torsdag 16. august 2012

Scravatar - A tiny scala library for Gravatar

I tend to get upset whenever I sign up to a site and they do not retrieve my profile picture from Gravatar (yeah, I'm looking at you . Because no one should have to upload a picture of themself on the Internet in a Sombrero more than once. Gravatar is a very simple, yet very good service that links profile pictures with e-mail addresses, every site out there with a profile concept should use it.

Just to see how easy it is to integrate with Gravatar I decided to write a tiny Scala framework for generating the Gravatar URLs, aptly named Scravatar.

It is hosted on Github and as of today, it is even available in maven central.

Here's how it works in its simplest form:

If you want to a URL that you can use as src in the img tag on your site served over a HTTPS connect, you'd want to set the ssl flag to true. That way browsers won't won't show a warning saying that your site contains insecure content.

And here's an example setting all the available properties before generating a URL.

The Gravatar class in Scravatar is immutable (and thus thread safe).

As for the maven central repo, the groupid is com.andersen-gott and the artifactid is scravatar. It is cross compiled for Scala version 2.9.1 and 2.9.2.

fredag 30. mars 2012

Using Unfiltered and HTTPS on Heroku

A few weeks ago I started a pet-project using Scala and Unfiltered. Basically I wrote a new front-end for an Internet-explorer-only website. Now, the website I'm scraping requires the user to log in, which in turn means that I have to handle a user's username and password. Obviously I don't want those to be transmitted in plain text over http, that would just be irresponsible. Luckily, Heroku offers HTTPS support out of the box, with the piggyback option that allows you to use the Heroku SSL certificates. This means that all resources available on will also be available with en encrypted connection on But how does it work?

Let Heroku do HTTPS, you do HTTP
The Heroku router will be the entry point that does the actual HTTPS communication with the client, then the router will forward the calls to your server (Jetty in my app) over HTTP. This means that the data is unencrypted between the Heroku router and your app, but if you are not a tin-foil-hat kind of guy, you'll be OK with that.

But those pesky users are accessing my app using HTTP
Here comes the problem, the app is available both through HTTP and HTTPS, and while you aren't into tinfoil hats, you don't want your non-IT-savy users' credentials freely available for anyone with Firesheep on that insecure internet cafe WIFI. What you want to do is to enforce HTTPS. But how do you do that? Your app is configured to run HTTP, not HTTPS.

Developer, meet x-forwarded-proto
Well, Heroku sets some header values that indicate wether your app is being accessed using HTTP or HTTPS, say hello to x-forwarded-proto. This header is set by the Heroku router, and will be either HTTP or HTTPS. So, by querying that value, you'll be able to see how your app was accessed. We now have a way to figure out how the app is accessed, all that is left to do now is to enforce HTTPS.

The following extractor will help you figure out what protocol was used to access your app
object XForwardProto extends StringHeader("x-forwarded-proto")

You can now use it in your Plans like this:
case r@POST(Path(Seg("login" :: Nil))) & XForwardProto("https") => //Do login
to only respond to logins over HTTPS for example.

What would be even better than only responding to https would be to redirect all http traffic to https. To do that I wrote (or to be fair, it was mostly my good colleague Erlend's work) this HerokuRedirect object:

object HerokuRedirect {
  def apply[A, B](req: HttpRequest[A], path: String): ResponseFunction[B] = {
    val absolutepath = if (path.startsWith("/")) path else "/" + path
    req match {
      case XForwardProto(_) & Host(host) => Found ~> Location("https://%s%s".format(host, absolutepath))
      case _ => Redirect(absolutepath)
Now, you can add to your Plan (preferably the first case of your first Plan in Unfiltered) a redirect for all incoming http requests, like this:
case r@GET(_) & XForwardProto("http") => HerokuRedirect(r,r.uri)
Quite nice, hu?

More uses for the XForwardProto
I'm also using the XForwardProto when setting cookies, specifically when setting the secure flag, like this:
        val secure = req match { case XForwardProto("https") => Some(true) case _ => Some(false)}
        SetCookies(Cookie(name = "someKey", value="some value", secure = secure)) ~>

Some text

Of course I could have set the secure flag always, but then testing on localhost would be a pain, this way I can test without https on localhost, and still enforce https only on heroku.

torsdag 23. februar 2012

Confessions of a waterfall refugee

Having just switched jobs from a consultancy that favored waterfall projects with few deployments each year to a smaller consultancy favoring clients with a more agile approach has been somewhat of revelation. At this point in time, pointing out that waterfall is not the right way to do projects is sort of a  waste of www-bytes. I've never been a fan of waterfall, but having finally escaped the clutches of upfront design, long development cycles and test phases here are my observations on what the waterfall convicts are missing out on.

Politics and Procrastination
The nature of waterfall with design phases, lengthy development phases and test phases is a breading ground for highly political environments with representatives from each phase digging trenches and preparing for combat as one transition from one phase to another. It's no wonder really. People have been putting all their effort into something for a long time and they are not about to get shot down when they are approaching the finish line. "You'll accept my design/code god damn it!! There is nothing wrong with it, I've spent months crafting it just right!"

These tense political environments are stressful, people will continuously look over their back and make sure they have a scape goat ready if push comes to shove. I can only speak for myself, but this make me an unhappy developer. It also provides ample grounds for procrastination. It's not like the developers work will be visible any time soon, there is no _real_ deadline coming up (in waterfall the 4 week testing phase ending a delivery cycle is always pushed). No one will notice if I don't pull my weight this week, I'll just accept all the meeting invites in my inbox (waterfall projects tend to have more meetings as well) and look busy. Also, I don't want to be the one writing the code that screws up this deployment everyone has been waiting for the last 6 months. If I don't make a lot of noise and don't write a lot of code, then I won't break anything. When deployment to production is a dot on the horizon, you'll delay. It's part of the human nature, it's why department stores are full of desperate people on Christmas Eve. We delay and procrastinate.

Developer productivity
I believe most developers are developers because they enjoy creating stuff. What fun is creating stuff if no one sees it and it's never used. If you are pushing to production frequently (say, at least every third week), the developer will see their code in production, they will see how it works. Or how it doesn't. When you fail it will also feel better than waterfall failure, as you can make it up again in a few weeks.

All this makes a developer more productive, seeing your work being utilized appeals to your sense of achievement. People are willing to visit the same coffee shop everyday to become a 4square mayor or get some sort of a Gowalla badge. Sense of achievement is the second highest level in Maslow's hierarchy of needs, it's a powerful thing. Developers will apply themselves more if they see their code in production frequently, at least that's my opinion.

Beware of the fake agile
I hate using the a-word, one of the reasons is the movement of "adapted agile". You know, we do sprints, we do whiteboards, we even buy the "super sticky" Post-its. We have demos every third week (though mostly by showing powerpoints)...and we push to production every 6 months. You want to push to production when a feature is done, not when the MS project plan tells you it's time.

Bottom line: go into production often
I don't care what you call it. Agile, lean, continuous delivery (or my personal favorite; programming motherfucker!). The effect isn't down to the application of the right buzzword it comes from reducing the time from when code is written to when it runs in production. That is what will motivate developers (at least me) to give a little extra. You'd think everyone knew this by now, but they don't... after I switched to clients doing frequent deployments to production 7 weeks ago, I've seen my code in production twice already, and I'm a much happier and more productive developer!