“Rails can’t scale” is so 10 years ago. It’s often other things like DB queries or network I/O that tend to be bottlenecks, or you have a huge Rails monolith that has a large memory footprint, or an application that isn’t well architected or optimized.
I mention Chinese social media specifically because I know it's not indexed so well by western search engines. You can't conclude someone has no social footprint until you've actually checked.
Regardless of how likely you think it is, finding a social media footprint would be useful information. Seek information first, reach conclusions second.
Production database access must always be locked down from external traffic, and only allow traffic from the production application or within the production environment.
Aside from mitigating local dev accidentally pointing to the prod db, if you have the db accessible externally means it’s susceptible to network attacks and password attacks
Ruby now has Fibers and other constructs for async like Ractor.
> Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.
It isn’t any less tricky than a Django or Express project. With any codebase discipline and regular tending to the garden of code is important to prevent weeds from growing.
If anything that Ruby (and Rails) has going against it is still the raw language performance and higher memory requirements/usage than its counterparts, which makes it less desirable for workloads that require low latency or small memory footprint
> Companies attempting to pay an engineer according to location, in my opinion, is another kind of discrimination. You are supposed to pay an employee based on his/her abilities, not her location.
So you’re saying, we should be paying engineers in Europe and in the US the same as an engineer in LATAM or India or Asia that has the same level of experience and skill.
The only way to be non discriminatory is to have a standardized formula of compensation that takes into account cost of living (rent, food, healthcare, taxes etc) where the final take home pay in locations around the world are equivalent - which I believe should be the case at most companies
It’s extremely rare to have projects be considered stable for years without any updates. Unless there are no external dependencies, uses very primitive or core language constructs, there’s always updates to be had - security updates, EOLs are common examples. What works in Python 2 might not work in Python 3
Software needs to be maintained. It is ever evolving. I am one of those that will not use a library that has not been updated in the last year, as I do not want to be stuck upgrading it to be compatible with Node 20 when Node 18 EOLs
Great that it works for you and your particular project.
Without knowing the details if your project and team, I’d take a monolith any day over 400 microrepos and the 70+ backend microservices. Our customers don’t care if it’s microservices or monoliths as long as it works and meets SLAs, so the question really is do I want to upgrade ruby or rails 400 times and deploy 100 services or just do it once in my monolith and deploy once?
Need to upgrade a gem that’s used in 100 of those repos to address a CVE - no thanks. Worse, 10 of those repos were owned by someone who left the company a year ago and since there were no PRs, no one knows how to work in the repo or understand what it does.
That isn't actually the question. I know it's not the question because we're capable of it, it is infrequent, and it takes on the order of single digit person hours a month for that type of concern for our particular project. Also, I didn't say 400 anything but repos. See some of my other comments for what those repos consist of.
> 10 of those repos were owned by someone who left the company a year ago
That's not how it works. Repos aren't "owned" by someone. Each repo stands on its own, is clearly testable on its own. Every one of our teammates is capable of updating every one of our projects because there is consistency between them.
If upgrading Rails or any gem scares you, you have other problems to deal with. For me personally (I'm relatively fast on this team) I can update Rails in all 20 of our Rails applications in maybe 30 minutes unless Rails caused a setback (this is somewhat frequent between propshaft and turbo). If Rails caused a setback, we have two dependencies (rails-application-operational and rails-application-development) that we can either include a patch or pin Rails. All told, it's a quick process.
You know what we don't have to spend time doing? Tracing callbacks across 30 entangled ActiveRecord models. Or anything else that comes from entanglement. We also don't need to entertain palliatives like packwerk and the like.
Cars break down all the time but at least they can be moved to the side of the road. Are Teslas not able to be moved once they run out of juice? They’re heavy and even with a few folks pushing from the back, is it able to disengage the parking brake?
> The handbrakes of electric cars, and some other modern cars, are controlled electronically, unlike those of traditional petrol and diesel cars, which are mechanical. This means that the handbrake often locks when the power fails and the car cannot be pushed or towed.
This sounds like a major oversight by Tesla as there should be some override in case a vehicle breaks down in a dangerous position or is blocking something important.
Not disabled, just overpowered. The winch can easily drag a car with locked up wheels. Very common in fact, e.g. automatic transmission that won't shift out of park, or handbrake malfunction, etc etc etc
EVs can’t be towed with a winch style tow truck, at least without frying them. A flat bed tow truck is required (also recommended for many newer ICEs).
That is an unhelpful quote. Yes, some cars have electronic parking brakes. It is quite common on new cars today. But they typically require being affirmatively commanded to change between their applied and unapplied states. Nothing about the general existence of electronic parking brakes explains why this particular vehicle would have one engaged mid-turn.
> Nothing about the general existence of electronic parking brakes explains why this particular vehicle would have one engaged mid-turn.
Did you notice the part that it run out of battery mid-turn? It seems that the brakes are designed to fail safe in case of a battery failure. I see how someone could argue for that as a design choice. The fact that there is no way to emergency release them without power is more questionable.
Sorry, but it doesn't make sense why a Tesla would apply the parking brake when the big battery dies, since the separate 12V battery would power the brake mechanism. If that 12V also happened to die at the same moment (highly unlikely), the parking brake would have been stuck in the released position, not applied.
And 9 hours? They could have called one of those tow trucks who haul away an illegally parked vehicle in a matter of seconds.
"Fail safe" is slamming on the brakes on a power failure? I heard a funny story about a guy who was used to chewing while driving and he'd open the door a crack to spit. Apparently some cars engage brakes if a door opens and he was driving his son's new Jeep going 50 mph.
It seems the wrong choice to me as a handbrake can be emulated by shoving some bricks under the wheels, and a non-movable vehicle could cause serious issues for other people.
Other car models have handbrakes and/or can be left in a gear that locks the wheels.
They should have called a parking enforcement truck that carries rollers that attach to the locked wheels, they could have moved the car pretty quickly.
Most electronic handbrakes just push out a cam against the rotor. Most designs have a way to back the cam out with a wrench or tool.
However sometimes access can be ridiculous I believe BMW's release requires you digging around in the rear seating area for a socket to put a allen-key like shaft into to ultimately back it out. Some vehicles you'd have to jack up a corner to ultimately back it out.
It can vary widely from manufacturer to manufacturer, so it's unlikely something a recovery service would know off-hand since in general a "stuck" parking brake (or automatic transmission parking pawl) is an edge case situation for them.
If the power failed on most vehicles with electronic parking brakes while you were driving, you wouldn’t have the parking brake applied. And it would remain that way. As there wouldn’t be any power to rotate the mechanism into the applied position.
No, but a situation that happened right outside my home is someone too busy looking at their phone bashed their BMW 3-series into the curb and utility pole, and then decided to put the automatic transmission in park before they got out of the vehicle.
And when they got back in, they were unable to remove it from park and put it in neutral.
The previous model you would’ve apparently been able to remove some center console trim on the transmission tunnel and insert the key into a covered keyhole to release the parking pawl. On this newer generation? Jack the car up, get underneath, remove an access panel, and then use a wrench to back out the parking pawl. What a pain in the ass.
Normal turbocharged 4-popper, not a hybrid or a BEV. Once it was put in park after a crash, car decided it was game over.
It was ultimately dragged up onto a flatbed, probably partially flatspotting the tires in the process. The guy sent by AAA had no intention (or the equipment) to safely jack up the car on a busy street to remove the pawl, and probably didn’t even want to even if he knew what to do.
My understanding is that many/most modern cars [0] have an electronic parking brake, and soon enough all of them will.
Of course, a headline such as “car with electronic handbrake breaks down mid-turn…” wouldn’t have had the same clickability. I’m shocked - shocked! - to find a “news” organization sacrificing truth for outrage!
[0] E-handbrakes aren’t a great fit to a manual transmission (or are they?) but I suspect the days of manual transmissions are numbered: electric cars no more need a manual transmission than they need a buggy whip.
On the other hand there are also numerous premium ICE cars which, if they break down in a specific way, can’t be placed into neutral without appropriate tools. This isn’t a new EV thing.
I’ve managed teams that have been excellent without scrum. Then there’s one or two teams that just cannot get things done and are all over the place. Had to introduce scrum to get more structure and accountability to getting things done. Once the team started having a good cadence, slowly weaned off scrum.
Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’
Different teams get by with different amounts of Scrum Processes.
Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives.
When the team gets better (and there isn't much turnover), you can relax the Processes.
I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)
