Wednesday, December 28, 2005

Oy, Managing Each Day

I was reading this interesting blog post on Ray Camden's Blog. About how he has his own ways of managing his projects and tasks. Mainly because his memory is going, bonkers.

I had my own comment about that, because mine has been going, the more I got into web programming.

The more I find that you get into deep programming/analysis/logic, your solutions come more from subconscious processes, the conscious ones.

But my reason for the post today, is to find out what kind of daily processes each of us uses to help keep track, moving forward, getting things done each day.

For example:

I use to create a new daily task sheet to print and put on my monitor clipboard to help me remind what i needed to get done and worked on each day.

Are we all getting older, or does programming change our brains?

Just curious :)

Happy Holidays and New Years to all of you and your loving families!!

Monday, December 26, 2005

Seven Stages of Expertise: My Thoughts

I have to admit this is something that has been on my mind. Seeing how different levels of technical and professional expertise change.

There is a maturation process, and that probably isn't well defined, how one person goes from one stage to another. Which probably is what interests me.

It really depends on what intrigues you, learning more about what factors can lead/dislead to project success, and what factors help mature both the process and people ina project.

I find that both are very important, but in the end, in any industry it really comes down to the people and the skills can they deploy towards goals that matters.

But let's ask an interesting question, what has helped in your maturation process? If you can talk to yourself in the past as a Stage 1 Expert, what would you tell yourself to help avoid the bumps and skids of the learning process and curve.

Thank you

Monday, October 24, 2005

The Importance of Architecture

Now having completed a really good class on the Intro to Fusebox as taught by Jared, at the MCTC in downtown minneapolis...

I hear that a few of my previous readers and comments expect to be go all google eyes and say how wrong I was and all that.

Well in a sense I was wrong. I really see the importance of having a common architecture to speed up development and the working with teams or individually.

And I also see how usefull it can be to seperate the presentation layer, I can dig it's usefullness. But to me that really depends if you code alone or not.

I still have a lot to learn about Fusebox, I find parts of it fascinating, but other parts not so impressive.

This is not a knock on architecture's, fusebox is obviously a step in the right direction, as great as procedural programming style is, it doesn't really comprehed the long term approach that well. But neither can our focus on architecture get in the way of completing tasks.

I see it as a need of balance, to find the approach that covers the butt in both directions...

1. I really still hate how all the apps refer back to index.cfm I am sure the url variables can be made search-engine compliant, but I am more honestly concerned about the lack of bookmarkability, to help customers know what page they are at.

I understand why all actions go to the same page, because it has a lot of processing to do, to enable all the custom architecture that fusebox has, and any additional methodologies it want's to have working with in, such as Model View Controller. MVC, is kind of cool to be honest.

But i believe that if we can hide what page we are by creating physical pages for each public fuseactions, that calls the appropriate fuseaction with a few lines of code, which will do alot to make the fusebox pages much more user friendly. Easier to remember, and bookmark.

2. Fusebox can be a real bitch to work with if all your other applications are done without a specific architecture or methodology. It really does make it harder to figure out without having worked within fusebox, to translate fusebox apps to non-fusebox methodology.

3. The setup for each fusebox has to be improved and simplified, let's enjoy the architecture without having to each of us create lots of folders, subfolders etc... I honestly found the setup part hard to do, and I can't imagine having to re-create the whole fusebox for each seperate app that exists for the same website. Unless I am missing something, which is possible, after all it was only 2 days of class.

Now for things I am knock down impressed by:

1. I really enjoy working with a solid architecture, it has all teh core values I've always wanted, documentation, coding style, naming conventions, teamwork, workflow, and I want to do a lot more proto-typing, and really get into smoother projects.

2. I kind of am hooked into MVC, still have a lot more to learn and I want to play with it more...

3. I like the idea of a parser of fusebox apps into a much more optimized app, makes complete sense. I am kind of curious to how that exactly works...

4. I want to learn and master FLiP, project management has always been something I am interested in, because it makes development that much smoother. I may be interested in getting certified in Project Management. So I need to find some good places to learn and master Project Management.

Is fusebox perfect? Of course not, no architecture is. But it's a step on the road of evolution of web development/software engineering.

Thank you, and I hope to hear any thoughts you have.

Friday, October 21, 2005

Good Morning Fuseboxers!

Well here I am Day 2, still alive. I am liking FLiP, and I just need practice prototyping, as I have never done any of that. However I strongly agree in not coding until all plans meet the approval of the client.

I completely hate wasting time and energy re-doing applications because:

1. client either did not know what they wanted
2. didn't know how to communicate their wants
3. They couldn't make up their mind as to what they wanted..

Fusebox i believe is a step in the right direction, but i agree i have to fully use it to really get my feet wet before i can say use/not-use.

However the setup for each app is a pain, but I am more than willing to give it a try.

Here are this morning's class notes...

----------------- Friday Morning - Day 2 Class Notes ------------
FLiP - has nothing to do with engineering lifecycle process...

FLiP - Fusebox LIfecycle Process

70% fail to meet their objectives
-budget, timeline, feature set

-fail to plan, plan to fail

1. Wireframe - Set diagrams
2. Prototypes & Devnotes
a. Prototype is a fully html ui generated for each page/step - Full as if the application existed. Static HTML Version
b. Devnotes helps communicate what's done/missings for each prototyping
3. Code Planning
a. skilled application architect defines the fusedocs... fuses, fuseactions
4. Coding
a. write independent fuses, team or pair-coding
5. Unit Testing
6. Deployment & Integration

Design Interface First, then let the interface indicate the database design/queries
Then fusebox interfaces/controlls the two. and the interaction of..

Mail Reading Application
-Home Page with login interface underneath it
--Post to List based email messages interfaces
--- Link back to previous step
--Read Email Messages
--- Link back to previous step

P.S. Here is a really funny tie-in with the Minnesota Vikings. Denny Green is one of my favorite Business/NFL Books talked about "Plan your work and work your plan".

Planning is really essential, and sometimes under-looked by real small web shops.

More to come....

Thursday, October 20, 2005

Last Fusebox Update of the Day

We discussed a went thru the whole abstraction, mvc actual usage etc...

I need to read the Book by Jeff Peters Fusebox 4 & FLiP

You guys should have been here...

---------------Evening Class Notes ----------------------
Long argument about long vs tiny urls, I thinks i've hit a hot-button...

xfa = exit fuse actions, actions by which we exit

This brings up the question of what really makes a good framework?
1. Invisible and usability to the end user - They have no need to know what framework we use, except for what page they are at, and how to get to where they want to go.
2. Easy Setup & Install - Each time you create an application, if you have several hours just spent on setup, it makes no sense. What's better is a simpler or pre-packaged installer, so you can spend time planning & developing and not just more configuration.
3. Simplified workflow either working individually or on teams

Now abstraction has some interesting features, but if your not familiar with the framework and abstraction, it can be painful trying track down where variables and data are populated and created.

Afternoon Fusebox Class Update

So far, it's been rather educational. We're on the same path of wanting long term great applications, but there are some serious thoughts made into fusebox. I still feel it has major work to get to where it will both be more usable and scalable from the end-user perspective.

However also, there is a lot of setup involved as a new fuseboxer to create each application, if that can be simplified or automated that would really help.

However what this class is introducing me to, is the real necessity for frameworks or methodologies in coldfusion...

Jared is damn smart, I may ask a lot of stupid questions, because I want to get a full understand, and having only worked on 1 fusebox application, in terms of incorporating it in an existing non-fusebox application, it can be difficult to grasp.

I find that fusebox can be a great doorway to learning more of frameworks and getting more polish into your professional skill set.

I find that very vital...

Here are my afternoon class notes for my fellow classmates in MCTC. And we had a great lunch at Davanni's oh man that was filling.

------------------------Afternoon Class Notes --------------------------------
Installed CFMX 7
Installed Dreamweaver 8 YUCK!

-Controller - xml files, configuration of all fuse actions????
-Model - CFM Files
-parsed - parses xmls and compiles directives and cfml template and executes
-plugins -fusebox plugins cfm templates, referrenced from the xml file
-view -interface files, form tags, table tags

-Controller Circuit main.prodlist
-Model query select * from tblProds - getallprodsqry.cfm
-View -/include dsp_prodlist.cfm Include layout.main.cfm name=body

layout.cfm looks like this

Saves whole app to the parsed folder -- Worth investigating

For each fusebox application, you have to reconfigure, drop skeletalMVC folder/files

precedenceFormOrUrl either do form or url grabbing...which takes precedence...
password - force fusebox to reload a file in the parsed folder
mode - development vs production


This is the configuration file fusebox.xml.cfm

Each application would get it's own configuration file.

enumerate what does that mean?

-a symantic improvement

page contest

scope prioritization, scope variable searching...

page context level for each variable scope

1. Plan it out
2. Create model
3. Create views
4. Create XML behind two

Nifty circuit aliases, to reference functionality in different parts of the application

circuit access="public" vs access="internal"

internal mode is kind of interesting...


Fusebox can be fun to play with, I am not sure about it's scalability or index.cfm?fuseaction issue, how it appears the developer does matter, and I am fine with that. If the two main issues are dealt with i am fine.

I am curious about the process of the compiling into parsed files...

Why not have the database do it's parsing of content and then in a stored procedure get the call of what content to display. Point being why not have the database do all the work instead of having coldfusion do it.

Controller gets the request and passes the work on to model then displays results via view.

use fusebox tags rarely unless necessary...

I think it is realistically possible to hide the links that go to the same page, either thru javascript, or we can have a link page creation process...

Where we loop thru each fuseaction and create a physical file for each that actually calls the fuseaction,but how does that deal with form or action pages. Unless it was done via a cfinclude.

Update FuseBox Class

I am actually quite impressed with the way Jared Rypka-Hauer of Continuum Media Group LLC are presenting this class.

There may be some things that I disagree with :)

But there is a solid agreement I feel we all have and that is to code ColdFusion Applications that are good for the long term.

If I die, how easy is it to fix, repair or modify the application(s) I created?

Well here are the notes from class so far.

Thanks for listening....

Frameworks? in general, what they are, what they provide
-What core code, actual files, pre-defined functionality. Procedural Framework
-When All the time...
-Metholodogy how to use the framework, built around the framework

Always see \index.cfm?fuseaction=guestbook.showform

guestbook is the circuit a collection of functions/actions
showform is the fuse that indicates what action to take

Hooks - plugins, pre-built actions, referenceable

Framework Definition
1. Sources
2. Methodology
3. Save Time
4. Communicate

MVC - Low Level to High Level. High Level Architecture Design Pattern.

-File Access

-CFM Templates - "PODS"
-Navigational Includes
-Logo Header

-Send Messages To Model
-Getting or sending Data
-Gets Data --> View
-Sends Data <--- View

96% of stats are made up on the spot

Very streamlined makes you more efficient, that is reasonable and understandable.

The way you think matters as much as the way you work....

Implicit Invocation - Clean The Kitchen - Not requires a lot of description
-One high level command to many tasks
-Main.home - main circuit home fuseaction
-More of a global command to refer an implied set of tasks

Mach II - Implicit Invocation

OO vs Procedural

-object orientated
--Defining Entities
---Real World Object like user, blog entry, shopping cart
--What should those entities do?
--Should user object talk to database or just be a container
--Encapsulate - it know only it knows
--Inheritance yuck!!!!
--Data Centric
--Defining Representation
--Each object has a specific role and defining them can be better for long term development,
---okay that makes sense, now how do i figure how to translate what they're saying...

---Do this do this do this, logical
---Tasks vs from point a to point b

ColdSpring, Carton - Persistant Storage Mechanism

Instance Variables

Gateway Objects

P.S. I am finding that my understanding of OO vs Procedural may be incorrect. While I do honestly see there is no standard for long term thinking in procedural programming, it is easier to think and put my head around it.

I think that would be a worthy goal, to find a middle place...


Let Fuseboxing Commence

Here i am, where is the alcohol or anesthetist to immunize me to this training...

Lol, just kidding...

Here I am a beautiful Minneapolis Morning, downtown, beautiful day.

A bit chilly outside, I have met Jared, Gary and a few other brave CFers that have decided to come down to MCTC and learn fusebox.

I am actually interested in learning, I am willing to give it an open shot, for 2 specific honest reasons...

1. If CF Shops are only hiring CF developers based on them knowing fusebox, then i have to adapt, i need a job like everyone else does.
2. I am curious about FLiP, as many of you know I am interested in developing better practices and life cycles to improve the quality and flow of work.

It does look interesting...

More to come...

The funny thing is when Jared came in with a CafePress box, I thought it was from that custom t-shirt site, and lol, I asked if the price of admission came with a free t-shirt...

Oh well I am trying to make the most of this...

I really do enjoy programming in ColdFusion, and I do want to be the best as I can be. Ever since I saw a few of the greats of the early CFUG...

What drives you to CF?

Have fun!

Tuesday, October 11, 2005

Framework Translation/Conversion

Now as I get closer to when I take this Fusebox class, and I keep hearing really interesting and different posts on frameworks, methodologies, I am kind of seeing a change what my real concerns with different coding methodologies instead of just my core emotions...

Really the problem was that we all code from different situations. Some of us code solo, some of us do agile partner coding, some of us do team coding, we all do it in different ways.

So then the bigger concern is how can the different situations work together well...

I think there should be a form of etiquette to help us work together better...

For example if your a web shoppe, your coding methodology should adapt itself to whatever coding methodology the client's code is in. Unless your the only people doing codework for them.

However most of the time, fore big companies, lots of different web shops have done code for them. So to all have different applications, created completely differently makes sense.

Sure you can introduce new methodologies or frameworks to your client but if they're not signed off on the latest method/framework then stick to their style.

We all like to code in different ways, or experiment but why are we experimenting with them at our clients expense?

Above are experiences I have seen at different client companies I have worked at. Where the outsourced code would be done in fusebox or cfc's and 99% of our code was still standard CFML.

Either then all code should be converted to X framework/metholodogy.

For example, at one company our checkout ecommerce code was outsourced to a web shop, and the result was a CFC and application that interfaced with that CFC. I am sure it was very interesting, but none of the rest of our site's code was in a CFC, and are CFC's always the best way to go?

We really need a multi-part solution:

1. What framework/metholodogy consisteny should we use for our clients? Do we use our favorites or use the clients? What if the people that work at the clients dislike your methodology?
2. When is a good time to introduce methodologies to clients? And when is it not a good tme?
3. Which kind of frameworks are best for which kind of applications? Surely there is a performance guideline both in terms of ease of setup, scalability, modularity, there has to be a measuring stick so we know which tool for which problem.

Because acting in the dark like we are isn't very healthy.

I want honest conversation, honest questions, I am here to help us be a better industry. If you just want to flame, please go elsewhere...

Monday, October 10, 2005

Intro To Fusebox

Well the day has finally come, I need and am going to take the intro fusebox class. It's not like I don't want to learn anything new, i just want to learn things that make me a better coder.

In this case it's more about getting skills that will get me a job.

Intro To Fusebox

I don't hate fusebox, as much as not really want to use it, because 100% of the time i'm a solo coder, working on hte full application.

I also don't like having all applications go thru a central app, which over time can tend to get bloated. That's how these things can get...

However there are some real pluses to fusebox, that I bet most of you thought i'd never say as long as I was alive...

1. Modularity - This is to be commended, and modularity used correctly, for maximum performance.
2. Teamwork Oriented Framework - I commend any method that helps new coders and old coders work together to create better products.
3. Standards, standards - I may not agree with all the standards of fusebox, but getting coders to stick to a standard instead of making one up, every week, is to be commeneded. This is a major problem in our industry.

Now as for OOP, I really don't care if other people use any model of thinking as long as it produces results, but then as long as i can produce results,why does it matter how i think of programming?

I have done plenty of javascript programming in my career, it is object oriented, and I can usually get done what i need to get done, without being a hardcore OOP.

For me the highest goal is creating solid applications we can be proud of, and not have to fix, upgrade because it wasn't done the right way the first time..

I also feel it's important we think about the posterity, if we died, how easy would it be for other people to fix, learn, change, any of the applications I created.

But when lots of people use lots of different ways, it creates havoc for other people who may have to change/alter their code.

Instead of making this a holy crusade for whichever framework or methodology or thinking process, we should concern ourselves with creating great applications, solid standards for our industry, and finding ways we can work together, instead of fighting..

I know i've had my share of flaming, but I'm done with that, let's move on, let's make ColdFusion the best web industry it can be...

I've been reading a lot of interesting stuff on fusebox, oop, and i no longer care about the flame wars, I just want to get a job, learn to master my craft.

And just keep moving forward...

Does anyone care to share their thoughts?

Wednesday, July 06, 2005

From Coder to Manager of Coders

It's amazing to be on a different side or perspective, but I still feel that the core ideas I always stood by, are even more important now.

1. Having documented and used Coding Standards
2. Using a Project Management Process & Intranet
3. Helping others and myself train to become even better.
4. Managing costs at different levels of growth.

There is much more to do, and think about, that I never realized when I was just a coder.

What others have you, have made the transition, and what sites, books, articles have helped you do it wisely and professionally?

Thank You.

Craig M. Rosenblum
-Technical Director

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.

Thursday, June 23, 2005

Search Engine & User Readiness

As we deliver more and more rich flash experiences, we must consider how our browser experiences affect the users.

I remember when I was working with one company, and all they're folder names, file names, did not make sense.

And why do they matter to end users?

To help them remember where they are, and what part of the site they are on, and to help clue them as to the informational architecture of the site.

For example with Ablecommerce, the shopping cart part of the site was in a folder named ecom7, and the file names were really not understandable.

This does mattter, because if the customer can understand the folder structures, then it makes them easier to navigate.

Now we go into flash applications, where whole web sites, can be in one url. Which is perfectly fine.

Then here's the question:

How do we help visitors bookmark, a specific part of the flash site? I mean an article, content, advertising? If we have an intensively content heavy site, we do not want to force people to go thru 10 steps to get to the page they were originally looking for.

I would like to hear from Flash people, how they deal with these kinds of issues.

Thanks, and please comment, so we all can learn from each other...

Monday, June 13, 2005

OT: Michael Jackson found not guilty

I really don't know what to say about this, except I felt certain he was guilty.

It's sad, I can't be sure he's innocent, and that he's somehow bought the jury, or that the prosecution screwed up so much.

But since I don't know all the details, it's really hard to be sure.

I really hope MJ gets some therapy, because he's got a new lease on life, it'd be good, to make sure he stays clean and doesn't provoke any future problems.

I wish the best for him, and please stay clean.

Why CF can be a scary ride sometimes..

I've been reading a post by Mark Kruger on Coldfusion Panic - why CF coders scare easily, in there he talks about how easily CF coders get scared when big changes happen.

This is something so poignant at a time, when we've got the Adobe/Macromedia merger happening.

We all remember the change from Home Studio/Cold Fusion Studio to Dreamweaver, and how the lessening of support for the older IDE's.

Face it, we are very empassioned in our interest in Cold Fusion.

We all have things we love to do in coldfusion, that we like to do a certain way, and that really is natural and okay. Even if we sometimes disagree sometime.

For example, I am of the minority that use a text-editor, textpad instead of Dreamweaver of Home Site Studio. It really doesn't matter, and there should be no need to push our choices on others.

I started my path to Cold Fusion, working as a Tech Support for an ISP, being bored, so I worked my way up to Webmaster and Hostmaster. But even that did not challenge me enough, so I kept asking questions of the nice web gurus in the web department.

I had to teach myself, which has it's good and bad parts.

And I've done good coding and bad coding, but it's so hard to know what is the right way of doing things or the wrong thing, during my earlier times, because there was no training, no leading by example, other than the few articles of CFDJ.

But like many technical skills, it takes experience to shape us, and then as we learn more and more, we become driven to become better and better, learn new things, keep our minds challenged.

There really are so many interesting and exciting things we can do with Cold Fusion; from working with Flash, PDF's, CFC's, Webservices, UDF's and more.

And we must keep growing, and that growth can be both exciting and frightening at times.

I know there's part of me that likes the old non-gui, non-rich internet days, but we must move on and not backwards.

I guess that's what makes me a purist.

Thursday, June 02, 2005

Why are so many down on ColdFusion?

I've been reading Mark Kruger's post about Coldfusion and its undeserved Bad Rap - is it I?. While it's a great post, about why it's so easy to do ColdFusion wrong, we're still focusing on the wrong things.

The problem with coldfusion code, is not coldfusion's fault, it's the coders fault.

So let's stop putting the blame on the language, and more on the coders.

I'm not saying coldfusion is the language to solve every problem, but it has it's strengths and weaknesses like any other language.

But for 90% of most web applications, Coldfusion is one of the top 2 solutions for it.

Let's explain why ColdFusion is one of the top 2, and let's be realistic.

1. ColdFusion coders are much cheaper and faster than java/main frame coders, simply because it's a markup language, easy to use, but hard to master.

2. Now that ColdFusion is now a java application it is much more stable, than it ever was.

What was the slogan of ColdFusion when we just got started?

Rapid Application Development

So that means speedy development of applications, if we code it right.

So let's stop downplaying ColdFusion because it's not OO-enough, java enough, framework friendly enough, that is 1% of what ColdFusion was created for.

Rapid Development of Applications, using good and reasonable standards of coding. If a framework helps improve ease of coding, while not interfering with scalability and performance, than by all means use it.

Think about it from a client's end. Does it really matter if you use the latest standard? Only if it's a good standard that delivers scalible code.

I know I really repeat that point, because I don't feel like many people really get that. And instead of worrying about quality code delivering for high performance, they worry about the latest framework, oo/mvc, cfcs.

Let's talk about CFC's. First of all, I am glad they are a part of the ColdFusion language set, but they were only specificially designed for webservice usage, and instead we get tons of people using them for regular applications, when they're not an improvement in performance.

I know it's a cool way of coding applications, but SO WHAT?

What's more important? The coolness of the coding style, or delivering applications that don't crash the server? Or causes endless errors?

If CFC's are proven to be of at least equal performance as cfincludes, then I'll be happy to use them, until them, they are a waste of time and energy.

I remember, when I was working for a previous job, and an outsourced company was hired to create a checkout process, and instead of using normal coding methodology, they did it as a CFC.

Are they BLEEPING Serious? CFC's are specifically just for web service usage, and instead you wasted weeks and money which I'd eventually have to re-do, because it wasn't scalible.

And don't give me this crap, oh you haven't worked on an enterprise application, of course I have. Maybe it's not in huge teams, but I've been working with top national companie's, being the main coder, having to clean up everyone else's code.

You can call it my nickname, Mr. Clean. I am the one who has to clean up everyone else's code.

And I am sick and tired of everyone else caring more about using the latest gui, methodology or standard, than producing scalible, quality code.

I've been forced to clean up fusebox code too. Because we needed an application, like 100% of ours, had to be Search Engine Friendly, so we had to waste more time and money re-doing it, into a regular application.

I understand the need for a framework and methodology, and fusebox has brought a lot of good ideas, but really when you look at the app from a customer's point of view, it's really not user friendly.

And it's not really coder friendly.

Unless you are that group of people who are fuseboxers and only work on 1 part of an application.

I know i am of the rare ones, that work on a full application, and that has a lot of benefits.

I get a much better idea of what everything is supposed to do, I am a much more complete and thorough coder, than if i were a fusebox coder.

I do forms, html, tables, css, javascript, dhtml, sql statements, I do it all.

But I am tired of being angry, I just want more people to get a grasp of common sense.

Of course, since I am not flouting what the popular bloggers say, so more people will hate me, but that's my due I guess for being different.

Be well.

Long live ColdFusion!

OT: Just bought the NewsRadio DVD

When NewsRadio was on TV, I really enjoyed it. In a way it was a scope into the Dilbert -like culture of corporate jobs. It was a great, laughing experience, introducing us into a cast of great comic experience.

But it also had it's sad moments when Phil Hartmann, passed away.

But it shows us the natural good and bad times of job cultures, which is both amusing and sad at times.

I just saw the DVD at the Target, and I was just possessed to buy it.

For some of these type of shows, we tend to identify with certain characters.

I myself, tend to identify with Matthew or the Gilligan type.

Who do you identify with? What are you favorite TV Shows of all time?

Tuesday, May 31, 2005

Starting the process of experience delivery

I recentally talked about my own personal change from merely creating scalible applications, towards a new thinking, that of delivering a good experience.

It sounds rather simple, but in actuality, takes a lot of effort to learn a whole new approach.

Here are the steps, I have subtly followed, and now hope to work with others to find the best standard.

1. Identify your true end user

There may be some struggle to help to identify who your end user is. Sometimes your boss thinks they are, and sometimes it's the hidden end user.

So you have to really examine who will be using the application you create

2. Identify the goals/objectives of your end users

Now, this sounds so complex, but in reality, most people, depending on the demographics of your end users, will have very simple goals or objectives.

Let's be clear hear, in my mind there are two really great, not perfect, sites that deliver great experiences. and, and why are they still so great? Because both sites, make it easy to find what you are looking, and don't get in the way of what you are really after. Sounds simple doesn't it?

Let's show you how they do their magic. - Most people come there for either a specific product, or to browse, and is designed for either in mind. They occassionally have advertizing for new departments or promotions, and that can sometimes get annoying but most of the time, it's easy to use. - Sticks by a very simple interface, that focuses on you searching and even more importantly finding what you are looking for. They do not let, design get in the way of usability.

So, how do we carry this over to your own site?

I tend to generalize most sites into 2 types:

1. Ecommerce
2. Content

There may be more types, but they're not where the money is so far. I am not saying other types aren't important, but these are the main two types i know of, where there is a lot of confusion.

3. Avoding confusion between your/bosses goals and your end users goals

It's so easy to change the navigation, add new tools, or add more promos.

And this is behind the sad, bad mentality of the dot-com era, that new visitors will keep coming, and you don't have to do anything to get repeat customers.

So if you are in any doubt, look at how your competitors up and down the food chain, make it easy for the custoemrs to fulfill their goals.

And when you think your designing the site for your own needs, that's where you can really go down the tube, and you just have created a site no one would visit or use, other than yourself.

That's enough for now, more to come...Please share your own thoughts and ideas.

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 =
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)


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

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.


Friday, May 20, 2005

Adapting Your Framework

In the last couple of months, I have been doing a lot of thinking about frameworks. They certainly are very important, and each has it's strengths and weaknesses. But are we choosing our frameworks for the right reasons?

One of my favorite football coaches of all time, Bud Grant, wrote one time of adapting your strategies/tactics to match the strengths/weaknesses of your team. "Make the Playbook Fit the Players".

For example, if you have a lot of great running backs, you don't try to force your team to be a passing team, and vice versa.

Now how does this go towards picking a framework?

Because we can't simply pick one, and assume it will solve all our problems, because there are always changing factors to the team that helps to create/update/fix the applications.

Because a framework has two end-users, the coders who work with it, to hopefully churn out high quality applications, and the end users who use the applications, hoping for high usability, efficiency and scalability.

Each has a different need, so what we really need is an Adaptive Framework/Metholodogy that adapts as both ends change.

What things does an Adaptive Framework need?

1. Easy to read code - Each company should pick it's own style, but document that style.

A. Naming Conventions - for filenames, folders, variables, it has to be well documented and referenced to in each root application. So that 5-10 years from now, someone can come in and reasonably easily read your code.

B. Indenting - Adding to the elements that make code more easy to read. This takes a lot of time, to develop as a skill/discipline, but it pays off, in making the code much more easy to read.

C. Comments - No one is a mind reader, and as applications get more and more complicated, the need comes for more comments not less.

D. Documenting Applications - As your sites/applications get more comprehensive it really becomes important to document every aspect, so in if anything happens to you, someone can easily pick up from where you left.

2. Making applications easier for end users

A. Each application must be a seperate file name, instead of all applications coming to one file name. This makes it easier for bookmarking, and that makes it more likely to be visited again.

B. Search Engine Friendly - Take the long view, and prepare your applications for maximum popularity, meta-tags, description, keywords, page titles.

C. Usability - Making sure the end user can use the application, and that any need for help/guidance is made available.

D. Handling Errors - All applications sometimes have errors, either caused by the application or the user or some other fluke, but by being prepared for this, you present a more professional image to the customer.

3. Improve Ease of Coding in teams/solo - It is obvious now that each company has a different setup for who and how many people do application coding, so we must prepare and adapt our framework to each, so that we make it smooth and comfortable for both.

A. In dealing with teams, it's highly important to divide the work according to each persons's strengths, however that has a couple negative side-effects:

1. People will never learn or get the opportunity to learn/practice in their non-strengths
2. People will not get a whole overview of the applications they work on
3. People will get burned out, only working in their strengths

So we must adapt, and perhaps provide job rotation, different people changing what part of an application they will work on.

B. However working by yourself has it's own strengths/weaknesses. While you do tend to get a stronger understanding of the application as a whole, and do tend to explore all skill ranges, your doing it alone, and may not learn new ways of coding, and you may not get better without others to learn from, share and compete with.

C. Companies can no longer afford not to have a training plan, this can be cheap to expensive, but this industry needs to adapt to the technology, and instead of constantly hiring different people for different technologies, it's cheaper and gets better employer longevity by having a training plan.

Simply since most of us in our field are self-taught, as I am, training was never really available, in an official outlet.

So a training plan can be having 1 lunch a week, where a different coder/developer shares a technique; rotate sending developers to different conventions to pick up and enhance skill sets; sign up for local classes; encourage study groups for certification testing.

You hired a coder to do a job, but that job cosntantly changes, you already paid an investment into that employee, why waste that money by not providing training to make them more valuable to you. Most people I know would love to be trained rather than get some kind of IPO or other benefit like in the 1990's.

D. Project Management - This is a must, you must prevent wasting time and money on projects that are not clearly requested/planned. We've all been burned, so plan out every step of the project ahead of time, in written/typed however you like it.

E. Planning applications for scalability in the long term - How many of us want to keep re-writing the same application over and over? Not me. I'd rather get it right the first time. And this involves knowing when to use the right coding method for the application.

Well this is enough of a good starting point, so let me know what you think.

Thank you.

Tuesday, January 18, 2005

Overemphasis on OO and Modularity

As I have seen more and more in our industry, the call for modularity has surpassed the original intent. In far past, too many applications were to huge, hard to read, and were using similar code, that could have been re-used, and save some time.

There is a lot of common sense involved with code re-usability:

1. Making sure we don't waste time in writing the same codee
2. Making sure that long applications are broken up into more readable applications

But I feel we've finally gone way over the edge, by these simple but needed changes in how we code, way too far into OO-land.

I feel there are times when OO can be useful, but not when you are coding coldfusion applications 99% of the time.

Coldfusion is a very powerful language for creating web applications, but is most know for it's speed of concept to results, Rapid Application Development. So that means there has to be a logical path from a to b, and that's the end of the application.

We are getting invested into things that may be interesting but are inhibiting our speed of delivery.

Simply said, Object Orientation, requires thinking in non-logical ways, that make it hard to work with and hard to communicate about.

What happened to plain old english logic?

I felt this when I had taken my first java class, I could figure out how eventually to do whatever i wanted, but no one would talk in a logical manner.

If I wanted to X, what things do I need to do X. A Simple Question, but because of object orientation, there was no way to logically describe the problem and solution.

Object Orientaton sounds really fascinating, but experiences like really a waste of time.

I have no problem finding new ways to both improve the quality of the code, and improve the speed of delivery, but I have never believed OO was the path to do that.

I am sure there can be a more logical approach to working with Java, without having to use OO language.

I mean, I've worked in javascript, which has methods and objects, but I've had no problem doing what I needed to get done, because it's coders use logic.

This goes along with CFC as well. Which were originally meant to be used for web services only, which is fine. But now everyone wants to use them for non-webservice related projects?

Doesn't anyone have a clue how to code for scalability? It's interesting and new ways of doing things, but they are not always the best ways.

We have to use our common sense.

So what things can we do to improve coding quality?

Start with the basics:

1. Commenting
2. Code Readability including good indenting
3. Use a Project Management Process to avoid coding mistakes
4. Documentation
5. Learning from Mistakes

My Motto - "Doing it the right way the first time"

Understand how to code for best performance, and code as if each application will be serving millions of users consistantly.

Understand how to write the best sql statements to get the data you want, but write it for performance. Use stored procedures, dts packages, all the functionality to move cf scheduled events into the database, so the web server can just focus on serving pages.

There are so many ways that we fail every day to just do the core, and all of us are into whatever the current fad is.

If there are other ways to be better coders, I am sure eager to know. I do not assume I know it all. But I do try to know what works, and what is a waste of time.

Coldfusion is about speedily creating great applicationss, so are you?

Job Hunting: A fun and educating experience

As the trend in this economy has been of constant flux of jobs, it has taken some learning to know how to deal in this new economy.

I hope to share the lessons and skills I have learned in dealing with this, and I hope to hear other people's experiences as well..

First off, there is never enough sites to store your resume, the key I have found is to identify which sites, are the future employer's actually using themselves??

I use Monster, Dice, Yahoo Hotjobs, and Careerbuilder, most of all. They all have all key features that make them different and yet the same.

1. The daily search email can be very useful, to automate the process of finding a job, or finding an employer. But the hard part is to identify, what keywords to use. Such as do you use coldfusion or cold fusion, which do employers use, and what should you use.

2. Job Titles, ooooh aah. It's weird that each company may have it's own job title, that do different things. Such as a webmaster in 1 company may be the developer, but in other, just handles maintenance of the web site and handles emails. It's so unnecessarily confusing, especially when looking for jobs, what job title, best describes what your employer wants to hire you at?

3. Constantly revise your resume. I am never satisfied with descriptions of what I have done.

4. Documentation or Profiling of work, this is one of the hard areas to provide. All employers want it, but won't allow us to provide it. Because all code is usualy propietary, so how can we prove what we know? Well I actually discussed this with a recruiter who wasn't sure how to handle this, and my answer is testing sites or services, such as brainbench or other sites that you can get an account for, and use to test potential employees. What else can we do?

5. Dealng with recruiters, this has been the most difficult experience. Such as 25 recruiters asking you regarding the same exact job. Or recruiters posting job ads, but with no actual job, just so that they can get you in their database. Also every recruiter besides having recieved an email of our web-based resume, want a word one as well. And there is no easy way to convert it to word, and still look good and on 1 page. There has to be a better way to both meet the needs of the job searchers and employers to have all the information they absolutely have to have...

It's just frustrating sometimes dealing with all the barriers to a job. After all we have similar goals, I want a job, they want to hire someone, so how can we meet in the middle and work out these problems.

Part of this has to deal with the experiences we had during and after the dot-com bomb. Companies can not simply exist without clear ways to earn and keep money.

We need to be paying people meritiously...and re-think how promotion and demotion works.

Good luck to everyone who is looking and hiring...