Language Hacker | Robert Elwell's Blog

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!

Quality assurance is a pain for everybody. There are countless ways a bug can avail itself, and sometimes they’re not easy to find. There are a couple of reasons why it’s generally a good idea to let someone with a fresh pair of eyes do some amount of bug reporting.  In this post, I’ll be discussing the value of QA, and how to make sure you’re doing it in a productive manner. I’ll also discuss a few possibly all-too-familiar QA stereotypes you will want to avoid falling into. Continue reading »

Hey everybody! I just got back from a ten-day vacation in Spain. I can finally tell you all that I’m moving to the Bay Area in the next couple of weeks to take up a position as PHP Software Architect at AetherQuest Solutions. As sad as I’ll be to leave Austin, easily the most enriching place I’ve lived in yet, I’m very excited for this opportunity. San Francisco and its surrounding cities is about the only area in the states that is technologically a step up — if you’re interested in being around cutting-edge technology, that is. I’ll make sure to let you all know how the move goes!

That’s right, I am officially a Certified MySQL Associate. Of course, I can’t disclose anything about the test now that I’ve taken it.  I will say that the certification book’s study material is pretty ample; so long as you’re working with MySQL on a regular basis, it shouldn’t be too hard to get a passing grade.

I take my Sun Certified MySQL Associate certification exam tomorrow. I work with MySQL most days, and I wonder if I actually should have started with the DEV-I exam instead. Either way, it’s good practice for the harder, more expensive exams, they say, and it’ll be a nice benchmark, or notch to have in my belt, or what have you.

I made this post mostly because I had an extremely hard time finding useful resources while preparing for the CMA. The folks at Sun/Oracle claim all you need is their MySQL 5.0 Study Guide book. The book is nice — a very thorough, must-have resource — but doesn’t even mention the CMA. Instead, you have to cherry pick chapters out of each exam. Sometimes you only have to do tiny sections out of chapters, and oftentimes, they even exclude portions of those subsections. Before I could even start studying, I basically had to take each section listed and mark it with sticky notes telling me exactly what subsections I had to read, or which ones to skip.

The kind of support — or truthfully, the lack of support — that Sun/Oracle provides for this exam really bothers me. Not only are there no mock exam questions to be found anywhere, but you don’t even get a section of your own to really focus on what you need to know. Searching for support online was a mess. The appropriate search terms have been absolutely hijacked by dishonest spammers more interested in turning a quick buck than explaining anything about the test. The MySQL forums seem to be locked down by administrators out to sell books and classes. The problem is that there isn’t a good bookfor the CMA, and the cost of the class is too much for someone who already knows MySQL.

This kind of ‘flying blind’ stuff is the exact opposite of what an entry-level certification should be all about. I disagree that you need an entire class to learn this kind of stuff, especially if you’ve had any amount of practice working with databases. Paying a grand just to have a basic idea of what you’re going to be tested on — let alone access to appropriate study materials — isn’t very fair. I ended up going through each section that I was supposed to master, taking a lot of notes along the way.  I find that taking notes is a great way to learn a subject matter. I felt that I could use a little bit more studying, so I typed up those notes.

I’m providing my MySQL CMA Study Guide here on my website as a courtesy to all of my fellow aspiring Certified MySQL Associates. Again, they’re just my handwritten notes typed up and put into PDF form. I’m not making any guarantee that memorizing these notes will get you to pass the CMA exam, because I haven’t even taken it myself yet. They’re intended to give you an idea of the material you need to be familiar with for the exam without having to take a class on stuff you may already know or buying the MySQL certification guide and referring to a byzantine list of book chapters. What you won’t find is mock exam questions or, hopefully, anything directly plagiarized from the book, as the goal of taking helpful notes is to paraphrase important concepts.

Welcome to the new blog feature on RobertElwell.info, which is my personal homepage moved from the UT Computational Linguistics group’s web hosting to its own domain and host. The main site has had a bit of a redesign, but you should notice that the blog is its very own thing. I’ve tried to keep the top navigation in the same exact spot, so ideally you’re still habituated to where the important links are from styling to styling.

I’ve implemented this new site in WordPress, creating my own theme along the way. I’ll just say that working with WordPress is a tremendous step back from working in the Zend Framework. I understand that it’s intended for people who want to hit the ground running, people who want to focus more on style and easy administrative UI than, say, clarity of code or extensibility to newer versions of PHP. I just worry that if the community doesn’t get its act together and drop PHP4 support entirely, they’re going to drown in their own spaghetti code. That being said, you’re reading a WordPress implementation done in less than ten hours of coding time (most of it being styling and migration), so it’s really not that terrible, unless you want to make any significant changes within the API.

Now that I’m hosting my own blog, I’ll have a reason to write a bit more. I’ve got a lot of big, exciting things coming up in my life, but after all those get squared away, I have a considerable mental list of things I’ll be riffing about. Stay tuned!