Remy Porter

Remy is a veteran developer who now operates his own consultancy. As the President of JetpackShark, he leads technology workshops across the North East, training developers to adopt new technologies and find their own best practices.

He's often on stage, doing improv comedy, but insists that he isn't doing comedy- it's deadly serious. You're laughing at him, not with him. That, by the way, is usually true- you're laughing at him, not with him.

Give Thanks for Well Routed Packets

by in Editor's Soapbox on

It’s Thanksgiving here in the US, so we’re taking a long weekend. In lieu of a more traditional “from the archives” post, I’m going to give thanks.

You know what I’m thankful for? I’m thankful that data packets on the Internet are routed and handled the same way, regardless of which network originated them, nor which network is their destination, nor what they may contain. You could say that networks are… neutral about packets.


by in CodeSOD on

There are some submissions that we get, and we simply sit on, because there’s nothing much to say about them. They’re awful code, but there’s no major comments to be added. It’s clear and simple in its awfulness.

For example, you have some code that needs to display details about colleges around the US. Each College has a name, a full name, a short name, a state and city where it exists, and full names for those states and cities. You are likely reaching for an object to store that information, but why do that, when you can employ what I call the “Arrject Pattern”. Y’know, when instead of using objects, you use multiple arrays and store related data at the same index? Stuff like what Kevin found in his codebase:

The Generated JavaScript

by in CodeSOD on

Once upon a time, I discovered a bug in some JavaScript. I went off to investigate the source, only to find… the JS wasn’t coming from a file. It was being generated by a server-side method. Through string concatenation. It was a simple generation, something along the lines of:

jsCode += "location.href = 'foo?id=" + someIdField + "';\n";


by in CodeSOD on

When faced with an API or programming paradigm that requires repetitive, boilerplate code, a developer is left with two options. They may refine or adapt the API/paradigm, using the idioms of their language to make something tedious and verbose into something elegant and clear.

Or they just automate it. If you have a mile of boilerplate that’s mostly the same across the application, just generate that. It’s like copy/paste, but, y’know… automatic.

One's Company

by in CodeSOD on

The more you learn about something, the less confident you often become in making statements about it, because you understand the complexities of the matter. If, for example, I asked you to help me refine my definition of how dates and times work, you know that many assumptions are wrong. Or if we tried to define what makes a string a person’s name, we’ll run into similar problems. This is even true for a value we’ve all probably seen implemented as a boolean value: gender. The more you learn about these subjects, the more complex and nuanced your understanding of them becomes. More and more, your answers start with, “It’s complicated…”.

Eugene was going through some code at a customer’s site, and he found that their business logic depended heavily on a flag ISCOMAPNY (sic), but there was no ISCOMPANY field anywhere in the database. There was, however, a SEX field on the customer records, implemented as an integer.

An Exceptional Contract

by in Representative Line on

The life of a contractor can be precarious. Contracts end- sometimes suddenly, and you rarely know what the organization you’re working for is actually like until it’s too late.

Ian S, for example, was contracting for a platform-as-a-service (PAAS) company, adding new features to their existing infrastructure automation system. It was the kind of place that had two copies of the same code-base, maintained side-by-side, just so that a single customer could use a script they’d written eight years prior.

Lowest-Bidder Conversion

by in CodeSOD on

Circa 2003, or so, Annie’s employer contracted a lowest-bidder to produce a relatively massive .NET Web Forms project. The code was built, signed off, and chucked into production without any of the in-house developers being involved, despite being the team that would support it in the long term. There was no documentation, no knowledge transfer, and no code review.

Over the next few years, there was a rush of feature requests as gaps in functionality were found. A series of in-house developers passed through, doing their best to patch them in, but the original project’s code quality didn’t exactly make it maintainable, and since they were operating in a rush, they weren’t exactly improving the code quality.

The Distract Factory Pattern

by in CodeSOD on

The Gang-of-Four design patterns have an entire category of creational patterns, to handle the complexities of creating objects. And yes, it can get complicated, especially when we think in terms of the single-responsibility principle. Often, creating an instance of an class is itself so complex that we need a new class to do it.

Thus, we have the Factory pattern. And the Abstract Factory Pattern. And the Abstract Factory Factory Abstract Provider Bean pattern, if you’re using Spring. The purpose of these patterns is to add indirection between the client, calling code, and the creation of the objects- different concrete implementations can be instantiated, without the client code needing to worry about what actual type it received. Polymorphism wins the day. Code is more loosely coupled, because the client code never needs to name the concrete type it uses.