Raymond Lewallen

February 2006 - Posts

• I’m you pusher. Unit tests are my drugs.

  I just finished a bunch of refactorings on some files in a project.  Nothing major, just your normal fixing of code smells and duplications that get left behind when you rush through some stuff.  So I finished all the refactorings I was going after and ran my unit tests. Doesn’t that feel good?  Don’t you just love your unit tests?  I want to take them to bed with me and feed them strawberries and champagne.  I had to make the pic small cause there is a bunch of stuff in there that you aren't supposed to see :) Yes, I did break 2 tests.  Both of which are easily fixable and will take less than a few minutes to rectify.  There were simply the tests that test the Object.Equals and Object.GetHashCode of one of my types.  Still, you people who have unit tests know how good it feels to see all the green lights light up and get that nice green bar in your unit test GUI. I actually touched quite a few files (dozens).  Framework files, mind you.  Things that if broken would cause awful bad problems back up the dependency chain, as these files I changed are highly responsible to the other pieces of the application (thats high afferent coupling for you metrics geeks out there like me). What a nice little security blanket.  Unit tests keep me all warm and fuzzy and feeling safe.  You’ve heard it plenty of times, you should have unit tests in place.  Every once in awhile I pull out the old GUI and run them that way instead of just getting a report or watching them run in the console.  The green lights are euphoric.  You should try it out. Like that Ice-T song, “I’m Your Pusher”.  Lyrics were his drugs.  Well, I’m you pusher.  Unit tests are my drugs.  They’ll make you happy. Posted Feb 23 2006, 03:21 PM by Raymond Lewallen with 3 comment(s) Filed under: .Net Development, Patterns and Practices, TDD

• Good design or bad design of abstract class?

  I came across this statement in the Framework Design Guidelines, page 84: “DO NOT define public or protected-internal constructors in abstract types.” Then it reads: “DO define a protected or an internal constructor on abstract types.” Sure. Makes perfect sense.  Then come the examples.  It says the following code is good design: Good design             public abstract class MySecondAbstract             {                         protected MySecondAbstract()                         {                         }             } So far so good.  Everything I’ve shown and read so far is something I think we’ve all known and agreed with for many, many years.  Its basic abstract class design. This next bit of code is labeled as good design/incorrect design: Good design/incorrect design             // good design             public abstract class MyFirstAbstract             {                         protected int _userId;                           // incorrect design                         protected MyFirstAbstract(int userId) // <--- this line is bad                         {                                     _userId = userId;                         }             } Why would this be bad design, as the book states?  Simple constructors are fine.  Protected constructors for abstract classes are fine.  So whats the deal? At first the thought was, maybe its creating a default public parameterless constructor that gets exposed.  But, the compiler is smarter than that and its not.  So far the only thing I can figure out is that design guidelines require that a parameterless, protected constuctor always exist for an abstract type. What are your thoughts on this?  Why would the above abstract class MyFirstAbstract be bad design? Posted Feb 22 2006, 09:22 AM by Raymond Lewallen with 16 comment(s) Filed under: Patterns and Practices, .Net Development

• Database Basics Part Four - Table Joins

  In an effort to provide information for those of you who are newcomers to databases, especially with the wonderul new Sql Server Express, I have committed myself to about half a dozen posts or so targeted directly at you to help you understand and build better databases.  Stay tuned to this blog for weekly updates to this series, or subscribe to the rss feed. Previous articles in this series: The ACID Model – the cornerstone of databases and database transactions. Normalization – the logical design and storage of data. Isolation – degrees of seperation among concurrent transactions. Today we discuss joins.  Joins allow an easy way for us to retrieve information from multiple tables, presenting the data as a single table, based on the logical relationships among the tables.  Typically joins utilize columns that have an existing foreign key defined on one of its columns and an associated column in another table.   INNER JOIN The inner join specifies that all matching rows, and only matching rows, are returned in the result set.  This is the default join type, although not the most common.  Let’s take a look at an inner join. Let’s say I have the following 2 tables:  Fig. 1 Here is our cars for sale table, called CARS Make Color 2001 Ford F-150 1 1998 Chevrolet Corvette 3 2003 Chrysler 300M 4 2005 Kia Sedona 5 Here is the lookup table for the colors ColorId Color 1 Red 2 Blue 3 White 4 Black For a quick explanation, if an actual constraint (relationship) between the color column of the cars table and the colorid column of the colors table existed, we wouldn’t have been able to put in the Kia Sedona with a color of 5, because 5 doesn’t exist in the lookup table.  For demonstration purposes, we are going to overlook the fact that we should have a relationship between the two tables. To demonstrate the inner join, let’s create a quick sql query that pulls back the rows from the cars table, along with the color description that matches from the colors table. Inner Join query select cars.make, colors.color from cars inner join colors on cars.color = colors.colorid And our resulting set looks like  Fig. 2 Results of Inner Join query Make Color 2001 Ford F-150 Red 1998 Chevrolet Corvette White 2003 Chrysler 300M Black You will notice two things.  First, the Kia Sedona did not come back in the result set.  This is because there was not a matching color in the colors table.  Second, the color blue was not returned in the result set.  This is because there is not a matching car with that color in the cars table.  This is the result set of an inner join.   FULL JOIN The full join returns all rows, matching or not, into a result set.  This means that even rows that do not meet the condition of the join are returned, and the output columns that come from the other table are set to null. A full join sql query for the same tables from Fig. 1. Full Join query select cars.make, colors.color from cars full join colors on cars.color = colors.colorid The matching result set is Fig. 3 Results of Full Join query Make Color 2001 Ford F-150 Red 1998 Chevrolet Corvette White 2003 Chrysler 300M Black 2005 Kia Sedona NULL NULL Blue All rows from both table were returned in the result set, including the ones that did not match our join statement.   LEFT JOIN In order to understand the left join, you have to understand what left means in the query.  In a join condition, the left table is the table listed to the left of the JOIN statement.  The right table is, you guessed it, the table listed on the right.  In both queries above, the left table is the cars table and the right table is the colors table.  The left join is the most common join used. A left join specifies that all rows from the left table that do not meet the join condition are returned in the result set, and the output columns from the joining table that do not match the join condition are NULL.  Non-matching rows from the right table are not returned. Left Join query select cars.make, colors.color from cars left join colors on cars.color = colors.colorid The results of our left join query are Fig. 4 Results of Left Join query Make Color 2001 Ford F-150 Red 1998 Chevrolet Corvette White 2003 Chrysler 300M Black 2005 Kia Sedona NULL From the colors table, the color Blue was not returned in the result set.  The Kia was returned, however, because we specified that all rows from the left table should be returned.   RIGHT JOIN The right join works just like the left join, except that the full result set is returned from the right table, and non-matching rows from the left table are not returned. Right Join query select cars.make, colors.color from cars right join colors on cars.color = colors.colorid  The results of our right join query are Fig. 5 Results of Right Join query Make Color 2001 Ford F-150 Red NULL Blue 1998 Chevrolet Corvette White 2003 Chrysler 300M Black This time, we got the Blue color from the colors table returned, but not the Kia Sedona. Posted Feb 10 2006, 10:27 AM by Raymond Lewallen with 13 comment(s) Filed under: Database Basics, Sql Development

• Face Recognition Website - Off-topic post

  This is an off-topic post, but it has to do with websites, so I'm justifying it that way.  We try to keep the main feed clean from oddball stuff like this, but any of you fathers out there understand why I posted this here once you get to the bottom. Per Scott H, I thought I would check this MyHeritage thing out.  I though, “Wow, this has got to be some pretty cool software!”.  I’m sure it just works by matching particular points on the face, length measurements from those points to other points and some other funky stuff. Here are a couple of my matches.  I think my wife would be happy. Yeah, I did end up with a few wierd people in my list, but at least a couple of nice looking fellows showed up, so of course I like it. Then, I took a photo of my daughter and put it in.  This face recognition thing is the shnizzle (is it still cool to say that?  was it ever?). And here are a couple of my daughter’s matches! Looks like I'll need to be polishing up and loading the guns before too long.  There's only one way to meet your daughters date.  That's with gun in hand. Posted Feb 09 2006, 08:36 AM by Raymond Lewallen with 8 comment(s) Filed under: Generalities