I'm Lance Ball. I write software. I work for JBoss in a group called project:odd. Among other things, I get to work on new and experimental projects. In truth, that also means that I write and then throw away a lot of code. The upside is that I get to work on some projects that eventually grow legs and have a life.

Some Projects

Here are some of the projects that I have written or contributed to.

  • Node.js - A JavaScript runtime that uses an event-driven, non-blocking I/O model
  • fidelity - A lightweight, spec-compliant Promises/A+ implementation for Node.js and the browser
  • opossum - An implementation of the circuit breaker pattern for Node.js and the browser
  • rhq-metrics - A Node.js client for the JBoss RHQ Metrics Server
  • jvm-npm - A JavaScript NPM module implementation for JVM JavaScript environments
  • WildFly Swarm - A microservices framework and runtime for Java
  • Vert.x - A reactive application framework and runtime for the JVM
  • DynJS - A JavaScript runtime written for the JVM
  • Nodyn - A Node.JS runtime written for the JVM
  • TorqueBox - A JRuby application server

Things I've Said in Public

Sometimes I go places and talk about my work. Here are some videos of me doing that, or at least the slides I used.

Things I've Written Lately

I don't write a lot of blog posts, but if I do they end up here.

Protect Your Node.js REST Clients with Circuit Breakers

Thu Jan 05 2017

One of the predominant patterns in today's Node.js applications is the microservice, or µ-service. Applications are composed of a suite of independently deployable services, usually running in independent processes. These µ-services typically communicate with each other using lightweight protocols such as REST over HTTP.

One of the side effects of this architecture, however, is that applications need to be designed to handle failure. Any one of the service calls could fail for any number of reasons at any time. Today, I'll explore one method you can employ to gracefully handle service unavailability — the Circuit Breaker pattern.


Forget Data Encapsulation - Embrace Immutability

Mon Nov 28 2016

A couple of weeks ago, I wrote a fairly long post attempting to shed some light on a few things you can do in your JavaScript classes to enforce the concept of data encapsulation - or data "hiding". But as soon as I posted it, I got some flak from a friend who is a Clojure programmer. His first comment about the article was this.

Mutability and data encapsulation are fundamentally at odds.

Eventually, he walked that back - but only just a little bit. His point, though, was intriguing. I asked him to explain what he meant.


Data Hiding in ES6

Fri Oct 14 2016

For a lot of my early career, I was an OO developer. I genuflected regularly in front of the altar of data encapsulation, object heirarchies and static typing. And the syntax. Oh the syntax!

But I have changed, of course, and so much of the dogma and ceremony that I participated in during those times has come to seem a lot less important than it was 20 years ago. Languages, and developers evolve. But that doesn't mean there aren't some really good lessons to learn.

Take, for instance, data encapsulation.