I was going to write a post on this topic but Rands summarised it so perfectly in this must read article. I’ve picked out some quotes that really hit home to me.
On the warning signs,
A decrease in productivity is a great early sign that something’s up, but what you are looking for is any change in their routine. Increased snark? Unexpected vacations? Later arrivals? Earlier departures? Anything that strikes you as out of the ordinary for someone whose day you are familiar with is worth considering.
On “urgent” tasks,
Get this urgent, unplanned task done or make progress on the unmeasurable? The only thing this decision teaches your team is how little you value the cultivation of your people.
On developer flow,
…it’s your job to remember that productivity costs surrounding these micro-tasks aren’t just the 30 minutes necessary to get them done, it’s the context-switching tax involved in stopping their work, preparing for the task, doing the task, and then rebuilding the context regarding the work that floats their boat … progress is not measured in interrupt-driven minutes, it’s blocks of delicious, uninterrupted hours.
Right on the money.
Splitstate.com is the gaming news service that I launched in 2009 and announced here a few weeks later. By using a combination of Ruby and CouchDB I was able to provide a stable and reliable service for over a year with very few tweaks needed. Just looking back at the git log and the server uptime I can see there was a period last year where no work was done on the site for 8 months while I and others were happily using the service everyday.
But all good things must come to an end - a few months ago requests started encountering long slow downs and the application would crash several time a day. It was due to a number of reasons but the main issue affecting performance was the database growing to 3GB and the app not being designed to handle such a large dataset. Partially my fault and partially a fault of the tools I was using I decided to rebuild splitstate once more - harder, better, faster, stronger!
I love CouchDB, I think it’s a fantastic database and it’s a great way to build web services and self contained data driven applications. What hasn’t been so great about using CouchDB is the driver and ODM support. The best way I found to work with it was to write map reduce functions right on the database - not the Rails way at all.
In my day to day work and on other projects I have been using MongoDB a lot more where the ODM support is just stellar. You really can’t go wrong with either MongoMapper or Mongoid as they both have active communities around them and continue to be updated to work with the latest versions of MongoDB and Rails. I went with Mongoid because I’m more familiar with it.
Last time I chose ruby daemons for processing all the feeds and links that need to be sifted through which has turned out to be a very primitive and non-scalable option. Luckily job queues and background processing options have come a long way since then! I chose DelayedJob because it integrates well with Mongoid and Heroku supports it with no configuration needed.
I took a much more modular approach when writing the code this time and was able to learn from the mistakes I made last time. Lots of small methods and anything that needed to hit a remote server I encapsulated as a delayed job. Switching to Mongo allowed me to keep more of the story selection logic in Ruby where it should be so I could throughly test it. I’m much happier with the code now - it’s cleaner, leaner and more maintainable than before.
I did rant about Heroku in my last post but it really is the easiest way to host a rails application. Splitstate 1.0 was running on Linode who are an excellent VPS provider but these days I need something a little more managed so I can just focus on the code. I don’t want to worry about installing packages on the server and heroku’s git based deployment makes it hard to use anything else.
This Is Not The End
The hard work is done, it’s running on production and finding loads of interesting news stories. Of course I would like to do more with splitstate and now it’s running nicely I can build on this a deliver new features and potentially even new sites!
Today Amazon’s US East Coast EC2 servers went down hard, taking with them many popular websites. Our internal application is hosted on Heroku, who provide a layer on top of EC2 for hosting Ruby rack applications, was one of the many effected. Heroku along with countless other hosting providers bill themselves as “cloud hosts” but that term is very lose and open to interpretation.
Amazon can degrade instances when they feel like and provide no easy way to move instances between data centres. Heroku provide excellent features and add a ton of value to the cloud but are really no better when it comes to reliability. They only run instances in the US East Cost data centre and are essentially at the whim of Amazon when it comes to availability.
A true cloud provider would spread instances across as many of Amazon’s regions as possible and even onto other provider’s clouds such as Rackspace.
The promises of the cloud were that it didn’t matter where your apps and data were located - they were just in the cloud! Turns out the current offerings are not even close.
We have been interviewing a fair number of junior/graduate/entry-level developers recently and it can be frustrating when someone with very poor fundamentals sneaks their way into a face to face interview. We came up with a stupidly simple question that we use to filter out these candidates.
Write a method that can add together (sum) all the elements in an array. Assume all the elements are integers. Use any programming language.
Seriously. I was shocked how many people just can’t do this.
If you haven’t checked it out yet I highly recommend watching David Chelimsky’s talk at RubyConf.
Using some great examples he shows exactly what DRY actually means and shows how sometimes refactoring can go too far. A lot of the topics are addressed in the Refactoring Ruby book and you can search your code for the issues mentioned using metric fu.
Dave Hoover writes here about the current lack of Ruby developers available in Chicago. A quick skim through the comments and we can see people chiming in from other cities voicing the same concern. I can definitely relate but here in London it seems there are a lack of good, keen developers across all languages. At my last two companies (Java and Ruby) hiring good people was a major ongoing issue that was always in the back of our minds. The hiring process is not only a major time sync but very depressing when it gets drawn out for months on end.
Here are some of the major stumbling blocks our (very few) candidates have run into. If you are hiring this is a good list of things to look out for and if you are job hunting you need to get this issues nailed down.
Concise Logical CV\Resumé
CVs that don’t make sense, are poorly written or are just too long usually get discarded. If you haven’t spent the time writing a concise, well thought out resumé tailored for the job you are applying for you don’t stand much of a chance. Write it, rewrite it, cut it down and use the god damn spell checker. No Word DOCs - only send PDFs or URLs.
This is often overlooked. In large companies many developers can be easily hide away in their cubicles and just get on with coding without talking to anyone for days. In smaller companies this is not the case and you will need to be prepared for it. Having clear, reasonable, democratic discussions about architecture and code is something we do everyday and you will not get hired if there is the slightest chance that flow could be disrupted.
The key thing here is to not be too opinionated, do not force your beliefs on others and allow the team to reach agreements naturally. You will not win every argument but it doesn’t matter if you can form a consensus.
If you interview with me and you say you don’t care if you work in PHP or Ruby then it’s probably over at that point. Then again if you consider them both exciting languages with great communities and lots happening we can talk further. It’s not about what area you find the most interesting, it’s a question of you engaging and seeking out new technologies and techniques. Always have side projects, the best developers do and I find it odd when people don’t. Being active outside of work is a sign of passion.
This is not a deal breaker but if you do not have a Computer Science degree (or equivalent) you will need to make up for it. That’s either through experience or at more junior levels evidence of existing projects and a clear grasp of the fundamentals. Write code and ship it.
The Silver Lining
Although we are having problems hiring this does present a major opportunity for young developers or people seeking a career change. Learn programming, get really good and deploy some applications. Also if you are looking for a good Ruby programming role in London please get in touch with me.
Capybara is a fantastic way to perform real integration tests on your Rails apps in actual browsers. Anyone can start writing tests (or features) after reading through a couple of examples using the super simple Cucumber tools.
I thought a lot of people would be using Capybara to run their tests in Internet Explorer on remote Windows boxes. Most Rails developers are not running Windows making testing in IE a chore, so any automated way of doing so would be massively popular right? Not really! I couldn’t find much in the way of end to end documentation so I dug through the Capybara\WebDriver source code and eventually got it all working. If you want to get it working in your Rails application it’s actually pretty simple (now I’ve done the research!).
Installing Cucumber and Capybara
First thing is make sure you have the latest Cucumber and Capybara configured in your Rails app. If you have a Gemfile add these dependancies and then run bundle update:
If you’re still adding gems in the environment.rb add these lines there instead:
These were the latest versions of the gems at the time of writing - use these or newer versions. Make sure these gems are installed and then run this is generate your cucumber config:
Feel free to omit the rspec and spork options if you don’t use them.
Testing It Out
I highly recommend at this point you write a Cucumber feature and get it passing. We haven’t configured Capybara for IE yet so this will run using Capybara’s default driver (headless) so you can see if your feature works at all before we even try and get it working in a real browser.
Pick a really simple part of your application (like a login screen) to start with and write a feature for it based on the excellent documentation and then run:
Once you have your feature passing we can move on with the configuration.
Pick a Windows box (XP, Server 2003 or newer) either on your local network, in the cloud or on a virtual machine on your desktop. So long as the box is accessible via the network it depends on your preference which one you go for.
WebDriver\Selenium requires Java so if you don’t have it download it here. You should be able to open up a new command prompt (Start..Run…cmd) and run the java command to see it has installed successfully.
Go to the Selenium downloads page and grab the file selenium-server-standalone-2.0a6.jar (or whatever the latest version is). From your command prompt you should be able to navigate to where the file is downloaded and run:
It should output some logs and let you know its running and awaiting connections.
Hooking Up Capybara to Windows
To get our features running on that box lets switch back to the Rails app, open up features/support/env.rb and after this line:
insert this configuration:
Replace the IPs of app_host and url to the IPs of your Rails app and Windows box respectively.
Watch The Show
Look at your Windows box and you should see the Capybara connect and start to run your tests through IE. With a little luck everything will pass!
Now you can right outside-in tests for every new feature you add and be safe in the knowledge they work in IE. Let me know if you had any problems.
In researching modern ways to perform cross browser integration tests I came across this rather crazy diagram of how everything fits together in the Rails world.
Believe it or not that’s entirely accurate. At least I know we should be using Capybara for maximum compatibility now!
via Martin Kleppmann
While upgrading an old Rails 2.3.5 app to Rails 2.3.9 I came across this error:
It’s very simple to fix as Rails 2.3.9 is just missing the i18n dependancy. If you are requiring gems using the old school way just add it to your environment.rb:
Or if you’re running Bundler, like everyone should be, just add it to your Gemfile and run bundle update:
The recent iOS 4.1 update added the ability to take HDR photos from the iPhone 4 camera app. Last weekend in London we had the Thames Festival which made for a great opportunity to try out the new feature in a low light setting. Here are some of the photos below. You can see the iPhone stores both the regular version (left) and the HDR enhanced one (right).
The rest of the set is up on flickr here. It still doesn’t come close to a real camera. Even a cheap point a shoot would avoid this level of blurring and light streaks. In daylight the camera is great but anything else is a gamble.