Nappi Sight

I recently discovered a poorly documented (in fact I couldn’t find any documentation about it) side effect of writing server-side cookies.  They cause outputcaching not to work, and they do so in a nonobvious way.  If your outputcache directive looks like this: <%@ OutputCache Duration= "100" VaryByParam= "none" location= "Any" %> But somewhere in your page you have code that looks like: Response.Cookies[ "user" ][ "value" ] = "something" ; The page will not be cached.  Sure, it’ll have the public cache-control/expires headers, but the value will always be 100 (duration), and it won’t be cached by IIS.  There won’t be any errors or warnings, it simply won’t cache properly.  In our case it was even less obvious because the cookie writing code had been written a long time ago in a base page, and was only triggered on certain pages with certain querystring parameters.  Even when I discovered pages that I had assumed to

"One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision" – Bertrand Russell Learn to Read the Source, Luke – Jeff Atwood encourages us to read source code. 10 Reasons Why Visual Basic is Better Than C# – See, VB is better! The ASs of Distributed Computing – Overview of definitions of cloud computing terms Estimating is often helpful. Estimates are often not Kiva Engineering: Innovation Iteration – Dedicating development sprints to infrastructure or other IT chosen features. Providing Synchronous / Asynchronous Flexibility With jQuery.when Storytelling that inspires and delivers vision: Lessons from Google Glass –“But there's little that's emotionally resonant. It feels like a demonstration of how you'd do all the stuff you do on your iPhone today in your Glass tomorrow. The focus is on performing tasks that highlight features. It com

I was recently interviewed on the Uhuru podcast .  Other than the fact that you could probably play a drinking game based on the number of times I say “sort of”, it turned out pretty well. Listen

Last year I experienced a confluence of events that would be an exaggeration to say  changed my life, so I’ll opt to say they modified my life, not the least of which was turning forty.  Turning forty itself wasn’t that significant, more of a relief once the threshold had passed. I guess I had been subconsciously aware of its looming arrival.  Nevertheless, it got me thinking about my age and my health.  Until my thirties I had always been extremely thin, but that lost decade had seen me fluctuate between 160 and 190 lbs.  Each time I’d get heavy, disgust myself and then attempt to loose some weight fast, using Atkins , South Beach and other nonsense.  They worked temporarily but weren’t sustainable lifestyles.  About the time I turned forty last year, a few other things happened.  I had been diagnosed which some severe reflux and some other minor health concerns that required that I alter my diet.  I went to Disney with my family and found myself once again disgusted with my 180 lb.

Migrating from EF model-first to code-first with FluentAPI wasn't terribly difficult and resulted in far simpler code.  Once completed, the resulting POCO's were pure enough to appear to be compatible with NHibernate.  The question I wanted to answer was how similar Fluent NHibernate is to EF’s code-first FluentAPI in terms of how it managed those POCOs.  What I was ultimately looking for was some kind of definitive answer that demonstrated that they were either similar enough as to make no difference or dissimilar in ways that made one clearly superior to the other.  The most thorough and recent comparison I had seen was Dino Esposito's in 2010 , and that wasn't definitive nor was it necessarily tailored to our particulars. Hey my man, what it look like? What I found was that the model-first to code-first conversion was a much bigger switch than from code-first to NHibernate.  The resulting NHibernate implementation looked nearly identical to the EF code-first Fluent