On Stealing Dreams

At present I am just under 2 weeks away from jetting off to Portland to attend OSCON, where I will proclaim with an acknowledged hubris that our American education system is fundamentally broken and that I have a fix for it.

Aside from madly trying to stuff facts and figures that the Open Education Track attendees might actually care about as to why the free-education (as in freedom, not as in beer) model that has naturally evolved around hackerspaces will be the model that carries our next few generations into success (if we choose to succeed at all), I’ve been poring over Seth Godin’s Stop Stealing Dreams. It’s incendiary, and a great way to get myself excited about convincing other educators to help legitimize the kind of free-form education that is actually preparing today’s students for the current networked economy.

Granted, this is probably a bit of confirmation bias, but Godin firms up a lot of what I’ve suspected all along about why schools (even good ones) aren’t working. I’ve selected and summarized a few points from the first few chapters:

  • We expect low-income schools to be bad, but they’re probably not bad for the reasons we think they are.
  • We started compulsory education to build better factory workers, and industrializing the education system in a way that benefitted factories resulted in a system that doesn’t create motivated scholars. As a result we created 50 years of uncreative, obedient workers and a dearth of “tradable” jobs. If you do a job where someone tells you exactly what to do, he will find someone cheaper than you to do it.
  • The school system we’ve built is bad at teaching cultural coordination, interest in pursuing knowledge and giving students good decision-making skills. We’re cranking out lazy thinkers.
  • Horace Mann thought he was building a better society of educated workers with character, but the qualities of character he originally attempted to instill (obedience, punctuality, etc) are no longer the needs of a worker in a network economy.
  • We still base our students’ “achievements” with multiple-choice tests, originally designed as a test of “lower order thinking”, and perhaps the least effective way to assess how thoroughly a student has absorbed a subject.
  • Instead of squashing dreams, we’ll need to encourage creativity and leadership if we want our students to succeed. They need to be dreaming bigger than “Personal assistant to a famous singer”.

Frankly, the kind of education we encourage in hackerspaces (perhaps the only kind we’ll tolerate) is Passion-based learning. Hackerspaces attract the passionate, those with a drive to fix the problems they find in the world.

I know anecdotally that the hackerspace model works, and can get someone who didn’t think they were interested in math or science doing precisely those two things at the lure of a blinking LED or bleeping piezo disc. I know empirically that the K-12 and college systems that I grew up in don’t prepare the students who are graduating today with the skills I need from them right now. I can’t wait (and none of us should) for the landslide change that brings forth a newer more successful kind of innovator from the American education system, and I think that the passion-based open education is exactly the rock that’s going to start that landslide.

My wacky vim/simplenote setup

Today I saw a question on the /r/vim subreddit about what people use to keep notes in vim and sync them across devices. Since this is something it took me forever to find a “groove” with (I guess that makes it something I’m passionate about?),)I took the opportunity to put down all the various programs I use to enable me to deal with taking notes and using vim.

I have always wanted a system that:

  • I can read pretty much wherever
  • I can take notes primarily in the editor I am fastest with (vim)
  • I don’t have to do maintenance on (remember to upload, commit, sync, blood sacrifice)

The following is the best I’ve come up with, and works pretty darn smoothly.

I tried a bunch of stuff over the years. Vimwiki, Vim-organizer, running org mode in that other editor, managing my own ReST files, keeping things in dropbox, keeping things on github… nothing was quite right. It was either a management overhead or didn’t go on all my devices how I liked or whatnot.

Nowadays I use this setup:

  • simplenote account

    Store simple plain-text notes in a cloud account. There’s like 90 bajillion apps that sync to simplenote because it does one thing and it does it well.

  • Simplenote.vim

    This one lets you see, edit, tag and delete your simplenote notes from a buffer in vim

  • Flick Note

    No bullshit simplenote app for android so I can get the notes I took on the go. Actually, they’re just magically already there, i don’t have to “get” anything.

  • nvAlt

    On the Mac, this is a really handy simplenote viewer plus it can render markdown and TeX, AND it has hotkeys to launch the current note as a buffer in Macvim.

  • nvpy

    This is the same as above but for linux (although it runs on the mac too with python and gtk installed). Slightly different features, but same use case and effectiveness.

This setup is the one I’ve found that gets what I want (synced markdown notes everywhere that I can edit in vim everywhere that I care to do editing and not mattering which OS I am using at the time and mostly just view on my phone or tablet) with the least amount of care and feeding to keep shit working.

Hope it helps.

Map git branches to each of your web service instances

When I have multiple server instances deployed from the same repo, I prefer to keep track of them with local branches, especially when using multiple clouds services like heroku and openshift. This makes it really easy to merge features branches into a particular instance’s deploy without ever bringing it into master, but still allow the inclusion of those commits into other instances after it folds into master.

The usual feature-branching

So, I have master, which stays as the primary place to put new commits. I then split features branches off of master and then merged in when they are accepted.

% git checkout -b wicked-sweet-login-page
% vim static/teh_loginz.html

# coding happens… <tappa tappa tappa>

% git add $_
% git commit -m 'made the login page look BALLER'

% git checkout master
% git merge wicked-sweet-login-page

Here’s a visual of this kind of branching from Pro Git (which is free to read online, by the way). If you haven’t read it, it’s certainly worth your time.

like so - image property of git-scm.com

Branches for server instances

However, in non-trivial projects, not every feature should go to every instance immediately, and it might entirely skip the master branch and go directly to the development environment until it’s accepted and merged to the staging server. For example a feature might get pulled directly into a dev branch to be deployed to myserver-dev.herokuapp.com, without ever touching myserver-stg.herokuapp.com or ever origin/master

% git checkout develpment-server-branch
% git merge my-test-feature

I can then push this particular branch to our development instance as the master branch on that instance by doing the following.

% git remote add development-remote git@heroku.com/myserver-dev.get
% git push development-remote development-server-branch:master

This way, each of the instances maintains a state that directly relates to local copies. Without dealing with the instance of the server in question, I can easily check where a server is at, and even run diffs against the remote if a feature was merged into the remote instance without actually being put into the appropriate branch first.

# wait… are we sure that's how it is in the live version?
% git diff origin/remote-feature-branch dev

# this won't work if your user doesn't have permission to access dev server repo
% git diff origin/remote-feature-branch dev/master

But why?

Admittedly, this is entirely unnecessary: it is completely possible to manage a whole slew of remote instances entirely on SHA hashes and intuition. I even have a pretty clever team most of the time, who are very good about keeping up with what features should be in what branches and what features should be on a given server. However, teams change over time, and projects get handed around. Keeping a record of where in a codebase’s history each remote is at with a branch (aside from whatever other record-keeping the team is doing) gives an immediate reference point of where each server should be at, at the cost of a mere 40 bytes and a few extra extra shell commands. Centralized branches for deployments communicate to the whole team a clear boundary between what is deployed where.

Lastly, if you are using only heroku, they have a quick-start tutorial in their dev center on how to manage multiple server instances using their own tooling.

doubleDrop updated

Today, I finally remembered the password on my Android Market keystore. This means that I got to update doubleDrop to 0.5. If you’re unfamiliar with it, it’s a tap-BPM app for figuring out the tempo of songs you’re listening to. When I wrote it, it was the only tap BPM app that let you do this with two tunes at once, making it the ideal tap-BPM app for DJs.

Really, the only change in this version is that I’ve been meaning to fix the drawing math so the records didn’t look… let’s just say “silly” on tablets. They were not scaling properly, and now should blow up to arbitrarily large (or small) sizes. They’ll probably look all pixelated on higher-resolutions, but it’s better than barely being visible. :)

Go check it out!

20 GOTO 10

Tuesday, I learned that since our NIH grant has run out, Backyard Brains is no longer able to afford to employ me. This news hit me quite hard, since BYB is by far the most interesting and educative open source project that I have worked on (and the first one to offer me a regular paycheck). It’s been an amazing year working with everyone at the company — and my have we grown since I signed on! A year ago I was the only full time employee, and have since managed to hire a production team to build Spikerboxes, ported the stable features of our iOS app to Android, set up a Javascript app to prep for recording neural information in the browser when the Web Media APIs stabilize, and managed to put out fires relating to a myriad of growing pains while our owners were in South America making the world a better place for Chileans hoping to catch the startup-company fever that we North Americans hold so dear.

Earlier this year, Backyard Brains applied for a second phase of funding, so there’s a hope that we’ll be able to afford to hire a developer again to continue to enrich the software assets at the company. However, I personally would have a hard time waiting around until early next year to hope that we will be in a financial position to keep my position as a Software Engineer going. Thus, it’s time for me to look for some other opportunities. I’ll be looking for positions writing software in any project that lets me continue my never-ending adventures in learning wicked-cool new languages, frameworks, business models, and engineering practices.

Until then, what now? Well, like any good develeper with too much time on their hands, I’m going to make stuff!

  • First of all, I plan on staying on with Backyard Brains in a voluntary position assiting with the management of their open-source software (I’m the local git ninja) for as long as they’ll have me or until they can manage to bring someone on in a paid position to handle it. I’m also planning to continue to help with adding features when possible, as I’m passionate about the project, and know every line of that code goes to helping youngsters learn about science.
  • I’ve also had a number of open-source projects on the backburner for a while that have gone under-attended due to how busy the work on BYB software has kept me. I can’t wait to get back to these with all the ideas I’ve been slowly adding to them — my .org file looks really ugly right now.
  • As it happens, I’ve still been serving on the board of directors for our hackerspace All Hands Active here in Ann Arbor, MI. The amount of work that could be put into furthering the hackerspace and helping the community around it could easily be a full-time job itself. You’ll be able to find me there rather often (as if I weren’t there enough already).
  • I think it’s actually obligatory that when a developer doesn’t have a paying position, they restart their personal website (that they were ignoring while persuing other interests) and make posts about things only a small subset of the software community cares about. (check)

For now though, it’s time to prep for teaching programming to youngsters for 2 days straight at our booth at Detroit Maker Faire. If you’re coming, stop by and say ‘print “Hello World”’!