Comments

If you like to teach test-first/test-driven techniques, then you have probably stumbled over configuration problems in your programming environment. This happens to every presenter at least once. We have a variety of ways to handle the problem, and today I’d like to share another one with you.

Google Spreadsheet can run Javascript, which means that we now have a ready-to-go approximation of Fit. It took me only a few minutes to figure out how to write a Javascript function that operates on the value in a spreadsheet cell. After that, I recorded ten minutes of video demonstrating the environment.

Using Google Spreadsheet as a simple TDD/BDD environment from J. B. Rainsberger on Vimeo.

Yes, I wrote the code test-first, but not test-driven. Please hold your cards and letters. I wanted to demonstrate a testing environment and not TDD. Even so, with ATDD or BDD, we programmers often receive a batch of customer tests and make them pass one by one, and sometimes we don’t need additional programmer tests to have confidence that we’ve built things well. Looking at the final design for this solution, I don’t think that a strict test-driven approach would have improved anything. If you disagree, then please share your approach with us!

Comments

So maybe not an epic, age-old battle, but a battle nonetheless. The battle over the correct ordering of the Four Elements of Simple Design. A battle that I’ve always known I’d won, but until recently, could never justify to others. I can finally declare victory and bestow upon you the One True Sequence.

Calm down; I’m joking.

Seriously: it has always bothered me (a little) that I say it this way and Corey Haines says it that way, and somehow we both have it “right”. I never quite understood how that could happen… until now.

Read on →
Comments

I have improved the code samples to make them closer to valid, working Python.—jbrains

At some point, you know I had to write this article. Let me state something clearly from the beginning.

In spite of the title, I use mocks freely and happily.

I do not intend with this article to join those who either shun mocks or appear to shun mocks only to praise them. I plan to share a simple example of using mocks as a stepping stone towards a potentially more suitable design, but you must not interpret this as a message against mock objects.

There. I feel better now. I trust you to carry my message the way I intended it. Do not betray that trust.

Read on →
Comments

I just wanted an HTTP client.

I asked my Twitter community which HTTP client to use. Certainly not HTTParty, because cool people don’t use HTTParty anymore. One takes these risks when one falls out of the loop with the latest and greatest tools.

“Use Faraday”, they said. “It’s the best”, they said.

Everything went fine until I needed to follow a redirect. What happened from that point forward could form the basis of a solid one-act play. I’ll spare you the horror and send you directly to the punch line.

connection.adapter Faraday.default_adapter

Read on →
Comments

At Øredev 2013, I asked managers to tell me what makes their job difficult. I spoke to one manager who told me an all-too-common story about facing immense pressure from the board of directors to deliver more features more often and similar pressure from the programmers to give them more time to refactor. More important than the details of this situation, I’ve heard dozens of stories like these over the years, and while one single piece of advice can’t possibly address every significant aspect of these situations, I have found that most of the people who tell me these stories identify with what I’d like to share with you.

Warning. You almost certainly have more to deal with in your exact situation than this advice can cover. You might need some more direct help. I can offer that to you, but for now, read on.

Read on →
Comments

Legacy code imposes an unbounded, inexact tax on the cost of all future features. This explains why I run events like Legacy Code Retreat and why I write about improving the design of software systems. This further explains why I’m willing to accept the risk of people labeling me as an “over-engineerer”. What they label “over-engineering”, I consider managing risk. As part of managing risk, I like to test-drive changes to legacy code, and implicit dependencies almost always get in the way of starting. I’m going through this right now, working with Octopress, the blogging software that I use here.

Let me state this clearly: I really like Octopress. If you intend to interpret what follows as me attacking Octopress, then stop reading and go away. Thank you.

Read on →
Comments

I love having tricky conversations on Twitter. I know a lot of you don’t, because you can’t express yourself clearly in 140 characters or less, but I love it for precisely that reason. The constraint makes it easy to voice objections, which makes assumptions visible and encourages us to challenge them. You’d be amazed at the things that people object to – issues that you thought were settled a long time ago, which you take for granted, at least within certain of your social circles.

This Twitter conversation reminded me of one of my own, long-standing assumptions… the one upon which I based the name of this website.

You owe it to yourself to read the entire conversation, so click on the Tweet’s timestamp and read further. Allow me to summarise: Letting your code tell you where it wants to go does not mean conducting a seance, speaking to the dead.

This is not in my design toolbox

In case that conversation link has long-since died, let me state very clearly that when I write code, it might look like I use a Ouija board, except that I know that I’m controlling it. I’m looking for signals in my code to indicate design problems, then I decide which problems to address right now, then decide what to do about them. Some signals hit me more strongly than others. Over time I have developed an awareness of and a sensitivity to an ever-growing number of different signals that indicate potential design problems.

I just find it more fun to say that my code tells me where it wants to go. Please don’t interpret this too literally.

Comments

A Twitter conversation about Primitive Obsession caught my eye today. That conversation began with this tweet:

I can’t read J, so I can’t decide much about the quality of the code Tracy wrote, but I do notice one thing:

There aren’t many functions that operate on the primitive data (card rank, card suit, hand classification), they’re close by each other, and they’re all quite short.

Read on →
Comments

The bottom line:

Modularity. Details. Pick one.

I routinely work with programmers who feel uncomfortable with tiny methods and tiny classes, in spite of all the benefits of tiny methods and tiny classes:

  • easier to test
  • easier to read
  • easier to understand
  • easier to build correctly
  • easier to compose into working systems

The programmers who don’t like them cite these problems most often:

  • “I can’t find stuff!”
  • “I have to click too much to see what’s happening!”

This article by Kevin Rutherford reminded me of this issue. While Kevin extols the virtues of tiny methods, he doesn’t address this phenomenon, although he admits to running into it himself. I wanted to share what I do with him, but it doesn’t fit well into a comment. When I hear programmers complain about these things, I offer the following two responses to them.

Read on →
Comments

Another “demystifying” article. Great! I know… bear with me.

Of the SOLID principles, the Dependency Inversion Principle remains somewhat misunderstood. I’d like to help with that. I hope you’ll ask questions and challenge these ideas, so that I can improve this little article.

I learned the Dependency Inversion Principle from Bob Martin’s article, the salient part of which states:

High level modules should not depend upon low level modules. Both should depend upon abstractions.

or

Abstractions should not depend upon details. Details should depend upon abstractions.

I’ve noticed that I spend the vast majority of my time introducing abstractions and inverting dependencies (abstractions that use concrete things) when rescuing legacy code or adding behavior to legacy systems. Sometimes I feel like I don’t know any other useful trick than invert this dependency. One could make a drinking game out of it.

Even so, not enough people understand and apply DIP. Perhaps if I share a few examples or equivalent formulations, they will.

Read on →