نرشح لكم أقوى كورسات
وأقوى من يشرح البرمجة وأيضاً APIs بالتفصيل والتطبيق العملي
من خارطة الطريق للمهندس محمد ابو هدهود شرحه مختلف عن عدة كورسات تابعتها شرحهم سطحي وغير مفهوم للامانة شرح نظري وعملي قوي جداً
بالتوفيق للجميع.
م.طارق العُمري
https://programmingadvices.com/courses/2537475/lectures/54047295
https://programmingadvices.com/courses/enrolled/2922828
وأقوى من يشرح البرمجة وأيضاً APIs بالتفصيل والتطبيق العملي
من خارطة الطريق للمهندس محمد ابو هدهود شرحه مختلف عن عدة كورسات تابعتها شرحهم سطحي وغير مفهوم للامانة شرح نظري وعملي قوي جداً
بالتوفيق للجميع.
م.طارق العُمري
https://programmingadvices.com/courses/2537475/lectures/54047295
https://programmingadvices.com/courses/enrolled/2922828
Programmingadvices
About This Course
📣 Connect backend systems to web, mobile, and everything else.
💯2
هل تعلم أدوات الذكاء الاصطناعي وحدها يجعلك مهندس برمجيات؟
أحد المهندسين المدنيين قرر دخول عالم البرمجة عبر أدوات الذكاء الاصطناعي، وأصبح يبني تطبيقات ومواقع جاهزة بالاعتماد على الأوامر والنماذج المسبقة.
وهذا أمر جميل، فالذكاء الاصطناعي أداة رائعة تسرّع العمل وتفتح أبوابًا جديدة للتعلم.
لكن دعنا نناقش بشكل منطقي :
إذا تعلمتُ أنا بعض برامج الهندسة المدنية، وشاهدت عدة مخططات جاهزة، ثم استخدمت أدوات تساعدني على رسم منزل خلال ساعات، فهل أصبح مهندسًا مدنيًا؟
هل أستطيع أن أبني منزلًا دون دراسة التربة؟
دون حساب الأحمال؟
دون تصميم إنشائي؟
دون تحليل للعوامل البيئية والزلازل والرياح؟
دون معرفة ما إذا كان المنزل قابلًا للتوسع مستقبلاً أو إضافة طوابق جديدة؟ 🤔
بالتأكيد لا.
قد أستطيع رسم شكل جميل، وقد أعدل على مخطط جاهز، وأغير الدهانات والإضاءة والديكور، لكن ذلك لا يجعلني مهندسًا مدنيًا.
ونفس الفكرة تنطبق على البرمجة.
إنشاء تطبيق يعمل ليس هو المعيار الوحيد. السؤال الحقيقي:
- هل النظام قابل للتوسع؟
- هل البنية البرمجية صحيحة؟
- هل الأداء جيد عند زيادة المستخدمين؟
- هل البيانات مؤمنة؟
- هل يمكن لفريق كامل تطوير المشروع بعد سنوات؟
- هل تم تحليل المتطلبات وتصميم النظام بشكل صحيح؟
- هل تمت مراعاة الاختبارات والجودة والصيانة؟
الذكاء الاصطناعي يستطيع أن يساعد في كتابة الكود، لكنه لا يمنحك تلقائيًا المعرفة العميقة التي يكتسبها مهندس علوم الحاسوب أو هندسة البرمجيات خلال سنوات من دراسة الخوارزميات وهياكل البيانات وقواعد البيانات والشبكات وأنظمة التشغيل وهندسة البرمجيات وتحليل وتصميم النظم.
الأدوات لا تصنع المهندس، بل المهندس هو من يستخدم الأدوات.
كما أن برامج التصميم الإنشائي لا تجعل أي شخص مهندسًا مدنيًا، فإن أدوات الذكاء الاصطناعي لا تجعل أي شخص مهندس برمجيات بمجرد أنه أنشأ تطبيقًا أو موقعًا مفهوم يا باش
التخصص ليس صعبًا ولا مستحيلًا، ويمكن لأي شخص تعلمه، لكن الطريق الصحيح يبدأ من فهم الأساسيات قبل القفز إلى التنفيذ.
فالبيت الذي يُبنى دون دراسة قد يبدو جميلًا من الخارج، لكنه قد ينهار عند أول اختبار حقيقي.
وكذلك المشروع البرمجي الذي يُبنى دون فهم هندسي عميق قد يعمل اليوم، لكنه ينهار عندما يكبر ويستخدمه الناس بالفعل.
لهذا لا نقلل من قوة وقدرات الذكاء الاصطناعي، بل على العكس، نستخدمه يوميًا. لكن الفرق كبير بين من يستخدم الأداة، ومن يفهم العلم الذي تقوم عليه الأداة.
رفعت الجلسة
#إنتهى
م.طارق العُمري
أحد المهندسين المدنيين قرر دخول عالم البرمجة عبر أدوات الذكاء الاصطناعي، وأصبح يبني تطبيقات ومواقع جاهزة بالاعتماد على الأوامر والنماذج المسبقة.
وهذا أمر جميل، فالذكاء الاصطناعي أداة رائعة تسرّع العمل وتفتح أبوابًا جديدة للتعلم.
لكن دعنا نناقش بشكل منطقي :
إذا تعلمتُ أنا بعض برامج الهندسة المدنية، وشاهدت عدة مخططات جاهزة، ثم استخدمت أدوات تساعدني على رسم منزل خلال ساعات، فهل أصبح مهندسًا مدنيًا؟
هل أستطيع أن أبني منزلًا دون دراسة التربة؟
دون حساب الأحمال؟
دون تصميم إنشائي؟
دون تحليل للعوامل البيئية والزلازل والرياح؟
دون معرفة ما إذا كان المنزل قابلًا للتوسع مستقبلاً أو إضافة طوابق جديدة؟ 🤔
بالتأكيد لا.
قد أستطيع رسم شكل جميل، وقد أعدل على مخطط جاهز، وأغير الدهانات والإضاءة والديكور، لكن ذلك لا يجعلني مهندسًا مدنيًا.
ونفس الفكرة تنطبق على البرمجة.
إنشاء تطبيق يعمل ليس هو المعيار الوحيد. السؤال الحقيقي:
- هل النظام قابل للتوسع؟
- هل البنية البرمجية صحيحة؟
- هل الأداء جيد عند زيادة المستخدمين؟
- هل البيانات مؤمنة؟
- هل يمكن لفريق كامل تطوير المشروع بعد سنوات؟
- هل تم تحليل المتطلبات وتصميم النظام بشكل صحيح؟
- هل تمت مراعاة الاختبارات والجودة والصيانة؟
الذكاء الاصطناعي يستطيع أن يساعد في كتابة الكود، لكنه لا يمنحك تلقائيًا المعرفة العميقة التي يكتسبها مهندس علوم الحاسوب أو هندسة البرمجيات خلال سنوات من دراسة الخوارزميات وهياكل البيانات وقواعد البيانات والشبكات وأنظمة التشغيل وهندسة البرمجيات وتحليل وتصميم النظم.
الأدوات لا تصنع المهندس، بل المهندس هو من يستخدم الأدوات.
كما أن برامج التصميم الإنشائي لا تجعل أي شخص مهندسًا مدنيًا، فإن أدوات الذكاء الاصطناعي لا تجعل أي شخص مهندس برمجيات بمجرد أنه أنشأ تطبيقًا أو موقعًا مفهوم يا باش
التخصص ليس صعبًا ولا مستحيلًا، ويمكن لأي شخص تعلمه، لكن الطريق الصحيح يبدأ من فهم الأساسيات قبل القفز إلى التنفيذ.
فالبيت الذي يُبنى دون دراسة قد يبدو جميلًا من الخارج، لكنه قد ينهار عند أول اختبار حقيقي.
وكذلك المشروع البرمجي الذي يُبنى دون فهم هندسي عميق قد يعمل اليوم، لكنه ينهار عندما يكبر ويستخدمه الناس بالفعل.
لهذا لا نقلل من قوة وقدرات الذكاء الاصطناعي، بل على العكس، نستخدمه يوميًا. لكن الفرق كبير بين من يستخدم الأداة، ومن يفهم العلم الذي تقوم عليه الأداة.
رفعت الجلسة
#إنتهى
م.طارق العُمري
إِذا لَم يَكُن عَونٌ مِنَ اللَهِ للِفَتى
فَأَكثَرُ ما يَجني عَلَيهِ اِجتِهادُهُ
صباح الخير 🤍.
فَأَكثَرُ ما يَجني عَلَيهِ اِجتِهادُهُ
صباح الخير 🤍.
❤2
مصطلح DTO هو اختصار لـ Data Transfer Object (كائن نقل البيانات). في هندسة البرمجيات، هو عبارة عن كائن أو فئة (Class) تُستخدم لتغليف البيانات ونقلها بين أجزاء النظام المختلفة، وخاصة بين واجهة برمجة التطبيقات (API) وقاعدة البيانات، أو بين الخادم (Server) والعميل (Client).
السمة الأساسية للـ DTO هي أنه لا يحتوي على أي منطق برمجي (Business Logic) أو عمليات معقدة؛ فهو يقتصر فقط على الخصائص (Properties) لتمثيل البيانات المطلوبة.
لماذا نعتمد على الـ DTO في بناء الأنظمة؟
الأمان وإخفاء البيانات: غالباً ما تحتوي نماذج قاعدة البيانات (Entities/Models) على بيانات حساسة لا يجب أن تظهر للعميل. على سبيل المثال، نموذج المستخدم قد يحتوي على كلمة المرور المشفرة (Password Hash). باستخدام الـ DTO، أنت تنشئ كائناً جديداً يحتوي فقط على البيانات الآمنة (مثل الاسم والبريد الإلكتروني) لإرسالها.
تحسين الأداء وتقليل حجم البيانات (Payload): عند استدعاء بيانات من الخادم، قد لا تحتاج الواجهة الأمامية إلى كل التفاصيل الموجودة في قاعدة البيانات. الـ DTO يسمح لك بإرسال الحقول المطلوبة فقط، مما يقلل من استهلاك عرض النطاق الترددي (Bandwidth) ويسرع استجابة النظام.
الفصل الاستراتيجي بين الطبقات (Decoupling): الـ DTO يعمل كعقد (Contract) ثابت بين الـ Backend والـ Frontend. إذا اضطررت لاحقاً لتغيير هيكل قاعدة البيانات، فلن يتأثر العميل أو التطبيق الأمامي، لأنك ستقوم فقط بتعديل طريقة تحويل البيانات (Mapping) لتبقى مخرجات الـ DTO كما هي.
توضيح برمجي بسيط
إذا كان لديك نموذج مستخدم في قاعدة البيانات بهذا الشكل:
لإرسال بيانات المستخدم إلى الواجهة الأمامية دون تعريض الأمان للخطر، تقوم بإنشاء DTO مخصص:
ابحث عنه واين تستخدمه وفي اي معمارية من معماريات البرمجة في الباك ؟
طيب التقنية مش مهم سي شارب او غيرها المفهوم واحد بكل اللغات والاطر
السمة الأساسية للـ DTO هي أنه لا يحتوي على أي منطق برمجي (Business Logic) أو عمليات معقدة؛ فهو يقتصر فقط على الخصائص (Properties) لتمثيل البيانات المطلوبة.
لماذا نعتمد على الـ DTO في بناء الأنظمة؟
الأمان وإخفاء البيانات: غالباً ما تحتوي نماذج قاعدة البيانات (Entities/Models) على بيانات حساسة لا يجب أن تظهر للعميل. على سبيل المثال، نموذج المستخدم قد يحتوي على كلمة المرور المشفرة (Password Hash). باستخدام الـ DTO، أنت تنشئ كائناً جديداً يحتوي فقط على البيانات الآمنة (مثل الاسم والبريد الإلكتروني) لإرسالها.
تحسين الأداء وتقليل حجم البيانات (Payload): عند استدعاء بيانات من الخادم، قد لا تحتاج الواجهة الأمامية إلى كل التفاصيل الموجودة في قاعدة البيانات. الـ DTO يسمح لك بإرسال الحقول المطلوبة فقط، مما يقلل من استهلاك عرض النطاق الترددي (Bandwidth) ويسرع استجابة النظام.
الفصل الاستراتيجي بين الطبقات (Decoupling): الـ DTO يعمل كعقد (Contract) ثابت بين الـ Backend والـ Frontend. إذا اضطررت لاحقاً لتغيير هيكل قاعدة البيانات، فلن يتأثر العميل أو التطبيق الأمامي، لأنك ستقوم فقط بتعديل طريقة تحويل البيانات (Mapping) لتبقى مخرجات الـ DTO كما هي.
توضيح برمجي بسيط
إذا كان لديك نموذج مستخدم في قاعدة البيانات بهذا الشكل:
C#public class User {
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public string PasswordHash { get; set; }
public DateTime CreatedAt { get; set; }
}لإرسال بيانات المستخدم إلى الواجهة الأمامية دون تعريض الأمان للخطر، تقوم بإنشاء DTO مخصص:
C#public class UserResponseDTO {
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
}ابحث عنه واين تستخدمه وفي اي معمارية من معماريات البرمجة في الباك ؟
طيب التقنية مش مهم سي شارب او غيرها المفهوم واحد بكل اللغات والاطر
اليوم 06/06/2026 😅
تاريخ مميز وجميل، فقلنا نذكركم
ونوصيكم بالدعاء🤍
دمتم بخير.
✍️المهندس
تاريخ مميز وجميل، فقلنا نذكركم
ونوصيكم بالدعاء🤍
دمتم بخير.
✍️المهندس
ماذا لو انقطع الإنترنت وبقي حاسوبك يعمل؟ ⚡
مشروع نوماد هو خادم بقاء يعمل دون اتصال بالإنترنت، ويعمل على حاسوب صغير دون الحاجة إلى خدمات سحابية أو اشتراكات أو اتصال بالإنترنت.
يتضمن المشروع ميزات مثل الذكاء الاصطناعي، ويكيبيديا، الخرائط، المراجع الطبية، أدلة البقاء، دورات أكاديمية خان، وخاصية البحث الذكي عن المستندات.
في عالم يعتمد بشكل كبير على الحوسبة السحابية، يُذكّرنا هذا المشروع بأهمية التقنيات المحلية.
الرابط : https://github.com/Crosstalk-Solutions/project-nomad
_
#GhaniWeb #تقنية #technews #الجميع
مشروع نوماد هو خادم بقاء يعمل دون اتصال بالإنترنت، ويعمل على حاسوب صغير دون الحاجة إلى خدمات سحابية أو اشتراكات أو اتصال بالإنترنت.
يتضمن المشروع ميزات مثل الذكاء الاصطناعي، ويكيبيديا، الخرائط، المراجع الطبية، أدلة البقاء، دورات أكاديمية خان، وخاصية البحث الذكي عن المستندات.
في عالم يعتمد بشكل كبير على الحوسبة السحابية، يُذكّرنا هذا المشروع بأهمية التقنيات المحلية.
الرابط : https://github.com/Crosstalk-Solutions/project-nomad
_
#GhaniWeb #تقنية #technews #الجميع
GitHub
GitHub - Crosstalk-Solutions/project-nomad: Project NOMAD is an offline-first knowledge and education server. Wikipedia, thousands…
Project NOMAD is an offline-first knowledge and education server. Wikipedia, thousands of books, courses, maps, and optional local AI, all running on hardware you own with no internet required. - C...
جوجل تبتكر طريقة ثورية لضغط ذاكرة نماذج الذكاء الاصطناعي من 31 جيجابايت إلى 4 جيجابايت فقط! 🧠⚡
نجح باحثو جوجل في تطوير تقنية ضغط برمجية متطورة للغاية تتيح اختزال حجم الذاكرة العشوائية المطلوبة لتشغيل نماذج الذكاء الاصطناعي الضخمة محلياً بنسبة تتجاوز 85%، دون التضحية بدقة وكفاءة النموذج.
أبرز ما يحققه هذا الإنجاز التقني:
* تشغيل نماذج لغوية ضخمة ومتقدمة بالكامل على الهواتف الذكية والأجهزة ذات المواصفات المتوسطة محلياً ودون إنترنت.
* تقليل استهلاك الطاقة والبطارية بشكل ملحوظ أثناء معالجة البيانات وتوليد النصوص على الأجهزة المحمولة.
* فتح الباب لدمج وكلاء ذكاء اصطناعي (AI Agents) أكثر ذكاءً واستقلالية داخل التطبيقات اليومية وأنظمة التشغيل الخفيفة.
خطوة تقنية عملاقة تنقل الذكاء الاصطناعي التوليدي من الحوسبة السحابية والمخدمات الضخمة المكلفة إلى بيئة التشغيل المحلية ب كفاءة عالية.
نجح باحثو جوجل في تطوير تقنية ضغط برمجية متطورة للغاية تتيح اختزال حجم الذاكرة العشوائية المطلوبة لتشغيل نماذج الذكاء الاصطناعي الضخمة محلياً بنسبة تتجاوز 85%، دون التضحية بدقة وكفاءة النموذج.
أبرز ما يحققه هذا الإنجاز التقني:
* تشغيل نماذج لغوية ضخمة ومتقدمة بالكامل على الهواتف الذكية والأجهزة ذات المواصفات المتوسطة محلياً ودون إنترنت.
* تقليل استهلاك الطاقة والبطارية بشكل ملحوظ أثناء معالجة البيانات وتوليد النصوص على الأجهزة المحمولة.
* فتح الباب لدمج وكلاء ذكاء اصطناعي (AI Agents) أكثر ذكاءً واستقلالية داخل التطبيقات اليومية وأنظمة التشغيل الخفيفة.
خطوة تقنية عملاقة تنقل الذكاء الاصطناعي التوليدي من الحوسبة السحابية والمخدمات الضخمة المكلفة إلى بيئة التشغيل المحلية ب كفاءة عالية.
لحظة محاسبة مع النفس
أغلق الإنترنت، ثم قم فتوضأ وصلي ركعتين، وعد بعدها لتجلس مع نفسك قليلًا بعيدًا عن ضجيج الحياة ومشاغلها
راجع نفسك قليلاً؟
ليش انا مقصر مع الصلاة مع ذكر الله مع القران ؟
ليش أبتعدت كثير عن الله؟ هل هنت على الله لهذه الدرجة؟
ليش انا ما أشعر إني مذنب ؟ ليش ما ارجع الى الله ؟
ليش أشاهد ما يغضب الله ؟ ليش اغتاب الناس ؟
ليش أكذب ؟ ليش أطعن في عرض الاخرين ؟
.....الخ أسال أسال حتى تحصل على إجابات مقنعة من قلبك
في تلك اللحظات الهادئة ستشعر بشيء من التقصير تجاه ربك، وتبدأ تراجع نفسك وتحاسبها على ما مضى. تدرك أن الإنسان مهما أذنب ومهما أنشغل بأمور الدنيا يبقى محتاجًا إلى لحظات صادقة يقف فيها مع نفسه، يراجع أعماله، ويصحح مساره، ويجدد علاقته بربه.
ما أجمل أن يمتلك الإنسان ضميرًا حيًا يوقظه إذا أخطأ، ويعاتبه إذا قصّر، ويقوده إلى التوبة والعودة. فمحاسبة النفس ليست ضعفًا، بل دليل على حياة القلب، وعلامة على أن الخير ما زال حاضرًا في الداخل مهما ارتكبت من ذنوب ومعاصي.
إن أعظم خسارة ليس أن يخطئ الإنسان، بل أن يعتاد الخطأ دون أن يشعر، أو يقصّر دون أن يؤنبه ضميره.
أما ذلك الشعور الذي يدفعنا للمراجعة والتوبة فهو نعمة تستحق شكر الله ليل ونهار لأنه ما زال فيك الخير يا عبدالله
اللهم أصلح قلوبنا، وأعنّا على ذكرك وشكرك وحسن عبادتك.
✍️المهندس
أغلق الإنترنت، ثم قم فتوضأ وصلي ركعتين، وعد بعدها لتجلس مع نفسك قليلًا بعيدًا عن ضجيج الحياة ومشاغلها
راجع نفسك قليلاً؟
ليش انا مقصر مع الصلاة مع ذكر الله مع القران ؟
ليش أبتعدت كثير عن الله؟ هل هنت على الله لهذه الدرجة؟
ليش انا ما أشعر إني مذنب ؟ ليش ما ارجع الى الله ؟
ليش أشاهد ما يغضب الله ؟ ليش اغتاب الناس ؟
ليش أكذب ؟ ليش أطعن في عرض الاخرين ؟
.....الخ أسال أسال حتى تحصل على إجابات مقنعة من قلبك
في تلك اللحظات الهادئة ستشعر بشيء من التقصير تجاه ربك، وتبدأ تراجع نفسك وتحاسبها على ما مضى. تدرك أن الإنسان مهما أذنب ومهما أنشغل بأمور الدنيا يبقى محتاجًا إلى لحظات صادقة يقف فيها مع نفسه، يراجع أعماله، ويصحح مساره، ويجدد علاقته بربه.
ما أجمل أن يمتلك الإنسان ضميرًا حيًا يوقظه إذا أخطأ، ويعاتبه إذا قصّر، ويقوده إلى التوبة والعودة. فمحاسبة النفس ليست ضعفًا، بل دليل على حياة القلب، وعلامة على أن الخير ما زال حاضرًا في الداخل مهما ارتكبت من ذنوب ومعاصي.
إن أعظم خسارة ليس أن يخطئ الإنسان، بل أن يعتاد الخطأ دون أن يشعر، أو يقصّر دون أن يؤنبه ضميره.
أما ذلك الشعور الذي يدفعنا للمراجعة والتوبة فهو نعمة تستحق شكر الله ليل ونهار لأنه ما زال فيك الخير يا عبدالله
اللهم أصلح قلوبنا، وأعنّا على ذكرك وشكرك وحسن عبادتك.
✍️المهندس
❤3
مستودع متكامل لأفضل مهارات واجهات المستخدم لمطوري الذكاء الاصطناعي! 🚀🎨
موقع ui-skills.com يقدم قائمة منسقة بعناية لأفضل المهارات (Skills) التي يمكنك تزويد وكلاء الذكاء الاصطناعي بها لإنتاج واجهات مستخدم أكثر احترافية وجاذبية، بدلاً من التصاميم التقليدية المكررة.
إذا كنت تبني فرونت إند بالاعتماد على الـ AI، فهذا الموقع يمثل كنزاً حقيقياً لك.
أبرز ما تركز عليه مهارات الواجهات المتاحة:
* حركات وأنيميشن تفاعلية تمنح المستخدم شعوراً بالمرونة والسرعة أثناء التنقل.
* معايير الوصول الشامل (Accessibility) لضمان توافق الواجهات مع كافة المستخدمين.
* كتابة كود Tailwind مخصص ونظيف، يضمن الحفاظ على الهوية البصرية والاتساق الكامل بين الصفحات.
* تفاعلات دقيقة مجهرية (Pro-level Micro-interactions) ترفع من جودة تجربة المستخدم النهائية بشكل ملحوظ.
دليل ممتاز لتلقين النماذج والوكلاء القواعد الصحيحة لإنتاج واجهات عصرية ومتكاملة بلمحة عين.
https://github.com/pbakaus/impeccable
موقع ui-skills.com يقدم قائمة منسقة بعناية لأفضل المهارات (Skills) التي يمكنك تزويد وكلاء الذكاء الاصطناعي بها لإنتاج واجهات مستخدم أكثر احترافية وجاذبية، بدلاً من التصاميم التقليدية المكررة.
إذا كنت تبني فرونت إند بالاعتماد على الـ AI، فهذا الموقع يمثل كنزاً حقيقياً لك.
أبرز ما تركز عليه مهارات الواجهات المتاحة:
* حركات وأنيميشن تفاعلية تمنح المستخدم شعوراً بالمرونة والسرعة أثناء التنقل.
* معايير الوصول الشامل (Accessibility) لضمان توافق الواجهات مع كافة المستخدمين.
* كتابة كود Tailwind مخصص ونظيف، يضمن الحفاظ على الهوية البصرية والاتساق الكامل بين الصفحات.
* تفاعلات دقيقة مجهرية (Pro-level Micro-interactions) ترفع من جودة تجربة المستخدم النهائية بشكل ملحوظ.
دليل ممتاز لتلقين النماذج والوكلاء القواعد الصحيحة لإنتاج واجهات عصرية ومتكاملة بلمحة عين.
https://github.com/pbakaus/impeccable
GitHub
GitHub - pbakaus/impeccable: The design language that makes your AI harness better at design.
The design language that makes your AI harness better at design. - pbakaus/impeccable
صورة تذكارية مع رفاق الدرب، والكورس شغال على صوت المهندس محمد أبو هدهود 😅
Mohammed Abu Hadhoud
قررنا ان نحتفظ بها للذكرى من قبل عامين، عشان نتذكر هذه الأيام بعد سنوات...
جيش أبو هدهود قادم من اليمن 🇾🇪🔥
ساعات طويلة من التعلم، وتمارين، وأخطاء، ومحاولات لا تنتهي، لكن بإذن الله القادم أجمل.
من هنا بدأت الرحلة... 🚀
#خارطة_الطريق #برمجة #فريق_عمل #DemoSoft
Mohammed Abu Hadhoud
قررنا ان نحتفظ بها للذكرى من قبل عامين، عشان نتذكر هذه الأيام بعد سنوات...
جيش أبو هدهود قادم من اليمن 🇾🇪🔥
ساعات طويلة من التعلم، وتمارين، وأخطاء، ومحاولات لا تنتهي، لكن بإذن الله القادم أجمل.
من هنا بدأت الرحلة... 🚀
#خارطة_الطريق #برمجة #فريق_عمل #DemoSoft
❤3
مقال المصري :
في بداية طريقك في ال Software Engineering، أخطر حاجة ممكن تعطلك مش إنك تكون ضعيف تقنيا، ولا إنك تغلط في ال Code، ولا إنك تتأخر في حل Bug، لأن كل ده طبيعي جدا وبيحصل مع أي حد بيتعلم.
الخطر الحقيقي إنك تتخدع في مستواك بدري، تخلص كورس، أو تعمل Project بمساعدة AI Tool، أو تستخدم Framework جاهز، وبعدها تحس إنك بقيت فاهم المجال وجاهز تتكلم بثقة عن ال Architecture وال Scalability وال Microservices.
الموضوع ده معروف باسم Dunning-Kruger Effect، ومعناه ببساطة إن الشخص في بداية التعلم أحيانا بيبقى واثق في نفسه زيادة عن اللزوم، لأنه شاف القشرة من بره ولسه مدخلش في العمق.
المشكلة إن ال Frameworks وال Tools الحديثة بتخبي عنك تعقيد كبير، وبتديك Output شكله حلو بسرعة، لكن فيه فرق بين إنك تشغل System على جهازك، وبين إنك تبني System يعيش في Production قدام Users حقيقيين و Load و Bugs و Failures.
الأسبوع اللي فات في ال Mentorship Program كان معايا متدرب مجتهد جدا، عامل Project لشركة شحن وتوصيل صغيرة، والمشروع من بره كان شكله قوي، معمول ب Microservices Architecture، وفيه Kafka ك Message Broker، ومتقسم على Docker Containers.
هو كان داخل السيشن واثق جدا، لأنه قدر يربط Tools كبيرة ببعض وال System اشتغل عنده، وبدأ يتكلم عن ال Distributed Systems وال Scalability وإن السيستم يقدر يشيل ملايين العمليات.
لكن لما راجعنا التصميم بجد، سألته لو Service وقعت في نص ال Flow إزاي هتضمن إن ال Data ما تضيعش؟ ولو 50 User عملوا Update لحالة الشحنات في نفس اللحظة، إيه اللي هيحصل؟
لما عملنا Load Testing بسيط، الدنيا بدأت تقع، في Requests وقفت، وفي Updates اتأخرت، وفي مشاكل ظهرت في ال Database، وال System اللي كان شكله قوي من بره وضح إن تصميمه من جوه محتاج فهم أعمق.
المشكلة ماكنتش إن المتدرب ضعيف، بالعكس هو شاطر ومجتهد، لكنه كان واقع في فخ مهم، وهو إنه اعتبر استخدام أدوات كبيرة دليل على الفهم، مع إن ال Tool مش هي اللي بتخليك Engineer.
ال Software Engineer الحقيقي مش اللي يعرف أسماء Technologies كتير، لكنه الشخص اللي يقدر يجاوب: ليه استخدمت Kafka؟ ليه قسمت ال System ل Microservices؟ هل المشروع فعلا محتاج ده؟ إيه ال Trade-offs؟ وإزاي هتصلح المشكلة لما تحصل؟
وهنا بيبدأ النضج الحقيقي، لما الشخص يقول لنفسه: أنا كنت فاكر إني فاهم، بس واضح إن في حاجات كتير لسه محتاج أفهمها، ودي مش لحظة فشل، دي لحظة وعي وبداية احتراف.
التواضع المعرفي أو Intellectual Humility معناه إنك تسأل Why قبل How، وماتجريش ورا ال Trends لمجرد إنها منتشرة، وماتحشرش Technologies معقدة في مشروع بسيط لمجرد إن أسماءها كبيرة.
الأدوات بتتغير، لكن الأساسيات بتفضل، ال Data Structures مهمة، ال Database Design مهم، ال Transactions مهمة، ال Concurrency مهم، ال Testing مهم، وال Problem Solving أهم من أي Tool.
استخدم ال AI عادي، واتعلم من ال Tutorials عادي، وابني Projects عادي، بس ما تخليش ال Output يخدعك، واسأل نفسك دايما: أنا فاهم اللي عملته؟ فاهم عيوبه؟ فاهم بدائله؟ فاهم هيقع إمتى؟ وفاهم هصلحه إزاي؟
في برنامج المينتورينج اللي بقدّمه، الهدف مش إنك تجمع معلومات أكتر وخلاص، الهدف إنك تتعلم تفكر ك Software Engineer، تشوف مشاكل حقيقية، تفهم ال Trade-offs، وتبني ثقة مبنية على فهم وتجربة.
لأن الطريق الحقيقي مش إنك تبان شاطر بسرعة، الطريق الحقيقي إنك تبقى فاهم بجد، وتوصل لمرحلة تبقى فيها أنت الشخص اللي فاهم، مش اللي بينفّذ وخلاص.
Have A Nice Day 😊✌
في بداية طريقك في ال Software Engineering، أخطر حاجة ممكن تعطلك مش إنك تكون ضعيف تقنيا، ولا إنك تغلط في ال Code، ولا إنك تتأخر في حل Bug، لأن كل ده طبيعي جدا وبيحصل مع أي حد بيتعلم.
الخطر الحقيقي إنك تتخدع في مستواك بدري، تخلص كورس، أو تعمل Project بمساعدة AI Tool، أو تستخدم Framework جاهز، وبعدها تحس إنك بقيت فاهم المجال وجاهز تتكلم بثقة عن ال Architecture وال Scalability وال Microservices.
الموضوع ده معروف باسم Dunning-Kruger Effect، ومعناه ببساطة إن الشخص في بداية التعلم أحيانا بيبقى واثق في نفسه زيادة عن اللزوم، لأنه شاف القشرة من بره ولسه مدخلش في العمق.
المشكلة إن ال Frameworks وال Tools الحديثة بتخبي عنك تعقيد كبير، وبتديك Output شكله حلو بسرعة، لكن فيه فرق بين إنك تشغل System على جهازك، وبين إنك تبني System يعيش في Production قدام Users حقيقيين و Load و Bugs و Failures.
الأسبوع اللي فات في ال Mentorship Program كان معايا متدرب مجتهد جدا، عامل Project لشركة شحن وتوصيل صغيرة، والمشروع من بره كان شكله قوي، معمول ب Microservices Architecture، وفيه Kafka ك Message Broker، ومتقسم على Docker Containers.
هو كان داخل السيشن واثق جدا، لأنه قدر يربط Tools كبيرة ببعض وال System اشتغل عنده، وبدأ يتكلم عن ال Distributed Systems وال Scalability وإن السيستم يقدر يشيل ملايين العمليات.
لكن لما راجعنا التصميم بجد، سألته لو Service وقعت في نص ال Flow إزاي هتضمن إن ال Data ما تضيعش؟ ولو 50 User عملوا Update لحالة الشحنات في نفس اللحظة، إيه اللي هيحصل؟
لما عملنا Load Testing بسيط، الدنيا بدأت تقع، في Requests وقفت، وفي Updates اتأخرت، وفي مشاكل ظهرت في ال Database، وال System اللي كان شكله قوي من بره وضح إن تصميمه من جوه محتاج فهم أعمق.
المشكلة ماكنتش إن المتدرب ضعيف، بالعكس هو شاطر ومجتهد، لكنه كان واقع في فخ مهم، وهو إنه اعتبر استخدام أدوات كبيرة دليل على الفهم، مع إن ال Tool مش هي اللي بتخليك Engineer.
ال Software Engineer الحقيقي مش اللي يعرف أسماء Technologies كتير، لكنه الشخص اللي يقدر يجاوب: ليه استخدمت Kafka؟ ليه قسمت ال System ل Microservices؟ هل المشروع فعلا محتاج ده؟ إيه ال Trade-offs؟ وإزاي هتصلح المشكلة لما تحصل؟
وهنا بيبدأ النضج الحقيقي، لما الشخص يقول لنفسه: أنا كنت فاكر إني فاهم، بس واضح إن في حاجات كتير لسه محتاج أفهمها، ودي مش لحظة فشل، دي لحظة وعي وبداية احتراف.
التواضع المعرفي أو Intellectual Humility معناه إنك تسأل Why قبل How، وماتجريش ورا ال Trends لمجرد إنها منتشرة، وماتحشرش Technologies معقدة في مشروع بسيط لمجرد إن أسماءها كبيرة.
الأدوات بتتغير، لكن الأساسيات بتفضل، ال Data Structures مهمة، ال Database Design مهم، ال Transactions مهمة، ال Concurrency مهم، ال Testing مهم، وال Problem Solving أهم من أي Tool.
استخدم ال AI عادي، واتعلم من ال Tutorials عادي، وابني Projects عادي، بس ما تخليش ال Output يخدعك، واسأل نفسك دايما: أنا فاهم اللي عملته؟ فاهم عيوبه؟ فاهم بدائله؟ فاهم هيقع إمتى؟ وفاهم هصلحه إزاي؟
في برنامج المينتورينج اللي بقدّمه، الهدف مش إنك تجمع معلومات أكتر وخلاص، الهدف إنك تتعلم تفكر ك Software Engineer، تشوف مشاكل حقيقية، تفهم ال Trade-offs، وتبني ثقة مبنية على فهم وتجربة.
لأن الطريق الحقيقي مش إنك تبان شاطر بسرعة، الطريق الحقيقي إنك تبقى فاهم بجد، وتوصل لمرحلة تبقى فيها أنت الشخص اللي فاهم، مش اللي بينفّذ وخلاص.
Have A Nice Day 😊✌
ثورة في عالم اختبار تطبيقات الويب: دليلك الشامل لمكتبة Playwright
في عالم تطوير البرمجيات السريع اليوم، أصبح ضمان جودة تطبيقات الويب (Web Applications) وموثوقيتها أمراً بالغ الأهمية. هنا تبرز مكتبة Playwright كواحدة من أقوى الأدوات الحديثة التي أحدثت نقلة نوعية في مجال اختبار البرمجيات (Software Testing)، وتحديداً في الاختبارات الشاملة (End-to-End Testing).
ما هي مكتبة Playwright؟
Playwright هي إطار عمل (Framework) مفتوح المصدر طورته شركة مايكروسوفت (Microsoft) لأتمتة متصفحات الويب (Web Automation) واختبارها. صُممت هذه المكتبة لتكون قادرة على تنفيذ عمليات الاختبار بسرعة، وموثوقية، وقابلية للتوسع، مما يجعلها أداة مفضلة لدى مطوري الويب ومهندسي ضمان الجودة (QA Engineers).
المميزات الجوهرية لمكتبة Playwright
تتميز Playwright بمجموعة من الخصائص التي تجعلها تتفوق في بيئة التطوير الحديثة:
دعم متصفحات متعددة (Cross-Browser Support): تتيح لك المكتبة اختبار تطبيقك على محركات المتصفحات الرئيسية الثلاثة: Chromium (مثل Chrome و Edge)، و WebKit (مثل Safari)، و Firefox، كل ذلك باستخدام واجهة برمجة تطبيقات (API) واحدة.
دعم لغات برمجة متعددة: لست مضطراً لتعلم لغة جديدة لاستخدامها؛ فهي تدعم لغات مثل JavaScript/TypeScript، و Python، و Java، و C# (.NET).
الانتظار التلقائي (Auto-Wait): واحدة من أكبر مشاكل أدوات الاختبار القديمة هي فشل الاختبارات بسبب بطء تحميل الصفحة (Flaky tests). تقوم Playwright بالانتظار تلقائياً حتى تصبح العناصر جاهزة (مرئية وقابلة للتفاعل) قبل تنفيذ أي إجراء (مثل النقر أو الكتابة).
التحكم في الشبكة (Network Interception): تتيح لك اعتراض طلبات الشبكة (Network Requests) وتعديلها أو محاكاتها (Mocking)، مما يسهل اختبار حالات معينة مثل انقطاع الاتصال بالإنترنت أو أخطاء الخوادم (Server Errors).
بيئات معزولة وسريعة (Browser Contexts): بدلاً من فتح متصفح جديد لكل اختبار (مما يستهلك وقتاً وموارد)، تعتمد Playwright على "سياقات المتصفح" وهي بيئات معزولة تماماً تشبه نافذة التصفح المتخفي (Incognito)، مما يجعل تنفيذ الاختبارات المتوازية (Parallel Testing) سريعاً جداً.
التقاط الصور وتسجيل الفيديو: يمكن للمكتبة أخذ لقطات شاشة (Screenshots) أو حتى تسجيل فيديو لخطوات الاختبار، مما يسهل جداً تتبع الأخطاء واكتشاف سبب فشل أي اختبار.
في عالم تطوير البرمجيات السريع اليوم، أصبح ضمان جودة تطبيقات الويب (Web Applications) وموثوقيتها أمراً بالغ الأهمية. هنا تبرز مكتبة Playwright كواحدة من أقوى الأدوات الحديثة التي أحدثت نقلة نوعية في مجال اختبار البرمجيات (Software Testing)، وتحديداً في الاختبارات الشاملة (End-to-End Testing).
ما هي مكتبة Playwright؟
Playwright هي إطار عمل (Framework) مفتوح المصدر طورته شركة مايكروسوفت (Microsoft) لأتمتة متصفحات الويب (Web Automation) واختبارها. صُممت هذه المكتبة لتكون قادرة على تنفيذ عمليات الاختبار بسرعة، وموثوقية، وقابلية للتوسع، مما يجعلها أداة مفضلة لدى مطوري الويب ومهندسي ضمان الجودة (QA Engineers).
المميزات الجوهرية لمكتبة Playwright
تتميز Playwright بمجموعة من الخصائص التي تجعلها تتفوق في بيئة التطوير الحديثة:
دعم متصفحات متعددة (Cross-Browser Support): تتيح لك المكتبة اختبار تطبيقك على محركات المتصفحات الرئيسية الثلاثة: Chromium (مثل Chrome و Edge)، و WebKit (مثل Safari)، و Firefox، كل ذلك باستخدام واجهة برمجة تطبيقات (API) واحدة.
دعم لغات برمجة متعددة: لست مضطراً لتعلم لغة جديدة لاستخدامها؛ فهي تدعم لغات مثل JavaScript/TypeScript، و Python، و Java، و C# (.NET).
الانتظار التلقائي (Auto-Wait): واحدة من أكبر مشاكل أدوات الاختبار القديمة هي فشل الاختبارات بسبب بطء تحميل الصفحة (Flaky tests). تقوم Playwright بالانتظار تلقائياً حتى تصبح العناصر جاهزة (مرئية وقابلة للتفاعل) قبل تنفيذ أي إجراء (مثل النقر أو الكتابة).
التحكم في الشبكة (Network Interception): تتيح لك اعتراض طلبات الشبكة (Network Requests) وتعديلها أو محاكاتها (Mocking)، مما يسهل اختبار حالات معينة مثل انقطاع الاتصال بالإنترنت أو أخطاء الخوادم (Server Errors).
بيئات معزولة وسريعة (Browser Contexts): بدلاً من فتح متصفح جديد لكل اختبار (مما يستهلك وقتاً وموارد)، تعتمد Playwright على "سياقات المتصفح" وهي بيئات معزولة تماماً تشبه نافذة التصفح المتخفي (Incognito)، مما يجعل تنفيذ الاختبارات المتوازية (Parallel Testing) سريعاً جداً.
التقاط الصور وتسجيل الفيديو: يمكن للمكتبة أخذ لقطات شاشة (Screenshots) أو حتى تسجيل فيديو لخطوات الاختبار، مما يسهل جداً تتبع الأخطاء واكتشاف سبب فشل أي اختبار.