What is a JSON feed? Learn more

JSON Feed Viewer

Browse through the showcased feeds, or enter a feed URL below.

Now supporting RSS and Atom feeds thanks to Andrew Chilton's feed2json.org service



Brent Simmons’s weblog.

A feed by Brent Simmons


Permalink - Posted on 2019-02-20 19:04

In the latest episode of The Omni Show, I am the guest. How does this even work? Do I interview myself? What’s going on here?

PS I like being on podcasts, and I’d be happy to be on yours, to talk about Omni stuff or my own stuff or both. I could probably even convince Ken Case to be a guest on your show if you want to talk about Omni apps and developing for Mac and iOS in 2019.

(My email address is no secret, and every spammer everywhere already has it, so I’ll just post it here: it’s brent@ranchero.com.)

NetNewsWire Status: February 19, 2019

Permalink - Posted on 2019-02-19 21:35

There are three big things that remain before the first feature-complete build (which will be 5.0a1): searching, the app icon, and syncing with FeedBin.

Brad Ellis is working on the app icon, so that leaves searching and syncing (and a few miscellaneous bugs) for me.

I’ve been working on searching — I want to get that done next, and then do syncing as the last thing before hitting alpha 1.

How search is implemented

The UI for searching is pretty straightforward: you type into the search field, and then the timeline shows your search results. Click on an article to show it in the detail web view. Exactly as expected.

But there are two ways I can think of to implement this UI.

  1. When a search starts, do the search and show the results in the timeline. When the user ends searching, restore the previous timeline and detail view states.
  2. When a search starts, swap in a separate timeline and detail view, do the search, and then show the results in these swapped-in views. When the user ends searching, swap those views out, and swap back in the regular timeline and detail views.

Ideally the user can’t tell the difference between the two methods. But if you go with solution #1 — use the existing timeline and detail views — then you have the challenge of restoring state, including selection and scroll positions, when searching ends.

If you use solution #2 — swapping views in and out — then you don’t have that challenge. State is restored exactly as it was, because you saved the non-search views and swapped them back in.

(If you look at other apps — Mail, for example — it appears they use solution #1, and state restoration is not always instant. I want it to be instant.)

So, for the past week, I’ve been re-jiggering so that I can have multiple timeline and detail views and swap them in and out.

(This is not that different from how searching in iOS apps is supposed to work.)

And then, last night, as I finished the re-jiggering, I did the actual search-in-the-database implementation, which took about an hour.

This still leaves me to handle changes to the search field, so that the search is actually run at the right time, and so that searching ends properly. I expect that to take a few hours to get all right. (I’ve done this before, and it’s always slightly more complex than it seems.)

Why do I make this point?

If you’re not a programmer — or you’re new to programming, or haven’t written apps with a user interface — it’s easy to think that the actual under-the-hood implementation of a feature is what takes the most time.

It’s not. In the case of the search feature, I spent more time just thinking about how I want to do the UI than on the actual search-in-the-database implementation. And then there’s the UI work itself, which absolutely dwarfs the database work.

Another case: you might imagine that the bulk of the work in NetNewsWire was writing an RSS parser, for instance. But no. While that code is critical, obviously, it’s very, very small compared to the user interface.

And, similarly, the part of syncing that’s just making API calls and updating the database will be the easy part. The part that takes longest will be user interface. A factor of ten would not be surprising.

Permalink - Posted on 2019-02-14 01:14

Jonathan T explains how to activate Apple ID 2fa when you have two accounts.

Short version: temp user on your Mac, SMS as backup, delete temp user, SMS keeps working.

Two-Factor Authentication and Developer Accounts

Permalink - Posted on 2019-02-13 22:45

I just got an email from Apple that two-factor authentication will be required for my Apple Developer account.

I have two accounts — one for personal use, one for development use — and so do lots of developers.

I don’t know how to make this work. None of my devices are ever signed in to my developer account. That account exists purely for building and distributing apps.

Permalink - Posted on 2019-02-13 19:21

Brett Terpstra writes about blogging, ethics, and thin skin.

I’ve been reading Brett’s blog for years — I trust him, and he’s a good writer. I also use his app Marked pretty much every day.

Permalink - Posted on 2019-02-13 18:28

Daniel Jalkut has bad news for Blogger users — Google is shutting down an images API.

Colin Devroe reminds us not to rely on mega-corporations keeping our beloved services alive. They won’t.

Permalink - Posted on 2019-02-12 22:14

There’s still snow everywhere — but the sun just came out, and I heard some birdsong, and I looked outside and saw a couple robins.

Permalink - Posted on 2019-02-11 18:07

Cliff Mass, Seattle’s favorite weather blogger, writes that the end of all this snow mess is in sight.

Permalink - Posted on 2019-02-08 18:39

Cheri Baker writes about Spotify in Dear Podcasters…:

I fear we’ve seen this scenario before. A biggish company decides that they’ll aggregate an immense amount of creative work and monetize it. They’ll offer you tools to make “sharing” easy, and at first the terms of service will be reasonable. But once they’ve eaten a big enough chunk of content, they’ll lock the gates tighter, change the terms of service, and monetize the audience. By that point, customers would feel locked into Spotify, and podcasters would be afraid to leave.

NetNewsWire Roadmap 2019

Permalink - Posted on 2019-02-07 02:05

Let’s look back at last year first.

2018: Evergreen to NetNewsWire

As 2018 started, the app was called Evergreen, which I still think is a pretty great name for an RSS reader. I’d been working on it for about four years, on weekends and at nights.

It was usable-by-me a year ago, and a few other people were using it, even though it was missing all kinds of important features.

And then, some time in the spring of 2018, I thought to contact the folks at Black Pixel about getting NetNewsWire back. Seemed like a total longshot. But why not try?

And they surprised me by being interested! In fact, they mentioned that they’d already been talking about it.

I was clear that I wanted just the name — not the code, not the then-current users, not the sync service. The app named Evergreen would be renamed as NetNewsWire, but would be, in every other way, the same app I was going to write. It would still be free and open source.

They agreed. And then, of course, discussions, mostly internal to Black Pixel, happened for a few months, because that’s how these things go — and we managed to make it official on August 31, 2018. (See NetNewsWire Comes Home.) Black Pixel gave it to me for free (we never haggled over price; that was their plan all along), and their generosity remains one of the things I’m most thankful for in my entire career.

Soon after that I renamed Evergreen to NetNewsWire — and memorialized the name Evergreen in the app’s bundle id: com.ranchero.NetNewsWire-Evergreen. (NetNewsWire will always be Evergreen.)

And so it turned out that I had been working on NetNewsWire 5.0 for four years already! I just didn’t know it for most of that time. :)

The rest of the year saw more work on the app, with code contributions from Maurice Parker, Olof Hellman, and Daniel Jalkut, with bug reports on GitHub, with the help of the folks on the NetNewsWire Slack group. (Which you can join too: just email me.)

That was 2018.

2019: Let’s Ship This Thing

At this writing we’re down to seven bugs in the 5.0 Alpha milestone. There are three main things: syncing with Feedbin, searching, and the app icon.

I want to ship 5.0 by WWDC, which is (most likely) the first full week of June. So here’s what I’m planning:

  • Finish those last bugs, and ship 5.0a1.
  • During the alpha period: write the Help book and document at least some of the code. Test, most importantly. Fix any bugs that get reported. Once there are no known defects, after a suitable period of testing, then ship 5.0b1.
  • During the beta period, continue testing. The code will be touched only with great reluctance. (Every beta is a shipping candidate.) Continue documenting the code.
  • Once there are no known defects, ship 5.0.

As you can see, the 5.0 Alpha milestone represents five years of work, and the alpha and beta periods ought to be relatively short, possibly just a couple weeks each.

But how quickly we get to alpha is mainly a function of how quickly I can get Feedbin syncing working and bug-free.

I think I can get it done by WWDC, but I could be wrong! No promises, of course. For NetNewsWire, app quality is everything, and hitting a date means very little.

Beyond 5.0: More Sync

There’s every chance that WWDC will bring changes and new technology from Apple that I’ll have to deal with. That’s expected — every app developer (hopefully) budgets for this. Assuming 5.0 is out before WWDC, then I can deal with this stuff in an update in the summer, in time for the next macOS.

There’s a huge list of features I could work on after that — there’s so much room for growth — but I think the big one has to be adding support for more syncing systems. I’m likely to do Feedly next, since it appears to the the most popular.

So my hope is to get Feedly support shipping by the end of 2019. And, if I do, then it will have been a very good year.

Permalink - Posted on 2019-02-06 19:21

National Weather Service Seattle lets us know what’s coming up. More snow!

Thursday is the Last Dry Day.

Permalink - Posted on 2019-02-06 18:58

Michael Zornek writes (and this is the entirety of his post):

It is not a podcast unless there is a RSS feed.


Permalink - Posted on 2019-02-05 21:54

I love it when companies or products publish a roadmap. Omni publishes one every year — here’s the latest.

Today I ran across the Fiery Feeds Roadmap 2019. I’ve heard of Fiery Feeds, but I haven’t checked it out yet. Now I will, because the developer Lukas Burgstaller is a blogger and I enjoyed reading the roadmap.

Now, of course, I have to consider writing a NetNewsWire roadmap for 2019. The big thing on the list would be shipping 5.0. (I’ve been working on the app for five years! Time to ship.)

Permalink - Posted on 2019-01-31 23:45

There should be a Roger Stone emoji.

Permalink - Posted on 2019-01-31 23:34

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!

Permalink - Posted on 2019-01-30 18:40

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


Permalink - Posted on 2019-01-28 18:36

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

TigerLaunch app icon

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.

Permalink - Posted on 2019-01-27 23:12

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.

Permalink - Posted on 2019-01-27 20:35

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.

Permalink - Posted on 2019-01-27 19:59

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.

Permalink - Posted on 2019-01-27 19:39

Passwords and Muscle Memory

Permalink - Posted on 2019-01-24 21:16

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!

Mark All as Read

Permalink - Posted on 2019-01-22 22:00

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.

Permalink - Posted on 2019-01-22 20:01

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.

Permalink - Posted on 2019-01-22 19:41

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

Xcoders Blog Renovation Phase Two

Permalink - Posted on 2019-01-18 17:55

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.

Permalink - Posted on 2019-01-17 22:38

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

I think so too.

Permalink - Posted on 2019-01-17 00:41

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.

Permalink - Posted on 2019-01-16 23:15

Permalink - Posted on 2019-01-16 22:50

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

On Public Bug Trackers

Permalink - Posted on 2019-01-15 21:41

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

Permalink - Posted on 2019-01-14 19:08

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.