I cracked open an older image and checked the version I’d been using and started reading the commit comments for each version looking for clues. You can do this from SqueakSource but I usually just do it in Monticello directly. After a bit of digging I find in Scriptaculous-lr.232.mcz the information I’m looking for, namely…

- NOTE: SUElement>>#render: does not call #update: anymore, directly use #update:, #replace:, #insert:, and #wrap: now. These methods finally accept any renderable object (string, block, …) and also encode the contents correctly.

Seems Lukas changed the API to make things more intention revealing. A quick trip through the app looking for evaluators and changing #render: to #update: and everything started working again. Having made the necessary changes, and looking at the new code for a few minutes, I liked it and agree with API change.

What I want to point out is the importance of good commit comments (thanks Lukas) that allow those who use your frameworks to work out their problems. Commit comments are the best place to share your thoughts about why you changed something or decided to go in a particular direction because they are, or should be, the first thing a developer reads before loading a new version of that code.

I also what to point out the process itself. Being open source code, when things go wrong it’s often up to you to solve your own problems. Had I not found what I needed in the comments, I’d have started Googling and searching the archives of the Seaside-Dev list to see if anyone else had run into this issue. If that fails, then I’d post to Seaside-Dev asking for help.

There’s not a lot of documentation on Seaside and Scriptaculous in comparison to some other frameworks, but there’s plenty of help to be found with just a little bit of effort on your part to do your homework and a great community ready and willing to help you out when you need it. But always do your homework first, in case your question has been answered many times over.

It’s based on Damien Cassou’s latest Squeak Dev Image (Squeak 3.9.1), an awesome base image with all the necessary goodies a developer needs. This image is a bit smaller than previous ones because I’ve taken Glorp out since I’m not currently using it anymore. I’ve also dumped the windows native fonts and use different default fonts due to my working from both Windows and Linux these days.

rST (Remote Smalltalk) is now loaded because I plan on experimenting with it a bit. OSProcess is part of my default setup as well, on the Linux side, it’s quite useful.

Some of the tools I’ve come to rely on like Daemontools from Daniel Bernstein also show this appreciation of the Unix way, small simple reliable tools that just work and are configured easily with plain text files. The most recent versions of Apache have also broken up the monolithic httpd.config into much smaller simpler individual files spread out over various directories that greatly ease automation by keeping individual site settings in separate files and using simple symbolic links to enable or disable individual sites.

Inspired by the simplicity and ease of managing these tools, I decided my Smalltalk programs, while ungodly easy to write, were much too hard to configure and deploy because configuration was based either on code in the image or in the case of Seaside, its custom configuration system, neither of which are simple or easy to move around between images and servers. I also like how Ruby on Rails configuration system allows multiple configurations that you can easily switch between to run your code in your various environments.

Rather than trying to design some ultimate configuration system, I just looked at how I write and deploy *my* applications, which is always one image per application in its own directory (possibly launched multiple times on various ports) and decided the simplest thing that could possibly work for me was just a directory named config, in my image directory, with three subdirectories named prod, dev, and test, and a single file named config which tells me which config subdirectory is active.

So I’ll declare a configuration class…

Object subclass: #SSConfig
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'SentorsaSeaside-Configuration'

and a class side #create method to setup this structure on the filesystem…

create
    | configDir |
    configDir := (FileDirectory default directoryNamed: #config) assureExistence.
    FileStream
        forceNewFileNamed: (configDir fullNameFor: #config)
        do: [ : f | f nextPutAll: 'dev' ].
    (configDir directoryNamed: #prod) assureExistence.
    (configDir directoryNamed: #dev) assureExistence.
    (configDir directoryNamed: #test) assureExistence

Next, I want a simple dictionary style API, “SSConfig at: #someSetting”, so I’ll need the core class side method #at: which grabs the current configuration and uses the key you hand it to looks for the file name that matches, opening it in read only mode if it exists or simply creating it if it doesn’t.

at: aKey
	| currentConfig configDir value |
	currentConfig := FileStream
		readOnlyFileNamed: ((FileDirectory default directoryNamed: #config) fullNameFor: #config)
		do: [ : f | f contentsOfEntireFile ].
	configDir := (FileDirectory default directoryNamed: #config) directoryNamed: currentConfig.
	value := (configDir fileExists: aKey)
		ifTrue:
			[ FileStream
				readOnlyFileNamed: (configDir fullNameFor: aKey)
				do: [ : f | f contentsOfEntireFile ] ]
		ifFalse:
			[ FileStream
				forceNewFileNamed: (configDir fullNameFor: aKey)
				do: [ : f | f contentsOfEntireFile ] ].
	^ (value endsWith: Character lf asString)
		ifTrue: [ value allButLast ]
		ifFalse: [ value ]

Next I want to be able to ask for a value and provide a default in case there is no configured value, built simply upon the previous method…

at: aKey default: aValue
    ^(self at: aKey)
        ifEmpty: [ aValue ]
        ifNotEmptyDo: [ : it | it ]

I also want to be able to ask for a config value typed to a boolean (SSConfig can: #useBlaBla) for the common case of true/false settings, another simple method built upon #at:…

can: aKey
    ^(self at: aKey) = 'true'

And of course, having strings and booleans, I now want a couple of simple methods for asking for integers from config…

numAt: aKey
    ^(self at: aKey)
        ifEmpty: [ 0 ]
        ifNotEmptyDo: [ : it | it asInteger ]

numAt: aKey default: aValue
    ^(self at: aKey)
        ifEmpty: [ aValue ]
        ifNotEmptyDo: [ : it | it asInteger ]

These are all class side methods, and so far I’ve not found the need for anything more than strings, bools, and integers. If I do, I’ll extend it more, however, this seems to be all I need for all of my configuration needs thus far. It’s simple, every setting is its own file, and it allows me to easily switch between various configs and easily share configurations between various images with nothing more than a simple file copy. I can also easily edit the configuration from the shell, where I do most of my administration tasks.

NOTE: This method is not application aware, so it won’t work well if you run multiple applications within a single image, but I’m not writing code for use cases I don’t have and it works well for how I deploy my applications.

Some people use VNC to connect to their production image, fire up Monticello, and hot upgrade the code. Personally, I’ve never been able to get a stable version of VNC going, there are always issues, the latest being that the client is messed up by the nice Squeak UI Enhancements hiding the menus. Too much hassle, I gave up, I don’t trust VNC at all.

There’s a simple web based method within Seaside under /tools/versionuploader, you can use the web version of Monticello to load packages into the running image and then save the image from there. It’s simple and effective, if not a bit clunky, but it works great if you’re willing to expose that to the internet wrapped with just basic http authentication. I’ve been using this, but I thought I could have a little fun hacking up something a little more interesting.

So what are we talking about here, just loading a few Monticello packages and saving the image, how hard could that be to automate? Turns out, not so hard if I use the Installer that comes in Damien’s dev image (that my image is based upon). I decide to make my images upgrade themselves from a staging directory where I can just secure copy or ftp up the new versions plus an empty trigger file named “load” to kick the process off. I’ve been playing with it a few days now, seems to work pretty well. Here’s what it takes to make a self upgrading image (assuming you use Monticello to package all your code, as I do).

It’s just two methods really, one to load all the packages deleting them after each one is installed, assuming the load file exists…

loadChanges
    | dir |
    dir := (FileDirectory default directoryNamed: 'load-package') assureExistence.
    dir fileNames
        select: [ : ea | ea endsWith: '.mcz' ]
        thenDo:
            [ : fileName |
            ((dir fileExists: fileName) and: [ dir fileExists: #load ]) ifTrue:
                [Transcript show: (fileName , ': ').
                Installer installFile: (dir fullNameFor: fileName).
                Transcript cr.
                dir deleteFileNamed: fileName ] ].
    (dir fileExists: #load) ifTrue:
        [ dir deleteFileNamed: #load.
        SmalltalkImage current saveSession]

And a second to kick off a background process that runs continually, say every few seconds, that kicks off #loadChanges.

watchForChanges
    [[ (Delay forSeconds: 5) wait.
    [ self loadChanges ]
        on: Error
        do: [ : error | Transcript show: error ] ] repeat ]
        forkAt: Processor userBackgroundPriority + 1
        named: ‘code loader’

Then I call watchForChanges in a class side #initialize somewhere on a utility class so the background process is kicked off automatically in any image I load my code into. Seems pretty slick so far, just upload the new packages, upload an empty file named load, the image upgrades itself, deletes all the files in the staging directory, saves itself, and chugs along like nothing happened at all. No session are lost, no users booted, if anything they might notice a slight pause for a bigger package loading.

This all of course assumes your production image is basically read only, i.e. has no code changes in it, as mine are. Enjoy!

It’s a mistake to assume every application needs a relational database, or even a proper database at all. It’s all too common for developers to wield a relational database as a golden hammer that solves all problems, but for many applications they introduce a level of complexity that can making development feel like wading through a pond full of molasses where you spend much of your time trying to keep the database schema and the object schema in sync. It kills both productivity and fun, and god dammit, programming should be fun!

This is sometimes justified, but many times it’s not. Many business applications and prototypes are built to replace manual processes using Email, Word, and Excel. Word and Excel by the way, aren’t ACID compliant, don’t support transactions, and manage to successfully run most small businesses. MySql became wildly popular long before it supported transactions, so it’s pretty clear a wide range of apps just don’t need that, no matter how much relational weenies say it’s required.

It shouldn’t come as a surprise that one can take a single step up the complexity ladder, and build simple applications that aren’t ACID compliant, don’t support transactions, and manage to successfully run most small businesses BETTER than Word and Excel while purposely not taking a further step and moving up to a real database which would introduce a level of complexity that might blow the budget and make the app infeasible.

No object relational mapping layer (not even Rails and ActiveRecord) can match the simplicity, performance, and speed of development one can get just using plain old objects that are kept in memory all the time. Most small office apps with no more than a handful of users can easily fit everything into memory, this is the idea behind Prevayler.

The basic idea is to use a command pattern to apply changes to your model, you can then log the commands, snapshot the model, and replay the log in case of a crash to bring the last snapshot up to date. Nice idea, if you’re OK creating commands for every state changing action in you’re application and being careful with how you use timestamps so replaying the logs works properly. I’m not OK with that, it introduces a level of complexity that is overkill for many apps and is likely the reason more people don’t use a Prevayler like approach.

One might attempt to use the Smalltalk image itself as a database (and many try), but this is ripe with problems. My average image is well over 30 megs, saving it takes a bit of time, and saving it while processing http requests risks all kinds of things going wrong as the image prepares for what is essentially a shutdown/restart cycle.

Using a ReferenceStream to serialize objects to disk Prevayler style, but ignoring the command pattern part and just treating it more like crash proof image persistence is a viable option if your app won’t ever have that much data. Rather than trying to minimize writes with commands, you just snapshot the entire model on every change. This isn’t as crazy as it might sound, most apps just don’t have that much data. This blog for example, a year and a half old, around 100 posts, 1500 comments, has a 2.1 megabyte MySql database, which would be much smaller as serialized objects.

If you’re going to have a lot of data, clearly this is a bad approach, but if you’re already thinking about how to use the image for simple persistence because you know your data will fit in ram, here’s how I do it.

It only takes a few lines of code in a single abstract class that you can subclass for each project to make a Squeak image fairly robust and crash proof and more than capable enough to allow you just use the image, no database necessary. We’ll start with a class…

Object subclass: #SMFileDatabase
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'SimpleFileDb'

SMFileDatabase class
	instanceVariableNames: 'lock'

All the methods that follow are class side methods. First, we’ll need a method to fetch the directory where rolling snapshots are kept.

backupDirectory
	^ (FileDirectory default directoryNamed: self name) assureExistence.

The approach I’m going to take is simple, a subclass will implement #repositories to return the root object that needs serialized, I just return an array containing the root collection of each domain class.

repositories
	self subclassResponsibility

The subclass will also implement #restoreRepositories: which will restore those repositories back to wherever they belong in the image for the application to use them.

restoreRepositories: someRepositories
	self subclassResponsibility

Should the image crash for any reason, I want the last backup will be fetched from disk and restored. So I need a method to detect the latest version of the backup file, which I’ll stick a version number in when saving.

lastBackupFile
	^ self backupDirectory fileNames
		detectMax: [:each | each name asInteger]

Once I have the file name, I’ll deserialize it with a read only reference stream (don’t want to lock the file if I don’t plan on editing it)

lastBackup
	| lastBackup |
	lastBackup := self lastBackupFile.
	lastBackup ifNil: [ ^ nil ].
	^ ReferenceStream
		readOnlyFileNamed: (self backupDirectory fullNameFor: lastBackup)
		do: [ : f | f next ]

This requires you extend ReferenceStream with #readOnlyFileNamed:do:, just steal the code from FileStream so nicely provided by Avi Bryant that encapsulates the #close of the streams behind #do:. Much nicer than having to remember to close your streams.

Now I can provide a method to actually restore the latest backup. Later, I’ll make sure this happens automatically.

restoreLastBackup
	self lastBackup ifNotNilDo: [ : backup | self restoreRepositories: backup ]

I like to keep around the last x number of snapshots to give me a warm fuzzy feeling that I can get old versions should something crazy happen. I’ll provide a hook for an overridable default value in case I want to adjust this for different projects.

defaultHistoryCount
	^ 15

Now, a quick method to trim the older versions so I’m not filling up the disk with data I don’t need.

trimBackups
	| entries versionsToKeep |
	versionsToKeep := self defaultHistoryCount.
	entries := self backupDirectory entries.
	entries size < versionsToKeep ifTrue: [ ^ self ].
	((entries sortBy: [ : a : b | a first asInteger < b first asInteger ])
		allButLast: versionsToKeep)
			do: [ : entry | self backupDirectory deleteFileNamed: entry first ]

OK, I’m ready to actually serialize the data. I don’t want multiple processes all trying to do this at the same time, so I’ll wrap the save in a critical section, #trimBackups, figure out the next version number, and serialize the data (#newFileNamed:do: another stolen FileStream method), ensuring to #flush it to disk before continuing (don’t want the OS doing any write caching).

saveRepository
	| version |
	lock critical:
		[ self trimBackups.
		version := self lastBackupFile
			ifNil: [ 1 ]
			ifNotNil: [ self lastBackupFile name asInteger + 1 ].
		ReferenceStream
			newFileNamed: (self backupDirectory fullPathFor: self name) , ‘.’ , version asString
			do: [ : f | f nextPut: self repositories ; flush ] ]

So far so good, let’s automate it. I’ll add a method to schedule the subclass to be added to the start up and shutdown sequence. You must call this for each subclass, not for this class itself.

UPDATE: This method also initializes the lock and must be called prior to using #saveRepository, this seems cleaner.

enablePersistence
	lock := Semaphore forMutualExclusion.
	Smalltalk addToStartUpList: self.
	Smalltalk addToShutDownList: self

So on shutdown, if the image is actually going down, just save the current data to disk.

shutDown: isGoingDown
	isGoingDown ifTrue: [ self saveRepository ]

And on startup we can #restoreLastBackup.

startUp: isComingUp
	isComingUp ifTrue: [ self restoreLastBackup ]

Now, if you want a little extra snappiness and you’re not worried about making the user wait for the flush to disk, I’ll add little convience method for saving the repository on a background thread.

takeSnapshot
	[self saveRepository] forkAt: Processor systemBackgroundPriority
		named: ’snapshot: ‘ , self class name

And that’s it, half a Prevayler and a more robust easy to use method that’s a bit better than trying to shoehorn the image into being your database for those small projects where you really really don’t want to bother with a real database (blogs, wikis, small apps, etc). Just sprinkle a few MyFileDbSubclass saveRepository or MyFileDbSubclass takeSnapshot’s around your application whenever you feel it important, and you’re done.

Here’s a file out if you just want the code fast, SMFileDatabase.st

It’s based on Damien Cassou’s latest Squeak Dev Image (Squeak 3.9), an awesome base image with all the necessary goodies a developer needs. Of course I’ve loaded up my window customizations and preferences, nicer looking fonts, and have all the preferences set the way I like.

Nothing major in this update other than keeping up with the latest versions of everything I use. I have removed the SentorsaBrowser and TrickRefractoringBrowser because the new OmniBrowser is just getting too good to use anything else. Enjoy.

After a beta phase of two months we release the final version of Seaside 2.8. Most bugs fixed during this period were either long standing (already in 2.7), minor or portability related, Together with the dozens of Seaside 2.8 applications already in production today this gives a pretty good feeling about this version. A special mention deserves Roger Whitney, thanks to him we went from 99 commented classes to 144.

We have a list of new features [1] and a migration guide [2] on our homepage.

Squeak users can get it either from SqueakMap, Universes or directly via Monticello (Seaside2.8a1-lr.518). A special note for Squeak users, do not load Seaside 2.8 into an image that has already Seaside 2.7 in it. If you use Squeak 3.7 you will have to load SeasideSqueak37 as well.

VisualWorks users can get it form Store (2.8a1-lr.518,tkogan).

GemStone/S users can load Seaside2.8g1-dkh.522.

[1] http://www.seaside.st/community/development/seaside28a1
[2] http://www.seaside.st/documentation/migration

Cheers
The Seaside Team

I’ve been using 2.8 for a while now in development and for several weeks in production, it’s solid and very easy to port to for 2.7 users. Upgrade as soon as you can, it’s quite a bit snappier and uses much less memory.

The basic idea is to take a block of code, schedule it on another thread and return a dynamic proxy that if accessed, blocks until the value returns. This lets useful work continue on the main thread until you access the value.

A nice way to break up a big task concurrently might be to #collect: all the futures for a bunch of work processes you have, say fetching rates for a bunch of hotels that require calls to outside systems that may or may not return quickly, and then aggregate the results at the end.

Here’s the complete implementation, it’s quite simple but seems to work pretty well while playing around in a workspace and makes concurrency seem less of a beast.

First the class, a subclass of ProtoObject since we’re building a proxy…

ProtoObject subclass: #SFuture
	instanceVariableNames: 'futureValue error lock'
	classVariableNames: ''
	poolDictionaries: ''
	category: 'OnSmalltalk'

Then a #value: write accessor which eagerly kicks off the process, sets up, and clears the lock after fetching the future value.

value: aBlock
    lock := Semaphore new.
    [futureValue := [aBlock on: Error do: [:err | error := err]]
                ensure:
                    [lock signal.
                    lock := nil]] fork

Now a #value read accessor that blocks if the lock still exists, re-throws any error that may have happened on the worker thread in the context of the main thread, and finally returns the future value.

value
	lock ifNotNil: [lock wait].
	error ifNotNil:
			[error
				privHandlerContext: thisContext;
				signal].
	^ futureValue

A quick testing method for checking if the future has finished executing (useful for doing what work you can with the results that have returned).

hasValue
	^lock isNil

And the all important #doesNotUnderstand: override that intercepts any message sent to the proxy and sends it to the future value, causing the thread to block until the result is finished computing.

doesNotUnderstand: aMessage
    ^ self value
		perform: aMessage selector
		withArguments: aMessage arguments

Finally, a single extension method to BlockContext to make using the future more natural and ensuring to call fixTemps so I can collect future values in a loop with the assumption that the block will act like a proper closure.

BlockContext>>future
	^ SFuture new value: self fixTemps

Now we can ask any block for its future value and just pretend we have it. Executing some test code in a workspace…

value1 := [200 timesRepeat:[Transcript show: '.']. 6] future.
value2 := [200 timesRepeat:[Transcript show: '+']. 6] future.
Transcript show: ‘other work’.
Transcript show: (value1 + value2).

Reveals the string ‘other work’, a long string of interspersed periods and pluses, and finally 12, the result of adding the value returned by each future. In all, a pretty nice way to handle concurrency, I’ll have to see where I can simplify some code with the use of Futures, I can already think of a few.

It’s based on Damien Cassou’s Squeak Dev Image (Squeak 3.9), an awesome base image with all the necessary goodies a developer needs. Of course I’ve loaded up my window customizations and preferences, nicer looking fonts, and have all the preferences set the way I like. The main update here is Squeaks great new UI enhancements from Gary Chambers and Seaside 2.8. Squeak has never looked better, I hope to see the UI enhancements continue to make Squeak a tool for grown ups.

It has bookmarkable URLs, uses regex (regex package found on SqueakSource) to make WikiWords into links, keeps line breaks, and accepts raw HTML. Pages are stored on the file system under your image directory based upon the app name.

For a production quality Wiki, use Pier, this one is super simple and only intended for learning. It was written in about two hours (not counting some changes made during the writing of this article) as a single Seaside component.

OK, here we go, broken up into code sections by method category, first declare the class…

WAComponent subclass: #WikiPage
    instanceVariableNames: 'isEditing currentContent currentPage'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'SimpleFileWiki'

Setup the app on the class side…

canBeRoot
    ^ true  

initialize
    self registerAsApplication: #wiki

Initialize instances of the class…

initialize
    super initialize.
    currentPage := ''.
    isEditing := false

Create some accessing methods we’ll need…

currentContent
    ^ currentContent ifNil: [currentContent := '']

currentContent: aString
    currentContent := aString   

style
    ^ ‘ textarea {width:90%;height:500px;}’

Then some fancier accessors that ensure our file system is setup and reads pages from it…

pageDirectory
    ^ (FileDirectory default
        directoryNamed: self session application name , #Pages) assureExistence 

pageAt: aPage
	isEditing := (self pageExists: aPage) not.
	isEditing ifTrue: [^ ''].
	^ FileStream readOnlyFileNamed: (self pageDirectory fullNameFor: aPage)
		do: [:file | file contentsOfEntireFile]

If a page doesn’t exist, the Wiki kicks into editing mode to create it. A testing method use by the above…

pageExists: match
    ^ self pageDirectory fileExists: match

A couple of actions (our controller methods)…

loadPage: aPage
    isEditing := false.
    currentPage := aPage.
    self currentContent: (self pageAt: aPage)   

savePage
	self currentContent
		ifEmpty:
			[ (self pageExists: currentPage) ifTrue:
				[ self pageDirectory deleteFileNamed: currentPage.
				self loadPage: #FrontPage ] ]
		ifNotEmpty:
			[ FileStream
				forceNewFileNamed: (self pageDirectory fullNameFor: currentPage)
				do: [ :file | file nextPutAll: self currentContent ].
			isEditing := false ]    

cancel
	isEditing := false

Deleting the contents of a page, deletes the page as well.

Now we’re ready for rendering. Let’s start with page title in the head…

updateRoot: aRoot
    super updateRoot: aRoot.
    aRoot title: currentPage

And setting up the url…

updateUrl: aUrl
    super updateUrl: aUrl.
    aUrl addToPath: currentPage withFirstCharacterDownshifted

Now that the URL looks valid, lets make it work by parsing new requests, those that don’t include the session key (_s) or includes an expired session key. Once the session key and the continuation key (_k) are present, the URL is no longer necessary and will be ignored. Should this URL be bookmarked and returned to later, after the session has expired, #initialRequest: will be invoked, a new session started, and the correct page served…

initialRequest: aRequest
	| page url |
	url := aRequest url stringAfter: self application basePath.
	page := (url beginsWith: '/')
		ifTrue: [ url allButFirst copyAfterLast: $/ ]
		ifFalse: [ url copyAfterLast: $/ ].
	self loadPage: (page ifEmpty: [ 'FrontPage' ] ifNotEmpty: [ page ])

This uses an extension method #stringAfter that I have loaded in all my images, and it relies on another #split that is also in my images. Here they are…

String>>stringAfter: aDelim
    | list |
    list := self split: aDelim.
    ^ list isEmpty ifTrue: [self] ifFalse: [list last withBlanksTrimmed]

String>>split: aString
    | index lastIndex |
    index := lastIndex := 1.
    ^ Array streamContents:
            [:stream |
            [index <= self size] whileTrue:
                    [index := self findString: aString startingAt: lastIndex.
                    index = 0 ifTrue: [index := self size + 1].
                    stream nextPut: (self copyFrom: lastIndex to: index - 1).
                    lastIndex := index + aString size]]

Now our main render method which decides which mode the Wiki is in…

renderContentOn: html
    isEditing
        ifTrue: [self renderEditorOn: html]
        ifFalse: [self renderViewerOn: html]

And either edits the Wiki page…

renderEditorOn: html
	(html heading)
		level1;
		with: ((self pageExists: currentPage)
					ifFalse: ['Page ' , currentPage , ' hasn''t been created yet, go for it!']
					ifTrue: ['Editing ' , currentPage]).
	html form:
			[html textArea on: #currentContent of: self.
			html break.
			html submitButton on: #savePage of: self.
			html text: ' or '.
			html anchor on: #cancel of: self]

Or renders the viewer which also parses the text for WikiWords and line breaks…

renderViewerOn: html
    self withLineBreaks: (self currentContent
                copyWithRegex: '[A-Z][a-z]+([A-Z][a-z]+)+’
                matchesTranslatedUsing:
                    [:match |
                    (self pageExists: match)
                        ifTrue: ['<a href="' , (html urlForAction: [self loadPage: match]) displayString, ‘”>’, match , ‘</a>’]
                        ifFalse: [match , '<a href="' , (html urlForAction: [self loadPage: match]) displayString, ‘”>?</a>’]])
        on: html.
    html paragraph:
            [(html anchor)
                callback: [isEditing := true];
                text: ‘Edit’.
            html space.
            (html anchor)
                callback: [self loadPage: #FrontPage];
                text: ‘FrontPage’]

The editor and viewer could have been separate components, but I’m going for simple here, one class. And finally, the method for breaking lines…

withLineBreaks: aString on: html
    | stream |
    stream := aString readStream.
    [stream atEnd] whileFalse:
            [html html: stream nextLine.
            stream atEnd ifFalse: [html break]]

And there we have it, a simple file based Wiki that covers quite a few things you’d want to do in a web app and should be easily digestible for the Seaside beginner. There are probably bugs, I didn’t do a ton of testing and its only intended use is this blog post.

According to the message “WikiPage linesOfCode”, that’s 90 lines of code total (and that’s including the HTML and CSS). Here’s a file out of the code for anyone interested. Make sure to manually add the two extension methods to String for this to work.

wget ftp://ftp.gnu.org/gnu/smalltalk/smalltalk-2.3.6.tar.gz
gunzip smalltalk-2.3.6.tar.gz
tar -xf smalltalk-2.3.6.tar

So far so good. The instructions say I need autoreconfig, so I fire up Cygwin setup and hit the Devel category and install it, just to be safe I install gcc compilers for C and C++ as well. Time to build Smalltalk (that sounds weird to me).

autoreconf -fvi
./configure
make

Takes a minute, checks a gazillion things, but all is well, build seems to work fine. Time to run the unit tests…

make check

Good to go, so lets install…

make install

OK, now just type “gst” to get a REPL, play around for a bit, and write my first simple shell script, a quick loop printing 1 to 10000 on stdout…

#!/usr/local/bin/gst -f
(1 to: 10000) do:[:it | it printOn: stdout].
!

Sweet, works like a charm. I can now fall back on Smalltalk for shell scripting instead of ruby or pearl when I need more power than simple bash scripts.

Stealing a sample from the Wiki shows a nice scripting syntax making use of blocks for declaring class and method bodies…

Object subclass: Person [
    | name age |
    Person class >> name: aString age: anInteger [
        ^(self new)
            name: aString;
            age: anInteger;
            yourself
    ]

    name [ ^name ]
    name: aString [ name := aString ]
    age [ ^age ]
    age: anInteger [ age := anInteger ]

    printOn: aStream [
        aStream << ('%1 (%2)' % {name. age})
    ]
]

I think I like it! Only time will tell, but I think this will be my new scripting language of choice.

For an in depth look at the design of Magritte you should read Lukas’ Master’s thesis, however, it’s a bit much if you’re just trying to get something done and just want to understand how to get going with the basics. Magritte’s capable of more than you’ll likely use if you’re just wanting to build forms with Seaside. I’m going to ignore those other abilities because frankly, I don’t use them and don’t plan to.

The basic design of Magritte involves a few classes that you’ll need to be familiar with and often subclass to extend and customize.

MADescription

With Magritte you describe your objects with subclasses of MADescription, this is where you’ll always start, just describing the fields of your domain objects that you’ll want generated forms for. Descriptions contain the extra metadata necessary to create user interfaces, and which component will be used to render it. A simple description looks like this…

descriptionIsClosed
    ^ (MABooleanDescription new)
          selectorAccessor: #isClosed;
          label: 'Is Closed';
          priority: 1000;
          yourself

Generally speaking you’ll keep these descriptions on the class side of your domain object. On occasion, you’ll want some property of the description to be dynamic and depend on the actual value of an instance side value, so you’ll move the description to the instance side. Strictly speaking, it doesn’t matter where you put them, sometimes you’ll use them to build forms when you don’t even have a domain object, but this isn’t the normal case.

There are two basic ways to create a form dynamically, one is simple and includes all descriptions found on an object…

buildComponentFor: aModel
    ^aModel asComponent addValidatedForm

The other, a little more complex, but much more useful because you’ll find that rarely do you want “every” described field in a form. Often you’ll have multiple UI representations of a domain object within an app. Descriptions are composable using a comma so you can build a form any subset of the fields…

buildComponentFor: aModel
    ^((ModelClass descriptionFieldOne, ModelClass descriptionFieldTwo, ModelClass descriptionFieldThree)
            asComponentOn: aModel)
        addValidatedForm;
        yourself

A Magritte form is generally wrapped with a form decoration via #addValidateForm, which by default gives you a #save and #cancel button. Magritte forms don’t directly work on your domain objects. They work on a memento of the values pulled from your object using the descriptions. When you call #save, the values are validated using the descriptions, and only after passing all validation rules are the values committed to your domain object by the momentos via the accessors, which I’ll describe shortly. For those interested, this is a good place to plug in a custom container component and integrate the #commit with Glorp, but that’s another post.

Conditions

Descriptions can have predicates associated with them to validate the input data which it calls conditions. There are two basic kinds of conditions (there are actually more, but the block forms are what I use), both are simply blocks that returns true or false to validate the data. One is the single field condition which is passed the pending value directly and attached directly to your descriptions. It’s as simple as…

addCondition:[:value | value withBlanksTrimmed size > 3]

The other is the multi field validation which works on the memento which I’ll describe below.

	addCondition: [:memento |
		(memento cache at: CAUser descriptionPassword) isNil or:
			[(memento cache at: CAUser descriptionPassword)
				= (memento cache at: CAUser descriptionConfirmedPassword)]]
	labelled: ‘Passwords must match’;

I’ve posted about these previously. They are attached to your containers description which has access to all the fields.

Conditions are one of the few things about Magritte that I’m still iffy on. There are advantages to having your rules outside your domain objects, especially if you’re taking advantage of Magritte as an Adaptive Object Model where users can build rules from the UI. It also allows the mementos to easily test data for validity outside the domain object and gives you a nice place to hook into the validation system in the components. It bothers me a little because it weakens the domain model, I’m still trying to find my balance here and decide just how much I’ll allow as conditions.

Magritte is very pluggable, should I decide I want all my rules in my domain objects, I could plug in my own memento subclass to handle that, but I haven’t felt the need just yet.

MAMemento

When components read and write to domain objects, they do it using mementos rather than working on the objects directly. The default memento is MACheckedMemento, a subclass of MACachedMemento. The mementos give Magritte a place to store invalid form data prior to allowing the data to be committed to the object. It also allows Magritte to detect concurrency conflicts for shared in image objects. By never committing invalid data to domain objects, there’s never a need to roll anything back. Should you feel the need, just override #mementoClass on your domain object to provide your own.

MAAccessor

When a memento writes valid data to its model, it does so through accessors which are also defined by the descriptions. MAAccessor subclasses allow you to define how a value gets written to your class. For example, while I have a read selector for my collections like #users, I prefer to encapsulate #add and #remove on the domain object itself rather than having a writable selector for #users:. When creating a description for that collection, I can specify my custom #accessor: rather than using the default #selectorAccessor: which then writes to my domain object with #addUser: and #removeUser:.

Another valuable use for accessors can be found when you want to flatten several domain objects into a single form. Say you have a User object with an Address object, and a CreditCard object but you want to edit them all as a single form. You can create your form and dynamically wire up some MAChainAccessors like so…

userTemplate
	^((((CAUser descriptionEmail, CAUser descriptionPassword , CAUser descriptionConfirmedPassword)
		addAll: (CAAddress description collect: [:each |
			each copy accessor:
                            (MAChainAccessor accessor: (MASelectorAccessor selector: #address) next: each accessor)]);
		addAll: (CACreditCard description collect: [:each |
			each copy accessor:
                             (MAChainAccessor accessor: (MASelectorAccessor selector: #creditCard) next: each accessor)]))
                yourself)
            asComponentOn: self session user)
            addValidatedForm: {  (#save -> ‘Update Profile’)};
            yourself.

Which basically just composes the users descriptions with the addresses and credit cards descriptions while chaining the accessors together to allow the addresses fields to be written to the address object rather than directly to the customer object. Any non trivial UI will contain many such forms and this is the ability I’m the most grateful for in Magritte. Also notice in the example above how I changed the label for the save button to “Update Profile”, also something you’ll need to do often that isn’t immediately obvious how to do.

MADescriptionComponent

Components control how your objects display. Magritte widgets are subclasses of this component. Some descriptions have an obvious one to one relationship with a UI component while others could easily be shown by several different components. For example, an MAMemoDescription would be represented by a text area, but a MABooleanDescription could be a checkbox, or a drop down with true and false, or a radio group with true and false.

Each description defaults to a component, but allows you to override and specify any component you choose, including any custom one you may write. For example, suppose I built a special component to render checkboxes as fancy graphics rather than ordinary html checkboxes. I could plug it in by changing the description as follows.

descriptionIsClosed
    ^ (MABooleanDescription new)
          selectorAccessor: #isClosed;
          label: 'Is Closed';
          priority: 1000;
          componentClass: CAFancyCheckbox;
          yourself

These are essentially meta components written in standard Seaside. They work on mementos and have access to your descriptions. This is where all that meta data comes in handy. If you’re building a dropdown list, it’ll get its option list from the description. When you render an element’s label, that’s also read from the description.

When you build your own descriptions, you’ll add fields to them for custom data that you’ll want available in your custom components. At first, you’ll mostly use built in descriptions and components, but as you grow comfortable with Magritte you’ll start wanting to build your own descriptions and components because you’ll want to do things beyond the basic framework like Ajax. Magritte provides a solid foundation for extension.

MAComponentRenderer

By default, Magritte forms are rendered using MATableRenderer which renders the fields in a table with errors at the top and labels to the left of input fields. This is the default because it’s the easiest thing to do automatically that looks halfway decent. This can be overridden like so…

buildComponentFor: aModel
    ^((ModelClass descriptionFieldOne, ModelClass descriptionFieldTwo, ModelClass descriptionFieldThree)
            componentRenderer: MACssRenderer;
            asComponentOn: aModel)
        addValidatedForm;
        yourself

This hook allows you to render the form as you please, should you want to display errors differently, or change how elements are wrapped, or how the outer container itself is wrapped. It’s handy to control how container classes are tagged with css classes to have the form dynamically change its appearance for various phases like valid/invalid. If you don’t want your forms to look like auto-generated forms, you will use this.

For each of the classes I just described, you’ll want to pull up a hierarchy browser and explore all the subclasses to see examples of how they are specialized. Find some example projects in SqueakSource that use Magritte to see how others create custom descriptions and components. As with any framework, successful use depends on understanding it, and understanding how the pieces fit together. Magritte will not doing everything you want out of the box, it isn’t meant to, but it’s an excellent foundation to base your application on. It will save you many hours of tedious work building forms by hand. It will also give your objects extra metadata that you may find handy for purposes other than building forms.

Along with Seaside, Magritte is also an excellent example of extremely well written object oriented code that is worth reading to see exactly what it takes to make a truly flexible and pluggable framework. Because it was originally a masters thesis, it’s also far better commented than you’d likely find in a similar “real” world framework.

He’s demonstrating some of the features of the refactoring browser on a running instance of the classic Asteroids game. He extracts a method to a component, changes the color of the asteroids, then shows off undo and redo. He does so while the game is running without ever having to break his flow with something as silly as a compile, debug, run cycle that we’ve all grown so accustomed to in most other languages.

It doesn’t matter how fancy modern refactoring browsers get, as long as they’re still working on dead files instead of a live running program, they’ll never be able to compete with Smalltalk when it comes to developer productivity and maintaining flow.

Featured Resources…

Whenever you look at a web design, you will notice that it’s usually not free from 3d animation effects. These features bring out the human interaction elements at its best. An affordable hosting will have you earn the desired outcomes from your website. There is a need of a good backup plan for your business hosting as the data security becomes a great concern in this case. And you will enjoy it’s advantages.

This is a short list of things to do when migrating for an older to a newer version of Seaside in the wiki at:
http://www.squeaksource.com/Seaside.html

2.6 to 2.7 must:

• every component that uses the old default WAHtmlBuilder must do so explicity by returning it in #rendererClass
• evaluate WADispatcher resetAll
• use WATagBrush >> #title: instead of WATagBrush >> #tooltip:
• move to new image map api, check all senders of #imageMap, see WAImageMapTag for details

2.6 to 2.7 should:

• move to new header api, modify implementors of #updateRoot:
• remove the implemtors of #rendererClass that return WARenderCanvas
• migrate to WARenderCanvas
• migrate from WAScriptLibrary and WAStyleLibrary to WAFileLibrary
• use WAAnchorTag >> #with: instead of WAAnchorTag >> #text:
• check for deprecated message sends
• replace users of WAChangePassword, WAEditDialog, WAEmailConfirmation, WAGridDialog, WALoginDialog, WANoteDialog

2.7 to 2.8 must:

• migrate to WARenderCanvas
• backtrack state by implementing #states (check all senders of #registerObjectForBacktracking: and #registerForBacktracking)
• move to new header api, modify #updateRoot:. #linkToStyle becomes #stylesheet #url, #linkToScript becomes #javascript #url:, check all implementors of #updateRoot:
• use WAAnchorTag >> #with: instead of WAAnchorTag >> #text:
• replace users of WAChangePassword, WAEditDialog, WAEmailConfirmation, WAGridDialog, WALoginDialog, WANoteDialog
• every component that implements #initialize must send this message also to super (use SLint)
• if you use Squeak 3.7 load SeasideSqueak37 after Seaside
• if you use Squeak do not load into an image that has an earlier version of Seaside already loaded

2.7 to 2.8 should:

• check for deprecated message sends
• migrate from WAScriptLibrary and WAStyleLibrary to WAFileLibrary
• remove the implementors of #rendererClass that return WAHtmlCanvas

I’m sure this list is not complete and I forgot stuff. So if you spot something that is missing send a message to me or the list or fix it directly. This is not on the Seaside homepage so anyone can edit it.
It will probably be moved to the homepage at a future point.

Cheers, Philippe

He showed a Java implementation of a simple and common programming problem…

int maxSalary = 0;
for (Employee employee : employees) {
  if (Role.PROGRAMMER.equals(employee.getRole())) {
    int salary = employee.getSalary();
    if (salary > maxSalary) {
      maxSalary = salary;
    }
  }
}

Comparible to a C# 1.0 version…

int maxSalary = 0;
foreach(Employee employee in employees) {
    if(employee.Role == Role.PROGRAMMER
        && employee.Salary > maxSalary) {
        maxSalary = employee.Salary;
    }
}

Then he does a Scheme version using a more functional style…

(define (salary-of-highest-paid-programmer records)
  (accumulate
      max 0
        (map salary
          (filter programmer? records))))

And a Ruby version of similar style, note the Smalltalk’ishness of it…

employees.
  select {|emp| :programmer == emp.role }.
    map {|emp| emp.salary }.
      inject {|m, v| m > v ? m : v}

And for comparison here’s a Smalltalk version…

(employees
    select: [:emp | emp role = #programmer ]
    thenCollect: [:emp | emp salary ])
        inject: 0 into: [:a :b | a max: b ]

Though if I found the pattern that common I’d define a quick helper method on Collection to clean up the syntax to this…

employees
    select: [:emp | emp role = #programmer ]
    collect: [:emp | emp salary ]
    inject: 0 into: [:a :b | a max: b ]

What’s interesting about them to me is really the difference between the Java/C# approaches and the more composable Scheme/Ruby/Smalltalk style. Because Java/C# 1.0 lack first class functions (C# actually has them now in 2.0 and a nice lambda syntax in 3.0) and a literal syntax for declaring them, everything ends up being a special case of for/foreach. They lack the ability to factor out common patterns like select:, collect:, and inject:into: into higher order functions.

As a side effect, select: turns into nested if’s and a loop, collect: into a temporary variable and a loop, and inject:into: into both an if, a temporary variable, and a loop. You end up writing these patterns inline over and over rather than just reusing existing versions from the base library.

Languages that can’t support and make idiomatic the use of higher order functions, aren’t worth using these days in most domains. They’re just too damn much work. However, using functional techniques doesn’t at all mean using a functional language. All of these work quite well in good object oriented languages like Smalltalk and Ruby.

However, despite the awesome effort (which I do appreciate), I have some problems with it. As with many other Squeak tutorials, it makes the mistake of using a standard Squeak image as you’d find on Squeak.org. This only helps further propagate the impression among newbies that Squeak is ugly, old fashioned, and lacking in all the features they expect from a more modern IDE. What you see in the screenshots is not a Squeak I’d use. Plain black code, ugly fonts, no intellisense, no use of the Refactoring Browser, no Shout Workspace.

Most developers who use Squeak would have a plethora of extra tools and utilities installed that make developing a much nicer experience than what you see in this tutorial. Do yourself a favor and start your Squeaking with a real developer’s image loaded with all the proper goodies like the SqueakDev image maintained by Damien Cassou.

Squeak.org still hasn’t figured out that its core audience should be developers, not children. They don’t seem to realize the base image they distribute actually scares away more people than it encourages to join the community. Though they do have a link to Damien’s SqueakDev image, they don’t encourage it like they do the base image, a mistake that leads new developers to open up Squeak for the first time, browser a tutorial or two, and toss it aside as a silly toy, never having seen the real power or beauty that is Smalltalk.

So all you developers out there using Squeak, please, stop showing people ugly images. Marketing matters, looks matter, and that stuff scares people away. Load up some decent fonts, setup the minimum *required* goodies like Shout, the Refactoring Browser, and ECompletion. And if you aren’t using these goodies, you should be, and you shouldn’t be making tutorials without them because it gives people a false impression of what Squeak is. Squeak is an awesome development environment that sadly doesn’t come out of the box that way, you have to start with the right box or learn to build your own.

Squeak.org could learn a lot about marketing Squeak by looking at how rubyonrails.org markets Rails. If there’s one thing Ruby does vastly better than Smalltalk, it’s marketing. Smalltalk continues to languish not because of technical merits, but because of bad marketing. Beaten by Java, and now beaten by Ruby, by marketing alone.

It’s an interesting thing, the Smalltalk browser. Unlike most IDEs, it’s optimized for reading code rather than writing code. Other IDEs allow you to see any number of methods all at once, cutting and pasting text giant chunks at a time, they sure make you feel like you’re working. They don’t however, allow you to navigate the semantic structure of the code very well nor do they encourage the writing of well organized code.

Modern IDEs are getting better at this, but they’re doing it by copying Smalltalk. Smalltalk’s various code browsers (hierarchy, method, inheritance, senders, implementors, protocol, category, package, refactoring) let you explore the structure and relationships between existing code and its tools (transcript, workspace, method finder, message names) make finding and using existing code, or understanding existing APIs vastly easier than any other language I know of. Seeing the structure of code is always but a context menu or hotkey away.

Smalltalk’s browser is rather opinionated, luckily, thanks to Rails, opinionated software seems to be having somewhat of a revival. When it comes to writing code, the browser forces you into a certain mindset, one that other languages don’t force you into. When I create a method in Java/C#/Ruby, I have to choose little more than what file and class it belongs in. I *can* organize the code well, but there’s little incentive to do so and my unit of work is rather undefined, I could be slicing and dicing methods, classes, namespaces, etc., usually with the full screen devoted to code across various files or even god forbid in one giant file. This encourages a code now and organize later approach. Sadly, later often never comes, and the code is left functional but messy.

Smalltalk on the other hand, defines my unit of work as *the method* and by doing so forces me at every turn, to continually organize my code in semantically meaningful ways. When I create a method, I have to choose a class category, a class, and a method category to put the method in. If I don’t, Smalltalk kindly categorizes the method for me in a protocol called “as yet unclassified”. It’s almost an insult, but it’s also a not so subtle reminder than I’m writing code sloppily, faster than I’m thinking. It reminds me to slow down, think for a second, where does this thing belong.

It only takes a second to pick a meaningful category name, and these names are idiomatic, I see them all the time when I’m looking for code. Aha, we’ve linked writing code to reading code. By taking the time to properly categorize my methods I also learn where to look for code later, when I’m in reading mode. It’s a feedback loop, the more I read the better I write and the better I write the more I learn to read with accuracy, looking only where necessary. It’s as if the code itself *is* a concise form of documentation hyperlinked by semantic meaning using things that Smalltalkers call browsers. Browsers and hyperlinks, bah, that’ll never work!

And RDoc, what the fuck is that, looks curiously like a Smalltalk browser to me, but why should class comments be anywhere except on the class itself? Oh that’s right, Ruby doesn’t have a Smalltalk browser, they code in files, how quaint.

As for editing the method itself, I work on and view only one method at a time, and only the lower half of the browser is for editing code which punishes me if I write long methods that can’t fit into that tiny pane. Smalltalk at every turn encourages me to read more code than I write, reuse more code than I otherwise might, and write smaller simpler methods than I likely would in a text editor.

Writing smaller methods forces me to give them meaningful names. Giving them meaningful names and putting them in meaningful places makes the code easier to read and easier to find. Code that is easier to read and easier to find, is easier to reuse, easier to understand, and easier to compose into new solutions. It’s called bottom up programming, the foundation of which is small composeable methods.

I keep using the word small, maybe that’s a mistake on my part, what I really mean is concise. Methods with a single purpose that is clearly summed up by their name. These kinds of methods happen to be short in general, but that’s a side effect of their being focused on a single task. The Smalltalk browser encourages these kinds of methods by making writing long methods or paying attention to too many methods painful. Text editors are general purpose editor aimed at text, that could be anything from a blog post to a novel. Surely an editor intended only for code, and only for a particular style of code, can be made much more *domain specific*.

The Smalltalk browser is such an editor, its domain is highly factored heavily structured bottom up style object oriented code. If that’s the style of code you like to write, you’ll find the Smalltalk browser wonderful, if not, you’ll find it painfully opinionated and rude.

Take a peek at decompiled .Net framework sources, or Ruby sources and what you’ll find, are average line per method counts in the 50+ to even 100+ ranges. In Smalltalk, around 10 or so. To me, this is a clear indication that text editors are the wrong interface for writing clean simple well factored reusable code. Sure, I just pulled these numbers out of my ass, but they reflect my experiences and even then, I’m being polite, 1000 line methods are not at all uncommon in .Net.

Maybe adjusting to the Smalltalk browser is similar to adjusting to Lisp’s parenthesis. It’s something you desperately want to fix as a newbie and make it work like other languages. In Lisp’s case, trying to design an infix Lisp while in Smalltalk it’s a text and file based editor. In both cases, once you stop fighting the language and realize the difference is actually a great strength of the language rather than something that needs fixed. You realize it’s you that needs to change, you open your mind, accept that sometimes different is good, and take advantage of the new power these tools give you.

Experienced Lispers love their parenthesis and experienced Smalltalkers love their browsers. Rather than seeing the Smalltalk browser as a barrier, maybe, just maybe, you’d be better off seeing it as a new toy to play with. Something new to learn.

UPDATE: Here’s a few admitidly cramped screenshots of the various browsers. They do of course look much better maximized on your monitor.

I was considering writing more about it but a quick Google search turned up this great reference Smalltalk for Lispers from the Smalltalk/X Programmers Guide that gives an excellent introduction from a more functional point of view.

If you mix object oriented programming, manifest types, and procedural programming, you get Java or C#, not exactly a fun or flexible combination of language features. Mix object oriented programming, dynamic types, and light functional programming and you get Smalltalk and Ruby, much more fun and much more flexible and productive.

People often seem to forget “object” is meant as an abstract term that means “thing”. Object oriented programming is about programming with “things”. In that sense, functions are objects too. Not all objects need be created with named classes, and all too often people who complain about OO are really complaining about their misguided view of OO and the often made newbie mistake of trying to model everything with a class. It’s not called class oriented programming, it’s called object oriented programming. Maybe approaching Smalltalk from a more functional point of view will shed some light on more interesting ways to solve problems.

I’ve been so busy with work lately that I haven’t felt much like writing but I think it’s about time I give the blog a little more love. So those of you looking to get into Smalltalk, or Seaside, where’s your pain? What things are tripping you up that you can’t find answers to? What things are getting in your way that keep you from getting into the flow and really doing something in Seaside?

I’m just looking for some ideas for some bite sized yet useful articles covering topics I haven’t already covered that’ll help ease someone’s pain just a bit and get me back into the writing mood.

Knowing who the parent is prevents the component from being re-used in other contexts with different parents. There is a general solution to this whole class of problems and it was solved quite elegantly by Vassili Bykov with his Announcements framework.

The basic idea is to setup an announcer somewhere global, in the session for example.

MySession>>announcer
    ^ announcer ifNil: [announcer := Announcer new]

Then subclass Announcement for any interesting thing that might happen like removing a child.

Announcement subclass: #RemoveChild
    instanceVariableNames: 'child'

RemoveChild class>>child: aChild
    ^self new
        child: aChild;
        yourself

RemoveChild>>child: anChild
    child := anChild

RemoveChild>>child
    ^child

Any component interested in this announcement registers its interest when it initializes.

Parent>>initialize
    super initialize.
    self session announcer on: RemoveChild do:[:it | self removeChild: it child]

Parent>>removeChild: aChild
    self children remove: aChild

And any component who wants to fire this event simply announces it by sending in an instance of that custom announcement object.

Child>>removeMe
    self session announcer announce: (RemoveChild child: self)

Works great, and depending on where you place the announcer, you could even have different sessions sending events to each other, or different applications.

Here’s a file out of a commented working demo that has a child remove itself from the parent via an announcement.

UPDATE: I use the port of Announcements from Lukas Renggli’s public repository. The one on SqueakSource is a different port.

Features include login, register, add entry, vote on entry, comment on entry, comment on comment. There are probably a few bugs. I’m not making any claims of best practice, only showing various ways I accomplish things to suite my needs.

Hopefully such an application will make Seaside more approachable for the newbie and help ease the lack of documentation available. I know when I first started learning, I was far more interested in actual samples than outdated documents. Enjoy!

UPDATE: Loading this code requires that you create a repository in Monticello. Just create a new HTTP repository with the following template using the +Repository button.

MCHttpRepository
    location: 'http://www.squeaksource.com/SmallReddit'
    user: ''
    password: ''

Once done, you can open the repository, select the package, and load it. It will create an application on localhost at /seaside/smallReddit, on whatever port you’re running Seaside on. You could also just download the mcz file directly and drag and drop it into your squeak image, at which point you’ll be prompted and asked what you’d like to do.

See my previous screencast about using Monticello for a quick visual on using Monticello.

“IMHO Seaside is the benchmark by which all web frameworks should be measured” — David Pollak

My thoughts exactly. It’s not about the language, it’s about the approach. Seaside is the right recipe for writing real applications, not just fancy websites. No other framework can do what Seaside does, as easily as Seaside does it. Real components with their own state, real objects, no pages, no templates, Ajax in pure Smalltalk by simply wiring events together on the server side, calls to other components are actual method calls rather than hacked up URL conventions.

For Rails fans (myself included), don’t compare Seaside to Rails, rather compare Seaside to ActionPack, the view controller layer within Rails. If you want to see an apples to apples comparison of the entire stack, it’d be something like…

ActionMailer == Existing Squeak services
ActionPack == Seaside
ActionWebservice == SoapCore
ActiveRecord == Glorp
ActiveSupport == Existing Squeak code, the image is full of DSL mini languages to make everything pretty

Seaside isn’t the well integrated full stack solution that Rails is, but all the parts are there, you can mix and match your own perfect framework.

Edward was lucky, he had a Smalltalker handy to show him the ropes, few have that opportunity. I’m still amazed by how many people think they can grok Smalltalk by seeing syntax examples. Smalltalk isn’t its syntax, it’s its environment. Smalltalk is a living world of running objects, there are no files, no applications, just what’s running. To understand Smalltalk, you have to either actually use it for a while, or have a seasoned Smalltalker demonstrate it to you. Reading sample code just won’t cut it.

For better or for worse, Smalltalk is a world unto itself. It’s much more an operating system than a programming language. When Steve Jobs stole the idea for a windowing system and mouse from Xerox (not that they invented it), it was Smalltalk he was seeing. Even he readily admits he was so dazzled by the GUI he didn’t even notice Smalltalk, or the fact it was all networked with email, things we take for granted now but didn’t exist widely back then.

Sure, we package code and use source control, but our methods aren’t file based. Our source control systems are language aware, they can diff and merge code at the method level, auto merge and allow you to select, method by method, which version you want to keep. Smalltalk is different, top to bottom, it’s just different. Everything is live, code changes are live, applications don’t start, they’re simply always running. Object oriented programming means something entirely different to a Smalltalker than to someone doing OO in another language.

Ruby comes very close to Smalltalk. It’s a nice introduction to many if not most of Smalltalk’s ideas. It’s very pragmatic, fits in with the world around it, it’s based on files, works with your favorite text editor, etc. etc. But Ruby still isn’t Smalltalk. I use Ruby, I like Ruby, but Smalltalk is more productive when I’m working in unknown territory. Smalltalk is better for prototyping ideas quickly. A read eval print loop and hyper-linked documentation just doesn’t compare to a real Smalltalk workspace and a real Smalltalk browser where the code itself is hyper-linked and navigable and objects are things you can actually pick up and shake.

Smalltalk doesn’t have to be pragmatic, because it’s better than its imitators and the things that make it different are also the things that give it an advantage. Its syntax isn’t weird, C’s is. Weird isn’t even the right word, because what’s weird is totally relative and very dependent on your background experience. Smalltalk’s syntax is simply better.

Window window = new Window(0, 0, 800, 600);

Simply isn’t as expressive as…

window := Window top: 0 left: 0 width: 800 height: 600.

And this is a trivial example, the more complicated the code gets, the more of an advantage Smalltalk has. Ruby chose to go with a C’ish syntax, but by convention, mostly tries to fake the Smalltalk style anyway because it’s simply better.

window = Window.new :top => 0, :left => 0, :width => 800, :height => 600

So, if you still haven’t tried Smalltalk, and I mean really tried it, by writing an application in it, give it a go. You’ll never regret it, because everything you learn, and you’ll learn a lot, you’ll be able to bring back with you to whatever language you call home. Smalltalk will change the way you think, no matter what language you’re coming from. Whether it changes it for better or for worse is of course entirely up to you. If you’re afraid to try Smalltalk, then at least try Smalltalk Lite… uh, I mean, Ruby, you’ll enjoy it and still be able to use your existing tools. You can work your way up to the real thing.

PS: Lisp and Haskell are two other equally mind bending languages that I think everyone should learn, however, neither of them can touch Smalltalk’s development environment. That being said, learn them anyway.

Featured Resources…

Just like Smalltalk stands different than the rest, there is a wide range of cheap web hosting companies offering their best hosting packages. You will be able to register domain very quickly with some of these. If you have many domains, you can still avail this facility. For small business owners, the hosting companies like startlogic are coming up with the best solutions for their needs.

I popped in the CD burned from downloading the ISO image and was greeted with a nice menu asking me what I wanted to do. I chose to install server to hard drive and proceed through an install that reminded me very much of the old NT4 install but better. The install finished, successfully detected all the hardware, auto configured the network (using the local DHCP server), and left me with a command line login prompt, exactly what I wanted. At this point, I was very impressed, setting up a Linux server takes a fraction of the time of setting up a Windows server and was completely trouble free. I wouldn’t use DHCP for a production server, but it’ll do fine for testing purposes.

Now, on to what I thought would be the hard part, setting up the necessary software. I haven’t yet loaded emacs, so I’ll use pico and to whip the server into shape.

I spent a few minutes looking into Debian’s package system, learned what I needed, and then away I went. First I needed to ensure the server was up to date.

sudo apt-get update
sudo apt-get upgrade

OK, that was easy. Now I need to install some software. Two of the main things I wanted weren’t in the default Ubuntu repositories. Squeak and Daemontools. Squeak for hosting Seaside and Daemontools because I found out that’s what Lukas uses to maintain his Seaside services, and HAProxy to load balance the processes. I quickly found repositories for all of them and added them to the list of repositories available.

sudo pico /etc/apt/sources.list

and added…

#daemontools
deb http://smarden.org/pape/Debian/ sarge unofficial
deb-src http://smarden.org/pape/Debian/ sarge unofficial
#squeak
deb http://ftp.squeak.org/debian/ stable main
deb-src http://ftp.squeak.org/debian/ stable main
#haproxy
deb http://ftp.sysif.net/debian sid main

Install the cert for HAProxy site

wget http://ftp.sysif.net/debian/apt_key.asc
sudo apt-key add apt_key.asc

Now fetch the new lists by updating again….

sudo apt-get update

OK, time to install everything I want. I need Squeak, an FTP server, Apache, Daemontools for managing services, a SSH server for remote access, HAProxy for load balancing, Samba for networking with my other windows servers, and Emacs because I’m going to be using it. I chose HAProxy for two reasons, there’s no official Ubuntu version of Apache2.2 with mod_proxy_balancer so installing is a pain, and even with mod_proxy_balancer I haven’t been able to get it to work successfully with Seaside. So, on to the install, simple enough…

sudo apt-get install squeak daemontools vsftpd
sudo apt-get install apache2 apache2-utils
sudo apt-get install openssh-server emacs21 haproxy samba

This was actually one command but 3 fits nicer on the blog. Now configure the ftp server…

sudo emacs /etc/vsftpd.conf

and make a few changes…

anonymous_enable=NO
local_enable=YES
write_enable=YES

and restart the ftp service…

sudo /etc/init.d/vsftpd restart

Now setup Apache with the modules I need…

sudo a2enmod rewrite
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod deflate

and restart the Apache service…

sudo /etc/init.d/apache2 restart

And I’m mostly setup. Wow, that was easy, much easier than I’d assumed it would be.

Time to setup Seaside. I’m no Linux expert, but I see other services running out of /etc/serviceName so I’ll setup my Seaside services the same way. I’m going to run 10 processes, so I’ll create one directory per process, i.e. squeak1, squeak2, etc. Using daemontools I simply have to setup a directory for my service with the files it needs and a shell script called “run” that will kick off the service. Here’s the script…

#!/bin/bash
exec squeakvm -mmap 200m -headless SqueakProd "" port 3001

I’m using mmap to limit each process to a maximum of 200 megs of ram and then feed Seaside the port number to start on, so squeak1 runs on port 3001, squeak2 on 3002, etc. In each folder I put SqueakProd.image, SqueakProd.changes, SqueakV39.sources and chmod 755 the run script.

Because I’m using daemontools, I can now start my services by simply creating a symbolic link in the /service directory to the /etc/squeakX directory for each directory I created.

sudo ln -s /etc/squeak1 /service/squeak1

My services are started within a few seconds and maintained by daemontools. Now lets setup the load balancer. Seaside requires session persistence to do the magic it does, so we need to configure HAProxy to use a cookie to ensure a user gets routed to the appropriate server each time. All that talk about statelessness being necessary is crap, an old onion in the web framework recipe that isn’t at all necessary and is actually crippling.

sudo emacs /etc/haproxy/haproxy.cfg

using these settings for now (these could change based on load testing later)…

global
    log 127.0.0.1 local0
    maxconn 32000
    chroot /usr/share/haproxy
    pidfile /var/run/haproxy.pid
    uid 33
    gid 33
    daemon

defaults
    log global
    mode http
    option httplog
    option dontlognull
    retries	3
    redispatch
    contimeout 5000
    clitimeout 50000
    srvtimeout 50000

listen smalltalk 0.0.0.0:8080
    mode http
    cookie SEASIDE insert nocache
    balance roundrobin
    server app1 127.0.0.1:3001 cookie app1inst1 check
    server app2 127.0.0.1:3002 cookie app1inst2 check
    server app3 127.0.0.1:3003 cookie app1inst3 check
    server app4 127.0.0.1:3004 cookie app1inst4 check
    server app5 127.0.0.1:3005 cookie app1inst5 check
    server app6 127.0.0.1:3006 cookie app1inst6 check
    server app7 127.0.0.1:3007 cookie app1inst7 check
    server app8 127.0.0.1:3008 cookie app1inst8 check
    server app9 127.0.0.1:3009 cookie app1inst9 check
    server app10 127.0.0.1:3010 cookie app1inst10 check

Then I need to enable the proxy, it’s disabled by default.

sudo emacs /etc/default/haproxy

and set…

STARTUP=1

then restart the service

sudo /etc/init.d/haproxy restart

Now I hit the box on port 8080 with a web browser to ensure everything works, it does. I now have 10 load balanced sticky session enabled instances of Seaside running behind HAProxy, sweet! Time to setup Apache as the front end to this beast to offload all the static content, URL rewriting, HTTP compression, HTTPS, and logging to it. Only dynamic requests will be proxied to the Seaside cluster. This also allows me to mix in other frameworks when necessary (Rails, .Net), all proxied behind Apache.

Now I want to disable the default site and create a new virtual host…

sudo a2dissite default
sudo emacs /etc/apache2/sites-available/linuxweb1

with the following settings…

NameVirtualHost *:80

<VirtualHost *:80>
    ServerName linuxweb1
    DocumentRoot /var/www
    RewriteEngine On
    ProxyRequests Off
    ProxyPreserveHost On
    UseCanonicalName Off

    # http compression
    DeflateCompressionLevel 5
    SetOutputFilter DEFLATE
    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    #proxy to seaside if file not found
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteRule ^/(.*)$ http://localhost:8080/$1 [P,L]

    # Logfiles
    ErrorLog  /var/log/apache2/linuxweb1.error.log
    CustomLog /var/log/apache2/linuxweb1.access.log combined
</VirtualHost>

Now I need to enable Apache’s proxy, it’s disabled by default.

<Proxy *>
    Order allow,deny
    Allow from all
</Proxy *>

ProxyVia Block

and enable the new site and reload Apache

sudo a2ensite linuxweb1
sudo /etc/init.d/apache2 force-reload

Now I just check the box by hitting it in my web browser, http://linuxweb1/seaside/config, verify everything works. It does, my session sticks to a single Seaside instance. It’s easy to tell if something is setup wrong, without sticky sessions no Seaside link works. All in all, I’m very pleased with this setup, it runs great, performs well, and being Linux, should be easy to replicate to new servers as I add them.

I’ll just pretend everything actually went this smooth, in reality, there were many points during this install where I had to stop and learn something new about Linux, or about configuring the various components required. In reality, my brain hurts a little after all this, but in a good way. I tackled a lot of new stuff all at once, but I had a lot of fun doing it.

If anyone has a better setup or pointers about mistakes I’ve made, I’d love to hear about it, this is my first crack at using Linux as a web server.

NOTE: I left out the samba setup because it deals with various things with my local windows network that aren’t relevant to this setup. As with any article of this detail, I may have overlooked some step I took but forgot to write down while doing so, so I’ll make corrections as they come up in any comments.

UPDATE: Thanks to a tip in the comments, and having learned Linux a little better now, I use “aptitude update/upgrade/install” rather than “apt-get update/upgrade/install” because aptitude will track dependencies and clean them out automatically when I uninstall stuff.

UPDATE: Since I’ve switched to Linux, my Seaside site has become incredibly stable and much faster than when it was hosted on Windows 2003 server. Part of the speedup comes from HTTP compression, however, the CPU load is now less than before. The hardware is slightly different as well. I went from 3 dual processor windows servers to 2 dual (both hyper-threaded so looks like 4) processor Linux servers. So it’s not an apples to apples comparison, but I’ll give Linux the credit anyway ;)

Truth is, I was always a Microsoft guy, and that simply included Windows along with all of their development products. I used to be a hardware/network technician. I’d setup and maintain networks for medium to small businesses. Windows was always the way to go here, it’s what the users were accustomed to and expected. I’d usually setup a Windows NT server and from a dozen to maybe 30 client computers running various version of Windows including NT workstation. So Windows was just something I was always familiar with.

Even back then, I had the occasional urge to try other things. One of my first experiences with Linux involved using it as a firewall for a windows network on some cheap throwaway hardware that wasn’t good for much else. But it always seemed a pain to use, and I didn’t really understand it, despite having it working quite well for what I intended. I just didn’t see the point of not having a nice GUI and using cryptic commands to do everything.

Later, I learned to program in VBScript and VB using ASP and SQL. I became a web developer and abandoned the hardware gig. Software was so much more interesting. ASP became ASP.net, and VB became C# when I realized how crappy a language VB actually was. What made me want to change was my discovery of the original Wiki. I found a place where real programmers hung out and discussed anything and everything. I realized the world was bigger than VB. VB.Net fixed many of the issues with VB and is pretty much equiva