A build step in your pipeline is fine because, chances are, you already have a build step in there.
3,381 karma · joined September 2, 2013
fer at fer dot ex why zee
https://www.fer.xyz
meet.hn/city/53.3493795,-6.2605593/Dublin
Socials: - github.com/fejiso
---
I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.
Which ones? I think there's always some way to isolate, even if ugly.
As some other comment said, it's like the Haskell IO monad and that's OK, because it lets you isolate and be aware of the implications of that code.
Same, but with peonzas/trompos[0]. It's interesting since it's also about breaking the other player's item thanks to the inertia provided by a string.
In short, they're hardcore spinning tops: large, generally with a metal tip, spun much faster due to the string winding, and as mentioned, the objective is to crack the other player's.
That's why on FB I mark my own writing as AI generated, and the AI generated slop as genuine. Because what is disguised as "transparency disclaimer" is just flagging content of what's a potential dataset to train from and what isn't.
Because it is a lie. Teams managed themselves and trusted their members.
People who were virtual employees, or whose team was in a different location than theirs, have been let go at different points of the layoffs/RTO mandates, when they existed before the pandemic.
This is a regression to a point that never existed in Amazon's history.
We use it internally and the technical debt is an enormous threat that IMO hasn't been properly gauged.
It's very very useful to carpet bomb code with APIs and patterns you're not familiar with, but it also leads to insane amounts of code duplication and unwieldy boilerplate if you're not careful, because:
1. One of the two big bias of the models is the fact that the training data is StackOverflow-type training data, which are examples and don't take context and constraints into account.
2. The other is the existing codebase, and it tends to copy/repeat things instead of suggesting you to refactor.
The first is mitigated by, well, doing your job and reviewing/editing what the LLM spat out.
The second can only be mitigated once diffs/commit history become part of the training data, and that's a much harder dataset to handle and tag, as some changes are good (refactorings) but other might be not (bugs that get corrected in subsequent commits) and no clear distinction as commit messages are effectively lies (nobody ever writes: bug introduced).
Not only that, merges/rebases/squashes alter/remove/add spurious meanings to the history, making everything blurrier.
The tech in the travel industry is cursed, and the pay is bad. Do not recommend.
PNR identifier and last name is the only reasonable key to use when a single PNR is meant to be shared among the GDS, the IT provider, the traveler and companions, hotels, car rentals companies, travel agencies and countless other players in the market (sometimes several of each at the same time).
But it's also true it relies on the traveler keeping the PNR reference secret.
Adding MFA would involve adding new segments to all sorts of EDI messages, more complex booking/ticketing/cancelling flows, and getting all those companies on the same page so shit works without impact.
It'd be possible and an impressive engineering effort, but also a royal PITA given all the moving parts in the travel industry.
The few times I had to cancel/rebook or similar I was next to the counter with my ID, but I can think that having people call you and/or send an email for you to click to confirm is easier and has less friction than revamping the whole GDS industry and their (ducks) legacy B2B interoperation.
The main exception would be heating, and even then, it's usually that the optimum performance is just really close to the top performance; e.g. imperfect combustion of more fuel being less efficient than perfect combustion of less.
For starters, the data is biased because the basal metabolic rate of someone who does sports is higher than someone who doesn't, and that's without taking into account the higher metabolic rate of people who are overweight/obese (albeit for different reasons), and even for people who are fit, runners are trained to be more efficient at running (duh).
But the underlying message isn't really all that insightful: the optimal running pace isn't the slowest nor the fastest, but somewhere in the middle, which is pretty obvious to anyone who's done some running.
> YMMV but as a software developer I am certainly not going to start throwing stones in a glass house. :)
I have absolutely no idea of what's involved when working as a GP/consultant, so I probably grossly underestimate their job, but in my interaction with them (involving my health as well as my family's) most of them seem to just put your case into a flowchart and prescribe along, because that's what reduces the liability to 0 and works most of the time. But if that's their job, they'll eventually be replaced by LLMs.
When you don't fall into the typical case, you'll have to go through retelling the whole story to all the flowchart ones (easily 80%) only to find along the way snake oil salesmen (10%), honest "I can't take your case" individuals (5%), and the 1-5% which actually feel like scientists and problem solvers.
(percentages pulled out of my rear but that's roughly my experience)
I think this is the "I live here" bias. I've hit most stans, each is unique and worth a visit in their own ways, but I give you that a random snapshot from Almaty could have been taken anywhere in the USSR.
The code wasn't simple, at all. It took active training of new arrivals for them to understand it. But it was very well thought out, with very few warts given the complexity, and extremely easy to extend (that was the main requirement, given constant changes in APIs and clients).
We had an API, with multiple concurrent versions, that transformed requests into an intermediate model, on which our business logic operated, later targetted external APIs (dozens of them, some REST, some SOAP, some under NDAs, some also with multiple versions), whose responses turned again into the intermediate model, with more business logic on our end, and a final response through our API. Each transaction got its context serialized so we could effectively have what was an, again improvised, "async/await"-like syntax in what was (trigger warning) C++03 code.
The person who engineered it didn't have formal CS background.
Even photos with signs in Irish were pointing to England, it's half funny, half offensive.
I (fixed desk) only get notices with a picture of how my desk should look like, and in that picture it looks like nobody works there. Granted, I'm a bit messy, but the standard I'm expected to follow is just bleak and sterile.
If anything, self-checkouts are a larger target to grift and yet they seem to do fine.
Barely use reddit since the API shenanigans, and I guess I never curated my Twitter feed because every time I go in I just see people getting angry and enjoying it.
"b-b-but other teams need visibility of your sprint!" no they don't. I don't think I've looked at other board other than by accident.