لمحة 👀 برمجية

"ماذا لو أخبرتك أن ولاءك الأعمى لـتقنية واحدة يخنق مشاريعك ببطء؟ 🔥 (مُترجم من دماغ مطور خسر 3 مشاريع قبل أن يفهم الدرس) 1. مصيبة الـ"سوّي بيها كل حاجة" 🙄 تخيل أنك تريد قطع شجرة: الفأس → مثالي. ملعقة → ممكن... لكنك ستتكسر قبل الشجرة! ⇢ .NET للمؤسسات، Python للذكاء الاصطناعي، JavaScript للواجهات... الضربة القاضية: استخدام غير المناسب يضيع الوقت والمال، ويُنتج أنظمة "مُرقّعة". 2. هل تقتل إبداعك وأنت لا تدري؟ 💀 التكنولوجيا تتطور بسرعة البرق، لكنك: تُحاصر نفسك بـ"أدوات الماضي". ترفض استكشاف حلول أحدث (مثل Rust للأنظمة، Go للتوزيعات). ⇢ العالم لا يكافئ من يعيش في "منطقة الراحة التقنية"، بل من يسبق بــمرونة التفكير. 3. مأساة الـ"أنا ومين؟ فريق التقنية الواحدة!" ماذا يحدث لو: قرر فريقك المغادرة؟ ظهرت تقنية جديدة تهدد وجود ما تعتمد عليه؟ ⇢ التبعية الكلية = انهيار النظام بأكمله عند أول أزمة. 4. "المُبرمج القاتل" vs "مهندس الحلول" الأول: يكتب كودًا بـ"أي ثمن". يُدافع عن تقنيته حتى لو دمرت المشروع. الثاني: يحلل المشكلة كـجراح، يختار الأدوات كـمهندس دقيق. يدمج التقنيات كـفنان لصنع نظام متناغم. ⇢ أي شخصية تريد أن تكون؟ الخلطة السرية: لا تكن عبدًا لـ Stack: اختَر التقنية كـوسيلة، لا كـ"هوية". تعلّم المبادئ، لا الأدوات: SOLID، Design Patterns... هذه أسلحتك الخالدة. جرّب شيئًا غريبًا كل شهر: لغة جديدة، framework مختلف... دماغك يحتاج "صدمات إبداعية". الـ"مُبرمج الحقيقي" لا يُقاس بعدد السنين في تقنية، بل بقدرته على اختراق المشكلات بأي أداة تطلبها اللحظة. 🧠 — تحدي: في مشروعك القادم، اختر تقنية لم تستخدمها من قبل ولو لـ20% من الكود. هل ستتقبّل المغامرة؟ 🚀"

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

اصحووووو

إلى السادة الأفاضل في الكادر التدريسي والإداري لكلية الحاسوب – جامعة صنعاء، السلام عليكم ورحمة الله وبركاته، نحن طلاب المستوى الثالث – تخصص علم الحاسوب، نكتب إليكم اليوم بدافع الأمل في أن يكون تعليمنا جسرًا نحو مستقبل أفضل، لا عبئًا يُكرِّس إحباطنا. نعلم أن الظروف الاستثنائية التي تمر بها بلادنا تفرض تحديات جسيمة، لكن هذا لا يعني أن نضيع سنواتنا الدراسية في موادٍ تكرر ما درسْناه سابقًا دون أي إضافة حقيقية. ### لماذا نرفض تكرار "علم الأحياء"؟ منذ الصف الأول الثانوي وحتى الثالث الثانوي، درسنا مادة علم الأحياء بتفاصيلها المعقدة (مثل تركيب الخلية، التكاثر، والوراثة)، ورغم اجتهادنا في حفظها، لم نستفد منها في حياتنا العملية أو حتى في تأهيلنا للجامعة. واليوم، نتفاجأ بأن هذه المادة نفسها تُفرَض علينا في تخصص علم الحاسوب! أليس من المفترض أن تكون المرحلة الجامعية مرحلة تخصصية تُعمِّق مهاراتنا في البرمجة، تحليل البيانات، وتصميم الأنظمة؟ فكيف لِمادةٍ نظريةٍ مثل علم الأحياء – تم تدريسها لنا لثلاث سنوات في المدرسة – أن تضيف لقدراتنا التقنية؟! ### السؤال الأهم: ما الهدف من هذا التكرار؟ لو كان الهدف توسيع آفاقنا المعرفية، فلماذا لا ندرس موادًا ذات صلة بالتكنولوجيا مثل: - الأخلاقيات الرقمية (Digital Ethics). - التعلم الآلي (Machine Learning). - تحليل البيانات الضخمة (Big Data Analysis). - التطبيقات الذكية في حل المشكلات المجتمعية. أما أن نُجبَر على دراسة علم الأحياء للمرة الرابعة (مرات ثلاث في الثانوية، ومرة في الجامعة)، فهذا يجعلنا نشعر أننا نُهدر الوقت في تكرار معلومات لن نستخدمها أبدًا في برمجة تطبيق، تطوير موقع إلكتروني، أو حتى تأمين شبكة حاسوب! ### تجربتنا مع المنهج: من الثانوية إلى الجامعة! في المرحلة الثانوية، كنا نحفظ مقرر الأحياء لاجتياز الامتحان، ثم ننسى كل شيء بعد تسليم الورقة. واليوم، نكرر نفس الحفظ في الجامعة، لكن النتيجة أسوأ: ففي آخر امتحان، حصل معظمنا على درجات متدنية (مثل 24/50) لأننا ببساطة لا نجد حافزًا لدراسة ما لا نؤمن بفائدته. هل يُعقل أن يُحكم على قدراتنا الأكاديمية بناءً على حفظ تفاصيل خلية لم نرها حتى تحت المجهر؟! ### مطالبنا: وقف التكرار، والتركيز على الجوهر! 1. إلغاء مقرر علم الأحياء من خطة تخصص علم الحاسوب، أو جعله مقررًا اختياريًّا لمن يرغب في التخصصات التي تجمع بين الحاسوب والأحياء (مثل Bioinformatics). 2. تعويض الحصص الأسبوعية بورش عمل تطبيقية في البرمجة، تطوير الويب، أو أمن المعلومات. 3. مراجعة شاملة للمناهج: بالتنسيق مع طلاب سابقين خاضوا تجربة سوق العمل، لمعرفة المهارات المطلوبة فعلًا. 4. توفير معامل حاسوب مُجهَّزة بدلًا من تحويل قاعاتنا إلى محاضرات نظرية في مواد غير ذات صلة. ### ختامًا: نحن لسنا ضد العلم، لكننا نريد تعليمًا يواكب أحلامنا! نحن نقدِّر كل الجهود المبذولة، لكننا نحمل همًّا أكبر: مستقبلٌ ينتظرنا بلا فرص عمل إذا لم نكتسب المهارات التقنية اللازمة. فبدلًا من إضاعة وقتنا في موادٍ مُكرَّرة، دَعونا نتعلم كيف نبني برامج تُساهم في حل أزمات وطننا، من انهيار اقتصادي إلى تعطيل خدمات أساسية. وتذكروا: أعظم هزيمة لأي جامعة هي أن يخرج طلابها وهم يشعرون أن سنوات الدراسة كانت مجرد "شهادة" بلا معنى. وتفضلوا بقبول فائق الاحترام، طلاب المستوى الثالث – تخصص علم الحاسوب جامعة صنعاء #شاركها_لتوصل

أكثر كلمه أزعجتنا في JavaScript : "Undifiend" 🥲🥲

🔸 عسكر: طيب النعيمي، خلينا نقول إننا مشينا على كل اللي قلته، وخلينا النظام Modular، واستخدمنا Events، وطبقنا الكاشينج، كيف نضمن إنه يظل سهل الصيانة ومش يتحول لكابوس مع الوقت؟ 🔹 النعيمي: سؤال مهم جدًا! علشان المونوليث يظل منظم وقابل للصيانة، لازم نعتمد على مبادئ الـ Clean Architecture. 🔸 عسكر: قصدك نفصل الـ Business Logic عن الـ Presentation Layer؟ 🔹 النعيمي: تمامًا! نخلي كل طبقة مستقلة وما تدخل في شغل الثانية مباشرة. يعني عندنا: 1️⃣ Domain Layer: تحتوي على القواعد والمنطق الأساسي للنظام. 2️⃣ Application Layer: تدير التدفقات (Use Cases) وتتعامل مع الـ Repositories. 3️⃣ Infrastructure Layer: تتعامل مع قواعد البيانات، الـ APIs، والـ Messaging. 4️⃣ Presentation Layer: وهي الـ UI والـ Controllers. 🔸 عسكر: كذا لو احتجنا نغير قاعدة البيانات أو نعدل في الـ UI ما راح نكسر كل شيء؟ 🔹 النعيمي: بالضبط! بالإضافة إلى الـ Dependency Injection، بحيث أي تغيير في الخدمات ما يحتاج تعديل في كل الكود. 🔸 عسكر: طيب، بس لو الفريق كبر، وكل واحد شغال على جزء معين، كيف نتأكد إنه محدش يخرب الشغل على الثاني؟ 🔹 النعيمي: هنا يجي دور CI/CD Pipelines! 🔸 عسكر: قصدك إننا نستخدم أدوات مثل GitHub Actions, Jenkins, أو GitLab CI/CD علشان نضمن إن الكود يتم اختباره تلقائيًا قبل ما يندمج؟ 🔹 النعيمي: تمام! كل كود جديد لازم يمر على اختبارات آلية (Unit Tests, Integration Tests) عشان نضمن إن النظام يظل ثابت وما تحصل مشاكل بسبب التعديلات الجديدة. 🔸 عسكر: أوكي، آخر شيء، لو قررنا إن النظام صار كبير جدًا، وقررنا إنه حان الوقت للتحول إلى Microservices، كيف نجعل الانتقال سلس؟ 🔹 النعيمي: لو كنا اتبعنا كل الخطوات السابقة، فالانتقال بيكون بسيط! ببساطة: ✅ أي وحدة داخل المونوليث يمكن فصلها بسهولة لأنها مستقلة في الـ Code و الـ Data. ✅ الـ Events جاهزة، فيمكننا تشغيل بعض الوحدات كـ Microservices تدريجيًا بدون مشاكل. ✅ الـ API Gateway ممكن يوجه بعض الطلبات للوحدات اللي تحولت إلى Microservices بدون ما نحسّن على المستخدم. 🔸 عسكر: يعني بدل ما نقفز مباشرة إلى Microservices ونغرق في التعقيد، نبدأ بمونوليث نظيف ومرتب، ولو احتجنا نتحول، يكون الموضوع سهل؟ 🔹 النعيمي: هذا هو التفكير الذكي! ابدأ صح، وخلي المستقبل مفتوح قدامك بدل ما تربط نفسك بتصميم غير مناسب. 🔸 عسكر: كلامك ذهب يا النعيمي! لازم نسوي جلسة ثانية عن كيفية تصميم Microservices بدون ما نقع في المشاكل الشائعة. 🔹 النعيمي: أكيد! بس خلينا نشرب قهوتنا أول، شكلنا دخلنا جو النقاش وما انتبهنا إننا خلصنا الدوام! ☕😂🔥

🚀لنكمل الرحلة كيف نجعل المونوليث مرن ومستعد للتوسع؟ (محادثة بين النعيمي وعسكر) 🔹 النعيمي: عسكر، تذكر لما تكلمنا عن المونوليث والمقارنة بينه وبين الـ Microservices؟ 🔸 عسكر: طبعًا، واتفقت معك إن المونوليث مش كارثة لو بنيته صح. بس كيف نضمن إنه يظل مرن وقابل للتوسع؟ 🤔 🔹 النعيمي: تمام، أول شيء لازم نقسمه بشكل Modular Monolith، يعني كل جزء من النظام يكون مستقل قدر الإمكان وما يعتمد على الأجزاء الثانية بشكل مباشر. 🔸 عسكر: قصدك نخلي كل Feature كأنه وحدة مستقلة داخل نفس الكود؟ 🔹 النعيمي: بالضبط! بحيث لو احتجنا مستقبلاً نفصل جزء معين إلى Microservice يكون الموضوع بسيط، وما نضطر نعيد بناء كل شيء من الصفر. 🔸 عسكر: طيب، بس دايمًا المشكلة مع المونوليث إنه كله مربوط بقاعدة بيانات واحدة ضخمة، ولو كبر المشروع تصير عندنا أزمة في الأداء! 🔹 النعيمي: الحل هنا إننا ما نعتمد على قاعدة بيانات مركزية بطريقة فوضوية. كل وحدة داخل المونوليث يكون لها نطاق بيانات خاص وما تدخل في نطاق غيرها مباشرة. ولو وحدة تحتاج بيانات من وحدة ثانية، نستخدم Events بدل الاستعلام المباشر. 🔸 عسكر: يعني بدل ما كل شيء يكون متصل ببعض، كل وحدة ترسل أحداث (Events)، مثل "تم إنشاء طلب جديد"، وباقي الوحدات تستجيب لها؟ 🔹 النعيمي: تمامًا! كذا نتجنب التعقيدات اللي تجي مع الاستعلامات المباشرة، ونخلي النظام أكثر مرونة وأقل ارتباطًا. 🔸 عسكر: طيب، والأداء؟ مع الوقت الاستعلامات على قاعدة البيانات بتزيد، وبيصير عندنا بطء في النظام. 🔹 النعيمي: الكاشينج هو الحل! أي بيانات ما تتغير كل ثانية، نحطها في Redis أو MemoryCache بدل ما نستعلم عنها من قاعدة البيانات كل مرة. هذا بيقلل الضغط ويحسن الأداء بشكل كبير. 🔸 عسكر: أوكي، بس نفترض إن المشروع كبر جدًا، وقررنا نحول بعض الأجزاء إلى Microservices؟ كيف نسهل الانتقال؟ 🔹 النعيمي: نستعد من البداية! بدل ما نخلي الوحدات تستدعي بعضها مباشرة، نستخدم Internal APIs أو Message Queues زي RabbitMQ أو Kafka. كذا، لو احتجنا نفصل وحدة معينة، يكون الموضوع مجرد خطوة بسيطة وما يحتاج إعادة بناء النظام بالكامل. 🔸 عسكر: يعني لو بنينا المونوليث بطريقة صحيحة، نقدر نستفيد منه بدون ما يدخلنا في مشاكل مستقبلًا؟ 🔹 النعيمي: بالضبط! المشكلة مش في المونوليث نفسه، المشكلة في سوء التصميم! لو خططنا صح، بيكون عندنا نظام قوي، سريع، وقابل للتوسع متى ما احتجنا. 🚀 🔸 عسكر: والله كلامك منطقي! نبدأ نطبق هذي الأفكار من الآن قبل ما يجي المدير ويطلب منّا نحول كل شيء لـ Microservices بدون سبب! 😂🔥

Css Border Radius

Css

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

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

متى يكون المونوليثيك أركيتكتشر هو الاختيار الصحيح؟ في السنوات الأخيرة، أصبحت الميكروسيرفيسز (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 أكثر سهولة وتنظيمًا. ما القادم؟ في المقال القادم، سنتحدث عن كيفية جعل المونوليث مرنًا ومستعدًا للتوسع دون أن يتحول إلى كابوس هندسي!

لو متعرفش 🙄 🤷‍♂️ تقدر تحميل 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 👍

تجربتي في التعامل مع عدد كبير من السجلات (حوالي 2 مليون سجل) من أهم مميزات LINQ في التعامل مع أي مصدر بيانات هو أنه يعتمد على السحب التدريجي للبيانات (Pulling)، على عكس الحلقات التقليدية مثل for loop التي تقوم بتحميل البيانات دفعة واحدة في الذاكرة قبل بدء المعالجة. في معظم الأحيان، يتم استخدام ToList أو ToListAsync لجلب البيانات، ولكن المشكلة هنا أنه حتى مع ToListAsync، يتم تحميل جميع البيانات في الذاكرة أولًا، ثم تنفيذ العمليات عليها. وهذا يعني أننا لم نستفد بشكل كافٍ من ميزة السحب التدريجي للبيانات. الحل: استخدام AsAsyncEnumerable عند الحاجة إلى كتابة البيانات في ملف Excel أو CSV، يمكننا الاستفادة بشكل أكبر من LINQ باستخدام AsAsyncEnumerable، حيث تتيح هذه الطريقة تدفق البيانات مباشرةً بمجرد أن تصبح جاهزة، دون الحاجة إلى انتظار تحميل جميع السجلات في الذاكرة دفعة واحدة. الفوائد: تقليل استهلاك الذاكرة: عند استخدام ToList، قد يتم استهلاك مئات الميجابايت من الذاكرة، بينما مع AsAsyncEnumerable، يتم استهلاك جزء بسيط منها فقط. في إحدى تجاربي، انخفض استهلاك الذاكرة من 460 ميجابايت إلى حوالي 10.5 ميجابايت. تحسين الأداء: بالرغم من أن الفرق الزمني لم يكن كبيرًا، إلا أن الطريقة الجديدة وفرت بشكل ملحوظ في الموارد، مما يجعلها أكثر كفاءة عند التعامل مع بيانات ضخمة. مقارنة بين الطريقتين بدلًا من استخدام Benchmark، فضّلت قياس أقصى استهلاك لحظي للذاكرة وليس الاستهلاك الإجمالي، لأن الهدف هنا هو تقليل الذاكرة المستخدمة أثناء تنفيذ العملية وليس فقط حساب المتوسطات. باختصار، AsAsyncEnumerable هي تقنية فعالة عند التعامل مع كميات كبيرة من البيانات، حيث تتيح معالجتها بشكل تدريجي دون الحاجة إلى تحميلها بالكامل في الذاكرة، مما يؤدي إلى تحسين أداء التطبيق وتقليل استهلاك الموارد.

#صنعاء #وظائف_شاغرة عديدة 1- مندوب تسويق ميداني 2- Full Stack (Laravel) Developer 3- Android (Flutter) Developer قدم الآن عبر هذا الرابط : https://forms.gle/MqxCbVXHcQfS5rfX8 ________ لمزيد من فرص الوظائف نوصي بمتابعتنا على صفحتنا في فيسبوك أو الانضمام إلى قناة الواتساب الخاصة بنا عبر الروابط التالية: صفحة الفيسبوك: [https://fb.shagher.net ] قناة الواتساب: [https://wa.shagher.net ] قناة التليجرام: [ https://t.me/Shagher_net ]

🥲🥲🥲 أذا رأيت منتجاً مجانياً، فأعلم انك أنت السلعة....💔

رسالة إلى كلِّ مُعلِّمٍ يَحملُ مِصباحًا، وكلِّ طالبٍ يَحلُمُ بِسَماءٍ، وكلِّ مُؤسسةٍ تَزعُمُ أنها تَبني العُقولَ: ### 1. المعلِّم: حارِسُ البوابةِ بين الظلامِ والنور  أيها الحاملونَ أمانةَ الكلمة..  لستم ناقِلينَ للمعرفةِ، بل أنتم حُرّاسُ البوابةِ بين عالَمَين:  عالمِ الجهلِ الصامِتِ، وعالمِ المعرفةِ الثائرِ.  كُلُّ كلمةٍ تَنطِقونَها هي إمَّا مِطرَقةٌ تَكسرُ قيودَ الوهمِ،  أو سِلسلةٌ تُقيّدُ بها العقولَ إلى أبدِ الآبدين.  فَـ  احذروا أن تَخونوا الأمانةَ..  فالطالبُ الذي تُطفِئونَ شعلَتَهُ اليومَ،  قد يكونُ الأخيرَ الذي يَجرؤُ على سؤالٍ يُغيِرُ مصيرَ أُمّةٍ! 🔥🗝️  ### 2. المحاضرةُ الجيّدةُ: ليست درسًا.. بل وَليمةٌ للعقلِ!  المحاضرةُ التي تُلهِمُ ليست نقلًا لِما في الكُتبِ،  بل هي رَقصةٌ بينَ السؤالِ والجوابِ،  حيثُ يَخرجُ الطالبُ وَكأنَّما شَرِبَ مِن نَهْرِ الفِكرِ،  فيَرى في كُلِّ كتابٍ مَرآةً تُعيدُ صياغةَ أَسئلتِهِ،  لا سِجنًا يُدَوِّنُ فيهِ إجاباتِ الآخرين!  هكذا تَصنَعُ المُحاضرةُ الجيّدةُ جيلًا يَقرأُ الوَحيَ بَينَ السُّطورِ،  ويَكتشفُ أنَّ الحقيقةَ ليست جَبَلًا ثابتًا،  بل بَحرًا يَتَحرَّكُ كُلَّما أَبحَرْتَ فيهِ. 🌊📖  ### 3. المحاضرةُ السيّئةُ: ليست خطأً.. بل جريمةٌ ضدَّ الإنسانيةِ!  أما المُحاضرةُ التي تَقتلُ الشغفَ،  فهي ليست مُجرَّدَ "ضعفٍ أكاديميٍّ"،  بل جريمةٌ تُرتَكبُ في وضحِ النهارِ..  جريمةٌ تَسرقُ مِن الطالبِ حَقَّهُ في أن يَتَعَجَّبَ،  وتَحشو رأسَهُ بِ"حقائقَ" جافَّةٍ كَأحجارِ المَقابِرِ!  حتَّى إذا ما وَجهَتهُ سؤالًا: "ما الهدفُ مِن هذا العِلمِ؟"،  أجابَكَ بِصوتٍ مَيتٍ: "لأجتازَ الامتحانَ فَقَط!".  هكذا تُنتِجُ المُحاضراتُ السيّئةُ أُمَّةً مِن الظِّلالِ،  تَسيرُ خلفَ شَموعٍ أُطفِئَت قَبلَ أن تُولَدَ! 🕯️⚰️  ### 4. الجامعاتُ: أينَ الحقيقةُ وراءَ القُبَّعاتِ والجِدارَاتِ؟  أيتها القلاعُ العاجيّةُ..  متى تَفيقينَ مِن سُباتِكِ؟  لقد صِرْتِ سُوقًا تَبتاعينَ الكرامةَ بِشهاداتٍ مَزورةٍ،  وتَبيعينَ الوهمَ بِاسمِ "التعليمِ العالي"!  أينَ أنتِ مِن جامعاتِ العالم،  حيثُ  الأستاذُ والطالبُ شَريكينِ في مُغامرةِ الفِكرِ،  يَحفرانِ معًا في أرضِ المُجهولِ،  لا يَخشيانِ مِن سُقوطِ الجدرانِ القديمةِ؟  إنَّ الجامعةَ التي لا تَزرعُ في طلابِها جُرأةَ الاعتراضِ،  هي مُجرَّدُ مَصنعٍ لِلقُوَّاتِ العاملةِ،  لا مَشعَلٍ لِلثوراتِ الفِكريّةِ! 🏛️💥  ### 5. الطالبُ: لا تَكُنْ وَقودًا لِآلةٍ قَديمةٍ!  يا مَن تَحملُ قلَبًا يَنبضُ بِالأسئلةِ..  لا تَسمحْ لأحدٍ أن يُحوِّلَكَ إلى بَندولٍ يَترنَّحُ بَينَ المُحاضراتِ والامتحاناتِ!  اِقرَأْ كَأنَّما الكِتابُ مِفتاحٌ لِغُرفةٍ مَجهولةٍ في رُوحِكَ،  اِسألْ كَأنَّما السؤالُ سَيفٌ يَقطَعُ أَسلاكَ الخوفِ،  وَاعلَمْ أنَّ الخيانةَ العُظمى هي أن تَخونَ فِكرَكَ لِتُرضيَ مُعلِّمًا عاجِزًا!  فَـ  مَتى ما وَضعتَ ثقتَكَ في عَقلِكَ،  ستَرى أنَّ التَعليمَ الحقيقيَّ يَبدأُ حَيثُ تَنتهي الكُتبُ! 🗝️🦅  ### 6. إلى صُنَّاعِ السِّياساتِ التَعليميّةِ: كفى تَشويهًا لِأرواحِ الأجيالِ!  يا مَن تَجلِسونَ في مَكاتِبَكُم الفَخمةِ..  أتَدرونَ أنَّ كُلَّ "توجيهٍ" تَصدرونَهُ بِلا رُوحٍ،  هو قَيدٌ يُضافُ إلى أقدامِ مُستقبَلٍ بِلا أجنحةٍ؟!  لَيسَ المَطلوبُ مَناهجَ أَضخمَ،  بل مُعلِّمينَ أَشجعَ..  لَيسَ المَطلوبُ مَدارسَ أَحدثَ،  بل فصولًا تَتَنفَّسُ حُرّيةَ السؤالِ!  فَـ  اتركوا العُقولَ تَنمو كَالأشجارِ،  لا تَقُصُّوها كَالأسيجةِ لِتُناسبَ أهواءَكُم! 🌳🔨  ### 7. الخاتمةُ: هُناكَ أملٌ.. لكن!  رُغمَ الظلامِ..  ما زالَ هُناكَ مَن يُضيءونَ شُمُوعَهُم في قُلوبِ التلاميذِ،  وما زالَ هُناكَ طلابٌ يَرفضونَ أن تَكونَ كِتاباتُهُم نُسخًا مُكرَّرةً!  فَلْنَكُنْ جُزءًا مِن هَذا الأملِ..  لِنُعلِّمَ أطفالَنا أنَّ الحقيقةَ وَطنٌ لا يُحتَلُّ،  وأنَّ السؤالَ حَقٌّ لا يُساومُ عَلَيهِ،  وأنَّ الكِتابَ لَيسَ نِهايةَ الطَّريقِ..  بَلْ بَدَايَةُ مَعرَكَةٍ مَعَ الذاتِ وَالجَهلِ وَالخَوْفِ! ⚔️📚  #التعليم_ليس_سوقًا_بل_معبدًا 🕊️  #أوقفوا_اغتيال_الفضول ⚠️✊

هل سمعت من قبل عن مصطلح Polyglot؟ يشير هذا المصطلح إلى الشخص الذي يتقن أكثر من لغة طبيعية، مثل العربية والإنجليزية والفرنسية والألمانية. وقد تم استعارة هذه الفكرة في مجال البرمجيات، حيث ظهرت عدة مفاهيم حديثة، من أبرزها: 🔹 Polyglot Persistence: وتعني استخدام أكثر من تقنية أو نوع من قواعد البيانات داخل نفس التطبيق، مثل الجمع بين قواعد البيانات العلائقية (Relational) مثل MySQL، وقواعد البيانات غير العلائقية (NoSQL) مثل MongoDB. 🔹 Polyglot Architecture: وهي تعني تصميم النظام باستخدام أكثر من معمارية برمجية أو لغة برمجة داخل نفس المشروع. هذا المفهوم أصبح شائعًا مع ظهور الـ Microservices، حيث يمكن لكل خدمة أن تستخدم التقنية الأنسب لوظيفتها. 🚀 قوة Polyglot في البرمجة تخيل أنك تطور تطبيقًا أساسيًا مكتوبًا بلغة Java، ولكنك بحاجة إلى جزء يتعامل مع Machine Learning، وهنا سيكون Python هو الخيار الأفضل. أو أنك تستخدم قاعدة بيانات MySQL، ولكن لديك جزء يتعامل مع Big Data، لذا قد تحتاج إلى Hadoop. هذه المرونة تتيح لك الاستفادة من أفضل التقنيات لكل جزء في مشروعك. ⚠️ تحذير مهم: لا تبالغ في التعقيد! ليس كل ما يمكنك تنفيذه يجب عليك تنفيذه! في معظم الحالات، التمسك بتقنية أو اثنتين فقط (مثل Java + MySQL مثلًا) سيجنبك الكثير من الفوضى، ويقلل من التكاليف، ويسهّل العثور على كفاءات متاحة في السوق. كلما أضفت تقنيات جديدة، زاد تعقيد الهندسة المعمارية للتطبيق وارتفعت تكلفة الصيانة. 💡 الخلاصة: Polyglot هي أداة قوية إذا استخدمتها بذكاء، ولكن إن أسأت استخدامها، فستواجه مشاكل معقدة وتكاليف عالية! 🤯

#حكم_برمجية -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 " اتحسس مسدسي