Mark Mandel and Kai Koenig were recently inspired by the ThoughtWorks "Technology Radar" to create their own, which they featured in episode 31 of 2 Devs Down Under, their conversational podcast. Because they're both somewhere along the spectrum of CFML-to-ex-CFML developers and have worked with Flex etc, their opinions on various technologies are probably of more interest to other CFML developers than the original ThoughtWorks radar. This podcast episode is longer than usual - nearly two hours - and Mark and Kai would love to hear your responses in comments. I decided my response was a bit too long to post as a comment, so I am turning it into a blog post instead.
The first category they covered is "Techniques" and their top two items are things that are top of my list as well: devops (infrastructure as code) and automated deployment. I've been advocating automation of builds and deployments for a long time and I'm always looking for better ways to manage these tasks. At World Singles, we've been using Ant for our build process and we're reaching the limits of what we can do easily so we're looking at code-based solutions instead, and we're also looking at devops via Pallet (Clojure-based specification of servers and software configuration). On the flipside, they advise "hold" on hand built infrastructure and one-off deployments - and I completely agree with them on that.
Finally in techniques, they have Agile in adopt and Waterfall in hold. Two decades ago I worked in a process/QA-focused company that advocated a "V" process to replace Waterfall in the enterprise, and for the last decade I would have advocated Agile instead of Waterfall, so I'm with Kai and Mark on that. I know Agile still has its detractors but I don't think Waterfall still has any supporters left?
Next, Kai and Mark move on to "Platform" and perhaps controversially put Apache, IIS and MySQL into the "hold" section. Given Oracle's track record, I can certainly understand their concerns with MySQL - and at work we've been bumping heads with its performance limitations and would agree that it is not easy to provide robustness (in terms of replication and failover). As someone who won't put Windows servers into production, I can only smile at IIS being in this section but I was surprised by Apache's inclusion. The web server to "adopt" they say is Nginx and I'm about to start assessing that so I won't argue overall. Also in their "adopt" / "trial" / "assess" sections are a broad spread of no-SQL databases - which I also agree with. Mark recommends PostgreSQL on the grounds that he's seeing a lot of recommendations for it. I've looked at it a couple of times and, to me, it seems to have all the complexity of Oracle, combined with some very quirky non-standard behavior - but, like Mark, I keep hearing good things about it. Personally, I'd rather move fully onto MongoDB at this point because of the flexibility it provides in terms of schemas and data storage, combined with simple (and solid) replication and sharding for robustness and scalability. The final item on Mark's "assess" list that I'd call out is Hazelcast which is a very impressive piece of technology: it is a library that provides distributed versions of several standard Java data structures. This makes it insanely easy to set up distributed caches using the same data structures you're already using in your application, so you hardly need to make any code changes to be able to leverage clustering. Definitely worth a look.
Along with Eclipse, Kai and Mark throw quite a few other tools under the bus: FTP for deployment, Ant, Maven, and Dreamweaver. If you're doing server-side development, I have to agree with all of these. I use Ant but really don't like it, I have to use Maven occasionally for Clojure contrib projects and don't like that either - do we really need to be programming in XML? I think Dreamweaver is probably still a great choice for front end design work but CSS and JS support has improved so much in so many lightweight, open source editors that I find it hard to get enthusiastic about Dreamweaver even in that realm.
Perhaps of more interest to our audience is their position on CFML: Mark puts CFML in the "hold" section and Kai puts Adobe ColdFusion in the "hold" section but puts Railo in the "adopt" section. They have quite a discussion about this and I think this is the part of their podcast that should generate the most comments...
This also matches with Mark being essentially "ex-CFML" whilst Kai is still "CFML". I'm not quite "ex-CFML" but I'm no longer really "CFML" either. I understand Mark's point of view - that no one in the world at large is going to start a project in CFML - but I'm somewhat fascinated by Kai's optimism and it makes me re-examine my own position on CFML. At World Singles we're using CFML for the View-Controller portion of our application and it still makes sense. We're using Railo but I have to admit that even Railo feels a bit bloated for the VC portion - because we're using such a small subset of CFML at this point. That said, CFML is a wonderful templating language, and script-based controllers are a decent way to glue any Model to your Views. I've previously said we wouldn't bother upgrading beyond Railo 3.3 yet we're in the process of standing up two new servers as upgrade replacements for two of our existing servers, and we've decided to deploy Java 7, Tomcat 7, and Railo 4 - and now will upgrade the third server (and QA and all our dev environments eventually) to the same. Which means we'll start using closures in CFML and it will continue to have a renewed lease on life for a while.
Would I start a new greenfield project in CFML? Until recently I would probably have said "no" but now I'm not so sure. Would I ever start a new greenfield project in Adobe ColdFusion? No, that makes no sense at all in this age of free open source languages and frameworks. But Railo 4? It's a possibility. With their continued evolution of the language and the system's overall facilities (such as command line execution), I might just consider them for future projects... and continue using a hybrid of CFML for the View-Controller / container portion of the application, with Clojure for the Model. That was my big surprise after listening to Mark and Kai for two hours.