Pharo Smalltalk experience report, part I

Written on August 11 2011.

Hi there, I’d like to share some of my latest experiments with Pharo. This post is not very well structured and certainly needs some polishing but time is scarce.

I use Ruby and Rail for my daily work at agilitic. I’ve always dabbled with Smalltalk (Squeak then Pharo) and wanted to build a real world project with it. Wapict.be was the ideal candidate: not too big while not trivial.

The idea behind wapict is simple: become the reference of photography in Wallonie-Picarde, a region of Belgium. We sell stock pictures in digital or printed format, provide photographers for events and experiment with photography techniques…

It started with a simple presentation website and has now some nice features for photographers. A lot more is planned (e.g., buy online with credit card) but the project is advanced enough to do a first post about it.

Stack

Currently, wapict is running with:

• Pharo 1.3
• Seaside 3.0.5
• XMLSupport
• Fuel 1.4
• Zinc HTTP server

All managed via Metacello Configurations.

The project runs with the Cog VMs. Development is done on MacOS while the staging and production servers are running Linux. A big problem with Pharo is that there are no official supported VMs. You are there on your own and choosing a suitable VM can be tedious. Hopefully this will change in the future.

Persistence

The traffic is quite low and a single Pharo image can handle the load while sipping a coffee. Persistence is primitive right now: I serialize everything with Fuel on disk. Nothing really fancy but it works well for what I need.

Pictures are stored on disk and are served with Nginx. The originals are kept private and are not accessible from the public.

Deployment

At work we use Git + Capistrano or Vlad to deploy our rails applications. My usual flow is as simple as:

git pull
git commit -am "fixed bug #456"
git push
cap staging deploy

and hopla my code is in staging. Once validated, `cap production deploy` deploys on the production box. Easy.

It seems that there are no equivalent on Pharo or at least there are no common workflow, everybody has his own recipe to roll out new code.

I have added a link in the admin section that loads the latest stable Metacello release available. So my deployment flow is:

• commit modified packages
• update and commit metacello configuration
• login to the application and click on the update link.

Not too bad but I have to leave my Smalltalk environment to deploy. I’ll probably create a small webservice to perform administrative operations on the deployed image.

Tools

I only use the tools shipped with Pharo 1.3. Nothing really fancy but they work well. The default for code highlighting and code completion suit me.

I rebuild my development image as often as possible. Two benefits: I’m sure the whole project is easily loadable in a fresh image all the time and the mess I introduce in my image when developing is cleaned.

Conclusion

All in all, i’m quite happy with Seaside and Pharo. It is really refreshing to work with those when doing Ruby and Rails all the day. I cannot stand Rails when it comes to flow anymore. It just doesn’t feel right. I love to develop web applications with Javascript: I can code the behaviour much more easily than with plain HTTP requests and I feel this kind of joy when developing with Seaside.

What I really miss though is the possibility to login and open an IRB on a server. That’s quite dangerous in production but it helps a lot when checking the state of an application. What would be really nice to have is a set of remote tools to browse and debug an image from the outside. Some uses RFB to do that but I find it clumsy and slow.

I’ve recently discovered tODE, a development environment that runs on top of Seaside, I haven’t checked it yet but Dale Henrichs use it for 80% of his development.

All in all, my dream is pretty simple: Pharo 1.4 with Ring, Coral and remote tools =)