So this blog is a bit of a spill over from a Twitter conversation I had today with Stefan Mischook, a PHP programmer and maker of all sorts of training videos at www.studioweb.com and www.killersites.com.  A few years ago, Stefan uploaded a video blog to YouTube titled "Should you learn Coldfusion?" (sic) where he presented a not-so-glowing review of ColdFusion through the lens of circa 2003.  I've seen the video before come up in YouTube searches.  Part of that is a testament to the pathetically small amount of actual CFML content on YouTube.  While I've recorded a number of screencasts and webinars that are posted online, they're all on Vimeo or Adobe Connect so alas I'm not contributing to that specific site.  

• www.youtube.com/watch?v=dLJpz

In  my last post,  I tackled two APIs-- notifications and contacts.  Even though I wasn't able to fully explore the contacts, I managed to get things working without too much troubles.   I'm occasionally hitting some weird parsing issues in CFBuilder or underlying JavaScript errors I can't explain but "rearranging" my code will usually make it go away (more on this later).  I'll try to go back  and put in tickets for these after the fact, but I'm always reticent to shout "BUG!" in a crowded theater when I'm not 100% I'm doing it right.

Accelerometer

Well, let's get right to it.  Today I played with the accelerometer API which is incredibly simple in terms of the API's surface area, but rather deep in applications. 

My last entry was a little light on the client APIs and mostly spent (unsuccessfully) wrestling my HTML markup around.  So,  to make up for it, I've implemented 2 different client APIs.  That's right, two for the price of one!  The first was notifications which was pretty straightforward, followed by contacts which is kind of complicated-- well, let's just say "involved".

You may notice in the screenshots that the app is no longer full screen.  I didn't care for that so I found the fullscreen preference under the project's PhoneGap properties and set it to false.  This setting does not appear to be stored anywhere in the web root though, so if you check out the code into a mobile project of your own you'll probably have to set it yourself too.

In my last entry, I discussed my decision to  create a "CFClient Sampler" app that would simultaneously allow me to play with each mobile client API, all the while providing the community with some nature of blog-based documentary on my attempt.  With a solid proof of concept under my belt (and on GitHub) I pushed forward with two goals in mind this time:

1. Pick another API to play with
2. Figure out some organization for the code before it got out of hand
3. Ok, I guess there was a third goal too:  Make it not so ugly.

I'll start with the last one, which was to make the app not look like a middle schooler banging something out with Microsoft FrontPage.  Quite frankly, I suck at UI stuff.  I'm a "function over form" guy and I'm quite happy architecting the back end of an application far far away from the perils of CSS, responsive layouts, and viewports.   For this I used my phone-a-friend and dialed up jQuery Mobile.  JQM has been around for a while and it doesn't make web pages that very unique (kind of like the BootStrap cookie cutter sites) but it's stupid simple to setup and covers every major navigation, button, control, and layout concern I'll be detailing with.  

So, in my first entry I discussed that I'm trying my hand at CFClient, mostly drawn to the idea of winning a $1000 gift card from Adobe.  Previously I followed Ram's YouTube videos and articles on setting up a Mobile project in ColdFusion Builder, installing his sample app, compiling that app via Adobe's cloud-based PhoneGap server, and installing it.

This venture was met with mixed success.  The PhoneGap shell app which allows one to test without needing to recompile after EVERY code change fell flat out of the gate for me.  I'm still waiting to hear back from Adobe on that.  I was able to compile and run the sample app, but couldn't get the file APIs to work.  I've sort of given up on that for now-- there's just not enough time to keep banging my head on that wall for the time being.

This didn't start as a blog entry.  I originally typed it up as an E-mail to Anit Kumar, Adobe's rockstar support guy who offered to help me on Twitter.  See, I'm trying to build a mobile app using ColdFusion 11 mobile technology to have a chance at winning the $1,000 prize from Adobe's little contest.  If you didn't know about it, please forget about it-- I don't want any more competition :)

So after several hours of fiddling yesterday, I got a lot of the workflow understood and working but still have some major hang ups and questions.  After I finished typing this E-mail to Anit, I thought to myself, "Self, why not make this conversation public so everyone can benifit from it?"  There's precious little information about CFClient out there already and some people like Adam C has already expressed interest in hearing my experiences-- not that I expect to sell him on CFClient or anything :)  

This is a little rambly and I apologize for that.  I'll try to blog some more organized thoughts after I get this all working.  So, without further ado... Anit, please reply here if you can just so everyone can benefit from the answers-- even if it means I'm a numbskull and did it all wrong.

There's an interesting project going on over at code2014.com to see what languages were used the most this year.  Now, I have to preface this by saying that I generally dislike these sort of popularity contests.  They give the appearance of something statistical, but only represent a subset of the population that's exposed to them and bothers to vote.  Perhaps I'm also just bitter since CFML seems to get shafted by a lot of these sort of things.  (See the Tiobe index for details)

But nonetheless, I've thought a lot recently about the declining mindshare of CFML in the eyes of other developers (or the complete lack of knowledge of it in some cases).  This is easily evidenced by attending a non-CFML conference and telling people that you're a ColdFusion programmer and observing the disbelieving stares.  So, I think it's in our best interests to increase the presence of CFML on the Internet in circles outside of ours where we all know it's a great, modern language used by many.  It's honestly hard to blame people for asking if anyone still uses CFML when they literally haven't heard a mention of it in 5 years.  News like the recent addition of Railo to Bitnami was huge for CFML and I was happy to see the CFML community gathered and voted it straight to the top for the entire month.

So, go vote.  Right now. it's easy, just Tweet out the names of all the languages you've used this year with the hashtag #code2014 somewhere in the message.  At first, they didn't even have ColdFusion or CFML on the list, but were quick to add it after several people on the Internet brought it up.  I'm unclear on whether they're counting "CFML" or "ColdFusion" so you might add both just for good measure. 

---------------------------

Update, Hybrid group confirmed they are looking for both CFML and ColdFusion in their search:

https://twitter.com/hybrid_group/status/550060557596766209

I spend a lot of time answering questions on the ColdBox Google Group.  Perhaps too much time, since it's all volunteer, but alas I enjoy helping people.  Often times people can't get something working in their site like they want.  It may involve optional ColdBox libraries, specific handler setups, or modules.  The best way to help them is to actually create  their setup locally on my PC and try it out.  Of course, this can be a prohibitively time-consuming process just to answer a question.  

Boilerplate Drudgery 

I do most of my development on Railo, and setting up a new site consisted roughly of the following:

1. Add hostname to hosts file tat resolves to localhost like myProject.dev
2. Create a folder somewhere on my hard drive to host the root of the site
3. Add new context to Railo's server.xml using the same hostname and web root
4. Add site to Apache w/permissions and reverse proxy and rewrites
5. Restart Railo and Apache

Now, if this was a ColdBox site, I would also need to:

1. Visit the coldbox.org download page
2. Download the necessary version of ColdBox
3. Unzip it into the web root
4. Grab an application template, or use the ColdBox platform utilities in CFBuilder IF I have a project set up for this site.

Wow, NOW I'm ready to start replicating the user's issues.  That's a lot of work for a one-time site I'm going to delete in 20 minutes.  Now, what happens when I want to tell the other user how to set up the same site to test on their end?  I think you get the picture.  To be honest, I usually didn't bother and would just throw out a guess as to what the user's issue was.

Work Smarter, Not Harder

Enter CommandBox.  This is a CLI, Package Manager, and REPL and comes with an embedded server and a growing list of generator commands.  This means I  can open up a console and in a few SECONDS have a brand new site created in a folder of my choice with ColdBox installed, an application template generated, modules or handlers installed, you name it.  And then I just type "start".  That's it.  About 3 seconds later a browser window opens and I'm using my new test ColdBox app.  

Let's take a look at the commands I used earlier today to test URL routing to two different handlers with the same name in different subdirectories.  

mkdir myTestSite
cd myTestSite
coldbox create app myApp --installColdBox
coldbox create handler event userlists
coldbox create handler pdt\real\ldr\ldr_nm\ldr_portal\ldr_agt\event userlists
start --!openBrowser --force
server open URI="/index.cfm?event\=event.userlists"
server open URI="/index.cfm?event\=pdt.real.ldr.ldr_nm.ldr_portal.ldr_agt.event.userLists"

That created an app that exactly matched what the original poster had reported and even opened up the test URLs after starting the server.  What's even better is I actually threw those commands in a recipe file called makeSite.boxr so I could tweak the recipe and run it repeatedly like this:

recipe makeSite.boxr

This is the beauty of making something automatable!  Then, I pasted those commands back into the mailing list so the user could try the same thing I did.  And when I was done, I just stopped the server with the "stop" command and removed the directory.  It's like it was never there.

CommandBox has changed the way I develop.  Admittedly more than I ever thought it would.  Spinning up test sites, installing/uninstalling modules, or even trying out a few lines of ad-hoc code with the REPL is so easy now.  I even use CommandBox for my client work too.  I can start up multiple dedicated servers based on what I'm working on that day, and just stop them when I'm through.

I was honored to be able to present on one of my newly-favorite topics tonight to the Nebraska CF User Group: CommandBox CLI, REPL, and Package Manager.  CommandBox is a brand new tool and unequaled in the CFML world.  It has the potential to really bring CFML devs up to speed with the kinds of tooling and automation that other platforms enjoy if people really embrace it and help build the community it needs to thrive.  

I had a wonderful time showing off cool features and answering great questions with the group and others who joined online.  I've also had this topic selected to present at CF Summit this year so I'm soliciting feedback (good or bad) on the slides, demos, or presentation style to help me tighten up my talk some more before CF Summit.

Recording URL 1hr 30min:

http://experts.adobeconnect.com/p8q3zuxan1j/

Slide Deck:

CommandBox - Brad Wood.pdf

Links from the presentation:

• Download CommandBox http://www.ortussolutions.com/products/commandbox
• Source Code https://github.com/Ortus-Solutions/commandbox
• Forgebox http://www.coldbox.org/forgeBox
• Sample App w/Dependencies https://github.com/bdw429s/ColdBox-Dependency-Sample-App
• Command API Docs http://apidocs.ortussolutions.com/commandbox/1.0.0/index.html
• Usage Docs https://www.ortussolutions.com/products/commandbox/docs/current
• Google Group https://groups.google.com/a/ortussolutions.com/forum/#!forum/commandbox
• Training http://www.ortussolutions.com/services/Training
• Professional Support http://www.ortussolutions.com/services/support

I'm very honored to announce that my topic "Go Commando, with CommandBox! CLI + REPL + Package Manager for CFML" has been selected for this year's ColdFusion Summit  Last year's inaugural event was a big success in my opinion and filled with great people and great topics.

 CommandBox is a new command line tool for ColdFusion developers that allows for all kinds of cool automation and package management.  It's the first of its kind in the CFML space and I'm actually writing it as we speak!  The link above has a sneak peek video of some of its features and by the time CFSummit rolls around I'll have even more cool stuff to show like dependency management and task runners.  Here's the topic description:

Go Commando, with CommandBox! CLI + REPL + Package Manager for CFML

A software craftsman is only as good as his or her tools, and quite frankly-- most CF developers' tools suck. For years CFML developers have relied on IDEs and text editors for their work, but what about when they wanted to spin up another server, install a library, scaffold out another site, perform a repetitive task, or just try out a snippet of code? The answer is that they did it manually. And what if they needed to do it again the next day? It was the same old story! Even though CFML as a language has modernized over the years, other platforms have advanced in the arena of developer tools while many of us still sit at work all day staring at the same glorified text editor. If you've only ever used CF, you probably don't even realize what you're missing, and it falls in 3 main categories:

• Power and expressiveness of tools
• Sharing and acquiring code with the community
• Productivity through automation

A GUI may provide the lowest entry barrier and initial intuitiveness, but it always comes with limits and restrictions to what you can do, and how easily/quickly you can do it. A Command Line Interface (CLI) is a common paradigm with a simple interface that can support any number of commands for all the common tasks you perform on a daily basis like creating new bits for your application, running tests, installing 3rd party libraries or starting a server. Another useful ability is to be able to run ad hoc CFML code without needing to spin up your CF engine. What if there was a simple text-based API that ran the same on Windows, Mac, or Linux to do all that?

Quick, how do you install the latest version of library XYZ into your site? (Please tell me you're using other developers' hard work and not writing everything yourself). If your first thought was "open up a web page and download a zip file", stop right there-- Brachiosaurus just called and he wants his workflow back. Other platforms have made their name in perfecting the art of gathering community libraries into one standardized format that can be searched for, manage dependencies, and downloaded with a simple command anywhere and any place. Forget the zip files-- what if you could just type "install XYZ" and go get another cup of coffee? And that ABC library that XYZ depends on-- don't worry it will be automatically installed as well.

Some of your day-to-day tasks might not seem so bad. So you create a new site for each new client every month with the same defaults and base libraries. You manually check every couple of months to see if any of your libraries have new versions. Every day you run your unit tests a few dozen times. And every time you need a new controller you copy the last one you made so you don't have to look up the method signatures again. Every one of those tasks should be scriptable and repeatable-- work smarter, not harder! What if you could create a "recipe" for a new site with all the goodies you like and just run the installation and setup with a single line of code to guarantee it was the same every time? Or what if running your BDD test suite was as simple as typing "testbox run"? You don't have time for boilerplate activities all day long, that coffee isn't going to drink itself!

A CLI, REPL, and Package Manager aim to help you be better, faster, and more powerful at everything you do. Come "up" your game and discover the power of CommandBox as part of your new everyday workflow. Go Commando!