If you write code that powers an EV's 'self driving mode' - which makes calculated choices, sell it and deploy it, when that car gets into an accident under 'self driving mode', you may not be liable (depending on the case and jurisdiction - as proven in the past). The driver is.
There are many instances (where I am from, at least - and I believe in the USA), where 'accidents' happen and individuals are found not guilty. As long as you can prove that it wasn't due to negligence. Could "don't be an asshole" as instructions be enough in some arenas to prove they aren't negligent? I believe so.
I'd like to agree with this, but I sadly don't. I'd like to agree because we've been Heroku customers for about 18 years - which is wild to think about. I've used Heroku both personally and professionally day-in, day-out for over a decade.
We've been on self service and we've been on enterprise contracts. In the last 2 years I believe we've cycled through about seven account managers. Heroku as a concept might not be dead, but if you release an incredibly empty announcement saying there's no new enterprise contracts and existing ones may be renewed, enterprise Heroku is absolutely dead and I'd suggest it means Heroku as the current product is dead too.
Any Heroku user that has been at the level of an enterprise user before, or who currently is, would be ringing alarm bells at the current situation. It doesn't matter about the internal good will of employees - if you have a blog post hanging your enterprise customers out to dry (ironically as enterprise customers we have received zero communication from Heroku about this) after a year of terrible stability - you're really doing a great job of killing the whole thing.
> Heroku remains an actively supported, production-ready platform, with an emphasis on maintaining quality and operational excellence
Anyone that has used Heroku for a while will know that it is far less reliable today than it has been at nearly any point in its history (it's the least reliable since its first year of existence, imo). There is very little "operational excellence" left as an organization. All you need to do is look at how they communicated (or extreme lack-thereof) a critical outage that lasted for hours last year[1]
As an organization, we've put up with terrible reliability over the last couple of years, and swallowed cost increases every renewal and we've always been committed. That's changed in the last few days - we've tried out Railway and Northflank, and we'll continue to try out a few other services until we find the one that fits. We're lucky, we have about 9 months left on our contract and that gives us enough time to move.
Also it's important to note the topic is during school hours. There's a wealth of knowledge to learn at school, and there's also a wealth to learn outside of school. Knowledge about the world can, and will, happen in both. Many hours outside of school to 'grow your knowledge' through your phone.
Currently Claude etc. can interact with services (including AWS) via MCPs.
What the user you're replying to is saying the Bun acquisition looks silly as a dev tool for Node. However if you look at their binding work for services like s3[0], the LLM will be able to interact directly with cloud services directly (lower latency, tighter integration, simplified deployment).
I'm not too familiar with the history of a few that you've mentioned, but the Mustang (excluding the GTD), Supra, Carolla, S2000, Z never had track focused cars. For the time-poor and money-rich racing enthusiast, lacking a turn key package isn't really an option.
Your local track days where you see the likes that you mentioned - you'll also likely get a few Porches etc too. But there's absolutely a culture of racing higher end cars, the GT3's, Ferraris (488 Pista, 360 Challenge Stradale, starting to see XX's around too), the Valkyrie and Valiant etc. There's also those that grab older Cup cars and track them to the track. There's absolutely a market for turn key, track focused, road legal Ferrari's.
You can have an air gap between two physical items - it doesn't matter if those physical items are air tight or not. Air gapped doesn't mean the items are prohibited to intake air (i.e. air tight), it just means they're prohibited to intake things _apart_ from air.
It's also a good paper-trail if you have an SLA. Pointing to a ticket saying "this is when we knew" makes time calculation for compensation very trivial and transparent. Of course if your salesforce account manager is like most, they don't need such "evidence" but in the past it has helped me.
We host our app on Heroku - the core service and a few microservices. The heroku dashboard is down, and we can't use the cli due to the in-browser auth callback that it needs (which is also down).
The status page itself is either saying nothing is wrong, or points to an error page[0]. The incident itself[1] hasn't been updated, which is pretty frustrating.
We can't submit a support ticket because, well, it requires the authentication procedure as well.
We use worker queues, and the queues are getting blown out because heroku can't action anything. We're having our microservices yo-yo now, which suggests things are getting worse, now better.
I've always been a huge Heroku advocate, but the last 5 years have been death by a thousand cuts.
Not sure what country you're from, but "blockout blinds" are likely what you're looking for. They blockout (essentially) all light and are operated like normal blinds.
The biggest difference is GitHub in your infrastructure is (nearly always) internal. Fly in your infrastructure is external. Users generally don't see when you have issues with GitHub, but they do generally see when you have issues with Fly.
I build an add-on for Heroku[0], have worked for a company on and off that's had all core services on Heroku for over 8 years, and I've put a lot of my side projects etc. on Heroku.
My experiences differ depending on the above, I've mostly use Render or an alternative for side projects now (just due to cost/forgettability). As a daily user of Heroku professionally - it's clear Heroku isn't a priority for Salesforce. Heroku has struggled to maintain any form of product development and, if anything, has become more unreliable over the last year or two.
As an add-on developer, my communication with Heroku has been fantastic. You can assume so because it's a direct revenue stream and feature expander - but my experience with other platforms isn't (iOS has slow/poor communication and docs, Chrome's extension support is non-existent and often not backwards compatible etc.). It's kind of re-ignited my love affair with Heroku, like it was pre-salesforce.
Overall I can't see us moving from Heroku unless costs demand us to - it's just too 'easy' to stay. Vendor lock in is real and I'm okay admitting that.
Sorry for ignorance, but how do you censor platforms you have no control over? If a tourist with a following posts it to Instagram, what can you actually do?
I feel like if you have the power to censor leak things you’d be worth a huge sum of money.
It’s impossible to know without a lot more details on your personal situation and the position of the company.
The main thing to keep in mind is most equity usually ends up being unrealised or diluted.
It really depends on how much you value money in your hand now, vs waiting. If you have a cliff and vesting schedule, can you see yourself waiting? If it’s a year cliff and you struggle to enjoy staying at places, you’ll end up with no equity and $20k worse off.
Instead of saying $20k, you should have said a percentage so it’s easier to gauge. If you’re on $50k, a bump to $70 is huge. If you’re on $250k, just do what you’re asked and it’s realistic that you can get a payrise + $20k after 12 months if you have your head on correctly.
It sounds like your experience was pretty terrible and I’m sorry that you’d spent formative and enjoyable years suffering.
We homeschool our kids and are generally quite the opposite (we’ve never been religious either). I wouldn’t say we are smarter than tertiary teachers in specific fields, but for the junior years it doesn’t really matter. Our kids are (electively) performing at higher grades than their age level requires, and we support that where they’re interested in it.
We do structured learning every day and also unstructured learning and just enjoying life. It’s a good balance that enables us to raise the happiest kids we can. My eldest has expressed an interest in going to school next year, we are fostering that interest and if he’s still keen next year we will enable that too.
People make blanket statements about homeschool, public school and private school. But after having kids one thing is certain: everyone’s experience is incredibly unique.
Depending on your access, you could easily install untreated hardwood flooring. You can use completely natural coatings to protect it (things like bees wax, even!) it will just require more maintenance. It’s a much more ‘natural’ portion than concrete or anything processed.
In many countries, including the UK (where the author is from), it's not illegal to talk openly and publicly about your salary. Contracts can have 'do not disclose your salary' but, in places like the UK, this is legally unenforceable[0]. It gets pretty grey though, in the UK it's allowed to protect you from underpayment and from bargaining etc. I reckon disclosing it publicly can be seen as a form of a basis for collective knowledge at the organisations, though.
High touch in the sense of being driven by product development. We let everyone make technical choices, sometimes autonomously but sometimes as a pitch. A part of technical leadership in smaller organisations is mitigating a lot of that “new hire/shiny thing” risk.
We used react a lot externally to the main product as early as 2014, but didn’t introduce it into the main product until we were comfortable.
I’m a Tech Lead for a SaaS product that’s been around since ~2010. Four or so years ago we stared piecemeal transitioning away from jQuery/Backbone to React. Nearly all of our main UI is React now, but it’s still pretty coupled to Backbone. There’s a lot more risk removing that, so we’ve not had enough of a reason to yet.
Basically the high touch (from a developer point) areas of the app are always the most modern and the first place to get whatever treatment we transition to (React, typescript etc) and there’s some really untouched areas that might remain prehistoric for years, and that’s fine.
Its worked pretty well for us, and I can’t see why it wouldn’t continue that way.