Has anyone read this:
http://martinfowler.com/eaaDev/ModelViewPresenter.html

This would make a good topic for a chalk talk.

-s

Seems many folks aren't available.  Wednesday and Thursday are out
as well.  Can anyone suggest another day, or should it be another
week?

-s

I have family in town for spring break so I probably will not make
it either...



--- In BellwareNET@yahoogroups.com, "p" <meny34@e...> wrote:
> It's possible I'll be able to make it but it's less than 50% at
this point.  I've got guests in for SXSW and it would be kind of
> tough to break away to talk business.
>
>   _____
>
> From: Jeffrey Palermo [mailto:jeffrey@p...]
> Sent: Thursday, March 17, 2005 2:20 PM
> To: BellwareNET@yahoogroups.com
> Subject: [BellwareNET] Re: Meeting - March 21st
>
>
>
> --- In BellwareNET@yahoogroups.com, "Scott Bellware"
<sbellware@h...>
> wrote:
> > How about 5:00?
>
>
> 5PM is good for me.  Are we going to be the only ones there?
>
> Jeff
>
>
>
>
>
> Yahoo! Groups Sponsor
>
> ADVERTISEMENT
>
>
<http://us.ard.yahoo.com/SIG=129di4cdm/M=298184.6191685.7192823.30011
76/D=groups/S=1705007709:HM/EXP=1111177236/A=2593423/R=0/SIG=11
> el9gslf/*http://www.netflix.com/Default?mqso=60190075> click here

>   <http://us.adserver.yahoo.com/l?
M=298184.6191685.7192823.3001176/D=groups/S=:HM/A=2593423/rand=887835
425>
>
>   _____
>
> Yahoo! Groups Links
>
>
> * To visit your group on the web, go to:
> http://groups.yahoo.com/group/BellwareNET/
>
>
> * To unsubscribe from this group, send an email to:
> BellwareNET-unsubscribe@yahoogroups.com <mailto:BellwareNET-
unsubscribe@yahoogroups.com?subject=Unsubscribe>
>
>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .

--- In BellwareNET@yahoogroups.com, "Scott Bellware" <sbellware@h...>
wrote:
> How about 5:00?


5PM is good for me.  Are we going to be the only ones there?

Jeff

How about 5:00?

That will be good for me.  It will need to be as early as possible
because I need to be out by 7PM.

Best regards,
Jeffrey Palermo


--- In BellwareNET@yahoogroups.com, "Scott Bellware" <sbellware@h...>
wrote:
>
> Folks,
>
> How does a meeting in the evening on Monday, 21st sound?
>
> -s

Folks,

How does a meeting in the evening on Monday, 21st sound?

-s

In another thread, Jeffrey Palmero asks:

"Will you enable RSS for this Yahoo group so I can aggregate it?"

Since the archive is not public, Yahoo does not provide the RSS
feature.  Which will proaly beg the question... why not make it
pulic?  I'm not really sure that this group should be public.  Not
everyone is comfortable asking questions in public fora.  I'd rather
optimize for the possilities of freedom of expression versus
suscription facility.  Since all messages are tagged with the group
name, a filter might be an appropriate means of solving inbox
clutter if you're not using a provider like Hotmail that will
automatically filter this stuff.

-s

> > A business object should know nothing at all about the
mechanisms
> > that allow it to be retrieved from persistent storage.  When you
> > test drive the development of a business object, you're
designing
> > and constructing code just the business logic... no data
access.
> > Any data access that might be emedded in the business logic
would
> be
> > done by stubbing or mocking the data layer.
>
> Yeah, I know, but I'm not to the point of using a persistance
> framework yet.  Right now, there are sproc names in my code.  I
was
> using the DAAB as my DAL, but I have to specify what sproc will
get
> the information somewhere.  My business object calls my DAL
(DAAB),
> so where else can I specify the sproc name?

Outside of the business object.

When I said oject-to-relational mapping, I wans't talking about
object-relational tools, I was really talking about
object/relational architectures - like the one you're using.  Any
time you have business objects and databases you have object-
relational mapping.  Whether use use a third-party tool is a
completely different footall.  You may one day use a tool to support
object persistence, but it's not alwasy necessary, a requirement, or
possible.

The one common aspect of object-to-relational data access is that
the specification of how the object is saved is the domain of
resources external to the business object - maybe not the business
object library, or _domain_ library, but not part part of the
business object.

You can do the same thing without a framework, just have the mapping
specification (stored proc names) in classes or structs or whatever
that are external to the business object itself.  You can find the
mapping specification you need for a given instance of an object
through reflection - either by a Hashtable indexed on business
object types (System.Type instances), or by string names of types,
you could derive the name of the mapping class for a business ased
on a naming convention and Activation based on a string, or you
could do it through .NET config files.  I bet you could come up with
a few more ways as well.

So when you ask for an instance of a given type from your DAL for a
given ID, it finds the map class (with the stored proc names, and
even more if you want... params, etc) for the type, does the DAAB
work, and returns a sustantiated instance of the the type.

This is a it elaborate in that it starts to go down the road to a
bit of data access automation, but it ain't so far down the road
that it would take more than a day or so to implement.

Anyway, you don't really need the automation, but it's just a "for
example"

In Domain-driven Design, Eric Evans talks about Repository objects
which act as the data gateway for business objects.  This is a great
book to get into.

> A business object should know nothing at all about the mechanisms
> that allow it to be retrieved from persistent storage.  When you
> test drive the development of a business object, you're designing
> and constructing code just the business logic... no data access.
> Any data access that might be emedded in the business logic would
be
> done by stubbing or mocking the data layer.

Yeah, I know, but I'm not to the point of using a persistance
framework yet.  Right now, there are sproc names in my code.  I was
using the DAAB as my DAL, but I have to specify what sproc will get
the information somewhere.  My business object calls my DAL (DAAB),
so where else can I specify the sproc name?

In my demonstration, I ended up just writing a new class with two
members, and the requirements were that these members needed to
support setting and changing (two properties).  Very simple, but it
got the point across.  There wasn't much time in that hour for
anything else because we had good discussion (and some apprehension).

Best regards,
Jeffrey Palermo

A workshop attendee asked:

"I found an article on April 2004 MSDN Mag on code coverage. Do you
use Clover.NET for code coverage? Are there any other good ones?"

I have Clover .NET.  It's a really good product.  I use clover
mostly as a matter of curiosity, and because I was given a free
license.  You really _need_ coverage tools if you're not doing TDD.
It's all about an once of prevension.  Coverage analysis is the
closing of the arn door once the horses have torn off into the
night.  Test coverage is like radiation therapy after years of
ignoring all the cancer warnings on cigarette packages.  In the end,
which do you think is more conducive to life?

I asked about the relevance of test coverage to TDD community on the
TDD message board at yahoo a couple of weeks ago suspecting that
coverage was really only relevant to non-TDD teams and efforts.  The
over-whelming response confirmed my thoughts ... if your never write
a line of code without first writing a (failing) test for the code,
how could you introduce code that isn't covered?

Ron Jeffries added that code coverage is only valuable to make sure
that nothing "flickered", ie: no aberrational sudden drops in the
high coverage that you'd expect from TDD.

-s

Jeffrey Palermo wrote:

> I started from scratch writing a business object that
> would be tightly-coupled to the table used to persist it.
> My class knows which sproc is used to retrieve a row from
> the database, so it calls the DAAB Database class's
> ExecuteReader method to get the result.

You're using a loose coupling design methodology to achieve high
coupling between a business layer and a data layer.  I think you
might be a bit off course ... :)

A business object should know nothing at all about the mechanisms
that allow it to be retrieved from persistent storage.  When you
test drive the development of a business object, you're designing
and constructing code just the business logic... no data access.
Any data access that might be emedded in the business logic would be
done by stubbing or mocking the data layer.

The thing that you're about to present as an example of TDD is the
thing that TDD aims to get rid of.  Why would the business object
have information about itself that isn't useful in it's own native
habitat, but only usefull once that object was used in the data
access layer.  What would happen to the business object definition
if we kept information in it regarding how it is used by all other
comnponents and layers in the system.  It would soon turn into a
huge, unreadable mess.  Readability is also one of the things we're
after.

Data access isn't the most obvious thing to demonstrate TDD with.
Business logic on business objects is a much better place to start.
Nonetheless, if your business ojects have knowledge of the stored
procs that are used to retrieve them, then you've got a bit of a
design smell.  Might be a better choice to remove the object-to-
relational mapping info - in your case the stored procedure name -
to a separate class.

-s

Thanks, Scott.  I've posted to my blog about what I'm doing.  Today
I'm giving a presentation to my team on TDD, and I wanted some good
samples, so I started from scratch writing a business object that
would be tightly-coupled to the table used to persist it.  My class
knows which sproc is used to retrieve a row from the database, so it
calls the DAAB Database class's ExecuteReader method to get the
result.

I've solved my problems by stubbing what I needed.  I derived from
Database and then overrode the method I needed to control.  It didn't
have an interface.  Then I stubbed out IDataReader.  That approach is
a lot simpler than NMock.

This is just demo code, so I didn't want a lot of clutter getting in
the way.  For an actual project using the DAAB, we'll create a DAL
and extend it.  We'll still need to develop the DAL test-first,
though, so I don't think I'm wasting my time with this.  I'm quickly
learning how to do it faster and faster.

My sample was just to demonstrate TDD quickly, not to demonstrate
DAAB best practice.  Thanks for the advice, Scott.  I'll probably do
it that way.

Will you enable RSS for this Yahoo group so I can aggregate it?

Best regards,
Jeffrey Palermo

Jeffrey Palermo wrote:

> I'm having a hard time decoupling my unit test.

To wit... it's not the unit test that needs to be decoupled.  You
want to stub or mock the dependencies of the component you're
testing/designing.

I should have spent more time reading your post.

-s

This is an obvious question, but it just occurred to me to ask...
Are you trying to do TDD with code that already exists, or are you
designing new code from the client?

Also, my other answer is only half-cooked now that I think about
it.  A design where you had an intermediary between your business
layer and the data access goo occurs to me because that's usually
what comes of it.  But to start from that assumption surely isn't
TDD.

If you start at the client (the test) and drive from there, the
design that you need to support the client will become clear.

However, if you're really just test driving the data access calls to
verify that the DAAB is actually CRUDing to the database correctly,
then I don't think you should mock or stub anything - because you
really need to verify that your data access code really does the
right stuff with the database.  This approach is actually all over
Jim's book.

At some point, you're gonna need to go beyond mock and actually
execute commands against the database.  Is that where you are?  Are
you writing data access logic, or buiness logic?  Building a mock or
a stub to represent the thing that you're testing basically gets you
into a position where you're not really testing anything.

However, if you're doing TDD against the buisiness layer, and that
layer has a dependency on another component - the data access
component for example - then you should mock or stub that
component.  This stub interface will become clear as you develop the
business layer, not as you develop the data access layer.  It's not
the data layer that needs the intermediary interface, it's the
business layer.

-s

Jeffrey Palermo wrote:
>
> I'm working up a small sample to teach my team TDD with NUnit, and
> all I'm trying to do is use the enterprise library's data access
> block.  It's a great block, but they didn't code to an interface,
so
> I'm having a really hard time testing my method that consumes it.
>
> I can't stub out the interface, and the methods aren't virtual, so
I
> can't use NMock.  I'm having a hard time decoupling my unit test.
> Any advice?

EntLib's DAAB is the low-level stuff that talks to the data API.
Not such a hot idea to have you're applicaiton logic able to talk to
the DAAB anyway.  By building a data access interface, you not only
isolate the DAAB, but you also create an interface that you can stub
or mock.  You'd have one concrete implementation for the real DAAB,
and another for the fake.

Jeffrey Palermo wrote:

> No, I wouldn't want to put it in the contructor because then I
> couldn't prevent it from running, and then it throws and
exception,
> and my unit test is toast.

I guess I'm not following the specific case you have in mind.  Could
you be more explicit about the issue of instantiating something and
the instantiation causing an exception?  Is this due to some
framework mechanism that has to be initialized in a specific
sequence?  If it caused an exception in a text fixture, wouldn't it
always cause the exception, and wouldn't that be something you'd
want to have fail a test (at least till you got it fixed)?

I'm working up a small sample to teach my team TDD with NUnit, and
all I'm trying to do is use the enterprise library's data access
block.  It's a great block, but they didn't code to an interface, so
I'm having a really hard time testing my method that consumes it.

I can't stub out the interface, and the methods aren't virtual, so I
can't use NMock.  I'm having a hard time decoupling my unit test.
Any advice?

Best regards,
Jeffrey Palermo

No, I wouldn't want to put it in the contructor because then I
couldn't prevent it from running, and then it throws and exception,
and my unit test is toast.

Best regards,
Jeffrey Palermo

--- In BellwareNET@yahoogroups.com, "Scott Bellware" <sbellware@h...>
wrote:
>
> Jeffrey Palermo wrote:
> >
> > Another option that I like for the below code is:
> > public class StubHttpContext : IHttpContext
> > {
> >    private Hashtable cache; // changed this: = new Hashtable();
> >
> >    public IEnumberable Cache
> >    {
> >        get {
> >             // my code
> >             if(cache == null) cache = new Hashtable();
> >             // my code
> >             return this.cache;}
> >    }
> >
> >    public SetCache(Hashtable cache)
> >    {
> >        this.cache = cache;
> >    }
> > }
> >
> > This doesn't make sense for a Hashtable, but if it's not a
> Hashtable
> > but an object of your framework that requires something to happen
> > before it is created, then it may error if it tries to start up
> > automatically.  If you can set it with a stub or mock object
> first,
> > then your framework object will not have to be new(ed) up (and
> > possibly throw an exception).
>
> ... Would that be more of a justification for putting the
> initialization in a ctor?

Jeffrey Palermo wrote:
>
> Another option that I like for the below code is:
> public class StubHttpContext : IHttpContext
> {
>    private Hashtable cache; // changed this: = new Hashtable();
>
>    public IEnumberable Cache
>    {
>        get {
>             // my code
>             if(cache == null) cache = new Hashtable();
>             // my code
>             return this.cache;}
>    }
>
>    public SetCache(Hashtable cache)
>    {
>        this.cache = cache;
>    }
> }
>
> This doesn't make sense for a Hashtable, but if it's not a
Hashtable
> but an object of your framework that requires something to happen
> before it is created, then it may error if it tries to start up
> automatically.  If you can set it with a stub or mock object
first,
> then your framework object will not have to be new(ed) up (and
> possibly throw an exception).

... Would that be more of a justification for putting the
initialization in a ctor?

Another option that I like for the below code is:
public class StubHttpContext : IHttpContext
{
    private Hashtable cache; // changed this: = new Hashtable();

    public IEnumberable Cache
    {
        get {
             // my code
             if(cache == null) cache = new Hashtable();
             // my code
             return this.cache;}
    }

    public SetCache(Hashtable cache)
    {
        this.cache = cache;
    }
}

This doesn't make sense for a Hashtable, but if it's not a Hashtable
but an object of your framework that requires something to happen
before it is created, then it may error if it tries to start up
automatically.  If you can set it with a stub or mock object first,
then your framework object will not have to be new(ed) up (and
possibly throw an exception).

Best regards,
Jeffrey Palermo

As I was falling asleep, it occurred to me that there's another way
to mitigate this problem… You could pass whatever the business logic
needs from the framework into the business logic, rather than have
the business logic call out for it.  This is a really, really simple
way of describing Dependency Injection:

http://www.martinfowler.com/articles/injection.html

I have yet to get beyond the halfway point in this article and not
find my head swimming.  However, when you get to the part about the
Spring framework, know that there is an implementation of Spring
for .NET in the works as well:

http://www.springframework.net/

(This would be a great topic for a meeting)


-s

I got this question via email from one of the people that was at teh
workshop:

"We are using a framework that other team developed, which gives our
website the same look and feel with the overall company look. Our
business layer is calling some methods in the framework, which is
getting some parameters from the querystring. So when I run the test
case against the method in our business layer object, it fails,
because it does not have httpcontext with NUnit. We have a
dependency on other apps."

This is a quintessential problem than TDD aims to solve!  You
couldn't have picked a better question!

You need to break all of the dependencies that your business layer
has on the framework.  That doesn't mean that the business layer
won't be able to use the framework, but it does mean that your
business logic needs to be loosely coupled to the framework.  You
need to do this for the obvious reason that the UI framework uses
the HttpContext.  This is a UI layer object.  Your business logic
should have no dependency whatsoever of things in the UI layer -
directly, or indirectly (by calling into the framework's methods).
Otherwise, as you've found out, when you take the business logic out
of the production context to test it in isolation, the business
logic simply won't work.  So, your business logic really isn't an
independent layer at the moment, it's more-or-less part of the UI
layer (since it can't work in isolation).

Every place your business logic calls into the framework, you need
to be calling either an interface, or an intermediary object.  A
good framework is made up of concrete classes that implement
interfaces.  This allows clients of the framework to plug in
implementations.  For example, the
System.Data.SqlClient.SqlDataAdapter implements the IDataAdapter
interface.  If it didn't, I wouldn't be able write generic data
access code that could also use the OleDbDataAdapter and the
OracleDataAdapter.  By typing my references to the interfaces rather
than to the concrete type, I can vary the concrete type that I want
to use (if, of course, I needed my data access layer to work with
multiple database types, like SQL, Oracle, etc).

For example:

IDataAdapter dataAdapter = new SqlDataAdapter();
dataAdapter = new OracleDataAdapter();

The above code really doesn't make practical sense, but it
demonstrates the ability to vary the dynamic type of the reference
(SqlDataAdapter, or OracleDataAdapter) as long as the static type
(IDataAdapter) is implemented by both of the concrete data adapter
classes.

You need to accomplish the same thing with the UI framework you're
working with.  Of course, if the framework classes you're working
with don't implement interfaces that are also part of the framework,
you're not going to be able to do this.  Instead, you'll likely need
to create an Adapter for the framework and call it rather than the
actual framework.

The point is, that you need a fake version of the UI framework when
unit testing the business layer, and the real framework when you're
doing system testing, or when the business layer is in production.
This is the essence of unit testing code that has external
dependencies.

If in your case the framework wasn't designed with loose coupling
and testability in mind (and it's very possible that it wasn't
unless it was built using Test-Driven Development, or some
extraordinarily fine framework design skills), then it likely won't
offer you any interfaces that you could plug fake objects into.  If
it did, then you should be able to tell the framework which
HttpContext you'd like to use.  Instead of defaulting to
System.Web.HttpContext, the framework would have provided a custom
wrapper for the HttpContext that implemented a custom interface.

For example, the framework code might have:

public IHttpContext
{
     IEnumberable Cache
     {
         get;
     }
}

public class HttpContextImpl : IHttpContext
{
     public IEnumberable Cache
     {
         get {return HttpContext.Current.Cache;}
     }
}

So if your business logic depended on the cache object in the UI
framework, you'd be out of luck, because the cache object in the
above example is the cache object from the live HttpContext.  And as
you know, it won't be available when unit testing the business logic.

If the framework was built with loose-coupling and testability in
mind, you could specify the implementation of the IHttpContext that
you wanted to use when you make use of the framework rather than the
framework always defaulting to the live HttpContext.Current.

For unit testing, we usually create what are called "stubs".  Stubs
are fake versions of real objects that we use in place of real
objects when the real objects aren't available - as the
HttpContext.Current is not available in isolated unit testing of the
business layer.

So essentially, you'd create a HttpContextStub class that would
stand in for the real HttpContext, and you'd use it during your unit
testing.

I'm going to over-simplify this next bit drastically just to show
you what I'm talking about…

If you could configure the framework's HttpContext implementation by
saying:

Famework.HttpContext = new HttpContextStub();

Then you'd have just re-routed all of the frameworks calls to
HttpContext.Current to your own IHttpContext implementation.  Your
implementation might look like:

public class StubHttpContext : IHttpContext
{
     private Hashtable cache = new Hashtable();

     public IEnumberable Cache
     {
         get {return this.cache;}
     }

     public SetCache(Hashtable cache)
     {
         this.cache = cache;
     }
}

Which means every time the framework refers to the
HttpContent.Current.Cache, it's actually referring to the Hashtable
instance called cache.  So now that you've got control of the cache,
you can load it up with what ever you want in the setup code of your
unit test:

[TestFixture]
public class ShoppingCartFixture
{
     [SetUp]
     public void SetUp()
     {
         ShoppingCart cart = new ShoppingCart();
         cart.Add(new Item(10m));

         Hashtable cache = new Hashtable();
         cache["Cart"] = cart;

         IHttpContext content = new StubHttpContext();
         context.Cache = cache;

         Framework.HttpContext = context;
     }

     [Test]
     public void Cart()
     {
         Assert.AreEqual( … );
     }
}

The above example isn't meant to be real-world, it's only intended
to show how to attain loose coupling and testability.  By the way,
in the real word in production, you would likely specify the
framework's cache implementation through XML configuration files,
not through a property - like you can specify many of the .NET
bindings through XML configuration.  You'll find that the deeper you
get into TDD and loose coupling, the more the design of .NET
framework itself will begin to make sense.

So let's say that the framework developers at your company didn't
build your company's framework with loose coupling in mind.  Then,
you'd need to isolate all of the calls to the framework by wrapping
the framework.  In this case, the following code would be your code,
none of it would be built by the framework coders in your company:

public IFrameworkAdapter
{
     IEnumberable Cache
     {
         get;
     }
}

public class FrameworkAdapter : IFrameworkAdapter
{
     public IEnumberable Cache
     {
         get {return Framework.Cache;}
     }
}

public class StubFrameworkAdapter : IFrameworkAdapter
{
     StubFramework framework = new StubFramework();

     public IEnumberable Cache
     {
         get {return this.framework.Cache;}
     }

     public SetCache(Hashtable cache)
     {
         this.cache = cache;
     }
}

public class StubFramework
{
     private Hashtable cache = new Hashtable();

     public IEnumberable Cache
     {
         get {return this.cache;}
     }

     public SetCache(Hashtable cache)
     {
         this.cache = cache;
     }
}

In your business code, you'd have to only use references to
IFramework adapter, just like the examples above with IDataAdapter.
During test, you would configure your business layer to use the
StubFrameworkAdapter, and in production, you'd configure it to use
the FrameworkAdapter.

This last bit about the adapters needs more thinking through.  It's
3:30 AM, and I usually stop making sense around 2:00 AM, so take it
with a grain of salt.  Other's in the group can probably punch holes
in it.  I'm not to sure of the adapter implementation, so please go
easy.

An alternative to stubs is Mock Objects.  There's a really good
article at:
http://msdn.microsoft.com/msdnmag/issues/04/10/NMock/default.aspx

-s

"bt42929" wrote:
> I would imagine more than 20 minutes - how much do we
> want to do in a typical meeting?

My personal feeling is that very little can happen in less than an
hour.  Optimally, I think an hour and a half is ideal - but I might
have more stamina.  My 2 cents.

I would imagine more than 20 minutes - how much do we want to do in
a typical meeting?  I don't know what sounds best for others, but it
seems like driving 40 minutes for a 20 minute meeting would be
hard.  I usually take short lunches so that wouldn't be easy for
me.  I don't mind having meetings in the evening, but realize other
folks are busy.  I live off 360 by the Arboretum, and work by
Highland mall, so I would never be more than 15 minutes from
Triangle.  That said, I can pretty much meet when others can if I
take a normal lunch.

This begs the question... how long will the meetings last?

For me the best meeting times would be lunches.  I can do just about
any lunch day.  I'm at Parmer and I-35 (Dell), so it would take 20
minutes to get over there.  No problem.  Meeting after work would be
a problem because I already have several things going in evenings
(one of the them being the .Net user group).  Another is a weekly
bible study.

I started this past week and implemented a performance counter on an
existing windows service using NUnit, and it was really easy!  I do
have some hang-ups when it comes to using configuration, network
shares, databases, and existing code frameworks that were not
developed to be testable.

Best regards,
Jeffrey Palermo



--- In BellwareNET@yahoogroups.com, "Scott Bellware"
<sbellware@h...> wrote:
>
> Hi folks,
>
> For anyone who wants some more questions answered aout TDD, agile
> development, etc, I'd like to get together as a group and do a
round
> table discussion, do some white boarding, and maybe even some
coding
> on the projector.
>
> The place will be offices of Triangle Technology - which is on
> Capitol of Texas, aout two miles from the Microsoft offices.
>
> The date and time - well, that's what I need to know from you.
>
> What works?
>
> -s

At present, this group is named after my website.  That's not going
to work for the long term.  The group needs its own identity.  When
that happens, the name of this group will change, and the Yahoo
group will be renamed as well.  So give it some thought.

-s

Hi folks,

For anyone who wants some more questions answered aout TDD, agile
development, etc, I'd like to get together as a group and do a round
table discussion, do some white boarding, and maybe even some coding
on the projector.

The place will be offices of Triangle Technology - which is on
Capitol of Texas, aout two miles from the Microsoft offices.

The date and time - well, that's what I need to know from you.

What works?

-s