Some of the more astute readers of my last article may have noticed that it took 40 seconds to run the LinkedIn sync on my address book. That’s not really surprising. Sync is slow and UI needs to accommodate it. Plaxo does this by popping up a warning and detaching the sync process so you can continue using the site.
[More after the jump.]
Not to be outdone
That’s something I wish that Tagged did since even my Yahoo! address book (around 1000 entries) takes a long time to import:
This is a peek at something I wrote on Wednesday and Thursday (okay, and part of Friday since I pulled another all-nighter). It’s why I have the weekend off because it discovered the performance issue plaguing our last release. I actually wrote the back-end for this a month ago, but didn’t create a GUI for it until this week when a persistent problem was costing the company serious money and possibly forcing a rollback of our last release.
I’m not a winner, but I really hate to lose. You’ll pry a product release from my cold-dead typing fingers.
Since I wrote it too quickly, the UI is actually a custom implementation based on an iframe Remote Scripting that’s less than a hundred lines of javascript and less than two thousand lines of code and HTML overall. (When you are rushed, you always resort to your bad habits.)
At least it was good enough to cause some jaw dropping at work. Watching one out of a hundred live requests flick in and out on a web top in almost real-time is simply a sight. (I tried real-time, but the browser would crash from all the javascript events.)
Isn’t that always the case? User interface is always the hardest thing to write, but it’s always worth it when it’s done.
Talk fodder
No, the image above doesn’t show the problem. The image was taken against our development site where the performance, usage, and user data isn’t close to typical and doesn’t reveal the problem. But put this tool on one of the servers in our web tier and you simply click on the red entries to reveal the problem.
But that’s really the point of this post. When you have a really complex internet architecture, you need bucket testing on live data to find problems that can’t be figured out otherwise.
Hopefully this will be fodder for a new presentation, tentatively titled: “The Internet is an Ogre: Brute forcing Art in Software Architecture.”
(OSCON rejected my last submission, time for a new talk.)
Do you think you’d be interested in it?
Yeah, this is probably the holy grail of development testing. Having the panels in place to know when it hits the fan. I’ve tried this in another unrelated area of development, not as good looking as your creation or as functional. 🙁 And it was lost on a rollback (need to remember to kill that person in an inhumane fashion… just kidding, the guy is alright). I think I learned a lot and I probably would have not used any of the code anyway.
Using your technique (using JavaScript to allow for richer interactivity) might had benefited the tool as it could be implemented as live, instead of running it against cached data.
I’m interested; not in the presentation, but the technique. If you write a book or tutorial then I’ll buy or visit it depending on which method you use.
(Finally, correct usage of internet in the context it was originally meant for, ‘internetwork’. Thank you. I do note that I lack proper grammar skills and in no way “mocking” those who code better than myself and use ‘internet’ instead of ‘Internet’.)