{ "version": "https://jsonfeed.org/version/1", "title": "programming on jocmp", "icon": "https://avatars.micro.blog/avatars/2026/14/52207.jpg", "home_page_url": "https://jocmp.com/", "feed_url": "https://jocmp.com/feed.json", "items": [ { "id": "http://jocmp.micro.blog/2026/01/19/mercury-parser/", "title": "Mercury Parser 3.0.0", "content_html": "

In 2024 I forked Postlight Parser to use in Capy Reader and returned the name to Mercury Parser. I really, really wanted to use the upstream version of the parser to avoid maintaining something off to the side. But nearly two years on, I feel I made the right choice for the scope of the app.

\n

That’s why I’m happy to announce Mercury Parser version 3.0. My fork of this project follows romantic versioning, or romver meaning that version 3 represents a major overhaul to how the project is developed.

\n

For starters, the app no longer uses jQuery. The previous version of the app used jQuery for the web-based version of the parser. This was completely removed by upgrading Cheerio to the latest version. Cheerio is responsible for much of the parsing in Mercury Parser and follows a similar interface to jQuery, just without the jQuery.

\n

Next, I replaced moment.js with dayjs for article date handling. This was another necessary shift since moment.js had been deprecated for several years. The shift was mostly one-to-one but there were a few trade-offs. Date patterns like DD are now replaced by D which was something lenient in moment.js. Date boundaries and timezone suffixes were also changed. This required manual code in the date-published cleaner.

\n

I also migrated from Karma for web tests to Vitest with Playwright. For now this means that the fixtures are only tested in node due to the constraint of the node-only fs import. This is something I may revisit in future for broader test coverage. Lastly, I migrated the project from yarn v1 to npm. There’s safety in defaults, and npm has come along way with performance since Mercury Parser launched in 2016.

\n

All in all, these changes have been easy to manage because my fork of Mercury Parser is a hobby project. There’s no stakeholders, no mission critical applications. That, and Claude Code Opus 4.5 is just leagues better than me at catching package conflicts. It’s been a fun journey to continue to revitalize this project in my spare time and use it in Capy Reader.

\n
\n

If you use this fork and have feedback, let me know! If you use the full content extractor in Capy Reader and enjoy its benefits, consider sponsoring my efforts on GitHub or Ko-fi.

\n", "date_published": "2026-01-19T16:48:11-05:00", "url": "https://jocmp.com/2026/01/19/mercury-parser/", "tags": ["programming","mercury parser"] }, { "id": "http://jocmp.micro.blog/2025/08/08/demo-mode-for-ios-simulators/", "title": "Demo mode for iOS simulators", "content_html": "

I was in search of a better way to take app screenshots. Typically you have two choices: use a physical device or a simulator. Physical devices are fine for a realistic display, but you can’t control the time or the radio indicators. No one wants to see just two bars of service on a screencap. iOS’ default simulators don’t even show the service indicator.

\n

Luckily the first result I came across was a post from Jesse Squires from 2019. The following command will override the current simulator with full service and the iconic 9:41AM time.

\n
xcrun simctl status_bar booted override --time "9:41" --dataNetwork "wifi" --wifiMode active --wifiBars 3 --cellularMode active --cellularBars 4 --batteryState charged --batteryLevel 100\n

The end result looks like this.

\n\n", "date_published": "2025-08-08T15:17:51-05:00", "url": "https://jocmp.com/2025/08/08/demo-mode-for-ios-simulators/", "tags": ["programming","mobile development","ios"] }, { "id": "http://jocmp.micro.blog/2025/08/02/capy-log-open-in-browser/", "title": "Capy Log: Open In Browser, Article List Tweaks", "content_html": "

Summer in the midwest is careening towards autumn, and version 2025.08.1153 of Capy Reader is in review for the Play Store. I haven’t been adding huge feature changes lately. Instead, I’ve been trying to pick apart the app and understand some underlying jank that exists. More on that later. While there aren’t huge changes in this release, I did get around to adding “Open in browser” as an option to view articles.

\n

Open In Browser

\n

“Open in browser” by default has been a long outstanding feature. It was first requested in January of this year. I feel bad sometimes when there’s a huge delta between time requested and time implemented, but I spent a lot of time waffling on this feature.

\n

It’s deceptively simple but the “open in browser” requires two key expectations

\n
    \n
  1. The article opens in the browser
    2. \n
  2. The article is marked as read
    3. \n
\n

This second expectation prevents a direct call to an ACTION_VIEW intent since there is not a way to simultaneously launch two actions from a widget RemoteView. The trade-off then is to create a trampoline activity which first opens the app with a transparent view, and then opens the browser. The trampoline activity can be avoided when the “open in browser” action is initiated within the app since the article state is already within context.

\n

Putting it all together, the new “open in browser” feature in Capy does what it says on the tin:

\n

\n

Feed Selection UI Improvements

\n

One outstanding problem in Capy Reader has been feed list transitions. To spot the bug in previous versions:

\n
    \n
  1. Scroll part way down a page, note the status and toolbar change color
    2. \n
  2. Open the feed list and select another feed
    3. \n
  3. Jank! The previous article list will scroll - or teleport - to the first index, and then the next feed will load in
    4. \n
\n

Here’s an example of the problem at 4x speed. The top bar state jank is noticeable at the 10 second mark when it still appears as the changed color when the list has already switched to the next feed.

\n

\n

The solution I found was to rebuild the article pager in the view layer. This in turn invalidates the list state which simultaneously invalidates the scrollbar state.

\n
import androidx.paging.Pager\nimport androidx.paging.PagingConfig\n\n// In View Model\nfun buildPager(): Pager {\n    return Pager(\n        config = PagingConfig(\n            pageSize = 50,\n            prefetchDistance = 10,\n        ),\n        pagingSourceFactory = {\n            findArticles(...)\n        }\n    )\n}\n\n// Pager is now in Compose view layer\nval articles = remember(...) {\n   viewModel.buildPager(...)\n}\n

The last wrinkle with this approach is pager updates in response to in-feed actions. One example of this is swipe-to-refresh on the “Unread” filter. When the refresh finishes, articles that have been read disappear. If the invalidation flag - in this case a timestamp - is passed to the remember function then the feed will flash causing the list to flicker and jump back to the first index. Instead the solution is to track a separate variable within the view model. When the timestamp changes, the view-level articles variable is refreshed which triggers a new call to the pagingSourceFactory.

\n

Here’s a demo putting it all together:

\n

\n

Something so subtle that you might not have even noticed, but your brain did.

\n

What’s next

\n

In the next few updates I hope to add more settings around “open in browser” based on early feedback. Additionally, I have an outstanding UI tweak around the local blocklists that I really want to wrap up and deliver.

\n", "date_published": "2025-08-02T14:49:32-05:00", "url": "https://jocmp.com/2025/08/02/capy-log-open-in-browser/", "tags": ["capyreader","rss","programming"] }, { "id": "http://jocmp.micro.blog/2025/07/12/full-content-extractors-comparing-defuddle/", "title": "Full Content Extractors: Comparing Defuddle and Postlight Parser", "content_html": "

One of the hardest problems with RSS feeds is displaying full content. It’s essentially an unsolvable problem given the complexity of webpages and the lack of adherence to a semantic layout for any given blog or news site. It would be nice if each page had a header tag, and an article tag, but it’s not that simple. Full content parsers attempt to solve this, but each has their own set of trade-offs.

\n

Legacy Contenders

\n

Tools like Mozilla’s Readability.js used to solve this in the past, but given their recent woes it’s hard to trust it as a tool. Postlight Parser née Mercury Parser was a better option. Instead of trying to solve all webpages with a set of common heuristics, each domain could be overridden with a custom parser. In effect, The Verge could have a Verge-specific parser while Ars Technica could have a slightly different parser.

\n

It would be simple to stop there, but Postlight Parser was a product of its time. Around 2015, there was a push by Google to speed up the web by simplifying webpages with AMP. Postlight was one of many companies that stepped in with their own set of tools like the parser to improve development with AMP. But as time passed, AMP fell out of fashion, and Postlight was acquired by NTT Data.

\n

Postlight Parser essentially ended with the acquisition. It’s still possible to find Postlight Parser in the wild, however. Feedbin, a web-based feed reader, uses Postlight Parser to power its full content mode. Core development has ground to a halt with the last release in 2022.

\n

A New Entrant

\n

Readability.js and Postlight Parser may very well represent the past of full content extraction. However a new project called Defuddle might take their place. Defuddle was released in early 2025 by the developer behind the note-taking app Obsidian. It takes the Readability.js route of a one-size-fits-all input function with different internal heuristics.

\n

The following is a brief and non-exhaustive comparison between v2.2.3 of Postlight Parser and v0.6.4 of Defuddle using a small node.js application (source code on GitHub). Defuddle seems to work best when the site’s markup is already well formatted which is the case with The Verge. In the following review article, Defuddle picks up more images, headers, and content like the overall review score than Postlight Parser.

\n\"\"\n

Parsing fails if you throw an article from Yahoo News Singapore at either Defuddle or Postlight Parser. Defuddle has a slight edge in that it at least extracts images and article content but still captures garbage text like “ADVERTISEMENT.”

\n\"\"\n

In short, better base markup still results in a better outcome. Defuddle is clearly the project to watch given Postlight Parser’s lack of updates, and it’s backed by a live project with Obsidian. Full content parsers come and go but the need to tame the chaos of the web is never ending.

\n", "date_published": "2025-07-12T18:03:00-05:00", "url": "https://jocmp.com/2025/07/12/full-content-extractors-comparing-defuddle/", "tags": ["rss","programming","mercury parser"] } ] }