As last year was coming to an end I wrote an article on ASP Alliance. Well now to my surprise, my article explaining very simply what the MVC pattern is and why it is useful, has become relatively popular. I wrote the article, because I talked to a bunch of people and they didn't really seem to understand the MVC pattern, what it did for them, or why they should use it. Setting out my goal was to write an article to help people understand exactly that. I am sure there are plenty of ways in which it could have been improved, but I think it turned out pretty well.
How do I know the article is popular? It is currently listed as one of the popular articles on the ASP Alliance home page. As of writing this blog post, that article has had 3964 views in the past 10 days. Not too shabby I'd say since the article is not new. I have noticed that posts usually get more traffic right after they're written. I believe this is because search engines find them and list them higher for a while because they are newer.
So I took a quick screen shot of the list of popular articles, so my readers could see the fame I've reached....
Just to show my enthusiasm about this feat, I've taken the same screen shots and added some Batman-style onomatopoeias. This will let everyone know that my blog posts are knocking out other ones to get to the top... or save Gotham... or something like that. Enjoy!
Have a great day. I hope everyone enjoyed reminiscing about their childhood batman-watching days.
Tune in for the exciting conclusion on a different blog time on the same blog site. (yes, I mean here later)
As I've said in previous posts, it is important to write tests for your code. A lot of the time I am talking about when refactoring code or when writing new code. Now I agree that bug fixing could be considered refactoring, but people seem to treat it differently. When fixing bugs they want to go in and quickly make the bug go away. That is a dangerous way to solve things, because it doesn't prevent the bug from returning.
If a bug exists in your system then there are test cases missing from the system. When you fix a bug, even if you do write a test case to handle the bug how do you know you've tested the right thing? If your test is not right it will not prevent the bug from returning. I know of only one way to be fairly confident that a bug is tested well. The test needs to be written before the fix. If it isn't written first you will not know. If you follow the TDD practice of Red, Green, Refactor, the Red lets you know that you've found the bug. Then when you make it green you can have confidence that you've fixed the bug.
If you had not tested first you don't even know that your test is accurate. How do you know you actually found what is causing the bug? You can't really be sure with any confidence, because all you saw were green tests. Your test couldn't fail. Either the test didn't actually test the bug or because you fixed it. You hope the latter, but it could be the former.
This will not work. For other things I can agree with you that you can write code and then test it, but not for bugs. With bugs the test needs to be written first, so there is some confidence that the bug is being tested. Since code already exists the test needs to be in place first. This same practice should be adhered to when doing refactorings of working code as well. The point in that case is also to prevent software regressions caused by the refactoring. Tests help you hold existing functionality, and in the case of bug fixing they help to ensure that the bug has truly been fixed and tested to prevent a return.
Software bugs are like bad musicians. If you don't actively prevent them, they will make a comeback.
Example
As an example of this. We can assume that we have two classes. One of them is called Student and the other is called Course. To represent this example we are going to have some badly written code which is going to cause us to have a few nasty bugs (Badly written code makes for easier examples). From our knowledge of the domain, we know that students take a few courses at a time, so there is a collection of courses associated with a student.
Say our student has a property called Courses and that property holds the collection.
public class Student
{
public int ID { get; set; }
public List<Course> Courses { get; set; }
}
Now we say that somewhere we are caching the Student objects based on their IDs. We want to make sure that if the student object is changed that we expire the cache, so we will cache it with a SqlCacheDependency on the database table for the Student object.
Assume we have a "View my courses" page for the student to get information about the courses. For ease, it will obviously grab the student object out of cache and use its collection of courses to display the information if the information is already there.
What bug have we created here?
Well we've now made it so that if any of the courses change this change will not be reflected on the courses page of any student currently in the cache. There are literally probably a dozen ways of fixing this bug. Plenty of ways we could have prevented it, but then we wouldn't have this nice example now would we?
All I am saying is that some unit tests and integration tests be written for these before we fix the problem. This lets us be sure that we've fixed the problem correctly.
The first test I would write is one that loads a student object (making sure that is gets cached) and then separately loads one of the courses the student is in and alters that course. I would then make sure that the change to the course succeeded and then I would get the student again, (it would come out of cache this time) and I would verify that it had the change I made to the course. I would expect that the first time I run it that the test will fail. If it doesn't fail, or fails for a reason other than what I expected, I need to fix it so it fails the way I expect.
Once it is failing correctly I can adjust the code to make it work correctly. I would call this an issue violating the single responsibility principle, because the Student object in my opinion shouldn't be holding a local copy of the Courses. If it doesn't have that then it will not be able to cache it. I think that property should just be a getter calling through to some Course-related class which can cache it if it wants to. Even though these are obviously domain objects, we should try to keep them separated a little bit better, because keeping them too close can cause some annoying bugs.
As always, have a great day, and keep testing your code.
Yesterday, a co-worker of mine and I were working on a task which required that we work in the xml of a Visual Studio project file. We were setting up a target with an exec statement, and ran into a little annoyance. The file we were trying to execute was in a folder with a space in the name.
If we were typing this into a command prompt window it would be easy. We would simply wrap the statement in quotes. Working in the project file our brains sort of stopped working. We tried to find a way to escape the spaces in the file path. Instead of doing this in the end we used the xml encoding for a quote. We used " to wrap the path in quotes. Yipee everything worked!
Today we were doing some similar work, and ran into another problem in these files. We want our msbuild stuff to work with both 32-bit and 64-bit machines. The code we are calling is always 32-bit, so we need to use a different file path depending on which type of machine we are using. We found this post on stack overflow from a person who found a way to specify the 32bit directory for program files in msbuild. The post on there is asking for a better solution, so I will also ask people to provide a better solution.
This is how Wimmel solved the problem.
<PropertyGroup>
<ProgramFiles32
Condition="Exists('$(PROGRAMFILES) (x86)')">$(PROGRAMFILES) (x86)</ProgramFiles32>
<ProgramFiles32
Condition="$(ProgramFiles32) == ''">$(PROGRAMFILES)</ProgramFiles32>
</PropertyGroup>
<Exec WorkingDirectory="src\app1"
Command='"$(ProgramFiles32)\doxygen\bin\doxygen" Doxyfile' />
All he did is create a variable called ProgramFiles32 which would contain one of two file paths depending on whether the (x86) program files exists. He then uses that variable in his file path. It works reasonably well, and since I am not concerned with running this in any language other than English I am not too concerned with any problems which might arise from this. If this bites me down the road please point me back to this blog post.
A while back I ran into a problem when setting up SQL Server on a computer and using it along with a database project in Visual Studio. It isn’t really a big deal, but I needed to change which locally installed instance of SQL Server I was using by default with Visual Studio. Since I blogged about this previously it is a very nice reference for where to find that setting should the need to change it arise again.
Today I just sat down at a computer which had Visual Studio pointing to a SQL Express instance. Yesterday I installed SQL Server on the computer, so I went to change to the new SQL Server instance. What was my first step? I Googled for my blog post I’d previously written, because I knew it had nice screen shots to show me exactly what I was looking for.
I simply searched for, “change database Brendan Enrick”. The top hit on Google was my previous post explaining how to change the SQL Server Instance for a Visual Studio Database Project. As I mention in that post, I expected the setting to be DB Project specific not VS specific. Now I know better, and I just use the blog post for a quick solution.
Step one is to go to the Tools menu in Visual Studio and choose Options…
Now that the Options windows is open in the left side navigation tree select Database Tools and then Design-time Validation Database. Once that screen is visible there is a text box to change the SQL Server Instance Name. Set that to the name of your desired SQL Server Instance. In my case the default one, so I erased the existing value.
This is one of the big reasons why I am a strong believer in blogging. It is a quick easy way to get this information out for others to use. Posts like this often get a few comments of thanks from people they helped. If helping others in the development community is not enough of a reason, you also always have a record to help you if you run into the same problem again.
A couple of days ago I received an email informing me that I received the 2009 Microsoft® MVP Award.
Thanks Microsoft. I am very honored.
Thank you everyone who reads the articles and blog posts I write as well as the other things I am involved in.
I hope everyone has a happy new year. Everyone at my office should not worry, because I am not really going to uphold the random resolution I mentioned in my previous post.
The year 2009 is turning out well. I hope everyone has enjoyed their first couple of days of the new year.
