Hot on the heels of Sublime Text 2.0's release, there's the official release for Chocolat 1.0, another new code editor (this time, and unlike Sublime Text, for OS X only).

I've given it a quick spin, and its first impression is pretty great; most of the features you'd expect are there, plus a really cool symbol browser and web preview for Markdown documents et al.

I was very close to describing Chocolat as “like Sublime, but with added sanity”, until I noticed two things that bugged me, and I'm hoping will be improved in future versions:

• Chocolat, like TextMate and Sublime, has a useful “Go To File” feature that allows you to jump to any file in your project quickly using fuzzy search. However, Chocolat's implementation shares a problem with TextMate's (and which has been fixed superbly in Sublime): the fuzzy search only applies to actual file names, not the paths preceding them. This makes this feature a bit cumbersome in projects that have many files of the same name (eg. most Rails projects, where you have lots of index.html.erb files). Update: I was wrong! Chocolat's “Go To File” supports searching in subdirectories just fine – you just need to separate the directory part from the path part with slashes. For example, a search query for sp/us will find spec/user_spec.rb, but not app/models/user.rb. Hooray!
• Sublime has a fantastic “Command Palette” that works just like “Go To File”, except instead of jumping to specific files, you select editor commands (including those provided by plugins). Chocolat's way of allowing the user to interface with plugins matches that of TextMate, so it feels a bit stale.

Well, you can see that the issues listed above are really just nitpicks rather than major problems. Chocolat 1.0 is an impressive first release, and I'm already looking forward to seeing what's coming next.

I've just tagged version 0.3.0 of rbfu, my light-weight alternative to RVM and rbenv (ie., it's a tool that helps you switch between different versions of Ruby). If you're on Homebrew, I'm now providing a formula for easy installation:

brew install http://git.io/rbfu

If you're not on Homebrew, manual installation is still pretty simple.

This version adds support for .ruby-version files (also supported by RVM, with rbenv support pending at time of writing) and improved bash and zsh compatibility.

A quote from the recently updated README:

Rationale

Most Ruby developers like to keep different self-compiled versions of Ruby on their systems so they can switch back and forth between them depending on the project they're working on. Most of them use RVM to do this; others prefer rbenv. Both are great tools, but do a little bit too much for my taste.

See, the thing is: switching Ruby versions is actually a trivial operation, since it merely involves modifying a couple of environment variables (PATH, GEM_HOME and GEM_PATH). Both RVM and rbenv go through a lot of hassle in order to eventually perform this very simple operation.

rbfu is trying to keep things simple; it's a small shell script that doesn't do much else beyond changing the variables mentioned above.

I believe that software should be small and focused. rbfu doesn't come with support for gemsets (a feature I personally disagree with), nor will it compile Ruby for you (it's easy enough with ruby-build).

It just does one thing, and I think it does it really well.

If this appeals to you, please give rbfu a spin.

rbfu is pretty much complete, and I'm aiming to get a 1.0.0 out of the door some time this week or the next.

Sublime Text 2.0 has reached its first official release, much to everyone's (or at least my own) surprise. I'm very much in love with that editor, but it doesn't yet feel as polished as it should, for a final release. I guess if it helps Jon drive sales and ensures continued development, it's a good thing.

Kenneth has a good overview of what makes Sublime Text 2 so great, along with some helpful first-time setup advice and configuration examples.

Yo, peeps. I'm getting married tomorrow, so I really wanted to ship just in case I disappear forever or something. So I proudly give to you today: Happy, the happy web application toolkit, in its glorious 0.1.0 version. Hooray!

gem install happy

It works, I'm using it (on hamburg.io), it's awesome, and now you can use it too. The documentation is half-way done, but there should be enough material for you to get started. Most significantly, there now is the Happy Book of Happy, a nice chapter-by-chapter introduction in how to build web applications using Happy.

(If you want to dig further, I recommend looking at the example application and/or the source code for hamburg.io.)

Expect a whole bunch more blog updates about Happy in the near future (including some extensive discussion of its architecture and, of course, motivation), but before all that, I need to go back to being really freakin' nervous about tomorrow. Waaagh!

You know what makes ninjas so special? They don't go on all-out killing-sprees. They sit in the dark, waiting, possibly for a very long time, for just the right moment to strike. And when they do, they do it swiftly, efficiently, lethally.

(Well, at least that is how I imagine ninjas operate. I don't know any personally.)

Companies are right in wanting software development ninjas. A great developer doesn't just write good (or lots of) code, he does it diligently, analyzing the problem long enough to solve it in one swift stroke, just like a ninja assassin would terminate his target. That sounds like something an employer would want, right?

However, most companies actually asking for development ninjas in their job postings don't really understand this. To them, a “development ninja” is someone who's simply “really good”, without understand what being a really good developer actually means.

Being a really good developer doesn't mean just throwing code at the problem and seeing what sticks. A lot of times it actually means just sitting there, thinking, analyzing, bouncing ideas of your workmates, maybe even just spacing out to get your mind in just the right spot.

Which, in a lot of companies, will quickly get you into a little one-on-one with your manager. “I've noticed that you spend a lot of time not actually writing code. What's wrong?”

Don't ask for development ninjas in your job postings unless you're willing to find out what it really means. When you do, go hire those ninjas, let them attend to their trade, and reap the rewards.

If you're using rbfu (the light-weight, decidedly focused alternative to RVM or rbenv), use the following one-liner to run your project's tests against all installed versions of Ruby:

for ruby in $HOME/.rbfu/rubies/*; do rbfu @${ruby##*/} bundle && bundle exec rake ; done

Very useful if you're developing a gem and don't want to rely on the lovely TravisCI for testing against those pesky other versions of Ruby you rarely use. And since the rbfu command doesn't actually export any variables, you can happily use this inside other scripts without worrying about messing up your current environment.

Have you read the 501 Developer Manifesto? No? Well, go read it, then come back here, because I'm about to go on a rant about how much I hate it.

Do I hate it because I disagree with it? No. Well, mostly not, but more on that in a bit. Do I hate it because I'm the kind of developer the author takes issue with? Well, I certainly hope not.

I hate it because I actually agree with most of everything it says, while at the same time it does an amazing job at discrediting itself.

The manifesto's core statements – listed in somewhat larger type on the website – I agree with. 100%. Not only are they important things to say; it is also important that they have been written down, published, and are now being dissected and discussed by the general developer populace. Agree with them or not, they will have some kind of impact to a bunch of people, and that's a good thing.

However, after listing said core statements, the author feels the need to fire some flak at people who, in his opinions, are doing things wrong. The list contains weird little ideas like “pushing to GitHub while on the toilet” alongside “contributing to open source projects” and “attending user groups in my spare time”. I have never pushed code to GitHub from the toilet, but I do contribute to open source projects and attend the occasional user group meet-up. I have no idea how the author thinks that all these things move on the same level.

The author claims to respect, and at the same time pity, these developers, something that he has later tried to put into perspective on the 501 Manifesto Blog, where he not only fails to understand why people are taking issue with the statement, but also ends up making things even worse by stating stuff like the following:

If you’re still feeling offended by the “pity” thing – one word in a longer, and I think mostly coherent and reasonable document – it may be that you’re not quite the nerd of the popular imagination. It may be that you’re a tedious, perpetually angry alpha-male coder who gets in everyones faces and throws a tantrum when they fail to show reverence to your throbbing code boner.

What the author fails to understand is that the problem is not the word “pity”, it's the fact that he believes contributing to open source projects, attending user group meet-ups or writing technical blogs are just as stupid/bad/wrong as pushing code to GitHub from the toilet. The idea of pushing code to GitHub from the toilet is ridiculous, and if your job requires you to do it (or, worse, you do it because you think it's fun), then I pity you, too.

At this point it's become really hard to defend the author, which really is a shame. The 501 Developer Manifesto could have been a great and important little piece of developer literature. But with the included snide remarks and the poor effort that is its blog, it stands as nothing more than a poorly conceived rant-fest by a developer who's probably better at writing code than at getting his point across.

The Manifesto also includes a link to Programmers Being Dicks, a Tumblelog collecting instances of, well, programmers being dicks. I take issue with efforts like that. Yes, our industry has dicks, sexists, idiots (and the occasional decent person making a bad call). But for every one of those, there are a hundred perfectly cool people who just get on with their jobs and don't feel the constant need to rant, belittle or patronize. Those are the real 501 Developers, and they don't even have a website.