inessential by Brent Simmons

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.

On Public Bug Trackers

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.

NetNewsWire Privacy Policy

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.

NetNewsWire Diary #3: The Crash Reporter

The consensus choice for crash reporters is PLCrashReporter. It’s solid work.

So I went to add it to NetNewsWire, and here’s what happened:

Because of Apple’s new app notarization service, I needed to have PLCrashReporter get built along with the rest of the app — this way I could turn on the required “hardened runtime” setting. (Correct me if I’m wrong about this! Update next day: I am wrong. See postscript.)

But when I tried to build it there were a bunch of deprecation warnings (OSSpinLock, for instance) — and, since I treat all warnings as errors, it wouldn’t build. (I could turn that off, but I won’t.)

So I forked PLCrashReporter with the idea of fixing those errors myself, but then ran into territory I’m not familiar with and not confident about, so I stopped and deleted my fork.

So…

I thought some more about it, and did some research, and I learned that crash logs are still written to disk. This means I could use the crash log catcher I used to use in NetNewsWire 3 and NetNewsWire Lite 4.

The way it works: at launch time it looks for a crash log in the appropriate folder, and if the most recent crash log has not been seen before, then it prompts the user to send it it in. (A window appears with the text of the crash log, a place to add more info, and some buttons — send or don’t-send.)

This isn’t as slick as an in-process crash catcher — but this system worked for me for years. And it means one less dependency, and it means code I fully understand and control.

It’s a few dozen lines of code compared to adding an entire framework. So that’s what I’m doing.

The code

The code isn’t complete yet, but here’s the start. (And here’s the code from NetNewsWire Lite 4.)

I think this is the first time that I’ve looked back to old NetNewsWire code. I’m rewriting it in Swift, but using the same logic.

Important note: this code will not be part of the Mac App Store build. For that build, for better or worse, I’ll rely on Apple collecting and reporting crash logs. This crash reporter is just for the non-MAS build.

PS The crash catcher that appeared in earlier versions of NetNewsWire itself had a crashing bug (briefly): it would crash if there were no crash logs found! Which was self-healing — because once there was a crash log it wouldn’t crash any more. This remains my favorite bug ever. :)

PPS Shoutout to Uli Kusterer — my code was originally based on his UKCrashReporter.

PPPS The next day… I was wrong about needing to build PLCrashReporter in order to use the hardened runtime. On the Apple dev forums, Quinn writes:

The hardened runtime is an attribute of the process. It’s not something that frameworks can opt it to or out of individually.

So… I could just add a pre-built PLCrashReporter binary. But I’m going to stick with my thing anyway, again because it means one less dependency, and it means simpler, smaller code that I understand and control.

(The only remaining dependency like this is for Sparkle. I don’t see any reasonable way of removing that.)

Prison

I’ve said before that my fondest hope is that all these people go to prison, and that they come to regard Trump’s decision to run for president as the worst thing that ever happened to them.

It’s not schadenfreude — well, it’s not just that — it’s about justice.

It should be known by all, by everyone everywhere, that long-time criminals and fraudsters who feed hate, who betray their nation, will get what they deserve. They’ll get years behind bars and their liberties taken away. They’ll suffer the condemnation of history, and they’ll be known forever as dirt.

It should be known by their supporters — whose support is based on a mutual love of cruelty — that these kinds of people are buffoons who do not have their best interests at heart. The only interest they serve is their own corrupt self-interest. These kinds of people are not worth supporting.

Some are already in prison or heading there. I hope there are many more, and that this goes all the way to the top.

New Xcoders Site

The Xcoders group is for Seattle-area and Vancouver, BC folks who make apps — by writing code, testing, supporting, designing, and so on. They even let marketers like me in there. :)

I’ve been attending since 2005, but only recently started helping out more formally — I’ve been part of the effort to get our communications working a bit better.

We started a new blog at https://xcoders.org/. It’s hosted by Micro.blog, and we want to thank Manton Reece and Jean MacDonald for all their great work on the service.

We gave our blog its own domain name, xcoders.org — because that’s how you own your own content on the web. We also set it up to automatically cross-post to Twitter, to our existing @xcoders account.

We’ve still got some work to do with design (and maybe a public calendar?), but we’ve got the standard links up there for downloads, videos, Slack signup, and our code of conduct.

If you use an RSS reader, you can follow it there instead of (or in addition to) Micro.blog or Twitter:

Next meeting

As the site says, there are no talks at the next meeting — we’re going straight to the Cyclops in Belltown (which is just a few blocks from the standard meeting place). Be there!

Special note to people who don’t write code: you’re totally welcome! You’re encouraged to come, in fact, to this meeting and every meeting. It’s a great group of people and we’d like to meet you. :)

Almost all the cats and dogs alive during 9/11 are gone now. I hope we remember the comfort they brought. I remember my kitten.

On Using Stock User Interface Elements on the Mac

The genius of the Mac is its consistency. Users brand-new to any well-done Mac app are able to understand how to use it pretty quickly, in part because they see familiar buttons, popup menus, sidebars, toolbars, and so on that they see everywhere.

While it’s tempting to put your own stamp on things — as you kind of need to on iOS — on the Mac you can relax and use what Apple has provided.

Not least because Apple has already done a better job than you will. Apple’s controls support various accessibility features, and they behave the way Mac users expect. Both of those things are very easy to get wrong, and when you do it wrong the app feels wrong, and people notice.

Mac users love the Mac because of the user interface, not despite it. Remember this.

Another thing worth considering: it’s cheaper. Writing your own custom UI — and maintaining it across macOS releases — takes resources. The more you use Apple’s controls, unmodified (or minimally modified), the easier time you’ll have when the Mac gets new features and behavior updates.

I’m not saying you should avoid beauty and delight. You want your app to be gorgeous; you want your app to make its users happy. Totally! I’m saying that you should design within the constraints of building a good Mac app. And that working within those constraints makes it more likely, not less, that you’ll reach that goal.

Cheri Baker, Eight months without Facebook:

When we allow sites like Facebook to do the heavy lifting in our relationships, it seems that we turn into cardboard cutouts, even when hanging out in person. I always hated that dynamic, and now it’s over.

So Basic It’s Not Even Funny

Laura K. Curtis writes about book bloggers and lists a whole bunch you might want to subscribe to:

There are fewer book bloggers around now than when I started, but I’d like to encourage people to visit them, especially since you are more apt to find less well-known books by looking at blogs, books you might really enjoy, but might otherwise never find.

“Who has time to cruise all these sites?!” I hear you cry.

“No one,” I answer. “That’s why there are feed readers.”

What delighted me especially was this line: “It’s NetNewsWire for Mac and it’s so basic it’s not even funny.”

And I — earnestly — love this, since it describes my design and development aesthetic so perfectly. So basic it’s not even funny. I might even ask her if I can quote her on the NetNewsWire website. (Update: I did ask.)

* * *

I’ve always been a minimalist, but when I was younger I’d temper that — sometimes extremely (remember the releases of Glassboard with a wood grain background) — because I was afraid my intended audience wouldn’t like it. I was afraid I was too extreme.

I don’t know what the difference is now, but I am completely unafraid to be the designer and coder I am. Or, as a bit of advice I got early in my career put it: be the freak you are.

Maybe just because I’m older? Maybe tastes in general have shifted that way a little? Dunno. But I’m sure glad I got here.

So basic it’s not even funny!

* * *

Yes, I’m aware of the modern use of basic to mean something rather judgmental. I plainly don’t give a fig. (And I don’t think Laura meant it that way.)

I’m on the latest Micro Monday podcast with Jean MacDonald! It was so much fun to do.

We talk about podcasting and about the similar ideas behind The Omni Show and Micro Monday. And The Record.

We also talk about NetNewsWire and about Micro.blog.

Entirely coincidentally — Micro.blog has been open to the public for a year now. Congratulations to Manton and Jean on this big milestone!

Crash Catcher for NetNewsWire?

An actual conversation:

Brent Simmons [9:40 PM]
Crash catching What are people doing for this? NetNewsWire needs something, I suppose.

Wise, Super Old Developer [9:42 PM]
Just don’t ship crashing bugs.
Duh.

Brent Simmons [9:42 PM]
Well, I don’t, but the system will enforce some amount of crashing, and I want to be able to file Radars.

* * *

Well that’s me being a total jerk. It’s also a measure of my confidence (sure, let’s call it that) in my not shipping crashing bugs.

But it’s worth remembering — here in the real world, outside of a developer’s chatroom — that there are plenty of programmers who think they don’t shipping crashing bugs, but do.

And, despite my confidence, the responsible thing is to include some kind of crash catcher.

* * *

I want something lightweight. Ideally it just opens a new message in Mail with the recipient, subject, and body set. (I could write that UI part myself, if needed.)

It has to be open source, since I’m not going to include any mysterious binaries in an open source app.

What should I do? Is PLCrashReporter the best bet? Or…?

Archive