Musings on refactoring

I happened to be across the refactoring in ruby book, which is the
adoption of the refactorings book by fowler from java into ruby. On
reading, one thing which strikes you is the fact that refactoring is persistent across languages and platforms. Java is verbose and allows various coding styles and idiosyncrasies which is evident why lot of java programmers churn
out code that is unnecessarily complex. The proliferation of IDEs has also encouraged this malpractice of creating not just sub-optimal but also unnecessarily complex code.

However, finding the same in ruby has traditionally been difficult as ruby, like its japanese inventor has been neat and concise in its apporach, allowing basically for a lot of bang for a small amount of code. However, as the community grows, there is an acute need to maintain the standards in ruby as well as the developer base is exploding exponentially in ruby. In my opinion, refactoring is a practice that every developer needs to apply and enforce amongst their team as a cardinal rule in programming. Applying this context in the updated refactorings book, I feel while using ruby the answers have become more to the point, but at the cost of grossly sloppy code. It could have better demonstrated in a language that is equally neat and offers variety like java. Python obviously springs into mind where at one place there is a C like procedural code and at the other end there are python experts proclaiming the use of pythonic code.

Having the same refactoring into another language feels alien for a while, but then it is a bliss to realize that same problem existed into another language as well, it was just that a learner like me got carried away in the syntactic differences.

At the end of the day, it is the learner who needs to decide what to and more importantly what not to include in the changes to be made in the codebase.

Relax, have fun and Play.. er Learn

Relax Play and Learn is the new mantra.. at least in learning Rails and related web tools used for development.
Maybe its just me, but over the past few days, I am increasingly finding newer and diverse forms of learning web development, especially using advanced frameworks like rails.
Some of these are directed at learning inter-spread with videos that users can learn at their own pace like the rails for zombies and others that focus on user provided content created by users themselves. Then, there are language specific courses like http://www.rubylearning.com .
When I started learning rails, how much I wish that I had access to similar resources as these are godsend for learners; they serve the dual purpose of ease in learning as well as enjoyment for beginners.
As I write this post, I am also casually looking at various websites like peepcode.com that offer much higher quality screen casts than railscasts.com especially for beginners.
What is surprising is that other technologies do not have this type of support, but web application development centered around rails, scripting languages and HTML5, CSS3 and jQuery combined are increasingly finding this support. One can only hope that this type of open and user friendly learning increases its umbrella and allows more technologies into its fold in the near future.

So If you are a beginner or are considering using rails, my humble advice to you is to bookmark these and start when you have some extra/free time.

Book Review: Jump start sinatra

The book is a good starting point for a new as well as intermediate experts having background in developing web applications in ruby.
However, this book assumes a basic level of competency in developing web applications as it is obvious from the very less emphasis placed for discussing over concepts like git, css, javascript and html. Since it assumes that a user knows ruby and has a basic idea if not familiarity with Ruby On Rails, rather than repeating basic information all over again, the focus is more on latest tools such as heroku, sass, coffescript that are more complex, but are more relevant if seen from a point of an intermediate or professional developer.

The book is centered around end to end application development of a sample website and lays emphasis on adding new features over it during the course of different iterations as is done in real life.
Considerable mentions go to deploying the website over Heroku as well as introduction of DataMapper  ORM.
While this incremental approach of building a sinatra powered application makes perfect learning for beginners, lack of pointers related to advanced solutions, tackling issues like setting up environment, debugging, etc are felt as the books usability seems constrained by the simplistic pattern it adopts.

After a high level introduction, a basic website is created, using different views. Next, a basic CRUD functionality with database is exposed and the application is deployed live, this is followed by additional DRY concepts available in sinatra and the book caps off its learning with creating modular sinatra applications and enhancing its functionality by demonstrating a custom framework.

Overall, this is a 150 page neat  and to the point book for people interested in sinatra.

Note: This book has been provided to me for reviewing under the Oreilly Blogger Review Program.

Demystifying DevOps

There has been a lot of noise recently about this 'DevOps' movement. In this blogpost, I present my take on the topic and hopefully, help the reader towards understanding it.

Wikipedia puts this as:
 "DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals."

Image: Wikimedia Commons

However, owing to pressures often within large corporations having plentiful resources at their disposal, it is easy to create a hype around a process that in general, is common sense and at the very best is automation.
Speaking of agile delivery, it is easy to deliver a product in small teams that the big ones. As my experiences go, in my present company the product gets a new release every evening(India time), prior to which the changes made in the release are tested by the commiters of the changes itself before the decision about build is taken. After the release is done, basic testing as well as testing of the new features is carried out. While this is pain staking methodology, this works well as the team size is relatively less, leading to fewer overall changes. As an astute reader would have pointed out by now, what is missing is automation as well as demonstration of scalability - about what to do when the product goes live. Some uneasy questions like these are answered by the DevOps which:

• Focuses on convergence of Development and Operations.
• Minimizes the gulf/barrier between development and production.
• Brings about QA into development.
• Is agile, and strives the processes after development to be agile/flexible
• Required as rapid scaling & uptime of applications is necessary.
• Focus on automation, towards reducing repetitive work

So, where does a software developer like me comes in?
Here's what I typically deal while playing with web applications: Java, ruby and some combination of these thrown in together with the odd php or python based applications. In this recession prone economy, there is a requirement for cutting costs; which can be effectively met by ensuring that developers also stick in charge for the deployment process. As this lean process gains its acceptance, it is obvious that development is going to be easier for operations people and similarly for developers, deployment/production environment is going to reduce its level of complexity.

Where does it affects us ?

For the java developers, the heavy duty work gets 'magically' done by the enterprise servers that we deploy on. As java is built with performance in mind, it is easy to ramp up the scale of operations (tomcat is insufficient, deploy on glassfish, Too many queries, use memcached, database connections are piling, use connection pooling).
However, the (physical) servers over which these applications are deployed in production also need to be profiled and studied.

To run load/stress tests, one needs to have a production environment. These are easily available as Amazon Machine Instances or rackspace or any other myriad cloudproviders, however this costs money and given the increasing hardware capabilities, one can perform similar tasks without using the cloud(and paying for such kinds of testing).

Virtualbox needs no introduction and is a free virtulization tool from Oracle (it was a sun offering earlier). However, for our example, even virtualbox fails out of box as it can only provision a single vm. To enhance its capability, one can use Vagrant, which is a tool for building and distributing virtual development environments. In other words, it is what rvm is for ruby; a manager that lets the user have clean state (of the server) as well as abstracted setup(different server configurations from same set of VMs). Vagrant is primarily a driver for virtualbox vms.

One can work with it on a per-project basis(similar to a version control) and configure it through a plaintext file, Vagrantfile which vagrant uses as a DSL. The nicest thing about it is that it does everything that you need virtualbox UI for, which is really beneficial while running numerous headless servers.
For example:

Vagrant::Config.run do |config|

   config.vm.define :app do|app_serv_config|

     app_serv_config.vm.customize ["modifyvm", :id, "--name", "app", "--memory", "512"]

   end

   config.vm.define :app2 do|app_serv_config|

     app_serv_config.vm.customize ["modifyvm", :id, "--name", "app2", "--memory", "512"]

   end

   config.vm.define :db do|db_config|

     app_serv_config.vm.customize ["modifyvm", :id, "--name", "db", "--memory", "1024"]

   end 
end

This is just getting started with different servers as in real life, you'd need to provision the vms - setup them with useful stuff and services, deploy and run your programs on them. Two of the widely popular tools that deserve a mention are: puppet and chef.
While the documentation and discussions around them typically involve rails, there is no reason why java, and for that matter any other technology stack can not be used.
Puppet helps us chiefly with setting up the stuff; it is not big on automation, but saves us the work of setting up different softwares in a vm manually.
For instance, the following puppet config file sets up apache and ensures that it runs as a service during vm startup:

Exec {

  path => "usr/local/sbin:/usr/local/bin:/bin:/opt:/usr/sbin"

}

package {

  "apache2":

      ensure => present

}

service {

    "apache2"

         ensure => true,

         enable => true

}

Once we've set up our environment, only half of the battle is over as we also need to monitor and report the status of the environment to evaluate the areas of concern in the setup.
Nagios is a wonderful monitoring tool that displays the health of server - which is needed in a headless environment. To use it, we need to build a puppet module and  enable its service and use the nagios server interface on the vm itself to gleam the details of the vm, displayed as services  as well as re-shedule it when needed. To monitor the nagios instance itself, one can use a service like pingdom.

There are various other tools related with setting up of the servers, but would stretch the discussion far from the concept of devopts in practice. Thus, there is a need to resist the urge of going on to cloud, but keep the production environment close to the development environment itself. This would not result in the elimination of cloud as production environments are now predominantly becoming cloud based, but will go a long way in ensuring lesser pains when the product goes 'live'.

Introduction towards using Ruby enVironment Manager

As I have been using RVM for quite a while during recent times, I felt it was necessary to give a quick introduction of it.

Similar to bundler, the dependency management tool, this sort of has become the de-facto method of setting up development environment in the ruby community.

Basically , this is a bundler for the entire ruby platform, or the ruby application stack. By using this, at a given project, we can specify the version of ruby that application runs upon (yes,  even its different ports like jruby and ironruby) and its different gems.

To install, it is recommended that you install from the default location as mentioned from the website itself as the bleeding edge projects tend to migrate and change their locations quite often.

After a single step installation and setup, you can perform different steps, some of which are :


Installation of platforms

rvm install

for eg : rvm install ruby-1.9.3

This will install the given version of ruby platform by fetching its source tarball into your .rvm/archives folder at home location and build that ruby from source

Testing of all platforms managed by rvm

rvm do ruby [filename.rb]

This will run the ruby command on all installed

Selection of an installed platform

rvm use

for eg : rvm use 1.8.7

This searches for an appropriate version of ruby and specifies steps for installation of that version if it is not present in the rvm.

Gemsets

In line with the compartmentalization introduced at platform level, rvm also provides the same at gem level. We can create different 'schemes' containing specified gems of specific version.

The gemsets are namespaces having different combinations of gems. This solves a lot of headache from developers as newer versions can be tried without compromising on stability of existing systems.

Creating gemsets
rvm gemset create 

This creates different gemsets which are used in the following manner :

rvm @[gemsetname]

This sets our current gemset and now we can install any gems that we like using the gem install -v version gemname here.

The version@gemset name is unique and will have these configurations saved.

Using gemsets
After the creation you can load a gemset configuration through:

rvm use version@gemset

rvm use gemset

There are host of other options that we may use, but these are enough to get started (as in git, where the necessary commands are a breeze once we understand its intent). Since I am currently working on only hobby projects based on ruby, I have not used rvm's advanced topics yet. I would update here as I come across other exciting facets of this technology.