Videos of the “Deep into Smalltalk” Workshop on YouTube

This is more a reminder for myself than news for you, because you’ve surely read it before: The sessions of the “Deep Into Smalltalk” Workshop earlier this year in Lille were filmed have now been put online at Youtube.

The sessions mainly cover Pharo (and therefor partly Squeak) related topics, but not necessarily introductory material, as you can tell from some of the sessions’ titles:

  • PetitParser Tutorial
  • A little Journey in a Virtual Machine
  • FFI (Foreign Function Interface)

So if the autumn evenings are getting too long and boring, instead of lighting a fire and brushing the dust from your old bearskin, why not learn something interesting about how your favourite language works from the inside?

A little update on sUnit and should:/shouldnt:

A few days after my post sUnit and should:/shouldnt: vs. assert:/deny: I received a mail from Niall Ross who maintains sUnit. I was quite busy the last weeks, so I am a bit late with this update…

Niall pointed out that should: and shouldnt: both are deprecated, so it is not a good idea to use them anyways. If I had taken a closer look at the category names in TestCase, I could have found out myself.

He also confirmed that the current behaviour of shouldnt:raise: is a bug. We still have to work out if the method should fail if the Block raises another exception than the one mentioned or if this means the test is passed. I think shouldnt:raise: is really meant to say: throw whatever exception you like, as long as it’s not the one(s) I name here! I’m planning to try and fix this one this week if I find the time and nerve.

Along with Niall, quite a few people made a strong point about my suggestion to make sUnit accept Blocks as a parameter to assert: .

I’m not sure it buys anything to make assert: take a block.  When not checking for the raising or non-raising of errors, why use a block?  (By all means give me counterexamples).

Even stronger opinions have been expressed about my suggestion to do this by implementing the value method on Object. I tend to not agree to most of them, but it was again Niall who came up with the strongest argument: as long as Object>>value is not standard on all Smalltalk implementations, sUnit shouldn’t introduce it. I must admit I agree to this one. Porting code from one Smalltalk dialect to another can be hard without this one, and even if implementing Object>>value is not much of a deal, it should be avoided.

So I am now happy to write

self assert: (myBlock value = true).

in my future tests.

This is probably necessary in most cases anyways, because the Blocks we use most often do not evaluate to a Boolean. So checking their result in an assert: rather than in a (deprecated) should: is the way to go.

Thanks to all commenters and to Niall for taking time to think about my post and comment.

Schauderhaft: Don’t Rewrite Your Application

I’m probably the last to find this excellent piece on Jens Schauder’s Blog called Don’t Rewrite Your Application. It’s not only worth reading, but also thinking about it and memroizing it. There’s almost never a really good reason to rewrite a reasonably-sized business application. The effect will very often be a the loss of a lot of money and probably never an application that is substantially better than the one it replaces:

  1. Whatever you might think of the code base and the developers that created it: They weren’t stupid nor evil. So chances are the results of your work will look just as ugly in two years from now.
  2. You don’t know the requirements: Part of the reason legacy code bases are ugly is that requirements change. There is no reason for you to assume this won’t stop.So chances are the results of your work will look just as ugly in two years from now.
  3. You don’t have the time: As long as the rewrite isn’t done, you’ll need to maintain and probably evolve the current application. If it is of any importance, you can’t ignore it for the months to come. If you can you should do so without wasting your time with a rewrite.

So true. In the Smalltalk world, we’ve seen all sorts of craziness in that field. Some customers spent literally millions of Euros into this lesson. Here’s a possible solution:

Instead of rewriting the application refactor it. Learn to properly estimate the effort needed for implementing new features in a clean way. Add some time to make the code immediately around that new feature a little cleaner as well. Use that as estimate. This way the application will become a little cleaner with every update.

Boy, how right he is!

If you know the requirements of your system, still have some skilled developers on the team and need to move the application further, it’s almost always better to invest in existing know how and the team to improve their skils in techniques like Refactoring, Unit Testing and Code Management. Combined with Continuous Integration you can accomplish several things:

  1. Improve an existing system with new features in little time
  2. Lay the grounds for easier addition of features in the future
  3. Come back to the pace of innovation that your project once  had
  4. Save a lot of money and frustration (and if you are a CTO or in upper management probably even keep your job and feed your family)
  5. (Re-) Motivate some of your most valuable team members who’ve lost their believe in a future of their projects a long time ago (you should NEVER underestimate this aspect!)
  6. Motivate new staff to come to your project as it promises to be fun, effective and respected within your organization (Have you ever heard or said the sentence “we can’t find Smalltalk developers”? – maybe it’s your fault because you scared people away from the project or technology for years for no real reason…)
  7. Surprise your users with new features instead of apologies for not delivering
  8. Have fun!