Product or Platform?

Posted by Nick Sieger Sat, 20 Oct 2007 03:34:45 GMT

This week, I attended the Sun 2007 Open Source Summit on the Sun Microsystems Santa Clara campus. This was a conference put on by Sun for Sun employees. I happened to be in the bay area, so I took it in.

Open Source at Sun

First off, let me say that it was comforting being in the company of 200+ colleagues, most of them smarter and more experienced in open source than me. These are the vanguard of the company, the people spreading the message inside and outside Sun about our decision to open source all of our software, and the ramifications of that. The message is in good hands, but the only downside is what a tiny fraction of the overall company this group represents. So for those of you observing Sun representatives seemingly going in many different directions, behaving subtly differently from project to project and community to community, we want to hear your feedback. The fact that we’re meeting this week can certainly be an indicator that we’re still figuring out how to do open source effectively, to retrofit the message into the company culture, to build and contribute to communities and to raise all boats.

Some of the topics discussed include:

  • Community building (around Sun-originated projects)
  • Community participation (in projects external to Sun)
  • Open (source) testing, documentation, and standardization
  • Marketing and legal: podcasting, public relations, trademarking issue
  • Going open source on a previously closed-source product, dealing with code encumbrances, etc.

Product or Platform?

Among other topics discussed is the notion of a product versus a platform, and what it means for an open source project and its surrounding community. Dalibor Topic brought up this point in a panel session discussing the perception of Sun from the outside that included several participants external to Sun.

Without providing definitions of those two, take a moment and think of a few thriving open source communities. Would you think of these projects as products or platforms? In general, does one kind of project foster community better than the other?

Dalibor pointed out that projects that form platforms tend to be more fertile ground for community-building. Why is this? After discussing this with him, a few attributes came to mind.

Variety. Platforms are likely to be more extensible and offer more modularity and variety. As a consequence, developers have more possibilities to “scratch their itch”.

Loosely connected communities. Platforms are more likely to be broken into component projects, and each component offers a more intimate community setting. The smaller size is an incentive to developers to invest time, as the reward of gaining a reputation as a community leader becomes easier to visualize and obtain. Thriving communities have a face, and that face should be a real person. The chance to be the face of a project and gain the prestige that comes with it is a big incentive for open source developers.

Low barrier to entry. The sub-projects’ codebases are not gargantuan or monolithic. Developers can bootstrap more quickly and get to the stage where they’re contributing much faster. As a counter-example, consider three of Sun’s largest open source projects: OpenJDK, OpenSolaris, and OpenOffice. Checking out source from source control, building and running these codebases is not a 10 minute proposition, and that presents a big barrier to entry.

Balance of contributions. If the barrier to entry is lower, the likelihood of attracting contributors is higher. Projects are more likely to be seen as worthwhile if contributions are not lopsided and they are not controlled by a single entity.

OpenJDK: Pushing Toward “Platform”

Dalibor stated in the panel session that he thought Sun had done an admirable thing by releasing OpenJDK under the GPL, and that everything had been executed well up to this point. OpenJDK is on the cusp of being a platform with a lot of energy and mojo, but there are still some barriers that need to be knocked down to allow the community to grow and prosper. Encumbrances and proprietary TCK licenses are one item, but the “product”-ness of the JDK are another. If OpenJDK can become a “platform” in the ways that Dalibor and I talked about, it will go a long way towards ensuring the long-term viability of the project, the community, and even the ubiquity of Java itself as a technology.

Footnote: Thanks to Simon Phipps and his team for leading an engaging, thought-provoking discussion. Looking forward to next time!

Tags , ,  | no comments

Obscure and Ugly Perlisms in Ruby

Posted by Nick Sieger Sat, 06 Oct 2007 12:39:00 GMT

So, it’s well known that Ruby owes a debt to its predecessor Perl, although some (maybe many) question whether we should repay that debt or even go so far as to put Perl on trial and excise those elements which somehow haphazardly survived the generation gap. It turns out the evidence is mixed.

Update: I use the word “obscure” in the title because, in my experience, they are obscure. “Ugly” is pure opinion, but this is my blog, after all.

Exhibit A: BEGIN/END

Update: Yes, yes, this is an awk-ism, not a perlism, strictly speaking. And I don’t deny its usefulness for pure scripting tasks. I just don’t see its utility in a larger application.

  puts "Bye!"

puts "Processing..."

  puts "One moment while I start your program"


One moment while I start your program

Why would any sane Ruby programmer do this? Have you ever seen a use for BEGIN that isn’t met by simply executing code at the top level of the main program? Geez, BEGIN even has its own node in the AST!

And how about END? If you really need to hook into interpreter shutdown, just use Kernel#at_exit. (In fact, Rubinius currently uses END simply as an alias for at_exit.)

Exhibit B: <> (ARGF)

Thank goodness we didn’t get the diamond operator in Ruby, but we did get ARGF as a replacement. Though obscure, it actually turns out to be useful. Consider this program, which prepends copyright headers in-place (thanks to another perlism, -i) to every file mentioned on the command-line. Any other creative uses of ARGF out there?

#!/usr/bin/env ruby -i

Header =

ARGF.each_line do |e|
  puts Header if ARGF.pos - e.length == 0
  puts e

# Copyright (C) 2007 Fancypants, Inc.

Exhibit C: The Flip-flop

This is a weird beast. I didn’t even know of its existence until Charlie was complaining about having to compile it properly. Apparently we have Perl to thank for this nonsense as well (and, indirectly, sed). With the exception of the sed-ism, I’m not convinced it adds any value -- in fact the code usually ends up looking more verbose.

This program, when run with itself as an argument, prints out everything between BEGIN and END.


ARGF.each_line do |line| 
  if (line =~ /^# BEGIN/)..(line =~ /^# END/)
    puts line


This snippet is a long-hand way to do 5.upto(10) {|i| puts i}.

i = 5
while (i == 5)...(i == 10) do
  puts i
  i += 1

Exhibit D: Output from defined?

Not sure if this came from Perl.

The basic need for defined? in a dynamic language is unquestionable. Instead, I meant to highlight the fact that defined? returns a string value here, which is strange.

Constant =  "Constant"
@ivar = [1, 2, 3]
integer = 10

puts "const : #{defined?(Constant)}"
puts "ivar  : #{defined?(@ivar)}"
puts "global: #{defined?($0)}"
puts "local : #{defined?(integer)}"
puts "expr  : #{defined?(Constant + integer)}"

Running this code produces:

const : constant
ivar  : instance-variable
global: global-variable
local : local-variable
expr  : method

Perl at least is sane enough to return true or false for its own defined operator. But method? Looking at the source, I see also expression, local-variable(in-block), assignment, class variable, true, false, and self. But why would this output be useful? As if it isn’t already plainly obvious what is defined?.

Any other obscure features in Ruby that you love to hate?

Tags  | 24 comments

RailsConf Europe: Hydra

Posted by Nick Sieger Sat, 06 Oct 2007 12:04:00 GMT


On September 19, Craig and I presented our talk at RailsConf, which appears to have been well received. It went off mostly without a hitch, if it wasn’t for a couple of hiccups in the demos. I apparently didn’t practice them enough, because a couple of critical steps were either missed or I did them out of order and confused myself. But that’s ok, because I’m releasing the demo steps, source and slides here so you can try them out for yourself.

So, download the zip and follow along. The contents look like this:


The demo steps are in the text files; I’d recommend going in the order specified. It turns out the third isn’t really a demo but more of a code review, because it also requires you to have Roller set up and I’m not going into those details for now. If you want to just run the demos, skip to demo-baked, the finished product.

For those of you who didn’t see the talk, here’s the basic message.

Look at your basic MVC Rails app.

Single app

Why not consider spliting it into two? ActiveResource allows you to access a RESTful resource in your Rails application like it was just another model.

Double app

This might seem like overkill for a simple application, but what if you had an e-commerce application domain like this?

E-Commerce app

Splitting up your code into separate Rails applications encourages encapsulation, reduces potential coupling, and gives you more flexible deployment options. Basing interactions upon REST and HTTP means that you can more easily mash up data or create caching strategies, given proper usage of ETags/Last-Modified and/or cache-control headers. The great thing is that existing HTTP reverse proxies can be used without having to mix the caching code in with your application code.

In the application we’re building, we have a number components that are not Rails-based. To expose them to our environment, we’ve taken the strategy of exposing a simple REST web service for the component, and then it can be consumed by the other applications using ActiveResource. The REST web service can either be implemented in the component’s native language/technology, or in some cases we’ve written a wrapper service in Rails since Rails makes it so easy to build REST interfaces. In that case, Rails is pure integration -- RESTful glue.

The idiom that makes this all possible is the uniform interface. In HTTP, this means addressability (each resource gets a unique URI) coupled with the HTTP method verbs HEAD, GET, POST, PUT, and DELETE. Inside your Rails applications, it’s the ActiveRecord interface. If you keep your controllers skinny, you can boil the interface down to the following set of methods (in this case, for the prototypical blog post model):

And in fact, this is precisely what ActiveResource provides, and it’s enabled by duck-typing. Walking through the demos illustrates this pretty well, as you’ll basically swap ActiveRecord for ActiveResource with no noticeable difference, all the way down to validation errors in the scaffolded forms (which I was unable to demo in the talk due to the hiccups).

We’ve found that when you’re making RESTful web services, the controllers largely become boilerplate because of the uniform interface. make_resourceful has been a boon in that regard, as the demos also show. There are several plugins that help you DRY up your controllers (other approaches include resources_controller), so you have some choices there.

We mentioned some drawbacks in our experience with ActiveResource, which have largely been addressed for the upcoming Rails 2.0 release.

Finally, we noted that deployment could be a pain with so many Rails applications to keep running. To that end, we are leveraging JRuby and Glassfish to make this a non-issue, as we simply WAR up our Rails applications with warbler and let Glassfish take care of the rest. Performance is still an open question, but we plan to roll up our sleeves and make sure this combination really hums.

Enjoy the demos! Feel free to drop me an email if you have any questions or troubles with them.

Tags ,  | 5 comments

RailsConf Europe: David Heinemeier Hansson

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
# ...
link_to 'Show', [:admin, post]
  • HTTP authentication
class Admin::PostsController < ApplicationController
  before_filter :ensure_administrator
  # ...
  def ensure_administrator
    authenticate_or_request_with_http_basic("Blog Admin") do |user,pass|
      username == "dhh" && password == "123"
  • 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

# initializer
Mime::Type.register "application/x-iphone", :iphone

# In a controller method
respond_to do |format|
  format.iphone { render :text => "Hello iPhone", :content => Mime::HTML }
  • 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 ,  | 6 comments

RailsConf Europe: (Prag-) Dave Thomas

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 ,  | 3 comments

Gig: Speaking at RailsConf Europe 2007

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  | Tags , ,  | 1 comment

Warbler, A Little Birdie To Introduce Your Rails App To Java

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,


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 , ,  | 13 comments

ActiveRecord JDBC 0.5

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:

  adapter: mysql
  database: blog_development
  username: root

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'

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 ,  | 1 comment

...And We're Back

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  | no comments

Gig: JRuby and Glassfish Hackfest

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 , , ,

Older posts: 1 ... 5 6 7 8 9 ... 17