Remy Porter

Computers were a mistake, which is why I'm trying to shoot them into space. Editor-in-Chief for TDWTF.

Aug 2017

Attention to Detail

by in Feature Articles on

The exotic and exciting life of the world-traveling contractor wasn’t exactly what Angie had been expecting. It mostly meant living in a dreary apartment on the outskirts of some city in a short drive from an industrial park where she’d go to try and keep 30-year old C code and their new ERP from fighting to the death. Six months later, she’d be off to the same apartment near the same industrial park in a different country.

When the crash came, it came hard. Hard enough that Angie ditched IT and got a temp job working in a customer service call-center for a greeting card company. She wasn’t exactly the best person on the phone, and nobody was giving her stellar marks for her cheerful demeanor during her quarterly review.

A vintage 'get well' card from 1949, with the text, 'How's the convalescent?/Down but not out'

Take a Byte of a Nibble

by in CodeSOD on

Imagine, if you will, that you have 64-bits of data. From this 64-bits of data, you need to extract a nibble, which contains the value that you care about. Now, I’m sure you’re imagining an integer with some bitmasks to extract the data, which is a perfectly sane approach.

Tomasz inherited some code from his company’s German office. It took the approach of taking the 64-bits and storing the 64-bits in an eight element byte array. Then, it extracted the values from that array with code looking like this:


Changing With the Times

by in Representative Line on

Melody got tapped to do a code review on a pull-request from a veteran team-member. It was… an interesting PR, in that very, very little changed. The code was terrible before anyone touched it- for example, the C-file started with 355 lines of variable declarations inside of the main method.

It was, in fact, down around line 354 where Melody noticed the change.


The Security Audit

by in Feature Articles on

We do our best to anonymize submissions, but there’s always a chance that some dangerously identifying detail slips through. Every once in a while, a submitter contacts us to ask for a modification. More rarely, a submitter’s employer contacts us.

Our rule is to make edits more or less as requested, then move on without comment. There’s nothing about an article so sacrosanct that it’s worth going to war over.


The Story of Things

by in CodeSOD on

Every line of code tells a story. It never just… appears. Someone made and crafted that code. There’s a story, and an explanation for how that code could be. The world, even the bad, awful corners of it, makes sense and can be understood.

For example, Luke sends us this block.


An Emailed Condition

by in CodeSOD on

For a change of pace, the code in this CodeSOD isn’t the real WTF. Our Anonymous submitter works for a company that handles meeting scheduling for corporate customers. This entails shipping off loads of HTML-emails, and that means using a relatively terrible WYSIWYG editor that generates code like this:

<p class="MsoNormal"><strong style="color: #003877;">Meals</strong></p>
<p class="MsoNoSpacing">
<span style="font-size:9.0pt;font-family:" verdana",sans-serif;="" mso-fareast-language:en-gb"="">
All breakfasts and lunches will be served in Food Capital on the ground floor of the hotel.
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;
</span></p>
<p class="MsoNoSpacing"><span style="font-size:9.0pt;font-family:" verdana",sans-serif;="" mso-fareast-language:en-gb"="">
We look forward to hosting you for the following dinners:
<o:p></o:p></span></p>

Featurette: Hired!

by in Feature Articles on

As you know, Hired has been sponsoring the site for the past few months. I went “behind the scenes” to have a brief chat with Michael Mitchell, a full stack web engineer focused on their “Candidate Experience” features.


Object Relational Mangling

by in CodeSOD on

Writing quality database code is a challenge. Most of your commands need to be expressed in SQL, which is a mildly complicated language made more complicated by minor variations across databases. Result sets often have a poor mapping to our business logic’s abstractions, especially in object-oriented languages. Thus, we have Object-Relational-Mapping tools, like Microsoft’s EntityFramework.

With an ORM, you use an object-oriented approach to fetching your objects, and could write something like: IList<HJFRate> rates = db.HJFRates.where(rate=>rate.typeOfUse == typeOfUse) to return all the rows as objects. There’s no concern about SQL injections, no need to process the result set directly. While ORMs can generate poor SQL, or create really inefficient data-access patterns, their ease-of-use is a big selling point.


Attack of the "i" Creatures

by in CodeSOD on

Mrs S” works for a large software vendor. This vendor has a tendency to quickly increase staffing to hit arbitrary release targets, and thus relies heavily on contractors. Since they’re usually doing this during a time crunch, these contractors may have a… dubious skill set.

They also don’t care. There is no documentation, no tests, and no explanation. They are just paid tho write the code, not maintain it. They’ll be on another contract before long, so it’s some other schmuck’s problem.


Protect Your Property

by in CodeSOD on

Given the common need to have getter/setter methods on properties, many languages have adopted conventions which try and make it easier to implement/invoke them. For example, if you name a method foo in Ruby, you can invoke it by doing: obj.foo = 5.

In the .NET family of languages, there’s a concept of a property, which bundles the getter and setter methods together through some syntactical sugar. So, something like this, in VB.Net.


Drop it Like it's a Deployment

by in CodeSOD on

Zenith’s company went ahead on and outsourced 95% of their development to the lowest bidder. Said bidder promised a lot of XML and MVC and whatever TLAs sounded buzzwordy that day, and off they went. It’s okay, though, the customer isn’t just taking that code and deploying it- “Zenith” gets to do code reviews to ensure code quality. The general flow of the post-code-review conversation goes something like:

Zenith: This code shouldn’t go into production, hell, it’s so bad that a proud parent wouldn’t even hang it on their fridge.
Management: I’ll raise your concerns.
Outsourced Team: We did the needful, please review again.
Zenith: They didn’t change anything. It doesn’t even compile.
Offshore Team: There are too many barriers, we cannot hit deadlines, your team is too strict
Managment: Yeah… I guess you’re gonna have to lay off the contractors. Don’t be so strict in your code reviews. We have to deliver software!


Nature In Its Volatility

by in Feature Articles on

About two years ago, we took a little trip to the Galapagos- a tiny, isolated island where processes and coding practices evolved… a bit differently. Calvin, as an invasive species, brought in new ways of doing things- like source control, automated builds, and continuous integration- and changed the landscape of the island forever.

Geospiza parvula

Or so it seemed, until the first hiccup. Shortly after putting all of the code into source control and automating the builds, the application started failing in production. Specifically, the web service calls out to a third party web service for a few operations, and those calls universally failed in production.


Synchronized Threads

by in CodeSOD on

Tim was debugging one of those multithreading bugs, where there appeared to be a race condition of some kind. The developer who had initially written the code denied that such a thing could exist: “It’s impossible, I used locks to synchronize the threads!”

Well, he did use locks at the very least.