Category: Miscellaneous

This is probably a “duh” tip, but here goes: don’t put heavy loading code in ~/.zshenv because this code will be processed in every system call inside another program like Vim, making the program seem slow.

Like every single programmer I maintain a repo of my dotfiles that I constantly tinker with. At some point I was reorganizing my ~/.zshrc and I moved some things into ~/.zshenv according to my (weak) understanding of how these things should be separated, mainly based on the advice of this Stack Overflow page.

So I gathered that you should put important environment variables there, but as you can see I also decided that this is where you should put the initialization code for rbenv, direnv, etc.

Don’t do this. I thought that Vim (actually I use Neovim these days) had become horribly slow and was inclined to blame this on individual plugins or just Vimscript in general. As soon as I moved the offending code out of ~/.zshenv into ~/.zshrc my Vim sped up dramatically.

I started playing around with a new Raspberry Pi 2 that arrived yesterday. I had used a Beaglebone before (always connected to ethernet) so I knew what to expect in terms of memory and CPU limitations. What surprised me was how flaky ssh connections were when connected over wifi using this USB wifi dongle (an Ourlink RTL8188CUS/RTL8192cu chipset) from Adafruit. I could connect for a second and then if I paused for even a moment the connection would drop and I would get  a “Host is down” response if I tried to reconnect. Usually I would need to power cycle the Pi to be able to ssh in again.

Googling for similar issues I found the following advice:

• Some 5V power sources actually deliver less than 5 volts. Also some chargers don’t deliver enough current (A) to supply both the Raspberry Pi and the wifi dongle. To guarantee that this wasn’t the issue I added a powered USB hub to run the wifi dongle. This didn’t solve the issue.
• You can enable an ssh option to send a “null packet” every X seconds. You can set this on the server-side or on the client-side. On the server in /etc/ssh/sshd_config:

  ClientAliveInterval 60

  On the client in ~/.ssh/config:

  ServerAliveInterval 60

  This helped out considerably. This made sense since I could stay connected by just running ping in the ssh session or typing ls constantly. I would still lose connection after a while and would have to wait for something in the Pi to reset.

• The real solution (and the point of this post) is suggested here. Apparently the wifi dongle has a power conservation mode that is causing it to disconnect from wifi. In hindsight, this is kind of obvious (I could see the Pi disconnecting from the router) but it took me forever to find this tip. Anyway this fixed everything:

  echo "options 8192cu rtw_power_mgnt=0 rtw_enusbss=0" | sudo tee --append /etc/modprobe.d/8192cu.conf

Hopefully this will save someone else some time.

http://www.amazon.com/Its-Complicated-Social-Lives-Networked/dp/0300166311

(This book is actually available for free download here: http://www.danah.org/itscomplicated/, though it would be good to support her work if you like it.)

The remarkable thing about It’s Complicated is that danah boyd actually talks to teenagers for her findings. As she describes the different popular attitudes and beliefs about teens and social media it’s striking how little of it is actually based on sound data, and how much of it is based on the selling of fear by news media, barely concealed inter-generational prejudice and sheer intellectual laziness.

In one telling story, boyd (like bell hooks, she doesn’t capitalize her name) talks about a girl who killed her mother who had also been active on Myspace and describes how the media translated this event into “Girl with Myspace kills mother”. boyd identifies this as a common theme: stories that would otherwise be about broken homes or social disfunction become stories about social media, with the implication that social media creates the pathology. She argues that technology is such a locus for our hopes and anxieties that the realities of how technology is actually used by teenagers becomes distorted, resulting in bad public policy that often causes real harm.

For her own research she simply sits down with a wide array of kids and asks them questions about how and why they use social media. She uses a qualitative, ethnographic method, meaning that there’s no attempt to statistically verify the universality of her findings with surveys containing standardized questions and answers. Instead she identifies common themes from hundreds of interviews conducted over the last decade. This style of research strikes me as a good way to open up a field of social research, because it starts from reported phenomena rather than from aggregated data that already embeds assumptions and is subject to multiple interpretations. Many of her findings run directly counter to conventional wisdom, and others seem completely overlooked by popular media.

One common finding is that many kids either have little unstructured social time, because of over-programming by parents, or their parents don’t allow them to leave the house or meet with friends because of safety fears.  Social media becomes more important to teenagers as a result (the teens keep telling boyd that they would always rather hang out with their friends in person). Another finding is that teenagers use the different social networks in different ways (just like adults do) and struggle to maintain their privacy in the face of confusing settings and social circle boundary collapses (just like adults do). She talks about teens who are exasperated with parents who jump into Facebook conversations that are clearly not intended for them. She also talks about teens who employ clever tricks to avoid “drama” stemming from social networks, like deleting all comments on their wall every day (“whitewalling”) and a teen who temporarily suspends her account every day instead of logging out.

A more general theme is the conflict between parents’ concerns about teenagers and teenagers’ own perceived interests. Adults are concerned with ensuring that teenagers are doing their homework, not getting involved with bad kids, and keeping their digital records clean for future employers. Teenagers on the other hand are interested in entering into public life wherever it can be found. Since other kinds of ‘publics’ are withheld from teenagers, even to the extent that many teenagers are prevented from gathering,  ‘networked publics’ are elevated in importance for teenagers, and they are willing to make more trade-offs in terms of privacy or potentially negative representations.

What adults see as irresponsible or even “obsessive” interest in social media is for boyd a rational response to the developmental stage of being a teenager given existing social conditions. She attributes the special anxiety that parents have towards the Internet and social media to the fact that it allows teenagers to enter into various ‘publics’. boyd argues that teenagers need to be able to step out and operate in these publics in order to do their ‘identity work’, to develop into social adults. The conflict between teenagers and adults is thus a disagreement about how valuable that online social engagement is. To teenagers it feels very important but adults tend to discount it, often without compassion.

Another theme that runs throughout the book is the idea that technology by itself generally does not create social problems, nor does it offer solutions on its own. In one chapter boyd looks at the fears about sexual predators on the Internet. She finds that the risk is extremely low for teenagers overall, but that the teenagers who do get involved with adults through the Internet tend to come from troubled households and engage in risky behaviors in real life as well. Likewise, in a chapter on whether teenagers are “digital natives”, boyd points out what should be obvious: like other forms of literacy technological literacy tracks with income and social class. Similarly social media doesn’t necessarily promote equality or erase racism, but largely reproduces existing social networks and attitudes. In a chapter on online bullying, she allows that technological ‘affordances’ can help spread harassing messages farther and wider, but she reports that her informants claim that bullying is not a big issue for them (instead they talk about “drama”, which doesn’t involve a power differential). Her message is that while technology can amplify or alter behaviors online, it does not necessarily create the behaviors or the underlying non-technological conditions behind them.

The book is written in an accessible style with a minimum of jargon that clearly enunciates its arguments and findings. These points are so counter to popular views on teenagers and social media that the exposition can be forgiven for being somewhat cautious and repetitive. boyd does a good job of not assuming any academic background on the part of the reader, and gives a clear explanation of the few theoretical constructs that she needs to make her case (she does have the annoying-to-me academic tic of referring to things as “problematic”). Over all, this is a great model for how to communicate challenging ideas to a wide audience. I would recommend this book to parents, educators, policy makers, journalists–anyone who would like to understand teenagers, rather than just demonize them.

Somebody asked me to make a list of webcomics that I subscribe to (using Feedly these days) and I started writing little descriptions next to each one. I figured I’d just place it here in case anyone else is interested. These are the webcomics that have made the cut after having tried out and abandoned many more. Here they are, in no particular order (well, the order of the tabs in Chrome at the moment). I read all of these but some I recommend more whole-heartedly than others (recommended comics have a * next to them).

• * Hark! A Vagrant — The panels require basic knowledge of literature and history, but it’s Kate Beaton’s art style that usually clinches the joke. She draws insanity and idiocy extremely well.
• * Left Handed Toons — The conceit is that the right-handed artist draws with his left hand, but he’s been doing it so long that it doesn’t seem like much of a hindrance anymore. The comic relies on brutally dumb puns and literalisms, as well as a recurring cast of characters like Fridaynosaur, Whale, and General Twobabies.
• Penny Arcade — Mainly of interest to people who play video games. Obscure references to recent video games and lots of gross-out humor.
• PhD — Only occasionally funny. This is basically Cathy for academics. The jokes are all: graduate students are overworked; dissertations are stressful; advisors are clueless.
• * Pictures for Sad Children — Grim strips that follow a depressive logic where events often take a surreal turn but nobody acts surprised. People end up inside dogs and idly discuss what to do, etc. Pretty great if you have the fortitude for this kind of thing. Not updated these days.
• * Poorly Drawn Lines — Just started reading this, but so far the gags are good, absurd but not particularly dark.
• *  Saturday Morning Breakfast Cereal — SMBC’s Zach Weiner is on par with Gary Larson and xkcd’s Randall Munroe in terms of raw creativity. He does both one-panel gags and longer multi-page stories. The comics generally have a science and science fiction bent with a solid grasp on related philosophical issues. Weiner is also a significantly better illustrator than most webcomic artists.
• Sheldon — This is more of a traditional syndicated comic, but it occasionally has some interesting storylines.
• * Subnormality — These are irregularly updated bizarrely dense comics that typically take up several screens. The comics are extremely dialogue-heavy, to the point where I frequently skip them not because I dislike the stories but simply because I don’t have the time to read them all. The stories typically take the form of externalized inner dialogues about insecurity, projection, prejudgment, etc.
• * Gutters — One-off comics about the comic book industry by comic book artists.
• The Trenches — Episodic strip about game testers.
• * Wondermark — Hilarious comic assembled from old illustrations to create absurd hybrid 19th-and 21st-century jokes. Has an alt text joke.
• * xkcd — Should need no introduction. Alt text joke.
• * Girls with Slingshots — A well-drawn sitcom about two girls who do polyamory. Sexy but not explicit.
• * Cyanide & Happiness — Incredibly crass jokes that could be fairly criticized as promoting all kinds of bad culture, but I would be lying if I said I didn’t find many of them to be amusing.
• * Dinosaur Comics — Dinosaur Comics is what it is: goofy (secretly rather intelligent) rambling about language and culture overlaid on an invariant set of six panels.
• * Dilbert — Just because Dilbert cartoons are a cubicle cliche doesn’t mean that they don’t generally speak a certain truth. It’s the same stuff over and over about pointy haired bosses and lazy coworkers, but the punchline is usually pretty fresh and often surprisingly edgy.
• Diesel Sweeties — People seem to love this comic. It’s sufficiently interesting but doesn’t blow me away. It’s mainly jokes about killer robots and coffee.
• * Crocodile in water tiger on land — Commentary about Indian society, delivered in a self-satirizing manner by a cast of Indian archetypes that I have to partially construct from context (e.g., the hipster, the religious zealot, the business fat cat, etc.) I don’t totally follow the issues being discussed, but it gives me some insight into Indian society and provides a valuable example of cultural self-criticism.
• * Cat and Girl — I can’t say that Cat and Girl is usually or even often laugh out loud funny. In fact I can’t say that I generally 100% understand Dorothy’s comics. The strips tend to reward taking time to do an analysis of the words and symbolism to derive something like a thesis statement. The thesis statement is often about the nature of authenticity as an ineffable criterion for value in the context of postindustrial society and the age of digital reproduction and social networks. This will certainly not be everyone’s cup of tea, but it definitely is mine.
• * Blaster Nation — This is another geeky narrative sitcom. Digging the story so far.
• * Bad Machinery — Scooby-doo-style mystery stories set in England. The fun though is in the hilarious banter between the kids.
• * Abstruse Goose — Similar to xkcd, jokes about being geeky with a focus on math and science.
• * A Softer World — Three-image strips with some text that is generally a funny-sad statement about love and loss.
• * Hijinks Ensue — Violent-gross jokes about geek dude culture.
• * Scenes from a Multiverse — Strips rotate through several universes. The most popular ones get to come back.
• * Perry Bible Fellowship — Wonderfully evil, beautifully drawn comic. Every punchline is designed to disturb you. Not updated these days.
• * Achewood — I’m not going to bother describing this comic. It’s about some dog people and the writer Chris Onsted has a wonderful ear for spoken English. Sadly not updated for more than a year.

My new work is great¹. The main thing I like about it is the consummate professionalism of the team. Everyone I work with is interested in improving their craft and is eager to engage in discussions about software principles, code quality, development processes and tools. In general there is a noticeable group ethos that seems guided by the following set of principles:

Take the time to make your work as high-quality as possible given the scope of the task at hand. This means writing tests and undertaking refactorings to manage complexity in the normal course of development. It also means often having to partially or fully revisit a design based on new findings that come out during development. This may seem like a recipe for low productivity but our team is pretty consistent in its output: to use a decidedly fake and wobbly measurement, each team member seems capable of producing about two significant user-facing features per week. I know from personal experience that the alternative, programming to hard deadlines and arbitrary deployment cycles², may at times produce the superficial appearance of a greater amount of output (“With Monday’s release we closed ten stories and five bugs!”) but this is just a loan taken out against the day when you have to devote entire “sprints” to fixing the earlier rushed implementations. Taking the requisite time with each task is consonant with the recognition that growth in complexity in a system has to be managed, either all at once in a great “redesign” crusade, or in small thoughtful efforts as you go.

Even sufficiently good work can be improved dramatically through constructive criticism and iterative development. This was something I’ve had considerable trouble with at times, as a person who avoids conflict and criticism at all cost. The key to being able to accept the criticism (which normally comes in the form of code reviews on Github), I’ve found, is to focus on the improvement to the final product brought about by incorporating the criticism. During each round of code review feedback instead of fighting the suggestions I try to let go of my ego (not at all easy) and visualize how the code will look after I implement the changes; I’m generally much happier with the final code than I am with the initial submission. I also try to approach criticism as containing information about what I should do and what I should avoid in the future, so that even when I am receiving brutal criticism about the quality of my code I receive some comfort from the fact that I am learning how to avoid similar criticism in the future³.

There’s more than one way to do it, but you should be able to articulate the reason for why you’re doing something a certain way, even if the articulation of that reason is “because that’s the way I learned it initially and there’s no compelling reason to change”. This of course opens you up to the possibility that somebody else has a positive argument for a certain practice, in which case it’s hard to argue for the original practice purely on the basis of apathy. Often the process of asking oneself why one prefers one practice to another ends up extracting motivations and values that are more interesting than the actual issue of practice in question. As a team we discuss many issues great and small, from high-level questions about design patterns and object composition to nitty-gritty questions about code block indentation. Sometimes these discussions result in some binding decision regarding style or best practice, but on other occasions we’ve articulated dueling reasons and concluded that the arguments for both are strong enough that both practices or styles are valid for different contexts.

Work to improve the product and support your teammates. I know this one sounds like a cheerlead-y cliché, but all I mean by this is that the primary motivator for working hard is to make the application and its codebase better, both because these support one’s self-interest of having the company succeed and remaining employed, but also because you see your teammates working hard and want to make a similar contribution. The codebase and app are a communal creation and as one works with it one begins to feel a sense of loyalty to the whole, as well as a sense of pride for the sections of code that you’ve played a major role in shaping. This is worth mentioning mainly because it stands in contrast to other motivational systems, like those that depend on fear of punitive action or explicit intra-team competition. There are still elements of fear and competition at work in our system, but they are sublimated into cooperative and high-productivity behaviors⁴.

This ethos doesn’t come from nowhere. It is the product of specific values that are held and promoted by my boss, and it is sustained through a combination of the personalities of the people he chose to hire and the practices (often enforced/encouraged by technological tools) he put in place. It is an impressive accomplishment that is easier to describe than it would be to replicate.

Anyway, it’s a pretty cool job.

---

1. New as in I’ve been there for ~6 months [back]
2. These deadlines and cycles often end up being Procrustean beds for feature requirements.[back]
3. Did I mention that I don’t like criticism?[back]
4. That is, people compete to be the most helpful![back]

I have meant to undertake this project for a long time: the compilation of a list of “local memes” in my household. As I get older (and older and older) I become more and more aware of this condition of being composed out of bits and pieces that originated in other people. I am also aware of various recurring gags, puns, patterned exchanges etc.– memes –that gradually died out through disuse or replacement. Every once in a while my wife and I will recall some old joke that we used to do and we’ll momentarily resurrect it, like the dinosaurs in Jurassic Park. We flatter ourselves that we have an unusual number of these active or recalled memes stored up, but probably most couples have equally rich archives. Anyways, ours are special to us, and I’d like to partially preserve them by sharing them now. I’ll just update this post as I think of more.

I’ll be right Barack Obama. Pretty self-explanatory. Also, Barack to the future, etc.

Thass nice. Thass real nice. — Slurring lecher #1 in the bar scene in the terrible movie Eve of Destruction. Denotes lustful appreciation of something (in the meme, usually something innocent like food or drink).

snoring/narcolepsy — This is where you decide that the point you’re trying to make is too boring, obscure and convoluted to actually finish and you stop in mid-sentence and nod off. The use of this has decreased because it was really off-putting for my wife and she basically forbid it.

“Oh God” — this was my sort of Joey Lawrence woah during college. I also briefly tried to promote my own pre-packaged meme: embrace the chaos/channel the void.

revolution in your stomach — when you mix foods causing gastrointestinal distress. From a Salvadoran family member. Also the phrase Don’t be lazy.

“What? What did you say?” — I tried to find a relevant video clip from the Ozu movie Good Morning to demonstrate this very simple and satisfying gag, but looks like you’ll have to check out the movie yourself.

cat names — We have two cats, Mackerel/Mack and Ruby. Ruby is variously Poofy, Miss Fluffy-shanks and Rubifer Jenkins. Mackerel is usually just Mack, but his friendly, chill demeanor often conjures up declarations that Mack is a buddy and that Mack is a mackimal.

monkey dancing — A monkey dance is a disrespectful display where you show your interlocutor that you are not paying attention to what they are saying because you are no longer a rational being with language. Traditionally you literally pretend to be a monkey by putting your arms above your head and bouncing back and forth on your feet while sticking your tongue out, but any elaborate discourse-destroying dance qualifies.

hot socks — This one is based on the Lords of Acid song “Rough Sex“, where the refrain is a litany of “deep sex, hard sex”, etc. So you replace the word sex with socks and try to come up with descriptions of socks that sound dirty but still make sense in the context of socks. “wet socks, hot socks, smelly socks.”, etc. I actually can’t remember how we kept this one going long enough to be interesting, but we came up with quite a few.

“Bob” Damon — If you’re watching a movie where an actor looks like a more famous actor, you come up with a fake first name and assert that the actor is the more famous actor’s sibling struggling in obscurity.

“And it looked just like a checkerboard!” — The punchline to a ridiculous true story once told to me by a friend. When uttered (in a high-pitched, incredulous voice) it denotes the discovery of an absurd and wonderful fact.

haspiration — This is where you append h’s before all beginning vowels in words and all silent h’s, as in “That’s hannoying” and “hu-wat hare hu-you doing?”

Y’see… Rudy — apocryphal quoting from the Bill Cosby Rap, which doesn’t actually include the name Rudy. Denotes when you’re saying something self-consciously condescending.

Stompy McStomperson — This is apparently me. Related to Messy McMesserson, which is a pretty universal meme.

“_ Joe, everyone’s favorite Joe.” — e.g., Hey look it’s Self-pitying Joe, everyone’s favorite Joe. This came from my roommate in college.

Sometimes a man has to do things that don’t make any sense, nevertheless he must do them, because he is a man. — half-remembered paraphrase from the great movie Fighting Elegy.

“I look good, I smell good, I feel good … I’m a cat!” — half-remembered line from Red Dwarf. Also, “The only thing that can kill a vindaloo: a lager.” Also, from The IT Crowd: “You’re making it go back in!”

deathwork — Term from an eccentric book by the cranky sociologist Phillip Rieff, which he uses to describe everything from Piss Christ to Ulysses to this image of a person made out of vegetables. A way to flippantly dismiss something. Related to the phrase The death of meaning.

You’re probably going to die. Used by a friend a lot, the joke being that instead of trying to reassure someone that their neurotic fears aren’t real, you just agree with them that they’re probably right in their catastrophic estimates. This friend also says Happy family, happy family whenever there’s slight social conflict, which is probably from something. Also, the whole concept of icecream cake being inherently more desirable than regular cake, which is apparently from Modern Family.

basic portalology — Recent meme from playing through Portal 2 with same friend, as in That’s basic portalology!, exclaimed when you realize you’ve been overthinking a level.

I think there was something wrong with the beer. The joke being that the beer being skunk is what made you sick, which is why you should always drink out of heinecans.

It’s important. — Said of things that aren’t important. See note.

an all too possible future — a reference to the offensively ridiculous Heinlein book Farnham’s Freehold, read by my friend and I and thankfully few other living people. Also with the same friend the principle that only one person can take off his shirt in a room at a time.

I’m sorry that happened to you — tepid expression of sympathy for an unfortunate event that is either extremely mild or entirely self-induced and preventable.

“Pretty. Pretty. Pretty good” — From Curb Your Enthusiasm, of course.

Uuuuuuuuuuuuumm — Open-ended contemplation sound that a friend’s five-year-old daughter would make. Also from same little girl: “Poop on your head!” And from that friend: “Wake up!”

“Train.” We live next to a railroad, so when the train comes by we translate what its warning horn is saying, which is clearly: “Train. Train. Traiiiiiin. Train.”, etc.  

Update (10/15/2012): This isn’t how I’m doing it now. See this aside for my current workflow.

(That Latour article is in a half-finished limbo state, but I’ll get around to posting it eventually).

I wrote in a recent post about how easy it is to configure Autotest these days. And Autotest has been an essential part of my toolset as I’ve developed my humble todo app, Method Todo. I’ve only been using it to run my Rspec stories (and not Cucumber features, since they take too long). Now that I’m adding another testing discipline, testing javascript code with Jasmine, I find that there’s an even simpler way to run all your tests — specs, features and Jasmine specs — continuously and in the background.

I decided to use Guard because I couldn’t get Jasmine to access the necessary asset pipeline files to run Javascript tests, I guess because those files needed to be precompiled. Once I started using guard-rails-assets I decided to try out the other plugins for Rails, Rspec and Cucumber. It seems to all just work and the ecosystem of plugins seems like it will provide quick solutions to obscure problems down the road.

So after deleting the Autotest dependencies out of my Gemfile, I have:

# other sections for rails, rspec, spork, etc., etc. 
 
group :guard do                                                           
  gem 'guard'                                                                   
  gem 'guard-rails'                                                             
  gem 'guard-spork'                                                             
  gem 'guard-rspec'                                                             
  gem 'guard-cucumber'                                                          
  gem 'guard-rails-assets'                                                      
  gem 'guard-jasmine-headless-webkit'                                           
end

Then I run

bundle exec guard init

to create the Guardfile with sensible defaults.

Then running

bundle exec guard

will start running all of these tasks together. The default for the Cucumber guard task seems to only watch changes in feature files before re-running Cucumber, so I’ll leave this guard in as long as it doesn’t delay the re-running of specs. A bonus is that the Rails guard starts up the development server and restarts it when you change major configuration files.

Update (7/25/2012):

I found that guard-rails-assets didn’t seem to be necessary for jquery-guard-headless-webkit to process assets. I removed it to see if it would fix a strange issue with the bootstrap-modal library that only occurs in development mode (it didn’t, but it also didn’t seem to break anything).

I also found that guard-rails was loading into the test environment when paired up with the other testing guard tasks. Changing the initial generated line to

guard 'rails', :environment => 'development' do                                 
  watch('Gemfile.lock')                                                         
  watch(%r{^(config|lib)/.*})                                                   
end

seemed to fix things.

Update: I’ve moved on to using Guard

Of the posts I’ve written this article about Rspec, Autotest, etc. has been one of the more visited. Time to update that ooold information.

If you don’t know what any of this is, the idea of Autotest is to get a test suite to run continuously in the background and provide ambient notifications about the failure/success status whenever a file is saved. You get feedback as soon as you break your test suite. The Linux part of this post involves getting Linux to pop up an on-screen display listing number of failed tests.

Cucumber is a BDD (Behavior-Driven Development) tool where you write out the features in plain language but then parse that natural language with regexps to pin tests behind it (called step definitions).

Rspec is a nice expressive test assertion library that can be used both in Cucumber feature step definitions and for traditional unit tests.

The process is much faster and cleaner now due to better gems and the convenience of Bundler. I’ll update with details about non-Rails projects.

The Gemfile section (note autotest-standalone and autotest-notification:

group :test do
  gem 'rspec'
  gem 'rspec-rails'
  gem 'cucumber'
  gem 'cucumber-rails'
  gem 'database_cleaner'
  gem 'autotest-standalone'
  gem 'autotest-rails'
  gem 'autotest-notification'
end

Setup commands:

# install the gems of course
bundle install
# steps for Rails
rake generate rspec:install
rake generate cucumber:install
# complained if I didn't do this
rake db:generate
# Do some magic for the notifications plugin
an-install

Then to run the tests:

export AUTOFEATURE=true; autotest

It’s working for me on Ubuntu 12.04.