There are days when I hate programming. I've wasted a few hours realising that the difference between those two images caused random crashes. Shall I tell you what was wrong, or do you want to solve the riddle?
Some time ago, I wrote that I won't use .NET #Aspire for now, and now I checked it again. Result? It got better! Now I can finally use it! 😅 I faced some issues again, but non-blocking this time. It's clearly visible that the team is motivated and working hard to improve it.
I was really impressed by the response time, discussion on Discord with @davidfowl and quick turnaround for the issues I found. Much appreciated!
Aspire still has rough edges, but now I see already that it can become useful for the local dev. For deployment? Possibly, but I need to learn more.
It's not yet time to say for 100% that it'll be my default option for .NET projects, but I appreciate the pace at which it evolves. I'm planning to spend more time on it and maybe even contribute. Definitely not Nay anymore 🙂
I really think that Event Sourcing, with its repeatable patterns and focus on business, can streamline development. Yet, learning it may be challenging. You need to learn both new approaches and tooling. That’s why I decided to publish Emmett to package safe defaults and my state-of-the-art. I don’t want to replace or compete with existing tooling but guide you through this journey.
Tests are first-class citizens in Emmett. I think that’s a pretty rare thing. I want to make getting the trust in your code and yourself smoother while going through the Event Sourcing journey. The proportion between unit, integration and end-to-end tests is up to you. The most important part is that I’ve got you covered. How?
@khalidabuhakmeh that's true. I'm lucky that I can be opinionated here and assume some stuff (for now). Plus TypeScript helps a bit, as you still need to do transpilation.
We're too often trying to show ourselves as busy bees. Sometimes it's a 21st-century fetish, sometimes it's accidental. In both cases, this can be dangerous as we may be putting pressure on other people who follow us. I wrote a short article on that for you and myself not to forget about that.
Too often, people tell me that I'm constantly busy while I'm working less than I did a few years ago. Knowing myself and how mental health is important, I should also look more at not leaving such false impressions as that can cause FOMO for others.
Plus, with the constant flow of the information, all those updates are mixing each other. It's easy to fall into the vicious circle of being obliged to do something.
It always amazes me how easy it is to project our biases into general advice and best practice. It's hazardous if they're made into "just do X" or "don't do Y".
E.g. "just use trunk-base development", "don't do code reviews on feature branches". Is it really so easy? Is it "just"?
I remember trunk-based development done in SVN when code reviews weren't the norm. I don't regret that they're past.
Conway's law should taught us already that changing a tool without changing the organisation won't make a bigger impact.
I'm fed up seeing it again, bashing one approach and just praising the other.
I'd like to see the nuanced take explaining how to transition from one method to another. How to make that actionable and why to apply it and in which context.
Pros and cons of choosing one over another and explaining the problem we want to address.
So if one doesn't have the time to do a code review on the feature branch, then do we really believe that one will find it to do it after the merge?
Is the feature branch actually an issue? Or maybe long-lived branch.
We should explain how to teach people and how to shape team culture. Showing how to apply that in contexts other than small teams and being an architect. But taking the bigger organisation with older practices and showing the journey also for middle-managers
Tried out Marten with F# again at work today, the amount of unmanaged memory: thru the roof of JetBrains dotMemory (~2GB+).
One day, I might be able to afford spending some time coding a repro, but the stuff was clearly occurring in a Marten-only section, and only with a handful of calls, just appending a bunch of events and then reading them.
As a matter of fact, replacing Marten with a full in memory event store (backed with a .NET Dictionary<string, obj list>) proved to be using less mem).