Josh Sierres is giving a workshop on Ruby on Rails so I'm going to take notes more for my own benefit than for yours.
So, what's the big deal about Rails?
Most important point is that it gets out of your way. Lots of people refer to it as a boring framework because the people who start using it in real business apps find it gives them more time to focus on business logic and less time on implementation details.
Productivity. Gains are massive. Not necessary to put a number on it because it's not measurable.
Happiness. Productivity makes people happy, and happy people are productive. Very important point. Rails programmers have a little smirk on their face because things start working better.
Creativity. Lots of people from design and usability are now using rails as their gateway into implementing tings, getting things prototyped without depending on a programmers. Designers can do this, without knowing Ruby at all, and can build an entire app in a few weeks, and do the design themselves.
Lots of plug-ins, lots of people contributing, nice atmosphere in the community, and a lack of tension.
'Bad things', that stop people using it. Rails is not a silver bullet. Anyone who says one tools solves all problems is a salesman.
Ruby is a slow language. So people say 'does it scale?'. Yes. Share-nothing always scales, i.e. the type of architecture where you have no shared resources between instances of the application (see Cal's book about scaling Flickr). These always scale. But you have to have the right people to build them. So pointless to talk about scaling really.
Some e.g.s: 37 Signals, MOG, Robot Co-Op.
Few experts, but you only need one.
Rails is not ready for The Enterprise. It's missing internationalisation, composite foreign keys in the database natively, etc. But Ruby's a very powerful language and people can write plug-ins and add behaviour without getting in the way of the user, so there are plugins for both these and other issues.
But is The Enterprise ready for Rails? It comes with its own philosophy…
But…. all this doesn't matter. Rails is good for most web apps – most people most of the time will get what they need to get done quicker with Rails.
Risk. Use risk inherent in switching to a new technology, Rails, to make yourself more valuable. Can easily demonstrate new projects in Rails.
Opposite of risk is not safety, it's stagnation.
Rails is:
– a tool for getting stuff done faster
– maturing very quickly, more and more programmers using it
– sneaking its way into all types of businesses
– supportive of AJAX, Agile development, and other buzzwords
Rails has an edge because
– AJAX functionality is in Rails in a way that puts it into Ruby itself
– uses one language for everything
– gives you the ability to create natural language mini-framework on Ruby
And it creates happy programmers.
Rails does not stop you needing to understand HTML or SQL, but it reduces your dependance on repetition. So gives you tools to make your HTML cleaner, or writing SQL for basic queries.
It's not a high level set of components like user authentication or shopping carts. Push back against this type of components, because there are so many ways of implementing business logic, like log-in or shopping carts, that it is bad to force one way on people by creating these sorts of components.
It's not magic, but it feels like it for a while.
Power of Rails comes from the Ruby language.
More about rails…
It's an Models, Views and Controllers framework. The Model is how is should work, the View creates the thing you look at and the Controller joins those two together.
Can override conventions, but best not to otherwise you'll not get the productivity gains. Can automatically create views and controllers.
It lets you test everything inside your Rails app, with very few exceptions. Building these tests gives you a sense of security and a way to mitigate the risk in your app to prove that it works without troublesome too and fro with browser.
A few ways to get started. Can build out your database first, then build the app around it, or you can generate database files and create a 'migration' which controls the changes you make to the database.
(Had to break off here and go to a session I'd promised to be in.)
{ Comments on this entry are closed }
