Scratching the surface with flask

Python is a strange beast. These days, I am trying my hand at django and right now am trying to do a bit of development in flask. As I was doing web apps in java/ruby before this, it is quite natural for me to compare django with rails and flask with sinatra.
However, I find flask a little bit more verbose than sinatra as it has a little bit more verbose metadata. Check out the following yourself:

from flask import Flask              require 'sinatra'
app = Flask(__name__)

@app.route("/")                      get '/' do
def hello():
  return "Hello World!"                "Hello World!"

                                     end 

 if __name__ == "__main__":
 app.run(debug=True)

To start off with, one of the nice feature is the presence of reloader by default in flask. If I saved the python file with syntax errors, the program crashed in the terminal. This is different with sinatra as it needs to be restarted (sinatra-reloader is not present as a default). The template engine, jinja (rhymes with ninja) is reminiscent of mustache template to an extent. However, instead of yielding within a master template, all the child templates must extend the master template itself.
So far, I have created a simple application that was previously working in sinatra in little over an hour. My initial experience is a tad disappointing with nothing really worthy of a mention. However, it can be deployed to platforms like google app engine that support python or heroku which pretty much supports all open source platforms now.

Book Review: Test Driven Infrastructure with Chef (2nd Edition)

This is the book review of 'Test Driven Infrastructure with Chef (2nd Edition)' by Stephen Nelson-Smith

 This is a book aimed for people interested in chef, which is an automated server configurator. An important thing to note about the book is the amount of easiness and clarity that the author has put in. Even for a person having no knowledge of chef or behavior driven development can feel right at home crafting complex recipes using chef in a development style that instills confidence and clarifies the intention of the generated script.
 The book starts with the philosophy of developing infrastructure as a code in a test driven manner, which is an alien concept for most of people; however as infrastructure as a code continues to become more popular and mature, the takers for this book will increase. In the second chapter, the chef is introduced and its installation and getting started with our development environment is explained. However, the book relies heavily on the wiki as chef is undergoing rapid transformations. In the next chapters, ruby language is explained followed by test and behavior driven development is explained. For any rubyist, there almost nothing new and the contents can be skipped. The next chapter introduces BDD to the user. For someone not having prior knowledge in BDD or tools like rspec and cucumber, this chapter is sufficient to give a high level introduction for the same. Given the scope of the book, the chapter performs its task very well and does not feel too short or long.
The test driven infrastructure framework chapter is where the theory and the concepts detailing test driven infrastructure are explained and in the last major chapter, various tools are introduced which are essential for any person wanting to carry out further development in chef using the approach mentioned in the book. Not only is the TDD and other allied concepts present, but issues like continuous integration also exist, that are a must in any agile team. These exercises are detailed and can be done with a sample chef recipe before using it in production.
Although, I did not follow the entire book and did all the exercises, but the book was nevertheless helpful in providing me with the details about TDD with while doing devops with chef.

Disclaimer: I received my copy of the book in its beta version through the oreilly's bloggers review program.

Scheduling tasks in ruby

Recently, I've been trying to run a ruby service on a rails application. As the application was deployed to Heroku, I first consulted the documentation which mentioned delayed_jobs, clockwork and resque.
Delayed jobs approach offers the least surprise in its setup and works using activerecord (It creates a table in your application). However, the least intrusive way is to use clockwork and as I mentioned in my previous post, it only needs a single config file. But if you are looking for fault tolerant systems, there is a need to dig deeper into various other frameworks as well.
Initially I was a bit hesitant to go the Resque way but I found this really handy offshoot that offered scheduling as well as queuing capabilities for various jobs. Resque scheduler is a solution that offers me with these capabilities.

It To view the redis tasks on windows, first we need to have the win32-process gem as well as specify the resque-web not to fork a process as this is not an *nix os.

rescue-web -p 8080 -r localhost:6789 -F -L

Since I required the jobs to requeue, therefore, I added another job that periodically requeued the failures
(Resque::Failure.count-1).downto(0).each{ |i|
Resque::Failure.requeue(i)
}
In execution of the jobs, Sidekiq forms an important alternative to resque as it offers multi-threaded capability to run the queued jobs based on the celluloid .
To summarize, there are various families of background/delayed/queued job schedulers and it is upto the developer to decide which ones to mix and match.
Update: This blog post at github provides information about the efforts made at github.