Table or Booth?

The Real Competition

Wow, NetBeans vs. Eclipse has been quite a pot-stirring debate!  I should've expected it when the Sun evangelists, themsleves, are involved.

Eclipse/NetBeans Popularity (ENP) Index

Javalobby has been stirring with NetBeans buzz and I've had some unexpected interest in my "NetBeans vs. Eclipse - No Real Debate" post.  In the end, to businesses such as webMethods, what's really important is knowing how viable each will be as an application platform.  One way to measure viability is with raw popularity; enter the ENP Index.

NetBeans vs. Eclipse - No Real Debate

NetBeans vs. Eclipse.  This used to be a flashy debate but is losing luster with the rapid adoption and growth Eclipse as a platform for developing rich client applications.  Perhaps this will explain why.

Flat Spot Shifting

I bought a new mountain bike recently and learned something pretty quickly: just as you begin a descent, immediately followed by a sharp uphill section, make sure you shift in the flat spot, just before heading downhill.  Not doing so forces you to either pedal to shift as you gain speed on the downhill or try to do so later on the uphill side.

If shifting on the downhill is even possible, given the slope angle, it requires pedaling, giving you even more speed at a time when gaining speed is already handled nicely by gravity.  Waiting to shift until you hit the uphill part causes you try to shift into the proper uphill gear right during some of hardest pedaling work you'll have.  Trying to shift during this max effort time tears up your gears and just brings you to a grinding halt (literally).  If this happens, depending on the hill, you may as well dismount and carry your bike the rest of the way.

It doesn't matter if the uphill section is short and steep or long and gradual, you're best off shifting in the flat spot before it.  As I was getting into the hang of this the other day, it occurred to me that it's quite true of commercial software development as well.  With enough practice, we should be able to predict the more demanding parts of the development cycle and prepare accordingly.

So, what kind of shifting do we need in the software world?  The group I work in starts study groups, where we pick a good book, divide it into reasonable chunks, and then have group discussions on them once a week.  Another idea floated by Luis recently is to plan for less critical training projects that give everyone a chance to work with some different technology.  It's also valuable at times like this to do team-oriented fun stuff that isn't so work related.

All of these things help us to shift gears in the flat spots.  It also suggests that flat spots should be put into the plan, if possible.  Eclipse.org's contributors have nice, big flat spots in their plan every six months.  The nice thing about tight iterations is that you get more chances to do this.  Trying to change into an easier gear during the toughest part of the development cycle forces inefficient context shifts and seldom moves things ahead any faster, if at all.  How quickly this is forgotten at times.

Painfree RCP in 3.1M5

This is the blog-workout sequel to my carefree "Eating the Eclipse 3.1M5 RCP Donut" post.  Presented here are four simple recipes for using the new 3.1M5 capabilities to create, configure, and export a Rich Client Platform (RCP) application out of one or more plug-ins.  It can all be done graphically and completely avoids messing with plugin.xml or hand-editing a .properties file.  Thanks, Eclipse RCP team for giving us this exquisite feature!

When Broken: Fix it

"If it ain't broken, don't fix it."  Like Dave Thomas and Any Hunt, who encourage fixing "Broken Windows" in their timeless book The Pragmatic Programmer, I prefer "If it's broken, fix it."  The only other option is to stop using it.  The assumption about unnecessary fixes is often that the machine cannot handle change well and will probably run best if left alone.  This may be true but the machine might still be severely lacking.

Fixing broken things applies as much to machines as it does processes.  If you find yourself in a broken process, you can either let it beat you up, fix it, or just exit stage right.  More often than not the best alternative is to fix it.  And yet, oddly enough, it seems most people's m.o. is to get the snot kicked out of them until they finally just leave, defeated.

Insist on the Fix
A better plan is to reject status quo and push to fix the problem.  This can be instigated at any level.  Often problems and their solutions aren't noticed where you'd expect they should be and fixing things means breaking out of baked in patterns and even, occasionally, talking to people who don't think things should be fixed.  In The Pragmatic Programmer, chapter one, section three, titled "Stone Soup and Boiled Frogs,"  Thomas and Hunt suggest avoiding the blank stares you'd get by asking permission to fix something:

Work out what you can reasonably ask for.  Develop it well.  Once you've got it, show people, and let them marvel.  Then say "of course, it would be better if we added..."  Pretend it's not important.  Sit back and wait for them to start asking you to add the functionality you originally wanted.  People find it easier to join an ongoing success.

If You're Wrong...
It also means occasionally being told to slow down because "It ain't really broken, Gungho."  And they'll probably respect what you're doing enough explain why.  So, the worst that can happen is, you'll learn how to stop worrying about whatever it was you thought was a problem.

New Math

The bizarre world may be the most interesting when explained by its witty rationalists.  Regarding procrasination, this had me chuckling: http://jamie.ideasasylum.com/2005/03/distraction-operator_02.php. 

It may have been intended only in jest but, if taken seriously, perhaps it would be useful in measuring how tasking and the work environment affect productivity?  Making this supposition ¬ Doing actual research to make something useful out it :^)

Open-Source: Offense or Defense?

Simple economics apply to any software strategy and should not be ignored.  This is equally true with respect to open-source software. Using it is often a no-brainer.  Building on top of it requires more deliberation but is still a fairly straightforward decision.  The harder question to answer is "Why might I contribute my software to open-source as a part of my business strategy?"

Eclipse Con 2005: Visual Studio

The speaker was so well rehearsed it was unnatural.  His words seemed carefully chosen and were perfectly consistent, each one associated with this feature or that.  He spoke in trademark terminology and seldom referred to useful abstractions like "extension" or "plugin."  The contrast to every other session I'd attended thus far was striking. 

He spoke a little fast but you had to forgive him; it took guts to give Visual Studio (VS) presentation to a den of Eclipse-developer lions.  I was open-minded, hoping he would compare VS's extension mechanisms to Eclipse's.  The growing .Net customer base is nagging knowledge that, someday, we might require increased support for VS extensions (along with Eclipse).  I wanted to know how I could write plugins in such a way that they could easily port to VS, later, if necessary.

The first line out of his mouth was (paraphrasing) "Visual Studio is, without question, the world's premier development environment..."  Just walk up and whack the lion in the jaw why don't you?  Not a good start.  He then proceeded to show us a cube-block diagram of the VS layers.  The VS Core, Team Server, and something else was positioned along the x-axis, at the base layer.  At the next layer, various language (C#, etc) silos stacked on top, along the y-axis.  Vertical industry 'packages' stretched from each language silo towards the center of the cube, along the z-axis.  Spheres indicated a certain customizable combination of related elements from each axis.  It was colorful and slick.

He went on to talk about five things that "...if I know developers, I know are important."  I thought, OK, here comes the meat I was looking for.  Each iteration his five-point-plan began with "And if I know developers, I know that..."  But the meat never came.  All we got was a garden salad explaining how we could create macros, move view/editor menus around, set code-preferences, or... I forget.  Call the lion an idiot, why don't you?  Eclipse can do macros and change code-prefs?  Who cares?  I've come to expect this stuff from my IDE like a carpenter expects a saw.  My buddy looked at me incredulously at this point.  I was embarrassed for the presenter. 

VS is extensible but, at best, it's unexceptional and, at worst, superficial.  It can probably be extended in interesting ways but it wasn't presented to us this day.  With limited exposure to VS at this point, as best I can tell, extensibility is not part of the VS ethos. 

One difficulty seems to be the lack of terminology for discussing extensions to VS, where extending it is the primary goal.  In the end, VS seems to be just an IDE for .Net, not a platform for extensibility.  This is great if you're building solutions on .Net but it's in stark contrast to the openness of Eclipse.

But the Eclipse-lion abuse didn't end there.  He plowed ahead, moving smoothly into a lengthy overview of the various levels of the Microsoft VSIP program.  I stopped listening intently and drifted into an acute awareness of the difference between Microsoft's and Eclipse's view towards developers.

Microsoft wants your money while Eclipse.org just wants your contribution.  To quote my buddy Zack, "I love how people at this conference ask questions about getting more Eclipse support for this or that... The answer is always either 'It's being considered by X,Y,...' or 'Do you want to write it?  We'd love for you to help us out with that.'"  He's right; Eclipse.org has the feeling of community ownership on a scale unlike anything else in the history of software.

I don't remember how the presentation ended, but it didn't end well.  His pointer for writing code that plugs into both Eclipse and VS was to "Write your own abstraction layer if you want to."  Thanks.  Several conversations later, the consensus was that we all felt like we'd just been given a sales pitch.  It was offensive.  This guy wanted to sell us something.  All Eclipse is selling is lots of free, highly useful code and a belief that everyone will be better off if each of us stops reinventing the wheel and focuses on building real value for our customers.

Eclipse Con 2005: Google on Scaling

Googles scaling strategy was integral to their search dominance and later emergence as a major player in this net-based software era.  This is a live blog of the Google keynote, presented by Urs Hoelzle at Eclipse Con 2005.  It briefly explains how they approached and solved the scaling problem.

They use cheap, commodity hardware, not high-end servers.  Lowers cost/CPU allowing for greater redundancy.  But, this increases potential maintenance.

They run Linux.

To win, they planned to fail; seems to break basic rules for success but actually it's smart.  When you have hundreds or thousands of servers, expected hardware failure at any rate makes efficient responses to these failures less than trivial. 

Urs took us through a few unbelievable, humorous slides showing their hardware progression from the late 90s on.

Redundancy is a Google core value.  Not losing data is central to Google's business so, it makes sense.  Requires reliable infrastructure building blocks.  To achieve this Google realized several useful abstractions:

Google File System (GFS)

• GFS Master manages metadata; these are replicated
• 64 MB file 'chunks' are managed Chunkservers, also replicated 3X
• Chunks also triplicated for fault tolerance. 
• GFS client servers directly access the GFS Master and Chunkservers

Basic Computing Cluster

• Needed massive parallelization and distribution that are easy to use
• MapReduce solves the problem.  MapReducing = mapping + reduction.

Map: take input k/v and produce set of intermediate k/v pairs
Reduce: emit final, condensed k/v pair - these are sorted, merged search results

MapReduction is so redundant that, in one unplanned test, they lost 90% of their reduction 'worker' servers and all of the reduction tasks still completed.  Now that's fault tolerance!

Regarding Query Frequency, he showed several successive graphs where frequency of
"eclipse" searches, before Eclipse.org, peaked every three years
"world series" searches peaked every year
"watermelon" peaked during the summer

Funny but, more importantly, Google uses these patterns to learn from the data.  This learning process is broken into two basic steps: establishing relationships between searched data, then clustering the related documents for relevant search results.

It was an interesting talk.  Their scaling approach isn't mind bending but it's sooo effective.  What's most fascinating to me is that they had the audacity and forsight to tackle the problem at the beginning.  For more information on How Google Works, go here.