Introduced an abstraction class to enable default filtering on contents only visible within the view port of the Garmin OneHelm Canyon Runner app.

Process

This was a fun problem to think through. After porting the functionality to the new Typescript codebase 1:1, I started testing various new overlays we introduced to the map. They loaded fine, but were laggy and made the Garmin go unresponsive for seconds at a time. I knew there had to be performance optimizations to be made by restricting the overall number of waypoints, but I didn't want to create these optimizations on a per-module basis. I created a basic proof of concept view port filter that takes any dataset containing coordinates, and returning it filtered for only items currently being viewed on the leaflet map.

Claude Information Gathering

To confirm the abstracting I created was going to be applicable across the code base, I utilized Claude to outline the functionality of the legacy code base, and compare it against our re-worked version. Seeing the repeated patterns, I worked through a series of updates to the PoC in order to make it more universal and extendable.

Performance Impact

By implementing the filter, we were able to stabilize load times and reduce the overall hangups the Garmin experienced. The above screenshot depicts our performance testing, with the largest peaks occurring before we introduced this filtering (around the 766 mark).

Extended xptracker's existing LLM functionality by introducing new ability to offer feedback on resume components, career journal entries, and a new upskill plan on the job matching board that outlines where your skill gaps are (according to your job matches only).

Privacy

While we try and do our best to de-contextualize your data when we send it (we don't send identifiers or your personal information), there's inherently a risk when sending data to any 3rd party provider. We're actively researching ways to further mitigate this risk, but it's one of the key reasons we use the color "violet" to denote anything that uses AI on the backend in xptracker. If you'd rather avoid the risk, you don't need to use this functionality (in fact a future update will let you disable these AI-assisted feature buttons entirely).

Access

These features are all currently in testing, but founding members should have early access to preview these features now. In the next few week's we'll be rolling out the features to the public once we're sure they're up to our standards and free of any bugs or logicy UI/UX gaps.

Upskilling Plan

This is the most exciting feature out of this release (in my opinion). It uses your job matches to determine what your top-most missed skills were. It then offers up suggestions on various experiences to write about in case you may already have that experience, but haven't introduced it to your resume yet. This will be part of a larger feature-suite rolling out in the future. One I'm super excited to share more details on. For now, this upskilling plan serves as a preview of some of the grander visions we have to help you land a job.

Working on a new data pipeline for finding and ingesting public job listings that then get matched to xptracker users by relevance. The feature is currently in beta, but the above screenshot offers a little sneak peak!

General Process

The overall pipeline covers several steps:
- Download public listings via publicly accessible API's.
- Store their various meta fields, whatever is available.
- Enrich stored listings using a lightweight AI model (like Claude's Haiku).
- Compute job matches to users with access to this feature.

Cost Cutting

Anything that uses LLM models in this way is bound to introduce an upfront cost, that's why we introduced checks into the pipeline that only poll for and tailor results to users who have access to this feature. Anything with heavy AI usage on xptracker will require a subscription to access in the future.

Optimized processing of encoded tile data on the Garmin OneHelm Canyon Runner app by utilizing onboard proxy server caching capabilities. Reducing cursor and touch event listener counts, offloading data-storage off the device to continue working within the 150MB memory limit, and targeted-access of per-pixel data to return the SST/CHL reading from a WMS PNG tile on click. Utilized a new local performance tracking server to track performance optimization change effects on the device.

Garmin OneHelm <--> Proxy Server <--> HTTP Requests

What's in the encoded data?

Depends! We can store sea surface temperature readings, chlorophyll concentrations, salinity, and so on. So basically, just raw data. We process satellite files from known databanks to create mapping tiles with this data so we can decode them on the front-end. We have 3 channels of 8-bit data to work with, so if we're trying to store, say, the logarithmic-scaling dataset for Chlorophyll concentrations, we can normalize the single concentration value to 24-bits before we distribute those bits across each 8-bit channel.

Introduced Loran lines for the Garmin OneHelm typescript application. Introduced various performance enhancements to reduce about 1kb of memory overhead to keep the application in-line with the OneHelm 150MB spec limit. Hyper-optimizations included reducing forced SVG layout counts from 2400 to 300, text alignment map pings from 600 to 300, and removed all 2100 event listeners entirely to reduce overhead further.

Event Listeners

Typically no one has to think about the overall number of web listeners their creating on their web page. Any modern device can support way more than even the most poorly optimized sites can truly throw at it; however, that's not the case for the Garmin device, which only allots 150MB of total RAM to any given OneHelm app. Removing the 2100 event listeners caused a noticeable drop in bootstrap times, and improved overall responsiveness (which unfortuntaely is still a work in progress overall).

Developed the Canyon Runner map's app from the ground up to support older webkits running on marine devices such as the Garmin OneHelm device. Created a custom lightweight typescript framework to help facilitate the 150MB RAM restriction onboard the device, and introduced countless performance enhancements to improve feel and responsiveness. Included a build and compile pipeline to auto-deploy the newly reworked app.

The typescript framework makes use of recurssive enclosures to create a more verbose and implied form of coding. For example:

CR           # Canyon Runner - Global Object
CR.MAP       # Map Module

Each module creates it's own logging handling and hooks into a global performance logging system. So for debugging on the out-dated Garmin webkit, we can access a log of all functions invoked and roughly at what time via:

CR.MAP.log("...", {...params}) # Logs only if running in _debug enabled environment.
CR.MAP.printLogs() # Prings all of the modules logs as a table.

Integreated the ATProto OAuth protocol to xptracker, authorizing only the scopes that are required for functionality.

Added (anonymized) metrics gathering as a “pro” feature to xptracker. Allows users to see number of visitors to their resume and career journal, as well as track which labels people are most interested in.

Developed the label generator and auto-labeler for xptracker. Keep it a secret though, it’s currently restricted to select users only while undergoing testing. ;)

Introduced the new more welcoming onboarding workflow to xptracker, including the option to automatically parse an uploaded resume.