https://hnbadges.netlify.app/?user=languagehacker
meet.hn/city/us-Atlanta
---
- 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...
- Thanks, I hate it. Keep an eye out for Nathan Grayson sliding into your DMs though.
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.