Finding and Fixing a Five Second Stall
the-witness.net
the-witness.net
> From experience, I’ve learned that it’s always best to fully understand a problem before you fix it. If you just patch over its symptoms but never figure out what the problem really was, it will often come back to haunt you.
Philosophical-level statements like this really help me as a dev, since my one of my biggest hurdles is getting traction for even simple 1-2 line refactors that, in my opinion, can simplify code and improve maintainability. Far too often, I hear "just get it done", and I like to be reminded with statements like this of why "just get it done" doesn't always result in a better bottom line for the company.
>For some reason, I took this concept to heart in a programming sense and have found it is a good rule to code by. My version of the static discipline, adapted for software, is that whenever you are making a modification to a piece of code, you should always leave it in a state of stability equal to or better than how you found it. And preferably the latter.
I try to do this where I can too, and again, appreciate the philosophical explanation. It prepares me to more thoroughly and calmly explain my own work style.
The author laments Windows development, and I can only contrast that with my experience on an open source web stack (Ruby on Rails, Backbone.js). The upside of working with open source is that I can crack open the gem (library) I'm using and investigate the logic myself. I could fix the bugs or extend the code to do what I want. That is pretty cool.
The downside of working with open source software is that documentation is horrid. As the author states, man-hours are finite, and people who write OSS typically don't want to spend their finite hours documenting their code. I just take these as tradeoffs. It seems like Microsoft invests heavily in documentation, but I guess the author's point is that they can still do better.
But, when bughunting, there's often the dilemma of whether to fix the bug at the source (and hopefully, submit a patch to upstream), or to work around it (which can lead to horrific hacks) in your app code.
With the former, you're stuck having to deploy custom packages with your fix in until/if it gets accepted into upstream and a new release is rolled, so all too often I've found myself doing both. I don't know what the solution is; even a perfect patch to a superhumanly responsive maintainer is going to take some time to merge and deploy.
On an entirely unrelated note, a superb way to drive yourself insane is to edit the currently installed system version of the package in question, and then forget that you did some time later.
- fork the gem to make changes/fixes - complete fix and point my app dependency to my branch - add testing and docs around my fix - submit pull request to project owner - point my app dependency back to original gem when merged
That all said, I consider the activity of a gem before I even bother submitting a pull request. If it hasn't been touched in a month, or if there are open pull requests from 1 month or older, I weigh heavily just writing a 'my team only' solution.
This is admittedly selfish, but I'm hedging my time and emotional energy. I don't want to put care into crafting something that I believe to be useful only to watch it sit around unused because someone else doesn't want to review my work.
Not universally true (although it probably is true in most cases). PostgreSQL has great docs and I've heard good things about Open BSD although I haven't looked myself.
Such a crust of backward compatibility code weighs heavily on a decades-old OS.
"DISCL_NOWINKEY - Disable the Windows key. Setting this flag ensures that the user cannot inadvertently break out of the application".
(I found this flag to work entirely reliably on Win2K and WinXP, and I'm pretty sure it worked on Win98 as well. I think it also kindly disabled a bunch of other things for you, leaving Windows with only Alt+Tab and Ctrl+Alt+Del. Which is basically exactly what you want for anything full-screen.)
Back in the day I wrote networking service that was occasionally failing under stress load with memory corruption. I was staring at rare dumps, re-reading code and documentation to no avail. Finally, after few days of debugging, I went ahead and located debug symbols and sources (oh, I happened to work at Microsoft at the time) for the build of Windows we used at the test lab, it was relatively arcane procedure back then (it got better later, but at the time it was either symbol server doesn't work, or sources don't match).
So I setup gflags with memory guards and windbg and started waiting. After few days of stress run it finally crashed again and there it was - comment in the code of the crashing library saying "OVERLAPPED can be deallocated at this time if completion ports are used, but we save this value to it here anyways for backward compatibility reasons with bla-bla." Glad that you told me guys, I guess now I have to rewrite it and refcount the OVERLAPPED! I still don't know how I could debug it without the source access. (Ironically, it also enlightened me on why service I implemented at the startup before was occasionally crashing as well).
And don't even start me on implementing SSL support in the service.
Because this was Linux, we were able to read the kernel source to see what actually happens. It turns out that the signal is only blocked for the current thread, and Linux will deliver it to the first unblocked thread instead.
This misunderstanding also came from a less explicit API doc, although not outright incorrect. But because we had full stack source we didn't need guesswork, a good night's sleep or inspiration. Just curiosity and persistence.
There's a zen-like calm to knowing you can always, always follow a bug through the entire system, that everything happens for a reason and you can open an editor and see what those reasons are.
I will miss this deeply if I ever return to closed-platform development.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd14...
They deserve all the stalls they can get. The reason it was so complicated to get this behavior in the first place is because its heavily discouraged.
Not to mention that calling SetWindowsHookEx will flag you as a keylogger in every antivirus snakeoil in existence.
You mentioned expected behavior, which is good to abide by. But there's also preventing accidents. Your users are imperfect. It's the reason big red buttons also get a follow-up confirmation dialog.
Now, I'd definitely like to have a conversation about whether there should be a setting for disabling that override. But as for the default: it's pretty straightforward. When playing a fullscreen video game, the number of accidental occurrences of that button press far outweigh the number of intended uses. Pick your battles.
It by no means sanctions what still remains a terrible hack. A badly written hook could render a users system essentially unusable, and as I explained, its a very common heuristic for anti virus software.
The point remains: the fact that you have to resort to globally hooking all input to break the expected behavior of a key can not possibly serve as an example for bad documentation or bad API design. It in fact proves the very opposite: you have to work very hard to break what users expect.
I think the author would agree with your last statement. By forcing the applications to handle this logic and break what some users expect the API isn't serving the users or developers well.
I kind of had the feeling I could write code for a Mac and ship it.
Wait, in some sense I have done so before with code for computing fractals I shared with other Mac users in my department. It worked perfectly in my Mac and their Mac.
Wait! I have downloaded and paid for apps straight from some developers websites (top of my mind, or top of my menu bar: Hazel, 1Password, Arq)
So I just stopped my reading there, sadly.
> So I just stopped my reading there, sadly.
This is a fascinating article, and you're derailing the conversation (the article is not actually about the topic you're discussing at all). I recognize I'm only derailing it further, but I feel it is good etiquette to explain downvotes.
Even with what I read before getting out I knew it wasn't about platforms at all, but after that line I just wasn't as interested as when I decided to check it.
If the author meant "Gaming Platform" that makes a bit more sense.
And there's the stab at Windows 8.
So, yes. Games.