buckyschwarz.net

Well, CFinNC is over, and from the accounts we’ve seen so far, it didn’t just rock, it Rocked the Casbah!

It was the first conference I’ve ever been to; I have to say, I can definitely see what all the fuss is about. I’ve already started following several new and interesting people on the twitter. I met so many cool and smart and nice people this weekend, and just got a chance to talk with people who want to share what they know. Even being part of the event staff, I got to see plenty of really good talks, and I learned so much.

Before last weekend, I was pretty dismal. I wasn’t really excited about web development anymore, in my mind, ColdFusion was a dead, bloated, washed up corpse of a former lover, being pecked at by sea gulls, and Flex was about as far from my mind as it could be. This conference completely re-energized me and gave me a new sense of motivation and a fresh new batch of ideas to go explore. It could not have come at a better time. I feel so excited and motivated about working with ColdFusion and Flex again.

And that is just about attending the conference. It was pretty awesome being able to work with really great people, especially the two really cool guys who shouldered a large portion of the responsibility. I can’t believe we actually did it. I can still remember our user group meeting back in the spring when Dan said he wanted to put on a conference. Nothing major, just a one day affair for locals of the Triangle Area, maybe people from Charlotte or even Asheville. Somehow, over the course of a summer it turned into a full-fledged, free, two day, international event with people coming from New York, California and Canada and a full list of well-known speakers. We kind of just did it as we went along, and some it was really done by the seat of our pants, but due to the hard work and determination of everyone involved, it turned out pretty okeydokey.

I think most of the people involved feel the same way: Last night, we had our debriefing/postmortem of the conference, at the beginning of the meeting, we cautiously approached the subject with the attitude of we may do this again next year, but let’s not commit. By the end of the meeting, when asked who would want to do it again, everyone in the room raised their hands. So without letting too much more out of the bag, it looks like there will definitely be another CFinNC conference next year and I’ll be  happy to work to make it better than this year’s.

Should links open in new windows?

Smashing Magazine answered that question succinctly and correctly (back in July of 2008, I might add): No. They shouldn’t. It’s as simple as that*. You should let your uses decide how to handle their links. When you force users to open a link in a new window against their will, it destroys their web experience for a few reasons:

• It removes control from the user in favor of control of the developer, and users should always be in control of their experience
• It forces the user to use the site in a way you’re dictating, which is usually not the way the user wants to use the site
• It removes use of the back button, an integral part of the web experience, even today with all of our AJAXy goodness
• To novice users, it’s confusing: where did my back button go, what just happened?
• To experienced users, it’s downright enraging: thank you, I know how to open links in a new tab or window, I don’t need your help telling me how to browse the web. In fact, I’m going to close your stupid site right now, just to spite you and your stupid ideas.
  
• It doesn’t do what it’s supposed to (keep users on your site): If a user wants to leave, opening a link in a new window won’t get them to stay. Giving them what they want (good content, good user experience) will, however.
• It destroys the very thin veneer that we’re in control of at least something in our existence, often leading to very severe existential crises in which a person’s entire reality might be shattered, leading to unintended consequences including but not limited to: psychosis, rage, murderous rampages, and losing touch with reality

*Of course, there are caveats. I would say that you should force the link to open in a new window or tab only when opening the link in the current window will interrupt the flow of the user experience. What does that even mean? I don’t know. Nah, but seriously, for example: let’s say a user is using your site to buy a vintage harpsichord, and he’s on the last step of the buying process: checking out. He’s found the perfect harpsichord to put in his basement, he’s entered his shipping and payment information, but he has a question about shipping. So he clicks the link that looks like it can answer his questions, and he’s taken away from his shopping cart. Crap, he’s thinking, now what? Do I have to re enter all my information? Do I have to start the whole process over? This is a perfect opportunity to open the link in a new, small window positioned right next to the link.

Smashing and webcredible provide a good cross section of times when you should open links in a new window:

• The link provides assistance, as in the example above
• The link will interrupt an ongoing process, again, see example above
• The link leads to a non-html document, like a PDF, mp3, or movie file
• The link leads to content that will take a long time to load, like a large image, or javascript heavy web page
• The link leads to a printable version of the current web page, although this can be mitigated by using a print stylesheet

Keep in mind however, that even if you do have a situation where it is appropriate to open a link in a new window, you should always inform the user that the link opens in a new window, either via the title attribute of the anchor element, or by specifying in the link text that the link opens in a new window. Similarly, if you’re in a situation where you’re forced to open links in a new window, like say if you work under someone who is convinced he is a usability expert and also makes the decisions and one of those decisions is deciding that all outgoing links will open in a new window, you should try as hard as you can to inform the users that their usability experience is about to be disrupted.

Remember: it’s not 1999, web usability has grown by leaps and bounds over the past decade, and one of the things we’ve learned is that you should trust the user to be in control of their user experience.

I’m a bit mad with myself. I’ve been using the Syntax Highlighter Evolved plugin on my WordPress blog to highlight my code. Well, I would have been using it to highlight my code if it had been working as advertised. There wasn’t any kind of highlighting happening – the code inside the generated pre tags looked the same as the rest of the text on the page.

I’ve hacked together my own WordPress template for fun and posterity to integrate into my site. See, I’m a pretty big newbie to all of this, and it didn’t help that the /blog directory under my main site actually pulls from a separate blog directory one level up (don’t ask me why I did this, I was probably drunk – in hindsight it’s pretty obviously boneheaded). Regardless, I had a suspicion that this had something to do with why the syntax highlighting wasn’t working. I did searches and couldn’t really turn up many good results. It seemed pretty obvious that most people with normal working blogs weren’t having issues.

I ended up looking at the plugin code in the WordPress plugins editor to see if there was something obvious causing it. I spent about 15 minutes looking through it when I figured that there was some kind of issue resolving the directory/URL structure between where the blog was being included and where it was actually located. I found the following code:

// Initalize the plugin by registering the hooks
 function __construct() {
 // Check WordPress version
 if ( !function_exists( 'plugins_url' ) ) return;

 // Load localization domain
 load_plugin_textdomain( 'syntaxhighlighter', false, '/syntaxhighlighter/localization' );

 // Register brush scripts
 wp_register_script( 'syntaxhighlighter-core',             plugins_url('syntaxhighlighter/syntaxhighlighter/scripts/shCore.js'),            array(),                         $this->agshver );
 wp_register_script( 'syntaxhighlighter-brush-as3',        plugins_url('syntaxhighlighter/syntaxhighlighter/scripts/shBrushAS3.js'),        array('syntaxhighlighter-core'), $this->agshver );

I figured it had something to do with the function

plugins_url()

not returning the correct location of the plugins directory where Syntax Highlighter is located. I figured it couldn’t resolve the location of the plugins directory and therefore couldn’t find the JavaScripts that color the code. I spent about an hour tooling around with

plugins_url()

trying to get it to work in various ways and permutations, all to no avail.

I was starting to get frustrated when I noticed, for the first time, right next to the code editor a list of plugin files to edit. One of them was titled ReadMe.txt. “What the hell,” I figured, it can’t hurt to take a look at it. I scrolled down about half way until I saw a FAQ. Right there, in the middle of the page, like a veritable bullhorn shouting, “You freaking moron!!!” at me, was my solution.

The code is just being displayed raw. It isn’t being converted into a code box or anything. What’s wrong?

The answer, of course, was to call the

wp_footer()

function in the blog’s footer. Man, did I feel like a jackass. Here I was, making things difficult, wearing my Big Boy Coder’s™ pants, trying to hack up functions and make things more complicated than they are, when all I had to do was RTFM like the noob that I am and find the function to include.

So naturally, the first thing I had to do (after fixing it) was write a post about it rife with Syntax Highlighting. Thanks, Alex Gorbatchev.

Given that I was laid off in October 2008, and that kind of experience is surprisingly relevant in today’s economy, a friend and former co-worker from college, Willie Jackson, asked me to write a guest blog post over at his site. It’s titled Why losing your job is not the end of the world and what to do if it happens: An essay on the interoperable relationship between business and fear, in particular as it relates to the current world economy, especially having to do with the prospect of losing one’s job vis-á-vis layoff. Head on over there and let him know what you think.

At work, I’ve been working with a user who needs a few certain pages on the site I’m developing to be printer friendly. These pages are usually ones that display data in tables with a dark blue/light blue zebra stripes. All the pages of the application (these table pages included) have a two-column fluid layout with the site navigation occupying the left column. Obviously, for printing tabular data, the navigation need not be displayed, nor do any kind of form controls that might be used for searching for particular data in that table, so obviously, those should be disabled in the print stylesheet.

So, for the first time ever, I wrote up a stylesheet with the media type set to print. I’ve just never needed to print anything from a website before. So I wrote up a stylesheet with the media type set to print. I just set the display properties of elements I didn’t want to show to none and went about testing it. During testing, I kept running into a problem where the left column, which should have been hidden, would still be causing the center content column to float right. The navigation menu wouldn’t be there, but the container the navigation menu lived in was still there, even though its border and content were hidden. This stumped me for a good day and a half, and after hitting my head against my cubicle wall I finally decided to try setting the media type of the main stylesheet of the app to screen. This solved every problem I had and now the tables are printing beautifully.

The moral of the story: Always set the media types of your stylesheets. It’s a good idea and a good way to add semantic meaning to your header files, and also, all the cool kids are doing it these days.

I’ve finished the second redesign of my site. After using jQuery extensively while preparing a presentation for my local ColdFusion usergroup, I decided that I wanted to redo my site with more jQuery. I initially wrote it using PHP, styled it, and published it, but quickly grew tired of the dark scheme. I’ve restyled it now with a lighter theme, which I’m pretty pleased with. I’ve also gotten my WordPress custom theme pages working correctly, and it was surprisingly easy.

So that’s about it.

I ran into an issue with Safari and jQuery 1.3 today that had me stumped. To keep things unobtrusive for the folks on the web who don’t have JavaScript enabled (and to keep current with good practices since no one except my girlfriend visits my site), I had a form which wasn’t needed if JavaScript was disabled hidden using the display: none property in the site’s main stylesheet. In the $(document).ready() handler for jQuery, I set the form to be visible using the show() method (which, to my understanding, set the display: property to block).

This worked fine every time in Firefox 3 and IE7, but in Safari, I noticed some strange behavior: Occasionally it would work like expected, but most of the time the form would stay hidden. It seemed the only times it did work were when the actual page load took longer to load than the stylesheets and scripts.

The following image shows the Safari Web Inspector when the strange behavior was occurring:

This image shows the Web Inspector when the normal behavior was occurring:

In all of the cases where the page behaved as expected, the page would finish loading after the stylesheets and scripts. I’m not really sure what this means, but it seemed like when the strange behavior was happening, the page would load, jQuery would show the form, and then the stylesheet would load and hide the form. I spent several hours searching for an answer to no avail.

The fix came when I changed the jQuery code. Instead of using the show() method, I used the css() method to change the css property, display: block. This fixed the problem in Safari, and did not introduce any strange behaviors in Firefox or IE7.

Well, I’m finally starting to get settled in to my new place in Cary, NC. I’ve been here for a few days now, and so far, I really like it. The weather has been nice and cool: in the 40’s and 50’s during the day, and the 20’s and 30’s at night. It rained and misted all day today. It’s weird; I’m not used to it being rainy and cold, I rather like it.

After two days, I want to say that my new job is fantastic, thanks for asking. I’ve signed on to be a ColdFusion developer with SRA International in Durham. Again, today was only my second day, but the first two were great. Yesterday was an orientation that was presented via a teleconference call with people across the country. Today was my first real day. I have to say, I’m very impressed with how organized and employee-oriented the company is. I have a nice sized cubicle that will have a name plate on the outside wall. Inside my cubicle today was a Dell PC with a dual LCD setup, which I thought was pretty cool. Also inside my cube were a stapler, a tape dispenser, a staple remover, a magnetized paper clip holder, paper clips, staples, and tape, two pads of paper, two pens, two pencils, two stacks of post it notes a telephone directory and instructions on how to use the phone. All of the office supplies were brand new in boxes. It was incredible, and also a little exciting to see the company that hired me putting in just a little bit of effort to show that I’m welcomed. That little bit went a very long way. It’s quite exciting to be working for a company that has their act together and tries to let their employees know how they feel about them.

I’ve made some changes to my site: I redesigned (read: designed) it with a new layout, changed the default behavior so going to buckyschwarz.net doesn’t take you to the blog, and played around with Wordpress layouts to integrate blog posts directly into the site, viewable by going to the blog navigation header tab.

All of this was done because 1) I had a lot of free time, not having a job, 2) I was bored, and 3) I wanted to refine my PHP skills and increase my knowledge and skill with the language. It’s a work in progress, as always, but so far, I’m pretty happy with the results. As of now, I haven’t gotten comments to show up or work when integrated with the site, which is fine because 1) no one is reading this blog in the first place and 2) when people are reading it, which they aren’t, no one is commenting. The tags still aren’t showing up, which is kind of disappointing and frustrating, so I’m going to work to get that up as soon as possible.

I wrote up a little review/call to action of a game I’ve been playing a lot of over at 2ndplayer. It’s on Betrayal at Krondor, one of my favorite games of all time. Seriously, the game will change your life.

So go check it out, I promise it won’t disappoint you. And if it does, be sure to go complain to someone else.