What does Squeak application development look like?

news.gmane.org mr.d.poon at gmail.com
Sun Dec 11 01:32:15 UTC 2005


Hi Keith.

 From the sound of you post, you are well versed in TDD. For some more 
insight in working in Squeak and Smalltalk in general, have a look at 
the original XP rules on the C3 project 
(http://www.xprogramming.com/Practices/xpractices.htm), especially the 
ones about the Smalltalk development environment, i.e.

	Do it in an inspector
	No, do it in a workspace
	No, do it in an object
	Just set the halt (see below)
	Let Smalltalk tell you (see below)

They will give you some ideas about how to leverage image based 
development. These rules also give hints as to how TDD came about.

Cheers

Daniel

<<*Don’t Think, Just Set the Halt*

     /When partnering with Kent Beck, most everyone has this experience:/

     Something goes wrong. The code doesn’t work. You start to think: 
"What could cause that to happen?" Kent doesn’t think about what the 
problem is. He just sets a halt in the system and lets Smalltalk tell 
him what the problem is.

     Sometimes you’re right about what the problem is. If you’re really 
quick you’ll be able to tell Kent what to edit in the window he’s 
already looking at. If you’re really quick.

     Sometimes you’re not right about what the problem is. Forget it, he 
has already fixed it.

     Train yourself to think about where to put the halt, not to think 
about what the problem is. Of course it’s a great feeling when you can 
reason to the problem. But we’re not here to make our brains feel good, 
we’re here to get the code working as quickly as possible. Setting the 
halt and letting Smalltalk tell you will help you build working code 
faster.>>

<<*Let Smalltalk Tell You*

Here’s another guideline that is very easy to forget, but very 
important. The general notion is that Smalltalk is very good at 
incrementally changing things, breakpointing, and checking values. 
Instead of wasting time thinking about what to do, or theorizing about 
what went wrong, just ask Smalltalk. Here are some examples:

     * To work out some new capability, inspect an object, browse the 
class if you need to, then send the object messages, building the code 
you need right in the Inspector workspace. Then copy the code to an 
appropriate method.
     * When working on a new feature, don’t implement all the necessary 
methods on all the objects you use. Instead, wait for the walkback for a 
method you haven’t defined. Then go to the browser, implement the 
method, and proceed from the walkback. (Kent calls this "just-in-time 
programming".) Smalltalk is keeping track of the order in which you need 
to do things.
     * When the system breaks, don’t theorize: put in a breakpoint and 
step through the code until you see what is wrong. You’ll find the 
answer much faster.>>



Keith Fieldhouse wrote:
> 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