Pretty docs for rubygems

Tip I got through my colleague Bart Duchesne:
to have nicer templates for the rubygem documentation, you can use templates.
Mislav’s Hanna templates are pretty decent (way better than the default ones anyway) – there are other options if you look around.

Howto (updated from this site):

1. gem install hanna
2. follow the instructions given here – best to put following line in your .gemrc
   rdoc: --inline-source --line-numbers --format=html --template=hanna
3. to regenerate all rdoc
   sudo gem rdoc --all --no-ri
4. install the sinatra-rubygems (after having installed sinatra – gem install sinatra – if you haven’t got it already)
   git clone git://github.com/jseifer/sinatra-rubygems.git
   It’s a web application (duh) so keep this in mind in choosing where you want to clone it
5. point your apache+passenger (replace by suitable web server) to
   directory/sinatra-rubygems/public
   (and give it its own port, of course)
6. bookmark the link in the toolbar of your favourite browser
7. Update: rather than using apache and sinatra, you could also install bdoc
   sudo gem install bdoc
   – no extra web servers needed ! and build the necessary index typing
   bdoc
   this will start up the index in the default browser, and the UI is even nicer
   (thanks to Josh Kim for the tip)
   doesn’t seem to work under ubuntu, I’ll see if I can fix it

You can add a cherry on top by also doing the same for your ruby, by fooling your system into thinking it’s also a gem.

They say laziness is a virtue in programmers: voila, you have your ruby documentation just a click away, and offline too.

Learning iPhone development

This summer I’ve had the mixed pleasure to get acquainted with the iPhone development platform. I have an iPhone, I enjoy using it, it seemed like the logical next step. I’ll share some tips so that if you feel like diving into it, you’ll know where to start, and also what you’re getting into.

• some preliminary objective-C knowledge is useful. The Apple doc gets you up to speed. Objective-C is an object-oriented language, and if you’ve done a strongly typed OO language like Java it shouldn’t be too hard. Some attention should be paid to memory management – if you’ve got some C in your past, that helps.
• Then, get a book. The Apple documentation is boring, it’s a reference, but not a tutorial. I used “Beginning iPhone Development” from Apress. This is pretty good: very hands-on, every concept is illustrated with a small project, so you can test yourself.
• Just so you know, you need to install Xcode to develop for iPhone, in other words, you need a mac. Really ? Really. The development tools are quite good, but there’s no way around the Apple universe.
• Plan for your first real project as soon as possible. You’ll need a decent app in your portfolio if you want to start developing commercially anyway. It’s the best way to learn.
• If you want to release your application to the AppStore, you need to subscribe to the iPhone Developer Program, which, the last time I looked, cost $99. Wait, scrap that, if you want to install your app onto your own iPhone you paid for yourself with your own hard-won money, you need to subscribe to the Developer Program. The iPhone will only admit executables which have been signed by Apple with what’s called a ‘provisioning profile’. That’s to keep people from circumventing the AppStore.
  Also, the best code samples, download and docs are only available to people who are registered.
• Be aware of the rules and regulations (PDF). Apple reserves the right to reject your application.

Don’t get me wrong, it’s relatively fun to develop for an iPhone. But it’s vendor lock-in raised to a whole new level. </rant> Unless there’s suddenly an enormous demand for iPhone applications, I’m not sure I’ll be pushing that part of my skills (after I finish developing my current application, to which I agreed). We’ll see.

The Real-Time web

Like all of the over-connected, I’ve been intrigued by the hype around the so-called realtime web, so i’ve been looking around and reading up. Today, I had an opportunity to bring it all together in a short presentation.

The main points I was trying to make:

1. nothing new under the sun, technologically: HTTP callbacks, and then ajax and js push for the webby stuff
2. taking a step back, and having a nuanced view, is as always a good idea

The structure is partly inspired by Jeff Lindsay’s talk about webhooks at Pivotal Labs. I gave 2 demo’s. The first is the one described by Ilya Grigorik in his post about pubsubhubbub, where I used the watercoolr site itself and postbin. The second was an illustration about how the magic of Google Wave can be reproduced using ajax and juggernaut (though I’m sure their solution has more complexity, since they have a much, much higher load).

The last image (the house) is to talk about a nice example of the real-time web (internet of things, yay): the Pachube application now has triggers. Pachube acts as a hub for sensor information: so that means you can put triggers on your sensor data. As in ‘my house is colder than 10 degrees, notify me’.

The real-time web

View more presentations from ehuard.

Service announcement: I’m going to move this blog to another hosting very soon, under a new domain name (jabberwocky.eu). Well, I’ll post here to say it, anyway.

I survived a Rails Rumble

“Why do I do these things to myself ?” is a question that came to mind this weekend, during the Rails Rumble. The principle of the weekend is simple: you develop an app in 48 hours, from midnight GMT on friday to midnight GMT on sunday.

Hendrik, Yoni and I came together at the office i share to have a go (Tom helped us for a few hours). Hendrik did the front-end integration, Yoni the design and CSS, Tom is a Rails developer. We’d brainstormed beforehand and came up with a nice and simple concept: Same Same, an application that allows you to create before-after stories with pictures. Loads of potential for storytelling (before-after haircut, after 1 beer, 2 beers, 3 beers, before-after food fight, the stages of pregnancy) .

Well, it took caffeine, chocolate, pizza, blood, sweat and tears, but we made it, goddammit.

Lessons learned:

• I do my best refactoring in my sleep, or in the shower. None of which were available in any great quantities during the weekend
• Simple is better: in this case, adding more functionality made the application more difficult to understand. We probably should throw out the voting mechanism, and add a big and obvious ‘next’ button.
• Lots of little technical things, like Rails templates I hadn’t used before, jQuery live validation, uploadify, …

What I’d do differently, if i did it again:

• more than 1 (full-time) developer is necessary. You need a pair, or at least someone to do sanity checks – by hour 25 you’re starting to lose your edge.
• Tests: i threw out testing thinking I’d gain time, but I didn’t – test sets immediately show breakages, and these occur even in the most sane situations, which this wasn’t.
• sleep more, like 6 hours in the middle – i slept 3. What you lose in time, you gain in focus. When i woke up on monday, i knew how to solve the app’s most obvious bugs in about 3 code lines … frustrating 🙂 No patching is allowed after the 48 hours …

I liked working with Hendrik and Yoni, and I think we made a good team, overall. We should have recorded our conversations from hour 45, it got fairly surreal. It was a good experience, one that, I think, made me a better developer. I’m intending to pick up Same Same later, rework it a little bit and put it online in a proper manner.

Rails Bugmash: sweet

Better late than never: if you’re into Rails, but have never had the time to get involved in Rails Core, do participate to the next Bugmash !

Not only was it very instructive, it was also lots of fun, like resolving chinese puzzles in group, and against a clock. The core team members on the IRC channel (#railsbridge on Freenode) made sure you could got an answer to every question. Thanks again to the folks of Railsbridge for organizing the whole thing.

The core team people had singled out a pool of bugs that needed cleaning up or looked at, and had tagged them so they could be retrieved easily. Patches, comments, test sets, all got different types of points. Everyone was pleasantly surprised with the number of bugs processed during the weekend.

I didn’t really see it as a contest, more as an occasion to get involved, so I had a fairly normal weekend, with a dinner party on saturday and a movie on sunday, and I bugmashed on a terrasse part of the time. Still, I was chuffed to land in the first page of results and to get a price (Lighthouse subscription for one year, nice).

So yes, much recommended … after all, don’t you want to know the internals of the platform you’re using every day, and help it evolve ? (some strange and puzzling things in there, let me tell you).

Really simple, no effort at all

Yesterday, i stumbled upon a job offer that reminded me of my corporate days. It started with: “This job is very simple and will not require lots of work”.

Recognizable vicious circle: manager comes to you, and said: “could you change this ? quickly ? I mean, it shouldn’t be a lot of work, should it ?”
The best kind then asked for an estimate in man-days. The worst kind, who were developers 20 years ago, figured this really IS easy, since they could have done it in 3 lines of Cobol on a mainframe, back in the days. I mean, how different could it be ?
(i’m not inventing this)

Often, the amendment really is quite simple. But one time out of five, depending on your system, the quick fix required has a lot of interdependencies, and a lot of complications. And you don’t always know in advance.

So my colleagues and I learned to take a defensive approach. The “This should really be simple” sentence usually was met with the Funeral Face. The Oh My God face. The You Ripped Out My Entrails face. And we over-inflated our estimates. At best, we’d have finished in time to do some refactoring and improve the build system, or other things that did not fit into our timesheet systems. At worst, it really did take that time to finish the job.

It’s a shame, really. In an ideal world, there would be honesty and understanding on both sides. I believe some companies, or some teams, manage to carry it off. Not that many though, because assuming it’s easy is beneficial for fixing Gant Charts, planning tight deadlines, and for selling projects.

In my humble opinion, the words ‘simple’ or ‘easy’ should be forbidden to non-technical analysts in this context. Just saying.

Rails Bugmash

This weekend, we have an unique opportunity to get involved (or attempt to) in the Rails core development: the Rails Bugmash, organized by RailsBridge.
The idea is to resolve as many bugs as possible on the stable version of Rails (2.3.x) – with some assistance of established Rails core members (through IRC on Freenode #railsbridge). A level of playfulness, or competition, is added by the fact that you get awarded points for bug reduction, and there’s a few small prizes. The main prize, in my opinion, is the opportunity to participate to a well-managed open source project like Rails.

You’ll find relevant information here. And what to do to have your environment ready: here. The railscast is also a good intro.

A few notes that might be useful:

• I installed a variant of Relevance’s ruby switcher. I’m using zsh myself, not bash: if this is your case, you’ll find the relevant dotfiles in the spicy-code’s repository. Good source of inspiration, but since I’m fairly happy with my configs, I just took over ruby_switcher.rb and ruby_installer.rb. Since I didn’t want to reinstall versions i already had on my machine, I changed ruby_switcher.rb to use the paths of existing installations (look at the update_path function to see what to use) and then i added the following line to my .zshrc .
  source ~/.zsh/ruby_switcher.zsh
• To run the activerecord test set, you need a few databases, and a user ‘rails’.
  create user rails;
create database activerecord_unittest;
create database activerecord_unittest2;
grant all on activerecord_unittest.* to rails@localhost;
grant all on activerecord_unittest2.* to rails@localhost;
  on postgres the grants of course are
  create user rails password 'password';
grant all on database activerecord_unittest to rails;
grant all on database activerecord_unittest2 to rails;
  Strictly speaking, you need to test on as many dbs at possible – i’ve got mysql, posgres and (duh) sqlite3 – might add the jdbc’s to that list.
  You can change configs in activerecord/test/connections/native_/connection.rb . For mysql, I had to add my :socket in there, which defaulted to something strange. For postgres, i had to add user and password (though i suppose you could grant to PUBLIC).
  If you want to just test activerecord for one type of database, you go into the activerecord directory, and do
  rake test_mysql
rake test_postgresql
  and similar. In fact, it’s adviseable to run ONLY the tests you need at first, because the test set is obviously sizeable, and takes a wee while to run (using env variable TEST=).
  Note: I must be missing a grant for postgresql, because i get a load of errors – I’ll update if i fix this Update: i ended up using the superuser.
• You also need to start memcached. 11211 is the default port.
  memcached -p 11211 -d
• especially this week-end, i’d do git pull regularly, to avoid surprises.

Interesting, anyway.

Rails Underground

I really liked Rails Underground, for several reason. First, where some Rails conferences (like last Railsconf Europe) was a bit disappointing in the levels of the presentations, here all technical presentations were relatively advanced.

Secondly, the audience came in a wide range of ages. At the hight of the Rails hype, conferences were attended by a majority of 20-year olds – which is fine, but it’s reassuring when a community contains a good percentage of software veterans, who’ve been around the block and judged that Ruby and Rails is Good Stuff.

And lastly, it was medium-scale – about 200 people. Seems to be an ideal number: there is enough weight to get some big names, and it’s still small enough to have a good atmosphere. You can approach people much more easily. Met lots of interesting people, amongst them some interesting women (!) like Desi McAdam from Devchix, Eleanor McHugh (who always does strange but interesting things with Ruby), Lena from Berlin, Allison Beckwith from Portland.

RailsUnder talk: internet of things

Rails Underground is proving to be extremely interesting – I’ll do a separate post about the talks I enjoyed later on.
Although to be honest the first day passed in a haze of nerves for me, since i was doing a talk that evening. Note to self: attempt to talk early on.

I had some expert advice beforehand from my friend Baudouin, who’s doing coaching for presentations, which I duly memorized. But of course, once i came on stage, all the good advice went out of the window. I talked too fast, I moved around, I pulled on my shirt, etc.

Well, despite all this, the subject matter seems to have interested people: a surprising number of people came to me afterwards telling me it was inspirational, and made them want to get started themselves ! So all’s well.
The video should be published later, apparently.
Update: the videos are already online ! Impressive.

Slides:

FOSDEM 2010: 6-7 of februari

Hear, hear ! We already have dates for next edition of FOSDEM, thanks to early cooperation with the ULB (and thanks to Christophe Vandeplas).

Having the dates set this early means:

• that we can already invite the bestest speakers
• that we can brainstorm about the awsum things we’re going to do for the 10th anniversary of FOSDEM (OSDEM included)
• that you, the open source developer, have no excuse to miss it, since you can write it down (right now, please) in your agenda.