As an experiment, I started to work on a new look for Pharo and Moose that tries to maximize whitespace (I even chose a white whitespace). I started from the existing Glamour theme and removed color and lines where I did not see a good reason for having them.

My experiment is a primitive one: first, I started from a filled space; second, I only touched the theme of existing widgets without affecting the widgets themselves. Still, I believe it shows potential. Take a look at the pictures below (please try to ignore the thick gray buttons from the Pharo code browser).

You can reproduce the pictures by executing the following code in a recent Moose 4.8 image:

MooseImageSetupCommandLineHandler new
     installFonts;
     installAthens;
     installGLMWhitespaceTheme.

To exploit whitespace at its full potential we need to make our widgets less dependent on lines and delimiters. During this experiment, I realized that our interfaces get often cluttered because we rely on fine-grained widgets that are designed to work independently from each other. As a consequence, to ensure their independence they have to be distinct which often leads to explicit delimiters. A way out of this trap is to approach the design globally and construct interfaces out of higher level patterns based on widgets that work tightly together.

Whitespace is a resource. We should fill it only for a good reason. Carefully.

To fix the problem, I created a little project:

Gofer new
   smalltalkhubUser: 'girba' project: 'FreeFonts';
   package: 'FontInstaller';
   load.

The project contains the FontInstaller class (did I mention it was small?) that imports TTF fonts from the file system and installs them in dedicated classes in the image.

Let’s take a look at an example. To use the FontInstaller all you need are the font files. In our example, I downloaded the Source Code Pro font and unzip the contents in the Fonts folder next to the Pharo image:

| fontDirectory |
fontDirectory := FileSystem workingDirectory / 'Fonts' / 
                 'SourceCodePro_FontsOnly-1.017'.
FontInstaller new
   installFromDirectory: fontDirectory / 'TTF'
   url: 'http://sourceforge.net/projects/sourcecodepro.adobe/'
   license: ((fontDirectory / 'LICENSE.txt') readStreamDo: #contents).

Executing this code results in the creation of several packages, each of them containing exactly one class. For example, the regular font ends up in the SourceCodeProRegular class that is placed in a package with the same name. Fonts can add a significant size to the image, and users might want to load only a selected set from a font family. Having a one font per package mapping makes it easier to customize loading.

The font is stored as a byte array in the fontContents, and it also has an install convenience method that stores it in the font provider. The license and url are placed in the class comment, while the name of the original file (used for traceability purposes) is stored in another method.

Following this scheme, I created a repository (http://www.smalltalkhub.com/#!/~girba/FreeFonts) with fonts from five font families:

• Source Code Pro
• Source Sans
• Linux Libertine
• Linux Biolinum
• Deja Vu

For example, suppose you want to install the Source Code Pro Regular as a code font in your Pharo image. In this case, you need to load only the SourceCodeProRegular package and install it. The code might look like this:

Gofer new
   smalltalkhubUser: 'girba' project: 'FreeFonts';
   package: 'SourceCodeProRegular';
   load.
(Smalltalk at: #SourceCodeProRegular) new install.
FreeTypeSystemSettings loadFt2Library: true.
StandardFonts codeFont: (LogicalFont
                         familyName: 'Source Code Pro'
                         pointSize: 10).

All in all, we got one step closer to adopting Athens.

When most people think of the term "big ideas", they think of ideas that made it big. These are the BIG ideas.

But, I am more interested in those ideas that appear with big letters in your head. They make your eyes blink. These are the big IDEAS.

While BIG ideas capture the headlines, it is big IDEAS that capture the imagination. Just because you might not see right from start how an IDEA can become BIG, it does not make it less interesting. At least for you. And that is what matters.

So, what is your big idea?

Here is what we did for Moose. First, let’s start with the requirements:

1. We wanted to use the latest Pharo 2.0 image and VM so that we can provide instant feedback
2. We wanted to load the code that comes with ConfigurationOfMoose
3. We wanted to run all the tests that come with our configuration
4. We wanted to setup the image with Moose-specific settings and tools

The first requirement is supported out of the box via the bash scripts supplied by Pharo:

wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20.sh | bash
wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharoVMLatest.sh | bash

These scripts will download the latest image and VM and will unzip them in the current folder. Easy.

The second requirement is also supported nicely by the Pharo image:

REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main
./vm.sh $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development

What the script does is to trigger the config command line handler that corresponds to executing the code from ConfigurationCommandLineHandler. The CommandLineHandler hierarchy is a new addition to Pharo, and it essentially lets you customize from within the image the handling of command line arguments. In this case, the scripts loads the #development version of the ConfigurationOfMoose from $REPO, and at the end it saves the image.

The third requirement was only partially supported. The image comes with a TestRunnerCommandLineHandler that lets you specify something like:

./vm.sh $JOB_NAME.image test --junit-xml-output "Moose-.*"

However, Moose is a large project formed by multiple sub-projects, and we wanted to run not only the tests that are in Moose core packages, but also the tests that come with the sub-projects. To solve this problem, I created the MooseTestRunnerCommandLineHandler subclass that specializes the default test runner with a list of packages derived from the configuration:

MooseTestRunnerCommandLineHandler>>packages

  | packages |
  packages := Set new.
  self addTestPackagesFrom: self mooseDevelopmentVersion to: packages.
  self mooseDevelopmentVersion projects do: [ :each |
    self addTestPackagesFrom: each version to: packages ].
  ^ packages

The code makes use of the infrastructure provided by the superclass and just lists all packages that are in the ’Tests’ group in the current configuration and in all directly referred configurations. Once this new command is available in the image, we can invoke it via the command line:

./vm.sh $JOB_NAME.image moosetest --junit-xml-output

However, still the question was how to get it in the image. Nothing simpler: I just added it in a package loaded by the configuration (the package is called Moose-Development-Tools). Thus, once the configuration is loaded, we can simply run the tests.

This final requirement can not be supported out of the box by Pharo given that it is highly specific to Moose. To support it, I created another command line handler that can install the settings:

activate
  self cleanupWorld.
  self installLogo.
  self installGLMTheme.
  self installGTInspector.

  Smalltalk snapshot: true andQuit: true

This being achieved, we can run:

./vm.sh $JOB_NAME.image mooseimagesetup

That is it. With minimal shell scripting dependency we have achieved a rather complex setup of an image. For reference, here is the whole script:

wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20.sh | bash
wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharoVMLatest.sh | bash
wget --quiet -qO - http://pharo.gforge.inria.fr/ci/image/PharoV20.sources
./vm.sh Pharo.image save $JOB_NAME
REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main
./vm.sh $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development
./vm.sh $JOB_NAME.image mooseimagesetup
./vm.sh $JOB_NAME.image moosetest --junit-xml-output
zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources

The resulting image can be found at: https://ci.inria.fr/moose/job/moose-latest-dev-4.8/

The abstract goes as follows:

Meeting real deadlines is a hard and stressful job. It’s a job that typically eats all resources available, because when we know exactly what the best way is, we want to go full steam ahead. After all, we want to utilize our productivity to the maximum. Except that we typically do not know the best way. We know just a way and we get comfortable with it.

While the status quo can be comfortable, it is certainly not perfect. There always is something to improve. However, when entrenched in a routine we typically have no clue of what that something is and how to improve it.

In this talk we distill some lessons learnt from the time we spent in the research world and in helping companies rethink their approaches. It turns out that the path to follow is not dependent on the domain, and that a set of simple steps can get you quite far:

• Always challenge the assumptions behind the status quo, even when it appears perfect.
• Design your approach, don’t just settle for half-baked solutions.
• Demo your design, even when they seem hard to implement.
• Listen, especially when you do not agree.
• Enable new things to happen.

Of them all, focus on the demo. Relentlessly. Much of the rest will follow. This is the simplicity and power of the demo-driven way.

Why is this relevant? Because it affects everything you do, including the design of your software system, understanding your clients’ requirements, or managing your team. And because the solution is simple and cheap.

What is new:

• Integration of the Roassal visualization engine
• New PetitParser browser with integrated refactorings
• Improved Glamorous Toolkit for Pharo including the Glamorous Inspector and Debugger
• Several features in Glamour including Watcher support (similar to OS X preview)
• Significant improvements in FAMIX
• Improved external VerveineJ parser for Java
• Based on Pharo 1.4

A list of issues addressed in this release can be found at: http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%20milestone=4.7

Moose apprentice is an introductory course that takes you on a ride to learn to use the Moose analysis platform for putting the humane assessment method into practice. It is dedicated to software engineers that want to get better at extracting useful information out of their systems. The course sessions are driven by hands-on exercises.

To register, please contact me directly.

The course covers the essence of the humane assessment method:

• why software assessment is economically important,
• why adopting it explicitly in-house is the only viable solution,
• how to integrate it in the development process,
• how to embed it in the organization, and
• how to support it via a new breed of tools.

The course is interactive and it is dedicated both to managers and engineers. Why both? Because the problem is both economical and technical. Managers have to understand the technical challenges that consume the budget silently. And engineers have to understand the economics involved in assessment.

To register, please contact me directly.

Although the main message remained steady over the years, every time is somewhat different thanks to the students.

One thing that I noticed last year was that students do not expect presentations to equal bullet points anymore. It used to be the case, but not anymore. Something has changed and that is good.

As a consequence, this year I started directly with delivering a quick 10 minutes presentation about humane assessment. At the end of the presentation, I asked three questions:

• First, I asked what they understood from the quick overview. They said that it is an activity for software engineers and it is important.
• Then, I asked what they missed, and everyone agreed that it was too abstract, and that they did not really feel what I was talking about.
• And at last, I asked if they believed I was convinced of what I was talking about, regardless of wether they felt like they understood or not. They all said yes.

And this is the point. In 10 minutes, the most I could hope for is for them to precisely remember that assessment is an important enough of a software engineering activity to deserve a dedicated name. That was my message. My one message.

To make it stick, I wrapped it in a little visual story. While the visual could have captured the attention, it is the story that did the actual work.

And this leads me to the main message of the lecture: presenting is storytelling.

Next year, I will be giving the another lecture on the same topic. The story will likely be different, but the message will be the same.

This year, the topic is Models vs. Services, and the lineup of speakers is as impressive as it ever was:

• Jean Bézivin (University of Nantes, France)
  Should we resurrect software engineering?
• Cesare Pautasso (University of Lugano, Switzerland)
  Executable Modeling of Software Architectures
• Lukas Renggli (Google, Switzerland)
  Practical Models in Practice
• Markus Völter (itemis AG, Germany)
  Modeling and Programming: isn’t it all the same?
• Carl Worms & Ksenia Wahler (Credit Suisse, Switzerland)
  Services and Models in a large IT system

Book it while it’s hot. The early registration ends on December 1.