أعمالنا
أعمالنا
مواقع وتطبيقات وأنظمة — تُصمَّم وتُبنى وتُدعَم على طريقة Virius.
موقع إلكترونيدیکوراس
- التحدي:
- كان الحصول على مواد البناء والتشييد في العراق مشتتاً ويدوياً، ولم يكن لدى العملاء مكان واحد وموثوق لتصفح المنتجات ومقارنة العلامات التجارية والطلب مع خدمة التوصيل. كانت الشركة بحاجة إلى منصة موحدة تخدم كلاً من العملاء الأفراد وحسابات الشركات (B2B)، مع تحكم إداري كامل في المنتجات والطلبات والعمليات.
- ما بنيناه:
- منصة متكاملة من البداية للنهاية: واجهة متجر للعملاء (ويب + تطبيقات هواتف محمولة بتقنية Flutter لنظامي iOS و Android)، ولوحة تحكم إدارية كاملة لإدارة المنتجات والطلبات والعلامات التجارية والعملاء المحتملين وحسابات الشركات، وواجهة برمجة تطبيقات خلفية (Backend API) آمنة بتقنية NestJS. تشمل الميزات أذونات مبنية على الأدوار، تتبع الطلبات، دعم لغات متعددة (الإنجليزية، العربية، الكردية)، إشعارات الدفع، ومفتاح إيقاف التطبيق من جهة الخادم (kill-switch) للصيانة والتحكم في التحديث الإجباري.
- النتيجة:
- تسليم منصة تعمل بكامل طاقتها: يمكن للعملاء الآن تصفح مواد البناء وطلبها وتتبعها عبر الإنترنت لأول مرة، بينما تكتسب الشركة تحكماً كاملاً في المنتجات والطلبات والعمليات من خلال لوحة تحكم الإدارة. متوفرة حالياً على الويب وApp Store وGoogle Play.
تطبيقمكتب علي شوفرليت
- التحدي:
- كان العثور على قطعة غيار شوفرليت أو GMC أو كاديلاك في أربيل يتطلّب الاتصال بعدّة محلات أو التنقّل بينها، دون معرفة ما هو متوفر فعلاً ولا كم سعره. لم يكن بإمكان الزبون مقارنة الحالة أو السعر قبل الطلب، وكان كل طلب يمرّ عبر مكالمة هاتفية. احتاج المحل إلى مكان واحد يرى فيه أصحاب السيارات والميكانيكيون وورش التصليح المخزون الحقيقي ويطلبون منه دون مغادرة الورشة.
- ما بنيناه:
- تطبيق موجّه للزبائن على iOS وأندرويد، مبني حول كتالوج قطع الغيار المحدَّث لدى المحل. تشمل الميزات التصفّح حسب السيارة والفئة، وعرض السعر والحالة والتوفّر على كل قطعة، والمحادثة المباشرة مع البائع، وسلة ومسار طلب كامل، وواجهة عربية أولاً مصمّمة للزبون المحلي.
- النتيجة:
- صار بإمكان الزبائن تصفّح المتوفر ومعرفة الأسعار والحالة وطلب القطع من هواتفهم، بدل الاتصال بمحلات المدينة واحداً تلو الآخر. ويدير المحل الطلبات وأسئلة الزبائن في مكان واحد بدل مكالمات متفرقة. متوفر على Google Play وApp Store.
نظامنظام الصرافة
- التحدي:
- كانت الأسعار تُكتب على لوح أبيض وتُتداول عبر رسائل واتساب. كان على الزبائن الاتصال أو الحضور شخصياً لمجرد السؤال عن السعر، وكان الموظفون يجيبون على السؤال نفسه عشرات المرات يومياً. تُدوَّن المعاملات في دفاتر ثم تُنقل لاحقاً إلى جداول إكسل، فلا يتطابق إقفال اليوم مع ما في الصندوق إلا بعد بحث طويل عن الفارق. ولم يكن بالإمكان معرفة من غيّر سعراً ولا متى.
- ما بنيناه:
- صفحة أسعار عامة تُحدَّث في اللحظة نفسها التي يتغيّر فيها السعر من النظام الداخلي، بالكردية والعربية والإنجليزية، ومبنية للهاتف أولاً لأن الزبائن يتابعون الأسعار من هواتفهم. لوحة تحكم لضبط أسعار الشراء والبيع لكل عملة، مع التحكم بهامش السعر وسجل كامل للتغييرات. سجل معاملات مع إيصالات مطبوعة، وحسابات صرّافين تسمح بتسجيل المعاملات دون تعديل الأسعار، وتقرير إقفال يومي بضغطة واحدة يُطابَق مع الصندوق.
- النتيجة:
- صار تغيير السعر يتم في مكان واحد بدل خمسة، ويصل إلى الزبون قبل أن يصل إلى الشباك. وصار إقفال اليوم تقريراً بدل بحث، ولكل تغيير في السعر اسم ووقت.
نظامأولالا شوبينغ - نظام نقاط البيع والمخزون
- التحدي:
- كان المخزون في دفتر وفي ذاكرة صاحبة المتجر. أحمر شفاه واحد هو اثنتا عشرة درجة لون، والكريم الواحد ثلاثة أحجام، فكان الصنف الواحد يملأ نصف صفحة ولا يعيد أحد عدّه. وكانت ديون الزبائن تُكتب على الورق وتُسوّى بالذاكرة. وكانت كل شحنة تصل بسعر مختلف، فصارت التكلفة الحقيقية للصنف تخميناً، والربح عليه تخميناً كذلك. ومستحضرات التجميل تنتهي صلاحيتها، لكن لم يكن شيء يتتبّع ما قارب على الانتهاء، فكان يُكتشف على الرف بعد فوات الأوان. وفي آخر اليوم كان النقد في الصندوق يُعدّ من دون ما يقابله، وإذا نقص لم تكن هناك طريقة لمعرفة من أين.
- ما بنيناه:
- نقطة بيع تبيع نقداً أو بالدين، بالكردية والإنجليزية مع دعم كامل للاتجاه من اليمين إلى اليسار، لأن من يقف خلف الكاونتر يعمل بالكردية. تحمل الأصناف درجات ألوانها وأحجامها كخيارات حقيقية تُختار من لوحة ألوان، فيصير أحمر الشفاه صنفاً واحداً لا اثني عشر سطراً. وكل شحنة تُحدّث تكلفة الصنف كمتوسط مرجّح، فيُحتسب الربح على ما كلّفه المخزون فعلاً لا على آخر فاتورة. وتُسجَّل الصلاحية لكل شحنة على حدة مع الأيام المتبقية وإمكانية الشطب بضغطة واحدة. وللموردين وديون الزبائن والمصروفات والخسائر سجلّ مستقل لكل منها، ويُقفل اليوم بتقرير يطابق الصندوق. ولا ترى حسابات المالكة والصرّافات إلا الصفحات الممنوحة لها، وكل حركة مخزون تحمل اسماً ووقتاً.
- النتيجة:
- يُعدّ المخزون مرة واحدة ويبقى معدوداً. تُباع درجة اللون فتنزل من الرف في النظام في اللحظة نفسها. ويُقفل اليوم بتقرير بدل بحث، وإذا نقص الصندوق أظهر النظام من أين. لكل دَين اسم، ولكل تكلفة فاتورة خلفها، والصنف القريب من انتهاء صلاحيته يُنبَّه عليه قبل أن يُرمى لا بعده.
تطبيقچيا مزاد - استيراد السيارات وتتبّعها
- التحدي:
- تستورد چيا مزادي السيارات من مزادات أمريكا إلى كردستان. وكل سؤال يطرحه المشتري - أين سيارتي؟ كم ستكلّفني عند الوصول؟ كم بقي عليّ؟ - كان يُجاب عنه بمكالمة أو رسالة واحدة تلو الأخرى. وكانت الأسعار تُحسب يدويًا من جداول شحن تتغيّر كل شهر، فتغيّر سعر واحد يعني إعادة الحساب كاملًا مع احتمال إعطاء العميل رقمًا خاطئًا. وخارج سجلات صاحب المعرض، لم يكن أحد يرى الوضع الحقيقي لأي شحنة ولا الرصيد المتبقي عليها.
- ما بنيناه:
- تطبيق Flutter للعملاء ولوحة إدارة Laravel لصاحب المعرض. يتابع العميل سيارته عبر خمس مراحل - الشراء، الكراج في أمريكا، التحميل، الشحن، الوصول - مع خط زمني مباشر، وتفصيل التكاليف خلف المبلغ الإجمالي، ومراحل الدفع، ووصل PDF يحمّله بنفسه. وتحسب الحاسبة سعر السيارة قبل شرائها على المسارين، أمريكا إلى مرسين وأمريكا إلى دبي، اعتمادًا على أسعار الشحن والسحب والتخليص الخاصة بصاحب المعرض. وهذه الأسعار موجودة في لوحة الإدارة يعدّلها بنفسه، فتغيير الشهر يستغرق دقائق ولا يحتاج مبرمجًا ولا إصدارًا جديدًا. كما يتيح سوق خاضع للمراجعة للعملاء عرض سياراتهم للبيع. الكردية والعربية والإنجليزية بالكامل مع دعم اتجاه الكتابة من اليمين إلى اليسار، ووضعان فاتح وداكن مكتملان. وتضع لوحة الإدارة العمل كله في شاشة واحدة: أعمار الذمم، والمبالغ المحصّلة، وقيمة البضاعة في الطريق، والمدة الفعلية لكل مرحلة.
- النتيجة:
- قيد الاستخدام اليومي الفعلي: ٢٢ عميلًا و٢٠ سيارة تُتابَع مباشرة عبر المراحل، وكل دفعة ورصيد متبقٍّ في سجل واحد بدل الدفتر. اختفى سؤال «أين سيارتي؟» - إذ يفتح العميل الخط الزمني بنفسه. وأسعار الشحن التي تتغيّر شهريًا صار صاحب المعرض يحدّثها في دقائق، فيخرج كل عرض سعر بالأرقام الحالية بدل حساب يدوي.
تطبيقسيواك
- التحدي:
- كانت الطلبات تصل بالاتصال ورسائل واتساب. يرسل الزبون صور جواز السفر والفيزا داخل محادثة، فتبقى تلك الصور في معرض هاتف أحد الموظفين، دون طريقة سليمة لحذفها ودون تحكّم بمن يراها. ولم تكن هناك قائمة تبيّن من طلب ماذا ولا أيّ الطلبات ما زال مفتوحاً - كان ذلك كله في ذهن من يردّ على الهاتف. والدفع يُرتَّب في كل مرة على حدة. أما الجمهور الذي يفتح هاتفه عدة مرات يومياً ليعرف وقت الصلاة، فلم يكن لديه سبب يفتح به شيئاً يخصّ العمل.
- ما بنيناه:
- تطبيق بالكردية أولاً للآيفون والأندرويد - واجهة كاملة من اليمين إلى اليسار بالسورانية، ومعها العربية والإنجليزية، بوضع فاتح وآخر داكن. الطلب يتم داخل التطبيق: يملأ الزبون الاستمارة، ويرفق صور الجواز والفيزا، ويدفع عبر كي كارد أو FIB أو فاست باي. وتُحفظ هذه المستندات في تخزين خاص لا في محادثة؛ يفتحها الموظف عبر روابط مؤقتة من لوحة التحكم، وتُحذف بعد إنجاز الطلب. ومواقيت الصلاة حسب موقع المستخدم نفسه مع إشعارات الأذان واختيار القارئ، وبوصلة للقبلة. وصفحة صور فقط ينشر فيها المستخدمون ويعجبون، بإعجاب واحد لكل شخص على الصورة الواحدة وسبعة منشورات في الأسبوع، مضبوطة على الخادم لا داخل التطبيق، مع أدوات للإبلاغ والحذف. ولوحة تحكم لمتابعة الطلبات وإدارة المحتوى ومعرفة ما زال مفتوحاً.
- النتيجة:
- صارت الطلبات تصل إلى مكان واحد ومعها مستنداتها، بدل محادثة وصور في معرض أحدهم. وخرجت المستندات الحسّاسة من الهاتف: تُحفظ في تخزين خاص، وتُفتَح بروابط تنتهي صلاحيتها، وتُحذف عند إغلاق الطلب. وصار الدفع يتم في لحظة الطلب لا في حديث منفصل. وصار للعمل سبب يجعله على هاتف الزبون كل يوم، عبر مواقيت الصلاة، لا حين يحتاج إليه فقط.
تطبيقسوز استیر
- التحدي:
- معهد فيه عدد من المدرّسين وأرشيف متنامٍ من الدورات المسجّلة، دون مكان واحد لبيعها وإيصالها. كان تحصيل المدفوعات يدوياً، والفيديو يُنسخ بسهولة بمجرّد خروجه، ولا يوجد سجل موثوق لمن اشترى ماذا ولا لما يستحقّه كل مدرّس. كما أن طلابهم يقرأون بأربع لغات مختلفة، فتطبيق بالإنجليزية وحدها لم يكن خياراً من الأساس.
- ما بنيناه:
- تطبيق لنظامَي iOS و Android بـ Flutter، وخلفه Laravel و Filament. يتصفّح الطالب الدورات المميّزة والمواد والباقات والمدرّسين، ويبحث في كامل الأرشيف، ويسجّل خلال ثوانٍ. الدفع عبر FIB: يمسح رمز الـ QR من تطبيق مصرفه، فيُفتح الوصول تلقائياً. تُبثّ الدروس عبر Bunny بروابط موقّعة، مع حظر تصوير الشاشة وعلامة مائية على المشغّل. يُحفظ التقدّم درساً بدرس، ويعلّق الطلاب أسفل كل درس، ويردّ المدرّس ويثبّت أهم الإجابات، وتعيد الإشعارات الفورية الطالب مباشرة إلى مكانه في التطبيق. كل ذلك يعمل بالإنجليزية والكردية السورانية والكردية البادينية والعربية، بتخطيط حقيقي من اليمين إلى اليسار، لا مجرّد نصوص مترجمة داخل تصميم مبني للاتجاه المعاكس. وللمدرّسين جانبهم الخاص: صافي الأرباح بعد عمولة المعهد، وتوزيع الإيرادات لكل دورة، وعدد الطلاب، وكل التعليقات في مكان واحد. أما لوحة التحكّم فتتولّى الباقي: ترقية مستخدم إلى مدرّس، وإسناد دوراته، وتحديد العمولة، ورفع الدروس، وإدارة التعليقات، وإرسال إعلان إلى الجميع دفعة واحدة.
- النتيجة:
- يعمل المعهد اليوم على نظام واحد. يدفع الطالب فيحصل على الوصول دون أن يؤكّده أحد يدوياً. وتُبثّ الدروس بروابط موقّعة، فلم تعد ملفات الدورات تتنقّل بين الناس. وتُسجَّل كل عملية بيع باسم طالب ومدرّس، ما يحوّل توزيع الإيرادات إلى عملية حسابية بدل أن يكون نقاشاً. والمعهد نفسه يضيف الدورات والدروس والأسعار والإعلانات، باللغات الأربع، دون العودة إلينا.
تطبيقMuxlis Course
- التحدي:
- كانت الدورات تُباع وتُسلَّم يدوياً. كل تسجيل يعني رسالة، وصورة إثبات دفع، ومجلداً مشاركاً - وما إن يخرج الرابط حتى يبدأ بالتنقل بين الطلاب. ولم تكن لدى المدرّسين وسيلة لمعرفة ما استحقوه، فكانت كل تسوية تنتهي بنقاش. ولم يكن أحد يستطيع أن يقول كم طالباً في الدورة فعلاً.
- ما بنيناه:
- تطبيق للطلاب ولوحة تحكّم للمعهد. يتصفح الطالب الدورات، ويدفع داخل التطبيق، ويشاهد الدروس عبر روابط موقّتة مرتبطة بحسابه، فتبقى ملفات الدورة في مكانها. وتُسجَّل كل عملية بيع باسم طالب ومدرّس. وللمدرّسين واجهتهم الخاصة: صافي الأرباح بعد عمولة المعهد، والإيرادات لكل دورة، وعدد الطلاب، وكل التعليقات في مكان واحد. أما الباقي فيديره المعهد من اللوحة - ترقية مستخدم إلى مدرّس، وإسناد الدورات إليه، وتحديد العمولة، ورفع الدروس، وإدارة التعليقات، وإرسال إعلان واحد إلى الجميع دفعة واحدة. كل ذلك يعمل بالإنجليزية والكردية السورانية والكردية البادينية والعربية، بتخطيط حقيقي من اليمين إلى اليسار، لا مجرّد نص مترجم داخل تصميم مبني للاتجاه المعاكس.
- النتيجة:
- يعمل المعهد اليوم على نظام واحد. يدفع الطالب فيحصل على الوصول دون أن يؤكّده أحد يدوياً. وتُثبَّت الدروس بروابط موقّتة، فلم تعد ملفات الدورات تنتقل بين الناس. وتُسجَّل كل عملية بيع باسم طالب ومدرّس، ما يحوّل توزيع الإيرادات إلى عملية حسابية بدل أن تكون نقاشاً. والمعهد نفسه يضيف الدورات والدروس والأسعار والإعلانات، باللغات الأربع، دون العودة إلينا.
نظامنظام إدارة معارض السيارات
- التحدي:
- كانت عمليات المعرض موزّعة على جداول منفصلة. لكل سيارة أساس تكلفة مختلف - سعر الشراء، تكاليف الاستيراد من دبي، أعمال الصيانة، المصاريف المرتبطة - فلم يكن أحد قادرًا على تحديد الربح الفعلي لعملية بيع واحدة. الأقساط تُتابَع يدويًا، ورسوم التأخير تُطبَّق بشكل غير متسق، والمجاميع الشهرية لا تتطابق أبدًا. الشرط الأساسي كان أن يكون للمال مصدر حقيقة واحد: الرقم المسجَّل لحظة البيع حقيقة تاريخية لا يجوز أن تتغير بصمت عند تعديل معادلة لاحقًا.
- ما بنيناه:
- واجهة برمجية بـ Express وTypeScript على PostgreSQL مع ترحيلات Knex، ومصادقة JWT برموز وصول وتحديث، وصلاحيات حسب الدور للمدير والمشرف والموظف، ومهام مجدولة تعالج الأقساط المتأخرة وتعيد حساب درجة مخاطر العميل ليلًا. الواجهة تطبيق أحادي الصفحة بـ React 18 وVite مع TanStack Query وZustand وReact Hook Form وZod وTailwind وRecharts. كل معادلة مالية تعيش في وحدة مرجعية واحدة، مع نسخة في الواجهة للمعاينة فقط، وفحص آلي يُفشل عملية البناء إذا تسرّب أي حساب إلى مكان آخر. فوق ذلك: معالجات متعددة الخطوات لعروض الأسعار والمبيعات، توليد تلقائي لجداول الأقساط، احتساب رسوم التأخير بالأيام، تحليل الربح لكل سيارة، تصدير Excel وPDF، وطبقة ترجمة كردية سورانية تغطي الواجهة بالكامل. تنشئ مجموعة الاختبارات قاعدة بيانات PostgreSQL مؤقتة، وتشغّل الترحيلات الحقيقية على استعلامات SQL حقيقية، ثم تحذف نفسها - فالاختبارات المالية تتحقق من المنطق الفعلي لا من محاكاة.
- النتيجة:
- صار هناك نظام واحد يجيب عمّا عجزت الجداول عنه: كم كلّفت سيارة بعينها وكم ربحت فعليًا، وأي العملاء يمثّل مخاطرة بحسب التأخير والنزاعات المفتوحة، وكيف تقف إيرادات الشهر أمام مصاريفه بشكل يتطابق مع قائمة الأرباح والخسائر. رسوم التأخير تُطبَّق بالطريقة نفسها في كل مرة، والمخزون يعود إلى حالته الصحيحة عند إلغاء أي عملية بيع. نحو ٢٦٠٠٠ سطر من TypeScript في ١٠٩ ملفات و٢٦ شاشة. والتسليم مشروط: يجب أن يعيد سكربت التحقق المالي صفر ملاحظات قبل تشغيل النظام.
نظامألان للصرافة - نظام إدارة الحوالات
- التحدي:
- تنتقل الأموال بين الفروع بعدّة عملات وبأسعار تتغيّر خلال اليوم الواحد. وحين تُسجَّل في الدفاتر والجداول، فإنّ كل تصحيح يمحو بصمت القيد الذي يصحّحه، وفي نهاية الشهر لا يستطيع أحد إثبات ما على الفرع فعلاً. كان على النظام أن يجعل السجل المالي غير قابل لإعادة الكتابة، وأن يوازن أرصدة المكاتب حتى أصغر وحدة من العملة، وأن يكون قابلاً للاستخدام بالكردية.
- ما بنيناه:
- بُني على Next.js 16 وReact 19 وTypeScript، منظَّماً كوحدة مستقلّة لكل مجال عمل - المكاتب، التحويلات، الأسعار، العمولات، المصاريف، التقارير - لكلٍّ منها طبقات الواجهة والخدمة والاستعلام والتخزين الخاصة بها. تُحفظ كل المبالغ كأعداد صحيحة بأصغر وحدة للعملة وتمرّ عبر طبقة حسابية مرجعية واحدة، فلا يُقرَّب أي رقم مرّتين. الجداول المالية تقبل الإضافة فقط، وهو أمر مفروض في منطق التطبيق وفي مشغّلات SQLite معاً: التصحيح يُسجَّل كقيد عكسي ولا يعدّل القيد الأصلي أبداً. كل تحويل يحتفظ بلقطة سعر الصرف الدقيقة وقت التسجيل، وتُحتسب أرباح وخسائر الصرف المحقّقة بطريقة FIFO. الواجهة بالكامل كردية من اليمين إلى اليسار، خلف بوّابة تفعيل بخوارزمية Argon2id، مع منظومة اختبارات تعيد تشغيل السيناريوهات المالية الأساسية من طرف إلى طرف.
- النتيجة:
- مصفوفة اعتماد من ثلاثة عشر سيناريو - الأرصدة الزائدة، أرباح وخسائر الصرف، دفعات FIFO، التقارير المفلترة، وتطابق الصفحات - اجتازت الاختبار بالأرقام المتوقّعة بدقّة. لوحة المعلومات والصندوق والمصاريف والتقارير وسجل المعاملات تعرض جميعها الأرقام نفسها من المصدر نفسه، ويبقى كل تحويل قابلاً للتدقيق بعد سنوات لأن سعره محفوظ معه.
نظامBookkeeping System
- التحدي:
- كانت حسابات العيادة موزّعة بين الدفاتر وجداول البيانات. المبالغ تأتي من عدة عملاء عبر مشاريع متعددة، والمصروفات تُدوَّن في أي مكان يتّسع لها. وللإجابة عن سؤال بسيط - كم أدرّ هذا المشروع فعلاً، وكم كلّف تشغيله - كان الأمر يستغرق أمسية كاملة من الجمع اليدوي، وتبقى الإجابة رهينة دقة الحساب.
- ما بنيناه:
- نظام مالي خاص محمي بكلمة مرور، مبني على Laravel. تُسجَّل الإيرادات والمصروفات كسجل واحد من الحركات، كل حركة مرتبطة بعميل ومشروع وتصنيف، فيجيب القيد الواحد عن أكثر من سؤال. تفتح لوحة التحكم على الأرقام المهمة: ما دخل، وما خرج، وما تبقّى. وتتيح التقارير تصفية هذا السجل حسب العميل أو المشروع أو التصنيف أو المدة الزمنية.
- النتيجة:
- صارت حسابات العيادة كلها في مكان واحد. كل دفعة وكل تكلفة تُقيَّد ساعة حدوثها، والسؤال الذي كان يستهلك أمسية مع الآلة الحاسبة - كم أدرّ هذا المشروع وكم كلّف تشغيله - صار يُجاب عنه بمرشِّح ونظرة.
نظامTerminal Red
- التحدي:
- بناء شيء يبدو كطرفية وسيط حقيقية دون أن يكون كذلك. كان على الأسعار أن تتحرّك، وعلى الأرباح والخسائر أن تتغيّر لحظيًا، وعلى أوامر جني الأرباح ووقف الخسارة أن تُنفَّذ من تلقاء نفسها - دون أن يتحرّك أي مال حقيقي، بينما لا تسمح الخطة المجانية لبيانات السوق إلا بـ ٨٠٠ طلب يوميًا و٨ طلبات في الدقيقة. كما كان لا بد من عزل الجانب التجريبي عن الحقيقي للمستخدم الواحد عزلًا تامًا: الأرصدة والهامش والصفقات والسجلّ، دون أي اختلاط.
- ما بنيناه:
- واجهة برمجية بـ Laravel 11 مع رموز Sanctum، وتطبيق أحادي الصفحة بـ React 18 و Vite و Tailwind فوقها. تأتي الأسعار من Binance للعملات الرقمية ومن Twelve Data للفوركس والأسهم، مجمّعة في طلب واحد لكل دورة عبر مجدوِل يحدّث العملات الرقمية كل عشر ثوانٍ وما عداها كل دقيقة، ثم تُخزَّن مؤقتًا وتُشارَك عالميًا حتى لا يصطدم المستخدم بحدّ الطلبات أبدًا. وتمرّ مهمة ثانية على الصفقات المفتوحة كل عشر ثوانٍ فتغلق كل صفقة بلغت جني أرباحها أو وقف خسارتها. تُحسب الأموال كلها بـ bcmath كأعداد عشرية نصّية لا كأعداد عائمة، ويجري كل فتح وإغلاق للصفقات وكل موافقة من المشرف داخل معاملة قاعدة بيانات مع قفل للصفوف، فلا يُصرف شيء أو يُغلق مرتين. ويغطي جانب الإدارة المستخدمين والصفقات والحركات المالية والأدوات وأسعار OTC وطرق الدفع والتحقق من الهوية والبطاقات الافتراضية والإعلانات وانتحال هوية المستخدم وإعدادات المنصّة. وتصدر الواجهة بخمس لغات، منها العربية بتخطيط من اليمين إلى اليسار.
- النتيجة:
- طرفية تداول متكاملة تعمل من طرف إلى طرف: التسجيل، والتداول بأسعار حيّة على أموال تجريبية، وطلب إيداع حقيقي مع صورة إثبات، ثم رؤية المشرف يوافق عليه قبل أن يتحرّك أي رصيد. تغطي ثمانية عشر اختبارًا وظيفيًا مسارات المال، ويعمل المشروع كله على استضافة cPanel مشتركة عادية.
موقع إلكترونيعباس صدر الدين - صفحة الروابط
- التحدي:
- كان يصل إلى متابعيه عبر حسابات متفرّقة - تيليغرام وواتساب ويوتيوب وقائمة من روابط المحاضرات والتبرّعات تتغيّر من أسبوع إلى آخر - دون عنوان واحد يحيل الناس إليه. وهو ليس مستخدمًا تقنيًا. أي حلّ يحتاج إلى مطوّر عند كل تعديل كان سيتوقف عن التحديث خلال شهر. كان لا بدّ أن يكون موقعًا يديره بنفسه، إلى ما لا نهاية، وبتكلفة صفر.
- ما بنيناه:
- صفحة React واحدة أمام واجهة خلفية على Firebase، ولوحة تحكّم من ست تبويبات خلف تسجيل دخول بالبريد: الملف الشخصي، الروابط، حسابات التواصل، الأقسام القابلة للطي، الألوان، والتذييل. تُضاف البطاقات وتُخفى ويُغيَّر لونها وتُرتَّب بالسحب من المتصفح مباشرة. تُصغَّر الصور وتُضغط داخل المتصفح وتُحفظ في قاعدة البيانات مباشرة، فلا يحتاج الموقع إلى مساحة تخزين مدفوعة. وتقرأ خطوةُ البناء المحتوى الحيّ وتضعه في وسوم Open Graph، ليصل الرابط إلى المحادثة بالصورة والاسم والنبذة الصحيحة بدل رابط مجرّد. المحتوى مقروء للجميع وقابل للتعديل للمشرف وحده، وكل رابط يُحفظ يُنقّى ويُفحص قبل وصوله إلى الصفحة. ولوحة التحكّم تظهر دائمًا بالألوان الافتراضية - فلا يمكن لتنسيق ألوان غير مقروء أن يحبسه خارج المحرّر الذي يصلحه.
- النتيجة:
- عنوان واحد يجمع كل شيء، وصاحبه يحدّثه بنفسه. روابط جديدة، صور جديدة، ألوان جديدة — تظهر جميعها بعد تحديث الصفحة، دون مطوّر ودون إعادة نشر. يعمل الموقع بالكامل ضمن الباقة المجانية من Firebase، فلا يكلّف شيئًا لإبقائه على الإنترنت، والرابط المشارَك في تيليغرام أو واتساب أو فيسبوك يصل كبطاقة معاينة كاملة.
لنتحدث عن مشروعك.
أخبرنا بما تريد بناءه. سنقدّم لك تقييمًا صادقًا وسعرًا واضحًا وجدولًا زمنيًا واقعيًا — مجانًا.