Bye bye mac
For about 2 years I’ve worked on a Macbook Pro. It’s been a mostly pleasant experience – smooth graphical interface, more than adequate hardware – it took a while getting used to, but it worked out OK.
Still, I find myself turning back to Linux for development.
Mess
I’m not the most organized person in real life, but I can be fairly anal about my file organization. And I find it quite an effort to keep my Mac’s file structure clean and simple.
First, there is Apple’s own directory structure – apparently they found it necessary to differ from the BSD they’re based on, and use a list of non-standard capitalized (!) directories (Libraries, System etc – have a look at Applications for pete’s sake).
In my work I use a fair number of open source tools. The easiest way to get those on a mac is using macports. Macports installs things in /opt/local by default, so there’s a few things lying around in their own directory structure there.
The macports people do good work, but it’s difficult to keep up with releases, so often you need a newer version of a tool, or you need an extra library that hasn’t been packaged yet. So you compile. If you’re not careful, the compiled items are then installed in the usual linux directory structure (/usr, /usr/lib etc).
Result: something that works, but it can become a disorganized mess, which chafes a bit.
(and don’t get me started on Mac’s very own dynamic libraries and executables)
Tools
when I work, I’m mostly using terminals and the command line. Vi is my editor of choice (good vim rails plugins here). So all the nice graphical effects and applications requiring a mouse don’t have much added value.
Friends have introduced me to a great window manager on Linux, coincidentally called Awesome. This is a tiled window manager – which means that most windows don’t float, but are tiled, and make full use of the screen real estate. There are by default 10 desktops, allowing a good organization of windows. Navigation happens through key shortcuts. Shortcut keys, default applications, the whole interface can be customized using Lua. Now tell me that isn’t awesome.
Linux for the desktop
It used to be a pain in the neck to have Linux be completely functional, especially on laptops. I remember poring over hardware manuals looking for chipsets, and endless trawling through forums to get X to work properly. Nowadays installing an ubuntu or a debian is mostly inserting a disk and clicking through an install.
Because you see, it’s not because I can manually partition, hand-compile kernels and libraries, fiddle about with settings, that I want to spend time doing this for my desktop, per se. We’ve all got better things to do. Zack the Mac was a temporary solution to this issue.
Apple
Fourth (minor) reason to go back: well, Apple. They have the hardware, they have the software, they make me pay. It feels like being submissive to the fantastic marketing machine Steve Jobs set up.
I like the mac hardware, and Mac OS X is fine for casual use (like watching movies, email, blogging), and of course for iPhone development, so it’s not a definite parting. Might make my MBP a dual boot (I’m told boot camp makes this very easy). Let’s see how this goes !
26C3
I’m not quite sure how I ended up at 26C3, but I had a blast.
From what I gather, the Chaos Communication Congresses are gathering of geeks and utopians (or both), around security, privacy and hacking. And LEDs.
We arrived the night before the start of the conference. We were lucky to have our places in advance, because when we went to retrieve our bracelets, people were queuing up to get their places.
The location of the 26C3 (and a few previous ones) is fantastic. The Berlin Congress Center is a graceful example of 70 architecture of the 2001 welcome to the future category. It’s basically a bloc containing a cylindrical structure – the outside edges are the corridors, the inside disks are rooms. Saal1 (under the cupula) in particular is phenomenal, but the rest of the building has lots of charm too.
The principle is that groups and projects book a table (or two), and gather round that table to sit, and hack, or misc. I ended up at the Debian table (‘debianist by association’), thanks to the friends I was traveling with. There were tables with people having brought really old hardware, tables with robot arms, and everywhere laptops.
At 26C3 they set up all kinds of networks. The building is properly wired, and there were a few wifi network that worked reasonably well. Then there was the DECT radio network, which means everyone was walking around with your average domestic chordless phone (DECT radio for those in the know). They even set up a GSM network which didn’t work too consistently, but was way cool nonetheless: instead of vodaphone et al. you had an in-house network which even worked for normal domestic calls !
The talks were streamed live. I didn’t attend that many talks in person, as the rooms were really packed. Besides, knowing that the conference recordings would be available later also made it less of an incentive to try and pile in. The talks I did attend/listen to were fascinating.
One talk I attended was about stylometry, or how you can in certain situation detect who’s the author of a text by the word choice, grammar, etc. Which obviously means danger for whistle-blowers publishing anonymously against an abusive employer or an oppressive regime. The author was trying to ‘attack’ those techniques, by trying pastiche or obfuscation. Another talk was about intelligence support systems, and their use by all kinds of organization. I also followed a talk about attacks on PKI, which is interesting since my current work is all about PKI.
The ground floor was catering mostly, and the lower floor was the hardware hackers floor. The catering floor was visited many times to get a dose of Club-Mate. Mate is a naturally caffeinated kind of tea leaf from South-America. Club-Mate is a soda version of that, and quite tasty and effective, as energy drinks go.
Then there were all the cool toys ! You could buy kits of electronic circuits to assemble yourself. I bought and assembled the TV-B-Gone kit to switch off tv’s, which worked, and a dotblox64, which lots of LEDs, which doesn’t yet (because of slightly shoddy solderwork). There was a group making helicopters, and a group building and programming LEGO robots to fight against eachother. Geek heaven, or what.
I also had a go at lockpicking, though I must admit that I miserably failed at that, being quite clumsy (the instructions in german might not have helped). The stories of the instructor (from lockpicking.org and the lockpicking club of Berlin) were interesting. He explained about how locks usually worked, about different kinds, and the pleasure and effort to figure it out. He also bragged a little about his exploits, of course: seems he has a master key of the Berlin underground, and the Berlin public toilets.
The general vibe was one of love for freedom. Lots of subculture represented, though obviously the overarching one was geekiness. No judgments, no rules, things were built for fun, not necessity. A fairly mixed audience, a slightly subversive but enthousiastic spirit. I had a good time, and will enjoy watching some of the remaining talks at home.
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):
gem install hanna- follow the instructions given here – best to put following line in your .gemrc
rdoc: --inline-source --line-numbers --format=html --template=hanna - to regenerate all rdoc
sudo gem rdoc --all --no-ri - 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 - point your apache+passenger (replace by suitable web server) to
directory/sinatra-rubygems/public
(and give it its own port, of course) - bookmark the link in the toolbar of your favourite browser
- 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:
- nothing new under the sun, technologically: HTTP callbacks, and then ajax and js push for the webby stuff
- 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’.
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.
(more…)
9 comments