This is just a quick post to let you know that AppConstants can now be used as gem! Just add it to your Gemfile and 'bundle install' it: #in your Gemfile gem "app_constants" #in the console $ bundle install $ rails generate app_constants #then follow the instructions on-screen instructions It can also be used without Rails. Check out full instructions on the GitHub repository. Feedback welcome :)

I think by now everyone's heard of the hard time the guys up in Queensland, Australia are having because of the recent floods. People have lost their lives and many others have lost their homes and businesses, product of years of hard work. As a result of this massive disaster the Queensland Government decided to run a telethon to encourage donations to help the flood victims. The Telethon aired last Sunday, 09/01/11, on Channel 9 and lasted for 2 hours.

I'm a big heavy metal fan. And so are most of my friends. As a result I launched RottingNames, a band name generator that will generate the most hilarious, nastiest and nonsense names the metal world is yet to discover - ok, that's probably a bit of an overstatement but the idea is good. However, a friend pointed out the code had a bug when running under - gasp - Internet Explorer.

What's the difference between your application's javascript code and its java/ruby/python/whatever code? Think about it for a second. Done? Well, the answer is: none! In today's web applications your javascript code is no different from the rest of your code base but yet we treat it with disregard - and we're all to blame. We often see developers investing time writing all sorts of automated tests around their code base but fail to do the same for their javascript - and yet they get surprised when their client can't click on a button on their web app that depends on that ajax call that has been manually tested once when the page was first released.

It's been now over a week since we moved to Sydney and everything is just great. We're still house hunting but I got a feeling we'll have a home soon. :) In the meantime, this morning I got a feature request on github to allow AppConstants to interpret YAML files with embedded code like this: I haven't needed it myself but thought it would be a nice addition so my latest commit does exactly that.

Now several months after I announced my odyssey to obtain my Australian work visa, the time has finally come! I'll be flying to Sydney next week, April 15th, and as you can probably guess, I'm excited as hell! :) This starts an important new page both in my life and my career, but that's not what this post is about. It's about sharing the experience of living for over two years in Europe.

This will come as no surprise to my closest friends, but I am a long time game development admirer. Although I've never done anything professionally I did spend some time in the past studying this amazingly interesting field - it's my dark hobby. As hardware evolves and gamers demand more and more reality from their consoles, the game development industry is one of the few that basically didn't suffer with the latest economic crisis.

Back in January I announced a small but useful plugin called AppConstants, that basically provides a central place where you can store environment specific constants. And since I started using Rails 3 in the past week, I thought I'd make it Rails 3 compatible. The code is really simple and - as I expected - the upgrade process was quite straight forward. I'm not gonna write a guide here on how to upgrade your plugins to Rails 3 - there is plenty about that around the web - but instead, just show the steps I went through to upgrade mine.

Learning new programming languages is fun. And if it's your 2nd, 3rd...Nth programming language you will eventually look for features you already know and love. Coming from Ruby - but after having done my fair amount of Java for many years, among other things - I end up looking for features like blocks, open classes and syntax sugar like automatic generation of attribute accessors. These are hard to let go of.

What? In Ruby you have basically two ways of defining private methods: I see a small problem with both approaches. In the first one, and the most obvious, is that you need to duplicate the method name as well as add an extra method call - private - just to change its visibility. The second approach avoids this but adds the risk of accidentally putting a method that is intended to be public under the private section of the source file, which can render an annoying debugging session.