محمد علاء محسن

مطوّر Python Backend — Django وDRF· تسليم Full-Stack مدعوم بالذكاء الاصطناعي

أبني المنتج كاملاً: واجهة API بـ Django REST Framework، وواجهة React/TypeScript مبنية بأدوات الذكاء الاصطناعي ومدموجة بيدي، وخادم Linux يشغّل كل ذلك. أكثر من ثلاث سنوات مع Python، ومنتج واحد في الإنتاج.

StoryHub — the landing page
يعمل في الإنتاج

StoryHub

مكان هادئ لكتابة القصص وقراءتها.

منصة كتابة ثنائية اللغة بطبقة اجتماعية — واجهة DRF وتطبيق React على خادم جهّزته وأشغّله بنفسي.

storyhubapp.comجارٍ الفحص افتح StoryHub ↗
7تطبيقات backend
41نقطة نهاية API
85اختباراً آلياً
24صفحة واجهة
سبتمبر 2026يعمل منذ
كيف يتركّب المنتج
واجهة APIDjango REST Frameworkبنيتها بنفسي
الواجهةReact 19 · TypeScriptبأدوات الذكاء الاصطناعي · دمجتها بنفسي
الخادمNginx · systemd · PostgreSQLجهّزته وأشغّله بنفسي
عدّة العمل
PythonDjangoDjango REST FrameworkRESTful API DesignPostgreSQLRedisCeleryJWT / OAuth 2.0React 19PythonDjangoDjango REST FrameworkRESTful API DesignPostgreSQLRedisCeleryJWT / OAuth 2.0React 19
TypeScriptViteTailwind CSSNginxsystemdLinuxGitHub ActionsOpenAPIPWATypeScriptViteTailwind CSSNginxsystemdLinuxGitHub ActionsOpenAPIPWA
الجاهزية
المقرغزة، فلسطين
اللغاتالعربية · الإنجليزية
متاح لـعمل Backend وFull-stack عن بُعد
للتعاقدBrightGaza ↗
GitHubCI ناجح

7 مشاريع بنيتها بنفسي

تطبيقات Django، ومختبر مرجعي لـ DRF، ومشروع رئيسي تعمل اختباراته عند كل push.

github.com/MohammedAMohsen
نبذة

خرّيج علوم حاسوب من غزة. أبني أنظمة Backend تصل إلى الإنتاج — والواجهات من حولها.

تخرّجت من الجامعة الإسلامية بغزة عام 2025، وأعمل بـ Python منذ أكثر من ثلاث سنوات. بدأت باللغة نفسها وشهادة Google في أتمتة تقنية المعلومات بـ Python، ثم قواعد البيانات العلائقية، ثم أول Backend بـ Flask قبل أن أستقر على Django. واليوم أُسلّم منتجات كاملة: واجهة Django REST Framework، وواجهة React مبنية بأدوات الذكاء الاصطناعي، وخادم Linux أجهّزه وأشغّله بنفسي.

الجزء الذي يهمّني أكثر في أي نظام هو الجزء الذي يجب أن يكون صحيحاً: نموذج البيانات، ومن يحق له رؤية ماذا، والاستعلامات التي تقرر إن كانت الصفحة سريعة. وأكتب سبب كل قرار في docstrings وملفات README وإجراءات التشغيل، حتى يفهم المشروعَ من يستلمه بعدي دون أن يسأل.

المسار حتى الآن
  1. Python
  2. Python المتقدمة
  3. شهادة Google
  4. قواعد البيانات
  5. أول Backend — Flask
  6. Django وDRF
  7. منتجات كاملة
  8. نشر حي على VPS
الأعمال

منتج حي، ومتجر كامل، وخمسة مشاريع أخرى.

كل مشروع بنيته بنفسي وهو مفتوح على GitHub. StoryHub في الإنتاج، وينشر عليه كتّاب حقيقيون.

دراسة حالة 01 · المشروع الرئيسي

StoryHub

مكان هادئ لكتابة القصص وقراءتها.

منصة للكتابة الطويلة مع طبقة اجتماعية — متابعة، إعجابات، تعليقات متفرّعة، حفظ، إشعارات — ثنائية اللغة بالكامل (عربي/إنجليزي) مع تخطيط من اليمين إلى اليسار، وقابلة للتثبيت كتطبيق (PWA). واجهة Django REST Framework وتطبيق React + TypeScript، يعملان على خادم Linux جهّزته وأشغّله.

يعمل منذ 14 سبتمبر 2026 7 تطبيقات 41 نقطة نهاية 85 اختباراً 24 صفحة EN / AR · RTL PWA
الـ Backendصمّمته وبنيته بنفسي

نموذج البيانات، التطبيقات السبعة كلها، كل نقطة نهاية، المصادقة، Celery، الكاش — والاختبارات الـ 85.

الواجهةبُنيت بأدوات الذكاء الاصطناعي، ودمجتها بنفسي

صُمّمت بأداة تصميم بالذكاء الاصطناعي وكُتبت بأدوات برمجة بالذكاء الاصطناعي — دون أي مطوّرين آخرين. أما ربطها بالـ API — العقد، تدفق المصادقة، أشكال البيانات — فمن عملي.

الإنتاججهّزته وأشغّله بنفسي

الخادم، Nginx، systemd، PostgreSQL، النسخ الاحتياطي باسترجاع مُجرَّب، وطبقة SEO.

أبرز ما في الهندسة

ستة أشياء في StoryHub تُظهر طريقة عملي — افتح أيّاً منها؛ وحيث يوجد كود، فهو أمامك مباشرة.

01 الصلاحيات قاعدة واحدة تقرر من يقرأ القصة

التغذيات وصفحات الكتّاب والروابط المباشرة والإعجابات والتعليقات والحفظ وخريطة الموقع، كلها تسأل دالة queryset واحدة هي visible_to(). إضافة القصص «للمتابعين فقط» عنت تعديل موضع واحد لا سبعة.

backend/apps/stories/models.py
class StoryQuerySet(models.QuerySet):
    """The one place that knows who may read a story."""

    def visible_to(self, user, *, with_own_unpublished=False):
        published = Q(status=Story.StatusChoices.PUBLISHED)
        public = Q(visibility=Story.VisibilityChoices.PUBLIC)
        if user is None or not user.is_authenticated:
            return self.filter(published & public)
        follows_author = Exists(
            Follow.objects.filter(follower=user, following=OuterRef("author_id"))
        )
        allowed = published & (public | Q(author=user) | Q(follows_author))
        if with_own_unpublished:
            allowed |= Q(author=user)
        return self.filter(allowed)
02 ORM والأداء حالة التفاعل تُحسب في قاعدة البيانات

الإعجاب والحفظ والمتابعة تُلحَق بالاستعلام عبر Exists/OuterRef — استعلام واحد للصفحة بدل استعلام لكل عنصر. وعدّ المتابعين يستخدم Subquery بعد أن ضخّم Count عبر join الأرقام.

3 فحوصات × كل قصة ← استعلام واحد للصفحة
03 البحث والمشاركة تطبيق صفحة واحدة يقرؤه Google وواتساب

Django يقدّم الهيكل المبني مع <head> مُعاد كتابته لكل مسار — العنوان، Open Graph، الرابط القانوني، JSON-LD — مع خريطة موقع تعيد استخدام قاعدة الرؤية، وmiddleware يضع X-Robots-Tag بدل حجب الـ API في robots.txt.

backend/config/robots.py
# Crawlers must be allowed to *fetch* the API; what they
# must not do is list its JSON as pages.
NOINDEX_PREFIXES = ("/api/", "/auth/", "/admin/")

class NoIndexApiMiddleware:
    def __call__(self, request):
        response = self.get_response(request)
        if request.path.startswith(NOINDEX_PREFIXES):
            response["X-Robots-Tag"] = "noindex, nofollow"
        return response
04 الأمان تعقيم HTML مرة واحدة عند الكتابة

نصوص القصص تُنظَّف وفق قائمة سماح (nh3) قبل تخزينها، فلا يحتاج أي مسار قراءة — الـ API، لوحة الإدارة، أي تصدير لاحق — أن يتذكّر الهروب من شيء.

16 وسماً مسموحاً · script وstyle وiframe تُحذف مع محتواها
05 المصادقة تسجيل الدخول بـ Google يُتحقق منه على الخادم

رموز ID تُفحص بـ google-auth، والبريد الموثّق شرط، وأسماء المستخدمين تُولَّد عند التعارض، وحسابات Google فقط تحصل على تدفق تعيين كلمة مرور بدل تغييرها.

has_usable_password ← «تعيين كلمة مرور» أو «تغييرها»
06 التشغيل سكربت نشر لا يستطيع كسر نفسه

deploy.sh يعمل كدالة bash واحدة تُستدعى في سطره الأخير — لأن git pull استبدل مرةً السكربت الجاري في منتصفه فتخطّى خطوة بصمت.

deploy/deploy.sh
# A function is parsed whole before it runs, so the copy
# in memory is the one that finishes — even if `git pull`
# replaces this file midway.
set -euo pipefail

deploy() {
    $RUN_AS git -C "$APP" pull --ff-only
    $RUN_AS bash -c "cd '$APP/backend' && .venv/bin/python manage.py migrate"
    $RUN_AS bash -c "cd '$APP/frontend' && npm ci && npm run build"
    systemctl restart storyhub-web storyhub-worker
}

deploy "$@"
في الإنتاج

خادم واحد، نطاق واحد، وكل خدمة في حسابها.

Nginx يقدّم الواجهة المبنية والملفات الثابتة ويمرّر الـ API إلى Gunicorn؛ وبجانبه PostgreSQL وRedis وعامل Celery كوحدات systemd معزولة. نسخة احتياطية ليلية تُنسخ إلى تخزين خارجي، وجُرّب الاسترجاع قبل الإطلاق. CI يشغّل الاختبارات والبناء عند كل push؛ والنشر نفسه سكربت بأمر واحد عبر SSH — يدوي عمداً عند هذا الحجم.

  • Nginxيقدّم التطبيق ويمرّر الـ API
  • Gunicornيشغّل Django
  • PostgreSQLقاعدة البيانات
  • Redisالكاش ووسيط Celery
  • Celeryالبريد خارج مسار الطلب
  • systemdوحدات معزولة بترتيب اعتماد
  • Let’s EncryptTLS وHSTS ورؤوس الأمان
  • Backblaze B2نسخ ليلية خارجية
  • Resendبريد بـ SPF وDKIM وDMARC
  • UptimeRobotفحص كل خمس دقائق
  • GitHub Actions85 اختباراً + بناء الواجهة، عند كل push
الواجهة

صُمّمت بـ Google Stitch وأُعيد بناؤها بـ Claude، ثم دمجتها مع الـ API بنفسي: وضع فاتح وداكن مبني على رموز، تخطيط من اليمين إلى اليسار يُعامل كبيانات، تحديثات متفائلة تبقى متزامنة في كل القوائم، محرّر Tiptap برفع صور مضمّن، العربية والإنجليزية عبر i18next، وservice worker للتثبيت.

العدّة
Django 6DRF 3.17DjoserSimpleJWTCeleryRedisPostgreSQLnh3drf-spectacularReact 19TypeScriptViteTailwind v4TanStack QueryZustandRadix UITiptapi18next
دراسة حالة 02 · متجر إلكتروني

GreatCart

متجر إلكتروني كامل، مُصيَّر على الخادم.

كتالوج بتنويعات اللون والمقاس، سلة تعمل قبل تسجيل الدخول وبعده، دفع محاكى بمحفظة تجريبية، طلبات ومخزون، مراجعات من المشترين فقط، فاتورة بالبريد، ولوحة عميل — Django تقليدي: قوالب ونماذج وجلسات.

5 تطبيقات12 نموذج بياناتقوالب Django + BootstrapSQLiteفواتير SMTP

سلة الزائر تنجو من تسجيل الدخول

الزائر يحصل على سلة مرتبطة بالجلسة؛ وعند تسجيل الدخول تُدمج في سلة المستخدم. العناصر تُطابَق بمجموعة تنويعاتها الكاملة، فقميص أزرق بمقاس Large ونفس القميص بمقاس Medium يبقيان سطرين منفصلين — لا دمج خاطئ ولا تكرار.

سلة الزائر · جلسةقميص · أزرق · Lقميص · أزرق · M
+
سلة المستخدمقميص · أزرق · L
دمج بمجموعة التنويعاتقميص · أزرق · L ×2قميص · أزرق · M ×1سطران، بلا تكرار

دورة طلب لا تخصم مرتين ولا تبيع ما ليس في المخزون

يُتحقق من المخزون قبل الدفع ويُخصم بعده؛ الطلب المدفوع لا يُدفع ثانية؛ الطلب المعلّق يُستأنف؛ التنويعات تُجمَّد داخل الطلب كلقطة JSON فلا تعيد تعديلات الكتالوج اللاحقة كتابة التاريخ؛ وفاتورة HTML تُرسل بالبريد.

  1. 1السلة
  2. 2الدفع + الضريبة
  3. 3فحص المخزون
  4. 4الدفع (محاكاة)
  5. 5خصم المخزون
  6. 6فاتورة بالبريد

مراجعات ممّن اشترى فقط

لا يراجع العميل منتجاً إلا بعد طلب يحويه؛ مراجعة واحدة لكل عميل قابلة للتعديل؛ ومتوسط التقييم تجميع في الاستعلام لا عدّاد مخزّن.

هل طلب هذا المنتج؟
✓مراجعة واحدة، قابلة للتعديل
✕قراءة فقط
rating = ReviewRating.objects.filter(product=p).aggregate(Avg("rating"))

في المشروع أيضاً: نموذج مستخدم مكتوب من الصفر — AbstractBaseUser ومدير بـ create_user/create_superuser — وتفعيل بريد مبني يدوياً بـ urlsafe_base64_encode ومولّد رموز Django.

!بوابة الدفع محاكاة — محفظة تجريبية تُدار بطلب JSON. التدفق حقيقي؛ المال ليس كذلك.

أعمال أخرى

ثلاثة تطبيقات ومختبرا تعلّم.

المختبران دراسة لإطار عمل لا منتجان، ومُسمّيان كذلك. طبقة المصادقة في StoryHub نشأت منهما.

تطبيقات مختبرات تعلّم
المهارات

عمق في الـ Backend، وقدرة على تسليم المنتج كاملاً.

Django وDjango REST Framework هما حيث أتعمّق أكثر. والبقية هي ما يجعلني أُسلّم منتجاً كاملاً لا واجهة API فقط.

Backend وواجهات API
DjangoDjango REST FrameworkRESTful API DesignOpenAPI / SwaggerCeleryRedisTransactional EmailQuery Optimization
المصادقة والبيانات
JWT / OAuth 2.0DjoserPostgreSQLMySQLSQLiteCustom Permissions
حِرفة الـ API
Filtering & SearchPaginationCaching StrategiesThrottlingQuery Profiling (Silk)Testing · pytest
تسليم Full-Stackبأدوات الذكاء الاصطناعي
React 19TypeScriptViteTailwind CSSTanStack QueryZustandi18n & RTLPWA
الإنتاج والأدوات
GitGitHub Actions (CI)LinuxNginxsystemdTLSBackups & RestoreTechnical SEODocker — قيد التدريب
التعليم والشهادات

درجة جامعية وشهادات — جميعها قابلة للتحقق.

أدوات الذكاء الاصطناعي جزء من يومي في العمل، والشهادة أدناه من الشركة صانعة Claude.

كيف أعمل

نموذج البيانات أولاً، ثم العقد، ثم الفحص قبل كل إصدار.

01

أبدأ من نموذج البيانات

قبل أن توجد أي نقطة نهاية، تُحسم البنية وقواعد الوصول: العلاقات، والقيود المفروضة في قاعدة البيانات نفسها، ومكان واحد يجيب عن سؤال «من يحق له رؤية ماذا». كل ما بعد ذلك يُبنى فوق هذا الأساس.

02

واجهات الـ API تُصمَّم كعقود

الموارد ورموز الحالة والترقيم والتصفية وحدود المعدل تُقرَّر مسبقاً، ومخطط OpenAPI يُولَّد من الكود — فتبني الواجهة الأمامية، وأي عميل آخر، على وثيقة حقيقية لا على تخمين.

03

لا شيء يُنشر بلا اختبارات وفحوص

طقم اختبارات يركّز على المصادقة والصلاحيات والرؤية؛ manage.py check --deploy بصفر تحذيرات؛ CI يشغّل الاختبارات وبناء الواجهة عند كل push؛ نشر من سكربت موثّق؛ ونسخ احتياطي باسترجاع جُرّب فعلاً.

04

الواجهة بأدوات الذكاء الاصطناعي — والدمج بيدي

أصمّم الشاشات بأداة تصميم بالذكاء الاصطناعي وأبني الواجهة الأمامية بأدوات برمجة بالذكاء الاصطناعي؛ دون أي مطوّرين آخرين. أما ما لا يُفوَّض فهو من عملي: عقد الـ API، وتدفق المصادقة، وأشكال البيانات. ومساعدة الذكاء الاصطناعي مذكورة صراحةً في README كل مشروع.

05

كل ما يهم مكتوب

القرارات والمفاضلات وإجراءات التشغيل موثّقة بالعربية أو الإنجليزية، بوضوح يكفي ليستلم زميلٌ المشروعَ دون مكالمة. أعمل بأفضل صورة كتابةً وبشكل غير متزامن. وأضيف Docker حالياً إلى عدّتي.

تواصل

لنبنِ المنتج كاملاً.

متاح لعمل Backend وFull-stack عن بُعد. تواصل معي دون تردد — اللغة لن تكون حاجزاً بيننا.

dev.albasha@gmail.com ↗