Eugene eugene1g

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't really have SREs and they make engineers pretty much do everything,

📝 I submit the same text to GitHub Support.

I want to use same scope for npm package and GitHub Package Registry.

For example, @org scope exist in npm and GitHub.

@org/foo-public package is public on npm registry
@org/bar-private package is private on GitHub Package Registry

tips to evolve as a developer

developers get stuck, paralized

https://nav.al/finding-time

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch04.html

Make It Stick https://www.amazon.com.br/Make-Stick-Science-Successful-Learning/dp/0674729013

(I'm enjoying doing these raw, barely edited writeups; I hope they're useful to you too)

Feature flags

This is my own writeup on feature flags; for a deep dive I'd recommend something like Martin Fowler's article (https://martinfowler.com/articles/feature-toggles.html).

So. Feature flags. The basic idea that you'll store configuration/values on a database/service somewhere, and by changing those values, you can change the user experience/features for a user on the fly.

Let's say that you're building a new feature, called 'new-button' which changes the color of buttons, which is currently red, to blue. Then you'd change code that looks like this -

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

Use ESM yourself. (preferred)
Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
Stay on the existing version of the package until you can move to ESM.

PostgreSQL is Enough

See the new site: https://postgresisenough.dev

	/**!
	* Fast CRC32 in JavaScript
	* 101arrowz (https://github.com/101arrowz)
	* License: MIT
	*/

	// If you use this code, please link this gist or attribute it somehow.

	// This code uses the Slice-by-16 algorithm to achieve performance
	// roughly 2x greater than all other JS CRC32 implementations (e.g.

	class RepositoryNamespace<Entity = string, Metadata = {}> {
	private readonly ns: string
	private readonly kv: KVNamespace

	constructor(kv: KVNamespace, namespace: string) {
	this.ns = namespace
	this.kv = kv
	}

	put(key: string, entity: Entity) {

	// SPDX-License-Identifier: MIT-0

	export interface Env {

	}

	export default {
	async fetch(
	request: Request,
	env: Env,