Software Engineering Matters

About two months ago, I wrote my review for Eclipse 3.4 Ganymede and participated in the Ganymede Around the World Contest. As one of the first few reviewers, I am going to receive a Eclipse shirt. I have not seen the shirt yet but I have already provided my mailing address to them.

Also, I was fortuitous enough to be randomly selected as one of the 5 participants to receive an Eclipse jacket. So I'll be looking forward to that as well.

Eclipse Java Debugger screencast

Anyway, as a follow-up, I said that I will be releasing a screencast to showcase some of the new features once the official version of Ganymede has been released. The first (I am hoping that I wlll have time to create more) has been released on the CS 427 Fall 2008 wiki page: Eclipse Debugger. It shows the new Enhanced Debug Hover feature introduced in Eclipse 3.4. The screencast is catered toward students who have never used a debugger in an IDE before (I might be a bit presumptuous on this...)

Hopefully someone else might find the screencast useful.

In Fall 2008, the Software Engineering I class at UIUC would make extensive use of the Eclipse 3.4 Ganymede as part of their class projects. In the beginning of the semester, students will start out by familiarizing themselves with Eclipse as one of the best tools for Java development. After familiarizing themselves with Eclipse as a Java IDE, they will then be using Eclipse as a development platform for creating their own plug-ins. Specifically, students will be contributing plug-ins for the Photran IDE. Eclipse is a big ecosystem – up to 17 milion lines of code – so it makes an appropriate exposure for students so that they get some experience working on a large code base compared to some small and unrealistic assignment.

We followed a similar plan last year as well but there are some features of Eclipse 3.4 Ganymede that I think will help make the process a little simpler this time around. Eclipse has definitely been growing extensively – some might even argue that it is extremely bloated right now. However, each release has been getting consistently better with new features that are making it more and more useful as the single IDE for different programming languages, frameworks and platforms. IntelliJ IDEA still has some advantages over it but Eclipse is certainly catching up.

So here are my top eight features that I like about Eclipse and why they are useful from the point of view of a teaching assistant for a software engineering class. All pictures are based on the Photran project since that is the current project that I have which has been ported to Eclipse 3.4. I gleaned the list of features from the milestone pages since the official documentation for Eclipse 3.4 is not out yet.

1. Plug-in Spy

The plug-in spy running inside Photran itself; it lets you identify which plug-in contributed to the UI feature via a simple point and click.

Those of us who are accustomed to the debug halos in Squeak now have a similar – albeit less functional – version of that in Eclipse 3.4 called the plug-in spy. By using the keyboard shortcut Shift + Opt + F1 you can click on any view, dialog, editor or preference pane and identify which plug-in contributed that functionality.

This makes it much simpler to actually investigate and explore the plug-in system of Eclipse. On previous versions of Eclipse, you had to actually browse the documentation or examine the plugin.xml file to see which plug-in contributed that feature. Now all you have to do, for the most part, is point-and-click.

This is the first version of the plug-in spy and it will definitely improve over time. Right now, it doesn't let you inspect the buttons on the toolbars or the menu items in the menubar.

2. Extension Point Renaming

Renaming an extension point in your plug-in.

This is a simple feature but it will encourage students to rename their extension point to something more descriptive as they evolve their plug-in projects. Previously, if you changed the name of an extension point, you had to find all references of it yourself and then manually rename them.

3. Breadcrumb Navigation in the Java Editor

Save precious screen estate with the breadcrumb navigation in the Java Editor.

In the class, most students work from their 13 - 15 inch laptops. So anything that can save some screen estate in Eclipse will definitely be helpful. With the breadcrumb navigation, you no longer need to dedicated precious screen estate to the Package Explorer and Outline views – both are now consolidated into the breadcrumb navigation bar. You can easily access the project and package structure as well as the individual classes, fields and methods from the bar itself.

4. Enhanced Debug Hover

View the value of a variable right from the editor itself!

Students don't really know how to use debuggers. In fact, most of the think of debugging as a chore that is only performed as a last resort. But the debugger is not only for fixing bugs. It's a great tool for learning, experimenting and reverse engineering how your program works.

Though Eclipse already provides wonderful support for Java debugging (there is no need to jump into the console and use jdb), students don't use the debugger enough. So any improvement, no matter how small, to the debugger to make it more friendly is definitely an advantage.

In Eclipse 3.4, you can now hover over a variable and have its value pop-up in a dialog box all from the editor view itself. Previously, you had to go to the Variables view to examine the values of variables. It's just a step closer to the editor now.

If you have used Xcode before, then you immediately notice the similarities except that the debugger in Eclipse has many other interesting features that Xcode lacks.

5. Import/Export Launch Configurations

Share your launch configurations with your team.

Last year, we had to write out a step-by-step guide on how to setup a proper launch configuration for Photran. It was tedious and students tend to make mistakes while following the instructions.

This time, there is no need for such meticulous instructions. All the teaching staff needs to do is export the launch configurations and have the students import it. And we have just eliminated one accidental complexity from the assignment.

6. Eclipse Communication Framework (ECF) Bundled

Now you can communicate with you group from within Eclipse itself.

ECF is now bundled with the RCP release of Eclipse. It allows you to have IM, IRC and BitTorrent (?) from within Eclipse itself. We have a couple online students taking the software engineering class and such features will make it easier for them to do pair programming and collaborative development over the web.

The roadmap for ECF is pretty ambitious with hopes of supporting collaborative editing – all from within Eclipse itself. There is no definite timeline for those features yet but it seems that they are definitely being planned. There is definitely support for collaborative real-time editing now but I am not sure if the final features will be incorporated into the final release of Eclipse Ganymede.

I can't show you my IM list but at least I can link to an image from the ECF wiki showing the Contacts view and the supported features:

7. Highlight Read and Write Occurrences

Now you can see where the variables are being read or written to.

This is another small feature but it definitely makes it much easier to see where variables are being read/written easily. Previously, Eclipse offered the ability to highlight all occurrences of a variable but now it distinguishes between read and writes for you.

This is much more effective than having to do a text search of the variable and then jumping back and forth between each location like what you have to do in other less-developed IDEs.

8. JUnit Execution Times

Ever wondered how long your tests take to run? Well, wonder no more since the times are now displayed right in front of you.

Again another simple feature but this feature makes it really easy to eyeball if something is wrong with your tests. This is an easy way to check if your test are suffering from the slow tests smell.

Eclipse has certainly come a long way in terms on the features it offers. As someone commented on one of my previous articles about the OmniBrowser in Squeak, Eclipse definitely has a more polished and modern feel to it. Just as Eclipse has been learning and improving from the Smalltalk tools (most of the features that Smalltalk revolutionize are now part of Eclipse), Smalltalk implementations could also learn a thing or two from Eclipse. Eclipse has definitely set the bar high for competing IDEs.

I have just written a pattern language for screencasting based on my experiences producing and observing various screencasts on the internet. Through my experiences I have noticed various patterns that myself and other screencasters have used. Applying those patterns would certainly help the presentation of your screencast but, more importantly, I believe that the patterns enhance the teaching-learning experience of screencasts. And ultimately that is what matters most.

Interested readers may view the patterns here. The pictures that I have included are based on software for the Mac since that is what I use for my screencasting.

At the moment, it's a rather complete version of what I had originally envisioned for such a document. It can definitely be improved but I would like to get a version out on the web for people to read in case anyone is interested in providing feedback or suggestions.

I do maintain copyright on the document in case I ever decide to publish it at some pattern conference.

Ruby Is Smalltalk Minus Minus:

"--- Challenge to Smalltalk advocates: go ahead and reimplement DwemthysArray? then! The Array is a rather short program so it shouldn't take you too long. It's also rather well known, even celebrated, by now so a ST version will reach many people who wouldn't normally even notice ST advocacy. And an elegant implementation will frankly be a lot more convincing than 'sure, we could do that' assertions. We've been promised Smalltalk DWEMTHY before: http://redhanded.hobix.com/inspect/theRabbitWillDieInSmalltalk.html - who will deliver?"

BIG DISCLAIMER UPFRONT: This is just an exercise and I am not advocating Smalltalk over Ruby or Ruby over Smalltalk. Both have their strong points. I am just doing this out of curiosity and for fun.

I was browsing around the web and glanced upon the snippet above from the c2 wiki. I am not sure how long it has been up there (probably since 2005) but it seems that no one has responded to it. For those unfamiliar with it Dwemthy's Array it's a Ruby meta-programming example that is along the lines of a text-based game. I was familiar with it when it first surfaced but never thought of the need to implement it in Smalltalk since the approach is not very Smalltalk-ish in the first place. However, since I had some time, I decided to explore how it could be done in Smalltalk by mimicking the Ruby implementation.

A sample run of Dwemthy's Array in VisualWorks. Look at the Browser to see how I mimic the Ruby code. Notice that I still need to explicitly write the super initialize.

The gist of the Ruby implementation of Dwemthy's Array is the ability to write code like the following to declare a new class. It's simple and it reads like a mini Domain-Specific Language. Because of this, it also looks very appealing aesthetically.

class ScubaArgentine < Creature
  life 46
  strength 35
  charisma 91
  weapon 2
end

Basically it can be "de-sugared" to look like this which would make it more familiar. Basically the entire code relies on doing class method calls (the self.life) to create

# This is a comment
class ScubaArgentine < Creature # This declared ScubaArgentine as a subclass of Creature
  self.life(46) # This is just a call to the class method life i.e. Creature.life(46)
  self.strength(35)
  self.charisma(91)
  self.weapon(2)
end

The gist of how all of this is done is in the following snippet:

# Advanced metaprogramming code for nice, clean traits
def self.traits( *arr )
  return @traits if arr.empty?

  # 1. Set up accessors for each variable
  attr_accessor *arr

  # 2. Add a new class method to for each trait.
  arr.each do |a|
    metaclass.instance_eval do
      define_method( a ) do |val|
        @traits ||= {}
        @traits[a] = val
      end
    end
  end

  # 3. For each monster, the `initialize' method
  #    should use the default number for each trait.
  class_eval do
    define_method( :initialize ) do
      self.class.traits.each do |k,v|
        instance_variable_set("@#{k}", v)
      end
    end
  end
end

# Creature attributes are read-only
traits :life, :strength, :charisma, :weapon

In my opinion, the original article on Dwemthy's Array doesn't actually explain how things work clearly -- the author goes through great lengths to make it seem magic and the prosy language doesn't help clarify how it works underneath. Unfortunately, if I were to dissect it line by line it would make this article extremely long. So, instead, anyone interested in a better explanation so watch this video presentation or refer to the Pickaxe Ruby Book or the Ruby Way book.

In the following paragraphs, I am going to focus on what I think are the most fascinating issues of the implementation and how it could be done in Smalltalk. The following paragraphs assume familiarity with Ruby and Smalltalk reflection/code generation. This lecture slide from the University of Bern gives a quick refresher on Smalltalk reflection. My implementation is a direct-translation as close as I know how to implement it. So that means that I will be sticking to code generation, using class instance variables and a lot of class methods.

Dynamic code generation

Ruby offers method such as instance_eval and class_eval to make code generation slightly simpler. In addition, it also offers attr_accessor. Smalltalk, on the other hand, does code generation by using the compile: 'some smalltalk code' method. Code generation might be a misnomer since that is basically how everything is defined into the image.

The compile: 'some smalltalk code' is used behind the scenes in Smalltalk for generating accessors and doing other refactorings. I have not actually seen the instance_eval and class_eval used to do any refactorings.

Code generated in Ruby is also hidden meaning that you are not able to see the actual source/implementation of the generated method. This makes things more terse but can make understanding/debugging the program harder -- it really makes things much simpler if you could actually see the methods that are generated.

define_method( someName ) do |val|
  @traits ||= {}
  @traits[someName] = val
end

def someName(val)
  @traits ||= {}
  @traits[someName] = val
end

Every generated code in Smalltalk (using the compile: 'some smalltalk code') appears in the Code Browser like every other method, which brings me to the next point...

File-based vs. image-based implementation

Because Ruby operates in a file-based manner, it re-initializes the meta-programming facility every time you reload the file. For this form of programming, reloading the file has some advantages -- if you screw up you can just easily reload everything and not worry about side effects.

As I was doing the implementation in Smalltalk, I screwed up a couple of times and had to remove some of the generated code. Rather than unloading everything and loading it again (tedious and not very Smalltalk-ish) I implemented a reset method that removes all the dynamically generated code and resets other meta-programming constructs. So using my reset method, I can simulate starting from a clean state each time for testing purposes.

Additionally, one solution that I used to simulate file-based loading is to override the initialize method on the class side so that some action is performed as the code is loaded into the image.

In a nutshell, it is possible to simulate a file-based loading by writing proper reset and reinitialize methods. These methods definitely come in handy as I was doing this exercise since I don't need to unload/load the parcel in each time -- I did do that for the final testing to ensure that everything is working.

Dynamically Adding Instance Variables

In Ruby it seems that you can just define a new instance variable using @some_name or instance_variable_set("@some_name, some_value)and it will immediately be picked up. In Smalltalk, I had to ensure that I declared a new instance variable first using self addInstVarName: 'someName' and then I can change its value using self instVarNamed: 'some_name' put: some_value.

Instance variables:

"Instance variables do not need to be declared. This indicates a flexible object structure; in fact, each instance variable is dynamically appended to an object when it is first assigned."

This two-step approach in Smalltalk hints are the differences on the underlying layer on how instance variables are stored.

Class Instance Variables

Another important (and possibly subtle) point about the approach is the use of class instance variables. Class instance variables offers the ability of class variables without the problems that come about from subclassing. This is important because it allows classes to share common variables without interference from the class hierarchy.

By default, VisualWorks uses/offers class instance variables when declaring a new class. If you ever need a class variable then I think you would actually define what is called a shared variable.

Bottom line, class instance variables are really useful. Without them you would have to resort to a lot of trickery to share data between instance of a class while preventing access/modifications from subclasses.

Class Methods

The Ruby implementation above uses a lot of class methods. Class methods reside on the metaclass of a class. Fortunately Smalltalk follows this paradigm closely so it's not hard to implement these features. It just involves doing compile: 'some smalltalk code' on the right receiver. In my implementation, you will find a lot of the methods in the class side of things. Most of the instance methods are dynamically generated.

Implicit self

Ruby's implicit self does have some advantage here since it reduces the need to repeat self keyword over and over and over and over....

So here's my implementation in VisualWorks Smalltalk. I am not an expert in packaging parcels in VisualWorks so expect potential problems. However, even if you decide not to load it into VisualWorks it is possible to eyeball the code to get the gist of it. As far as I know, this is not a very Smalltalk-ish way to approach the problem. I did it this way to mimic the Ruby implementation as closely as possible.

The Ruby implementation seems very magical because a lot of the generated code is actually hidden. I think that if it were possible to just examine the generated code, it would make it must easier to analyze and reason about. It also enables you to use your normal tools for refactoring/ debugging. Of course, because things are hidden, it also makes the code terse and sometimes easier to read especially if you don't care about the details.

For an alternative approach see Darren Hobbs: Getting Meta. I am not really sure whether his implementation works in the end or not.

About a month ago, I volunteered as a shepherd for EuroPLoP '08. I shepherded an interesting paper which I hope will be accepted at the conference. I don't think I can talk about the paper here because of confidentiality issues but I can at least describe my experiences with the shepherding process.

I did the shepherding process pretty much based on my own experiences both as a teaching assistant and a peer reviewer for my colleagues' papers. Even though this was my first time shepherding, I think I did a good job based on what my sheep and PC member said. Today, I was pretty much surprised to discover that someone had actually created a pattern language for shepherding -- The Language of Shepherding. I was also pleasantly surprised that most of my actions were inline with the patterns from the article.

The following paragraphs are titled with a pattern from the The Language of Shepherding article and my experiences with that pattern.

The Shepherd Knows the Sheep

Start immediately to build a relationship with the author, and maintain it throughout the shepherding. Contact the author right away, even before reading the patterns, and tell the author about yourself. Tell the author what to expect from you (such as three iterations), and establish what you expect from them in return. Above all, follow through on your commitments!

Three Iterations

There is usually little time for reviews between the start of the shepherding process and the deadline for submission. Therefore, it is a good idea to establish a schedule at the beginning of the shepherding process. I have found that having an iteration be about 1.5 weeks long works out well -- a week is usually a bit too short. This allows for some flexibility in the schedule in case some other commitment pops-up halfway through the shepherding process. Once you have established a schedule (make this concrete by listing the actual dates that you expect an iteration) both parties should agree to stick with it. Having a complete paper at the end of an iteration (vs just having chunks here and there) is also better since it allows both parties to gauge the current state of the paper in its entirety and examine its cohesion.

It also helps to have a plan for each iteration. The first iteration should focus on the big picture of the pattern (and whether or not the paper is really a pattern). Subsequent iterations would be geared toward polishing the paper and making it more cohesive.

The hardest thing about iterations is to be mindful of consistencies. As the paper undergoes various rewrites, some parts can become inconsistent and need to be adjusted. For instance making sure that the same terms are used consistently throughout the paper is an important consistency to check for.

Half a Loaf

I found that small manageable chunks of feedback work well. Small comments tend to be more detailed and concrete and are easier for the sheep to follow. Thus, as the shepherd you are less likely to ramble on too much or dwell into some meta-argument of the paper.

As the original article suggests, it might also be necessary to give a full loaf sometimes. For instance, it is important to provide important feedback as soon as possible even if this might be a big comment. For instance, some changes are big and need to be made since the entire paper hinges on it. It's best to deliver such feedback early even if it would require a lot of explanation/reworking.

This makes it possible to produce a polished paper within the time constraints by addressing the most important issues first.

Small Patterns

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
-- Antoine de Saint-Exupery, French writer (1900 - 1944)

So it is prudent to keep the pattern short. It is best to prune pathological cases from the pattern that practitioners of the pattern are unlikely to encounter. Or it could also be a symptom that the pattern should be broken down into smaller ones. Anyway, a huge pattern is a kind of "pattern smell" and should be examined thoroughly.

Here are some of my own techniques that were not actually mentioned in the original article but which I found helpful.

Sheep Bleats

Usually as a shepherd you would be familiar with the domain of the paper. However, sometimes there will be certain details that you are not familiar with. Or maybe the sheep makes a very compelling argument for something that you are almost certain is wrong. Nonetheless you want to avoid unnecessary conflicts/arguments.

Multiple Examples

It's hard to explain something just by giving a meta-argument of the issue.

Interlaced Comments

This appeared as a candidate patlet in the original article.
You want to point out a particular section of the pattern that requires work by the author. Usually what you would do is write down the page and paragraph number and then describe the problem in the e-mail. However this has some potential problems:

1. it becomes tedious and confusing to refer to multiple sections.
2. there is the potential for miscommunication since people in different countries use papers of different sizes. So the page and paragraph number might be off.

If the use of such tools is not possible it might also be prudent to label the comments so that they can be referred to easily in subsequent follow-ups.

Using a pencil/pen or a tool also allows the embedding of non-text comments e.g. images. drawings, circles which might make it easier to communicate.

Modern Communication

Sometimes it is hard to express something in text. It could either get very verbose or you are afraid that there is a chance for misinterpretation. After all, e-mail doesn't really convey emotion that well.

I offered this option to my sheep but we never got around to using it. My friend Maurice had a chance to use it with his sheep and he told me that it worked well. Setting up a Skype session takes a lot prior arrangement from both parties since it requires you to set up a meeting that could span multiple time zones.

As far as I know, The Language of Shepherding has not been revised/updated since its inception in 1999. So hopefully the details of my experiences will highlight the fact that the article is still very much relevant for use circa 2008. Moreover, perhaps someone would also benefit from some of my suggested patlets.

Many people hear that the code browser in Squeak (or any Smalltalk for that matter) is designed for code browsing. In other words, the browser is optimized to help you read code.

However, I have found that reading code in the regular Squeak environment can quickly become a big mess especially if you are trying something out for the first time and need to read multiple implementations in different classes. Usually, when this happens, you end up with a proliferation of browser windows that quickly clutter your screen. I am assuming that veteran Smalltalkers don't find this a problem because:

• they know most of the methods so well that there isn't much need to refer to it
• they have LARGE monitors so 20 open browsers is not a problem
• they are just disorganized and don't give a damn about it

In this article, I am going to show you how to use the OmniBrowser with some new enhancements. The same group that made the OmniBrowser has also created a whole bunch of very nifty tools. I'll try to get to each one in separate articles. But before that, let me divert your attention to this very relevant message:

A Squeak Smalltalk Development Example:

"Most developers who use Squeak would have a plethora of extra tools and utilities installed that make developing a much nicer experience than what you see in this tutorial. Do yourself a favor and start your Squeaking with a real developer’s image loaded with all the proper goodies like the SqueakDev image maintained by Damien Cassou."

So at this moment, I am going to insist that you download one of the excellent images maintained by Damien over at his webpage. Don't even bother using the basic squeak image. The basic image is pretty disheartening and discouraging to any new developer who is trying Squeak for the first time. Since Squeakers are usually developers, I have always found it mind-boggling that the standard Squeak image does not include better support for developers out-of-the-box. Instead, it is cluttered with a lot of stuff that most developers don't care about.

For this tutorial I am using the squeak-web/beta version from here. Don't forget to grab the SqueakV39.sources file from here as well.

Here's our scenario: we want to see how to actually implement the relevant methods so that two objects can be compared to one another for sorting purposes. Here's a step-by-step guide to how I would use the OmniBrowser + enhancements to do it.

Open the SmartGroup Browser
Bring up the World Menu in Squeak and select the SmartGroup Browser.

Type in the '<' selector
In the top pane of the SmartGroup Browser type in '<'. The top pane is called the Mercury Pane and it lets you type in class/selector names and quickly displays it in the current browser for you. For more information about the Mercury Pane see this.

New window showing the implementors of '<'
A new windows pops-up showing the implementors. I think it is OK to have a new window pop-up with the search results. Also notice that this actually shows the classes in a hierarchical manner (by tabs). So you can see that Character is a subclass of Magnitude.

Search for 'Float'
Now back in the SmartGroup Browser, I am going to search for the Float class since I am interested in seeing the definition of the method for it. I am going to enter 'Float' in the Mercury Pane.

Split Panes in the Browser!
By doing a Shift+Click on a class/method you split a new pane with it!

Multiple Split Panes showing all the methods
By repeating the Shift+Click process, we can create as many split panes as we want. Usually it's enough to have about 4 of them. Also, don't forget that you can browse back using the '<<' button.

For comparison, this is what it would look like if we had to use the normal tools from the standard Squeak image. Look at the wasted screen estate and how I don't see any nice hierarchical information between the classes.

This is roughly what it would look like to find the '<' method in Squeak 3.10 without the new tools. We start by trying to look for the '<' selector in the Method Finder and then clicking on each method to see its definition. Notice that there can be no end to the list of new windows!

So I claim that by using the new tools, reading code in Squeak is much more organized. Good organization not only helps the developer focus but also makes it more approachable (and less intimidating) for a new user. Personally, I advocate that any new tutorial about Squeak be written with reference to these new tools. These new tools are hidden gems that need to be exposed to the world! Only by getting more people to use them can we:

• improve existing tools based on user feedback and experience
• actually get new tools to appear for Squeak - after all what's the motivation of creating new tools if everyone is just using the old way?
• change people's perception that Squeak's tools are 20-years outdated compared to more polished tools such as Eclipse
• make it easier for first-time developers to use Squeak. Seaside has already done a fantastic job garnering attention for Squeak and we should take this opportunity to make it easier for developers to get started

I also hope that people will be less close-minded about enhancing Smalltalk as evident from some of the comments in the following posts:

• Extending Smalltalk Syntax
• How Should We View Methods?

Of course, changes should be implemented judiciously but without an open-minded attitude toward change, nothing will change.

Fred Brooks, the author of the seminal book The Mythical Man-Month and the famous essay No Silver Bullet was invited to give a talk at OOPSLA 07. His Collaboration and Telecollaboration in Design talk addresses the issues that affect designs done in teams. Currently, the designs of complex systems are usually done collaboratively in teams because the design requires more effort and knowledge than what a single architecture can muster. However, design by teams present a new challenge: how do we get great designs when there are so many contributors? After all, it's pretty much a truism that too many cooks spoil the broth.

The key to achieving great design is maintaining conceptual integrity. Conceptual integrity is achieved when the system exhibits a consistent and unifying theme: everything seems to fit together seamlessly. Conceptual integrity is the presence of normalcy and the absence of radical designs in different parts of the system. A possible example of conceptual integrity would be the drag-and-drop metaphor found in most operating systems (done more right in some than others). If the system was design with conceptual integrity then drag-and-drop should just work everywhere. For instance, opening a file would just involve dragging it to the appropriate application; deleting a file would involve dragging it to the trash. In short, conceptual integrity (for the user and developers alike) creates an easy-to-use system with little surprises.

Ideally, conceptual integrity is easy to maintain when there is only one chief architect who oversees everything. This chief architect plays the important role of seeing how the pieces fit together. He might not understand all the details but he certainly knows at a high level how everything works. How would one achieve this in a team? It does not really seem possible to have multiple chief architects (in fact, that sentence seems grammatically wrong since chief already refers to a single person). There could be multiple architects but there is one chief architect who has the authority to make the final decisions. Even in an open source project like Linux, Linus Torvalds still has the ultimate veto power on what to put in and what not to put in. This almost seems like a dictatorship but if that is what is required for conceptual integrity then it is something that has to be done.

While collaboration should definitely be done, the need to actually appoint someone with the authority for making the final decisions should not be overlooked. According to Brooks, collaborative efforts such as pair-programming actually works to get ideas and design decisions out quickly. The important thing to realize is that certain phases of design requires decisions by an individual.

On the other hand, Brooks does not actually think that telecollaboration with all the fancy bells and whistles actually work. The phrase he used to describe this is profound: [telecollaboration sytems are] technologically-pushed rather than application-pulled. So most of the tools out there are just loaded with technology that no one needs to use. In fact, there is no need for fancy teleconferencing equipment: what is needed is a way to share the documents (via e-mail, source control, real-time editing, etc) and voice conferencing. Video conferencing does not bring any additional benefit.

Brook's thoughts agree well with what the two second-life developers said during a previous talk. The developers of Second-Life are located all over the world and they need to use telecollaboration as well. They use an application such as SubEthaEdit for real-time code editing. And they use the new 3D voice technology in Second Life to talk to one another while their avatars are positioned in a room inside Second Life itself. They do not use any form of video conferencing. This setup has been found to be effective for their development task and they have been using it for some time.

One final issue that Brooks addresses in his talk is the perceived malleability of software. Non-programmers have the notion that software is very easy to change - it's easy to add a feature, remove a feature or modify the feature. The software marketing industry is partly to blame for this perception since the marketing team is always touting that the latest version of application X and how it has 100+ features and tons of bug fixes. And they do these kinds of promotions annually. Is it any wonder that the masses just think that software is so easy to change?

In my opinion, this mindset causes many problems for developers. Requirements in software tend to change a lot more than any other engineering project especially once it has started. No one would change the design of a bridge halfway especially after all the foundation has been done. And yet, even after the architecture of software has been decided, it is not impossible to imagine the pointy-haired boss coming up to the developers and demanding a radical change. And this is why, agile methods have been so pivotal in the development of modern software systems.

Maybe people would think differently if they had something more tangible such as the printed source code to relate the efforts of software development. After all, it's easy to see how much of the bridge has been completed based on the visible structures. It makes me wonder if there are other areas which suffer from perceived malleability. I think fiction books suffer from the same syndrome since most editors might think it is very easy to rework the story line. However, this is not always true since the astute reader can actually find inconsistencies between the lines when the author changes the story line halfway through the book.

Fred Brooks is undoubtedly a very smart man. And his arguments, as shown in both the The Mythical Man-month and No Silver Bullet, hold true for many decades. In fact, it is unlikely that anything would come to contradict his arguments. After all, it's hard to challenge something that was written based on his observations on the projects that he was involved in. So when he says something about collaboration and telecollaboration, it's advisable for people like us to actually pay attention.

SeemleCode by Semmle is a tool for for Java and XML code querying. It features its own query language, unsurprisingly called, QL for Query Language and a set of UI options for displaying the results of the queries. Currently, the results could be displayed in a table or in graph form (pie chart, bar chart, etc).

from Class c
where c.getPackage().getName().matches("org.jhotdraw%")
select c.getPackage(), c

What I like about this system is the fact that the query language can be used to do a lot of useful things. The example script that comes preloaded with SemmleCode has some example metrics that you could run on you system. Here is an example that measures the Depth of Inheritance Tree.

from MetricRefType t, int d
where t.fromSource() and d = t.getInheritanceDepth() and d > 6
select t, d order by d desc

Moreover, given a complex enough query you could even use it as a form of code lint to check for inconsistencies in the code. So this system is extensible and could be used as a tool to query and inspect the source code in a non-invasive manner by the programmer.

SemmleCode comes with an in-memory database to store all the meta-information for querying. However, using this in-memory database for larger projects is really not recommended. Instead you should either install PostgreSQL or Microsoft SQL Server. Since I was on a Mac, I installed PostgreSQL and got it to work. The installation took only an hour or so (mostly because the internet connection was flaky) and PostgreSQL was easily installed on the Mac following the instructions that came with the download.

One caveat though and I discovered this after showing my installation to one of the developers present at the demo: SemmleCode operates on working sets in Eclipse. Unfortunately, those working sets need to be defined as Java Working Sets and not Resource Working Sets. SemmleCode will not recognize the Java files in a Resource Working Set since it is looking for the Java nature. After fixing this, SemmleCode works just fine. I ran it on the Photran source code and it was able to complete the analysis rather quickly.

So far SemmleCode is free to download and use. I suspect that a paid version would include a prepackaged library that has more sophisticated queries that developers might find useful.

I spent the morning in the Educators' Symposium at OOPSLA. It was an interesting session but unfortunately I could only stay for 3.5 activities since I wanted to go for the Dynamic Language Symposium in the afternoon.

We started off with a short session on how to teach recursion to incoming freshmen by Michael Goldwasser from St. Louis University. He had an interesting way for teaching recursion to first year students: he would pick a group of volunteers who would act as nodes in a list that is defined recursively. He would set it up so that each node knew which was the next list (null being the next node for the tail of the list). He would then act as the main program and call out a function like count() which returns the length of the list. His call of the function was symbolized by throwing a real tennis ball. This tennis ball was slit open and contained a piece of paper that was supposed to show the activation record of the current method call. In the case of count() each volunteer would then throw the ball to the next node and await a reply. This is a great way to illustrate how recursion works. However, I was a bit skeptical whether this activity might distract the students from the main concept of recursion. I was also curious whether this method of teaching recursion had permanence in the students's minds. Lastly, I wonder how well this method would scale up to a class that has 100+ students. Either way this was a nice method and it did give me some ideas for things to try on my students next time.

Next we had a session on Scrum. This was my first introduction to Scrum and it was pretty intersting -- it's a high level process that emphasizes customer needs and iterative design but it is not focused entirely on software development. So unlike XP, it is not explicitly required in Scrum to do pair programming or test first development. However, most software developers who use Scrum will augment it with those two practices anyway. It was a fun hands-on introduction to Scrum but again unless there is a decent reflection session after the activity I am curious whether the students will actually understand what Scrum is all about.

After the break, Kathy Sierra gave a nice presentation on how educators can create more motivating materials for their students. There were some nice gimmick tricks such as using bright colored slides, using seductive images, using animation, etc. These are definitely some ideas that I have to remind myself to use next time. Kathy is an engaging speaker and she managed to capture the audience's attention easily. I think she was the perfect person to give the keynote for the Educators' Symposium. Kathy also had a list of books that she thought was entertaining and enriching to read as educators. Here is a partial list of those that I wrote down:

• Flow: The Psychology of Optimal Experience
• A Smile in the Mind
• What the Best College Teachers Do

Before I had to leave, there was a presentation on Extreme Learning by two professors from the University of Utah. Basically it is a form of XP but in the process of developing the software, you had to actually put down goals to learn something. So you are teaching yourself new things as you implement the project. Again, this seemed rather intuitive to me: every time you do any major development you are bound to have to dedicate some time learning something new. The only difference in this case is that the student has to make it part of the user story to learn a new technology. This is definitely something that would be a good approach in a graduate level class since graduate students are often more mature and know how to organize their time to actually learn something new.

The Educators' Symposium is definitely fun and interesting. I wished I could have stayed for more of the sessions but the Dynamic Language Symposium was too compelling to miss.

BOFs or Birds of a Feather Sessions allow people with common interests to gather and just talk about anything and/or everything about their common interest! This time I went for three BOFs, all of them focused around Squeak and Smalltalk.

The first one was on Tuesday evening and it featured several short talks by various people. I have to say that the highlight of that BOF was about the by-now-well-known XO laptop (formerly known as the OLPC laptop). We even had two demo units available for us to try out if we wanted. The XO laptop is a marvelously piece of technology for its price. Undeniably, it is built to withstand all the harsh conditions that it might suffer through. However, as mentioned by the presenters the biggest roadblock for this project might not be technology but the lack of actual educational contents to put onto the device itself. Right now, there are no official educational materials that will be installed onto the machines yet. And for a machine that is supposed to function as the all-in-one textbook replacement, this is a major predicament. In fact, it might be a serious blow toward the success of this system. And no one knows what is the best solution to this problem.

There were also two presentations on language tools for Squeak: OMeta and CAT. OMeta is a project by Alessandro Warth and is already available from SqueakMap. It's pretty compact and has some nice features for parsing languages. Alessandro has actually implemented a Javascript interpreter on top of it but the source is not yet available. CAT is another tool for language recognition by Jamie Douglas. It has more features compared to OMeta -- can support PEG and CFG, has better error messages, automatic AST generation and some AST rewriting. It's currently not released yet but from what I have seen during the BOF demo it is as good as ANTLR and I will definitely be looking into it. It might be fun and useful to create a simple IDE for CAT in Squeak like what AntlrWorks does.

At another BOF that I attended, Dan Ingalls did a presentation of the Lively Kernel project at Sun. Basically the project shows an implementation of a Squeak-like system in Javascript. Since Javascript is supposed to be cross-platform and runs on all modern web browsers, it is one of the best choices to implement this project in. And by taking advantage of the latest SVG features in new web browsers, one can actually create a lot of graphics without all the overhead of loading images. The demo for the Lively Kernel project is available from its website and runs fine on the Safari 3.0 and above.

The final BOF I attended was the Seaside BOF organized by Roger Whitney who is currently on sabbatical at UIUC. Unfortunately I arrived late for this BOF since I thought I have misplaced my keys and had to go to the lost-and-found office to check on that. I must have arrived more than halfway through the BOF since they were already going into the QA session. The attendees had very different backgrounds: there were some newbies like myself who have read about Seaside but have never used it and there were clearly some veterans who have worked extensively on Seaside. It would have been good if a quick walkthrough demo could have been done to introduce the newbies to Seaside development. Some attendees did raise some interesting questions. For instance, how many projects were using Seaside; what is needed to set it up quickly; which databases did it work with; what hosting options were available (besides hosting it yourself). Fortunately there is an up-to-date website, appropriately named seaside.st, that addresses those questions. I must say based on the short demo that web development with Seaside certainly has a different feel. It requires the developer to use all the tools from Squeak (or some other Smalltalk version). However, like Rails, once you have accepted the philosophy of Seaside, web development is certainly better than what it used to be.