القوائم المترابطة المتضمنة (Intrusive linked lists)

القوائم المتصلة المتداخلة (Intrusive linked lists) هي نوع من القوائم المتصلة التي تكون فيها روابط الربط مُضمَّنةً داخل البنية نفسها التي يجري ربطها.

في التنفيذ المعتاد للقائمة المترابطة، تحتوي عقدة القائمة على مؤشر بيانات يشير إلى البيانات المترابطة، ومؤشر "التالي" (next pointer) يشير إلى العقدة التالية في القائمة.

في تنفيذ القائمة المتصلة المتداخلة (intrusive linked list)، تحتوي عقدة القائمة على مؤشر يشير إلى العقدة التالية، ولكنها لا تحتوي على مؤشر للبيانات؛ وذلك لأن القائمة تكون مضمّنةً داخل الكائن المرتبط نفسه.

تكون عقدة القائمة (list node) مضمّنة داخل الكائن الذي يحتويها.
تشير عقدة القائمة هذه إلى عقدة قائمة أخرى مضمّنة في الكائن المرتبط (linked object).
يتم حساب العنوان الأساسي للكائن المرتبط عن طريق طرح قيمة الإزاحة (offset) الخاصة بعضو القائمة من عنوان الذاكرة الخاص بكائن القائمة المرتبطة.
بعد كل هذه العمليات الحسابية على المؤشرات، ربما تتساءل: لماذا قد يلجأ أي شخص عاقل إلى استخدام قائمة مرتبطة "متداخلة" (intrusive linked list) بدلاً من القائمة المرتبطة العادية؟
لماذا نستخدم القوائم المرتبطة المتداخلة؟
هناك سببان رئيسيان لتفضيل القوائم المتداخلة على القوائم المرتبطة غير المتداخلة (non-intrusive):

• عدد أقل من عمليات تخصيص الذاكرة.
• انخفاض معدل "اضطراب الذاكرة المخبئية" (cache thrashing).

في القوائم المرتبطة غير المتداخلة، يتطلب إنشاء كائن جديد وإضافته إلى القائمة عمليتي تخصيص للذاكرة: واحدة للكائن نفسه، وأخرى لعقدة القائمة. أما في القوائم المتداخلة، فأنت بحاجة فقط لتخصيص كائن واحد (نظراً لأن عقدة القائمة تكون مضمّنة داخل الكائن). وهذا يعني عدداً أقل من الأخطاء التي يجب التعامل معها، حيث تنخفض إلى النصف الحالات التي قد تفشل فيها عملية تخصيص الذاكرة.
كما تعاني القوائم المرتبطة المتداخلة بشكل أقل من مشكلة اضطراب الذاكرة المخبئية؛ فالتنقل عبر عقدة قائمة غير متداخلة يتطلب الوصول إلى محتوى العقدة (dereferencing) ثم الوصول إلى بيانات القائمة، بينما تتطلب القوائم المتداخلة الوصول فقط إلى عقدة القائمة التالية.
قبل استعراض كيفية إدارة العمليات (processes) باستخدام القوائم المرتبطة في نظام Linux، يجب عليك فهم القوائم المرتبطة المزدوجة (doubly linked lists) والقوائم المرتبطة الدائرية (circular linked lists).

المزيد في المزقع هنا

حسناً، سأبني محرر النصوص الخاص بي!

لقد لاقت عبارة "لم يعودوا يصنعون برامج مثل Sublime Text" صدىً واسعاً لدى الكثيرين؛ فمعظم البرمجيات هذه الأيام رديئة المستوى. وهذا دفعني للتفكير: أنا أيضاً أجيد صنع برمجيات رديئة!

لماذا لا أقوم ببناء محرر نصوص خاص بي؟
يعتمد محرر VS Code على Monaco Editor، وهو عبارة عن كابوس من تداخل عناصر `<div>` بشكل فوضوي. لقد تأخرت في الانضمام إلى ركب مستخدمي VS Code لأن جهاز Mac الخاص بي (بمعالج Intel) كان بطيئاً للغاية لسنوات، وقد حُلت هذه المشكلة عندما اشتريت جهازاً بمعالج Apple Silicon. وإذا كان هذا هو المعيار السائد، فهذا يعني أن لدي مجالاً واسعاً لارتكاب الأخطاء.
Canvas
تعتمد تجربتي الأولى على عرض كل شيء داخل عنصر `<canvas>`.
معدل الإطارات (FPS): 55
قد لا تلاحظ ذلك، لكن المعالج (CPU) يبذل جهداً كبيراً لعرض تلك الصورة بمعدل يتراوح بين 60 و120 إطاراً في الثانية. وتُعد قلة التفاعل مشكلة واضحة بالنسبة لمحرر نصوص.
أعددت قائمة بالميزات "الحد الأدنى القابل للتطبيق" (MVP) وقمت بتنفيذها:
النقر لتحديد موقع مؤشر النص
استخدام مفاتيح الأسهم لتحريك المؤشر
تمييز السطر الحالي
الكتابة لإدخال النص
رسوم متحركة جذابة للمؤشر
العرض التوضيحي التالي تفاعلي؛ جرب النقر والكتابة.
معدل الإطارات (FPS): 55
قبل أن تنتقدني بشأن اختصارات Vim: اصمت، فلدّي مشكلات أكثر إلحاحاً. لا يوفر لي عنصر Canvas أي ميزات جاهزة؛ ومن بين الميزات المرغوبة التي أفتقدها:
تحديد النص
سجل التراجع والإعادة (Undo/Redo)
لصق نصوص متعددة الأسطر
التمرير عند تجاوز المحتوى للمساحة المتاحة (Overflow scrolling)
تُعد هذه النقطة الأخيرة بالغة الأهمية؛ فالحياة أقصر من أن أقضيها في برمجة أشرطة تمرير مرنة (elastic scrollbars) مخصصة. لذا قررت اللجوء لحيلة برمجية واستخدام خاصية التمرير الأصلية للمتصفح على عنصر مخفي: حيث يتم ضبط حجم عنصر `<div>` ليتطابق مع أبعاد النص في الـ Canvas، ويُستخدم موضع التمرير لحساب إزاحة العرض (render offsets) داخل الـ Canvas.

الموقع الرئيسي

البرمجة فن

عندما بدأتُ البرمجة، كان يومي بأكمله يتمحور حول التطوير؛ أستيقظ، وأكتب الكود، ثم أخلد للنوم. هكذا كان حالي يوماً تلو الآخر. كانت دائرتي الاجتماعية بأكملها تتألف من أشخاص يمارسون البرمجة أيضاً، وكنت أدرس أطر العمل (frameworks) والمكتبات البرمجية ولغات برمجة متنوعة.
لقد دخلت مجال التطوير لأنني كنت مفتوناً بفكرة أنني أستطيع إنشاء برامج جديدة بمجرد كتابة الكود. كان كل ما علي فعله هو تعلم البرمجة لأتمكن من بناء أي شيء؛ فإذا تعلمت PHP، أمكنني بناء تطبيقات للجانب الخلفي (back-end)، وإذا تعلمت HTML وCSS، أمكنني بناء مواقع إلكترونية.
كان بإمكاني اختيار ما أريد إنشاءه، وتعلم التقنيات اللازمة لذلك، ثم البدء في البناء. تفتح بيئة التطوير المتكاملة (IDE)، وتنشئ مشروعاً جديداً، وتبنيه من الصفر. تختار الأنماط والمكتبات وأطر العمل، وتقرأ التوثيق الفني وتغوص في الكود المصدري. تندمج في العملية لدرجة أنك لا تشعر بمرور الأيام بسرعة. ومع مرور الوقت، تطور أسلوبك الخاص في البرمجة.
لقد كتبت الكود واستمتعت بذلك، لكنه لم يكن نوع العمل الذي أردت القيام به لبقية حياتي. كنت أفضل عملية "الابتكار" أو إنشاء شيء جديد على عملية كتابة الكود بحد ذاتها. أحببت البدء من الصفر -بمجرد فكرة- لإنشاء منتج يستخدمه الناس فعلياً؛ ولهذا السبب عملت حصرياً في الشركات الناشئة ولم أعمل قط في الشركات الكبرى.
لطالما حلمت بالتقدم في مساري المهني -لأصبح قائد فريق أو مديراً، أو أتولى دوراً لا يتضمن كتابة الكود. وكلما توفر شخص آخر لكتابة الكود، كنت أنتقل من البرمجة إلى المهام الإدارية. لم يكن يهمّني ما إذا كنت أكتب الكود بنفسي أو أوكله للآخرين.
ورغم أنني دخلت مجال التطوير بدافع الاهتمام بابتكار الأشياء، إلا أنني لاحقاً أصبحت أمارسه لمجرد الحصول على مقابل مادي؛ فقد كان الأمر بالنسبة لي مجرد وظيفة. وحتى عندما كنت أكتب الكود في وقت فراغي، كنت أستخدم ذلك النهج لبناء شركاتي الناشئة الخاصة التي خططت لجني المال منها. لقد كانت كتابة الكود وجني المال أمرين لا ينفصلان؛ ومع مرور الوقت، أصبح الدخل الناتج عن المشاريع هو المحور الأساسي، بدلاً من مجرد الرغبة في إنشاء المشاريع. ولكن هناك نوع آخر من الأشخاص؛ إنهم المبرمجون الحقيقيون الذين يكتبون الأكواد البرمجية بغض النظر عن العائد المادي. فهم يكتبون الكود لمجرد أنهم لا يستطيعون التوقف عن ذلك، ولا يكترثون لحجم المال الذي قد يجنونه منه؛ إذ قد يعملون على مشاريع مفتوحة المصدر لن تدرّ عليهم أي دخل على الإطلاق.
إنهم يستمتعون بكتابة الكود، وحل تحديات التطوير، والتصميم، واستنباط المنطق البرمجي، وإصلاح الأخطاء، وفهم النظام بأكمله؛ فهم يستمتعون بالعملية ذاتها، ولن يتنازلوا أبداً عن هذا الدور لصالح وكلاء الذكاء الاصطناعي.

أنا أحب تأسيس الشركات الناشئة، وهم يحبون كتابة الكود. بالنسبة لي، يُعد بناء المشاريع وسيلةً لكسب المال، أما بالنسبة لهم، فالبرمجة فنّ.
لهذا السبب، فإن كل ما أطرحه من حجج حول دور الذكاء الاصطناعي في مساعدتي على بناء المشاريع لا يعني شيئاً لهؤلاء الفنانين الحقيقيين؛ فهم ليسوا بحاجة إلى الذكاء الاصطناعي لمساعدتهم في أي شيء.

المزيد

Bitap: خوارزميتي المفضلة لمطابقة السلاسل النصية

تتمثل إحدى المسائل الكلاسيكية في العثور على أول ظهور لنمط (Pattern) معين، ولنرمز له بـ P، داخل سلسلة نصية (String)، ولنرمز لها بـ T. وتوجد خوارزميات كلاسيكية متنوعة لحل هذه المسألة بكفاءة، مثل خوارزميات "بوير-مور" (Boyer-Moore) و"كنوث-موريس-برات" (Knuth-Morris-Pratt) و"تو-واي" (Two-Way). أود في هذا المقال استعراض خوارزمية أقل شهرة، وهي خوارزمية "بيتاب" (Bitap) -أو ما يُعرف بـ "شيفت-آند" (Shift-And)- التي تعمل بكفاءة عندما يكون النمط P قصيراً نسبياً (أي أن طوله يقل عن عرض "كلمة الآلة" أو machine word). ورغم ما لهذه الخوارزمية من قيود، إلا أنني أفضلها كثيراً؛ فهي بسيطة الفهم والتطبيق، وتتمتع بكفاءة عالية نسبياً عند التعامل مع السلاسل النصية القصيرة، كما أنها توظف العمليات المنطقية على مستوى البتات (bit operations) بأسلوب أنيق ومميز.
ولإثبات أن هذه الخوارزمية تتسم بالبساطة المفاهيمية المذكورة، سأحاول استنباطها تدريجياً، بدءاً من أبسط خوارزميات مطابقة السلاسل النصية وأكثرها بدائية.
تحويل الخوارزمية البسيطة (الساذجة) إلى خوارزمية تدفق (Streaming)
لنفرض الآن قيداً إضافياً يدفعنا لتعديل الخوارزمية قليلاً: بدلاً من الحصول على جميع محارف النص $T$ دفعة واحدة، لنفترض أنها تُقدَّم الآن على شكل تدفق بيانات، بحيث يصل محرف واحد في كل مرة (ربما يكون النص $T$ طويلاً جداً ولا نرغب في تحميل كامل محتوياته في الذاكرة دفعة واحدة).
الخوارزمية البسيطة المذكورة أعلاه لا تعمل بنظام التدفق؛ فهي تحتاج إلى قراءة ما يصل إلى $m = \text{len}(P)$ من المحارف المتقدمة (أي التي تلي الموقع الحالي) في النص $T$ لاكتشاف مطابقة للنمط $P$. فكيف يمكننا تكييفها بحيث تجري تمريرة واحدة فقط عبر البيانات؟
بعد قليل من التفكير، نتوصل إلى الصيغة التالية المعدلة من خوارزمية البحث الشامل (brute-force). بدلاً من محاولة اكتشاف وجود النمط $P$ فوراً عن طريق القراءة المسبقة في النص $T$ بدءاً من كل موقع $i=0, \dots$، يمكننا الاحتفاظ بمجموعة من المطابقات "قيد التنفيذ" أثناء مسح النص $T$. من الناحية المفاهيمية، تتكون المطابقة قيد التنفيذ من بادئة (prefix) النمط $P$ التي طُوبقت بالفعل قبل الموقع الحالي، بالإضافة إلى اللاحقة (suffix) المتبقية التي لم تُطابق بعد. وعند قراءة محرف جديد $c$ في النص $T$، نقوم بتقديم المطابقات التي تنتظر هذا المحرف $c$، ونلغي (أو ننهي) بقية المطابقات. وإذا وصلت أي من المطابقات النشطة إلى نهاية النمط $P$، نكون قد أتممنا المهمة.

المزيد

سحابة في زجاجة: جعل الاستضافة الذاتية متاحة للجميع

موقع Cloud in a Bottle هو مشروع مفتوح المصدر (مُرخّص بنظام AGPL-3.0) يُقدّم نظام تشغيل مبسط لسحابتك الشخصية (Personal Cloud).
الهدف الرئيسي منه هو تمكينك من استضافة تطبيقاتك وبياناتك بنفسك بسهولة دون الحاجة للرابط المباشر أو التعقيدات التقنية، وهو بمثابة متجر تطبيقات خاص بك يُدار بنقرة واحدة على خوادم أو أجهزة تملكها وتحتكُم بها.
أهم الميزات والخصائص
كتالوج تطبيقات جاهز: يحتوي على تطبيقات مفتوحة المصدر مشهورة ومجهزة للتثبيت بنقرة واحدة مثل:
Nextcloud: لتخزين الملفات والمزامنة والتقويمات.
Jellyfin: لتشغيل البث المباشر للأفلام، الموسيقى، والوسائط.
VaultWarden: لإدارة كلمة المرور (بديل Bitwarden).
Pi-hole: لحظر الإعلانات والبرمجيات الخبيثة على مستوى الشبكة.
SearXNG: محرك بحث محلي يحافظ على الخصوصية.
Open WebUI: واجهة تشبه ChatGPT للتعامل مع الذكاء الاصطناعي المحلي.
استضافة تطبيقاتك الخاصة: أي برنامج يعتمد على تقنية الحاويات (Docker Containers) أو مشروع قمت ببرمجته، يمكنك رفعه وربطه بسهولة عبر حساب GitHub الخاص بك ليتم تشغيله وإعطاؤه عنوان ويب خاضع للتحكم.
الخصوصية والأمان: تعمل جميع التطبيقات داخل بيئات معزولة (Security Sandboxes) برصيد أدنى من الصلاحيات.
ملكية البيانات: يتم حفظ جميع بيانات التطبيقات في مجلد واحد على قرص خادمك، مما يسهل عملية النسخ الاحتياطي (Backup) ونقل البيانات دون قيود أو احتكار من الشركات (No Lock-in).
خيارات الاستضافة والتسغيل
على أجهزتك الشخصية (مجاناً): تشغيل النظام على جهاز كمبيوتر قديم، أو كمبيوتر محمول، أو Raspberry Pi.
على خادم افتراضي خاص (BYO VPS): استئجار خادم خاص بك من أي شركة مثل (Hetzner, DigitalOcean, Linode) وتثبيت النظام عليه.
خدمة مُدارة بالكامل (مدفوعة): الاشتراك عبر مطوري المشروع (Imbue) للحصول على خادم جاهز مع عنوان IP ونطاق (Domain) جاهز (تبدأ من 5$ شهرياً).
كيف تستفيد منه؟
الاستغناء عن الخدمات السحابية المدفوعة: يمكنك استبدال Google Drive أو OneDrive باستخدام Nextcloud، واستبدال Spotify/Netflix باستخدام Jellyfin أو Navidrome، واستبدال 1Password بـ VaultWarden.
إطلاق وتجربة مشروعاتك الشخصية: إذا كنت مبرمجاً أو تطور تطبيقات باستمرار، يتيح لك الموقع نشر تطبيقاتك وتجربتها على نطاق خاص (my-app.your-domain.com) بسهولة.
حماية الخصوصية: حظر الإعلانات والتتبع على كافة أجهزة منزلك عبر تشغيل Pi-hole وتصفح الإنترنت بأمان عبر SearXNG.
تشغيل نماذج الذكاء الاصطناعي محلياً: الاستفادة من Open WebUI لتشغيل نماذج ذكاء اصطناعي دون إرسال بياناتك لشركات خارجية.

المزيد

بعض الأفكار حول مسألة "نافييه-ستوكس" (إحدى مسائل جائزة الألفية)

يتناول هذا الموضوع نتيجةً مبهرةً توصلت إليها شركة OpenAI؛ إذ استخدمت الشركة نموذجاً غير مُعلن عنه لتقديم حل لمسألة "الوجود والسلاسة" (existence and smoothness) الخاصة بمعادلات "نافييه-ستوكس"، وهي واحدة من "مسائل جائزة الألفية" السبع التي رُصدت لها جائزة قدرها مليون دولار منذ 24 مايو 2000.
غير أن هذا الاكتشاف قد طغت عليه بعض الاتهامات بممارسات غير نزيهة وجهها تريستان باكماستر، أستاذ الرياضيات في جامعة نيويورك، الذي كان يتعاون في مسائل ذات صلة مع ليفنت ألبوج، وهو عالم رياضيات بارع يعمل حالياً لدى شركة Anthropic.
تزامنت شكوى تريستان مع نشرٍ متسرع لنتائجهما الخاصة؛ ويمكن الاطلاع على ملف PDF يوضح تفاصيل ما حدث هنا. وباختصار شديد: عمل تريستان وليفنت على المسألة لما يقرب من عام، مستخدمين بشكل مكثف نموذجي Claude وCodex (وتحديداً نسخة GPT-5.6 Sol)، حتى حققا اختراقاً بحثياً في 15 أغسطس. وفي خضم تداول الشائعات في الأوساط الرياضية، وصل إلى مسامع تريستان وليفنت أن OpenAI قد علمت بأن Anthropic نجحت في حل "مسألة كبرى عالقة"؛ فتواصلا مع OpenAI ليعلما أن لديها فريقاً يعمل على مسألة ذات صلة وبنهج مشابه. وعلى حد تعبير تريستان:
سألتُ عن موعد إرسالهم لأول "أمر توجيهي" (prompt)؛ وهو سؤال لم تُجب عليه OpenAI بشكل مباشر لفترة من الوقت. وفي النهاية، تم الاتفاق على أنه أُرسل خلال الأيام القليلة الماضية، وذلك بعد أن وصلت معلومات حول عملنا إلى OpenAI.
سألتُ عما إذا كان النموذج قد تدرب على جلساتنا في نظام Codex —حيث كنا نضع جميع مسوداتنا الخاصة بالمشروع بأكمله— أو ما إذا كان بإمكانه الوصول إليها. فأُخبرتُ بأن النموذج لا يطّلع على بيانات المستخدمين. عاودتُ السؤال بشأن التدريب، لكنني لم أحصل على إجابة.
ازداد الأمر تعقيداً بعد ذلك؛ إذ عرض فريق OpenAI الانتظار حتى ينشر "تريستان" (Tristan) نتائجه، أو أن يقوم هو بكتابة ورقة بحثية حول ما توصلوا إليه، لكنهم أوضحوا بجلاء أن "ليفنت" (Levent) لن يُدعى للمشاركة كمؤلف مشارك نظراً للعلاقة التنافسية بين OpenAI والجهة التي يعمل لديها "ليفنت".
وإليكم كيف وصفت OpenAI عملها:
في يوم الثلاثاء، الأول من سبتمبر، سمعنا شائعات تفيد بحل مسألتين من "مسائل جائزة الألفية" (Millennium Prize problems). واستلهاماً من هذه الشائعات ومن القفزة النوعية في أداء نموذجنا الداخلي، أطلقنا مبادرة لتقييم أدائه على جميع مسائل جائزة الألفية المفتوحة، بالإضافة إلى بضع مسائل أخرى ذات أهمية بالغة. [...]
توصلت الوكلاء (الأنظمة الذكية) إلى الحل يوم السبت، الخامس من سبتمبر، أي بعد حوالي 88 ساعة من إطلاق الدفعة الأولى منها. واستغرقت عملية الصياغة الرسمية والتحقق (باستخدام لغة Lean) 17 ساعة إضافية عبر نموذج GPT-6 Astra.
وعبر جميع المسائل التي جرت محاولة حلها، أرسلت هذه الوكلاء 4.9 مليون رسالة واستهلكت حوالي 300 مليار "رمز" (token) من المخرجات. وفي سياق حل مسألة "نافييه-ستوكس" (Navier–Stokes)، أرسلت الوكلاء 2.7 مليون رسالة واستهلكت ما يقرب من 130 مليار رمز من المخرجات.
(نحن لا نعرف هيكل التكلفة الخاص بالنموذج الداخلي الذي استخدموه، ولكن 300 مليار رمز من المخرجات -وفقاً لأسعار واجهة برمجة التطبيقات العامة لنموذج GPT-6 Astra- كانت ستكلف 15 مليون دولار).

المزيد

Huzzah ! طريقة تجريبية جديدة للبرمجة باستخدام الذكاء الاصطناعي

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

لماذا تُعدّ لغة Go لغة مثالية لهندسة البرمجيات المدعومة بالذكاء الاصطناعي؟

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

المزيد

بإمكان HTML فعل ذلك

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

المزيد

خاصية القص الشبح - أو لماذا خاصية القص واللصق معطلة في كل مكان

هل هي عملية قص ولصق، مثل السمك والبطاطا المقلية؟
إن خاصية القص واللصق معيبة في جميع برامج معالجة النصوص، ومحررات النصوص، ومساحات النصوص في المتصفحات التي استخدمتها من قبل. وهذا حالها منذ عقود.
ولكي نكون على دراية بالأمر: القص واللصق هما عمليتان متكاملتان: القص، وهو إزالة النص من المستند ووضعه في الحافظة، واللصق، وهو إدراج هذا النص في موضع جديد من المستند.
كيف يمكن أن تكون معيبة وهي منتشرة بهذا الشكل؟ دعني أعدد لك الأسباب!
1. لا يمكن التراجع عن القص
أول عيوب القص واللصق هو أنه لا يمكن التراجع عن عملية القص بشكل كامل. التراجع (Ctrl+Z أو Command+Z) بعد القص يعيد النص إلى حالته قبل القص في المستند، لكن التغييرات التي أُجريت على الحافظة تبقى. إذا ندمت على استبدال محتويات الحافظة، فقد ضاعت إلى الأبد. حتى مع استخدام مدير الحافظة، فإن التراجع لا يُلغي تمامًا كل ما تم تنفيذه بضغطة زر واحدة.
2. إعادة تنسيق النص بعد القص
العيب الثاني هو أن القص يُعيد تنسيق المستند. عادةً ما يكون القص واللصق لنقل النصوص، ولكن بمجرد القص، يُعاد تنسيق النص، مما يُجبرني على تحديد الموضع الذي أرغب في اللصق فيه من جديد. قد يبدو هذا عبئًا ذهنيًا بسيطًا، ولكنه غير ضروري.
3. القص واللصق ليسا عمليتين منفصلتين
العيب الثالث والأخير هو أنه على الرغم من أن القص واللصق يُفترض أنهما عملية نقل نص من مكان إلى آخر، إلا أنه لا يمكن التراجع عنهما كخطوة واحدة (بغض النظر عن مشكلة الحافظة حاليًا). يؤدي التراجع عن اللصق إلى إزالة النص المُضاف حديثًا، ولكنه يتطلب تراجعًا ثانيًا لاستعادة النص بالكامل - بافتراض عدم وجود أي تعديلات بين القص واللصق. في حال وجود تعديلات وسيطة، مثل إنشاء فقرة جديدة، فيجب التراجع عنها قبل الوصول إلى القص الأصلي.
تقديم ميزة القص الخفي
أضفتُ آليةً إلى برنامج إسماعيل تُصلح هذه العيوب. والخبر السار هو أنها لا تتطلب إعادة تدريب الذاكرة العضلية أو أي شيء إضافي عما تفعله بالفعل.
أُطلق عليها اسم "القص الخفي"، وتعمل كالتالي: الضغط على Ctrl+X يُخفي النص المُحدد ويجعله غير قابل للتحرير - لا يمكنك النقر على النص المقصوص، ويقفز المؤشر فوقه، ولكنه يبقى موجودًا في المستند. لا يتم وضع أي شيء في الحافظة في هذه المرحلة، ولا يوجد ما يُمكن التراجع عنه. إذا قررتَ عدم اللصق، فإن الضغط على مفتاح الهروب (Escape) يُعيد النص إلى حالته القابلة للتحرير.
اللصق (عادةً Ctrl+V أو Command+V) يُزيل النص المُحدد من موقعه الأصلي ويضعه عند المؤشر، مما يُنشئ عملية نقل واحدة دون استخدام الحافظة. بعبارة أخرى: يُمكن عكس العملية تمامًا بضغطة زر واحدة دون حذف الحافظة.
إليك مثال عملي:

المزيد

بعض الأمور التي تعلمتها حول تشغيل SQLi

مرحباً! أعمل حالياً على موقع Django، وقررت استخدام SQLite كقاعدة بيانات. عندما بدأتُ استخدام SQLite كقاعدة بيانات لموقع ويب، قرأتُ العديد من المقالات التي تُشير إلى أنه من الآمن تماماً استخدام SQLite في بيئة الإنتاج لموقع صغير، وأعتقد أن هذا صحيح تماماً، لكن ما لم أُدركه تماماً هو أن SQLite تبقى قاعدة بيانات، وقواعد البيانات معقدة، ولا أملك خبرة كبيرة في تشغيلها.
لذا، إليكم بعض الأمور البسيطة التي تعلمتها حول تشغيل SQLite. هذا هو الموقع الرابع الذي أستخدم فيه SQLite، وأعتقد أن هذا الموقع أصعب لأنني، بفضل قوة Django ORM، أحمّل قاعدة البيانات مهاماً أكثر مما كنتُ أقوم به سابقاً بدون Django.
بدأتُ بتفعيل وضع WAL كما هو مذكور في جميع المقالات، متمنياً أن تسير الأمور على ما يُرام.
يبدو أن أمر ANALYZE مهم. اليوم، كنتُ أُجري استعلامًا (باستخدام FTS5 من SQLite للبحث النصي الكامل) على جدول يحتوي على 4000 صف، واستغرق 5 ثوانٍ. بدا لي هذا غير منطقي: فالحواسيب سريعة!
اتضح أن ما كان عليّ فعله هو تشغيل أمر ANALYZE! فورًا، انخفض وقت تنفيذ الاستعلام من 5 ثوانٍ إلى حوالي 0.05 ثانية (أو رقم صغير جدًا لدرجة أنني لم أُعر الأمر اهتمامًا). ما زلتُ لا أعرف بالضبط ما الخطأ الذي حدث في خطة الاستعلام، لكنني أرجّح أنه كان خطأً تربيعيًا غير مقصود.
يُنشئ أمر ANALYZE "إحصائيات" (أظن أنها تتعلق بعدد الصفوف في كل جدول؟ وربما أشياء أخرى؟) حتى يتمكن مُخطط الاستعلام من اتخاذ خيارات أفضل.
ربما أتعلم يومًا ما قراءة خطة الاستعلام.

المزيد

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

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

المزيد

ماهو SIMID؟

 تقنية SIMD هي اختصار لـ Single Instruction, Multiple Data (تعليمات واحدة، بيانات متعددة). وهي نوع من بنية الحاسوب وتقنية معالجة تسمح لتعليمات وحدة المعالجة المركزية (CPU) بتنفيذ نفس العملية على نقاط بيانات متعددة في نفس الوقت. كيف تعمل تقنية SIMD؟ المعالجة العددية مقابل المعالجة المتجهة: في المعالجة العددية، يتم تشغيل حلقة لمعالجة جزء واحد من البيانات في كل مرة. أما في تقنية SIMD، فيتم تجميع قيم متعددة في سجل واحد عريض (متجه) وتطبيق العملية الحسابية عليها جميعًا في دورة ساعة واحدة. الكفاءة: تقلل تقنية SIMD من الحمل الزائد للحلقات وعدد التعليمات، مما يجعل البرامج تعمل بشكل أسرع بكثير دون الحاجة إلى أنوية أو خيوط معالجة إضافية. دعم الأجهزة: تتضمن معالجات الحواسيب والهواتف الحديثة امتدادات SIMD مدمجة مثل SSE/AVX من Intel أو Neon من ARM. الاستخدامات الشائعة: الرسومات والألعاب: معالجة البكسلات، والرؤوس ثلاثية الأبعاد، وعرض الفيديو. الوسائط والصوت: معالجة تدفقات الصوت وفلاتر الصور. العلوم والذكاء الاصطناعي: تشغيل نماذج التعلم الآلي، ومحاكاة الفيزياء، ومصفوفات الأعداد الضخمة.

المزيد

ويكيبيديا

نظام بيئي مفتوح لأجهزة القراءة الإلكترونية.

فري إنك هي مجموعة مفتوحة المصدر تعمل على تطوير البرمجيات والبرامج الثابتة والأجهزة الخاصة بقارئات الورق الإلكتروني. جميع مكوناتها متاحة للجميع، مما يتيح لأي شخص استخدامها وتطويرها وتخصيصها حسب رغبته.
تجربة قراءة إلكترونية مُصممة خصيصًا لأسلوب قراءتك.
برنامج ثابت مفتوح المصدر بالكامل، تم تطويره من قِبل المجتمع، لأجهزة قراءة الكتب الإلكترونية الاقتصادية، يتميز بمزيد من الميزات، وتحكم أكبر، وقاعدة مفتوحة يُمكن لأي شخص البناء عليها.
عرض ملفات EPUB 2 و3
يقوم الجهاز بتحليل ملفات EPUB 2 و3، وتطبيق CSS المدمج، وتنسيق الفصول بالخط والحجم والهوامش التي تختارها. يتم تخزين الصفحات مؤقتًا على بطاقة SD عند فتحها لأول مرة، مما يجعل إعادة فتحها في كل مرة شبه فورية.
خيارات تخصيص الخطوط
يتضمن الجهاز خطي Noto Serif وNoto Sans مدمجين، بالإضافة إلى أي خط يتم تحميله من بطاقة SD. يمكنك ضبط الحجم والتباعد والهوامش والوصلات والمحاذاة والتنعيم.
نقل ومزامنة عبر Wi-Fi
يشغل الجهاز خادم تحميل عبر Wi-Fi. يمكنك سحب ملفات EPUB من أي متصفح، وإرسالها مباشرة من Calibre، والاحتفاظ بمكانك على جميع الأجهزة باستخدام مزامنة KOReader.
إضافة إشارة مرجعية لأي فقرةاضغط مطولًا على زر التأكيد في أي مكان لإضافة إشارة مرجعية. يحتفظ كل موضع محفوظ برقم الصفحة ونسبة القراءة، مما يتيح لك العودة إلى سطر مفضل بنقرة واحدة.
قراءة مركزة
يُبرز بداية كل كلمة لتوجيه نظرك وتحديد سرعة قراءتك، مع تنعيم الحواف بتدرجات الرمادي وعرض مُجزأ لتصفح سريع وسلس للصفحات.
يدعم لغتك
تصميم كامل من اليمين إلى اليسار للغتين العبرية والعربية، بالإضافة إلى قوائم مترجمة بالإسبانية والفرنسية والألمانية والإيطالية والبرتغالية والروسية.

المزيد

الشبكات والإنترنت: من المبادئ الأساسية

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

المزيد

إرشادات واجهة سطر الأوامر

في ثمانينيات القرن الماضي، إذا أردتَ استخدام حاسوب شخصي لإنجاز مهمة ما، كان عليك معرفة ما تكتبه عند مواجهة C:\> أو ~$. كانت المساعدة تأتي على شكل كتيبات سميكة ذات غلاف حلزوني. كانت رسائل الخطأ مبهمة. لم يكن هناك موقع مثل Stack Overflow لإنقاذك. لكن إن كنت محظوظًا بما يكفي لامتلاك اتصال بالإنترنت، كان بإمكانك الحصول على المساعدة من Usenet، وهي مجتمع إنترنت مبكر يضم أشخاصًا آخرين كانوا محبطين مثلك تمامًا. كان بإمكانهم مساعدتك في حل مشكلتك، أو على الأقل تقديم بعض الدعم المعنوي والتضامن.
بعد أربعين عامًا، أصبحت الحواسيب متاحة للجميع بشكل أكبر، غالبًا على حساب تحكم المستخدم النهائي على مستوى النظام. في العديد من الأجهزة، لا يوجد وصول إلى سطر الأوامر على الإطلاق، ويعود ذلك جزئيًا إلى تعارضه مع مصالح الشركات التي تُفضّل الأنظمة المغلقة ومتاجر التطبيقات.
معظم الناس اليوم لا يعرفون ما هو سطر الأوامر، فضلًا عن سبب رغبتهم في استخدامه. كما قال رائد الحوسبة آلان كاي في مقابلة عام ٢٠١٧: "لأن الناس لا يفهمون ماهية الحوسبة، يعتقدون أنهم يمتلكونها في هواتفهم الذكية، وهذا الوهم لا يقل سوءًا عن وهم أن لعبة 'Guitar Hero' تُضاهي الغيتار الحقيقي".
ليس المقصود بـ"الغيتار الحقيقي" الذي يتحدث عنه كاي هو واجهة سطر الأوامر (CLI) - ليس تمامًا. كان يتحدث عن طرق برمجة الحواسيب التي تُوفر قوة واجهة سطر الأوامر وتتجاوز كتابة البرامج في ملفات نصية. هناك اعتقاد سائد بين أتباع كاي بضرورة التحرر من قيود البرمجة النصية التي نعيشها منذ عقود.
من المثير تخيل مستقبل نبرمج فيه الحواسيب بطريقة مختلفة تمامًا. حتى اليوم، لا تزال جداول البيانات هي لغة البرمجة الأكثر شيوعًا، وتنتشر حركة البرمجة بدون كتابة أكواد بسرعة في محاولة منها لتلبية الطلب المتزايد على المبرمجين الموهوبين.
ومع ذلك، لا تزال واجهة سطر الأوامر، بقيودها القديمة وخصائصها غير المفهومة، هي الجانب الأكثر تنوعًا في الحاسوب. يُتيح لك هذا النظام كشفَ خبايا النظام، والاطلاع على ما يجري فعلاً، والتفاعل معه بأسلوب إبداعي بمستوى من التطور والعمق لا تُوفّره واجهات المستخدم الرسومية. وهو مُتاح على معظم أجهزة الكمبيوتر المحمولة، لأي شخص يرغب في تعلّمه. يُمكن استخدامه بشكل تفاعلي، أو بشكل آلي. كما أنه لا يتغير بالسرعة نفسها التي تتغير بها أجزاء النظام الأخرى. تكمن القيمة الإبداعية في استقراره.
لذا، ما دام هذا النظام مُتاحًا، علينا أن نسعى إلى تعظيم فائدته وسهولة الوصول إليه.
لقد تغيّر الكثير في طريقة برمجة أجهزة الكمبيوتر منذ تلك الأيام الأولى. كان سطر الأوامر في الماضي مُصمّمًا ليُلائم الآلة في المقام الأول: لم يكن أكثر من مُحاكاة تفاعلية (REPL) فوق منصة برمجة نصية. ولكن مع ازدهار لغات البرمجة التفسيرية للأغراض العامة، تقلّص دور البرامج النصية. أصبح سطر الأوامر اليوم مُصمّمًا ليُلائم المستخدم في المقام الأول: واجهة مستخدم نصية تُتيح الوصول إلى جميع أنواع الأدوات والأنظمة والمنصات. في الماضي، كان المُحرّر موجودًا داخل الطرفية - أما اليوم، فالطرفية غالبًا ما تكون جزءًا من المُحرّر. وقد شهدنا انتشارًا واسعًا لأوامر الأدوات المتعددة الشبيهة بـ Git. أوامر داخل أوامر، وأوامر عالية المستوى تُنفّذ سير عمل كامل بدلًا من وظائف مُفردة.
انطلاقًا من فلسفة يونكس التقليدية، ورغبةً منا في تشجيع بيئة سطر أوامر أكثر سهولةً ومتعةً، واستنادًا إلى خبراتنا كمبرمجين، قررنا أن الوقت قد حان لإعادة النظر في أفضل الممارسات ومبادئ التصميم لبناء برامج سطر الأوامر.
فلتحيا سطر الأوامر!

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

المزيد

أصبح تطبيق Chatto الآن مفتوح المصدر!

يهدف تطبيق Chatto إلى أن يكون تطبيق الدردشة الجماعية الذي ستستمتع باستخدامه حقًا. ربما تعرف التطبيق الذي يُنطق اسمه مثل "knack" أو "beams" أو حتى "this gourd".يشبه Chatto هذه التطبيقات تمامًا، إلا أنك ستُعجب بحجمه الصغير وسرعته الفائقة، بالإضافة إلى كونه مفتوح المصدر، ويمكنك استضافته بنفسك مجانًا! (قد يبدو هذا غريبًا، لكن عالم تطبيقات الدردشة مفتوحة المصدر أصبح غريبًا جدًا في نواحٍ عديدة!)
صُمم هذا التطبيق ليكون سهل الاستضافة الذاتية على بنيتك التحتية الخاصة. في أبسط صوره، ما عليك سوى تشغيل الملف التنفيذي، وانتهى الأمر. حتى أنه يوفر واجهة مستخدم خاصة به!
يتميز التطبيق باستهلاكه المنخفض للموارد، وربما يمتلك أسرع واجهة مستخدم استخدمتها في تطبيق مماثل. يولي التطبيق أولوية قصوى لحماية البيانات والخصوصية، حيث تُشفّر جميع البيانات الشخصية وبيانات الدردشة بالكامل أثناء التخزين باستخدام مفاتيح خاصة بكل مستخدم تُحذف نهائيًا عند حذف المستخدم لحسابه.
يدعم كل خادم Chatto مجتمعًا واحدًا فقط، دون أي تبادل للبيانات بين الخوادم، أو أي تتبع أو تحليل من جهات خارجية. إذا كنت ترغب في التواجد على عدة خوادم في وقت واحد، فسيتصل التطبيق بها جميعًا مباشرةً. إذا كنت ترغب في استضافة مجتمعات متعددة، فما عليك سوى تشغيل عدة عمليات Chatto. بكل بساطة!

المزيد

نهاية العالم الزائفة Pseudpocalypse

إليكم فرضية: إذا نشرتَ كمية كبيرة من النصوص على الإنترنت بأسماء مستعارة، يُمكن ربط هذه الهويات باستخدام النص نفسه فقط. هذا ممكن (حسب ظني) بفضل "البصمة" الإحصائية التي تتركها في كل ما تكتبه.
تخيّل موقعًا إلكترونيًا يُمكنك من خلاله لصق نص جديد كتبه أحدهم للتو. في المقابل، يُوفّر الموقع روابط لجميع النصوص التي نشرها هذا الكاتب على الإطلاق، مهما كان اسمه. ليس مثاليًا، ولكنه جيد جدًا. على حد علمي، لا يوجد موقع كهذا - على الأقل ليس على الإنترنت العام. لكني أظن أنه ممكن وسيُصبح سهلًا قريبًا. سيُشكّل هذا بعض الصعوبة للتدوين بأسماء مستعارة.
ملاحظة: كتبتُ معظم هذه المقالة في منتصف عام 2025، وبعدها تركتها جانبًا لمدة عام كامل، مُنكبًّا على تعديل عبارات نظرية لن يقرأها أحد منكم.١
في هذه الأثناء، أصبحت منصات الذكاء الاصطناعي أكثر دقة في تخمين هوية المؤلفين من النصوص. (بمجرد قراءة أول ألف كلمة من مسودة هذا المنشور، يعرف كلود 4.8 أنني أنا). مع ذلك، أعتقد أننا في البداية فقط. أتوقع أن نرى كتّابًا مغمورين بشكل متزايد يتم التعرف عليهم من خلال أجزاء نصية صغيرة جدًا. أتوقع أن ينجح هذا حتى عندما يكتب الناس بأسلوب مختلف أو عن مواضيع غير ذات صلة. وأتوقع أن كل ما كتبته تحت أي اسم مستعار سيرتبط قريبًا باسمي الحقيقي.
التخمين الأقوى هو أننا نتجه نحو نوع من نهاية العالم للأسماء المستعارة. ربما، في المستقبل، إذا تفاعلت مع العالم من خلال أي قناة ذات نطاق ترددي عالٍ، فستكشف عن هويتك. لنفترض أنك ترتدي قناعًا في الأماكن العامة وتتحدث فقط عن طريق التلفظ بصوت خافت في جهاز تغيير الصوت. لا بأس، سيتم التعرف عليك من خلال شكل جسمك أو مشيتك أو بصمتك الكيميائية. أو لنفترض أنك لا تحب أن يتم تتبع سيارتك في كل مكان، لذلك تتوقف عن حمل الهاتف وتقنع المشرعين بطريقة ما بحظر لوحات الترخيص. لا مشكلة، ستظل سيارتك قابلة للتتبع من خلال خدوش صغيرة أو أصوات تنبيه مميزة من المحرك. أو لنفترض أنك لا ترغب في أن يتم تتبعك على الإنترنت، لذا قمت بتأمين ملف تعريف متصفحك، واشتريت فقط باستخدام عملة مونيرو، واتصلت عبر سلسلة من ثلاث شبكات VPN. لا بأس بذلك. ستظل هويتك قابلة للتحديد من خلال طريقة تحريك إصبعك أثناء تصفحك للصفحة. كلنا فريدون للغاية، وحدود المعلومات النظرية تقترب منا.

المزيد

أصبح برنامج Microsoft Comic Chat الآن مفتوح المصدر

برنامج الدردشة الذي قدّم خط Comic Sans للعالم متوفر الآن على GitHub.
يسرّنا اليوم الإعلان عن إطلاق برنامج Microsoft Comic Chat مفتوح المصدر، وهو برنامج الدردشة الذي حوّل المحادثات تلقائيًا في بروتوكول IRC إلى لوحات قصصية مصورة بشخصيات ورسوم متحركة وفقاعات كلام وتعبيرات وجه، وساهم في تعريف العالم بخط Comic Sans المميز.
نعم، إنه Comic Sans نفسه. صمّمه في الأصل فنسنت كونار، مصمم الخطوط في مايكروسوفت، عام ١٩٩٤، ووجد Comic Sans مكانه الأمثل في Comic Chat، حيث انسجم أسلوبه غير الرسمي، الذي يُحاكي الكتابة اليدوية، تمامًا مع فقاعات الكلام في البرنامج.
بالنسبة للكثيرين، يُعدّ برنامج Comic Chat أثرًا حنينيًا من بدايات الإنترنت، حين انتقلنا من تقنيات مثل Telnet وUsenet وIRC إلى شبكة الويب المرئية التي نتمتع بها اليوم. أما بالنسبة لآخرين، فهو جزء أسطوري من تاريخ مايكروسوفت، لم يسمعوا عنه إلا في القصص والصور والنقاشات حول الطباعة. الآن، يُمكن للمطورين والمؤرخين وهواة الحوسبة القديمة، وكل من يُقدّر فكرةً غير تقليدية، استكشاف شفرة المصدر بأنفسهم.
رؤية مختلفة للتواصل عبر الإنترنت
اليوم، اعتدنا على تطبيقات المراسلة التي تتضمن تفاعلات، وملصقات، وصور متحركة، وصور رمزية، وفيديوهات، ومحتوى مُولّد بالذكاء الاصطناعي. لكن في منتصف التسعينيات، كانت محادثات الإنترنت عبارة عن صفحات نصية متحركة.
بدلاً من عرض الرسائل كنص عادي، قدّم تطبيق "كوميك تشات" المشاركين كشخصيات مُصوّرة. كانت المحادثات تجري في لوحات قصصية، مع فقاعات كلام، وتعبيرات، وإيماءات مُولّدة مما يكتبه المستخدمون. فإذا كتب أحدهم "أعجبني هذا"، قد تُشير الشخصية إلى نفسها. وإذا أوحى النص بالغضب، فقد تعبس الشخصية أو تعقد ذراعيها. كان التطبيق غريب الأطوار، وطموحًا، وفوضويًا أحيانًا، ومُتطلّعًا للمستقبل بشكلٍ مُدهش.
العديد من الأفكار التي نعتبرها اليوم بديهية في التواصل عبر الإنترنت، يُمكن أن تُعزى روحها إلى تجارب مثل "كوميك تشات".

مصدر الخبر

لا يمكنك اختبار الوحدات من أجل الذوق

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

يعرض التطبيق تقدمك على خرائط تفاعلية، مما يتيح للمستخدمين استكشاف أماكنهم بأنفسهم. لطالما رغبت في إثراء الخرائط بمعالم سياحية أو مواقع تاريخية مثيرة للاهتمام. بالنسبة للمسارات التي أعرفها، يمكنني إنشاء قوائم مماثلة بنفسي، لكن هذا لا ينطبق على المسارات التي تمتد عبر بلدان لا أعرفها. لذلك، بدأت البحث عن مصدر بيانات لنقاط الاهتمام التي يمكنني بناء نظام بيانات عليها. خلال هذه الرحلة، واجهت تحديات تتعلق بالذوق والتحيزات، وكافحت حالة هلوسة. ظننتُ في البداية أن الذكاء الاصطناعي سيكون الميزة الأساسية، لكنه انتهى به الأمر مجرد عنصر داعم إلى جانب الإشارات الأخرى وأساسيات معالجة البيانات.
مجموعة البيانات والأدوات#
كانت GeoNames نقطة انطلاق بديهية، فهي مصدر بيانات شامل يضم مواقع وفئات وروابط. يمكن تحميل مجموعة البيانات الكاملة وهي مرخصة بموجب رخصة المشاع الإبداعي. لذا، شرعتُ مع صديقي كلود في بناء مسار بيانات لتحويل البيانات الخام إلى نقاط اهتمام ذات صلة لمستخدمي In the Long Run.
استخدمنا لغة بايثون للبرمجة (لأنها تتمتع بدعم مكتبي ممتاز للمهام المطلوبة)، وخزنّا البيانات المُعالجة محليًا كملفات Apache Parquet، واستخدمنا DuckDB كطبقة استعلام.1 كانت هذه تجربتي الأولى مع كل من Parquet وDuckDB، لكنني وجدتُ سهولة استخدام كليهما، وقد عرّفني كلود على ميزاتهما خطوة بخطوة (وكان معظم العمل على DuckDB باستخدام لغة SQL التي أتقنها جيدًا). ​​عمومًا، أجد أن إضافة أداة أو اثنتين جديدتين أو تقنيتين إلى أي مشروع هي أفضل طريقة للتعلم. إذا كانت جميع التقنيات جديدة عليك، فسيكون تعلمها صعباً للغاية وقد يجعلك تتخلى عن المشروع تماماً. تُغيّر برامج الذكاء الاصطناعي هذه المعادلة إلى حد ما، ولكن حتى مع ذلك، أجد أن إلمامي بمعظم التقنيات المستخدمة يُتيح لي توجيه البرنامج بشكل أفضل واتخاذ قرارات مدروسة بدلاً من اتباعه بشكل أعمى.

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

المزيد