I was in this demographic for a log time. I wanted to support small artists in ways past just going to their shows. This seemed like a nice way to do that (not a big shirt guy for bands). It also helps that you are not only getting music but a large(ish) art piece as well with the vinyl covers. It also feels good to physically have and own something. I recently bought a Portable CD player as well. I think a lot of the Gen Z folks I talk to are starting to (if just wishfully) drift back towards physicality in some ways.
It also feels good to physically have and own something.
I gave all my CDs (probably more than a 1000) away about a decade ago. I find physical media annoying, they take up space and require more effort to use them. All those CDs became more of a burden. I guess it's because I grew up with cassette tapes, portable tape players, then CDs, then Discman, then Discman with buffering. Having gone through all of that, being able to play music on your phone is... excessively nice. I also care more about the music than the packaging -- if I want something nice on the wall, I would get a painting, litho, etc. instead.
The only thing I really miss is old-school music discovery. Reading reviews, then going to a record shop, listening a stack of records to decide, talking to record shop owners and friends for scoops, etc. was so much more fun than letting algorithms do recommendations. And after spending your monthly pocket money on two albums, you were invested in the music.
Surprisingly, chat GPT is amazing at recommendations. (I guess that it is also an algorithm). But it recommended me some great artists and explained why I might like them.
Word-of-mouth recommendations worked better across genres. I want great, unique, high-quality music, not necessarily music that is similar to what I already listen to.
- iOS keyboard dismiss decoration - Not sure on this.
- iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
- iOS NavigationLink widget - Not familiar with this construct but easy to build yourself.
- iOS checkbox widget - Totally agree but also easy to build directly.
- Android camera that doesn't randomly crash (unfixed for 3 years) - We've got a couple application that use camera and never had this issue.
Just an additional note: Integration testing was indeed completely broken for a while, with the docs stating otherwise. They reworked it a few releases ago and since then it works well for us (limited usage, but completely stable for what we do with it).
Do you have tests that run on your host machine, can start an API server and interact with it, and also drive the Flutter app? Or do your tests run on the mobile device?
The tests run on the mobile device, or rather mostly the emulator. No API server to interact with (and I would not know why?). The shop uses integration tests for three things: 1. Testing some migrations 2. Click through the app, as part of a release checklist 3. Run crypto operation to check multiple plugins for continued compatibility.
Integration testing supports only running tests inside the device. If your test needs to start an API server, then you must use the deprecated and broken flutter_driver module. See the bug I linked.
Flutter's Cupertino dark mode support is broken. Some text is invisible. Some widgets are unusable. Cupertino Dark mode theme support is completely absent. See the bug I filed, with a comprehensive reproduction with screenshots. It's like the dev who added it just decided to stop half-way.
> - iOS keyboard scroll-to-dismiss mode - This is trivial to setup, just listen on scroll and hide keyboard. You could even create a generic handler that can be reused everywhere for this.
Please use an iOS device and notice how nicely one can dismiss the keyboard in iMessage, FB Messenger, Instagram, etc. Getting that behavior in Flutter requires using a third-party package.
The Material date picker is not a date-time picker. Letting the user pick a date & time requires a lot of extra code. For example, I spent many hours writing a widget that displays the date & time and lets one click to change it, like in Google Calendar.
See the bugs I linked about Navigator. The docs have multiple omissions. I lost a day and a half on them.
Yes, you can debug tasks with a breakpoint. You cannot see which async tasks are running. You cannot pause a task. I needed to debug concurrent RPC problems and tried using print. Unfortunately, print provides no visibility into tasks running in standard library code, like timed-out HTTP requests that continue running.
You can timeout waiting for an HTTP request to finish, but the request still continues in the background. If it's a large upload then it can continue for minutes, draining the device's battery and transferring data. See the bug I linked.
> - Testing on physical devices for apps that use flavors - We do this regularly across 5 different flavors on both iOS and Android.
How do you install on iOS? I tried `flutter build --flavor staging --release` and then `flutter install` which fails saying that I must supply `--flavor`. But when I supply `--flavor` it says the parameter is not supported. See the bug I linked. I spent a few hours and figured out how to first do a Flutter build and then use XCode to build again, then use Devices & Simulators to manually install the archive. But this requires that I remove the app from the device first, which destroys the app state. This makes manual testing extra slow. The process is noxious.
Flutter Inspector in Android Studio on macOS breaks 1 out of 5 times I try to use it. I often waste a few minutes trying to figure out why my code changes did not have the desired change on the widget tree. Then I finally realize that the widget tree pane is broken and I need to restart Android Studio. It's been like this since 2018 through multiple upgrades of Flutter, Android Studio, and macOS.
I worked with React Native for 3 years before jumping over to Flutter and this was the biggest reason why I made the switch. Its exponentially better on Flutter. The only time builds break for the team are when we made a code change that broke it. Its consistent and non-flaky (looking at you RN). Not that you won't run into the occasional issue but with React Native easily 20% of my time developing was "this just stopped working and there's no reason why". React Native was configuration hell. With Flutter, I haven't struggled with that at all past the initial setup.
This has been my experience with RN too (admittedly, a few years back). So much time wasted on troubleshooting random glitches that occur for seemingly unrelated reason. Some minor library version update? Boom, your breakpoints no longer work. Why? Noone knows. The "turn it off, turn it on" approach seems to be the go-to fix in this environment. And there's always another surprise around the corner.
I can't really contrast it with Flutter, because I only toyed with it a little bit, but at least the docs were of much better quality - and this being a few years back as I said, the fact that Flutter was the newer framework (and still provided better quality at least in this area) was even more pronounced.
I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to say, I definitely see how it can be disliked and I also disliked it when I started working with it but it definitely grew on me.
> It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages.
Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time.
I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/
This might not be obvious in anyway if you’re not pretty deep in the Dart ecosystem but I’ve never seen anyone pay as much attention about building a good long term language as that team.
They put crazy amounts of thought and effort into how they evolve it.
Their entire strategy as far as I know was to intentionally aim for “boring and predictable” so that no matter how large or complicated your application got that you would never outgrow it.
Then they built a bunch of really nice tooling and DX on top of it.
It’s genuinely a pleasure to work with in my experience.
I was enjoying the frog book (The Dart Programming Language, Gilad Bracha & Erik Meiker) but that was 2015, and now very out of date. Its strange to see there is no up to date book from major publisher, like the Rust book at https://doc.rust-lang.org/book/
The incentive structures around technical books are pretty weird.
Most major publishers pay quite small royalty rates, so even a popular tech book won't actually make the author much money. And the effort to write a good technical book is pretty huge. Also, the set of people who will actually finish writing a book is quite a bit smaller than the set of people who aspire to. (An editor at O'Reilly told me once that only about 1/3 of the authors they sign deals with actually end up finishing the book.)
So for a book to appear, you need to find someone who:
1. Knows this particular topic in depth.
2. Is interested in spending a lot of time writing a book about it.
3. For relatively little money in return.
4. And actually has the discipline to finish it.
Not a lot of people in that set. It's also particularly hard for technologies that are in flux since the quicker the book gets out of date, the less value there is in writing it.
Former O'Reilly editor here: story checks out. The 1/3 might be a bit low -- I had some surprises (one guy joined the Peace Corps and moved to South America, plus usual divorces and deaths and job changes) but it felt more like 80% completed. This might be the rosy glasses of memory, though.
There's also a weird difference in incentive between writing the first edition and working on updates: if the author was just after "I wrote a book!" then they already have that, and won't be so interested in updating.
If they were made famous and now have a lot of work as a result of the first book, they may not have time for it. It's quite the delicate dance to get someone else to update the book: without the update, sales will drop, but 1st edition authors feel weird giving a lot of their (not sizable) royalties to someone who didn't write most of the text.
That is fascinating. As someone who has writing a technical book as a life goal, I'd love to ask--do you have any insights you'd be willing to share regarding how to get started?
Are you already blogging? If not, I would start doing that. Writing short form technical articles and sharing them is like bootcamp for longer form writing. You'll learn the mechanics of organizing thoughts into a linear narrative, the discipline to finish, and you'll get feedback from readers about what works and what doesn't.
I blogged for a few years (and wrote thousands and thousands of comments on Reddit, which was also helpful) before I wrote a book.
Alternative to (3) - Company that owns a language and is willing to pay decent money for someone qualified to write a book in order to increase popularity
Yeah, this is viable, but the cost is quite high if you're paying a skilled software engineer for their time. The company driving the language can probably spend that budget better elsewhere. (For example, on online documentation that is more easily incrementally maintained and grown.)
Picking it up is really easy if you have any experience with Java or C# and the QOL improvements compared to the former make it seem like a treat for me. What language are people who hate it coming from?
At Superformula, we use design and engineering to elevate the way people interact with the world. We are customer experience experts—creatives, engineers, and enterprise roadmap consultants flexing our skills to design and deliver world-class digital products for our clients. We are also expanding!
We’re a 100% REMOTE team, fully distributed across 14 countries, and supporting our clients across EST to PST timezones. We have been operating this way for over 10 years. Here’s a brief intro of our open roles:
- [Senior] Backend Engineer: You possess a strong understanding of the AWS Ecosystem, are highly experienced in TypeScript and Node.js, and are a natural thought-leader that takes ownership of work items and helps to cultivate new ones with a Product-first mindset. https://careers.superformula.com/o/senior-backend-engineer-n...
- [Senior] Frontend Engineer: You'll be joining a high visibility product team focused on producing a best-in-class customer experience in the automotive or hospitality industries, designing and building the next generation client architecture serving 9M+ monthly visitors. https://careers.superformula.com/o/senior-frontend-engineer-...
- [Senior] IAM Engineer: We need you to have experience building enterprise-scale, production-ready Identity and Federation solutions. This is a high visibility shared-services team with modernization goals and a strong focus on quality. As part of our team, you will play a vital role in accelerating digital transformation through our Identity surface area. https://careers.superformula.com/o/senior-iam-engineer-net-c...
At Superformula, we use design and engineering to elevate the way people interact with the world. We are customer experience experts—creatives, engineers, and enterprise roadmap consultants flexing our skills to design and deliver world-class digital products for our clients. We are also expanding!
We’re a 100% remote team, fully distributed across 10 countries, and supporting our clients across EST to PST timezones. We have been operating this way for over 10 years. Here’s a brief intro of our open roles:
- [Senior] C# .NET Engineer: You possess a strong understanding of the .NET ecosystem, are highly experienced in C#, and are a natural thought-leader that takes ownership of work items and helps to cultivate new ones with a Product-first mindset -- https://careers.superformula.com/o/c-net-full-stack-engineer...
- [Senior] Mobile Flutter Engineer (US-based): You are experienced in building enterprise-scale and production-ready applications. This is a high-visibility product team where you will make a positive impact on CX in the mobile banking or hospitality industry -- https://careers.superformula.com/o/mobile-flutter-engineer-d...
- [Senior] Technical Product Manager: You have experience designing, developing, and shipping digital experiences as a humble but confident product leader. If you're a passionate auto enthusiast, then you'll love this team -- https://careers.superformula.com/o/sr-product-manager-digita...
We all make mistakes but rarely at this scale. I hope whoever accidentally sent out the integration email to everyone doesn't get in trouble. I would hate for my dumb mistakes to be put on blast by hundreds of thousands or millions of people.
I often see "this person should be fired" etc in response to legitimate mistakes.. but that's massively undervaluing the mistake.
There's a pretty good chance the person who made such a mistake is less likely to repeat it or other mistakes than someone who hasn't yet had the experience. So at best you're just sending a more valuable employee to one of your competitors.
There's some gray area when it comes to making a poor judgement call to skip a well defined procedure or be lazy.. and some cases this doesn't apply to like intentional malice or a continued series of similar obviously avoidable mistakes.
On a related note im often frustrated when people play a blame game (even if one might be somewhat called for, in a way) instead of considering "human factors" and how to systematically avoid people being able to make such mistakes. Or refuse to accept a human factors style explanation and just say the person "should have known better" etc. The best high profile example was that hawaii missile alert that was supposed to be a test having an incredibly poor UI. But there are countless examples everywhere all the time. I often try to think about this a lot in my work.
“Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?”
If someone can make these kinds of mistakes, IMHO it is usually not their fault and instead is the fault of the systems that failed to prevent it from happening.
It is still their fault -- they did something they shouldn't have done. But the mistake exposes a bigger problem in the underlying infra, which is a good thing.
I think it's harmful to ascribe fault as a binary thing.
Assuming, of course, that this wasn't some deliberate act (because that would be weird):
The person who ultimately pressed the button which caused the code to run that sent this email only shares some portion of the fault. Maybe that person even wrote and deployed the code.
There's many other deficient processes that led to this even being possible - why did test code run in a place that had access to production credentials? what caused the code to run in the first place - was it accidentally triggered by some other bug, or deliberately run by somebody who didn't realize they were in production? If so, why are their systems built in a way that it's hard to realize when you're in production? Why is the system architected in such a way that large quantities of email can be sent inadvertently without some sort of approval? You could always delay large batches and send an alert so a human on-call could be in the loop to detect and delay such emails.
I've definitely seen issues where the engineers at the keyboards that day weren't at all at fault, and were just doing exactly what was asked of them, but systemic issues caused something like this. You can blame poor tech hygiene by the whole team, and lack of foresight by the manager, but most of that would be 20/20 hindsight.
This is why blameless postmortems are a good thing, because humans are simply awful with hindsight bias.
Best thing to do is just figure out how not to do it in the future.
On the list of screw-ups I've seen, this is pretty benign. I'm sure not long after this happened, they either realized their mistake or a flaw on the system they were working with. No reprimand needed, maybe some joking criticism to ease the stress I'm sure they're feeling knowing some asshat manager might actually think this is terrible and do something stupid like fire them.
The worst side effect of this to HBO is probably the cost of some unnecessary customers calling customer service confused.
The other side effect is a non-trivial number of people probably reported email from HBO Max as SPAM to Gmail etc. Speaking of which--I got this and, while I subscribed to HBO on Comcast for a while, I've never been an HBO Max customer.
Some successes are obvious luck (e.g. winning the lottery). Some failures are the obvious result of bad choices or are so egregious they don't warrant generosity (e.g. cheating on a spouse).
