Friday, June 28, 2013
The Bug that Surfaced while Blogging Another Bug - Quicktime
So I was blogging the LinkedIn bug I found today, and this happened. Oops, Apple!
LinkedIn comment editor bug.
Responding to a thread on LinkedIn today, I noticed an annoying bug in the resizeable text control. It's a movement bug, so I decided to make a video of it for your enjoyment.
Friday, May 31, 2013
On Apathy, Voting, and Scalability
Though I have mostly focused on web portal bugs here, this has led to a sort of apathy for a number of reasons.
First, there are too many bugs in web portals. If you look for them, there seems to be, on average, more than one bug per web-page on the internet. Some of these are common, glaring, and recurrent to the point that they become boring to find. Navigating them is a lot like communicating with someone who does not speak the language well and is not paying attention - you just deal with it while trying not to become too bogged down in the workarounds. Facebook interface problems alone could fill a blog with daily entries for several years.
I have also recently spent a good deal of time on latin-american sites, where QA seems to be an alien concept, navigation is atrocious, functionality is spotty at best, and information is tremendously unreliable. Critiquing these is a waste of time, because the list of what works correctly is generally shorter than the list of what does not. Web-construction tends to be superficially imitative and full of poorly-implemented bells & whistles, while basic navigation and visual organization are clearly mostly not understood. If you like computing, it's a bit soul-crushing.
So, in the interest of not stopping altogether, here is one I found some time back on YouTube. This is interesting because YouTube seems to be on a continual release cycle, and the number and quality of improvements Google has made to the property since the purchase is absolutely staggering. It seems that, without much of a splash, virtually every pixel on YouTube now is subtly changed and has slightly different and vastly improved code behind it, while the visual metaphor has been gently shifted.
So here's some random video with 5,348 likes and 15 dislikes after 1,448 total views... There you go: Bug du Jour. I'm sure it was fixed in no-time, and I bet it's related to scalability. Here's why:
Back in 2007, when I worked at CurrentTV, one of the early problems I faced had to do with voting that was falling on its face, showing the user a beach-ball/hourglass for 15s after the click, at a time when Current.com had about 500 real users. That's abysmal performance by any standard, but when you consider the deals Current TV had in place with vendors that had Oracle running on fully-loaded state-of-the-art servers, there's obviously an issue, right?
Well, this is not an unusual scenario. Functionality that develops dynamically pushes prototypes into production with time-to-market trumping architecture, and the belief that this can be fixed later at center-stage in most product and release-planning decisions. All true and reasonable. People, however, have a tendency to freak out at this juncture in a prototype's life, but that's another topic. The story here is that programmers had conceived of a voting system that showed a tally, and made the mistake of trying to get technical sign-off from non-technical stake-holders*1, which had resulted in an additional (and reasonable) requirement that the user's vote be reflected instantly in the displayed tally of votes. Naturally, the programmer who wrote this function sent the vote to the SQL server and ran a query asking for the count of upvotes. The trouble was that the indexes were wrong on the table, so the update query was pretty slow, and the transaction isolation level was set to repeatable read, causing the query to block the count query.
To solve the problem I made a transactional table with asset IDs & vote counts (actually I did collect user IDs, timestamps, & origin IPs for analytical & weighting reasons, but not relevant to the story), indexed on these columns separately, and made the code get the vote tally initially on load, use a read_uncommitted connection, send the vote update off on a separate thread, and instead of re-querying for the tally, simply increment the on-load tally by 1 locally.
Net effect: wait-time for voting at 500 users reduced from ~15s to ~240ms, database reads for votes reduced by a factor of 2, expected performance for 1,000,000,000 users: ~630ms*2
So a little planning and application of basic algebraic principles can make the difference between handling a billion users comfortably and reaching a performance limit at 500 users.No doubt, YouTube was in the middle of making a change somewhat along this vein to their voting algorithm when I stumbled onto this bizarre result. I have, in any case, been unable to reproduce it since.
*1 - One might ask why this is a mistake. The reason is that non-technical users don't usually have practice visualizing a complete site from specifications, or being aware of the interdependence between logically separate presentation elements unless specifically shown. What happens then is that when users are shown partial implementations, it sets their wheels turning about the functionality that will go on top of the current functionality, and without looking at the current spec, they will at worst fall into the trap of reinventing already-specified functionality, and at best think of brand new functionality to add, sometimes resulting in significantly increased scope, regressions, and project slippages.
*2 - The performance prediction is based on the number of seeks it requires to read a b-tree index. Updating or inserting a row in a database will require two additional seeks, so we can add 2 to the result, but what is of interest here is noting that this number can be computed pretty reliably using the formula:
log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1
since block-lengths are usually 1024 bytes, an index on a mediumint column is three bytes long, a data pointer able to hold 4G discrete values is 4 bytes, then for 500 rows:
log(500) / log(1024 / 3 * 2 / (3 + 4)) + 1 = ln(500)/ln(2048/21) + 1 = 2.35
-a write requires 2 additional seek requests. So if we take the complete operation on a 500 row table to require 6.7 seeks (2.35 for the original read and 4.35 for the update), then the same operation on a 1 billion row table will require ~7.8 seeks, and 9.8 for the update, for a total of 17.6.
If 6.7 seeks took ~240ms, 17.6 will take 17.6/6.7*240=630ms
QED
First, there are too many bugs in web portals. If you look for them, there seems to be, on average, more than one bug per web-page on the internet. Some of these are common, glaring, and recurrent to the point that they become boring to find. Navigating them is a lot like communicating with someone who does not speak the language well and is not paying attention - you just deal with it while trying not to become too bogged down in the workarounds. Facebook interface problems alone could fill a blog with daily entries for several years.
I have also recently spent a good deal of time on latin-american sites, where QA seems to be an alien concept, navigation is atrocious, functionality is spotty at best, and information is tremendously unreliable. Critiquing these is a waste of time, because the list of what works correctly is generally shorter than the list of what does not. Web-construction tends to be superficially imitative and full of poorly-implemented bells & whistles, while basic navigation and visual organization are clearly mostly not understood. If you like computing, it's a bit soul-crushing.
So, in the interest of not stopping altogether, here is one I found some time back on YouTube. This is interesting because YouTube seems to be on a continual release cycle, and the number and quality of improvements Google has made to the property since the purchase is absolutely staggering. It seems that, without much of a splash, virtually every pixel on YouTube now is subtly changed and has slightly different and vastly improved code behind it, while the visual metaphor has been gently shifted.
 | |
| What's wrong with this picture? |
Well, this is not an unusual scenario. Functionality that develops dynamically pushes prototypes into production with time-to-market trumping architecture, and the belief that this can be fixed later at center-stage in most product and release-planning decisions. All true and reasonable. People, however, have a tendency to freak out at this juncture in a prototype's life, but that's another topic. The story here is that programmers had conceived of a voting system that showed a tally, and made the mistake of trying to get technical sign-off from non-technical stake-holders*1, which had resulted in an additional (and reasonable) requirement that the user's vote be reflected instantly in the displayed tally of votes. Naturally, the programmer who wrote this function sent the vote to the SQL server and ran a query asking for the count of upvotes. The trouble was that the indexes were wrong on the table, so the update query was pretty slow, and the transaction isolation level was set to repeatable read, causing the query to block the count query.
To solve the problem I made a transactional table with asset IDs & vote counts (actually I did collect user IDs, timestamps, & origin IPs for analytical & weighting reasons, but not relevant to the story), indexed on these columns separately, and made the code get the vote tally initially on load, use a read_uncommitted connection, send the vote update off on a separate thread, and instead of re-querying for the tally, simply increment the on-load tally by 1 locally.
Net effect: wait-time for voting at 500 users reduced from ~15s to ~240ms, database reads for votes reduced by a factor of 2, expected performance for 1,000,000,000 users: ~630ms*2
So a little planning and application of basic algebraic principles can make the difference between handling a billion users comfortably and reaching a performance limit at 500 users.No doubt, YouTube was in the middle of making a change somewhat along this vein to their voting algorithm when I stumbled onto this bizarre result. I have, in any case, been unable to reproduce it since.
*1 - One might ask why this is a mistake. The reason is that non-technical users don't usually have practice visualizing a complete site from specifications, or being aware of the interdependence between logically separate presentation elements unless specifically shown. What happens then is that when users are shown partial implementations, it sets their wheels turning about the functionality that will go on top of the current functionality, and without looking at the current spec, they will at worst fall into the trap of reinventing already-specified functionality, and at best think of brand new functionality to add, sometimes resulting in significantly increased scope, regressions, and project slippages.
*2 - The performance prediction is based on the number of seeks it requires to read a b-tree index. Updating or inserting a row in a database will require two additional seeks, so we can add 2 to the result, but what is of interest here is noting that this number can be computed pretty reliably using the formula:
log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1
since block-lengths are usually 1024 bytes, an index on a mediumint column is three bytes long, a data pointer able to hold 4G discrete values is 4 bytes, then for 500 rows:
log(500) / log(1024 / 3 * 2 / (3 + 4)) + 1 = ln(500)/ln(2048/21) + 1 = 2.35
-a write requires 2 additional seek requests. So if we take the complete operation on a 500 row table to require 6.7 seeks (2.35 for the original read and 4.35 for the update), then the same operation on a 1 billion row table will require ~7.8 seeks, and 9.8 for the update, for a total of 17.6.
If 6.7 seeks took ~240ms, 17.6 will take 17.6/6.7*240=630ms
QED
Tuesday, April 16, 2013
Monday, August 6, 2012
Is it a bug if it's deliberate?
There's something really exasperating about repeatedly watching things one once enjoyed or found useful being turned into sterile profit-extraction machines by minions whose overarching goal is to maximize near-term profit. Facebook could be accused of this since it's earliest public recognition, and has therefore become a darling of investors over the last few years. They did everything right, if you follow the money. The only thing lacking might be some functional compass that would say: Wait a minute - Our fundamental value-proposition was "I want to share stories with my friends", not "Let's just shop and decree consensus opinion!"
Many ruffled feathers have flown in the wake of sketchy privacy ethics, ubiquitous salesmanship, and not surprisingly, disappointing IPOs, but it does not matter too much. The public is forgiving in that it has a stunningly short memory. Oracle is a trusted guardian of your data despite having been caught red-handed falsifying bench-marks and committing various other venial sins in the capitalist bible over the years. Microsoft is a respected entity despite highly impeachable business and engineering practices and repeated convictions for antitrust and predatory marketing violations all over the world. I think there's a seemingly close correlation between the developmental psychopathology of a Facebook selling a hockey-stick reality to investors and serious gaffes in user interface design.
Over the past years, Facebook has refined and tweaked a UI experience that is very attractive to many. It renders a social stream of gargantuan proportions in a way that makes some very computationally intensive work look smooth and simple to a user. You mostly just see a stream & don't worry about it. While you do, database servers are calculating Erdos neighborhoods, Nosql datastores are rendering streams ordered on keys generated from these calculations, bright and unassuming machines are figuring out where to shuttle content so you can get it faster, and how to redirect your browser's requests, and servers are feeding you a list of stuff that seems relevant to you. In the end, it looks simple, but getting there requires a lot of horsepower, finesse, dollars, and CO2
What has gone slightly askew is that as the rumor-mill decided that Facebook would possibly replace Google as the 'search engine' of the future (*this has nothing to do with search and everything to do with recommendation - but accurate language is not the strength of the tech-mob) and Facebook's valuation, expectations, and implicit promises shot through the roof, something started going wrong, in a Film Noir sort of way - the interface became obtuse and seemingly flawed. Non-modal dialogs so often treed the user into decisions that were not necessarily her decision. Clicking in one check-box changed the state of others outside the user's field of view. In short, it started acting like Windows - like an interface that did not follow established or intuitive interface rules, and that therefore defined the result of an interaction without requiring the consent of the actor.
In a more erudite world, this might seem like coercive visual language. Many of the early examples, where brilliant young Facebook UI engineers erred in some glaring way in a given release of a small feature for a few hours, amounted to botched editing abilities. But the short training video I saw tonight for assigning a username to a Facebook profile was a bit frightening. It might not seem like much - just like it might not seem like much to give your social security number to the checker at a supermarket (seriously - people do this unquestioningly in more repressive regimes, and you do it implicitly each time you use your ATM or "frequent shopper discount" ID tags), but it surely is not safeguarding anyone's privacy or freedom.
So what jumped out at me tonight is that I got an email for Poverty Sucks, a Facebook page I made some time back that I have really not attended to as I should. It was an announcement from Facebook that I could now assign a username to the Poverty Sucks account to 'improve my numbers' (you can see I'm seduced already!).
The weird thing is that at this particular moment in the training video and likewise in the applied scenario managing the page on Facebook, I can check on the 'availability' of a name, but' without warning, if a name I check on is available when I'm checking on it, it becomes mine.
Visions of Mongol hordes raping an pillaging across the Caucasian planes notwithstanding, I find it a little forward to simply stick me with the first name I check on which is actually available, without telling me that 'checking' and 'buying' are now equal.
A sign of despair?
Many ruffled feathers have flown in the wake of sketchy privacy ethics, ubiquitous salesmanship, and not surprisingly, disappointing IPOs, but it does not matter too much. The public is forgiving in that it has a stunningly short memory. Oracle is a trusted guardian of your data despite having been caught red-handed falsifying bench-marks and committing various other venial sins in the capitalist bible over the years. Microsoft is a respected entity despite highly impeachable business and engineering practices and repeated convictions for antitrust and predatory marketing violations all over the world. I think there's a seemingly close correlation between the developmental psychopathology of a Facebook selling a hockey-stick reality to investors and serious gaffes in user interface design.
Over the past years, Facebook has refined and tweaked a UI experience that is very attractive to many. It renders a social stream of gargantuan proportions in a way that makes some very computationally intensive work look smooth and simple to a user. You mostly just see a stream & don't worry about it. While you do, database servers are calculating Erdos neighborhoods, Nosql datastores are rendering streams ordered on keys generated from these calculations, bright and unassuming machines are figuring out where to shuttle content so you can get it faster, and how to redirect your browser's requests, and servers are feeding you a list of stuff that seems relevant to you. In the end, it looks simple, but getting there requires a lot of horsepower, finesse, dollars, and CO2
What has gone slightly askew is that as the rumor-mill decided that Facebook would possibly replace Google as the 'search engine' of the future (*this has nothing to do with search and everything to do with recommendation - but accurate language is not the strength of the tech-mob) and Facebook's valuation, expectations, and implicit promises shot through the roof, something started going wrong, in a Film Noir sort of way - the interface became obtuse and seemingly flawed. Non-modal dialogs so often treed the user into decisions that were not necessarily her decision. Clicking in one check-box changed the state of others outside the user's field of view. In short, it started acting like Windows - like an interface that did not follow established or intuitive interface rules, and that therefore defined the result of an interaction without requiring the consent of the actor.
In a more erudite world, this might seem like coercive visual language. Many of the early examples, where brilliant young Facebook UI engineers erred in some glaring way in a given release of a small feature for a few hours, amounted to botched editing abilities. But the short training video I saw tonight for assigning a username to a Facebook profile was a bit frightening. It might not seem like much - just like it might not seem like much to give your social security number to the checker at a supermarket (seriously - people do this unquestioningly in more repressive regimes, and you do it implicitly each time you use your ATM or "frequent shopper discount" ID tags), but it surely is not safeguarding anyone's privacy or freedom.
So what jumped out at me tonight is that I got an email for Poverty Sucks, a Facebook page I made some time back that I have really not attended to as I should. It was an announcement from Facebook that I could now assign a username to the Poverty Sucks account to 'improve my numbers' (you can see I'm seduced already!).
The weird thing is that at this particular moment in the training video and likewise in the applied scenario managing the page on Facebook, I can check on the 'availability' of a name, but' without warning, if a name I check on is available when I'm checking on it, it becomes mine.
A sign of despair?
Wednesday, April 27, 2011
It's been a while...
I've been busy for the past few weeks scratching out a living in a barren land, and so haven't posted here, which is infuriating to me because I have a treasure-trove of newly discovered bugs. OSX, specifically Leopard, incorporated 'Spaces' into the core OS offering, and messed it up, just a little - reminiscent of Microsoft grabbing up enterprising utilities & de-clawing them until an upgrade was the only viable alternative... Oracle went on a binge, not unlike Microsoft some years earlier, to buy up favorites of the opensource community: Java, OpenOffice, and VirtualBox, and promptly broke two of the three badly. If you want a viable alternative to OpenOffice now that the Lord of the Sith has taken over the original offering, try LibreOffice. Del.icio.us was down for an entire day today in the wake of it's sale from Yahoo, witless defender of opensource. Facebook continues to be the crown jewel of the interface hall of shame with their wiggy text-box edit controls. Picasa has a couple of new ones, and both Firefox and Thunderbird have new releases that create pain in terms of long mouse-sweeps and inappropriately disabled controls along with a much slicker look and a level of crashiness previously unknown.
It's not as if new bugs aren't being delivered by the bushel - it's just that life got in the way. How annoying. All the same, it's time to hit the code again...
Monday, March 28, 2011
Spontaneous Problems with VirtualBox on OSX
In December I upgraded VirtualBox on my Mac to 3.2.12. Everything went great, and I proceeded to use it with very few glitches until later February, when I saw there was a version 4.0.4, and figured it was time to upgrade again. The upgrade went ok, but as soon as I installed the new Guest Add-ons for my Windows & Linux virtual machines, things started going south. Every time I tried to launch these machines, VirtualBox would produce lengthy error messages about unavailable USB support due to missing Guest Add-ons. I got in the habit of simply clicking through a bunch of modal errors on startup, and reinstalling Guest Add-ons every time I started a session. Trying to save the running machine state & reload resulted in a fatal error, so there was no short-cut. Well, a week ago, for reasons unknown, VirtualBox stopped working completely, giving me this gut-wrenching message as the virtual machine was initializing, and then closing the virtual machine - neither my Windows nor Fedora virtual machines would run anymore. This was a big deal, because I can't read my ReiserFS backup disk without the Fedora VirtualBox, and I can't initialize my 3G modem with the OSX software, (Movistar 3G Modem control program is deserving of its own post) but I can in the Windows VirtualBox.
Searching, I found a smattering of posts on the error-message. Most of them from other operating systems, but all describing exactly the same problem, and most concluding that the problem was that /usr needed to be owned by root for VirtualBox to work properly. To be fair, some people claimed having made this change and then being able to use VisrtualBox again. Swapping owners and permission-masks in the core OS because VirtualBox spontaneously stopped working seems like a perfectly irrational guns-ablaze panic response, like what one might get from a corporate tech preceded by a disclaimer about responsibility. Instead, I packaged my virtual machines into appliances, saved them off, uninstalled Virtual Box, and re-installed it, figuring that the installation script would set whatever it needed correctly as it did once before, and things would be OK again, but much to my surprise, the exact same error was generated every time I tried to start a virtual machine. I went back to look for more postings on the problem, and mostly ran into the same ones. What I noticed this time was that the ones that mentioned a version at all were all running version 4.x.x. On a lark, I went fishing in my packages directory and found 3.2.12, so I uninstalled 4.0.4 again, and this time rolled back, installing 3.2.12, and now everything works perfectly!
It seems like some external change, like updates to the core OS, might have changed something that 4.0.4 relies on, and I am sure a lot of folks using some of the newer features in VirtualBox really have no use for this solution, but if, like me, you use it mostly to test cross-compatibility, to use devices that have OS-specific drivers, or to access disks in different formats, it works. The lesson remembered is that whenever upgrading anything, it is a good idea to have a rollback plan and the necessary tools, like my older VirtualBox package, in hand. Of course, may OS's have tools to make this easier. OSX has Time Machine, and Windows has Restore Points, so if you have them, use them.
It seems like some external change, like updates to the core OS, might have changed something that 4.0.4 relies on, and I am sure a lot of folks using some of the newer features in VirtualBox really have no use for this solution, but if, like me, you use it mostly to test cross-compatibility, to use devices that have OS-specific drivers, or to access disks in different formats, it works. The lesson remembered is that whenever upgrading anything, it is a good idea to have a rollback plan and the necessary tools, like my older VirtualBox package, in hand. Of course, may OS's have tools to make this easier. OSX has Time Machine, and Windows has Restore Points, so if you have them, use them.
Subscribe to:
Posts (Atom)