What does Squeak application development look like?

Keith Fieldhouse keith at rexmere.com
Thu Dec 8 14:16:31 UTC 2005


Hi Folks,

I've been lurking on this list for a couple of years now, and greatly 
enjoy following the discussion.  I occasionally fire up a Squeak image 
and mess around a bit but for various reasons (most having to do with 
having a chance to experiment with Seaside) I'm going to try to get a 
little bit more serious about things.

I'm a professional software developer who uses C/C++, Java, Python and 
Lua on and ongoing basis (and a handful of other languages 
intermittently).  The most fun I ever had as a developer was writing 
code for the Apple Newton.  I also write the occasional freelance 
article.  This is all by way of showing that I've got a reasonably 
eclectic background to draw from.

The reason I'm writing is because I'm still having trouble "getting" 
what application development looks like when using Squeak.  I understand 
the Smalltalk language reasonably well.  I love the rich set of tools 
and browser based development (my first exposure to a browser was 
MacBrowse along with MacApp development -- Squeak's mouse logo reminds 
me a bit of the kitten on MacBrowse's splash screen).  I also understand 
that image based development is fundamentally different than file based 
development as it exists with most languages and I can see the possible 
advantages.  What I still can't quite understand is what an application 
development cycle looks like from idea to distributable application.  
I'm hoping that this message will start a discussion that will help me 
(and perhaps others).

Here's what I think of when I consider application development in other 
environments.  I'm hoping to get an idea of what the Squeak version of 
these concepts are.  I understand that in some cases, the reply will 
essentially say "We don't do that because we do this..." but I'm trying 
to relate Squeak development to what I already know.  I also suspect 
that I'm trying to tease out information that many of you no longer 
think twice about. 

I should point out that in some cases below, I *do* know, or have an 
inkling of the Squeak way but I'm not particularly confidant of any of 
my understanding yet.

So, when I start an application in another language I:

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

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

3.  I'll "write the tests first"

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

5. I'll run my tests.  This involves starting the application from a 
known state (no objects instanced yet, for example), starting some 
portion of the
application and running it.  

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

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

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

8.  I'll go on to the next application.

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".

Best regards and thank you for your time,

Keith Fieldhouse



More information about the Squeak-dev mailing list