Evolution. The name of this blog says it all. We as a company and myself as an individual are evolving. A sea of change is upon us. One change that will have a great effect, is the choice of computer language we use to develop in. Up to this moment, we have mainly been using PHP to do all our development work. It’s a great language, easy to use and relatively powerful. In fact Wordpress, the blogging software that is powering this site, was written in PHP. That being said, it has been somewhat of a hindrance as well (which I won’t get into here).
For our next project, a complete re-writing of our Puck Systems product, we are making the switch to the Ruby programming language, a very powerful object-orientated language with a syntax that is very natural language-ish (IOW, the way in which the code is written is similar to the way in which one would say it in normal, everyday conversation). More specifically, we are making the switch to Ruby on Rails (aka RoR or just Rails), a web-based MVC framework written in Ruby that allows for rapid and agile development with a minimum of tedious configuration.
The reasons why we are making this switch is many-fold, but I will try to lay out one of them here. Increased efficiency is a primary factor in evolution. The more efficient one is, the more work that can be done in same length of time. More work (with all other things being equal) means more code written (ie new features, improving existing product, etc.) or less time that needs to be spent on writing code and more time spent doing something else (id spending time with family, sleeping, working out, hobbies, etc.). How this relates to RoR is this, RoR was conceived and developed by its original creator, David Heinemeier Hansson, with two guiding philosophical principles in mind: “Don’t Repeat Yourself” (DRY) and “Convention over Configuration”. In regards to software development, having multiple pieces of code that do the same thing or perform a similar action is a big no-no. If an error is found or a new feature is added, it has to be changed or added to in each and every spot where the code is repeated. This is incredibly inefficient and also inviting to even more errors cropping up. RoR is written in such a way to discourage multiple copies of similar code from being produced in the first place, thereby making the developer more efficient (and in turn much happier). Another way in which RoR helps the developer become more efficient is in the standard conventions that it encourages one to follow. As long as one follows certain basic conventions in naming things (files, database tables, etc.) and also uses the default setup for file organization, one can reap large benefits in efficiency. The small loss in flexibility will be more than made up for in ease and speed of development.
That’s it for now on our switch to Ruby on Rails. It’s still early, but so far it’s been wonderful working with the Ruby language and the Rails way of doing things. I plan on writing more about it, when I can find some more time. Until then, happy coding!
