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.

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.

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.

Favicon, done. Colors picked, done. StackOverflow flair, done. Layout tweaked, done.

I forgot how fun it can be to muck around with this stuff.