A writable file closing itself when it goes out of scope is usually not great, since errors can occur when closing the file, especially when using networked file systems.
You need to close it and check for errors as part of the happy path. But it's great that in the error path (be that using an early return or throwing an exception), you can just forget about the file and you will never leak a file descriptor.
You may need to unlink the file in the error path, but that's best handled in the destructor of a class which encapsulates the whole "write to a temp file, rename into place, unlink on error" flow.
Java solved it by having exceptions be able to attach secondary exceptions, in particular those occurring during stack unwinding (via try-with-resources).
The result is an exception tree that reflects the failures that occurred in the call tree following the first exception.
Or it’s simply an indicator of a schema that has not been excessively normalised (why create an addresses_cities table just to ensure no duplicate cities are ever written to the addresses table?)
DISTINCT, as well as the other aggregation functions, are fantastic for offline analytics queries. I find a lot of use for them in reporting, non-production code.
It depends when you see it, but I agree that DISTINCT shouldn't be used in production. If I'm writing a one off query and DISTINCT gets me over the finish line sparing me a few minutes then that's fine.
There's nothing wrong with using DISTINCT correctly and it does belong in production. The author is complaining about developers that just put in DISTINCT as a matter of course rather than using it appropriately.
One reason to have excessively normalised tables would be to ensure consistency so that you don't have to worry about various records with "London", "LONDON", "lindon" etc.
Because a city/region/state can be uniquely identified with a postal code (hell, in Ireland, the entire address is encapsulated in the postal code), but the reverse is not true.
At scale, repeated low-cardinality columns matter a great deal.
There are ZIP codes that overlap a city and also an unincorporated area. Furthermore, there are zip codes that overlap different states. A data model that renders these unrepresentable may come back to bite you.
This assumption got me in trouble as a junior analyst years ago. I was asked to analyze our customer base and wrote something like the below. Management congratulated me on finding thousands more customers than we'd ever had before.
SELECT
zipcode.rural_urban_code,
COUNT(*) AS n_customer
FROM
customer
INNER JOIN
zipcode USING(zipcode)
GROUP BY 1;
Its less bad that they offered refunds, but why would it that make it ok?
If you buy a car, and the company lights it on fire and then offers you a refund is that ok?
You'll still have the burnt husk if you choose not to take the refund
It's hard to take this comparison seriously because Rocket League is a (mostly) online game for which an active connection to active servers (and thus a cost to the developer). Also, there is no burnt husk.
It's like you paying to get lifetime access to a club, the club closing and reimbursing you.
Since when are companies required to run servers for multiplayer? There is always other ways to play multiplayer. At least there used to be but not any more. It is just a thinly veiled excuse to be able to shut it off.
> It's hard to take this comparison seriously because Rocket League is a (mostly) online game for which an active connection to active servers (and thus a cost to the developer).
This is a different situation, but if this was the stop killing games initiative, the answer would be that when you shut down the game you release the server software.
> Also, there is no burnt husk.
The burnt husk is the program on your computer that opens to the menu and then falls over unable to play. That's what you're left with if you don't take the refund.
> It's like you paying to get lifetime access to a club, the club closing and reimbursing you.
That makes it sound like they merely shut down a rocket league hosting service and someone else could provide the same service. They arranged it so they're the only possible way to play rocket league, even though the game runs on my computer using my resources.
I have tried to keep the Psyonix wikipedia article true to reality if you look at the change history but there are people working for Epic heavily whitewashing it and I didn't want to force (wiki) arbitration or cause a disturbance after the first couple edit/revert battles. The Rocket League one is even harder to keep true.
Basically, they said they were stealing the Mac and Linux Rocket League versions because they wanted to go full directx 10 instead of 9. But the fact that the PS3 is still a first class client running Directx 9 even today shows this is/was a lie. Epic lies quite a bit. In fact when they bought Psyonix they loudly announced there would be no changes, it'd stay rocket league. But of course that lie only lasted 6 months. And now they re-write the wiki pages to pretend it was always the plan.
Anyway, I didn't want a refund. I wanted to keep playing rocket league. And now I cannot play. That's wrong. They bricked my game. And everyone thinks that's A-OK. Just like when they'll brick your modem, or your fridge, or maybe your car. Frankly, having any software in a $thing is a huge risk these days given the status quo.
The Investigatory Powers Act 2016 was one of the big things (before Brexit) that made me realise the UK wasn't a suitable place to run a tech business.
>waiting for 2 different lights just to get to the opposite corner.
A solution sometimes seen in London is a “Pedestrian Scramble”, where pedestrians are explicitly given full (and even diagonal) access to a junction with all other traffic stopped.
In Seattle, they call these "all walks" or officially, "all way walks." I love them, since I don't feel like I have to watch out for drivers making left turns.
With SSO, the party running the SSO decides what the authentication policy is.
For example, where the authentication request is coming from (on-site, managed device), what methods are being used (hardware second factor, Authenticator app).
These are all things that the SSO can check at time of authentication, before a token or session key gets issued to the user. Also, all of these things can be checked again when doing any auth flows for the various linked services.
So with stolen SSO credentials, they might be worth diddly squat to you if you didn’t think to also be on-site or on a managed company device (physically or virtually).
A smartwatch for kids could be so good if it was designed in a way to be educational, but most importantly, which respects a child’s privacy utmost, even from their parents in terms of tracking.
For example, a maps app, to always get the kid home if they’re lost. Medication reminders. Fitness tracking. Emergency SOS. A calendar to remind them about family birthdays and upcoming holidays. School timetables. Medical ID. Payment cards or passes for travel (in Western Europe a lot of schoolchildren commute by themselves, especially on public transport) and spending their allowance. Let the kid choose to notify their family of their location as and when they want to. Empower them to use tech to their advantage but put their privacy first.
Children are going to end up as adults in this world regardless of whether we teach them, so we should be teaching them the benefits and warning them of the many bad actors. We should be teaching our children the skills they need to navigate the modern world. This includes technology and abusive/controlling relationships.
I believe a good responsible smartwatch for kids can exist. Alas, this is Google and helicopter parents exist, so this product is not it.
https://github.com/isocpp/CppCoreGuidelines/issues/2203
reply