So, someone shared some code on Github and some classic developer snark rolled in. And then there were some apologies about it. I saw those snarky tweets when they came through, clicked to the Github project, didn’t understand what the issue was, and went back to work.

Now, I’m all for bad projects and bad code being called out. Our industry produces some shitty code, and a general lack of craftsmanship can kill business, or even people. So bad code needs to be pointed out. The question is, is this bad code? I think we can all agree that if it is bad code, we should try to point it out in a more constructive way (and I know it’s easier said than done), but let’s forget the tone and focus on the message. Is replace a silly project, or implemented in a stupid way?

No, it’s not.

Saw a blog post this morning titled Why Functional Programming in Java is Dangerous. Author Elliotte Rusty Harold sets up the world’s worst straw man I’ve seen. He talks about Uncle Bob’s post on the advantages of functional programming. Elliotte’s thesis is that Java and JVM just can’t handle this sort of thing, and then sets out to prove this with some terrible code that, unsurprisingly, is terrible. He takes this bit of Clojure

1

(take 25 (squares-of (integers)))

And “re-implements” it in Java. He does this by implementing integers to just allocate an array of all the integers.

Yeah.

Both DHH and Tim Bray make great points about “dependency injection” and its issues regarding Ruby and testing. My colleague Adam Keys makes a similar point, though doesn’t call his anti-pattern “dependency injection”.

The scare quotes are because neither DHH nor Tim are accurately representing the purpose of dependency injection. Dependency Injection is not about a framework, XML, factories, or testing. It’s about simplifying code. Let’s see how.

There’s been lots of talk about DCI in the Ruby community lately. As I mentioned, I am only partway through Jim Gay’s unfinished book on the subject, but I ran across a blog post that had a more substantial example in it.

Titled Why DCI Contexts?, someone named rebo, shows a starting point of “normal” code, then “DCIzes” it, then walks through adding new features to the system. It’s a bit long, but his explanation is great, and it shows a lot more than just calling .extend on an object - he clearly demonstrates how roles and contexts are used to implement specific use cases.

Despite the deftness of his explalnation, I find the result code entirely too complex, thanks to confusing abstractions, a needless DSL and leaky abstractions. It would all have been a lot simpler if he Just Used Classes®

Let’s see why.

The ever-opinionated DHH, on the “hype” about “hypermedia” APIs:

The recurrent hoopla over hypermedia APIs is completely overblown. Embedding URLs instead of IDs is not going to guard you from breakage, it’s not going to do anything materially useful for standardizing API clients, and it doesn’t do much for discoverability.

Couldn’t agree more. Just getting developers to consume an API that isn’t all POSTs is hard enough. If “hypermedia” has demonstrable benefits, I certainly have never seen proof of this, outside of a lot of exasperated flailing.

Remember when “Hypermedia APIs” were called REST? I do. From my post about this in 2009:

Rest Compliance Officer: Is there exactly one endpoint, from which any and all resource locators are discoverable?

Me: Um, no, that puts undue burden on the client libraries, and over-complicates what we were trying to accomp….

RCO: YOU ARE NOT RESTFUL! READ FIELDING’S DISSERTATION, THE HTTP SPEC AND IMPLEMENT AN RFC-COMPLIANT URI PARSER IN THREE DIFFERENT LANGUAGES. NEXT!

Using HTTP methods for their intention is great, as is sane URL design, but the fantasy of a generic client that can discover and navigate every possible operation of a web UI seems like just that…fantasy.

Over the past several months, the Rails community, at least to my eyes, has become increasingly concerned with managing the complexity that appears when following the “fat model, skinny controller” advice prescribed my many Rails experts. The real issue, however, is reusability. How can logic be easily used in two places? In your average object-oriented language, there are four primary ways to accomplish this:

• Copy and Paste
• Inheritance
• Composition
• Mixins

None are so superior to the other as to always be applicable, so how can we know when to use one over the others?

Was having a discussion with Mike Gehard, Jeff Simpson, and Dan Hopkins about Dan Mayer’s excellent post, and we go on the topic of refactoring test code. My assertion is that you cannot, technically speaking, refactor test code, because you have no tests of the test code. Refactoring cannot be done without tests that assert that the changes you’ve made haven’t introduced problems.

The discussion put forth a few such tests of tests code, such as running it on prod, having the tests continue to pass, or measuring coverage. Unfortunately, none of these are sufficient to call changes in test code a refactoring. I would call it a rewrite or redesign, and I think that the distinction is important.

We were recently having a discussion at work about “doing it right” and “technical debt”. The discussion revolved around the optionality of “doing it right” - when is it OK to not “do it right”?

I would say it’s almost never OK to write code incorrectly. If your understanding of what “doing it right” means includes an “optional” clause, you have the wrong definition. As professionals, we should always do it right. We should always do our work correctly. I don’t mean we should over-engineer, nor do I mean that we should solve an abstract problem instead of the one in front of us for “flexibility”, but we should have a basic standard that we inflexibly hold ourselves to.

Writing code that does not adhere to our personal standards of correctness isn’t technical debt - it’s slop.

GLI 2.0 is out! GLI is the best way to make a “command-suite” command line interface. If you need to make a complex command line app that takes subcommands, like git or gem, GLI is the most powerful and easy-to-use way to do that.

Another stinker from jelastic, this time on how Java’s not that bad:

So next week someone will invent another DSL that makes Twitter easier to use, but your bank will be writing new COBOL to more efficiently transfer funds to another Bank. We’re embarrassing ourselves with our petty arguments.

So, because some industries are still using COBOL, we should stop advancing the state of the art, which involves moving onto more modern languages than Java, and go help out these poor billion-dollar industries get into the cloud?