Wednesday, February 25, 2009

Sync early, sync often.

Update: the phone wasn't stolen after all, I somehow lost it and it somehow didn't ring when called. But this post has some interesting ideas anyway.

It's entirely my own fault. I had my iPhone in an outside jacket pocket, without being aware of this fact, in a bar, at night, in a not-so-great neighborhood, in big city in a recession, while speaking a foreign language.

So I deserve no sympathy. iPhones are stolen from better people every day.

However, it does get me thinking about a few things.

Always remember you have no automatic sync.

Of course you know that you have to connect your iPhone to your computer in order to synchronize your contacts and such. And of course it's annoying, so of course you put it out of your mind.

I just lost a week's worth of vacation pictures, and one very important phone number. I can recover about three of the pictures, which I had e-mailed to people, and I'm pretty sure I can get the phone number through a mutual friend.

But if I'd just bothered to sync once a day I would be in much better shape. And I did charge the phone, so I have no excuse: I was simply too lazy to bother with a daily sync.

Identity theft: what to do about the risk?

I was using a PIN code to prevent easy access to my iPhone. I was able to deactivate the number and reset my e-mail password without incident.

But there's still a large amount of personal data on that phone, most of it unencrypted. E-mail, address book, photos, bookmarks...

I think it's reasonably safe to assume the thieves will reset it, hardware unlock it, and sell it for about $500 on the local grey market. There's plenty of demand, and identity theft is hard work.

On the other hand there's no way to be sure somebody won't do the work and have acces to that frighteningly detailed archive of your life.

In principle this is no different than having your notebook stolen. And that's a good reminder: always encrypt your home directory and always back up your important data. (Note to self: use FileVault on the private Mac just like I do on the work Mac, as soon as I get home.)

But the iPhone doesn't have FileFault, at least not that I'm aware of. I never gave it much thought, but now it strikes me as a really bad idea to not encrypt application data in (at least) Mail and Notes.

The lack of unlocked iPhones makes theft worse, not better.

Finally, I'm convinced that theft would be a much smaller problem if provider-neutral (SIM-unlocked) iPhones were readily available.

I am quite sure that most of the gray market in iPhones is for people who want to use them with other carriers. This is particularly true in Europe, where the entire network is GSM and 3G coverage is excellent, but Apple only partners with (usually) a single carrier in each country.

It would also make life a lot easier for the theft victim. I'm still traveling for two weeks, and now I have to travel iPhonelessly.

If I could easily buy an unlocked iPhone, I could use it for the rest of my trip and then get my SIM card replaced as soon as I return to the US. It would vastly reduce the inconvenience to me, the customer, and it would make money for Apple.

But of course it would make less money for AT&T.

*Sigh* - off to ebay to look for my stolen phone.

Monday, February 02, 2009

Apple is behind the social networking curve.

I know Apple isn't a "social network" and I know it's not a "Web 2.0" company (the ongoing slow-motion train wreck that is MobileMe notwithstanding).

I don't care. Apple is still my favorite technology company.

But I just had an experience that illustrated just how far behind the Web curve Steve, Tim &co are.

I was using NetNewsWire to read the latest computerite news on my iPhone. This is, I'm informed, a fairly standard way of staying informed.

I came across a post on Daring Fireball that really wanted to be opened in Safari. And so I did. And indeed, it was awesome. And I wanted to post it to Facebook, and --

This is not possible.

Fine. I went to the laptop and made it happen. Voila, just like in 1998, use the computer for the computer things and don't forget who's who.

How sad. How absurd. How simple to add a "Share Link" option after "Mail Link to this Page." Let the user configure it to use Facebook or MySpace or both or something else, as long as the (public) API is respected.

Cost to Apple: $0.00 (I guarantee Facebook would send them a dozen engineers to do the work).

I would say it's not Apple's problem, but there is a precedent: Google Maps links open in Google Maps, and YouTube links open in YouTube, and of course I would never imply anything like a conflict of interest with Apple's valued board member and competitor-on-many-fronts Mr. Schmidt.

I hope to see this soon. And if Apple really doesn't want to keep Safari up to date in these things, fine: as long as they give us the option of choosing our default browser in the iPhone Preferences.

Thursday, January 29, 2009

Easy to Book.

I just booked a hotel, which is something I don't do terribly often.

And while researching hotels on the wonderfully informative, horrendously designed TripAdvisor I found someone mentioning easytobook.com.

Off I went, and I was very pleasantly surprised. I ended up booking through them. It was easy.

http://www.easytobook.com/

And I got a very good deal. I recommend it.

Sunday, December 07, 2008

Twitter Train Traffic

I still haven't quite talked myself into using Twitter but I suppose I'm inching towards it.

Today I ran across a really cool use of the service, but one that also shows the flaw in its enforced brevity: Swiss rail delays are posted at http://twitter.com/oev.

This is a great idea, and apparently the PR folks at Burson-Marsteller had something to do with it. The only problem is that the cornerstone of Twitter is a 140-character limit on posts ("tweets" to the kids).

So you get things like this:

Zwischen Ramsei und Langnau auf der 
Linie Burgdorf - Langnau ist die
Strecke für den Bahnverkehr un...
#sbb #cff #ffs
...which translates loosely as "Between Ramsei and Langnau on the Burgdorf-Langnau line, train traffic is un..."

Of course you could always hire a programmer to condense all that into txt-ese bt nobdy likes u thn. Or you could break it into multiple "tweets," but that breaks the paradigm.

Instead, I think Twitter should allow longer "tweets" in cases where all of the following conditions are met:

  1. The twitterer is a robot.
  2. The information is also available elsewhere (i.e. it's not someone just asking for special Twitter treatment).
  3. The feed is clearly a public service.
  4. Information would clearly be lost at 140 characters.

Traffic reports of all kinds would qualify. Updates from your political party, television show, or church would not.

Saturday, November 29, 2008

Giving up on a local WordPress install on Mac.

Summary

WordPress is nice, but setting up a local instance in a nonstandard environment is more trouble than it's worth. WordPress was designed for shared-hosting environments that have a classic "LAMP" application stack preconfigured (Linux+Apache+MySQL+PHP). It was specifically not designed to run on a wide variety of server environments.

Fortunately, for the kind of work I want to do (blog template design) there are acceptable workarounds. But this latest encounter with the MySQL and PHP ecosystems has left me, once again, sorely tempted to just build my own blogging system.

Read on if you want to geek out on some of the details. If you just want the conclusion, it is: use a standard virtual machine (VM) or set up a sandbox blog in a shared environment. Either one of those will work well enough, and the VM approach is probably the closest you'll get to a "safe" install. Unless you're being paid for the setup time, I strongly advise against trying to make it work locally in anything but a stock configuration.

Motivation

A while ago I set up a blog with a friend of mine: Migratorium. It's an outlet for our travel writing, or at least it will be.

It runs on WordPress in a shared-hosting environment over at Dreamhost: bang, meet buck, at least for small projects. I really like the WordPress user interface, but even with great templates like veryplaintxt I quickly became frustrated with the design possibilities.

In short, you have to learn some PHP (painful but not so hard) and the arcane, under-documented WordPress templating system (ditto) in order to do any meaningful design. Since I already know HTML, CSS, Perl, and Template Toolkit, I thought I'd be much happier building my own sites using those technologies. And it would keep me away from PHP, which I dislike, and MySQL, which I abhor.

Then I thought about setting up an RSS feed. No biggie, just another afternoon. Then I thought about setting up a decent editing UI. No biggie, just another weekend. Then I thought about making it easy for my non-computer-geek friends to use. Uh-oh... that started to sound like real work.

So I decided to make at least one serious effort to teach myself enough WordPress Templatese to either do serious design in that ecosystem or give it up from an informed position. And for that I need a local copy of WordPress in which to hack the templates.

Technical Goals

I'm doing this on an Intel Mac running the latest version of Leopard (OS X 10.5.5 as of this writing). I use lighttpd as my local web server and would prefer to use that, but I will use the built-in Apache if I must. I have MacPorts installed, but I would prefer to run this under the system default PHP. I also want this to run on SQLite if at all possible, since I want to hack templates, not databases.

Trying to Get There

  1. I checked Google first.

    Oh-oh. The first thing I found is that only MySQL is supported, as WordPress doesn't have a database abstraction layer. That's a shame, but it seems like an absolute.

    There is one plug-in that gets you close: PDO, but its limitations make it sound just about as onerous for my purposes as MySQL itself.

  2. Install MySQL

    OK, let's see if this can be done with minimal exposure to MySQL. 2 tablespoons has some instructions for getting MySQL running under MacPorts. That almost worked, but not quite. Following more info under the comments I found I had to set the socket file in /opt/local/etc/mysql5/my.cnf:

    [mysqld_safe]
    socket = /tmp/mysql.sock
    [mysqld]
    socket = /tmp/mysql.sock
                
    I also had to create the run directory:
    sudo mkdir -p /opt/local/var/run/mysql5
                
    Now I was able to start the system, but everything complained about the socket file location. I fixed that in my aliases in .bash_profile:
    # evil mysql is required for local wordpress
    alias mysql5='mysql5 --socket=/tmp/mysql.sock'
    alias mysqladmin5='mysqladmin5 --socket=/tmp/mysql.sock'
    alias mysqlstart='sudo /opt/local/bin/mysqld_safe5 &'
    alias mysqlstop='/opt/local/bin/mysqladmin5 -u root -p shutdown \
    --socket=/tmp/mysql.sock'
                
    Backgrounding your startup command with & is a Very Bad Practice but it seems like that's what mysqld wants; I may be using the wrong command altogether. Also note that you will almost certainly have to set that socket location explicitly in other commands/configs as well. Once you have the above aliases in effect don't forget to set your MySQL "root" password (not to be confused with the system root password). Press RETURN at the Password prompt, or enter whatever the previous password was.
    mysqladmin5 -u root -p password MYSECRETPW                
                

    At this point I'm able to connect to the database server with mysql5 and issue some simple commands, so I consider it done-ish after about two hours of work. Further tweaks will be listed below.

  3. Pour another glass of tasty Basque wine; do not give up yet!

    This little exercise is already confirming my various prejudices against MySQL and PHP and all sloppy engineering everywhere in the universe. But man, I do love that editing UI. Must... persist! Thank you Xarmant Txakolina!

  4. Install PHP from source. Ouch.

    I'd actually gotten far enough to have the PHP running, more or less, though without valid HTTP headers and without a successful database connection. And then I hit the php-cgi wall. Turns out you have to install from source, the standard install doesn't work properly with lighttpd.

    Fortunately Simplistic Complexity had a helpful blog post.

    Unfortunately that doesn't work with MySQL installed via MacPorts.

    I tried a few of the obvious tweaks to the make process and realized I would have to reinstall MySQL. And that's where I hit the wall.

Hitting the Wall

Having spent most of the day on this and gotten very close, I had to ask myself: Is it worth it to push on through?

Since I make software for a living I'm always tempted to put on my Big Fat Engineer's Hat and complain about the quality gaps in whatever piece of software I'm pounding my head against at the moment. But that wouldn't be even close to fair in the WordPress case: here is a product I really like as long as I don't have to look under the hood; and its content-management UI is frankly more usable than any equivalent thing I've ever built, and even if it is finicky on the server side I think the proof of its value is in the client experience.

I love WordPress for its content-management UI, and there's no special reason why its installation prerequisites or developer documentation should be tailored to my needs. If I cared that much I could contribute to the project, or fork it, or write my own.

So in the interest of fairness to a justly popular blogging system, and also in the interest of my own sanity, I gave up on my little snowflake of a local WordPress installation.

Instead, I'll try it their way and see if I can make some headway with the templates. A lot of generous people have given a lot of their time to this open-source product, and I still hold onto the hope that I can more easily beef up my WordPress templates than use (or write) a different blogging system.

To be continued (perhaps virtually).

I think the most sensible thing to do now is install a VMWare image with a recent version of WordPress. It looks like rPath has one.

That has the advantage of still being more or less "local" even if a bit resource-intensive; and if it doesn't work, it's always possible to just set up a sandbox WordPress account with an obfuscated URL.

I'll be sure to update the blog with the results of that operation when I have time for it.

Wednesday, November 26, 2008

Heavy web dev: TechCrunch is a 2MB page.

One of the blogs I read all the time is TechCrunch: it covers the high-tech startup scene.

http://www.techcrunch.com/

You could argue that it's more than a blog since it's a full-fledged business with multiple partner sites and paid writers, but I still think of it as a blog because if its focus on immediacy. Everything is reported fast and off-the-cuff, with even the more ponderous, essay-like posts obviously written in haste.

As I was looking at it today I started wondering how big, in terms of data size and bandwidth, a site like that is. The answer: almost two megabytes for the home page.

Folks, that is a lot. Yahoo's front page, which also takes a long time to load and is also full of Flash adverts, clocks in at 445K today. The chart view on Google Finance, which has light ads but very heavy (and feature-rich) Flash, is 680K.

I'm not trying to pick on TechCrunch here: the fact is that the acceptable size of any web page has grown phenomenally in the last year or so. As an iPhone user and a Web developer I find the trend worrisome.

Of course you want to make the page as rich as possible for the user, and of course you want to maximize your ad revenue. But you have to balance that against a fundamental aspect of usability: if the page takes too long to load, or puts too great a burden on low-power devices, you are leaving a lot of potential users out in the cold.

For my part, I plan to take page size and load time very seriously in my next Web project. I doubt I'll be able to hit my Web 1.0 gold standard of 15K per page, since a decent JavaScript toolkit and a bit of Google Analytics already breaks the 100K barrier, but it's still an important consideration.

(As for TechCrunch specifically, they're very good about publishing a full RSS feed. I read that on my phone most of the time, and read the site a bit during the day since there are often embedded videos and links to other heavyweight sites that aren't as usable on a mobile device.)