joshclarkson.net

Just write. That’s what the blog post told me to do to get better at writing so that’s what I’m doing. I’m writing whatever comes into my head and I’m giving myself permission to fail. Permission to write junk that won’t be useful for anything but fodder for the delete button. I keep reminding myself I don’t want to be that guy who lets his blog go stale. I started this site to have an outlet and to share in a creative way my thoughts and musings as well as technical know-how.

So here goes. I recently worked on a regular expression to eliminate certain order lines in a label creation program and I thought I’d share it with you. I wanted to eliminate labels where the description was like:

"DOOR ! SOME COMMENT HERE ! "

So I came up with this regular expression to match against these comments and get rid of them.

"/^DOOR[\s]+[!]{1}[^!]*[!]{1}[\s]+$/"

I will break this one down so you can see what it does.
The “/” and “/” surrounding the pattern are what is known as the pattern delimiters, they specify the beginning and end of the pattern. The “^” at the beginning and the “$” at the end are known as anchors, they specify that what is found in the expression must be found starting with the first character in the subject text and ending with the last character of the subject text respectively.
The beginning of the pattern “DOOR[\s]+” indicates I want to find the word “DOOR” followed by one or more whitespace characters (spaces). The “\s” within brackets is shorthand for whitespace characters and captures also newlines. The “+” is the regex element that indicates that we’re looking for “one or more” of the preceding pattern.
The exclamation point inside the square brackets continues the pattern I’m looking to match and the number one inside curly braces indicates the number of them I want to find. So “[!]{1}” means find exactly one exclamation point.
Next the sub-expression “[^!]*” indicates any characters that are not an exclamation point (The caret inside of square brackets matches everything that is NOT the following characters) and “*” is a wildcard character meaning “matches zero or more times” so that “[^!]” means we must have an indeterminate number of non-exclamation point characters following the one exclamation point. Then following that there is another “[!]{1}” for that latter exclamation point, and another [\s]+ for one or more whitespace characters at the end of the subject text.
So that attempting to read this regular expression in English would give you something like this:

At the beginning of our subject text (^) look for the word DOOR (DOOR) followed by whitespace characters ([\s]) of which there will be one or more (+), followed by an exclamation point ([!]), just one! ({1}) followed by a non exclamation point character ([^!]) zero or more times (*), followed by an exclamation point ([!]), just one! ({1}), followed by a whitespace character ([\s]), one or more of them (+), up to the end of the subject text ($).

The tedious tasks are not always the low hanging fruit. The reason tedious tasks persist is that the water is muddy. Our vision is blurry. Our view is cloudy. However the underlying truths in solving all tasks still remain. Namely that seeing the real problems, finding discreet steps, exploring unconventional options, and persistence in breaking your own mental barriers is required.

Many problems that you will face in trying to bring efficiency to the world through web technologies will be issues of vision. That old proverb: “Where there is no vision, the people perish” holds truth for our everyday lives. If you do not take the time to see the problem, no matter how hard you try to spin your wheels, the result is epic fail.

I’m reminded of a story I read about Taiichi Ohno, the famous Toyota exec, where he would draw a circle on the shop floor and ask his employees to stand in the circle and watch the process for hours with an eye for improvement. When was the last time you watched a user of your applications in the wild? Just sit and watch them use it. Take more time than you normally would to observe each action. Try not to interfere — just observe. Catch a vision of the frustrations, the problems, the effects of the application in it’s current state. Before you even start thinking about solutions, make sure you fully understand the problem.

How many horrible UI implementations were because some designer didn’t ask if his improvement would be beneficial to a process, but just added it because it was another bell or whistle? For all your work you could be making things worse! Now once you have sufficiently observed (and have you really?). Let’s think about solving problems.

Another key to tedium-busting programming is the ability to find workable discreet steps. A summary of the problem you are trying to solve that is divided into actionable steps. If you cannot act, you are paralyzed. When you eat a steak you cannot merely absorb the entire steak, but must first cut the steak into manageable bite-sized pieces that may then be chewed and swallowed. Follow the old adage; “Don’t bite off more than you can chew”. If you wish to accomplish great things with your programs you must continually divide your work into bite-sized pieces. Segments that are within your ability. Actions like: “search google”, call a friend”, “read some of my old code”, “write a unit test”, “solve this error message”, etc., are the kind of pieces of work you need to isolate.

Exploring the unconventional approaches are how great leaps forward are found, and where in programming your creative side may be unleashed. When I say to explore these ideas I mean an inner mental exploration as well as a physical fleshed out exploration. Imagine your fantasy solution, how it would work, how it would behave. And the ways in which the world might be changed forever by your unique approach to a problem. I find using a whiteboard and running my ideas past the Rubber Ducky are great ways to reflect on these ideas when you are working solo.

With all of this we still tend to get bound up in the old ways we’ve always done things. The status quo gets us, especially when the direction that is necessary to take can be much more difficult. That’s why sometimes breaking your own rules about how you work, in a deep and meaningful way, is the only way to have a breakthrough. Do you always write things out on a legal pad while you’re sitting at your desk? Take it outside. Get a big sheet of butcher paper. Do you ever just write some throwaway code that no one will ever see? Are you caught up in syntax? Whip up some pseudo-code. Breaking your own rules can be an excellent way to say “NO!” to mediocrity.

I’ll finish this by exhorting you to challenge your own willingness to innovate. Is it enough?

This post will show you how to get checkbox values with jQuery and how to set checkbox values with jQuery.

In my application I wanted to have two checkboxes and when one box was unchecked to check the other checkbox (to always keep one check box checked) But I didn’t want to use radio buttons. I also wanted to tie an ajax call to the checking of a checkbox. Here is how I used jQuery to accentuate the behavior of the checkboxes.

Here is my HTML:

<label for=open>open: </label><input class="switch" name="open" type="checkbox" checked>
<label for=closed>closed: </label><input class="switch" name="closed" type="checkbox" >

Here’s the segment of jQuery used to get and set the checkboxes:

$('input:checkbox').live("change", function() {
        $("#display").html('Loading...<br><br><img src="images/small_wait.gif" style="border:none;">');
        if($(this).attr("checked") === true) {
                //uncheck this checkbox
                $(this).find("checkbox").removeAttr("checked");
        } else {
                //check this checkbox
                $(this).find("checkbox").attr("checked","checked");
                if($('input:checkbox').not($(this)).attr("checked") == false) {
                        $('input:checkbox').not($(this)).attr("checked","checked");
                }
        }
        if($(this).attr("name") == "open") {
                //get status of open and closed checkboxes
                var open = $(this).attr("checked");
                var closed = $(this).next().next().attr("checked");
        } else {
                //get status of open and closed checkboxes
                var closed = $(this).attr("checked");
                var open = $(this).prev().prev().attr("checked");
        }
        //Do AJAX query and response....
        //now do a post of open and closed vars
	var url = "ajaxcallurl.php"
	$.post(url, {open: open, closed: closed}, function(response) {
		//apply response to the display
		$("#display").html(response);
	});
        return false; //don't perform standard checkbox function
});

By returning false you effectively commandeer the change of checkbox and disallow it while replacing it with your more intelligent function. And by using prev() and next() a couple times you can refer to the other checkbox easily. I covered in a question on StackOverflow how to post an array of multiple checkboxes if you are using more of them.

As I write this, I’m in a 737 flying over the Rocky mountains on my way home from a long week in Denver, Colorado. When you think about all the infrastructure that is in place to facilitate a flight from one US city to another it boggles the mind. Not just software and hardware; but people, places, processes, and protocols. With all those puzzle pieces a person and their belongings can be safely (and magically) transported. (I’m hoping :)

All those balls in the air makes me think of the conglomeration of technologies that make up the web services I’ve built and how they are working together to synergistically create an experience and a working model of something much bigger than it’s parts.

Nowadays when a person looks at a website they rarely see a collection of pages but most websites have become their own platform and environment for the user. The advent of Ajax and frameworks like jQuery, have made a consistent look and feel with consistent user controls a must have for any (aspiring) mainstream site.

To extend my (overextended) flying analogy, certain plane manufacturers and boarding methods for example have become the default choice for all airlines. This is generally a good thing. We want our planes to be Boeing and our airports to have rolling sidewalks. (Those are awesome by the way; “Look at me! I’m walking and I’m not moving my legs!”).

However along the way it seems we’ve laid aside some important considerations on the merits of a completely unobtrusive (read “it doesn’t get in my way”), user interface.

Remember standard hyperlinks? Why do away with a method that has worked for years just because you can slap an id an on element and a write up a jQuery function? We need to at least with temerity consider not breaking a time tested model.

Remember documentation that was simple text pages hyperlinked together? An amazing tool still today which many have abandoned.

If you’ve created an exclusive club that requires an up to the minute javascript interpreter, at least bother to preserve the use of the old fashioned back button.

It so easy to ignore all the technologies that, when built upon, gave us our new shiny toys. However it takes much more effort to see the important parts of those base UI features that would be catastrophic (in a “your new app sucks” kind of way) to leave behind.