Writefreely for iOS v1.0
I'm thrilled to announce the release of [WriteFreely for iOS] on the App Store. 🚀
I'm thrilled to announce the release of [WriteFreely for iOS] on the App Store. 🚀
UPDATED: I opened my original PR against the wrong branch, so I've fixed the links here to point to the new PR.
I've been wanting to learn more about building macOS apps. SwiftUI multiplatform apps are a great way forward in building something quickly, but you'll often still need to drop into AppKit and UIKit to solve things that SwiftUI just doesn't address (yet). So, for someone that's got some experience building iOS apps, what's a good way to learn?
I could just build a bunch of toy projects on my own. I read through Hacking with macOS which taught me a tonne. But for myself, the best learning is social learning — by observing and interacting with others.
I've been lurking on the Slack group for NetNewsWire for months, and once I felt comfortable with the way the community worked together, I asked to tackle a first issue. Nothing especially complex for my level of experience, but that would have me digging through the codebase to figure out how things work, and learn how to make the changes for a framework (AppKit) that I'm less familiar with.
I like digging through a codebase and teasing apart the way it works. The advantage of poking at NetNewsWire is that it's a nicely-organized project, clearly structured for long-term maintainability by anyone willing to contribute.
(If we're ever able to sit and enjoy an afternoon restorative together, ask me about having to port a 20 kLOC, uncommented, single-file code project to another language.)
(On second thought — don't.)
It's one thing to learn how the Notifications API works by changing the way a feature works. But there's a lot to learn by looking at how others structure and organize their codebase, set up their build steps, share code between iOS and macOS targets, &cet. You just don't get that depth from simple how-to tutorials. Those tutorials have their place in the learning process, and they're a wonderful community resource! But you have to go deeper to go from “my first massive view controller app” to building a complex software project.
Another nice thing about contributing to NetNewsWire is that the community is wonderful. One thing I appreciated was that I was trusted to tackle the problem myself, rather than be told (more or less) what to do as a first-time contributor. Of course, any questions I had were answered, and whenever I asked for feedback it was honest and helpful. That's a testament to the community Brent Simmons has built around the project.
And so, I opened my first pull request this morning. In service of showing messy work (and because it's good Git hygiene, IMO), the work's broken up into a dozen fairly small commits. You can see some of the comments I removed after figuring out what exactly happens when you fetch the user's notification settings, for example.
I'm looking forward to the team's feedback on my proposed changes, and I'm looking forward to contributing more to the project!
Hot on the heels of the WriteFreely Swift Package, I'm kicking off another fun open-source project: building a WriteFreely client for all Apple platforms as a SwiftUI multiplatform app.
I've written about the project a bit more here, where I'm sharing updates on the WriteFreely/Write.as work I do. If WWDC got you interested in learning more about multiplatform apps and SwiftUI, join me in building this! The goal is to go from what you see in the GitHub project today to a functional app by the end of August. Developers of any level of experience are welcome!
This work will have two tracks — building the client app, which will be the bulk of the work, and improving the Swift package. Personally, I'm more excited about SwiftUI and multiplatform apps than I've been about other tech stacks in a long time.
That said, one of the reasons Per has been stagnating for as long as it did was because I got bitten by the Swift 2 → 3 transition, which kinda broke everything. I'm hoping that it'll be smoother for SwiftUI as it's improved and extended over the next few years.
More TK!
Today, I published the v1.4.0 release of Indigo, my theme for the Hugo static site generator (which powers this site as well).
Web Monetization is a draft Web API spec that lets the user agent (i.e., your browser) stream payments to a website. I got to speak with a few people on their team, and the idea of a privacy-focused, patron-driven way for creators to generate revenue really spoke to me.
I then promptly got caught up in a bunch of other stuff, so when a couple of posts that were recently shared by Chen Hui Jing (1, 2) showed up in my feed reader, it reminded me that I wanted to add it to Indigo (as well as my own site).
Hui Jing explains it all in great detail, but in essence, the way this works is as follows:
<meta name="monetization">
tag to the head
of their site.Once that's set up, anyone that's got a Coil subscription and is using a compatible browser will now micropayments to that creator whenever they visit that site. Hui Jing's site is monetized, as are some others you may know.
First, make sure you update the theme to v1.4.0, just as you would update any Hugo theme:
$ cd path/to/your/hugo-site
$ cd themes/indigo
$ git pull origin v1.4.0
Then, open your site's config.toml file and, under the [params]
section, add:
paymentPointer = "$your.payment.pointer/here"
Build and deploy your site, and you're ready to go! If you've got any comments or questions, don't hesitate to reach out and let me know.
It's been a while since I posted an update here, and I wanted to announce a new project: a WriteFreely Swift package that you can drop into your Mac and iOS apps.
You can find it here: https://github.com/writeas/writefreely-swift
WriteFreely is an open-source platform for writing on the web. It powers the Write.as service (find me here!), and lets you build writing communities on the web.
I was introduced to Write.as and WriteFreely while working with Glitch, where I got to chat about the service and its principles with Matt and CJ. Matt wrote a thoughtful post on Glimmer about the importance of privacy for creating on the web, and CJ built a tonne of cool sample apps that connected to the Write.as service for their Glitch team.
This project represents a couple of firsts for me:
URLSession
and Result
in SwiftRight now, it's an alpha/developer-preview release. There's a lot of room for improvement here, and I'm looking forward to working towards a 1.0 with the WF community.
As I mention in this forum topic and my Write.as post, the design for the WriteFreelyClient
is to leverage completion blocks that return a Result
tuple with either a User
, Post
, or Collection
(or an array of these types where that makes sense), or an Error
on failure. That makes it pretty easy to build completion handlers:
func loginHandler(result: (Result<User, Error>)) {
do {
let user = try result.get()
print("Hello, \(user.username)!")
} catch {
print(error)
}
}
guard let url = URL(string: "https://your.writefreely.host/") else { fatalError() }
let client = WriteFreelyClient(for: url)
client.login(username: "username", password: "password", completion: loginHandler)
Good question! There are definitely some major to-do items that are obvious to me:
WriteFreelyClient
public methodsMostly, though, I'm excited for people to try it out and let me know how it works for them!
One of my goals for 2020 is to share more, and one of the ways I intend on doing this is to take photos more often and share them on Flickr. There's even a daily-photo challenge on Micro.blog to help kickstart that challenge. And since I can just plug any RSS feed into Micro.blog to pull in content, and I can generate Flickr RSS feeds from a given tag
, we're golden! Just add the Flickr feed to Micro.blog, post one photo to Flickr daily with the tag photoblog
, and it'll get shared to Micro.blog (which then cross-posts to other platforms, like Twitter). Great!
Except, right now, Flickr search is broken, so getting a feed of my photos filtered by tag returns… nothing.
But! I can create a Glitch app that uses the Flickr API to pull in my photos, filter them by tag, and generate an RSS feed of them. Yeah, that duplicates the functionality of Flickr's own built-in feed services, but hey, they're broken, and I can make this pretty easily, right? And once search is fixed, I can just turn off the app. It'll be a fun learning experience.
I'm in the middle of working on some other stuff right now. Those projects are far more important and/or time-sensitive, so I add this Flickr feed-generator app to my Someday/Maybe list in OmniFocus; it's neither important nor time-sensitive. Someday/Maybe lists are a collection of “nice to haves” — a backlog of project that you maybe want to do, someday.
A better turn of phrase is the side-project graveyard, as we call these lists on the show.
But the nature of this list, for me, is a little bit more insidious than that. As part of the weekly retrospective that I do, I go over my Someday/Maybe list, automatically bringing every one of those projects to the front of my attention. This routine signal boost makes sure these backlogged projects are kept on the radar.
I have never actually promoted anything from my Someday/Maybe list to an actual project that I tackle.
I have also almost never deleted an idea from my Someday/Maybe list, except during my annual purge.
I have demoted actual projects to my Someday/Maybe list.
I've been thinking about what this does to me. Here's this list of projects that aren't important or urgent enough to take on, but I'm reminded of them week after week. Hey, my system says, don't forget about these things. And so, as I go through my week, my planning is distracted by these ideas. I could be more ruthless about deleting them from the list, but, the fact is:Â I'm a digital hoarder.
So, today, I deleted the Someday/Maybe list in OmniFocus.
For myself, it's probably better to ignore a new idea. I'm too easily pulled off course by the promise of something new and shiny. Going forward, if I think of something interesting to make or do, I'm going to push it aside.
If it eventually comes back, that'll be interesting. But that's not good enough — maybe I turn the idea over in my head a bit more, and write it down in my journal where I'll only see it maybe another couple of times in the year, and then I'm going to push it away again.
But if it comes back to me a third time? That's probably a sign. That's maybe where you decide to create a project for it, either to tackle right away or sometime in the future. It's planned, and it's considered.
The ideas that pester you, that won't leave you alone, those are probably the ones you want to pay attention to. And you can't tell which ones they are, if you're pestering yourself with every idea you have.
More TK.
This site runs a customized version of [Indigo] — essentially, a different colour palette and some custom styling for the [Updates] page. Because of this, it's always been a bit of a headache to update to the latest version of the theme. No more! I'm happy to announce that you can now easily import custom CSS into Indigo.
It's been over 10 months since I [released] my theme for Hugo, called [Indigo].
Some changes have been made since launch, but it always seems to take so much longer to build out new features or fix bugs than I'd like, and a recent [breaking change] in Hugo 0.57 (temporarily rolled back in 0.57.2) that I have to [fix] really drove that point home.
Ash Furrow’s blog is always a great read, and Monday's thoughts on learning from other developer communities was no exception.
[Last week I wrote][last-week] about defining my goals a bit more carefully, making sure that projects I undertake fit who I want to be and how I feel, set in the context of what I’m capable of. Part of that meant making some hard decisions about which projects I'll put in my backlog, and which projects I'll drop altogether. The work I'd started on a [Manuscript integration][mu-integration] is one of the latter.