October 2006 Entries
My MP3 player decided to take a dirt nap this morning so I went out to buy a new one. The first thing that I noticed is that all of the new players are USB changed. While this may be good for the environment it isn't good for long rides to work. Actually it is a conspiracy to sell more junk. Now you need a mobile changer for your MP3 player. SUCKER!
I found one that looked like it had decent features and bought it. Now maybe I am just a geek, but I don't want to have to install software to deal with a product that is really just a flash device. Worse yet XP decided that it recognized the player and changed the way Windows Explorer shows the device.
Now if it had done that immediately it wouldn't have been so bad, but it first showed it as a drive and then changed the view. Now I can't see the files that I originally transferred to the player. I can play them, but I can't manage them. I am sure I will eventually dig up a way to either manage or delete them, but it is just aggravating.
Ultimately I don't consider something user friendly if it only works for one set of users. Buyer beware! Better yet, remember this lesson as you design and implement systems.
I knew I would find it. Buried deep in the menu of the device itself was a setting for access mode.
I am currently checking some code that I had written to be published. The process has put an exclamation point on the importance of code reviews for me. The parallels between reviewing the text, structure and examples in the book and the organization and coding structures of an application really struck home.
Sometimes you just need to walk away from what you are working on for a while. You may come back an wonder what the heck was I doing. I found places that I had been writing while coding and the final code didn't make it to the text. Other places the structure didn't make sense.
How many times have you written some code by laying out the over all structure and them forgotten to implement a stub (yes this is why code generation puts exception throws in stubs).
Code reviews are the best way to catch these and other gotchas early. Make them fun. I know associates who have had a beer fund (you know who you are) where you had to donate for every time you broke the build. Take that idea in a new direction. Say you have to donate for every code smell that someone finds in your code during a review. It could make for a great party at the end of the project.
I decided the other day that I would like to install the latest version of the Guidance Automation Toolkit. No big deal, right? Wrong!
The toolkit itself didn't complain during the process, but GAX has been giving me hell. It seems that I had a couple of hands on labs installed that it felt needed to be uninstalled first. The problem is that the installer only knows them by their short names which aren't very helpful when you have about 20 different HOL on your machine.
I had eventually gotten it down to one that it just calls HolPackage. I can't find anything in the Add/Remove Programs window that looks like a possible target.
Finally I went to every developers friend, Google. There I found a post from Tom Hollander (should have started there anyway) that had some comments describing just this situation. It seems that when I was playing with the TechEd HOL I had installed a guidance package I had created.
Finally, success. The moral of the story is to check for an authority in the area you are haphazardly romping in.
I will probably get myself in trouble with this post, but a recent ARCast just irritated me like walking through poison ivy in a pair of swimming trunks. C# or VB.NET. The battle rages on. I will say that I prefer C#, but I spend a lot of time writing VB for clients who have that as their standard.
In the podcast Ron's guest Bill McCarthy talks about how great VB.NET is. The funny thing is that what he points out as its strong points are exactly what I dislike about VB. Specifically things like the Handles and Implements keywords. Where he finds that it makes the code more readable I find that it causes me to type things that I already know about the class.
The other point he makes is the My namespace. While he contends that it makes coding more efficient I think in some cases it may put blinders on some developers. Mr. McCarthy says that very few people need to worry about performance these days, the important thing is getting the job done. I completely disagree on this. The majority of problems that I have run into over that past five years have been performance related. To solve these issues you need to know more than just the most commonly used classes and methods contained in the My namespace. You need to be aware that the framework has much more to offer.
One thing that really almost made me heave up my lunch was when he said that it is easier for VB developers to pick up C# then the other way around. I have been mentoring developers in .NET since it was still in beta. Of all the developers that I have worked with the VB developers have been the hardest to get to understand development concepts. Now this is not a reflection of the language as much as some of the people it attracts. The very thing that is touted as VB's strength is also its weakness. Ease of entry allows more people to use the language but with greater numbers also comes a larger amount of flotsam. While it isn't a reason to ditch VB and pick up C#, C-like languages have always had more to learn which I think means at the end only the most serious developers remain.
Ultimately a good developer can write good code in any language. Every language has its place. Heck, even COBOL does a specific job very well. My gripe is with people who think that their language actually is better than other languages because of syntax or one or two features that are not in another language. Let's concentrate on teaching proper design, development and testing practices and quit bickering over languages.
First let me say that my sense of humor is twisted. You may not agree with me on this one.
Carl Franklin and crew who bring you .NET Rocks, a mostly serious podcast about all things .NET, have added a new outlet for their warped sense of humor. Now they already had Mondays, which keeps me in laughing until I cry on my drive to and from work. I now know why that show has been more irregular than usual in being produced. Mark Miller now has his own show called Millahseconds. It is a skit style story telling format for no subject is off limits. It is also shorter than ten minutes so you won't lose much time checking it out.
Now there is a second show that has been added to the collection which, although I didn't care for it, some of you might like. Rory Blyth also has a set of short podcast called The Smartest Man In The World. They are in a story format, but it is almost more like poem reading. It does make you wonder if Mark Miller is right about Rory.
One of the most frustrating challenges we have to deal with when we create an application is a memory related problem. These may actually manifest themselves as out of memory exceptions or possibly slow downs as the system waits for resources. Diagnosing the cause of these problems requires cunning and perseverance.
So how do you go about finding the offending piece of code when your application contains several layers and thousands of lines of code. The answer is to dig into your bag of wizard’s spells and exercise the demons to send them back to the beyond.
Ok, that is a little dramatic. The real answer is to get a profiling or analysis tool. There are several out there. Some are free. Of course the ones with all the bells and whistles will set you back the price of a few first person shooter games.
While I was doing some diagnosis recently I ended up working with Dev Partner’s Memory Analysis, Red Gate’s ANTS, as well as the CLR Profiler and DebugDiag from Microsoft. This is by no means a complete list of what is available, just what I have tried. They each have their strong points and aggravations.
Memory Analysis has a really nice real time graph of the memory being allocated system. This helps as you are stepping through code to tell you at what point you app becomes a pig. The problem is that it isn’t good at telling you which object is bellying up to the buffet.
For the detailed level and ease of reading I actually found that CLR Profiler did a nice job. The allocation graph gives you a tree diagram that is easy to follow and allows you to drill down when you find a point of interest.
In the end I found that this is a process that still takes a lot of basic troubleshooting skills. Changing your code to exercise different scenarios and building test apps to isolate suspected thieves are crucial tasks. I hope this little bit of information can help some of you out there if you run into this type of situation.
I know others have already posted this one, but I wanted to put my two cents in. Scott Guthrie posted about the Patterns and Practices Guidance Explorer. The part that I thought was nice is that it comes in both desk top and web flavors. To some extent it seems to be little more than a dump of FXCop rules, but sometimes a search-able version of that is just what you need.
I think a good thing to do with this is to use its ability to add more items would be to include such jewels as those in “.NET Gotchas”. I would especially like to see more guidance around managing them memory footprint of applications.