It truly doesn't matter, given Musk waived due diligence. Unless the number of bots is enormous (think 75% or more) then it won't make a material difference.
Depending on your architecture, an API or rendering HTML is an implementation detail, rather than the meat of the application. Have your business logic elsewhere and have the API or controller endpoints call out to those and just do the business of rendering JSON or HTML in the controllers.
(I think this is inversion of control, someone can correct me if I'm wrong)
Sounds more like a great reason to stay away from some of the most chaotic traffic in the US until it can be considered safer. There are far, far more pedestrians in NYC than in Phoenix, and I do not trust a Waymo car to not hit some of them.
Well I think "high quality" is doing a lot there. Obviously autonomous vehicles would be safer if they work perfectly -- the concern is that they will not.
Yeah, approximately 10 minutes for me to pass driving test (from second attempt). And then around a year of driving (effectively training myself) in city to get more or less comfortable with traffic.
Generally, self driving cars are very safe, too safe actually. There are some high profile accidents, most of them involving Tesla because of the scale and way they approach the problem, plus an infamous one by Uber, but generally, self driving cars will not go anywhere unless they are sure the way is clear.
And this is the problem, self driving cars don't force their way, and they break when anything is vaguely in a collision course. If there is a problem putting them in NYC traffic is that they will stop all the time and create traffic jams, maybe get rear ended by other (human) drivers and fail to get their passengers to the destination because of some minor obstruction.
It absolutely was not the right choice for the UK (not just Britain, don't forget about Northern Ireland). The EU has definitely shown itself to be quick when it needs to be, and in general has improved life for the average person. There are nothing but downsides in the immediate and long-term future for the UK without the EU — these economic consequences are not easily solvable, and the Tories have not shown themselves capable of actually solving these problems.
The UK had a very privileged place in the EU before, and was able to punch above their weight. When they inevitably rejoin they certainly won't be able to hold that special status again.
Thanks for your work! One question I had is about when it comes to expanding beyond the web, what are the solutions available with Phoenix? For example, if I'm making a web app using LiveView, do I need to make a second app for my API for an iOS app?
We structure Elixir applications differently than a lot of platforms. Phoenix is not your app – it's just one thing that slots into your Elixir application's supervision tree. So you can run one Phoenix web server or multiple in a single Erlang VM, and nothing changes. Your Phoenix endpoint isn't global, so it will happily sit alongside several, or it will happily serve a single web server to any number of Phoenix routers serving different APIs.
So to answer your question directly, you could either add your JSON or GraphQL API directly in the same router that serves your LiveViews, or you could create a router specific to the API, or you could introduce a completely separate Phoenix endpoint and router that starts a 2nd web server. Both would boot as part of the app serving different ports. Phoenix remains a great choice for native clients if we're talking JSON/GraphQL, but because we also have native channels clients in objc/swift. Hope that helps!
I was actually just searching for this same thing on Google. I recently started a new project that LiveView would have been great for, but the fact that I need a native iOS/Android app caused me to go with Socket.IO instead for the backend. It seems likely to me that there is a way to use Phoenix channels with web, iOS, and Android.. but there isn't a lot of good information on doing it that I've been able to find.
Edit: I realize you could just use regular web sockets with Phoenix to do what Socket.IO does. But my confusion comes from actually getting it all to play nice with a LiveView front end, as well as a native app front end.
Phoenix channels is similar to socket.io, except we multiplex the channels with their own events, vs socket io that creates a single bidirectional "channel" with events. So you can think of channels as namespaced socket.io, with the server side allowing isolated and concurrent message handlers to live.
The channel docs give a solid overview of the server side, and we have a listing of third-party channels clients for most platforms here:
Out of my head (just amateur in Phoenix right now) you could just leverage the API endpoints in Phoenix and implement the iOS and Android frontend with them.
The Views are decoupled. So you can have the business logic, as you would normally do, inside Phoenix, then the API on top of this logic, and then you could either implement the whole LiveView workflow on top of the API or just directly on top of the business logic (if you’re feeling kinky but it invalidates the architecture Phoenix sets up for you).
The Getting Started guide on Phoenix has a lot of useful material even for your use case. I might be missing something crucial though :)
Well, you say that it's one of the nicest companies to work in, but clearly not if 1/3 of their employees are willing to leave over a policy decision. Some of the employees that left had been there for over 15 years — it used to be a good place to work, but this made it untenable for them.
> Well, you say that it's one of the nicest companies to work in, but clearly not if 1/3 of their employees are willing to leave over a policy decision.
I'm afraid many of them will be in for a rude awakening.
> I'm afraid many of them will be in for a rude awakening.
This is what stood out to me. Basecamp pay 90th percentile Bay Area salaries regardless of where you choose to live. Maybe I'm wrong but I'm not sure that's going to be easy to find without relocating.
Even if you're not a rabid mercenary you're certainly going to feel the impact, if not on your day to day life then on your future plans, of taking a possibly massive pay cut, if you don't want to relocate.
Maybe remote working will become more the norm post-pandemic, and that will put upward pressure on remote salaries, but I don't by any means think that's a foregone conclusion.
I'd say "I've been here too long, let's shop around since IT is a buyers' market, and take advantage of this one-time buyout offer" is a far more probable explanation than "no political discussions at work rule makes this untenable for me"...
Without the buyout or in a worse job market, we'd see much closer to 0 "principled" exits...
Difficult as it may be for you to fathom, not everyone is a mercenary driven by money and greed. Many people choose their work based on their values and beliefs. Especially a well known, tight knit company like Basecamp have leadership positions filled with people who live and breathe the product and its users.
Choosing to leave for greener pastures may be an easy decision if you're at an early stage of your career, but there's a reason these extraordinarily talented folks stayed with Basecamp for as long as they have. It's not because they just couldn't get Google to pay them more.
You could use NixOps[0] for Nix but I'm not sure you can directly compare Terraform and Guix/Nix? My set up involves Terraform for infrastructure and Nix for provisioning, and it's working for me so far.
On underground trains, you have to choose between air conditioning the platforms or the trains. It wouldn't be feasible (especially in old systems like New York or London) to do both because of the lack of ventilation (the hot air needs to go somewhere).
