DEV Community: Viorel PETCU

So, I Vibe Coded A Way Out, Again.

Viorel PETCU — Sun, 16 Aug 2026 22:18:46 +0000

A while ago I wrote an article asking When Is 100% Vibe Coding OK?.

My conclusion was that it works when the human already owns the invariants. If you know the problem is solvable, understand the constraints, and have a reliable way to verify the output, AI can be a fantastic accelerator.

Apparently I decided to test that theory again.

This time with my banking app.

If you are savvy enough in the Go ecosystem and you just want to produce QR codes that most banking apps can consume here's the "TL;DR just show me the code" version:

The rest of this article is for those who are interested in how the sausage was made.

The "paper" problem

I live in Germany. Germany loves paper. I don't. Well, I do, but in its original form, as trees 🌳🌳🌳 🌳🌳🌳 🌳🌳🌳

Here, lots of invoices arrive in envelopes. Notices arrive in envelopes. Things that absolutely could have been an email arrive in envelopes, and because I am terrible at filing them, they pile up.

Eventually I perform the ancient German ritual of sitting down next to the pile and dealing with it. This is when the second annoyance begins.

Somewhere on each invoice are the recipient, IBAN, amount and payment reference. I open my banking app and start copying them (nowadays the app can photograph the page and you get a decent prefill - but I still check each field). IBAN, check it. Amount, check it. Reference, check it. Look back at the paper because I no longer trust myself. Check everything again.

There has to be a lazier way.

Wait, isn't this what QR codes are for?

My first thought was extremely sophisticated: Can I somehow shove all of this into a QR code?

Turns out others in Europe had the same idea 14 years ago 😀

There is an EPC QR code standard for SEPA credit transfers, commonly encountered as GiroCode. Underneath the banking terminology is something wonderfully boring (just how I like it): structured text.

Something along these lines:

BCD
002
1
SCT

Example Recipient
DE69670400440672013000
EUR12.34

Invoice 2026-001

Encode a correctly structured EPC payload as a QR code, point a compatible banking app at it, and the payment form gets populated. Recipient, IBAN, amount, reference. Exactly the boring automation I wanted.

- note that you can only transfer a maximum of 999.999.999,99 EUR so if you need to transfer more than a billion you can't use this method.

Linux already had most of my application

I could have started looking for QR libraries. Instead, Linux already had qrencode.

Give it text. Get a QR code.

So the first architecture was basically:

payment fields
    ↓
EPC payload
    ↓
qrencode
    ↓
PNG

This is my favorite kind of software architecture: boring.

The EPC specification defines the payload. qrencode already knows how to make QR codes. Neither problem needed me to invent anything. What I actually needed was some glue around them.

And this is where Codex shines.

Enter Codex

I didn't really want to spend my free time typing GO boilerplate. I knew what I wanted the program to do, I knew the boundaries, and, most importantly, I had an extremely good test oracle sitting in my pocket: my banking app.

To be clear I didn't ask Codex to just "build the thing". I started with the project structure. Once that was good, implement the EPC payload and tests. Good. Add the qrencode boundary. Good. Now generate a self-contained HTML document. Good. Now make the CLI accept a real payment.

Small step -> test -> commit -> iterate.

At some point in this cycle I felt less like someone programming in the traditional sense and more like Tony Stark talking to Jarvis.

"Good. Now throw a database in there."

Except with far less holographic UI and considerably more:

go test ./...
go vet ./...

The database was SQLite, of course, because of the architectural principle mentioned before: pick the most boring thing that solves the problem.

The HTML followed the same philosophy. The QR PNG is embedded directly into the document as Base64 encoded text. One file contains the payment details and its QR code. No server, no framework and no external assets required to display it.

At this point in time the pipeline looked like this:

payment fields
    ↓
EPC payload
    ↓
qrencode
    ↓
PNG
    ↓
self-contained HTML
    ↓
SQLite

Then came the important test.

And then I made a donation with it

Eventually I could run something like:

go run ./cmd/giro create \
  --recipient "Wikimedia e. V." \
  --iban DE09370205000003287300 \
  --amount 6.79 \
  --reference "Via LAZY-EPC over GitHub"

The application validates the payment, creates the EPC payload, asks qrencode for the PNG, embeds it into the HTML document and archives the result in SQLite.

generated ~/Documents/payments/payment-20260816-184212.html
stored payment #7

I opened the generated document, pointed my banking app at the QR code, and everything appeared in the correct fields.

xdg-open ~/Documents/payments/payment-20260816-184212.html

And then, because apparently I have more faith in my software development process than is healthy, I actually made a real transfer with it.

It worked.

That probably should have been the end of the project.

Once I had used it for a real payment, another obvious annoyance appeared. A lot of these payments are similar. Same recipient, same IBAN, perhaps a different amount or reference.

I already had SQLite. Why should I type all of that again?

So the database gained search and notes. Previous payments could become the starting point for new ones. Find the old payment, change what changed, generate another QR.

This solved the data problem, but now I needed some way to browse it and that's when a roughly 30-year-old memory came back.

A Romanian post office, sometime in the late 1990s

I grew up in Romania, and sometime in the 1990s I remember seeing computer terminals at the post office.

I couldn't tell you what computers they were. I don't know what operating system they ran, and I for sure couldn't tell you anything about the software behind them. But I remember the interface.

Those wonderful old forms. Boxes, rows, fields, keyboard navigation. No mouse required. No animation. No hamburger menu. It looked incredibly serious to me as a kid.

It looked like a computer.

Thirty years later, while building software specifically because I don't want to deal with paperwork coming through the post, I realized exactly what interface I wanted.

"A post-office terminal, from the 90s"

Apparently some circles take thirty years to come around.

So I went back to Codex.

"Give it a TUI."

The result looks exactly as dated as I wanted it to.

The SQLite archive becomes a terminal table. I can filter it by recipient, reference, notes or IBAN, navigate through previous payments and press Enter on one.

That opens a form containing the complete payment. Tab through the fields, change the amount or reference, and create a new one.

There are no recurring-payment templates because, after using the application, I realized I didn't actually need them. The database itself is the template system. Search for the last similar payment and clone it.

The notes field is deliberately local metadata. It never enters the EPC payload. It's there so Future Me has some chance of understanding what Past Me was doing.

And yes, the TUI has Create, Update, Delete and Open. Delete asks first, because even my commitment to 1990s user-interface design has limits.

Boring is a feature

There are already plenty of things I could add.

The external qrencode dependency could become a small Go library so the application can eventually be distributed as one binary. The TUI could gain mouse support, more keybindings and other views. Prebuilt packages would make installation less dependent on knowing your way around the Go ecosystem.

I also discovered another rabbit hole that I am deliberately not entering yet: custom URI handlers.

Something like:

lazyepc://payment/...

could eventually let a service hand a payment to the locally installed application through the operating system.

That sounds fun.

Which is precisely why I'm not building it right now.

The current application solves the problem that annoyed me. It generates the QR, remembers previous payments and gets out of the way. Good is better than perfect, and useful software is allowed to stop before it is mirror polished.

So, was this 100% vibe coded?

Pretty much.

Codex wrote essentially all of the implementation. I made the architectural decisions, tested what came back, rejected complexity I didn't want and decided what the next increment should be.

That distinction became particularly obvious when the TUI developed a wonderfully stupid bug: pressing Enter did absolutely nothing.

At first this looked like a terminal focus problem. It wasn't. The callback was firing, but the code had returned a Go slice by value while another closure later reassigned its captured slice. The selection callback was therefore still looking at the original empty state.

AI wrote the bug. I still had to understand why the system couldn't possibly be behaving correctly.

Then Codex fixed it.

That experience reaffirmed my conclusion from the previous article. Vibe coding didn't remove engineering from this project. It removed an extraordinary amount of typing.

And, unexpectedly, sitting.

I'm in my 40s now and I've been typing essentially nonstop since university. My hands occasionally remind me of that. What I didn't expect from working this way was that while Codex was implementing something or running the test suite, I didn't have to sit there staring at it. I could get up, walk around the house, stretch, do something else, then come back and review the result.

I'm not going to pretend that AI-assisted programming is some kind of ergonomic treatment, but reducing the amount of time I spend glued to a keyboard turned out to be a surprisingly nice side effect.

I still decided where the boundaries belonged. I decided that calling qrencode was preferable to adding another abstraction just because it was possible. I decided HTML was enough. I decided SQLite was enough. I decided what needed tests, what constituted success, and when a feature wasn't worth building.

Most importantly, I decided whether I trusted the result.

The invariant was sitting in my pocket

This project had unusually strong invariants.

EPC is a specification. The payload is inspectable text. The QR code is machine-readable. At the end of the chain is an independently developed banking application that parses the result and shows me exactly what payment it thinks I am about to authorize.

Codex could hallucinate an implementation detail. It could choose a bad abstraction. It could misunderstand what I wanted the TUI to do.

But it couldn't negotiate with my banking app.

Either the QR code represented the payment I intended, or it didn't.

That is what I meant when I wrote that the human needs to own the invariants.

This time I just happened to own them while repeatedly saying the software-engineering equivalent of:

"Jarvis, throw in a little hot rod red in there."

The result is lazy-epc, and the code is now public. It's a workable MVP rather than a polished consumer application. If you're reasonably comfortable around Go and Linux, you can build it, use it, break it, or make it better.

For now, it does exactly what I wanted:

Turn annoying payment details into a QR code, remember them for next time, and get out of the way.

When Is 100% Vibe Coding OK ?

Viorel PETCU — Sun, 31 May 2026 22:20:09 +0000

Recently, I lost a lot of time reviewing and would have lost even more implementing, what I can only describe as vibe-written specs.

Requirements that felt coherent while saying almost nothing concrete. The kind of document where every paragraph sounds reasonable until you scratch the surface a bit and realize the thing is not applicable in the existing ecosystem.

To be clear: I am not against vibe coding.

I use it myself all the time.

If I need:

a one-off script,
a throwaway visualization,
a temporary parser,
a document nobody else will maintain,

then speed matters more than rigor.

But maintenance changes the equation completely.

This weekend accidentally gave me a good example of where vibe coding actually shines. During my usual Saturday clean-up, I knocked over one of those wooden cube puzzles:

25 identical pentacubes that are supposed to fill a perfect 5×5×5 cube.

Specifically this one:

I tried reconstructing it manually for a while and failed ( blaming the fact that I was tired and there was heat dome over EUROPE messing with the comfort index 🥵 )

Needless to say this really bugged the engineer in me and on Sunday morning I was ready to throw AI at this. I realized that:

the rules are precise,
the state space is finite,
the problem is absolutely solvable,
and computers are very good at brute force.

So I opened Go and started vibe coding.

The single piece shape is simple:

A planar pentacube of which there are 25 instances.

At first the challenge was not the algorithm. It was the representation or the domain specific language (DSL).

Even explaining the puzzle to ChatGPT took multiple iterations. We had to establish:

coordinate conventions,
slice notation,
legal piece states,
rotation semantics,
and eventually a labeling system for pieces.

Once the model stabilized, the rest followed naturally:

generate transformations,
normalize orientations,
recursively place pieces,
backtrack on collision.

Classic brute force.

I fully expected to need serious optimization eventually:

pruning,
bitboards,
placement precomputation,
maybe even Algorithm X.

But modern hardware is absurdly efficient.

The naive recursive solver found solutions fast enough that optimization stopped being necessary and became optional engineering curiosity instead.

Somewhere in the middle of this, the project accidentally became a generic mono-pentacube solver.


computing unique orientations for default piece...
unique orientations: 24
solution found

z = 0
1 1 1 1 2 
3 1 4 2 2 
3 3 5 6 2 
3 7 8 9 2 
3 8 8 8 8 

z = 1
A B C D E 
A 4 4 4 4 
A A 5 6 6 
A 7 F 9 9 
G H H H H 

z = 2
I B C D E 
I I C D J 
I 5 5 6 J 
I 7 F 9 J 
G 7 F H J 

z = 3
B B C D E 
K K K K E 
L M 5 6 J 
G 7 F 9 N 
G O O O O 

z = 4
L B C D E 
L M K P N 
L M P P N 
L M F P N 
G M O P N

Then I wanted visual output.

So we added OBJ/MTL export and grouped the generated geometry by piece so the solutions could be inspected directly in Blender.

At that point I left the chat entirely, opened Codex, cleaned the implementation up, packaged it properly, and turned it into something reusable for solving this entire family of problems.

Solution	Exploded View

Not bad for roughly two hours of vibe coding.

But I think the important part is this:

My attempt only worked because I already knew the problem itself was solvable.

That certainty let me push through:

incorrect assumptions,
hallucinated constraints,
broken code generation,
malformed OBJ output,
and multiple rounds of ChatGPT confidently misunderstanding the puzzle.

That is where I think vibe coding genuinely works well:

When the human already owns the invariants.

If you know:

the problem is solvable,
the constraints are real,
and the output is verifiable,

then AI becomes an accelerator and vibe coding is 100% OK in my book.

But if the requirements themselves are "vibes", then the system has nothing solid to converge toward.

You do not get speed.

You get, well, nonsense.

PS:

should you knock over your puzzle, or ever need to fill a 5x5x5 cube with a planar pentacube, while also needing to visualise the solution...
I got you: vibe coded go implementation

No One Has This Problem? Just Me? OK.

Viorel PETCU — Sun, 02 Nov 2025 09:51:08 +0000

I think I just solved a problem nobody else cared to fix.

I’ve been using a Mac for years and got used to everything just working the way I like it. But at work, I have to use Windows. Add to that the fact that I live in Germany, so the provided hardware has a QWERTZ layout plus all the umlauts: Ä, Ö, Ü, and the Sharp S or ß. Add to that the fact that I have to write a lot in Romanian, with its own set of diacritics: Ă, Â, Î, Ș, Ț, and you can imagine how messy keyboard shortcuts and special characters can get.

After 12 years of doing this balancing act, as a software developer and technical writer, I finally found a setup that fixes it all. It’s the perfect mix of AutoHotkey and the Logitech MX Keys Mini (German layout), Mac, and PC special keys.

Logitech MX Keys Mini is the best.

Before we go any further, let’s settle one thing. If you don’t think the Logitech MX Keys Mini is the best keyboard out there, you’re wrong. Stop reading, go to a brick-and-mortar store that carries it (all of the technology-oriented ones will have it), and test it. After you inevitably discover this fact, come back and finish the article. I could write an entire fanboy article about this piece of exceptional hardware because it's just that good.

But we are here for a different reason... so let's get back to that.

QWERTZ Isn’t a Problem.

No, wait — one more detour while we’re at it. Yes, I’m using the German layout for programming. I know, I know... everyone thinks their layout is the best. Go ahead, grab your pitchforks, and tell me how I’m “doing it wrong.” But after 22 years of professional coding, I can tell you: it is all in your head! No layout is superior — you build muscle memory and become efficient regardless of character location. So the best layout is the one that makes you fastest and doesn’t give you Carpal Tunnel issues after a day of coding and writing. It just so happens that QWERTZ is more useful for both German and Romanian, and I would also argue for programming in general.

Here are the stats:

Keywords Total	Keywords with Y or Z	"Y"	%-Y	"Z"	%-Z
C (32)	—	0	0%	0	0%
Java (≈67)	`byte`, `finally`, `synchronized`, `try`, `yield`	5	~7.5%	1	~1.5%
Python (35)	`async`, `yield`, `finally`, `try`	4	~11.4%	0	0%
Go (25)	`type`	1	4%	0	0%

OK, now for real — getting back to the topic...

macOS Got It Right

One thing macOS absolutely nailed is how Command + C and Control + C just make sense everywhere. Copy in the terminal? Works. Copy in a GUI? Works. No weird exceptions. On Windows, for the longest time, you had to remember that in the terminal it’s Ctrl + Shift + C — because we all know you don't want to execute Ctrl + C mid-command. It always felt wrong to me. I know Microsoft finally fixed this when text is already selected, but after years of fighting with it, I wanted something better — something that just works all the time and does so regardless of the OS.

Fixing Windows With AutoHotkey

This is where AutoHotkey enters the picture and solves this issue sublimely. This software is the:

VIM of Windows hotkeying.

Insane amounts of possible customization, including interacting/polling with open windows. WikiHow does a great TL;DR setup for getting up and running with AutoHotkey. But the authors also maintain the official documentation, so you can fully take advantage of this unique software and its capabilities.

All right, after all that reading, several rants, and what I think is my longest article yet, here is your reward — enjoy:

; Romanian diacritics layer on German keyboard using Right Ctrl as modifier
; AutoHotkey v2 — Explicit combo version, reliable uppercase handling

#SingleInstance Force
#Requires AutoHotkey v2.0

; --- Lowercase layer ---
>^a::SendText("â")
>^ä::SendText("ă")
>^s::SendText("ș")
>^t::SendText("ț")
>^i::SendText("î")

; --- Uppercase layer (Right Ctrl + Shift + key) ---
>^+a::SendText("Â")
>^+ä::SendText("Ă")
>^+s::SendText("Ș")
>^+t::SendText("Ț")
>^+i::SendText("Î")

; --- ALT(CMD) + C / X / V remaps to COPY / CUT / PASTE system-wide ---
!c::Send("^c")   ; Alt + C → Ctrl + C
!x::Send("^x")   ; Alt + X → Ctrl + X
!v::Send("^v")   ; Alt + V → Ctrl + V
!r::Send("^r")   ; Alt + R → Ctrl + r
!z::Send("^z")   ; Alt + R → Ctrl + z
!+z::Send("^y")   ; Alt + SHIFT + R → Ctrl + y

; --- ALT(CMD) + A / S remaps to SELECT ALL / SAVE system-wide ---
!a::Send("^a")      ; Alt + A → Ctrl + A  (Select All)
!s::Send("^s")      ; Alt + S → Ctrl + S  (Save)
>^q::SendText("@")  ; Right CTRL + q (produce @ )
>^+::SendText("~")  ; Right CTRL + "+" (produce ~ )
>^-::Return         ; Right CTRL + - (do nothing / RETURN)
>^<::SendText("|")  ; Right CTRL + "<" (produce | ) 
>^e::SendText("€")  ; 
>^2::SendText("²")  ; 
>^3::SendText("³")  ; 

; --- CODING NEEDS
>^7::SendText("{")  ; 
>^8::SendText("[")  ; 
>^9::SendText("]")  ; 
>^0::SendText("}")  ; 
>^ß::SendText("\")  ;

Really customizing the MX Keys Mini

Now, if you also happen to be a total NERD and perfectionist, you can really take this all the way up to ELEVEN.

Here's how I customized the crap out of the MX Keys Mini keycaps too. The stock German layout doesn’t show any Romanian letters, obviously, so I added the missing diacritics right onto the keys. It’s a small detail, but it makes the keyboard feel bespoke!

For that, I used a permanent marker that you can find on Amazon (oil- and water-proof and able to adhere to plastic) and a simple template:

TRACE	GUIDE

Final result

So, if you made it all the way here, I am impressed. I really thought this was a niche thing, but apparently, you are also in need of a solution for typing Romanian while using a German layout and also switching between Mac and PC on a daily basis for years. I think this makes you officially my:

BROTHER (or sister) FROM ANOTHER MOTHER

PEACE!

Patreon Doesn’t Show Your Total Spending. So I Did.

Viorel PETCU — Sun, 27 Jul 2025 00:04:36 +0000

I like supporting small creators on Patreon. A few euros here, a few bucks there — no problem. But one day, I looked at my Memberships page and thought:

“Wait… how much is this costing me per year?”

Patreon doesn't tell you.
No total. No filters. No export. No API. It’s like they don’t want you to know.

Here's a Challenge for You

Go to https://patreon.com/settings/memberships and check how much you’re spending yearly on creator support. Go ahead, I’ll wait.

...

Back? Was it easy?

If you only support a couple of people, maybe.
But if you’re like me — supporting multiple creators in different currencies and on different billing periods — it turns into a bit of a chore. Right?

Since I want a clear view of all my subscriptions (and Patreon doesn’t offer it), I had to build it myself.

This is Part 3 in My "Why Doesn’t This Site Show a Total?" Series.

id	name	follow	code
1	Total cost of an Amazon wishlist	article	gist
2	Total time of a YouTube playlist	article	gist
3	Total cost of my Patreon memberships	this one	gist

Each one is a quick userscript using vanilla JavaScript and the User JavaScript and CSS browser extension. Drop the code in, refresh the page, and boom — feature unlocked.

What This One Does

Scans the Patreon Memberships page
Finds prices like $4.99 per month or €50 per year
Groups them by:
- Currency (USD, EUR, etc.)
- Billing cycle (monthly, yearly)
Adds everything up
Shows the result in a popup with:
- Monthly and yearly breakdowns
- A bold total per year, in green for dollars and blue for euros

How It Works

The script waits for the page to load fully, then:

Injects a styled modal
Hooks into the second <h1> on the page and makes it clickable
When clicked, it scrapes all relevant <span> elements
Extracts price, frequency, and currency
Totals everything and shows it in a popup

Before vs. After

Before	After

So there's my answer: 90.24 $ and 252 € per year going to creators I like and like supporting! - less than 1€ per day

Why This Script Exists

I like being generous — but I don’t like being blind.

If a big platform like Patreon hides something as basic as "how much am I spending?", then I’ll just write it myself.

This script gave me back visibility. No tracking, no login, no API — just a plain overview.

No Plugin? No Problem

If you don't like to install extensions (even if these are extremely useful) you still can use this script as such:

Open the browser dev tools → Console tab
Paste the full code and hit Enter
Totals will appear when you click the second <h1> on the page

Or turn it into a bookmarklet if you want a fun little challenge and another alternative to installing extensions.

Enjoy!
Vio, Out!

PDF Scan File Size: What To Do About It.

Viorel PETCU — Sat, 14 Sep 2024 22:25:03 +0000

In today's digital age, we're constantly creating, sharing, and storing documents and media. While the cost of storage has dropped and internet speeds have skyrocketed, there's a hidden cost we often overlook—our environmental impact. A wonderful resource for insights on how our digital activities affect the environment is The Green Web Foundation, particularly their calculators.

The Environmental Cost of Large Files

It might not be immediately obvious, but the size of the files we share and store contributes to global energy consumption. Data centers, which store everything from photos to PDFs, use massive amounts of electricity. Smaller files mean less data transferred, processed, and stored—leading to a direct reduction in energy usage and, ultimately, CO₂ emissions.

The 'Ubuntools' Docker Image

This is where my project, the ubuntools Docker image, comes in handy. Initially created as a basic toolkit for probing APIs and aggregating data, I expanded the project to include tools for compressing PDFs and media files. Why? Because reducing file size doesn’t just save space—it helps reduce the environmental impact of our digital lives.

Why Document and Media Compression Matters

Even though cloud storage seems limitless and fiber internet offers instant downloads, the carbon footprint of transferring large files still matters. Every megabyte of data requires energy to transmit and store. By compressing documents and media, we can make a small but meaningful contribution to minimizing our environmental impact. Here's an example of how I incorporated this idea into ubuntools:

I planned to send an article from a magazine to a contact of mine as an email attachment since there was no online version to simply share the link. So, I fired up my flatbed scanner and scanned the three pages:

To my surprise, for a 300 dpi resolution, the result was a 1.77 MB PDF file. That would not even fit on a standard floppy disk back in the day—unacceptable!

I planned to do some editing of the files anyway, using GIMP (for image corrections, cropping, fine rotation, etc.), so I told myself, "Once the shading is gone and the colors are uniform, the PDF size will surely reduce."

BTW, if you're interested in a tutorial on editing PDFs with GIMP (all free and open source software), leave a comment. If there's enough interest, I'll write up a tutorial on the top 10 things you need and how to accomplish them using GIMP.

But then I got an even bigger surprise. After rotation, color correction, and exporting the layers as pages of the PDF, I felt like this:

Well... 💩 The file was now 11.4 MB—kind of going in the wrong direction!

So, I taught ubuntools some new tricks. Under the pdf-processing tag, you'll find a base Ubuntu Docker image with the following tools:

ghostscript
pdftk-java
poppler-utils

# start ubuntools in the directory where your big PDF file are
docker run -it --rm -v $(pwd):/work --workdir /work viorelpe/ubuntools:pdf-processing /bin/bash

# execute the following command
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=compressed.pdf original.pdf

This command reduces the scanned document's size while maintaining high quality—perfect for email attachments or archiving. How much did it reduce the size? It came down to 0.71 MB, which is a considerable improvement.

Here’s the finished product and the original side-by-side:

Check the difference for yourself on GitHub.

Expanding with Media Compression

From here, it's easy to integrate other media compression utilities, such as FFmpeg, to reduce the size of videos and images. These tools, combined with ubuntools, make it real easy for you, because all you have to do, is to run two commands:

Start ubuntools with the appropriate tools (via tag).

Run a command and feed it your files.

Conclusion: Think Small, Act Big

File size might seem trivial in an era of "unlimited" storage and bandwidth, but it's the small, cumulative actions that matter. Compress your files, shrink your media, and contribute to a greener future.

I Built ubun🔨ools, So You Don’t Have To

Viorel PETCU — Sun, 08 Sep 2024 09:59:21 +0000

Not sure how often this happens to others, but whenever I start a new project, I like to start with a blank slate. I do this to avoid unconsciously dragging in tools or methods from other projects that might not fit into the current tech stack.

So, typically, I check out the project and mount the directory into a fresh Ubuntu container like this:

git clone https://github.com/realvorl/ubuntools.git
cd ubuntools

docker run -it --rm -v $(pwd):/work --workdir /work ubuntu:24.04 /bin/bash

All set, right? Well, not quite. Let’s say I want to check the weather quickly:

root@20fb3c8cf2eb:/work# curl wttr.in
bash: curl: command not found # <--- and this is what I am talking about
root@20fb3c8cf2eb:/work#

I don’t always check the weather, but you get the point. I’ve already set everything up, but now I’m in a container where tools like curl, wget, jq, or even a simple editor like nano are missing. And if the container crashes, whatever I install now is gone. Frustrating, right?

The Solution: Ubun🔨ools

So, I built ubunTools—a lightweight Docker image generator that packages the tools I need in these situations. No more fumbling with missing dependencies or reinstalling them every time. With ubunTools, you pull the image, and boom—you’re ready to go.

Let me show you how this works:

1 add your list of tools to the workflow input form:

2 put that list into an ENV variable:

3 build the parameterized image:

4 push to docker hub:

Here’s the same workflow, but this time using an image generated by ubunTools:

# Swapping ubuntu:24.04 with viorelpe/ubuntools:useful_REST_tools
docker run -it --rm -v $(pwd):/work --workdir /work viorelpe/ubuntools:useful_REST_tools /bin/bash

root@0325311145e2:/work# curl wttr.in
Weather report: 

      \   /     Clear 
       .-.      11 °C          
    ― (   ) ―   ↑ 6 km/h       
       `-’      10 km          
      /   \     0.0 mm          ...
                                ...
┌────────────────────────────── ...
│            Morning            ...
├────────────────────────────── ...
│    \  /       Partly Cloudy   ...
│  _ /"".-.     +22(21) °C      ...
│    \_(   ).   ↖ 5 km/h        ...
│    /(___(__)  10 km           ...
│               0.0 mm | 0%     ...
└────────────────────────────── ...

Easy, right? Now, I’m good to go with all the tools I need.

Principle 1: Adding More Tools Shouldn’t Be Hard

One of my favorite things about ubunTools is how simple it is to expand. Need a new tool for a specific project? No problem! Just name it in the GitHub workflow inputs, trigger it, and the image will automatically update with the new tool(s). Minimal effort, maximum flexibility. It’s like a toolkit that grows with you as your needs evolve.

Principle 2: Keeping It Secure and Up-to-Date

Security matters, especially when dealing with Docker images. That’s why ubunTools includes a mechanism that keeps it in sync with the latest Ubuntu image. If the Ubuntu image changes (like when there’s a security fix), ubunTools rebuilds the image (at midnight) and pushes it to Docker Hub under the appropriate tag - overriding the previous one. You don’t have to worry about manual updates—it keeps everything secure and fresh.

Conclusion: A Toolkit That Works for You

Ubun🔨ools started as a personal solution to a common onboarding headache, and it’s already grown beyond what I imagined. Whether you’re probing APIs, aggregating data, or just needing a basic toolkit, ubunTools has you covered—and it’s easy to build on.

Check out ubunTools on GitHub 🚀. Don’t want to deal with creating your own Docker Hub account? No worries! Just create an issue on GitHub, and I’ll build the image for you. It’s just a few text fields and a click—no biggie.

Final Thoughts

I wanted to make my life easier, and now, with ubunTools, I hope it makes yours easier too. Whether you’re a developer who likes starting projects with a clean slate, or you just need a reliable, customizable toolkit, ubunTools is there for you. Let me know if you give it a spin!

I built a Free Badge Generator for Everyone

Viorel PETCU — Sat, 31 Aug 2024 21:27:02 +0000

It all started with a simple sticker. On a business trip to Hamburg, my colleagues and I came across a promotional sticker from the German county of Baden-Württemberg, which humorously boasted, "nett hier, aber waren Sie schon mal in Baden-Württemberg?" ("Nice here, but have you ever been to Baden-Württemberg?").

Have a look at the promotion if you ever taught about moving to or within Germany, Baden-Württemberg is a great destination.

Since my team is based in Stuttgart, this little joke hit home, and we all had a good laugh. But it also sparked an idea—what if I could create similar badges or "stickers" digitally and easily share them in README files, CI/CD pipelines, or anywhere else they might bring a bit of humor or information?

That idea grew into the Badge Maker Lite, a simple yet powerful tool that anyone can use to create custom badges with personalized text, colors, and layouts.

The Concept: A Tool for Everyone

The Badge Maker Lite is designed to be a free and accessible service. It’s hosted on GitHub Pages, ensuring that anyone can use it without cost or the need for a personal account. The service is straightforward: you customize your badge, preview it in real-time, and get the SVG code to use wherever you need it. The goal was to make it as easy as possible to create these badges, without requiring any complicated setup or installation.

However, for those who want a bit more control, the app has some special features. When run locally with a GitHub Personal Access Token (PAT) that has the appropriate scope, you can save and load your badges using GitHub Gists. This feature adds a layer of persistence to your badges, allowing you to easily share or reuse them later.

My Badge Gallery

the joke	other work link	approved link	nice touch link	future ideas
				...

Special Features: Gists and Short URLs

One of the standout features of the Badge Maker Lite is its ability to save badge configurations as GitHub Gists. This is only enabled when the tool is run locally with a PAT, making it both secure and optional. By saving a badge as a Gist, you receive a unique UUID that you can later use to reload your configuration.

But the fun doesn’t stop there. I’ve also been using Bitly to create short, memorable URLs that link directly to these SVGs. This makes it incredibly easy to embed badges in Markdown documents, project READMEs, or even CI/CD pipeline statuses. Here’s how it works:

Generate Your Badge: Customize your badge using the Badge Maker Lite.
Save It as a Gist: If running locally with a PAT, save the badge and get a UUID.
Create a Bitly Link: Use Bitly to shorten the URL of your public raw SVG hosted on GitHub. Now, you have a neat, memorable URL that can be shared or embedded wherever you like.

This process not only makes it easier to share your badges but also adds a layer of professionalism to your documentation.

A Tech Test for Something Bigger

While the Badge Maker Lite is a fun and useful tool, it’s also a tech test for a larger project I’m planning. This project has allowed me to experiment with different technologies, workflows, and user interactions, all of which will inform the development of my next big idea. Stay tuned for more on that front—exciting things are coming!

Call for Contributions

The Badge Maker Lite is open to contributions, and I’d love to see what the community can bring to the table. While I’m content with the HTML, DIVs, and CSS approach for the UI, I’m fully aware that there’s room for improvement, especially when it comes to responsiveness and modern design. If you have ideas for enhancing the UI, or if you want to contribute new features or improvements, I encourage you to jump in.

I’ve intentionally kept the project open-ended, so there’s plenty of scope for innovation. And if there’s something you’d like to see but don’t have the time or skills to implement, feel free to open an issue. I’ll prioritize the ones that get the most upvotes.

Conclusion

What started as a joke sticker on a business trip has evolved into a fully-fledged tool that anyone can use to create custom SVG badges. Whether you’re adding a bit of humor to your documentation or displaying important status updates in your CI/CD pipelines, the Badge Maker Lite makes it easy and fun.

I’m excited to see how others use this tool and where the community takes it. If you’re interested in trying it out or contributing, check out the GitHub repository. Let’s build something awesome together!

I built a Free Badge Generator for Everyone

Viorel PETCU — Sat, 31 Aug 2024 21:27:01 +0000

Have a look at the promotion if you ever taught about moving to or within Germany, Baden-Württemberg is a great destination.

That idea grew into the SVG Badge Generator, a simple yet powerful tool that anyone can use to create custom badges with personalized text, colors, and layouts.

The Concept: A Tool for Everyone

The SVG Badge Generator is designed to be a free and accessible service. It’s hosted on GitHub Pages, ensuring that anyone can use it without cost or the need for a personal account. The service is straightforward: you customize your badge, preview it in real-time, and get the SVG code to use wherever you need it. The goal was to make it as easy as possible to create these badges, without requiring any complicated setup or installation.

My Badge Gallery

the joke	other work link	approved link	nice touch link	future ideas
				...

Special Features: Gists and Short URLs

One of the standout features of the SVG Badge Generator is its ability to save badge configurations as GitHub Gists. This is only enabled when the tool is run locally with a PAT, making it both secure and optional. By saving a badge as a Gist, you receive a unique UUID that you can later use to reload your configuration.

Generate Your Badge: Customize your badge using the SVG Badge Generator.
Save It as a Gist: If running locally with a PAT, save the badge and get a UUID.
Create a Bitly Link: Use Bitly to shorten the URL of your public raw SVG hosted on GitHub. Now, you have a neat, memorable URL that can be shared or embedded wherever you like.

This process not only makes it easier to share your badges but also adds a layer of professionalism to your documentation.

A Tech Test for Something Bigger

While the SVG Badge Generator is a fun and useful tool, it’s also a tech test for a larger project I’m planning. This project has allowed me to experiment with different technologies, workflows, and user interactions, all of which will inform the development of my next big idea. Stay tuned for more on that front—exciting things are coming!

Call for Contributions

The SVG Badge Generator is open to contributions, and I’d love to see what the community can bring to the table. While I’m content with the HTML, DIVs, and CSS approach for the UI, I’m fully aware that there’s room for improvement, especially when it comes to responsiveness and modern design. If you have ideas for enhancing the UI, or if you want to contribute new features or improvements, I encourage you to jump in.

Conclusion

GitHub Actions for Secret Management

Viorel PETCU — Sun, 10 Mar 2024 12:54:25 +0000

Navigating the complexities of managing projects, especially those inherited with little documentation on API keys and secrets, presents a formidable challenge. My journey began with an urgent need to identify and securely document the secrets dispersed across repositories—a challenge compounded by frequent personnel changes and a lack of previous accountability. To tackle these issues and avert potential downtime risks associated with indiscriminately replacing tokens, I devised two GitHub Actions:

Initially born out of necessity, these tools have evolved to assist developers facing similar challenges more broadly.

Download Secret Text

(Encrypted Documentation & Secure Sharing)

Download Secret Text offers a secure method for encrypting and documenting sensitive information. By using a GPG public key for encryption, it enables the safe sharing of secrets among team members or for archival purposes. This action stands as a testament to the critical importance of maintaining the confidentiality and integrity of project secrets.

Using the action is quite intuitive:

    steps:
    - uses: vosos/download-secret-text@v1
      with:
        gpg_public_key: ${{ vars.GPG_PUBLIC_KEY }}
      # gpg_public_key: ${{ secrets.GPG_PUBLIC_KEY }}
        plain_text: |
            SOME_API_KEY=${{ secrets.SOME_API_KEY }}
            FYE_SECRET_ONE=${{ secrets.FYE_SECRET_ONE }}
            FYE_SECRET_TWO=${{ secrets.FYE_SECRET_TWO }}
            SOME_TOKEN=${{ secrets.SOME_TOKEN }}

such a step in your workflow will produce this kind of result in your run summary:

For setting up a GPG key pair, GitHub's own TUTORIAL provides an excellent starting point. The tutorial walks you through generating the necessary public and private keys—the former for this action and the latter, combined with your passphrase, for decryption.

Mystery Token Explorer

(Shedding Light on the Shadows)

Mystery Token Explorer illuminates the obscured tokens within a project by leveraging the GitHub API to fetch information about their ownership. This insight is invaluable for developers tasked with navigating projects riddled with undocumented secrets. Plans for future enhancements include expanding the use of the GitHub API to uncover additional token details (I'll get around to this soon—meanwhile, contributions via PRs and issues are encouraged).

Using this action is also intuitive:

    - name: Identify GitHub User
      uses: vosos/mystery-token-explorer@v1
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        jq_filter: '{name: .name, login: .login, id: .id}'

such a step in your workflow will produce this kind of result in your run summary:

Bridging GitHub's Secret Management Gap

GitHub's "write-only" policy for secrets safeguards security by preventing direct viewing or retrieval post-addition. Download Secret Text cleverly circumvents this limitation, providing a "read" capability akin to GitLab's more flexible secret management approach. This functionality is particularly beneficial for teams migrating to GitHub or managing projects across different platforms, offering a unified and secure secret management solution.

Expanding Utility Beyond Initial Needs

Though these GitHub Actions were created to ease project transitions, their utility extends into broader contexts:

Streamlining Security Audits & CI/CD Pipelines

Incorporating Mystery Token Explorer into security audits or CI/CD pipelines facilitates the automated identification and cataloging of tokens. Used alongside Download Secret Text, it ensures secure updates to secrets, minimizing exposure risks and maintaining uninterrupted operations.

Advancing Secure Documentation Practices

Download Secret Text is invaluable for teams committed to securely documenting their infrastructure, ensuring sensitive details remain accessible only to those authorized.

In Closing

Inheriting projects laden with undocumented secrets need not be overwhelming. Mystery Token Explorer and Download Secret Text equip developers with robust tools for discovering, understanding, and securely managing digital secrets. These GitHub Actions smooth project transitions and bolster security and operational efficiency, demonstrating a proactive secret management strategy that maximizes GitHub's strengths while mitigating its constraints. As these tools progress, they highlight the potential for community-driven enhancements to forge more secure and efficient development workflows.

A Zero-Cost Monitoring Solution

Viorel PETCU — Tue, 26 Dec 2023 23:31:58 +0000

Introduction

In the data-driven domain of content creation, having a real-time pulse on audience engagement is invaluable. My quest was to construct a tool that epitomizes both efficiency and elegance—a solution where a simple URL would serve as a portal to the metrics of my Dev.to articles.

The Challenge

Manual monitoring was out of the question. The goal was to create an automated system that provides live updates on comments and reactions without the hassle of repeatedly checking each article. And importantly, this system had to be cost-free.

The Solution

My resolution took the form of a memorable URL: bit.ly/dev-mon, a nod to both its daemon-like operation and ease of recall. The choice of hosting fell on the sturdy shoulders of GitHub Pages, a free platform that became the stage for my engagement dashboard.

TL;DR: Quick Start Guide

Eager to see a dashboard like this?

Follow these steps:

Clone the Repository: Visit InteractoGraph and clone the repo.
Customize for Your Profile: Navigate to ./cypress/e2e/0-mine/all_in_one.cy.js#L4 in your cloned repo and replace realvorl in https://dev.to/realvorl with your DEV.TO username.
Commit and Push: Commit the changes with a message like "Update username in Cypress test" and push to main.

Voilà! Post workflow, visit:

https://<YOUR-GITHUB-USERNAME>.github.io/InteractoGraph/

for your very own engagement dashboard. Of course, you can now extend it to include anything that you can think of and are able to scrape using the Cypress API.

For a deeper understanding of the setup, let's dive into the subsequent sections.

Automating Data Collection with Cypress

The Cypress test below scrapes engagement data from my Dev.to profile, illustrating the ease of automation:

describe('Article Metrics on dev.to', () => {
  it('captures comments and reactions for multiple articles', () => {
    // Visit the user's main page
    cy.visit('https://dev.to/realvorl');

    // Define an array to hold our article metrics
    let articleMetrics = [];

    // Wait for the articles to load
    cy.get('.crayons-story__body').each(($body, index, $bodies) => {
      // Extract the article title, comments, and reactions
      const title = $body[0].getElementsByTagName('h2')[0].textContent.trim();
      const links = $body[0].getElementsByTagName('a');
      const reactionsCount = links[links.length - 2].innerText.trim();
      const commentsCount = links[links.length - 1].innerText.trim();

      // Add the metrics to our array
      articleMetrics.push({
        title,
        'commentNo': parseInt(commentsCount, 10) || 0,
        'reactionNo': parseInt(reactionsCount, 10) || 0
      });

      // After the last article, write the metrics to a JSON file
      if (index === $bodies.length - 1) {
        cy.writeFile('./cypress/e2e/0-mine/data.json', {
          'dateISO': new Date().toISOString(),
          'articles': articleMetrics
        }, { flag: 'w+' });
      }
    });
  });
});

It captures titles, comments, and reactions and consolidates them into a JSON file, timestamped for traceability.

Integrating Data with Visualization

Using a Node.js script, updateHtml.js, the data from Cypress is dynamically injected into a Google Chart within an HTML template, chart.tmpl.

const fs = require('fs');

const tmplFilePath = 'chart.tmpl'; // Template file path
const htmlFilePath = 'index.html'; // The final HTML file path
const jsonFilePath = 'data.json';  // The JSON data file path

// Read the template HTML content and the JSON data
const htmlContent = fs.readFileSync(tmplFilePath, 'utf8');
const jsonData = fs.readFileSync(jsonFilePath, 'utf8');

// Replace the placeholder in the template with the actual JSON data
const updatedHtmlContent = htmlContent.replace('// JSON_PLACEHOLDER',
`var json = ${jsonData}`);

// Write the updated HTML content to the final file
fs.writeFileSync(htmlFilePath, updatedHtmlContent);

This transforms the JSON data into an interactive chart, ready for publishing.

Continuous Integration and Deployment with GitHub Actions

The workflow I've established with GitHub Actions automates data scraping, chart updating, and deployment to GitHub Pages. Here's the workflow:

name: CI
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
  workflow_dispatch:
  schedule:
    # Runs at minute 0 past every 6th hour
    - cron: '0 */6 * * *'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Install and Run Cypress
        run: | 
          # Set up Git credentials
          git config --global user.email "6973263+realvorl@users.noreply.github.com"
          git config --global user.name "(Vorl)-Bot"
          # Install dependencies and run tests
          yarn 
          yarn cy-all
          # Commit and push the results
          git add .
          git commit -am "chore (ci): update e2e test results $(date +%s)"
          git push
          # Branching strategy for GitHub Pages
          git checkout -b gh-pages
          git push --set-upstream origin gh-pages --force

      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_branch: gh-pages
          publish_dir: ./cypress/e2e/0-mine

      - name: Upload a Build Artifact
        uses: actions/upload-artifact@v4.0.0
        with:
          name: chart
          path: ./cypress/e2e/0-mine/index.html
          retention-days: 14

The branching strategy for GitHub Pages involves force-pushing to a gh-pages branch, using the peaceiris/actions-gh-pages action to deploy the updated chart, and uploading the chart as a build artifact for quick access.

The first unintended consequence, but actually my favorite feature of this implementation, is the diff that you can get when you look at the git history:

You can just click on the parent link and you can navigate, in this view, through the history of the changes.

Another unintended feature is the possibility to declutter the notifications on your phone. Because this can be used for virtually anything that you want to monitor, you can disable the annoying push notifications, and just do an hourly / daily digest of the engagement you get online.

Conclusion

This automated system scrapes new data and refreshes the dashboard every 6 hours, eliminating manual effort and providing a continuously updated view of article engagement. Of course, it is not limited to DEV.TO, basically anything that you are interested in (LinkedIn), you can set up a Cypress Test, enrich the JSON with that information and follow the pattern laid out in this article.

The "Censorship Brush" - GIMP enabled Invoice Redaction

Viorel PETCU — Wed, 20 Dec 2023 17:59:38 +0000

Introduction: A Holiday Challenge Turned Innovation

This holiday season brought more than just cheer to my doorstep; it brought a mountain of delivery invoices. As I sorted through this paper avalanche, I realized that I needed to redact some sensitive information before recycling. But there was a catch – my trusty redaction roller had run out of ink. "No problem," I thought, and hopped online to order a replacement. However, the estimated delivery time was way past the city's pre-Christmas recycling pickup schedule.

In a moment of what I thought was brilliance, I decided to use my printer. Why not print something over the sensitive parts? And what better than the seemingly endless digits of Pi? After all, 6766 decimal places of Pi on an invoice seemed like a foolproof plan. It was a joyous moment of geeky triumph until I proudly presented my creation to my wife. She was less than impressed. "Isn't that a bit... wasteful?" she pointed out, both in terms of toner and recycling efficiency.

Her comment got me thinking. There had to be a smarter way to do this, a way that was economical yet effective. Because this is a lot of toner that you just waste, when in fact you only want a few lines or sections redacted

Then it hit me – GIMP, the versatile image manipulation program, had all the tools I needed. I recalled a YouTube video about creating custom brushes in GIMP. With a spark of inspiration, I scanned an old, redacted page to capture the pattern left by the roller. From there, it was a matter of putting those GIMP skills to work and crafting a custom censorship brush.

What followed was an interesting journey of digital DIY and a testament to the power of open-source software. In this article, I'll guide you through the steps to create your own censorship brush in GIMP, turning a simple software tool into a powerful ally for maintaining your privacy.

Getting Started: GIMP Setup and Initial Preparations

⚠️ Disclaimer ⚠️ While this method has worked well for me, please be aware that using crumpled or improperly aligned invoices in your printer could cause damage. I share my experience for informational purposes and cannot guarantee the same results for everyone. Always use caution and at your own risk.

First things first, you will need GIMP, a scanner, or a very good lighting setup for your smartphone. I used my Brother DCP-1610 wireless printer and scanner.

The only other thing you will need is an image of random letters (here you can customize to your liking)

For example:



KVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQ
VAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQK
AMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKV
MQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVA
QKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAM
KVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQKVAMQ

OR:



REDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDRE
EREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDR
TEREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTED
CTEREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACTE
ACTEREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDACT
DACTEREDACTEDREDACTEDREDACTEDREDACTEDREDACTEDREDAC

This you can screenshot for later use in the creation of the censorship brush.

Creating the Tool: Crafting a Custom Censorship Brush in GIMP

For anything, you might ever need to implement using GIMP, there is no better resource than Logos by Nick on YouTube.

The following is the exact tutorial I used to implement the brush

Towards the end of the tutorial, you are shown how to install the brush, but Nick is using Windows, if you are on Linux (like me) you would need to install the new brush at a location similar to:

/usr/share/gimp/2.0/brushes

The Redaction Process: Preparing and Censoring Your Invoice

Now that your GIMP has a new superpower, you are only a couple of steps away from perfectly censoring any invoice that is compatible with your printer!

Now you can scan the invoice(s) and get to work.

Step 1: Scan the invoice

This step is self-explanatory.

Step 2: Mark the places you want to redact

Start by adding a new layer fill it with white and reduce the opacity to 50%

Make sure the new top layer is selected, choose the rectangle select tool, and, with the shift key pressed start selecting areas you would like to redact.

Now that you have multiple areas selected, you can choose your new censorship brush, select the appropriate size and start stamping (do not click and drag) click, reposition and click again.

When all is done, you will end up with something like this

Step 3: The Finish

All that is now left to do is to delete the invoice layer and restore the opacity to 100% for the redaction layer.

Now put the invoice in your printer on top of your paper stack (facing the right way) and PRINT, make sure to Ignore Page Margins

Congratulations 🎉 you have now perfectly censored an invoice, so you can throw it in the recycle bin free of any remorse, both from a privacy point of view and also for the amount of wasteful toner.

Conclusion: Towards a More Automated and Efficient Future

As we've seen, GIMP is not just an image manipulation tool; it's also a powerful ally in maintaining privacy and reducing waste. This DIY approach to invoice censorship showcases the versatility and potential of open-source software in everyday tasks.

Looking ahead, there are exciting possibilities to further streamline and automate this process. Imagine leveraging GIMP's API to integrate with an automated system that detects and redacts sensitive information on invoices. This could be integrated with hardware solutions, enabling a seamless scan, censor, and print workflow.

I'm also considering creating a repository of censorship masks tailored for different types of invoices, making it even easier for others to adopt this method without starting from scratch.

WOW you are still reading !?

👀

Respect!

Did this guide help you create your own censorship brush in GIMP? Do you have other innovative ideas for hacking one thing to do another unintended thing? Share your thoughts, experiences, or any questions in the comments below.

🌱 Introducing the Climate Positive Public License! 🌱

Viorel PETCU — Mon, 16 Oct 2023 23:09:52 +0000

Hello everyone out there using open-source licenses,

I'm working on a new kind of license I'd like to present: the Climate Positive Public License (CPPL). It's still in its early stages, much like the weather outside, unpredictable and ever-changing. However, I believe it holds a lot of promise.

Why another license, you might ask? Well, the goal isn't just to create software, but to do so with a climate-positive footprint. The CPPL is designed to promote climate-friendly software practices, CO2 neutrality, carbon capturing, and more. It's an endeavor that's not just for me; it's for our planet.

The license is very much influenced by the GPL, and the core idea is simple:

Use this license for your software, and in return, make sure your software or project actively contributes to the betterment of the environment.

If not, support the cause in another manner, through environmental funds or other means.

In essence, it's a license with a conscience.

I won't claim the CPPL to be the solution to all our environmental concerns. I'm not even sure if it will gain traction, but I'm hopeful. What I do know is that it's another tool in the toolbox for developers who are conscious about the environment and wish to make a positive impact through their work.

I'd appreciate any feedback, ideas, or contributions. The project is open-source and is very much a collaborative effort. If you're curious or want to contribute, the repo is available on GitHub.

Would love to hear what you think!

Maybe take a look on GitHub.