arialdomartini

Neat, very very well done.

One observation: Kanban is all about limiting the work in progress. That’s really its foundation. WIP limit is the main means for controlling and improving overall workflow effectiveness.

I would argue that boards not offering a WIP limit are not really “Kanban” boards, as they defeat the very goal of Kanban.

Amazing. I wonder if a similatly seamless migration can be obtained leveraging the versioning and branching capabilities of Dolt.

Beautiful video with an update on the evolutionary development (up to 2021)

https://www.youtube.com/watch?v=C97kMKwZ2-g

Cool idea! Thank you for the suggestion. Fixed!

Very well written and informative. My personal taste, but I find the amount of meme pictures a bit boring.

A series of articles starting from the very scratch and getting to the State Monad. It's thought to be novice-friendly: although using F#, it assumes no knowledge of it. If only it aroused someone's curiosity around F#, that would make my day.

It shows how algorithms with mutable state can be implemented with pure functions, with immutable variables only.

The series itself is an excuse to take several detours on other Functional Programming topics: currying, partial application, recursion, Functors, Applicative Functors.

The source code includes F# and C# examples. In the next weeks it will be followed by code examples showing how to apply a state monad in practice.

Honest question: didn’t you have any unit test around the subscription functionality?

You might appreciate this little series of posts, specifically thought to provide a smooth introduction:

https://arialdomartini.github.io/property-testing

Would you be so kind to share the result? I’m very interested in this experiment.

The comments in my code are written with code, and executing them reveals if they are valid or if the code diverged. They are the project test suite.

The wrong assumption in that page is that Static Typing implies the need for type hints or annotations.

In fact, type inference is a thing.

Most of the languages with Hindley Millner type system (such as oCaml, F#, Haskell, PureScript) do feel dynamic (e.g., developer does not need to hint the compiler) yet they are purely static typed.

What is the argument against having Python checking the types, without asking the developers to change their code?

Another (possibly simpler) approach is to set project specific settings in the `.git/config` file, right in the project directory. As for the OP's example, in:

`~/src/github.com/work_org/.git/config`

without modifying the root `~/.gitconfig` file.

I personally don't squash commits and loose information. I see the value in having a compressed view of the log history, but in that case I use

  git log --simplify-by-decoration