jongleberry

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

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.

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.

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.

seems like you need to find a job with better management

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.

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.

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

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.

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.

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...

will do

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.

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

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

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

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

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

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.

Could still be just 3. <marketing>.<breaking>.<non-breaking>

Any suggestions for improving the spec? I wrote that in like an hour and I have no experience writing specs.

I don't and wouldn't even really use it anyways. Easier to just follow semver and bump minor instead of patch if there's a remote possibility of anything breaking

for the discussion between strongloop and the current maintainers: https://github.com/strongloop/express/issues/2264

If you want a mobile-first, vanilla JS autocomplete implementation: https://github.com/jonathanong/autocomplete

connect is basically just a `.use()` kernel, and express' router was just mounted on this kernal. now, express' kernel combines connect's `.use()` kernel as well as the router, simplifying the entire middleware system internally and removing the need to do `app.use(app.router)`.

i.e. you're no longer mounting the router on top of another kernel.

not really. use koa instead if you can. a lot of middleware hasn't been written for koa yet, so you might have to write your own.

if you're interested in creating small, modular browser modules, feel free to contribute to any repo in https://github.com/component. most work with browserify as well, and bower support is trivial.

TJ just updated express' benchmarks to match koa's. here are the results on my computer: https://gist.github.com/jonathanong/8065724

you can also use it with > 0.8 with https://github.com/TooTallNate/gnode

if there's a project you want to maintain for him, just ask and he'll give you ownership. i help with koa and most of his more popular repos have multiple maintainers now, so don't worry.

yes, stack traces work now, as long as they aren't being thrown in a different event loop: https://github.com/koajs/koa/issues/117