Github repo (mirror): https://github.com/deuxfleurs-org/garage
814 karma · joined November 4, 2010
It's that small changes like adding getters and setters give an easy-to-follow PR, a false sense of accomplishment for both the author and the reviewer, and ton of dopamine with that. While important changes, that actually deliver business value or repay technical debt, become increasingly difficult to do without replacing massive amounts of code and redoing the file structure.
Inertia is the biggest demotivator.
More: https://use-the-index-luke.com/sql/where-clause/partial-and-...
> An interesting reminder that PMs aren’t always in the driver’s seat. In fact, sometimes they’re not even in the car .
If you're building a technical tool for technical folks then you probably don't need product managers, until late game anyways. Though you'll probably already have a few product engineers and product designers, who fill in that role.
Seems dated as it requires NodeJS either 0.8 or 0.10.
And I believe there should be a better way to prepare your users for a major version upgrade (React 15 -> 16) than to update the current branch with all kinds of deprecation warnings. Even if a library - as popular as React - doesn't plan to provide lifetime support for any major because they like to to move fast, I understand that, it's simply not okay to ruin older branches this way, madly assuming everyone is surely going to upgrade to React 16 in the immediate future.
Ideally, I'd imagine there could be a separate optional package that adds these warnings dynamically. If that's not possible technically, then an optional build flag would be nice. Or two separate releases: react-15.5.0 and react-15.5.0-upgrade-support. Even better: go back to semver, and treat major upgrades as optional for the first 6 months. This allows other libraries like routers and style libs to catch up, so app devs can upgrade even more smoothly.
Maybe after all, DX is about when to provide helpful errors and warnings. And when not to?
However external deployment of code somehow doesn't feel like an improvement to me. From a DevOps perspective having webtask code run on a closed third party environment is a big risk. It makes continuous integration, testing and error reporting more difficult or even impossible if the webtask service isn't well thought-out.
The way forward for webhooks in my opinion should be standardization of push and pull protocols, with concerns like cryptographic signatures, metadata headers, and failure recovery through event sourcing.
Python - https://github.com/blockstack/secret-sharing
PHP - https://github.com/mathieuk/secretsharer
Node - https://github.com/amper5and/secrets.js
Go - https://github.com/codahale/sss
C - https://github.com/fletcher/c-sss
Ruby - https://github.com/lian/shamir-secret-sharing
If you only care about code and learning new APIs, that's your right. (I'd say do it at home.) If you want to ship something real with 20% company time? Get your project organized.
If you're a designer/developer on Mac I would strongly recommend ImageOptim (https://imageoptim.com/). It supports Zopfli and has a simple drag-n-drop user interface.