naildrivin5.com

Website of David Bryant Copeland

DCI vs Just Making Classes

January 02, 2013

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.

☞ DHH on Hypermedia Hype

December 20, 2012

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.

Re-use in OO: Inheritance, Composition and Mixins

December 19, 2012

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 by 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?

Why you can't refactor test code

November 16, 2012

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.

Making it Right: Technical Debt vs. Slop

October 05, 2012

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

August 19, 2012

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.

☞ Hate COBOL, not Java?

August 13, 2012

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?

☞ End of Rational Discourse?

August 10, 2012

Steve Yegge has an interesting post up, that classifies programmers along the conservative-to-liberal axis (which is, ironically, completely useless in classifying real people’s political feelings):

I think that my conceptual framework gives us an “out” – a way to avoid being emotional about these subjects. Casting the problem as a clash between Liberalism and Conservatism gives us the ultimate ticket for “agreeing to disagree”.

The way to avoid being emotional is to…avoid being emotional. I think that casting the problem as some unchangeable political “stance” is lazy thinking, and gives use the ultimate ticket for avoiding any real discussion. This way of thinking seems most useful in dismissing arguments one doesn’t feel like thinking too hard about.

Honestly, if you can’t have a real discussion about the pros and cons of e.g. static typing, you either have a lot to learn, or are not a very capable developer. If your best answer to “Can we use Ruby on this project?” is “oh, we’re Conservative, so…no”, then you are either have a lot to learn or you are an asshole. If you refuse to even discuss what the benefits of explicit, yet verbose code are over implicit, but compact code, then you are either have a lot to learn or are an asshole1.

As developers, we’re blessed to work in a field full of objective truths. To avoid seeking them out under the guise of immutable political stances is the epitome of anti-intellectualism.

  1. 1I would make the same conclusion for the opposite: you should be able to discuss the benefits of implicit, terse code over explict, verbose code, too.↩

Running Stock

August 02, 2012

One of my fellow developers asked me the other day if I had any good dotfiles for bash. I realized I don’t. I don’t even have ll aliased to ls -l like most of the known universe. I realized that I like to run as stock as I can.

☞ Hungry Academy graduates

July 30, 2012

An article in the Washington Post gives a good summary of Hungry Academy, LivingSocial’s experiment to train 24 motivated people to become fully-functional developers in just five months. They worked hard and all graduated last week, starting as official developers over the next week.

The benefit, if all goes according to plan, however, is a fleet of engineers that can be hired en masse with a commitment to work at LivingSocial for at least 18 months. Unlike fresh hires, the academy students are already familiar with the company’s products and culture.

The 2-3-week-long projects they delivered over the course were impressive enough, but given that many of them didn’t have any professional programming skills beforehand, their progress has been amazing to watch. The first half of this grand experiment is over and it was a rousing success. The second half - how well they succeed in the actual work environment - begins now. I’m optimistic.