Git a Job

While developing one’s software development skills are all the rage, being a pragmatic programmer is about more than just knowing what a JavaScript closure is. Your code needs to do more than just work: it has to be tested for edge cases and exceptions, it has to be reusable, maintainable, and modifiable for the next poor schlub who has to read it. More often than not, that poor schlub is Future You. I find the Programmer Competency Matrix to be a good reference on the many skill sets that being “skilled” at programming now entails. Looking in the comments on that post, people think even that listing of over 30 items is incomplete.

But the matrix is also incomplete in how little it addresses the collaborative abilities of the coder. Not everyone’s a Woz or a Carmack. For us mere mortals, being able to work together on a project can be a force multiplier. Having a distributed version control system (DVCS) like Git is like gaining the efficiency of the assembly line plus the creativity of crowdsourcing. Being able to work with people across time zones and cultures, as GitHub enables one to do, is a transferable skill. This post is about how Git can be a transferable technology, with uses outside of the programming sphere. It is related to a Thunder Talk I gave at the Matchbox Studio on February 6th, 2016.

 From the Git-go

I am not trying to make a comprehensive guide to Git, nor even cover basic commands, there are other sources online that do that much better than I can. If you look at the embedded slideshow, I point to for getting into the commands, as well as Emma Jane Westby’s various resources for learning Git. In this post I want to go over Git conceptually, and show how I used Git for application development of a different sense: job application development. I will refer to the slideshow below to help illustrate my points.

Slide 3 shows how most people do version control. They rename the file to reflect what change they made, or for what purpose they’ve revised the document. This gets unwieldy after a certain point, and God forbid you need to share this work with someone else. If you’ve ever worked on a group project where e-mail attachments are flying around with names based on whoever last touched the file, I’m sorry for inducing PTSD.

Slide 3, how most people do version control.

Slide 3, how most people do version control.

To resolve this, centralized version control systems provided a server for people to collaborate on code together. To help save on disk space, they would record the deltas (changes) made to the files instead of whole copies of the files. Workers could branch off and work on certain features without affecting the main code base, then merge things back into the fold when they were done. Like a library, you could check out and check in code to prevent people from stepping on each others’ work in the same file.

These systems, like CVS and Subversion, worked well for a while. But they also had their bottlenecks and single points of failure. So, in comes Git (and Mercurial, and Bazaar). I am focusing on Git because of the mammoth market share it now has; it has become the new lingua franca of version control.

A programmer wants to work on a project, they can clone it to their personal repository. This sets up a relationship between their copy of the code and any subsequent work that is done on the originating project. It’s a best practice to clone the code onto a separate “local” server, then pull another copy of the database onto one’s actual workstation.

Once a developer has a project clone, they can navigate the history of the project, but most commonly they will “branch” off the project for whatever revision they want to add to the code. They then “check out” the branch to make sure the code they contribute is isolated from the project. The revision control system reinforces modularity.

As the programmer completes functions they commit the work back in to their local repository. These commits are snapshots of the filesystem layouts of the project. Slide 9 shows how each revision (the folder numbers) will record deltas to the file, while unchanged files provide a pointer to the previous commit of the file.

Slide 9, Git taking snapshots of a project's filesystem

Slide 9, Git taking snapshots of a project’s filesystem

Once they’ve reached a certain level of functionality and feature testing, the developer can push their code back up to their personal repository. If the developer wants that code branch to be integrated into the original project (the “origin” repo), they call for a pull request. (Slides 10-16).

The phases of pulling and pushing a git project.

The phases of pulling and pushing a git project.

This point shifts the focus from the merits of a version control system to the merits of a distributed VCS. In a collaborative context, a project core member can take a look at the pull request by pulling the branch into their own personal repository. They can look at the functionality of the code, see if it complies with the style guide, is well-tested and documented, and merge the code into the development branch of the project.

A project that really has its act together can have hooks, automated scripts that can push the new development code up to a continuous integration server, running the code through the gauntlet of unit tests and style guide scripts to truly make sure the contribution is up to snuff. It the Test/QA Server finds the code up to muster, it can be merged into the master branch, which is what most end users end up using. Slides 17-21 illustrate this process, but if you want more information, don’t overlook Emma Jane Westby’s Git for Teams. I link to her site in the slideshow as well.

Git workflow in a team setting

Git workflow in a team setting


Résumé Management

I keep a MarkDown-formatted résumé, a master list along the lines of a CV to chart my skills, experiences, and accomplishments, which I can then whittle down to what is most pertinent to the position for which I’m applying. If the position calls for networking knowledge, then I will slide my Cisco certs up the batting order. If I am looking at a systems administrator job, I will rearrange the bullet points so that my Linux and Windows Server projects are more prominent. If I am trying for a development role, I will mention the hackathons and open source projects I’ve contributed to. Plus, GitHub profile is the programmer’s portfolio of the 2010’s. I also have a macro in Notepad++ which strips all of the distinctive MarkDown characters if I need a truly plain-text document to work with. As I iterate and remix the resume, I create a branch structure in employer/position format to keep things straight. If I add something like a new skill or certification, I can just update the master branch, then pull it into the other branches. It is easier for me to keep a resume straight with this structure than to navigate up and down directories, renaming things based on when and where they were submitted. What are your thoughts on this approach to résumé revision control?

Chains and Trains, Pt. 3

This post is the third in a series on my experiences at the NC Bike Summit

How to Turn Elected Officials and other Town Employees

Heidi Perov Perry and Eric Allman described the evolution of their newsletters into the Carrboro Bicycle Coalition. They demonstrated how to legitimize and politicize informal bicycle groups through several steps. First, they need to advise the town on its bicycle master plan, and write themselves in as a bicycle advocacy group. That bicycle advocacy group needs to establish legitimacy rapidly, deciding to be either a 501(c)3 or 501(c)4, getting business cards for leadership, and setting up a good, if basic, website.
They need to have a point person for each player in town government, residents and businesses that will be affected by road closure during rides. They must make the program sustainable, and be creative in identifying and reaching out to other groups whose interests align.

Again, they mention data gathering. They recommend partnering with university, and taking lots of photos. Keep a running list of previous events and activities.

Part of sustainability is funding. Look for grants and public-private partnerships.

Streets Alive and Open Spaces

Salisbury, Greensboro, and Winston-Salem describe their open streets events. They recommend that the events shouldn’t focus solely on cyclists, but if they can be tied in ensure there is a sufficiently large and long enough route.

Every Wheel has a Hub

Jeff Viscount, webmaster of, describes how his site has become a clearinghouse for North Carolina bike rides, the work involved, and the stats that bolster his case in setting advertising rates.

Chains and Trains, Pt. 2

This is the second post in a series on my experience of riding an Amtrak train to the North Carolina Bike Summit in Charlotte

Bikes, Policy, and Politics

The morning discussion featured Representative Chuck McGrady, Will Morgan, Representative Charles Jeter, and Harry Johnson, Jr. They gave a run-down of the sometimes convoluted processes in gaining political momentum for bicycle-friendly legislation. One of the panelists talked about the mysterious origins of Section 7(b) of HB44, which would strip municipalities of the ability to replace automobile vehicle lanes with bicycle lanes during a “road diet” construction project. They mention that sometimes lawmakers have an urban versus rural dynamic, and will block city street improvements that curb vehicular traffic because it is perceived as a slight to the people who must use their cars to get to downtown amenities.

The great takeaway to this panel was how to get a legislator’s ear. While it is suspect, you have to cultivate a personal relationship with the representative. Ask if they have a bike, or spouse has a bike, and would like a ride. Sending a thank you note when a legislator does well in defending cyclists’ rights can make a big difference.

One must always stay vigilant with a bill even if an upsetting section is struck. Sometimes the provision finds another way to get passed. The best quote: “the true test of influence isn’t being able to defeat a measure, but to get one passed.”

Safe, Sustainable, Social Rides

Boyd Safrit, Pamela Murray, and Mike Sule describe their experiences with organizing social rides in Charlotte and Asheville. They emphasize continuity above all else. Being able to keep a group of regulars allows the rides to maintain momentum even during the slower months. The regulars are useful to enforce protocols; Mike Suler enforces riding in complete compliance with the law: while traffic lights and stop signs break up groups, having a well-scouted route can provide regroup points, and regulars can shepherd the broken groups back into the ride. By building the goodwill with safe, legal riding, businesses buy in and can help sponsor things like brochures, maps, and web sites. They also emphasize “overcommunication”, using a listserv, Twitter feed, Facebook page, and smoke signals to get ride details to the group beforehand. Finally, keeping stats gives everyone an idea of what the ride entails: how many customers businesses along the route might expect, what sort of traffic burst a cycling convoy might cause, how much time a ride might take.

Keynote: Gil Penalosa

8-80 initiative emphasizes a city that accommodates mobility throughout the lifetime of its inhabitants. Penalosa laments that elders are a wasted resource: after 65 they often have another “career” worth of life expectancy, but the built environment exacerbates limited mobility and the sense of isolation that senior citizens experience. We learned how to survive, now we must learn how to live, and how do we WANT to live. Change is HARD, and CAVE (Citizens Against Virtually Everything) people are everywhere, but politicians are elected to do SOMETHING, not nothing. Improving mobility isn’t a technical issue: we know the techniques of boosting public transit, carving space from cars back to people, and increasing density. Instead, it’s a political one. Penalosa concludes with 5 Elements of change:

  1. A Sense of Urgency
  2. Political Will
  3. Doers
  4. Leadership
  5. Citizen Engagement

Small Towns, Big Impacts

This panel described the early, authentic outreach that Wake Forest and Marion engaged in their projects to increase cycling. They were able to pursue grants that some cities don’t consider, such as Congestion Management/Air Quality funding.  Public-private partnerships helped Wake Forest publish its BikeWalkRun map with color coding for cyclist proficiency

Chains and Trains, Pt. 1

This is part one of a series of posts I will be making as I attend the North Carolina Bike Summit in Charlotte, NC.

A News & Observer Road Worrier blog post discussed the vagaries of bicycle signage in North Carolina, namely “Share the Road” signs and sharrows. According to George Hess, a professor at North Carolina State University, “Share the road” signs are somewhat confusing to motorists and cyclists alike. Some even interpret them as putting the burden on cyclists to yield to cars. I was pleasantly surprised, then, to find this less ambiguous sign on the way to the station this morning.

I hope they use this sign design more in the future. I would prefer if they were a little larger, though.

Related works:
Hess, G. Peterson, N. (2015) “Bicycles May Use Full Lane” Signage Communicates U.S. Roadway Rules and Increases Perception of Safety.” PLOS ONE.

Getting Started with Drupal 8 REST

I am getting back into Drupal web design, since it is incorporating into its core codebase RESTful web services as well as responsive themes. That makes it a powerful, versatile CMS that can be adapted to apps and various form factors. I once populated a Drupal 7 web site with the Feeds Module, importing a CSV file into a custom Content Type. I then unlocked a lot of the information of those nodes using the RESTful Web Services module. There wasn’t a useful module to replicate this setup for Drupal 8, so here’s my workaround using the integrated REST capabilities.

  1. Installed Composer
  2. Continue reading

Extending the Life of an Acer Aspire One Netbook

My parents gave me an Acer Aspire One netbook over five years ago, and it was a nifty little machine for taking notes in graduate school before the ascendance of ubiquitous touchscreen tablets. I still use it as a quick terminal machine when I’m feeling masochistic, and here’s how I’ve extended the shelf life on some rather humble hardware.

  • Install Ubuntu

The netbook originally shipped with Windows XP, but there is that old joke that rings true, especially when I got the computer in 2009, “How do you get better performance out of Windows? Install Linux.” I used a Trusty Tahr iso on a USB drive to wipe out Windows and install Ubuntu.

  • Boot into text mode

More often than not, I was using the Linux terminal on the netbook. Instead of having to wait for the Unity desktop environment to load every time, I followed this guide to change around the grub.conf file and boot directly into text-only mode. If I need to use a web browser or e-mail client, I can fire up Unity with the command sudo service lightdm start . When I need to switch back to text mode, I can use Ctrl+Alt and a function key to switch between virtual consoles.

  • Make an alias to check on battery life

For my last step, I wanted to know how much battery life I had remaining, since terminals typically don’t have an indicator for that. I used the guidance from this AskUbuntu answer to make a quick battery command to tell me what I want to know.

First, I used upower -e to find out what my battery address was.

Looks like it’s that BAT1 line. upower -i gives the following results:

That doesn’t fit too well on an 8.9 inch screen. With a little grep filtration, we can get the most pertinent information.

Finally, I made an alias to make that long, piped command into the simple word “battery”.

I appended the command to the .bash_aliases file, then made sure the .bashrc file loaded up the alias. Not a bad way to keep an old computer running.

Book Report: Flirting With French

William Alexander’s memoir Flirting with French is a wry look at his efforts to become fluent in French at the age of fifty-seven. It starts with the discouraging discovery that he missed the window, the critical period, for speaking the language like a native by half a century. Nevertheless, an attendee of the Second Language Research Forum encourages Alexander to press on, as his maturity allows him a sense of self, to make mistakes without taking them as blows to his intellectual identity. Moreover, he has a syntactical scaffold he can leverage; I think The Story of French remarks English is the most French of the Germanic Languages.

Alexander excellently interlaces his anecdotes with research and trends among myriad topics relating to the French Language. He flits between French history and the history of the French language. He surveys research on the neurological processes involved in language acquisition and the biology of the brain, both in its development and the effects that second languages have on them. He investigates computer-aided language learning through software like Rosetta Stone and language learning social networks, as well as machine translation methods. He dabbles in linguistics, mnemonics, and home economics as well.

I enjoyed Flirting with French; it inspires me to try again at picking up the language.