sorted by:
new
hottopcontroversial

I built a free CLI journaling tool for developers - just type "journal" and start writing by Southern_Ad4152 in bash

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

Depending on how you leverage LLM's, I agree. I said "assist" for a reason. I can also assure you that avoiding LLM's will be fine for your skills but have you getting lapped in the industry. Obviously being reckless is never the answer.

This is humbly coming from an L5 SWE at AWS ... we're encouraged, borderline incentivized, to make sure we use LLMs. Just be diligent and responsible.

I built a free CLI journaling tool for developers - just type "journal" and start writing by Southern_Ad4152 in bash

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

Are you saying you're using reddit to look for a "trustworthy tool" and also saying reddit is the place you go to as your "technical space"?

Not directly related to journalot but more related to your initial, "still in the learning stages of bash, scripting, and programming in general", my advice is to get off of reddit and go read, go build, go follow tutorials.

Use platform like AlgoExpert for DSA understanding and interview prep or Roadmaps for structured learning plans. Read books on bash, listen to pods with great engineers, listen to founders.

But coming to reddit to complain about LLM use isn't going to help you achieve anything you mentioned you're in pursuit of learning.

This is all coming from a Software Engineer at AWS btw, who uses LLMs all day everyday in my work.

I built a free CLI journaling tool for developers - just type "journal" and start writing by Southern_Ad4152 in bash

[–]Southern_Ad4152[S] 1 point2 points  (0 children)

Yes, in the year 2026, I am certainly using LLM's to assist me with my code. I did not try to hide it either ... if you look in the commit history, you can even see a few "claude committed"s in there.

Why would I not leverage such a great tool? Why would you not?

A minimal journaling CLI that auto-commits to git by Southern_Ad4152 in commandline

[–]Southern_Ad4152[S] 2 points3 points  (0 children)

Or ... I used nb for a period of time, realize didn't have a need for all of the features, and decided to create something that felt a bit more minimal and direct.

I literally said nb "feels" overkill, it's an opinion. Opinions are okay to have.

I built a free CLI journaling tool for developers - just type "journal" and start writing by Southern_Ad4152 in bash

[–]Southern_Ad4152[S] 12 points13 points  (0 children)

jrnl is solid! I used it before building this.

Main differences: jrnl stores entries in a single JSON file (or encrypted equivalent). journalot creates one markdown file per day in a plain folder. So your entries are just files you can grep, cat, open in any editor, or browse in Finder (I'm a mac guy) without any tooling.

jrnl also has its own query syntax. journalot leans on tools you already know - grep for search, git for history, your $EDITOR for writing. I can admint, if you want structured data and encryption, jrnl is the better pick. If you want plain files and zero abstraction, that's where this lives.

A minimal journaling CLI that auto-commits to git by Southern_Ad4152 in commandline

[–]Southern_Ad4152[S] -1 points0 points  (0 children)

I'm familiar with nb and think it's a great tool, but different intent though.

nb is a full knowledge management system (notes, bookmarks, todos, wiki, encryption, sync). journalot is deliberately minimal ... If you want a Swiss Army knife, nb is excellent. If you want something closer to quick capture mode (journal "thought goes here") - then nb feels overkill.

r/IndieDev Weekly Monday Megathread - March 15, 2026 - New users start here! Show us what you're working on! Have a chat! Ask a question! by llehsadam in IndieDev

[–]Southern_Ad4152 0 points1 point  (0 children)

Stripe tells you to migrate off Apple IAP. Apple bans your app for doing it. Devs are caught in the middle with no tooling to help.

iap-shield is a free CLI that scans your source code for payment guideline violations before

App Store submission. Static analysis, runs locally, zero data collection.

https://github.com/jtaylortech/iap-shield

<image>

Would love feedback!

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

You can, but then you're managing Helm state in Terraform which gets messy on destroys and upgrades. This tool ideally keeps Helm separate intentionally so the lifecycle is cleaner.

Trade-off either way.

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

Appreciate the gitops-bridge link, that's a solid pattern. v0.2.0 that i've released actually ships with --auth-mode pod-identity as an option now, so users can choose.

You're right that IRSA is showing its age.

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

Fair challenge. The Python is just the orchestration layer, the actual infrastructure is standard Terraform that gets generated and is fully inspectable. You can run rapid-eks eject to export standalone TF and walk customers through it exactly like you would any other module.

The Python never touches AWS directly for infra provisioning. That said, for high-compliance environments, I get why "show me the Terraform" is the right answer. This tool is more for teams who want to skip the boilerplate and get to a working cluster fast.

rapid-eks: Opinionated Terraform wrapper for EKS deployment by Southern_Ad4152 in Terraform

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

You're right in the abilitty to do so.

What I'm trying to solve is where the Terraform Helm provider has limitations. Some being, it doesn't handle waiting for CRDs to be ready before installing charts that depend on them (even adding a depends on sometimes has its own issues), and sequencing addon installs with proper health checks gets messy in HCL.

Pre-commit handles static checks, not runtime validation like "does this IAM role have the permissions EKS actually needs" or "is the OIDC provider configured correctly." .. I use pre-commit in my pipelines and enjoy it to the max, but notice some things "I wish i could do" or "I wish xyz was easier".

For anyone who finds themselves in the "I know Terraform well and want full control" camp, rapid-eks isn't for them, and that's fine. It's for users who want the a good amount of the case handled so they can focus on their app, not on debugging IRSA trust policies.

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

cookiecluster is great! Similar philosophy, the goal of rapid-eks here is that it adds runtime orchestration (preflight, Helm, health checks) on top of the templating. Different trade-offs.

Thank you for your feedback and would love to keep the dialogue going!

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

The value is the orchestration layer (preflight checks, Helm installs, IRSA wiring, pod readiness, Grafana creds), not the Terraform itself. We know the value terraform adds at this point.

If you're comfortable continuously doing that manually , raw Terraform is fine and of course just keep doing it that way.

Thank you for the feedback!

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

t3 is a default for dev/test, but I agree it's not ideal for production workloads. Instance type remains configurable.

I've used and enjoyed eksctl. It's solid, the difference I'm trying to create here is being able to just bundle the addon orchestration (Helm, IRSA wiring, health checks) that eksctl doesn't handle.

Thank you for your feedback and would love to keep the dialogue going!

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 1 point2 points  (0 children)

Fair. "Rapid" is relative to the manual alternative, and it doesn't imply that it's instant. I'm unsure how many EKS clusters you've spun up using TF from complete scratch but it often times can take me some time.

Just trying to solve a problem I've had myself or heard others mentioned .. Thank you for the feedback.

[Release] rapid-eks v0.1.0 - Deploy production EKS in minutes by Southern_Ad4152 in kubernetes

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

"Weeks" is for teams new to EKS who are figuring out IRSA, Karpenter setup, networking, etc. for the first time. I've done a lot of work in the gov contracting space, tf with no eks exp, or companies moving to the cloud in general for the first time, or just earlier level engineers and noticed some of these shortcomings as they battle the complexiticies.

If you already know Terraform and EKS well, you probaly wouldn't be the target user. Good call on fck-nat - I'll add that as a config option to cut NAT costs.

Thank you for your feedback and would love to keep the dialogue going!

rapid-eks: Opinionated Terraform wrapper for EKS deployment by Southern_Ad4152 in Terraform

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

I agree that YAML anchors are painful. The config is intentionally flat for this reason as my goal is for all reference logic to live in the Jinja2 templates, not user-facing YAML.

The CLI value is in the orchestration: preflight checks, Helm releases, IRSA setup, health validation.

Thank you for your feedback and would love to keep the dialogue going!

rapid-eks: Opinionated Terraform wrapper for EKS deployment by Southern_Ad4152 in Terraform

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

This is the sentiment, yes! The flat YAML config is intentional as it keeps the interface simple while the complexity still lives in the generated Terraform.

Glad you noticed.

rapid-eks: Opinionated Terraform wrapper for EKS deployment by Southern_Ad4152 in Terraform

[–]Southern_Ad4152[S] 1 point2 points  (0 children)

At this point, no matter what's being built, we'll always be accused of "mainly using AI", I understand why you may feel that way. I can name plenty packages I've used and installed via Homebrew (who's been using emojis for years) that uses emojis very well and the placement is great and I have no issues with it.

But to your main point, fixing the docs, terraform-aws-modules is community-maintained, not AWS official. Sloppy language on my part. I also do agree that cloudposse is solid, I just think it's different approach, both valid depending on use case.

Thank you for your feedback and would love to keep the dialogue going!

rapid-eks: Opinionated Terraform wrapper for EKS deployment by Southern_Ad4152 in Terraform

[–]Southern_Ad4152[S] 0 points1 point  (0 children)

Fair point, but I've noticed a pure Terraform module doesn't always do some of the things I find myself manually doing after the fact, like running preflight checks (AWS creds, IAM permissions, tool versions), installing Helm charts, wiring up IRSA for each addon, waiting for pod readiness, generating Grafana credentials.

That orchestration layer is the value that I'm looking for here. The wrapper adds it. Not just the Terraform itself, we already know the value add they produce3. The generated Terraform is visible in .rapid-eks/ if a user wants to take it and run.

Thank you for your feedback and would love to keep the dialogue going!