I just made a couple of updates to our NSDate (Helper) project, thanks to a suggestion from Stephan Burlot in our comments. We’re not the only ones who think working with NSDate is a big pain! The code I had in there to determine relative days ago was based off of NSCalendar and while accurate in its own special way, wasn’t quite what you’d want for a relative time display.
In addition to the tweaks made in the code, I finally got around to creating a more illustrative set of examples in the README, and put up a corresponding document in our software archive. Check out how it works over at Github.
I miss my old Treo’s bluetooth sync capability. And for a device that does syncing (although in a much more limited way) and has bluetooth, it’s somewhat obnoxious that I have to sync over the wire with my iPhone, that wireless sync isn’t available.
It’s amazing that all smart phones still commonly cripple the bluetooth capabilities of the devices to keep you from using them and for all sorts of reasons – Apple doesn’t want you looking at the file system, Verizon wants you to buy ring tones over their EVDO network, etc. I was hoping Apple would be a pioneer here, tell the carriers to shove it, and go further than Palm did, making other bluetooth capabilities available.
On a mostly unrelated note, there has got to be a better way to package up and bundle Cocoa code you frequently use in different applications.
Last night we deployed a pretty substantial update to Tempo, our time tracker. Many of the changes are unseen, nuanced, and/or performance-related, so I want to give our customers an update on what we’ve done. It looks like a short list, but it was quite a bit of work. Details follow for some of the more significant changes.
Improved Time Zone Support
This was a huge update. In order to support future planned features we needed to overhaul our handling of time localization. There were a couple of hiccups last night during the deploy related to this, but we’ve got it worked out now. Tempo does browser-based detection of your time zone for new users, setting your time zone preference. On the Account screen you can now change this preference, should you so desire.
Remote Command Stability Upgrade
As mentioned last week, we’ve done a bit of work to make sure that our remote command message handlers are rock solid in the face of weird input via email, and outages on Twitter. The remote command handlers are Looper daemons that check to see if you’ve sent in time entries or timers by email or Twitter.
Batch Tagging Performance
Also mentioned here previously, the batch tagging interface received a serious speed bump. This was a bit tricky, because we’ve been caching tags as a concatenated string on the entries for performance. Nothing a little PL/PgSQL can’t fix.
Rails Upgraded
It’s no secret that Tempo is a RubyOnRails application. It started it out on 1.2 and we’ve kept upgrading with each update to the framework; we’re now on the 2.3 series. This brings significant performance and flexibility improvements. It may not seem like a big deal, but the amount of work that goes into making these upgrades a success is well worth the sweat considering the capabilities it opens up for Tempo in the future.
Potential XSS Vulnerabilities Closed
Being a security company, we try to never take the appearance of security for granted. We decided to give our code a thorough review to plug any potential cross-site-scripting vulnerabilities. Generally speaking, such holes allow an attacker to execute malicious Javascript in your browser. Such code can execute as you inside the application in question, which can wreak all sorts of havoc. Fortunately, we’ve been really on top of this from the beginning, so we only found a couple of instances in Tempo where this was possible, and plugged up the few holes we found.
Coming Soon!
That’s that for this update, but there’s a lot more coming around the corner. We have a new feature that’s almost ready, and we’re working with nGen Works to develop a new graphic design and improve the user experience dramatically.
We’ll be pushing a number of maintenance and performance improvements out to Tempo tonight, at 10pm EDT. This should only briefly interrupt service for our users. More information on the various changes will be posted here once the update is complete.
We all make mistakes. Or we make decisions that we have to later revisit, to put it kindly! I’ve got a Rails app where I wasn’t using UTC back in the beginning, and this was pre Rails 2.1, so ActiveRecord has been storing all the time stamps into postgres as Eastern time. I need to move all those dates over to UTC for this particular app to go through its next growth spurt, so I threw together a migration that does just that. I’d like to think it couldn’t get more DRY, hope it’s useful to anyone else out there. It’s dependent on Postgres, but you could adapt the increment statement to suit your own DB or to be more generic: