The diary of a .NET Developer, working on an unlaunched startup project. Also, I live and work in Southern Oregon.

Tuesday, January 27, 2009

ASP.NET Ajax vs jQuery.ajax

I love jQuery but ASP.NET Ajax has some great features for calling your own webservices.  Using jQuery to call services is much simpler, and has less going on behind the scenes, but is harder to debug.  ASP.NET Ajax is creating a leaky abstraction for you, and along with that you get intellisense, helpful erorrs, and full visual studio debugging capabilities.

Calling ASP.NET Webservice with jQuery:

$.ajax({
type: "POST",
url: "PortfolioService.asmx/AddBenchmarkToCart",
data: '{portfolioId: "'+portfolioId+'", benchmarkId:"' + benchmarkId+ '", position:"'+position+'"}',
contentType: "application/json; charset=utf-8",
dataType: "json"});


Pros:
  • Simple code: not a lot of behind the scenes magic
  • Efficient: doesn’t load any extra javascript files
Cons:
  • Hard to debug: it either works or it doesn’t, you get no useful error messages
  • Six lines of code to copy/paste each time

Calling ASP.NET Webservice with ASP.NET Ajax:

<asp:ScriptManager ID="ScriptManager1" runat="server" >
<Services>
<asp:ServiceReference Path="~/Portfolio/PortfolioService.asmx" InlineScript="false" />
</Services>
</asp:ScriptManager>
PortfolioService.AddBenchmarkToCart(portfolioId, benchmarkId, position);
Pros:
  • Intellisense
  • Useful Error Messages
  • Fully functional visual studio debugging
Cons:
  • Less efficient: includes a small proxy javascript file for your webservice (which the client must download).

For more information on this, see this nice tutorial over on the asp.net site.

Javascript Class Definitions

Two ways to define a class in javascript.  

At first glance, I didn’t realize what was going on in the second example, but the code is just using JSON syntax to define the prototype.

The benefit of reading other people’s code is you always learn something new.

(I picked this up browsing through the jQuery source code.)

I placed the actual source code here so you can can see it in action.

This is the way I always defined classes:

    function Person2(name, age) {
this.name = name;
this.age = age;
}

Person2.prototype.HaveBirthday = function() {
this.age++;
}

Person2.prototype.GreetWorld = function() {
return "Hello World, my name is " + this.name + " and I am " + this.age + "years old";
}

A shorthand way using JSON syntax:

    Person.prototype = {
HaveBirthday: function() {
this.age++;
},

GreetWorld: function() {
return "Hello World, my name is " + this.name + " and I am " + this.age + "years old";
}
};

This makes a lot more sense when you realize you can even do this:

var ben3 = { 
age: 29,
name: "Ben",
GreetWorld: function() {
return "Hello World, my name is " + this.name + " and I am " + this.age + " years old"; },
HaveBirthday: function() { this.age++; }
};
 

Thursday, January 22, 2009

TDD and Private Methods: What an eye opener!

I’m continuing to practice TDD while creating a simple word search solver. I’m giving TDD a shot is because normally I don’t write testable code and find it difficult to create unit tests after getting so far into a project. This leads to little or no unit tests.

In my short time trying TDD, I’ve realized a couple things about my coding style. Although my code always works (ie. it performs the task at hand), it is full of interdependencies. This creates an environment that is pretty much impossible to write unit tests for. Any tests that I do write only cover large parts of the system, but they are not testing small units of my code—so they do not provide much value.

By sticking to TDD I’ve been forced to change this style in a drastic way!

Normally, this how my public facing code would look. The algorithm for SolveForWord would basically be hiding inside some private methods and fields of the PuzzleSolver class.

PuzzleSolver solver = new PuzzleSolver(wordSearchText);
PuzzleSolution solution = solver.SolveForWord(“dog”);
I could only test the method “SoveForWord”, which tells me nothing about how it was implemented.

With TDD, I did things much different. After a bit of “new thinking”, I created a PuzzleParser class that implements parsing and data manipulation, and left the PuzzleSolver class to perform only the solving algorithm. PuzzleSolver gets an instance to PuzzleParser in the constructor. Then I extracted an interface for PuzzleParser:

    public interface IPuzzleParser
{
string GetLetterFromCoordinate(int row, int col);
string GetLettersFromCoordinate(int row, int col, ParseDirection direction);
int MaxCol { get; set; }
int MaxRow { get; set; }
}

This is of course the DependencyInjection pattern, and I finally get why this is so valuable! In this case, I can mock the parser in a test:



            MockRepository mock = new MockRepository();

IPuzzleParser parser = mock.StrictMock<IPuzzleParser>();

PuzzleSolver solver = new PuzzleSolver(parser);


So it's certainly baby steps in the right direction, but mabye I'm starting to see the light!

Monday, January 19, 2009

My own personal version of a "Startup Company"

I'm currently working for a startup company.  I don't get paid and it's not going to make millions, so it's hard to be excited about the product.  But, I'm the sole creator and it's actually pretty cool, so it's a love/hate relationship.

Plus, their is always a chance that it will make a profit.

Obviously, their is more to a startup then a good idea.  Currently, I'm slaving away down-in-the-trenches, and this type of work is what is going to help this thing survive the first year.  

Since learning from mistakes is the best way to learn, I eagerly jumped at the opportunity be involved with this project.  I'll either succeed or gain another lesson from a failed project.

I'll post more about the product as soon as it's ready (more like as soon as I'm ready.)

Sunday, January 18, 2009

Testing private methods

I am writing a crossword word search puzzle solver for the purpose of practicing Test Driven Development.  Yep, I am only writing code after first writing a test. 

I started off with a very powerful method named SolveForWord:

   public class PuzzleSolver
{
public PuzzleSolution SolveForWord(string word)
}


Almost instantly, I had the urge to start writing private methods to help parse the puzzle into a private data-structure.   But since I’m doing TDD, I had to think about how to continue.  Since I can’t test private methods, how do I write that code? 



To be honest what I did next was find out how other people do in this situation.  After a bit of googling, I decided to try testing my private methods using reflection.  Then it hit me.  My attempt to test private methods was “test friction” right?  The PuzzleSolver class shouldn’t be doing any parsing!  By experiencing this “test friction” I changed my design. 



   public class PuzzleParser
{
public PuzzleParser(string text)
{
}
}


PuzzleSolver will use PuzzleParser to perform parsing and not actually perform parsing itself. Single Responsibility in action!



Note: I didn’t know how much code to include in my post, so I purposely left out most of it.

Create Syntax Highlighted code in Blogger using Live Writer

I found a Windows Live Writer plugin to do syntax highlighting of text.

You can install plugins by simply copying the dll to your plugin directory.

Here is a test:

    public class PuzzleSolver
{
private string[] rows;

public PuzzleSolver(string[] rows)
{
this.rows = rows;
}

public PuzzleSolution SolveForWord(string word)
{


}
}



Saturday, January 17, 2009

Test Driven Development is design

In Hanselminutes podcast #146, Scott Bellware talked about Test Driven Development being design, which I already sort of knew, but what I got out of the show is how TDD can really make a difference in my coding practices.

By practicing TDD, it's going to bring to light all sorts of "test friction". For example, the harder it is to setup tests, the harder TDD becomes. The difficulty I have in setting up tests my objects is a big reason I don't even attempt to practice TDD. Once I realized this, the idea that "test smell begets design smell begets code smell?" sort of made sense. I've got this horrible test smell staring me in the face and now I really want to do something about it.
How can I reduce test setup friction? Is single responsibility (part of SOLID) the answer? Will Structure Map help?

Scott Bellware finished the podcast with a suggestion to read the book TDD in Microsoft .NET by James Newkirk. I actually already own the book and immediately pulled it off the shelf and am re-reading it. ( I read it 2 years ago before I even knew what unit testing was.)

I'm researching this topic heavily and will post more when I find some answers.

Monday, January 5, 2009

Vista Sidebar Gadgets are HTML pages!




Yep, you heard me right, the vista sidebar gadgets are tiny html pages with images and JScript (aka javascript).  

Even the clock app is a simple background image with two clock hands as images.

They do have a gadget API which can rotate images. This is how they achieve the nice animation on the clock, for example.








You can browse the source code for every gadget that comes with Vista by going here:

C:\Program Files\Windows Sidebar\Gadgets\

 


I was amazed when I found this out!  For some reason I assumed they were fancy WPF apps.

If you're interested you can read more on msdn.

Vista Sleep Issues Solved




I finally found outhow to troubleshoot Vista sleep issues.  Specifically, how to tell what woke the computer.

By using "powercfg lastwake" on the command prompt, I could at least tell that it was a USB device.

A little peeking into Device Manager  and I noticed both my mouse and keyboard were allowed to wake the PC.  (Normally this is probably a good thing.)  I simply disabled that feature and my problem is fixed.