I used to think that the secret of happiness is that, when you show up at [whatever], people are happy to see you.
Which is great! It truly is. No question. When people see you, and they’re glad, it’s so great. It is.
But years on I figured out the real secret: what’s even better is that when they show up, you’re happy to see them, and you show it.
That’s the real secret to happiness.
Remember that at WWDC. :)
After five years of work — including getting the name NetNewsWire back, and a beautiful new app icon by Brad Ellis — NetNewsWire 5 has finally hit the alpha stage.
This was the very first milestone to hit in the bug tracker. No other milestone will take years to achieve. But I did it — and, way more importantly, we did it. I did a bunch of foundational work, but then folks like Maurice Parker, Daniel Jalkut, Olof Hellman, and others totally stepped up and made huge contributions.
* * *
When we (NewsGator, at the time) sold NetNewsWire to Black Pixel, I described working on NetNewsWire as the thrill of my career. I loved every minute. I loved talking to every NetNewsWire customer who wrote in. I loved everybody who helped test, and everybody who helped me think things through.
And now I’m at it again. Only this time it’s open source, and there are people willing and able to help actually write it. And there are people writing in again, via email and via the Slack group — and this is already better. A bigger thrill.
I’m in my 50s now. When NetNewsWire 1.0 shipped, I was 35. Did I think things could get better with age? Nope!
I’m so glad to be wrong. :)
* * *
How fortunate am I! Today is the day NetNewsWire 5.0 alpha one goes out — and it’s NetNewsWire, not something else, and it has a NetNewsWire icon.
And my Bendii Syndrome has taken me over entirely.
Find me at the Fairmont hotel lobby bar at 4 pm on Monday (June 3).
I don’t expect a large group — not like the Micro.blog meetup or Automators meetup. So I think we can keep it simple and just meet there in the hotel. (It’s a pretty big lobby.)
NetNewsWire isn’t in alpha just yet, but, with the addition of syncing with FeedBin, it is feature-complete.
Here are the change notes for this release.
Many thanks go to Maurice Parker, a major NetNewsWire contributor, for writing the syncing system.
This is a major milestone! I can see shipping from here. I’ve been working on this thing for years, and it feels great to be getting close.
We’re testing and filing and fixing bugs. Brad Ellis is working on a new app icon.
We’ve just started working on the Help book, which will live online.
We haven’t thought that much about the product page yet, but we’ll have to make that a real marketing page while still retaining — hopefully enhancing! — the spirit of the app.
The iOS app is surprisingly far along. At some point, hopefully this summer, we’ll get that into TestFlight.
And, of course, after NetNewsWire 5.0 will come 5.0.1, 5.1, and so on. There are lots of things still to do. NetNewsWire 5.0 will be the foundation, not the end.
PS If you want to help test, write code or documentation, or just help us think things through, please consider joining the Slack group.
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:
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.
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.
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. :)
I’m currently testing FeedBin syncing in NetNewsWire, and just filed issue #666. Hell yes!
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.
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.
Fiery Feeds is looking pretty damn good!
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.
ScriptWeb for iOS found: it’s Automation Orchard. :)
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!
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.
NewsWave developer writes about his new app, including the principles behind the app and how he decided on the business model.
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!
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.)
Becky Hansmeyer writes, wisely, of App Store pricing, that “you’re not going to make it up in volume.”
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.
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.
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.
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:
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.
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.
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!
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.)
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.
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.
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. :)
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. :)