Hello Keith,


KF> The reason I'm writing is because I'm still having trouble "getting"
KF> what application development looks like when using Squeak.  I understand

You have hit on an issue that's also very important to me. I'm using
squeak when time permits for one and a half years now and still
consider myself a novice.

I work quite different from you and my strengths are not so much on
the programming side but in understanding the application field.

KF> 1.  Create a directory in which I'll keep the files related to the new
KF> application.  There's a good chance that this directory will be near
KF> some other code that I use in the form of libraries).

Well yes, when I do this in squeak it means the necessary squeak files
and a full image plus the tools I use for development.

KF> 2. Create a sub-directory in which I'll keep unit tests using some sort
KF> of unit test framework like JUnit.

Everything in the image, just different categories, like you see in
3.8 image which in many cases nicely lines up "my category tests"
under "my category". I've adopted this.

KF> 3.  I'll "write the tests first"
Well, I'm not an educated programmer, so I don't (blush).

KF> 4.  I'll write some code for my application, probably driving a "spike"
KF> through it's functionality in order to get at least one test to pass.

I create some objects and some functionality to have some rudimentary
application as fast as possible. Then I "grow" this application while
it is running. This is a thing I could not do before Squeak. In Squeak
I am in my first "commercial" project, an inhouse quality analysis
tool operating on a mysql database at one of my customers.

Functionality is added in real small increments (long before I heard
of XP) and used at once.

KF> 5. I'll run my tests.  This involves starting the application from a
KF> known state (no objects instanced yet, for example), starting some
KF> portion of the
KF> application and running it.
This is the big advantage of Squeak (image based development to be
more precise). In Lisp (my main source of bread and butter) I just
recompile a single function (two keypresses) and as I'm in the
interpreter all other data is sill alive and I only have to start the
relevant dialogue where the function to test is hopefully not nested
several buttons or subdialogues later.

In Delphi / C Assembler it's the usual horror: Set a breakpoint.
Compile the changed file, relink and fire up the app (one button in
the IDE). Connect to the database. Select the product whose quality I
want to check. Select the test I want to perform on the data, set
some options .... What the heck did I want to test???

In squeak the dialogue with all settings is already open. I accept the
change in the browser and press the button in the dialogue. Sometimes
the customer stands behind me during this (still gives me the creeps).
In former environments I sent the guy away for half an hour and
when I was ready to show him, he was (naturally) busy with something
else.

KF> 5. Once I've got *something* to work, I'll check all of the code in my
KF> working directory into some sort of Source control system (probably
KF> Subversion) and continue to write code, checking.

Squeak has Monticello for this, I can live without it as I'm
developing alone. From the list I get the impression that it doesn't
scale well, the people preparing the next image seem to have serious
performance problems.

KF> 6.  I'll periodically run my application to see how its working from a
KF> user perspective.  Generally that application starts from a known state
KF> and at a known entry point.  The start up state may differ slightly
KF> based on saved information.

Every now and then I file all sourcecode into a fresh image to make
sure that I didn't do something that depends on my interactively
creating some objects. I don't think this is necessary and still is a
relic from having to be able to compile some source and start a
program with a well defined entry point.

Actually I believe in Squeak it doesn't matter how objects are
created. You deploy an image which contains all necessary objects and
you don't need a single entry point which will set up everything ready
to use. I still believe such things are useful for migrating to a
future version of Squeak.

For the current project I provide a button for the customer which
saves the image and quits so he can continue exactly where he left.
This was not easy in other languages and I will see if people use it.

KF> 7. Eventually, I'll be done and I'll deploy the application.  Generally
KF> I'll use some tool (Ant build files, Python setup files) to build the
KF> release.  I'll generally test the deployed release in a "fresh" 
KF> environment to duplication a potential user's experience.

As far as I know this is located somewhere between impossible and "you
need a deep knowledge of the system". As well as getting previous but
abandoned attempts to work again in a current image. No tool around to
help with this.

I'd love to be corrected here but this is one of two big points which
may still prevent me from making squeak the tool to earn my money
with. The other one is printing. Well, the lack of it.

KF> discussions or documentation.  As I said, I've gotten hints about much
KF> of the above but I'm trying to synthesis it into the whole "story".

Let's hope this leads to a story or recipe. AFAIK the only place where
Squeak is "deployment ready" is Seaside.

Cheers

Herbert                            mailto:herbertkoenig at gmx.net