271–280 of 423 posts
Earlier quoted context omitted.
You definitely can, although it would be unlawful under the GDPR without user consent, so you could never release the figures publicly.
It wouldn't if you're not tracking user identity. Websites get this data pretty much by default and they don't need consent for it.
Earlier quoted context omitted.
What's wrong with checking for updates upon start once (and cache per day) For me that would also be wrong, if I cannot disable it in the configuration. I do bot want to extend startup time.
Wait until you learn about non-blocking IO. And threads. It's a whole new world out there.
Earlier quoted context omitted.
> their software also downloaded a 250MB update file every five minutes How on earth is a screen recording app 250 megabytes
As I recall, it’s an Electron app. I just checked and the current version of Google Chrome is 635 MB, with its DMG being 224 MB. So yes, it’s insane, but easy to see where the size comes from.
Also webapps are just great nowadays most OS support install PWA's fairly decently no?
ffs
Earlier quoted context omitted.
When I built an app that “phones home” regularly, I added the ability for the backend to respond to the client with an override backoff that the client would respect over the default.
Why not just use http retry-after? then you can use middleware/proxy to control this behavior. Downside here is that system operation becomes more opauqe and fragmented across systems.
For people finding this thread via web search in the future: screen.studio is macOS screen recording software that checks for updates every five minutes. Somehow, that alone is NOT the bug described in this post. The /other/ bug described in this blog is: their software also downloaded a 250MB update file every five minutes. The software developers there consider all of this normal except the actual download, which c…
Little Snitch catches these update request checks and I realize now that it should have an additional rule meta which is *how often* this endpoint request should be allowed (LS should allow throttling not just yes / no)
Earlier quoted context omitted.
> Code reviews kill velocity - introduce context switching, and are make work This is the same point three times, and I don't agree with it. This is like saying tests kill velocity, there's nothing high velocity about introducing bugs to your code base. Everything introduces context switching, there's nothing special about code reviews that makes it worse than answering emails, but I'm not going to ignore an importan…
> This is the same point three times No it isn’t. Fake work, synchronization, and context switching are all separate problems. > code reviews are a way to catch those I said you can do reviews - but there is no reason to stop work to do them. Why not require two or three reviews if they are so helpful at finding mistakes? I agree everyone makes mistakes - that’s why I would design a process around fixing mistakes, no…
Places do? a lot of opensource projects have the concept of dual reviews, and a lot of code bases have CODEOWNERS to ensure the people with the context review the code, so you could have 5-10 reviewers if you do a large PR
For people finding this thread via web search in the future: screen.studio is macOS screen recording software that checks for updates every five minutes. Somehow, that alone is NOT the bug described in this post. The /other/ bug described in this blog is: their software also downloaded a 250MB update file every five minutes. The software developers there consider all of this normal except the actual download, which c…
Earlier quoted context omitted.
> Code reviews kill velocity - introduce context switching, and are make work This is the same point three times, and I don't agree with it. This is like saying tests kill velocity, there's nothing high velocity about introducing bugs to your code base. Everything introduces context switching, there's nothing special about code reviews that makes it worse than answering emails, but I'm not going to ignore an importan…
> This is the same point three times No it isn’t. Fake work, synchronization, and context switching are all separate problems. > code reviews are a way to catch those I said you can do reviews - but there is no reason to stop work to do them. Why not require two or three reviews if they are so helpful at finding mistakes? I agree everyone makes mistakes - that’s why I would design a process around fixing mistakes, no…
Context switching is a problem because it...kills velocity. Fake work is a problem because it kills velocity. You're saying it's time that could be better spent elsewhere, but trying to make it sound wider. I disagree with the premise.
Synchronization is a new word, unrelated to what you originally wrote.
> How many times have you gone back to address review comments and introduced a regression because you no longer have the context in your head?
Never? I am not unable to code in a branch after a few days away from it. If I were, I would want reviews for sure! Maybe you have had reviews where people are suggesting large, unnecessary structural changes, which I agree would be a waste of time. We're just looking for bug fixes and acceptably readable code. I wouldn't want reviewers opining on a new architecture they read about that morning.
I am always kind of a stickler about code reviews. I once had a manager tell me that I should leave more to QA with an offhand comment along the lines of "what is the worst that could happen" to which I replied without missing a beat "We all lose our jobs. We are always one bad line of code away from losing our jobs" The number of times I have caught junior or even experienced devs writing potential PII leaks is abso…
Code reviews kill velocity - introduce context switching, and are make work, it feels like you’re doing something to make a PR etc but your not. The context it makes the most sense is accepting code from strangers in a low trust environment. The alternative to trying to prevent mistakes is making it easy to find and correct them. Run CI on code after it’s been merged and send out emails if it’s failed. At the end of…
Yes, they kill your velocity. However, the velocity of a team can be massively increased by shipping small things a lot more often.
Stable branches that sit around for weeks are the real velocity killer, and make things a lot more risky on deployment.