kai_mactane: (Default)

Back when I got my Palm Prē, I noticed that it wanted to store various of my information on Google’s servers. I thought I’d kept it from doing so; I sure wasn’t using Gmail on a regular basis. I configured the Prē’s email client to check my own account on mactane.org, and I thought everything was fine.

Eventually, I gave up on the Prē and switched to my current, Android-powered Samsung Epic. I figured I was in for a boring day of transferring my contacts over manually… until I discovered that many of them had been synced to my Gmail account, and so they showed up in my new phone without me having to do anything.

Considering all the work I had to go to in order to get my to-do list items, memos and notes transferred over manually… I decided that having stuff transfer automatically was actually pretty damn cool. Since I got my Epic, I’ve been picking “Save contact to Google” whenever I create a new contact. So, if I accidentally drop my phone on the street and it gets run over by an 18-wheeler and then the fragments get kicked into the bay and sink to the bottom, I can just buy a new Android phone and have all my contacts “magically” appear there.

On the other hand, all my contacts are sitting on Google’s servers.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

In my ongoing job search, I’m sometimes asked by recruiters: “How many years of experience do you have with [name of some technology or skill]?” It’s a somewhat reasonable question when the item involved is a programming language or technique that I use every day, or at least every week. But there are far too many things that it just doesn’t work for.

For example, I can reasonably well say that I have 5 years of experience with AJAX: I taught myself AJAX in the summer of 2005, and have been using it pretty consistently since then. But how many “years of experience” do I have with SQL?

I started using it around 2002 or 2003, but if I say that I “have 7 years of experience” with it, I give the impression that I’m some kind of SQL expert… which is definitely not true. It’s the sort of thing I use about once every week or two. I’ll set up a database schema, maybe even type out some raw commands in a MySQL command-line client, and then I’ll just let whatever framework I’m using handle all the details for me.

So, what sort of answer should I give to the question? The sense in which I “use” (or “have experience with”) SQL is simply not the same as the sense in which I use things like JavaScript, PHP, or CSS. (The sense in which a DBA uses SQL is probably comparable to the sense in which I use CSS… but I can’t be sure, not being one myself.)

At least the idea of having “a year of experience with” SQL does make a certain sort of sense. What should I say when asked how many “years of experience” I have with XML or JSON? These aren’t really “technologies” so much as data formats. It’s like asking someone how many years of experience they have saving files in .txt or .doc format (as opposed to using Notepad or MS Word).

The only metrics that are worse than “years of experience” are: “When did you start using Technology X?” (which, thankfully, very few people have asked), and the utterly subjective “How would you rate yourself with Technology X, on a scale of 1 to 10?” (I need to write an entire post about that particular metric, when I get a chance.)

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

If you haven’t been getting as much email as usual this past week, the culprit may be SpamAssassin. It turns out that SpamAssassin 3.2.5 (the current version, released in June of 2008) has a Year 2010 Bug.

The problem lies in the core configuration file 72_active.cf, which contains a wide variety of “currently active” rules. On line 543, it says:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

For those who don’t read regular expressions, this rule will match any Date: header that contains a string like 201x, 202x, 203x, etc., where “x” could be replaced by any digit. So, back in 2008, this rule would catch email that claimed to hail from the year 2010 or later. (Well, up to 2099.)

Starting on the morning of last Friday, this rule started triggering on pretty much all mail that hadn’t been delayed, thus adding 3.384 points to every piece of incoming email. Naturally, this could easily push mail over the threshold from “not spam” into “spam” when it doesn’t belong there.

If you’ve been expecting some mail that hasn’t arrived, and your mail host uses SpamAssassin, you might want to check your spam folder.

According to a note on the SpamAssassin project’s main page, you can easily correct this problem in either of two ways:

  1. If your system is configured to use sa-update, run it now.
  2. Remove the FH_DATE_PAST_20XX rule altogether by putting “score FH_DATE_PAST_20XX 0″ at the end of your local.cf file.

Alternatively, if you’re the mail administrator, and you don’t mind setting up a Year 2020 Bug for yourself, you could always change the part that says Date =~ /20[1-9][0-9]/ so that it says Date =~ /20[2-9][0-9]/ instead. After all, stuff that claims to be from years in the future (or past) is likely to be something you don’t feel like reading. But if you do this, I strongly urge you to find some way to send yourself an alert around December of 2019, warning yourself that you need to fix that problem. (And that may be easier said than done.)

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

I’ve always questioned the wisdom of building a startup company based around someone else’s platform, like Facebook games or Gmail inbox add-ons. You’re totally at the mercy of the other company. (Many people have found out how silly it was to go up against Microsoft or Apple in just the same way.)

And yet, here I am with Hummingbird, which is totally dependent on Twitter’s bandwidth. (In my own defense, I can only point out that: a) I wrote it because I needed the functionality; and b) I’m not building a money-making company around Hummingbird. I’m just giving it away.)

In the past couple of weeks, I’ve noticed that Twitter can sometimes take an astonishingly long time to provide an update. Hummingbird works by requesting URLs like http://twitter.com/statuses/user_timeline/kmactane.xml?count=25, and (up until now) it worked on the assumption that Twitter couldn’t possibly take longer than 10 or 15 seconds to respond to such a request.

That turns out not to be the case.

In fact, my recent tests have shown that Twitter can sometimes take over 5 full minutes to finish responding to such a request. This is a problem, because the default installation of Hummingbird tries to update its cached data once every 5 minutes. And since I assumed the request would be fulfilled in, at most, 10% of that time, I didn’t bother building in any concurrency checking.

I’ve just completely reorganized most of Hummingbird’s architecture. The interface that a blog owner sees (in the sense of the configuration variables in hummingbird.php, and the calling syntax for blog pages and cron jobs) is still the same. However, all of the code for retrieving data from Twitter has been spun off into a new hummingbird-cache.php file, which can be launched into the background by the rest of Hummingbird, so that it can patiently take as long as it needs to in order to update the blog’s tweets cache.

The Major Change This Causes

In Hummingbird’s previous incarnations, it would freshen an out-of-date cache before displaying it. The assumption was that every once in a while, someone might have to wait a few more seconds before seeing your blog page. However, everyone would always see an up-to-date record of your tweets. (Where “up-to-date” means “no more than 5 minutes old, absolute tops”. If you tweet so relentlessly that that’s a problem, you probably don’t have enough time to keep up your blog…)

Now that we know that Twitter can take over 5 minutes to give you the data needed to freshen your tweets cache, that design is not acceptable. Instead, Hummingbird is now committed to showing the contents of your tweets cache as quickly as possible, and only then does it fork the cache-update process into the background.

This means that, if you’re not using cron or some other automatic job-scheduling facility to run Hummingbird every 5 minutes, visitors who arrive at your blog after a period of inactivity will see an out-of-date, stale listing of your tweets.

If you have a cron job set to keep Hummingbird fresh, you’ll be fine. (A page view will also trigger an update, so if you get so much traffic that there’s never a 5-minute period during which your page doesn’t get hit, you’ll also be fine.)

Originally published at Coyote Tracks. You can comment here or there.

Profile

kai_mactane: (Default)
kai_mactane

July 2011

S M T W T F S
     12
3456789
101112 13141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 20th, 2017 09:53 pm
Powered by Dreamwidth Studios