> call them with CFSTOREDPROC rather than just CFQUERY.
How about a function or custom tag that makes all the extra keystrokes
of cfstoredproc unnecessary without eliminating any of the power of
them? :)
> 2) Learn what @@IDENTITY and @@ROWCOUNT mean, or better
> yet, what Scope_Identity() is (we use MS-SQL). If you
> write an insert process that involves selecting the
> max(id) out after the insert, walk out of the room
> immediately. I don't care if that's in the CF book under
> CFTRANSACTION. It's not best-practice and anyone who
> really knows CF knows it.
And @@IDENTITY doesn't guarantee the value you want because it's not
thread-safe. SCOPE_IDENTITY() was introduced in MS SQL 2000 with
little fanfare, so few folks are aware of it, but it is a necessity if
you're writing SP's in SQL2k that need to return an inserted identity.
> 3) Learn how to write cursors. It comes in handy.
Very much so in some circumstances.
> 6) Learn the dos and don'ts of CF in server farms
> (i.e. shared scope variables)
Is that a do or a don't? And why?
> 7) Learn best practices with CFLOCK
> (we're still with CF5, it matters)
Though you should try and have a deeper understanding of
race-conditions in general, and best practices with both CF5 and CFMX.
> 8) Learn best practices with cached queries and
> query-of-queries to take the load off the DB.
Although cached queries offer limited and quirky access to the memory
management. I tend to manage query caching myself rather than relying
on the CF Server's query caching. CF's native query caching does have
a couple of advantages - you can control the amount of memory used to
some extent in the CF-Administrator by setting the number of queries,
which isn't as easy to do if you write your own caching, and it
automatically expires the cache if the sql syntax changes -- which can
either be a benefit or a liability depending on the circumstance and
how well the developer understands cf's query caching. My bigger
problem with the native query caching is that you may never know how
many queries are in the cach (so you have to guess at whether or not
your app is caching more queries than are allotted in the cf admin),
and clearing the cache for a cachedafter query can be quirky/clunky
especially with CF5.
> 9) Know what fusebox is. If you don't even know the
> buzzword, you've been living under a rock.
Can we know what it is and still not like it. :)
> 10) Learn best practices in how to implement tracking
> routines and splitting systems up between production
> and reporting databases.
What do you mean by "tracking routines" in this context?
> 12) If you are used to Oracle or MySQL or something,
> learn MS-SQL too. I don't care if Oracle doesn't have
> identity or not. Know how to work with
> databases that do have them.
Identities are common enough that I'd say everyone should have some
understanding of them... developers should have a diverse
understanding of databases in general - some (if not in-depth)
understanding of the SQL standard, and at least rudimentary
understanding of the common/necessary variations in the more common
databases: SQL Server, Oracle, Access (yuk!), MySQL. Even though at
least in my case, variations in these db's are usually just
frustrations for me -- I wish SQL Server supported sequences and used
the standard name for their timestamp data type, I wish MySQL
supported views, I wish Access ... well, I'll not get into Access.
> 13) At least know a few gotchas like how
> CFLOCATION prevents you from writing cookies.
> A lot of intricacies of CF have to be learned
> through the school of hard knocks. Most of us
> know these common things.
One would hope.
> I've had people come in for interviews who can't even
> script out a CREATE PROC script on a whiteboard without
> leaving off commas and making other syntax errors, who
> don't understand how to rely on default values like
> GetDate() on insert statements by not referencing those
> columns.
With CFStoredProc the only way to do that is to either pass a null to
the procedure or make sure the parameter is the last in the sequence
since the dbvarname attribute didn't work and then was deprecated or
removed from the documentation. I wrote a custom tag and a function
(which calls the custom tag), which allow you to execute a stored
procedure using a structure as its parameters which lets you chose
whether parameters not found in the structure should be discluded from
the cfstoredproc tag or passed as null values. The problem with
discluding them is that if you are passing values further down the
list of parameters in the structure, they also _MUST_ be dropped,
there's no way around it.
> People who have never returned an output parameter via
> a stored procedure. To me this is really basic stuff.
> But some of these guys have years worth of
> experience based on their resumes.
You'd be surprised how many large and completely professional
companies never use stored procedures in their cf code. And in all
honesty not all of them really need them.
> This tells me these guys were dozing off for years in
> the corner of some office maintaining someone else's
> back-end CF code running on a single server, who relied
> on a dba to do all their DB design and procs. Or they
> worked in a team and the others in the team did all the
> heavy lifting.
Neither of these are _necessarily_ true. I have worked in places where
there were no dba's and where all the cf developers either wrote
stored procedures or didn't. In most cases I've seen, whether or not
stored procedures are used depends almost entirely upon the lead
developer on the project -- if he likes them, he yells when he sees a
cfquery tag. If he doesn't like them, then he yells when he sees a
cfstoredproc tag. There are a handfull of lead developers or project
managers who are in-between or indiferent to stored procedures, but
most of the ones I've worked with seem to have been pretty firmly
entrenched on one side or the other of this imaginary fence they've
made, which has little to do with what kind of software they're
working on and whether or not stored procedures would be good for a
given environment, situation or circumstance.
> If someone got into that situation, fine. But have the
> initiative, have the curiosity, to spend some of that
> free time cracking open a CF or SQL book and filling in
> the gaps of your skillset for the next time you have to
> find a job. You are NOT going to get the job based
> solely on your resume. You are going to have to show
> that the time you spent at these jobs actually
> made you a good developer.
It's an unfortunate truth that most developers are simply in the job
to earn a living. They're 9-5'ers... Most companies don't pay for them
to be trained or to learn on the company's time, and they're not
willing or interested in learning on their own time. So by and large
the only time they learn something is when it's absolutely necessary
because they're staring down a deadline. I don't blame them, ya know,
I gotta eat too, and it's nice to be able to have some time away from
work or work related things, although I do wish more of them would
have more initiative to learn more about their jobs.
> It looks _really_ bad to me when I see that sort of
> thing. I expect more from these people. I'd be more
> forgiving if they only had a few months of experience.
> A lot of these guys have plenty of other computer-related
> experience under their belt too, like Comp-Sci degrees,
> prior experience with other languages, most of which
> with higher learning curves than CF (like C++ or Java)
> so there really is no excuse for them not knowing the
> fundementals.
If they had degrees and held-down long-term jobs with C++ and Java
yes, I'd find a lack of knowldge of CF and database fundamentals quite
frustrating as an interviewer.
> Of course, the recruiters don't see this up front so
> they keep sending these guys over to waste our time.
Recruiters don't have the kind of understanding necessary to weed them
out... The only way you could hope for a recruiter to have this kind
of understanding is if the recruiter is also a CF developer competing
for the same job their clients want... which isn't very likely. :)
Though you left out a couple of my big issues -- I think everyone
should have a thorough understanding of how to write (and therefore
how to interpret) custom tags (attributes and end tags at minimum -
sub-tags is a plus) and functions. An understanding of CFC's is also a
big plus, but for the most part I wouldn't be terribly upset if
someone didn't have a deep or thorough understanding of them. At least
not yet... maybe in a few years if the CFC discovery process improves,
which unfortunately I don't see happening soon.
s. isaac dealey 954.927.5117
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
