العلامات الشائعة：
الافتراضية أمان DNS التحقق الرسمي تحليل قابلية الوصول أخطاء المترجم تضارب الماكرو امتدادات الويب إطار عمل تطوير كومودور 64 بياسيك 2.0 جميع العلامات

قراءة التعليمات البرمجية: قوة خارقة للبحث عن الأخطاء

2025-09-08

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

اقرأ المزيد
(matklad.github.io)
التطوير قراءة التعليمات البرمجية البحث عن الأخطاء

حلقات إعادة المحاولة الأنيقة: تجنب التكرار والانتظار غير المتوقع

2025-08-27

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

اقرأ المزيد
(matklad.github.io)
التطوير

أسلوب أنيق في Zig: مطابقة جزئية للعدادات

2025-08-09

توفر Zig حلاً أنيقًا للتعامل مع المطابقة الجزئية في العدادات، مما يتجنب الكود الزائد والأخطاء في وقت التشغيل. تشرح المقالة تقنية ذكية باستخدام `inline` و `comptime unreachable` للسماح للمُترجم بالتحقق من فروع `else` غير الضرورية في وقت الترجمة، مما يحسن من متانة وقابلية قراءة الكود. هذا مفيد بشكل خاص عند التعامل مع العديد من متغيرات العداد، مما يبسط منطق الكود بشكل كبير.

اقرأ المزيد
(matklad.github.io)
التطوير عدادات التحقق في وقت الترجمة

الفائدة غير المُفهومة لـ `font-size-adjust`

2025-07-26

تتناول هذه المقالة المفاهيم الخاطئة الشائعة حول خاصية CSS `font-size-adjust`. يجادل الكاتب بأنّ `font-size` تحدد حجم المربع المحيط بالرمز، وليس حجم الرمز نفسه، مما يؤدي إلى عدم اتساق بين الخطوط المختلفة. وبدلاً من التركيز فقط على بدائل الخطوط، يمكن استخدام `font-size-adjust` لضمان حجم أكثر اتساقًا بين الخطوط المختلفة على الصفحة. يوصي الكاتب بتعيينها على `ex-height 0.53` في إعادة تعيين CSS لتحسين الاتساق الطباعي.

اقرأ المزيد
(matklad.github.io)
التطوير الخطوط

قارئ RSS بسيط: إنشاء خلاصة مدونة شخصية باستخدام Deno

2025-06-26

سئمت من قُرّاء RSS المُنتفخة؟ اتّبع الكاتب نهجًا مختلفًا، حيث قام بإنشاء قارئ RSS مخصص باستخدام Deno وملف نصّي بسيط. يعرض فقط عناوين وروابط آخر ثلاث مشاركات، بدون تخزين نصّي كامل محلي أو علامات قراءة/عدم قراءة، ويُحدّث تلقائيًا يوميًا عبر GitHub Actions. الشفرة موجزة، وسهلة الفهم والتوسيع، وهو حلم الحداديين.

اقرأ المزيد
(matklad.github.io)
التطوير حد أدنى

بناء سريع لـ Rust: أسرار CI أقل من 10 دقائق

2025-06-20

من الشائع الشكوى من بطء عملية تجميع Rust، لكن المؤلف يجادل بأن معظم مشاريع Rust تُجمّع أبطأ بكثير مما ينبغي. باستخدام rust-analyzer (200 ألف سطر من التعليمات البرمجية بالإضافة إلى مليون سطر من التبعيات) كمثال، تم تحقيق خط أنابيب CI مدته 8 دقائق على GitHub Actions. تُفصّل المقالة استراتيجيات لتحسين أوقات التجميع، بما في ذلك الاستفادة من ذاكرة التخزين المؤقت لـ CI، وتقسيم مهام CI، وتعطيل التجميع المتزايد ومعلومات التصحيح، وتقليل التبعيات، واستخدام `cargo build -Z timings` للتمثيل الشخصي، وتصميم التعليمات البرمجية بعناية لتجنب إنشاء مثيلات زائدة عن الحاجة للأنواع العامة على حدود crate. يُشدد المؤلف على تأثير وقت التجميع على إنتاجية المطورين، ويُوصي بتحسين أوقات التجميع بانتظام للحفاظ على أوقات CI لمشاريع Rust الكبيرة ضمن نطاق معقول، حوالي 10 دقائق.

اقرأ المزيد
(matklad.github.io)
التطوير

مشكلة التنسيق في البرمجيات مفتوحة المصدر: دروس من سطح مكتب لينكس و LSP

2025-06-20

يستخدم الكاتب خبرته مع NixOS وتطبيق KDE كنقطة انطلاق لمناقشة تحديات تنسيق البرامج مفتوحة المصدر في بيئة سطح مكتب لينكس. ويشير إلى نقص معيار واجهة برمجة التطبيقات الموحد في سطح مكتب لينكس، مما يؤدي إلى نظام بيئي للبرامج مجزأ، موصوف بأنه "آلة حركة دائمة على طريقة إسشر". وهذا يتناقض مع إطلاق بروتوكول خادم اللغة (LSP) من قبل مايكروسوفت قبل عقد من الزمن. وعلى الرغم من أن التنفيذ كان متوسطًا، إلا أن وجوده وحده حل مشكلة التنسيق لوظائف بيئة التطوير المتكاملة، مما دفع التقدم في الصناعة. ويجادل الكاتب بأن عدم قدرة مجتمع البرمجيات مفتوحة المصدر على التنسيق أدى إلى ضياع فرصة إنشاء بروتوكول بيئة تطوير متكاملة موحد قبل LSP. ومع ذلك، يُعزى نجاح لينكس إلى معيار واجهة برمجة التطبيقات المحدد مسبقًا الذي يوفره POSIX، مما يقلل من صعوبات التنسيق. وتحث هذه المقالة على التأمل في آليات التنسيق في مجتمع البرمجيات مفتوحة المصدر ونماذج تطوير النظم البيئية للبرامج. التصنيف: التكنولوجيا

اقرأ المزيد
(matklad.github.io)
التكنولوجيا

قاعدتان عمليتان لكتابة كود فعال

2025-05-17

تقدم هذه المقالة نصيحتين عمليتين لتحسين كفاءة الكود: نقل شروط `if` لأعلى ونقل دورات `for` للأسفل. يؤدي نقل شروط `if` إلى دالة المُستدعي إلى تقليل التفرعات، وتبسيط تدفق التحكم، وتحسين القابلية للقراءة. يؤدي نقل دورات `for` إلى المكان الذي تُعالَج فيه البيانات الضخمة إلى الاستفادة من مزايا المعالجة الضخمة، وتحسين الأداء، وربما يُمكّن من التوجيه المتجهي. تتكامل هاتان النصيحتان معًا، مما يُحسّن كفاءة الكود بشكل فعال، خاصة عند التعامل مع كميات كبيرة من البيانات.

اقرأ المزيد
(matklad.github.io)
التطوير

تجاوز الانتقاء القياسي: معالجة دفعات تيارات الأحداث من أجل الكفاءة

2025-05-15

يصف الكاتب عدم كفاءة نمط مكافحة الاختيار القياسي في تصميم الخدمات ذات الحالة، كما هو موضح في خادم LSP. يؤدي معالجة الأحداث واحدة تلو الأخرى إلى تأخيرات وإهدار للموارد. الحل المقترح هو معالجة تيارات الأحداث على دفعات. تقوم دالة `batch_stream` بدمج الأحداث الواردة في دفعات، مما يحسن الكفاءة بشكل كبير. تحت الحمل المنخفض، تعمل مثل معالجة حدث واحد، لكن تحت الحمل العالي، تقلل بشكل كبير من الأعباء الزائدة، مما يعزز الأداء.

اقرأ المزيد
(matklad.github.io)
التطوير مدفوعة بالأحداث

وقت التشغيل في زيج: برمجة وسيطة قوية لكنها مقيدة

2025-04-20

تُعرف ميزة وقت التشغيل في لغة زيج بقدراتها: الأنواع العامة، والترجمة الشرطية، وأكثر من ذلك. ومع ذلك، فهي مقيدة بشكل متعمد، حيث لا تسمح بتوليد التعليمات البرمجية الديناميكية، أو امتدادات بناء الجملة المخصصة، أو معلومات نوع وقت التشغيل (RTTI)، ومدخلات/مخرجات. يستكشف هذا المقال المنطق الكامن وراء هذه القيود، ويعرض كيف تحقق زيج برمجة وسيطة فعالة وسهلة الفهم من خلال التقييم الجزئي وتخصص النوع. يوضح مثال دالة الطباعة المخصصة كيف تقوم زيج بعمل انعكاس وقت تشغيل آمن من حيث النوع بدون RTTI. ويختتم المقال بالإشادة بأناقة زيج الفريدة في البرمجة الوسيطة؛ فعلى الرغم من أنها أقل قوة من البدائل، إلا أنها فعالة بشكل ملحوظ وسهلة الاستخدام في الممارسة العملية.

اقرأ المزيد
(matklad.github.io)
التطوير برمجة وسيطة وقت التشغيل نظام النوع

مصحح الأخطاء كبيئة تطوير تفاعلية (REPL): وظيفتا Run to Cursor و Quick Evaluate Expression في IntelliJ IDEA

2025-03-28

شعر الكاتب بالتعب من مصححي الأخطاء التقليديين، خاصةً قيود gdb و lldb مع التعليمات البرمجية الأصلية. اكتشف تدفق عمل قويًا في IntelliJ IDEA. من خلال الجمع بين "Run to Cursor" و "Quick Evaluate Expression"، يتحول مصحح الأخطاء إلى بيئة تطوير تفاعلية (REPL). تقوم "Run to Cursor" بتشغيل البرنامج حتى موضع المؤشر، بينما تسمح "Quick Evaluate Expression" بتقييم التعبيرات (حتى التعليمات البرمجية المكتوبة حديثًا!) ضمن إطار المكدس الحالي. يستبدل هذا النهج تصحيح الأخطاء خطوة بخطوة بتفاعل تجريبي ثنائي الأبعاد داخل المحرر، باستخدام إكمال التعليمات البرمجية وتوفير تجربة تصحيح أخطاء أكثر كفاءة بكثير.

اقرأ المزيد
(matklad.github.io)
التطوير

استخدم الخيارات الطويلة في البرامج النصية

2025-03-22

تدعم العديد من أدوات سطر الأوامر كلًا من الخيارات القصيرة (-f) والخيارات الطويلة (--force). بينما الخيارات القصيرة ملائمة للاستخدام التفاعلي، إلا أن الخيارات الطويلة أفضل بكثير في البرامج النصية. قابلية قراءتها المحسّنة وطبيعتها الواضحة تُحسّن من الصيانة والفهم. على سبيل المثال، في Git، الأمر `git switch --create release-{today} origin/main` أوضح بكثير من الأمر `git switch -c my-new-branch`، خاصة في البرامج النصية المعقدة.

اقرأ المزيد
(matklad.github.io)
التطوير كتابة البرامج النصية الخيارات الطويلة

Rust المتشددة: برنامج تتبع الأشعة بدون تخصيص ديناميكي للذاكرة

2025-01-30

تتناول هذه المقالة دراسة حالة حول كتابة تطبيق Rust باستخدام واجهة برمجة تطبيقات (API) ضئيلة للغاية ومقيدة بشكل مصطنع (بدون تخصيص ديناميكي للذاكرة). ينتقد الكاتب آلية RAII (Resource Acquisition Is Initialization) لقيادتها إلى إدارة موارد فوضوية، ويقترح "وضعًا متشددًا": تقسيم البرنامج إلى ملف ثنائي `std` ومكتبة `#![no_std] no_alloc`، مع السماح فقط للملف الثنائي بطلب الموارد مباشرة من نظام التشغيل. باستخدام برنامج تتبع أشعة لعبة كمثال، يشرح الكاتب بعناية كيفية التعامل مع مخازن البكسل، والتوازي، ومخصص الذاكرة، وتحليل المشهد في هذا "الوضع المتشدد"، مما يحقق في النهاية برنامج تتبع أشعة بدون تخصيص ديناميكي للذاكرة.

اقرأ المزيد
(matklad.github.io)
التطوير

الثوابت: أداة قوية لكتابة شفرة صحيحة

2025-01-12

تتناول هذه المقالة مفهوم "الثوابت" في البرمجة وتطبيقاتها. بدايةً من مثال صغير - كتابة متغير من البحث الثنائي يحسب نقطة الإدخال - يوضح الكاتب كيف يؤدي تعريف وصيانة الثوابت إلى شفرة صحيحة. الثوابت، كما يشرح المقال، هي خصائص تبقى صحيحة طوال التطور الديناميكي للنظام، مما يبسط عملية التفكير من خلال تجنب تعقيدات النظر في العديد من مسارات التنفيذ. أمثلة من مشاريع مثل Cargo و rust-analyzer و TigerBeetle توضح فوائد استخدام الثوابت في الأنظمة الكبيرة، مثل تحسين الصيانة والأداء. يختتم الكاتب المقال بتلخيص أهمية الثوابت في البرمجة على نطاق صغير وكبير، مشدداً على قيمتها في كتابة شفرة صحيحة وفعالة.

اقرأ المزيد
(matklad.github.io)
التطوير تقنيات البرمجة

فكرة ثورية: تطبيق مبادئ Magit على نظام التحكم في الإصدارات jj

2024-12-13

يقترح الكاتب نهجًا مبتكرًا: تطبيق واجهة التحكم في الإصدارات Magit من Emacs (التي تستخدم ملفات نصية كواجهة مستخدم) على نظام التحكم في الإصدارات jj الناشئ. تشير المقالة إلى أن واجهة المستخدم النصية لـ Magit توفر الكفاءة والقدرة على النقل. من خلال الاستفادة من بروتوكول LSP، يمكن تنفيذ تجربة مشابهة لـ Magit في محررات متعددة، مما يتجنب التطوير المتكرر. يتوقع الكاتب إنشاء ملفات نصية محددة (مثل .jj/status.jj) واستخدام ميزات LSP مثل الرموز الدلالية، ونطاقات الطي، والانتقال إلى التعريف، لتحقيق عمليات تحكم في الإصدارات مشابهة لـ Magit. والهدف النهائي هو إنشاء واجهة مستخدم فعالة ومتعددة المنصات للتحكم في الإصدارات jj.

اقرأ المزيد
(matklad.github.io)
التطوير