Product Management

As a Staff-level Software Engineer, this post by Joel Spolsky best describes my standard of excellence for Product Managers – mostly in terms of the degree of attention to detail and technical aptitude that I would expect from a self-respecting, ambitious Product Manager.

Even though Joel is talking about his experience as a Program Manager at Microsoft, most product managers I have worked with at Google and elsewhere function at least partly in the space of a Microsoft Program Manager as described here.

The Software Business

I was reminded today of a quote by Bill Gates I had read 6 years ago in then-Sun Microsystem’s just-ex-CEO, Jonathan Schwartz. Here it is:

The software business [is] all about building variable revenue streams from a fixed engineering cost base

This is from Schwartz’s Good Artists Copy, Great Artists Steal post, which is also very informative about how Software Patents are used in practice.

The above is an important definition for everyone involved in building software to keep in mind and never lose sight of.

WordPress on AWS


I had been running my WordPress blog on a shared hosting account at for the last eight years, when about a month ago I decided to consider alternative solutions. In particular, I wanted to see if I can lower the cost of running my site. Here was my starting point:

Web Hosting from $71.40 / year (paid in 2-year increments)
Domain Registration from $10.87 / year
SSL Certificate from (promotion) $1.99 / year

Given that my blog gets very low traffic, I decided to give AWS a shot. With microbilling, I thought I should be able to drive the cost of my hosting even further down from the already low $6.86/month at hostforweb (for comparison, a blog hosted on costs $8.25/month, billed yearly, and that does not even include google analytics integration, which I can easily add for free to my self-hosted wordpress site).

TL;DR; I was wrong. Hosting on AWS is more expensive with a lower level of reliability, scalability and higher management overhead.

Just the cost of running the t2.micro VM instance is $9.36/month, and that does not include the cost of the RDS instance and the ELB.

I will share the details of my experience in a later post.

Dart vs Java (cont'd) — Richards and Tracer

This week I managed to port the rest of Dart’s benchmark_harness examples to Java.

The experience of porting Richards and Tracer was as smooth as that of porting the DeltaBlue benchmark. The only unfamiliar (and interesting) Dart feature I encountered that is worth noting was the ability to declare and pass method parameters by name.

Here are the numbers:

Richards Benchmark

Tracer benchmark

The results this time are limited to two recent nightly releases of the Dart SDK (22577 and 22720), and 32-bit and 64-bit Java. I ran each benchmark 3 times to warm up, and then 5 more times and took the best time of the 5 runs as the final number you see on the charts.

I did a lot of experimenting based on feedback I got on the Dart mailing list. I am well aware that Java needs to run a method some number of times before the JIT kicks in, and of the caveats of OSR. However, in my tests I found no substantial differences when running the benchmarks with a longer warm-up time.

Java 8 results were not different enough to warrant inclusion in my tests. I test both Java and Dart VMs with default settings, and do not intend to tweak custom VM flags in order to optimize each VM. It is obvious that a lot can be done by tweaking various VM parameters. My goal here is to get a gut feel for the relative out-of-the-box performance.

I was told that for a fair comparison Dart should be evaluated against the 32-bit client JVM, as the Dart VM is also optimized for use on client devices (with more focus on things such as faster startup vs long-term throughput). Hence, I include the 32-bit Client JVM in my tests. However, for all practical purposes, 64-bit JVMs are more relevant and in-use nowadays, so I feel obliged to still include the 64-bit server JVM in my tests. There is no client version of the 64-bit JVM by the way. To be fair, 64-bit compilation does have the advantage of access to a much larger set of registers, which can be used to gain performance.

Dart vs Java — the DeltaBlue Benchmark

As of the time of this writing the performance page on tracks Dart VM performance as measured by the DeltaBlue benchmark.

I ported the benchmark_harness Dart package (including the DeltaBlue benchmark) into Java and ran against the latest Java 7 and 8 JDKs.

The experience of translating Dart to Java was surprisingly smooth. Some of the most common small porting tasks included

  • Dart bool to Java boolean;
  • Dart C++-like super call syntax;
  • Dart constructor syntactic sugar;
  • Dart shorthand (=>) functions to Java full format;
  • Wrapping Dart top-level functions and variables inside a Java top-level class;
  • Changing the use of the Dart Function type to a Java Runnable;
  • The Dart truncating division operator ~/, which apparently is equivalent to plain division (/) when applied to integers;
  • Dart list access [] operator to Java List.get()

The trickiest part of the translation was the following piece of code that appeared absolutely befuddling at first sight:


As it turns out, this is simply an array literal


prefixed by a generic type parameter specifying the type of the elements in the list


and followed by the list access ([]) operator, getting the element of the list at index value:


After working my way through this, the translation went smoothly, until I got to run the benchmark and hit a NullPointerException. In DeltaBlue, the BinaryConstraint constructor calls the addConstraint(), which is overridden in its subclasses. The ScaleConstraint sublcass implementation of addConstraint(), in particular, accesses ScaleConstraint fields that are initialized in the constructor. This pattern works in Dart, where apparently “this” constructor arguments are stored in their corresponding instance fields before the super constructor is invoked. Since this is not possible in Java (the super call must be the first statement in the constructor), I moved the addConstraint() call from BinaryConstraint to each of the subclass constructors. With that fix, the port was complete and I was able to run the Java version of the benchmark.

Here are the DeltaBlue numbers for Dart and Java on my ThinkPad W510:

Dart (22416)    2,810.39    355.82
Dart (22577)    2,283.11    438.00
Java (1.7.0_21-b11)    2,728.51    366.50
Java (1.8.0-ea)    2,693.14    371.31
Java (1.7 32-bit)    3,555.95    281.22

Update 5/11 More numbers: running for 45 seconds improves the performance of the 64-bit JVM (1.7,45s) but not the 32-bit one (1.7 32-bit,45s); the 32-bit Server JVM (32-server,45s) performs just as fast as the 64-bit JVM; the xxgreg version (xxgreg,45s) of DeltaBlue runs slower on the 64-bit JVM than my version ported from Dart; the xxgreg benchmark (xxgreg-run) uses a different harness and measurements include VM startup and warmup time.

Java (1.7 32-bit,45s)    3,533.99    282.97
Java (32-server,45s)    2,701.67    370.14
Java (1.7,45s)    2,559.38    390.72
Java (xxgreg,45s)    2,780.61    359.63
Dart (xxgreg-run)    2,356.70    424.32
Java (xxgreg-run)    2,800.10    357.13

The number in the first column is the runtime in us as reported by the benchmark harness at the end of a run. The second number is the score as defined on the performance page: “runs/second.” I ran the benchmark on each VM multiple times and as the variance between runs was small enough I picked the result from a random execution for each VM.

The first Dart VM (22416) is the current public release available on the Dart website, while 22577 is the current nightly build. I included the nightly build, as it is clearly visible on the performance page that Dart saw a major gain in performance as of build 22437. My test confirmed this observation.

The results are truly impressive. Dart, still a baby at 2 years of age and pre-1.0, already exhibits 15% better performance than Java, a veteran of 18 years. I think this truly deserves to be called a case of David vs Goliath.

Update: Both Dart VMs tested are 32-bit, while the two original Java VMs are 64-bit. Tested with the 32-bit Java 1.7.0_21 VM with even more disappointing results.

On Openness

I am a firm believer in openness. That is the reason I believe open source has such great value. The way I see it, the word open in “open source” does not just refer to the source code: it also means open communication, open structure, open management… openness in every aspect of a project.

Yet, in one of my own projects I failed to abide by my own principle. Two years ago, at the end of the summer of 2008, I left my small GSoC project – a split editor for Eclipse, in the state of a working prototype to begin a full-time job and join a master’s program. For two years now I have neglected the split editor project and kept in complete silence to the point that people have even forgotten that there was ever anyone involved in this effort.

I am now nearing the end of my master’s program and with all classwork completed am getting ready to begin work on a thesis. Before I do that, however, I wanted to clarify the state of affairs of my split editor work. I have not forgotten about it, and I am determined to complete it eventually. Although I will not have any time to dedicate to this work for another year, it is first on my queue of side projects after completing my master’s.

Actually, if anyone is willing to pick up the work now, I will be more than willing to provide whatever support I can. Here are the patches with my latest work, updated against the current Eclipse release as of the time of writing – 3.6.1 (R3_6_1 label in CVS):

The file contains four separate patches for the four Eclipse plugin projects involved in the split editor implementation:

  • org.eclipse.ui.workbench – this project contains the bulk of the split editor work.
  • org.eclipse.ui,
  • org.eclipse.ui.editors,
  • org.eclipse.jdt.ui – the above three projects contain mostly configuration changes to activate the split editor for Java and Text editors.

To see the split editor in action, check out these four projects from the Eclipse CVS repo (at label R3_6_1), apply the patches and start up an Eclipse launch configuration. If you want to try this but get lost or none of this makes sense, post a comment here and I will be happy to provide more detail.

I have always wanted to make it very easy for people to try out and experience the split editor at the earliest possible stage of its development (at which it stands currently – there are quite a few known bugs). The best way I see for this would be to share a custom build of Eclipse with the split editor work compiled in. Unfortunately, I have never been able to successfully build Eclipse from source. I gave it a shot two years ago, and more recently, I spent the last two months frantically trying to build the Eclipse 3.6/3.5/3.7 SDKs, without any success. It seems like I am not alone in this. If at any point fortune strikes me, you can be certain that Eclipse packages with split editor support will appear here immediately. If anyone is willing and able to help with this, please get in touch!


Integrated split editor prototype

A new split editor prototype that is integrated into the Eclipse workbench API has been available as a patch on the Eclipse Bugzilla for some time now. Unfortunately, I have not able to create an easily deployable plugin that can be installed easily in any Eclipse 3.4 distribution (by copying to the dropins or plugins directories). Even if I did I would probably have to worry about the legal aspects of redistributing Eclipse code, since the plugin will no longer only contain my code.

That said, you can test out the latest split editor by checking out the o.e.ui.workbench project in Eclipse, applying the patch from bugzilla, and debuggin Eclipse from Eclipse. There are no immediately visible changes, but it would be very helpful to have as many people as possible test the split editor in everyday use. I do not expect a lot of users to go through the above procedure, however, and so I will keep trying to get an easily installable package out.

Next time I will talk about the internal integration design of the split editor because I believe this is the most interesting part of all. This will be of particular interest to Eclipse plugin developers who want to know how to enable editor splitting for their custom editors.


There is no new Java split editor yet.

I got overwhelmed by new issues that I discovered while testing last week’s prototype including the fact that most preference changes do not propagate to both editors or cause exceptions.

I am looking into the alternative MultiEditor-based approach and this is leading me to some interesting ideas that I am about to try out… so there should be interesting split-editor-related stuff coming soon.

Working prototype of Eclipse split editor

The first working prototype of a working split editor is here. You can download it and play with it in Eclipse 3.4.

Basic functions like text cursor, current line highlight (these did not work in the first prototype), undo/redo, cut/copy/paste, status bar items (insert mode, line and column numbers) work fine and stay in sync when switching between the top and bottom half of the split editor.

There are also some known issues:

  • Ctrl+Left/Right/Home/End keyboard shortcuts always operate on the top part of the split editor, even if the cursor is (blinking) in the bottom half.
  • Navigating back and forth using the Alt-Left/Right keys browser-style does not remember the correct editor along with the location and doe not move between the top/bottom half of the editor. I actually have no plans of fixing this. This problem also occurs when opening multiple editor tabs.

Here are some images that demonstrate how to open and use the split editor.

First select the Open With dialog…
Split Editor 1

Then select the [Split Text Editor] option…

Split the Editor by clicking and dragging on the narrow line that runs all the way across above the first line.

And there you go… long live the split editor!

You can try different commands out and see if they work when you move between the two sides (top and bottom) of the editor…

That’s it for now. Enjoy!

Bonus The plugin now includes source code so you can see the kind of monster that lurks in the background to make editor splitting work.

Up Next Next up is a java code splitter, after I resolve the remaining known issues with basic editing functionality. I will also put up an update site for faster/easier delivery of future updates.

First split editor prototypes available

In the true spirit of “release early, release often” I am making my first prototype of a split editor available now as an Eclipse plugin. The plugin works in the new Eclipse 3.4 Ganymede. Download, place in your Eclipse dropins directory and you’re set to go.

Instructions on how to test the plugin are available on the wiki.

Keep in mind that this is a very early prototype and it barely works. There are a lot of issues. If you do download it, please feel free to share your experience with me by posting your (encouraging/bashful/hateful/frustrated/…) comment to this blog or the wiki.

There will be lots more in the coming weeks, so stay tuned!