Legacy Code Part 5: Crossroads

So, you're committed to bringing your legacy ColdFusion app into this century. You've been following along with these posts, and maybe even started to study some of the latest technologies. Now comes the big question. Are you sure?

Hopefully, you know your app. Is it big? Is it small? Are there a large number of sub-applications? I'm not gonna lie to you, there's a lot of work ahead. A lot of it is very tedious and repititive too. Right now, you are at a crossroads. (How fitting that you're here...) You've got a decision to make.

It's time to look at the ROI. How much time, money and effort do you already have in this application? You have to weight the pros and cons of your actions, in relation to the bigger picture. You have a couple of different directions that you can go from here.

You can just rewrite your app from the ground up. If your app isn't that big, this might be a really good opportunity to go ahead and start from scratch. You might decide, at this point, that you want to work on an entirely different tech stack. OK, I can see that there might be real, viable reasons to go that way. That said, I also know the true Rapid Application Development capable with ColdFusion, in the hands of a talented developer, so for me the reasoning to move to something else would have to be overwhelmingly compelling.

You can scrap your app, and replace it with a COTS alternative. This only works if there is a COTS alternative, and even then you have to find a way to handle data migration.

The final option is to refactor. This will typically be slow, requiring you to pick apart your applications, document process and workflow, and truly think about what's going on under the covers. There will be trial and error. Version control branching strategies will become critical. The big advantage here is, you have code, so you have a blueprint for how it was all supposed to work.

So know, going in to this decision, that if you choose this last option you will have a lot of work ahead of you. But, in the end, you should also end up with a well documented application, for which you will know every in-and-out.

So, time to decide. Are you up for the game? Or bowing out? If you're coming back to the table, in my next post we'll really start digging in on "how" to upgrade that legacy app.

This article is the fifth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 4: You Don't Know...

You're bringing your ColdFusion app into this century, but you've never heard of CFC's? Still using third party tags for image manipulation? Didn't know there was scripting? Before you start touching your code, it's time to do some research...

ColdFusion has grown a lot, in the past decade. CFC's help create reusable code, and allow for Object Oriented like architectures. There's built in image manipulation methods, MS Office, Exchange, and Sharepoint integration, native JSON serialization on remote requests, PDF creation and manipulation, and a whole lot more. On top of that, you can script most anything now as well. Take some time to look through the documentation to see some of the new things available for your application.

Speaking of changes, the <center> and <font> tags were deprecated years ago as well. Today, we use HTML markup for data, and CSS for display declaration. Get up to speed on HTML and CSS and JavaScript. You're a web developer, not a process manager. All of this data is useless if the user can't "use" it. Learning these things now will go a long way as you bring your app up-to-date. I bet your SQL server has some upgrades too (like stored procs in MySQL).

The web changes at the speed of light. It can take a lot to keep up, but it's necessary in an environment that never stops growing.

This article is the fourth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 3: The Right Tools

You don't use an butter knife when you need a hatchet, nor a machete when you need a scalpel. When you're bringing Legacy Code out of the Dark Ages, you need the right tools. That old copy of ColdFusion Studio was the bomb in it's day, but it's not working so hot on your new Windows 8.1 laptop. On top of that, it's help dictionary is out of date by about 5 server revisions, and it's never even dreamed of HTML 5.

You need some good tools to resuscitate a dying app, and the first one is a good editor. I personally prefer Adobe ColdFusion Builder, but you could use CF Eclipse or Sublime Text 2. I like an IDE, and love Eclipse for it's plugin architecture, which allows me to handle the majority of my workflow directly in one environment. Others prefer just a text editor, and that's fine too, but at least pick something with code complete and up-to-date dictionary add ons.

Do you use Source Control? Now's the time to learn. The ability to branch, merge, and revert are critical for continuing to maintain a working application at this stage. I've used Subversion in the past, but have come to prefer Git. The learning curve is steep, but the benefits and flexibility are well worth the time investment, especially in a team environment.

Using MS SQL? Then you want the Redgate SQL Toolbelt. This one isn't cheap, but it's well worth the purchase. You can do comparisons of database schemas, source control sql, backup and restore at an object level, document your db, and the compression technology here can save you a bundle in storage costs. And all of that is just scratching the surface.

And when it's really time to dig in, you're going to want FusionReactor. For me, this tool paid for itself in the first five minutes. You can watch every single request that's hitting your app. Track your slowest requests, queries, and more. Get live data on memory utilization. You can setup notifications for different events, and even setup auto recovery scenarios. This is the must have tool when you're modernizing your application.

Finally, if your getting hit with security breaches right now, it'll probably take some time to pay off some of that code debt and get back on track. FuseGuard, from Foundeo, is an easy way to add some badly needed security when you have none. It won't do your work for you, but it can save you a lot of grief while you get it together.

This article is the third in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code Part 2: Getting Started

Your ColdFusion site is crawling. Pages take seconds to render. The DOS attacks from China are taking you down daily. Your boss is crawling up your backside, because clients are running away. And... you're still running ColdFusion 5 and MySQL 3.

Why are you complaining again? Wake Up!

Your problem isn't your platform. It's...your platform. Why would you think that you have to upgrade your desktop software, but not your web platform? Every new iteration of an Operating System becomes (hopefully) a little more performant and a little more secure and (generally) has a few more bells and whistles. So why are you still running IIS on Windows NT?

You want things to get better? Want the boss to stop breathing down your neck? Step 1: Get Current. If you aren't up-to-date, your app will show it's age. We can get wrinkled and put on weight with age, why wouldn't your site?

Give your site a Lifestyle Lift. Get a modern OS, a modern web server, a modern database server, and a modern app server. (And, if you're that far out of date, you probably need some modern equipment too.) No budget for all of this? Consider a hosted VM instance(s), where the host handles the software licensing.

The language has changed/improved, a lot, in the past decade+. So has the server. You can't take advantage of any of these enhancements if your infrastructure is archaic.

Now, all of this being said, you'll want to test your code on a local architecture of the same make up. Chances are that there are minor code changes that you will have to make just to get up and running on "New Stuff". Set yourself up on a local VM, with all the same upgrades (OS, web server, db, etc) and thoroughly test your application. Having trouble? It's worth the time to test and figure it out (or hire a good consultant).

This article is the second in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.

Legacy Code: Coming In To This Century

For more than a decade now, I've made a living upgrading legacy applications. Many times, these are applications originally built on ColdFusion 4 (or even earlier) and never touched again. Some company invested thousands, or even tens of thousands of dollars having an application written, adding to it over and over with time, but never refactoring it for a new age.

This is probably the number one issue with how ColdFusion gets viewed, as a language and a platform, from outside the ColdFusion community. There are these huge applications, written on a platform that has grown and moved on, and that old code just doesn't perform the way they want it to anymore. What was written was probably great, at the time, but now there's millions of database transactions, thousands of concurrent users, and changes to processes in general. That old app just isn't cutting it anymore.

The question that comes up for a company, at this point, is do they rewrite the app? Do they upgrade the app? Or do they replace the app all together? Each of these questions have answers with their own pitfalls, but today many companies are looking at this issue and saying that their problem is ColdFusion, instead of seeing it as their answer.

Here's the bottom line: ColdFusion isn't always the answer to every problem. No more so than .NET is, or PHP, or Ruby, or any other particular language. That said, ColdFusion does have a very large advantage, in that it truly is a Rapid Application Development platform. If you know the language, if you know the server, and if you have a solid plan, it is possible to rapidly change an an application, or write a new one.

With this post, I'm going to start a new series of posts about some of the things that I've found, over the past decade, that can be used to bring a legacy application into a new age. There are a number of things that a company can do to bring new life back to that old and frail beast that used to be their pride and joy. More over, some of the things I'll relate can save a company from unnecessarily spending thousands of dollars in redevelopment when they didn't need to do so.

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...

Skinning Bootstrap Tabs

Bootstrap is the number one downloaded project on GitHub today. A small, lightweight framework for layout, Bootstrap is a combination of CSS, HTML format, and JavaScript that allows one to create very dynamic, responsive web sites and applications. This isn't a new concept, being the same sort of thing that jQueryUI and Ext JS are conceptually designed for. Each has their merits, and differences. Those libraries primarily utilize JavaScript for designing and configuring layouts and components, whereas Bootstrap focuses primarily on HTML and CSS (and a small JS file for event handling) for building these things.

One of the things that sets Bootstrap apart is the ease with which one can "skin" the library. Bootstrap uses LESS for building it's CSS files. LESS allows you to define variables and functions, that are then utilized in style declarations. Once compiled, those variables and functions are parsed in the definitions, to create your CSS. By changing a few variables, you can completely change the look and feel of your application.

In this example, I'm going to change the default Bootstrap tab display. When you see the default Bootstrap tabs, they aren't always easily identified as a tabbed interface, until you mouse over a tab. My clients have become used to the contrast provided by the layouts of the other libraries I've mentioned, having seen those interfaces time and again. Here, we'll update the Bootstrap tabs so that they appear more like those used by jQueryUI.

Basic File Structure

I, personally, don't like to change a libraries files. Even though you can do so, I find it better to create an "override" file that will add or change a definition. That way, if I update that library I'm not trying to find and replicate my changes. First, I start off by organizing my assets. I personally like to separate my CSS from my images from my scripts. I also like to create sub-folders under each, to further organize my assets for easy change, management, and retrieval. From Bootstrap's Getting Started page, I downloaded both the basic download, as well as the "source" download. I moved the .less files out of the css folder in the "source" distribution, placing them in /assets/css/bootstrap. I then moved the .js files out of the js folder in the "basic" distribution, placing them in /assets/js/bootstrap. Last, I took the .png files, out of the img folder in either distro, and put them in to the /assets/img/bootstrap folder. The last thing I'm going to do is create a new sub-folder to the css folder, titled core. Within this folder I'm going to create three files: core.less, overrides.less, and variables.less.

Getting started with LESS

We're going to start off by doing something really simple. First I told you that I didn't want to change the core Bootstrap files, but instead create "overrides". Since we changed the basic file structure of the Bootstrap distro, the first thing we'll need to do is correct the pathing to the image sprites. What we're going to do, rather than including the Bootstrap css directly, is create our own "core" file. "Core" needs to include Bootstrap, and then our overrides. We do this by adding the following lines to our core.less.

view plain print about
1@import "../bootstrap/bootstrap.less";
2
3@import "overrides.less";

These statements will include these two files, when core.less is compiled. If you go back and look at bootstrap.less, you will see that it is nothing but import statements as well.We want to create variables that we might need to reuse elsewhere. This is the general purpose of our variables.less file. If we open Bootstrap's variables.less file (/assets/css/bootstrap), we can search through it and find two specific variables: @iconSpritePath, and @iconWhiteSpritePath. Copy and paste these two lines into our variables.less file, then adjust their paths to coincide with our new file locations.

view plain print about
1// Sprite icons path
2@iconSpritePath: "/assets/img/bootstrap/glyphicons-halflings.png";
3@iconWhiteSpritePath: "/assets/img/bootstrap/glyphicons-halflings-white.png";

Finally, we need to use these updated variables in our overrides.less file, to override the proper style declarations. First we add the import statement that includes our variables.less file. Then, we find the declarations, in the sprites.less file (/assets/css/bootstrap), that currently define these paths (you can search for the variable names). Copy and paste these two declarations into our overrides.less file, and then take out all of the definition items except for those that define the background images. Our override only needs to "override" the background image paths, keeping everthing else.

view plain print about
1@import "variables.less";
2
3/* Icon Sprite Path Overrides */
4[class^="icon-"],
5[class*=" icon-"] {
6 background-image: url("@{iconSpritePath}");
7}
8
9/* White icons with optional class, or on hover/focus/active states of certain elements */
10.icon-white,
11.nav-pills >
.active > a > [class^="icon-"],
12.nav-pills > .active > a > [class*=" icon-"],
13.nav-list > .active > a > [class^="icon-"],
14.nav-list > .active > a > [class*=" icon-"],
15.navbar-inverse .nav > .active > a > [class^="icon-"],
16.navbar-inverse .nav > .active > a > [class*=" icon-"],
17.dropdown-menu > li > a:hover > [class^="icon-"],
18.dropdown-menu > li > a:focus > [class^="icon-"],
19.dropdown-menu > li > a:hover > [class*=" icon-"],
20.dropdown-menu > li > a:focus > [class*=" icon-"],
21.dropdown-menu > .active > a > [class^="icon-"],
22.dropdown-menu > .active > a > [class*=" icon-"],
23.dropdown-submenu:hover > a > [class^="icon-"],
24.dropdown-submenu:focus > a > [class^="icon-"],
25.dropdown-submenu:hover > a > [class*=" icon-"],
26.dropdown-submenu:focus > a > [class*=" icon-"] {
27 background-image: url("@{iconWhiteSpritePath}");
28}

Ok, now that you have the mechanics out of the way, all you need to do is compile your file. If you use a dynamic server side language (ColdFusion for instance), then you might be using an asset management framework that will automatically compile LESS files for you at runtime (I like cfStatic). But, you can always get a standalone compiler that will process your files manually. There are many freeware programs available on the web. I Googled "Windows LESS compiler", and came up with WinLess. I was able to plugin the folder name, select my core.less file (you only need to compile the one, as it includes the rest), and hit "compile" to get my core.css file created.

I unselected the Minify option, so that could see the underlying result in an easy to read format. For production code, I suggest having a minified and unminified version, using the unminified for debugging purposes. If you check your new, unminified core.css file, you can go all the way to the bottom and see your two overriding style declarations, verifying that they now reflect the updated sprite paths.

Creating Tabs

OK, we have the basics out of the way. Now lets make some tabs. First, lets write up an index.html that will be prepared for Bootstrap, using our new all-in-one css file.

view plain print about
1<!DOCTYPE html>
2<html lang="en">
3 <head>
4 <meta charset="utf-8">
5 <title>Bootstrap Themed Nav</title>
6 <meta name="viewport" content="width=device-width, initial-scale=1.0">
7 <meta name="description" content="">
8 <meta name="author" content="">
9 <link href="assets/css/core/core.css" rel="stylesheet">
10 <!-- Le HTML5 shim, for IE6-8 support of HTML5 elements -->
11 <!--[if lt IE 9]>
12 <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
13 <![endif]-->

14 </head>
15 <body>
16 <div class="container">
17
18 </div>
19 <script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
20 <script src="assets/js/bootstrap/bootstrap.min.js"></script>
21 </body>
22</html>

The next thing we need is the proper markup to create a tabbed interface within Bootstrap.

view plain print about
1<ul id="myTab" class="nav nav-tabs">
2 <li class="active"><a data-toggle="tab" href="#home">Home</a></li>
3 <li><a data-toggle="tab" href="#profile">Profile</a></li>
4 <li><a data-toggle="tab" href="#tab3">Tab3</a></li>
5 <li><a data-toggle="tab" href="#tab4">Tab 4</a></li>
6</ul>
7<div id="myTabContent" class="tab-content">
8 <div id="home" class="tab-pane fade active in">
9 ...
10 </div>
11 <div id="profile" class="tab-pane fade">
12 ...
13 </div>
14 <div id="tab3" class="tab-pane fade">
15 ...
16 </div>
17 <div id="tab4" class="tab-pane fade">
18 ...
19 </div>
20</div>

This produces a basic Bootstrap tabbed interface. No additional JavaScript is required here, the base bootstrap.js will handle all the basic event binding necessary for a fully functional interface. But, as you can see, there's not much in the way of contrast, identifying tab separation, nor is your tabbed interface really separated from the rest of your page. What's needed now is to create that contrast and separation.

Skinning Tabs

We'll look to jQueryUI's tab representation, as a guide for how we wish ours to look. We won't get an exact match, but we can get really close. First, let's start with the new stuff. jQueryUI's tab sets have a border around the entire interface, separating the tabs from the rest of page flow. Bootstrap doesn't have this, so we'll make it. We'll add a new div around the nav-tabs unordered list and tab-conent div, and give it a class: nav-tabs-container. Next, we'll add a style declaration to our overrides.less file.

view plain print about
1/* Add a tab container class, for a border around the entire tabset */
2.nav-tabs-container {
3 padding: 3px;
4 border: 1px solid @grayLight;
5 .border-radius(4px);
6}

Here's what we're doing here. We gave the container a 3 pixel padding all the way around. We gave it a one pixel solid light gray border, using the color variable in Bootstrap's variables.less file. Last, we gave it rounded corners with a four pixel radius (for those browsers that support it) by calling on the .border-radius() LESS function that's defined in Bootstrap's mixins.less file.

Our next step is to see what makes jQueryUI's tab interface different. We make a list of the basic elements.

  • The tab bar (ul with a class of nav-tabs) has:
    • a one pixel gray border with rounded corners
    • padding on the left, top, and right of a few pixels
    • a gradient background of a gray that is darker than the tabs
  • The tabs (list item tags containing anchor tags) have:
    • active tab (li with a class of active) has:
      • a white background
      • a one pixel gray border with rounded corners
      • no bottom border
    • inactive tabs (li's without classes) have gray backgrounds, of a lighter gray than the nav-tabs
    • active and inactive tabs have text that is gray

At this point, our next step is to find the original Bootstrap declarations for tabs. These can be found in the navs.less file (/assets/css/bootstrap). Copy and paste these declarations into your overrides.less file. From here, it's a matter of removing lines that won't change, adjusting lines that meet your requirements, and adding any new code needed to finalize those requirements. I'm not going to go over every line of code, instead giving you the full set, but we'll hit the high parts. First, the code:

view plain print about
1/* Tab Theming Overrides */
2// TABS
3// ----
4
5/* Add a tab container class, for a border around the entire tabset */
6.nav-tabs-container {
7 padding: 3px;
8 border: 1px solid @grayLight;
9 .border-radius(4px);
10}
11
12// Give the tabs something to sit on
13.nav-tabs {
14 border: 1px solid @grayLight;
15 padding: 4px 3px 0 3px;
16 margin-bottom: 5px;
17 .border-radius(4px);
18 #gradient >
.vertical(@grayLighter, @grayLight);
19}
20
21// Actual tabs (as links)
22.nav-tabs > li > a {
23 line-height: 10px;
24 background-color: @grayLighter;
25 border: none;
26 outline: 0;
27 &:hover,
28 &:focus {
29 border-style: solid;
30 border-width: 1px 1px 0;
31 border-color: @grayLight @grayLight transparent;
32 }
33 &:link,
34 &:active,
35 &:visited,
36 &:hover,
37 &:focus {
38 color: @gray;
39 }
40}
41
42.nav-tabs > li:not(.active) > a {
43 &:hover,
44 &:focus {
45 padding: 7px 11px;
46 }
47}
48// Active state, and it's :hover/:focus to override normal :hover/:focus
49.nav-tabs > .active > a,
50.nav-tabs > .active > a:hover,
51.nav-tabs > .active > a:focus {
52 border-style: solid;
53 border-width: 1px 1px 0;
54 border-color: @grayLight @grayLight transparent;
55}

We mentioned earlier the use of variables within LESS. Throughout this block of code you will see multiple references to various colors identified in the base Bootstrap variables.less file. We also previously utilized the .border-radius() method from Bootstrap's mixins.less file. We use this again, within this block of code, as well as other mixin methods, such as the .vertical() method we're using in our gradient definition. It's a good idea to look at the mixins.less and variables.less, to get ideas as to what's available to you. You will also notice nested declarations (such as the link psuedo selectors) that will automatically build out with LESS.

That's it! I hope you found this post helpful and informative. Any feedback, please leave me a comment. Here's what I hope you'll takeaway from this post:

  • Bootstrap is a powerful layout framework
  • Bootstrap is easy to modify/skin by making minor modifications using LESS
  • LESS is a great way to create dynamic, adjustable CSS
  • LESS can be a lot of fun

ColdFusion 10 File Uploads and MIME Types

Quick Note: On one project that I'm on, we're in the process of moving from ColdFusion 9 to 10. During some regression testing, one of the testers began receiving errors on file uploads. When looking at the code, I saw this:

view plain print about
1fileUploadResult = fileUpload(arguments.tierCSSDirectory, "header_background_image", "image/*", "overwrite");

Now, I remembered that there were changes to MIME type checking in CF 10, but I wasn't entirely sure. This code, written by one of our developer's several months ago, would allow any "image" MIME type. What we discovered is that we couldn't do this kind of wildcard mapping under CF 10, that we now had to list out each accepted MIME type as a comma delimited list.

Just thought I'd share.

Bootstrap Tree

It'll be a little while before I add this to the projects link on the site, but yesterday I pushed a new project up to GitHub. Bootstrap Tree is a lightweight Tree component, for use with the Bootstrap framework. This is still a work in progress, and very bare bones at the moment, but basically you write some formatted HTML (nested lists with data attributes), include the css and js (very small) and it works. Currently you'll have to download the code for the example, but I welcome any feedback, suggestions, comments, etc.

I can think of several things to add to this project, but what do you look for in a tree component?

ColdFusion Roadmap

Shilpi, the 'Security Czar' of Adobe's ColdFusion Engineering team, recently posted about the Roadmap for future ColdFusion Server Devlopment, post CF 10. This links to an abbreviated set of slides, presented in a PDF document, that layout the focus on next two versions of CF.

There are some things you might easily miss, in reading over the slides. First thing I picked out was in "Splendor"'s Other focus areas section, you see Pluggable Framework mentioned. Hmmmmmm...

Mobile, Social, HTML 5 and the Cloud are big topics here, but I also noted that "Dazzle" has Customizable Enterprise Video Portal mentioned. Interesting...

Another one that's easy to miss? How about the timeline? According to the last slide, "Splendor" looks like a 2013 release, while "Dazzle" is slated for 2014. That's a much more progressive release cycle than we're used to seeing.

The biggest, immediate take away here, is the fact that Adobe is obviously investing time and resources in to continuing to produce and progress the ColdFusion platform. That's a win.

Previous Entries / More Entries