Web apps have plenty of cons too. You seem to only be looking to the Pros.

There’s something in it; though the article is a little more nuanced than its title. There’s also another debate to be had around the question of what a web application really is. If thousands of lines of JavaScript are executing on the client, is it a web app? If it is running in Flash or Silverlight is it a web app? If it is running out of browser (Adobe AIR, Silverlight, JavaFX) has it crossed the border to become a desktop app? This last case is particularly interesting, since although something like AIR should probably be categorised as desktop, its programming model is normally that of a web application with an offline cache.

The semantic discussion can distract from the real issues. The ascendancy of web applications has a lot to teach software developers. The enforced simplicity, even crudeness, in the user interface of early web applications brought some surprising benefits: users generally liked the minimalist approach and ease of navigation. The page model, intended for documents, turns out to work for applications as well.

Another big lesson: users value zero-install extremely highly. The routine of go to the web page – run the app is easy to understand. Some find it easier than finding an application shortcut in the Windows Start menu, and that is after the potentially painful business of running setup.

Still, I am slipping into reiterating the advantages of web apps. What about their cons? What about the pros of desktop applications?

I still use desktop applications a great deal: Microsoft Office, Live Writer, Foobar, Visual Studio, Eclipse, all the things I listed in 10 Mac alternatives to Windows utilities. Doesn’t that prove that desktop applications are still important?

It does; but there is an important qualification. None of these are line of business applications of the type which occupy so much of the time of corporate software developers and contractors.

The real point: if there is a discussion about whether a particular project should be implemented as a desktop or web application, it is not the web application advocates who need to make their case. Rather, it is the desktop advocates who need to show the particular reasons (which may be good ones) why only a traditional local install will do.

It is also important to follow the curve on the graph. The list of things that can only be done by desktop applications gets shorter with every upgrade to the web platform – whether you think of that as HTML/AJAX, Adobe Flash, Microsoft Silverlight, or [insert your favourite web technology].

Ten years ago, a web version of Photoshop seemed an unlikely prospect. Today, here it is. Office and email is going the same way, even if it is not quite ready for all of us; Microsoft will have to accept that or lose its business.

I don’t follow Rich Internet Applications with such interest because they are cool, but because they are the future of the client – and increasingly the present as well.

Related posts:

1. Silverlight versus HTML, Flash – Microsoft defends its role
2. Who needs AIR? NY Times does desktop Silverlight app for Mac
3. How much "branded desktop presence" will you put up with?

Digitrad wants me to sign up for yes.tel, which means registering a .tel domain with its service and using it as a public home page, email address and voicemail box. It’s not clear to me what advantage it has over all the other third-parties who want to own my digital identity, except that Digitrad is smaller and therefore less threatening than Google or Facebook. I’m happy with conventional registrars.

From my perspective, Symbian managed to dominate the event with engaging images around the walls and numerous representatives to talk up its mobile platform. The Symbian story is an interesting one. Originally developed by Psion, it was spun off in 1998 into an independent company co-owned by the giants of mobile at the time: Ericsson, Nokia, Motorola and Psion itself. Nokia proceeded to acquire more and more of Symbian, achieving greater control but also – it seemed to me – reducing the chance it once had of becoming an industry standard. Other vendors became wary of depending on an operating system controlled by a competitor. Linux had greater appeal – as seen in both the Palm Pre and Google Android – while Apple did its own thing with OS X on the iPhone, and Microsoft ploughed on with Windows Mobile.

Last year Nokia responded to the pressure by announcing plans to acquire Symbian in its entirety and then to give it to a new Symbian Foundation, an open source, collaborative project along the same lines as Eclipse. Developers can sign up to get the tools for programming Symbian applications in C++, Java, Python, Ruby, Adobe Flash, C# or HTML/JavaScript. I was told that Symbian intends to be even more open than Android. It restores Symbian’s cross-industry potential though there is now more competition.

Should you develop for Symbian? The Symbian Foundation is a great move, but in the App Store era I suspect deployment issues are even more critical than the quality of the OS or its development tools. Developers will go where they can find customers. Apple is reaping the rewards of controlling the entire platform and marginalizing the mobile operators.

Still, as long as Apple is content for the iPhone to be punishingly expensive, it leaves space for others. The appeal of Symbian will depend not only on its success among device manufacturers, but also on how easy it is for users to find, purchase and install applications.

There is also the matter of reliable, fast and affordable internet access, the lack of which has so far spoilt every mobile device I have owned.

Related posts:

1. Is Apple iPhone now unstoppable in the mobile platform wars?
2. .NET Framework for Symbian
3. Qt goes mobile, gets bling, aims for broader appeal

Here is what I found interesting. First, there’s a shift towards Linux and Apple Mac in the desktops developers use for Eclipse. In 2007 it was 73.8% Windows, 20% Linux and 3.5% Mac. In 2009 it is 64% Windows, 26.9% Linux and 6.9% Mac.

This is echoed in deployment platforms too (client and server). In 2007 it was 46.5% Windows, 36.6% Linux, 1% Mac; today it is 40.5% Windows, 42.7% Linux, 3% Mac.

Those surveyed were asked what other IDEs they used. I noticed that Microsoft Visual Studio and NetBeans feature fairly strongly; I also noticed that Embarcadero’s JBuilder is hardly a blip on the chart – intriguing, given how popular this used to be in the pre-Eclipse era.

The most popular code management tool is Subversion (57.5%) followed by CVS (20%). For build tools, Ant (33.4%) and Maven (18%).

Here’s an intriguing one: I often hear that Java is only successful on the server. That presumption is not supported by this survey. 23.4% said that desktop client apps are the primary type of software they are developing, compared to 30.2% server, and 24.7% web or RIA apps.

The preferred app server is Apache Tomcat (34.8%) followed by JBoss (12.7%) and Websphere (6.9%).

The most popular database manager is MySQL (27.7%) followed by Oracle (27.3%). That’s 55% for Sun+Oracle, of course, though bear in mind that many of the MySQL users are likely attracted by its free licence.

Before drawing too many conclusions, bear in mind that it is a small sample self-selected by people willing to take the survey; apparently it was also featured by a German technology site which resulted in a larger response from German visitors.

Although it suggests a declining use of Windows – which is especially plausible given the trend towards web applications – it does not prove it beyond the Eclipse community.

And next time – how about using the same questions, which would make it possible to identify trends?

I’ve also written about Eclipse here: The Eclipse Conundrum: can it grow without hurting its contributors?

Related posts:

1. Eclipse, WebSphere winners in latest Java survey
2. Survey ranks developer tools, and reveals what developers care about most
3. Oracle breaks, then mends Eclipse with new Java build

The tools covered are Eclipse, Embarcadero’s Delphi, IBM’s Rational Suite, IntelliJ, Microsoft’s Visual Studio, NetBeans, Oracle JDeveloper and Sun Studio.

I was sorry not to see more products covered. Flex Builder Flash Builder, Zend Studio, Aptana and JBuilder would all have been interesting, for example. Each developer only scored the product they actually use (a good thing), so the sample is not as big as it first appears.

I’m also mistrustful of the survey results, particularly when you look at it in detail. For example, one of the categories is “Support for frameworks”.  Visual Studio came top, while Eclipse was last. But hang on: in Visual Studio (for example) are we talking MFC, or .NET Framework? The development experience for each is totally different. And were developers primarily judging on the framework tools, or the framework itself? It is hard to attach much meaning to the scores in this category.

Another flaw: the versions of the products is not specified. That means a weakness may have been fixed in a later version, but the survey does not tell you.

A third flaw: some tools are weak in several categories, dragging down their overall score, but that does not matter to developers who do not use them for that purpose. It is hard to compare like with like.

Still, while I’m wary of the survey overall, I though it brought out some interesting points. One is that developers were asked what features matter most to them. So:

The three things developers care about most (highest priority first):

1. Basic tools (editor/compiler/debugger)

2. Documentation

3. Tool integration

The things developers care about least (lowest priority first):

1. Support for remote development

2. Support for parallel programming (sorry Intel!)

3. App Modeling tools

What about the winners and losers in the survey? I almost forgot. IBM’s Rational Suite came top, followed by Microsoft’s Visual Studio. Eclipse came last, though it still got a decent score, well below its rival NetBeans.

The low ranking for Eclipse (which is nevertheless wildly popular) deserves some comment, particularly as the top tool, IBM Rational Suite, is built on Eclipse. I spoke to Eclipse executive director Mike Milinkovich while researching this Register piece recently. One of the points we discussed was the tension (if there is one, which he disputes) between tools vendors sharing resources to build the best possible platform, and holding resources back to retain commercial differentiation. I’ll write this up in more detail shortly; but it shows why certain areas in Eclipse may not receive the attention they deserve – localization was a specific example.

Another problem with Eclipse is that it is all a bit messy, confusing and hard to manage, particularly in a team where you want every member to have an identical setup. It is still worth it though, for the riches it provides for free.

Related posts:

1. Eclipse survey shows Windows decline
2. When will PHP Developer Tools be mainstream at Eclipse?
3. Borland keeps its developer tools after all

It does sound as if Google is not talking to Sun as much as it might. Still, let’s note that Google has good reason to omit certain classes or methods. App Engine is a distributed, shared environment; this mean that some things make no sense – for example: writing to a local file – and other things may be unacceptable, such as grabbing a large slice of CPU time for an extended period.

Salesforce.com addressed this same issue by inventing a new language, called Apex. It’s Java-like, but not Java. The company therefore avoided accusations of creating an incompatible Java, and conveniently ensured that Apex code would run only on Force.com, at least until someone attempts to clone it.

Google’s approach was to use Java, but leave a few things out. This FAQ gives an overview; and the article Will it play in App Engine lists common frameworks and libraries with notes on whether they work. Given that languages like JRuby, Groovy and Rhino work fine, it’s clear that core App Engine Java is not too badly damaged. The big omissions are JDBC (because you are meant to use the App Engine datastore, which is not relational), and Enterprisey things like JMS, EJB and JNDI. Google is nudging, or shoving, developers towards RESTful APIs along with its built-in services.

Will you be able to escape App Engine if you have a change of heart after deployment? I’d guess that porting the code will not be all that hard. Perhaps the biggest lock-in is with identity; you could roll your own I guess, but Google intends you to use Google accounts and supplies a Java API. Microsoft is ahead of Google here since it does support federated identity, if you can get your head round it: you can authenticate users in the Microsoft cloud against your own directory using Geneva. The best Google can offer is Directory Sync; though even that is some protection from identity lock-in.

Java support on App Engine is actually a vote of confidence in Java; if what is good for Java is good for Sun, then Sun is a winner here. That said, just where is the benefit for Sun if companies host Java applications, built with Eclipse, on Google’s platform? Not much that I can see.

Related posts:

1. JavaFX – just for Java guys?
2. Apple not Android is killing client-side Java – so why is Oracle suing Google?
3. Salesforce.com, Apex and Web 2.0 vendor lock-in

The answer was not good, because I now had an error:

Warning: session_start(): Cannot send session cookie – headers already sent

I puzzled over this for some time. The error was in line 0 of my login page. I couldn’t see anything that was different from before, except the static image that meant nothing to PHP.

Eventually I worked it out. Eclipse (running on Windows) created the PHP files using ANSI. On saving, Expression Web silently changed them to UTF-8. That in itself was no bad thing – it’s usually a better choice – though I reckon it should ask. The bigger problem was that Expression also added a BOM (byte order mark) to the beginning of the file. This is actually optional for UTF-8, and most non-Windows editors do not add it. It happens to flummox PHP, which interprets them who-knows-how and sends some output to the browser, preventing session_start from working.

This is particularly painful to debug since most editors do not display the BOM; they simply use it to confirm the character set in use. So you can have file A which works, and file B which does not, and they are character-by-character identical.

One way to see and remove the BOM is to open it with Edit.com, which does not understand it at all:

I guess both Expression and PHP could do better here. The bit that puzzles me is that I can’t be the first to run into this. Doesn’t Microsoft know that its UTF-8 BOM breaks PHP files, at least on the two versions I tried (XAMPP on Windows and PHP 5.2.1 on Linux)? I can’t even see a preference in Expression that would prevent it being written. And if you remove it, and then re-edit in Expression, it carefully writes it back. Unlike Adobe’s Dreamweaver, which leaves well alone.

PS if you want to know all about BOMs, see here.

Update: See comments – apparently this was fixed in Expression Web 2.0. Tina Clarke discusses the problem here.

Related posts:

1. Microsoft to support PHP in Expression Web 2.0
2. Microsoft Expression Blend is too hard to learn
3. Expression Blend 2.5 problems with Silverlight 2.0 Beta 2

I installed it this morning, and so far it does not impress. There is zero documentation (just a few links to the standard Flex docs on Adobe’s site), and it lacks even MXML Intellisense, let alone a visual designer. When you go to project properties, there is nothing to configure. The toolbox is also empty. On the plus side, it successfully invoked the Flex compiler to build the project, and managed to open it as a static file in Internet Explorer when I clicked Debug. I’d prefer an option to use Visual Studio’s built-in web server for debugging. There must be more to it than this; then again it is advertised as a beta which is meant to mean well advanced (ha ha). I suggest sticking firmly with Flex Builder for the time being.

Adobe has largely ignored .NET in its Flex and AIR technology, though it does support SOAP. I am not sure whether this is caused by aversion to Microsoft, or an assumption that Microsoft developers will use Microsoft technologies like Silverlight or Windows Forms, or a bit of both. Integration with Visual Studio and server-side .NET could be significant for Flex adoption, though it would be better if Adobe itself were doing the add-in.

You can see the same thing happening on Microsoft’s side, with a half-hearted Silverlight project for Eclipse (which only works on Windows), or the well-regarded Teamprise which integrates Eclipse with Visual Studio Team System. In both cases Microsoft keeps itself at arms length, which does not have the same impact as in-house support.

There are always concerns about the quality of third-party applications. I am sure Adobe itself would not have put such an inadequate preview up for download, as Ensemble has done for Tofino.

Related posts:

1. Amethyst from SapphireSteel: Develop Flex in Visual Studio, an alternative to Tofino
2. Develop for Adobe Flash/Flex in Amethyst for Visual Studio
3. Microsoft Silverlight vs Adobe Flex

… given the level of community participation, the appropriate course for ALF is to close down the project. Unfortunately, our recent efforts did not identify potential contributors willing to justify keeping the project active.

says project lead Brian Carroll. The project aimed to enable interoperability between ALM (Application Lifecycle Management) tools from different vendors. Here’s the problem statement from the project page:

Application development today is achieved through the use of numerous tools from software vendors, open source communities and some are even home grown. Getting these tools to work together is an integration problem that has never been solved. Each vendor and open source project creates their own API standards and many hours of effort are required to create even the most straightforward of integrations.

The problem is real, so why the lack of participation? Of the major ALM vendors, only Serena gave it serious backing. The project could not succeed without either IBM, or a solid alliance of IBM’s competitors.

My interpretation: those ALM vendors will have considered whether it was really in their interests to help customers integrate their tools with those from rivals. Good for customers, yes, but vendors want to keep you hooked on their product suites. “Buy more from us, it integrates with what you have already” is a great sales point. Since only the participation of those vendors could make ALF work, the project was doomed.

It is another manifestation of what Salesforce.com CEO Marc Benioff calls “an aspect of our industry”.

Everyone loves standards, right?

Related posts:

1. Erich Gamma on Eclipse and Jazz
2. When will PHP Developer Tools be mainstream at Eclipse?
3. Eclipse survey shows Windows decline

I’m getting this pain because I want to use PDT 2.0 and Eclipse3.4, instead of the older PDT 1.0.3 which has an all-in-one download based on Eclipse 3.3. “All-in-one” means that you download a bundle which includes both Eclipse and PDT, and treat it as a separate standalone IDE. The question though: why wasn’t the PDT properly integrated with Ganymede, which brings together multiple Eclipse projects with the promise that they will all work together?

I looked in the Eclipse PDT newsgroup and found some discussion on the subject. Apparently the PDT team felt it was just too difficult to manage the dependencies. More depressing is that apparently the team feels the same way about Galileo, the follow-up to Ganymede expected in June 2009. It means that the PDT stays outside the mainstream of Eclipse projects, reducing its visibility.

Conspiracy theorists might surmise that major PDT contributors like Zend, which has its own commercial IDE called Zend Studio which uses both Eclipse and PDT, might enjoy keeping the free version low-profile. That (or some other reason) might also explain why Zend Studio uses a 1.x version of PDT along with Eclipse 3.4, which is not meant to work. It turns out that Zend Studio uses PDT 1.0.5, whereas the latest public download (unless you go directly to the source) is 1.0.3. If 1.05 works fine with Eclipse 3.4, why isn’t the public all-in-one based on this combination?

I like the PDT, and my patched together Ganymede + PDT 2.x works very well. Debugging seems more stable since I updated it. Personally I’d like to see PDT get more prominence within the Eclipse community, and for it to be packaged as part of Galileo rather than being left on the sidelines.

Related posts:

1. PHP Development Tools 2.0 released, joins official Eclipse “Galileo” release
2. Survey ranks developer tools, and reveals what developers care about most
3. Silverlight 2.0 is released, Eclipse tools for Silverlight announced

Underpinning all this, though, is an attempt to escape the “baroque” 3.x codebase for something that’s simple, clean and modular. That means eliminating repetition in code and interdependencies found in the monolithic 3.x.

“It’s getting to the point where it’s difficult to reach in and fix a bug without impacting lots of other things,” one e4 committer told EclipseCon.

Now, Eclipse is a child of the refactoring era. It is built using an MVC (Model-View-Controller), component-based, plug-in architecture. Design patterns guru Erich Gamma worked on Eclipse and on its Java Development Tools.

If Eclipse is now a ball of spaghetti, what went wrong? Though its possible the problems are being over-stated in an effort to justify version 4.

Technorati tags: eclipse, erich gamma, mvc, java, refactoring

Related posts:

1. Erich Gamma on Eclipse and Jazz
2. QCon London
3. Is Eclipse adoption peaking?