przemo_li

How good is mise at clean up of accumulated versions?

That's wrong hot take.

GH have forks. Those are distributed repos. You can also sync to GitLab and similar, you can front it with the likes of Gerrit, integrate some code review UIs that actually clone code, etc.

You can exercise distributed nature of git with GitHub quite well.

There is huge array of alternatives between git-flow and trunk based development.

Most still miss on benefits TBD and CI bring.

Companies settle in the middle because git-flow is very specialized branching strategy. You almost need physically sold software (but that's still not enough!).

Nobody insures nuclear power plants. Government is always spillover guarantee.

It also does not come into play after start of operations.

Financing would be different matter. Those percentages trump up heavily and can kill any large project with long delays.

If you allow at most 2 versions and expect team introducing change to rewrite all code...

At small size of code, tooling for that may be off-the-shelf for monolith.

Are there any rewrite told that work cross repos though?

Have you tried to just track time on board / time on column on each task on Kanban board? You just need to keep track of time to trigger those discussions.

In Kanban you multiply cycle time by tasks and do some modeling on that value. Only difference is that in SCRUM whole team does produce raw value upfront of work, while in Kanban manager computes raw value downward of work.

Raw value here refers to lack of statistical analysis.

I think you where sold on "scrum is all you need"lie.

Kanban isn't there to dictate process, but as a tool to correctly and truthfully inspect your process.

E.g. we recently used length of UAT column to prove that we need more business people doing testing in next few weeks as we close to feature release and more tests take form of exploratory testing.

Scrum isn't blind to benefits of such inspections either! So doing simplified Kanban board is frequent.

Proposing retro board be available 24/7 and retros be skipped if board is empty is good use of retro time. ;)

If revenue they bring is estimated you may only need relative comparison.

After all if dev team days that more perspective project is very likely cheaper to make, why would you choose the other one?

See? No need for detailed answers if there is sufficient difference in qualities.

I think it's reference to a team that can be satisfied with a pizza in take out event.

Increasing number of pizzas you get bigger teams.

Increasing number of microservices you assign more of them to a single team.

Over focusing on source leads to stand conclusions.

True remedy in both cases is refactoring. So if team don't have time for refactoring in monolith, then switch to microservices would need to free up enough time for the team to start doing it.

Can that even with on a level of a single team?

French scenario could have been avoided is much better loans where secured. Delays skyrocketed costs for to fat % on those financing agreements.

Which is 101 of big projects anyway. Hard to understand why french project wasn't deemed to risky to investors.

That's too native. Output is indeed cooled but only enough to be only fraction hotter then input. Then dumping is safe again.

This is also why most of those power plants have to shut down. It's not the physical lack of water, but instead input is already so hot that output would already be over the upper limit.

Nobody build enough cooling towers to cool with them "needlessly".

Which is also why global warming is disastrous to energy sector. Those older power plants just don't have enough cooling capacity for newer higher temperatures.

Valid basket does not imply valid order.

Sometimes just splitting stuff into more types that are appropriate to specific portion of pipeline is a win.

Can you expand by providing rough size and GL variants you have used with that monolith.

Twitter got new round of lay offs.

Don't drink cool aid. Twitter case is not yet settled. Musk bought Twitter as company-in-crisis, and crisis was not about excess workforce...

composer.json is from PHP. Config file for package manage (almost universal).

So it will be even bigger pain in the keyboard to write them :(

Can you give an example? E.g. signal that you chose to ignore?

Batteries.

Everybody have better manufacturing capability then Tesla. Everybody know better then Tesla how to do cars.

No really!!!

It was always about costs side of equations. Manufacturing does not solve costs. Batteries factories and battery chemistry R&D solves costs. This and only this is why CAR oems didn't do good EVs before.

So Toyota can do zero with their manufacturing until they invest in batteries.

Nobody can, until they out-invest Tesla... Who has best deals in whole industry so far.

So it's still Tesla that can build best cars is they choose to do. Cause why sell cheaper when you sell all at higher price???

Git branchless have restack command that restacks whole trees/branches of commits.

Problem of wrong incentives is that they put same pressures on everybody. So if those aren't cleared next batch of devs, just didn't spoil yet :(

So looking at incentives first is good place to start. Those experienced devs can be great asset if they can feel they can change behavior now.

Interfaces do not solve Expression Problem. So not even having interface can guarantee success.

(Finding abstractions to solve given expression problem ain't easy too, but ultimately it may be better effort for library authors)

Generalization is a way to go forward. Years back, they didn't even dreamed about your new class. Refactoring isn't waste. Its what enables good code this time around. (And what avoided mistaken decisions back then as someone just assumed stuff will be refactored)

But those whole years compilation speed benefited greatly (because in Java interface is a cutoff for incremental compilation - in Java interface is THE developer experience).

Autor do not talk about any abstraction though.

They talk about concrete knobs and dials, bolted on in advance of actual requirements.

"Can do it all" isn't abstraction because it does not hide any details, doesn't abstract away anything.

So if we both have such a different take, please share which part of article motivated your comment so that we can compare in greater detail, if you please.

Haskell was intended for academic language on which lazy programming can be researched.

It was designed to a small extend to be used during CS studies. Witness some of those functions in prelude that will crash app on incorrect input, which could be trivially improved to total versions. Those where defined they way they are because it ease teaching.

I was not there, so I can not tell if Haskell comity had any thought put into teaching younger audiences.

However, Haskell was never, ever meant for teaching The Programming. It was always about lazy evaluation and static type system.

In deed, here in lies the trap. Python programmer expect different foundation to be laid during programming course to R programmer, to Prolog programmer to Haskell programmer to Clojure programmer.

There is no introductory programming course. We specialize from get go, and its only through learning multiple languages and/or advanced concepts that we generalize ;)

Closest but VERY BADLY BROKEN analogy to Monads is one of many Java standard interfaces.

Would you agree that introducing particular interface is gonna show interface definition in question?

What should follow (just like in Java) is few examples of actual implementations and how they fit into that interface.

IO is also pure.

It will not be executed until the very last line of your app.

O_O

No seriously. If you wanted to model IO in say Java. Your whole program would be about constructing values. No I/O what so ever. Only do this then that then get a, then if a is this do x other.....

Whole Java app and I/O would only happen when at the very end you execute run method on that constructed value.

That'd not usual Java. After all in Java code itself can do control flow and I/O. Do why bother with those values. Need I/O on line ten out of 100. Do I/O immediately on line 10.

What I/O on Haskell is is side effect. Explicit side effect.

It's possible to write impure code in Haskell but that is not IO. It's when you use escape hatches that break type system guarantees.

That's because every single line of code is about side effect.

That means that you have already eliminated all the unnecessary side effects (in both cases), and there is no extra work that could be made pure (also in both cases).

Haskell gives you good tools to limit number of side effects to minimum necessary and verify that it is so.

JavaScript? It's free for all and people talk all the time how developer discipline leads to more maintainance codebases. Examples give for that discipline? (Almost) all are about more purity.

> As a Symfony dev I agree. And the process to convert PHP into a Java-esqe Kotlin-esque language is continuing. Why not use a different language if you like it rather than change PHP?

The audacity of PHP 5.3 developers. How dared they! The audacity of PHP 5.4 developers. How dared they! The audacity of PHP 5.5 developers. How dared they! The audacity of PHP 5.6 developers. How dared they! The audacity of PHP 7.0 developers. How dared they! The audacity of PHP 7.1 developers. How dared they! The audacity of PHP 7.2 developers. How dared they! The audacity of PHP 7.3 developers. How dared they! The audacity of PHP 7.4 developers. How dared they! The audacity of PHP 8.0 developers. How dared they! The audacity of PHP 8.1 developers. How dared they!

/s

(sorry, couldn't help. this particular argument is sooooo silly...)