ColdFusion Beyond

I imagine most of you have heard of Adobe's launch last year of the new "Creative Cloud" (CC) versions of the programs within its Creative Suite (CS) line. When it first came out, I wasn't particularly concerned. I figured it was aimed at specific markets, like big business that might want to have the latest/greatest at all times and could afford the subscription fees. There were rumors at the time that Adobe would go all CC, rumors I tended to write it off as paranoia. Adobe itself made it sound like CC was totally optional and if it wasn't for you, you could continue on with the desktop versions like always.

Suffice to say Adobe lied and I now those owe those folks an apology, so I'm sorry. Yes, Adobe announced at Adobe Max 2013 that it is effectively killing off the CS desktop product line. New versions will only be available from Creative Cloud. If you go to the Adobe CS6 site now now, you see a lovely notice that it's the last of the traditional software versions for any of the creative suite products and encouraging you to "upgrade" to CC, which will essentially be where what would have been CS7 will be released in June (with new, really crappy, barely readable icons, IMHO)

So what is the Creative Cloud thing and what does it really mean? There are lots of myths going around, like that it only runs through your browser, but they are myths.  Despite having "Cloud" in the name, the CC applications are all desktop-run applications. You download and install them the same as you would any of the existing CS 6 stuff. They don't run over the Internet or through your browser or any other such thing (thank goodness). In this regard, they really are no different from the existing CS products.

The big change that is causing lots of uproar (and even a fairly pointless petition) is that you are no longer buying a perpetual license for the applications you are using, instead you are on a month-to-month lease; i.e. it is all subscription-based. While your computer does not have to be online 24/7 for the apps to run, the computer will start prompting you after 30 days of not being able to get online and kill the software after 90 if it can't check the license periodically. On the good side, you can now use your "license" for two computers regardless of OS, versus the old license which only allowed for two computers with the same OS. You also get all upgrades/updates/etc as desired, without extra cost and can easily sync settings and even share files across multiple systems. Having CC is essentially like having the Master Collection of CS6 with some perks, like the option to have files on the cloud that can be accessed from all your comps, and access to a few non-CS apps, like Muse and their iPhone app Kuler, and features like the Behance collaborative social network.

Still, the subscription-based methodology isn't cheap. For an individual subscription, it runs $49.99/mth or $599.88/year to have access to all applications on Creative Cloud. If you already have any CS3 or above product, it drops to $29.99 for the first year ($359.88) or you can choose to subscription to individual apps for $19.99/mth/app ($239.88/yr/app). If you qualify for an educational discount, that $49.99/mth also drops to $19.99/mth.

Now, I use currently three applications from the CS suite with any regularity: Dreamweaver, Fireworks, and PhotoShop. I qualify for the educational discount through my job, so I'd be paying $239.88/yr on CC. The normal retail price for the Master Collection with educational discount is $999.99 (I've always said, Adobe does do some darn generous educational discounts). It would take just over 4 years of using CC before I start paying above what I'd have paid retail.  Without the educational discount, the Master Collection retails at $2599.99, so again just over 4 years before the CC subscription goes beyond the outright price. 

For students who only really need it for 1-2 years or even just a semester for classes, it is an awesome deal, much like text book rental versus buying.  If you are someone who has to upgrade every year, it really isn't a bad deal.  Presuming Adobe keeps up with their hype, you'll be on the next versions of all your apps (if you want) before you've "fully" paid for the current one you're on.

For business and organizations who do not qualify for educational discounts, the team pricing of $69.99/mth/person is still fairly good, as it is still 3 years before you meet the outright purchasing cost, per person. There is an educational team discount (though it is buried in the site and not easily findable on the main price chart), which bring it's down to $39.99/mth.  So $479.88/person/year - so only 2 years.  Many such insitutions, being non-profit with limited budgets, are more inclined to wait 3-4 years to upgrade, so that significantly more expensive. True, they can just do individual licenses for way less, but they it forces them to forgo the "team membership" benefits like extra storage, centralized deployment, easier seat reassignment, and 2 one-on-one consultations per person per year.

And if you only needed a few of the applications, you likely wouldn't buy the Master Collection to begin with. It would be like buying a Hummer to transport you and a mouse. More likely you'd get Design Premium, Web Premium, or Design & Web Premium, all of which are much less expensive.  So that 4 years of "cost recover" drops to around 2-3 years, depending on which one you would have usually purchased. And none of that takes into account the discounts you'd get upgrading from an older version to a new, versus buying full retail, when you upgrade.

For me, access to their high end video stuff without buying Master Collection would be a nice perk as I've always wanted to dabble in it.  But if I was buying my software stuff myself versus it being employer supplied, I sure wouldn't be upgrading every 3-4 years and I wouldn't be using FIreworks or Photoshop, I'd have just gotten Dreamweaver.  And I'd run it into the ground until it just can't run on my system anymore or no longer meets my needs, like I do most anything else. I use Quicken 2007 because it works - no reason to pay $50-100 for the newest version when the current works just fine. No, I can't download bank stuff anymore, but I couldn't in older versions either and I pay more attention when I have to reconcile myself.  I run Office 2003 because it works perfectly for my needs as is (plus I abhor that ribbon crap with a passion that was shoved into Office 2007 and up).

For folks, like my photography loving sweetie, who primarily just needs PhotoShop for photo editing and only upgrades very 5-10 years, CC is insanely expensive versus buying the retail version: $1,199.40-$2,398.80 over the course of those 5-10 years versus $699.99 for full retail or $199 for upgrading from an older CS edition. It cost less to upgrade previous CS editions than he'd have to pay for a single year on CC! And, for the most part, the software is good to go out of the box unless, again, you do an OS upgrade that can't run it, or for PhotoShop, when it can't handle the RAWs if you upgrade to a new camera.

There is also no guarantee the monthly prices won't start going up once they stop shipping CS6; their license only guarantees your price is fixed for the term of each annual commitment.  Considering Adobe already did a switcheroo regarding CC, I'm not particularly inclined to trust them saying that ever version of every app that goes on CC will always be available/usable.  Nor do I trust their saying you'll never be forced to upgrade.

If an updated version no longer meets your needs or works for your system, you could find yourself out in the cold.  Adobe could decide to ax a product all together and you'll be stuck trying to make your new versions backwards compatible with whatever older traditional desktop version you can find. And if Adobe goes belly up one day, you're stuck with hundreds, maybe thousands, of proprietary formatted files for apps like PhotoShop that will be rendered completely useless because that cloud-based subscription app will commit suicide 90 days after the server goes offline. In short, they offer consumers no exit strategy at all.  If you don't want to subscribe anymore, then all those proprietary files are useless! Yes, the PSD format is publically documented, but what about the rest? And what programs can really read and write them reliably besides PhotoShop?

The only bit of really good news, for me, is that not all of their products are going to the Creative Cloud model, like Lightroom.  At least, not for now.  For Adobe, the "foreseeable future" could just mean until the end of the year and they change their mind to go 100% subscription-based on that as well. As for me, I'll be sticking with CS 5.5 until I'm forced to upgrade my systems to a new OS or the like and it all just dies, and I'll be making a dozen back up copies of the installation download until then, just in case.  And when that day comes, that will be it for me with Adobe and the CS line.  Likewise, if my Dreamwaever CS 5.5 becomes too outdated to use, I guess I'll be trying out some of those IDEs mentioned in a previous post. Until then, I'm certainly no longer inclined to recommend anything from the Creative Suite/CC line, even though Adobe has long been the "boss" for image and video editing for as long as I can remember. 

To me, Adobe seems to be sending a clear message that they no longer want "lay", casual, hobbyist, or new users, only big, high budget organizations/companies or folks with money to burn that can afford a subscription-based plan (or who don't do the full math and just look at the "low" monthly fee).  They realize they are the best of the best and want to milk users for all they have got, confident in the lack of alternatives for many of their products.  Sadly, they are right, though maybe the advent of the Creative Cloud will be enough to get some new names out there trying to pick up those left behind.

As for Lightroom, I'm currently running version 3. Regardless of Adobe's new moves, I still love it, just like I still love Dreamweaver.  Fortunately, for me I don't have to have "shiny and new" all the time...my software and things don't stop serving my needs just because a new version came out.  And Lightroom 3 works great for me as is.  I'm not adverse to upgrading to 5 when it comes out, so long as it isn't butched to CC, for the improvements to the editing tools and being able to make videos from stills (versus having to dump them over to move maker), but I can also just live with 3 until I just can't run it anymore. Unlike Dreamweaver, the only threat to it getting out dated is if I get a shiny new camera that has a RAW format not supported by the software (which is unlikely - my camera also works just fine).  And it will be the one Adobe product I'll still recommend it, 'cause it rocks, but those recommendations will come with a caveat about Adobe's new business model.

That's my three pages or so of rambling about CC…how about you?  Do you love it, hate it, or somewhere in the middle?

I love Google Reader, especially combined with iGoogle, as it allowed me to easily track new posts on the various blogs of interest to me in a nice compact format that remembers what I've read or not read. If the title is interesting, I can click it to open in a new window and all good. And the "mark all as read" feature is nice as well. And all accessible from any computer where I was logged into my Google account. Alas, as most of you probably know by now, Google is killing off Reader due to "not enough users" at the end of June. iGoogle is also dying, but not till the end of November (even though it's demise was announced last year...Google's scheduling is odd...).

My Google Reader in iGoogle - nice, simple, clean

This left me trying to find a replacement. Most of what is out there in terms of RSS feed readers are just not how I want to see stuff. Magazine layout? No thank you! Categories, clouds, tags, what have you...no, a single, simple list is fine, thanks. Desktop based? No, I need to be able to access/read from multiple computers, multiple browsers on those computers, and if I can do it from my iPad cool (though I rarely do that one, so if not, I don't care). I saw various names floating around in all the news reports about Reader's shut for down for viable options, but none appealed to me.

I've also seen some folks loudly proclaiming those who use RSS are just "old fashioned" and they wouldn't miss it at all cause they have Twitter or whatever to find stuff. For my more polite response to that view, many of the blogs I read are smaller ones, not big mainstream company things, so they don't do Twitter posts for every update, and frankly I HATE Twitter. I won't use it, I won't even read it most of the time. So no, that isn't an option. And I'm not trying to "find" stuff, RSS feed consumption is generally for tracking what's already been located. Sites I found interesting that have regular (or irregular) content updates that I want to know about.

Anyway, in disgust I'd pretty much decided I was just going to build my own, then I don't have to deal with shut downs anymore. But time is starting to run short and my "to do" list in terms of personal projects is as long as it was back in January. After reading a bit more about it, I finally decided that, for now at least, I'll switch to Feedly. I'd rejected it at first because of their pushing the whole magazine format, but I have since learned I can pretty much get a layout similar to Google Reader via iGoogle if I desire.

I went to the site and hit the "Get Feedly for Chrome" which popped in a quick plug in. No problem there. When it was done, it took me to a page with a button to connect to Google Reader, so I hit that. Moments later, wee, I have my Feedly account and some feeds. At first I was really confused, since it seemed like it had only picked up 3 of the 42 feeds I follow, but after more hunting around I found the full list of feeds it had pulled in, which was correct. So yay. It does offer categorization, but I'm just leaving all my uncategorized since I don't care about that right now.

After playing with the settings and turning off most of the "enhanced" features and switching up the themes a bit, it's usable and will certainly suffice for my needs. It does have some odd quirks, though. For example, on the All/Index pages, you can switch up the views between "Title Only", "Magazine", "Card", and "Full Article". For most of the views, the content loads in the main part of the site design, which seems to be fixed width. However, when I go to Title View, i.e. the one like Google Reader that I am going to use, it switches to a percentage-based design and the main content window stretches to full the browser window. For context, I have Chrome on my second monitor on the computer I'm on now, which is at a1920x1080 resolution and I have my browser maximized. I can live with it, though the sudden shift is a little visually disconcerting when literally every other aspect of the site is fixed at the same width, but it just seems like an odd thing to do for a list of text titles, but not for the image glutted magazine view, for example.

Also, if you resize the browser window down "too much", the whole left side menu vanished behind a little button, then pops up on mouse over as an overlay on top of the content. I hate that kind of thing, but I'm guessing they are using a "responsive design" to work with mobile devices (though really, resized down to 1076x736 is considered too small?). Again, it's tolerable since I always have my window maximized anyway.

One aspect that made me laugh out loud was the one setting asks if you want a "Giant Mark As Read" button to show at the bottom of the feed. I was like, "sure", figuring it would be a button or something. But man, when they say Giant, they meant it! Gave me a laugh and hey, can't say I can't see it :-)

"Mark as Read" button - browser window is cropped a little, but suffice to say, that is GIANT! Otherwise, close enough to what I'm used to.

I do have concerns, of course. Feedly is itself just a wrapper for Google Reader via the API. They are working on their own server-based implementation that will supposedly result in a "seamless" transition when Google Reader shuts down. If they are delayed, something borks, whatever, then I'm guessing it will just go away. The company that built it sounds confident though, and of the options I've seen it's the closest to what I want, so for now I'll take the risk. There is also the bigger risk that now that Reader is dead, and many users are switching over to Feedly, they will decide to go from free to $$.  In deed, after I wrote most of this post, they added a survey about how much they should charge for it. *sigh* 

Suffice to say, I've made a back up of my feed list from Google, just in case, though.  I mean, I can live with losing my "what's been read" data, but I would hate to lose the list of feeds. And, until it is dead, I'll probably just keep using my iGoogle + Reader for my primary checking of my feeds.

P.S. When you click the "Get Feedly for Chrome" button, you get the Chrome App.  There is also a Feedly Extension, if you prefer it (like me). Just search for Feedly and look for the Extension that is from Feedly itself.

Back when I was first learning web design, you generally sliced up large images into multiple files because it was believed it resulted in a faster loading time. These days the rule is just the opposite - fewer images, JavaScript files, and CSS files can improve loading performance quite a bit. With JS and CSS, of course, you can combine and minify your JS to reduce the number of files, and thus the number of server calls. But what about those images, especially in an icon rich site?

Enter sprites! Now I fully admit, sprites is something I just kind of "oh yeah, those" for quite awhile. I had exposure to them because jQueryUI makes excellent use of them in their themes, but I didn't really look at them until today as we explored ways to optimize a slow loading page - a page with 137 table rows, each with 6 icons, plus there were 3 more icons above. I decided it was time to get off my lazy duff and look into this whole sprite thing more.

I guess the first question is figuring out just what a "sprite" is? Basically it's a single image made up of a bunch of individual images. Since it's one file and one image, it is only a single file to download to your browser and a single server request. It can save bandwidth and loading time. You then use CSS to only show the image desired where we need it to go. While they can be a bit tricky, from my understanding, for repeating backgrounds, they are ideal for things like icons! So instead of calling individual images, you might have this in your HTML for one of your icons:

<img class="home" src="img_trans.gif" />

And this in your CSS:

img.home {

width: 46px;

height: 44px;

background: url(img_navsprites.gif) 0 0;

}

To start, of course, we had to make our sprite image. But that required starting with optimizing our images a bit. We were doing another "old school" trick - having on image of the largest size and just resizing it on call as needed. So all of our icons were at 128x128, even though we actually never used it at any size larger than 30. So I replaced our oversized graphics with the larger ones. Now using a sprite does mean you can't resize on the fly, so for the one image we used at two different sizes, I had to make sure we had two different copies, one at each size, to go into my sprite image.

With that done, it was time to combine them...that sounds kinda of a pain, ya know? And then I have to write all the CSS to position each one? Or not. There are plenty of tools out there now to help do it for you, so it isn't nearly the aggrevation it was in the beginning! The one I ended up using came highly recommended from a few different articles on sprites, SpritePad from KISS. It was fast, easy to use, worked perfectly, and you can download the resulting image and CSS all you want. In particular, I like that it names your new classes the same as your image name - makes search/replacing SO much easier!! Oh, and its FREE! I do like that word! With the free version, you can have up to two sprites saved at a time. The paid version allows for unlimited space, team collaboration/sharing, and using an auto alignment tool.

Once I had my new sprite and the CSS, it was just a matter of going through the code and updating it to use the new sprite. In our case, instead of just throwing all of the individual sprites into a selector for the background, I made it it's own class.  So in my HTML I have something like this for our calendar icon (obviously with appropriate ALT and TITLE attributes):

<img src="/includes/images/spacer.gif" class="calendar spritedIcon" />

and this in the CSS:

.spritedIcon {

    background: url('/images/conferenceServicesIcons.png') no-repeat;

    padding: 0px !important;

}



.calendar {

    background-position: -364px -215px;

    width: 32px;

    height: 32px;

}

It took about four hours, though it probably would have only taken two or so if we'd done it all first, then checked, versus checking while we went along. It also would have gone a little faster if we'd been more consistent with our img tag attribute ordering LOL. In the end, we went from 55 individual icons to a single tidy sprite.

Once it was all in, we just had to do a little tweaking. For example, we had some places we used padding with our icons. This didn't work with the sprite ones as it resulted in other icons "peeking" in, so we had to adjust our CSS a bit. There were also a few places I had to go clean up issues from my search/replace resulting in a double "class" attribute on my image tags. And after I had made my sprite, I stumbled on six icons that we used at a 48x48, not just our 32x32 size. Fortunately, since I used SpritePad, I just pulled up my saved sprite, added the new sizes of those images, and was good to go.

There seem to be two general schools of thoughts regarding sprites, either implementing them as you go, or doing it at the end when your site is getting its final polish. We obviously did the latter and I'm still not sure which would be easier over all. We did have some icon changes throughout the project, but updating was just a matter of updating the sprite image file and the relevant CSS - since SpritePad generated all that for me, it wasn't a huge deal. I suspect if we'd done sprites from the get go, the overhead of dealing with the icon changes would have added up to less time spent than the four hours it took to convert to it. We'll probably find out on our next project.

Meanwhile, yay to our first app that will be utilizing sprites we implemented (versus just coming with something like the jQueryUI ones).

There are times when I envy web app developers who don't have to deal with much on the UI end because they have other people in their departments/organizations that deal with it. Alas, in our small shop, we code the apps and we have to do all the UI stuff, with most of the CSS/layout stuff falling on me because of the two of us, I hate it less so I'm overall stronger in it. But days like today make me want to scream!

Getting close to launching a new app, so doing some internal testing and checking pages, especially the public facing sites, in Firefox, IE, and Chrome. After about an hour or so, all I'd found so far as a little border issue that showed in incorrectly displayed in Chrome that was easily fixed. And then I got to the very last page I had to test for the public site (seriously) and discovered a joyful little bug in IE that has had me googling, unsuccessfully, for a solution for the last two hours. Plenty of hits, but no fixes.

See, IE 8 and 9 have a bug that causes them to change all of the items in an ordered list to "0" if the list is within a DIV that is hidden then "displayed", as happens when using jQuery UI tabs.

How the list should (and does) look - in everything but IE

How the list actually looks in IE 9

If you take the list out of the tab, it works perfectly:

This is a known bug in these two versions of IE, that is supposedly fixed in IE 10, but by our standards we must also code to support 8 and 9. My googling found lots of bemoaning about the issue, but thus far, no actual solutions. The "empty div" after the list trick didn't work, nor did the "counter-reset" trick or the CSS trick posted over on jQuery UI's bug reports. I've seen some posts talk about it being an issue with using width or the like in the list's CSS, but we aren't doing that. The list isn't really styled at all. It's just a basic list plopped into a tab. It doesn't help that many of the "problem" forum posts get boiled down to "it's not a bug with our product but IE, so discussion doesn't belong here" or dissolves into code critique that point out other issues but not the ones that are actually giving a work around for the real, known bug.

For ideas I came up with, I tried the well known CSS "fix" for tabs to push them off screen instead of using the usual method of hiding (oft employed when you have dynamic stuff in tabs that borks), but IE was not fooled. I also tried adding an extra item to the list and removing it when the FAQ tab was activated, hoping it would trigger IE to "recount" the list, but nope, it did not work.

So far, the only "solution" I've found that works, besides just not using IE, is to just not use an ordered list and to manually put the numbers in, but of course it looks off as the text doesn't nicely align to the left, instead the text items wrap under the numbers if they are long enough to wrap (which several will be). The alternative is, of course, to just not use an ordered list at all, which may end up being the solution we go with, pending client approval, of course.

In one of our applications, we have a couple of "core views", i.e. view stuff that is used in a couple different places, so we have it in one tidy CFM for easier maintenance. For most of them, the content coming in is the same or similar in nature, however we have one where they are not quite the same. With our registration view, the populating object (a "bean") could be a "real" registration object, with a full set of methods, or it could be a "pending" registration object, which has a slightly smaller set of methods.

When we first built the view, it wasn't really an issue because the methods that only a real registration would have were also only called on when certain flags were in place, which were never set for a pending registration. Then we added a new bit to the view, which isn't limited by the flags, whether or not it was a "transferred" registration. This caused us to start getting system errors when trying to view a pending object using this view. We could have just made yet another flag, but I figured there had to be a way to just say "hey, if you don't have the method getPreviousRegistration, skip this bit".

Well, we have IsDefined, but that just got us an error that the method wasn't found (well duh, that's why I asked you!). I could just wrap it in a try/catch, but then I'd have to deal with trying to filter out this fake error from real ones, and that really doesn't match how I like to code. So I Google'd around for "ColdFusion function exists". To my surprise, I found almost nothing, beyond a very brief thread on Adobe (2 posts) with an "answer" that lacked any details.

The brief answer did give me a starting point, though, so I decided to expand on it here in case anyone else finds themselves wondering hwo to do it. Basically, you can do this using a combination of StructFindValue and getMetaData. StructKeyExists doesn't work, at least the way I solved this, because the function names in getMetaData aren't set as keys, but rather values. So the resulting bit that went into my CFIF?

ArrayLen(StructFindValue(getMetaData(bRegistration), "getPreviousRegistration")) GT 0

If the function is there, you'll have a populated there. If it isn't, you'll have an empty array. It may not be the most "elegant" of solutions with the multiple nested functions, but it works and it is working well. So if anyone else wants to test for a function's existence, here is one way to do it. If you can think of some others, by all means share so that next time someone Google's the question, they get some hits! ;-)

Update 4/17/13 @ 7:45 am: Thanks to Aaron who showed me how StructKeyExists can work in this case, if you skip all the MetaData stuff.  So now we have a cleaner bit of code:

StructKeyExists(bRegistration, "getPreviousRegistration")

I didn't even think to try it cause I was stuck on the idea that "it's an object", forgetting that often for ColdFusion, they can be treated similarly :)