Skip to content

Streaming output from a Restlet resource

This is horrible.  But I am unashamed.  It’s extremely useful to me, too.

Say you have a Restlet resource that needs to do something that is going to run for a long time.  And say you want to know how it’s going, in realtime.

// Inside a Restlet Resource's represent(...) method

PipedInputStream pi = new PipedInputStream();
PipedOutputStream po = new PipedOutputStream(pi);
Representation ir = new OutputRepresentation(MediaType.TEXT_PLAIN){
public void write(OutputStream realOutput) throws IOException {
byte[] b = new byte[8];
int read;
while ((read = != -1) {
realOutput.write(b, 0, read);
OutputStreamWriter ow = new OutputStreamWriter(po);
PrintWriter out = new PrintWriter(ow,true);

// ...

try {
new Thread(new LongRunningBeast(out)).start();
return ir;
} catch (Exception e) {
// return some error representation

( for a prettier version.  WordPress is being rude.)

This trick will let you kick off the LongRunningBeast in another thread, and stream content to “out” as if it were stdout or another relatively immediate trick.  The caller will get this content in realtime, and if it’s something like curl, will display that output in realtime.  Lovely!  Almost as good as interactive shell access.


GitWrite – Blogging with Git

[NOTE: This is cross-posted on my GitWrite blog.]

The first round of Rails Rumble 2010 judging isn’t even done yet, but you can see all the completed entries already.

My favorite of the crop turns out to be from my tweep @greenideas and his Hounds of Gore team: GitWrite.  Here’s their pitch:

Jekyll is awesome. GitHub is awesome. Heroku is awesome. But they don’t do what we want.

We want a place we can push a blog to and get online editing, offline editing in our favorite browser, Sass support and more.

We want to build a WordPress-like experience on top of a Git-based blog.

For a 48-hour application build, it’s pretty and it does what it says on the tin.  Very fun to use; you can pull your blog down with git and post to it with markdown, then push it back up.  Or just use the Web UI, like WordPress.  Themes should be easy to drop in.  For people who like Ruby applications and the git workflow, this is a lot more fun than blogging in a PHP-ruled universe.

My top feature requests (before I go off with a few friends, spend 48 hours and make a competitor … heh) are:

And haml templates and sass, if I can’t already do those — haven’t tried yet.

Anyway, I love it, I hope it wins, and if it’s still up next week I’ll use it to blog from Git Together ’10.


MagLev surprises me

Monty Williams reached out to me after that last post to see whether I’d done similar experimentation with MagLev.  The answer was an embarrassing “no,” since I really haven’t kept up on MagLev development.  Last time I looked at it, I couldn’t get it to do much of anything with my existing apps, and sort of set it aside.

Monty tells me it still has these limitations:

  • It’ll run Rails 3, but not Rails 2
  • No C extensions yet

OK, but I do have some things I can try outside of those restrictions.  At the very least, in memory of poor Benoît, we can fire up the Mandelbrot … great Caesar’s ghost!

Jeez.  MagLev r24407 just turned in the 1000-iteration bench in half the time of any other Ruby I’ve tried so far.

rob@hurricane:~$ time ruby mandelbrot.rb 1000 > mandelbrot-maglev.out
real	0m10.238s
user	0m8.630s
sys	0m1.010s

Did it actually work?  I better check the image.  Yep, that looks like a Mandelbrot set.  Am I using the same computer?  Sure am.  Still singleprocessing on one of the 2 cores?  Yep.

Looks like the topaz vm knows its stuff.  On the 16000×16000 render, MagLev lands here:

rob@hurricane:~$ time ruby mandelbrot.rb 16000 > mandelbrot-maglev.out
real	41m29.750s
user	37m7.030s
sys	3m39.320s

… again, consistently halving the time of the other Rubies.  That’s almost a Python time! Still the worst on the board, but progress.  Since Monty says they haven’t done any special performance tuning, I can only assume that the battle-tested GemStone VM is just getting out of its own way pretty efficiently.

I’m really impressed by this, and several other short benchmarks I tried.  MagLev always smokes the other Rubies.

I’m still pondering what exactly to do with the MagLev alpha, though.

For now, I do still need cext support or easy alternatives like JRuby has.  Despite my best efforts, all my projects use extensions.  To port just about any Ruby project to MagLev, looks like I’ve got hours of work in store.

Before I sign up for that or start looking at the source, I need to get over my IP-phobia. Since this is a commercial product now under the VMWare banner, I’m not sure about the intellectual property underlying MagLev and its patent and trademark issues.  In the trail of GemStone acquisitions over the last couple years, I’m lost as to who holds the IP rights and what licenses and patent grants are really available for the whole stack.  If anyone reading this knows (Monty?), please post a comment pointing me to where I can educate myself properly.  Googling failed me.

Anyway, assuming I get past the cext limitation and IP paranoia, the real reason to play with MagLev isn’t the 2x benchmark gain.  It’s the free pony.

The free pony of which I speak is a robust and mature object persistence layer, with all the appropriate acronym and buzzword compliance to warm the hearts of cold, loveless IT decision-makers.

MagLev’s raison d’être is to create a Ruby environment that can leverage the GemStone object database persistence layer.  This layer is something I’ve only ever heard rave reviews about (e.g. from Randal Schwartz), but really just haven’t actually tried.  Like much about MagLev, it’s a Smalltalk thing, and I’ve never worked in Smalltalk.  Why not?  Lack of acute peer pressure.  I just don’t travel in the right circles.

By contrast, there’s stuff like MongoDB, which I’m actually using in production now, mainly because all the cool kids were doing it.  Yes, Mom, I know.

You know what else is cool?  Saying “rvm use maglev” to cheat on benchmarks.  Thanks for the suggestion, Monty!

Rubinius vs. the benchmark from hell

This Mandelbrot benchmark really highlights Ruby’s weakest bit.  Read the chart.  Breathe.  Fully internalize that the newest, hottest Ruby interpreter takes an hour and twenty minutes to do a simple render that C can do in 23 seconds.

Yup.  Ruby is 200x slower than C here.  The benchmark page doesn’t show Ruby 1.8.7 any more, but if you saw it, it would be more than 500x slower than C.  On Stack Overflow, according to someone who sounds like they know their stuff, the big boost between 1.8 and 1.9 is that Ruby 1.9 can inline some basic math.  I’ll take his word for it; I still can’t read the YARV internals worth beans.

Even with that boost, though, the performance is still bad; everything’s a method invocation, and it really, really hurts to watch this benchmark kick Ruby in its soft and tender bits.

I’ve been very interested lately by the different performance profile of Rubinius.  I feel it has a lot philosophically in common with JRuby, with 100% less Oracle dependency.  Especially once its hydra branch kills the GIL and introduces true multiprocessing, Rubinius could be something I get real use out of at work.

The best way for me to “benchmark” Rubinius is for me to just run my big Ruby apps on it.  On balance for my real-world applications, Rubinius 1.1 seems to perform about the same as 1.8.7, occasionally reaching into the range of 1.9.2.  (@headius will be happy to know that under heavy load, JRuby still beats the snot out of all of ’em.  Different story.)

This is a big deal for me; I could actually make a lateral move from 1.8.7 or ree to rbx and nobody would even know!  Neat.

Except in one case.  I have an old branch of a Rails app, created in-house by another developer, which does a lot of computationally intense operations in Ruby code.  It’s a geo app, and those slow computations made this branch utterly unusable.  In the shipped version, I delegated all that to GeoServer, where it’s quite peppy.  But for giggles, I thought I’d run the original branch under Rubinius.

Okay, I admit, it still sucked out loud.  But it was doing its work in much less time than on 1.8.7.  Which made me wonder, and made me get out a copy of this depressing Mandelbrot bench.

Rubinius, shockingly, beats 1.9.2 by a noticeable margin on this benchmark.  At 1000 iterations, with the JIT very aggressively set, despite the horrifying spaghetti being dumped out by the compiler for this simple bench, 1.9.2 has the win.

Ruby 1.9.2:

rob@hurricane:~$ time ruby mandelbrot.rb 1000 > mandelbrot-yarv.out
real	0m19.387s
user	0m19.380s
sys	0m0.000s

vs. Rubinius:

rob@hurricane:~$ time rbx -Xjit.sync=true -Xjit.call_til_compile=1 mandelbrot.rb 1000 > mandelbrot-rbx.out
real	0m20.802s
user	0m19.360s
sys	0m1.120s

But when you take out the compilation time and run for longer at a steady state, Rubinius starts to win!  Rubinius takes the lead, on my machine, somewhere between 2000 and 2500 iterations.  On the full run (a 16000×16000 render), Rubinius crosses the finish line a whole minute ahead of 1.9.2.  Whoa.

[Edit] Here are the final standings amongst the legitimate contenders (leaving 1.8.7 out, ’cause who has that kind of time?)

JRuby: 85m49.466s
1.9.2: 85m10.357s
Rubinius: 83m49.293s

[Further Edit] Read the comments below.  Rubinius’s Brian Ford links to a gist which explains what’s slow, and optimizes the test script to cut the execution time substantially — almost in half.  Haven’t tried it yet, but wow!

What’s potentially very neat is this: as near as I can read the JIT’s output as it flies by, Rubinius’s math *isn’t* being inlined. Looks like all ordinary object operations to me.  And based on another quick looping 5-line bench I wrote, floating point divides in Rubinius continue to perform tragically, whereas they’re almost free in 1.9.2.

So I’m guessing — and hoping — that Ruby 1.9.2 and Rubinius have each optimized a completely different aspect of the problem.  This bears further study!  If the approaches can be combined, it would be great to get Ruby up into the range of merely crummy performance (like Python) on this benchmark, and out of the embarrassing basement.

If the improvements are indeed multiplicative, this would bode well for the ability to do some compute-intensive operations directly in Ruby from time to time when expedient, without always having to drop to a language with primitives and less OO noise.  In practice, I see people getting away with little compute-heavy Python scripts all the time.  I see nobody daring it in Ruby 1.8.7, for obvious reasons.

Three cheers for Rubinius and Evan Phoenix, anyway, for being the non-JVM Ruby to win this horrid bench for now.

A little love letter to the USPTO

On Monday, the public comment period expires for the USPTO’s upcoming guidance in the wake of the Bilski decision.  If you hate software patents (or love them) now’s the time to get your licks in.  Here’s what I had to say:

I am not a lawyer.  I am a professional software engineer, an innovator and inventor, and a U.S. citizen.  My livelihood depends on the ability to effectively research and develop creative software solutions to real problems.

The patent system theoretically exists to protect the rights of inventors.  However, I can personally attest that in my industry, computer software, the system achieves exactly the opposite.  Software patents are a heavy, leaden weight around the necks of software inventors like me, and I would like the USPTO to take a strong stand in the wake of Bilski and exclude them from consideration altogether.  I think the Bilski decision hints that the Court leans this direction, but as I said, I am not a lawyer.  I just believe this guidance affords a unique opportunity to undo a misdeed.

Software moves quickly.  The ability to innovate is equally available to anyone.  Many, if not most software ideas can be brought to market worldwide with less time and funding than it takes to acquire a U.S. software patent.

This results in a situation where software patents are predominantly pursued by professional “patent trolls” and large well-funded entities scarcely in need of patent protection itself, but desperately in need of a defensive screen against patent system abusers.  This situation creates only drag; it adds no value.

As I’m sure you well know, software patents are impractically difficult to examine, and this situation only worsens over time.  With untold billions of lines of software code in use around the world, much of it in private or closed systems, prior art is effectively impossible to discover.  I share the wide belief that many of the extant U.S. software patent awards are invalid; a quick scan online finds dozens of examples where my own prior art overtly invalidates the claimed innovation.

I also believe that the “non-obviousness” test is also broadly failed; I would go so far as to say that most U.S. software patents would have been obvious to any other researcher in that specific field at the time of the claim.  Patents filed in my areas of specialization are often laughably obvious to me as a specialist.  But were I to put myself in the examiner’s shoes, I don’t know that I could do any better; no one can be an expert in every focus within this immense field.

So software patents, by and large, are simply awarded to whichever entity is willing and funded to do the legal documentation necessary.  The burden of proving the invalidity of these patents falls on the people least equipped to play the game — individual innovators and small software entrepreneurs.  This helps no one, and is a truly sad inversion of the intent of patent protection.

I cannot imagine solutions to these practical problems.  The software patent system is broken, and only hurts who it is meant to help. It stifles innovation, rewards abuse, and wastes public resources on a nonexistent problem.

Please, exclude software patents altogether from your forthcoming guidance.  This will be a good deed for me and all the millions of software engineers like me in the United States.  It will free the USPTO to focus on intellectual property protections which do good and not harm.

“Entrap and extort”

Like many, when Sun open-sourced the JDK in 2006, I shouted Huzzah, and utterly missed the shell game being played with the patent portfolio backing it.  Let’s review the strategy briefly:

  1. Release an implementation of your patents under GPL2, which has no implicit patent grant
  2. Offer a patent grant only to fully spec-compliant derivative works
  3. Withhold the tools necessary to achieve compliance

Stalling there, as Sun did, this strategy was just messy and incomprehensible.  I can kind of see how it propped up Sun’s implementation and struggling business model; I suppose screwing with high-velocity projects like Apache Harmony was merely an effective equalizer.  But when Oracle came along, they knew how to add their special sauce to turn this into a money-maker.

Oracle knows:  It’s not profitable to merely entrap someone.  To profit, you must also extort them.

Oracle loves to use this entrap and extort strategy with NGOs.  They donate “millions of dollars worth” of software to worthy organizations — taking tax write-offs on those donations, of course — and then in due time, Oracle comes knocking to claim its six-figure annual maintenance payments on its gifts.  Unfortunately, I speak from personal experience with these situations!  In a couple of cases, the Oracle maintenance demand has been as big as the entire annual software development budget for the affected business unit.  In one case, the software had never even been used.

Microsoft’s legendary embrace and extend strategy is practically angelic compared to entrap and extort.  Microsoft wants to beat its competitors.  Oracle prefers to beat its customers until they’re scared to go to the competitors.

In case you missed it, in the Oracle vs. Google suit, Oracle’s demands include the impound and destruction of all infringing copies. I get this Ray Bradbury image of  jack-booted thugs appearing at my door, and wresting my expensive Android phone from my cold, sweaty, terrorized hands.  Laughing, they throw it into a wood chipper marked “Contraband.” Mercifully, they move on, because they they have to confiscate a phone from just about everybody on my street.

That’s no accident.  I’m supposed to get this image.  I’m supposed to be afraid.  Oracle’s Nazgul lawyers did their best to saturate the whole claim with the Black Breath of fear.

But all that horror could be avoided, if those dirty Google bastards just agree to pay … wouldn’t that be easier?  Can’t we all be friends then?

No.  We cannot.

I see some respectable people now pledging that Oracle will never get another dime of theirs.  While I’m there in spirit, they never have gotten a dime of mine.

But one thing I can do is cease to use Oracle’s trademarks, including the one that describes James Gosling’s language work.  I can move away from products or projects that in any way are tied to Oracle and its acquisitions.  And I can step up my effort to contribute to serious alternatives that allow others to flee Oracle’s extortionate practices.

For one thing, I get to use a lot more Ruby and Go, and that makes me quite happy.  I might even use some more C#. And when I’m using Gosling-speak, I’ll be darn sure to use it on Apache Harmony or Android.  At least until the jack-booted thugs come.

Scala as a second language? Not for long

I really feel like we’re within 6 months of my ability to abandon Java for Scala permanently.  Let’s rehearse why Scala’s currently my favorite language: cross-platform, type-safe, reasonably fluent, and interoperable with anything on the JVM.  But, there’s another reason: pace.

The people behind Scala are smart, and they listen and learn.  While they’re not afraid to change things, they don’t just leap on every nutty idea either.  I just started using some of the features in 2.8.0, and discovered much to my surprise that they’d captured most of the missing essential fluency benefits that I’d come to love working in C# for a while.  Bless named parameters.

I don’t have any serious beef with Java other than that it’s totally showing its age.  Seriously, can we really debate the wisdom of adding closures to the language for a friggin’ decade?   (Odersky’s wings-to-an-elephant comment is what won me to Scala in the first place) Dear Java: when Microsoft seriously outpaces your rate of change and growth, it might just be time to hang up your spurs.

Now, as to why I don’t actually write very much Scala for-real at-work yet:

The IDE support has been pretty wack.

While it’s all cool at hackathons to show off my vi-fu and build with sbt, for-real at-work I need a solid IDE.  I’m working on multi-participant projects most of the time, and I need things like code completion, jump-to-declaration, and so on.  Yes, I can be really clever and do it with TextMate.  No, I don’t want to.  I want Eclipse or NetBeans (preferably Eclipse) to just work.

Solved: The Scala IDE project’s output is getting quite good.  Eclipse 3.5.2 has a serviceable 2.8 Scala plugin that doesn’t crash too much.  It does mixed Scala/Java pretty well now.  If only it worked on Helios, I’d be ecstatic.

Making OSGi plugins with Scala has been hard.

For about 2 years, I’ve been able to demonstrate that it’s possible to create an OSGi plugin with Scala, if you stand on your head, squint, and repeat some magic incantations.  (e.g. build it all with ant and some custom classes, fudge around with the .project file in Eclipse, etc.)

I’m not the only one who cares about OSGi and Scala — have a look at ScalaModules for a really ambitious project.  Still, not quite …

Almost solved: It’s now a simple matter to add the PDE nature to a Scala project in Eclipse, and nothing blows up.  But the builder still doesn’t work right — you get source .scala files instead of classes in your exports.  You can include /bin in the definition as a quick workaround, and the bundle works, but it’s sloppy and still contains source.

I’m hoping it’s … well, not trivial, but achievable … to mutate the Scala builder to do the right thing for a PDE build.  I’m also hoping the Scala IDE guys won’t mind a patchset that lays out an sbt/Maven-style project AND still does the right thing under the Eclipse Scala builder.  I’d like something that Hudson could build with sbt and a human developer could build with Eclipse export.

You can’t use Scala in GWT.

Well, you still can’t, but we’re solving that.

You can’t use Scala code on Android.

There are two problems here — getting the code compiled, and linking to the Scala libraries.  Somebody on the Scala-IDE wiki has got a pretty ingenious solution here.  The documentation kind of vanishes near the end, so I’m not sure if it actually works, but it looks like it might.  I’m wondering if we won’t have to do something analogous with Scala+GWT, as there’s a fair bit of the Scala standard library that would end up getting slurped into any non-trivial Scala+GWT application.

Once we wrap these last two issues, I feel like I can banish Java from my life altogether and just write Scala code.  I’ll be happier.