October 27, 2008
This weekend, I was at the first Danish Rails Camp near Svendborg.
(Photo by wa7son)
The camp was Fri-Sun (unfortunately I could only attend Sat-Sun), and we ended up being 12 attendees. A little less than we had hoped for, but this also meant that we could all fit comfortably in the living room of the cabin.
Saturday afternoon, many of us went for a run in the beautiful countryside. This was an excellent way to kickstart the brain and kill the legs, grounding us for a serious round of hacking.
Thomas took some very good pictures. Not from the run, thankfully.
It’s always nice to meet new people and learn new stuff, and it was especially great to hear more about the Ruby and Rails work that people do professionally in Denmark. The landscape seems to have changed a lot since I last considered a Rails career about a year ago. It seems that both dynamic languages and opinionated frameworks are still gaining ground, even in conservative Denmark (with Rails still leading the crowd). Great news!
All in all, it was a great trip. That being said, I think we should consider how we can make the camp even better next year.
For some reason, software developers have an ability to sit for hour after hour, totally absorbed in whatever they’re working on. I am certaintly no exception.
And there’s nothing wrong with that. On the contrary, that is how we learn new stuff.
But we can do that at home, each and every day if we want to. Many of us probably do, more days than not. When we go through the trouble of renting a cabin in the middle of nowhere, we should really make the most of the time we have together.
I definitely learned new stuff at the camp, but I’m sure I could have learned much, much more.
Stop bitching and get to the point
I have been thinking of a few ideas for improving the learning-from-each-other part next year:
We should prepare a stack of small assignments in advance. Just very simple tasks that take no more than 2-6 hours to complete.
A few examples:
- Create a simple battleships game (Laust and Jakob, that was a great idea).
- Create a super-simple Wiki server using Sinatra and CouchDB.
- Review and compare a few search libs (eg. Ferret, Sphinx) with regards to features and performance. A suitable dataset is provided with the assignment.
- Design an internal DSL for creating SQL queries.
- Compose the ultimate Ruby blogroll, briefly describing each entry.
The assignments should generally touch on something that most attendees find slightly exotic (eg. CouchDB, Haml, Shoooes), but not completely alien or Ruby-less (eg. Fortress, Emacs Lisp).
They should be solved in groups of 2 or 3, preferably consisting of people who don’t know each other in advance.
Personally, I know that having a concrete goal would help me maintain a sense of direction. So would splitting the days into chunks.
A laptop will consume any amount of time you throw at it. In my experience, this often happens because software development is inherently both interesting and complex. When working on anything non-trivial, you’re bound to go of on a tangent every now and then.
Again, this is perfectly normal, and it is an important part of how geeks work and learn. But it is not social, and the guy next to me learns nothing from it.
Given hard deadines for all assignments, we would all be forced to stay focused for a few hours, share our gained knowledge, then refocus.
Each assignment should result in a demo or some other kind of presentation.
Briefly presenting the work done should be mandatory. If everything failed, it’s no big deal. Just tell us why, and we might avoid some pitfalls in the future. Anyway, only a few hours were lost.
The big picture
What I’m suggesting here is that we aim for a more conference-like atmosphere on next year’s Rails Camp.
I think the great thing about conferences is the feeling of enthusiasm they imbue. A good conference should leave you with:
- Lots of half-baked ideas
- A handful of email addresses and half-ass business proposals
- A craving for more knowledge about a dozen new frameworks and several new languages
- Vague thoughts about possible career moves
Conferences should inspire, not teach. I think the Rails Camps could provide the perfect small scale setting for achieving the same goal, if that is what we want.
Your comments, please
Obviously, you’re all very welcome to share your thoughts on this. Do you agree, or am I way off?
Drop me a comment and let me know what you think.
By the way
Francesco, I hope you had (or will have) a nice trip back to Florence. I still can’t believe you came all the way to Denmark to attend…! But I’m glad you did, it was nice talking to you.
October 21, 2008
I had been blogging on blogger.com for a while, but the last few months, I have been increasingly annoyed with the service. Little things, mostly, like the way the editor works and how the Preview mode is very far from the appearance of the published entry.
However, the main reason for the switch was the fact that I simply could not get Emacs support working. g-client took me some of the way, but it wasn’t nearly good enough in its current state.
Just one example: To create a new blog entry, I needed to specify a “post URL”. And to obtain that, I needed to invoke some method (forgot the name) which created a temporary webpage on my harddisk and launched Safari to show it to me! On that webpage, I could then see an overview of the blogs I had on Blogger (a list with 1 element), copy the link to the “post URL” of the blog and paste it back into Emacs.
Also, to save my new entry as a draft, I had to modify the template used for new entries to include some XML snippet that I had to look up in the Google API. And after saving or publishing an entry, the buffer was completely garbled for some reason.
OK, that was a few more examples 😉
I’m not sure if it was just me who completely misunderstood how to use this library, but it seemed extremely rough around the edges.
As I have described in another entry, blogging from Emacs works beautifully with WordPress. And Emacs is where I want to spend my time, also when blogging. I like it here, it’s comfy.
Actually, I was planning on doing a thorough comparison between Blogger and WordPress, but I have realized that this would be pointless, because hundreds of others have done just that. So just google for it if you’re considering which to choose.
October 20, 2008
After switching to WordPress, I can now post entries from Emacs, thanks to weblogger.el.
Note that there seems to be several “weblogger mode” packages for Emacs. Follow the link above to see how I got it working.
weblogger.el had a few problems, most of which were fixed by ciju. Thanks for that! However, it did require a few additional hacks to get it working in the way I wanted to.
Below is the diff between ciju’s version and mine.
2a3,6 > ;; NOTE: Modified by ciju as described here: > ;; http://ciju.wordpress.com/2008/06/06/twiddling-with-webloggerel-emacs-wordpress/ > ;; Also, further hacking by Chopmo > 584c588,589 ; (list "Subject" title) ; fixed by chopmo > (list "Subject" (or title"\n")) 938,939c943,945 < (if (buffer-modified-p) ;; modified by ciju, disabled by chopmo > ;; (if (buffer-modified-p) > ;; (weblogger-prepare-and-send nil nil)) ;; ciju's modification
You can also download the patched weblogger.el here.
The diff above tweaks the weblogger feature in two ways:
- Fixes a small bug which caused the newline after “Subject:” to be missing when starting a new entry.
- Reverts a change made by ciju which caused the current entry to be saved as a draft when navigating to the next (with C-c C-n) or the previous (with C-c C-p) entry.
The second change means that published entries stay published and that navigation between entries is very fast, but also that you need to actively save a modified entry before leaving it. This is done with C-c C-s to save it as published or C-c C-c to save it as draft.
Both commands simply overwrite the previous published/draft state of the entry, so there’s not explicit “publish” step. You just save the entry as published. Also, both commands can be used for initially saving the entry.
Another small tip: Note that after initially saving an entry, the URL to the entry is displayed in the header:
As long as you’re logged into your WordPress account, you can use this URL to see a preview of the entry as you work on it. The preview is updated as soon as you save the entry in Emacs.
October 19, 2008
As all MacPorts users know, the process of building can take a significant amount of time when installing ports.
While setting up my new multicore machine, I had to install a lot of ports, and I was surprised to see that MacPorts only used one core when building (by the way, it seems that this may be about to change).
To have MacPorts use all cores, change the following in /opt/local/etc/macports/macports.conf (if you installed MacPorts in the default location):
# Add the following line: use_parallel_build yes # Find and update this line. Specify the number of # concurrent jobs to run or 0 for "auto" (ie. use all cores available). buildmakejobs 8
However, note that each individual port can override these values, and unfortunately, it seems that many ports do.
October 15, 2008
So, time for a (late) JAOO 2008 recap. How was it this year?
Unfortunately, the keynotes were clearly lacking this year, but in very different ways.
Monday, Anders Hejlsberg talked about the future of programming languages. Or should I say, the future of programming languages on the .NET platform. For which there is currently support in Visual Studio. Don’t get me wrong, I actually like .NET, even though I hate Windows. But for the opening keynote, talking about F#, LINQ and P-LINQ (with the Pascal background intro that seems to be becoming the slightly dull backdrop for Hejlsberg’s talks) simply doesn’t cut it. And switching to VS three times to do live demos is just missing the mark by a mile. I was very disappointed with this talk, but mostly because I know how brilliant Hejlsberg is, so I expected more than just an MS-centric view of the future.
Lars Bak talked about V8 tuesday. This keynote was a bit special, because obviously it had to be planned some time in advance, and the V8 project was only revealed very recently.
Working in the office next to Lars and the rest of the Google team here in Aarhus, I was very curious to hear more about what they have been up to for the last few years. In that respect, I certaintly wasn’t disappointed. The talk was rich on details, so having no experience with VMs (in the V8 sense, not the VMware sense :-)), I was lost at times. But this was no problem, and it was great to hear Lars explain about the challenges they’ve been facing in creating V8. Also the QnA session was very good.
So I was very pleased with this keynote, actually. But as someone pointed out to me later on, the topic really wasn’t keynote material. Interesting as it was, and popular as the topic is, it was obviously only relevant for a fraction of the audience. Nevertheless, I personally enjoyed this one.
Wednesday’s keynote was a complete disaster. The otherwise brilliant Guy Steele and Richard Gabriel (who is also very bright, I’m sure) did their “50 in 50” routine, and I have to say that I absolutely loathed every minute of it.
The tagline was something like: 50 remarks in 50 minutes, each 50 words long (if I recall correctly). The remarks were interspersed with images, audio and video clips. The substance of the talk was a tour through the last many (50?) years of programming languages, sprinkled with uber-geeky humour. Definitely not for me, but fortunately, judging from the reaction of the audience, others liked it better.
However, I’m pretty sure noone enjoyed the fact that they went more than 20 minutes over their time slot. Given that the talk was so rigorous in its form, I simply don’t understand how this could happen.
I didn’t see as many talks as I would have liked this year, but I did see some good stuff.
Guy Steele gave a great talk on Fortress. Not unlike the one he gave last year (or was it 2006?) but with even more substance. Some of the maths stuff was over my head, but that didn’t matter. The important this was that the talk was interesting and really whet my appetite for learning more about Fortress.
Also, Sun ran a great little competition in the exhibition area this year. A guy came around to our booth with 2-page Fortress program that solves Sudoku puzzles in a massively parallel fashion. The challenge was to figure out how many threads of execution are used, and the prize was a Sun-branded USB stick with the latest snapshot of Fortress on it. I still have the program on my home office wall, and when I feel like it, I look over it and understand another little chunk. Unambitious, you may say, but a lot better than putting it away and forgetting all about it.
Wednesday, a guy from LEGO gave a pretty weak talk about a project that actually looks very interesting. They’re building a new “robotics platform” called WeDo, which is basically a $30 (IIRC) kit with a few motors and sensors. This was a challenge spurred by the OLPT project, so various measures have been taken to target it at developing countries. For example, the robot is connected to the laptop with a USB cable because batteries may not be readily available. A very cool project, but the presentation was really a drag… For instance, I now know that LEGO uses Perforce for their software projects, and I would have lived happily on without that piece of information.
Lastly, the talk “The lively kernel” by Dan Ingalis was awesome! I urge you to check out this video demo or simply have a go at it yourself. I’m very curious to see what this project might lead to in the future.
The exhibition floor
Again this year, we had a VMware Denmark stand, and we got to show off our software and tell people what we do.
One thing that we all noticed was how much more aware of virtualization everyone was this year. At last year’s JAOO, we were very surprised to learn how many developers simple had no idea that virtualization existed as a concept. But this year, it was different. Maybe because we handed out so many VMware Workstation coupons last year 😉
On the demo side, we had taken the time to get a VMotion setup up and running this year. Two ESX hosts and a Linux VM running some streaming video server being moved between them. And obviously a third machine running Virtual Center and a VLC player showing the streaming video without a glitch as the VM was moved. A lot of the attendees didn’t know that this was possible and wanted to know the details of how it works.
Also, we brought our Mac Mini running the recently-released Fusion 2. With all the Google Chrome hype in full effect, it was a lot of fun showing off Chrome running (apparently) natively on the Mac! Of course, it was running in a Windows VM in unity mode, but we did manage to fool a few people 🙂
Version 2 of Fusion also adds the ability to run Linux VMs in Unity mode, so we were able to fire up Chrome, Safari and Evolution side-by-side on the (struggling) Mini.
I didn’t go to a lot of talks this year (I was at work most of Tuesday) so I shouldn’t pass judgment on the conference as a whole. But I do think the keynotes left a lot to be desired.
Also, I think the Trifork team should reconsider the number of tracks on the conference. Judging from various Ruby-related blogs, the trend for conferences is clearly in the direction of fewer tracks (often just one) and much shorter talks.
I think this makes perfect sense. We go to conferences to widen our perspectives on software development in general. And you really don’t need 50 minutes to present new ideas or projects. With so many tracks going on at the same time, attendees constantly need to discard a lot of material. This would be less of a problem if there wasn’t such a big overlap between the topics of the tracks. But as it is, I think most developers wish they could follow 2-3 concurrent tracks. This leaves you with a constant feeling of missing out on interesting stuff (which you probably are!), and if you’re unlucky enough to attend a boring talk, its 50 precious minutes gone.
I think the organizers should consider cutting the number of tracks and the length of each talk in half. The talks should inspire and engage the audience, and this can easily be done in 25 minutes, leaving us with an urge to know more. The success of a talk should be measured by the surge of hits to the project’s website after the talk, not by the number of people still present in the room after 50 minutes.