That’s definitely an interesting idea. Thanks for sharing.

Though it means that someone down the line must have written a bootstrap programme with C/Assembler to run the host forth.

In case of jbForth, I decided to write the bootstrap too.

That’s impossible unless you’ve got a Forth machine.

Where the OS native API is accessible via C API, you’re bound to write, using C/C++/Rust/etc, a small bootstrap programme to then write your Forth on top of. That’s essentially what bjForth is at the moment: the bootstrap using JVM native API.

Currently I’m working on a set of libraries to augment the 80-something words bjForth bootstrap provides. These libraries will be, as you suggested, written in Forth not Java because they can tap into the power of JVM via the abstraction API that bootstrap primitives provide.

Hope this makes sense.

Haha…good point! That said bjForth is still a fully indirect threaded Forth. It’s just that instead of assembler and C/C++ it calls Java API to do its job.

“Announcment”

It used to be quite common on mailing lists to categorise/tag threads by using subject prefixes such as “ANN”, “HELP”, “BUG” and “RESOLVED”.

It’s just an old habit but I feel my messages/posts lack some clarity if I don’t do it 😅

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.

Update 1

Thanks all for your feedback 🙏 I think everybody made a valid point that the OOTB configuration of 33 requests/min was quite useless and we can do better than that.

I reconfigured timeouts and probes and tuned it down to 4 HTTP GET requests/minute out of the box - see the configuration for details.

🌐 A pre-release version is available at lemmy-meter.info.

For the moment, it only probes the test instances

• enterprise.lemmy.ml
• ds9.lemmy.ml
• voyager.lemmy.ml

I’d very much appreciate your further thoughts and feedback.

Agreed. It was a mix of too ambitious standards for up-to-date data and poor configuration on my side.

sane defaults and a timeout period

I agree. This makes more sense.

Your name will be associated with abuse forevermore.

I was going to ignore your reply as a 🧌 given it’s an opt-in service for HTTP monitoring. But then you had a good point on the next line!

Let’s use such important labels where they actually make sense 🙂

beyond acceptable use

Since literally every aspect of lemmy-meter is configurable per instance, I’m not worried about that 😎 The admins can tell me what’s the frequency/number they’re comfortable w/ and I can reconfigure the solution.

You can hit the endpoint /api/v3/site for information about an instance including the admins list.

Exactly what I was looking for. Thanks very much 🙏

Thanks for the link. Had no idea about that.

This is quite intriguing. But DHH has left so many details out (at least in that post) as pointed out by @breadsmasher@lemmy.world - it makes it difficult to relate to.

On the other hand, like DHH said, one’s mileage may vary: it’s, in many ways, a case-by-case analysis that companies should do.

I know many businesses shrink the OPs team and hire less experienced OPs people to save $$$. But just to forward those saved $$$ to cloud providers. I can only assume DDH’s team is comprised of a bunch of experienced well-payed OPs people who can pull such feats off.

Nonetheless, looking forward to, hopefully, a follow up post that lays out some more details. Pray share if you come across it 🙏

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.

Thanks all for the input 🙏

I did a quick experiment w/ the APIs and I think I have identified the ones I’d need. Obviously, all is open source (GPLv3) available on github: lemmy-clerk

As the next step, I’m going to expose that data to Prometheus for scraping.

I still haven’t made up my mind as to what is a good interval. But I think I’ll take a per-endpoint approach, hitting more expensive ones less frequently.

So far I can only think of 4-5 endpoints/URLs that I should hit in every iteration as outlined in the post above.

web/mobile home feed
web/mobile create post/comment
web/mobile search

I think those will cover most of the usecases.

Thanks. Yes, lemmy-status.org was where I got the initial idea 💯

automatic list

For the website I’m thinking about, I’d rather keep it exclusively opt-in. I don’t wish to add any extra load since most of the instances are running off of enthusiasts’ pockets.

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!

Good point! I just replaced my LI profile photo w/ an abstract image 🍻

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 🙂