Saturday, May 28, 2005

Delivering on Experience

As time goes on, and I get more experience, and hopefully wiser, I tend to see application building in a new way. Not in terms of just mastering the craft of delivering scalible applications, but in terms of delivering good experience to the end user.

And it is this new passion of mine, to deliver good experience, that really makes the technology not as important, that the good experience is delivered on.

This is part of the new trend that I call, Technology Transparent. This is the idea that in the eyes of the end user, it really does not matter what programming language, what server, what coding methodology.

What matters it the good experience. What matters is the kind of questions, end users tend to ask or demand of the applications we create.

Here is a list of some of those questions:

1. How easy is it to use this application?
2. Is there any kind of support or help system for this?
3. How do I train my fellow workers or other users on this?
4. Is this anything like the previous X application we used? If not, that will require more time for training.
5. Will this application stay up 24/7?
6. What kind of security systems do we have, and how hard are they to learn?

This is just like the kind of questions people ask when they switch operating systems, because people are being asked to transfer their paradigm of how they previously did whatever work they did, to a new application.

The learning curve has to be taken into consideration, we can no longer just build the application, and since it was easy for us to figure out how to use it, it must be easy for the end users.

In honesty, it's time for us to shift our awarenes of what we do, instead of being coders and designers, we really are Experience Deliverers.

Because everything we do is what the end user experiences in their ease or lack of ease in their use of the applications.

Let's take a for example, on how user experiences have to shift/adapt frequentally when they change what applications they use.

I remember back in the day, using Wordstar 2000, it was heavily dependent on using odd command combinations, and it took lots of training to learn how to bold, italic, postscript, whatever it is we wanted to do with it.

And now look at MS Word 2000, all graphical icons, and lots of tools, toolbars. That is a huge transformation of experiential paradigm. How can we imagine that people can constantly adjust their paradigms to understand how different applications work.

So from the end user's perspetive, they are getting new/changed/updated applications, but are constantly have to change how they work with them. Because the way applications are created, it's not kept in mind, how it changes the users way of working with it.

Instead of seeing how end users work with their current applications, and make the experience seamless with it, we're constantly changing the wheel, re-inventing the wheel, based on what we feel the experience should be, rather than what the customer really needs.

This goes to the reason we are doing this, I mean we all love creating interesting and wonderful applications, but what good are we doing, if the customers constantly have to re-learn how to use their applications.

So these are my thoughts, and it has driven me to create a new personal motto.

Experience First, Technology Transparent

Because in the end, what really matters to the end user, the technology or the experience?

Thursday, May 26, 2005

Managing Data in it's Scope and Validation

When it comes down to it, 99% of the time, we're processing, analyzing, tweaking to get data into both the datatype, and validity. However as time goes by, we learn different tricks to help prevent the common errors we had of the past: SQL Hacking, User Error, Scope Error and a few more I'll remember as I go on.

In my own preparations of the application, I think about what kind of data is coming, and what priorities different scopes have, and what kind of validation measures i have to stand by. So to help me, I've come up with means of setting that all up, to reduce the number of data errors.

I always use cfparam using a new name for the scope of the application itself. I simply create a cfparam of local_variablename, to help make sure that I have absolute control of what scope priority.

For example, in the past I can remember using the same variable name for url, form and local, and there was a lot of confusion as to which one was populating the variable in the application.

So let's say you have a variable called movie_id, first i determine what kind of datatype is that going to be? Most likely with id as past of the name, it's going to be a number. So i type in like this.

1. cfparam name=local_movie_id default=0 type=mumeric

2. What possible locations for data do I have?

cfif isdefined("url.movie_id") cfset local_movie_id = url.id
cfif isdefined("form.movie_id") cfset local_movie_id = form.movie_id

now i could re-arrange the above, into which source i want to come from.

3. Simplify the checking of incoming data

cfif local_movie_id then take action, else ignore and show error of no data sent from previous page.

4. Why is this better?

Because instead of multiple if's, checking each possible scope for it's existance and then having repetitions of the same exact actions, it's much easier to just have one if statement. Was the data passed, if so take action, otherwise error.

It's much easier to read, you just have to do the setup.

5. Use cfqueryparam

Now for different databases, cfqueryparam can improve performance, it depends if it has the feature called BIND Variables, which it treats the queries with different where values, etc to be the same, which means it caches the query and just changes what results come back.

The other major reason I always use it, unless i have to cache the query in other means, is for it's data validation.

I really don't care how simple or complex an application is, I always make sure the datatype is validated before being sent to the database. It makes a great practice, and makes sure you don't waste time, having to go back to fix your code after you thought you were done.

Now, maybe 99% of the time it never happens, or it's just some maladjusted user, playing with url variables, but you have to protect your database against that.

Now that we've made sure the data, is in the right datatype and is validated, what things can we do to make it more organizable and efficient?

It really depends on the complexity of the data and how many different ways you need to organize it.

I tend to like creating fake queries or as we call them, query of queries, because it makes it much easier to do all kinds of whacky where's/sorting/order by etc. They are really easy to set up...

1. First you create the query

cfset myQuery = QueryNew("first, last, address, city, state, zipcode, email, acct_balance")

2. Then you want to populate the data, and this is where it can get really fun.

Such as if you have this datafeed or report that is a file in a .csv format, you can convert it into a query of queries. I have done this quite a few times, and a lot of fun.

Or it can be a structure object being sent as an application, url or form variable, that you just need to turn into some kind of report.

Wherever the source is, it's going to be in the form of a looping mechanism to add row by row to the query object, called myQuery.

cfloop however your data is getting imported

cfset temp = QueryAddRow(myQuery)
cfset temp = querysetcell(myQuery, first, "#firstname#")
cfset temp = querysetcell(myQuery, last, "#lastname#")

the basic syntax is cfset temp = querysetcell(queryname, field, value)

/cfloop

Now you've created this query object, now you can play with it to help produce the results you want. And remember, depending on what variety of reports or results, to only grab the data once, unless you update the datasource frequentally.

Now we get into report generation, first what kind of data and in what order do you want?

For example, if you wanted the names, email of those who had a big account balance of over $100, you can do something like this:

cfquery name=bigbadclients dbtype="QUERY"
select first, last, email
from myQuery
where acct_balance > 100
/cfquery

Then you can do your normal cfoutput's, laying the data into table structures. OR for example you can export it into a csv or excel file.

Now you are starting to see, that once you have a handle on the best ways to handle data, you can do anything you want with them.

Have fun with your data, and share any of your best tips here at ColdFusion Purists.

Tuesday, May 24, 2005

Developing the Right Habits

I was reading Cameron Childress's blog on Building the Perfect Application. He talks about how people still fight over whether coding with Select * being a good thing vs a bad thing.

If you want to be a good/great coder you can't simply do the laziest habits in coding, you have to develop the habit of creating applications building skills.

I know these aren't exactly fun or hip or cool, but they make sure we make less mistakes, and don't have to re-code our work for a number of reasons.

Solid Disciplines to Prevent Future Re-Coding:

1. I always plan out my projects using either a word template or flow chart or both.

2. I plan out what incoming/outgoing variables so i make sure that each step of the application has the data it needs passed or sent.

3. I even go so far as to create all the commented sections of each application with all the needed indents.

4. Writing SQL Statements, I know we're all in a hustle to get the project done as fast as possible, but if we build the right habits, we'll still have speed, but have created more scalible and error-proof applications.

5. I create a funcitonal testing checklist, that i use to identify what areas as possible causes for errors, and create the traps around them, and the right locations. We can't catch ever error, but the more effort you do in preparing for them, the better you look.

In conclusion, the more effort you put into creating the right habits to create scalible and error-proof code, the less times, you'll have to come back later and re-write it. I mean, how many times have you had to re-write yours or other people's code either because of scalability/page loadings or bad handling of user/technical errors?

I have done it many times, and that's why I developed my own set of habits, to prevent, predict and fix problems.

"DO IT THE RIGHT WAY THE FIRST TIME."