Tuesday, June 28, 2005

How I create an application

I know we each have our own styles and methods, but let me share the methods I use to create an application.

I'll put it into a checklist, because that's how I can make sure i got everything done in the right way and order.

1. Project Details: I really need to have as much information on a project as possible, because I don't want to waste time and energy on code, only to find out, it was nothing like what the client/end-user wanted. So get the details, ask as many questions as possible.

2. Project Plan: As you get into more complicated projects it really helps to plan everything out. There is a saying that sounds corny but really works in the real world. "Plan to Work, Work to Plan". The project plan can be simple to complex, but the more effort you put into it, for the simpler projects, the more prepared you'll be for the complex ones. This can involve using a ms word template, notebook paper, flow charts, wireframes, etc.

The other benefit is that if you store this plan you can refer to it, for future changes to this application, so you can a better idea of the thinking behind each project.

3. Dev Enviornment: Where am I saving the files to? What folders, server etc. And how can i test and debug the application? Do I have access to cfadmin for easy debug? Make sure your setup so, you can go to coding.

4. Comment Header: Basically name, description, author, manager of this project/application. Include version number, dates/times, more details is better. Because not all the time you'd be working on new applications, there is always new changes/fixes/features to be done to existing applications. So prepare the way by having a detailed comment header.

5. Comment out what each section of the application will be. Before I code each section, I create sectional comments to help indicate what code needs to belong where, to make sure I know where to put each code, and i describe what each section does, and I use indents as they would be when I add the code beneath them.

6. Now I work on incoming and outcoming variables. Over my experience in issues with scoped variables, and isdefined or parameterexists, I have my own system and naming system to help me control and simplify incoming data.

I always create a cfparam for any possible variable, and name it like local_first_name. Even though the form field may be form.first_name.

Then I have default blank values for all of them, unless they need to have a special value.

Now I no longer have to check for the existance of variables, and then there values, now i only check for values.

In the past you had to do

cfif isdefiend("form.first_name")
cfif form.first_name eq "Craig"

Now I can do

cfif local_first_name eq "Craig"

Now before I can use these local_ variables, I still have to populate them.

And this is where I can get into more specific control of scope priorities.

I can say that I want an url variable, to pass value more than i want a session variable to pass the value.

The reason for this extra detail into scopes, is because if they have the same name, they can be over-written without you being aware of it. (Because at some time I had this horrible application that variable named clk, that was being populated by a bunch of different scopes with no scope specificity or prioritization.)

So we have a cfparam variables all populated, if you use additional variables, please add them to the top section with all the cfparams.

7. Logic, now i go over all the logic that I have to go thru, what kinds of conditions, simple or complex. If simple I stick to using CFSWITCH & CFCASE because they are faster than cfif, but if it is complex, i stick to CFIF.

8. Queries / SQL Code, here is where I go thru a similar checklist.

A. Use a sql tool to generate the data, you'll need for each query, and then put it into the order you want. Select * is a definite NO NO. It is better for performance and scalability if you stick to what fields you want from what tables.

B. Once I have the data for each query I want, then I convert it into the dynamic queries, and use datatype validation via CFQUERYPARAM and CFPARAM to make sure data sent to databases is exactly what we want. CFPARAM has an additional but not well used paramater called type, so that as you copy from different scoped variables to the local_ one or whatever naming convention you use, then you can make sure it's the right type. In addition CFQUERYPARAM also has a CFSQLTYPE to make sure of data type. You should at least use one way of data type validation, for security sake.

C. Performance Analysis, I look at the CFQUERIES in debug info, for times that are over 250 milliseconds. I verify that each query is only bringing the data in terms of fields and rows that I need. I make sure there is no looping of a cfquery because that is very bad for performance, and there are other faster ways to grab data. I look for queries that should be converted into VIEWS, if they are multi-table joins or complex sql code, then they are open to being converted.

9. Error Proofing, no matter how hard we work, there will always be errors, so now I double check my variables, logic, queries, then look for areas that might crash, and then i put CFTRY/CFCATCH. Make sure that there is a custom error page, to re-direct to, to make sure the user feels we are professional in how we handle our errors. I'd rather spend the time proofing and preparing, then having to explain an error to them that cost them a lot of money.

10. Functional Checklist, now I start looking at all the project details to come up with a checklist of how to determine if this application does everything that it is supposed to do.

Once you feel you did everything right, then hand it off to someone else who has not seen the code, and have them go thru the functional checklist. Become expert in helping others break applications, because if you get that knack during development, you'll develop the instincts and skills to prevent repeating mistakes.

11. Schedule the release of the application to production after it has been approved.

How do you create your applications?

I always make sure I have as much details about a project as possible. I don't want to repeat the experiences of wasting time and energy, only to find out I was no-where near where the end-user wanted me to be.

Coldfusion Basics

I've been working on a new job possibility, and been meeting people who are new to Coldfusion and Coding, and it intrigues me. Reminds me of the struggle we all go thru in teaching ourselves to code.

So I really like to go over, on the basics, maybe it's boring, but I personally finally , we focus so much on the cool stuff, that we may not master the basics.

If you know me by now, i find it really important to make sure each application is scalible. Meaning, I don't want to have to re-write an application, because I didn't take the time and effort to write the SQL and logic code to be fast.

I know we can be lazy at times, but that's why we need to maintain the core basic disciplines.

1. Take pride in your code, and make sure it won't go back and bite you because you did not give everything you had to make sure the quality is high. To our end users, the application layout and functionality are most important, but in the real end in terms of long term costs, the quality of the code is just as important.

2. Commenting, whatever system your company uses, more is better. Remember if you died, how would anyone know what exactly you did, and how to change or fix it?

3. Indenting, for other coders it's really important to be able to read the code, in case they have to change or fix it.

4. CFSWITCH vs CFIF, if the comparrison value is simple, then use CFSWITCH, because cfswitch executes faster. But only for simple values, keep using cfif for complex logic.

5. SQL Code, even if this application is only meant to be for a low-traffic site, what if they suddenly get a huge bend in traffic, but it keeps crashing the server? That is exactly why you have to write the SQL Code for scalability.

6. Modularity, I know as the lines of code grow, we want to split it up, so it doesn't get too out of hand. In the old days of coldfusion there were not as many ways to break up your code, and that has changed so much. The key thing to think about is how it effects performance and whether it takes up more to setup than necessary.

That's it guys, and feel free to send me any cold fusion question, I would love to help others learn.