1,726 karma · joined June 29, 2010
https://hnbadges.netlify.app/?user=languagehacker
meet.hn/city/us-Atlanta
---
I can think of two major ways to operationalize a Python script that needs to run continuously. One is with containerization, which usually means Kubernetes, which already has a perfectly fine resource definition for cronjobs. The other approach is to run the script in a bare metal or VM, which would mean defining a service to ensure that the process can be managed appropriately, restarted if it dies, and the like. In other words, defining a service is about just as much effort as defining a cronjob, and there's no escape from some amount of "ops work" that isn't encapsulated in a Python script.
So why not just use the tried-and-true prior art than worry about building and supporting your own secret third thing that others would need to learn, support, maintain, and keep in mind when debugging a problem?
This is all while companies reap the benefit of and build their pricing structures off of cheap, undocumented labor. We are profiting off of criminalizing people who are just trying to live their lives.
You might count yourself fortunate not to be in this kind of a predicament, but it may benefit you to consider educating yourself on the subject and having a bit of empathy for others instead of relying on categorical absolutes.
Your analogy of an illegally parked car is spurious because where a car may park is pretty unequivocal. I hope that what I've described here helps you understand that this would be like someone choosing not to tow a Ford but opting to to tow a Kia even though they're parked against the same red curb.
Please remember that 23% of those with no conviction but pending charges should be considered innocent until proven guilty. If you get hit with a traffic stop, you shouldn't be lumped in with violent offenders. That's not how our justice system works.
Something tells me the outcome will likely be the same -- years of trying to get competing systems to get aligned or absorbed, attrition of all the most important people who are ready to move on and do more interesting work, and ultimately a poorer experience for the customer.
But what do I know.
This one and Manning and Schutze's "Dice Book" (Foundations of Statistical Natural Language Processing) were what got me into computational linguistics, and eventually web development.
My favorite saying on this subject is that any sufficiently expressive REST API takes on GraphQL-like properties. In other words, if you're planning on a complex API, GraphQL and its related libraries often comes with batteries-included conventions for things you're going to need anyway.
I also like that GraphQL's schema-driven approach allows you to make useful declarations that can also be utilized in non-HTTP use cases (such as pub/sub) and keep much of the benefits of predictability.
IMO the main GraphQL solutions out there should have richer integrations into OpenTelemetry so that many of the issues the author raises aren't as egregious.
Many of the struggles people encounter with the GraphQL and React stack is that it's simply very heavyweight for many commodity solutions. Much as folks are encouraging just going the monorepo route these days, make sure that your solution can't be accommodated by server-side rendering, a simple REST API, and a little bit of vanilla JS. It might get you further than you think!
The iOS keyboard "just not working" is something I gripe about pretty much every day as a symptom of the world getting quantifiably worse than even five if not ten years ago, alongside a whole laundry list of enshittification transgressions.
Once you're in the situation of supporting a production system with some of the limitations mentioned, you also owe it to yourself to truly evaluate all available options. A rewrite is rarely the right solution. From an engineering standpoint, assuming you knew the requirements pretty early on, painting yourself into a bad enough corner to scrap the whole thing and pick a new language gives me significant pause for thought.
In all honesty I consider a lot of this blog post to be a real cause for concern -- the tone, the conflating arguments (if your tests were bad before, just revisit them), the premature concern around scaling. It really feels like they may have jumped to an expensive conclusion without adequate research.
In an interview, I would not advance a candidate like this. If I had a report who exhibited this kind of reasoning, I'd be drilling them on fundamentals and double-checking their work through the entire engineering process.
Psychology and other social sciences are too multi-variate to speculate on, and the HRB exists so that we don't commit atrocities in the name of properly isolating variables as we poke at the black box we call the human mind. You're never going to get anything right, but we should definitely be referencing surveys of studies instead of single studies. So there's at least one point there for appropriate rigor. Not getting the interpretation of those studies right definitely seems unethical, but so does all of the misconduct stuff Van Der Kolk has been mired in.
It's a disingenuous argument to say that your body doesn't change from a traumatic experience, or that stress doesn't express itself through the body sometimes. It's also problematic to say that because it happens to you doesn't mean you can't work through it and learn to manage it or even control it. What I gleaned from the book is that if I have a physical sensation that I can map to stress or a past experience of trauma, I can understand it, label it, and grow from it.
I gotta say I didn't know about this Johnny Silverhand post, but I hope that if these things don't come to fruition he still finds time to stick it to the corpos in the most rockerboy way possible.