أقول لك، الواقع كان من طموحي قبل أن أدخل أن أطلع الأول 🎯، لكن دخلت وانصدمت بالواقع! 🚀 خطتي تحولت 360 درجة 🔄، إهمال 100% 😴، لا أيدي تكاليف ✍️، لا أذكر أي اختبار من سنة أولى 📚، لا يدخل يستعلم عن درجته من سنة أولى، لكنه حاسس كم جاء ساعة ما يخرج من الاختبار ⏳😂.
دي خريطة 🗺️ لمن يريد أن يمشي بها وكيف سيتخرج 🎓:
في الواقع، الواحد يقدر يطلع امتياز بدون أي تعب وجهد 🤷♂️، لكن الموضوع خرج تمامًا عن السيطرة أحيانًا.
أحيانًا تخرج بخمسينات 📉، وأحيانًا تهبش 🥴، وأحيانًا توفق بزميل 🧑🤝🧑، وأحيانًا توفق بكمبيوتر خارب 💻🔥، وأنت وحظك! 🎲
لكن أقول لك نصيحة ذهبية 🏆: لو تريد تستمتع بالرحلة 🚀، كن أفضل من يكون في تخصصك 💡، واتبع حب المهنة ❤️🔥!
دي خريطة 🗺️ لمن يريد أن يمشي بها وكيف سيتخرج 🎓:
في الواقع، الواحد يقدر يطلع امتياز بدون أي تعب وجهد 🤷♂️، لكن الموضوع خرج تمامًا عن السيطرة أحيانًا.
أحيانًا تخرج بخمسينات 📉، وأحيانًا تهبش 🥴، وأحيانًا توفق بزميل 🧑🤝🧑، وأحيانًا توفق بكمبيوتر خارب 💻🔥، وأنت وحظك! 🎲
لكن أقول لك نصيحة ذهبية 🏆: لو تريد تستمتع بالرحلة 🚀، كن أفضل من يكون في تخصصك 💡، واتبع حب المهنة ❤️🔥!
Forwarded from اللجنة العلمية CS 22 (ʙʀʜᴏᴏᴍ ⑇)
وانا اتصفح مشاريع GitHub مريت على هذه الريبو وحبيت فكرتها... يمكن تفيدكم:
مجموعة من الوظائف تمكن مطوري المواقع العربية من تقديم خدمة البحث الاحترافي وتقديم ومعالجة المحتوى العربي بلغة PHP
https://github.com/khaled-alshamaa/ar-php/
مجموعة من الوظائف تمكن مطوري المواقع العربية من تقديم خدمة البحث الاحترافي وتقديم ومعالجة المحتوى العربي بلغة PHP
https://github.com/khaled-alshamaa/ar-php/
GitHub
GitHub - khaled-alshamaa/ar-php: Set of functionalities enable Arabic website developers to serve professional search, present…
Set of functionalities enable Arabic website developers to serve professional search, present and process Arabic content in PHP - khaled-alshamaa/ar-php
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
🔹 التبسيط في البرمجة: فنٌ نادرٌ يستحق الإتقان 🔹
كتابة برامج معقدة يصعب التعامل معها هو أمرٌ في غاية السهولة، فجميع المبرمجين يمكنهم جعل الأمور معقدة! 😅 لكن الوصول إلى السهل الممتنع هو التحدي الحقيقي، وهو مهارة نادرة تتطلب خبرة، وذكاءً، وتوفيقًا من الله.
إن اختيار مستوى التعقيد المناسب لحل المشكلة هو أمرٌ ضروريٌ للغاية، إذ أن الإفراط في التعقيد يؤدي إلى كود صعب الصيانة، بينما التبسيط الذكي يجعل البرنامج أكثر مرونة وكفاءة.
تحدثنا في السابق عن بعض الأسباب التي تؤدي إلى تعقيد البرامج، كما تناولنا نصيحتين هامتين في التبسيط، وهما:
1️⃣ ابدأ صغيرًا
2️⃣ فرِّق تسُد
👈 في هذه المقالة، سنستكمل النصائح التي وفقني الله إليها وأفادتني كثيرًا، وأرجو أن تكون مفيدة لكم أيضًا.
3️⃣ لا تُعقّد الأمور من أجل "احتمالات مستقبلية" 🚫
إذا كنت تضيف تعقيدات إلى البرنامج لكي تغطي سيناريوهات "قد تحتاجها في المستقبل"، فدعني أخبرك شيئًا مهمًا: أنا قادمٌ إليك من المستقبل وأقول لك "لن تحتاجها!" وستجد نفسك غارقًا في التعقيدات التي أضفتها بلا داعٍ.
🔸 هناك مبدأ في البرمجة المتطرفة (Extreme Programming) يُدعى YAGNI، وهو اختصار لـ:
You Aren't Gonna Need It – "لن تحتاجها!"
💡 يقول "رون جيفريز" (Ron Jeffries)، أحد مؤسسي البرمجة المتطرفة:
"نفِّذ الأشياء التي تحتاجها فعليًا فقط، وليس تلك التي تتوقع أنك ستحتاجها مستقبلاً."
🔹 إذن، ماذا لو كنت متأكدًا بنسبة كبيرة أنني سأحتاجها لاحقًا؟ 🤔
هذا يقودنا إلى القاعدة التالية...
4️⃣ اتّخذ القرار في آخر لحظة مسؤولة ⏳
🔸 هذا المبدأ قادمٌ إلينا من كوكب اليابان، وتحديدًا من شركة تويوتا، وهو يساعدك في الإجابة على الأسئلة الصعبة مثل:
❓ كم من التصميم المسبق أحتاج قبل أن أبدأ؟
✅ الإجابة: قم ببناء الحد الأدنى الذي لا يمكنك البدء بدونه، مثل اختيار التقنيات، وهيكلة التطبيق، والعناصر الأساسية اللازمة لأول دورات التطوير (Sprints). أما ما تبقى، فأضفه أثناء العمل.
❓ كيف أستعد للتغييرات المستقبلية؟
✅ يقول "مارتن فاولر" (Martin Fowler):
"إذا كان تنفيذ الميزة في المستقبل سهلاً، فقم بتنفيذها مستقبلاً. أما إذا كان من الصعب إضافتها لاحقًا، فقم بها الآن."
5️⃣ استعِن بصديق 🤝
🔹 هذه من أهم النصائح! حتى لو كنت "تنينًا مجنحًا" في البرمجة 🐉، ناقش زملاءك في المشروع، وضعوا التبسيط كهدفٍ أساسي. هذا سيفيدكم جميعًا، وعن تجربة!
✨ لماذا؟
1️⃣ الشورى بركة، وستجد حلولًا قد لا تخطر لك وحدك.
2️⃣ كسب تأييد الفريق، حتى لا يأتي أحد لاحقًا ويقول: "أنا لم أكن مقتنعًا بهذه الفكرة!"
6️⃣ راعِ مستوى فريقك 👥
في أي فريق ستجد أنواعًا مختلفة من المبرمجين:
🔹 المغامر الجريء الذي يريد تجربة كل شيء.
🔹 المُبلّط في الخط الذي لا يريد الخروج من منطقته الآمنة (Comfort Zone).
💡 نصيحتي لك هنا: اجعل مستوى التعقيد أعلى قليلاً من متوسط الفريق، وليس أكثر من ذلك، ثم قم برفع المستوى تدريجيًا. بذلك، ستدفع الفريق للنمو دون أن تُرهقهم بتحديات لا تناسبهم.
🔹🔹🔹
🚀 الخاتمة:
تبسيط البرامج ليس مجرد مهارة، بل هو فنٌ يحتاج إلى ممارسة مستمرة. استخدم هذه القواعد، وستجد أن برامجك أصبحت أكثر كفاءة، وأمتع في العمل عليها!
كتابة برامج معقدة يصعب التعامل معها هو أمرٌ في غاية السهولة، فجميع المبرمجين يمكنهم جعل الأمور معقدة! 😅 لكن الوصول إلى السهل الممتنع هو التحدي الحقيقي، وهو مهارة نادرة تتطلب خبرة، وذكاءً، وتوفيقًا من الله.
إن اختيار مستوى التعقيد المناسب لحل المشكلة هو أمرٌ ضروريٌ للغاية، إذ أن الإفراط في التعقيد يؤدي إلى كود صعب الصيانة، بينما التبسيط الذكي يجعل البرنامج أكثر مرونة وكفاءة.
تحدثنا في السابق عن بعض الأسباب التي تؤدي إلى تعقيد البرامج، كما تناولنا نصيحتين هامتين في التبسيط، وهما:
1️⃣ ابدأ صغيرًا
2️⃣ فرِّق تسُد
👈 في هذه المقالة، سنستكمل النصائح التي وفقني الله إليها وأفادتني كثيرًا، وأرجو أن تكون مفيدة لكم أيضًا.
3️⃣ لا تُعقّد الأمور من أجل "احتمالات مستقبلية" 🚫
إذا كنت تضيف تعقيدات إلى البرنامج لكي تغطي سيناريوهات "قد تحتاجها في المستقبل"، فدعني أخبرك شيئًا مهمًا: أنا قادمٌ إليك من المستقبل وأقول لك "لن تحتاجها!" وستجد نفسك غارقًا في التعقيدات التي أضفتها بلا داعٍ.
🔸 هناك مبدأ في البرمجة المتطرفة (Extreme Programming) يُدعى YAGNI، وهو اختصار لـ:
You Aren't Gonna Need It – "لن تحتاجها!"
💡 يقول "رون جيفريز" (Ron Jeffries)، أحد مؤسسي البرمجة المتطرفة:
"نفِّذ الأشياء التي تحتاجها فعليًا فقط، وليس تلك التي تتوقع أنك ستحتاجها مستقبلاً."
🔹 إذن، ماذا لو كنت متأكدًا بنسبة كبيرة أنني سأحتاجها لاحقًا؟ 🤔
هذا يقودنا إلى القاعدة التالية...
4️⃣ اتّخذ القرار في آخر لحظة مسؤولة ⏳
🔸 هذا المبدأ قادمٌ إلينا من كوكب اليابان، وتحديدًا من شركة تويوتا، وهو يساعدك في الإجابة على الأسئلة الصعبة مثل:
❓ كم من التصميم المسبق أحتاج قبل أن أبدأ؟
✅ الإجابة: قم ببناء الحد الأدنى الذي لا يمكنك البدء بدونه، مثل اختيار التقنيات، وهيكلة التطبيق، والعناصر الأساسية اللازمة لأول دورات التطوير (Sprints). أما ما تبقى، فأضفه أثناء العمل.
❓ كيف أستعد للتغييرات المستقبلية؟
✅ يقول "مارتن فاولر" (Martin Fowler):
"إذا كان تنفيذ الميزة في المستقبل سهلاً، فقم بتنفيذها مستقبلاً. أما إذا كان من الصعب إضافتها لاحقًا، فقم بها الآن."
5️⃣ استعِن بصديق 🤝
🔹 هذه من أهم النصائح! حتى لو كنت "تنينًا مجنحًا" في البرمجة 🐉، ناقش زملاءك في المشروع، وضعوا التبسيط كهدفٍ أساسي. هذا سيفيدكم جميعًا، وعن تجربة!
✨ لماذا؟
1️⃣ الشورى بركة، وستجد حلولًا قد لا تخطر لك وحدك.
2️⃣ كسب تأييد الفريق، حتى لا يأتي أحد لاحقًا ويقول: "أنا لم أكن مقتنعًا بهذه الفكرة!"
6️⃣ راعِ مستوى فريقك 👥
في أي فريق ستجد أنواعًا مختلفة من المبرمجين:
🔹 المغامر الجريء الذي يريد تجربة كل شيء.
🔹 المُبلّط في الخط الذي لا يريد الخروج من منطقته الآمنة (Comfort Zone).
💡 نصيحتي لك هنا: اجعل مستوى التعقيد أعلى قليلاً من متوسط الفريق، وليس أكثر من ذلك، ثم قم برفع المستوى تدريجيًا. بذلك، ستدفع الفريق للنمو دون أن تُرهقهم بتحديات لا تناسبهم.
🔹🔹🔹
🚀 الخاتمة:
تبسيط البرامج ليس مجرد مهارة، بل هو فنٌ يحتاج إلى ممارسة مستمرة. استخدم هذه القواعد، وستجد أن برامجك أصبحت أكثر كفاءة، وأمتع في العمل عليها!
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
🎩 مرحبًا بك في عالم الهندسة البرمجية! ✨
هل تريد أن تعرف كيف تحدد هل تحتاج إلى تقسيم تطبيقك إلى طبقات؟ حسنًا، لن يكون ذلك عبر طريقة تقليدية مملة! 🚀 دعني آخذك في رحلة ملحمية عبر نظام برمجي يعيش ويتنفس ويتطور، حيث سنرى بأعيننا كيف يقرر النظام بنفسه متى يحتاج إلى طبقات! 🏗️
🏰 مرحلة البناء الأولى: "عندما يكون النظام طفلًا صغيرًا 👶"
في البداية، التطبيق صغير، مثل طفلٍ يلعب في حديقة، لا يحتاج إلى قواعد معقدة، مجرد ملف واحد، وقاعدة بيانات واحدة، وكل شيء مباشر وسلس. لا داعي لـ Repository ولا Service Layer، فقط DbContext والتوكل على الله! ☁️
📌 العلامات الدالة على هذه المرحلة:
عدد المستخدمين قليل (<100). لا يوجد تعقيد في البيانات. كل Resource يحتاج إلى عمليتين أو أقل. لا يوجد أكثر من مصدر بيانات واحد.
✅ الحل: لا تفكر في الطبقات الآن، فقط استمتع بالكود! 😎
🧑🎓 مرحلة النمو: "عندما يبدأ النظام في الذهاب إلى المدرسة 🎒"
النظام يكبر، المستخدمون يزدادون، الاستعلامات تتعقد! ⚡ الآن، فجأة، تجد نفسك مضطرًا إلى إعادة استخدام نفس المنطق أكثر من مرة، وهنا تبدأ فكرة الطبقات في الظهور! 👀
📌 العلامات الدالة على هذه المرحلة:
أكثر من 40 قاعدة عمل. كل Resource لديه عدة عمليات معقدة (أكثر من عمليتين لكل كيان). ظهور الحاجة إلى إعادة استخدام نفس العمليات. بدأت تجد نفسك تكرر نفس الكود في أكثر من مكان!
✅ الحل:
إنشاء Service Layer لعزل القواعد المنطقية عن الـ Controllers. بدء استخدام Repository Pattern إذا زادت تعقيدات التعامل مع البيانات.
🚀 الآن التطبيق لم يعد مجرد طفل، بل طالب مجتهد يتعلم النظام والهيكلة!
🏢 مرحلة العمل: "عندما يصبح النظام موظفًا مسؤولًا 👔"
🎯 الآن، التطبيق يخدم أكثر من 1000 مستخدم، ويتصل بأكثر من مصدر بيانات (APIs، Redis، Message Broker، إلخ)، وهناك استعلامات ثقيلة ومعقدة تتطلب أداءً عالٍ!
📌 العلامات الدالة على هذه المرحلة:
ارتفاع عدد المستخدمين (>1000). الاعتماد على أكثر من مصدر بيانات. وجود عمليات تتجاوز 3-5 خطوات لكل عملية رئيسية. الحاجة إلى إدارة الأداء عبر Load Balancer و Scaling.
✅ الحل:
إضافة Integration Layer للتعامل مع مصادر البيانات المختلفة. استخدام Background Jobs لتحسين الأداء وتقليل الضغط على الـ API. تنفيذ Caching Mechanisms مثل Redis لتسريع الاستعلامات الثقيلة. استخدام Load Balancer & Scaling لضمان استقرار النظام تحت الضغط.
🚀 النظام الآن موظف محترف، يعمل بكفاءة، ويستطيع التعامل مع الضغط!
🤖 مرحلة الذكاء الصناعي: "عندما يصبح النظام كيانًا ذكيًا مستقلًا! 🧠"
⚡ هنا يصل التطبيق إلى مرحلة النضج الفائق، حيث لم يعد مجرد مجموعة طبقات منظمة، بل أصبح نظامًا ذكيًا متكيفًا، قادرًا على التنبؤ بالضغط، توزيع الأحمال، وإدارة نفسه ذاتيًا!
📌 العلامات الدالة على هذه المرحلة:
مئات الآلاف أو الملايين من المستخدمين. استخدام Microservices بدلاً من التطبيق المتجانس (Monolith). وجود AI يساعد في تحسين تجربة المستخدم بناءً على البيانات. الاعتماد على Kubernetes و Serverless Architectures لتوزيع الأحمال تلقائيًا.
✅ الحل:
تبني الـ Microservices أو Event-Driven Architecture. استخدام AI و ML لتحليل سلوك المستخدمين وتحسين الأداء تلقائيًا. استغلال Serverless Functions لإنجاز العمليات الديناميكية.
🚀 هنا يصبح التطبيق ليس مجرد أداة، بل كيانًا ذكيًا يتطور ويتكيف مع المستقبل! 🤖
🎬 ختامًا: كيف نقرر؟
🧐 التطبيق هو كائن حي يتطور، فكر فيه كرحلة نمو!
✅ إذا كان بسيطًا، اتركه بسيطًا.
✅ إذا زادت القواعد والعمليات، افصل الطبقات.
✅ إذا تضخمت مصادر البيانات، أنشئ طبقة تكامل.
✅ إذا زاد الحمل، فكر في Load Balancing و Scaling.
✅ إذا كبر جدًا، ابدأ بتبني حلول متقدمة مثل Microservices و AI.
🎩 والآن، لديك طريقة لتحديد عدد الطبقات بدون أن يكون الأمر مجرد "قواعد جافة"—بل رحلة تنبض بالحياة، تشعر بها، وتتطور معها! 🚀
هل تريد أن تعرف كيف تحدد هل تحتاج إلى تقسيم تطبيقك إلى طبقات؟ حسنًا، لن يكون ذلك عبر طريقة تقليدية مملة! 🚀 دعني آخذك في رحلة ملحمية عبر نظام برمجي يعيش ويتنفس ويتطور، حيث سنرى بأعيننا كيف يقرر النظام بنفسه متى يحتاج إلى طبقات! 🏗️
🏰 مرحلة البناء الأولى: "عندما يكون النظام طفلًا صغيرًا 👶"
في البداية، التطبيق صغير، مثل طفلٍ يلعب في حديقة، لا يحتاج إلى قواعد معقدة، مجرد ملف واحد، وقاعدة بيانات واحدة، وكل شيء مباشر وسلس. لا داعي لـ Repository ولا Service Layer، فقط DbContext والتوكل على الله! ☁️
📌 العلامات الدالة على هذه المرحلة:
عدد المستخدمين قليل (<100). لا يوجد تعقيد في البيانات. كل Resource يحتاج إلى عمليتين أو أقل. لا يوجد أكثر من مصدر بيانات واحد.
✅ الحل: لا تفكر في الطبقات الآن، فقط استمتع بالكود! 😎
🧑🎓 مرحلة النمو: "عندما يبدأ النظام في الذهاب إلى المدرسة 🎒"
النظام يكبر، المستخدمون يزدادون، الاستعلامات تتعقد! ⚡ الآن، فجأة، تجد نفسك مضطرًا إلى إعادة استخدام نفس المنطق أكثر من مرة، وهنا تبدأ فكرة الطبقات في الظهور! 👀
📌 العلامات الدالة على هذه المرحلة:
أكثر من 40 قاعدة عمل. كل Resource لديه عدة عمليات معقدة (أكثر من عمليتين لكل كيان). ظهور الحاجة إلى إعادة استخدام نفس العمليات. بدأت تجد نفسك تكرر نفس الكود في أكثر من مكان!
✅ الحل:
إنشاء Service Layer لعزل القواعد المنطقية عن الـ Controllers. بدء استخدام Repository Pattern إذا زادت تعقيدات التعامل مع البيانات.
🚀 الآن التطبيق لم يعد مجرد طفل، بل طالب مجتهد يتعلم النظام والهيكلة!
🏢 مرحلة العمل: "عندما يصبح النظام موظفًا مسؤولًا 👔"
🎯 الآن، التطبيق يخدم أكثر من 1000 مستخدم، ويتصل بأكثر من مصدر بيانات (APIs، Redis، Message Broker، إلخ)، وهناك استعلامات ثقيلة ومعقدة تتطلب أداءً عالٍ!
📌 العلامات الدالة على هذه المرحلة:
ارتفاع عدد المستخدمين (>1000). الاعتماد على أكثر من مصدر بيانات. وجود عمليات تتجاوز 3-5 خطوات لكل عملية رئيسية. الحاجة إلى إدارة الأداء عبر Load Balancer و Scaling.
✅ الحل:
إضافة Integration Layer للتعامل مع مصادر البيانات المختلفة. استخدام Background Jobs لتحسين الأداء وتقليل الضغط على الـ API. تنفيذ Caching Mechanisms مثل Redis لتسريع الاستعلامات الثقيلة. استخدام Load Balancer & Scaling لضمان استقرار النظام تحت الضغط.
🚀 النظام الآن موظف محترف، يعمل بكفاءة، ويستطيع التعامل مع الضغط!
🤖 مرحلة الذكاء الصناعي: "عندما يصبح النظام كيانًا ذكيًا مستقلًا! 🧠"
⚡ هنا يصل التطبيق إلى مرحلة النضج الفائق، حيث لم يعد مجرد مجموعة طبقات منظمة، بل أصبح نظامًا ذكيًا متكيفًا، قادرًا على التنبؤ بالضغط، توزيع الأحمال، وإدارة نفسه ذاتيًا!
📌 العلامات الدالة على هذه المرحلة:
مئات الآلاف أو الملايين من المستخدمين. استخدام Microservices بدلاً من التطبيق المتجانس (Monolith). وجود AI يساعد في تحسين تجربة المستخدم بناءً على البيانات. الاعتماد على Kubernetes و Serverless Architectures لتوزيع الأحمال تلقائيًا.
✅ الحل:
تبني الـ Microservices أو Event-Driven Architecture. استخدام AI و ML لتحليل سلوك المستخدمين وتحسين الأداء تلقائيًا. استغلال Serverless Functions لإنجاز العمليات الديناميكية.
🚀 هنا يصبح التطبيق ليس مجرد أداة، بل كيانًا ذكيًا يتطور ويتكيف مع المستقبل! 🤖
🎬 ختامًا: كيف نقرر؟
🧐 التطبيق هو كائن حي يتطور، فكر فيه كرحلة نمو!
✅ إذا كان بسيطًا، اتركه بسيطًا.
✅ إذا زادت القواعد والعمليات، افصل الطبقات.
✅ إذا تضخمت مصادر البيانات، أنشئ طبقة تكامل.
✅ إذا زاد الحمل، فكر في Load Balancing و Scaling.
✅ إذا كبر جدًا، ابدأ بتبني حلول متقدمة مثل Microservices و AI.
🎩 والآن، لديك طريقة لتحديد عدد الطبقات بدون أن يكون الأمر مجرد "قواعد جافة"—بل رحلة تنبض بالحياة، تشعر بها، وتتطور معها! 🚀
❤1
لن تدرك أهمية Docker إلا عند العمل بـ Microservices، ولن تشعر أنك تطبق Microservices فعليًا إلا عند مرحلة Deployment! 😂
👍1🔥1
هذه فكرة مثيرة للاهتمام وتتلاقى مع بعض الفرضيات العلمية والخيالية حول الحضارات المتقدمة خارج الأرض. هناك العديد من النظريات التي تتحدث عن إمكانية وجود حضارات فضائية سبقتنا بآلاف أو ملايين السنين، وقد يكون تقدمها التكنولوجي غير قابل للتخيل مقارنة بما نعرفه.
بعض العلماء والمفكرين يتساءلون: إذا كانت هناك حضارات متقدمة، فلماذا لم نتواصل معها بعد؟ هذه الفكرة تُعرف بـ مفارقة فيرمي. بعض الإجابات المحتملة تشمل:
أنهم يراقبوننا دون تدخل، مثل تجربة علمية يدرسون فيها تطورنا.
أنهم متقدمون للغاية لدرجة أننا غير قادرين على إدراك وجودهم.
أنهم ببساطة غير مهتمين بنا، كما نحن غير مهتمين بالنمل في الغابة مثلاً.
أنهم كانوا هنا بالفعل في الماضي، وربما ساهموا في تطورنا، وهي نظرية تثيرها بعض الكتابات القديمة والأساطير.
هل لديك تصور معين عن نوع هذا التقدم الخيالي الذي تعتقد أنهم وصلوا إليه؟
بعض العلماء والمفكرين يتساءلون: إذا كانت هناك حضارات متقدمة، فلماذا لم نتواصل معها بعد؟ هذه الفكرة تُعرف بـ مفارقة فيرمي. بعض الإجابات المحتملة تشمل:
أنهم يراقبوننا دون تدخل، مثل تجربة علمية يدرسون فيها تطورنا.
أنهم متقدمون للغاية لدرجة أننا غير قادرين على إدراك وجودهم.
أنهم ببساطة غير مهتمين بنا، كما نحن غير مهتمين بالنمل في الغابة مثلاً.
أنهم كانوا هنا بالفعل في الماضي، وربما ساهموا في تطورنا، وهي نظرية تثيرها بعض الكتابات القديمة والأساطير.
هل لديك تصور معين عن نوع هذا التقدم الخيالي الذي تعتقد أنهم وصلوا إليه؟
🔥1
Forwarded from اللجنة العلمية CS 22 (Ayham Al-Akhali)
خدمه ال reasoning اصبحت متوفره الان في chatgpt
نتيجة المنافسة بين الغريم
ادخلوا جربوه 👍🏻
نتيجة المنافسة بين الغريم
ادخلوا جربوه 👍🏻
لو عايز تعمل لك مودل خاص بك حتى offline ادخل على موقع ollama تقريبا ونزل المودل الي يناسب مع إمكانيات جهازك لو انت بتخاف عبى بياناتك أو افترض قطع النت 🙋
أنت معك chatgpt بيدعم كل المجالات وانت فقط هتدربه مثلا على coding مثلا في مجال تخصصك لذلك سيكون خفيف على جهازك
زمان كان الوضع في إمكانيات بس كان صعب مثلا انك تحصل شبكة نت مثلا برغم ان اليوم الوضع صعب لكن أصبح من السهل ان تتعلم مثلا online يعني بالمختصر هذه نعمة عظيمة نحمد الله عليها حتى ولو كانت الظروف صعبة والعالم هاي والمعنى الأشياء الي كانت زمان صعبه اليوم من السهل ان تحصل عليها وشكرا
👍1🔥1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
هل تطلق الخدمة فورًا أم تنتظر حتى تصل إلى الكود المثالي؟ إنه السؤال الأزلي الذي يراود كل مبرمج!
في عالم البرمجة، نقف دومًا عند مفترق الطرق بين الإسراع في إطلاق الميزة المطلوبة، وبين التريث حتى نبلغ حد الكمال في الكود. لكن الحقيقة التي قد يغفل عنها البعض هي أن الكمال ليس حالة ثابتة، بل مفهوم متغير، والسعي خلفه دون توقف قد يصبح عقبة تعيق التقدم وتؤخر الإنجاز.
البرمجة ليست مجرد كتابة أكواد؛ إنها التزام بمواعيد وتسليم مهام في الوقت المحدد. وهنا تأتي أهمية السرعة في الإطلاق—إخراج المنتج إلى النور في لحظته المناسبة، حتى وإن لم يكن مثاليًا، ثم تحسينه شيئًا فشيئًا بناءً على الملاحظات والتجربة العملية.
لكن هذا لا يعني إهمال جودة الكود أو تجاهل مبادئ البرمجة النظيفة (Clean Code). فالكود يجب أن يكون قابلًا للصيانة، سهل الفهم، ومنظمًا بما يكفي لتطويره لاحقًا، لكنه ليس بحاجة إلى الكمال المطلق منذ اللحظة الأولى.
السعي إلى الكمال دون تنفيذ عملي قد يكون حجر عثرة، لكن التقدم المستمر هو المفتاح الحقيقي للوصول إلى أفضل النتائج مع مرور الزمن.
#دروس_اتعلمتها
في عالم البرمجة، نقف دومًا عند مفترق الطرق بين الإسراع في إطلاق الميزة المطلوبة، وبين التريث حتى نبلغ حد الكمال في الكود. لكن الحقيقة التي قد يغفل عنها البعض هي أن الكمال ليس حالة ثابتة، بل مفهوم متغير، والسعي خلفه دون توقف قد يصبح عقبة تعيق التقدم وتؤخر الإنجاز.
البرمجة ليست مجرد كتابة أكواد؛ إنها التزام بمواعيد وتسليم مهام في الوقت المحدد. وهنا تأتي أهمية السرعة في الإطلاق—إخراج المنتج إلى النور في لحظته المناسبة، حتى وإن لم يكن مثاليًا، ثم تحسينه شيئًا فشيئًا بناءً على الملاحظات والتجربة العملية.
لكن هذا لا يعني إهمال جودة الكود أو تجاهل مبادئ البرمجة النظيفة (Clean Code). فالكود يجب أن يكون قابلًا للصيانة، سهل الفهم، ومنظمًا بما يكفي لتطويره لاحقًا، لكنه ليس بحاجة إلى الكمال المطلق منذ اللحظة الأولى.
السعي إلى الكمال دون تنفيذ عملي قد يكون حجر عثرة، لكن التقدم المستمر هو المفتاح الحقيقي للوصول إلى أفضل النتائج مع مرور الزمن.
#دروس_اتعلمتها
أزي تعرف ان جهازك قد اخترقوه وتم سرقة معلومات اقل شيء الباسورد الي حافظها في المتصفح بتوع أمنية ↪
⬇️ ال
كيف يمكن لمحلل النظم (Business Analyst - BA) تقليل الأخطاء (Bugs) في النظام، والمساهمة في جودته، ومساعدة مهندسي الجودة في اختبارات التراجع (Regression Tests)؟ 🤔
✅ عندما يكون محلل النظم لديه فهم عميق للنظام، ومتطلباته، وتكامل أجزائه ومنتجاته، فإنه يستطيع تحديد جميع المناطق المتأثرة (Impacted Areas) التي قد تتأثر بأي تغيير أو متطلب جديد.
✅ بناءً على ذلك، سيتمكن المطور من أخذ هذه التبعيات (Dependencies) في الاعتبار أثناء عملية التطوير، مما يقلل من احتمالية حدوث أخطاء.
✅ بالإضافة إلى ذلك، سيتمكن مهندس الاختبار والجودة من تغطية جميع المناطق المتأثرة بالتغيير، بما في ذلك سيناريوهات التكامل (Integration Scenarios) وجميع السيناريوهات المحتملة التي قد تتأثر بالتعديلات الجديدة.
✅ كلما كانت المتطلبات موضحة بدقة عالية، ومكتوبة بتفاصيل كافية وواضحة للجميع، سواء للمطورين أو لمهندسي الجودة والاختبار أو المصممين، فإن ذلك يقلل من سوء فهم المتطلبات (Misunderstanding)، مما يضمن أن المطورين سينفذون المنتج بالشكل المطلوب، وأن مهندسي الجودة سيقومون بتغطية كافة السيناريوهات والاختبارات الضرورية.
⬇️ ال
كيف يمكن لمحلل النظم (Business Analyst - BA) تقليل الأخطاء (Bugs) في النظام، والمساهمة في جودته، ومساعدة مهندسي الجودة في اختبارات التراجع (Regression Tests)؟ 🤔
✅ عندما يكون محلل النظم لديه فهم عميق للنظام، ومتطلباته، وتكامل أجزائه ومنتجاته، فإنه يستطيع تحديد جميع المناطق المتأثرة (Impacted Areas) التي قد تتأثر بأي تغيير أو متطلب جديد.
✅ بناءً على ذلك، سيتمكن المطور من أخذ هذه التبعيات (Dependencies) في الاعتبار أثناء عملية التطوير، مما يقلل من احتمالية حدوث أخطاء.
✅ بالإضافة إلى ذلك، سيتمكن مهندس الاختبار والجودة من تغطية جميع المناطق المتأثرة بالتغيير، بما في ذلك سيناريوهات التكامل (Integration Scenarios) وجميع السيناريوهات المحتملة التي قد تتأثر بالتعديلات الجديدة.
✅ كلما كانت المتطلبات موضحة بدقة عالية، ومكتوبة بتفاصيل كافية وواضحة للجميع، سواء للمطورين أو لمهندسي الجودة والاختبار أو المصممين، فإن ذلك يقلل من سوء فهم المتطلبات (Misunderstanding)، مما يضمن أن المطورين سينفذون المنتج بالشكل المطلوب، وأن مهندسي الجودة سيقومون بتغطية كافة السيناريوهات والاختبارات الضرورية.
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
إذا كنت ترغب في بناء أساس قوي في البرمجة، فمن المهم أن تفهم المفاهيم الأساسية مثل البرمجة الكائنية (OOP)، هياكل البيانات، الخوارزميات، وأنماط التصميم، بالإضافة إلى معمارية البرمجيات. هذه الأمور ضرورية لأي مشروع برمجي كبير، بغض النظر عن لغة البرمجة أو الإطار (Framework) المستخدم.
هل يجب أن تتعلم .NET فقط؟
لا، .NET ليس الخيار الوحيد، لكنه قوي جدًا للمشاريع الكبيرة، تمامًا مثل Java. ومع ذلك، لا يعني هذا أن باقي اللغات والتقنيات غير صالحة. أي تقنية يمكن استخدامها بشكل صحيح لإنشاء مشاريع ضخمة إذا كان لديك المعرفة الصحيحة حول كيفية تصميمها وتوسيعها.
هل الجامعات تضيع وقتك مع Python؟
الجامعات تركز غالبًا على Python لأنها سهلة التعلم وتستخدم في عدة مجالات مثل الذكاء الاصطناعي وتحليل البيانات. لكن إذا كنت تريد أن تصبح مطور برمجيات متمكنًا، فأنت بحاجة إلى فهم أعمق للبرمجة وهيكلة المشاريع، وليس مجرد تعلم لغة معينة.
نصيحتي للمبتدئين:
لا تجعل إعلانات التوظيف مثل "نحتاج مطور React" أو "نبحث عن مطور ASP.NET Core" تدفعك لاختيار مسار معين بسرعة. هذه مجرد احتياجات حالية للشركات وقد تتغير مع الوقت.
ركز على فهم الأساسيات البرمجية أولًا، ثم اختر التقنية التي تناسبك بناءً على اهتماماتك والمجال الذي تريد العمل فيه.
تعلم كيفية بناء أنظمة قابلة للتطوير بدلاً من مجرد تعلم "كيف تكتب كودًا" في إطار معين.
إذا كنت في بداية المشوار، ركز على فهم البرمجة العميق وليس مجرد تعلم الفريم وورك الأكثر طلبًا في الوقت الحالي.
هل يجب أن تتعلم .NET فقط؟
لا، .NET ليس الخيار الوحيد، لكنه قوي جدًا للمشاريع الكبيرة، تمامًا مثل Java. ومع ذلك، لا يعني هذا أن باقي اللغات والتقنيات غير صالحة. أي تقنية يمكن استخدامها بشكل صحيح لإنشاء مشاريع ضخمة إذا كان لديك المعرفة الصحيحة حول كيفية تصميمها وتوسيعها.
هل الجامعات تضيع وقتك مع Python؟
الجامعات تركز غالبًا على Python لأنها سهلة التعلم وتستخدم في عدة مجالات مثل الذكاء الاصطناعي وتحليل البيانات. لكن إذا كنت تريد أن تصبح مطور برمجيات متمكنًا، فأنت بحاجة إلى فهم أعمق للبرمجة وهيكلة المشاريع، وليس مجرد تعلم لغة معينة.
نصيحتي للمبتدئين:
لا تجعل إعلانات التوظيف مثل "نحتاج مطور React" أو "نبحث عن مطور ASP.NET Core" تدفعك لاختيار مسار معين بسرعة. هذه مجرد احتياجات حالية للشركات وقد تتغير مع الوقت.
ركز على فهم الأساسيات البرمجية أولًا، ثم اختر التقنية التي تناسبك بناءً على اهتماماتك والمجال الذي تريد العمل فيه.
تعلم كيفية بناء أنظمة قابلة للتطوير بدلاً من مجرد تعلم "كيف تكتب كودًا" في إطار معين.
إذا كنت في بداية المشوار، ركز على فهم البرمجة العميق وليس مجرد تعلم الفريم وورك الأكثر طلبًا في الوقت الحالي.
Forwarded from InfoTechnology (IT4_2024)
🔁 الغوص في أعماق التكرار الذاتي (Recursion) 🔥
عندما تطرح سؤالًا على أي مبرمج عن التكرار الذاتي، ستجد الإجابة التقليدية جاهزة:
"إنها الدالة التي تستدعي نفسها، ويجب أن تحتوي على شرط إيقاف (Exit Condition) لضمان عدم الدخول في حلقة لا نهائية."
لكن، هل فكرت يومًا في ما يحدث خلف الكواليس؟ 🤯
🔎 اللغز الخفي داخل الذاكرة!
التكرار الذاتي يضع عبئًا ثقيلًا على ذاكرة المكدس (Stack Memory)! لماذا؟ لأن كل استدعاء جديد للدالة يُنشئ إطار مكدس (Stack Frame) جديد داخل الذاكرة، والذي يظل مشغولًا حتى ينتهي الاستدعاء ويُحرر من الذاكرة. لكن الكارثة الحقيقية تبدأ عندما لا يتم تحرير هذه الإطارات فورًا، بل يستمر التكديس الواحد تلو الآخر... حتى يحدث الانفجار! 💥
🎭 المشهد كما لو أنك تتسلق جبلًا بلا حبال!
تخيّل أنك تصعد جبلًا، ومع كل خطوة تضع حقيبة إضافية على ظهرك. في البداية، يبدو الأمر ممكنًا، لكن مع كل خطوة جديدة يصبح الحمل أثقل وأثقل... حتى تصل إلى القمة منهكًا بالكامل! ثم تبدأ رحلة العودة، حيث تتخلص من كل حقيبة في طريقك للأسفل، حتى تعود إلى نقطة البداية خفيفًا كما كنت. هذا بالضبط ما يحدث داخل المكدس (Stack) عند استخدام التكرار الذاتي!
⚠️ الخطر الحقيقي!
إذا كان الاستدعاء متكررًا بشكل مفرط أو على بيانات ضخمة، فقد يؤدي ذلك إلى نفاد الذاكرة (Stack Overflow) وانهيار البرنامج بالكامل! 🚨
🛠 الحل؟ فكر بطريقة أخرى!
بدلًا من التكرار الذاتي، يمكنك غالبًا إعادة تصميم الشيفرة باستخدام:
🔹 الحلقات (Loops) لتكرار العمليات بشكل مباشر دون استهلاك زائد للذاكرة.
🔹 المكدسات (Stacks) أو الطوابير (Queues) لمحاكاة الاستدعاء الذاتي ولكن بطريقة أكثر كفاءة.
🤔 لماذا يفضل عقلنا التكرار الذاتي؟
لأن العقل البشري يميل بشكل طبيعي إلى التفكير بـ الأنماط المتكررة! 💡
أضف إلى ذلك أننا كنا نُلقَّن منذ الصغر أن التكرار الذاتي هو "السحر الخفي" للمبرمجين المحترفين، وكأنه شارة الشرف التي تميز العباقرة! 🚀
💡 لكن الذكاء الحقيقي ليس في استخدام التكرار الذاتي، بل في معرفة متى يجب تجنّبه! 😏
عندما تطرح سؤالًا على أي مبرمج عن التكرار الذاتي، ستجد الإجابة التقليدية جاهزة:
"إنها الدالة التي تستدعي نفسها، ويجب أن تحتوي على شرط إيقاف (Exit Condition) لضمان عدم الدخول في حلقة لا نهائية."
لكن، هل فكرت يومًا في ما يحدث خلف الكواليس؟ 🤯
🔎 اللغز الخفي داخل الذاكرة!
التكرار الذاتي يضع عبئًا ثقيلًا على ذاكرة المكدس (Stack Memory)! لماذا؟ لأن كل استدعاء جديد للدالة يُنشئ إطار مكدس (Stack Frame) جديد داخل الذاكرة، والذي يظل مشغولًا حتى ينتهي الاستدعاء ويُحرر من الذاكرة. لكن الكارثة الحقيقية تبدأ عندما لا يتم تحرير هذه الإطارات فورًا، بل يستمر التكديس الواحد تلو الآخر... حتى يحدث الانفجار! 💥
🎭 المشهد كما لو أنك تتسلق جبلًا بلا حبال!
تخيّل أنك تصعد جبلًا، ومع كل خطوة تضع حقيبة إضافية على ظهرك. في البداية، يبدو الأمر ممكنًا، لكن مع كل خطوة جديدة يصبح الحمل أثقل وأثقل... حتى تصل إلى القمة منهكًا بالكامل! ثم تبدأ رحلة العودة، حيث تتخلص من كل حقيبة في طريقك للأسفل، حتى تعود إلى نقطة البداية خفيفًا كما كنت. هذا بالضبط ما يحدث داخل المكدس (Stack) عند استخدام التكرار الذاتي!
⚠️ الخطر الحقيقي!
إذا كان الاستدعاء متكررًا بشكل مفرط أو على بيانات ضخمة، فقد يؤدي ذلك إلى نفاد الذاكرة (Stack Overflow) وانهيار البرنامج بالكامل! 🚨
🛠 الحل؟ فكر بطريقة أخرى!
بدلًا من التكرار الذاتي، يمكنك غالبًا إعادة تصميم الشيفرة باستخدام:
🔹 الحلقات (Loops) لتكرار العمليات بشكل مباشر دون استهلاك زائد للذاكرة.
🔹 المكدسات (Stacks) أو الطوابير (Queues) لمحاكاة الاستدعاء الذاتي ولكن بطريقة أكثر كفاءة.
🤔 لماذا يفضل عقلنا التكرار الذاتي؟
لأن العقل البشري يميل بشكل طبيعي إلى التفكير بـ الأنماط المتكررة! 💡
أضف إلى ذلك أننا كنا نُلقَّن منذ الصغر أن التكرار الذاتي هو "السحر الخفي" للمبرمجين المحترفين، وكأنه شارة الشرف التي تميز العباقرة! 🚀
💡 لكن الذكاء الحقيقي ليس في استخدام التكرار الذاتي، بل في معرفة متى يجب تجنّبه! 😏
❤2
Forwarded from InfoTechnology (IT4_2024)
العلم يضيع بين الحياء والكبر، فمن يستحي من السؤال يفوته العلم، ومن يتكبر عن السؤال يضل عن الصواب.
فكوني أسألك يعني أن لدي حياءً، لكنه حياء من الخطأ، ولست أشعر بالخجل من التعلم، كما أنني لا أتكبر عن طلب العلم بتواضع ممن يملكه.
فلا تأتي أنت فتكتم العلم أو تتكبر وتتظاهر بالحكمة، لأن خيبتك هي الخيبة الحقيقية.
فكوني أسألك يعني أن لدي حياءً، لكنه حياء من الخطأ، ولست أشعر بالخجل من التعلم، كما أنني لا أتكبر عن طلب العلم بتواضع ممن يملكه.
فلا تأتي أنت فتكتم العلم أو تتكبر وتتظاهر بالحكمة، لأن خيبتك هي الخيبة الحقيقية.
👍1
Forwarded from InfoTechnology (IT4_2024)
قبل ظهور مجال الويب، كان تطوير البرمجيات يتركز على تطبيقات سطح المكتب التي تعمل على أنظمة التشغيل المحلية. كان المطورون يبنون برامج تعتمد على بيئة تشغيل معينة مثل Windows أو Unix، وكانت هناك عدة تحديات كبيرة:
التوزيع والتحديث: كان من الصعب توزيع البرامج على المستخدمين وتحديثها، حيث كان يتطلب الأمر إرسال أقراص أو تحميل التحديثات يدويًا.
التوافقية: لم يكن هناك توحيد للأنظمة، فالتطبيقات كانت تعمل على أنظمة معينة فقط، مما جعل التطوير مكلفًا عند استهداف منصات متعددة.
مشاركة البيانات: تبادل البيانات بين الأجهزة كان معقدًا، حيث لم تكن هناك بنية تحتية سهلة مثل الإنترنت اليوم، وكانت مشاركة الملفات تتم عبر الأقراص المرنة أو الشبكات الداخلية.
إدارة الموارد: البرامج المكتبية كانت تستهلك موارد الجهاز بالكامل، مما جعل الأداء والتوافق مع الأجهزة المحدودة تحديًا كبيرًا.
الأمان: البيانات كانت مخزنة محليًا، مما جعلها عرضة للضياع أو التلف عند حدوث أعطال في الأجهزة.
عندما بدأ العالم ينتقل إلى مجال الويب، تم حل العديد من هذه المشاكل، ولكن ظهرت تحديات جديدة، مثل أداء التطبيقات عبر الإنترنت، أمان البيانات المرسلة والمخزنة، واستجابة الواجهات مقارنة بتطبيقات سطح المكتب. هذا الانتقال كان تدريجيًا وتطلب تطوير تقنيات مثل HTML، JavaScript، وHTTP لجعل الويب أكثر تفاعلية وفعالية.
هل لديك جانب معين تود التركيز عليه أكثر؟
التوزيع والتحديث: كان من الصعب توزيع البرامج على المستخدمين وتحديثها، حيث كان يتطلب الأمر إرسال أقراص أو تحميل التحديثات يدويًا.
التوافقية: لم يكن هناك توحيد للأنظمة، فالتطبيقات كانت تعمل على أنظمة معينة فقط، مما جعل التطوير مكلفًا عند استهداف منصات متعددة.
مشاركة البيانات: تبادل البيانات بين الأجهزة كان معقدًا، حيث لم تكن هناك بنية تحتية سهلة مثل الإنترنت اليوم، وكانت مشاركة الملفات تتم عبر الأقراص المرنة أو الشبكات الداخلية.
إدارة الموارد: البرامج المكتبية كانت تستهلك موارد الجهاز بالكامل، مما جعل الأداء والتوافق مع الأجهزة المحدودة تحديًا كبيرًا.
الأمان: البيانات كانت مخزنة محليًا، مما جعلها عرضة للضياع أو التلف عند حدوث أعطال في الأجهزة.
عندما بدأ العالم ينتقل إلى مجال الويب، تم حل العديد من هذه المشاكل، ولكن ظهرت تحديات جديدة، مثل أداء التطبيقات عبر الإنترنت، أمان البيانات المرسلة والمخزنة، واستجابة الواجهات مقارنة بتطبيقات سطح المكتب. هذا الانتقال كان تدريجيًا وتطلب تطوير تقنيات مثل HTML، JavaScript، وHTTP لجعل الويب أكثر تفاعلية وفعالية.
هل لديك جانب معين تود التركيز عليه أكثر؟
😍1
Forwarded from InfoTechnology (IT4_2024)
قبل ظهور تقنيات الويب وHTTP، كان التواصل بين تطبيقات سطح المكتب يتم بعدة طرق رئيسية:
الملفات المشتركة (Shared Files): كان يتم تبادل البيانات عبر ملفات نصية أو قواعد بيانات مشتركة يتم قراءتها وكتابتها من قبل التطبيقات.
الشبكات المحلية (Local Network - LAN): استخدموا بروتوكولات مثل TCP/IP أو Named Pipes للتواصل بين الأجهزة عبر الشبكة المحلية.
الرسائل بين العمليات (Inter-Process Communication - IPC): مثل Windows Messaging أو Memory-Mapped Files، حيث كانت البرامج تتبادل البيانات عبر ذاكرة مشتركة.
تقنيات الـRPC (Remote Procedure Call): مثل DCOM (Distributed Component Object Model) من مايكروسوفت أو CORBA (Common Object Request Broker Architecture)، حيث كانت التطبيقات تستدعي وظائف في برامج أخرى عبر الشبكة.
قواعد البيانات (Database Communication): إذا كان التطبيقان يتشاركان قاعدة بيانات، فكان يمكن للتطبيق الأول كتابة البيانات والتطبيق الآخر قراءتها مباشرة.
FTP أو ملفات مشاركة (File Transfer Protocol): إذا كانت البيانات تحتاج إلى تبادل عبر الإنترنت أو بين أنظمة مختلفة، فكانوا يستخدمون FTP أو SMB لمشاركة الملفات.
لما جاء الويب، استبدلت هذه الطرق بـ REST APIs وSOAP عبر HTTP، مما جعل التواصل أسهل وأوسع انتشارًا. هل لديك سيناريو معين تحاول فهمه؟
الملفات المشتركة (Shared Files): كان يتم تبادل البيانات عبر ملفات نصية أو قواعد بيانات مشتركة يتم قراءتها وكتابتها من قبل التطبيقات.
الشبكات المحلية (Local Network - LAN): استخدموا بروتوكولات مثل TCP/IP أو Named Pipes للتواصل بين الأجهزة عبر الشبكة المحلية.
الرسائل بين العمليات (Inter-Process Communication - IPC): مثل Windows Messaging أو Memory-Mapped Files، حيث كانت البرامج تتبادل البيانات عبر ذاكرة مشتركة.
تقنيات الـRPC (Remote Procedure Call): مثل DCOM (Distributed Component Object Model) من مايكروسوفت أو CORBA (Common Object Request Broker Architecture)، حيث كانت التطبيقات تستدعي وظائف في برامج أخرى عبر الشبكة.
قواعد البيانات (Database Communication): إذا كان التطبيقان يتشاركان قاعدة بيانات، فكان يمكن للتطبيق الأول كتابة البيانات والتطبيق الآخر قراءتها مباشرة.
FTP أو ملفات مشاركة (File Transfer Protocol): إذا كانت البيانات تحتاج إلى تبادل عبر الإنترنت أو بين أنظمة مختلفة، فكانوا يستخدمون FTP أو SMB لمشاركة الملفات.
لما جاء الويب، استبدلت هذه الطرق بـ REST APIs وSOAP عبر HTTP، مما جعل التواصل أسهل وأوسع انتشارًا. هل لديك سيناريو معين تحاول فهمه؟
👍1
Forwarded from InfoTechnology (IT4_2024)
المتصفح مثل Chrome أو Firefox هو في الأساس تطبيق سطح مكتب، لكنه مخصص لعرض صفحات الويب. فكر فيه كبرنامج يأخذ ملفات HTML وCSS وJavaScript، ثم يقوم بترجمتها وعرضها على الشاشة بطريقة مفهومة للمستخدم.
كيف يفهم المتصفح الـ HTML ويعرضه؟
المتصفح يمر بعدة مراحل لمعالجة الصفحة:
جلب المحتوى (Fetching):
عندما تكتب عنوان موقع أو تضغط على رابط، المتصفح يرسل طلب HTTP إلى الخادم.
الخادم يرد بملفات HTML، CSS، JavaScript، وصور، وغيرها.
تحليل المحتوى (Parsing):
يقوم المتصفح بقراءة كود HTML وبناء شجرة DOM (Document Object Model)، وهي تمثيل هيكلي للصفحة.
في نفس الوقت، يتم تحليل CSS وبناء شجرة CSSOM (CSS Object Model)، وهي المسؤولة عن الألوان والتنسيقات.
تكوين الصفحة (Render Tree Construction):
يتم دمج DOM وCSSOM لإنشاء شجرة العرض (Render Tree)، وهي ما يراه المستخدم فعليًا.
التخطيط (Layout):
المتصفح يحسب مواقع العناصر وأحجامها وفقًا للقواعد المحددة في CSS.
الرسم (Painting):
يتم رسم العناصر على الشاشة باستخدام GPU أو CPU، حيث يتم تحويل التصميم إلى بيكسلات تُعرض على الشاشة.
تنفيذ JavaScript (إن وجد):
يقوم محرك JavaScript (مثل V8 في Chrome وSpiderMonkey في Firefox) بتنفيذ الأكواد البرمجية، مثل التفاعلات مع المستخدم أو تحديث الصفحة بدون إعادة تحميلها.
ما هو المتصفح بالضبط؟
المتصفح هو برنامج يتكون من عدة أجزاء رئيسية:
محرك التقديم (Rendering Engine): مثل Blink في Chrome أو Gecko في Firefox، وهو المسؤول عن تحليل HTML وCSS وعرض الصفحة.
محرك JavaScript: مثل V8 في Chrome، وهو الذي ينفذ أكواد JavaScript.
مدير الشبكة: مسؤول عن تحميل الموارد من الإنترنت باستخدام HTTP/HTTPS.
واجهة المستخدم: الأزرار، شريط العناوين، الإعدادات... إلخ.
هل لديك نقطة معينة تريد التعمق فيها أكثر؟
كيف يفهم المتصفح الـ HTML ويعرضه؟
المتصفح يمر بعدة مراحل لمعالجة الصفحة:
جلب المحتوى (Fetching):
عندما تكتب عنوان موقع أو تضغط على رابط، المتصفح يرسل طلب HTTP إلى الخادم.
الخادم يرد بملفات HTML، CSS، JavaScript، وصور، وغيرها.
تحليل المحتوى (Parsing):
يقوم المتصفح بقراءة كود HTML وبناء شجرة DOM (Document Object Model)، وهي تمثيل هيكلي للصفحة.
في نفس الوقت، يتم تحليل CSS وبناء شجرة CSSOM (CSS Object Model)، وهي المسؤولة عن الألوان والتنسيقات.
تكوين الصفحة (Render Tree Construction):
يتم دمج DOM وCSSOM لإنشاء شجرة العرض (Render Tree)، وهي ما يراه المستخدم فعليًا.
التخطيط (Layout):
المتصفح يحسب مواقع العناصر وأحجامها وفقًا للقواعد المحددة في CSS.
الرسم (Painting):
يتم رسم العناصر على الشاشة باستخدام GPU أو CPU، حيث يتم تحويل التصميم إلى بيكسلات تُعرض على الشاشة.
تنفيذ JavaScript (إن وجد):
يقوم محرك JavaScript (مثل V8 في Chrome وSpiderMonkey في Firefox) بتنفيذ الأكواد البرمجية، مثل التفاعلات مع المستخدم أو تحديث الصفحة بدون إعادة تحميلها.
ما هو المتصفح بالضبط؟
المتصفح هو برنامج يتكون من عدة أجزاء رئيسية:
محرك التقديم (Rendering Engine): مثل Blink في Chrome أو Gecko في Firefox، وهو المسؤول عن تحليل HTML وCSS وعرض الصفحة.
محرك JavaScript: مثل V8 في Chrome، وهو الذي ينفذ أكواد JavaScript.
مدير الشبكة: مسؤول عن تحميل الموارد من الإنترنت باستخدام HTTP/HTTPS.
واجهة المستخدم: الأزرار، شريط العناوين، الإعدادات... إلخ.
هل لديك نقطة معينة تريد التعمق فيها أكثر؟
Forwarded from InfoTechnology (IT4_2024)
المتصفح يستخدم محرك عرض (Rendering Engine) ومحرك JavaScript لمعالجة الصفحات. دعني أوضح كيف يعمل كل شيء:
1. كيف يتحمل المتصفح HTML و CSS ويترجمها؟
المتصفح لا "يفهم" HTML وCSS مباشرة، لكنه يستخدم محرك العرض (Rendering Engine) لتحليلها وتحويلها إلى شيء يمكن عرضه على الشاشة.
محرك العرض (Rendering Engine) هو المسؤول عن تحليل HTML وCSS وتحويلهما إلى واجهة رسومية.
كل متصفح يستخدم محرك عرض مختلف، مثل:
Blink في Chrome وEdge
Gecko في Firefox
WebKit في Safari
العمليات الأساسية لمحرك العرض:
Parsing (التحليل):
عندما يستلم المتصفح صفحة HTML، يقوم بتحليلها لإنشاء شجرة DOM (Document Object Model)، وهي تمثيل برمجي للصفحة.
نفس الشيء يحدث مع CSS، حيث يتم بناء CSSOM (CSS Object Model).
Building the Render Tree (بناء شجرة العرض):
يتم دمج DOM وCSSOM لإنشاء شجرة العرض (Render Tree)، وهي ما يحدد كيف ستظهر الصفحة للمستخدم.
Layout (التخطيط):
يتم حساب أماكن العناصر وأحجامها بناءً على القواعد الموجودة في CSS.
Painting (الرسم):
يتم رسم العناصر على الشاشة، وتحويلها إلى بيكسلات يتم عرضها باستخدام المعالج الرسومي (GPU).
2. كيف ينفذ المتصفح JavaScript؟
JavaScript ليست لغة يتم تحليلها مثل HTML وCSS، بل يتم تنفيذها بواسطة محرك JavaScript، وهو بيئة تشغيل مدمجة داخل المتصفح.
كل متصفح يستخدم محرك JavaScript مختلف، مثل:
V8 في Chrome وEdge
SpiderMonkey في Firefox
JavaScriptCore في Safari
العمليات الأساسية لمحرك JavaScript:
Parsing (التحليل):
يتم تحليل كود JavaScript إلى كود وسيط يسمى AST (Abstract Syntax Tree).
Compilation (الترجمة إلى لغة الآلة):
JavaScript ليست لغة يتم ترجمتها مسبقًا مثل C++، بل يتم تحويلها أثناء التشغيل إلى كود يمكن للمعالج فهمه عبر تقنية تسمى JIT (Just-In-Time Compilation).
Execution (التنفيذ):
يتم تنفيذ الكود على المعالج، مما يسمح بحدوث تفاعلات مثل الضغط على الأزرار أو تحميل البيانات من الإنترنت.
3. ما هي التقنية التي تجعل المتصفح يعمل؟
المتصفح نفسه مكتوب بلغات مثل C++ وRust (مثل Firefox)، ويستخدم العديد من الأدوات والتقنيات مثل:
محرك العرض (Rendering Engine): مثل Blink أو Gecko، لتحليل HTML وCSS.
محرك JavaScript (JavaScript Engine): مثل V8 أو SpiderMonkey، لتنفيذ JavaScript.
مدير الشبكة (Networking Layer): لتحميل الصفحات عبر HTTP/HTTPS.
نظام التخزين المؤقت (Cache System): لتخزين الموارد وتسريع التصفح.
GPU Acceleration: لتسريع عرض الرسومات وتحسين الأداء.
باختصار:
المتصفح يعمل عبر دمج عدة تقنيات معًا:
HTML/CSS يتم معالجتهما بواسطة محرك العرض (Rendering Engine) مثل Blink أو Gecko.
JavaScript يتم تنفيذه بواسطة محرك JavaScript مثل V8 أو SpiderMonkey.
المتصفح يستخدم تقنيات مثل JIT وGPU لتسريع الأداء.
هل لديك نقطة معينة تحتاج شرحًا أعمق؟
1. كيف يتحمل المتصفح HTML و CSS ويترجمها؟
المتصفح لا "يفهم" HTML وCSS مباشرة، لكنه يستخدم محرك العرض (Rendering Engine) لتحليلها وتحويلها إلى شيء يمكن عرضه على الشاشة.
محرك العرض (Rendering Engine) هو المسؤول عن تحليل HTML وCSS وتحويلهما إلى واجهة رسومية.
كل متصفح يستخدم محرك عرض مختلف، مثل:
Blink في Chrome وEdge
Gecko في Firefox
WebKit في Safari
العمليات الأساسية لمحرك العرض:
Parsing (التحليل):
عندما يستلم المتصفح صفحة HTML، يقوم بتحليلها لإنشاء شجرة DOM (Document Object Model)، وهي تمثيل برمجي للصفحة.
نفس الشيء يحدث مع CSS، حيث يتم بناء CSSOM (CSS Object Model).
Building the Render Tree (بناء شجرة العرض):
يتم دمج DOM وCSSOM لإنشاء شجرة العرض (Render Tree)، وهي ما يحدد كيف ستظهر الصفحة للمستخدم.
Layout (التخطيط):
يتم حساب أماكن العناصر وأحجامها بناءً على القواعد الموجودة في CSS.
Painting (الرسم):
يتم رسم العناصر على الشاشة، وتحويلها إلى بيكسلات يتم عرضها باستخدام المعالج الرسومي (GPU).
2. كيف ينفذ المتصفح JavaScript؟
JavaScript ليست لغة يتم تحليلها مثل HTML وCSS، بل يتم تنفيذها بواسطة محرك JavaScript، وهو بيئة تشغيل مدمجة داخل المتصفح.
كل متصفح يستخدم محرك JavaScript مختلف، مثل:
V8 في Chrome وEdge
SpiderMonkey في Firefox
JavaScriptCore في Safari
العمليات الأساسية لمحرك JavaScript:
Parsing (التحليل):
يتم تحليل كود JavaScript إلى كود وسيط يسمى AST (Abstract Syntax Tree).
Compilation (الترجمة إلى لغة الآلة):
JavaScript ليست لغة يتم ترجمتها مسبقًا مثل C++، بل يتم تحويلها أثناء التشغيل إلى كود يمكن للمعالج فهمه عبر تقنية تسمى JIT (Just-In-Time Compilation).
Execution (التنفيذ):
يتم تنفيذ الكود على المعالج، مما يسمح بحدوث تفاعلات مثل الضغط على الأزرار أو تحميل البيانات من الإنترنت.
3. ما هي التقنية التي تجعل المتصفح يعمل؟
المتصفح نفسه مكتوب بلغات مثل C++ وRust (مثل Firefox)، ويستخدم العديد من الأدوات والتقنيات مثل:
محرك العرض (Rendering Engine): مثل Blink أو Gecko، لتحليل HTML وCSS.
محرك JavaScript (JavaScript Engine): مثل V8 أو SpiderMonkey، لتنفيذ JavaScript.
مدير الشبكة (Networking Layer): لتحميل الصفحات عبر HTTP/HTTPS.
نظام التخزين المؤقت (Cache System): لتخزين الموارد وتسريع التصفح.
GPU Acceleration: لتسريع عرض الرسومات وتحسين الأداء.
باختصار:
المتصفح يعمل عبر دمج عدة تقنيات معًا:
HTML/CSS يتم معالجتهما بواسطة محرك العرض (Rendering Engine) مثل Blink أو Gecko.
JavaScript يتم تنفيذه بواسطة محرك JavaScript مثل V8 أو SpiderMonkey.
المتصفح يستخدم تقنيات مثل JIT وGPU لتسريع الأداء.
هل لديك نقطة معينة تحتاج شرحًا أعمق؟
👍1