STIC 2013 – tODE: A New Development Environment for GLASS

Video of my talk on tODE at STIC 2013:

Link to my slides.

ESUG 2011: GLASS 2.0 video available

Click on the picture to view the video of my GLASS 2.0 talk from ESUG 2011. Slides from my talk are available here (SlideShare) and here (pdf).

During the talk I cover:

• a short overview of GemStone/S
• a bit about VMware’s Cloud Foundry and GemStone/S
• and tODE

tODE rEPOSITORY rELOCATED

The tODE repository has been relocated to the SS3 repository.

It’s new home is http://ss3.gemstone.com/ss/tODE/.

For more details see the announcement on the tODE mailing list.

Photo by http://www.flickr.com/photos/gagilas/5955775677 / CC BY-SA 2.0

Transferring packages between repositories with Gofer and Metacello

[1]

When you have a bunch of packages that you need to transfer between repositories, you can use Metacello and Gofer to simplify the task.

With the SS3 repository coming on-line, I decided to move tODE development to it’s own repository on SS3. The scripts that I wrote turned out to be pretty simple, but not necessarily obvious, so I thought that they’d be worth sharing.

The basic idea is to use Metacello to identify the packages that you want to transfer and use Gofer fetch to download the selected packages from the source repository into the local cache. Then use Gofer push to upload the packages from the local cache to the target repository.

In my case I want to transfer all versions of the packages used in tODE 0.1:

| gofer |
"Identify the source repository"
gofer := Gofer new gemsource: 'Naviode';
	package: 'ConfigurationOftODE' yourself.
"Traverse all packages defined in version '0.1' of the tODE configuration"
(ConfigurationOftODE project version: '0.1') packages do:[:spec |
	"Use the #name and #package: messages and Gofer will fetch 
	all versions of the Monticello package"
	gofer package: spec name ].
"Initiate the download with the #fetch command"
gofer fetch.

After the above expression completes, I can then initiate the upload:

| gofer |
"Identify the target repository"
gofer := Gofer new url: 'http://ss3.gemstone.com/ss/tODE';
	package: 'ConfigurationOftODE' yourself.
"Use the same algorithm for identifying the packages to be pushed"
(ConfigurationOftODE project version: '0.1') packages do:[:spec |
	gofer package: spec name ].
"Initiate the upload with the #push command"
gofer push.

If you want to transfer only the latest versions of the packages, substitute the following expression in the above scripts:

"Traverse all packages defined in version '0.1' of the tODE configuration"
(ConfigurationOftODE project version: '0.1') packages do:[:spec |
	"Use the #file and the #version: messages and Gofer will fetch
	only the specified version of the Monticello package"
	gofer version: spec file ].

—–

[1] Photo by http://www.flickr.com/photos/blueship/137771066 / CC BY-NC-SA 2.0

A Peek at tODE

[1]

tODE – the Object (centric) Development Environment is a Smalltalk development environment written in Seaside that runs in Pharo and GemStone.

In preparation for ESUG, I created (with the help of James Foster) an introductory video and a One-Click Pharo download.

I created tODE for a couple of reasons:

• GemTools is slow over the WAN. Neither the GCI interface [pdf] nor VNC interface is fast enough for me. A faster development environment for deployed GLASS applications is sorely needed.
• With Platform as a Service becoming a popular way to deploy web apps, development-level access to deployed applications is often limited to HTTP (including VMware’s Cloud Foundry). In these cases, even a slow GemTools is not even an option. What Smalltalk programmer in their right mind would choose to resort to print statement debugging for deployed applications?
• I wanted to provide GLASS users a development environment with integrated Metacello support. Alexandre Bergel made an excellent start with the MetacelloBrowser, but like most tools in the traditional Smalltalk development environment, the MetacelloBrowser was Yet Another Tool Window (YATW) and not directly integrated into the development environment.
• While not a reason for creating tODE, it is very important to me that tODE run on multiple platforms. The fact that I’ve implemented tODE in Seaside means that tODE could run on every platform that supports Seaside. I’ve licensed the code for tODE under the MIT license, so licensing issues will not stand in the way.

I started work on tODE in April and by mid-June I started using tODE to develop tODE as much as possible. I’ve been able to do about 80% of my development work in tODE, only having to drop out of tODE to perform operations not available yet.

With almost 2 months of development experience under my belt, I’ve found a bunch of things that I’ve done right and a couple of things that I need to change before tODE is really ready. There are a handful of technical changes I’d like to make to the basic architecture and a couple of issues in tODE 0.1 that I need to solve:

• The debugger is more of a stack inspector than a real debugger. Some of the difficulty is due to the way that the JQuery components make their callbacks into Smalltalk and some of the difficulty is probably due to my ignorance. I can capture the stack easy enough, but the Smalltalk process that I want to debug is also the process that is supposed to return the HTTP response…
• I am not happy with how tightly coupled the business logic and rendering code has become. By it’s very nature, the tODE rendering methods are pretty small (we’re not talking about the complex interactions of a multi-pane code browser here), but disentangling the small fragments of business logic from the small fragments of rendering code looks difficult from my current perspective. I would prefer a cleaner separation, but I have not spent time investigating a solution, so hopefully there’s a simple solution to be found ‘just around the bend’.

All in all, I personally enjoy using tODE so I think that tODE will form the basis of a solid Smalltalk development environment that can extend the Smalltalk development experience to applications that have been deployed in the cloud.

Of course I am interested in feedback so I’ve create the tODE mailing list where you can share your thoughts and criticisms.

—–

[1] Photo by http://www.flickr.com/photos/tamdotcom/518999335 / CC BY-NC-ND 2.0