المتصفح مثل 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.

واجهة المستخدم: الأزرار، شريط العناوين، الإعدادات... إلخ.

هل لديك نقطة معينة تريد التعمق فيها أكثر؟

المتصفح يستخدم محرك عرض (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 لتسريع الأداء.

هل لديك نقطة معينة تحتاج شرحًا أعمق؟

اللي تتكلم عنه هو التطور الكبير في تطبيقات الويب الحديثة، وانتقالها من مجرد صفحات HTML ثابتة إلى تطبيقات تفاعلية متقدمة تعتمد على تقنيات مثل DOM الافتراضي، WebAssembly، وSPA (Single Page Applications). خليني أفصل لك الموضوع أكثر.

١. كيف تعمل React وVue وAngular مع DOM؟

تقنيات مثل React وAngular وVue غيرت طريقة التعامل مع DOM التقليدي، حيث أصبحت تعتمد على DOM الافتراضي (Virtual DOM) أو Shadow DOM، وهذا يفسر ليش لما تفحص الكود في DevTools ما تلاقي نفس التاجات الأصلية المكتوبة في HTML.

🔹 ماذا يعني DOM الافتراضي؟

المتصفحات تقرأ شجرة DOM العادية وتعيد رسمها عند أي تغيير، وهذا مكلف من ناحية الأداء.

React مثلًا، يستخدم Virtual DOM وهو نسخة وهمية من DOM تُحفظ في الذاكرة، ويتم تحديثها بدون الحاجة إلى إعادة تحميل DOM الحقيقي في كل مرة.

عندما يحدث تغيير، يقوم React بمقارنة DOM الافتراضي مع الحقيقي (Diffing Algorithm) ثم يقوم فقط بتحديث الأجزاء المتغيرة، مما يحسن الأداء.

🔹 التاغات المخصصة (Custom Built-in Elements)

في Angular وVue، يتم تعريف تاغات خاصة مثل <app-component> أو <my-button> وهي ليست جزءًا من HTML الأصلي، بل يتم تفسيرها عبر محركات هذه الفريموركات وتحويلها داخليًا إلى عناصر HTML وJS فعلية داخل DOM.

هذه التاغات يتم معالجتها باستخدام Web Components أو Shadow DOM بحيث تصبح جزءًا من النظام الأساسي للمستعرض.

٢. ماذا أضافت WebAssembly وBlazor؟

🔹 ما هي WebAssembly؟

WebAssembly (WASM) هي تقنية تسمح بتشغيل لغات أخرى غير JavaScript داخل المتصفح مثل C، C++، Rust، وC# بسرعة قريبة من الأداء الأصلي (Native Performance).

WebAssembly هو في الأساس Bytecode يتم تشغيله مباشرة بواسطة المتصفح بدون الحاجة إلى مفسر JavaScript، مما يجعله أسرع بكثير.

🔹 كيف تعمل Blazor مع WebAssembly؟

Blazor هو إطار عمل من Microsoft يتيح تشغيل C# داخل المتصفح باستخدام WebAssembly، مما يسمح بتطوير تطبيقات ويب بدون الحاجة إلى JavaScript.

عند استخدام Blazor WebAssembly، يتم تحميل بيئة تشغيل .NET داخل المتصفح، ثم يتم تنفيذ كود C# محليًا، والتفاعل مع DOM مباشرة.

الفرق هنا أن بدل ما يعمل المتصفح Compile لكود JavaScript، يتم تشغيل كود C# كما هو عبر WebAssembly، مما يعطي أداءً عاليًا.

٣. لماذا يعتبر WebAssembly مستقبل الويب؟

🚀 أداء عالٍ: لأنه يعمل مباشرة فوق المعالج بدون تفسير إضافي.

🔥 دعم لغات متعددة: يمكن تشغيل C++، Rust، C# داخل المتصفح بدون JavaScript.

💡 تقليل استهلاك الموارد: لأنه يستخدم الـ Bytecode وليس النصوص البرمجية العادية، مما يحسن السرعة.

🛠️ تشغيل تطبيقات متقدمة: مثل الألعاب، برامج التصميم، الذكاء الاصطناعي داخل المتصفح بدون الحاجة إلى تنصيب برامج إضافية.

٤. مقارنة بين WebAssembly وJavaScript Frameworks

٥. كيف ستتغير تطبيقات الويب في المستقبل؟

أداء أعلى: لأن المتصفحات أصبحت تدعم WebAssembly بقوة.

أقل اعتمادًا على JavaScript: قد نرى تطبيقات مكتوبة بـ Rust أو C# تعمل بدون JavaScript.

انتشار WebAssembly في التطبيقات المعقدة: مثل برامج الفوتوشوب أونلاين، الذكاء الاصطناعي في المتصفح، وبرامج المونتاج داخل الويب.

تكامل أفضل بين الويب والتطبيقات المكتبية: لأن WebAssembly يجعل المتصفح بيئة تشغيل قوية.

الخلاصة

تقنيات مثل React وVue وAngular تستخدم DOM الافتراضي لتحسين الأداء.

WebAssembly قدم نقلة نوعية تسمح للمتصفح بتشغيل لغات مثل C++ وC# وRust بأداء قريب من Native.

Blazor WebAssembly يسمح بتشغيل تطبيقات C# داخل المتصفح بدون JavaScript.

WebAssembly سيكون المستقبل لتطبيقات الويب الثقيلة مثل الألعاب، الذكاء الاصطناعي، التطبيقات المعقدة.

هل عندك أي جزء تحب أتعمق فيه أكثر؟

⚡ عندما يصبح الوقت عاملاً حاسمًا، أي تقنية تختار؟

في عالم مليء بالتحديثات الفورية، الاختيار بين Node.js مع WebSockets و SignalR في .NET ليس مجرد قرار تقني، بل استراتيجية تحدد سرعة استجابتك للعالم.
🕹 Node.js + WebSockets
إذا كنت تبحث عن أداء بلا قيود، فإن Non-Blocking I/O في Node.js يمنحك السرعة التي تحتاجها. مع Socket.IO و Redis Pub/Sub، يمكنك التعامل مع ملايين الاتصالات المتزامنة، لكنك تتحمل مسؤولية إدارة الأمان والبنية التحتية بنفسك.
🔗 SignalR في .NET
أما إذا كنت تريد تكاملاً سلسًا مع ASP.NET Core، فإن SignalR يتولى عنك عبء الاختيار بين WebSockets و SSE و Long Polling. يتيح لك التركيز على منطق التطبيق، بينما يوفر Azure SignalR التوسع بسهولة وأمان أعلى.
🎯 النتيجة؟
🔹 تبحث عن تحكم وأقصى أداء؟ اذهب مع Node.js + WebSockets.
🔹 تريد حلاً متكاملاً وسهل التوسع داخل .NET؟ SignalR هو الخيار المثالي.
المعادلة بسيطة: ليس المهم فقط ما تختار، بل كيف تستخدمه. 🚀

للعلم 👇
SignalR هي مكتبة في .NET تُضاف كـ Layer فوق بروتوكولات الاتصال الفعلي مثل WebSocket، مما يتيح لك إنشاء تطبيقات تعتمد على التحديثات في الوقت الفعلي. بمعنى آخر، SignalR لا تُمثل بروتوكول الاتصال نفسه، بل هي الأداة التي تستخدمها لتمكين هذا الاتصال.

المشكلة في .NET هي أن SignalR تعتمد على الـ Runtime الخاص بـ .NET، مما يؤدي إلى تأخير إضافي في الأداء، مقارنة بـ Node.js. الـ Runtime في .NET يُضيف طبقات إضافية من المعالجة، وهو ما قد يؤدي إلى زيادة استهلاك الموارد وتأخير في الاستجابة عند التعامل مع العديد من الاتصالات في الوقت الفعلي.

أما في Node.js، فإن التعامل مع WebSockets مباشرة يعني أنك تتجنب هذه الطبقات الإضافية، مما يساهم في أداء أسرع و استهلاك أقل للموارد، خاصة في التطبيقات التي تتطلب إدارة عدد كبير من الاتصالات المتزامنة.

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

معلومة جديدة


"في عالم اليوم، أصبح الذكاء الاصطناعي (AI) حديث الجميع ويشكل ترندًا قويًا، ولكن بالتزامن مع ذلك، أين نحن من تقنيات Web3 والبلوكشين التي لم تكن في الصدارة؟
بينما يغير الذكاء الاصطناعي طريقة تفاعلنا مع التكنولوجيا، يظل Web3 والبلوكشين حجر الأساس للشفافية والأمان واللامركزية. فبدلًا من أن يكون أحدهما بديلًا للآخر، يمكن أن يشكلا معًا مستقبلًا أكثر قوة:
🔹 الذكاء الاصطناعي يحلل البيانات ويخلق حلولًا ذكية.
🔹 البلوكشين يضمن الأمان والثقة واللامركزية.
💡 التكامل بينهما قد يكون المفتاح لإنترنت أكثر تطورًا وموثوقية! فهل نرى قريبًا عودة قوية لـ Web3 بجانب ثورة AI؟ 🤔

On this day, we can say that we have completed our third year! 🎉🎓

#حكم_برمجية

-1- انا احارب في issue انت لا تعلم عنها شيء - تقولها لمديرك لما يسألك انت بتعمل ايش

2- كلنا فريق واحد حتى تأتي production issue

3- عندما يتعلق الأمر ب Deadline فلا تحدثني عن clean code

-4 اعطني مبرمج عنده ولاء للشركة و PM 3 sleeping bag بلا بيت وانا meet the deadline

-5- إذا سألوك عن ميعاد التسليم فقل لهم مات ابن خال التيم ليدر

-6- فيا له من كود لو أن له architect

-7- ولكن المبرمجين لا يقرأون ال log واذا قرأوا لا يفهمون واذا فهموا لا يعملون reproduce the issue

8-لا تعطنى الكود ولكن اعطني stack overflow thread

و ارتق فأن الكود قد امتلأ special cases

10- ولولا اختلاف الاراء لكنا خلصنا Sprint هذه

11- ولا estimation plan الأعداء ال agile - تقولها لمدير المشروع لما يسألك عن الخطة .

12- كان يمكنني حل كل issues ولكني تركتهم لتعلموا كم أن النظام خربان ويحتاج refactor

-13- اللي معاه bug محيره يحط try و empty catch

14 - الحياة أقصر من أن نقضيها في عمل unit testing

-15 اعطني day work from home فربما لست بخير

-16 رفقا ب support فالعالم في production مخيف جدا

17- عندما يقول احدهم " احنا شغالين Agile " اتحسس مسدسي

هل سمعت من قبل عن مصطلح Polyglot؟ يشير هذا المصطلح إلى الشخص الذي يتقن أكثر من لغة طبيعية، مثل العربية والإنجليزية والفرنسية والألمانية. وقد تم استعارة هذه الفكرة في مجال البرمجيات، حيث ظهرت عدة مفاهيم حديثة، من أبرزها:
🔹 Polyglot Persistence: وتعني استخدام أكثر من تقنية أو نوع من قواعد البيانات داخل نفس التطبيق، مثل الجمع بين قواعد البيانات العلائقية (Relational) مثل MySQL، وقواعد البيانات غير العلائقية (NoSQL) مثل MongoDB.
🔹 Polyglot Architecture: وهي تعني تصميم النظام باستخدام أكثر من معمارية برمجية أو لغة برمجة داخل نفس المشروع. هذا المفهوم أصبح شائعًا مع ظهور الـ Microservices، حيث يمكن لكل خدمة أن تستخدم التقنية الأنسب لوظيفتها.

🚀 قوة Polyglot في البرمجة

تخيل أنك تطور تطبيقًا أساسيًا مكتوبًا بلغة Java، ولكنك بحاجة إلى جزء يتعامل مع Machine Learning، وهنا سيكون Python هو الخيار الأفضل. أو أنك تستخدم قاعدة بيانات MySQL، ولكن لديك جزء يتعامل مع Big Data، لذا قد تحتاج إلى Hadoop. هذه المرونة تتيح لك الاستفادة من أفضل التقنيات لكل جزء في مشروعك.

⚠️ تحذير مهم: لا تبالغ في التعقيد!

ليس كل ما يمكنك تنفيذه يجب عليك تنفيذه! في معظم الحالات، التمسك بتقنية أو اثنتين فقط (مثل Java + MySQL مثلًا) سيجنبك الكثير من الفوضى، ويقلل من التكاليف، ويسهّل العثور على كفاءات متاحة في السوق. كلما أضفت تقنيات جديدة، زاد تعقيد الهندسة المعمارية للتطبيق وارتفعت تكلفة الصيانة.
💡 الخلاصة: Polyglot هي أداة قوية إذا استخدمتها بذكاء، ولكن إن أسأت استخدامها، فستواجه مشاكل معقدة وتكاليف عالية! 🤯

رسالة إلى كلِّ مُعلِّمٍ يَحملُ مِصباحًا، وكلِّ طالبٍ يَحلُمُ بِسَماءٍ، وكلِّ مُؤسسةٍ تَزعُمُ أنها تَبني العُقولَ:


### 1. المعلِّم: حارِسُ البوابةِ بين الظلامِ والنور 
أيها الحاملونَ أمانةَ الكلمة.. 
لستم ناقِلينَ للمعرفةِ، بل أنتم حُرّاسُ البوابةِ بين عالَمَين: 
عالمِ الجهلِ الصامِتِ، وعالمِ المعرفةِ الثائرِ. 
كُلُّ كلمةٍ تَنطِقونَها هي إمَّا مِطرَقةٌ تَكسرُ قيودَ الوهمِ، 
أو سِلسلةٌ تُقيّدُ بها العقولَ إلى أبدِ الآبدين. 
فَـ 
احذروا أن تَخونوا الأمانةَ.. 
فالطالبُ الذي تُطفِئونَ شعلَتَهُ اليومَ، 
قد يكونُ الأخيرَ الذي يَجرؤُ على سؤالٍ يُغيِرُ مصيرَ أُمّةٍ! 🔥🗝️ 


### 2. المحاضرةُ الجيّدةُ: ليست درسًا.. بل وَليمةٌ للعقلِ! 
المحاضرةُ التي تُلهِمُ ليست نقلًا لِما في الكُتبِ، 
بل هي رَقصةٌ بينَ السؤالِ والجوابِ، 
حيثُ يَخرجُ الطالبُ وَكأنَّما شَرِبَ مِن نَهْرِ الفِكرِ، 
فيَرى في كُلِّ كتابٍ مَرآةً تُعيدُ صياغةَ أَسئلتِهِ، 
لا سِجنًا يُدَوِّنُ فيهِ إجاباتِ الآخرين! 
هكذا تَصنَعُ المُحاضرةُ الجيّدةُ جيلًا يَقرأُ الوَحيَ بَينَ السُّطورِ، 
ويَكتشفُ أنَّ الحقيقةَ ليست جَبَلًا ثابتًا، 
بل بَحرًا يَتَحرَّكُ كُلَّما أَبحَرْتَ فيهِ. 🌊📖 


### 3. المحاضرةُ السيّئةُ: ليست خطأً.. بل جريمةٌ ضدَّ الإنسانيةِ! 
أما المُحاضرةُ التي تَقتلُ الشغفَ، 
فهي ليست مُجرَّدَ "ضعفٍ أكاديميٍّ"، 
بل جريمةٌ تُرتَكبُ في وضحِ النهارِ.. 
جريمةٌ تَسرقُ مِن الطالبِ حَقَّهُ في أن يَتَعَجَّبَ، 
وتَحشو رأسَهُ بِ"حقائقَ" جافَّةٍ كَأحجارِ المَقابِرِ! 
حتَّى إذا ما وَجهَتهُ سؤالًا: "ما الهدفُ مِن هذا العِلمِ؟"، 
أجابَكَ بِصوتٍ مَيتٍ: "لأجتازَ الامتحانَ فَقَط!". 
هكذا تُنتِجُ المُحاضراتُ السيّئةُ أُمَّةً مِن الظِّلالِ، 
تَسيرُ خلفَ شَموعٍ أُطفِئَت قَبلَ أن تُولَدَ! 🕯️⚰️ 



### 4. الجامعاتُ: أينَ الحقيقةُ وراءَ القُبَّعاتِ والجِدارَاتِ؟ 
أيتها القلاعُ العاجيّةُ.. 
متى تَفيقينَ مِن سُباتِكِ؟ 
لقد صِرْتِ سُوقًا تَبتاعينَ الكرامةَ بِشهاداتٍ مَزورةٍ، 
وتَبيعينَ الوهمَ بِاسمِ "التعليمِ العالي"! 
أينَ أنتِ مِن جامعاتِ العالم، 
حيثُ  الأستاذُ والطالبُ شَريكينِ في مُغامرةِ الفِكرِ، 
يَحفرانِ معًا في أرضِ المُجهولِ، 
لا يَخشيانِ مِن سُقوطِ الجدرانِ القديمةِ؟ 
إنَّ الجامعةَ التي لا تَزرعُ في طلابِها جُرأةَ الاعتراضِ، 
هي مُجرَّدُ مَصنعٍ لِلقُوَّاتِ العاملةِ، 
لا مَشعَلٍ لِلثوراتِ الفِكريّةِ! 🏛️💥 


### 5. الطالبُ: لا تَكُنْ وَقودًا لِآلةٍ قَديمةٍ! 
يا مَن تَحملُ قلَبًا يَنبضُ بِالأسئلةِ.. 
لا تَسمحْ لأحدٍ أن يُحوِّلَكَ إلى بَندولٍ يَترنَّحُ بَينَ المُحاضراتِ والامتحاناتِ! 
اِقرَأْ كَأنَّما الكِتابُ مِفتاحٌ لِغُرفةٍ مَجهولةٍ في رُوحِكَ، 
اِسألْ كَأنَّما السؤالُ سَيفٌ يَقطَعُ أَسلاكَ الخوفِ، 
وَاعلَمْ أنَّ الخيانةَ العُظمى هي أن تَخونَ فِكرَكَ لِتُرضيَ مُعلِّمًا عاجِزًا! 
فَـ 
مَتى ما وَضعتَ ثقتَكَ في عَقلِكَ، 
ستَرى أنَّ التَعليمَ الحقيقيَّ يَبدأُ حَيثُ تَنتهي الكُتبُ! 🗝️🦅 

### 6. إلى صُنَّاعِ السِّياساتِ التَعليميّةِ: كفى تَشويهًا لِأرواحِ الأجيالِ! 
يا مَن تَجلِسونَ في مَكاتِبَكُم الفَخمةِ.. 
أتَدرونَ أنَّ كُلَّ "توجيهٍ" تَصدرونَهُ بِلا رُوحٍ، 
هو قَيدٌ يُضافُ إلى أقدامِ مُستقبَلٍ بِلا أجنحةٍ؟! 
لَيسَ المَطلوبُ مَناهجَ أَضخمَ، 
بل مُعلِّمينَ أَشجعَ.. 
لَيسَ المَطلوبُ مَدارسَ أَحدثَ، 
بل فصولًا تَتَنفَّسُ حُرّيةَ السؤالِ! 
فَـ 
اتركوا العُقولَ تَنمو كَالأشجارِ، 
لا تَقُصُّوها كَالأسيجةِ لِتُناسبَ أهواءَكُم! 🌳🔨 


### 7. الخاتمةُ: هُناكَ أملٌ.. لكن! 
رُغمَ الظلامِ.. 
ما زالَ هُناكَ مَن يُضيءونَ شُمُوعَهُم في قُلوبِ التلاميذِ، 
وما زالَ هُناكَ طلابٌ يَرفضونَ أن تَكونَ كِتاباتُهُم نُسخًا مُكرَّرةً! 
فَلْنَكُنْ جُزءًا مِن هَذا الأملِ.. 
لِنُعلِّمَ أطفالَنا أنَّ الحقيقةَ وَطنٌ لا يُحتَلُّ، 
وأنَّ السؤالَ حَقٌّ لا يُساومُ عَلَيهِ، 
وأنَّ الكِتابَ لَيسَ نِهايةَ الطَّريقِ.. 
بَلْ بَدَايَةُ مَعرَكَةٍ مَعَ الذاتِ وَالجَهلِ وَالخَوْفِ! ⚔️📚 


#التعليم_ليس_سوقًا_بل_معبدًا 🕊️ 
#أوقفوا_اغتيال_الفضول ⚠️✊

#صنعاء
#وظائف_شاغرة عديدة

1- مندوب تسويق ميداني
2- Full Stack (Laravel) Developer
3- Android (Flutter) Developer


قدم الآن عبر هذا الرابط :
https://forms.gle/MqxCbVXHcQfS5rfX8

________
لمزيد من فرص الوظائف نوصي بمتابعتنا على صفحتنا في فيسبوك أو الانضمام إلى قناة الواتساب الخاصة بنا عبر الروابط التالية:

صفحة الفيسبوك:
[https://fb.shagher.net ]
قناة الواتساب:
[https://wa.shagher.net ]
قناة التليجرام:
[ https://news.1rj.ru/str/Shagher_net ]

تجربتي في التعامل مع عدد كبير من السجلات (حوالي 2 مليون سجل)
من أهم مميزات LINQ في التعامل مع أي مصدر بيانات هو أنه يعتمد على السحب التدريجي للبيانات (Pulling)، على عكس الحلقات التقليدية مثل for loop التي تقوم بتحميل البيانات دفعة واحدة في الذاكرة قبل بدء المعالجة.
في معظم الأحيان، يتم استخدام ToList أو ToListAsync لجلب البيانات، ولكن المشكلة هنا أنه حتى مع ToListAsync، يتم تحميل جميع البيانات في الذاكرة أولًا، ثم تنفيذ العمليات عليها. وهذا يعني أننا لم نستفد بشكل كافٍ من ميزة السحب التدريجي للبيانات.

الحل: استخدام AsAsyncEnumerable

عند الحاجة إلى كتابة البيانات في ملف Excel أو CSV، يمكننا الاستفادة بشكل أكبر من LINQ باستخدام AsAsyncEnumerable، حيث تتيح هذه الطريقة تدفق البيانات مباشرةً بمجرد أن تصبح جاهزة، دون الحاجة إلى انتظار تحميل جميع السجلات في الذاكرة دفعة واحدة.
الفوائد:

تقليل استهلاك الذاكرة: عند استخدام ToList، قد يتم استهلاك مئات الميجابايت من الذاكرة، بينما مع AsAsyncEnumerable، يتم استهلاك جزء بسيط منها فقط. في إحدى تجاربي، انخفض استهلاك الذاكرة من 460 ميجابايت إلى حوالي 10.5 ميجابايت.

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

مقارنة بين الطريقتين

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

لو متعرفش 🙄 🤷‍♂️

تقدر تحميل DeepSeek علي الهاتف الخاص بك وتشتغل عليه بدون الابلكيشن حتي مع التفكير العميق R1 الطريقه كالأتي:

1- تحميل تطبيق [Termux] يفضل يكون من github النسخه [v0.118.1] واختار حسب المعالج الخاص بجهازك

2- بعد تثبيت التطيبق يفضل ان ترسل الأمرين التاليين :
termux-setup-storage تفعيل صلاحية الوصول الي الملفات
pkg upgrade تحديث الحزم
3 - pkg install git cmake golang
4- git clone --depth 1 https://github.com/ollama/ollama.git
5- cd ollama
6- go build .
7- ./ollama run deepseek-r1:1.5b --verbose

بس كده هيشتغل معاك مدي الحياه من غير ميجبلك "الخادم به مشكله يرجي الانتظار" 😋

ملحوظه : حجم الموديل 1.2GB حول توفر الحجم ده من الانترنت شكراً للجميع
GOod LuCk 👍

متى يكون المونوليثيك أركيتكتشر هو الاختيار الصحيح؟

في السنوات الأخيرة، أصبحت الميكروسيرفيسز (Microservices) وكأنها الحل السحري لكل المشكلات، وأي نظام لا يزال يعتمد على المونوليثيك (Monolithic Architecture) يُعتبر "قديمًا" أو "غير مواكب للتطور". ولكن هل هذا الاعتقاد صحيح؟

في الحقيقة، هذا طرح سطحي جدًا، فالمسألة أعقد بكثير. لو كان المونوليث خيارًا كارثيًا كما يُروّج البعض، لماذا إذن بدأت أنظمة عملاقة مثل Amazon, eBay, LinkedIn كمونوليث؟ بل ولماذا عادت بعض الشركات الكبرى لاحقًا إلى Modular Monolith بدلاً من الميكروسيرفيسز؟

ما هو المونوليثيك أركيتكتشر؟

المونوليث هو نظام متكامل يتم تشغيله كتطبيق واحد (Single Codebase & Single Process) مع قاعدة بيانات واحدة. أي أن جميع الميزات (Features) مترابطة داخل نفس التطبيق، وأي تعديل على جزء معين قد يؤثر على باقي النظام، مما يعني أنه في كثير من الحالات، ستحتاج إلى إعادة نشر (Redeploy) التطبيق بالكامل عند إجراء أي تغيير.

قد يبدو ذلك عيبًا كبيرًا، لكن هل هذا صحيح في كل الحالات؟ 🤔 دعنا نناقش الأمر بموضوعية.

متى يكون المونوليث هو الاختيار الأفضل؟

على عكس ما يعتقده البعض، المونوليث لا يزال خيارًا ممتازًا في العديد من الحالات، ومنها:

1. عند بدء مشروع جديد (MVP أو Startup)

عندما تطلق منتجًا جديدًا، يكون الهدف الأساسي هو الوصول إلى السوق بأسرع وقت ممكن، وليس تحقيق أحلام معمارية معقدة.
المونوليث يوفر سرعة في التطوير لأنه لا يتطلب تعقيدات مثل Networking, API Gateway, Service Discovery التي تفرضها الميكروسيرفيسز.

2. عندما يكون لديك متطلبات صارمة للاتساق (Strong Consistency)

إذا كان النظام يحتاج إلى اتساق قوي للبيانات (Data Consistency)، فالمونوليث يوفر تحكمًا مباشرًا في المعاملات (Transactions) دون الحاجة إلى حلول معقدة مثل Distributed Transactions, Eventual Consistency, Saga Patterns.
التعامل مع ACID Transactions في قاعدة بيانات واحدة أسهل بكثير من إدارة بيانات موزعة عبر عدة خدمات.

3. عندما يكون الفريق صغيرًا أو يفتقر للخبرة في Microservices

الميكروسيرفيسز ليست مجرد تقسيم للكود، بل نظام هندسي متكامل يتطلب فريقًا متمرسًا في:

DevOps & Observability Service Orchestration & API Management Security & Distributed Systems

العديد من الشركات قفزت إلى الميكروسيرفيسز دون خبرة كافية، فزادت التكاليف وتعقد التشغيل، وانتهى بها الأمر بمشكلات أكثر من الحلول!

4. عندما تكون الميزانية محدودة

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

خلاصة القول المونوليث ليس شرًا مطلقًا، والميكروسيرفيسز ليست الحل السحري. الاختيار بينهما يجب أن يعتمد على احتياجات المشروع، وخبرة الفريق، وليس مجرد اتباع الترند. أفضل نهج عملي؟ ابدأ بـ Modular Monolith، وعندما يحتاج النظام إلى التوسع، سيكون الانتقال إلى Microservices أكثر سهولة وتنظيمًا. ما القادم؟

في المقال القادم، سنتحدث عن كيفية جعل المونوليث مرنًا ومستعدًا للتوسع دون أن يتحول إلى كابوس هندسي!

أيها السادة الكرام 😅 ال platforms كلها ساحت علي بعض
فلاتر بتعمل ويب و php بتعمل موبايل و عجبي

اللي محتاج اوصله لاي عضو هيئة تدريس في مجال البرمجيات علي اختلافها.
حيث انك بقالك سنين طوية مش قادر تطور منهج عليه القيمة فحاليا تقدر فعلا تساعد الطلبة بتوعك بشكل فعال.
قلل ال Assignments بتاعتهم علي المنهج بتاعك شوية و اديهم فرصة يتعلموا كويس من مصادر عليها القيمة و يتعلموا مواد و مواضيع عليها القيمة و معاهم ChatGPT o3 and DeepSeek R1.
هتبقي فعلا خدمتهم و خدمت الصناعة فعلا لانهم هيتخرجوا افضل كمهندسين.
و الكلام دا جد. انا مش قاصد اضايقك انا فعلا مقتنع ان مفيش عندك اكتر من كده.
بس كونك قليل الحيلة يجب الا يعوق الطلبة و تفضل شاغلهم في مهام هدفها انك تبقي بتفرمهم و خلاص.ال يعني تعليم شديد بقي.
سيبهم يتعلموا. مش معقول يبقي لا عارف تتعلم و لا تعلمهم و لا تسيبهم يتعلموا.
فكر. هتلاقيه حل كويس.

#شير_ياسطى

Css