You are currently browsing the category archive for the ‘tODE’ category.
tODE – the Object (centric) Development Environment is a Smalltalk development environment written in Seaside that runs in Pharo and GemStone.
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.