Oikeutta Eläimille, the Finnish animal rights organization, unveiled their new campaign “Julma totuus” yesterday. And what a beautifully executed campaign it is! They have documented the state of things on 101 Finnish farms in videos and photographs, and made it all available online.

The TV magazine news show A-Studio picked up on the matter and broadcast some of the material. They also had some talking heads in to discuss the material. Jaana Husu-Kallio, the director of The Finnish Food Safety Authority failed to put up a convincing argument, and instead alluded to these being “isolated incidents” and made some vague references to “scientific advances” that are supposed to alleviate the suffering of these animals.

They also had Elisa Aaltola (a prominent animal ethics expert) in, and boy, did she make her case like Noam fucking Chomsky! While successfully linking the broader issue of our twisted relationship to animals to the discussion, she also had her facts straight, where Husu-Kallio didn’t: When asked about what the EU regulations say about the crowdedness of broiler chicken buildings, she did not have a number. Aaltola did: They are allowed to stock up to 38 kilograms of chickens per square metre.

It will be interesting to see how all of this plays out. I’m not getting my hopes up though. (Then again the Facebook group has gone up to 360 members in one day…) Certainly most of the information here is nothing new, and so far it has mostly been stifled by the power of denial. But if there is one person in the country who, because of this material, starts to question the origins of their food, and that results in their consumption of animals going down, then, well, there’s that much less suffering in the world. It’s a nice thought.

It feels good to see an issue so important to me get some media attention. The animal rights movement has been so effectively marginalized that it rarely gets this kind of coverage, whereas this arse dribble is funded by the state. Go figure.

This weekend I was quite vividly reminded of why Warp Records was one of the most important sources of music for me during my teenage years. This happened in the form of two albums I hadn’t heard (of) before:

Mirrored by Battles, released earlier this year blew my socks off, and is quite unlike anything I’ve ever heard before.

Body Riddle by (Chris) Clark is.. well.. classic Warp. It’s been out for about a year now, and seems to be heavily influenced by RDJ et al. Lovely.

It’s been about a year now since I stopped eating animals. As the reasons I did this were mainly ethical, becoming a proper vegan has been the goal ever since. To commemorate this “anniversary”, I think this is as good a time as ever to stop fucking around and take it to the next level.

There are a few main areas I still need to concentrate on before I’m able to call myself a vegan:

Food

For the past year I’ve pretty much been a lacto-ovo vegetarian, meaning that although I haven’t eaten animal body parts, I’ve continued consuming eggs and dairy in situations where it would have been somehow inconvenient to decline them.

For my eating habits at home it isn’t a very big step to drop eggs and dairy, as I very seldom buy them anyway and never use them for food I cook myself.

It does mean dropping many ready-made and half-made products though, and start cooking more often. I’m actually looking forward to this, as I like cooking and this is a good reason to spend more time on it. Living in Kallio also has the big advantage that there is a phenomenal variety of ethnic food shops and other vegan-friendly shops all within a few blocks from where I live.

The biggest change for my daily eating habits will be that for the most part I won’t be able to eat the food they serve at work, as even the vegetarian choices usually contain one form of animal secretion or another. This isn’t a big deal either, though, as I only have lunch at work occasionally, and I can always take food with me from home.

I’ll also educate my family a bit on what I’ll be able to eat. This won’t be a problem with my immediate family as my mum is very aware of these issues. Events like x-mas are a bigger challenge, but I’m confident I’ll be able to communicate my situation with a reasonable amount of explaining.

Drink

For the most part, I won’t have to change my drinking habits (thank God!), but I know they do use animal parts to make many wines and beers, so I’ll keep an eye on it.

Nutrition

I’ll start taking plant-based B12 as pills, as well as D in wintertime (although I’m aware I probably should have done that even in my carnivorous days).

Protein intake is not going to be an issue, but I’ll need to be aware of it to make sure I get enough.

Most other nutritional issues will be taken care of naturally by having enough diversity in my diet. I might try keeping a dietary calendar for a while and calculating my nutritional intake, but let’s see.

Clothing

I’ll stop buying pieces of animal carcasses to decorate myself with. This affects mostly shoes, belts, wallets, coats, and other leather goods. The apparel I already have that’s made from animals, I’ll use until they wear out naturally.

Fur is no issue, as like any sane person, I’ve always declined it.

Cosmetics

I don’t use a lot of cosmetics, but I’ll make sure the ones I do use don’t include animal parts and haven’t been tested with animals.

Medication

I don’t use a lot of medication either, apart from the occasional painkiller.

In situations where I do need medication though, I won’t decline animal-tested meds when I need them. I’m aware that there are rarely options for medication that haven’t been tested on animals. However, I will try to be aware of my options and use vegan-friendly medication where such an option exists.

Travel

This is what I think will be the hardest part of becoming a vegan. I like to travel, and I’ve been to places where vegetarian food has been difficult to find.

In most places, this is just a matter of inconvenience though. It will mean that in many places I may need to cook my own food and/or not have a very diverse diet. But this is very much an inconvenience I’m prepared to accept.

So, I still have some work to do in becoming a proper vegan. In the near future, I might write a separate post on the reasons I’m doing it. For now, I’ll just say it gives me a great peace of mind to know that I’ll no longer be directly paying for violence and murder to be inflicted on sentient beings.

Oh, and the effects on climate, global food distribution, as well as my own health are a pretty nice bonus too.

I think Google’s well-known “20 percent time” is an absolutely brilliant idea, and we’ve been having discussions of maybe implementing something similar at EfiCode. I’m fairly sure it could end up being the best thing since sliced bread.

Here’s my take on what we could do, which I call Freeform Fridays. It consists of three key ideas: freeform work, brown bag sessions and video sessions.

The basics

Every Friday, say after 10 am, everyone is allowed to work on whatever they want. There are only two rules:

1. Whatever you do, it should not be directly related to any project you’re currently involved in at work
2. You should share with others what you’re up to

The time could be spent studying or experimenting with new technologies. It could also be used programming on some personal project. It could be contributing to an open source project, or starting a new one. It could be doing pro bono development for a non-profit organization. It could be solo work or teamwork.

If someone has an important meeting on a Friday, or if they’re just extremely busy, the free time could be rescheduled to another day.

Brown Bag Sessions

Every Friday we would provide the possibility to have take-out lunch together, and every Friday someone would do an informal presentation about some idea, technology or problem they’re working on, after which we could discuss it. We could probably schedule the sessions with a wiki page.

The Video and Pulla Sessions

We could continue the video sessions we’re already doing. They would just merge into the concept of “Freeform Fridays”.

One of the most important things Ruby did for me was that it helped me break out of the Java ghetto. Previously, Java was the only language I really knew well, and because of that I naturally thought it was the answer to every problem in the world. I’ve since learned how severely this limited my creativity and ability to solve programming problems. Perhaps even more importantly, it actually made programming enjoyable again.

However, I still use Java professionally all the time, and don’t actually think it’s that bad. My point is that learning to program in other languages well has greatly improved my ability to think. This has made me so much better at Java as well, than I would be had I not made the leap.

So, as learning many different languages and frameworks is obviously a good idea, I’ve been thinking of possibilities to enable people to experiment with them. One idea that this severely hung over brain of mine produced today was to organize an internal “coding competition” at EfiCode. Rails Rumble was a good experience for me, and led to the thought that maybe we could do something similar.

The Gist of It

People are divided into 4-5 teams. Each team will create and deploy a web application, and they will do it in two days. The application domain can be anything, and there are no restrictions for the functionality (apart from that it must be browser-based). The only rule – and this is the interesting part – is that the application must be done in a language and framework the team has never used before. Here’s some possibilities:

• Ruby and Rails
• Smalltalk and Seaside
• Python and Django
• Erlang and Erlyweb
• Scala and Lift
• Groovy and Grails

All members of a team will be physically located in the same space. Meeting rooms would probably be ideal for this. All workspaces are equipped with network connections, a projector, whiteboards, index cards and other writing materials, and some refreshments.

Each team will get their own Subversion repository, and a fresh Linux server / VPS for deployment. All other software usage is voluntary, but access to Mingle, Trac, Campfire and a wiki will be provided.

At the end of the second day, all teams gather in the same place, and over a few beers, will in turn present their application. They’ll also be asked to discuss the peculiarities of the technology they chose, what was good about it and what wasn’t that good.

After the presentation, we’ll have a vote on whose application was best. The winners will receive some kind of prize, such as some cool gadgets.

The comp would ideally be scheduled to start on a Thursday morning and finish the following Friday evening. We could possibly do this at the time of this year’s x-mas party, so after the competition we could continue with the festivities.

I think this would be an extremely fun exercise in programming and teamwork. And who knows, maybe the beginnings of a great product or two would also come out of it.

While enabling automated Selenium test runs for a project, I came across a situation where I needed to run the tests in a browser on a headless Linux (RHEL) server. I wanted to always have an X Virtual Framebuffer on to run Firefox in, so I added it to init. The following script starts Xvfb on display :2.

1. Add the following to a file called /etc/init.d/xvfb

#!/bin/sh
#
# Startup script for Xvfb
#
# chkconfig: 2345 79 21
# description: Xvfb - X virtual frame buffer
# processname: Xvfb
#
# Source function library.
. /etc/rc.d/init.d/functions

case "$1" in
  start)
        echo -n "Starting Xvfb services: "
        Xvfb :2 -screen 0 800x600x8 &
        touch /var/lock/subsys/Xvfb
        ;;
  stop)
        echo -n "Stopping Xvfb services: "
        killproc Xvfb
        rm -f /var/lock/subsys/Xvfb
        ;;
  status)
        status Xvfb
        ;;
  restart|reload)
        $0 stop
        $0 start
        ;;
  *)
        echo "Usage: xvfb {start|stop|status|restart}"
        exit 1
esac

2. Make it runnable

chmod +x /etc/init.d/xvfb 

3. Add it to boot

/sbin/chkconfig --add xvfb
/sbin/chkconfig xvfb on   

This post continues the exploration started in Pt.1

All packages in a project, all classes in a package, and all methods in a class could benefit from a display where they are all on the same screen, in small separate graphs.

This technique fits a lot of data on a screen without making things crowded. It also scales quite well to larger numbers of categories.

The technique invites the user to make comparisons between categories, to identify differences and similarities, but it doesn’t compromise the significance of any individual time-series, as a single graph with multiple categories would do.

This is the small multiples technique from Edward Tufte’s Envisioning Information:

“Small multiple designs, multivariate and data bountiful
answer directly by visually enforcing comparisons of changes,
of the differences among objects, of the scope of alternatives.
For a wide range of problems in data presentation,
small multiples are the best design solution.”

Many continuous integration servers that have been running for any significant period of time have accumulated a large amount of data about project health. This is especially true for projects that use code coverage and analysis tools.

However, often this data is just sitting there, in XML files on the build server, seen by no one. Seems like an awful waste of perfectly good data to me. So during this fall I’m going to be thinking about what can be done with it to make it look more interesting. Being a beginning student of information visualization, I’m going to be especially concentrating on the visual aspect of things, but I’ll bet I’m going to do some forays into statistical analysis and data mining as well.

Starting with the simplest of things: A time-series showing the trend of code coverage. What is the least chart-junky way to display this variable?

A line chart is probably the best way to visualize a time-series:

Code coverage is distinctively a variable of “volume”, and always a fraction of some maximum volume (100%), so it might benefit from being displayed as such, by coloring the “filled” area:

The filled area of coverage is usually considered good, and the uncovered area as bad, so maybe the negative quality of the negative space could be highlighted by coloring it red?

The colored areas now outline the data, so the original line representing the graph becomes redundant. This means it must go. Let’s get rid of the bounding box too. Now we can also increase the value of the fill colors as they become the primary (only) element of the graph:

That’s better. However, although right now the graph shows the general trend pretty well, it isn’t very easy to make out what the actual coverage value is at any given time. Maybe this can be helped by introducing a horizontal grid line at every 20% interval?

It does help, but the grid is way too heavy. It actually takes over as the primary graphic element. That can’t be good. I don’t like things that are too heavy for their purpose. We’ll make the grid as thin as possible, and make it white so it fades to the background:

There. It is now easy to see the grid but it doesn’t get in your face.

I haven’t thought about the temporal scale here at all, nor the different granularities of code coverage that we could examine (project / package / class / method / block / line -level). That is what I’ll look at next.

As part of a Wicket-Spring-Hibernate vs. Rails evaluation we’re doing, I’ve been thinking of a set of best practices we could employ if we were to go for the Rails solution.

Most of these would be of course relevant for Java as well as Rails. However, being familiar with the realities of most software projects I know some of these things are the first out the door when scheduling pressures kick in. I think the considerable productivity gain we would get from employing Rails should give us an opportunity to really concentrate on improving the quality of both the software and the process.

So, here’s what I have in mind: Behaviour-driven development, automated acceptance tests, continuous integration, code reviews, shared ownership, automated deployment, enhacing communication with a wiki, a chat solution and daily meetings, and last but not least, reflecting on how we’re doing with agile retrospectives.

Behaviour-Driven Development

We should use the wonderful rSpec library to do behaviour-driven development. BDD brings real rigor to the coding process by making us always specify the code we write before we write it.

BDD is the next natural step from test-driven development, and improves it by replacing the vocabulary of testing with that of specifying. rSpec is becoming quite mature at this point and can pretty much fully replace Test::Unit in a Rails project.

We’ll want to use rCov to keep track of code coverage. We could decide to make some level of coverage an acceptance criterion for an iteration, but once we fully embrace BDD we won’t need to do that. At that point coverage reporting becomes a tool for the developers to use to find those little nooks of code that might have slipped in untested (or unspecified).

Automated Acceptance Tests

The acceptance criteria of each iteration should include automated acceptance tests of all implemented features. We can employ Selenium to do them, and they should be done by the developers, together with the system tester and the customer representative. They could be defined and stored in a system like Fitnesse, or just in the version control system with the code.

Automating acceptance makes it provable that the agreed-upon features were actually implemented. They also define a powerful regression test harness, as acceptance tests from previous iterations can be run any number of times without additional cost. Using Selenium also has the added benefit that the tests double as a cross-browser sanity check.

It is notable that automating acceptance tests does not replace the need for a separate system testing / QA process. What it does do is free up the system tester’s time from hunting down coding errors to doing exploratory testing and finding the really hard problems caused by integration issues or miscommunication between developers and customers.

Continuous Integration

We should setup a continuous integration server, such as CruiseControl.rb, which runs all our specs on each commit. It should also run our in-browser acceptance tests.

The CI machine can also be used for automating deployment to development / testing servers, so that they automatically get new versions of the software when its committed into version control and all automated tests pass.

Code Reviews

All code changes should be reviewed by other developers before they get committed to version control. We can do this in a controlled & automated fashion by using Review Board or a similar solution.

Code reviews not only provide a proven reduction to defect rate, but also enhance communication by keeping everyone up-to-date on what’s going on in different parts of the software.

Shared Ownership

There should be no “my code” or “your code”. All code is owned by the team. We can support this by rotating the responsibility areas for each iteration: The developer who was working on feature A in iteration 1 will work on feature B in iteration 2.

This prevents silos from forming, and helps everyone to understand all parts of the software and how they fit together.

Another thing which happens with rotating responsibilities is that developers will want to produce cleaner code. This is because they know the code will absolutely have to be understood and continued by someone else in the near future.

Automated Deployment

This is pretty much a no-brainer for a Rails project, but I feel it needs to be said as this still often doesn’t happen in Java projects.

Deployment to development, testing and production servers should be automated so that it can be done easily by any developer, any number of times.

The whole process of deploying the application, which includes updating the code, updating the database schema and data and restarting all server processes should be reduced to a single command.

In a Rails project, we can of course employ Capistrano to achieve this.

Wiki

An active wiki should be maintained. It can include any kind of information which could be of interested to developers. Here are a few examples:

• News and announcements
• Scheduling issues, upcoming deadlines and milestones
• Project metrics (open defects, code coverage, server status)
• Server infrastructure information. IPs, directories, server software
• Development environment setup instructions
• Contact information for developers, customer representatives and other project personnel
• Coding conventions and standards
• Documentation of used plugins, both in-house and external
• Solutions for common problems, “knowledge base”

A rotating wiki gardener duty should be set up, so that every project member is responsible for one week at a time for keeping the wiki clean, consistent, relevant and up-to-date.

Chat

The team will be distributed, so we need some kind of group IM solution. We could setup an IRC room or some web-based solution.

It should be encouraged that everyone is present in the chat whenever they are working on the project, as this will probably be the closest thing we get to a shared agile workspace.

Daily Meeting

A daily 15-minute meeting, such as a daily scrum should be held consistently. This meeting should be face-to-face when possible, and over the phone when not.

Agile Retrospectives

In each iteration, we should spend some time reflecting on how these practices are working and what should be added, dropped or improved.

We should also do some “code strategizing”, like looking for emerging patterns in the code base which could be abstracted into reusable components. We should do this consistently in each iteration.

IEEE Computing has a very nice article up about Seaside, a web framework I think I’m falling in love with (in an extraordinarily geeky way).