diff options
| -rw-r--r-- | _drafts/emacs.md | 99 | ||||
| -rw-r--r-- | _posts/2013-02-15-read-the-code.md | 15 |
2 files changed, 114 insertions, 0 deletions
diff --git a/_drafts/emacs.md b/_drafts/emacs.md new file mode 100644 index 0000000..fdeb151 --- /dev/null +++ b/_drafts/emacs.md @@ -0,0 +1,99 @@ +--- +layout: post +category: emacs +title: Emacs modes +--- + +For Christmas, I'll share a few modes for Emacs I've discovered +lately. + +In the past few years, a few kit for Emacs have appears. The first +one was the Emacs Starter Kit (by technomancy), followed by Emacs +Prelude and the last one is Emacs Live. I don't use any of them, +since I've my own configuration crafted the way I like, but from time +to time I take a look at them to see what's new and what I can steal. + +I'm using Emacs on OSX, but I assume that most of the modes and +example in this article will work at least for Linux. + +## Packaging + +Since version 24, Emacs come with a packaging system. The official +repository is Elpa, but you can add other repositories + + * [Marmalde](http://marmalade-repo.org) + * [MELPA](http://melpa.milkbox.net) + +In your configuration, add the following code: + +..code +(require 'package) + +(add-to-list 'package-archives '("marmalade" . "http://marmalade-repo.org/packages/") t) +(add-to-list 'package-archives '("melpa" . "http://melpa.milkbox.net/packages/") t) + +(package-initialize) + +Now, if you want to install a package: M-x package-instal {name}. If +you don't know what to install, a simple M-x package-list-packages +will open a new buffer with all the packages available in the +repositories you've selected. + +If you're using multiple computers and you share you're configuration +between them, an easy solution is to list all the packages you want to +be installed everywhere: + +..code +(defvar my-packages + '(magit + paredit + rainbow-delimiters + rainbow-mode + helm + helm-projectile + clojure-mode + diminish + nrepl + exec-path-from-shell + highlight-parentheses + auto-complete + markdown-mode + tango-2-theme + cyberpunk-theme + popwin + yasnippet + helm-c-yasnippet + yaml-mode + ruby-block + ruby-end + ruby-tools + inf-ruby + yari) + "A list of packages to ensure are installed at launch.") + +(dolist (p my-packages) + (when (not (package-installed-p p)) + (package-install p))) + + +## Helm mode + +I've been using ido for a long time now. I knew about anything.el, +and I've probably tried it in the past. This project has been +renamed to Helm, and it's much much better. You could replace +entirely ido with it, but I've been using it as a complement. ido is +good to open/find files/buffers, but if you're working on a project, +Helm is more suited for that case. + +## auto-complete + +This one (and the next one) took me some time to decide I wanted to +use them. I've never been a big fan of auto completion stuff, and for +what I want, hippie-expand is generally good enough. But the video +for [Overtone](http://vimeo.com/22798433) convinced me to give it a +try, and I don't regret it. + +## yasnippet + + + diff --git a/_posts/2013-02-15-read-the-code.md b/_posts/2013-02-15-read-the-code.md new file mode 100644 index 0000000..275bb96 --- /dev/null +++ b/_posts/2013-02-15-read-the-code.md @@ -0,0 +1,15 @@ +--- +layout: post +category: devops +title: Read the code +--- + +The other day we had an interesting conversation at work. We were investigating Riemann, and we started to talk what it means to adopt this technology in our stack. Riemann is writen in Clojure, and no one at work is familiar with this language, or any other lisp (except for me, and I don't consider myself being fluent in it). + +So we started to talk about what it means to have only one person who can read the code, maybe add feature, find and fix bugs, etc. One of us pointed that we don't have to be expert with the source code of the stuff that we use. I mean, I've never read the code of MySQL, I've read only some part of Apache's code, and I've never looked at Linux. But at the same time, I usually read the code of the Perl and Python libraries I use frequently, and we also looked at the source of statsd and Graphite, in order to understand what they were doing, and find issues/bugs. + +Then our question drifted to "when do we have to be expert in something ?". I think that there's many answer to this question. + +As a developper, you *have* to be able to read and understand the code of the libraries you depend on (we've found some serious issues with libraries like httplib2 that way). + +For services you rely on in your infrastructure, it depends of the size of the tool and it's community. For something new, or when the documentation is not good enough, or the community is rather small, it's a good thing to be able to look at the code and explain what it does. When the project is bigger (MySQL, Riak, etc), I think you can ignore the source, and rely more on the community if it exists and is mature. |