Remy Porter

Remy is a veteran developer who writes software for space probes.

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.

Enterprise Streaming

by in CodeSOD on

Enterprise software development gets a bad rap, especially here, because "good code" isn't really a goal of an enterprise. Solving business problems is. And no enterprise is more enterprise than a government, and no government is more government than the US Federal government.

Which brings us to today's anonymous submitter, who wanted to keep up on current events in US politics. While watching some recent videos of Senate proceedings, our submitter got bored watching (as one would), they pulled up the browser tools. And that's where our WTF comes from.


SQL with no Equal

by in CodeSOD on

Relational Databases and No-SQL Databases take two key different philosophies, by and large. No-SQL is hard to talk about in broad terms, as it's mostly a set of unrelated technologies all solving the data storage problem in different ways. But we can still make some broad generalizations.

In No-SQL-land, we mostly store data the way we plan to query it. Ad-hoc queries are likely a bad choice, if they're even allowed. In RDBMSes, we store data according to a platonic ideal of normal forms, driven by the data in our domain. We can query the data however we like, using a language that only declares the data we want, not how to get it. Indexes and views and other behind-the-scenes structures make the query efficient.


It's Not That Different

by in CodeSOD on

We recently discussed the challenges of testing legacy code. Willy sent us some code from tests for a newer Java application.

Now, one of the main advantages, in my opinion, about unit-tests is that they serve as documentation. They tell you what the method does, and how it expects to be called. A good unit test is far better than a large pile of comments.


Switching Your Test Cases

by in CodeSOD on

Chris was given a program and told to improve it by adding tests. That was a good start to a terrible experience. Just getting it to build was a chore, as the build files had absolute paths hard-coded into them.

But the real problem Chris ran in to is that it's hard to write tests for something if no one knows what it does or why it does it. The application had no documentation. No comments, aside from commented out blocks of dead code. But comments aside, there was no other documentation. Which left Chris with methods like this to work with:


D'Tables

by in CodeSOD on

Wim works on a web app with a problem. Specifically, the error log is the fastest growing file on the system. Well, perhaps that's not the problem, but actually a symptom. Like so many applications, it's a PHP web app with a MySQL backend, and the previous developer made… choices.

$sqlisgt = "insert into ser_gen_tj values (4, '$type_juridiction', '$enr[23]', 'O')";

Hungry For an Education

by in CodeSOD on

An anonymous submitter from Hungary reached out with both some bad code, and a story behind it.

Hungary's school system runs on a software package called KRÉTA. The Sawarim$ hacker group felt that the software was badly designed and left millions of students personal information unprotected- so they hacked in to prove it. The company running the software responded in the worst possible way- by attempting to cover up the breach and pretending nothing ever happened. It's quite the news story.


The Parameters

by in CodeSOD on

As we frequently observe, code in scientific applications tends not to have the best code quality. And it's not hard to understand why: a researcher is frequently trying to take a wholistic understanding of a complicated problem domain and turn it into code. Software engineering, on the other hand, teaches us to break that wholistic picture up into little parts that we glue back together. The latter approach produces better code, but requires a lot of thinking about the structure of code, which is a whole layer on top of that wholistic understanding.

Which brings us to Plink, a C program Oliver R has had to work with. It analyzes genetic variance data. It also has a method with this signature:


A Null Mystery

by in CodeSOD on

The saying goes that debugging is like solving a murder mystery, where you are both the victim and the killer. This, of course, is a bit inaccurate, since we rarely are the only programmer working on a project.

Cole Tobin brings us a small mystery in C# today, though in this case, the mystery is- how does this even work?


Archives