First off, I was ready to close the tab at the slightest suggestion of using Velocity as a metric. That didn’t happen 🙂

I like the idea that metrics should be contained and sustainable. Though I don’t agree w/ the suggested metrics.

In general, it seems they are all designed around the process and not the product. In particular, there’s no mention of the “value unlocked” in each sprint: it’s an important one for an Agile team as it holds Product accountable to understanding of what is the $$$ value of the team’s effort.

The suggested set, to my mind, is formed around the idea of a feature factory line and its efficiency (assuming it is measurable.) It leaves out the “meaning” of what the team achieve w/ that efficiency.

My 2 cents.

Good read nonetheless 👍 Got me thinking about this intriguing topic after a few years.

A bit too long for my brain but nonetheless it written in plain English, conveys the message very clearly and is definitely a very good read. Thanks for sharing.

When i read the title, my immediate thought was “Mojolicious project renamed? To a name w/ an emoji!?” 😂

We plan to open-source Mojo progressively over time

Yea, right! I can’t believe that there are people who prefer to work on/with a closed source programming language in 2023 (as if it’s the 80’s.)

… can move faster than a community effort, so we will continue to incubate it within Modular until it’s more complete.

Apparently it was “complete” enough to ask the same “community” for feedback.

I genuinely wonder how they managed to convince enthusiasts to give them free feedback/testing (on github/discord) for something they didn’t have access to the source code.

PS: I didn’t downvote. I simply got upset to see this happening in 2023.

I work primarily on the JVM & the projects (personal/corporate) I work w/ can be summarised as below:

1. Building & running the repo is done on the host using an SCM (software configuration management tool) such as Gradle or SBT.
2. The external dependencies of the repo, such as Redis, are managed via adocker-compose.yml.
3. The README contains a short series of commands to do different tasks RE (1)

However one approach that I’ve always been fond of (& apply/advocate wherever I can) is to replace (3) w/ a Makefile containing a bunch of standard targets shared across all repos, eg test, integration-test. Then Makefiles are thinly customised to fit the repo’s particular repo.

This has proven to be very helpful wrt congnitive load (and also CI/CD pipelines): ALL projects, regardless of the toolchain, use the same set of commands, namely

• make test
• make integration-test
• make compose-up
• make run

In short (quoting myself here):

Don’t repeat yourself. Make Make make things happen for you!

😆Can someone make a similar one for bluetooth devices too, pretty please?

Recently, I’ve found myself posting more often on Mastodon a Lemmy & blog way less - indeed credits go to Fediverse and the mods for making it a safe and welcoming place ❤

Here’s my latest one: https://www.bahmanm.com/2023/07/firefox-profiles-quickly-replicate-your-settings.html

It’s not self-hosted, rather I’m using Google’s blogspot. I used to host my own website and two dozens of clients’ and friends’ until a few years ago (using Plone and Zope.) But at some point, my priorities changed and I retired my rock-solid installations and switched to blogspot.

Given I was recently involved in minimising the impact of Lightbend’s similar move earlier this year, AFAIU it means their products will be conditionally open source. They’ll be free to use for non-commercial use but you’d need to pay for anything else.