Today I was going through some trouble setting up an existing Rails project I need to do some work on.

The project uses the Postgres database and Sphinx to provide search functionality. Installing Postgres is easy using the official DMG. Installing Sphinx using Homebrew is also very easy:

sudo brew install sphinx

That should be it, right? Unfortunately, not quite. This did install Sphinx, but without Postgres support. If you build TS yourself, Postgres support is enabled by adding the –with-psql option when calling ./configure. I looked through the brew documentation but didn’t find any way of passing this option to the configure command that brew executes.

Finally, it occurred to me to look into the brew “formula” for Sphinx. This is just Ruby code, and the source of the problem was easy to spot: It turns out that the formula installs Postgres support automatically if it detects that Postgres is installed. The problem was the method it used for detecting this:

config_args << “–with-pgsql” if `/usr/bin/which pg_config`.size > 0
So if pg_config had been in my path, it would have worked. But it wasn’t, simply because I hadn’t yet gotten around to adding /Library/PostgreSQL/8.4/bin to my PATH variable.
Did this, reinstalled sphinx, all went well.

Here’s a surprisingly insightful blog post from Matt Aimonetti. Yes, the guy with the “Perform like a pr0n star” CouchDB presentation.

I really hated this guy when the heated debate about his talk was running (when was this…some time last year?). He responded to the comments he got with such arrogance and lack of respect for other people’s emotions that a lot of us were appalled. I really felt (and still feel, actually) that he did damage to the reputation of the entire Ruby community. The fact that DDH stood behind him obviously just made everything worse.

Now all this seems to be forgotten, and that’s certainly a good thing. I had personally forgotten all about the issue until I came across this blog post. And it completely changed my feelings about him. It’s really great to see that a lot of people do change when they get a chance to sit back and reflect  on the stupid things they’ve done. Everybody should get a second chance if they want it, even a guy like Zed Shaw if he comes to realize some day that he’s being an asshole.

Well done, Matt. Looking forward to following your work in the future.

For a while now I’ve been working on a Danish forum for Ruby and Rails developers: railsforum.dk. It will be based on the excellent El Dorado “full-stack community web application” by Trevor Turk.

However, I wanted the forum to be in Danish, including menus, system messages etc. Not because Danish Ruby developers don’t understand English, but because I want to emphasize that this is a Danish site for Danish developers.

So I decided to contribute a Danish localization to El Dorado. Quite a work-intensive (read: boring) taks, although it was made a lot easier by another contribution: An almost complete German translation made by a guy called Manfred. So I didn’t have to go through the really boring process of finding all the strings that need to be localized.

Along the way I added a few more features:

  • The option to hide the title and tagline, making the entire header image a link to the front page.
  • A feature to disable tabs on the site. I need this because I want to keep railsforum.dk as simple as possible, and El Dorado has lots of features.
  • Ruby syntax highlighting (incomplete, not yet submitted).

Finally, I rearranged a few items on the front page and added a new “portlet” there after discussing this with Trevor.

Here’s how it looks right now:

Ah yes, and then I had to spend some time untangling my Git repository. Because I am (or was?) such a Git newbie, I had put all my stuff on one branch, making it impossible for Trevor to merge.

It feels really good finally to have made a more significant constribution to an OSS project than the occasional patch or bug report. This has definitely whet my appetite for getting more involved into projects like El Dorado. Also, Github is really an excellent platform for this kind of collaboration – the catchphrase “Social Coding” is spot on.

Talking the talk

January 16, 2010

I have come to realize that I talk a lot about Clojure, but I don’t really use it.

I am very excited about functional programming in general and Clojure in particular, so I spend a lot of time catching up on the news on this front. Lots of stuff going on, always.

The other day I sat back for a moment and looked over the hundreds of blog entries piled up in my reading list. Suddenly I realized that most of these would be conveying actual experiences with some language or framework. Be it Ruby, Clojure, Erlang or what have you, these authors have actually tried something out and written about it.

This is more than I can say for myself, unfortunately. I do have several pet projects underway, but I’m not making nearly as much progress as I would like to. Why? Because I spend way too much time reading about new stuff. Reading about what everybody else have been making progress on.

So I have decided that I need to code more and read less. Pretty much the opposite decision from the one I made a few years ago, but hey, times change. It’s a tough balance to strike properly, but I guess we all do the best we can.

Right now I’m splitting my spare time between two areas: Functional programming and dynamic languages. More specifically Clojure and Rails. I have a lot of ideas for projects in both camps, but like I said I’m spending way too much time catching up. I have seriously considered ditching one of these areas completely, but I just can’t do it. Both are extremely interesting from different points of view.

And since I need be both places at once, I must be very careful about how I spend my time. If I want to move forward with my projects, I can’t afford to spend entire evenings reading up on almost a hundred technical blogs. Even worse, almost every single entry is tempting me to go on out on a tangent. So much interesting stuff to learn, so little time. But I’m not really in it for the learning. What I really love about being a geek is the part where I create new stuff. And I think that is what I’m good at, too.

I really need to start walking the walk. It’s OK that I’ll fall a little behind the newsstream, because I’ll gain a much deeper understanding of the areas I choose to focus on. And before long, I should be able to contribute interesting new stuff on my blog as well.

I have decided to build the one thing I know the world doesn’t need: Another Twitter client!!

There must be hundreds out there already, and dozens of them very good. However, after trying out quite a few of them, I’m not really pleased. A quick roundup of the ones I know of:

  • Twitterific is the best so far, but it displays ads every hour (unless you pay), and I can’t really get used to the overlay-style interface. Plus, it often reports communication errors for no reason.
  • TwitterPod is actually OK, but very wierd…! It features a completely useless “QC” mode, where tweets flicker by, intertwined with user mugshots and psychedelic colorized patterns (but of course, you don’t have to use that mode). Actually, I can’t really remember why I stopped using TwitterPod. Probably just because it is wierd and Japanese and alien. It didn’t really have a cool feel to it.
  • The web-based interface (nah)
  • All the AIR-based clients: No, I don’t want AIR on my Mac right now. Maybe some day when I run out of more interesting stuff to play with.
  • All the Android/iPhone/Windows Mobile based ones: No, I want it here on my laptop

So there you have it, nothing is good enough right now. But what would be good?

Here are my thoughts so far about the client I want to build:

  • Open source. I can’t be bothered to do it all myself.
  • Runs on my Mac. If someone wants to port it, great.
  • I want an easy way to track “conversations” between me and some other dude (there probably a funky term in Twitterish for this).
  • When I add a tweet, I expect it to appear in my timeline, or what it’s called, immediately. It should not wait for the next batch of updates.
  • Builtin support for quickly searching for people to follow, using first-, last- or username.
  • Easy way to create all sorts of filters. Most simple method would be to show only the tweets of one followee.
  • It should be easy to mute and unmute friends. The name of a muted friends appears in red when others address him.
  • Every tweet should be colorcoded. Each friend should get a “lease” on a particular color. The lease should expire after some period of inactivity.
  • Fancy visualization: A large canvas (optinally full-screen) on which tweets are clustered by relationship. Ie. when they respond to each other, they form a little group of tweets with arrows showing response directionality. Each tweet should fade in color as it ages.

I will probably be writing the client in Ruby using RubyCocoa.

I am not fooling myself here. I know that someone else has probably covered the features mentioned above in a client much cooler than I could ever come up with. There must be hundreds of alternatives listed on this page alone.

However, there does seem to be a lack of decent open-source Twitter clients. At least ones that are not based on AIR.

Oh well, let’s just see when I get around to actually coding this. I have all sorts of half-baked ideas these days, but way too little spare time to realize any of them.

Drop me a comment if how have an idea for a killer feature to include.

Pre-publish update: OK, so I found one more client that almost discouraged me from writing my own: Lounge.

It looks very nice and IMO is easier to use than Twitterific because it uses a regular window instead of an overlayed one (or whatever it’s called). However, Lounge is an early beta so some features are incomplete or simply missing. For example Growl integration is pretty basic and the Vanity category doesn’t seem to work(?).

One feature that could have been great is the ability to display pictures from Twitpic inline. However, only thumbnails are shown, so you need to launch your webbrowser anyway. Pretty useless then…

Also, it’s closed source – in fact the beta expires on July 1, which makes me a bit suspicious…what then, will I have to buy it?

So in conclusion, it looks quite promising, but I still need to write my own client 😉

Back from Rails Camp DK '08

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!

But…

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

Right, sorry.

I have been thinking of a few ideas for improving the learning-from-each-other part next year:

1. Assignments

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.

2. Deadlines

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.

3. Demos/presentations

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.

Thanks a lot to Henrik for all his work in this, and thanks to Lenio for sponsoring the event!