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

CURRENT FEED

inessential

Brent Simmons’s weblog.

A feed by Brent Simmons

JSON


Toolbars Without Button Titles

Permalink - Posted on 2019-05-23 20:23

Michael Tsai, in Mac Toolbar Labels and Accessibility, mentions that he considers showing buttons and button titles, at least as an option, preferable to icon-only.

Two things to know about this:

  • VoiceOver can still read the button titles
  • The buttons display tooltips on mouseover

In other words, it’s still possible to read the titles, and it’s still accessible in at least one important way. However, the titles are not as easily discoverable, and it’s difficult for people who have trouble picking out shapes or associating them with meanings.

Here’s the thing: title-less windows don’t give us the option of showing button titles. No window title, no button titles. I assume most developers would like to be able to offer the option of showing button titles — but they can’t if they also want to use a title-less window. (This is an AppKit thing.)

Title-less windows often make sense for non-document-based apps. Michael mentions MarsEdit, OmniFocus, and ReadKit — and he could have mentioned NetNewsWire too, which uses this style.

* * *

There’s a hugely important aspect to this: developers follow Apple’s lead when it comes to app design. I’m trying to find Apple apps that allow for buttons and titles, and all I’ve found so far is Mail and the iWork apps. (The iWork apps are document-based, which means their windows need titles.)

Some Apple apps with unlabeled buttons include Safari, Calendar, Dictionary, Font Book, iTunes, Xcode, Maps, News, Notes, System Preferences, and Photos.

This is how the platform rolls these days.

* * *

In fact, lots of Apple apps — and third-party apps — don’t even have configurable toolbars at all. This is a shame. At least with Safari — and the apps Michael mentions, and NetNewsWire — you can rearrange items to your liking, and choose the items you want to see.

Because toolbar customization is part of AppKit, it requires less code than writing your own fixed toolbar. And it’s an easy customization win for your users.

If your designer doesn’t like it, then tell them they need to understand Macs and Mac users better.

* * *

I’d bet that Mail in the next MacOS release will have unlabeled toolbar buttons.


Still Fearing the Reaper

Permalink - Posted on 2019-05-22 20:26

Steve Troughton-Smith writes a lovely article (Don’t Fear) The Reaper — but I still fear the reaper. I do.

Steve’s point is that the Mac has been through transitions before. A transition takes time, and we don’t necessarily know exactly how it will end up, but it ends up marvelously.

I completely agree about the past: Mac OS X was a thrilling fusion of the classic Mac experience and NEXTSTEP, with a whole bunch of new stuff added.

I loved it.

I started writing NetNewsWire, a Cocoa app, during the 10.1 days, even though I had been a classic Mac developer. I had no interest in Carbon — because Cocoa was an amazing framework, so far ahead of what we had on the Mac before.

With OS X we had the power and ease-of-use of the Mac — including Apple events — and we had Unix under the hood and a Terminal app. This brought so much power and freedom to the Mac.

It was incredible. It‘s still incredible.

So, knowing how this has worked out in the past, why do I fear the reaper?

Because bringing UIKit brings no new power. If anything, it subtracts power. UIKit apps — at least so far — are all sandboxed and available only via the App Store. They don’t offer everything AppKit offers.

And, to make things worse, it’s reasonable to be somewhat skeptical of Apple leadership’s understanding of the platform. Daring Fireball quotes a source at Apple as saying they had “taken their eye off the ball on Mac.”

Getting the Mac OS X transition right was a priority for the company: if it failed, the company would fail. But with this? Not the same story at all.

* * *

I will be delighted — and relieved, and singing hosannas — when it turns out I was wrong to fear the reaper. I hope so very badly that I’m wasting my time with my worries. I know what Apple is capable of — I just need to see it.


Permalink - Posted on 2019-05-21 20:18

New website: macopenweb.com is a single-page directory of “open and indie Mac, iOS, and web apps that help promote the open web.” It’s by my friend Brian Warren.

I love this. This is a page that would never appear as a category on the App Store — and yet it’s an important category.

And it’s a reminder that we can create things that don’t appear on Twitter, Facebook, or Medium. Putting up a website isn’t hard. And it’s fun! Plus you get to do it exactly how you want to do it.

The site has a repo on GitHub, where you can file bugs and feature requests or make pull requests.

Do yourself a favor and bookmark the site. :)


Permalink - Posted on 2019-05-20 00:05

I’m currently testing FeedBin syncing in NetNewsWire, and just filed issue #666. Hell yes!


Permalink - Posted on 2019-05-17 22:15

I’m so looking forward to LIVE near WWDC — not just because it’s fun, but because the App Camp for Girls folks deserve a huge round of applause and a big party!

And, of course, we want to support their ongoing mission, even if doesn’t include summer camps.


Permalink - Posted on 2019-05-17 18:23

Is it true that UISplitViewController doesn’t support three panes?

If so, then what I want from WWDC is three-pane support. Bigger iPads these days need it.


Permalink - Posted on 2019-05-17 17:51

Fiery Feeds is looking pretty damn good!


Permalink - Posted on 2019-05-16 20:11

Slack has a new thing — I think it’s new, anyway — where you can have a page where people can sign up to get an invitation. No longer a need to run your own thing.

Here’s a link for signing up for the NetNewsWire Slack group.


Permalink - Posted on 2019-05-15 19:59

ScriptWeb for iOS found: it’s Automation Orchard. :)


Permalink - Posted on 2019-05-14 22:31

Here’s what’s cool for me: normally I’d be stressing right now about a talk to give during WWDC — at AltConf or SwiftBy or somewhere — but I’ve retired from doing talks. It’s so nice not to be stressing!


ScriptWeb for iOS Should Be a Thing

Permalink - Posted on 2019-05-14 20:56

Back in the ’90s and early 2000s — before we forgot how easy and fun it is to code up a little site and put it up on the web — people used to make sites for the communities they were in.

It was like: “I know! Let’s put up a page! It will link to all the cool resources somebody interested in __ would learn from. We’ll update it now and again when there’s new stuff.”

Key point: it’s not a blog. It’s a directory, and often a single-page site. (There might be a few bullet points under a “What’s New” section, though.)

The best example that I know of was ScriptWeb — which still exists, though it’s no longer updated. It was all about Mac scripting, back in the early days of AppleScript, in the days of UserLand Frontier and MacPerl and HyperCard.

ScriptWeb was great. I started off my career as a scripter, and I went to ScriptWeb all the damn time.

So… where’s the ScriptWeb for iOS automation? I’m not going to do it, but somebody should!

* * *

If I were doing one of these sites these days, I’d store the source on GitHub, so that people could see revisions, and, most importantly, be able to make pull requests and file bugs for things they think should be added.

In other words: let the community help with the site. It shouldn’t be a big time commitment.


Permalink - Posted on 2019-05-13 17:46

NewsWave developer writes about his new app, including the principles behind the app and how he decided on the business model.


Permalink - Posted on 2019-05-13 05:10

I finally converted this site to SSL. It’s not the first site I’ve converted, but it’s the last.

It wasn’t hard. I’m using Let’s Encrypt, and my hosting provider handles all the details, including renewing and updating.

The one thing I had to do manually was edit the .htaccess file so that http requests get redirected to https.

I’m still dubious on the use of https for sites like this one — but mainly I worry about sites that are hard to convert or where there’s nobody to do the work. What happens to what remains of the web’s history if, at some point, browsers won’t let us visit those sites anymore?

I’m thinking specifically of alexking.org, penmachine.com, and aaronsw.com. There are plenty of others.

* * *

The change from http to https means all the permalink and guids changed in my feed — so you may get reruns in your RSS reader. Sorry about that!


Permalink - Posted on 2019-05-11 22:05

I discovered just today that there’s an independent forum for outliner software users: outlinersoftware.com. (I’ve been using outliners for decades. Couldn’t live without one.)


Permalink - Posted on 2019-05-11 22:01

Becky Hansmeyer writes, wisely, of App Store pricing, that “you’re not going to make it up in volume.”


Permalink - Posted on 2019-05-09 18:03

Dave Mark wonders if Marzipan apps will be available only through the App Store.

I wonder this too. This one of the biggest questions for this year’s WWDC. The answer matters to me personally: if Marzipan apps are App-Store-only, then I can’t use it for my apps.


Permalink - Posted on 2019-05-08 19:00

More to read: Martin Pilkington on Appreciating AppKit, Part 1.

Hopefully we’ll find that UIKit is awesome for writing Mac apps. But it’s worth knowing what AppKit provides, because it’s part of understanding Mac apps.


Permalink - Posted on 2019-05-08 18:20

Craig Hockenberry’s What to Expect From Marzipan should be required reading for iOS developers considering doing Mac versions.

I want to amplify a couple things.

If you’re writing a Mac app using Marzipan, you’re still writing a Mac app. You’re a Mac developer now! For real.

As a Mac developer, you should do what other Mac developers do: understand and respect the platform and get help from Mac users, power users, and fellow Mac developers.

I’ve always found that Mac users are rooting for our success. They want us to make great apps — and they reward us for it. It’s a smaller, more intimate community, and warmer than iOS world. But you can also blow it by not trying, by not respecting the Mac and Mac users.

And that’s the biggest investment here. It’s not the coding. It’s your own intellectual and emotional investment in the Mac itself.

If you decide you’re up for it, then great! And: thank you.


The Feature I Most Want in Web Browsers

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

Websites these days use crazy amounts of resources — and a lot of it goes to surveillance and tracking.

What I want is two related and similar things:

  • The ability to turn off JavaScript by default, and turn it on only for selected sites. (For me that would be sites like GitHub.)
  • The ability to turn off cookies by default, and, again, turn them on only for selected sites.

If it‘s the opposite — if I have to blacklist instead of whitelist — then I’d be constantly blacklisting. And, the first time I go to a site, it gets to run code before I decide to allow it.

I realize this will horrify many web developers: they’re accustomed to assuming that JavaScript is always available.

But we’re long past the time when we have to recognize that the extreme abuse of JavaScript and cookies is the norm. It’s the rare site that uses these for good.

I can’t believe we’ve tolerated this situation for so long.

* * *

PS You can still show ads without JavaScript. You just have to be able to render it server-side. I realize that’s harder.


NetNewsWire/Rainier Status

Permalink - Posted on 2019-05-07 20:40

The big thing remaining for NetNewsWire 5.0 alpha is syncing with Feedbin. My head is just not into syncing right now — I’ve done it too many times — but, luckily, Maurice Parker is into it, and he’s working on it right now, and making great progress.

NetNewsWire for Mac

There are some bugs to fix for 5.0 alpha — most of them small, but on that list is, of course, a new app icon. (Since an evergreen tree no longer fits the app.) There are some other cosmetic changes and very small features to consider too. But syncing is the big thing.

Once we get to alpha, then it’s all about testing, fixing any bugs that come up, writing the Help book, documenting the code, and getting the website closer to its shipping state (adding things like screenshots). A whole lot of writing, mainly — which I hope to get help with. Once that’s all done, then we’ll call it beta. (Beta is all about final testing and finishing the website.)

If things go well, we’ll hit 5.0a1 by WWDC. Fingers crossed!

NetNewsWire for iOS

The app is surprisingly far along (again, thanks to Maurice). It too is mainly waiting on syncing — but it also needs polish and UI review before it gets to alpha. My plan is to get there some time in the summer.

I expect to finish it after finishing the Mac version. I’m not trying for a simultaneous release. (Why bother? It’s harder to do a simultaneous release. It’s better to ship what’s ready to ship the moment it’s ready.)

Rainier

While Maurice is working on syncing, I’m taking a NetNewsWire break and working on Ballard, the language built-in to Rainier. Currently working on the parser and evaluator (the thing that runs scripts).

I’ve never written a language before, and I’ve always wanted to. It’s fun! And brain-bending. (I’m writing all of it by hand. In Swift, of course.)

One of the goals with the language is to create something simple but easy-to-learn and useful. How-it-works should be understandable to anyone who wants to peek under the hood. (Since it’s open source, you can learn the entire thing.)

The language, and much of Rainier, will also be embedded into NetNewsWire — because that will allow me to use it to write new features for the app and it will allow people to automate NetNewsWire using an easy scripting language with a built-in storage system. (Other apps could embed it too. Even yours.)

My two apps are not just related — I think of them as two parts of the same project. Something about the open web and the freedom and power to make things.

Rainier for iOS

There could be a Rainier for iPad some day. I’m not sure it would make sense as an iPhone app — but as an iPad app, definitely. (Though I’m not sure Apple would approve it. If not, you could build it on your own.)

It’s even possible — depending on what we see at WWDC — that I could write the UI using UIKit and Marzipan. I totally will, if that still means I can make a great Mac app and deliver it outside of the App Store and not have to sandbox it.

We’ll know soon enough!

But, for now, I’m still working on the lower levels of Rainier, which would be shared code regardless (the language, standard library, storage system, etc.).

Anyway. That’s where I’m at. :)

PS There’s a single Slack group for both NetNewsWire and Rainier. Email me at brent@ranchero.com if you’d like an invitation.


Elementary Swift: Catching the Actual Error

Permalink - Posted on 2019-05-05 19:14

I’ve written 100,000 lines of Swift code, maybe? But, even after all this code, I still have a blind spot with Swift try/catch. I’m writing this up just in case you do too.

My problem was with getting the actual error in a catch block. When I learned that there was a magic error variable, my problem was partly solved, because I could do this: catch { doSomething(with: error) }.

So that’s what I always did. But then, just yesterday, I finally had a case where I wanted to catch a specific type of error — and I just couldn’t figure it out.

I looked at the documentation on Swift error handling, which shows catching a specific error type like this: catch is VendingMachineError. (That’s the actual example! No, I’m not writing code for vending machines.)

I figured that, inside the block, there would be that magic error variable, and it would be typed as VendingMachineError. Like this: catch is VendingMachineError { doSomething(with: error) }.

Nope! That’s not how it works. The magic error variable does not exist in this case.

So…

I asked some friends — Dave DeLong and Tim Ekl — who helped me. The answer was this:

catch let error as VendingMachineError { doSomething(with: error) }

The key to this is that you use Swift patterns with the catch, and Swift patterns support variable binding. But patterns are a topic I don’t fully get yet, either.

(For instance, why do we use case sometimes outside of a switch? I don’t actually know.)

* * *

Anyway. This post has four points. One is to help anyone else who runs across this problem. Hopefully a search will land them here.

The second is to suggest that the Swift error-handling documentation really should have this as an example — catching an error of a specific type, and getting a reference to that variable, is (or should be) a common thing to want to do.

The third is a reminder that even long-time programmers are still sometimes learning basic stuff. If your brain likes to justify your impostor syndrome with various tests — like “I’m not a real programmer till I know everything about Swift” — then tell your brain to hit the road.

The last is a reminder that having smart friends is always a good idea. :)


Post-WWDC Lightning Talks at Seattle Xcoders: Speakers Wanted

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

The Xcoders post has more detail.

This is a great way to get started on learning how to talk in front of an audience. The Xcoders audience is wonderful. And you don’t have to talk long, and it will be on a topic that doesn’t have any experts sitting in the audience.

In other words: nobody’s judging you — we just want to learn what you have to tell us about. :)


NetNewsWire Syncing Implementation Roadmap

Permalink - Posted on 2019-04-30 05:23

I wrote up three new tech notes:

Why Articles and Statuses Are Separate Tables

Possible Gotchas To Be Aware Of When Working on Syncing

Syncing Implementation Roadmap

The last one is the important one — and it shows (but you knew already) that Syncing Is Not a Small Feature.

The good news is that a lot of it is infrastructure that needs to be written just once. Adding systems later will be much easier than adding the first one.

(I might be done with tech notes for now.)


NetNewsWire Technotes Added

Permalink - Posted on 2019-04-29 00:09

I’m writing some documents about NetNewsWire’s code and architecture. In part because I believe this is a good practice for any software project — but even more because I want NetNewsWire to be completely knowable by anybody who’s interested.

It’s one thing to have an open source app, and quite another to have one that anybody — even, or especially, new programmers — can read about and come to understand.

I don’t claim that every decision I’ve made is brilliant. In fact, some are just okay, and some might be bad. That’s fine! But it’s a real, working app, and I like the idea of having explanations of how it works and why it works that way.

I’ll be posting links on this blog as I write them. Note that the tech notes are part of the repo, and they appear in the workspace tree, so everybody who checks out the code has a local copy always at hand.

Two new ones today:

Accounts — notes about the accounts system. (The “On My Mac” thing is an account; later you’ll be able to add accounts for Feedbin and other systems.)

How NetNewsWire Avoids Parsing Feeds — talks about using Conditional GET and other methods to avoid parsing feeds.

PS My favorite, though written quite a while ago, is the Coding Guidelines.


The Under-Appreciated Awesomeness of Apple Events (the Technology)

Permalink - Posted on 2019-04-25 23:41

Picture Jane in her office. She gets an email from Bob every month with the latest WidgetX numbers. With that email in front of her, she double-clicks a script (or chooses one from a scripts menu), which:

  1. Grabs the text of that email
  2. Extracts the actual numbers (minus Bob’s signature, etc.)
  3. Tells FileMaker Pro to open a specific database, and then adds those numbers to the database
  4. Creates an HTML page from a template, including the new numbers
  5. Uploads that HTML page to the company’s internal CMS
  6. Creates and sends an email (via Mail), with the new numbers, that goes to the CEO
  7. Updates and saves (on a shared folder) a Keynote presentation with the new numbers

This used to take hours, and it was prone to errors. Now it takes a minute or less — and it’s error-free.

What’s going on here? It’s AppleScript, sure — but, under the hood, it’s Apple events.

How to save a computer company

Apple events (lowercase “e” is correct) arguably saved Apple in the ’90s. Desktop publishing was huge and very Mac-centric, and that was in part because the various tools were automatable. When you can automate, you can save time and money.

This was before Mac OS X: there was no UNIX automation. No shell scripts, no pipes, no Terminal.

Instead, there was AppleScript and UserLand Frontier and an underlying bit of technology called Apple events. And apps like QuarkXPress which were scriptable.

You might say that Steve Jobs — or the iMac or the iPod or NeXT technology — saved Apple. But it’s very possible that Apple, without automation, might not have lasted long enough to get to Steve Jobs.

What Apple events are

Roughly put — they’re a way of calling a function, with parameters, in an app and getting back a result.

There are a few key things to know:

  • The other app is an already-running instance: Apple events do not result in a new instance of an app (exception: if an app isn’t running, you can, conveniently, launch it via an Apple event)
  • The function parameters are not limited to strings — you can send binary data (image data, for instance), arrays, etc. (This is key: the API is much richer than just a URL scheme with some text, which is what we’re limited to on iOS)
  • Apple events are an underpinning of AppleScript, but they’re not limited to AppleScript — they can be sent and received programatically by any app

Mac developers will often use Apple events without even realizing it. For instance, there are methods in NSWorkspace that hide underlying Apple events: opening a URL in the browser, or opening a Finder window rooted at a given folder.

These work because the browser and the Finder respond to specific Apple events, and NSWorkspace knows how to send them.

Another key thing to know: this was early ’90s technology. It survived the transition to Mac OS X because people relied on automation — particularly, as I mentioned, for desktop publishing, but for other purposes too — and, without that automation, they would have left the Mac.

When I say “relied on,” I mean that there were companies whose profits relied, at least in part, on being able to automate away hundreds of hours of manual tasks.

And there are plenty of people today who rely on Apple events to get their work done. It’s quite common.

Apple events are an example of the genius of the Mac

The Mac, the “computer for the rest of us” — for those of us who didn’t want to deal with a DOS prompt and arcane stuff — always promised to be easy for novice users. The UI was consistent, which helped a ton. Designers were encouraged to make commonly-used features the most visible and easiest to use.

And that’s great — but the absolute genius was combining that with power-user features by way of progressive disclosure.

This meant that more power was there, but it wasn’t required in order to use the app well. But, once you needed it, you could find it. And that extra power was as well-designed as the rest of the app, so you could get the most bang for your click.

But what do you do about features that shouldn’t actually be baked into the app? What about the power to do what Jane does?

That’s where automation — Apple events — comes in. It doesn’t get in the way of the UI, but if you can find your way to Script Editor (or a similar app: there are others), you can learn how to write any feature or workflow you can dream of (as long as it’s technically possible).

Part of the genius of this is that you’re scripting the apps you already use. You’re scripting these great GUI apps that you know and love. No command line, no piping/launching/closing. Just pulling information from apps and telling them to do things.

The Mac OS X Accelerator Pedal

I have heard — I don’t know if it’s true — that some people at Apple wanted to ditch Apple events (and AppleScript) in the transition to Mac OS X. It was already a several-year-old technology, and I can see how people thought it might not fit in with OS X.

But the technology was preserved, as I mentioned earlier, because people and companies needed it. So it’s old stuff, but it’s stuck around for very good reasons.

But here’s where the Mac gets even better: OS X is UNIX, and now we can mix-and-match traditional Mac scripting with Python and Ruby and shell scripts and all the power of UNIX tools. (Note: you can call an AppleScript script from a shell script, and vice versa.)

I didn’t mention it, but Jane, in the example at the top, is using AWK to extract the numbers from Bob’s email text.

An outside observer might think Mac users just use pretty — and pretty simple — apps, and that’s the whole story. But that completely misses the power and genius of Macs.

I can’t think of another platform with the sheer level of automation power that OS X (now macOS) has.

So, after all that, a question

What happens to Jane if Mail is a Marzipan app that doesn’t respond to Apple events?


Freedom

Permalink - Posted on 2019-04-24 00:37

When my parents bought me an Apple II Plus — in 1980, when I was 12 — I fell in love with this entire new world that was mine. Anything that was technically possible, I could do.

I played games and I learned how to write programs in BASIC and, later, using an assembler.

It was marvelous. There were no chains on me other than the limits of the machine.

* * *

At the same time, grown-ups were sneaking in Apple II Pluses to work so they could run VisiCalc. A little later it was IBM PCs.

And the reason there was similar: the computing power they had access to was tightly controlled by the IT priesthood. Then the personal computer came along, and they had the freedom to solve problems on their own — when they wanted to, the way they wanted to.

This was a revolution.

And then, a little while later, the Mac came out. The PC was great and it democratized computers to a certain extent — but the Mac, and the ideas behind the Mac, took that much, much farther. People who were put off by a DOS prompt on a green-screen monitor had a computer they wanted to use. This extended that revolution, and Microsoft later joined in with Windows.

* * *

After a while, of course, people realized that work computers weren’t really their own. And IT departments did their jobs — as they should — and they networked these computers and worked out administration and so on.

But still, it was much better than what had been.

And — very importantly — outside work, your computer was yours. You had the freedom to use all its power.

And Macs and PCs became ever-more-powerful, with faster CPUs, bigger hard drives, more accessories, and — perhaps most importantly — better software. Things like Photoshop and QuarkXpress and Lotus 1-2-3 and Word.

And (on Macs, which I know best): HyperCard, AppleScript, and UserLand Frontier. ResEdit. INITs. All this crazy powerful stuff, which I loved.

* * *

Maybe because I lived through this — maybe because I’m a certain age — I believe that that freedom to use my computer exactly how I want to, to make it do any crazy thing I can think of — is the thing about computers.

That’s not the thing about iOS devices. They’re great for a whole bunch of other reasons: convenience, mobility, ease-of-use.

You can do some surface-level automation, but you can’t dig deep and cobble together stuff — crossing all kinds of boundaries — with some scripts the way you can on a Mac. They’re just not made for that. And that’s fine — it’s a whole different thing.

In a way, it feels like iOS devices are rented, not owned. This is not a criticism: I’m totally fine with that. It’s appropriate for something so very mass-market and so very much built for a networked world.

* * *

But what about Macs?

Macs carry the flame for the revolution. They’re the computers we own, right? They’re the astounding, powerful machines that we get to master.

Except that lately, it feels more and more like we’re just renting Macs too, and they’re really Apple’s machines, not ours.

With every tightened screw we have less power than we had. And doing the things — unsanctioned, unplanned-for, often unwieldy and even unwise — that computers are so wonderful for becomes ever-harder.

And now comes Marzipan, and I can’t help but worry that it’s another tightened screw. Will sandboxing be a requirement? Probably. Will they be able to send or receive Apple events? Will they support AppleScript? Seems unlikely. Will they be available only on the App Store? Good chance.

And you could say that’s fine — developers will use AppKit. But if AppKit is deprecated — or, effectively the same thing, perceived as deprecated by developers, or just perceived as uncool — then you get only the less-powerful Marzipan apps.

Meanwhile, the iOS triumphalists are saying that we should welcome the end of the revolution.

People will probably tell me it’s generational. And maybe it is. But if we don’t have this power that is ours, then I don’t actually care about computers at all. It meant everything.


NetNewsWire Now Running on iOS

Permalink - Posted on 2019-04-17 20:22

Maurice Parker took his proof-of-concept code and moved it into the main NetNewsWire repo — and now we have a version of NetNewsWire that builds and runs on iOS.

This morning, during my bus commute, for the first time I was able to read my feeds using NetNewsWire on my iPhone. So. Damn. Cool.

* * *

A TestFlight build is still quite a way away, I think. There’s still a lot to do. You could build it and run it on your own phone right now, but I wouldn’t recommend it yet.

* * *

I’ve been working on the app for five years. Most of the work is under-the-hood stuff — the UI is always the tip of the iceberg. UI is super-important, obviously, and takes a while to write too, but it’s not the bulk of the code.

Along the way I’ve had many moments where a thing I’d written years before — because I knew I would need it — suddenly becomes useful. For instance, I wrote the OPML parser early on (one of the very first things), and it was only years later when I added OPML import to the app. (There wasn’t even an app at all when I wrote the OPML parser.)

Those moments are great. The pieces start to click together, and you realize you planned well.

And this particular moment is one of the greatest of all — because it means that all of that under-the-hood code, written over so long, was ready to run in iOS with just the barest amount of rejiggering. (We needed to deal with NSImage vs. UIImage, for instance. We needed to restructure the workspace tree to make it easier to work on the two apps.)

So: I’m continuing to work on wireframes. We’ll iterate over appearance and behavior using a running app. I’ll get back to working on syncing pretty soon (because it won’t ship without syncing).

* * *

If you’re interested in helping — testing, coding, giving feedback, helping me think things through, etc. — I’d be happy to invite you to the NetNewsWire Slack group. Just send me email asking for an invitation.


Swift Generics Improvements

Permalink - Posted on 2019-04-15 01:45

Several days ago Joe Groff posted Improving the UI of generics on the Swift forums.

This proposal felt important — but it was, I hate to admit, really slow going for me to figure it out. For one thing, I had no idea what an “existential” is.

This is no criticism: this stuff, like a scientific paper, has to be written precisely and with agreed-upon terminology. It’s just that I don’t know all the terminology.

So, on another discussion forum, some of my friends were talking about it, and two people really helped with everyone’s understanding of the proposal: Greg Titus and Tim Ekl.

And then Tim went on to write a blog post which explains all of this in a way that regular Swift users — like me! — can understand.

Go read it! Swift Generics Evolution by Tim Ekl.

I’ve used generics a little, but I didn’t like what it did to the readability of my code. Now that I understand this new proposal, I like it. Very much.


More Thoughts at Random on Blog Search Engines

Permalink - Posted on 2019-04-14 18:54

I can dream about how I’d build one of these. (I’m not going to! This is way outside my expertise, and I have other things to do.)

Instead of having it crawl blogs, I’d have it download and index RSS feeds. This should be cheaper than crawling pages, and it ensures that it skips indexing page junk (navigation and so on).

To get feeds into the system, I’d add an accounts system to the site. A registered user can do two things: 1) add individual feeds and 2) upload an OPML file of feeds (which they’d probably get from their RSS reader).

Registration (with an email confirmation loop) would be required for feed-suggesting.

And: a feed gets added to the crawl-and-index list once it’s been suggested by at least two users. This should help cut down on spam.

Accounts that are suggesting spam would be just shut down. And suggestion counts for all the feeds they suggested would be appropriately decremented. (And of course all spam feeds should be removed from the index.)

There would also have to be a way for users to report spam. And report hate speech and other things that shouldn’t be there.

* * *

Anybody should be allowed to use the system: it doesn’t require registration. The main page is like Google or DuckDuckGo — a big search field.

Registered accounts can login and see their saved searches.

Searches should be able to look for incoming links to a given site as well as search terms.

It should also provide search results via RSS — to all people, registered or not — via an easily-constructed URL, as in https://blogsearch.example.com/search.rss?q=some+search+term

Since a search results feed includes items from different feeds, it should use the RSS source element.

* * *

I don’t have any solid ideas about making this a business. I’m sure that it would be way easier to build than the search engines we had in 2005. And it should be way cheaper to maintain.

It could display ads on the website. Maybe it would offer a subscription that gets rid of the ads and perhaps offers some kind of extra features.

Years ago you could probably get VC funding for something like this. I consider it a blessing that we’re way past VC interest in RSS and blogs — you don’t need that amount of funding to get it built and running, and you wouldn’t want it anyway.

Could a person or small team run it as a labor of love, like I do with NetNewsWire? I’m not sure, because I don’t know enough about the costs involved (other than that they’ve gone down). Maybe?

One of the key would be to keep it simple. It’s just one component in an ecosystem of tools. Do search, and do it well, and that’s it.


Wishing for Blog Search Engines

Permalink - Posted on 2019-04-11 20:20

One thing I wish we had that we used to have: blog-only search engines.

You could go and search for a hash tag. Or for links to your blog or elsewhere. Or for keywords. Etc.

It should have an API that returns RSS, so RSS reader users could set up persistent, updated searches.

There used to be a bunch of these, and now there are none that I know of.

* * *

Sure, it’s easy to search on Twitter. But you only get things posted on Twitter, and it doesn’t search the content of linked-to articles. So you’ll miss all kinds of things.

I can’t do this work myself — partly because I’m too busy with work and with other apps, and partly because I’m no expert at web-based stuff like this. I wish I could.


Permalink - Posted on 2019-04-11 20:09

Jeffrey Zeldman, Nothing Fails Like Success:

On an individual and small collective basis, the IndieWeb already works. But does an IndieWeb approach scale to the general public? If it doesn’t scale yet, can we, who envision and design and build, create a new generation of tools that will help give birth to a flourishing, independent web? One that is as accessible to ordinary internet users as Twitter and Facebook and Instagram?

I think so. I hope so. My part is to write a free RSS reader — and make it open source so that other people can easily use RSS in their apps.

RSS isn’t the only part of the solution, but writing an RSS reader is in my wheelhouse. So this is what I choose.

Do I claim it’s as accessible to ordinary internet users as Twitter (for instance)? I do not. But it’s the step forward that I know how to take.

My point is: don’t give in to despair. Take a step, even if it’s not the step that will solve everything. Maybe your step is just to start a blog or open a Micro.blog account. Whatever it is — do it! :) #LetsFixThis

* * *

See also: Why Micro.blog is Not Another App.net


WKWebView Rendering Latency in 10.14.4

Permalink - Posted on 2019-04-04 20:16

I noticed, starting in MacOS 10.14.4, that switching between articles in NetNewsWire was way less smooth than it had been.

NetNewsWire uses a WKWebView to display HTML. Before 10.14.4, there was no perceptible delay when switching to a new article.

With 10.14.4, there is. It’s quite noticeable, enough to be unacceptable.

I did some more detective work, and I’ve narrowed down the problem a little bit.

I’m using loadHTMLString(String, baseURL: URL?). The HTML is generated locally, and I set the baseURL because I want relative paths (especially for images) to get resolved properly.

What I found:

  • If I make baseURL nil, then the latency is gone.
  • If baseURL is the same as in the previously-loaded article, then the latency is gone.

Probable workaround

Here’s what I’m exploring: instead of using loadHTMLString for each article, I will:

  • Call loadHTMLString with a nil baseURL exactly once, to load a template.
  • To make relative paths resolve, I’ll parse and rewrite article HTML with resolved relative paths.
  • To load a new article, I’ll pass data to a JavaScript function inside the template that will swap-in new HTML in the right places (title, body, byline, avatar, etc.).

This is not work I was planning, and it means taking a break from syncing to get this done — because, right now, with 10.14.4, the app is not nearly as nice to use as it was.

PS While I’m rewriting the HTML, I’ll also remove ping attributes.