Forem: Tawhid

7 Underrated Open Source Tools That Will Actually Make You a Better Developer

Tawhid — Mon, 18 Aug 2025 06:45:03 +0000

We've all heard of the usual suspects: Git, VS Code, Docker. Great tools, but there's also a second layer of tiny open-source tools operating behind the scenes to speed up development, reduce friction, and minimize the day's annoyance. Seven of these are listed below, why you'll find them useful, how to install them in seconds, and a tiny sample to get you productive right away.

1) fzf - the terminal fuzzy finder that actually changes how you navigate

What it is: an interactive Fuzzy Finder for the terminal. Use it to quickly jump between files, command history, git commits, process lists, etc. It’s insanely flexible and integrates with shell workflows and editors.

Why it helps: instead of remembering exact paths or typing find/ls pipelines, you type a few fuzzy characters and fzf finds the result, saves time and cognitive load.

Install (macOS / Linux / Windows with WSL):

# macOS (Homebrew)
brew install fzf
# Ubuntu
sudo apt install fzf
# Or use the installer to enable shell integration
git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf
~/.fzf/install

Quick example: find a file and open it with your $EDITOR:
$ vim $(fzf)

When to use: navigation, interactive filters, quick-selection UIs in scripts. Great with fd, rg, or git commands.

2) bat - a way-better cat with syntax highlighting and Git awareness

What it is: a cat clone that adds syntax highlighting, line numbers and Git modification markers. It makes reading files in the terminal pleasant.
Why it helps: quickly skimming a file in terminal becomes readable; useful in code reviews or when exploring unfamiliar repos.

Install:

# macOS
brew install bat
# Ubuntu (example)
sudo apt install bat

Quick example:

# show file with syntax highlighting and paging
bat src/main.py

Note: some distros name the binary batcat to avoid conflicts - check your package manager. Use in pipelines like bat file | less if you prefer a pager.

3) tldr - documentation that doesn’t make you cry

What it is*: community-driven, simplified examples for common CLI tools. If the man page is a novel, tldr gives you short, copy-paste examples.

Why it helps: ideal when you only need a few common usage examples for a tool (e.g., tar, rsync, openssl) instead of parsing the whole man page.

Install (one of many clients):

# Node-based client
npm install -g tldr
# Or on many systems:
brew install tldr

Quick example:

tldr tar
# -> shows short examples like 'tar -xzf archive.tar.gz' and similar

Tip: there are fast Rust clients (e.g., tealdeer) if you want speed.

4) Glances - one tool to monitor CPU, RAM, disk, network and more

What it is: cross-platform system monitoring tool (top/htop alternative) that consolidates system stats into one dashboard. Useful for dev servers and local performance checks.

Why it helps: when debugging slow builds, flaky containers, or noisy background processes, Glances gives an at-a-glance status without opening multiple tools.

Install (Python-based):

pip install glances
# or use package manager (apt/brew) for system packages

Quick example:

glances
# opens an ncurses dashboard with CPU, memory, disk, network, processes

Pro tip: Glances can run as a web server or export stats to InfluxDB if you want long-term monitoring.

5) HTTPie - an HTTP client that reads like prose (and is great for APIs)

What it is: a human-friendly command-line HTTP client for testing APIs. It formats requests/responses nicely and has intuitively readable syntax. Perfect for quick API testing.

Why it helps: much easier than remembering curl flags when making JSON requests, sending auth headers, or debugging endpoints.

Install:

pip install httpie
# or use your package manager

Quick example:

# GET
http https://api.example.com/users
# POST JSON
http POST api.example.com/users name="Tawhid" email="you@example.com"

6) delta - readable, GitHub-like diffs in your terminal

What it is: a syntax-highlighting pager for git diff/ git show that renders diffs so they’re easier to read (side-by-side, with intra-line highlighting). If you spend time reading diffs, delta pays back minutes every day.

Why it helps: default diffs are hard to parse; delta brings color, clearer context and optional side-by-side rendering.

Install:

# macOS
brew install git-delta
# Or download prebuilt binaries from the releases page

Quick example (config git to use delta):

git config --global core.pager "delta --dark"
git config --global interactive.diffFilter "delta --color-only"

When not to use: if you need raw diffs for scripts, keep the raw output; delta is for human consumption.

7) ripgrep (rg) - the grep replacement that actually respects your repo

What it is: a fast, line-oriented search tool that recursively searches directories while respecting .gitignore. It combines speed with usability for codebases.

Why it helps: faster than many alternatives in realistic developer workflows, and by default ignores binary and hidden files - so your search results are relevant.

Install:

# macOS
brew install ripgrep
# Ubuntu
sudo apt install ripgrep
# Or cargo install ripgrep

Quick example:

# search for function name across project
rg "calculateScore" src/

Notes: ripgrep is not always faster than grep in every single scenario (depends on I/O patterns and arguments), but it’s optimized for common codebase searches.

Big frameworks and IDEs are awesome, but a lot of day-to-day developer productivity comes from small friction reductions: faster search, readable diffs, understandable examples, and clean terminals. These open-source tools aren’t flashy, they’re practical. Invest a few minutes setting one up and you’ll feel the payoff in every subsequent hour of work.

Want a one-line starter pack? Try installing fzf, ripgrep, and bat, you’ll notice the difference the same day. (And if you want, I can generate a dotfiles snippet to wire these together in your shell.)

Why We as Programmers Shouldn’t Use AI Art

Tawhid — Mon, 18 Aug 2025 06:25:59 +0000

AI art is everywhere these days. Type in a prompt, and boom. You’ve got a “masterpiece” in seconds. It feels magical, but also… kind of wrong. And as programmers, I think we should step back and ask ourselves: is this really the kind of creativity we want to support?

Because if anyone understands what it means to create, it’s us.

Code Is Art Too

People outside our world often think coding is just math and rules; cold, logical, robotic. But you and I know that’s not true. Writing good code feels a lot like writing poetry, painting, or composing music. Because, it is just that.

We agonize over function names like a poet over word choice.
We refactor messy blocks of logic the same way a sculptor chips away at stone.
We structure systems so they’re elegant, not just functional, like a designer shaping form and function together.

Code can be beautiful. Code can be art. And if we believe that, then we’re artists too.

The Problem With AI Art

Here’s the thing about AI art: it doesn’t actually create. It doesn’t wrestle with ideas, make mistakes, or carry intention. It just chews up huge amounts of human-made work—art that real people put hours, years, sometimes entire lives into, and spits out something “new.”
It’s basically remixing without asking. And if you’ve ever had someone rip off your code without credit, you know how bad that feels. Now imagine that happening on a global scale to entire communities of artists.

We Should Get It More Than Anyone

As programmers, we’ve been there. We know the difference between throwing together spaghetti code and carefully crafting something that’s a joy to use and maintain. We know what it feels like to build something from scratch and feel proud of it.

That’s the same pride artists have in their work. And just like we’d hate to see our craft treated as disposable or easily replaced, they deserve the same respect.

So What Do We Do?

I’m not saying AI tools are evil. They can be fun, even useful. But when it comes to art, we should think twice. If the tool is built on the unpaid labor of thousands of creators, maybe that’s not something we want to normalize.

Because at the end of the day, we’re artists too. And artists should have each other’s backs.

If we really believe code is art, then we should treat other forms of art, and the people behind them, with the same respect we expect for ourselves.

What tech stacks do you guys use ?

Tawhid — Sat, 02 Aug 2025 05:12:14 +0000

I asked this question a few years ago, but while revisiting my old blog posts, I got curious again: what tech stacks do you use for web development these days?

The Rise of "Objective" Opinions in Tech Content, And Why You Should Care

Tawhid — Mon, 28 Jul 2025 20:41:34 +0000

Development is a craft. Think like a developer, not a follower.

"Never use Redux again."
"React is dead, switch to SolidJS."
"Here's why this framework will double your productivity."
Sound familiar?

If you've been surfing the web, YouTube, dev.to, or Medium lately, you've probably read headlines such as these delivered with the assurance of gospel truth. The line between subjective experience and objective truth is increasingly blurred on a daily basis, especially in the field of programming content.

Let’s talk about that.

When Opinions Masquerade as Facts

The online dev community is full of passionate people. Fortunately. Passion has a tendency to be redefined as truth, though, especially when one's got something to sell - be it a blog, a camera, or a product.

“I didn’t like X in my last project.”

Becomes:

“X is a terrible tool. Don’t use it. Ever.”

It is fine to hate a tool. But when writers, especially professional developers, influencers, and content creators, set forth these stances without context, nuance, or caveat, they accumulate to dogma in technology. It fosters a culture of "right" vs. "wrong" in doing it this way, rather than just working with trade-offs.

YouTube: The Home of Overconfident Hot Takes

YouTube is packed with informative dev content, but it's also full of videos like:

"You’re still using Node.js? You’re doing it wrong."
"Tailwind is garbage — here’s why I never use it."
"Stop using Express.js in 2025."
Are these inherently wrong? Not necessarily.
But most of the time, they’re clickbait-heavy and experience-poor. You’ll often find:
Junior devs or career switchers repeating opinions they read somewhere else
Bold claims that lack benchmarks, context, or industry usage stats
Videos that tear down a tool just to promote another one (often with an affiliate link.)

These videos tend to oversimplify complex decisions and overcomplicate simple decisions, choosing a framework, API style, or hosting solution, into black-and-white answers.

Blogs: When Content is Just a Sales Pitch

Let’s talk about developer blogs: including big platforms like dev.to, Hashnode, or Medium.

There’s a growing trend of posts that look like tutorials, but are really covert product plugs. Some examples:

A "guide" on building authentication... that just happens to be all about this new API-as-a-Service.
“Why we moved from X to Y” blog posts… that just happen to be written by an employee at Company Y.
“Top 5 JavaScript tools you need in 2025” — 3 of which are made by the same company, and all have paid tiers.

This isn't inherently bad, developers need to make money, and tools need exposure.
But transparency matters.
If you're promoting a tool, say so.
If you're writing a tutorial, don’t bury three affiliate links and pretend it’s a neutral recommendation.

Why Does This Matter

Junior developers get confused.
When someone’s new, they often don’t know how to filter hype from reality. A post saying “Don’t ever use React Query” might scare someone off a perfectly good tool because the author didn’t like the docs.
We stop learning how to think critically.
Part of being a good developer is learning to weigh trade-offs. When content is all about absolutes, we lose that habit.
The ecosystem becomes more about narrative than facts.
Some tools get hyped to death (hi, Bun), while stable, boring solutions (hi, Express) get dumped on, even if they work just fine.

What You Can Do

Whether you’re consuming or creating content, here are a few simple ideas:

Read critically
Ask: What’s the author’s experience? Are they using real examples? Do they explain the trade-offs?
Beware of strong claims
If someone says “X is better than Y” — ask, in what context? For what use case?
Look for discourse, not dogma
Good tech content welcomes disagreement. Bad content shuts it down.
Reflect your bias (if you’re writing)
If you love SvelteKit, awesome. Say that. But don’t pretend it’s “objectively” better than Next.js unless you’ve tested both deeply.

Wrapping Up: More Nuance, Less Noise

Tech isn’t a religion. It’s a craft.
We need more humble opinions, more curiosity, and less shouting from digital rooftops.
Because the truth is: most decisions in software are subjective.
And that's okay.
So next time you see a bold claim in a video or a post, take a breath.
Ask questions. Look for context. Read the comments (okay, maybe not YouTube’s ).
Think like a developer, not a follower.

Brainfuck in a nutshell. (and Why Would You Want to Learn It)

Tawhid — Mon, 28 Jul 2025 18:23:09 +0000

So you know Python, JavaScript. and then some guy leaned over and said: "Brainfuck."
You laughed. You thought that it was a joke.
Well, it is true.

And yes the name is 100% intentional.

What is Brainfuck?

Brainfuck is a Turing-complete esoteric programming language created by Urban Müller in 1993.
It's as hard to use as humanly (and technically) possible yet still technically able to do anything any other language can do (with a lot of time, patience, and possibly a few tears).

It's not used to create websites or apps. It's more of a puzzle, a logic gym for brains.

How Does It Work?

If you have:

A line of memory cells that's very long (like a line of small boxes, all set at 0)
A pointer that moves left or right across these boxes
And 8 commands to interact with them

Symbol	What it does
`>`	Move pointer to right
`<`	Move pointer to left
`+`	Increment current cell by 1
`-`	Decrement current cell by 1
`.`	Print the ASCII character at current cell
`,`	Input a character; store it at current cell
`[`	If current cell is 0, jump past matching ]
`]`	If current cell is not 0, jump to matching [

That's all. No functions, no variables, no comments. Pure, keyboard-bashing chaos.

Your First Brainfuck Program: Hello, World!

Here’s the classic "Hello, World!" in Brainfuck:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

What does this do?
Uh… don’t ask.
But here's a breakdown of just the first part to give you a feel:

++++++++++        // set cell #0 to 10
[                 // start loop
 >+++++++         // move to cell #1, add 7
 >++++++++++      // move to cell #2, add 10
 >+++             // move to cell #3, add 3
 >+               // move to cell #4, add 1
 <<<<-            // move back to cell #0, subtract 1
]                 // loop until cell #0 is zero

It's like attempting to eat soup with a screwdriver. Not intended for the purpose, but worth a look.

Why Learn Brainfuck?

Sincerely? You most likely won't require it. But here's why you might consider it:

Puzzle Addicts: Sudoku in Morse code. Aside from it could be your secret language ;-p
Brain Gymnastics: It gets you thinking bottom-up, like loops and memory from the ground up.
Wow Your Nerd Friends: Build a full program using only + and >, and others will wonder.
Get a Deeper Understanding of Computers: You'll get a sense of how computers really work at a far deeper level.

Try It Out (No Setup Required)

You may run Brainfuck code in your browser using one of the following:

copy.sh
Dcode.fr Brainfuck Interpreter
Or just Google “Brainfuck online interpreter”, they’re everywhere
Paste in the Hello World example and hit run. Boom, you’re a Brainfuck developer now. And then add it on your LinkedIn resume!

Final Thoughts

Brainfuck is not about practicality.
It's simply a matter of flexing your brain, playing around with code, and chuckling at how silly things get.
If you are bored, curious, or just want to flex, give it a shot. You will not create the next monstrous app in it, but you will certainly get your low-level stripes.

Why You Should Try Coding In Rust.

Tawhid — Mon, 28 Jul 2025 05:54:19 +0000

If you have spent any time surfing dev Twitter, Github, or any Reddit thread that involves modern programming, you have probably encountered Rust many times. No I am not talking about rust the metal corrosion (but the folks with expertise with Rust will tell you that these memory bugs are equivalent to corrosion). We are talking about the programming language Rust that has been rapidly gaining momentum in software (mostly quietly, and sometimes not so quietly).

What is the deal with Rust? What's with Google, Microsoft, and even parts of the Linux kernel beginning to bet on Rust? Let's have a look into it.

Rust: Safety with No Tradeoffs

Rust is all about safety, its big selling point is that it allows you to write hyperfast code without the perilous bugs associated with C and C++, particularly memory management bugs such as null pointer dereferencing, buffer overflows, and use-after-free bugs.

How does it do that? Enter the borrow checker. You can think of it as Rust's super strick librarian trying to make sure your variables aren't getting accessed in a way that makes your code crash or choke itself a bit. Is it annoying at first (and trust me as a new Rustacean, I do know), but ultimately you will turn that annoyment into livelihood writing Rust code.

Zero-Cost Abstractions

Normally you have to choose. Low-level control or a high-level convenience. Rust says "Why not both?"

Rust provides you with a lot of features such as pattern matching, traits, enums, and an extremely expressive type system at no performance cost! The compiler is smart enough to drop all the fluff so the end resulting binary is surprisingly lean and mean.

This means that Rust is good for system programming (operating systems, embedded devices), but also for web services, game engine, etc.

A Real-World affection

Let’s talk about adoption. This isn’t just a playground for language nerds anymore:

Mozilla created Rust and used it in Firefox’s rendering engine (Servo).
Microsoft is exploring Rust for writing secure system components in Windows.
Amazon is backing Rust through AWS and using it to build scalable, efficient infrastructure.
The Linux Kernel: that 30-year-old codebase, is slowly adding Rust support. If that’s not a vote of confidence, I don’t know what is.

Why Devs Are Switching

Here’s what draws developers to Rust:

Memory safety without garbage collection (no runtime surprise costs)
Great tooling (Cargo is probably the best package manager/build tool combo out there)
Friendly, helpful community (check out users.rust-lang.org or the Rust subreddit)
Fantastic documentation (the Rust Book is basically a masterclass)

But let’s be honest, the learning curve can be steep. Rust makes you think about your code. Ownership, lifetimes, and borrowing are a different beast. But once it clicks? You’re writing code that’s safe, fast, and often surprisingly elegant.

What’s Next?

Rust won't just fade away. With large tech companies covering it, a dedicated community, and proven world success stories, it is on track to be a real player in systems and application development.

Only you can decide whether you are a grizzled C++ veteran tired of dangling pointers or a high level Pythonista that wants to write something that is faster than a caffeinated squirrel, but either way you should give Rust a look.

You can try Rust out right now with nothing to install. Just go to and start playing. The community also recommends checking out The Rust Book. It is completely free, well written, and highly useful.

Final Thoughts

Rust is not perfect. It can be maddening at first. But it can also be liberating. Rust forces you to write better code, consider safety, and produce software that does not blow up in production.

Why not give it a try? The worst thing that will happen is that you walk away with a different outlook on memory. The best thing that can happen? You will become one of the cool kids writing really good systems code in Rust.

Why Everyone Is Talking About Edge Functions

Tawhid — Sun, 27 Jul 2025 04:56:38 +0000

This year there has been a huge buzz in the world of modern web development with edge functions, edge computing or more awkwardly phrased as "running your code at the edge."

It's not some new punk band. It's the next phase in how we build fast, scalable applications and it isn't hype.

So, what are edge functions? Why should you care? And how do they fit into modern stacks?

First, What Is the Edge?

In the traditional model, when someone requests your app, it hits a centralized server, sometimes in Virginia, and sometimes in Germany, or California, or an enormous AWS data center half a world away in a different timezone.
And that's all okay. But you're in Tokyo and your server is in New York City - that's going to be a pretty big physical distance. And even if you're on fast internet, you've got latency to account for.
The edge is about running your code on servers that are as physically close to your users as possible. Instead of having one origin server - you're deploying to lots and lots of little servers around the world. The benefit? Reduced latency, faster response times, and happy users.

So... What Are Edge Functions?

Edge functions are like mini serverless functions that run at those edge locations. Think:

Middleware logic
Authentication checks
A/B testing
Personalization
Redirects, rewrites
Low-latency APIs

They’re small, fast, and often run in lightweight environments like V8 isolates, not full Node.js processes. This means they spin up quickly and run with minimal cold start.

Popular platforms supporting edge functions include:

Vercel Edge Functions
Cloudflare Workers
Netlify Edge Functions
Deno Deploy
Bun (experimental edge support)

Why Are They a Big Deal?

Let’s break down why edge functions are such a modern dev darling:

Speed Matters
The closer your logic runs to your user, the faster your app feels. We're talking milliseconds saved on every request. That adds up, especially for global apps.
Dynamic Logic Without a Heavy Server
You can run logic like authentication or header manipulation without needing a full server. It’s like CDN rules, but on steroids.
Scalability by Default
No need to think about traffic spikes or managing infrastructure. Edge functions scale globally and automatically, just like serverless.
Plays Well With Modern Stacks
Edge functions fit naturally into JAMstack and headless architectures. They’re great when paired with static sites and APIs, letting you add just the right amount of dynamic behavior.

What Edge Functions Are Not Great At

Let’s be real: edge functions aren’t a silver bullet.

Cold starts still exist, though they’re faster than traditional serverless.
No file system: Most edge environments are sandboxed, no reading/writing to disk.
Limited runtime: Many edge providers don’t support full Node.js. That means no native modules or heavy server-side logic.
Memory & execution time caps: They’re built for small tasks, not running a whole backend.

In short, edge functions are great for lightweight, latency-sensitive tasks, not your whole monolithic app.

Should You Use Them?

If you’re building a modern web app, especially one with a global audience, edge functions are worth exploring. They're perfect for:

Running authentication logic at the edge before hitting your backend
Serving geo-personalized content
Speeding up routing decisions
Rate limiting
Feature flag evaluation

Start small. Try using one for middleware. See how it affects performance. The tooling has gotten really developer-friendly in the last couple years.

Edge functions are one of those “sounds cool, but do I need it?” tools. But once you start to see them in action, particularly in combination with static files or headless CMS's: they begin to feel like magic.

Let me know if you would want a follow-up post with hands-on examples (like building an auth layer at the edge or using Cloudflare Workers for caching tricks).

Why Git is So Hard to Learn (and Why You Should Learn it Anyway)

Tawhid — Sun, 27 Jul 2025 04:39:42 +0000

To be clear: Git is confusing! Nobody picks up git and immediately feels like a wizard. If you're someone who has ever looked at your terminal and asked yourself what the hell "detached HEAD" means, you are definitely not alone.
But, Git is worth the pain. Once you get a handle on it, Git can be one of your most powerful tools as a developer. The important part is to know why it feels weird in the beginning.

Git Doesn’t Work Like Other Tools

Most tools do one job and do it simply. Git, on the other hand, is like a Swiss Army knife duct-taped to another Swiss Army knife. It tracks versions, coordinates collaboration, manages history, branches reality... and expects you to understand how all those parts fit together.
And unlike DropBox or Google Docs, Git does not give you a nice UI with who changed what. You get a command line, lots of arbitrary logs, and you figure out refs, trees, blobs, and commits.

So yeah. It's not you, it's Git.

The Mental Model Is The Difficult Part

Once you grasp the fundamentals, Git really starts to come together.

Think of Git as a really cool key-value store, because every commit is merely a point in time or a "snapshot" of your code, and that is precisely how Git will be storing these snapshots; as objects. The objects are related by the hashes, not by the file names. So, if you rename the file, it literally doesn't matter, because git doesn't care about names, it cares about content.

And branches? They’re just pointers. Tags? Also pointers. HEAD? Just a pointer to the pointer. Once you wrap your head around this, it stops feeling like magic and starts to feel like... well, still weird, but less scary.

You Will Mess Up

Everyone messes up in Git. You will push to the wrong branch. You will merge something by accident. You will panic when your files disappear after a reset.

But here’s the upside to it all: Git is pretty hard to break. You can usually revert almost anything. This is why you have a few options like reflog, reset, and checkout. Even better, as you break things, you will become more assured of how to fix things.

Real-Life Git Advice

Here’s some advice that helped me:

Start with a GUI, tools like GitKraken, Sourcetree, and the Git panel in VS Code really make it clearer when you're getting started. But then transition to the terminal slowly.
Learn the basic commands: clone, add, commit, push, pull. You should really get those down cold.
Branching is cheap, so take advantage of it and branch often to experiment.
Pay attention to the error messages. Git's error messages are long and sometimes verbose, but they usually indicate what went wrong.
Don't be afraid of rebase, but also don't use it blindly. Know how to rebase, and what you should be rebasing versus merging.
Use git status all the time. It's your best friend, I promise.

Why It's Worth It

If you're working with code, you're working with Git. Whether you’re solo or on a team of 100, version control is non-negotiable. And Git, for better or worse, is the industry standard.

Once you get comfortable with it, you’ll find yourself doing things like:

Fixing a bug from three months ago with one cherry-pick
Squashing messy commits before a pull request
Debugging a production issue by bisecting your commit history
Resolving merge conflicts without breaking a sweat

That’s the kind of power that Git gives you. It's not flashy, and it's not easy at first. But it’s absolutely worth learning.

Debugging MATLAB Scripts Like a Pro: Common Mistakes and How to Fix Them

Tawhid — Fri, 25 Jul 2025 19:02:12 +0000

Let's be frank: if you have written more than two MATLAB scripts in your life, you have probably encountered that dreaded error message way more than you want to admit. You write some code, hit Run, and then BAM! Nothing is working, and no error has been issued.

The good news is that debugging things in MATLAB does not always have to be painful. After you figure out what you are looking for, it can actually be somewhat fun. So let's go through some of the most common errors that control engineers (and students) make while programming in MATLAB, as well as some possible ways to fix them without having a meltdown.

1. Not Preallocating Arrays

This is a typical new user error. You write a for-loop that builds a vector or matrix, and MATLAB gets real slow on you, but there is no error message; just bad performance.

for i = 1:1000
    x(i) = i^2;
end

Technically, this works. But MATLAB has to resize the array on every loop iteration, and that gets expensive fast.

Fix it like this:

x = zeros(1, 1000);  % Preallocate
for i = 1:1000
    x(i) = i^2;
end

Pro tip: If your script feels slower than it should be, check for growing arrays inside loops.

2. Using `=` Instead of `==` in Conditionals

This one’s sneaky. You write an if statement and accidentally use = (assignment) instead of == (comparison).

if x = 5
    disp('x is 5');
end

MATLAB throws a syntax error immediately, but it’s still one of the most common logic bugs.

Fix:

if x == 5
    disp('x is 5');
end

Remember: = assigns a value. == checks for equality.

3. Forgetting to Clear Old Variables

MATLAB holds onto variables between runs. So if you define something once, it can stick around and mess with your next script, especially if variable names overlap.

Let’s say you defined a variable called n in one script and forgot about it. Now it’s interfering with a for loop that also uses n.

Fix:

Start your scripts with a clean slate.

clear all; clc;

Or, better yet:

clearvars; clc;

This clears the workspace without removing breakpoints.

4. Indexing from Zero

If you're coming from Python, C, or JavaScript, you're used to arrays starting at zero. Not in MATLAB. Here, array indexing starts at one.

x = [10 20 30];
disp(x(0));  % This will throw an error

Fix:

disp(x(1));  % First element

This mistake is especially common if you’re switching between languages.

5. Mismatched Matrix Dimensions

You try to multiply two matrices and MATLAB flips out about incompatible dimensions.

A = [1 2; 3 4];
B = [5 6];
C = A * B;  % Error

Fix:

Double-check dimensions with size() before you do any matrix math.

size(A)  % Returns 2x2
size(B)  % Returns 1x2

% Maybe you meant:
C = A * B';  % Transpose B to 2x1

If you're doing a lot of matrix math, make size() and ' (transpose) your go-to tools.

6. Not Using the Debugger

If you're adding 20 disp() calls just to figure out what's going wrong, there's a better way. Use MATLAB’s built-in debugger.

You can:

-Set breakpoints by clicking the margin next to a line number.
-Step through the code line by line.
-Inspect variable values as you go.
Or, drop this line into your code to pause execution:

keyboard

Once paused, you can run commands in the Command Window to investigate.

Trust me. Once you use the debugger, you'll never go back to printing everything manually.

7. Calling Functions That Don’t Exist

You call a function and get this lovely message: Undefined function or variable. This usually means:

You forgot to add the file to your path.
You misspelled the function name.
You're calling a function that was deleted or renamed.

Fix:

Use the which command to see where MATLAB is looking.

which myFunction

If it says 'not found', you probably need to:

Fix the name.

Add the file’s directory using addpath.

Or double-check the function exists at all.

Final Thoughts

MATLAB can be a little quirky, especially if you’re switching between other languages or just starting out. But once you understand these common pitfalls, debugging becomes way less painful.

To recap:

Preallocate your arrays.
Use == for comparisons.
Clear your workspace often.
Index from one.
Always check matrix sizes.
Use the debugger.

And make sure your functions are where MATLAB expects them to be.

Once these habits stick, you'll find that debugging actually becomes kind of fun. Like solving a puzzle. A frustrating, algebra-covered puzzle, but still a puzzle.

Got your own MATLAB horror story? Drop it in the comments. Misery loves company.

Happy scripting.

Create a GOOD game as a beginner

Tawhid — Tue, 22 Jul 2025 07:29:40 +0000

This guide is tailored towards Unity 3D but you can use them for other engines as they are pretty much general.

Creating a good game as a beginner using Unity is less about ambition and more about clarity, scope, and structured execution. Unity is a robust and versatile engine that, when used methodically, allows even novice developers to build high-quality games. This guide breaks down the essential components of making a good game as a beginner, avoiding generic advice and focusing strictly on Unity-specific, actionable steps.

1. Start with a Focused Game Concept
Avoid large-scale ideas. Instead, choose a narrowly scoped mechanic and expand only when it is functional. Examples include:

A 2D top-down shooter with one enemy type and one weapon.

A single-level puzzle platformer with a jump and switch mechanic.

A basic clicker game that increments score and introduces timing.

Why this matters in Unity: Unity projects scale quickly in complexity due to its component-based architecture. Limiting scope keeps inspector hierarchies and script dependencies manageable.

2. Use Unity’s Built-in Tools Over Third-Party Assets
Unity provides several mature systems out of the box:

Input System: Start with the old Input Manager (Input.GetKey, Input.GetAxis) before adopting the new Input System. The old system is easier to prototype with.

Tilemap Editor: For 2D games, Unity’s Tilemap tool speeds up level design.

Animator Controller: Avoid external animation tools early. Use Unity’s Animator with blend trees and state machines for simple animations.

This avoids dependency hell and keeps build size and performance in check.

3. Scene Management and Prefabs
Break game logic into manageable pieces:

Use prefabs extensively. Every enemy, projectile, pickup, and UI element should be a prefab. This allows for scalable instantiation and reuse.

Utilize ScriptableObjects for shared data (e.g., weapon stats, enemy configurations) without requiring scene references.

Unity’s prefab workflow lets you decouple scene logic from game logic, improving modularity.

4. Leverage Unity’s Debugging Tools
Good games don’t just run; they run predictably. Unity has built-in tools to help:

Console Debugging: Use Debug.Log, Debug.LogWarning, and Debug.LogError with context objects.

Gizmos: Use OnDrawGizmos() to visualize raycasts, detection ranges, and waypoints directly in the Scene view.

Profiler: Don’t wait for performance problems. Profile early. Avoid Update() methods in every script—use managers or events instead.

These tools help ensure functionality behaves consistently across test runs.

5. Implement a Simple Game Loop Early
The core game loop should be functional as soon as possible:

Title screen → gameplay → win/lose condition → restart.

Use Unity’s SceneManager.LoadScene() for transitions.

Keep global managers (e.g., score, lives, settings) on a persistent singleton object via DontDestroyOnLoad.

This ensures your project is playable from start to finish, which is essential for iteration and feedback.

6. Build Custom Editors Only When Necessary
Unity’s editor extension capabilities are powerful, but building custom inspectors or windows is unnecessary for most beginner projects. Instead:

Use serialized fields with [SerializeField] and custom tooltips.

Group fields logically using [Header], [Space], and [Range].

Editor scripting can become a distraction unless it solves a direct bottleneck.

7. Use Version Control from Day One
Avoid losing progress due to broken prefabs or scene files. Even for solo projects:

Use Git with a .gitignore tailored for Unity (available on GitHub).

Commit before major changes. Unity YAML files are text-based, so changes are trackable.

This keeps your project maintainable and reduces the fear of experimentation.

8. Optimize for Device Early, Not Late
If you're targeting mobile or WebGL:

Test performance on target hardware early. Unity’s editor performance is not indicative of build performance.

Reduce draw calls: use sprite atlases, static batching, and combine meshes where feasible.

Use object pooling for frequently instantiated objects like bullets or enemies.

Unity’s Application.targetFrameRate and Quality Settings allow tuning for platform-specific needs.

9. Avoid Feature Creep Through a Defined Feature Lock
Before adding anything new, ask:

Does it support the core mechanic?

Can I build and test it in under 2 days?

Will it create UI or system dependencies that complicate other systems?

This protects your Unity project from growing beyond your current technical ability.

10. Polish with Small Details, Not Systems
A good beginner game feels finished, not because it has many systems, but because the existing systems feel deliberate:

Add particle effects using Unity’s VFX Graph or ParticleSystem to make actions feel impactful.

Use audio sources with spatial blending and reverb zones.

Smooth camera movement with Lerp or Cinemachine.

Focus on player feedback loops. Simple effects add clarity and professionalism without code bloat.

Unity allows beginners to create good games, but the key is discipline, not ambition. Use the engine as it is intended, lean into its component-based design, and stay within a narrow scope. A well-executed 2D game that runs smoothly and finishes cleanly will always outshine an unfinished attempt at a 3D open-world RPG. Start with completeness, not complexity.

50+ Tips For Big Games in Unity

Tawhid — Fri, 18 Jul 2025 04:19:36 +0000

Ever tried to create an ambitious game only to be met by a thousand setbacks ? Don't worry it happens. In fact this list is compiled from my own experience building horror games in unity(painful memories). This are for the versions unity LTS 2023 and previous but is not limited to them and applies to unity 6 as well. I hope it was worth a read, enjoy :)

Planning & Project Architecture

1. Always create a GDD first.
A Game Design Document (GDD) is your blueprint. Include story drafts, pseudo code, environment design, post-processing ideas, everything. It keeps you grounded. I personally use notion for that.

2. Always plan your target platform.
PC? Console? Mobile? VR? Everything from UI scaling to shader complexity hinges on this decision.

3. Decide on your render pipeline early.
URP, HDRP, or Built-in. Each has pros and cons. Switching mid-project is painful, and also later on, you may realize that your project is too complex for that certain pipeline but too broad to change, so plan carefully.

4. Prototype first, optimize later.
Get the gameplay right before sweating performance. Because, later on, you will need to reoptimize again anyways.

5. Never render what the player can't see.
Use occlusion culling, cull distances, and smart camera frustums, fog to hide stuff far away.

6. Break down logic into manager scripts.
GameManager, AudioManager, UIManager, etc. Modular systems scale better.

7. Use version control.
Git, Plastic SCM, or Perforce, use something with at least 100GB of storage. You'll thank yourself later. And also get an UPS, because electricity can go out anytime, and unity corrupts itself when suddenly closed. So get yourself an asset that autosaves!

8. Functionalize everything.
Keep logic modular. Reference shared systems, don’t duplicate them.

9. Document your code in the GDD.
Track your systems, variables, and data structures alongside your design. Trust me, it WILL pay off. You are a human, today you know everything about your code, tomorrow you will be confused as hell. Granted that code should be self documented, having an external documentation helps too.

10. Use ScriptableObjects for shared data.
They're ideal for configuration, global state, and shared resources without hard references.

Code Architecture & Performance

11. Don’t overuse singletons.
Limit them to essential systems, and keep logic out of them.

12. Separate core logic from UI.
UI should reflect state, not control it. At best, assign runtime references for buttons.

13. Use the Addressable Asset System.
Especially for large projects. It’s efficient, modular, and memory-friendly.

14. Organize your project folders early.
Structure matters: Scripts/, Prefabs/, Audio/, Art/, Scenes/.

15. Async load big scenes and assets.
Prevent hard freezes by using SceneManager.LoadSceneAsync() or Addressables.

16. Profile early and often.
Use Unity Profiler, RenderDoc, or external tools regularly. And watch out for every thread !

17. Use nested prefabs.
Makes your systems modular, reusable, and scalable.

18. Never animate UI directly on GameObjects.
Use DOTween or Unity’s Animator for flexibility and polish.

19. Pick your input system early.
Switching between the legacy Input and the new Input System mid-project is painful. And Both input systems aren't ideal for phones. So my recommendation is to use the newer one, if you're planning on multi-platformed games.

20. Avoid FindObjectOfType() in runtime.
Use serialized fields, dependency injection, or event systems. Why? Because they are mad expensive to run.

21. Use event-driven architecture.
UnityEvents, C# delegates, or custom event buses keep your code modular.

22. Set up physics layers and a collision matrix.
Do it from day one to avoid debugging chaos later.

23.Keep FixedUpdate() lean.
It’s for physics, don’t clutter it with heavy logic. It impacts performance badly.

24. Use object pooling.
For bullets, blood splats, enemies, etc. Avoid instantiate/destroy hell.

25. Don’t hardcode references.
Use ScriptableObjects, serialized fields, or managers to handle resources like audio clips.

Content, World, and Performance

26. Implement localization early.
Retrofitting it later is a nightmare. Unity's localization package helps.

27. Use gizmos for in-editor debugging.
AI ranges, vision cones, nav paths, etc just draw them.

28. Use logs, but don’t rely only on Unity Editor.
Implement on-screen logs or console toggles for builds.

29. Avoid MonoBehaviour bloat.
Large classes are hard to debug. Keep responsibilities separated.

30. Understand Unity’s garbage collection.
Watch out for allocations from string operations and LINQ. Use object pooling where needed.

Advanced Systems & Optimization

31. Bake lighting for static geometry. Use light probes for dynamic objects.
This gives you the best performance and visual fidelity mix.

32. Divide large scenes into loading zones.
Use additive scenes or addressables for seamless streaming.

33. Manual occlusion for dynamic content.
Unity’s occlusion only works for static objects. Use frustum checks or portals for the rest.

34. Bake navmesh per scene. Use links for transitions.
This allows AI to transition between areas cleanly.

35. Build a custom audio system.
For horror, layer ambient loops, whispers, distant cries, and stingers. Audio is 70% of fear.

36. Use post-processing volumes for mood shifts.
Transition colors, fog, exposure per room or area.

37. LOD logic for non-visual elements.
Disable scripts, triggers, and AI systems far from the player.

38. Use tags/layers wisely in AI.
Detect “Player” or “SoundSource” with custom logic instead of brute-force raycasts.

39. Create a persistent “Manager Scene.”
Game state, UI, audio, and input all live here. Load game levels on top of it.

40. Simulate memory pressure during testing.
Force GC, simulate low-end hardware, and test worst-case scenarios.

AI, Horror Systems, and Tools

41. Visualize AI logic.
Use rays, gizmos, or debug UIs to show what AI sees, hears, or targets.

42. Build a robust save/load system.
Don’t just save position! track doors, enemies, notes, and more. Serialize with JSON or binary.

43. Create an event queue system.
Chain scares, animations, and sequences across scenes with reusable logic.

44. Separate physics layers for enemies and players.
Allows fine control over interactions like footsteps, traps, or triggers.

45. Use real-time reflections sparingly.
Mirrors, blood puddles? yes. Everywhere else? no. Use baked probes for everything else.

46. Compress textures intelligently.
Use mipmaps and Crunch compression to save memory, especially on detailed horror assets.

47. Use custom shaders and contact shadows.
Creepy lighting, fake subsurface scattering, or screen-space effects all boost horror atmosphere. And also use decals for shadows, less expensive and good visual results.

48. Log or simulate player behavior.
Record test sessions to improve pacing, scare timing, and level layout.

49. Bundle environmental effects together.
Avoid chaos when a scare triggers. Group sound, light, camera shake into a timed package.

50. Build internal tools to speed up workflow.
Editor scripts for placing lights, randomizing props, or testing paths will save days. For example, I built editor tools to advance through quests and acts to playtest faster.

Some additional tips:

Always use simplified colliders like box, sphere, capsule instead of mesh colliders unless needed.
Always use simplified materials like simple lit instead of standard lit or complex lit.
Realtime Lighting shouldn't be used unless you need light that needs to be turned off or on at some point.
Your game is more prone to be gpu intensive than cpu, so debug accordingly.
Use shader graphs and vfx graphs as they run on the gpu and take less resources
Have people playtest your game but not actual players, as it may impact their impression.
If you want to release on ios but don't have a mac or enough money to pay for unity cloud, then run mac os on VMWare, Virtual Box and compile your game there after exporting from unity. (indie dev core)

If you made it this far, thank you. These tips come from many hours (and sleepless nights) building large Unity games, especially in the horror genre. Hopefully, they save you some pain and help you build better, smarter, and faster.

You can check out my free beta horror game which I made in last two months.

Got your own tips or horror dev stories?
Drop them in the comments. We’re all in this haunted house together.

Why Vibe coding is the best and we are wrong

Tawhid — Wed, 23 Apr 2025 01:01:39 +0000

(PS. I'm just trolling)
Ah, "vibe coding"! It's got a certain ring to it, doesn't it? While it might not be a widely recognized term in the traditional coding world, the essence of what I think you're getting at – the intuitive, almost artistic approach to development – is definitely something we could all benefit from embracing more. Perhaps we are sleeping on the power of the "vibe" in coding.

Let's be honest, when we think of coding, images of rigid syntax, logical structures, and meticulous debugging often come to mind. And those are undeniably crucial. But what about the flow state? The moments when the code seems to write itself, when you're deeply connected to the problem and the solution emerges almost organically? That's the "vibe" I suspect you're talking about.

Think about it: some of the most elegant and innovative solutions in software development didn't necessarily come from strictly following a textbook. They arose from a deep understanding of the problem, a creative leap, and an almost intuitive feel for how the pieces should fit together. It's about more than just knowing the rules; it's about feeling the rhythm of the code.

Here's why tapping into this "vibe coding" can be so powerful:

Unlocking Creativity: When you're not solely focused on adhering to every single rule by the book, your mind opens up to more unconventional and potentially brilliant solutions. You start to see connections you might have missed otherwise.
Boosting Intuition: As you gain experience, a certain intuition develops. You start to anticipate potential problems and see patterns more readily. "Vibe coding" encourages you to trust this intuition and explore ideas that might not be immediately obvious through pure logic.
Enhancing Flow: That coveted state of flow, where time seems to melt away and productivity soars, is often fueled by this intuitive connection to the code. When you're "in the zone," you're essentially operating on a powerful creative and intuitive wavelength.
Creating More Elegant Solutions: Code written with a good "vibe" often feels cleaner, more concise, and more maintainable. It's as if the very act of intuitive creation leads to a more harmonious structure.
Increasing Enjoyment: Let's face it, coding can sometimes feel like a slog. But when you're tapping into that creative flow, it becomes a much more enjoyable and fulfilling process.
Now, I'm not suggesting we throw all best practices out the window and just "wing it." That would be chaos! "Vibe coding" isn't about abandoning logic; it's about integrating intuition and creativity alongside established principles. It's about finding that sweet spot where technical expertise meets artistic expression.

So, how do we cultivate this "vibe"? It's not something you can simply switch on, but here are a few thoughts:

Deeply Understand the Problem: The more you truly grasp the nuances of what you're trying to solve, the more your intuition can guide you.
Experiment and Play: Don't be afraid to try different approaches, even if they seem a little unconventional at first. Sometimes the most unexpected paths lead to the best discoveries.
Trust Your Gut (to a point): As you gain experience, learn to recognize those moments when your intuition is guiding you towards a promising solution.
Step Away When Stuck: Sometimes, the best way to find the "vibe" is to take a break and let your subconscious work on the problem.
Embrace the Iterative Process: Coding is rarely a linear process. Allow yourself to explore, refactor, and refine your code until it feels right.
Perhaps "vibe coding" isn't a formal methodology, but it represents a powerful aspect of the development process that we often overlook. It's about acknowledging the role of intuition, creativity, and flow in crafting elegant and effective solutions. Maybe it's time we all started tuning into that "vibe" a little more. What do you think?

Forem: Tawhid

7 Underrated Open Source Tools That Will Actually Make You a Better Developer

Why We as Programmers Shouldn’t Use AI Art

Code Is Art Too

The Problem With AI Art

We Should Get It More Than Anyone

So What Do We Do?

What tech stacks do you guys use ?

The Rise of "Objective" Opinions in Tech Content, And Why You Should Care

When Opinions Masquerade as Facts

YouTube: The Home of Overconfident Hot Takes

Blogs: When Content is Just a Sales Pitch

Why Does This Matter

What You Can Do

Wrapping Up: More Nuance, Less Noise

Brainfuck in a nutshell. (and Why Would You Want to Learn It)

What is Brainfuck?

How Does It Work?

Your First Brainfuck Program: Hello, World!

Why Learn Brainfuck?

Try It Out (No Setup Required)

Final Thoughts

Why You Should Try Coding In Rust.

Rust: Safety with No Tradeoffs

Zero-Cost Abstractions

A Real-World affection

Why Devs Are Switching

What’s Next?

Final Thoughts

Why Everyone Is Talking About Edge Functions

First, What Is the Edge?

So... What Are Edge Functions?

Why Are They a Big Deal?

What Edge Functions Are Not Great At

Should You Use Them?

Why Git is So Hard to Learn (and Why You Should Learn it Anyway)

Git Doesn’t Work Like Other Tools

The Mental Model Is The Difficult Part

You Will Mess Up

Real-Life Git Advice

Why It's Worth It

Debugging MATLAB Scripts Like a Pro: Common Mistakes and How to Fix Them

1. Not Preallocating Arrays

2. Using = Instead of == in Conditionals

3. Forgetting to Clear Old Variables

4. Indexing from Zero

5. Mismatched Matrix Dimensions

6. Not Using the Debugger

7. Calling Functions That Don’t Exist

Final Thoughts

Create a GOOD game as a beginner

50+ Tips For Big Games in Unity

Planning & Project Architecture

Code Architecture & Performance

Content, World, and Performance

Advanced Systems & Optimization

AI, Horror Systems, and Tools

Some additional tips:

Why Vibe coding is the best and we are wrong

2. Using `=` Instead of `==` in Conditionals