TulipeMoutarde.be

As usual, this post is most a reminder for myself but it can be useful for others. In previous version of Seaside (prior to 3.0), it was possible to change the default session timeout by using:

application preferencesAt: #sessionExpirySecond put: 1200

It has changed with Seaside 3.0 and looked a bit more complicated now:

application cache expiryPolicy configuration
  at: #cacheTimeout 
  put: 1200

If I’m missing something, tweet me :)

I’m polishing a very small package to interact with ogone, a payment platform, from a Seaside application. So it’s time to write a Metacello configuration to share it easily.

I always have hard time to read Metacello configurations and wonder if a vertical alignment wouldn’t help. Basically, I find this:

baseline10: spec
  spec for: #common do: [
    spec blessing: #baseline.      
    spec
      repository: 'http://www.squeaksource.com/ogone';
      package: 'Ogone-Core';
      package: 'Ogone-Seaside-Example' with: [spec requires: 'Ogone-Core'];
      package: 'Ogone-Tests'           with: [spec requires: 'Ogone-Core'].

    spec
      group: 'default'         with: #('Core' 'Seaside-Example' 'Test');
      group: 'Core'            with: #('Ogone-Core');
      group: 'Seaside-Example' with: #('Ogone-Core' 'Ogone-Seaside-Example');
      group: 'Tests'           with: #('Ogone-Core' 'Ogone-Test')
  ].

More readable than this:

baseline10: spec
  spec for: #common do: [
    spec blessing: #baseline.      
    spec
      repository: 'http://www.squeaksource.com/ogone';
      package: 'Ogone-Core';
      package: 'Ogone-Seaside-Example' with: [spec requires: 'Ogone-Core'];
      package: 'Ogone-Tests' with: [spec requires: 'Ogone-Core'].

    spec
      group: 'default' with: #('Core' 'Seaside-Example' 'Test');
      group: 'Core' with: #('Ogone-Core');
      group: 'Seaside-Example' with: #('Ogone-Core' 'Ogone-Seaside-Example');
      group: 'Tests' with: #('Ogone-Core' 'Ogone-Test')
  ].

Am I the only one ?

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 =)

I wanted to display or hide the tool bar on a Seaside application. It turned out to be pretty simple.

To remove it:

app configuration 
   at: #rootDecorationClasses
   addAll: #() 
   removeAll: (Array with: WAToolDecoration)

And to show it:

app configuration 
    at: #rootDecorationClasses 
    addAll: (Array with: WAToolDecoration)

Another useful snippet to retrieve an application from its name:

WAAdmin defaultDispatcher handlerAt: 'wapict'

Seasiders won’t find this exciting but this post is more a reminder for myself than anything else. If I’m doing something overcomplicated for nothing, shout my ignorance in the comments ;)

I’m currently playing with Seaside (a Smalltalk web framework) for a pet project. As you maybe know, Seaside is, by default, not very friendly with URLs. I wanted to have bookmarkable URLs for user convenience and for search engine. Ramon Leon explains how he managed to get nice urls for his blog in a super-interesting blog post.

When playing with WAAnchor methods, I fought with a weird behaviour:

html anchor
  callback: [self moveToPage: page];
  useBaseUrl;
  extraPath: page slug;
  with: page title.

did not work, while

html anchor
  useBaseUrl;
  extraPath: page slug;
  callback: [self moveToPage: page];
  with: page title.

worked fine. Can you see the difference in these two snippets?

The reason of the resulting bug is quite simple but is hard to spot when you’re not careful: the method useBaseUrl should always be the first to be called in a method cascade on a WAAnchor. Indeed, both extraPath: and callback: will affect the url of the WAAnchor while useBaseUrl will reset it. This reset will cancel all the operations you’ve done before on the url of the WAAnchor.

Moral of the story: beware of side effect (or How I Learned to Stop Worrying and Love Functional Programming)