Here are some of the projects that I have written or contributed to.
- 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
- WildFly Swarm - A microservices framework and runtime for Java
- Vert.x - A reactive application framework and runtime 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.
- A View Into the Vortex: Tracing Async Operations in Node - Nodeconf Budapest 2017
- Tracing Asynchronous Operations with Node's AsyncWrap API - Nodevember 2016
- Microservices in a Java EE World - Red Hat Microservices Architecture Day 2015
- Process Bindings: How to do Node.js on the JVM - CodeMash 2015
- Vert.x: Async Data From Cluster to Browser - DataIO 2013
- Vert.x - Bringing the Browser to the Cluster - DevIgnition 2013
- Complex Made Simple: Sleep Better with TorqueBox - RailsConf 2012
- Simple Scalability With TorqueBox - Ruby Hoedown 2012
- DataMapper on Infinispan: Clustered NoSQL - StrangeLoop 2012
Things I've Written Lately
I don't write a lot of blog posts, but if I do they end up here.
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.
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.
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.