Tim Weaver

What to give the guy who has everything [OT]

My answer is here

Using Close Dispose and Finalize

Check out my latest article on Finalizers, IDisposable, Close and the Using Statement

Here

Stopping Comment Spam Iteration 2 Continued

I've posted the code changes that resulted from our comment spam module iteration two

http://codeverity.com/blogs/tim_weaver/archive/2005/06/16/23.aspx

Search Engines Finding My New Site

Read it here http://codeverity.com/blogs/tim_weaver/archive/2005/06/15/21.aspx

Or just read below for the summary

YahooSearch rules

....

Google and MSN get a big goose egg

Assembly Manifest Breaking Change in Whidbey

Read it here http://codeverity.com/blogs/tim_weaver/archive/2005/06/15/19.aspx

Creating an HttpModule to Stop Comment Spam -- Iteration Two

Continuing my comment spam HttpModule posts I've put up iteration two. Next will be the code that results from this iteration. [ First I have to go write it though]

http://codeverity.com/blogs/tim_weaver/archive/2005/06/14/17.aspx

Creating a HttpModule to Stop Comment Spam - Iteration One

Read it here

http://codeverity.com/admin/blogs/posteditor.aspx?App=tim_weaver&PostID=10

Creating an HttpModule to Stop Comment Spam

I've begun a new series of posts on creating an HttpModule directed towards stopping unwanted comment spam.

Initial Post: http://codeverity.com/blogs/tim_weaver/archive/2005/06/13/5.aspx

Design: http://codeverity.com/blogs/tim_weaver/archive/2005/06/13/6.aspx

Moving blog to new host

I've decided I can't wait any longer on the spam fix. DNJ has been great and I'll probably continue to direct posts from here to my new blog for the near future.

I've setup Community Server RC3 and have begun posting on the new site. It's likely to be a little iffy until I can iron out any issues that might come up.

Check it out here:

CodeVerity

RSS

Dev Partner Security Checker Team is looking for you

The Security Checker team is currently looking to add an additional member to the team. Think you got what it takes to create cutting edge tools for developers?

Interested in learning more? Contact Ryan.Kramer [AT] compuware.com with your resume or feel free to contact me via this blog if you want more info.

Complete Job posting: http://www.compuware.com/careers/search/posting.asp?index=33003&jobNum=T15619102

Job Description

Join the people that build software for business applications. Compuware's Product Development Centers allow you to be an integral part of developing award-winning software.

A critical member of the DevPartner development team, responsible for creating state-of-the-art, award-winning products, specifically in the ASP.NET space.

Primary Roles/Responsibilities:

* Translate requirements into software design.
* Design components and/or products to satisfy requirements.
* Work closely with the Architecture team to ensure product design is inline with overall architectural vision.
* Implement, unit test and integrate components into a stable, highly usable product.
* Conduct training sessions for QA, Support and Sales on all aspects of the product.
* Work with the Release Engineering team to define the product installation requirements.
* Work with the Human Factors / User Interaction team on all user visible aspects of the product.
* Document software engineering processes. Mentor teammates in understanding the total product architecture, suggesting improvements and providing strategies for problem resolution.
* Work with Support and QA on customer issues.
* Meet deadlines without sacrificing quality goals.
* Take an active role in and support process improvement initiatives and follow all company policies and procedures.

Required Skills/Competencies:

* Extensive experience with writing medium to large ASP.NET applications with C# and Visual Studio.NET 2003.
* In-depth understanding of HTTP, proxies, .NET code access security and various authentication mechanisms.
* Strong understanding of the .NET Framework, use of multiple AppDomains, multithreading, P/Invoke and COM.
* Bachelor's degree in Computer Science / Engineering, or higher.
* Strong technical background in .NET, ASP.NET, C#, WinForms and COM.
* In-depth knowledge of software development techniques.
* Strong analytical / troubleshooting skills.
* Team player. Ability to work effectively within a diverse team and with other functional teams.
* Excellent verbal, written and presentation communication skills.
* Strong organizational / time management skills.
* Ability to accurately estimate software size and effort required.

Desired Skills/Competencies:

* Experience with the DevPartner family of products.
* Experience with web security assessment and validation products
* Experience with C/C++, VB.NET, XML, XSLT, ChangePoint, VMWare and Perforce.
* Experience with beta versions of Visual Studio.
* Familiarity with Capability Maturity Model (CMM) and / or Capability Maturity Model Integration (CMMI).

NH .NET User Group Tonight - May 19th

This month at New Hampshire Dot Net

Thursday May 19^th BU Corp Education Center Tyngsboro, MA 6 PM

vCalendar

This month is the first of a three part series on Web Services, Web Services Enhancements (WSE) and Service Oriented Architecture (SOA).

In coming months, we’ll be hearing from Michael Stiefel on SOA and Julia Lerman on WSE 2.0 (if we can entice her to come down from Burlington VT)

This week Phil Denoncourt will be getting us started on WSE 2.0 and Pat Tormey will attempt to introduce you to SOA.

There will be an opportunity for attendees to share their lessons learned from getting hands on with Web Services.. So bring along your war stores.. show us the battle scars…

Why do companies buy SAP R3

I just got my weekly issue of (fill in your weekly computer rag) and under the news section is “Difficult ERP Rollout Slows Furniture Maker”. Is it just me or does this seem like the norm with SAP R/3 rollouts?

Let's see there was
The City of San Antonio
Rowe Furniture
Dell Computer
That whole UK fiasco with EDS ( I pretty sure that was SAP R/3 )

So my question is who is buying this crap and why do companies continue to try and roll it out when there is one high profile, expensive, failure after another?

Dell Computer tried to use SAP to replace its DOMs (Dell Order Management System). This was many years ago and the price tag that I recall was around 14 million dollars. For what? Not a single Dell employee was using SAP when I worked there. In fact Dell tried to replace DOMs so many times it became something of a joke [but that's another post]. It is always amusing to watch a company squirm because their entire backend system is running on a competitors hardware (Tandem).

Has anyone worked on a SAP R/3 rollout that wasn't a death march? I really want to know. Five or six years ago I was seriously considering jumping to the SAP platform because the developers were making gobs of money. These days you couldn't pay me to work on a SAP rollout. I'm both older and smarter. Who wants to work on something doomed to fail?

Team System - Team Test

I've been spending a lot of quality time with Team System creating, running, and cursing web tests and load tests. Don't get me wrong here, the product is a lot better than trying to write load tests in ACT, but it falls short in a number of places. It's still beta so hopefully these things will be addressed before RTM.

My Current List of Issues

No way to share test context between tests -- I want to be able to create a test called LogIn that only logs a user in. Then I want to create a test that is ModifyAccount that only modifies the user account. The ModifyAccount test depends on the user being logged in so I want to be able to point it to LogIn and have that context (cookies, etc) pass through. Otherwise I have to duplicate the LogIn code in each and every test that requires a user be authenticated. That sucks!

Memory Usage -- I'm running with 1Gig of RAM and the default selection of counters causes the test to fail due to lack of memory in minutes. In fact I had to close everything down and remove well over 50% of the counters in order to get a test to run for more than a few minutes. On top of that if I used SQLExpress to store the results it's memory usage would grow as long as the test was running (which would only be about 5 minutes) and again it would shut down. I had to change to Xml storage to get a test to run for any length of time.

DataSources -- The whole datasource concept needs some work. Once you setup a datasource there is no way to change it. For example I changed a table name. The datasource contains the table names and doesn't allow you to change them once it is created. In fact the entire database could be missing, but the datasource will happily act as if it is available. Another issue I ran into was the fact that I had two tables, one of which was empty [no rows] and the other had data. My webtest was bound to the table with data however the test refused to run because it said that it was bound to a table with no rows [which it wasn't using]. Since I can't modify the tables I had to insert a dummy record into the empty table in order to get the test to run.

Graph View -- The graph view of the performance counters is nice, but the decision to vary the scale dynamically seems like a poor one especially from a Human Factors point of view. Now, when looking at a running test, or test results, I can't compare the lines I have to mentally do the coversion to make sure everything has the same scale. Also I noticed if you add two counters that are similar but vary only by page name only the first counter will be added to the graph. Evidently the graph decides the counter is already there so it doesn't show it again.

Location of Results -- One of the issues I'm having is that I'm running out of space on my C drive. The XmlResults files are placed in C and I couldn't find a dialog that would allow me to move them somewhere else. This is a real problem because the test will shut down if you run out of space. I should be able to have these files live anywhere, not just under some folder in Documents and Settings

Test Settings -- Another more general complaint is that after you have created your load test and you decide you want to change some values (number of users, think time, whatever) it is no small feat to figure out where to go. There are many items in the load test tree and except for a few of the more obvious ones finding a specific entry/value is a hassle. The opening wizard is nice, so about a single click relaunch of the wizard to keep it that way?

Dependency Injection

A couple of replies to my recent posts on ASP.NET Context and using the Strategy pattern have really got me thinking about one of the design guidelines I've been following. Tim Haughton posted an example of the strategy pattern and Michael Polo posted that I should consider NMock to handle my ASP.NET Context testing.

Now in the past I have looked at NMock and for a lot of things it makes great sense, but it tends to be a lot of work and the benefit to work ratio isn't necessarily positive (in my past experience). So I have not gone down that route.

Both Tim Haughton and Michael Polo either directly or indirectly were saying use Dependency Injection to handle these issues (which is what NMock does). In the past I've always considered writing my code so that it can be tested to be less than ideal. In fact if I had to write an interface specifically for a unit test and for no other reason I wouldn't do it because it just didn't “feel” right.

I've mostly decided that I was wrong. The extra effort to design for depenedency injection scenarios, especially in code that is hard to test, [e.g. ASP.NET Context] is not only smart, in the end it would be more efficient. It is far more important to have code that is testable than to have some obscure purity of design.

So thanks Tim and Michael for helping me see beyond the blinders I had put on!

Strategy Pattern

How many times have you read something along the lines of "replace switch statement with strategy pattern"?

I've read it a lot and to be honest I never really "got it". I've read a number of patterns books and looked at numerous examples but they always left me wondering how that gets rid of the switch. After all, I thought, you still have to make a determination on what gets called...

It's all about the Pattern
I decided to end my ignorance. It turns out that the problem was with how I was interpreting the pattern. I kept thinking that you would still have to use a switch/if then else or something to figure out what to call, but that simply isn't true. Using the Strategy pattern you move that decision step back up the call stack [I'll probably get smacked around for that statement, but it fits my mental picture].

How about an Example
In order to have this make sense I created a non trivial example. In it we have a class RequestHandlerOriginal that has a single method ProcessUserRequest that takes in an enum value and a userID. Based upon the enum it will call out to the appropriate method. In the below example I left the calls to the Worker.* methods. There isn't really any good reason for this class to exist. In reality these methods could/should be folded into the strategy classes. This cuts down on the actual amount of code you have to maintain. Here's the original: [this is code I just tossed together. It compiles, but that is my only promise]

5 /// <summary>

6 /// The original implementation

7 /// </summary>

8 public class RequestHandlerOriginal

9 {

10 public enum ActionType

11 {

12 Login,

13 LogOut,

14 ChangePassword,

15 ResetPassword

16 }

17 #region Constructor

18 public RequestHandlerOriginal(){}

19 #endregion

20 #region ProcessUserRequest

21 /// <summary>

22 /// Takes in the ActionType and the userID and then based upon the requested action it will

23 /// call the appropriate method

24 /// </summary>

25 /// <param name=3D"action"></param>

26 /// <param name=3D"userID"></param>

27 public void ProcessUserRequest(ActionType action, int userID)

28 {

29 switch(action)

30 {

31 case ActionType.Login:

32 Workers.ProcessLoginRequest(userID);

33 break;

34 case ActionType.LogOut:

35 Workers.ProcessLogOutRequest(userID);

36 break;

37 case ActionType.ChangePassword:

38 Workers.ProcessChangePasswordRequest(userID);

39 break;

40 case ActionType.ResetPassword:

41 Workers.ProcessResetPasswordRequest(userID);

42 break;

43 default:

44 throw new ArgumentOutOfRangeException("ActionType", action, "Unable to handle the requested action");

45 }

46 }

47 #endregion

49 }

Now here is how it is called

96 public void CallOriginal()

97 {

98 RequestHandlerOriginal orig =3D new RequestHandlerOriginal();

99 orig.ProcessUserRequest(RequestHandlerOriginal.ActionType.ChangePassword, 11111);

100 }

Here are the new class(s) based upon the Strategy Pattern

50 #region Strategy Base Class

51 /// <summary>

52 /// This is the base class that all strategy participants inherit from

53 /// </summary>

54 public abstract class RequestHandlerNew

55 {

56 public abstract void ProcessUserRequest(int userID);

57 }

58 #endregion

59 #region Concrete Strategy classes

60 public class RequestHandlerLogin:RequestHandlerNew

61 {

62 public override void ProcessUserRequest(int userID)

63 {

64 Workers.ProcessLoginRequest(userID);

65 }

66 }

67 public class RequestHandlerLogOut:RequestHandlerNew

68 {

69 public override void ProcessUserRequest(int userID)

70 {

71 Workers.ProcessLogOutRequest(userID);

72 }

73 }

74 public class RequestHandlerChangePassword:RequestHandlerNew

75 {

76 public override void ProcessUserRequest(int userID)

77 {

78 Workers.ProcessChangePasswordRequest(userID);

79 }

80 }

81 public class RequestHandlerResetPassword:RequestHandlerNew

82 {

83 public override void ProcessUserRequest(int userID)

84 {

85 Workers.ProcessResetPasswordRequest(userID);

86 }

87 }

88 #endregion

Here is how to call the new class(s)

64 public void CallStrategy()

65 {

66 RequestHandlerNew newHandler =3D new RequestHandlerChangePassword();

67 newHandler.ProcessUserRequest(11111);

68 }

Here is the worker class (just so the code compiles as promised)

74 public class Workers

75 {

76 protected Workers(){}

77 #region worker methods

78 public static void ProcessLoginRequest(int userID){ /*do something*/ }

79 public static void ProcessLogOutRequest(int userID){ /*do something*/ }

80 public static void ProcessChangePasswordRequest(int userID){ /*do something*/ }

81 public static void ProcessResetPasswordRequest(int userID){ /*do something*/ }

82 #endregion

83 }

Conclusion
At the point of the CallOriginal() method call the developer had to make a decision about what action was being taken. The reason I say that is because the enum ActionType had to be set. Likewise with the Strategy pattern the decision about what is being called is made at the time of the call the difference is that it is explicit instead of implicit. The switch statement is no longer needed because we don't have the additional intermediate method.