It's a pity I can't read this blog post. On an iPad it specifically prevents me from zooming and the font is too small. Please don't use "ipad-specific" or "mobile" themes. They break the web.
Zooming works fine here, ipad3, safari.
A bug I won't forget
21–28 of 28 posts
Re: A bug I won't forget
#22Earlier quoted context omitted.
Sidenote: I'm pretty sure the author is Paul Asmuth, not Paula Smuth.
Ah, thanks. I wonder how many people even know that dashes are legal in DNS names. (I mean, of course, the ASCII character that serves as hyphen, en-dash, and minus sign.) I think there are lots of domain names that would benefit from a well-placed dash -- the most amusing example I've seen being Pen Island's.
Expert Sex Change. (Familiar to almost everyone here, I think.) Power Genitalia. (An Italian battery company.) Whore Presents. (A service for finding out about people's publicity agents, etc.)
Re: A bug I won't forget
#23"I hadn't noticed this before since the parser is written in a way that it will ignore everything that doesn't look like JSON." and this is precisely why you want to fail hard if you encounter invalid input. Yes. It's annoying in the cases of "nearly valid" input or "valid input but with some garbage". Yes it's more work to deal with the error. But it also means that something like this blows up before you end up in…
I can argue this both ways, mainly based on who I focus on.
If I focus minimizing pain for the end user, I want things to blow up as little as possible. If I focus on minimizing my pain, I tend to go for hard failure.
For things that are important enough to spend the time on, I go for both: a system that is maximally kind to its users, but is internally a fussbudget. But that requires building a decent infrastructure for logging and alerting, plus an organization disciplined enough take the alerts seriously.
Re: A bug I won't forget
#24Earlier quoted context omitted.
Heh no, this was the actual bug (that it was reading "random" data from memory on the first iteration). I just hadn't noticed the issue until this "random memory" contained fragments of invalid json.
Were you or the network library reusing buffer objects (to avoid reallocating them), so the random data was leftover from an early socket read? I'm surprised the JVM would allocate a new buffer object with non-zero data.
Yeah, he was almost certainly reusing his byte[]s. My takeaway is that if you program a high-level language as if it's C, expect C-like bugs.
Re: A bug I won't forget
#25"I hadn't noticed this before since the parser is written in a way that it will ignore everything that doesn't look like JSON." and this is precisely why you want to fail hard if you encounter invalid input. Yes. It's annoying in the cases of "nearly valid" input or "valid input but with some garbage". Yes it's more work to deal with the error. But it also means that something like this blows up before you end up in…
I'm currently having issues with em-http-request, resque and resque-retry. It's still sometimes dropping work before the retry limit and not behaving nicely with the retry timespans. Also the async http request is not using the timeout value, randomly... It only happens with big traffic, like 0.01% just fails in a wrong way. It's not much, but still it's our and our customer's money. I hope our get together to solve…
I've noticed the same issue with that gem. It only happens randomly and with high density asynchronous traffic.
Re: A bug I won't forget
#26Would it be awfully smug to point out that Valgrind would've pointed this bug out in mere minutes? That's exactly why I make a habit of running my tests under Valgrind regularly during development; there's no point wasting hours debugging the classes of problem that tools can pinpoint in minutes.
Re: A bug I won't forget
#27Earlier quoted context omitted.
Were you or the network library reusing buffer objects (to avoid reallocating them), so the random data was leftover from an early socket read? I'm surprised the JVM would allocate a new buffer object with non-zero data.
Yeah, he was almost certainly reusing his byte[]s. My takeaway is that if you program a high-level language as if it's C, expect C-like bugs.
Likely reusing his directly allocated ByteBuffer and not checking the number of bytes that he filled it with.
From what I remember, directly allocated ByteBuffers are not guaranteed to be zeroed.
Re: A bug I won't forget
#28Would it be awfully smug to point out that Valgrind would've pointed this bug out in mere minutes? That's exactly why I make a habit of running my tests under Valgrind regularly during development; there's no point wasting hours debugging the classes of problem that tools can pinpoint in minutes.
Tangent -- it's crazy to me that println passes as debugging.