KevinUp

real world programming

Archive for the ‘.net’ Category

Central Ohio Day of .NET

Posted by kevinup on February 17, 2009

While technically you can’t register till about a month prior, I fully anticipate that I’ll be there. April 18th 2009.

Central Ohio Day of .NET

Posted in .net, ASP.net, C#, javascript, performance, tdd, web development | Leave a Comment »

Changing Priority

Posted by kevinup on February 3, 2009

So a while ago my client gave me new requirement that went something like this:

It has to be fast, really, really, really, fast. And did I mention it has to be fast? Oh almost forgot, it has to go fast.

Well, I coded it up, was pleased and moved on. This week our QA server was having some problems. It would slow down, and then suddenly be responsive again. Apparently the testers had finally gotten around to testing my little piece of functionality. The head architect came to me saying that everything was running slow on the box. My code was basically spawning a bunch of threads, doing a bunch of work, and then closing out. This was causing the processor to peak at 99%, which is apparently a problem J.

Part of me was a little proud of my code. In hindsight I should have asked more questions about how fast it needs to run in.

Anyway, with the following code, it still was able to run pretty quick, without doing any major refactoring:

Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.BelowNormal;

Posted in .net, C#, performance | Leave a Comment »

Multi Threading

Posted by kevinup on December 10, 2008

A little something that I’ve found myself doing a lot is performance tuning. It’s something that I find myself being delegated with, and something I really enjoy.

When performance tuning one technique is to look for places where there is work being done sequentially that could be getting done in parallel. When found, I usually start writing the same class to use the .net framework to parallelize it. Its time to make that code available for anyone else that wants to use it, plus I’ll have this post so I can start to have a repository for my code.

The idea is you have a list of inputs, do work on it, and get back a list of outputs. In the middle you have some worker class that takes a single input, and returns a single output. For the sake of an example, let’s say I have a list of urls, and I need to hit a couple websites, and return their HTML. The syntax would look like this:

List<string> returnedHtml = ThreadManager.ExecuteParallel<HitWebpage, string, string>(inputUrls);

ThreadManager spools everything up, and does the parallelizing. The first generic in ExecuteParallel is the class that does the actual work. The second represents a list of that type of inputs, in this case, a List of string’s. The last generic represents a list of the output, in this case also a list of string’s.  When using this method of parallelizing, all you have to do is write a worker class. It needs to inherit from ThreadBase, and you just need to implement Execute. Here’s what my HitWebpage class looks like:

    public class HitWebpage : ThreadBase<string, string>

    {

        public override string Execute(string input)

        {

            WebRequest request = WebRequest.Create(input);

            WebResponse response = request.GetResponse();

            StreamReader reader = new StreamReader(response.GetResponseStream());

            return reader.ReadToEnd();

        }

    }

 

I’m hoping this looks pretty simple. I’m putting the rest of the code here on http://www.codekeep.net/ if you’re interested.

Posted in .net, C# | 2 Comments »

code coverage

Posted by kevinup on October 20, 2008

I was recently talking to another developer about code coverage and it made me re-think about code coverage.

I had asked him what his code coverage was on this project, and he replied it was probably pretty bad, but that coverage didn’t matter. The quality of the tests mattered. His argument was that if you had good tests that is all you need. 

At first I agreed, I love high quality tests. I like the idea of having 2 high quality tests over 10 medium to poor quality tests. Depending on the quality of your developers that isn’t always possible to have high quality tests.  I’d rather take over a project with 70% coverage with average quality tests than one with <20% coverage with high quality tests. A high coverage number gives you a lot more confidence about your source code, and any potential changes.

I recently was on a project where we were adding items to a shopping cart. There were around 150 tests built around adding items to the shopping cart, and it broke all the time. The team was around 10 developers, and the issue was that developers didn’t have the time to run all 150 tests, which could take up to 5 minutes. So they would check in and move on without running the tests. (Yeah I know, not a good practice)

I went through and identified 3 tests which captured most of the base functionality. I asked all the developers to at least run those tests before checking code in. Coverage-wise they were probably only hitting 60% of the shopping cart logic. But because they were higher quality tests, and could be run in <30 seconds, we were able to have the best of both worlds.

Posted in .net, C#, Uncategorized | Leave a Comment »

vb

Posted by kevinup on October 6, 2008

I recently finished a seven month assignment. It wasn’t anything glamorous. It actually was somewhat miserable at times. The worst thing about it was the client wanted their solution in VB.net. At first I was thinking, that’s ok, I’m a multi-lingual kind of guy. I prefer C#, but I’ve done some VB.net in my past, so it shouldn’t be that big of a deal. The assemblies are the same, it always compiles down the same or similar IL right? While that’s all true, I could never be so wrong about being multi-lingual.

Let me start of complaining about the IDE. In C#, when I was creating a class, I would drop in my private properties first. Then traverse back through and simply right click on the properties, and select ‘encapsulate method’. The IDE would code out my public properties. This would allow me to create my classes pretty quickly. In VB.net you get nothing. I thought initially it was a mistake. I checked on a couple other developer machines, and I got the same result. So instead of it taking 30 seconds to create a class, it took 5 minutes of boring copying and pasting.

Next: There is no extract method. Like any good developer I like my methods to be short, quick, and concise. A good method will usually start out around 5-10 lines. As the code matures, it might get to 15-20 lines, which I consider the max a function should be. Above 20 lines, its time to refactor your code. At this point I like to evaluate the method and try and isolate a couple lines that are specialized enough to be its own method. At that point you can highlight those lines, right click, select ‘extract method’, and BAM!. Done. In VB, not so much.

Next: Nullable types. I love nullable types; I don’t know how I used 1.1 without them. In C# a nullable type is declared as: ‘int? myInt’. In vb you can to say: ‘dim myInt as Nullable(of Integer)’. If you do that a couple times it will make you want to shoot yourself. The same applies to generics. A generic list in C# is just: ‘List<int> myList’ in VB its ‘dim myList as List(of Integer).

Those are my main gripes about VB.net. I found it so frustrating that I went to the client multiple times to try and convince them that C# was better, with no luck. The application had been in production for 4 weeks and generated 2.5 million in revenue by time I left. They were impressed enough that they offered to hire me away but I had to turn them down with my number one reason being VB.net. Ironically the week I was leaving they decided all new development would be in C#, and re-offered me the job again. C’est la vie. Too little to late in my book.

Posted in .net | 2 Comments »