This is not one of those times: the art in software engineering is most evident when building compelling visual interfaces, something Palantir knows a thing or two about.

A demo reel is an industry term in the movie business — a short reel that acts as a portfolio when applying for jobs, a highlight reel of the author’s visual career. We’re not in the movie business, we’re in the software business. We do, however, use moving pictures to tell stories, stories backed by data — this is our demo reel: two-and-a-half minutes of data visualization and user interface eye-candy (It has pounding music — you may want to put on headphones or turn down your speakers.):

The movie will take a few seconds to load. It’s 800×600, so expanding to full-screen is suggested. We’ve done our best to create a streamable-yet-good-looking video. The compression artifacts are there, but shouldn’t be too distracting. In a real Palantir client, there are no compression artifacts and everything looks even better than it does here.

The Palantir family of products is much more that just pretty pictures; we have the underlying intelligence infrastructure to make those realtime animations possible and (more importantly) meaningful. That said, we sure do think they’re pretty.

By the way, if you’re interested in the progression of our interfaces, this not the first time we’ve posted eye candy: we posted a set of updated screenshots a little over a year ago; think of this as the next installment in the series.

And yes, it’s really all Java Swing.

“Freaking lag!” It had started to become a common refrain around the developer pit. Listed as a project on a candidate’s resume, MultiSnake was a game that we had started to play during our coding breaks. The game was really quite fun — it was easy to play, games were short, and its multi-player nature fostered great competition. The only real drawback was that we seemed to experience network lag. There was nothing more infuriating than having your long snake die by running straight into a completely avoidable wall because the game lagged and didn’t respond to your keyboard commands in time. During one of our particularly lag-heavy games, someone yelled out a gripe that would change our MultiSnaking days for good: “Man, we could totally write this game ourselves, in our app.”

The gripe stuck around, and one day someone finally called out the person making the claim. “Do you seriously think we could write this ourselves?”

“Sure, why not? We have all of the architecture that we need to make this work. We could do it in four hours.”

“I bet you we couldn’t.”

The rest of the story and a video of MultiSnake in action follows.

The Challenge

A challenge was born. The task sounded fun, and it also provided us with a great chance to test the extensibility of our platform. Our most recent milestone had focused on solidifying the public APIs of our platform, and this challenge seemed like a way to test its pluggability. We also thought that it would be a great showcase to demonstrate how easily one could add capabilities to our platform — if we could write a multi-player network game using only the same public APIs available to our clients, it would be a strong signal that our framework was solid.

The Rules

Once we decided that we were going to take on the challenge, we decided that we would do it on Sunday from 8:00PM to midnight (our normal peak productivity hours) and laid out the following rules:

• There would be a strict four-hour time limit for all planning, design and coding.
• The game had to be implemented using only our public APIs — no touching core code.
• The game had to support all of the features provided by the online game and had to be lag-free (after all, that was the whole point of writing our own!).

The Race

Sunday night came along, and it was off to the races! We projected a countdown timer onto a whiteboard in the middle of the developer space, blasted some techno music and got to work! Five developers decided to participate, and it was a pretty collaborative effort in which most of the participants ended up contributing in their standard roles — the frontend people did the game graphics and UI, the backenders worked on the server and game logic, and our data folks dealt with creating a game board provider.

The pluggability of our platform and the fact that it already had support for multiple users and sending out realtime messages from the server to clients made most of the work go pretty smoothly. Besides Eclipse crashing on one of our machines, development was pretty seamless and fast-paced, with team members yelling out at each other across the room to communicate. Within 45 minutes, most of us had finished our first iteration of code, and at the one hour mark we verified that we could successfully get the server and client communicating with each other and draw some game state. By the time we were two hours in, we had most of the core game features implemented, and once we hit the three hour mark we had a fully functional snake game that allowed us to play against each other. We spent the last hour doing some UI polish and ironing out a few bugs, and by the time midnight rolled around we had a fully functional MultiSnake implementation in our platform that was written using only our public APIs. We were even able to get in a few extra features such as a visible timer to count down to the end of the game, a circle to show where a snake respawned and a name that followed the snakes vertically to identify them. We celebrated by eating a rum cake that a coworker had brought in earlier and playing multiple rounds of lag-free MultiSnake against each other. Success!

The Results

MultiSnake lives on as an add-on to our platform. Even after the challenge was completed, devs have been playing around with the code on slow weekends, adding extra maps, new features such as wormholes, and overhauling the graphics. The final product is a pretty impressive and fun-to-play game that we now often demo as an example of the versatility and power of the APIs for our platform.

How it usually works

• Developers submit changes to the code base.
• The continuous build system detects a problem and the build “breaks” (or “goes red”).
• All developers who made recent changes are notified via email.
• Someone (usually the guilty developer) locates and fixes the problem.
• The continuous build system verifies the corrected problem and “goes green”.

Ideally, the delay between failure and fix should be as short as possible. But failure notifications are typically sent by email, which can easily be overlooked or ignored. Clearly we can do better.

The Palantir Way

With some time, some hacking, and a little home automation, I came up with a simple visual notification system. Our continuous build process now has a few extra features:

• When the build breaks, a rotating red light (the “build light”) turns on for a few seconds.

   

• A personalized build light next to the culprit’s desk turns on to get his/her immediate attention.

   

• When the problem is fixed, we celebrate: a bubble machine rings in the joyous occasion.

The enhanced system relieves the need to constantly check email, and gives immediate feedback to those who need to be informed (it tends to stop home-bound developers in their tracks). Also, it brings a bit of entertainment to the environment, and serves as a convenient mechanism for public shaming .

Palantir started in a very small office on Sand Hill Rd. For a time (while between offices), all work was done in a founder’s bedroom. In late 2005, the Palantir moved to medium-sized, nondescript suite on Page Mill Rd., just across the street from Hewlett-Packard in south Palo Alto. I joined a few months later, as the fifteenth employee. Since that time, we’ve sextupled in size and we’re currently pushing a triple-digit headcount!

We almost ran out of space last year, but managed to find a fantastic office space in downtown Palo Alto, at the intersection of Hamilton and Alma. At the time we acquired the space, we were told that it had been the home of Digital Equipment Corporation’s Western Research Lab. I mentioned this to an acquaintance of mine who mentioned, offhandedly, that this same set of offices was where Java was developed.

A few weeks ago, I got curious about this potentially dangling reference and decided to see if I could transmute it from rumor into fact. It sure would be neat if the fundamental technology that underlies our software was first developed in the very offices in which we work.

Some quick research confirmed the rumors and they’re all true! After the jump, the history of 100 Hamilton Ave.

1982-1992: DEC’s Western Research Lab

Before there was a Google, Microsoft, Apple, Sun, or Internet, there was Digital Equipment Corporation (aka DEC). DEC built the PDP series of mini-computers that Unix was originally developed on. In later years, DEC built AltaVista, the first search engine that returned useful results quickly. They did this to show off the power of their Alpha microprocessor, which was one of the first “commodity” 64-bit processors.

In the style of most tech behemoths, DEC funded a number of laboratories where researchers could work on basic science that would hopefully be turned into profitable technologies. In 1982, DEC opened the Western Research Laboratory at 100 Hamilton Ave., in Palo Alto.

Their raison d’être is spelled out in the front matter from one of their technical reports:

The Western Research Laboratory (WRL) is a computer systems research group that was founded by Digital Equipment Corporation in 1982. Our focus is computer science research relevant to the design and application of high performance scientific computers. We test our ideas by designing, building, and using real systems. The systems we build are research prototypes; they are not intended to become products.

As you may know, DEC was purchased by Compaq in 1998, who was then bought in some bizarre reverse-merger fashion by Hewlett-Packard. The full list of their published research is available on the HP Labs website.

People might assume that researchers in this field might be a dry humorless lot. Not so! In 1988, WRL publishes Technical Note 13: Characterization of Organic Illumination Systems, an experiment into the incandescent properties of three varieties of pickles, mandarin oranges, and bok choy. The report includes instructions on making your own pickles as well as a discussion of the practical considerations of making glowing cucumbers commercially viable:

9. Practical considerations

The primary advantage of pickles as light bulbs is that they can be eaten, either before or after providing illumination. Thus they are to be preferred for long sea voyages. Pickles are also organically grown and so do not contribute to pollution. However, whereas incandescent lamps can be manufactured by a single machine at a rate of 20 or 30 per minute [4], proper pickling takes several weeks and requires careful control [5]. Thus the challenge to economically exploit the rediscovery of pickle light sources comes down to developing techniques for the massive growing of cucumbers and efficient vast vats for pickling. This may be an excellent industry for the Developing world.

For those of you wondering what an incandescent pickle looks like, YouTube is here to help you out:

The legacy of this experiment lived on inside DEC for years. From the Wikipedia page on the DEC Alpha:

Officially, the Alpha processors were designated the DECchip 21×64 series, the “21″ signifying the 21st century, and the “64″ indicating 64 bits, with the middle digit corresponding to the generation of the Alpha architecture. Internally, Alpha processors were also identified by EV numbers, EV officially standing for “Extended VAX” but having an alternative humorous meaning of “Electric Vlasic”, giving homage to the Electric Pickle experiment at Western Research Lab.

The Western Research Lab ultimately produced some slightly more useful innovations, like AltaVista (in 1995, after they had moved around the corner).

1993-1997: Javasoft

Sometime in 1992, DEC moved the Western Research Lab a few blocks away to 250 University Ave. The world did not yet know Java. At that time, the Java team was known as “The Green Team” and were working in relative seclusion from the rest of Sun, on the fourth floor of the Bank of America building on Sand Hill Road.

Around 1993, the Green Team demoed the *7 (”star seven”), a hand-held computer running an early version of Java (then known as “Oak”) on top of a stripped down version of SunOS.

Building on the momentum of that demo, the Green Team formed FirstPerson, a wholly owned subsidiary of Sun. FirstPerson was working on building and promoting the Oak technology (not yet officially named Java), focusing primarily on the cable set-top box market. The team expanded to about 100 people and moved into the offices that are currently occupied by Palantir. As one of the earliest Java developers recalls:

We moved the company to the best location in the entire south bay. The old DEC Western Research Lab at 100 Hamilton Avenue in Palo Alto. This is ironically where the OSF, Open Software Foundation was formed by the “Hamilton Group” before they came up with what Scott always called “Oppose Sun Forever”. Six blocks of the finest restaurants in the Bay Area, CalTrans across the street for the San Fran commuters, and the nicest looking office buildings around. Things were looking up.

Javasoft occupied 100 Hamilton for a very exciting four years before being re-assimilated into the Sun mothership. During that time Java was named, introduced, released to world, and worked through three major revisions of the platform (1.0, 1.1, and 1.2).

This interview with Sami Shalo from JavaWorld’s October 1996 issue (no longer available online) has the details:

JavaWorld: What is your recollection of the meeting in which the word “Java” was chosen as the name of Sun’s new programming environment? Where was it held and when?

Shaio: Oh, boy. Well let me look through my extensive archives. The meeting was held at the “TestPattern” conference room in “PAL2,” which is the building at 100 Hamilton Ave., where all the Java-Internet thing happened. It’s also the infamous building where OSF started, when it was known as the “Hamilton Group.” I believe the meeting was held in perhaps January of 1995.

2007 – ?: Palantir Technologies

Palantir started operations at 100 Hamilton in October of 2007. We love our new home, especially having lunch out on our third-floor kitchen balcony. In the grandest Silicon Valley tradition, we’re living the dream of working hard and playing hard, moving the state of the art forward, one line of code at a time.

Check out this reflection magic! Now iTunes isn’t the only one with fancy reflections on album art. The best part about it is that it’s a general use component that doesn’t require customization each time. It can wrap any transparent JComponent and it will automatically repaints whenever the contained component changes. You see the text appearing in the reflection as you type in the text field. Try the Web Start ReflectionDemo. Source code is provided in reflectiondemo.jar, and an explanation of how it’s done follows.

This component is a combination of several techniques:

• Image fading.
• Applying a transform so the contained component is painted upside down.
• Active update accomplished by, *gasp*, calling repaint during paintComponent!

Fading images

You can paint colors/lines/solid shapes/etc using a GradientPaint to create an object that fades from solid to transparent as we desired, but getting a complex graphic to do the same thing didn’t seem possible until we learned about AlphaComposite.DST_IN, (see our previous blog posting on the subject). It’s a class that, instead of blending two images together, allows you to use the color bytes from one image and the alpha from the second image. This technique allowed me to composite together a fully opaque picture of a component with a rectangle of black painted using a standard Gradient paint.

Imagine the icon upside down and you’ll see what I’m trying to accomplish here.

Inverting the component

The reflection is obtained by applying transforms to a Graphics object, then permitting the reflecting component to paint itself to a BufferedImage instead of the supplied Graphics instance. This results in a copy of the contained component painted upside down in a separate BufferedImage. After compositing using the above technique, you get something that looks like the component but upside down and faded with whatever GradientPaint you used.

You can paint upside down to the supplied Graphics, of course. However, if you want the fading effect to apply only to the contained component, you need to isolate it on a separate BufferedImage until it’s fully prepared.

In the below snippet of code, reflG2D is the Graphics2D of the offscreen buffer that holds the reflection so that it may be faded before painting to screen. The scaling step causes all y-coordinates to be multiplied by -1, so when you paint the children of ReflectionComponent to reflG2D, source paints itself upside down.

Look out, though, that means the paint which would normally be (0,0) -> (source.getWidth(), source.getHeight()) is now (0,0) -> (source.getWidth(), -source.getHeight()). You've just painted outside the boundaries of the image so you translate down to put it in the visible region. The rest of the translation ensures proper painting even if source isn't at (0,0) due to insets or the layout manager.

	Insets i = getInsets();
	reflG2D.scale(1,-1);
	reflG2D.translate(-source.getX(), - (source.getHeight()+i.top));

	super.paintChildren(reflG2D);

	reflG2D.translate(source.getX(), (source.getHeight()+i.top));
	reflG2D.scale(1,-1);

Don't forget to undo the changes you made so the fade operations can be done without being affected by the inversion/translation.

Active update of the reflection

This is a bit sketchy but too cool to pass up. I've seen several reflection component examples out there, but they don't seem to do active update, so here it is. There's no event that fires to report when repaints occur (I suppose Sun engineers figured it was just too likely to be abused). They're probably right. So I abused opacity instead. When a component is marked for repaint and it is transparent (i.e. isOpaque() == false), then the parent of said component will be repainted as well. So, if everything contained in a ReflectionComponent is transparent, then ReflectionComponent itself will repaint every time the contained object does so. The only hurdle to overcome is the crop -- the dirty region will never automatically include the reflection region because the reflection lies outside the bounds of the contained component. This makes it necessary to call repaint on the reflection region as well. Basically it doubles up on every repaint, not something you REALLY want to do all over the place but it does the job.

Here's how I did it:

public void paintComponent(Graphics g) {
	...
	Rectangle r = g.getClipBounds();
	if( (r.y+r.height) < (getHeight() - 1) ) {
		repaint(r.x, r.y, r.width, getHeight() - r.y);
	}
	...
}

• HBR1 – the crazy Germans at HBR1 give us Psytrance on tap, probably the most driving of all the genres. The I.D.M. Tranceponder Stream stream is pretty consistently driving and great to code to.
• Proton Radio – really good house music. Probably the best on the web. Consistently good to code to, slightly less energetic than the HBR1 pystrance streams. [stream link here].
• SomaFM – an grand old institution of internet radio, SomaFM is operated out of San Francisco and has streams for every taste. People like Brien, who like things a bit more chill, love their famous flagship stream, Groove Salad. Their trance stream, known as Tag’s Trance Trip is similar to HBR1’s channels, but slightly less psy and a bit more classically trance-ish. There’s a are 11 different streams coming out of SomaFM, all worth checking out.
• Digitally Imported Radio – they have a whole bunch of streams, without fancy names, split by genre. I’m personally a fan of their house and breaks streams, but there are many more.
• BreaksFM – Breaks out of the UK. This station has some great underground, really big breaks. Occasionally, there’s a little too much talking by the DJ over the stream, but the music so exceptional, it more than makes up for it. Stream links: Channel 1 Channel 2.