Enterprise ColdFusion

I am entirely too obsessed with work and as a result I tend to only get to read the House of Fusion lists sporadically at best. I was reading it today and a topic crossed my eye that I had to check out "JREE Servers (was Session Management - sticky sessions)." Brad posed the question, how many people out there use something other than JRUN, or even multi-instance JRUN. I've often wondered this myself. In our Enterprise we've been running ColdFusion on JBoss for 2+ years now, we ran in CF7 unsupported. Over the course of the next few months I'm going to try harder to post some of our experiences with ColdFusion and Websphere. I'm also going to push one of my peers, Bob one of our Technical Leads, to start posting too. Bob has had a wealth of experience getting things up and running and has taught me a thing or 2 about connecting all the different pieces/parts together. Anyway, reply to the list or reply here but let everyone know, are you running ColdFusion on something other than JRUN?

Here's a quick rundown of our setup:
2 Different environments.

Environment 1: IHS, Jboss (4.2.1), mix of CF8 and CF7, AIX Servers with IBM 1.4
I do not have all the specifics on this environment b/c my involvement with it was limited. It runs half a dozen or so ColdFusion deploys concurrently. I am pretty sure it is load balanced across 2 servers.

Environment 2: IHS, Websphere (6.1), CF8, all sitting behind an F5 running on AIX.
This environment is a set of decked out P5 series IBM servers, 16 processors 100gig of ram. The processors are split up into 60 logical partitions with 40ish partitions dedicated to running 1-4 deploys of ColdFusion.
Our CMS on this cluster during peak AM hours supports about 10-15k sessions with peak around 60 simultaneous requests. Our LMS (my old system) once moved onto this cluster will serve about 5000 courses/hour during peak hours, push about 200 gigs of content/hour and process an average of 60 requests/second.

Some systems or libraries of interest we use/interact with: ACEGI, webMethods (well its in the works), IBM MQ series, Connect Direct, BMC's Enterprise Security Station (ESS), Lectora, Apollo, just about any database you can chuck at a system (for the search engines that includes Derby, Oracle, DB2, DB2 mainframe, MS SQL, MySQL, probably sadly Access).

Thermo

Thermo was announced and subsequently shown off at MAX this year but if you didn't attend you didn't get much more than a few blurbs about it on blogs. Adobe has now posted a great 45 minutes(ish) presentation on Thermo. Check it out here. Additional imformation is available on Adobe labs.

Open Source Projects

Open source is great for the community and for the developers behind the projects. It gives the developer(s) publicity and it also gives the developer(s) an opportunity to garner feedback from the community. I appreciate all the work that goes into open source and in an effort to improve a large portion of open source projects, notably frameworks that are out there, I want to bring up context roots. For all practical purposes context roots generally should not make a difference but I've now run into multiple projects that require modifications to work in an environment that runs on a context root other than /. When possible I make fixes and contact authors of the issue. Its not terribly difficult to fix generally but I have had experience that authors were not even aware of context roots. Since this has occurred multiple times I just want to try to make people aware of context roots and and explain them (I may over simplify this but I'd rather over simplify than over complicate).

To keep it simple I'll limit this explanation to deploying ColdFusion as a WAR file. When you deploy a JEE application to an application server each application lives in its own directory. The context root is (in many app servers) the name of the containing directory. So if I deploy my ColdFusion application as cfusion.war (this contains my CFML and the CFML engine) the context root is cfusion. Now if I want to visit the administrator I would visit, http://sam.pl/cfusion/CFIDE/administrator/index.cfm. Note the /cfusion/, this is the context root. Now on the flip side if I am in a ColdFusion page and want to use cfinclude to include that same CFM I would do <cfinclude template="/CFIDE/administrator/index.cfm">, note the lack of the context root. Generally context roots do not rear their ugly head, the most common place I see issues arise is when pages attempt to include static assets in HTML. You see things like an application is deployed to /wwwroot/myproject/ and static assets are referenced like /myproject/css/default.css. The fix is simple enough, #getPageContext().getRequest().getContextPath()#/myporject/css/default.css. There are other issues I've seen when projects try to calculate the paths, generally resulting in {path including WAR directory}\{context-root (put here by framework generally}\{path to project}. Most of these issues can be overcome by using expandPath() and other built-in functions. Hopefully this helps a couple of open source contributors that may not have been hip to context roots.

Training Developers pt. 1

For the last month I've been working on creating training content for ColdFusion as well as training associates throughout the enterprise, a total of 25 so far and probably another 15 by end of this year. I also got the chance to visit Teratech and receive an official training in Fusebox which was nice. Though in all honesty the lack of labs really made me question how valuable it would be for someone with no practical experience with the framework. Never the less I found the the fusebox training enlightening and it was very nice to see how others used/viewed the framework.

My main focus was Introductory ColdFusion training, you know the things you would find in the bootcamp tack at cfUnited. The audience was a pretty diverse range of people including mainframe programmers, interns, business analysts that wanted to gain more technical background, and Jr. level Java developers. With such a diverse audience I struggled with knowing exactly what content to cover and how much detail folks would need. I've learned quite a few things along the way about training and even a few things about ColdFusion. For starters when you think you have enough examples create about twice that even if one example is a copy and paste with a slight difference. Prepare as many of the examples ahead of time to reduce boring typing, remember to go through them SLOWLY. Do the labs you've created, twice, then multiple the time it took by about 5 or 6 that's how long it will take the class. If you know you will have a diverse set of aptitude levels having "extra credit" or slightly more advanced application of concepts ready for those done with labs early will give the advanced something to do, other than talk and create distractions (and potential frustrate others). Alternatively you can encourage them to help others.

I've always taken my skillset for granted. I've progressively grown with the internet, learning HTML then Javascript, then perl and ASP, then ColdFusion and Java and so on. Mainframe programmers know little at best when it comes to making web applications. Without any prior exposer, learning web application development is a daunting task. You have to learn a new IDE, a serverside language, a client side language, wait a client side language you mean the client isn't on the server? Hopefully you are getting the point, be prepared to teach about HTML and web basics even if the class is really intended to teach ColdFusion. While I'm on the topic of IDEs a good explanation and lab on just using the IDE is a great use of time. Concepts such as setting up your application server in Eclipse, starting a new project, deploying that project, what are views and perspectives, and how a workspace works are all very important foundation concepts for a budding developer. I'll get into the details about the topics and the order of topics in a future post, this one is getting a bit long. I look forward to getting feedback from others about training and their approach!

Its been a while! For the past year I have been knee deep in my company's Learning Management System, which has been running on ColdFusion 5 so my chances to do anything remotely interesting were limited to my evenings, and when I finally got the LMS partially onto CF7 (long story). I am now on the path to transitioning into a new role in my company as a Software Architect (mostly focused on ColdFusion). This should give me more opportunities to play/experiment with new concepts. Here's a list of things I plan to be playing with in the not too distant future:

• Integration with Maven
• I found Maxim's blog entries about Maven here. They've been helpful and I'm curious if anyone else has used Maven with any success?
• Static Analysis
• I've found CodeCop From Steve Bryant and I am having mild success with that so far. I'd love to port it over to an AIR application and use JS as the main brain to I can hack the reliance on ColdFusion.
  
• Code Coverage
• Who wants to help provide this to a growing maturing community? I know I would love to work on it in all that spare time I have ;)

That's the list I have of things I plan on playing with the rest of this year. In addition to that I started then stopped an initiative with a couple of friends to launch a new website (cfInnovate). We're restructuring and planning a little more then trying again, so keep and eye out for that. Finally I've been playing with integrating Spring with ColdFusion, not to wire together my ColdFusion apps with it but using it to leverage some Java components in our CF applications. Most notably we are leveraging ACEGI as the middle man between our applications and our single sing-on solution.