3 ms·

Couldn't upload files for more than a day. It was stuck at "connecting". I wish they had notified on twitter/blog upfront that they are still working on it.

by enscr 13y ago

jackgavigan 13y ago
About ten years ago, I had a minor epiphany while working on a system that used a standard client/service architecture. We were having "stability issues" with the back-end (trans: it was going down more often than a two dollar hooker). If the back-end service didn't responding, the GUI just hung; there was no indication for the end user that there was a problem - it just hung until it timed out (and because of the nature of the system, the timeout was relatively lengthy). This caused a certain amount of consternation amongst our users (because they were losing money as a result), who would far prefer to be told that the system wasn't working than to have to wait for a timeout. So I got the GUI developers to add in a little bit of logic along the lines of: if the response received from the back-end service starts with the string "ERROR_MESSAGE" then parse and display the ensuing text to the user else continue as normal We then knocked up a simple little service (using netcat, if I recall correctly) that squirted the contents of a text file back in response to any request, and echo >>'d the username supplied with the request into a text file. From then on, if the back-end service had a problem, we would redirect the load balancers to point to the mini-service so that any users would get a nice friendly error message (that we could edit/update) telling them that there was a problem. When the outage was over and we'd confirmed everything was working properly again, we'd would simply re-point the load-balancers back to the actual service IPs/ports, grab the file with all the usernames and email/call them to let them know that the service was back up. (We had planned to build more logic into the GUI and add an "Alert me when the system is back up" button to the error dialog, which would cause the GUI to automatically/silently re-try every X minutes and alert the user with a pop-up when full seervice was restored but we sorted out the stability problems before we got a chance to implement that). Maybe Dropbox should implement something similar so that, instead of being stuck at "connecting", users get an error message.

Couldn't upload files for more than a day. It was stuck at "connecting". I wish they had notified on twitter/blog upfront that they are still working on it.

by enscr 13y ago

Couldn't upload files for more than a day. It was stuck at "connecting". I wish they had notified on twitter/blog upfront that they are still working on it.

jackgavigan 13y ago

About ten years ago, I had a minor epiphany while working on a system that used a standard client/service architecture. We were having "stability issues" with the back-end (trans: it was going down more often than a two dollar hooker). If the back-end service didn't responding, the GUI just hung; there was no indication for the end user that there was a problem - it just hung until it timed out (and because of the nature of the system, the timeout was relatively lengthy). This caused a certain amount of consternation amongst our users (because they were losing money as a result), who would far prefer to be told that the system wasn't working than to have to wait for a timeout. So I got the GUI developers to add in a little bit of logic along the lines of: if the response received from the back-end service starts with the string "ERROR_MESSAGE" then parse and display the ensuing text to the user else continue as normal We then knocked up a simple little service (using netcat, if I recall correctly) that squirted the contents of a text file back in response to any request, and echo >>'d the username supplied with the request into a text file. From then on, if the back-end service had a problem, we would redirect the load balancers to point to the mini-service so that any users would get a nice friendly error message (that we could edit/update) telling them that there was a problem. When the outage was over and we'd confirmed everything was working properly again, we'd would simply re-point the load-balancers back to the actual service IPs/ports, grab the file with all the usernames and email/call them to let them know that the service was back up. (We had planned to build more logic into the GUI and add an "Alert me when the system is back up" button to the error dialog, which would cause the GUI to automatically/silently re-try every X minutes and alert the user with a pop-up when full seervice was restored but we sorted out the stability problems before we got a chance to implement that). Maybe Dropbox should implement something similar so that, instead of being stuck at "connecting", users get an error message.