I was thinking along parallel lines. If you have fuck-you money then sure: you just leave when asked to do something imoral. But if you are materially dependent on the job then you have battling imperatives that will stress you.
The first thought that popped into my head here was, "well I have no kids, so yeah if forced to choose between job and morality I'd just bounce and figure it out later". But if I DID have dependents it's harder.
I will say if the choice is between being imoral and _personally_ poor ... I'd like to think I'd rather just be poor.
edit. Then again this is also on us as people to anticipate and prepare for these dilemmas and not let ourselves be trapped in toxic situations. I suck at this and don't do any real forward planning like having a lot of savings or having a backup plan to getting out of a bad job. But that's on me.
> But if you are materially dependent on the job then you have battling imperatives that will stress you
I would like to offer a different perspective for you.
I’ve never been shouted at in my work life. And I also know a few people who complain about being shouted at, at all places of work they’ve had — and it’s difficult for me to empathize with them.
At some point I understood that I never allowed my coworkers or managers to shout at me, and in the rare occasions when their voice was raised, I had made myself very clear, and I quit on the spot had the situation ever happened again. As a result, I’ve always had very pleasant and respectful working conditions, with self-respecting people who I know will quit if abused, so I treat them with respect as well.
On the other hand, people who endure humiliation by imagining contrived moral dilemmas about why it’s good and right for them to continue suffering — suffer for decades wherever they are employed, as they seem to filter out and stick to workplaces where this is acceptable.
Are there really no jobs for your talent where you can be moral, or you’re prepared to endure immorality (and to be faithful employee to such businesses) until you’re old and frail?
It's not really random. Disease development in the Old World was a combo of long term urbanisation and animal husbandry. Urbanisation in the New World existed but wasn't as old and obviously there was way less animal husbandry. Also assuming the Bering straight crossing hypothesis humans probably left almost every freaking old world parasite and disease behind by the time they got into the americas. Hundreds of thousands or even millions of years of eveolution of diseases that evolved in Africa/Eurasia pretty much gets purged during that migration.
Sure, "random" isn't the right term for what I mean.
There were reasons, but neither side understood them!
From their perspective, it just so happened that 80-90% of the population on one side died within weeks of contact. Often the disease travelled faster than the invaders, so as the went inland they found mostly empty settlements they could just take over.
It's easy to see how both sides could think that the god(s), in their inscrutable ways, had decided to give the land to the Europeans.
This also played out in the opposite direction in Africa. There the Europeans just couldn't survive for long until Malaria treatments became available in the mid 1800s, and so Africa was colonized last. Since Africa is where humanity originated, it has the most diseases and parasites that specialize in feeding on us.
Many of the diseases that afflicted the old world may have evolved after humans crossed into North America, so there was never any resistance in the New World.
They were charging up hill in the mud. Noone really died from arrows, except maybe some of the horses. But a lot of their horses fell and then the knights ran back through their own infantry, though apparently that wasn't that big a deal in the battle.
The battlefield killing was done by light infantry wading in with daggers and hatchets apparently during a foot slog up the muddy hill which left the french heavy infantry exhausted. Another wave of killing afaik was when the captured prisoners were all executed since the english position seemed like it might be overrun by some follow up fighting.
(keep in mind the battle took hours and there was a lot more going on then just heavy horse riding up against arrows once or twice)
This is absurdly wrong. Most immigrants are poor people entering their new societies at the very bottom, not hipster digital nomads. Sometimes they are lower middle class in their own societies, but often they are pretty much at the bottom at home as well.
For whatever reason the west fails to successfully socialize an unacceptably large portion of the native born population.
A train engineer with decades of experience moved to the US when the war in Ukraine started. The job she could get here was as a nanny, watching children in her extended community, and even that was half a favor.
> For whatever reason the west fails to successfully socialize an unacceptably large portion of the native born population.
Part of the reason for that is protection and promotion of freedoms of individuals, which means that we expect the society to stay away from our lives, because we did try various forms of state and church hierarchies running our lives and we did not like it. If you come to the West or are born here learn what it is about and decide how you want to live your life. The same people complaining about the society not caring for all are those who wanted the society to leave them alone.
You need to consider the distinction between legal and illegal immigration for starters. Most legal immigrants are reasonably well off in their society of origin - enough so to afford the legal process (which is not cheap).
And yes, immigrants generally tend to end up lower on the social hierarchy in their new society as compared to the old one, but how is that relevant to what I wrote?
It's easier to steal pentagon contract money than money issued for highways or train tracks therefore military contracting has a higher profit margin therefore that's what the lobbyists advocate for.
This sounds good but doesn't actually make sense, like most corporate money-grabs. If cards accumulate in value, everyone is essentially playing for free(or indeed being paid to collect cards since generally the market rose faster than inflation). Everyone can sell their collection and if the secondary market is healthy they can get back what they spent on it and more.
This is the fundamental scam of the game-piece idea: it kills the secondary market and basically means instead of having the option to recycle your old decks into new ones you have to always pay $50/deck or whatever Hasbro is selling decks for.
You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully.
This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate where to put every file in a project or having to invent a new folder structure for every app we build fills me with a bizarre mixture of boredom and rage.
As with everything in life the people that whine about the medicine the most are the ones that make it necessary.
Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.
Totally, Rails is a great tool. So
is my gunsmith hammer. I can like it for what it does without arguing it's the best thing in the world for cutting wood or joining two pieces of metal together.
you're seriously convinced they would have had no problems if they chose something else? every codebase that lasts that long and is used that much is going to face very hard challenges as it scales and meets new landmarks.
the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs.
I'm also curious about YOUR choice of stack at this point.
I never said that some other stack wouldn't have problems. My point was that Rails is great at some problems and awful at others. No idea how this can be controversial at all. My impression seems to be that there is a group of fanboys that are not able to have any intelligent conversation on what their favorite tool is good for and what it's not good for.
In my day job I use mostly Rails. My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. Rails was great to get started fast.
Nothing wrong with using a press instead of a hammer at some point, they are just tools.
The Rails app I scaled posted half a meg of JSON on every save-request every 10-15 seconds. In Rails, we parsed it, converted some parts into HTML nodes in Nokogiri, sanitized it, and saved it to both mysql and cassandra.
It wasn't a problem other than that a better initial design (nothing to do with rails) could have made passing all that data not needed, which was better for mobile. We had about 600,000 customers.
How many requests per second are you talking about roughly? One major problem we face is that downstream services also have performance problems and have multi second response times. While waiting for the response, a whole rails worker is sitting idle, taking up hundreds of megabytes of memory for seconds.
Is there any comparably complete framework that does not need any significant adjustments even when it's used by 1000s of developers building the same app?
Can confirm. Nothing worse than figuring out what sort of "magic" is affecting a route in a huge Rails app. Oh look, a before_filter in a super class 4 levels up that is defined in an include helper. But wait, why isn't it affecting all calls and only some? Ah there's another chain of filters that you only can know about if you are familiar with the older Rails version API.
Rails is the "goto:" label of web frameworks. It's unbelievable how much it encourages spaghetti code and misdirection directly via its conventions.
I don't think it's necessarily bike shedding, and actually a lot of the sentiments resonated with me. Rails is a tool that does a tool's job. It's nice to know a hammer does hammer things when you're expecting it. If you need a level, maybe use a different tool. I think the main issue is everyone expecting it to be "one-size fits all." It was never meant to be that, really
This is part of the problem with your claim - many of us are not building CRUD apps, we are building complex enterprise software and there are unique challenges to solve.
At the end of the day, all programming is CRUD at various levels of abstraction. You read some data, and then create/update/delete various forms of related data in various locations, like your DBMS or maybe a file or your GPU's VRAM
Rails provides a way to approach CRUD via MVC. Controllers are your API. Models are the connection to the Database. Views are what the controllers render.
If your app doesn't do these 3 things - API, Database, and representation of your API - you don't need rails (I bet you do those three things). Other than that, you're free to layer on whatever architecture via ruby that you want on top of these basic rails constructs. If you don't like it, again don't use rails. It's opinionated for a reason
Then I think the focus should be on the API. At enterprise level, the API becomes the language, and the frameworks (and even departments to an extent) become the functions/methods.
on the off chance someone doesn't understand the subtext here.
BaseCamp is DHH's company's product. DHH is the creator of Ruby on Rails. He literally create RoR to build BaseCamp, which is exactly the type of software the other poster is claiming is problematic for RoR.
DHH is on record as having said RoR was evolved organically from the early code of BaseCamp.
> which is exactly the type of software the other poster is claiming is problematic for RoR.
I wasn't. I specifically did not mention any concrete examples. I presume parent misread it as "for project management rails is unsuited" which, indeed it's not: specifically because PM is very much CRUD and has relatively little and/or relatively simple business logic (It's not for nothing that the hello-world of nearly all frameworks around CRUD are "TODO lists", the simplest form of PM).
What I tried to say, is that your domain, your team, your timing, your specific planning and your kind of project and any combination thereof has different needs. A setup, architecture, framework, fits one or a few of these perfect. But never all of the combinations of them. Nor over time (today you are a one-man-shop, tomorrow a team of 6. Today you build a full-stack web, tomorrow you need APIs for integration. Today you build a CRUD app for some medication journal, tomorrow it pivots into a complex tool for medical research.)
It's so easy that there's like 5 or 6 of them that I know of in Romania alone and drivers will swap between 2-3 of them every day. So yeah, it's pretty trivial. While there's no reason to start one if you can't undercut Uber or whoever's already cutrate prices, that doesn't mean Uber has a lot of room to increase prices/profits.
I'll add that Ruby meta-programming has 2 pseudo-phases(at least in my mind): load time and 'true' run time. They're both technically run time, but smth like a has_many method in rails ActiveRecors runs once when the code is loaded, defines some other methods and doesn't run again while the process is running, normally.
You could also be defining methods pretty much whenever, for instance in response to user input, mutating the state of the process from that call onwards.
The former is much, much more common than the latter.
e. A blurring of the 2 is something like ActiveRecord defining field accessors dynamically once a DB connection is eatablished. You connect to the db and now your User model has email, first_name etc methods, unless you'd defined them already.
I'm guessing nothing quite like this could exist for Ecto(I vaguely know this isn't a super good comparison, Ecto is quite different from AR from what I remember).
That being said even that would still happen as part of a prod app's 'loading' phase so to speak rathet than during a request cycle.
Another difference between the two comes from Ruby having open classes, so there is no callback that says "no further changes will be made to this class". This means you need to postpone some meta-programming to certain events, like Rails telling the app has done initializing, or until something is invoked for the first time.
So you are right there are distinct phases but they are established by convention and practices. And sometimes it is different between dev and prod (lazy loading vs eager loading). Or at least it was back then. :)
> I'm guessing nothing quite like this could exist for Ecto
The first thought that popped into my head here was, "well I have no kids, so yeah if forced to choose between job and morality I'd just bounce and figure it out later". But if I DID have dependents it's harder.
I will say if the choice is between being imoral and _personally_ poor ... I'd like to think I'd rather just be poor.
edit. Then again this is also on us as people to anticipate and prepare for these dilemmas and not let ourselves be trapped in toxic situations. I suck at this and don't do any real forward planning like having a lot of savings or having a backup plan to getting out of a bad job. But that's on me.
Hope it works out alright for you!