Square to Lose Money Faster Than Ever
A few days ago, Square announced a partnership with Starbucks.
As a longtime fan of Square, my first thought was “hooray for them!” But then I remembered that they lose money on every transaction. This deal is only going to accelerate the process.
I want Square to achieve its goals, but I keep getting that Underpants Gnomes vibe: relentlessly pursue your goals, then figure out that whole “income” thing. Of course, Silicon Valley startups have known for years that Step 2 is “get acquired.” It worked for Instagram to the tune of a billion dollars.
I just hope Square figures out its plan in time. Also, that it isn’t a terrible plan.
An Undesirable Form of Tethering
I’m trying to get into the habit of posting regularly. It’s a good habit to get into, if I’m to avoid having this site fall dormant again.
There is a problem, though. With my current setup, I have to be at my laptop to write and publish a post. The result of this friction is that by the time I can sit down to write something, I often forget what it was I wanted to say.
This problem seems rather quaint, seeing as I always have an iPhone handy, and often have an iPad nearby. I have to believe there are already apps out there that solve this particular problem in a way that works with my setup (Diet Coda seems to be a good candidate). But secretly, I hope there isn’t, because that would give me something to attempt for myself.
All the various pieces are cobbled together on my MacBook Pro. I just need to work out some way to get them onto iOS.
Mulligan
It’s been far too long since I updated this blog.
This site was previously a Tumblr, and I had my personal domain point there. Over the last several months, I’ve taken a minute here, a minute there to redo everything. This is now a static site hosted on Amazon S3. The content is currently being produced with Jekyll. I know the look of the site leaves much to be desired, and I could fiddle with it, tweak bits of it for the next month or more. Or I could write an actual post.
So, here we are.
This is my personal site. It will have all manner of content, so if you find one post is boring, perhaps the next one will be to your liking. As I am a developer, I will often write about technical things.
I have a business site, but it’s not worth linking to at this time. Perhaps later.
Real Backups
Like most people, I tend to do a poor job of backing up my data. I’ve been bitten by the consequences of my carelessness before, and am finally doing something about it, albeit a bit too late.
In August of 2003, my PC’s hard drive crashed, taking everything with it. I had a single 3.5” floppy with my most important files backed up on it, which had last been updated the preceding December.
You would think that I learned a lesson, that as a professional in the field, I would know better, but habit is a powerful drug. The lack of a proper backup solution nagged at me, but that was all.
At least with the appearance of Time Machine in Mac OS X Leopard, I was able to do a little something. If nothing else, I made sure I always had a spare external drive for this purpose.
My instinct is to point you to John Gruber’s An Ode to DiskWarrior, SuperDuper, and Dropbox, or Merlin Mann’s Yes. Another Backup Lecture. and leave it at that. And why not? They cover the topic better and more thoroughly than I could, and those were the articles that stuck in my mind throughout 2010.
I get paid biweekly, and last month was one of those times when I got three paychecks instead of two (in fact, last year was one of those rare years when my coworkers and I got twenty-seven paychecks instead of twenty-six). I decided to quit stalling and purchase the hardware needed to do “real backups,” as defined by Merlin Mann.
I have a 2005 Mac mini (PowerPC) that I use as a home media server, a 2007 iMac, and that rare breed of aluminum MacBook that only existed for eight months, before Apple decided that aluminum meant “Pro.”
The Mac mini has a 1TB external hard drive attached to it with all my digital media, so that means four hard drives that need to be backed up. Because anything worth doing is worth overdoing, I purchased a docking station, ten 1TB internal hard drives, and a set of cases to store them in.
Last night, Thursday, everything was finally delivered, so I got to work. The initial backup of my laptop took four hours. With only one docking station, the first round of backups is going to take a very long time. Tonight, I opted to backup my external drive of media files. I was out of ports, so I had to root around for an old USB hub. Finally, at about 8:00 p.m., everything was hooked up and I started copying my digital media.
Naturally, that drive failed about sixty seconds later.
Allegedly, my Time Capsule has a backup only a few hours old. I’m attempting to make a copy of that backup as I type, but the process will take until morning.
May I suggest you look into doing some real backups of your own?
CodeMash Scheduler 1.1 Available
Download it from the App Store, if you plan to attend the conference.
CodeMash + Core Data
It took a lot longer than I anticipated, but I replaced the poorly-designed SQLite database of the CodeMash Scheduler with a Core Data store.
I’m new to Core Data, so there was a learning curve involved (I highly recommend Core Data: Apple’s API for Persisting Data on Mac OS X). In addition, I insisted to myself that the app remain fully functional after every commit. That led to a long period where the app’s data was split between two data stores, which slowed me down.
Finally, I insisted on writing a migration step into the app. Because I never uninstalled the app from my iPhone after January’s conference, I discovered that the 1.0 version still (mostly) works. You can “favorite” some talks, and it records that fact in a SQLite table. It’s possible (though highly unlikely) that someone will mark some talks in this way, then upgrade to the next version of the app. I wanted to make sure they didn’t have to mark those talks again. It’s the little things that make an app useful.
That’s the big news. There are also a few minor changes that are worth noting:
- support for fast task switching, like any decent iOS 4 app;
- dynamically generate some lists that were previously hardcoded;
- replacement of the annoying full screen “loading” message with the subtler status bar network activity indicator; and
- a pre-populated Core Data store.
That last one deserves a brief explanation.
On startup in 1.0, we downloaded the contents of the CodeMash REST feeds and replaced the database contents (if any) with the results. This meant that, unless you had network connectivity, the app was unusable. CodeMash’s venue this January was in an area with terrible cell phone reception. Their wifi was also overtaxed by the presence of so many technical geeks, so the app was either useless, or people were repeatedly confronted with error messages about being unable to download data.
Because I don’t trust AT&T nor the Kalahari Waterpark Resort to beef up their offerings in time, CodeMash Scheduler will now come with a pre-populated Core Data store for improved offline use.
On a personal note, I am thoroughly enjoying Core Data. I know I’ve only just scratched the surface, but I can already see a lot of ways I can use it.
CodeMash iPhone App Rewrite
Late last year, my employer asked me to finish an iPhone app that had been started by another employee. He was pulled away on a paying gig, and didn’t have time.
I finished it, but I’m not thrilled with how it turned out. It’s a pretty basic scheduling app for CodeMash, a technical conference in northern Ohio. There was another app that did more or less the same thing, and while it had a bunch of features ours didn’t, ours wasn’t prone to random crashes. (We had plenty of bugs, but none were show-stoppers, in my opinion.)
I’ve decided to revisit the codebase to see if I can spruce it up a little for next year’s CodeMash, which is a little over a month away. Looking over the code, it’s amazing how obviously rushed it was. I think both of us were still pretty new to mobile development (and Objective-C), and with the app store’s notorious delays in approving apps, we were desperate to reach something approximating “done.”
Of course, that means I’m short on time this year, too. Hopefully, things will go better this time.
I’ll post updates with any interesting milestones I reach.
Apple No Longer Taking Responsibility for Others’ Crap Code
I can’t help but notice a theme in a couple of Apple’s recent communiqués.
A few weeks ago, John Gruber talked to an Apple spokesman about their decision to stop bundling Flash with Macs. He was told:
“We’re happy to continue to support Flash on the Mac, and the best way for users to always have the most up to date and secure version is to download it directly from Adobe.”
Today, Apple and Oracle announced a plan to deal with Apple’s decision to deprecate its port of Java. It reads, in part:
“We’re delighted to be working with Oracle to insure that there continues to be a great version of Java on the Mac,” said Bertrand Serlet, Apple’s senior vice president of Software Engineering. “The best way for our users to always have the most up to date and secure version of Java will be to get it directly from Oracle.”
Bundling third-party software with a new computer arguably makes a computer more valuable right out of the box. But it can also be a pain for Apple (and, presumably, its PC counterparts), because when something goes wrong (bugs, security problems, whatever), people look go to whoever gave them that software for a fix.
So previously, if there was a problem with Flash (and there have been plenty), people expected Apple to fix it, even though it wasn’t their software. Now, those problems are officially Adobe’s (and Oracle’s) problem.
I can’t help but be reminded of the (former?) motto of Microsoft’s Excel team: “Find the dependencies — and eliminate them.”
Mail • Send Flagged Mail to Things
Because I’m a fan of Inbox Zero, and I hate checking two places for my list of things to do, I cobbled together some AppleScript that will turn the flagged mail in my inbox into To Do items in Things. Here it is, if you’re interested.
I can’t take much credit. It’s really just a hack based on John Gruber’s script for flagging iPhone mail. It cycles through the IMAP accounts in Mail, and for each flagged message it finds in the Inbox, it creates a new To Do in Things’ Inbox with the name set to the subject line of the message. Additionally, it adds the message as an attachment, then archives it.
tell application "Mail"
repeat with _acct in imap accounts
if (_acct is enabled) then
set _acct_name to name of _acct
set _inbox to _acct's mailbox "INBOX"
try
set _archive_box to _acct's mailbox "Archive"
on error
-- Archive doesn't exist; maybe this is Gmail?
try
set _archive_box to _acct's mailbox "[Gmail]/All Mail"
on error
display alert "No “Archive” mailbox found for account “" ¬
& _acct_name & "”."
return -- Stop the script
end try
end try
set _msg_list to (every message of _inbox whose flagged status is ¬
true and read status is true)
if (_msg_list's length > 0) then
repeat with _msg in _msg_list
set _msg_subj to subject of _msg
set _msg_id to message id of _msg
set _msg_url to "[url=message:%3C" & _msg_id & "%3E]" ¬
& _msg_subj & "[/url]"
try
tell application "Things"
make new to do with properties ¬
{name:_msg_subj, notes:_msg_url}
end tell
move _msg to _archive_box
on error
display alert "Could not create To Do for message “" ¬
& _msg_subj & "”."
return -- Stop the script
end try
end repeat
end if
end if
end repeat
end tell
Of course, the best way to use this is to create a Snow Leopard service. Speaking of which: I guess the URL format for messages changed in Snow Leopard, so this script won’t work as-is in Leopard.
Crept out the back door
White evangelical Protestants have been stable as a proportion of the population for decades. […]
And that’s interesting, because the biggest defining characteristic of this subculture […] is that it is evangelistic.