14
submitted 2 weeks ago by bahmanm@lemmy.ml to c/programming@lemmy.ml

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

Just wanted to share some (exciting) news about my Common Lisp project, euler-cl. I finally got the time to sit down and integrate it with Codecov! This means a couple of cool things:

  • 📈 Test Coverage Tracking: I can now see how well my code is tested over time, giving valuable insights into code quality.
  • 🏅 Codecov Badge: euler-cl now sports a snazzy Codecov badge to show off!
  • 📦 Reusable Setup: The code and setup process should be simple enough to be used as a reference to integrate Codecov (and potentially other services) into your own Common Lisp projects!

If you're interested this commit is almost all you need: https://github.com/bahmanm/euler-cl/commit/855b014

Let me know in the comments if you have any questions or want to chat about integrating Codecov into your own projects!

4
submitted 2 months ago by bahmanm@lemmy.ml to c/programming@lemmy.ml

If you've found yourself manually crafting complex Docker images or repeatedly installing tools, I've got something for you 😁

Check out "fusions" in bdockerimg project (https://github.com/bahmanm/bdockerimg).


With fusions, you merge base images into powerful composite images.

Currently there are:

  • sdkman.bmakelib
  • quicklisp.bmakelib

Let me know what other fusions would make your Docker life easier 🙏

9
submitted 3 months ago by bahmanm@lemmy.ml to c/programming@lemmy.ml

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 🙏

1
submitted 3 months ago by bahmanm@lemmy.ml to c/vancouver@lemmy.ca

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.

1
submitted 6 months ago by bahmanm@lemmy.ml to c/lemmy_meter@lemmy.ml

Latency, aka Roundtrip Time (RTT) or Time To Load (TTL), is the time it takes for the instance to respond to an HTTP request.


Latency indicators have been added to the instance health breakdown dashboard, allowing you to view the latency of your favourite instance compared to itself:

  • Past 3 hours compared to the past 7 days
  • Past 24 hours compared to the past 30 days
  • Past 24 hours compared to the past 90 days

Screenshot 1

Screenshot 2

3
submitted 6 months ago by bahmanm@lemmy.ml to c/programming@lemmy.ml

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...
1
submitted 6 months ago by bahmanm@lemmy.ml to c/lemmy_meter@lemmy.ml

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

30
submitted 7 months ago by bahmanm@lemmy.ml to c/lemmy@lemmy.ml

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:

1
submitted 7 months ago by bahmanm@lemmy.ml to c/lemmy_meter@lemmy.ml

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

8
submitted 7 months ago by bahmanm@lemmy.ml to c/programming@lemmy.ml

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
12
submitted 7 months ago by bahmanm@lemmy.ml to c/programming@lemmy.ml

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:

14
submitted 7 months ago by bahmanm@lemmy.ml to c/programming@lemmy.ml

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 22 points 8 months ago

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 🙏

[-] bahmanm@lemmy.ml 42 points 8 months ago

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.

[-] bahmanm@lemmy.ml 33 points 9 months ago

If the controversies, allegations, rumors and gossips are about firefox though it definitely is important.
...
the huge chunks of money firefox gets from their biggest competitor

I think we're confusing things here 🙂

Examples of topics relevant to Firefox
  • [Hypothetical] Firefox collects user data w/o consent.
  • [Hypothetical] Researchers found government backdoors X, Y and Z in Firefox code base.
  • [Hypothetical] Firefox to disable Javascript by default.

Examples of topics NOT relevant to Firefox
  • Mozilla's contract w/ Google
  • Mozilla's political campaign
  • Mozilla's CEO allegedly being a selfish a-hole

Finally let's not forget that Firefox is an open source project, the result of the collaboration of hundreds, if not thousands, of people over the past 2 decades. Despite Mozilla's important role, there's way more to Firefox and its potential future than the usual corporate gossip/controversies.

My humble 2 cents 🙂

[-] bahmanm@lemmy.ml 73 points 9 months ago* (last edited 9 months ago)

I'd rather keep this community about Firefox the product and what it (doesn't) brings to the table. That's what I am, personally, interested in.

It'd be great if we could keep all the other things such as controversies, allegations, rumours, gossips, ... contained in a "mozilla" community and tried our best to maintain the separation.

[-] bahmanm@lemmy.ml 27 points 9 months ago

Interestingly "Bazzi" means "game" in Farsi 🤷‍♂️

[-] bahmanm@lemmy.ml 37 points 9 months ago

The GNU GPL is not Mr. Nice Guy. It says no to some of the things that people sometimes want to do. There are users who say that this is a bad thing—that the GPL “excludes” some proprietary software developers who “need to be brought into the free software community.”

But we are not excluding them from our community; they are choosing not to enter. Their decision to make software proprietary is a decision to stay out of our community. Being in our community means joining in cooperation with us; we cannot “bring them into our community” if they don't want to join.

[-] bahmanm@lemmy.ml 27 points 9 months ago

"Do you not know my son, with how little wisdom the world is governed?" 🤷‍♂️

[-] bahmanm@lemmy.ml 82 points 9 months ago* (last edited 9 months ago)

I wonder what would that mean for openSUSE, given that, apparently, an equity firm is making decisions on behalf of the SUSE board 😞

[-] bahmanm@lemmy.ml 48 points 9 months ago* (last edited 9 months ago)

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 💪

[-] bahmanm@lemmy.ml 42 points 10 months ago

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.

[-] bahmanm@lemmy.ml 28 points 11 months ago
view more: next ›

bahmanm

joined 11 months ago
MODERATOR OF