DEV Community: Ashan_Dev

UnProductive™: An Enterprise Dashboard for Accomplishing Absolutely Nothing

Ashan_Dev — Wed, 08 Apr 2026 17:22:14 +0000

This is a submission for the DEV April Fools Challenge

What I Built

UnProductive™ — The Anti-Productivity Suite.

A full bento-grid dashboard that looks like a legitimate SaaS product at first glance. Dark background, sidebar nav, real-time clock, progress charts, an AI advisor, a terminal. Everything a productivity app needs.

Except every single feature is engineered to fail, flee, gaslight, or accomplish nothing whatsoever.

Here's what's inside:

The Evasive Button — A box labeled "Important Decision Matrix" with a button that says "Acknowledge." It physically runs away when your cursor gets within 110px of it. If you actually manage to click it, the response is: "Click registered. Action: none. You are welcome."

Thought Shredder — Type your billion-dollar idea. While you type, it randomly scrambles your characters and injects glitch symbols. Hit Obliterate and the text corrupts into garbage on-screen before disappearing to /dev/null/forever.

UnProductive AI™ — Consults "The Oracle." The advice includes things like "Analysis complete. You are 97% procrastination, 2% good intentions, 1% cached regret." and "ERROR 418: Goal detected. Initiating avoidance protocol." Response accuracy: 0%. Powered by 0 neurons and pure vibes.

Vibe Check Terminal — A fake terminal with real commands. Run npm install and it adds 9,847 packages with 12,674 vulnerabilities. Three of them are sentient. Run git blame and it just says "you did this." Try to exit and it tells you the void doesn't have a door.

The Anti-Ledger — A to-do list. Click any item and it shakes, denies your access, and changes the status to "ACCESS DENIED." The task label gets a strikethrough. You did not complete it. You were rejected by it.

Chaos Clock — Keeps time, mostly. 10% of the time it steps backwards. 12% of the time it jumps several hours in either direction with a color flash and a CSS skew. Feels eerily plausible.

Productivity Donut — Animates up to 99% with great confidence, then immediately crashes to 0% and fires a toast: "Productivity peaked at 99%. System reset to preserve institutional standards."

Gaslight Toasts — Random notifications every 7–21 seconds. "You blinked 5 times. Recommended: 3. Please calibrate." and "Your cursor is moving at an unsustainable velocity."

Synergy Optimizer Modal — Full-screen takeover with a spinner and a progress bar permanently stuck at 99%. The Cancel button runs away from your cursor. Auto-dismisses after 28 seconds with: "Results: statistically indistinguishable from before."

FIX UI Button — Hue-rotates the page, mirrors it, rotates it slightly, or removes all color. Always reverts. Never fixes anything.

Daily Motivation Engine™ — Cycles through quotes like "Every expert was once a beginner who gave up and rebranded as a consultant." and "A plan without execution is a very impressive document."

The Developer's Confession — A "CLASSIFIED" section leaked as evidence that I have, outside of UnProductive™ hours, been observed writing real software. Links to my actual GitHub automation repos under a redacted watermark. The irony is intentional.

Demo

🔗 devaprilfoolschallenge.vercel.app

For the full experience, try these in order:

Try to click the "Acknowledge" button
Type something important into the Thought Shredder, then hit Obliterate
Run git blame in the Vibe Terminal
Click "Run AI Optimizer" and try to cancel it
Press FIX UI a few times
Just... wait for a gaslight toast

Code

itxashancode / DEV-April-Fools-Challenge

How I Built It

Vanilla HTML, CSS, and JavaScript. No framework. Intentionally.

Three.js for two things: a background particle field (2,200 points in acid/magenta/cyan pulled by the mouse), and the entropy visualizer widget which renders a wireframe torus knot that randomly glitches its scale, position, and color.

Tailwind (CDN) for layout. The bento grid is a 12-column CSS grid with span classes per widget — w1 through w9, full-width for the GitHub confession section.

The 3D card tilt on hover uses CSS custom properties set by mousemove on each widget:

card.style.setProperty('--local-mouse-x', x.toFixed(3));
card.style.setProperty('--local-mouse-y', y.toFixed(3));

Then consumed in CSS:

.widget:hover {
  transform: perspective(900px)
             rotateX(calc(var(--local-mouse-y) * -12deg))
             rotateY(calc(var(--local-mouse-x) * 12deg))
             translateZ(20px);
}

No JS touches the transform. Keeps it smooth.

The evasive button logic (used in both the Acknowledge button and the Synergy Cancel button) tracks mouse distance to the button center and randomizes top/left within the parent's bounding rect if you get too close:

if (Math.hypot(e.clientX - cx, e.clientY - cy) < 110) {
    btn.style.top  = `${4 + Math.random() * maxY}px`;
    btn.style.left = `${4 + Math.random() * maxX}px`;
}

The noise overlay is a single <div> with an SVG feTurbulence filter tiled over the whole page at 4% opacity with mix-blend-mode: overlay. Basically free performance-wise.

The Chaos Clock has weighted randomness — most ticks advance normally, 10% go backwards, 12% jump by up to ±10 hours with a visual flash. Random clocks tend to feel too chaotic; weighted behavior makes it feel almost plausible until it isn't.

Fonts: Space Mono for the monospace/terminal aesthetic, Playfair Display for the big italic headings. The contrast between them does a lot of work.

Prize Category

Best Ode to Larry Masinter — the HTTP 418 easter egg is hardcoded in the AI advisor responses ("ERROR 418: Goal detected. Initiating avoidance protocol."), the project name gestures at RFC 2324's whole ethos, and the entire thing is built on the premise that software can be technically correct and completely useless. That feels like the spirit of the teapot to me.

Built by @itxashancode

I built a bot that answers GitHub Discussions using free AI models — here's what I learned

Ashan_Dev — Wed, 08 Apr 2026 13:16:48 +0000

Heads up: This is an educational project. The bot can post to GitHub Discussions, which means you need to use it carefully. I'll cover what responsible use looks like at the end.

A few months ago I wanted to get GitHub's Galaxy Brain badge — the one you earn by getting answers marked as Accepted in Discussions. I figured automating the search part would be interesting. Finding relevant open questions manually is genuinely tedious.

What started as a script to find unanswered threads turned into a project I actually care about. Not because of the badge, but because of the infrastructure problems it forced me to solve.

Here's what's in the codebase and what I learned building each piece.

The basic idea

The bot does four things:

Discovers GitHub repos that have Discussions enabled, filtered by topic tags and star count
Fetches open, unanswered Discussion threads from those repos
Sends the question to a free LLM via OpenRouter and gets an answer
Optionally posts that answer (with your confirmation, by default)

None of that is complicated. The interesting problems came from making it reliable.

Problem 1: Free LLM models are flaky

OpenRouter's free tier is great — 18+ models, no billing required. The catch is availability. A model that worked yesterday might 404 today. A model that worked an hour ago might be rate-limited now.

My first version just tried one model and crashed when it failed. The fix was a rotation list:

_DEFAULT_MODELS = [
    "qwen/qwen3.6-plus:free",
    "stepfun/step-3.5-flash:free",
    "nvidia/nemotron-3-super-120b-a12b:free",
    "meta-llama/llama-3.3-70b-instruct:free",
    "google/gemma-3-27b-it:free",
    # ... 13 more
]

The bot tries them in order. If a model returns an empty response, a 404, or a 429, it logs the failure and moves to the next one. At session end, --models shows a table of which models succeeded, failed, and how fast they were.

One thing I noticed: "success" and "quality" are different. A model can return a response that passes all the checks but still gives a generic non-answer. The answer length filter (ANSWER_MIN_CHARS, ANSWER_MAX_CHARS) catches the worst cases, but it doesn't catch confident-sounding garbage.

Problem 2: Retrying the wrong way

Before adding proper backoff, the bot would hit a rate limit and immediately retry. Then retry again. Then again. GitHub's API would respond with 429 for the rest of the session.

The fix was reading Retry-After headers:

retry_after = int(response.headers.get("Retry-After", RATE_LIMIT_RETRY_AFTER_DEFAULT))
time.sleep(retry_after)

GitHub is inconsistent about including that header. When it's missing, the bot falls back to exponential delay. It's not perfect, but it's miles better than hammering an endpoint that's already telling you to stop.

Problem 3: One bad endpoint killing the whole session

This took me a while to notice. If a particular GraphQL query started timing out — say, because a repo was unusually large — the bot would retry it over and over, spending most of the session waiting.

Circuit breakers solve this. After a configurable number of consecutive failures, the circuit "opens" and blocks further requests to that endpoint for a timeout period. Then it half-opens: one probe request goes through. If that succeeds, the circuit closes again.

class CircuitBreaker:
    CLOSED = "closed"
    OPEN   = "open"
    HALF   = "half_open"

    def __init__(self, name, threshold=5, timeout=120):
        self.state    = self.CLOSED
        self.failures = 0
        self.opened_at = None

The effect in practice: the bot now skips broken endpoints and moves to the next repo in the list, instead of getting stuck.

Problem 4: Ctrl+C corrupting the stats file

The stats file (galaxy_brain_stats.json) gets written at the end of each session. If you hit Ctrl+C mid-write, you get a partial JSON file, which breaks the next session.

The fix was a ShutdownHandler that catches SIGINT/SIGTERM and sets a flag:

class ShutdownHandler:
    def __init__(self):
        self._shutdown = False
        signal.signal(signal.SIGINT,  self._handle)
        signal.signal(signal.SIGTERM, self._handle)

    def _handle(self, *_):
        self._shutdown = True

    @property
    def requested(self):
        return self._shutdown

Every loop in the bot checks shutdown.requested before its next iteration. Ctrl+C finishes the current task cleanly, then exits. The stats file always gets written to disk before the process ends.

What else is in there

In-memory TTL cache. Avoids re-fetching the same GraphQL results within a session. Default TTL is 5 minutes. When you're processing 50 repos, this matters.

Multi-modal support. If a Discussion post contains images and the selected model supports vision, the bot fetches the images and includes them in the prompt. Same for external links — it fetches the page content and appends it.

Key rotation. You can put multiple OpenRouter API keys in .env, comma-separated. When one hits its rate limit, the bot rotates to the next.

Webhook notifications. Discord and Slack. Sends an alert when an answer gets accepted, and a summary at the end of each session.

Stats by org. Breaks down your answer history by repository owner. Useful for seeing which communities you've been most active in.

Setting it up

git clone https://github.com/YOUR_USERNAME/galaxy-brain-bot.git
cd galaxy-brain-bot
pip install -r requirements.txt
cp .env.template .env
# Fill in GITHUB_TOKEN, GITHUB_USERNAME, OPENROUTER_KEYS
python test_bot.py  # run this before anything else
python galaxy_brain_bot.py

The test suite checks all your credentials and API connections before you run the main bot. Run it first.

By default, the bot asks for confirmation before posting each answer (AUTO_APPROVE_ANSWERS=false). Keep it that way until you've seen a few answers and trust the output quality on the repos you're targeting.

Responsible use

A few things I want to say directly:

Don't run it unsupervised at scale. The MAX_ANSWERS_PER_SESSION setting exists for a reason. Posting 50 answers in an hour is a good way to get flagged.

Read the answers before posting. LLMs are wrong sometimes. Posting a confident wrong answer in a GitHub Discussion is worse than posting nothing.

Check the repo's rules. Some repos have Codes of Conduct that explicitly restrict automated participation. The bot tries to detect this, but it can miss things.

It's a research tool, not a farming tool. The badge is a byproduct. If you're using this to post low-effort answers at volume, you're not using it for what it was built for.

Source code

Full source, setup instructions, and config reference: https://github.com/itxashancode/Galaxy-Brain-Automation

The whole thing is one Python file (galaxy_brain_bot.py) plus a test suite. No frameworks, no magic — just requests, rich for the terminal UI, and python-dotenv. If you want to understand a specific piece, it's all in one place.

Happy to answer questions in the comments. If you spot something in the circuit breaker or backoff logic that could be better, I'm genuinely interested.

Built for learning. MIT licensed.

🏥 gh-repo-health: Check Your GitHub Repo's Health Score in Seconds

Ashan_Dev — Thu, 19 Mar 2026 03:56:43 +0000

Have you ever opened a GitHub repo and wondered "is this project actually maintained?" — or pushed your own project and asked "does this even look professional?"

I asked myself the same questions. So I built gh-repo-health — a CLI tool that audits any GitHub repository and gives it a health score based on community standards.

🤔 Why I Built This

When I was exploring open source projects to contribute to, I kept manually checking:

Does it have a README?
Is there a CONTRIBUTING guide?
Any issue templates?
A LICENSE file?
A CODE_OF_CONDUCT?

Doing this for every repo was exhausting. I wanted a single command that tells me everything at once.

So I built gh-repo-health.

⚡ What It Does

gh-repo-health scans any public GitHub repository and checks for key community health files:

File	Why It Matters
`README.md`	First impression — does the project explain itself?
`LICENSE`	Legal clarity for contributors and users
`CONTRIBUTING.md`	Guides new contributors on how to help
`CODE_OF_CONDUCT.md`	Sets community standards
`SECURITY.md`	Responsible disclosure for vulnerabilities
Issue Templates	Structured bug reports and feature requests
Pull Request Template	Consistent PR process

Each check passes or fails, and you get an overall health score at the end.

🚀 Getting Started

Clone the repo and run it against any GitHub repository:

git clone https://github.com/itxashancode/gh-repo-health
cd gh-repo-health
pip install -r requirements.txt

Then audit any repo:

python main.py itxashancode/Pull-Shark-Automation

You'll get output like:

✅ README.md          found
✅ LICENSE            found
❌ CONTRIBUTING.md    missing
❌ CODE_OF_CONDUCT    missing
✅ Issue Templates    found
❌ SECURITY.md        missing
❌ PR Template        missing

Health Score: 43% — Needs Improvement

🛠️ How It Works

The tool uses the GitHub REST API to check for the existence of community health files. No cloning required — it's all API calls.

import requests

def check_file(owner, repo, filepath):
    url = f"https://api.github.com/repos/{owner}/{repo}/contents/{filepath}"
    response = requests.get(url)
    return response.status_code == 200

It checks common file locations — root, .github/, and docs/ — so it doesn't miss files tucked in subdirectories.

💡 What I Learned Building This

This was one of my early Python projects, and it taught me a lot:

GitHub's API is incredibly powerful — you can inspect almost anything about a repo without cloning it
Community health files genuinely matter — repos with them get more contributions
CLI tools are satisfying to build — instant feedback, no UI needed
Error handling is critical — private repos, rate limits, and missing tokens all need to be handled gracefully

🔮 What's Next

I'm planning to add:

[ ] Badge generation — embed a health score badge in your README
[ ] Batch scanning — audit all repos in an organization at once
[ ] GitHub Actions integration — fail CI if health score drops below a threshold
[ ] JSON output — for piping results into other tools

🌟 Try It on Your Own Repo

Run gh-repo-health against your own projects. You might be surprised what's missing!

👉 GitHub: itxashancode/gh-repo-health

If you find it useful, drop a ⭐ on the repo — it genuinely motivates me to keep building.

I'm Ashan, an APTECH student from Karachi building GitHub automation tools and learning in public. If you have ideas for features, drop them in the comments below — I read every one! 👇

🎮 What I Learned Building a Minecraft Voting Portal with Pure HTML, CSS & JS (No Frameworks!)

Ashan_Dev — Sun, 15 Mar 2026 01:50:54 +0000

I'm a student developer from Karachi, Pakistan 🇵🇰 — studying at APTECH and building real projects to level up my skills. This one started as a fun side project for a Minecraft server community called HustlersMC and turned into one of the biggest learning experiences of my journey so far.

No React. No Vue. No Tailwind. Just pure HTML, CSS, and JavaScript — and way more depth than I expected.

Here's everything I genuinely learned. 👇

🤔 Why Build a Voting Portal?

Minecraft servers live and die by their ranking on voting sites like Planet Minecraft and Minecraft Server List. The more players vote, the higher the server ranks, the more new players join.

Most voting portals out there are ugly, slow, or just a boring list of links. I wanted to build something that actually made players want to vote — something that felt premium, fast, and exciting the moment you landed on it.

That became Vote-for-HustlersMC.

✨ What I Built

Here's the feature list at a glance:

🪟 Glassmorphism UI — frosted glass cards, layered transparencies, depth without weight
✍️ Typewriter text effects — dynamic headlines that animate on load
🌌 Animated backgrounds — subtle motion that brings the page to life
🔗 10+ verified voting platforms integrated in one place
📈 SEO-ready structure — meta tags, semantic HTML, Open Graph
📊 Analytics-ready — plug in your tracking ID and you're live
♿ Accessibility-first — keyboard navigable, proper contrast, ARIA labels

And it runs on zero dependencies. No npm. No build step. Just open index.html.

💡 Lesson 1: Pure CSS Can Do Incredible Things

I went into this thinking I'd need a CSS framework to pull off the glassmorphism look. I was wrong.

The glass card effect is just a few lines:

.glass-card {
  background: rgba(255, 255, 255, 0.08);
  backdrop-filter: blur(16px);
  -webkit-backdrop-filter: blur(16px);
  border: 1px solid rgba(255, 255, 255, 0.15);
  border-radius: 16px;
  box-shadow: 0 8px 32px rgba(0, 0, 0, 0.3);
}

That's it. backdrop-filter: blur() is the magic. It blurs everything behind the element, creating that frosted glass illusion.

What I learned: Before reaching for a framework, ask yourself — can CSS do this natively? More often than not, the answer is yes. Frameworks add weight. Native CSS adds nothing.

💡 Lesson 2: The Typewriter Effect Taught Me JavaScript Timing

The animated typewriter headline was something I'd seen on hundreds of sites but never built myself. I assumed it required a library. It doesn't.

Here's the core logic I wrote:

const phrases = [
  "Vote. Rise. Conquer.",
  "Support HustlersMC Today.",
  "Every Vote Counts. ⚔️"
];

let phraseIndex = 0;
let charIndex = 0;
let isDeleting = false;

function typeWriter() {
  const current = phrases[phraseIndex];
  const displayed = isDeleting
    ? current.substring(0, charIndex--)
    : current.substring(0, charIndex++);

  document.querySelector('.typewriter').textContent = displayed;

  if (!isDeleting && charIndex === current.length) {
    setTimeout(() => isDeleting = true, 1500); // pause before deleting
  } else if (isDeleting && charIndex === 0) {
    isDeleting = false;
    phraseIndex = (phraseIndex + 1) % phrases.length;
  }

  setTimeout(typeWriter, isDeleting ? 60 : 100);
}

typeWriter();

What I learned: setTimeout recursion is incredibly powerful for animations. Understanding the difference between typing speed (100ms) and deletion speed (60ms) is what makes it feel human. Small timing details create big UX impact.

💡 Lesson 3: SEO Is Not Just for Big Websites

This one surprised me most. I thought SEO was something you worry about when you have a blog or a business. But even a simple static page benefits enormously from it.

I added:

<!-- Basic SEO -->
<meta name="description" content="Vote for HustlersMC — the fastest growing Minecraft server in Pakistan. Support us on 10+ platforms!">
<meta name="keywords" content="HustlersMC, Minecraft server, vote, Pakistan Minecraft, server ranking">

<!-- Open Graph for social sharing -->
<meta property="og:title" content="Vote for HustlersMC 🎮">
<meta property="og:description" content="Click to vote and help us climb the rankings!">
<meta property="og:image" content="https://yoursite.com/preview.png">
<meta property="og:type" content="website">

<!-- Semantic HTML -->
<main>, <section>, <article>, <nav>, <footer>

The moment I shared the link on Discord, the Open Graph preview card showed up beautifully — the server logo, title, and description. Players were more likely to click it. The server's visibility on Google improved too.

What I learned: Semantic HTML + meta tags = free marketing. It costs you 10 minutes and pays back for months.

💡 Lesson 4: Animated Backgrounds Are About Restraint, Not Complexity

My first attempt at the animated background was too intense — particles flying everywhere, colors shifting rapidly. It looked like a nightclub, not a website.

The version I shipped uses a subtle CSS keyframe animation:

@keyframes gradientShift {
  0%   { background-position: 0% 50%; }
  50%  { background-position: 100% 50%; }
  100% { background-position: 0% 50%; }
}

body {
  background: linear-gradient(135deg, #0f0c29, #302b63, #24243e);
  background-size: 300% 300%;
  animation: gradientShift 8s ease infinite;
}

Slow. Smooth. Atmospheric. It adds life without distracting from the content.

What I learned: Great animation is mostly about what you don't do. Subtlety wins. If users notice the animation more than the content, you've gone too far.

💡 Lesson 5: Building for a Real Community Changes Everything

This wasn't a practice project for a fake client. Real players from HustlersMC were going to use this. That pressure made me:

Test on mobile obsessively (most Minecraft players are on phones between sessions)
Check contrast ratios for accessibility
Make sure every voting link opened correctly in a new tab
Add a smooth loading state so it didn't flash unstyled content (FOUC)

I also integrated Google Analytics so the server owner could see which voting platforms were being used most and which players were dropping off. That turned a static page into an actual growth tool.

What I learned: Building for real users forces you to care about details you'd ignore in a tutorial. Ship something real as early as possible — even if it's small.

🛠️ The Tech Stack (Zero Dependencies)

What	How
Structure	Semantic HTML5
Styling	Pure CSS3 (glassmorphism, keyframe animations, CSS variables)
Interactivity	Vanilla JavaScript (typewriter, scroll effects)
SEO	Meta tags, Open Graph, semantic markup
Analytics	Google Analytics (plug-and-play)
Hosting	GitHub Pages (free, instant)

No npm. No node_modules. No build pipeline. Just files.

🚀 The Result

A voting portal that looks like it cost money to build — but didn't. Players actually commented on how clean it looked. The server owner could share the link anywhere and it looked professional on every platform.

You can explore the full source code here 👇

🔗 GitHub: github.com/itxashancode/Vote-for-HustlersMC

💬 What Would You Build Next?

I'm currently exploring:

Adding a live vote counter with localStorage
A leaderboard showing top voters of the month
A Discord webhook that pings the server when someone votes

If you've built something for a game community — or if you're curious about any of the techniques above — drop a comment below! I'd love to see what you're working on. 🎮

If this helped you, consider giving the repo a ⭐ — it genuinely means a lot to a student developer from Pakistan trying to make his mark!

🐍 5 Python Scripts Every Student Dev Should Automate First

Ashan_Dev — Fri, 13 Mar 2026 16:04:02 +0000

I'm a student dev from Karachi. No internship. No senior to guide me.
Just a laptop, Python, and a habit of automating everything that bored me twice.
Here's what I wish I had automated sooner.

1. 🔁 Auto-Rename & Organize Your Downloads Folder

Your downloads folder is a graveyard. Fix it in 15 lines.

import os
import shutil

FOLDER = os.path.expanduser("~/Downloads")
TYPES = {
    "Images": [".jpg", ".jpeg", ".png", ".gif", ".webp"],
    "Docs":   [".pdf", ".docx", ".txt", ".xlsx"],
    "Code":   [".py", ".js", ".ts", ".html", ".css"],
    "Videos": [".mp4", ".mov", ".mkv"],
    "Zips":   [".zip", ".rar", ".tar"],
}

for file in os.listdir(FOLDER):
    ext = os.path.splitext(file)[1].lower()
    for folder, exts in TYPES.items():
        if ext in exts:
            dest = os.path.join(FOLDER, folder)
            os.makedirs(dest, exist_ok=True)
            shutil.move(os.path.join(FOLDER, file), dest)

Run it once a week with Task Scheduler (Windows) or a cron job. You'll feel like a wizard.

2. 📸 Bulk Screenshot → PDF Converter

Got lecture slides scattered as screenshots? Merge them into one PDF instantly.

from PIL import Image
import os

def screenshots_to_pdf(folder, output="merged.pdf"):
    images = sorted([
        Image.open(os.path.join(folder, f)).convert("RGB")
        for f in os.listdir(folder)
        if f.endswith((".png", ".jpg", ".jpeg"))
    ], key=lambda x: x.filename)

    images[0].save(output, save_all=True, append_images=images[1:])
    print(f"✅ Saved: {output}")

screenshots_to_pdf("./slides")

Install: pip install Pillow

This saved me hours before exams. Seriously.

3. 🔔 Desktop Notifier for Any Website Change

Watching for a job post? A price drop? A new batch opening?
Stop refreshing. Let Python do it.

import requests
import hashlib
import time
from plyer import notification

URL = "https://example.com/jobs"  # replace with your target
CHECK_EVERY = 300  # seconds

def get_hash(url):
    r = requests.get(url, timeout=10)
    return hashlib.md5(r.text.encode()).hexdigest()

last = get_hash(URL)
print("👁️ Watching for changes...")

while True:
    time.sleep(CHECK_EVERY)
    current = get_hash(URL)
    if current != last:
        notification.notify(title="🚨 Page Changed!", message=URL, timeout=10)
        last = current

Install: pip install requests plyer

Set it, forget it, get notified.

4. 📂 Auto-Backup Your Projects to a Zip

Before you break something (you will), back it up.

import zipfile
import os
from datetime import datetime

def backup_project(source_dir, output_dir="./backups"):
    os.makedirs(output_dir, exist_ok=True)
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    zip_name = os.path.join(output_dir, f"backup_{timestamp}.zip")

    with zipfile.ZipFile(zip_name, "w", zipfile.ZIP_DEFLATED) as zf:
        for root, dirs, files in os.walk(source_dir):
            dirs[:] = [d for d in dirs if d not in ["node_modules", ".git", "__pycache__"]]
            for file in files:
                filepath = os.path.join(root, file)
                zf.write(filepath, os.path.relpath(filepath, source_dir))

    print(f"✅ Backup saved: {zip_name}")

backup_project("./my-project")

Notice: it skips node_modules, .git, and __pycache__ — so the zip stays small.

5. 🤖 GitHub Auto-Commit Streak Keeper

Missing a day on your contribution graph hurts.
This script makes a tiny commit so your streak stays alive when life gets in the way.

import subprocess
from datetime import datetime

LOG_FILE = "streak.log"

with open(LOG_FILE, "a") as f:
    f.write(f"streak kept: {datetime.now()}\n")

subprocess.run(["git", "add", LOG_FILE])
subprocess.run(["git", "commit", "-m", f"chore: streak {datetime.now().date()}"])
subprocess.run(["git", "push"])
print("✅ Streak alive!")

Set this on a cron job at 11:50 PM. Sleep peacefully.

⚠️ Use on a personal/practice repo — not your main project.

🎯 Quick Recap

#	Script	What It Solves
1	Downloads Organizer	Chaos in your folders
2	Screenshots → PDF	Messy lecture notes
3	Website Change Notifier	FOMO on opportunities
4	Project Backup	That "oh no" moment
5	Streak Keeper	GitHub anxiety

💬 Drop Your Script in the Comments

What's the first thing YOU automated as a student dev?
I'm building a list — your script might end up in part 2. 👇

Built in Karachi. Tested at 2am. Working on more automation tools at github.com/itxashancode

I Have 18 GitHub Repos at 17 — Here's What I Built, Broke, and Learned

Ashan_Dev — Thu, 12 Mar 2026 23:42:21 +0000

When I joined GitHub, I didn't have a plan.

I just started building things — some useful, some broken, some embarrassing.
But 18 repositories later, I've learned more from pushing code than from any tutorial.

Here's an honest breakdown of what I built, what flopped, and what actually taught me something real.

🦈 The One That Started Everything: Pull Shark Automation

Automate GitHub PR creation at scale — 62 PRs/min with Python

This was my first "real" project. I wanted the GitHub Pull Shark badge, but doing it manually was painfully slow. So I automated it.

What it does:

Dual modes: Sequential (stable) and Parallel (blazing fast async)
Multi-token rotation to stay within rate limits
Auto-merge, Discord/Slack webhooks, proxy support
Windows compatible

# Sequential mode
python main.py

# Parallel mode (fast)
python parallel_automation.py --count 100 --concurrent 10

# Test without committing
python main.py --dry-run

Real-world result: 62.5 PRs/min with 3 tokens and 20 parallel workers.

⚠️ Built for learning and CI/CD stress testing. Use responsibly.

🔗 Pull-Shark-Automation on GitHub — drop a ⭐ if it helps!

🤝 Pair Extraordinaire — Automating Co-Author Badges

After Pull Shark, I went after the Pair Extraordinaire badge.
Same idea — understand how GitHub's contribution system works by building around it.

This one taught me:

How Git co-authoring actually works under the hood
Managing multiple identities in commits
Token scoping and permission management

🔗 Pair-Extraordinaire on GitHub — drop a ⭐ if it helps!

💡 What 18 Repos Actually Taught Me

1. READMEs matter more than code quality at first

Nobody digs into your code on first impression. They read your README.
Write it like you're explaining to a smart friend who's never seen your project.

2. Stars don't validate you — but they do signal clarity

Pull Shark got 27 stars in a week not because the code was perfect,
but because the README was clear and the use case was specific.

3. Broken repos are fine. Abandoned repos are not.

I have repos I haven't touched in weeks. That's okay.
What's not okay is leaving them with no description, no README, no context.
Even a one-liner description helps someone understand what you were thinking.

4. Your GitHub is a portfolio before you have a portfolio

I don't have a deployed portfolio site yet (it's in progress 👀).
But recruiters and collaborators can still see exactly what I can do
by looking at my repos. Treat every repo like a mini-resume.

5. Committing consistently beats committing perfectly

Green squares on your contribution graph tell a story.
Don't wait until your code is "ready." Push early, push often.

🛠️ My Current Stack Across All Projects

Language/Tool	Used For
Python	Automation, scripting, GitHub tools
JavaScript / TypeScript	Web apps, frontend logic
React + Next.js	UI, full stack projects
Node.js	Backend, API building
Firebase	Auth, real-time DB
HTML + CSS	Foundations, landing pages

🔭 What I'm Building Next

Personal portfolio site with Next.js (almost done)
AI-powered web app integrating Claude / OpenAI APIs
More open source tools for developers

🤙 Let's Connect

If you're a dev from Pakistan, a beginner just starting out,
or someone who loves building weird automation tools — let's connect.
Drop a comment, follow along, or check out my repos.

📦 GitHub → itxashancode
🌐 Linktree → itxashanvibes

What was your first GitHub repo? Drop it in the comments 👇

🤝 Automate GitHub's Pair Extraordinaire Badge with Python

Ashan_Dev — Wed, 11 Mar 2026 10:13:57 +0000

A deep dive into Pair Extraordinaire Automation — a Python framework that streamlines co-authored PRs at scale, with dual execution modes, token rotation, webhook notifications, and smart state resumption.

🔗 Full source code on GitHub: Pair-Extraordinaire — drop a ⭐ if it helps!

Ever wondered how some developers rack up GitHub achievement badges at scale? Or wanted to deeply understand how GitHub co-authoring workflows actually function under the hood? That's exactly what Pair Extraordinaire Automation is built for.

This open-source Python framework automates co-authored Pull Request workflows — giving you a hands-on way to explore GitHub API integration, token management, webhook notifications, and stateful automation design, all in one project.

⚠️ Heads up: This tool is built for educational purposes — to study GitHub automation and co-authoring patterns. Always use it responsibly and in line with GitHub's Terms of Service.

🏆 What Is the Pair Extraordinaire Badge?

GitHub awards the Pair Extraordinaire achievement when you co-author and merge Pull Requests with a collaborator. The badge has four tiers:

Tier	Required PRs
Default	1 PR
🥉 Bronze	10 PRs
🥈 Silver	24 PRs
🥇 Gold	48 PRs

The magic happens through Git's Co-authored-by commit trailer — a simple but powerful convention that GitHub recognises to credit multiple authors on a single commit.

🎯 What Does This Project Do?

Pair Extraordinaire Automation is a configurable Python framework that:

Creates branches, makes co-authored commits, opens Pull Requests, and merges them — all automatically
Supports sequential and parallel execution modes
Handles rate limits with exponential backoff and smart retry logic
Rotates across multiple GitHub tokens for higher throughput
Sends real-time progress updates to Discord or Slack via webhooks
Persists state so you can resume after any interruption
Includes a dry-run mode for testing without touching your repository

🏗️ Architecture Overview

The project is cleanly structured into four layers:

Pair Extraordinaire Automation
│
├── run.py              ← Entry point & orchestrator
├── src/                ← Core bot logic (git ops, GitHub API, token mgr)
├── config/             ← JSON settings + .env variables
└── templates/          ← Commit message & PR body templates

The orchestration flow looks like this:

Start → Load Config → Choose Mode (Sequential / Parallel)
      → Create Branch → Co-authored Commit → Push → Open PR
      → Auto-Merge → Save State → Notify → Repeat

What I like about this design is its clear separation of concerns. The src/ layer handles all Git and GitHub API interactions, while config/ and templates/ let you customise behaviour without touching any core logic.

⚙️ Getting Started

Prerequisites

You'll need Python 3.8+, Git 2.0+, and the GitHub CLI installed. You also need two GitHub accounts — your own and a collaborator's.

Installation

# Clone the repo
git clone https://github.com/itxashancode/Pair-Extraordinaire-Automation.git
cd Pair-Extraordinaire-Automation

# Install dependencies
pip install -r requirements.txt

# Authenticate GitHub CLI
gh auth login

Configuration

Copy .env.example to .env and fill in your details:

GITHUB_TOKEN=your_personal_access_token
REPO_OWNER=your_github_username
REPO_NAME=your_repository_name

CO_AUTHOR_NAME=Collaborator Name
CO_AUTHOR_EMAIL=collaborator@email.com
CO_AUTHOR_TOKEN=collaborator_token_optional

# Optional webhooks
DISCORD_WEBHOOK=https://discord.com/api/webhooks/...
SLACK_WEBHOOK=https://hooks.slack.com/services/...

Then set your run parameters in config/:

{
  "pr_count": 50,
  "delay_seconds": 15,
  "auto_merge": true,
  "dry_run": false,
  "max_retries": 3
}

🚀 Usage

Always test first with dry-run

python run.py --dry-run --count 5

This simulates the full workflow — branch creation, commits, PRs — without making any real changes. It's a great way to catch config mistakes before they matter.

Run for real

# Basic run (uses config defaults)
python run.py

# Custom count with specific delay
python run.py --count 50 --delay 10

# Resume after an interruption — state is automatically tracked
python run.py

Sample output

🚀 Starting Pair Extraordinaire Automation from PR #1

🔹 Processing PR #1
  ├─ 🌿 Created branch: pair-auto-1-a1b2c3d4
  ├─ 💾 Committed with Co-authored-by trailer
  ├─ 📤 Pushed to remote
  └─ ✅ PR #101 created and merged

⏱️  Waiting 15 seconds...

🔹 Processing PR #2
...

🔑 The Co-authored-by Mechanic

The key to how this project works is a Git commit trailer that GitHub specifically recognises:

feat: automated update #1

This is an automated co-authored commit.

Co-authored-by: Collaborator Name <collaborator@email.com>

When a PR containing this trailer is merged, GitHub awards the Pair Extraordinaire badge to both the author and the co-author. The email in the trailer must match an email associated with the collaborator's GitHub account — that's a common gotcha.

🛡️ Security Considerations

A few things to keep in mind when running this:

Never commit your .env file — it's already in .gitignore, keep it that way
Use fine-grained personal access tokens scoped to specific repos only
Rotate tokens every 30–90 days as a good hygiene practice
Monitor your rate limit with gh api rate_limit — you get 5,000 requests/hour per token, and multi-token rotation lets you stack that

🐛 Common Issues

gh: command not found → Install GitHub CLI for your platform and verify with gh --version

Authentication failed → Run gh auth login and follow the prompts, or use echo "TOKEN" | gh auth login --with-token

Co-authored-by not recognized → Double-check that CO_AUTHOR_EMAIL exactly matches an email registered on the collaborator's GitHub account

API rate limit exceeded → Increase delay_seconds in config, or add a second token for rotation

📈 Real-World Benchmarks

Badge Goal	PRs	Approx. Time
Default	2	~30 seconds
Bronze	10	~3 minutes
Silver	24	~5 minutes
Gold	48	~10 minutes

💡 What I Learned Building This

This project is a great reference for several Python and GitHub automation patterns:

Stateful automation — persisting progress to a JSON file so a long-running task can be safely interrupted and resumed
Exponential backoff — retry logic that doubles the wait time on each failure (5s → 10s → 20s) to avoid hammering a rate-limited API
Token rotation — cycling through multiple API tokens to multiply your effective request quota
Template-based commit messages — separating message content from code so customisation doesn't require touching logic
Webhook integration — pushing structured notifications to Discord/Slack with colour-coded severity levels

Even if you never use this for badge automation specifically, these patterns come up constantly in real-world automation and DevOps work.

🤝 Contributing

The project is MIT licensed and welcomes contributions. If you want to jump in:

gh repo fork itxashancode/Pair-Extraordinaire-Automation
git checkout -b feature/your-improvement
# Make changes, commit with conventional commits
git commit -m "feat: add your amazing feature"
gh pr create

The codebase follows type hints and clear docstrings — black for formatting, flake8 for style, mypy for type checking.

🔗 Links

📦 GitHub Repo: itxashancode/Pair-Extraordinaire-Automation
👤 Author: @itxashancode
🌐 More from the author: linktr.ee/itxashanvibes

If you found this interesting, drop a ⭐ on the repo and let me know in the comments — what GitHub automation patterns have you built or wanted to build?

I'm a Self-Taught Dev from Pakistan — Here's What My First 6 Months Looked Like

Ashan_Dev — Thu, 05 Mar 2026 16:37:40 +0000

"Everyone talks about learning to code. Nobody talks about learning to code when resources cost money you don't have, and people around you don't understand why you're staring at a screen at 2 AM."

I'm Ashan — a student at APTECH Pakistan and an aspiring full stack developer. This is my honest, unfiltered story.

📅 Month 1–2: HTML & CSS (The Honeymoon Phase)

I started the way everyone does — building a portfolio page that looked nothing like what I imagined.

I spent 3 hours trying to center a div. No joke.


Please just center



  Finally.

The lesson? Everyone struggles with CSS at first. It's not you — it's the box model.

⚡ Month 3–4: JavaScript Hit Different

HTML/CSS felt visual and rewarding. JavaScript felt like being handed a book written in a language I'd never seen.

// My first real "aha" moment
const greet = (name) => `Hello, ${name}! You can actually code.`;
console.log(greet("Ashan")); 
// → Hello, Ashan! You can actually code.

The moment functions clicked for me, everything changed. I started building small projects:

✅ A to-do app
✅ A quiz game
✅ A basic calculator

None of them were pretty. All of them taught me something.

🔥 Month 5–6: React & The Real World

React blew my mind. Components, state, props — it felt like thinking in building blocks.

function WelcomeCard({ name }) {
  return (

      Welcome, {name}! 👋
      You're building something real.

  );
}

export default WelcomeCard;

The mental shift from "writing HTML" to "composing UI" was huge.

💡 3 Things Nobody Told Me

1. You will Google everything — and that's completely normal

Senior devs do it too. The skill isn't memorizing syntax. It's knowing what to search for.

2. Build ugly projects first

Pretty comes with practice. Shipping something broken teaches you more than planning something perfect.

3. Your background doesn't disqualify you

It's your superpower story. Developers from non-traditional backgrounds bring perspectives the industry desperately needs.

📊 My Honest Progress Chart

Month	Focus	Feeling
1	HTML basics	🤩 Excited
2	CSS layouts	😤 Frustrated
3	JS fundamentals	😵 Confused
4	JS projects	😤→😊 Getting it
5	React intro	🤯 Mind blown
6	React + Firebase	🔥 Building real things

🚀 What's Next for Me

I'm now diving into:

Next.js — for server-side rendering and full stack apps
Firebase — for auth, databases, and real-time features
AI integrations — because that's where the web is going

The journey is far from over — but I'm proud of how far I've come from that mis-centered div.

💬 If you're starting — what's the hardest thing you've hit so far? Drop it in the comments. Let's figure it out together. 👇

🦈 Pull Shark Automation: Create 62 GitHub PRs/min with Python

Ashan_Dev — Wed, 04 Mar 2026 10:26:40 +0000

🔗 Full source code on GitHub: Pull-Shark-Automation — drop a ⭐ if it helps!

What Is Pull Shark Automation?

Ever wanted to earn the GitHub Pull Shark badge — or stress-test your CI/CD pipelines by generating hundreds of pull requests automatically? Meet Pull Shark Automation, an open-source Python framework built for exactly that.

⚠️ Disclaimer: This tool is for educational purposes only. Use responsibly and in accordance with GitHub's Terms of Service.

GitHub's Pull Shark badge is awarded when your PRs get merged — Default (2 PRs), Bronze (16), Silver (128), and Gold (1024). Doing that manually is tedious. Doing it at 62 PRs/minute? That's automation.

✨ Key Features

Dual execution modes — Sequential (stable) and Parallel (blazing fast, async)
Multi-token rotation — Automatically switches GitHub tokens to stay within rate limits
Proxy support — Built-in proxy scraping and rotation from free sources
Auto-merge — PRs are created and merged without manual intervention
State persistence — Resume from interruptions via state.json
Real-time notifications — Discord & Slack webhook support
Windows compatible — Async operations work cross-platform

🏗️ Architecture Overview

The project is cleanly modularized:

main.py                    # Sequential mode entry point
parallel_automation.py     # Parallel/async mode
git_manager.py             # Git branch, commit, push
github_tool.py             # GitHub CLI wrapper + rate limiting
token_manager.py           # Multi-token rotation
proxy_manager.py           # Proxy scraping & rotation
notifier.py                # Discord & Slack webhooks
logger.py                  # Dual-output logging

The high_performance/ package provides async-first versions of all the above for maximum throughput.

🚀 Quick Start

1. Clone & Install

git clone https://github.com/itxashancode/Pull-Shark-Automation.git
cd Pull-Shark-Automation
pip install -r requirements.txt

2. Authenticate GitHub CLI

gh auth login

3. Configure `config.json`

{
  "repo_path": ".",
  "base_branch": "main",
  "pr_count": 100,
  "delay_seconds": 30,
  "auto_merge": true,
  "dry_run": false,
  "max_concurrent": 10
}

4. Run

# Sequential (reliable)
python main.py

# Parallel (fast)
python parallel_automation.py --count 100 --concurrent 10

# Dry run (test without commits)
python main.py --dry-run

⚡ Performance Benchmarks

Mode	Workers	Tokens	Speed	Time for 1000 PRs
Sequential	1	1	~2 PRs/min	~8 hours
Parallel	10	1	~36 PRs/min	~28 min
Parallel	20	3	~62 PRs/min	~16 min

With 3 GitHub tokens and 20 parallel workers, the tool hit 62.5 PRs/min in real-world testing.

🔑 Multi-Token Setup

Add multiple tokens to github_tokens.json for automatic rotation — each GitHub token supports 5,000 requests/hour, so 3 tokens gives you 15,000+/hour:

{
  "tokens": [
    { "name": "Primary", "token": "github_pat_..." },
    { "name": "Secondary", "token": "github_pat_..." },
    { "name": "Backup", "token": "github_pat_..." }
  ]
}

The TokenManager automatically picks the token with the most remaining requests.

📢 Notifications

Set up Discord or Slack webhooks in config.json to receive live progress updates:

{
  "discord_webhook": "https://discord.com/api/webhooks/...",
  "slack_webhook": "https://hooks.slack.com/services/..."
}

You'll get color-coded alerts for PR creation, merges, failures, and completion summaries.

🏆 Earning Your Pull Shark Badge

Badge	PRs Needed	Recommended Command
Default	2	`python main.py --count 5`
Bronze	16	`python main.py --count 20 --delay 15`
Silver	128	`python parallel_automation.py --count 150 --concurrent 15`
Gold	1024	`python parallel_automation.py --count 1024 --concurrent 20`

🔗 Links

📦 GitHub Repo: itxashancode/Pull-Shark-Automation
🔗 Author: @itxashancode

If you found this useful, drop a ⭐ on the repo and share with devs who love automation!

Have questions or feature ideas? Drop them in the comments below. 👇