Hold the submitter to a higher standard by introducing penalties for errors, and/or incentives for clean PRs. In my opinion a PR should be flawless once submitted, as the dev should have tested thoroughly. QA should only catch errors in a small percentage of cases
If you want to buikd and distribute something B2B or just to friends or colleagues outside of the app stores, it's a nightmare on iOS. Sideloading isn't as simple anymore for Android, but it's way easier. It's for that reason and for more open hardware and software that I exclusively work on Android now. Too bad about iOS as generally I like Apple hardware, just not interested in the hassle with everything else.
Personally if I see a PR that's not readable, I send it back immediately without much of a read-through. AI or not, the code should be readable or it's not maintainable by people or AI
Yes, very familiar. I think it might be ok though, as it's similar to a web search where you maybe need to refine it a few times.
Just assume that the first answer may not be fully correct or complete, until the AI has more context.
It would be a nice change if it would ask the follow-up questions automatically.
You may want to offer a page credits option instead, as "50 pdfs" for the free tier is a little vague. Is that 50 1-page pdfs, or 50 100 page pdfs? We generate our pdfs one page at a time, and then stitch them together into one at the end; I'm unsure whether your solution would be practical for us. Self-hosting is maybe the other option
Totally agree that creating something to reproduce the issue is a big turn off when it comes to reporting bugs; what else can one do though? In your case though, I guess it was a pretty simple thing
Well-written and valuable for insight whether you have similar personal experience or not.
As someone who does hardware and software as well, I relate to the challenges of making something you can hold; it's very easy to underestimate the challenge difference between the two.
Your Murphy's law references are spot on; I feel comforted reading I'm not the only one this happens to! Misery does love company, and it's important to hang on that I think, so that you don't lose hope :)
When I read the "I had no prior experience in hardware; I was counting on being able to pick it up quickly with the help of a couple of mechanical/electrical/firmware engineers" I was ready to curl up into a foetal position... the fact that the author actually got something like this manufactured and shipped is nothing short of miraculous, it's not just a board off JLPCB and a plastic case, this involves custom manufacturing of metal parts and whatnot, and I take my hat off to him for managing it.
This is also why so many crowdfunded projects fail, people go into it with no idea of how hard it is to get something to market and waaaay underestimate the time and cost. Years ago for the first project we did we took an absolute worst-case estimate, then doubled the time and cost on that. We came in on time and under budget, but only just.
Congrats on the first batch shipment! What an accomplishment. As someone who just crossed 10 years as a first time foray into HW, I'd like to tell you it gets easier. It doesn't but keep going anyway! Good luck.
No, I use them but loading and unloading the app in the tab still happens when the browser flushes the app from memory because the OS killed it or the browser eviction policy hits.
This loading is not nearly as seamless as a regular app starting back up.
For a regular app, you have the app loading, and the os cache helping with it. If you do your job half correctly, it loads as a block almost instantly.
For a web app you have the web browser loading, the the display of the white viewport in a flash, then the app loading in the browser (with zero os cache to help with so it's slower). It needs then to render. Then restoring the scroll (which is a mess with a browser) and the state as much as you can but you are limited with persistence size so most content must be reloaded which means the layout is moving around. Not to mention JS in a browser is not nearly as performant as a regular app, so as your app grows, it gets worse.
I think the parent may be referring to the fact that safari/webkit will evict all localstorage/indexeddb/caches etc after 7 days of not visiting a site. And apparently this now extends to PWAs making it a pretty big blog to building any infrequently accessed PWA that needs to persist user data locally.
I do but I feel it's long overdue for replacement. I've been working on a new protocol that includes timestamp filtering, real-time notifications, and optional things like 'likes' and 'comments'. I use it everyday and I load it with content from RSS feeds. Not ready for sharesies yet though
