Posted by Nick Sieger
Tue, 18 Sep 2007 08:14:00 GMT
Rebel With a Cause
Rails is no longer the James Dean character, looking outward, trying to convince you of something. It’s no longer about a rebellion or a revolution. Instead, Rails is settling in as a passionate, inward-looking craftsperson.
After the rebellion, settle in and enjoy the results of your work. David hasn’t been working directly on Rails too much, instead he’s been enjoying it.
And it’s not about David anymore. It’s about You (cue the Time Person of the Year cover). David wants Rails to be more friendly to newcomers.
Report #12: Verified Patches. Encouraging the community to approve patches, rather than limiting the decisions to the core. Opening up Rails. (Also, unfortunately looking a little scarce at the moment. Update: turns out it’s empty because patches are quickly applied, not because there aren’t any submitted!)
David screened the original Rails movie – showing Apache setup, manually creating databases and tables. He quickly lost patience for it.
Compare to the current state of the art, with everything down to the routes and migrations gets created for you, lowering the barrier to entry (example: a new rake task db:create:all).
Rails 2.0 is largely about continual improvement and removing the cruft:
- Cookie-based session store as the default
- Routing:
map.root
- Removing the dynamic
scaffold :posts feature
map.namespace and script/generate controller admin::posts*.html.erb files with the MIME type and renderer baked into the filename, since the two are now mutually exclusive.- Automatically named partials with
render :partial => @posts resolving to _post.html.erb
- Namespacing and named routes:
mop.namespace :admin do |admin|
admin.resources :posts
end
link_to 'Show', [:admin, post]
class Admin::PostsController < ApplicationController
before_filter :ensure_administrator
private
def ensure_administrator
authenticate_or_request_with_http_basic("Blog Admin") do |user,pass|
username == "dhh" && password == "123"
end
end
end
- Custom layouts for specific user agents (say, oh, the iPhone). Views can also be rendered, e.g.,
index.iphone.erb.
class ApplicationController < ActionController::Base
before_filter :adjust_format_for_iphone
def adjust_format_for_iphone
if request.env["HTTP_USER_AGENT"][/iPhone/]
request.format = :iphone
end
end
end
Mime::Type.register "application/x-iphone", :iphone
respond_to do |format|
format.iphone { render :text => "Hello iPhone", :content => Mime::HTML }
end
atom_feed_helper, a new plugin – builder for Atom specified in index.atom.builder<%= yield :head %>, content_for :head { auto_discovery_link(:atom, formatted_posts_url)}- Debugger – allows you to be lazy and leave your
breakpoints in your production code, not that you’d actually want to do that. Dumps you into irb where you can inspect variables, etc. but you can also drop down another level to see the call hierarchy, etc.
So when will we see Rails 2.0? The preview release is coming, hopefully before conference end.
Tags railsconf, railsconfeurope2007 | 6 comments
Posted by Nick Sieger
Tue, 18 Sep 2007 08:08:34 GMT
(Written from Dave’s perspective, in the first person, but paraphrased)
What is a relevant topic in Germany? Engineering. Except there’s no such thing as software engineering. The software equivalent of building a bridge is taking a whole lot of dirt that fills in a hole.
So what makes engineering good? I look for elegance and beauty.
Fred Brooks – Mythical Man-Month. Not a single thing in software engineering has changed in the 30 years since the book was written. Go out and order it tonight if you haven’t read it.
We are privileged, because we get to start with nothing. Anything we can conceive of, we can create. And so, we suffer the same problems as poets suffer.
Writer’s block: a blank page standing in the way of getting started. Painting: a blank canvas without structure or form. Software project: a blank editor buffer.
Leonardo was commissioned to build a statue. But, having never bronzed in his life, he picked up a scrap of paper and drew sketches. He’s prototyping on paper, but in reality he’s prototyping in his mind, getting his brain thinking about what he’s doing.
We could do more of this experimentation. Whiteboard, index cards, we eschew them for scaffolding or other crutches. But we could think of more ideas if we got away from the familiar and tossed around new, fresh ideas.
The idea that we sit down and start coding the application is crazy. We don’t know what it’s supposed to be. Why should we fool ourselves into thinking that this works?
Artists draw cartoons, often a fully rendered version of a painting. If they don’t like the cartoon, it survives, but the final product probably takes a different form.
With Rails we can do rapid end-to-end prototyping. Scaffolding helps with this, and it probably won’t make it into the end result.
So start anyway, and be prepared to throw it away. Write tests, use them as tracer bullets. And act on worry. Listen to the inner voice that tells you when something is wrong.
Sistine Chapel: brilliant example of modularization. It shows you how to conceive of doing a huge project without the fret of focusing on the entire thing.
Another example: comic books. You’re splitting up the product into time slices. Limit how much you do, and leave open the possibility of continuing at a later day. Know when to stop.
Satisfy the customer. Compare portraits to pictures. The best portraits, while not always faithful to the real image of the subject, still achieve the goal of satisfying the customer.
There is art in engineering, and engineering in art. Neither is an either/or proposition. Art and engineering are mutually supportive, in that you can’t have one without another.
With Ruby and Rails, we have a responsibility to uphold. Rails is a canvas, so be an artist. Create something great. But we also should create something beautiful. Sign your name by your work, and take pride in it.
Tags railsconf, railsconfeurope2007 | 3 comments
Posted by Nick Sieger
Fri, 14 Sep 2007 05:33:00 GMT
Speaking of keeping busy, I’ll be speaking alongside my colleague Craig McClanahan at RailsConf Europe in Berlin next week.
Sun is a Diamond Sponsor at RailsConf again, just like in Portland last May. Part of that sponsorship money pays for a brief keynote spot (filled by Craig) as well as a session or two. So no, I didn’t get my spot through an accepted proposal submission, but that doesn’t mean that the session is going to be a big marketing shill.
No, actually Craig and I are part of a small group at Sun that’s embracing Rails in a big way, and we’re going to be launching a site built mostly on Rails later this fall. We’re taking what we think are some novel approaches to building a Rails-based application and we thought we’d share some of those thoughts with you rather than drone on for the session about how great Sun is and what snazzy tools we make. (Although expect to see a subtle plug or two for Sun hardware and tools. Call it product placement rather than overt selling.)
I titled the session “Rails Hydra” because the central idea of the structure of our application is not one Rails app, but many. The UI and views don’t even talk to a database; instead they make use of ActiveResource and RESTful web services, talking to the models living in other Rails applications in the backend. One key point is we’re deploying .war files to JRuby running on Glassfish, thus avoiding headaches of morbidly multiplying Mongrel math. We’ll elaborate on this arrangement and talk about some of the other tools and tricks we’re using.
Also, Charlie, Tom and Ola will be there, so we’ll certainly have a JRuby summit at some point. Stop by and say hello!
Posted in java | Tags gig, rails, railsconf | 1 comment
Posted by Nick Sieger
Tue, 04 Sep 2007 02:48:40 GMT
This week I was working on integrating the latest JRuby 1.0.1 and Goldspike 1.3 releases into our environment, when my frustration hit a fever pitch.
See, I had always thought that the .war packaging side of Goldspike was a little clunky and
un-ruby-like, but I didn’t see a clear path to fixing it. I had heard little complaints about it here
and there: the little configuration DSL didn’t give you enough control or wasn’t documented well
enough; the fact that it downloads libraries from the internet during assembly (convenient, but not
safe or reproducible for production deployments).
Also, in my own opinion it took the wrong approach to packaging Rails in a .war file. It puts the
Rails application directory structure into the root of the .war file where any web server or Java
application server might mistakenly serve up your code as static content. The Java .war file spec has
this special directory called WEB-INF expressly for the purpose of hiding that stuff away, so why
not use it?
And then, suddenly Goldspike was packaging up my entire Rails application directory, .svn directories
and everything. So I set out to fix this once and for all.
And so I present Warbler. A little bird who chirpily steps up to the task of assembling your
Rails application into a Java Web Archive (.war). Here, get it:
gem install warbler
And then, in the top directory of your Rails application,
warble
Those two steps are all it takes to make a .war file, including your application and recent versions
of JRuby and Goldspike, that’s deployable to your favorite Java application server.
There are a number of points about Warbler worth mentioning.
Does one thing, well
Warbler only packages, and doesn’t care about anything else, like how to dispatch servlet requests to
Rails. This will allow for more runtime servlet binding mechanisms to take advantage of Warbler in
the future.
Fast and lightweight
50% less code than the Goldspike packaging plugin, yet does the job quickly and efficiently.
Sane defaults
Warbler only packages code that you need to run the application, omitting database migrations and
tests. If your application is self-sufficient (no external dependencies), then the out-of-the-box
configuration will probably work for you. Public HTML/images/javascript/stylesheets go in the root of
the webapp, where Java webservers expect them to be.
Documented, flexible configuration
Need to customize your configuration? Run warble config and edit config/warble.rb. All the
options are there, commented and documented.
Need to change out the bundled JRuby/Goldspike versions? warble pluginize makes a copy of Warbler
in the vendor/plugins area of your application, allowing you to change the .jar files in the
vendor/plugins/warbler-0.9/lib directory. Warbler then makes his nest in your project’s list of
rake tasks (as rake -T | grep war shows)
rake war # Create trunk.war
rake war:app # Copy all application files into the .war
rake war:clean # Clean up the .war file and the staging area
rake war:gems # Unpack all gems into WEB-INF/gems
rake war:jar # Run the jar command to create the .war
rake war:java_libs # Copy all java libraries into the .war
rake war:public # Copy all public HTML files to the root of the .war
rake war:webxml # Generate a web.xml file for the webapp
Warbler even omits himself in the .war file produced when running in plugin mode, since you won’t
need him at runtime. It’s the little details that matter.
Give him a try and let me know if it makes your life deploying Rails applications to JRuby on Java appservers easier!
Tags jruby, rails, warbler | 13 comments
Posted by Nick Sieger
Sun, 02 Sep 2007 04:47:26 GMT
This one’s a bit late – consider it part of my get-caught-up-since-unclogging-the-clogged-blog series.
ActiveRecord JDBC 0.5 is out, so you may have heard (it went out the door a week ago Friday; c.f.
Arun and Tom). The major feature you get in this version is a new database.yml
configuration style:
development:
adapter: mysql
database: blog_development
username: root
password:
Ok, ok, so what’s the big deal? This is just Rails’ default database configuration. Well, that’s the
point – you no longer have to know anything about JDBC URLs, driver class names, and all that. We’ve baked it in for you. This should make it easier than ever to try out your Rails application on JRuby, as the only piece of manual configuration left for you is the ugly bit of JRuby-specific code you need to activate ActiveRecord-JDBC lurking right above the Rails::Initializer:
if RUBY_PLATFORM =~ /java/
require 'rubygems'
gem 'ActiveRecord-JDBC'
require 'jdbc_adapter'
end
If we can obliterate the need for this last bit of code, and make it easy to obtain the necessary driver bits, I’ll feel good enough to call this thing a 1.0 product.
Tags activerecord, jruby | 1 comment
