Scriptionary Blog

Neil McAllister of InfoWorld recently made his case against web-based applications. He gives five reasons for companies not to use web based technologies.

Having developed for both platforms (desktop and web) professionally, I can say with all certainty that Neil McAllister is wrong in his assertions.

Web applications try to mimic the realtime behavior of desktop applications, there’s no doubt about it. But the one thing that’s to think about is: Would a desktop application scale in the 21^th century?

What I mean by this is: Would I be able to use my desktop application on Mac, Linux and Windows at the same time? With the exception of Java apps, the answer is a resounding “no”.

Desktop applications don’t do so well when they have to be ported to multiple platforms since they have to be recompiled on the targeted platform. In addition, if you have offices overseas or people working from their homes, thick clients don’t make sense.

I think when Neil was halfway through his post, he must have doubted his writing since the article mentions using “consistent UI Toolkits” like the Win32 API, Cocoa etc. Now, anyone who’s worked with desktop applications knows that UI design for the desktop is moving heavily towards an XML/style based approach, influenced by the web (WPF, etc.).

All of the APIs mentioned are not cross platform compatible so a cross platform abstraction layer has to be put in place with all its limitations for the application to be able to run. If you’ve read the last two paragraphs, you’ve probably already figured out that creating an application that would scale on the same amount of platforms as a web application would be extremely costly and time consuming.

As for cross browser compatibility, it’s not that big of a deal as it was in the early years. All of the quirks that cross browser development brings are known to (proficient) web designers and developers and are taken into consideration when designing a User Interface.

As for online access by employees, invest in an internet filter with the money you save going from desktop development to web development and you’re all set. But really, if your employees access porn websites at work, there’s something really wrong with your hiring process and the motivation levels at your company.

Good luck trying to get these damn interweb kids off your lawn.

While I’m not an expert on law or anything, the last ten years have seen a steady decline in technology jobs in the western world and I would like to share my opinion as someone who (luckily) still is part of the existing workforce.

When I finished high school, like many others I had to choose a major for college. This wasn’t a hard decision for me since I was always involved with computers and programming. So I decided I was going to major in ICT (Information and Communication Technologies).

There were many jobs available in that field during that time (around 2000), so this field seemed very lucrative to me. But then the dot-com bubble burst and from then on till now jobs have been disappearing steadily.

Many of these jobs have gone overseas due to outsourcing and this is, in my opinion like everything else on this blog, the biggest problem the western tech market is facing. So, how can these jobs be brought back to the western world? Here’s my two cents:

1. Tax companies that outsource labor.
Enforce an outsourcing tax that would bring the cost of overseas labor to a similar level as the cost of hiring workers from the same country. This will make it less lucrative for companies to hire an outsourcing provider.

2. Prohibit personal information from leaving the originating country.
Personal information should not be viewable by countries other than the originating country. This will allow western call- and data-centers to be reestablished and provides more safety to the people who’s personal information is being shared.

Besides from bringing jobs back to the countries involved, this will give a higher quality of service as we all know how much quality work has come from outsourcing. Finally, the drive for innovation will be greater as people will understand that their technologies will be used by their peers instead of competitors.

All in all, this is my personal stab at the topic and might be a bit too “risque” for some and I apologize in advance if you feel I have offended you.

*cough*grow a pair*cough*

Edit: FYI, by Hungarian notation, I mean Systems Hungarian such as bIsSucky.

It seems I’m in some kind of pickle. For some reason, two of the programmers at the company I work for still use Hungarian notation.

In case you don’t know what that is, in short: Hungarian notation prefixes an abbreviation of either the data type or purpose of the variable to its name. For example, Microsoft’s WINAPI still uses it, hence we have things such as hInstance, nShow, szCompany, etc. So it’s quite ugly and confusing to the programmer.

Yet these two programmers still cling to their old ways and refuse to give up on this ancient method. Even in VB.NET. One of these programmers happens to be Joe the Programmer mentioned before, go figure.

I was asked by one of them “Why not use Hungarian notation?” In case you dind’t know, dear reader, the name of the variable should give away the data type, use UpperCamelCase and logic for your naming conventions. Turns out, UpperCamelCase is a programming convention in this company, so why we were arguing, I don’t know. Now if only logic were a convention, we’d be set.

But it was like pissing against the wind as neither them nor I were persuaded in the end. How would you persuade a person to switch to a different methodology? By them using Hungarian notation, people who will eventually take over their source code will want to shoot themselves.