IMO this tool is basically allowing you to do that, it just takes care of the bookkeeping to associate the series of smaller PRs with eachother which is possible today but requires a lot of clicking.
176 karma · joined November 27, 2014
The terms and conditions say as much https://docs.github.com/en/site-policy/github-terms/github-t...
E.g. if you get a RPC request coming in, and make an RPC request in order to serve the incoming RPC request. The traced program needs to track some ID for that request from the time it comes in, through to the place where the the HTTP request comes out. And then that ID has to get injected into a header on the wire so the next program sees the same request ID.
IME that's where most of the overhead (and value) from a manual tracing library comes from.
In Github at least you can set the behavior to take the PR description by default as the squashed commit message. In fairness this is not the default. The default behavior for squash merges is to ask for a new commit message right as you hit the merge button, and the default is all of the messages from the commits being squashed together.
> make no effort to produce high-quality independent commits
I'm partial to sqaush merges when using github. I don't put much effort into the individual commit messages, instead I put lots of effort into the PR description (the thing reviewers will read, and what will eventually become the commit message in revision history). That said, one of my favorite features from gerrit at a past job was that the commit message itself could be reviewed.
Each job will always have to run a clone, always pay the cost of either bootstrapping a toolchain or download a giant container with the toolchain, and always have to download a big remote cache.
If I had infinity time, I'd build a CI system that found a runner that maintained some state (gasp!) about the build and went to a test runner that had most of its local build cache downloaded, source code cloned, and toolchain bootstrapped.
To take this example I found off the NYS assembly website legalizing adultery (it was the first one I found, I swear)
https://nyassembly.gov/leg/?default_fld=&leg_video=&bn=A0010...
It's phrased as "Section 255.17 of the penal law is REPEALED", but if you try to find "the penal law", but if you look up a a copy of the penal code do you see 255.17 in it? If so, how can you find out what was actually repealed. If not, do you need to hunt through every possible amendment to figure out the state of the law is at the time of reading?
I used to write low-scale Java apps, and now I write memory intensive Go apps. I've often wondered what would happen if Go did have a JVM style GC.
It's relatively common in Go to resort to idioms that let you avoid hitting the GC. Some things that come to mind:
* all the tricks you can do with a slice that have two slice headers pointing to the same block of memory [1]
* object pooling, something so common in Go it's part of the standard library [2]
Both are technically possible in Java, but I've never seen them used commonly (though in fairness I've never written performance critical Java.) If Go had a more sophisticated GC, would these techniques be necessary?
Also Java is supposed to be getting value types soon (tm) [3]
[1] https://ueokande.github.io/go-slice-tricks/
> noted that the city rule has a provision that drivers’ pay can’t be reduced because of the fee caps
This seems impossible to enforce right? The city can't reasonably have any insight into why driver fees change.
> Oh, also, the implementation of Kubernetes cron jobs is also complete garbage (spawning a new pod every job is insanely wasteful).
How often/how many cron jobs are you running that spawning a new pod per job is a problem ?
Similarly, lots of hosting providers wouldn't expose the guts of Apache to developers. They would give you some sftp credentials, and let you upload whatever PHP files you wanted. No need to think about Apache configurations (except maybe a few htaccess files).
Perhaps that's not a fair comparison because the way legalization has been going, at least in the U.S. looks like a cross between tobacco and gambling. Taxing tobacco feels like the more correct metaphor, but I'm not sure why.
There are lots of drawbacks to doing it that way, the worst of which is that you need to remember to override the method in CachedHTTPClient everytime you add a method to HTTPClient, and the compiler gives you no hints about it.
Even if that number is right, I would think that Uber/Ola cars have higher after-production emissions due to them being driven all day and being driven in city settings (as opposed to on a highway where cars are more efficient.)
The only way to know this for sure would be to ask half your applicant pool to do the test, and the other half to go through the exact same battery of interviews sans take home test and then see how many of the offers you extend are accepted.
Obviously this requires that you're a big enough company to split your applicants into two pools and still have a big enough sample size.
Whenever I talk to people involved in hiring about this, they balk at the idea (for okay reasons -- in theory doing that would mean less people filtered out by homework and more applicants rejected during in person interviews that take up engineer time.)
- they're moving "legacy" infrastructure off EC2 or similar onto Kubernetes and their service discovery stack is already in place. They end up bypassing cluster IPs and dealing directly with pod IPs. - they're starting with Istio or something similar from the get go because the native service discovery is hard to grok and leaves out a lot of the nice things that Istio gets you for free (once you've set it up)
There's lots of overlap, but I've not heard of anyone making a strong argument for the native service discovery.
And yes, Google cooperated in this specific case, but only after the problem got really bad. It's really hard to take a charitable view when Google, a large player in the ads space, and a company known for technical excellence, allows stuff like this to happen:
> An agency or advertiser looking to place an ad would only see the name of TBS.com in the ad exchange and not know they were buying ad space on a counterfeit site. Then the bots would visit the fake site and view the ad to generate revenue. (This technique of masquerading as a legitimate publisher is called domain spoofing. It’s a long-running issue, though a new standard called ads.txt [1] is helping curb it.)
This article (https://digiday.com/media/ft-warns-advertisers-discovering-h...) is a year and a half old. Google obviously had the resources to discover this years ago and failed to do so.
[1] https://www.youtube.com/channel/UCE31MqUy6nIMJ_f8y4R3_AA
Why ask users to import the certificate into the root certificate store instead of packaging the self-signed certificate with and specially loading it from the application. That seems easier from the users' perspective and more secure as you aren't touching the global certificate store.
Plenty of traditional bikers are folks who are using bike shares and do things like not wear helmets, ignore road signs, ride two abreast, and swerve without warning. Also a problem are the "pro" bikers (you know, the ones on a racing bike, fully decked out in gear) that tend to ride ~10 mph faster than everyone else and pass aggressively.
E-bikers on the other hand, go in a straight line, usually single file, without swerving and seem to follow traffic signs because they have an easier time accelerating and decelerating.
Again, just my anecdotal experience -- I ride ~5 miles to/from work in New York.
Fine it's impossible to correctly calculate externalities. I don't see the line from there to: "BigCo dumped a ton of waste in my pond, but it's unfair for the government coerce BigCo to compensate me because there's a chance the I might get more than the true value of that pond."