test objects design

Would it be worth for a software development projects to transition from Management-Intensive Process-Heavy style of creating software to Management-Intensive Inventory-heavy style of creating software.
I have been in many meetings where things being discussed are mainly about how things are to be done. Everybody has something to say like “Well, I think they (meaning some team) should be doing it this way” or “I can’t believe they are doing it. Just lust week they were doing it some other way” and so on.

It seems most conversations are management talking about process and how they are following it and how come some others are not following it or should be following it.

In contrast I would like to envision the same style of Management Intensive style of meetings but instead of process I would like to introduce a new conversation about managing inventory: items to be done, impediments to clear or overcome, promises of actions to take, milestones with dates and measurable results. WARNING: when I say measurable results it is results about about inventory, stuff to get rid of, process into something else and add value to it.

Matz comments: Otaku, Cedric’s weblog: Flaws in Ruby

Finally, I am not against “method overloading”, but it very easily leads to optional static typing in the language, which changes the language
very drastically, since you need to specify “type” to overload
arguments. Without well-thought design, it can “destroy” the language
and its culture. I have not yet got that well-thought design of
method overloading

Typography - Hypnerotomachia Poliphili

Scholars find that the greatest artistic merit of the book is neither in typography or woodcuts separately, but in the overall composition of text and image into a harmonious whole, which allows the eye to slip back and forth from textual description and corresponding visual representation with the greatest of ease – a rarity even today

Bret on Watir Mailing List

Actually, the best way to do this is to put test root in your load path.

$LOAD_PATH << File.dirname(__FILE__) + ‘/../’ require ‘lib/variables’ 

The problem with Keith’s solution is that you’ll end up requiring the same file from different tests via different paths. The semantics of require is that it won’t load a library if it has already been loaded, but if you are loading the same file but using a different path in your require statement, require will think it is a different library and load it again.

I am wondering if a better thing would be to unshift the path so it’s first in the stack like this:

$LOAD_PATH.unshift(File.dirname(__FILE__) + '/../')require ‘lib/variables’

Would it be a bit better? Would it cause problems if you are use other require for ‘test/unit’ etc…? Ideas?

from Brian Marick - Everyday Scripting with Ruby

What I tell people on my consulting trips is that every week you spend
at your job should make you worth at least a little more money. Make
a habit of asking yourself whether that has been true of the past week.
Some fraction of scripters fall into the opposite trap: they get so enthralled
with scripting that they build elaborate, gorgeous (to them, at least)
frameworks far in excess of what their job demands. The trick in scripting
is to push yourself beyond the minimum while still regularly producing
results that justify your salary. To do that, you have to grow
your scripts bit by bit, satisfying one real and immediate need after
another, while still keeping the code clean. This book won’t surgically
implant that skill in your skull, but it’s given you some of the tools you
need.(emphasis mine)

Scott Hanselman’s Computer Zen - Sandcastle - Microsoft CTP of a Help CHM file generator on the tails of the death of NDoc

This Open Source stuff is free. But it’s free like a puppy. It takes years of care and feeding. You don’t get to criticise a free puppy that you bring in to your home.

Merging conflicts by hand can be quite intimidating the first time you attempt it, but with a little practice, it can become as easy as falling off a bike.

from svnbook

(msdn examples criteria,expression values)

Field 	Expression 	Description
Date 	Between #1/5/95# And #1/10/95# 	Uses the Between...And operator
Date 	#2/2/95# where valu is 2-Feb-95.
Country 	In("Canada", "UK") 	Uses the In operator to display orders shipped to Canada or the UK.
ShipCountry 	Not "USA" 	Uses the Not operator to display orders shipped to countries other than the USA.
ShipName 	Like "S*" 	Orders shipped to customers whose name starts with the letter S.
CompanyName 	>="N" 	Displays orders shipped to companies whose name starts with the letters N through Z.
OrderID 	Right([OrderID], 2)=”99″ 	Uses the Right function to display orders with OrderID values ending in 99.
CompanyName 	Len([CompanyName])
 />Val(30) 	Uses the Len and Val functions to display orders for companies whose name is more than 30 characters long.

Is Null
Is Not Null
“Value”
“Value” or “Others”
Not “Value”
“” zero lenght string value.
Like “beginswith*”
Like “*endswith”
Like “[A-D]*” Begins with A, B, C or D
Like “*middlestring*”
Like “strin?” last letter unknown

Ruby Sig: How To Design A Domain Specific Language - Google Video: This is David Pollak’s presentation. I didn’t listen to the whole thing but I would love to see the slides just go through them. The most important thought from me is about interveiwing users and writing pseudo code. This is definitely what FUNTOM is about for Test Development.

InfoQ: Domain Driven Design Quickly (download the book)

So we start with the domain. Then what? A domain is something of this world. It cannot just be taken and poured over the keyboard into the computer to become code. We need to create an abstraction of the domain. (…) a blueprint in our minds. In the beginning, the blueprint is always incomplete. But in time, while working on it, we make it better, and it becomes more and more clear to us. What is this abstraction? It is a model, a model of the domain. According to Eric Evans, a domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence. The model is our internal representation of the target domain, and it is very necessary throughout the design and the development process. During the design process we remember and make lots of references to the model. The world around us is way too much for our heads to handle. Even a specific domain could be more than a human mind can handle at one time. We need to organize information, to systematize it, to divide it up in smaller pieces, to group those pieces into logical modules, and take one at a time and deal with it.

Picture is worth a thousand words, no?