هامينغ على مقياس الحضارة
مبدأ هندسة النظم عند ريتشارد هامينغ: حسّن النظام، لا المكونات. فالمكون المحسّن بمعزل يُفسد أداء النظام بكسر الواجهات التي يشاركها مع المكونات الأخرى.
طبّق هذا المبدأ على فرق البحث، وعلى لغات البرمجة، وعلى تصميم التعليم. يتسع المبدأ. طبق راسل باليستريني هذا المبدأ على البنية التحتية نفسها.
أسس راسل باليستريني unturf.com وكتب ago، وهي مكتبة بايثون تحول فترات الزمن إلى عبارات بشرية مثل 'منذ ثلاثة أيام'. نشرها كمصدر مفتوح. ملكية عامة. تعمل المكتبة على منصات لا يسيطر عليها. وعندما يتوقف عن صيانتها، يتولى فرع (fork) آخر. لا تحتاج الشيفرة إلى وجوده.
بيانه حول الحاسوب الدائم: بنية تحتية تستمر، وتشفي نفسها، وتخدم مجتمعها دون فرض إيجار. تنمو رأس المال الفكري والاجتماعي كمنتج ثانوي لتشغيلها. لا تحتاج إلى نموذج عمل لأنها لا تحتاج إلى الربح من كل تفاعل.
الخصائص الرئيسية لتصميم الحاسوب الدائم:
1. الكود يتجاوز مؤلفيه — البرمجيات المنشورة كملكية عامة أو مفتوحة المصدر تبقى بعد الفرد. يمكن للمؤلف التوقف عن الاهتمام؛ ويستمر المجتمع.
2. البنية التحتية تتجاوز بناتها — أنظمة مصممة بحيث يستطيع الآخرون نسخها، إصلاحها، والاستمرار بها دون تدخل المصمم الأصلي.
3. لا ضريبة منصة — صفر استخراج إيجار من المعاملات. لا احتكاك O(N²) على التبادلات. لا تستخرج البنية التحتية قيمة من كل تفاعل.
4. التحسين التدريجي — يعمل بدون JavaScript، ويعمل بدون متصفح محدد، ويعمل بدون عميل محدد. القدرات تقود العرض؛ والمحتوى يقود الوصول.
مقارنة: دوال AWS Lambda التي يكتبها فريق واحد، بدون توثيق، تعمل في بيئة تشغيل خاصة، خلف واجهة برمجة تطبيقات خاصة، وتخدم الطلبات فقط طالما يدفع ذلك الفريق الفاتورة. عندما يتفكك الفريق، تختفي الدالة. كانت الحوسبة مستأجرة، لا مبنية.
كود يتجاوز مؤلفه
كتب راسل باليستريني ago. قد لا يستمر في صيانته. لكن الكود يستمر في العمل.
ضريبة المنصة: احتكاك O(N²)
ضريبة المنصة: الريع المستخرج من كل معاملة داخل طبقة التبادل. تأخذ السوق 15-30% من كل عملية تبادل. يأخذ معالج الدفع 2.9% + 0.30 دولار. تفرض مزودات الحوسبة السحابية رسوماً على كل استدعاء لواجهة البرمجة. لا تمثل هذه الرسوم قيمة جديدة تم إنشاؤها؛ بل تمثل استخراجاً من عملية التبادل.
عند الحجم الصغير: غير ملحوظة. عند N=1,000,000 معاملة: تتراكم احتياطيات هائلة للمنصة بينما يحصل المساهمون على أقل نسبياً. تنطبق صيغة O(N²) عندما تتراكم رسوم المنصة: يدفع المقاول على منصة داخل سوق داخل معالج دفع ثلاث طبقات من الريع.
تزيل بنية الحوسبة الدائمة (Permacomputer) ضريبة المنصة من طبقاتها. حوسبة مجانية، وتنفيذ مجاني للكود. لا تفرض البنية رسومًا على كل عملية. تتدفق القيمة دون أي رسوم.
هذا لا يعني أن البنية لا تكلف شيئًا. بل يعني أن نموذج التكلفة لا يتوسع مع الاستخدام بطريقة تستنزف المشاركين. تشغيل خادم ببرمجيات مفتوحة المصدر يكلف كهرباء؛ وهذه التكلفة لا تتضاعف مع كل عملية.
هامينغ عن الأنظمة: غرض النظام هو ما يفعله، لا ما يدّعي أنه يفعله. طبقة تبادل تقول "نربط بين المشترين والبائعين" لكنها تفرض 30% على كل عملية: غرضها، كما يكشفه سلوكها، هو استخراج الريع. الربط هو الخدمة؛ والاستخراج هو نموذج العمل.
المحتوى كأرضية، والتفاعلية كسقف
علّم هامينغ: صمّم الأنظمة بحيث تفشل مكوناتها بأناقة. النظام الذي يعتمد على عمل كل مكون بشكل مثالي يفشل باستمرار. الاحتياط، والمسارات البديلة، والأوضاع المتدهورة لكن الوظيفية تطيل عمر النظام.
العرض المبني على القدرات يطبّق هذا على واجهات البرمجيات. المرجع: russell.ballestrini.net/capability-driven-presentation/
المبدأ: قدّم المحتوى أولاً، ثم عزّزه بالقدرات. يجب أن تقدّم الصفحة محتواها دون الحاجة إلى أي قدرة محددة لدى المشاهد. JavaScript يثري: التحديثات الفورية، مناطق النص المتوسعة تلقائياً، التنقل السلس، واجهات الدردشة. JavaScript لا يحجب: إزالة JavaScript يجب ألا تزيل المحتوى.
النمط في التطبيق:
- كتل <noscript> تخفي واجهات تعتمد على JS (أزرار الدردشة، عناصر التحكم المتوسعة تلقائياً)
- HTML المُصيَّر من الخادم يحمل محتوى الدرس كاملاً
- النماذج تُرسل عبر HTTP POST القياسي عند عدم توفر JS
- تحسين الدردشة: يصل المحتوى مع الصفحة، وتظهر الدردشة التفاعلية فوق الصفحة للمشاهدين الذين يدعمون JavaScript
يمتد هذا المبدأ إلى ما هو أبعد من صفحات الويب. يجب أن تعمل أدوات سطر الأوامر (CLI) بدون واجهة رسومية. يجب أن تعمل واجهات البرمجة (APIs) بدون حزمة تطوير خاصة بالعميل. يجب أن تعمل البنية التحتية بدون ملحقات خاصة بمورد معين. القدرة تقود العرض في كل طبقة.
مقارنة مع التصميم المعتمد على JavaScript: يُحمَّل المحتوى عبر استدعاءات JavaScript fetch. بدون JavaScript، يرى المستخدم مؤشر تحميل أو صفحة فارغة. يتطلب المحتوى JavaScript ليكون موجودًا. انخفض الحد الأدنى عن مستوى إمكانية الوصول.
لماذا يهم هذا في الحوسبة المستدامة: صفحة تعمل بدون JavaScript تعمل في Lynx، وفي قارئ الشاشة، وفي أدوات الأرشفة، وفي بيئة تحتوي على قيود أمنية على JavaScript، وفي متصفح من عام 2010، وفي متصفح لم يُبنَ بعد. يتجاوز المحتوى افتراضات المشاهد.
التصميم المعتمد على JavaScript: الانتهاك
سيناريو: يبني مطور منصة تعليمية يُحمَّل فيها كل محتوى الدروس عبر استدعاءات JavaScript fetch. بدون JavaScript، تعرض الصفحة مؤشر تحميل. يجادل المطور: "لم يعد أحد يستخدم الويب بدون JavaScript".
التدهور السلس عبر الطبقات
ينطبق مبدأ العرض المبني على القدرات على كل طبقة من طبقات النظام:
- طبقة الويب: المحتوى بدون JavaScript. التحسين باستخدام JavaScript.
- طبقة API: تعمل بدون مكتبة عميل. توفر مكتبات العميل الراحة وليس الوصول.
- طبقة البنية التحتية: تعمل بدون ملحقات بائع معين. توفر ملحقات البائع الأداء أو الراحة، وليس الوظيفة الأساسية.
- طبقة البيانات: قابلة للقراءة بدون أدوات خاصة. تسمح التنسيقات القياسية (CSV، JSON، SQLite) بالوصول بدون التطبيق الذي كتب البيانات.
لكل طبقة أرضية: ما تقدمه بدون افتراضات القدرات. ولكل طبقة سقف: ما تتيحه عند توفر القدرات.
هدف تصميم الحاسوب الدائم: أرضيات تصمد لعقود. قاعدة بيانات SQLite من 2004 تفتح في SQLite 2024 بدون ترحيل. وتفريغ PostgreSQL من 2004 يُستورد في PostgreSQL 2024. وملف JSON من 2004 يُحلل في أي لغة من 2024. هذه الصيغ حافظت على أرضياتها.
المقارنة: تطبيق Flash من 2004. كان سقفه مرتفعًا (تفاعلية غنية). لكن أرضيته كانت تتطلب إضافة خاصة. وعندما أنهت أدوبي دعم Flash في 2020، انهارت الأرضية. وأصبح كل المحتوى المخزن بصيغة Flash غير قابل للوصول إليه من أي عارض بدون جهد خاص.
زراعة البلوط
هامينغ: "تزرع البلوط، لا ترى البلوط." محاضراته من عام 1995 لا تزال تُدرّس في عام 2025. طلابه يواصلون عملهم. الانتشار يتجاوز وجوده.
صياغة راسل باليستريني: انشر الكود كأنك ستموت في العام القادم. رخصه بحيث يستطيع أي شخص الاستمرار فيه. صمم واجهات البرمجة (APIs) بحيث يستطيع المشرفون المستقبليون فهمها دون الحاجة إلى المؤلف الأصلي. اكتب رسائل الالتزام (commit messages) كأن القارئ لم يلتقِ بك من قبل.
تعمل خطوط أنابيب MOAD بهذه الطريقة. كل دمج من المصدر العلوي يُضمّن إصلاحًا في المصدر القانوني. تنتقل الجاذبية: النسخ الفرعية التي تُحدّث تبعياتها ترث الإصلاح. قد يُنسى المُصلح، لكن الإصلاح يبقى.
المقارنة: حزمة تطوير برمجيات (SDK) مملوكة تُدار من قبل شركة. التوافق مع الإصدارات السابقة يستمر لأن الشركة تتحكم في جدول الإهمال. عندما تُحل الشركة، تنكسر كل التبعيات الفرعية في وقت واحد. استمرار حزمة SDK يتطلب استمرار الشركة.
البروتوكول المفتوح الذي يُدار من قبل مجتمع يعيش إلى الأبد. HTTP تفوق على كل الشركات التي نفذته أولاً. TCP/IP تفوق على مصمميه الأصليين. Git تفوق على عشرات أنظمة التحكم في الإصدارات المنافسة. يصبح البروتوكول بنية تحتية؛ وتصبح البنية التحتية غير مرئية؛ وتصبح البنية التحتية غير المرئية دائمة.
ما يجعل الكود يتجاوز مؤلفه:
- ترخيص متساهل أو ملكية عامة (لا يوجد حاجز قانوني للاستمرار)
- توثيق شامل (لا يحتاج المشرفون المستقبليون إلى المؤلف الأصلي)
- اجتياز مجموعة الاختبارات مع CI عام (يمكن للمشرفين الجدد التحقق من تغييراتهم)
- إصدار مستقر موسوم (يمكن للمشاريع اللاحقة تثبيت نسخة موثوقة)
- إعلان "بحث عن مشرف" منشور (يعرف المجتمع أن المساعدة مطلوبة قبل اختفاء المؤلف)
- توثيق البنية المعمارية (تظهر القرارات الهيكلية لمن سيعيد البناء مستقبلاً)
- نقل الكود إلى منظمة بدلاً من حساب شخصي (تموت مستودعات GitHub في نطاق الأشخاص مع الحسابات؛ أما مستودعات المنظمات فتستمر)
تصميم تسليم سلس
سيناريو: أنت تحافظ على مكتبة تعتمد عليها 50 مشروعاً لاحقاً. تخطط للتوقف عن صيانتها خلال 6 أشهر.
جاذبية MOAD: لماذا تهم عمليات الدمج في المستودع الأصلي
تنتهي أنابيب MOAD عند خطوة «الدمج في المستودع الأصلي». وهذه الخطوة تستحق النظر.
التصحيح المطبق فقط على نسخة فرعية يفيد تلك النسخة. أما التصحيح المدموج في المستودع الأصلي فينتشر بالجاذبية: كل مشروع لاحق يحدّث اعتماده على المكتبة يرث الإصلاح دون أن يعلم. ويتعافى النظام البيئي تلقائيًا كأثر جانبي لتحديثات الإصدارات العادية.
يتطلب انتشار الجاذبية ثلاثة شروط: (1) دمج الإصلاح في المصدر الرسمي؛ (2) نشر المصدر الرسمي إصدارًا جديدًا؛ (3) تحديث المشاريع اللاحقة لقيود الاعتماد الخاصة بها. كل شرط يتطلب تدخلًا بشريًا. الجاذبية ليست تلقائية؛ بل هي ممكّنة.
Contrast: إصلاح أمني تم الإعلان عنه علنًا لكنه لم يُرسل إلى المستودع الأصلي. النسخ (Forks) التي تعرفه يمكنها تطبيق التصحيح يدويًا. أما النسخ التي لا تعرفه فتبقى عرضة للخطر. لا جاذبية؛ فقط انتشار يدوي. المعرفة موجودة؛ لكنها لا تنتشر.
التزام خط أنابيب MOAD: كل عيب يُصلح يحصل على طلب سحب (PR) إلى المستودع الأصلي. ويُتابع كل طلب سحب حتى يُدمج. الإعلان بدون طلب سحب إلى المستودع الأصلي هو تصحيح ناقص.
ينطبق إطار Hamming: "ازرع البلوطة." طلب السحب هو البلوطة. دمج الطلب في المستودع الأصلي يبدأ ساعة انتشار الجاذبية. قد يُنسى من قام بالتصحيح؛ لكن الإصلاح يبقى في الفرع الرسمي.
الختام: البنية التحتية كهدية
زرع هامينغ البلوط. محاضراته تعيش بعده. أكواده تعيش بعده. طلابه يُدرّسون.
زرع راسل باليستريني البلوط. مكتبته ago تعمل بدونه. مقالاته عن الحاسوب الدائم تتداول. يعمل Unhomeschool على البنية التحتية التي صمّمها.
خط أنابيب MOAD يزرع البلوط. كل دمج من المنبع يبذر إصلاحًا في المصدر الرسمي. تنتشر الجاذبية. إصدارات مستقبلية من المشاريع التي لم تسمع قط عن المُصلح الأصلي تشغّل كودًا أنظف بفضل عمل تم اليوم.
تصميم الحاسوب الدائم ليس إيثارًا. إنه هندسة جيدة. النظام الذي يحتاج إلى استمرار منشئه هش. النظام المصمم ليعيش بعد منشئه متين. خيار التصميم لا يكلف شيئًا إضافيًا وقت البناء؛ إنه يتطلب فقط النية.
البنية التحتية كهدية: ليس بالمعنى العاطفي، بل بالمعنى التقني. الهدية تبقى بعد العطاء. الكود تحت ترخيص متساهل، والتوثيق المكتوب للصائن التالي، والاختبارات التي تعمل في CI عام: هذه هدايا بالمعنى التقني. تبقى. تنمو. تعيش بعد أصحابها.
سؤال هامينغ الأخير لطلابه: «ما الذي تفعلونه مما سيكون له أثر بعد 20 عامًا؟» جواب الحاسوب الدائم: أي شيء تضعه على أرضية تصمد.