So for the last couple weeks, I've been spending a little time on weekends working on a personal project. Honestly, it's as much to teach me new things as it is to teach me new features of CF9 as it is to actually accomplish anything.

I'll tell you more about it when there is more done on it. Which, given my recent increase in free time, should be sooner than planned, which is why I mentioned it at all.

But I'm not writing about my project. I'm discovering the joys of writing components in pure CFScript.

The reason I've always found CF great for writing web programs (and not so great for other things) was because the tag structure fits so nicely into the nested structure of HTML, and (forgive the imprecision) feels right to me. However, for the M and C in MVC, it's always been .... mediocre ... in my opinion. Don't get me wrong, I love it, but having to write tags out, even if you keep most of the system in CFScript blocks, could get painful.

So, I'm loving the new all-script stuff. Queries in script? Check. Includes in script? Check (although I'm not crazy about the syntax). Mail. Check.

I know this probably isn't a revelation for a great many of you who are working on new systems, but I've been elbow-deep in legacy code, and being able to write objects and controller code all in script is a revelation. Nah, that's too strong a word. But it is nifty.

Recently, the operation I work for had the misfortune of having several outages (three in a week) at our primary hosting platform. We have therefore lost a handful of clients, including one of the 5 biggest. Falling revenues mean I've been downsized.

Anyone need a ColdFusion programmer?

The thing about passwords is that I don't actually want to store them. if I store them, they can be retrieved, and that is a security hole. What if (like most of the world) a user reuses a password? Now it's out in the world.

A better answer is to hash them. If you aren't familiar, a hash function is a mathematical function that takes an input and mangles it in a specific, repeatable, impossible-to-reverse manner. Knowing the result of the hash function does not give you the original input, and there's not an easy way to reverse the process.

However, there is a known attack for this called a rainbow table. Basically, you find an input for the hash function that generates each possible result. This takes a lot of time, but you only have to do it once. Realistically, if you know how to use Google, you don't have to do it at all -- tables are out there on the web. Now, if you know the hash value and the hash function (there are only a few commonly used), you can find a string that generates it, even if that string isn't the password proper. If only the password is hashed, there's a way to defeat this.

There is an easy fix, though. You need two pieces of information. Conveniently, there are almost always two pieces of information in a login: the username and password. We assume we can safely store the username -- it's not a secret. Now, instead of looking up the username and matching hash(password), we look up the username and matching hash(username + password). Now, in order to defeat the combination, they don't just need a password that generates the hash. They need a password that, when combined with the username, generates that hash. This is much, much, much harder.

I love automation. It does things for me, so I don't have to remember. And it takes care of tedious tasks. And it handles boring things so I can focus on what matters.

Until it breaks.

Then, I hate automation. How do you make sure your alarm clock will go off at exactly 6:00 am without waiting for the hour to roll around? Change the time? But then you're not sure it got changed back exactly right. Change the alarm? Same problem. So you can test, at most, once per day.

Can you tell I'm having automation issues today?

There is a balancing act that I'm not sure how to do.

People want new functionality. New abilities, a new look, the new shiny. To an extent, as developers, we owe it to our audience to provide this. This is what we pay for attention. This is how we keep our application from getting stale, from being cloned (only better), and how we earn our daily bread.

As developers, sometimes we reach a point where we feel we need to rewrite some of the underlayers in order to support more functionality. This is how we keep code mainatainable, how we add scalability, and how we make sure we can keep adding functionality.

The problem comes when the two are out of balance. And I don't know how to solve that. I see the problem from one perspective: We need good underlying code to be able to scale and to add features and to give people the new shiny. I feel like without this, we're burning time and effort on things that should be easy.

But I'm not in charge. The people in charge understand this to a point, but often, I feel like they don't understand the problem until it becomes critical, and then they just want quick fixes. But, then, as I've pointed out, I'm biased. I think they they are too fixated on the new shiny, and allow the code to rust underneath.

Now, let me be clear. This is not a condemnation of my current employer. This is not a condemnation of my past employers. This is a trend I see everywhere. As a programmer now, I'm under the gun to deliver new functionality. As a consultant, we would slap a new coat of paint on older software that was perhaps not the ideal solution for the client. When I worked retail, the stock room and overstock were the last things cleaned and organized, until we couldn't find any more USB cables. Then cleaning was critical.

So how, as developers, do we strike the balance between new and improved? In my current position, I'm trying to combine the two, and improve where I'm creating new. But this doesn't fix core code that isn't touched often. So what is the real solution?

No, seriously, folks. If you have an answer, leave it in the comments. I really want to know.

Apparently, it's Ada Lovelace day. If you don't know who she is, she was one of the first programmers, working on Babbage's Analytical Engine. Of course, he never finished building it, so debugging was tricky, but that's hardly her fault.

Today is supposed to be a big deal because, according to the note that told me to observe this, we tend to overlook the accomplishments of female techs and engineers. But instead of writing about old Ada, I'm going to mention some people I've worked with.

As recently as this morning, I worked with Sherri. She trouleshot a network problem preventing access to our test server. Sherri, I appreciate you getting up early to fix a problem that had people calling me at 7 this morning.

Carmella was, for a while, not the best programmer on our staff. Looking back at our programming staff, that's like being a relief pitcher at the All-Star Game. She's moved on, and I imagine she's one of the est where she works now.

At my previous job, I worked with Bev. Bev is old enough to be my mother in an industry that favors young men. She was also experienced enough to regularly school me on any number of topics. In her particular specialty, she (literally) wrote the book, and having a specialty did not stop her from being very good at other things.

I did college work-study in an IT department that was staffed with more women than men, which is an unusual experience, I'm told. It didn't seem that different to me. Working with women is, in my experience, much like working with men. Is this because women in tech are self-selected to be like men, or because techies as a group are similarly self-selected?

Anyway, we're supposed to share our thoughts on women in tech, or something, but I don't really have much to say. I like working with techs and gearheads. Plus, the female ones tend to be prettier.

I realized the other night that no one else cares whether a problem is a bug or not.

Let me be clear, I'd seen evidence of this, and understood intellectually that they didn't get why it matters. The other night, I realized that it never will matter to them.

I'm a professional programmer. I deal in algorithms and data. I classify everything. Classifications are important in my world. The classification of a problem is important to me on a gut level, as well as having an important function in this case.

So, to all you non-programmers, listen closely. Programmers, remember this idea.

A bug is when the system does not work as it is intended. If there is a bug, we need to fix the code, so the program works as it is designed to. When the design is bad, it is not a bug. It is a design flaw. If we treat design flaws like bugs, you end up with a program that does the wrong thing perfectly. When the problem is not a bug, we have to re-design the program (or a portion thereof) or you don't get what you want.

Design flaws and bugs are fundamentally different, and we should treat them as such.

There are two ways to fix a problem of inefficiency.

The first, and simplest, is to beat it into the ground with money and hardware.

The second is to fix the inefficiency.

Right now, I'm having a lesson in why the first does not work. We wanted to speed up the site. For business reasons, no one wanted to allocate time to address the problems inherent in a four-year-old system that was originally designed by someone who was relatively new to the language. So, we put the system on two web servers behind a load balancer. There were a few wrinkles, but we were ironing them out one at a time, until we hit a snag. The balancer (which is shared, so we can't reconfigure) has a timeout of 30 minutes. For reasons I won't go into here, we need a minimum of 40 (and a little more for security).

So, now, we either have to address the inefficiency in such a way that we can produce a division of labor (my suggestion) or apply a quick fix that will regenerate sessions if they are routed to the wrong server.

This frustrates me. The whole reason that the higher-ups (I was not part of the decision) went with a load-balancer was to avoid doing work. Now we have to do work to support the load balancer, and it's not even going to fix the original problem.

I just want my site to be well-structured, efficient, and maintainable. Right now, it is none of those. And it stinks.

Time to update my blog code. Time to find out how easy it is!

Edit: Easily enough, if you remember to back up your config files and CSS changes. I did not. Fortunately, I had backups anyway. Yay, good habits. Boo, not planning ahead.