Agree with Teddy that closing would be good.
Although (cringe) I don't. It's just not habit I ever started. But I
may change that.
As for "peeve" and all that - I was just ranting, really in response
to other conversations. And yes, "peeve" is personal.
I think the discussion is good to have.
_____________________
Derrick Peavy
derr...@derrickpeavy.com
404-786-5036
“Innovation distinguishes between a leader and a follower.” -Steve Jobs
_____________________
On Jan 5, 2010, at 11:23 AM, Teddy R. Payne wrote:
I can remember something anal and small that irks me.
I am a big fan of closing tags and scoping variable. I think it
looks more neat and adheres to an XHTML type mind set.
Example:
<cfset foo = 1>
This would ping my OCD part of brain and want to reach out and do:
<cfset variables.foo = 1 />
I know the scope and the fact that the statement is concluded. This
obviously does not apply to custom tags unless you program your tags
to respond to execution in the various states. *IF* it did bother
me, I would just not use the short notation and invoke it.
Oh! I just thought of another, I like to initialize variables even
though CF allows for dynamic creation of just about everything. I
like the "var" or "local" scopes. I started way back when on the
web in JS heavy shops and variable definition just carried over
deeply from C and C++.
<cfset var foo = "" /> or
<cfparam name="foo" default="" /> or
<cfscript>
variables.foo = '';
</cfscript>
... etc. =)
Prevents all sorts of problems for me when I receive data and
variables from unknown recipients.
My $0.02,
Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com
On Tue, Jan 5, 2010 at 11:04 AM, Teddy R. Payne
<teddyrpa...@gmail.com> wrote:
I agree that the amount of concurrent users and traffic do determine
how much preparation, planning, and code design is necessary. We
can definitely run into "scope creep" or "analysis paralysis" over a
simple problem.
Remember that "peeve" is a subjective and personal condition. It
does not mean that everyone should adopt or be concerned if their
code irks someone from outside their organization or even their team.
What I read from Allen's comment was more of a "use the right tool
for the right job." If you return 100,000 records for 10-20 records
at a time, I would agree that would not make sense network
utilization wise. A logical approach would be to return possibly a
few pages before and after the current page, so you are returning
30-50 records.
For smaller application with 1000 records, this may not be a design
approach or architectural consideration. I would say though if you
are comfortable that the size of the application will stay a given
size, then you are perfectly fine. If you have a small number of
users now, but expect more later, I would say that planning now
instead of responding to the performance issues later is always good
advice.
As for the OO approach for queries, it depends if you used an ORM
for your data access or if you are just using something as simple as
a gateway. A gateway being just a logically(domain) grouped custom
query objects that a service can call to get custom (non-generic)
data.
I like gateways myself if I have the ability to cache the gateway,
so as not to instantiate the object frequently. This, however, does
not have anything to do with query caching. You can still query
cache inside of those gateway methods, use stored procedures, or
cache stored procedures.
If I were to say that I have a "peeve" would be to see code that
implements a technique, design pattern, or functionality not to its
full potential. "Half cocked" would be what I would call this or as
someone of online buddies would say "borked."
You can get into endless discussion about when to use a framework,
design pattern, anti-pattern, ...etc. I think the original intent
of this email chain was more for identifying small little nit pick
things for fun.
Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com
On Tue, Jan 5, 2010 at 8:25 AM, Derrick Peavy <derr...@derrickpeavy.com
> wrote:
(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
-------------------------------------------------------------
