Why Smalltalk tools can still be improved a lot

Readers of my bog know that I sometimes start to dream of a nicer, better Smalltalk environment. Smalltalk has great tools and the language and environment give you a lot of possibilities to explore the objects hanging around in your system and fixing / improving them. Developing a Smalltalk program has two components to it:

• exploring and maintaining the zoo of objects living in the system
• reading and writing code

Typical Smalltalk environments have very good tools for doing the first, but the world around us has improved a lot on the second field over the last few years. And Smalltalk environments are only slowly catching up on code editing tools as compared to what other environments offer today.

Over at the VA Smalltalk support forums, a member of the development team asked for ideas of what could be done short- to mid-term to improve the environment.

Around that evolved quite some discussion in several threads, from Improved Code editing, to code merging tools and new ways of navigation source code. A few very nice ideas that I’d also call low-hanging fruit for improvements of VAST were brought up in the discussion and I hope Instantiations is going to pick them up.

In an answer to somebody’s post that repeated an often used argument, I wrote the following post. The argument was essentially that Smalltalk methods tend to be short, so if you see long, hard to merge methods often, you should think about refactoring these methods instead of crying for better tools. While I agree that long method should be avoided and I also agree that refactoring them would help in not only making the code better readable, but also in improving the maintainability of the system, I think the consequence drawn is wrong. Here’s my argument:
I agree. If we all wrote short methods and were good in OO design and programming techniques, the quality of our tools wouldn’t matter all that much.
I just had the same discussion with a Smalltalk friend yesterday. We old bones Smalltalkers often don’t realize how much tool support we are missing:

• no need for code completion/intellisense if I know the Collection Protocol by heart
• no need for a code formatter because it would only start religious wars in the project team and we as as a Smalltalk community would be extinct within weeks
• no need for good merge support because Smalltalk is so easy to read
• no need for line numbers or code folding because our methods are no longer than 6 lines (gives me a good laugh every weekday when I work with legacy code)
• no need for any tools that help me keep track of my browsing history, because you get used to 38 open windows very soon
• no need for a “new class” dialog because everybody knows I can just type over an existing class definition expression to create a new class
• no need for an online “API” documentation because I can always fire up a Class Browser on SortedCollection to see how I can use it
• The list continues

But still, when I’m in Xcode and enjoy code completion, online help, good merge tools and a nice-looking environment, I feel some excitement about that. I would say that Objective-C methods are also short, if you program in good OO style. Being able to fold/unfold code can help a lot. Finding the opening bracket for a closing one helps me find missing ones. Code completion which also helps me find the online documentation for what parameters to hand in etc. helps me.Maybe that’s because I am a relative Objective-C newby and need that, whereas I don’t need it in Smalltalk all that often.

But maybe I am also not the kind of user that brings in fresh blood into the community.

New Camp Smalltalk Wiki

John O’Keefe and Don MacQueen from Instantiations have put up a Camp Smalltalk Wiki on Google Code. The purpose of the Wiki is to discuss possible projects and exchange ideas in preparation of Camp Smalltalk’s, one of which is usually held on the weekend before or after ESUG. This year there will be a Camp Smalltalk the weekend before Smalltalk Solutions in Vegas.

The term “Camp Smalltalk” refers to loosely organized gatherings of Smalltalkers where they work on extending and improving the capabilities of Smalltalk. Camp Smalltalk will take place before Smalltalk Solutions on Saturday, March 12 and Sunday, March 13 from 10 AM until 8 PM both days.

So if you’d like to join in on a Camp Smalltalk or want to find people who join you in a hacking session on some open source project in any Smalltalk dialect, visit the wiki and leave comments or submit project proposals. Here’s how to jump on the boat:

How do I join the camp-smalltalk project?
Anyone can read the camp-smalltalk project pages. However, if you want to comment on any of the content, you will need a Google Account (perhaps you already have one for posting to Google Groups or for access to other Google applications). One of the project owners (right now, dmacq@instantiations.com or wembley@instantiations.com) must use the project administration page to add your Google Account email address to the project. Just email one of the project administrators from your Google Account email address and we will be happy to add you to the project.

I’m happy to see that John has added my Idea for extending SUnit for logging purposes (like for a build server) to the list of project candidates.

How to find out if you made progress

Shawn Blanc relates to a nice description of how you should feel when reading code that you’ve written months or years ago:

If your old work doesn’t shame you, you’re not growing.

It’s nice to look back and feel that you’ve made progress. When you look at old work, it should suck glaringly and you should cringe painfully. But there should also be some germ within it that you’re not ashamed of—some spark of talent or inspiration that connects to what you do now.

The good news for me: I feel the shame from time to time. The bad news: sometimes the code doesn’t have to be much older than a day. Of course it just means I’m learning fast 😉

What sUnit could learn from jUnit [UPDATE]

The complete family of xxxUnit testing frameworks have their roots in Kent Beck’s sUnit testing Framework for Smalltalk.

While jUnit (the Java flavor) and sUnit were very similar for a long time, jUnit “lately” added a lot of stuff that is helpful in Java, but quite useless in Smalltalk (like Java Annotations), mostly with jUnit Version 4.

There is, however, one difference between sUnit and jUnit that I think should be overcome. I am speaking of the TestFailure Class in jUnit that has not been added to sUnit. I don’t know exactly when the jUnit implementation got TestFailure, but I miss it.

Why do I miss TestFailure? Because its non-existence makes post-testing reporting very hard, unless you write your own TestRunner.

But let’s start from the beginning.

I’ve played with the Hudson Build Server (which will soon be known as Jenkins, but that’s another ugly Oracle-related story) lately in order to have a nice frontend for automatic builds of the VA Smalltalk projects of a customer (you can learn more about the beginnings of this project here) .

One thing that I wanted to do is use my TestResults and report them back to Hudson. Which is quite easy once you find out about a suitable xml format for TestResult. The gold standard here is again an artefact that’s coming out of the jUnit project.

Since my build machine works like a batch processor, and since I wanted to simply use the TestResult of a Suite to create an xml file that can be read by Hudson, I was hoping for an easy way to marshal TestResult to XML. So the first idea was to add a step to my batch that accepts the TestResult from the Test runner step and simply convert the results to XML.

Unfortunately, sUnit does not keep the output of failed tests anywhere, it just keeps the test class and test selector of a failed test.

So if you have an assertion like

self assert: (1>2) description: ‘1 should be greater than two’.

and the assertion fails, you will not find the description anywhere in the TestResult. The testwill be recorded as failed, but there will be no way of finding out what went wrong. You’ll have to rerun the test in the sUnit Browser and take a look at the Exception that gets thrown.

I took a look at Lukas’ implementation of his Hudson build integration for Pharo. He wrote his own TestRunner that immediately outputs the jUnit XML file, but I think this is not the right solution. The right solution is what jUnit does: keep an instance of TestFailure for each failed test that includes the description. (you can take a look at TestFailure API documentation – it’s lean and easy)

Why do I think so? Because writing your own TestRunner will probably decouple you from future sUnit development, and because writing an xml output is probably not the only place in which you might need the description.

What do others think? Should we change sUnit and add a TestFailure Class?

[UPDATE]: I just found out that sUnit V4 has a TestFailure class, as a subclass of Exception. From the comments on the SUnit Config Map in VAST 8.02:

– The major 4.0 change is to dispatch on the exception (see #sunitAnnounce:toResult:).  This allows
user-defined subclasses of TestFailure or Error to plugin different behaviour in specific cases.  (For
robust behaviour in the face of old code using pre-ANSI-error-raising, Signal also responds to it.)

So I now have to take a closer look at V4 to see whether and/or how I can collect them in a TestResult.

Still I think the design and implementation of #sunitAnnounce:toResult: is wrong or insuffcicient for reporting purposes. #sunitAnnounce:toResult: adds the TestCase to the list of failures, but what I’d really want is some extra infor to which I can add the error description so that it is accessible from the TestResult.

One approach (which seems obvious) would be to add the TestCase to the TestFailure Exception and add the exception to the failures collection. Thus the failures list could access all info that’s needed for Reporting.

I’ll have to Play with this a little, and hope to find some time in the next few days…

Smalltalk Solutions 2011: Agenda is online

Last night (at least european time) the agenda for Smalltalk Solutions was put online. There are a lot of interesting talks there, and especially for VA Smalltalk fans, there is something quite new here: at least 4 talks related to this platform will be given:

• Diane Engles (Instantiations) > Invoking a Smalltalk Hosted Web Service from an ASP.NET Web Application
• John O’Keefe (Instantiations) > VA Smalltalk Update
• Solveig Viste (Instantiations) > Using the VA Smalltalk Web Service Deployment Tool
• Donald MacQueen [(Instantiations)]> JWARS – Lessons Learned

So if you come to Vegas to attend Smalltalk Solutions, there is a chance to meet several members of the VAST development team. I am sure this is a great opportunity to discuss your problems, needs and ideas with the team.

The rest of the talks is also highly interesting. And the weather in Vegas is said to be not too bad in March ;-), so there are enough reasons to go.

Smalltalk Solutions: Early Bird Registration ends monday

In case you’ve missed it so far (freqent readers of this blog haven’t, of course…):

There’s ging to be a revamped Smalltalk Solutions Conference this year, held in Vegas in March. Keynote speakers are Avy Bryant (who once started Seaside with Julian) and John McIntosh (who ported Squeak onto iOS devices).

Even though there is no complete Agenda available on the web (or at least I haven’t found one), I’ve heard and read of a few interesting talks, so if you happen to be close to Vegas in early March, why not drop in?

There is an early bird registration offer, and due to some server problems STIC decided to extend the deadline for early bird registrations until Monday, January 17th, 11:59 pm. The stic website is not updated yet to reflect the extension, but that’s sure just a matter of minutes.

Build automation is social engineering

James comes up with an interesting observation:

It’s one thing to come up with a few simple tools to automate a build […] The harder problem is fitting the technical siolution into the process that your project has evolved.

I’ve been in that boat a few times (You can have a look at a talk of mine from last year’s VA Smalltalk forum here (PDF) (Video)).
While it seems easy to define a standard way of managing code, building and deploying artefacts and such, it can be extremely hard to use that way of doing things work in a project team that has

• existed for 10 or more years
• lost the people who once managed all that stuff
• always done it the way they do it (often without understanding why)
• never enough time to change such complicated and unimportant stuff (because improvements in the process do not immediately improve the product)

So I’ve given up on the idea of giving teams a toolset for managing their code and do automatic builds. This will surely fail, even if the tool involves automatic build servers like Hudson (which is really easy to use for Smalltalk builds). Because the hardest part is not to make Hudson or any other rool run. The hardest part is to change a team’s habits in order to deliver a codebase that can be handled by the tools.

My approach is to work with a team for a while and tweak my ideas and tools individually for that team or develop new concepts and tools with the team rather than trying to tweak the team too much. It’s good to identify problems and convince people to change their work style, but you can only go a certain mileage into that direction without risking to mess up the project completely or become the esoteric clown that nobody listens to any more.

It is much better, btw.,  to first see what problems the team has identified and try to solve these first. Many times, these have nothing to do with Build Automation at first sight, but with lack of communication or knowledge.

Build automation is social engineering – at least in existing project teams.

Commercial Break: If you are looking for a social engineer with knowledge in Build Automation in VA Smalltalk, perform these two easy steps:

1. look at one of the above-mentioned links to my talk
2. get in touch with us if you like what you see

 

Where to find GLORP info?

GLORP seems to be the evolving gold standard for O/R Mapping frameworks across all Smalltalk dialects.

It is, however, massively under-documented. I was quite shocked to find out that even VisualWorks NC (which is the flagship Smalltalk of Cincom, Alan’s employer) in its latest version 7.7 comes completely without any documentation of GLORP. At least I haven’t found it.

So here is a list of documents that I could find so far. Most of these are quite old and only cover the basics.

• The GLORP project homepage is hopelessly outdated and unmaintained. Sorry to start with this one, but this is really a pity, because most of the times, the hoempage of an open source project is a valuable source of information. At least most of the documents I found were linked to from this page.
• The GLORP Tutorial by Roger Whitney was so far my best source (in fact it seems Instantiations also liked it so much they copied it into their Database Guide – including the typos 😉 ) of information together with
• Nevin Pratt’s Glorp User Guide
• and a lot of experimentation and intuition
• There is a somewhat active Google Group for GLORP
• A few really good articles on Ramon Leon’s blog “On Smalltalk” (search for GLORP)

My impression is that most GLORP experts have been users of TOPLink before and therefor know the concepts very well. Having worked with and on similar frameworks, I find it relatively easy to find my way with GLORP, but still sometimes there are cases in which I’d like to simply walk to my bookshelf and look something up.

I like GLORP and so far I got everything to work that I wanted to, sometimes it was a bit of a pain, but I like it very much. Maybe I should add that I am using the version that shipped with VA Smalltalk 8.0.2, which is not really close to the current version. VAST comes with Version 0.3.178 with some VAST-specific changes, and the GLORP homepage says: The current version (2006-08-10) is 0.4.43. To my knowledge, work on GLORP has continued since August 2006 😉

If you now have the impression that using GLORP is not a good idea, you are wrong. Cincom has moved all their version control stuff in Store over on GLORP and GLORP is the Basis for their WebVelocity product. GLORP is being maintained, but somewhat secretly. So even though it is a good framework and there’s quite some mission-critical code using it, there’s no current material on it. Depressing, isn’t it?

Are you aware of any more information or documentation on GLORP?
Let me know in the comments!

Instantiations’ CEO Mike Taylor te be interviewed on Independent Misinterpretations

James Robertson just announced the next episode of the Independent Misinterpretations podcast:

The next podcast on the schedule will involve a look at where Instantiations is taking VA Smalltalk. Dave Buck and I will be talking to Mike Taylor, President and CEO of the company.

Now that Instantiations has sold their Java Business to Google and now fully concentrates on their VA Smalltalk product, it’ll be interesting to hear what Mike has to say about their vision and plan for VA Smalltalk. The podcast will be released next sunday.

The German Mac Keyboard is not developer friendly

I know that the vast majority of Mac users will probably not care about what I have to say today, but this is something I’ve hated about my Mac for a while now.

Back in 2006 when I switched to a Mac, the biggest problem apart from the poor Finder GUI is the fact that the German Keayboard completely lacks printed characters that you frequently need as a programmer.

If you sit in front of your Mac’s German keyboard and want to write a program in C, Smalltalk, Objective-C or most other programming languages, you won’t find any of these characters printed on your keyboard: “[{|}]~\” and probably a few more.

Don’t get me started about the key combination to enter a Tilde!
But that put aside, given the fact that in Objective-C, Apple’s favored programming language, is stuffed with square brackets for message sends and curly braces for all blocks of code, it is somewhat a crime to programmers to not print these characters onto the keyboard.

Since I guess many developers constantly move between Mac and PC, it is surely not only me who starts searching for them on the keyboard every time they sit in front of the Mac. My primary development environment is VA Smalltalk on Windows, XCode is more of a secondary environment for me, so the fact that all of the above-mentioned characters sit on different keys on a PC and a Mac make it harder (if not impossible) to transfer the knowledge on which key to press into the muscular brain.

Apple has a design principle of less is more, and most of the times, it works out really well. But in this case, it is a complete failure in my opinion.

I like my aluminium keyboard. It is nice to type on, I can go very fast on it without too much mistyping (except for special characters), so a third-party keyboard that could replace it is probably hard to find. The ones I’ve seen so far also have no special characters printed on them in the German layout. I am quite sure I couldn’t handle a US Keyboard layout, so I have to live with it (I know because I had to type on french, swiss and czech keayboards before and I really felt lost). Grrrrr!