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 ;-)

 

One of the things that bothers me the most in software development is when you come across a problem for which there simply is no nice solution to be found. You come up with some ugly hack and get the job done, but the nagging feeling of having fallen short lingers for days.

Problem in question: A project I’m working on sells stuff and uses a payment gateway for this. API access is expensive so we’re opting for the proxy method, meaning that the page that reads credit card information is actually served by the payment provider. It looks something like this:

http://epay.dk/proxy.cgi/http://myshop.com/payment

This means that our /payment page is a very special case. All asset paths must be relative, ie. images/foo.png instead of /images/foo.png. In contrast, links must be absolute, http://shop.com/about instead of /about.

I want the rest of the site to follow normal Rails conventions, so I need to special case this very page. This in itself is a challenge, because as it turns out my ugly hack will affect the application layout as well.

I first tried a few different routes:

  1. Override url_for and set :path_only => false. This solves only half of the problem (asset paths would still be wrong) and turned out to be painful because of the two different url_for implementations. Figuring out why is left as an exercise for the reader because frankly, I can’t be bothered to explain why. Leave a comment if you want to know.
  2. Define some default_url_options. For some reason, I never got this to work reliably, and after some time of fruitless digging trough the Rails source, I abandoned the idea.
  3. Create middleware that kicks in only if controller == Xxx and action == Yyy. It would then process the HTML and change href=”/…” instances to be relative etc. You may object that this is a terrible way of abusing the middleware system, but if it had worked, it would actually have been the least intrusive option. The reason it broke down was unexpected and enlightening: I was able to rewrite the HTML, but afterwards the Apache module pagespeed rewrote it again to optimize CSS includes etc. Obviously this only happened in our production environment, so it took me a couple of hours to track down.
So it would seem that my quest to solve this (somewhat) elegantly had failed. So be it. Time to resort to the nasty hacks.

The solution

Warning: You will be appalled.

What I ended up doing was:

  • In views/layouts/application.html.haml, I only include JS and CSS if we’re not on the payment page.
  • In the payment view, I include all JS/CSS like this (notice that the path does not begin with a slash): %script{ :src => “javascripts/jquery.min.js”, :type => “text/javascript” }
  • Also in the payment view, I added some JS that absolutifies all links. It looks like this:
  $('a[href^="/"]').each(function (idx) {
    fullUrl = "http://myshop.com" + $(this).attr("href");
    $(this).attr("href", fullUrl);
  });

Conclusion

I have created some code that works, but which I’m really, really unhappy about. I hope that some day I’ll come up with a better idea and fix this, but I doubt it. Suggestions are obviously welcome – please leave a comment.

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 :-)

On a project, I have a “Revision” resource and URL’s like

http://foobar.dev/revisions/1

Now suddenly the client wants to rename “revision” to “edition”, so all URLs should be changed to the format

http://foobar.dev/editions/1

Unless I’m missing something in the Rails docs, there is no option to change the base part of the path without renaming the resource itself. Actions can be renamed, eg. “nuevo” instead of “new”, but I don’t think the path segment for the resource name can be changed (please correct me if I’m wrong).

I guess the proper way to go would be to rename everything: The AR model, all helper calls, controllers, tests etc. Even with lots of automation, this would be a really annoying task and I’m not inclined to spend time on this right now. Who knows if the client will change his mind again?

So instead, I ended up changes the resource from

  resources :revisions

to

  resources :editions, :controller => "revisions", :as => "revisions"

I’m changing the name of the resource, but the :controller option makes sure the right controller is still called, and the :as option controls the generation of path helpers (so I can keep using eg. edit_revision_path).

Remember to make the same change for nested resources.

EDIT: As Rasmus and Jakob point out, the :path option sets the actual path, not a prefix. I have made some minor updates to the Rails docs to correct this (most instances were already fixed).

It turns out that lots of MBP models have a well-known issue with the headphone port, and this can cause the internal speakers to become disabled. Actually, they’re disabled as a side-effect of digital output being enabled. The headphone port is used for both electrical and optical connections, and the internal switch managing this can sometimes enter the “optical connector present” state for no apparent reason.

Here’s one thread describing this issue, and Google turns out many more.

However, the reason that I’m writing this is that my machine (2010 17″ MBP) seems to suffer from a variation of this problem. All descriptions of the issue I found were rather old, and in all cases it was reported that the red light (ie. the optical signal stream) was turned on when the internal speakers were disabled. On my machine, the red light was visible only some of the time.

Doing a software update, a reboot and even an SMC reset did not help. I eventually fixed the issue by moving the headphone jack slowly in and out of the port while wiggling it a little bit. It took maybe 15 tries before it worked…

To monitor your (lack of) progress, open the System Preferences, go to the Sound pane and select the Output tab.

  • In the broken state, the topmost item will read “Digital Output” and a red light may or may not be visible from the headphone socket
  • When the headphone jack is inserted, this should change to “Headphones”
  • The non-broken state is “Internal Speakers”. This is when you have managed to clear the switch (HW or SW, I don’t know) that is stuck in the “optical connector present” state.

My oldish Acer Aspire One has been running Ubuntu Netbook Remix for a year or so, and I have become increasingly annoyed with how slow it is. I remember it as being much faster when I installed it, so either a) I have become faster, b) The performance of the installation has degraded, or c) My memory is incorrect yet again.

I’m actually inclined to go with b). The problem with the Aspire One (some models) is its extremely slow 8GB SSD. I know, those things are supposed to be fast, and they have done wonders for my last two laptops. But on the AA1, especially the write speed really is terrible. So I’m suspecting that something has caused the Ubuntu installation to do more writes over time…whether this is disk fragmentation, the browser cache or whatever, I don’t know.

For the reinstall, I decided to try out Joli OS and so far it looks like this was a good choice! What I basically need is for this machine to be 100% quiet, reasonably responsive and able to render web pages and PDF files. That’s all, because I use it almost exclusively for reading in bed.

The entire OS is built very much like I would expect Chrome OS (which I haven’t tried) to be built. Everything revolves around the web, and it seems that most of the OS is written in HTML5. Joli OS is in fact based on Ubuntu Netbook Remix, but simplified (even further) and integrating Jolicloud, which is pretty cool. In fact Jolicloud is at the core of the user experience where it replaces the launcher found in UNR.

The idea with Jolicloud is to have a web-based, portable desktop containing all the webapps that you use all the time. Facebook, Twitter, Gmail, Flickr, YouTube, just to name a few of the ones that are added by default.

I’m not sure exactly what Joli OS adds to this (because the OS is all I’ve tried), but a feature I found especially nice is the ability to link my device with Dropbox and Google Docs. I use Dropbox for storing a lot of PDF documents that I want to have available anywhere I go. But I also use it for lots of other purposes, and actually I think this is one of the reasons my UNR installation finally gave up – because I was naive enough to have Dropbox installed and syncing everything.

With Joli, I can browse my Dropbox and open individual documents. Browsing is of course slightly slower than on my physical disk, but I tend to keep these documents open for weeks, so this is not an issue. And of course I could just download any files I want to access offline.

So far, I have done very little customization of the OS. The AA1 has a very noisy fan, but fixing this problem with the acerhdf module is a  simple matter of editing a few files. I also want Caps Lock to be an additional Ctrl, and I want both Danish and US keyboard layouts installed. Both wishes were granted after a few minutes of poking around in the settings (these are just the Gnome settings, of course).

I’m really surprised to discover that I seem to fit exactly into the target group for an OS like this. I have installed Emacs (mostly to edit org files), but apart from that, it looks like I’ll be fine with the built-in selection of programs. Which is just Chromium and the Gnome stuff.

Finally, it looks like there’s a whole social networking thing built into Joli which I haven’t explored at all yet. But I have already earned the badge “Recycler” just by installing Joli and recycling a computer that was destined to be replaced by a tablet before long :-)

Follow

Get every new post delivered to your Inbox.