XP makes randomness safer than clockwork [Was: Break out of]

XP makes randomness safer than clockwork [Was: Break out of]

Post by Phli » Mon, 14 Jul 2003 07:09:53



Guys,

At a recent XP meeting, they asked if so many constraints on code production
make changing large subsystems - the answer is nothing speeds change like
never not changing anything else.

So if a colleague asks a question, you only change a test to answer it.

Like a haiku detector set loose on your bedroom floor, this sucks up bugs.

International penpals, these things constrain.

Constraints produce a phase space, with vectors. We only need flatten the
floor; a solid layer of continualy passing tests.

They align on better code. Via change.

From: Steve Jorgensen

Quote:> I'm committed to trying to move from Access programming to OOP/TDD, and
I'm
> looking at moving to C# and/or Java.  So, I'm trying to think of projects
to try
> to implement as self-teaching projects.

Have any significant others put a day-care center on your credit card?

Read Mike Feather's startup work "welc". Take a sf.net program, and try to
upgrade it.

You'll find yourself expanding its sample code into a test.

If no sample code, reject and audition the next one.

Quote:> I've read enough now here and elsewhere to know that for TDD, the idea is
> usually to try to keep the UI as thin as reasonably possible since that's
the
> hardest thing to write tests for, and code as much as possible to be UI
> agnostic.  That sounds great, but my brain is having trouble bending that

way.

The GUI story is here: http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Quote:> It's not that Access is the only thing I've ever known.  I started out
> programming in Applesoft Basic, taught myself Assembly Language, then went
on to
> C, Modula II, ad did a fair amount of hobbying in C++ before ending up
working
> in database development using Paradox, Foxpro, then MS Access.

Is your GUI already thin in the stories?

If its thick, your tests must reach in from the GUI Layer. That's not the
nail then - it's the hammer.

Quote:>  Still, I find I've been steeped in Access for so long that my thought
process is
> that everything starts out as a UI tied to a back-end, then sprinkle code
as
> necessary (I'm a hammer now, and every problem looks like a nail to me).
How to
> I develop a replacement way of thinking to break out of this?  What does a
thin
> UI feel like?  How does code that now seems like an extension of the UI
begin to
> feel like a part of the internal process instead?
> Any tips?  Links?  Books?

Yeah. All 3.

--
  Phlip
    http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

 
 
 

XP makes randomness safer than clockwork [Was: Break out of]

Post by Jeremy Dunc » Thu, 17 Jul 2003 14:44:27



>Guys,

>At a recent XP meeting, they asked if so many constraints on code production
>make changing large subsystems - the answer is nothing speeds change like
>never not changing anything else.

>So if a colleague asks a question, you only change a test to answer it.

>Like a haiku detector set loose on your bedroom floor, this sucks up bugs.

>International penpals, these things constrain.

>Constraints produce a phase space, with vectors. We only need flatten the
>floor; a solid layer of continualy passing tests.

>They align on better code. Via change.

I'm just sure that meant something, but I'm not squinting at it right.

<snip>

Quote:>Is your GUI already thin in the stories?

>If its thick, your tests must reach in from the GUI Layer. That's not the
>nail then - it's the hammer.

Wha?

<snip>
Got any of that green cheese?

*ponder*

 
 
 

XP makes randomness safer than clockwork [Was: Break out of]

Post by Phli » Fri, 18 Jul 2003 04:34:21


Quote:> I'm just sure that meant something, but I'm not squinting at it right.

Sorry. I have practicing being careful and lucid for a while, so what
I really think accidentally pops out some times, unedited.

I promise not to let it happen again.

--
  Phlip
                http://www.greencheese.org/YaAw
  --  To catch a bug, you'v got to learn to think like a bug  --

 
 
 

1. am I going to break OLE?

  I posted this question before, but I think it got lost in the mail.

  I would like to write a little program that would take the place of an
executable so that my program would get executed when someone tried to
run the original one.  My little wrapper would then decide whether or not
to let the original program run.  I would be replacing the actual
executable on disk.
  However I don't know how well this strategy would work in the face of
OLE - that is, when a program tries to use the one I've replaced.  For
example, suppose I have an Excel spreadsheet in a Word document.  If I
try to edit the spreadsheet, Word will try to activate Excel but it'll
get my little wrapper program instead.  Is this bad?  I mean, if my
wrapper ran the real Excel as soon as it could, would Word have a
problem?
  I just don't know enough about exactly how OLE works.
  If this strategy could pose a problem, does anybody know of a way
that when my program got executed I could give Word the HINST for
Excel instead of for my wrapper?  Or maybe I could pass every message
I got down to Excel?
                                                Kim

BTW, this isn't a lame idea for some kind of virus; it's for
copy-protection.  My wrapper would check to make sure a site-license
is available for the program being run.  The reason I need to do
this wrapper is because I can only implement this from a file
server, and it has to support queueing (waiting in line for the next
available site-license).

2. how to improve Win2k performance

3. XP service pack 1 breaking things?

4. afs write on close

5. Office XP SP2 - Broken mapi application

6. Any problems with Expansys Hitachi CF cards?

7. IDragSourceHelper broken on XP?

8. need hypercube timing

9. DDE broken in Windows XP?

10. Can't break out of a loop under XP

11. DDE from Explorer broken in Windows XP?

12. Large data breaks socket on XP, what is this?

13. IDragSourceHelper Broken on XP?