Some JavaScript API Coding With Restify & Express & Hacking it With cURL …Segment #1 (with some Webstorm to boot)

So often I end up putting together some RESTful services (or the intent is to at least build them with that premise, but we all know how that ends up). The API URIs routing gets put together and one wants to take a crack at the service as soon as possible. Here’s a quick guide for using cURL to take some basic actions against the services and understand what you’re getting back.

The first thing to do is make sure you can run JavaScript, which means you have a computer. The second thing is to get cURL, which means you’re running some variant of Linux or UNIX. In most scenarios one would be running OS-X. The easiest way to determine if it is installed on your computer just open up a terminal and type ‘curl –help’. You should get a result with all the switches, which is almost always a bit of overload.

[sourcecode language=”bash”]$ curl –help
Usage: curl [options…]
Options: (H) means HTTP/HTTPS only, (F) means FTP only
–anyauth Pick "any" authentication method (H)
-a, –append Append to target file when uploading (F/SFTP)
–basic Use HTTP Basic Authentication (H)
–cacert FILE CA certificate to verify peer against (SSL)
–capath DIR CA directory to verify peer against (SSL)
-E, –cert CERT[:PASSWD] Client certificate file and password (SSL)
–cert-type TYPE Certificate file type (DER/PEM/ENG) (SSL)
–ciphers LIST SSL ciphers to use (SSL)
–compressed Request compressed response (using deflate or gzip)
-K, –config FILE Specify which config file to read
–connect-timeout SECONDS Maximum time allowed for connection
-C, –continue-at OFFSET Resumed transfer offset
-b, –cookie STRING/FILE String or file to read cookies from (H)
-c, –cookie-jar FILE Write cookies to this file after operation (H)
–create-dirs Create necessary local directory hierarchy
–crlf Convert LF to CRLF in upload
–crlfile FILE Get a CRL list in PEM format from the given file
-d, –data DATA HTTP POST data (H)
–data-ascii DATA HTTP POST ASCII data (H)
–data-binary DATA HTTP POST binary data (H)
–data-urlencode DATA HTTP POST data url encoded (H)
–delegation STRING GSS-API delegation permission
–digest Use HTTP Digest Authentication (H)
–disable-eprt Inhibit using EPRT or LPRT (F)
–disable-epsv Inhibit using EPSV (F)
-D, –dump-header FILE Write the headers to this file
–egd-file FILE EGD socket path for random data (SSL)
–engine ENGINE Crypto engine (SSL). "–engine list" for list
-f, –fail Fail silently (no output at all) on HTTP errors (H)
-F, –form CONTENT Specify HTTP multipart POST data (H)
–form-string STRING Specify HTTP multipart POST data (H)
–ftp-account DATA Account data string (F)
–ftp-alternative-to-user COMMAND String to replace "USER [name]" (F)
–ftp-create-dirs Create the remote dirs if not present (F)
–ftp-method [MULTICWD/NOCWD/SINGLECWD] Control CWD usage (F)
–ftp-pasv Use PASV/EPSV instead of PORT (F)
-P, –ftp-port ADR Use PORT with given address instead of PASV (F)
–ftp-skip-pasv-ip Skip the IP address for PASV (F)
–ftp-pret Send PRET before PASV (for drftpd) (F)
–ftp-ssl-ccc Send CCC after authenticating (F)
–ftp-ssl-ccc-mode ACTIVE/PASSIVE Set CCC mode (F)
–ftp-ssl-control Require SSL/TLS for ftp login, clear for transfer (F)
-G, –get Send the -d data with a HTTP GET (H)…[/sourcecode]

Don’t get intimidated! It goes on and on and on, but just know it’s installed if you see all these goodies. If you don’t get the results above, then installing cURL is the next step. I’ll leave that to you. Here’s some links to download and get started however.

Next you’ll of course need Node.js and Restify installed. I’ll assume you have Node.js installed. Create a directory and in that directory just run the following command.

[sourcecode language=”bash”]
npm install restify
[/sourcecode]

Next create a file called server.js in that directory you’ve just installed restify in. Here’s the initial JavaScript code for that file that I’ve used to put together for the first few examples of using cURL.

[sourcecode language=”javascript”]
var restify = require(‘restify’);

function respond(req, res, next) {
res.send(‘hello ‘ + req.params.name);
}

var server = restify.createServer();
server.get(‘/hello/:name’, respond);
server.head(‘/hello/:name’, respond);

server.listen(8080, function() {
console.log(‘%s listening at %s’, server.name, server.url);
});
[/sourcecode]

Ok, now to run this with node.js just issue the command to launch node.js with this file that was just created.

[sourcecode language=”bash”]
node server.js
restify listening at http://0.0.0.0:8080
[/sourcecode]

Getting Get

Now the service is running on port 8080 against 0.0.0.0. To check out what a standard GET verb will do in a browser, open up a browser and navigate to http://0.0.0.0:8080.

Browsing the GET response via Chrome.
Browsing the GET response via Chrome.

You’ll see this in the browser window. Just straight plain text too. If you look at source, this is all you get back. Now open up a terminal and run the following cURL command to execute a GET against the URI & port. This is the most basic cURL command one can make. It is simply issuing a GET request against the URI and will display the body of the response.

[sourcecode language=”bash”]
curl 0.0.0.0:8080
[/sourcecode]

The response will be similar to this for the particular request.

[sourcecode language=”bash”]
{"code":"ResourceNotFound","message":"/ does not exist"}
[/sourcecode]

Your terminal will probably stick the subsequent prompt at the end of the result too, because the result doesn’t end in a newline. Beware of that, your prompt hasn’t disappeared. 😉

To get a little more information you can get the header of the response dumped into the terminal with a -i. The -i option stands for –include, to include the header. Issue the command as either line shown below.

[sourcecode language=”bash”]
curl -i http://0.0.0.0:8080
curl –include http://0.0.0.0:8080
[/sourcecode]

The response will be provide a little bit more about what is going on.

[sourcecode language=”bash”]
HTTP/1.1 404 Not Found
Content-Type: application/json
Content-Length: 56
Date: Wed, 27 Nov 2013 00:27:36 GMT
Connection: keep-alive

{"code":"ResourceNotFound","message":"/ does not exist"}
[/sourcecode]

With this response the actual response error code number is shown. In this case we have a 404, which points us to the problem with this curl request. The server isn’t returning anything to our curl request. If we look at the code, we can see that the ‘get’ route is setup as ‘/hello/:name’ which means that the domain root is only looking at http://url_root/hello/someName for a request to be made in order to return a response.

[sourcecode language=”javascript”]
var server = restify.createServer();
server.get(‘/hello/:name’, respond);
server.head(‘/hello/:name’, respond);
[/sourcecode]

Issue a command against the server now with the following curl request.

[sourcecode language=”bash”]
curl -i http://0.0.0.0:8080/hello/Adron
[/sourcecode]

The response should come back as an actual response with content.

[sourcecode language=”bash”]
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 13
Date: Wed, 27 Nov 2013 00:34:04 GMT
Connection: keep-alive

"hello Adron"
[/sourcecode]

Here the content is returned as “hello Adron” and the header returns a 200. The content type is application/json format with the length returned as 13. Note also the connection is set to keep-alive. Let’s dive into that.

If we change the connection type, which is important for many scenarios, we have to send extra header information to ask for the response to be returned accordingly. In order to do that we can pass the -H or –header option in with the curl request. If the command is issued with an -i and -H as shown below the result will be as follows.

[sourcecode language=””]
curl -iH "connection: close" http://0.0.0.0:8080/hello/Adron
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 13
Date: Wed, 27 Nov 2013 00:41:07 GMT
Connection: close

"hello Adron"
[/sourcecode]

If we take away the -i we’ll just get the response, which is “hello Adron” and wouldn’t get the header, which now returns Connection: close in the response. By default, curl sets the connection as keep-alive, but in order to make the request return right away the connection needs to be issued a request for it to close. By setting the -H or –header value of connection to close, we get the response immediately. With restify, it is also important to note that it checks if the user agent is curl.

If it is curl the connection header to close and removes the content-length header. However I’ve experienced that restify is not doing this in all circumstances or that the use of curl is being changed in some of my usage. So don’t always assume that this will be the case. The safest bet is to set the connection closed when done. Thus, adding -H or –header and setting connection to close with a “Connection: close”.

Beyond Basic Get

Ok, so that’s a pretty solid use of GET with cURL. Let’s dive into some puts and deletes with a get or two thrown in for comparison. Change the executing code to the code shown in the server.js file below.

[sourcecode language=”javascript”]
var restify = require(‘restify’);

function send(req, res, next) {
res.send(‘hello ‘ + req.params.name);
return next();
}

var server = restify.createServer();
server.post(‘/hello’, function create(req, res, next) {
res.send(201, Math.random().toString(36).substr(3, 8));
return next();
});
server.put(‘/hello’, send);
server.get(‘/hello/:name’, send);
server.head(‘/hello/:name’, send);
server.del(‘hello/:name’, function rm(req, res, next) {
res.send(204);
return next();
});

server.listen(8080, function() {
console.log(‘%s listening at %s’, server.name, server.url);
});
[/sourcecode]

The first section of code to check out is around the function send.

[sourcecode language=”javascript”]
function send(req, res, next) {
res.send(‘hello ‘ + req.params.name);
return next();
}
[/sourcecode]

This function is setup to take req, res, and then handle next. The req is the request, the res is the response and the next is for issuing to return and continue with the result. The next bit of code starts the server with the restify.createServer();. Just below that there are several handlers that are setup.

[sourcecode language=”javascript”]
server.post(‘/hello’, function create(req, res, next) {
res.send(201, Math.random().toString(36).substr(3, 8));
return next();
});
server.put(‘/hello’, send);
server.get(‘/hello/:name’, send);
server.head(‘/hello/:name’, send);
server.del(‘hello/:name’, function rm(req, res, next) {
res.send(204);
return next();
});
[/sourcecode]

Now at this point I got a little sidetracked writing this blog entry. But I thought to myself, “hell, I’m just figuring out some parts of Webstorm, I ought to blog a little about it!” So, here’s…

A Little Webstorm Love

Webstorm and cURL. Click the image for a full size image.
Webstorm and cURL. Click the image for a full size image.

Before continuing on I wanted to cover a few tidbits of the Jetbrains Webstorm IDE. I often switch back and forth between the Sublime/Terminal combo and the Webstorm IDE. The really cool thing about this IDE is that it actually has a Terminal built in, color coding and autocomplete of the code, refactoring, and file and folder viewer and a whole slew of other features. In the image above that I’ve included there are four neon pointers that are displaying some of the key functionality that I’m using to work through this blog entry with cURL and Restify.

The arrows, from left to right are pointing to the following IDE elements. The first is pointing to the javascript files storgie.js and starter.js which I added specifically to show the git status colors. Each color reflect if the file is new (green), has changes (light blue) or is committed with no changes (white). The second arrow is just pointing to the general folder structure. Here you can see the hidden .* files like the .gitignore and .npmignore and also easy to dig through the node_modules directory. Webstorm also uses the node_modules directory to provide extra information and autocomplete to the code as you work through your coding session. The next arrow is pointing out the terminal in the editor, which is where I’m working up the curl examples in this blog entry. Then of course the color coded starter.js file that is one of the working examples. Webstorm, simply, is pretty sweet. I’m looking to do some more walk throughs and work sessions with the editor in the near future. So if interested, be sure to keep reading and subscribe, I’ll be sure to post any links to wherever the material ends up right here.

Now, back to the cURLing. 😉

After I toyed around with Webstorm and bit to get it work in a way that was efficient for me to use it for developing these APIs I stumbled into an idea. I’d provide a page for the APIs that could be located at the root of the API service such as http://api.blagh.com. The APIs would still be a restful type schema like http://api.blagh.com/thing/create or http://api.blagh.com/thing/destroy but at the very root would be a kind of docs. Maybe this could just be a status page even. Whatever the case, there needs to be something at http://api.blagh.com so I decided right then and there I’d switch to express.js to build the rest of the API services. Restify is fine and all but for this, it seemed like express would have all of the pieces I need for this.

Just to boot, I then read a few articles about express being faster such as this one. But then I read this issue on github and almost thought, “maybe I should keep using restify” but then I thought, “dammit, just get it done the way you want it built” so it was back to express. It’s easy enough to change this later so I just got back to coding, albeit with express now. So keep reading and in the next day or two I’ll have part two of this series on using cURL to hack at your APIs.

Enjoy the composite coding & cheers!

References:

Why Phone Calls Suck and Coders Hate You For Making Them

<[Rant On]>

During the work day some of the most disruptive events for a coder are phone calls, getting punched in the face or bum fights in the street. Why are these events so disruptive to programmers? Much of the answer lies in the maker versus manager schedule. Let’s talk a little bit about what someone does when they make a phone call and actually manage to disrupt a coder. NOTE: This could also apply to every musician, painter, coder, programmer, database SQL writer or other occupation that actually requires doing something around a creative solution that isn’t baked into some text book.

The Mental Train Wreck

This is what happens every time the coder’s brain is interrupted with a phone call, punched in the face or a bum fight erupts outside.

Because in all of those situations, the coder must stop what they’re doing, complete a mental dump of all the things they’d loaded into their mind, to pay attention to the phone call somebody has just interrupted them with, the punch in the face or the bum fight outside. Let’s take a dive into what this interruption actually means.

Mental Dump, Starting the Train Wreck

No Dumping Brain to Bay.
No Dumping Brain to Bay.

The mental dump is the hardest part of the disruption for a coder. For a musician or artist, it often means they’re going to look at you (or the phone) and an immediate loathing of your person will occur. For a coder most will have their phone on ignore, like I myself do. If they do pick up, the first words spoken by the person calling will probably be indistinguishable. The mental dump takes more than a second or two.

But if a coder picks up the phone, they do it quickly, it often means they’ve not completed the mental dump yet. This in turn means they’re not going to be able to communicate with you in a very easy to understand way. Often a very boolean response will occur, such as “uhuh” or “uhno“. They’re hating you at this moment, because they’ve been removed from coding or thinking through the problem they were working.

What has happened here is a huge decrease in productivity for a coder. Imagine that train wreck above in the picture. How many hours, days and weeks did it take for the crews to get the train back on the tracks. How much effort did it take and how much time was lost by having the train sitting there crammed outside of the building tilted over and down on the sidewalk? I’ll tell ya, a whole freakin’ bloody lot of time, effort and frustration.

Time wasted: ~2 minutes.  (and that’s just to GET the phone call)

Getting Frontal Cortex Loaded, AKA Re-railing The Train Wreck

This mental dump takes anywhere from 30 seconds to 2 minutes to effectively complete. At this point, a creative individual has been thrust from an effective and productive place in their mind. What’s it take to get things back on track?

The first step is to get off of the phone and settle down from the frustration of being disrupted. Getting disrupted by one of the aforementioned annoyances is very costly. Doing a mental dump is because so much has been loaded in the gray matter for use in the coding, painting, music playing or other activity. To get front loaded into a state in which actual music can be played or written, a painting can be created or coding can be done takes time. I’m not talking about a few minutes here or there either, I’m talking about 10 minutes being a low number. Often, it takes 30-45 minutes to get properly frontal cortex loaded. All of that time, upon the disruption is gone. All of it, every single minute. Sometimes a person can re-load a little bit faster then the initial loading, but often times not.

So what happens when the coder goes back to work? You guessed it, they have to get the frontal cortex loaded again. Yeah, your interruption just caused them many minutes, often 15-45 minutes just to pick up the bloody phone call.

Time wasted: ~15-45 minutes.

Maker Versus Manager Scheduling

Now we come to the serious problem. Not only did the phone call cause a disruption of epic proportions. The other massive problem is now the coder has to determine if it is even worth it to try to get the frontal cortex loaded and get back to work. Let’s take a few questions a coder has to ask themselves before getting back to work after such a disruption.

  • What if the phone call was 30 minutes before lunch? Nope, not worth it.
  • What if the phone call is 15 minutes before you’re going home? Nope, not worth it.
  • What if the phone call is 45 minutes before a meeting? Nope, that sure as hell isn’t worth it either. Meetings being a completely different topic that’s worth discussing, or ranting about sometime.

That’s just a few examples. So if the call disrupted the coder at a time before any other activity that requires they stop doing what they’re doing, it’s not even worth going back work on anything. With that in mind, if a coder is interrupted 30 minutes before lunch, that means another 30 minutes just got wasted because now the coder has to find some mundane task to do, or just surf the web ticked off that they got interrupted. Most programmers are often thinking of something that the great Captain Picard states so eloquently.

Captain Picard, not beating around the bush.
Captain Picard, not beating around the bush.

Time wasted: ~0-45 minutes or more.

Bum Fights & Punches In the Face

Punched in the face.
Punched in the face.

Ever been punched in the face? Ever had to deal with a bum fight? If you have you can totally relate to this type of interruption. The closest thing a manager is likely to experience is a bum fight or a punch in the face in comparison to a coder receiving a phone call.

Summary

The next time one thinks, “I’ll just give Bob the Programmer a call”, think again. Try not to be a complete douche bag in a land of naive obliviousness and maybe send an email or txt message. Maybe don’t even make the communication – because we all know how many times the answering box has a “hey I just called to say I called and you should call me so we can have a call“. That’s what one calls bullshit. EVERY PHONE ON EARTH has caller id, that’s a no shit sherlock moment.

So next time, please be considerate of your dear programmers, coders, SQL coders, painters, sketch artists, musicians, composers or others in your life. You’re not taking 5 minutes of their life when you call, you’re likely taking well over an hour and causing them much consternation.

Now that I’ve wasted 3 hours writing this post, mainly because I was interrupted by a phone call in the middle of writing it, I’ve got to get back to some work I was trying to wrap up post-turkey day comma.

<[/Rant Off]>

Oh yeah, this was indeed a sardonic post in case it wasn’t obvious. Oh and happy holidays!  😉

Is PaaS Tech Still Around? Maybe Containers Will Kill it or Bring it?

Recently a post from @Gigabarb popped up on the ole’ Twitter that started a micro-storm of twitter responses.

This got me thinking about a number of things and I started to write her an email specifically, but realized I should really just blog it. After all, the topic is actually part of what should be the public conversation. It’s about the changing world of technology, which we’re all part of…

First Topic: Usage of PaaS

Barb, just shortly after the tweet above was posted, this other tweet altered what information I might provide her. @TheSteve0 had responded with some items, which @GigaBarb then responded with

Now, not to pick on OpenShift & Red Hat (the effort @TheSteve0 is working with), because they have a great open source effort going on around this PaaS Technology, but Barb had a point. If Cloud Foundry responded with something like this, she’d still have a point. The only companies that continually sign up new companies is AWS & Beanstalk (ok, so they don’t call it PaaS, it gets you to the same place – arguably better than most of the others), a little bit at Windows Azure and a few companies pop up every once in a long while that might take Cloud Foundry or OpenShift and run with it. Most of the early adopters are already on board and most that might get on board are still mostly just waiting in the sidelines.

This fact is frustrating for those

in the space that want to see more penetration, but for those that arent’ technically in the space, it seems kind of like ASP. Oh wait, I should add context now, ASPs as in Application Service Providers. The technology from the beginning of the 21st century similar in many ways to what is dubbed SaaS now. At the time it could have been revolutionary. However at the time nobody picked it up either. This is similar to what PaaS is seeing. However…

A Hypothesis of What Will Happen to PaaS Tech

I have a theory of what will happen to PaaS Tech, it is similar to ASP Tech. PaaS will keep plundering along in odd ways, and eventually one day, it will become a mainstream tech. Right now however it will remain limited. In that same turn, by the time it becomes a common tech, it’ll be called something else.

Here’s a few reasons. One, is that many developers see PaaS and their response, especially if they’re seasoned developers with more than a few years under their belt, is to respond will immediate apprehension to the tech. It removes key elements of what they want to control. It hides things they can’t actually get to and it abstracts in ways that don’t always make sense. The result is that many senior devs stay away from pure PaaS offerings and instead use it only for prototyping, but production gets something totally different. I’ve been there more than a few times myself.

However, the result of what most senior devs end up with, when they get their continuous integration and development environments running at full tilt, is exactly what PaaS is attempting to promise. There are some companies, with senior devs, and extremely intelligent members that have taken PaaS and effectively implemented it into their continuous integration and delivery environment giving them strengths that most companies can only imagine to have.

One of those companies is lucky and smart enough to have Jonathan Murray @adamalthus heading up efforts. On his team he also has Dave McCrory @mccrory and Brian McClain @brianmmclain. To boot, they are close to the Cloud Foundry team (and @wattersjames, who cuts a path when there are issues) and keep a solid effort going working with key partners such as @Tier3 (now part of CenturyLink)  and other companies that help bring together one of the most strategically and tactically relevant PaaS deployments to date.

Other PaaS deployments are questionable for various reasons, they’re trying, but they aren’t there. At least not the types of companies and efforts that Barb was looking for. So really, if there is another out there that’s hiding, but wants serious street cred. A boost to hiring serious A grade talent, and to push forward past competitors, please let us know. Let me know, let Barb know and let’s hear about what you’re doing. If a company is hiding their implementation and doesn’t want to be part of the community, then fine, they can stay hidden and not gain the benefit of the community that presses forward beyond them. But I would love to hear from those that I might have missed, that want to push forward, so ping me. Ping Barb, we’ll get word out there and get developers checking out and making sure your company is getting it done! 😉

Second Topic: PaaS on PaaS and Start Docker

PaaS is nice. If your company can get it deployed and use it effectively, the you’re going to push forward fast in many regards. Deployments, savings, code cleanliness, effective separation of concerns and abstraction at a systems level are some of the things you can expect from a good PaaS implementation. Sometimes however, as the senior devs I mentioned pointed out, you give up control and certain levels of abstraction. However almost all senior devs understand that they want the ability to abstract at the levels that PaaS enables. They want to break apart the app cleanly at the system level from the software level. No reason for an app to know where or what a hard drive is doing right? That’s a rhetorical question, onward with the topic…

Docker has entered the market with a BOOM, part of the abstraction level that enables PaaS tooling in the first place. This tool enables a team to jump into the code or to just deploy the tool to abstract at a PaaS level, but to build the elements that they need specifically. The components are able to be brought together in a composite way that provides all the advantages of PaaS, while put together specifically for the problem space that the team is attacking. For environments that don’t make cookie cutter apps that fit perfectly to PaaS tooling as it is, that needs that little bit extra control of the environment, Docker is the perfect tool to bring those pieces together.

So really, is Docker and containerization that new word (from a technically old tech! lolz), that new tech, that’s going to bring PaaS into the mainstream as the standard implementation? Is it going to make PaaS become containerization when we developers talk about it? It could very well be the next big step. It could be that last mile coverage that devs want to push environments into a PaaS Tech ecosystem and make full use of hardware, software and move to the next stage of application development. Could it? Will it?

Personally I’m ready for the next stage of the whole PaaS thing, are you?

Next up on other thought patterns, WTF are people using Oracle for still when mariadb and postgres mean their freedom to innovate, move forward and surpass their competition.

Learning About Docker

Over the next dozen or so few days I’ll be ramping up on Docker, where my gaps are and where the project itself is going. I’ve been using it on and off and will have more technical content, but today I wanted to write a short piece about what, where, who and how Docker came to be.

As an open source engine Docker automates deployment of lightweight, portable, resilient and self-sufficient containers that run primarily on Linux. Docker containers are used to contain a payload, encapsulate that and consistently run it on a server.

This server can be virtual, on AWS or OpenStack, in clusters, public instances or private, bare-metal servers or wherever one can get an operating system to run. I’d bet it would show up on an Arduino cluster one of these days.  😉

User cases for Docker include taking packaging and deployment of applications and automating it into a simple container bundle. Another is to build PaaS style environments, lightweight that scale up and down extremely fast. Automate testing and continuous integration and deployment, because we all want that. Another big use case is simply building resilient, scalable applications that then can be deployed to Docker containers and scaled up and down rapidly.

A Little History

The creators of Docker formed a company called dotCloud that provided PaaS Services. On October 29th, 2013 however they changed the name from dotCloud to Docker Inc to emphasize the focus change from the dotCloud PaaS Technology to the core of dotCloud, Docker itself. As Docker became the core of a vibrant ecosystem the founders of dotCloud chose to focus on this exciting new technology to help guide and deliver on an ever more robust core.

Docker Ecosystem from the Docker Blog. Hope they don't mind I linked it, it shows the solid lifecycle of the ecosystem. (Click to go view the blog entry that was posted with the image)
Docker Ecosystem from the Docker Blog. Hope they don’t mind I linked it, it shows the solid lifecycle of the ecosystem. (Click to go view the blog entry that was posted with the image)

The community of docker has been super active with a dramatic number of contributors, well over 220 now, most who don’t work for Docker and they’ve made a significant percentage of the commits to the code base. As far as the repo goes, it has been downloaded over a 100,000 times, yup, over a hundred. thousand. times!!! It’s container tech, I’m still impressed just by this fact! On Github the repo has thousands of starred observers and over 15,000 people are using Docker. One other interesting fact is the slice of languages, with a very prominent usage of Go.

Docker Language Breakout on Github
Docker Language Breakout on Github

Overall the Docker project has exploded in popularity, which I haven’t seen since Node.js set the coder world on fire! It’s continuing to gain steam in how and in which ways people deploy and manage their applications – arguably more effectively in many ways.

Portland Docker Meetup. Click image for link to the meetup page.
Portland Docker Meetup. Click image for link to the meetup page.

The community is growing accordingly too, not just a simple push by Docker/dotCloud itself, but actively by grass roots efforts. One is even sprung up in Portland in the Portland Docker Meetup.

So Docker, Getting Operational

The Loading Bay
The Loading Bay

One of the best ways to describe docker (which the Docker team often uses, hat tip to the analogy!) and containers in general is to use a physical parallel. One of the best stories that is a great example is that of the shipping and freight industry. Before containers ships, trains,

Manually Guiding Freight, To Hand Unload Later.
Manually Guiding Freight, To Hand Unload Later.

trucks and buggies (ya know, that horses pulled) all were loaded by hand. There wasn’t any standardization around movement of goods except for a few, often frustrating tools like wooden barrels for liquids, bags for grains and other assorted things. They didn’t mix well and often were stored in a way that caused regular damage to good. This era is a good parallel to hosting applications on full hypervisor virtual machines or physical machines with one operating system. The operating system kind of being the holding bay or ship, with all the freight crammed inside haphazardly.

Shipping Yards, All of a Sudden Organized!
Shipping Yards, All of a Sudden Organized!

When containers were introduced like the shiny blue one shown here, everything began a revolutionary change. The manpower dramatically

A Flawlessly Rendered Container
A Flawlessly Rendered Container

dropped, injuries dropped, shipping became more modular and easy to fit the containers together. To put it simply, shipping was revolutionized through this invention. In the meantime we’ve all benefitted in some way from this change. This can be paralleled to the change in container technology shifting the way we deploy and host applications.

Next post, coming up in just a few hours “Docker, Containers Simplified!”

Docker Portland, Docker Hack Day & Portland Docker Logo -> Represent!

I threw together a Portland Docker logo user group banner today.

Why did I create a Portland docker logo? Because tomorrow is the Portland docker user group meet up. RSVP the group and check it out. I won’t be able to make this meet up but I will be attending and participating regularly. It’s at New Relic, so easy to find, great views and epic tech to discuss. Let me know how it goes.

On December 3rd, which I hope to be able to attend, it’s Docker Global Hack Day! Check out more by following the @dockerhackday and log into IRC and join #docker. Happy hacking, cheers!