crichardson.bsky.social
Creator of Microservices.io
117 posts
1,385 followers
97 following
Regular Contributor
Active Commenter
comment in response to
post
Now I can conveniently rebuild with command-shift-B:
https://buff.ly/3QCoQWw
comment in response to
post
map(), flatMap() and reduce() might be your new best friends, but you need to get to know the Stream collectors.
https://buff.ly/43afI2I
comment in response to
post
What took 10 seconds? To come up with the plan? I've found it was quite quick to do that. It was the execution that took the time.
comment in response to
post
This was 60% of the way towards a solution and took approximately 2 mins.
The two follow up tasks perhaps took a minute each:
Remove the deprecated getEventuateCommandHandler() method
Remove the eventuateCommandHandler constructor parameter
comment in response to
post
Junie then spent 2 minutes:
comment in response to
post
That's super interesting. For example, I just pushed this commit github.com/eventuate-tr...
It was created by Junie
The task was "Replace the eventuateCommandHandler field with fields containing the needed values "
comment in response to
post
Although, ironically because it's new, I was fascinated with what it was doing so I was rather engaged. 😂
comment in response to
post
A big concern is that it's glacial: multiple tens of seconds to accomplish a task.
From a UX perspective that means there's a good chance that the user loses their flow, which is essential for productivity: microservices.io/post/archite...
comment in response to
post
I started using Junie a couple of weeks ago. It's an interesting experience. It's certainly worthwhile evaluating.
It accomplished some tasks well - others, not so much.
comment in response to
post
I've written a new article that explain the concept of flow state and why it's important.
It also describe the obstacles to flow that are all too prevalent in the modern world.
And, discusses what you can do to increase opportunities for flow
https://buff.ly/4be7SHu
comment in response to
post
https://bit.ly/3EP2Sgf
comment in response to
post
To learn more, please read https://buff.ly/4k5m35G
Need help? Please contact me.
comment in response to
post
3. Microservices are a magic pixie dust
Microservices are not a magic pixie dust that will solve all your problems. Before jumping to microservices as a solution, first analyze the root cause of the problem: performance, slow development, etc.
comment in response to
post
2. Applications built for the cloud should use microservices
The choice between a monolith and microservices should be driven by the application’s non-functional requirements, not the deployment environment.
comment in response to
post
1. Modern applications are built with microservices
Just because a technology is modern and popular does not mean it is the right choice for your application. You should choose an architectural style based on your application's requirement.
comment in response to
post
Sure. There are countless ways metrics can be misused, e.g. Goodhart's law.
As always, competence is essential.
comment in response to
post
Good point about skipping PRs although I like the ship/show/ask model.
martinfowler.com/articles/shi...
comment in response to
post
I prefer the original DORA metrics - like all metrics they are imperfect but at least they measure getting stuff done.
comment in response to
post
Also, and perhaps more importantly, just because a PR is merged into trunk doesn't not mean anything has been delivered.
Enterprises often have all kinds of long review/testing activities before the PR makes its way to production.
comment in response to
post
Yes.
On the one hand, PRs/dev/day indicates that some things are working well.
But in their descriptions of the PR metric they seem to be missing a verb? Created? Merged? Merged into which branch?
comment in response to
post
To learn more, please see the article:
https://buff.ly/4b6AAKi
comment in response to
post
Yes. I wanted the 'full' developer experience.
IMHO To accomplish that you need to minimize the JBang part to what it does best and leverage regular Maven/Gradle project + tooling for everything else.
comment in response to
post
My Manning LiveProject: developing a service template and microservice chassis
https://buff.ly/4jB4n1k
comment in response to
post
My new LiveProject Series: Deploying Services with Kubernetes
https://buff.ly/3CDJDW6
comment in response to
post
My book Microservices Patterns
https://buff.ly/39l09qG
comment in response to
post
To learn more, please read:
https://buff.ly/4hvd8sl
comment in response to
post
If someone outside of your team, e.g. on social media, strongly suggests that you to use technology X or architectural style Y, you should take that advice with a grain of salt.
comment in response to
post
There’s no shortage of strong opinions when it comes to architecture and design decisions. X/Twitter and LinkedIn, for example, are awash with them.
But in reality, only you know what's best for your application.
comment in response to
post
To find out more:
https://buff.ly/3QeSDo6
comment in response to
post
https://buff.ly/4jUkpUj
comment in response to
post
https://buff.ly/40JbEna
comment in response to
post
Here's the article: https://buff.ly/4hq2SSk
comment in response to
post
To learn more about this pattern and how to avoid it, please read:
https://buff.ly/40Jwm6z
comment in response to
post
It describes a situation where technology - in this case the microservice architecture - becomes a scapegoat for the mistakes made by the engineering organization.
comment in response to
post
Key requirement: the grammar checker needs to be integrated into the VS Code/IDEA, ie. like Grazie, with keyboard accelerators to navigate between errors and fix them.