Digital Ninja

Just wrangled a new (well, used but new to me) MacBook for office use and I wasted no time getting a development installation of ColdFusion on it so I can work with examples and code when I go to CFUnited Express in Atlanta in a handful of days. I had no idea what I was doing because not only am I a fairly weak Apache administrator, but I'm also a Mac noob. Here's what I did.

Quick Note: Any manual file creation/modification steps may need a "sudo" command for root level permissions. For example, to edit a configuration file with vi (or pico, ya cowards) you would type: sudo vi httpd.conf

ﾠ

1. Make a dummy httpd.conf file in /etc/httpd/ if it's not there (more on this later)
2. Install ColdFusion 8.0.1 using the following configuration values:
   1. Choose third party web server connector for Apache
   2. Point it to /etc/httpd for configuration and /usr/sbin for the application/server directory
   3. The document root (to install CFIDE into) should beﾠ/Library/WebServer/Documents
3. Open the Leopard Sharing preferences to turn off then turn on again the Web Sharing service

My goal with this blog is to help other folks find the tools and tricks that help me so much. Here's one that I'd like to plug. It's a project I found on RIAForge called Deployment Builder. It was made by the hands of developers (Rob Brooks-Bilson and Adam Crump are involved) doing exactly what my team and I are trying to do, which is ease the deployment process for projects from the source code repository to any environment, whether it's staging or production.

There are two things that might make you hesistate, if my guess is right. The first is, "that's a lot of power to put into a tool/application." You're right for thinking that. The fine folks who built this tool have jumped through some sophisticated hoops to make it very well secured IMHO. I endorse their efforts and applaud the result. Being that it's installed, not hosted out there somewhere, I feel very comfortable with the product in this regard.

The second question I'm guessing you'll ask is something like, "My infrastructure is complicated - it would be a nightmare to configure this into an application!" Yes, you might be correct here. I found, however, that this application will take you at least 60% there, depending of course on where "there" is. For me, "there" was telling Deployment Builder the tag in SVN I want to deploy, the server (configured as a name and FTP host) I want to send it to, and then click "GO".

Nothing will replace the human factor here, but I see a dramatic speed increase coming now for the team and an increased "nimbleness" entering play that will allow us to juggle entire versions of products we're staging, testing, and pushing to live. No, I still don't have my one button trigger to get that OneHugeApp(TM) onto the load-balanced ColdFusion pool, but I can in just a few clicks anyway. It's a start.

And it's open source, which means perhaps we can contribute to it to help get it where it needs to be to make those kinds of things happen in one click. My motto lately has been the constant mantra, "there is no original problem." Finding this tool was a reassurance of that mantra.

Chronicled within this somewhat lengthy post I detail my growing knowledge about how the current implementation of the custom Coldspring lexicon for Fusebox is falling short of my needs. I decided to do some research and try to make it better. Lots of progress was made, but there's more to go. Read on for details and code samples...

Read more...

Woe is me, I've been sat on a stool by Subversion. Well, let's be serious. Not really by Subversion, but by a hosting provider, Apache, and my own unpreparedness. But it's easier and less wordy to simply blame Subversion (although not fair). Let me take you through my series of events.

First, the free project host Assembla made an announcement early this week that by the end of this week their initially-awesome and free service would no longer be free, and therefore not quite so awesome. They basically said they're locking things down on JAN 9 so pay up or get off the server. I'm sort of in the middle of a project I was hosting there, and I'm not feeling in the giving mood so I'm outta there. You can disregard my positive-toned blog post last year about how great Assembla was. The free SVN hosts out there many, and yes Assembla - they also do project management and ticketing solutions! For free!

So all of a sudden I'm looking for a new host for my SVN repo of a private project I'm working on. A colleague recommended Beanstalk, which I had already found and was considering on my own (not to mention I saw it pimped by Versions). So with all signs pointing to Beanstalk, I'm headed over there for a little while to test the waters. I might even become a paid member. The rates are good.

I was able to download a Subversion dumpfile of my work, but it's not in a very cleaned-up state. I wanted to do some filtering with it, and I needed Subversion. So I downloaded it and tried to install it but the Apache WebDAV wasn't playing ball. Turns out I have an older (2007!) version of Apache, which was part of the XAMPP distribution from Apache Friends. That's an excellent package, by the way, and I recommend it for anyone wanting to throw together their own development server in near-zero seconds. The ColdFusion 8 installer will play nice with it, too, and get it's hooks in.

Skipping a few details and hours of frustration trying to get configuration from the Collab-bundled install of Apache into my XAMPP installation, let me just say that it was all about my older XAMPP. I threw some caution to the wind, only backing up my Apache modules and the conf directory, and did an overlay install of the latest XAMPP over the old one. Whala! It's all working. All of it, including the WebDAV SVN integration and the MySQL configuration and heck - CF is alive and well!

Looks like I lucked out this time, sort of. Now I'm going to use the SVN dump filter to trim up my dump file and import it to Beanstalk, beginning chapter two of this damned SVN hosting ordeal. And I guess I'm about to become a Basecamp man, too. I was really trying to avoid that for some unknown, inner-child reason.

If I had a quarter for every time this tag, which was forged upon the anvil of evil and chaos, got the best of me and my time I'd be able to... I don't know. Hire Adobe to write my code for me?

The CFLOGIN tag and the attribute-of-disdain known as loginStorage has smote me. It's my own fault for not understanding the difference between choosing "cookie" (the default, and my God just leave it be!) and choosing "session". I chose "session", thinking of course I'd like it in the session. All session based things, authentication included, ought to be in the session. Uh... no.

What started happening was that I would authenticate fine, establish my CF login and my roles, and it all looked okay. A CFDUMP of my credentials immediately following the CFLOGINUSER would yield just what I expected. However, the very next request would forget who I was entirely!

<cflogin>
	<cfloginuser
		name="#attributes.j_username#" 
		password="#Hash(attributes.j_password)#"
		roles="administrator" />
</cflogin>
<cfdump var="#GetAuthUser()#" />
<cfdump var="#GetUserRoles()#" />
<cfabort />

Now I'd like to give some credit to Ray Camden for his frustration with this a long time ago, which is featured on this blog post. Also, please take note of this adorable post in the Adobe Knowledge Base about the issue, which basically says don't use loginStorage="session" because it's a security risk. Whiskey Tango Foxtrot!?