Well, the cat is out of the bag now.  Railo, the free open source alternative CFML engine to Adobe's ColdFusion Server has been forked and reborn as a new product called Lucee.  I was lucky to be part of the launch party (via webcam) that happened this morning in London.  This is a major event in the tiny CFML eco-system and it's understandable that there's a  lot of questions floating around and confusion on just exactly what has happened.

There are a lot of large open source projects that have forked before.  For instance, MySQL spawned MariaDB, OpenOffice, begat LibreOffice, Hudson turned into Jenkins, and even recently Node.js was forked int IO.js.  In some cases, the original project continues alongside the new one.  In other cases, the old project basically sits there and everyone stands up, shuffles over to the new one, sits down and continues as if nothing happened.  I personally think Lucee is going to be more like one of those.

I'm throwing together this post to address some questions that have come up over and over again today.  Hopefully they will be answered more fully by the Lucee team as they dig out of this major announcement, but in the mean time this is a compilation of some answers I've given multiple times today around the Internets.  Please note, I am not speaking on behalf of Lucee nor Railo, these are my opinions and observations mixed with some info I've picked up along the way.  I'll happily accept corrects or clarifications in the comments.

Yes, that's right.  Wherever you are and whatever you're doing, it's time you had a look at what's happening over in ColdBox 4.  I'm just giddy about our newest release of the most-advanced CFML MVC platform.  If you want to read all the details of what makes ColdBox 4 absolutely slap-yo-momma amazing, you can read the press release over on the engineering blog or the What's New guide.  

Even if you are using an older version of ColdBox, we're re-imagining the way CF apps are built and I think you want to be onboard.  This is my personal blog though, so here you'll find my candid, personal, and extremely biased opinions on why you're doing yourself a disservice if attempting to build meaningful ColdFusion applications in 2015 without ColdBox 4.0.  Fair warning, I'm about to tell you how I really feel :)

In my last post I played with the Media API to add sounds effects to the Roll The Ball game and made an Adobe CF Soundboard.  Today I'll be showing my work with the Geolocation API.  I wish I had some more time to do something more useful, but the CF mobile contest is drawing to a close tonight and I this will be the last feature I have time to put in.

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

Previously I played with the Accelerometer API make a "roll the ball" labyrinth game.  While I found the accelerometer API easy to implement, my experiments with the Media API proved less fruitful.  For a while I was afraid I would be unable to show anything at all, but after a considerable amount of fiddling (and Googling), I was able to get it working.   

The Media API contains function for capturing audio and video as well playing back audio.  The first thing I did was add some fun sound effects to my "roll the ball" game.  And secondly, I made an Adobe ColdFusion Sound Board.  But first, I had to get it working.

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.

A twitter user named @JesusFreak84 pointed out that Cloud9's web-based editor service didn't support syntax highlighting for CFC files. Cloud 9 is a pretty cool concept.  I gave it a try and after just a few clicks, I logged in via GitHub, cloned a repo and was editing my code in their web-based editor.  It's pretty slick-- except for the fact that it needs some CFML love.  After a bit of digging I found this bug Mike Henke put in back in 2012 but it never really went anywhere other than a lot of "me too!" votes.

Cloud9 lists ColdFusion as a supported language and it seems it may have come through this p

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.