Some months ago I decided myself to work with Seaside, and to develop all my upcoming web applications with it, if possible. If not possible, I will fall back to Rails. So far I am very happy with my decision and the current projects. One of it just went live (it's a closed application, not for public). Its a highly specific course management tool, deals with courses and subscriptions, manages course capacities, sends emails to paticipants and course leaders, generates PDF on the fly, automatically confirms courses or cancels them etc. And here is the proud footer:
It's german but you can guess the meaning. That Monticello package name as a version description really gives me the confirmation of "Yes, I've made it with seaside!" (wouldn't believe it, else).
Here are my conclusions and some internals (unordered):
- Working with Smalltalk for the problem domain is really cool (As expected).
- Having Seaside as the web framework is a productivity booster. Seaside directly improves user friendliness of your application, since it never is a problem (It's a joy!) to add an extra user interaction step here, add an extra state changing link there etc. I do not want to see the Rails code, which would do the same job...
- Gemstone as a Database really rocks. It makes you feel like there is no such thing like a database. That really, really cleans my head. And the code. Due to rather low data volume, I did not even need to create Gemstone indexes on my data.
- As a good strategy I simply created a "Database" class which holds all the top level data collections in a singleton instance, and provides a lot of querying features ("finders") and maintenance tasks. So, in the problem domain I still have a database, but not in the server domain. And that's perfect.
- For backup of the data (besides the backup of the whole Gemstone repository) I use SIXX and just periodically dump out my "database" instance to a timestamped file. SIXX dumps are also cool, because I can load in the data objects from the live Gemstone system into my Pharo/Squeak development image.
- For sending emails I use the simple command line tool "sendEmail" (not sendmail). Available as a package on most Linuxes. It supports SMTP authentication, which I needed. I execute it asynchronously so the web application will not pause while sending.
- For generating PDF I use the command line tool "htmldoc". From Smalltalk I generate a HTML file and convert it to PDF with htmldoc (via shell execution with System>>performOnServer:).
- Getting a 64bit server was one of the challenges, since all our existing servers are 32bit. Needed new infrastructure. It now runs as a KVM virtual machine with Ubuntu Hardy 64bit on a brand new Ubuntu Jaunty KVM host machine. (Good to know for the future, that Ubuntu's default since version 9.04 Jaunty is 64bit.)
- Frontend server is cherokee. I used to have lighttpd for that task, but gave cherokee a try. Nice to setup and configure. No problems so far.
- A problem was (and partly still is) the translation into german. Date names, Magritte button labels, error messages etc. I created a monticello package, which just rewrites some key methods in Gemstone, Magritte etc. And I defined a SeaShell task which installs German date names into Gemstone. Definitely no award-winning strategy, but since beeing "at the end of the pipe" quite pragmatic and OK for me.
- Deployment done with SeaShell. Improved it alot while working on that project. Good to have it as my deployment servant. It's a command line oneliner to deploy a new monticello package version to the live machine, doing a handful of steps automatically, like writing libraries to disk, flushing magritte caches, registering the application, set to deployment mode, removes the "/seaside" path prefix, defining a default entry point for the root URL etc. etc.
- A rather painful thing is that I develop on Squeak/Pharo and deploy to Gemstone. There are still some incompatibilities between those dialects (as expected) which are real pitfalls. But it's good to know, that this is beeing worked on, and it will get better and better. I did get some help from the Sport portability library (but did not manage to install the same version of it on Squeak like it is within GLASS...).
Meta conclusion: I have gained a lot of speed and productivity, having written the above mentioned helpers and libraries (will share them, if shareable) and having worked intensively with Seaside and Magritte. That gives me a very good base for future projects with seaside!
SeaShell, the shell based seaside deployment suite
Did I mention that I love Smalltalk, lately? If not: I love Smalltalk! And I want to say "Thank you!" to all of you, who make this scene such a nice place for hygienic software.
The Gemstone Smalltalk system has been around for a long time, but just lately has been made also available as a no-cost community version. Gemstone really rocks, it feels like an ideal world for a software developer. It's Smalltalk, it's robust, it scales and persists your stuff like magic! Imagine how many problems are automatically solved (or more precise: don't even show up) by such an underlying machine! But shhh! Don't tell anyone! Let them love their daily fight... ;-)
Coming from the Rails world, I clearly see that there is yet missing some proven best practices for the hosting of a Gemstone powered seaside application server. Progress on GemTools is moving fast, that's super fantastic! And I always felt that there should be a bare access to the deployment, a more basic direct access from the shell, too.
In the world of Rails there is a solid tool called capistrano, which you can use as a deployment servant. The cool part is, that capistrano is not married with Rails, it's basically just a remote control for your server, let's you define tasks and their dependencies. OK, too bad it's not written in Smalltalk but it does an excellent job as a command line tool. And come on: Ruby is a good friend of Smalltalk, isn't it?
Now, getting serious
I wrote some of these handy capistrano tasks for seaside deployment and want to share those with you. These recipes currently only cover my personal needs with the following kind of seaside hosting environment: Gemstone as seaside server, lighttpd as frontend server and load balancer, everything running on Ubuntu 8.04.1. It's far from complete or rock solid, but I want to share it as early as possible. There is plenty of room to add more tasks for other tools and environments, of course. And I plan to add more features, as soon as I need them. Contributions welcome, of course!
The goals of SeaShell are:
- Handle multiple concurrent gemstone seaside applications (each with its own stone), running on the same server machine.
- Easy to add tasks for your individual environment and project.
- Easy to run the tasks from the shell
- Fast execution
Very important: SeaShell is not meant to get a replacement for GemTools! GemTools solves more the task of "working IN the system", and SeaShell solves the task of "working AROUND the system" dealing also with non smalltalk tasks like stopping the frontend web server etc. SeaShell should be a companion tool to GemTools for the seaside developer.
As for now, besides some handy standard tasks, SeaShell gives you the ability to run multiple Gemstone powered applications on one server. It does that with this rules:
- Each application has it's home folder in /opt/gemstone/applications/ with it's own extent file, web document root, etc.
- All applications share the same Gemstone system installation
- Switching between applications is done by setting the GEMSTONE_* environment variables accordingly.
How to install
- Get it via github.com from here: http://github.com/dassi/seashell (either with git clone or as a zipped file, direct link here)
- Place the contents in a folder called "deployment" inside your project folder
- Read README
(Maybe I will make an easy to install ruby-gem soon)
I hope it's useful!
Currently I am teaching Scratch to swiss teachers in two courses. This gives me the opportunity to intensively work with Scratch again. Scratch has attracted me some years ago, because it is grown out of the Smalltalk/Squeak scene. Scratch is built with Squeak. Since I did the initial job of translating it into the German language, there have been a number of activites in my business around Scratch.
Scratch really enables the course members to learn to program. Now that depends what you call "to program": Is it to know the native integer type's boundaries? Is it to know how to allocate memory? Is it to know how to manage threading? Is it to know whether an array starts with index 0 or 1? Is it to know the syntax and the compilers friendly error messages?
No. Basically none of the above (and lot more, you get the idea) is essential if you start to learn programming. In first place, you program with your mind, not with a tool. So that leads to: Don't annoy your pupils with C (no matter how many "plusses" or "sharps"), Java, Pascal, Visual Basic, etc. These tools disturb your mind, while learning how to program a solution.
Use Scratch instead, if your pupils are beginners. And use Squeak (Smalltalk) if you go further.
See some Scratch work of mine and my favorites in my profile on the Scratch website here.
UPDATE: Scratch in the news: English and german.
"Here I go" would be the better title for this very first blog post. Finally "I go", I've done it: I took the time and setup my own blog.
OK, I could have taken one of the super simple, widely used blogging software - but hey, what is this blog all about? "Hygienic software"? That's why this blog is powered by Pier!
You might ask: "Wait a minute! Hygienic software development, what the heck is that?" So, here is the solution: As a software engineer I hate to work with tools which are bad for my mental hygiene and therefor are bad for my work as a software developer. Here is what I don't do: C, C++, C#, Java, PHP, Delphi, and all the related stuff. These tools are not hygienic.
"What tools are hygienic, then?", you ask. "Pure, beautiful, elegant things. Such as 100% object oriented engineering environments, for example", I reply. My main tools of choice are:
- Smalltalk
- Ruby
- Seaside
- Ruby on Rails
- Squeak
- Gemstone
- and related.
(...with a strong preference on Smalltalk and Seaside). They really enable me to focus on the problem domain, and not to struggle too much with technical implementation details.
As a consequence to my "hygienic" committment I do not work with Windows. I work on a Mac and with Linux servers.
In this blog I will write on my work as a software developer.