Despite his rants against C++, Stevey’s Drunken Blog Rants, is one of my favorite new blogs. Actually, since it hasn’t been updated in about nine months, and was written mostly in 2004, it’s not really new. It was rediscovered by social bookmarking sites (I found it on reddit.com). I was reminded of it while thinking about resuscitating this site.

There are a lot of great articles, but this one about server-side service software is one of my favorites (given that I’ve spent a lot of time thinking about the subject). Another great article on this topic is Paul Graham’s The Other Road Ahead.

The old .NET SAPs is rechristened under the name: Western Mass .NET Users Group  (and a spiffy new website). Tomorrow’s meeting topic is XML.

Speaking of XML, I saw this recently: Don’t Invent XML Languages by Tim Bray. In addition to pointing to this great list of XML Languages, he introduces “The Big Five” XML Languages and where they should be used.

Suppose you’ve got an application where a markup language would be handy, and you’re wisely resisting the temptation to build your own. What are you going to do, then?

The smartest thing to do would be to find a way to use one of the perfectly good markup languages that have been designed and debugged and have validators and authoring software and parsers and generators and all that other good stuff. Here’s a radical idea: don’t even think of making your own language until you’re sure that you can’t do the job using one of the Big Five: XHTML, DocBook, ODF, UBL, and Atom.

I was talking to a developer friend today about developers who don’t get the importance of communication. Look through any want-ads for developers and right after the alphabet soup of technologies you have to know is the same requirement—must have “excellent written and verbal communication skills”. You’d be hard pressed to find a programmer job without those requirements.

But, expressing yourself clearly is only half of communication. The more important aspect is listening to and understanding other people. This is what separates good and great developers. And the most important skill in understanding is empathy—not only understanding someone, but being able to be them.

To be a successful developer, you have to learn more than just the software aspect of your business. Developers who understand this are more valuable and valued more. If you want to do this effectively, you have to think like a saleperson, a marketer, a CEO, your customers, the press, etc. You have to think like them because they aren’t all going to try to think like you (but if they’re going to try, by all means, help them).

Another part of empathy is thinking about how they will interpret your words. For instance, avoid rhetorical tics like “think about it” and “you’re not seeing the big picture”. Not only are they annoying, but it puts people on the defensive.

If you understand—not only what someone is saying, but why—you’ll have a much better chance of expressing yourself. So, the next time you have a communication gap with a non-developer, stop talking and ask yourself how much you even understand about them.

I’ve written a couple of add-ins for CityDesk, and of course, it’s tempting to think about trying to make some money off of them. I’m already a partner in another add-ins business (Spheresoft, which makes MS Office addins — check out Highlighter if you view realtime data in Excel), so I know a little about what goes into the development, support, marketing, sales, licensing, etc. of doing this kind of thing.

Add-ins are a great business for small companies, because they are much easier to implement than a full-blown product and the software you are adding on to will help with marketing. Another add-in that Spheresoft will be publishing soon, changes the nature of spreadsheet modeling, but we’d never want to compete with Excel on thousands of other tiny features, so it makes more sense for this to be an add-in.

But, with any business, you have to decide how much effort you are willing to put in and what you are expecting back. The market of people who have Office is huge and I have a reasonable expectation of making a good enough return on Office add-ins to warrant the time spent writing and supporting them.

I’m not sure I can do the same for add-ins for Fogcreek products. I’m glad that people find them useful, and I do them because I need them as well. I would never make enough money to recoup support costs I would have to undertake if I charged for them.

So, they will remain free and pretty much unsupported for now.

This article on Domain Specific Languages from Martin Fowler got me thinking on code generation in general. A project I’m working on right now has many opportunities for generating code—not from a domain specific language, but from the requirements documentation and other source information.

I am working on a project now with a very detailed requirements document. For instance, practically all of the strings shown to the user are in there. Since the project uses string resources, there’s no reason to manually copy and paste—the string resource is easily generated from the document.

The project also has a lot of images.  And images are associated with each other (some images are the small version of another, or meant to be the same object but from another angle). Luckily, the artist used a directory and naming convention that makes these associations easy to figure out, and generate an XML resource descriptor and object building code from.

Tying together this information (each image has a string descriptor) is also easy, given the detail in the document and the naming convention.

Actual logical code generation is almost possible as well, as the project is a kind of complicated finite state machine. In this case the document doesn’t go far enough to be a source. A Domain Specific Language might help here, and leaves me with source that might be able to be maintained more easily that a Java representation.

This brings up a good lesson for those writing requirements, even if you don’t know how to program. If you follow conventions closely, it might be a good starting point for generating code.

I’ve been playing around with the Furl Beta. It’s looking pretty good. Essentially, it’s a personal online cache of web pages that you can view, search, and share. Better than bookmarking because you can search the contents of it later, and it’s accessible from any browser. You can even provide RSS feeds to your Furl content.  Collaborative research on the internet just got a whole lot easier.

One drawback, there does not appear to be any way to make the cache private, so I can’t possibly use it, because there is no way I want a public database of every site I find interesting or useful. I definitely would share some of it with some people, but totally public is not an option.

Perhaps there will be a pay service for a private space.

Update: My bad. Just mark the item private when you Furl it.  Duh.  Didn’t see that on the Furl dialog and still don’t see how to make a public item private (except to change its topic to personal, but then I lose the utility of topics). Anyway, now the biggest drawback is that the first dialog comes up at the wrong size and there is no scrollbar, so you can’t see the buttons.

Any program that accepts user input will need to separate good input from bad, and to make sure little of the latter gets recorded.

So begins the CHECKS Pattern Language of Informational Integrity by Ward Cunningham. I read this article years ago and loved it—mostly because it jibed with my experience for writing usable business software. The theme of the language is to make sure that data entered by the user is correct, and accomplishes this with various kinds of validation and data representation techniques.

I find that two of the patterns are invaluable for usable user interfaces—Echo Back and Visible Implication. The section they appear in starts with:

A person reaches through a program’s interface to manipulate the domain model. Although the interface is itself a program (an interface model and graphical machinery), its purpose is to enable the direct manipulation of the domain model as transparently as possible. The user interface is programmed to create the illusion of control in the mind of the user. To this end it must provide sufficient clues of the model’s state so that sensible operation is the norm.

These ideas are so important to the usability of software and so difficult to implement in HTML based software, because there is little domain knowledge accessible from the client side. For instance, Echo Back requires that a field, once entered, is transformed into a domain object and injected into the model. It is then read back from the model and displayed as understood by the model. Visible Implication further requires that any cascading consequences are also displayed. This kind of interface is the norm in the Fat Client or Client-Server world, and mostly absent in the web-based software world. As a consequence, it is harder for users to enter data.

We’ve all had the experience of filling out a huge form on a web page and submitting it, only to be told that we’ve made a mistake and have to go back. That’s Deferred Validation used in isolation of the other patterns, and was never considered a good UI decision until the web made it commonplace. And yes, I know that you can get part of the way there with javascript, but only simple validations are possible. Imagine correcting a pay date in a maintainable and configurable way as described in the example for Echo Back.

I appreciate the revolution that the web has brought us, but something better is needed for software with high usability or productivity requirements (as opposed to high learnability or deployability requirements). Philip Brittan describes an architecture we worked on that can recapture the connection between UI code and the domain model, while still maintaining the benefits of web based software.

If you want to add the results of Database queries to HTML files before they are published (and keep them as static pages), you can use my new utility, HTML DBScript. It will work on any HTML, but is designed to fit well with CityDesk’s “Before Copy” publishing location feature.

It’s in Beta right now, but well tested and has decent error reporting. Let me know if you have any comments by using the Contact Page.

Update: v1.0 is released. FogCreek is featuring a link to it on their CityDesk News Page.