I believe 'var' was introduced in C# to make it much easier to work with LINQ, where you can easily return a subset of properties - without var you would have had to declare interfaces. I think ReSharper is responsible for the rapid proliferation of using var everywhere.
Is ReSharper that prevalent? I've always thought it a small subset of programmer's who use it but are very vocal (and preachy). I've only seen it used twice 'in the wild'. And one of those two times most of the devs hated it because it was a performance hog, it was a preachy 'architect' shoving it down their throats.
I don't use resharper, personally found it far too opinionated in what I felt were bad ways. Plus it often resulted in poor performance in VS.
For years I've used var pretty much exclusively, it's just easier than typing the type twice. Even after they introduced new().
With the new array-like declarations I'm considering switching to declaring the type on the left rather than the right.
Which, in the end, is all this syntax is, a pretty way to stop you needing to declare the type twice. And now you can either do it on the right of the expression like this:
var things = new List<string>();
Or on the left:
List<string> things = [];
Although, one of the nice things about using var is that it makes it easy for your eye to scan a bunch of variables declared together as they line up.
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.
> I would assume that the claim that "most users on Product Hunt are developers, designers, or founders" has always been true.
Their user base is narrower than that, IMO. Actual founders (not just wannabe founders) are too busy to be scrolling Product Hunt all day. If they do, they’re more likely to be there to rip off your idea than pay you for it. Developers prefer sites like HN or engineering blogs.
Product Hunt caters to product managers and designers.
Add networking users to the list, who engage in paid upvoting campaigns. After my first and last post on product hunt I got 3 different requests for "Supportive Product Review" within 4 hours.
I should probably look this up somewhere on the net, but here goes anyway: What was the basis for Elon not receiving his stock award?
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.
A judge found that the bonus was awarded basically by Elon to himself, so it was invalidated. Technically it was awarded by the board, but at a time when Elon had extreme control over them.
> Musk controlled only 21.9% of Tesla’s voting power, so he lacked mathematical voting control...
> Defendants sought to prove otherwise, and they generally contend that the stockholder vote was fully informed because the most important facts about the Grant—the economic terms—were disclosed...
Basically, the shareholders voted on the grant while having a full understanding of the economic terms. It was awarded by musk, to musk, with approval of the shareholders and (supposedly overly friendly) board.
It really makes it sound like the judge might have been wrong based on the sequence of events we have now, which is:
1. The shareholders approve a stock grant on economic terms
2. A judge says "If the shareholders knew everything, they wouldn't have approved that"
3. The shareholders, now knowing everything, approve it again despite it having almost no benefit now
That really really makes it sound like the shareholders did in fact want to approve it in 1, and so the information they didn't know wasn't all that important, was it?
I know it's a different set of shareholders then and now, but still...
> A judge says "If the shareholders knew everything, they wouldn't have approved that"
That's not what the judge said. It's more like "this award didn't follow the requirements for such an award for a corporation in Delaware". It doesn't at all depend on some prediction about what the shareholders would or wouldn't do in other hypothetical scenarios.
Tesla stocks have a lot of hype especially from Cathie of Ark. Nearly everywhere from spams to YT to FB, you have a lot of "ads" to promote Tesla. Anything EVs good news straight away related to "Tesla" even if it is about Toyota or BYD bad news, seems like Tesla getting credit instead. At current stage I am convince somekind of coordinated and multi layered pump and dump is happening. We are at the "pump" stage. Anyone doing a decent research will see Tesla has near no moat unlike Apple, Nvidia or Microsoft. No battery factory. No owning any lithium mine. No gpu productions. Factories depend heavily on China grace. High churn of employees. Solarcity gone. Autopilot rebranded as FSD which is not even reaching 3.0 after half a decade of promises. CyberTruck design are joke. Any trainees working in BMW or BYD can design a better CyberTruck. Gigafactory? Hahaha...you got a chance take a look BYD factories. Even Taobao warehouses will make Amazon warehouse look like medieval setup. There are Chinese factories that look more like Star Trek than ANY gigfactory. Just ride the hype part and make sure you do the dump earlier before the actual dump happening by the elites.
Don't use DRY but WET: Write Everything Twice. :o)
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.
Basically never ever abstract something if you only have two copies. Copy/paste and move on and be productive. It's usually only if you have a third or fourth copy that you start to see if there is any inherent abstraction to be gleamed.
The difference between PUT and POST is weather the command is idempotent or not.
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.
Aren't you basically describing that you want idempotency?
The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.
9.3.4 PUT
"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."
9.2.2 Idempotent Methods
"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
I hope this means that CarPlay gets some more focus, because I would like a CarPlay integration where everything I have configured in a car is stored in a profile on my phone. This is what I imagine: When I get into a car, I just have to connect my phone, and the seat automatically adjusts, the radio has my favorite stations configured, and the UI is set up as I prefer it. When I find myself in a car model that I haven't driven before, the phone is able to make a good guess of how to configure things based on my setup in other cars.
> But you don't actually do that on Spotify. As the article correctly points out, your subscription fee doesn't go to the artists you listen to, it goes to the artists played on Spotify as a whole.
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.
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.
> In the meantime current solution could stay simply because it does not hinder any competition.
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.
By the same logic the mere existence of Safari would be unfair because other browsers are not ported yet. This is of course incorrect reading of DMA. Have a look yourself:
If Apple demonstrates that the entry barrier is sufficiently low by cooperating with other vendors, how one could possibly build a legal case under DMA against them? On the contrary, by disabling PWA in Safari Apple acts as a gate keeper complicating access to the platform for business users. THIS is what DMA forbids.
Also it has to be taken into account that the less PWA engines exist the lower is actually the entry barrier. We only need 2-3 competing solutions max to support innovation without harming PWA developers.
