jeeybee

Hi HN,

I’m the maintainer of PGQueuer, a minimalist job queue for Python that runs entirely on PostgreSQL—no Redis, brokers, or additional infrastructure required. It’s designed to offer solid concurrency with low overhead and fit seamlessly into projects that already use Postgres.

I’ve been working on improving the public documentation [1], and I’m looking for feedback from others who’ve gone through this process—especially those maintaining small, technical open-source projects where all the important knowledge lives in the docs. There’s no internal documentation and likely never will be, so clarity and accessibility are essential.

I’d especially appreciate your thoughts on:

* How do you decide what’s worth documenting for a technical audience who might just read the source anyway?

* How do you balance being thorough without overwhelming the reader?

* I’m currently using Read the Docs [2], but I’m considering switching to a self-hosted MkDocs site. What have your tradeoffs been between Read the Docs and self-hosting?

* What practices have helped you keep your docs in sync with your codebase?

* What’s worked well (or poorly) for encouraging contributions and getting users to help improve the docs?

If you have time to browse the current docs [1], I’d love to hear what’s missing, what’s confusing, or what stands out as helpful.

I’m here to learn from your experience—tools, workflows, hosting decisions, contributor strategies, anything. Thanks in advance!

---

[1] https://pgqueuer.readthedocs.io/en/latest

[2] https://readthedocs.org/

[3] https://github.com/janbjorge/pgqueuer

I attended a secure development course where the instructor insisted on always using third-party libraries. While I agree that relying on well-audited libraries—especially for cryptography—is often the safest route, there have been plenty of cases where libraries were exploited. Has anyone experienced scenarios where building custom solutions outperformed using existing libraries? Also, how do you typically audit third-party libraries to assess their security, and what factors do you consider when weighing library trustworthiness against in-house development?

Hi Hacker News,

I'm working on integration projects that require communication between our internal systems and external platforms. I’ve been using ngrok to expose local servers, but my organization’s IT security team has denied its usage with the reason:

> "We will not allow any kind of services that will allow external traffic to hit local machines."

Without ngrok, the integration process has become time-consuming and error-prone due to the guesswork needed to understand external systems.

Current Development Cycle:

Currently, I point the webhooks to a site like webhook.site and manually copy the payload from there. While this works, it's extremely inefficient and increases the potential for errors during integration.

Potential Workaround:

I'm considering using a Docker container running in the cloud that allows me to live change the code as needed. This setup would operate behind our IT security measures, potentially bypassing the restrictions on direct external traffic to local machines.

What I'm Looking For:

- Alternative Tools: Secure alternatives to ngrok for exposing local or cloud-based services.

- Cloud-Based Solutions: Insights on using Docker containers in the cloud for integrations, including best practices for live code updates.

- Best Practices: Strategies for integrating with external systems in highly secure environments.

- Community Insights: How others have navigated similar restrictions and any successful solutions they've implemented.

Any recommendations, experiences, or advice on this approach would be greatly appreciated!

Thanks!