I decided the other day that it was time to learn a bit more about Pollock. After loading up the latest Pollock code from the VW Public Repository, I decided the best place to start was to go to the source. Sam's blog about Pollock has some real nice examples and walk-throughs. It is a bit dated however, so I'm going to add my own notes here are I go.

All was going well until I got to his entry on "How to Build a GUI With Pollock - Hooking up the Interface". Since writing this, the change mechanism has been... changed. So below are the changes I made to get this example to work. You will need to use these changes in subsequent entries in his blog. As I go forward with Pollock, I'll try and add any additional changes here to make things easier for anyone else.

hookupInterface 
	(self paneAt: #TreeView1) when: SelectionChanged do: [:ann | self fillProtocolList] for: self. 
	(self paneAt: #ListBox1) when: SelectionChanged do: [:ann | self fillMethodList] for: self. 
	(self paneAt: #ListBox2) when: SelectionChanged do: [:ann | self displayMethodSource] for: self.
 
 
fillProtocolList 	
	(self paneAt: #TreeView1) selection ifNotNil: [:value | 
		(self paneAt: #ListBox1) list: value organization  categories asObservedList
	] 
 
fillMethodList 	
	(self paneAt: #TreeView1) selection ifNotNil: [:classValue |
  		(self paneAt: #ListBox1) selection ifNotNil:[:protocolValue |
  			(self paneAt: #ListBox2) list: (classValue organization listAtCategoryNamed: protocolValue) asObservedList
 		] 	
	]  
 
displayMethodSource 	
	(self paneAt: #TreeView1) selection ifNotNil: [:classValue |
  		(self paneAt: #ListBox2) selection ifNotNil:[:methodValue |
  			(self paneAt: #TextEdit1) model value: (classValue sourceCodeAt: methodValue)
 		]
 	]

I found this interesting article in CIO magazine. It is a good case example of what I struggle with on a daily basis. Many of you may remember the old adage from many years back “you can’t go wrong with IBM”, in fact the decision makers who used that line just simply didn’t have the guts to implement unique solutions. Today it seems that adage would be “you can’t go wrong with .NET or Java”. When in fact if you look at the productivity you get with Smalltalk, there is significant reason to use a product that is not “mainstream”. How can you get a competitive advantage over the other guy? Use tools that let you focus on the business problem and not the language restraints. I’m not some “nuts and bolts” coder, I’m a business applications architect/developer who deals with a lot of complexity. While I believe in having a thorough knowledge of the business problem you are solving, I do not believe that requires a long and tedious design process. Odds are you will be changing that design as you go and enhancing it somewhere down the line. Being flexible while developing makes a better product in the long run, one that fits the user’s needs better, solves the problem better. If you are using tools that let you make those changes more efficiently, you can embrace the process of change during development, instead of fight it.

Better products, better maintainability, agility, faster time to market. That’s what CIO’s should be looking at, not “nobody ever got fired for choosing IBM”. It's that sort of mentality that stifles real advancement.

Recently I needed to output some data into Excel and create a nicely formatted page. Using the Com- Automation Examples package provided with VisualWorks, I was able to create some nice excel spreadsheets. I packaged up those extensions and published them to the public repository (Com- Automation Examples Extensions). While there are still a ton of things that could be added, I figured that this would be a good start and hope that others add in functionality as they need it.

If you want to look this over, load the package from the public repository and look at the examples on the class side of ExcelApplicationController.

One of the things I did early on when I moved our code into Store was revise the blessing levels.

The blessing levels I created in house more closely correspond to the way we develop and release code. As a result, I came up with the following levels that progress from development work being done by an individual, to shared development work and all the way up to Production Release

Broken - Code that was published that is non-functional and should not be the base for future work

Work in Progress - Work being done by an individual developer and should not (at this stage) be merged with any other projects

Development - Work being done by more than one developer (so it may need to be merged within the project)

Wait for Alpha - Code that is expected to go into Alpha testing but is being held up due to some other reason

Ready for Alpha - Code that is ready to be put into Alpha, but is not there yet

Alpha - Code that has been released to Alpha

Wait for Beta - Code that is expected to go into Beta but is being held up due to some other reason

Ready for Beta - Code that has been released to Beta

Beta - Code that has been released to Beta

Wait for Production - Code that is expected to go into Production but is being held up due to some other reason

Ready for Production - Code that is ready to be put into Production but is not there yet

Production - Code that has been released to Production environment.

To me at least, this reflects the path that code may go through on it's way to a production release.

With the developers that I've worked with and used these levels with, we have an understanding that something "waiting" is ready to go, but requires something else be done (usually something like a db change), while "ready" signifies that the code can be released to that blessing level by the proper person and something at the blessing level (ie Beta), has actually been released to that area for use by the end user.

For more information on how I deploy my applications, see Running the Deployed app

Development on our system takes pace at a rapid pace, it’s not uncommon for me to release new/fixed code many times a day. Generally these are small enhancements, incremental development or even “preview” code that I want only specific users to run. So it is not uncommon to have three different versions of the code “out there” at any one point.

I’ve divided up our releases into Production, Beta, Alpha and Testing. The first three types correspond to the blessing levels I use and the final is an area I use mostly for myself to test and debug runtime issues. My deployment procedure is pretty simple, create the .pcl files, copy them to the appropriate directories (corresponding to the release types) and have the user restart.

The end user actually executes a .cmd file. This file copies all of the application down to the local hard drive (in a directory corresponding to the release type). This includes visual.exe, all .pcls from Visualworks that are used, all of my .pcls and any configuration files. It then uses the start command to launch visual in a new process so that the .cmd file can exit and the command window disappears.

The .cmd file starts by changing to the local hard drive and verifying that the target directory exists using the following command

IF not Exist C:\Production731\prn md C:\Production731

So it will create the folder on the fly if the local drive does not already have a folder named it.

The copy command (I use XCopy) uses the /D and the /Y options, /D ensures that only newer files are copied down (making the startup process much faster) and the /Y eliminates any “overwrite this file” messages that the command processor might throw.

Here is an example of the start command which will start my application in another process, thus allowing the command window to close.

START Visual.EXE Runtime.im -cnf myApp.cnf -notifier MyNotifier -doit 'MyApp open'

By copying everything locally and then running the application, I do not have issues with copying the .pcl files out onto our network during a busy time. The actual files on the network are not “in use” by anyone directly.

You can see that my release directories also include the version of VW that we are running. This lets me then migrate users to the next version in a much more controlled fashion. The shortcut that the user has to start the application actually points to a general .cmd file for Production/Beta/Alpha on our network. In that .cmd file, I call another .cmd file for the specific version of VW that I am running. That way, when I am ready to move Beta users over to VW7.4.1, all I do it edit the Beta.cmd file on our network to point to the Beta741.cmd file. The end users shortcut on the desktop is not changed, so there are no changes on the workstation that we need to make. This also adds in the ability to revert back to 7.3.1 should I find anything that is unacceptable. Since I use release directories with the VW version number as part of the name, there are no issues with running a mix of the wrong code.

Down the road, if I want to clean up the local users hard drive, I can always insert a command in the .cmd file to delete a previous release directory should it exist.

In practice I’ve found that these techniques make deployment much easier to manage. I can easily place Alpha users on a different version of VW, or have Beta users running different code than production. I may release code in the middle of the day and ask a specific user who requested a change to restart. This gives them the new code but does not disrupt any of the other users.

Here is a listing of one of my .cmd files

@Echo off Echo Starting Target Trading II - 2005 Beta Version ...

Echo Updating Source Code Echo Please wait....

REM Code to update the local workstation with new code

IF not Exist C:\TradingBeta731\prn md C:\TradingBeta731 C: CD \TradingBeta731

REM DEL . /Q

XCOPY I:\Forest\Apps\VisualWorks7.3.1\*.* C:\TradingBeta731 /D /Y

XCOPY I:\Forest\Apps\TargetTrading\Beta7.3.1\*.* C:\TradingBeta731/D /Y

XCOPY I:\Forest\Apps\TargetTrading\bmp\TargetIIBeta.bmp C:\TradingBeta731\Herald.bmp /D /Y

C:

Echo Code update complete.

CD\TradingBeta731

START Visual.EXE Runtime.im -cnf trading.cnf -notifier TargSysNotifier -doit 'TargetFrameApp open'

One of the things I do every time I migrate my apps to a new version of Visualworks is start by upgrading my “Developers Tool”. While I’ve found some great add-ins in the public repository, I’ve always customized the VisualLauncher with buttons and hot keys to make myself as productive as possible. VisualLauncher is still open in my image, so that I can get to everything thing it offers, but my DevTool is customized to my environment, the way I work.

I’ve got the Transcript in it as well as many of the Menu options that VisualLauncher has, but I’ve added in a section at the bottom with buttons (and hotkeys) for my most commonly used “stuff”. I'll try and figure out how to show it below and I’ve listed some of the buttons options I use. What options would you add?

My development tool also contains a list of My Bundles (I exclude all the system bundles). By selecting a bundle I can easily create .pcls files and then release them to different development and production directories. This makes the process of releasing code to my users fast and painless.

Here are some of my more usefully buttons

Browse class/Implementors/Senders - I use these, but I find that the hotkeys are much more convenient. When I upgrade to 7.4.1 (currently in progress). I need to make my hotkeys more consistent, which will require me to change a few of them.

Garbage collect - I’m always using this to make sure I don’t have stuff left around from debugging before I save.

Process Monitor - More recently I added this, because it helps me further clean my image before saving it.

Published items/More recently published items - Standard options from the VisualLauncher menu

Sweep Alpha/Sweep Beta/Sweep Production - Works like “More recently published” but only for those packages/bundles at the specified Blessing level or above (Note that I’ve modified my blessing levels to be a bit different than the standard ones).

Show SQL - This toggles a global variable I use in my persistence framework which will send all SQL commands to the transcript. Very helpful in tracking down issues with SQL interaction.

Create - Will create a .pcl file using the bundle I have selected in my bundle list. Will not let me create a .pcl on unpublished code (unless I enable that option).

Release - Will copy the .pcl file (created previously) to a list of directories (as presented to the user). My options for release are things such as “Production Environment”, “Beta Environment”, “Alpha”, “All environments”. This copy will first “archive the existing.pcl file (and keep the most recent 10 version of it) so that I can back out a release quickly.

Target - This is the name of the main application and this button just launches it. I also have hot keys for launching it.

Hot keys

Ctrl-A Find all senders of halt (and althalt) that are in the image. This excludes halts that are in the VW system code. As a matter of procedure, I never release code that has halts or althalts, I therefore always use this option prior to creating a .pcl file and releasing it.

Ctrl-B Browse a class

Ctrl-Q Browse implementers

Ctrl-W List VW windows

I decided to jump into the world of blogging in order to demonstrate some of the techniques I use while writing/maintaining a complex financial application in Visualworks. I’ve been using Visualworks for the last 8+ years, mostly developing a comprehensive Portfolio Management/Risk evaluation system for several hedge funds. While over the years I’ve had help in writing the code and designing the application, it has been myself who has been the overall architect for the systems in place. As a result, I’ve developed techniques/procedures/tools to help manage and enhance these applications that I hope you will find useful, or at least thought provoking.

As of this writing, I am the only developer on this system, so I play the roles of architect, developer, tester, advocate, operations manager (I do get some help in this area) and anything else related to this system. It is a testament to Smalltalk that I can not only continue to maintain this system in production (it is quite extensive) but also continue enhancements.

Please feel free to add constructive comments to my blog and encourage the use of Smalltalk out there for real-world applications

Chip