there's a bug that's been bothering me. i fixed it, i solved the problem on Thursday but today, Sunday it's still nagging at me. At this point i'm not really sure what it is about the bug that's digging into my subconscious so hard. I can explain why it happened, the fix that I put in place feels a bit hacky but works. Why is it still bothering me?
I can't help but wonder if it is / was my initial reaction to the problem that's a bother. When I first saw the bug happen, I shrugged it off. It happened again, but I wasn't able to figure out a pattern as to when it triggered.
It took a third time to see it before I acknowledged that there was in fact a problem, however small, with the code. This disbelief in what I had seen with my own eyes bugs me. I can't get over how willing I was to just let it slide. I figured out a replication case, which was key to solving the problem: Knowing the preconditions for occurrence.
Yet what was it about me that made me think that I didn't need to dig into it? That it wasn't a real problem? Why was this a non-problem problem? I mean no, it didn't affect the functioality, just the visual appearance. It wasn't obvious what made it happen.
The deeper problem was with the fix. Did I fix it right? What else am I missing about the situation? clearly i was wrong at the outset about it, what else might i be wrong about? i know why he fix worked, i think, but was it the right fix? is there not a more elegant way to solve the problem?
the issue was that there's a flag that gets flipped when an element is moused over or moused out. in react you use a flag to communicate this state change to the drawing engine. when i clicked on a button, it dispatched a view redraw without triggering the 'mouse out' action so on the next drawing pass, the 'isHovered' flag was still set. when i activated a second flag (turning off my mic for example) then the notification that's supposed to pop up when you hover over an element showed up, but it showed up without triggering the layout code that dynamically centers it over the element beneath it. so there are really 2 problems that i'm trying to solve. one that the notification was showing up when the target item wasn't hovered (which i figured out what was going on and fixed). the other, unanswered question, is why the dynamic centering code wasn't being called. (it's done dynamically because the width of the element is calculated via the view engine aka CSS, and is dependent on the length of the text in the element, which is variable. by waiting until the element has been rendered and then using the total rendered bounds to calculate placement you can get it to hover precisely over the midpoint of the anchoring artifact)
here's some guesses: the element did not recenter because the props didn't change -- since the isHovered was flagged to true at both the inception of the item and when the variable that displays the item was switched to true, checking if the 'show' element has been updated misses the case where the show was on at the beginning.
in other words there still is a bug in my code, i've just removed the cases where it can get triggered. is that why it's been bothering me?
karthik and i went to the SF MOMA today to check out the last few bits of the soundtracks exhibit. we saw this great video work that i can&...
Continuing from last year, here's the stats and short synopses of books that I read (or didn't read) this year. According the Good...
Edgar Degas was obsessed with the female form. This much was obvious just from the few works that they had from him at MASP. I would go fu...
this has been copied without permission from the appendix of the 2011 edition of The Question of Separatism. It was conducted with Jane in ...