Home > Archive > Extreme Programming > March 2007 > Greetings to all into XP!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Greetings to all into XP!
|
|
|
| I am new to the whole XP/Agile thing but I'm catching on quick (I
think). What I would like to know is does anyone have some suggestions
for quick info on unit-testing in c#. I'm reading Ron Jeffries' book on
Extreme Adventures in C#, but I could really use some supplemental info
on unit-testing in general. Any help would be greatly appreciated.
| |
| Phlip 2007-01-29, 10:00 pm |
| Phil wrote:
>I am new to the whole XP/Agile thing but I'm catching on quick (I
> think). What I would like to know is does anyone have some suggestions
> for quick info on unit-testing in c#. I'm reading Ron Jeffries' book on
> Extreme Adventures in C#, but I could really use some supplemental info
> on unit-testing in general. Any help would be greatly appreciated.
O'Reilly's /Unit Test Frameworks/ book has a nice critter on the cover.
The Pragmatic Programmers have a /Pragmatic Unit Testing/ book, re-exampled
twice in Java and C#.
The Martins have /Agile Software Development; Principles Practices &
Patterns/, if I recall correctly; it also has both a Java and C# version.
After those, you have to just start trying it.
But try a dynamic language too, like Ruby. Java and C# are so close to each
other that those books are quite redundant!
Dynamic languages simplify a lot of this stuff!
--
Phlip
[url]http://www.greencheese.us/Z Land[/url] <-- NOT a blog!!!
| |
|
| Phlip wrote:
> Phil wrote:
>
>
> O'Reilly's /Unit Test Frameworks/ book has a nice critter on the cover.
>
> The Pragmatic Programmers have a /Pragmatic Unit Testing/ book, re-exampled
> twice in Java and C#.
>
> The Martins have /Agile Software Development; Principles Practices &
> Patterns/, if I recall correctly; it also has both a Java and C# version.
>
> After those, you have to just start trying it.
>
> But try a dynamic language too, like Ruby. Java and C# are so close to each
> other that those books are quite redundant!
>
> Dynamic languages simplify a lot of this stuff!
>
Well thanks for the advice! I'm going to scour Amazon for some of those
:) What advantages would learning ruby net me?
| |
|
| Phil wrote:
> Well thanks for the advice! I'm going to scour Amazon for some of those
> :) What advantages would learning ruby net me?
Because everyone thinks that the big three choices are C++, C#, and Java.
That's because they are very well marketed. But C# is derived from Java, and
C++ is a legacy thing. They are not very different, and they are not very
Agile.
Ruby is among the languages using Duck Typing. That's where "If it walks
like a duck, and quacks like a duck, it's a duck." You can mix and match
objects simply if they call the right methods on each other, regardless of
any inheritance relation between these objects.
That's Agile because you can rapidly upgrade the code to do more things, so
long as you convince client objects your new object is a duck, like they are
familiar with. The "statically typed" languages make you jump thru hoops
just to polymorph. Dynamic languages make polymorphism the default behavior,
and make you work just a little harder to get static typing.
In conjunction with rampant unit testing, dynamic typing actually makes the
Liskov Substutition Principle _easier_ to apply than it is in languages that
pretend investing fear and paranoia in strict type systems will somehow
prevent bugs.
Look all that up!
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
| Daniel T. 2007-01-31, 7:02 pm |
| "Phlip" <phlipcpp@yahoo.com> wrote:
> Phil wrote:
>
>
> Because everyone thinks that the big three choices are C++, C#, and Java.
> That's because they are very well marketed. But C# is derived from Java, and
> C++ is a legacy thing. They are not very different, and they are not very
> Agile.
>
> Ruby is among the languages using Duck Typing. That's where "If it walks
> like a duck, and quacks like a duck, it's a duck." You can mix and match
> objects simply if they call the right methods on each other, regardless of
> any inheritance relation between these objects.
You might also want to check out Python and SmallTalk which use "duck
typing" as well. (I always called them "dynamic-typed" but I must admit
that ducks are more fun.)
| |
| Ron Jeffries 2007-02-09, 7:02 pm |
| On Mon, 29 Jan 2007 16:07:52 -0600, Phil
<pmanning@automatedresearch.com> wrote:
>I am new to the whole XP/Agile thing but I'm catching on quick (I
>think). What I would like to know is does anyone have some suggestions
>for quick info on unit-testing in c#. I'm reading Ron Jeffries' book on
>Extreme Adventures in C#, but I could really use some supplemental info
>on unit-testing in general. Any help would be greatly appreciated.
You might want to check Jim Newkirk's book on NUnit, Microsoft Press.
Have fun!
Ron Jeffries
www.XProgramming.com
| |
|
| Ron Jeffries wrote:
> On Mon, 29 Jan 2007 16:07:52 -0600, Phil
> <pmanning@automatedresearch.com> wrote:
>
>
> You might want to check Jim Newkirk's book on NUnit, Microsoft Press.
>
> Have fun!
>
> Ron Jeffries
> www.XProgramming.com
Thanks Mr. Jeffries! Do you (or anyone for that matter) have some advice
on the task of extracting Stories from our customers? My approach may be
wrong but I feel like I need a CIA interrogation just to get them to
tell me what they want!
--
Phillip Manning <pmanning(at_glyph)automatedresearch.com>
Public Key Available on Request.
| |
| Ron Jeffries 2007-02-13, 7:02 pm |
| On Tue, 13 Feb 2007 08:25:56 -0600, Phil
<pmanning@automatedresearch.com> wrote:
>Thanks Mr. Jeffries! Do you (or anyone for that matter) have some advice
>on the task of extracting Stories from our customers? My approach may be
>wrong but I feel like I need a CIA interrogation just to get them to
>tell me what they want!
Tell me more about your experience with them. When you just sit down
and chat about what they want, what does the conversation go like?
Ron Jeffries
www.XProgramming.com
| |
|
| Ron Jeffries wrote:
> On Tue, 13 Feb 2007 08:25:56 -0600, Phil
> <pmanning@automatedresearch.com> wrote:
>
>
> Tell me more about your experience with them. When you just sit down
> and chat about what they want, what does the conversation go like?
>
> Ron Jeffries
> www.XProgramming.com
The meetings flow like this: I am asked to start a new project to make a
reporting program. I ask for some input on what kind of reports they
would like to see. They reply that they need a program that can generate
any report that the user would want from our data stores. This could be
tricky since none of our data tables are consistent ( many different
columns and data types). So I think that slurping it out in XML will
enable me to reorganize all this into a form that can be transformed and
otherwise munged into a dataset that will be the basis for a report of
some sort. They like this since XML can be used with MSOffice among a
plethora of other software. However; This is where the communication
breakdown happens. I need to figure out how to get them to tell me what
need on the output end. They like being able to produce computed columns
of data, but they don't want a "too difficult to use" interface for
specifying a formula to be evaluated. I think a parser/evaluator because
using precanned reports will not work since the requirements change too
fast. The example I showed them, a text box that could hold stuff like
column D = sum(col A, col B - col C), was "too complicated" for our user
base. They cannot imagine anything else that would be intuitive enough
and neither can I!
Perhaps it's not the specs... It may be one of those "it comes with
experience" type of things but I'm feeling lost.
--
Phillip Manning <pmanning(at_glyph)automatedresearch.com>
Public Key Available on Request.
| |
| Phlip 2007-02-15, 10:02 pm |
| Phil wrote:
> The meetings flow like this: I am asked to start a new project to make a
> reporting program. I ask for some input on what kind of reports they
> would like to see. They reply that they need a program that can generate
> any report that the user would want from our data stores.
"I know how to program ANY report, but it will take some time. Until then,
could you sketch ONE report you need to see NOW? I will make sure you get
that very soon, while I work on ANY report. And doing ONE report now will
make ANY report much easier later, when I get there."
(My emphasis - don't shout at them like that...)
> This could be
> tricky since none of our data tables are consistent ( many different
> columns and data types).
"Okay, this is a good sketch to start with. Now these columns here are a
standard type, but those types there will take longer to code. Which ones do
you REALLY need, and which ones can you leave out?"
Strike strike.
"Do you need that one formatted, or can I just barf out the raw data for the
first version?"
The users might already be familiar with that raw data, so the sketch might
get another strike.
> So I think that slurping it out in XML will
> enable me to reorganize all this into a form that can be transformed and
> otherwise munged into a dataset that will be the basis for a report of
> some sort.
"May I deliver HTML in a browser? That's the easiest because it gives us
printing and delpoyment for free..."
Now you trivially do database -> XML -> XSLT -> XHTML, and dump the result
into a static website.
The ideal here is to find a path of least resistance towards the business
value that can be delivered as early as possible, with . Your customers
might think they have to heap on the requests for options and
configurations, fearing they won't get any of them unless they ask for
enough. Your role is to question and optimise this clutter away, to get down
to the minimum that you can code, this w. Show them, every w, results,
so they get the habit of requesting more every w, and of postponing
_anything_ that they don't need and that could slow you down.
> They like this since XML can be used with MSOffice among a
> plethora of other software.
That's different - XML with a strict Schema...
(If I were starting this project, I would use Ruby on Rails for the
front-end, and MSOffice data for the _back_end_, but that's just because I
prefer the RADdest user interface I can find...)
> However; This is where the communication
> breakdown happens. I need to figure out how to get them to tell me what
> need on the output end. They like being able to produce computed columns
> of data, but they don't want a "too difficult to use" interface for
> specifying a formula to be evaluated. I think a parser/evaluator because
> using precanned reports will not work since the requirements change too
> fast.
All of that is the result of having too long a delay between requesting
features and using them. If they didn't snow you with requests like "ANY
reports", then you could deliver one little feature, with its little user
interface, and they could use it to plan the next feature.
Adaptive planning is a great way to smooth out the usability of some iron
hog like an MSOffice skin.
> The example I showed them, a text box that could hold stuff like
> column D = sum(col A, col B - col C), was "too complicated" for our user
> base. They cannot imagine anything else that would be intuitive enough
> and neither can I!
Right - you reverted to programmer thinking; the ability to do ANY formula.
Ask them what's the ONE stupid formula they need now, and then put that
under a dumb button that just says "click me". This is what users want, and
it's safe to give them it. You can change or upgrade as they ask for more
features.
(You ARE writing unit tests for all this MSOffice code, right? I know that's
a pain in the balls, but you have to do it; it makes the adaptive planning
safe and efficient...)
--
Phlip
[url]http://www.greencheese.us/ZLand[/url] <-- NOT a blog!!!
| |
|
| Phlip wrote:
> Phil wrote:
>
>
> "I know how to program ANY report, but it will take some time. Until then,
> could you sketch ONE report you need to see NOW? I will make sure you get
> that very soon, while I work on ANY report. And doing ONE report now will
> make ANY report much easier later, when I get there."
>
> (My emphasis - don't shout at them like that...)
>
>
> "Okay, this is a good sketch to start with. Now these columns here are a
> standard type, but those types there will take longer to code. Which ones do
> you REALLY need, and which ones can you leave out?"
>
> Strike strike.
>
> "Do you need that one formatted, or can I just barf out the raw data for the
> first version?"
>
> The users might already be familiar with that raw data, so the sketch might
> get another strike.
>
>
> "May I deliver HTML in a browser? That's the easiest because it gives us
> printing and delpoyment for free..."
>
> Now you trivially do database -> XML -> XSLT -> XHTML, and dump the result
> into a static website.
>
> The ideal here is to find a path of least resistance towards the business
> value that can be delivered as early as possible, with . Your customers
> might think they have to heap on the requests for options and
> configurations, fearing they won't get any of them unless they ask for
> enough. Your role is to question and optimise this clutter away, to get down
> to the minimum that you can code, this w. Show them, every w, results,
> so they get the habit of requesting more every w, and of postponing
> _anything_ that they don't need and that could slow you down.
>
>
> That's different - XML with a strict Schema...
>
> (If I were starting this project, I would use Ruby on Rails for the
> front-end, and MSOffice data for the _back_end_, but that's just because I
> prefer the RADdest user interface I can find...)
>
>
> All of that is the result of having too long a delay between requesting
> features and using them. If they didn't snow you with requests like "ANY
> reports", then you could deliver one little feature, with its little user
> interface, and they could use it to plan the next feature.
>
> Adaptive planning is a great way to smooth out the usability of some iron
> hog like an MSOffice skin.
>
>
> Right - you reverted to programmer thinking; the ability to do ANY formula.
> Ask them what's the ONE stupid formula they need now, and then put that
> under a dumb button that just says "click me". This is what users want, and
> it's safe to give them it. You can change or upgrade as they ask for more
> features.
>
> (You ARE writing unit tests for all this MSOffice code, right? I know that's
> a pain in the balls, but you have to do it; it makes the adaptive planning
> safe and efficient...)
>
WOW! This is REALLY informative. The comment about XML => XSLT => HTML
is funny because during and earlier iteration I actually had a utility
that I guess the code "willed into existence" that grabs meta-data from
the tables and makes XML and HTML (using XSLT) files for the tables in a
DB so I can see what type, column names, nullabilty etc, so I keep it
around for its usefulness. I barked up the "just give me a report so i
can start coding" approach but they don't actually have a report they
would like to run. This stuff doesn't need to work w/ office either, Its
just a "feature" i suppose that XML can be imported to office, the
winform control I'm using does all the rendering to the screen,
printer,and pdf or even excel but is XML native so it just made sense to
do it that way. The whole "Train them to give feature requests wly"
stuff is to get me into the sustainable pace right? Yes like a good
monkey I use TDD from the ground up now. This discussion is really great
to inform me of some of the practical applications of Agile methods in
the trenches. Should I be working toward getting more specific features
from my users/customers? Any advice on how to prod them in this
direction? Thanks for all the advice and sharing your experience Phlip,
Ron, and everyone else!
--
Phillip Manning <pmanning(at_glyph)automatedresearch.com>
Public Key Available on Request.
| |
| Thomas Hafner 2007-03-27, 10:04 pm |
| "Daniel T." <daniel_t@earthlink.net> wrote/schrieb <daniel_t-34E207.09502431012007@news.west.earthlink.net>:
>
> You might also want to check out Python and SmallTalk which use "duck
> typing" as well. (I always called them "dynamic-typed" but I must admit
> that ducks are more fun.)
And the Scheme programming language has duck typing, too, long before
than Python and Ruby!
Regards
Thomas
--
Sometimes I wonder if I'm in my right mind. Then it passes off and I'm
as intelligent as ever.
-- Samuel Beckett, "Endgame"
|
|
|
|
|