المنشأ المعمارية المميزات خارطة الطريق
● SYSTEM_ROOT BUILD v2.2.0

PORTFOLIOBACH

لا أدوات جاهزة. لا قوالب.
100% مهندَس.

استكشاف الحالة

Chapter I: The Origin

لماذا أعدت اختراع العجلة.

Motivation

مشكلة «الصندوق الأسود»

بالطبع كان بإمكاني استخدام WordPress أو Wix. ذلك يستغرق ساعتين ويبدو جيداً.

لكن في الدراسة نتعلم الخوارزميات وهياكل البيانات وكيف تفكر الحواسيب. استخدام أداة جاهزة يبدو كالغش. إنها «صندوق أسود» — أضع المحتوى وتخرج موقعاً كاملاً، لكن دون أدنى فهم للآلية.

الهدف: أردت امتلاك الكود. أردت الضغط على Inspect Element في المتصفح وفهم كل class لأنني كتبتها بنفسي.

mindset.sh

# Option A: The Easy Way (Rejected)

$ npm install wordpress-theme-starter

# Option B: The Engineering Way

yusef@home:~$ mkdir PortfolioBach
yusef@home:~$ touch index.html main.css renderer.js
[STATUS] Control acquired.
[STATUS] Bloatware removed.
[READY] Starting development...

Bundle Size Comparison

قالب جاهز ~5.0 MB
jQuery, Bootstrap, Fonts, Trackers, Ads
PortfolioBach ~50 KB
Pure HTML5, CSS3, Vanilla JS Logic
Performance

Bloatware مقابل الحِرفية

القوالب الجاهزة كثيراً ما تحمّل ميغابايتات من مكتبات JavaScript (jQuery وBootstrap ومكوّنات لا تُعد) لمجرد عرض بعض النصوص. هذا هدر صريح.

نهجي: حددت لنفسي تحدياً: Zero Dependencies. لا Bootstrap، لا React، لا Tailwind. فقط HTML5 وCSS3 وVanilla JS الأصيل.

بهذا تعلمت كيف يعمل CSS Grid فعلاً، بدلاً من مجرد كتابة col-md-6. النتيجة؟ موقع يُحمَّل في ميلي ثوانٍ (Lighthouse 100).

Transfer

النظرية تلتقي بالتطبيق

في الجامعة ندرس Java والبرمجة كائنية التوجه. كثير من الطلاب يسألون: «هل أحتاج هذا لتطوير المواقع؟»

المحفظة هي «مختبري». أردت التحقق من إمكانية تطبيق مفاهيم كـنمط MVC (Model-View-Controller) على موقع بسيط. هنا يمكنني كسر الأشياء وإصلاحها دون أن يشتكي أي عميل. هذه هي الطريقة الوحيدة لبناء فهم حقيقي وعميق.

Modelprojects-data.js
→
Controllerrenderer.js
→
Viewindex.html

Chapter II: The Architecture

من HTML ثابت إلى محرك ديناميكي.

Evolution

ثابت مقابل ديناميكي

في البداية (v1.0)، كانت المحفظة تتكون من ملفات HTML منفردة. المشكلة: تغيير رابط في القائمة كان يتطلب التعديل في خمسة ملفات مختلفة. كان ذلك عُرضةً للأخطاء ولا يبدو «ذكياً».

الحل (v2.2): طبّقت مبدأ «لا تكرر نفسك» (DRY). بدلاً من ترميز المحتوى مباشرة في HTML، نقلته إلى هياكل بيانات منفصلة.

  • سابقاً: نسخ ولصق لكتل الكود.
  • اليوم: مصدر بيانات مركزي واحد (Single Source of Truth).

Struktur-Vergleich

📄
v1.0
index.html
about.html
contact.html
➝
⚙️
v2.2
renderer.js
+ data.json
Engineering

«محرك العرض»

أردت فهم آلية عمل الـ frameworks الحديثة (كـ React) في جوهرها. فبنيت نسخة مبسطة منها بنفسي.

النظام مبني على مبدأ فصل المسؤوليات (Separation of Concerns):

  • Data Layer: projects-data.js يحتفظ بجميع المعلومات (النصوص، مسارات الصور) ككائنات JSON.
  • Logic Layer: project-renderer.js يأخذ هذه البيانات ويبني HTML مباشرة في المتصفح.
  • View Layer: ملف index.html لم يعد سوى هيكل فارغ (حاوٍ).

هذا يتيح لي إضافة مشروع جديد بمجرد إضافة عنصر للمصفوفة — دون كتابة سطر HTML واحد.

project-renderer.js
01// Core Function: Renders projects into the DOM 02function initProjectRender() { 03 const container = document.getElementById("hero-container"); 04 05 // Filter current hero project from data 06 const heroItem = projectsData.find(p => p.id === HERO_ID); 07 08 if (container && heroItem) { 09 container.innerHTML = renderTemplate(heroItem); 10 } 11}

مقتطف من طبقة المنطق

Chapter III: Invisible Tech

ميزات تشعر بها لكن لا تراها.

إدارة الحالة

Custom i18n Engine

بدلاً من تحميل 500KB لمكتبة كـi18next، كتبت محركي الخاص.

  • Attribute Mapping: المحتوى مفصول عن HTML (data-i18n).
  • Persistence: اللغة تُحفَظ عبر localStorage بعد إعادة التحميل.
  • Fade-Transition: انتقال مبني على Promise يضمن أنيميشن سلساً بدلاً من وميض مزعج.
lang/de.json (Async Chunk)
{ "meta_c3_css_text": "Die Sprache bleibt dank localStorage..." }, "meta_c3_li_2": "Persistence..." } };

Logic Pipeline Visualization

if (heroItem) return renderHero(heroItem);
img/logo.png
→
Detect Path
→
../img/logo.png
Dynamic Rendering

Smart DOM Injection

يعمل project-renderer.js كـ mini-framework («Vanilla React»). يقرر وقت التشغيل ما سيُعرض.

من أبرز الميزات Path Normalization. بما أن المحرك يعمل على الصفحة الرئيسية (Root) وفي الأرشيف (Subfolder)، يُصلح مسارات الصور النسبية تلقائياً قبل حقنها في DOM. لا صور مكسورة أياً كان السياق.

Performance First

المحفظة يجب أن تكون سريعة. بتجنب الـ frameworks واستخدام تسريع الأجهزة (GPU) نحقق أعلى الدرجات.

100
Performance
100
Accessibility
100
Best Practices
100
SEO
نمط المراقب

كفاءة الموارد

أحداث التمرير تُطلَق مئات المرات في الثانية. هذا يستنزف بطارية الأجهزة المحمولة. حلّي: Intersection Observer API.

STATUS: IDLE
Triggered only when
visible in Viewport

⬆️ عرض حي: هذا الصندوق لم يُفعَّل إلا حين رأيته للتو. قبل ذلك كان يستهلك 0% من طاقة المعالج.

Architecture

Modern CSS & GPU

CSS أكثر من مجرد ألوان. أستخدم Custom Properties للثيمينغ العام. علاوة على ذلك، أجبر تشغيل الأنيميشن على كارت الشاشة (GPU) عبر transform: translate3d بدلاً من المعالج.

GPU

تسريع الأجهزة

.element {
  transform: translate3d(0,0,0);
  will-change: transform;
}

Chapter IV: DevOps & Workflow

الكود لا يكون جيداً إلا بقدر جودة العملية خلفه.

Git History (Main)

8a2b4frefactor: reorganize assets (DDD structure)
3c9d1efeat: impl dynamic renderer & i18n engine
b7a89cfix: mobile nav z-index conflict
1f0e2dmerge: branch 'dev/v2.2' -> 'main'v2.2.0
Version Control

Clean Commits

المحفظة تنمو بشكل عضوي. للسيطرة على الفوضى، أتبع استراتيجية Git صارمة.

  • Semantic Commits: كل commit يبدأ بـ feat: أو fix: أو chore:. هذا يجعل السجل قابلاً للقراءة.
  • Branching: الميزات الجديدة (كهذه الصفحة) تُطوَّر في branches معزولة قبل دمجها في main.
  • Safety: لا ينتقل أي كود للبناء النهائي دون اختبار (خادم حي محلي).
Structure

Domain Driven Design

في البداية كانت جميع الصور في مجلد واحد. الفوضى كانت محتومة.

خلال إعادة الهيكلة (v2.2)، رتّبت البنية. الأصول مجمّعة الآن منطقياً حسب نطاقها. هذا يجعل المشروع قابلاً للصيانة والتوسع لأي إضافات مستقبلية.

📂 images/ ├── 📂 ui/ // Logos, Profile ├── 📂 techstack/ // SVG Icons └── 📂 projects/     ├── 📂 phishing/     └── 📂 cv-engine/

بنية الملفات بعد إعادة الهيكلة

Chapter V: Infrastructure

الطريق إلى هويتي الرقمية (yusefbach.de).

توجيه DNS

من الهواية إلى الاحترافية

في البداية كان الموقع تحت yusef03.github.io. للحصول على حضور احترافي، كان لا بد من نطاق من المستوى الأعلى (TLD).

التحدي: GitHub Pages مُضيف ثابت. يجب بناء الجسر بين مزود النطاق وGitHub يدوياً. أستخدم A-Records متكررة (4 IPs لموازنة الحِمل) لضمان الاستمرارية.

DNS Zone FileTTL: 3600
TYPEHOSTPRIOVALUE
A@0185.199.108.153
A@0185.199.109.153
A@0185.199.110.153
CNAMEwww0yusef03.github.io

ضبط DNS لصفحات GitHub

«مشكلة الثبات»

فخ كلاسيكي مع GitHub Pages كلّفني أعصابي.

⚠️
المشكلة
أدخلت النطاق في إعدادات GitHub. كل شيء عمل. لكن بعد كل git push جديد، الإعداد كان يختفي والموقع يتوقف.

السبب: GitHub يُعيد كتابة الإعدادات اليدوية عند النشر.
✅
الحل: ملف CNAME
الحل هو ملف صغير باسم CNAME (بدون امتداد) في المجلد الجذر.

المحتوى: yusefbach.de

بهذا أصبح النطاق «محدداً بالكود». مهما نشرت، GitHub يعرف الآن: «هذا ملكي».

Chapter VI: The AI Brain

RAG Chat-Twin بدون أي dependencies.

Architecture

Python Serverless

Google Gemini 1.5 Flash API تعمل كـ microservice معزول على Vercel (FastAPI).

System Context Injection

قاعدة بيانات markdown («yusef_brain.md») توجّه النموذج اللغوي بصرامة نحو شخصيتي كمطور وبياناتي المهنية.

Vanilla Bot UI

الواجهة الأمامية تتواصل بشكل غير متزامن عبر pipeline fetch خاص. واجهة Glassmorphism مبنية بالكامل بدون React أو حزم خارجية.

Context Safety

ترويسات CORS وتوجيهات النموذج الصارمة تمنع الإساءة (Prompt Injection).

RAG_PIPELINE.flow

User
(Glassmorphism)
⚙️ Vercel Serverless
Failover Array
yusef_brain
(Context JSON)
Gemini API

Chapter VII: Future Roadmap

الكود لا يكتمل أبداً. الرحلة مستمرة.

خارطة الطريق الحالية للمحفظة — ما القادم وما تم تسليمه.

🗺️ عرض خارطة الطريق →

Ready for
Production

هذه المحفظة دليل على أنني مستعد لتحويل النظرية إلى قيمة حقيقية.

لنعمل معاً إلى الصفحة الرئيسية