I don’t have a problem with the fines for the spam texters, if anything it should be higher, but not punishing the electoral commission for that is utterly insane.
I have never seen stacked PRs work that well in practice. Two reasons:
- Namely there would be review comments on the first PRs that then cause a cascade of merge conflicts in the follow-on PRs
- Somehow reviewers never seem to like the stack of PRs, my experience is they always react with disdain and/or confusion.
There is the counter-question too, why not stack commits cleanly?
A third reason against, not a good reason, but for many developers Git is super difficult (IMO largely a skill issue, not taking the time to learn basic tools that they need everyday; otherwise I have no clue why software developers do not learn their IDEs and VCS tools very well). Stacking PRs requires some Git skills, a simple feature-branch workflow can be a challenge for many..
In other words, if someone is skilled enough to do a set of stacked PRs, the team likely benefits by letting that person merge the stack on their own when each bit is ready and do a post-merge review instead of pre-merge.
(Side-note, my unsolicited perspective: I'm personally convinced that the benefits of linear history is a magnitude more important than all the other peeves & nits combined between merge vs rebase.)
Multiple at once. Good pointer on `--update-refs`!
I can think of quite a few additional concerns. Overall I think it comes down to how the team wants to handle code reviews.
Personally, I do think if the team is at the level to coordinate and execute on a stack list of PRs, there is little need to incur extra round-trip times for "reviewing" precursor changes and instead focus review time where it is explicitly wanted.
Though, I do indeed like stacked PRs over commit-list because there is more incremental progress, but it does come with some costs. For example, perhaps the last reviewer does not like the overall direction that the cumulative work has led to.
My experience is that at that rate, it's best to let teams decide how they want to operate, formalize somewhat how things are shipped, and bias towards shipping. On the other end of the spectrum, a person quickly glancing at refactoring updates, not having good context on how a given PR fits in - it can almost put into question whether CR itself is entirely a best practice. Hence, I'm a fan of "ship/show/ask". I think it mostly does away with the need for stacking PRs with very little downside (and upside of greater efficiency, CR is spent time reviewing more important code, things that benefit from CR and use the reviewers time well, and makes for a better flow for the author since they can readily merge).
There's tooling that helps with some of that. I have evaluated StGit for a month or so now, and while it does require that one unlearns some git in the process, it has been handling that sort of situation well.
Couldn’t agree less. I’ve been a developer for nearly 20 years, working with Python, PHP, JavaScript, ObjC, Swift, Java, bash scripting, SQL, Terraform, and a bunch of others. Written code for data transformations, web servers, client side JS apps, native mobile apps, and games.
Android has been my favourite platform to work with and has offered the best developer experience I’ve found. It’s not particularly close. The SDK has improved significantly over the years, the IDE is wonderful, the feedback loops are short, Kotlin hits the sweet spot between functional and OO code, and Compose is a joy. Although yes, Gradle is a sore spot.
IMO the reason why Google have gone all-in on Android Studio is because it’s really, really good. Compare it to Xcode. If you’ve never used a JetBrains IDE, it can feel a little unfamiliar, but I’ve never felt as productive in any other programming environment.
Probably. Purely anecdotal and it may just reflect the company I keep, but Meetup seems to have dropped off my radar and that of people I know. I can easily believe that many groups paused during the pandemic and never kicked back off again; I've certainly seen that behavior with a lot of groups generally.
It can be tough to get people to pay an ongoing fee for something that's often used for people to do casual recreational activities rather than one of the many free alternatives--even if they're not quite as suited for the purpose.
Meetup had a way to do this: make it opt-in by organizers, then increasing organizer price later on, perhaps even drastically, to incentivize the new structure. Over a year, say, even on organizers who didn't opt in, they could likely double their revenue per subscription with minimal churn.
Instead, their messaging strongly implied that, while it was still being tested, this would be mandatory, destroying community trust. An absolutely flubbed rollout.
Briefly. There are Kotlin areas in the codebases I work on, particularly in Android code. It's not something I've needed to use yet, but I've heard good things and I'm interested to get into it once we start using it more.
Strongly second the GP. I ramped up over the past year and I compare it to C# or TypeScript as far as the type safety and async features go. That whole time I kept running into QoL features and sugar that were just a joy to use.
The best side benefit for our Java heavy org was that the migration risk is very low due to excellent JVM/Java integration.
I started using Kotlin in Java 8 before the "record" keyword existed to be able to use "data class" instances. This provided very nice semantics for defining immutable structures, and the resulting classes could be imported into the existing Java codebase.
As the project progressed we started adding more in Kotlin and it massively improved developer experience.
No, but it makes the code a mess because you’re handling optionals for every protobuf field deref. So you’ve got error handling all over the place. It looks like go’s error handling.
They really are optional though. This is inherent in the problem if you want to support arbitrary past and future versions. You need to decide what to do when the data is missing. Open file formats are a difficult problem. [1]
I might define a different class for a validated object, so version skew only needs to be dealt with at the system edge.
Maybe you don’t actually have that problem because you can make a closed-world assumption? For example, you control all writers and aren’t saving any old-format data, like in a database that has a schema. In that case you can make fields required.
