bahmanm

joined 2 years ago
MODERATOR OF
 

cross-posted from: https://lemmy.ml/post/8492082

bmakelib is a collection of useful targets, recipes and variables you can use to augment your Makefiles.


I just released bmakelib v0.6.0 w/ the main highlight being the ability to define enums and validate variable values against them.


➀ Makefile:

define-enum : bmakelib.enum.define( DEPLOY-ENV/dev,staging,prod )
include define-enum

deploy : bmakelib.enum.error-unless-member( DEPLOY-ENV,ENV )
deploy :
	@echo πŸš€ Deploying to $(ENV)...

➀ Shell:

$ make ENV=local-laptop deploy
*** 'local-laptop' is not a member of enum 'DEPLOY-ENV'.  Stop.

$ make ENV=prod deploy
πŸš€ Deploying to prod...
 

As of a couple of days ago, uptime indicators have been added to the health breakdown page allowing you to glance at the availability of the instance during the past 7, 30 and 90 days.

Screenshot 1

Screenshot 2

 

lemmy-synapse is a light-weight observability and monitoring stack for Lemmy servers.


Using Prometheus and Grafana, it allows the admins to visualise and query the stats of their instance. v1.0.0 comes out of the box with 3 detailed dashboards:

  • Host stats (CPU, RAM, disk, network, ...)
  • PostgreSQL stats (connections, locks, transations, queries, ...)
  • Docker stats (container CPU, RAM, disk, network, OOM signals, ...)

It runs as Docker compose cluster alongside the Lemmy cluster and does not require any changes to it in most cases. Uninstalling lemmy-synapse is as easy as tearing down its cluster and deleting its installation directory.


Got questions/feedback? Pray drop a line:

 

As an instance admin, would you be interested in receiving alerts in case lemmy-meter detects your instance's health has deteriorated?

The alerts could be sent to any combination of

  • a Matrix chat (private or channel)
  • a Discord server
  • an e-mail address

For example, you could receive an alert if the landing page hasn't been loading for the past 5 minutes.


The details of alerting levels and the conditions that'd trigger them will be ironed out later. At this stage I'd mostly would like to know if there's interest in this feature in the first place before getting to the implementation.


Follow up on https://github.com/bahmanm/lemmy-meter/issues/71

 

cross-posted from: https://lemmy.ml/post/6863402

Fed up w/ my ad-hoc scripts to display the targets and variables in a makefile(s), I've decided to write a reusable piece of code to do that: https://github.com/bahmanm/bmakelib/issues/81


The first step toward that would be to understand the common commenting styles. So far I have identified 4 patterns in the wild which you can find below.

Are there any style guides/conventions around this topic? Any references to well-written makefiles I can get inspiration from?


A

VAR1 = foo   ## short one-liner comment
my-target:   ## short one-liner comment 
	…

B

# longer comment which 
# may span
# several lines
VAR1 = foo

## comments can be prefixed w/ more than # 
## lorem ipsum dolor
my-target: 
	…

C

#####
# a comment block which is marked w/ several #s on
# an otherwise blank line
#####
VAR1 = foo

D

#####
#>    # heading 1
#     This is a variation to have markdown comments
#     inside makefile comments.
#
#     ## It's a made-up style!  
#     I came up w/ this style and used it to document `bmakelib`.
#     For example: https://is.gd/QtiqyA (opens github)
#<
#####
VAR1 = foo
 

Fed up w/ my ad-hoc scripts to display the targets and variables in a makefile(s), I've decided to write a reusable piece of code to do that: https://github.com/bahmanm/bmakelib/issues/81


The first step toward that would be to understand the common commenting styles. So far I have identified 4 patterns in the wild which you can find below.

Are there any style guides/conventions around this topic? Any references to well-written makefiles I can get inspiration from?


A

VAR1 = foo   ## short one-liner comment
my-target:   ## short one-liner comment 
	…

B

# longer comment which 
# may span
# several lines
VAR1 = foo

## comments can be prefixed w/ more than # 
## lorem ipsum dolor
my-target: 
	…

C

#####
# a comment block which is marked w/ several #s on
# an otherwise blank line
#####
VAR1 = foo

D

#####
#>    # heading 1
#     This is a variation to have markdown comments
#     inside makefile comments.
#
#     ## It's a made-up style!  
#     I came up w/ this style and used it to document `bmakelib`.
#     For example: https://is.gd/QtiqyA (opens github)
#<
#####
VAR1 = foo
 

cross-posted from: https://lemmy.ml/post/6856563

When writing a (GNU) Makefile, there are times when you need a particular target(s) to be run before anything else. That can be for example to check the environment, ensure variables are set or prepare a particular directory layout.

... take advantage of GNU Make's mechanism of includeing and makeing makefiles which is described in details in the manual:

 

When writing a (GNU) Makefile, there are times when you need a particular target(s) to be run before anything else. That can be for example to check the environment, ensure variables are set or prepare a particular directory layout.

... take advantage of GNU Make's mechanism of includeing and makeing makefiles which is described in details in the manual:

 

I just stumbled upon a collection of bash completions which can be quite handy: https://github.com/perlpunk/shell-completions

I tried mojo, cpan and pip completions in a sandbox and they worked like a charm!

The only question I've got is, has anyone ever done a security audit of the repository? Anyone has taken the time to look at the code? I could try auditing but I'm not even sure what to look for.

I feel quite wary of letting an unknown source access to my bash session and what I type.

 

I'm trying to gather requirements wrt a potential bmakelib feature linked in the post.

I'd appreciate your feedback around:

  • What are the conventions you follow to document your Makefiles?
  • How/where do you usually declare variables and how do you document them?

Please take a second to share your thoughts on the issue or simply reply to this post if you'd prefer πŸ™

 

With most of the initial tasks done, I think 🌎 lemmy-meter.info is in a good place now.

I just tagged v1.0.0-beta on the repository and will be focused mainly on polishing things and fixing potential bugs in the coming days before the release of v1.0.0.

In the meantime, I'd love to know about your experience using lemmy-meter and any feedback/ideas you may have about the current version or any future versions.

Thanks in adavnce πŸ™

 

I'm interested in registering for the tournament but I've got no clue as to where to begin? Where can I find the list of teams? How can I request to join a team?

I'd appreciate any help/hint πŸ™

[–] bahmanm@lemmy.ml 1 points 2 years ago

I didn't like the capitalised names so configured xdg to use all lowercase letters. That's why ~/opt fits in pretty nicely.

You've got a point re ~/.local/opt but I personally like the idea of having the important bits right in my home dir. Here's my layout (which I'm quite used to now after all these years):

$ ls ~
bin  
desktop  
doc  
downloads  
mnt  
music  
opt 
pictures  
public  
src  
templates  
tmp  
videos  
workspace

where

  • bin is just a bunch of symlinks to frequently used apps from opt
  • src is where i keep clones of repos (but I don't do work in src)
  • workspace is a where I do my work on git worktrees (based off src)
[–] bahmanm@lemmy.ml 14 points 2 years ago

Thanks! So much for my reading skills/attention span πŸ˜‚

[–] bahmanm@lemmy.ml 0 points 2 years ago (3 children)

Which Debian version is it based on?

[–] bahmanm@lemmy.ml 10 points 2 years ago

Something that I'll definitely keep an eye on. Thanks for sharing!

[–] bahmanm@lemmy.ml 4 points 2 years ago (2 children)

RE Go: Others have already mentioned the right way, thought I'd personally prefer ~/opt/go over what was suggested.


RE Perl: To instruct Perl to install to another directory, for example to ~/opt/perl5, put the following lines somewhere in your bash init files.

export PERL5LIB="$HOME/opt/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"
export PERL_LOCAL_LIB_ROOT="$HOME/opt/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"
export PERL_MB_OPT="--install_base \"$HOME/opt/perl5\""
export PERL_MM_OPT="INSTALL_BASE=$HOME/opt/perl5"
export PATH="$HOME/opt/perl5/bin${PATH:+:${PATH}}"

Though you need to re-install the Perl packages you had previously installed.

[–] bahmanm@lemmy.ml 3 points 2 years ago

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.

[–] bahmanm@lemmy.ml 4 points 2 years ago (1 children)

This is fantastic! πŸ‘

I use Perl one-liners for record and text processing a lot and this will be definitely something I will keep coming back to - I've already learned a trick from "Context Matching" (9) πŸ™‚

[–] bahmanm@lemmy.ml 1 points 2 years ago

That sounds a great starting point!

πŸ—£Thinking out loud here...

Say, if a crate implements the AutomatedContentFlagger interface it would show up on the admin page as an "Automated Filter" and the admin could dis/enable it on demand. That way we can have more filters than CSAM using the same interface.

[–] bahmanm@lemmy.ml 2 points 2 years ago

I couldn't agree more πŸ˜‚

Except that, what the author uses is pretty much standard in the Go ecosystem, which is, yes, a shame.

To my knowledge, the only framework which does it quite seamlessly is Spring Boot which, w/ sane and well thought out defaults, gets the tracing done w/o the programmer writing a single line of code to do tracing-related tasks.

That said, even Spring's solution is pretty heavy-weight compared to what comes OOTB w/ BEAM.

[–] bahmanm@lemmy.ml 1 points 2 years ago* (last edited 2 years ago)

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.

[–] bahmanm@lemmy.ml 2 points 2 years ago

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

[–] bahmanm@lemmy.ml 0 points 2 years ago* (last edited 2 years ago)

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 πŸ™‚

view more: β€Ή prev next β€Ί