3,625 karma · joined March 9, 2011
Perhaps this doesn't apply to your area of engineering, but I do feel that it does affect a substantial chunk of the HN audience.
How and what data you choose to collect about internet visitors is no longer a purely technical analysis, it now has broader implications that potentially involve political actors. You don't know who might have access to that data in the future or what they might do with it.
We as engineers are the final implementer of these decisions. Should we really abdicate the ethical responsibilities tied to these decisions so easily?
I know I have the same cable unbundling problem and have mentally decided that the maximum amount of subscriptions I will have is 4. If I want to subscribe to a new one, I find the one I'm using the least and unsubscribe from it first before adding another.
"OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. You can do most things with OOP or without OOP but each path has some upsides and downsides and most of the time it's good to use some things it provides where it makes sense and not get too religious about it. The great architect has the foresight on how the code will be used in five years and design it accordingly."
A lot of times the good stuff is at the bottom.
That said, I really hope favorites isn't removed because even though I only discovered the feature a few years ago, I really cherish the comments I've favorited.
why would that be a bad thing?
Not really by definition - tables rendered on the server side are a good example of a payload that can easily be larger than template + dataset.
How do you deal with spam?
How do you ensure your emails don’t get junk mailed?
[1] https://docs.aws.amazon.com/systems-manager/latest/userguide...
Most of us are building CRUD apps not sending people to the moon.
Still too high of a % to ignore.
This makes talking about and planning for a release unnecessarily verbose. You can only describe your releases in terms of relative time. Item A is going in the next release. Or the release after next. Or three releases from now. It's much easier to know the name of a release ahead of time.
I did away with semver for my company awhile ago, moved to dates for a little while, and now just do plain numbers. It's basically just a simplified version of semver without a distinction between MAJOR or MINOR patches. This works just fine when you're building a web app and not a library to be consumed by others.
Postgres is fine as a queue for medium to large sized projects as it depends completely on your workload and what sort of performance characteristics you need. Thinking about it in terms of project size is the wrong way to evaluate it.