|
Featuring...
    Perhaps one of the most unfortunate situations I’ve had with a developer in the past is when one came to me and reported that a particular piece of software was ready; and when I asked for the protocol documentation, they told me that “The code is the documentation.” That’s amateur-hour. The code isn’t the documentation, and with good reason. Recognizing the necessary difference between the two makes the difference between a coder and a software engineer. So, your team has worked hard on designing a high-performance software system. One of the key components is a thread or service designed to buffer and protect the application from slow operations by caching the response of lookups from slower or more distant systems (like frequently used credential data or permissions, for example that might be coming from database servers). On the test-bench, everything looks good and then the code goes into production. Everything scales nicely up to peak loads, and then the whole system begins to stall and stutter. Performance ratchets in a staccato sinusoid, working just fine here, and coming to an almost complete halt there. After a while, as overall load falls and end-users become frustrated, it all sorts itself out and runs smoothly, until just after the next peak load. You direct the team to investigate, to profile code, to monitor logs and performance. Nobody can find a link. Your engineers come up with plans to optimize the cache service and eke every microsecond of performance out of it. Mysteriously, the problem just gets worse, not better despite thousands of hours and weeks or months of investigation, and tuning. Someone discovers that disabling hyperthreading on the server mitigates the problem significantly, but nobody’s closer to a solution. Congratulations, you’ve hit a common, but very rarely understood problem in high-performance systems design. It’s bitten almost every high-performance systems shop, yet almost nobody has truly solved the problem, because hardly anyone has understood the true cause at the time. Most engineers end up working around it, because they never quite know where to look. Let’s save the day and tell your team where to look. It might not be the source of your particular problem, but ruling it out early can save you tens of thousands of dollars in development, and far more than that in frustrated customers. Well, it’s been a bit of a difficult slog, but I’ve made a slew of changes to the blog template to allow for the site to be better-rendered by a variety of browsers. The so-called “Y2K bug”, which technically isn’t a bug, and was not solely confined to the year 2000 is widely hailed by many people to have been a false alarm and a waste of time and money. I’ll now take the time to call those people ‘idiots’. A bunch of people ask me fairly often why I’m so keen on the Imprudence viewer for Second Life. This is why.
Well, you’d think. In fact, you’ll be lucky to make it through the week with your sanity. If you’re a Windows gamer, you’ve very likely had the issue where you’ve installed a game (including, but not limited to, Scrapland or System Shock 2), and when you start up the game, you get a black screen. Maybe there’s sound, maybe not. Maybe the application works except for the video – and maybe it doesn’t. When it doesn’t, you often have to use control-alt-delete to break out and kill the process. There’s a bunch of possible causes, but one of the most common ones is easy to fix. Recently, I’ve been toying with the idea of shucking Windows XP and flirting with the idea of purchasing Windows 7. I picked up Windows XP with a new system close to the last days it was still available. Talking the matter over with a friend, led to a conversation that went something like this: Okay, so you probably use a password manager or something like that, because – face it – you’re probably not daft enough to use the same password for everything, right? Right? Right! Your ‘password manager’ might be a simple paper notebook, something like KeePass (recommended, by the way), a sheet of paper, or a simple text-file that you keep somewhere on your hard-drive. Whatever it is, just think a moment. If there was a fire or a flood or a robbery or whatever at home, would you still have your passwords? 
|
Support us |
|||||||||
Dwell On It is proudly powered by
WordPress
Entries (RSS)
and Comments (RSS).
© Tateru Nino. All Rights reserved.
Tateru Nino and Dwell On It are trademarks of Tateru Nino. Your local laws provide the conditions for your fair and reasonable use of these marks.
All other trademarks are properties of their respective owners.
It’s the early 1600’s, the plague is in town (again), business could be better, and Shakespeare’s gearing up for a new play at the Globe. You’ve got a dinner invitation from an old acquaintance, whose lively and ribald tales stand to brighten things up .
