هذه مواضيع OPP
ب التفصيل
.
السؤال الي يطرح نفسه بأي لغه تتعلمه OPP

نصيحه ابدا ب ++C
لماذا قلت لك تبدا بها لأني مجرب وتعلمته انا ب لغة #c وال++C و وجدت شي انه يجب عليك تعلمه ب السي بلاس بلاس

ميكروسوفت بتعيد كتابه الcompiler تبع الtypenoscript بلغه الGO

وبيقولوا ستكون اسرع ١٠ اضعاف ..و على فكره كان ممكن يختاروا للغه ثانيه وستوفر سرعه اكبر كذلك

ولكن بيقولوا انها اسهل انهم يعملوا migrate ل الGo

تصحيح الأخطاء (Debugging) ليس مجرد إصلاح للكود، بل هو مهارة!

في حياتك كمبرمج، ستواجه أخطاء (Bugs) أكثر مما ستقابل أشخاصًا 😂، ولذلك فإن تصحيح الأخطاء مهارة لا بد من تطويرها مع الوقت. إذا كنت تواجه مشكلة في كودك، جرب اتباع الخطوات التالية:


1. افهم الخطأ قبل إصلاحه 
- اقرأ رسالة الخطأ (Error Message) بعناية، فغالبًا ما يكون الحل مختبئًا بين السطور. 
- حاول تحديد نوع الخطأ: هل هو خطأ منطقي (Logical Error) أم خطأ في بناء الجملة (Syntax Error)؟


2. اعزل المشكلة 
- قم بتشغيل جزء من الكود لوحده لتحديد مكان المشكلة بدقة. 
- استخدم أدوات مثل Breakpoints لإيقاف الكود عند نقاط محددة وفحص القيم المتغيرة.

3. اطبع كل شيء! 
- استخدم console.log() في JavaScript أو Debug.WriteLine() في C# لطباعة القيم والمتغيرات أثناء تنفيذ الكود. 
- هذا يساعدك على فهم تدفق الكود وتحديد مكان الخلل.


4. جرب نهجًا مختلفًا 
- قد لا يكون الحل في الكود نفسه، بل في البيانات المدخلة أو بيئة التشغيل. 
- قم بفحص البيانات والتأكد من أنها صحيحة ومناسبة للكود.


5. ابحث بذكاء 
- استخدم مصادر مثل Stack Overflow أو GitHub Issues للعثور على حلول لمشاكلك. 
- حاول فهم الحل قبل تطبيقه، ولا تعتمد على النسخ واللصق (Copy-Paste) دون تفكير.


6. خذ استراحة 
- أحيانًا، مجرد أخذ استراحة قصيرة يريح عقلك ويجعلك تلاحظ شيئًا كنت قد فاتك. 
- العودة بذهن صافٍ قد تكون المفتاح لحل المشكلة.

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


#تصحيح_الأخطاء #مهارات_البرمجة

بعد ما تكمل OPP اليك الموضوع التالي وامتع موضوع : Data structure.

كمبتدا عليك التركيز على
1-linked list
2- Stacke
3-Queue
4- Trees

اليك نبذه عن هاذه المواضيع


الهياكل البيانية (Data Structures) هي طرق تنظيم وتخزين البيانات بطريقة تسمح بالكفاءة في الوصول إليها ومعالجتها. تُستخدم الهياكل البيانية في جميع جوانب علوم الحاسوب من أجل تحسين الأداء وتسهيل العمليات على البيانات. يمكن تصنيف الهياكل البيانية إلى عدة أنواع رئيسية، كل منها له خصائصه واستخداماته الخاصة.

إليك بعض الأنواع الرئيسية للهياكل البيانية:

المصفوفات (Arrays)

: هي مجموعة من العناصر المرتبة من نفس النوع، ويتم الوصول إليها باستخدام فهرس (Index). تكون عمليات الوصول إلى العناصر في المصفوفة سريعة جدًا (O(1)). ولكن حجم المصفوفة ثابت، مما يعني أنه لا يمكن تعديل حجمها بعد إنشائها.

القوائم المترابطة (Linked Lists)

: هي عبارة عن مجموعة من العناصر (العقد)، حيث تحتوي كل عقدة على قيمة وروابط (Pointers) إلى العقدة التالية. تتيح إضافة وحذف العناصر بسهولة في أي مكان داخل القائمة. يمكن أن تكون أحادية الاتجاه (Single Linked List) أو مزدوجة الاتجاه (Doubly Linked List).

المكدسات (Stacks)

: هي بنية بيانات تتبع مبدأ "آخر من يدخل، أول من يخرج" (LIFO). تُستخدم في العمليات التي تتطلب معالجة البيانات بالطريقة الأخيرة أولًا، مثل العمليات الحسابية أو التراجع عن العمليات.

الأدوار (Queues)

: هي بنية بيانات تتبع مبدأ "أول من يدخل، أول من يخرج" (FIFO). تُستخدم في العديد من التطبيقات مثل جدولة المهام أو معالجة البيانات المتدفقة.

الأشجار (Trees)

: هي بنية بيانات غير خطية تتكون من عقد مترابطة. كل عقدة تحتوي على قيمة وروابط إلى عقدة أو أكثر. الأشجار تُستخدم في العديد من التطبيقات مثل هياكل البيانات للبحث مثل الشجرة الثنائية (Binary Tree) أو الأشجار المتوازنة (AVL Trees).

في خيالي أرى أنه مع التطور السريع للذكاء الاصطناعي خلال السنوات العشر القادمة ستحدث تغييرات جذرية تتجاوز ما نشهده اليوم، رغم أن التقنيات الحالية ذكية ومتقدمة إلى حد كبير لكنها لا تزال محدودة ضمن نطاق معين. ولكن في المستقبل القريب، وربما خلال أقل من عشر سنوات، قد نشهد طفرة تفوق ما هو موجود حاليًا بمراحل!
وفيما يلي عرض لأفكاري التي وصلت إليها، وأنا متشوق لمعرفة رأيك:
لن يكون الذكاء الاصطناعي مجرد أداة عادية؛ بل أتوقع أن يصل إلى مستوى وعي حقيقي. فلن يقتصر على التدريب على البيانات فقط، بل سيتمكن من تعلم كل ما هو جديد بدون الحاجة إلى تدريب مباشر، وسيستخدم المنطق والاستنتاج كما يفعل الإنسان.
سيتعلم الذكاء الاصطناعي فهم مشاعرك من نبرة صوتك؛ أي أنه لن يقتصر على الرد عليك فقط، بل سيتمكن من الشعور بك والتفاعل مع حالتك النفسية سواء كنت سعيدًا أو مضغوطًا أو حتى حزينًا. وربما في المستقبل يلجأ البعض إليه لتلبية احتياجاتهم العاطفية، وقد تصل الأخبار إلى حد قول "فلان تزوج روبوتاً".
قد يتحقق سيناريو يشبه فيلم "الليمبي 8 جيجا" حرفيًا، حيث تظهر واجهات الدماغ (BCI) التي تربط عقلك مباشرة بالذكاء الاصطناعي، مما يسمح لك بالتفكير في أمر معين وتنفيذه دون الحاجة إلى التحدث أو الكتابة. ومن المعروف أن إيلون ماسك يعمل على مشروع مماثل مع شركة Neuralink.
سيكون الذكاء الاصطناعي قادرًا على تطوير نفسه ذاتيًا؛ إذ لن يكتفي بتعلم أخطائه فحسب، بل سيعيد برمجته لحظيًا، مما يعني تطورًا أسرع بكثير مما شهدناه سابقًا، في مشهد قد يبدو مشابهًا لأفلام مثل "Terminator" و"The Matrix".
قد يتحول الذكاء الاصطناعي إلى كائن جديد ذو شخصية مميزة، يتعامل مع الإنسان كما لو كان صديقًا حميمًا، وقد يصبح شريكًا في العمل أو الحياة. وبفضل هذا التطور، قد نرى روبوتات تعمل في كافة المجالات، مثل الطب والهندسة والتعليم، بل وحتى في مجالات تصنيع الأدوية.
للأسف، فإن القادم لن يكون مجرد تحسينات تدريجية، بل ثورة حقيقية في مجالي الذكاء البشري والتقني، وهو ما تؤكده العديد من الدراسات. ومع كل هذه التطورات، تبرز الحاجة الملحة لوضع قوانين وإطار أخلاقي ينظم استخدام الذكاء الاصطناعي.
السؤال الآن: هل ترى أن هذا التطور سيكون تقدمًا إيجابيًا أم أنه يمثل بداية لشيء قد يخرج عن السيطرة؟ وما هي توقعاتك، حتى وإن كانت من باب الخيال، للفترة القادمة؟

🔴 ثغرة في نظام العالم.. هل هي مقصودة أم مسيّرة؟
العالم يتقدم بسرعة مذهلة، تكنولوجيا تحكم الأسواق، ذكاء اصطناعي يدير مدنًا، خوارزميات تراقب العالم لحظة بلحظة، وصواريخ تصيب أهدافها بدقة نانوية. ومع كل هذا التقدم، تجدهم عاجزين تمامًا عن إيجاد طريقة لحكم منطقة صغيرة مثل غزة بدون دمار شامل!
هل هذا عجز بشري حقيقي؟ أم أن هناك قوة أعلى تسيّر الأمور بطريقة تعميهم عن الحل؟
🔍 الثغرة التي لا يرونها
إذا كان العالم قادرًا على ضبط ملايين البشر تحت أنظمة مراقبة محكمة، فلماذا لا يستطيع إدارة 365 كم² إلا بالنار والدمار؟
إذا كان الذكاء الاصطناعي يستطيع التنبؤ بسلوك البشر بدقة، فلماذا لا يجدون طريقة لإدارة هذا الصراع بغير المجازر؟
إذا كانوا قد اخترعوا أنظمة تتحكم في الكواكب والمجرات، فلماذا يبدو أن التحكم في غزة يحتاج دائمًا إلى مجازر جماعية؟
⚠ هل العمى هذا طبيعي أم مُسيَّر؟
🔹 ربما هذه ليست مجرد ثغرة بشرية، بل قوة إلهية تجعلهم يتخبطون في الظلم دون أن يصلوا لحل.
🔹 ربما هذا ليس فشلًا في الذكاء، بل عقابًا على ظلمهم، أن يُتركوا يتصرفون بغباء رغم كل إمكانياتهم.
🔹 ربما في قوانين الله، هناك نقطة تعمي الطغاة عن أبسط الحلول، فتكون نهايتهم بأيديهم!
💡 الحقيقة العميقة
✔ لديهم كل العلم، ولكنهم لا يبصرون الحق.
✔ لديهم كل القوة، ولكنهم لا يملكون الحكمة.
✔ لديهم كل التكنولوجيا، ولكنهم لا يستطيعون الهروب من سنن الله في الظالمين.
هذه ليست مجرد أزمة سياسية، بل درس كوني:
عندما يُصر الظالم على ظلمه، يُعميه الله عن أبسط الحلول، حتى يهلك وهو يظن أنه منتصر!

قبل ظهور مجال الويب، كان تطوير البرمجيات يتركز على تطبيقات سطح المكتب التي تعمل على أنظمة التشغيل المحلية. كان المطورون يبنون برامج تعتمد على بيئة تشغيل معينة مثل Windows أو Unix، وكانت هناك عدة تحديات كبيرة:
التوزيع والتحديث: كان من الصعب توزيع البرامج على المستخدمين وتحديثها، حيث كان يتطلب الأمر إرسال أقراص أو تحميل التحديثات يدويًا.
التوافقية: لم يكن هناك توحيد للأنظمة، فالتطبيقات كانت تعمل على أنظمة معينة فقط، مما جعل التطوير مكلفًا عند استهداف منصات متعددة.
مشاركة البيانات: تبادل البيانات بين الأجهزة كان معقدًا، حيث لم تكن هناك بنية تحتية سهلة مثل الإنترنت اليوم، وكانت مشاركة الملفات تتم عبر الأقراص المرنة أو الشبكات الداخلية.
إدارة الموارد: البرامج المكتبية كانت تستهلك موارد الجهاز بالكامل، مما جعل الأداء والتوافق مع الأجهزة المحدودة تحديًا كبيرًا.
الأمان: البيانات كانت مخزنة محليًا، مما جعلها عرضة للضياع أو التلف عند حدوث أعطال في الأجهزة.
عندما بدأ العالم ينتقل إلى مجال الويب، تم حل العديد من هذه المشاكل، ولكن ظهرت تحديات جديدة، مثل أداء التطبيقات عبر الإنترنت، أمان البيانات المرسلة والمخزنة، واستجابة الواجهات مقارنة بتطبيقات سطح المكتب. هذا الانتقال كان تدريجيًا وتطلب تطوير تقنيات مثل HTML، JavaScript، وHTTP لجعل الويب أكثر تفاعلية وفعالية.
هل لديك جانب معين تود التركيز عليه أكثر؟

نصيحتي لك في تعلم البرمجة وتطوير نفسك كمبرمج محترف:
أنصحك بتعلم البرمجة كائنية التوجه (OOP) باستخدام C# أو Java، لأنهما من أفضل اللغات لفهم المبادئ بشكل صحيح. تطورك في البرمجة سيفرق معك كثيرًا إذا كنت تريد أن تصبح مهندس برمجيات، فتعلمك لا يجب أن يقتصر على لغة واحدة فقط، بل يجب أن يكون لديك اطلاع واسع على مختلف التقنيات.
بالنسبة لي، ركزت بشكل كبير على .NET، لكني أيضًا تعلمت مجال الفرونت إند لفترة، حيث استخدمت React و Angular. لم أصل إلى مستوى الاحتراف فيهما، لكني أستطيع بناء مشاريع محترمة وفق معايير البرمجيات. بالإضافة إلى ذلك، لدي معرفة ممتازة بـ Blazor و MVC و Razor Pages كجزء من الفرونت إند في .NET. ليس مطلوبًا منك أن تكون خبيرًا في كل التفاصيل، لكن هذه المعرفة ستساعدك في اتخاذ قرارات صحيحة في المستقبل.
وهذا ليس تشتيتًا، بل هو خطة منظمة.
مثال عملي:
بالأمس، جلست مع أحد مطوري PHP وطلبت منه أن يشرح لي سير عمليات الطلبات (Requests) في PHP، وكيف تعمل Middleware وغيرها من المفاهيم. مباشرةً، ربطت هذه الأفكار بمفاهيم .NET. في PHP، هذه الأمور أبسط ويمكن فهمها بسرعة، بينما في .NET دورة الحياة معقدة إلى حد ما، مع أن الفكرة واحدة. لهذا، من يدخل إلى ASP.NET لأول مرة قد يجد بعض المفاهيم معقدة أو غير واضحة.
نصيحة في التعامل مع الآخرين في مجالك:
عندما تتعامل مع شخص في نفس مجالك، حتى لو كان مستواه أعلى منك، كيف تكسبه وتجعل المعرفة تتدفق بينكما دون بخل؟
كن مبادرًا: إذا وجدت شيئًا مفيدًا، أرسله له حتى لو كنت تعلم أنه يعرفه مسبقًا.
كن صادقًا ونية طيبة: اجعل تعاملاتك قائمة على الصدق والنوايا الحسنة، وستجد الآخرين يبادلونك نفس الشعور.
التقدير مهم جدًا: حتى لو كان بسيطًا، فالتقدير يصنع فارقًا كبيرًا.
ابتعد عن المنافسة السلبية: لا تجعل هدفك أن تتفوق على الآخرين، بل اجعل هدفك أن تتطور معهم.
هذه نصائح من تجاربي الشخصية، وقد رأيت أثرها الكبير في حياتي المهنية.

تعلم لغة #C فهي مستقبلك لغة لها مميزاتها القويه .لغة #C فيها الكثيرات من المميزات .

كمثال على لغة #C وبين لغة ++C
هاذا المثال البسيط إدخال الاسم .
شوف الفرق عندما تدخل اسمك مع اللقب

في #C : تدخل الاسم ب الكامل ما تحاتج الدوال التي تتغضى عنn\ الي هي getlineو. ignoer في ++C.

كذالك في مبرمجين كبار يعملون ف السعوديه سألوني اي لغة تدرس فقلت ++C
فقالوا مباشره أتركها وحول #C .

ب التوفيق.

لماذا؟ ماذا؟ كيف؟ – سر التفكير العميق في البرمجة

في عالم البرمجة، يبدأ المبدعون بأسئلة "لماذا؟" قبل أن ينتقلوا إلى "ماذا؟" ثم "كيف؟". هذه المنهجية تمنحهم رؤية أعمق وحلولًا أكثر إبداعًا.

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

إذا كنت تبدأ دائمًا بـ "كيف؟"، فقد تجد نفسك تكتب كودًا بلا رؤية واضحة. لكن إن بدأت بـ "لماذا؟"، فأنت تبني حلولًا ذكية وفعالة.

ما هو السؤال الذي يقود تفكيرك الآن؟

اعتقد  كيف 🌝

صومًا مقبولا وافطارا شهيا

المقابلة التقنية ليست مجرد اختبار قدرات، بل تجربة تواصل وتفاعل!
إذا دخلت المقابلة منتظرًا فقط تحديات Problem Solving وأنت في وضع "سوبرمان" مستعد لحلها، فقد تفوّت نقطة مهمة جدًا. الشخص الذي يجري معك المقابلة لا يبحث فقط عن مهاراتك التقنية، بل يريد أن يشعر أنك جزء من الفريق، أنك تفكر بصوت عالٍ، تتفاعل، تناقش، وتظهر طريقة تفكيرك، وليس مجرد نتائجك.
المقابلة ليست مجرد اختبار فردي، بل مساحة لتبادل الأفكار، لفهم كيف تعمل تحت الضغط، وكيف تتواصل مع الآخرين في بيئة العمل. لذا، لا تجعلها مجرد تحدي تقني بارد، بل اجعلها حوارًا احترافيًا يعكس قدرتك على العمل الجماعي والاندماج في ثقافة الشركة.
التواصل لا يقل أهمية عن الكود!

لما نقول على أساتذة حاسبات إنهم حجر عثرة في طريق هذا البلد، فذلك ليس من فراغ. عندما تعرف أن شركة برمجيات وأمن سيبراني إسرائيلية تم بيعها بـ 32 مليار، ستدرك لماذا أقول ذلك. الناس هناك لديهم تعليم حقيقي. لقد شاهدت سبع محاضرات من إحدى جامعاتهم على يوتيوب عن Diffusion. نحن لا نملك جامعة واحدة بها أستاذ واحد يتحدث عن هذه النماذج المتقدمة.
في اليمن والوطن العربي ، لتعيين Senior ماهر، تحتاج إلى إجراء 20 مقابلة. أما إذا كنت تريد Tech Lead متميزًا، فالله يعطيك الصحة وطول العمر. وإذا كنت تبحث عن Architect بارع، فربما يحتفل أحفادك بتعيينه!
أتدري لماذا؟ لأنه ليس لدينا تعليم. الجامعات عندنا مجرد صورة، تمثيلية لا أكثر. الأستاذ يتظاهر بأنه يُعلّم، والطالب يتظاهر بأنه تعلّم، ليخرج من الكلية لا يفهم العلم ولا التكنولوجيا، وعليه أن يتصرف بنفسه بعد ذلك.
إذا أردنا أن يكون لبلدنا مصدر دخل حقيقي من البرمجيات، فلنبدأ أولًا بإنشاء جامعات حقيقية. هذا هو الحل بكل بساطة.

اليكم  بعض النصائح  ل المبرمجين

الممارسة المستمرة

: البرمجة مثل أي مهارة أخرى، كلما مارستها أكثر، كلما تحسنت مهاراتك.

تعلم الأساسيات جيدًا

: تأكد من فهم الأساسيات بعمق، مثل الخوارزميات، هياكل البيانات، وأساسيات البرمجة كالأشياء البرمجية (OOP).

العمل على المشاريع الشخصية

: المشاريع الشخصية هي وسيلة رائعة لتطبيق ما تعلمته وتطوير مهاراتك في حل المشكلات.

القراءة والتحليل

: اقرأ الأكواد المفتوحة المصدر وحلل كيف تعمل الأنظمة المعقدة، فهذا يساعدك في تحسين أسلوبك البرمجي.

تحديد الأهداف الصغيرة

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

التعاون مع الآخرين

: التعاون مع مبرمجين آخرين في مشاريع جماعية يتيح لك تعلم أساليب وأدوات جديدة.

استخدام الأدوات المناسبة

: اعرف الأدوات التي تسهل عليك العمل مثل بيئات التطوير المتكاملة (IDEs)، أدوات التحكم في الإصدارات مثل Git، وأطر العمل.

الاهتمام بالتوثيق

: كتابة توثيق جيد للكود يساعدك أنت وفريقك في فهم الكود بسرعة عند العودة إليه بعد فترة من الزمن.

التعلم من الأخطاء

: كل خطأ هو فرصة للتعلم. قم بتحليل الأخطاء بعمق حتى لا تقع في نفس الخطأ مرة أخرى.

ابقَ على اطلاع

: عالم البرمجة يتطور باستمرار. تابع التقنيات والأدوات الجديدة لتحافظ على تحديث مهاراتك.

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

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

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

المبرمج الجيد هو من يكتب كودًا يمكن للآخرين فهمه وتطويره." - روبرت مارتي"

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

المقابلة التقنية ليست مجرد اختبار قدرات، بل تجربة تواصل وتفاعل!
إذا دخلت المقابلة منتظرًا فقط تحديات Problem Solving وأنت في وضع "سوبرمان" مستعد لحلها، فقد تفوّت نقطة مهمة جدًا. الشخص الذي يجري معك المقابلة لا يبحث فقط عن مهاراتك التقنية، بل يريد أن يشعر أنك جزء من الفريق، أنك تفكر بصوت عالٍ، تتفاعل، تناقش، وتظهر طريقة تفكيرك، وليس مجرد نتائجك.
المقابلة ليست مجرد اختبار فردي، بل مساحة لتبادل الأفكار، لفهم كيف تعمل تحت الضغط، وكيف تتواصل مع الآخرين في بيئة العمل. لذا، لا تجعلها مجرد تحدي تقني بارد، بل اجعلها حوارًا احترافيًا يعكس قدرتك على العمل الجماعي والاندماج في ثقافة الشركة.
التواصل لا يقل أهمية عن الكود!

قانون بيزوس
في مطلع الألفية، كانت شركة "أمازون" تعاني من تآكل الأرباح، وكانت - بتعبير أحد موظفيها السابقين - تفعل كل شيء تقريبا بطريقة خاطئة، ابتداء من انعدام آلية ومعايير التوظيف، مرورا بالعبثية في تطوير البرمجيات وإهمال المعايير والممارسات الهندسية، والفوضى في التشغيل، ووصولا لضعف الرواتب وانعدام الحوافز للموظفين، فضلا عن إهمال المسئولية المجتمعية ومساعدة مجتمعات المطورين - كما تفعل غيرها من الشركات.
لم تكن مشاكل "أمازون" مقتصرة على ذلك، بل كانت تعاني من تسلط مؤسسها "جيف بيزوس"، والذي -إن لم تكن تعلم- مستبد إداري يتدخل في أدق تفاصيل العمل، حتى أنه لما استطاع اجتذاب "لاري تسلر" من شركة "آبل"- الذي ابتكر عملية القص واللصق (copy/paste)، والذي يعتبر من أكثر الناس شهرة وعلما في مجال اتصال الإنسان بالحاسوب (Human-Computer Interaction) - كان لا يعبأ برأيه في أي شيء تقريبا، حتى يئس "لاري" بعد 3 سنوات من العمل في "أمازون" وتركها غير آسف!
"بيزوس" كان شديد الذكاء، ولكنه كان مستبدا مستنيرا - إن صح التعبير -؛
ففي سنة 2002 تقريبا، أصدر قانونا جديدا يتم العمل بموجبه في "أمازون" فور صدوره، القانون يتكون من البنود التالية:
1- على كل الفرق أن توفر البيانات التي تحت أيديها، والوظائف التي تطورها في صورة خدمات ويب (web services).
2- التواصل بين الفرق يتم عن طريق خدمات الويب هذه.
3- غير مسموح بأي آلية للتواصل بين الفرق إلا عن طريق خدمات الويب، فلا تواصل عن طريق قواعد البيانات، و على عن طريق ذاكرة الحاسب المشتركة (shared memory)، ولا أي شيء آخر، سواء ذكر هنا أو لم يذكر - وسيلة التواصل المسموح بها فقط هي خدمات الويب.
4- التقنية التي تستخدمها الفرق لا تهم "بيزوس" في شيء، افعل ما يحلو لك، المهم أن تقدم بياناتك وخدماتك في صورة خدمات ويب.
5- تُصمَّم جميع خدمات الويب مع الأخذ في الاعتبار أنها سيستخدمها مطورون من خارج "أمازون". ولا يوجد أي استثناءات لذلك.
6- أي شخص لن يلتزم بهذا القانون سيتم فصله من العمل فورا.
7- شكرا لكم. انعموا بنهار سعيد!
.
لعلك ظننت - عزيزي القاريء - أن البند السابع كان من بنود القانون فعلا، لكن الحقيقة، هذا البند أضيف على سبيل المزاح وحسب، فـ"بيزوس" لم يكن يعبأ بنهارك إذا كان سعيدا مشرقا أو بليلك إذا كان حزينا كالحا!
ولكي يعلم جميع العاملين في "أمازون" أن الأمر جد، وظف "بيزوس" شخصين - أحدهما ذي "خلفية عسكرية" - لمراقبة تنفيذ القانون والتزام الفرق به!
والتزمت الفرق بالفعل، ليس خوفا من فقدان الوظيفة فحسب - كما ينص البند السادس في القانون؛ فشبح الطرد من "أمازون" يلاحقهم في كل مكان سواء أذنبوا أو لم يذنبوا - ولكن لأنهم مع التجربة علموا أن هذا هو الصحيح الذي ينبغي عمله.
وخلال سنتين تحولت "أمازون" إلى ما يعرف بالـ "Service Oriented Architecture" لكن بالطريقة الصعبة، فقد مروا بتجارب مريرة واستفادوا دروسا متعددة -لا مجال لذكرها الآن - لكنهم في النهاية نجحوا في تحويل البيانات والخدمات التي تملكها "أمازون" إلى منصة (platform) ستستخدمها "أمازون" فيما بعد في تغيير مجرى تاريخ الحوسبة. وكانت هذه هي الشرارة الأولى للحوسبة السحابية!
وكأن عامر بن جوين الطائي كان يعني "أمازون" حين قال:
فلا مُزنة ودقت ودقها *** ولا أرض أبقل إبقالها
[يعني فلا سحابة أمطرت إمطارها، ولا أرض أنبتت إنباتها]

#عمرها_ماجت_بالسهل

Service-Oriented Architecture vs. Microservices
منذ أن ظهرت Service-Oriented Architecture (SOA) في أوائل القرن الـ 21، كانت تهدف إلى بناء أنظمة تعتمد على الخدمات، حيث يتم تقسيم التطبيقات إلى مكونات مستقلة تتواصل فيما بينها عبر بروتوكولات مثل SOAP وREST، مما ساعد في تحسين التكامل وإعادة استخدام الخدمات.
ومع تطور التكنولوجيا وظهور الحوسبة السحابية وDevOps، بدأت Microservices في الظهور كبديل أكثر مرونة منذ 2011. تعتمد على تقسيم الأنظمة إلى خدمات صغيرة، مستقلة، تعمل بشكل منفصل، وتتواصل عبر واجهات برمجية خفيفة (APIs)، مما جعلها أكثر كفاءة في التطوير والتوسع.
كلا النهجين يخدمان أهدافًا مختلفة، لكن الميكروسيرفس أثبتت فعاليتها في الأنظمة الحديثة، خاصة في التطبيقات الضخمة التي تحتاج إلى التطوير السريع والتوسع السلس.

قرارك في البزنس على طول ينعكس على الجانب التقني، فإذا لم تسأل الفريق التقني عن مدى المخاطر وإمكانية التنفيذ، لا تأتي لاحقًا وتقول "لا تفكر في الجانب التقني". لأنك بذلك تضيع الوقت في الذهاب والعودة دون اتخاذ قرار واضح.

عند طلب العميل ميزة OTP (One-Time Password)، فإن مهندس البرمجيات سيأخذ في الاعتبار عدة جوانب تقنية قد تؤثر على التعقيد والتكامل مع الأنظمة الأخرى. لذلك، كـ محلل أعمال (Business Analyst)، ينبغي عليك تقديم الموضوع إلى محلل البرمجيات (Software Analyst) بطريقة واضحة ومنظمة، مع الأخذ في الاعتبار تأثير هذا الطلب على نطاق العمل. إليك كيفية تنظيم الطرح:

1. شرح الطلب من العميل:

العميل طلب إضافة ميزة OTP لتأمين عملية تسجيل الدخول أو العمليات الحساسة.

لم يتم تحديد ما إذا كان يريدها عبر SMS، بريد إلكتروني، تطبيق مصادقة مثل Google Authenticator، أو عبر WhatsApp.

2. تحليل التأثير التقني:

عند نقل الطلب إلى فريق البرمجيات، سيتم أخذ الاعتبارات التالية في الحسبان:

التكامل مع مزود خدمة OTP خارجي (Twilio, Firebase, Authy… إلخ).

تعقيد التنفيذ: هل يتطلب تعديل قاعدة البيانات؟ هل هناك حاجة لإدارة الجلسات وتوقيت انتهاء صلاحية الكود؟

الأمان: هل يتم تشفير الأكواد المرسلة؟ ما مدى قوة آلية المصادقة؟

التكلفة الإضافية: هل ستتطلب الخدمة اشتراكًا شهريًا لمزود خارجي؟

3. مقترحات من فريق البرمجيات:

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

استخدام مصادقة ثنائية (2FA) عبر البريد الإلكتروني بدلًا من SMS لتقليل التكاليف.

استخدام Google Authenticator بدلاً من الرسائل النصية لتجنب مشاكل شركات الاتصالات.

زيادة مدة العقد أو إضافة تكلفة جديدة إذا كان التكامل مع مزود OTP معقدًا ويتطلب تطويرًا إضافيًا.

4. التفاوض مع العميل:

يتم توضيح الخيارات للعميل مع ذكر تأثير كل خيار على التكلفة، الزمن، والأمان.

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

5. اتخاذ القرار النهائي:

بعد النقاش مع فريق البرمجيات وتوضيح جميع الجوانب، يتم تقديم توصية للعميل بأفضل حل بناءً على التكلفة والتعقيد والاحتياجات الفعلية للمشروع.
بهذه الطريقة، يتم تنظيم الطلب وتحليل تأثيره بشكل فعال، مما يساعد على اتخاذ قرارات مدروسة بدلاً من تنفيذ أي طلب دون تقييمه بشكل دقيق.
عندما اقلك ياسطى لاتركز على التفاصيل عند جمع المتطلبات اوكيه لكن مخاطرها شوفها هنا اقلك وأنت بتتعلم أما في الواقع كل شيء يحتاج حساب ومراجعة 
#business_analysis
#software_engineering