Keith Fieldhouse wrote:
> 
> So, given the above framework of a developer's day, what would the
> corresponding day look like with Squeak?  Feel free to point me to other
> discussions or documentation.  As I said, I've gotten hints about much
> of the above but I'm trying to synthesis it into the whole "story".

Here's what I do. [Aside. Before Monticello (MC), I used to use
file-outs (.st) and changesets (.cs). There may still be reasons to
use .st and .cs, but MC lets you easily browse and compare with old
versions, amongst many other advantages.]

1. Choose an initial image - e.g. 3.8 basic or full, or 3.9 alpha.

2. Setup a base developer image as follows. Start the initial image,
load in the desired development environment, and save the image to a
different name.

I actually do something slightly different since I've just started
using Monticello Configurations (MCC). I start with Squeak3.8-6665,
and load Monticello Configurations (MCC) and save image as R3.8-MCC.image.
Then I start the R3.8-MCC.image, load Connectors(1.9) and FastSocketStream,
which are non-MC packages. Then I use a MCC file which loads KomHttpServer,
Seaside and ShoreComponents. I save the image as dev-base.image.

3. Code in a work image. Start the dev-base image and save as work1.image.
Use another MCC file to load my application packages. Code away,
using TDD and Spikes (a.k.a. Smalltalk development style). TDD is
test-driven development. Spikes are architectual spikes from the
XP terminology. Often there are more spikes than tests :(, oh well.
Save the image frequently, especially just before testing some new
functionality. At end of day, open an MC browser on my MCC configuration.
Update it from the image to refer to any newer MC versions I've created
during the day. Then save it under a new name. If you're working in
a group, you may have to check for and load newer versions from the
repository during the day.

4. Verify in a test image. Start the dev-base image and save as test.image.
Use the application MCC file to load all my packages. Run various
automated and manual tests.

5. Deploy an image. I've not deployed yet, but what I'd do here
is copy my test image from step 4 (before the tests are run) to
the deployment environment, then configure and start it. You might
want to build a deployment image without the test, and then run
some sanity checks before deploying.

6. Continue development. Every once in a while I re-build my work
image by starting the dev-base image, loading my packages through
the MCC file, and saving the image as work2.image.

====

Working with Monticello packages. Since the class category is
the package name, when using Monticello, it's good to choose
a good application name early. You can change it later, but it'll
be harder to follow the history.

If my application is called Super-duper Foobar Thingy, then
I'll called the package/class-category Foobar. It's good to
have a short distinctive name. If it's short enough, you can
even use it for class name prefixes. Mostly, class name prefixes
are two-characters uppercase, so there's bound to be name collisions
soon. If the application gets complicated, I split it up into
multiple categories - e.g. Foobar-partOne, Foobar-partTwo, etc.
MC will still package this as a single Foobar package.

The Seaside components and anything tightly coupled to it,
I put in a separate package called FoobarUI.

The SUnit tests, I put in a package called FoobarTest.
I don't have any FoobarUI tests though. I manually test
the application, for now.

Hope that helps.
-- 
Yanni Chiu