tara_hanoi | Entries tagged with programming

So, this has been a mild rant in my head, and I feel like I need to articulate it somewhat.

Recently, I was out drinking with some developers, and I got talking about some pattern that some framework uses that another developer considered harmful¹. To be honest, I didn't have a strong opinion on it, I just liked to use it on occasion when I was working with that framework a few years ago. However, the other developers argument against it is what I'll call an Appeal To Personality.

In this particular case, it went something like this, "I worked with the smartest programming guy ever, and he was really anal, and really obsessive, but he produced great quality code, and he said not to do X", with the implicit followup that I'm not going to claim I'm better than this guy I've not met, or otherwise challenge the authority of this Personality.

Similarly, when having a discussion about Agile, one of the developer said to another (who claimed Agile didn't work), "This was put together by some Very Smart People, and they found it worked. Who are you to argue with them?"

I have 3 words for this style of argument: Bull fucking shit.

My own personal take on this is simply that programming isn't a religion, there aren't the gods from on high, there aren't high priestess, priests or Great Rites that confer upon us the wisdom of the gods, and these great Personality Deities. Maybe it's just my own mental blocks, but I need a Reason^tm to accept this. I need to understand why something is a bad idea.

Here's a list of things I know to be a bad idea:

Programming in really complicated Regular Expressions - I've done this before. I've had to debug some very complicated Regular Exression. As time went on, I spent less time fixing the broken big regex, and either reducing them to small ones in multiple phases, or just taking out the need for them altogether, because that was easier for me to debug

Similarly in python, I try not to use nested loop comprehensions. Yes, you can look smart and cool, but I don't do them. I can, but I won't because I've learned from regexes that just because you can do something is not a reason for doing it.

Operator overloading is cool, but unless the semantics fit what you're trying to do, you're just going to confuse yourself when you go back to it later

Don't write a one-liner just for the sake of writing a one-liner if you expect to rely on that code. If it fits more naturally in multiple lines, do that instead.²

It's not a whole load of stuff, really. They're just mistakes I made for myself, and that I've learned from. I learned a lot from mistakes I made. In fact, I'm pretty sure I've learned the most from mistakes I've made for myself.

Maybe it's a mental block that I can't accept wisdom from others without the memory of pain to back it up, or it's that I can't accept a good practice without a similarly good reason, but an appeal to personality is just not a good enough reason for me.

That said, there are Personalities that I will listen to. I have a few colleagues like that. One even gave a presentation on refactoring. He worked through an example from a book he was very fond of. So, you might be asking, how does this differ from the "Appeal to Personality" that I've just been wittering on about?

Well, in this guy's case, he didn't just rework an example application, following what was in the book, but he took the time to explain what he was doing. Moreover, he wasn't just explaining what was in the book, he was explaining his interpretation of what he'd learned in the book. He'd learned something, distilled it, and shared this knowledge with us. His personality lent a lot to the process, but he wasn't the reason. He didn't say, "I'm pulling out the code and putting it here Because I Say So", or saying, "Whenever you see this, this is a Code Smell and it must be moved", but took the time to explain why he was doing it. These reasons mean a lot.

I'd much rather hear someone who has lived through some pain share tales and stories of their pain, and reasons why they do what they do. I'd much rather have a good reason to do something, and because I'm told to by a Personality is not it. I don't care if Denis Ritchie said it, Linus Torvalds, or some super-smart guy in the back-ass of nowhere said it. I want good reasons, not the celebrity.

( Herein lie the footnotes )

Sorry for the delay in posting, there's been a post I've been trying to articulate for months, and every time I feel ready to finish it, another related event crops up, and changes (but reinforces) the point I want to make. So, I've stashed it for now to share something shiny I made.

You see, I've recently switched jobs, and I'm now working as a developer. I have to say, the benefits that switching jobs has had on my general well-being cannot be understated (sadly, I will be understating them in this post as that's possibly for another post).

However, professionally speaking my new role meant switching from my familiar use of mercurial to git. I was a bit wary at first, mostly because most blogs about git usage have a strange obsession about exposing the plumbing of the system, giving the impression that you need to understand the internals in order to simply use it, but I have to say I'm liking it now that I'm using it. That said, I've always been dabbling with git over a long period, but because I had done paid, productive work with mercurial, that got priority over my own git-dabbling. Now, part of my job is to learn how to use git productively, so I've taken some of my start-up time to go on a deep-dive into the system, and its supporting ecosystem, in order to customize my setup to ~~a point beyond all recognition~~ my needs.

If you google around about git and bash, you'll inevitably stumble on sites with completion recipes, prompt hacks, and other fun aliases to give you more information and insight into what you're doing and where. I have to admit, I felt a bit left out. I had to blog about something to do with git and bash.

Now, here's the thing. In my new workplace, we've got about 20 different git repos. There's apparently A Very Good Reason(tm) for this, but what it means is that when I'm flitting through the sources, I'm dealing with a forest of separate source trees, each with a roughly identical directory structure, and I'm prone to wanting to 'cd' up to the root, then switch to the next one. Now, it's quite possible that my Google-foo failed me, but I couldn't easily find something allowed me to realias 'cd' so that it that got me to the top-level directory of the repository when I just typed "cd" on its own; I'd just end up back in my home directory. So, after having a peek at the bash auto-completion code that's shipped with most git packages, I decided to make my own.

I shouldn't be as proud of this moment as I actually am. Seriously, I should not. It took some googling, and trawling StackOverflow for some of the interesting tricks I used, but overall, I had this done in about an hour or so.

After mentioning it on facebook, and how disgustingly proud I was of making this monstrosity, I was encouraged to join the trendy github hoardes and share it. So I did. I know, I'm now one of those trendy hipster GitHub folk, and I'm still disgustingly proud of this. It's like a kid running up to their parents holding a potty with a perfectly formed poo inside saying, "Look mommy, I didn't miss this time!".

With that adorable image aside, it was mentioned that if I'm blogging about this I might as well explain some of the tricks in there, so that's going under a cut. But first, a few notes:

You'll want to source this file after you source your bash-completion script for git, otherwise this won't work (this is kinda by design, more on that in the fine details).
While I've done my best to test this, there may be corner cases.

The idea is to get to the top-level directory of your git repo with a blank "cd" call. If you type it again, "cd" should behave normally.

( Now for the finer details )

And that's my tour of the code¹² done. I hope someone finds it (and the actual function) vaguely useful, and I really hope that the blog was at least fun to read, if not that informative. I welcome any comments, questions or issues on either the blog or on github (although if you mention an issue, please put the name of the function's filename in the title).

( Herein lie the Footnotes )

Current Mood: bouncy

In case you haven't figured out from half of my posts, I'm one of the many people involved in the software industry. While most of my job is Quality Assurance, there's a relatively significant development portion as well; such as developing internal tools. Some of these tools are web-based, and some of them aren't.

Over time, I've developed a bunch of habits and tools that are probably so inutterably obvious to the professionals that they don't bear mentioning. That said, there's always a wealth of information for beginners and pros, but very little for those stuck somewhere between. Sometimes academia will teach you grand plan for how something works, but will ignore the basic techniques for writing anything more complicated than "Hello World". I'd like to make a humble effort to bridge that gap (although I think I'm still crossing that gap myself) by sharing techniques that I frequently fall back on in the course of my job.

I really don't know how I want to format this, so I'll go with a rambling list.

Learn your method for isolating and identifying failures - As a QA engineer, I need to know this one to do my job. As a result, I've picked up too many techniques to enumerate, but basically it boils down to building a theory of what went wrong, testing that theory, and then taking steps to fix the problem. Many people will sell many techniques (either for money or for mindshare), but you should take none of them as gospel. As time goes, you'll build your own technique, and you'll pick up tips from others. But the basics remain the same: Identify the deviation in behaviour; formulate theories on what caused that deviation; test those theories (preferably in a safe environment); fix the problem.

As a side-note: it also helps to document your progress through your diagnosis in case you encounter a similar problem again. Most professionals do that in a bug report or in some other tool they've employed for the job. Trust me, that saves a lot of heart-ache.

Outlines in comments are a good thing - this is how I'm fleshing out my list, and how I did most of my essays in college (and my blogs; if you look carefully you can see the seams dividing something I wrote at different points of the day, or even entirely different days). Yet it came as a surprise to some co-workers, once upon a time.

Figure out the basic steps you want to perform. Write them out in comments. Fill in the code to complete those steps between the comments. If you want, delete the comments later, although I always think that's a bit of a bad idea. But, reading a lot of code blogs, I'm pretty sure people wouldn't like how I comment. That said, these comments are just to remind you what the basic steps of your program are - this allows you to walk away from your program for a while, return to it, and figure out what the hell you were in the middle of doing.

Investigate and learn how to use some tools of your trade - Depending on your development domain, there can be a lot of tools available to you, or not very many. No matter, you should take some time to get the lay of the land. One very useful tip, when you find yourself developing in a new domain is to browse around various forums and discussion groups to see what names crop up frequently; chances are you'll do well to become familiar with them before you're forced to do so.

For instance, I had to maintain an internal webtool that relied very heavily on javascript. Mozilla's "view source" only showed the page that it had downloaded, not what it went on to render. For that, I found firebug to be indispensable; it would have taken me a lot more time to understand what was going wrong if I didn't have a tool like that at my disposal.

I still don't use, or know how to use, a good 90% of its features. That doesn't matter, because the 10% I did use did the job I needed.

Maintain a 'trinkets' directory - This is a little habit of mine, and I don't know if anyone else does this. I find this works better for scripts than it does for compiled languages, but both are perfectly acceptable; I just find compiled languages require a little more work (so I normally keep a template handy). Trinkets are exactly what they say on the tin. They are small playthings that you use to prove a concept to yourself in some way. In work, I currently have 3 trinkets directories for 3 different languages: c, ksh and perl. I've tidied up a handful of these and I'm putting them up for people to see - Hosted on BitBucket.

Trinkets are useful because they allow you to test something outside of production code. They normally focus on exactly one topic, and just have a bit of other trivial code to show the output of what you're doing.

At this point, I feel I must stress something: TRINKETS ARE NOT UNIT TESTS.

A unit test is testing the functionality of your product, and should be automatable. A trinket is meant to solidify your working knowledge of something. Chances are you'll throw it away after you're done. A unit test should know whether it passed or failed. A trinket is meant to expose some functionality so you can eyeball how it works. A unit test tells you if you've broken something. A trinket tells you if you understand a concept or not. You're meant to play with it, and make it work. It's not any indicator of the quality of your project, it's simply a way for you to solidify something you weren't sure about. Trinkets are a learning tool, not production code.

These are practices that I use when coding. I'm pretty sure the programming community at large will sneer at some of them (namely comment outlines and trinkets), but I think these are really useful, especially for beginners.

One of my fascinations, although not enough to warrant giving myself any sort of title, is the history of computer folk in the days when unix and the internet were purely academic subjects. A lot of interesting culture and cultural terms emerged from that time, and seem to be relatively consistent. There again, the consistency probably stems from the fact that the authoritative tome for these terms is the FOLDOC (Free On-Line Dictionary Of Computing).

Some of its more famous articles are still common terms in industry today, such as Cargo Cult Programming. One of my favourites is the Magic Switch Story (although it's rather less famous, or at least not used commonly).

What really captures my imagination is that these terms are relics from what is the closest thing to an oral tradition as we're going to get. A lesson abbreviated into the title of a story or lesson. You hear terms like "Deep Magic" and you can guess at what they mean, even before you read the definition. Sometimes when I take a step back and look at what programmers are actually saying to each other, I can only think of "Darmok and Jalad at Tanagra". (By-the-by, the fact that I'm linkspamming with various pieces of hacker folklore, and the plot summary of a Star Trek episode is not lost on me)

Sometimes I'd get a little lost feeling about not having the same common depth of folklore nowadays, but hanging around the likes of reddit, I realise that there's as much of a common language now as there was before, but it's shifted. I can talk about doing a Bobby Tables and expect that folk understand it. If I say someone's a real BOFH, you might get an idea as to what to expect.

There are also traditions that are spreading as memes. For instance, the editing of production code, live on the server, now requires the perpetrator to wear a Pink Sombrero... and the thought of the pink sombrero brings me onto one of my own traditions.

Just over half-my-life ago, I was at the right age to appreciate the cartoon Earthworm Jim when it came out. I loved the graphical beauty of the game, even though I wasn't very good at it, and its attitude. To my mind, the cartoon managed to faithfully recreate and enhance aspects of game, and it was just enjoyable.

There's one scene from that cartoon that's stuck in my mind from then until now: Jim is, once again, captured by the bad guy of the episode, a particularly televangelist-sounding fish, who wants Jim's suit and, as a bonus, wants a nice worm-roast for dinner (what with Jim being a worm and all). The henchman tasked with making said wormroast decides to watch a cookery programme and learn how to make pot-roast. The henchman, not being the gifted in his class, says something to the effect of, "I know, when he says 'pot', I say worm."

The conversation follows something like this:
Chef: We're gonna make a pot-roast tonight.
Henchman: Worm Roast!
Chef: To make a pot-roast-
Henchman: Worm Roast!
Chef: you get a nice shiny metal pot and stick it in the oven.
Henchman: Get a shiny metal worm.
*casts eye around, and settles on a generic cartoon missile and shoves it in the oven*
*Hilarity ensues and our protagonist makes his escape*

So, how does this have anything to do with hacker culture, folklore, sayings and traditions?

Well, I sometimes have to heavily modify existing scripts. For better or for worse, I frequently find myself renaming and retasking one major component to make room for another. That's mostly fine but, from hard experience, I'm always conscious that I'm probably missing some of the subtleties that stop me from directly renaming one thing to another. Chances are I've got 90% of the problem in my head, it's just that last 10% is going to hurt me if I stumble blindly just swapping bits around.

It's just like saying 'worm' whenever they say 'pot' without understanding that the two are not completely substitutable.

Just to remind myself, when I do that sort of work, I chirp out in my dumbest little voice, "WORMROAST!"; it's fun trying to explain that one to co-workers who already think you're half-mad. Now that I've explained it to them, I'm more prone to chirping "WORMROAST" in the office.

I know that my call of "WORMROAST" isn't going to catch on any time soon, but it's a story that keeps me amused while I go and break things in the name of progress.

I know places like Stack Overflow like to enumerate all the new little terms that have turned up, but I'd love to hear any personal little terms you use, either in the comments here or by twitter.