I have been reading and working out examples in the book Agile Web Development with Rails, written by Dave Thomas and David Heinemeier Hansson. I discovered rails about 6 months ago and started reading about it. I was fascinated by the simplicity and the ease of development that it offered in quickly putting together a fully functional web application. Needless to say, in just over a year after its creation, it has captured the hearts and minds of programmers and web designers alike.
There are many facets to rails that make it worthy of being the one of the foremost choices in developing web applications, like clear separation of model view controller functionality and in-built testing support - besides the inherent advantage of having a dynamic language like Ruby at its core. However, there is one more rarely-exploited paradigm that it uses that really struck a chord with me - the fact that it stresses "convention over configuration". Rails does not have XML files for specifying the configuration aspects of the application. It assumes certain values and uses those to power the rest of the application.
What does this exactly mean? It means that configuration information is already predetermined by rails and it urges the programmer to name objects a certain way and put files and resources in specific predetermined directories. One would think that this is very restrictive, but the fact is that it doesnt seem restrictive at all when most of it is done by the framework itself! It creates the directories, creates the templates for the files, so that what falls on the shoulders of the programmer is the actual business logic. It is like it says, "Dont worry about maintaining configuration info, I will lay it out and make sure its all in place. You just worry about implementing the requirements in code."
Imagine what this means in terms of application maintenance. A new programmer entrusted with making changes to a rails application coded by another developer already knows where everything is, and how the basic components are named. No flailing around trying to make sense of variable and object names!
It definitely is worthwhile trying out and working on a framework that works on the "convention over configuration" principle. This may not be for all, but is perfect for a framework if it has to be true to its promise of blazing speed in putting together a working application. And Rails does a great job there, no question.
Monday, October 03, 2005
Tuesday, September 13, 2005
The Craft of Classification
Ravi mohan writes another thought-provoking post on this blog in response to the notion of classifying programmers into 3 categories - apprentice, journeyman and master.
I have to admit I was a bit swayed by Pete mcBreen's book when I first read it - mainly because I had read about that idea for the first time. But then Ravi is onto something when he shows how that classification may have no real value. The book talks about a situation where it says its okay for a "master" to learn a new language from an "apprentice" and that this doesnt invalidate him of his current category of "master". How is this possible? A student is always supposed to see himself as lower in that relative situation when he learns something from a teacher.
When Pete McBreen and others advocate this idea, I suspect they have an underlying assumption about the quality of the learning. Maybe they are saying that the master already has the fundamental concepts down(which is a higher quality of learning) and he just learns another language syntax which is of a lower quality of learning. But will this always be the case?
Imagine a UNIX guru in the league of Eric Raymond or Richard Stallman. Lets call him Mr X. He has been working on UNIX for years and written dozens of open-source tools, is very active in communities and is usually approached when his UNIX peers have issues. According to McBreen, he would be a master. Lets say he is hired by a shop that does development mostly in UNIX tools but also have a smattering of applications in Scheme. He starts working with a candidate who has a good knowledge of Scheme but is not active in the public domain (as a result of which he is not well-known). Now, I am sure Mr X will definitely not breeze through Scheme, since its not just a new language - it requires a different way of thinking. Now in this situation, there is a lot of "higher" quality learning involved where the "master" learns from the "apprentice". Whos the master here then?
All my thoughts are based on the following premise:
There are too many varied things in software for them to be grouped into a "general" category that somebody can be said to be good at.
If somebody has sound concepts of OO design, he may be quick to pick up Java, C, C++, C#, etc but it may not be easy to pick up Python or Ruby or Smalltalk. That is to say, it will not be easy to think "the Ruby way". And also by the same token, sound programming concepts in even Python or Ruby or any language will not make you a good webdesigner, adept at CSS, HTML or Flash.
I guess then what can conclude is:
1. The only thing one can categorize a person is with respect to a particular paradigm and/or language ("OO programming", "Functional programming" is a paradigm - "Java", even ".NET" is a language for purposes of explaining). If he has to work on another area he doesnt know, he is a novice there and there is nothing wrong with that fact. So Mr X is a UNIX "master" but an "apprentice" in Scheme. There is nothing wrong with a classification which relates to a particular technology/paradigm/language/framework.
2. The only way to categorize a person with respect to a technology is by seeing his work.
There can be no other parameter. No writings, no talks, or drawing on the board. Now, the question is, how do you know if his work is good? Sadly, it cant be judged right away. This can only be decided over a period of time. Say over a course of 2,3,5 years, how many times was it changed? How easy was it to change? Has he constantly delivered running, "not-getting-in-the-way" software to the users?
After reading McBreens book, I started thinking, "I am an apprentice now..I want to be a journeyman in X years, and then a master in a another Y years." Looks like it wont work. I am now going to say - "I know java and I want to learn Python this year. Next year I will dig into Scheme. And hey, OCAML looks interesting, why not try it after that?" And when I get that job in the Python firm that wants me to maintain some apps in Erlang on the side, I will seek out the "Erlang guy" and become his "apprentice"!
I have to admit I was a bit swayed by Pete mcBreen's book when I first read it - mainly because I had read about that idea for the first time. But then Ravi is onto something when he shows how that classification may have no real value. The book talks about a situation where it says its okay for a "master" to learn a new language from an "apprentice" and that this doesnt invalidate him of his current category of "master". How is this possible? A student is always supposed to see himself as lower in that relative situation when he learns something from a teacher.
When Pete McBreen and others advocate this idea, I suspect they have an underlying assumption about the quality of the learning. Maybe they are saying that the master already has the fundamental concepts down(which is a higher quality of learning) and he just learns another language syntax which is of a lower quality of learning. But will this always be the case?
Imagine a UNIX guru in the league of Eric Raymond or Richard Stallman. Lets call him Mr X. He has been working on UNIX for years and written dozens of open-source tools, is very active in communities and is usually approached when his UNIX peers have issues. According to McBreen, he would be a master. Lets say he is hired by a shop that does development mostly in UNIX tools but also have a smattering of applications in Scheme. He starts working with a candidate who has a good knowledge of Scheme but is not active in the public domain (as a result of which he is not well-known). Now, I am sure Mr X will definitely not breeze through Scheme, since its not just a new language - it requires a different way of thinking. Now in this situation, there is a lot of "higher" quality learning involved where the "master" learns from the "apprentice". Whos the master here then?
All my thoughts are based on the following premise:
There are too many varied things in software for them to be grouped into a "general" category that somebody can be said to be good at.
If somebody has sound concepts of OO design, he may be quick to pick up Java, C, C++, C#, etc but it may not be easy to pick up Python or Ruby or Smalltalk. That is to say, it will not be easy to think "the Ruby way". And also by the same token, sound programming concepts in even Python or Ruby or any language will not make you a good webdesigner, adept at CSS, HTML or Flash.
I guess then what can conclude is:
1. The only thing one can categorize a person is with respect to a particular paradigm and/or language ("OO programming", "Functional programming" is a paradigm - "Java", even ".NET" is a language for purposes of explaining). If he has to work on another area he doesnt know, he is a novice there and there is nothing wrong with that fact. So Mr X is a UNIX "master" but an "apprentice" in Scheme. There is nothing wrong with a classification which relates to a particular technology/paradigm/language/framework.
2. The only way to categorize a person with respect to a technology is by seeing his work.
There can be no other parameter. No writings, no talks, or drawing on the board. Now, the question is, how do you know if his work is good? Sadly, it cant be judged right away. This can only be decided over a period of time. Say over a course of 2,3,5 years, how many times was it changed? How easy was it to change? Has he constantly delivered running, "not-getting-in-the-way" software to the users?
After reading McBreens book, I started thinking, "I am an apprentice now..I want to be a journeyman in X years, and then a master in a another Y years." Looks like it wont work. I am now going to say - "I know java and I want to learn Python this year. Next year I will dig into Scheme. And hey, OCAML looks interesting, why not try it after that?" And when I get that job in the Python firm that wants me to maintain some apps in Erlang on the side, I will seek out the "Erlang guy" and become his "apprentice"!
Wednesday, August 24, 2005
This may work...
I think writing and keeping an online journal does help in quite a few ways. This weblog is to explore, refine, clarify and elucidate ideas in software development - a profession that has helped me earn a living, and by virtue of doing which continuously for a few years, I have developed a deep interest and love for. This interest is the result of a cycle that has been set in motion by a yearning to learn more about it so that one can be better, which in turn infuses in one an enthusiasm to learn more just because they enjoy their achievements attained by learning.
The interesting about this is now I feel that I am in a different plane of existence. Seems like the constant spinning of the cycle has catapulted me into a different mental state, where I feel there is so much more to learn and knowledge seems never-ending. This is different from my previous plane of existence, where I was doing just what was supposed to be done, limiting myself to only knowledge of my specialization.
I must admit that at first, this new mental state left me more insecure, as its like exposing a huge waterfall to a camel thats happy drinking just the small amounts of water available in the desert. But then I realized that it is necessary to see the waterfall so that you can get an idea of how small the desert water sources are. And it is necessary to know that the water sources are small. It is necessary to know that you are ignorant....because only then can you think about achieving mastery.
The interesting about this is now I feel that I am in a different plane of existence. Seems like the constant spinning of the cycle has catapulted me into a different mental state, where I feel there is so much more to learn and knowledge seems never-ending. This is different from my previous plane of existence, where I was doing just what was supposed to be done, limiting myself to only knowledge of my specialization.
I must admit that at first, this new mental state left me more insecure, as its like exposing a huge waterfall to a camel thats happy drinking just the small amounts of water available in the desert. But then I realized that it is necessary to see the waterfall so that you can get an idea of how small the desert water sources are. And it is necessary to know that the water sources are small. It is necessary to know that you are ignorant....because only then can you think about achieving mastery.
Subscribe to:
Posts (Atom)