(looking forward to being told how wrong I am here and being raked
over the community coals for my heresy.)
Something that is clear from this thread - the needs of some types of
apps are different than others. Size and business does dictate coding.
For someone at UPS or another large company, there are multiple issues
defining code structure, techniques, etc., I would guess that at any
large corp. the need to do something in a standard way far outweighs
other issues. If you need to hire a developer, you need to be able to
hunt for a specific skill set which is most commonly used. Ergo,
matching your development to that makes sense. And yes, I do
understand that it is also good practice in general and proper form,
etc., etc.,
But I do believe that is actually the minority of cases. Places I
recall off the top of my head that use CF in all of their app, or some
CF in all or part of their large scale production app:: Bank of
America, UPS, MySpace, Nike (at one time). And I am sure there are
others people can point out. All of those should be using the latest,
hottest framework, 100% CFC's, etc, blah, blah.
Then, there is the rest of us.
Mostly small shops, small businesses, start ups or companies that are
never going to grow beyond 5-10 people and never more than 1-2
developers. Should we hack things and forget rules, standards, good
coding. No of course not. But there are other approaches to take.
In my app, CollegeClassifieds.com, as I said, I have four client vars,
some standard app vars and the rest are session - that's just an
example of the development approach - not something that is an issue
here. But yes - I DO mix queries and HTML in the same doc - proudly.
I don't use CFC's unless I have no choice or I use third party code,
and guess what - in the entire site, there are maybe, maybe 5-10
queries that are used more than once. And I don't mean that I copy a
query and make a slight change. No, I mean the data structure, the
layout, the pathways on the app, the code, the business goals, align
so that there is not redundant code or the need for it. If a query is
used more than once in the same exact way without changes, then yes, I
isolate it. But otherwise, no.
Here is an example:
This page - http://www.collegeclassifieds.com/
This page - http://www.collegeclassifieds.com/georgia/
This page - http://www.collegeclassifieds.com/kennesaw-state-university/
This page -
http://www.collegeclassifieds.com/georgia/kennesaw-state-university/jobs/
Are all the same file.
One file.
That entire file, and all the views associated with it are done with
just 8 queries - all very different queries that are never used, never
going to be used, anywhere else in the app. All very fast queries.
All very simple queries with not more than one join per query because
someone actually took the time to to frickin' think about the data,
the business and the code as being one. But that's the advantage
that a small business has. The person doing the code and the business
goals can be one in the same, or 2 or 3 people who can actually
communicate, take their time to build the right tools for the job and
not hack something.
In real terms - maintainability, extensibility, troubleshooting, this
makes life very, very easy. Need to fix a problem - you have one file
to look at - ONE! And I don't mean it's 5,000 lines. Usually, it's a
couple hundred, if that. In many cases, less than 100, 33 are empty
lines, 33 are comments, and 33 are actual code (simplifying here).
If I need to change the sign in form, the contact form, an about page,
pretty much any page view / screen, I have one file and one file only
to examine. One file to break. One security issue. One concern. And
if I die, then I know that the least capable CF developer in the world
can pick up my code and go forward. That is worth a lot.
Question - how many people on this list have an app that get's 100k
page views/loads/crawls in a single 24 hour period on a regular basis?
I'll go further out on a limb here and say that if a CF developer gets
his or her "panties" in a wad over CF and HTML in the same page, or
they "just don't 'get' HTML," then they need to "get" out. Period.
I've done Fusebox for years before this, I've looked at other
frameworks and guess what - even when working for others, very rarely
was a query actually used in the same form in more than one place. Too
often the query was isolated through a call (CFC), with 5, 10, 20
parameters that could be passed to the query from 10, 20, 40 different
screens/sections in the app. Which means.... when the next person
comes in to the development team, they have to learn all of those
aspects of the app before making one single change. The time, effort
and complexity involved in doing that - all in the name of "reusable
code", "extensible code" or some other BS term never, ever, ever pays
for itself in most apps.
Again, there are cases where this is not true. And one example would
be any shopping cart style app where the same queries (what's in my
cart?) could be used in various views, in various places. So, those
needs are different.
The "hottest" thing today is LAMP. So, go take a look at some of those
awesome PHP ini files. Fun, huh? You have to read the da*n thing. You
have to take the time to understand the settings there. And people
think it's the holy grail, the shizzle. So that's where we are. And
yet I see CF people who want to take a simple app, divide it into 10
sections, all with their own app.cfm file settings, each sub section
broken into it's own sub-directories with CFC's and modules and by the
time you are done, you have an app used by maybe 20 users a day, with
75 directories and sub directories all in the name of proper coding or
OO, or pick a topic. Care to come in behind that developer and
troubleshoot that pesky session var that keeps breaking and creating
problems because "sales dude" can't run a frickin' mouse without
bringing down the network? That's fun, eh?
My app
1. An application.cfm file that covers the app - yes, all of it. With
code that is explained and commented. This also forces the developer
to consider each and every da*n scoped variable they want to create.
Do you really need it?
2. An index file in the root which is the site template.
3. A folder containing the pages/files that are used for the app.
Each file is called and included in the index file when needed (only
one at a time). Each screen is it's own file. And this is done without
a 5000 line cfswitch/case structure. It's actually butt simple. User
clicks a link, a specific page file is called and included in the
index file. Done. Over. Nothing more to do. Files follow standard
format:
<!--- start file --->
<!---
===============
START: QUERIES USED IN THIS PAGE/SCREEN/WHATEVER
===============
--->
<!--- query one does ABC --->
<!--- query two does XYZ --->
<!--- set some scoped vars if it makes you feel good, but they better
be in the application.cfm file and they better be used in other places
for a darn good reason --->
<!---
===============
END: QUERIES USED IN THIS PAGE/SCREEN/WHATEVER
===============
--->
<!---
===============
START: PAGE VIEW/OUTPUT
===============
--->
<!--- some XHTML and content --->
<!--- if using a query output or any cf var, cf output, etc., isolate
with space, comments and explain --->
<!--- see an application, client or session var?? Really? Well then,
open the application.cfm file and learn what it does before you muck
with it. If it's been designated worthy of being in the
application.cfm file, then it's used in more than one place, it's
important, and it's probably going to be explained in that file. --->
<!--- need a var on this page that is unique to this page, not sticky
and will disappear as soon as the user leaves this screen? Well then,
it doesn't need to be client, session or application now does it? --->
<!---
===============
END: PAGE VIEW/OUTPUT
===============
--->
<!--- end file --->
_____________________
Derrick Peavy
derr...@derrickpeavy.com
404-786-5036
“Innovation distinguishes between a leader and a follower.” -Steve Jobs
_____________________
On Jan 5, 2010, at 7:18 AM, <axunderw...@ups.com>
<axunderw...@ups.com> wrote:
My biggest pet peeve:
CFQueries inline in a CF template. I'm not a stickler for complete
object oriented or "you have to do things exactly a particular
way"...that being said, I have two reasons why I like to see
cfqueries or cfstoredproc calls in a cfc or a cfm template that can
be called as a cfmodule:
1. You know where to look for the code - if you do it in a cfc, you
can have all your data access calls in one place that is easy to
find in various methods
2. If you're writing a query to be used on a page somewhere, chances
are, you'll need that same query again somewhere else - this doesn't
always stand true, but 9 times out of 10, you use the same general
queries for multiple areas on a site.
My second biggest pet peeve:
Looping over a query just to query x number of times again. This is
probably the thing that I see beginners do the most, probably
because they just don't understand how to write a query to retrieve
all the data at once. For instance, someone might want to see their
top 100 customer's orders..a lot of times you'll see someone write
a query to retrieve their customers, and then loop over that query
and then query to get the orders (so basically 101 queries to the
db)...in reality, all they had to do was a query from the customer
table left joining the order table in one query, and then looping
over the results with a group by.
The last one I can think of this early:
Using CF as your paging repository for large datasets...this is
probably the fault of many a book and message board out there, and
probably just having the feature available in CF makes it too easy
to pass up for most. But, the ability to query a db, retrieve
100,000 records, and then just using records 10-20 or something like
that. I hate seeing that. The amount of network bandwidth being
utilized, the memory being wasted, the processing required from cf,
etc. It's just a horrible thing to use. I cringe every time I see
it...and if I have my hands in it...I change it immediately to do a
db implementation to just retrieve the rows needed.
From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Derrick
Peavy
Sent: Monday, January 04, 2010 9:07 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Examples of How NOT to Code in
ColdFusion?
<!---
============
MY FIRST PET PEEVE
============
--->
<!--- people need to learn to comment their code --->
<!--- for example, when I have to throw in a hack, i like to remind
myself to remove it --->
<!--- so I type: "hey dumba** - remove this comment and code block
as soon as you can figure out how someone is loading this page, four
screens deep in an app without any client or session vars enabled in
the client when it should be impossible and the page will not even
load when tested by 20 different browsers in 7 countries" --->
<!--- I have an important file in my app that is probably 50%
comments. seriously. because it's an awesome file and elegantly
simplistic and responsible for 50% of the data on the site, so it's
nice to be able to go back when tweaking and know why something is
done the way it's done. So, maybe 350 lines of code mixed with xhtml
and another 350 of comments. overkill? yeah. But if I die, you won't
have to guess! --->
<!--- just to check myself after your post, I looked over my app.cfm
file, I have a total of four (4) client vars, two of those can be
int(11), one can only be a single digit, and one can only be either
"Y" or "N" --->
<!--- there are some application variables for things that never
change and so they can persist across any client or time up to the
max allotted time for app variables to expire --->
<!--- everything else is session with a reasonable time out setting
--->
<!--- not unusual to have 100k page loads total considering all bots
and spiders and users, and 7 or 8K user page loads in a 24 hour
period with no cpu spike or lag time unless a background data
process is scheduled --->
<!---
============
MY SECOND PET PEEVE
============
--->
<!--- writing every gosh damned query as a fricking cfc --->
<!--- the beauty of CF is that you can actually just write a da*n
query and just run it --->
<!--- which brings me to... --->
<!---
============
MY THIRD PET PEEVE
============
--->
<!--- people who can't accept a database structure that gets the job
done without 100 x-ref matching tables which require 42 queries to
get a user name and email --->
<!--- stop it. just stop it already and learn how to make data
simple and accept that you are not Aamazon and you will never, ever,
ever, likely scale your app beyond a few hundred concurrent users
accessing the minimal amount of data --->
_____________________
Derrick Peavy
derr...@derrickpeavy.com
404-786-5036
“Innovation distinguishes between a leader and a follower.” -Steve
Jobs
_____________________
On Jan 4, 2010, at 7:12 PM, Cameron Childress wrote:
On Mon, Jan 4, 2010 at 5:18 PM, Derrick Peavy <derr...@derrickpeavy.com
> wrote:
So, five session vars, numeric in value, less than four digits (or
single
char values), along with multiple client vars of less than 4 digit
numeric
values or single chars - you're saying that's a huge eff'n no??
I ask because at even 10,000 page views a day, I see no
performance hit at
all. But then, maybe if I change it according to some rule, I
would see
average CPU loads of 0.004 instead of 0.04??
Well, considering the relatively low load, and low number of
variables, I don't know that it would have a significant impact in
your case.
Like I said, there are always exceptions. Nine times out of ten,
however, when I see both client vars and session vars both enabled in
an application, it's for no good reason at all.
What's on your list of no-no's?
-Cameron
--
Cameron Childress
Sumo Consulting Inc
http://www.sumoc.com
---
cell: 678.637.5072
aim: cameroncf
email: camer...@gmail.com
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------