jQuery on Rails and Addressing CSRF Issue

It seems that rails 3.0 has some vulnerabilities when it comes to cross site forgery protection. To that end, all ajax requests that are made without a csrf token results in the user being removed from the session. In order to address this in rails with jQuery the following steps can be followed:-
1. Add the csrf meta tag in your layouts - <%= csrf_meta_tag %>
2. Download and add the rails.js from https://github.com/rails/jquery-ujs.
3. Replace <%= javascript_include_tag ':defaults %> with <%= javascript_include_tag 'jquery-1.5.1', 'application', 'rails' %>
4. Add jrails gem into your GemFile or environment.rb file.
This should get forgery protection ajax working.

Drivers of Project Success

Recently I delivered my first project as an "architect". What made my day was that it was possibly the smoothest project that I was involved with. Even my project manager thought so (hopefully, as I shall be sharing this blog with him) and asked me to list down a few things that made this project smooth. Below is the list I came up with:-

• The project is only as good as the requirements and requirements translation and in this the product owner team plays a big part. We were most fortunate in having the most responsive and accommodating product owner to whom I attribute most of the success.
• A near symbiotic relation between the development and product owner team based on trust where they anticipate and not second guess the needs of one another.
• Valuing time and time boxing all activities which include adhering to tight time lines during meetings and following an agenda.
• Understanding all failure points before hand - security, infrastructure, personnel etc and planning ahead for them.
• Automating all repetitive activities to the extent of pushing them to the users' control as this ensures that users are not frustrated in waiting for a response from other teams like support.
• Having access to all environments including production so that changes could be pushed out on the fly. We did not have this one but I often wished for it ;)
• Which brings me to my last point - effective communication - which binds all the above points.

So, here's hoping that I am part of many more projects that go as smoothly as this one. (Touch wood)

A Confirmed Java Developer Moving to Ruby

Like many Java developers, I finally made my jump onto the Ruby bandwagon last week. Before that, I was a through and through Java developer who used to liken Ruby to a Toyota compared to the Rolls Royce called Java. Just to bear in mind, I meant no disrespect to Ruby. What I just meant was the comparison (unflattering to some) simply meant that Java was more configurable and took longer to get up and running to the convention over configuration approach taken by Ruby on Rails and Toyota.

However, the last few days have been quite a revelation. I found that Rails and Ruby combined to give a rather neat package which allowed enough freedom to express oneself and at the same time ensured that minimum code was written. I shall not bore hardened Rubyists by eulogizing the various characteristics of Ruby as they know them much better than me but would like to say that I find myself privileged to join their ranks.

The one thought that struck me in the last few days is that the single most time consuming task in web development is getting the user interface working perfectly and herein lies the crux of the problem. It makes no distinction between java and Ruby and generally drives the developer to pulling his hair out in frustration. Fix something in IE and it breaks in Firefox or Chrome and if one does the same in Firefox, IE breaks and this vicious cycle continues. At least we have some control over javascript with frameworks like jQuery. Thus, according to me, the true renaissance of the web development cannot happen unless a framework for html and css can be developed which takes care of all the "mundane" activities like browser compatibility.

So, for now, bye from a novice Ruby developer stage -1.

How can a production like environment be simulated in QA?

Recently we redesigned a Java/J2EE application to perform better. We did the following:-
1. Followed ySlow recommendations.
- Moved static content to an asset server.
- Added configurations to gZip and enabled expiry headers.
- Minified and combined js and css files using Closure compiler.
2. Removed the older Dojo Ajax framework and used jQuery which uses chaining and caching for faster DOM parsing
3. Removed middle tier service applications.
4. Removed Websphere Portal Server and used Websphere Application Server.
5. Reduced size of JSPs by removing whitespaces.
6. Cached DB data into an optimized schema for the application.

However, after deployment stability/performance issues increased. It seems that there were too many database materialized views being refreshed(some from previous applications and some introduced by the new application) that the database server was unable to cope with the load.

Before going live, the system was tested rigorously in QA:-
1. Load testing with 100 user load.
2. Performance testing across geographies.
3. Integration testing by starting other applications in a QA that were sharing the same infracture.

However, there were obvious gaps in our simulation of production in QA -
1. All back end jobs were not running in QA.
2. Even though the other applications were up and running, they were operating on no load.
3. The QA infrastructure is inferior to production (less RAM, lesser number of servers, etc.).

Which brings me to the questions, "how can a production like environment be simulated in QA?"