Saturday, July 24, 2010

Attend Dallas TechFest for only $25!

Dallas TechFest is a great multi-technology event that's coming up on 7/30. There are tracks on Java, Flex, PHP, .NET, and most importantly CFML, so it's not only a great place to get your CFML fix, but also to engage in some all-too-rare cross-pollination between technologies. (The tech community doesn't do nearly enough of this sort of thing in my opinion.)

The CFML track doesn't have details on the track page unfortunately, but when you check out the speakers page you'll see the following great CFML speakers:

I don't know what the specific topics for some of the speakers are, but I can tell you that I'll be speaking on Building and Deploying CFML on a Free Software Stack, Jeff Lucido is speaking on Open BlueDragon for Google App Engine, and I'm pretty sure Steve Good is speaking on Mura. With this lineup I'm sure all of the CFML topics will be great!

UPDATE: Steve pointed out in the comments a big oversight on my part--you can check the Agenda page to see all the details of all the tracks.

There are also some big names from other technologies at TechFest as well, such asScott Davis (Grails guru extraordinaire), Ted Neward (.NET developer and consultant), Mark Piller (Midnight Coders), and Craig Walls (SpringSource) to name but a few.

Sounds excellent, right? Well, today's your lucky day. If you haven't registered yet there's still time, and there's a big discount to boot! Register now and use the discount code coldfusion to get in for only $25. That's right, a mere $25 for all this geeky goodness.

See you there!

Thursday, July 22, 2010

CFML Advisory Committee Officially Dead: My Version of the Story

Since Adam doesn't have comments open on this post (what's up with that?), I feel compelled to clear the air and discuss the probable ending of the CFML Advisory Committee from my perspective. (And yes, all are welcome to comment on this post.)

I really regret having to spend the time writing this since in a lot of ways it will be airing dirty laundry. But since Adam is grossly misrepresenting a great deal of what went on during the effort of the CFML Advisory Committee and what led to its eventual demise, I think it's only fair that people don't take Adam's version of the story as gospel. It's far from it.


First, I'd like to get some semantics out of the way. I can't bring myself to refer to this now-defunct effort as "Open CFML" because it's such a huge misnomer. Frankly, we never referred to the committee as "Open CFML" so I suspect the use of that term in Adam's blog post is merely FUD/scare tactics that suit his purpose. (Saying Open CFML is dead sure has impact, don't it?)

The CFML Advisory Committee was anything but open. There was no communication with the CFML community as to what was going on with the effort, there was no way for the community at large to participate, and suggestions by myself and others to update the wiki regularly with our progress and have an open mailing list that anyone in the community could at least read were continually shot down. Given all this it's not surprising the effort ultimately failed, because openness always wins in the end.

Now for the timeline of the CFML Advisory Committee and why things went wrong from my perspective.

In the beginning ...

When I was invited to join the CFML Advisory Committee I was excited because I originally thought the effort was important for the future of CFML. The CFML landscape changed dramatically with the introduction of two open source CFML engines, so it seemed logical that the interested parties would want to get together and discuss a certain level of standards for the language. It's also something that the CFML community was clamoring for, at least initially, because of concerns over code portability between the various engines.

After getting up to speed on things and having discussions via the closed mailing list as well as a couple of conference calls, it became quite clear to me that the effort wouldn't be able to survive the politics. Even given my valid pessimism, I decided to continue on in earnest, hoping for the best but expecting the worst.

Here comes a bit of dirty laundry, but I think it's necessary for people to understand what was really going on behind the scenes. Adobe's participation and level of effort during their involvement with the committee was incredibly lackluster. The committee had conference calls monthly in the beginning, but after Adam didn't show up for three calls in a row, it seemed rather pointless to continue to schedule them. The email traffic on the closed mailing list would go in fits and starts, and in many cases months would go by with no traffic at all.

To cite but one example of Adobe's lack of effort, the way the committee was attempting to organize the language was to use a Google spreadsheet, with columns for the CFML tags and functions on the left, and then a column for each engine indicating whether or not it had the tag or function. There were then columns for each member of the committee to indicate if they thought the particular tag or function should be "core," "extended core," or "vendor specific" as far as the eventual language specification was concerned.

As you can imagine simply organizing the spreadsheet took a great deal of time and effort, to which many members of the committee contributed. Each vendor was tasked with entering their engine's tags and functions. OpenBD and Railo provided their information quite promptly, and I think it was Rob who did the Lion's share of getting things organized initially, but Adobe's column was incomplete for weeks. Finally I took a day or so and added/corrected all the Adobe functions and tags. That at least got things to the point where we could vote.

When it came to voting, Adobe failed to complete this effort as well. To put things in perspective voting took about an hour, but Adobe couldn't seem to find that hour to input their votes. First it was the CF 9 release, then it was MAX, then ... who knows. Bottom line is it never got done. Everyone involved with this effort is incredibly busy, yet everyone but Adobe made the time to vote.

Lack of Accountability Means Lack of Commitment

After weeks turned into months and the voting was still waiting on Adobe, I believe it was Peter who made the modest proposal of setting deadlines for votes. If someone didn't meet the deadline then we'd simply indicate the person didn't vote and proceed with the votes we had. Everyone paid lip service to having deadlines, but even while discussing deadlines Adobe reserved the right to ignore the deadlines if they were "busy." Again, we're all busy. Either the effort is worth your time or it isn't.

I also suggested repeatedly that the whole specification and voting process be open to the public. The members of the committee were selected to represent the CFML engines and the CFML community, but we don't necessarily have all the best answers, and at a minimum the community at large should have been able to see the process as it unfolded. But that would have meant both commitment and accountability on the part of everyone involved, and in the case of certain members of the committee the commitment clearly wasn't there. Having accountability--let alone public accountability--wouldn't work in their favor.

In the end the incredible lack of progress led everyone to agree to simply codify what was in Adobe CF 8/9 so we could get past the voting roadblock and move on. (Keep that decision in mind; it backs up an important point I'll make later.)

Conspiracy Theories Debunked

Here's where things get really bizarre, so please don your tin foil hats and try to stay with me.
Adam mentions the CFML Conventional Wisdom group in his post, which is an effort Alan Williamson started in order to foster public discussion of the CFML language. Personally I think an open discussion list should have been an arm of the CFML Advisory Committee from the start.

To quote Adam's post, "At the very least, this explained why Peter so abruptly resigned." I'm not going to speak for Peter, but this is not why he resigned, and his resignation wasn't exactly abrupt. He debated it for a long time, but to call it abrupt reminds me of a scene from "Fletch":

Dr. Dolen: "Shame about Ed."
Fletch: "It was. Really a shame. To go so suddenly."
Dr. Dolen: "Oh, he was dying for years."
Fletch: "Sure, but the end was so sudden."
Dr. Dolen: "He was in intensive care for eight weeks."
Fletch: "Yes, but the very end, when he actually died, that was extremely sudden."

Why Adam chose not to take Peter's eloquent resignation email at face value, but instead drums up yet another conspiracy, only serves to further his agenda.

Back to our story. So why didn't I mention the CFML Conventional Wisdom list to the committee?
Two reasons.

First, it's a public mailing list, and I found out about it like everyone else did, on a blog post or Twitter or who even remembers where. Alan may have even sent me an email directly to make sure I was aware of it, but it wasn't a big secret. There were no back-room dealings on any of this. Alan saw a need, created the group, and then announced it publicly. Simple as that.

Second, and more importantly, I saw this as a completely separate effort from what the committee was doing. The committee never had a public forum to discuss CFML, and the powers that be on the committee didn't want one. So this provided something the committee didn't, and giving the community a voice in helping to define the language they use is something vitally important in my opinion.

Ultimately the Conventional Wisdom list could even serve as a benefit to the committee. Loose ideas could be hashed out, sample code usage could be created, and the results could be submitted to the ivory tower that was the committee.

And a bonus reason: at the time when the Conventional Wisdom list started, the committee was in no way, shape, or form in the business of discussing enhancements to the language. We weren't even able to codify what was already in the language, so for Sean, Peter, or me to bring a CFLOOP enhancement discussion to the committee wouldn't have made sense. The committee wasn't the time (or the place, frankly) to have those sorts of discussions.

The way Adam phrased all of this makes it sound like Alan, Peter, Sean, and I got together and were all conspiring against the committee, and maybe Adam even believes against him personally. Nothing could be further from the truth. Sean, Peter, and I found out about the Conventional Wisdom group when everyone else did, and since people on the committee are supposedly aware of what's going on in the CFML community, I assumed everyone on the committee would have seen it as well. The implication that we were keeping a publicly announced, publicly available list hidden from the committee simply doesn't hold water.

As for my better mouse trap header above, ultimately I think having an open discussion group is the way things should have been from the start. Why not seek input from the community at large? Why not have the discussions out in the open? Seems like a no-brainer to me. If Adobe wants to have enhancement discussions with their customers and among the members of their private programs that's great for Adobe, but that doesn't let the legions of CFML developers in the wild participate in the process.

Again, openness always wins.

Where I Agree
Adam did make a couple of points with which I agree.

"In the end, the community isn't losing much at all with the demise of the OpenCFML board."

I completely agree with this statement. Though I was honored to be a part of it I questioned the effort from the beginning because at the end of the day, Adobe ColdFusion sets the de facto standard for the language. I made that point in my last email to the committee list (which for a very long time was the final email on the committee list), and I don't think anyone would disagree.

I take issue with Adam's follow-up to this statement, but life's too short to nitpick every last detail of what he said. The real beneficiary of this effort was supposed to be CFML developers, but somehow that ideal got lost along the way.

Bottom line here is that CFML developers don't have anything to fear due to the loss of the committee, because the practical value of the end goals were rather dubious from the start. It's in the best interest of the open source engines to be largely compatible with Adobe CF, which they are. We haven't had an official CFML standard before and the world hasn't come to an end, so the cf_apocalypse won't come now.

"Innovation and progress in CFML is driven exclusively by the ColdFusion community."

I suspect Adam and I have very different ideas of what constitutes the "community" and what community really means, but ultimately this is correct. The odd thing here is that before the Conventional Wisdom list was started, there was no single public forum where members of the community at large could discuss what they want to see in the CFML language. So if innovation and progress in CFML is truly driven by the community, they now finally have an outlet.

Setting the Record Straight

Now, for the corrections.

"Matt claimed the OpenBD team was too unorganized to submit tags like CFJAVASCRIPT and CFSTYLESHEET (tags I had hope to include in CF9)."
Pure FUD on multiple levels. I may have said something along the lines of "These tags were added on a whim last week," but that's how open source projects work. If Alan or Andy get an idea, or need something for a project they're working on, they'll create the tags and release them in a nightly build. We then get feedback from people actually using the new features and refine as needed. That in no way means the OpenBD team is disorganized. It differs from proprietary software development, sure, but calling that process "disorganized" would be the equivalent of me calling Adobe "lazy" because they only have a new release every two years. Apples and oranges.

CFJAVASCRIPT and CFSTYLESHEET were added to OpenBD, and Adam's response when he found this out was apparently to take it as an affront because we didn't run the idea by the committee first. Adam seemed to continually and conveniently ignore the fact that OpenBD is an open source project, so Adobe or anyone else can see what we're doing every step of the way.

Furthermore, it was agreed upon by all members of the committee that tags and functions developed in specific engines would be brought to the committee only if their creators wanted the language enhancements to be considered as "core" in the CFML specification. We didn't consider CFJAVASCRIPT, CFSTYLESHEET, and some of the other innovations in OpenBD as "core" CFML, so we didn't officially submit them. But again, the source code is open. If Adobe saw something in OpenBD they thought made sense to be core to CFML or to add to ColdFusion, they could have brought it up and we could have discussed it.

And let's talk about what "submitting a tag" to the committee even means. I'm not sure what exactly I was even supposed to "submit"--the tags were out there in the OpenBD source along with documentation as to how they are used, so wouldn't it make sense that if Adobe was interested in considering those tags for ColdFusion they could read the docs and ask about it on the committee list? If you get the sense from Adam's post that there was some rigorous formal process that OpenBD was somehow subverting, don't. There was no such defined submission process in place.

Finally, the "tags I had hope[sic] to include in CF 9" bit is completely bogus. Yes, Adobe did make some changes to CF 9 (specifically CFSCRIPT if I remember correctly) based on the committee's recommendations, and I applaud them for that, particularly given that CF 9 was nearing the end of development at that point. They ignored plenty of other recommendations, and the reason for that--the real bottom line here--is that CF 9 was largely baked by the time the committee was even having these discussions. So to point a finger and say CFJAVASCRIPT and CFSTYLESHEET didn't make it into CF 9 because I failed to make an official submission to the committee is false on numerous levels. We didn't consider them to be core to the language, the code and spec were available from day one, and adding this new functionality to CF so late in the development process likely wasn't going to happen anyway.

"Sean claimed that Railo wanted to wait a version (or two) to see how new Railo tags were accepted by the community before making a formal recommendation."
Again, this is how open source projects work. Did Adobe expect that the open source engines will stop following the process that is best for their projects and users, and hit the brakes on the rapid pace with which new features are added, to ask the committee's permission before making enhancements to their engines? Does it not make sense--and ultimately benefit Adobe--if the open source projects introduce new features to CFML and let the community kick the tires before finalizing the feature? That saves Adobe time in the future if they decide to implement these features, because a lot of the questions surrounding the new features and how they should work will already have been answered.

I'm at a loss to see what the real issue is here. OpenBD and Railo are both open source, both have nightly releases, both have public roadmaps ... everything's always available for anyone to view. I think ultimately this comes down to a culture clash between open source projects and proprietary products, which was probably partially to blame for the failure of the committee's efforts.

"As a community, we never needed the OpenCFML board to guide or document feedback."

I give this one a "thumbs sideways." We didn't need the CFML Advisory Committee specifically to serve this function, but I don't see Adobe doing anything to foster open language discussions in a public forum either. Perhaps that isn't their job; they focus on finding out what their paying customers want, and no one can fault them for that. In similar fashion the open source projects get continual feedback from their users and make changes accordingly.

I do think it's important that there be some avenue for people to discuss CFML as a language in an engine-agnostic way, however, but that was as simple as creating a Google Group. It's a much better solution and will yield far better results than the committee ever would have.

"I really want to thank Ben, Rob and Ray for the work they put into the OpenCFML."

... but no one else. Not Sean for making valiant efforts to keep things going even when the committee was at its lowest points, and not any of the rest of the people who participated far more than anyone from Adobe, and particularly Adam, ever did. If anyone questioned Adam's real attitude towards the committee that statement pretty much sums it up for me. He was never interested in setting politics aside and working collaboratively to create a CFML language spec, and apparently the only efforts that matter are the ones made by the people in his camp. "You're either with us or you're against us" has been proven to be a very divisive attitude, and it's one that ultimately isn't good for the community as a whole.

"As far as I am concerned, the ColdFusion ACPs will be the CFML Advisory Panel for ColdFusion X and beyond. We'll be asking them to review and sign-off on all of our language enhancements (very soon)."

So this at least defines what "community" means to Adobe, and helps to illustrate that they never had any interest in helping to define CFML as a language outside of their own product. That's fine, and makes perfect sense coming from a proprietary software company, but leads me to the conclusion that the CFML Advisory Committee was a PR stunt to begin with. Adobe's heart was never in it, they were just trying to get out in front of the open source CFML revolution.

In Summary ...

The goal of Adam's post is patently obvious: to blame everyone but himself and Adobe for the failure of the CFML Advisory Committee. His rhetoric sounds almost McCarthy-esque. Get people focused on a common enemy--real or imaginary--and they'll become oblivious to little things like logic and the truth.

Let me be clear: Adobe's lack of participation and paranoia over the supposed malfeasance of Railo and OpenBD are, from my perspective, a massive part of what killed the CFML Advisory Committee. I'd have a lot more respect for everyone involved if we could have collectively decided to end the effort, made a joint statement, and parted ways amicably. But for Adam to post a truth-challenged version of events out of the blue, while not surprising, is in very poor form.

And That's All I Have to Say About That
I've said my peace and then some at this point. Feel free to comment, and if you have any specific questions you think I can answer, I'll be happy to do so. If, however, your comment is of a "he said/she said" nature or intended solely to inflame the situation further, don't be surprised if I don't respond. Adam gave his version of the story, I've given mine in abundant detail, and everyone can continue to speculate on what went on behind the closed doors of the committee. If you care to, anyway. I'd certainly hope you have much, much better ways to spend your time. ;-)

To me, it's not worth dwelling on all of this. The CFML Advisory Committee will go down as an interesting side-note in the annals of CFML history, and people looking back will wonder why we even tried in the first place. I've been asking myself that very question for quite some time.

Wednesday, July 14, 2010

Closing the Tech Gap | The White House

What if senior management in an Agency – or anyone in the public – could identify and monitor the performance of IT projects just as easily as they could monitor the stock market or baseball scores?  That’s what the IT dashboard does  -- and it’s changing the way government does business.

Government IT projects all too often cost millions of dollars more than they should, take years longer than necessary to deploy, and deliver technologies that are obsolete by the time they are completed. Colossal failures have contributed to a significant technology gap between the public and private sector which results in dollars wasted and a government that is less responsive to the American people.  To close the technology gap, cut waste, and modernize government, the Obama Administration is taking concrete steps to deliver better results for the American people.

I am continually floored by the efforts of the US CIO to get the bloat eliminated from government IT projects. Extremely encouraging stuff.

CouchDB NoSQL Database Ready for Production Use -

Two major enhancements to CouchDB make it 1.0-worthy, said Chris Anderson, the chief financial officer and a founder of Couchio. One is the fact that performance of the software has been greatly improved. The other is its ability to work on Microsoft Windows machines. A lot of work was also put into stabilization of the software. 
Performance-wise, the new version has demonstrated a 300 percent increase in speed in reads and writes, as judged by internal benchmarking tests done by Couchio. The performance improvements were gained by optimizing the code, Anderson said. 
This is also the first release of CouchDB that can fully run on Windows computers, either the servers or desktops, Anderson said. Previous versions could run on Linux, and there is a version being developed for the Google Android smartphone operating system.

I'm really stoked that I may finally get to use CouchDB on a "real" application soon, so this is great timing. Congrats to the Couchio guys and the fantastic community around CouchDB.

Thursday, July 1, 2010

Using Java Regex Functions on CFML Strings

I ran into this today while working on ColdTonica, and since it's something I'm still surprised people forget (including myself) I thought I'd share.

ColdTonica is a CFML clone of StatusNet (formerly Laconica), which is an open source PHP-based microblogging service similar (although vastly superior) to Twitter. As you might imagine, those simple 140-character notices you spend way too much of your day posting go through a lot of transformations before reaching the final form in which they are displayed, because the notices need to be parsed and manipulated to add things like links to tags, links to @ replies, shortening URLs, and so on. Honestly when I started studying the StatusNet code and saw what all goes on behind the scenes for such a seemingly simple service, I have to admit I was a bit surprised.

All the text manipulation of course involves a lot of regular expressions, and since for ColdTonica we're porting the PHP code over to CFML, it saves us a ton of time since all the regular expressions have already been written. Unfortunately there are some syntax issues with the regular expressions that render them incompatible with CFML and even Java, so it did take a bit of research and help from a friend of mine to start to unravel and convert them.

One of the issues I ran into while moving the PHP regular expressions over to CFML is that CFML doesn't have Unicode support in regular expressions (some nice info about Unicode in regex here, although the information about Java is dated), at least not without first converting Unicode to ASCII values and wrapping them all in Chr(). This is what I've discovered while messing with this at least; if this isn't correct I'm happy to be proven wrong.

Since the PHP regular expressions use the Perl syntax of x{hex_value_here}, which CFML doesn't support, converting the regular expressions was getting a bit messy. Java, however, does support the x syntax (though it didn't used to), but with a slightly different syntax. You can read more about Java regex syntax in Java 6 here.

During the course of this I was reminded of the fact that under the hood, CFML strings are Java strings, which means that rather than using functions like REReplaceNoCase() in CFML and converting the hex codes into something usable by Chr(), I can simply use Java's replaceAll() function on the String class. This lets me keep the PHP syntax more intact and do a lot less conversion research.

So the original PHP looks like this:

$r = preg_replace('/[x{0}-x{8}x{b}-x{c}x{e}-x{19}]/', '', $r);

And the CFML version using replaceAll() on the String class looks like this:

r.replaceAll("/[x00-x08x0B-x0Cx0E-x19]/", "");

At least I think that's right. ;-) I still need to test all of this out, but as I convert the rest of these it'll be much simpler to go this route and keep things in hex as opposed to converting everything to CFML-compatible Unicode regex syntax.

The moral of the story is you can do a lot in CFML by leveraging the underlying Java functionality, and this doesn't apply only to the String class. So if you run into things that are a bit weird to try and accomplish in CFML check the Java docs and see what additional functionality you have available. You'll probably be surprised at what you learn!

On Vanilla Moon Pies and Growing Old

This is totally random, and my point is probably far less than profound, but yesterday I went to the 7/11 near my house and was practically jumping up and down when I saw Vanilla Moon Pies. I'm a huge fan of anything vanilla, and you just don't see vanilla Moon Pies that often. Chocolate, sure. Maybe even banana. But for some reason vanilla is hard to come by.

"This is awesome!" I thought to myself as I pondered buying the whole box. Just to, uh, have some around the house for a while. Yeah, that's it. I found the inner strength to only buy two, and I grinned all the way home about my great find, because again, these are pretty darn rare in my experience. Even as I was enjoying the first of my two rare vanilla Moon Pies yesterday, I was thinking, "I better save the other one for a special occasion, or go back and buy more, because I never know when I'll find them again!"

Then this morning for some reason it hit me. There's this little thing called the Internet, and you can actually buy stuff on the Internet. But surely the Internet doesn't sell vanilla Moon Pies, right?
Well of course the Internet sells Moon Pies. And not just vanilla either. They have flavors I didn't even know existed, like strawberry and orange. You can even get mini Moon Pies if you're so inclined.

So how does this all relate to the title of this post?

Well, I got to thinking about why it didn't dawn on me to go to right away if I wanted a vanilla Moon Pie, or anything else for that matter, and I think it's because I grew up when there was no Internet. (I know, I'm old.) I guess in my brain you still only buy tech stuff, books, DVDs, and things of that nature on the Internet, but buying food on the Internet--other than holiday baskets at Christmas--just didn't enter into my head.

Back when I was a kid (see, I am old) if your local store didn't have something, you didn't get it. There was no instant access to infinite choices, and you couldn't have exactly what you wanted at a moment's notice.

I still have fond memories of my Dad hunting around for a very specific kind of Heinz dill pickles because the local grocery store stopped carrying the ones he liked. He talked to the manager and tried to explain the situation, and I think the manager even said he'd check with the distributor, but I think he'd get maybe a jar here or there and that was the best the store could do for the most part.

Then for Father's Day or my Dad's birthday one year, I remember either my Mom or my sister (another sign of getting old--the memory starts to go) got my Dad a whole case of these hard-to-find pickles. He was thrilled. He kept a jar in the fridge and put the surplus in the basement, and he'd have his favorite pickles for quite some time to come.

I guess my point is that back before it was so easy to get everything, and when there's more or less no such thing as scarcity anymore (at least not in the land of plenty), there was excitement in all of this. It was fun to see something you don't see often in the store, and it took some detective work and actual leg (OK, car) work to hunt down that exact item you wanted. And I bet it tasted all that much sweeter (or sourer in the case of pickles) when you finally found your Holy Grail.

So as I was enjoying my vanilla Moon Pie yesterday, I guess I was reliving all of this. And now that I know I can get vanilla Moon Pies whenever I want, somehow it's just not as exciting. (They still taste pretty damn good though.)

At least the ones I got at the 7/11 were double-decker vanilla Moon Pies. Those aren't available on yet.