Code Renaissance

Named Function Expressions in JQuery & Knockout JS

2011-10-29T00:59:00.001-04:00

Recently I was working with JQuery & Knockout in javascript and got a long running script error so I broke out the profiler to see what was wrong. Unfortunately both JQuery and Knockout code take in a lot of anonymous functions so looking at the profiler and the stack wasn't especially useful. To make the debugger and profiler more more useful I added a name to the function expression that I suspected was causing the problem similar to this:

//Changed form this:
viewModel.FooBar = ko.dependentObservable({
  read: function(){ //Note the anonymous function expression
     return this.foo() && this.bar();
  },
  owner: viewModel
});

//To this:
viewModel.FooBar = ko.dependentObservable({
  read: function readFooBar (){ //Note the name readFooBar 
     return this.foo() && this.bar();
  },
  owner: viewModel
});

These are called named function expressions (NFE's) and they can be seen in both the profiler and the call stack. As it turns out the function that I was troubleshooting didn't have a problem after all. Later the same trick allowed me to verify the real problem was in a custom binding that I had written.

Using named function expressions hasn't been common up till now because there were issues in IE8 and lower, however these issues are easily avoided by 1)giving all named function expressions unique names withing their enclosing scope and 2)NEVER referencing the NFE name in your code (IE9 and other major browsers don't allow you to do this anyway). By following these rules and making this small investment in your code you can earn huge dividends when debugging and profiling.

The Lie of Reusablity

2011-07-18T00:01:00.003-04:00

The lie of reusability in software engineering is that modules and controls that are competently designed are easily reused and that reuse will translate into increase productivity. Business people love this concept, which has ample examples in the physical world, because reuse should save time and time is money. So they push the expectation of reuse and increased productivity on developers who strive in vain to bring the myth to life. In practice though, reuse usually requires significant effort and the main benefit you get, at least the first couple of times something is reused, isn't increased productivity, it's increased maintainability.

Consider a simple textbox control (win-forms, asp.net, etc). It took thousands of hours of effort (adding together the planning, coding, testing and maintenance time spent on the control) to bring that level of reuse to your finger tips. It seems like a simple control, but it has lots of events and properties that make it work for everyone and behind those are a myriad of subtle and well thought out decisions that have perfected it for general reuse.

Anyone who has ever tried to do simple composite user controls for internal use can tell you that even that relatively minor level of complexity has can contain a host of hidden and unexpected problems. Ever purchase a user control from an outside vendor? Worked great didn't it... until you got past the basic cookie cutter code and tried to get it to work in you particular context with your constraints; under those conditions subtle little problems emerge and it often falls just short of what you want it to do. Now go hunt down one of those developers and ask how much blood, sweat and tears their team put into getting that control to that level of reuse.

The truth is when you build a module or control you have no way of knowing how or even if it will be reused. The best you can hope for is to follow best practices and to keep the code as clean and well commented as possible... anything else is wasted time. When you reuse it for the first time you now have a new context to code for and the code will have to be adjusted to work in that context and then refactored mercilessly to make the code clean again. In all likely hood the this work will take longer that the initial work on that item. In the next iteration if you're lucky you may get your first efficiency gain from reuse but adjustments will still need to be made.

One real danger in iteratively adjusting code for reuse is increased complexity. Each iteration will likely have new features and requirements that will have to be added to make it work in that context. The larger the code becomes the harder it will be to understand the code as a whole and the more work it will take to change it cleanly.

In some contexts ("okay now we need all but one of the fields to be read only and we also need 12 additional fields and one button added, but only here") it may be worthwhile to simply build a new control or module to handle that particular case. Yes there may be some code duplication, which you may or may not be able to refactor it our into a common module, but everything in software is a trade off. You'll have to ask yourself which hurts you more (makes things less maintainable), the code duplication or the loss of cohesion and added complexity?

Of course if you're a developer who's been around a while you've likely already been through all this, perhaps wondering what you're doing wrong that the dream of reusability isn't working for you. The truth is you're likely not doing anything wrong... reuse can be a worthwhile endeavor but in all but trivial cases it's going to be difficult.

Quotes for Software Developers #3: Efficientcy

2011-07-11T00:01:00.023-04:00

"There is nothing so useless as doing efficiently
that which should not be done at all." [Peter Drucker]

My Take On It

Unneeded, poorly planned and underutilized features are one of the biggest wastes of time in software development. You can run the most efficient team in the world but if you're allocating time to unnecessary fluff, you're wasting time.

Is that feature needed? Really? If it is, is there a better way to do it? The longer a bad idea lives the more time it wastes. If it makes it into production not only was the development time wasted but maintenance time will continue to be allocated to a feature that never should have been.

Implement the minimum set of features first and build upon them incrementally. Kill feature ideas early and often. Good ideas will come back again and again until they're implemented.

Maintainability: Consistency Trumps Correctness

2011-07-02T22:06:00.001-04:00

Consistency is the key to a maintainable, high quality codebase. The way an architectural problem (see def) is solved in one part of the code is the way it should be solved everywhere in the code. This is true even if that solution isn't totally correct, correct being defined here as the optimal, preferred solution at a particular moment in time. With correct defined this way, as it is in practice by developers, correctness changes on a fairly regular basis, and can vary wildly from developer to developer, leaving behind it a wake of inconsistent, bug ridden, unmaintainable code.

Consistency provides Quality

One time solutions, those built from the ground up without regard to previous work, have a lot of unknowns that can't be accounted for. Though estimates will be padded to compensate, developers tend to be overly optimistic about their skills and minimize the complexity of the problems. This leads to insufficient time being allocated for a task. When nearing the end of their allotted time behind schedule, having spent time they didn't have on problems they didn't account for, developers will push themselves even harder to meet the deadline by taking short cuts and cutting code quality. These solutions will have significant problems(e.g. bugs or missed requirements) and will take yet more time to get right. To the business it may look like everything is going reasonably well, despite a few defects and delays, but in reality the foundations of the project being demolished beneath their feet.

In contrast, when a developer knows exactly how something is going to be built, especially when they've built it that way before, then their estimates tend to be accurate and realistic, allowing the business to plan accurately and pull features or make other adjustments if necessary. Solutions that are repeated can be implemented quickly with relatively few defects and solidified over time, which is to say that if a bug is found in one implementation it can be quickly checked for and fixed in all. As unfulfilling as it may be for programmers, the only way to do it right every time is to do it the same every time.

Consistent code is Maintainable

When a bug is found or a feature needs to be added the first thing that a developer will do is look at the code to understand where changes need to be made. When consistent patterns are implemented then the developers have a very good idea of how the code works, where to look, and what to do, therefore maintenance will go smoothly.

If an existing pattern isn't working then the team as a whole needs to evaluate it and define a new one... and then go back and change all of the old code. If it's not worth fixing all the old code then it's probably not that broken. Only by establishing and enforcing team standards, patterns, and practices you can create a consistent and maintainable codebase.

Fail 1: Poor Communication and Lack of Documented Standards

Writing standards is an arduous task for most developers and being restricted by them can seem stifling. It's the old "Smart for one, dumb for all" adage. Each developer thinks "I'm skilled. I'm experienced. I should be able to decide how to do things!" but when everyone does this then their disparate ideas and standards will eventually collide (as developers are forced to maintain each other's code) and the codebase will become a nightmarish hodgepodge of one offs, cludges, and hacks. If developers don't talk about the problems they're solving and work together to standardize on solutions then the codebase is doomed to devolve.

Fail 2: A Search for Interesting Problems

Smart developers love to be challenged by interesting problems. These are the kinds of problems that developers will fight over and that the more tenured developers tend to take for themselves. These problems come up frequently early in a project but become ever more valuable commodities as the project matures. During a drought of interesting problems developers will look for problems that have been solved in less than optimal ways and challenge themselves with them. This leads to a codebase peppered with complicated, novel solutions; a complex, inconsistent codebase is the bane of maintainability.

Fail 3: Excessive Speed of Development

This is the biggest killer of code quality. Early in the project, in an effort to prove they are on track and on top of things, the business pushes the developers to produce too many features too quickly. This stifles developer discussions and standards at the time when they will have the biggest impact on the success of the project and future developer productivity. In addition each developer is likely solving many of the same problems in different ways with different levels of success and a great deal of time is wasted.

Developers respond well to, and can even thrive on light to moderate amounts of consistent pressure (this varies from developer to developer). Under too much pressure though they write absolutely horrid code and will sacrifice the code quality and pretty much everything else in order to meet a deadline. Sadly, early efforts to push productivity usually end up hamstringing the project before it ever gets off of the ground.

The Solution

As counter-intuitive as it can seem from a business perspective sacrificing productivity for communication, group problem solving, and team standards actually leads to significantly greater levels of productivity over time. This can be a hard decision for leadership to commit to. Commonly they'll pay lip service to it without actually reducing the pressure on the developers so they can follow through with it. Or worse they won't hold the development team accountable and the developers will shirk the hard work of putting standards in place. The only sane way to manage a project is to put code quality, consistency and standards first.

Quick Tip: JS Event Binding and the Call Stack

2011-07-01T10:46:00.084-04:00

Here's a little tip to make your javascript easier to debug... when subscribing to an event always wrap your event handler in an anonymous function so you can see the binding in the callstack. For instance the anonymous functions below will show up in the call stack (and thus the call stack can take you to the wiring code):

$(document).ready( function () {
   Init();
  });

Sys.WebForms.PageRequestManager.getInstance().add_pageLoaded(
  function () {
   Init();
  }
 );

But on the following calls (without the anonymous wrapper) all you'll see in the call stack is the jQuery or ASP.Net javascript that is doing the event handling:

Sys.WebForms.PageRequestManager.getInstance().add_pageLoaded(Init);

  $(document).ready(Init);

Hope this helps.

Quotes for Software Developers #2: Architecture vs Design

2011-06-24T00:01:00.005-04:00

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. [Grady Booch]

My take on it:

I've worked on systems where every developer does their own thing. Highly interactive business web apps where there is no over arching pattern and everyone takes the path of least resistance... which is usually the way they did it at their last job or worse, whatever seems clever at the moment. These systems are pure hell to work on and maintain.

Every significant decision (ones difficult to change or make consistent later) is part of the architecture. From how you construct user controls, to what is done in code behind and what in javascript, to how you do ajax behavior... it's all architecture and it all matters. There must be a cohesive vision for how everything is constructed. The team must share and enforce that vision.

A lot of this comes down to communication. If someone is doing something that hasn't been done before on the project then they should grab a few team members for five or ten minutes and discuss it. Doing it right the first time is very important because one tendency of developers in a hurry is to simply see how things were done the last time and copy that. If the first set of code was bad you'll end up with six one off copies (each worse than the last) in a blink.

From what I've seen, the more developers have time to discuss the code and how things are constructed (and then run the decisions by their manager or architect for sanity check) the better and more cohesive the architecture will be over time. Peer discussions of architecture must be part of the culture. This means everything from new pages and new features to old code and refactoring. It doesn't have to be long and it doesn't have to be everyone together but small discussions must take place between team members throughout the day.

If developers share in the architecture of the system, if the own it and take pride in the architecture as a part of the team culture, then there will be little need for management to police it because the team members will police it on their own. New members, through peer pressure and team interaction, will quickly be indoctrinated into the culture and the team's pride in the architecture thus perpetuating the system.

Bug Hunt

2011-06-23T19:32:00.003-04:00

While hunting down a bug
I found a mess that made me cringe;
a nasty little block of code,
that cried out for revenge.

Worse yet I found a problem there,
the source of all my grief.
Just who could be this clueless twit
whose code defies belief?

I checked the change-sets one by one
I searched with zeal and glee;
Until at last I found the twit
one year ago was me.

Photo by Mike_tn's on Flickr

Finding Prime Factors in Javascript

2011-06-21T00:35:00.024-04:00

As a coding exercise I decided to write a recursive algorithm to find prime factors of numbers. Why? For fun, learning, discovery, mental exercise... take your pick.

Among other things prime factors have cryptographic applications. Also it's a great way to increase your knowledge of a language... among other things I discovered that javascript floating point handles these calculations just fine but after 15 places some numbers have the last digit(s) become 0 e.g. parseInt("10000000000000000",10)+1 == 10000000000000000... it's the only floating point problem I found with this exercise. Other than that the code works well and the app below will factor numbers in real time as you type (and check the results to make they're valid).

Give it at try:

Enter a number to get it's prime factors:

As you can see it's pretty darn fast... results may vary but if you have a recent computer then there shouldn't be a noticeable lag on numbers up to 15 digit primes. Primes take the most calculations; they are verified by attempting division by 2 and then every odd number from 3 to the square root of the number being factored.

Using this method determining that 1243245576856897 is prime only needs 17629844 iterations which takes ~2 seconds on my laptop. 5467154436746477 only takes 5 seconds. If you did every calculation up to half of 5467154436746477, which is what I did at first, it would take a year to verify it was prime (assuming you could keep the javascript running that long).

The amazing thing is that the code that does this is small... This little recursive function does all the calculations:

function primeFactorization(num){
  var root = Math.sqrt(num),  
  result = arguments[1] || [],  //get unnamed paremeter from recursive calls
  x = 2; 
  
  if(num % x){//if not divisible by 2 
   x = 3;//assign first odd
   while((num % x) && ((x = x + 2) < root)){}//iterate odds
  }
  //if no factor found then num is prime
  x = (x <= root) ? x : num;
  result.push(x);//push latest prime factor

  //if num isn't prime factor make recursive call
  return (x === num) ? result : primeFactorization(num/x, result) ;
}

If Software Teams Made Cars

2011-04-22T18:56:00.003-04:00

...these requirements would be accepted:

Must have 4 Wheels
Must have brakes and steering
Must have a way to get in
Must be reddish orange

...this mock-up would be approved:

photo by marcmos

...the developers would plan to make this:

photo by jarm13

...the business would expect this:

photo by djbwhizz

... the customers would actually want this:

photo by earthworm

... there would only be enough time to make this:

photo by jdueck

And the kicker is... all the "defects" would have to be fixed while it was being road tested!

Note: Regarding this post... gross exaggerations and stereo types have been used liberally in a fictional context for comedic effect. Any similarities to the development practices of employers past, present, future, or in parallel universes is purely coincidental, depressing, and sad.

The Devolution of Code

2011-04-18T02:14:00.000-04:00

The more intense the demands of business or market forces acting on a system, the faster it will change. Unlike in life though, natural selection in software does not favor evolution into a higher state; instead code naturally devolves.

Photo by MangPages on Flickr

Why? Because writing bad code is easy and writing good code is hard. Because with every change to the code there is an increased chance for a reduction in quality. Poorer quality code is more likely to survive because it's difficult to understand and time consuming to fix. It is also more likely to devolve further with future changes. Without intervention a downward spiral of code quality occurs.

The rate of decay of a system is determined by three factors:

The quality of the team
The speed of development
The size of the system

The Quality of the Team

A weak team can't develop a strong code base; it's just impossible. Beyond the maturity of the team and knowledge of the individual members, both the team and their manager must have a strong commitment to the internal quality of the project... because they're the only ones that can. No one else knows what trade offs have been made to meet deadlines. No one else knows what pieces of code have become muddled and difficult to work with over time. So too, no one can advocate for code quality except the team.

Speed of Development

The faster the project moves, the less time there is to discuss, design and refactor the code. A emphasis on time to market over quality and design can pay off for a little while but only at the expense of an ample amount of technical debt. Problems occur when management (usually upper levels) doesn't recognize the cost of this initial boost of speed (i.e. time saved must be paid back later with interest) or worse yet, expects it to be sustainable.

Unfortunately prioritizing speed (the rate at which new features are added) produces ever diminishing returns because reducing internal quality slows things down. As the project becomes more brittle defects increase and features become harder to add. A vicious cycle ensues.

Of course this could be easily fixed if the business allowed time to clean up the codebase by drastically reducing or halting time spent on new development. But that's unlikely to happen. You see the business views development time as an expenditure not an investment. From their stand point they've already paid for these features once. They're done! They work! Time spent refactoring them only increases the cost of those features. From the business view point you're asking them to pay for the features twice! Crazy!

Size of the System

The larger the system grows the more time it will take to add features, the longer the learning curve will be for new people and the more people you will need to handle the work load. The less code you write the better, because the smaller the code base is, the less code has to be maintained and the more well-designed/well-factored the code that's there is likely to be.

Because of this an effort must be made to fight unnecessary features, get rid of seldom used features and otherwise constrain the size of the system. You have to pick your battles. That new feature that's going to add 10,000 lines of code, turn your code base to swiss cheese and only be used by 3% of users... that's the one you better fight.

The bottom line is, do what you can to stem the rising tide of code; even small victories can have a major impact down the road.

How to Fix this Mess

You need to focus on code quality as much or more than you focus on defect count. While a rising defect count can be a symptom of reduced code quality, defects are actually a measure against requirements not code quality. Given enough effort it's possible to get a project with abominable code quality into a defect free state; it just really hard to do and even harder to keep it that way.

The sad truth is that in most places a balance is reached. Projects become mired in mediocrity and just enough upkeep is done on them to keep things from falling apart completely. Developers who have been on a project like this a long time tend to be disheartened as years of disappointment and frustration can quench the most ardent fire.

Fortunately there is an ebb and flow of programmers on every team and you can use it to your advantage. Each programmer that leaves offers you a chance to make things better. Find good people, passionate people to replace them. The right person can stoke the fires of existing team members and breath new life into the team. Set them loose and help them break the status quo.

Set standards and expectations early and review them often. Do whatever you can to keep the speed of development and the size of the codebase manageable. Every week try to make things a little better and don't give up.

Increasing Eventual Efficency

2011-03-18T00:26:00.009-04:00

David Brion over on the Inquisitive Coder recently posted a great article on measuring developer productivity. In a nutshell the problem he poses is: given two developers with similar tasks over time, if one developer averages 4 hours more per task than the other then who is the better programmer?

Photo by Sherlock77 on Flicker

It could be that the programmer who gets it done faster has more defects. It could be the one who spends more time leaves fewer defects and has cleaner, more maintainable code or it could be they took longer because they overcomplicated the code or took cludgy shortcuts. Scenarios abound.

Eventual Efficiency

The article proposes an interesting measure of productivity called "eventual efficiency" which is how a developer's code impacts the team and the project down the line. Write buggy, brittle, or overly complicated code then your eventual efficiency is low. Write simple, solid, maintainable code and your eventual efficiency is high. Unfortunately he concludes the article saying that at present there is no way to measure eventual efficiency.

While I agree there's no way to put a hard number on it I think that it's possible to get a good idea of the eventual efficiency of each developer. I also think team members can be coached to improve their eventual efficiency.

Steps to observing and increasing eventual efficiency:

#1 Managers Should Code

There's no better way to get a clear picture of the state of the codebase than being in it and fixing defects from each of their team members will give managers an eye into their strengths and weaknesses and show you what they need to do to improve. I've known developers that can excuse their way out of problems so smoothly and cleanly you'd swear they worked in sales; but the code doesn't lie.

#2 Managers Need to Review Code

Managers need to regularly review check-ins of significant size. This will fill in a lot of blanks, for instance:

What standards need to be reinforced and what tendencies need to be dissuaded?
Who's complicating the code and who's simplifying it?
What types of coding does each person do best or, worse case, where do your weaker people do the least damage?
What coaching does each person need? Who needs an at-ta-boy (or at-ta-girl) for a job well done?
Who needs more frequent code reviews?

Am I saying that managers need to spy on their developers? No, spying is in secret, what I'm saying is trust, but verify, and let them know you're doing it. Managers need to keep their developers accountable. When they do thoughts like "well this is kind of cludgy, but it'll do" or "This turned into a mess but I really don't have time to refactor" will be more easily curbed because the developers will know their manager will be reading their code.

If you're a manager you likely don't have time to be part of the the formal code review process, but spot reviewing code from each of your developers will keep them in sync with the team and help you let them know when adjustments as necessary.

One warning. Coaching should not be a black mark that hurts people come review time. In fact those who respond enthusiastically to coaching and quickly study to fill gaps and modify their behavior should be the first up for raises. The managers goal here is to build a strong team and a solid code-base and people who work with them toward that goal need to be rewarded. It's the team and the codebase that matter, period; no games and no favorites.

#3 Managers Need Someone To Lean On

Yes I realize #1 and #2 can be difficult to accomplish for many managers by themselves either because of lack of skills or lack of time. That's why managers need a good team lead to them in the loop to the status of the team.

The team lead shouldn't need to be harsh with people; that's the managers job. Instead the team lead should set the tone of the team. They should write solid code and promote standards and best practices and lead by example.
While the team lead should be experienced, they need not be the most productive or knowledgeable person on the team, in fact those people are often too busy to lead effectively. I'm not saying they don't need to be knowledge and experience — they do to hold the respect of the team — but the most critical thing is that they know how to relate to others and are passionate about the quality of the team and the code-base.

Conclusion

It will take a concerted effort to stay in tune with the team and the code but between the efforts of the manager and the team lead a solid view of the eventual efficiency of each developer should emerge. From there consistent coaching and feedback should increase the eventual efficiency of the team.

Site Redesign Complete: Come and See

2011-03-03T00:30:00.003-05:00

If you've been by the site the past couple of days (particularly in the evenings between 9pm and 12pm EST) you've probably noticed continual changes being made to the design. It wasn't the ideal way to do it, but it did put a fire under me to get it done... and well, it's done. As a preview for those who subscribe to this feed here's the new logo (I'm really quite proud of it):

If you do subscribe I'd like to invite you to drop by and check out the site... and please, Please, PLEASE leave a comment on this post and let me know what you think of the redesign. Thanks.

Quotes for Software Developers #1: Change

2011-02-23T17:57:00.014-05:00

"It's better to put a stake in the ground and get started than it is to sit around waiting for perfect inspiration, the right timing and an unassailable position of strength. It's easier to navigate when you're moving. It's easier to criticize when you are standing still."
John Summers, HR Examiner

My take on it:

Everyday there are new opportunities for change. Is something on your team less than ideal? You be the one to try and fix it! Not being challenged at work? Do something on your own: learn something new, start a blog, create an App, or get involved in open source; challenge yourself.

Whatever your frustrations or your woes, stop whining and get moving. What are you going to do today to make things better?

Extending LINQ to Objects

2011-02-22T02:50:00.027-05:00

To start off there seems to be a fair bit of confusion about what LINQ is because a lot of related technologies fall under that name. Here's a short list of Linq Technologies:

Linq Query Expressions - A declarative syntax similar to SQL. At compile time the standard query operators in the query expression get mapped to method calls.
Linq Providers a.k.a. Linq to [whatever] - whether it be SQL, XML, or custom providers these are data providers that work with Linq Query Expressions.
Linq to SQL Mapping (Not to be confused with the Linq to SQL Provider) - Microsoft created these specialized mapping tools for SQL Server though as you may have heard they will not be available going forward. Microsoft is dropping them in favor of the Entity Framework.
Linq Extension Methods - Each Linq Provider comes with a library of extension methods. Some of them match up to standard query operators and others have to be called using method syntax.

What I'll be covering is adding extension methods LINQ to Objects so that when you include the "System.Linq" namespace your new methods automatically get included. Any methods that are added should be in line with the other extension methods and should be carefully chosen; it would be very easy to clutter the namespace.

In the application I'm working on I need to check lists of objects for duplicates; if a duplicate is found then the list is rejected. Adding an efficient hasDuplicates method to the Linq namespace seems like a good option. Here's the code:

using System.Collections.Generic;

namespace System.Linq
{

 public static class DuplicateExtension{

  public static bool HasDuplicates(this IList list, Func areEqual)
  {
   for (int index1 = 0, lastIndex = list.Count() - 1; index1 < lastIndex; index1++)
   {
    for (int index2 = index1 + 1; index2 <= lastIndex; index2++)
    {
     if (areEqual(list[index1], list[index2]))
     {
      return true;
     }
    }
   }
   return false;
  }

  public static bool HasDuplicates(this IEnumerable list, Func areEqual)
  {
   for (int index1 = 0, lastIndex = list.Count() - 1; index1 < lastIndex; index1++)
   {
    for (int index2 = index1 + 1; index2 <= lastIndex; index2++)
    {
     if (areEqual(list.ElementAt(index1), list.ElementAt(index2)))
     {
      return true;
     }
    }
   }
   return false;
  }

 }

}

I created an extension method first for IList, which is what I needed, then copied it over and made some modifications for IEnumerable (since in general Linq to Objects methods support IEnumerable). Neither of these have been tested yet for efficiency and I suspect the IEnumerable one in particular can be improved upon.

Other than that everything is pretty straight forward. All I did is create extension methods in the Linq namespace. The first parameter (preceded by 'this') indicated the interface to be extended and the namespace was the namespace to be extended, in this case System.Linq. The static class name is not referenced when calling the extension method so it can be named anything you like. I guess the most surprising thing about digging into this was finding out there wasn't more to it.

The extension method above is very flexible and can be called as follows:

var dupicateFound = list.HasDuplicates((a,b)=> a.ToLower() == b.ToLower()

Given a list of items of type T then you pass in a method compare two objects of type T to determine if they are matched/duplicate. Here I'm passing in a lambda expression that takes two parameters of type T and returns a bool. In this simple example the signature is Func<string, string, bool> though you can work with lists of any object type and pass in a method that uses any sort of match logic you like.

Complicator's gloves

2011-02-19T22:44:00.013-05:00

Anytime we're discussing over-engineered code around the office it's a safe bet that someone will mention complicator's gloves. Picture a pair of magical gloves that, when you wear them, bestow you with the ability to complicate anything you touch.

Photo by Arts

Complicator's gloves are synonymous with a mindset that is always looking for interesting and novel approaches and is the antithesis of K.I.S.S. methodology. I even use the term now in place of my all time favorite aphorism. The phrase comes from a TheDailyWTF story entitled The Complicator's Gloves that struck such true note with some of the developers where I work that it became part of the vernacular. While the usage in the story is slightly different, the concept is the same.

The Complicator's Gloves story is a story of people who revel in abstraction, indirection and patterns viewing them as fun little toys to build puzzles out of instead of what they are: key tools for reducing complexity. Often complicators justify their bad behavior by trumpeting how much lower the implementation overhead is for themselves (while remaining oblivious to the huge implementation and maintenance overhead they create for everyone else).

All programmers have a tendency to slip into the complicator's mindset from time to time and though most developers fight this tendency it's really easy to grab hold of a shiny new hammer and see every problem in the code as a nail. Mentally you look down and it's like "Complicators gloves? How did those get there?". When that happens, when you get that mental nudge that you are going astray, you need to mentally check yourself, take the complicator's gloves off and begin again.

Program like Hansel and Gretel: Leave a Trail

2011-02-12T23:05:00.012-05:00

There's a lot to be learned from the story of Hansel and Gretel (like don't be evil or you'll get shoved into an oven) but the main thing that developers can take away from the story is the importance of leaving a good trail.

Here's the ultra-condensed version of the story:

Times are hard and there's not enough food for the family.
The children's father takes them in the woods and leaves them to die.
Fortunately Hansel left a trail of stones and they get home safely.
Again father takes them deeper into the woods and leaves them.
This time Hansel left a trail of bread and it gets eaten by birds.
Without a trail they're lost and get in a lot of trouble with a witch.

At this point you're wondering where I'm going with all of this, let me explain.

I'm living with a code base that uses a lot of very complicated code to do very simple things. It's not everywhere but there are several areas, mainly written by an overly intelligent former team member, that are pure hell to find your way through. You're stepping through the debugger and then... nothing. Something magic happened and the debugger didn't step you into it. There's no trail to follow; you're lost.

These nasty sections of code are the woods.

Something as simple as adding a few values to a drop-down means you have to trace back through six layers of javascript, including several callbacks and a proxy object, 5 layers of c#, a stored procedure and some nested SQL functions all to find out that a simple table change in the database was all that was needed. Wouldn't it have been nice if someone had left a comment saying "To change the values in this drop-down edit table x... oh and reset the app pool to get the changes to show up".

Lesson one is that if you're one of these hyper-intellectuals who enjoys building logic puzzles in code, don't. Instead design things so that there is an obvious trail through the code for us mere mortals to follow. I know, I know... simple is hard; let that be a challenge for you.

Lesson two is that as you find yourself hacking your way through the woods and get to know your way around, leave copious trail of comments for others to follow. Your team will thank you for it and who knows you may find your way through here again some day.

Lesson three is that not following lessons one and two is evil and evil people get shoved into ovens at opportune times... you've been warned!

Confession time: I worked my way through that nasty drop-down code on Friday and was so worn out when I finished at the end of the day that I didn't comment it. Come Monday I'm going to trudge back through there and leave detailed comments in the sections of code where the trail ends. Time to practice what I preach.

The Javascript void operator explained

2011-02-10T14:51:00.187-05:00

I haven't seen a clear explanation of why we have the void operator in javascript so I decided to do a bit of research myself.

Picture (of Javascript Graffiti Art?) by S. Mason

The javascript void operator was introduced in the Javascript 1.1 specification. The explanation of void states:

The void operator takes an expression of any type as its operand, and returns undefined.

This is pretty straight forward though it's not entirely clear why that would be useful. One thing this clarifies is that void is an operator (not a function). Because of this void(0) is technically incorrect though in practice implementations allow it to be used this way it should be used without parentheses e.g. void 0. Also because it is an operator you can't assign it to a variable. This means that "var a = void" will throw an error.

Another thing that's important is that when it the specification mentions undefined it is not talking about the undefined keyword which is a global variable that wasn't introduced until javascript 1.3; instead it's talking about the undefined type which is a primitive type like string and number in javascript.

I also found another mention of void in the document:

When a JavaScript expression is evaluated (executed), the result denotes one of
three things:

a variable (in C, this would be called an lvalue)
a value
undefined (the expression is said to be void)

From this you can tell that undefined is strongly related to concept of void in C. In some early coding examples elsewhere I found code that said "if(a === void 0)", so it looks like early on (in practice if not by intention) void was a common way to get the undefined value for comparison. For instance the following will display true: javascript:alert(undefined === void 0).

This can still be useful. As of the currently implemented specification the undefined property doesn't have to equal undefined, so javascript:undefined=4;alert(undefined === void 0) returns false (though in IE9 and Firefox 4, per the ECMA 5 spec, undefined is no longer writable, so this returns true). Because of this, if you are writing code that will be executed in someone else's web page (an ad perhaps) you may want to use void 0 in place of undefined. As more browsers support the ECMA script 5 specification this will be less of an issue.

Some sources I've read suggest the sole reason that void was put in specifically for anchor tags (a hack that is so often debated), but I have found no evidence of that.

I hope this information helps though, outside of anchor tags, I'm still unclear on it's real usefulness. If you have any coding examples that show where void is helpful please share.

Brown field software: The five rules of code maintenance

2011-02-05T23:41:00.022-05:00

As previously described (picture a cow pasture) brown-field development is the maintenance of an established project after the initial developers, working under tight time constraints, have pooed all over the place.

Photo by Fabio Rava

With that in mind here are 5 simple rules to help you clean up your code base:

#1 - Always leave the code cleaner than you found it.

This is both common courtesy and common sense. Think of the most brittle and painful code you've ever worked with. It didn't get that way all at once. Person by person, edit by edit, deadline by deadline it slowly descended into a blackhole of entropy.
A vicious cycle ensued: the more brittle that code became, the longer each change took and the more the developers complained there was no time clean it up. Do yourself a favor and clean as you go... you and your team will be the better for it.
#2 - Never clean up code that will not be tested.
Cleaning up code that's not going to be tested is like playing Russian Roulette; if you clean up enough code eventually your luck will run out. That's why it's critical to only change code you know will be tested.
If you're fixing a bug or adding a feature that code should already be covered by either unit tests or human testers (QA/QC), so you're golden. If you see other code that's in desperate need of a clean up but isn't covered by tests then either arrange for tests or leave it alone.

Whats the worst that could happen? A really nasty subtle bug slips into production and isn't immediately caught. Depending on the application this may be a minor inconvenience or the end of the world. Manage your risks accordingly.
#3 - If you mix your refactoring with your maintenance its not refactoring.
Refactoring by definition is changing structure without changing functionality. Making structural changes while making functional ones is a sure way to find yourself at a dead-end that requires you to roll back everything you've done (or worse yet end up with a brittle working mess that's near impossible to straighten out).

Refactor. Test. Check-in. Repeat as necessary. Then make functional changes.

Its best to refactor first for clarity. This makes the code easier to understand and gives you a solid place to roll back to. Once that's checked in refactor again to make it the specific pieces that need to be changed easier to work with. Often this means isolating the code the code that you will change in its own functions and even adding pseudo code to note the expected changes. Check in again.
Make functionality changes, test and check in again. After your changes are complete you can refactor again if needed to clean up your own mess.
#4 - Incremental improvements are more stable than large sweeping ones, don’t try to fix everything all at once.
Small changes are easy to understand, easy to validate and easy to undo if they cause problems. In systems of any complexity large changes are difficult to understand and are likely to have unintended side effects which will be difficult to identify and resolve.
#5 - If you have taken the time to understand difficult piece of code then take a little more time to make it more clear.
This may be renaming variables, functions or classes to match their purpose or more complicated refactorings or it may be as simple as adding comments to the code.

Following these tips consistently over time (especially if done as a team) can make your brown field a cleaner and a more pleasant place to be.

If you have any tips you'd like to share please leave a comment.

Green field software: five rules for writing maintainable code

2011-02-04T23:53:00.025-05:00

If you're not familiar with the term green-field development the analogy works like this: the field is the project, developers are cows and poo is other people's hard to maintain code. Brown-field development is code maintenance and is so named because other developers have already pooed all over the place.

Photo by Robert Crum

If you're lucky a few times in your career you'll get to take on a new project from scratch. That's green field development.On a smaller scale it could be a new control, web page or application feature that doesn't really depend on the existing code base.

Keeping this in mind here are five simple rules to make your code easier to live with over the long term and make the field a little less brown for those who come after you:

1) Don't write something in one line of code if two lines is more easily understood.
Having multiple operations on a single line is a code smell; it makes code more difficult to understand and harder to debug. Given a choice between conciseness and clarity, choose clarity.
2) Name things well; rename them early and often.
How well things are named plays a huge role in the maintainability of the code. If you find that the name of a variable, property, function or class doesn't match its purpose then rename it; the earlier you do this the easier it will be. If you find a function or class is difficult to name that's often a sign that it's not cohesive and/or needs to be refactored.
3) Avoid premature optimization.
Optimized code tends to be less readable. Given a choice between clarity and performance, choose clarity unless speed has proven to be a problem. If speed becomes a problem identify your bottleneck, fix it and comment the optimization explaining both how and why.
4) Follow the style of the existing code where possible.
Consistency makes code easier to understand. Teams should try to converge on a single style. As a team member let go of your preferences and emulate the status quo where possible. If the status quo sucks then work with your team fix it.
5) Keep the code as simple as possible but no simpler.
When solving a problem in code look go for the simple solution first. Simple solutions are easily maintained and easily changed. Having explored a simple solution and understood the problem it's easier to refactor to something to more complex if necessary. In contrast novel solutions tend to be hard for others to understand and maintain... pursue those on your own time, for fun.

What about you? Are there any tips you have for writing maintainable code?

Clean up JSLint with LintBrushJS

2011-01-17T22:58:00.021-05:00

Before I can talk about how LintBrushJS came into being, I first have to talk about JSLint.

I've been addicted to JSLint for some time now though I occasionally find it frustrating to use. Currently I'm doing maintenance on a lot of really big JavaScript files that have never been through JSLint. After clearing all the errors that stop the file from processing I inevitably end up with 200 to 400 errors.

Some of the errors that JSLint provides I consider really important but there are others that can wait (like all the == and != errors). Unfortunately its hard to sift through the less critical errors to find the ones I want. Also because JSLint doesn't give a count of the errors its impossible to know if any changes I make to the file introduce new errors.

That's why I created my first FireFox add-on LintBrushJS to clean up the JSLint output and make it more livable. LintBrushJS refactors the JSLint output by grouping like errors together and giving you a count of each group and a total count for page.

Here's some sample output:

Among other benefits this allows you to work through like errors at the same time and track your progress as your error count slowly makes its way to zero.

I'm a huge fan of Douglas Crockford, who created JSLint. Overtime he has worked to make JSLint more and more stringent about errors — an effort I wholeheartedly agree with. I have however, felt frustrated from time to time that those efforts have made my job more difficult, often when I have the least amount of time to spare. There are a lot of people that I know that shy away from JSLint for just those reasons. I hope that LintBrushJS helps make JSLint more manageable and helps it see wider adoption.

LintBrushJS started as a GreaseMonkey that I wrote with identical functionality (ironically this project was both my first GreaseMonkey script and my first Firefox add-on). When I finished the script I wanted to share it with others on my team and but distributing the script and having everyone install GreaseMonkey seemed a poor way to share it. So I decided to make it into an add-on. It was a fun experience that I'd recommend to others (and not so hard as I'd feared).

I hope you enjoy using LintBrushJS as much as I have (and to to Crockford, thanks for an awesome tool).

Cleaning up Bad Javascript with JSLint

2010-12-31T00:34:00.020-05:00

The web app I'm working has a ton of Java Script. It was written by many people, over a short period of time, under incredible deadlines. To make matters worse the direction of the product changed several times during initial development, which required things to be shifted and duck taped together quickly with no time for cleanup. Needless to say, the code base is a mess.

So what's the answer to cleaning up a brittle Java Script code base?

JS Lint!

JSLint is life, JS Lint is sanity. Yes it can be a huge pain and even it's author Douglas Crockford notes "JS Lint will hurt your feelings", but JSLint is the first step in solidifying the most horrid code base.

When I run a file through JS Lint for the first time I inevitably find several problems:

Unreferenced code - it's very difficult to make sense of code that has unused functions and variables; how can you know what's relevant? JS Lint will flag these for you so you can remove them.
Bad practices - While I'm sure JS Lint's list of bad practices will include things you disagree with, it's worth it to fix all of the minor errors so that the truly horrific things will be revealed. Be very careful with your changes though. When JS Lint says you should use !== instead of != for comparisons doesn't mean that's the exact change you should make.
```
if(a != 0) could need to be changed to any of the following:
      if(!a)//excludes any falsy values (NaN, '', false, 0, null, undefined)
      if(a !== 0)//excludes 0
      if(parseFloat(a,10) !== 0)//excludes 0 and '0', but not '' or 'abc'
      if(parseInt(a,10) !== 0)//excludes 0, '0', but also 0.13, '.13'( truncated .)
```
Undeclared global references - JS Lint flags undeclared global references. Some of these will be objects that are missing a declaration, some will be mispelled variable names, and some will be intentional global references to other js files. Once you comment your intentional globals JS Lint will no longer flag them. I prefer to comment my globals like this:
```
/*globals
Authorization, ApprovalTypes, //Authorization.js        
jQuery, $, //jQuery 
window //browser
*/
```

Once you've gotten your file to pass JS Lint and tested your changes then you need to do a check-in. This gives you a stable starting point to begin refactoring the code. I'll admit this can be dangerous but rerunning the code through JS Lint every so often as you're making changes catches a lot of issues. Everytime you revisit a file to make a change refactor it a little more. If the function you're working on is too big and too confusing then extract out its different responsibilities into cohesive methods. Clean up the code until it makes sense and you can reliably make your change.

It is critical to resist the temptation to clean up code that will not be tested. Don't fool yourself into thinking you won't introduce bugs, you will. That's why it's equally critical to take advantage of the opportunity to clean up the code while you're making functional changes. This will allow your clean up efforts to be tested. Don't Pass up an opportunity to clean up code while you're in it... that's how the code became brittle in the first place.

New Team Members and the Five Stages of Grief

2010-12-18T00:49:00.007-05:00

After years of watching new developers join teams (and from time to time being one myself) it occurred to me that the five stages of grief apply to this transition as well.

Denial – "This code makes no sense… I must be missing something."
Anger – "I can’t believe this $#!%. What kind of moron designed this?"
Bargaining – "I realize the code works but it’s brittle, confusing and impossible to maintain, can’t we refactor it a little at a time? ... What do you mean it’s too critical?"
Depression – "The code base is crap and they won’t let me fix it… I might as well shoot myself now."
Acceptance - “Hi you must be the new guy… Yeah, I’ve been here a year now… Oh that code, yeah it's not ideal but it works… No we can’t change it, it’s too critical and there's no time... Hey, there’s no point in getting upset about it, it’s just a job.”

Using SQLCE with the Entity Framework and Linq to Entity: Part 1

2010-04-11T13:16:00.001-04:00

SQLCE is a compact database that is click once deployable and runs as part of your application (as opposed to SQL Express which has a much larger footprint and runs as a service). To make SQLCE so small and light weight a lot of things have been pulled out. Most notably its missing stored procedures but fortunately we can use LINQ to Entity to compensate for that.

So lets get started.

Create a new project. For simplicity sake I created a class library.

Add a SQL CE Database

Just click finish when the wizard appears.
Your Project should now look like this:

You can go ahead and delete AppDBDataSet.xsd… we won’t need it for what we’re doing. You can delete class1 too while you’re at it.

Now your project should look like this:

Now double-click on AppDB.sdf. You should be taken to your sever explorer which should look like this:

Right click on Tables and select Create table and enter the following values:

Press OK to accept the parent table. Now add another table.

Press OK to accept the child table. Your server explorer should now look like this:

Now right click on the child table and select table properties and then select Add Relations.

Enter the information below and click Add Columns

Your Table Relationship be listed as below.

Now click Add Relation.

Congratulations you’re now done with your SQLCE Database, now let’s create an entity mapping for it.

Now return to your solution explorer, right click the project file and select add new and select ADO.NET Entity DataModel (see below)

Click Add, then click Next until you get to the last page.

Click the check box for Tables and click finish. Your Solution Explorer should now look like

Congratulations your entity model has been created. Click on AppDBModel.edmx and let’s take a look at it:

Now right click on the class name Parent in your code and select refactor / extract interface (select all). Your code should now look like this.

And you should have a new interface that looks like this.

Next follow the same steps to create a Child class and interface. Your solution window should now look like this:

Ok, now you’ve generated interfaces for your entity classes and you can also use your partial classes to extend your generated entity classes without worrying about anything being lost when your entity classes are regenerated and updated.

You should now be able to access your data using standard linq to entity queries.

In Part-2 I'll cover CRUD operations using the Entity Framework and Linq to Entity.

Why Twitter and Facebook are popular and Blogging is not

2010-03-04T23:13:00.005-05:00

It's seems like every month or two someone asks the question "Is Blogging Dead?". It's not hard to understand why. Abandoned blogs litter the landscape like burning vehicles in some post-apocalyptic-war movie.

Photo by Nir Nussbaum

There was a time not so long ago when it seemed everyone had a blog. Some would be bloggers made it only days or weeks. Others lasted several months to a year before giving up. The vast majority of blogs, however, never saw their first anniversary, let alone their second.

It has nothing to do with talent. You'll find that quite a number of talented writers gave up on their blogs after only a handful of posts. The truth of the matter is that even if you love writing and even if you choose a broad topic that you're excited about, producing consistent, well thought out, meaningful content for an extended period of time is mind-blowingly more difficult than most people imagine.

And this is the reason why Facebook and Twitter are so popular. Because bullet point updates, random thoughts and links to other peoples content are orders of magnitude easier to produce. Even within these limited constraints people many people still find it hard to stick it out because even micro content of any quality is difficult to produce consistently. Faced with this truth they resort to posting mindless updates on what they had for lunch or dinner or where their at now... no now... no now...where they're at now... no now... now... now... now. Annoying isn't it. Worse yet, many give up on producing content all together and choose to Facebook-spam their friends with Mafia-Wars and Farmville invites.

Don't despair though, blogging isn't dead as some would have you believe. Despite the fact that blogs have an infant mortality rate magnitudes worse than the poorest third world country blogging is just as alive as it ever was. In fact I would go so far as to say that nothing about blogging has changed.

Blogging has always been a numbers game. For every X number of people interested in blogging a certain percent of people will start a blog. A certain percent of those will make it a month or a year and a certain percent of those will actually turn into sustainable blogs. That process and those percentages haven't really changed.

What has changed is the number of people starting blogs. During the blogging boom a switch was flipped and anyone who wanted a blog could get one instantly. Those who started a blog told their friends, who told their friends, until within just a few short years all of the people who were likely to start a blog had already been exposed to the concept and the math predictably worked itself out. You're seeing fewer new blogs started now simply because there are fewer new people exposed to the concept.

And the current massive die off of blogs? It's not because other media have replaced blogging as a medium but because a massive die off was inevitable given the massive numbers that went in. I predict that less than 1 in 50,000 newly started blogs will make it a decade and those numbers were inevitable even if Twitter and Facebook had never come along.

No matter how hard core and fanatical the crowd following something, if it requires any effort at all you're going to see a very predictable die off over time. It's why there aren't crowds of 50 year old surfers. It's why the gyms aren't packed with gray haired yoga practitioners with the flexibility of a Chinese noodle. Consistency over time for anything worthwhile is very very hard.

Blogging is an intensely personal and selfish endeavor. People invest the time in it because it meets a practical need or because they find it fulfilling in some way. The second that stops being true they'll quit. Even the most hard core and popular bloggers will eventually write their last post as life and circumstances change.

Noted blogger Joel Spolsky recently announced his departure from the blogging world. He made it 10 years. His reasons for quitting? It's time consuming and no longer provides the marketing benefits to his company that it once did.

Kathy Sierra, one of my all time favorite writers and speakers, gave up her phenomenally successful blog after less than a year due to death threats and online harassment.

I had thought that long time blogger Dan Appleman had given up blogging but despite sometimes going months between posts it looks like he's still at it.

Blogs will come and go but blogging is here to stay.

WPF and Expression blend - a marriage of necessity

2010-02-07T23:24:00.004-05:00

I've been using VS2008 WPF(Windows Presentation Foundation) and Expression Blend lately at work and I'm loving the combination. If you've been struggling with doing design work with WPF in Visual Studio it's because Microsoft took all of the tools that make it easy to work with and packaged them as a separate application called Blend.

Of course you could use either tool to create a complete application but I wouldn't recommend it.

Blend is painful to code in - it has poor intellisense and lacks tools like refactoring and namespace resolution - but what it lacks in coding it makes up for in design. It has all kinds tools and shortcuts for creating, manipulating and consuming controls, resources and styles. In particular designers will love that all of their design work in Blend is created as vector graphics and so will render flawlessly no matter what resolution they are rendered in.

Visual studio is of course the preferred coding environment but it is severely handicapped in when it comes to design. It lacks UI basics like a font-chooser, and all of the other nifty Blend tools that make design so pleasant. If you choose to use Visual Studio for design the easiest way will be to dive head first into XAML and do all your design there. Actually hand coding XAML is how I started out and it gave me a great deal of insight to how things worked and what could be done. I still do most of my animations by hand there.

One thing that I finally get is Microsoft's vision for splitting design and development. In a development shop where you have Joe Coder who hates design and Joe Designer who despises code, these tools can work well together. The developer can create a functional but ugly UI in Visual Studio and pass it off designer who can skin it, style it and turn it into a work of art in Blend then hand it back to developer when he's done. It works pretty seamlessly.

Of course as one person doing both design and programming it's a huge pain. I find myself constantly switching from one app to the other and it wears on you after a while. Also if you're doing any hand coded XAML you have to familiarize yourself with how Blend marks everything up or you can have trouble editing things using it's UI tools when you're done.

Anyway, I'd like to write some tutorials and compare and contrast the two further if I get the chance... I'll see what I can do.

Boycott Ajaxian: Punish Hotlinking and Bandwidth Theft

2010-02-01T15:54:00.007-05:00

Update: Well this may have been the shortest, smallest Boycott in history. One person commented that they Unsubscribed from Ajaxian before Dion Almaer from Ajaxian fixed the problem and posted a comment on Roman Cortes blog apologizing. Boycott over, go check out the cool CSS only Rolling Coke Can effect that instigated everything.

Popular website Ajaxian needs to be punished for their blatant Hotlinking and Bandwidth Theft from blogger Roman Cortes website. Roman recently unveiled a mind-bending CSS only Rolling Coke Can effect which Ajaxian hotlinked to in an iFrame, stealing both bandwidth and visitors from him. They have yet to removed the offending content-frame from their home page despite Roman rick-rolling them by removing the content and changing his page to the following content. Sadly this means that you can no longer see what an awesome effect this was (check out his site though for other amazing effects).

I hate to see a large site step on a smaller site just because they think they can. Let's show them they can't! I'm calling for a Boycott of Ajaxian until they remove the link and publicly apologize on the front page of their blog.

Ajaxian Boycott:

If you subscribe to them, unsubscribe.
If you follow them on twitter (I assume they're on twitter), block them.
If you visit their site, stop.
If you've linked to them then either disable your links or point them here (or to your own post where you've joined the boycott).

Let's show them that we take care of our own.

Disagreements are WONDERFUL

2010-01-26T16:50:00.025-05:00

Call me weird but I love when my piers, people that I respect, disagree with me on technical issues. Here's why...

Photo by Stuar Barr

Assuming we're both professionals the most common outcomes are:

I find out my logic is flawed and learn from it.
They find out their logic is flawed and learn from it.
We discover that each of us are being logical and reasonable but that we are in dispute about facts, priorities, or assumptions (which we will hopefully be able to resolve and learn from).
We find our differences are a matter of deeply held belief and not wholly constrained by logic (think religion, politics or programming language preference). We understand each others views, agree to disagree and move on.

I don't like to leave a discussion without one of these things happening. To some people this can be taken as being pushy, and I guess it is, but what I really want is for them to push back. If you can show me where I'm wrong, I'm perfectly happy to admit it and I'll quickly become a vocal champion of your side of the argument. Even if we can't agree, each discussion either strengthens or changes our views about the subject and we come out of the discussion with a better understanding of what we believe and why.

All of this hinges on the assumption that both people act like professionals. Here are a few things you can do to help:

#1 - The moment things get a little heated tell them you respect them and why.

Obviously you don't have to do this every time, but the first time you push a discussion with someone this can help a lot. If you value them as a logical, intelligent human being then let them know it. This cuts down any defensiveness that comes from feelings that you're trying to make them look bad or don't respect their opinion. And if you don't respect their opinion, if you think their an idiot? Walk away. There's no reasoning with an idiot. If you're dealing with an idiot, I say again, just... walk... away.

#2 - Quickly admit to being wrong about any point they prove you're wrong on... even if it hurts.

The more points you can let go the more they'll be willing to do the same. If you want to be dogmatic or save face then become a public speaker or write a book (and by all means quit having conversations all together) otherwise be an adult, swallow your pride and admit when you're wrong.

#3 - Restate what they've said in your own words and point out any views you agree on.

This gives them the opportunity to correct anything you've misunderstood and gets them to concede the points you agree on. The more you can agree on the less heated the discussion will be.

#4 - When you're sure you understand them and they understand you then you need to let it go.

Even if you still disagree, even if it's tearing you up inside, you need to let it go.

Letting go is my biggest problem. If we can't agree or at least fully understand each others viewpoints then that says to me that either I haven't explained my view well enough or I haven't asked the proper questions to fully understand the other persons view.

I like to see my professional world in black and white. The bit is on or it's off. Everything needs to add up. And when things don't add up? My instinct is to press until they do. And every great once in a while I press when I should let go... profuse apologies, I am working on it.

Sadly, letting it go is not the problem for most people... it's having the discussion in the first place. Some people feel you're putting them down if you
disagree with them. I disagree. I take it as a great sign of respect.

By disagreeing with me and giving me a chance to respond you're saying you value my opinion and you're inviting me to share it with you. If you listen to me then you're conceding ever so slightly the possibility that you may be wrong. And if you patiently discuss the issue with me until I understand why I'm wrong then you're saying you think I'm worth the time it takes to do so. I know it's a different perspective than most people hold, but I think it's a better one.

Much of the problem stems from companies/schools/systems that punish errors, mistakes and lack of knowledge. Paradoxically these environments generate a sea of people who work wholeheartedly to hide their errors, mistakes and lack of knowledge. Fearful environments can never produce optimal people.

It's only in an environment of mutual respect that disagreements and open discussion can flourish. My advise is that you nurture such an environment with you're piers and refuse to shy away from conflict.

No Longer Under (much) Construction

2010-01-23T20:41:00.012-05:00

Well revisions to the blog following previous loss of formatting are completed. I put off redoing it nearly a month but I finally caved in today and got to work. To be honest it's the first time I've really liked the way the blog looks since I started it.

FYI... I've started using CSS3 for some of the formatting so the site will look best in firefox and safari, which support everything I've done. The design isn't quite as nice in other browsers (IE versions don't show round corners) but I used the YUI css reset file and I've practiced graceful degradation so it should be pretty good, whatever your browser choice.

Sadly this is my first post for 2010... belated happy new year everyone! I guess it's way past time I got back to writing as well. I've been busy learning WPF lately and using Expression Blend for the design work so I'm sure that'll be the focus of at least a few posts.

Please leave a comment and let me know what you think of the revisions.
Thanks. (P.S. I still find myself tweaking the format and fine tuning cross browser, so pardon the minor layout problem in the interum).

Problems with blog

2009-12-23T14:30:00.009-05:00

You may have notice that my blog was completely unreadable recently and is still hasn't fully recovered. For the past 2+ years I've used blogger to host my blog and Google sites to host little things like CSS files and logos. Well I got a warning a while back that Google sites was going away and being replaced.

Foolishly I put off doing something about it and am now dealing with the consequences. I'll be working hard over the holidays to get things back up and running, but in the mean time at least it's readable. Because the browser caches files it's possible that this could have been a problem for some time before I realized it, but I'm hoping you haven't been inconvenienced for too long.

Profuse Apologies.

Developer vs Manager Responsibilities

2009-12-21T21:04:00.022-05:00

Have you ever had a manager disregard your opinion? Make a technical decision contrary what you recommended? Ever get frustrated by it? Well don't. It comes down to a difference in developer and manager responsibilities.

Your Responsibility as a Developer

You might be saying to yourself "My responsibility? Duh! Get out the code, do my job!", well, yes and no. In addition to your job, you have a responsibility to your manager to provide solid information that they can use as a basis for their decisions. You're in the trenches; you know better than anybody what they need to know. You're responsible for bringing information and situations to their attention for them to act on.

You're the data input. Occasionally, if something is important enough, it's your responsibility to strongly push an point that you think is critical. However, once your boss has made it clear that they've made their decision, it's your job to follow their direction and move on.

Don't like it? Become a manager! Give up the joys of code for the monotony of meeting after endless meeting as your hard won technical experience melts away (the sad truth for most, but not all, who make the transition).

Their Responsibility as a Manager

You may not be aware of this but managers have a lot on their plate and even they don't get to call all the shots. They're fighting office politics (so that you don't have to). They're taking the information that you provide and arguing for more time or resources or what ever else it is the team needs. They're using the information you you gave them to make decisions about what the team's tools, strategy, staffing and priorities should be and often they're presenting that information to their boss for approval.

Here's the thing: If your boss makes bad decisions it's on them. It's their neck on the line. Of course it might blow back on you too, but in an accountable organization it's still on them. And given the internal politics of most companies your manager also has to tread carefully; they can't push hard for everything. They have to choose their battles... and so do you.

Choosing your battles

I know you've heard the saying "The squeaky wheel gets the oil", but a wheel that squeaks too often can become part of the background noise and be ignored completely. The reality is that some arguments can't be won; more importantly some arguments shouldn't be won. I know that in the vulcanesque mind of the programmer arguments are weighed based on their logic and merits only. Unfortunately the real world works differently.

Social Capital

There are often many valid ways to view a situations based on conflicting priorities and there can be many conflicting, yet compelling arguments depending on the view you hold. In these situations you gain social capital by yielding to others on topics that you consider less critical to the team and you spend social capital when you push your view-point forward ardently (whether you win or loose). My advice? Yield whenever you can and push forward only when you think it's really important (and only if there a chance of winning).

I know this sounds a lot like playing office politics and to some extent it is. That's not what I'm about though; trust me, I despise office politics but the sad reality is that if you're constantly the source of conflict, constantly the one with the only right answer, constantly rocking the boat then you will quickly find your opinions shunned and ignored. Even if you're right.

Going the distance

Team structure, rules, and the status quo evolve over time; "the way things are" can't be changed over night. If you really want to have an impact then you have to bide your time and work towards what you think is good for the team over the long haul. Often you'll find that your manager is in agreement with you and already working the same long term strategy with their boss and piers. Over time you will earn respect, trust, and social capital and, if you wait patiently, you'll be ready when opportunities present themselves to share your well thought out views and to influence things for the good of the team.

What are your thoughts?

Good design vs Bad design

2009-12-14T23:21:00.011-05:00

Good design is a pleasant surprise. It makes you wonder: why wasn't it always like that. Take the following picture for example. Even with the context removed the functionality is obvious. I love this fan.

Bad design isn't always obvious until you put something to use. The chair below is in a I.T. recruiters office. It's narrow and the protruding chair arm easily snags men's pants and is just high enough to rip them thoroughly. At the time I was extremely embarrassed that I ripped my pants and a little mad at myself, but out of curiosity I asked the recruiter if anyone else had had it happen to them. He confided in me that several people had including himself!

I'd be willing to bet that, like me, most people who ripped their pants felt it was their fault. It's funny that victims of bad design seem to blame themselves, while the beneficiaries of good design take it for granted.

Last time I went back the chairs were still there; just something to ponder.

Problem serializing WSDL generated properties where minOccurs equals zero

2009-11-10T09:02:00.008-05:00

A colleague brought me a problem that had us both stumped. He had a WSDL generated class that, when serialized, was missing several properties in the XML. He'd found something in common with between the missing properties though: all of the missing properties had minOccurs=0 set in the WSDL. The problem was that we didn't see any difference between the properties generated with and without the minOccurs zero setting; they seemed to generate the same code.

After a bit of google-gymnastics I found a stack overflow post that detailed the problem. When minOccurs is set to zero for and element WSDL.exe rightly considers the element optional. To handle these optional elements it generates two properties in the class: myProperty and myPropertySpecified. If you choose to set a value for the optional property then you must indicate that you've done so by also setting the specified property. When you do everything serialzes just fine.

Hope this helps.

Two years of blogging: Work, family, life balance

2009-10-27T21:46:00.009-04:00

Well I'm still going at after two years and I'm committed to sticking with it, though blogging has, of necessity, taken a back seat to everything else. Believe it or not I've added body-boarding to the list of things that take priority. It's the first thing since programming that I've really gotten into and gone full throttle on.
I was started feeling tired and burned out on life. Nothing unusual, I got married started a career and quit doing anything for myself and eventually the combination of a sedentary lifestyle and no real outlet for stress for nearly a decade began to take it's toll.
I heard a pastor say once that if you don't have an outlet for stress, something outside of work and family just for yourself, that eventually you break. I wasn't broken yet, but I think I was showing a few cracks. Body-boarding is what helped me turn that around.
I dropped some weight, got toned. I sleep better now and wake up feeling rested. Walking back to my car after a surf session I feel tired, relaxed and thrilled and when I'm out there there's no room for anything but me and the waves... for a little while all the concerns of life just melt away. It's been years since I've felt this good. If you haven't tried it I highly recommend it. For about 150$ you can get an entry level board and some fins.
Anyway, I think I'm almost ready to dive back into blogging again and write some heavier posts. We'll see.
Keep programming. Stay stoked.

ASP.Net Code Blocks: Pound vs Equal (%# vs %=)

2009-09-22T09:05:00.010-04:00

I got a runtime error after changing a pound code block(<%#statement%>) to equals code block( <%=statement> ) in some legacy ASP.Net code that I was cleaning up . I'd never seen the pound version before and had assumed it was an old obsolete way of doing things. Since this clearly wasn't the case I decided to do a bit of digging.

Eventually I turned up a post on code blocks by Dan Crevier that shed some light on things.

He summarizes the differences as follows:

The <%= (equal) expressions are evaluated at render time.
The <%# (pound) expressions are evaluated at DataBind() time and are not evaluated at all if DataBind() is not called.
<%# (pound) expressions can be used as properties in server-side controls. <%= (equal) expressions cannot.

This helped explain the error I got; unfortunately the post itself was hard for me to find (Google doesn't support searching for non-alphanumeric characters like less-than, percent, pound and equal) so I'm throwing this out there in hopes that it'll show better in search and help some people. All props to Dan though; he did a lot of work to research this.

Thanks Dan.

Bit.ly launches new url shortener J.mp to replace Bit.ly

2009-09-04T10:04:00.009-04:00

Bit.ly, the default url-shortener for twitter, has just launched a new site j.mp (saving two whole characters; I know you were counting) which will apparently replace bit.ly.

Moments ago I was automatically redirected from bit.ly to j.mp, then after trying again a few times I received a error message from Firefox saying that the redirect would never resolve. Then the Bit.ly link worked again.

My next test was to try to see if a bit.ly link would resolve if changed to j.mp and it does. www.bit.ly/1HMSZ2 and www.j.mp/1HMSZ2 are equivalent. And if you go to bit.ly and j.mp you'll see that other than the logo the pages look the same.

Looks like a permanent replacement is in the works.

Update:

Bit.ly has confirmed J.mp launch but not a permanant move. Then why test a redirect from Bit.ly to J.mp? Maybe they're waiting for brand recognition and trust to build up for j.mp before flipping the switch? That's my guess anyway.

Why Twitter needs more than 140 characters

2009-09-03T23:59:00.005-04:00

I express my thoughts and ideas on my blog so my output stream on twitter is limited to two things:

sharing links to content
sharing quotes

Often I combine the two: I quote great content and include a link to it. Unfortunately this requires me to slaughter the quote.

Case in point, I recently found a post by Kevin Anderson that compared old media's response to Twitter to their response to the rise of the internet (and how well that faired). The post included some excellent quotes by Douglas Adams on the internet and I found one I wanted to share. Unfortunately the quote was much bigger than 140 characters and there was absolutely no way to shorten it and keep its meaning.

Witness the slaughter:

(317 char quote from Adams) What should concern us is not that we can't take what we read on the internet on trust - of course you can't, it's just people talking - but that we ever got into the dangerous habit of believing what we read in the newspapers or saw on the TV - a mistake that no one who has met an actual journalist would ever make.
(149 char heavily edited quote; lacking attribution or link) [it's] not that we can't take what we read on the internet on trust [but]… that we ever got into the dangerous habit of believing… newspapers or… TV.
(Actual 140 char post) Douglas Adams "[it's] not that we can't take… the internet on trust [but] the dangerous habit of believing… newspapers/TV" www.bit.ly/1HMSZ2

Note that the final, horribly crippled quote lacks any attribution to Kevin Anderson for providing it and is sadly not retweetable since it has maxed out at 140 characters even in it's current, sad state. Also, if you go to the original quote, note that the ellipsis are single characters (not the proper way to do them on the web); so they may not be valid characters for everyone viewing, but it saved space so it's a trade off.

Also note that I changed http://bit.ly to www.bit.ly, saving 3 characters (both formats are converted to links by twitter). As noted by others, there should really be a way to attach a link as meta-data and not have it count against your character count, but unfortunately twitter's remained unresponsive to that request.

Honestly even just another 50 characters would make a huge difference in the user experience, but multiplied by the number of tweets in a day it would take up a significant amount of bandwidth, so I understand why they'd be reluctant to do so. I think that one way to monetize twitter might be to charge a flat rate for an increase in characters. An extra 50 characters per message could cost 4$ a month, 100 characters for 7$. I'd definitely be willing to pay a modest amount for that bandwidth; unfortunately there may not be a significant number of people out there who would.

Jacksonville Code Camp 2009

2009-09-01T13:30:00.012-04:00

Jacksonville Code Camp 2009 was this past Saturday and it was the best, most well organized Jax code camp yet. I gave a talk on "Becoming a Renaissance Developer" and the found the room surprisingly packed... until they found out the IPhone developer talk was next door.

Due to the demise of my Laptop the week before, including the loss of all of my notes and slides, I gave a revised presentation which ran short (just 25 minutes long). Fortunately there were no shortage of questions and the rest of the time was filled up with Q&A (I think we even ran a few minutes over) so over all it went very well.

During the session before my talk I found a large lecture hall and spent the time practicing in front of an empty room. Despite the lack of audience it felt very official and helped me feel a lot more prepared when I actually did it in front of people; definitely something I'll do next time.

Thanks to UNF for hosting the event and to all the sponsors. A special thanks to all of the Jacksonville Code Camp organizers and volunteers for putting on a great event.

The Renaissance Developer's Creed

2009-08-11T11:29:00.011-04:00

I've been putting a lot of thought lately into what it means to become a Renaissance Developer, a person who is a master of multiple domains of knowledge relating to software development.

Some today equate Renaissance Developers with T-Shaped people or Generalizing Specialists and in doing so, I think, cheapen the term. Not that the individuals that they refer to do not deserve a ton of respect. They are experienced people with a great deal of skills, talent and cross domain knowledge that are well on their way to becoming Renaissance Developers. This is no small feat; but I would rather that we be careful not use the term Renaissance Developer too lightly. It's like calling med students doctor; you don't do it... they must first earn the title.

It takes many years to master one craft (some say up to 10,000 hours spent striving at continual improvement). The idea of choosing and mastering several of the many related domains of study that influence software development is daunting. Just to list a few of the applicable fields:

Business
Software Testing
Configuration Management
Graphic/Visual Design
Coding (multiple language/platforms)
System Architecture
Security/Hacking(know thy enemy)
Marketing
Typography
Public Speaking / Writing (effective communications)
Interaction Design
User Experience
Database Administration and Optimization
Information Architecture

If someone chose any 5 of those of those and then spent many years mastering each of them then I'd say that would qualify them as a Renaissance Developer.

But if the title is so hard to earn and applies to so few, and if we cannot associate ourselves with it, then why even bother discussing Renaissance Developers at all?

I'd say that you make it worthwhile by not cheapening it. Otherwise you'll have any web developer with a bit of graphic and business knowledge lauding themselves as a Renaissance Developer. Just another piece of personal marketing fluff.

I think what we really need is to set the goal clearly and help as many people to get on the path as possible. The more who get started, the more who will reach the end.

In light of this I propose creating a Renaissance Developers Creed.

Why a creed? Why not a manifesto? (After all manifestos are cool, right?)

Well manifestos tend to be statements of belief by those who have arrived. Creeds, on the other hand, are commitments to a set of beliefs by those who have yet to arrive but have chosen to set out on the journey.

The Renaissance Developer's Creed

We believe that there's more to great software than just the code.
We believe in continual learning. We believe there are many domains of knowledge that can aid us in creating better software and that we should strive for some level of expertise in as many of those domains as possible.
We believe in exploring new languages and new systems, in applying the concepts that they introduce to our work and in learning from both their achievements and their shortcomings.
We believe that real world experience is to be preferred over book knowledge and that opportunities to apply what we have learned should be diligently pursued.
We believe in being a part of the developer community and sharing what we've learned with others. We believe that one indication of mastery of a subject is the ability to teach it effectively and that our knowledge is increased and perfected through the feedback that we receive from others.

I must admit that I do not follow these tenets perfectly and that there are some of them I'm just now starting to explore. But I think that that's the point. I think that if we commit ourselves to these principles that we will be much better programmers one, five.. ten years from now than we are today.

I think that is what makes the struggle worth it, whether or not we are ever awarded the lofty title of Renaissance Developer.

Related Posts:

Evolution of (my) Javascript

2009-07-30T07:02:00.008-04:00

Over the years the way that I code JavaScript has changed significantly and I wanted to review how my code has evolved. When I first started in JavaScript it might have looked something like this:

<a id='HW0' href='javascript:void(0)'
onclick='HelloWorld();'>Hello World Test 1</a>

<script type='text/javascript'>
function HelloWorld(){alert('Hello World');}
</script>

Later I learned that it was considered a good practice to mimic standard OO principles and that everything should be under one namespace so my code changed to this:

<a id='HW1' href='javascript:void(0)'
onclick='jdh1.World.Hello();'>Hello World Test 2</a>

<script type='text/javascript'>
    var jdh1 = {};
    jdh1.World = {};
    jdh1.World.Hello = function(){
    alert('Hello World!');}
</script>

Then I learned about JavaScript Object Notation (JSON) and my code looked more like this:

<a id='HW2' href='javascript:void(0)'
onclick='jdh2.World.Hello();'>Hello World Test 3</a>

<script type='text/javascript'>
var jdh2 = {
World:{
    Msg:'',

    Hello: function(){
        alert(jdh2.World.Msg);
    },

    Initialize: function(Settings){
        jdh2.World.Msg= Settings.Message;
    }
}
};

jdh2.World.Initialize({Message:'Hello World?'});

</script>

A while later I learned that my HTML really shouldn't have javascript embeded in it (e.g. no onclick) and also found out about self-executing anonymous functions (which I see no real need for, but find strangely irresistable), so my code morphed ever so slightly to this:

<a id='HW3' href='javascript:void(0)'>
Hello World Test 4</a>

<script type='text/javascript'>
var jdh3 = {
World:{
    Msg:'',

    Hello: function(){
        alert(jdh3.World.Msg);
    },

    Initialize: function(Settings){
        jdh3.World.Msg= Settings.Message;
    }
}
};

(function(){/*Page Initialization*/
    document.getElementById('HW3').onclick = 
    jdh3.World.Hello;
    jdh3.World.Initialize(
        {Message:'Hello World???'}
    );
})();

</script>

Finally I started using frameworks, such as JQuery and Asp.Net ajax which are more assistive than transformative and don't really apply to this example (though they allow you to replace that pesky getElementById with either dollar-sign($) or $get).

I have, however, mostly avoided the Moo Tools framework — which attempts to transform javascript from a prototyped object oriented language into class inheritance based one — for the same reason that I avoid prototypes themselves; within the context of my programming they add complexity without much gain (again strictly speaking within the context of my development).

I must say that I am ethusiastically embracing the the combination of ajax(via ASP.net) and DHTML(via jQuery); they complement one another beautifully.

T-Shaped People vs Generalizing Specialist

2009-07-14T19:26:00.022-04:00

I've talked about T-shaped people in the past and why it can be useful to have them on your team. To hit the highlights:

T-shaped people are expert in a core skill, but also have a number of tangential skills that they are shallower in.
They should not be considered generalist because, unlike a generalist, T-Shaped People do have a core area of expertise.
T-shaped people work well on teams because they have the ability to see many perspectives, can stretch to fill gaps in the team and can take on new skill-sets quickly.

When I started reading about Generalizing Specialists I immediately drew parallels between the two and wondered how Generalizing Specialists differed from T-Shaped People.

One of the best articles on Generalizing Specialists is by Scott Ambler. In it he says that a Generalizing Specialist "seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas." He goes on to give examples including Programming, Testing, Business, Project Management, and Deployment.

Though I strongly implied it in my original discussion about T-Shaped people I failed to state explicitly that I think that T-Shaped people are defined by their cross-disciplinary knowledge. From all that I've read from Scott and others there seems to be agreement that the requirements for a core specialty and cross-disciplinary knowledge cover both T-Shaped People and Generalizing Specialists, though, as with me, people haven't always emphasized that point strongly enough.

Consider the following comment I found on a post about Generalizing Specialist:
"I see great value in generalizing specialists for programming technologies. However... I cannot expect a single engineer to have IP routing, mobility management, session protocols, packet inspection and fast path expertise in my product. Those areas are domains in themselves and sometimes require years to master." Comment by Paul C

No disrespect to Paul, but a person with all of those skills is not a Generalizing Specialist. I wouldn't even recommend that they try to be (maybe there are some IP routing, packet inspecting, mobility managers out there who can enlighten me, but I just don't think they'd benefit from a great deal of cross-disciplinary knowledge).

Don't get me wrong, studying multiple sub-specialties within a domain is admirable, it's just not what we're talking about here. If you're going deep with a super narrow focus I'd say that makes you an uber-specialist and if you're doing so on several topics within the same domain, as above, would make you multi-uberspecialist. But no matter how many sub-domains a specialist masters it will not make them a Generalizing Specialist.

Regarding specialists Nobel laureate Konrad Lorenz said "Every man gets a narrower and narrower field of knowledge in which he must be an expert in order to compete with other people. The specialist knows more and more about less and less and finally knows everything about nothing."

Not that there's anything wrong with that. In many contexts a specialist is exactly what you need and I think that Paul lists several great examples, but in other contexts, for instance Agile Development and User Experience/User Interaction Design, I think it's been widely recognized that it's beneficial to to have a lot of T-Shaped, Generalizing Specialists in those roles.

So, are T-Shaped People and Generalizing Specialists the same thing? I think they are. Its funny how nearly identical concepts can spring up from multiple sources around the same time.

I'll leave you with one final quote about specialists from one of my favorite Sci-Fi authors:
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." Robert Heinlein

You may also be interested in the following posts:

Good Marketing vs Evil Marketing

2009-07-09T00:14:00.019-04:00

Like many of you I have a teeth grinding, nails on the chalkboard, trip to the dentist reaction to the term marketing. One that conjures up memories of late night infomercials, telemarketers, and internet/twitter/email spammers. Corporately you may also encounter the term used in the following context: "Marketing says they need [impossible changes] to [something you're responsible for] by [impossible deadline] because of [illogical reasoning/self-promoting corporate politics]".

In fact in most contexts the term Marketing is about as well received as a fur coat at a PETA luncheon.

Believe it or not though, while it can be used for evil, marketing isn't inherently evil. At its heart marketing is simply an attempt to take something that you're selling and make it appear favorable. Yes you could be selling a product but thinking more broadly you could also be selling an idea or even selling yourself (think about the last time you went on an interview).

Evil marketing says: We have a awful product/service/idea that we want you to think is great! Often the product was designed primarily to be sellable, but not necessarily useful or reliable.

Good marketing stems from the product itself. It only occurs when you've worked hard to create an awesome, usable product that fills a need and, having done that, seek to get the message out to the people that it will help.

To simplify it further, marketing is the sum of the messages that you are putting out there about something you want others to care about, whether it be your company, your product, your team, or yourself. It is critical to be aware of the messages you are putting out, how consistent they are and the perception that they are creating.

How good your product/blog/software looks sends a message. How it's presented sends another. How useful it is, while critical, can be buried behind the all the other messages that are being sent. Perception is often more important than reality and perception is exactly what marketing seeks to influence.

Companies are marketing their products; Managers are marketing their teams; Team members are marketing their skills and their usefulness to the company. Good marketing takes something worthwhile and aligns perception with reality; poor marketing fails to do so. Evil marketing takes something worthless and attempts to skew perceptions to make it seem worthwhile.

Virtual ALT.NET Lunch & Learns: A chance to speak

2009-07-03T00:25:00.006-04:00

I attended the yesterdays Virtual Alt.Net(VAN) Brown Bag Lunch online and was surprised by the variety of content. The floor was opened up for anyone in attendance to give a quick presentation of things they're working on or wanted to share and several different developers stepped up. From programming to tools to application etc it was quality content all around and well worth the time.

It's rare to find something this exceptional and pleasantly different out there. I'm sure if the meetings got large enough they'd need to have people schedule ahead of time but for the moment it's an extremely interesting, and rather unique format; I really hope it scales as they grow.

If I'd know ahead of time that they would be opening up the floor I might have had something quick prepared... I may have a go at it next time.

I hope you'll all make it a priority to make at least one meeting in the next month. Whether you come to speak or just to listen I think that you'll be pleased.

Every Wednesday 1PM EST Virtual Alt.Net Mettings (via LiveMeeting) are here.

Virtual ALT.NET is not a Cult

2009-07-01T22:22:00.012-04:00

I mentioned to someone at work that I'd be attending a Virtual Alt.Net (VAN) Meeting online and their response was (no kidding): "Alt.Net? Isn't that a cult?".

Now you may have heard rumors flying about those crazy Alt.Net guys being some sort of X-Files, Lone Gun Men sitting on the sidewalk outside of Starbucks typing on a laptop with one hand and holding up cardboard sign with the other declaring the coming Apocalypse , but I assure you it isn't so (at least not based on tonight's meeting).

Ryan Svihla (@rssvihla) gave an excellent presentation for VAN (Virtual Alt.Net) on the Castle Project tonight. His coverage of IoC and Dependency Injection were solid and the discussion of Castle was interesting. Castle it isn't quite mainstream and to tell the truth, all the code was a bit much for me to absorb in one session, but it was clear from what I saw that these types of frameworks for managing dependencies are the way things need to be headed.

Anyway, the meeting went off without a hitch using Microsoft LiveMeeting (just like the Linked In Dot Net User Group - LIDNUG). Unlike LIDNUG The Virtual Alt.net guys have meetings scheduled very consistently and conveniently for an American crowd; if you're in the continental US they should be Wednesdays sometime after work and Thursdays around Lunch time. There are also a few meetings scheduled for the international crowd.

It seems like they're just getting everything off the ground and they're doing a great job so far but I would like to offer a little feed back. Their site www.virtualaltnet.com doesn't come up first in a google search. Also, when I got there I couldn't find the LiveMeeting link (I might have missed it but I didn't see it there). Thankfully they have members active on twitter and I found the link there with a quick search. It's a minor thing, and one to be expected with a newly forming group, but the sooner they fix it the better their numbers will be.

Anyway, it was a great meeting. I plan on attending tomorrow's brown-bagger from work if I can.

You should be able to attend for tomorrows and all future Virtual Alt.Net Mettings (LiveMeeting) here.

Thanks again guys.

Can anybody do agile?

2009-06-28T00:02:00.000-04:00

I'm a fan of lean/agile practices but, like most people who call themselves fans, I've never actually played the game. Given that my knowledge of agile comes from the bleachers I'm a little wary of offering opinions, but I'm going to wade carefully into the waters anyway.

I've been pondering the question for a while "Can anybody do agile?" I have a suspicion that for agile-type practices to work well you need individuals specifically geared toward that type of development (or who have been mentored in it).

This may be the reason that there are disparities in the reports of how well these techniques deliver in real life ("oh we tried --insert agile flavor here-- but it didn't work"); it's possible that good developers under waterfall may not always turn out to be good developers under more agile practices.

Fundamentally these practices address people problems and I suspect that they can depend a lot more on the chemistry of the group and the quality of the members than the process itself (however well crafted it may be). Just as one tainted ingredient in a chemistry experiment can skew or ruin the results, likewise, so can one poorly chosen member in a team.

I know this applies to all teams, but I think the speed and connectedness of agile teams makes it much more critical to them.

Anyway, to those who are actually doing agile: please forgive the sideline ponderings of a fan who just wants to be in the game. Hit a home run for me!

Being a Professional on the Internet

2009-06-27T10:53:00.008-04:00

Imagine this: You work for a big, uptight corporate company. You google the name of a coworker or someone in a local users group or maybe just some designer or programmer you've heard of. You find that they have a website, a blog, or a twitter account that's professionally related.

Question: Do you dare click through to their content?

If you do, will you find profanity, inappropriate content, or questionable photos?

Maybe your search was more directly work related. Did you find a great Photoshop tutorial or image rotator that just happened to feature scantily clad women? (Common guys, are we in eighth grade? Grow up already.)

It seems to me that if you're producing content within a professional context then you need to self-filtered that content stream so that it remains professional and is not offensive to others. And yes, this includes twitter if you make your profession prominent on your bio.

And if you want to do shock-jock content? Fine. Just don't do it in a place where people are expecting professional content. Don't delude yourself, there's no such thing as being somewhat professional; you're either professional or you aren't.

To me this is just common sense, but there've been a lot of people not following these guidelines lately, so maybe it's not.

Blog Update

2009-06-26T13:10:00.004-04:00

I've turned on comments. Until now I've kept them disable because of the nightmare stories about stalkers, spammers, and the loss of blogging time to moderation. It always seemed to me that it wasn't worth the trouble. But I've been in an adventurous mood lately so I'm going to give it a try.

In other news, I've decided to try adding other bloggers to the site, similar to what Los Techies has done. We'll see how it goes.

That's all for now.

Linked In Dot-Net Users Group (LIDNUG)

2009-06-22T17:01:00.012-04:00

I attended my first Linked .Net Users Group meeting online last night and really enjoyed it. I logged in early to make sure I wouldn't have problems and spent a half hour or so talking (VOIP) with Brian H. Madsen a Microsoft MVP & LIDNUG organizer in Perth, Australia. He was starting his work day Monday morning just as I was putting kids to bed half a world away Sunday night. I don't know why but I think that's just too cool... world-wide interconnectedness and stuff.

I will note that due to the worldwide nature of the group the scheduling can be somewhat inconvenient -- last nights meeting was from midnight to 1:30am in my time zone. I really enjoyed the talk but I was running on fumes by the end of it. On the plus side:

The meetings are free.
You don't have to be a member of LinkedIn to attend (though I am)
They have top notch speakers from around the world.
You get to make connections with programmers from around the world.

As I noted you don't have to become a member of LinkedIn to attend, though if you aren't you can't register as a member of the LIDNUG, so you won't qualify for prizes/drawings. I understand from Brian that some people who came up in the drawing for complete MSDN subscriptions were very upset to be disqualified because they weren't members (not LINDUGs decision per se... sponsors want goodies to go to members, and understandably so).

Anyway, Sara Ford, who is a Microsoft Program Manager out of Redmond, Washington, gave the talk last night. Sara heads up the CodePlex project, which is Microsoft's open source project hosting initiative (think SourceForge only by Microsoft) and her presentation was a detailed overview of CodePlex. It was an excellent talk overall; if I started an open source project I'd consider it and I wouldn't have before the talk, so kudos to Sara; she made a dent.

Bear in mind that while I program using Microsoft tools, I'm not a Microsoft fanboy, and remain strongly suspicious of Microsoft when it comes to open source. What makes me take a step back from this position is more my impression of Sara from the talk than from any credence that I give to Microsoft. She seemed really passionate about open source and even a bit of a rebel (which is always a redeeming quality when it comes to Microsoft employees).

The talk will be online in a few days along with other past talks. I look forward to listening to the it again in a more conscious state of mind; particularly the last 30 minutes, which, though I remember that part of the talk being very interesting, I can't recall the details of it... I'm pretty much worthless after 1am unless you pump me full of coffee, which wasn't really an option for a Sunday night at 1am (or I would've never gotten to sleep).

You should be able to attend future LIDNUG meetings through LiveMeeting here. You can also check for all future LIDNUG events on LinkedIn here.

Linked In .Net Users Group Logo Submissions

2009-06-20T23:01:00.008-04:00

I recently became a member of the Linked In .Net Users Group, though I've yet to catch a online meeting. A few days ago they put out a call requesting members to help with a logo for the group. I just got around to working on it tonight and created the following:

Not too shabby, IMHO... Unfortunately I realize just after submitting this that the official group name is not LinDUG, but LIDNUG. LIDNUG... Try saying that 10 times fast. Ok so, my bad; I did some editing and submitted this:

A quick google search will show a few others making the same mistake I did, so I don't feel too bad. I do think it's a better name for the group so I'm suggesting a name change to LinDUG on the following grounds:

it's easier to say
it associates more with linked in
it plays better as a logo

But, hey what do I know? In any case, the revised logo is growing on me. I kept the arch from the dot over the 'I' which I meant to look like the curve of the world, suggesting the world-wide nature of the group. I still like the blue/orange combo of original better. As usual I asked my wife's opinion: she likes the all blue of the new logo (though she prefers LinDUG as a name).

Update: Decided I liked the new logo better. Even if the name changed I'd swap the letters and keep the design over the old one.

Master Page, Header, Code Block Problem

2009-06-18T16:25:00.006-04:00

I added a script tag with a script block --src='<%=Page.ResolveUrl(" ") %>-- to the head of a master page and got the following error:

"The Controls collection cannot be modified because the control contains code blocks"

The error didn't get thrown on all pages and I was stumped as to what to do, but on a hunch I moved the script tag from the head to the top of the body and voila, no more error.

A quick google didn't turn up anything useful (though other, non-pertinent stuff on the error is out there) so maybe this will help to someone.

More mixed feelings about Twitter

2009-04-11T00:41:00.019-04:00

I'm still working on pushing good content to my twitter feed, but I find I'm having mixed feelings about the purpose of the platform.

Supposedly Twitter is all about "What are you doing?". I still don't find answering just that question to be very useful.

Some classify it as micro-blogging and I actually find that aspect to be pretty useful. It's a great place for links, quotes and thoughts that I otherwise wouldn't have a place for. It's even fun.

Then there's the whole social networking @ aspect of twitter which I still don't quite get yet.

Anyway I'm still figuring it all out.

Update: Just found some interesting guidelines on posting to twitter from Rands in Repose: The Art of the Tweet

Dysfunctional Deployment Practices: Constipation Deployment

2009-04-10T23:59:00.003-04:00

Have you been having trouble with constipation? No not that kind of constipation, I'm talking about the dysfunctional deployment condition that I like to call Constipation Deployment.

With Constipation Deployment it seems practically impossible to get anything out at all. Sometimes it looks like you're about to push something out and then inexplicably you're put on hold again. Eventually you do manage to get something out, but it's not as big as you'd like and it's a piece of crap.

I've heard that Agile or Lean brand laxatives can get things moving more regularly and dropping golden nuggets in no time. I'm not sure its as good as all that, but its got to be better that what a lot of places do which is just keep straining away and wait it out.

Hmm.... I wonder what the development equivalent of hemorrhoids is?

Aren't metaphors great!

Javascript Bug: Processing takes progressively longer

2009-04-09T21:55:00.005-04:00

Javascript Bug: Processing takes progressively longer each time you click a button or hit enter.

You might guess this is a Memory Leak Problem, and since this is Javascript you might suggest it could be the much hyped circular reference problem that can occur between a JavaScript object and a DOM object. Close but no cigar.

I've only seen this symptom 3 times in the wild, but every time the actual culprit has been a problem with event handlers, i.e. the same event handlers are being re-added without the old ones being destroyed. In the worst case each run of an event handler added another which generated an exponential explosion of handlers.

Depending on how you think about this you might want to classify it as a memory leak, but a progressive consumption of memory is not what's causing the slow down. Instead it's just huge stack of handlers being queued up and taking forever to run.

For a quick fix you can wrap this if statement around your add handler statement:

if(!this.HandlerAdded)
{
/*$addHandler code here*/

this.HandlerAdded = true;
}

This if block will only allow the handler to be added once. Note that HandlerAdded is a property of the function and not a variable. This means it won't error out as undefined even though it doesn't exist yet; it also means that it will persist to subsequent calls.

Alternately you could do something like this:

function EnableKeyPressHandler(enabled)
{

if(enabled== true)
{
 if(!this.HandlerAdded)
 {
      $addHandler(myObject, "keypress", CheckKey);
      this.HandlerAdded = true;
 }
}
else if(enabled!= true)
{
  if(this.HandlerAdded)
  {
      $removeHandler(myObject, "keypress", CheckKey);
      this.HandlerAdded = false;
  }
}

}

Then you can replace the appropriate add/remove handler calls with a call this method (note: this code is a mod/simplification of working code, but has not itself been tested).

Ideally you would do further refactoring to make sure that calls to add/remove handlers are made at appropriate times.

Creating a Professional Twitter Feed

2009-04-07T00:37:00.006-04:00

I opened a twitter account nine months ago and didn't touch it again until last week. I wasn't sure what I wanted to do with it and I couldn't find any feeds that I liked to use as an example. On Friday I started toying with the idea of creating a professional twitter feed and what that would mean.

Mostly what I'm after from a professional feed is meaningful information. There are probably lots of things that people on twitter have said that I'd be interested in knowing. Unfortunately the signal to noise ratio is just too low. Any important stuff out there is being drowned out under a mountain of noise.

So at the risk of looking foolish, and realizing I'm still a twitter noob, I'm going to take a run at creating a decent feed http://twitter.com/CodeRenaissance.

Here are what I think are important uses of a professional twitter feed:

Sharing clear, concise, relevant, meaningful, original thoughts: Hopefully these are your thoughts, but I'm also a sucker for great quotes. If you quote then include the source and if possible a link.
Links to outstanding content: If not outstanding then really good; video and audio content are especially nice because these are resources aren't as easy to ferreted out. Oh and if you have a unique perspective on a link then blog it, don't tweet it (or do both).
Meatspace networking: Imagine a member or leader from a Developer User Group tweeting "Hey I'll be at coffee shop x at location y for the next hour if anyone wants to talk code". That might be cool.

That's it for now. Let's see how this experiment goes. Oh and here's some common sense advice about starting on twitter.

Link Fest: 1st Quarter 2009

2009-04-01T23:00:00.003-04:00

Everyday I skim about a hundred blog posts and only flag a handful of important ones for careful reading later. Now once a quarter I'm going to start going through those posts and picking the best on a handful of important topics. Without further ado, here it is, the 1st Quarter 2009 Code Renaissance Link Fest.

Code and Software Development:

Entropy In Software - Los Techies
JavaScript, time to grok closures - Devlicious
Software Development Lessons Learned - Elegant Code
Multicore Mania - Simple Talk
The Emergence of Knowledge in Software Development - Los Techies
The 25 Most Dangerous Programming Mistakes(Security) - Coding Horror
Good Software Design is Easy (Testability) - Scott Belaware
The Big Redesign in the Sky (Green Field Development) - Object Mentor
Things About Programming I Learned in Music College - Working Software Daily
Estimation Is Not For Accountability (It’s For Visibility) - Code Squeeze
Readability Is Number One - Coding Instinct

Development Methodologies:

Software is a Movie, not a Building - Cooper Journal
Why Requirements Stink - Scott Berkun
Lean: Doing Less With More - Net Objectives
Decade of Agile, Dawn of Lean - Scott Belaware
DDD: What Kind of Applications Is It Suited To? - Devlicious
What Would You Want Someone to Know Before They Run Your Project? - Net Objectives
Learning Culture - Scott Bellware

Testing:

Explaining Exploritory Testing - JW on Test
I'm Helping You, I'm Helping You - Questioning Software
Testing is Like Raking Leaves - Test This Blog

Refactoring:

Refactoring Legacy Code -Los Techies
Back to the Basics: Refactoring Code - Rachel Appel

Technical Debt:

Technical Debt - Martin Fowler
Paying Down your Technical Debt - Coding Horror

Typography:

Fonts and The Web - Web Designer Wall
12 Resources for Beautiful Typography - Web Design Ledger
Lovely Ligatures - Design O' Blog
5 Simple Ways to Improve Web Typography - Web Design Depot
40 Super Sleek Fonts For Clean Web Design - Web Design Ledger
Frustrated With Coworkers? - Code Squeeze

Marketing:

How To Switch From Personal To Business Branding - Freelance Switch

Information Architecture:

Complete Beginners Guide to Information Architecture - Ux Booth

LogoDesign:

Logo Design Walkthrough - Spoon Graphics
4 Logo Design Details You May Be Forgetting - Logo Designer Blog
9 Solid Logo Design Tips for Beginners - I'm Just Creative
Let's Talk Logos - David Airey
What Should You Get From Your Logo Designer - The Design Cubicle

Web Design:

50 Monochromatic Website Designs - Web Designer Depot
Fluid Grids - A List Apart
Why Programmers suck at Picking Colors - Beta Version
21 Stimulating Color Palette Tools For Designers - Pheedo
Another 20 Inspiring Website Footers Designs - Eightyone Design
Why Programmer's Suck at CSS Design - Stefano Linotype
Open Source Image Editors … for Designers? - SitePoint
Web Design Trends 2009 - Men with Pens
The Details That Matter - SitePoint
200 Beautiful Seamless Patterns - Web Design Ledger
Interfaces and Color Blindness - Particle Tree

Web Writing:

The Disgustingly Simple Rule for Web Writing - Copy Blogger
Writing Tips for Web Designers - Web Designer Wall

Web Development:

Beautify Your Html and Enrich Your Content - SitePoint
Fix Your CSS - Search This
The Five Most Under Used Html Tags - SitePoint

Configuration Management:

Continuous Integration 101 - Davy Brion

Management:

Are You Creating Micromanangement Zombees - Coding Horror
Creating a Culture of Responsibility - Los Techies

People & Teams:

How to Call Bullshit on a Guru - Scott Berkun
Thinking only of the Junior Developer - Elegant Code
Frustrated with Coworkers - Code Squeeze
How Many Projects Should You Work on at a Time - Net Objectives.com

OtherStuff:

Quality is not Dead - Satisfice
Rule of Twelve - Dilbert Blog
Running a Micro ISV - SuccessfulSoftware

Zero Defect Software Development

2009-03-25T13:22:00.010-04:00

There is an old article about Zero Defect Software Development(ZDSD) by Steve Pavlina that was recommend to me by a coworker.

According to the article the basic tenet of ZDSD is "Maintain your product in what you believe to be a defect-free state throughout the development process."

I think a lot depends on how you define defect. For instance the article uses games as an example and includes in defects "unpolished artwork, an unacceptably low frame rate on the target system, levels that aren't fun enough, or any number of unfinished features". These can be restated as aesthetics, performance, usability, and unmet feature requirements.

Restated further, defects are measures against a defined level of quality (i.e. anything that falls below the defined level of quality is a defect). If the only measure of quality is the business requirements then the defect rate may be relatively low. If other measure of quality are defined (performance, maintainability, documentation, etc) then the defect level would need to be reevaluated based on those standards.

Rule 8 advises you to "Set QA objectives at the beginning of every project". Combine this with the basic tenet, "Maintain your product in what you believe to be a defect-free state throughout the development process" and what you get is "Set a standard of quality and live up to it".

Not bad advice. I'm sure a lot of development shops could be helped by it. The problem is that different development shops practicing Zero Defect Software Development could be given identical requirements and produce substantially different levels of work depending on what other measures of quality they define.

Fortunately there is more to Zero Defect Software Development than this. The recommended practices are actually quite stringent. Here are a few:

Review code regularly
Rewrite poor-quality modules
Make the quality of your code as important as the quality of your product
Learn from every bug

Good stuff. In fact the article recommends a laundry list of very solid practices, but I wonder if Zero Defect Management isn't as aptly named as it might be.

Also, I couldn't find much of recent chatter about ZDMS, except some talking about zero defects in general, so maybe this never really took off. There were some solid recommendations in the article though and I highly recommend checking it out.

Family Eulogy

2009-03-23T14:44:00.008-04:00

My father died last week at the age of 65. My grandfather died just a year or so before him at the age of 93. Below is a picture of me, my son, my father and grandfather taken almost 7 years ago. 4 generations.

In the end death humbles us all. The most I can offer them is a brief remembrance, sharing the best of these men that I loved and admired so much.

Briefly though I need to take a step back in time and share the story of a man that they admired, my great grandfather, James Partin.

My great grandfather was a cowboy all his life. My grandfather had an old picture of him on his horse, a gun on each hip and lasso in hand, herding cattle. He was good to the Indians that some times camped on the other side of the lake from him and was know to share the sweet potatoes that he grew with them and anyone else who came to visit. He was a good man by all accounts, tough but fair and hard working every day of his life.

At the age of 73 my great-grandfather was trampled by his horse after his saddle broke while he was roping a calf. He managed to walk some miles back to the ranch where he worked as supervisor and was taken to the hospital, but died a few days later of internal injuries and gangrene.

My grandfather, Judson David Partin, loved his dad dearly, and in his 90’s he still got choked up telling the story of his father’s death. I don’t think anyone ever gets completely past the death of their father.

As much as my grandfather admired his dad he chose a different path. As a teenager my grandfather was out tilling the field barefoot with a mule and plow when he had a root pop up and hit him hard on shin. It was a small but pivotal moment. He said he decided then and there that he was he was going to do something different with his life.

Some time later he talked his way into a job driving a Model-A truck moving citrus (the model-A was the successor to the original Model-T). He told the man who hired him that he knew how to drive it, and though he didn’t, he figured it out.

He spent the next 60 or so years of his life driving trucks off and on. He cleared land for airfields stateside in WWII and was known to be able to operate any machinery with wheels or treads. He was forced to retire from truck driving for insurance reasons at the age of 82. So far as I know he was the oldest working CDL licensed driver in the United States.

A few years later when I went to visit he was still doing 90 mile per hour on the local interstate, three radar detectors on the dash and a .38 and .45 next to his seat. I took a trip with him up to North Carolina and he stopped to help some people who were broke down on the side of the road up in the mountains. He figured out what was wrong with the car and we drove 30 miles away to the nearest parts store, came back, fixed their car and got them on the road again. He was a good man and spent his life helping people, especially family.

Though his health began to fade after retired, he spent another 10 years sitting on the porch feeding the sand cranes and the squirrels and driving his girlfriend around to garage sales (a younger woman, just in her 70’s). In 2006 he fell in his home and broke his hip. He managed to get up, clean a gash in his head and was sitting his chair when my dad came to check on him. He lived another year or so but was never independent again.

Electric light, the automobile, movies, and airplanes were all just beginning to be commercialized when my grandfather was a kid; electricity and indoor plumbing were luxuries that most did not have, his family included. In his lifetime my grandfather saw the time of cowboys and indians fade and transition to the age of computers, space and the internet. There has never been any other time in history when one lifetime could see so much change.

My Dad, J. David Partin, was just as determined as my grandfather was to do things differently. From childhood my dad had a gifted voice. He went to college and studied business and music. He spent most of his life as a singer and an entertainer. He even briefly had a local television show on Tybee Island, GA in the late 70s called the Dave Partain Show (Partain being a small alteration of his last name that he used as a stage name).

He was drafted into the army during Vietnam, but was fortunate enough to be stationed stateside; he managed several restaurants, owned a club for a while and never gave up his dream of making it as an entertainer, returning to it time and again. Over he all lived a wild and crazy life.

Though he hung on close to 10 years longer than the doctors had given him, being ever the contrarian, he passed away quietly in his sleep days after his doctors offered the family hope that he might bounce back one more time. In the end he was most happy that he had been able to reconnect with my sister and I and that he had gotten to see his grand children, of whom he was immensely proud; a joy he shared with everyone.

I loved my father very much.

I always will.

Update: I couldn't bear to post this at the date it was written, and don't want to update the date and have it show up as current now after the fact, so I'm posting it at the original date. I'm not certain if it'll be picked up by the RSS feed or not, but I want it out here on my blog as a testimony, whether anyone sees it or not.

QC Testers - Not Just Software Sanitation Engineers

2009-03-12T00:02:00.004-04:00

A good Tester can be worth their weight in gold if you let them. Their job is to put your application through the ringer. They are also generally the first person to use your app/feature so they can provide some key insights into user experience and usability.

Off the top of my head here are some things that a good tester can check:

Is anything broken that worked before? (regression testing - a lot of work here)
Can your URLs be hacked to get information that users shouldn't have? (security)
Are sql injection attacks possible? (security)
Is your tab order right? (usability)
What would the stupidest person using your app do here? (user experience/idiot proofing)
What happens if you double click on buttons? (user experience/idiot proofing)
If there is role based content/functionality what would happen if a user with multiple roles accessed this feature? (security/usability)
What would make this feature easier to use or easier to understand? (usablity)

Those are just a few. If you're a developer I'm sure you've asked yourself a lot of these questions and then some, but testers are different. As a tester, "If it ain't broke, you aren't trying hard enough". A good tester takes it as a challenge to out think you, to find the things that you missed when you were busy getting it working.

It used to be that testers were either inexperienced techies trying to break into development or just business people who just stumbled in and filled a need. They'd give the app a quick once over to make sure nothing obvious was broken and move on.

More and more I'm seeing testers with decent database and coding skills. They understand how the application works. They're in the database, they know how the data moves. They know how to know if things are working right and how to set everything up properly.

Bright people are now choosing testing as a career and I think the gap is quickly widening between a top notch tester and a merely competent one.

So if you're lucky enough to have a good tester don't look at them as another hurdle that has to be jumped to get your code out to production. They are a valuable part of the process; they're you're collaborators in turning out an awesome product.

P. S. Can't resit giving a belated shout out to my favorite testing blog, JW on Test... Thanks James, keep up the good posts.

Jump the fence or bloom where you're planted? When to move on to another job.

2009-03-02T18:00:00.006-05:00

After only six month at my current job I've accepted an offer at another company. If you follow my blog you may remember my last job change and my excitement at finding a good job close to home. It was a very good job. I had a good team, a good boss, and a reasonable workload; I was very happy there.

Then, just before Christmas, my company let go of a bunch of contractors. Though I wasn't one of them and though my boss assured me that he was very pleased with my work, my confidence in the security of my job there as a contractor was shaken. I didn't immediately start a job hunt, but planned instead to reassess things toward the end of February and make a decision then.

Providence intervened however. In mid February I received an inquiry through LinkedIn asking if I was interested in a web development job at a small, growing company in Ponte Vedra Beach (just 20 minutes from where I live in Jacksonville, FL). A growing company in this economy sounded really appealing. Long story short I interview and loved what I saw and heard; two days later I accepted an offer and gave notice at my current job. Perfect opportunity, perfect timing.

All of this upheaval got me to thinking, though. Is there a fixed set of criteria that people can use to judge when it's time to move on from a job? What are the things they should look for?

You've heard the saying "the grass is always greener on the other side of the fence", which is to say that things always seem better elsewhere, though they seldom are. Often it's just a matter of trade offs. If you work for a solid company, have a reasonable boss and interesting work then you should overlook the little things and strive to make lasting changes in your company for the better or, as I heard a preacher say once, "dig in roots and bloom where you're planted".

Making the most of the job that you have is usually the right move, however, I've come up with a short list of things that I think signal that it may be time to move on:

If the company that you work for is unstable. If you are in a company that is on shaky ground then you need to try to get out before things hit the fan and you end up looking for a job with a large group of your peers. Feelings of loyalty can be compelling, but if you're married, especially with kids, and don't have a generous rainy day fund to fall back on then you need to start weighing your options immediately. Remember that your duty is to family first, work second... Always. Remember too that it's easier to find a job when you have a job, if for no other reason than that time is on your side. Just be careful and make sure that the company you're moving to is more secure than the one you're leaving.
If you have an unbearable boss. Maybe your boss is truly evil or incompetent in a dilbertesque kind of way or perhaps there is simply a personality conflict or idealistic differences between you. In any case, if you can't resolve the issue, if you can't be at peace and if there is no end in sight then you need to move on before you grow bitter and hurt your reputation. Oh and if you and your boss are at odds, you can be sure that you'll be the first on the chopping block when it's time for cutbacks.
You are working insane hours. We work in I.T. and in crunch time we do whatever it takes to get the job done. I'm sure you all have your own war stories of long nights and 24 hour days. We're proud of those. They're badges of honor. But those should be the exception not the rule. If everyday becomes crunch time and unrealistic expectations are the norm, then you need to get out. It's a tough call to make. I've been there. Your boss promises that you're almost over the hump and then it'll get better.... months later he's still promising it, with genuine sincerity, but in your gut you know there's no end in site. It's time to move on before you burn out and it starts affecting your health, your work or your relationships.
If you're not learning anything. If you are no longer challenged and if most of your learning comes from off the job then it may be time to move on. Technology is moving faster all the time and if you aren't moving forward you're getting left behind. This is one situation that can respond well to a frank talk with your boss about your concerns, but if you've exhausted all other avenues you need to consider making a move, before you get trapped in a dead end career .
You are grossly under compensated. Money isn't everything, but then again you don't want pay inequities to be abusive. If there is a significant difference between your salary and others at the same level in your industry then it may be time for a change. I worked a company once where where every few years people would take a job somewhere else and come back in a year making significantly more money simply because the pay structure favored new employees over loyal employees (i.e. base rate increases over time dramatically outpaced yearly pay raises). If your efforts to address the inequities have been ignored or rebuffed then you may want to consider your options.

The above points can be categorized as Security, Environment, Workload, Skills and Pay.

If you're having one or more of the above problems with your current job then I'd say it's definitely time to start looking for other employment, even if, given the current economic situation, it's a slow steady search over time.

As a wise man said recently, YOU, and NO ONE ELSE, is responsible for your career.

Be careful that you never allow yourself to be be paralyzed by either the comfort of your current circumstances or the fear of change. Change is inevitable; change is life. If you're comfortable now, don't become complacent; hone your skills and build your experience... change is coming.

Update: Shortly after writing this post and moving on to my new contract to hire position, my new employer (owner/developer in the small 2 man shop I signed on with) decided I wasn't a good fit. No really satisfactory reason given... he was the owner, he got a gut feeling... that was it. I received the call Monday morning as I was leaving the house not to come in that day.

It was a gut punch. With the economy down I knew there were only a handful of positions out there and I felt the world crashing in.

Fortunately I was in good standing with my old employer and my old boss and his boss jumped through a bunch of hoops with HR to get me my old job back (especially tough since 2 rounds of layoffs had just happened). I am grateful and very personally touched by the effort made to bring me back.

In this midst of this I immediately pulled the above post, not wanting anything to jeopardize my chances coming back. I finally feel comfortable putting this back out there (as of 6/22/09). Having gone through all of this and had time to reflect on what I wrote I still think I got it right, but with a few caviots:

Be very careful about your decision to leave; a job is a very precious thing.
Be very careful how you leave; don't burn any bridges.
Be very careful what you put on your blog when you leave; many people at my work read this blog post after I left... I'm so glad I didn't, even accidentally, write anything questionable or anything that offended anyone. Even so I rather wish I'd waited a month or two before posting it.

And finally: Thank you again to those who helped -- I am both humbled and touched by the decision to bring me back.

Accessing Page data via Session in WebMethods

2009-03-01T00:01:00.003-05:00

Asp.net public static methods that are marked with the attribute [webmethod] are available as Ajax calls in JavaScript. Unfortunately these methods can't access the Page object or any non-static values or objects.

The solution? Create one or more static properties and use them to store the data you need in your session.

static IAccount account
{

get
{
return (IAccount) HttpContext.Current.Session["MyPageAct"];
}

set
{
HttpContext.Current.Session["MyPageAct"] = value;
}

}

Now you can initialize this property in your page load event and because it's static it can also be accessed from your web method.

What we gain when IE6 finally dies

2009-02-21T10:26:00.001-05:00

IE6 is on life support. The latest update I could find says IE6 had only about 20% of the market as of February.

I've mostly ignored IE7 up to this point, because as a corporate developer I have remained bound by all of the limitations of IE6. But since IE6's demise seems eminent I decided to do a quick review of what we'll gain when it finally bites the big one.

Alpha channel PNG support(I've been avoiding transparent PNGs until now because the IE6 work around was such a pain)
:hover on all elements not just on anchor tags (Woohoo! no more rapping DIVs and images in anchors)
Width and Height Min/Max supported (is it Christmas?)
CSS2: first-child, adjacent, and child selectors
CSS3: attribute selectors: prefix, suffix, substring and the general sibling selector
About a million bug fixes....

For full details I highly recommend this August 2006 IE Blog post about IE7 and you may also want to read this February 2009 one about IE8 to see where we're headed.

The future of computers is in your pocket

2009-02-16T15:15:00.024-05:00

The future of computers is in your pocket. It's currently known as a cell phone, but I don't think that moniker will stick around very long.

I imagine that some time within the next 8 to 15 years things will be wildly different.

Picture this:

You get a new job. On the first day you are given your company computer which you promptly slip into your pocket. When you get to your desk you dock your computer next to your monitors and log in to the network.

That night you decide to do a little extra work from home. You take your work computer and your personal computer (which was in your other pocket) and slip them into a docking station next to your television. Working from your recliner with a wireless keyboard and mouse you toggle between your the two computers so you can get a bit of work done and catch up on your personal emails. A football game is on in the upper right hand corner of the screen and you quickly switch to it to catch the instant replay of your team scoring a touch down.

Unfortunately for you your new job requires a bit of travel. On one of your many business trips you decide to slip into a coffee shop to have lunch and get some work done. You pull out your laptop, which is just a cheep accessory with no real processing power. It's a super thin keyboard and screen paired with some sort of wireless technology to allow input and output to be exchanged remotely with your computer (which of course remains comfortably in your pocket).

This is the future of computing. I probably have the timing off and I think there'll be parts where the technology will far exceed my expectations, but I'm pretty sure I'm right on this one.

Only time will tell.

Update Panel, Partial Postback and Javascript

2009-02-13T10:21:00.013-05:00

OK, so here's the problem. I have an update panel and after it refreshes I need to run JavaScript to initialize tabs within the panel based on their state before the refresh (partial postback). I tried getting the onload event of an element within the panel to fire and explored a few other options, but nothing I did was successful.

It's at this point I need to send out a big thank you to David Ward at Encosia.com for documenting a simple solution to triggering JavaScript on partial postback client-side initialization. It turns out that Asp.net wires up any JavaScript method named pageLoad() to the Application.PageLoad event so it not only gets called on the initial page load but also on any partial postback. With this fact in hand getting my JavaScript to fire was a snap.

This is my final code:

pageLoad = function()
{
  if(this.isPostBack != true)
  {
    cr.initPage();
    this.isPostBack = true;
  }
  else
  {
    cr.initTabs();     
  }
};

You'll notice that I initially test if this.isPostBack != true, but since it doesn't exist yet it can't be true. This allows the first if block to run, initialize the page and set this.isPostBack to true. All future times the pageLoad function is called will be in post backs. At that point this.isPostBack will return true because my previous setting of this value was preserved through the partial post back and my tab initialization will run.

Again thanks to David for pointing me in the right direction.

Firefox and Blogger conspire against me

2009-02-10T11:30:00.006-05:00

I recently discovered that my post on image layering was not displaying correctly after a minor edit to the post, despite the fact that I had tested the post beforehand in IE6, IE7, Firefox, Chrome, and Safari. On examining the post I was surprised to find that the markup had been changed.

The first problem I found was that my image urls had been altered (slashes and http stripped from the CSS... just weird). I had to fight to get blogger to accept these, but eventually they went through. I also just found that IE6 was still having problems, so I've made yet more changes to fix that.

After a bit of experimentation I found source of the IE6 problem (though the url problems still remain a mystery). When you click the blogger Preview link to preview your post, Firefox strips the markup of all IE specific CSS and injects additional Firefox specific CSS. When you click Hide Preview, blogger apparently pull this updated markup back into the HTML Editing textbox. Since previewing is normally the last thing I do after I edit a post I didn't notice the markup changes. Of course everything looked fine when I viewed the edited post in Firefox, because Firefox had optimized it.

So if you happened to have viewed my image layering post and my examples looked really bad please check them out again. I'm sorry for the inconvenience.

The benefits of ergonomic keyboards and mice

2009-02-03T23:00:00.015-05:00

I'm stunned by how many companies now give developers two large flat screen monitors by default but scoff at the idea of getting them ergonomic keyboards and mice. The cost is a fraction of that of a single monitor and can prevent injuries (downtime) to people who are critical to company operations. I imagine it's because dual monitors have been widely praised for providing a productivity boost to developers (and rightly so), but ergonomic keyboards and mice have not been; health concerns are just a tougher sell.

The surprising thing about ergonomic keyboards and mice is that they tend to have productivity features built into them, including programmable keys that can be customized per application. The added productivity from this, even if you consider it to be rather minimal, adds up to to more than enough on a programmers salary over a year to justify it's purchase. Unfortunately these gains are not yet being shouted from the rooftops, so it may be sometime before companies come around.

I was looking forward to posting about my weekend acquisition of a Microsoft Natural Ergonomic Keyboard 4000, one of the most well designed and pleasing devices I've ever used (and it has tons of programmable features to boot). So I was surprised and little peeve yesterday morning to find that Jeff Atwood over at Coding Horror stole my thunder by touting his re-purchase of the Keyboard 4000. My only consolation is that at least he didn't purchase a Logitech Marble® Mouse, my second favorite piece of data-entry paraphernalia, so I can independently tout it's virtues.

The Marble® Mouse is a trackball and its symmetrical design means that it can just as easily be used by you lefties out there. It has two additional programmable buttons that can be set to nearly any function you like. While it may take a little adjustment for those of you who haven't used a trackball before, I think it's far superior to any other mouse I've used; even more so if you have limited desk space, as I do.

I realize that my preference for these particular ergonomic devices is to some degree a matter of taste but, what ever device you choose, I would encourage you to to start using ergonomic devices as early in your career as possible to ward off future problems. And if you're already having problems... QUIT PUTTING IT OFF! I don't know why but we developers, myself especially, seem to ignore common sense measure at taking care of ourselves. As the minor health annoyances of middle age and the detrimental effects of a sedentary carreer in front of a computer start to set in, I'm starting to take things like this more seriously.

New Year's Reflections

2009-01-01T13:06:00.010-05:00

I'm in a somewhat pensive mood this New Year.

Given the downturn in the economy, I count myself blessed to have a good job and that my family had a good Christmas. We're healthy and all our needs are met. I am deeply thankful to God for all that He given us. I think that too often I take for granted how truly blessed we are.

Some people that I know have had setbacks and struggles recently, even in the past couple of weeks. For them and for all of you who are struggling I pray that God will help you and turn things around for you quickly this new year. I wish you and yours the best.

And so, with such sobering thoughts in mind, I come to my New Years resolutions:

Be more thankful this year; take nothing for granted.
Be diligent and more conscious how I am spending my time.
Take more time for family; don't let the little, important things pass by unnoticed.
Cheer up, enjoy life and quit being such a grouch.

Time to start putting that last one to work. Sorry to be such a buzz kill. I wish you all the best. Happy New Year!

Why you should be reading this in Google Reader

2008-12-26T02:25:00.008-05:00

I've started doing an informal survey of people in I.T. about their blog reading habits and a surprising number of them follow blogs by, get this, actually going to the website; not so long ago I was one of them. I knew about RSS and feed readers, but the idea of installing another program and checking it for content was less than thrilling to me.

When I found out about Google Reader I decided to give it a try... After signing up and I went to my iGoogle Page, and added it as a gadget. The beauty of this was that anytime I went to do a search I would have a small number of posts waiting to distract me... OK, maybe that's not exactly beneficial from a productivity standpoint but I am a big believer in information snacking and when I've hit a dead end and need to do research, it's probably time to give my brain a brief rest anyway.

Actually Google Reader did solve some important problems.

It kept me from having to look for useful information to distract myself with when I needed a break (snack attack).
It allowed me to flag important/longer posts for a more thorough read later (so I didn't have to finish them if I was in a pinch for time).
It made discovering new content easy. Google Reader will make suggestions based on your current subscriptions.
Most importantly it made reading blogs convenient. The fact that it's web based means it's just there. Whenever and wherever I go online I it's always waiting for me; I never needed to think about it again. Once I subscribed, up to date content was always at hand.

I'm not an early adopter of tools and technology. This is mainly because, no matter how cool or beneficial the technology is, if it's a pain I won't use it. For me convenience is my tipping point; once something becomes easy to use or, more importantly, makes my life easier, then I'll try it.

If convenience is a sticking point for you too then you may want to give Google Reader a try. If you do I'm fairly certain that you'll be hooked on reading blogs via RSS too.

C# - A Simple Infragistics Ultra-Web-Chart Bar-Graph Example

2008-12-23T14:10:00.007-05:00

I'm not a big fan of Infragistics. One of my biggest annoyances with them is that it's really had to find documentation on how the different controls work. Since I couldn't find a simple example of manually loading data into their UltraWebChart control (though many ultra-complicated ones) I thought I'd post the code here in the hopes it may help some of you out there.

If you drop an UltraWebChart on a page and add this code you'll get something that you can start to play with.

protected void Page_Load(object sender, EventArgs e){

UltraChart1.ChartType = ChartType.ColumnChart;

DataTable columnData = new DataTable("ColumnData");

columnData.Columns.Add("Month", typeof(string));

columnData.Columns.Add("Foo", typeof(double));

columnData.Columns.Add("Bar", typeof(double));

//Add additional columns here; for each column add a parameter to each row below.

//Below uses params so additional columns of data are comma delimited

columnData.Rows.Add("Jan"/*Month*/, 3400/*Foo*/, 1200/*Bar*/ /*, YourNewColumn*/);

columnData.Rows.Add("Feb", 2300, 1200);

columnData.Rows.Add("Mar", 5994, 1200);

UltraChart1.DataSource = columnData;

UltraChart1.DataBind();

}

Asp.net Work Around - Display Nested Master Pages in Design View

2008-12-22T10:10:00.002-05:00

Here's a quick workaround for displaying nested master pages in Asp.net design view. As you may know, when you switch to design view on a page that inherits from a nested master page you will normally get the following notification:

"Design view does not support creating or editing nested master pages. To create or edit nested master pages, use Source view."

Interestingly if you place a space after the reference to the master file name (e.g. MasterPageFile="~/TemplateC.Master ") the IDE will let you switch to design view, only now you will get the following error in your error list.

"Could not find master '~/TemplateC.Master ' "

Once you rebuild your project that error disappears as well and everything works fine at run-time. In the design view you'll see all of the content that you have added (but not the content inherited from the master page). This will allow you access smart tags and wizards for configuring controls and do a little visual editing.

The lack of a full view of your page with inherited content is limiting. However, because the design view often greatly differs from the different browser renderings(including IE) I have long since gotten into the habit of keeping a browser open on my other screen to use as my "Design View" during development.

Hope this helps... I know it was really bugging me.

There's more to Software than just the Code

2008-12-16T01:08:00.010-05:00

You may have noticed that the site logo now has cleaner graphics/typography along with the new tag-line "There's more to Software than just the Code".

The new tag-line isn't meant to imply that I don't plan to post code from time to time -- currently I'm doing web development using c#, asp.net and AJAX and that's is bound to work it's way in -- but I knew from the outset that I wanted to keep this blog fairly language agnostic and try to focus on principles, concepts and topics that would apply to a wide array of programmers. My recent post about Renaissance Developers lays out the kinds of topics that I plan to cover (typography, graphic design, UX, Testing, etc).

The tag-line is my way of saying that I think that we as software engineers too often emphasize coding to the exclusion of other helpful and necessary skills. In light of this my focus and the focus of this blog have been broadened to discuss a variety of skill-sets and topics, coding or otherwise, that are beneficial to developers seeking to create truly great software.

UI/Graphic design should matter to developers

2008-12-11T01:55:00.012-05:00

For the first time I'm working at a company that has a graphic-artist/web-designer. He's very good at what he does -- if you are in the position to hire such a person for your company I highly recommend that you do; it pays dividends. At a lot of companies though we developers are all they have and we need to start making an effort.

How often have you heard someone say "I'll make the form/webpage/whatever, just don't ask me to make it pretty" or something of the sort? Starting out as a developer I made similar comments myself.

Why? Because no one likes sucking at what they do and if you can blow it off like it's not something important then you don't have to feel bad when what you turn over sucks. Then, of course, there is the moral superiority of being a real coder, not like those mamby-pamby Graphics/UI guys.

Over time I had to do more and more front end work and, being the kind of guy that hates to suck at anything and loves to learn, I started to study graphic design and User Interface(UI) design. The more I learned, the more I began to understand how important it could be to the company and the more I cared about the quality of the work I was doing.

Now just to be clear I'm not saying that you have to be a graphics guru, but if you are doing any work that is visible to the customer/client then what you do affects the bottom line; it can make a good product less usable and a good company or product seem unprofessional and unpolished. A considered, consistent layout with some subtle gradients, and a few graphics will take you a long way and a bit of study and practice will set you in good stead to producing consistently visually appealing work. If you already work with a designer then you'll be better able to understand their viewpoints and have a stronger team because of it.

Continuous learning is part of our jobs, part of staying competitive in our field, and that's starting to mean more than just staying on top of the latest programming languages and methodologies. The more you can learn about UI and graphic design, the more valuable you will be.

The Renaissance Developer

2008-12-03T23:55:00.012-05:00

You may be familiar with the concept of the Renaissance Man, someone who, like Da Vinci, explored art, science and writing and excelled at all of them. This got me thinking -- what would it mean to be a renaissance developer? It takes a lot of time to master one field of study let alone many, but following the concept of the T-Shaped person I think it is important that we branch out, explore related fields and become as well rounded as we can, with the idea of the renaissance developer being something to strive for.

Picture from the Wikipedia Commons

A true renaissance developer would be someone who is not only a excellent developer in multiple languages, but who also appreciates all of the ancillary fields in their work (business, design, marketing, configuration management, testing, etc.) and strives for a level expertise in as many of these fields as possible. Because of this their applications should not only be well coded, but they should also look good, be extremely usable, secure, testable, maintainable, configurable, scalable and easily deployed and thoroughly meet the needs of the users and the company.

That said, what skills does the up and coming Renaissance Developer need? Well here's a short list of things that I think are important:

Multiple language/enviroment expertise
Interaction Design(IxD)
User Experience(UX)
User Interface(UI) Design
Information Architecture(IA)
Software Architecture
Graphic/Visual Design
Security/Hacking (know thy enemy)
Configuration Management
Software Testing
Marketing (not bad marketing, like our product sucks but we want you to think it's great and buy it anyway; good marketing)
Typography
Business
Writing

There may be more that I haven't considered yet, but those are some quick qualifications for a renaissance developer. I have some followup post on many of these already in the works, so I'll be talking on this more.

Oh and I'm not implying by any of this, or by my blog in general, that I think I have "arrived". I believe in continual learning. I think that becoming what I now refer to as a renaissance developer is a lofty goal and, having found a excellent destination, I have set my course in that direction. I invite you to come along on the journey.

You may also be interested in the following posts:

Agents of Change and Enablers of Change

2008-11-30T03:14:00.003-05:00

A good manager is an enabler of change. Once they find out that their team has a problem they do what ever they can to resolve it. They fix the process, they get the tools, they deal with the bureaucracy... what ever it takes.

What the manager needs on their team is one or more people who will be an agent of change. People who will be actively looking for problems and places where there is room for improvement and identifying them.

New people who come onto a team tend to be passionate, exited and sure that this time they're going to be part of a team that's going to do it right. Over time these passionate people, if not encouraged and valued by their manager, will become just another member of the status quo.

Too often I see teams who are bogged down in the status quo... the way things are. They fought those battles before and lost. They struggled with the bureaucracy and lost. They tried to do things right and were told "just do what you're told". Eventually they quit fighting the system.

If you're a manager, be an enabler of change and look for and encourage agents of change on your team. Find the people who are passionate about doing things right -- and don't let them get bogged down in the status quo.

Problems with wiki's in small groups

2008-11-29T12:29:00.007-05:00

At previous employers I have suggested the idea of a Team Wiki and have never been able to get one implemented. I had bought into the concept so thoroughly that I assumed if I could ever just get approval then people would quickly see the value and start using it.

So when I brought the idea up at my new job I was very surprised to hear that it had already been tried... twice; And people didn't use it. It seems the main problem was that there was limited collaboration because the team was small and segmented (not a lot of duplicated work/roles).

It's a lost opportunity because one of the best times to implement a wiki is when you first bring someone on board (like me). Then every time they ask a question you have them document the answer for you and you review it to make sure that they understood. When the next new employee starts then have them search the wiki for answers before asking questions. If the information there is hard to understand or wrong, have them clarify or correct it.

The biggest benefit of having new people do the documentation is that they will get the details that are ignored by those who already know the system (because once you know a system everything seems intuitive and obvious).

I'll have to put some more thought into how to make wikis successful in small groups. In the mean time I've started documenting the details myself before I get too used to everything; maybe I'll get the chance to turn that information into a wiki yet.

How to Revert/Rollback a file using Tortoise SVN

2008-11-20T07:14:00.004-05:00

It appears that a lot of you are finding my previous post about Revision Control Using Tortoise SVN when looking for how to Revert or Rollback a file using Tortoise SVN (at least per keywords in Google analytics). So I thought I'd throw this out right quick to help because I didn't cover it there.

As you probably know Tortoise SVN integrates into the explorer so that right clicking on a file lets you drill down into a ton of menu options. Not all functionality is deployed through the menu though; a lot is done through the Log. To roll back a file, start by right clicking on it and selecting Show Log.

Once you have the log open, right click on the desired version of your file. Your options will let you view this version or compare to your working copy (I highly recommend configuring Tortoise SVN to work with Beyond Compare if you have it; Settings/External Programs/Diff Viewer). The menu item that you want is "Revert to this Revision".

Upon selecting this Tortoise SVN will notify you that it is doing a reverse merge into your working copy; click yes. You will note that your file has been reverted/rolled-back and is showing as changed (red dot on icon). Commit the file (or make changes and commit) and you're done.

Hope this helps.

Blogiversary: One Year of Blogging

2008-10-07T23:52:00.004-04:00

Well it's been one year of blogging and it's been a lot of fun; I don't think I'm in danger of stopping anytime soon.

Some months have had more posts than others, and over the next year I'll try to be more consistent. I plan on trying to get out 1 post a week (more or less) as I think it's pretty sustainable -- though I averaged a little less than that this year.

I hope you have enjoyed the blog. Thanks for reading.

Work-life balance

2008-09-13T00:01:00.004-04:00

This month I ended one job and started another. My decision was based in part on the fact that a portion of my old company (including me) was sold to another company. This resulted in me being abruptly pulled away from my team and my boss, both of which I liked a lot, and from the cool rearchitecture we were working on; That, as well as all of the uncertainty of transitions like this, made it an ideal time to make a break.

So, having made the decision to move on, what was the most important criteria in my job search? Outside the usual things (tools, environment, professional-growth) I added a new criteria to the top of my list; as the old real-estate saying goes: location, location, location.

My previous commute was 50 minutes each way; my goal was to get my commute down to a maximum of 25 minutes each way, preferably less. Actually I was able to get it to quite a bit less; my new commute is just 10 minutes, which gives me a whopping 1 hour 30 minutes of my life back per day.

So what does this move get me? more family-time(hey kids, my you've grown) and free-time(blogging! exercise?), less money spent on gas, less wear and tear on my car, and less traffic related stress. And with a 5 minute drive home for lunch it means eating healthier and more time with my wife without the kids. It also means I can be there for parent teacher conferences and similar things without taking half a day off from work.

As much as many of us long for work-life balance, it's been my experience that it still falls to the bottom of the list in light of more practical concerns. The real question about work life balance is how can more of us have it and have it more often?

With telecommuting being nearly unheard of in I.T. (unless you know something I don't) the best we can do is either take a job closer to home (not easy but not impossible) or move closer to work (seldom practical and certainly not popular with my wife). Oddly enough it's customer service jobs that seem to be taking the lead in telecommuting and then only when the companies can work it decidedly to their advantage. My hope is that more companies will open campuses or small branch offices near the suburbs where developers actually live; well that and that more companies will see that I.T. staff are exactly the kind of people who could excel in a teleworking environment (even if for only a few days a week).

There are probably longer commutes somewhere in my future (hopefully far far away) but I am enjoying a more balanced life now and I plan to make the most of it. I hope that you have the opportunity to do the same.

Audio: Jared Spool on Designing for the Scent of Information

2008-09-13T00:00:00.005-04:00

(Recommended Audio -MP3 from webjamsession.com)

Another excellent talk from Jared Spool for all of you web developers out there. In this podcast he talks about the scent of information and how your content and design should suck, by which he means pull users toward the information that they are looking for. He also explains what trigger words are and how they allow your users to find the content that they are looking for. He also walks you through several user testing scenarios on different websites and gives a lot of real world examples; there's really just a ton of great tips and information here.

Quit Commenting Out Dead Code

2008-09-09T19:40:00.002-04:00

If you're one of the guilty parties who leave dead, commented-out code in the code base please stop.

Seven reasons to delete dead code:

It's dead.
The dead code is only valid/useful in it's original context and as the code continues to change that context will quickly disappear.
It's in source control history anyway (in it's original context). You are using source control aren't you?
When you checked in your changes to source control you should have noted in the comments box that you deleted the code and why (assuming the deleted code was important).
In the future neither you nor anyone else could really trust that the code is valid even if it does need to be put back in place; it's probably just as fast to rewrite it as to validate it.
If people do need similar functionality they might be tempted to use the commented code as a crutch without really understanding what it does, and when they do really bad things will happen.
The code will stay there... forever. No one else will delete because they won't know why it was removed and they'll be afraid it contains some magic bullet that may be needed sometime in the future (after all it must have been left there for a reason). In three months even you won't remember why you removed it, your comments will seem unclear and you won't delete it either because you'll be just as afraid as everyone else.

I'd like to jump back to number 4 right quick... you are filling in the source control comments when you check in a file, aren't you? This takes 60 to 90 seconds tops and really improves the value of your code history. When someone looks at the comments they should see at a minimum the ticket or project number (or emergency situation) that instigated the changes and a 1 to 3 sentence summary of what you did.

And don't cheat and check in 60 files at once and put "updated for ticket 0974". Though this is better than nothing, in most cases checking in each file individually and commenting on that file in the context of the ticket is much more useful e.g. "ticket 0974: added a link to header menu to point to the new analysis engine (only available for administrative role); fixed menu formatting problem; removed commented, dead code from my previous changes.". Now if someone reviews you're changes they can look at your comments, do a file compare to the previous version and understand exactly what you changed and why.

The down-side of the big new client

2008-08-27T13:10:00.001-04:00

Let's say you have a new customer that you're about to bring on board that will grow your business significantly, say by forty to sixty percent. Is this a good thing or a bad thing? From some perspectives of course it's good, especially if your company needs the money to keep its head above water. Even if that's not the case, additional profits are always welcome.

Something to think about though... how will your current system hold up under the load? How maintainable is it? How scalable is it? What will happen when those nightly jobs that normally run into the wee hours of the morning come under double load and now don't finish before users log-in in the morning? What impact will those reports that are directly hitting against production data have when they pull twice as much data?

Perhaps those aren't you your problems, perhaps you run a good clean shop and there are no skeletons in your closet. Still, trust me, there will be problems. Given this much growth it's just entirely too likely that there will be things that do not scale under the additional load (even if you don't and probably can't know what they are yet).

Of course the work that these problems require is in addition to the other work that the client will generate. What new features and reports has the sales team promised? For a client this big I can almost guarantee there were some. If you're lucky sales has had conversations with I.T. to verify that they can meet the demands. Still, what is I.T. going to say? "No we can't do it; you'll just have to turn down the really big client." Not likely.

Sadly though, these probably won't be the last of the new customers demands. The customer knows how valuable they are to you and they'll likely use this to their advantage. They're in the position of power. What happens if they continue making demands? What happens if they get frustrated and leave?

Worse yet what happens if they stay? Will you burn out your IT staff? Your development team was likely at or just above capacity. If you have a small team it will take at least 2 to 3 months to staff up if you want competent people and then it'll take another 2 to 3 months for them to become really productive. And this is if you're lucky; sometimes it can take a really long time to fill just one position. Sometimes, after a long search, you hire someone really good and you're feeling great... and then they leave after a week and you have to start all over.

Have you started looking yet? Don't wait too long or your development team may start to buckle under the demands and then you'll have turnover to worry about. Let's say that your team manages to stay on top of things. Did they do it by cobbling together brittle, unmaintainable code under the pressure of unrealistic time lines?

What about the plans the business had for innovation and revolution... the types of things you were doing that brought in this big new client. How long are you delaying them? Will they ever be revived. What about the really talented developers that you had working on these cool new projects? If you reallocate them to the new client work will they get bored or frustrated and jump ship.

Slow, steady growth is best, but it may not be possible to turn down a big new client, even if you know you're not ready for them. So what do you do? If you go forward you'll need to mitigate the risks as quickly as possible.

I think the main the problem is often just poor planning and communications. You can't blame the sales staff for aggressively pursuing new clients; that's their job. But someone has to be coordinating their efforts with preparation on the I.T. side well in advance of anything actually happening. Someone has to be looking at the big picture.

Some one has to say, "We're planning to double our business, what do we need to do to support that?". In general, big clients do not come on board quickly; there should be adequate time for preparation if only you're careful to plan for it. Just don't be blinded by the profits and don't rush things.

Living in a Dilbert World

2008-08-19T10:00:00.001-04:00

Have you ever found yourself living in a Dilbert world at work? You know when you're working in an otherwise sane company and someone does something so bizarrely wrong that you would have sworn it could never happen in real life so you must be in a Dilbert comic?

At a previous job there was a problem with an integration server which was traced back to a USB flash drive that was accidentally unplugged. Apparently the server was low on memory so someone plugged a 2 Gig drive in and moved a critical database onto it. Then when someone else saw the flash drive and removed it (likely thinking, "Hey what the heck is this doing here?"), the integration environment went down.

This is yet another example of the short-term fix myth in action. In addition to the to the fact that short term fixes are a maintenance disaster and get you deep into technical debt, they are often really bad ideas in and of themselves for other much more basic reasons (such as the fact that pulling out a flash drive will bring down the integration environment).

Audio: Jared Spool on Incremental Redesigns

2008-08-19T09:59:00.002-04:00

(Recommended Audio - MP3 from UIE.com)

This is a great podcast on the risks of large redesigns and the benefits of incrementally redesigning one piece at a time. I've wondered before why this isn't done more as it seems to me it offers a lot less risk for only a little more effort. The audio is rather brief but it covers the content well and it was just great to find someone talking about this.

Dealing with bottlenecks

2008-08-13T10:00:00.002-04:00

I was very interested in what Kent Alstad had to say about bottlenecks so I pulled out what I could get from his talk and tried to fill in the gaps. After a bit of study on my own here's my take on it.

First we know that there are always bottlenecks in distributed applications (web or otherwise) and though they may not initially be apparent, under enough load they will show themselves.

There are three main types of bottlenecks:

Memory bound – Too much data being cached or too much data being held in processes at one time for the specific amount of RAM on a system.
CPU bound – Too many processes and/or one or more intensive processes consuming the the all available CPU time.
IO bound – Processes fighting for their turn to read and write data as well as different processes contending for access to the same data.

Once you hit your first bottleneck you can fix it in hardware or in software or both.

Hardware/Design solutions to bottlenecks:

Scaling up – Increasing performance by improving hardware: adding faster/more processors, faster/more drives, more memory.
Scaling out – Increasing performance using distributed architecture (adding more servers); more servers share the load by processing different pieces of a process or having a piece of the process duplicated on two or more servers. This approach often requires that software changes be made to distribute the load across the servers. Also JavaScript and Ajax are often used to scale out by distributing some processing to the client; remember to include client-side compute time in your performance analysis, not just server side compute time.

Software Solutions to Bottlenecks:

Cashing – avoid reprocessing/re-querying data by storing the results in memory for future use.
Finding inefficiencies in database design and stored procedures and correcting them.
Normalizing/flattening data to decrease query time.
Profiling code to determine the slowest methods and then performance-tuning that piece of code to make it faster.

Remember: No matter how scaled-up or scaled-out you are, there is always another bottleneck.

Revision Control using Tortoise SVN

2008-08-10T19:18:00.005-04:00

As I mentioned previously, now that I have decided that I really enjoy blogging and plan to stick with it, it's time that I start putting some work into my site. So how do I make (possibly) sweeping changes to my site without risking a misstep that will flush everything down the toilet?

Well the first thing that I need is some sort of Revision Control System. Revision/Version/Source Control software allows you to track all changes that you make to your files and to compare different versions and roll back to whatever version that you choose. It's particularly useful if you have multiple people working on a project as it usually has mechanisms in place that help you resolve changes made by different people and it keeps everyone on the same version of the project.

The concept is simple. Change a file, check it in. Change something else, check it in. Think you made a mistake, compare versions and roll back if need be. Roll out to test. Find a bug, fix it and check it in. Once the release is solid push it to production. If you find a bug in production you can pull the last release from source control and roll back to it.

Some common/popular open source solutions include Subversion, GIT, and CVS. I had previously heard good things about Tortoise SVN (a Subversion Client), which won the SourceForge.net - 2007 Community Choice Award for Best Tool or Utility for Developers. It's a shell extension so integrates directly into windows explorer, which makes it very easy to use.

It took me about 15 minutes to create a repository and get a handle on the basic functionality. It was all fairly intuitive. Right clicking on files allows you to access a context sensitive menu. The "SVN Commit" command saves your changes. The "SVN Update" command pulls the latest version of a file or directory down. A sub menu provides more advanced features.

It would be nice to have it accessible from the Visual Studio IDE and I understand there is at least one Subversion Client that lets you do just that for a price, but I wanted something free and for the small scope of this and other projects that I'll be working on Tortoise SVN is more than enough. Also because it inserts itself into windows explorer it is not limited to software development but can be used on any files that you need to track versioning on.

P.S. I've added a post on how to rollback or revert a file using Tortoise SVN since many of you seemed to be looking for that info.

Firefox: the Dominant Browser of Choice

2008-08-07T22:59:00.001-04:00

Official stats put Internet Explorer well in the lead in the browser wars, but that's mainly because most computers are sold with windows installed, which means that they get IE by default. A large majority of these people never even know that they have a choice in browsers. Among the people who are tech savvy enough to make a choice I believe people are overwhelmingly choosing Firefox. In support of this, here are some stats provided by Google Analytics about my site.

Notice Firefox's dramatic lead. People reading technical blogs are people empowered to make a choice and those people are overwhelmingly choosing Firefox.

So why Firefox? In a word, extensibility. Firefox was built with user added functionality in mind and lots of very talented people are very busy extending it. Firefox has hundreds of plugins for all sorts of things, one of them is bound to be right up your alley.

As a web developer the Firebug and YSlow plug-ins are a must. The added productivity and quality that these tools provide make the decision to design your site to support for Firefox a no brainier.

Analyze your sites performance
Monitor ajax http requests
Debug javascript
Syntax check your javascript
Drill into the DOM realtime
Make temporary changes to HTML, Javascript and CSS realtime to work out what if's

That last feature is really cool. Imagine sitting down with someone who is approving your site design and having them comment that they wish the font was a little bigger. You jump into the css and two seconds later it is. Image too small, spacing wrong? Zippity zip... "There hows that?". Keep a notepad handy because the changes can't persist, but that also means you can freely tweek things without fear of messing something up (just refresh the screen).

Public Library 2.0

2008-08-06T21:59:00.002-04:00

In junior high I'd ride my bike several miles to the library and ride back with a stack of books balanced on my handle bars. I read a lot of science fiction and studied everything from gemology and sailing to computers and lasers. In high school I started frequenting book stores more and more because the materials were up to date but I still made it to the library about once a quarter. Following high-school though I almost never went to the library; it was inconvenient and I seldom found what I wanted.

A few years ago I check my local library website out of curiosity and found that everything about libraries had changed. Welcome to what I'd like to call Public Library 2.0: the interactive online experience. Now you can:

Search the catalog of all libraries in your area and reserve books online.
Get an email notification when your book is available and pick it up at the location of your choice within 7 days.
Renew online if you need the book longer.
Get access to difficult to find books through the inter-library loan program. Library staff will locate the book by contacting college and private libraries. They'll have it shipped to them, and call you so that you can pick it up (this is great for technical books, even recently released ones).
Download popular audio books online and listen to them up to 2 weeks.
View your account online (books / requests / fines).

Because of the convenience of all of this I now rely on the Jacksonville Public Library as a reliable source of current information. I can't guarantee that your library will live up to these high standards, but I'd encourage you to take a few minutes to check your local library website and find out.

Audio: Leisa Reichelt on Waterfall Bad, Washing Machine Good

2008-08-06T21:45:00.002-04:00

(Recommended Audio - MP3 from dconstruct.org)

In this presentation Leisa talks about iterative verses waterfall development. She does not recommend a specific methodology, but instead elaborates on the failures of waterfall models and the benefits of iterative ones. If you have experienced the failures of waterfall and are looking for alternatives then this talk is for you.

Saying no to CSS Hacks

2008-07-31T20:35:00.001-04:00

Don't be lured to the dark side. Some people advocate CSS Hacks and call them CSS Filters, but if you are a programmer who is interested in maintainable code, look at this chart and tell me that hack isn't the right word.

CSS hacks are not maintainable. Every time a new browser version comes out you have to add new CSS to cover it (and hope it doesn't conflict with older hacks). Every time you change your site, the CSS must be updated for every browser branch that's supported. Just picture yourself as the poor developer who has to take over maintenance of a site like this in a few years; the choice should be obvious.

My advice: be creative.... just do it without the hacks. Yes, I know, I know. You had a really cool idea that takes just a few CSS hacks, and then you're golden. OK now be really creative and come up with something just as good, that doesn't need the hacks.

Audio: Kathy Sierra on Creating Passionate Users

2008-07-31T12:16:00.002-04:00

(Recommended Audio - MP3 from OOPSLA.org)

This talk was given at the end of last year. It contains a lot of great information about creating passionate users for your application (and creating applications that you're users will be passionate about).

The speaker, Kathy Sierra, is the author/co-author of many of the successful "Head First" technical books. She is also one of my favorite bloggers. Unfortunately she left the blogging scene following problems with extensive online harassment and threats from a small group of crazies. Her blog Creating Passionate Users can still be read at headrush.typepad.com.

Blog Changes

2008-07-30T02:59:00.002-04:00

When I started blogging I threw this site together over a few evenings. I set it up on blogger, which is free, and figured that if I found that I liked blogging I would do more work on it later. Since I've decided that I want to stick with it I think that it's well past time that I clean-up/redesign the site because as a software/web developer, the quality of my site is a reflection on my skills. I have started that process today.

Originally I was going for a blog / wiki concept where I could blog on topics and link to audio, book reviews, definitions, people profiles, and possibly other content. Because this content was separate from the blog it wouldn't clutter up my posts and could be updated as necessary. The additional content was available via a menu at the top and though I was never really happy with this approach, it seemed a good way to start. In retrospect I've found that the additional content was seldom visited, and that working on it was a pain and a distraction. I also thought that the menu cluttered up the site and that the point of the other sections might be lost on visitors/readers, and that a lot of the information was only useful/desirable within context.

If you visit my site now you'll notice that I have removed the menu bar at the top. Also the book review and audio review sub-domains have been disable.

Audio reviews (commentary on talks, webinars, etc) have been inlined with the main blog because I find them valuable. Because of this subscribing to my RSS feed in ITunes or similar software will provide a podcast of my recommended audio. I have removed Book reviews completely as I have found that I really hate doing them. I have decided to keep the areas for people and definitions but these really didn't need to be in the menu as they are just places for me to add ancillary/supporting content that I could link to.

I am still not satisfied with the site and will make further changes to it as I have time. Because of the changes some links to ancillary data in past posts may be broken; I will try to clean this up as quickly as possible. Thanks for your patience while I figure out a better format.

The New Spagetti Code: Indirection

2008-07-28T02:59:00.003-04:00

Traditionally when the term Spaghetti-Code was thrown around you would hear talk of goto statements. If this, goto line number (or label)... and when you got there it would send you some place else, which would send you some place else to infinity. It was kind of like procedural programming without any encapsulation or meaningful names, where the code could and did step all over itself, and you had no idea why. If you don't know what I'm talking about, count your blessings.

One of my favorite aphorisms is credited to David Wheeler who says: "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." The new form of Spaghetti Code is what I guess I'll call Spaghetti-Code by Indirection or perhaps YALI(Yet Another Layer of Indirection). Essentially it goes like this... You're doing maintenance on some code and you've tracked the problem to a particular method, so you step into the method in the debugger and that method instantiates another class. You go to that class and it gets an object from a factory class. You go to class that's being passed by the factory and it sends you to it's base class, which calls a class in the framework, which sends you to another class, which sends you to another, which sends you to another, which sends you to another, ad nausium.

Twenty layers or more in you find out that the business logic that's causing the problem isn't in the code at all... it's actually in a stored procedure. Congratulations you have just experienced the New Spaghetti code. It comes from overly complicated, poorly engineered solutions. That's why I think design reviews and code reviews are so important; there's no way that a programmers peers would let them get away with something like this, because for all they know, they might just be the next person to work on it.

Maintenance suicide: the short-term fix myth

2008-07-12T20:00:00.003-04:00

How many software features have you seen added on like this:

This is a great example of a short term fix... a bunch of bungee cords, a ladder, and a pair of vice grips to hold a red rag on the end. If you're moving a single piece of wood its no big deal, but I have seen far too many features or even whole applications cabled together like this.

Immediate needs require a quick solution... but in software development time is almost never allocated to clean up the mess afterward. That's the myth, that short term solutions in Software Engineering are ever short term. In reality they're left in place until they start to fail or can't meet current requirements. After all, a working feature will never rank as high as the next fire that crosses your bosses desk (and at organizations that regularly do things like this, there is always another fire waiting).

It's maintenance suicide. Short term solutions never hold up to long term use and changing requirements and they are nearly impossible to maintain. Lets take our current metaphor further... what happens when the business comes back and says now they need to move 200 pieces of wood at a time or that they need to be able to open the trunk while moving wood? Clearly the current solution won't work and we'll likely have to start from scratch.

And that's just what happens at short term minded organizations... there is never time to do it right, but there's always time fix it when it breaks or to just to do it over. A few years ago I was at an organization that ground to a halt after 6 years of short-term, business driven decisions. The short term fixes were breaking right and left under the weight of the growing business. Short term solutions are the antithesis of long term stability in a company.

T shaped people

2008-07-06T14:50:00.008-04:00

T-Shaped people are people who are deep or expert in one particular skill set and also have a number of complementary or tangential skills that they are shallower in. It is important to note that they do have a primary area of expertise and are quite different from a generalist or a jack of all trades (as the old saying goes, "Jack-of-all-trades; Master of none"). T-Shaped people are like the traditional I-Shaped person, a specialist, but they also branch out wider, where an I-Shaped person will primarily go deeper and deeper.

I like how David Armano relates T-Shaped people to being passionate about different things (basically a primary or core passion and many ancillary ones). I laughed when I read this because one of my favorite questions to ask people is "What are you passionate about?". I like passionate people, especially people who are passionate about programming. Kathy Sierra has said that "People aren't passionate about things they suck at". It's a fairly accurate truism, especially for people who have been doing something for a while.

I've been programming since I was a kid. I love being in-the-code, in-flow -- that state where all the pieces are in your head and everything makes sense and the code just rolls out. I love solving interesting problems, finding clean solutions and building useful things that help people do what they need to do and I don't think I could be happy in a job that took me away from that. That is my primary passion.

And then there are my ancillary passions...

I've put a lot of thought and study into development methodologies, team dynamics, and people management, but I can't believe I would be happy in any sort of management only role -- too many head aches and no coding. (I have been fortunate enough to have worked under two excellent managers who took the heat, dealt with the headaches and fought for the team so the team could get the job done. To Robert Killory and Miles Andrews, a profound thanks.)
I had my hands in configuration management for a while. It made me a zealot for source control and for easily deployable applications and I gained a real appreciation for people who can thrive in that role but my time was split between coding and config management and the time that I was away from coding became a painful distraction.
I love improving business processes (bad processes are a serious pet-peeve) but I'd go nuts as a business analyst -- too much documentation, too little creativity and no coding.
I have strong feelings about well designed databases and I love tweaking the last bit of efficiency out of complicated stored procedures, but I wouldn't want to be a DBA -- too much tedium, too little creativity.
I love user interface design and focusing on user experience and usability, but I need to have my hands in the guts of the application at least some of the time or I get restless.

So that's me... I can't stand being pulled away from code for long, but I love doing different things and having input on a lot of different aspect of a project. That, as I understand it, is a T-Shaped profile.

I don't think it's better to be T-shaped than to be a more traditional I-shaped specialist and I suspect having all T-shaped people might have its own hazards, but I do think having a few T-shaped people on any team helps the team dynamics. T-shaped people can bridge opinions between people of differing view points or find gaps where only one view point is being considered.

That's one of the key things that T-shaped people bring to a team: an ability to see many perspectives. Another thing that I think that they bring is the flexibility to temporarily fill gaps within the team and to take on new skill-sets quickly.

It's funny, but on those personality/learning/communications assessments that companies give out from time to time I tend to score fairly evenly across all the areas, leaning just a bit toward the logical/analysis aspects... I wonder if that is common among programmers who consider themselves T-shaped people. Also how many T-shaped people are bloggers? Is any correlation between the two?

You may also be interested in the following posts:

Learning another programming language

2008-06-23T23:02:00.002-04:00

I've been dying to explore some interesting non-Microsoft languages (among others, my list of includes PHP, Perl, Python, and Ruby/Rails). It's always fun to learn something new and can't help but feel that a different perspective will help me be a better programmer. Sadly I've been avoiding the task of overcoming the suck threshold of an unfamiliar, and likely command-line-warrior only, environment. What I really want is to explore a language and start being creative as quickly as possible without suffering through a big environmental learning curve. Last night I finally decided I just needed to bite the bullet, pick a language and dive into it. Funny thing though... just as I was ready to give in I may have found a way to get just what I wanted.

It turns out that there are open-source efforts underway to port many of these languages to the .Net environment. As with many things in open source there are often multiple efforts to do the same thing, only slightly differently. Some of these efforts are being built on top of the CLR but Microsoft is now encouraging the use of it's (relatively) new .Net DLR (Dynamic Language Runtime). The DLR is build on top of the CLR and makes it easier for the more fluid languages to be ported to .NET. I don't know where the chips will fall, but at least one of the DLR efforts has killed off it's CLR alternative (see Ruby.NET is dead). Also the DLR is being pushed as part of Microsoft Silverlight 1.1, which sets things further in it's favor. So, for the time being my plan is to only look into the DLR implementations.

Here are a some on going DLR efforts in various stages of development:

I haven't had the time for more than a cursory look at them yet, but I'll let you know what I decide.

Download Firefox 3 and Help set a world record today!

2008-06-17T07:51:00.002-04:00

Firefox is trying to beat the world record for the most downloaded software in 24 hours and you can be a part of it. It start's at 1:00PM EST today (check your timezone time here). Prior to the release time the download site also lets you pledge to download the software and so far there are over 1.5 million pledges. Join the party and get the latest version of the best browser ever!

Audio: Scott L. Bain on Emergent Design

2008-05-25T13:39:00.003-04:00

(Recommended Audio - MP3 From netobjectives.com)

In this webinar Scott L. Bain talks about the concept of Emergent Design and about best practices that reduce risk and waste in software development. This is a solid review of software design principles relayed from a new perspective... I highly recommend that you give it a listen.

Index:

00:00 Speaker & company plug
02:04 Speaker's background
03:08 Some questions about design
07:20 Overview of topics to be covered
08:28 Natural flow of software development
28:23 The open/close principle and design patterns
43:00 Principles and Practices

Adventures in Ajax

2008-05-23T00:43:00.001-04:00

My current project has me doing some hand coded Ajax (by which I mean that I'm not using an Ajax library). There are a couple of interesting findings I'd like to mention to anyone out there who might be doing the same.

As I watched the http requests (courtesy of "Charles") I notice that IE6 allowed only 2 concurrent Ajax requests and that Firefox allowed a maximum is 3. The impact of this is if you have several XMLHttpRequest objects processing requests (each object can only process 1 request at a time) you could have one or more ajax calls in queue. This might be important if you have slow response times or several different pieces of functionality making Ajax calls.

Another thing that I discovered is that while the async parameter for HttpRequest.open does not have to be specified, it actually defaults differently depending on the browser; in IE6 the default is true, but in Firefox the default is false. Not specifying this parameter will lead to Firefox locking up while waiting on requests.

Finally, make sure that you take slow response times into consideration. In your testing you'll probably have very fast response times, but in production your database server and web server are likely to come under heavy load from time to time. The result of this is that the action of clicking a button, which previously gave instantaneous results via Ajax, might appear to have no affect at all. Make sure there is some sort of UI feed back to the user that your application is processing their action/request. Also slow response times, database time outs and other issues may lead to failed requests. Make sure you handle these or they may lock up your application.

Hope this helps...

The beauty of JSON with Ajax

2008-05-07T00:18:00.002-04:00

JSON is a subset of the JavaScript that provides a fairly terse, dense data notation. When passed as data client-side it can be deserialized into a JavaScript Object with one line of code. In contrast XML is bulky and requires a fair bit of code client-side to parse and work with it. I believe that the denser notation and client side ease of use make JSON a ideal data transfer format for Ajax.

Lets take a quick look at some data in both XML and JSON formats...

XML:
<Table> <Rows> <Row><Item>1.1</Item><Item>1.2</Item></Row> <Row><Item>2.1</Item><Item>2.2</Item></Row> </Rows> </Table>

JSON:
{Rows:[{Item:[1.1,1.2]},{Item:[2.1,2.2]}]}

The leaner format can cut the size of your data in half and while you do loose a bit of the human readability with JSON, you can always use a tool like Charles to break it out into a tree view when debugging. The real beauty of JSON, however, is the ease of working with it on the client. If you deserialized the data into a variable called DataTable you can read first item in the second row by doing this:

DataTable .Rows[1].Item[0];

The trade off is that you will get cleaner, smaller client side code in exchange for more work getting your data into JSON on the server. Personally I'd rather have the extra code on the server where it can be unit tested and easily debugged than on the client where it can't.

Some might say that if you aren't using XML then you aren't doing Ajax. I disagree. I think that Ajax is actually a misnomer and so is XMLHttpRequest. XMLHttpRequest doesn't require that your data be in XML and will accept any format you choose. Believe it or not even JavaScript isn't even required to do Ajax; I hear VBScript works with XMLHttpRequest just fine.

I think that we've missed the big picture; JavaScript and XML aren't the reason why Ajax is such a phenomenal tool... it's the Asynchronous HTTP requests that it provides that make it so powerful. Also DOM scripting and DHTML are not Ajax, although they are used quite effectively in conjunction with it to provide the rich features that everyone associates with Ajax. The bottom line is that any site that makes Asynchronous HTTP requests is using Ajax and any site that doesn't, isn't.

The irony is that the one technology that is actually required for Ajax, HTTP, isn't even in the name. I think that AJAX would be better called Asynchronous HTTP-Request Scripting. Sadly AHS will never have the marketing appeal of the cool sounding Ajax, so we're stuck. As for the purists out there, I'm sure you'd prefer that I say that I am recommending "Asynchronous HTTP request scripting with JavaScript and JSON" than for me to talk about using JSON with Ajax. Sorry no such luck.

You're gonna love working with "Charles"

2008-05-04T16:03:00.002-04:00

Charles isn't a person, it's software and once you get past the goofy name I'm sure you'll like Charles as much as I do.

Works on:

Windows

Linux

With:

Internet Explorer

Firefox

Safari

Charles inserts itself between your browser and the internet. It's able to provide:

Bandwidth throttling - see how your website will behave at any connection speed slower than your own.
HTTP Monitoring -monitor data passing between your browser and the Internet.
AJAX debugging - monitor Asynchronous requests and responses in XML, JSON, JSON-RPC, and SOAP formats in a simplified tree view.
DNS redirection - redirect calls to a website to point elsewhere.
Browser cache disabling.
Cookie disabling.

I've been using Charles for a few weeks now and found it very useful. First I throttled down the connection to 56K and noticed that some images which were applied to tabs through CSS would take a moment to render when changing tabs(clicking changed the CSS class). It was clear that the image wasn't being cached. Checking Charles showed that the http header didn't contain an expires date so I set a far future expires date in IIS which caused IE6 to start caching the image.

I monitored the sites Ajax communications with Charles which showed that IE6 was caching my AJAX responses. A quick Google search showed that putting a date-time stamp in a query-string parameter would make the URL unique and keep this from happing. Charles confirmed the fix.

As a test I used the DNS redirection feature to set it up so that when I went to www.[ my website name].com the browser would think it was there but Charles redirected the browser to localhost. This could be useful if you were working on a site that had URLs hard-coded to the Domain or calls to Web-services that you wanted redirected elsewhere.

I also disabled cashing and throttle my bandwidth to view how the site would load on a slow computer for the first time.

I'm sure I've got a lot more to discover about Charles, but so far it is a solid, very useful piece of software. The bad news is that it's not free, but the good news is its affordable 50 dollars for a single user license, and only 400 dollars for a corporate (single site) license. In corporate terms that's a steal. I definitely recommend that you try it free for 30 days; the benefits should make it an easy sell to your boss.

On My Radar: UI Design Resources

2008-04-04T02:00:00.001-04:00

Though I haven't gone through it completely, at first glance DesigningInterfaces.com looks like a great site on UI Design patterns. The site is a promo for the O'Reilly book Designing Interfaces by Jenifer Tidwell and it contains a lot of the book content for free. I plan on going through the site and may pick up the book later. I'm always glad to see another good UI Design/Usability book pop-up; there aren't alot of the out there.

Another UI resource on my radar is the site csszengarden.com and the related book called The Zen of CSS Design. The site allows you to apply CSS designs from hundreds of CSS designers (no html changes only CSS) and the extent of transformations that can be made through CSS alone is truly impressive. I have skimmed the book and it seems to be a in depth study/walk-through of the better designs. It lays out why the design decisions were made and how they were achieved. It's definitely not a light read but I think it's likely to be worth it.

Audio: Fred Brooks on Collaboration in Design

2008-02-17T12:42:00.003-05:00

(Recommended Audio - MP3 From OOPSLA.org)

In this presentation Fred Brooks talks about Design, Collaboration, Telecollaboration and Conceptual Integrity. Some of what he covers here expounds upon the concepts in his widely respected book "The Mythical Man Month".

Index:

00:00 - Introduction by the conference leader
05:52 - Fred Brooks talks about his history in the industry
08:55 - Collaboration and Conceptual Integrity: Individual vs Team design
45:48 - Telecollaboration
52:59 - Question and Answer (a lot of great stuff here)

Its better to be wrong than to be vague

2008-01-31T23:03:00.001-05:00

There's a saying, "Its better to be wrong than to be vague". This is apparently credited to physicist Freeman Dyson, though I heard it in a talk by Fred Brooks. I believe this saying holds true in any scientific discipline and especially in software engineering. If you're wrong and specific then others can question your assertions and assumptions; together the group will find the correct answer. It's best for the team and best for the project, but it requires a degree of trust and maturity only found within well-lead, competent, accountable teams.

Guidelines for Communications in Accountable Teams

If you don't know just say you don't know... then go find the answer.
If you think you know then clearly identify your degree of certainty.
If there are other likely causes or possibilities then acknowledge them.
In areas where you are knowledgeable be bold enough to take quick, logical, defensible positions; be wise enough to remain silent in areas where you are not.

Audio: Jim Purbrick and Mark Lentczner on Challenges in Second Life Programming

2008-01-29T12:46:00.002-05:00

(Recommended Audio - MP3 From OOPSLA.org)

Second Life is a massive persistent 3-D world that has millions of users. Jim Purbrick and Mark Lentczner talk about the programming challenges they face in developing in and for this environment. Regardless of what you think of Second-Life itself, this is a truly intriguing and informative talk.

Talk Index

0:00:00 - Intro / About Second Life
0:18:24 - Problems with internal scripting in second life
0:34:22 - A new approach to internal scripting (really cool stuff here)
0:54:54 - Collaboration, Communication and Teamwork
1:14:33 - Questions

While listening to this my mind turned to the Wayne's World scene where Wayne and Garth are comically bowing to Alice Cooper, chanting "We're not worthy!!! We're not worthy!!!" (Even if you don't get the reference I trust you get the idea). They're programming on a 3D persistent world with 30,000 to 60,000 concurrent users, 15,000 CPUs, and 30 million concurrently running scripts; this is mind-blowingly cool stuff.

I am but a humble business programmer. It's fun and I enjoy it but even at it's very best the cool factor of my work would only reach a 2. It was nice to glimpse through the looking glass and briefly see the world beyond; Follow the white rabbit and all that... perhaps some day I will.

Agile Manifesto

2008-01-25T14:55:00.001-05:00

I recently became a signatory of the Agile Manifesto and I wanted to share it with you:

The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.

You'll notice that it does not advocate any tools or practices, but simply the driving concepts behind agile processes. Regardless of what you think about Lean/Agile practices, I hope we can all agree that these are solid principles to move towards. If you'd like to become a signatory you can sign up here.

It's always a people problem

2008-01-24T22:07:00.001-05:00

There's a saying (credited to Jerry Weinberg) that I've heard drifting around for a while now in various talks, blog posts, and books. Here are some common forms:

No matter what they tell you the problem is, it's always a people problem.
No matter how it looks at first, it's always a people problem.
No matter what the problem is, it's always a people problem.

I believe it was Kent Beck who related the 5 whys (from the Toyota Production System) to this. Basically the premise is that if you ask why roughly 5 times and try to move in the direction of a people problem then you should be able to root out a human cause to the problem. I'd like to take it a step further and say: "Don't stop with 'why'. Don't stop at 5. Keep asking questions till you can fix the problem."

An Example: The deployment failed

Why?

Users are unable to log in.

Why?

The application is pointing at the wrong database.

Why?

The config file had the wrong connection string.

Why?

The developer changed it for testing and didn't change it back.

Why?

We don't have a clean process for changing configurations from dev to test to prod.

Why?

No one has taken the time to create a process.

OK, that's a people problem, but let's go on.

Why hasn't anyone created an effective process?

We don't have the time.

Why?

There's to much to do, too many projects, too many fires(like this one), it's just not a priority.

Why?, no wait scratch that... who sets the priorities?

Management

Is anyone talking to management about this?

Yes, no, maybe? Whatever the answer it's still another people problem. Let's continue.

Has anything like this happened before?

Configuration file problems between dev, test, and prod? Yeah sure. Why?

Well wouldn't you have more time if you fixed this process instead of having to debug failed releases all the time?

Yeah, but...

We could keep going but you get the point. I think one of the most important skills that anyone can develop is the art of asking effective questions. In addition to helping you root out the causes and fixes for problems, it will also help prevent mistakes that are rooted in preconceptions, misunderstandings, and assumptions.

Audio: Robert Kalin on User Interfaces

2008-01-21T14:06:00.002-05:00

(Recommended Audio - MP3 from IdeaConference.org)

This is an entertaining and thought provoking talk by Robert Kalin from the 2006 IDEA (Information: Design, Experience, Access) Conference. Robert discusses the history of Achitectural/Object design concepts and how he is apply them to the User Interfaces Design on the website etsy.com.

Whiteboard appreciation day

2008-01-14T21:30:00.001-05:00

There's a Dot Net Rocks Interview with Richard Campbell where he says:

"Computers are amplifiers; they can either amplify our intelligence or they can amplify our stupidity. Until we can clearly delineate what we're trying to achieve on a whiteboard, computers are not going to help us."

I whole-heartedly agree.

I'd like to suggest we start a whiteboard appreciation day. You know, everyone bring a little gift, an eraser, some new dry-erase markers... Treat it to a good cleaning, whatever.

Ok, I'm kidding, but only slightly. I love whiteboards almost as much as I love computers. They let me work out ideas in free and unhindered ways. I often do impromptu sessions, just me and a whiteboard, for small projects, application problems, or designs in need of refactoring.

The next best thing is a free computer-based tool called Freemind (on Sorceforge). It's a mind mapping tool, which is basically a structure-enforced whiteboarding application. It's very useful and I highly recommend you give it a try.

There's always a Trade-off

2008-01-03T12:33:00.001-05:00

In Kent Alstad large scale site talk that I recently mentioned he discussed the trade-offs needed to scale large websites (i.e. more complexity, greater cost per feature, etc). It got me to thinking that in Programming / Design / Architecture there's always a trade-off. Even if the trade-off is very small, even if you don't know what it is, there is always a trade-off.

For some reason this also touched off a connection to an old post that Jeff Atwood made about the Worse is Better concept(where Worse is a measurement against an intellectual ideal, and Better refers to the success of a product). He chews on the idea that Complex and Right often looses out to Simple and Wrong. Off the cuff I'd say that worse probably is better, except for all those times when it's not.

New Years Resolution: Can you sleep when the wind blows?

2008-01-02T22:32:00.002-05:00

Kent Beck's Call for Accountability in Software Development was for me a call for self-evaluation. Consider the following story he shared:

Once, a farmer interviewed a young man for a job as a farm hand. One thing the young man said particularly puzzled the farmer, “I can sleep when the wind blows.” The farmer didn’t know what this meant, but the young man seemed competent and knowledgeable and so he was hired.

A few months later the farmer was awakened in the middle of the night by a thunderous wind storm. Panicked, he raced to the cot where he found the farm hand fast asleep. Shaking him roughly awake, he demanded, “We have to bring in the animals!” “They are already in.” “We need to fasten the windows.” “They are already fastened.” “We need to tarp the hay.” “It’s done.”

After going down his list of worries and being reassured that they were already taken care of, the farmer finally realized the meaning of the young man’s puzzling statement. By taking care to finish every job and leave the farm safe every night, the farm hand could sleep when the wind blew.

The farmer went back to bed and told his wife what he had just learned. She just smiled knowingly and the two of them went back to sleep, lulled by the music of the storm.

Are you reliable? Are you accountable? Professionally, do you do what you say and say what you mean? Can you sleep when the wind blows?

Audio: Kent Alstad on Large Scale Sites and Application Data Cashing

2008-01-02T14:12:00.003-05:00

(Recommended Audio - MP3 from DotNetRocks.com)

The talk was given by Kent Alstad at DevConnections, with comments by Richard Campbell and Carl Franklin. The talk begins 10 minutes 40 seconds in. It has alot of excellent information on performance in large scale internet applications and the trade offs of application space data cashing. If you work on internet applications I highly recommend this.

Audio: Kent Beck on The Future of Developer Testing

2007-12-24T14:14:00.004-05:00

(Recommended Audio - MP3 from itc.conversationsnetwork.org)

This is an excellent pep talk by Kent Beck on Developer Testing(unit testing), how it affects the health of software over time, and how it leads to Healthy Software.

I like the distinction he makes between Quality Software and Healthy Software. Quality Software is software that currently works as designed and lacks bugs. In contrast Healthy Software is software responds well to changes over time. It is possible to have Quality Software without developer testing but healthy software relies on developer testing. I've had to maintain a lot of Unhealthy software that's falling apart at the seams. Some of it was likely considered quality software in the first deployment, but lack of documentation and lack of unit testing doomed it to failure over time.This is an great introduction if you are interested in getting into unit testing or want to get others you work with on board.

Audio: Here comes another bubble

2007-12-21T19:39:00.007-05:00

(Recommended Audio - MP3 from RichterScales.com)

This is a little off topic but I ran across the song "Here comes another bubble" on a TWIT podcast a few days ago and I think it's hilarious. It's an I.T. parody by the Richter Scales of the song "We didn't start the fire". I finally found a copy of the music video on ValleyWag (it apparently disappeared from YouTube on a Take-Down order). The video makes the song even funnier; I can't imagine anyone in I.T. not getting a chuckle out of this. If you haven't see it yet then you should. Enjoy.

Well-Factored Code

2007-12-19T20:13:00.001-05:00

What precisely is well-factored code? The phrase grabbed my attention in a recent post by Jeff Atwood. It's a familiar concept; At a gut level this shouts at me: clean code! The self explanatory definition would be: code that has had an acceptable number of refactorings or, perhaps, code that has had all obvious refactorings performed on it. I googled the term to see how it is being used. From this search and, in particular, discussions in one wiki entry I have inferred my own definition.

Well-factored-code: code that is inherently readable, scalable, and maintainable but may be performance insensitive in certain contexts, platforms, and environments.

To optimize the performance of well factored code certain defactorings, such as in-lining small methods, combining classes or rearranging data structures, may be required. In general though, the consensus is that well-factored code is easier is optimize because bottlenecks are easier to identify and the code is easier to change.

Don't think kitchen, think cooking

2007-12-17T16:44:00.004-05:00

I was listening to a talk by Robert Kalin from the 2006 IDEA (Information: Design, Experience, Access) conference in Seattle and I came across a saying that comes from architectural design "Don't think kitchen, think cooking". This is the type of thing that I love to latch onto. To restate this: avoid preconceptions by keeping your conceptual domain as large as is possible but no larger. The 'no-larger' part is very important and is driven home rather well by a long winded joke that my boss pointed me to "A toaster is not a breakfast food cooker".

I love to cook though I seldom get the chance. Mainly this is because wife says I make too much of a mess when I cook. I consider this point irrelevant; since I always clean up my 'mess' what difference does it make how big it is? In any case when I think kitchen my mind scans every kitchen I have ever cooked in and takes in the good points and throws out the bad and I have a pretty good idea of what a kitchen should look like. These are preconceptions. When I think cooking my mind jumps into creative analysis mode and I begin to consider the different points of cooking, what is convenient and inconvenient, and what needs to exist to allow me to cook easily.

I once saw a picture in a magazine of an extendable faucet over a stove. This is a great idea. When you needed to add water to a pot you simply extended the faucet rather than carrying the pot to the sink or getting a pitcher to carry water to the pot. This little detail is a major convenience that could only have developed by thinking cooking not kitchen.

There's a shortage of good material on good design but I just found an excellent book on web usability and design called "Don't Make Me Think" by Steve Krug. I also found the transcript of an interview he gave on usability if you'd like to see what he's about.

Another excellent book(not web/programming specific) on usability and general good design practices is "The Design of Everyday Things" by Donald A. Norman. The concepts he discusses carry over to programming.

Audio: Discussion Panel on Domain Specific Languages

2007-12-17T11:42:00.004-05:00

(Recommended Audio - MP3 from Thoughtworks.com)

This is an Expert Discussion Panel on Domain Specific Languages (DSLs). The concept of DSLs has hung around a long time and some think that it may be close to going mainstream. If you've heard the term and need clarification or just want an overview of a maturing technology you may want to take a listen.

DSLs are not mainstream and I have yet to form a cohesive opinion on them yet, but the concept interests me and I continue to look into it periodically.

If you'd like additional resources here are some written commentaries on the topic:

Code Renaissance

Named Function Expressions in JQuery & Knockout JS

The Lie of Reusablity

Quotes for Software Developers #3: Efficientcy

My Take On It

Maintainability: Consistency Trumps Correctness

Consistency provides Quality

Consistent code is Maintainable

Fail 1: Poor Communication and Lack of Documented Standards

Fail 2: A Search for Interesting Problems

Fail 3: Excessive Speed of Development

The Solution

Quick Tip: JS Event Binding and the Call Stack

Quotes for Software Developers #2: Architecture vs Design

My take on it:

Bug Hunt

Finding Prime Factors in Javascript

If Software Teams Made Cars

The Devolution of Code

The Quality of the Team

Speed of Development

Size of the System

How to Fix this Mess

Increasing Eventual Efficency

Eventual Efficiency

Steps to observing and increasing eventual efficiency:

#1 Managers Should Code

#2 Managers Need to Review Code

#3 Managers Need Someone To Lean On

Conclusion

Site Redesign Complete: Come and See

Quotes for Software Developers #1: Change

My take on it:

Extending LINQ to Objects

Complicator's gloves

Program like Hansel and Gretel: Leave a Trail

The Javascript void operator explained

Brown field software: The five rules of code maintenance

#1 - Always leave the code cleaner than you found it.

#2 - Never clean up code that will not be tested.

#3 - If you mix your refactoring with your maintenance its not refactoring.

#4 - Incremental improvements are more stable than large sweeping ones, don’t try to fix everything all at once.

#5 - If you have taken the time to understand difficult piece of code then take a little more time to make it more clear.

Green field software: five rules for writing maintainable code

1) Don't write something in one line of code if two lines is more easily understood.

2) Name things well; rename them early and often.

3) Avoid premature optimization.

4) Follow the style of the existing code where possible.

5) Keep the code as simple as possible but no simpler.

Clean up JSLint with LintBrushJS

Cleaning up Bad Javascript with JSLint

New Team Members and the Five Stages of Grief

Using SQLCE with the Entity Framework and Linq to Entity: Part 1

Why Twitter and Facebook are popular and Blogging is not

WPF and Expression blend - a marriage of necessity

Boycott Ajaxian: Punish Hotlinking and Bandwidth Theft

Disagreements are WONDERFUL

No Longer Under (much) Construction

Problems with blog

Developer vs Manager Responsibilities

Your Responsibility as a Developer

Their Responsibility as a Manager

Choosing your battles

Social Capital

Going the distance

Good design vs Bad design

Problem serializing WSDL generated properties where minOccurs equals zero

Two years of blogging: Work, family, life balance

ASP.Net Code Blocks: Pound vs Equal (%# vs %=)

Bit.ly launches new url shortener J.mp to replace Bit.ly

Why Twitter needs more than 140 characters

Jacksonville Code Camp 2009

The Renaissance Developer's Creed

Evolution of (my) Javascript

T-Shaped People vs Generalizing Specialist

Good Marketing vs Evil Marketing

Virtual ALT.NET Lunch & Learns: A chance to speak

Virtual ALT.NET is not a Cult

Can anybody do agile?

Being a Professional on the Internet