Tag Archive for 'geek stuffs'

unit testing is teh suck, or is it?

Published on May 6, 2008 in geek stuffs. 580 Comments Tags: , .

I was read­ing about unit test­ing and I came across Wil‘s blog arti­cle: Unit test­ing is teh suck, which was dated back in 2005. That title looked like it was asking for a flame war (as it hap­pened) and it sounded very inter­est­ing to me right after I recently dis­cov­ered the value in Test Driven Development.

The arti­cle was great, with many valid point. One par­tic­u­lar com­ment from Shalev prob­a­bly sums up my view:

I feel as if a great light has finally dawned upon me. The dark hypocrisy’s of people yelling “Don’t Repeat Yourself!”, and then turn­ing around and writ­ing their appli­ca­tion twice have finally given way to the light of a new way. The fact is that code that fully tests an appli­ca­tion will always be bigger than the appli­ca­tion code itself. This has always grated against the grain of my least-code-possible pro­gram­mer soul. I thank you for finally val­i­dat­ing what I others claimed a defect in my pro­gram­ming nature.

The least-code-possible pro­gram­mer soul, huh? That’s my phi­los­o­phy all along.

So what’s my take on unit test­ing now? To test or not to test? I would say, be flexible.

From another of Wil’s arti­cle (forgot which one), he said some­thing along the lines of “When people first learned objec­tive lan­guages, they go and create a God class, which inher­its like 40 sub­classes each with prob­a­bly a couple of lines of code difference” That’s right, that’s prob­a­bly also the case for unit test­ing: when people first heard of unit tests, they became advo­cates. (For the case of unit test, per­haps more people run away than to become advo­cates, but you get the point)

Does that mean objec­tive lan­guages and OO are teh suck? No! It’s the master programmer’s deci­sion as to when to use what tools and when to not use them. These kinds of expe­ri­ence, instead of things like which lan­guage 0wnz which lan­guage, are what sep­a­rate generic pro­gram­mers from the true masters.

Unit test­ing in gen­eral is a good idea, but it becomes an anti-​pattern when one gets restricted by it: waste too much time writ­ing tests other than writ­ing actual code, obsess­ing over than 10% of code cov­er­age which is just a number (as high-​scores from video games) Sim­i­larly, I think com­pletely ditch­ing unit tests is a waste of such valu­able tools.

In the end, there is no need for black-and-white think­ing here, just do what feels right at the moment based on your experience.

K2HttpRequest: asynchronous HTTP request using IWebBrowser2

Published on May 5, 2008 in geek stuffs. 644 Comments Tags: , , .

In my pre­vi­ous battle against Inter­net Explorer add-​on (BHO), I dis­cov­ered some valu­able (and scarce) resources to my aid. Pete‘s TinyBHO and CPete­HttpRe­quest prob­a­bly saved the most of my day.

Then I real­ized a prob­lem: for the browser add-​on that I was writ­ing, I would have to fetch a Web page from a server that requires user login. Under typ­i­cal usage sce­nar­ios, the users are assumed to have logged in the server in a pre­vi­ous ses­sion, so the Web server will autho­rize the user from cook­ies. How­ever, using WinHttp on which CPeteHttpRequest is based on, there seems to be no (simple) ways to obtain the user’s cook­ies and embed it in the HTTP request. I couldn’t find another piece that is as sim­plis­tic as CPeteHttpRequest and also able to deal with my prob­lem at hand.

So I wrote one myself.

K2HttpRequest has the usage of:

K2HttpRequest request;

// Synchronous wstring innerHTML = request.request ( L"http://www.google.com" );

// Asynchronous void foo ( wstring innerHTML ){} request.SetOnComplete ( foo ); request.request ( L"http://www.google.com", true ); K2HttpRequest uses IWebBrowser2 inter­nally, which means it opens a new Inter­net Explorer instance under the hood and loads the Web page with it. Thus, the server will receive login cook­ies as if the user vis­ited the Web page. It will fetch the Web page at the spec­i­fied URL and return the HTML in the <body> ele­ment (I actu­ally intended return the whole <html> ele­ment but I can’t find an easy way to do it, as IHTMLDocument2 doesn’t have get_innerHTML())

This is still a very pre­lim­i­nary ver­sion, and will prob­a­bly improve as my COM/ATL skills improve some day.

Down­load K2HttpRequest(source code ~5KB, Visual C++ 2008)

(Update: The asyn­chro­nous part of this doesn’t work very well. I didn’t know COM enough to use Mar­shalling when I wrote this ver­sion. I’ll prob­a­bly update this some day. If you want to get the asyn­chrounous part work­ing, you’ll prob­a­bly have to add in mar­shalling your­self :p)

why Test Driven Development (TDD) matters

Published on May 2, 2008 in geek stuffs. 641 Comments Tags: , , .

Like many pro­gram­mers who first heard of con­cepts of Test Driven Devel­op­ment (TDD), I was like “What the heck? Yet more code to write for some­thing that won’t pro­duce end user output?”. I’ve been puz­zling for quite some time to get myself accept­ing this con­cept, because Code Com­plete men­tioned it so I thought it must have been a good thing (very great book by the way, every seri­ous pro­gram­mer should read it).

Code Complete by Steve McConnell

I some­times write unit tests and I think unit tests are very useful in some tricky areas. It’s just that I haven’t been moti­vated enough to try TDD (test first then write code).

Then today I real­ized how TDD is a nat­ural pro­gres­sion for people writ­ing unit tests. TDD pro­motes clean OO designs. In short, I can even almost say that “If you can test it, it has good design”.

I came across this real­iza­tion while trying to write unit tests for this piece of JavaScript code after­wards: /** * Existing (bad design) JavaScript */

var Gateway = { ajaxGet: function(){}, };

// AccountManager uses Gateway, this is the “class” we want to test in this example var AccountManager = { get: function ( id, onComplete ) { Gateway.ajaxGet ( “/accounts/” + id , function ( profile ){ onComplete ( profile ); } ); } } That’s intu­itive enough, huh? As much as I thought it was, until I tried to write unit tests for it using JsMock, which has the typ­i­cal usage of: /** * Typical JsMock usage example */

var mockControl = null;

function Worker(){} Worker.prototype = { doWork: function(){} }

function setUp() { mockControl = new MockControl(); }

function testWorker() { var workerMock = mockControl.createMock ( Worker ); workerMock.expects().doWork(); workerMock.doWork(); workerMock.verify(); } With the code I have writ­ten, it is impos­si­ble to do test­ing with JsUnit: /** * Attempt to test my existing code with JsMock (in JsUnit) */

var mockControl;

function setUp() { mockControl = new MockControl(); }

function testAccountManagerGet() { var accountManagerMock = mockControl.createMock ( Gateway ); // ERROR! mockControl.createMock() only accepts a class name, // but Gateway is a variable name } So to make things com­pat­i­ble with JsUnit, I had to rewrote the whole stuff: /** * My revised JavaScript compatible with JsUnit */function Gateway (){}

Gateway.prototype = { ajaxGet: function(){} }

function AccountManager ( gateway ) { this.gateway = gateway; }

AccountManager.prototype = { get: function ( id ) { this.gateway.ajaxGet ( “/accounts/” + id ); } } /** * JsUnit tests for my revised code */var mockControl = null;

function setUp() { mockControl = new MockControl(); }

function testAccountManagerGet() { // OK now, because Gateway is a class var gatewayMock = mockControl.createMock ( Gateway );

var accountManager = new AccountManager ( gatewayMock );

// test fixtures var id = “kizzx2”;

gatewayMock.expects().ajaxGet ( “/accounts/” + id ); accountManager.get ( id );

mockControl.verify(); } The above changes might look redun­dant at first and not so intu­itive. But then I came to think of it, it removed the depen­dency between my Account­Man­ager class and the Gate­way class. I wasn’t quite aware of such anti-​pattern until JsUnit/JsMock brought it to my attention.

If I had used TDD in the first place, where I would have to write the tests first, it would have enforced me to use clean OO models to design things. Now I think that’s a pretty solid jus­ti­fi­ca­tion for using TDD.

making an Internet Explorer add-on

Published on May 1, 2008 in drumming and geek stuffs. 1,853 Comments Tags: , , , , .

I was recently doing a project to make an add-​on for Inter­net Explorer. How do I put it? I must say that was an extremely frus­trat­ing expe­ri­ence. The doc­u­men­ta­tion is severely lack­ing, if not non-​existent. One page from MSDN (which states the psarray is a BSTR is even dead wrong).

I have never been more moti­vated to con­tribute to the scene by writ­ing my own “Internet Explorer add-​on writ­ing sur­vival guide” sort of thing, but then I real­ized Pete has beat me to it by open­ing an entire [bho-wiki][wiki].

Nev­er­the­less, I’m writ­ing this arti­cle so more people can find these scarce infor­ma­tion on IE add-​on. On the other hand, here are some thoughts I had when writ­ing the IE add-​on. If you’re about to write an IE add-​on, these would prob­a­bly be the “survival guides” you’re using (as there aren’t many).

1. An IE add-​on is a Browser Helper Object (BHO)

To save you some time search­ing in vain, try using BHO in your Google searches. This would give you programming-​related infor­ma­tion instead of where to down­load the latest IE add-​on product.

2. Use C#

C++ just plain sucks, in terms of writ­ing an IE add-​on. Don’t get me wrong here, the lan­guage is mar­velous, but Microsoft’s sup­port just seems broken and unfin­ished. The whole Win32 hack­ing, COM stuffs involved when using C++ just makes your life 10 times more difficult.

The inter­face for C# is much more usable, and you won’t have to deal with all the bull­shits when pro­gram­ming in the out­dated (and most prob­a­bly unmain­tained) Win32 API.

Another major issue with C++ is Visual C++ 2008 Express. It doesn’t come with ATL, which means a ridicu­lous amount of grunt work deal­ing with point­ers, releas­ing and stuffs (as illus­trated below, as I hap­pened to use VC++ Express). VC# doesn’t have this prob­lem and it even has a number of libraries built-​in (such as reg­u­lar expressions).

Exam­ple 1: getEle­ment­ById from BHO

Using C++ IHTMLCollection * elements; HRESULT hr = document->get_all ( &elements ); assert ( SUCCEEDED ( hr ) );

long numElements; hr = elements->get_length ( &numElements ); assert ( SUCCEEDED ( hr ) );

IHTMLElement * element;

for ( int i = 0; i < numElements; i++ ) { VARIANT index; index.vt = VT_I4; index.intVal = i;

IDispatch * elementDispatch;

hr = elements->item ( index, index, &elementDispatch ); assert ( SUCCEEDED ( hr ) );

hr = elementDispatch->QueryInterface ( IID_IHTMLElement, (void **)&element ); assert ( SUCCEEDED ( hr ) );

elementDispatch->Release();

// After all this hard work, we have finally obtained our element! // GetAttribute is a custom function, I didn't even bother to // list out it's content here if ( GetAttribute ( element, L"id" ) == id ) break; else { element->Release(); element = NULL; } }

elements->Release(); return element;

Using C# document.getElementById(id); Exam­ple 2: exe­cute some Javascript

Using C++ BSTR code = SysAllocString ( L"alert ( 'Hello World' );" ); BSTR language = SysAllocString ( L"javascript" ); VARIANT result = {0};

window->execScript ( code, language, &result );

SysFreeString ( code ); SysFreeString ( language ); Using C# window.execScript ( "alert ( 'Hello World' )", "javascript" ); 3. Use jQuery for DOM manipulation

jQuery is a client side JavaScript library to sim­plify common tasks (the “write less, do more” library as they say). I found it delight­fully pleas­ant to use. It has some pow­er­ful func­tions like CSS selec­tors that would be a pain in the ass to imple­ment in BHO. With jQuery, you can do stuff like: // Find all the <a> elements with class "bookmark" and // target attribute "_blank" and hide // them smoothly using a slow slide up animation

$('a.bookmark[@target="_blank"]').slideUp("slow"); To use jQuery, simply use execScript to load the jQuery file on doc­u­ment complete.

4. About XmlHttpRequest

Fetch­ing exter­nal Web pages using client side JavaScript will give you a per­mis­sion denied error because of the cross-​domain poli­cies of most modern browsers. Xml­HttpRe­quest must be done in the BHO. Sven offers an exam­ple code to use IXml­HttpRe­quest, which is very valu­able con­sid­er­ing the lack of offi­cial doc­u­men­ta­tion. Pete has rolled his own CPete­HttpRe­quest class using WinHttp.

(Strangely enough, both of the above are coded in C++. I have yet to come across an equally effi­cient way to do Xml­HttpRe­quest in C#. Please feel free to leave a com­ment if you have good ideas)

one of the best programmers

Published on April 2, 2008 in anything. 4 Comments Tags: , .

I just read Teach Your­self Pro­gram­ming in Ten Years by Peter Norvig, the direc­tor of research at Google. The para­graph quoted below was pretty gross:

One of the best pro­gram­mers I ever hired had only a High School degree; he’s pro­duced a lot of great soft­ware, has his own news group, and made enough in stock options to buy his own nightclub.