languagehacker

If Celery seems like overkill for your process, and you're really just looking to execute basic cron functioanlity, then why not just use crontab to invoke your Python script?

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?

Isn't postal arbitrage how the original Ponzi scheme started?

There are a lot of reasons why people are here illegally. Over 50 years we created an environment in Latin America that made it dangerous and unlivable for normal, law-abiding people. At the same time, we radically altered what we consider to be refugee status for immigration, and introduced rules that unfairly put requirements on other countries that refugees going over land need to apply for refugee status in every other country, whether or not there is infrastructure or jobs to support those refugees.

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.

There's a challenging burden of proof that starts even with what constitutes the ability to detain a person. US Citizens don't need to show anyone proof of citizenship due to a law that's been on the books since before World War II -- a law that was created after our legislators were disgusted by what was going on in Germany at the time. This means that for ICE to detain someone whose identity they don't already know 100%, there is a legal grey area where a citizen does not need to comply with their request. So how do they improve their accuracy? Sounds like racial profiling, right? That's because it is.

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.

For sure, using civil power, since these are all administrative violations and aren't considered felonies.

The issue isn't with the deportations -- it's actually with the change in tactic, and a lot of the extrajudicial behavior. Immigration is an absolute mess, and it's one we created ourselves with one bad policy after another. I'd recommend "Everyone Who Is Gone Is Here" to understand the 50+ year history of how American military and political involvement in Latin America created the instability which caused the refugee crisis -- and even created the cultural phenomena that resulted in the creation of MS13.

When the Cato institute publishes something like this it's all over. These guys used to be considered incredibly conservative. For them to submit something so level-headed and factual which goes counter to a Republican-led administration's politices indicates that the current government is being run not by folks engaging in good faith with our existing political institutions, but with radicals intent on twisting those institutions for their own agenda.

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.

For the first couple of paragraphs, I almost agreed with this dope. Thought he was a moderate on the wrong side of things after the next couple of paragraphs, and after the AI-generated anime picture, I'm pretty sure the guy is a groyper.

I miss Newgrounds so much

The Tesla board should just put a bumper sticker on Musk that said "I bought this before Elon went crazy". Like, how did you not know.

Will 2026 be the year hammers get a little phillips head on the back in case you run into one of those weird ribbed nails?

Interesting development. I had assumed a private equity company was behind this, but it seems like a deal brokered between two public companies, maybe struggling to show growth.

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.

Good old Jurafsky and Martin. Got to meet Dan Jurafsky when he visited UT back in '07 or so -- cool guy.

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.

Production-Ready GraphQL is a pretty good read for anyone who needs to familiarize themselves with enterprise issues associated with GraphQL.

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!

I've wondered for a while whether it's a dark pattern where they're trying to optimize for more text to speech in this post-literate world.

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.

Sure, but an informed opinion would mention that not only do these chips become obsolete quickly, but the ones that will survive long enough to become obsolete are likely to have a very fast and high failure rate.

Impressive that you have have that many assets under management and still not show a clear understanding of an industry you're prognosticating on. The author doesn't talk at all about the hardware aspect of this stuff such as the surprisingly short lifetime of the GPUs that are being rolled out at a break-neck pace. The recommendation that you take a moderate investment position and not overdo it could be shared without as much needless thinking out loud, and doesn't bring anything new to the conversation. Kind of like every other AI offering out there, if you think about it -- participating in something you don't understand because of FOMO.

Possibly the best thing John Milius has done -- I said what I said!

Mary Beard's SPQR is an amazing book about Rome and I recommend it to any fellow history nerds. If it wasn't for that book, I wouldn't have gotten the "Cataline conspiracy" joke in Mountainhead.

This made me think of The Tree that Owns Itself in Athens, GA: https://en.wikipedia.org/wiki/Tree_That_Owns_Itself

"What if I farmed everything out to an AI and felt like I accomplished something"

My first impression on property-based testing is that it's likely to introduce flakes that distract engineers from their task at hand, forcing them to investigate a new failed test in an area that they weren't even touching.

Just because you couldn't figure it out doesn't mean the capability wasn't there. More than ten years ago at this point I was running a massively scaled Celery + RabbitMQ + Redis deployment with excellent off-the-shelf reporting using Flower.

I don't see it mentioned enough in the comments here, but not considering Celery as an alternative to Django + async really is the missing puzzle piece here. Aside from application-level options that weren't explored, I'm wondering whether handling some of the file IO stuff with, for instance, nginx, might be a better fit for their use case.

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.

A very accessible and gentle introduction for the scientific set who may still be largely stuck on Conda. I liked it!

I thought The Body Keeps The Score was interesting and informative. I made sure to look up counterarguments afterwards, because there were definitely parts that I wasn't so keen on.

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.

Very disingenuous to put second-coming style prognostications from religious nutsos in the same list as people trying to use science, pattern analysis, or surveys of scholarly literature to identify when society will gradually break down from writing too many checks the environment or the economy can't cash.

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.

Any project that doesn't need 30 or more devs with various specialties working on it all at the same time doesn't need the complexity that frontend/backend separation introduces. I learned this the hard way through years of over-architecting 1-2 person projects as a freelancer. Nowadays, it's just Django with a little bit of Tailwind on top.

There's definitely a market for something like this, because most software companies at a certain size end up needing to build something like this. The real question is, how much work will you need to do to fit your current software to their paradigm in order to get the benefit? For a newer project, there's likely little sunk cost, but for anything that's already productionalized, I don't doubt that the rework -- particularly around all the devops bits and pieces -- will likely be significant. And then of course, from a strategic standpoint, you need to balance the risks vs. rewards of hitching your wagon to Flightcontrol's set of conventions.

There will be a really solid chunk of projects that find good cost savings using this platform -- especially teams that are resource-constrained on devops and don't consider it their core competency.

When Jeff Hodges gave a presentation of his "Notes on Distributed Systems for Youngbloods"[1] at Lookout Mobile Security back in like 2014 or 2015, he did this really interesting aside at the end that changed my perception of my job, and it was basically this. You don't get to avoid "politics" in software, because building is collaborative, and all collaboration is political. You'll only hurt yourself by avoiding leveling up in soft skills.

No matter how correct or elegant your code is or how good your idea is, if you haven't built the relationships or put consideration into the broader social dynamic, you're much less likely to succeed.

[1] https://www.somethingsimilar.com/2013/01/14/notes-on-distrib...