It's not that it's a bad language, but Mail just doesn't like to run them. I had this fairly simple AppleScript that ran the Perl script for each appropriate email, and it works if I click on an email and tell Mail to "Apply Rules", but it completely ignores the Rule, or heeds the rule but doesn't run the AppleScript, or runs the AppleScript and crashes without explanation - when processing an incoming email. I gave up. It's for the best anyway. Now I'm not bound to using a Mac, or needing Mail running.
And I turned to the Mail::IMAPClient Perl module.
I took the blogger script and added an imap checking component. It looks in a couple different mailboxes for emails with a certain subject and downloads them. The matching emails are cached locally and subsequent checks only look for emails after the date of the most recent cached email.
Then processing continues as normal - handing off a path to a "raw" email which eventually finds its way to the blog.
And all of this is tied together with OS X's version of cron (ie, launchd) with a little plist file.
--
I ordered 2GB of RAM for my Mac mini, which already performs the duties of a file and media server, webcam streaming server, VPN, BitTorrent client - and soon it'll be tasked with holding the Postgres/PostGIS database for Locator and doing all of this IMAP checking and blog posting. The original 512MB was never enough and the upgrade cost something like $20.
I'll probably spend three hours trying to figure out how to open the case.
2009-03-29
More Locations
I found an easily parse-able list of ~1,100 US cities that includes their longitudes/latitudes and I wrote a little program to do the parsing and create the GIS-complaint SQL insert statements, and now there's all sorts of interesting points I can be near.
--
In June, Apple is supposed to release a new iPhone. I'm still sporting the "classic" model, because I wasn't that impressed with the 3G. I like the cool metallic backing of the original, and I'm not a fan of the new case design - to speak nothing of the so-so feature set. I have high hopes for the third-generation, which will hopefully be more than a simply-what-the-previous-generation-should-have-been phone.
In particular, I want a gps in my phone, finally.
With the little app that I'm writing, I should be able to "tag" a location, give it a brief description and push it to the database on my server. Not entirely unlike Loopt I admit, but this is mine - and that's important.
With potentially thousands of locations in the database, the SQL query to find the nearest point requires that PostGIS calculate the distance between the target point and each record in the location table. This isn't ideal. I read a brief conversation on this matter. The suggestion was to narrow the search to a bounding box (centered on the target point) that is relatively small, and increase the size of the box until at least one match is found.
But at what rate should the box size be increased? Double it every time? And what should the initial size be? A square mile? I guess it should be based on the density of points (on the order of a thousand spread across all of the US). Big enough that there's a sufficiently high probability of a hit on the first try, but not so large that there are many hits. Hrmm.
--
I was thinking that I should add an event table to the database. An event would have a location associated with it, and the event would be triggered when a Spot message indicated that I was within the specified tolerance of that location. An event might occur every time I am in/near the target location, or it might be a one-time thing. Then I could write a little bit of code to post certain messages to my blog when I finally arrived at a given camp on McKinley. Show a map. That sort of thing. I probably won't have time but I'm pondering it anyway.
--
In June, Apple is supposed to release a new iPhone. I'm still sporting the "classic" model, because I wasn't that impressed with the 3G. I like the cool metallic backing of the original, and I'm not a fan of the new case design - to speak nothing of the so-so feature set. I have high hopes for the third-generation, which will hopefully be more than a simply-what-the-previous-generation-should-have-been phone.
In particular, I want a gps in my phone, finally.
With the little app that I'm writing, I should be able to "tag" a location, give it a brief description and push it to the database on my server. Not entirely unlike Loopt I admit, but this is mine - and that's important.
With potentially thousands of locations in the database, the SQL query to find the nearest point requires that PostGIS calculate the distance between the target point and each record in the location table. This isn't ideal. I read a brief conversation on this matter. The suggestion was to narrow the search to a bounding box (centered on the target point) that is relatively small, and increase the size of the box until at least one match is found.
But at what rate should the box size be increased? Double it every time? And what should the initial size be? A square mile? I guess it should be based on the density of points (on the order of a thousand spread across all of the US). Big enough that there's a sufficiently high probability of a hit on the first try, but not so large that there are many hits. Hrmm.
--
I was thinking that I should add an event table to the database. An event would have a location associated with it, and the event would be triggered when a Spot message indicated that I was within the specified tolerance of that location. An event might occur every time I am in/near the target location, or it might be a one-time thing. Then I could write a little bit of code to post certain messages to my blog when I finally arrived at a given camp on McKinley. Show a map. That sort of thing. I probably won't have time but I'm pondering it anyway.
FindMeSpot Locator Alert!
Apparently we're still alive:
Location: 44.3621, -71.2901
Timestamp: 02/24/2009 09:05:42 (US/Eastern)
Map: Google Maps
Closest point of interest:
Description: Mt Washingtn, New Hampshire, USALocation: 44.27000, -71.30000
Distance: 2.16 miles
2009-03-28
First Post
Going to use this blog to do my location testing stuff, so as to curb the annoyances endured by those subscribing to my real blog.
Subscribe to:
Posts (Atom)