Who Is Mucking With Google Maps?

A few months ago I noticed something.  I could no longer find my apartment address in Google Maps.  I was attempting to get directions from my apartment to another location and Google Maps just could not find it.  For 3 years I lived at that apartment and never has Google Maps not been able to find it.  I thought I was just going insane or something or that I was mistyping it.  Live Maps was still able to find the address.  It didn't matter if I put in the address on file with USPS or the way I was used to writing it out.  Nothing.

Now this morning I found something else out.  I was skimming the Google Blog and came across this post about Street View.  The areas listed blanketed my home town so I decided to see if they had street views available.  So I typed in my parents' address and something even stranger popped up.  First, the address it corrected to was for a different city.  Now, my parents' address does not actually exist in the USPS database.  In fact, the whole town, population of about 800, has PO Box addresses only in the USPS database.  Also the mail happens to come through this other town that Google Maps decided to change the address to.  However, this would never fly as an address to get mail delivered.  Never has Google Maps had a problem finding my parents' house.  And it never decided to change it to something else.

The second thing I noticed was that the roads in my home town were very off the mark.  The street that my folks live on shows a hook at the end of the street.  I've traveled that street by foot, bike and car tens of thousands of times.  Never once have I noticed a hook in the street.  We're talking a 45 degree change in direction.  Kind of hard to miss.  The street in reality is completely straight.  It also shows the south end of the street extending further than it actually does and connecting to another court.  This is not possible as it would cut through houses.  Our street is not the only one messed up.  My home town is nearly grid-like and Google Maps shows the streets angling in ways that it just does not.  Many of these streets have existed this way for 80+ years.  How can a mapping system be so completely wrong?

So I hopped over to Live Maps and sure enough, I found both my apartment address and my parents' address and my home town's street layout is correct.

I took a look at the caption on the bottom of the screen and noticed that the provider for Google Maps is Tele Atlas.  I don't recall for certain, but this may not be who has been the provider for Google Maps over the past couple years. If this is the case, Google, I implore you, drop Tele Atlas because their data is just blatantly wrong!

I don't feel as though I can trust Google Maps at this point so, for the time being at least, I will be switching to Live Maps until Google can win my trust again.  And I will be encouraging others I know to do the same.  I do not want them getting lost because of Google's directions or ending up in a bad neighborhood because of it.  Kind of dramatic, yes.  But when your mapping system suddenly loses your home address or starts making your home town look like a Picasso painting, are you really going to stick around?

"Software Tools You Should Be Using and Blogs You Should Be Reading"

I've read so many Dugg and Kicked articles about "Top 10 Tools" or "Top 10 Blogs", etc. that you should be using and probably aren't.  Every time I read one I think, what makes that person the authority on this topic and what research did they do to determine that yes, in fact these are the top 10 tools or blogs?  But ultimately it's just a title that is meant to draw your attention to tell you what tools that person or team is using or blogs they read.  And who knows, you may even find a tool or blog that you've never heard of but is just the one you've been looking for.

However, there's a problem with these articles.  There's a huge portion ("huge" added for dramatic effect, I have no research showing exactly how much) of the target audience that isn't even reading that article.  There are developers out there, probably working for a small company on a team of 5 or less that simply will never end up reading that article or hearing about those tools.  They may even be ignorant to the fact that such things exist.  These people are the ones who need to be reading these articles the most.  They are the ones positioned to gain the most benefit from it.

I'm not saying that anyone that works for a small company on a team of 5 or less fits in that category.  I work for just such a company yet I do not fit in that category.  In fact, I and a colleague brought a toolset to the company I currently work for and the other developers didn't realize that there were such tools out there or maybe just never bothered to really try to find them.  We've recently brought a new developer onboard and even in his experience working for several companies, including software development contracting companies, had never seen a toolset as large as the one we had constructed at this company.  We're talking the basics: source control, build processes, development aids such as Notepad++ and RegexBuddy.

So what makes us different from the developers that don't have an extensive toolset?  Much of the suggestions I'm about to make extend beyond the tools you use and into the improvement within your field in general.

Read the best blogs and technology sites

This one has been preached several times over.  I'm guilty not doing this one well though.  I read a couple, but I don't read the best ones and I tend to gloss over too many articles without actually paying attention to them.

This also requires changing your habits from time to time.  Blogs and technology sites go stale or become polluted with bad information.  Sometimes you have to give up on a site and move on to the next one.  Don't be afraid to abandon one of your favorite sites after it has gone bad or lost the lead.  Don't let their falling behind let you fall behind.

Strive for improvement

It's not just a matter of reading news on technology sites or reading popular blogs to try to stay on top of your field.  You have to be constantly on the lookout for better ways to do what you're doing.  You're not going to be spoon-fed every new tool, better process, better techniques or new technology.  Sometimes you have to go hunt for a better way by yourself.

Don't be satisfied with Notepad to record your notes or edit your text files.  There's Notepad++ and it's free!  Better yet, there's Microsoft OneNote for keeping track of your notes.  Don't want to pay for OneNote?  How about Zoho Notebook or Google Notebook?  Software constantly breaking because you and another developer deploy from your local working copy and end up ultimately overwriting each other's changes?  Set up a build server and build process.  It's what all the big boys do and maybe it's time you do too even if you're working for a Mom and Pop shop.  As long as it can improve your process, why not consider it?  NAnt does wonders for creating a build process and CruiseControl.NET is great for setting up the build server.  Both are free and XML based so they're fairly easy to work with.  Don't like those?  Search for more.  Search for better.

Also, when reading technology articles about the 'Top 10 Blabity Blah', don't be satisfied with what the author is telling you.  Look for better.  You may stumble upon a whole new slew of tools and blogs and ways of doing things that you've never heard of.

The same can be said for developing and testing software.  Don't be satisfied writing code the same way you used to.  Learn about design patterns, development methodologies, software testing techniques.

You have to be constantly hungry for knowledge.

Be curious

Don't shy away from the unknown.  Take a look at the ads on your favorite blogs or the technology site that you just discovered searching for a solution to your problem.  Hear something you've never heard of?  Google it.  Learn more about it.  It may not be as complicated as you think or it could help you in ways you've never dreamed.

A colleague once asked me if I had ever heard of 'Inversion of Control' (IoC).  I hadn't.  I read about it on Wikipedia and kind of got it.  But I was curious so I kept digging.  I found out about 'Dependency Injection' (DI) and 'Aspect Oriented Programming' (AOP).  All of which I was never taught about in college.  Never anything even remotely similar to these.  This also led me to the Spring.NET framework.  I started playing around with Spring.NET and within a month had employed IoC/DI and AOP and it greatly reduced the complexity of my code, decreased the development time and increased the unit testability and the system testability of the application.

On another day, I had been searching for the solution to a problem and saw an ad for XHTMLiT.  This company claimed to take any design file (of the popular file types such as PSD, PNG and AI) and generate valid XHTML and CCS.  They also said all the right things such as 'table-less' design (if you want), hand-coded and more.  All this in 8 business hours and for an extremely low price!  I was curious and decided on an upcoming web site revamp to try them out.  The price fit well within the budget and if they could get it taken care of in 8 hours, then they'd save me a bunch of time.  Sure enough, they delivered and got it done in far less time than it would have taken me.  If I hadn't taken the time to click that ad, I would have added probably a week or more to the schedule for that project.

Listen to others and more than that, talk to others

Don't wait for your friends or colleagues to tell you what they are doing or what they are using.  Ask them.  A vast portion of my knowledge and tools I use have been conveyed to me from one of my colleagues.  He does a lot of the footwork for gathering the information and I basically leech off of his knowledge.  Ok, I don't leech.  I do reciprocate.  I educated him on Spring.NET, AOP, IoC and DI.  So when I say 'talk' to others, I also mean that you should volunteer your knowledge.  They may be one of the people waiting to be spoon-fed.  So spoon-feed them once in a while and then educate them on how you learn about everything.

Don't be afraid to experiment

You have to experiment and play with new tools, technology and techniques before you can become familiar with them.  It's a rare breed that can simply read about something and put it into play the next day.  The first couple tries at using something may not be pretty.  But you learn more from your mistakes than you do from your successes.  Edison himself learned 2000 ways not to make a light bulb.

The toughest part about this one is that you either have to experiment on your company's time or your time.  The choice is yours, but either way, you have to do it.  Sometimes just monkeying with something helps you figure it out easier than reading about it or being taught about it and you can learn things about it that may not have been obvious or documented or taught.

Don't accept the world the way it is

Just because a set of processes, tools, etc. are already in place does not mean that they are the best.  Be the butterfly flapping its wings off the coast of India that causes a tornado in Kansas.  Speak up.  Suggest the new stuff.  Even if they don't change to what you suggest, it may be the catalyst for other change.  And sometimes you have to be more forceful.  Sometimes you have to implement a new tool without anyone knowing just so you can prove to them that it works.  Be smart when choosing to do this, but don't be afraid to do it if you think it will work.

Don't be afraid to throw the old stuff out

Things change all the time.  Tools, processes, methodologies, none of these live in a bubble.  They are subject to the same rules as everything else and thus they change as well.  When a tool just doesn't cut it anymore, get rid of it.  You may love it, have a long history with it and are an expert with it, but if it doesn't get the job done, then what good is it?  Throw it away and get a new one.

You must unlearn that which you have learned.

When you have a hammer, everything looks like a nail.  When you have a better hammer, everything still looks like a nail, but the nails are easier to pound.

I've got a million of these... Ok, I don't.

Keep your eyes open

One of things I have seen done as part of Lean is to observe your day-to-day tasks.  Even go as far as video tape your day.  Then analyze it.  Really scrutinize it for waste.  If you find waste, try to figure out if there's a tool that would be helpful in reducing or eliminating that waste.  Be mindful of what you are doing.  Things that are repetitive that we've done day in and day out are often glossed over and not seen as waste because we do them all the time and don't think twice of why we do it the way we do.  Find these tasks and ask why you do them that way and if there's a better way to do it or if there is something that will help you do it better or faster.

Not everything I suggested here is always feasible within a company because you are dealing with their money and time.  I can't go learn a new tool if my company doesn't allow me or I don't have the time.  Just be smart and you can sometimes find ways.  Explain to your manager how it could benefit the company and in the long run save them money.  But just because it may be difficult to follow these suggestions does not mean that they are any less valid of points.

Got any other suggestions?  Leave a comment.

Technorati Tags: Development Tools

One Scary Judge Of Talent

How does a programmer judge how talented he or she is?

I got to thinking today about one of my major projects.  It's a vital piece of our daily business and would cost the company a large amount of money if it came grinding to a halt for a day.

There are two new branches of this application that were recently rolled out and while I was rolling the first out I worked extensively with the team that would be benefiting from this branch to get this developed to meet their needs.  After I rolled it out, it was modified slightly to become the second branch that was rolled out.  I haven't heard much from the team that is using that second branch but I know it gets used heavily and they benefit dramatically from it.  In fact, as I thought about it, I hadn't heard from the first team in a while either.  I called someone up from the second team to find out how things were going and she said things were going great! and thanked me for checking in.

I'm not saying I'm talented (I'll leave that up to my peers to decide), but I did take a large amount of pride in my work today.  If I were to try to judge how talented I was, I would take the fact that this major piece of software that is used so heavily and has had no complaints against it or feature requests for it to assist in that judgement.

I admit this could also mean that people have come to live with it, deal with the problems and have been too lazy to request new features or think the feature requests will fall on deaf ears.  However, this software hasn't been out long enough for people to "learn to deal with it" and the second team sounded very pleased with it making me believe they truly have no feature requests at this time.

Development vs. Production Web.config

One of the big pains that I've run into creating a build process for a web site is the web.config.  When running in development, the web.config needs a certain set of development-only settings that get changed for production.  For example connection strings.  When developing, the web.config points to the development database but in production, it should point to the production database.

In the past I've kept two configuration files.  Web.config and Release.config.  At build time, the web.config was overwritten with a copy of the release.config.  Horrible you say?  Yeah, I know.  For those that it's not obvious to, the release.config and web.config will contain a lot of duplicate information.  Especially if you extend the web.config with your own custom configuration sections.  Let the synchronization issues ensue!

The ideal solution to handling the web.config is simply to change those values that you want changed.  But how to do this without writing some kind of script to find and replace these values?

Thankfully, the configuration file is just XML.  XML can be easily modified using XSLT.  And guess what!  NAnt (our build script language of choice) has a <style> step that allows you to perform an XML transformation with XSLT.  Ok, the only thing I needed now was time to get back up to speed on XSLT.  As you may have guessed it, I'm writing this post because I found that time.  Below is the code needed to make those changes.

XSLT:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl"
>
	<xsl:output method="xml" indent="yes"/>

	<!--Copy every node from the web.config applying templates when possible-->
	<xsl:template match="@* | node()">
		<xsl:copy>
			<xsl:apply-templates select="@* | node()"/>
		</xsl:copy>
	</xsl:template>

	<!--Remove custom debugging app settings-->
	<xsl:template match="/configuration/appSettings/add[@key='CreditCardTestMode']" />

	<!--Remove Conditional Compilation Symbols - Removes the 'compilerOptions' attribute-->
	<!--If you use the DEBUG conditional compilation symbol, you will have to transform your web.config before compiling your website.-->
	<xsl:template match="/configuration/system.codedom/compilers/compiler/@compilerOptions" />

	<!--Remove Debug Trust--> 
	<xsl:template match="/configuration/system.web/compilation/@debug">
		<xsl:attribute name="debug">false</xsl:attribute>
	</xsl:template>

	<!--Switch to production database-->
	<xsl:template match="/configuration/connectionStrings/add[@name='myDB']/@connectionString">
		<xsl:attribute name="connectionString">Data Source=SERVER; Initial Catalog=MYDB; User ID=DBO; Password=REALLYSTRONGPASSWORD;Application Name=APPLICATION;</xsl:attribute>
	</xsl:template>

</xsl:stylesheet>

NAnt Step:

<!--Build website using the aspnet compiler-->
...

<!--Modify web.config for production-->
<style style="${buildfiles.path}webconfig.xslt" in="web.config" out="${website.output.path}web.config" />

One of the other big hurdles is the DEBUG conditional compilation symbol.  Most of our web projects depend on that symbol so things happen a little different while in development (such as exception handling).  Because of this, our web.config would have to be transformed before we compiled.  Thankfully, that code should be able to be removed from the web project and moved into the supporting project.  Yay!  Less code in the web project!  I'm all for less code in the web project.  That's the way it should be.

Technorati Tags: XML,ASP.NET,web.config,.NET,XSLT,NAnt

Why You SHOULD Have 100% Code Test Coverage

I recently wrote a post about the level of code coverage that I achieved on a project that I was working on.  Then I started seeing articles about how 100% code coverage is a fallacy, or how code coverage tools are "evil".  I disagree.

Ok, before everyone kills me, let me explain.  I do agree to the following:

• Code coverage numbers can be abused (just like a defect/bug count)
• Code coverage is NOT and indicator of how well tested your code is
• Code coverage number should never be used by themselves to draw any sort of conclusion about the code

Argument 1: It's Waste of Time

The first argument that I saw was that testing simple pieces of code such as simple getter/setter properties is a waste of time that can better used writing a unit test for a more complex piece of code.  So more bang for your buck.

You don't have to waste your time writing tests for simple getter/setter properties.  A good testing framework can take care of this for you with little or no work on your part.  NewtonSoft Utilities.NET contains a class that will dynamically test all of your properties.  Using this utility, you can write a single unit test that tests all of your properties on a class.  And this unit test can copied and pasted with one or two minor modifications to test the next class.  Elapsed time: 30 seconds to create class, write function and run test.

In addition, no unit test should ever be considered a waste of time.  A single unit test is meant to test a single scenario and that unit test will also ensure that chunk of code will always behave as expected in that scenario.  What starts as a simple getter/setter property may evolve to a more complex one and the unit tests written for that property will ensure that the evolution of that property does not sacrifice functionality without you know about it.

Argument 2: Trust Your Programming Language/Framework

Another argument against testing things such as simple getter/setter properties is that why would you not trust your programming language/framework/environment to perform a simple get or set operation?

Why would you trust your programming language/framework/environment?  Programming languages are software and thus can contain bugs too.  Now the likelihood that you will ever encounter such a bug is low, but why take the risk?  As long as you have a good testing framework as I stated above and unit testing your properties takes little or no time, then it is far better to catch the bug in unit tests than in production code.

More importantly, unit testing the simple pieces of code is not about not trusting your programming language but rather not trusting yourself.  I, and I'm sure most of you, have at one time or another fat-fingered something in code.  There are numerous ways to screw up on a simple property.  How about having the following?  It is very easy to do the following, especially with code-completion.  This is not really a bug you want making it into production code, especially if a single unit test would have exposed this.  And if the problem doesn't immediately stand out at you, then you've proved my point.  And now imagine this property inside of a class with other code and documentation.  Suddenly this bug because camouflaged and less easy to see with the naked eye.

public int Width
{
	get { return Width; }
	set { _width = value;}
}

Argument 3: Code Coverage Is Not An Indicator Of Code Quality

This argument is half true.  The true reason that code coverage can not be used as an indicator of how well the code is written is because code coverage only indicates that the individual lines were executed.  It does not indicate what combination of individual lines were executed.  In other words, it says nothing about code execution paths.

However, code coverage can help indicate how modularized the code is.  What?!  I said it helps indicate that.  If you have complex code, the quicker you are able to achieve 100% code coverage (or a high level of code coverage), the more modularized your code possibly is.  Very modular code means that the individual pieces of your code are smaller and less dependent on other pieces of code.  This in turn means that your unit tests will be smaller, more focused and require less setup.  Given all of that, the unit tests should be quicker to write.

In my previous post about code coverage, I stated that I employed IoC/DI and AOP and was able to achieve a high level of code coverage very quickly and every class was either 100% covered or 0% covered and the 0% covered classes were very small and contained "untestable" code.  The application had its complexities, yet I was able to achieve this code coverage scenario relatively quickly.  Analyzing the code showed that it was very modular.  TDD yields the same results.  Modular code with high code coverage.

Having modular code means that you should be able to write more unit tests quicker and more effective unit tests because they are more focused on smaller pieces of code.  This could lead to more quality code.  It is important to note that highly tested modular code does not guarantee quality.  But the chances of it are higher.

Conclusion

While it does not give you the world, aiming for 100% code coverage does help you write better software depending on the steps you take to achieve this high code coverage.  Code coverage in and of itself is not evil and the code coverage percentage does provide some useful insight when used in conjunction with other pieces of data about your code.

Just as with everything else, the quality of your code depends on the methodologies, techniques and technology that you use coupled with your development skill level.  Aiming for 100% code coverage is just another technique.

Aim high.  Never let your grasp outreach your goals.

Technorati Tags: Code Coverage,Inversion of Control,Dependency Injection,Aspect Oriented Programming,Test Driven Development