iPhone Codesign Error 2.2.1 Firmware

I have an older project and have had my certificates expire. I spent a couple of days trying to figure out how to get the stupid thing to build. Then I found this blog: http://iphonesdkdev.blogspot.com/2009/01/codesign-error-valid-provisioning.html.

Basically what it says to do is to go into the .xcodeproj file for your application, open the project.pbxproj and modify the PROVISIONING_PROFILE variables.

This didn’t work for me, but removing all of the key / value pairs did.

I moved to wordpress

I’ll get all the old content in soon!

Bold Predictions About Rails

Bold Predictions About Rails

For a couple of years now I have been very disparaging of Rails, and in general the whole convention driven development movement. I have always figured that maybe I could do things a little better myself perhaps. Recently, however I have found myself using rails, and in a larger sense, adding Ruby to my toolbox, and have been a much happier programmer.

What suprises me is how many excuses I found myself making about why I shouldn’t use Rails. What I eventually realized is that I didn’t care if I could write that CRUD code a little better, or if I could shave a tenth of a second of execution time from whatever function I had written in *name the language* the important thing was that I could get my project done and get outside, or work on several projects simultaneously, instead of only two. I found myself spending time and thought cycles on code that was directly related to solving my problem, instead of code to get me to where I could start solving my problem.

Now I am always suprised when I hear my same old excuses coming out of other good developers’ mouths. I want to say, “you just don’t understand.”

The reality of the situation is that the ground has shifted under our feet. Because of rails, business stakeholders are demanding quicker turnaround on features and products, and non-rails shops are struggling to keep up.

Performance is always the first crotchety old excuse, the answer is memcache. Then reliability, f5 big ip is the answer.

Really everyone, evolve or die, it’s as simple as that.

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.