Find out the full course content here and register for the course here.

Find out the full course content here and register for the course here.

You may already be passionate about and experienced in Erlang, or if you are not already a skilled Erlang programmer, we will train you in the language. The right candidates will join small teams of highly skilled systems engineers developing software using Erlang/OTP.

You will gain valuable experience in exciting state-of-the-art systems within the Telecom, Financial Services, Banking, Messaging and Logistics sectors. As our clients are spread on six continents, there will be an opportunity to travel if you’re up for it.  

1.    Responsibilities:

• Research, design, development, test and support of Erlang and related software.
• Develop solutions using distributed concurrent programming, software packaging and release.
• Write and test code in Erlang and occasionally in other languages such as C, Java, Clojure, Haskell, Scala & Objective-C.
• Experienced programmers will be expected to mentor and coach junior staff.

2.    Skills and experience required:

• Good programming skills and experience with one or more language such as C, Java, Haskell and Erlang.
• Knowledge of Distributed Computing.
• Experience of implementation of soft, real time servers in a multicore environment would be a nice to have.
• Experience with interconnection protocols (HTTP, XMPP, SMPP, ...)
• Experience with Linux, OS X and Solaris operating systems.
• Experience with Agile Methods, including Test Driven Development will be an advantage.
• Problem-solving and thinking laterally as part of a team, or individually, to meet the needs of the project.
• Good verbal and written communication in English.
• Good customer facing and presentation skills.

3. Minimum Education, Certification, Training:
A Degree or Masters in Computer Science, or an Erlang Foundation level certification.

4. Eligibility:
The right candidate will work in a rapidly expanding company and community, receive a competitive salary with full benefits and stock options.

Join us Thursday January 19 at 6:30 PM at our brand new Headquarters (aka Fort Awesome). Join and RSVP here.

Together with the Zurich FLOSS and IT geeks and hosted by ETH Zurich,     we will be holding an Erlang Factory Lite on the 23 April 2012. The   Factory Lite will be a chance for you to learn, socialise and network   with some fantastic names.

We are currently accepting talk submissions. We welcome submissions from developers, system designers,  testers,  community leaders, inventors,  CTOs, evangelists, students,  researchers and entrepreneurs alike.  Submit your talk here.

The Erlang Factory Lite is open to   everybody with any level of Erlang experience from newbies to   experienced developers and is free to attend.

Why not come   along and meet up with like-minded developers and architects and find   out how more firms are using Erlang/OTP to solve previously intractable   problems.

Book your place now!

The talks, even though officially part of the “Distributed Systems Design” course, are open to all interested students. No prior knowledge of Erlang is required. 

Lecture One:  Date: Tuesday 17th January 2012 Time: 15:00-17:00
Location: Room D33 - Cittadella Universitaria Catania 

Lecture Two:  Date: Thursday 19th January 2012 Time: 15:00-18:00
Location: Room D31 - Cittadella Universitaria Catania 

Erlang Solutions wishes to thank the University of Catania, which has a long tradition of using Erlang in its projects, for this opportunity. A special thanks goes to Professor Antonella Di Stefano and her collaborators, who made all this possible.

Simple Fast Elastic.

That’s pretty much it. We make it very simple to get started, we are extremely fast (and getting faster), and we really are “web scale”, with the ability to add and remove machines from a cluster to rapidly scale your capacity to your workload.

The Membase product was very fast and scalable, but a bit too simple, with no reporting capability or cross-datacenter replication capability.

The CouchDB product has a lot of features, but is too slow, unable to keep up with high loads and inability scale-out on it’s own.

The combination of the 2 will hit a sweet spot to allow developers to quickly get their apps up and running, along with the reliability, speed and low cost that make running it in production cheap and worry free.

Our 2.0 product is coming soon, adding CouchDB style views and reporting with a nifty trick for extremely fast failover while maintaining full coherency with the underling distributed data storage (we are calling it our B-Superstar index). We’ll of course have lighting fast reads (same as Memcached) but also very fast durable writes. For 2kb docs, we are currently getting sustained random insert/updates rates of 25k writes/sec, fully durable, with compaction in background so it can go all day and all night. We’ve got some more write work coming soon which we are hoping will give us another performance boost too before 2.0. Stay tuned.

And so right now the focus is on the features and customers that pay, a thing that allow us to build a real sustainable business. And that’s REAL DAMN IMPORTANT. It’s not enough to build some cool technology, not enough to build a community of excited technologist. You need to cross the chasm and build a real business. A business that provides support, training, documentation and of course a reliable product. A business you can call up when you have difficultly upgrading from an old version, or are getting some weird error you’ve never seen before at 3am. A business you know will be around to support you for years to come.

And so while we focus on the features and customers that most quickly make us a viable business (and it’s growing fast), we are still looking to build the features and technology to expand our use cases and, get customers and developers excited. Future versions are planned to have full CouchDB compatible replication technology, with the ability to support all sorts of mobile and embedded databases, such as our new TouchDB projects for iOS and Android. So with Couchbase you can have fast, scalable database in the cloud that also supports the offline use of thousands, or millions of apps on devices that drop in and out of internet connectivity, and can sync when connected but still completely usable when disconnected.

That’s some cool shit. Simple Fast Elastic. And Reliable. And Mobile. That’s why Couchbase.

The NoSQL Roadshow starts off with an overview of the changing landscape around data management – highlighted by concepts like Big Data and NoSQL databases. Attendees will learn how to “think” differently when it comes to designing highly scalable systems and hear from the experts who are designing and utilizing Riak, an opensource non-relational database.

For more information and registration click here

open_file =: open :. close

Well, really, that should be:

open_file =: (1!:21) :. (1!:22)

But the former, without the explicit foreign function calls, gets the point across clearer, I think.




One common use of obverses and the “under” operator is for boxing and unboxing values. In J, a list contains values of the same type. There’s no mixing of integers and strings like Lisp or Python. Instead you can “box” a value, then have a list containing only boxed values. But there’s nothing you can do with a boxed value except unbox it, so it’s common to say “[some operation] under open box,” like “increment under open box.” That means unbox the value, increment it, then put it back in a box. Or in real, eyeball-melting J:

inc_box =: >: &. >

The >: is increment. The right > means open box. That’s the “under” operation in the middle.




Now it sounds like this “open box, do something, close box” sequence would translate beautifully to the “open file, read the contents, close the file” example I gave last time, but it doesn’t. The catch is that the open / read / close verbs aren’t manipulating a single input the way inc_box is. Opening a file returns a handle, which gets passed to read. But reading a file returns the contents of the file, which is not something that can be operated on by close. So this definition won’t work:

read_file =: read &. open

If a structured data type like a dictionary was being passed around, then okay, but that’s not a pretty example like I hoped it would be.




Still, I encourage learning J, if only to make every other language seem easy.

Huh? So what about Apache CouchDB? Well, that’s a great project. I founded it, coded the earliest versions almost completely myself, I’ve spent a huge amount of blood, sweat and tears on it. I’m very proud of it and the impact it’s had. And now I, and the Couchbase team, are mostly moving on. It’s not that we think CouchDB isn’t awesome. It’s that we are creating the successor to it: Couchbase Server. A product and project with similar capabilities and goals, but more faster, more scalable, more customer and developer focused. And definitely not part of Apache.

With Apache CouchDB, much of the focus has been around creating a consensus based, developer community that helps govern and move the project forward. Apache has done, and is doing a good job of that. But for us, it’s no longer enough. CouchDB was something I created because I thought an easy to use, peer based, replicating document store was something the world would find useful. And it proved a lot of the ideas were possible and useful and it’s been successful beyond my wildest ambitions. But if I had it all to do again, I’d do many things different.

If it sounds like I’m saying Apache was a mistake, I’m not. Apache was a big part in the success of CouchDB, without it CouchDB would not have enjoyed the early success it did. But in my opinion it’s reached a point where the consensus based approach has limited the competitiveness of the project. It’s not personal, it’s business.

And now, as it turns out, I have a chance to do it all again, without the pain of starting from scratch. Building on the previous Apache CouchDB and Membase projects, throwing out what didn’t work, and strengthening what does, and advancing great technologies to make something that is developer friendly, high performance, designed for mission critical deployment and mobile integration, and can move faster and more responsively to users and customers needs than a community based project.

Apache CouchDB, as project and community, is in fine shape. And many of us at Couchbase are still contributing back to it. But the future, the one I’m pushing forward on, is Couchbase Server.

And what is my part in building Couchbase? Right now I’m focusing on getting Couchbase 2.0 ready for serious production use. I’m once again an engineer and coder, back in the trenches, designing and writing code, reviewing code and designs, helping other engineers and solving tough problems. And I’m dead serious about making it the easiest, fastest and most reliable NoSQL database. Easy for developers to use, easy to deploy, reliable on single machines or large clusters, and fast as hell. We are building something you can put your mission critical, customer facing business data on, and not feel like you’re running a dirty hack.

Soon, to work more closely with the team (and get rid of my nasty Oakland commute), I’ll be relocating my family to the Mountain View area. Shit just got real!

And I’m really excited about the work we’ve got in the pipeline. We are moving more and more of the core database in C/C++, while still using many of the concurrency and reliability design principles we’ve proven with the Erlang codebase. And Erlang is still going to be part of the product as well, particularly with cluster management, but most of the performance sensitive portions will be moving to over C code. Erlang is still a great language, but when you need top performance and low level control, C is hard to beat.

Anyway, there so much to talk about, to much for one blog post. One of my New Years resolutions is to blog more, and I’ve got a ton of interesting things to talk about. The trials of tribulations of building a startup and an engineering culture. What’s wrong (and right) with Erlang. Bringing forth UnQL. TouchDB for Mobile. And yes, we’ll still interoperate with Apache CouchDB and Memcached. But the future is Couchbase.

Ride with me.

Take the rake out of the shed, use it to pile up the leaves in the backyard, then put the rake back in the shed.




Fly to Seattle, see the sights, then fly home.




Put the key in the door, open it, then take the key out of the door.




Wake-up your phone, check the time, then put it back to sleep.

See the pattern? You do something, then do something else, then you undo the first thing. Or more accurately, the last step is the inverse of the first. Once you’re aware of this pattern, you’ll see it everywhere. Pick up the cup, take a sip of coffee, put the cup down. And it’s all over the place in code, too:

Open a file, read the contents, close the file.




Allocate a block of memory, use it for something, free it.




Load the contents of a memory address into a register, modify it, store it back in memory.

While this is easy to explain and give examples of, it’s not simple to implement. All we want is an operation that looks like idiom(Function1, Function2), so we could write the “open a file…” example above as idiom(Open, Read). The catch is that there needs to be a programmatic way to determine that the inverse of “open” is “close.” Is there a programming languages where functions have inverses?




Surprisingly, yes: J. And this idiom I keep talking about is even a built-in function in J, called under. In English, and not J’s terse syntax, the open file example is stated as “read under open.”




One non-obvious use of “under” in J is to compute the magnitude of a vector. Magnitude is an easy algorithm: square each component, sum them up, then take the square root of the result. Hmmm…the third step is the inverse of the first. Sum under square. Or in actual J code:

mag =: +/&.:*:

+/ is “sum.” The ampersand, period, colon sequence is “under.” And *: is “square.”




(If you liked this, you might enjoy Understanding What It’s Like to Program in Forth.)