Thursday, December 29, 2011
Saturday, November 12, 2011
There is a little too much exposition in some places, and it may seem to have a libertarian agenda, though it shows that corporate power can be just as much of a threat to freedom as government power.
The chapter about the VR Epidemic, and the VR Museum (which serves this society like "the Holocaust Museum" serves ours) warns that we could entertain ourselves to death, if our entertainment gets to be too good.
I recommend this book.
Wednesday, June 8, 2011
(repost from 2006.Aug.12 Sat)
Check out Dave Astel's paper (pdf) on TDD/BDD. Quotes:
[...] There are a score of books available on TDD, mine even won a Jolt award. So it seems that everything is rosy? Everyone who's doing TDD is fully understanding it and getting the full benefit, right?
Too few people I talk to really understand what it's really about. That means that many people who practice TDD are not getting the full benefit from it. What's wrong?
The focus on testing
Well... one thing is that people think it's about testing. That's just not the case.
Sure, there are similarities, and you end up with a nice low level regression suite... but those are coincidental or happy side effects. So why have things come to this unhappy state of affairs? Why do so many not get it?[...]
So with people thinking about testing, it's easy to come up with all sorts of negative reactions and reasons not to do it... especially when time gets short and the pressure's on.
By the way, I HATE saying TDD is "not about the testing". I have to say it now and then because of people not realizing it's about designing, rather than testing. The fact that the word "test" is in the name just helps confuse the issue. My preference for naming this design technique, is to call it "Behavior Driven Design". Or "Behavior-Spec Driven Design". With BSDD, I could say BSDD is about the behavior-specs, but mostly aboutdriving design.
Alistair Cockburn's "Executable Example Driven Design" (XXDD) is OK, but a bit long-winded. And I don't want to have say "Dos-equis Driven Design is not about beer." :-)
The problem is mental frameworks. People reject ideas that don't fit into their mental framework. You say "test" and the listener's mental framework comes up with these and other assumptions:
- Testing can be done manually.
- I can do implementing, someone else can do testing.
- Testing looks for bugs.
- Tests need something to test.
- Testing is hard.
- We can skip testing if we are good enough programmers, or time is short.
None of those assumptions directly applies to TDD. TDD can't be separated into tests written by one person and code written by another because the TDD cycle of test-code-refactor is a design process that one person (or a pair) goes through in cycles, where each cycle takes only minutes. TDD/BDD helps me find bugs, but that's not the purpose of TDD. TDD isn't TDD is you do the "test" part manually.
If you say "Test-Driven Development is not about the tests," that usually doesn't provide the zen-like kick in the brain-pan that the speaker intends. Instead, the phrase gets rejected because it doesn't fit into the listener's mental framework for "tests". The listener probably thinks you're nuts. He or she might just flip the "bozo bit" and stop listening to you.
If instead you say "Behavior Spec", the listener's mental framework will have fewer contradictory assumptions. For example:
- Specs are written before coding.
- Specs can provide examples.
- Specs tell you what you need to implement.
- Someone else can write specs and I can write the code.
Not all of those assumptions are true for BDD, but there are fewer contradictions to this idea of BBD that you're trying to introduce into someone's mental framework. Behavior Specs are written before the code exists (though only minutes before). Behavior Specs are executable examples. Behavior Specs tell you, more or less, what you need to implement next. There is still the contradictory idea that someone can write the Spec and someone else can write the code, but that isn't as difficult to overcome as all the other assumptions that come up with the word "test".
Thursday, June 2, 2011
Monday, April 18, 2011
Here are some dependencies from best (least-coupled) to worst (most tightly-coupled).
1. Class A depends on Class B, where class B is an interface ("pure" abstract base class).
We can test instances of A by creating our own test-specific subclasses of B to pass into A.
2. Class A depends on Class B, where class B is a concrete class but the functions are declared virtual.
We can test instances of A by creating our own test-specific subclases of B, but at a price: we have to deal with B's constructors and destructor, possibly doing stuff we don't want.
3. Class A depend on Class B, where class B is concrete class with no virtual functions.
4. Class A depends on Class B, and class B grants class A "friend" access.
5. Class A depends on Class B, and class B is a class declared INSIDE class A.
Also affecting how class A depends on class B is the WAY the dependency is manifest. It turns out that "visible" dependencies are often better than "hidden" dependencies, which is opposite of the usual idea of "information hiding", the predecessor idea of "encapsulation".
Saturday, April 9, 2011
RT: @LeanVoices: The idea is the easy bit, execution is where excellence and hard work resides.
RT: @suziedwards: Resume blooper of the day? "Software Mythologies used include Waterfall and Scrum".
RT @markrneedham: How to type on an iPad http://bit.ly/ftr9Vl
RT @flowchainsensei: Facebook's data center play sidelines Google, Apple http://reg.cx/1NBh
Chad Fowler = "These have changed my developer life, how I perceive software
and that great technology is fun" http://bit.ly/hP2B6O
Cool, @gregturn has finished Python Testing Cookbook! #congrats http://www.packtpub.com/python-testing-cookbook/book
RT @hackernewsbot: New engine shakes up auto industry... http://www.msnbc.msn.com/id/42460541/ns/technology_and_science-innovation/
Divvy is pretty awesome. http://bit.ly/g11Hj5
RT @badbanana: If you enjoy being the 10,000th person to put your thumb into a hole, then bowling is for you.
RT @theCoachingblog: "The things we hate about ourselves aren't more real than things we like about ourselves."
(Ellen Goodman) #quote
"Managing" Velocity: The term velocity is very well-chosen. It means speed in a certain direction, w... http://bit.ly/gvikOP #agileotter
RT @capotribu: "My startup story: from big idea to thriving business in 8 short years" http://t.co/IXMCjfV < great story of real reality
Fun Fact http://dinosaurmusings.wordpress.com/2011/04/08/fun-fact/
Our schools failed many of us. Why don't people understand the role of analogy? http://bit.ly/gBRqji (see comments) #testing
Good read. RT @toddcharron: An Agile Pace http://t.co/Rn9Gzuf - reminds me of http://t.co/gwmGRX7 #agile #scrum #kanban #overtime
Best #Agile article this year: Agile’s Second Chasm (and how we fell in) http://bit.ly/hvQDpT by @williampietri #recommended
RT @tottinge @jamesshore Someone was selling us a product that allows you to "collaborate in isolation from each other."
James Shore = For the record: Rabu is not and never* will be a project management tool, a planning tool, or a replacement for a whiteboard.
See what you started, mike hill? RT @alancfrancis: I am now nekkid as a jaybird, in an apartment with 10 windows wide open, attempting to cool down. #sorrytoputthatimag ...
10 Acts of Resistance That Changed the World — YES! Magazine http://t.co/NFN2UVx
jasonlittle = we did a retrospective on why we stopped doing retrospectives. good insights, blog post coming.
I read this = http://blog.benjaminm.net/2011/02/16/argyriscasestudylearningmodelii/ = worth it
publishing co I never heard of: http://www.packtpub.com/python-testing-cookbook/book
This practical cookbook covers lots of test styles including unit-level, test discovery, doctest, BDD, acceptance, smoke, and load testing. It will guide you to use popular Python tools effectively and discover how to write custom extensions. You will learn how to use popular continuous integration systems like Jenkins (formerly known as Hudson) and TeamCity to automatically test your code upon check in. This book explores Python's built-in ability to run code found embedded in doc strings and also plugging in to popular web testing tools like Selenium. By the end of this book, you will be proficient in many test tactics and be ready to apply them to new applications as well as legacy ones.
engineering.twitter.com blog = Cross-site Scripting Protection is one hundred percent live on mobile.twitter.com
http://www.infoq.com/articles/Accidental-Agilist = Johanna Rothman wrote:
I didn’t think if myself as an agilist, of course. I decided to experiment with some practices, such as pairing and TDD. I’d worked closely with a couple of people one-on-one, back when I was a developer, and I wasn’t sure if it was really pairing. So I tried pairing and TDD with a colleague, Keith Ray, at an AYE conference, and sure enough, it was just like what I had done at work. Except, Keith was much nicer than my work colleague back in the ‘80s.:-)