Forem: Bashar Hasan

Vibe Coding: ″Feel pain. Accept pain.‶

Bashar Hasan — Sat, 31 May 2025 13:28:00 +0000

Background:

Honestly, I was skeptical about vibe coding. I only used LLMs to help with a small portion of the code — around 10%.

Why?
Because it doesn’t know the context.
It’s great at building standard apps like calculators, e-commerce templates, or to-do lists… but that’s not what I needed.

That’s not to say I didn’t use it. I did.
I leaned on it to:

Fix bugs
Write code for domains I haven’t faced before
Answer questions I was too lazy to Google

But everything changed when I started building a Phoenician transliteration tool — a website that converts Arabic and English text into the ancient Phoenician script.

And I was doing this in ReactJS... without ever really learning ReactJS.

Sure, I had some experience with Flutter. But building a web app in Flutter felt off. React was calling.

It Worked at First Sight!

I tested the idea using ChatGPT.
First, I asked Gemini to help me craft a good prompt. I tweaked it a bit, then passed it to ChatGPT.

To my surprise, within about two hours, I had a working, decent-looking website.

Sure, I had to adjust some of the mapping logic — the GPT-generated code wasn’t perfect there — but still, it worked.
The LLMs handled everything else surprisingly well, from code generation to debugging.
Except for the core logic — as I mentioned earlier, that part still needed human intuition and correction.

Where the Problems Started

Then came the part where I had to actually deploy the website — and that’s when the real problems began.

ChatGPT couldn’t even provide a full list of the libraries it used. I thought, “Okay, maybe Cursor can help me solve this.”
But even Cursor couldn’t install all the necessary libraries correctly.

Worse, I couldn’t even get the app to run locally — only inside ChatGPT’s code canvas.
Both Cursor and ChatGPT were using outdated methods for starting React projects.

After some digging, a few hallucinated commands from ChatGPT, and multiple retries, I finally got partial answers.
Some libraries were revealed, but I had to manually go through component websites to figure out what was missing.

For example, ChatGPT used shadcn/ui components but never referenced or installed the package.

Eventually, after several trial-and-error commands, I was able to:

Start the app locally
Fix the missing pieces
And finally, deploy it on GitHub Pages

It’s Live… But Was It Worth It?

In the end, I managed to upload the site and get a fully working version online.
Yes — I even added it to Google Search and made final tweaks without using any LLMs 😅.

But here's the catch:
The code was… messy.
Everything was mostly thrown into a single file, with different pieces mixed together. No structure, no maintainability.

It took me around 6–8 hours to fully debug and deploy it.

Can you imagine? The app was generated in 2 hours, but I spent 4 times that just trying to make it actually work.

That’s when I realized something important:
If I had invested just 20 hours learning React properly, I probably could’ve:

Avoided a ton of debugging
Known which library versions to use
Used LLMs more like a Lego kit — asking for small, focused pieces of code
And focused my energy on the core logic, not fixing broken scaffolding

Conclusion

As many people say, AI and LLMs are skill multipliers.
If you bring nothing to the table — you’ll get nearly nothing back. (Just like me struggling with React 😅.)

Sure, tools like context7 promise to make LLMs (e.g., in Cursor) use the latest documentation versions.
But I’ll write about that later. (Spoiler: it doesn’t work as well as you'd hope.)

Trying to build anything beyond a small tool using pure "vibe coding" — no architecture, no planning, just prompts — is painful.
The code complexity scales faster than exponential, and debugging becomes a nightmare.

But if you treat LLMs like a Lego toolkit, everything changes.

Take the time to:

Design a solid architecture (yes, this might take hours!)
Write a few key functions yourself
Then use the LLM to generate small, self-contained parts that fit into your structure
Handle the hard logic manually — around 20–30% of the code

Don't ask it to write large functions across multiple files — that’s where hallucinations begin.

And yeah, stay tuned for my next article — where I’ll show a successful vibe coding case in FastAPI (where I actually know what I’m doing 😄).

Hit the reaction that match how you feel — and follow me to explore more!

References:

Phoenician Transliteration Tool
Source Code

You can also find me there :)

Github

Medium

How Does print() Work in Python?

Bashar Hasan — Tue, 01 Apr 2025 21:30:12 +0000

Overview:

Have you ever asked yourself how Python's print() function works?

Yes, yes, how to use it. Everyone knows how, but figuring out the core elements will be interesting.

🚀Short Description:

🐍Python interpreter starts.
Create buffer of type FileIO or BufferedWriter, we will see later.
Create sys.stdout object:

sys.stdout = TextIOWrapper(buffer, encoding)

TextIOWrapper works as a cover for FileIO or BufferedWriter and also includes encoding as an option ('utf-8', 'ASCII', etc).

The print() calls sys.stdout.write.
sys.stdout.write is calling its internal function written in C.
C code call Syscall.
Execution go down to the Kernel.
Finally, drivers.

🖨️Let's check out the print() definition:

The print() function has two overloads, which accept any number of values and only four named parameters: separator, end, file, and flush.

The sep parameter specifies how to join objects together.

🔚end controls what will be at the end of the print; by default, it is "\n" (next line).

📁file prints the values to a stream, file, or to sys.stdout by default, but as we mentioned above, the first overload accepts the parameter of type SupportsWrite only, and in the second overload, file has a type that supports both writing and flushing (It supports writing and flushing with the write() and flush() methods).

Thus, flush cannot be true in the first overload, in case that file may not have the method flush().

What are sys.stdout and sys.stderr?:

⚜️sys.stdout: standard output stream.

❌sys.stderr: the standard error output stream.

They are special Python objects of type TextIOWrapper, and we can use them to print information directly through an alternative method instead of the built-in print() function.

📃TextIOWrapper—First Layer:

This class is the upper class of print levels, as we mention above, sys.stoud and sys.stderr are objects of TextIOWrapper class.

TextIOWrapper can have either unbuffered(FileIO) or buffered IO (BufferedWriter) object, and it depends on the variable PYTHONUNBUFFERED

hmm‼️, you've seen this variable before; it's used in Docker images, where it is set like PYTHONUNBUFFERED 1.

This instructs Python to run in UNBUFFERED mode, which is recommended when using Python inside a Docker container. The reason for this is that it does not allow Python to buffer outputs; instead, it prints output directly, avoiding some complications in the Docker image when running your Python application.

Okay, when PYTHONUNBUFFERED=0 the class BufferedWriter will be utilized, and when PYTHONUNBUFFERED=1, we will use FileIO directly without any buffers, which is unbuffered I/O.

Take in mind🚨: in most cases python uses buffered output as default, PYTHONUNBUFFERED=0 😊

Buffered Writer—Second Layer:

This class stores many values until they reach the maximum value of the buffer, and then prints the output.
We use buffers because physical output inside OS is not a cheap operation.

It uses FileIO as inner layer, so BufferedWriter works as additional layer that let us store data and output them in chunks.

🏗️Constructor:

self.buffer_size: If the buffer_size is not given, it defaults to DEFAUTL_BUFFER_SIZE = 8 * 1024.
_write_buff: Store data in order to print it.
_write_lock: We use Lock() in order to print the data in safe thread mode.
raw: is a write stream, type of FileIO.

✍️write() method:

Using safe lock thread, we check whether our buffer is already full, in this case we flush the output (write to the output stream).
Add output data to _write_buff and flush the _write_buff if it gets full.
Return length of added data (printed data or which will be printed).

⚡Flush methods:

flush(): just execute _flush_unlocked() method with thread lock.
_flush_unlocked(): while loop puts the _write_buff on the write stream, and delete the first n written bytes until the write buffer get empty.

FileIO—Last Layer:

🏗️Constructor:

File Descriptor: named as fd.
_File descriptors in Python are identifiers that represents the open files in the os kernel and are kept in a table of files. Typically, they have non-negative values. Negative results denote an error or a "no value" condition. They support a variety of file-related operations. In general, descriptors are a special approach Python uses to maintain attributes.

✍️write() method:

Write bytes b to file, return number written.
Only makes one system call, so not all of the data may be written. The number of bytes actually written is returned. In non-blocking mode, returns None if the write would block.

⚡Flush method:

Simply returns None, because FileIO don't have buffer, and it writes inside the system directly.

Hit the reaction that match how you feel — and follow me to explore more!

References:

Source
PYTHONUNBUFFERED
Buffered Writer
File Descriptor

You can also find me there :)

Github

Medium

Best Practices for Storing and Securing Passwords: A Developer's Guide

Bashar Hasan — Fri, 28 Feb 2025 18:59:57 +0000

Introduction

In the digital age, safeguarding user passwords is crucial for protecting sensitive data. With the rise in data breaches, where passwords are exposed as plain text, attackers can exploit reused passwords to access multiple user accounts across different platforms. This compromises both user security and organizational integrity.

One of the most effective ways to prevent such vulnerabilities is through hashing. However, it's not just about hashing passwords—it's about implementing a robust, secure hashing strategy. In this guide, we’ll dive deep into the best practices for password hashing, ensuring that even if your password database is compromised, user data remains secure.

The Obvious First Step: Hashing Passwords

Hashing is the foundational security technique used to protect passwords. When done correctly, it ensures that even if hackers gain access to your hashed password database, they cannot easily reverse-engineer the hashes to recover the original passwords.

While developers often consider simple hashing algorithms like MD5 or SHA-1, these are now considered outdated and insecure. Their vulnerabilities make them susceptible to modern attacks. Let’s dive into why simple hashing techniques aren’t enough and explore more secure alternatives.

Key Problems with Simple Hashing Techniques

1. Collision Vulnerability
Cryptographic hashing algorithms are designed to map variable-length inputs (like a password) into a fixed-length output. However, a collision occurs when two distinct inputs produce the same hash output. This vulnerability can be exploited by attackers to reverse-engineer passwords, particularly when using weak hashing functions. This scenario is analogous to the birthday paradox, where the likelihood of collisions increases as the input size grows in relation to the hash output length.

2. Brute-Force Attacks
While hashing improves security over plain text passwords, attackers can still use brute-force methods to guess the original password by attempting every possible combination. If the attacker has significant computational power, brute-force attacks become feasible, making it critical to slow down the hashing process to mitigate such threats.

3. Hash Tables

Hash tables are precomputed tables containing hashes of common passwords or strings. These allow attackers to bypass the time-consuming hashing process, quickly identifying matching hashes and dramatically reducing the time required to crack a password.

4. Rainbow Tables

Rainbow tables are advanced versions of hash tables, using precomputed chains of hashed values designed to reverse-engineer a hash back to its original string. Although static salts can reduce the effectiveness of rainbow table attacks, improper password storage practices can still leave your system vulnerable.

Solutions to Enhance Password Security

1. Salt: The First Line of Defense

To protect against hash tables and rainbow table attacks, salting is indispensable. A salt is a random string added to the password before it’s hashed. By doing so, even if two users have the same password, their resulting hashes will be different, as each password is combined with a unique salt. This process makes hash tables and rainbow tables ineffective since attackers would need to generate unique tables for each salt.

Static Salts: A static salt is a single random value generated once and used across all passwords. While it effectively prevents rainbow table attacks, a compromised salt could put all passwords at risk.
Dynamic Salts: Dynamic salts are unique for each password, created at the time of password generation. This adds another layer of security by ensuring that even if an attacker compromises one salt, they cannot use it to crack other passwords.
"Salting is your best defense against rainbow tables."

2. Adjusting Computational Cost: Making Brute-Force Attacks Harder
Modern cryptographic hashing algorithms are intentionally designed to be slow to counter brute-force attacks. By adjusting the computational cost—which refers to the time required to compute the hash—you can increase the difficulty of brute-force attacks. The longer it takes to hash a password, the more computationally expensive and time-consuming it becomes for attackers to try multiple combinations.

The optimal hashing time is around 50 milliseconds per password. This ensures a balance between security and performance, making brute-force attacks impractical while keeping application responsiveness intact.

3. Using Cryptographically Secure Hash Functions
For optimal password security, you need to use cryptographically secure hash functions specifically designed for password storage. Algorithms like SHA-512 are fast and suitable for general hashing tasks, but they are not ideal for password hashing because their speed makes them vulnerable to brute-force attacks.

Here, the specific needs of your system come into play: if your server resources are limited, you can still implement cryptographic hash algorithms with both dynamic and static salts, alongside performance standards that ensure the hash algorithm runs within the 50-millisecond range. This approach strikes an optimal balance between performance and security.

However, if you have more resources at your disposal, consider using more advanced, pre-configured, and robust hashing algorithms like Argon2. These algorithms are designed to be both secure and scalable, making them ideal for larger projects with more computational capacity.

bcrypt: Includes a salt and is adaptive to hardware improvements, meaning the computational cost can be increased over time.
scrypt: A memory-hard function that requires substantial memory and CPU resources, making it more difficult to crack with brute-force methods.
Argon2: The winner of the Password Hashing Competition, Argon2 offers exceptional security and flexibility, allowing you to adjust time, memory, and parallelism parameters, providing strong resistance to modern attack techniques. Argon2 is widely regarded as the most secure option due to its flexibility and superior features, making it the best choice for most applications.

4. Implementing Strong Password Policies

Strong password policies are crucial for ensuring password hashes are resistant to brute-force attacks. The more complex and lengthy a password is, the more difficult it becomes for attackers to crack.

For example, let’s assume an attacker can perform one trillion operations per second. If the password uses 72 symbols and is 8 characters long, the total number of combinations would be approximately:

728≈722,204,136,308,736 combinations.

If the attacker can perform one trillion operations per second, the time to crack this password would be around 12 minutes. Increasing the password length to 9 characters increases the attack time to 14.44 hours, and with 10 characters, it would take an impractical 1,039 hours.

This exponential increase in time makes it far more difficult for attackers to succeed, especially with long and complex passwords.

5. Regularly Updating Hashing Parameters
As computational power grows, it's important to regularly update hashing parameters—such as the number of iterations and memory usage—to stay ahead of improvements in computing power. Regular updates ensure that your password hashing techniques remain effective against increasingly sophisticated hardware and attack methods.

Conclusion

Proper password security hinges on robust hashing, salting, and careful adjustments to computational costs. By using secure algorithms like Argon2, implementing dynamic salts, enforcing strong password policies, and regularly updating your hashing parameters, you can significantly improve your system’s resistance to attacks.

No system is immune to threats, but by adopting these best practices, you can fortify your application against hash table attacks, brute-force attempts, and rainbow table exploits. In doing so, you ensure that your users’ data remains secure well into the future.

Hit the reaction that match how you feel — and follow me to explore more!