Coder's Revolution

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 :)

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.

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:

Create a folder somewhere on my hard drive to host the root of the site

Add new context to Railo's server.xml using the same hostname and web root

Add site to Apache w/permissions and reverse proxy and rewrites

Restart Railo and Apache

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

Visit the coldbox.org download page

Download the necessary version of ColdBox

Unzip it into the web root

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.

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.

I'd like to thank the Chicagoland user group for letting me present on the ColdBox MVC Platform tonight-- I had a great time. Here is the recording URL and slide deck. Be forewarned, I spent most of my time building a simple ColdBox app from scratch that showed bare-bones usage of MVC, models, logging and caching. I'm ok with that though, I always prefer to show via examples than boring slides :)

Show Recording

Slide Deck

I'd like to thank Dan Fredericks and the NOVA CF UG for asking me to come and present for them last night. I was given the floor to present whatever I wanted to regarding ColdBox as part of their History of CF Frameworks series. I had a great time and was happy to be able to talk about some of the exciting things coming up in ColdBox's future as well as some demonstrations of CommandBox, the new CLI, REPL, and package manager for CFML developers.

With the release of DataBoss 1.3 today, I thought I'd share a quick story about my recent first project diving into DataBoss. Full disclosure: DataBoss is a commercial product and I work for the company that makes it. None the less, I thought it was pretty freaking useful so I thought I'd throw out this quick post.

For those of you who don't know what the heck DataBoss is-- it's a Dynamic ORM Administrator. Basically, it can scaffold out CRUD (Create, Read, Update, Delete) screens for pretty much any database structure and it's all based on ColdFusion ORM. It runs on Adobe ColdFusion as well as Railo and the minimum to get it running is to create ORM entity CFCs, drop them in your models folder and reload ORM via the interface. It will pick up your entities, read all the relationships, and create all the screens necessary to manage the data in your database complete with formatting, validation, rich text editors, date dropdowns, etc.

So, the recent project I got assigned was for a company that does development services. They had a project they had been working on for one of their clients that involved a nicely-normalized database of about 20 tables that supported a multi-lingual ordering and reservation system. They had the front end system built out with ColdFusion but the problem was the deadline was getting very close and they weren't going to have to time build the backend of the system that allowed all the products, descriptions, and companies to be configured. They needed to have a backend over to their client in a matter of days to start entering data, but there simply wasn't enough time to build one from scratch.

Enter DataBoss. I was tasked with setting up a data-entry app they could use to manage their database until they had time to finish the backend. The database that had already been built was well-structured and contained many examples of one-to-many, many-to-one, and many-to-many relationships. I was given a backup of the data structure and a diagram that showed all the foreign key relationships. Using Adobe's CFC Generator for ColdFusion Builder, I selected the tables via the RDS datasource view and stubbed out all the ORM entities in script. Don't try to use the CF Builder plugin to create relationships. It's horrible and you'll be sorry. For just stubbing out the entities and the properties, it's pretty good though and saves a lot of time.

DataBoss is packaged as a portable ColdBox module which means you can drop it into an existing ColdBox app, or just deploy it as a small standalone app. I chose the latter and dropped my ORM entities in the /model folder. After adding my datasource name to Application.cfc and changing dbCreate to "none" the app sprang to life and displayed a list of all my entities in a drop down. There's settings in a JSON file to control pagination as well as the internationalization of the DataBoss app itself. DataBoss already comes bundled with German translations which was nice since this project was for a German company.

At this point, I went through and configured all the relationships and added metadata to each entity and property that controlled how it displayed on the screen, what kind of validation it applied, and what form controls to display for each field. After a bit of tweaking, we had really nice CRUD screens fleshed out that even used 24-hour clock and dd/mm/yyyy date formats to match the local standard. I enabled the Basic HTTP Auth built into DataBoss, and it was ready to deploy publicly! All in all, we had the entire admin finished and ready to deliver to the customer in just a few days.

I was pretty pleased with how easy it was to get working, and was a major saver for them to get the edit screens to their customer in time. And now, they can use those ORM entities for future development on the application. DataBoss Standalone is only 99 bucks which isn't bad considering the time it can save you. Think about using it for that old legacy database you have no edit screens for, or to help you create your next database. You can also download a trial to play around if you want.

In my last entry, CFML, Meet Runnable.com For Live Code Sharing, I talked about what Runnable.com is and why it's worth looking into for anyone who's looking for a nice platform to publish live working code samples that people can launch in their web browser. Today I'd like to cover the steps I took to getting CFML working on Runnable as well as gotcha's and other bits that weren't immediately obvious. The great thing is, you don't have to know most of this to publish your own code! Just click on one of my Runnables, click the "Save Draft" button, change the name, description, and code to your liking, and then Publish it! You don't have to start from scratch; you can spring board off of my work. For those of you who want to do it your way or are just curious, keep reading.

As discussed in the first post, each runnable is stored as a template of a Linux server called a "container" and is managed by a technology called Docker.io. When a user comes to the site and clicks a runnable, a unique lightweight "instance" will be spawned from the container template just for that user. This instance actually runs inside of a master linux instance that it shares resources with, but it is completely isolated from all other instances. It will also be destroyed when the user leaves their web page. As such, site users have root access to this instance and can run whatever commands and write whatever code they want, but they are isolated to their instance and securing the runnable is not necessary.

Here's a list of items in no particular order that I wish were documented somewhere on the site when I started:

Installing Software

As far as the server you set up, the world is your oyster. Any servlet container, CFML engine, and configuration is valid as long as it runs on Ubuntu.

Note, I had issues getting the Railo Linux installer to run. I have logged this issue with the Runnable guys.

I installed Tomcat via apt-get and deployed Railo as a WAR file in the root context. To do this, delete the folder called ROOT under /var/lib/tomcat/webapps, rename the Railo file to ROOT.jar and place it in the webapps folder. After a few seconds, Tomcat will pick it up and explode it out. The /var/lib/tomcat7/webapps/ROOT folder is your new web root. I asked the Runnable guys to default the editor file explorer to there.

If you have them disable Apache, you can bind Tomcat to port 80 but I just set up a reverse proxy so I could use Apache's rewrite module.

Configuring CFML

The config for the default Apache site is located in /etc/apache2/sites-available/ in a file called "default".

By default the web root is /var/www. I changed the DocumentRoot directive and <Directory> tag to /var/lib/tomcat7/webapps/ROOT

I also changed the DirectoryIndex directive to index.cfm

I created a file called "railo.conf" in the /etc/apache2/conf.d directory. It is automatically included.

Check in /etc/apache2/mods-enabled and if proxy.conf, proxy.load, and proxy_ajp.load aren't listed, enable them with a2enmod
sudo a2enmod module_name

Tomcat web config is located In /etc/tomcat7/server.xml

Uncomment the AJP connector on port 8009

The web root is configured in the <host> block. Check it if you're going somewhere different than the default context.

When "running", if you break the page out of the frame, you can access the Railo administrator at the usual URL by adding /railo-context/admin/server.cfm to the end of the URL

I didn't set the Railo password, but there's not security concern if someone accesses it since the entire instance is unique to them.

Running Code

For a web framework, you don't need to change the "Run cmd" or "Build cmd" options that drop down on the "Run" button.

I would also recommend setting "Only Web" which will not show the terminal window along side the web page output.

When the Run button is pressed, a new window will open that hits your instance in an iframe. A DNS name will be created on the fly that uses a GUID to make it unique. You can click an icon to open your runnable address directly in the main browser tab.

Basically, whatever is spit back on port 80 in the web root is what the user will see. There is currently no way to have the "run" button target a specific URL or query string, but I have requested that.

If everything is set up correctly, you should see your default page rendered. If you've copied one of my runnables it will just work :)

Your sample can have multiple pages that the user navigates between. You can have an entire site if you want! I like to have instructions on the first page, and then links to view additional pages that show code running.

Gotchas

You cannot paste text into the terminal window. This is VERY annoying.

A very slick workaround if you need to download an extremely long URL is to shorten the URL with a URL shortner. wget will follow the 302 redirect automatically and it's much less typing.

You cannot SSH directly to the instance via PuTTy. I have suggested they allow this.

Apache is automatically running and bound to port 80. The runnable guys can disable that, but you can't. Whatever you do, it will come back.

Port 80 is the ONLY externally-accessible port. That means you can't run Tomcat on 8080, etc.

Tomcat will NOT start by default and there's nothing you can do to fix it. E-mail the Runnable guys and ask them to change your instance startup script to include Tomcat and they will happily oblige.

Tomcat takes a few seconds to spin up and Apache will throw a 503 the first time someone hits it. I have reported this issue, and in the mean time I placed a custom ErrorDocument directive in /etc/apache2/sites-enabled/default like so:

Git repos can't be cloned into a non-empty directory, so what I do is delete everything in the web root but the script and WEB-INF. Then I clone the repo into a folder called __tmp, move the files into the web root, and delete the temp folder
To pull down the code for a runnable sample, simply run:

$> ./.setup CFML_Templating_With_Tags

DON'T DELETE THE WEB-INF FOLDER. Doing so will remove Railo and CFML will stop processing. If you do this on accident, remove the entire ROOT folder, and restart Tomcat. It should redeploy the Railo WAR. My .setup script is located in the "admin" repo for cf-runnable. You can easily modify it to point to your own repo.

So the process for creating a new runnable is fairly straight forward for me. I create a new repo and copy over my last project into it including my .gitignore file. I set up my tutorial on my local install of Railo and when I'm done, commit and push to GitHub. Then I simply clone another runnable on the site with "Save Draft", edit the title and description and run "./.setup Repo_Name" from the command line and I'm done

Conclusion

That's enough of a brain dump for now. Runnable is basically as flexible as you could want it to be. Don't be scared away by all the stuff I typed here. Most of it is already done for you so go play around with one of my runnables and get your feet wet. I'll be adding more tutorials-- mostly centered around ColdBox and other Box libraries soon. I think Runnable.com can be a very cool platform for the CFML community to publish example code on.

Here's some of the runnables I've created. The full list will always be here.

You may have seen be tweeting about Runnable.com this week. I've spent a decent amount of time figuring out how their platform works and getting CFML (Railo) running on it. Basically, Runnable.com is CFLive.net, trycf.com, and JSFiddle.net all mashed up and super cool. In short, the platform lets developers post any code samples they want for any database/language/framework up on the Internet so other developers can come along and not only read their code, but run it right there in the browser. It doesn't stop there, other developers and fiddle with the original code and run the new version right there on the site to figure out how it works.

It's all possible with Docker.io, a cool virtualization platform I just learned about, and Runnable has the whole thing running on top of Amazons EC2. Basically, each code sample is an entire Linux VM with whatever installed on it that the publisher wanted to set up. The template of this VM is stored and every time a visitor comes to the site and wants to check out that code sample, a dedicated VM is spun up in seconds just for that user. Docker.io allows them to simultaneously service hundreds of users because it shares overlapping resources between the VMs so they're very lightweight and come online in seconds.

And since each user gets their own isolated playground, there's no sandbox security to worry about. In fact, each code page has an emulated bash shell with root privileges at the bottom of the page! Any local changes made by the visitors of the site, are discarded after they close their browser and the session times out. The code samples aren't limited to a single file of code-- publishers can create tutorials to demo entire frameworks, with multiple files. Need a database? Install one. Need Tomcat? Install it.

So, speaking of Tomcat-- this is where ColdFusion comes in. Runnable's Twitter account popped into a recent conversation and urged us to get CFML setup, so i took the task and ran with it. Due to some issue with the Railo installer which they're looking at, I installed Tomcat 7 with apt-get and deployed Railo 4.1 as a WAR file in the root context. The Runnable guys were super helpful. They exchanged several E-mails with me and even chatted on Skype for an hour last week answering questions, tweaking my setup, and writing down suggestions.

I published a proof-of-concept Runnable called CFML Templating With Tags and then a more involved followup called Use WireBox To Create Objects In ColdBox. I've also created a new GitHub organization called cf-runnable to store all my tutorials. Feel free to send me pull requests, or ask to collaborate and store your CFML runnables there as well. Now, what's really, REALLY cool about Runnable is anyone can clone one of my tutorials, make it their own, and re-publish it under their name. That means no one else has to reinvent the wheel to start putting cool code up on Runnable-- I've already figured a lot of it out and you can springboard off of what I've done, or dive in fresh yourself.

So this is the intro to a blog series I'm going to do how how I got Runnable working with CFML, what little speedbumps I've hit, and how I've been integrating with GitHub to version and host my code. I have a lot of ideas for Runnable- both improvements for them (like beefier descriptions, and embeddable runnables) and ColdBox-themed tutorials I want to create to let people play around with simple examples and how-to's. Stay tuned!