Like many folks, I wasn't fortunate enough to be able to attend MAX this year, but thru the magic of the interwebs we were all able to "listen in" on today's keynote.

Some interesting information about FlexBuilder and Dreamweaver... but the big news for me, as well as a lot of ColdFusion developers, was the announcement of Bolt, a new Eclipse-based ColdFusion IDE.

There is not a lot of information available yet. The product isn't available for download. The best you can do is sign up for Adobe's prerelease program at http://www.adobe.com/go/boltprerelease. What little information there is can be found at http://labs.adobe.com/wiki/index.php/Bolt.

Looking forward to hearing more about Bolt as information becomes available, as well as eventually test-driving a beta.

PS - Yes, I'm aware that the Bolt image above isn't the ColdFusion IDE Bolt. Best I could do for now. Hopefully Disney doesn't sue. :)

UPDATE: via Kristen Schofield's blog, what I assume to be the actual Bolt logo:

At Amcom we're huge fans of maximum resolution and minimum font sizes, and apparently I wasn't fully maxing out on this capability.

I noticed that one of our guys (Charlie) was coding with the Consolas 8pt font, but when I used it, it was blurry.

Turns out the trick is to enable ClearType - which isn't on by default. If you're a fan of the ultra-small fonts, make sure to enable ClearType and try the Consolas font at 8pt.

This is one of those entries that's kind of embarrassing to write, because I'd like to think that after doing this for as long as I have, it wouldn't have been an issue that stumped me for an hour. But it did. And I'd like to think that it may potentially stump somebody else, so let's get it out in the open and try to save somebody else an hour.

I had data that related to 3 distinct entities. Let's say those entities were representations of an employee (a nice textbook-ish example). Employees have names, phone numbers, and departments. I want to store that information in a structure for each employee, and put each structure into an array. Here's how I went about doing that:

<cfscript>
	employees		= arrayNew(1);
	employeeStruct	= structNew();
	// populate employeeStruct, append to array
	employeeStruct.name		= "Bob Smith";
	employeeStruct.phone	= "800.555.1212";
	employeeStruct.dept		= "Marketing";
	arrayAppend(employees, employeeStruct);
	// populate employeeStruct, append to array
	employeeStruct.name		= "John Jones";
	employeeStruct.phone	= "800.555.1313";
	employeeStruct.dept		= "HR";
	arrayAppend(employees, employeeStruct);
	// populate employeeStruct, append to array
	employeeStruct.name		= "Frank Wilson";
	employeeStruct.phone	= "800.555.1414";
	employeeStruct.dept		= "IT";
	arrayAppend(employees, employeeStruct);
</cfscript>

[More]

Few companies/organizations have made much of an effort to cater to the mobile use case, let alone specifically support it.

Dev teams may have dabbled with it, but the reality is the demand from users (traffic wise) wasn't there, and from an ROI perspective the return didn't justify spending much QA time testing it, let alone developing views optimized for low resolutions.

The traffic (as a percentage of overall traffic) still isn't there, but we're starting to see end users beginning to experiment more with what they can do with their mobile devices. Obviously iPhone opened up playing field, and as the next gen Palm, BlackBerry, HTC, and Android devices grab market share we're seeing users give them a try with our online web applications.

Assuming mobile traffic becomes substantial enough to warrant catering to this use case, how does that affect the SDLC?

From a development perspective, this is where your efforts in MVC are going to pay off as you focus on building different mobile views.

As for the testing portion of development, and QA itself, obviously these are tremendously impacted. I'd expect to see test automation tools that can simulate different devices, OS's, and browsers. Similarly emulation tools that show you what it would look like on such a device; without it you'd need to buy all the devices you support, and they're coming in over public internet which typically your Dev and QA environments aren't exposed to.

It's still a ways to go before these become a serious challenge that Dev teams need to deal with, but as it ramps up over the next few years and it'll be interesting to see how teams and tools adapt.

We love SeeFusion - its been a life safer in helping isolate slow running pages and queries.

But when CPU/Memory is totally pegged on the server its Flex interface may not load. As an alternative you can load it's HTML only interface which gives you a chance to spot the offending page/query.

To do this add /html to the SeeFusion URL. E.g instead of http://machine:8999, use http://machine:8999/html.

You can also kill a process from this page, but when it does that it'll redirect you back to the Flex interface. If it's still not loading, just go back manually to the HTML page to see if the process has been killed.

When killing processes with SeeFusion, you may need to do it a few times. The first attempts will try to do it gracefully, whereas subsequent attempts will try a hard kill.

In an ongoing effort to put together our development standards at Amcom, we're currently researching AJAX/JS frameworks. The choices have been essentially narrowed down to Spry or jQuery.

I haven't done a considerable amount of work with either, but my personal preference leans towards jQuery. I'm more familiar with it than Spry (while I haven't really gotten my hands too dirty with it, I've used a number of jQuery plugins), and being someone who likes JavaScript I'm comfortable with the syntax.

The boss, however, being a big Flex guy, really gravitates towards the Spry syntax, as it's more familiar to him. The boss, being a fair and noble kind of boss (yes, he reads the blog), told me to go out and do an objective analysis of the two and see if one comes out significantly ahead of the other.

I built a few demo apps using each (http://amcomtech.net/labs/ajaxframeworks/) and from a technical perspective I have to admit, it's still kind of a tie.

[More]

One of our client web sites allows users to generate custom marketing materials and save them as PDF files. We had a request yesterday to allow users to save these PDFs as images so that they could embed them directly into e-mails, as opposed to sending as attachments. Sounded like a job for some of the new image manipulation capabilities of ColdFusion 8. I'd not yet had the opportunity to play around with this new functionality, so I was looking forward to it.

At first, I thought it was going to be as easy as using <cfpdf> with the "thumbnail" action. The hitch that I ran into was that some of the PDFs are multiple pages, and <cfpdf action="thumbnail"> generates a thumbnail image for each page. So the challenge was combining each of those individual thumbnails into a single image file. That's where I really got to get my hands dirty with the new built-in image functions. Here's what I came up with (breakdown follows the code):

[More]

In my travels I've found that business folk are anxious to emphasize content to help ensure that the reader not only notices the content, but feels engaged to read it all, and retain it.

Fair enough, but the problem is in the implementation. The instinct is to start off with a heavy approach using heavy weighted and large fonts with high contrasting colors.

This initially may work, but probably not. The problem is that the mind can only pick up so much loudness before it instinctually tunes it out.

Even outside of UI this is true. For example they studied NY subway riders, and those starting off from the far suburbs started off their trip being cognizant of those around them, making eye contact, nodding hello and all that... But as more riders got on, they progressively shut down.

Once the brain feels there's too much information to track, it changes gears to a broader level in order to compensate.

Going back to UI, now that you've zoned out the user, in order to draw attention to new or important information you have to make dramatic changes to that text (even larger fonts, louder colors, etc...). For example:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec quis ante. Suspendisse vitae velit ut nibh lobortis convallis. In rutrum venenatis leo. Aliquam id libero. Suspendisse augue. Nulla facilisi. Nulla facilisi. Cras vulputate tempor lectus. Ut viverra risus non eros. Nam sit amet turpis eget arcu mollis cursus. Quisque ante lectus, gravida quis, laoreet ut, mollis sit amet, sem. Aenean blandit pede a tellus. In enim. Curabitur felis. Morbi et lectus.

It's a slippery slope you don't want to go down, and it looks unprofessional at the same time. Instead, give the user some credit. The brain does a good job of picking up subtle changes. For example I'll take the same text and gear down the intensity big time, while using incremental changes in font family, style, weight, and color.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec quis ante. Suspendisse vitae velit ut nibh lobortis convallis. In rutrum venenatis leo. Aliquam id libero. Suspendisse augue. Nulla facilisi. Nulla facilisi. Cras vulputate tempor lectus. Ut viverra risus non eros. Nam sit amet turpis eget arcu mollis cursus. Quisque ante lectus, gravida quis, laoreet ut, mollis sit amet, sem. Aenean blandit pede a tellus. In enim. Curabitur felis. Morbi et lectus.

The purpose of the above is just to demonstrate that your eye did catch the four types changes. But in actuality, you'd limit yourself even further by just sticking to as few callout styles as possible to highlight certain content. Because again, even if you stick with subtle changes, if you have too many different subtle changes you're back into too-much-information-to-process land.

The bottom line is that you can get away with adding only an incremental amount of new information (i.e. style, color, and weight), and have a better chance of having the user notice and absorb the content.

The other day I had a client call about a bug in an application that we had released a few weeks back. This particular piece of the application allows users to import an Excel spreadsheet, which is parsed and inserted into a database. The reported bug was that the user (apparently) successfully imported their .xls file (no errors were reported by the system), but the records didn't show up in subsequent searches. Hmm....

The majority of the import happens within a single method. At the top of the method, I declare a variable to hold any potential error messages... initially set to an empty string:

<cfset var insertErrorMsg = "" />

Further down in the method, the actual SQL INSERT is done within a <cftry> block. actually, it's a number of INSERTs done inside of a <cfloop>. after each INSERT, i have the following <cfcatch>:

<cfcatch type="database">
	<cfset insertErrorMsg = cfcatch.detail />
	<cfbreak />
</cfcatch>

At the end of the method, if the length of the value of the insertErrorMsg variable is 0, I assume all is well and indicate to the user that their import was successful.

In this case, however, all was not well. Something went horribly, horribly wrong and under a specific set of circumstances (which I later identified), a specific variable that was intended to be an integer was sent into the method as an empty string. ColdFusion would error with Invalid data '' for CFSQLTYPE CF_SQL_INTEGER. Why then, wasn't my bulletproof error handling working? I added a <cfmail> to the <cfcatch> with a dump of the <cfcatch> scope:

Note the empty string for the detail key. Yeah, I know. So there were any number of easy fixes that could have been done (using the cfcatch.message string, or incrementing an errorCount variable that's initially set to zero). It's not so much about the solution as it is about the problem. This isn't one that I would have anticipated. Thought it was worthwhile to throw out there in case others may be using, or considering using, similar conditional logic.

Here at Amcom we're starting to formalize our coding processes, which includes coding standards, tools, etc. While I don't think we'd ever mandate the use of a specific IDE (as long as the final code adheres to the agreed upon standards, it's not really important how it was created), we find that we keep coming back to Eclipse.

We've discussed unit testing and MXUnit (Eclipse plugin). We've discussed the CF8 debugger (Eclipse plugin). We've decided to use the ColdBox framework (which has Eclipse plugins). We do a good amount of Flex work (FlexBuilder being available as a standalone Eclipse product or as an Eclipse plugin). And of course, as a ColdFusion shop, there's CFEclipse (Eclipse plugin).

A few of us have been using Eclipse (and various plugins) for a while, but some have yet to make the leap. I recalled my first efforts to make the switch from HomeSite+ (previously ColdFusion Studio) to Eclipse, and some of the challenges that I faced.

I was a bit overwhelmed at some of the terminology like "Perspective" and "View" and don't even get me started on the concept of a "Project". It took me a good couple of tries switching back and forth between Eclipse and HS+ before I was truly comfortable developing in the Eclipse environment. I put together a document that was intended to be used internally to help demystify Eclipse as an IDE. At this point it's pretty basic and a work in progress. But it was suggested that it might have some value to the community, and might help others that are considering making the switch but having a hard time mentally reconciling the Eclipse environment versus their current environment. I've attached a pdf to this entry, available at the "Download" link below.

If anyone finds this to be useful, please let me know and perhaps I'll flesh it out a bit more. If there's anything in the document that needs further clarification or correction, please bring that to my attention as well.