Giving credit

I ran into someone who obviously had a handle on the PathGradientBrush before I did, so I’d thought it respectable to call out to his site where he details the PathGradientBrush use. Yep, it’ Bob Powell, and if you do graphics work you probably know of him, since he hangs out on the newgroups regularly. I don’t quite see my application of using it for shadows, but it isn’t much of a stretch from his billiard ball example. Thanks for all your excellent help, Bob.

Filed under: .Net Graphics

Connecting the history of the lover of truth (a.k.a the geek)

 

A dear friend of mine from my local community knows I love (first entry, meaning 7) technology, and I suspect it was a motivation to send me the following excellent transcript from dear Mr. Jobs:

‘You’ve got to find what you love,’ Jobs says

It finally struck me that today’s "geek" archetype (and Steve is very much one, regardless of what googlefight says) is a modern replica of those people who throughout humanity’s history have blurred the lines between spirit and matter in the quest for truth and beauty… how many of my colleagues, though not half as well-known as Mr. Jobs, could recount a story with startlingly similar features. It is the pleasure of finding the essence of things and using the knowledge of that essence to create and innovate in seemingly unrelated areas – seemingly, but as they share an essence not so – and yet these seekers of truth are satisfied more with the discovery than the outcome… the ancient Greeks, the Chinese scholars and philosophers, the Arabic poets and scientists, the great thinkers of the Renaissance all seem to be cut from the same cloth.

A recent(ish) post from one of my (soon to be) fellow code crafters put it like this.

 

More to say, but time wears on, with deadlines looming…

Filed under: Metathought

Knowing the DBMS

I ran into an issue recently where an application was not updating all the values it was supposed to be, and other values were mysteriously changing when they weren’t supposed to. Yea, sounds like a lookup problem. Either keys were being mixed up or values which were not keys were being used to do updates. The latter shouldn’t really be a case, since keys should _always_ be used to do updates (this forms the foundation for the relational model), but sometimes we run into this sort of thing in the wild.

 

At any rate, the problem had manifested itself in counts which were not exactly accurate. We were expecting zero or very near zero records which didn’t have a verification date on them, since the ad-hoc process we generated was supposed to create one based on the last modified date of the profile. However, after running, it turned out that several thousand records weren’t being updated. This sounds like a lot, but it was only about 1 – 2% of all records, so we forgot it temporarily and moved on.

 

Later, we started getting calls that our work to invalidate certain profiles was having an adverse effect, and updating records which it should have been updating. This was a big problem, since it would nag customers about it when there was _nothing wrong_. This is among the last things you’d ever want to do to your customers, for a number of reasons (irritating spam-sensitive users, desensitizing the behavior you want to encourage). This prompted action.

 

I traced the issue to code other than my own (again – whew! – it’s hard being an outsider and lacking the experience of the large institutional platform which everyone else has been living and breathing) – this time to logic which was updating the database in a batch update utility. The problem apparently was an assumption that the code would update correctly because of the position of the boolean check in the conditional statement. There was a two-fold problem to this logic, since the base assumption that the check would short-circuit was incorrect was complicated by the indeterminate (exluding use of the ORDER BY clause, that is) order of results of a SELECT statement. The programmer didn’t seem to know either of these things, which reinforces my belief that _every expert enterprise developer needs to have a firm grasp on database storage and retrieval fundamentals_ as well as near-expert depth of the peculiarities of the chosen vendor specifics. I’m not sure how other platforms do it, but SQL Server doesn’t short circuit OR statements (but it does AND statements). The docs try to lead us astray on this one, but a simple test shows us everything:

CREATE TABLE #Test ( myValue nvarchar(20) )
INSERT INTO #Test VALUES ( 'Test1' )
INSERT INTO #Test VALUES ( 'Test2' )
INSERT INTO #Test VALUES ( 'Test3' )

--The entire "OR" statement is evaluated, and not short circuited, even thought the first value is true (1/0 will return an error)
SELECT * FROM #Test WHERE myValue LIKE 'Test%' OR 1/0 = 1

--The "AND" statement is short-circuted, since T-SQL 8.0 does this for "AND" (1/0 will return an error) SELECT * FROM #Test WHERE 1 = 2 AND 1/0 = 1

--Test 1 will be returned first, even though it is listed 2nd, because the way the inserts happened, and how the loader retrieves the rows into the page buffers, and then how the query engine reads the buffers…
SELECT * FROM #Test WHERE myValue = 'Test2' OR myValue = 'Test' + '1'

Filed under: Getting Data

Another switch

I’m moving again. This time not to escape a bad situation, but to embrace a greater opportunity… and hey, we need health care. I’ll miss Intel and the folks around here… the experience has done much to solidify my desire and ability to code excellently. A lot was the driving, type-A culture and the remainder the separation from my family (2 hrs away) and my solitude during the week. A perfect storm of opportunity for an obsessive learner.

Filed under: Software Engineering

Passed 70-300

FWIW, I passed the 70-300 today (oops, May 31, forgot to publish). The MS free second shot promotion helped me finally commit. They extended it to August 31… let’s see if I can get a couple more out of the way.

Filed under: Software Engineering

SqlCommand.ExecuteReader deficiency

.Net exceptions have two purposes: signal that there was an exceptional situation when executing program flow which needs to be handled using routines that are separate from the main program flow (usually the catch block), and the other is to allow decisions to be made about how to handle what handled and take some appropriate action based on the type of the exception. HRESULTS did the same thing, but exceptions are more elegant because the exception code is outside the main program flow. Now, imagine if all you had was the Exception type (or HRESULT 0x80004005) – we would know that an exception occured, but the program would only have one recourse which would maintain program runtime integrity – exit. Since we don’t have information on the exception, we wouldn’t know if it was an input validation error or something more critical, like an access violation or that the system was out of memory. Strongly typed exceptions allow corrective action or graceful degradation of program execution in a reliable fashion. While most of the .Net Framework provides excellent variety of strongly typed exceptions which allow good programming structure and responsiveness, there is one notable exception: the ExecuteReader method in the SqlCommand class. Check out the docs: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemDataSqlClientSqlCommandClassExecuteReaderTopic2.asp

 

Notice that when a statement can’t be executed, a plain old generic Exeption is thrown! How are we supposed to know that this is what really happened, and not some other error like OutOfMemoryException or ExecutionEngineException which apparently can happen at any time? One might say, "Well, those are all subclasses of SystemException, so just trap that and handle it differently." However, there are many, many SystemExceptions, so should we differentiate in our catch statement among all of them, some of them, or what? Obviously, this is a serious oversight, since SQL code which doesn’t run is a quite common occurance. Perhaps this is fixed in 2.0….

Filed under: Software Engineering