One line of code that did cost $8k
pietrasiak.com
pietrasiak.com
Even once a day seems excessive.
Thy cynic in me sees a pattern of disregard for other people's resources like with electron. Being a good software citizen is also realising that the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities. It feels like every tray daemon and widget assumes they are the main reason the computer is running and load a web view, 3 windows services and scheduled tasks.
Admittedly the App in question is interactive, but the same principle holds.
Categorical imperative hah:
Construct in a way that you accept all tray icons to be constructed like.
Aside: If your users are in the same time zone you may not want to do checks/updates on startup per se in order to avoid putting all your update load into the same time slice.
This one bite my in the ass with a login used by IRL offices which all wanted to log in at 9:00 at the same time lol
The 5 minute bug was introduced while fixing this issue. But it was a bad one: I have so many apps "randomly" popping update notifications up all the time: Skype and Fantastical are the two worst, seemingly every day. The popups interrupt me when working, and _take keyboard focus_ meaning I lose the last half of a sentence, or sometimes even dismiss the dialog before I realise it's appeared.
> the product is not the main task running on a computer and it's not acceptable to make decisions about other peoples priorities
Yes! One thing I loved about early macOS (about OS X Tiger - Snow Leopard days) was that I never saw apps steal focus. On Windows at the time it happened all the time in various ways, but never on Mac. That included when apps started: if you were working in an app and started another but kept working in the first, the second started with the window in the background. It was lovely.
1. Prevent focus stealing (again)
2. Probably more in Sparkle than macOS itself: apps today update constantly. I think it comes from web apps where you can deploy an update and people get it without realising, but updating a desktop app causes an interruption, so it shouldn't happen nearly as often. You end up with multiple apps during the day asking for updates. Apple tried to solve this through the App Store but many apps don't use it and use their own update mechanism, usually Sparkle.
So the Sparkle framework should collect all apps wanting to update and show a single notification (not a popup, a notification) once a day. Clicking it would show all apps that want to update. If you want to read release notes etc, you can there. But a single, centralised, shown via notifications not popups update mechanism for all Sparkle-enabled apps would be a _huge_ boost.
Good point, when did Mac OS lose that? It's insulting if you know how it used to be.
The absolute worst are the ones that steal it while running in the background, unpredictably and with no visible UI.
[1]: https://superuser.com/questions/734007/how-do-i-tell-which-a... [2]: https://apple.stackexchange.com/questions/123730/is-there-a-...
Part of it is just incompetence. Bootcamp dev is used to coding web apps where the code just gets to the client's machine every time (10 mb single page apps). When they transition to Electron, because it works with the same web tech they memorized, they see nothing wrong with doing these frequent updates.
Part of that is why I don't hate the idea of App Stores on desktop to distribute programs; The store can handle checking for update once per day instead of every app implementing it's own logic.
No, it doesn't. People used desktop apps perfectly fine before the always-on phone-home era of nearly universal broadband.
What's more troubling though is that this is somehow a story about monitoring cloud costs, and not a story about why your update interval was every five minutes instead of daily; or why it would auto-download instead of politely (no popups!) letting the user know there was an update; or why you failed to reconsider the fundamentals of your design in the face of the first round of negative feedback.
Your users told you they felt harassed and interrupted by your prompts. That's why you were making this change in the first place. That should have told you something.
Don't do it like the OP clearly, and it's really sad that desktops can't provide an experience like mobile where updates are platform managed but you still gotta do it.
there needs to be some auto updater
but you don't necessary need to have some
or in other words you normally want to integrate into existing update services, e.g. then package manager on linux. And if it then doesn't get updated e.g. because people don't update their system at all then that's their choice and problem IMHO. Just flag a warning/error once the API to your service changed too much or similar.
If you're not on a Linux distro then you have neither hence the auto-updaters.
Users should not have to update, applications should not auto-update unless asked specifically.
An update should be voluntary, not mandatory.
I hate finding a different application each time I open the same application. Particularly if it's a feature change or worse, a whole UI change.
This applies to desktop apps, saas apps, appliances, cars..
It does worry me that this may not be true anymore. How many years of the “slowly boiling frog” are necessary, with people growing increasing dependent on software they can’t control running only on others’ computers, before they forget what having locally-controlled software was like? How about young people or those who came to computers late in life who have known nothing different?
I’m increasingly resigned to the fact that the industry will wipe away this past. Old man “yells at cloud”, indeed.
I hate security updates that has zero impact on my use case to be applied automatically.
Like a fix for amd64 arch applied for an app currently only running on arm64.
What do you mean? There's an App Store for Mac users and there's the Windows Store for Windows users. I bet Linux has some similar offerings as well that I'm not aware of.
The services are there but developers have to jump through a bunch of (compliance) hoops (for good reasons) before they're accepted and it's easier to just let users download a ZIP from your landing page.
And then it's up to the OS that has more complete information to make decisions on when (i.e. don't check for updates on power saving mode).
A better solution would be for the system package manager to allow programs to add their own update servers. Assuming the developers package their programs the same way the system does, this allows you to use the exact same update logic.
Most linuxes allow this. Add a third party repository to you sources, and you can update their software with the rest of your system.
Ideally, you would have a more locked down version, where you can restrict the permissions of a given repository; although I'm not aware of anyone that has done that yet
For decades before there was an app store and a windows store, yes.
I feel like developer / publisher expectations are what changed, not the users’.
The allure of telemetry (even if it’s actually used for telemetry, not for nefarious spying and data collection) is just too much for most developers or publishers to resist. As somebody else said, these 5 minute update “pings” seem less, to me, about updates and more about near-realtime usage monitoring.
If it has been about 3 months since the user last updated; it will prompt the user to update to the latest version when the application starts (not some popup when they are in the middle of doing something important).
Yes, and people used cars perfectly well before seatbelts. Except the people that died.
If your application is internet connected then you need a good update story so that (if nothing else) you can push out security updates. This is true of everything from embedded firmware to desktop apps.
This is why I use Little Snitch, an application firewall that blocks requests like this and gives me some control over which applications are phoning home all the time. There’s no reason a desktop application should check for updates every 5 minutes. Once a month ought to do it without a compelling reason for more. But none of the lessons learned in the article show any attempt to reevaluate the update check frequency.
Especially in a case like screen studio where it's under active development.
Mandatory updates should only happen for critical security issues and even those don't need to be fixed on a five minute interval, once a day at most for a check and less frequently is probably fine as well unless the app is absolutely mission critical and people will die. And even then you should probably wonder if your QA is so bad that you need to be able to intervene on a moments notice, better to design your process in such a way that you can alert the user rather than to forcibly upgrade their system, especially if there is a chance that you'll get it wrong (again).
An upgrade is always a burden on the users, so you really don't want to do this too often and even if you are capable of releasing multiple updates per week it would be ridiculous to expect your users to follow that frequency.
Especially if you are like Nextcloud client - just killing Explorer if you like so (without asking the user first) and then even rebooting the machine without asking user first.
It's a glorified sync client, why the hell it should behave like that?
However those rapid updates also increase the risk of a bug in a release, and so maybe a more regular update check is needed during that time?
Adam is also following the "build in public" marketing strategy, warts and all. It's worked very well, he has had massive growth in sales. The combination of building in public, a product that is "visual" and one that effectively advertises itself, is very clever.
If your background is web apps with CI, thinking you need a 5min update check interval is an easy trap to fall into.
At startup is perfectly fine. Then once every 24 hours later if the app hasn't exited is also perfectly fine.
More often than that is too often. Every 5 minutes? That's ridiculous.
No. There is enough apps what I start, use and close. Why it should check the update every time it starts?
And this is even more irritating when the update check isn't working for some reason, eg update URI is not available but overall Internet works, now you sit there and wait while the update checker timeouts. Why, why?
This is how you deal with a situation like this that you’ve caused. Accidents happen, what matters is how you clean up after.
- Why check every 5 minutes? It's not like anyone will die if you wait a day to upgrade.
- Why download it without user confirmation. This is the worst one.
- The timer should not be stopped, or the user is forced to install the last downloaded update before they can install the latest.
It seems unwarranted to go to so much trouble for a screen recorder app, when just checking for an update at startup and prompting the user to go to the website would have been enough.
The whole take-away of this article feels backwards. Instead of going 'hey maybe we should not just download stuff in the background without prompt', the author doubles down and actually proposes to add a way for the server to signal to the client that an update should be forced.
I'm actually baffled by this entire thing.
>The app checks for the update every 5 minutes or when the user activates the app.
>Normally, when the app detected the update - it downloaded it and stopped the 5 minutes interval until the user installed it and restarted it.
To me this reads as them downloading the update unprompted (as they mention their issue with the previous updater was that it would prompt the users every 5 minutes, which would be solved by just not checking every 5 minutes).
Either way, whatever the bug and its effects are, my gripe is that their conclusion is to add a way for them to remotely force-updates. As opposed to just notifying once or any of the other hundred ways to handle auto-updates that don't involve you remotely forcing an update.
Edit: the founder has confirmed in the comments the app does download without user confirmation, so my original point still stands.
That's in contrast to being interrupted twice (once to download, then again to restart) or a single long interruption (shutting down, then downloading, then restarting).
Of course, it's a different matter if the user doesn't want the update. But we developers don't like to think about that :)
Oof, imagine you're using the app to demo something and bam update Lol
But also: a check every 5 minutes? I understand what you're saying but the only reason those interruptions are frustrating is because of the high volume of daily updates. This could be solved by just keeping this update-frequency reserved for beta users and maintaining a more sane update-frequency for regular users (now what a sane update-frequency is, is a whole other discussion judging by the comments so far :P)
Now I’m not saying coding is rocket science (because it isn't), but there are certain types of people who are a little (too?) obsessed with thinking of ways their logic can break and covering it with checks and tests… I'm guessing that designers are less likely to be one of those.
I love designers, btw. I think UI/UX is a hugely underrated discipline (see: "dark patterns", designing for safety). But unless you stare at logic all day, the implications of a code change like this might not immediately strike you as a risk.
But my issues with this aren't really related to code: * downloading without user 'consent' (in the loosest sense of the word) * and mainly: a proposed fix being a way the server can force an update on the user.
This whole issue just stems from the unreasonably high update-frequency imposed by the developer. They aren't addressing that and instead conclude that perhaps they can avoid a high bill by building remote code-execution into their app. As opposed to just adding a toggle and letting users decide whether they want updates to be auto downloaded. I would argue that's more of a UI/UX issue than a coding issue.
Yeah, it's a pain in the neck. If I've got 20 bits of software on my PC and they all update once a month, then most days I'm going to get a random popup asking to update. Just get on and do it please.
That super high speed 1Gb fiber connection? The one that STILL has the 1Tb/Mo cap? You can blow through it in an afternoon with one poorly constrained app (e.g. Torrenting)
Same here. Google has _company ending_ amounts of bandwidth in their datacenters and you can lose everything without knowing it.
(See also medical billing)
The right solution would be throttling of spending - easy way to set proper limits, good notifications etc. It's possible to set up all these limits but nowhere near as easy as it should be. Also, how easy would it be for Google to send you an email saying "your spend looks a bit different than normal due to this traffic here"!
But yes, Google and others should implement a cap.
My dislike of ISPs is evergreen.
The issue is not the bug anymore but the update process.
These comments in HN might provide much more insights than the bug itself.
I posted this because it's a good war story, we can all learn from it, and enjoying it at the same time. Laugh along with the OP.
Point is, don't jump to conclusions that someone has made a choice for ulterior purposes, given them the benefit of the doubt. Don't tare someone down because you think they made a silly mistake, we are better than that!
Screen Studio is a solo founder, making an awesome product and releasing updates to it almost daily!
Adam has fixed the bug and changed the interval to 3 hours - Chrome for context has an interval or 5 hours for update checking: https://support.google.com/chrome/a/answer/6350036?hl=en#zip...
> Google Update checks for the latest update approximately every 5 hours
I would have loved to read mention of "testing" or "regression tests" in the author's summary of learnings. "Be careful" and "monitor bandwidth" don't really resonate with me as a sign the author gets it yet.
And should had set it to at least a week. It's not some 911/mission/missile critical program, there is absolutely no reason for checking that often.
> I'm incredibly disappointed in some of the comments here
Because you are the one of the people who thinks what phoning home every 5 minutes/3 hours is perfectly fine.
> I posted this because it's a good war story
Oh yes, it's a goooood war story how 'move fast for no fucking reason' gave trouble for everyone.
If I'm reading this correctly, the update mechanism stops if there is updated downloaded and waiting. So if user just doesn't install it, it will not get the versions after that?
Seems like whole logic might have more issues, beyond the basic uselessness.
I've read the article and saw no justification for that.
If you don't have a billing alarm setup, stop reading HN and add one now.
I understand that for revenue-producing production workloads, stop spending money vs. burn everything down isn't always an obvious decision. But, for for many personal workload cases, I absolutely want to stop spending money above a certain level no questions asked.
Thanks for all the comments.
Why 5 minutes? Well I ask this question myself as well. I think it was bad and risky idea.
You create MVP and you make 20 decisions like this a day. I probably thought "why not" as it was stopping anyway and I released a few versions a day at times and wanted to get feedback and crash reports quickly.
I did change it now to 3 hours.
Why downloading it without user confirmation?
Well - because this is how Electron auto updater works under the hood (checking for update = downloading it) and it cannot be customized without implementing a lot of the logic by myself. I'll soon modify it and do exactly that, but I was creating MVP, got traction and as solo dev I had to carefully pick things to focus on. Electron auto updater works and is battle tested so I picked it knowing this limitation and suboptimal flow.
---
So I understand a lot of critique you're making and I agree with it. It's just I was making compromises, iterating quickly and making silly mistakes.
Fair enough people make mistakes...
> I did change it now to 3 hours.
lol
Yay, one more argument against Electron and the likes.
> this is how Electron auto updater works under the hood (checking for update = downloading it)
Electron auto updater seems too raw, for an app that has a decent size.
> I did change it now to 3 hours.
In my opinion, it is still too frequent. Ideally, the user should be able to set his preference and the app should have a less aggressive default (once a day seem more than enough for most cases).
1 for Alpha/dev/beta testing, whatever, and 1 for "stable".
Allow users the option of being beta testers and getting updates every 3 hours, and if they do not opt in, they're put in the weekly update "stable" group that gets the most reliable and solid but up-to-date version of the app at that time.
I did have 3 months of savings left and wanted to pursue my dream of creating a start-up.
I did create a fully working desktop app, a high-quality design for it, a landing page, an entire deployment infrastructure for the website, and uploading new version artifacts. While doing that, I was also taking care of all this marketing (30k unique website visitors a month on avg - analytics is public here: https://plausible.io/screen.studio). And a lot of other shit I don't even remember.
At the same time, you were working at a company where very likely at least one person was working on each of those areas independently, and most of the people did not give a damn if there would be a month delay in some area.
And then, you simply explain to me to compare version strings as if you've discovered a circle. WTF. It is a damn obvious thing, and it, of course, happens. The bug was about a whole different thing, but I'll not even try to explain it as I already did and it didn't prevent you from writing this bs. I wonder if you ever think how would you feel if your co-worker wrote a code review pointing out obvious things you did correctly, not related to the context of the PR at all, and ending it with "Simple and light weight." punchline. Maybe it would give your team an amazing opportunity for a long lunch break to discuss things.
this is really annoying, and this triggered me to write my challenging question.
I really doubt you'd be so "mistakes-free" and "I know it all" if you switched roles with your CTO for a week while all devs will take a week-off. If you write comments to solo founders so confidently, maybe you should consider that or if you're not willing to, to fucking think twice before writing comments next time thinking you're a guru because you nail your full time work.
Looking at the confidence you express your opinion (you actually don't express an opinion, you state your opinion as a fact), I believe there is no slightest thought like "maybe I miss something" or "maybe I'd also do exactly the same thing in this person shoes" and other shit like that.
I admire you for being careful and always thinking through all possible scenarios. On the other hand, I enjoy my life as a founder of a startup that has traction (and all its benefits of it). I'll risk betting that this difference is there precisely because you likely never make such mistakes, and you look at people who do from a perspective of "I know it all, and I'll tell you what you should do." ("Simple and light weight.") (note: it is possible you simply don't dream about founding a start-up which is totally fine. But even then, I believe it is a fundamental mistake to look at people who do create start-ups from the perspective of full-time-work and projecting your perspective on theirs)
--------------
I have no idea why the hell I even discuss with your "compare strings" wisdom. I just wasted 1 hour and half the emotional energy I have for this day and it's 9AM.
I can set a connection as "metered", whatever that means, but no way to set a limit of max throughput (speed/data) whilst on wifi. Android/Google treats WiFi as an unlimited resource, where the OS can consume as much data as possible (so that all the ad tracker networks don't miss out).
Android needs to:
1: Let you disable networking on any app (inc. system) on AOSP
2: Warn you (you know, the 'smart' element of smartphone) when an app consumes an 'unusually' high amount of data - if one app has consumed 200%+ more than any other app maybe, just maybe there should be a notification as such.
This is a sad but important reminder 'you' are treated as a disposable resource on Android. You do not get afforded reasonable control measures over your own device, even on GrapheneOS (which does let you disable networking per app, but not control WiFi data consumption).
Really, similar to "notification channels" there needs to be "data channels" that can be toggled on/off ("tracking", "updates", "resources") etc. And the user should be able to block at the DNS/app level (tracker detection, similar to Firefox would be nice too)
This new world of frequent app updates is just a mess, and in most cases, the updates are minor or just marketing spam.
That is the actual bug.
There's also a concern that the update is designed to check every five minutes. So a rate limit may not actually get exceeded.
> you could run your own update server, but S3 is so convenient.
IMO if you're providing updates to your users you're distributing code automatically and potentially infecting their computers if anything goes wrong. You should take all proper precautions.
Seeing as it's macOS only is there even any reason to roll your own update mechanism when you can use the Sparkle framework [1]?
EDIT: after a bit of digging, it actually looks like it uses Squirrel instead [2]
[1]: https://sparkle-project.org/ [2]: https://github.com/Squirrel/Squirrel.Mac
Ex: - we used to sync 1MM contacts per month to our crm, but this month it’s 2mm - I created an rds database for testing something, but forgot to turn it off (imaging a “library checkout” feature, where I get permission to create a resource for X time, then alerts if I don’t delete it)
Did some investigating and finally found the root cause. I had a background backup job that downloaded some resources and then zipped them up and stored them in s3. But I had changed servers, and the final step of the job on the new server was failing. So it just kept downloading resources, failing, and a short while later attempting again.
I put in some new checks to notify me on failures.
At $previous_company, user-initiated account deletions were only soft deletes, and we were supposed to actually delete data 60 days after the request (in case people regretted their decision). Due to a bug in a SQL query we stopped deleting users (and their associated data) for over six months, racking up over half a million dollars in additional storage cost.
BTW, in our team we compiled a spreadsheet showing Git commits before and after security audit reports [1].
[1] https://docs.google.com/spreadsheets/d/1bqtQI05z-O6uclvYYXxH...
Additional feedback on HN about checking even less often, getting user consent, and writing regression tests but commentators are being dramatic and insulting about it.
Granted, they will take their share so that kinda sucks.
Why isn't checking once a day / week enough?
And... code review?
Relying on code review is a dangerous game because fine looking code can be riddled with bugs.