Zürich Smalltalk Meetup, Nov. 8, 2016?

It’s been almost a year since the Zürich Smalltalk users met. What a pity. So I’d like to get the ball rolling to gather interested Smalltalkers to meet on Tuesday, November 8, 2016.

If you are interested, drop me a note or mail and I’ll keep everybody updated on the exact time and place.

Where to meet? What to do? Why come? How to help?

The place we met over the last few years was a nice restaurant/bar, so having dinner together and chatting was interesting, fun and informative. But we never actually got to the point where we could exchange ideas, nobody pulled out their laptop to do some pair programming or debugging on some interesting issue. I’d love this to happen. Just imagine you have some beer (or Schorle or green tea) with a bunch of Smalltalkers and suddenly you find out somebody has the same problem in (Glorp/Seaside/you name it) and you just start tackling it together. And after a 40 minute session you just present the problem and your solution to us. Sounds like lots of fun, doesn’t it?

Last year we discussed whether we could meet at a place where people can give short demos of their current work or show some cool tool they found or whatever, rather than just sit together at a table and chat all night. Unfortunately, so far nobody came up with a suggestion. Dimitris suggested trying to find a hacker space and see if we can meet there. There are several hacker spaces in Zürich, so if you not only would like to meet other Smalltalkers, but also are in contact with somebody at a hacker space, let’s talk and see if we can arrange somtehing. If the date in November doesn’t fit, let’s talk anyways, I’d love to get the ball rolling.

A hacker space is not only a great place to meet the community, it is also a place to get in touch with people who aren’t yet part of it. Open (minded)ness is part of the concept of hacker spaces, so we might even have the chance to make new friends…

If you happen to work for a company that might host us in some meeting room or you know a nice restaurant where we can use a side-room for our meeting, sound off in the comments or drop me a mail.

Seaside: Registering a WAApplicaton too late leads to an HTTP 503 error

[Update: Thinking about this a little more, this post has a misleading title. This is very likely not to be a Seaside issue at all, but one of VA Smalltalk’s WASstServerAdaptor, which, if started/registered too late (whatever too late may be), doesn’t get realized by Apache. So the title of this post should rather be:

VA Smalltalk: registering a WASstServerAdaptor too late  leads to an HTTP 503 error


From time to time, I learn something new. Sometimes it’s fun, sometimes it’s less pleasant. And sometimes it feels like wasting lots of time.

Yesterday, I lost a lot of time, and I ended up only understanding the problme and found a way to circomvent it. But I don’t really understand why things happen the way they do. So if a kind soul out there reads this and understands the reasons for the problem, I am grateful for helpful comments😉

So here is the story:

During startup of our Seaside Application, we load a lot of read-only data into memory. This takes a while, almost half a minute. During that time, the server shouldn’t really accept user logins because if that data isn’t pre-loaded, the server can’t really do anything useful for users – other than write friendly walkbacks that keep our developers happy😉

Since the main purpose of our Server Application is not being started, but to run and do useful stuff, and since under normal circumstances a restart of the application is not necessary for days, sometimes even weeks in a row, we just tried the simplest thing that could possibly work. We would just start the WAServerAdaptor after the pre-loading of data is finished. In pseudo-code the sequence looks like this:

self loadAllNecessaryStuff.
self startSeasideAdaptorOnPort: xxxx.
WAAdmin register: MyApp asApplicationAt: 'TheBestStuffYoullEverSee'.

We thought this is a clever idea. Users visiting our Application would see an HTTP 503 served by Apache during startup. This would be good enough, because we only restart the Application late at night under normal circumstances, and there would be only a small chance that anybody would be affected, although it did happen once or twice before.

So we started the Application, started Firefox and tried to see the results. All worked well: Apache answered an HTTP 503 Service not Available.

A bit surprising was the fact that Apache didn’t change its mind after a minute or so. Still a 503.

A look at the Application’s logfile said: the pre-loading is done, we’re ready to go!

Another minute later, Apache still was very confident in the fact that nobody is listening on port 8080. So we tried locally with curl, and there really was no answer. Looking a bit closer at the log output of the Application also gave us a bit of a shiver: the usual startup log output of the WASstServerAdaptor were missing from the log.

So we changed the startup sequence of our Application to look like this:

self startSeasideAdaptorOnPort: xxxx.
self loadAllNecessaryStuff.
WAAdmin register: MyApp asApplicationAt: 'TheBestStuffYoullEverSee'.

This is much better: During the pre-loading, Seaside now answers with a short message saying that /TheBestStuffYoullEverSee is not found.
And when the pre-loading is done, users are greeted with a login page.

One day we’ll probably add a nice page saying: please wait, the server is currently starting. But for now, this is enough. This whole thing is not happening often, and we just want to avoid getting walkbacks just because somebody logged in too early, because that’s a waste of time.

So here is what puzzles me:

  • What sequence of events leads to the fact that the Application is not answering request, or better: why doesnt SST register the handler?
  • Is this a Seaside bug or an SST bug in VAST?
  • How can we tell if registering a handler is too late? how late is too late?
  • How can this be too late at all? I mean, we’re starting to listen at a port, and no matter if this happens a second after an image starts up or five minutes later, this should work, right?

Even though the matter is fixed for us now, there is some bitter taste somewhere in my throat.

MOOC on Live Object Programming in Pharo

inria41010session01-730x412_q85_crop-scaleEver wondered why Smalltalk developers love their environment and what all the buzz about Live Object Programming is about?

Would you like to learn Smalltalk and understand why Smalltalkers are so passionate about it?

Maybe this Free online course is the right opportunity for you to start discovering a new level of programming and widen your horizon.

Here’s an excerpt from the course description:

[Pharo] offers a unique developing experience in constant interaction with live objects. Pharo is elegant, fun to use and very powerful. It is very easy to learn and enables to understand advanced concept in a natural way. When programming in Pharo, you are immersed in a world of live objects. You have immediate feedback at any moment of your development on objects representing web applications, code itself, graphics, network…

You can read more information about the online course (mooc) and register here:

Live Object Programming in Pharo

VA Smalltalk 8.6.2 is available

John O’Keefe from Instantiations sometimes makes this joke that a new release of VA Smalltalk will be out “in October” but it’s not clear yet how many days this year’s October will have.

Well, 2015 October had exactly 61 days. Instantiations just announced the availability of VA Smalltalk on November 30th, 2015.

At first sight, nothing dramatic is happening in this new edition. It is not uncommon for Instantiations to pack new and exciting features into new releases whose version number only increases at the third digit.

The most awaited evolutionary step, 64 bits, is not part of this new version (hence no version number 9), but there is a number of nice new things that will make life for Smalltalk developers easier:

  • Multi-lingual workspace support. This may not sound like much, but if you have to work with external resources like Javascript, CSS or XML, you will pretty soon be happy to have syntax highlighting and stuff for your artefacts right in your favorite IDE. This is just another proof that Instantiation’s decision to use Scintilla in VAST was a great choice. From discussions with Seth Berman and John O’Keefe I know that this is not the end of it, there is more to come in that area in upcoming releases.
  • Updates to openSSH support. OpenSSH ist not shipped with VA any more. Instead they made it easier to integrate VAST with installed openSSH on your machines. This is very important because openSSH is constantly updated due to security problems, so sticking with an old version is risky.
  • Official support for new O/S versions, like Windows 10 and Ubuntu 15.04 LTS or Fedora 22
  • Updates of Grease, Seaside and Glorp.

One feature that is not prominently mentioned in the announcement is the introduction of a new code compression/decompression algorhithm for library access. There was an evil bug in VAST that would only bite you in very special scenarios, but then it was really bad. What I am talking about are special characters in your source code that was used on different operating systems. Like if you used German umlauts in Strings in your source code and saved your code on Windows and wanted to continue development on Linux. New method editions would get “scrambled” when you saved them on Linux. This is now history, and especially for projects developing on, say, Linux and testing/fixing on Unix/Linux, this makes life a lot easier.

There are, of yourse a lot more small and medium improvements and bug fixes that you can read in more detail on Instantiations’ web site and in the Migration Guide.

VA 8.6.2 is free to download for customers with a current support contract. You can also register to get a free evaluation licence (no time-bombs, no restrictions, just a nag screen on startup). If you are interested in purchasing and upgrading you can contact Instantiations or, if you are in Germany, Austria or Switzerland, get in touch with us (objektfabrik). We are an official reseller of Instantiations and provide traning and consulting services for VA Smalltalk projects.
I look forward to hearing from you.



YouTube fixed my printer

Today I had a problem with my (oldish) Epson Stylus SX600FW printer. The display said “Paper Jam” and the whole box would refuse to do anything. After a few tries to remove all the paper pieces it still insisted on jammed paper. I used air spray, a pocket lamp, opened a few screws (always a spooky thing) – to now avail.

The printer’s documentation is very helpful: open the lid, remove paper, close the lid, there you go.

In my case, I went nowhere and was ready to order a new printer. Just one more try: the web.

And look what I found: https://www.youtube.com/watch?v=fKBlv7rFmYY

I wasn’t really optimistic that pressing onto the whatever on the right would help, but having a broken printer, giving even esoteric stuff a try seems okay. So I pressed this little white thing to the right, slid it back in again and powered the printer: and believe it or not: it prints like on iits first day. The video talks about another printer, the message code is different, but the mechanics inside the printer look almost identical.

Smalltalk Meetup in Zürich, Nov. 10, 2015

If you are a Smalltalk developer or would like to get in touch with people who use it to learn more about it, and if you happen to be in or near Zürich, Switzerland, on November 10th, then feel invited to join a few of us for a meetup.

We’ll meet at Restaurant Steinfels around 7:30 pm.

I’ve reserved a table there and if you’d like to come it would be good if you sent me a message in advance so that I can see if we need a bigger table. But you can also just drop in and get in touch with us.

Hope to see you there

On the importance of Analyst Reports

You wonder why analyst reports or irrelevant stuff like the TIOBE index matter?

Because they give decision makers with a lack of time, interest, knowledge or intelligence a framework of well-sounding arguments in favor of whatever technologies the analysts want them to buy.

In essence, analyst reports are nothing else than sales accelerators.

Grey-bearded IT guys may remember the saying “Buy IBM and you can’t fail”.

The modern version is: “Look up what’s in the upper right quadrant of this graphic and you’ll keep your job even if you fail”.

Sorry guys, having a bad day today😉

Why do we need commercial Smalltalk implementations?

Over on the VA Smalltalk Discussion group, somebody asked what commercial Smalltalk vendors are needed for nowadays where you have the choice between so many good and innovativa platforms like Pharo, Amber, Squeak and quite a few others that are completely free and maintained by an open community.

I am pretty convinced we need both: open source implementations which test the ground for new, innovative, sometimes radical technologies and tools (I can tell you there is a lot of that stuff going on right now) and vendors that concentrate on stability and longevity, which includes long-term support and downwards compatibility.

Here’s what I wrote on the discussion thread:

I must say I immediately had a smile on my face when I read Sebastians comparison between a tank and an e-car. But it is not bad after all. He surely nailed it when he mentioned the longevity and long-term support of commercial Smalltalks.

VA ST is quite young on the commercial Smalltalk market, just above 20 years old😉
When Instantiations took VAST over from IBM, they made two very important decisions:

* They’d keep their versions downward compatible to the last IBM version for a while (this still stands true, after 9 years)
* They’d provide support in their support contracts for all existing versions of VisualAge and VA Smalltalk, so that even if you don’t upgrade to VAST 8.6, you’ll still get help from INstantiations for your VisualAge 4.5 code (just an example)

This is very important for commercial customers, and has been for a number of our customers as well. Some of them never used newer VAST versions, but still renew their VAST support contracts every year. They had hard times in the days when top management wanted everything reimplemented in Java. These projects, however, had to deliver new features on mini-budgets for ten years or more, before even the top management realized they’d have to ramp up their budgets and teams again, because the rewrite never actually happened or never worked (not always for technical reasons).

Support is the keyword here. Pharo and Squeak are communities in which some projects just are reinventions of wheels, because somebody thought “well, wouldn’t it be cool if…”, and instead of researching available code or concepts just wrote stuff. SOme of these lead to great sub-projects, some were just dropped in favor of something else. This is not bad per se, because that is what evolution is all about. But if you as a user decided to use such a dead-end, you are in trouble and will probably run into even more trouble if a new version of the IDE simply doesn’t host the old code well. You will be cut off the innovation until you migrate a potentially big pile of code.

With commercial support, decisions will be made more cautious and definitely slower, because the vendor has to guarantuee that their customers can use their code for a number of years. Switching to something new that replaces something old has to be made feasible and as easy as possible, because customers would complain a lot. There have been examples in the Smalltalk world where commercial vendors made exactly this mistake: make a decision, postulate something as the future and after a few years let it drop like a hot potato. Customers were upset, because they had been financing something that never made it into the product, had to live with postponed fixes and extensions of old code, because the vendor said “our now thing will solve this problem anyways”, and so on.

So commercial Smalltalks move slower, but give you safety.

On the other hand, nowadays there are lots of open source projects that get ported from, say, Pharo to VA. There are lots of great stuff coming from the Pharo community especially, and many of them will stay, for sure!

One thing that I hope will happen in the near future is that we’ll also be able to give code and stuff back into the open source community, not just harvest from it. But that is not so much a technical problem, but a political one in the customer base of commercial Smalltalk implementations…

If you don’t buy this argument, just take a second to think about why Redhat and SuSE are so successful? Why do you think Ubuntu got a dent into that market? I think it is because they understood that long-term support is a key factor for commercial users.

Grease Extensions for VA Smalltalk

If you’ve ever tried to use open source code from Squeak or Pharo on VA Smalltalk, you had a few obstacles to take:

  1. How do I load Monticello Packages into my envy library? Many moons ago, you had to use FileIn/FileOut and some manual editing of the fileout to make it loadable. Sometimes, I just gave up on that and copy/pasted code method by method. Nowerdays there is the Montocello Importer from Instantiations, which works very well for importing code from Pharo/Squeak into VAST.
    Side note: Unfortunately, there is no solution yet for contributing back to the original projects. In order to do so, you have to work in Pharo – that is really a pity, because in the end we VAST users will look and behave like shameless harvesters who are good at taking code but don’t give back.
  2. Pharo code today is stuffed with method sends for little helper methods on Collections, Strings, Classes and Behavior that make code much cleaner and shorter. These methods are often just re-namings of standard methods, but for special uses. If you need an example: Pharo has this nice #beginsWith: which tests if a String (or SequencableCollection) starts with some String (‘My home is my Castle’ beginsWith: ‘My’). In VAST, there is no such method, but you can achieve the same thing by sending #indexOfSubCollection:startingAt: and test the result whether it is greater than zero. In the end, #beginsWith: just does exactly that, but it is much easier and less error prone to just type beginsWith: than a full test. That is why Pharo code has so many sends to such methods

If you encounter such a method send in to-be-ported-code and want to port it over to VAST, you have two options:

  1. Replace every method send from VAST with a send to “the real thing”
  2. Add the helper methods to VAST

The first alternative has a lot of drawbacks, the most important ones being that you’d have to repeat this every time you port a new version of the code to VAST. If you find a bug in the code, you can hardly communicate about it, because you don’t really use the same code any more. Once there is a solution to contribute fixes and changes back to Pharo (I hope one day there will be such a thing), this also means you’d contribute a version that has all those little easier method sends replaced with more complex ones…

The second one also is not without problems, but more from the perspective of Code Configuration Management and the way Envy works (from a conceptual standpoint). There is a thread on the VAST mailing list that highlights some of the problems this approach has.

Nevertheless, I just started a new mini-project to attack the issue. While porting the Twitter Boostrap code from Pharo to VAST, I just added the methods I needed and put them into a new Application named GreaseVAST860Extensions. I tested if it loads into VAST 8.6.1 as well.

The idea here is that whenever I or other people port code from Pharo and find they need another helper method to make life easier, they can extend my mini-collection of compatibility methods and upload it to VASTGoodies.

I hope this will help us VAST users keep up with the rest of the Smalltalk world. I remember giving up porting newer versions of NeoCSV to VAST because I constantly had to change methods (I tried approach 1 back then, because I had too much respect of the problems Approach 2 would be associated with).

So I want to encourage everybody who uses Pharo code in VAST to use and extend GreaseVASTExtensions and publish their changes back to VASTGoodies.

I think this will make life easier for many of us VAST users.

There are two main areas which remain to make life even better, that I think need to be addressed in the near future:

  • We urgently need to work on ways to make this one-way-street for code a real street where code can travel both ways. There is a bunch of good open source code on VAST that could be helpful for Pharo users, and we could help improve projects that live in the Pharo eco-system with our contributions or fixes
  • One thing that Pharoers really like to do is create collections using curly braces. Especially in test methods where you need a bunch of data points to feed into some algorithm, people tend to use {1 10 15 25 $c} rather than OrderedCollection with:with:with: and so on. The {} notation for creating literal arrays is not available in VAST, and so we still have to modify code in order to make it workable in VAST.

Please feel free to download the GreaseVASTExtensions and extend them. Tell me about problems, publish extensions to it and help make VAST an even more beautiful place to work in. Let’s work on ways to improve the manageability and version compliance of this little extension for newer versions of VAST.

Twitter Bootstrap for Seaside ported to VA Smalltalk

I just uploaded a port of Torsten Bergmann’s Twitter Bootstrap code for Seaside to VASTgoodies.com.

Our kontolino! web platform is currently being worked on design-wise. Over time we found out the hard way that keeping up with how people think a web application should look and feel, and making cool things workable across multiple mainstream browsers, combined with at least a minimum level of adaptability to smaller screen sizes, can be a lot of work. So much that you start spending most of your time for a new widget in JavaScript tweaking and CSS exploration rather than adding features to your application. Just to find out somebody has solved the same problem better, more visually pleasing and for free already.

Making long story short: we decided Bootstrap would be the thing to use for us. There is a risk of making your web site look like all the others out there, but Bootstrap can be tweaked and customized and adapted in many ways, while you still profit from lots of cross-browser code. If you’ve never written a web application, you won’t believe how much of a problem that really is. And users somehow expect a site too look somewhat like that anyways – at least that is what our users told us.

So what I did was borrow Torsten’s code and use the Monticello Importer to load it into VAST. It was a very smooth process – I was quite surprised how little I had to do to get the packages into our Library.

There were, however, a few obstacles to making it run:

* Some of the Javascript helpers of Bootstrap only run on JQuery 1.9.1 or later (which is still very old). Seaside/JQuery as it ships in VA Smalltalk comes with some 1.7 – even in the latest VA Smalltalk 8.6.1 version. So I had to load the latest 1.x series code into JQueryDeployment and JQUiDeployment Libraries in VAST. It’s easy: download the js files from jquery.com an jqueryui.com and execute #addFileAt: on the two FileLibrary – classes to update your File Libraries in VAST.

* Pharo has a ton of little helper methods that save some typing and make code a bit shorter to write and read. These are not ANSI Smalltalk compliant, but very nice. So people use them – a lot. When you import code from Pharo, you have two options: change the places where such methods are being used and replace them with mothods that are available in VAST (mostly their ANSI counterparts) or add the methods to VAST. We did the latter for various reasons. The outcome there of is a small Application named GreaseVAST860Extensions whcih we also uploaded to VASTGoodies (more to follow on this blog).

* A few examples that come with Torsten’s Bootstrap code use #call:, which is not working on VAST due to the fact that VAST doesn’t support Continuations. I didn’t take the time to change these examples. It should be easy to use show: instead of call:, so if you feel like you want to help out, please feel free to change the code on VASTGoodies and publish a new version.

So far, we are very pleased by Bootstrap. Things like DropDown-Buttons and such are so easy to build and you can be sure they work on all mainstream Browsers. The additional work of changing our widgets to use Bootstrap logic (some more/less divs, changing a few css classes and such) is not as bad as we expected, but the result is fascinating! Once we’ve ported all our stuff, we can concentrate on functionality instead of Browser compatibility! (How stupid does this sound in the early 21st century??? But that is web reality!)

So feel free to download Twitter Bootstrap from VASTGoodies and play with it. Please let me know about problems you find – and, mor importantly, help by submitting bug fixes and stuff. I’d also be happy to discuss topics of Bootstrap in a Seaside context with other users and learn!