public class DrawDown : IComparable<T> : IComparable<T>
{
public static Comparison<DrawDown> DateComparison = delegate(DrawDown field1, DrawDown field2) { }
public static Comparison<DrawDown> ValueComparison = delegate(DrawDown field1, DrawDown field2) { }
public int CompareTo(DrawDown other) {}
}
And sort like this:
var list = new List<DrawDown>();
list.Sort();
//or
list.Sort(DrawDown.DateComparison);
var list = new List<DrawDown>();
list.OrderBy(d=>d.Date);
//or
list.OrderBy(d=>d.Value);
Basically, I use LINQ more then anything else in the .NET framework. It really does save hours of writing boring “sort” code.
NOTE: I am working on getting better syntax highlighting in my blog. Live Writer is not working out at all.
I spent way to much time staring at this code trying to figure this out:
int number = 10;
int firstDigit = Convert.ToInt32(number.ToString()[0]);
Assert.AreEqual(1,firstDigit) //fails: firstDigit == 49
I knew it was returning the Unicode value of 1, which is 49, but I was after the integer value. Converting a char to an int always returns the Unicode value, not the integer value. Converting a string returns the expected result.
int number = 10;
int firstDigit = Convert.ToInt32(number.ToString()[0].ToString()); //add an extra ToString()
Assert.AreEqual(1,firstDigit) //passes
Nothing too exciting, but I was stumped for about 15 minutes trying to figure this out. I almost started looking for a atoi() function.
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.
$.ajax({
type: "POST",
url: "PortfolioService.asmx/AddBenchmarkToCart",
data: '{portfolioId: "'+portfolioId+'", benchmarkId:"' + benchmarkId+ '", position:"'+position+'"}',
contentType: "application/json; charset=utf-8",
dataType: "json"});<asp:ScriptManager ID="ScriptManager1" runat="server" >
<Services>
<asp:ServiceReference Path="~/Portfolio/PortfolioService.asmx" InlineScript="false" />
</Services>
</asp:ScriptManager>
PortfolioService.AddBenchmarkToCart(portfolioId, benchmarkId, position);
For more information on this, see this nice tutorial over on the asp.net site.
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.
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";
}
Person.prototype = {
HaveBirthday: function() {
this.age++;
},
GreetWorld: function() {
return "Hello World, my name is " + this.name + " and I am " + this.age + "years old";
}
};
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++; }
};
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.
I could only test the method “SoveForWord”, which tells me nothing about how it was implemented.PuzzleSolver solver = new PuzzleSolver(wordSearchText);
PuzzleSolution solution = solver.SolveForWord(“dog”);
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);
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.
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)
{
}
}
Posts
All Comments
