bahmanm

joined 1 year ago
MODERATOR OF
 

I've been working on a small project called bdockerimg.

It's a collection of pre-built Docker images for some less common development tools (currently bmakelib, QuickLisp, and SDKMAN).

The idea is to streamline setup, especially for CI/CD pipelines, where I found myself repeating the same Dockerfile steps a lot. Basic functionality tests are included for a bit of extra peace of mind.


πŸ‘€ Here's the repo if you're interested: https://github.com/bahmanm/bdockerimg
πŸ—£ And here's the the Matrix room: https://matrix.to/#/#bdockerimg:matrix.org


I'm curious:

  • Does this seem like something you might find useful?
  • Are there any specific tools you'd love to see as easy-to-use Docker images?

This project is still in its early stages, so any feedback or contributions are much appreciated πŸ™

 

Do you know any chess clubs/programmes for a 5-7 year old in Vancouver/Richmond area?

I would preferably want to be able to look up the coach(es) online or attend one of their lessons before enrolling my kid.

PS: I know I may sound very picky, but I have witnessed first hand how a not great tutor in the early ages can ruin the enthusiasm for chess and change the future.

 

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...
 

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...
 

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:

 

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.

[–] bahmanm@lemmy.ml 3 points 1 year ago (1 children)

I'm not an 1.e4 or Sicilian player but this smells like wild tactical variations early in the game.

 

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

[–] bahmanm@lemmy.ml 3 points 1 year ago

Done βœ…

Thanks for your interest πŸ™


Please do drop a line in either !lemmy_meter@lemmy.ml or #lemmy-meter:matrix.org if you've got feedback/ideas for a better lemmy-meter. I'd love to hear them!


Oh and feel free to link back to lemmy-meter from BlΓ₯haj if you'd like to, in case you'd prefer the community to know about it.

 

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 3 points 1 year ago

Update

sh.itjust.works in now added to lemmy-meter πŸ₯³ Thanks all.

[–] bahmanm@lemmy.ml 1 points 1 year 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 1 year ago

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

[–] bahmanm@lemmy.ml 0 points 1 year ago (3 children)

Which Debian version is it based on?

[–] bahmanm@lemmy.ml 10 points 1 year ago

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

[–] bahmanm@lemmy.ml 4 points 1 year 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 1 year 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 1 year 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 1 year 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 1 year 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.

view more: β€Ή prev next β€Ί