Nokia places Qt under LGPL License – Sweet!

I have been a big fan of the Trolltech Qt Framework for a number of years. It is a fantastic way to build high quality cross-platform desktop applications in C++. For the past six years it seems like every project I work on has included a rich desktop GUI application of some sort. Each time this need would arise I would start the process of selling the idea of using the Qt Framework for the project. The biggest hurdle was always the per-developer cost for the commercial license of the framework. I would hear things like

Just use MFC. It’s free and we don’t really see a need for the application to be cross-platform anyway.

or sometimes I would hear

Use the GPL version of Qt and just keep it under the radar until we are sure the application will be released to our customers.

It was always frustrating to try and make the case that Qt was a better solution than MFC for UI, was more comprehensive for general development than other frameworks, and that it was worth planning for the possiblity of releasing the applications for Linux or Mac as well as Windows. In the end each project did adopt the Qt Framework, but it really was a distraction to try and justify the use.

Thankfully with the purchase of Trolltech by Nokia we are seeing a change in the licensing terms for the Qt Framework. Starting with the 4.5 release it looks like the framework will be placed under the LGPL license making it much easier to adopt as part of commercial development efforts.

Here are a couple links that discuss the development further:

and you can read the news directly from Nokia on the Qt Licensing Terms page.

This new development on the licensing front and the recent inclusion of WebKit into the Qt Framework make me very optimistic about a long and prosperous future for developers who know the Qt Framework! Thank you Nokia!

Software Design: Want vs. Need

I am always surprised at how short-sighted some folks are who design software. It seems like there is no shortage of people who feel that you just have to listen to your customers to build great software. In my experience, if all you do is build what the customer says he/she wants then your software will likely be obsolete in a year (maybe even less time) and your customers will ultimately be very unhappy with you.

To build great software you have to listen intently to what the customer is saying so you can identify the pain and suffering that usually lies unexpressed just below the surface of comments like “All I need is a widget that does X.”

Check out what BusinessWeek magazine had to say about this phenomenon:

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”
— BusinessWeek, May 25 1998

Probably my favorite quote about building great software came from someone on the team that built the NeXT computer. I think they really understood what it takes to build quality systems (software and hardware) that last.

“It took us three years to build the NeXT computer. If we’d given customers what they said they wanted, we’d have built a computer they’d have been happy with a year after we spoke to them – not something they’d want now.”
— Someone on the NeXT Team

It all comes down to making a decision to apply your knowledge and understanding of technology to address the immediate problems for the customer and to push beyond so you can give the customer a system they can grow with. The ultimate measure of success is when a user says “Hey, now I need to do Y with the widget.” and you can reply with something like “Okay, this is how you do that with the system we built.” If you find yourself replying with something more like “Hmmm, we could add that to the software but it will cost you.” then you are doing it wrong!

Setting up Unit Testing in Xcode 3.1

Xcode includes OCUnit, so you don’t need to get a copy. But, you might want to take a look at their website (http://sente.epfl.ch/software/ocunit/) for information and tutorials on how OCUnit is intended to be used.

If you are planning on doing Test Driven Development (TDD) you may also want to get the following packages:

Other good articles on Xcode Unit Testing that I came across:

By reading through the documents references above I was able to get OCUnit up and running for one of my projects. It took a bit of experimentation, but in the end it looks like OCUnit will work just fine for doing TDD in Xcode with Objective-C. Anyone wanting to try out TDD should give it a try. The benefits for your project are significant. Go for it!

Building Team Cohesion Quickly

When forming a new team to build that Killer Web App ™ it is very important that the team work as a cohesive unit. Much has been written about how to build a collective team spirit and I won’t rehash that here. Sufice to say, if you don’t have a cohesive team you probably won’t be able to execute on your grand ideas and the project will eventually fail.

Today on TechCrunch there was a terrific article that details how one group of like-minded individuals came together to build a web application in a few days for a meer $10,000. Check it out.

Microsoft Professional Developers Conference 2008 – See you there?

logo-flat.png

The last time I attended the Microsoft Professional Developer Conference was back in 2001, shortly after the attacks of September 11th, 2001. Just over 6000 people made the trip to Los Angeles to learn about the latest technologies from Microsoft, as they were in the midst of rolling out the .NET Framework. They were pushing Hailstorm (I still have the free book they gave everyone with the Hailstorm API in it. I never did get a chance to use it though.). Everyone was excited about building new web services using .NET and C#.

A lot has changed since then. Vista and Windows Server 2008 are here, the .NET Framework has gone through three major revisions, Visual Studio has seen major improvements supporting team development, Intel has delivered multi-core processors and Microsoft still hasn’t delivered on the promise that was Hailstorm.

The preliminary agenda for PDC 2008 has some interesting sessions listed. Topics I am hoping to learn more about this year include:

  • Silverlight
  • Visual Studio 10
  • Windows 7
  • Multi-core Programming Techniques

Even though Bill Gates is now officially retired it looks like he is scheduled to speak at the conference as well. For a geeky college dropout with a whiny voice he does a great job delivering keynotes to developers. He doesn’t have the stage presence of a Steve Jobs, but he isn’t running Apple either. I look forward to hearing what his message for Microsoft developers is this year.

The dates for the conference are October 26 – 30, and the event is being held at the Los Angeles Convention Center once again. I hope to see you there.

Simple UI Refinements Increase Developer Productivity

Recently I have been thinking a lot about what it takes to create a good user interface versus one that just gets the job done. Whole books are available about UI design, but I think most developers steer clear of them, adopting a Git-R-Done attitude instead.

Most developers that do UI work know how to use the various widgets, can follow the general patterns that can be observed in other platform applications (i.e. copy the UI “feel”), and have a vague sense of how to lay out the elements of a dialog box. What we all seem to forget is that the field of human interaction is separate from programming, and that there really is something to it.

A very good example of how subtle changes in a UI can make all the difference can be found in Visual Studio and Xcode; the development environments for Windows and Mac OS X. In both tools a dialog is provided for manipulating the compiler and linker settings that control how the project is build.

Visual Studio 2005 – nice set of property pages that can be navigated by a tree on the left. The problem is, you have to already know where all the properties live (under which tab) in order to quickly navigate to the properties you want to change. Take a look at the screenshot to see what I’m talking about.

vc2005_properties_thumb.png

Apple took a similar but subtly different approach on their project properties dialog box. They list all properties by default, grouping them by category. The developer can scroll up/down through the complete list to browse all of the properties. The search box at the top of the dialog provides a more powerful user interface than the tree control in Visual Studio. This one little addition makes all the difference in the world for a busy developer.

Xcode Project Properties_thumb.png

Here we see how this simple addition can increase the productivity of a developer. By simply letting the developer type a free-form string that describes part of the property he/she wishes to change the list of properties is narrowed to display only those that are a match. In the screenshot below you can see how this makes it very easy to get at the preprocessor definitions to make a quick change. In Visual Studio the developer is expected to remember which category the property appears in, remember the name of the category, and then navigate to that tab before he/she can make the change.

Xcode Project Properties (Narrowed)_thumb.png

This is just one small example of how similar user interfaces can be very different when actually used. Both provide a way to manage the properties of a project, but only Xcode provides solid UI features that support the day-to-day use cases for a busy developer.

So, it should be clear that spending time on UI design can pay off. Your users may not recognize the amount of effort that was put into the UI, but they will appreciate the increased productivity that a well though out UI provides.

How to enable MSI Logging

If you are trying to debug an installer problem it is probably worth having MSI logging turned on. This will produce a file in your %TEMP% directory that contains a detailed trace of the activities that took place in MSIEXEC. This can be very helpful when an install or uninstall fails without any clear indication as to why it failed.

Log files are stored in the directory pointed to by the TEMP environment variable. The filename format is MSIxxxx.LOG, where xxxx is replaced with a random string. A new log file is created for each invocation of MSIEXEC.

To enable logging through group policy, do the following:

  • Start / Run… / gpedit.msc
  • Drill down into Local Computer Policy / Computer Configuration / Administrative Templates / Windows Components / Windows Installer / Logging
  • Enable logging with the setting “voicewarmup”. These are the command-line arguments that MSIEXEC will use.

These links contain more information on setting up logging: