To do this, once the “delay” reaches a certain threshold, we simply change gears. What does this mean for the application? The simple answer: provide less intensive implementations based on the current gear. For instance, if your site has a lot of animations and the client’s browser can’t handle it, turn off more animations the higher the gear number is. That way, your app will tune itself to the client machine’s performance capabilities automatically. Here’s a link to the project:
[Gearbox.js on Github]
A couple of weeks ago I bought the “stevenhunt.me” domain name, and after tinkering for a couple of days I have launched the site. I will be using the domain to host demo applications as well as interactive tools for web developers. It also links to my other social media sites including this blog.
I have added the second part of the “Intro to jQuery” tutorial. It focuses on triggering actions when a user on your site triggers an event like a button click. Enjoy!
Late last year, I was working on a piece of code that was quite troublesome: I had a variable that was changing its value for absolutely no reason! I spent two days trying to explain how that value could possibly be changing, and got nowhere. The worst part: the program in question touched every record in the database when it ran, and if the value changed during the running of the program, records got orphaned.
The code in question started off as a mainframe application, but now it was C# code running against a SQL database and THERE’S NO WAY THAT VARIABLE CAN CHANGE. However, the vendor who built the ORM used unsafe pointers and GOTOs, so who knows… The other scary part is that the intended purpose of the program was to alter record keys, which is why it had to iterate over all of the tables in the database. For whatever reason, the value would reset to its original value after having updated about 20% of the tables and orphan all related table records from that point on. Needless to say that our customer was not thrilled with the outcome of the program since it hosed their data.
After bashing my head against a desk for several more days, I talked to the senior project manager about it. Having been a coder himself at one point and considering his generally “out of the box” thinking, he says to me “Why don’t you store the value in another variable, then when you get to the part of the program where the value changes, set it back to what it was supposed to be.” I said, “THAT’S CRAZY!” Well, I tried it and it worked. In the end, we ended up blocking the program so that people weren’t changing database keys to begin with, which is probably for the best. However, it was an interesting experience in programming the right way, getting the job done, and knowing when to change course.
So, I finally got a smartphone, a twitter, and now a blog which means I will be participating as part of the “Internet community” or whatever you want to call it. I will mostly be posting programming-related stuff, but sometimes I write about space policy, science, food, and maybe football.