WHEREAS IT IS AGREED THAT
There exist THINGS which one MUST DO; and There exist THINGS which one WOULD ENJOY DOING; and The above-listed THINGS may be MUTUALLY EXCLUSIVE; IT IS RESOLVED THAT
Where a THING is ENJOYED and MUST BE DONE, one shall REVEL for one can easily give a 💩 about it; and Where a THING is ENJOYED but whose execution is NOT REQUIRED, one shall strive to MAKE THE TIME for it, for it is good to do things one gives a 💩 about; and Where a THING is NOT ENJOYABLE but MUST BE DONE, one shall give a 💩 about executing the THING with CARE AND ATTENTION; and Where a THING is NOT ENJOYABLE and is NOT REQUIRED, one shall strive to ELIMINATE IT from the list of things one invites into their lives, for one should strive to fill their lives with things one gives a 💩 about.
Fun little morning project. 📇📲
(Barcode is blurred because I’m not quite done yet. 🙃) pic.twitter.com/4eXh5NdTCP
— Angelo Stavrow (@AngeloStavrow) May 14, 2016
A couple of months ago I played a little bit with PassKit and Wallet after finding this little tutorial on adding a business card to Passbook (now named Wallet).
A Wallet pass is pretty easy to create—just fill some metadata into a JSON file, create a Pass Type ID certificate in your Apple Developer account, and then run a signing utility.
There’s a new kid on the XCTest block, and its name is XCTAssertThrowsError.
I haven’t been able to find much on its usage aside from its original discussion on the swift-evolution mailing list and a Stack Overflow question, so here’s a little bit of a discussion on how I’m using it in a new project of mine.
Swift introduced some pretty neat error handling in 2.0, and Natasha the Robot provided a nice guide on how to throw an error in your code.
In moving this blog to a static site generator, one concern was whether I’d still be able to work on and/or publish a post from my phone. I tend to do a fair bit of mobile drafting while I’m in the subway or waiting in line, and will sometimes publish content when I’m away from my computer. YOLO.
Requirements It’s a given—since that’s how the site has been setup—that you need a GitLab.
As I mentioned last week, today is July 1st, which marks a convenient half-way point for the year. On New Year’s Day, I posted a short list of goals that I was hoping to make progress towards. Here’s how it all breaks down.
1. Post something here every Friday. So far, so good. I haven’t missed a single week, which I’m pretty pleased with. I’ll grant that it hasn’t always (ever?
Reminder: as of next week, the RSS feed for this site is moving! If you subscribe, please be sure to point your favourite reader to:
Next week is July the first. It’s Canada Day here, which means it’s a national holiday, but in Montreal, it’s also an unofficial moving day.
So it’s a propos that this site will be moving over to its new digs on that same day.
This week, I took a hiatus from the refactoring fun I’ve undertaken to (finally) move the blog over to a static site generator.
I’ve written before about my plans to move to Hugo, and that’s now complete. Since the beginning of the year, all posts have been written as Markdown files that I can easily grab and format with the necessary front matter. Before then, I hadn’t written very much, and in fact I’ve dropped a couple of old posts that I felt didn’t add to the site in any way.
I’m in the process of (finally) finalizing the move of this site to Hugo.
No, for real.
Most content is already in place. A few older posts need to be added, and some info pages are to be added. This is normal-priority.
I’m using a slightly-modified built-in template to render the site. There a few more modifications to make, but this is low-priority.
A commenting platform will be added. This is also normal-priority.
The Great HoneyJar Refactoring is a series of posts in which I take the first iOS app I ever wrote, HoneyJar, and refactor it out of its original burning-dumpster-fire state and into a modern app. And I'm doing it in public. Earlier this week, I tweeted about my adventures in trying to add a test suite to HoneyJar.
The idea is this: I want to be sure that I’m not breaking anything in the app, as it exists right now, when I start refactoring.
The Great HoneyJar Refactoring is a series of posts in which I take the first iOS app I ever wrote, HoneyJar, and refactor it out of its original burning-dumpster-fire state and into a modern app. And I'm doing it in public. Last week I introduced an idea I had: to open-source my first-ever iOS app, embarrassing as it might be, and refactor it out in the open.
Over the last week, I handled the open-sourcing of the app.
Tinkerer with a strong interest for development, of both the personal and software persuasion; easily defeated with spatulas. Equal measures enthusiasm and concern for tech's effect on the world. He/him.