An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

On My Radar?

July 24, 2013 ·

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.

Also in their "adopt" or "trial" sections for techniques are SPA (Single Page Applications) and modular development with JavaScript. As we move into a world of mobile web applications, MVC on the client side is inevitable and something we're going to need to live with. JavaScript is not a language well-suited to large scale development and the lack of modules or namespaces has led to a number of workaround techniques and clever libraries (covered later). We'll eventually get native modules in JavaScript but, like many other issues with JavaScript, we're hamstrung by older browsers so adoption will be painfully slow. I'd recommend looking at other compile-to-JS languages that have native support for modular development and can bury the JS issues in a cross-browser manner (my personal preference is ClojureScript, of course, and that will come up again later).

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.

Next we move onto "Tools" and Mark, in particular, recommends a lot of things that I am not familiar enough with to agree or disagree. Mark recommends Ansible and Vagrant where I'd probably lean toward Pallet and VMFest but, given Ansible is Python-based, I suspect Ansible would be a lot more approachable for many developers. Kai puts the Brackets editor from Adobe in the "trial" section which is an interesting choice. As a lightweight editor for HTML / CSS / JS, it's probably got a lot going for it but I'm keeping my eye on LightTable which, like Brackets, is also based on CodeMirror but offers some very interesting live evaluation options for JavaScript, Python and Clojure (and ClojureScript). Like Brackets, LightTable is designed to be extensible but full plugin support is something we'll get in the upcoming 0.5 release which is when I think LightTable will become very, very exciting! Both Kai and Mark put Eclipse in the "hold" section (which I agree with - it's become pretty bloated and plugin version compatibility can be a problem, esp. when Adobe's ColdFusion Builder is based on such an old build of Eclipse). Strangely - to me - they both put IntelliJ in "adopt". I've tried IntelliJ several times and I really can't get on with it. I find it to be every bit as bloated and complex as Eclipse, but far less usable. I can sympathize far more with Kai's recommendation of Sublime Text although, again, I just can't get on with it. I find it to be fussy and counter-intuitive in many areas, although a couple of my team members love it. My weapon of choice for editing is Emacs but I'm not going to try to convince everyone to use it. If you're doing Clojure development, it's probably the best-supported option, and it is extremely powerful but at the same time, quite lightweight.

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.

Finally Mark and Kai move onto "Languages & Frameworks" and they have a lot of JS-related recommendations which... well, I just can't find it in myself to like JS. The more I work with it, the less I like it. I know it's ubiquitous but as far as I'm concerned, it deserves to be the assembler of the web and no more. There are an increasing number of compile-to-JS languages now that provide some compelling choices. If I was a Windows guy, I'd probably be pushing WebSharper and FunScript which both offer F#-to-JS compilation, built on top of TypeScript. A statically typed functional language is a good choice for targeting JavaScript and papering over its many flaws. For a more general functional language, ClojureScript offers Clojure-to-JS compilation and that will be my choice as we move into more complex JS territory at work I expect. Both Mark and Kai recommend Clojure, which I was pleased to see (of course). Mark also recommends JRuby and Kai recommends Python. I had both on my list of languages to learn but having spent some time with both of them (Ruby via "Programming Languages" on Coursera; Python via 10gen's MongoDB for Developers, and attending PyCon), I've taken Ruby off that list and plan to spend more time with Python, probably in a system scripting capacity.

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.

Tags: coldfusion · oss · podcast · railo

8 responses

  • 1 Ali // Jul 24, 2013 at 9:28 AM

    Do you have any good python references you can point us to?
    As a CFML programmer, I have not found any good tutorials, or entry-points into learning the language. It's either really basic stuff like, adding 2 numbers in the command-line. Or something totally horrific, like some theoretical algorithms, that gave me nightmares in college.
  • 2 Sean Corfield // Jul 24, 2013 at 10:54 AM

    You don't think the official tutorial is good enough? It covers pretty much the whole language and a lot of the standard library.

    http://docs.python.org/2/tutorial/
  • 3 Sean Corfield // Jul 24, 2013 at 11:22 AM

    FYI, some nice material about "Waterfall" being "hold" or worse: http://ronlichty.blogspot.com/2013/07/the-most-convincing-reason-to-change.html
  • 4 Ali // Jul 24, 2013 at 4:29 PM

    Thanks, I'll give those a try :)
    I'm interested in how it's used as a web development language, google brought up a couple of frameworks like Django which seems to be the most prevalent and Grok.
  • 5 Kirill // Aug 24, 2013 at 6:38 AM

    We've been using TypeScript 0.9 a work now and I must say that the experience is just great so far. I also took Programming Languages course and it really gave me some good knowledge about types so TypeScript is really making sense to me now. I also learned and used Scala, so I kind of like strongly typed languages. I guess thought that TypeScript is more for people with strongly typed languages background starting client side development rather than for people who've been doing just JavaScript. I guess people who do not have good understanding of types would struggle with TypeScript. But people who do would thrive.

    I should say I am surprised with your critics of IntelliJ. I've used Idea for Scala (and Clojure!!) and using WebStorm 7 for TypeScript/HTML/CSS. It's been great (thought I should say that they are still adding support for TypeScript so it's not all perfect yet). After trying Idea/Webstorm I don't even have to use Sublime. And I am definitely not going back to Eclipse.
  • 6 Sean Corfield // Sep 3, 2013 at 5:43 PM

    Kirill, good to hear about real world experience with TypeScript! I'm looking at Elm now - http://elm-lang.org - as a strongly typed, compile-to-JS option. I like that it is inspired by Haskell and uses a Signal type abstraction for the asynchronous event stream (so a text field is a Signal of values from that field, representing the change over time).

    As for IntelliJ, I think IDE choices are very subjective and I've just never been able to like it. Eclipse was "OK" for me, but too bloated for small machines. I love Emacs now but I know it's not for everyone :)
  • 7 Zack Pitts // Dec 28, 2013 at 10:53 PM

    "I'm about to start assessing that [Nginx] so I won't argue overall."

    Have you assessed Nginx enough to comment on it yet?
  • 8 Sean Corfield // Dec 30, 2013 at 9:23 AM

    @Zack, it hasn't risen to the top of my stack yet but I'm hoping to spend more time with it this year. 2013 threw me some curve balls which interfered with my plans to investigate more technologies...