January 2019

There should be a Roger Stone emoji.

Seattle Xcoders special fifth Thursday unofficial meeting is tonight at 6:30 pm at the Waterwheel in Ballard.

Note: not Cyclops. Waterwheel.

And it’s not really a meeting. We just hang out. Join us!

Craig Hockenberry wrote up a simple WebKit feature request: Add limits to the amount of JavaScript that can be loaded by a website.

In 2002 I wrote TigerLaunch, a little app-launcher app, and released it for free.

In 2019 it still runs — and has 4.5 stars on MacUpdate and a number of comments over the years.

I’d pretty much forgotten about it, until recently when I started getting email from people asking me to make it 64-bit so it will continue to run on future OSes.

* * *

The idea behind TigerLaunch was to make the simplest app-launcher I could make. It adds a menu to your menubar. The menu is a list of apps on your machine, sorted alphabetically. There was a settings screen where you could exclude apps that you never launch.

Here’s the oldest version of the TigerLaunch page that archive.org has.

* * *

I’m considering doing an update. It doesn’t have many users — but the app is 17 years old and it’s still in use. Seems like it would be a shame if it stopped.

It’s such a simple app. I’d just rewrite it from scratch in Swift, probably. Make it open source. The hard part is that it would need a new app icon.

Update a couple days later, because people keep asking: It would need a new app icon because Mac apps these days need larger sizes for app icons than was required in 2002, and I don’t have larger sizes of the icon.

The best book I’ve ever read on programming and making apps is Six Memos for the Next Millennium by Italo Calvino.

It’s about literature, not programming. But it applies, and I highly recommend it to people who make apps.

In 2015 I wrote a series of articles on How Not To Crash. My favorite part is at the end of the last article, the “Cape, mask” section.

It begins:

When I was younger I wanted to be a code magician — or, really, a hero. But I learned that actual software quality is more important than what I imagine other people think of me.

And, more: quality is a reward that’s almost spiritual. It’s an act of devotion, both selfish and unselfish, to something more important than ego.

The latest version of NetNewsWire includes a crash log reporter. On each launch, it looks for the latest crash log. If it finds one, and it hasn’t been sent in yet, it prompts the user to send it in.

(The user may choose not to. The user may also choose just to send crash logs automatically in the future.)

At the moment, NetNewsWire has no known crashing bugs. This may change as people update!

I might start getting crash logs. And I might not. Either way is interesting.

PS At the moment I have 12 bugs to go before 5.0a1 ships.

NetNewsWire 5.0d8 has been released. Check for updates!

Yesterday I was unable to login to one of my (personal, not work) computers because I had forgotten my password.

It’s the same password I use on all my personal machines, and I think it’s been my password since the earliest Mac OS X public betas. (Possibly not wise, sure, but at least I never used it anywhere else.)

I was at work when this happened (where I have a personal computer mainly for playing music and podcasts). I figured that maybe my muscle memory would kick in once I got home and back to my normal context. (It did. Whew!)

But that still meant a few hours where I wasn’t sure if I’d be able to login to my personal computers. Which is definitely a scary thing. Even though important things are backed up elsewhere (NetNewsWire’s code is on GitHub, for instance), it’s still scary.

* * *

Why bring this up? It’s because this situation snuck up on me, and it could sneak up on you too.

What I realized is that — probably for many years — I didn’t actually know my password. I couldn’t have told you what it is. I just relied on my fingers to know it. And since it always worked, I never thought to question it.

And then, one day at random, my fingers failed. And the more I tried to figure it out — trying things that seemed likely — the more I worried I was fuzzing my muscle memory.

(Luckily that wasn’t true.)

Once I did get logged in, I decided to take some important steps. I changed my password to a passphrase (it had been gibberish), and I’ve saved two copies elsewhere (securely but retrievably).

So here’s my advice: check to see if you actually know your password, because you just might not. And, even if you do, make sure you have a way to get back into your computer in case you forget it.

Don’t trust your fingers!

One of my favorite parts of the latest The Important Thing podcast is where Rands explains that, in his RSS reader, he just marks-all-as-read at will.

For the kinds of RSS readers that track read/unread status, this is the right approach. If something’s truly important, it will come to you another way. And there are so many other ways that important things will reach you than in, say, 2005.

I write an RSS reader and I do this myself. (I often read just what’s new today, and then mark everything older as read.)

It’s totally a-okay. Your RSS reader is not your task master.

One of the best reasons for getting rid of a bunch of the things you own is that you can then take better care of the things you keep.

Unofficial Seattle Xcoders — where we just eat, drink, and talk (no meeting) — is this Thursday.

I’ve started the next step in my plans for the Xcoders blog — I’m now posting links to:

• News about apps written by Xcoders,
• Interesting blog posts written by Xcoders,
• And news from elsewhere of interest to Xcoders.

In other words, it’s becoming a developer news blog with a Northwest point of view. And I think it will be worth following, even if you don’t attend Xcoders (or don’t even live in the Northwest).

If you’re on Micro.blog, you can follow Xcoders. And, of course, most importantly, it has an RSS feed and a JSON Feed so you can subscribe in your RSS reader.

Manton Reece writes, “I think 2019 is going to be a great year for blogging.”

I think so too.

Jean MacDonald writes a message to her friends at Facebook as she’s leaving the website:

The more time I spend on Micro.blog, the worse I feel about participating in other social networks: the creepy targeted advertising, the outrage, the endless lists of tips that imply something is wrong with me, all the notifications and suggestions that are intended to capture more of my time and attention for the benefit of the platform.

Coyotes in my neighborhood have started drinking.

Colin Devroe writes that RSS is not dead. Subscribing is alive.

For open source projects it makes sense to have a public bug tracker. It would be hard to do the work without it.

But for commercial software? It’s not a good idea at all.

(I bring this up because I saw someone suggest this idea recently, and it stuck in my head.)

Decisions about what to work on — and when, and by whom — are complicated. From the outside it might look like it’s as simple as picking the next feature request with the most votes, but it’s not that simple.

A company might prioritize a crashing bug over that bug.

Or that feature might need x, y, z and done first, all of which require major work — maybe it needs some surprising amount of design or under-the-hood work, or both, that the requestors understandably don’t know about. Or it needs a bunch of localizations. Or lots of extra testing because the implementation is complex or wide-ranging — or it’s in an area where it could cause regressions.

Or the person who best knows that area of the code is temporarily on another team to help with another company priority. Or that person is going on vacation.

Or there are features nobody has asked for specifically, but that the company thinks would be awesome, and those get priority.

Or there are a half-dozen features that are low-hanging fruit, and for various reasons it’s a good idea to do a bunch of easy things for a while.

Or the feature doesn’t even really fit with the app: companies make that call all the time. (I never added Usenet support to NetNewsWire, despite getting requests for it.)

Or the feature is actually impossible. Or impossible without spending two years and a few million dollars on research and development first.

Or there’s a new OS feature that should be supported. Or an incompatibility with a new OS to fix.

And so on — the list goes on.

But if you have a public bug tracker, you’d likely find that you’re having to explain your decisions all the time. You’d be constantly defending your plans to people who remind you that Feature X has all these votes, so why hasn’t it shipped yet?

I’d argue that most companies aren’t open and accessible enough. Many companies don’t listen to their users very well. Many don’t even write honest and respectful release notes.

But opening up the bug tracker to the public is just a way to get bogged down: it’s a way to make worse decisions, and make them more slowly.

I’ve been working on the NetNewsWire privacy policy, which I realized I needed as I was working on crash log collecting.

If you have questions, feedback, or suggestions, please let me know.

The gist is pretty simple: I really, really, really do not want anybody’s information. It’s not interesting or useful to me, and managing it is a burden I don’t want. Most importantly: I believe strongly in not just a decentralized web but a web where privacy is respected.

That said, I do have webserver logs (which, frankly, I complete ignore — I don’t even look at the stats, though that could change), and I collect crash logs when the user opts in, because making sure that the app doesn’t crash is job one.

* * *

My favorite line of the privacy policy:

Neither ranchero.com nor inessential.com use any cookies or JavaScript, and they do not display any ads.

I wish there were a clever marketing name for no-cookies/no-JavaScript sites. It should be a trend.

While the industry is focused on SSL everywhere, we’re not looking at the other half of surveillance tech.

I’ll actually be attending the Xcoders meeting tomorrow — not just the after-hours thing. I’m making an effort. It’s a new year. Why not?

What’s cool is a talk from Sean McNeil on ReactiveSwift. I’ve been personally skeptical about React-style frameworks on Mac and iOS, because experience, and the wisdom of others with experience, tells me that the further you get from Apple’s frameworks the less your app will feel like a native app.

The best advice has always been “Don’t fight the frameworks!”

But still — this is something I should learn about rather than just dismiss it. So I will.

* * *

Despite my skepticism about React for Mac and iOS apps, I have pretty strong feelings about things I think React folks would agree with: minimize state, for instance. Use immutable objects and structs. Don’t share memory across threads (queues). (NetNewsWire’s coding guidelines goes into more detail.)

The web will, eventually, make everyone a crime victim.