RailsConf: Dave Thomas keynote
Posted by Nick Sieger Fri, 23 Jun 2006 15:12:00 GMT
Dave Thomas, Professional Cassandra
Intro
Dave starts by dissecting a google search and pointing out how the sponsored links sidebar contains a wealth of paid ads for various topics:
- Hosting
- Consulting
- Commercial IDEs and tools
- Alternatives to RoR!
Moving on to rubyforge, Dave examines some download stats, and points out that there have been 536835 downloads of Rails through gem install rails
Dave examines some Google trends mapping of ruby on rails vs the following, showing RoR catching up on some and overtaking others:
- websphere
- jboss
- tapestry
- spring framework
- zend
3 Problems for Rails
Dave proceeds to give his own, tailored for Rails, version of David Hilbert’s famous “23 unsolved problems”...except due to time constraints, can only discuss three.
PDI
An acronym, PDI, has emerged on the Rails core team as a way to encourage people to contribute. Please Do Investigate
The challenge is to get new features to be proved out in the community before taking it into the core, the Rails core team is only 12 and has limited bandwidth, and that is the idea behind PDI
The three problem areas are:
- Data integration
- CRUD
- Deployment
Data integrations
Dave mentions that he and David “disagree mildly” on the point of using constraints in the database.
- automatic validation based on schema
- work with foreign keys - make it easy to define in a migration
- add a “belongs_to” relationship if a foreign key constraint is detected
- primary key support, e.g., non-integer keys, particularly in migrations, and composite primary keys
The argument here is that real-world applications, and legacy databases today require these features, and Rails needs to be able to have answers to those questions if it wants to be viable in that area.
Dave is asking for distributed transactions now. Should we be pushing Rails into such an enterprisey direction? If you really need XA transactions, shouldn’t you be banished to a java world?
Non-database models would be a fabulous addition to rails. ActiveRecord::Base currently assumes that it’s talking to a sinle relational datastore. If we could integrate multiple disparate data soures, it would make integrations, REST data sources, and mashups much easier. Microsoft is doing this with LINQ today, and if Rails wants to keep up, it will need this.
Real-world CRUD
Dave is arguing that we should beef up scaffolding and make it useful. Scaffolding was the star of the initial 10 minute Rails video that started everything, but yet it’s the ugliest web 1.0 interface ever! No AJAX, no automatic, DRY, in-browser validation. But should we, can we really genericize these interfaces? Maybe a scaffolding widget/component system? It can and probably will happen, but at the momet I’m inclined to think that this will complicate things. Do we want Rails view to turn into Wicket widgets or ASP.NET components? It’s a completely different way of writing web programs. We’ll have to see how it plays out.
Deployment
Dave argues for improved deployment. Yes we have Capistrano, and it’s arguably the best web deployment mechanism in existence, but the web of knowledge required to deploy a Rails application is too large, varied and unwieldy.
Capistrano is a push model, ideal for small shops where the developers manage and maintain everything, but it’s not the real world. Larger shops have separate development and admin departments. They have stricter requirements for where files go, pre and post-deployment hooks, roles, passwords, security, etc. Capistrano currently falls down a bit in this environment.
Dave discusses cap --deploy-on: a hypothetical extension to Capistrano that would allow staged deployment to multiple servers, and the possibility to introduce workflow between developers and administrators. What if ISPs had a standardized infrastructure that would allow hobbyists to issue a cap --deploy-on and instantly have their apps running up on TextDrive, DreamHost, etc. To go further, what if we could deploy from rubygems? gem deploy <name> --on cap://my.isp.com. Typo installation would literally be a single command.
Closing
All developers need to be happy, so let’s make their lives easier!
