Fanax: the Mycenaean term for "king"; pronounced "wanax". The funny initial letter, "F", is called digamma and shows up in Archaic Greek epigraphy (papyrus and tablet writings). The sound, if not the letter form, and its linguistic equivalent initially show up in the heiroglyphic writings (Linear B) of Bronze Age Greece both at Pylos, in the far west of Greece (Peloponnese), and at Knossos in north central Crete, the funny "F". Specifically, digamma shows up in the Greek of Homer's Iliad with the word "F"anax, but there it's a "rough breathing" in the form "(h)anax", where the term is linked to an important individual at Pylos. In Classical and Hellenistic Greek, the F continues in this aspirant, or "h" sound, form at the beginning of many Greek words.

Entries Tagged as ColdFusion

A Lesson on How to Write a Rant

April 24, 2012 ·

Now, I'm a CFML user from way back, and it continues to be my language of choice.  In business, however, other matters impact decisions of platform and staffing, and I have hired a number of .NET programmers (including a Java programmer to do .NET).  We use only frameworks for our web apps, but nonetheless, Doug's got this Nailed.  Not only is it true for so, so many .NET programmers, but it's just a beautifully visceral and nasty rant.  Well done, Doug, well done.

Tags: ColdFusion · software development


October 15, 2008 ·

Thanks to Dan Vega for posting this brilliant gem, linked back to!

Ben Forta (The ColdFusion Evangelist for Adobe) on who should NOT use ColdFusion:

Click this link for the video


Tags: ColdFusion · software development

Arehart's Master List of CF Resources

September 04, 2008 ·

Charlie Arehart has just re-arranged his awesome list of CF (and non-CF) links, publishing the entire library at a new URL:  If you're a CF user, use it and tell your friends about it!

Tags: ColdFusion · software development

Deliver a Redirected File

August 24, 2008 ·

So a few weeks ago, my low-cost, shared hosting account began to reach / pass capacity, as a client got further and further into weekly video uploads.  These were church messages, so each about 25-30 minutes long, and quite large.  The cost of adding additional storage seemed out of line with the costs of other services which are just "online backup" or "online storage".  Most of those services focus on providing free storage, however, and they don't allow direct-linking; the user has to go their website to link the file.  This wasn't going to work since I wanted to be able to put the Flash player widget on the page and show the video which had been uploaded.  (They're *.flv anyway, which means they don't play without a player to begin with.)

After trying several different free accounts (,, and learning the ins and outs of each, I settled on MediaFire, a vendor with very low cost and very high storage / bandwidth.  They claimed to allow direct linking, so I thought I was set and good to go.  I purchased the pay-per-month plan, since you don't get their direct linking for free, and uploaded the first file.  I found that I could direct link to it and download the FLV, but I could not get the URL to work as the param of my Flash player.  What was going on??  After some more digging and a quick Live Chat to the service's support (love Live Chat support!!!), I realized that while they give me (the owner) a very nice, readable, share-worhty link (such as, the service actually redirects on their side (to something like, which actualy even uses the original file name).  The given short path is perfectly fine and works transparently when linking to a Word doc, for instance, but certainly doesn't work at all as the file param in Flash.

But, CF came to the rescue again, as usual.  After worrying I had picked the wrong service, it suddenly dawned on me that CFHTTP has a redirect param which can be set to 'No'.  Doing so returns the URL of the redirection, that is the 'true' destination / location of the file.  All I had to do then was add the unique part of MediaFire's file storage key to my database, and then run a quick CFHTTP to get only the URL (not the file, which would take 45 minutes to load from server to server), and then generate the Flash object with param = cfhttp.response.  So, after a file is FTP'd to our web server, the local path will work fine; if the file has been moved to MediaFire, then it doesn't exist locally, and I can test for the 'mf' key in the DB.  If I get a response, then the code swaps the path variable and continues to the object call.

<!--- "v" gives the file name of video, if it's there locally --->
<cfset v = viewState.getValue("v")>
<cfset mov = "../swf/" & v>
<!--- "mf" stores the MediaFire key --->
<cfset mf = viewState.getValue("mf")>
<cfset movFile = expandPath(".") & "\swf\" & v>
<cfif not fileExists(movFile) and len(mf)>
 <cfhttp method="GET" url="" redirect="No"></cfhttp>
 <!--- the response header now has a 'location', which is the redirect URL --->
 <cfset mov = cfhttp.responseHeader.location>
 <cfset v = listLast(mov, "/")>

Simple. Brilliant. Effective.  Love the CF!

Tags: ColdFusion · software development

Powered by Mango Blog Questions? Comments? Wanna say 'hi'? Write to us! top