There are abundant resources online trying to scare programmers away from using shell scripts. Most of them, if anything, succeed in convincing the reader to blindly put something that resembles

set -euo pipefail

at the top of their scripts. Let’s focus on the “-e” flag. What does this do? Well, here are descriptions of this flag from the first two results on Google for “writing safe bash scripts”:

• “If a command fails, set -e will make the whole script exit, instead of just resuming on the next line” (https://sipb.mit.edu/doc/safe-shell/)
• “This tells bash that it should exit the script if any statement returns a non-true return value.” (http://www.davidpashley.com/articles/writing-robust-shell-scripts/)

Unfortunately, this is bash we are talking about and the story is never that simple.

» Continue Reading.

Jane Street is looking to hire a technical writer. If you’re interested, or know someone who you think would be a good match, here’s the application link.

We’ve always believed that developers should spend time and effort documenting their own code, but at the same time, a great writer with a feel for the technology can raise the level of quality in a way that few developers can. And as we’ve grown, having someone dedicated to writing makes a ton of sense.

Here are the kinds of things we’d like to have a technical writer work on:

• Training material. We have a training program that many new hires go through, including most new developers and all new traders. In that program, they learn about OCaml, our base libraries, our build system, the UNIX shell, Emacs, and our dev tools. Part of the job would be to help make the course better, both by improving what we have, and by adding new material.
• Improving library documentation. While we expect developers to do a reasonable job of documenting their code, our most important libraries deserve the time and care to make them really shine. This is aimed both internally and externally, since a lot of these libraries, like Async, Core and Incremental, are open source.
• Writing longer pieces. We need more tutorials and overviews on a variety of topics. Part of the work would be to create great new documentation, and part of it is to serve as an example for others as to what good documentation looks like. And where possible, we want to do this so that the documentation effectively compiles against our current APIs, preventing it from just drifting out of date.

In terms of skills, we want someone who is both a clear and effective written communicator, and who is good enough at programming to navigate our codebase, work through our tutorials, and write up examples. An interest in functional programming and expressive type systems is a plus, but you don’t need to know any OCaml (the language we use). That’s something we’re happy to teach you here.

We have a new tech talk coming up on May 17th, from our very own Dominick LoBraico. This one is about how to represent configurations with programs. In some sense, this is an obvious idea. Lots of programmers have experienced the dysphoria that comes from watching your elegant little configuration format metamorphize into a badly constructed programming language with miserable tools. This happens because, as you try to make your configs clearer and more concise, you often end up walking down the primrose path of making your config format ever more language-like. But you never really have the time to make it into a proper language.

» Continue Reading.

It’s often surprising just how much software performance depends on how the software is deployed. All the time and effort you’ve invested in optimization can be erased by a few bad decisions in scheduler policy, affinity, or background workload on a server.

So here are a few things I check for when an app’s performance is unexpectedly bad. These are things that should apply to any OS running on a modern server, but the specific tools I’ll mention are for Linux.

Are you running the binary you think you are?

It’s funny how often seemingly bizarre problems have simple explanations. So I start by checking that I’m really running the right binary. I use md5sum to get a hash:

» Continue Reading.

From now and then, I found myself having to write some mechanical and repetitive code. The usual solution for this is to write a code generator; for instance in the form of a ppx rewriter in the case of OCaml code. This however comes with a cost: code generators are harder to review than plain code and it is a new syntax to learn for other developers. So when the repetitive pattern is local to a specific library or not widely used, it is often not worth the effort. Especially if the code in question is meant to be reviewed and maintained by several people.

» Continue Reading.

I’m happy to announce our next public tech talk, called Seven Implementations of Incremental, on Wednesday, April 5th, presented by yours truly. You can register here.

The talk covers the history of Incremental, a library for building efficient online algorithms. The need to update computations incrementally is pretty common, and we’ve found Incremental to be useful in creating such computations in a number of different domains, from constructing efficient financial calculations to writing responsive, data-rich web UIs.

The ideas behind Incremental aren’t new with us; there is a lot of prior art, most notably the work from Umut Acar’s work on self-adjusting computations, on which Incremental is most directly modeled.

» Continue Reading.

Are you thinking about applying to Jane Street for a developer role? Or already have a phone interview scheduled but unsure what to expect? Read on as we walk through an example phone interview with you.

We want to give you some insight into what a typical Jane Street phone interview looks like and give you a chance to prepare. We’re going to take a look at a question we call “Memo” which we used to ask regularly (but of course don’t ask anymore so no need to memorize anything on this page!). As such this post is meant to be a specific case analysis. If you haven’t yet seen it, we recommend reading this blog post for a general overview what we are looking for in candidates.

» Continue Reading.

Our first Jane Street Tech Talk went really well! Thanks to everyone who came and made it a fun event.

Now it’s time for another. We’re planning for the series to feature a combination of voices from inside and outside Jane Street. This one is of the latter variety: on March 6th, Arjun Guha will be presenting On Verification for System Configuration Languages, which is about using static verification techniques for catching bugs in Puppet configs.

I’ve known Arjun for years, and he’s a both a good hacker and a serious academic with a real knack for finding good ways of applying ideas from programming languages to systems problems. Also, he has excellent taste in programming languages…

» Continue Reading.

UPDATE: We are full up. Tons of people signed up for the talk, and we’re now at the limit of what we feel like we can support in the space. Thanks for all the interest, and if you didn’t get into this one, don’t worry, we have more talks coming!

We’re about to do the first of what will hopefully become a series of public tech talks in our NY office.

The first talk is on February 2nd, and is an overview of the architecture of a modern exchange. The talk is being given by Brian Nigito, and is inspired by our work on JX, a crossing engine built at Jane Street. But Brian’s experience is much broader, going all the way back to the Island ECN, which in my mind marks the birth of the modern exchange.

» Continue Reading.

Spacetime is a new memory profiling facility for OCaml to help find space leaks and unwanted allocations. Whilst still a little rough around the edges, we’ve found it to be a very useful tool. Since there’s not much documentation for using spacetime beyond this readme, I’ve written a little intro to give people an idea of how to use it.

Generating a profile

As an example of Spacetime in action let’s get a profile for the js_of_ocaml compiler. First we’ll need a Spacetime-enabled OCaml compiler:

$ opam switch 4.04.0+spacetime
$ eval `opam config env`

Using this compiler we build the executable. In this case we just let opam build it for us:

» Continue Reading.