Archives for

Learning Clojure

I have always had a thing for functional programming. Not so much for functional languages maybe, but definitely for functional programming principles. I had learned a tiny bit of Lisp at the uni and have fond memories of reading “On Lisp” by Paul Graham, but I never really tried to learn any Lisp for real. Or, I tried to learn Common Lisp again by reading “Land of Lisp” but gave up very quickly. I have tried to learn other functional languages with varying degrees of success (ranging from “read a tutorial or two and got the general idea” to “solved a couple of exercises and/or write trivially small programs”), but for some reason none of them really stuck.

One of those times that I decided I would try to learn a new language, I tried Clojure. I had read some hype about it but remembered Common Lisp as annoying so I was sceptical. Although this is probably extremely unfair, and I don’t really have any experience with any Lisp that is not Common Lisp (and then again that was only a bit of uni stuff), I got this impression that Clojure had all the good bits of Lisp while avoiding a lot of stuff that really bothered me.

So, in case you have avoided Clojure because you (think you) hate Lisp, you should know that:

  • Clojure makes the syntax a bit easier to scan (because it uses other characters, like [] and {}, for some data structures) while keeping all the advantages of “code = data”.
  • Another way it which Clojure feels more modern is function names: let*, setf, car, cdr, and others I hated are not there. To be fair this is both subjective and might be exclusive of Common Lisp.
  • As it runs on the JVM, there are many, many things you can take for granted, like available libraries, and well-known, documented and relatively sane way to install new libraries and figure out what is available.
  • Leiningen is a really nice tool for “project management” (run the project, install dependencies, run tests, etc.), so don’t be afraid if you hate Maven/Ant, the authors of Leinigen did, too *grin*
  • Clojure really insists on using immutable data structures, and has some very, very cool implementation for all the basic data structures that allow immutability while having excellent performance (in a nutshell, different copies share all the common items). Of course you do have mutable versions of those data structures for special cases, but they’re rarely needed.
  • There is a thing called ClojureScript, which is a language very, very similar to Clojure (exactly the same for most stuff) that compiles to Javascript, so you can use Clojure for both the front- and back-end of web applications. This is actually one of the reasons that convinced me to try Clojure, although I haven’t really used ClojureScript yet.
  • My impression is that it has more IDEs to choose from that the average Lisp: apart from VIM and Emacs, you have Eclipse, Lighttable, and many others.

If you’re interested in learning Clojure, the book I used was Clojure Programming, which I found really nice and informative, and I totally recommend. Although I haven’t completely groked all the concepts yet because I haven’t had the chance to use them in real settings, I have a basic understanding of most Clojure stuff and I know I can go back to the book and re-read parts I need.

And while I haven’t really written anything big in Clojure yet, I have had some fun learning it making two (very) small projects:

  • cludoku, a simple sudoku solver made to learn more than anything.
  • clj-flickr-memories, a small utility that fetches pictures from Flickr and sends them via e-mail. The idea is that is picks photos that were taken several years ago, “on a day like this”.

I’m looking forward to using and learning more Clojure, and hopefully using it at work someday…

Personal groupware

Oh, wow. It has been a long while since I wrote anything on this blog. Hopefully I’ll get back in shape soon. This time I wanted to write about groupwares for personal use. As you may know, I had already written a personal wiki, and several weeks ago I started thinking that it would be cool to have my own place to keep my calendar and my contacts, and use exactly the same list in any e-mail/calendaring program I use, regardless of the device.

After looking around a bit, I chose SOGo. Firstly, because I managed to get it to work (I had tried and failed with Kolab first); secondly, because it seemed simple/small enough to be appropriate for personal use. In my case, I’m using the version that comes with Debian Wheezy (1.3), but I don’t think it will be very different to install in other environments.

Installing SOGo

The installation itself is kind of long, and although it’s documented, the installation and configuration guide doesn’t give a straightforward list of steps to install. Instead, you have to read it and understand how the whole system is put together. This post is a reminder for myself, as well as documentation for others that might want to install SOGo in their own servers.

The first step is to install the Debian packages “sogo”, “postgresql” and “apache2″. Then, copy /usr/share/doc/sogo/apache.conf into /etc/apache2/sites-available/, and tweak x-webobjects-server-{port,name,url}. Then, enable Apache modules “proxy”, “proxy_http”, “headers” and “rewrite” and enable the new site with the following commands:

# a2enmod proxy proxy_http headers rewrite
# a2ensite sogo
# /etc/init.d/apache restart

The next step is to configure PostgreSQL. First, add this line at the end of /etc/postgresql/9.1/main/pg_hba.conf (or the equivalent for your PostgreSQL version):

host sogo sogo md5

Then create a PostgreSQL user “sogo” and a database “sogo” with the following commands (remember the password you set for the “sogo” user, you’ll need it later):

# createuser --encrypted --pwprompt sogo --no-superuser --no-createdb --no-createrole
# createdb -O sogo sogo

Then connect to the database with psql -U sogo -h sogo and create a table “sogo_custom_auth” with this SQL:

CREATE TABLE sogo_custom_auth (
  c_uid varchar(40) CONSTRAINT firstkey PRIMARY KEY,
  c_name varchar(40) NOT NULL,
  c_password varchar(128) NOT NULL,
  c_cn varchar(128),
  mail varchar(80)

Then calculate the MD5 for whatever password you want for your user (eg. with echo -n 'MY PASSWORD' | md5sum -) and connect again to the database with psql, this time inserting the user in the database:

insert into sogo_custom_auth values ('myuser', 'myuser', '<PASSWORDMD5SUM>', 'User R. Name', '');

Now you have to configure SOGo so that (1) it can connect to the database you just created, and (2) it looks for users in that database. You do (1) by editing /etc/sogo/sogo.conf to set the correct username and password for the PostgreSQL database; you do (2) by adding the following lines to your /etc/sogo/sogo.conf:

SOGoUserSources = (
    type = sql;
    id = directory;
    viewURL = "postgresql://sogo:@";
    canAuthenticate = YES;
    isAddressBook = YES;
    userPasswordAlgorithm = md5;

Finally you’ll have to restart the “sogo” service with /etc/init.d/sogo restart so it uses the updated configuration.

Importing contacts

It’s easy to import contacts if you have them in vCard format. Just login to SOGo (should be https://<YOURSERVER>/SOGo/), go to Address Book, right click on Personal Address Book and select “Import cards”.

If you want to import the contacts in your Google account, go to GMail, click on the “GMail” menu at the top left (just below the Google logo), and select “Contacts”. From there, you have a menu “More” with an “Export…” option. Make sure you select vCard format.


Of course, the whole point of setting all this up is making your e-mail/calendaring applications use this as a server. I think there are several formats/protocols SOGo can use, but WebDAV/CardDAV works out of the box without any special tweaking or plugins so I went for that. I have only tried contacts, mind you, but I imagine that calendar information should work, too. I haven’t tried having my e-mail in SOGo because I don’t care :-)

I have briefly tried with two different clients: Evolution running on Ubuntu Raring, and Android. Both seem to be able to get data from SOGo, but here are some things to note:

  • The WebDAV/CardDAV URL for the contacts should be something like: https://<YOURSERVER>/SOGo/dav/<YOURUSERNAME>/Contacts/personal/. The Android application seemed to have enough with https://<YOURSERVER>/SOGo/ or https://<YOURSERVER>/SOGo/dav/(can’t remember which one), though, so maybe it’s Evolution that can’t autodiscover the URL and needs the whole thing spelled out.
  • Evolution seems to have a problem with HTTPS CardDAV servers that don’t use port 443. If yours runs in a different port, make sure you make the WebDAV URLs available through port 443 (with a proxy or similar).
  • Certain contact editing operations seem to crash Ubuntu Raring’s version of Evolution. A newer version seemed to work fine on Fedora 15’s live CD and an older version seemed to work on some Debian I had around.
  • Android doesn’t seem to support CardDAV natively, but there’s a set of applications to add support for it. I have tried “CardDAV-Sync free beta” for contact synchronisation and at least it seems to be able to read the contacts and get updates. I have only tried the “read-only” mode of operation, I don’t know if the other one works.

In conclusion, this post should contain enough information to get you started installing SOGo on your own server and having some e-mail clients use it as a source for contacts. Feel free to report success/failure with other clients and platforms. Good luck!

Javascript for n00bs

Recently a friend asked me for an easy way to learn JavaScript. I can’t remember how I learned myself, but I do remember some things that were surprising coming from other languages, or that I had guessed wrong or took me a while to understand for whatever reason, despite not really being complicated at all.

As I wrote the list for her anyway, I figured it could be useful for other people, too, so here it goes, somewhat edited:

  • It’s object-oriented, but it doesn’t have classes (instead, it’s prototype-based). The Java-like syntax often makes you think it’s a normal object-oriented language, but it’s not.
  • What are called “objects” in Javascript are hashes, really. It just happens that the values for some of the keys are functions. Related: object.prop and object['prop'] are equivalent.
  • The for (x in obj) { ... } statement is strictly an object (not an array) thing. If you need to traverse an array with a “for” loop, you have to use the C-style form: for (var i = 0, len = obj.length; i &lt; len; i++) { ... }.
  • There are no methods in the sense of other programming languages. When you do object.blah(...) in JS, you’re simply calling the blah function with the “context” (ie. the value of the reserved word “this”) set. For example, you could do var f = obj.blah; f(...). That would (a) be perfectly legal, and (b) set “this” inside that function call to be undefined, not obj. The “call” function allows you to set that binding explicitly, like so:, ...).
  • This implies something that I find ugly: if you have two levels of functions, you need to save the value of the this of the outer function in some variable if you want to use it in the inner function. See example below:
  • JavaScript has functional language features: functions are first class citizens, and higher-order functions are possible and even common.
  • You should use the operators === and !== instead of == and != (the latter are too liberal with type casting).
  • You should get used to always using semicolon at the end. Although the interpreter adds them in most cases, in some other cases it might be a big surprise.
  • Also, JavaScript is full of small design problems and quirks. Learn them, learn how to avoid them, and you use tools like “jshint” or “jslint“. That way it’s much easier to enjoy the language :-)
  • Maybe I’m weird, but I have always found programming “inside” the browser to be awkward and clunky. To fool around with the language, you might want to use Node instead.

Example of two levels of functions:

// Imagine this function is a method
function foo(widgetList) {
    // Save the value of "this" for later
    var that = this;
    widgetList.forEach(function() {
        // Here, "this" points to widgetList. If we need
        // the object the "foo" method was called on, we
        // need to refer to "that", saved above
    }, widgetList);

Resources (that I haven’t read myself, but seem useful):

Book summary: See What I Mean (II)

This is the second half of my summary of “See What I Mean“, by Kevin Cheng. It covers from chapter 6 until the end. See the first half on this blog.

Laying out the comic

Once the script is ready, you sketch the comic storyboard to answers these questions:

  • Composition of each panel (where characters go). See example on p.108. Tips: rule of thirds, writing speech bubbles first to use space better, avoid intersecting lines in foreground and background.
  • Perspective (how the audience will look at the characters). Use and be aware of perspective and distance (where the camera is). For inspiration, have a look at Wally Wood’s “22 panels that always work”.
  • Flow & progression (change of locations, how time passes, …). What happens between panels should be obvious. Take care of small details like which hand is used, or the side of something.

Drawing and refining

Resources to make higher-quality art, faster:

  • Reference materials: tracing over stuff is easy, quick and gives good results (eg. photographs, incl. made by yourself for the purpose, or avatar generators like IMVU or XBox).
  • Templates: a couple available on the net, but tend to be limiting. Create your own templates?
  • Comic creation software: several, seem too complex and/or expensive.
  • Online creation tools: websites like and seem interesting.

Applying comics

Possible uses of comics:

  • Requirements/vision: documents don’t get read, and if they do, they’re ambiguous. Comics are easy to read and explaining requirements through real use-cases often works better.
  • Good start for projects/companies: comics help you validate your ideas before you build anything, or decide exactly what to build. In these cases, make the person read the comic on her own, then explain with her own words as she reads again. That way, misunderstandings are easier to spot. Also, make people say how it relates to them: if they or someone they know would use it.
  • Marketing materials. Explaining your product, or why it’s special, through comics.
  • Certain kinds of documentation.

It’s generally easier to get people to read comics than to read text descriptions of the same content.

Breaking Down the Barriers

When convincing bosses to approve the use of comics, there’s usually less resistance than what people think. That said, understand who you’re convincing and what arguments to use (eg. some designers think that comics take relatively little time compared to alternatives, or the evidence suggesting that words + pictures help in understanding and memory). Fidelity and polish in comics (and any other medium) needs to be higher for certain audiences, eg. bosses or corporate clients.

Useful templates and references

The appendix has ideas about how to show someone in front of a computer, interesting panels, gesture dictionary and a facial expression dictionary:

Facial expression dictionary

Book summary: See What I Mean (I)

Oh, boy. It’s been a while, hasn’t it? This is the first post of the year, and it will be about the first book I’ve finished, “See What I Mean” by Kevin Cheng (which, by the way, I got from O’Reilly’s Blogger Review Program). It’s a book about using comics “for work”, to communicate ideas like product concepts, user stories, and such, more effectively.

This post will cover about half the book, from chapters 2 to 5. These notes are much more useful if you have the book to refer to the pictures, but hey, this is mostly for me ;-)

Properties of comics

Basic vocabulary for the anatomy of comics:

Anatomy of a comic

Properties of comics:

  1. Communication: comics don’t need words, or can express a lot without them (p. 23). They’re universal!
  2. Imagination: characters with few features make more readers relate. This can be applied to UI mockups/sketches, too: people focus less on design if it’s abstract (p. 25,26).
  3. Expression: give interpretation to words (“I’m sorry”/”Thank you” examples with different facial expressions on p.27). When combining text and pictures, the sum is bigger than the parts.
  4. Time: comics can express time passing by using empty or repeated panels. Also, via words in “narration” and reference objects (like burning candles, clocks, or day/night).

Drawing 101

Drawing faces is easy! Eyebrows and mouth go a long way to express mood. Body language helps quite a bit, too, and it’s easy to represent. See examples of combinations of eyebrows and mouths on p.47, 48. In faces, eyes go in the middle, and dividing the bottom half in three gives bottom of nose and mouth. Also see for tips on how to draw different things.

Approx. proportions for a person are two heads for torso, 1 for hips/groin, and 3 for the legs. Body language basic guidelines: leaning forward shows interest, concentration or anger (depends on arm position and context; curling the spine works, too); arm position can tell a lot (lifting one or both, on chin, in front of body); head positions don’t change much, but facial expressions or where the person is looking, does. When drawing body language, try to imagine the situation and exaggerate it. It often helps to start with a stick figure, then add detail.

Steps to create a comic

There’s no single correct way to create a comic. One possible approach:

  1. What’s your comic about? Why you’re using comics, what to include, who’s the product and comic for. This chapter is about this step.
  2. Writing the story: create scripts in words, an outline, define characters, setting and dialogue.
  3. Laying out the comic: plan each panel, what to show and how much of it.
  4. Drawing/refining the comic.

What’s your comic about?

Don’t approach the question broadly and vaguely, break it down! Define goals (what to accomplish), length (3-8 panels encouraged; should fit on site homepage, a postcard or e-mail; if longer, consider physical prints), audience (expertise level, context), and representative use case (help your readers understand why they should care).

Writing the story

When writing a script, you can use a similar format as that of film scripts. Each panel’s needs four primary elements:

  1.  Setting (defined up front, usually in bold). It can be time of day, location, or maybe what happens in the background. It depends heavily on the audience. The first panel can help with the setting (“establishing shot”). There are different graphical ways to convey a setting: the description of it describes a concrete way (eg. exterior of coffee shop vs. interior of coffee shop vs. close-up of coffee cup being served).
  2. Characters (all caps, bold). There are several types: target audience, people who interfact with them, and objects/locations that play a significant role (eg. the solution). Target audience is typically based on personas, go make them if you don’t have them already.
  3. Dialogue (regular font). It’s defined by more than the text itself: fonts, sizes, colours, bubble shapes or the split into different bubbles are very important, too! The text can be hard to get right: make it fit the character, keep it realistic (avoid marketing jargon and overly enthusiastic conversation). Captions can communicate time, setting, action, and even dialogue, but don’t add unnecessary information in them, and always try to speak from the character’s voice.
  4. Actions (usually italics). It’s what characters do, depicted in the panel art.

How to tell a story: remove all unnecessary. You can combine several points in a single panel. Show, don’t tell. See examples on p.98-100.

And that’s it for today. In a few days I’ll publish the rest of the summary.

Writing music, printing .gpx files

UPDATE 2012-10-27: I have updated the .gpx viewer to recognise silences! Download the updated version.

Note: if you’re only interested in printing .gpx files, download and follow the instructions in the README.txt file.

I have been playing with my last band for over half a year now. From the beginning the idea was to write and play our own material, but actually we had been mostly doing song covers. After some time practising and after having our first gig, we decided to start focusing more on writing our own songs. That’s something I had never done, so it sounded intriguing, challenging and a bit scary (as I essentially don’t know any music theory, and I don’t even own a guitar or keyboard, it seemed extra difficult for me to come up with ideas for new songs). So I decided to try it out, and that meant looking for a way to try it out ideas and record them.

I tried many different programs both for Linux and for Android (I even tried a couple of Windows programs under emulation, but they seemed terribly complex), but nothing was really satisfactory. After searching a lot, I found Guitar Pro for Android (a tablature editor). It wasn’t really what I was thinking about at first, but I found that it was actually the best for my needs: thinking in terms of tabs is easier for me, as I don’t really know music but I have played a bit of guitar. Guitar Pro for Android is supposed to be mostly a tab viewer, but it does have a small feature for “notes”. The idea is that you’re on the bus or whatever, and come up with some musical idea: in that case, Guitar Pro allows you to quickly write it down. As you can listen to what you’re writing, I don’t need an actual guitar/bass to check if what I’m writing really sounds like I think.

Guitar Pro for Android works fairly well for my needs, but something really bugged me: you can only export the music you have written to the .gpx format, which didn’t seem supported by any open source program I knew of. That really pissed me off because it looked like I would be forced to buy Guitar Pro for Linux in order to print the music I had written (I wanted to do so in order to distribute it to my bandmates). After searching the net for a while I found the excellent alphaTab library, but it seemed to not recognise many of the parts I had written, which was a disappointment. See below for the nerdy details, but long story short I improved slightly alphaTab to support Guitar Pro mobile’s .gpx files so now I can print all the music I write, w00t! You can download a little Guitar Pro file viewer/printer I wrote using alphaTab. It’s basically a webpage that can show Guitar Pro files, see the README.txt for details.

Now on to the technical details. You can skip the rest of the blog post if you’re not interested ;-) alphaTab is an open source library that can read several Guitar Pro formats. It can play them, render them in the browser, and do other things. It’s written in a language called Haxe, which compiles to, among others, Javascript. If you download the alphaTab distribution you’ll get a Javascript version of the software that you can use directly in your browser, which is really cool and already does a bunch of stuff, but there were two changes I wanted to do: fix the bug that made it not understand most of the files Guitar Pro mobile produced, and add an option to upload files from the browser (instead, the example programs read tabs directly from a path relative to the programs).

For the first, I debugged a bit and quickly realised that the problem was that alphaTab was being too strict: Guitar Pro mobile was producing some “empty” notes and beats, and that made alphaTab consider the file corrupt and not show it at all. Adding some code to ignore those empty notes seemed enough to make alphaTab render the file. I filed bug #31 on GitHub and added the ugly patch I made :-)

For the second, as the alphaTab API needed a URL to load the tablature file, I had to learn a bit more about the Javascript File API and be a bit creative, replacing the file loader in alphaTab with something that would load the local file using the FileReader object, as you can see here:

function handleFileSelect(evt) {
  // Fake the getLoader function so make it support data
  // URIs: apparently jQuery can't make an Ajax request to
  // a data URI so this was the best I could think of.
  alphatab.platform.PlatformFactory.getLoader = function() {
    return {
      loadBinary: function(method, file, success, error) {
        var reader = new FileReader();
        reader.onload = function(evt) {
          var r = new alphatab.platform.BinaryReader();
  document.getElementById('files').style.display = 'none';

With these two changes, alphaTab finally does what I need, so I don’t need to buy Guitar Pro for Linux just to print tabs. I might buy it anyway for other reasons, but it’s nice to not be forced to do so ;-)

I hope this code and small program is useful to someone. If not, at least I have solved a pretty annoying problem for myself.

Exceptions in Node

Whoa, boy. It seems I haven’t written for a good while now. Let’s fix that. One of the things I had in my list of possible posts was my experiments (and frustrations) with Javascript exception classes under Node, so here we go:

I needed to have several exception classes in Javascript (concretely, for RoboHydra, which works under Node). My first attempt looked something like this:

function NaiveException(name, message) {, message); = name;
 this.message = message;
NaiveException.prototype = new Error();

That seemed to work well, except that the stacktrace generated by such a class doesn’t contain the correct name or the message (notice how I even try to set the message after inheriting from Error, to no avail). My second-ish attempt was to try and cheat in the constructor, and not inherit but return the Error object instead:

function ReturnErrorException(name, message) {
    var e =, message); = name;
    return e;
ReturnErrorException.prototype = new Error();

That did fix the stacktrace problem, but breaks instanceof as the object will be of class Error, not ReturnErrorException. That was kind of a big deal for me, so I kept trying different things until I arrived at this monster:

function WeirdButWorksException(name, message) {
    var e = new Error(message); = name;
    this.stack = e.stack; = name;
    this.message = message;
WeirdButWorksException.prototype = new Error();

This is the only code that seems to do what I want (except that the stack trace is slightly wrong, as it contains an extra line that shouldn’t be there). I tried in both Node 0.6 and Node 0.8 and the behaviour seems to be the same in both. In case you’re interested, here’s my testing code showing the behaviour of the different approaches:

// NO WORKY (breaks stacktrace)
function NaiveException(name, message) {, message); = name;
    this.message = message;
NaiveException.prototype = new Error();
// NO WORKY (breaks instanceof; also stacktrace w/ 2 extra lines)
function ReturnErrorException(name, message) {
    var e =, message); = name;
    return e;
ReturnErrorException.prototype = new Error();
// WORKS (but has extra stacktrace line)
function WeirdButWorksException(name, message) {
    var e = new Error(message); = name;
    this.stack = e.stack; = name;
    this.message = message;
WeirdButWorksException.prototype = new Error();
 WeirdButWorksException].forEach(function(eClass) {
    var e = new eClass('foo', 'bar');
    console.log(e instanceof eClass);
    console.log(e instanceof Error);

It feels really strange to have to do this to get more or less proper exceptions under Node, so I wonder if I’m doing anything wrong. Any tips, pointers or ideas welcome!

Gustav Vigeland’s sculpture park

Gustav Vigeland‘s sculpture park in Frognerparken is without doubt my favourite part of Oslo. It’s “simply” a collection of sculptures of people doing different things, but ever since the first time I saw it I fell in love with the park. I have been there many times and I have taken many pictures of the sculptures, and when I went there again about a week ago I remembered how much I like it and decided it was about time I wrote about it and made my personal “ode” to it.

The most famous sculpture is the “Angry Boy”, a sculpture of a little boy crying. While it’s expressive, funny and original, I think it’s a pity that many visitors seem to only pay attention to that one, and miss the dozens of amazing sculptures around it.

The reason why I like these sculptures so much is that, in my view, they represent the essence of what is being human. They are completely stripped down, timeless and lacking unnecessary elements. Adding clothes to these sculptures wouldn’t work because they would make them belong to a concrete time and culture, and thus lose their expressive power. I also like the nakedness because it reminds me of how clothes and many other social conventions often hide how similar we all are, and how we often forget what really matters and what doesn’t. Thus, it’s no surprise I get annoyed when people refer to it as the “park with the naked sculptures” :-) They’re indeed naked, but that’s missing the point of the park miserably.

When I think about why I like these sculptures so much, I can’t help thinking about the book “Technopoly” and the book (and movie) “The Road“. I see all three as being about being human and about stopping for a second, forgetting about all the things you assume (as part of your everyday life in whatever society you live in) and considering what you think is actually important; what is “essentially human” and what is simply a detail of the current culture and time; what is strictly necessary and what “needs” are artificial.

If you have never been in the park, here’s a collection of pictures I have taken (the one above is by Dion Hinchcliffe). You can see the full version of these pictures and more on Flickr:

Book summary: Eating Animals

This is my summary of the book “Eating Animals” by Jonathan Safran Foer. Contrary to what the title may suggest, it’s not a “vegetarian book” defending some variant of the argument “animals are cute, don’t kill them”: it’s a book about factory farming (it’s true that one of the conclusions is that you essentially have to go vegetarian to avoid factory farming meat, but this book is for anyone interested in how food is produced). Sadly I had to skip many interesting stories and data in order to give the summary some continuity.

Edit: corrected statement “total collapse of all fished species in 50-100 years” to read “we have depleted large predatory fish communities worldwide by at least 90% over the past 50–100 years” (the article it linked had the second statement, not the first; although it does say “We conclude that today’s management decisions will determine whether we will enjoy biologically diverse, economically profitable fish communities 20 or 50 years from now, or whether we will have to look back on a history of collapse and extinction that was not reversed in time”). I think the original statement is true, but I couldn’t find a reference for it.

Factory farming

Factory farming (and industrial fishing) is a mindset: reducing production costs to the absolute minimum, ignoring or “externalising” costs such as environmental degradation, human disease or animal suffering. Nature becomes an obstacle to overcome.

Factory farming possibly accounts for more than 99% of all animals used for meat, milk or eggs. As for industrial fishing, we have depleted large predatory fish communities worldwide by at least 90% over the past 50–100 years (see also Sylvia Earle’s TED talk, not mentioned in the book but related). It doesn’t help that the so-called “bycatch” is actually much more than the actual fish: typically 80% to 90% (and up to around 98%), which is tossed back (dead) into the ocean.


There is scientific consensus that new viruses, which move between animals and humans, will be a major global threat into the foreseeable future. According to the WHO the “World is ill-prepared for ‘inevitable’ flu pandemic“. The factory farm conditions encourage diseases in animals (some of them virtually unknown outside of factory farming), that end up in the actual food in the supermarkets. It’s even worse considering the animals are constantly fed with antibiotics (livestock gets almost 6 times more antibiotics than humans… if you trust the industry’s own numbers!), making the resulting diseases much harder to fight off for humans. The whole chapter 5 is filled with descriptions of filthy, dangerous and disgusting practices that are absolutely common and normal in (US, at least) factory farming.

Factory farming animal shit is a big problem both because of the quantity and for being so poorly managed: it kills wildlife and pollutes air, water, and land in ways devastating to human health. Its polluting strength is 160 times greater than municipal sewage, and yet there’s almost no waste-treatment infrastructure for farmed animals. Ignoring these problems are part of why factory farming is so “efficient”. The problem, of course, is not the shit in itself but the desire to eat so much meat and pay very little for it.


Simply put, someone who eats factory farmed animals regularly can’t call herself an environmentalist.

It takes 6 to 26 calories fed to an animal to produce 1 calorie of animal flesh (the vast majority of the food produced in the US is fed to animals). The UN special envoy of food called using 100 million tons of grain and corn a “crime against humanity”, but what about animal agriculture, which uses more than 700 million tons of grain and corn per year, much more than enough to feed the 1.4 billion humans in poverty?

The FAO/UN summarised in “livestock’s long shadow — environmental issues and options” (which has been criticised BTW!):

The livestock sector emerges as one of the top two or three most significant contributors to the most serious environmental problems, at every scale from local to global. The findings of this report suggest that it should be a major policy focus when dealing with problems of land degradation, climate change and air pollution, water shortage and water pollution and loss of biodiversity. Livestock’s contribution to environmental problems is on a massive scale […]

Factory farmer perspective

Some interesting comments from a factory farmer (note that I don’t find them convincing, but there are some good points that need to be explained or considered when proposing alternatives to factory farming):

In fact, we have a tremendous system. Is it perfect? No. […] And if you find someone who tells you he has a perfect way to feed billions and billions of people, well, you should take a careful look. […] If we go away from it, it may improve the welfare of the animal, it may even be better for the environment, but I don’t want to go back to […] starving people.  […] Sure, you could say that people should just eat less meat, but I’ve got news for you: people don’t want to eat less meat. […] What I hate is when consumers act as if farmers want these things, when it’s consumers who tell farmers what to grow. They’ve wanted cheap food. We’ve grown it. […] It’s efficient and that means it’s more sustainable.

Closing thoughts

We shouldn’t kid ourselves about the number of ethical eating options. There isn’t enough nonfactory pork in the US to serve New York City. Any ethical-meat advocate who is serious is going to be eating a lot of vegetarian fare.

Ending factory farming will help prevent deforestation, curb global warming, reduce pollution, save oil reserves, lessen the burden on rural America, decrease human rights abuses, improve public health, and help eliminate the most systematic animal abuse in world history.

A good number of people seem to be tempted to continue supporting factory farms while also buying meat outside that system when it is available. […] Any plan that involves funnelling money to the factory farm won’t end factory farming […] If anyone find in this book encouragement to buy some meat from alternative sources while buying factory farm meat as well, they have found something that isn’t here.

Other quotes

I can’t count the number of times that upon telling someone I am vegetarian, he or she responded by pointing out an inconsistency in my lifestyle or trying to find a flaw in an argument I never made (I have often felt that my vegetarianism matters more to such people than it does to me).

Virtually all of us agree that it matters how we treat animals and the environment, and yet few of us give much thought to our most important relationship to [them]. Odder still, those who do choose to act in accordance to these uncontroversial values by refusing to eat animals […] are often considered marginal or even radical.

It might sound naive to suggest that whether you order a chicken patty or a veggie burger is a profoundly important decision. Then again, it certainly would have sounded fantastic if in the 1950s you were told that where you sat in a restaurant or on a bus could begin to uproot racism.

We can’t plead ignorance, only indifference […] We are the ones of whom it will be fairly asked, What did you do when you learned the truth about eating animals?

It shouldn’t be the consumer’s responsibility to figure out what’s cruel and what’s kind, what’s environmentally destructive and what’s sustainable. Cruel and destructive food products should be illegal. We don’t need the option of buying children’s toys made with lead paint, or aerosols with chlorofluorocarbons, or medicines with unlabelled side effects. And we don’t need the option of buying factory-farmed animals.

Small experiments with Cherokee

A couple of weeks ago I decided to move my wiki (see Wiki-Toki on GitHub) and my package repository (see Arepa on CPAN) over to a new machine. The idea was to move it to some infrastructure I “controlled” myself and was paying for (mainly inspired by the blog post “A Set of Tenets I Have Set Myself“). As I was curious about Cherokee and this was an excellent opportunity to learn it, I decided to use it as the web server.

I have to say I was pretty impressed by how easy it was to set it up. Although I did have several small problems, most of them were less related to Cherokee itself, and more related to me not being very familiar with Node application configuration outside of Joyent’s environment, or FastCGI configuration. In particular, the web-based configuration is brilliant: you don’t have to open or know the format of any configuration files, but instead configure everything from a pretty powerful UI (which in the end writes a text configuration file of course, so you can always automate or generate the configuration if you need to). I even knew this already, but seeing it in action was pretty impressive. To avoid security problems with people accessing that configuration interface, there’s this little tool called cherokee-admin that starts another web server with the configuration interface (tip: pass the -b option without parameters if you want to connect to it from a different machine, which is the case unless you’re installing Cherokee in your own PC). On start it generates a random admin password, which you use to login.

Static content serving, CGI, FastCGI, specifying certain error codes for certain paths, and reverse proxying was all very easy to set up. There was only a small problem I bumped into: tweaking URLs in reverse-proxied responses. In my situation, I was doing reverse proxying from port 443 to port 3000. As the final application didn’t know about the proxy, it generated URL redirections to “http://…:3000/” instead of “https://…/”, so part of the process of proxying was fixing those URLs. Cherokee, of course, supports this out of the box, in a section called “URL Rewriting”. Each entry in that section takes a regular expression and a substitution string. My first attempt (“” -> “”) didn’t work: all URL redirections were changed to “”, disregarding the rest of the URL. After some time trying different things, I decided to try with “*)” and “$1″. As it turns out, that worked like a charm! The documentation does mention that it uses Perl-compatible regular expressions, but I thought the HTTP reverse proxy documentation could have been more explicit in this regard.

But apart from that detail, everything was very smooth and I’m very, very happy with it :-)