jason.famularo.org

Running a JavaScript Function when Subscribed Events Stop Occurring

Mon, 20 Feb 2012 18:14:37 -0500

Maybe this is well-known to the JavaScript coding community — below is a simple technique I’ve found that runs a block of JavaScript when subscribed events stop firing. Full disclosure, I stole this from Hugoware. If he stole it from someone else… ;)

Use Case

A user is entering text into a text box. The user stops typing for a period of time, tabs or clicks out of the text box, or is otherwise done using the text box. When the user is done, server side validation is done (such as checking for uniqueness of a username on a sign-up form).

Solution

Attach a set of events to the text box that capture when the user is making a change, or leaving the text box. Every time the event fires, create a function that contains the functionality you want, to be fired on a timeout. If the event is fired again, cancel the existing function.

In code (using jQuery 1.7 syntax):

var timeout;
('#mytextbox').on('focusout blur keyup change', function () {
    if (timeout) {
        window.clearTimeout(timeout);
    }
    timeout = window.setTimeout(function () {
        // Perform server-side validation here
    }, 1000);
);

Bonus: jQuery plugin

While the above code is pretty simple, if you want to use this pattern a few times on the same page, it can lead to some duplicated code and multiple variables to hold the timeout. So I’m solving that with a jQuery plugin. Behold, jquery.onidle.js:

$('#mytextbox').onidle('focusout blur keyup change', 1000, function () {
    // Your idle functionality here
});

For more details on the plugin, visit its GitHub page.

Location Known, but Still Lost

Wed, 25 Jan 2012 20:48:16 -0500

A started a new job in late 2010. At first, it seemed like something that was too good to be true at the time. It had a lot of awesome perks (to me, in no particular order):

Wasn’t consulting
Was a product/service owned by the company and slowly built upon
Had a software team and manager that believed in a lot of those software principles you read about, but never truly see at your job (confession: we’re not perfect, but we strive to always improve)
Was a telecommute job with very little travel
Used the technology and practices I wanted to use

I’m not here to recruit (although at the moment we are hiring) you, but to share a set of experiences that had me baffled until recently.

Whenever I start a new job (or project, as it often is in consulting), there is a period of time where I know absolutely nothing about the software you are writing and the business behind it. After a few weeks or months (depending on the size of the project and code base), I’ve always felt very comfortable. If I ever made it to the year mark on a project, I could recite policies and procedures (even to this day for previous projects, in some limited capacity).

But my new job was different. I hit the six month mark, and still knew less than 50%. Now, at a more than a year with the company, I realize that I may lucky to reach the half way point in knowledge, if I am lucky. This bothered me a lot.

Why wasn’t I learning this new code? Was it harder? Was I losing my touch?

Why wasn’t I learning the business? Was I not paying attention? Was it because I was working from home?

I was lost.

Only recently, I realized the answer to why I wasn’t understanding the business behind the job. Put simply, I didn’t fully understand the business. I was no longer on the “front lines”, sitting, talking, planning, prototyping, demoing, testing, and involving the end user in day-to-day project activities.

Instead, I was on a product development team, sheltered from the “why’s”. Instead, I had plenty “what’s” and “how’s”, but never a good explanation why. Sure, there were some user stories, but never did I get the depth of knowledge gained from being there with the end user, watching them work, and truly understanding what the needed.

How have I solved this problem and why am I happier? I’m not sure it is truly solved. I volunteered to work with a client more directly. In two months, I feel I know their business and needs better (but not anywhere close to completely) than what I learned in the first twelve months. I’ll be master of a few things, instead of a jack of all trades.

Sure, there is a larger slope to learning “everything” this time. I’ll eventually get to “the guy who knows a lot”. In the meanwhile, I’ll be happy to know what I know and to know how to find answers to what I don’t.

Patching vs. Merging

Thu, 12 Jan 2012 20:03:52 -0500

One of those “fun” activities developers look forward to is merging code from one branch to another. The scenario I personal use most is merging changes from the trunk back to the branch that is about to be released.

For the last few releases I’ve deviated from my normal usage of the built-in merging capabilities of (Tortoise)SVN. Instead, I’ve made a patch of my changes just before I’ve checked them in (to either trunk or the branch, wherever I’m working). I then apply the patch to the other.

The upside is it’s a lot easier and generates less mess. Perhaps I merge to infrequently and forget the “best” way, or run into troubles because SVN is, well, SVN. The downside is I lose the context of the merge. Nothing ties to the commits together (arguably, I could commit at the top-level of the repository, but I’m not currently setup to do that).

Is this good, bad, or just preference? I’m not sure, but I’m a fan of anything that removes development friction.

How Reading User Reviews and Triaging Software Defects are Similar

Wed, 11 Jan 2012 20:44:47 -0500

User reviews saved e-commerce — the power of the Internet buying masses, crowd-sourced into a win-win situation for both retailers and consumers (B2C!).

The above is a lie (and also hard to read, filled with terrible e-buzzwords).

User reviews are difficult to parse, give a false sense of security to the buyer, and are one of the many profit-extraction tools that retailers employ. How many times have you seen a 4 or more star review (out of 5) end up being a complete dud? How about a poorly review app on your phone actually being quite good (Amazon app store, I’m looking at you).

I’ve finally gotten to a point where I feel comfortable parsing the reviews and discerning (potentially) valuable information. I try to end up with one of the following (mind-blowing) generalizations:

This product is worth purchasing
This product is not worth purchasing
Not enough information is available to make a decision

Often the journey is the reward, not the destination. How do I parse all of the reviews, both good (in content, not score) and bad? I want to know what’s genuinely wrong with the product, and if I’ll be okay with it. I’ve come up with a few rules that help me determine this:

Score doesn’t matter
Read most or all the bad reviews (within reason)
Read a random sampling of average and good reviews
Discard the overly positive lovefests and the snarky, curmudgeonly negative reviews

So how does this relate to software defects? Defects have a stigma attached to them. They are often an unfair “1 star” review by the person reporting the issue. When prioritizing work, these sour items have the possibility to poison the choice of the work that gets done. Each defect needs to fit into one of the three categories, conspicuously similar to user reviews:

This defect is worth pursuing at this time
This defect is not worth pursuing at this time
Not enough information is known to make a decision; research and reevaluate until #1 or #2.

What technique and tidbits can you learn by reading the list of defects as if it was an anonymous user review?

The priority of the defect as determined by the submitter may not represent the true priority within the project
Read all the comments, and similar defects, and weigh together
Deflect the overly negative opinions of your software; a single defect can change the opinion of the software, but shouldn’t change the team’s motivation
Likewise, don’t get trapped only hearing the positive feedback. I’ve yet to meet a project that has zero defects (although I did have a manager once who claimed his last project didn’t have any bugs and that was the standard I was going to be held to)

Often times, a sign of great software are the requests for enhancements by the end users. At a glance, user reviews don’t give an accurate picture of what’s right or wrong with a product. Likewise, defects (and enhancement request) don’t always tell the story of where your project needs to focus its energies.

User review and software defects have their value when evaluated together. Also, if you liked this post, be sure to give it a 5 star rating. ;)

Inbox One, the Pragmatic Approach

Wed, 04 Jan 2012 20:09:17 -0500

The Getting Things Done methodology encourages behavior such as Inbox Zero, the concept of dealing with all the items in your inbox and keeping a zero count. In previous jobs, I’ve tried to do this, and struggled at times, having as many as 1000 items. Even when triaging my inbox regularly, I’d still end up with 50 items that needed some sort of attention.

Lately, I’ve been using Gmail for personal and work email, and have found a balance that isn’t as stringent as inbox zero, but eliminates most of the mail. I call it Inbox One, as in one page of email. At any given time, I have at most enough email to fit on one page. As soon as it gets larger than a page (or I get a downturn in work), I clean it out as much as I can.

Currently, I have 3 items in my work inbox (up 50% from this morning, oh no!) and 10 items in my personal email inbox. Only 1 of those 13 items need attention today.

I still follow the Inbox Zero teachings, but try to be a little more pragmatic. Not everything needs to be handled immediately, but as much that can be dealt with quickly, or properly scheduled as work to do in the near future, I take care of. What is left are a few items that eventually need to get done. Like Inbox Zero, anything unimportant is archived, deleted, or filtered.

Inbox Zero is near impossible to maintain all the time unless you are very self-disciplined. Inbox One is far more tenable.

The Importance of Releasing

Sat, 24 Dec 2011 20:31:06 -0500

An “old” adage in development is “release early, release often”. This is a form of iterative development which allows for lack of functionality initially, and additional function in short releases afterwards. It’s helpful, because it gets your site in front of real people, quickly.

I recently tried this approach with machine2date and SharedBetween.Us

machine2date is a site that focuses on one thing, converting “computery” dates into dates people recognize. If you do JSON or XML in your development, dates like “\/Date(1240718400000)\/” don’t mean much to anyone but a Unix time programmer (it’s ticks since January 1st, 1970 at midnight.)

SharedBetween.Us started out as something that was much simplier than what it is today. It’s a simple task list that can be easily shared between users. It was originally “SharedLists”, but the domain was taken, so I lazily renamed it to its current name.

Both of these sites are easy to make changes to and deploy quickly. A lot of the friction in deploying is managing releases and doing the physical deployment. The combination of git and AppHarbor makes setting up a new site stupid-easy. In 15 minutes, you can likely do all of the following:

Create an AppHarbor application
Buy a domain name
Setup DNS to point to AppHarbor
git init (in the root of the application or webpage you’d like to deploy)
git add .
git commit -m “your comment here”
git remote add appharbor http://username@your.appharbor.url… (Your URL is easily viewed on the AppHarbor application page after your complete step 1)
git push appharbor master

That’s it. To update the site, you may need 3 minutes. Just do the following:

Make update to application or webpage. Trivial changes or spelling corrections no longer need to wait for a “full release”.
git add .
git commit -m “your comment here”
git push appharbor master

AppHarbor explains it all here. There’s not an excuse to do an initial release. Or a simple update.

If Nuget Won't Update, Try This

Fri, 23 Dec 2011 23:58:21 -0500

The newest version of Nuget, version 1.6, wouldn’t update on either of my computers from within Visual Studio. I’m not certain why, but the fix is simple. Run Visual Studio as administrator, go the Extension Manager, uninstall Nuget, restart Visual Studio, and reinstall. Don’t bother uninstalling from Add/Remove Programs, it’s a trap!

Removing IDE Distractions in Visual Studio

Fri, 23 Dec 2011 23:49:40 -0500

I’m not sure where I first read about “distraction free Visual Studio”, but it’s a thing, and I quite enjoy it. This article explains how to take to the extreme. At a minimum, I suggest turning off all your various toolbars. How often do you really use them?

Obvious Observations: Ask good questions

Wed, 21 Dec 2011 20:49:05 -0500

I was on a call with a client the other day and realized I wasn’t getting good answers. Instinctively, I wanted to blame the person answering the question. I’d never blame a client (coworkers are fair game ;) ), so I took a step back and thought about the situation. It was instantly obvious that I wasn’t asking a good question. If you want a good answer, you should ask a good question.

Volleyball for Programmers

Tue, 20 Dec 2011 21:20:05 -0500

Reflecting on the year, I learned a valuable lesson about what I can and can’t do. The things I could do ten years ago, but haven’t really done since, are still doable, but very painful.

My “case-in-point”: volleyball. I played a lot of volleyball in high school and college, but haven’t really played consistently since. I had a chance to play in a tournament a few months ago and came to the realization: I, a decent volleyball player in the later nineties and early “aughts”, am a shell of my former “glory”. I didn’t push myself exceptionally hard, and played how I would have normally played. I thought I played well for being away from the sport for few years, but came away extremely sore for days. That soreness was a shock.

As I discussed this painful situation with others and thought of how this could have come to be, I realized that our bodies and brains think we can do the things we were easily able to do in the past. I could once jump, dive, and run around like a crazy man all day, for days on end. Sadly, that’s not the case anymore. I can still dive, but the rewards are less (such as the ball not getting saved) and the penalties are worse (soreness for days).

How did this come to be? Through simple atrophy. I have played volleyball casually throughout the last decade, even semi-competitively like this. But never have I been sore for days. The decline was gradual. At first I was only sore the next morning, a few years later, sore for the entire next day, and now, sore like the out-of-shape computer dude I am for a few days.

So what does this mean for you, the programmer? Your technical skills atrophy over time. I used to be really good at deploying and configuring Windows Server 2000 and 2003 for a ASP classic solution. I haven’t done that in six or seven years. I think I can still do that, but I will likely have a much more difficult time than I would have had circa 2004.

That’s an interesting example, because we truly have two sets of skills: those we care about and those we don’t. It’s unlikely I will ever need to do another deployment of that decade old technology again. That’s a specific skill I can let atrophy.

On the flip-side, I’ve not done serious Java development in five or six years. I don’t think I’ll have a hard time coming back up to speed. I’ve coded C# in the meanwhile, and a lot of the patterns and practices can be shared between the two (for example, the concepts behind MVC are still valid, regardless of technology). Still, I should expect some “soreness” as I come back up to speed.

Once you get behind on a technology or skillset, you have two choices: risk it and wait until you need it, and endure a lot of pain once you do, or plan for it, and keep the skill sharpened by practicing from time to time.

Waterfall Development, a Slow Dulling

Mon, 19 Dec 2011 12:14:54 -0500

I’m sure this comparison has been made before, but repeated use of the waterfall development model has a slow, dulling effect on software teams (and the systems they ultimately create). Stones at the bottom of a waterfall are far more likely to be rounded after years of wear by the falling water. Likewise, a developer, business analyst, QA tester, project manager, and (possibly) designer start to wear down after the same rigid process, repeated over and over.

Changing again

Sun, 18 Dec 2011 21:54:21 -0500

Once again, I’ve decided to change blogging platforms. It’s a hassle I’m learning to not like, but this transition went a lot smoother than the last. This time I landed on Tumblr. It’s pretty good, custom URLs and all.

One thing I realized in changing to a service I don’t control completely from the web server level, is that all existing items would “go away” in the eyes of Google, old links, etc. Last time I set up 301 redirects. I did this as well, but couldn’t reuse blog.famularo.org. I ended up choosing jason.famularo.org, which is okay, I guess.

Also, done with tagging. I choose poor tags and I am terribly inconsistent between posts. Less is more!

Lessons learned from changing blogging software and moving to a new host

Mon, 12 Sep 2011 12:30:00 -0400

I recently decided to move my personal website to AppHarbor. (If you are a .NET developer and haven’t had a chance to check out AppHarbor, stop reading this and click on the link. Seriously. They are awesome.) The hardest part was moving my WordPress-based blog, which is based on the PHP scripting language. Don’t get me wrong, WordPress has been pretty awesome, is widely supported, and did everything I needed, and more. I ran across Phalanger, which is PHP for .NET. In a few simple steps, I was able to install it and get my existing WordPress blog running on it. It was awesome. Decidedly less awesome was trying to get it to run on AppHarbor.

In the end, I decided to abandon the idea of running PHP on .NET. I’m pretty sure I figured out most of the hurdles that would have prevented it from running on AppHarbor, but it wasn’t worth the hassle and fragility of the whole thing. Instead, I decided to find a .NET blogging engine, and settled on – wait for it – BlogEngine.NET. It seems to do most of what I need, and seemed easy to install. In the process of changing blogging software (and domains, from www.famularo.org to blog.famularo.org), I learned the following.

301 Redirects are essential

A secondary goal was to keep highly ranked, useful posts (both of them) both highly ranked and properly linked to the Google result. The answer is pretty simple: sending an HTTP status code of 301 at the former URLs. I accomplished this by creating a new section in my web.config under the system.webServer element. Here’s an example of one such entry:


    
		
			
				
					
					
				
			
		
<- The rest of your web.config -->

Since the ASP.NET engine fires before PHP, IIS successfully redirects to the new site. I didn’t try to get fancy and create a single regex for all nine posts. Instead I hand crafted each one, and added a default for all other traffic to /blog.

I was already using Feedburner and updated it to point to the new RSS feed. I shouldn’t lose my (four) subscribers. A loss of even one would be catastrophic, statistically.

Load-balanced “cloud” hosting has some hidden surprises

This issue was the only one to surprise me along the way. Everything thing else went according to plan, even if some learning was included (a bonus!). I tested everything locally, including the remote connection to the database. All that was left was to deploy and enable the 301 redirects. As soon as I deployed, about 20% of the links included some (seemingly) random port. I used IIS Express to test, and instantly though I’d cached some sort of URL in the database or app_data. After searching, I read an article on the AppHarbor support form. The load balancer does “weird” things to URLs, namely when asking for the absolute URL of a server, it gives you the absolute URL, including port. After downloading the source code for BlogEngine.NET, I found the problem. And decided to fix it.

< 10 Posts? Just copy and paste

If I was a prolific writer, I would have had a huge problem importing data into the new system. Instead, I just copied and pasted each post. Two caveats: formatting and images. Formatting didn’t come across in all instances. I also changed some H2 tags to H3 to be more consistent with BlogEngine (H2 is the post title, and I strive to be semantically correct). Images also weren’t playing nice with the rich text editor (upon saving). I solved this by changing BlogEngine to store files in the database. In retrospect, this is a smart decision for any cloud-hosted application. Your files need to be in a common location (because you ideally only want one logically set), either in a cloud database or in a cloud file share (like Amazon S3).

Open Source saves the day

I had two problems with BlogEngine.NET. The first is described above, under the load balancing topic. The second was with Diqcus, the popular commenting system. My (four) discuss comments didn’t appear to migrate, even though I picked the super-useful “follow 301 redirects” option. Disqus seemingly had the right data in the admin dashboard, but it wasn’t showing on the site. After reviewing Disqus’ documentation, I realized the JavaScript on the blog calling the API to get the comments wasn’t sending all the “recommend” information. That’s probably the nice way of saying “required”. In the end, I decided to do the same thing that I did with URL issue. Fix the source code.

Open source is great for this. I have the source, I can read and change as needed. I plan on sending my changes back to the project, as someone else will likely need them.

Summary

The migration had a few bumps, but after hacking some code (always fun, no sarcasm intended), I was able to get the result I wanted. And I will get to save $9 a month in web hosting costs, at least until the blog gets popular. At the current rate, that’ll be the year 2113. Only 102 years to go!

Matty and the upside-down mouse

Fri, 15 Jul 2011 20:30:00 -0400

Ah, Salley Hall, part of the prestigious suite of dorms at FSU that were voted top five “dorms like dungeons” during the late nineties. It was during my time in this fine residence that I became the unofficial tech support for the seventh floor. Computers weren’t yet a requirement for students, and were considered a luxury. Still, most of the rooms had at least one (we were four to a suite, two to a room). All students incoming that year got free dial-up access (at 33.6kps speed). There was a (paper) form to fill out to “get online”. In addition, all students were encourage to claim their free “@garnet.acns.fsu.edu” email address. How memorable!

Being one of the few students to properly setup Eudora and dial-up in Windows 95 (oh, how I didn’t miss the PPP stack in Windows 3.1), I often got asked to setup email for my floor-mates. One such gentlemen was “Matty”, an out-of-state undergrad from the Bronx (assuming my memory serves correct). Matty was used his roommate’s computer, so I setup a second Eudora profile and a neat little shortcut on the desktop.

One day, I got word that he needed some help, so put on my flip-flops (slim chance I was walking barefoot in those hallowed halls) and went down to his suite. Matty was sitting at the computer with some problem on-screen, but my attention was immediately turned to his mouse. He was clutching the mouse in his right hand, but it was rotated 180 degrees, his palm resting on the buttons. I watched him use the mouse and asked how he was doing that. His answer surprised me. “The first time I used a computer the mouse was upside-down. I assumed it was the way you were supposed to use it.”

I was having a hard time comprehending the situation. I mentally went through the motions of using a mouse “upside-down”. Left would be right, up would be down. “How do you click the buttons?” I asked. “Like this,” he replied, showing me how he rocked his palm left to right click (remember, the mouse was upside-down) and right to left click. Everything I assumed about how computers were used was now in question.

Baffled, I fixed his problem and went back to my dungeon-like dorm. To this day, I don’t remember what Matty’s computer problem was. All I can remember is the mouse. Luckily, this traumatic incident didn’t affect my ability to use a computer throughout college and into my professional career. But I do sometimes think back to the situation when I make sweeping assumptions about how a user interface I’ve designed will be used.

Why you have to get a paper document signed to update the database

Wed, 13 Jul 2011 00:50:00 -0400

A term I’ve used to describe various IT organizations in the past is “maturity”. A more mature IT shop will have a standards, practices, and other safe guards to ensure that production, testing, and development environments are functioning at all times. A less mature IT shop will just “wing-it”, doing whatever it takes at that particular moment to put out the fire at hand. They’ve yet to see many of the various problems that can occur.

One thing I’ve noticed at the “mature” organizations is the need for a signed piece of paper requesting a change to the database. For an outsider (I was a consultant in a former life), this seems absurd on the surface. Why do I need to sign a piece of paper? We work with computers! If you take a step back you’ll see the bigger picture. It’s a safe guard. The extra steps make multiple people put thought into what is about to happen, including the developer, DBA, and project manager. But how did we get there? Let’s start at the less mature organization and work our way up. Please note these are generalizations.

Starting point: Anything goes

Initially, the IT organization may exist of only a single or few developers. In this case, the sole developer may or may not have a development database that gets updated. Once this hopefully-existent database is tested with the new code changes, it’s deployed directly to the production database. The deployment is done through the path of least resistance: copying the website directly from the developer’s computer and using the GUI tool that came with the database to make the database changes manually.

Point 2: We have a problem

The above procedure works fine for a while, but the developer makes a simple mistake. He or she was working late on a Friday and forgot to add the new column to one of the tables. Production isn’t working on Monday and the owner of the small company is angry no orders were taken over the weekend. (Feel free to insert your own story here about what whom this IT organization supports.) The developer vows to “get things right” from now on and makes an informal step of writing a SQL script to apply the changes. The other developer (my, how we have grown!) reviews it prior to release and tests it on his local database. The problem is generally resolved. Small refinements are made throughout the next few deployments.

Point 3: Sizable concerns

The business is successful and the development team is now four or five strong. They’ve even convinced the management team to hire a tester. Things are great. The developers and tester often talk about “how we can do deployments better” and “how we did it at my last company”. A few processes are discussed, implemented, and enjoy relative success. Deployments are no longer scary! But something unexpected happens on evening after a deployment. The database server runs out of disk space. No one is a proper DBA, so it takes hours to figure out and recover. Unfortunately it’s now six in the morning. The Monday morning retrospective is going to be painful.

Point 4: A team effort

It’s now years later. The business is more than just successful. IT is an official division, and has its own suite in the office complex. Things are rocking. Deployments are scheduled for Friday evenings. Hotfixes go out as needed, but in a controlled fashion. A project manager has been hired to coordinate all the various sub-projects that have sprung up. Gant charts line cubicle walls, a library of project document templates exists on the shared drive, and in the corner of the suite, alone, sits a sole database administrator. He’s pretty good and handles a lot of the infrastructure requests as well (and has had no luck getting that network engineer position approved he’s been lobbying for).

A divide has occurred between and within the teams. There’s the dev team, the test team, the analysis and management team, and the DBA “team”. A single guy makes a team, it seems. The DBA is tired of the developers and their unoptimized queries and DDL changes. He’s tried lobbying for some sort of change, but the dev team “just runs everything” anyway. And besides, the project manager only cares about deadlines and budgets. You spend how much on database licenses but can’t hire a second DBA? One more screw up by the dev team and he’s going to threaten to quit.

Point 5: Maturity

A few years later and IT has all the kinks “worked out”. The teams know and fulfill their roles. Standards have been in place for a few years, and systems written years ago are now up for a rewrite. A particularly tricky replacement of some of the original systems — how are those things still working — goes live this weekend. A document has been produced that illustrates the roles each team member plays. The current system goes offline at seven in the morning on Saturday and the new one should be online by noon.

The big day is finally here. One of the managers has brought bagels and orange juice, although no one knows why he keeps bringing the salmon spread. It almost never gets opened, let alone touched. The first step is to ensure the nightly backup of the database was successful. After a few minutes, the green light is given and the development team lead gives the go ahead to the infrastructure team to apply the deployment package. In the meantime, the database team starts the database migration.

Then something goes wrong. Horribly wrong. Wrong enough to make any other problem the company has had look weak in comparison. Every contingency was discussed and planned for. The migration was run multiple times against a clone of prod. How could this happen?

After much discussion, much chastising, and many long hours, the development team lead explains to the rest of IT that one of his team members made a slight change to the migration on Friday. There was a new scenario in the last production refresh that didn’t migrate correctly. Perhaps if it didn’t take a week to get a refresh they would have caught it sooner. A meeting had been held on Thursday to discuss options, and project manager agreeing with the need for the change, but not really understanding it, approves the change.

The database team instantly objects. “We weren’t involved”. The development team lead explains, “we didn’t think you needed to be. It was a simple change. Low risk.” QA wonders why they weren’t in the loop at all. The blaming goes on for a week and the manager finally has enough. Starting next release, a new policy goes into effect. Each change made to the database must be reviewed, approved, and tested by the database team. Everyone reluctantly agrees.

Epilogue

It’s months later. The dev team hates the “paperwork”. Submitting the SQL scripts to the database team is pointless. They either approve them without looking or reject them based on some misunderstanding. Meanwhile, the database team is sick of all the complaining, as well as the paperwork. The dev team submits script after script. There has to be a better way.

Recap

This story is absurd, and only partially based in the reality of my career. Hopefully it illustrates an important point. Ludicrous decisions don’t get made overnight. There are usually years of justification behind them. At the time they are made, they seem like the right decision. No one willingly chooses to have signed paperwork. It’s a series of mistakes over years that leads to this result.

I only ask you be pragmatic when making these decisions.

Finding unused CSS with Google Chrome

Tue, 03 May 2011 09:27:00 -0400

With the advent of jQuery and its selector engine, I’ve gotten a lot better at writing accurate stylesheets. But I’m never 100% sure if all of my CSS rules actually point to something. This tweet reminded me of my lack of CSS skills. And a few days later I stumbled upon a gem in Google Chrome.

Open the “Developer Tools” in Google Chrome by hitting “Control-Shift-I” (Windows, your OS may vary). You can also find it in the wrench menu under “Tools”.
Navigate to the “Audits” tab.
Optionally, uncheck “Network Utilization”. It’s not need for the CSS auditing.
Select “Audit Present State” and click “Run”.

After following those steps, the results will display on the same tab. One of the results may be “Remove unused CSS rules”. If it’s not there, you are the best CSS artist in the world. For the rest of us, expand the tree.

You’ll get stats (my home page doesn’t use 91% of its CSS — a case for not having monolithic stylesheets) as well as a list of files or inline CSS that can be optimized. Expanding each item will show you the culprits.

I also suggest reading the other results of the audit. They’re good too.

Can Any() of you Count()?

Tue, 12 Apr 2011 22:55:00 -0400

LINQ, which stands for Language Integrated Query, isn’t new anymore. It was introduced in .NET 3.5, which saw its release in November 2007. At this point, I feel it should be a core skill for any seasoned .NET developer.

But every now and then, I see LINQ that makes me cringe. Before you write a line of LINQ, you should understand that it has deferred execution. That means it’s not executed as soon as it is called. Instead, the query waits as long as possible before returning results.

My personal philosophy is to take advantage of that delayed execution. The following line, when called needlessly, causes that cringing feeling I spoke of earlier:

var results = (from o inobjects
  where o.something == "something"
  select o).ToList();

The ToList() forces LINQ to loop through all the items in that enumerable. That’s all fine if it will always be executed, but what if the next line throws an exception? You’ve just looped through a possibly large collection for no reason. Perhaps this is a better example of a possible pitfall:

var results = from o inobjects
  where o.something == "something"
  select o;
if(results.Count() > 0)
{
  // Do something
}

Oh my eyes! Not so bad you say? Let’s consider what .Count() does. Unlike IList.Count, the .Count() extension method in LINQ doesn’t know what the size of the enumeration is yet. It has to iterate over each and every item. The cost of counting is very expensive. When combined with Count() > 0, you can see that you have to count all the items just to see if you have any. What’s the smart developer to do?

The Any() extension method is exactly what we want. It iterates the bare minimum number of times to determine if there are items. Logically, if (enumeration.Any()) is the same as if (enumeration.Count() > 0). But the cost of .Count() is a order of a magnitude higher.

While I am on a LINQ tirade, let’s discuss .First(), my least favorite LINQ extension method. Often times, I come across the following code:

var myThing = (from t in things

  where t.something == "something"
  select t).First(); // Or .FirstOrDefault()

Why does this concern me? It assumes any results after the first one are insignificant. What if two things match “something”? Did you expect that? What do you want to do with the second result? Apparently nothing.

For a resolution, I suggest using .Single() or .SingleOrDefault(). These extension methods are clear in their intent. I expect one (or zero or one for .SingleOrDefault()) items to come back. Any more, and an exception is thrown. I’ve avoided hard-to-find bugs by using .Single() instead of .First().

Please continue to use LINQ in your applications. But think of the implications of your next query. You may not save humanity, but you will save my sanity.

Presentation Considerations

Mon, 21 Mar 2011 14:40:00 -0400

I’ve had the opportunity to give numerous presentations at work, and recently, have started giving presentations at the local .NET user group. I’ve gathered a few tips, some I’ve (painfully) figured out myself, and some graciously passed on from co-workers.

Be early

Ensure that you get to your presentation location early, especially if you are using the network or a projector. These two elements add unknowns and configuration hassles that are sure to take longer than you think. Even if you are presenting at a location you’ve presented at many times, get there early. Nothing is worse than showing up just in time for your presentation only to find out that the computer that is always there, isn’t. Trust me, it happens.

Practice

It helps to know what you’re going to talk about ahead of time. Practice your presentation at least once, if only mentally. Be knowledgeable in your topic, as questions will likely come. Know how long it will take to get through the material. You don’t want to be the proverbial deer in the headlights.

Prepare your computer

Consider creating a demo user. Your daily user account, especially if a personal laptop, may disclose personal information or stuff you’d rather not show your audience. Especially if your audience is your client. And your laptop name is spongebob. Do realize that you may need to setup your development environment again. And that can cause issues. But ideally, that only has to happen once.

Don’t play hide and seek

Your audience is there to see something you are presenting. If you are hidden behind the computer, you won’t be as engaged with your audience. No matter how good your material, a voice from behind the computer will be tough sell.

What are you doing?!

You want your presentation to be remembered for what you presented. Not that nervous hand movement, not the fidgeting, and not the fast talking. In short, remove the distractions. It’d also be nice to remove the “um” and “likes” from your vocabulary.

Dress appropriately

Your mom was right. It does matter what you wear. If you are presenting to clients, consider dressing your best. Also know what their dress code is. If they have casual Fridays and you roll in dressed in a three-piece suit, you may be done before you start. If your audience is a user group or similar presentation, consider something a little more casual. Too casual and you may lose credibility. When in doubt, see what others before you are doing.

PowerPoint prepared

Say what you will about PowerPoint, but chances are some sort of presentation software will be a part of your presentation. If borrowing a computer, make sure it has the right software to display your MS Office 2012 PowerPoint XP Ultimate Edition file. PDFs also work.

A second thing to consider is your content on your PowerPoint. Know what is coming up. Have a printed outline to refer to, with speaking points in case you get lost.

Checkpoint

If doing a demonstration in code, or demoing an application with complicated data entry, consider setting up “checkpoints”. If you get behind, run into problems, or can’t remember the exact way to get that rare-but-awesome scenario to occur in your application, you aren’t helping your cause. Compare this guidance to the cooking show that cooks a turkey in sixty minutes.

No happy clicks

When showing an application or the depths of some menu tree, don’t have a happy mouse. Move slowly so users can see what you are doing. Explain the actions verbally and any behind the scenes functionality.

Zoom Zoom

Projectors show your picture really big. But if you are running 1080p with tiny fonts, half the room won’t be able to see it. Zoom in your application, or lower the resolution of your computer. Many IDEs have zoom modes built in. In Visual Studio 2010, just hold control and scroll the mouse wheel.

Plug in your laptop

Unless you get five or more hours, plug in your laptop. You don’t want to risk your computer shutting off. Which reminds me, make sure all your Windows Updates are installed. I once had a computer force reboot in the middle of a demo. It gave me a five minute countdown. I had ten minutes of material left.

Stay

Plan to stay afterwards to answer questions. Say thanks to anyone providing feedback, both good and bad.

Respect

Respect others’ time. Start on time and end on time. Speaking of which, this post has run a little long…
Got a tip I missed? Let me know!

Simulating TFS Shelvesets in Subversion

Wed, 16 Mar 2011 21:31:00 -0400

Update: A proper SVN Shelve feature is tentatively scheduled for Subversion 1.8

Having worked with Team Foundation Server for version control for a few years, there was a slight adjustment for me when I started working with a team that used Subversion. A feature my previous team used was Shelvesets, designed to save code to the version control system but not commit against your daily work. This was useful if you were partially done and got interrupted, wanted to experiment and save for later, or share changes with a teammate. In the end, your code is temporarily saved away for later retrieval.

How it works in TFS

To create your temporary shelveset, right click the solution root, selected “Shelve Pending Changes”, give the shelveset a name, optionally add a comment, select the files to save, give the shelveset a name, decide if you want to preserve the changes locally, and hit “Shelve”. The files are stored on the server, based on your local changes. Your local changes are undone, if you unselect the option the preserve local changes.

To retreive, you right click the Solution root and select “Unshelve Pending Changes”. Type the owner’s name, if you are not looking for your shelvesets, select the desired shelveset, and click “Unshelve”. The files are retreived and merged into your local workspace. Please note that in Visual Studio 2010 the menu item has “hidden” itself in the File/Source Control menu.

How it (mostly) works in Subversion

I’ve tested the following with TortoiseSVN and the AnkhSVN plugin for Visual Studio. It’s not nearly as seamless as the TFS solution and leaves a little to be desired. I’ll be using the patch feature in SVN, which creates a file denoting the differences that can be applied back to the original source.

I’ll use TortoiseSVN for the examples, as many will be familiar with that tool. Right click the folder in Windows Explorer containing the changes (likely the solution root) and select “Create Patch” from the “TortoiseSVN” menu. Check the items you’d like to “shelve”, and click “Okay”. Name the patch and place somewhere safe. For a full TFS like experience, create a folder in SVN for your patches and commit. I’ve been keeping them on my local system, which I’ll admit is a little dangerous.

At this point, you can revert your changes. All your changes are saved in the patch.

To restore your changes, right click the solution root and select “Apply Patch” from the “TortoiseSVN” menu. Select the patch you saved in the last step. At this point, you’ll be prompted to merge your changes, one file at a time. This is where the experience is less than ideal. In TFS, if all is well, your changes are auto-merged. In Tortoise, I’m asked to review the changes and resolve conflicts (if any exist), which is important in its own right (TFS prompts to resolve conflicts as well if they exist).

A few things to note. You can share your patches with your team. This is a nice way to shared a proposed change with a co-worker or send your changes to someone for code review. I’ll include a warning as well, although this is generally true with all version control systems. The longer your patch sits unused, the more stale it becomes. At some point, the pain of merging it may exceed that of reviewing the content of the patch and making those changes manually.

I hope this small guide provides some insight for TFS developers making the switch to Subversion. Please leave a comment if you can improve the process. This is just the way I’ve been doing it, and is by no means ideal. And no suggesting Git. ;)

Learn a Foreign Language (and Spy on your Enemies)

Wed, 16 Mar 2011 12:40:00 -0400

Besides coming up with corny jokes and blog post titles, I spend a fair amount of time reading about new technologies. Recently I have found that I am reading more on languages outside the .NET world. It’s interesting to note the similarities and the differences. For example, the well-known and timeless design patterns tend to show up in all languages.

This got me thinking about a project I was on years ago. I was a ASP/VB6 developer at the time (sad, I know) hoping to get into .NET (VB.NET of course, wasn’t too sure about that new-fangled C#). An opportunity came up at work to join a Java team. It wasn’t .NET, but it also wasn’t VB6. I jumped on the opportunity.

As an aside, I should note I wasn’t yet a seasoned developer. I thought I knew a lot, but “I didn’t know what I didn’t know”. It was clear the programming leads really knew Java. I had “mastered” ASP, so I fit in as a “smart dude”.

The leads were into all sorts of various Java technologies and projects. I instantly concluded that Java was about assembling far too many different small pieces. Pieces I would have to learn one-by-one. So whether it was Struts, Java Beans or Java Server Faces, I jumped in.

I quickly found out a few things:

Java, the language, was pretty easy to learn. I had done a little bit of Java in college, but that didn’t mean anything in the professional world. I came up to speed pretty quick.
Java, the enterprise collection of features, projects, and practices, was really hard. They don’t teach this stuff in school.
Some of the “Java” programmers on the team were just as clueless as my ASP brethren.

What turns out to be hard usually frustrates. I was frustrated by all these little bits and pieces. There was a pattern that seemed to have a different, yet similar object, at each level of the application as data made its way through the system. Form Bean objects copied their data into data transfer objects, which passed their data onto objects to persist the data. I didn’t understand each of their purposes and quickly went mad.

Fast forward five years and the .NET development practices have matured and caught up to Java in many regards. I’ve been involved in various UI patterns, and finally see the value in all those various objects I used to loathe. In a way, I feel I wasted two to three years of my career being “good enough”, not knowing what I was missing. Had I paid more attention and found out the “why” behind the patterns, I could have been ahead of the curve.

Let’s review the implied lesson. If you spend time in other languages and developer ecosystems than your native, day-to-day language, you may learn something. Ruby has has had this “on Rails” thing for a while. Perhaps you (and I) should check it out. jQuery loves to talk about “chainability”. While it may not have created to the fluent interface, I can’t help but think web developers switching between their native languages and JavaScript wanted to see more of that.

I’m not asking you to commit to completely learning a new language, or abandoning your current. I’m asking you to look around, see what else is out there, and take the best pieces and improve your craft.