Bring It On

I want to make a rich web application. Ajax is out of question (too many horror stories). I want to choose 1 platform and stick with it. Requirements are:

1. Widespread install base (I guess Silverlight's already out!)
2. RAD. Need to write an app from inception fast.
3. Has a lot of third-party/free code available on the net.

BTW I'm a C++ Win32 developer, and I would definitely prefer Silverlight *if* it had a higher install base.

I'M ESPECIALLY LOOKING FOR INSIGHTS ON PEOPLE WHO HAVE FIRST HAND EXPERIENCE IMPLEMENTING ONE OR MORE OF THE AFOREMENTIONED TECHNOLOGIES. Yea, I just yelled.

This is a great question for several reasons: the poster tells you why one of the technologies (AJAX) is not on the list (even if you disagree with the reason). He tells you about the criteria for choosing the platform. He gives you his background. Finally, he preempts any “evangelist” comments – do give advice if you’ve used one or more of the technologies above.

Unfortunately, the poster is in a “cheap, fast, good: pick two” situation. None of the technologies listed will satisfy all or even most of his requirements.

I was a C++ Win32 developer, just like him. I have used Java (for applets) and WPF (a bit of Silverlight). I only know what I’ve read about Flash. Here are my 2 euro cents…

Silverlight in its deployed version 1.0 (no CLR) is, for his needs, useless, regardless of the adoption. What he would most likely want is Silverlight 2.0 (CLR included), but that’s months away and then there’s the question of adoption and tools. Personally, I don’t think adoption is what he should be worried about, but that’s another story. Tools (RAD) should be fine for him as most will be integrated in Visual Studio where he should feel right at home. Third-party code will be scarce.

Flash has a great install base (anecdotally, around 90%). Tools appear to be very RAD. I don’t think there’s much third-party/free code available on the net as Flash is not so much about code. Mainly, as far as I can tell, the problem with Flash is the host language. It’s some kind of JavaScript mutant called ActionScript. It appears to be faster than JavaScript in the latest incarnation of Flash, but it’s still a script language. Him being an ex-C++ developer, I don’t see him using a script language and being productive with it. But that really is the only problem with the Flash.

Java has a widespread install base, but you never know which version users have installed. I’ve seen point releases of Java breaking applications and that is to me one of the biggest problems with Java. RAD is questionable (depends on your definition of RAD), but on the other hand if the applet is graphics intensive, he’ll be able to trivially transfer all the GDI/GDI+ knowledge accumulated over the years. There is a lot of third-party and even more free code on the net, so much that it might be a problem to pick which library to use, not to find if there’s one to suit his needs.

All in all, it’s tough for Win32 desktop developers trying to build RIA. Java feels great as a language (if you have C++ experience), but there are deployment issues and RAD aspect. Silverlight looks even better, but it’s not ready. Flash uses awkward script language. Let’s not forget that unlike Java which still uses rather traditional GUI concepts, both Flash and Silverlight are fully vector-enabled and use substantially different GUI concepts and this takes time getting used to.

My recommendation? If possible, wait for Silverlight. If not, go with Java.

This is probably old news to veteran Java developers using Eclipse, but to me it’s new. Eclipse is an IDE (mainly) for Java development, written in Java. Thus you need Java runtime to run Eclipse itself plus the Java compiler to compile your code. Usually you’d just install the JDK and be done with it.

Or at least that’s what I thought… Even if you install just the runtime (JRE), Eclipse will compile your projects! This is somewhat strange because writing compilers is hard and IDE developers do not need yet another problem to solve. On the other hand, most modern IDEs offer code completion and refactoring plus a lot of helpers that warn you about code issues on the fly, while you are typing. To do that, the IDE needs a compiler, but not the “regular” one because this compiler needs to work in the presence of “errors”, that is unfinished code (you are still typing it).

Thus, it is not too strange that Eclipse has internal compiler, but it’s great that it is not just used for advanced editing but also for producing a final executable.

Besides from missing the new/official name for the Visual Studio “Orcas” (it’s 2008 apparently, but might not ship in 2008) I completely missed one interesting low-key announcement from Microsoft: there will be a new product coming with the 2008 release called “Visual Studio Shell”.

It’s easy to explain what this is: it’s a GUI shell part of the regular Visual Studio, but the contents are up to you. Differently put, it’s a foundation for you to build your own tools based on the Visual Studio GUI platform. Doesn’t this sound familiar? Doesn’t Eclipse RCP offer similar set of functionality?

Yes and no. Visual Studio Shell is meant to be used for the development of IDE for custom tools and programming languages. In one of the deployment scenarios, your components will integrate into full Visual Studio (if installed on the target machine). In another, the shell and your content are installed as a standalone application. In both cases, the IDE is optimized for languages and tools but not for any kind of GUI application.

This is an important point. While some developers enamoured by their IDE might think it’s a good idea to build an end-user application that looks exactly the same as their IDE, end-users disagree. For most applications, zillions of dockable windows only add to the UI overload and confusion. I’ve been there and done that: only the most complex enterprise applications need this level of customizability. Look at mass product like Microsoft Office 2003 – it has task pane that looks like dockable pane, but there’s always at most one open (you can switch to different views inside the task pane though).

Eclipse RCP on the other hand advertises itself as a generic GUI tool. Unfortunately, I see this leading to the development of RCP based end-user apps by overzealous developers. This is not a big downside of the Eclipse RCP platform as such, I just think that it should be advertised for what it is – a tool that rose from the IDE meant for the creation of IDEs and tools. In fact, when you look at the list of available commercial RCP applications, you’ll notice that most of them are tools for engineers. It’s a good thing developers are applying common sense to this issue.

In any case, there are two platforms now for developers to base their tools on, both are free and well established. This is great news for those looking to build custom tools that are not really IDE plug-ins: not only do they get a basic GUI for free, but they don’t have to “force” their end-users to have the “full” IDE installed (in case of Visual Studio, this means that you don’t have to have a commercial version installed which saves money).

We are progressively getting more and more spoiled by the features of a modern IDE . Each new version brings better intellisense, code generation and sometimes even mind reading (that's what it looks like, anyway) features. It’s hard to imagine how could we have ever worked without an IDE.

The feature I’d like to comment on today is background compilation. Jeff complained how C# should have offered it, just like VB.NET does. Ian chimed in asking if IDE could refrain itself from constantly compiling his VB.NET code and do what C# compiler does – wait for user’s explicit action. These are two opposite approaches – is there a better one that could satisfy both sides?

Maybe. Just like VB.NET, Java code in Eclipse is checked all the time, as you type. But the compilation only happens when you save the file. You do get red squiggly lines while you’re typing obviously incomplete statements, but the IDE goes out of your way and even helps you whenever it can. Post-save automatic compilation actually works great and is quite hard to shake off – I miss it all the time when I switch to C# in Visual Studio 2005.

Ideally, this could be a global IDE setting, or per-language one. If you want background compilation (it suites your coding style) turn it on, otherwise don’t. Ian has a point here: it probably has more to do with the way you code than with anything else, background compilation itself is inherently neither good nor bad.

This particular rant was caused by a post that doesn’t really go in the direction I’m about to, but is interesting read nevertheless (check out the comments!): Agile and Test-Driven: A Marriage Made In Hell?

I want to touch a topic concerning single acronym in this post: YAGNI, or You Ain’t Gonna Need It.

In general, I agree that YAGNI is a solid concept. Don’t build too much, especially if you’re going to throw it away later. Makes sense. Less work is better. Less code means less bugs and less time spent for no benefit. Leaves you more time to work on things that a customer wants now. Goodness, right?

Not always. If some of us are crazy for building code even though a customer did not request it (so we’re doing exactly the opposite of what’s recommended) there is a method in our madness. Why exactly are developers building more than necessary?

Sometimes it’s because customer’s behavior is actually not so unpredictable. Customers are not technical people (most of the time). They can’t think in abstract terms. So what they tell you and what they really mean are most often a variations of one and the same thing – a “hardcoded” version they give you, and a more flexible, a bit more generalized version they are vaguely aware of, but can’t express in abstract terms so you can translate it literally to code.

So you detect this situation. You don’t say anything, but you code more generalized version of what customer wants. A few weeks/months later, the customer realizes that his initial idea was too narrow in scope and wants something better/more complicated/more general.

Now, if you followed YAGNI, the chances are that the architecture of the app as is at that moment simply does not support that scenario. If you want to incorporate changes the customer is insisting on, you’d need to refactor large portions of your code. All your unit tests go down the drain, as you’re not testing the same thing any more. You end up writing lots of code with a risk of breaking big chunks of previously written code, plus you have to write a ton of unit tests again.

Contrast this to the “developer premonition” approach above. You have already incorporated the general idea, your tests reflect that so all you need to do now is to expose a GUI item or two and call the right method. You’re done. Besides from not jeopardizing the existing code, you look cool in the eyes of customer because you adapt to change so fast.

This is oversimplification of course, but once you observe the above scenario in the wild, if repeated enough, you’ll start adapting to it and ignore YAGNI. The real issue here, just like with YAGNI, is to know when to stop.

I think it’s precisely because of this – developer’s inability to stop themselves from generalizing too much – that YAGNI was introduced. When in doubt, YAGNI.

But it’s hard to fight the real-world experience. Use your own judgment and most of all, adapt to the customer.

Scott Hanselman has recently discussed the ways that an application can auto-update itself.

He’s only discussing the nice side of the auto-update, assuming that the app will behave correctly and predictably. Here’s my take: if you can’t implement this functionality right, don’t even try, you’ll only annoy your users.

Examples of auto-update done right:

• Reflector, besides from being an all-around cool tool, updates seamlessly and with the lest fuss
• Eclipse, even though it consists of a million plug-ins and sub-platforms and whatnot
• Paint.net, including auto-update to and from a beta version
• Windows Live Messenger, notifies you, downloads and installs, simple and effective
• Firefox, downloads the update in the background, just restart and that’s it

Examples of auto-update done bad:

• Samsung PC Studio, where the update consists of the individual downloads of each and every DLL and EXE (I kid you not), judging by the look of the progress bar uncompressed; takes a lot of time on my 15Mb connection, but at least it works
• Nero 7 Premium, confusing UI, mindless questions, does not work and it’s not obvious why; looking from the Process Explorer it does establish the HTTP connection(s) to the French mirrors (OK, at least it got right that I live in France) but then nothing happens and it declares “download problems” – “very” informative

If it takes more trouble and nerves to use the auto-update, please don’t bother. Just link to the Web page with the info on the latest version and I’ll download it myself, thank you very much.

I had to do this again today because of my hard drive crash, so I’ll document it here in case I have to do it again in the future.

Due to the relatively poor integration of GUI tools for Subversion (I consider them a leaky abstraction) with the command line version, I only use the command line for most of the actions. Still, I can’t stand the diff output generated by subversion.

It’s not hard to plug in a different diff tool like SourceGear’s Vault Diff and Merge into subversion. Here are the steps:

• create a batch file called diff.cmd and put it somewhere in your path; the contents of this file should be a single line: <path_to_vault_directory>\sgdm.exe %6 %7
• go to %AppData%\Subversion folder and open config file (it has no extension) in notepad (or suitable replacement); then search for diff-cmd = … and replace right hand side with diff.cmd
• enjoy!

With a title similar to the one of this post, Tim Bray was sure to attract attention. In fact, I am surprised that his post did not cause a larger scale flame war. Short story: PHP, Ruby and Java frameworks are compared. Ruby wins, sort of.

While I think his analysis is quite reasonable, there was one thing that is just plain stupid ignorant. At one point, Tim comments on the exclusion of Python and .NET based frameworks from the comparison:

.NET and the Python frameworks, starting with Django, are notable by their absence here. Sorry; I just don’t have any first-hand knowledge on them. And .NET isn’t open-source, so why would you use it?

Huh? OK, you don’t have experience with these frameworks, fair enough. But to avoid .NET just because it’s not open source? Here’s one reason why you might consider .NET: it works. It has tool support as good as Java. In fact, it largely looks and feels like Java, except that (in my opinion) it has better framework (overall, not Web framework in particular). Thus, in a comparison like Tim did, .NET would probably fare roughly that same as Java.

I have worked with many open source and closed source applications/libraries in my career. I’ll take closed source library that works well over half-baked open source teenager’s-weekend-project-eighty-percent-finished any day. Open source does help when things don’t work (you can “step into” in the debugger) but as long as things work, you’re good.

Open source does not imply quality. Closed source does not imply quality too. Don’t use it as a criteria for picking the library/framework to use.

As expected, if you don’t add extra code, drawing things that move on the applet surface will result in flickering. It’s ugly, it hurts eyes and it just looks unprofessional.

The remedy is simple and works with all technologies and platforms – draw to the off-screen buffer and then just slap the whole buffer to the screen in one go. This is very easy to implement in Java since you can get a Graphics class out of the Image (that represents your off-screen buffer) and then when you draw to this Graphics everything is drawn to the  Image.

Except that the flickering is still there. Just like with Windows API applications, the problem is that there is an “erase background” step. In Windows API the culprit is WM_ERASEBACKGROUND message, in Java it’s the update method of the Applet class. Override update method and only call your paint method – it’s that simple.

By the way, don’t forget to recreate the off-screen buffer when the applet’s size changes. Most of the applets are fixed size, but some could be detached from the browser and then they might become resizable.

Those fortunate to remember the 1999 and the nice part of the .com boom (insane salaries, expensive conferences, state of the art offices and hardware, luxurious hotels etc) probably also remember the state of the tools of the most hyped language of the time – Java.

Java was undoubtedly darling of the .com boom, as much as anything Web related. However, the tools support was relatively poor and IDEs were usable, but nothing to write home about. At the time, I was happily developing Windows MFC applications in C++ and looking from the Visual C++ (version 6 at the time) IDE standpoint, Java IDEs looked crude.

Years passed. In the meantime partly because of inability to “embrace and extend” Java, Microsoft came up with the .NET. Visual Studio continued to evolve and I switched to C#. Java IDEs evolved too, I just wasn’t aware of how much.

Then in early 2004, Maksa, a friend of mine and at the time long-time Java developer sent me an email that goes something like this

Hey, have you seen Resharper? It almost brings Visual Studio up to a par with Eclipse. Go check it out!

Almost? I couldn’t believe it. From my point of view, still heavily influenced by the memories of cruddy IDEs of the ‘90s, Java IDE could never be as good as Visual Studio.

However, I have recently used Eclipse quite a lot and I can finally see what Maksa meant. At the time of his email, Visual Studio (2003) was nowhere near Eclipse as an IDE (for the respective “primary” languages, Java and C#). Version 2005 of Visual Studio improved a lot, but Eclipse is still generally better – only when you install Resharper or a similar add-in you’ll get the same kind of experience.

Not all is great with Eclipse though. I still don’t get their idea of “project” and the perspectives don’t always switch back and forth the way I would expect them too, but on average as a Java IDE (and a free one too!) it is really good.