Of late I seem to find myself ranting about the return of desktop applications. It certainly wasn’t intentional. Maybe I’m just bored of building applications for such a mess of a medium known as the web. In any case I’m excited about desktop applications which seems so 1980’s of me.

Moving applications to the web browser certainly fixed some things, however, it broke a bunch as well. First, let’s dispense with the notion of the web browser being web-based and traditional client applications being non-web-based. Upon closer inspection it seems that web browsers themselves exhibit most, or all, of the attributes of a traditional application. My point is, every trad application can access and do things ‘in the cloud’ so they’re web based.

A good example is the trad application I’m using to write this very entry. Drivel is a Gnome client “for working with online journals”. I no longer write web posts in a web browser. I was sick of losing posts by accidentally closing a browser, not being able to write or edit while offline like being on a plane among other annoyances. I now enjoy the rich features of a trad application, save posts locally etc, as well as being able to post directly ‘to the cloud’. As well, I use drivel to post to multiple blog applications which gives me a consistent writing experience regardless of the blog software I choose to run the blog on.

Further complicating this issue is that two giants are on either side of this. Microsoft owns the desktop, google owns the ‘cloud’. My 2 cents is that google will do everything they can to get you and your applications on the web as they don’t own your OS. The more you take off your desktop and put entirely on the cloud then the more of you they have.

Mozilla’s prism is now trying to help you “split web applications out of their browser and run them directly on their desktop”. I’m only getting more confused. Mozilla claims that the problem with trad apps versus web apps fixed was that they had slow installation, a verbose update process, and they didn’t have ‘data in the cloud’.

We’re already mentioned that the ‘data in the cloud’ no longer differentiates. So that leaves us with install and update. I believe I’m biased in that I’m an ubuntu user and therefore have access to synaptic. That means I’ve installed virtually every application by typing one line in bash or using the synaptic client. Once an application is installed I forget about it for the most part and synaptic handles all updates for me.

“Synaptic maintains a database of packages on your system in order to keep track of installed software. This list is checked against the software repositories to inform you of new packages or updates. Synaptic checks for new software packages when you launch Synaptic.”

This means I no longer suffer from a cumbersome install or update process for trad apps. Should we not just take the synaptic path and fix the real problem, making trad apps dirt simple to install and keep up to date? Cripes, I’m starting to feel old..

Caveat, I’ve never built and distributed a multi-os python application. I was asked recently if a python application would naturally be multi-os. Here’s my modified for public consumption answer.

It depends. Until I’ve done it, I don’t know. I believe it’s relatively painless to do it though. Python itself comes ‘out of the box’ with every major OS except windows so that’s a good start. As well, if you build your client application using dabo which is built on top of wxPython which is built on top of wxWidgets then you’re in great shape. Not to mention your apps look native to all Os’s which is handy.

“Dabo applications are known to run on all flavors of Windows, all recent flavors of Linux, and Macintosh OS X 10.2 or higher. Because Dabo is currently built on top of *wxPython*, which is built on top of wxWidgets, it probably runs elsewhere, too. It also suffers from the same display limitations on some platforms (most notably OS X), but these should improve as the underlying toolkits improve.

You can develop Dabo applications on all three supported platforms, and you can run your Dabo applications on all three supported platforms. Flexibility is a really good thing.”

There’s also pyGTK which promises your applications will be “truly multiplatform and they’re able to run, unmodified, on Linux, Windows, MacOS X and other platforms.” I believe that choosing between pyGTK and wxWidgets starts to get into questions of mobile device delivery etc. In terms of major OS’s I think you’re covered completely with either.

I’d concur with Joel that the Business of Software conference, organized by Neil Davidson from Red Gate, was the best conference I attended last year. I’m not much for conferences so it was also the only real conference I attended so that’s not saying much. I’d go so far as to say it was the best software conference I’ve attended to date.

They are running it again this year and apparently Joel’s taking over. It’ll be in Boston in fall 2008 and I’m planning to hit it up. If you are interested in attending, and know me personally, then contact me as Neil’s graciously offering a reduced rate to people who attended last year. I’m curious to see what natural disaster they have planned for us this year.

Some examples poached directly from Mark Hurst of business success that has come directly from creating a good experience:

• Amazon
• Apple Store
• SAS
• This one’s cool and would be judged ‘insane’ by most business standards, Holidays and Whole Foods
• Zappos.com

An example of how Mark Hurst has pulled off something similar? They had a small outage with their gootodo application last year, small meaning a few hours I believe. Their response was to email their user base offering a 6 months credit to any user who was interrupted by this outage.

It’s a sad fact that I spent most of my “holidays” rewriting the blueTurbine client in python which is my first real experience with the language. Python is described as a “high-level language“:

“In a high-level language, complex elements can be broken up into simpler, though still fairly complex, elements for which the language provides abstractions, keeping programmers from having to ‘reinvent the wheel.’ For this reason, code which needs to run particularly quickly and efficiently may be written in a lower-level language, even if a higher-level language would make the coding easier.”

I have to agree with the above in that I find it significantly simpler to develop complex concepts into python code as compared to any other language I’ve used. The catch, however, is the “though still fairly complex” part. Being able to translate complex concepts into simpler code does NOT mean it’s simpler to work with complex concepts.

If you happen to be struggling with complex software concepts, or have yet to be exposed to them, then don’t expect python to teach them to you. If anything it’s the exact opposite in that it puts the burden squarely on the developer to completely understand those complex concepts in the first place. Python allows you to code them with less code which means they’re more subtle and less explicit.

That’s amazing for developers who already grasp those concepts. They can be more productive both in reading and writing code. If you’re trying to learn them, however, then I’m not sure how that helps. If anything you may want to spend more time wading through more verbose (less simple) code first? Wow that sounds backwards…

Having said that Bruce Eckel makes a great point about using python as a learning language so what do I know? He doesn’t, however, speak to the idea of learning complex concepts by working on codebases where they exist which is more what I’m speaking to.

“Python would make an even better first language to teach programming. It’s such a gentle learning curve. You can start with scripts, and of course some people dismiss Python as a scripting language, because you can script with it. You start teaching scripts. You can teach functions. Then later you can add classes. Then you can go onto things like metaclasses. Python has many more of these powerful constructs that you can learn when you’re ready. And I think that’s very impressive, because it doesn’t say you should only be an object-oriented programmer.”

Is it just me or is Paul describing coworking?

“If companies want hackers to be productive, they should look at what they do at home. At home, hackers can arrange things themselves so they can get the most done. And when they work at home, hackers don’t work in noisy, open spaces; they work in rooms with doors. They work in cosy, neighborhoody places with people around and somewhere to walk when they need to mull something over, instead of in glass boxes set in acres of parking lots. They have a sofa they can take a nap on when they feel tired, instead of sitting in a coma at their desk, pretending to work. There’s no crew of people with vacuum cleaners that roars through every evening during the prime hacking hours. There are no meetings or, God forbid, corporate retreats or team-building exercises. And when you look at what they’re doing on that computer, you’ll find it reinforces what I said earlier about tools. They may have to use Java and Windows at work, but at home, where they can choose for themselves, you’re more likely to find them using Perl and Linux.”

Success is all about the measuring stick. Let’s peek at the success rates YCombinator has experienced with a few different measuring sticks.

1. Success as a business, got stupid rich: 50% although Paul indicates 25% is likely more reasonable over the long term
2. Everyone got paid, no one lost their shirts: 100%. Even the initial projects that didn’t continue as a business were able to somehow make enough money to pay back investors and then some.
3. Enjoyment and growth: 100%, “Whatever our long-term success rate ends up being, I think the rate of people who wish they’d gotten a regular job will stay close to 0%.”

It’s easy to peek in from the outside and read about a business failing and think ‘wow, they screwed that up, poor losers’. As always there’s more to it then you read in the papers.

Quote from Why to Not Not Start a Startup.

Just an interesting quote…full Paul Graham post here..

“When you decide what infrastructure to use for a project, you’re not just making a technical decision. You’re also making a social decision, and this may be the more important of the two…when you choose a language, you’re also choosing a community. The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.”

Rick Chapman spoke about software as a service(saas) at The Business of Software.

A lot of his examples, meant to convince the crowd that saas was the way software was moving, were based on flawed products. He listed a ton of poorly designed software products. My thought was he did little to nothing to sell saas. For me, crappy software as a service is still just crappy software. Altering delivering, deployment, etc isn’t going to make your crappy software better.

Ricardo Covo came out to DemoCampGuelph3 and demo’d one of the facebook applications he’s built called Network Trotters.

The interesting part for me is that he’s building facebook applications in .NET. Personally I have zero interest in actually using facebook apps. I am, however, curious about facebook applications from a development perspective so I’d love to see Ricardo come out again sometime and show some code. As well, what are the dirty details involved in building and deploying these applications?

If you missed DemoCampGuelph3, sign up for the google group and join us next time.