From April, 2006 - Cedric Beust explains “Why Ruby on Rails won’t become mainstream”
Personally, I think he turned out dead wrong on this. If the AARP is building a large-scale software project in Ruby-on-Rails, with the ongoing back-and-forth between Django and Rails, and the various efforts to “port” rails to other languages, I think it is hands-down a mainstream contender.
Never ever ever, no matter how much it makes sense semantically, use the word ‘type’ to describe a column in a database table that will be used by Rails.
Every technology needs a good slap in the face once in a while. While most of this rant from Zed Shaw is insipid, there are some very good points. Especially regarding the people and ideas that are worthy of respect, and some commentary on the potential issues with large-scale agile consulting shops.
Anyways, one doesn’t have to admire someone to admit they make some good points.
You can do this in Ruby, and there is some argument whether it is a good thing to be able to do (in terms of readability, comprehensibility). You can override an existing method w/your own (I forget what the term is, right now, mainly because I never use it). Ruby on Rails takes full advantage of this.
Apparently, you can do the same thing in Flex, for the internal functions/capabilities of the MX Controls.
Void where prohibited, your mileage may vary, etc.
I just registered the domain name EnterpriseRails.com; let’s see whether I can come up with something interesting to put there.
Here are some interesting links discussing the concepts around Enterprise Rails
I reserve judgement for now on that last one.
Update:
What happens when you have 4 different versions of a language being worked on at the same time?
So, there are 4 Ruby runtimes in various states of being built. They all (except for 1.9) will be fully compatible with 1.8 and they will all run Rails just fine. So, what’s going to happen when some enterprise customer wants interfaces or some other optional typing mechanism
*snip*
At the core, I think Ruby is defined by Rails. Sooner or later, the Rails guys will realize they’re the dog and start finding a tail that’s easier to wag for the customers with lots of money. That will likely lead to fractured Ruby syntax and fractured Ruby dialects.
Try as I might, I can’t disagree with his analysis. There will be some very interesting challenges for Rails as it evolves forward.
Update:
Jonathan dissents. He makes some good points, but Lisp doesn’t have the kind of Internet hype that Rails has, so I’m not sure it’s a valid comparison.
A friend of mine wrote a great Rails app that aggregates movie news from a bunch of sources. Check it out!
Robert Martin provides us with a great demonstration of how to avoid bad programming in Ruby entitled “The Hungarian Abhorrence Principle”
The general rule can be summarized as:
However, you should read the whole post for a concrete example and additional thoughts.
More generically - if you need to know the structure of your data type in order to work on it, it probably means you’re not using good encapsulation.
I probably do this several times a day, so it’s definitely something for me to be more aware of.
In the context of technologies hitting a peak, and then experiencing a trough of disillusionment as people discover it won’t really solve the world’s problems in 10 year lessons, Obie asks (read through for more)
Perhaps we can skip the trough altogether? Has that already happened? What do you think?
I responded in comments, and reproduce my comment here:
No. Rails will not skip the trough. Just like everything else, as it ascends the hype-scale, people will jump on the bandwagon, and proceed to build slow performing, horribly modelled, insecure bug-ridden crap. And when their work fails to impress, they will, of course, blame Rails. They will say “Rails doesn’t have an effective IDE.” and “Rails doesn’t integrate with existing legacy database schemas”, and “Rails scaffolding isn’t secure.” and “Rails has a crappy debugger” and “Rails doesn’t have thread support”, and “Rails doesn’t have support for legacy security and management infrastructure.”
And so on, and so forth. In other words, all the objections that “Enterprise Architects” gave as to why they won’t use Rails, will be used as excuses for the people who decided to use Rails without actually checking to see if it made sense for their project.
Yes, even the mighty SOA must endure the Gartner Trough. (Hat Tip: Sam Gentile)
I am seeing a number of different posts about “Blub” - the programming language that you are most comfortable with, that blinds you to the power in other languages.
Which is more powerful? A Maserati, a Fire Truck, a Hummer or a Segway?
Well, it depends on what you want to do with them. Fighting fires with a Maserati would be quite hard, but touring a boardwalk in a fire truck would be a sight to behold indeed.
I’m very much enjoying the work I’m doing with Ruby On Rails, and I find it quite powerful for the purpose of building web apps. But I have a big project coming up, and Ruby On Rails isn’t even a contender for it. Languages are a means to solving a problem. The word “Powerful” crosses more categories than just objects, closures and MapReduce.
Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures. He carefully read the entire “Lambda: The
Ultimate…” series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system. He learned much, and
looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by
saying “Master, I have diligently studied the matter, and now understand
that objects are truly a poor man’s closures.” Qc Na responded by hitting
Anton with his stick, saying “When will you learn? Closures are a poor man’s
object.” At that moment, Anton became enlightened.
I’m only 1/4th of the way through, but already I have to say - Rails Recipes by Chad Fowler is an awesome book - full of nifty examples of things you can do to make your Rails apps better.
The first section (the one I’m reading) is all about Web 2.0 things that are enabled/assisted by Rails. Very well done, and I’m excited to see how his approach will carry on into other parts of the framework.
This link was useful, but somewhat incomplete. I’m still looking for a good general reference for building a suite of unit tests to test an actual application, instead of just simple theoretical apps.
One thing I did discover - my tests were all failing, due to something seemingly completely out of my control - the unlock_mutex method, buried deep in the ActiveRecord base.
Some investigation revealed that this was likely related to the “use_transaction_fixtures” control variable. A bit of googling revealed that I could just turn it off, which fixed the problem. Interestingly, the documentation says that this is only required for MyISAM database structures. However, I verified that I use InnoDB. However, this “MyISAM-only” fix fixed the problem, so there we are.
More for me than others, but I’ve done a few of these things, and this is a good read.
Did I mention that I finally, finally have a chance to do for-pay Rails work? Nothing fancy, but its a great start.
Scott Bronson reviews the various Ruby debuggers. Winners:
And then a guy named ‘rabble’ is, or has written a book on Testing Rails (woo hoo!). Here is the companion blog.
Someone stole my idea to build an app combining the eye-candy of Flex with the web-dev coolness of Rails.
Actually, I’m happy someone else did this, since I don’t have the spare time to work on this with all my other projects.
The tutorial is very well written. I will enjoy looking at it with more leisure when I get a chance.
*Update* - changed the URL to point to the new location of the project.
Some may think I’m being unhelpfully mean with my criticism of Mr. McGovern’s post. So, let’s try a different approach. Using the same basic content that James put together, I’ll demonstrate the difference between leading and following. I’ll indicate where I feel that I deviated from James’ content with italics.
How do we get Ruby into the Enterprise.
I’m a fan of Ruby, and an Enterprise Architect, and I’ve given some thought as to how Ruby might become important in the Enterprise architecture space.
First, the problems:
Let’s address how we might be able to solve those problems:
Conservative Enterprise Architects
The key here is critical mass - nothing gets done in F500 enterprise architecture w/out lots of tongues wagging. We need one ore more of the following:
- A large hardware vendor to adopt Ruby as a solution. IBM or HP are obvious choices. This is obviously hard, and largely out of our control. The best way to do this is probably to build Ruby up in small and medium enterprises. OVer time, this will help make it more legitimate and more interesting to build solutions around
- Consulting Agencies (Bearingpoint, Wipro, etc) need to develop a Ruby practice. Thoughtworks is already doing this, and while they are small, they have a lot of press. This is an area where continued success will force the big consultants to take notice.
- Articles about Ruby in the enterprise need to show up in major magazines. This is probably the easiest one - we know that Ruby has some legs, and magazines like to talk about interesting new things.
- Coverage by analysts. Unfortunately, analysts are the classic lemmings - uninterested in new things, because they don’t like having to argue a position. This won’t happen until one or more of the others do.
Transparency over Performance
I bet you didn’t realize this was true, but yes, Fortune 500 companies are forced by Sarbanes-Oxley and other laws to worry much more about complete business transparency and ethics than they are about raw performance. This is not to say that performance isn’t valuable, but it is just not as important as transparency. And don’t forget, as an enterprise architect, I get several calls a day from people who tell me their product will improve productivity. But a product that could improve transparency? That would be very well received! A transparent enterprise architecture is one where every step is monitored, logged and compared to the last for correctness, where alerts are generated when things change in unexpected ways. Essentially, you need to think of your data as prisoners, and your enterprise architecture as the jail that they are forced to live in. If the data escapes, or it goes somewhere its not supposed to, you’re fired. What does this mean for Ruby? Extensive Security Analysis. Extremely accurate and voluminous logging, and a bunch of other things that I won’t get into here.
Enterprise Infrastructure
If your Ruby server goes down, how is that communicated to the operations team? How about detecting dictionary password attacks? What about integration with SNMP or JMX? Those are the kinds of things that enterprise systems need to support. You need books - on how to make Ruby applications monitorable and traceable, written by people with extensive enterprise experience. You need robust toolsets for integrating with enterprise authentication systems, with enterprise monitoring systems. You need development tools that make the already easy mechanisms for producing code in Ruby even easier.
Model-Driven Architecture
Over time, I’ve become a big fan of MDA, and I think it is the wave of the future. If this comes to pass (and I hope it does), then the traditional metrics of “it’s easy to produce code in language X” no longer really apply. However, I think there are some interesting things about Ruby that might make this easier - especially when you look at Rails - techniques that make Ruby-based MDA more robust and flexible to change than other language choices. I feel very strongly that agile development is on the downswing, and MDA is the wave of the future. But that doesn’t mean Ruby can’t keep up. Because Ruby is a programming language, not a development methodology. You may disagree with me, but that’s fine. I can handle a diversity of opinions on this issue without assuming that everyone else is a sellout.
There.. That’s what a Thought Leader writes.