DEV Community: Ziad Amr

AI in Web Development: From Assistant to Partner

Ziad Amr — Sun, 07 Jun 2026 14:52:38 +0000

I know some people still treat AI like a "smart autocomplete" — you write a line and it finishes the rest. But the truth is, AI in web development passed that stage a long time ago. It's now a true partner in the development process: it understands context, suggests architectural solutions, writes complete code, and works with you to solve problems. In this article, I'll share how AI has changed my workflow as a web developer, from the early GitHub Copilot days to the tools we use today.

The Assistant Phase (2022-2023) was the first appearance of GitHub Copilot. The idea was simple: you write a comment or the beginning of a function and AI completes the code. It wasn't much, but it genuinely saved time. I'd write a comment like "// function to validate Egyptian phone number" and Copilot would write the entire function. But it had many issues: it suggested code from outdated libraries, didn't understand the bigger context of the project, and sometimes hallucinated functions that didn't exist. In my projects like Esma3 Radio, it helped with small tasks like writing CSS or utility functions, but anything beyond that I had to write myself.

The Partner Phase (2024-2025) changed everything. Tools like Cursor appeared and understood that AI needs to understand the whole project, not just the file you're working in. Cursor reads all files, understands the architecture, and suggests changes consistent with the rest of the project. In the Elmokhber project, I wanted to add a new feature to the game room. Instead of explaining everything to AI from scratch, Cursor understood the context on its own because it read all the code. It suggested a solution that was consistent with the pattern I was using throughout the project. That's the real difference — AI now understands context instead of just guessing.

Using AI for debugging was a major turning point. Before, when I found a bug in an app like Battle of Questions — say, players not seeing the same scores at the same time — I'd sit and manually analyze the Socket.io events, read logs, and try to reproduce the problem. Now I tell AI "players are seeing different scores" and it analyzes the code and finds that the issue is a race condition in the event handler. AI doesn't solve it for you, but it gets you to the solution much faster.

In design, AI has become a real assistant. Tools like v0 can turn a text description into a complete UI component. In the Eah ElKalam app, I wanted a card design for Egyptian trends with an image, title, and share count. I described the design to v0 and got a complete card with Tailwind that was almost exactly what I imagined. I tweaked it a bit and was done. Previously, I would have spent an hour designing that card from scratch.

Testing is one of the areas where AI has had the biggest impact. Writing tests was always one of the things developers hate most — tedious, time-consuming, and easily forgotten. In Eleqbal Form, I used AI to write comprehensive tests for the registration form. The agent wrote tests for everything: invalid email, Egyptian phone numbers in different formats, empty fields, SQL injection. What would have taken me a full day of testing took half an hour.

So what does AI still struggle with? First: understanding the real intent behind a request. Sometimes I ask for something and AI interprets it differently and produces something almost right but not quite. For example, in Tammeny, I asked AI to "add a notification feature when someone accesses your location" — it understood I wanted Push Notifications, but I meant an in-app notification. The difference is subtle but important. Second: AI loves over-engineering. You ask for something simple and it responds with a complex solution full of Design Patterns and techniques you don't need. That's why you always need to be clear and specific in your requests.

One of the most frequently asked questions: will AI replace developers? My personal opinion: no, but it will replace developers who don't use AI. The difference is like someone writing with a pen versus someone using a keyboard — both write, but the latter is much faster. A developer using AI can build in one day what a traditional developer takes a week to do. But there are things AI can't do: understand real client needs, make architectural decisions based on project context, and be creative in solutions. Critical thinking and creativity are still human.

My advice for any developer: start integrating AI into your workflow gradually. You don't have to use it for everything from day one. Start with things that take a lot of time and are tedious: writing tests, documentation, refactoring. Then gradually use it for bigger tasks like designing components and writing APIs. The important thing is to review everything AI generates — don't forget that you're ultimately responsible for the code. AI is a powerful partner, but a partner needs someone to guide them.

الذكاء الاصطناعي في تطوير الويب: من المساعد للشريك

Ziad Amr — Sun, 07 Jun 2026 14:51:54 +0000

أنا عارف إن فيه ناس لسه بتتعامل مع الذكاء الاصطناعي كأنه مجرد "أوتوكومبليت ذكي" — بتكتب سطر وبيكمللك الباقي. بس الحقيقة إن الذكاء الاصطناعي في تطوير الويب عدّى المرحلة دي من زمان. دلوقتي بقى شريك حقيقي في عملية التطوير: بيفهم السياق، بيقترح حلول معمارية، بيكتب كود كامل، بيشتغل معاك على حل المشاكل. في المقال ده هشارك إزاي غيّر الذكاء الاصطناعي طريقة شغلي كمطور ويب، من أول GitHub Copilot لحد الأدوات اللي بنستخدمها النهاردة.

مرحلة المساعد (2022-2023) كانت أول ظهور لـ GitHub Copilot. الفكرة كانت بسيطة: تكتب تعليق أو بداية دالة والـ AI يكمل الكود. كانت مفيشة كتير بس وفّرت وقت فعلاً. كنت بكتب تعليق زي "// function to validate Egyptian phone number" وCopilot بيكتب الدالة كاملة. بس كانت مشاكله كتير: بيقترح كود من مكتبات قديمة، مش بيفهم السياق الكبير للمشروع، وبمرات بيـ hallucinate دوال مش موجودة. في مشاريعي زي إسمع راديو، كان بيساعد في المهام الصغيرة زي كتابة CSS أو دوال مساعدة، بس أي حاجة أكتر من كده كنت لازم أكتبها بنفسي.

مرحلة الشريك (2024-2025) غيّرت كل حاجة. أدوات زي Cursor ظهرت وفهمت إن الـ AI محتاج يفهم المشروع كله مش بس الملف اللي شغال فيه. Cursor بيقرأ كل الملفات، يفهم الـ architecture، وبيقترح تغييرات متناسقة مع باقي المشروع. في مشروع المخبر، كنت عايز أضيف ميزة جديدة في غرفة اللعب. بدل ما أشرح للـ AI كل حاجة من الأول، Cursor فهم السياق لوحده لأنه قرأ الكود كله. اقترح حل كان متناسق مع الـ pattern اللي كنت بتستخدمه في باقي المشروع. ده الفرق الحقيقي — الـ AI بقا فاهم السياق مش بس بيخمن.

استخدام الذكاء الاصطناعي في الـ Debugging كان نقطة تحول كبيرة. قبل كده، لما كنت بلاقي Bug في تطبيق زي معركة الأسئلة — وليكن مشكلة إن اللاعبين مش شايفين نفس النقاط في نفس الوقت — كنت بقعد أحلل الـ Socket.io events يدويًا، أقرأ اللوجات، أحاول أعيد المشكلة. دلوقتي بقى بقول للـ AI "اللاعبين شايفين سكور مختلف" وبيحلل الكود ويلاقي إن المشكلة في Race condition في الـ event handler. الـ AI مش بيحل مكانك، بس بيوصلك للحل أسرع بكتير.

في التصميم، الذكاء الاصطناعي بقا مساعد حقيقي. أدوات زي v0 بتقدر تحول وصف نصي لـ UI component كامل. في تطبيق إيه الكلام، كنت عايز تصميم كارد للترند المصري فيه صورة وعنوان وعدد المشاركات. وصفت التصميم لـ v0 ولقيت كارد جاهز بـ Tailwind تقريبًا مطابق للي كنت متخيله. عدلت عليه شوية وخلصت. قبل كده كنت هقعد ساعة أصمم الكارد ده من الصفر.

الاختبارات (Testing) من أكتر المجالات اللي الذكاء الاصطناعي أثر فيها. كتابة الاختبارات كانت دايمًا من أكتر الحاجات اللي المطورين بيكرهوها — مملة ومحتاجة وقت وبتتنسى بسهولة. في نظام الإقبال، استخدمت AI عشان يكتب اختبارات شاملة لنموذج التسجيل. الوكيل كتب اختبارات لكل حاجة: الإيميل الغلط، الرقم المصري بصيغ مختلفة، الحقول الفاضية، الـ SQL injection. اللي كان هياخد مني يوم كامل اختبارات خلصته في نص ساعة.

طيب إيه اللي الذكاء الاصطناعي لسه بيتعثر فيه؟ أول حاجة: فهم النية الحقيقية خلف الطلب. أحيانًا بطلب حاجة والـ AI بيفهمها بطريقة تانية وبيعمل حاجة شبه الصح بس مش الصح. مثلًا في طمني، طلبت من الـ AI "أضف ميزة إشعار لما حد يوصل لموقعك" — هو فهم إنني عايز Push Notification، بس أنا كنت قصدي إشعار جوه التطبيق نفسه. الفرق دقيق بس مهم. تاني حاجة: الـ AI بيحب يعمل Over-engineering. بتطلب حاجة بسيطة بيرد بحل معقد فيه Design Patterns وتقنيات مش محتاجها. عشان كده دايمًا بيكون لازم تبقى واضح ومحدد في طلباتك.

من أكتر الأسئلة اللي بتتسأل: هل الذكاء الاصطناعي هيستبدل المطورين؟ رأيي الشخصي: لا، بس هيستبدل المطورين اللي مش بيستخدموا الذكاء الاصطناعي. الفرق زي اللي بيكتب بالقلم واللي بيستخدم الكيبورد — الاتنين بيكتوب، بس التاني أسرع بكتير. المطور اللي بيستخدم AI بيقدر يبني في يوم واحد اللي المطور العادي بيستنى أسبوع يعمله. بس في حاجات الـ AI مش هيقدر يعملها: يفهم احتياجات العميل الحقيقية، يتخذ قرارات معمارية بناءً على سياق المشروع، ويبدع في الحلول. التفكير النقدي والإبداع لسه بشريين.

نصيحتي لأي مطور: ابدأ دمج الذكاء الاصطناعي في ورقتك تدريجيًا. مش لازم تستخدمه في كل حاجة من أول يوم. ابدأ بالحاجات اللي بتاخد وقت كبير وبتكون مملة: كتابة الاختبارات، التوثيق، الـ refactoring. وبعدين تدريجيًا استخدمه في مهام أكبر زي تصميم المكونات وكتابة الـ APIs. المهم إنك تراجع كل حاجة الـ AI بيولّدها — متنساش إنك أنت المسؤول عن الكود في الآخر. الذكاء الاصطناعي شريك قوي جدًا، بس الشريك محتاج حد يوجهه.

AI Agents: Revolutionizing How We Build Software

Ziad Amr — Sun, 07 Jun 2026 14:51:14 +0000

If you asked anyone in tech in 2024 about AI, they'd say ChatGPT and leave it at that. But 2025 and 2026 changed the game entirely. We're no longer talking about a model that responds to a question with an answer — we're talking about agents that can think, plan, and execute complex tasks on their own. The difference between a chatbot and an agent is like the difference between a receptionist and a project manager. The former answers your questions; the latter takes a goal from you and achieves it from first step to last.

What exactly is an AI Agent? An agent is an AI system capable of achieving a complex goal through a sequence of independent steps. It's not just "write me code" and it writes — you say "build me a complete login page with validation, database integration, and good UX" and it plans the steps: first it designs the interface, then writes the API, then connects the database, adds validation, and tests everything. All on its own without you intervening at every step.

An AI agent has four essential components: First, the engine (LLM) like Claude or GPT — the brain that thinks and makes decisions. Second, memory — the agent needs to remember what it's done and what's left to do, achieved through conversation context or long-term memory. Third, tools — the agent can browse the web, read and write files, run terminal commands, and interact with APIs. Fourth, planning — the ability to break a large goal into small steps and execute them in the right order.

The difference between an agent and a regular chatbot is clear. A chatbot asked "how do I build a notification system?" gives you theoretical explanation and code examples. An agent told "add a notification system to my project" reads your code, understands the architecture, adds notifications in the right place, connects them to the database, and tests them. This is a fundamental shift — from consultation to execution.

In my own projects, I've started leveraging agents practically. In the Esma3 Radio project, I used an AI agent to do a comprehensive performance analysis. The agent read the Lighthouse report, analyzed the bundle size, and suggested specific improvements with ready-to-use code. It would have taken me a full day to do that analysis manually, but the agent completed it in minutes. In Tammeny, I used an agent to write tests for the location sharing components — it wrote comprehensive test code that covered edge cases I would have missed if I wrote the tests myself.

The concept of Multi-Agent Systems is the next step. Instead of one agent doing everything, you have a team of agents: one specialized in design, one in backend, one in frontend, one in testing. Each works in their domain and communicates with the others. Imagine a project like Battle of Questions — one agent writes the Socket.io logic, another designs the game room interface, and another writes stress tests. All working in parallel and coordinating with each other. This isn't science fiction — it's happening right now.

So will agents replace us as developers? The short answer: no. The long answer: no, but they'll completely change how we work. Agents are excellent at repetitive and knowledge-based tasks, but they still need someone to define the right goal, review results, and make decisions that require human context. In Eleqbal Form, an agent can write form validation code quickly, but design decisions like how to make the experience easy for students — that needs human thinking.

One of the real challenges with agents: hallucination. An agent can make a wrong decision and keep building on it, which wastes more time if you're not reviewing. There's also the infinite loop problem — an agent can get stuck in a loop if the problem is complex and it can't solve it. The solution is to set clear boundaries: maximum number of steps, review checkpoints, and a stop mechanism if the agent feels it's not making progress.

My advice for any developer wanting to start with agents: begin with tools like Claude Code or Cursor Agent on small projects. Try giving the agent specific, clear tasks and see the results. Don't expect perfection on the first try — you'll notice the agent does some things well and others need adjustment. But over time, you'll learn how to write prompts in a way that gets better results from the agent. The future isn't for the agent alone or the developer alone — it's for the developer who uses agents intelligently.

وكلاء الذكاء الصناعي: ثورة في طريقة بناء البرمجيات

Ziad Amr — Sun, 07 Jun 2026 14:50:33 +0000

لو سألت أي حد في المجال التقني سنة 2024 عن الذكاء الاصطناعي، كان هيقولك ChatGPT وكفاية. بس سنة 2025 و2026 غيّرت اللعبة تمامًا. مبقناش بنتكلم عن موديل بيرد على سؤال ويديك إجابة — احنا بنتكلم عن وكلاء (Agents) بيعرفوا يفكروا، يخططوا، ينفذوا مهام معقدة لوحدهم. الفرق بين الشات بوت والوكيل زي الفرق بين موظف استقبال ومدير مشروع. الاول بيرد على أسئلتك، التاني بياخد هدف منك وبيحققه من أول خطوة لآخر خطوة.

إيه هو الوكيل الذكي (AI Agent) بالظبط؟ الوكيل هو نظام ذكاء اصطناعي بيقدر يحقق هدف معقد من خلال سلسلة خطوات مستقلة. يعني مش بس بتقولو "اكتبلي كود" وبيكتب — بتقولو "ابني لي صفحة تسجيل دخول متكاملة فيها تحقق وربط بقاعدة بيانات وتجربة مستخدم كويسة" وهو بيخطط الخطوات: أولًا هيصمم الواجهة، بعدين هيكتب الـ API، بعدين هيربط الداتابيز، بعدين هيضيف الـ validation، وبعدين هيختبر كل حاجة. كل ده لوحده من غير ما تتدخل في كل خطوة.

المكونات الأساسية لأي وكيل ذكي أربعة: الأول هو المحرك (LLM) زي Claude أو GPT — ده العقل اللي بيفكر ويأخذ القرارات. التاني هو الذاكرة (Memory) — الوكيل لازم يفتكر اللي عمله واللي لسه عايز يعمله، وده بيتحقق من خلال سياق المحادثة أو ذاكرة طويلة المدى. التالت هو الأدوات (Tools) — الوكيل بيقدر يتصفح الويب، يقرأ ويكتب ملفات، يشغّل أوامر في التيرمنال، يتعامل مع APIs. الرابع هو التخطيط (Planning) — القدرة إنه يقسم الهدف الكبير لخطوات صغيرة وينفذها بالترتيب الصح.

الفريق بين الوكيل والشات بوت العادي واضح جدًا. الشات بوت لو سألتو "إزاي أعمل نظام إشعارات؟" هيديك شرح نظري وأمثلة كود. الوكيل لو قلتو "ضيف نظام إشعارات في مشروعي"، هيقرأ الكود بتاعك، يفهم الهيكل، يضيف الإشعارات في المكان الصح، يربطها بالـ database، ويختبرها. ده تحول جوهري — من استشارة لتنفيذ.

في مشاريعي الشخصية، بدأت أستفيد من الوكلاء بشكل عملي. في مشروع إسمع راديو، استخدمت وكيل ذكي عشان يعمل تحليل شامل لأداء التطبيق. الوكيل قرأ الـ Lighthouse report، حلل الـ bundle size، واقترح تحسينات محددة مع الكود الجاهز. كان هيأخذ مني يوم كامل أعمل التحليل ده يدويًا، لكن الوكيل خلصه في دقائق. كمان في طمني، استخدمت وكيل عشان يكتب اختبارات (Tests) للأجزاء اللي متصلة بمشاركة الموقع — وكتب كود اختبار شامل غطّى حالات كنت هنساها لو كتبت الاختبارات لوحدي.

فكرة الوكلاء المتعدين (Multi-Agent Systems) هي الخطوة الجاية. بدل ما وكيل واحد يعمل كل حاجة، عندك فريق وكلاء: واحد متخصص في التصميم، واحد في الـ backend، واحد في الـ frontend، واحد في الاختبارات. كل واحد بيشتغل في مجاله وبيتواصل مع الباقيين. تخيل مشروع زي معركة الأسئلة — وكيل يكتب الـ Socket.io logic، ووكيل يصمم واجهة غرفة اللعب، ووكيل يكتب اختبارات الضغط. كل دول بيشتغلوا بالتوازي وبينسقوا مع بعض. ده مش خيال علمي — ده بيحصل دلوقتي.

طيب هل الوكلاء هيستبدلونا كمطورين؟ الإجابة القصيرة: لا. الإجابة الطويلة: لا، بس هتغيّر طريقة شغلنا تمامًا. الوكلاء ممتازين في المهام المتكررة والمعرفة، لكن لسه محتاجين حد يحدد الهدف الصح، يراجع النتائج، ويتخذ القرارات اللي محتاجة سياق بشري. في نظام الإقبال، الوكيل يقدر يكتب كود الـ form validation بسرعة، لكن التصميم القرارات زي إزاي نخلي التجربة سهلة للطالب — دي محتاجة تفكير بشري.

من التحديات الحقيقية للوكلاء: الهلوسة (Hallucination). الوكيل ممكن ياخد قرار غلط ويكمل عليه، وده بيضيع وقت أكتر لو مكنتش بتراجع. كمان مشكلة الحلقة اللانهائية — الوكيل ممكن يدور في حلقة مفرغة لو المشكلة معقدة ومش عارف يحلها. الحل إنك تحط حدود واضحة: أقصى عدد خطوات، نقاط مراجعة في النص، وآلية إيقاف لو الوكيل حاسس إنه مش بيتقدم.

نصيحتي لأي مطور عايز يبدأ مع الوكلاء: ابدأ بأدوات زي Claude Code أو Cursor Agent على مشاريع صغيرة. جرّب تعطي الوكيل مهام محددة وواضحة وشوف النتائج. متتوقعش الكمال من أول مرة — هتلاحظ إن الوكيل بيعمل حاجات كويسة وحاجات محتاجة تعديل. بس مع الوقت هتتعلم إزاي تكتب الأوامر (Prompts) بطريقة تخلي الوكيل ينتج نتائج أفضل. المستقبل مش للوكيل لوحده ولا للمطور لوحده — المستقبل للمطور اللي بيستخدم الوكلاء بذكاء.

Progressive Web Apps (PWA): How to Make Your App Work Offline

Ziad Amr — Sun, 07 Jun 2026 14:22:51 +0000

Progressive Web Apps (PWA) have changed the old rule that said "an app must be either a Native App or a Web App." PWA offers the best of both worlds: a native app experience with the accessibility of the browser without downloading. In this article, we'll discuss the technical fundamentals of PWA, from Service Workers to caching strategies to push notifications.

The foundation PWA is built on is the Service Worker. A Service Worker is a JavaScript file that acts as a Proxy between the app and the network. When the app requests a file or data, the request goes through the Service Worker first, and it decides: fetch from the network, serve from cache, or do something else. The most important thing about Service Workers is they work in the background even if the browser is closed.

The Service Worker lifecycle has three stages: Install, Activate, and Fetch. In the Install stage, you download and cache essential files (Pre-caching). In the Activate stage, you clean up old caches from previous versions. In the Fetch stage, you handle every network request and decide how to respond.

Caching Strategies are the core of PWA. The most important strategies: Cache First (suitable for static files), Network First (suitable for data that changes frequently), Stale While Revalidate (suitable for content where being the latest isn't critical).

Offline-First Architecture is the right way to think about PWA. Instead of thinking "the app works online and might work offline," think "the app works offline and updates data when the network returns." This completely changes how you write code and gives a much faster user experience.

In the Esma3 Radio project, converting the app to a PWA was a very important decision. Users listen to radio in many places with weak or no network. After PWA, the app continues working with cached data and tries to reconnect in the background. We also added offline station downloads.

The Web App Manifest makes the browser treat your app as a native application. Push Notifications are one of the most powerful PWA features. Background Sync saves operations when offline and executes them when the network returns.

My advice: start with the basics, then add caching strategies, then think about notifications and Background Sync. PWA is like layers, each layer adds value. Test on real devices especially on slow networks.

تطبيقات الويب التقدمية (PWA): إزاي تخلي تطبيقك يشتغل بدون إنترنت

Ziad Amr — Sun, 07 Jun 2026 14:22:20 +0000

تطبيقات الويب التقدمية (Progressive Web Apps أو PWA) غيّرت القاعدة القديمة اللي بتقول "التطبيق لازم يكون أما Native App أما Web App". PWA بيوفر أفضل العوالم: تجربة تطبيق أصلي مع إمكانية الوصول من المتصفح بدون تنزيل. في المقال ده هنتكلم عن الأساسيات التقنية لـ PWA، من Service Workers لاستراتيجيات التخزين المؤقت للإشعارات، كل حاجة من تجربة عملية مش من قراءة Documentation بس.

الأساس اللي عليه PWA مبني هو Service Worker. Service Worker ده ملف JavaScript بيعمل كـ Proxy بين التطبيق والشبكة. يعني لما التطبيق يطلب ملف أو بيانات، الطلب بيمر على Service Worker الأول، وهو اللي بيقرر: يجيبها من الشبكة ولا من الكاش ولا يعمل حاجة تانية. أهم حاجة عن Service Worker إنه بيشتغل في الخلفية حتى لو المتصفح مقفول — ده اللي بيخلي الإشعارات والتزامن في الخلفية ممكنة.

دورة حياة Service Worker ليها تلات مراحل: Install وActivate وFetch. في مرحلة Install، بتحصل على فرصة تحمّل الملفات الأساسية وتخزّنها في الكاش (ده اسمه Pre-caching). في مرحلة Activate، بتنظّف الكاش القديم من الإصدارات السابقة. وفي مرحلة Fetch، بتتعامل مع كل طلب شبكة وبتقرر إزاي ترد عليه. فهم الدورة دي مهم عشان مش عايز Service Worker يرد على طلبات بإصدار قديم من الكاش.

استراتيجيات التخزين المؤقت (Caching Strategies) هي جوهر PWA. مش كل الطلبات بتتعامل بنفس الطريقة — لازم تعرف إيه اللي يتخزّن وإيه اللي يتجيب من الشبكة أولًا. أهم الاستراتيجيات: Cache First (الكاش الأول وبعدين الشبكة — مناسب للملفات الثابتة زي الصور والخطوط)، Network First (الشبكة الأول وبعدين الكاش — مناسب للبيانات اللي بتتغير باستمرار)، Stale While Revalidate (اعرض الكاش واطلب من الشبكة في نفس الوقت — مناسب للمحتوى اللي مش مهم يكون أحدث حاجة).

المعمارية Offline-First هي الطريقة الصحيفة للتفكير في PWA. بدل ما تفكر "التطبيق يشتغل أونلاين وبس ممكن يشتغل أوفلاين"، فكر "التطبيق يشتغل أوفلاين وأول ما الشبكة ترجع يحدث البيانات". ده بيغيّر طريقة كتابة الكود بالكامل. بدل ما تعمل طلب شبكة وتستنى الرد، بتعرض البيانات المخزنة أولًا وبعدين بتحّدثها في الخلفية. ده بيدي تجربة مستخدم أسرع بكثير حتى لو الشبكة شغالة، لأن المستخدم مش بيشوف شاشة تحميل.

في مشروع إسمع راديو، تحويل التطبيق لـ PWA كان قرار مهم جدًا. المستخدمين بيستمعوا للراديو في أماكن كتير فيها شبكة ضعيفة أو مفيش شبكة خالص — في المترو، في السفر، في مناطق بعيدة. قبل PWA، لما الشبكة بتقطع، التطبيق كان بيبطل يشتغل خالص. بعد PWA، التطبيق بيستمر يشتغل ببيانات الكاش وبيحاول يعيد الاتصال في الخلفية. كمان أضفنا ميزة تنزيل المحطات المفضلة للاستماع أوفلاين — ده خدم مستخدمين كتير بيقولوا "أنا عايز أسمع راديو في المترو من غير نت".

Web App Manifest هو الملف اللي بيخلي المتصفح يتعامل مع تطبيقك كتطبيق أصلي. ده ملف JSON فيه اسم التطبيق وأيقونات وألوان واتجاه العرض. لما المستخدم يزور تطبيق PWA، المتصفح بيقترح عليه "إضافة للشاشة الرئيسية" — وده بيخلي التطبيق يظهر زي أي تطبيق Native على الموبايل بدون شريط المتصفح.

الإشعارات (Push Notifications) من أقوى ميزات PWA. تخيل تقدر تبعت إشعار للمستخدم من غير ما التطبيق يكون مفتوح — ده كان محصور بتطبيقات Native زمان. مع Push API وService Worker، بقى ممكن تبعت إشعارات حتى لو المتصفح مقفول. بس انتبه: الإشعارات لازم تكون مفيدة وقليلة، مش تزعج المستخدم. الإشعارات العشوائية بتخلي المستخدم يلغي الإذن وده بيخسرك الميزة كلها.

الخلفية (Background Sync) ميزة تانية مهمة في PWA. لما المستبيعمل حاجة محتاجة شبكة والشبكة مقطوعة، Background Sync بيحفظ العملية وبينتظر الشبكة ترجع وبعدين ينفذها تلقائيًا. مثال: المستخدم بيبعت تعليق والشبكة مقطوعة — التعليق بيتحفظ محليًا، وأول ما الشبكة ترجع، بيتحبعت من غير ما المستخدم يعمل حاجة. ده بيحل مشكلة شائعة جدًا خصوصًا في البلاد اللي فيها شبكات ضعيفة زي مصر.

من الأخطاء الشائعة اللي بشوفها: نسيان تحديث Service Worker لما بتنزل إصدار جديد. Service Worker القديم بيفضل شغال على المتصفح وبيرد من الكاش القديم. الحل إنك تغيّر اسم الكاش في كل إصدار جديد وتحذف الكاش القديم في مرحلة Activate. كمان مشكلة تانية هي عدم التعامل مع الحالة اللي الكاش يكون فيه فارغ والشبكة مقطوعة — لازم تعرض صفحة أو رسالة مناسبة مش خطأ أبيض.

نصيحتي لأي حد عايز يعمل تطبيقه PWA: ابدأ بالأساسيات — سجّل Service Worker واعمل Manifest واختبر التثبيت. بعدين أضف استراتيجيات الكاش المناسبة لنوع بياناتك. وبعدين فكّر في الإشعارات والـ Background Sync. مش لازم تعمل كل حاجة مرة واحدة — PWA زي الطبقات، كل طبقة بتضيف قيمة. والأهم: اختبر على أجهزة حقيقية خصوصًا على شبكات بطيئة لأن ده اللي هيبان الفرق الحقيقي.

Database Performance with PostgreSQL: How to Make Your Database Fast and Stable

Ziad Amr — Sun, 07 Jun 2026 14:21:08 +0000

PostgreSQL is one of the most powerful relational databases on the market, but power alone isn't enough if you don't know how to use it properly. The database is the heart of any application — if that heart is slow, the entire application will be slow no matter how beautiful the code is. In this article, we'll discuss the most important performance optimization strategies in PostgreSQL, from indexing to query optimization to connection pooling.

The first and most important thing in PostgreSQL performance is indexing. Indexing is like the index at the back of a book — instead of flipping through every page to find a specific topic, you open the index and find the page number immediately. In PostgreSQL, the default index is B-Tree which is suitable for most cases. But many developers use indexes incorrectly. Don't put an index on everything — each index increases the database size and slows down write operations.

There are more types of indexes in PostgreSQL than just B-Tree. There's Hash Index for equality lookups, GIN Index for complex data like JSONB and arrays, and GiST Index for geographic data. If you try to search JSONB without an index, PostgreSQL will do a Sequential Scan on every row in the table. With GIN Index, the search is almost instant. The difference can be from 5 seconds to 5 milliseconds.

Query Analysis is your first step when facing a performance issue. The EXPLAIN ANALYZE tool is your best friend. For every slow query, run EXPLAIN ANALYZE and see what PostgreSQL is actually doing. What you look for: is there a Sequential Scan? Is there a Nested Loop with many rows? Is Sorting taking a long time?

One of the most common slow query patterns I see: using SELECT * instead of choosing only the columns you need. Also the N+1 Query problem that happens when you fetch a list and then fetch details for each item separately. This happens a lot with ORMs like Prisma.

Connection Pooling is one of the most important topics that many developers overlook. PostgreSQL treats each connection as a separate Process, meaning each connection consumes memory and CPU. The solution is a Connection Pooler like PgBouncer. In a Serverless environment like Vercel, Prisma has a built-in Connection Pooling feature that solves the "too many connections" problem.

Quick final tips: use pg_stat_statements to know which queries consume the most time, enable auto_vacuum so PostgreSQL cleans itself automatically, and monitor database size regularly. Database performance isn't something you fix once and forget — it's an ongoing process.

أداء قواعد البيانات مع PostgreSQL: إزاي تخلي قاعدة بياناتك سريعة ومستقرة

Ziad Amr — Sun, 07 Jun 2026 14:20:32 +0000

PostgreSQL من أقوى قواعد البيانات العلاقية في السوق، بس القوة لوحدها مش كافية لو مش عارف تستخدمها صح. قاعدة البيانات هي قلب أي تطبيق — لو القلب ده بطيء، التطبيق كله هيكون بطيء مهما كان الكود حلو. في المقال ده هنتكلم عن أهم استراتيجيات تحسين الأداء في PostgreSQL، من الفهرسة لتحسين الاستعلامات لتجميع الاتصالات، كل حاجة من تجربة عملية مش من نظرية الكتب.

أول وأهم حاجة في أداء PostgreSQL هي الفهرسة (Indexing). الفهرسة زي الفهرس في آخر الكتاب — بدل ما تقلّب كل صفحة عشان تلاقي موضوع معين، بتفتح الفهرس وتلاقي رقم الصفحة على طول. في PostgreSQL، الفهرس الافتراضي هو B-Tree وده مناسب لمعظم الحالات. بس المشكلة إن كتير من المطورين بيستخدموا الفهرس بطريقة غلط. الفهرس مش ضعّه على كل حاجة — كل فهرس بيزيد حجم قاعدة البيانات وبيبطّئ عمليات الكتابة (INSERT, UPDATE, DELETE). القاعدة: ضع فهرس على الأعمدة اللي بتستخدمها في WHERE و JOIN و ORDER BY بكثرة.

أنواع الفهرسة في PostgreSQL أكتر من B-Tree. فيه Hash Index للبحث عن القيم المتساوية، وGIN Index للبيانات المعقدة زي JSONB و المصفوفات، وGiST Index للبيانات الجغرافية. مثال عملي: لو عندك عمود tags من نوع JSONB وبتدور عليه كتير، GIN Index هو الخيار الأمثل. لو حاولت تدور في JSONB بدون فهرس، PostgreSQL هتعمل Sequential Scan على كل صف في الجدول — يعني هتمر على ملايين الصفوف واحد واحد. مع GIN Index، البحث بيكون فوري تقريبًا. الفرق ممكن يكون من 5 ثواني لـ 5 ملي ثانية.

تحليل الاستعلامات (Query Analysis) هو خطوتك الأولى لما تواجه مشكلة أداء. أداة EXPLAIN ANALYZE هي صديقتك الأولى. كل استعلام بطيء شغّل عليه EXPLAIN ANALYZE وشوف PostgreSQL بتعمل إيه بالظبط. اللي بتبص عليه هو: هل في Sequential Scan (ده علامة إن محتاج فهرس)؟ هل في Nested Loop مع صفوف كتير (ده ممكن يحتاج تحسين JOIN)؟ هل Sorting بيأخذ وقت طويل (ده ممكن يحتاج فهرس على عمود الترتيب)؟

من أكثر أنماط الاستعلامات البطيئة اللي بشوفها: استخدام SELECT * بدل ما تختار الأعمدة اللي محتاجها فقط. في جدول فيه 20 عمود، لو محتاج 3 بس، اكتب أسماءهم. SELECT * بيحمّل بيانات مش محتاجها وبيستهلك الذاكرة وبيبطّئ الشبكة. كمان مشكلة الـ N+1 Query اللي بتحصل لما بتسحب قائمة وبعدين بتسحب تفاصيل كل عنصر لوحده. ده بيحصل كتير مع ORMs زي Prisma.

تحدثنا عن Prisma — وهي الأداة اللي باستخدمها مع PostgreSQL في أغلب مشاريعي. Prisma بتوفّر تجربة مطور ممتازة بس لازم تفهم إزاي بتولّد SQL عشان متعملش أخطاء أداء. مثلاً، Prima بيسمح بـ include لجلب البيانات المرتبطة، بس لو بتشمل علاقات كتير متداخلة، الاستعلام المُولّد ممكن يكون معقد جدًا. الحل: استخدم select لتحديد الحقول المطلوبة، وinclude بس للعلاقات اللي فعلاً محتاجها.

تجميع الاتصالات (Connection Pooling) من أهم المواضيع اللي كتير من المطورين بيتجاهلوها. PostgreSQL بيتعامل مع كل اتصال كـ Process منفصل، وده معناه إن كل اتصال بيستهلك ذاكرة ومعالج. لو عندك 100 مستخدم متصل في نفس الوقت، وكل واحد فاتح اتصال، السيرفر هيكون تحت ضغط كبير. الحل هو Connection Pooler زي PgBouncer. ده بيعمل طبقة وسيطة: التطبيق بيفتح اتصالات مع PgBouncer، وPgBouncer بيدير اتصالات حقيقية مع PostgreSQL. بدل 100 اتصال حقيقي، ممكن تخلّي PgBouncer يدير 20 اتصال بس ويعيد استخدامهم.

في بيئة Serverless زي Vercel، المشكلة بتكون أكبر لأن كل Function Invocation ممكن يفتح اتصال جديد. Prisma عنده ميزة Connection Pooling مدمجة مع Prisma Data Proxy اللي بيحل المشكلة دي. في مشاريعي اللي على Vercel، كنت بواجه خطأ "too many connections" بشكل متكرر لحد ما فعّلت Prisma Connection Pooling. المشكلة اختفت تمامًا.

مشكلة تانية شائعة هي عدم استخدام Transactions في العمليات اللي بتعدّل أكتر من جدول. لو عندك عملية بتخصم من رصيد المستخدم وتضيف طلب جديد، والعملية فشلت في النص، الرصيد هيتخصم بس الطلب مش هيتحط. ده كارثة بيانات. مع Transactions، لو أي خطأ حصل في أي نقطة، كل التغييرات بترجع زي ما كانت.

نصائح أخيرة سريعة: استخدم pg_stat_statements عشان تعرف أكتر الاستعلامات اللي بتستهلك وقت، وشغّل auto_vacuum عشان PostgreSQL تنظّف نفسها تلقائيًا، وراقب حجم قاعدة البيانات بانتظام عشان تكتشف أي مشالة نمو مبكرًا. أداء قاعدة البيانات مش حاجة بتصلحها مرة وتنسى — ده عملية مستمرة بتحتاج مراقبة وتحسين دائم.

TypeScript Type Safety: Why TypeScript Is More Than Just JavaScript With Types

Ziad Amr — Sun, 07 Jun 2026 14:19:56 +0000

Type safety in TypeScript isn't just a nice additional feature — it's the difference between a project that breaks in production and one that runs reliably. I was one of those people who said "JavaScript is enough, I don't need TypeScript," then I discovered that was the biggest technical mistake I made in my career as a developer. In this article, we'll understand together why TypeScript matters, how types prevent real bugs, and the most important patterns every developer should know.

The first thing we need to understand: TypeScript isn't a new language, it's JavaScript with a type layer on top. That means everything you know about JavaScript still works, but you get extra protection from errors. When you write regular JavaScript code, you might create a variable called age and accidentally put a string in it, and no one will tell you until the app crashes. But TypeScript will tell you from the start: "This is a number not a string, you're wrong." That difference saves hours of debugging that could have been resolved in a second.

The most common pattern that helps you in TypeScript is Interfaces and Type Aliases. Instead of dealing with anonymous objects whose shape you don't know, you define a clear Type for each object. Practical example: if you're building an API that returns user data, instead of guessing whether the field is userName or username or user_name, you write a clear Interface.

Generics are one of TypeScript's most powerful features and the one that scares people the most. But the truth is, Generics have a simple idea: you write code that handles different types but in a safe way. Instead of saying a function returns any (which loses all of TypeScript's benefits), you use a Generic to preserve type information.

Utility Types in TypeScript are like a magic toolbox. Instead of writing new types from scratch, you take an existing type and modify it. The most important ones: Partial makes all fields optional, Required makes all fields mandatory, Pick selects specific fields from a Type, Omit removes specific fields, and Record builds an Object with keys and values of specified types.

One of the most common mistakes I see in development teams is underestimating strict mode in TypeScript. Many people enable TypeScript but write any everywhere and turn off strictNullChecks and ignore errors. This completely negates TypeScript's benefits. My advice: enable strict mode from day one and let any be the exception, not the rule.

Ultimately, TypeScript isn't just a tool that adds types — it's a different way of thinking about writing code. You think about the shape of data before writing the code, and this makes the design better, the code cleaner, and the bugs fewer. If you haven't used it in your projects yet, start today.

أمان الأنواع في TypeScript: ليه TypeScript مش مجرد JavaScript مع أنواع

Ziad Amr — Sun, 07 Jun 2026 14:19:20 +0000

أمان الأنواع (Type Safety) في TypeScript مش مجرد ميزة إضافية لطيفة — ده الفرق بين مشروع بيتكسّر في الإنتاج ومشروع بيفضل شغال بثبات. أنا كنت من الناس اللي بتقول "JavaScript كافي ومش محتاج TypeScript"، وبعدين اكتشفت إن ده أكبر غلطة فنية عملتها في حياتي كمطور. في المقال ده هنفهم مع بعض ليه TypeScript مهم، وإزاي الأنواع بتمنع أخطاء حقيقية، وأهم الأنماط اللي لازم كل مطور يعرفها.

أول حاجة لازم نفهمها: TypeScript مش لغة جديدة، ده JavaScript مع طبقة أنواع فوقها. يعني كل اللي بتعرفه عن JavaScript شغال زي ما هو، بس بتحصل على حماية إضافية من الأخطاء. لما بتكتب كود JavaScript عادي، ممكن تعمل متغير اسمه age وتحط فيه string بالغلط ومحدش هيقولك لحد ما التطبيق يقع. بس TypeScript هيقولك من الأول: "ده رقم مش string، إنت غلطان". الفرق ده بيوفّر ساعات من الـ debugging اللي كان ممكن يتحل في ثانية.

أكثر نمط شائع بيساعدك في TypeScript هو الـ Interfaces و الـ Type Aliases. بدل ما تتعامل مع كائنات مجهولة (anonymous objects) مش عارف شكلها، بتعرف Type واضح لكل كائن. مثال عملي: لو بتعمل API بيرجع بيانات مستخدم، بدل ما تتخبط وتفتكر هل اسم الحقل userName ولا username ولا user_name، بتكتب Interface واضح:

Database Systems: From SQLite to PostgreSQL

Ziad Amr — Sun, 07 Jun 2026 14:18:44 +0000

The database is the heart of any web application. And choosing the right database is a decision that affects everything in the project: performance, security, scalability, and even development speed. In this article, I'll share my journey with databases from SQLite to PostgreSQL, and how Prisma changed the way I handle data.

I started with SQLite in my first projects. SQLite is excellent for small projects and prototypes — there's no server to run, the database file sits in the project itself, and everything works instantly. In a simple project like Eleqbal Form initially, SQLite was sufficient. But as the project grew and user numbers increased, problems emerged: SQLite can't handle many concurrent connections, and lacks advanced features like Full-Text Search or JSONB.

Moving to PostgreSQL was a turning point. In Esma3 Radio, we needed a database that could handle thousands of stations and hundreds of users simultaneously. PostgreSQL provided that and more. JSONB support made it easy to store variable station data without a complex schema. Native Full-Text Search helped me implement fast searching across station names without external libraries.

Prisma ORM was the link that tied everything together. Instead of writing SQL manually and dealing with connections and migrations, Prisma provided a clear, readable schema, automatic TypeScript types, and a migration system that manages database changes. In Tammeny, the schema was simple and clear: User model, LocationShare model, FamilyCircle model. Every relationship is clearly defined in the schema.prisma file.

One of Prisma's biggest benefits: Type Safety. When writing your code, everything has a clear type. If you want to query users, Prisma returns an exact type with all the fields in the model. This prevents many runtime errors and makes autocomplete work perfectly. In Battle of Questions, the Types helped me handle player and round data without any runtime errors.

But Prisma isn't perfect. One of the most frustrating things: the N+1 Query Problem. When querying a model with relationships, sometimes Prisma makes a separate query for each record instead of a single JOIN. The solution is to use include wisely or enable _previewFeatures = "relationJoinMode" to force Prisma to use JOINs. Also, Prisma can't do some complex queries that SQL handles easily, like Window Functions or CTEs. In those cases, you have to use $queryRaw and write SQL manually.

Schema design is an art in itself. One of the most important patterns I learned: use Many-to-Many relationships through intermediate tables instead of trying to shortcut them. In Esma3 Radio, the relationship between stations and users (favorites) was Many-to-Many, and I created an intermediate Favorite table with dates and additional data. I also learned that Indexes aren't a luxury — every field you search frequently should have an Index. After adding an Index on station name, search became 10 times faster.

The Migration strategy with Prisma was a strong point. Every schema change creates a new migration with only the changes, not the entire database. This makes rolling back changes easy and preserves modification history. But be careful: migrations that have been applied aren't easily reversible if data exists. That's why I always make a backup before any major migration.

My advice for beginners: start with SQLite for development speed, but plan the transition to PostgreSQL from the beginning. Use Prisma for Type Safety and Migrations, but learn SQL well so you can write complex queries when needed. And always test database performance with real data, not small test datasets.

Tailwind CSS: لماذا أصبح أسلوبي المفضل

Ziad Amr — Sun, 07 Jun 2026 14:18:15 +0000

لما بدأت أتعلم CSS، كنت كتبت كل حاجة بالطريقة التقليدية: أسماء كلاسات معبرة، ملفات CSS منفصلة، وكل كلاس ليه خصائص محددة. كنت حاسس إن ده الطريقة الصح والأكثر تنظيمًا. بس مع كبر المشاريع، لقيت نفسي بتكتب CSS أكتر من الكود نفسه.Tailwind CSS غيّر الطريقة دي تمامًا، وفي المقال ده هقولك إزاي وليه.

أول حاجة لاحظتها مع Tailwind كانت السرعة. بدل ما أفتح ملف CSS وأكتب كلاس جديد وأروح أضيفه في HTML، بقيت أكتب كل حاجة في مكان واحد. في إسمع راديو، الصفحة الرئيسية كانت محتاجة تصميم معقد: بطاقات محطات، مشغل صوت، قسم قرآن. بالـ CSS التقليدي كان هاخد يومين بس في التنسيق. مع Tailwind خلصت في نص يوم.

المقارنة بين Tailwind وCSS التقليدي مش مجرد مسألة تفضيل شخصي. في CSS التقليدي، كل مرة بتكتب كلاس جديد بيزيد حجم الملف، وبتحصل تكرار كتير. في Tailwind، الأدوات (Utilities) بتتُعاد استخدامها في كل مكان، والـ PurgeCSS بيحذف اللي مش مستخدم. النتيجة: ملف CSS أصغر بكثير. في مشروع المخبر، ملف CSS النهائي كان أقل من 10KB مقارنة بـ 50KB بالطريقة التقليدية.

التخصيص (Customization) في Tailwind كان نقطة تحول. ملف tailwind.config بيخليك تتحكم في كل حاجة: الألوان، المسافات، الخطوط، نقاط التوقف. في تطبيق طمني، عرفت أضيف لون براند خاص (أخضر للأمان) وأستخدمه في كل مكان بسهولة. لو حبيت أغيره، بغيره في مكان واحد بس. ده مستحيل تقريبًا بالـ CSS التقليدي من غير preprocessors زي SASS.

التصميم المتجاوب (Responsive Design) مع Tailwind تجربة مختلفة تمامًا. بدل ما أكتب media queries منفصلة، بكتب البادئة مباشرة: sm:, md:, lg:, xl:. في إسمع راديو، بطاقات المحطات بتظهر عمودين على الموبايل وتلاتة على التابلت وأربعة على الكمبيوتر. الكود ده بيكون واضح ومقروء في مكان واحد: grid grid-cols-2 sm:grid-cols-3 lg:grid-cols-4.

الوضع الداكن (Dark Mode) مع Tailwind بسيط جدًا. بادئة dark: قبل أي أداة بتخليها تتنفذ في الوضع الداكن بس. في تطبيق الطقس، الوضع الداكن كان مطلب أساسي عشان التطبيق بيستخدمه الناس في أوقات مختلفة من اليوم. كل اللي عملته إني أضفت dark: قبل الألوان والخلفيات وخلصت. بالـ CSS التقليدي، كنت محتاج أكتب media query منفصلة لكل عنصر.

أكبر نقد بيتقال عن Tailwind هو إن HTML بيكون مليان كلاسات وبيبقى صعب القراءة. وده صحيح في البداية. بس مع الوقت بتتعلم تنظم الكلاسات: الأول الأساسيات (display, position)، بعدين الأبعاد (width, height, padding)، بعدين الألوان والحدود، وفي الآخر التفاعلات (hover, focus). كمان استخراج المكونات (Component Extraction) بيحل المشكلة دي — لما عنصر بيتكرر، بتعمله مكون منفصل.

مثال حقيقي من معركة الأسئلة: كرت السؤال كان بيتكرر في كل جولة. بدل ما أكتب الكلاسات كل مرة، عملت مكون QuestionCard واستخدمته في كل مكان. الكلاسات الطويلة بقت في مكان واحد بس، والاستخدام بقي نظيف ومقروء.

نصيحتي: لو لسه ما جربت Tailwind، ابدأ بمشروع صغير. هتزعل في الأول من شكل الكود، بس بعد أسبوع هتلاقي نفسك أسرع بكتير. واستخدم VS Code Extension بتاع Tailwind عشان الـ autocomplete — ده بيغيّر حياتك. وأهم حاجة: اتعلم تنظيم الكلاسات عشان الكود يفضل مقروء.