Dennis Forbes is a Toronto-based software architect. While focused primarily on the .NET and SQL Server worlds, Dennis frequently ventures outside of this comfort zone into game development and image processing. He has been published in several industry magazines, has been quoted in the Wall Street Journal and has been interviewed by NPR.
Nearing the end of 2006 I put up a bit of a rant--
Two-Factor Authentication, Hashing, and Cell Phone Restrictions /
J2ME -- concerning two-factor authentication, and the
difficulties implementing a simple, no-cost solution on my handy
new Motorola cell phone. I pretty much gave up in frustration, the
many barriers and limitations just making it not worth the
trouble.
I recently started using a Motorola Q, based upon Windows Mobile 5.0 and running on the Bell Canada network, and I have to say that the situation is night and day -- developing and deploying either native or .NET Compact Framework apps on it is ridiculously easy (and incredibly well supported in Visual Studio 2005 with the SDK add-ins), easily using the data network to communicate with sites over the net, and so on.
Absolutely wonderful device for developers and enlightened shops.
A couple of years back I wrote a short piece titled "Edit and Continue - Valuable Tool, or Sloppy Vice?"
I pondered whether some development tools and practices -- such as test-driven development (TDD) and the reduced cost of errors (in both time and personal reputation) -- were actually making us worse developers, paradoxically decreasing productivity and the suitability and correctness of solutions.
That entry was motivated by the outpouring of demands by my peers that a particular tool continue to feature edit-and-continue functionality: what I thought would be an infrequently used frill turned out to be something that many depended upon daily, correcting their flawed code at runtime as a regular part of their process.
Today I came across DevGrind's How not to solve a Sudoku entry -- itself linking to Ravi Mohan's "Leaning from Sodoku Solver" -- where he links to a gent who implemented a thoughtful, sober design carefully, and another who pursued a TDD-approach, building his test harness, and then, it appears, flailing about madly in the hopes that some random keypresses will generate a solution that passes the test.
To demonstrate the value of TDD.
...Today's blast from the past is To GUID or not to GUID in your Database, where I describe the benefits and pratfalls of GUIDs in the database.
