I wrote a Slack bot, ReadBot, to both scratch an itch and check out the current state of Slack integration. As a bonus, I got to spend some time getting familiar with Glitch, a pretty cool live coding platform.
ReadBot lets you connect your Goodreads and Pocket accounts to Slack, and then adding a bookmark (š) reactji to a message with an Amazon book link in it will add that book to your Goodreads āto-readā shelf, or any other URL to your Pocket account.
The Slack API and documentation has improved immensely since I last checked it out a couple years ago. I was clearly not the only one to get confused by profusion of integration options (bot? slash command? webhook?) , so theyāve improved their API landing pages to help guide you. There are also plenty of tutorials to get you started.
One of the fears when diving into an API integration is whether that APIāor even integrations in generalāare going to be supported in the future. Many developers have been burned by neglected, deprecated or even shutdown APIs. Slack, however, seems to be encouraging integrations whole-heartedly with its app directory.
One challenge of creating a new Slack integration has been Slackās requirement that it be served over SSL. While Letās Encrypt has made this a lot easier, setting up an SSL-enabled server is still a significant hurdle to clear just to start developing your integration. This is where Glitch comes in.
Glitch is a collaborative live coding environment made by Fog Creek Software. Itās super easy to get started, especially since you can find existing public projects on the site and āremixā them to make them your own. And every project has its own SSL-enabled hostname, right out of the box.
Glitch apps are Node.js-based (they seem to allow Python apps as well, but support is currently unofficial). The app restarts itself on the fly as you edit (although this can be disabled), so your app is always live. Autocomplete package search makes installing new packages a breeze. You can do pretty much everything you need to through the UI, but if you need, you can drop into a shell and do whatever you like to your instance.
Thereās no built-in revision/commit history, but you can export your project to GitHub (as well as import from GitHub). Since your app is just a regular Node app, itās perfectly portable to any other environment.
One general issue with writing Slack bots is that in order to continue working on your app after it is in production, you need to have separate development apps and endpoints. It would be nice if Slack made this a little easier, perhaps by allowing you to specify separate production and development endpoints, slash commands, etc.
I have no plans on publishing ReadBot to the Slack App Directory because I donāt want to have to maintain another production service. If youāre interested in doing so, go for it.
I recently got a new monitor and it came with a problem. For some reason when I attached or detached my laptop, many of my windows would end up off the edge of the screen, and Iād have to drag them back over one by one. It was annoying enough that I decided Iād write an app to ārescueā them.
I figured it wouldnāt be too hard. Get a list of active windows, see which are off-screen, and move them over. But it was hard. My code only half-worked. And for some reason I couldnāt get Chrome windows to move.
I started looking around and found Swindler. It seemed to be just what I needed and confirmed that I wasnāt completely incompetent:
Writing window managers for macOS is hard. There are a lot of systemic challenges, including limited and poorly-documented APIs. All window managers on macOS must use the C-based accessibility APIs, which are difficult to use and are surprisingly buggy themselves.
But then I saw Hammerspoon listed at the bottom of the Swindler README, under Related Projects. Intrigued, I checked it out. It was just what I needed.
Hammerspoon lets you write Lua scripts to interact with the MacOS system, and itās pretty powerful. The Getting Started Guide gives a good sense of some of the things you can do with it.
Iād never written Lua before, but with plenty of examples to crib from and good API documentation, it didnāt take me long to come up with a little script that did just what I needed:
I have that file saved at ~/.hammerspoon/rescuewindows.lua, and in ~/.hammerspoon/init.lua I have:
local rescueWindows = require "rescuewindows"
hs.hotkey.bind({"cmd", "alt", "ctrl"}, "R", rescueWindows)
So when it hit āā„āR, all my off-screen windows slide over to my main screen. Nice!
When my friend Nelson and I set out to build our location tracking app & accompanying website, Wanderings, we started down the familiar path of choosing our stack. Flask seemed like a reasonable choice. Postgres for the database. SqlAlchemy for the ORM? Sure, I guess. We figured weād try hosting on GCP, mostly to learn more about the platform. Do we bother with containers? Meh, leave those for the youngsters. And so on.
But the more we thought about hosting our own service, the less enthused we were. The GCP costs were piling up, and we didnāt really want to be responsible for having a copy of our usersā location data. One of the driving ideas behind Wanderings was having a location tracker where you controlled your own data. Why should you trust us with a copy of it?
I should back up and talk a little about what Wanderings is and how it works.
Back in 2011 there was a small uproar when it was revealed that Apple was apparently tracking your every move with your iPhone. Out of that grew a project, OpenPaths, that allowed you to generate your own location data, and have full control over it. The app used very little energy, so you could just start it and forget it.
However, with the release of iOS 11, OpenPaths stopped working, and its accompanying website, openpaths.cc, no longer resolved. It appeared to be no longer maintained. There were some other location tracking apps out there, including Google Timeline, Fog of World, and Strut, but none that had the combination of strong privacy guarantees , simplicity, and low-energy usage that we were looking for. So we decided to make our own.
The Wanderings iPhone app is pretty basic. It uses iOSā significant location change service to only update your location when you move by a significant amount. It also relies on wifi and cellular for location information rather than power-hungry GPS. It does all this in the background, so you can start it once and forget it.
New location data is uploaded to your private, secured CloudKit database on iCloud, so you are the only one with access to your data.
So back to our server conundrum.
One of our requirements was a website that would render the full heat map of your travels, let you export that data, and eventually let you do a lot of interesting things with your data. Of course, it doesnāt make sense to re-download all your location data every time you visit (especially since CloudKit only lets you pull 200 records per request) so we needed some kind of cache of your data in the app, as in a database.
But we donāt really want your data. And we really donāt want to deal with maintaining a server somewhere, either.
Fortunately, for a few years now browsers have supported IndexedDB, an embedded transactional database with sizable storage limits. We realized if we used this as our cache, the app could be a static site (something Nelson had explored years ago), which we can host cheaply anywhere. In fact, we ended up just using GitHub Pages to host the site right out of our repository.
Using a browser-embedded database has the downside of having to re-download all your data when you go to a new browser or if youāve cleared your cache, but we think thatās an acceptable trade-off to have complete control of your data.
So check it out and let us know what you think. Send your bugs/feature requests/love to support@wanderin.gs.
The file prefixed with ā._ā is problematic and a was the result of copying certain Mac OS X files to a non-HFS+ formatted disk. These files are referred to as Dot files, Apple Double files, or resource forks. They are invisible to Finder but can be removed using the dot_clean utility.
I wrote a Mac menu bar app for internal use at Etsy that show the status of a number of internal systems and pops up a notification if any of them change statusāfor example, if a problem is detected and someone puts a hold on our deployment queue.
Some months ago, a colleague noticed the app was leaking memory. I put off looking at it until recently, when I noticed that my own instance was eating up 3+ GB of memory.
Fortunately, Apple provides some great tools for tracking down leaks. One is Instruments, an incredibly powerful tool that I know thiiis (puts thumb and forefinger a millimeter apart) much about. But I know enough to inspect a process for leaks.
I started Instruments, selected the Leaks profiling template, and attached it to my leaky app, and saw this:
Yup, thatās a leak. You can also drill down to see where the leak is coming from:
So the leak is obviously in the networking code, seemingly in Appleās part of it.
I should pause here to say a bit about how the app works. Itās pretty simple: every 3 seconds, it fetches an internal status web page, parses out the statuses from an HTML table (writing a JSON endpoint for the status page is on my todo list!), and updates the menu accordingly.
The networking code in the app was pretty simple:
letsession=NSURLSession.sharedSession()lettask=session.dataTaskWithURL(url){data,response,errorin// check for error, do something with the data}task.resume()
NSURLSession was introduced with in Mavericks and iOS 7 as a replacement for NSURLConnection.
I tried setting the cache sizes to 0, and invalidating the session when I was done, as recommended in this article, which seems to describe the same leak:
// THIS CODE DID NOT HELP!letconfiguration=NSURLSessionConfiguration.defaultSessionConfiguration()configuration.URLCache=NSURLCache(memoryCapacity:0,diskCapacity:0,diskPath:nil)letsession=NSURLSession(configuration:configuration)defer{session.finishTasksAndInvalidate()}lettask=session.dataTaskWithURL(url){data,response,errorin// ...
But this didnāt help. What did end up working was using an ephemeral session:
With that in place, hereās what Instruments showed me:
Yay! No leaks!
We Donāt Need No Stinkinā GUI
If youāre more of a command-line gal, thereās another way to investigate leaks built into OS X: the leaks command:
$ leaks EtsyInternalStatus
Process: EtsyInternalStatus [24147]
Path: /Applications/EtsyInternalStatus.app/Contents/MacOS/EtsyInternalStatus
Load Address: 0x105eaf000
Identifier: com.etsy.EtsyInternalStatus
Version: 1.2.3 (1.2.3)
Code Type: X86-64
Parent Process: ??? [1]
Date/Time: 2015-09-02 20:33:26.173 -0700
Launch Time: 2015-09-02 20:30:44.447 -0700
OS Version: Mac OS X 10.10.5 (14F27)
Report Version: 7
Analysis Tool: /Applications/Xcode-beta.app/Contents/Developer/usr/bin/leaks
Analysis Tool Version: Xcode 7.0 (7A192o)
----
leaks Report Version: 2.0
Process 24147: 25225 nodes malloced for 15639 KB
Process 24147: 615 leaks for 5321984 total leaked bytes.
Leak: 0x10a02f000 size=135168 zone: MallocHelperZone_0x105f65000 length: 5020
...
<snipped 7800 lines of leaked memory dumps>
Now, the fixed version:
$ leaks EtsyInternalStatus
Process: EtsyInternalStatus [85066]
Path: /Applications/EtsyInternalStatus.app/Contents/MacOS/EtsyInternalStatus
Load Address: 0x102d2f000
Identifier: com.etsy.EtsyInternalStatus
Version: 1.2.4 (1.2.4)
Code Type: X86-64
Parent Process: ??? [1]
Date/Time: 2015-10-10 10:27:29.556 -0700
Launch Time: 2015-10-10 10:16:11.476 -0700
OS Version: Mac OS X 10.10.5 (14F27)
Report Version: 7
Analysis Tool: /Applications/Xcode.app/Contents/Developer/usr/bin/leaks
Analysis Tool Version: Xcode 7.0.1 (7A1001)
----
leaks Report Version: 2.0
Process 85066: 62741 nodes malloced for 6598 KB
Process 85066: 0 leaks for 0 total leaked bytes.
The eagled-eyed among you might have noticed that about a month elapsed between me running those checks (life intervened), and there was an Xcode release in the meantime. Turns out that when I ran the leak check again on the leaky version of the app, it was fine! Iām guessing that it was a bug in Appleās networking code after all, and it got fixed in the latest release.
Try out leaks on some of the other apps you have running. Youāll find that leak-free apps are oddly rare, and some are downright eggregious (my beloved Sublime Text text editor, in which Iām writing this post, shows ā577841 leaks for 44554352 total leaked bytes.ā Oof).
One of our requirements was a website that would render the full heat map of your travels, let you export that data, and eventually let you do a lot of interesting things with your data. Of course, it doesnāt make sense to re-download all your location data every time you visit (especially since CloudKit only lets you pull 200 records per request) so we needed some kind of cache of your data in the app, as in a database.
