أهم شي أولًا: خليها تشتغل (First, make it work)
بعدين تقدر تزبط الشكل (Then make it pretty)
ولا تنسى تضيف اختبارات كثير (Add safety with lots of tests) عشان تتأكد إن كل شي تمام.
ابعد عن التعقيد الزايد (Stay away from over-engineering)، خلك بسيط وواضح.
وإذا حسيت الكود يبيله ترتيب؟ عدله ونسّقه (Refactor if needed – and it usually is!)

الـ Refactoring هو السلاح الخفي اللي يخلي كودك نظيف وسهل تتعامل معه.
خلك ذكي، نظّم كودك، واستمتع بالبرمجة!

#يوميات_مبرمج #Refactoring #CleanCode #نصايح_كود #برمجة

العنوان: "لو كلمت شات جي بي تي، كان حضرلي المحاضرة"

المعيد داخل المحاضرة، ماسك اللابتوب، والشرح شغال كأننا شغالين في جوجل،
وإحنا أصلاً لسه مش عارفين نثبت لينكس!

من سنة أولى لسنة ثالثة، بنتكلم عن أنظمة تشغيل، شبكات، قواعد بيانات، ولغات برمجة.
بس الواقع؟
أنا ما ثبتش لينكس، ولا مرة.
درست PHP، درست Python، بس ولا مرة كتبت كود حقيقي فيهم.

اللي اكتشفته؟
الموضوع مش ملزم!
يعني محدش بيتابع وراك إذا كنت فعلًا طبّقت ولا لأ،
إنت حر... تكتب في التقرير إنك عملت كل حاجة، وهما هيصدقوك.

المعيد بيشرحلك كأنك هتطلع بكرا تبني نظام تشغيل،
وإنت مش عارف تفرق بين CMD و Terminal.
بيطلب منك مشاريع مش بتتناسب مع اللي إنت فهمته أصلًا،
وبيعتبر أي سؤال إضافي "تضييع وقت".

طب لو كلمت شات جي بي تي، يحضرلي المحاضرة؟
أيوه، ويحضرها كمان بفهم، ويشرحلي بعد المحاضرة بمنطق وهدوء.

الجامعة بتقولك: "اللي عايز يتعلم، يتعلم لوحده."
طب ما توريني الطريق الأول؟ ما تديني تجربة حقيقية؟
مش تحفظني أوامر وخليني أكتب كود في Word!

المشكلة مش في المادة... المشكلة في طريقة التدريس، وفي عدم ربط العلم بالحياة.

أنا ما ثبتش لينكس، لكن كتبت في التقرير إني ثبتّه
ما برمجتش بـ PHP، لكن نجحت في المادة.
ليه؟
لأن النظام بيربي طالب بيجيد التمثيل، مش التطبيق.

فـ لو إنت طالب ولسه بتقول "هبدأ لما أخلص المنهج"،
أحب أقولك: المنهج مش هيخلص،
ابدأ من دلوقتي، واشتغل على نفسك بنفسك،
لأن الجامعة مش دايمًا بتعرف تجهزك... لكن أنت تقدر تجهّز نفسك.

فكرة إنك تضيف بوابة دفع في مشروعك مش حاجة واوو، الفكرة الحقيقية هي: هل انت مستعد تحمي نفسك من الفخاخ اللي جاية بعدها ولا لا؟

تعال نعرف مع بعض رحلة الدفع كيف بتم، وإيش الفخاخ اللي لازم نخلي بالنا منها من بدري. خلينا نمشيها "فخاخ" كذا كأنك ماشي في أرض ألغام!

شوف يا صديقي، العملية ماشية كذا:

تسجل العملية في قاعدة البيانات ترسل الطلب لبوابة الدفع عشان يتم تستلم التأكيد من بوابة الدفع (وهنا تبدأ الفخاخ!)

المحطة الأولى:
تسجيل العملية
أول حاجة تعملها إنك تسجل البيانات هذي عندك:

مين هو العميل؟ المبلغ كم؟ حالة العملية (بانتظار الدفع). تاريخ الطلب.
ليش نسوي كذا؟ لأن البيانات هذي بتكون المرجع لك لما تجي تتأكد من نجاح العملية. ولو نسيتها؟ مبروك عليك المشاكل يا صاحبي!

المحطة الثانية:
إرسال الطلب لبوابة الدفع
هنا الموضوع سهل، السيستم حقك يرسل البيانات لبوابة الدفع، والعميل يدخل بيانات البطاقة أو أي وسيلة دفع ثانية. ذي مش شغلتك، لأن بوابة الدفع هي اللي بتتعامل مع البنك والمشاكل التقنية هناك.

المحطة الثالثة:
استلام التأكيد (وهنا تبدأ الفخاخ!) الفخ الأول: إنك تصدق أي رد من بوابة الدفع!

بوابة الدفع ردت وقالت لك "تم الدفع"، رحت حدثت العملية عندك لـ "مدفوعة"، وسويت كل الخطوات؟ للأسف، ممكن يكون اتنصب عليك!

ليش؟ فيه أدوات مثل Charles Proxy و Burp Suite تخلّي أي أحد يعترض الطلب اللي رايح لبوابة الدفع، ويرد عليك هو، قبل ما يوصل الطلب. فيرسل لك بيانات مزيفة، وانت تصدق إنها حقيقية!

الحل؟ بعد ما توصلك البيانات، لازم ترسل Request ثاني من الباك إند لبوابة الدفع وتتأكد إن العملية فعلًا تمت هناك، مش مجرد أحد يضحك عليك.

الفخ الثاني:
التلاعب في المبلغ
حتى لو تأكدت إن العملية نجحت، انت متأكد إن العميل دفع المبلغ الصحيح؟

ممكن أحد يلعب في البيانات اللي رايحة لبوابة الدفع، مثلًا: اشترى منتج بـ100 دولار، لكن بدل ما توصل البوابة إنها تخصم 100، وصلها إنها تخصم 2 دولار بس!

الحل؟ لما تبعت طلب التأكيد لبوابة الدفع، لا تسأل بس "هل العملية نجحت؟"، لازم تسأل كمان "المبلغ كم؟"، وتقارنه باللي عندك.

الفخ الثالث:
حيلة استرجاع الفلوس (Refund Fraud)

العميل ممكن يدفع، وبعدها يتصل بالبنك ويقول إنه ما كان هو اللي دفع، والبنك يرجع له الفلوس، وانت تخسر! والأسوأ؟

ممكن يدخل يعيد نفس العملية، وانت تخزنها عندك كأنها جديدة، ويرجع يسترجع الفلوس، ويعيد الحركة مرة ثانية وثالثة!
الحل؟

اتأكد إن العملية مازالت pending مش refunded. حدد وقت انتهاء لكل عملية دفع، ولو تأخر الوقت تلغيها تلقائي. اتفق مع بوابة الدفع على حد أدنى للدفع.

الفخ الرابع: تجاهل الـ Webhooks!

بعض المبرمجين يعتمدوا على الرد المباشر من بوابة الدفع، وذا أكبر خطأ!

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

اعتمد على Webhooks، اللي هي إشعارات تجيك من بوابة الدفع لما يصير أي تغيير. سيستمك لازم يكون قادر يستقبلها ويتعامل معها صح.

إضافات مهمة ل الشباب:

التعامل مع الـ Idempotency: أحيانًا يصير تأخير أو تكرار في الطلبات، ممكن يسبب تنفيذ العملية مرتين بالخطأ. الحل؟ استخدم Unique Transaction ID، وتأكد ما في معاملة مكررة.

الالتزام بـ PCI DSS Compliance: لو تتعامل مع بيانات البطاقات مباشرة، لازم تلتزم بالمعايير الأمنية، لأن ذا الشي مو خيار، بل إلزامي.

لا تخزن بيانات الكروت عندك نهائيًا. استخدم التوكنز أو Customer IDs اللي توفرها بوابة الدفع.

تأكد إن السيرفر هو اللي يتعامل مع بوابة الدفع، مش الفرونت إند. الـ Signature من بوابة الدفع يضمن إن الرد جاي من عندهم فعلاً، مش مزور، بس مش كافي لحاله. لازم كمان تتأكد إن الـ Transaction ID ما يتكرر، عشان تمنع Replay Attacks.

بالنسبة للفخ الثاني
(التلاعب في المبلغ)، لو قلنا إن الحل هو التأكد من الدفع عن طريق طلب خلفي، طيب ما هو ممكن نفس الشخص يعترض الرد الثاني؟ الحل؟
اعتمد على Webhook أو IPN يجيك مباشرة من بوابة الدفع.

تأكد إن كل Transaction ID يُستخدم مرة وحدة فقط وبمدة محددة.
وفي الأخير خليك دائمًا يقظ، وتأكد إن كل خطوة في الدفع محمية كويس. وصدقني، الأمان في الدفع مش مجرد خطوة، دي رحلة كاملة لازم تكون مستعد لها من البداية للنهاية!

#أمان_الدفع #بوابة_الدفع #تطوير_ويب #حماية_المدفوعات #أمن_المعلومات #المدفوعات_الإلكترونية #مطورين #نصائح_برمجية #تجربة_مطور #فخاخ_الدفع

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

> لما تسمع معلومة جديدة من صديقك، وماتكون سمعت عنها من قبل، طبيعي جداً إنك تستغرب أو حتى ما تفهمها من أول مرة. بس الغلط الكبير إنك تسكت وتعمل نفسك خبير، كأنك عارف كل شيء من قبل!

صدقني، هالأسلوب يخسّرك كثير. لأنك لما تلبس قناع الفاهم، تحرم نفسك من فرصة حقيقية للتعلم. يمكن صاحبك عنده خبرة، أو مرّ بتجربة، أو قرأ شيء مفيد، ولو سألته وقلت له: "صراحة أول مرة أسمعها، ممكن توضح لي؟" — راح يقدّرك ويحترم فيك رغبتك في الفهم.

لا تخلي الكبرياء يمنعك من إنك تطور نفسك. مافيش إنسان يعرف كل شيء، والعلم عمره ما كان عيب، العيب إنك تتهرب من الفهم علشان ما يبان إنك مش عارف.

خليك دائمًا من النوع اللي يسأل، ويفهم، ويتواضع. التواضع في طلب العلم رفعة، مو نقصان. واللي يسأل اليوم، بكرة يكون هو اللي يُسأل.

إذا أنت مبرمج التطبيقات اللي ندوّر عليه،
قدّم على وظيفة App Developer معنا🖱

– مشاريع إبداعية تنشاف وتُستخدم
– بيئة تشجّعك تطوّر وتبدع
– الدوام حضوري في مقر الشركة
– رواتب مجزية
– مقر العمل صنعاء - *#مدري*😁
للتقديم، قم بتعبئة الفورما التالية ⇓
https://forms.gle/wkQ4w3iXCvP7KdQs7


#منقول

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

https://careers.hsayemen.com/lp/تمهيد/d6f2094cd85a04d2/?locale=ar_SA

اغتنموا الفرصة و سجلوا للتدريب في البرنامج التدريبي التأهيلي الاستثنائي 🔥🔥

خير الله واجد
موقع من أفضل المواقع الي استفدت لعمل prototype أصحاب ui/ux
جربته والله ضخم جدا ال free في limit
أتمنى أن يفيدكم ب ai

https://www.visily.ai/

تحذير مهم: لا تستخدم الشبكات العامة للإنترنت لمشاركة معلومات حساسة!
هل تعلم أن اتصالك بشبكة Wi-Fi عامة (زي الموجودة في المقاهي أو المولات) ممكن يعرّض بياناتك للخطر؟ خاصة لو دخلت موقع غير آمن (يبدأ بـ http:// بدل https://)!
ليش؟
الشبكات العامة غير مشفّرة، وأي شخص على نفس الشبكة ممكن يتجسس على اتصالك. ممكن يسرق معلوماتك، كلمات المرور، أو حتى بياناتك البنكية باستخدام أدوات بسيطة! والمواقع الغير آمنة ما تقدم أي حماية لبياناتك.
الحل؟
لا تدخل معلوماتك الخاصة في شبكة عامة. لا تستخدم مواقع غير آمنة (تأكد من وجود علامة القفل في المتصفح). استخدم VPN إذا اضطررت للشبكة العامة. أو الأفضل: استخدم باقة الجوال عند الحاجة.
احمِ نفسك، وكن واعيًا في عالم الإنترنت.

"الذكاء الاصطناعي... الطفرة التي جعلتنا نلهث خلف العالم"

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

لماذا؟

لأننا لم نكن قد وصلنا بعد إلى المرحلة التي كان فيها الآخرون قبل 10 سنوات، فجاء الذكاء الاصطناعي وقفز فوقنا بعقود. فصرنا لا نلحق فقط، بل نكافح لنفهم ما يحدث.

💔😂

عن تجربه 👇


عند استخدام GitHub، في خيارات مختلفة لتنظيم المشاريع والعمل الجماعي. في البداية، يمكن الواحد يبدأ بريبو في حسابه الشخصي، ويضيف الباقين كمساهمين. لكن مع مرور الوقت، بيواجهوا مشاكل، مثل:
الريبو بيكون مربوط بحساب شخص واحد، يعني لو الشخص هذا غاب أو حذف المشروع، بيضيع كل شيء. ما في صلاحيات واضحة بين الأعضاء، والكل يقدر يعدل أو يمسح من المشروع. الشكل العام للمشروع بيكون فوضوي، ما في هوية ثابتة للفريق أو المشروع.
لكن لو استخدمنا GitHub Organization بدلًا من الريبو الشخصي، الأمور بتتغير:
المشروع بيكون مرتبط باسم الفريق أو الشركة، مو باسم شخص واحد. تقدر توزع الصلاحيات بين الأعضاء بشكل واضح، سواء كانوا مالكين، مشرفين أو مطورين. لو واحد غاب أو خرج من الفريق، المشروع يظل محفوظ وما يتأثر. الشكل العام بيكون أكثر احترافية، وهذا مهم في حالة عرض الشغل أو في السيرة الذاتية.
الفرق بين الريبو الشخصي و Organization: الريبو الشخصي حلو لو بتشتغل لحالك، لكن في حالة العمل الجماعي، الـ Organization هي الخيار الأفضل، لأنها بتمنحك تحكمًا أفضل، وتنظيمًا دقيقًا للصلاحيات، وأمانًا أكبر للمشروع.
أما بالنسبة لـ Azure DevOps: هو قوي ولديه أدوات مفيدة مثل Pipelines و Boards، لكنه بيكون أكثر تعقيدًا في المشاريع الصغيرة. GitHub هو الأنسب في حالة المشاريع الجماعية الصغيرة أو الطلابية.
ولكن إذا كنت بتشتغل مع مجموعة أو على مشروع جماعي، استخدم GitHub Organization لأنه يوفر لك تنظيمًا أفضل وأمانًا للمشروع.

الصورة هذه توضح لك ليش DevOps

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

The resume said "10 years experience" The code said "1 year, ten times"

المرحلة الأولى: البداية والتخطيط

كنت في بداية المشروع، وقررت أنني سأستخدم Azure DevOps لتنفيذ الأتمتة، وكان الهدف أنني أتمكن من تسريع عمليات البناء والنشر باستخدام CI/CD pipeline.
لكن مع مرور الوقت، بدأت أواجه بعض التساؤلات التي كانت تقلقني:
"لماذا لا أستخدم GitHub Actions بدلاً من DevOps؟"
كنت أعرف أن GitHub Actions أصبح أحد الخيارات الشائعة في الأتمتة، وكان في بالي أن هذا الخيار قد يكون أسهل وأسرع.
لكن في الوقت نفسه، كنت أعلم أن Azure DevOps قد يقدم ميزات قوية أخرى، مثل التكامل السهل مع Microsoft Stack.

المرحلة الثانية: التساؤل عن GitHub Actions

بدأت أبحث في الفرق بين GitHub Actions و Azure DevOps:

GitHub Actions:

يوفر CI/CD مباشرة داخل GitHub.

يدعم الـ runners القابلة للتخصيص.

يعجبني أن GitHub هو المكان الذي أعمل فيه مباشرة مع المستودعات، لذا كان من الممكن أن يكون كل شيء في مكان واحد.

Azure DevOps:

يقدم بنية تحتية قوية للأتمتة.

يدعم الـ agents الجاهزة أو المحلية.

كنت أعرف أن Azure DevOps يعطي تحكمًا أكبر في بيئات العمل الحساسة، وهو شيء كنت أحتاجه لمشروعي.

لكن هنا بدأ السؤال يدور في رأسي: "هل GitHub Actions أفضل من Azure DevOps في هذه الحالة؟ أم أن Azure DevOps هو الخيار الأنسب نظرًا لمتطلبات الأمان والإدارة؟"

المرحلة الثالثة: الفرق بين Agent و Runner

بينما كنت أبحث، بدأت أتساءل:
"ما هو الفرق بين Agent و Runner؟"
كنت متأكدًا أن هناك شيء أساسي يفصل بين الاثنين، وكنت بحاجة لفهم هذا التفصيل.

الـ Agent (في Azure DevOps):

هو الخادم الذي يتولى عملية تنفيذ الـ pipeline.

يمكن أن يكون مستضافًا من قبل Microsoft أو مستضافًا محليًا (Self-hosted).

الـ Agent المستضاف يأتي جاهزًا من Microsoft، ويقوم بتشغيل المهام على بيئات مهيأة مسبقًا.

الـ Agent المحلي يمكن استخدامه لتخصيص البيئة بما يتناسب مع متطلبات الأمان والبنية التحتية الخاصة بك.

الـ Runner (في GitHub Actions):

هو نظير الـ Agent في GitHub Actions.

يعمل بنفس الطريقة، حيث يقوم بتشغيل المهام في البيئة المخصصة.

يمكنك استخدام Runner مستضاف من GitHub أو Runner محلي.

الفكرة في GitHub Actions أن الـ Runner يتحكم في بيئة العمل ولكن بتخصيص أكبر لاحتياجاتك، ويعمل مع كل مستودع على حدة.

المرحلة الرابعة: الأسئلة والتساؤلات الداخلية

بدأت أتساءل الآن بعد أن عرفت الفرق بين Agent و Runner:
هل أحتاج إلى استخدام DevOps Agent مع كل ميزاته الأمنية؟
أم أن GitHub Actions Runner سيحقق لي نفس النتائج، لكن بأسلوب أبسط؟
إذا كانت البيئة في شركتي حساسة، هل أحتاج إلى استخدام Self-hosted Agent (أو Self-hosted Runner في حالة GitHub Actions) لتحكم أكبر؟
لماذا أستخدم Agent من Azure DevOps إذا كنت أستطيع استخدام GitHub Actions مع Runner الذي يقدم تخصيص أكبر ومرونة أفضل في التعامل مع GitHub مباشرة؟

المرحلة الخامسة: القرار والتجربة

بعد التفكير والتساؤل، قررت أنني سأجرب كل خيار وأقيمه بناءً على الأمان والتحكم والتخصيص:

جربت GitHub Actions مع Runner:
كانت الفكرة بسيطة لأنني أعمل مع GitHub مباشرة.
الـ Runner المستضاف كان جيدًا، لكن شعرت أنني بحاجة إلى المزيد من التخصيص.
كان من السهل إعداد Self-hosted Runner ليتوافق مع بيئة العمل الخاصة بالشركة.

جربت Azure DevOps مع Agent:
البيئة كانت أكثر أمانًا وتخصيصًا.
الـ Agent المحلي أعطاني سيطرة أكبر على البيانات والبنية التحتية.
شعرت أن Azure DevOps يوفر تكامل أفضل مع الأنظمة الداخلية في شركتي.

المرحلة السادسة: التقييم النهائي

الآن وبعد التجربة:
هل GitHub Actions أفضل من Azure DevOps؟
بالنسبة لمشاريع صغيرة أو إذا كنت تعمل داخل GitHub فقط، يمكن أن يكون GitHub Actions خيارًا جيدًا بفضل مرونته.
أما إذا كنت بحاجة إلى تحكم أمني كامل في بيئة العمل، فـ Azure DevOps و الـ Agent المحلي سيكون أفضل بكثير.

النصيحة:

إذا كانت بيئة العمل في شركتك حساسة ولا تستطيع المخاطرة باستخدام حلول مستضافة من جهة خارجية، فإن Self-hosted Agent في Azure DevOps هو الخيار الأكثر أمانًا.
إذا كانت المرونة و التخصيص أكثر أهمية بالنسبة لك وتعمل بشكل أساسي على GitHub، فإن GitHub Actions مع Self-hosted Runner يمكن أن يكون الخيار الأفضل.


#Devops
#On_Promise

لو كنت تتواصل مع الذكاء الاصطناعي طوال يومك، تذكر أن تطلب منه في نهاية اليوم أن يسرد لك كل ما ناقشته معه. هذه الطريقة ستساعدك على تنظيم أفكارك وتوثيق كل النقاط المهمة. اليوم، كنت أعمل على تجربة أدوات الأتمتة، مثل GitHub Actions و Azure DevOps، وكنت أتساءل عن الفرق بين الـ Agent والـ Runner. مع الوقت، جربت الـ Self-hosted Agent في Azure DevOps، وأدركت الفرق الكبير في الأمان والتحكم في بيئة العمل. هذه التجربة غيرت الطريقة التي أفكر بها في تخصيص الأتمتة واستخدام الأدوات بشكل أكثر فاعلية. تعلمت الكثير، وحققت تحسن كبير في تطبيقاتي.

ياسطى لو عايز تكتب ال CV والله معك تاريخ في ChatGPT ماقصر سيعيد لك الماضي بذكرياته وأيام ما كان تنسخ وتلصق صدقني 🏃‍♂️

الطالب اللي بيدرس سوفتوير مهمل و مش مهتم يتعلم و بيقاوم الاستاذ بتاعه. تفتكر دي جمله منطقيه ؟
كمل و انت تعرف قصدي ايه.
ايه اللي لما يتحقق يخلي الطالب متحمس انه يحضر محاضرة و يبقي شايف انه بيتعلم بما يفيده ؟
انه يشوف ازاي اللي بيدرسه هيستخدمه.
دي مساله مهمة جدا.
لو حضرتك قلتلي ان نظام التشغيل عنده حاجة اسمها Process و حاجة اسمها Thread و غيره و غيره من المفاهيم. انا هفضل سامعك و مستني اعرف الكلام دا مرتبط بعملي المستقبلي ازي. لو حضرتك خلصت كلامك و انتهي الامر عند انك قولتلي التعريفات و خلاص هيبقي مش شايف فايده حقيقه من كلامك لانه مجرد سرد لتعريفات.
امال ايه المطلوب. المطلوب ان بعد متعمل تعريفات واضحه لكل شئ تبدا بقي تقولي ان مثلا الكود اللي بيعمل Context Switching كتير دا كود مؤذي و تديني كود بيستخدم عدد كبير من Threads و بيعمل Context Switching و تقيس قدامي الزمن اللازم لتنفيذ نفس المهمة باعدادا متغيره من ال Threads علشان اشوف تاثير ال Context Switching.
هنا بقي الطالب عرف ان اختيار عدد ال Threads مهم و مؤثر علي الاداء و شاف كود و درس تاثير عدد ال Threads. و اربط دا بقي بمفهوم CPU Bound and IO Bound Task و اشرح الفرق بينهم و اكتبلي كود علي كل حالة و اخيارات عدد ال Threads اللي بيتوقف علي نوع ال Task. لو عملت كده يبقي نظم التشغيل بترتبط في عقل الطالب بعملية التصميم و يشوف الكود لازم يعمل ايه و ليه.
قيس بقي علي كده كل شئ. الطالب اللي بيتعلم كده هيحب المحاضره و مش هيصرخ و يعيط لما تديله ماده اكتر.
هو زهقان من المحاضره لانه مش شافها مفيده لان الاستاذ مش عارف يقدم العلم كويس لاسباب كتير ليس اقلها انه هو نفسه مش عارف تاثير و لا تطبيق العلم اللي بيقدمه لغيره.
اللي بيقولك ان الكليات بتاعتنا مستواها تعبان عاوز يلاقي خريجين متعلمين كويس بهذا الشكل علشان يبقي منحني النمو بتاعهم اسرع لمصلحتهم و مصلحة شركاتهم.
مش هزهق من الموضوع و عندي امل ان الكلام يوصل للناس اللي في ايديها الحل و العقد و حد يقرر يطور المناهج و الاساتذه.

بعد عككك 😊 طويل وتأمل.....


أحيانًا لما أشوف مواضيع زي Cloud، Microservices، وAI… أحس إن العالم دخل دوامة تعقيد، لكن الواقع أوسع بكثير من كود ومعادلة.

العالم ما بيتطور لأنه حل مشكلة برمجية أو اخترع مكتبة جديدة أو طلع معادلة.


مش تقليل 😌 من أهمية البرمجة، بالعكس… هي الأساس،
لكن لوحدها ما تصنع التأثير الكبير بدون رؤية تجارية وتحليل سوقي ذكي.

التطور الحقيقي جاي من شركات ضخمة عندها عقول تجارية، رقمية، ونفسية، قاعدة تدرس وتحلل وتخطط وتبني إستراتيجيات. سواء كانت B2B أو B2C، الموضوع أكبر من كونه فقط “مشروع مطور”.

خذ مثال بسيط: مارك ما صنع واتساب لأنه عبقري برمجة، ولا فيسبوك لأنه توقع كل شي من البداية. لكن لأنه فهم السوق، والمجتمع، وكيف يتوسع خطوة خطوة.
اليوم لما تدخل AI في التطبيقات مثل واتساب، تحس الإضافات باهتة، ويمكن تقول "فين الذكاء؟". بس الواقع إنهم شغالين بمبدأ الـ Open/Closed Principle… التطبيق مفتوح للتوسع، لكن مغلق للتعديل الجذري، علشان ما يكسر البزنس.

الدروس اللي فهمتها من هذا كله:

مافي قرار مستقبلي تاخذه وانت متأكد منه 100%. العالم ماشي بالتجريب والتحليل والتكيّف مع السوق. المشاريع اللي تبنى اليوم من الصفر في عالم AI، بعضها بيذهلك من تصميمه وسلاسته، لأنه ببساطة… بدأ من لا شيء، لكن بتفكير جديد.

كلامي مش قانون، لكن تحليل من واقع متابعتي واستيعابي للّي يحصل. وربما أهم فائدة: لا تغرق في التقنية وتنسى تفكر بعين "العقل التجاري" و"تحليل السوق".

لا لا عندما اشوف مواضيع وكبر الانظمه cloud ميكروسرفيز وغيرها وتعقيداتها والي خائف من ai العالم بقاء متوسع في تطور في التجارة والصناعة وغيرها ليس فقط التكنولوجيا التطور هذا الي وصل اليه العالم ليس يعني من حل مشكله في كود ما أو عمل معادلة رياضيه الموضوع هنا الي وصل التطور هذا هي شركات عملاقه وهي الي الان بتتحكم بالسوق العالمي عندما عمل مارك مثلا واتس اب هل بفضل من برمج التطبيق لا والله بعد فتره تطور نزل فيسبوك ثم انستجرام الموضوع في عقول تجاريه و رقيميه ونفسيه مجهود جبار بيدرس المجتمع الذي بتستهدفه وتحلل وتقارن بين المنافسين وغيرها سواء B2B أو B2C وغيرها الان في تطور كبير في ai لكني لحظه بعض الأشياء وحللتها مثلا في بعض التطبيقات مثل واتساب وغيرها طريقها إضافة ميزات ومحاولة دمج ai في بعض التطبيقات تشوفه بايخه لاحد الان مثل وتس اب لكن الدرس المستفاد هنا هل فعلا مارك كان حاسب من زمان ان في المستقبل سيضف ال ai هو محلليه لا أعتقد لأن في الواقع بيعملو كل يوم على تطوير التطبيق والتخطيط وكثر تركيزهم هو على التوسع ماشين بمبدأ ال open closed وهنا كل يوم وتشاهد اضافه ميزه جديده بكل اريحيه فعندما بدأت المنافسه في ال ai هنا بتقلب في رأسك اخماس واسداس الان في عقلك ميزات ضخمه تقدر تضيفها وتدمجها على تطبيقك هنا مثل ماتفتح كلاس جديد وعملت الي تريد واضفت الي تريد لكن في افكر صعب تضيفها على شيء شغال من زمان في تحديات انك تغير في قلب البزنس ناهيك عن مشاريع الان تبنا من الصفر في هذا الثوره كيف فعلا يكون ظهورها تنذهل من كل الميزات حتى على مستوى التصميم فكلامي ليس 100% لكن هذا تحليل استفيد منه ان أصحاب التطو هذا ان لايوجد قرار للمستقبل يتخذ بدرجه 100%

#النسخة_الأصلية_بدون_ai