Ok, it has been long since my last post (as usual) and I thought I would talk about a new different topic.
I am currently involved working on a web application and I was exposed to a concept of agile programming about a year ago (maybe more, time flies, does it not) and I looked at it and said "Oh yeah! Just a new fad that will go away" and I continued slugging away on my J2EE application (stuff for real programmers, right?). Well it did not go away, quite the contrary and I am now using it.
Just to show you should keep your mouth shut or (as Jean-Jacques Rousseau said: put your work one thousand times on the mill - sound much better in french) I should have thought 1,000 times before saying something. But actually, you did not come here to read my ramblings on my lack of good judgment (or maybe you did, in which case I can suggest a couple really good therapist) so what is this agile programming.
Well, pushed to the limit, which in reality is never attained, it's basically having your client next to you while you develop your application and have him/her give you immediate and continuous feedback. Now, interesting as it may be, this approach is a recipe for never ending projects because giving your client the opportunity to change his mind 100 times is not necessarily productive. Also, unless you are on a time and material contract basis (or employee) it is simply not cost feasible on a fixed price basis.
Although this extreme approach is never used in the real business world (although you could read a good article on O'Reilly Onlamp web site) , you can take a less drastic version and actually invite your client at some crucial points in the application and have him or her give you feedback. The agile programming approach is usually most effective at the very beginning stage of the development when you quickly and effectively demonstrate the initial data abstractions and how to connect them to a web page. You can quickly show how to perform typical create/read/update/delete (or CRUD) operation and this with your client present and giving you feedback.
So far, I have not mentioned the word Ruby nor the word Rails. This is actually the tool I used (and there are lots other but I would say none as popular). Ruby is an interpreted object oriented programming language with loads of really nice features. Rails is a web application framework (like STRUTS/SPRING/JSF etc... on Java) written in the ruby language.
Getting back to the agility effect, ruby on rails (or RoR as it is affectionately referred to by hardened converts which I am not :-) ) (pardon my poetic license with the two closing parenthesis before and after :-)) is a very good tool for implementing an agile programming paradigm. It does this by using convention rather than configuration to do most things. This means that if you follow all of the conventions, you will be able to write very little code to do most things. Now, this is where the agile paradigm fails when you need to deviate from the convention (either by necessity or by ignorance). The necessity may come because you have existing conventions that you must adhere to or that the business problem you have requires it. You may do things without using the RoR (now, does that make me a liar and turn me into a hardened convert?) conventions simply due to ignorance and lets face it, a true scalable business class production web application is not a simple thing and any framework that must support any kind of such application is even more so complex by nature and RoR is such a beast. So ignoring one of the hundreds of conventions in RoR is not a sin to be terribly ashamed of.
Since I do not have more time I will leave this post as is but I will resume this discussion later.
I am currently involved working on a web application and I was exposed to a concept of agile programming about a year ago (maybe more, time flies, does it not) and I looked at it and said "Oh yeah! Just a new fad that will go away" and I continued slugging away on my J2EE application (stuff for real programmers, right?). Well it did not go away, quite the contrary and I am now using it.
Just to show you should keep your mouth shut or (as Jean-Jacques Rousseau said: put your work one thousand times on the mill - sound much better in french) I should have thought 1,000 times before saying something. But actually, you did not come here to read my ramblings on my lack of good judgment (or maybe you did, in which case I can suggest a couple really good therapist) so what is this agile programming.
Well, pushed to the limit, which in reality is never attained, it's basically having your client next to you while you develop your application and have him/her give you immediate and continuous feedback. Now, interesting as it may be, this approach is a recipe for never ending projects because giving your client the opportunity to change his mind 100 times is not necessarily productive. Also, unless you are on a time and material contract basis (or employee) it is simply not cost feasible on a fixed price basis.
Although this extreme approach is never used in the real business world (although you could read a good article on O'Reilly Onlamp web site) , you can take a less drastic version and actually invite your client at some crucial points in the application and have him or her give you feedback. The agile programming approach is usually most effective at the very beginning stage of the development when you quickly and effectively demonstrate the initial data abstractions and how to connect them to a web page. You can quickly show how to perform typical create/read/update/delete (or CRUD) operation and this with your client present and giving you feedback.
So far, I have not mentioned the word Ruby nor the word Rails. This is actually the tool I used (and there are lots other but I would say none as popular). Ruby is an interpreted object oriented programming language with loads of really nice features. Rails is a web application framework (like STRUTS/SPRING/JSF etc... on Java) written in the ruby language.
Getting back to the agility effect, ruby on rails (or RoR as it is affectionately referred to by hardened converts which I am not :-) ) (pardon my poetic license with the two closing parenthesis before and after :-)) is a very good tool for implementing an agile programming paradigm. It does this by using convention rather than configuration to do most things. This means that if you follow all of the conventions, you will be able to write very little code to do most things. Now, this is where the agile paradigm fails when you need to deviate from the convention (either by necessity or by ignorance). The necessity may come because you have existing conventions that you must adhere to or that the business problem you have requires it. You may do things without using the RoR (now, does that make me a liar and turn me into a hardened convert?) conventions simply due to ignorance and lets face it, a true scalable business class production web application is not a simple thing and any framework that must support any kind of such application is even more so complex by nature and RoR is such a beast. So ignoring one of the hundreds of conventions in RoR is not a sin to be terribly ashamed of.
Since I do not have more time I will leave this post as is but I will resume this discussion later.
Comments