“You’re asking us to test our platform’s programming language? How am I supposed to do that?”

My head itches from trying to recall the bits and pieces of what I learned in high school about programming, specifically the semantics of a programming language. Sure, I did a bit of programming for homework assignments in college, but I was no CS major. This was a much different challenge for a QA engineer to test. Compared to an application, a programming language is completely open ended; there are no specifications to test, guidelines to follow, or limits to break.

The Hedgehog language had the basic set of tools laid out for me already: I could declare variables, create data structures, and use loops for iteration. As I was trying out individual usage examples, such as how to structure if statements or how to cast an object to a different type, I realized that this was no way to test something as powerful and flexible as an entire language. It would be like a doctor who claims that since each individual organ works fine, there are no problems with the entire system. This is insufficient: one needs to look at the system as a whole, including examining the interactions between each component. I decided I needed to create much larger and elaborate code samples in order to test the Hedgehog language in a larger scope.

Using the Hedgehog language, I had programmed several algorithms, solving puzzles that would output a number. This was getting bit boring, since once the output value was matched the expected number, there was nothing more to be done. I wanted to create something more dynamic, a toy I could play around and experiment with. And opportunity presented itself in the form of one of our newest tools: the spreadsheet application. With the capability of setting the value of each cell programmatically and then coloring them depending on their value… hmm what could I do with this?

Hedgehog is a powerful tool in coding functions and workflows that directly interact with our applications. Most of the time, the language is used to write expressions for an input value, create custom metrics that return values after a set of calculations, or even to set inputs, calculate, and save documents. Given the language’s ability to integrate with Spreadsheet, the capabilities of the Hedgehog language can literally be visually shown to the user, resulting in some stunning displays. Below are three examples I’ve coded in Palantir Finance’s own language: calculating and drawing the Mandelbrot fractal, simulating Conway’s Game of Life, and solving a Nonograms puzzle.
Read the rest of this entry »

Software engineering is a craft that blends science and art. This fact is easy to overlook as the artistic aspects are often eclipsed by discussions of the science and technology behind what we do.

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.”

Read the rest of this entry »

Here at Palantir, we use continuous integration as one of our development practices. Part of this includes running automated builds and tests. This practice is quite common, and is useful because it gives immediate feedback on (some of) the software’s correctness.

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.
Read the rest of this entry »

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.
Read the rest of this entry »

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.
Read the rest of this entry »

It’s amazing to me how much the music I’m listening to defines my energy level and output. Couple that with the open office environment we have at Palantir, and I end spending a good portion of the work day listening to music on my headphones. I often use different music for coding than debugging, as the tempo of the two activities feels very different to me. As my coworkers know, I’m a total beat-head and lover of drum machines, but even within that, I like to mix it up a bit. Here’s a quick list of the internet radio I like to listen to while coding:

• 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.