While I'm on this rage rant, these are the other things that really piss me off.

1. Oprah
   I really don't like how Oprah's audience takes everything she says at face value without question. What's more, I really hate how she stands by her premise of engaging readers who didn't go to school or don't know where to begin in a bookstore but didn't bother to read the OJ book If I Did It, but made a whole show out of it with guest interviews. I think it's bullshit. More info here
2. Money spent on stupid signs on the freeways of our nation
   Click it or ticket, drive 55 arrive alive, litter and it will hurt, Report carpool violators: 555-HERO, etc. I would rather see our tax payer money go to education of drivers who have long since forgotten their DMV rules of the road pamphlet knowledge required to pass their written drivers exam. Recently I was in Canada and noticed what a lovely system they have for stop lights--if you can go the light is green, and if you must yield it is flashing yellow. The beauty of this is when you need to make a protected left turn and there is NO ONCOMING TRAFFIC, you can go and keep traffic moving rather than wait two minutes for the signal light to cycle and change.
3. People using their feet to open bathroom doors, flush the toilet, or lift up seats
   Several problems with this--the first just being hygiene. When I go to flush the toilet I use my hand to pull the lever, but now I have to worry about the jerk that used his disgusting urine soaked shoe to pull it instead. These extends to the stall doors and in some instances the main entrance to the bathroom entirely. To counter this madness people are using paper towels to as a cushion to open the door and discarding in a strategically located wastebasket or, if none exists, on the floor.
4. Cyclists that ride in the motorized traffic lane instead of their bike lane
   Living in Seattle you will find that there are more cyclists in the area than in other areas--which is fine; I am all about keeping slim and trim. What I don't like is when spandex-clad cyclists ride three wide in your lane making it impossible to go more than 15 miles per hour. When I commuted from Capitol Hill to Redmond I would take Lake Washington Blvd and sure enough I would be stuck behind some cyclist for a few miles. Sure, the road is marked so I can pass them, but the corners are tight and you really can't see far enough ahead to make a safe pass.

Hope you had a great vacation. Visiting the family is fun, but it's not really a vacation. One of these years I would really like a pre-holiday vacation to unwind.

On the way home this year I got a cold, which for me always turns into a raging sinus infection. I'd like to think i'm like most people and can be grumpy when your sinuses won't drain and you have to fly. What's worse on my 3 and a half hour plane ride home there was a family of 5 (3 kids and two adults) with the kids all under the age of 3.

I like kids, and usually they're pretty good on a flight. They're really only a problem if the parents are pushovers and don't discipline the children or they're bored and kick the seat back in front of them--fortunately for me I was in the row behind them.

Before the cabin doors were even closed this one little girl belonging to that family started screaming--she was upset because her mother wanted her to sit with her dad. After about 10 minutes the dad gave up and switched with the mom. Great news there is the family only bought 4 seats so the girl had to sit in her mom's lap--which is fine so long as she's not about two years old.

What's even worse is during the flight when the girl would cry the mom would just lift her shirt and offer her breast to the child. I, for one, don't particularly like public breast feeding, but I am strongly opposed to using your breast as a pacifier. After a dozen incidents with several passengers shocked and horrified (including the two nice men who sat on either side of the family and observed the breast-pacifier on many occasion) and three and half hours later we landed and could get the hell off the plane.

Quote

Political Blooper and Practical Joke Hall of Fame

Feb. 10: During a speech yesterday, the president identified a Los Angeles Office building as the "Liberty Tower."  Only problem is that it used to be called the "Library Tower" and now goes by the name of the "U.S. Bank Tower." Whoops!  It's not all [that] bad Mr. President. You're the newest inductee into Countdown's Political Blooper and Practical Joke Hall of Fame!

Microsoft is offering free online training (over 62 hours of material) for free until Nov 17, 2005! Visit http://lab.msdn.microsoft.com/vs2005/learning for Visual Studio .NET 2005 and http://www.microsoft.com/technet/sql/learning for SQL Server 2005

Additional training courses:

Performance is not always the top non-functional design goal; however, it is important to ascertain where security, scalability, maintainability, code reuse, development speed, traceability, and testability sit in relation to performance, which can be mapped to performance goals.

1. Response time under a certain load
2. Maximum number of requests per second
3. Total client load
4. Target hard understanding performance goals
5. Scalability—performance improvement as hardware is improved/increased

To achieve these performance goals it is imperative to get your develop lead and/or client on board and to commit to these goals. Committing to these goals assists with scheduling, takes away a client’s “blank check” for performance expectations and makes all parties stake-holders in performance issues. Of course in order to see the effectiveness of a goal, one must measure and revisit it regularly; leaving performance until the application is feature-complete is a recipe for many late nights.

While I am a .NET application developer, it is important to say that .NET is NOT a magic bullet for building good applications—leveraging lessons learned in other technologies and from past projects will lead to building great applications. That said, here are some other great groundwork guidelines:

1. Data locality can make or break an application. Think about locality from day one.
2. Think about patterns, but don’t go over the top. An architectural pattern that seamlessly supports caching is good.
3. Look at the architecture of sample applications to get a feel for best practices
4. Don’t be afraid to leverage server products where required. Building a Commerce Server or BizTalk replacement is hard—build on the hard work of others.
5. Validate the architecture early with testing! Going back and changing architecture after coding has begun can be expensive.
6. Appreciate the cost of using framework library functionality
7. Remember that referenced DLLs are delay-loaded, but still add up over time.
8. Keep the cost of third-party control and utilities in mind—balance the non-functional issues (performance, security, deployment) versus added functionality.
9. The ROI of testing is proportional to how early it is added to the project
10. Performance tests can be included in unit testing, particularly if hard performance goals exist
11. Ongoing performance testing allows problem areas to be picked up as soon as they are written
12. Testing on target hardware AND target operating systems is prudent. Windows 9x/ME and NT4 can have different performance than Windows 2000/XP/2003

Diagnosing performance issues in the CLR can be a difficult task. Luckily there are many tools available for assisting in these matters.

• Testing—keeps performance goals in mind and in check

o       NUnit – www.nunit.org

• Profilers—“Why is my program running slow?”

o       Compuware DevPartner Profiler Community Edition—http://www.compuware.com/products/devpartner/profiler

o       AQtime.NET – www.automatedqa.com/products/aqnet.asp

• Excessive memory usage—“why is my app chewing up so much memory?”

o       Virtual Address Dump (VaDump)—command line tool that ships with the platform SDK

o       .NET Memory Profiler – www.scitech.se/memprofiler/

• Managed Memory Inspection

o       CLR Profiler – www.microsoft.com/downloads/details.aspx?FamilyId=86CE6052-D7F4-4AEB-9B7A-94635BEEBDDA&displaylang=en

• Relative Performance (which is faster, A or B)

o       .NET Benchmark Harness – www.dotnetperformance.com

Diagnosis tools, however, can only get you so far. Efficient code must utilize the .NET Framework efficiently.

1. Never throw exceptions to control flow
2. Prefer non-throwing methods over throwing equivalent
3. Consider cost of setting up try-catch blocks (while minimal, it isn’t free). Avoid such code in performance demanding code or tight loops
4. Don’t throw a new exception in a catch block by accident; rethrow the original exception.
   
   Example:
   Right
   Catch (ex as Exception) { throw; }
   
   Wrong
   catch (ex as Exception) { throw ex; }
5. Don’t call GC.Collect() method to compensate for missed dispose calls. Instead fix the bad code.
6. Use a tool (like FxCop) to check for missed dispose calls
7. Be conscious of memory locality—referencing near data is much quicker than far data.
   1. Cache
   2. RAM
   3. Hard Disk
   4. Local Network
   5. WAN/Internet
8. Favor language array support over System.Array
9. Use the appropriate data collection to store data
   1. An array list or array may not always be the most efficient data store. Consider hash tables, etc.
10. Understand operation complexity (big “O” notation), and know the cost of common operations
11. When using the hash table type, make sure the object used as a key has a good hash code distribution
12. Remember that strings are immutable and each modification creates a new String object
    1. Use String.Format or StringBuilder when modification operations exceed 5 operations
13. Use the appropriate form of string comparison. String.Compare() offers flexibility with locale and case, but comes at a cost.
14. Use Regular Expressions for complex string manipulations
    1. RegEx objects can be compiled to assemblies for greater performance

In summary I’d like to say that the .NET Framework offers the ability to create high performance applications, but lag behind native applications in a few areas and performance planning in a project is critical to achieving the correct outcome. Additionally a number of tools exist for tuning application performance (so now you know), but choosing the correct tool is important for achieving the best results. Lastly, I’d like to emphasize that the efficient use of types in .NET is important for achieving good performance—learn the characteristics and cost of heavily used types.

My actual blog address:

http://www.themurillofamily.org/blogs/richardm