Here’s the link to the translated page: Squeak Tutorial page translated to Serbo-Croatian.

I added a note to the page explaining what happened and why. Pretty neat.

I decided last Fall to take a crack at writing an App for the iPhone and iPad to be included in the App Store. Using my Laser Game published as a tutorial for Squeak as a starting point, I rewrote the App using Objective-C. The idea was to keep as much of the initial design and Smalltalk object models as possible.

Now I had seen Objective-C many years ago, 1993 I think it was, when I was investigating NeXT Step on Intel computers. And I knew it was a “cousin” to Smalltalk, having been launched by Brad Cox as an attempt to make Smalltalk-like programming on top of C. That may just be a poorly formed opinion of my own about Objective-C’s roots. I had not programmed in C since maybe the late ’80s.

So with a few books and tutorials on learning Objective-C in hand I dove in. At first, not unexpectedly, I was very frustrated with the tools and libraries because of a lack of familiarity. On the other hand, I can see why there’s developer loyalty about Objective-C. It is actually enjoyable coding once you get use to things.

Okay, long story short, I’ve published my App in June 2011 after many interruptions and typical other distractions — including being very busy at my regular Smalltalk professional work. After that initial hurdle of getting the first App finished and published, it’s been quite enjoyable to add new features and also polish up the code. As I’ve gotten smarter about coding in Objective-C I’ve been changing the implementation, refactoring and replacing code here and there.

Without any real attempt at marketing the App, I’ve had some success in sales. That was a real surprise. My purpose was to gain the experience of writing an App for the iPhone and iPad and to have something to point to as a “notch on my resume” for technical skills. It didn’t matter to me at all if the game sold. But I am delighted to see people have been downloading it and playing the game. In fact, what’s really cool is that people all over the world have downloaded and installed my Laser Game App. Apple makes publication of Apps worldwide very easy to do.

I just submitted Version 1.2 to Apple for approval. Considering the Fourth of July holiday I suspect it will be approved around mid-to-late-week coming up. The V1.2 update is a significant improvement over the previous designs. I feel like I’m just starting to get on a roll here.

The App has it’s own web page for news and support. I recently published some screenshots showing how the new release appears.

All in all, I really prefer working in Smalltalk and am much faster at developing there than in Objective-C. And that’s to be expected since I’ve been doing Object Oriented work with Smalltalk since the late ’80s. But I can say that developing for the iPhone and iPad with Objective-C is quite enjoyable and I hope to keep getting better. Also, it really is cool having my own App running on my iPhone and iPad.

More to come, I’m sure.

Just read this evening that Google purchased Instantiations. Here is the Instantiations web site with an official report.

http://www.instantiations.com/

Wow. Of course I know the Instantiations folks really well, having worked with many of them for years and I congratulate them. I’m guessing that Google was mostly interested in their Java tools, but I have to wonder if they appreciate the Visual Age Smalltalk product that Instantiations also produces. That’s some formidable team and product line they purchased and I wish Eric and the rest great success going forward.

UPDATE: I have part of this wrong. Google purchased the Java tools. Instantiations will remain as a Smalltalk only company.

While I’m busy posting about Smalltalk….

Something very interesting happened to me today.  One of the developers I work with came to me and explained that he downloaded and tried Cincom Smalltalk over the weekend.  He’s already familiar with Smalltalk since we use Visual Age Smalltalk everyday, and he knows I’m also a Squeak advocate.

It was funny to me when he mentioned how impressed he was with the professional quality of the product.  My first reaction was to think “of course it is”.  Then I commented that I think VisualWorks (or whatever they are really calling it nowadays) is one of the finest Smalltalk products on the market.  No, I’m not putting in a plug for Cincom and I don’t owe them any favors.  I used to work with VisualWorks years ago and came to appreciate how well crafted that dialect of Smalltalk is.

I often write here about Squeak but then realized that I’ve never said much about VisualWorks or Visual Age, the 2 leading commercial professional Smalltalk products available today.  They really deserve a look.

Here’s the link for Cincom Smalltalk: Cincom Smalltalk. They offer a non-commercial license and you will find a rich family of experienced VisualWorks developers available in the community.

I’m a long time developer with Squeak. And I’ve seen a lot of the changes and how it has morphed over time. Literally. Remember when everyone using Squeak used MVC? I’ve made a number of contributions over the past 13 years or so to Squeak. So make no mistake about it. I love Smalltalk, I love Squeak and working with Squeak.

This entry is about something that I both love about Squeak and occasionally get frustrated about.

There are about 3 or 4 (but who’s counting?) personal on-going projects I’m developing with Squeak. Over the weekend I was working on one of those projects. And I noticed how frustrating the behavior of the system browsers are when resizing the panes. Here’s what I mean.

This is the standard Squeak system browser when it’s first opened up. Click on the image to see it full size.

Basic System Browser when opened

The browser is highly functional in its current presentation. You may have noticed that I use the Optional Buttons and Annotations Pane for my browsers when I work.

It’s all fine until you resize the browser window. Here’s how it appears when you make it really tall.

Again, click on the image to see it full size.

Standard System Browser made tall

Notice what happened to the Class/Instance switch? Stretched out. And those Optional Buttons and Annotation Pane? Same thing.

It gets especially interesting when you want to shrink it down to something taking up less space on your desktop. Click on the image to see it full size.

System Browser when squeezed

I’m not sure how or when this happened, but I’m 100% certain there were versions of Squeak older than this that didn’t behave this way with code browsers. I remember working with Scott Wallace on the Optional Buttons and Annotations Pane layouts in earlier Squeak browsers maybe 9 to 10 years ago.

Now, I’m not frustrated that this is happening. No, no. Well, maybe a little. It does seem like we get pretty good at “chewing the same meat twice.”

But in fact this leads me to one of the things I really love about programing in Squeak, or any Smalltalk for that matter.

It’s easy to fix.

I spent a couple of hours over the weekend digging around inside the classes that constitute the System Browser and its related components, and created my own version that behaves like this.

Here’s my new System Browser when first opened up. Click on the image to see it full size.

Modified System Browser when first opened

Notice that it looks the same as the original did. I actually think it looks a little “tighter”, with less space, around the optional buttons and annotations pane.

Here’s how it works now when stretched really tall. Click on the image to see it full size.

Modified System Browser stretched tall

The buttons, all of them, stay the same size. This remains true for the annotations pane as well.

And here’s how it works when squeezed. Again, click on the image to see it full size.

Modified System Browser when squeezed

Same result. The buttons remain the same size, and even better, you can still read them.

So that was fun and rewarding in its own way. That’s one of the things I love about Squeak. But alas, this is also one of my frustrations.

I find myself getting distracted by this sort of thing all the time. Instead of working on the task at hand, I find new “interesting” diversions. Sure these have value and it’s always good to dig around inside Squeak to learn how it works under the covers now and then.

As an aside, that’s one of the things I have come to admire about Smalltalk developers that have spent a lot of time with Squeak. Historically, there’s been no documentation to speak about. Books and tutorials have appeared only recently. Well, there were Mark Guzdial’s excellent Squeak books years ago, but for the most part you had to figure things out on your own. You had to learn to read the code and dig things out to understand. Skilled Squeak programmers end up being good at understanding and extending other complex Smalltalk systems and applications.

What I would like to say is that I love how Squeak is open under the covers, and so easy to explore and extend. All the Smalltalk tools do that. But I’m also aware of how these little annoying behaviors about Squeak have more that just a few times caused me to become diverted by yet again another tools enhancement run. The temptation to personalize it, which is exactly what I think Alan Key and Dan Ingalls had in mind, can be great enough to the point of distraction. You just have to remember that.

Comments and feedback on my personal BLOG are welcome.

I was thinking about how you can tell if someone is really interested in something. Sometimes you will hear it described as being passionate. “He is passionate about musicianship”, for example.

Dictionary time. Passionate: having, compelled by, or ruled by intense emotion or strong feeling.

It has been my observation that being talented is not what it takes to be exceptional about something. It’s passion. The lexicon of those individuals who have created products, companies, or content, seem to always include that those individuals were passionate about it.

To follow the musicianship idea, the outstanding examples of musicians you can think of are probably all individuals who are passionate about their craft. Somewhere in the equation we probably assume that genius or innate natural talent is also required. I believe that passion in a subject also drives someone to a high level of focus and detail. A passionate guitar player will never have to be reminded to practice their craft to become better musicians. Passion can also make up for genius. Although I think talent, is required.

If someone is passionate about something they think about it a lot. Morning, noon and night. Perhaps the passionate amongst us are even seen as “unbalanced”.

If you are interested in creating an excellent orchestra you would think a lot about having passionate musicians included. Your First Viloin is probably going to be someone with a lot of passion about playing the violin. You don’t have to remind them to practice.

I’ll bet your First Violinist is not a “9 to 5″ musician. Doing only what it takes to complete the work. They are probably not in it just for the money either. We’ve all met those folks.

To carry the orchestra metaphor along, a successful orchestra has the full range of musicians. People will demonstrate different levels of passion about their craft. It doesn’t work if all your Violinists are First Violin. Everyone should be passionate, but they also need to play well together. In an orchestra a skilled musician is listening to what the others are doing while playing their own instrument. They both know and can hear where they fit in.

Obviously I’m also writing about software development teams. The metaphor works.

I think it works when you interview someone to join your little software development orchestra. I pay attention to the level of passion the individual demonstrates. Do they practice their craft after hours? Do they read, write, and talk about their craft all the time?

I continue to receive emails from students new to learning programing, object oriented development, Smalltalk and Squeak, as they go through my tutorial LaserGame.

Recently I was reminded again that I misunderstood my target audience when I wrote that tutorial.  My original goal was that this would be a process showing development through-to-completion of a delivered application all written in Squeak using Test Drive Development and generally sound everyday development practices.  And I thought the tutorial would be utilized by students having already learned the basics.  That turned out to be way off base.  I get letters all the time from complete newbies telling me thank you.

And earlier this week I was asked by one of these less experienced students about how I did what I thought was a very basic step in the process.  But of course, someone new wouldn’t know that.  My mistake.  So I just published another update with a clarification in that section.  I’m so grateful for the positive feedback that I get.

Here’s the updated page: http://squeak.preeminent.org/tut2007/html/038.html

I’ve made a lot of noise about doing a complete rewrite of the tutorial, in the past.  Yes, I have not completed that work.  First there were health concerns interrupting my work, then some health issues within the family.  Lately it’s just been too many other projects.  It’s amazing that I was able to carve out a clean free-time space and create that tutorial in 2007 like I did.  I think the whole thing was written and published over 4 weekends during that summer.

When I get back to the project I have several new goals in mind.  First off the tutorial will account for the inexperienced motivated student.  I’ll have more detailed notes and examples.  I’ve already started rewriting much of those parts.  I’m also uncomfortable that I gloss over some design considerations in a few places and want to amplify upon that work.  I’m also intending to make the tutorial available in book form, probably through LuLu.com.  Two other goals are worth mentioning.  I intend to have a version of the tutorial support the new dialect of Squeak called Pharo.  That actually complicates things considerably since the tutorial relies heavily on screenshots and the two dialect look so different.  I’m guessing I’ll have to create some of the Morphic objects that LaserGame uses but do not exist in Pharo too.  Lastly, I think the tutorial could easily be extended to take the student as far as making Laser Game an iPhone app.  That would increase the audience for Smalltalk development too.

This is a comment for fellow software developers. Has this ever happened to you?

I just awoke at about 3:00 AM from a sound sleep with a single thought: “I should have used an IdentityDictionary object.”

Yesterday I completed an activity at work that concluded several days of redesign and code refactoring. I deleted quite a bit of code and unified how some basic operations were performed. And I just realized that one of my new core operations was always using Symbols when accessing a Dictionary.

I know what I’m doing first-thing when I get into the office this morning.

Here is a report of how the US Navy is using a 3D simulation environment, written in Squeak, to evaluate submarine console designs.

http://gcn.com/articles/2009/08/24/data-visualization-sidebar-2-navy-sub.aspx

Context
This is going to be a small rant. Before I begin I should set a context. I’ve been programming computers now for more than 30 years. And I’ve had the good fortune to have paying jobs doing Object Oriented Programming (OOP) in Smalltalk for over 20 of those years. I enjoy this work very much.

Furthermore, my experiences in programming has been relatively broad in that I have worked on financial applications, insurance applications, development utilities, industrial process controls, point-of-sale kiosk software, Virtual Machine-level troubleshooting, entertainment software and applications delivered in multiple human languages. Once even in Kanji, but I can not read a work of Kanji. I’ve also conducted workshops and seminars, provided many mentoring and tutoring sessions, and have worked as an Adjunct Professor teaching programming skills.

But this is not going to be a rant about “How we used to do things.” I’ve noticed as I work with teams developing software there are a few common problems and behaviors encountered regularly.

Knowing that I have an “astigmatism” because of my deep involvement in the Smalltalk community, I have a tendency to view many aspects of programming through the lens of an Object Oriented Programming developer. I see things in a very Smalltalk-centric way and I’m discussing things seen on Smalltalk projects. However, I’m guessing there is a level of universality.

Complex problems to model
It doesn’t matter if we are talking about financial settlement models, high speed process control systems, high speed transaction systems, insurance billing models, serving up reports over the web or whatever. These are complex systems. These problem domains are often loosely defined and changing throughout the development cycle. Complex problem domains often include nuances and subtlety seldom encountered in everyday programming projects.

Smalltalk is used to handle complex problems
Smalltalk is often used to handle complex problems because it can do it so well. Smalltalk makes modeling complex systems simple. For both Object Oriented Programming and Smalltalk, I can say that I have never worked with a more productive environment that allows programmers to tackle difficult problems with rapid reliable results.

Handling the complex well is one of Smalltalk’s strengths. And here’s the really cool part. Smalltalk syntax is dead simple and easy to read.

While it’s true it may take years to acquire the skills of a more seasoned Smalltalk developer, folks with a decent amount of Smalltalk literacy (and I’m talking about what you can learn in a weekend) can make meaningful contributions to a team project even as newbies with proper coaching and mentoring available.

That’s the beauty of Smalltalk. It provides a rapid reliable development environment for complex problems in a an approachable manner. Smalltalk is not “file-centric” like some of the so-called modern programming languages, so that takes a little getting used to. You do almost everything inside code browsers, inspectors and even develop within the debuggers. The language itself is easy to learn.

The class library of Smalltalk, refined and developed for over 30 years, is both rich with capability and daunting to approach for a new-commer. You could probably make that statement about any rich library of information, even those outside of programming. The skills required are learning how to look for things, how to recognize their value and where and when to apply what you know. But you also can start out doing quite powerful things after grasping just a few key core Classes in the library.

Complex code
It also evident that complex models are created to solve complex problems. Keep this in mind. Smalltalk helps to make the complex easier to express and model. Smalltalk code can be very simple to read and understand.

That’s not the same thing as saying you can write code without careful thought and study. Remember we are modeling complex problems with powerful software.

In addition to good Object Oriented Programming concepts, most Smalltalk development teams use SUnit. This is the testing framework behind the modern concepts of Test Driven Development (TDD). It’s roots began in Smalltalk and are often integrated into the everyday development processes the Smalltalk teams use to deliver quality code.

I’ve become a strong advocate of this approach, recognizing it’s strength’s and weaknesses, and consider TDD an essential component for delivery of quality code.

Development team composition
Modern software development teams are not composed from a full compliment of strictly seasoned programming veterans. In fact, it’s been my experience that teams with limited diversity in experience are often the worse performing. A full team of “Type-A” individuals will have a high level of both churn and drama. A good team has a mix of high-end talent, less experienced programmers, and developers with good business domain skills. It works just fine if the domain experts also have the least Smalltalk programming skills. Over time domain knowledge and programming knowledge will grow for the entire team.

Usually the more seasoned the developer, the lighter and cleaner the code is. A seasoned developer will write less code and often deletes code. I know, that seems contradictory.

Learning Smalltalk
It takes very little time to learn how to develop in Smalltalk and become a contributing member of the team. It takes a little more time to develop decent Smalltalk literacy skills, where the developer can browse code and quickly understand what is really going on across multiple collaborating objects. It can take quite a while before the developer begins to leverage well the deep Class library of code available.

Issues
A problem occurs when Smalltalk developers without strong code literacy skills (reading and comprehension) are writing enhancements for or fixing bugs in existing code. They often don’t catch the nuances in the code. But it’s often not their fault.

Let me draw out an example or two.

Example 1. The relatively new developer correctly determines that the root cause for a problem is code that exists in a common super-class. So he or she begins to modify code in the super class without really noticing how the other subclasses use it. Things could break. Hopefully the team has constructed a strong suite of SUnit Tests that will catch if a programmer inadvertently breaks something in this manner. But it can be difficult to detect.

The developer should apply code refactoring to break out unique behavior amongst the subclasses. A new developer should not be expected to have those refactoring skills. That takes time and training. Mentoring or “just-in-time” pairing helps.

Example 2. Smalltalk is a “late-binding” environment. That is, the “type” of an object is often irrelevant if it is passed as an argument along with a message. The receiving object will handle whatever it gets. Sometimes a developer will attempt to simplify method arguments so they are always assumed to be of one specific kind. Sometimes this is done to an extreme level. For example, an Array object is a kind of Collection object. You can ascertain it’s size (dimension) and you can access it’s components by iterating over it with indexes. However an Array object is a fixed size. An OrderedCollection has many of these same properties, also inheriting from the Collection class hierarchy, but you can change it’s size by adding and removing items. If the developer starts writing code assuming the argument is always an Array, a consumer of this method may discover they can no longer use it’s service for a more flexible Collection type. It breaks.

The developer should examine the known senders of the message and see how it is used. Also, it’s almost always the case that correct behavior in a method allows for the more general object to be accepted as an argument. New developers often don’t realize the subtlety and power that comes from polymorphism.

Example 3. We are often taught that comments in code are a good thing. Certainly throughout our school years we’ve probably even gotten feedback that not enough clear comments exists in our code.

I tend to take the opposite view. A comment is a sign that something hard to understand is happening in the code. The correct approach, in my opinion, is that the code should be made self evident. Add a comment if you need to alert the developer to something, but do it sparingly. Comments never tell the computer what to do. A comment is a note to a human being.

Time out for a humorous story.

A Computer Science student with excellent skills and grades volunteers to help out at the computer lab at school as a lab assistant to help newer programming students work on their assignments. One day a very frustrated student approaches the lab assistant with computer printouts in hand and, exasperated, exclaims that he just cannot get the program to work. The lab assistant begins to pour over the program listing. While examining the code, the new programming student exclaims, as a way of demonstrating how frustrated he is, “I get the idea that the compiler is ignoring all my comments.”

Comments never tell the computer what to do. The programming statements do. So why am I writing about this? When I find code that has a lot of comments in it I get curious and begin to review it for possible flaws in the logic. The programmer obviously thought it was difficult to write and understand. It’s a tip-off for me. I once even saw a comment that said “I pray to God this works.”

Oh yeah. That will work. A new kind of development model: Divine Intervention Development (DID).

Other team factors
Our industry is also loaded with egos. That’s easy to understand. It often takes an exceptional mind to break down the complexities of the real world and model them in manageable software. Math Majors and Engineers often make great programmers. Our industry tends to collect individuals who really think about things. We call ourselves “Analysts” for good reason. And it’s also easy to see that programmers can have both a narrow approach to things and how they see the world.

The problem with this is that it can show up in the code in ways it shouldn’t. How many times have you seen a piece of code and you say “That’s brilliant”? The cool part is when you realize the brilliant code is often also dead simple.

Cleverly written code
Yet we also encounter code everyday where the programmer was just being “clever”. I have nothing against clever programming. But here’s the trick.

The code has to be “smart” and simple. If you are doing some trick in the code because of a technique you’ve seen elsewhere, stop and think about this for a moment. What kind of team do you have? If you have a lot of newbies on the team, it could be an un-smart choice.

Keep things simple. Make it obvious what you are doing. Rarely do we really write code that has to be constructed as if we were writing in “C” or Assembler. Make the flow of the algorithm obvious, perhaps even including temporary variables in intermediate steps. Don’t waste everyone’s time writing highly optimized, fast, code. Write maintainable code. Write something that can be read quickly and understood immediately.

Set the example
Training takes time. If you are an experienced developer, remember that the new coders are likely going to be browsing your code and reusing it. Often, that’s actually where some of the brittleness comes in our projects. Rather than reading the code to understand exactly why it is written the way it is, a new coder will often journey on a “cut-and-paste” raid, grabbing pieces from anywhere to make something work.

That’s okay as a first pass at a solution. But take the time to go back and revisit these situations. You probably have an excellent opportunity to refactor code and probably redesign. If behavior is being replicated in multiple places throughout your project, manifest as little repeating snippets of code, that’s a sure sign there are one or more objects missing from your design. Search for these gems and see if you can remove code by elevating the behavior to a richer object.

And don’t shy away from using First Class objects. We’re not coding in “C” here and passing around lots of strings as arguments. If you have a first class object that has powerful behavior, use it.

Strong unit tests
Another area that takes real time to develop skills, is in understanding how to write unit tests with good code coverage. What I’m looking for is a test suite that exercises the model in as many permutations as you can imagine. Yeah, that’s often tedious work. But it protects you from later damage done by someone, including you, fixing a problem without realizing it’s impact on other parts of the system. If there are combinations of inputs that can exercise a set of Boolean logic in your model, construct a “truth table” of inputs and outputs for those combinations and codify it in a unit test. Lock the behavior of your objects down.

Refactor by design
I’m making a case here for building-in a level of expected refactoring in code and design. We’re all human and our knowledge about a domain evolves over time as we learn more about it. This is often the root to some of the “change” that can be so difficult for programming teams to adopt. The team may institute a change. The customer may request a change. Accept this as a natural effect of how our knowledge grows. Changes in requirements are actually a good thing. Changes can cause you to revisit your assumptions and realize how to make a richer more flexible model. You shouldn’t be expected to be aware of all ending conditions when you start a project and neither should your customer.

Tactical and strategic responses to issues
There is one down side to rapid response that I have seen that troubles me. I know, you may be wondering how rapid response of any kind may be bad. This shows up in at least a few forms I can think of while writing this.

Don’t strictly reward quickly fixing bugs. Sure, we want bugs fixed quickly. But here’s the thing. If the development team becomes “trained” at quickly finding the errant code piece, correcting it and then shipping it, an opportunity is lost and a mistake is being made. We are rewarding the wrong behavior. Often bugs are universal. What was coded wrong somewhere was probably replicated elsewhere. Count on it. To some extent this shouldn’t actually happen. I believe the best projects are where code is never duplicated across classes. Write it in one place. Then if you find a bug you know you fixed it everywhere. Sometimes the bug was really just a change in the design. These are more subtle and difficult to find when they exist in other places in the code.

Smalltalk will help you
Smalltalk provides outstanding tools to assist you in finding similar code. Look for other implementors of the same method name. Look for similarly named methods. Look at senders of all of those methods. Learn to develop good browsing skills in your team. Reward finding similar bugs and eradicating them by reducing code first.

Also, when you find a bug, immediately begin thinking about how you can construct a unit test to demonstrate the bug exists before you even fix it. This way, after you fix it, it should never re-appear.

Software debt
If the team ignores the need to be vigilant about code refactoring, you will build “software debt”. These are places in the code where you know things are brittle, and given other conditions, will fail. Refactoring should be a natural built-in part of the development process. If you are developing in quick iterations, consider adding a short iteration where the team does nothing but refactor code.

I tend to follow the process that says, “Write it to work first, have strong unit tests to exercise it’s permutations, and then refactor before you are done.” That’s critical to refactoring. You need to have the faith that there are unit tests that will exercise the code you are refactoring. If not, you’re taking chances. Ensure the code is tested before you refactor it.

Remember what really matters
I was once part of a development team where the manager declared that the most important thing was that we deliver the software on time. There’s a nuance and perspective that I like to add to this point of view. I agree, never lose sight of who is paying the bills. After all, the first order of business must be to stay in business. You have to deliver and keep your promises. To a certain extent, that means you are obliged to only promise what you can deliver. That’s how you build trust – and not just in the software development world either. Delivering on your word is the universal technique for gaining trust.

Here’s another important consideration. Most teams are comprised of a mix of junior and senior developers working together. Obviously the skills of all will and need to grow. Software development is an expensive proposition, even when ignoring failed projects. Dollars spent, time spent, it all matters. And no one like to pay what it really costs to develop custom projects.

But if all you do is deliver a software product when you are done, you haven’t done enough. You should also be delivering a better quality development team.
The product should be finished, yes. But the team should be better as a result too.