I said what I said with purpose. I can't share this shit with anyone serious. It looks like someone who watches too much cartoon porn made this. I'm sorry these types of real life viewpoints offend you. I do sincerely suggest you reflect on what I am saying and consider it with weight.
Thanks for ur feedback on the project's visual style. Let me clarify a few things: First, associating an anime character, especially a minor, with inappropriate content is unfair and disrespectful to both the character and the original work. Second, this character wasn’t added by me—it was included by the previous developer who created these visualizations. As part of the open-source community, I believe it’s important to respect the project’s history and acknowledge their contributions. Lastly, I appreciate your perspective—it might highlight how cultural differences can shape perceptions, and I’ll pay attention to that in my subsequent work. That said, I also value maintaining the entertainment and avoiding overly dry or preachy content, which I think is equally important. This will likely be my final reply on this matter. Let’s focus on being open-minded and keeping the community peaceful. Thanks again for your support of the technical aspects of the project
Storing and streaming is an expensive model, and the subscription price is a premium in the majority of the world. It’s actually impressive that so much content (both incredible and bad) is available, for “free” to so many.
I’m an ideal world there would be no ads, but we don’t live in one.
If you have such disdain for ads you should probably pay the premium or not use YouTube.
Commenters like you are why people don’t give honest feedback. Why review something for free when someone like you is unable to accept honest feedback even if it is critical.
Look up 'pig butchering' when you get a chance. It is an elaborate process of convincing your mark to fall in love with your persona and asking them to send it money. It takes months to years to execute but marks end up losing their properties, retirement accounts, life savings, everything to it.
It was unclear to me that you were being tongue-in-cheek. Were you serious, I'd point out for starters that A. You probably don't know whether it's serverless currently and B. Even if it were it's not a particularly uniquely likely explanation for consistent latency at scale
my understanding is that in a serverless architecture the dev does not manage the server, there still is one but its managed via third party cloud services who expose basic server or database functions which your app can plug into.
think a "like count" database, it needs to increment and persist. Both very simple, and its implementation is entirely decoupled from the client implementation. Firebase would manage that for you, youd just call firebase functions instead of updating a database yourself.
That’s great if you’re the only person working on the code.
Not everyone is as diligent and not everyone will have thought through/remembered all those edge cases when they happen to end up maintaining/adding to your code.
Personally I find that tests are a great way to ensure all that hard work you did thinking about those edge cases isn’t wasted. That and manually testing stuff is annoying after the first time.
Things that either work or don't, don't really need tests. Things that have a ton of edge cases... you might spend ten times as long writing tests as writing the code. In a few cases it might be worth it. Like, I have a piece of hotel software that lets rates be set by the night plus peak extra rates over overlapping time periods, and has to delineate the nightly totals for a customer stay that crosses over lots of those. Lots of edge cases. I had that in production for 5 years before someone noticed that although the totals were right, if the very last night was at the default rate after coming off a peak rate, the line item wasn't printed on the bill. It was a simple case of greedily including one more
segment in what was printed. Now... would a unit test have found that? You have to know exactly what you'd be looking for first. The test would have to be smarter than the person writing the code.
No, the test would not help to find it, but now you can write a test for that bug. Later, when you change something, related to this code or something unrelated, you can be sure it did not affect this part.
Tests are useful when you change code that is unrelated, but still somehow connected. You would never notice the issue as you don't manually try the unrelated code, but the test would catch it.
If you had unit/integration tests for all potential edgecases you came up with, you don't have to manually test that over and over.
yeah but because the code is segmented into very discrete functions... and it's quite easy to see their call chains...
Well, I get it. You're right in principle. The truth is, though, I have had to rewrite software from scratch in new languages every 10 years, and these sorts of bugs only appear a few times per decade. Once a piece of central business logic works, it usually works forever; a change to that central logic will of course require changes and tests across the whole system, from user inputs to annual reports, but that can't be helped. I suspect you'd then have to rewrite the unit tests, too.
It's probably true that when I die, most of my software will slowly wind down and eventually be abandoned. But also that's probably true even if I were to write a lot of tests.
> Now... would a unit test have found that? You have to know exactly what you'd be looking for first. The test would have to be smarter than the person writing the code.
This is a textbook example of something that property based testing can catch. Yes, the tests are smarter than the person that wrote the code. At least, smarter in a different way or maybe it’s that the people who wrote the property based testing framework are super smart.
Look up QuickCheck for the OG or property based testing + your language.
I don’t exactly understand your bug, but the way it would work is something like you’d make some generators that create night stays and rates and put those together into a bill. Then you test the property that the number of line items on the bill is the number of nights + number of discounts (or whatever is right). It will search to break this property and if it breaks it, find a minimal case. Seriously check it out, it’s perfect for this sort of thing.
> Not everyone is as diligent and not everyone will have thought through/remembered all those edge cases when they happen to end up maintaining/adding to your code.
Edge cases could be due to accidental complexity. In this case, the solution is to remove accidental complexity, not to freeze it forever in tests.
Edge cases could be due to essential complexity. In this case, if people are making changes without remembering them, it means they are changing code they don't understand. Sure, tests are making it easier. I don't want it to be easier.
> tests are a great way to ensure all that hard work you did thinking about those edge cases isn’t wasted
It is also a great way to ensure that your best talent is wasted on building guard rails.
Think about it: your best engineers are spending time making worst engineers more productive. And they are not even doing it through mentoring, so your worst engineers will remain where they are.
What’s the best way of monitoring suites? The built in report tool is amazing, but would love a solution that makes for easier analysis and maybe a closer integration with jira.
reply