Hating Online Only Help in Creative Suite

Perhaps I'm just getting old and crusty, or perhaps it's just lack of sleep, but I'm really not liking the way the current Creative Suite 4 products go online for help. Seriously, does this content really change so much that having offline help isn't useful? Last time I checked the Dreamweaver documentation hasn't changed all that much since Mx2004.
First of all, fat lot of good it does me when I'm on a laptop on the train. Even if I had a cellular card in my machine, which I don't, would I really want to be wasting my monthly bandwidth allotment, looking up a tag or function that I don't use frequently. Not to mention, that much of my ride is underground and out of cellular range.
My second beef is that Dreamweaver CS 4 help (F1) defaults to the Dreamweaver Support Center rather than the Dreamweaver Documentation. Sure, the link for documentation is there on the right, but it is quite hard to spot. I realize that you can change the default behavior back to point to the documentation, but again, it's not easy to find.
Most likely I'll just download the PDF versions and think very carefully before upgrading in the future. It seems to me that this is yet another case of just because you can do something, doesn't mean you should.
In any event, that's my rant for the day.

Labels: Adobe, Dreamweaver, Flash

posted by Luis - 3 comments

Testing is hard work!

I recently found myself in the beta test group for Tunnels of Doom Reboot. My initial thought was that this would be easy. After all, I do write code for a living. I regularly test my code as well as my colleagues' code. I've spent countless hours of my life playing the original; I know it inside and out. How hard could this be?

Enter a world of fantasy where your instincts and imagination determine your chances of survival. Your journey is about to begin—Prepare yourself.
–Tunnels of Doom Manual

When the beta became available to the testers, I downloaded it, fired it up, and quite frankly had a ball. That day I submitted my first 'bug report' which consisted of a 'bug' that I could not reproduce as well as a handful of usability suggestions. Shortly after that the first status report came out, with a number of reported bugs list, most of which I had seen, but not thought to mention.

My big problem was that I was approaching it like a gamer and not like a tester. While I did not have access to the design spec to confirm behavior against like I normally do, several of the bugs that I failed to report, were pretty obvious. For my part, once I realized my mistake, I fired the application back up and have since delivered the type of bug reports that I want to see when folks are testing my code.

The thing is as web developers we are all very aware of the limitations of web-based applications, and it is easy for us to ignore things that are not easy to fix. We cannot, however, let ourselves become complacent. With the help of newer technologies such as Flex, we are in a position to overcome many of the historical limitations of web-based applications. The challenge is weilding these new technologies appropriately, and freeing ourselves from the limitations and thinking of the past.

Labels: Actionscript, Adobe, AJAX, ColdFusion, Flash, Flex, user interface, web 2.0

posted by Luis - 0 comments

Think More, Code Less

This is the first in what I hope will become a series of posts aimed at beginner and intermediate level web developers. I see it as a venue to share some of the lessons I've learned, and what's worked for me, rather than a definitive development guide.

I've had a quote taped to my door for a few years now, that struck me when I first read it, but didn't really take on any serious meaning until recently.

Code that only you can understand does not make you an advanced coder; code that your grandmother can understand does!
Jeremy Brown - Macromedia Flash MX 2004 ActionScript 2.0 Dictionary

When I initially saw this quote, I took it to mean that I needed to make sure that I wrote clearly and comment things accurately, so that in the future it would be easy to figure out what I had done. Since that time I have slowly come to realize that it means that I need to take the time to think strategically about the code I'm going to write, so that I can keep it as simple and small as possible. All other things being equal, a small amount of code is inherently easier to understand than a large amount of code.

Successfully keeping your codebase as small as possible requires planning up front. Don't get me wrong here, I'm in no way suggesting that one shouldn't prototype. What I'm suggesting is that the prototype should not become the beginning of your codebase. At first glance this might appear to increase your development time, and while this may or may not be true, if done right you will more than make up for this time with ease of maintenance. The key here is doing enough planning to help you steer away from major pitfalls, without boxing yourself in. Your plans, along with any prototypes, should be treated like an artists sketches. They help guide you and prepare you for the final work.

Finally, keep in mind that common sense can be your best asset. I tend to work with Model-Glue for my medium to large scale projects, but I will really think it out before I use it for a small project. It's a question of whether or not the added complexity of a framework will make it easier or more difficult to maintain my project. The answer typically depends on how much I foresee the project growing/changing, and the difficulty of migrating into a framework later if needed. I've even been known to forego CFCs in favor of old school ColdFusion 4 style programming on real simple projects (Typically only if we're talking 1-2 hours of effort and 75 lines of code or less). The point is that you shouldn't be afraid to deviate from "best practices" when the situation warrants, however, when you do it is vitally important to make good notes of what you've done and why you've done it so that the next person that comes along to touch that code, understands what's been done and why.

Labels: Actionscript, Adobe, ColdFusion, Flash, Planning Series

posted by Luis - 0 comments

Gettin' Reorganized

I came back from Vacation a few weeks ago to find out that my department is reorganizing. It's taken a few weeks to find out what exactly that means, but essentially I (and my colleagues) are in the process of deciding to either be full time web developers or move into middleware. It's an interesting decision to make. In my case, most of what I currently work on, falls under the middleware umbrella, but moving over there means probably less coding (at the very least less, ColdFusion coding, probably no Actionscript work, and most certainly no Flex). It would mean, however moving into other interesting things like identity management, and data integration, that would give the reconstituted web development group broader access to interrelated data from various systems. At the moment I'm trying to figure out whether it'll be more interesting enabling this access, or building the mashups that will hopefully be and end result. Decisions, decisions... In any event, I'll either keep this blog Adobe/Web related, or have it removed from MXNA.

Labels: Actionscript, Adobe, ColdFusion, Flash, Flex, mashup, middleware

posted by Luis - 0 comments

Getting Animated

In an attempt to provide some relief for my brain which is quickly frying due to: (in no particular order)

• The extreme heat in the North East
• Being short-staffed at work due to openings, illness, new babies, and vacations
• Trying to learn too many new technologies at once

I've decided to animate my logo. While this may sounds like a simple task, I've decided to do an animated version of the wandering fishbowl using Action Script 2.0. The first question that probably popped into your mind is, "Why? Wouldn't just doing an animated .gif be easier?" The answer is, "Yes, it would be easier". But that's not really the point. The point of this blog is to give me a place to try things out that I've not done before. I started learning Action Script when ColdFusion MX 7 came out because I could forsee a time when Action Script skills would be as important for a CF developer as HTML skills are now. With the recent release of Flex 2, I'm more certain than ever that this will be the case.

Creating an AS version of the logo gives me an opportunity to continue to work on those skills without having to delve in to Flex 2 (yet). Beyond that, I'm thinking that ultimately I'm going to end up with smoother and more randomly animated image than I could using more traditional methods. Time will tell, and I'll post samples as they become available.

Labels: Actionscript, Adobe, Flash

posted by Luis - 0 comments