inessential.com

Brent Simmons’s weblog.

FaviconMark All as Read 22 Jan 2019, 5:00 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 22 Jan 2019, 3:01 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 22 Jan 2019, 2:41 pm

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

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconXcoders Blog Renovation Phase Two 18 Jan 2019, 12:55 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 17 Jan 2019, 5:38 pm

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

I think so too.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 16 Jan 2019, 7:41 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 16 Jan 2019, 5:50 pm

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

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconOn Public Bug Trackers 15 Jan 2019, 4:41 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconNetNewsWire Privacy Policy 14 Jan 2019, 2:08 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 9 Jan 2019, 6:47 pm

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.)

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 7 Jan 2019, 6:57 pm

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

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconNetNewsWire Diary #3: The Crash Reporter 18 Dec 2018, 4:32 pm

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.)

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconPrison 13 Dec 2018, 4:35 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconNew Xcoders Site 11 Dec 2018, 8:48 pm

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. :)

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 6 Dec 2018, 4:52 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconOn Using Stock User Interface Elements on the Mac 6 Dec 2018, 4:30 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 5 Dec 2018, 7:27 pm

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.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconSo Basic It’s Not Even Funny 5 Dec 2018, 4:14 pm

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.)

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 3 Dec 2018, 2:59 pm

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!

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconCrash Catcher for NetNewsWire? 28 Nov 2018, 1:17 am

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…?

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconNetNewsWire Status Report: the Last 10% 27 Nov 2018, 4:24 pm

I’ve been working on this app — originally Evergreen 1.0, now NetNewsWire 5.0 — for four years, at least. And now GitHub tells me that the 5.0 alpha milestone is 91% complete.

Which means, yes, I’m down to that last 10%. Old engineering wisdom says that the last 10% takes as much time as the first 90%, which means I have another fours year to go, and it will ship in late 2022.

I’m going to try and beat that, though, and ship in the first quarter of 2019. Let me emphasize the try part of that — there’s no guarantee. But I’m resisting all other temptations and buckling down on NetNewsWire.

What remains, of course, is all the stuff I’ve put off. Like syncing, drag-and-drop in the sidebar, search, and so on. (New app icon coming too.)

Note that I did say the alpha milestone is 91% complete. Let me be clear what I mean by alpha: it will be feature complete and won’t have any known defects. The alpha period will be for testing and finding and fixing bugs.

Once it gets to beta, it will be considered a shipping candidate. If possible there will be zero code changes from beta 1 to shipping. At any rate, code changes, at that point, will be made with extreme reluctance and caution.

(Yes, this is a little different from how other people do things. It’s how I do things.)

My hope is that it will get to alpha in February, and that things will move relatively quickly from there and then it will ship in March. Maybe on my birthday? (March 26.)

Again, that’s just a hope. Anything could happen!

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 21 Nov 2018, 4:19 pm

Is there an App Store for Saudi Arabia? I don’t personally have any apps on the App Store — but if I did I’d make them unavailable there.

It’s totally a-okay for businesses and individuals to impose our own sanctions. We should, in fact.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconRainier Diary #10: Ballard’s Tokenizer 21 Nov 2018, 4:11 pm

Rainier is the app, and Ballard is the language. It’s named for the neighborhood where I live in Seattle. (Using Pacific Northwest names is what I do now.)

Ballard has a fresh GitHub repository. It’s a separate framework, since I want to use it in NetNewsWire, and because I want to make it so other people can use it in their apps if they want to.

Another goal: the code should be understandable and tinker-able. The idea is to create a language where the implementation is not mysterious, where it’s accessible to even new programmers who are willing to put in some effort.

So I’m writing in Swift, at the highest level I can, and I’m writing blog posts which explain things.

Four Pieces

The language implementation will have four main parts:

  • Tokenizer: takes a string of code and breaks it into tokens. A token is a small structure that specifies things like: this is an identifier, and its name is whatever. Or this is an if keyword. Or this is a + sign. Etc.
  • Parser: turns the tokens into a tree of nodes that can be evaluated.
  • Evaluator: runs the script — that is, it evaluates the tree of nodes created by the parser.
  • Standard library: the set of commands — we call them verbs — that are built in to the language. These are for things like operating on strings, files, dates, and so on. This also includes some constants for things like the maximum value of an integer.

Makes sense, no?

Where I’m At

On the weekend I got far enough with the tokenizer — named Tokenizer — that I could start writing tests for it.

The tokenizer is probably the least interesting part of all of this, and I don’t think I need to write much to explain it.

The gist of it is that it goes through the string by calling popNextToken() to create an array of tokens until it reaches the end of the string. It will throw an error if it encounters something it can’t handle.

Which should be super-rare, because the tokenizer does not do much in the way of syntax checking. The tokenizer should be able to handle stuff that is entirely incorrect code.

Checking syntax is the job of the parser. The tokenizer just performs that initial pass that gives the parser something besides raw text to work with.

So, next step: write more tests for the tokenizer, fix any bugs, and then move on to the parser.

The parser will be more challenging, for sure. The evaluator, too — especially since it needs to be able to handle debugging, which means being able to pause, view the variables in the stack, resume, etc.

But one thing at a time: the tokenizer comes first.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconOne Year of The Omni Show 9 Nov 2018, 3:18 pm

It just popped in my head to check today — and, sure enough, I’ve been doing The Omni Show podcast for just over a year now.

There are a bunch of reasons why I like doing it. The main reason is that it’s fun to show the personalities of the people who work at Omni — and the personality of the company — to the outside world.

It’s also fun as a way for co-workers to get to know each other a little better. We’re showing our personality to ourselves.

I also like it as documentation. This is a special time — our industry is still so young — and so I like it in the same way I liked doing The Record with Chris Parrish. This history will all be lost unless we record it.

And recording this history means not just talking to the usual suspects, the same people you hear every week. It means talking to people who’ve never been on podcasts before, but who all have stories to tell. This is a personal challenge — it takes extra work to prepare for someone different every episode — but it’s so satisfying. I love it.

PS For the curious: last April I wrote, on The Omni Blog, How We Do the Omni Show.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 7 Nov 2018, 4:48 pm

After the firing of Attorney General Jeff Sessions today — not at all unexpected — we’re closer to the break-glass moment where we take to the streets.

It could happen any moment, any day. Could even be minutes from now. Could have happened by the time you read this.

Sign up here.

PS The Democrats retaking the House last night was huge. The next two years were going to be perilous and tumultuous either way — but now we have a way better chance of just outcomes.

But we may walk through fire first.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconWhy I’m Writing These Particular Apps 6 Nov 2018, 2:18 pm

On the Rainier Slack group, I was asked why I’m writing the app. What are my goals? What’s my exit strategy?

The below is how I replied. It’s unedited Slack-writing, so forgive me for (for one thing) suggesting that at age 65 I might not be writing code anymore. (I very much hope to be.)

Here’s the deal with Rainier (and NetNewsWire too). I’ve been obsessed with writing this app for many years. I’m 50 now, and have a good day job, and I don’t need to make any extra money. This means I can afford to make the apps I’m compelled to make. They will do good for the world, and I do have political and social goals for them.

But I don’t expect NetNewsWire to be popular like Twitter, and I don’t expect Rainier to be popular like Ruby or Python or Swift. Not even close.

I’ve worked all these decades to be able to be in the position where I have the ability and freedom to write the apps I want to write. Anyone could argue that I should be putting my skills and experience toward something more likely to be earth-shaking, and that’s fair — but I believe I can do the most good by making the apps I was born to make, rather than working at something that doesn’t excite me.

Large numbers of users doesn’t excite me. High-quality, open source Mac apps excite me. Bringing the power I enjoyed with Frontier to a new generation excites me. Bringing RSS reading back excites me.

My goal is just to be able to continue working on these apps, no matter how few or many users they have. My exit strategy… well, eventually cognitive decline will come, and I’ll write less code and do more writing about the apps. And eventually I’ll end up turning them over to someone else (or some group). But hopefully that’s 15 years from now, at least.

These are the apps I need to make. This is an emotional thing, for sure — but I’m rational enough to understand my heart and to follow it rather than to fight it.

Further reading: Love, from 2015, and Why I develop for Mac OS X from 2002.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconVote for Democrats Everywhere 5 Nov 2018, 3:14 pm

The president recently called himself a nationalist — and it’s no stretch at all to call him a white nationalist.

From before his campaign, to his remarks after coming down that escalator in Trump Tower, to everything he’s said and done since — including his recent drumming up of fear about refugees planning to seek asylum in the United States — he’s led the effort to ensure that America respects only white power.

This is antithetical to Western democracy, which is built on individual liberty and equal protection, which says that all adult citizens have the right to vote.

If Republicans in Congress had acted as a check on his power, if they had exercised oversight, then I could plausibly suggest voting for the best candidate in each race.

But that didn’t happen. Not even close. It’s been quite the opposite — Republican politicians have aided him at every conscience-shocking turn, and the Republican party has become the party of white nationalism.

I don’t agree with every position of the Democratic Party, and I certainly don’t agree with every position of the candidates available to me. But that’s always true.

What I know, though, is that a Democratic majority in at least one Congressional chamber would finally allow for checks on the president’s power. There would be oversight, at long last.

And we’d have the chance to preserve Western democracy in the United States, and stop this acceleration toward something dark and old and corrupt and dangerous.

Please vote. Please vote for Democrats.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Favicon 31 Oct 2018, 2:27 pm

The latest episode of The Omni Show should be of interest to developers — it’s all about building OmniFocus for the Web.

Remember that OmniFocus is a Mac and iOS app written in Objective-C and Swift. The answer for how Omni made it work on the web is the most Omni thing ever. :)

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconIntroduction to Rainier’s Scripting Language 17 Oct 2018, 4:14 pm

I just posted a tech note for Rainier’s scripting language, Ballard.

Feedback is welcome, of course. Best place is on the Slack group. (You can find my email address near the bottom of this page and then email me to ask for an invitation.)

(Note: other tech notes on the Rainier site are out of date, so I’d skip ’em for now.)

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconWhy Create a Frontier-Inspired Scripting App? 16 Oct 2018, 1:28 am

Let me tell you about Frontier.

It still runs (though on its last leg as a 32-bit app), but I’ll talk about in the past tense, because I’m talking about it in its heyday in the ’90s and early 2000s. I was working at UserLand — Dave Winer’s company, which made Frontier — at the time. I was a Frontier enthusiast before I joined the company. It was my dream job.

Frontier began life as a Mac scripting app, before even AppleScript. While it never lost that ability, it turned into a web scripting app around 1995, which is when I first started using it.

In those days — ’90s and early 2000s — Dave Winer invented, collaborated on, popularized, or fleshed-out a number of things we take for granted today: websites created with scripts and templates, weblogs, RSS, RSS readers, podcasting, OPML, and web APIs (XML-RPC).

It was an extraordinary run of creativity. You might just assume that Dave and his team were writing in Perl or Python or similar — but we weren’t. All this work was done in Frontier.

Does the tool matter?

It’s easy to say that the tool doesn’t really matter, that it was all about the people and that particularly fertile time. And it was about that.

But if the tool doesn’t matter, then why do developers care so much about their tools? Tools matter too.

Nothing in my entire career has ever matched Frontier for how it enabled me to make things quickly. Things that are difficult in other environments — persistence, debugging, seeing the results of a script — are so simple in Frontier. It’s just how the app works. It still feels to me like it comes from the future.

The bet I’m making is that there was something special in this design, that this particular tool was capable of unleashing a level of creativity capable of changing the tech world.

What Frontier Was Like

Frontier was a Mac app (yes, there was a Windows port eventually) with an integrated hierarchic database and scripting system.

The key is that it was a Mac app, in the very best sense — it had that old-school Mac philosophy of taking things that were abstruse and difficult and reserved for the priesthood and giving them an easy-to-use GUI. You browse the database and add, edit, and delete values. Everything lives in the database.

Even your scripts live in the database. Open a script in a window, edit it, click Run or Debug, jump to a different script, etc.

The database

Think of the database like a dictionary that could contain dictionaries. We call those tables, but they’re not at all tables in the SQL sense. (Think hash table.) A table can have subtables, and sub-subtables, and so on.

The database holds scripts, outlines, menubars (you can create menus and attach scripts to menu items), styled text, strings, arrays, booleans, numbers of various types, binary data, and more. (Even some things nobody uses anymore, such as QuickDraw rectangles.)

There’s one simple bit of power — it sounds small to say it, but it’s huge: persisting data from a script is as simple as this:

states.Nebraska.capital = "Lincoln"

In the code above, there’s a table named states with a subtable for each state, and it sets the value of capital for Nebraska to “Lincoln.”

Quit and relaunch the app — it’s still there.

Like dictionaries, tables have no schema. You can put anything you want into any table. And of course scripts have full power to create, edit, and delete tables and not just values (the database is fully scriptable — that’s the point).

Scripts

Just as you can refer to database values using dot syntax, a script can call another script the exact same way. In fact, you do that all the time, because the standard library is also stored in the database.

If you call file.readWholeFile(f) — which returns the contents of a file as a string, given the path — you’re actually calling a script readWholeFile that lives in a table named file, which contains the standard library’s file verbs.

And of course that works with your own scripts too. There are no import statements — you just call, using dot syntax, whatever you want to call.

The debugger has the standard things — step into, continue, etc. — and you can view the stack when you debug. The stack is just more tables! Which you can also edit, while you’re debugging, like any other Frontier tables.

And the debugger works across scripts — you can step into a call to another script and continue debugging. (This is super-common, even.)

Your one-off scripts are typically stored in the workspace table. For collections of scripts that work together — as a kind of app — you’d create a “suite” (a table containing scripts and data) or, in later years, you’d put them together in a separate “guest” database.

Getting around was super-easy — if you saw file.readWholeFile in a script, for instance, you’d cmd-double-click it to jump to that location in the database.

Brilliantly, and I think uniquely, scripts were written in an outliner. Scripts are, after all, tree structures — and using an outliner for code folding and reorganizing has huge advantages. It feels surprisingly natural, too. I know how how weird that must sound to anyone who’s never written code that way. But, really, all other code editors seem sad to me in comparison, like reindeer that can’t fly. The outliner spoiled me.

(Tabs vs. spaces was never an issue, at least!)

In the end

It was just so easy to start something, and then refine it and keep going, and make things that did useful things.

We wrote blogging software and RSS readers and all kinds of early open web things. (It even had a built-in webserver.) It was fun — it was a joy, even.

I think the Mac is missing this app. So my goal with Rainier (which is a mess at the moment) is to do a new, modern Mac app inspired by Frontier. It won’t be compatible with Frontier, and lots of details will be different, but I hope to capture that same lightning, which, I think, we could use right now.

I could be wrong! Worst case is that I’ll just get back the fun that I miss so much. Which is okay. :)

PS Somebody somewhere is thinking that this is like a very weird, not-object-oriented Smalltalk. It is! But that doesn’t make it less awesome.

PPS I’ve left out a ton of details, but I hope I’ve gotten the gist of this across.

PPPS If you’re interested in joining the Slack group and helping me with my thinking, just email me. (You can find my email on this page.)

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

FaviconNetNewsWire Article Age Limits 13 Oct 2018, 5:41 pm

RSS readers — at least the several where I know how they work — have some limits on how long they keep articles and how long they track read/unread status.

I may not have the details exactly right, but I recall that Google Reader stopped tracking read/unread status for every article older than 30 days. With NewsGator it was two weeks or the most recent 200 articles. Older versions of NetNewsWire had different limits, depending on which version you’re talking about.

There are several good reasons for limits. One is ethical: piling up unread articles forever isn’t fair to people. Your RSS reader should not be a taskmaster or a source of guilt. Articles should age out after a period of time.

Another is that the more data is saved, the slower database lookups tend to get, and the slower the app gets. In the case of a Mac or iOS app, this also means using more disk space and more energy (more battery).

A third is that if an RSS reader sets the expectation that it creates a personal backup of the internet, then the developer will be doing features, bug fixes, and performance optimizations for this forever, to the detriment of the rest of the app and the majority of its users. (I went through this with earlier versions of NetNewsWire.)

Limits are a necessity. The hard part is deciding what the limits should be, and figuring out how to make them understandable to users.

NetNewsWire will sync with various systems (Feedbin and similar), and, for each syncing account, it will just adopt the limits of each system.

But that still leaves one case where the limits need to be worked out: the non-synced On My Mac account. The below is my thinking (after much discussion with other people) on this.

The Rule

Articles older than n days will be deleted automatically — but it will preserve a minimum of the 10 most recent articles per feed, and it won’t delete starred items.

(Where n is something like 90 days.)

This is slightly more complex than just aging out older articles. It makes sure that feeds that haven’t been updated in a long time still have their most recent 10 articles.

I think this is reasonable because you don’t want to click on a feed and see zero articles just because it hasn’t been updated in six months (or whatever).

But there’s a tricky part here: how do we define the age of an article? Seems like it should be obvious, but it’s not.

Publication Date vs. Arrival Date

Every article has three dates, though two of them may be empty.

  • Publication date: the date specified in the feed when the article was published (may not exist in the feed)
  • Modification date: the date specified in the feed when the article was edited (may not exist in the feed)
  • Arrival date: the date NetNewsWire first saw the article (guaranteed to exist, since it’s NetNewsWire-generated)

Most of the time, arrival date and publication date will be pretty close. Not always, though — not, for instance, when adding a feed. When it reads a feed for the first time, the arrival date is that moment for each item, while the publication date could be anything.

You might think, naturally, that NetNewsWire should use arrival date when deciding whether or not to delete an article. If it arrived more than n days ago, then it should be deleted, because that means the user has had it for more than n days.

But there’s a problem with that: arrival date is never shown in the user interface. It’s not otherwise an interesting piece of information, where publication date is interesting to users.

So if we have a time-based limit that’s triggered by unseen metadata (arrival date) — and there is visible metadata (publication date) of the exact same type and that seems like it’s directly relevant to age — then I think we have to use the visible date, the publication date.

This makes the limit understandable: you can see the dates, after all, that it uses for its calculation.

(Note: when publication date isn’t specified in the feed, then NetNewsWire uses the arrival date as the publication date, since it will usually be pretty close. Luckily, feeds do tend to include publication dates.)

The one drawback to using publication date, though: it could delete an article with a recent arrival date but a long-ago publication date. I think this is okay — I think it’s the best of the available trade-offs.

The Other Tricky Part: Communicating with the User

The app shouldn’t behave mysteriously. How this works should be clearly communicated.

One option is to just to write about it in the Help book. Unfortunately, people don’t read these all that much.

So here’s what I’m thinking:

Since there will be a preference pane where you can add and edit your various sync accounts (much like in Mail), we have a place for settings for the On My Mac account.

In those settings would be something like this:

Delete articles published more than: [popup] 30 days ago / 90 days ago / 120 days ago

With explanotext:

The On My Mac account deletes older articles when there are more than 10 articles in a feed. It never deletes starred articles.

Though I most definitely like to limit preferences, this is a reasonable thing to want to configure — and having this there makes it much more likely that a user will see it and learn about the limit.

I think that’s the best call, though it’s not set in stone yet.

Reminder: None of This Applies to Syncing

After reading all these words, you might have forgetten that I’m just talking about the limits of the On My Mac account. Different syncing systems have their own limits, and NetNewsWire will adopt those for the synced accounts.

Feedback welcome

If you go to the repo you can find my email address and find the bug tracker. You can always email me to ask to be added to the Slack group. But — fair warning! — a lot of the discussion is over super-dry stuff like this issue.

Blinklist Blogmarks del.icio.us Digg Ma.gnolia My Web 2.0 Newsvine Reddit Segnalo Simpy Spurl Wists Technorati

Page processed in 8.906 seconds.

Powered by SimplePie 1.0.1, Build 20070719221955. Run the SimplePie Compatibility Test. SimplePie is © 2004–2019, Ryan Parman and Geoffrey Sneddon, and licensed under the BSD License.