RoR Currents and Tides
I had a puzzling thing happen the other day. After upgrading to Rails 2.3.5, rails was still creating projects using 2.2.3 gems.
In particular, the vendor directory had slinks to the active* components elsewhere. These were created by rails 2.2.3. I hadn's seen this before. Using 2.3.4, there was typically nothing in the vendor directory, save another empty directory called plugin. Why have a bunch of links to core rails components rather than automatically finding the gems? And so started research on the vendor dir.
I learned that vendor is used to freeze the configuration of a project by storing the dependant libs, rather than depending on systems to have the "right" version. Most articles were dated 2005 through 2007. And comments on the blog articles reflected that there were a number of different techniques/opinions on how to make configurations consistent in a project with many developers.
Then found that 2.2.3 automatically creates these slinks. Or if you use -C, the gems are copied from /usr/share/rails into vendor.
I found that "rails" changed the -d option - in 2.2.3, -D was used to specify what kind of database. In 2.3.5 -d specifies the database type. And 2.3.5 has an equivalent of -C, but is now --freeze.
So its March 2010, and in ~3-5 years option flags and the default usage of the vendor dir have changed.
And btw, what started all this is that after sudo gem install in one ssh window does not change the path to rails in a previously opened rails window...
My first takeaway is that the changes would throw me into confusion without being able to google the issues. Second is that RoR is still in a period of fast evolution and it could spell rework when upgrading even minor versions (2.2 to 2.3). I have a strong feeling that the key to being a good RoR programmer is being able to keep up with the flow and whatever gems or practices come with it. Similar to how the tide brings in fish and other stuff in the large volume of water, the RoR tide will carry an entire environment and being able to navigate it will help determine your worth as a programmer. That's my hypothesis anyway...
3.x is going to be a big one, especially for ActiveRecord changes. Most of the interface is different. The 3.2 changes look like a good design, but developers writing code today for 2.x should be aware of the changes in 3.2 to minimize rework.
In particular, the vendor directory had slinks to the active* components elsewhere. These were created by rails 2.2.3. I hadn's seen this before. Using 2.3.4, there was typically nothing in the vendor directory, save another empty directory called plugin. Why have a bunch of links to core rails components rather than automatically finding the gems? And so started research on the vendor dir.
I learned that vendor is used to freeze the configuration of a project by storing the dependant libs, rather than depending on systems to have the "right" version. Most articles were dated 2005 through 2007. And comments on the blog articles reflected that there were a number of different techniques/opinions on how to make configurations consistent in a project with many developers.
Then found that 2.2.3 automatically creates these slinks. Or if you use -C, the gems are copied from /usr/share/rails into vendor.
I found that "rails" changed the -d option - in 2.2.3, -D was used to specify what kind of database. In 2.3.5 -d specifies the database type. And 2.3.5 has an equivalent of -C, but is now --freeze.
So its March 2010, and in ~3-5 years option flags and the default usage of the vendor dir have changed.
And btw, what started all this is that after sudo gem install in one ssh window does not change the path to rails in a previously opened rails window...
My first takeaway is that the changes would throw me into confusion without being able to google the issues. Second is that RoR is still in a period of fast evolution and it could spell rework when upgrading even minor versions (2.2 to 2.3). I have a strong feeling that the key to being a good RoR programmer is being able to keep up with the flow and whatever gems or practices come with it. Similar to how the tide brings in fish and other stuff in the large volume of water, the RoR tide will carry an entire environment and being able to navigate it will help determine your worth as a programmer. That's my hypothesis anyway...
3.x is going to be a big one, especially for ActiveRecord changes. Most of the interface is different. The 3.2 changes look like a good design, but developers writing code today for 2.x should be aware of the changes in 3.2 to minimize rework.