A few weeks ago I attended a great Geek night at Trifork. The speaker was @drkrab, and he was talking about “Actor oriented programming”.

Knowing Kresten’s work in recent years, it is obvious that this talk was very inspired by Erlang. In fact, much of it was about Erlang, but he only briefly touched on his Erjang project (which was nice for those of us who saw his Erjang talk at last year’s GOTOcon).

Erlang

Erlang is “designed for reliability in the presence of errors”. Others (notably @drkrab) can explain what this means better than me, but the following is a quick tour of some of the highlights as I understood them from the talk.

An actor is an “active object” (ie. an object containing its own thread) plus a state machine. In Erlang, actors are implemented as processes which are designed to be very lightweight. Kresten mentioned that the size of a process in Erlang is comparable to that of a Hashtable in Java, so literally millions of processes can coexist in the same Erlang VM. Processes can be hooked up to monitor each other, so that if one process dies, it can be restarted by its monitor process. Error handling is done very differently than in other languages: In general, don’t try to cover all possible error cases by coding defensively. Instead, let stuff crash and make sure that the system as a whole is resilient.

Processes communicate with each other by passing messages in the form of immutable data structures. Often, communication will simply be one-way, or it may be indirect in the sense that process A receives a message from process C in response to a message it sent to process B. In this scenario, process B will typically have spawned process C as a worker for handling that particular request. The interface of an actor is called a protocol. It can be thought of as an API except that it may change with the internal state of the actor.

Revolution

The basic premise of Kresten’s talk was that we as developers are headed towards a revolution. Just like object orientation was a revolution about 15 years ago, the internet age will be forcing to change horses again soon.

This is a very interesting theory which sounds very plausible to me. I’ve heard the topic mentioned many times before in different forms, but this was the first time I had heard anyone systematically explore what may be going on right now, and I found that really interesting.

Kresten started by exploring the anatomy of a scientific revolution, using the classic example of the geocentric vs. the heliocentric model of our solar system. Assuming that the earth is at the centre of the universe obviously made the orbits of our neighboring planets look very strange. Also, I’m sure there was a multitude of other problems I know nothing about.

Revolution needed

So there were a lot of observations that were hard to fit into the model, and this is a sign that a revolution is needed. And indeed, a very painful revolution was needed in which lots of scientific effort was suddenly rendered obsolete, and lots of frustration had to be endured.

Software professionals saw the same thing happen with the advent of object orientation. There were lots of misconceptions and resistance initially, but as history has shown, OO turned out to be a very useful paradigm.

However, we may be on the verge of the next revolution. The internet age is profoundly changing the way we build software – everything is now much more decoupled than is used to be. We often build new systems by integrating lots of existing services, each of which is outside our control. So increasingly, we need to design for reliability in the presence of errors. Sounds familiar?

My thoughts

I have thought about this talk a couple of times over the last few weeks, and I am pretty convinced that Kresten is on to something. And when I try to put these ideas in the context of my day to day work, there’s at least a partial match.

Much of what I do is Ruby on Rails programming, and in that community we do a lot of integration work. Not integration in the SOA sense, but integration in the form of consuming services provided by other parties. More and more frequently, we use web services to supply functionality that is just easier to buy than to develop from scratch. A good example is mailing lists. I don’t know anyone who would still opt for a DIY mailing list system when we have services like Mailchimp which are feature-rich, affordable and very solid. It has just become cheaper to buy services like this. Error reporting is another good example. I pay $5 per month for my Hoptoad account – this is so cheap that I wouldn’t dream of rolling my own solution. It just wouldn’t be cost effective because my time is much better spent working for clients.

These external services may be down from time to time, and we need to be prepared for that. Were we to implement them in our own software, they would be down from time to time as well, but that downtime would often coincide with the downtime of the client software (which is especially scary in the case of error reporting – related, check Avdi Grimm’s war story on the latest PragProg podcast).

Apart from RoR I do a lot of Android programming, and some of the ideas apply here as well, but I think putting them into practice is further off into the future. Mobile devices certainly need to handle errors well (loss of network connectivity is a very real issue), but changing the programming paradigm to something like Erlang doesn’t seem to be right around the corner.

However, the Android app I’m working on right now is written in Scala, so maybe I should try to sneak in a few actors ;-)

 

Feeding the trolls

May 31, 2011

Today, after reading Zed Shaws latest blog post, I did something really stupid.

Of all internet phenomena I’ve come in contact with, trolling is probably the worst. And although I think Zed is not helping the situation by being so harsh, I can understand why he is really, really pissed off.

In response to this, I started a repo on Github of known trolls. I tweeted about it and Mentalizer correctly pointed out that my repo was more or less an act of trolling in itself. Such a list is worthless without some kind of public criteria for who goes on there, or at least some sensible definition of “trolling”. I offered neither, and I wasn’t prepared to put in the effort, making my initiative decidedly half-assed.

So my public repo of trolls was a bad idea. What do we need instead?

Another bad idea

Here is another well intended but probably really bad idea. I’ll build a site that allows you to propose trolls and allows registered users to vote up their troll-ranking. It will be complete with an API to retrieve someone’s troll-score and automatically blacklist them from your site.

Why is this a bad idea? Well obviously, if I actually built such a site, I would be the first name on the list, voted up by hundreds of actual trolls. So by my own definition, I’d be a troll. If this became popular (which it would have to in order to fullfill its goal), it would become a warzone of mudslinging and attempts to destroy people’s reputation.

Conclusion

This is not the first time I have thought about how to help the internet getting rid of trolls, but hopefully it will be the last, because I feel like I’m wasting my time. I think it would be a huge accomplishment to reduce the amount of trolling to a tolerable level, on the same scale as what Google is doing to fight spam or what Stack Overflow is doing to fight ignorance.

But it all comes back to the old advice: Don’t feed the trolls. By creating any public list, voting based system or whatever, I would be feeding the trolls. My problem is that I don’t really understand the psychology of trolls, so I keep thinking up all kinds of elaborate systems which all fail in the same way: By acknowledging the trolls, feeding them.

Fighting something by ignoring it is really hard.

Non-intuitive UIs

May 30, 2011

Have a look at this page:

http://www.thefreedictionary.com/brought

OMG, it includes the word “participle”, WHAT DOES IT MEAN?!?

Well, what you have no way of knowing is that you can double-click this or any other word and go to the entry for that word. Not a bad feature at all, but not very obvious either :-)

Although I basically agree with the Pragmatic Programmers’ old advice about learning a new programming language each year, the time has come for me to slow down.

I have been programming for many years and I know a lot of different languages. Many of them are boring and similar (eg. Java, C#, C++), some are not boring but similar (Ruby, Python) and some are completely different (Clojure, Common Lisp, JavaScript).

I’m well aware that I could learn a lot by studying Haskell or diving deeper into Javascript, but I’m going to take this year off.

Why? Very simple. I still have so much to learn from Clojure. I could write at length about the virtues of functional programming or about how Clojure takes advantage of the JVM. I could go on and on about the REPL, Java libraries, infinite lazy sequences (list of all primes, anyone?), the exceptionally smart community members and so on. But others have already done this much better than I could. For a great introduction to the language itself, go watch the intro videos by Clojure creator Rich Hickey. For all the surrounding stuff, there are lots of interesting blogs to read.

Likewise, although I have a lot of experience with both Ruby and Rails, I’m not done learning here either. Especially, I need to tune my Emacs to achieve better code navigation and debugging support.

Two languages that I really like. This year, I’m going to focus, not diversify.

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.

I’m often surprised by the amount of effort people put into getting things done. Reading books, blogging about it (I realize that this is what I’m doing right now, but I’ll keep it brief), using all kinds of fancy software etc.

Sometimes, you really just need to keep it simple. One example is email. Most of us get a lot of email, and it can be hard to keep up.

Here’s my solution: Whenever I get an email that I need to respond to, I either respond to it immediately or “star” it in GMail. Every time I have a few minutes to spare, I go over my folder of starred messages and respond to them.

Keeping it very simple, and this works perfectly for me.

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.

Growing up as an Emacs user

December 19, 2009

Today I took another step towards Emacs adulthood: I disabled transient-mark-mode.

Big deal, you say? Well, I vividly remember the relief I felt when I found out how to enable it as a novice Emacs user two years ago. Not having a visible selection was just too wierd.

But now I’m ready to change that habit as well. I enjoy the reduced visual clutter, and ironically, I find it easier than before to quickly extend the region to the part of the buffer I want. A frequent annoyance with transient-mark-mode enabled was that I often highlighted text by accident.

However, I’m a bit annoyed that some commands don’t behave the way they used to. For example, comment-dwim (which I use a lot) needs transient-mark-mode to be enabled on the region to (un-)commet. I know that I can temporarily enable transient-mark-mode by doing two C-SPCs instead of one, so I guess it is a small price to pay. But I don’t understand why it can’t just work on the region.

I’m not sure why I suddenly decided to ditch transient-mark-mode. Maybe I accidentally highlighted a region one time too many. But it got me thinking, yet again, about the way I use Emacs. I’ve used it for a few years now, and I think I know and use the most important productivity tricks. But obviously I know that there’s so much still to learn. And now that I feel comfortable, moderately productive and (most importantly) almost never annoyed at anything, I don’t learn as much as I should. I still customize stuff at least few times a week, but I don’t learn significant new features, modes etc. very often.

I want to change that. I really want to be an Emacs wizard, not just an experienced user.

So where should I find inspiration to learn new stuff? The hard part is that I don’t know what I’m missing anymore. As a novice user, I knew what Emacs could do, but not how. Now I need to find out what else Emacs can do. Apart from the plentitude of Emacs-related blogs out there, I’ve found a really good source of inspiration. At VMware, we have a “Tips & tricks” mailing list to which I’m subscribed. Often, useful Emacs, Vim, Sed, Awk etc. tips are posted on that list. I just need to pay attention, which can be hard when you receive hundreds of emails every day.

So let that be the tip of the day. If you work with other Emacs users, learn from them. Create a forum on which you can exchange tips and tricks, be it a mailing list, wiki page or whatever.

And be sure to forward a copy of each tip to me ;-)

Wow, that entry ended up way too chatty.

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!

Follow

Get every new post delivered to your Inbox.