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.
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
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:
The last two weeks have seen a ton of development work here at Zetetic. We’ve been working to cut over one of our bigger client’s single-sign-on systems to a new location, we’ve built new features into the Strip beta (update coming soon, promise!), and we’ve completed a pile of performance, stability, and maintenance improvements for Tempo, our time tracker.
I should say that a lot of this work was made possible by an extra pair of hands; we’ve recently brought Bret Morgan onto our team as a developer. He’s been doing a lot of great Rails development work on Tempo and helping out with testing and Q&A for Strip.
Without going into all the changes we’ve made in Tempo, there are two I’d like to highlight:
Message Handler Stability
Tempo provides our customers with various ways to log time remotely and start timers, and our message handler is responsible for scooping up email and Twitter messages. We did some tweaking that dramatically improves its ability to handle the unexpected (you wouldn’t believe the weird stuff that comes in from MS Exchanges and Outlook systems), touches up its ability to respond to erroneous messages, and ensures that Message Handler keeps it up. We had some older daemonizing code in there, and ripped it out in favor of the Looper module we posted to Github recently. We’ve been using Looper in PingMe’s handlers for quite some time now, it was time to gemify it and use it in Tempo.
Tag Operations Improved ++bajillion
Sometimes you need to re-name your tags in Tempo, sometimes you need to add a tag like ‘oracle’ to everything tagged ‘apex’, and sometimes you just need to delete a tag from all of the entries in the current report. To provide this capability we added the Batch Tag interface, and it got the job done, but it was horribly slow. We got down and dirty with the SQL and updated our tag caching strategy to get it right. Operations on hundreds and hundreds of entries that used to take really long times (often leading to time-outs, I’m sad to say) are now complete within a second or two.
The batch tags interface still needs work, I will concede. We’re not entirely happy with the UI itself and expect to overhaul it soon.
We are planning to roll out these updates and more on Monday night EDT, and we’ll publish a full list of improvements made once it’s complete.
So let’s talk Strip. A number of people are already finding that the simple Categories → Entries navigation can be a little restrictive. We’re working on a number of features to allow for easy re-categorization of Entries, but there are two new features that will make accessing your data a lot easier:
Simple idea, extremely convenient, a tab displaying the most recent entries you’ve opened up:
I use this more than the Categories → Entries navigation already.
Sometimes I just don’t remember where I put something, and I don’t really want to figure it out, I just need the information, and I need it now. I also tend to think that perfect taxonomies are a thing of fantasy, and I get annoyed at software that expects me to be a perfect person. Accordingly, the new Search interface allows me to start typing the name of an Entry, or any data I’ve stored in Strip and it will pull up any matching Entries:
I think you can expect to see these new features among others in the next version of the Strip beta early next week. Thanks for all the great feedback, and keep it coming. If you’ve recently e-mailed us about joining the beta, or you’d like to join the beta, be sure to send us your device’s UDID to firstname.lastname@example.org. The Ad Hoc Helper app (free) will actually take care of the details for you.