This afternoon I conducted a talk on Facebook and Twitter applications using Silverlight, and a lot of people might have missed the links that I showed during the presentation. So here they are:
These links would serve as a good starting point for those who want to make their own Facebook and Twitter apps.
A bunch of Twitter friends and myself - Jerome Gotangco, Dean Berris, Aileen Apolo, and Migs Paraz, put together a little podcast we generically named "Pinoy Tech Podcast", which came out last weekend:
Pinoy Tech Podcast Episode 01 - Swapping Betamax Tapes
The podcast is in a mix of English and Filipino. We hope you listen to it and give us your thoughts.
A few weeks back while listening to .NET Rocks Episode 408, I cringed so badly when I started hearing Dr. James Whittaker, who is, apparently, in charge of Visual Studio Team System's testing tools (which I surmise includes the oft-admonished MS Unit Testing framework), talk about test driven development and his gripes about it.
Right then and there I saw it: Microsoft's attitude about test driven development has been totally wrong, precisely because they were asking the worst possible person about it. Whittaker is the worst person to talk about test driven development, because he's focused on testing.
Microsoft failed to understand, outright, that test driven development is NOT about testing.
Scott Bellware responded to Whittaker's statements via the Hanselminutes podcast, wherein he offered The Last Word On Test Driven Development on Episode 164. There, he questions (at around 5:30 into the podcast) "why test-driven development is coming out of a conversation about software quality and software quality tools":
I think it's quite sad though that no matter [how much we tell people] that TDD is about design rather than testing, that it never really sank in...
Questions about software quality are damaged when we let them fall over into conversations about test driven development...
The goal with [TDD] isn't really a unit testing goal although we're borrowing unit testing tools to achieve the goal... [We're almost like] "demonically" possessing unit testing to achieve other needs.
["The Last Word on TDD" on Hanselminutes]
I said as much when someone asked on Stack Overflow whether TDD takes focus away from design. In my response, I stated that it's precisely the opposite -- that, once again, TDD is all about software design:
If done right, Test Driven Development IS your design tool.
[...]
Test Driven Development, done right, should make developers highly aware of design pitfalls like tight coupling, violations of DRY (don't repeat yourself), violations of SRP (Single Responsibility Principle), etc.
If you write passing code for your tests for the sake of passing your tests, you have already failed: you should treat hard to write tests as signposts that make you ask: why is this done this way? Why can't I test this code without depending on some other code? Why can't I reuse this code? Why is this code breaking when used by itself? ["Does TDD take away focus from design?" on Stack Overflow]
The reason why I don't take this misconception lightly is because this realization came to me the hard way -- I was part of a project wherein Test Driven Development was grossly misunderstood by previous members of the project:
There was... a failure to recognize that TDD is not about tests, it's about design. The rampant case of singleton abuse in the unit tests made this obvious: instead of the test writers thinking "WTF are these singleton = value; statements doing in my tests?", the test writers just propagated the singleton into the tests. 330 times.
The unfortunate consequence is that the build server-enforced testing was made to pass, whatever it took["When TDD goes red" on Dotnet @ Kape ni LaTtEX]
The attitude the MS Test team took regarding this issue explains a lot why testing is an add-on "luxury" feature to Visual Studio, which you pay extra for, and not part of its core features out-of-the-box, and on top of that made it definitely illegal to implement in Visual Studio Express. Hiring a testing expert to implement a software design engineering guide lead to the inevitable misrepresentation of the value of TDD.
Unfortunately, treating TDD as a luxury feature gives the impression to hobby and professional software developers alike that test driven design is nothing but a bell and a whistle in Visual Studio -- which it is not. Test driven development is a paradigm in software development, and to many it has become a fundamental way of ensuring that code for software of any size and complexity is flexible and maintainable and remains that way.
So repeat after me: TDD is about design. It's NOT about unit tests. Tell that to the every developer who asks what TDD is all about, and to every developer who thinks TDD is about testing.
I've got a requirement wherein I needed to have a way to make dynamic predicates, with the need to support for And and Or operations between two predicates. I was aware that there are ways to create Dynamic LINQ queries if I wanted to use LINQ to Objects (I was using these on generic lists anyway), but a voice at the back of my head told me there would be a much simpler solution.
I was astounded at how simple it turned out:
public static class PredicateExtensions
{
public static Predicate And
(this Predicate original, Predicate newPredicate)
{
return t => original(t) && newPredicate(t);
}
public static Predicate Or
(this Predicate original, Predicate newPredicate)
{
return t => original(t) || newPredicate(t);
}
}
Of course the assumption here is that the logic operations are simple.
The following are the tests to show how it works. Needless to say, the lambda expressions can be replaced by any method following the Predicate delegate:
[TestFixture]
public class PredicateExtensionsTest
{
[Test]
public void PredicateExtension_And_method_performs_an_and_between_orig_and_new_predicates()
{
int t1 = 1;
Predicate orig = t => t == 1;
Predicate newPredicate = t => (t + 1) == 2;
Predicate falsing = t => (t - 1) == -1;
Predicate origAndNew = orig.And(newPredicate);
Predicate origAndFalsing = orig.And(falsing);
Assert.IsTrue(orig(t1));
Assert.IsTrue(origAndNew(t1));
Assert.IsFalse(origAndFalsing(t1));
}
[Test]
public void PredicateExtension_Or_method_performs_an_or_between_orig_and_new_predicates()
{
int t1 = 1;
Predicate orig = t => t == 1;
Predicate newPredicate = t => (t + 1) == 2;
Predicate falsing = t => (t - 1) == -1;
Predicate origOrNew = orig.Or(newPredicate);
Predicate origOrFalsing = orig.Or(falsing);
Assert.IsTrue(orig(t1));
Assert.IsTrue(origOrNew(t1));
Assert.IsTrue(origOrFalsing(t1));
}
}
This is my first post in this blog, and I'd just like to say:
Console.WriteLine("Hello World!");