The watchdogs are extremely slow and have a huge backlog. You’re right that storing that data in the US or without transferring ownership to an EU subsidiary would not be legal.
64 karma · joined August 22, 2020
Changing the temperature while driving on a good touch interface is trivial and incredibly far from incredibly dangerous. Besides with CC systems nowadays people look at the set temperature just as often. More advanced features like toggling internal air circulation do require a peek, but so do the buttons on most classical cars where you have multiple buttons in a row with unlit icons.
I still prefer buttons for the tactile feel and feedback, but the downsides you listed are pretty much made up.
The great benefit of a touch screen is unlimited update capabilities. It seems absurd to me that there are still cars rolling off the factory line that have unupdatable software in 2022. Your car is basically outdated and replaceable by something better within a year. That’s great for the manufacturers, but not for the customer. Compare that to a 3+ year old Tesla which works almost as good as a brand new one despite big upgrades to their internals, largely thanks to regular updates.
If you want to be selective in what people email you about, you can always move your email to your personal readme with further restrictions.
He, as many Tesla employees do, got FSD for free from Tesla. He still owns the free FSD after being fired, which as it being an employee perk already seems strange to me.
FSD beta is a closed beta only for people in the top ~1% safety scores and can be revoked for any reason (as has been done for reckless drivers). I assume another Tesla tester perk (he was employed as an FSD tester after all) is getting into the beta program regardless of your safety score. Revoking that employee-privilege after firing is not taking something he owns.
AFAIK Tesla has never taken unlocked addons such as FSD away from cars that were paid for.
I've been working as a contractor for several years now, and for about 2 years now I am also working on my own start up together with a partner but it's earning 0 because reasons. After having worked A LOT over the past few years, I had a big financial buffer that allowed me complete freedom in my decision to quit, which was a very important factor.
For a long time I felt like I might be close to burning out due to working too much, getting bored of work, being unable to get anything changed at the company I was working for (as a software architect), and dealing with relationship issues. I took all of March off to see if that would help, but within 1-2 weeks after getting back I realized I wasn't really ready yet but I kept going because it was a very convenient job. Second last week of April something small happened that pissed me off more than it should, revealing to me that I wasn't in a good state of mind to keep working there. The next day I informed the company I would quit as soon as possible (which ended up end of April).
I decided I was going to be working on my own startup for the foreseeable future while taking it easy to get my head straight again. I ended up just coding endlessly on the project as a means of being distracted while never really dealing with real issues because I did not have the energy to confront them. Meanwhile I keep going in circles dealing with the end of my relationship and I seem to be unable to move on. I've come to realize spending so much time on my own with little distraction has been an issue.
I ended up deciding to try to find a new job again and work for my start up only 2 days a week, but it has been hard finding something for 3 days a week. I obviously want to work on location 1-2 days, which is also not ideal with Covid.
The lesson I learned from this is not to quit when you're not happy about your personal situation, even if you can afford to financially and professionally. The distraction is probably healthy, and if your current job isn't, find another one that is instead of quitting altogether.
What is the downside of using Google's? You can E2E encrypt messages and using firebase for notifications is free.
In the past I had to write or figure out my own Redux solutions to store data from queries in the state and now that comes out of the box with Apollo. If I want to manipulate this state locally, I can just do a client.writeQuery in a standard JS function (no resolver bullshit). In the rare event I want purely client-side state, I can use the same method with the @client directive. I've never really needed resolvers as I can contain the logic in my `update` handlers or state manipulation (action) functions that look and behave like standard JS.
Caching is great out of the box. You get all variations you might want (cache-first, cache-only, cache-and-network) and it's very easy to configure. Not sure what problem you ran into. Maybe server-side?
State persistence is a whole different story. I've found it's hard to do well due to Apollo's ROOT_QUERY combining all pieces of the state. It requires almost an all-or-nothing approach or a lot of hacking to get it to work. I've spent a lot of time searching for proper solutions and even built my own, but they've all been insufficient. Considering local storage persistence brings XSS vulnerabilities as well, I've decided to focus my efforts on performance for now which helps both returning and new users.
Personally I love Apollo for its state management and will continue to integrate it in more projects. My biggest gripe at the moment is writing maintainable client-side queries. The code gets quite verbose, especially when you try to do proper (TypeScript) typing without splitting up your code into tiny fragments all over your codebase. And keeping the types in sync with the queries and server-side schema takes a lot of time and effort. I've mostly been thinking about solutions to auto-generate client-side query types, this would increase type-safety as well.