Technology

Contains all posts related to any kind of technical stuff. There might be sub-categories if required. However, should use tag instead

Error logging with ELMAH

ELMAH stands for Error Logging Modules And Handlers for ASP.NET.

Wondering in Scott Hanselman blog i know about this one. Scott Hanselman ELMAH

The tool helps us monitoring the exceptions have been happening during the life of web application. Why do you need that? Stack trace and its suffs are useful information in order to fix bug. With this tool, you do not need to modify, or recompile your application. Just a few steps with web.config then you get it in hand.

You might also want to read about rule of exception handling  here

Do we need technical design?

Recently, the trend is for XP ( Extreme Programming) and Agile management with Sprint/Scrum, so do we still need technical design for a project?

The purpose of Agile developement is to supply the deliverable product sustainably and XP helps team accomplish the goal. Over the internet, we have found many principles, tips, best practises about coding, how to make a better code. However, noone talks about good technical design. In fact, none exists.

With the agile developement, the project is splitted up into small tasks. Each has acceptance test and customer relation. And most important, the customer is involved and the delivered product satisfy customer and we are ready for the change from them.

Now, let’s assume that we have all stories need to implement in one sprint. And the whole team will discuss how to do it. The question is how to make the technical design for those stories? and does it make sence to make the design for only those parts and the next sprint will continue next parts? I think NO.

Someone will say YES. Then i assume that you have made the technical design for those parts. Then come to the coding. Click here to see XP Practice . In summary it says:

  1. Write unit test and acceptance test, if you follow TDD.
  2. Write code to pass those test
  3. Refactoring code, of course make sure the tests are green.

And how can we refect the refactoring in Technical Design? So still say NO to technical design.

And consider time you spend on that

Someone will say: It keeps the thing we did in case when new comer want to get a preference. Do you really use the technical design to get understanding about the code or you will look directly into the code? if the code wrote 1 year ago and now you come in, what will you do in order to understand it? You only do this if the code has never been refacted.

My conclusion is that: If you are in XP and Agile development, you DO NOT need technical design. Instead of spending time on making the technical design, you should spend time on learning OOP principles, best practices. Then the code will explain itself.

Oobs, Are you throwing technical design away or is it useless? NO. We should consider it as a general documents of the project not the technical thing in detail.

Donot mix up layers in one function

Recently i did some refactoring on the old code. The code works fine as expected. Except that it was hard to test since there were too many dependencies on the implementation.

Here what it look like:

      public static void Accept(Task task)
      {
         task.ActualStartDate = CGDateTime.Now;
         task.Completed = false;

         if (task.ResponsibleResource.ResourceType == ResourceType.Group && task.GetSetting(RuleResource.Rules.Personalize_On_Acceptance))
            task.ResponsibleResource = AccessFactory.CurrentUser;

         task.Save();

         Comment acceptance = new Comment();
         acceptance.CreatedBy = acceptance.ModifiedBy = AccessFactory.CurrentUser;
         acceptance.CreatedDate = acceptance.ModifiedDate = CGDateTime.Now;
         acceptance.Type = CommentType.Acceptance;
         acceptance.Resource = task;

         acceptance.Save();

         UpdateAcceptedChildren(task, acceptance);

         TaskInformer.RegisterForCatTask(task, ApplicationVirtualPath, TaskInformer.Action.Accept);
      }

I am not going to explain more about that implementation and why and how i did the refactoring since it belongs to another topic.

In general, after creating some interface i had this one:

public static void Accept(Task task)
{
// #1 – The implementation
        task.ActualStartDate = CGDateTime.Now;
         task.Completed = false;

         if (task.ResponsibleResource.ResourceType == ResourceType.Group &&
             task.GetSetting(RuleResource.Rules.Personalize_On_Acceptance))
            task.ResponsibleResource = AccessFactory.CurrentUser;

         task.Save();
// #2 – The abstraction
         Comment comment= _commentcreator.CreateAcceptedComment(task);
         _childenupdator.UpdateAcceptedChildren(task, comment);
         _informer.RegisterForCatTask(task,ApplicationVirtualPath, TaskInformer.Action.Accept);

}

 _commentcreator is interface responsible for creating comment based on task

_chidrenupdator is interface responsible for updating its children information

_informer is interface responsible for informing others in the system.

It seems that we’ve alread done or at least at that time i can easily test the function without caring too much on the other parts. However, if you look at the code again, which i have marked with #1 and #2.
WE ARE MIXING THE IMPLEMENTATION AND ABSTRACTION IN ONE FUNCTION.

It should be in the same level.

How to solve the problem? Simply just abstract the implementation part. Here comes with the final code:

public static void Accept(Task task)

{

       _taskinfor.UpdateTaskInfoOnAcceptance(task);

         Comment comment= _commentcreator.CreateAcceptedComment(task);
         _childenupdator.UpdateAcceptedChildren(task, comment);
         _informer.RegisterForCatTask(task,ApplicationVirtualPath, TaskInformer.Action.Accept);

}

The benefit of doing this is obvious.