I recently gave a 2-session training on #DDD fundamentals for #JDriven / #JCore and I'm excited to visit #dddeurope2024 to get all the latest insights and practices!
Sometimes, when I talk to frontend developers about how #HTMX requires you to have more presentation awareness in the projection side of your server application as you generate content in HTML, which in the #Java world is pretty much what we did with #JSP, Freemarker and Thymeleaf, I'm met with amazement.
No dis, but be aware: There's a generation of capable professional frontend developers who don't know backend servers can serve HTML just fine, and not just Json over HTTP.
Doubt between 3 and 5 does not average out to a 4.
3 stories of 5 does not equal 15.
5 stories of 1 does not equal 1 story of 5.
As you progress and improve your understanding and ability to deliver, will you deliver more points, lower your estimations, or divide work better?
A velocity, measured in expected estimated unspecified effort, to measure a size in multiple unspecified dimensions, expressed via incomparable numbers, is meaningless.
Too often, what people call technical debt is simply an encounter with the limits of functional anticipation. If you think a system will never need to do X given the foreseeable usecases and then one day it does need to do X, you don't have technical debt.
Technical debt arises when you then try to shoehorn the needed functionality in, instead of asking/making/taking the time and effort to redesign it.
In fact, I've come across more technical debt in systems that tried to anticipate more functionality than reasonably foreseen: overzealous abstraction and open-endedness in a technical implementation can be a nightmare to work with. It's healthier to foster a culture where developers can cooperatively make disciplined adjustments to their software.
Would be sweet if I can have a static #HTML / #CSS website that uses #HTMX for interaction with a backend written in Kotlin and compiled to #wasm running on an edge location using #wasi .
It's baffling how vocally people allow dislike to replace certainty when there is none. Will all the people, eager to involve and blame all sorts of things, and making the wildest speculations regarding #joostklein at #esf also rectify their posts and invalidate their assumptions once they find out what actually happened?
You cannot visit a #LinkedIn page from a #Chrome browser without LinkedIn creating an account based on the #Google account info that you're logged in with on that Chrome browser, even if you cancel the account creation process that LinkedIn automatically starts.
Because you didn't actually create that account, you cannot delete it. You have to complete the signup process just so you can then proceed to delete it.
Does no one at #microsoft challenge this kind of implementation?
People may want to reconsider using #AWS#S3 for static web hosting, or at the bare minimum come up with convoluted names and treat their S3 bucket name as sensitive information. If your S3 bucket name comes up in any web search (for example because it's literally in a public GitHub repo), that's a potential attack vector.
The problem with calculating a "velocity" for your team when using #Scrum in combination with Fibonacci-based storypoint sizes, is that completing 3 backlog items of size 8 is not the same as completing 8 backlog items of size 3, or 24 backlog items of size 1. The difference in effort and uncertainty makes such numbers a useless basis for comparison and prediction.
And following the example of XKCD in https://xkcd.com/2295/ : adding garbage numbers together leads to worse garbage numbers.