The first meeting of the Vancouver Smalltalk Developer Group was pretty good! Nine people showed up, which is quite nice considering the size of the Smalltalk community and the fact that it was the first event. Unfortunately I forgot to take pictures, probably a side effect of interesting discussions ;)

We got the meeting room of a Waves coffee shop in downtown Vancouver, the venue is allright but there is no projector and we were kicked out of the room at 8.30.

The next event is on its way. The date is not decided yet but it will happen between the 11th and 16th of June (tell us what’s better for you in the doodle). If you are in the area, you’re more than welcome even if you’re not a smalltalker.

In the future, please subscribe to the Meetup group, the ESUG list or the SCONA list to be in the loop ;)

When loading a package with Monticello, a copy is cached in the directory ‘package-cache’ in your image folder. This is super useful when you need a package that you already have downloaded. Unfortunately, this cache is limited to the image directory. If you need that package in another image which is in another directory, you’ll have to redownload the package.

Here’s a little trick to have a global package cache:

MCCacheRepository default directory: 
  (FileDirectory on: '/home/fstephany/package-cache/')

Of course, adapt the path to your configuration. Thanks Mariano for the tips (original discussion).

Another super useful things is the ability to send stuff to sdtin, stdout and stderr. I don’t know if it was present prior Pharo 1.3 but I’ve just discovered how to play with the standard streams:

FileStream stdout nextPutAll: 'Yopla'

Browse the class side of FileStream for more ;)

Igor Stasenko summarizes what he does to avoid coding with hard dependencies in his code:

Rule #1. never make more than 1 reference to any class external to your package in your code. an exception is kernel classes.

which means, that you are allowed to do Set new or Array new, in any place of your code but never SomeFooClass new more than once.

If your code having such dependency, localize it in single method:

fooClass
  ^ FooClass

and then use self fooClass everywhere.. Like that, if you will figure out one day, that sand moves under your feets, you’ll have to change only single method. :)

I never felt the need of doing that when the refactoring browser can rename all that for you but it’s still make sense if you want cleaner code.

Thanks Igor :)

You’ve probably heard that Pharo 1.4 is out. This version contains many improvements (as software developers like to say) and some aspects have changed quite a lot.

One the Pharo team’s goal is to clean Squeak. Version 1.4 has made some critical steps toward this goal and more than 850 tickets have been closed. Impressive.

What is still lacking though is a detailed changelog of all the API changes. Sure, there’s a release note but hey what does Better headless support mean?

I’ve switched some of my projects from 1.3 to 1.4. I haven’t tested everything in production yet but here are my first surprises:

FS integration

The FileSystem (or FS) library has been integrated. FS is a replacement for the aging FileDirectory. Manipulating files is now much easier and the API is less chaotic than its predecessor. The FileDirectory is still there for compatibility reasons I guess but you shouldn’t use it anymore.

If you used the FileSystem library before, beware that the FS prefix has been changed to “File” (i.e., FSLocator becomes FileLocator). Update your code accordingly.

If your project has a MetacelloConfiguration that loads FS, you don’t need it anymore for 1.4

Startup scripts

That one was missing for quite a long time. Pharo will now look up in your home directory for startup file in the following order:

#{image_directory}/startup.st
~/.config/pharo/#{version}/startup.st
~/.config/pharo/general/pharo#{version}.st

This has bitten me when deploying an a server. I used to launch my image with the following:

exec $VM $VM_PARAMS $IMAGE $STARTUP_SCRIPT

where $STARTUP_SCRIPT is the path to a .st file. That file was named startup.st. My startup script was executed twice without I realized it. It took me some time to realize what was going on ;)

Beware, it seems that this feature is not reliable (or not implemented?) on Windows.

No default browser

Pharo 1.3 used to be shipped with OmniBrowser (OB). This is not the case anymore and the default browser is now the basic one. No advanced features, no refactoring, plain boring.

The best choice is to load Nautilus, a browser developed by Benjamin Van Ryseghem. There is a job on the CI build server which contains the latest version of Pharo 1.4 and Nautilus.

Unfortunately, I had some troubles with it. When using the build from CI, loading seaside didn’t work. And when I load Seaside in a clean 1.4 image and then loading Nautilus, some strange problems occurs (like the font changes). I haven’t really investigated yet but that smells like bleeding edge piece of software.

The browser is pretty cool though and it is definitely a huge step from OB. My muscle memory is still trained for OB, which complicates the transition :p

All in all

This release is a good one, the Pharo team did an awesome job and I can’t wait to see what the 2.0 will look like. They apparently changed their release process for a time-based versioning (à la Ubuntu). Time will say if it’s a good choice…

I recently needed to send emails from a Pharo image. There is a SMTP client integrated in the standard libray but I wanted to wrap the excellent Postmark REST API.

You can load it from SqueakSource 3:

Gofer it
     url: 'http://ss3.gemstone.com/ss/postmark';
     package: 'ConfigurationOfPostMark';
     load.

(Smalltalk at: #ConfigurationOfPostMark) project stableVersion load.

And you can use it like:

| email interface |
email := PMEmail new
  from: 'francois@wapict.be';
  to: 'francois@yopmail.com';
  subject: 'Test Application';
  textBody: 'Yeah baby';
  yourself.

interface := PMInterface new.
interface apiKey: 'blopblop'.

interface send: email.

The implementation is really basic and does not handle attachments at the moment. I use it on a staging application that will probably be in production in January. I will see how it behaves under small load and improve it if needed.

edit: you can now attach files to your emails !

I’ve written this article in June 2011 and never published it. Now that Nokia has shipped their phones and the Mango (aka Windows Phone 7.5) is everywhere, it’s maybe time to click on the publish button ;)

When reading reviews of WP7.5, Microsoft has fixed almost all the issues I had with my LG Optimus 7 phone. Unfortunately, it broke during the (awesome) Dour festival. The phone became crazy and kept rebooting. (In case you are wondering, fifteen minutes of cycling reboots keeps your phone hot). The shop where I bought it did not plan to get any Windows Phone soon so they gave me a Galaxy S2 (almost) for free.

While Android 2.3 is packed with wonderful features, it’s not as polished as the WP7 phone I owned but it usually works well. Android 4 is said to address this but I don’t think it will be as fresh and usable than Windows Phone. Anyway, here’s the short review I wrote back in June:

I was the first to be surprised when I came back home with a windows phone in my bag. Three months later, it’s time to report.

A bit of context: I’m a big fan of Apple products for seven years now (and I was a Linux user before). MacOS X is an impressive operating system: the geek inside me loves UNIX, the end user part of me likes the ‘everything works out of the box’ side of the Mac experience.

Long story short, I love this Windows Phone 7.

• Tiles are awesome. Simple, no gradient, no round corners, ni shiny effect, just the fact. Data-ink ratio is very high, Tuft would be happy.
• Menus are kept to their minimum. There are not tons of options everywhere. Microsoft provided a very opiniated way of using the phone and they made the right choice almost every time.
• All in all, this Metro UI is particularly well thought. Navigation follows a consistent pattern through the OS. Third party applications tend to adopt it.
• Animations are plain right. Very subtle, never too long, they are visually pleasant and serve their purpose very well. They bring a sensation of fluidity and smoothness.
• No custom ringtones. That sounds ridiculous but it clearly shows the direction taken by the creators of the OS.
• Actually one of the only possible customisation is to change the dominant color. My favourite is Magenta. The color will be used almost everywhere in your phone. Elegant.
• The Mac software is simple and easy to use. It synchronises your phone with iTunes' data. Don’t know if Apple appreciates but it works just fine

• I have mixed feelings about the web browser though. Navigation is fast and fluid but javascript performance and CSS handling sucks at best. The navigation bar disappear when you are in landscape mode. That’s quite weird. Microsoft says it is based on a mix of IE 7 and 8. Fortunately, they will ship IE9 with the next release of Windows Phone. The stuff that could have been added without too much boilerplate:

• They screwed up with the first update of the OS. It brought copy-pasting but deployment was a nightmare for Microsoft.

• Notification LED. My android phone had a small LED hiddden in the speaker. Even when you’re phone is in silent mode you can see in one eye glance if you'vre a text or missed a call. very useful

• No threads in emails. Epic fail.

• No tethering. Annoying in the train.

• No multiple calendars when synced with Google Calendar.

• I cannot find a good Remember The Milk app. WinMilk is way to slow to be usable (yeah, I know, it is open source it is up to me to improve it instead of complaining)

This week, Microsoft unveiled a new version of WP7 called ‘Mango’ or WP7.5. This update brings a lot of new features. Hopefully they won’t screw the whole Metro experience (fingers crossed).

All in all, forget Windows Mobile 6.x, Microsoft changed everything. The subtle rename from Windows Mobile to Windows Phone is not innocent.

I can’t believe I’ve just said something good about Microsoft software.

As a company or freelance developer you have probably encounter the dilemma of taking over somebody else code. On one side you are happy to get new work, on the other side dealing with legacy code can be frightening.

Here are some questions you will need to ask when you continue and maintain a project:

• What kind of client will you get when accepting the project?
• How was the relation between the previous developer and the client?
• Where is the project hosted? Do you have control over it?
• What are the dependencies of the project? Ruby 1.8.6, Rails 1.2? RMagick? Will you have to migrate it to newer versions at some point? Does the client understand that you need to upgrade libraries and frameworks?
• More generally, is the client aware that software needs maintenance?
• Will you be the one responsible for old bugs that are discovered after you took over the project? Usually the client sees a bunch a stuff not working once you start to work on the project.
• Have you considered a code review before accepting the project? Who did it? Someone external? The previous developer (hint: blink in red in your radar)?
• Will you need to implement big new features? How the previous developer used to bill the client for them?
• Is the client aware that you will probably be a bit slower than the previous developer when you start working on the project?

Many of these questions sounds stupid or simple good sense but a checklist is never too much when it comes to such a tricky decision.

Everybody likes to write new code. Maintaining code is usually less appealing.

I love to dig in somebody else code,to refactor it, to understand what the previous developer had in mind when doing it. I like to remove the small imprecisions here and there and to curse when I see useless javascript files or two hundreds lines of commented code.

From time to time, someone on the Pharo mailing list asks how to build a desktop application.

A long time ago, Smalltalk was a great way to make desktop apps. drag & drop, rich visual interface, mouse pointer. Yeah, the mouse was quite a big thing.

Things have changed. People expect consistency from the software they use. Not only in the look but also in the feel. They want their applications to be tightly integrated with their operating systems. If you’re considering a niche application where people only care about the functional part of the system, that could work. Otherwise I would not bet a penny on a smalltalk dialect.

Long story short, don’t use Smalltalk if you want to be the next WordPad or iTunes.

I’m not saying that Smalltalk is bad at user interfaces, new UI paradigms are tested with Smalltalk. Croquet and Newspeak, Gaucho are examples of some innovations in user interfaces (one for collaborating in 3D world, the other for IDE and GUI framework).

footnote: I actually have to mention that I’ve heard that Dolphin and ObjectStudio runs natively fine on windows.

After my previous post about the Pharo ecosystem, some people asked me more about a comparison of Smalltalk and Ruby. And how a Rubyist could leverage his knowledge when learning Smalltalk.

The two languages are class based, dynamic and their supporters like their clean and easy syntax. Actually, Smalltalk is sometimes considered as one of the father of Ruby. They share quite a lot and most of the patterns used in one can be easily expressed in the other.

This post does not cover the basic syntax of Smalltalk. If you want to learn it (15 minutes max), wikipedia should be enough.

Implementations

Ruby comes in different flavors: MRI, YARV, Rubinius, JRuby, Maglev, etc. So does Smalltalk. The principal difference is that they are no “official” distribution. Every dialect has its own ecosystem and tools. Some are open source, some are proprietary.

Choosing an implementation can be a quite challenging task. If you want to go the open source way:

• Squeak, the most famous implementation. The project has quite a long history. The development seems to have slowed down a bit 3-4 years ago but Squeakers are working hard now.
• Pharo, a fork of Squeak. The goal of the Pharoers is to produce a clean and industry-capable Smalltalk. It all started when some people were really pissed off by the inaction of the Squeak community. Backward compatibility was a pretext for doing nothing. Pharo moves fast and does not aim to stay backward compatible with Squeak. Many projects still runs on the two without a itch though.
• GNU Smalltalk, an alien implementation. You can use your favorite text editor with it. It is a clean implementation but it maybe misses a complete environment.
• Amber, a smalltalk that compiles to Javascript. Pretty young but already impressive. It can be used with Node.js or in the browser.

I’m not really interested in proprietary implementations but there are three big players in that field: Cincom Smalltalk, VA Smalltalk, Gemstone/S.

Gemstone is not only a Smalltalk implementation but also an extremly scalable object-database. Actually Maglev is a Gemstone based products. If you’re serious about Ruby, you should definitely give Maglev a look.

My favorite implementation is Pharo. I like the energy in the community and its direction. It is for me the best bet for the future. It very similar to squeak but this screenshot of the main menu is enough to convince me.

You can follow this thread on stackoverflow to get the opinions of others.

The Environment

Here comes the biggest problem when learning Smalltalk. That’s where people usually get lost. Smalltalk code does not lie on a plain text file. There are literally no “code time”, it’s always runtime. It would be like coding in an IRB session. You manipulate objects all the time. Consequences ?

• You can inspect object in live. You are working with a webservice and want to inspect the answer? Just inspect the response.
• Change values on the fly. You wanna know what happens if that variable is -5 instead of 5? Change its value to see what happens.
• You can actually code in the debugger. The debugger (or a stacktrace) is not an analysis tool anymore. You can actually code in it. A method is missing? Oops. Create it on the fly and continue the execution from where it failed.
• Fast tests, all the time. Corey Haines teaches you how to get fast tests in rails. You do not need this in Smalltalk as your web/test/whatever framework are already loaded. Of course, if your tests starts to rely on external depencies (disk/network/etc) without mocking, they’ll get slow. No surprises.

Actually some tools are starting to appear in Ruby. Pry is pretty damn cool Ruby tool. Once you’ll get used to Smalltalk environments you’ll want more.

When you load a library in your image, it lies next to your code. You can then read it, inspect it, put breakpoint in it and do whatever you want with it.

An image contains your code and all the libraries you want. It acts as a container and is completely independent from other images.

Metaprogramming, Object and Classes

Okay, that one is tricky. What do you expect from meta-programming?

• Adding methods on runtime? You are already in runtime.
• Handle method_missing? Welcome doesNotUnderstand.

As method_missing in Ruby, doesNotUnderstand must be used carefully. The usual advice applies in Smalltalk.

Actually defining a class in Smalltalk is just sending a message (“calling a method” in Smalltalk jargon) to the class Object. Adding a method is also a matter of sending a message to define it. The only difference is that you use tools to do it. Remember, it’s runtime and your environment is the running your code. That living environment comes with great responsibilities. If you try something along Object := nil I guess you’re a footing yourself in the foot.

If you want to learn more about the Smalltalk object system, I warmly recommend the chapter 13 of the Pharo By Example free book. If you don’t know that much about Ruby’s object system, I recommend the Dave Thomas presentation at Scotland on Rails 2009.

Returns

Methods need explicit returns (with ^). If omitted, the method will return self.

You get implicit returns for blocks: the value of the last instruction is the the value returned by the block. If you return (with ^) inside a block, it is a return value for the method.

Syntax Convention

Methods name and variables are spelled in CamelCase. Abbreviations are usually avoided. Smalltalk uses keyword based method name (as in Objective-C). Many Ruby libraries/framework mimic this by passing an hash as argument.

The tabs vs. spaces does not exist in the Smalltalk community. In every tool, press Tab to indent and you’re done.

As usual, just keep the global syntax style of the project you’re working on.

Usual suspects

Be careful when using cascades, a common is mistake is the following:

programmingLanguages := OrderedCollection new
  add: 'Ruby';
  add: 'Java';
  add: 'Haskell'.

In the end of the execution, programmingLanguages will be the String Haskell. That’s because the method add: returns its argument, not self. To prevent this, send yourself at the end of the cascade:

programmingLanguages := OrderedCollection new
  add: 'Ruby';
  add: 'Java';
  add: 'Haskell';
  yourself.

Another trick of the the language is the evaluation order:

3 + 4 * 5  #=> 35 and not 23

Evaluation is done from left to right. Mathematical order is not preserved. Indeed, + and * are simple methods. Smalltalk does not even know (and does not care) that it is executing mathematical instructions. You must use parenthesis to express precedence:

3 + ( 4 * 5 ) #=> 23

Version Control

My previous post will explain you how to version Smalltalk code. Do not expect Git, Mercurial or Subversion (although they can be used as backends for Monticello).

Conclusion

Once again, this post is inspired by someone else doing the same for Javascript (thanks Greg Spurrier for the link). The Squeak by Example or Pharo By Example books are worth to read. Beware that the tools described in the book are sometimes outdated but the principles are still perfectly valid.

This post is intented to developers who’ve heard that Smalltalk is hot and sexy. A fraction of them have tried to download a One-Click version of Pharo and played a bit with the language by following a tutorial or two.

So now they have a taste of Smalltalk but they do not get the entire picture, how the environment work, how people actually build and deploy software with it. If you are one of them, you’ll probably want to take some time to read this :)

Images and VMs

If you’ve downloaded a One-Click image, you haven’t experimented with the notion of image and VM in Smalltalk. Actually you have but not in an explicit way, you’ve simply clicked on an icon and got your environment. You’ve maybe ‘Quit and Save’ and when reopening the application you had the same state than when you left. Easy.

In pratice, Pharo works with an image running on top of a virtual machine. If you come from another scripting language, it certainly offers a REPL (e.g., IRB for Ruby). Think of the image as a dump of that REPL at a given moment.

A Pharo image contains everything: your code, the tools and the libraries. You can load code into it, you can save it and restart it at any moment. This image is closed. That’s why you cannot use your text editor to edit Pharo code (actually you could but you certainly would not want that).

The VM is usually something you should not care about. My advice is to use the one given by the Pharo website, it is tested by a Jenkins server and is the one people use the most.

In a nutshell: download a VM and an image from the official website. At this moment, the stable version is Pharo 1.3 and the image is CogVM-13307. I personnaly put the VM in the /Applications folder on my Mac. The image comes with a .changes and .sources files. Keep them in the same directory than your image.

Beware that the evolutions of the image and the VM are not tight. It is possible that a Pharo 1.3 image will run on a new VM version in two years.

To start an image, double-click on it. If your OS does not get it, you can drag the image icon on the VM icon. That should work.

Version numbers

When you download the image, you can see the exact version you are downloading: Pharo-1.3-13315.zip. It means that it is the 315th revision of Pharo 1.3. The 13xxx part is redundant with the Pharo-1.3.

The VM has currently the name CogVM-Mac-13307.zip. Which means it was frozen with the 307th revision of the Pharo image.

Source version control

Your code is in the image. You don’t even have a full text view of your nice classes. How do you persist it? So far, you’ve probably save your image and re-open it later. That’s the best way to lose everything if your image crashes (and that happens). It’s also not really handy if you’re not alone on the project.

Monticello comes to the rescue. It is a version control system like Git, Subversion or Mercurial. The only difference is that it does not version files but classes and methods. That’s pretty great for an object-oriented language, isn’t it?

Historically, Squeaksource is the GitHub of Smalltalk. It is old, ugly and slow but it works. A more modern alternative is SqueakSource3, which brings Squeaksource to the latest frameworks. There are less projects than in the original Squeaksource but you should use it for your new projects.

SmalltalkHub is on its way. It is not stable enough to be used in production but we are all waiting for it :)

James Robertson has made two (very short screencasts to help you get up and running. You won’t need more than 4 minutes to watch them.

• Smalltalk For You, episode 48, you’ll see how to save a package in a Monticello repository. Gives you all the basic information you need to know to use Monticello. Three minutes. That’s it.
• Smalltalk For You, episode 49, this screencast will show you how reload the code you saved in the previous screencast in a fresh image. A little more than one minute.

Load external libraries

Loading code in your image is pretty easy. Open a Monticello Browser and add the repository from which you want to load code. Et voilà, done.

The problem is that sometimes, a package has dependencies. So you end up losing 4 hours only to track the dependencies of the package and to figure out a load order. Metacello was designed to help you.

A project can provide a “Metacello Configuration”. This configuration describes the dependencies and the load order of the project. Of course a configuration can load an other one. You can also tag versions of your project.

When you want to use a project, the first thing to do is to find its MetacelloConfiguration. As of today, the lookup to find a configuration is:

1. Check if the project exists in http://www.squeaksource.com/MetacelloRepository.html. This repo is a goldmine.
2. If it is not there, check in the project repository if you find a ConfigurationOfTheProject.
3. Ask the Pharo-users mailing list.

If your project is not trivial, you should write a ConfigurationOfYourProject. You can get inspiration from other configurations. I personnaly like the ConfigurationOfFuel.

Once again, James Robertson has already covered the subject in his Smalltalk For You screencast series. Episode 82 shows you how to load GlorpDBX (an object-relational mapping package for Smalltalk) in a fresh image using Metacello Configuration in a little more than two minutes.

Good practices

Ok, so now you know the tools that are used by Pharo developers. Let’s move on to the next critical point: Good habits.

New image everyday

As you save your image and reopen it 16 hours later in exactly the same state, you are probably tempted to keep it forever and do all your development in it. So convenient.

In theory only. With time, you experiment and create a bunch of stuff you won’t need. You have loaded many external packages and you don’t know anymore which are your dependencies. Your image becomes bloated, it may eventually crash.

The best way to avoid rotten images is to get a new one everyday. Download a stock Pharo image (or keep one somewhere locally) and load your MetacelloConfiguration. This will have two benefits:

• Your image is always clean and not bloated.
• You know that your code load and works. This way you are sure that your co-workers can load your code and deployment is smooth.

Keep your images organized

I’m sure you’ve already think about it but try to keep your different images organized. it is not hard to end up with dozens of Pharo images scattered across your hard drive. Try to keep things simple. For example, I keep a directory with all my stock images (Pharo 1.2, 1.3, the preversion of 1.4, Squeak, One-Clicks, etc).

Choose a convention and stick to it.

Syntax conventions & micro decisions

Follow the conventions used by many Smalltalkers. Naming conventions as well as indentation. A very good read is Smalltalk Best Practices Patterns by Kent Beck. Follow this style your code will follow Smalltalk idioms. Actually, the patterns discussed are also valid for Ruby. So go and grab your copy.

Conclusion

I wanted to write this guide for a long time now. This article for Python convinced me to post it.

I hope it will be useful for some folks who want to try Smalltalk (and its Pharo implementation). Feel free to email me or to comment if you have any question or suggestion. If you are a Ruby developer wanting to learn Smalltalk, please drop me an email, I need your help for future posts !