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’ve been using sdkman for about a decade now and am totally pleased w/ it. It does a very good job of managing JDK versions for you and much more, eg SBT, Gradle, Scala, Groovy, Leiningen, SpringBoot, …

Now, technically you could use sdkman in your CI/CD pipeline too but I’d find it a strong smell. I’ve always used dedicated images pre-configured for a particular JDK version in the pipeline.

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!

Since I haven’t heard/read about any bugs, I plan to release v5.0.0 on the 13th (😬)

I’ll keep this post, well, posted 🙂

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.

I used to be in a relatively similar position years ago so I totally relate to what you’ve got to do on a daily basis.

These are the the titles that come to my mind (leaving ths seniority level up to you):

• Software engineer
• Software engineer in Integrations
• Software engineer in Enterprise Applications
• ERP Implementation consultant

Bookmarked!

Oh, I see. It kind of makes sense. Who’d need Jython when GraalVM’s out there nowadays!? Well, unless it’s a legacy app 😬

Not a direct answer to your question but here’s what I’ve learned and am learning:

It all boils down to “finding the right balance between the costs of implementation, the value the implementation offers given the circumstances and constraint.” Essentially, the foundational guideline of engineering across all engineering principles.

Usually every decision brings about about a series of advantages/improvement but it’s important to remember that “one must lose in order to gain.”[1] That is, every improvement (value) comes at a price (cost). Unlike other principles of engineering (which are closer to bare maths), software engineering more closely resembles something intuition-based like art. That is what makes it difficult to see the values and costs and measure them. It takes lots of practice and introspective and extrospective (!) effort; doing things and potentially making mistakes and learning from them is as important as observing others do things and make mistakes.

In other words, it boils down to honing your intuition to “do the right thing, at the right time, the right way.”

PS: Please note that I used the word “right” and not “correct.”

[1] Dialectically speaking, every material good contains w/i itself its own seeds of destruction 😆

I genuinely wonder why the downvotes?

Good refresher on the topic and ineteresting gory details of CPython impl.

On another note, is Jython still a thing?

Effective method…so long as your kid doesn’t hate you 😂 in which case, IMHO, it should be a favourite aunt/uncle/teacher/… who introduces them to the topic while the parents try to stay quite on the topic as much as possible.

Unfortunately didn’t work. I got the same *** target pattern contains no ‘%’ error.

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.

This is the 2nd of such moves this year to my knowledge; first there was #Lightbend and #Akka and now this. What a year for #FOSS 😕

I know for a fact that so many organisations use #hashicorp products for commercial purposes w/o ever contributing back. And I understand how this may feel for hashicorp in these harsh economic times. Though this still is, IMHO, a cheap move: they used an OSS license for a very long time which resulted in a massive user base and a “soft” vendor lock-in, and now they decided to milk that user base.

Looking forwards to solid community-driven forks of their products 💪

I’m a software engineer by profession and passion and have been writing programs for well over 20 years now. I believe your experience is totally natural - at least I share the same feelings:

1. Large code bases take time getting to know and understand: most definitely true. It takes time and effort and is an investment you need to make before being able to feel confident. You don’t need to fully comprehend every aspect of the project before you can contribute but you sure need to have a decent enough idea of how to build, test, run and deploy a particular feature. See point (2).

2. Don’t let the size of the project intimidate you. Start small and expand your knowledge base as you go. Usually one good starting point is simply building the project, running tests and deploying it (if applicable.) Then try to take on simple tasks (eg from the project’s issue tracker) and deliver on those (even things like fixing the installation docs, typos, …) That’ll have the additional impact of making you feel good about the work that you’re doing and what you’re learning. I’m sure at this stage you will “know” when you’re confident enough to work on tasks which are a bit bigger.

3. During (1) and (2), please please do NOT be tempted to just blindly copy-paste stuff at the first sign of trouble. Instead invest some time and try to understand things, what is failing and why it is so. Once you do, it’s totally fine to copy-paste.

After all, there’s no clear cut formula. Each project is a living and breathing creature and “not one of them is like another.” The only general guideline is patience, curiosity and incremental work.

It doesn’t look to be a decline at all (quite healthy on the contrary) until around the time ChatGPT was released.

I’m definitely interested to take a look at the code. Any other URL you could share that wouldn’t require logging in?