391 karma · joined August 1, 2013
My personal experience is that you have to blame the people and not the method.
I would define my current project as very agile in the sense that we only have details plan for what to do a week ahead at the time. Each week the team has an hour long meeting where we present what we have done, and discuss if it's good enough. If something like a hover region is found to be wrong it will get fixed for next week. If you find this issue while working on something else, you make task and PR and just fix these smalls things. I feel like this way of working is what what meant by the people who invented the idea of making software development agile.
Just curious, but did it ever make sense to launch on Product Hunt? I would assume that the claim that "most users on Product Hunt are developers, designers, or founders" has always been true.
As I understand it, he and the stock holders made an agreement some years ago, that entitled Elon to a certain amount depending on how the stock performed. It turns out the stock performed really well, entitling Elon him to a really, really big bonus. I get that this is somewhat weird given that people are being fired and that Tesla is currently not able to sell their cars at the same rate as they are being produced. But is this enough to withhold the bonus? Are there some aspects of the agreement that Elon did not adhere to? From my point of view it looks like Elon was simply able to make a really good deal with the shareholders.
In practice: The second time you implement something, start out by copy-pasting the first implementation. Once you're done with the second version, figure out if and how to abstract the two implementations.
Some APIs us PUT for creating items and let the clients specify the ID. If the IDs are UUIDs, the risk of creating duplicates is so slim that it's neglectable, and if that should happen, it's easy for the client to call again with a different ID. The real advantage of this approach is that if the API call times out, the client can just PUT again without having to fear creating a duplicate record. Recovering from a create with POST that has timed out can be pretty difficult because it can happen that the record was created just fine, but the internet connection died before the OK response reached the client.
But doesn’t that even out?
Napkin calculations: There are 10 subscribers to Spotify, each paying 10 dollars/month, and everything goes 100% to the artist. 9 of them only listen to Taylor Swift and 1 only to Metallica.
If the subscriptions would go directly to the bands you listen to, Metallica would receive 10 dollars from the one listener.
But the subscriptions are distributed based on the percentage of listeners, meaning that the Metallica fan is only giving 1 dollar to their favorite band. But this percentage is also payed by the 9 Taylor fans, so they also pay 1 dollar. In the end Metallica receives 10 dollars per month.
What am I missing here?
Yes, I agree here. To me, this feels like the cookie legislation all over again, in the sense that the end result was a lot of annoying cookie banners instead of websites stopping the usage of cookies. And yes, I know that answering 'no' in these banners reduces the amount of cookies used, but I am seeing more and more websites where things like videos don't work unless you accept cookies.
As I understand it, this is specifically not allowed by the DMA, since it would be considered an unfair advantage to Safari, if that browser/engine was the only one allowed to run PWAs.
Second: The data in cached in React Query is effectively globally available, so it comes with all the benefits and pitfalls that globals have. We use Storybook and do not use React Query in the components that have stories, so React Query is only used in the root components of the app.
But could you not just pay for a month and try it? I don’t think their plans bind you for a longer than a month.
I think one of the main takeways from Sandi Metz's quote is that you should postpone creating the abstraction until after you have the duplicated code. Sometimes you will remove the duplication when you have just two implementations, sometimes you will want many more. Once you have the repeated code it's relatively easy to make the right abstraction.
My experience is that this is only true your CSS is written by a one man army.
Example: We use information about the devices that access our web site (screen resolution, browser versions) to figure out how best spend our limited resources. This data is important to us.
Just here point out that the issue is that it's enough to have the bank account number to issue a request to withdraw money from that account, and not that the bank accounts numbers are listed.
But yeah, they should just go ahead and follow semver from now on.