Software Engineering Matters

I was fortunate enough to have the opportunity to go to OOPSLA this year. I say fortunate because I had to apply for a Canadian visa; and based on past experiences it can either be a painless ordeal or one where you are unsure what you have done to not deserve one. Anyway, all went well, and after 15 hours of driving and 12 hours of recuperative sleep -- I was not able to sleep in the van -- I attended the first day of OOPSLA without any problems.

The first day was relatively easy-going since I was not signed up for any of the symposiums and could freely choose which two tutorials (or none) that I wanted to attend. I chose the tutorials on Software Architecture by Michael Stal of Pattern-Oriented Software Architecture fame.

The first tutorial was during the morning session and was entitled High Quality Software Architecture. It was an interesting tutorial and I think I was the youngest person in the room. The tell-tale signs of balding heads indicated that most of the other attendees were professional software architects that were here to learn the secrets of the trade from Stal himself. Anyway, the first part of the talk was essentially a nice review of the material that I had read about a year ago when I took the Advanced Software Engineering class. In fact, I wrote articles on the books and papers that we read for that class here in this blog. Stal was using the same terms an definitions from the Software Architecture in Practice book. It was interesting to actually see how someone else who interpret that book since it was a rather academic book and it was hard to actually find someone else to discuss about it.

Stal emphasized three main issues that was only lightly touched upon in the book. And I agree with him that these three topics will help promote higher quality software architecture:

• Clear architecture vision: This is similar to the metaphor in XP or the ubiquitous language in Domain Driven Design. Essentially it means that the architecture should be driven by a clear idea of what you are trying to achieve. And the architecture should strive to maintain this goal in every aspect possible.
• Iterative Development: This is really important. Developers usually think of architecture as something that must always be done up-front. There is some truth to this since if you get the architecture (vs the design; see this for an explanation on the differences) wrong then there is a heavy price to pay in terms of development efforts. Stal solves this by introducing the concept of the baseline. The baseline is the core of the architecture that needs to be done right and will not change throughout the entire development cycle. The baseline is determined from a set of prioritized requirements from the stakeholders. Only the most important requirements shape the architecture of the baseline; the remaining requirements will be acted on later in an incremental manner. This balance on what to add first and what to add later makes sense: unlike design, software architecture will definitely permeate the entire system so it is essential to at least get the important aspects right the first time.
• Testing: It is necessary to be able to test that your system supports certain requirements. It is usually commonplace now to have automated tests for most of the functional requirements of the system. Stal claims that it is necessary to have tests as well for the system architecture. These tests need not be automated fully of course but they should exist nonetheless. Either doing it through a code review or a formal inspection would reveal missing requirements in the architecture. I talked to Stal about using executable Architectural Description Languages(ADL) to verify the architecture and he says that most of the time that approach is not feasible since it requires a domain expert on the ADL itself reaffirming what I thought about ADLs in the first place.

The afternoon session was on Refactoring Software Architecture. Stal admitted that what he was going to present was based on preliminary work but nonetheless he felt that it was essential enough to warrant a tutorial. I completely agree with him especially since he too mentioned the Grand Unified Theory of Refactoring at the end of his talk and if we have any chance of finding one we had to start thinking of a lot more about software in terms on refactoring and program transformation. Like Fowler, Stal motivated the indicators of architecture refactoring in terms of architecture smells or what he terms the lack of the following qualities:

• Pattern Density
• Symmetry
• Expressiveness
• Simplicity
• Orthogonality
• Emergent behavior

The list of refactorings that he presented were based in the spirit of the original refactorings by Fowler: he used a pattern language to describe them. When I first saw the first few refactorings that he presented I was confused by the scope of it: were they architecture refactorings or design refactorings? And this is where the distinctions in the paper Architecture, Design and Implementation might be useful. When I asked Stal, he explained that he treats refactorings that could have a percolating impact to be an architectural refactoring. So when you refactor something and it affects things below it then it is probably an architectural refactoring pattern. There is still this nagging feeling inside me that thinks that architectural refactorings might not be behavior preserving -- the quintessential definition of what a refactoring is -- but I just cannot come up with an example of this. So I could be wrong about this.

Stal has a list of roughly 30 refactorings. But the two that most interested me were Aspectize and Integrate DSLs. The former being that you might need to address some cross-cutting concern and use an aspect-oriented approach to solve it. This is actually the few times that I have seen someone promote aspects in an appropriate manner. Usually people are vehemently for or against aspect-oriented programming. Stal however, presented a clear case where aspects can actually be a good approach. The second pattern is all about not being reserved on using a Domain Specific Language for your architecture if you need one. Again, I think that the time for thinking in more than one language has come and this is one way to make good use of that approach. Software architecture can be a complex beast and while it might be usually over-kill to use AOP and DSLs for normal projects, architecture could be the key area where they should both have relevant roles.

Throughout both these presentations Stal mentions the need for iterative design and refactoring. He is clearly a strong supporter of refactoring. He realizes that all future software development can only be successful with decent and continuous refactorings. And he is far-sighted enough to see how refactoring can be applied not only to code but also other artifacts like architecture.

I was talking to Maurice and we both agree how our advisor, Ralph Johnson, could have made one of the greatest contributions to software engineering by introducing the concept of refactoring. Sure he has co-authored the book on Design Patterns but the main concept of refactoring is probably more influential. Thinking of software engineering in terms of refactoring and transformations is definitely how all future software should be developed.

There were a ton of demos going on at OOPSLA this year but I was only able to attend three of them. The three that I chose were all focused on Java or Eclipse development since I was really interested in finding out what we could use to make Eclipse a better environment for tool development.

Jazz

I did not go for the original demo of Jazz but rather stopped by the booth the next day to talk to some of the developers there. From what I heard, the original demo has some technical problems; they were doing a demo of two development team -- one team at OOPSLA and the other team in another part of the world -- and someone accidentally tripped on the ethernet cable and the demo could not go on after that.

Jazz is an all-in-one collaboration tool for Eclipse. It integrates version control, bug-tracking, task-management and even wiki editing! It could potentially do lots more but those were the features that I saw and which I was most interested in. In order to provide a better user experience the creators of Jazz decided to recreate some of the underlying features from scratch instead of relying on existing technologies that users have grown accustomed to. For instance, instead of relying on CVS or SVN, Jazz has its own version control system. When I first heard this I was rather doubtful of how necessary it would be since most developers are already using some system like CVS and might be reluctant to migrate over to something new. However, this issue is resolved by having an importer that takes the current CVS repository and converts it into a Jazz repository. I was at the booth during this demo and the person there actually imported the source code from CVS for the Photran project that we are working on and converted it into a Jazz project. The conversion retained the meta-information from CVS and this would ease the transition for existing projects.

The goal of Jazz is for all its features to work together seamlessly in a consistent manner. To fulfill this goal, the developers deemed that wrapping a myriad of tools such as CVS/SVN, Bugzilla, etc would not provide the best user experience. This might be true since tight-integration is one way to ensure that everything is working together without having to spend countless hours configuring all the tools to work together. Jazz comes with its own fully packaged server that contains all the tools that you would need to get started immediately.

The approach Jazz has taken is different from Mylyn, another popular Eclipse plug-in for collaborative development:

Mylyn FAQ - Eclipsepedia:

"At the EclipseCon and JavaONE 2006 conferences IBM demonstrated previews of Jazz, a collaborative team server and Eclipse-based client. Articles have remarked on the similarities between Mylyn and Jazz because both integrate tasks into Eclipse (Jazz's 'work items' and Mylyn's 'tasks'), and both provide change sets grouped by task. But there are both significant differences and complementary aspects to the two approaches. A key goal of Mylyn is to provide an open source framework to support integration of task management with existing issue trackers and source repositories. According to the presentations, components that come with Jazz include include a next-generation issue tracker and source repository and related lifecycle management tools such as project health. In addition, a driving and unique goal of Mylyn is to focus the UI around a usage-based and degree-of-interested weighted task context, which is complementary to the Jazz platform. Just as it integrates with Mylyn's Task List, Mylyn's Task Focused UI and task context model components are possible to integrate with other kinds of task management systems, such as the one provided by Jazz."

I have only begun using Mylyn recently and have been impressed by what I have seen so far. Our university Computer Science department has an existing JIRA server that we are using for our development needs. Mylyn connects seamlessly to it and works fine. It is this ability to interoperate with existing technology and tools that is the strongest advantage about Mylyn. Though I would really like to use Jazz it is not really practical to convince the technology services group to install a dedicated server for it when they are already using a bunch of existing tools that work well. I suspect the same situation occurs in existing software development companies as well.

The Jazz developers have already done a good job at reducing the initial risk of switching over to it by providing the importers/adapter that convert existing data into a format that Jazz can work with. If the Jazz developers could convince the Eclipse foundation to adopt Jazz instead of using their current tools, then it would make a big impact in convincing other projects to follow suit. Until then, most developers with existing projects might be less inclined to use it.

In this paper, Jackson addresses the issue of why software engineering (SE) does not generally fit into the notion that one would have of other engineering disciplines such as aeronautical engineering (AE)-- which he uses as his primary example in the paper. While AE has enjoyed a disciplined approach to building planes and other equipment for several years since its inception, SE has yet to discover its own set of disciplined approach. The emphasis here is on the term disciplined approach. While there are certainly many different ways to solve a problem, most engineers will stick with solutions that are commonly employed usually because they are almost guaranteed to work.

There is certainly no shortage of effort to present SE in light of the more traditional engineering disciplines. The existence of formal methods and other specialized math that has been employed in SE is a testimony to that. The specialized math present a means for modeling complex problems in SE. However, even with these rigorous math models, SE has failed to gain the distinction and recognition that other fields of engineering share.

In fact, Jackson identifies the current modeling for SE as a form of detachment from the real world. Jackson asserts that most of the modeling that has been done is influenced by Djikstra's view that computer science should maintains its mathematical purity and distance itself from the pleasantness problem -- whether or not the model conforms to real world requirements. This detachment from the real world is the root cause for the discrepancies that SE has with other engineering disciplines.

To bring SE closer to the realm of traditional engineering, Jackson proposes his theory of problems frames: viewing the problems that SE needs to solve in the context of the real world. While Djikstra eschewed the need for relating software to the real world, Jackson's problem frames theory promotes the real world into a first class component that needs to be considered as part of the model.

Generalized Problem Frame Diagram

Using the problem frames approach, software engineers can strive to model physical objects in the real world as part of the system that has to be considered. After all, real engineers always model the real world when solving the problems. To use the equations for fluid dynamics, an aeronautical engineer needs to set up the appropriate constraints - for instance the acceleration due to gravity, the viscosity of the fluid, etc. The equations for fluid dynamics can stand alone with all their symbols but unless one supplies the real world constraints, those equations remain nothing more than equations -- certainly a marvel of mathematics but useless nonetheless to the real world.

The astute reader will recognize that lots of problems SE might not have a direct correspondence with the real world. For instance, in a compiler, there is no direct real world correspondence. Jackson acknowledges that his problem frames approach would require some modification to be used under those context. Nonetheless, it is undeniable that most SE projects involve some identification with real world objects and thus the problem frames approach might be useful.

The greatest contribution of problem frames is the fact that it is not just another tool for modeling. In fact, I would categorize it as a tool for synthesizing and distilling the real problem that needs to be solved. After applying the problems frames technique of modeling, certain patterns begin to surface. These patterns are useful to help software engineers solve recurring problems.

As an analogy, one seldom solves a problem in its natural context since that would require too many unknown variables. As a greatly simplistic example, consider the problem of counting how many apples one has after frequenting the grocery store. After kindergarten, most of us would be able to just use numbers to represent the apples without actually thinking about the apples themselves. For instance, if one had 3 apples before and bought another 3 later, then one would end up with 3 + 3 apples. We have reduced the problem of counting apples to the problem of adding two numbers together. The ability to add numbers together is more important than being able to count apples since counting is a skill that can be applied to numerous other domains.

Similarly by using the problem frames approach, one is able to distill certain recurring patterns of modeling. Effectively, if one is able to solve one of those patterns, then the same solution can be applied -- with some modifications of course -- to other problems. Jackson himself acknowledges that this is similar to the notion of Software Patterns popularized by the GoF Design Patterns book. However, unlike software patterns, problem frames are language and system agnostic; their solutions should be applicable to different styles of software development.

In engineering, there are two forms of design: normal design and radical design. Normal design is achieved using a set established best practices. For instance, a civil engineer never needs to start from square one when he is designing a new bridge. Instead he follows known conventions for designing a bridge. In fact, the task of designing the bridge can easily be decomposed into several different smaller projects that other engineers can work on simultaneously. Indeed, it is this set of established best practices that enable normal design to occur.

While SE has definitely developed some form of normal design using some best practices -- using design patterns, choosing some framework to prevent reinventing the wheel, and even choosing the architecture to run the system on -- most of the time, some form of radical design is going on behind the scenes. A radical design is a design that is not based on any established set of rules. In fact, a radical design might be just be an ad hoc solution that is never to be seen again.

In SE, the number of radical designs dwarves the number of normal designs. This makes it awkward to call SE an engineering discipline. There are just too many ways to skin a cat. And this abundance of solutions itself is a challenge to this field. The lack of the best practice principles makes it hard for a new software developer to quickly develop a new system to solve similar problems.

In short, this paper views the abundance of radical design versus normal design to be the problem of SE. This overabundance is an indication that the field of SE has yet to mature enough that known solutions to real problems have manifested themselves. Problem frames is proposed as one way to distill the dormant knowledge that permeates those problems and present them in a way that a software developer can reason about.

In my opinion, it might not be possible to find a unifying method for software development. In many other engineering fields there are real physical constraints that must be obeyed for the system to work. There is nothing much you can do differently for a car since it must move along some road system. In SE, it is different. In software, you can do a lot of things differently unbounded by the physical rules. As an example, consider virtual reality games. Such systems are huge and each game tries to model the world closely. But there is nothing to prevent the virtual world to behave radically different. People could walk the other round and the game would still function correctly. In fact, other than the term virtual reality, these games have nothing much to do with reality since anything and everything can happen.

This freedom in computer science to model things differently is what makes it interesting for many people. In software, a lot of solutions are only limited by what creativity the designer can come up with. True, this leads to a whole hodgepodge of different solutions but this also makes this area of software more challenging. As another example, consider developing software for civil engineers. The software developer not only needs to know the domain knowledge -- how civil engineers reason about their tools and how to actually do the calculations -- but also how to write the software itself. To be useful, SE has to be cross-disciplined. Useful programs for other engineering disciplines can actually be done with software. Whereas I find it hard to imagine using some of the ideas from civil engineering to biomedical engineering.

So while problem frames is one way to solve certain problems, it is not going to radically transform the world of SE as we know it. Perhaps it is time to view software development as a different form of engineering -- one that is different from the other older disciplines. And if the word "software engineering" becomes a misnomer then it is only a matter of coming up with a more suitable name for it.

Squeak by Example:

"This book presents the various aspects of Squeak, starting with the basics, and proceeding to more advanced topics. This book will not teach you how to program. The reader should have some familiarity with programming languages. Some background with object-oriented programming would be helpful."

An updated book for Squeak is long overdue and Squeak By Example will fill that void. The book is still work in progress though a beta version of the pdf will be available soon. The Subversion repository of the LaTeX sources is available though and whoever is interested could generate the .pdf from that.

I find this book to be a positive step in introducing people to Squeak. I have commented before that a book is a physical manifestation of the quality and maturity of an open source project. If you dealing with a close source project then the company backing that project up could easily invest money into making documentation or even publishing a book in that technology. However, when dealing with an open source project -- where all documentation is freely available in the form of code as the proponents would claim -- the commitment to create a book shows just how much the community loves the product and want to get other people excited about it too.

A book shows commitment to the project. After all, why waste time writing a book if the project is going to die some time down the road. Now, this does not mean that the project will not die in the future. But it shows that the people behind it are committed enough that they don't foresee this project shutting down anytime soon. In short, the project has enough momentum to sustain itself for some time.

A book shows excitement for the project. And this book practically bubbles with it since it is co-authored by one of the most prominent figures in the Squeak Community, Stephen Ducasse. If a project leader is excited enough about the product to write a book then you can be certain that it's an exciting product.

A book shows the maturity of your project. After all, it's too risky to write a book if things are going to change. Maturity is a sign of stability -- meaning that this product is unlikely to undergo a capricious change in the near future. Thus, if your product depends on Squeak, it is probably not going to suddenly be incompatible in the future.

A book shows that other people are interested. Why write when you don't even have an audience? This is actually a catch-22 since you wouldn't write a book if there is no audience but you wouldn't really have an audience if you don't really have good documentation to inform them adequately in the first place.

In short, I think an updated book is a good sign that the Squeak community is committed and excited about how much quality and maturity Squeak has achieved. I will be looking forward to this book and hopefully be able to incorporate it in the Smalltalk class that I am teaching assistant for.

A History of Erlang:

This I did first in Smalltalk and then in Prolog. This was fairly sensible at the time, since I literally interpreted Bjarne's directive to "solve all of Ericson's software problems" as "program POTS in Smalltalk".

This post is based on the paper A History of Erlang by Joe Armstrong which was recently presented at HOPL-III.

About a year ago, I stumbled upon the article Erlang Stye Concurrency. It piqued my interest in Erlang and I decided that it would be an interesting language to learn. However, I put it off due to the lack of a good book. Now, a year later, there is a good book for it: Programming Erlang by the Pragmatic Programmers. I've managed to cover the first few chapters of the book and thus was acquainted with the basic syntax of the language. Erlang reminded me of a cross between Maude and Scheme.

Anyway, I had enjoyed a couple of papers presented at HOPL before and was delighted to see that Erlang had made the list for the latest conference. The paper is fairly easy to read and it does not dwell too much on the technical side of Erlang but it does have some interesting points, some of which I list below.

Erlang has this requirement where a variable must begin with an uppercase character. I was a bit appalled when I discovered this since it reminded me Prolog - a programming language that I have yet to appreciate. A identifier that begins with a lowercase character is automatically treated as an atom (or a symbol as one would call it in Ruby or Smalltalk). My suspicions on the connection between Erlang and Prolog were confirmed in the paper. Joe Armstrong, one of the creators of Erlang did indeed write the first interpreter for Erlang in Prolog. This was one of the reasons that the convention for capitalized identifiers as variables persisted in Erlang. It is also interesting to note - though not the fault of Prolog in any way - that there is an upper limit to the number of atoms that one can have in a program since atoms are stored in a fixed-size hashtable. This limit is some ridiculously large number but it is possible to run out of atoms nonetheless.

Another interesting aspect of the Erlang language is that the semantics of threads, processes, concurrency are built-in the language itself. In fact, the whole idea of concurrency and its importance at are the center of Erlang. After all, this was a language designed at Ericson to help the company solve its software problems. Thus, Erlang can be considered a large language which is, in general, frowned upon by language designers since it lead to complications in semantics, implementation, training, etc. However, the power of Erlang comes from its design since concurrency is already inherent in the language without the need for any other glue code or libraries.

Though not discuss extensively in the paper, Erlang has the useful property of being able to support garbage collection while still being able to meet the soft real time constraints that it was designed for. This property cannot be guaranteed 100% but the pathological case of the garbage collector interfering with the real time constraints is so improbable that is non-existent. The key strategy was to use per-process stop-and-copy GC. With many small processes, the cost of garbage collection would be negligible. The more processes that are used, the less likely that the effects of garbage collection would be noticeable.

Although Erlang was conceived by the scientists at Ericson, it was actually banned for new product development within the company during the late 90s! The good news is that this ban eventually led to the open source version of Erlang and paved the way for Erlang to spread outside of Ericson. Which is how we could get our hands of an implementation of it to play with.

Erlang is indeed an interesting language and it is one that I shall be devoting more time to now that I have purchased the book. Even during my early evaluation of the language, its model for concurrency seems more maintainable and understandable compared to the traditional view of using mutexes and semaphores.

This post is inspired by the contents of this entry at the Squeak Wiki FAQ. I just added some pictures to make it more clear.

Squeak is an interesting system. All the source code for the system is embedded in the system itself. This means that you can actually go ahead find the code where a certain feature has been implemented rather easily. And if you desire, you can even change that behavior to suit yourself. Of course, before either of that could happen, you need to know how to look for the code first. I am going to show you three methods for locating code in Squeak. As our example, we will be looking at ways to find where the "Save and Quit" functionality is implemented.

The first method requires the use of the Method Finder (or selector Browser). You can drag an instance of the Method Finder from the tools flap in Squeak. Or you can create a new instance from the World Menu. Just as its name implies, you can use the Method Finder to find methods. You just need to enter a fragment of the method name in the search box and look for it. Sometimes this requires guessing the method name. Fortunately the naming convention in Squeak is fairly consistent and most of the time your guess will help you find the method.

Here I am guessing that there must be a method called "saveandquit" so I enter that into the Method Finder (or Selector Browser) and try to find it. The results show that there is indeed such a method and that two classes have it: TheWorldMainDockingBar and TheWorldMenu.

In my previous post I mentioned some useful packages that do not come installed by default in normal distribution of Squeak. There are two ways that you can get hold of those packages in your image.

The first way is to download a specially packaged image that contains most of the developer tools. You can get that image from here. The advantage is that you get all the tools that Squeak developers usually use. The disadvantage is that if this is your first time using Squeak, you might not know all the tools. Hence you end up with an image that contains a lot of things that you will not use. And documentation for tools are usually pretty sparse so it is a good idea to start small and selectively choose the tools that you will use.

Thus, I present the second method to get hold of those tools: installing them as individual packages. For this process, I am going to start with a clean image to show you how it is done. I will install the Shout workspace package which gives you syntax highlighting in the workspace.

Bring up SqueakMap Package loader first.

One way to reduce the clutter in Squeak is to create projects. Contrary to its name, a project is more of a organized view of the image. Every project shares the same code in the image; changes made in one project affect code in another project that reside in the same image. So why would anyone want to do this? Like I mentioned, projects are a nice way to organize the things that you are working on.

A similar analogy is the mksession command in gVim. It allows you to record the current state of your files, which files are opened, etc. Eclipse has a similar feature called working sets but it is not as useful since it does not remember the files that are opened in the editor.

Give the project a name and then hit accept. You can now click on the project to enter it. You can even drag it around. Explore the project... menu to see what else you can do. One quick way to see all the projects and quickly navigate to them is projects... > jump to project...

An easier way if you have the navigator flap open is to select it and click the "NEW" button.

Once you get used to using projects, you will wish that every IDE has this feature. The ability to remember the exact state of all your open windows and their layout is actually pretty useful to get your brain back into the context it was in while working on your code.

There are lots of excellent introductions and tutorials on Squeak on there so this is not an attempt at another tutorial. Instead, this will hopefully be a condensed version of the information I would have liked to know the first time I use something like Squeak.

When you first start Squeak, your initial reaction might be something along the lines of: What is this thing!? You are probably in a state of shock and disbelief especially if you have been programming with text editors and the command line or use some nifty IDE. Squeak 3.9 actually has a more appealing interface compared to prior versions of Squeak.

After overcoming your initial shock, you are now ready to begin dwelling into Squeak. You should read all the initial documents that pop up when you first start Squeak. They contain useful information on how to get started. You should also be prepared to use a three-button mouse; while you can emulate the three buttons, having direct access to the buttons on your mouse makes you more productive. Squeak windows behave differently compared to normal windows in your operating system. You will need to click on the window using the right-mouse button to gain access to some of the window manipulation tools. Hover your mouse over each icon to get a description of what each does.

Here is what a typical development session in Squeak might look like. There will be a bunch of windows open as you develop in Squeak.

The main thing you should realize is programming in Smalltalk is very different from languages such as Java, Ruby, C#, etc. Programming in Smalltalk entails using its own system. You do not use an external editor, you do not really have a compile/execute phase, and you do not fire up FireFox to read documentation on the web! You even get some primitive form of source control without using CVS or Subversion! Everything for developing in Smalltalk in built-in. So when people refer to Smalltalk, they usually refer to the whole package. And yes, this does mean that you do not really have much of a choice if you would really like to use your favorite text editor.

I assume that you have done some of the basic built-in tutorials in Squeak and are familiar with how to navigate in Squeak. In the next few paragraphs, I am going to tell you more about the Squeak image and what you can do with it. I think this is fairly useful and will help you in case you did something wrong in your initial fiddling with Squeak and would like to find out what you can do to rectify it.

Everything you do in Smalltalk will eventually be saved in the image. The image is the file that you is named like Squeak3.9-final-7067.image. Accompanying the image are two very important files: the .changes file and the .sources file. Under no circumstance should you attempt to delete them (as I had in the past!) no matter how large they grow. I will explain one way to condense the .changes file in another post but for now leave it alone. For a short description of the purpose of those files, refer to here.

This image is actually a very useful. The closest thing that I can think of that is similar to a Smalltalk image is the image file that you use in VMWare. Even then there are subtle differences. Everything you do in VMWare is recorded directly into the image whereas in Squeak you have the option to just quit without saving the image. Note: This is a useful feature. If you think you have messed something up, you should always quit without saving. And when you restart the image, it reverts to the last time you actually saved it (where everything was hopefuly working).

What if you forget to save the image before quitting and you have just done a whole bunch of work? Does this mean that all your work is gone?! Fortunately it does not. Squeak stores everything that you have done in the .changes file. So you can always start with the last image that you have saved and then use the .changes file to get your stuff back in. This is a pretty cool feature and there is a video showing this in a different version of Smalltalk. To get the same features in Squeak, just left-click on the desktop, select changes..., select recently logged changes... and you have a similar menu where you can see the previous changes that you made.

What if you want to revert back to a previous version of the image after saving it? This is similar to version control and I will post more on that later. In a nutshell, there are two main ways to do version control: the changeset and Monticello. If you are new to Squeak, I suggest you just skip the changesets and take a look at Monticello. It is buit-in to Squeak 3.9 and most new packages that you might install are already using the Monticello format.

When you are just starting to get familiar with Squeak, it is always a good idea to keep a backup copy of the .image, .change and .source files. Even though there are tools that can help you restore the image, you might accidentally screw it up so bad that it is simply easier to just restore from a backup first and then try to apply your changes again.

Over the next couple of days, I will be explaining how to get hold of some tools that will make developing in Squeak more convenient for you. If you cannot wait, you can always try installing them on your own:

• eCompletion - Enables smart auto completion to the squeak system
• Shout - Enables syntax highlighting as you type in the code browser
• Shout workspace - A workspace that syntax highlights using Shout
• SVI - A text editor for Squeak that supports dozens of VIM and Emacs commands and modes. Useful when you really do not feel like picking up the mouse
• Whisker Browser - A browser that allows you to view/read/compare source code more intuitively

There is also a set of excellent screencasts for VisualWorks (another distribution of Smalltalk) available here. While the screencasts revolve around VisualWorks, there are similarities that make it pertain to Squeak as well.

Apparently, the same problem that hit my other blog a few months ago has haunted this blog. This morning, all I did was add a new category (the squeak category; new posts on that coming soon). After saving the changes, my entire layout was messed up. The CSS will not work properly and the theme will not even load.

Since I have already seen this kind of problem before, I just decided to upgrade to Typo 4.1. This upgrade process was long overdue anyway. After checking the typosphere.org website, I realize that Typo 4.1.1 was released. Usually I will not bother with a .1 increment release but with bleeding-edge software like Typo sometimes the latest version has bug fixes that will make all the difference between having a smooth transition and a few wasted hours trying to get things to work.

Unfortunately, Typo 4.1.1 required the use of a newer version of rubygems. The files no longer use the old require_gem method but the newer gem method. So it was not possible to install Typo 4.1.1

Anyway, long story short, I finally got Typo 4.1 installed, updated the theme (I used the default ones so that I will not suffer from any compatibility issues). There is some problems with the new sidebar AJAX interface: I was having trouble dragging and dropping the items; sometimes they refuse to stick to the active sidebar and merely float around the page.

Things seem to be working the way I want them to now and I will probably not mess around too much with the layout anymore.