Archive

Archive for March, 2009

Misc. BDD thoughts

March 6th, 2009 No comments
Categories: Behavior Driven Development Tags:

Interview of Dan North and Elizabeth Keogh

March 5th, 2009 No comments

The video of the interview is here.

First you get the UI, behind that there is code that gives benefit to the UI, and behind that there’s code that gives benefit to that piece of code, is smaller and more specific bits until the feature works.  The Domain Language is used all the way through.  Dan North tells a story…  While the developers were struggling with how to handle credit derivatives, a domain expert (a former trader) came by.  Because the developers were talking in the Domain language, the expert didn’t know they were even talking about code.  He thought they were talking about derivatives themselves and explained exactly how they work, giving them the algorithm.  

Scenario (and example) are words that the customer has a natural understanding for (unlike use case), that flesh out behaviors: given this situation, what to you want the software to do – what is the outcome?

  • Stakeholder: someone who has an interest in the work being done
  • Business analyst: expert in helping stakeholder articulate what they want in abstract terms e.g. “withdraw cash”
  • Tester: gets concrete with it e.g. “what does withdraw cash mean?  If I have $100 and withdraw $20, what is the result?”

This eliminates misunderstanding between the stakeholder and the developers as to what “done” actually means.

Using “should”  has two benefits.  Firstly, it forces you to focus on the class under test, because behaviors that don’t belong to that unit will not fit the “should” format.  Also, it allows the space to continually question “should it actually do this?”  This will have the documentation (the tests) naturally evolve with your understanding of the domain.

North describes different methodologies as:

  • Top-down – start with one big unit and keep breaking it up into smaller pieces
  • Bottom up – start with frameworks/architects and hope to solve the problem
  • Outside-in (BDD) – using the language of the domain, distinguish outer-most layer (e.g. scenarios) and work in from there.  The inner-most layer is the domain itself.  The UI is the third layer, which describes how the user interacts with the software.  In total, the question is “how do I describe software [interaction method] that [behavior in domain]?”  e.g. “how do I describe software [on the web] that [helps me plan the best shipping routes]?”

He concludes by suggesting that developers who are ingrained in the domain language can actually become part of the process of discovering business value, as they bring their level of understanding to the domain.

Value Driven Development

March 4th, 2009 No comments

Why are we writing software?  People are doing things that matter to them.  Software supports and enables them to fulfill on what really matters.  Nobody is born and says “I love bytes.  What really matters to me is sitting in front of a screen all day.”  The user of the software has real dreams and desires.  Software, at it’s best, can magnify their ability to achieve those dreams.

How do we create software that has the maximum impact on what matters to our users?  Assuming that their business process is effective (who knows how much business value could be derived from the question “what is important to us and how do we fulfill on that?”), the question becomes “what will this software do to produce outcomes that matter to the customer?”

Ultimately, it’s the outcome that matters.  The customer cares about the behavior of the software, but as a means to their ends.  The metaphor that most completely captures and illustrates puts this outcome at the forefront, as the driver of the process.  How would we communicate this?

???? Driven Development:

  • Outcome DD
  • Value DD
  • Result DD

The question that the customer needs to answer for themselves is “what’s most important?  Maybe an access is “why do you do this?”  This would be an ongoing question.  The process is then to continually declare and implement behaviors (what it does) to fulfill on these (why it does it).  Obviously a domain language would be invented and agreed upon so what matters can be faithfully translated – to outcomes, then behaviors, and finally into code – without losing any of the juice.

It could look something like this:

  • What matters: our customers are served as quickly as possible and back to their full lives
  • Outcome: customers can process common transactions without a representative
  • Sub-outcome: customers can withdraw cash from a machine using a card
  • And then BDD takes over…

 What would this achieve?

  • customers would be focused on and present to what really matters, supporting them in discovering and specifying requirements that will stick earlier
  • customers are clear about the value they have received
  • developers are fulfilled and focused because they understand and get committed to what matters to the customers
  • code is written with its ultimate objective palpably available
Categories: Agile Development, Programming Tags:

Wait for it… wait for it… (let the code call for the pattern)

March 4th, 2009 No comments

As I read the design patterns in Agile Software Development, I constantly have to remind myself to avoid Needless Complexity.

  • only apply patterns to remove “smells”
    • rigidity (changes cascade)
    • fragility (changes break unrelated parts)
    • immobility (hard to disentangle parts)
    • viscosity (harder to do the right thing than the wrong thing)
    • needless repetition
    • opacity (hard to read and understand), and…
    • needless complexity (infrastructure with no benefit

It’s so perfect that a clue to poor design is applying design techniques themselves, if they are unnecessary.   It completes the circle and keeps you honest.  And, it’s so hard to live that it’s mentioned 8 times in the book – p. 86, 88, 136…

“if… the application is not changing in ways that cause the… change… separating them would smell… An axis of change is… only if the changes actually occur” (p. 97)

“we initially write our code especting it not to change.  When a change occurs, we implement abstractions that protect us from future changes of that kind… we take the first bullet… get the bullets flying early and frequently… stimulate changes… [by writing] tests first… using very short cycles – days,” prioritizing features – getting frequent feedback, and releasing the software early and often (p. 105), “defer all but the most obvious LSP violations until” you smell fragility (p. 116)

“global variables are not intrinsically evil… situation is an ideal choice for a global… only ever one instance… known by a very wide audience… a singleton or monostate would smell… it’s easier to simply keep the database instance in a global” (p. 213), & “don’t be offended by the… public data members.  This is not an object… just a container for data… no interesting behavior to be encapsulated… private [data with] getters and setters would just be a needless complication” (p. 339).

Categories: Agile Development Tags:

Domain Driven Development

March 3rd, 2009 No comments

My Behavior Driven Development research has turned me onto Domain Driven Development, as explained inDomain-Driven Design: Tackling Complexity in the Heart of Software.

  • Brainstorming and experimenting are emphasized as the developer and domain experts model the the domain, channelling the massive amount of information into what is significant.  All work – even if thrown away – develops problem understanding and strengthens feedback loops
  • The direct connection between developers and domain experts/users follows many iterations.
  • The developers’ knowledge of the domain supports refactoring and abstraction, accelerating the development trajectory
  • Analysts, domain experts, users and developers constantly keep the model conformant to business logic, user desires and software realities.
  • Everyone involved develops and speaks using a common domain language
    • While advocating a common project language, the book describes all the developers & domain experts, with unique languages describing the system from their perspective, translating for each other. It conjures the Tower of Babel – with the juice of the knowledge slipping through the cracks in the translation. It seems so obvious that software is a language problem – how to translate from the world, to business rules, to developer jargon, to code, to assembly, to electrical signals without losing the meat of it.
    • The difference between vague technical discussions and precise domain model descriptions is striking
    • The common language lies at the intersection of developer language and domain expert language, covering only what’s relevent to the project.
  • Patterns to keep code supple – a joy to work on and inviting change
    • Reveal the intention in the interface: name classes and operations based on effect and purpose, not implementation, using the common language. Force this by writing the interface you wish you had in tests.
    • Prefer Side-effect-free Functions – separate commands (have side-effects) into KISS methods that do not return domain data, and queries/calculations (no side-effects); use value objects when indicated.
    • Use Assertions (or Unit Tests) to promise pre/post-conditions & invariants (Programming by Contract)
    • The code wants to relax into its natural units.  Repeated refactoring and adaptation kneads it into conceptual contours – granular appropriate to the interest of the customers e.g. drivers don’t care about the fuel injector pressure, they want to know about acceleration.  Changes significantly breaking the domain layer are opportunities to deepen the model.
    • Annihilate all non-required coupling – to zero if possible – especially for the most complex computations
    • Prefer Closed Operations, which have the same type for all arguments (including the calling class if state is changed) and return value, to minimize dependency 

Ok, enough for today.  Very good focus on sound design.

Categories: Programming Tags:

Safari Books Online

March 3rd, 2009 No comments

Did you ever use a product and want to find the person responsible and… give them a hug.  Probably not often if you have the experience of corporations that I do!

For the past few months, I’ve been deciding how best to access my programming reference books while program from multiple locations (home, office, client’s office).  I accidentally found Safari Books Online (http://www.safaribooksonline.com).  They have almost every significant programming reference (at least for C++) written in the last 10 years.  Here’s a list of some of my favorite, available online at the site:

1. C++ Coding Standards: 101 Rules, Guidelines, and Best Practices
BOOK
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices
By  Herb Sutter; Andrei Alexandrescu
Table of Contents
   
2. C++ FAQs, Second Edition
BOOK
C++ FAQs, Second Edition
By  Marshall Cline; Greg Lomow; Mike Girou
Table of Contents
   
3. C++ Gotchas: Avoiding Common Problems in Coding and Design
BOOK
C++ Gotchas: Avoiding Common Problems in Coding and Design
By  Stephen C. Dewhurst
Table of Contents
   
4. C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond
BOOK
C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond
By  David Abrahams; Aleksey Gurtovoy
Table of Contents
   
5. C++ Templates: The Complete Guide
BOOK
C++ Templates: The Complete Guide
By  David Vandevoorde; Nicolai M. Josuttis
Table of Contents
   
6. Effective C++: 55 Specific Ways to Improve Your Programs and Designs, Third Edition
BOOK
Effective C++: 55 Specific Ways to Improve Your Programs and Designs, Third Edition
By  Scott Meyers
Table of Contents
   
7. Efficient C++ Performance Programming Techniques
BOOK
Efficient C++ Performance Programming Techniques
By  Dov Bulka; David Mayhew
Table of Contents
   
8. Exceptional C++ Style 40 New Engineering Puzzles, Programming Problems, and Solutions
BOOK
Exceptional C++ Style 40 New Engineering Puzzles, Programming Problems, and Solutions
By  Herb Sutter
Table of Contents
   
9. Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions
BOOK
Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions
By  Herb Sutter
Table of Contents
   
10. Modern C++ Design: Generic Programming and Design Patterns Applied
BOOK
Modern C++ Design: Generic Programming and Design Patterns Applied
By  Andrei Alexandrescu
Table of Contents
   
11. More Effective C++: 35 New Ways to Improve Your Programs and Designs
BOOK
More Effective C++: 35 New Ways to Improve Your Programs and Designs
By  Scott Meyers
Table of Contents
   
12. More Exceptional C++
BOOK
More Exceptional C++
By  Herb Sutter
Table of Contents
   
13. Sams Teach Yourself C++ in 21 Days , Fifth Edition
BOOK
Sams Teach Yourself C++ in 21 Days , Fifth Edition
By  Jesse Liberty; Bradley Jones
Table of Contents
   
14. The C++ Programming Language, Special Edition
BOOK
The C++ Programming Language, Special Edition
By  Bjarne Stroustrup – AT&T Labs Murray Hill, New Jersey
Table of Contents
   
15. The C++ Standard Library: A Tutorial and Reference
BOOK
The C++ Standard Library: A Tutorial and Reference
By  Nicolai M. Josuttis
Table of Contents

Are you kidding!  No more lugging 6 textbook sized books everywhere I go!?  The service is about $45 a month and the best money I’ve ever spent on a programming tool.

By the way, I have no business connection with the company, just wanted to share!

Categories: Programming Tags:

Behavior Driven Development

March 3rd, 2009 No comments

My adventure continues.  Today I’m exploring Behavior Driven Development, which seems to address my “lost in the jungle” relationship to TDD by starting with user requirements:

First reference, from the man himself – Dan North, the creator of BDD @ http://dannorth.net/introducing-bdd: 

I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.

Damn, sounds good so far!

The details:

  • Test method names should be sentences like testFailsForDuplicateCustomers.  The benefits are:
    • creates powerful documentation when combined with a utility (like AgileDox)
    • using “should” keeps you focused on what the class-under-test should do, and keeps you challenging whether it actually “should” do that – this guy is an artist :)
    • gives guidance when the test fails
  • Use behavior instead of test i.e. instead of “class ContainerTest,” write “class ContainerBehavior”
  • Continually ask “what is the next most important thing [behavior] the system doesn’t do?  This keeps you thinking in terms of business value
  • Requirements are actually behavior, so requirement analysis is actually behavior analysis.  For each user story, apply a Given/When/Then template to each relevent behavior:
    • Story – Customer withdraws cash: As a customer, I want to withdraw cash from an ATM, so I don’t have to wait in line at the bank)
    • Behavior – (Scenario 1) Account is overdrawn: Given that the account is overdrawn, And the card is valid, When the customer requests cash, Then ensure a rejection message is displayed, And ensure cash is not dispensed, And ensure the card is returned
  • Acceptance tests should be executable, analogous to unit tests.  He created JBehave for java.

Impressions: whhhewww.  I’m relieved that this isn’t yet another approach that must be learned from scratch.  It’s really just a metaphor (to quote Bob Martin) shift.  The techniques are identical to TDD, just looked at from the perspective of the users of the system.  What is the behavoir that the user wants in this stiuation – nothing to do with implementation!  This is great because that’s what the software is all about anyway!  It seems like TDD focused on the needs of the customer – perfect!

Bob Martin suggests that BDD really describes a finite state machine that could tell you all the possible combinations of behavior, and thus what tests to write and when you are finished (http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd).

Categories: Programming Tags: ,

Showing Hidden Files in Finder

March 2nd, 2009 No comments

If you do any work with hidden files on your mac (like local web development .htaccess files), this script will save your behind.

http://forums.macworld.com/thread/72863

Just set a shortcut to it with FastScripts – one of my favorite Mac apps – and your ready to rock!

p.s. I edited the script by moving the “Finder” quit line to the start of the script changing the delay to .02 (after a bit of experimentation) – so far so good!

Categories: Mac Tags: , ,

Accessing documents outside the web root in Apache using mod_rewrite

March 2nd, 2009 No comments

I’ve been wanting to keep a CGI script outside my web root (for security), but still serve it on my site.

The problem:

  • I’m on a shared host, so I have no access to the server config files (if I did, an ScriptAlias directive would be the move)
  • RewriteRule directives in .htaccess files will not serve documents outside the web root
  • SSI is not implemented correctly on my server (actually running litespeed), and is recommended for small code insertions anyway.

After days of mailing list and forum posts, always seeming right on the edge of success… Arrrggghhhh!!!!

The solution?

  • Put a symbolic link to the script (which does not contain any of the sensitive data) in the directory with the .htaccess file
  • In .htaccess:
    • Options +SymLinksIfOwnerMatch # tells Apache to follow the link
    • RewriteEngine on # enable URL processing via mod_rewrite
    • RewriteRule ^(.*)$ scriptname?$1 [T=application/x-httpd-cgi] # pass the path_info requested (everything after the hostname) as a query string to the CGI; and handle it as a CGI script (T=…)

And, voila: script outside web root served!

I hope this saves someone else the frustration!

p.s. the minimum permissions to make this setup work are:

  • Script, link and .htaccess: 604
  • Script directory: 701
Categories: Web Development Tags: , ,

How much up-front design?

March 2nd, 2009 No comments

I’ve been writing code for a C++ CGI application that drives a website.  I love Test Driven Development, yet I can finally see that it’s just one technique – albeit a very effective one.  I can’t wait to integrate the other Agile practices and see what shakes out.  Right now, driving with unit tests, I feel like I’m in the middle of a jungle with the sharpest, lightest machete available – now if I can only figure out which way is out, I can start chopping, lol

Acceptance Testing!  Duh.  Something I’ve always heard about, but never investigated.  It makes perfect sense: sure the objects work, but are they even the right objects?!  Start with what success looks like from the customer’s point of view.  I just found FitNesse, an Acceptance Testing tool by the legendary Robert “Uncle Bob” Martin.  Looks promising…

Categories: Programming Tags:

windows 7 product key

windows 7 product key

windows 7 key generator

windows 7 key generator

free winrar download

free winrar download

winzip activation code

winzip activation code

free winrar

free winrar

winzip free download

winzip free download

winrar free download

winrar free download

winrar download free

winrar download free

winzip free download full version

winzip free download full version

windows 7 activation crack

windows7 activation crack

windows 7 crack

windows 7 crack

free winzip

free winzip
\n