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
Posted by Nick Sieger
Fri, 31 Aug 2007 16:19:48 GMT
After a busy few weeks since my recent troubles keeping the blog up, we’re back.
The kind folks at Joyent were nice enough to provide accelerators for the JRuby team members to use, and this post is one of the first results of that gift. Thanks Joyent!
There are a lot of news items to recap and report; more on that shortly.
Tags joyent | no comments
Posted by Nick Sieger
Thu, 26 Jul 2007 22:49:52 GMT
I’ll be speaking and participating at an upcoming event at the Axis Café in Potrero Hill, San Francisco on August 8, co-hosted by Sun Microsystems (my new employer as of mid-May), and Joyent.
We’ll be talking JRuby, Glassfish, Open Solaris, Joyent Accelerators, and deploying your Rails applications using those technologies. Bring your laptop, outfitted with your favorite Ruby editor/IDE, and get ready to write some code (or, if you wish, take your existing app and deploy it).
Food and drinks will be provided, and space is limited, so go register now. Look forward to seeing you!
Tags glassfish, joyent, jruby, sun
Posted by Nick Sieger
Fri, 13 Jul 2007 09:39:00 GMT
The size of this blog seems to have outgrown the small 128MB VPS it’s running on. Any post/comment/change causes the server to swap endlessly, and I know some of you have seen 500 or 502 errors. I hope to remedy this soon, but until then, comments have been disabled, and the site will remain more or less frozen.
If you do have a comment, please send it to me the old-skool way (email – with your name and URL and the article you’re commenting on), and I’d be happy to add it for you for historical purposes.
If you have any ideas on tuning my servers to avoid hitting the memory limit, I’d appreciate those as well. I’m currently running Ubuntu Dapper with Apache 2.0, Ruby 1.8.4, Mongrel 1.0 with fastthread 0.6.1, Typo SVN revision 947 (a bit old, I know), and SQLite 2. Upgrade to the latest Ruby? Upgrade Typo – yeah, that would be a little more painful. Switch to Mephisto – more painful still. Ditch Apache in favor of nginx? Probably, except I’m using Apache for SVN and Trac as well. We’ll see.
I tried running MySQL (4.1) for a while last night, but it too was swapping and the site wouldn’t even render, so I turned off and reverted to SQLite, which at least allows the site to load, even if it blows chunks when you try to post a comment or an article. Sigh.
Posted by Nick Sieger
Thu, 12 Jul 2007 08:27:00 GMT
Summer is settling in, and so is the JRuby 1.0 release. Most of the core team seemed to take some time off since the release, as the commits and lists have felt quiet compared to the frenetic lead-up to 1.0. I don’t know if that’s a good thing yet – I’m not bold enough to suggest that it means that JRuby’s just working for everyone, and that the software is bug-free. There have been calls for a point release (probably 1.0.1) and a better roadmap – we’re working on those and should have something in the next couple of weeks.
On the other hand, the number and quality of blog posts about JRuby seem to be steadily increasing. The number of compelling applications of JRuby, both in the Ruby/Rails and the Java worlds, are being demonstrated more and more. Here are a few examples.
JMS is turning out to be a great place to sprinkle some JRuby magic. Ola started by implementing direct JMS support for ActiveMessaging, eliminating the need for the separate poller process. Nutrun goes the other way and demonstrates how simple it is to run a broker, publisher and subscriber using ActiveMQ and a short JRuby script.
Jeff Mesnil has started jmx4r, a simple DSL leveraging JRuby to write monitoring scripts for your JMX-enabled applications.
Kyle Maxwell whipped up a compelling plugin for Rails in time for RejectConf using Lucene. Why imitate when you can use the real thing?
Zed Shaw has caught the JRuby bug, and decided to do his own take on scripted Swing applications with Profligacy. Check out the progression of examples as Zed hones in on his final product. As nap points out, Zed’s Layout Expression Language (LEL) is a refreshingly concise take on specifying UI layouts. Cleaner separation of component layout and event handling logic is also a big win. Move over Groovy SwingBuilder and JavaFX!
Last but not least, my own earlier proposal on Java interface integration has been implemented in current JRuby trunk. Along the way I found the opportunity to toss in some extra sugar and implement proc and block coercion to interfaces as well. This means you can pass a proc or block to a Java method and it will be converted to the appropriate Java interface type (e.g., Runnable and Swing/AWT listeners):
button = JButton.new
button.add_action_listener do |event|
event.source.text = "You pressed me"
end
If closures for Java can’t do this, they will have gotten it wrong. Note that blocks will be converted and used in place of the last argument to the Java method only; if you need to pass behavior to any argument preceding the last, use a proc. Here’s one example that gets progressively better as we switch over to blocks.
Two parting thoughts – a couple of things that aren’t quite ready, but you should keep your eye on.
Glassfish dev Jean-François Arcand demonstrates parked Rails requests with Grizzly. And you thought you had to do comet-style request handling outside of Rails? The future of scalable Rails servers looks pretty good to me.
Finally, respected object technologist Alan McKean has started looking at object serialization and persistence for JRuby. You thought you had to wait for that Gemstone-thing that Avi Bryant mentioned at RailsConf? Maybe the wait won’t be too long after all…
Tags jruby
Posted by Nick Sieger
Mon, 11 Jun 2007 15:35:00 GMT
Many libraries and plugins ship custom Rake tasks. Of course, as slick as Rake is for a build and configuration language, it’s still just Ruby code right?
Case in point: I released a version of ci_reporter with a fairly careless bug in a rake task that attempted to << a string into an existing environment variable. It escaped me at the time that Ruby sets up the ENV hash with frozen strings, because my own usage of ci_reporter did not exercise the task in that way.
So shouldn’t that Ruby code be subjected to the rigor of automated testing just like the rest of your code? It became obvious to me that it must be so. It turns out it’s straightforward to use Rake in an embedded fashion, and invoke targeted tasks in your custom Rake recipes. The examples here use RSpec, since that’s what I use for testing ci_reporter, but you could apply this to Test::Unit as well.
The technique is to create a new instance of Rake::Application, make it the active application, and load your rake scripts into it:
describe "ci_reporter ci:setup:testunit task" do
before(:each) do
@rake = Rake::Application.new
Rake.application = @rake
load CI_REPORTER_LIB + '/ci/reporter/rake/test_unit.rb'
end
after(:each) do
Rake.application = nil
end
end
Notice the use of #load rather than #require, as you want to execute your rake script each time you setup the Rake application object. When tearing down your test or example, you should cleanup Rake by setting the Rake.application back to nil (or save the previous application and restore it, if you prefer).
Now, in the body of your test or example, you invoke your rake task with @rake['target'].invoke. Here, I’m exercising the case of an existing, frozen ENV value. After the task is invoked, I check the value after the task to make sure the variable was modified as expected.
it "should append to ENV['TESTOPTS'] if it already contains a value" do
ENV["TESTOPTS"] = "somevalue".freeze
@rake["ci:setup:testunit"].invoke
ENV["TESTOPTS"].should =~ /somevalue.*test_unit_loader/
end
I was fortunate here that the tasks for which I wrote tests after the fact were simple enough to be testable on their own, which may not always be the case, especially with organic, homegrown Rake tasks that interact with the world outside of Ruby. Still, if your Rake tasks are a critical part of your application, library or plugin, they should be tested. For example, it would be nice if tests could be written for the Rake scripts in Rails’ Railties module to increase coverage there.
Perhaps someone out there will run with this idea and take up the challenge and write a Rakefile completely in a test-driven or behaviour-driven style. It’s always been a sore point for me with Make, Ant, Maven, and virtually every other build tool in existence that you have no other way of automatically verifying your build script is doing what you intended without manually running it and inspecting its output – it just feels so dirty! I’d expect that test-driven Rake scripts would likely have the level of granularity to match the tasks that need to be done, in a way that you can combine them in the right ways to make incremental and deconstructed builds simpler.
Tags ruby, testing | 5 comments | no trackbacks
Posted by Nick Sieger
Sun, 10 Jun 2007 04:03:00 GMT
I’d just like to take a moment to echo what Ola has to say about the JRuby 1.0 release. This one is definitely for all of you out there. It’s been incredibly gratifying to see the growth of the community, and the increased amount of positive feedback and success stories with JRuby, and I’m honored to have been part of the team that made 1.0 happen.
We really feel strongly that we’ve put out a quality piece of software, a tool that will make your work more enjoyable, easier, and allow you to inject some creativity and innovation back into the Java stack.
We’ve got a solid base to start from. Being able to run Rails is no small feat, to be sure, but the best is yet to come. You can expect more performance, a complete compiler, support for more applications, and tighter integration with long-standing Java technologies. In addition, we’d like to push the envelope of what both Ruby and Java are capable of, including implementing (even driving) Ruby 2.0 features, leading the way for dynamic language support in the JVM, eased as well as novel ways of doing application deployment, better debugging and tooling, and experiments with new ways of doing concurrent and parallel computing.
Do join up with us – it’s never too late to hop in and enjoy the fun!
Tags jruby, ruby | 2 comments | no trackbacks
