What he’s mostly talking about are those open reqs that you keep seeing, month on month, that never seem to get filled, but he is also asking why well-qualified people have a hard time getting hired. He doesn’t really answer his own question but he gives some good advice about applying for jobs…

• If the job requirements are specific, ensure your resume makes it clear you really have those skills.
• Keep your resume current and if the application says “attach an up-to-date resume” then make sure it is current and attach it to your response! I’m guilty: I tend to send folks a link to my online resume which is generic, not tailored to a specific job.
• If the application asks for your salary expectations, be reasonable but never undervalue yourself.
• The cover letter is the first impression you make - and may be your only impression! Judith provides good advice in the middle of Michael’s post.
• If the application asks for a code sample, send them something appropriate to the job (although I’ve not actually seen an application that requests this - and most code is proprietary and belongs to an employer/client unless you write a lot of open source stuff!).

I’ve definitely seen some of these perpetually open job requirements. I’ve talked to the companies posting them. Their two most common responses?

1. “We get lots of applicants but they aren’t the right people.”
2. “Almost no one has applied for that job.”

The second one I can understand when the application reads like an encyclopedia of “required” skills (which many of them are). I’ve looked at job openings and thought yes, yes, yes, er… gosh, no, hmm… yes, yes, nope… really? They require that skill? It’s part of the problem with “laundry list” job requirements - and yet it’s needed to help filter the flood of applications that many jobs might otherwise get. It’s why Michael recommends you tweak your resume to “match” the job requirements.

What about the first response? I know lots of “right people” but they are mostly very happy in their current workplace and aren’t interested in applying for another job. In fact, when Broadchoice wanted to hire people, we drew up a shortlist of people we’d like to hire and then simply asked them to join us! It’s a tactic I highly recommend. You might get turned down but you might not. The important thing here is not to think “I can’t have X - they’d never come to work for us!” because that will stop you going after the people you really want. Go on, just ask them!

So let’s go back to part of Michael’s question where he asks “why can’t I get a ColdFusion job?” and let me assume he’s asking specifically for himself and people like him, by which I mean “well-known people in the community”. Why would a company not hire a “Community Expert” (to use Adobe’s term for a select band of several hundred of the top-notch developers / designers in each product user base)? Part of the problem is our level of involvement in the community - we attend and speak at a lot of conferences, we seem to spend a huge amount of time blogging, answering posts on mailing lists, writing open source software and twittering. Given all that, how can we possibly have time for a full-time job? The conferences alone are a huge issue for many companies. I’ve had interviews where one of the first questions out of my prospective employer’s mouth is “do you expect to continue attending several conferences a year if we hire you?”. I’ve also actually been asked “do you really have time for a full-time job with all the community work you do?”.

There’s also the aspect of “fit” with the team. If the company is looking for even a senior level developer to work in a team, they probably want someone who will work happily with their peers and code like a demon. Companies are wary of “Community Experts” because they fear those folks will want to change things, to “educate” the other developers, to introduce “new” technology and processes, to agitate for training and conference attendance. Heck, such outspoken people might even challenge management itself in trying to “improve” the way a company’s software gets built! That can definitely work against the more outspoken members of our community.

So, if you have thoughts on this subject, drop your thoughts on Michael’s blog!

Comments

The POSS model allows us to offer a variety of support and consulting services around the core free product, including the ability to custom develop new features or extensions and accelerate parts of the roadmap to suit those customers who need something specific sooner, rather than later. For example, if you have decided to port a large application to Railo but your code depends on a feature we don’t yet support, you have the option to engage our professional services team to add that feature, ahead of the roadmap, so that you can be up and running faster. We like to refer to this as a customer “sponsoring” a feature or an extension.

If you decided to sponsor an extension, what’s in it for you? First off, you get the features you want, when you want them. Second, you can decide whether, when and how the extension would be made available for everyone else. You could allow us to make it available as soon as it is ready for you - or later based on our original roadmap. You could make it free or set a price for it - either way it would be available to all Railo users via the Extensions feature in the Server or Web Administrator. If it is a paid extension, you would share the revenue with Railo, helping to recoup the cost of the sponsorship. And finally, the extension information would feature a link and descriptive text about your business, right there in the Administrator.

If you think this might help your business get better value out of Railo, feel free to contact the Railo team and discuss your needs!

Comments

I’ve left comments on a few of the blog posts but several people have asked me to go into a bit more depth about my thoughts on this issue (since I’m one of the people sometimes accused of “pushing” OO and insisting it’s the “right” way to do things).

First off, I’ll repeat what I’ve said many times: there is no One True Way. What works for me might not work for you and even I will solve the same problem different ways at different times in different circumstances.

Having said that, for me there is almost no problem today where a purely procedural solution is the right one for me. Years ago, that wasn’t the case. Prior to 1992, I hadn’t worked with any OO languages but I hadn’t done just procedural programming either: I had started learning functional programming techniques around 1982. As part of my university degree, I did a one year work experience assignment at an insurance company, mostly writing IBM 8100 assembler (and some COBOL). I helped design and implement a number of powerful library routines for a hierarchical database system the team was developing, recursive routines that I now recognize as implementing the Visitor design pattern (which I hadn’t heard of at the time). What I’d learned from high-level functional programming changed how I wrote the most procedural language available - assembler.

In 1992, I started to pick up C++. I picked up Smalltalk in the mid-90’s. By 1997, I’d discovered Java. Over the years, I got a little better at writing OO code and started learning about design patterns and OO design. It was a process, a journey, still ongoing. Along the way there were a few lightbulb moments and there was plenty of frustration.

Surprised? Knowing what you know of me from my blog and my posts on mailing lists and my talks at conferences, would you expect that I have been through a lot of frustration trying to become a better software developer, a better software architect?

I’d be surprised at anyone who had not had such frustrations!

Why do we go through this? Why do we push through to the other side to learn - and master - this stuff? IT is an interesting industry because not only does it change - like all other industries - but the pace of change is extremely fast. What we learned last year will be outdated next year, or the year after. If you look at job descriptions for ColdFusion developers, they’ve changed over the last few years. Most of them want experience with frameworks and CFCs now. As Matt Woodward said in comments on those blog posts, the debate is over - OO won. Years ago.

No matter what you think about OO, the industry has moved on and OO is the norm. COBOL, the mainstay of procedural programming, adopted OO features in the early 90’s and OO COBOL compilers were available by 1997 with an OO ANSI standard following in 2002. Ada was the first ANSI standardized OO language in 1995. C++ became an ANSI standard in 1998 but work first began on that language in 1979. Simula is considered the first object-oriented language and it appeared in 1967. Smalltalk appeared in the 70’s, became a de facto standard in 1980 and an ANSI standard in 1998. All modern languages - all new languages - embrace objects from the start. Many modern languages go beyond OO and incorporate other advanced features - some of those languages would probably seem incomprehensible to traditional, procedural programmers. We shouldn’t expect to understand everything but we should expect to continually learn new things so that we remain employable, relevant, interesting.

One of the subjects that came up in the various blog conversations was Fusebox. Someone lamented that “even” Fusebox had become OO. Fusebox is a very important illustration for the CF community. Fusebox 4 was built as four large, procedural files and supported both procedural and OO styles of application (yes, a framework written in a procedural style supported OO - even Fusebox 3 supported OO application development!). Fusebox had become hard to maintain and enhance. In order to move forward, I rewrote the core files to be more maintainable - I rebuilt Fusebox as a set of collaborating objects but it was 100% backward compatible. The same procedural apps that ran on Fusebox 4 still ran on Fusebox 5. The same OO apps that ran on Fusebox 4 also still ran on Fusebox 5. Even tho’ the core files changed from pure procedural (and unmaintainable) code to fully object-oriented (and, hopefully, more maintainable) code, the range of supported application styles did not change.

So, how do I really feel about Marc’s post? I sympathize. I know his frustration is real. His background is design and not computer science - of course he finds OO to be extremely hard. I have met only a handful of people who have a natural ability for OO thinking. Sorry, but for everyone else, this is hard shit! There are no short cuts. Some years ago, I gave a talk at CFUnited (I don’t even remember which talk now) and a guy came up to me afterward and asked me about learning OO. I told him to go easy on himself and expect this to be a difficult path that would take him a long time to learn. He exploded in anger, accusing me of calling him too stupid to learn OO. For me, that perfectly sums up the unrealistic expectation many people have about learning OO. It is hard. It does take a good long while. Many people give up. Some people push through and eventually reap the benefits of the pain of learning this stuff - and of making lots of mistakes along the way.

Don’t beat yourself up if OO doesn’t make sense. Don’t kill yourself trying to master it. I don’t “get” numbers but many people do (including my wife). I completely “get” abstract math (my wife does not). She “gets” OO but she can’t program (programming languages are too fussy for her tastes). Don’t kill your business attempting to achieve some ideal that doesn’t work for you. Spend some personal time on it, sure, but don’t lose too much sleep over it.

Here are the original blog posts:

• Marc Funaro’s original post
• Steve Bryant’s response
• Brian Rinaldi’s different slant
• Scott Stroz’ challenge
• Brian Kotek - it’s not OO, it’s people
• Peter Farrell on learning OO

Comments

Right now, we have a pretty solid definition of how CFSCRIPT should work so that you can write entire components. Mostly it follows what you may have seen Adobe show off at conferences but Adobe is still making changes in response to feedback from the committee (and its own banks of prerelease testers, I’m sure) and some of Adobe’s suggestions were considered vendor-specific by the committee.

But we’re stuck on a couple of tags that we’re really struggling to define in CFSCRIPT. We’d like you to help us make some decisions here!

First off, here’s a simple component written using core CFML2009:

Extended core CFML2009 would allow the <cfscript> tags to be omitted (with rules about what is allowable outside component). Extended core also adds a few other useful constructs that are optional for vendors (but if they implement them, they should follow the committee’s spec).

You’ll see import and new in here, as well as var appearing somewhere other than the top of the function. You’ll also see that we’ve voted to include throw in core CFML with a function-call style syntax that allows attributes to specified like named arguments. We’ve generally followed that pattern for tags-as-script, so you can say, for example:

But we’ve run into some problems trying to solve this for cfmail and cfquery. The problem is that the body of these tags is treated specially. It isn’t just code, it’s text with embedded code. You can see the problem clearly in this example:

In the tag-based version, it’s easy to identify code: it all begins with <cf or is wrapped in # but in CFSCRIPT, code looks like regular text.

Both cfmail and cfquery have nested tags and we can clearly put those in the tag-as-script body:

Since CFML allows multi-line strings, we’re considering adding a body attribute to cfmail and a sql attribute to cfquery so you could do this:

We’ve reviewed a lot of syntax options and dismissed most as either unworkable for some technical reason or just downright ugly.

What would you like to see for mail and query in CFSCRIPT?

And, yes, we’re still discussing cfmail vs mail. For some tags, the name without the prefix is likely to clash with existing user variables and functions - and may not be as easy to read. For example, which of these two are more obvious and less likely to cause compatibility problems with your code:

So, input please! On both the syntax for mail and query specifically but also tags-as-script in general.

Comments

Given the availability of such software, you might ask why anyone would pay for software? There are many reasons, foremost of which is usually to leverage the support of a corporation. The same logic applies to why people pay for maintenance and support, even on commercial products where they’ve already paid for the software license in the first place.

In the FOSS world, commercial maintenance and support is often still available through an organization that is associated with the free software. MySQL, for example, offers free software with paid support and consulting (typically around $2,500 / day). JBoss does the same, offering a variety of both support and consulting packages. This model is often called Professional Open Source and offers a way for companies to avoid upfront costs but still get all of the benefits of commercial software, by purchasing support and assistance as needed. We’ve already seen several well-known open source CFML projects adopt this model, a trend I would expect to continue as CFML projects become more sophisticated and more widely used.

As a JBoss project, Railo follows this model as well, which should be no surprise. The Railo team has recently reviewed and updated the information about our offerings in these areas:

• Support - offering four levels: silver, gold, platinum and enterprise.
• Consulting - covering everything from installation, configuration and performance tuning thru all aspects of application development and even assisting you with deployment to “the cloud”.
• Training - covering Railo itself as well as various frameworks and development processes and tools.

As the saying goes “We’ve got you covered!” so if there is anything we can help you with, Railo-specific or otherwise, feel free to contact us to discuss your needs.

Comments

I’ve been using ColdFusion since 2001, back when I worked at Macromedia and my team of Java and C++ developers first encountered CFML in the form of very early builds of what went on to become CFMX (6.0). We were pretty skeptical at first.

A tag-based language? Weird, pseudo-objects? Lots of bugs (sorry, but CFMX was very buggy!). CFMX 6.1 was a huge step forward. Frameworks helped (Fusebox didn’t suit my team but Mach-II was adopted with enthusiasm). I moved from web development to systems integration, helping the ERP team integrating dozens of sales order feeds into Oracle’s business applications - using early builds of what went on to become CFMX7 and writing the first cut of the JMS event gateway that shipped with CFMX7 and an OracleAQ event gateway (which was subscribe-only and therefore never released publicly). After the acquisition by Adobe, I had a new team which continued to work with ColdFusion, pushing some core web services live with an early build of CF8 on JBoss (there was definitely some push back from ‘legacy’ Adobe team members to using CFML on that project and we did encounter memory leak problems which gave them some just cause - but I now think that was due to a cache problem in Transfer ORM… did I mention we were using early builds of Transfer ORM as well?).

After I left Adobe in April 2007, I went freelance and worked on a number of interesting projects for clients who were all using ColdFusion 8 (well, almost all of them were!). I took advantage of my lack of tethers to the ‘mothership’ to become a User Group Manager (staff cannot be UGMs) and a Community Expert. And I started talking with Vince Bonfanti at New Atlanta about the upcoming Open BlueDragon steering committee which I joined officially in April 2008, albeit fairly briefly, and then I was asked by Adobe to head up the CFML Advisory Committee a few weeks later (and I’ll be blogging about the committee a lot in the next few weeks!). The committee initially featured Adobe representatives, community representatives and Gert Franz from Railo. A couple of months ago, we were pleased to welcome Matt Woodward of Open BlueDragon onto the committee.

Along the way, I joined Broadchoice to work with Ray Camden and, later, Brian Kotek and Joe Rinehart. Long-time ColdFusion users and evangelists, we found ourselves designing an application for the Amazon cloud and turned to free open source software to build it. Flex (which is free open source, remember), BlazeDS, Groovy, Spring, Hibernate, JBoss. We launched Broadchoice Workspace in mid-October 2008. We decided to add an iPhone-compatible web application and we all knew the best way to add that was using CFML. However, Adobe’s license for ColdFusion 8 didn’t work with Amazon EC2 and our deployment process was WAR based so ColdFusion’s JEE packaging didn’t really work for us. We decided to try out Railo 3.0 Community Edition. Railo ran Model-Glue 3 and ColdSpring just fine. It ran on top of JBoss just fine. It didn’t add a huge amount to our deployment WAR (about 12MB). It was a pragmatic choice and we were happy with it.

I have to say that Adobe were not thrilled about our decision. Since we were working with Cocomo at the time, there was talk of us being featured in the opening keynote at MAX 2008 (we weren’t, in the end) but we did have our time on Flash Platform Adobe Partner booth at MAX. I was cautioned to keep the focus on the AIR application rather than the Railo-powered iPhone web application.

In the meantime, we’d been evaluating our development and QA server organization. We were using the JMS event gateway for our ColdFusion 8 powered CMS (Broadchoice Community Platform) but we didn’t feel it was right to have to pay $7,500 for each development and QA server. Fortunately, Adobe’s license did permit virtualization on a known number of CPUs so we bought a ‘big’ server and used Xen to set up ten virtual machines: 5 development instances, 4 QA instances and 1 demo instance. Just one CF8 Enterprise license covered the entire system. It wasn’t our ideal but it was the only reasonable way to manage our systems with Adobe’s license. Our production cluster - for our CMS - grew to four servers, all running CF8 Enterprise, fully paid for. Yet we had to skimp on on dev/QA setup.

We really wanted to move our CMS out of the data center and up into the cloud, like our collaborative Workspace system. Discussions with Adobe ensued and we got the permission we needed to deploy CF8 on EC2 - thank you Adam and Kristen! - and so, at the end of 2008, we migrated our CMS to multiple instances of CF8 running on EC2 (and that migration will be the subject of my talks at Scotch on the Rocks and CFUNITED). The net result was that CF8 ran beautifully on EC2 and we saw improved performance (after the slower startup due to the virtual file system).

Today, the Broadchoice applications are very coupled to their choice of CFML engines. We run both Railo and ColdFusion - and unless there are substantial changes to both, those choices are unlikely to change.

Which all brings me back to my point (oh, I bet you are pleased to discover I actually have a point after all this rambling!). Over the years, I’ve become a huge fan of ColdFusion and I’ve staked my professional career on it. However, despite that enthusiasm, I recognize that there are certain situations where Adobe’s licensing and/or the memory/disk footprint of ColdFusion simply don’t work. Sometimes a ‘proprietary’ system won’t fly, only an open source solution. Sometimes cost is an issue. What are the options in those situations? In the past, the only option was to turn to a non-CFML solution.

Given many companies’ preference for homogenization, this often meant a wholesale shift to Java or .NET (the latter is something that New Atlanta seem keen to assist with). It has also meant the ‘bleeding out’ of advanced CFers to Ruby on Rails and Groovy (as hinted at by Peter Bell and Neil Middleton, who has moved to Ruby on Rails).

ColdFusion long held the RAD crown for web development but even Adam Lehman will admit, I think, that RoR and Grails have at least borrowed, if not stolen, that title these days. Adobe are working hard to grab the crown back with Centaur - and from everything I’ve seen it will be an incredibly impressive release! But these days, it isn’t just Adobe fighting to get the RAD title back. OpenBD and Railo have shown that you can have a full-featured CFML engine that can compete with RoR and Groovy on price and licensing.

This week we’ve seen the culmination of the maturing process for CFML so far. We now have multiple, credible open source implementations. We have big names backing those projects. We have a strong, growing community (Adam Lehman says 350k new CF developers have appeared since Adobe took the helm). The original implementation continues to evolve and innovate. The open source implementations are also innovating and evolving too. We have a central, multi-vendor committee that is attempting to standardize the language.

Could the free alternatives hurt Adobe? There’s an argument that they’ll leech away some of the low-end sales but my impression is that high-end sales are growing and Adobe is making more money from the Enterprise edition than from the Standard edition. Having said that, I think there’s no doubt that free open source CFML engines will cannibalize some low-end ColdFusion licenses. However, if those licenses are endangered by free CFML engines, they are also endangered by other free options (or even non-free options). A corporate commitment to CFML is not overturned by price alone but licensing is a factor. So if some low-end licenses will be lost by Adobe, how could this new competition actually benefit Adobe? Consider those CF shops that would move to another technology, a free technology (or a “free” technology - don’t get me started on .NET!) or a perceived “more RAD” technology. What if CFML was available in those categories too? What if the choice between PHP and CFML was not based on price? What if the Java community could consider CFML as a native JVM language supported by a well-respected Java-based organization like JBoss? All of a sudden, CFML is no longer a proprietary, expensive application server. The eco-system has grown. Adobe’s audience has grown to encompass people who might otherwise have embraced PHP or RoR or Groovy or even Java. If Adobe picks up even a few of those licenses - as people in that sector demand more from their new language - they’ll have benefited from the competition.

Comments

Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inherited hierarchies, and establish key relationships among them. Your design should be specific to the problem at hand but also general enough to address future problems and requirements. You also want to avoid redesign, or at least minimize it. Experienced object-oriented designers will tell you that a reusable and flexible design is difficult if not impossible to get “right” the first time. Before a design is finished, they usually try to reuse it several times, modifying it each time.

Yet experienced object-oriented designers do make good designs. Meanwhile new designers are overwhelmed by the options available and tend to fall back on non-object-oriented techniques they’ve used before. It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don’t. What is it?

Read it over and over again to make sure you’re taking it all in. This stuff is hard and you’ll be overwhelmed at the beginning. It takes a lot of time and experience to get “good” and even the experts almost never get it “right” the first time, or even the first few times.

Don’t be discouraged but be realistic: don’t expect OO to be a quick win. It’s a process, a journey. I’d been doing OO for about three years before that book first appeared - imagine how frustrating those first three years were! Even after the book appeared, imagine how long it took people to come to terms with what the authors were saying and how much longer it took most people to take the contents of the book onboard!

Comments

You can read all about the training course on the ColdBox website and the cf.Objective() pre-conference page.

You can now register for the training when you register for cf.Objective(). You can even attend the training without attending the conference (but why would you want to miss such an excellent conference?).

I know some folks were holding off registration until the pre-conference training was announced - now you have no excuse!

Remember that the early bird ends on March 31st. If you register at least one person from your company before then, other people from your company will be able to register at the same price even after that date (and if you send five or more people, you’ll get an additional discount!). After March 31st, the regular price goes up to $629 - which is the same price as last year.

Comments

cf.Objective() 2009 early bird pricing ends on March 16th and the price will go up by $130 after that.

3-day registration is currently $549. 2-day registration is $499.

After March 16th, 3-day registration will be $679 and 2-day registration will be $549.

Expect pre-conference training to be finalized in the next few days and posted to the website this week!

The online scheduler will be available this week too.

Comments

Session Descriptions Posted!

All of the session descriptions have been posted on the cf.Objective() 2009 website.

The sessions page describes the four tracks at this year’s conference with session titles and speakers. Click on each title to jump to the description on the full track listing page.

Don’t forget to check out the schedule - it has had a couple of small tweaks as well.

Adobe sessions will be listed nearer the time (since much will depend on where Centaur and Bolt development is at the time of the conference!).

Comments

Standardization is a long, slow, complex process. It is always a multiple vendor process and it always takes time to assimilate all of the information about each vendor and to figure out where the standard should tread on the paths between all the vendors.

We have been reviewing all the dialects of CFML and figuring out what tags and functions are really core to the language and what are “extensions” in some sense. We’ve already analyzed Adobe’s CFML support and recently we started looking at Railo and OpenBD extensions and, since Gert was already on the committee, it was clear that we needed an official representative of the OpenBD project as well.

I’m very pleased to have Matt on board, knowing that the three major CFML engine projects can work together to help standardize the language and guide the evolution of CFML over the next several years.

I’m under no illusions about the work involved - I was a member of the C++ standardization committee for eight years (and secretary for three years!). We will soon be announcing the committee’s website which will provide a definition of what is considered “core” CFML, “extended core” CFML and also what is considered a vendor-specific extension. Over time, we will provide guidance on how all vendors can extend the core language in idiomatic ways, maintaining consistency of the language. We will also, over time, provide a full specification of the CFML language.

We are starting with a simple list of which tags and functions to expect to be implemented, providing a baseline of portability, and we will evolve that to fully specify the behavior of those tags and functions. We will also specify CFScript (since that has never really been documented properly) as we all believe that is a core part of CFML.

Once we publish the website, we will be looking for feedback from the community on the standardization and evolution of CFML.

I think today will be looked back on as a very significant date in the history of CFML!

Comments