 |
|
|
fogbound.net
Thu, 17 Sep 2009
Wed, 9 Sep 2009
So, in the middle of working on something, the balance of luminiferous ether in the universe must have come unhinged, because every other column of pixels on my screen went black:
 View at full resolution to see detail
I tried the usual tricks, to no avail. I figured it was a hardware connector issue, so got an appointment at the Apple store. However, to my annoyance and chagrin, the problem has proved intermittent. It “cures itself” and then recurs. This supported my theory that it was a connector issue, or so I thought.
The Apple Genius, however, taught me a trick to reset the graphics subsystem: shift + control + eject
The last time the problem arose, this trick *did* cure it.
So the question is – is my graphics card going south? Is this some bug in recently installed software (Snow Leopard, the new version of iStat Menus, or Final Cut Express)? Could it be entirely due to my attitude? Or was the reset cure also a coincidence? Only time will tell.
Fri, 2 Jan 2009
So. Millions of people use Apple’s Mail.app. Someone must have a solution to the problem of households … but I somehow have been left in the dark.
Stated more precisely:
I have numerous friends for whom I have multiple contacts. For example, Alice Code and Bob Crypto are what we now call pairbonded partners. They share a common home address, but separate cell phones, email, work addresses, work email, etc. So I end up keeping three records for the two of them: one for Alice, one for Bob, and one for Bob and Alice.
Now, three records for two people isn’t so onerous, particularly when there’s not a lot of redundant information. But then, if they happen to have a land-line, and change the number, I have to update three records (unless I only put home number for the common record, in which case I’d have to remember this protocol). And the fact is that there are a lot of redundant notes I try to keep, such as anniversaries, favorite charities, etc. This makes the system unwieldy, especially since my whole goal is to reduce the amount of stuff I have to remember and maintain.
So how do people in the real world manage this? Bonus points for solutions that will still work when I sync to my Palm-OS based phone!
Sat, 13 Sep 2008
So it’s a familiar problem, where you’re developing a data-driven application, and you want to optimize the queries that will run against your database (I’ll have more interesting stuff on this later). The problem, of course, is that to really optimize those queries, you need a lot of sample data.
So I needed to do some address lookup code against a huge collection of users. But because there was the possibility of having to demo the prototype, I really didn’t want 100,000 users named “Foo McBar” living at “10101 Binary Place.” So, with the help of the almighty Internet, the all-frobnicating Perl, and the all-knowing US Bureau of the Census, I created a quick, semi-flexible script to generate people with plausible names and addresses that, if not Google-mappable, at least had agreement on city/state/zip. The city/state/zip is a collection of 250 random zip codes. If you have good zip code data, you can easily extend this to be complete! Names are generated from the most popular forenames and surnames, with a probabilistic bias towards the most common ones. The script also allows you to specify “pick one of n item” type fields, pick a number from a range, plausible email addresses, not-very-plausible phone numbers with or without extensions, and the ability to export as CSV or tab-delimited.
In principle, this should be easy to adapt to other countries, although you’ll need lists of common first names, surnames, street names, and a way of mapping cities to regions, states, districts, cantons, or whatever’s appropriate.
You can grab a copy of it here. It requires a Perl interpreter with the Text::CSV and Getopt::Long CPAN modules.
Usage: user-data-maker.pl [OPTIONS]
-t, --header : header, a colon-delimited list of column headers
-f, --format : format string, a colon-delimited list of column contents
data types:
fn - first name
ln - last name
a1 - street address
a2 - apartment number
c - city*
s - state*
z - zip 5*
e - email address
pne - phone (US), no extension
pwe - phone (US), with extension
[a,b,c] - one of a, b, or c
{a,b,c} - one of a, b, or c in decreasing probability
[x-y] - a number between x and y, inclusive
* city, state, and zip will be agree to create a valid address
if you need multiple addresses, use the code ! to reset the
synch. The reset works on a left-to-right scan of the format string.
-n, --number : number of records to create
Flags:
-c, --csv : output CSV format (otherwise, tab-delimited).
-v, --(no)verbose : verbose mode (default false)
Example:
Viajante:samuelg$ user-data-maker.pl --header "First:Last:Age:Email" --format "fn:ln:[10-100]:e" -n 5 --c
First,Last,Age,Email
Margot,Sawyer,33,Margot.Sawyer@netscape.com
Francisco,Cantrell,18,Cantrell@sbcglobal.com
Lynetta,Orozco,28,Lynetta@mac.com
Latrice,Dunlap,41,Latrice.Dunlap@sbcglobal.com
Anissa,Fitzgerald,59,Anissa@hotmail.com
or, more exotically:
Viajante:samuelg$ user-data-maker.pl --header "First Name:Last Name:Address:City:State:Zip:Super Power" --format "fn:ln:a1:c:s:z:[Invisibility,Invincibility,X-Ray Vision,Flight,Likes Squirrels]" -n 5 -c
"First Name","Last Name",Address,City,State,Zip,"Super Power"
Roseanna,Best,"8821 7th Str.",Manati,PR,00674,Flight
Euna,Crawford,"8195 Lee Str.","Fort Washington",PA,19034,Invincibility
Ted,Williams,"7140 Birch Ave.",Monroe,CT,06468,Invincibility
Mariano,Miranda,"2657 1st Way",Lyford,TX,78569,Flight
Tammy,Flowers,"2135 Washington Blvd.",Duluth,MN,55806,"Likes Squirrels"
Enjoy!
Wed, 28 Nov 2007
I’ve done some more work on the Aperture Importer (background here), and the latest is attached below. It now does some reformatting of keywords that get split (e.g., “San” and “Diego” can be merged to “San Diego” as a keyword.) It’s hacky and ugly. You’ll have to set up your own keywords for this kind of merge.
I’ve found a couple of apparent Aperture bugs.
If I tell Aperture to import an empty directory from Applescript, it’ll stall and lock up Aperture.
Worse, I find that if I do a large import (more than, say, 5,000 images), Aperture grabs a bunch of memory that never gets released. Well, Aperture itself doesn’t grab the memory, but it causes the kernel_task “process” to allocate a big pile of real memory, which it seems to hold on to until reboot.
It’s a cumulative thing: if I import 5,000 images, the memory gets grabbed. Then, if I do another 5,000 image import, the memory usage doubles. Thinking it would be handled by swapping, I didn’t worry, and continued. This was a bad idea. Aperture locked up, but so did the whole OS. The last thing I could see from top was that 100% of my real memory was allocated, that less than 256M of swap was in use. I had at least 50GB of disk free, so that wasn’t the problem.
Anyway, for safety, if you use this import script, I recommend rebooting between import sessions. Yeah, it’s voodoo, but it’s guaranteed to work.
Aperture Importer Update
|
|
|