A Developer WeBLOG RSS 2.0

The last 2 weeks have been one of the most fun times working for Docscorp. The team were given the chance to redesign our comparison model to be a better one. At the current state, the model is one big giant blob of procedural functions which are contained in …. 2 CLASSES. Yep that’s right 2 classes. (Now you know how bad it is). Our job was basically to transform these 2 classes into a model that is much more object oriented.

I spent some times to skim through all the functions of the 2 classes. I realized that all the logics are already solid, its just that the code are not as “organized” as it should be. Or in other words, redesigning the current model means One BIG refactoring job needs to be applied to the 2 classes.

I decided to take a stab on it and started refactoring the classes. After a few days, I came up with a good clean model of how it should be done. While refactoring, I realized that all I’m doing is just applying a couple of programming principles to those 2 classes. These principles are:

Yep, those are the only principles that helped me transform/refactor 2 giant procedural classes to be a modular object oriented model.

I think those should be the basis of your decision of when to refactor your code. If you find that you’re repeating yourself or writing the same/similar logic, then it warrants to refactor your code. If you find that your logic/algorithm gets too complicated, it’s time to break it down to make it simpler (doesn’t mean that you have to change your logic). Lastly if you find your code is doing to much or having to much responsibility, it’s time to refactor it out (I know by definition SRP is a class thing, but I think the same logic can be applied to functions).

You can always take things further and apply more programming principles to your code. But these three principles is a must in order to achieve a reasonable clean code. If you apply these three rules in your day to day code, I’m sure overtime you’ll find that your code will be a lot cleaner and much more maintainable. Thus, don’t be afraid to apply these rules to refactor your code.

RWendi

Monday, August 17, 2009 7:54:58 PM UTC |  Comments [0]
Programming

Visual Studio 2008 comes with a unit testing tool, MSTest. The coolest thing about MSTools is that it integrates so well with Visual Studio. Every time you build your solution, Visual Studio will automatically run your test projects and display the results in a nice graphical user interface (similar to NUnit’s one). I’ve been using MSTest for my side projects, until I found out that MSTest is not supported Visual Studio Express, which I have installed in my MSI Wind. Because of this limitation, I had to resort back to the good old NUnit.

After using NUnit again, I really missed MSTest integration with Visual Studio. NUnit provides a very minimal integration with Visual Studio, which requires you to create an external tool that points out to the NUnit console. When you run the NUnit tool, it will spit out the results into your Visual Studio’s output window. The simplistic approach works, but the problem with this is that I have to run it manually each time I run my build. It would be ideal to just have this automatically run each time we build our solution. Luckily, this can be automated by using Visual Studio macro and post build event. Here is how you do it.

Creating NUnit As A Visual Studio External Tool

First we need to create NUnit as a visual studio external tool. To do this, in Visual Studio, go to Tools > External Tools. You will be prompted with a form, in which you can manage all of the available external tools. Click on the Add button and fill in the form as follows.

ss1

You should fill in your form exactly as above, except for the Title field (if you wish to have different name) and the command field. The command field is the path to your NUnit console runner. Click the Ok button to create the external tool. Now that you have created it, if you go to Tools menu in Visual Studio, you will see NUnit in one of the available external tools. When you run the NUnit external tool, it will run NUnit through command line, and display it in your Visual Studio output window.

NOTE: the above will make NUnit runs all of the tests in the current active project. Thus make sure your active project is your test projects when running the tools. You can do this by having your test as your active file in Visual Studio when compiling. You can make it not to be bounded by your current active project by; hardcoding the arguments value to be your test dll and the inital directory value to be the location of your test dll. But keep in mind that the tool is not project/solution specific. That is, if you open up a different solution, it will still run the hardcoded value.

Automating NUnit Integration To Run After Compile

Now that you have the NUni integration set up, its time to make it run automatically after each compile. Here’s how you do it:

  • In Visual Studio go to Tools > Macros > Macros IDE.
  • This will bring up a the Macros IDE.
  • On the left hand side there should be a “Project Explorer” panel.
  • In the Project Explorer panel, double click on EnvironmentEvents module.
  • Insert the following code in the module.
Private Sub BuildEvents_OnBuildDone(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildDone
    DTE.ExecuteCommand("Tools.ExternalCommand1")
End Sub

As you can see that the above custom macro tries to run an external tool by its order. Thus depending on where you put your NUnit tool, you might want to change the parameter of right number based on the order of your NUnit tool. For example, if your NUnit is the third external tool, you can change the macro to this: DTE.ExecuteCommand(“Tools.ExternalCommand3”).

Debuging Your NUnit Tests.

Now that you have everything set up, how can one debug their NUnit tests? Surely you want to debug your tests once it fails. Here’s how you do it:

  • Right click on your test project and select "properties”.
  • On the right hand side, click on the Debug tab.
  • Change the start action from “Start Project” to “Start External Program”.
  • Insert the path to your NUnit GUI runner as your External Program.
  • In the Start Option section, insert your test dll, as your command line args, followed by “ /run”. For example: “tests.dll /run”.
  • Lastly set your working directory to the path of your test dll.
  • Your form should look something like this.

ss2

With this configuration set up, whenever you run your solution (don’t forget to set your test project as your Start Up project), this will run NUnit’s GUI runner to run your tests. Moreover, Visual Studio will automatically attach the debugger to the NUnit’s GUI runner process. This means that you can start debugging by putting breakpoints in your test code.

Wait a minute, isn’t this another way of automatically running NUnit after compile? Yes it is. So why mentioning the “External tool” method? Well the problem with running NUnit as external program is that, you have to always run your solution (F5) and set your test project as your start-up project. Doing it as an external tool, you can just build your solution and it runs your test automatically. Moreover, I find that NUnit runs much faster in the “External tool” method.

Hope you find this useful. Now write some TESTS!

RWendi

Friday, July 31, 2009 9:28:54 PM UTC |  Comments [2]
NUnit | TDD | Unit Test

Saw someone tweet this link. It gives a good and simple explanation of the much misunderstood relationship between HTML and XHTML.

Misunderstanding Markup: [Link]

RWendi

Thursday, July 30, 2009 1:16:21 AM UTC |  Comments [0]
Internet Stuff | Link | Programming

Today marks the beginning of week 7. My current weight is about 60.5 kilos, which means that I have lost around 4.5 kilos since I have started my weight lost Journey. My upper and lower abs has started to look more defined, though my mid section is still covered with fat. I’m guessing that I’m probably about 17-18% of body fat right now. I think my diet and training strategy has worked pretty well.

Sadly I must say that I have injured my calve muscles. Last Saturday I was helping my sister moving in to her new house. I had to carry heaps of heavy stuffs from third floor to the ground floor, in which between each floor there are probably about 15 stairs. And then on Sunday I felt sharp pain on my calve muscles. I tried having a low intensity cardio, but it made the pain worse.

I decided to give my legs some rests and will stop doing cardio. But I’m not going to give up on my weight lost journey. I will still be on diet and do upper body training for the last of the two weeks. Hopefully without cardio, my weight loss journey will still be effective.

RWendi

Monday, July 20, 2009 10:27:33 AM UTC |  Comments [5]
Fitness | Personal

Yesterday marked the end of week 2 of my weight loss journey. I have lost about 1-1.5 Kilos so far, which means that I lost about 0.5-0.75 Kilos a week. I think that is not too bad. There are still rooms for improvement and things to adjust, to make my weight lost journey to be more achievable. But I’m not going all out just yet, I’m taking it progressively and doing some adjustments to my diet and training every 2 weeks. Anyways, In today post, I am going to layout my workout routine.

I work out five days a week, which consists of 3 days of weight training and 2 days of cardio sessions. All my weight training is done with moderate intensity. Being in caloric deficit state (due to my diet), I may already have a chance of losing some muscles. Doing a high intensity weight training will definitely makes it worse. That is the reason why I weight train on moderate intensity as I don’t want to over train myself and lose too much muscles. Moderate intensity should be enough to maintain or built a little bit of muscle, and stimulate my metabolism.

I do cardio every weekdays, but only for 2 days will I be focusing solely on cardio. On weight training days my cardio will be done after I pound the weights, with low intensity for about 10-15 minutes. On cardio day, I will be doing high intensity cardio sessions for 20-30 minutes, followed by low intensity abs training. Weekends will be my rest days, but I may throw in 20-30 minutes low intensity cardio session depending on my mood.

This routine has been doing me pretty good. It gives me good recovery time,  which is crucial to keep me going on my weight loss journey. Anyways here is my typical workout routine looks like:

  • Monday: Back, Biceps
    4x10 Deadlifts
    3x10 Wide Grip Lateral Pull Down
    3x10 Close Grip Lateral Pull Down
    3x10 Bent Over Barbell Row
    3x10 Barbell Curl
    10-15 minutes Low Intensity Cardio (Power Walk)

  • Tuesday: Cardio
    20-30 Minutes of High Intensity Cardio
    2x15 Sit ups
    2x10 Leg Raise

  • Wednesday: Chest, Triceps, Deltoids
    4x10 Flat Bench Press
    3x10 Incline Bench Press
    4x10 Machine Flyes
    3x10 Triceps Push Down/SkullCrusher
    3x10 Front Dumbell Raise/Shoulder Press
    10-15 minutes Low Intensity Cardio (Power Walk)

  • Thursday: Cardio
    20-30 Minutes of High Intensity Cardio
    2x12 Cable Side Bend (both sides).

  • Friday: Legs
    4x10 Squats
    2x15 Standing Calf Raise
    3x10 Standing Leg Curls
    3x10 Leg Extensions
    10-15 minutes Low Intensity Cardio (Power Walk)

  • Saturday: Rest

  • Sunday: Rest

RWendi

Sunday, June 21, 2009 6:03:27 PM UTC |  Comments [3]
Fitness | Personal
All Content © 2012, RWendi