An Architect's View

An interesting blog post from TechRepublic was doing the rounds on Twitter this morning so I thought I'd comment on it in terms of revelance to the CF community. The blog post was 10 skills developers will need in the next five years. Let's go through each of the ten items in turn...

[Read more →]

Ben Nadel had a bit of a "crisis of faith" last week over his ability to learn OOP the "right" way. He's highlighted a problem most people have coming to OO these days: in their search for the One True Way(tm), they are overwhelmed and can feel like failures. It can be a long, hard road. In a comment on his blog, I recommended everyone read the first two paragraphs of the "Gang of Four" Design Patterns book because it really sets this in context. I'm going to reproduce those first two paragraphs here to get you thinking. I highly recommend buying and reading the book.

[Read more →]

Several people have been blogging about the OO Quiz created by Hal Helms. I'd question the wording of a couple of the questions but it's a fun way to while away 15-20 minutes and it will definitely test your understanding of object-oriented terminology and principles.

Sammy Larbi has a great blog post on the value of contributing to open source projects. He cites several famous names - people we know because they contribute to projects we know. This is part of a series of posts from Sammy on "how to save your job" (by improving your skills) and is inspired by Chad Fowler's book (52 ways to save your job). Good reading!

Geoff Bowers has posted a helpful crib sheet on the Daemonite blog that shows how to merge branches under SVN. I do this often enough that I get frustrated with how counter-intuitive it seems but not often enough that it becomes second nature. Geoff's post definitely helped clarify things for me.

An interesting blog post aimed at helping non-programmers recognize the indicators common in good programmers. The comments are long (over 180 as of this writing!) but mostly in agreement although there are some interesting dissenters as well. He talks through six major issues and then summarizes in positive and negative bullet points. It's not a perfect list but I agree with most of it. When I'm hiring, I look for someone who is passionate, programs in their spare time, works on personal side-projects, learns additional technologies "for fun". I want someone who has "strong opinions, weakly held" (which is a toned down version of what is presented on that blog post). Similarly, I hear alarm bells when I am interviewing a developer who views programming as "just a job", only learns new technologies when the company sends them on training courses and only knows one set of technologies. I'm less concerned (than the blog's author) about someone who started programming "late" in life. As folks who've been interviewed by me know, I don't "quiz" people or set them "clever" tests. I get them talking about their work and their projects. I want to hear passion, I want to hear about problems and how they solved them - and how they dealt with managers (or peers) who didn't see eye to eye with them on solutions. Are your criteria different?

If you watched this week's "Chuck", right at the end he has a C++ book on the bench and, much to my wife's amusement, I excitedly recognized it "OMG! That's Barton & Nackman's book!" "Scientific and Engineering Programming in C++" was a landmark book that introduced powerful techniques based on templates. When we (ANSI Standards Committee) were trying to redefine the language rules around name lookup as regards the friend keyword, we were forced to preserve the examples in that book because they had passed into common usage, even though we really wanted to restrict how the friend keyword worked. We did, eventually, come up with suitable rules. Watching "Chuck" tonight (we recorded it from Monday) brought that whole committee experience back to life for me!

Jeffrey Zeldman suggests that "maybe" is not an appropriate choice and should not be offered to users. As someone building a social networking website, I know what he means and, whilst "maybe" was part of our earlier design, when we launch, you will only be able to say "yes" or "no" to an event. Zeldman says:

How can you know what "maybe" means? In the context of a web service, you can't.

He also rails against five-star ratings since those have an implicit "maybe" (three stars) that tells you very little. Thoughts?

Many of us have seen the (infamous) Ruby on Rails "Blog in 15 minutes" video and probably also Joe Rinehart's "Blog in 9 minutes" Model-Glue: Unity video. It makes it all look so easy. Wow! We should all use Ruby on Rails (or Model-Glue: Unity) because it will clearly make us so much more productive! Of course, as those folks who've struggled with Model-Glue: Unity (or Rails or any other framework) know only too well, it's not quite that simple! So why do some people struggle when others find these frameworks so easy and so productive? The answer is blindlingly obvious, unfortunately, but it isn't an answer most people want to hear. Sammy Larbi asks "is Rails easy?" and points to Venkat's blog entry "Can your cat code my Rails App?". The answer to both of these might seem obvious. The answer to the second question is clearly "no". The answer to the first question is, unfortunately, "it depends". As Venkat says:

I asked why she thought developing with Ruby/Rails is so darn simple. She said she had seen a demo of a fully working app being created within minutes without much effort or code.

The videos are, of course, somewhat misleading because they show what someone can do once they already know the framework really well. It's the same reason that experienced OO developers find OO so liberating and productive: they already know OO really well! Venkat compares C++ and Java, saying the latter is more productive with the following caveat: "I doubt anyone would say that Java makes an ignorant programmer more productive. You did have to take the time to learn the details of the language, the platform, and the API." The point behind all this is that there really is no silver bullet. Using a framework doesn't automatically make you more productive from day one. You have to learn how to really use your tools and sometimes that learning process is non-trivial to the point of seeming endless (and being a lot of hard work!). I post this because I got into a somewhat heated discussion at CFUNITED a few years back with someone who thought OO was dumb because they'd tried to use it and it made a mess of their application. I said that it takes time and effort to learn OO in order to be able to apply it properly. They got offended, thinking I was telling them they were too stupid to learn OO. I've repeatedly said: this stuff is hard. I started doing OO in January 1992 and I'm still learning. OO has mostly become second nature to me now but that doesn't preclude me from learning new techniques - often from people with less OO experience - that help make me more productive. So don't think that Rails is going to turn everyone into super-productive programmers overnight - most people coming to Rails already have a fair bit of Java and OO experience so pick up the concepts easily and, once they've learned the Ruby and Rails specifics, they can be more productive than they were in Java. It's the same principle that applies when you learn a new framework in ColdFusion. It may seem strange at first and may look like extra work but once you understand most of the specifics, you can be much more productive. Just be prepared for a learning curve.

Having just spent the last few days tinkering with AIR applications - including some training at the annual Adobe Summit - I'm pretty fired up about AIR! You can build AIR applications easily with Flex using the beta of Flex Builder 3 but you can also build AIR applications with HTML. You need the AIR SDK (again, from Adobe Labs) and a text editor (and access to the command line to run the adl and adt SDK programs to run and package AIR applications respectively). Of course that might be a bit more work than you want to do. In which case, install Aptana - either standalone or as a plugin for Eclipse / Flex Builder - and then install the AIR plugin for Aptana. Now you simply create a new "Adobe AIR" project, fill out the application information wizard, select your JavaScript libraries (it assumes you are building an AJAX application) and off you go!