Language Hacker | Robert Elwell's Blog

So I’ve been a little quiet on this blog lately. I’ve been busy devoting a lot of my free time to some interesting contracting opportunities.

I’m currently working with Time Doctor, LLC, a company working on the sites TimeDoctor.com and Staff.com, as a retained technical advisor. It’s a great opportunity to work on different software in my spare time and continue honing my craft. I get the opportunity to analyze code quality and application architecture, and solve some interesting problems on a useful stack of productivity and hiring tools. I’d see myself continuing on in this capacity for the foreseeable future, since I really enjoy doing it in my free time.

Here and there, I’ve also been providing some additional time to Earmilk.com, a really cool cutting-edge music blog that’s got some interesting new features on the up and up. Keep an eye out for those changes to come into effect real soon.

My big announcement is that I will be changing my full-time employment from Software Architect at AetherQuest Solutions to Senior Software Engineer at Wikia. I’m making this change for a lot of reasons. Working at a top-50 website is definitely up there. And I’m really excited to get into Big Data again now that the technology has progressed a bit. I’m excited to use my search knowledge again, too, after spending so much time on other sort of enterprise-level concerns in my current role.

I’ll be continuing strengthening my skills in application architecture, technical definition, and project management on the side as I work through some important issues with Global Workforce. This is important to me, because I don’t want to lose any of the momentum I’ve achieved over the last year and change.

I had a lot of great opportunities to learn and grow at AQS, and I’m really proud of what I accomplished there. But it’s about time I put the “language” back in “Language Hacker”!

A service-level agreement is a useful method for setting expectations on deliverability, and incentivizing quick turnaround. It’s also a great way to motivate a development team. SLAs encourage goal-setting and collective buy-in internally. They improve your users’ perception of your software and the people who maintain it. Best of all, they provide concrete, measurable criteria to evaluate the success of your team at a larger-scale level than issue-by-issue, or the regressions introduced in a given release. Whether your business model is software as a service or software as a product (free products included), you can easily use the fundamental components of an SLA to reap positive benefits. In this post, I will describe some guidelines for implementing an SLA in your team.

Continue reading »

I work in the Bay Area at a company based out of the Washington, DC area. I lead a development team with the manpower roughly divided between both offices. On top of that, we have certain stakeholders that work in other cities out of a home office. This isn’t unusual these days in tech. However, it puts a lot of strain on traditional methods of project management and release management. I’ve used it as an opportunity to implement some nifty methods that some might call agile to keep pushing our product forward in a rapid but guided manner. Continue reading »

When it comes to “The Real World”, one of my biggest learning experiences was getting fired from a temp job at a Verizon Wireless store the summer before grad school.

Continue reading »

Adding a change log to your database is the best way to make sure you’re working on a version of your web application that adequately reflects a given state of your product. However, when working with a branching-and-merging development environment, where two different developers may be working on a migration at the same time, we often encounter a race condition that can cause keeping development-level environments pristine compared to those that only deploy stable code. Here, I outline a methodology that allows both the flexibility of distributed development as well as sane migration management in an application with an evolving database schema.
Continue reading »

I recently spearheaded a campaign at my workplace to move from a problematic system of building releases using patching and SVN to the more modern, widely accepted Git approach. Things are moving along pretty well, and everyone is starting to get acclimated, but we found ourself with a little confusion with respect to code review.

Previously, reviews were done on the patches attached to issues in our bug tracking solution. Now people are a little confused as to where to go to do code review. The solution I created involves creating private posts in pastebin and providing the link as a comment in the issue. It’s basically a stop gap until we get something like Crucible+Fisheye for more intelligent code review.

I realized rather quickly on that I needed to make it as easy as possible to create diffs and share them from the command line, where I’m encouraging people to do all their work with respect to Git. I created the following command-line function:

In other words, pop this into your bash profile, or a separate script that you source during logon, and you have yourself a script that interacts with the Pastebin API and returns the URL of the new post. Here’s an example of how we plan on using it:

# after merging your ticket branch to the dev branch, "next"
# and any commits you need to make locally in case next has changed since branching
$ git diff origin/next next | pastebin

http://pastebin.com/y3sIDiDmAketh15UP

So you basically grab that URL and comment it in the ticket, and that snippet is available for review. You can use this function for anything, too. Just make sure to change up the format specification (or remove it all together), and remove the privacy specification if you intend to make it public.

At my job, I’m currently spearheading a move from an SVN patching model to a Git branching model. This should make it easier to do things like manage releases and streamline development. But we have a lot of finished work that’s been queued up for future monthly releases for some time. So I ran into the problem of expediting the move to Git with all of this extra stuff that still needs to get in, that was committed using a different paradigm.

So what’s an appropriate way to incorporate these SVN changes, currently sitting in queue in the form of patches, into a Git repository? Some might say a transitional period using git-svn. That’s not the direction I plan on taking, because I’m a big believer in creating expertise out of necessity. If someone feels like working on SVN still, they will, and then we’ll have disparities in knowledge once Git is fully adopted.

Let’s assume we’re working with a successful Git branching model.  Let’s also assume that your SVN code has gone through a release process and been appropriately tagged. In this case, my Git codebase in master is identical to a previous SVN release. It doesn’t have to be, since we’ll be merging branches. Here are the steps I’ve developed to incorporate new changes from a minor SVN release to the up-and-coming Git model.

1. Branch from master. Usually, when you’re working on new code, you’ll want to branch from your development branch, but in this case you’re taking code that’s ostensibly been prepped for release and process-vetted within SVN.
2. Export your SVN tag to your Git branch. Use the –force option when exporting so SVN won’t complain that there are already files in the folder you’re exporting to.
3. Review your changes. It’s always a good idea to see what got added and what got modified. Does it look like your new release?
4. Push this branch forward as a release candidate. You’ve already tested this, right? Well, test again real quick, just to be safe.
5. Merge the branch into master, increment the tag, and push to origin.
6. Merge master into next. This ensures your changes are added to the development branch. People working on branches have the option to rebase them onto the latest HEAD of next or to just merge their changes in later. I’d suggest they merge with the –no-commit option so they can review their changes.

Using this workflow, you can sneak in a few more SVN releases before finally dumping it like a sack of moldy potatoes. Note that you’ll only really have one informative commit for all of the changes that you made to increment your tag. If you’re running a patching model, there’s still a chance of this in SVN if your release is prepared all at once. Because of that, I view the loss in revision history as unfortunate, but acceptable. Ultimately, moving to Git improves your ability to read the logs without all the patching cruft and really get a feel for the changes that took place from commit to commit.

MAMP is a popular platform for web development on a Mac. As you’re doing web development, working on a Mac generally also results in needing either a Windows machine or a VMWare instance of Windows on your Mac. In my work development environment, we work with VMWare Fusion.

Recently, I noticed that a number of developers seemed to be committing code and pushing it to the QA server just to test it on Internet Explorer. I realized it was because they were having trouble getting their virtual machine to talk with MAMP right. I’m all about making a lot of small commits with very detailed messages. What I’m not about is committing code that is entirely experimental as a workaround for a problematic development environment. I knew I had to research this issue and come to a conclusion everyone could live with.

I should preface the description of my solution by noting that we’re missing an internal DNS solution. That’s actually something I kind of miss from my last job. From any computer on the company network, you could send access languagehacker.local, for instance, and be able to see my development machine. If we had internal DNS, the steps I’m describing wouldn’t even be necessary. So for lack of it, here we are.

Here’s the solution that I put together so that developers using our setup can access their local source code through their virtual machines without going through an internal DNS. Continue reading »

Variable variables are a nice, flexible tool for when you’re transforming data types (say, arrays to classes). At the very worst case, they’re good for using some kind of string data that has come down the pipe to serve as scalar variables for future use. I’d like to rail against the abuse of strings by many developers in PHP web development, but that’s probably best saved for another blog post. I’ve been seeing variable variables get brought up a lot on the usual sources lately. Yes, they’re cool, but there’s always the usual ‘hammer and nail’ argument about PHP. You can give a developer a powerful tool, but it doesn’t mean they won’t get ahead of themselves in using (or abusing) it. Here is something you must never, never, never EVER do:

    for ($i = 1; $i < count($anArrayOfThings); $i++)
    {
        ${'thing'.$i} = 'some value';
    }

There is absolutely no reason to do this. Unfortunately, I have seen it in real, life, actually-used-to-make-money code. It’s a mistake someone in their first year of PHP development should make, only to get swiftly corrected by a more senior developer. As I’m getting older, I suppose it’s weird to be that guy.

Anyhow, there’s a really simple way to both create an access related items iteratively, and you’re probably already using it to build out junk variables like this. Obviously, it’s an array:

    $myArr = array();
    foreach ($anArrayOfThings as $thing)
    {
        $myArr[] = "that same value";
    }

I had a great professor in grad school who had a great saying: “Do the dumb thing first.” When applied to machine learning, it meant use the most naive model you possibly could and see how far that got you with data predictions. Sometimes killing yourself over using some cutting-edge model only squeezes a half percentage more accuracy to your solution. In other words, be pragmatic, and use well-tested tools that get you most of the way there to your solution, and then fit your solution around those tools. Don’t waste your time with variable variables unless you really, really, really need them. And you probably don’t. Are you trying to write a quine, or an interactive command prompt for PHP? Well, you probably don’t even need them then.

Variable variables can be pretty nifty, but they shouldn’t be your first solution. And if you think they’re the only solution, then you need to step back for a few minutes and determine whether or not the choices you have made to get you to this chunk of code were the correct ones.

I took a few minutes today to change up the way the site looks. I thought the original design felt a little heavy. It didn’t seem to be the palette, but rather how it was employed. The fonts were a bit too big, and the background, while part of the palette and doing an okay job putting a focus on the content, was a bit too dark. I relieved these issues with a minimum of design changes by reducing the font size, moving the content to the right, and making lots of room for a background that employs a natural element with an architectural element.

The image that I used is the same as the one on my Twitter page. It’s the Grafton Peace Pagoda, a shrine to nuclear non-proliferation in the mountains of Rensselaer County, New York. There’s also a Peace Pagoda in San Francisco, so it sort of reflects where I come from and where I’m going.

In some ways, this change also reflects my recent travels to Spain, where I spent a lot of time marveling at Gaudi’s Barcelona. While in no way related to any of Gaudi’s work, the Grafton Peace Pagoda has a similar integration with nature. Like Las Pedreras, or multiple components of Parc Guell, it interacts with the sky by using light-colored materials with lots of upward direction.

The blog portion is excluded from major design changes, as I have a high emphasis here on readability and blog-related actionability. It also gives me an opportunity to play with two designs at once.

In other news, my first two weeks in Burlingame have been fairly crazy. Between getting situated in a new city (let alone a new state!), diving right into developing new processes to streamline existing workflows, and going onsite to the McAfee Focus10 conference in Las Vegas, I’ve got my hands pretty full.

In the last month, I spent ten days in Spain (get the rabbit dinner at Meson Gregorio III and tell Javier I say hola!), drove across the country in three days (pulling a U-Haul trailer and downshifting up and downhill like a big rig trucker), and flew to Vegas to support our system at work. I’ll be looking forward to relaxing a bit and exploring the Bay Area once everything settles down.

Given all the stress, fiddling with this site design has been a little therapeutic, so I hope you enjoy how it looks!