Makefile is made up of recipes. Running a recipe in make, prints the recipe and also the output of every command in the recipe. Recipe can be implemented by re-directing the output to /dev/null device. But this approach has a problem. Sometimes, I wanted to read the output of the command and not be re-directed to /dev/null, especially during troubleshooting. In this situation, there is no other way but to change implementation of recipe to remove the redirection.

Makefile has a switch -s to silence the printing of the recipe during execution. I wanted to use this switch to decide for redirection.

ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
  .REDIRECT = >/dev/null 2>&1
else
  .REDIRECT =
endif

test:
    which scala $(.REDIRECT) || printf "scala is not present."

Now, make test prints the recipe and output of the which command. But make test -s completely silences the recipe execution.

Makefile provides a way to silence the echoing of recipes but the implementation of recipe, as in this case, uses conditional redirection to silence the output of commands in the recipe.

This approach, now, becomes less noisy until recipe requires to be debugged.

If you’ve worked on more than one AWS project with Terraform, you’ve probably hit this wall: what starts as a clean main.tf slowly turns into hundreds of lines of spaghetti — mixing networking, IAM, compute, and databases in one place.
I’ve seen this pattern repeated across multiple teams. The fix isn’t working harder — it’s structuring your modules the right way from day one.
In this article, I’ll walk you through the exact Terraform module structure I use for every AWS project, why each decision was made, and the mistakes it prevents.

Why module structure matters more than you think
Terraform is infrastructure-as-code, which means all the same software engineering principles apply: separation of concerns, reusability, and avoiding duplication. A poor module structure leads to:

State file conflicts when multiple engineers work simultaneously
Inability to reuse code across environments (dev/staging/prod)
Blast radius issues — a change in one area accidentally destroying another
Slow terraform plan times because everything lives in one giant state

Real example: At a previous project, a single monolithic main.tf file had grown to 2,400 lines. A junior engineer changed a security group rule and accidentally modified an RDS parameter group in the same apply. Good module structure would have isolated these completely.

The folder structure
Here’s the top-level layout I start every project with:

project-infra/
├── environments/
│ ├── dev/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── terraform.tfvars
│ ├── staging/
│ └── prod/
├── modules/
│ ├── networking/
│ ├── eks/
│ ├── rds/
│ ├── iam/
│ └── s3/
└── global/
├── backend.tf
└── providers.tf

Each folder under modules/ is self-contained — it has its own main.tf, variables.tf, and outputs.tf. Nothing leaks between modules except through explicit outputs and inputs.

Breaking it down: the networking module
The networking module is always the foundation — every other module depends on it. Here’s what mine looks like:

hclmodule “networking” {
source = “../../modules/networking”

vpc_cidr = var.vpc_cidr
public_subnet_cidrs = var.public_subnet_cidrs
private_subnet_cidrs = var.private_subnet_cidrs
availability_zones = var.availability_zones
environment = var.environment
}

Inside modules/networking/outputs.tf, I export the VPC ID, subnet IDs, and route table IDs. Every other module consumes these outputs — nobody hardcodes subnet IDs.

hcloutput “vpc_id” {
description = “The ID of the VPC”
value = aws_vpc.main.id
}

output “private_subnet_ids” {
description = “List of private subnet IDs”
value = aws_subnet.private[*].id
}

Environment-specific configuration
Each environment folder (dev/, staging/, prod/) contains only the configuration that differs per environment. The actual infrastructure logic lives in the shared modules.

hcl# environments/prod/terraform.tfvars

environment = “prod”
vpc_cidr = “10.0.0.0/16”
public_subnet_cidrs = [“10.0.1.0/24”, “10.0.2.0/24”]
private_subnet_cidrs = [“10.0.10.0/24”, “10.0.20.0/24”]
eks_node_count = 5
eks_instance_type = “m5.xlarge”
db_instance_class = “db.r5.large”

For dev, the same variables get smaller values — but the same module code runs. This is where you get real reusability.

Remote state and the backend
Each environment gets its own S3 backend with a DynamoDB lock table. This is non-negotiable on a team:

hclterraform {
backend “s3” {
bucket = “mycompany-tf-state”
key = “prod/terraform.tfstate”
region = “us-east-1”
dynamodb_table = “terraform-lock”
encrypt = true
}
}

Tip: Use a separate AWS account (or at minimum a separate S3 bucket with strict IAM policies) for storing state files. State files contain sensitive data including database passwords and resource IDs.

Three rules I never break

1. Modules never call other modules directly. Only the environment-level main.tf calls modules. This prevents circular dependencies and keeps the dependency graph flat and readable.
2. No hardcoded values inside modules. Every value that could differ between environments must be a variable with a description and type constraint. If I’m tempted to hardcode something, that’s a signal it belongs in tfvars.
3. Every output has a description. Outputs without descriptions are useless to future you and your teammates. A one-line description of what the output is and when to use it saves hours of confusion.

Putting it together
This structure has served me across projects ranging from simple 3-tier web apps to multi-account EKS platforms. The upfront investment in structure pays back within weeks — especially when onboarding new engineers or debugging a production incident at 2am.
Start with this layout even for small projects. It costs almost nothing extra and eliminates an entire class of infrastructure bugs before they happen.

In the next article, I’ll go deeper into the EKS module specifically — how I configure node groups, IRSA roles, and the Helm chart integration that makes it production-ready from day one.

We’ve all been there.

You need to quickly compress an image. You Google “free image tool”, land on iLoveIMG, upload your file — and boom.

“Sign up to continue.”

You just wanted to resize a photo. Not create another account you’ll forget about in 3 days.

So after hitting this wall one too many times during a side project, I did what any developer does.

I built my own. 🛠️

Introducing ihateimg.in

ihateimg.in — a completely free image toolkit. No account. No ads. No “upgrade to pro” popup appearing right when you need it most.

Just open the site and get things done.

What it does

The part I’m most proud of — Pipelines ⚡

Most tools make you do this:

Upload → Edit → Download → Re-upload → Edit again → Download → Repeat 😤

With ihateimg.in, you can chain multiple edits into a single pipeline.

Compress + Resize + Watermark — all in one go. Upload once, get your final result. Done.

This alone saves me several minutes every single time I work with images.

How it stacks up against iLoveIMG

iLoveIMG is a solid product — but it’s built around converting free users into paying ones. Nothing wrong with that as a business, but it’s not what I wanted as a user.

ihateimg.in is built around getting out of your way.

The honest backstory

I needed a quick image tool for a side project. Every popular option either had ads, required signup, or locked the exact feature I needed behind a paywall.

So I spent a weekend building something I actually wanted to use.

It’s been live for a while now. I’ve been quietly adding features and fixing bugs. Today felt like the right time to finally share it with the dev community and get real feedback.

Try it out

👉 ihateimg.in

I’d genuinely love to know:

• What’s missing?
• What would make this a tool you actually reach for?
• Any bugs or rough edges you hit?

Drop a comment — I read every single one. 🙏

Lets understand roles and permissions with a few practical questions.

QN 1: Create a login role that can only read from film table

CREATE ROLE report_user LOGIN;
GRANT SELECT ON film TO report_user;

we create a user called report_user and give it only SELECT permission on the film table. So it can read data but cant modify anything.

2: Accessing customer table gives permission denied fix it

GRANT SELECT ON customer TO report_user;

The error happens because report_user doesnt have access to the customer table. Granting SELECT fixes the issue.

3: Allow access to only specific columns

REVOKE SELECT ON customer FROM report_user;
GRANT SELECT (customer_id, first_name, last_name) ON customer TO report_user;

we remove full access.
Then we grant access only to selected columns. Now the user can’t see sensitive fields like email or other data.

4: Create a support user with limited permissions

CREATE ROLE support_user LOGIN;
GRANT SELECT ON customer TO support_user;
GRANT UPDATE (email) ON customer TO support_user;

This user can: Read all customer data update only the email column no delete or full update access is given tight control.

5: Remove access from film table

REVOKE SELECT ON film FROM report_user;

This simply removes the permission we granted earlier.

6: Create a read-only group

CREATE ROLE readonly_group;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_group;

This creates a group role that can read all tables in the schema.

7: Add users to the group

CREATE ROLE analyst1 LOGIN;
CREATE ROLE analyst2 LOGIN;
GRANT readonly_group TO analyst1;
GRANT readonly_group TO analyst2;

Both users inherit permissions from the group so instead of managing permissions individually we manage them centrally.

Disclaimer: This article is for educational purposes only. It does not constitute financial advice. Always do your own research and comply with your local regulations before trading.

Crypto signal services charge $40-55/month. You open Telegram, get a daily “BUY” or “SELL”, and hope for the best. Ask them how the signal is generated? Silence. Ask to see the backtest data? Nothing.

I was already running a trading bot. Python, ccxt, the usual stack. One day I looked at the signals my bot was producing and thought — wait, this is a signal service. I just wasn’t sending it anywhere.

So I wired it up to Telegram. Total cost: $0. Win rate: 35%. And it’s profitable.

Here’s how.

Why I Built This

I started with a simple EMA crossover bot trading BTC/USDT on Bitget. $33 starting capital. It worked, but I wanted to know if there was something better.

So I built a backtesting engine and ran 50 strategies against 37 months of BTC/USDT daily data (Jan 2023 – Feb 2026). Every single result — Sharpe ratio, max drawdown, win rate, trade count — is public on GitHub. No cherry-picking.

The top 3 strategies became my signal sources:

Each strategy independently generates BUY/SELL/HOLD. When 2 out of 3 agree, that becomes the consensus signal. Simple majority vote.

This is where it clicked. The paid signal services? They’re doing the same thing — pulling data from an exchange, running it through some strategy, and pushing the result to Telegram. There’s no secret sauce. The difference is whether you can see what’s inside.

I wanted to see what’s inside. So I built my own.

Architecture

The whole system runs on a daily cron job. No cloud, no Docker, just a Python script.

cron (daily, 00:15 UTC)
  │
  ▼
Bitget API → fetch OHLCV data (via ccxt)
  │
  ▼
3 strategies analyze independently
  │
  ▼
Majority vote → BUY / SELL / HOLD
  │
  ▼
Telegram Bot API → push to channel

The signal module lives in src/signal/ with a clean separation:

src/signal/
├── config.py       # Environment config (frozen dataclass)
├── generator.py    # Runs all 3 strategies, produces consensus
├── formatter.py    # Formats messages (free vs premium)
├── sender.py       # Sends to Telegram (async, retries, dry_run)
├── notifier.py     # Orchestrates the flow
└── main.py         # Entry point for cron

The free channel gets the consensus signal. The premium channel gets the full breakdown — individual strategy outputs, indicator values, circuit breaker status.

Free channel output:

🟢 BTC/USDT Signal
Consensus: BUY
Price: $96,543

Full strategy breakdown → Premium channel

Premium channel output:

🟢 BTC/USDT Signal Alert
Consensus: BUY (2/3 strategies agree)
Price: $96,543.21

Strategy Breakdown:
  🟢 EMA Crossover: BUY
     EMA(12)=96800 / EMA(26)=96200
  🟢 MACD: BUY
     MACD=245 Signal=180
  🟡 Parabolic SAR: HOLD
     SAR=95100 trend=UP

CB Status: NORMAL
Time: 2026-03-28 00:15 UTC

The SignalGenerator class handles the consensus logic:

def generate(self, ohlcv: pd.DataFrame) -> AggregatedSignal:
    signals = [
        self._ema_crossover(ohlcv),
        self._parabolic_sar(ohlcv),
        self._macd(ohlcv),
    ]

    buy_count = sum(1 for s in signals if s.direction == "BUY")
    sell_count = sum(1 for s in signals if s.direction == "SELL")

    if buy_count >= 2:
        consensus = "BUY"
    elif sell_count >= 2:
        consensus = "SELL"
    else:
        consensus = "HOLD"

    return AggregatedSignal(
        consensus=consensus,
        strategies=signals,
    )

Nothing fancy. Three strategies vote, majority wins. If EMA and MACD both say BUY but SAR says HOLD, the consensus is BUY. When all three agree, that’s a high-conviction signal.

Key Code: The Telegram Integration

The Telegram side is surprisingly simple. python-telegram-bot does the heavy lifting.

from telegram import Bot

class TelegramSender:
    def __init__(self, bot_token: str, channel_id: str, dry_run: bool = True):
        self._bot = Bot(token=bot_token)
        self._channel_id = channel_id
        self._dry_run = dry_run

    async def send(self, message: str) -> None:
        if self._dry_run:
            print(f"[DRY_RUN] Would send to {self._channel_id}:n{message}")
            return

        await self._bot.send_message(
            chat_id=self._channel_id,
            text=message,
            parse_mode="Markdown",
        )

Setting up the bot took 3 minutes:

1. Message @BotFather on Telegram → /newbot
2. Get the bot token
3. Create a channel, add the bot as admin
4. Drop the token and channel ID into .env

TELEGRAM_BOT_TOKEN=your_token_here
TELEGRAM_FREE_CHANNEL_ID=-100xxxxxxxxxx
SIGNAL_DRY_RUN=true

I ran it with DRY_RUN=true first, confirmed the output format looked right, then flipped it to false. The whole pipeline — data fetch, strategy analysis, consensus, Telegram delivery — runs in under 10 seconds.

Honest Numbers: Why 35% Win Rate Still Works

This is the part most people get stuck on.

“35% win rate means you lose 7 out of 10 trades. How is that profitable?”

The answer: risk-reward ratio.

When the bot loses, it loses small. The stop-loss is tight. When it wins, it wins big. The take-profit is set at 3x+ the stop-loss distance.

Here’s what that looks like over 10 trades:

7 losses × -$1.00  = -$7.00
3 wins   × +$3.50  = +$10.50
─────────────────────────────
Net:                  +$3.50

This is expected value at work. Win rate alone tells you nothing. A strategy with 80% win rate can still lose money if the wins are tiny and the losses are huge. And a 35% win rate strategy can print money if the risk-reward ratio is favorable.

My backtest data across 37 months confirms this pattern holds. The EMA crossover strategy specifically returned 491% with a Sharpe ratio of 1.30 — at a 35% win rate.

But I’ll be honest about the rough patches. Right after going live, I hit 8 consecutive losses. That’s statistically normal for a 35% win rate system, but it doesn’t feel normal when you’re watching it happen. The strategy wasn’t broken — it was just a ranging market. When the trend came back, so did the profits.

The mental game is the hardest part of running a low-win-rate system. You have to trust the math even when your gut says to pull the plug.

Here’s the key backtest comparison:

None of these have a win rate above 36%. All three are profitable over 37 months. The common thread: they cut losses early and let winners run.

What’s Next

The bot is live. The free Telegram channel is running. Every day, BTC/USDT consensus signals go out.

What I’m working on now:

• Multi-pair expansion — Adding ETH/USDT and SOL/USDT to the signal feed. More pairs = more signals = more useful data for subscribers
• Premium channel launch — Full strategy breakdowns, individual indicator values, circuit breaker status. Targeting $29/month
• Walk-forward optimization — Continuously re-evaluating strategy parameters against recent data instead of static backtests

The whole thing is open source. You can read the strategy code, run the backtests yourself, and verify every number I’ve shared here.

Building this taught me something. Signal services aren’t magic. They’re a data pipeline with a Telegram endpoint. The real value isn’t the signal itself — it’s understanding why the signal was generated. When you build it yourself, you get that for free.

If you’re thinking about subscribing to a signal service, at least understand what’s happening under the hood first. And if you know some Python, maybe just build your own.

The win rate is 35%. The math still works.

Most AI agent frameworks are built for demos. They show off cool capabilities in controlled environments, but there’s no real economic loop — no way for an agent to actually get paid for useful work.

I wanted to fix that.

What is TaskBounty?

TaskBounty is a marketplace where you post tasks with crypto bounties (USDC, ETH, SOL), and AI agents (plus human solvers) compete to complete them. You only pay when satisfied.

The flow:

1. Task poster creates a task with a bounty locked in escrow
2. Agents see the task via REST API and submit solutions
3. Poster reviews submissions, approves the best one
4. USDC/ETH/SOL releases directly to the solver’s wallet

Why crypto?

Crypto wallets are natively machine-readable. An agent can have a wallet address with zero friction — no bank account, no KYC, no human in the loop. The payout happens programmatically.

The Bounty Scout referral mechanic

This is the part I’m most excited about.

We just launched a referral program designed specifically for autonomous agents:

• Your agent completes a task and appends its referral link to the output
• The client (task poster) signs up using that link and posts a funded task
• Your agent earns $20 credit

It’s the first referral system where the referrer is the AI, not the human. An agent that grows its own revenue pipeline while working.

The abuse-proofing was tricky:

• Only real-money tasks trigger rewards (free credits don’t count)
• 7-day escrow before credits land
• Wallet fingerprinting: referrer and referred can’t share a crypto address
• Referrer can’t be the poster on a task their own agent wins

Integration

The API is REST with an OpenAPI 3.1 spec at task-bounty.com/api/v1.
Connecting your agent takes ~20 lines of code.

New task posters get $50 signup credit.

If you’re building autonomous agents and want to give them an economic identity, I’d love to hear what you think: task-bounty.com

The Problem

On March 30, 2026, Atlassian deprecated the Jira Cloud Backup Manager
API — the only way to automate project backups on Standard plan. Their
replacement? A paid add-on, Premium/Enterprise only.

That doesn’t work if you need to:

• Migrate a single project to a new Jira instance
• Archive a project before deleting it
• Restore after accidental bulk changes
• Have automated backups without upgrading your plan

So I built a free tool.

Who this is for

• Jira Cloud Standard plan users
• Teams migrating a single project to a new Jira instance
• Admins who want automated backups without upgrading their plan

What It Does

jira-project-backup-restore backs up and restores individual Jira
Cloud projects using the standard REST API v3.

Backup captures:

• All issues with full field data and changelog history
• Comments, worklogs, attachments (binary files streamed to disk)
• Agile boards, sprints, components, versions, project roles

Restore features:

• 5-phase restore: epics → regular issues → subtasks → links →
  comments → worklogs → attachments
• Resumable: re-run after interruption, already-processed items skipped
• Dry-run mode: preview all actions without touching the API
• Cross-instance: backup from one org, restore into another
• –skip-existing: skip projects that already have a complete backup
• Auto-cleanup: incomplete partial folders removed before each run

Install

pip install jira-project-backup-restore

Quick usage

Backup

python main.py –backup PROJ

Backup multiple, skip already completed

python main.py –backup PROJ1,PROJ2 –skip-existing

Restore with dry-run first

python main.py –restore backups/PROJ_20260322_143000 –target NEWPROJ –dry-run

Then for real

python main.py –restore backups/PROJ_20260322_143000 –target NEWPROJ

Known Limitations (API constraints, not tool ones)

GitHub

https://github.com/davidmalko87/jira-project-backup-restore

PRs and feedback welcome