عطل مفاجئ في عمل "فيسبوك" وواتس آب" و"إنستغرام"




أعلنت خدمة Downdetector عن عطل مفاجئ أصاب عمل شبكات "فيسبوك" و "واتس آب" و"إنستغرام" في بعض البلدان.
وتبعا للمعلومات المتوفرة فإن المشكلات في عمل شبكة "فيسبوك" والمسنجر التابع لها واجهت بشكل أساسي المستخدمين في موسكو وسان بطرسبورغ، كما أن مشكلات "إنستغرام" و "واتس آب" ظهرت في العديد من البلدان الأوروبية مثل فنلندا وبولونيا والتشيك وعدد من البلدان الأخرى.

ويشتكي 47% من مستخدمي "إنستغرام" تبعا للبيانات المتوفرة من مشكلات في تنزيل البيانات عبر الشبكة، بينما يعاني نحو 35% منهم من مشكلات في تحميل البيانات، بينما لا يتمكن نحو 17% من استخدام الشبكة إطلاقا.

أما بالنسبة لـ "واتس آب" فنحو 86% من المستخدمين في اشتكوا من مشكلات في الاتصال مع خدمة التطبيق، بينما عانى نحو 12% من مشكلات إلى الدخول إلى الموقع الرسمي له عبر الإنترنت، بينما واجه نحو 2% من المستخدمين من مشكلات في تسجيل الدخول إلى تطبيق المراسلة.

وفيما يخص "فيسبوك" تشير البيانات إلى أن نحو 83% من المستخدمين في عدة مناطق عانوا من مشكلات في الموقع ومشكلات مع الدخول إلى الخدمة.

المصدر: نوفوستي

استنونا يوم الخميس ، 14 اكتوبر 🤩

الي مهتم يعرف مقدمة عن ال Machine Learning ، بيكون معكم المتحدث البش مهندس : أحمد الشافعي

= طيب ممكن تعطونا شوية نبذة عن المتحدث وايش هي المواضيع الي بيتكلم عليها تحديداً؟ 🤔

🔹 بش مهندس أحمد :
- هو GDSC Lead في جامعة حورس في مصر.
-طالب هندسة ميكاترونكس ومهتم بمجال علم الآلة والروبوت. 🤖

🔹 المواضيع الي بيتكلم عليها :
- What is Machine Learning.
- Components of Machine Learning.
- Introduction to ML.
- Define the problem.
- Build a Data Set.
- Model training and evaluation.
- Examples
- Simple Quiz.

مهتمين تكونوا معنا؟ 🤩

🗓️ يوم الخميس ، بتاريخ 14 اكتوبر.
🕓 في الساعة (8 مساءً بتوقيت مصر ، 9 مساءً بتوقيت اليمن ).

وانتظرونا احنا كلنا ال GDSC MENA في بارتنرشب فريد من نوعه فيه مكس لأكثر من دولة 😎.
Stay Tuned ... 👀

+ ما تنسوش كمان تتابعونا بكرة الاربعاء الساعة ٤ مساءً ، في اليوم الثاني ل ايڤنت Google Workspace 😉

بنكون معكم بكرة نحن فقط GDSC Yemen عبر الرابط :
https://gdscyemen.com/gworkspaceday2/

#GDSCMENA
#GoogleDeveloperStudentClubs
#DeveloperStudentClubs
#GDSCSanaaUni

كل عام ويمننا بألف خير
#١٤_اكتوبر_🇾🇪

انتهينا من أول سيشن في تراك ال Machine Learning ، وانتظرونا في سيشنز جاية 🤩🔥

الآن وبكل حماس نعلن عن افتتاح تراك الويب ، للناس الي حابة تتعلم web development ( برمجة المواقع) 🤩👏

احنا في GDSC بنعمل لكم ورشة لطيفة ، بتعرفوا فيها اساسيات برمجة المواقع 🤩

✅بتعرف كيف ممكن تعمل موقع خاص بك "portofolio" 😌👏

✅الورشة بتكون يومين في الاسبوع و موعد الورشة بنكون ننزله في جروبنا على فيسبوك
هذا رابط الجروب :
https://web.facebook.com/groups/4174747645985092/

✅ طبعاً بتعرف اساسيات ال HTML & CSS

بيكون معكم المتحدث: احمد هاني من مصر 🤩🔥 ، استنونا في أول يوم للايڤنت

🗓️ الأحد ، ١٧ اكتوبر
🕘 ٩ بتوقيت اليمن - ٨ بتوقيت مصر

وانضموا للجروب عشان تتابعونا كل مرة على الموعد 🔥

#GDSCMENA
#GoogleDeveloperStudentClubs
#DeveloperStudentClubs
#GDSCSanaaUni

⚠️⚠️⚠️⚠️⚠️⚠️⚠️

دعماً للخريجين والراغبين في صقل مهاراتهم العلمية وتحويلها إلى قدرات عملية 🤩

يسر شركة فيجول سوفت للبرمجيات المرئية Visualsoft بتقديم ورشة عمل (مجانية ) لمدة ثلاثة أشهر في الأنظمة المالية والإدارية ERP 👏🏼

المميزات 🤔 :
🔸 التعرف والبرمجة عن طريق قاعدة الابتكار InnovBase من إنتاج الشركة والحاصلة على براءة اختراع
🔸 إنجاز مشروع احترافي أثناء ورشة العمل بإشراف فريق المطورين لدى فيجول سوفت
🔸 شهادة مشاركة في ورشة ERP من شركة فيجول سوفت

الشروط 🤨 :
⭕ الإلتزام بالوقت المحدد للورشة.
⭕ الإلتزام بإنجاز المهام المطلوبة
⭕ الرغبة الشديدة لتعلم برمجة الأنظمة المالية والإدارية ERP

على من يجد في نفسه الرغبة للتقديم عبر الرابط التالي:

https://forms.office.com/r/7zfqB4M5v8

⚠️⚠️⚠️⚠️⚠️⚠️⚠️

‏⚡ Design Patterns ⚡

ايش هي نظرية الـ Design Patterns ؟! وايش فائدتها؟! وكيف نطبقها ؟!

موضوع اليوم جداً مهم لكل شخص، خصيصاً للأشخاص المُهتمين ببناء software بطريقة professional 💻⚡

‏سابقاً كان المُبرمجين يمروا بمشكلات متكررة اثناء بناء الـ SW
مِنها صعوبة في تعديل وتطوير الكود وكُلفة في الوقت والجهد، فأصبحت المشاكل مشتركة بينهم.

وعلى مر الزمن والخبرة بدأوا يحصروا المشكلات وبدأوا يعطوها مصطلحات علميه ويوجدوا لها أفضل طريقة حل وهذا ما يسمى بـ Best practice

‏نظرية الـ Design Patterns تنطبق في أي مجال شغالين عليه في SW سواءً Web developer , Desktop , Mobile

ومش بس في SW كمان النظرية تنطبق على علوم أُخرى مثل هندسة المباني وهندسة الإلكترونيات وحتّى الطبخ.

‏مثلاً
عند بناء عمارة بعدة طوابق فالمهندسين عندهم قواعد معينه للأساس من نسبة المواد والخ. عشان تكون العمارة بأساس قوي!

المهندسين مش في يوم وليله عرفوا هذي القواعد هم مروا بمشاكل لين اوجدوا هذي القواعد واصبح كُل المهندسين المعمارين يمشوا على هذي القواعد.

ونفس الشي ينطبق في SW

‏⚡إذاً مفهوم Design Patterns هو

- Best practice to solve common software problems

- مجموعه من القواعد الأفضل اللي بنحل فيها المشاكل الشائعة في SW

ولها أنماط مُختلفة بتستخدم بحسب الاحتياج.

‏⚡ الفائدة

-سهولة صيانة وتطوير وتعديل الكود بأقل مجهود.

-تتبع الأخطاء بكل سهولة وذلك بسبب ان النظرية تهدف إلى تقليل الترابط بين أجزاء الكود مع بعضها لبعض.

-بتخليك professional software engineer بمعنى بتلاقي نفسك تكتب كود اقل بكثير وقدراتك في حل المشاكل بتزيد بشكل ملحوظ جداً.

‏⚡و أخيراً كيف نطبق الـ Design Patterns

قبل تطبيق Best practice في حل المشكلات لابد انه نكون مراعين لمجموعة من
المبادئ واللي يُطلق عليها بـ SOLID Principles

وكلمة SOLID ليست مصطلح وانما اختصار للخمس المبادئ.

طيب هل المبادئ هذي هي Design Patterns 🤔؟

لا طبعاً..

‏هي مجموعة مبادئ لو اتبعتها في SW بتطلع SW جودته كويسه ويسهل عليك انه تطبق فيما بعد أي Design Patterns تشتغل فيه.

وبنفس الوقت يحسن من جودة SW، وهنا الجودة ما تقاس فقط بالأخطاء اللي بتحصل في Functionality ❗

ولكن لو حبيت تطور او تغير في SW بيكون بجهد اقل ⚡

‏طيب ايش هي SOLID Principles 🙄❗

هذا اللي رح اوضحه لاحقاً ان شاء الله 😊

أتمنى انه يكون الثريد هذا نال أعجابكم وبالتوفيق.🙏🏼❤️

#Design_Patterns #برمجه #software
#Ahlam_Mohammed

⚡SOLID Principles ⚡
(Part 1)

ايش هي SOLID ؟! وكيف نطبقها ؟!

أولاً SOLIDهي مبادئ او قواعد ارشاديه بنمشي عليها اثناء بناء SW بحيث انها تسهل علينا فيما بعد تطبيق أي Design Patterns وحتى لو ما طبقنا Design Patterns فهذي المبادئ بحد ذاتها بتحسن من جودة SW .

و بالرغم من أننا في 2021 إلا أن هذه المبادئ ما زالت غير مُتبعة وغير معروفة خصوصاً لدى المبرمجين الجدد، وهذه الأفكار والمفاهيم من أحد الفوارق بين كود مهندس البرمجيات الجيد والشخص الذي يضع كل شيء في دالة أو كلاس واحد.

⚡ أول مبدأ Single Responsibility Principle (SRP)

كلنا ما نحب تحمل مسؤوليات كثيره (الخارجة عن إرادتنا) لأنه بتخلي حياتنا معقدة وممكن بأي لحظة نتحول لقنبلة من أطرف سبب من كثرة الضغط 😵 نفس الشيء ينطبق على الكلاس.

عشان يكون بسيط وقابل للصيانة والتطوير لابد انه يكون مسؤول عن هدف واحد فقط كيف يعني 🤔! Uncle Bob قال:

“ there should never be more than one reason for a class to change”
يجب ألا يكون هناك أكثر من سبب يخليك تدخل للكلاس وتعدل فيه.

مثلاً لو كان عندنا كلاس PaymentProcessor لشحن الحساب وفيه عدة وظائف Methods مثل :

charge()
تستقبل المبلغ المطلوب للشحن وتعمل إجراءات الشحن.

createReport()
تنشئ تقرير عن عملية الشحن هل تمت او لا.

لو جينا نشوف كم سبب يخلينا ندخل الكلاس عشان نعدل فيه !

بنلاقي انه اول سبب هو تغير إجراءات الشحن وهذي وظيفة الكلاس مارح نختلف عليها 🙏.

ثاني سبب لو مثلاً بنغير في format التقرير! نضطر ندخل للكلاس ونغير الـ format وهذا هدف خارج عن مسؤولية الكلاس!!

اوك صح لابد من انشاء تقرير اثناء عملية شحن الحساب ولكن الكلاس غير مسؤول عن تعديل الـ implementation الخاص بأنشاء تقرير.

وعشان نحل المشكلة بيتم انشاء كلاس للتقرير ومن ثم يتم استدعاء دالة انشاء التقرير، وبكذا حققنا مبدأ SRP واصبح كُل راعٍ مسؤولٌ عن رعيته😊.

وأخيراً هذا المبدأ لا يطبق فقط على مستوى الـ Class وإنما على مستوى الـ Methods ايضاً.

.
يتبع..

⚡SOLID Principles ⚡
(Part 2)

‏⚡ ثاني مبدأ(OCP) Open Closed Principle

- should be open for extension, but closed for modification

- جميع مكونات تطبيقك من ال Classes او Methods يجب ان تكون مفتوحة للتوسعة وإضافة مميزات جديدة لكنها مغلقة امام التعديل .

‏مثلاً لو كان عندنا كلاس Employee وفيه method لحساب الراتب بعدد الساعات لأي موظف أي تستقبل عدد الساعات فقط،

واردنا فيما بعد تطوير الكلاس بحيث تكون method تحسب الراتب بعدد الساعات حسب نوع الموظف، فهنا نضطر نعدل في الكلاس ونخلي الدالة تستقبل عدد الساعات ونوع الموظف صح !

‏خلينا نتخيل السيناريو الي ممكن يصير بسبب التعديل 🤔

لنفترض انه عندنا client يستخدم الكلاس وأستدعى الدالة (واقصد بالـ client هنا أي جزء في البرنامج ) ، اكيد بيصير له Errors صح! .

‏لأنه الدالة أصبحت تستقبل متغيرين وليس متغير، فلو كان عندنا SW كبير متخيلين كمية التعديلات اللي بنسويها بسبب التعديل ! هذا غير امور الـ testing 😵.

‏لو طبقنا مبدأ OCP من البداية كُنا وفرنا وقت وجهد.

كيف 🤔!!

نرجع نتخيل السيناريو من البداية مع تطبيق مبدأ OCP

عندنا طريقتين تٌستخدم لتنفيذ المبدأ، إما Interface أو Abstract.

‏اولاً بنغير كلاس Employee لـ Interface بحيث تكون الدالة abstract وبعدها ننشئ كلاس للمدير وكلاس للموظف العادي ويورثوا من Interface وكل كلاس يعمل implementation للدالة بحسب احتياجه،

‏بحيث عندما تُستخدم الدالة من أي client سيتم انشاء obj من الكلاس المُراد سواءً مدير او موظف ومن ثم يتم استدعاء الدالة.

طيب ايش استفدنا 🙄!

‏لو في ما بعد حبيت تطور الكود وتخليه يحسب الراتب لنوع اخر من الموظفين، اللي عليك تنشئ كلاس لهذا الموظف ويورث كلاس Employee

أو مثلاً حبيت تضيف دالة لحساب الراتب الشهري بتضيفها طيبيعي في Interface وبعدها تستخدمها لأي كلاس.

وبكذا مارح نضطر إلى التعديل في كلاس Employee و تجنبنا اضرار التعديلات واصبح كلاس Employee قابل للإضافات ولكن مُغلق لأي تعديل.

‏أخيراً متى يُستخدم هذا المبدأ! إذا شفنا انه الكلاس قد يكون فيه عمليات متغيرة وليست ثابته. 🙏🏼

يتبع...

🔥 فرصة !!

للفتيات فقط في محافظة حضرموت 👩
للإنضمام الى مخيم تطوير تطبيقات الويب

📌 نبذة عن مخيم Web Full Stack
مخيم تدريبي وتطبيقي مكثف يستمر لمدة خمسة أشهر سيتم من خلاله تأهيل المتدربين على تطوير مواقع الويب و تطوير تطبيقات متكاملة بواسطة أفضل بيئات وأُطر التطوير.

فإذا كنتي بين 18 -35 عام وتمتلكين الرغبة والحماس اللازم لتنضمي لمخيم تطوير تطبيقات الويب

سجلي معنا عبر تواصلك معنا في أسرع وقت ممكن اما بإرسال سيرتك الذاتية أو بياناتك (اسمك الكامل ، تفاصيل مستوى تعليمك ، ارقام التواصل ) إلى ايميل الأكاديمية :
info@rcodingacademy.org

📌 ملاحظات هامة جداً حول التسجيل :-

1- اخر موعد للتسجيل يوم الأحد الموافق 24/10/2021
2- سيكون هنالك اختبار قبول للفتيات المسجلات ويجب عليكن المراجعة والاستذكار من الآن .
3- سيتم التواصل من الفتيات المسجلات خلال الأسبوع القادم لتحديد موعد اختبار القبول .

📌 اختبار القبول يتكون من قسمين نظري وعملي ويشمل المواد التالية :-

- C++ , OOP
- Database & SQL
- HTML , CSS
- JavaScript , PHP

مع تمنياتنا لكنّ بالتوفيق الدائم ،،،
.

⚡SOLID Principles⚡
(part 3)
‏⚡ ثالث مبدأ(LSP) Liskov Substitution Principle

ليسكوف هو اسم العالمة اللي اقترحت هذا المبدأ وهو مبدأ الاستبدال والتعويض اللي يعرفك متى تعمل وراثة من كلاس ثاني ومتى لا وهذا المبدأ يُعتبر تكملة للمبدأ OCP.

‘‘If you have class B inherits from class A then class A should be replaceable by class B without any changes’’

بمعنى اذا كان B يورث من A فإن سلوك الـ client لن يتغير ويظل يعمل بكفاءة اذا استخدمنا B بدلاً من A.

لنفترض لدينا كلاس للطيور وفيها دالتين eat , fly ويوجد كلاسين اخرين(البطريق، النورس) يرثوا من الطيور.

من الطبيعي ان كُل كلاس اصبح يمتلك fly,eat .

لو انشئنا كائن من كلاس الطيور واستخدمنا الدالتين
Bird a = new Bird()
a.fly()
a.eat()

ومن ثَم غيرنا نوع الكائن لكلاس النورس.
Bird a = new Seagull()

فهل سلوك الـ client لن يتغير ويظل يعمل بكفاءة 🤔!

نعم ،لأنه النورس بُكل بساطه يطير ويأكل، إذاً هُنا طبقنا مبدأ ليسكوف.

طيب لو نغير نوع الكائن لكلاس البطريق !
Bird a = new Penguin()

هنا من الطبيعي جداً أن سلوك الـ clint يتغير ولن يعمل بكفاءة لأن البطريق يأكل ولاكن لا يطير ، إذاً هُنا تفشل عملية الوراثة .

طيب ايش الحل🤔؟

موضح في الصورة (2) 🙏.

وأخيراً متى يُستخدم هذا المبدأ ؟!

حينما نجد بأن الكلاسات الفرعية لا تتصرف بنفس الكيفية التي تتصرف بها الكلاسات الرئيسية .

لذلك نحتاج إلى تطبيق هذا المبدأ من أجل أن نضمن أن الكلاسات المُشتقة تستطيع أن تتصرف وكأنها كلاس رئيسي دون أن يؤثر على سلوك الـ client.

يتبع..

⚡SOLID Principles⚡
(part 4)

⚡ رابع مبدأ(ISP) Interface segregation principle

- “ Clients should not be forced to depend on methods they do not use”

إذا كان يوجد كلاس يرث من Interface المفروض لا يعمل Impalement إلا للـ methods اللي هو يحتاجها .

لذلك عند بناء Interface يجب ان يكون كُل الـ methods الموجودة مرتبطة مع بعض مالم يتم تقسيمها إلا أكثر من Interface وهذا المبدأ شبيه إلا حدٍ ما من مبدأ SRP.

واقصد هُنا بالـ Interface أي جزء يستخدمه الـ client سواءً Class او Interface

مثلاً كان عندك Interface لطرق الدفع ، وشخص آخر حب يأخذ منك الواجهة هذي ويستخدمها في طريقة الدفع اونلاين

فأنت قولت له عشان تستخدم الواجهة لازم تعمل Implement للدالة الخاصة بالدفع اونلاين وكمان للدالة الخاصة بالدفع كاش عشان يشتغل معاك، طيب هو ما يحتاج الدفع كاش تجبره عليها ليش🙄؟

لذلك يتم تقسيم Interface وتكون كُل Interface خاصة بطريقة دفع مُعينه وبكذا حققنا مبدأ ISP وبنفس الوقت مبدأ SRP.

يتبع..

⚡SOLID Principles⚡

⚡ خامس مبدأ(DIP) Dependency Inversion Principle

“ High level modules should not depend upon low level modules. Both should depend upon abstractions”

الـ High level classes يجب ألا تكون مُعتمدة على low level classes و يجب ان يكون بينهما وسيط وهو abstractions.

على سبيل المثال افترض عندك كلاس سوبر ماركت وعشان تملي السوبر ماركت بالأصناف لابد انه تستخدم كلاسات كُل صنف مثلاً كلاس خضروات وكلاس الفواكه وتستدعي دالة الإضافة.

Fruit f = new Fruit();
f.add();
Vegetable v = new Vegetable();
v.add();

ونفس الشيء في بقية الأصناف ..

هنا كلاس السوبر ماركت يُعتبر ( High level ) مُعتمد بشكل كُلي على كلاسات الأصناف ( low level )،بمعنى أي تغيرات في ( low level ) لابد ان تنعكس في ( High level ) طيب ايش المشكلة اللي ممكن تصير🙄!

تخيل لو كلاس الفواكه عدل في دالة إضافة فاكهة ❗ هنا انت مضطر ترجع تعدل في كلاس السوبر ماركت.

وبكذا خالفنا مبدأ Open Close واصبح كلاس السوبر ماركت مفتوح للتعديلات😵وايضاً مُعتمد على كلاسات أخرى أي خالفنا مبدأ DIP .

طيب والحل ،السوبرماركت ضروري نضيف لها اصناف🤔❗

الحل هو عمل وسيط عن طريقه تضيف الصنف اللي تحتاجه وبدون ما تعتمد على الغير 😉 .

لنفرض الوسيط هو Interface يكون بداخلها دالة الإضافة، ومن ثم نجعل كلاسات الـ low level تعمل Implement لهذا الوسيط .

بحيث يستطيع كلاس السوبر ماركت التعامل مع low level عن طريق الوسيط .

وبكذا طبقنا المبدأ واصبح كلاس السوبر ماركت منعزل تماماً عن التغيرات اللي ممكن تحدث في كلاسات Low Level أي جعلنا الكلاس مُغلق عن أي تعديلات وبنفس الوقت غير مُعتمد على أي كلاس، أيضاً قللنا من Coupling واقصد بالـ Coupling هو ترابط الكود .

ملاحظة : عند زيادة Coupling في الكود يصبح صعب التعديل عليه او تطويره لذلك تسعى SOLID إلى تقليل من Coupling وزيادة Cohesion.

⚡أخيراً
هذه المبادئ يوجد بينهما علاقة بمعنى لو اخذت كُل منهم بشكل معزول عن الآخر وطبقته فسوف تحصل على فائدة ولكن ليست كبيرة.

تمنياتي لكم بالتوفيق 🙏❤

ندوة هذا الاسبوع في #بلوك_ون بعنوان (انشاء المواقع بدون برمجه)
خلال الندوة هذي ستتعرف على كيفية انشاء المواقع من دون برمجه باستخدام انظمة الCMS.
محاور الندوة
● تتعرف على انواع المواقع الالكترونية
● الاستضافات المجانية و المدفوعة
● حجز و كيفية ادارة الدومين
● مفهوم انظمه ادارة المحتوى
● انواع انظمة ادارة المحتوى المختلفة
● تركيب القوالب و الثيمات و الاضافات المختلفة
● مواقع المدونات و المواقع التعريفية للشركات
● انشاء مواقع متعددة اللغات
● ادوات مواقع المتاجر و التجارة الالكترونية
● رفع ونشر المواقع على الانترنت
يقدم الندوة : م/ مختار غالب
- مدرب في اكاديمية رواد للبرمجة
- معيد في كلية الحاسوب لعدد من الجامعات الخاصة
- متخصص في برمجة و تطوير مواقع الانترنت و التطبيقات
موعد الندوة:
الاربعاء: 3 نوفمبر 2021
من الساعة 3:00 مساء الى 7:00 مساء
المكان: حاضنة الأعمال #بلوك_ون (مؤسسة رواد)
شارع حدة جولة المصباحي عمارة النزيلي
الدور السادس مكتب 36
الرسوم: 3000 ريال يمني.
للتسجيل أرسل إسمك وإسم الندوة برسالة نصيه أو عبر الواتس آب إلى الرقم 777833433
#بلوك_ون
#مشاريع_ناشئة
#ريادة_اعمال
#ابدا_مشروعك