I wanted to write something positive about the Fairphone Fairbuds. Here it is: They are a great idea. That’s it. Please move on. Continue reading for gory details, but this really sums it up: Replaceable batteries at the cost of a larger form factor is a tradeoff I am absolutely willing to make and advocate for. I hope more companies try this in our greener future.
So I found this list of books I read and which I wanted to put on this blog in my inbox. It’s from a migration from OmniFocus to Emacs/org-mode from 2019, and the title is “Transformative Reading 2017”. What were the picks back then? And being 7 (!) years wiser, what do I think about the picks now? Here’s the list. I don’t know why I originally ordered them this way, but I left it as-is.
Berlin-based company ExactCODE, makers of ExactScan and OCRKit, experiences trouble with Catalina and a rather short time to submit bug fixes for their app before the public release of Catalina earlier this month. They decided to leave the Mac App Store behind:
- each manual update review by Apple causes delay and drama
- AppStore does not support paid upgrades, only new App, in-App purchase or subscriptions
- Apple takes 30% and that is not sustainable to run a company and pay salleries
- it is not provide to provide free updates forever
- if you purchased our application this year we provide a direct license, if you had it significantly longer, we think a paid upgrade is fair for continuously developing, improvements, and support
[…]
There is mostly only one benefit [of using the MAS] for users: one central place for purchasee and updates. However, there are many negatives, such as: […]
I don’t know if they could’ve done more to prepare for the macOS upgrade. Recently, folks on Slack shared screenshots, and it turns out that as a serious Mac developer you apparently have external hard drives full of previous and future macOS versions, plus a stack of different Xcode versions (that are no longer available for download by Apple!) – that’s required by virtually everyone in order to support multiple OS versions and fix bugs. The Catalina beta also was very flaky.
After releasing the Catalina Golden Master build to developers on October the 3rd, we immediately finished fixing any new crash or issue we could find over the weekend. In our opinion, leaving developer just four (4!) days over a weekend with a public release on October the 7th is not very helpful nor professional.
They have a point here. But could they have fixed the same bugs earlier in preparation of the Golden Master release?
The call for App Store submissions went live on October 3rd, too, at the day of the Golden Master release. So even if they fixed all the bugs early, Apple would have had only 4 days to review all App Store submissions, which sounds like a bad idea nevertheless.
See also:
Shameless plug: I also wrote a book on selling outside the Mac App Store in case you want to leave the App Store, too, or make your company more resilient through availability in multiple stores.
Since I’m going to spread my writing thin on this blog in the upcoming weeks, I thought it might be nice if I highlighted some things that were happening. So here goes. Update 2017-04-29: Forgot the coding stuff. Is now added!
Although I knew there’s a “cookbook” book series, I haven’t read any of these before I read Erica Sadun’s The Swift Developer’s Handbook. The code listings are called “recipes”, and most of the time rightly so: I bet I copied about a dozen of the recipes into my own handy code snippet index to extend Swift’s capabilities with super useful things like safe Array indexes.
Recently on Google+, someone recommended Wallace Wang’s Swift OS X Programming for Absolute Beginners. Well, I’m not a beginner anymore, but the book sounded fun, so I gave it a spin. And I’m quite impressed. That’s why you read the review here. In short, Swift OS X Programming for Absolute Beginners (or SOXPAB as I would like to call it to save myself from typing that much) is the best programming book to teach the reader about user interface programming. I can’t honestly judge how well this textbook will actually work for non-programmers. But that’s because I can’t fathom learning to code from a book anyway. If you know programming, or the Cocoa APIs already, this should work for you.
This post has moved to Zettelkasten.de. Read it there.
I want to start this series of reviews with a software I’m fairly familiar with. While most things apply to the Notational Velocity base application, I will talk about nvALT exclusively in this review. nvALT is a fork by Brett Terpstra and David Halter of the original Notational Velocity, which was created by Zachary Schneirov, and a few modifications by yours truly. It’s Open Source, free, and very popular.
This post has moved to Zettelkasten.de. Read it there.
I’m going to take a close look at applications to find out which are suitable to implement the Zettelkasten note archive. I already talked about reference managers. While reference managers can be switched pretty easily, migrating a database of notes is far from being a trivial task, depending on the software you used in the past. Therefore, we have to chose how to implement the note archive with great care. Here you’ll find my criteria.
If you are interested in taking notes fast and reliable but never got around NV’s interface, now it’s the best time to reevaluate the situation. Introducing nvALT, the result of joint efforts of both David Halter and Brett Terpstra who united their two popular NV forks.
Two weeks ago, I switched from my own NV fork to nvALT. In this newest community-customised fork of Zachary Schneirov’s original Notational Velocity, a few neat design changes have been applied. There is a fullscreen mode, widescreen-layout (<3), word count and a shortcut to open the current file in TextMate—just to name a few of my favorites. Naturally, NV’s original features introduced in January are included as well: for example Tags are stored in OpenMeta format, meaning you can delete the Notes & Settings database file without any loss (except bookmarks), which initially make them useful for me since heavy NV customizations can render this file useless in no time.
Also, the text width is adjustable: when set to 650px with a nice and free Anonymous Pro 14pt font, you can resize the window to your liking but never exceed 78 characters. In this way, I can focus on writing notes in fullscreen mode and still be able to manually break lines at a common width. (Common in respect of ancestral terminal use and derived guidelines for composing plain text files, mails and whatnot.)
There are a few issues which I’d like to fix as soon as the source code is released.
Hereby, I stall my fork until nvALT’s source becomes available. Maybe I’m able to plug my desired custiomizations into this new big thing.