Living the Question

Happy Birthday

In about a month, it will be my 36th birthday. Normally, my birthday isn't a big deal to me. I get a few Happy Birthday e-mails, my girlfriend makes a chocolate cake; it's all low-key and nice.

This year is a little different. My driver's license expires, and I need to stop in at a Department of Motor Vehicles (DMV) in order to get a new license. So, you might ask, what's the big deal? Show up, fill out a form, pay the fee, and get a new license. Easy as cake, right? Not quite.

Religious Conviction

I am a Pastafarian. I am also an ordained minister of the Church of the Flying Spaghetti Monster. When it comes to getting a driver's license photo, the tradition is to wear a spaghetti strainer (colander) upon one's head for the photo.

Here are some other examples of Pastafarians who have done the same in the past two years:

• [Feb 2013] 'Pastafarian' Aaron Williams Refuses To Remove Strainer For License Photo 
• [Aug 2013] Texas Pastafarian Wins Battle At DMV, Becomes First In U.S. To Wear Colander In License Photo 
• [Jan 2014] Pastafarian minister sworn into office
• [Aug 2014] California Pastafarian wears pasta strainer for license photo 
• [Sep 2014] Pastafarian Wears Colander as Hat in DMV Photo
• [Sep 2014] ‘Pastafarian’ Poses for Driver’s License with Colander as Religious Headwear (Video)

This is the first time I've needed to update my driver's license photo since I became a Pastafarian. I don't know how much resistance to expect from the Wisconsin DMV. Aaron Williams was denied his right to wear a religious headware by the New Jersey DMV in Feb 2013. It seems other Pastafarians in other states have fared better since then. I remain hopeful.

Sincere Beliefs

My girlfriend of two years doesn't understand my desire to wear a colander on my head for my driver's license photo. Her objections are similar to objections that my friends have voiced before:

• A driver's license photo is serious, why aren't you taking it seriously?
• Why do Pastafarians make fun of religion and religious people?

Juxtaposed, the two objections make an odd paradox. Other religions are assumed to be sincerely held by the people who practice them, they are serious, and it is disrespectful to make fun of them. Yet, if I seek to practice my religion, I'm assumed to be insincere, making fun of religion, and not taking my driver's license photo seriously. It's really an odd kind of contradiction.

It occurs to me that my girlfriend (a non-Pastafarian) does not understand the nature and purpose of the Church of the Flying Spaghetti Monster. She does not understand that I am a Pastafarian and therefore, I am Living the Question.

Asking the Question

Before we get to Living the Question, it might first help to Ask the Question. Before we Ask the Question, we need to ponder something important. Here, I need to quote the Join Us page of the Church of the Flying Spaghetti Monster:

"FSM is a real, legitimate religion, as much as any other. The fact that many see this is as a satirical religion doesn’t change the fact that by any standard one can come up with, our religion is as legitimate as any other. And *that* is the point."

What I will ask you to ponder is this: The Pastafarian religion is a legitimate religion, but many see it as a satirical religion. If we want to be taken seriously, why go to all the trouble to make our religion appear satirical to so many? Is it important to Pastafarians that our religion be seen as satire?

The reason for this becomes clear after we Ask The Question. The Question, succinctly, is this:

What is the proper role of society with respect to religion?

That's a pretty big question, so let's rephrase that question another way. American society is an inclusive society with multiple religions. Our constitution guarantees Freedom of Religion for all. Most of us belong to one religion and regard the other religions as strange. So the question is:

How does society maximize the religious freedom of everyone, while preserving its own legitimate interest in the welfare of its citizens?

This turns out to be a very important question. For example:

• Should be it legal to withhold medical care from children due to religious belief? Even if they might die because that medical care is withheld?
• Should it be legal for a man to marry his 12 year old daughter to a 50 year old man due to religious belief?
• Should it be legal to refuse military service due to religious belief?
• Should people who are incarcerated in prison have special dietary accommodations due to religious belief?
• Should religious belief be required to hold public office?
• Should religious beliefs be taught in public schools?

There are almost too many questions to enumerate them all. Now we see why The Question is such a big and important question. So let's ask it again, so that we're clear on The Question...

What is the proper role of society with respect to religion?

Living the Question

Let's return to what we were pondering before:

The Pastafarian religion is a legitimate religion, but many see it as a satirical religion. If we want to be taken seriously, why go to all the trouble to make our religion appear satirical to so many? Is it important to Pastafarians that our religion be seen as satire?

Now in the context of The Question:

What is the proper role of society with respect to religion?

Let's consider this another way:

What is society to do when a very strange religion, with very strange beliefs shows up? What if some of those beliefs seem to be absolute nonsense and at odds with reality? What if some of those beliefs are based on logical fallacies and other faulty reasoning?

Now the pieces of the puzzle begin to click together. In asking The Question, we want to know how society should interact with religion. A religion that we are all familiar with is less useful here. Such a religion might be accepted because "Well, that's the way it's always been." which implies a bias against other religions, since they aren't "the way it's always been."

No, to explore The Question, we need a religion that is very odd. A religion whose practices are so far "out there" as to seem like satire. A religion that is so strange that people looking at it from the outside will say to themselves, "Only an idiot would believe that!" And that, is the point.

Our religion is as legitimate as any other, and "other" enough that society can reason about it without personal or cultural biases. Someone might think teaching Creation Science or Intelligent Design in public schools is a good idea. Yet, when asked if schools should teach Flying Spaghetti Monsterism, they don't have the pro-FSM bias. Suddenly, they are left in the awkward position of explaining how and why the government should be favoring one religion over another religion.

As a Pastafarian, I am Living the Question when I put a colander on my head for a driver's license photo. I am asking society at large to ask itself, "Should the state make headware exemptions for religious belief?" Is an identification photo with uncovered head important? Does the state have an compelling interest in regulating the appearance of the head in an identification photo? Is that compelling interest so strong as to override religious belief? Or can society tolerate that a strange person with a strange belief wears a strange thing on their (strange) head while having an identification photo taken?

I assert that this is a very important thing for all of us, as a society, as a whole, to consider. Yes, the colander, as part of the bigger picture; The Question:

What is the proper role of society with respect to religion?

I sincerely believe that this is a very important question to answer. And I believe that being a Pastafarian is a good (and fun!) way to help people answer that question.

Now, I just need to find a spaghetti strainer that doesn't make me look fat in the picture.

Server Side WebSocket in Java

I recently wrote a high quality, low grade, server side WebSocket (RFC 6455) implementation. The intended use-case is as follows:

• I want to create a service in Java that accepts connections from modern web browsers.
• I want to use InputStream and OutputStream to get my bytes back and forth between my service and the browser.
• I want my service code to do this with minimal setup.
• I want to ignore all the protocol details; just give me the bytes.
• I'm not sure, but I might like to support SSL/TLS security (i.e.: HTTPS) for none/some/all of my connections.

 

Need More?

If you need something else, like Java NIO support, non-blocking I/O, evented I/O, ability to provide custom handlers for web frames, etc.. then you'll probably need to find another implementation:

• http://stackoverflow.com/questions/4003102/best-java-framework-for-server-side-websockets
• http://stackoverflow.com/questions/4278456/websockets-production-ready-server-in-java
• http://stackoverflow.com/questions/4292624/java-websocket-host

Note that JavaEE 7 includes WebSocket support. So if you've already got a web container (i.e.: Tomcat), then you've probably already got a solution at hand:

• http://docs.oracle.com/javaee/7/api/javax/websocket/package-summary.html

 

Just Enough

Since you're still reading this, I'll assume you want to know more about my WebSocket implementation. You can find the repository here:

https://github.com/blinkdog/websocket

How does it work? I'm glad you asked...


This is how you start listening for WebSocket connections:

ServerSocket serverSocket = new ServerSocket(PORT);
WebSocketServerSocket webSocketServerSocket = new WebSocketServerSocket(serverSocket);
WebSocket webSocket = webSocketServerSocket.accept();

And this is how you read data from the connecting client:

InputStream is = webSocket.getInputStream();
int data = is.read();

And this is how you communicate back to the connecting client:

WebSocketServerOutputStream os = webSocket.getOutputStream();
os.writeString("This is a UTF-8 string.");
os.writeBinary("Some binary data.".getBytes()); 

That's It

A high quality, low grade, server-side WebSocket component with no frills or nonsense. That's it, that's all. Enjoy!

Checking Node.js Project Dependencies with CoffeeScript

I love Node.js. I love CoffeeScript. I have never found it easier to translate concepts in my head to working code, as I do when I'm working with these two. Like this morning, when I was spinning up a new project...

Node.js Background

In Node.js, a project is defined by a package.json file. Here is an abbreviated example from my project telnet-stream:

{
    "name": "telnet-stream",
    "version": "0.0.4",
    "description": "Transform streams for TELNET protocol",
    "devDependencies": {
        "coffee-script": "1.7.x",
        "mocha": "1.19.x",
        "should": "3.3.x"
    }
}

Note the section "devDependencies". This section, along with a section called "dependencies" define the dependencies for a Node.js project. The Node Package Manager (npm) will fetch and recursively install all of your project's dependencies with the following command:

npm install

I've discovered two interesting points about the dependency management here.

One, the semantic versioning is very useful. Note above how I've specified "coffee-script": "1.7.x". When npm installs the coffee-script module, it will automatically grab the latest in the 1.7 series. And that is just scratching the surface of what you can specify with semantic versioning.

Two, you can specify Git URLs as dependencies, including your preferred branch/tag. Need to make a small tweak to a dependency? Easy, clone the repository, make your tweak, and specify the URL to your branch. Managing bleeding edge dependencies couldn't be easier.

Even better, as of version 1.1.65, GitHub URLs can be specified as dependencies using an abbreviated "user/project" syntax. So, if you wanted to use my telnet-stream project:

{
    "dependencies": {
        "telnet-stream": "blinkdog/telnet-stream"
    }
}

If you use GitHub, this is a very convenient way to manage dependencies for and between your projects.

CoffeeScript Background

CoffeeScript is a language that transpiles into JavaScript. That is, you write code in CoffeeScript and the compiler will output JavaScript. Said JavaScript is suitable for running in the browser, or on the server in containers like Node.js.

One of the nice little utilities provided by CoffeeScript is cake. cake is a simple build utility, similar to make; instead of a Makefile, you specify a Cakefile. Unlike a Makefile, a Cakefile has no special format. It is just a CoffeeScript source file with a few helper functions to define tasks.

For example, here is my Cakefile for telnet-stream:

{exec} = require 'child_process'

task 'build', 'Build the module', ->
  compile -> test()

task 'clean', 'Remove build cruft', ->
  clean()

task 'compile', 'Compile CoffeeScript to JavaScript', ->
  compile()

task 'rebuild', 'Rebuild the module', ->
  clean -> compile -> test()
 
task 'test', 'Test with Mocha specs', ->
  test()

clean = (callback) ->
  exec 'rm -fR lib/*', (err, stdout, stderr) ->
    throw err if err
    callback?()

compile = (callback) ->
  exec 'node_modules/coffee-script/bin/coffee -o lib/ -c src/coffee', (err, stdout, stderr) ->
    throw err if err
    callback?()

test = (callback) ->
  exec 'node_modules/mocha/bin/mocha --compilers coffee:coffee-script/register --recursive', (err, stdout, stderr) ->
    console.log stdout + stderr
    callback?() if stderr.indexOf("AssertionError") < 0

I've defined a lot of tasks at the top (build, clean, compile, rebuild, test), but none of those are required. The Cakefile is plain old CoffeeScript, so everything is optional. Note that the five tasks delegate to only three functions that call exec.

Problem

So this morning, I was specifying the dependencies for my project in package.json. This is a project that I intend to deploy for public consumption on the Internet, so stability and managed configuration are important. One of the things that caught my eye was the semantic versioning:

{
    "devDependencies": {
        "coffee-script": "1.7.x",
        "mocha": "1.19.x",
        "should": "3.3.x"
    }
}

If I were to execute npm install today, npm would choose CoffeeScript 1.7.1 to satisfy the "coffee-script": "1.7.x" dependency. However, if I were to install next month (or next year), there may be a new version of CoffeeScript in the npm repository. Installing at that time might give me CoffeeScript 1.7.8.

The convention is that minor point changes shouldn't affect the public API. That is, the difference between 1.7.1 and 1.7.8 might be internal bug fixes or optimizations. We do not expect that major components in the module will be removed, renamed, or exhibit wildly different behavior.

Because this is intended to be a production-grade service, a managed configuration is important. Or: It is not wise to bet the behavior of the service on how well a dozen+ authors of third-party modules can follow the versioning conventions. Despite the power of npm's semantic versioning, it is unwise to trust it with the final configuration of a public facing production-grade service.

For the project, this means the dependencies have to be specified precisely. If we say 0.1.6, we mean, version 0.1.6 and no other. This solves the managed configuration problem, but it does open some other problems:

• How can we be sure that we're not missing bug fixes, especially security related bugs?
• How can we be sure our codebase evolving with its components, and staying on the cutting edge of their features?

Just because our configuration is managed doesn't mean that it can't change or evolve. The key here is that configuration changes shouldn't be a surprise. It is okay to use version 0.1.7 instead of version 0.1.6, if you've reviewed the changes and know what differences to expect in production.

We just need a tool to tell us which dependencies have been updated and require review...

Solution

I thought that it would be neat if I could look up my project's dependencies and determine if I've specified the latest version or not. So I wrote a Cakefile task to do that:

{exec} = require 'child_process'

task 'depcheck', 'Check dependency versions', ->
  project = require './package.json'
  for dependency of project.dependencies
    checkVersion dependency, project.dependencies[dependency]
  for dependency of project.devDependencies
    checkVersion dependency, project.devDependencies[dependency]

checkVersion = (dependency, version) ->
  exec "npm --json info #{dependency}", (err, stdout, stderr) ->
    depInfo = JSON.parse stdout
    if depInfo['dist-tags'].latest isnt version
      console.log "[OLD] #{dependency} is out of date #{version} vs. #{depInfo['dist-tags'].latest}"


And here is the output of a contrived example:

tux@laptop ~/NetBeansProjects/sekrit-project $ cake depcheck
[OLD] should is out of date 3.3.0 vs. 4.0.4
[OLD] sansa is out of date 0.1.4 vs. 0.1.6
[OLD] express is out of date 4.4.1 vs. 4.4.3
[OLD] body-parser is out of date 1.2.1 vs. 1.3.1
[OLD] supertest is out of date 0.11.2 vs. 0.13.0
[OLD] mocha is out of date 1.18.0 vs. 1.20.1
[OLD] coffee-script is out of date 1.7.0 vs. 1.7.1

A dozen lines of CoffeeScript and now a single command tells me if any of my project's dependencies are out of date. Did I mention that I love Node.js and I love CoffeeScript?

Thoughts

What if I wanted to do something like this with Java and Maven?