The Idaho backcountry is an intimidating place, and rightly so. Many of the destinations there are unforgiving airports with little to no margin for error. The reward for developing the needed skills to fly here is operating in one of the most scenic and remote areas in the continental US. The most challenging strips are generally not accessible to those without a STOL plane and a good amount of experience, but for pilots looking to dip their toe into the backcountry, there are some options that are accessible to your run of the mill GA plane in addition to a reasonable amount of mountain flying training.

The airports listed here (in no particular order) are some of the more accessible airports in the Idaho backcountry. This means those with longer runways and more forgiving approaches that you don’t need tundra tires and a 500ft takeoff roll to land at. All while still being some incredible destinations that makes flying GA worth it.

Last year I wrote extensively about the politics of ski areas in Washington and a vision for the future of skiing in the PNW. One of the topics that came up in both of those posts was Mt. Pilchuck. Namely its history as a ski area and the potential it has for the future. This made me want to explore more on the possibility of reestablishing winter access to Mt. Pilchuck.

First off, for readers who know the history of Pilchuck, this is not a post about re-opening the lift-served ski area that was once the Mt. Pilchuck ski area. The proposal being made here is more modest: specifically reestablishing winter access to the previous ski area parking lot and current summer trailhead. Yup, that’s it. Doing that alone could have a material impact on expanding winter recreational access in the Snohomish county area through expanded high elevation snow access for ski touring, snowshoeing, sledding, and general snow play areas for families.

Here’s a problem: You have 20,000 records each with latitude and longitude coordinates. You want a search function for these records to show the results closest to the user’s current position on a map. What do you do?

Thanks to Postgres’ full text search and Earthdistance extension we can implement this logic entirely in the database and it’s lightning fast to boot.

This is exactly the problem I had when I was working on my recent project Pirep. The core functionality of the website is based around a map which displays ~20,000 airports in the US provided by the FAA’s database. The map has a search feature on it and I wanted it to display results based on the area the user was looking at on the map. For example, searching for Portland when looking at New England would return the Portland, Maine airport rather than the Portland, Oregon airport even though Oregon would likely be the more common result given it’s a larger city.

As far as searching goes, given a database with all of the airports in it, indexing by airport name and location isn’t difficult. The difficulty comes in when trying to rank search results based on the proximity to the user’s current location. It’s not exactly feasible to read every record, calculate its distance to the user, sort by distance, and then take your search results in realtime. You could conceivably index airports by their state and only return results from the same state as the user then calculate distance on those results and sort by that. That may be a “good enough” solution, but in my case I wanted, for example, a search for port when looking at the south Puget Sound to return Port Orchard, WA at the top of the list instead of the further away Port Angeles, WA. Thanks to the Earthdistance extension it’s possible to do this type of calculation entirely in the database and in realtime.

I dislike Webpack. I even more strongly dislike Webpack when integrated with Rails. My prior experience with it has always been one of those tools that when it works silently in the background doing what you expect it’s fine, but when it doesn’t do what you expect, well, there goes the rest of your day debugging it and endlessly tinkering with obscure configuration files. Then again, JavaScript in general has never been my forte, but all the more reason for a desire to not have JavaScript tooling continually get in the way of focusing on my actual application.

Regardless, when I started work on my recent project, Pirep, circa two years ago I read about a new gem installed by default with Rails 7 applications: importmap-rails. It described itself as such in its README:

You can build modern JavaScript applications using JavaScript libraries made for ES modules (ESM) without the need for transpiling or bundling. This frees you from needing Webpack, Yarn, npm, or any other part of the JavaScript toolchain. All you need is the asset pipeline that’s already included in Rails.

All of this was absolute music to my ears. I instantly adopted it into my application and forwent any type of JavaScript build system. And it worked wonderfully. There was one rough edge, however: third party dependency management.

Recently I launched the initial version of Pirep, a collaborative website for pilots to collect & share their local knowledge about airports such as transient parking location, crew car availability, nearby attractions/restaurants, camping information, etc. The central component of Pirep being the map page where airports are charted and filterable based on what amenities exist at them.

While it’s easy to get a map with satellite imagery, naturally one would also want the FAA VFR sectional charts as a layer on the map as well. This turned out to be fairly easy to get a proof of concept for, but much more tedious to get to a production-ready state.