DEV Community: Francesco Bianco

🧠 How to Write Shell Scripts That Access Memory Safely

Francesco Bianco — Mon, 19 May 2025 14:16:10 +0000

Rust became popular for one key reason: it made memory safety a core principle. In a world where a small mistake like a segmentation fault or a race condition can crash an application—or worse, open it up to serious vulnerabilities—Rust stepped up and said: “No more.”

But what about us? Those of us who write shell scripts every day to automate DevOps tasks, manage CI/CD pipelines, handle data, files, and processes? Do we have any tools that help us write "memory-safe" shell code?

Not quite like Rust. But we do have a few tools to make things better. One of the most underrated? The local keyword.

🛡️ Why `local` Is Important

In Bash, when you define variables inside a function, those variables are global by default. This means that your function can accidentally change the global environment even after it finishes.

Here’s a simple example:

#!/bin/bash

foo() {
  var="modified"
}

var="original"
foo
echo "$var"  # -> prints "modified"

The function foo unexpectedly changed the global variable var. This can lead to hard-to-debug issues, especially in larger scripts or CI/CD environments with many functions.

🔐 Use `local` to Contain State

The local keyword solves this problem by making a variable local to the function scope:

foo() {
  local var="modified"
}

var="original"
foo
echo "$var"  # -> prints "original"

Just like Rust ensures memory isolation and ownership, local helps isolate variable state and prevent cross-function contamination.

⚠️ But Be Careful How You Use `local`

A very common mistake is doing this:

myfunc() {
  local myvar=$(some_command)
}

This is not safe. If some_command fails, behaves unexpectedly, or produces weird output, it may interfere with the local declaration.

Also, ShellCheck (an amazing Bash linter) warns against this with:

SC2155: Declare and assign separately to avoid masking return values.

The correct, safe way is:

myfunc() {
  local myvar
  myvar=$(some_command)
}

This separates the declaration (local myvar) from the assignment (myvar=$(...)), avoiding unintended behavior.

🧪 Practical Example

Let’s say you want a function that returns the size of a file in bytes:

get_file_size() {
  local size
  size=$(stat -c%s "$1")
  echo "$size"
}

file="example.txt"
echo "Size: $(get_file_size "$file") bytes"

In this example:

size is local and won’t affect other parts of the script
The function is safe and reusable
You avoid unexpected side effects

🔚 Final Thoughts

No, local isn’t Rust. But in the world of shell scripting, it’s one of the best tools we have for writing modular, safe, and maintainable code. Using it correctly helps prevent bugs and makes your scripts more robust and predictable.

If you're writing scripts for DevOps, CI/CD, or system automation, make local your default when working with function variables. It’s a small habit that brings huge value.

💬 Do you know other tips or patterns for writing safer, cleaner shell scripts? Share them in the comments! The more we exchange ideas, the stronger our scripting practices become.

What Would Rust Be Without Cargo? A Beautiful Disaster

Francesco Bianco — Wed, 07 May 2025 22:02:05 +0000

Ask any developer who’s used Rust what made the experience special.
Sure, they’ll mention memory safety, fearless concurrency, and expressive types.

But dig a little deeper, and something else almost always comes up:

Cargo.

Rust’s package manager and build tool isn’t just “nice to have.”
It’s the invisible architecture that makes Rust practical, structured, and even joyful.

Now imagine Rust without it:

No standard project layout.
No dependency management.
No easy testing or publishing.
No cargo build, cargo test, or cargo run.

Just a complex, opinionated systems language... with zero guidance or tooling.

It would be a beautiful disaster—full of promise, but hard to harness.

Now Think About Shell Scripts

Shell is ancient, universal, and indispensable.
But if we’re honest, scripting in Bash or Dash often feels like stepping back in time.

Despite its power, shell scripting is stuck in the dark ages:

Scripts are ad-hoc and fragile.
Logic is duplicated everywhere.
There's no clear way to structure or modularize projects.
Reuse? Testing? Versioning? Almost nonexistent.

It’s like we’ve been using Rust, but without Cargo—for decades.

What If Cargo Existed for Shell?

That’s the question that led me to something surprisingly elegant:

Mush — Modular Unix SHell

Mush brings to shell scripting what Cargo brings to Rust:

A project structure
Dependency management
Reusable packages and modules
Testing and build automation
Easy distribution

Mush speaks native shell, but gives it modern development tooling—without breaking the Unix philosophy.

Mush in Action

Let’s say you want to start a portable, testable, modular shell script project. Just run:

curl get.javanile.org/mush | sh
mush new hello_world
cd hello_world
mush run

In seconds, you're working inside a fully structured shell project, with support for:

extern packages
cross-shell compatibility (Bash, Dash, Zsh, Ksh, BusyBox)
integrated testing
easy publishing

You can even compose complex toolchains by stacking modules, just like you would with Rust crates.

Why It Matters

Just as Cargo turned Rust into a practical ecosystem, Mush is doing the same for shell scripting.

Without tooling, even the most elegant language becomes brittle.
And with the right tooling, even an ancient language like shell becomes powerful again.

Mush doesn't try to reinvent shell—it unlocks its potential.

Closing Thought

Rust without Cargo would have been a niche tool for systems nerds.

Shell without Mush... well, that’s what we’ve been living with.
It’s time for that to change.

If you believe scripting deserves structure,
If you want reuse, modularity, and sanity in your shell workflows—

Give Mush a try.

If You Run Your CI Locally, You’ve Already Failed

Francesco Bianco — Thu, 24 Apr 2025 23:30:14 +0000

“Run your GitHub Actions locally!” — ACT

“Why would you want to do that?” — Me, genuinely wondering

We live in an era where Continuous Integration (CI) — one of the most mature and battle-tested DevOps practices — is constantly being reinvented and reinterpreted. And then comes ACT, a popular tool that lets you run GitHub Actions locally.

How convenient, right?

Wrong. It's the symptom, not the cure.

The Dream Gone Wrong: CI as a Fancy Makefile

ACT was born out of a real frustration: testing GitHub workflow files is painful. Commit, push, wait, fail, repeat. We've all been there.

So someone thought: “Let’s run it locally!”

And boom, ACT was born.

But here’s the kicker: you’ve completely misunderstood what CI is supposed to be.

CI is not part of your development loop.

CI is not a fancy Makefile.

CI is not something you “test until it works and then push.”

CI is a gate.

CI is the external referee.

CI is the “Stop. This isn’t ready. Fix it before it hits the repo.”

The Anti-Pattern: Turning CI into a Dev Loop

When you use ACT to “test” your GitHub Actions workflows before pushing, you’re not optimizing — you’re subverting the entire purpose of CI.

CI is not here to help your code pass.

It’s here to block your code when it shouldn’t pass.

If you need to test your CI pipeline endlessly before pushing, then one of these is true:

Your CI is overly complex.
Your CI is too fragile.
Your CI lacks modularity and good design.

And that’s not a tooling issue — that’s a design flaw.

CI Failures Are Bugs — Compensatory Bugs

Let me say this loud and clear:

CI failures are not annoyances — they are bugs.

Not in your code, but in your process.

When your CI fails in production but passes locally, you’ve written compensatory logic. You’re covering up deeper issues with fragile CI setups that can’t scale or generalize.

ACT lets you hide from those failures. It lets you live in the illusion of “it worked locally, so it should work on GitHub too.”

That illusion is dangerous.

ACT Isn’t the Problem — Misuse Is

To be clear: ACT isn’t evil. It’s actually quite elegant.

It’s useful in emergencies, debugging, or extremely isolated edge cases.

But using it as part of your regular development flow?

That’s like testing the fire alarm with a match and saying, “See? It beeped.”

You’ve completely missed the point.

So What Should You Do Instead?

Design simpler workflows. Don’t shove your entire pipeline into yaml hell.
Use modular, testable shell scripts that your CI orchestrates, not defines.
Embrace CI failures as red flags, not hurdles.
Use ACT as a microscope, not as a mirror.

Final Thought

ACT is another example of devs chasing convenience over correctness.

It’s appealing, sure. But it betrays the whole point of what CI is supposed to be.

So next time you “run your CI locally,” ask yourself:

Are you solving the real problem — or just hiding from it?

Because if you need to run your CI locally to make sure it passes…

You’ve already failed.

Flame on.

Everyone Loves Open Source… Until It's Time to Contribute

Francesco Bianco — Wed, 23 Apr 2025 20:00:02 +0000

We live in an era where open source is everywhere. From backend tools to frontend frameworks, from infrastructure-as-code to machine learning libraries — open source is the backbone of modern software development.

And yet, when it comes to contributing, most developers are… missing in action.

This isn't a rant. It’s a reflection based on data, observations, and a little bit of lived experience. Let’s dig in.

🧠 The Hypothesis

"Everyone loves open source, but when asked to contribute — even a little — participation is surprisingly low."

Sound familiar? If you've ever maintained or promoted an open source project, you've likely seen this pattern.

📊 The Data Doesn’t Lie

1. A Tiny Core Does the Heavy Lifting

Most open source projects are maintained by a very small group of contributors. GitHub's Octoverse reports over the years consistently show that a vast majority of contributions come from a minority of users.

A DEV article by @szabgab hits the nail on the head:

“There are hundreds of thousands of open source projects out there. Most of them have few contributors. Many have exactly one.”

2. Barriers Are Real

According to a 2020 study on ScienceDirect, developers face numerous obstacles that prevent them from contributing, including:

Lack of clear documentation
Complex or unfamiliar codebases
Poor or no response from maintainers
Imposter syndrome (especially among juniors or underrepresented groups)

It’s not always about laziness — sometimes it’s about not knowing how to start or not feeling welcomed.

3. Recognition Is Rare

Contributing takes time. And when contributors feel their efforts aren’t acknowledged, they’re less likely to stick around.

As pointed out in this piece by OpenSauced, recognition isn't just about ego — it's about visibility, growth, and belonging.

🧠 Why This Bias Matters

It’s easy to fall into the trap of blaming "the community" for lack of participation. But understanding the psychological, structural, and social factors behind the gap helps us build better systems.

If we want more contributions, we need to lower the barriers and raise the rewards.

✅ What Can We Do?

Here are a few practical steps to improve participation:

Good First Issues: Label them well and make sure they’re actually beginner-friendly.
Mentorship or buddy systems: Pair new contributors with experienced ones.
Clear contribution guidelines: A simple CONTRIBUTING.md goes a long way.
Say thank you: Shout out contributors in README files, releases, or community posts.
Lower the entry bar: Sometimes a typo fix is the first step to a lifelong contributor.

🎯 Final Thoughts

Loving open source is easy.
Using open source is convenient.
Contributing to open source is a choice — one that we can make easier for others.

If you’re reading this, maybe it’s time to open that first PR. Or if you’re a maintainer, maybe it’s time to open the door a little wider.

Let’s turn passive users into active contributors — together.

Want to discuss this or collaborate on something open source? Drop a comment or ping me on GitHub!

Stop Writing Messy Bash Scripts: Build Real Internal Tools with Mush

Francesco Bianco — Tue, 22 Apr 2025 22:42:25 +0000

In the DevOps world, internal tooling is not a luxury—it's a necessity. Whether you're deploying to Kubernetes, releasing software, or bootstrapping new services, custom scripts often bridge the gap between teams, tools, and infrastructure.

But let's face it: internal scripts tend to start as quick-and-dirty Bash hacks, and over time, they become unreadable, unmaintainable, and fragile. Sound familiar?

What if we could treat Bash like a real programming language, with structure, modules, versioning, and installable tools?

That’s where Mush comes in.

The State of Internal Tooling in DevOps

Almost every DevOps team builds their own tools. Here are some real-world examples:

Tool Name	What It Does
`deploy.sh`	Deploy a service with custom settings
`release.sh`	Create a new release and update changelogs
`check-env`	Verify if the developer machine has the required dependencies
`onboard.sh`	Set up a new repo with templates and CI/CD
`kube-wrapper`	Simplify Kubernetes commands across namespaces and clusters
`git-policies`	Enforce Git commit rules and tag naming

These tools often grow from a one-liner in a README to a critical script used by the entire team—yet we rarely invest in making them maintainable.

Why Bash Scripts Get Ugly

No module system (copy-paste culture)
Zero discoverability (--help? What help?)
Hard to test
Impossible to version cleanly
No proper CLI structure or autocompletion
Unclear dependencies

What if we could fix all of that—without leaving Bash?

Meet Mush: Modular Shell Scripting

Mush is a lightweight ecosystem that gives your Bash scripts:

A clear project structure (src/, tests/, mush.yaml)
Modular architecture (module primitive to load other scripts)
Built-in CLI command dispatching
Automatic --help generation
Dependency management via Git
Easy install and distribution (mush build, mush install)

Think of it like Cargo for Shell.

A Real Example: Hello, Bash Tool

Let’s build a simple CLI tool using Mush.

mush new hello-bash
cd hello-bash

Create your main file:

# src/main.sh
main() {
  echo "Hello, Bash World!"
}

Your config file:

# Manifest.toml
name: hello
version: 0.1.0

Build and run:

mush build --release
./bin/hello

Result:

$ ./bin/hello
Hello, Bash World!

You now have a real executable, with structure, dispatch, and versioning—using only Bash.

Internal DevOps Tooling with Mush

Let’s imagine some real DevOps use cases:

1. A CLI to Standardize Deployments

# src/deploy.sh
module utils

devops::deploy() {
  env="$1"
  utils::banner "Deploying to $env..."
  kubectl apply -f k8s/$env.yaml
}

./devops deploy staging

Now you have devops deploy, devops help, devops version... all for free.

2. Kubernetes Wrapper Tool

kubetool logs app-name --env prod
kubetool switch-context dev
kubetool apply-all teamX

Under the hood: one script per command in src/, loaded with module and structured like a Go or Rust CLI.

3. Project Onboarding Tool

onboard new-service

Clones a template repo
Sets up CI/CD
Creates GitHub repo
Registers service in monitoring

Organized as:

src/
├── main.sh
├── git.sh
├── ci.sh
├── register.sh

Reused across teams. Versioned. Maintained. Documented.

Why Mush Matters

For DevOps teams, Mush is a game changer:

No more spaghetti Bash
Encourages structure and reuse
Teams can collaborate on shared modules
Tools can be versioned, installed, and reused
Easy to write, even easier to maintain

Mush brings modern software development practices to one of the most widely used languages in infrastructure—Bash.

Final Thoughts

Every time you write a script like deploy.sh, you’re building a tool.

Why not treat it like one?

Mush lets you build real, structured, maintainable tools—with zero dependencies and 100% Bash.

So next time your team needs a CLI helper, skip the Python and Go boilerplate. Use Mush, and make your scripts proud.

Try it out

GitHub: github.com/javanile/mush
brew install javanile/tap/mush
mush init my-tool && cd my-tool && mush build

Happy scripting!

101 Ideas for Smart DevOps Tools 🚀🛠️

Francesco Bianco — Fri, 18 Apr 2025 07:21:53 +0000

💡 This list was created to inspire developers, sysadmins, and DevOps enthusiasts to build their own tools instead of spending thousands of dollars on vendor-locked SaaS platforms.

A true DevOps engineer doesn't just use tools—they build them.

This is the mindset that separates a button-pusher from a toolsmith. 👩‍🔬

Too many modern DevOps teams rely on tools that are closed, bloated, overpriced, and slow to evolve. Real DevOps culture is about automation, transparency, and self-sufficiency. 🧰

That’s why I’ve curated this list of 101 CLI-based tool ideas you can build, contribute to, or adapt for your stack.

Perfect for:

Hackathons 🎎
Side Projects 🌱
GitHub Actions and GitLab CI pipelines 🤖
Learning Bash, Go, Python, Rust 🐍🦀
Automation scripts at work 💼
Showing off your DevOps chops 💪

🐳 Docker & Container Tools

DockClean – Clean up unused Docker containers, volumes, and images.

$ dockclean --all
ImageShrink – Optimize Dockerfiles and reduce image sizes.

$ imageshrink my-image:latest
LayerView – Visualize Docker image layers in the terminal.

$ layerview my-image:latest
TagWatch – Monitor Docker Hub for new image tags.

$ tagwatch nginx
PrivPush – CLI for interacting with a private Docker registry.

$ privpush myregistry.io/my-image
SecretScan – Scan Docker images for secrets.

$ secretscan my-image:latest
ComposeDiff – Compare two Docker Compose files.

$ composediff docker-compose.old.yml docker-compose.new.yml
LayerDiff – Show changes between Docker image layers.

$ layerdiff image1 image2
OrphanWipe – Remove orphaned Docker volumes.

$ orphanwipe
DockSpy – Monitor container CPU, memory, and network usage.

$ dockspy container-id

☸️ Kubernetes Tools

KubePodRestart – List pods with frequent restarts.

$ kubepodrestart --threshold 5
KubePort – Port-forward to a pod/service with autocomplete.

$ kubeport my-service
KubeSnapshot – Snapshot current cluster resources.

$ kubesnapshot --output snapshot.yaml
KubeNSwitch – Quickly switch namespaces.

$ kubenswitch dev
KubeGarbage – Clean up old deployments and jobs.

$ kubegarbage --older-than 7d
KubeWhoami – Show current context, user, and namespace.

$ kubewhoami
KubeSecretEdit – Edit secrets in a safe and encrypted way.

$ kubesecretedit my-secret
KubeHPAWatch – Monitor Horizontal Pod Autoscaler behavior.

$ kubehpawatch deployment-name
KubeNodes – Show node stats (CPU, mem, pods).

$ kubenodes --all
KubeLinterWrap – Wrapper for kube-linter with presets.

$ kubelintwrap ./manifests

🧪 CI/CD Pipeline Tools

PipelineTimer – Measure execution time of CI stages.

$ pipelinetimer .gitlab-ci.yml
CIEnvExport – Export CI environment variables locally.

$ cienvexport > .env
GitCITrigger – Trigger pipelines from CLI.

$ gitcitrigger --project my/repo --ref main
CITestMatrix – Generate matrix builds from YAML.

$ citestmatrix matrix.yml
CISecretsAudit – Check pipeline for secret leaks.

$ cisecretsaudit .github/workflows/main.yml
CIEmojiStatus – Display emoji-based status of last CI run.

$ ciemojistatus
ArtifactFetch – Fetch CI/CD artifacts easily.

$ artifactfetch build.zip
CIYamlMerge – Merge multiple CI yaml files into one.

$ ciyamlmerge base.yml env.yml > final.yml
CIJobKill – Kill hanging CI jobs from CLI.

$ cijobkill --job 12345
WebhookFire – Trigger test webhooks locally.

$ webhookfire --url http://localhost --event push

🧑‍💻 Git & GitHub Tools

GitWIP – List all WIP branches across repos.

$ gitwip
PRCreator – Open PRs from terminal with template.

$ prcreator --title "Fix bug"
BranchLinter – Enforce branch naming policies.

$ branchlinter --check
GHStatus – Check GitHub Actions CI status of repo.

$ ghstatus
RepoSync – Sync forks or mirror repositories.

$ reposync --all
StarStats – Show star growth of a repo.

$ starstats myrepo
GHDash – Terminal dashboard of GitHub issues and PRs.

$ ghdash
GHReviewers – Suggest reviewers for PRs based on history.

$ ghreviewers PR-ID
GitConfigCheck – Ensure global/local configs are set.

$ gitconfigcheck
PRConflictCheck – Check if a PR is conflicting before merge.

$ prconflictcheck PR-ID

🧠 Dev Tools

SnippetGen – Generate code boilerplates.

$ snippetgen react-component
RandData – Generate fake data for DB seeding.

$ randdata --rows 100 --format csv
RandUser – Generate fake user profiles.

$ randuser --count 5
PassGen – Strong password generator.

$ passgen --length 20
NickGen – Generate nicknames for users/bots.

$ nickgen
Text2Speech – Convert text to audio (mp3).

$ text2speech "Hello world"
TextSummary – Summarize a text using OpenAI.

$ textsummary my-report.txt
FlashcardCSV – Convert text into flashcards CSV for Anki.

$ flashcardcsv notes.txt
HT2PDF – Convert HTML to PDF.

$ ht2pdf index.html
MD2HTML – Convert Markdown to HTML.

$ md2html README.md

🛠️ System & Infra Tools

PortScan – Scan open ports on a host.

$ portscan 192.168.1.1
DiskWatch – Watch disk usage over time.

$ diskwatch /mnt/data
MemCheck – Print memory usage of top processes.

$ memcheck
CpuTemp – Display CPU temperature.

$ cputemp
ProcWatch – Monitor a process by name or PID.

$ procwatch nginx
LoadAvg – Show system load average.

$ loadavg
LogTail – Tail and grep multiple logs.

$ logtail /var/log/*.log --grep ERROR
SysUpdate – Unified updater for multiple Linux distros.

$ sysupdate
DnsPing – Test DNS resolution and latency.

$ dnsping google.com
UptimeTop – Visual uptime and reboot history.

$ uptimetop

🔐 Security Tools

JwtDecode – Decode and verify JWTs.

$ jwtdecode token.jwt
VaultPeek – View secrets in Vault without revealing full value.

$ vaultpeek secret/myapp
CertCheck – Check SSL certificate expiry.

$ certcheck google.com
PortAudit – Find services exposed on public IPs.

$ portaudit
BashSafe – Scan bash scripts for insecure patterns.

$ bashsafe deploy.sh
KeyGenRSA – Generate RSA key pairs.

$ keygenrsa --bits 2048
HashFile – Compute hash (md5, sha1, sha256) of a file.

$ hashfile my.zip --algo sha256
YaraWatch – Run YARA rules on files or folders.

$ yarawatch ./bin
IPBanCheck – Check if your IP is in common blocklists.

$ ipbancheck
SecureWipe – Securely delete files.

$ securewipe secrets.txt

📦 Package & Build Tools

BinSize – Check the size of compiled binaries.

$ binsize ./myapp
PkgVersion – Auto-increment semver version.

$ pkgversion patch
TarPlus – Enhanced tar wrapper with progress.

$ tarplus -czf archive.tar.gz folder/
MakeGraph – Visualize Makefile dependencies.

$ makegraph Makefile
DebMaker – Create .deb packages easily.

$ debmaker ./build
PyInstallerWrap – Simplified CLI for PyInstaller.

$ pyinstallerwrap app.py
GoBuildScan – Scan Go binaries for debug info.

$ gobuildscan mytool
NPMSizeCheck – Check size of npm dependencies.

$ npmsizecheck
LicenseCheck – Check open-source licenses in your project.

$ licensecheck
BinCompat – Check binary compatibility across systems.

$ bincompat ./app

📊 Monitoring & Visualization Tools

GrafLog – Convert logs to Grafana-friendly JSON.

$ graflog access.log
AlertTest – Trigger mock alerts to test integrations.

$ alerttest --channel slack
DashTerm – Terminal-based live dashboard.

$ dashterm
TracePlot – Visualize HTTP traces.

$ traceplot traces.json
HeatmapGen – Generate activity heatmaps.

$ heatmapgen git-log.txt
MetricGen – Create mock Prometheus metrics.

$ metricgen --type gauge
StatusTicker – Show system status in ticker format.

$ statusticker
JsonStat – Summarize large JSON logs.

$ jsonstat logs.json
TrendDiff – Show visual diffs in metric trends.

$ trenddiff --before old.json --after new.json
PulseBeat – Show heartbeat events in terminal.

$ pulsebeat --interval 10

🧰 Misc Tools

TodoLog – Add todos with timestamps.

$ todolog "Fix NGINX config"
ClipShare – Share clipboard text via short URL.

$ clipshare
QrText – Generate QR codes from text.

$ qrtext "https://my.site"
DirSizeTop – Show largest directories.

$ dirsizetop /var
AsciiArtify – Convert images to ASCII.

$ asciiartify logo.png
SleepCalc – Calculate optimal sleep cycles.

$ sleepcalc --now
WakeMe – Schedule a command to run at wakeup.

$ wakeme "notify-send \"Get to work!\""
HttpDump – Dump HTTP requests/responses.

$ httpdump --port 8080
ChatMem – Store short chat memory notes.

$ chatmem "Need to check cron jobs"
NowWhat – Suggest a random productivity tip.

$ nowwhat
ToolSuggest – Suggest a random tool idea from this list.

$ toolsuggest

📣 Join the Hackathon!

I'm launching a community DevOps Hackathon 👨‍💻👩‍💻

Build one of these tools (or your own!)

Fork it, share it, improve it, make it yours.

And submit it for feedback, visibility, and collaboration!

More info coming soon. Stay tuned on my LinkedIn and GitHub!

💬 Share This With Your Team

👈 If you found even one idea useful, hit ❤️ and

📬 share this list in your company Slack or Discord channel

💬 Ask: "Which one shall we build in our next hackday?"

🚀 Let's stop buying stuff we can build better ourselves.

🔁 Like. Share. Build.

Let’s bring the craft back to DevOps.

Let’s build smart tools, not just use bloated ones.

Which idea will you build first?

Let me know in the comments 👇👇👇

🌟 Hackathon Tamasha: Where DevOps Meets Creativity! 🚀

Francesco Bianco — Sat, 29 Mar 2025 13:07:20 +0000

Calling All DevOps Innovators – Join the Challenge & Win! 🏆

Are you ready to showcase your DevOps skills and compete in a global hackathon? Hackathon Tamasha is here to challenge your creativity and technical expertise! Whether you’re a seasoned DevOps engineer or just starting, this is your chance to shine, win prizes, and connect with a growing community of like-minded innovators.

🔥 What’s the Challenge?

Your mission is to create a command-line tool that simplifies daily DevOps tasks using Mush – a new, game-changing tool designed to revolutionize embedded scripting and automation in DevOps workflows.

💡 Example project ideas:

A script to stop all running Docker containers.

A tool to clean up unused containers and free up disk space.

A utility to extract files from a running container.

If you love automation and want to build something impactful, this is your moment! 🚀

💻 How to Participate

1️⃣ Fork the Repository & Get Started

👉 Click here to Fork & Start the Challenge

2️⃣ Set Up Your Environment

curl get.javanile.org/mush | sh
mush init

3️⃣ Build, Test & Push Your Code

Develop your tool using Mush & Bash.

Document it with a clear README.md.

Implement a GitHub Action to automate tests or other tasks.

Invite your friends to star ⭐ your project and gain visibility!

4️⃣ Check the Leaderboard & Win Prizes 🎯

The project with the most GitHub stars ⭐ by April 14th wins $10! 💰

🎉 Why Should You Join?

✅ Boost Your DevOps Portfolio – Get hands-on experience in automation & CI/CD. ✅ Gain Recognition in the Open Source World – Your project will be part of a growing DevOps ecosystem. ✅ Connect with the Community – Join our WhatsApp group & collaborate with other DevOps enthusiasts.

👥 Join the Mush DevOps Community 👉 WhatsApp Group

🌍 Why Indian Developers Should Join

India is a powerhouse of tech talent, with one of the largest DevOps and cloud engineering communities. Hackathon Tamasha is designed to give Indian developers a global stage to showcase their skills. Whether you’re a student, a professional, or an open-source contributor, this is your opportunity to gain visibility, sharpen your skills, and win prizes!

🚀 Let’s build the future of DevOps together!

Click here to Fork & Join the Hackathon

How to Make Conventional Commits a Lasting Habit?

Francesco Bianco — Mon, 24 Mar 2025 20:42:08 +0000

Conventional commits sound great in theory: structured, readable commit messages that make history tracking easier. But let's be honest—most of us try them for a few days and then fall back into our old habits. Why? Because it’s tedious to remember the exact syntax, and we often don’t have the patience to write proper commit messages when we’re in the zone.

The Problem: Conventional Commits Fade Away Quickly

If you've ever attempted to enforce conventional commits in your projects, you might have noticed this pattern:

Day 1: You're excited and commit with messages like feat: add authentication module or fix: resolve login bug.
Day 3: You start forgetting the exact format and write something like feat(auth): added stuff.
Day 7: You're back to fix bug or wip, and conventional commits are a thing of the past.

It’s not that you don’t see the value—it’s just hard to stay consistent without frictionless tooling. That’s where convcommit comes in.

Meet Convcommit: Your Memory Booster for Commit Messages

convcommit is a simple but powerful CLI tool that ensures you never fall back into bad commit habits. It does a few things:

✅ Guides you through commit message selection – No need to memorize commit types or scopes.

✅ Stores and suggests your previous messages – If you’ve used a message before, you can quickly reuse it.

✅ Works with git add . and git push seamlessly – Keeping your workflow fast and efficient.

How It Works

Using convcommit is straightforward:

Install it (if you haven’t already):

   mush install convcommit

Run it whenever you commit:

   convcommit -a -p

Select the commit type, scope (if any), and message from suggestions or enter a new one.

That’s it! No more second-guessing your commit messages or breaking your commit history structure.

Why You Should Start Using It Today

Develop muscle memory: The more you use it, the more natural conventional commits become.
Maintain a clean commit history: Future-you (and your teammates) will thank you.
Boost your personal branding: Writing clean commits is a sign of professionalism in open-source projects.

Try It Now and Make Your Commits Count!

You can check out convcommit on GitHub, give it a star ⭐, and start using it today:

👉 GitHub Repo

Let me know what you think, and if you have ideas for improvements, PRs are always welcome! Happy committing! 🚀

Stop Bloating Your Containers! Why Your Cron Jobs Don't Belong There 🚀

Francesco Bianco — Sun, 23 Mar 2025 09:29:40 +0000

Are you still stuffing cron jobs inside your Docker containers? In 2025, that's like wearing socks with sandals to a tech conference! Let me blow your mind with a game-changing approach that will make your DevOps colleagues worship the ground you walk on.

The Hidden Nightmare Inside Your Containers

We've all been there. You build this beautiful, sleek container for your application, and then someone says: "Hey, we need to run a scheduled task every hour to clean up temp files." And just like that, your elegant container becomes a bloated mess:

Install cron inside your container ✅
Create a crontab file ✅
Set up proper logging ✅
Make sure cron daemon starts properly ✅
Debug why your jobs aren't running ✅
Repeat for EVERY container that needs scheduling ✅

Before you know it, your lightweight container has gained 50MB of unnecessary bulk, and you're spending more time debugging cron than working on your actual application.

There's a better way.

Enter javanile/crontab: The Docker Composer's Dream

What if I told you there's a way to keep your containers lean and focused on their primary purpose while managing all your scheduled tasks from a single, centralized place? Meet javanile/crontab - the superhero your Docker Compose setup has been waiting for.

Why This Will Change Your Container Life Forever

1. Ridiculously Simple Setup

Just add this to your docker-compose.yml and you're ready to schedule anything:

version: "3"

services:
  crontab:
    image: javanile/crontab
    command:
      - "* * * * * ping 8.8.8.8"
      - "0 0 1 * * rm -fr /tmp"

That's it. No more installing cron packages, no more fighting with startup scripts.

2. Your Containers Stay Pure and Focused

By extracting scheduled tasks out of your application containers, each component in your architecture becomes cleaner and more maintainable. Your application containers do what they do best - run your application. Period.

3. Centralized Schedule Management

Imagine updating a cron schedule without rebuilding containers. Imagine seeing all your scheduled tasks in one place. With javanile/crontab, you're not just dreaming anymore.

Real-World Superpowers

Need something more complex? No problem. Mount your application directory and the Docker socket to enable true scheduling superpowers:

version: "3"

services:
  crontab:
    image: javanile/crontab
    command:    
      - "* * * * * bash /app/my-project-script.sh"
    volumes:
      # Mount local path '.' over '/app' to access your scripts
      - .:/app      
      # Mount 'docker.sock' to enable your script to run 'docker compose' commands
      - /var/run/docker.sock:/var/run/docker.sock

Now you can schedule scripts that interact with your other containers! Want to run a backup of your database container every night at 2 AM? Easy. Need to restart a service once a week? Done.

The Cherry on Top: Effortless Logging

Debugging cron jobs is usually a special circle of hell. But with javanile/crontab, all logs are automatically sent to stdout. Just run:

$ docker compose logs -f crontab

And watch your scheduled tasks execute in real-time. No more digging through system logs or wondering why your job didn't run.

The Time to Change Is Now

Still not convinced? Consider this: Every unnecessary component in your container is:

More potential security vulnerabilities
More disk space used
Longer build times
More complex debugging

By extracting your scheduled tasks to a dedicated crontab container, you're not just following best practices - you're embracing the true Docker philosophy of single-purpose containers.

Get Started Today

Ready to revolutionize how you handle scheduled tasks in your Docker environment? Head over to GitHub and star the project that's changing the game for DevOps professionals worldwide.

Remember: Your containers should do one thing and do it well. Let javanile/crontab handle the scheduling, so your application containers can focus on what matters.

Licensed under MIT - because great tools should be free to use and improve.

What's your experience with scheduled tasks in Docker? Have you tried this approach? Let me know in the comments below! 👇

The Secret Chamber Every Developer Should Have: Unleashing the Power of Side Repositories

Francesco Bianco — Fri, 21 Mar 2025 16:52:20 +0000

Have you ever found yourself struggling with sensitive files that shouldn't be committed to your main repository? Or perhaps you have common utilities that you reuse across projects but don't want to maintain multiple copies of? What if I told you there's a secret development pattern that can solve these problems and more?

Enter the side repository — a complementary codebase that works alongside your main project, offering a hidden chamber of possibilities that many developers overlook.

What Exactly Is a Side Repository?

A side repository is exactly what it sounds like: a secondary Git repository that exists parallel to your main project repository. It's not a fork or a branch, but a completely separate repository with its own history, purpose, and contents that somehow integrates with your primary codebase.

Think of it as your project's secret vault — a place to store valuable assets that don't belong in your main codebase but are still essential to your workflow.

Why You Might Need a Secret Chamber

You might be wondering: "My .gitignore works fine, why complicate things?" Here's where side repositories shine:

1. Sensitive Configuration Management

While .gitignore helps you avoid committing sensitive files, it doesn't help you share or back them up. A side repo can store:

.env files with different configurations
API keys and credentials
Development certificates
License files

All while keeping them organized and versioned, but separate from your main code.

2. Team Resources Without the Noise

Ever had to send a configuration file to a new team member or found yourself saying, "Oh, you need to create this file locally"? A side repo eliminates these friction points by providing:

A shared storage for development tools
Template configurations that new team members can access
Documentation that doesn't belong in the main repo

3. Cross-Project Resource Management

Perhaps the most powerful use case is maintaining resources that span multiple projects:

Shared scripts and utilities
Common CI/CD configurations
Design assets and templates
Database seeds or fixtures

Making It Even Easier with git-popper

For those who want a more streamlined approach to managing side repositories, check out git-popper, a minimalist side repository manager that automates the integration between your main and side repositories.

This tool, available at https://github.com/francescobianco/git-popper, simplifies the entire process with a declarative approach:

## Use this as side repository
FROM https://github.com/your-side-repo.git

## Store and sync local files into this remote directory of the repository
WORKDIR projects/2025/myproject

## Sync local files into side repo to prevent losing secret files
ADD .env
ADD .secrets
ADD Makefile-dev

With git-popper, you can define which files to synchronize in a .gitpopper configuration file and use simple commands to maintain the connection between repositories:

git-popper sync   # Synchronize changes between repositories
git-popper pull   # Get latest changes from side repository
git-popper push   # Push changes to side repository

It's an elegant solution that takes the manual work out of the patterns described below.

Setting Up Your Secret Chamber

Creating a side repository is straightforward:

Create a new repository (private if it contains sensitive information)
Structure it according to your needs
Clone it alongside your main repository

projects/
├── main-project/  # Your main repository
└── main-project-side/  # Your side repository

Integration Patterns

There are several ways to integrate a side repository with your main project:

1. The Symlink Approach

Create symbolic links from your main project to files in your side repository:

ln -s ../main-project-side/config/.env .env
ln -s ../main-project-side/scripts ./scripts

2. The Copy-on-Setup Approach

Copy necessary files during project setup:

# In your setup script
cp -r ../main-project-side/config/* ./config/

3. The Automation Tool Approach

Create a simple script that manages synchronization:

#!/bin/bash
# sync-side-repo.sh
rsync -av --exclude='.git' ../main-project-side/shared/ ./

4. The Git Submodule Approach (Advanced)

For more sophisticated integration, Git submodules can link repositories:

git submodule add git@github.com:your-org/main-project-side.git side

Real-World Success Stories

At my company, we implemented a side repository pattern for our microservices architecture. Each service had its own repository, but we maintained a shared side repository containing:

Common Docker configurations
Shared authentication utilities
Local development environment setup
Database migration tools

This approach reduced duplication by 70% and cut onboarding time for new developers from days to hours.

Pitfalls to Avoid

Like any pattern, side repositories come with potential downsides:

Drift - If not properly maintained, your side repo can become out of sync
Dependency Management - Creating circular dependencies between repos
Overuse - Using the side repo as a dumping ground for anything

Is a Side Repository Right for You?

A side repository makes the most sense when:

You have sensitive configurations that need version control
Your team frequently shares non-code resources
You maintain similar setups across multiple projects
You need controlled access to certain resources

If you're nodding your head to any of these points, it might be time to open your own secret chamber.

Getting Started Today

Begin small:

Identify files that are currently in your .gitignore but would benefit from version control
Create a private repository
Move those files there with a clear organization structure
Implement one of the integration patterns described above or try git-popper for a more automated approach

You can install git-popper quickly with:

curl -fsSL https://raw.githubusercontent.com/francescobianco/git-popper/main/bin/git-popper | sudo tee /usr/local/bin/git-popper > /dev/null && sudo chmod +x /usr/local/bin/git-popper

Conclusion

The side repository pattern isn't revolutionary, but it's remarkably effective. It provides a clean separation of concerns, keeps your main repository focused, and solves common development workflow issues that every team faces.

Have you used side repositories in your projects? What integration patterns worked best for you? Share your experiences in the comments!

Francesco Bianco is a senior developer with over a decade of experience optimizing development workflows and architecture patterns across enterprise applications.

Organizing Large Shell Script Codebases with Mush

Francesco Bianco — Mon, 24 Feb 2025 18:52:09 +0000

Shell scripting is a powerful tool for automation, system administration, and software deployment. However, as your shell scripts grow in size and complexity, maintaining them can become a nightmare. Code duplication, lack of modularization, and difficulty in testing are common pitfalls.

Enter Mush by Javanile—an innovative framework designed to bring structure and maintainability to large shell script projects. In this article, we’ll explore how Mush can help you organize your shell scripts efficiently and improve code reusability.

Why Do Large Shell Script Codebases Become Unmanageable?

Traditional shell scripts tend to evolve in an ad-hoc manner. As the codebase expands, you may face:

Spaghetti Code: Scripts grow into monolithic, hard-to-read files.
Code Duplication: No clear way to reuse functions across different scripts.
Poor Dependency Management: Sourcing multiple files manually is cumbersome.
Difficult Debugging: Large scripts lack structured error handling and logging.

Mush offers a structured approach to shell scripting, making it easier to scale and maintain your scripts.

What is Mush?

Mush (short for Modular Unix Shell) is a framework that enhances shell scripting by introducing:

Modular architecture
Dependency management
Autoloading functions
Built-in testing and debugging tools

Mush is inspired by modern programming paradigms, allowing shell scripts to be structured similarly to software projects in Python or JavaScript.

Setting Up a Mush-Based Shell Script Project

To start using Mush, you need to install it:

curl -fsSL https://mush.sh/install | sh

Once installed, you can initialize a new Mush project:

mush init my-shell-project
cd my-shell-project

This creates a structured project layout:

my-shell-project/
├── bin/       # Main executable scripts
├── mush/      # Mush modules (functions and utilities)
├── test/      # Unit tests for your scripts
└── Mushfile   # Dependency and module definitions

Structuring Your Shell Scripts with Mush

1. Breaking Code into Modules

Instead of writing large scripts, you can modularize your functions inside mush/:

# mush/logger.sh
log_info() {
  echo "[INFO] $1"
}

log_error() {
  echo "[ERROR] $1" >&2
}

Now, any script inside bin/ can use the log_info and log_error functions without manually sourcing them.

2. Autoloading Modules with Mushfile

Mush provides automatic module loading using Mushfile. Define your dependencies like this:

module logger

Now, you can use log_info and log_error without explicitly sourcing logger.sh.

3. Writing Executable Scripts

Create a script in bin/ that utilizes your modules:

#!/usr/bin/env mush

log_info "Starting process..."
# Your script logic here
log_info "Process completed."

Make it executable:

chmod +x bin/myscript

And run it:

./bin/myscript

4. Managing Dependencies

Mush allows you to manage dependencies in an elegant way. You can install modules from external sources or repositories, ensuring your scripts remain lightweight and modular.

To add an external module:

mush add https://github.com/example/shell-utils.git

5. Testing Your Shell Scripts

Mush provides a built-in testing framework. Create a test script in test/:

# test/logger_test.sh
assert_log_info() {
  output=$(log_info "Test message")
  [[ "$output" == "[INFO] Test message" ]]
}

Run your tests with:

mush test

Conclusion

Mush transforms shell scripting from a chaotic, hard-to-maintain practice into a structured and scalable development approach. By modularizing your scripts, automating dependency management, and integrating testing, you can build large-scale shell applications with confidence.

Ready to streamline your shell scripts? Try Mush today and bring order to your codebase!

🔗 Learn more about Mush

Unveiling the Power of Alphabetor: Enhancing Cryptographic Prowess and Password Mastery 🚀💻🔐

Francesco Bianco — Thu, 08 Feb 2024 09:01:52 +0000

Are you a developer fascinated by the intricate world of cryptography? Do you find yourself intrigued by the art of crafting powerful passwords that stand as guardians of digital fortresses? If so, then let's embark on a journey together, exploring the significance of memorizing the alphabet's letter positions and how it can empower your cryptographic endeavors.

Alphabetor, a captivating game crafted with the sole purpose of honing your memory of alphabetical order, serves as our gateway into this realm of cryptographic mastery. By engaging in this interactive challenge, you not only sharpen your ability to recall the sequence of letters in the alphabet but also lay the foundation for a deeper understanding of cryptographic principles.

In the world of cybersecurity, where threats loom at every virtual corner, the ability to generate robust passwords swiftly and retain them securely is paramount. Here lies the crux of our discourse – the profound link between memorizing letter positions and the creation of potent passwords.

Consider this: armed with the knowledge of the alphabet's order, you possess the key to construct passwords with unprecedented speed and complexity. Each letter's position becomes a building block in the fortress of your password, fortifying it against malicious intruders seeking to breach your defenses.

Furthermore, mastering the alphabet's sequence empowers you to navigate cryptographic algorithms with finesse, unraveling their intricacies and harnessing their potential to safeguard sensitive data. Whether you're delving into symmetric or asymmetric encryption, your proficiency in alphabet memorization serves as a guiding star illuminating the path to cryptographic excellence.

But let us not forget the practical implications of this endeavor. Beyond the realm of cryptography, the ability to swiftly recall letter positions fosters efficiency in various coding tasks, from array manipulation to string operations. It streamlines your workflow, enhancing productivity and proficiency in diverse programming endeavors.

In essence, Alphabetor transcends the confines of a mere game; it becomes a gateway to unlocking the full spectrum of your cryptographic prowess and coding acumen. As you ascend the ranks of the leaderboard, remember the underlying significance of your quest – to forge stronger passwords, fortify digital defenses, and chart new frontiers in the realm of cybersecurity.

So, fellow developers and cryptography enthusiasts, heed the call of Alphabetor. Let us embrace the challenge, empower ourselves with the knowledge of letter positions, and embark on a journey toward cryptographic excellence. Together, we shall conquer the virtual landscapes, safeguarding our digital realms with passwords forged in the crucible of our mastery.

For those brave souls ready to embark on this noble quest, venture forth to Alphabetor's domain here, and may your endeavors be as legendary as the passwords you forge.

This post is licensed under the MIT license. For more details, refer to the LICENSE file in the Alphabetor repository. 📝🔒🚀

DEV Community: Francesco Bianco

🧠 How to Write Shell Scripts That Access Memory Safely

🛡️ Why local Is Important

🔐 Use local to Contain State

⚠️ But Be Careful How You Use local

🧪 Practical Example

🔚 Final Thoughts

What Would Rust Be Without Cargo? A Beautiful Disaster

Now Think About Shell Scripts

What If Cargo Existed for Shell?

Mush in Action

Why It Matters

Closing Thought

If You Run Your CI Locally, You’ve Already Failed

The Dream Gone Wrong: CI as a Fancy Makefile

The Anti-Pattern: Turning CI into a Dev Loop

CI Failures Are Bugs — Compensatory Bugs

ACT Isn’t the Problem — Misuse Is

So What Should You Do Instead?

Final Thought

Everyone Loves Open Source… Until It's Time to Contribute

🧠 The Hypothesis

📊 The Data Doesn’t Lie

1. A Tiny Core Does the Heavy Lifting

2. Barriers Are Real

3. Recognition Is Rare

🧠 Why This Bias Matters

✅ What Can We Do?

🎯 Final Thoughts

Stop Writing Messy Bash Scripts: Build Real Internal Tools with Mush

The State of Internal Tooling in DevOps

Why Bash Scripts Get Ugly

Meet Mush: Modular Shell Scripting

A Real Example: Hello, Bash Tool

Internal DevOps Tooling with Mush

1. A CLI to Standardize Deployments

2. Kubernetes Wrapper Tool

3. Project Onboarding Tool

Why Mush Matters

Final Thoughts

Try it out

101 Ideas for Smart DevOps Tools 🚀🛠️

🐳 Docker & Container Tools

☸️ Kubernetes Tools

🧪 CI/CD Pipeline Tools

🧑‍💻 Git & GitHub Tools

🧠 Dev Tools

🛠️ System & Infra Tools

🔐 Security Tools

📦 Package & Build Tools

📊 Monitoring & Visualization Tools

🧰 Misc Tools

📣 Join the Hackathon!

💬 Share This With Your Team

🔁 Like. Share. Build.

🌟 Hackathon Tamasha: Where DevOps Meets Creativity! 🚀

🔥 What’s the Challenge?

💡 Example project ideas:

💻 How to Participate

🎉 Why Should You Join?

🌍 Why Indian Developers Should Join

How to Make Conventional Commits a Lasting Habit?

The Problem: Conventional Commits Fade Away Quickly

Meet Convcommit: Your Memory Booster for Commit Messages

How It Works

Why You Should Start Using It Today

Try It Now and Make Your Commits Count!

Stop Bloating Your Containers! Why Your Cron Jobs Don't Belong There 🚀

The Hidden Nightmare Inside Your Containers

Enter javanile/crontab: The Docker Composer's Dream

Why This Will Change Your Container Life Forever

1. Ridiculously Simple Setup

2. Your Containers Stay Pure and Focused

3. Centralized Schedule Management

Real-World Superpowers

The Cherry on Top: Effortless Logging

The Time to Change Is Now

Get Started Today

The Secret Chamber Every Developer Should Have: Unleashing the Power of Side Repositories

What Exactly Is a Side Repository?

🛡️ Why `local` Is Important

🔐 Use `local` to Contain State

⚠️ But Be Careful How You Use `local`