There’s a small mountain near me that I’ve probably summited dozens of times so far. I don’t keep track but I’ve always been curious about the exact number. Let’s find out.
The mountain in question is the Brocken, with 1141 meters the highest peak in the Harz mountains. In this post, we’ll determine the number of times I’ve successfully climbed it by analyzing all my Strava activities. To date, I have about 800 runs, hikes and other activities logged on there.
An activity is represented by a polyline of geographical coordinates. The summit is represented by a polygon. In particular, we’ll use a circle with a radius of 350 metres around the peak (marked red in the images). This is large enough to account for inaccuracies in the GPS data.
Split Activities
An activity that starts directly at the summit is not counted as a successful summit. This is in response to activities where I logged ascent and descent separately. For example, I would run up the mountain, take a lunch break at the top and hike down later. If we were to treat the two parts separately, we’d risk overcounting the number of summits.
Multi-Summits
Multiple summits within a single activity are counted individually. Hey, if I put in the effort, I want to see it reflected.
We need to define some criteria for what constitutes a valid subsequent summit. Going down a few metres from the peak and right back up is probably not sufficient. To make it simple, we’ll use a second circle with an arbitrary radius of 3 kilometres around the peak. The boundary of this circle must be crossed between one successful summit and the next.
One activity with two summits. Right: Between the two summits, the activity reaches over the required 3 km away from the peak, marked by the outer circle.
Finding Summits
The basic idea is straightforward: If an activity contains a summit, its polyline must intersect the summit polygon. However, this alone is not enough as it does not account for multiple summits within a single activity.
To do that, we need to take a closer look at the individual segments of an activity. We obtain these segments by splitting up the line along the boundary of the summit.
Consider the following activity:
A schematic view of an activity. Right: The activity split into line segments by the summit polygon.
The activity crosses in and out of the summit three times. Cutting the activity along the summit boundary leaves us with seven individual line segments (the three inner ones included).
Of these, we can identify four different types of segments by where they lie in relation to the summit. The two interesting ones here are:
Start segment: Its end point lies on the summit’s boundary. The rest lies outside the summit.
Loop segment: Both its start and end points lie on the summit boundary. The rest lies outside the summit.
A start segment itself marks one successful summit. A loop segment marks a summit only if it is not completely contained by the outer boundary circle. The inner and the end segments can be disregarded.
As such, the activity above contains two successful summits.
We repeat this process for every activity and sum up the results to arrive at the total number of valid summits.
Implementation
I implemented the algorithm using the spatial analysis package turf.js. To get the input data, I first wrote a script to batch download all my activities from the Strava API and convert them to GeoJSON.
Results
All 57 identified summit activities.
Here is what the script spit out:
Total number of activities: 777
Total number of summits: 60
Activities with summits: 57 (48 runs, 9 hikes)
Shortest: 8 km, longest: 59 km, mean: 21 km
Lowest elevation gain: 363 m, highest: 1881 m, mean: 719 m
60 summits is a respectable number if I say so myself.
Only three of the activities contain multiple summits. I actually expected there to be more. This is a consequence of our choice of 3 kilometres for the outer perimeter between subsequent summits. If we reduce the required radius by just 100 metres, the number of valid summits increases to 64.
Also captured: my preference of trail running over hiking.
I wanted to have this done a while ago. When I first made this site, I threw it together in haste and hesitated in putting it out there. I finally got around to cleaning up the site, properly putting it under version control and updating the deployment process.
There’s still not much to this website. It is a handful of text files and images, some HTML, CSS and a config file mashed together with Jekyll to produce what you see here.
Anyway, it’s done: The repository is on GitHub. If you find any typos or errors, feel free to open an issue or submit a pull request.
What do you do when you look for a niche app with a specific set of requirements but can’t find one that you like? You make a Workflow.
This workflow does one thing: It tells you when it’s going to be dark outside today. By dark I don’t mean sundown, I mean dark dark or Civil Dusk. I wanted this for when I plan my evening activities. Mostly it’s about finding a good running or walking route for the amount of daylight left.
The apps I tried missed the mark in several ways:
No widget: This is a prime use case for a widget. Glance at some information and done.
Only sundown: Many apps included sunset and sunrise, not many the stages of twilight.
Cluttered: Many apps had a specific focus such as photography or fishing. As such, when they did include the time of darkness it was drowned out by other irrelevant information.
The workflow, on the other hand, does everything I need perfectly. It instantly replaced the app I previously used for this niche use case. Which really is a testament to the importance of Workflow for the iOS automation environment. Now that it’s acquired by Apple, I hope it sticks around for as long as possible.
The solar data is obtained from the Sunrise Sunset API. To speed up the result, I hard-coded the location in the workflow. Alternatively, you could let Workflow geolocate you dynamically on every request.
I don’t use a lot of shortcuts. I know a core set I for my most used applications but that’s about it. My problems with shortcuts are:
There are too many to remember.
They are not unique. Collisions happen resulting in nothing or possibly the wrong thing.
They are abstract and do not describe the actions they represent.
The last point is key. I associate actions with names, not with symbols. Names can be remembered and searched. And the best thing is actions with names can be triggered with a search.
Searching the Menu Bar
Getting to the point: I don’t see too many people searching the menu bar on macOS. It’s a fantastic feature. Instead of either remembering shortcuts for items or digging through the various menus by hand, just search for it! It’s incredibly convenient and very fast.
Ideally, you’d set up a shortcut for this, for me it’s ⌥⌘?. This one shortcut is your gateway to all others. You can set up the shortcut in System Preferences > Keyboard > Shortcuts > App Shortcuts > All Applications > Show Help Menu.
Using Alfred
A great alternative is Alfred with the Menu Search workflow. It displays the menu items right within Alfred. This one is completely without shortcuts. Since I’m not a fan of unclear abbrevations either, I renamed the command from the default m to menu.
Actions
This is the preferred way of computing for me. Thinking in terms of actions and names. Just type what you want to do and do it. The barriers to entry are low, the intentions are clear and the results predictable. Granted, shortcuts are a lot faster when mastered. But the investment is high and results volatile when you switch between a lot of applications.
Quiet Links is my answer to the Wikipedia Rabbit Hole. It is a stylesheet to quiet down links on pages to help you focus on reading.
Look at a typical Wikipedia article:
The stylesheet in action
There is too much noise to stay focused. Sometimes, I can’t even make it past the first paragraph before getting sucked into all those links. It’s fascinating information, yes, but it is not what I am after. After applying the stylesheet, the page feels markedly calmer and easier to read.
Admittedly, getting distracted by links sounds more like a me problem and not a Wikipedia problem. In either case, the stylesheet solves it. It started out as an experiment but I was surprised how much of an effect it had on my reading. I still use it regularly.
Installing and Using
The stylesheet is not designed to be used permanently across the web. On some pages, it may interfere with the native CSS and things can look weird. For reading individual long-form articles, especially on Wikipedia, it is perfect though. Enable and disable it on a per-site basis.
In case you do need to follow links, you still can. If you hover over the text, you’ll find that links are still discoverable and clickable. There’s also a hard mode which disables links completely.
Update December 2016: This feature finally made it natively into Hacker News. This userscript is now obsolete.
This userscript adds a button to a Hacker News comment site to bring you back to the full thread.
It’s a head scratcher how this is not an existing feature on the site. The comment detail pages include no context as to which thread they belong to. Not even a title is included. When you land on a single comment from a Google Search, you’re pretty much stranded.
The only thing way out is to repeatedly click the little parent button until you reach the root of the thread. The first iteration of the script did exactly that: It repeatedly scraped the preceding comment’s page for the next URL. Later I learned about the Hacker News API but the API is limited so the process pretty much remained the same.
For a quick pick-me-up, I sometimes browse the catloaf forum. At catloaf is a cat that looks like…a loaf. There is just something special about those goofy cats.
The problem is the catloaf forum’s post volume is rather low which means I’ve most likely seen the most recent posts. Also, there’s just the general hassle of opening the website and navigating the forum. Too slow. I wanted to speed up my catloaf delivery for when I need it the most.
Solution
My solution was to set up an instant catloaf delivery system. It comes in two parts:
This IFTTT recipe grabs any new image from the forum and saves it to a folder in Dropbox.
This iOS Workflow fetches those images and displays them in random order.
In the end, I just open the workflow and boom, a random bunch of loaves. It’s silly but it works.
Catloaf delivery in action.
Improvements
Currently, only the images without any context are saved to Dropbox. It would be nice if I could see the title and maybe a link back to the forum thread.
To reduce the volume, you could also modify the recipe to only add new hot or top posts instead of all new posts.
