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:

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

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 an 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!

VA Smalltalk 8.6.1 – first impressions

Instantiations released VA Smalltalk 8.6.1 yesterday. We haven’t ported our project code to the new version yet, but given the fact that this is “just” an update to 8.6, I don’t expect to experience a lot of problems here. The Migration Guide, an often undervalued but very helpful resource, doesn’t really mention a lot that seems relevant to our code (except for the Base64 encoder, but we’ll have to see if it’s just a new class name for us or if there’s more to it).

But be warned: if you think an update that only shows in the third digit of a version number is a minor update, you are wrong, Instantiations has a tradition of coming up with new and interesting features in what seems to be minor releases. This time, there is not much new feature-wise, meaning you can’t build much new stuff for your end users that you couldn’t with 8.6. But for the developer, 8.6.1 feels a lot slicker and this release really is a big step forward.

Code Assist is such a great and nice feature and has learned quite a few nice tricks in 8.6.1. It now runs lint checks online on your code right as you type and provides you with a lot of hints and stuff.

But first things first.

I’ll give you a brief overview of the first things I encountered with 8.6.1 and that I think are probably important for other users.

Installation and Environments

One of the strange things in VA Smalltalk for the last few releases was the fact that the install scripts for Linux needed teh X server. There was no installation script for headless installation. It was easy to get around this if you know VA Smalltalk, but for a less experienced user, this was a no-go. With 8.6.1, the Linux version ships as either rpm or deb packages and an install script that runs on the command line. On our OpenSuSE box, this worked like a charm using ssh.

On the client side, I was shocked at first that the 8.6.1 installer does not ask for an installation path and just installs into the existing 8.6 installation directory.It does, however, make sure that the important directories like newimage etc. are untouched and adds 861-versions of these. There is no separate installation package for client and manager any more.

So I was in doubt if I like that. But it turns out that my existing environments/images are running as before, old image, connected to the old Library. No troubles so far.

The best thing that may or may not be new, but that I just realized now is that if you create a new Environment (image directory), the Environments tool lets you select if you want to create an 8.6.0 or an 8.6.1 environment. Great idea for all those who have to maintain existing software but also make progress in new versions.

The installer also has an option to upgrade an existing library to 8.6.1, which I didn’t test. But it sounds like a fantastic little feature (once you’ve made a backup of your library, as you always do, right?). We chose to use a new Library, and do whatever needs to be done later (we’ll most likely make a copy of the existing 8.6 library and use the Library Importer tool to get the latest VAST code into it. This way we keep all our code history).

Tool improvements

Boy, 8.6.1 is so much better than 8.6. If you are on a version like 7 or even older, I promise you won’t realize your favorite tool any more. Code Assist was such a great step forward in 8.6, but it really lifts off in 8.6.1.

The editor now has such nice things as code folding (you can fold long comments) and it feels much faster and fluid. Autocompletion suggestions come up much quicker and teh whole thing just seems like it got a boost. I only learned a lot about what Code Assist added to the last version (like camel case guessing – you can type “oc” and Code Assist will instantly suggest “OrderedCollection”), so I look forward to what I will learn and love over the next few weeks and months.

I remember being blown away by what Seth showed in August at ESUG. A lot of refactoring and code improvement will be so much more fluid with 8.6.1, but I must say I haven’t played with this stuff yet.

One thing I checked was Refactoring, or better the “Mastering Envy Refactoring Browser extensions”. I’ve sat with Seth and showed him a few things I really thought should be changed or improved there. And what can I say?

Refactoring now just feels right in so many little aspects. Like when you select an instance variable in a Class Browser and click on “Create Accessors…”. The Browser now knows which variable you mean!

This doesn’t sound like a big thing, but it is, because in the past, you had to pick the very same variable ion a little prompter again. Not any more. It is pre-selcted now and you can just press Enter! If you refactor a lot, and I really do refactor a lot, both my own and lots of legacy code, then you will value these little things a lot. It saves you a lot of time and your metabolism profits a lot from 8.6.1.

I haven’t really spent much time with the new version, but what I’ve seen is really promising. I’ve also read Marten’s first impressions and he also likes 8.6.1.

I’m sure I will come across new wow-moments with this release and look forward to porting our code (which will be a bit involved, since we have quite a few fixes to Glorp and Seaside that may or may not be fixed in this new release and we’ll have to take a close look at these) and work with it.

Camp Smalltalk on Vancouver Island (Canada)

Sometimes, you have the feeling you just live on the wrong side of the globe. If you are a Smalltalker or would like to learn more about this dynamic programing language and get in touch with a bunch of enthusiasts, you better be in North America the first weekend of October:

This particular Camp has grown like Topsy from a simple attempt to get the small number of Smalltalkers on the island together for a weekend of social programming into a gathering of nearly two dozen experts from all across Canada and the US west coast. If you’re a newcomer to Smalltalk this might be a good chance to meet some experienced people that can help you.

The Camp was ignited by Tim Rowledge of Squeak fame (you can learn more about his work on Squeak on the Raspberry Pi in episode 24 of Smalltalk Inspect) and Sebastian Heidbrink, who has been a co-host on our Smalltalk Inspect podcast for years now. I hear there are a number of very interesting people coming and the list of topics and projects is a like first class menu.

To attend, visit their registration page.

I only hope somebody will take a few photos and blog about the camp, because this will sure be a lot of fun!

Beautiful little tutorial on how to build a complete Seaside Application with an RDB Backend

Sven just announced the availability of a new tutorial named “ — In 10 Cool Pharo Classes“.

I am fascinated by how short and clear this piece is. It really explains all you need to know to get started building a Seaside Application using Glorp and Postgres as a database. It is nice to read and really covers all there is to it without leaving you out in the cold. 

Skimming through the code I’d say that the code can be used in any Smalltalk dialect, not only Pharo. Just the Captcha class needs a bit of tweaking for other dialects than Pharo.

I must say I not only like Sven’s coding style but also his writing very much. I recommend taking a look on his other articles on

How to see who tried logging into your Ubuntu machine

Putting a piece of software onto a publicly reachable machine on the open (bad, dangerous, dirty and unbelievably complex) web presents you with all kinds of neat problems.
One of them is that as soon as you have a public address, a certain kind of people will sure try to knock on your door, push and pull a little here and there in order to see if they can open a door or a window and look what’s inside for them.

The last few days, we’ve seen an interesting increase in visits from China (well, as far as you can tell from IP address lookup. Maybe someone just uses a chinese access point or whatnot), who all try to log in as root on our Linux server.

Here is what you can do to first find out if someone was on your machine (and left traces):

This will show you a list of all your users on the machine and when and from which address they logged in. As long as there are no users in the list that you don’t know, and as long as there are no addresses from where they logged in that sound suspicious to you, there is a chance there was no breach into your system – at least you have a first idea if there is a problem here. Of course, you can assume that real professionals will be clever enough to remove their traces anyways. Not to mention those bad guys we hear so much about these days…

Here’s what the output of lastlog looks like:

Username         Port     From             Latest
root             pts/2    IPADDRESS     Thu Aug 28 15:38:05 +0200 2014
daemon                                     **Never logged in**
bin                                        **Never logged in**

/var/log/auth.log (on Ubuntu)
This is the log file in which you see all authentication attempts. By searching through this file, you can see all login attempts that failed by looking for entries like:

Aug 24 07:21:22 yourhostname sshd[20151]: Failed password for root from port 45168 ssh2

Based on what you learn from the logs you can decide to block certain IPs or subnets in your firewall. It’s hard to give good general advice on the topic…