Mar 06

Nifty Things for Week Ending 6 March 2015

Karojisatsu — PSA & Must Read

Stephen, in his presentation, described a Japanese term called Karoshi – literally as “death from overwork.” I have seen this hundreds of times in our industry and I also have come close enough to understand the brink of Karoshi myself. … In the 1980s there was such a concern about Karoshi in Japan that the Japanese Ministry of Labour began to publish statistics on it. While most of the discussion around Karoshi deals with older workers dying from heart attaches and strokes, the Japanse have also identified “Kar?jisatsu” as someone who commits suicide due to this kind of mental stress. — Kar?jisatsu « IT Revolution IT Revolution



Our Feline Overlords


Web Playground

Things of Beauty

Moonlit night of plum blossoms
* Moonlit night of plum blossoms | Today’s Image | EarthSky

The Final Frontier



Raspberry Pi


When you write copy you have the right to copyright the copy you write. You can write good and copyright but copyright doesn’t mean copy good – it might not be right good copy, right? — Copyright 1991 Shelley Herman S.P.E.B.S.Q.S.A., Whittier Chapter. Adapted and Appended by Scott Simmerman. Copyright Explained!


Mar 06

Cloudy with a chance of Raspberries

Raspberrbee Pi Swarm!

Raspberrbee Pi Swarm!

I have been experimenting with Raspberry Pi computers with the intent of having a small cloud that I can take with me to talks.


  • I can have a good sized cluster in a small volume.
  • Low power draw (6W or less per computer)
  • With the release of the Pi 2, distribution based upon available resources is available.


  • Binaries need to be recompiled in many cases
  • Memory is limited
  • Processing power is limited

The last one, particularly with the new Pi 2 B’s quad core processor is less of an issue. Additionally, the Pi 2 has more memory than its predecessor.

All in all, though, given that many lowend cloud instances have 512M or 1G ram, I think that the Pi is of a decent size for experimentation. I may even try to be masochistic enough to try Hadoop on the cluster.


At present, the cluster consists of the following:

  1. 2 stacks from HDZConcepts
    HDZConcepts Stackable Case

    HDZConcepts Stackable Case

  2. Four Pi B+ — these were on sale, so I purchased some. A couple of days later, the new version was released.

  3. Five Pi 2 B
  4. A 16 port 10/100 switch
  5. Power supply rated for 60 watts

There are a couple of extra PI; one of each flavour. These I’ve been using for some experiments & compiling; I’m not sure what role they will play as yet.



Previously the choices for running Docker with Raspberry Pi’s were limited to either running Archlinux, Raspbian updated to Jessie, or attempting to make the release from [](} work with more current versions. I was able, after much time elapsed, to update stock Raspbian to Jessie, then compile Docker 1.4.x on a Pi B+. This took many hours.

Recently, however, a very compelling possibility emerged.

The wonderful people at Hypriot announced that Docker 1.4.1 is working on the Pi 2, and that they have a very lightweight image with it (that works on both Pi B+ and Pi 2)!!! on their blog: Kick-Ass Raspberry Pi 2 having a forbidden love affair with Docker 1.4.1


They have since announced support for 1.5: Heavily ARMed after major upgrade: Raspberry Pi with Docker 1.5.0 – Docker Pirates ARMed with explosive stuff


Swarm is written in Go and the current methodology is rather than to ship a binary executable, the commands are run from within a Docker container. I’d started the process of bootstrapping a Golang container for the Pi when I happily discovered that someone else had done so.

In order to create a swarm container for the Raspberry Pi, clone the git repository for swarm:

The Dockerfile needs to be edited; there are a few differences which are necessitated by the different platform and differences which result. Here is the resulting Dockerfile

Once the Dockerfile has been edited, then compile it like this:

You now have a working swarm container and can run swarm commands as follows:


I have started a repository for Dockerfiles (and changes necessary) for building containers on the Pi. It can be found at aetherical/rpi-dockerfiles.

I will soon post scripts and a demo of using swarm with the raspberry pi….

Mar 04


11 Raspberry Pi, (Pi 2x6, Pi B+x5), Cables, Switch, and Power. (Keyboard not shown)

11 Raspberry Pi, (Pi 2×6, Pi B+x5), Cables, Switch, and Power. (Keyboard not shown)

Have cluster, will travel…. Build details to follow shortly.

Feb 27

Nifty Things for week ending 27 February 2015

Cloud Computing




Social Consciousness

  • ENABLING THE FUTURE — A Global Network Of Passionate Volunteers Using 3D Printing To Give The World A “Helping Hand.”

Small Computing


  • [How I got to see an upside down iceberg](]

Monitoring & Logging

Artificial Intelligence


  • feedr — feedr can generate custom data and send it away..

Song remains the same

Feb 25

Grabbing Titles & URLs with a Bookmarklet

The following is fixing the wrong problem, but often technology is easier than people problems. $WORK removed the ability to use plugins with Chrome without having to go through a bureaucratic process lasting weeks. One tool I’ve found useful is the ability to copy the title and link of a page to the clipboard and I am missing it mightily. After a (admittedly brief) search for a generic solution, I came up with the following, which is loosely based on information found at the following:

It’s not perfect, and something of a hack — I didn’t find a browser independent method to copy to the clipboard, but it beats cutting and pasting. Drag the following link to the bookmark bar:

The link looks like this:

The false is important; without it you’ll be taken away from the current page and the page will be replaced with the title and url of the page you’d been on….

It’s easy enough to modify; a similar link returning html follows:

As an aside, Bookmarklets – Design tools has a great tool for editing bookmarklets.

Feb 13

Nifty Things for Week of 13 February 2015





Nifty Things


Feb 12

Developer Personality

DZone is conducting a survey of Developer Personality Types along the lines of a Meyers-Briggs analysis. They plan to shortly release the results, but will leave the “quiz” up after. If you’re curious about your developer type, you can take it at:

Here’s my results from the full test (62 questions). In each case it shows how I scored, then a description of the two types.

Independent vs Collaborative

You are Collaborative!


You prefer to spend most of your time working in an isolated environment. You rarely want to collaborate because you have a better chance of solving problems on your own. If you do have to collaborate on the direction of a project, you dislike it when you have to defend your position or when others try to muddy your plans for the project. It’s better to have one strong vision for a project from the lead programmer on that project. Having a large team or allowing others to have significant control over the project risks communication errors, a muddied code base, and inefficiencies. If one developer has a firm grasp on the entire codebase, they’ll be much better at fixing and improving it quickly.


Good code doesn’t happen in a vacuum. You need a team to keep you energized and on your toes so that you’re constantly improving the project code using the entire team’s varied experience and strengths. You like to talk frequently with colleagues and discuss ideas so that you can learn from others and spark ideas. It doesn’t matter what their experience level is, you can always learn something by including everyone. A solo coder can’t possibly code a large software project with the speed and quality that a team can.

Abstract vs Low-Level

You are both Abstract & Low-Level!


You prefer to write in languages and frameworks that simplify development as much as possible and use as few characters and lines of code as possible. The trajectory of software development has always been toward making life easier and error-free. Programming has always been about adding more abstraction layers to simplify tasks, so why not trust the technology on your layer and don’t worry about handling the lower layers?


The more abstraction tools and high-level languages we build, the further we get from understanding and controlling the deeper components in our programs. This means lower performance and endless bug searches. Developers today need to have a stronger understanding of compilers, memory management, pointer arithmetic, and other low-level topics.

Frontier vs Conservative

You are on the Frontier!


You like to work at the cutting edge. Using too many old languages and technologies bores you, and it severely hinders your software’s potential to keep outdated technologies in it for too long. Developers need keep their ears to the ground for new technologies and new versions of tools that they already use. Even if the community and maturity of the project isn’t at a level that most enterprises would consider “safe,” you’re willing to be an early adopter if you believe the community and the technology has momentum. Development technology is changing faster every day, and we need to constantly be adopting new tools and methods to keep up.


It seems like every 10 years we forget all the problems we solved in the previous decade and start to build ‘new’ tools that solve the same problems, even though there is a perfectly good solution that has existed for years. Enterprises have it right when they make conservative decisions about their technology stack. Why would you hang your business on a technology with only a few years of maturity in just a handful of production use cases? Technologies like PHP, Java, and SQL have been mainstays of the development industry for years, and it takes a lot of time for new technologies to make it into that maturity tier.

Generalist vs Specialist

You are a Generalist!


You like to be known as a “Jack of all Trades” and a reference for others on your team. You jump at every chance to enhance your skills in a wide variety technology topics, not just the ones that apply to your day to day work. You don’t always know when it might be useful to have these extra skills, but when the time comes, you are ready. If more developers took the time to learn other skills outside of the ones relevant to their project, they’d work more seamlessly with the rest of their organization because they’d have more empathy and understanding of the challenges that their colleagues face.


If you’re a Jack of all Trades, you’re a master of none. Mastery in one or two areas is what makes you valuable. What’s the point of learning skills for other jobs you don’t have and can’t control? When you plan for a project or do technical research, it’s always focused on something you’re working on. You don’t get side-tracked. If you learn a new skill, it’s because the project requires that you do it. Most or all of your hobby projects are also building your mastery of the skills you use at your job.

Idealist vs Pragmatist

You are Pragmatic!


You believe in the power of well-defined processes. It’s crucial to an organization’s success that they create and follow appropriate and effective processes for building software. Trying to improvise or play it by ear invites the possibility of workflow errors that can decrease the quality of the software or even cause major product failures. Planning is also extremely important to you. You like to research all of the things you will need to know before starting a project. It’s important to find out the best architecture for your software beforehand, and then strictly implement that architecture with objective best practices. The more planning and scaffolding you do in the beginning, the less overall work you will have to do to complete the software.


Speed is your best weapon in a competitive industry, and to quickly prototype and build new products, you need to have a flexible, pragmatic process. You don’t have a few months to plan your projects, you need to just start coding and a good path for the project will reveal itself. Great products are made through frequent feedback and releases, so why shouldn’t your plan be just as adaptable? Your plan should be adapted to changes in the software, and your expertise should be adapted to the project. You shouldn’t spend your precious time studying a problem that you’re not certain to run into while coding your projects. Trying to build test coverage for every possible scenario and having long meetings throughout the process are a waste of time and distract you from doing more productive work.

Feb 06

Nifty Things for Week of 6 February 2015

Historical Footnotes


Raspberry Pi

Software Architecture


  • .bashrc PS1 Generator — generate your .bashrc PS1 prompt with drag & drop.
  • mkcast — tool for creating GIF screencasts of a terminal, with key presses overlaid
  • epoch — A general purpose real-time charting library for building beautiful, smooth, and high performance visualizations.
  • Google Web Starter Kit — Multi-device responsive boilerplate
  • Gulp — automate workflow
  • deb.js — Minimalistic JavaScript library for debugging in the browser; this looks really cool!

Neat Stuff

This week’s image was drawn by my daughter, Althea, almost a year ago — I’d asked her to draw me as an animal, and this was the result.

Feb 01

Nifty Things for Week of 30 January 2015

Big Data

Cloud Computing





*Introducing statsd-jvm-profiler: A JVM Profiler for Hadoop

Jan 23

Nifty Things for Week 23 January 2015







Older posts «