>>Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process.
Don't confuse this with "Don't test and don't do code reviews"
The line you quote is oddly one of my strongest arguments against Scrum.
Agile in general and Scrum in particular don’t want to declare things as done when they aren’t and if you haven’t yet given feedback, is it really Done? I don’t think it is.
With Scrum the pressure to put away the done thing and start something else is very high. The moment you start thinking about your next story, unless it’s very closely related to the previous, your ability to accept feedback becomes quickly curtailed.
This is half of the point of Continuous Integration. Fast feedback is often the only feedback that causes behavioral changes. Things that happened a while ago become abstract. Think about a conversation you’ve seen where someone describes how another person hurt their feelings yesterday, versus five years ago. The reactions are very different.
So if you enjoy talking, I suppose it “works” for you but if you hate having to give the same correction over and over, you need to make the person stop and go back until they learn how not to get stopped. Anything else loses the war.
In my teams, I try to pre-empt as much as possible by getting feedback from users on mockups. And then the item is "done", only when product verifies the core flows before it goes to production. I don't do Scrum/sprints (I think it puts artificial timelines and unnatural item splits) , but more aligned with Kanban (this gives me never-ending grief about quarterly releases, QBRs etc, but thats another story). So we try to make what's "done" fairly well defined. Does this slow down shipping? A little bit. But in practice, we end up shipping something at least a couple times a week.
We used to play a bit fast-and-loose with what's defined as "done", and that allowed us to ship everyday, but the loose part of that invariably came back from our customers, at a much higher cost. So we went back to being a little more rigorous.
Been using pip and venv for long. I get uv is faster, but I don't get why people drool over it this much. What is wrong with pip + venv? I build webapps so perhaps I don't see issues in ML world
One day, I plan to release a mobile and web app that's a pixel perfect representation of my low fidelity Balsamiq wireframes/UXUI exploration. Just to make the right kind of people's head explode.
What if I told you - you can use a batteries-included framework, and still write your own libraries specifically only for things you want your own version of and want to share across projects?
The problem isn't that I don't know how to use a batteries included framework. The problem is that you guys don't know there is even an option to reuse your code by writing libraries.
Why are you assuming you cannot write your own library and use it with Spring? It's not an either/or, just like most frameworks are. You are framing it as if there is only one way to do it in spring.
Please do not project things like "you guys don't even know..". I'm one of "you guys" , and have built production code in a variety of languages and frameworks. So this "you guys" knows exactly what he/she is talking about.
Server side template wrangling is not really a big deal, if you use an HTML generation library...something like Python's Hpty/FastHTML or JavaScript's JSX. You can easily split the markup down into 'components' and combine them together trivially with composition.
I mean in practice you rarely target individual elements in datastar. You can sure. But targeting the main body with the entirety of the new content is way simpler. Morph sorts out the rest
A good example is when a page has expensive metrics specific to say a filter on the page. Let's say an action on the page shows a notification count change in the top right corner.
While morph will figure it outz it's unnecessary work done on the server to evaluate the entire body
Expensive queries on the server should be shared where they can be (eg: global leaderboard) or cached on the server (in the game of life demo each frame is rendered/calculated once, regardless of the number of users). Rendering the whole view gives you batching for free and you don't have to have all that overhead tracking what should be updated or changed. Fine grained updates are often a trap when it comes to building systems that can handle a lot of concurrent users. It's way simpler to update all connected users every Xms whenever something changes.
Yeah so that was how I used to think about these things. Now, I'm. less into the fine grain user updates too.
Partly, because the minute you have a shared widget across users 50%+ of your connected users are going to get an update when anything changes. So the overhead of tracking who should update when you are under high load is just that, overhead.
Being able to make those updates corse grain and homogeneous makes them easy to throttle so changes are effectively batched and you can easily set a max rate at which you push changes.
Same with diffing, the minute you need to update most of the page the work of diffing is pure overhead.
So in my mind a simpler corse grain system will actually perform better under heavy load in that worst case scenario somewhat counter intuitively. At least that's my current reasoning.
