There is an open web developer position on my team at the Wharton School in Philadelphia, PA.

We’re a ColdFusion/Flex shop with an emphasis on rapid development. But experience working with other web platforms such as PHP, .NET, Java, Ruby, etc. will apply. It’s a junior level position. If you are strong on the concepts of web development, we are willing to help you learn a new language. I would also consider somebody who has mostly front-end experience that wants to dig a little deeper into the programming side of things.

If this sounds like something you’d be interested in, drop an email to dkonopka@wharton.upenn.edu and I can give you more details.

ColdFusion makes developing web applications insanely quick and easy. I don’t need to worry about the nuts and bolts of how to connect to a database, or how to invoke a web service, or how to read and write files on the server. I just write straightforward tags in my favorite text editor — and I’m done, web application launched for all the world to use.

But there are some things that web applications can’t do. They can’t really read and write files on the client machine. They can’t interact much with the client operating system. Drag and drop, PDF manipulation, copy and paste… the list goes on. And all that aside, an Internet application will never work without an Internet connection.

So how do you go about creating something that can do those things? A couple years ago, you were stuck building complex and clunky binary applications. So you have to dig into lower level languages like Java, C++, or any of the .Net languages.

Suddenly you’re working with compilers and writing 300 commands to do what one tag does in ColdFusion. Sure, you’re scoring points with the Java and .Net purists. But all that doesn’t leave a ton of time for the trivial things like the interface or user experience.

Enter the Adobe Integrated Runtime — AIR. You can use AIR to write a desktop application in Flex XML and ActionScript, or HTML and JavaScript. AIR exposes hooks in to the client system to handle a local database connection, catch drag and drop events, open up local files, and even render PDF documents.

So instead of writing complex machine code, you’re back to writing tags to define the interface. And you’re calling a simplified scripting API to do heavy lifting under the covers. And the API runs on both Windows and Mac, so your pool of potential users is not limited to one operating system.

Have you already written a full web application in Flex or AJAX? You’re only a few steps away from adapting the same code to run either online, or on the desktop. Maybe it’s a little of both.

Flickr has offered a pretty slick upload tool for a few years now. It’s an executable that you can install on your desktop to do drag and drop file uploads. Somebody at Flickr had to develop separate binary Windows and Mac executables.

With AIR, that’s something you could in one shot. Don’t believe me? Check out Matt Chotin’s MediaWiki uploader AIR app. They’re different underlying services, but it’s a great example of how a web app can be extended to the desktop.

AIR does a lot to bridge the gap between web and desktop apps. But just like ColdFusion did for web scripting, it makes building all the parts easy. And you get to use tools that you already know exactly how to use.

Now you can get back to focusing on what’s really important: building better software.

I just posted the code for a dual select box ColdFusion custom tag called cf_SelectSwap.

It takes a query of items and produces two DHTML list boxes. Users can pick items from the available list and move them to the selected list. The selections are stored to two form variables. The first is a list of selected values, the other a list of selected display text values.

If a user has JavaScript disabled, it degrades down to a single list box with items selected. It can be used multiple times within the same cfm template.

Nothing earth shattering, but I put it together in the middle of a project I am working on. Maybe someone else can get some mileage out of it.

There’s an interesting discussion about programming frameworks going on over at the Wharton Computing developer blog: Why Not Frameworks?

Wharton Computing is where I work as a ColdFusion developer/administrator. There’s fifteen or so full time ColdFusion and Flex developers, and ten or fifteen more part-time developers scattered throughout the school.

It’s great to read what people think about the place of programming frameworks inside a school where the focus is on rapid and flexible development.

I’ve got to echo the sentiments of everyone else: cf.Objective was a top notch conference.

I can’t think of a session that didn’t offer something new or challenging to think about. The smaller crowd allowed for some great interaction with community gurus and other developers. And the double-stuffed pillow topped beds, fresh carved pork lunches and artisan pastries were certainly nice touches too.

Overall, I came away with the challenge to improve my coding practices increase the planning that I put into projects.

At one point Terry and I were lobbying Mark Drew, lead developer of the CFEclipse project, to include more remote development features in CFEclipse. Remote development is how most of the developers in our shop work, but it definitely isn’t the industry standard.

Mark questioned why he should divert time away from other enhancements to build in support for bad practices. He used the analogy that if everyone had a six inch pointed spike fixed to their car’s steering wheel, we’d all be much better drivers.

Avoid cutting corners in any software development, plain and simple. There may not be a sharpened spike staring me in the face when I write code, but bad practices usually have a way of catching up.

I think it’s time to overcome my aversion to frameworks. I’ve always been worried about a hit to application performance and keeping up to date with framework code changes. But it’s becoming increasingly difficult to turn away from the industry tested patterns and practices that frameworks enforce. That’s not to mention all the repetitive busy work that frameworks automate so that I can focus on building better apps.

I’ve been using Ray Camden’s and Adam Podolnick’s ColdFire Firebug extension for a little while now. For those who haven’t tried it yet, the Firefox extension displays ColdFusion debugging info in a separate panel instead of appending it directly to the bottom of each page. It’s powerful stuff if you’ve ever had a page layout mangled by the vanilla debug dump.

Part of the setup for using ColdFire is deploying a customized debugging cfm template to your server. I never knew this — but ColdFusion actually uses a cfm template to parse and format the debugging output that ends up on each page. You can actually edit this file to customize the output on your system.

I wanted to get ColdFire working on our shared development server at work. But I knew not all of the developers would be on board to start. Luckily, the debugging cfm executes within each application. So the session and application variable scopes are available inside it.

The server debug template can alternate between the default debugging dump and ColdFire formatted output by checking for the existence of a session variable. By default, the server will append the default debug information. But each developer can set a session variable inside an application event or on individual templates to fire the ColdFire formatted output.

This is what your debug template looks like:

Day two of cf.Objective and my brain is approaching maximum capacity. But, there’s only one more day of sessions to go.
Read the rest of this entry »

Yesterday was the first day of sessions, and it was packed with great information. I learned some new stuff in every one of the sessions. Lots of other people are covering the details, but here’s what stuck with me.
Read the rest of this entry »

Not much to report yet. I flew into Minneapolis this afternoon, shuttled to hotel and checked in.

The welcome reception was very friendly, a good chance to mingle and put some faces to the names in the ColdFusion community. I also got to meet a few new faces — I’m always happy to dish about CF.

After a few drinks, I fear I may have disparaged Asp.NET a bit too much. I’ll try to keep it positive the rest of the conference

Desktop and dashboard gadgets are particularly useful when they pull in dynamic information from the web. ColdFusion can make it really easy to supply your gadgets with dynamic data.

No matter what platform you choose — gadgets generally rely on HTML and scripting code just like any web page. You might be sneaky and squeeze some Flash or Silverlight into the mix, but the same concepts still apply.

Without the traditional back/forward/refresh functionality that web browsers provide for web pages, you’ll need to rely on AJAX methodologies to access and process data within your gadgets.

Where does ColdFusion fit in?

Since gadget files reside and render on the user’s machine, you’re stuck using vanilla DHTML for the front-end. But the front-end needs to retrieve dynamic data from somewhere. That’s where ColdFusion comes into play.

Read the rest of this entry »