Google Chart API and large queries: the wrong end of a problem

Recently I have stumbled upon a "floating" (randomly appearing and disappearing, the nastiest kind) bug in the legacy code of an in-house financial system: a pie chart, drawn by Google Chart API, sometimes disappeared from the report. After a quick investigation I found out that requests URLs to the API were too long. First, I thought about converting request to POST. Thanks to the Good Empire, they added the POST support to their Chart API.

But then it dawned upon me: who on Earth needs a pie chart with 50+ sections? It is absolutely unreadable! Why the users even wanted to call this kind of report? Inertia of mind - they put all data they had in the report just because they could, and they just didn't care about the result.

Grouping all the "small" (under 1% of the chart's total value) entries into a single "Others" entry not only fixed the bug, but also rendered the report much more readable, and made customers happier.

Valuable lesson learned: never underestimate the inertia of mind – the customer may be actually unaware of what he really needs. The more usable your cases are, the simpler your code will be. And sometimes discovering a bug in your system can be a good thing: it can give you a possibility to improve the system's design.

Comments

  1. AnonymousDecember 2, 2022 at 7:38 AM

    We at all times prioritize online on line casino bonuses that give users an excellent probability to show the bonus cash into actual money. Sloto Cash welcomes its new gamers with a staggering $7,777 worth of welcome bonuses and 300 free spins on 5 of the preferred slot games in its on line casino library. You only have to make a deposit of 점보카지노 $20 to claim this bonus.

    ReplyDelete

Post a Comment

Popular posts from this blog

High-volume sampling: algorithms’ comparison

Goal : To determine the most efficient way to perform high-volume sampling. Set-up : The sampler's goal is to give permission to sample use a given sampling rate; (approximately) each 1000th request should result in actual sampling. There are several samplers: AtomicSampler: uses AtomicInteger to keep track of sampling attempts;  RandomSampler: uses an instance-wide Random instance to determine if a sample should be taken.  RandomSampler2: uses a local Random instance to determine if a sample should be taken, which is initialized each time.  XorShiftSampler: uses a XOR-Shift algorithm to produce psedo-random numbers ( http://www.javamex.com/tutorials/random_numbers/xorshift.shtml )  Before actual measurement each sampler is called 50K times to warm it up and give a hot-spot compiler a chance to compile the samplers' bytecode into a native high-performance code. Then 10 runs are performed, using a variety of scenarios. 10M sampling attempts are performed during each
Read more

Spring Framework and Code Obscurity

I just realized why what I don't like about Spring Framework. Don't get me wrong. I love Spring Framework. I use it daily. In fact, I am a huge fan of it. But there is a constant "something is wrong" buzz in the corner of my mind. And I finally caught it. The name is Obscurity Yes, all the Spring annotation fairy dust magic just works. It is great. It removes boilerplate code. It is supposed to make your code easier to read and maintain. And it does - to a point when it doesn't. A simple example: @Scheduled(fixedDelayString="${execution.delay_ms}") public void scheduledJob(){ // your code goes here } Easy, right? A few lines of code, a configurable property to define a delay between runs, what can be more simple? A few questions: How do you know what threadpool this scheduled job used? How do you to configure the threadpool? How do you test the scheduling part of your code? Ouch, painful!
Read more

Multi-threading skills - what do you mean by that?

A while ago I mentioned the possible need of brushing up our multi-threading skills. Having said that, I cannot but share the post I came across a few years ago in the RSDN.ru forum . Disclaimer: I am not the author of the original post, I merely translated it, hoping its content can be useful. Lately, many Java Developer job openings started to include Java concurrency/multi-threading as one of the requirements. As a response, many developers immediately added the corresponding line to their resumes. Being the one who runs interviews, I'd like to dispel some of the misunderstanding that is related to the term. I'd like to split all multi-threading-related projects into 3 levels: the ones that use multi-threading; the ones that are based upon multi-threading and the ones which are multi-threading itself. The first level ("the ones that use") includes projects that are meant to run in the multi-threaded enviroment. E.g., there is BlahBlahFactory class and you n
Read more