Cube Drone Comic: JS Community Persistence, and Version Sacrifice

DZone 's Guide to

Cube Drone Comic: JS Community Persistence, and Version Sacrifice

Thousands of community libraries and build tools of varying quality are examples of the JS community's persistence in making JS work for them, which can be funny.

· Web Dev Zone ·
Free Resource

The first comic in this batch is one of the most on-point Cube Drone comics yet.  See the madness of the JavaScript ecosystem that still manages to make it all viable in the end.

Relentless Persistence

Image title

Problem: Compiled code isn't interpreted code, even if it compiles to interpreted code. Solution: Grunt watch Problem: Promises Solution: IOUs Problem: Javascript is a toy language that was tied to a document markup and somehow this has become the universal runtime of the internet. Problem: At this point, the ecosystem around Javascript is so densely layered and frequently changing that maintenance of any project over any significant period of time is going to be a nightmare.

Sometimes, Why?

Image title

We briefly outlined plans to move to Welsh, but cancelled them after discovering that the Welsh language lacks any grammar, syntax, or morphology and Welsh people have only been pretending to understand one another all these years

Version Sacrifice

Image title

This comic provided by Threepanel 0.gassy.0.0.potato.1436966326.7

The Complete Drone-Ver Specification

This also lives at drone-ver.org.

Drone-Ver v.1.sleepy.0.0.calamitous.1437363538.7


Given a version number MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME.SEVEN, manage your releases as laid out in this comic :

  1. MAJOR is incremented when you feel like you've added something cool.
  2. MOOD is how you felt when you released this version.
  3. ISSUES is the number of open GitHub issues against your project.
  4. SOCIAL is the number of GitHub forks & favourites of your project.
  5. DICTIONARY is a random dictionary word.
  6. UNIXTIME is the unix time, and
  7. SEVEN is always the number seven (7).


In the world of software management, there exists a dread place called "San Francisco." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If you don't want to end up in San Francisco with the rest of the developers - or worse, in Silicon Valley - you're going to have to do everything that you can to make versioning even harder.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are mostly based on what I thought would be most entertaining at the time that I first came up with Drone-ver. For this system to work, you need grim-eyed determination and a madness that seeps out of every pore in your being, affecting both your work and your relationship with others. It is probably best if you not work on a Drone-ver project with other developers, as your respective moods might become horribly entangled.

Once you've decided to use Drone-ver, you mostly communicate changes to your project using Twitter. If people using your library don't catch the update, you will post it again, but later in the day. Do your best to discourage these people. They are trying to steal your libraries to use in their own code. You owe them nothing and honestly wonder if they are stealing your butter knives when you are not watching your utensil drawer.

I call this system "Drone Versioning". Under this scheme, version numbers convey almost no useful information whatsoever.

Drone Versioning Specification (Drone-Ver)


  1. Software using Drone Versioning MUST be AWESOME TO THE POWER OF COOL.
  2. Why are we SHOUTING?
  3. A normal verion number must take the form MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME.SEVEN. If it takes another form, please call an EXORCIST immediately. You are in DANGER.
  4. I don't know what we're YELLING ABOUT.
  5. Major version zero (0) is for initial development. Anything may change at any time. This is also true of life. Take a moment to PONDER this, perhaps over a whisky, while staring out a window.
  6. Build metadata MAY be denoted by appending a plus sign, followed by a short paragraph describing your summer at camp. Your summer at camp SHOULD HAVE been MAGICAL.
  7. Precedence refers to how versions are compared to each other when ordered. When making precedence calculations, ALWAYS discard everything except for the Unix time and sort by THAT. It is NOT RECOMMENDED that you use the random dictionary word instead, but it would probably be MORE EXCITING.
  8. ALWAYS I wanna be with you and make believe with you.

Why Use Drone Versioning?

This is not a new or revolutionary idea. Not even a little bit. In fact, you probably do something close to this already, because you read the SemVer specification and you were like "urgh, standards. Not for me!".

The problem is that "your standard" isn't good enough. Without compliance to some sort of formal specification, your version numbers will never truly be spectacularicento, a word I made up that is a portmanteau of magnificent, spectacular, and the letter 'O'. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, your users will leave you to your coding in peace, never again e-mailing you at 7AM on a Saturday.

QIIPAM (Questions I Imagined People Asking Me)

This is terrible.

That is really more of a comment than a question.

I hear TenVer is good. Why shouldn't I use that?

TenVer is a different standard for versioning that is incompatible with Drone-Ver and therefore sorely lacking.

What about SemVer? Isn't that a practical, no-nonsense standard?

SemVer? Never heard of it.

Doesn't this discourage rapid development and fast iteration?

You're damn right. Go forth and turn pip into a wasteland.

You can leave npm out if this, it is already a wasteland.

How do I know when to release 1.0.0?

This is an invalid Drone-ver. Why would you even ask me that?

Is it "Drone-Ver" or "Drone-ver"? You seem to use both interchangeably.

I can tell that you are a software developer.

What about "Dronever"?

No. Emphatic no. Do I look like I have the money to register two domains?

What do I do if I accidentally release a backwards incompatible change?

Rejoice. To embrace Drone-Ver is to embrace chaos itself.

How should I handle deprecating functionality?

With gusto.


The Drone-Ver specification was authored by Curtis Lassam, internet cartoonist and internet gadabout.

If you'd like to leave feedback, I'm sure you'll find a way.


This document is a remix of SemVer. Except this standard is way better. Especially better than TenVer, which was authored by a real scoundrel.


Creative Commons No-Commercial Closed-Captioned International Share-Alike

Conference Call

Image title

Getting the visual language for this joke right was surprisingly difficult. It involves a lot of cutting from place to place. I hope it comes together.

Small Classes Big Classes


I was discussing some of the finer points of coding with my boss yesterday, and we're somewhat diametrically opposed on some points. In the end, he brushed aside my suggestions as "style differences" but I think it's more of a maintainability issue, and I was curious what the rest of you thought. I'll try to present both sides neutrally.

When designing a system in an OO environment, is it preferable to have fewer, larger classes with similarly few methods, or many classes and methods, and at what point have you gone too far in one direction?

My Answer

It feels like there's a bit of a hole in the "few classes/few functions" vs "many classes/many functions" dichotomy. In a system with fewer classes, those classes will require many functions as each class will be dealing with more state and performing more tasks. So it's "few classes/many functions" vs "many classes/few functions".

I prefer to keep classes as small as reasonably possible. Imagine a single instance of your class in isolation, as its own application. Each instance variable is functionally a global! The bigger that this unit becomes, the harder it gets to test, maintain, manage, and reason about. Global state needs to be cached in your memory all of the time while you're coding, so if a class has more than about 7+-2 instance variables that need to be reasoned about, you're going to make mistakes. Having many variables also vastly increases the number of potential "error" or "invalid" states your class can be in. Can you reasonably check for all of them?

Martin Odersky, describes "shared mutable state" as the root of all evil, and his language, Scala, focuses really tightly on forcing developers to either treat state as immutable, or keep it tightly under wraps. The mutability checking is statically compiled into the language. Seriously if it weren't for rampant abuse of operator overloading and the ongoing nightmare that is the JVM, I'd be a dyed-in-the-wool Scala advocate. The bigger a class gets, the more shared mutable state that class has.

"As small as reasonably possible" can be hard to manage, though. Code wants to intertwine. How do you keep classes small and minimize shared state?

I seriously distrust deep inheritance trees. Not for C++ programmer reasons like "vtable lookups" - if I cared about performance I wouldn't be a Python programmer. My problem with deep inheritance trees is the widening avalanche of state that gets bigger and uglier as you travel closer and closer to the object that you're actually using. Reasoning about code at the bottom of the tree requires knowledge of every step up the entire chain. A small class in a deep inheritance tree is just a LARGE CLASS.

People who are stuck with Java are forced to favor composition/interfaces over inheritance ( https://en.wikipedia.org/wiki/Composition_over_inheritance ) - whereas C++ and Python offer multiple inheritance, and Scala and Ruby offer mixins and traits - making it possible to build very broad inheritance trees where individual classes only focus on managing small parts of the class.

Scala also borrows from Haskell a focus on allowing programmers to build functions that just take small immutable objects as arguments and produce small immutable objects as output, which is composable as fuck and easy to test and awesome to the power of cool.

okay I'm dithering all over the place here

Lots of small classes! Immutable if possible! Share as little as possible! No deep inheritance trees!

See how I build a comic:

humor ,javascript ,linux

Published at DZone with permission of Curtis Definintely , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}