After I posted my CFSummit 2013 APK Teardown I continued to think about what might be good and bad about having a tool like this. I've had many conversations about it and heard many arguments both for and against it. The most common pro-cfclient argument I hear is that it's a "gateway drug" approach: CFClient will enable you to make a mobile app without any real knowledge of JS, and eventually (maybe) you'll learn enough not to need it.
There is some merit to this argument. To put all of my cards on the table, that's precisely what happened to me with -- I am loathe to admit this... -- CFAjaxProxy.
ColdFusion 8 was released in July 2007, at a time when jQuery was just starting to get mainstream traction. I had been using a somewhat... unsavory... method for AJAX-like behavior, because, to be honest, AJAX seemed scary and hard. Then Adam Lehman came to our local CFUG and demonstrated new features in CF8, CFAjaxProxy among them, and I started using it. Of course these days I'm well beyond the feature, but it certainly had the "gateway drug" affect on me.
But here's my biggest counter-argument:
As Scott Stroz has said regarding CFAjaxProxy: You're not learning how to do Ajax, you're learning how to do CFAjaxProxy. If you go into a job interview and they ask you to write AJAX code, and you write a
<cfajaxproxy> tag, they're going to laugh and show you the door. Similarly, if asked in a job interview about your capability to write mobile apps and you write
<cfclient>, nobody is going to take that seriously. It is a tool for the lazy.
What I'm doing about it
One of the people that I discussed the blog post with was Simon Free, who has had the pleasure of working with CFClient -- he presented about it at CFSummit -- and he refutes some/most of what I criticized in my post (comment posted after our discussion). We agreed that the end result was not great code (totally side-stepping the problems with the UI/UX), but he insists it's possible to "do it right" using CFClient.
The result of the conversation was that he and I have agreed to work together on a sample app of our own, built using CFClient, trying to adhere to PhoneGap best practices as much as possible. Hopefully with the combination of his CFClient knowledge and my PhoneGap experience, we can put the best possible product out.
We have an idea of what app we want to write, and when we want to have it done, but I'm not sure how much Simon wants to divulge at this point; so more news about what the app will be, and when you can expect to see it, will be forthcoming at a later date.
Published 2013-10-28 @ 08:30 in
Thanks again to everyone that attended my presentation on Closures at CFSummit!
For your reference, my slides are available here on my website: http://fusiongrokker.com/p/closures -- Navigate with your keyboard: Down if it's available, otherwise Right.
As well, the whole thing is open source, if that interests you: https://github.com/atuttle/preso-closures
I had a great time at the summit, and especially considering it was their first year I think Adobe and Kishore did a great job!
Of particular note, the wifi was probably the best I've ever seen at a conference. I joked with some friends as they were publicizing the wifi password during the opening keynote: "there goes the wifi usability..." and boy was I wrong!
Anyway, I had a great time and I hope to be invited back again next year. Will I see you there?
Published 2013-10-28 @ 08:00 in
For those of you that don't have an Android Device or follow Android News, an "APK Teardown" is basically de-compiling an Android app to see what's in its source code. This is usually done by news sites to try and scoop new features of pending updates.
This teardown isn't really interested in any hidden features of the app, but in the cross-compiling technology used to make it: CFClient.
I make no bones about it: I'm not a fan of the new CFClient feature of ColdFusion 11:
Judging by the 22 retweets (and counting), I'm not alone in this opinion.
For those of you that weren't at the Keynote, prior to the CFClient unveiling, Ben Forta opined on the history and future of ColdFusion, and what seemed to be his thesis (in my opinion) was a message delivered on a single slide:
ColdFusion is not *the* solution, ColdFusion is *a* solution
-- meaning that it should be a tool on your toolbelt, but is not a silver bullet for all problems. All my tweet did was point out the discrepancy between what Ben said (which I agree with) and the purpose of this new flagship feature.
Anyway, on to the teardown, eh?
Can we assume this app follows what Adobe would consider the best practices for using the feature? I hope so: The app was written by Ram Kulkarni, who as I understand, is "The CFClient Guy" (according to Simon Free's CFClient presentation).
Structure & Size
/CFIDE/scripts/ajax/messages/cfmessage.js (32kb) "messages" - sort of a localization or string lookup file.
/CFIDE/scripts/ajax/package/cfajax.js (39kb) 1700 lines presumably dedicated to making ajax requests. I say presumably because it's obfuscated code: all of the variable names and private method names have been changed by a code compressor -- but for some reason the code hasn't been minified down to 1 line. It's not that big of a deal: compressing more only shaves off another 7kb or so, and in the grand scheme of things, 7kb is a drop in the bucket.
That's it for the
/CFIDE/scripts/ folder, but it leaves quite a lot to the
/CFIDE/cfclient/ folder. So much so, in fact, that (rounded to 1 significant digit) the contents of
/CFIDE/cfclient/ take up 100% of the 1.6mb of
/CFIDE/. Obviously there's quite a lot of code in here: 43 files in total. I won't analyze them all in detail -- most are easy to analyze in name only.
The biggest files in this folder are:
That seems... sub-optimal. Even more so when you remember that PhoneGap Build automatically injects a copy of
cordova.js (whatever version corresponds to your app config) into the root of the
www folder... And that one is 226kb. So we're looking at a lot of wasted space. I suspect that none of the three of those files in the
/CFIDE/cfclient/ folder are needed for the app to run (just the one injected by PhoneGap Build) -- nor even used for CFBuilder code insight.
When you look at
/CFIDE/cfclient/dfni/dfnimain.js, you can see that these cordova files are included for the case when you're not compiling on PhoneGap Build. Clearly there's some clean-up necessary. It should remove unnecessary cruft at compile time.
There's not much more of interest to say about the
useragent.cfm file, but it's not plain text. It doesn't look like any cfencoded file I've ever seen either, so I'm not sure what to make of it just yet.
I certainly hope they're generated, because file names like that would scare me if chosen by a person. They all have the obfuscated variable names again, so that sets my mind at ease: Very likely generated.
So there are a lot of these generated files. None of them are all that large, and none of them seem remarkable. It's just not a very clean approach to put them all in the root like this; or to have them all separate for that matter. If they're going to be obfuscated and unreadable, why not just lump them all into one file?
I'm actually a huge fan of LESS CSS, but unfortunately, not of the way it's been implemented in this app. The app loads the
.less files, though it's unclear if they are all actually loaded and transformed into CSS by the browser. They use the
media attribute of the
<link> tag to specify some media queries. For example:
media="only handheld, screen and (min-width:1224px)".
The HTML doesn't appear to the the cleanest, either. It remains to be seen -- Adobe say they're planning to release the source (presumably the pre-compiled CFML that uses CFClient) of the app after the summit is over -- if this is the fault of CFClient or just poorly executed HTML by whomever wrote the app. Index.html consists of:
- 4 LESS file includes
- 1 CSS file include (bootstrap)
- 1 meta tag
- and a single div with a small smattering of content
Published 2013-10-25 @ 10:30 in
Test Driven Development is great, right? But wouldn't it be great if you didn't have to jump over to a browser window and refresh the tab every time you wanted to run your test suite? Sure, MXUnit has an Eclipse plugin, but if you're not using an Eclipse based IDE, that's not much help to you.
You can find it on GitHub, and you can install it from NPM (requires Node.js):
npm install -g mxunit-watch
Feedback, bug reports, and patches are all welcome.
Published 2013-10-14 @ 09:00 in