Entries Tagged 'Uncategorized' ↓

My fellow Hillsider Robert S. Hanmer has just finished his book on fault tolerant patterns (to be available from John Wiley & Sons, October-November 2007). Here’s the book’s descritiption, in Bob’s words:

This book presents proven techniques to achieve highly available, fault tolerant software that can be implemented by software developers, software architects and small teams. The techniques are presented in the form of patterns as a resource for teaching developers and students about fault tolerance principles and also as a reference for experts seeking to select the technique appropriate for a given system.

Within the phases of fault tolerance (fault detection, error processing and fault treatment) the patterns will be organized in a way that leads from high-level abstractions to the concrete mechanisms. The collection of techniques will be programming language independent, and will be presented in a way that supports their working together to design fault tolerant software. This allows the designer to build the fault tolerant pattern language needed to solve their unique design problems.

Readers are guided from concepts and terminology, through common principles and methods to advanced techniques and practices in the development of software systems.

This book gives present proven methods of increasing the fault tolerance in a way that helps individual architects and developers. The fault tolerance domain lacks a handbook that provides well-known techniques and practices that are larger in scope than ‘defensive programming’ as many books focus on specific techniques or exclusively on reliability engineering.

I’ve been following Bob’s work and I am very happy to see it come to fruition in this form. For years seasoned programmers have been extracting techniques and insight from carrier grade software. It’s great to see a book on this topic from one of the long time members of the patterns community!

Robert Lucky’s column brings up the question of identity on the Internet. In contrasting the old identity with the new, Google/Flickr/YouTube/MySpace/FaceBook one he points out that “Now you’re at the mercy of what other people and what various computer algorithms think of you.” His example reminded me of an older post about interviewing in an era of long-lived databases. Are we seeing the emergence of the phenotropic identity?

At JAOO 2006 I gave an interview for Software Engineering Radio. Markus Voelter asked me questions about architecture evaluation, the topic of the talk I gave in the architecture quality track. Here are some of the questions that we covered:

• Why would you perform an architecture evaluation?
• When should you perform an architecture evaluation?
• What are the prerequisites for evaluating an architecture?
• How does architecture evaluation fit with agile development?

The interview is now available as a podcast; you can also download the slides from the Talks section of this site.I am surprised with the quality of the recording: the bartender was removing clean dishes from the dishwasher clese by. I don’t know how much post-processing was done but all that noise is not distracting. It was distracting while we recorded the interview so I’m glad that it doesn’t interfere with the conversation.

The slides from my talk on employing state of the art methods to validate software architectures are available (I just didn’t get to it earlier). I gave this talk at the 10th JAOO in Denmark, and then at the patterns & practices summit in Redmond, WA. Though I distilled the talk from experience with ATAM and SAAM, you may find the recommendations useful even if you’re employing other methods. If you’re not familiar with SAAM and ATAM they’re described in the SEI book.

As we wrapped up a group discussion I was reminded about the wonderful discussion of correlation and causality from Freakonomics. How do they differ? When is it one, and when is it the other? Why do people confuse them? The book illustrates eloquently the differences between them. And any mention of causality needs the obligatory reference to the Merovingian: You see there is only one constant. One universal. It is the only real truth. Causality. Action, reaction. Cause and effect.

Wojtek blog-tagged me so let’s continue this 21st century pyramid scheme. Here are 5 things you’re not likely to know about me:

• I have 8 years of classical piano training; I haven’t played the piano in a very long time though.
• When I was young and foolish I’ve done a bit of rock-climbing.
• The first framework I’ve ever extended was Digital Research’s CP/M; it came with the source code for the BDOS and a skeleton for the BIOS that provided the 8080 interrupt-driven entry points.
• My musical preferences span an unusually wide range. For example classical, ethnic, electronic, progressive rock and rock.
• I like all wheel drive station wagons and dislike motorcycles.

My turn: Greg Wdowiak, Steve Freeman, Paul Brown, Nat Pryce and Brian Foote.

I’ve just wrapped up work on a patterns article. While doing the analysis with my co-authors (an co-workers) Ade Miller and Wojtek Kozaczynski I wondered about the connection between software patterns and Metcalfe’s Law.

By the way, if you’re interested in reading about how Metcalfe came up with the ideas that ultimately led to Ethernet read Michael Hiltzik’s book; you will thank me later.

Clearly the more people know about patterns, the better you can communicate with them (since instead of waving hands you would say Decorator, Broker or Service-Oriented Decomposition). Regardless of whether the growth is quadratic or not, the value of patterns increases with the number of people who use them. Stated otherwise, patterns exhibit positive network effects.

A decade ago few people dealing with code were interested in business processes. That’s no longer the case. Due to a variety of reasons many developers discuss processes in one form or another. Some want to understand the business process that the appplication they’re building implements. Others want to grok the coordination of the services comprising their SOA. Yet others leverage workflow engines to implement the flow of pages in web applications (i.e., page flow).

A large fraction of these folks assume that processes always involve activities and their sequencing. Right? Wrong! Just because the workflow/orchetsration/coordination/etc. engine they picked to implement your process revolves around activities doesn’t mean that that’s the only way to think about a process. There are many instances when representing a process as a set of activities is unfeasible. Consider for example a web-based shoppping site: at any point you can perform one out of many activities: add something to your shopping cart; remove something from your cart; checkout; update your profile; save the cart for another visit; and so on. How would you represent somethig like this with activities?

What’s missing is the process model, something that not many newcomers are aware of. In a nutshell the process model provides the set of abstractions, relationships, and constraints that allows people to define processes. Several process models are available, each of which is suitable for a particular class of problems.

The most popular process model is activity-based. Its abstractions represent the activities performed as part of the process (or the states between these activities). This model is suitable when the process can be described through activities. It is also easy to understand because the activities resemble the elements of structural programming. However, as the web-based shopping example illustrates, sometimes it’s cumbersome to express a process as a set of activites.

Another process model uses conversations among participants as the fundamental abstraction. This model has its roots in social sciences and was pioneered by Terry Winograd (a computer scientist) and Fernando Flores (a philosopher). Together they founded Action Technologies, a company that in the mid-1980s built the first workflow system employing a conversation-based process model). Winograd and Flores describe the ideas behind their Business Interaction Model and ActionWorks in Understanding Computers and Cognition. Anyone serious about workflow ought to read their book.

A third process model uses the artifact produced as the process unfolds as its key abstraction. Though not as popular as the activity-based process model the artifact is well suited for representing processes where at any point one out of many actions are possible, such as an e-commerce Web site. The work of Richard Hull and Jianwen Su (among others) focuses on this process model. AT&T’s Vortex workflow system represents a research prototype built around the artifact-based process model.

I’m sure there are other process models, including hybrid ones that combine some of the above. Unfortunately the literature is scarce in this area. In addition, the increasing popularity of the activity-based process model (mostly because people don’t know any better) will only bury the other models even deeper.

A visit to pandora.com prompted me to revisit the topic of feature extraction. Tim Westergren’s Music Genome Project is probably one of the coolest ways of exploring feature extraction and relevance feedback:

• The feature extraction part extracts the “phenotypes” from a piece of music you like and uses those features to find similar tunes.
• The relevance feedback part uses your input (thumbs up/down) to refine the search.

So starting from “Jimmy Smith” and after a few course corrections the suggestions (e.g., Lou Donaldson’s Funky Mama) started to sound like what I was after.It’s great to see feature extraction and relevance feedback demonstrated in such an intuitive way. It’s also great to see that the Music Genome Project got it right. Others are still having problems employing these technologies right. For example, Amazon’s recommendations insist on recommending based on items that I bought but not for myself. I bet they’ll get more mileage (read sales) if their recommendation algorithms would discriminate between an item’s intended recipient and the person buying it. Are you listening?

Albert-László Barabási’s book Linked: The New Science of Networks is probably one of the books that stand out from the ones I read in 2004.The author does a marvelous job of pointing out that many hubs we know of (including social networks such as St. Paul’s) follow a power law. While reading within about DoS attacks, six degrees of separation, Pareto’s law, Google, The Faloutsos brothers, and other intersting stories, keep in mind that this work comes from a group of statistical physicists rather than computer scientists (though the references to the Bose-Einstein condensation would give that out). Good to see that they’re at it again!