Updates to Komodo Edit/IDE Color Schemes

Spurred by a request from an interested Komodo user, I've finally started working on updating my color schemes for ActiveState's Komodo Edit/IDE. I'm generally pleased with the initial results, having started with Solaron-Light (based in large part on Ethan Schoonover's Solarized palette, but with some intentional tweaking).

Solaron-Light Komodo color scheme, updated to include Komodo UI

Adobe ColdFusion Docs team, there's a better way...

I'm not a fan of the approach the Adobe ColdFusion (ACF) documentation team has moved to with documentation for the recent versions of their product.

A bit of background

With the recent (late May 2014) release of ACFv11, there are now three versions of ACF in which I have varying degrees of interest: 

• v9: we are in the final stages of moving our last app from a shared v9 server to one of our dedicated v10 servers,
• v10: our entire dev environment is based on v10, and all of our apps with the noted exception above run on v10 in production, and
• v11: the recent release we've watched from a distance as we weigh whether to continue with ACF in the future or shift to Railo as our CFML engine.

As a team, we've been on ACF since its Allaire v4 days, and have historically had multiple versions in play across our development and production environments, so the above situation covering three versions is very typical for us. In fact, having all of our dev and production environments based on a single version of ACF as we (almost) do now represents the first time in close to 10 years we've been able to achieve this. I don't believe we are unique in this: any developer moving between versions of the product (or even considering such a migration) will be working with at least two versions of the language and/or the documentation before and during their migration effort.

In addition, I built and continue to maintain a CFML language mode for ActiveState's Komodo IDE and Edit editors, providing syntax highlighting and tag/tag attribute completion. The tag/tag attribute completion is specific to each CFML version, allowing the user to designate which version of the language is to be used as the basis for which tags and which attributes are to be provided as options to the user. I rely heavily on version-specific documentation to build each of these version-specific implementations.

The problem with the current wiki approach

In versions of ACF up through v9, each version had comprehensive documentation sets available both online and as downloadable PDFs. Each of these documentation sets were separate and distinct, and the online versions made it very straightforward to shift between versions. With v10, however, there is a downloadable PDF version of the documents (thanks to Adam Cameron for pointing me toward those) but the only references to it I can find are not easy to find (search the wiki for "archive" -- how obvious is that if you are looking for CF10 documentation?). The online version of the documentation is maintained as part of a wiki that does not contain discrete sections for different versions of the product or language and for the most part appears to be focused on v11.

The old version of the online docs has the tremendous benefit to the user of being crystal clear as to what capabilities are available in that version of the language (e.g., which attributes are available for a given tag, what functions/function arguments are available). If I am working on an app currently running on version "x" of ACF, I typically want to see only the version "x" documentation for that tag.

The current wiki-based documentation set, however, does not have that clear distinction between versions of the product or language. This makes differentiating between versions for tags, attributes, supported attribute values, functions, etc., in terms of what is valid and supported between versions far more challenging and error-prone than in previous versions. If I care about the v10 implementation of the cfzip tag, for instance, I have to either use the off-line version of the docs or make sure I look at the "history" portion of the relevant tag page and then mentally remove the new attributes added for v11 ("password" and "encryptionalgorithm", in this particular case) as I scan down through the attribute documentation -- particularly given that there is nothing within the description of the attributes indicating their recent addition in v11).

A better approach?

It seems to me that a better approach would be for separate, discrete version-specific sections within the wiki. The language reference -- along with the supporting documents identifying additions, removals, and deprecations -- is one example of where this would make the documentation much easier to use. The v10 portion of the reference would always be specific to v10 and would not (should not?) need to contain any v11 content. The v11 portion of the reference would presumably start as a clone of the v10 portion of the documentation, and could evolve along with the language as v11 was developed. As work on v12 is started, the v11 portion would be cloned as a draft and evolve independently from the sections covering previous versions.

The current wiki approach is likely to get more and more unwieldy as additional versions of the product and the language are covered within the current wiki structure. Take the page listing deprecations and removals as an example. Besides being in drastic need of updates as of this writing for completeness and currency with v11, this page -- based on its current structure -- will get more and more unwieldy as additional versions have to be covered: more rows to cover features being deprecated or removed, and more columns for subsequent versions? The current approach just does not seem to scale for pages such as this.

Note that this is not a problem with the use of a CMS or wiki for the documentation itself as much as it is a poor decision, in my opinion, on how to structure the documentation within the tool they selected.

Finding documentation for earlier, but still-supported, versions of a product should not be difficult but in this case it is getting harder. I'd like to believe the ColdFusion documentation team will see the light and restructure the documentation set before it collapses under its own weight and degenerates even further in terms of being usable and useful.

And the off-line docs?

The current wiki structure -- where it seems to be focused mostly on the current language version -- also raises the question for me as to whether a similar set of downloadable v11 references will be made available now that the product is available or as the wiki gets refocused on v12. That's a separate but important and relevant question. I hope they do, as those downloadable PDFs have repeatedly proven invaluable for me and my team.

A Gotcha with Enabling J2EE session in Adobe ColdFusion on Apache Tomcat

I've spent a bit of time over the past month or so playing with setting up a couple of my development systems to run Railo and Adobe ColdFusion 10 on a stock install of Apache Tomcat 7. In the case of ACF10, my interest in running on stock Tomcat is based on a desire get away from the custom-built and now outdated version of Tomcat Adobe (unwisely, in my opinion) bundles with ACF10. This past week I bumped into a bit of a gotcha that took me quite a bit of time to track down and solve. In the hopes of helping others avoid this same problem and so that I don't forget it, I'll share what I ran into and how to solve it.

The symptoms I was seeing were that as soon as I enabled J2EE sessions in the CF administrator and then subsequently stopped Tomcat for any reason, Tomcat would no longer start cleanly,it was no longer bringing up the context running ACF, and because it was not starting cleanly it would also not shutdown cleanly. As weird as this seemed (and sounds, I realize), this was very repeatable. I had it down to something I could reproduce in under 5 minutes: set up a clean new Tomcat install, deploy ACF10 on it via a WAR file, sign into the CF admin, enable J2EE sessions, stop Tomcat... and it would no longer start. There was nothing in the ${CATALINA_BASE}/logs/catalina.out log file indicating what was wrong; it just looked like as Tomcat began starting, it would hang.

It seemed like something about turning on J2EE sessions in ACF10 was breaking Tomcat. Based on a suggestion from a co-worker, I removed write permissions for the user under which Tomcat was running from all folders under ${CATALINA_BASE} except the ./logs/ and ./webapps/ folders, in an attempt to see if I could determine where the breakage was occurring. On starting Tomcat, I noticed a complaint in the ${CATALINA_BASE}/logs/catalina.out log file about not being able to write to folder ${CATALINA_BASE}/work/Catalina/localhost/_. Looking in that folder, I found a file named SESSIONS.ser and doing a bit of Googling, I came across a short blog post dealing with session persistence across Tomcat-restarts.

I'm not going to pretend that I know why Tomcat would have session persistence enabled across restarts, or why I might want to persist sessions across restarts (I really can't come up with a scenario where I would want that), or why enabling J2EE sessions in ACF10 would seem to break this persistence... but clearly it does. To disable this persistence, the context(s) within Tomcat on which ACF10 is enabled need to include a session manager component specifically configured to disable this persistence:

<Manager pathname="" />

This is touched upon in the Apache Tomcat docs here.

Time for a talk

Li turned 7 years old this past Monday, and based on something I saw Friday afternoon, it would seem that the time has come for one of those important father/daughter "talks". I was doing some volunteer computer tech support at Li's school on Friday afternoon. She had left her research paper on Argentinean pampas deer open in MS Word on one of the computers in her classroom. (She had saved it -- of which I was proud -- something not all of the students in her class have apparently learned, based on my observations.) One of her teachers found me sobbing uncontrollably under the computer table... Li's entire paper is set in ... [gasp] Comic Sans. The horror, the shame... I was so unprepared.

While MS Word probably does not deserve anything better, Comic Sans is a horrible thing to do to Argentina, pampas deer, and research papers. Yes, even 1st grade research papers.

(This entry is based on a Facebook post I started on January 10, 2014. Most of it is true, aside from the "sobbing uncontrollably under the computer table" bit.)

Here we go...

All of these are combining -- as they typically do each year -- to pile on a good case of the January blues:

• Li's birthday is tomorrow. She turns 7. How is this even remotely possible? I can't believe how fast this past year and, really, all of her life have raced past.
• Ian heads back to Norman mid-day tomorrow for the upcoming start of the spring semester of his fourth year of college. Has he really been home for three weeks already? It's never been easy on any of us when he leaves but the past couple departures have really been hard; this one will be, too.
• Li goes back to school tomorrow. She's really excited about this and about her birthday, but also really struggling with Ian's impending departure.
• I go back to work on Tuesday (the day after tomorrow), after having been off work for a full three weeks. 

Holiday Traditions

This post comes out of a recent conversation with friends over coffee, in which we were talking about our respective families' traditions for the Christmas season and where those traditions came from.

• Food: we cook much more frequently over the Christmas break than during the rest of the year, where by "cook" I mean really cook (as in make stuff that takes more time than we would normally have during a typical day). A big part of this is tied to work schedules: the lab where I work shuts down between Christmas and New Year's Day each year and I usually bracket that with additional personal leave to stretch it even longer. This is something we've just sort of grown into over the past 10 years or so.
• The Christmas tree: usually up around mid-December (these days tied to Ian's arrival home from school) and down on the 1st or 2nd of January. My least favorite tradition, truth be told.
• Christmas music: we almost always have some sort of Christmas or holiday-ish music playing during this same period, with "The Andy Williams Christmas Album" occupying a special place in the play list as the most important. I remember listening to this each year as a kid, and at some point we ended up with it on CD. Cheesy, but still my favorite Christmas album (probably as much for the memories as for the actual music).
• Baking Christmas goodies: my fudge, Ian's peppermint strips, sugar cookies (most decorated, of course), Deb's pecan fingers, holiday breads. Some to eat, lots to share and give as gifts. This is something both Deb's and my families did as we were growing up.
• Clam chowder and candlelight church on Christmas Eve: the clam chowder part is from my family; we both grew up going to church on Christmas eve.
• Hot chocolate and cookies before bed on Christmas Eve: something my family always did after coming home from church.
• Cinnamon rolls on Christmas morning: this is something my mom did some years as I was growing up, and I love getting up early on Christmas morning and making them for my family.
• Christmas stockings before breakfast on Christmas morning, opening gifts after breakfast: definitely from my family, rather than Deb's. Stockings were always one of my favorite parts of Christmas growing up, and still are. The challenge at this point is convincing Li to let Ian sleep until something he would consider a "reasonable" hour (maybe a little after 8:00 am, these days).
• The bibliophilic elf: each year, each of us gets a book from a certain literature-loving elf, something we started about 10 years ago.
• Jigsaw puzzles: more from Deb and Deb's family than mine. Deb always gets a puzzle started and everyone helps, whether it is looking for a piece or two as they walk by, or pulling up a chair and sitting down for an extended period of time to work on it. There is almost always a puzzle or two under the tree for all of us each year.

We also tend to play lots of board and card games, and we tend to stay up late watching movies (or, the past couple years, binge-watching something Ian has found like "Firefly" or "Battlestar Galactica"), but I'm not sure those have yet reached what I would consider full tradition status. We also almost always spend a few days with my parents and with Deb's parents somewhere during time around Christmas, either here or at their respective homes; again, part of our typical Christmas Season but not necessarily what I would call tradition.

I've thought about some of these things this Christmas, given a conversation with Deb back in mid-December when we were talking about Christmas. There is actually quite a bit about "Christmas" I really don't like: the busyness, shopping, unwanted obligations or things we do just because we feel like we ought to or are expected to (we all have them, right?), dicey travel conditions, the clutter. The parts I really like are the time spent together as a family (all of us home from work and school) and the food (the eating but even more so the preparation together). Some of that almost certainly comes through in looking at what we've turned into our family traditions. 

Goals for 2014

I'm not really a "resolutions" person, but here are my goals for the new year (in no particular order):

• Read more
• Write more
• Listen more and speak less
• Contribute more
• Consume less
• Simplify

That last one probably deserves a bit of explanation, if only because that's a such a broad characterization of what I have in mind. My (our?) lives have gotten too cluttered on many fronts and would clearly benefit from less clutter on several different levels including stuff, commitments, technology.