I use the tag feature a lot. On a single save, I usually end up with more than one tag. My favorite pancake recipe is tagged format-text, topic-cooking, topic-pancakes and flag-bad-parse.

Pocket's web and android apps do not have a way to filter using multiple tags at the same time, so I can't filter items that have both topic-cooking and topic-pancakes. You have to filter by one tag only, then manually search.

After years of using node.js scripts and Pocket's API to multi-tag search (and more), it finally occurred to me to share my tool so others can get more from Pocket without writing a line of code or messing around with API keys.

Sparkpocketjoy syncs a copy of your Pocket metadata to your device (persisted to disk via IndexedDB), generates some indexes (indices?!) and loads both into memory. Every query happens in-memory, so exciting your data happens as fast as you can click.

In addition to filtering by tags, you can filter by status (archived, favorited, queued), media attachments (has images or embedded videos) or text search of the title.

The landing page is a throwaway, and there's some features I really want to build, but I decided to step out of my comfort zone and show HN my unpolished but functional project. Let me know what you think!

https://www.sparkpocketjoy.com

Comments URL: https://news.ycombinator.com/item?id=40881621

Points: 2

# Comments: 0

Just occurred to me there's a different possibility:

The extra connection bug mentioned could be from a rogue thread/process/code-path connecting to the queue and fetching an item, but somehow not doing the work.

Verifying this likely requires access to the codebase, so treat this as little more than idle speculation.

why does generating indexes at start-up not count as having indexes?

(asking because i do this all the time)

it feels correct, even though it's not a complete guide

(reliably persisting changes to disk is a big part of what dbs do, but is missing here)

- clear case of misconfigured instance (prefetch) and a bug somewhere in the stack (reconnection issue)

- prefetch behavior sounds like they receive a message, ack it then process it

- i wouldn't recommend ack before processing, because you become responsible for tracking and verifying if the worker ran to completion or not.

- work then ack is the way. the other way around ignores key job processing benefits like rabbitmq automagically requeueing messages when a worker crashes and failure related logic like deadletter queues.

- the trick i've started leaning on with rabbitmq is giving each worker their own instance queue (i call it their mailbox).

- when a worker starts a job, it writes the job id, start time and the worker's mailbox to a db. any system can now look up the "running job" in the database, know how long it has been running and can even talk to the worker using its mailbox to inquire if it is running and if that job state in the db is accurate.

- happy the writer and team found what works for them. ultimately, what you understand best would serve you better, so they made a good choice to lean on their strengths (postgre).

Just got back into the job market, and every potential employer has expressed gratitude for my level of honesty and transparency.

I'm "weaker" at negotiations since I've laid out my cards on the table upfront. The other side of the coin is companies are less likely to waste my time unnecessarily, or play hardball too much when you appear to roll over so easily.

My take on Hard Truth 6 is to be careful and strategic with your honesty. It may not always be interpreted the way you intended, so be honest but be wise about what you're disclosing.

http://designbymobius.ca/resume

Two wrongs don't make a right.

> Crypto messaging does not appear to be directed at the rational or sensible.

I would recommend it to anyone looking to experiment with a "high latency social network".

Comments URL: https://news.ycombinator.com/item?id=27010066

Points: 132

# Comments: 17

Sometimes a single operation has multiple ways of failing, each with their own ideal recovery / retry plan.

You want to catch the error, examine context (app state, error type and metadata at crash point) and determine what the best next step is.

This example linked below is from a web crawler service I run.

When an error occurs while logging in (multiple page loads and sometimes a redirect), there is a single handler to determine if retrying the login, crashing or alerting a human is the best course of action.

https://twitter.com/akamaozu/status/1193910918641532934

Ended up with a way to write code that recovers from errors in ways that I might not immediately understand but demonstrably works.

https://twitter.com/akamaozu/status/1274341510419329029

Easy access to changelogs should be an "easy to access" feature in all databases. Event driven systems aren't rare: the data store needs to be done to tell interested parties that underlying data has changed.

Would love to talk to anyone on the EToys team or anyone who has done something similar.

I'm @akamaozu on twitter.