Hard Coding Scopes In CFCs Is A No No!
Now Hear This!
This is a public service announcement. If you hard code scopes inside your CFCs (request, application, session), stop today.
I know it might be 'easier' or 'cleaner' or less lines of code, but you are really painting yourself into a corner when you do this.
An object (CFC) should not know or have access to ANYTHING outside of itself, its configuration and its immediate dependent objects.
If you want to question/argue with me on this, go for it. (Just go Read Up On Information Hiding before you do).
That Is All
I Need Advice On Teaching My 11 Year Old Nephew To Program
My 11 year old nephew Cole, is really good with computers. He is a smart kid in general, actually, being in the top 2% in the USA for mathematics. He's even been to Space Camp. He is also a surfer, and you know how I like surfing!
He knows what I do for a living and I asked him if he was interested in learning some programming. When he said he was interested in learning, I began to think on how to get him up to speed.
Here are the criteria I've come up with:
- Dynamic, Loosely Typed (Dereferencing Pointers? Blech!)
- Low hardware requirements
- Free IDE
- High Impact (should be easy to make it do visible stuff)
- Lots of tutorials (self-learning is good)
Since I am not the first person to think of this problem, I'd like to hear what others are doing about teaching kids programming...thoughts?
Application Architecture and the elusive Right Answer
I often listen carefully to Chris Scott, one of the authors of ColdSpring. He has a keen mind for Application Architecture and Object Oriented Programming. Recently, while responding to a post on the ColdSpring-Dev list, he made a point that bears repeating. Rather than rephrase, I'd like to quote him directly:
There are tons of developers out there working on small teams that really don't need to be going crazy trying to protect their code against themselves. Larger projects, larger teams may very well set different standards[...] -Chris Scott
So often, the 'right answer' depends on all the elements in the equation. Architecture decisions are about effectively managing trade offs. The 'right' answer could be Extensibility over Simplicity, Performance over Maintainability, Clarity over Convenience.
A shop with 4 developers delivering lots of little projects has quite different needs over an enterprise with 50 developers supporting years of mission critical code. The cost of a mistake are not equal. The contributions of an individual is not equal. The measure of success is not equal. The 'right answer' is also not equal.
It is up to you, developers and architects to constantly educate yourself on technologies and standards. Be mindful of your environment. Challenge your viewpoints. Ask questions.
As for the 'right answer' I'll quote the ever wise Mr. Corfield, "It Depends".