Been looking around WinFX and specifically XAML recently. Not sure I think writing XML is a great way to write a GUI (but billions of web pages clearly prove me wrong). My first impression is that one of the benefits is going to be automated creation of XAML — not from tools, but from our own programs.

It’s been 10 years since HTML was a household word and I still feel like it’s easier to hand write it than use a WYSIWYG tool. I also never really liked using dialog editors. Even good ones like Delphi have too many limitations, especially when it comes to layout. So, I’m not expecting much from the tool support for XAML. But since it’s just a text format, it should be pretty easy to generate from a simpler format (or from models). I’m looking forward to playing around with that idea.

Here are some links I’ve collected on giving presentations. I have been revisiting them lately in preparation for my talk next month.

• Kathy Sierra, in her Creating Passionate Users blog, thinks that we shouldn’t have slides. She also has this crash course on learning theory (with pictures and a workbook). 
• Seth Godin has a free-book called Really Bad PowerPoint. First tip: “No more than six words on a slide. EVER”
• Guy Kawasaki has the 10/20/30 rule of PowerPoint.
• The Beyond Bullets blog has great tips.
• The Zen master of presentations, Steve Jobs, vs. Bill Gates.

C++ (and Cocoa) unit testing is built into XCode on OSX. I am writing an application right now that I plan to port to Windows. When I wanted to see how portable my code was, I decided to get all of the unit tests passed on Windows.

Unfortunately, XCode does not use CppUnit, which is already portable. Here is some code I wrote that you can use to run your XCode generated unit tests on Windows.

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.