The New Armaggedon? Or Web Developer Boon?

OK, so it's a little link baiting, but... ZDNet has just posted an article about Your perilous future on Windows XP. Basically, Microsoft will stop supporting XP on April 8, 2014. This means no more security patches, no more malware checks, and no more holes plugged in Internet Explorers 6 & 7.

Wait...What?

Yes, there are still people using Internet Explorer 6 & 7. Why? There are large organizations (public and private sector both) that invested a lot of time, money and resources to put XP on their desktops to begin with. They then wasted even more money developing browser based applications that only ran in those browsers.

So, here's what's going to happen. MS will EOL XP, and IE 6 & 7 with it. (Definitely 6, and hopefully 7...). The day the last patches are released, new zero day exploits will come out that will never be patched. After the initial pandemonium, organizations who have not upgraded from XP will either A) upgrade right away, or B) start using Firefox or Chrome. Many of them would also start spending mad resources to upgrade their application code to work in browsers other than Internet Explorer.

Where this is going to be felt first, hardest, and likely the slowest to respond, will be within the finance and government sectors. These are the areas that should be the most secure, but are also the tightest on the purse strings. It will probably take some major intrusions, crimes, and data loss before they finally begin to respond appropriately. Even then, it will probably take an Act of Congress, which means it'll be even longer.

The upside is that contracts for web developers should skyrocket, come April or May of 2014. If you are highly skilled in HTML, CSS, and JavaScript, and can work quickly and reliably, you should be in high demand.

Now, will all of this come to pass? I don't know. That's what it looks like in theory. They all though Y2K was the end too, and it wasn't. I do think that this is a much bigger threat, on the grand scale of things. Guess we'll just have to wait and see...

2011 In Review, and the View for 2012

My, how time flies when you're having fun! It seems like only yesterday that I was welcoming in 2011, and now we're here a year later. So many things have happened in the last year, and rereading that post I see that I missed some things I should've done, but let's take a look in retrospect.

I wrote 27 blog posts in 2011. This is nothing, compared to guys like Ray Camden or Ben Nadel, but for me it was quite a bit, especially when you consider that between March and August I released only one post. Very early in the year, I began a series on creatingmany sites with one codebase. In the process, the series has evolved to contain a fairly detailed primer in ColdFusion application architecture (because of it's importance to this process), has currently spanned 8 separate posts, and was even referenced by Sean Corfield in his great presentations on the same topic. 2012 will see the completion of that CF app discussion, and gradually move it back to the MSOC topic itself, as there is still a ton to talk about there, and a lot of interest in the topic. I also began a series on the jqGrid JQuery plugin. jqGrid is another Data Grid visualization tool (I have now written about three, including Ext JS and DataTables), and is a clear choice for those who must use JQuery. (To be fair, JQueryUI is working on a grid component, but they are still behind the curve, and way behind Sencha.) Finally, one common thread seen in the majority of my posts, is how much I've embraced cfscript. I wrote a lot of things, on a variety of topics, but most of my code examples were pure scripted examples.

Now let's talk about some other departures from the norm for Cutter.

You did not see a lot of content around Ext JS. In fact, I stopped writing Ext JS books. This is not, in any way, a reflection on my feelings for Ext JS. I still believe that Sencha has built one of the best client-side libraries for web application development. In evaluating the overall ROI, I realized that I was writing more for the community than the money, and that my reach was greater through my blog, while giving me flexibility on when and what I deliver from a content standpoint. That said, I didn't have a single project this year that used Ext JS, so had very little time to experiment and write about it. This year, I'm going to expand on a personal project, and get back to some great Ext JS content for my readers.

You, also, did not see me speak at any conferences this past year. Nor at any user group meetings. This wasn't because I didn't want to, but because of some more personal reasons. I'm not going to go in depth here, other than to say that I've had some long standing health issues that required me to have some surgery done on my mouth. (Mark Drew is making a joke right now...) Aside from the fact that this has been very costly (chewing up any conference/travel budget), it also meant that my speech has been affected for a good part of the year. Thankfully this experience is (mostly) over now, and I hope to get back to presenting sometime this year. Any user group looking for a speaker this year, please contact me through the Contact link on this blog.

One group I am hoping to speak to this year is the Northeast Florida CFUG. I have to call Mike back, but he's looking to get things kicked off again, and I want to help it be successful. If you're in or around the Jacksonville area, make sure to keep an eye on the site for upcoming events.

One other thing I'm looking to do is to migrate all of my projects into GitHub. I've been using Git at work, and I am loving it, and I think combining GitHub with RIAForge is a great way to promote the terrific technologies we work with every day. I will make the time, I promise.

This comes to the final discussion of this post, Adobe. I again had the pleasure of being an Adobe Community Professional this past year. Due to my health issues, I didn't get to do everything I would've wanted to this year, but I've tried to be a good supporter. There are some fabulous things coming in ColdFusion Zeus and, by extension, to ColdFusion Builder as well. There has been a lot of hub-bub over Adobe's communications flubs regarding Flash, mobile, and Flex. I've avoided much of the discussion, other than to say "be patient and watch". Flash isn't going away, and neither is Flex. HTML 5 is a beautiful thing, if you aren't developing desktop browser applications (i.e. You're only writing for mobile/tablet development). There, that is my whole contribution to that discussion. Give it a rest.

2012 will be a fantastic year. Set yourself some clear, definable goals. Break them down, step by step, and write the steps down on paper. Each successive step, print out in large letters and place it somewhere where you will see it each and every day. Set yourself up to succeed, and you will. Have a great year, everyone, and I can't wait to hear what you have planned for 2012.

Legacy Code and Some Modern Browsers

Working on some legacy code the other day, and came across one that was driving me nuts. I had a form that was part of a tabbed interface, and the form would not submit in Firefox or Chrome. Finally, after some trial and error, I was on a specific tab when I hit submit, and saw the following:

Unable to display content. Adobe Flash is required.

Did you see that? Some kind of form validation. It was odd though, because I didn't see that popup from any other tab, nor did it shift focus to the tab with that field (though focus was on that field). So, I went searching.

After quite a bit of time I found out something even more odd. There was no form validation on that field. Zilch. Nada. What the...? Now I was really stumped.

So, I started looking at the code of the form itself, specifically at that field. Here's what I found:

view plain print about
1<input type="text" name="somefield" required="No">

Like I said, some legacy code. Have you figured it out yet? Here's the deal. This form used to be a cfform, and the original developer had added the required attribute on a cfinput (unnecessarily). At some point, the form was switched over to a standard form, with it's own validation, and the cfinput was switched quickly to an input, without removing the attribute. No big deal, right?

Well, it wasn't a big deal, for a very long time. But, the browsers are updating. They're slowly implementing changes to support html5. And, guess what. There are changes to the input elements for html5. Now you have a required attribute? It will automatically validate that field, with a default message, and stop form processing if the field is empty. Never mind that you've implemented the required attribute incorrectly for html5, it'll still validate it regardless.

Removing the required attribute, which was no longer necessary in our application, resolved the issue.

How 'bout that gotcha?