Author: Beau

Categories
Programming Software

Source Control

If a piece of software claims to be able to manage my source code, I want it to manage all of my source code. Let me describe a tool that I use daily for my job whose purpose is to manage source code.

The Tool

This tool is quite simple to use. It’s been around for a while now. It has a straight forward interface and a very easy model of use to understand. I checkout code. I update code. I change code. I update code. I commit code. Pretty dead easy. Maybe a conflict happens but not really usually a big deal.

Collaborating

Sometimes I need to share some of these changes with a collaborator so I use The Tool to make a patch file. I then email/upload/transfer it in some way to my collaborator who — if her code is in the same working state and she knows how to use a tool to apply my patch file to her working copy — she can then apply the changes that are represented in my patch file. Meanwhile, if I make any changes to my working copy my patch may no longer even apply to my own working copy. At this point it could be useful to note what revision my working copy was at when I made the patch, you know, just for sanity’s sake.

Let me reiterate what just happened there. If I want to share some changes that I have made to my source code, I have to use tools other than The Tool (the one responsible for source control). Does that strike anyone else as a little odd? I need to use a tool other than my source control tool to manage my source code.

The patch file that I make has no context attached to it. It knows not which repository it came from nor the state of the repository when it was created. Very quickly the repository is going to change because there are fifty (maybe even more people) committing to this repository all the time.

Experimenting

Sometimes I get an idea — or even less — an inkling of an idea. I want to test it out in my own little sandbox and experiment with it and see if it can go anywhere. This idea consists mostly of new files but it also requires me to modify some existing ones. Time has passed and the idea is somewhat working but I need to get to something else more pressing. Ok, so what do I do with this experiment? I certainly don’t want to lose it because even though it’s not fully baked, there is some value in it.

Guess what? You’re screwed. You can create a patch and save it, but inevitably the files you modified will be changed. Maybe you make a branch1, but no, branches are for important things not your little experiments. Imagine how messy the branches folder would be if everyone used it to dump their little experiments.

Identifying the Problem

I started explaining my woes to one of my coworkers. I try my best to be diplomatic because I am not one to get involved with flame wars. The problem was identified and alas the problem is not The Tool. Apparently it’s my workflow. So perhaps I’m The Tool.

Did I mention how I love Git?

  1. Yes, the “b” word. Please excuse my language.↩
Categories
Programming

Explore the WordPress.com REST API

WordPress.com has unveiled a new REST API and I wrote a tool to help debug and explore it.

In fact, the documentation for the REST API is built by the API itself! With this information we were able to build a console to help debug and explore the various resources that are now available through the new API. So let me introduce you to the new REST console for WordPress.com.

Categories
Programming

I write code

I have never labeled myself a programmer. As one who has learned the craft via the omnipotent Google search box and the sharing of open source codes, I have always felt that I have yet to venture through the initiation rite that I am told consists of reading The Dragon Book and K&R, and building a compiler. Or maybe it’s because I prefer the dynamic, loosely-typed, “toy”, scripting languages to the ones real programmers use.

Regardless of how I am identified I do have a ferocious appetite to learn new things, try new tools, and challenge anything that becomes a little too precious. So in order to prevent myself from stagnating I have intentionally not self-identified what it is I do for a living other than “write code”. I write a fair amount of PHP but I am not a PHP Developer1. I have recently spent most of my time writing Javascript in the DOM but I do not identify as a Javascript Developer2. I spent a solid 2-3 years writing Ruby for eight hours a day learning how to “meta-program” as well as craft a gem and do “test driven development” but I would not consider myself a Ruby Developer3.

All of these different languages brought with them different ways of doing things and, more importantly, different people and cultures for me to learn from.

To put it as plainly as possible: I enjoy solving problems using computers. My solutions tend to involve a web browser and a web server. When this no longer interests me or — more depressingly — I can no longer maintain the skills necessary to make a living doing it, I will stop.

Until then I write code.

  1. Sometimes I want to kick PHP right between the “H” ↩
  2. Sorry, I mean “Javascript Ninja” ↩
  3. Sorry, I mean “Ruby Rockstar” ↩