“No Bugs” Bunny
“No Bugs” Bunny
Sarcastic Architect
Hobbies: Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek
Once upon a time, in a rabbit outsourcing warren of Bunnylore, there was a young software developer bunny. And as a developer, she has had one very unusual treat: she was obsessed with eliminating all the bugs she can get his forelegs on. So, it is not surprising that her friends called her a “No Bugs” Bunny (or simply “NoBugs”).
Later on, she grew up, so she decided that “Bunny” in her name has became inappropriate (not to mention potential arguments with Warner Brothers), so she has asked all her friends to call her “No Bugs” Bunny. She has made a career as a team lead and software architect, and they lived happily ever after.
Testing Memory Allocators: ptmalloc2 vs tcmalloc vs hoard vs jemalloc While Trying to Simulate Real-World Loads
July 4, 2018 by • “No Bugs” Bunny
Quote:
if you DO want to get performance from changing mallocs, make sure to test them with your own app
Another Quote:
in our humble opinion, overall winner so far (by a nose) is jemalloc.
Filed under: On.ProgrammingOptimizations
Read moreThe Curse of External Fragmentation: Relocate or Bust!
June 21, 2018 by • “No Bugs” Bunny
Quote:
We won’t ever get (almost) any virtual memory back, plain and simple
Another Quote:
relocation allows not only to reduce fragmentation, but to eliminate it entirely.
Filed under: On.ProgrammingOptimizations
Read moreHow to consume an HTTP API
June 11, 2018 by • “No Bugs” Bunny
Quote:
Programs are not the self-contained, self-reliant, self-sufficient things they once were.
Another Quote:
I highly recommend you log every HTTP request you send and every HTTP response you receive.
Filed under: On.ProgrammingTips and Tricks
Read moreUnchecked Exceptions for C++
June 7, 2018 by • “No Bugs” Bunny
Quote:
‘unchecked’ std::errors are treated as ‘something which should never ever happen, but in practice MAY occur as a result of potentially-recoverable bug'
Another Quote:
Failing-Fast does NOT mean we should necessarily Fail-Hard(!). In certain (production!) cases, Failing-Fast-AND-Soft IS a substantially better alternative.
Filed under: On.System ArchitectureDesign decisionsOn.ProgrammingProgramming LanguagesOn.DevelopmentDevelopment Philosophy
Six Impossible Things Before Breakfast Ltd. © 2026. All rights reserved.
