Beyond Ruby

Jakob Mattson from Burt talked about his view on Ruby as a language. Ruby is often titled as a fully dynamically typed language. Something the speaker wouldn’t  totally agree upon. Especially when it comes to the dynamic features. He made his point clear and we all could agree that everything in Ruby isn’t dynamic. He did also bring up the false assumption that everything (really everything) is an object in Ruby. For instance the “end” statement or the booleans operators (also referred to as “Chuck Norris” operators) aren’t object therefor almost impossible to overwrite their behavior.

I liked the fact that someone had the curage to share a rather critical opinion after lots of Ruby embracing. New programming languages often arises from frustration over the current available ones.

Mountain Dew and My Trail of Tears

Aaron Patterson more commonly known as @tenderlove held a real entertaining talk. This man knows how to get every single person in the audience attention during the whole talk. The topic was legacy code and what methods and techniques that can help us dealing with this phenomena on a regular basis.

Overall it was good stuff. A few notes that stuck:

• Appending the “w” flag when using the Ruby binary will output warnings. Ruby 1.9.3 will even inform you when there’s unused variabels in your code(!).
• The “I” flag lets you specify the load path when running the Ruby binary from your console. Comes handy if you for instance want to overwrite some dependencies with your own code.
• Aaron uses pure Ruby to mock objects during testing.
• Deprecation warnings should be omitted if the $VERBOSE variable isn’t present.

“Legacy”

Chad Fowler a respected and well-known person from the Ruby community did also talk about legacy. But from a totally different perspective.

Legacy isn’t by all definitions a bad thing. Legacy also means inheritance, gift or benefaction. Take Beethovens symphonies for instance. They’ve been around for ages by now and can therefor be classified as legacy by all means.

Keeping this definition in mind how do we then make software that stick? Statistics tells us the chances your code will still be around after a five year period of time is close to zero. Definitely worth thinking about.

Also worth mentioning. Nordic Ruby was one of the first conferences I attended that did have a fully mobile optimized website. It’s even responsive! Strangely enough this isn’t as common as you might assume.

Thanks to all the folks that made Nordic Ruby possible. I will definitely be back next year!

I arrived yesterday and went straight for a run in the beautiful Slottsparken. Sadly enough I got to tired and had to skip the preparty. Instead I spent some time hacking CoffeeScript which I recently became very found of.

Below is a short summary of some of the talks that I found interesting.

GitHub Flavored Ruby

Tom Preston-Werner, one of the founders of GitHub, talked about various techniques used internally at GitHub in order to avoid complexity. Which most often tend to grow into a invincibly battle when dealing with software development in general.

Most of techniques is essentially about opposing the Waterfall model or “cowboy coding” as Tom put it.

One technique I did find interesting was Readme Driven Development. The idea is basically to start of with the readme of your project. Which if often is the initial encounter for your end-users who’s starting to dig into your project.

Tom also mentioned TomDoc (named after Tom himself) which I hadn’t heard of before. Finally a “non-bullshit” specification for writing code-level documentation with humans and not machines in mind. Similiar specifications like RDoc or phpDoc is a good thing but it forces you to use this strict grammar in order to make it parser friendly. Just like one of the essential foundations of Ruby TomDoc puts the human in center of attention.

Some trivia about Tom to round of. He’s also the creator of Semantic Versioning which I adopted in almost all of my work by now.

As you might concluded Tom’s and GitHub’s contributions to Open source is by far extremely impressive.

The Limited Red Society

Joseph Wilk from Songkick held an inspiring talk on the subject of testing. Where the “red society” is a reference to failing tests. He mentioned and demoed a few tools that can help you gather better insight about your test suite. And especially help you find the pitfalls who either tends to fail most often or consume most of your time.

Rounding of with a quote from the presentation which I found real compelling: “to measure is to know“.

Lightning Talks

The first day ended with five minutes talks from a bunch of attendees. This was probably the hilight of the day.

Stephen Sykes help a entertaining talk on obfuscated code and showed of some crazy Ruby one-liners. Great fun!

Nikolay talked about what he thought started out as a bad idea. Namely to give all developers on a project the ability to deploy at any time. Doesn’t sound to bad does it. Well let me put you in to context. We’re not talking about a regular site. We’re talking about WordPress.com. Severing around 6 000 000 pageviews a day. Now you might start to realize why this is considered being a bad idea.

One prerequisite to even make this possible in practice is speed. Since the code needs to be deployed to around 1000 servers. This was simply solved by not running any kind of tests before deployment. For any Ruby developer this is considered pure madness. To spice things up he did also confessed that their only using one branch for all their code.

But even how paradoxical this might sound it turnes out this is one of the best decisions made at WordPress.com. Due to the rapid deployment cycle their able to test their code live and get instant feedback. Since deployment occurs that often the changes are quite small and bugs are therefor most often easily to track down.

Last but not least. Ruby is definitely hot stuff. Everybody seems to be hiring.

I decided to create a service called lastcred.fm. With the following tagline: last.fm without shame. Since I think we all at some point get ashamed of our last.fm profile lastcred.fm is here to help. The service simply lets you scrobble music from a given set of genres. I highly recommend you giving it a try and save your cluttered last.fm profile!

Built using my favorite framework Ruby on Rails and hosted on Heroku.

Last but not least thanks to Adrian for helping me out with the design, Jonas for coming up with the tagline and Johan and Roel for organizing a splending Music Hack Day.

The presentation was held at a company called Improove. I came in contact with the company through @andk. A friend of mine. Improove invites speakers on a montly basis to talk about web related topics.

The presentation hilights a selection of features I became very found of in Ruby. All in all the presentation went well and I hopefully inspired a few to start digging into the world of Ruby.

This year I decided to donate a total of $300 to two people I think have embraced and contributed to the world of open source in a outstanding way. It ain’t that much but hopefully something.

Ryan Bates

Ryan is the author of a fanatstic resource called Railscasts. Every week a new screencast if being released where Ryan covers something from the world of Ruby on Rails which he finds interesting. By now almost 250 episodes have been released. Therefor the chance of that gem or functionality you’re seeking isn’t yet covered by Ryan is close to nonexistent.

FUEL PHP5 Framework

The FUEL framework is definitely the most promising PHP framework out there. I’ve spent quite an amount of time working with CodeIgniter during this year. Don’t get me wrong I really like CodeIgniter but once I tried Ruby on Rails I’ve been looking for something equivalent written in PHP. FUEL might be the answer to my prayers.

Almost all my work I do for my clients are based upon open source tools. Contributing back is an important matter of keeping this ecosystem healthy and fair. I’m not asking you to donate cash. But giving somekind back is a nice gesture especially since it’s christmas.

I’ve borrowed Ryan Bates list filled with ideas on how to contribute back to open source. Slightly modified.

Start of by choosing one tool or solution you’ve been using alot during the last year. Contribute back by:

• Making a donation.
• Fixing a bug.
• Adding documentation.
• Or simply thanking them.

Go out there and start contributing back to open source!

The image in this post is borrowed from Jen.

As stated above the wrapper now uses the OAuth 2.0 protocol instead of 1.0. The new shiny updated protocol is in my opinion a huge step forward and the authentication flow isn’t that much of a hazzle anymore.

The wrapper has been written with PEAR in mind and can easily be distributed as a PEAR package. The PEAR coding standard is also adapted.

Also worth mentioning is that most of the code is now covered by unit tests which makes maintaning and contributing to the project a more gentle matter.

Check out the new demo application or go grab the updated wrapper over at GitHub.

Happy hacking!

Image borrowed from Anders Pollas.

I’ve been doing deployment using Git for a while by now. But I find Capistrano more flexible and reliable. Since Capistrano is intended to be used with Ruby on Rails it doesn’t work with other platforms “out-of-the-box“. But magic can still occur with a few lines of code.

Below you’ll a “step-by-step” tutorial on how the get started using Capistrano for easier deployment. The whole idea for this post came in mind during a Capistrano setup for a Codeigniter application I did recently. But I don’t see why this deployment process wouldn’t be applicable on any other platform or framework.

This tutorial assumes you already got your code hosted using either SVN or Git. You preferaly have setup public ssh keys between your computer and the server you’re deploying to. You’re using the same directory structure as below for your applications on your server (feel free to change the Capfile in order to match your existing structure).

/var/www/example.com
/var/www/example.com/www.example.com
/var/www/example.com/www.example.com/logs
/var/www/example.com/www.example.com/public

Start of by installing Capistrano on your computer. Capistrano is distributed as a Ruby gem.

$ sudo gem install capistrano

Next up clone my default Capfile (Capistrano config file) using cURL. Or use the Gist below.

$ curl "http://gist.github.com/raw/353124/ceda1eccacee7604d7180b23ff20cb618cb760af/capfile.rb" > Capfile

There are some variabels you need to change in order to make this Capfile work with your setup. Basically look through all lines that begins with “set” and change the corresponding value. Also make sure to change the server domain on line 10.

A typical Capistrano deployment is loaded with different kind of tasks. Since Capistrano is awesome it allows you to setup own tasks and even overwrite existing tasks.

As mentioned earlier Capistrano was invented with Ruby on Rails in mind, therefor we need to overwrite a few Rails specific tasks (migrate, restart, start). These default tasks are probably not compatible with your application. But feel free to rewrite them if needed.

As you might noticed by now the task “copy_config” inside Capfile isn’t a default task. My Codeigniter applications usually include some setup specific config files that shouldn’t be included in the repository by obvious reasons. For instance a config file including all necessary MySQL credentials. Therefor these files needs to be setup and edited manually in order to get the application running. But there’s one problem using this method with Capistrano.

Everytime you deploy using Capistrano a fresh copy of your latest application is being cloned/checkout from the repository and stored inside a new folder on the server. Since Capistrano doesn’t proceed from the previous deployed release all files that isn’t included in the repository will not be moved to the new deployed release folder. But no worries! Since Capistrano allows us to hook up our own tasks to specific events during deployment we can solve this problem with ease.

The task namned “copy_config” is being executed right after the “symlink” task. Right after the new release directory has been created and linked to the current directory. Since all my necessary config files are included in the “.gitignore” file we can use that as a reference and simply check if the file exists in the previous release folder. If so simply move the file to the newly created release folder. Capistrano provides some nifty variabels such as “previous_release” and “latest_release” to make this operation easier.

Any other needed operation to get your application up and running should probably be executed after the “symlink” task.

Once your Capfile is done it’s time to run a initial setup deploy. Start of by running the following command.

$ cap deploy:setup

You should end up with a similar directory structure on your server.

/var/www/example.com/www.example.com/public/releases
/var/www/example.com/www.example.com/public/shared
/var/www/example.com/www.example.com/public/shared/log
/var/www/example.com/www.example.com/public/shared/pids
/var/www/example.com/www.example.com/public/shared/system

It’s finally time to perform a first initial (cold) deploy of your application to your server.

$ cap deploy:cold

Congratulations! You just performed your first deploy using Capistrano. For future deploys the cold task isn’t necessary. Simply execute the command below.

$ cap deploy

Easy enough don’t you think?

This post should give you a brief idea of the Capistrano workflow. And show how you can hook up your own tasks in order to get your application up and running. I can’t guarantee that this method can be applicable on your application. As the title states “… almost anything“.

Interested in learning more about Capistrano? Here’s a few posts that I stumbled across and found interesting during research for this post.

Photo credit: heyskinny

Many older phones suffer from the lack of JavaScript support. Which in some cases makes it more complicated to track the user. But running the tracking service server-side will solve this problem easily.

As mentioned earlier Google does offer a server-side solution for Analytics. Sadly enough the documentation is almost non-existing and the only thing provided is some crappy PHP example code to get you started.

Therefor I wrote a simple class in PHP used for interacting with the server-side solution for Analytics. The logic and flow is provided by the existing example code. Below you’ll find a brief description of the “flow“.

A user comes to your site and the url function will generate an uri with all mandatory parameters included. This uri is will be included in the src attribute inside an img element. The browser will then request the uri believing that it’s an image. The uri will actually be pointing to a executable script. In this script the track function is called. A unique visitor id will be generated and stored inside a cookie. An HTTP-request will be sent to Analytics including all kind of parameters in order to track the user. When the request is done a 1×1 GIF image will be severed in order to satisfy the browser.

The method described above is a quite common way of solving lack of JavaScript related problems.

In order to start using this tracking method you’ll need to create a new Analytics profile for your website.

• Create a new profile.
• Select “tracking for a new domain” or new subdomain if applicable.
• Click on the “Advanced” tab and choose the mobile option.
• Copy your new Analytics ID from the textarea (MO-XXXXXX-XX).

The code is available on GitHub so feel free to fork away! There’s also a demo included in the repository. Should be just enough to get you started.

To all CodeIgniter fanboys out there. The class works perfectly as a library in CodeIgniter. You just need to make sure to include the uri generated from the url function inside your view. And then point it towards a function in your controller which executes the track function. See the demo inside the repository for further reference.

Happy accurate tracking!

Photo credit: Antonio Manfredonio.