XHTML is a Programming Language

XHTML is a Programming Language

When a developer is working on the front end of a website. They need to be afforded the same deference and respect as a developer working on Java, ColdFusion, or PHP. The reason is simple. In order to create a website correctly, one needs to be able to focus on the project at hand. Much of the difficulty companies face when trying to meet deadlines is that they treat their web developers like artists. Web development is not like art. They are different jobs, and while someone may have both skills, shifting gears between the two is difficult to say the least. That is not to say that artists can't build websites, but the skills required to take a design and translate it into a format that will work on the internet, and remain consistent across browsers and platforms without using Flash are different than the skills that allowed the artist to design the look and feel. Web Developers need to work in a location that affords them privacy. When co-workers need something from their web developer, they need to respect that the developer may need to continue working on what they are doing and that to disturb them could cause them to lose their place.

Employers should recognize that web design and web development are different. Web design is done in Illustrator and Photoshop, not in Dreamweaver or in a text editor. The people that you hire to assemble your website, should not be the same individuals that design it. Likewise, the individuals that you hire to design your website should not be the same people who make it work. Some people have overlap in their abilities, but most true designers hate to deal with the underlying code. Most developers hate to be bothered with the look and feel in more than a rudamentary sense. Why is this? If you hire an accountant to work on your taxes, you probably wouldn't have that same accountant represent your business in court to defend your use of the corporate jet to fly your family to Barbados for the weekend, right? Accountants have a different skill set than even tax lawyers. In a more extreme example, you wouldn't try to get your doctor to fix your car, would you?

Most designers can get a website together, just like most developers can cobble together an interface. But what I am talking about is being proficient at it. I am quite fond of my designs, but I do not believe they are of award-winning breakthrough interface quality. Some of my code may be, but then again I am a developer. I pride myself on writing error free code. This is probably why I am so caught up with making my sites conform to XHTML 1.0 Strict. Most browsers can display 1.0 Transitional just fine. Its a point of pride for me to get there.

Furthermore, businesses should realize, as many of the more progressive ones do, that object oriented procedures should not be limited to programming exclusively. The reason developers have switched to object oriented programming is because they can reuse parts of their code that they know to be reliable, and can use different parts of their code to perform new operations in a different program.

Are human resources any different? Most workers have a variety of skills in addition to the skill they were hired for. Many tasks that customers require of the modern business can use these skills. Why not have a project manager, like the main class in a Java application handle calling and selecting the classes it needs to perform a particular job, and release those resources when they are finished with them to perform a different job.

Perhaps John there has experience with SOAP objects even though he was hired to build web pages, maybe Mary the project manager knows this and has a job where the client needs to use SOAP objects. So Mary will put John on her team, as long as there is no other higher priority. Tying this business model back to web development, you have a stable of web developers and designers who share the skills required to create an entire website in different quantities. Perhaps you need to develop a site where the look and feel is more important than the back end so you would pull resources that had more design skill than development skill. If the job is for an intranet where the functions and features are more important, then you pull more resources who lean toward development and fewer that lean toward design. It is up to the project manager to know this about the people they work with, and the model described above will be the model that takes enterprise web development into the future creating reusable, reliable components and interfaces.

Dual Core – Twice as Strong?

Dual Core – Twice as Strong?

Why the sudden push toward parallel processing? Many in the industry would have computer users believe that two processors are better than one. Apple has been using dual CPUs for quite some time, and the dual G5s are the fastest Apples around. Does that make them faster than single CPU machines?

The crux of the issue is the software. The first problem with using a dual CPU system is that the software has to be written to utilize both CPUs to their maximum efficiency. Though some developers have been coding using threads, the majority of them have not. Largely because many programs will never need dual-cpus. Microsoft Word is a good example. On either the Mac or PC platform there is no reason for Word to ever use both CPUs. Perhaps they could offload the find and replace to another thread, which would allow the Operating System to send that operation off to another processor, but the thread would almost never operate simultaneously with any other process you would want to run in Word making opening another thread kind of pointless. If you were doing a find and replace, it would be unlikely that you would be typing anything while that operation was taking place. Most of the software we all use is a lot like Word. So which computer would run Word faster? One that had two 2.5 GHz processors, or one that had a 3.76 GHz processor? The one that has the 3.76 GHz processor of course! This is why PCs tend to be faster than Macintoshes at most operations. Most think this ends the debate permanently as to the faster platform, however it does not. There are many processes that can take advantage of dual-processors. Even the 3.76 GHz processor running Word has a limit, and that limit is the individual operating the computer. People can only type so fast.

So what software do we have that could use two processors? Many 3D rendering software packages have the ability to use dual-processors during heavy rendering tasks. Photoshop has the ability to split the workload of many filtering tasks in half and use both processors.

These are very minor tasks to put to multiple CPU systems. With many 64-Bit, dual-core, dual-processor designs about to hit the market, the uses for multiple processors will begin to unfurl. Accurate voice recognition, 3D holographic rendering, and alternative systems for input such as holographic humanoid computer representatives will begin to become possible with more parallel processing power. Still, even with massively powerful multi-processor systems, serial processing will still need to be carried out at speeds more rapid than we can achieve today. The problems that face modern processor designers are the issues that have always plagued them to a lesser degree. Power, Heat, and physical space. Many wouldn't accept a processor that was the size of a magazine, and the resulting motherboard would be huge, so each leap forward in compression of die sizes creates more issues of power dissipation and heat generation.

Intel's newest breed of processors generate so much heat that they have to be throttled between keystrokes to keep them in their proper operating range. Even if they could get a processor to operate reliably at 4 GHz or above, how would the other components in the PC handle the heat generated, and the power drawn. Modern video cards for example create almost as much heat as the CPUs. Both together can overheat the hard-drives, which now spin at between 7200 RPMs, and 15000 RPMs. Overheated hard-drives would have much shorter lives, and would potentially lose data on writes, or corrupt data on reads. Not to mention the penalty paid when overheating RAM chips in a system. All of this is much more difficult to manage on a PC where a chip designer is uncertain of what could be in the computer that will use the processor, or the cooling measures taken to keep the computer in a safe thermal operating zone.

These are the difficulties facing modern CPUs in the computer. There is no real solution at the moment, so the conclusion most processor manufacturers have come to is that having multiple processors will sell more computers without having to increase CPU speeds. Not that CPU speeds are everything, a dual-processor can perform some activities faster than a single-CPU system. However, most of the operations that most users perform won't benefit much from the second CPU. Intel's Hyper-Threading technology, when it first came out, actually made the system perform more slowly than its single threaded counterpart at the same clock speed. The difference in performance was due to the overhead imposed on the system by Windows in managing the threads that the program creates.

The bottom line, does it make sense to buy a dual-processor or dual-core system rather than buy a single-processor or single-core one? The answer in my opinion is no. Unless you can get the dual at the same cost or cheaper than the single, the single is the better deal if it has a higher clock speed. Going with multi-core, or multi-CPU systems only prolongs the inevitable, we will have to beat the limits imposed upon us by electricity, as well as thermal stress in order to really push computing to the next level. Still, as it is there are not many applications that require a system to fully use both of its processors. Even the mighty Pro-Tools only uses a single processor. Most of this is hype. The majority of users would still get excellent performance from a 2 GHz processor with a decent video card. Only the extreme high end will really get the benefit of having two processors in a computer. It has yet to be seen if, especially Intel, AMD, and IBM / Apple can really convince users to buy a processor that is slower than the one they have but is dual-cored. I am looking forward to seeing how they spin benchmarks to show how much better the performance of dual-core systems are.

So what about 64-Bit CPUs? Eventually 64-bit CPUs will make a difference, but at the moment the only applications that might really gain from having 64-bit capability are large scale server applications that require as much memory as they can use, and high end games that can use a wider path through the processor to enhance performance. Heavy duty 3D applications could use the power of 64 bits. Microsoft Outlook and Internet Explorer can't really use a full 64-bit processor. Maybe their interface could, but their core functionality can't. Again, it probably isn't worth it to buy a 64-bit system that costs more than an equally capable 32-bit system at this time. It will take at least another year, and some innovative thinking about how people interact with the computer to really push 64-bit processors to their limits. All of these “new” developments are really attempts to draw consumers attention away from the fact that the processor industry has hit a performance wall. They have to keep selling until they can figure out how to get past it. For all of the big three's talk about how CPU clock speeds don't matter, if one of them tomorrow figured out how to release a 5 GHz processor, all of this hyper-treading, dual-coring would disappear, and the gigahertz race would begin anew. That you can bank on.

Life, Liberty, and the Pursuit of Broadband

Life, Liberty, and the Pursuit of Broadband

A couple of days ago I walked around San Francisco for almost an hour looking for an open access point so that I could send a single email with attachment to another party. I couldn't find one where I was. A friend had suggested carrying a key fob that would show me where there was an open hot spot. One of the biggest problems was that whenever I would find an open access point I couldn't get on the internet, probably due to my lacking proper credentials to log on to a proxy server that would allow me to get out to the internet.

I was moving from Mission and New Montgomery up through Columbus and Stockton. I would stop every few blocks to get out my iBook and check for available networks. There were always at least three, but they were all locked down. Suffice it to say that I wasn't able to send the email until I reached my destination. Why isn't internet access universally available? I have heard the arguments that it will destroy several companies' businesses, but I am not sure I believe that. After all Comcast is a cable TV company and SBC is a telephone company. Between the two of them they probably are responsible for over 60% of the ISP business in the US. For them, TV and telephone are their primary business focuses. Internet is just icing on the cake. In fact I remember reading that cable internet wasn't even profitable for many cable TV companies just a short while back.

So what would happen if internet access were spread out over a very cheap 802.11b citywide network. First off, for heavy users, it wouldn't be acceptable. The speeds would probably hover around 256kbps even if the access point were connected to a T1 because of a combination of range, interference, and traffic. So for email and internet browsing it would be O.K., but for uploading significant amounts of data it would be great.

The cable companies are beginning to offer much greater downstream bandwidth speeds than before. These downstream speeds are similar to the speeds offered by Japanese ISPs. Of course the Japanese ISPs are still offering greater bandwidth than most of the cable internet providers here in the US. The 6 Mbps downstream speeds that I have recently heard offered are closer than the 2 Mbps cap before. Domestically getting the greater bandwidth costs almost four times more in adjusted dollars than it does in Japan.

The main benefits to widespread internet access would be that people who have had limited access to the internet would gain greater access to it and balance the gap between the rich and the poor in schools. After all, it is much easier to do a report when you have high-speed internet access at home than it is when you have to cross sometimes significant distances to reach your public library to do the same research. It would increase the profile of the city in which it was deployed. The city would immediately become a more popular destination for business travelers as well as tourists. The hospitality industry, currently making a small profit from offering high-speed internet connections in their hotel rooms wouldn't be hurt too bad, because most business users would still rather have the greater bandwidth since they are usually in a hurry and money is less of an object.

The benefits to consumers are obvious. The prices would drop for bare bones internet access, and companies would have to offer rich content to add value to their broadband services. They could offer synchronous net connections and large web based file stores, movies streamed over the web at full quality, and sporting Dolby Digital. DRM wouldn't be much more of an issue than it is now with QuickTime or any other streaming technlolgies. With the large web store consumers' automobiles could be connected to the 802.11b network and people could stream their music to the car stereo. Many consumers would pay for that. They could offer social networking services to get to know other people on the network. There are many, many other models for increasing margins and profits on providing internet service. Web advertising would explode with new opportunities to market to previously untapped urban markets in the U.S.

Rich media producers would immediately see a boost as the number of users connecting at higher speeds went up. Ideas that would have been cancelled as too bandwidth intensive could be drawn back up. TV over IP could really become viable, and the overall substance of the internet would increase almost overnight. IP telephony would pick up, video conferencing would pick up. Online retailers would be able to give better and more visual information about their products to would be consumers, and therefore sell more products online, which in turn would increase their margins and decrease their costs.

The negatives are that there may be some very short term instability in the internet access segment, but companies who are forward thinking and progressive will be able to make the transition easily. Right now the internet service provider market, and really the overarching view of the internet is stuck in the nineties. If business really want for the internet to become profitable, and for new services to proliferate, web access needs to be at the least, far less expensive, or at best free.

I fail to see the logic in not deploying citywide broadband net services for free. Unless people are truly classist and some may say racist, although I am not prepared to go that far, we should roll out free broadband in all major cities across the country. We might finally realize that new economy that we have been promised since the eighties.

Evaluating Developers

Evaluating Developers

One of the biggest issues with modern development is how to practically test programmers. The heart of the problem is that for many years, one could segregate the good or experienced programmers from the inexperienced or bad programmers by their knowledge of the deep syntax of the language.

The problem with this method of testing is that now the answer to a question about a command or function is available at the drop of a Google search. Without this divider, suddenly all developers are at the same level. Worse even, developers who are less good, but have studied up are able to make themselves look better initially than their better comrades by cramming harder before the technical screening. Employers and clients are now stuck in an untenable conundrum. If they hire the person who can best answer their technical questions, they still can not be assured that they are the best person to do the job.

Here is where logic testing comes in. Not boolean logic, but flow logic. If you make a potential developer lay out how they would structure their functions, CFCs, Classes, or Methods then you will be able to see instantly if they are an experienced developer or not. The experienced developer will think out their application in a manner that separates the data, display, and logic and allows for maximum modularity and reusability of components. The language doesn't matter. A semi-decent developer with a good understanding of logical flow can pick up the syntax of most any language in 3 – 6 months. Which is a long but acceptable ramp up for someone who you can be assured will do the job right.

What if you don't want to wait 3 – 6 months. Then I would recommend combining the syntax test and the logic test and weighing carefully the results of each. If the candidate can answer all your syntax questions, but can't layout a simple application, then they probably will not ramp up quickly enough to perform to your needs. Likewise, if they excel on the logic portion of the test, but have difficulty with the syntax, they will have the same difficulty in ramping up acceptably.

In a web development environment, I have found that learning Java has helped me tremendously in tackling the difficult concepts of inheritance and even modularity. I was average at ActionScript until I learned it since much of ActionScript is based on Java. I would now consider myself good at it. The same goes for ColdFusion. I thought I really understood it, but after learning Java I realized how little I truly knew about it. Many programmers will scoff at learning the languages from which the others are derived, however it really does help. I had to learn basic C before I could even begin to understand Java, and even then it was a struggle to get my head around its strongly typed nature (declaring variables, and initializing objects before using them), and especially the nature of public and private objects. I had many long nights tearing my hair out over the only one public method-per-class rule, which makes sense, but in all the documentation I had read, I had never seen that rule explicitly stated. All programming languages have their do-or-die moments of explosive frustration, and all programmers know that we have to push through that to get to the real payoff, but that frustration is magnified by a factor of 10 when we don't really understand why something works the way it does. All-in-all learning C and Java is definately worth your time.

All of this leads us to more questions than answers about how to pick a good programmer. Employers should remember that probably the most un-natural thing for a human being to do is to program. Developers take nothing and turn it into nothing that looks like something different. All software is just thought perpetuated, so what you are really interested in is how the individual thinks, and there are many ways to test that. What we are left with is that businesses and clients should be hiring individuals not skill sets. What I mean by that is that they should select a particular programmer because they think in logical patterns and have a strong work ethic where planning is concerned. The measure twice and cut once allusion works well for development. It is much better to find a problem in the planning stage than it is to find it after customers or other employees are using the application daily.

If the development cycle is too short, programmers are set up to fail. There is no way that a group can develop good robust software with a micro-development cycle. True, there are people out there who could take 20 years to develop, and still turn in an unusable application. However, the majority of good developers given a well planned and stable development cycle will deliver good code, which will make for a good maintainable application. The problem comes when developers have to rush. The part of the cycle that is always cut is the planning portion. Wireframes aren't adequately tested, flowcharts are never completed, and the developers have to rush in and just start building uncharted methods, this quickly leads to spaghetti code and extraneous methods that lead no where. Dead code stripping IDEs are cool, but unnecessary if developers are able to create quality flowcharts and wireframes. Should the development cycle be indefinate? No, but the PMs and clients should talk to the developers and make sure they have a complete understanding of the specs before delivering the final draft with timetable to the client. The developers will know how long it will take them to plan and whiteboard the entire application, then the actual construction will just be follow through. If this process is adhered to, you will have happier developers, because they won't have to work insane hours to remain on target. Happier PMs, because they won't have to constantly reassure the client when the project goes over time. And ultimately happier clients because they will have strong robust applications that will deliver in the short term and remain upgradable in the future.

Then what of team dynamics? It is obviously best if you have a team of developers who respect each other's ideas, and it is superlative if you have a team that likes each other as people. It is crucial to have a good team dynamic. A developer's best resource is another developer. One of my favorite things about being a developer is the sense of comradery that comes with being a part of this incredible group of people that spans all races, geographical locations, and political affiliations. Well, maybe that is too grandiouse. Most developers share the common thread of being way too into technology and a overwhelming desire to show someone who can understand why using bit shifts instead of old math to speed up Java operations is cool.

So, evaluate logic, personality, and some syntax when hiring developers and you won't have a problem with your development teams. Set proper expectations with the client, and you won't have problems with your development cycle. Build enough time into the development cycle and you won't have problems with buggy spaghetti code and applications that need constant repair. Do all of these and you will have a bubbly productive environment in which everyone is happy. Fail to do the above, and you will have a lot less hair. The choice is yours.

CFCs and the Single Web Developer

CFCs and the Single Web Developer

Didn't all the talk about CFCs go out in the early nineties? Isn't a CFC some nasty chemical compound that chomps on the ozone layer? Well, that used to be what we defined a CFC as, but since ColdFusion MX, a CFC is a reusable module of code that we can write to change the value of strings, perform query operations on a database, write a trigger for a stored procedure, or really anything our code hungry little brains can think up. The need for CFCs developed once enterprises began to want to build object oriented web applications. ColdFusion originally had been developed to be easy to learn and use, so it was a procedural language similar to basic. The code executed as it was written so it was relatively easy to read through a block of code and see what it did.

ColdFusion is still procedural, however through the use of CFCs(Cold Fusion Components) we can simulate object oriented design. The proper use of CFCs starts way before we write even a single line of code. In the planning stage, a web developer has to ask themselves, “does this need to be a part of every web page?” “Can this function stand on its own, and would it be cool if I could use it for all of my applications?” If the answer to the first question is yes. Then you should probably just put the code into your Application.cfm file. If the answer to the second question is yes, then we should start looking at building a CFC to handle that function.

Building a CFC really requires that you understand three tags. The cfcomponent tag, the cffunction tag, and the cfinvoke tag. The cfcomponent tag is a wrapper for all of our cffunctions. The cffunctions will be doing the work for us. You can include as many functions as you would like inside of your cfcomponent wrapper. You can even have a function call another function inside of the cfcomponent wrapper, or another cfcomponent. When you save your file, it has to have the extension .cfc or ColdFusion won't know that it contains components, and your cfinvoke won't work. One of the cool things about components is that you don't have to cfinclude them to make them work. Thats what the cfinvoke tag is for.

So let's dive right in. The problem is that our application needs to have a login page, and every page in the application needs to verify that the person reading the page is indeed logged in. Easy right. So to plan it out quickly, keeping display, data, and logic separate, we would have a form that takes user input. Then a second page that invokes our login verification, to check if the username and password are correct (this is a simple login system), and a third page that acts as one of the many pages of the application that will indeed verify that the user looking at the page is logged in. You will have to make sure that session variables and the proper timeout is set up in your Application.cfm file for all this to work. I am going to assume that the people reading this article know how to create a form that when submitted passes the form values to a file called validate.cfm. Our CFC file is called security.cfc. Here is the code for our password validation function:

What this code does is to take the arguments supplied by the cfinvoke tag and pass it over to the cffunction. Once the function gets the username and password arguments, it checks them against what is stored in the function. If they match the function returns true or false back to the validation.cfm file. Where the following code decides what to do with it.

what the above invoke does is that it calls the passwordAuthentication method we created in our cfcomponent in the file security.cfc in the same folder as the validation.cfm file, sets the return variable of true or false to the ColdFusion variable gonogo. The remainder could be another function, but it is so little code that it seemed like overkill to make it one. The cfif statement checks the value of the variable gonogo and if it is true it creates a session variable named authenticated to true and passes the user on to the application. If gonogo is anything but true it will pass them back to the login page.

The next step is to write a cffunction to check to see if the user is logged in to provide security for each page. The cffunction can go into our security.cfc file. It would look something like this:

This function checks the session variable authenticated to see whether it is set to true or not. Based on your cfapplication settings it will timeout and force the user to log in again. If the variable's value is true then it will do nothing and let the user see the page, however if it has timed out or the user has tried to improperly access the page it will send them back to the login page.

There is now one last thing to do. To make sure that every page of the application calls this CFC to make sure the user is logged in. This can be tricky, because you could create a bad loop where as soon as the user tries to log in, the page goes back to the login page, repeatedly. If you put the cfinvoke into your Application.cfm file then it will constantly loop. The way I resolve this is to put the cfinvoke tag into each page of the application that I want protected, leaving it out of the index.cfm page, or the login page. There are more creative ways to do this, but it really is only a couple of lines so it isn't a big deal. True purists would do something more dramatic, but I like to get things done, and for a small application this is sufficient. If however, you have a larger scale application you would be best served by making your authentication stand alone. The code for the start.cfm page and all other pages of your application would be like so:

That's all it takes. I hope this helps some of the CF developers out there that want to get into the world of CFCs. It really fires the imagination, and can help reduce the alarming failure rate of custom developed applications. Good hunting!

Thinking In The Box

Thinking In The Box

Well, yesterday I wrote my first real 100% fusebox program. You can check it out here. It allows a user to type notes into a text field, while broswing for instance, then come back to the site and load up their notes again. The implementation is completely devoid of any database use, and is unique to each user visiting the site. How was this accomplished, you ask? I used ColdFusion session variables to hold arrays with the titles and content of each of the memos. Since session variables are unique to each user's session, they are mostly private, and completely editable and deletable. Session variables timeout, and the length I have set for this application is 2 hours.

Client variables would have been optimal for this since the burden of data storage would have been on the user's systm, however client variables in ColdFusion only allow simple data types. This is actually good for Macromedia's PR because the last thing they need is for a bunch of developers to go hog-wild with client variables and begin storing entire applications in cookies on the user's computer.

The application was written for those times when you are going around the internet gathering information, and you start down a trail of sites. If you want the source, you can download it here.

I am sharing it with the public, but please let me know if you use it in your applications at irvin@owensperformance.com, I am curious about how others would implement this little app. Where was I, oh yes… You often find yourself deep down your trail, with no idea of where the trail originated. Or, as frequently happens to myself, I will be working on a web application and get a call from a client or friend and lose my train of thought. It will take me hours to get back to where I was again.

I am sure that right now you are thinking, why wouldn't I use notepad or its Mac equivalent TextEdit? There is no reason you shouldn't except notepad isn't on the web, it takes time to load up and save, and it wasn't written using the Fusebox methodology. What does Fusebox have to do with little notepad apps? Well, nothing really. This was an exercise to force me to write an application using Fusebox, which I have criticized for a long time. I still have a few issues with it that aren't really with it, rather they are with the way some search engines lack the ability to properly index sites that use includes heavily. But, any trouble caused by using a methodology such as this are miniscule compared to the failure rate of custom enterprise software.

I am not going to go into deep detail about how to code fusebox, other sites have done a far better job than I could. fusebox.org, secretagents.com, and halhelms.com are just a few of the sites that deal with fusebox and its related lifecycle management methodology FLiP. I do like the fusebox way of doing things because it remains very flexible with keeping everything modular and dynamic, but really any system of programming that breaks display, data, and control code up into separate little well-documented bits is very helpful. I especially like fusedocs.

Fusedocs are an XML based way of structuring documentation so that a machine can read it and convert it into good framework documents, or another developer can easily pick up the file and figure out what is going on. I find that most of the code I see is terribly underdocumented. I have done it myself, thinking that I am the only one who has to look at the code, so why should I document it? Several large applications, and long nights of Mountain Dew later I find myself creating copious documentation for all of the new code I write, as well as the revisions and bug fixes to the existing code.

I probably wouldn't recommend going through and rewriting all of your existing applications in Fusebox if they are working, but I would recommend writing all of your new features and auxilliary applications in it, since I have found the even those applications are suspect to revision feature creep.

It is hard to make a developer write software using Fusebox and its associated Fusedocs, because good developers are often that way because they are lazy. I don't say that in a derogatory way, many good developers take the simplest and clearest path to the end, which is often not the fanciest way, but it is the easiest to understand and in my opinion the best. The downside to that is that it usually excludes documentation and limits the scalability of the application. Using fusebox just makes sure that the applications you write today will be easier to rewrite tomorrow, which all developers will have to do eventually. For those just beginning with Fusebox, I hope the source helps you, I was glad that I had source available when I was just starting to figure it out, and for those who are new to ColdFusion, start working with Fusebox sooner rather than later, and save yourself those long nights with Mountain Dew and Jolt as a chaser.

Application Deathmatch Desktop vs. Web

Application Deathmatch Desktop vs. Web

In this corner, wearing the red and yellow trunks you have your typical desktop application, and in the opposite corner, wearing the red, white, and blue trunks you have the same functionality in a web application. Now you both know the rules, at the sound of the bell, come out with your hands up ready to fight!

That is almost the situation in most corporate IS departments right now. Even though it is still early, it looks like the web application has taken an early lead. Now, let me state my bias. I am a web application developer, so I should have a bias toward web applications, right? Not exactly. I also love Java for desktop applications because of its portability. Let's evaluate some of the pros and cons for both approaches and we can decide later who will be at the center of the ring, battered and bloody, but victorious.

The Underdog – Desktop Applications

Why the underdog, well, what most people think of as desktop applications have been with us for about 20 – 30 years, depending on whether you are talking to people from XEROX PARC, Apple, or Microsoft. The tale of the tape for the desktop application is that it is extremely flexible in ways that its opponent, the web application can never be. The desktop application can use the computer's hardware in almost any way imaginable.

The only barrier to development is the operating system, which is usually written in such a way as to allow the developer as much flexibility as possible without giving them the ability to bring the entire system down. The application developer's language of choice is usually one of the following: C, C++, C#, Visual Basic, Obj C, Java, Python, or sometimes if the developer is in an arcane mood, Perl with TK. C# and Java are different from the others and have different pros and cons than the other languages listed, but we'll get into that in a minute.

Notice a lot of C's in there? That is because C is the language from which almost every modern language has derived. It is often difficult to develop using C because GUIs and the like weren't around when it was developed so it takes a lot of code to create the pretty images we take for granted every day when we boot up our computers. It isn't object oriented, so it is more difficult to produce clean code, which has spawned the object oriented C languages, C++ and Obj C. These language allow a developer to easily call and implement modular components to develop an interface for example. The major flexibility of desktop applications comes in where a developer wants to present something in a non-standard way, like a box with three rounded edges for example. The developer can eschew the standard window and write his own window look and feel. Most modern operating systems frown on this, but it can be done. Also, floating content on top of the window, or on top of text can be easily done.

The killer right cross of the desktop application is the speed with which it can execute code. The application developer can count on the full attention of the computer's processor, video card, and sound circuitry if they so desire, at least for a while anyway. This makes it highly improbable that an application like Photoshop would be developed as a web application anytime soon. Also, that access to resources causes issues. Office is about 300 MB, Creative Suite is almost a gigabyte with everything installed, and really doesn't get up to speed unless the user has 1 GB of RAM installed. Users don't really want their applications to take up all of their drive space, they would rather fill it up with pictures, music, etc…

The desktop application's right cross happens to coincide with the web applications weakness, that it can only have what system resources are available to the browser. Flash and Java are two ways to get around that, but not completely.

The developer working on the desktop application does have a couple of headaches though. When writing an application the developer will do it on a single computer more than likely, and that computer will run a single operating system, perhaps two, so the developer won't know if it will run on a competing architecture. This isn't often a problem since most of the world is using Windows on an x86 based machine right? Wrong, as the future unfolds, it is likely that a de-homogenized computer environment will become the norm again with many different architectures needing to communicate with each other. I say this because of the ever growing use of computers in areas where they aren't traditionally used. Media center devices for example. Microsoft has rolled out an entire operating system for this purpose, but there will probably be intense competition on this front, making it difficult for application developers to create software that will work on all platforms.

Enter Java. Java was developed so that it will run on almost anything. It has applications from cell phones to huge multi-cpu servers. It allows a developer to write a desktop application and have it run on almost any platform with little to no changes. Even down to the graphical user interface. It is my language of choice when developing desktop apps, however it is limited in that it performs slowly on older systems, which will continue to be less of a problem. This would seem to be the ideal language with which to develop since it runs on everything to which the Java Runtime has been ported. Microsoft has its version of Java called C#. C# has some of the ease of use of Java, but it is limited to Windows machines, which makes one wonder why the software wouldn't be developed in Windows' native C++ since it would run faster that way anyway. I don't see any practical use for C# as a desktop application development language, but it does have applications in web application development….

Desktops ultimately can run software faster, have far more vast resources, such as the entire free space of the hard drive to store data, can use 3D hardware, etc… The largest detractor from the success of custom software development on the desktop is the deployment nightmare. When rolling out a new piece of desktop software, you have to ship it, or at best have users download it and install that piece of software on their computers. Then that user has a version running on their system that they can use at anytime. Great!

The trouble starts when the developer finds a bug in the software. The developer patches the bug and then distributes the revised version of the application to the affected parties. After about 10 rounds of this, the users are all running different versions of the software, and the developer is fielding all manner of trouble calls only to find out that the version they are running has never been updated. There are complicated and sometimes expensive solutions to this problem with desktop application development. To make matters even more insane, most modern enterprise desktop applications are using a database server, so all of these desktop apps are using a database to store their information, why would you write a desktop application again? The reasons are more of what we touched on above. Users like to print and have the print out look like what was on the screen. That is something that desktop applications do very well where web browsers leave much to be desired. Ok enough about desktop apps.

The Favorite – Web Applications

We've already done a good job of talking about the issues with current web application development. There are still, however a few we haven't talked about. Connectivity is a biggie. If a user isn't connected to the internet or local network, they can't use a web application. Now, in most business environments, users won't be off-line for more than a few minutes so this isn't as much of an issue as it used to be, but for home computer users, this is a big deal.

What's so good about web apps then? Well, the distribution is much simpler. If there is a new version of an application it is already distributed as soon as the developer puts it up in production. There are no messy distribution issues, and the calls the developer has to field will almost always be due to his sloppy coding at 2 am instead of very simple user issues.

Since there is often very limited ways in which the user can interact with the browser, there is a shorter learning curve, most web saavy users understand the concept of hyperlinks, etc… If the application is coded to standard XHTML, then it is every bit as portable as Java, and in the future it would even be portable to places where there is no Java runtime such as internet applicances. Another huge benefit is that users can use the processing power of huge complicated servers instead of being limited to their small CPU.

Web apps can do all processing in the back end, so the speed of the application is limited to how much server dough the company wants to cough up. Storage is another benefit. While storage on the user's machine may be limited to a few kilobytes in cookies, storage for that user on the server is up to the web developer's discretion. If everything is on the server, and the server is backed up, the user is off the hook if his computer succumbs to viruses and they have to reformat.

Rights management, this is a biggie. If users never have posession of the actual software, then they can not redistribute it. The owner of the software has the ultimate right to allow that user to log in or not. If someone were to hack into the user rights, it would be much more easily traced than someone handing a disk to another person. Because of the ease of distribution and the lack of piracy cost drops drastically. In the end Microsoft is right, and web applications will be the wave of the future. They are wrong however, in believing that they will control that future. Macromedia with Flash and Flex will be very valid contenders, especially if you compare ASP.net with ColdFusion. I don't know many developers if everything else is equal that would choose ASP.net over ColdFusion.

Another benefit is that taking applications off of the users' computer frees up system resources to run their operating system in a sandbox. Since the OS will almost never change and the applications they are running will not be on their hard drive, the OS can be read only for the most part and reside in RAM. Viruses couldn't do much more than knock the user offline, and that could be remedied with a power-cycle and the user would be right back where they were. With advances in browser technologies, the 3D hardware can become available to web developers enabling a new level of online gaming, and a new form of virtual office and business collaboration. Ultimately we will be running gaussian blurs on our photo images online. Connectivity is an issue now, but in five years or so, there will be blanket wireless coverage in most major cities.

It looks like web applications are delivering a killer combo to desktop applications with them against the ropes. Which will win is ultimately up to the hackers and their undermining of the public's trust in the internet and the imaginations of web application developers.

Mac OS X 10.4 – Review

Mac OS X 10.4 “Tiger”

Since I'm a Mac user, I feel that it is my duty to do a quick and dirty review of “Tiger.” After all, there are so many sites that seem to be content to remain in Apple's good graces, I haven't found many that have been all that objective. I am not an ADC member, so I really don't have anything to lose by calling Apple on any of their exaggerations or lies. The Ars Technica review of “Tiger” was very good, and I don't want to try to redo what they or anyone else has done, so I'm going to proceed in discussing the well known points of “Tiger” from a user's point of view, then I'll discuss some of the lesser known changes and updates of “Tiger,” and finally I'd like to discuss some of the ramifications of what Apple has done with some of the new APIs they have added to their OS.

I, unlike many, eschewed the advice of most of the Apple news / discussion sites and did a simple upgrade from Mac OS X 10.3.9. I didn't feel that I should have to erase and restore everything for a point upgrade. If it was the case that I always had to do an archive and install, or a wipe and install, I may as well continue using Windows. My original reasons for switching to the Macintosh back in 2001 were very simple:

• Spending too much time on maintenance
• Tired of spending money on fighting spyware / malware
• Insistance that with a decent GUI Linux would be the OS of choice
• Free OS X developer tools
• Macs are cool

So why would I do things like move all my files to another drive, and then move them back? Fortunately for me, Mac OS X 10.4 installed beautifully. It took about 30 minutes on my G5, and about an hour on my iBook. Both systems then took about 4 hours to index.
Spotlight
Let's start by talking about the feature that has gotten the most attention due to our search crazy eSociety, take a look at Google's stock price. This feature was not that important to me in the larger context of things. The individual applications I use, iTunes, iLife, Office, etc… all have decent searching functions built into them. My folders and files, while spread across two file servers and over 200 GB of internal storage follow an intricately balanced system devised by me over about 20 years of computer use. Suffice it to say I never really had trouble finding files on my computer. At least files that mattered to me. Still, I find Spotlight to be cool not for what it is today, but for what it could be in the future. Metadata is great, but you still have to enter it. Apple has just opened the door for third party application developers to go wild with helper applications for OS X. Imagine, a small application that will go out through the web and get lyrics for each and every one of the 5 to 10 thousand songs in your iTunes library and put them into metadata for their respective song. Think about the possiblities for images. Another third party application could ask you to load up images of your family members on black backgrounds so that it could generate a clean algorithm for matching their faces to pictures. It could then generate metadata for images putting in who is in the pictures, it could even find common patterns like text in images and add that to the index, like the sign for the camp that your son went to last summer. While this would be technically very difficult, it is not beyond the possible.
Spotlight is more useful as a framework for future development than something that will get massive use today, unless you have many hours that you can devote to typing in your own metadata for each of your files, or copying and pasting it from various internet websites. Without that metadata it is only marginally better than the search in OS X 10.3, but with the metadata, it is of great use to the vast body of computer users who don't have an organization scheme for their computers and do not follow naming conventions for their files.
Dashboard
I don't know if I am the only one who is super psyched about this, but Dashboard is probably one of the most important innovations of the last few years. I know all about the Apple stole it, but wait they didn't steal it, they came up with it, etc… I'm talking about dashboard as a concept. What Apple has effectively done is to create a way to allow the vast number of web developers in the world to create applications that can run in stand-alone fashion on Macs without learning anything new. The Dashboard framwork is extremely impressive. It allows developers to write widets using CSS and XHTML, in a standards compliant mode, that can execute shell scripts to perform system level tasks. If this sounds a bit like ActiveX to you, then you get the door prize. Apple is again kicking Microsoft in the chops by taking an idea they came up with and executing it in a much better fashion, embracing the existing developer community. Microsoft has to remember, its about the developers stupid! No OS is going to survive if people have to learn a new programming language with each revision, ie VB 2005. Also, if it costs thousands of dollars to start writing software for a platform most developers won't touch it, unless some kind corporation will allow them to muck around with their source code and servers.
Dashboard is a stroke of genious, and hopefully the hacker community will stay out of it and allow it to thrive and be what ActiveX should have been. I think that as long as billy bob and ray ray don't download widgets that are from “Gator” as they are prone to do then things should proceed nicely. Again, there is nothing extremely useful for Dashboard right now, but soon there will be.
iChatAV
I was reluctant to cover iChatAV's improvements becaus most of the mac audience really can't take advantage of it. The Ars Technica article does a good job of describing the ins and outs of this enhancement, but the more salient points are that 1 to 1 video conferencing only works with either a fast dual G4 to any G5, or G5 to G5 and requires 100kbps. Otherwise, it falls back to H.263 and the framerate drops to 15fps. This is somewhat understandable as it is pretty tough to compress video on the fly, but it shouldn't be worse than it was with 10.3. I think Apple needs to fix this.
To do the super cool three-way video conference a dual G5 needs to host it, I would hate to be in the same room with that G5, especially if it were one of the non-liquid cooled models, talk about loud, but the hardware requirements are understandable again because coordinating packets for four computers with non-consistent geographic locations and network connections is not a task for the faint of heart. But the 1Mbps upstream is going to be tough for the people who really want to use it, families. I don't blame Apple for this though, it isn't their fault that we have super litigious broadband ISPs in the US who don't really want to see technology advance. There is no reason we shouldn't have synchronous speeds over cable, and that it should be reasonably cheap. They have the money to deploy an advanced fiber network, and if that is too expensive then deploy wireless.
Developer Tools 2.0
Xcode is much stronger in this release with updated documentation and the ability to have it automatically flowchart methods. The ability to distribute builds across multiple computers using Apple's Xgrid technology, with the addition of a new GCC compiler with more automatic G5 and AltiVec optimization tools makes it completely indespensible. I thought the original Xcode tools were really sweet, and didn't know how Apple could make the tools even better, but they have. Apple is obviously a company that can learn from its mistakes and avoid them in the future, which is what most corporations fail at miserably. Many good companies have withered and died because they failed to change, and Apple realized after the bad OS 9 days that without a strong developer community they would be doomed. Objective-C is still really hard to learn, but now Java developers have as much to love about OS X as Obj-C developers do. Apple has done a great job with that.
General
Apple fixed a bunch of stuff that was wrong with 10.3, and enhanced some of the applications that you didn't know needed enhancement. The new system profiler does a much better job of giving users relevant information, where the old one, ie graphics cards being called by their chipsets, didn't provide much help. Now it gives you a detailed description of the graphics card, in plain english, and the enabled technologies ie Core Graphics, Quartz Extreme. They have greatly improved the speed of Safari and Flash within Safari. The overall OS is much more fluid and responsive than 10.3. Networking with PCs is much much improved as is wireless speeds. 10.3.9 for example would dump the finder whenever I was doing a large file transfer from Mac to Mac over wireless. My G5 would cause my PC to freeze for long periods of time while copying files across. That doesn't seem to happen any more with 10.4. Window resizing is finally smoother with OS X's enhanced line drawing abilities. It just feels really solid now.
The Future
Apple has left Quartz 2D Extreme turned off in Tiger's .0 release. I can only assume that this is because of some bugs found late in development. Users who have installed the developers tools can turn it back on by running Quartz Debugger found under the developer>Applications>Performance folder. I have found that window resizing and text scrolling get an incredible boost on my single 1.6 GHz G5. Of course it doesn't work on older PowerBooks and even recent iBooks because they don't have fast enough video cards and not enough video memory, ie Radeon Mobility 9200. I have yet to notice any artifacts, or bugs with it. I can only hope it will get tuned up over the next few months and enabled in the .1 release. Another really cool feature is the ability to change the dpi of the screen to make everything smaller on a 1024 x 768 screen for example. This is also available by the Quartz debugger, but appears to have a way to go before it will be ready for general release. It is promising though that someday I will be able to get a boost in screen real estate at the expense of my eyes.
It seems that Apple has done a lot of work with frameworks, but there isn't much to see in 10.4.0. At least not much for the average Joe user to see. It really isn't that much different than 10.3 as far as most people are concerned. Spotlight will be cool, but is it really worth $129.00 to the masses, no not really. I bought it because I wanted the developer tools to play with, and I am into frameworks and programming, but nothing about the new OS is so cool that I just have to have it. I know that Apple will start releasing updates that have cool functionality that will only work with “Tiger,” since that's Apple's modus operandi, and this will force its user base to upgrade, but cmon' is it really that much better than 10.3. It will probably get better at 10.4.3, but until then I'd say that the majority of users could probably wait.
iWork
This was almost not worth mentioning, but I thought I had to say something about it. With most if not all OS X 10.4 purchases, users are treated to a 30 day trial of the iWork suite. What is this a joke? This isn't a suite, Pages is like Microsoft Publisher but with Apple's world renowned marketing engine thrown at it, and Keynote is OK, but I'm not dropping PowerPoint anytime soon. There is no spreadsheet application at all, if this is supposed to replace AppleWorks, they have a very long way to go. I really have no use for it. The last Word upgrade was pretty good and Apple is not going to dethrone it with Pages, and the functionality of the rest of the suite still goes unmatched. The closest thing to it is OpenOffice. Seriously, I wouldn't have even released iWork until I had a spreadsheet application that was Excel caliber, an integrated email / PIM application, and some kind of database application that was based on MySQL. What was the point? Their sales are awful because most of the users who need this kind of stuff already have either Office v.X or Office 2004, both of which are better. I was really hopeful for this suite, thinking that it would be a better looking OpenOffice, but I was greatly disappointed. Hopefully by iWork 2006 it will be at least a useful low cost replacement for Office, but I still see no reason to upgrade from AppleWorks 6 if you don't have Office.

Challenge to $0.99 Songs

Challenge to $0.99 Songs

I have been reading about the heat that Steve Jobs is taking for offering songs for .99 US on iTunes. Apparently the large record labels feel that they could get more money for downloads and cite the popularity, and cost of ringtones, as their justification for raising the prices. I am in no way one of those Apple people who claim that Steve Jobs is the Messiah and that every word he uttereth is the gospel, but in this case I agree with him. Apple's price point is exactly how much the market will bear. Not a penny more. I don't know anyone who would be willing to pay more than .99 US for a song. I downloaded a couple of ringtones, and then I got my phone bill. I subsequently have not downloaded any more ringtones.

These same big record company execs feel that they should be able to vary the cost of albums based on whatever whim they feel on that particular week. Again, $9.99 US is all anyone will pay for a download. That price point is sweet, and resonates with most users as how much an album is worth. I fail to understand how someone could have money coming in hand over fist, and then want to tamper with success. But if I could believe that such an entity could exist, the record companies would be it. Their logic just doesn't add up. I think that most of it is just that Jobs' holds too much power over them, and his power is increasing by the week. People have been saying the day of reckoning for the recording industry has been coming since the '80s when CDs crept up to around 20 US. Even the artists themselves are disgusted with how the industry is run. In black and white. I would not buy any more music from the iTunes store if prices started creaping over .99 US for songs and 9.99 for albums.

Instead of chasing their tails over DRM and pay-per-listen business models, how about offering consumers some innovation. Most of the music is currently delivered on CD, how about DVD. It would be much more difficult to rip, and it offers substantially better sound quality than a CD. DVD offers the ability to use DTS for surround sound, opening up new avenues for audio engineers who have to be going bananas with being limited to 44.1KHz at 16-bit sample depth. DVD offers a crisp 92KHz and 24-bit sample depth, and for those audiophiles, like myself, who insist that LPs still sound way better than DVDs, there is a stereo format for DVD-Audio that weighs in at 192KHz at 24-bit depth, and listening to that, the DVD spinning noise nonwithstanding, I can almost forget I am listening to digital.
How about including all the lyrics of the artists in the metadata with the songs so that I don't have to type it all in and can use Spotlight or Google search to find songs by a bit that I may remember. How about throwing videos and extra content on a DVD-Audio disc and selling it for 14.99 US?

I am not slighting CD audio. Some of the tricks recording engineers have used to get every last bit of sound quality out of an old technology are simply amazing. There are some darn good sounding CDs out there, but consumers are being offered nothing for their money except for the same old, same old. Hey, listen, record execs, technology has changed. The potential for digital audio is much higher than most people know. Why not try to get new people to fall in love with the format. The fact that people are choosing a sonically degraded format over whatever is being offered should tip the industry off that something is wrong. CDs are inconvient and offer nothing in trade for their lack of quality. DJs lug 12″ vinyl around because it sounds good. There is nothing conveninent about a 50lb crate of music, but they deal with it for the quality.

The product being put out by recording companies in the way of pop music leaves much to be desired also. The quality of the music has dropped as the result of using formulas to try to grab every last sale from either a stale loop, or an ancient guitar lick, or some inane hook. How about some experiental music. Digital distribution will win because it breaks new artists to the public.

It is incredible that in the face of declining disc sales, all they can do is figure out new and improved ways to hurt the consumer. Most businesses would have been destroyed by competition now, and I guess that is what is happening right now. Now if only someone could get the artists out of their contracts and get them to record directly to digital, and compress the songs at a higher bitrate with new features like the surround MP3 format, digital music would explode. The best thing about it would be that consumers would have a choice, and artists would finally be compensated in the way that they should.

A Marketable Mix of Languages

Marketable Mix of Languages

Recently I have had to ponder a very unsavory prospect. The prospect of having to learn a new favorite programming language. Since I am a web developer my favorite language is now and has been ColdFusion. The problem is that, while I deeply hope it will thrive under new ownership, ColdFusion faces a very uncertain future. While I would love to stick with ColdFusion forever, I have had to think about a world without it.

The real problem is that while ColdFusion has its handful of issues, there is nothing that approaches its ease of use and relative power. ColdFusion's performance leaves something to be desired, but that is because its riding on top of Java. JSP suffers from the same issues. Still, Macromedia has been working on tuning it, and I don't think many will complain about MX 7's speed. Still, it seems that ASP.net is the fastest. Of course the relative speed of any web application is only as good as the developer. ColdFusion's ease of use is one of the things that has caused it the most trouble. Much of its bad reputation is due to inept programming, or poorly administered or written SQL, not the application server itself. It is really easy for a novice to jump in and start throwing tags around willy-nilly, building dynamic web applications with CF. However, these almost never scale and rarely ever end up in use. Frameworks such as Fusebox and Mach II have helped CF in these respects, but the issue is that developers who choose to use these frameworks are few and far between, while the landscape is littered with sloppy CF projects.

Most of the companies I have interviewed with in recent history have confided that they are having extreme difficulty finding ColdFusion developers. This is astonishing to me because it seems as though everyone has at least heard of it, and many have dabbled in it, so what is keeping them from using it full-time? The answer is that it is not easy to really get a handle on Object Oriented Programming principles. ColdFusion is not an object oriented language, but it does an extremely good job of simulating it now that we have components and inheritance.

Well, we have covered what's up with ColdFusion, what about the other languages out there? Let's start with ASP.net. The original ASP was only marginally better than Perl for building web applications, and less secure because it had to run on IIS. Microsoft has taken it on the chin for the issues with IIS and ASP, and the result is new versions of IIS and ASP.net. The good thing about ASP.net is that now developers can use full C# classes by invoking simple tags. This is really cool because credit card transactions for example can be removed completely from the web server and can be processed by a C# class running in the background and connecting to the bank via another secure socket. This creates another layer of abstraction between the hackers and the data. ASP.net is fast and it is capable, so what is wrong with it? It's complicated. Microsoft has overhauled Visual Basic, and now if you are an existing VB developer, you may as well learn C#. It takes a lot of code to do a little if you are not using the default tag library that comes with it, or one that has been downloaded from the web. There is a silver lining to this cloud. If you do it right, you will only ever have to write that code once for that particular function, then you can use it over and over in your future code. Another advantage is that since its Microsoft, corporate America loves it despite their security issues. The reason is that they are already heavily invested in the technology. Many of them are running Windows Server 2000 or 2003, and it comes with IIS and therefore, if it has been kept current with updates, is ready to process ASP.net code requiring no further investment. ASP.net code is not script anymore, but instead is compiled code ready to run against Microsoft's .net framework. This framework is similar to Java's runtime / JDK, but since it is all closer to native code, and Microsoft knows its operating system as well as anyone, it seems to run much faster than similarly compiled Java classes against the Java runtime. However, you have to run ASP.net on a Windows server, and you can't easily port it to another platform.

JSP is relatively new, and the JSTL has made it more ASP.net like, or vice versa. In JSP 1.0 / 1.1 developers had to write longhand Java classes in the pages themselves, or in the pages to which the html form was submitted. JSP 2.0 has done away with this in favor of a customizable tag library. Again, it takes a lot of code to do a little, but you only have to write it once. Its advantages are the same as ASP.net. It is compiled so it runs faster, but it will only run as fast as the Java runtime can process it. Therefore it needs a Java container like Tomcat or Macromedia's JRun. These are sometimes difficult to configure, and have memory leak issues. Unfortunatly ColdFusion has to run in these containers also, so it has the same issues as JSP. Many of the memory leak issues can be avoided by careful programming, but they can be annoying. Many companies seems to trust JSP because of its pretty good security track record, and its ability to work well with their existing Java infrastructure. IBM is backing Java so it has a strong following. At the same time IBM has started to back PHP so one has to wonder how strong its commitment to JSP is. Perhaps IBM realized that JSP is just no good for high volume public facing websites, while being acceptable for intranet applications.

Let's talk about Perl. There isn't much to say about it anymore. It used to be very dominant, but there are only a few sites remaining that still use it. It is pretty cumbersome, arcane, and slow. It was originally designed for writing scripts that could perform functions on UNIX servers. It is still used frequently to perform those tasks.

Python is relatively obscure and new. Google has been making good use of it, and it seems to be extremely fast. It can be used for creating desktop applications as well as web applications. Its telltale is web pages ending with .py. Time will tell how this language will weigh in, but other than Google, www.folklore.org, and perhaps Yahoo! I am not sure who is using it.

PHP is a favorite among many web developers because of its simularity to C and its clear and easy syntax. Apparently it was developed specifically with web development in mind so it is processed along with the HTML in the page. There is no need to write extreme amounts of code to do basic tasks, and its performance can be close to ASP.net. It makes a good bridge between ColdFusion and the more difficult langagues like JSP and ASP.net. The bain of its existance has been its poor security record. PHP has allowed hackers to do some pretty horrible things to the web servers that have been attacked. The newer versions have done much to lock down these security issues, and now its reasonably secure. It is possible to establish a persistent database connection which minimizes the impact of overhead against queries. Most commercial sites have begun switching to PHP and MySQL because of their good performance and excellent price point, Free!

So for now, those are the real choices. So what's marketable. Microsoft's ASP.net will probably be a good choice for the next few years, and JSP is going to hang around, but it isn't clear if anything can be done to help its sluggish performance compared to other application servers. ASP.net isn't cheap either. You have to buy a license for Microsoft Server 2000 or 2003, and to use it with a database requires either MySQL free, or Microsoft SQL Server. Microsoft SQL Server probably has better performance for large applications, but it costs.

Hopefully ColdFusion will be around for the forseeable future. Its ease of use and short time to market for apps keep it in the fore. It is secure, easy, modular, and scalable. It is used on many large commercial sites like Bank of America, look for the .cfm. Its price isn't too steep either, $1,200 US for standard isn't too much when you compare the cost of 5 develoepers for 12 months vs 2 developers for 9. Python and Perl are pretty much out because there isn't enough demand or use for them. The return on the investment of learning these just wouldn't be there.

I'll probably continue to master PHP and ColdFusion while trying to osmotically absorb ASP.net. After my experiences with trying to administer Jrun and Tomcat on low volume servers I am going to stay away from JSP until I understand more Java. I can write desktop Java apps, but web apps take a slightly different thought process. It isn't really worth learning right now over ASP.net because so many people are using it. Look for the .asp, old ASP, or .aspx, ASP.net. Still if you are working on front end websites. PHP, ASP.net or ColdFusion are probably all you should consider. JSP is just a little too new, slow and complicated, but it is free if used with Apache and Tomcat so it might be compelling. It certainly seems to have a foothold in large corporate intranet settings. Although I still wonder why they don't migrate to ColdFusion. CF can interface nicely with their legacy applications, and they could get more custom apps done more quickly, but productivity often takes a back seat to cost. Keep you fingers crossed with me about ColdFusion, and good luck!