Hacker News: jongleberry

New comment by jongleberry in "An update on recent Claude Code quality reports"

jongleberry — Thu, 23 Apr 2026 18:59:37 +0000

it seems to be the same cycle for everyone now, not based on first usage. I saw a reddit thread on this from someone who had multiple accounts that all had the same cycles

New comment by jongleberry in "Always Be Quitting"

jongleberry — Thu, 10 Jun 2021 05:19:12 +0000

I don’t know the details as I didn’t work directly with him, but from what I understand he was trying to get a sabbatical to figure out some life stuff, but eventually he had to quit, which was not his desired outcome as he needed the income and didn’t have the time to find another job quickly.

New comment by jongleberry in "Always Be Quitting"

jongleberry — Thu, 10 Jun 2021 04:59:19 +0000

Which means you need to find a new employer. There are companies and/or managers out there that don’t have these misalign incentives, encourage best practices (like those in this blog post), and provide psychological safety. They exist.

New comment by jongleberry in "Always Be Quitting"

jongleberry — Thu, 10 Jun 2021 04:42:39 +0000

we had a principal engineer who thought he was very skilled and held critical knowledge and tried to use it as leverage. turns out, everyone else considered that poisonous behavior.

New comment by jongleberry in "Always Be Quitting"

jongleberry — Thu, 10 Jun 2021 04:34:09 +0000

seems like you need to find a job with better management

New comment by jongleberry in "Always Be Quitting"

jongleberry — Thu, 10 Jun 2021 04:31:27 +0000

I'd agree on most points, but like others, 1 & 2 I don't agree with.

Most of my knowledge is useless or irrelevant, so taking the time to document this knowledge is a waste of time. 90% of writing a document is understanding your audience and "document your knowledge" misses that point. Littering documents and code with various tidbits is also not very helpful and probably not worth anyone's time.

Documenting long term plans is also pretty useless. Realistically, anything past 30 days is not going to happen. Documenting your strategy and decision making process may be useful, but your idealistic plans? Probably not unless it's just a few bullet points.

The most important documentation is usually the "why?", which ideally should be written before the project starts. Documentation outside of the scope of in-flight projects (which 1 & 2 seem to be encouraging) are not as important as they can be discovered with a tiny bit of effort.

New comment by jongleberry in "Get notified when a file on GitHub has changed"

jongleberry — Mon, 25 Jan 2021 19:09:46 +0000

You can set up a GitHub Action that performs an action on any push to master/main (or any branch). You can also only perform the action when specific files are changed: https://docs.github.com/en/actions/reference/workflow-syntax.... This shouldn't require admin access, assuming admins allow you to use GitHub Actions.

I generally don't bother looking at master/main for code changes unless there's something I'm looking for specifically. I set up CODEOWNERS so that teams get notified when their files are changed in PRs - this is how I get notified of potential changes to files that I care about.

New comment by jongleberry in "Ask HN: How do you monitor your websites?"

jongleberry — Wed, 24 Oct 2018 20:12:37 +0000

At Dollar Shave Club, we use CircleCI 2's Scheduled Workflows to run "monitors" against our production services every minute. These are idempotent, analytics-disabled API & Browser (via Puppeteer) tests that we also run as CI tests on every commit.

We send all monitor metrics to DataDog. When a monitor fails, the appropriate teams will get a Slack notification with the full stack trace. A DataDog monitor will also be triggered, alerting the appropriate teams.

For browser monitors, we upload screenshots and Puppeteer tracing files to S3, then share links within each Slack hook. This allows people to figure out what's going on just by clicking links in Slack.

We were planning to improve this setup in the future, but it's good enough for us right now. For example, CircleCI goes degrades frequently so we sometimes get spotty coverage. We basically spend < $200/month with CircleCI to monitor about 300 APIs/pages every minute.

You can read more here:

- https://engineering.dollarshaveclub.com/monitor-all-the-thin...

- https://circleci.com/blog/how-dollar-shave-club-3x-d-velocit...

- https://github.com/dollarshaveclub/monitor

New comment by jongleberry in "Ask HN: Please AWS team, make links work with control-click"

jongleberry — Fri, 24 Mar 2017 22:49:30 +0000

I have this exact problem with Microsoft Azure as well. Changing pages always takes 5-10 seconds and you can't open in a new tab to open new tables concurrently. Makes working in their portal really inefficient.

New comment by jongleberry in "The Way of the Gopher: Making the Switch from Node.js to Golang"

jongleberry — Sun, 27 Mar 2016 17:56:42 +0000

My same thought as well. S3 has a rate limit, which is where a lot of these timeouts or errors are probably happening. Seems like they should be using a database instead.

New comment by jongleberry in "Microsoft Edge gets native ECMAScript 7 async/await support in latest build"

jongleberry — Thu, 01 Oct 2015 23:01:20 +0000

We're moving Koa to be ready for async functions. Does anyone know whether async functions will have an arrow function form?

https://github.com/koajs/compose/pull/27#issuecomment-144868...

New comment by jongleberry in "Polyfills as a Service"

jongleberry — Mon, 31 Aug 2015 04:57:13 +0000

will do

New comment by jongleberry in "Polyfills as a Service"

jongleberry — Sun, 30 Aug 2015 16:22:32 +0000

Author here. Haven't maintained this in a while. It's down due to some breaking changes in libraries and I haven't updated the code to handle it.

I also stopped using this as you could just use babel to automatically use whichever polyfill you use with babel-runtime. Saving a few kb is an overoptimization.

If you're interested in maintaining this project, let me know. I can add you to the GitHub organization.

New comment by jongleberry in "A Strong Mode for JavaScript"

jongleberry — Thu, 12 Mar 2015 01:10:46 +0000

use `let ` or `const `. there's no need to use `var` in ES6+, ever.

New comment by jongleberry in "Response to Netflix's “Node.js in Flames” Blog Post"

jongleberry — Wed, 19 Nov 2014 20:37:32 +0000

this is why the express team actively rejects any features or support for dynamically changing middleware and routes during runtime.

New comment by jongleberry in "An easier way of using polyfills"

jongleberry — Fri, 07 Nov 2014 09:24:12 +0000

working on an alternative that doesn't use its own polyfills and instead uses other people's well written libraries. i used polyfill.io before and half the implementations had bugs due to the lack of tests. feedback welcomed!

http://polyfills.io

New comment by jongleberry in "Istanbul: A JavaScript code coverage tool written in JS"

jongleberry — Wed, 24 Sep 2014 16:52:36 +0000

or you could just write it as a single CLI command: https://github.com/strongloop/express/blob/master/package.js...

New comment by jongleberry in "SemVer has failed us"

jongleberry — Fri, 08 Aug 2014 22:22:16 +0000

You're assuming "no duplicate dependencies" is equivalent to "install globally", which is false. In the article's context, the argument is against duplicate dependencies per project

New comment by jongleberry in "SemVer has failed us"

jongleberry — Fri, 08 Aug 2014 22:19:54 +0000

You're assuming that development and production version ranges will always be the same, which is false. This is what npm shrinkwrap is for, and not pinning during production is stupid. But pinning everything in development is unnecessary until you stage/deploy.

New comment by jongleberry in "SemVer has failed us"

jongleberry — Fri, 08 Aug 2014 21:56:10 +0000

Could still be just 3. ..