I can't understand the situation we're faced with when it comes to hiring developers at CFI.
Earlier this year, we finally got the approval to do something we knew we needed to do for a while: massively staff up to meet our business's needs for their internal software applications. For the first time since I have been with CFI, we had 26 openings across every software team for development positions.
In two months, we've filled four of them.
Unfortunately, the Java developer market is "hot" right now. What does this mean? I roughly translate it (from several years of hiring experience) to a bunch of worthless developers expecting stupidly high money for their lackluster skills. We've received resume after resume of people with 10+ years of industry experience, who (after a thorough screening) clearly don't give a shit about their work in terms of passion, and can't string a line of code together that one of our junior developers six months on the job wouldn't laugh at.
Don't mistake my blunt tone for harshness or shades of jade. I only wish I were exaggerating the situation.
In the past, we've been lucky to find a core group of people who actually care about their profession and have some passion and ownership for what they do; developers who gently push the envelope by sharing their knowledge with each other, bringing the fruits of extracurricular pet projects and self-study to the table every day. These are the guys that I get up every day to work with, and without whom I'd have been long gone from CFI around Q4 of last year. It's these peers that allow me continue to learn, have fun, and take interest in my work.
What frustrates me is how few and far between these sort of developers are. From my experience interviewing candidates spawned from all sorts of local shops, corporate IT seems to churn out a relentless stream of garbage developers.
Frankly, it pisses me off.
Does nobody really care about quality product or clean design aesthetics? How the hell do you guys look at yourselves in the mirror when you get home from work? Is it really more important to fill a seat with a guy whose only qualification is that he can spell "Java" and fog a mirror if you hold it up to his mouth, but he can't even tell you why he likes being a developer or what the core principles of his chosen technology are?
I'm over it. The sheer number of clock-punching numbskulls out their diluting the development community simply infuriates me. You guys are a discredit to the people who make this profession worth being a part of, and I'd be glad to see you doing something else. As a suggestion, I'm sure there's currently high demand for those proficient in the custodial arts; after all, somebody has to clean up the mess that you created in your tenure filling whatever position you recently vacated.
God bless our recruiters; at least, the ones who have delivered for us in the recent weeks. We demand what appears to be a rare calibre of developer, with nothing to offer except a techie-friendly work environment and fair industry salaries in a market that is currently ripe with extortion by hapless buffoons.
I've got to admit that I've completely lost faith in the ability of our local market to support our needs, to the point where I'm almost convinced that our only hope is the college grads and the internship program we drafted last year. Sica can claim "told ya so" rights on this one; he called this the middle of last year, and while I loved the idea, I felt that we'd be able to find what we wanted in the local market if we were patient and persistent. We've held true to both of these virtues, and have been left bleeding with minimal relief to our staffing woes as a result.
Shame on me.
Sorry to be so depressing. I'm going to log in to our VPN server and look longlingly at our Flex apps in development, reminding myself that the situation will eventually get better, and that the goals we've been fighting for over the last few years still hold a chance of having their day in the sun.
I just installed this update, and after two reboots and a rather long wait to get to the login window, none of my hardware controls worked (brightness adjustment, etc.). I tried to shut down, and my Mac hung after closing all the UI elements and Finder. However, a hard reset and a reboot brought it back to normal.
Security updates for OS X can be a little weird; I guess this one is just weirder than usual.
Finally, Microsoft attempts to do something new and original with their billions and brainpower. The name is a bit lame, but I like the product. Microsoft clearly ripped off a few ideas from the iPhone (like the music album flip), but then both Apple and Microsoft ripped off the MultiTouch user interface in this YouTube video for their respective products. It's like Xerox all over again: as Bill Gates would say, Microsoft and Apple were like these kids that had a rich neighbor that left his door open all the time... :)
Also, the entire Surface web site is in Adobe Flash. So, how long before Microsoft starts building their rich content in their own technology?
I'm also wondering when Apple will release iLick: the world's first tongue-sensitive user interface. After all, OS X's Aqua UI was supposed to be designed so that you would want to lick it... what else could Apple have had in mind for the end game?
I lost a little faith today. I usually stay out of the ego-driven world of blogging, and based upon the reaction to my friend's blog I'll probably achieve pariah status in the CF community for even voicing my opinion on this subject. Fortunately, my blog has a readership of about six people, and those who would really get upset about what I have to say in this post probably wouldn't take kindly to me anyway.
My friend and co-worker Brian LeGros has been blogging for about two months now on various things, and was the subject of some interesting events recently.
It's always a shame when people take the opinions of others to heart, especially when they are stated as opinions. Opinions will obviously differ, especially in a field as academic and subjective as technology. It seems that Brian Rinaldi took some serious offense to some of the things that Brian LeGros has been posting, resulting in a regrettable public outburst during which Brian LeGros was referred to as an "@$$".
Anybody who knows LeGros knows that he is a pretty humble individual with a self-deprecating sense of humor. This is obvious when you read the title of his blog, which is "What Do I Know", and are made aware that his nickname amongst his colleagues at work is "Ham Ham Fury Legs." Unfortunately, tone doesn't translate well electronically, and things that I can read and see LeGros smirking at in sarcasm would be clearly lost as arrogance on those who are not familiar with his mannerisms.
Additionally, anybody who has worked with LeGros is well aware of his deep understanding of computer science. I'd say he's clearly one of the brightest people I've had the pleasure to work with (which either makes him very smart, or means I need to enlarge my circle of professional connections). Even so, LeGros and I don't always agree on technology matters, and we can comfortably put our differences down to personal taste (or "preference" as LeGros would call it - we don't even agree on nomenclature :) ).
So I can see an outsider poring over LeGros's blog, and taking the sarcasm and dry wit out of context. I can then see that same outsider reading what I can only imagine is the offending blog post and being sent over the edge.
"Overall a pretty good talk, very solid. Everyone seemed to get the topic and have relatively relevant questions. It was kinda crazy, but exciting, to see some level of understanding at a CF conference finally."
I'll state my disclaimer, followed by my opinion, and then I'll don my flame-retardant underwear since I'm sure somebody will violently disagree with me. And thank God, because otherwise we'd be living in a police state.
My disclaimer is this: I have a great deal of respect for the CF community, and this is why I have involved myself in it publicly for the last three years, speaking at several conferences and user groups and supporting community initiatives. There are a bunch of really smart people I have had the pleasure of meeting and learning from, including (in no particular order) Joe Rinehart, Sean Corfield, Simeon Bateman, John Paul Ashenfelter, and many others who I apologize for not mentioning.
That being said, there's clearly a large percentage of the CF community that has struggled with OO concepts ever since CFCs were introduced, and it's been interesting to witness the emergence of OO technology as a core concept in CF development. It's literally happened over the last three years; I wouldn't be arrogant enough to say I was part of making it happen, but I witnessed it and hopefully contributed to it through some of my talks.
At my second CF conference in 2004 (Fusebox, DC), the entire focus was on "what's MVC?" and "how do I use CFCs with Fusebox?", a topic which practically popped up as soon as Hal made his keynote speech. I was presenting a case study at this conference on using a CFC model for a Fusebox app that we had built at CFI, and clearly by the audience reaction there were not a lot of people using CF in this fashion at the time (bearing in mind that the app I case studied was almost a year old by the time I was presenting it at my talk). mach-ii was the only OO CFC framework, and many of the developers present hadn't even looked at OO development seriously prior to the conference. There were excellent presentations by Hal and others on OO design and development that were packed wall-to-wall with CF developers looking to get on the OO bandwagon.
Next year at the 2005 Frameworks conference, I was talking about using Java and Spring with ColdFusion. I had a nice chat with a guy named Chris Scott who said he was working on an AOP implementation for an IoC project based on Spring called ColdSpring. At the time, ColdSpring was still pretty small in terms of adoption, but it was clear that a revolution was taking place in the way that CF developers built their apps.
I just got back from cf.objective() 2007, and still, Hal's sessions on OO design and Chris Scott's sessions on ColdSpring are packed wall-to-wall, and for many of the developers there it's the first time they are really pulling back the curtain on OO development and getting ready to put it in to practice.
So, what am I getting at? I'm getting at the fact that when LeGros says "It was kinda crazy, but exciting, to see some level of understanding at a CF conference finally", he's not being a dick. He's not being sarcastic, and he's not trying to talk down to anybody. What he's saying is that it's great to see OO concepts like those applied in ColdSpring and AOP becoming de-facto for CF developers, and for the adoption of OO and design patterns to be concepts that CF developers embrace and understand in the mainstream, as opposed to being limited to a handful developers pushing the limits.
Anybody who attended the 2004/2005 conferences knows exactly what I'm talking about; the questions on OO development during those conferences were rudimantary and at the beginner's level. This isn't an insult to CF developers at large; it makes total sense for the state of the community and the technology at that time. If Sun hadn't introduced OO language elements to Java until its sixth release (as Macromedia did with CF), I'm sure that the Java community would have gone through an identical learning curve.
Less than two years ago, I had a great conversation at a mainstream CF conference with a prominent CF blogger and community member (who shall remain nameless) about the state of OO development in the CF community. This individual reminded me that I was one of probably 2% of the CF development community who operated at a high level of OO understanding. I thought this was harsh at the time; my speaker buddies at the conference were all on the same page, and I didn't see us being that advanced in terms of our capability. But the more I thought about this person's comments, the more it made sense; it's just the evolution that the CF community has gone through. I started with Java and ended up with CF, so of course I would have a different perspective on development than somebody who went the other way around.
And the CF community is not alone in this situation. About 90% of the Java developers we interview at CFI fail our technical screening because they don't understand OO development. That's a sad state of affairs for a language that is OO to the core; at least the CF community started off procedural and went OO years after it became a mainstream technology.
So, I guess it's a bit sad to see LeGros's comments taken out of context, and for there to be a clear chip in the shoulder of some prominent CF community figures. All I can say is, take it for what it is, and don't feel the need to be defensive when it comes to technology. Knowing something about a technology doesn't make anybody better or worse; I can't write a single line of assembly code, but that doesn't make me an idiot any more than a CF developer who hasn't needed to touch OO yet. If LeGros feels that he needs to express excitement at something he observes taking place in the CF community, feel free to correct him if you think he's wrong. But if you ask me, calling him names and feeling the need to defend an entire community of developers over a statement seems a little over the top, especially when it's abundantly clear from previous industry conferences that mainstream OO development in CF is still a pretty new thing.
Overall, I'd like to see that change as a good thing rather than a bad one.
UPDATE: In the comment thread for this post, Brian Rinaldi corrected some of my statements. Rinaldi's comment was directed toward Brian LeGros's apparent tone in his blog posts, and not toward him personally.
After writing my prior diatribe on Flex frameworks, I was reminded of Joe Berkovitz's MVCS, or Model-View-Controller-Service architecture.
Joe wrote an article on this approach to Flex development last year (funnily enough, on my birthday) which I personally feel is one of the "better" approaches I have seen so far in terms of how lightweight it is. Since Joe's code is entirely framework-free, I did feel that perhaps there was some room for taking his concepts and making some framework utility components from them. I also have mixed feelings about multiple controllers as opposed to one monolithic front controller, which both Joe's sample approach and Cairngorm seem to favor; again, with great respect to the people who wrote code for both approaches, this is probably just a result of my naivety with Flex development.
In any event, more food for thought, and some additional interesting ideas for me to play with.
As much as I love Flex, I haven't been too impressed by the frameworks that have emerged yet.
Now, let me be clear by saying that most of the work I do these days is either in Java on the back end or at the architectural/conceptual level, and my experience with building a full blown app in Flex is still pretty limited. However, I have tinkered enough to know what I like and what I don't, and some of our top talent at CFI comes by my office regularly to let me know when they are experiencing challenges. So, some of what I write in the post will be my own experience, and some of it will be anecdotal based upon the experiences of others.
With that said, let's get back to the main event.
When we started doing Flex development at CFI, we jumped in to Cairngorm because it was something of a de-facto standard; and let's be honest, nothing much else existed at the time. We were on Flex 1.5, I had a copy of the "Developing Rich Clients with Macromedia Flex" book, and liking most of what I read in there I felt that the authors knew what they were doing, and since they had also authored Cairngorm it seemed like a good place to start.
Is Cairngorm bad? I wouldn't say so. It's a clean framework implementation and it addresses some of the idiosyncracies associated with asynchronous application development. However, it is an awful lot of work to get an application to do anything in Cairngorm; there are many layers, some of which I found to be rather tedious when I was working with it, and some of our Flex developers felt the same way. One even went so far as to customize some Cairngorm-internal classes to get the framework to be a little easier to manage.
We've also had some discussions internally about how Cairngorm's implementation approaches the Front Controller pattern, and this is not necessarily ideal for rich application development. Flex can maintain state, and it would make sense for a Flex framework to leverage the statefulness of the front end in any framework that might be developed for it. I'd also like to see frameworks emerge with minimum boilerplate, and there seems to be an abundance of boilerplate in Cairngorm based upon both my limited experience and the feedback from our developers building Cairngorm apps in-house.
Let's switch gears for a second, and go to the other extreme.
A few months back, I went to the OJUG meeting where James Ward was demoing some Flex apps. I had been out of the Flex development arena at work for a while, and wanted to see what James had to say as well as check out the local JUG. James put on a great presentation as always, and it was the usual Flex drill of features and demoing the performance and experience capabilities that I was already familiar with.
We had been having the "is Cairngorm what we want" discussions at CFI right before I went to the OJUG meeting, and something happened in James's preso that made me think about the far end of the spectrum for simple Flex app development. When James demo'd his Flickr widget, I was struck by the simplicity of it: drop the Flickr widget tag on the page, bind another UI component to a public array property of the Flickr widget that would fill with images, and make a call to the widget to perform a service call that would ultimately fill the array and populate the UI component through data binding. No controllers, no listeners, and yet a simple pair of encapsulated, purpose-built objects that could be reused in any application.
Seeing this in action, it reminded me of what I loved about Flex's ability to create simple observer relationships using data binding, something that had been so painful in my Java Swing days (damn you, ActionListener! :) ). It also reminded me that the technology in Flex should be treated differently to traditional web technologies, and that perhaps a reasonable middle ground could be found between traditional MVC web frameworks and simple bindings in Flex. Ideally, I'd like to see a bare minimum of useless boilerplate and maximum productivity, and I imagine every Flex developer would agree.
So then, a week or two back, Cliff Hall released a demo Apollo app (CodePeek) for his fledgling PureMVC framework. I looked through the architectural documentation on the web site and the sample code in the demo app, and felt like things were moving in the right direction. I like Cliff's approach to the framework, and while there is still some boilerplate, it's minimal.
If anything, the framework is almost too minimalistic in its present form. For example, as the application kicks itself off, it's necessary to announce an event in the main MXML file to start up the app, which fires off a MacroCommand to fire two other commands initializing the Model and the View. In order for this to take place, commands have to be created for initializing the Model and View, and the APP_STARTUP command has to be explicitly denoted, created, and listened for. Model and View initialization seems like a fairly standard operation that almost every, if not all, applications utilizing PureMVC would need to take place in order to be functional, and as a result, this is the sort of thing that could be simplified by creation of a convention or simple configuration that saves the developer from doing these steps. Of course, Clff has done a nice enough job with the framework that any developer could make these simple extensions themselves, but having been spoiled by Spring for Java for so long I guess I'm just used to seeing built-ins like this in a mature implementation.
There were some other things in the PureMVC demo app that I thought I would do differently. For example, the AppControlBar and AppControlBarMediator objects are pretty tightly bound, but it seemed like Cliff went out of his way to try to keep them loosely coupled.
In AppControlBarMediator's constructor, there are three lines of code registering event listeners so that the mediator can pick up events from the AppControlBar. The AppControlBar then has to define specific functions to announce these events (another six lines of code). Once the AppControlBarMediator catches the events, it does nothing but invoke the appropriate proxy, but only after referencing specific properties of the AppControlBar using dot property notation.
Having discussed this with my buddy Russ at work (easily our most experienced Flex developer, and a very sharp fellow besides that), we agreed that using an event registration/announcement model would allow the AppControlBar component to be reused in other applications. I can see the point for completely reusable components, but this control bar is so specific to the application in question that all the event registration code seemed like overkill, especially if the mediator is just going to break the encapsulation of the component in order to get the properties to pass to the appropriate proxy.
In this simple use case, it seems like it would be simpler and just as clean to make the AppControlBar an MXML component that announces events containing the appropriate data, which the AppControlBar would prepopulate, thus decoupling the View's internal properties from the Mediator. Then, we could treat the Proxy as a component also, exposing a publicly available service method. Next, we would embed the AppControlBar and a service-located reference to the Proxy in an MXML file that links the event ennouncement from the AppControlBar to a service method invocation on the proxy. Finally, the Proxy could announce an event once the service call returns. We'd listen for this event in the MXML file containing the AppControlBar and the reference to the Proxy, which could handle the event by manipulating the AppControlBar through a publicly exposed method. Taking this approach, the containing MXML file becomes the Mediator, as a kind of blend between an XML config file and a code file.
With an appropriate amount of abstraction in the nature of/access to the proxy and the AppControlBar's interactions with it, I think this sort of approach would eliminate the boilerplate code and could still extoll the virtues of a clean MVC framework. With a simple mechanism for interested parties to listen for events from the Proxy (similar to the excellent job Cliff has done in PureMVC) and a twist in the Mediator concept that would use the MXML file containing the components as something of a blend between a purpose-built controller and an IoC configuration file, I think that a great balance could be struck.
Either that, or my limited exposure to full scale Flex development is blinding me as opposed to letting me think openly, and I'll be back here eating my words in a few weeks. In any event, the combination of our semi-pain with Cairngorm, the simplicity of James Ward's Flickr widget demo inspiring me, and Cliff's excellent work on PureMVC, I'm going to take a stab at building a proof of concept app that hits this middle ground. As I identify opportunities for reuse, I'll try to break those out in to reusable/configurable components, and maybe a framework of sorts will emerge.
And if (worst case) this all falls apart, I'll come back to the table with a more in-depth understanding of the design behind the Flex frameworks that exist today, which can't be a bad thing.
I just spent about ten mintues Googling for how to do the cool right click "View Source" option in Flex applications, which generates your source and allows you to publish and link to it when putting a Flex app on the web.
I had a feeling that this option was in Flex Builder 2, but since I haven't had a chance to convert one of our licenses over to the Mac edition yet, I couldn't verify it. It turns out that all you need to do is execute the "Publish Application Source" option from the Project menu, which (from the sound of it) acts like a standard Eclipse project export, letting you choose what you want published to the world.
Hopefully my post has slightly more useful keywords than you might have found elsewhere and this will help you save some time if you (like me) were wondering how to take advantage of this very cool option. I found the final answer to this question on this blog post if you want to take a look.
