So You Want To Be A Ruby Dev(kevingisi.com)
kevingisi.com
So You Want To Be A Ruby Dev
http://www.kevingisi.com/2010/08/09/so-you-want-to-be-a-ruby-dev.html
16 comments
The article is meant to be taken as satire, but do consider that if you're a new developer and you go a'Googling, you're going to encounter JRuby, and Rubinius, and Macruby.
It would be silly to throw all of these items at a new developer, and no teacher in their right mind would ever do that.
But if you're trying to pick up the language on your own...that's what you'll see.
It would be silly to throw all of these items at a new developer, and no teacher in their right mind would ever do that.
But if you're trying to pick up the language on your own...that's what you'll see.
Unless Ruby's your first programming language, I don't see how you can be that astonished by the fact that there are multiple implementations of the same programming language.
> but do consider that if you're a new developer and you go
> a'Googling, you're going to encounter JRuby, and Rubinius, and
> Macruby.
1. Forcibly prevent people from developing new Ruby interpreters, Ruby frameworks, and alternatives to popular Ruby tools.
-- or --
2. Force Google to adopt a old-style Yahoo / DMoz approach to internet search so that a Google employee can sort/categorize all of these things manually for presentation to the user.
The crux of the article seems to be that too many choices can be overwhelming to a newbie, so we should restrict everyone's ability to choose so that inexperienced, new developers don't hurt themselves (or run screaming due to information overload / confusion).
I actually think this is a little unfair.
Yes, the number of choices in Rails has proliferated, but a new user can easily ignore these choices. I don't think the situation is at all equivalent to the Java stack (which is the only other one I can comment on).
To use Java, you probably want to use Maven, Spring for dependency injection, an MVC framework (Struts 2, Spring, Tapestry, etc...), an ORM framework (probably Hibernate, probably with JPA?), though there are other choices.
This blog lists a bunch or Rails/Ruby choices. However, it's important to keep in mind that essentially all of the things a newbie needs to get started with Rails are in a single, self contained framework that is (in my opinion) incredibly easy to use.
I had well over five years of Java experience when I took on the latest in Java-based web framework. A book on Struts 2 covered Spring, but not Maven. A book on Maven covered MVC, but used Spring's MVC. A book on Spring MVC used Ant for the build, not Maven. Ultimately, I had to spend a great deal of time researching these technologies to just get my first simple app up and running. You should spend some time getting to know your framework and not just rely on magic. But should you have to do this for weeks or even months before you can write a simple webapp?
For rails... well, there's absolutely no need to worry about JRuby, IronRuby, or Ruby Enterprise, and whatever tutorial you're doing on Rails will tell you what version of Ruby you need. You don't need to download any of that windows crap mentioned here. You can ignore Sinatra for the time being. Gems are utterly simple to use (try adding a Maven dependency some time, especially one that doesn't have a public repo). You don't have to download any database to get started with rails, but you will have to spend a lot of time figuring out how to configure applicationContext.xml in Spring (or however you decided to go about it).
In fact, I think you can be a successful web apps developer with Rails and never bother with anything other than the basic defaults (ok, you'll want to use a different database).
Ok, I realize I've been ranting. But there's a huge difference between a proliferation of choices that can be ignored, and a proliferation of choices that have to be understood and dealt with before you can write your first app.
Yes, the number of choices in Rails has proliferated, but a new user can easily ignore these choices. I don't think the situation is at all equivalent to the Java stack (which is the only other one I can comment on).
To use Java, you probably want to use Maven, Spring for dependency injection, an MVC framework (Struts 2, Spring, Tapestry, etc...), an ORM framework (probably Hibernate, probably with JPA?), though there are other choices.
This blog lists a bunch or Rails/Ruby choices. However, it's important to keep in mind that essentially all of the things a newbie needs to get started with Rails are in a single, self contained framework that is (in my opinion) incredibly easy to use.
I had well over five years of Java experience when I took on the latest in Java-based web framework. A book on Struts 2 covered Spring, but not Maven. A book on Maven covered MVC, but used Spring's MVC. A book on Spring MVC used Ant for the build, not Maven. Ultimately, I had to spend a great deal of time researching these technologies to just get my first simple app up and running. You should spend some time getting to know your framework and not just rely on magic. But should you have to do this for weeks or even months before you can write a simple webapp?
For rails... well, there's absolutely no need to worry about JRuby, IronRuby, or Ruby Enterprise, and whatever tutorial you're doing on Rails will tell you what version of Ruby you need. You don't need to download any of that windows crap mentioned here. You can ignore Sinatra for the time being. Gems are utterly simple to use (try adding a Maven dependency some time, especially one that doesn't have a public repo). You don't have to download any database to get started with rails, but you will have to spend a lot of time figuring out how to configure applicationContext.xml in Spring (or however you decided to go about it).
In fact, I think you can be a successful web apps developer with Rails and never bother with anything other than the basic defaults (ok, you'll want to use a different database).
Ok, I realize I've been ranting. But there's a huge difference between a proliferation of choices that can be ignored, and a proliferation of choices that have to be understood and dealt with before you can write your first app.
It's easy to paint everyone's experience with your own isn't it?
I answer questions from people new to Ruby a lot (given that I wrote one of the few and the earliest introductory books for Ruby that's free) and they are VERY often the exact questions he mentions here. Maybe people are too lazy to find the answers. Maybe they're utterly immobilized by a new tech stack that has a lot of choices. Maybe they just aren't as smart as you are. Whatever it is, we really need to find a simple way to address these questions. I think a lot of them are already addresses through blog posts, and as you mentioned, through the tutorial you're following, but a lot of them aren't (and sometimes they're answered incorrectly due to the age of the content or simple ignorance on the author's part).
Let's not pretend these people don't exist just because you aren't one of them. Many people do have to deal with this stuff up front due to the nature of the work they plan to do with it, and if the information isn't accessible, they'll just move on to somewhere it is.
I answer questions from people new to Ruby a lot (given that I wrote one of the few and the earliest introductory books for Ruby that's free) and they are VERY often the exact questions he mentions here. Maybe people are too lazy to find the answers. Maybe they're utterly immobilized by a new tech stack that has a lot of choices. Maybe they just aren't as smart as you are. Whatever it is, we really need to find a simple way to address these questions. I think a lot of them are already addresses through blog posts, and as you mentioned, through the tutorial you're following, but a lot of them aren't (and sometimes they're answered incorrectly due to the age of the content or simple ignorance on the author's part).
Let's not pretend these people don't exist just because you aren't one of them. Many people do have to deal with this stuff up front due to the nature of the work they plan to do with it, and if the information isn't accessible, they'll just move on to somewhere it is.
"Let's not pretend these people don't exist just because you aren't one of them."
I assure you that I am one of them. I'm probably one of the people whose questions you helped answer on a discussion forum.
The part where I am, as you said, painting everyone's experience with my own is comparing Rails to a Java based web programming stack. Someone coming from PHP, for instance, might find it kind of difficult to use a framework that (essentially) can't be used without some knowledge of OOP, MVC, and so forth (as opposed to just putting some things up on a page). Sure, there's a learning curve.
But the "immobilization" you mentioned happens in degrees. Yes, it always takes some work to get up in running, because programming isn't easy. However, I don't think that the range of choices immobilizes a new programmer in Rails to anywhere near the degree that it does in the Java world.
So while I would agree that I have a particular angle that isn't necessarily shared by everyone struggling with rails, I don't think that my experiences are unusual for a programmer with experience in Java who has gone through the learning curve on web app development in Java and Rails.
I assure you that I am one of them. I'm probably one of the people whose questions you helped answer on a discussion forum.
The part where I am, as you said, painting everyone's experience with my own is comparing Rails to a Java based web programming stack. Someone coming from PHP, for instance, might find it kind of difficult to use a framework that (essentially) can't be used without some knowledge of OOP, MVC, and so forth (as opposed to just putting some things up on a page). Sure, there's a learning curve.
But the "immobilization" you mentioned happens in degrees. Yes, it always takes some work to get up in running, because programming isn't easy. However, I don't think that the range of choices immobilizes a new programmer in Rails to anywhere near the degree that it does in the Java world.
So while I would agree that I have a particular angle that isn't necessarily shared by everyone struggling with rails, I don't think that my experiences are unusual for a programmer with experience in Java who has gone through the learning curve on web app development in Java and Rails.
"Whatever it is, we really need to find a simple way to address these questions ... they'll just move on to somewhere it is."
Really? Java is worse in this regard! C# even worse since you have to use mono if you aren't on windows and mono isn't 100% up to date with C# from MS. Python is very similar to ruby on this front, lot's of choices. PHP is well PHP.
I still think ruby in the best in this regard. install 1.8.7, gem install rails, but the agile rails book, start coding. A lot of the stuff in this article is just noise that no one needs to think about. In fact, there is a giant 'getting started' link on the rails site which answers this question pretty well.
http://rubyonrails.org/download
I'd still like an example of where else some one would go to find a greener pasture.
Really? Java is worse in this regard! C# even worse since you have to use mono if you aren't on windows and mono isn't 100% up to date with C# from MS. Python is very similar to ruby on this front, lot's of choices. PHP is well PHP.
I still think ruby in the best in this regard. install 1.8.7, gem install rails, but the agile rails book, start coding. A lot of the stuff in this article is just noise that no one needs to think about. In fact, there is a giant 'getting started' link on the rails site which answers this question pretty well.
http://rubyonrails.org/download
I'd still like an example of where else some one would go to find a greener pasture.
A lot of it is noise, absolutely. But while I wrote this as satire, it's based on the experiences I've seen from new developers. If you didn't know any better, it could be easy to think that Rails devs all use Rails 3, are completely swept up in the NoSQL movement, and don't have libraries that will run on Ruby 1.8
Really this article was designed to point out that an overabundance of choice - even though they're great choices - can be harmful to new developers. And people should consider joining things like RailsMentors.org right now. Because more than ever, this is a time where one-on-one mentoring is all but necessary.
As far as greener pastures...I'd hate to see the day when any community measures itself by comparison to other communities, rather than on its own accomplishments.
Really this article was designed to point out that an overabundance of choice - even though they're great choices - can be harmful to new developers. And people should consider joining things like RailsMentors.org right now. Because more than ever, this is a time where one-on-one mentoring is all but necessary.
As far as greener pastures...I'd hate to see the day when any community measures itself by comparison to other communities, rather than on its own accomplishments.
"'d hate to see the day when any community measures itself by comparison to other communities"
most value judgements can only be made relative to other like things.
most value judgements can only be made relative to other like things.
It's important to distinguish between Ruby and Rails. The setup and configuration of Ruby hasn't increased in complexity much over the last few years. (Keep in mind you don't have to use Bundler to use Ruby; Bundler is used in Rails 3).
Back in 2005/2006, it was easier to install Rails. There were less choices which made configuration and setup easier (but which also meant you could do less).
Now Rails has matured and has a large community. There are more features, more Rails-related gems, and the architecture has more choices and moving parts. As a result, you can do more with Rails now, but the learning curve and setup costs are stiffer.
Back in 2005/2006, Rails had a reputation of being easy to set up and dive into. Even though that's no longer true in 2010, the reputation for being easy to pick up has stuck.
Here's a glimpse of how it was "back in the day": http://www.garbett.org/blog/?p=88
Back in 2005/2006, it was easier to install Rails. There were less choices which made configuration and setup easier (but which also meant you could do less).
Now Rails has matured and has a large community. There are more features, more Rails-related gems, and the architecture has more choices and moving parts. As a result, you can do more with Rails now, but the learning curve and setup costs are stiffer.
Back in 2005/2006, Rails had a reputation of being easy to set up and dive into. Even though that's no longer true in 2010, the reputation for being easy to pick up has stuck.
Here's a glimpse of how it was "back in the day": http://www.garbett.org/blog/?p=88
Back in 2005/2006, Rails had a reputation of being easy to set up and dive into
Almost entirely based on DHH's 15-minute scaffolding/TextMate blog demo. It was a brilliant marketing move that arguably put Rails on the map, but the problem was that it gave the impression that Rails was somehow "easy" like PHP and suitable for casual web tinkerers.
The fact that things are more complex now tells a truer story: if you want to do any serious work with Rails you need to be prepared to dive deep into Ruby. When a meta-programming bug strikes you can't hide behind even the most elegant DSL.
Almost entirely based on DHH's 15-minute scaffolding/TextMate blog demo. It was a brilliant marketing move that arguably put Rails on the map, but the problem was that it gave the impression that Rails was somehow "easy" like PHP and suitable for casual web tinkerers.
The fact that things are more complex now tells a truer story: if you want to do any serious work with Rails you need to be prepared to dive deep into Ruby. When a meta-programming bug strikes you can't hide behind even the most elegant DSL.
You could write the same article for most in-depth subjects.
Want to try model airplanes ? Get ready to spend a couple of days just to figure out the various materials, radios etc
Want to try computer assisted music ? Which plugin ? Which host ? How do I write music with this, etc ?
You could even rewrite the article for Java a few years back at least (should I go WebLogic ? WebSphere ? TomCat ? Struts or something else ?).
Want to try model airplanes ? Get ready to spend a couple of days just to figure out the various materials, radios etc
Want to try computer assisted music ? Which plugin ? Which host ? How do I write music with this, etc ?
You could even rewrite the article for Java a few years back at least (should I go WebLogic ? WebSphere ? TomCat ? Struts or something else ?).
i think the deal is that it wasn't like this for ruby before.(and it still really isn't, but rails has grown exponentially)
It's been like this with Ruby since certain developers have been pushing harder for 1.9 adoption. A new developer is gonna pick the higher version number, cos higher version means newer. They're then gonna wonder why some gem doesn't work :)
to be fair, there are lots of very real advantages to 1.9. the development community finally seems to have collectively decided to take the plunge, and let the gems catch up, rather than waiting around on 1.8 forever.
While I don't _disagree_ with this... it's the place the Ruby community has chosen among the 'stability vs. innovation' continuum. The Ruby community may be a bit chaotic, but it also innovates and iterates really fast.
I also choose to use Arch and not Debian on my computers. Such is life.
I also choose to use Arch and not Debian on my computers. Such is life.
Also it's worth noting that the core ruby language moves quite slowly. It's just Rails and the gem ecosystem that moves a maddening pace.
It moves pretty quick in comparison to other languages though, and I rather think the versioning system is a bit weird as 1.9 broke backwards comparability enough that quite a few ruby libraries and programs are still only functional on 1.8 without editing source
7 years between point releases?
Exactly. The Ruby community likes to experiment and it's a bit hyperactive. Personally I quite like it because of that.
That said the article was a bit of a stretch both in the example it used, and in particular the fact that the Ruby world is currently undergoing a big shift. I would imagine one year from now a lot of those choices will be gone (e.g. Ruby 1.9.1 or even 1.8.x, Rails 2.x and maybe some of the less popular Ruby implementations).
But the general principle is correct: the Ruby community likes to try, change, play with new frameworks and ideas. If you hate the principle, then maybe Ruby is not for you. Or maybe in true Open source philosophy, you can make a simpler installer, or get someone else to do it. Then you'd have made the Ruby world a better place, and we'd all thank you for it. :)
That said the article was a bit of a stretch both in the example it used, and in particular the fact that the Ruby world is currently undergoing a big shift. I would imagine one year from now a lot of those choices will be gone (e.g. Ruby 1.9.1 or even 1.8.x, Rails 2.x and maybe some of the less popular Ruby implementations).
But the general principle is correct: the Ruby community likes to try, change, play with new frameworks and ideas. If you hate the principle, then maybe Ruby is not for you. Or maybe in true Open source philosophy, you can make a simpler installer, or get someone else to do it. Then you'd have made the Ruby world a better place, and we'd all thank you for it. :)
This post strikes me as not really about Ruby but about software development in general and specifically developing web apps. There isn't much insight here, of course it is hard and the language and framework don't matter much.
As someone who has been tinkering in Ruby for a couple of months, I can see where the author is coming from.
Personally, I tried to spend time on what was stable (Ruby 1.8.7 and Sinatra). This allowed me to focus much more on the language yet still feel productive.
Once you get past getting started, the decision on what to use (or who to ask) become much clearer.
Personally, I tried to spend time on what was stable (Ruby 1.8.7 and Sinatra). This allowed me to focus much more on the language yet still feel productive.
Once you get past getting started, the decision on what to use (or who to ask) become much clearer.
That's the sensible approach most beginners take with ANY platform/software. Download the highest stable release and work with it.
Work with the cutting edge _later_.
Work with the cutting edge _later_.
Hey guys, I really want to learn ruby for web development, but without rails or sinatra or any framework. I want to start from zero and go all the way up.
I want my first app to be:
Any good tutorials or docs?
I want my first app to be:
puts "<h1>Hello world</h1>"
Any good tutorials or docs?
Well, you're going to want to look into Rack.
Really, you should just check out Sinatra. The whole 'framework' is like a thousand lines (or maybe two) of Ruby, and it's a pretty thin wrapper over Rack.
... any particular reason I'm at 0? Rack is the absolute minimum you're going to need to get Ruby to serve up dynamic pages, and Sinatra is an extremely minimal framework, to the point where it almost doesn't really deserve the term.
Really, you should just check out Sinatra. The whole 'framework' is like a thousand lines (or maybe two) of Ruby, and it's a pretty thin wrapper over Rack.
... any particular reason I'm at 0? Rack is the absolute minimum you're going to need to get Ruby to serve up dynamic pages, and Sinatra is an extremely minimal framework, to the point where it almost doesn't really deserve the term.
Http:ruby-doc.org/q/cgi
Then go dig into Ramaze. Strong helpful community around a durable, lightweight web framework that works as well for single-file web apps as it does for anything large and sophisticated.
Then go dig into Ramaze. Strong helpful community around a durable, lightweight web framework that works as well for single-file web apps as it does for anything large and sophisticated.
90% of this rant could be solved by just using Rails 2.3 until Rails 3 becomes more stable. Why be a guinea pig and waste your time if you don't have to. There is nothing wrong with not operating on the bleeding edge if it decreases your productivity.
I know you were trying to be satirical, gisikw, but you could have offered some suggestions or solutions. For example, I've often commented that I do not know whether a gem runs on 1.9 or 1.8. I have to test it out.
There are many many ruby projects on the rubyforge site that have never released code. They still exist after years! and they come up in searches. There are those that are obsolete, broken, or with not one line of documentation that one has to download, go through source code to figure out what it does, and if it does anything at all.
When a person comes in to ruby he needs a starting page on ruby-lang.org that tells him the popular gems or frameworks for major uses: such as CLI programs, web dev, scientific computing etc. What some call a list of "blessed" gems/projects.
However, we cannot criticize ruby if everyone is writing his own framework, parser, templating engine etc. Its also hard to be critical that so much documentation and tutorials online are outdated/broken due to the constant rate of change. Either devs are not updating tutorials/articles, or google is bringing up older documents first.
When we see a high download count for a gem that still does not indicate that people are using it. It only means people have downloaded it to check out. DOwnload counts are deceiving. Gems that offer a very sketchy description and have NO webpage often get a high download count since that's the only hope of figuring out what it does.
There are many many ruby projects on the rubyforge site that have never released code. They still exist after years! and they come up in searches. There are those that are obsolete, broken, or with not one line of documentation that one has to download, go through source code to figure out what it does, and if it does anything at all.
When a person comes in to ruby he needs a starting page on ruby-lang.org that tells him the popular gems or frameworks for major uses: such as CLI programs, web dev, scientific computing etc. What some call a list of "blessed" gems/projects.
However, we cannot criticize ruby if everyone is writing his own framework, parser, templating engine etc. Its also hard to be critical that so much documentation and tutorials online are outdated/broken due to the constant rate of change. Either devs are not updating tutorials/articles, or google is bringing up older documents first.
When we see a high download count for a gem that still does not indicate that people are using it. It only means people have downloaded it to check out. DOwnload counts are deceiving. Gems that offer a very sketchy description and have NO webpage often get a high download count since that's the only hope of figuring out what it does.
My solution was simply to recommend personalized tutoring via RailsMentors.org - as you can really learn from any development stack. It's just finding the right combination that can be very difficult for a new developer.
You bring up some very good suggestions - we need a better metric for whether things are stable, supported, etc. And you're absolutely right, Google won't work, and download counts won't work. I would be interested in seeing something like you've suggested though, essentially coming up with a "trust" system for different libraries.
At the same time, you have the experience available to test whether a gem runs on 1.8 or 1.9, where a new developer doesn't know how to read stack traces yet. Providing one-on-one support helps tackle this issue (RailsMentors.org), as would increased tutorials that try and _limit_ the range of choice, rather than overload the developer with too much.
Of course, these are just my own thoughts on how we can address the problem. I'm hopeful that by discussing it, people can come up with some additional solutions.
You bring up some very good suggestions - we need a better metric for whether things are stable, supported, etc. And you're absolutely right, Google won't work, and download counts won't work. I would be interested in seeing something like you've suggested though, essentially coming up with a "trust" system for different libraries.
At the same time, you have the experience available to test whether a gem runs on 1.8 or 1.9, where a new developer doesn't know how to read stack traces yet. Providing one-on-one support helps tackle this issue (RailsMentors.org), as would increased tutorials that try and _limit_ the range of choice, rather than overload the developer with too much.
Of course, these are just my own thoughts on how we can address the problem. I'm hopeful that by discussing it, people can come up with some additional solutions.
If you want to be a ruby dev, then install linux. On windows you use Visual Studio and .NET
on Windows, you use VMWare and Linux. Linux is hands down the best Ruby development platform I've used, whereas Ruby on Windows can be a bit sucky at times, especially with gems that require native builds
Yup. That's pretty much it. I remember jumping on a Ruby project and having to install 50 (not exaggerating at all) gem dependencies. A handful of them didn't build because of my version of (Ruby|GCC|Rails|OS X|MySQL) and of course nobody else knew how to fix it.
I still love Ruby, but now I use it almost exclusively for sysadmin/build type stuff with Rake.
I still love Ruby, but now I use it almost exclusively for sysadmin/build type stuff with Rake.
That's the fault of the project for not specifying a Ruby version. In fact any project that is bringing new people on on a regular basis should have a standard environment setup documentation/wiki.
I admit it's pretty dicey with Windows, but between Linux/OS X things are usually pretty manageable.
I admit it's pretty dicey with Windows, but between Linux/OS X things are usually pretty manageable.
The problem with RoR, isn't RoR. It's the community. I've frankly never seen a worse community to outsiders. Every discussion I've had with them, they end up basically saying, "RoR makes things so easy that over the weekend I reimplemented Google Maps in Outlook Web running Gears of War, with multitouch support -- all HTML6 compliant. And then on Sunday I watched football. MS sucks."
But then you begin to peel the onion and you start to realize -- that onion looks kinda similar to this other onion I was using.
Don't get me wrong, RoR is good technology. The community oversells it, and the most outspoken are kind of jerks (for some reason the Java, Python, C#, C++, Haskell, Scala, Clojure communities don't seem to have the rudeness or jerkness).
But then you begin to peel the onion and you start to realize -- that onion looks kinda similar to this other onion I was using.
Don't get me wrong, RoR is good technology. The community oversells it, and the most outspoken are kind of jerks (for some reason the Java, Python, C#, C++, Haskell, Scala, Clojure communities don't seem to have the rudeness or jerkness).
It's certainly a reputation that has managed to stick with the Rails community for a while. And we're trying to get the jerks to shut up ;-)
And while I can say that Rails is fantastic, and in my opinion, the best framework out there, I'm also going to tell you: unless someone's willing to sit down and show you, don't listen to them. That said, there are many people who _aren't_ jerks, and are more than willing to help you reimplement Google Maps. A lot of them can be found at RailsMentors.org
And while I can say that Rails is fantastic, and in my opinion, the best framework out there, I'm also going to tell you: unless someone's willing to sit down and show you, don't listen to them. That said, there are many people who _aren't_ jerks, and are more than willing to help you reimplement Google Maps. A lot of them can be found at RailsMentors.org
Wow, that's an insanely brilliant thump against Ruby and the community.
As a born Rubyist (That is I started programming with Ruby) hopefully this article will get enough traction to make people start looking into having Ruby be as easy as it should be to start with.
As a born Rubyist (That is I started programming with Ruby) hopefully this article will get enough traction to make people start looking into having Ruby be as easy as it should be to start with.
I wouldn't call it "brilliant"; it's a rant. Not that there's anything wrong with rants. This is a frustrating moment in Rails history, a two-fold version transition; a little cursing is to be expected.
Ruby is transitioning to 1.9. Rails is transitioning to version 3. These things are always painful. Some platforms try to rip off the band aid; others try to step slowly and carefully from one version to another. Then there are the platforms that just stop shipping new versions for a decade or so.
It's not unique to Ruby. The Drupal community is struggling to transition to Drupal 7, while legacy sites must negotiate the transition from Drupal 5 or Drupal 4.x, as well as the PHP 5.2/5.3 transition (or even a transition from PHP4), and the MySQL 5.0/5.1 transition -- or maybe the future of MySQL is MariaDB or Drizzle, or maybe we should pay more attention to good old Postgres, and then there's the team that insists that MongoDB is the future.
The web evolves. It is barely old enough to vote. It is unlike anything we have had before. If you don't like negotiating a blizzard of loosely-connected impermanent pieces you need to work on something else.
Or you need a better strategy. Many of the complaints in this rant are self-inflicted. Pick one text editor and stick with it. Pick one database and stick with it. Pick the Ruby version that DHH uses and stick with it. Don't agonize over every option. There are lots of ways to build a web page, and almost all of them work.
Ruby is transitioning to 1.9. Rails is transitioning to version 3. These things are always painful. Some platforms try to rip off the band aid; others try to step slowly and carefully from one version to another. Then there are the platforms that just stop shipping new versions for a decade or so.
It's not unique to Ruby. The Drupal community is struggling to transition to Drupal 7, while legacy sites must negotiate the transition from Drupal 5 or Drupal 4.x, as well as the PHP 5.2/5.3 transition (or even a transition from PHP4), and the MySQL 5.0/5.1 transition -- or maybe the future of MySQL is MariaDB or Drizzle, or maybe we should pay more attention to good old Postgres, and then there's the team that insists that MongoDB is the future.
The web evolves. It is barely old enough to vote. It is unlike anything we have had before. If you don't like negotiating a blizzard of loosely-connected impermanent pieces you need to work on something else.
Or you need a better strategy. Many of the complaints in this rant are self-inflicted. Pick one text editor and stick with it. Pick one database and stick with it. Pick the Ruby version that DHH uses and stick with it. Don't agonize over every option. There are lots of ways to build a web page, and almost all of them work.
You hit the nail on the head. The simultaneous push from Ruby 1.8 to 1.9 and the upgrade of Rails from 2 to 3 is ripe for turbulence. Rails 3 is a major upgrade and the supporting gems also need to simultaneously be upgraded as well. This upgrade is no small feat.
Then there are the platforms that just stop shipping new versions for a decade or so.
Perl's mistake was not releasing another Camel Book for a decade. The Perl 5.x language and libraries have done just fine.
Perl's mistake was not releasing another Camel Book for a decade. The Perl 5.x language and libraries have done just fine.
Ruby is a hacker's paradise. The reason things are so chaotic is because people are doing so many cool things independently. It's impossible for someone to step in and impose order for the benefit of beginners, and even if it were possible it would diminish the value of Ruby.
The greatest opportunity for improvement is in the documentation arena, since blog posts are a huge part of the Rails documentation ecosystem, and because they tend to go stale and clog up Google with misinformation. Rails Guides are a really nice addition, but a meta-source that provided staleness information and list of preferred resources for various things would go a long way towards guiding newbies to a sane stating point (hmm, wheels turning in head).
The greatest opportunity for improvement is in the documentation arena, since blog posts are a huge part of the Rails documentation ecosystem, and because they tend to go stale and clog up Google with misinformation. Rails Guides are a really nice addition, but a meta-source that provided staleness information and list of preferred resources for various things would go a long way towards guiding newbies to a sane stating point (hmm, wheels turning in head).
I love Rails, and this is still the best summary of the current situation I've seen.
I just spent way too much time getting passenger and rvm and rails 2 and 3 to (all) play nice together in a deployment environment, though, so I'm biased.
I just spent way too much time getting passenger and rvm and rails 2 and 3 to (all) play nice together in a deployment environment, though, so I'm biased.
People always complaining... Too cold in winter, too hot in summer... Too inflexible framework, too much choose in framework... Too boring gf, too hot gf (attracting too much males =))... Too high taxes, too low quality of life... I can continue =)
Just shut up and learn/do stuff. Learn/do the way you like it. This is how everything evolve!
Just shut up and learn/do stuff. Learn/do the way you like it. This is how everything evolve!
I develop more for fun .. i develop in ruby 1.9 and test to see it works in 1.8.7 also. No big deal!
I use "gem" for installing gems. Not bundler. No need to confuse someone new with RVM and ask him to play with all versions of ruby till he finds the one that suits him.
Its like asking a Java developer to try out all versions of Java starting with the 1.0 version, or asking a python developer to try jython and IronPython in addition to the 2 or 3 current versions.
What about perl. Should a new developer try out perl 4 and perl 6 too first ?