AJ Kovalainen

Developer/Designer Role

2016-11-10T00:00:00+02:00

A friend wanted to know how a developer/designer hybrid role works in real life. Especially when it comes to working in a software consultancy. So here are my thoughts.

Solita is a software consultancy, and I think being a developer & designer hybrid at Solita worked very well. I designed & developed HTML/JS prototypes for various projects. The team then “copy-pasted” it into the code. A few times, when I was on a project as a designer, I created style guides with some of the UI interactions implemented in JS. I also did small one-man projects where I designed e.g. a campaign website with the client and then implemented it e.g into an existing website monolith in ASP.NET. I guess that’s better for the company as you don’t have to put two resources on it, and have them spend budget communicating. Tho' a lot of the time talking with someone opens up new possibilities so ¯\_(ツ)_/¯

At Flockler being a developer/designer works great. I can create brandline adhering fully functional features on my own. Of course, I don’t just build it & ship it like that, but seek feedback continuously. And we’re actually lucky to have two developer/designer hybrids on our team, and we give feedback on both the design & the code to each other :) And it works great because in a fun way we complement each other. I’d say I’m more of a developer, with a ratio of 60% developer 40% designer while Petri is more of a designer with the same ratio in reverse.

The trickiest thing for me at least is that sometimes you’re in dev mode and can’t get into the artistic/creative mode, and sometimes you’re in design mode and just can’t think in code. But if you e.g. draw in Sketch first, then have a long pause (reset the brain with exercise or sleep) and write the code e.g. next day, it works better. Can be done in reverse as well (code first, design later).

Are you a fellow developer/designer hybrid? Or have you wondered what it’s like? Let me know your thoughts!

Soundboard with Ember.js

2016-05-02T00:00:00+03:00

I have a friend who’s a pretty fun guy. He’s been sending these bigger-than-life one-liners, small songs and what-not to our gang’s WhatsApp group and we’ve been having a laugh at them over a period of time. They’re mostly alcohol related and heavily tied to the Finnish culture. But I digress.

Looking for these sound clips in our WhatsApp group is tedious. It’s also impossible to anyone except our group. I wanted to make these clips easily available to everyone so I built a quick Ember app called Simo Soundboard just for that, and here’s how I did it.

TL;DR: Quick soundboard
If you just want to build a similar soundboard quickly—and don’t care about my story—you can clone my simo-soundboard GitHub repo, replace the audio files, give each file a nice name, change the secrets, compile the code and deploy it somewhere. And there you go.

Getting started

I picked Ember because I’ve been working with Ember for 3 years and I’m very comfortable working with it. I simply love the workflow you get with ember-cli – even if an app doesn’t need Ember all that much, just like this soundboard didn’t! I used only Ember as there wasn’t any backend stuff required. Just static resources and some client-side logic.

Next, I started creating a mockup of the app in HTML & CSS. Soundboards are usually very simple and I wanted to follow that convention. I also wanted it to work well on mobiles so I started the design with the small screen sizes in mind. I made it responsive so it didn’t look like a stretched up mobile UI on desktop.

The actual Ember part of the app was very simple: just one ApplicationRoute as the root object, a template, and one play-button component that would wrap each sound clip and its logic.

Playing sound

After getting the initial design and the basic Ember app structure done, the next hurdle was to get the browser to play the sound clip. Having worked on Beatstream, I know from experience how tricky playing sound in a wide range of browsers and devices can be. I’ve tested a bunch of different audio playing libraries and my experience is that SoundManager2 does it best. So I pulled that into the app with bower install --save ember-cli-soundmanager-shim, updated the ember-cli-build.js to include SoundManager2’s files in the build, and made the play-button component use SM2 to play the audio file it was given. You can see the code in https://github.com/Darep/simo-soundboard/blob/master/app/components/play-button.js.

Deployment with secrets

ember-cli-deploy is another tool that I really like. It’s a “root” addon for creating a deployment pipeline. Basically, you stack a bunch of addons on top of it and they are run on deploy. I wanted to deploy the soundboard onto my cheap RamNode server so I went with rsync and ember-cli-rsync.

Secrets such as passwords, encryption keys and access keys should not be checked into the source code repository. At least not in plain text. I still like to have the secrets in the repo so I encrypt them with EJSON. It’s a Go app/Ruby gem by Shopify and I’ve been using it for a while. I would love to have a JS version of the gem for these JS based apps but none exist so far.

EJSON works simply by encrypting a given JSON file into “encrypted JSON” using a certain private key. Later you can use the same private key to decrypt the EJSON back to regular JSON. I wrote a simple Node.js script to decrypt EJSON which I use in this project as well. It requires the Ruby ejson gem, sadly.

After you have the secrets you can actually deploy. Running ember deploy production will walk through the ember-cli-deploy chain: build according to build config, create some manifest & revision data, and finally transfer the files to the destination host & directory specified in my secrets.ejson.

Testing in production

After I deployed the app to my server I noticed a usability problem related to bandwidth: there was no indication in the UI (like a loading gif) when a sound clip was being downloaded in the background. The user was just left there hanging wondering if something was going to happen soon. I know Chrome has a network throttling feature and I do use it, but I rarely remember to use it while developing unless I know I’m e.g. fixing a network latency related problem. So deploying and testing in the real production environment revealed a bug I hadn’t thought of. It’s good to deploy early and often to catch stuff like this.

And there you have it. Finished soundboard. “Vois hakkee Vammalasta Kossun” as our friend Simo once said.

I'm a digital nomad

2016-04-02T00:00:00+03:00

In September 2015, my wife and I hopped onto Finnair’s wings. The plane would take us from the autumn-stricken Helsinki to Singapore. A week long holiday in tropic after no summer holidays sounded good to me. Seven days of sweating and air-conditioned shopping malls later, we hopped over to Australia. There we would spend the next 6 months or so working as a ‘digital nomad.’ We are already 6 months in and it’s been great!

The idea for this trip came to me in 2009. At the time I was working as an IT Trainee at UPM, a global forest industry company. I enjoyed working with this Australian bloke and somehow we all started joking around about me moving to Australia to work on UPM’s IT. The “joke” stuck with me and I started saving money for the trip. Saving is easy, but saving to stay in Australia for several months is not easy. I left UPM in 2010 and didn’t feel like going back to work there. So my plan was to find a job at an Australian company, but in the end I happened to find something different: in 2013 I got a remote-friendly position at Flockler and could live anywhere with Internet.

We bought plane tickets for all the major flights at the start of May 2015, 4 months before leaving for the trip. HEL→SIN, SIN→DRW, BNE→NRT, and NRT→HEL¹. The next day we started selling our stuff and gave notice on our lease. Getting rid of all that stuff felt so good! Right now my belongings consist of my Macbook, a camera, miscellaneous computer stuff (like cables, a mouse & keyboard), and a suitcase full of clothes. And I feel good about owning so little even though I could do with less clothes, hehe.

So we flew to Singapore. Then we hopped to Darwin, the north-most big city of Australia and spent another week on holiday there. After Darwin we flew straight down the middle of Australia to Adelaide. Adelaide was a lovely place, we were there for 12 days and I worked at Cocolat café through most of that. From Adelaide it was a 1 hour flight to Melbourne where we spent 3 months. Melbourne is amazing, probably my favorite city in the world! Then I took another week of holidays to travel via Wagga Wagga & Canberra to Sydney where we stayed for 1 month. I met with an old university friend and worked from their office for a few days. We took an extended weekend trip to get to Brisbane through Byron Bay, and now we are in Brisbane. We will be here for 3 months.

Noora and me in Gold Coast. Photo by Maria Morri

I’m not sure how to put the experience in words, but I’ll say this: trying to work while moving from city to city every week or few days is not easy. I full-heartedly recommend staying in one place for at least a month, preferably several. Slow travel. Suits me perfectly.

Anyways. I just wanted to drop a quick memo/update on what’s been going on. Let me know if you’d like to know details about stuff, like living arrangements, expenses and so on!

P.S. If you’re fluent with Finnish, check out our travel blog.

We’re gonna make a one month stopover in Japan before flying back to Finland ↩

The Recipe for the Worlds Largest Rails Monolith by Akira Matsuda

2015-06-01T00:00:00+03:00

Akira Matsuda gave a really good talk on some of the problems that CookPad has run into with their quite sizable Rails app:

300 app servers, deploys are slow (~20min) => replaced capistrano with a handmade deploy program (mamiya) which deploys in 1 min
1000+ models, 30 databases, ActiveRecord is choking => read / write splitting, handmade ActiveRecord adapter for this (switch_point)
Tests take 5 hours
=> execute rspecs distributedly (rrrspec)
=> use a beefy, spot instance server to run tests. Cheap.
=> database_cleaner is slow with 1000+ tables => database_rewinder
ActiveRecord migrations take forever to execute => ridgepole
Big rails app with big team results in code conflicts => created a rapid prototyping framework for rails (chanko)
Upgrading rails: created a response verification tool (kage)

Conclusion: Monolithic apps can scale, you don’t have to split it into many apps, eventho' microservices are really hot these days. Microservices bring their own problems and are not a silver bullet.

Writing Fast Ruby by Erik Michaels-Ober

2014-11-24T00:00:00+02:00

Good tips for optimizing your Ruby code. Remember though, premature optimization is the root of all evil!

Cache busting

2014-08-30T00:00:00+03:00

Caching CSS, JS, images and other website resources on the client is a standard for quality websites. If you want your site to be fast, you should be doing browser caching using ETag and Cache-control or Expires headers. If you are not yet caching your website’s assets client-side, hit the Google’s performance guide for in-depth info.

Unfortunately, caching creates a problem. When you update the CSS, JS, or other resources, the user’s browser won’t download the updated files until the specified caching period is over. For CSS and JS, I usually set the caching period to be 1 year. Without cache busting, the user would have to wait 1 year or push refresh (aka. F5) to see the changes. And users won’t go around pushing F5 on any website they visit. That’s just silly :)

Luckily invalidating (or busting) cached website resources, such as CSS & JS, is not hard: serve the asset under a new, unique name.

For example, if your CSS file was previously called style.css, you can rename the new version to style-v2.css and change the href of <link> to style-v2.css in your HTML manually.

Automatic cache busting

Renaming the assets everytime manually (as mentioned above) is doable if the project is small and you have the nerves. But it’s actually simple to automate.

Many Web frameworks – such as Ruby on Rails – actually already provide automatic cache busting. If you’re using such a framework, you only have to configure it. There are also libraries and tools made for busting the cache. mod_pagespeed is one. I’ve used it successfully in the past for specifically this.

If you want to create your own automatic simple cache busting, I’ll explain my technique for automatic cache busting with WordPress and PHP.

How to: Automatic cache busting in WordPress

First of all, I have my asset (a CSS file) located at /wp-content/themes/ajk/css/main.css.

Add this auto_version() function into functions.php of your theme:

Add a <link> to the CSS file into the WordPress theme’s header.php with auto_version() like this:

<link rel="stylesheet" href="<?php echo auto_version(get_template_directory_uri() . '/css/main.css'); ?>">

And you should see this in your HTML source:

<link rel="stylesheet" href="/wp-content/themes/ajk/css/main.1361054840.css">

See that 1361054840? That’s a unique identifier. It will change everytime the file changes.

But this isn’t enough, this alone won’t work. This won’t load our CSS at all, because a CSS file with numbers like that doesn’t exist.

Add a rewrite rule to a .htaccess file (Apache only):

# CSS/JS auto-versioning
RewriteEngine On
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]

(Note: I only have (css|js) written on the RewriteRule line there, but you should also cache and cache bust images, webfonts and so forth)

Now when the browser asks for main.1361054840.css Apache will serve the main.css file!

How to: Automatic cache busting in other environments

If you understand PHP and Apache rewrite rule syntax, you can easily port this technique to other platforms. A co-worker recently did this for a .NET project based on the description above:

He created a C# version of the auto_version() shown above
He then created a HttpHandler in C#/.NET for recognizing the unique identifier and serving the actual resource file

Some notes

Build process busting

If you happen to have a build process for your project, changing the asset’s name and updating the URLs could be done in the build phase. No need to waste CPU cycles on-demand, like with the .htaccess method or a HttpHandler. For example, Ruby on Rails has a task for precompiling the assets, which will create “copies” of the asset under a new, unique name.

Hash instead of timestamp

Google’s guide for optimizing the cache tells you that a hash is more reliable than a last modified timestamp. The timestamp method is easier to implement, but timestamps can be wrong on different systems, or may not even get updated when you deploy, or update, or whatever… So if you want to go pro, you should definitely use a hash instead of the last modified timestamp. My auto_version() is just a simple example and it gets the job done for me.

Query strings

Some people suggest adding a query string to the resource URL. Like here:

<link rel="stylesheet" href="/css/styles.css?v2">

Or:

<link rel="stylesheet" href="/css/styles.css?1234567890">

This will definitely bust the cache, but it might have some unwanted consequences: atleast some proxies will not cache URLs that have query strings in them.

Summary

Pretty much every website should be optimized for speed. Especially considering the rising mobile devices usage these days. Browser caching is one of the ingredients for speed, but it creates the problem of “how-to invalidate the cache”. And this is easy: rename the cached resources & optionally automate this renaming.

I’m happy to take on any critique, comments, suggestions and the sort! Send me a tweet or comment below.