Disqus - Friends of ChrisMDP

Re: Central Agile Calendar?

J. B. Rainsberger — Tue, 30 Nov 1999 00:00:00 -0000

I was going to write what Rachel wrote, so +1 to her.

Re: Do you love a tax refund?

J. B. Rainsberger — Wed, 23 May 2007 16:01:13 -0000

@Barb, one of the advantages to being my own boss is that I can easily approve direct employee RRSP contributions to avoid having to remit withholding tax on the contribution to the CRA. I still have to pay the associated CPP contribution, but that's minimal by comparison. This way, I don't have to remit money in November just to get it back sometime in the spring.

Re: How To Backup Your Mac Intelligently

J. B. Rainsberger — Sat, 26 May 2007 17:38:50 -0000

Since you're a TextDrive customer, you might have StrongSpace. Since my Subversion repositories are the lifeblood of my business, I back them up off site to my TextDrive account nightly. Highly recommended and easy.

Re: How To Backup Your Mac Intelligently

J. B. Rainsberger — Sat, 26 May 2007 17:38:50 -0000

Re: The editing pass

J. B. Rainsberger — Thu, 11 Oct 2007 00:33:02 -0000

I just read this and it seems to describe refactoring almost exactly. I don't know why I hadn't thought of it before. Excellent.

Re: Motivation

J. B. Rainsberger — Sat, 24 Nov 2007 21:22:24 -0000

@Ravi, you could read "on balance, I want those results" as "I want those results more than I want to avoid what I have to do in order to get them". In other words, preference is about preferring the results to going without them. I have a similar problem with exercise, which is why I get exercise only when I do other things, like walk 25 minutes each way to the center of town here. I do that a few times a week, either to deposit money into the bank or to buy a particular brand of coffee I love, both highly motivating activities. While I could easily spend $14 and take a cab return trip to do those things, I use the motivation around those activities to provide the motivation for exercise. I can't go back to the gym. I simply find I can get good-enough results with much less pain and suffering.

Re: Why Agile Doesn’t Really Work

J. B. Rainsberger — Wed, 28 May 2008 22:18:06 -0000

I understand and feel your pain, but I quibble with your title. If you had named this article "*Where* Agile doesn't really work", then I'd have been right with you.

Unfortunately, it seems that Agile will hit big business only when small businesses that succeed with Agile/Lean become big businesses that succeed with Agile/Lean. If it happened, that would take decades, but then, any revolution takes that long attain anything close to critical mass.

Still, your message is clear: the world is not Agile. I hope you don't think anyone sane is walking along claiming it was, or could be anytime soon!

Re: Roku Netflix Player Unboxing & Setup

J. B. Rainsberger — Sun, 06 Jul 2008 20:30:28 -0000

I'm eager to find out whether the Canadian experiment worked. If it does, that's one more step away from cable TV.

Re: Why Dauphin?

J. B. Rainsberger — Thu, 11 Sep 2008 08:59:11 -0000

15 months later and I'm sitting on a Murphy bed in Oshawa, Ontario, visiting family at the end of a two-month trip away from home. It hasn't gone the way we expected, but on April 1, 2008 we retired, Phase 1. That means that our wealth ratio vaulted well above 1.0, closer to 2.0, when considering our essential expenses (income taxes, property taxes, insurance, utilities, communications, food). We expect to focus on streamlining our current system of getting paid and reporting the results in 2009 in preparation to scale up (as my IT colleagues would say) to a 400% increase in passive income.

Re: Agile India plans to go Virtual

J. B. Rainsberger — Fri, 27 Mar 2009 09:03:14 -0000

I like the idea and would enjoy participating. Skype chat seems to work well for this.

Re: Easter Monday

J. B. Rainsberger — Sat, 18 Apr 2009 10:16:53 -0000

I don't want to act rudely, but I disagree with the way you use the term "story" here, and I nearly gasped when you added a property 'url' to your Feed because, "feeds should have URLs"!

As a user, I never want to add a feed to a list, and I never want to see the list of feeds. I interpret those as design activities, and return to the classic question "What's the good business reason for doing this?" to help me find the story. Not knowing your domain intimately, I can't answer the question, but I can certainly ask it. What's the good business reason for adding a feed to a list?

Your tests leave me speechless:

def testShouldExist(self):
try:
Feed()
except NameError, e:
self.fail(str(e) + 'The Feeds class does not exist! What are you waiting for?')

Why do you need this class? What feature requires you to design it? I consider this step far too small for TDD.

Now I must stress something: I imagine you built good software with a strong design, but your "stories" are tasks and your tests indicate that you wrote your code doing test-first programming, rather than test-driven development. I have no problem with all that, except that when we use the same words to describe different things, we cause wars.

Take care.

Re: Corey Haines Continues His Journey at Acts as Conference 2009

J. B. Rainsberger — Fri, 24 Apr 2009 23:30:48 -0000

@anonymous, I'm so glad you took the time to write your comment, but didn't find the testicular fortitude to include your name. Pussy.

Re: A brief experience with PhoneTag.com

J. B. Rainsberger — Tue, 28 Jul 2009 16:25:10 -0000

Workable, but I don't want to have to start giving out a new phone number.

Re: Unpopular Developer 5: Stop Unit Testing Your Scaffold Controllers

J. B. Rainsberger — Wed, 12 Aug 2009 16:09:50 -0000

Of course... why test the platform? Worry about your code, not Other People's Code.

Re: TDD: Testing with generic abstract classes

J. B. Rainsberger — Tue, 06 Oct 2009 18:31:05 -0000

This looks like contract tests to me. As long as you're using these abstract tests to verify common behavior and not to reuse test helpers, that makes me happy indeed. Rock on!

Re: A comment on "A Test Double Dilemma"

J. B. Rainsberger — Fri, 09 Oct 2009 02:20:59 -0000

I'm not prepared to reach that conclusion, because I haven't asked Gary enough about his situation. I can only guess what I wrote in the article: his layers have hard dependencies that make refactoring difficult, and he hasn't yet seen the relationship between the state of his tests and that dependency problem. I suspect that, but I would absolutely need to see his code to know for certain.

Re: Who tests the contract tests?

J. B. Rainsberger — Sat, 10 Oct 2009 03:15:00 -0000

Thank you for your comment, Denis. I think I can help you.

Can you upload some of your code here? If so, then I can see your example and give you more specific advice. Please go to http://www.thecodewhisperer... to register and post an item under "I Need Help!" We can work through your example there, and maybe other readers will have suggestions.

Re: Thought Leaders

J. B. Rainsberger — Sat, 10 Oct 2009 07:35:21 -0000

I /have/ retired by following the advice I give others. Sorry. Read http://www.weliveherenow.net to learn a bit about how.

Re: Part 4: Mark Needham and his book club on "Integration Tests Are A Scam: The Movie"

J. B. Rainsberger — Sun, 18 Oct 2009 13:36:30 -0000

You make a good point, Dan. I tend to need integration tests for only the Technology View, but not for the Logical View. http://bit.ly/b5Q8l

Even so, I would want to write tests that only run the view without integrating it with the request handler (controller layer) on all those browsers. The last time I had to do that in anger, I worked at IBM and didn't have the skill or knowledge to do that well, so I didn't try it then. I can imagine a simple system to make that work, though, based on the Golden Master technique.

Go to your application and issue an end-to-end request, but capture the complete request information and complete response information. Verify the behavior by inspection once. Now take that request and response and put them into a simulator that stubs the entire application at the HTTP level: when it sees that request, it sends back the corresponding response. This would allow us to check the view in different browsers without having to involve the entire application. It feels like a large-scale version of stubbing the controller layer (and below). I could see that working well, and I would like to try it.

Re: Single Responsibility Principle Demystified

J. B. Rainsberger — Sun, 18 Oct 2009 19:08:38 -0000

I think of SRP as a cohesion principle, and I model cohesion as "similar things are close together and different things are far apart". This means that I violate SRP when I put different things together, which relates to "one reason to change". When I put similar things far apart, I might not violate SRP, but I have duplication elsewhere, in the form of "duplication of intent".

As a result, I don't think directly about SRP. Instead, I think about cohesion, and when I fix cohesion problems, I tend to fix SRP violations.

Re: Single Responsibility Principle Demystified

J. B. Rainsberger — Mon, 19 Oct 2009 12:53:09 -0000

I think of cohesion (in general) instead of (just) SRP (in particular). I agree that SRP is one half of cohesion, specifically the "different things far apart" part of it.

I can't pick a single "Biggest Stinker", at least not in a few minutes, but I can give you a rough order in which I'd look for smells. The first "wave" consists of Feature Envy, Long Method and Primitive Obsession. The second "wave" includes Switch on Type and Law of Demeter Violations. From there, it depends mostly on the actual codebase.

Re: Part 1: Mark Needham and his book club on "Integration Tests Are A Scam: The Movie"

J. B. Rainsberger — Mon, 19 Oct 2009 13:03:19 -0000

Thanks, Nigel. Unfortunately, I don't have an example handy, which follows from clients not wanting me to use their code in my examples. :)

I had the same concerns you voiced here about separating data from behavior in interfaces and resulting in dumb data objects. I did that for a while. When I started to move behavior back into my entities, I noticed that I had better separated business logic from application logic. I could safely move the business logic into the entity and leave the application logic in the controller layer. I can't tell what steps I took to better see the coupling between business logic and application logic in my services, although I imagine it came down to better noticing duplication in names. At least, that's how I teach it now.

If you'd like me to look at code you have, then please go to www.thecodewhisperer.com/di... and post something in the "I Need Help!" forum. We can work on it there.

Re: Checking a method directly or indirectly

J. B. Rainsberger — Wed, 21 Oct 2009 13:42:50 -0000

In languages like Ruby, Python and Javascript, one can easily write a test double for the method doingOtherThing() without having to introduce an interface. I have not yet decided how I feel about this, because it relieves design pressure that I often find useful. Specifically, I like that trying to write the test double in Java or C# encourage me to move doingOtherThing() onto another class, and that JMock or NMock encourage me to move the method onto an interface. In a language like Ruby, I'd need more evidence to support judging the level of cohesion between doingSomething() and doingOtherThing(). I don't know how to interpret this yet, so I need to practise more.

Re: Checking a method directly or indirectly

J. B. Rainsberger — Tue, 27 Oct 2009 13:40:18 -0000

Why do you label "relieves design pressure" as "bad" here? Can you say more about what you mean?

Also, I find it difficult to compare these designs. Clearly, my suggestion reduces coupling, but without knowing the domain, I can't tell how much it also reduces cohesion. I usually want to reduce coupling and increase cohesion together.

I can use one guiding principle to help me prefer splitting class A into two classes: I find it easier to put small things together than I do to break large things apart, so I tend to write smaller classes and wait for evidence that behavior belongs together before putting it together. I consider that a learning preference rather than something objectively better or worse.

Re: Checking a method directly or indirectly

J. B. Rainsberger — Thu, 29 Oct 2009 10:23:57 -0000

I can't tell the level of abstraction of doingSomething() and doingOtherThing(), because the names don't represent any specific domain. If it happens that they have a similar level of abstraction, then I might consider introducing a new method doBothThings() that invokes each of them one by one.

I don't mind the use of public here for both methods. If that exposed an encapsulation issue, then I would solve that by extracting an interface for A that includes doingSomething(), but not doingOtherThing(). As I type that, though, I lean even closer to introducing doBothThings().

I'd need to know the domain to draw a reasonable conclusion.