• The Worth of Learning a Language Just for Fun

    I really enjoy learning new programming languages. Actually, I love learning new programming languages. I always have something in my mind that I want to learn. Some things I just want to tinker with a bit and others I want to have a deep understanding of.

    Two languages I’ve been trying out recently are Scala and Flex. Both are very enjoyable languages to use. I’m running into a bit of a problem though. How do I find the motivation to really learn these languages and is it worth it? In the past, I’ve usually just learned languages because I’ve had to for my job. But this time it is just for fun. Sure, someday in the future I might want to get a job using one of these languages but not yet. I just find them to be fascinating languages.

    So the question is this: If I am just learning these for fun, should I invest the time to have a deep understanding of it or just a superficial understanding? Will it benefit me that much? If so, how do I motivate myself to learn it? If one day I want to get a job using either of these languages then how do I get the work experience an employer would be looking for?

    Whatever I do, it is critical for myself and every other programmer to continue learning. Whether that comes from thoroughly learning a single new language, superficially learning a multiple languages, reading books, or simply trying new things in your language of choice, it is vital for our continual improvement.

  • The Cost of Quick and Dirty Programming: Technical Debt

    Why do programmers always make such a big deal about best practices, proper object oriented design, unit testing, and the like? Chances are if you ask somebody who champions these ideas they’ll respond “it makes for higher quality software” or something along those lines. They are probably right about saying it makes for better software. Ideas such as these won’t produce “perfect software” but they definitely improve the chances of better software with easier maintenance.

    I am one of those programmers that believes that unit testing, thoroughly thought out OO design, best practices, etc. contribute to better software. But unfortunately, taking these actions does not come for free. They all take time and energy which translates into money.

    Unit testing is a great example. Writing tests for code can definitely add more time to a project. Possibly quite a bit more time. Many people, myself included, often just ignore testing and just wait for bugs to pop up before they are fixed. It is at times very difficult to find the motivation to write the unit tests and do what I know I should be doing.

    But this view is very short sighted.

    Writing unit tests, while time consuming up front, can dramatically save time, money, and energy later in a project. The reason is because they enable you to find bugs earlier when they are easier to fix which means time and money saved later. It is far easier to fix a bug early in a project soon after it is introduced than when it has been in the system for months and covered but by other layers of code.

    A concept that paints a good picture of the consequences for this quick and dirty approach is called technical debt. The idea of technical debt is related to commonly understood financial debt. It is best explained by Martin Fowler in his post on this metaphor.

    In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

    Doing things quick and dirty, as us programmers often do, has consequences that we frequently ignore or thoroughly take the time to understand. Not writing unit tests or ignoring problematic software designs creates debt that can be difficult to pay down later. Allowing excessive technical debt without reason is a quick way to heavily burden a software project. It has happened to me just as I’m sure it has happened to you.

    But technical debt can sometimes be an OK thing. Sometimes software just needs to get done ASAP or sometimes it is a rarely used or temporary piece of software. In circumstances like this I believe it is ok to take on a certain amount of technical debt.

    This is something I need to remember. Software doesn’t always need to be perfect (if it even can be that). Sometimes it is far more important to just get it done. It often is very tempting to analyze and analyze and analyze in an effort to get that perfect piece of software but never actually get anything programmed. By keeping this metaphor in mind I will hopefully think through how I approach software in the future and think through the consequences of the actions I take.

    Additionally, I like the metaphor of technical debt as a way of working with non-technical users to explain the the time is needed to “do it right” the first time or to pay down the debt accumulated in other phases of the project. Most people have some kind of financial debt so this concept seems like an easy concept for people to understand.

    It also seems useful in explaining to other programmers who may be hesitant to embrace new methodologies and practices. In my work in ColdFusion, I’ve often found other programmers wondering why go through all the work some best practices like unit testing. They think it is too much work and don’t bother. But using this metaphor seems like an effective way to demonstrate the fallacy with that thought process.

    In short, before you program something, take the time to consider technical debt and whether you want to avoid it or accept some in the short term. I plan to do so and hope it will lead me to better think through my actions and consequences in the software I write

  • Monitoring a Form for Changes with jQuery

    JQuery constantly amazes me. Its ability to simplify tasks that ordinarily would have been complicated is truly wonderful. Today I found myself amazed at jQuery’s power yet again.

    First a little background. My coworker had been working on a project which required her to notify users if they were leaving a page with unsaved changes in a form. When she asked me if I had any ideas I researched online to see if anybody else had a solution.

    What I found were some pretty great ideas that allowed me to come up with a solution that is pretty darn cool. The solution uses jQuery’s “:input” selector, “each” function, and “data” function to loop through every form field and store whatever the initial value is. Then it uses “window.onbeforeunload” to check the form before user leaves. The code loops back through all the form fields and checks if the current value is different from the initial value. If so, it notifies the user and give them a chance to stay on the page and save.

    Here is the code.

    $(':input').each(function() {
        $(this).data('initialValue', $(this).val());
    window.onbeforeunload = function(){
        var msg = 'You haven\'t saved your changes.';
        var isDirty = false;
        $(':input').each(function () {
            if($(this).data('initialValue') != $(this).val()){
                isDirty = true;
        if(isDirty == true){
            return msg;

    Let me break this down a bit.

    The first part of this code finds all form fields: $(':input'). It finds all inputs, textareas, selects, etc. jQuery returns all found elements as an array which I then loop through with the “each” function.

    The next line takes each element in the array and stores a variable called initialValue containing the current value of the form field (remember, the array is a collection of all found form fields on the page) and associates it with that form field. If the “data” method doesn’t make much sense, the jQuery Docs can probably explain it a bit better.

    Next, the function set to the window.onbeforeunload event is run whenever the user tries to leave the page. When run, it once again finds all form elements and compares all current values to the initial values saved earlier. If some changes have occurred, it returns a message to the user.

    One limitation I know of is if new form elements are added to the page after it loads and the initial values of the fields are stored. That could probably be easily remedied but it is just something I haven’t yet done.

    Overall this is a very useful piece of code and is a beautiful example of what can be done with jQuery. I look forward to using this in future projects. As a reference, here are two websites that provided some very useful information about this: CFSilence and My Dog Boris.