…requires more than just good programming.

Tag Archives: mac

I prefer static websites to a CMS for simple product websites because:

Static websites are fast.

I have more low-level control over the HTML/CSS.

I don’t have to worry about the very-real threat of a CMS being hacked.

Obviously writing every page separately in raw HTML/CSS would go against one of the cardinal rules of development, Don’t Repeat Yourself. But you can avoid this using a static website generator such as Hammer for Mac.

Hammer uses a simple syntax embedded in HTML comments to ‘compile’ a website from source files. I have now used Hammer to create several static HTML/CSS websites, including my perfecttableplan.com and hyperplan.com websites.

I like the simple syntax of Hammer. For example:

I can put the HTML for a page header in an _header.html file and then each page just needs to start with:

If Hammer can’t make sense of a source file (e.g. it can’t find the image file), it generates a compilation error.

Because everything is text based I can easily manage all the source in a version control system. Also, if I have to move away from Hammer, it should be relatively straightforward to change the syntax to another static generator (or even write a replacement for Hammer!).

Overall I like Hammer. But it does have a number of shortcomings:

1. The user interface is very limited. Hammer shows you a list of source files and you can click on a source file to see the compiled version or edit the source. But the source files are listed in the order they were edited and you can’t filter or sort the list. This seems such a simple and basic feature, that I can’t understand why the developers have omitted it.

2. Hammer takes a dumb, brute force approach to compilation. If you change any file in a source folder, it recompiles *everything*, without checking if other source files include that file. This is a pain if you have 100+ source files. Surely it wouldn’t be that hard to work out which files depend on which and only recompile the files that need recompiling?

I am organizing a regular meetup in Swindon (UK) for people who are running (or are interested in running) their own bootstrapped (i.e. not VC funded) software product business. Come along and talk shop with other aspiring and experienced bootstrappers. It doesn’t matter if you are developing for web, Windows, Mac or mobile.

I have written previously about signing Qt applications for Mac OS X. It all worked fine until I upgraded to Mac OS X 10.9.5, which broke my signing script. Those Apple chaps do love to break stuff. Grrr.

The problem appears to be that the directory structure of the app bundle has changed and the Qt4 macdeployqt command does not conform to the new layout (I believe this is also the case for Qt5). Oh joy. I managed to work out how to get it working again after a bit of digging around. The good news is that Apple have also made the codesign command easier with a --deep option to traverse and sign the whole bundle in a single command. About time.

So here is the basic process to build and sign your Qt .app on the latest versions of Mac OS X:

(Sorry about the small font, but I wanted to avoid confusing line wraps).

I then invoke DropDmg to create a .dmg image file complete with licence and background image. This is all stuck it all in a bash script, which I can pretty much forget about it (until Apple break something else).

In the above rebundle.py is a Python script written by some public spirited individual that can be downloaded from github (thank you, ‘kingcheez’). Note that you can just find and replace all the ‘5’ characters in the script by ‘4’ if you are still using Qt4.

The first time I ran my script I ended up with a whopping 50MB .app file. It turns out that the cp -r commands in my script don’t preserve symbolic links. So you end up with 3 copies of each framework library. You can avoid this by using cp -R instead.

On the subject of signing for Mac, Apple recently sent out an email stating:

Signatures created with OS X Mountain Lion 10.8.5 or earlier (v1 signatures) will be obsoleted and Gatekeeper will no longer recognize them. Users may receive a Gatekeeper warning and will need to exempt your app to continue using it. To ensure your apps will run without warning on updated versions of OS X, they must be signed on OS X Mavericks 10.9 or later (v2 signatures). … Apps signed with v2 signatures will work on older versions of OS X.

So you are going to have to start signing using 10.9, whether you like it or not.

I released my new product Keyword Funnel today. It is a tool to help Adwords advertisers improve the profitability of their Adwords campaigns.

I have found the best way to get a decent volume of affordable conversions from Google Adwords is to use a ‘long tail’ strategy. For my Perfect Table Plan product there are a few ‘head’ keyword phrases that have high search volumes, such as “table plan” and “seating arrangement”. But these aren’t very well targeted (“table plan” might have been typed in by someone who wants drawing plans to make their own dining room table). Also lots of other people are bidding on these head phrases, pushing the bid prices up. This combination of poor targeting and high click prices makes it hard to make a profit on head keywords.

So I prefer to concentrate on ‘tail’ terms such as “table plan software mac” and “wedding seating arrangements program”. These are much better targeted, so convert a lot better. The clicks are also cheaper because less people are bidding on them. However the search volumes are much lower, so you need a lot of these tail terms to get a reasonable amount of traffic. At least hundreds, and preferably thousands. Hence ‘long tail’.

The good news is that you can mine lots of different sources of data for these long tail keywords. For example you can extract keywords from your web logs, Google Analytics and Google Webmaster Tools accounts. Even though many searches are now listed with the keywords ‘not provided’ by Google, it still isn’t hard to come up with thousands of candidate keyword phrases. The bad news is that they aren’t in a usable form. Before you can import them into Adwords you need to:

Sort out duplicate phrases, foreign characters, capitalization and other noise.

Remove unwanted and negative keywords.

Group keyword phrases into tightly focussed adgroups.

Put the results in a form Adwords understands.

I tried to use Excel for this. But, marvellous tool though it is, it really wasn’t up to the job. So I wrote my own tool. This worked very well, but it wasn’t a commercial quality product. So I started again, from scratch 6 months ago. Keyword Funnel is the result.

Keyword Funnel allows you to add hundreds of keywords to new or existing Adwords campaigns in minutes, rather than hours. This makes long tail Adwords campaigns with hundreds or thousands of keywords a much more realistic proposition. It also allows you to set up new campaigns in a fraction of the time.

Keyword Funnel is available for Windows and Mac. It is priced at a one-time fee of just $49 (up to 2 Adwords accounts) or $99 (unlimited Adwords accounts). You can download a free trial from the website and it comes with a 60-day money back guarantee. The website is currently a little unpolished, but the software is well tested and robust. Any feedback is welcome.

I prefer to build Qt from source. I have been trying to build Qt 4.8.5 on Mac OS X 10.9 (Mavericks). I managed in the end, but it took a few tweaks. Online information about how to do this was fragmentary, so I am documenting it here in case it is useful to someone else.

1. Webkit doesn’t build. I don’t need it so I disabled it using configure option:

It’s rare that I chat to other software developers without someone asking me when I am going to do a web version of my seating planner software. Because the market for desktop is dead, right? SAAS apps is where all the action is!

I think the web is a great platform for some products, not so much for others. Let’s look at the advantages of web apps over desktop apps.

Web advantage 1: No installation

You can access a web app from any device that has a browser. No need to install. There is no doubt this is a major convenience. However most desktop utilities can be downloaded and installed in 1-2 minutes with a decent broadband connection. Also you don’t have to keep logging in to most desktop apps, once they are installed.

Web advantage 2: No upgrades

End-users are always using the latest version. This is definitely an advantage for technical support. But it does take away some choice from the user. Perhaps they weren’t ready to upgrade or preferred the old version?

Web advantage 3: Better user insights

You can analyse how users are using your software. This allows you to improve usability and send out tailored lifecycle emails. It is possible to gather similar information for desktop software, but it involves a lot of extra work.

Web advantage 4: Distributed architecture

If you are writing web apps, you get a distributed architecture for free. No need to do socket programming.

Web advantage 5: Less piracy

Cracks and keygens are a fact of life for desktop software vendors. It is easier to protect against piracy with a web app.

Web advantage 6: Cross platform

In theory web apps are cross-platform. Write them once and they can run on any device with a browser. But browser compatibility issues mean it isn’t that easy in practice, especially if you are still forced to support the dreaded IE6. Also there are solutions (such as Qt) that allow you to deploy to multiple desktop devices from a single code base.

Web advantage 7: Subscriptions

Web apps lend themselves to subscription based payment. This is great because you get a more predictable monthly income and potentially get more money from each customer over the lifetime of the product.

So what about the advantages of desktop apps over web apps?

Desktop advantage 1: Responsiveness

Native apps are more responsive than web apps, partly due to lower level access to the machine and partly due to not having to talk to a remote server. However this advantage is eroding as bandwidth and JavaScript performance improves and more work is carried out by the client in web apps (e.g. using Ajax).

Desktop advantage 2: Reduced hosting costs

The costs of hosting a website for a desktop app is minimal. Typically you just need to serve a few pages and a download file to each visitor. They then won’t need to come back until there is an upgrade. But hosting costs can be significant for a web app, particularly if the app requires large amounts of bandwidth or compute power.

Desktop advantage 3: Better access to hardware

Desktop apps can make better use of the hardware available. For example, you can generally do printing a lot better from a desktop app.

Desktop advantage 4: Better development tools

The old joke is that JavaScript is to Java as the Taj Mahal curry restaurant is to the Taj Mahal. As a C++ developer I am used to working with a fully fledged IDE, debugger, profiler, static analyser and runtime coverage analyser. I tried some JavaScript development recently. Ugh. The development tools seemed very primitive and JavaScript is a language so hideous that surely even it’s mother couldn’t love it. No classes, no strong typing, no templates and broken scoping. However frameworks such as jQuery have made JavaScript much more accessible over recent years.

Desktop advantage 5: Psychological

Many people feel that anything web-based should be free. Psychologically customers seem more ready to pay for desktop software. Perhaps they feel a greater sense of ownership. This perception is gradually changing for B2B, but I think it is still prevalent for B2C.

Desktop advantage 6: Privacy

Many customers don’t feel confident storing important and confidential information on third-party servers.

Desktop advantage 7: Availability

You can’t use a web app unless the server is up and you have an Internet connection. A desktop app installed on your local machine is always available. You can continue to use it, even if the vendor goes out of business.

Desktop advantage 8: Up-front payment

Desktop apps lend themselves to a single, up-front payment. This is great because you get all the money straight away, improving your cash flow.

So I have come up with similar number of advantages for web apps and for desktop apps. Which is better? It depends, of course. For my particular application, I think a desktop app still has significant advantages:

My software can render and zoom in and out of large floor plans better than my web based competitors.

I use a genetic algorithm to assign guests to seats. It makes more sense to use under-utilised desktop CPUs for this, rather than me having to pay for a beefy compute server. The thought of writing a genetic algorithm in JavaScript is too awful to contemplate (although Atwood’s law dictates that someone will, if they haven’t already).

I can do printing better than my web-based competitors.

Most of my web-based competitors seem very feature-poor. I am sure that is at least partly due to poor tooling for web development compared to desktop development.

Most of my web-based competitors give their product away for free in the hope of making some money back on ads. I charge for mine.

Seating plans can contain sensitive information, particularly for events with celebrities, royalty and heads of state. Some of my customers don’t want this information transmitted to and stored on third-party servers.

If my server goes down then I lose sales. But my customers can continue to use my software. Imagine if they were dependent on my server and it went down (or I went out of business) the day before their big event. It brings me out in a cold sweat to think about it.

But other products are a better fit for the web. If I was writing a collaborative CRUD app, I would almost certainly do it as a web app. I have recently been working on a couple of new products. One is a web app and the other is a desktop app. Horses for courses.

A lot of the money I have spent on software over the last few years has been for desktop software. When I had to choose bookkeeping software, I chose a desktop package because I didn’t want to:

The line between desktop and web apps is also becoming more blurred. Many desktop apps now use web protocols and embed web browsers. For example, the Qt toolkit allows you to easily create applications that are hybrids of desktop and web. It is also possible to sell a web app that companies host on their own servers. This adds some of the advantages and disadvantages of a desktop app compared to a web app installed on the vendor’s server (SAAS). Perhaps desktop and web apps will converge to the point where there the whole desktop vs web debate becomes meaningless.

So I think reports of the death of desktop software have been greatly exaggerated. There is no doubt that long-term trends ( e.g. increasing bandwidth and attitude to paying for web apps, for B2B at least) have been changing the balance in favour of web apps for some types of product. Particular those where collaboration is more important than graphics or computer power. But I think there will continue to be plenty of markets where a desktop app is a better choice than a web app for the foreseeable future. In the final analysis, customers care a lot more about how well your software solves their problem, than how it happens to be deployed (if they even understand the difference).

Mac OS X 10.9 (Mavericks) was released yesterday. And those nice people at Apple made it free, so you can be sure lots of people are downloading it. However Qt 4 apps look at bit strange on the new OS. Look at the text alignment in these buttons:

The text isn’t centre aligned. It doesn’t look like much of an issue out of context. But it looks wrong when you look at a whole UI. The good news is that there is a simple fix:

You need to place this code in your main() before creating your QApplication. For more details see this bug report.

With the fix the buttons look like this:

Much better! There are some console warnings:

CoreText performance note: Client called CTFontCreateWithName() using
name "Lucida Grande" and got font with PostScript name "LucidaGrande".
For best performance, only use PostScript names when calling this API.

I am not sure how how significant these are.

I have also found that updating to Qt 4.8.5 fixes a printing crash bug in my table plan software. This crash happened when rotated pixmaps were printed from Mac OS X 10.8.

I have seen on forums that Qt 5 is completely broken on 10.9. But I don’t know if that is true.