القصة الأولى. رسائل قاتلة
[
الأصل ]
ذات مرة ، حصل
جورج على وظيفة في مكتب Initech. استأجرت الشركة للتو عدة طوابق في مبنى المكاتب القديم الذي انتقل مؤخرًا من فئة التراجع الحضري إلى المقاهي الأنيقة في الطابق الأرضي ورائحة تلميع الأحذية والمفروشات الجلدية الطازجة على أي شخص آخر.
لقد كانت مساحة شاسعة ، وكان جورج في تلك المرحلة من حياته المهنية عندما كان من المفترض أن يكون لديه مكتب منفصل مطل على الممر.
كانت مهمته الأولى إصلاح المشكلة في إصدار Mac من برنامج الشركة. بدا الأمر مثالياً على Windows ، ولكن ظهرت أخطاء تجسيد الخط على OSX. من الصعب العثور على هذا الخطأ ، لكن جورج ربما كان محققًا في حياته السابقة ، لذلك كان مستعدًا لهذا الاختبار.
كانت الفكرة الأكثر أهمية هي تاريخ التحكم في الإصدار. على مدار السنوات الثلاث الماضية ، عمل خمسة مطورين على المنتج. يبدو أن كل واحد منهم كان في الشركة لمدة أربعة أشهر ، ثم غادر. لعدة أشهر مضت دون أي تغييرات ، ثم جاء مطور جديد وتكرر الدورة مرة أخرى. كما اكتشف جورج ، ظهرت أسماءهم طوال الوقت عندما حاول اكتشاف وظائف أخطاء المنتج وعمله وأسبابه.
نظرًا لأن التطبيق كان عبر نظام أساسي ، فقد قام المطورون بتنفيذ محمل الخط وجهاز عرض الخطوط الخاصين به. على الأقل هذا ما فكر به. البنية الداخلية للخطوط شيء خطير ومربك ، وهذا ينعكس في الكود. كما أنه يعكس حقيقة أن العديد من المبرمجين ، الذين لم يحافظوا على سلامتها ، عملوا عليها واحدة تلو الأخرى.
لقد كانت فوضى .
في المدونة ، رأى جورج مجموعة من الجوانب التي كانت بلا شك سيئة - مكالمات غير آمنة إلى
memcpy ،
malloc دون حساب
free ، مؤشر ، والتي عملت على الثقة أكثر من المنطق. ولكن على ما يبدو ، لم يكن أي من هذا هو مصدر مشكلة الخط.
بالإحباط ، قرر جورج الاقتراب منها من الجانب الآخر. على الشاشات التي تحتوي على أخطاء العرض ، كان هناك دائمًا خط واحد أو خطان متخصصان. قام جورج بتحميل الخطوط إلى أدوات فحص الخط من Adobe و Microsoft ، وشاهد تقارير عن مجموعة كاملة من الأخطاء.
رمز تنزيل الخط كان سيئًا ، لكن الخطوط نفسها كانت أسوأ. بعد تحديد المشكلة ، أخبر جورج رئيسه أن الخطوط تحتاج إلى إصلاح. نقله الرئيس إلى رئيس الشركة.
في اليوم التالي ، اتصل رئيسه بجورج: "الرئيس يريد مقابلتك ، على
وجه السرعة ".
كان مكتب الرئيس أشبه بقاعة مؤتمرات ، ولكن بدون طاولة مؤتمرات. غرفة طويلة ، على جانب واحد طاولة ونوافذ في جميع أنحاء الجدار وإطلالة على النهر. كان الرئيس الغاضب يجلس على مكتبه.
"ما الخطأ فيكما؟ جورج ، لقد كنت هنا أقل من أربعة أشهر ، وتبدد بالفعل وقتي - هل تبدد
أموالي على فكرة مجنونة حول مشكلة في
الخطوط ؟ "
"لكنه كذلك. أستطيع أن
أظهر ".
"في إصدار Windows ، يعمل الخط بشكل جيد! يجب أن تكون المشكلة في الجحيم. أنا أعرف مقدار ما تدفع لك. ربما ينبغي عليّ أخذ آلة حاسبة وحساب تكلفة الشركة على مطاردة الأشباح هذه؟ " قام بلكم الطاولة بحيث قفزت الحاسبة بجانب لوحة المفاتيح قليلاً.
استمرت الاتهامات ، لكن جورج عرف بالفعل ما سيفعله بعد الاجتماع. بحلول نهاية اليوم ، عاد بشارته وحاسوبه المحمول إلى جانب إعلان استقالة وقح وصادق.
بعد إجازة قصيرة غير مدفوعة الأجر ، حصل جورج على وظيفة جديدة. مرت السنوات ، وبدأ بالفعل في نسيان الوقت الذي يقضيه في Initech. لكن في أحد الأيام رأى رسالة حول إصدار تصحيح هام لضعف Microsoft Windows. كما اتضح فيما بعد ، قد يتسبب "رمز معالجة الخطوط لجهة خارجية" في تنفيذ تعليمات برمجية عشوائية في بعض مكتبات Windows. بعد قليل من البحث ، أكد جورج حداده: كان رمز Initech هو الذي تسبب في المشكلة. علاوة على ذلك ، تم إصدار آخر إصدار ثنائي من Initech في عام 2008 - بعد
شهر من مغادرته الشركة.
القصة الثانية. العمل على العملية ، وكذلك تحتها وفوقها
[
الأصل ]
عندما حصل
كيفن على وظيفة في Townbank في أواخر الثمانينيات ، كان في نفس الموقف مثل الآلاف من المبرمجين الجدد الذين تم الاستغناء عنهم قبل وبعد: لم يقم مبرمج الشركة بكتابة الكود - إنه بحاجة إلى الالتزام بالعملية.
تختلف العملية عن الوصايا الصارمة لديانات العالم فقط في أن مهمتها هي الحفاظ على سلامة الكود. المجد للعملية ، قد يكون مباركاً ، والعملية جيدة ، ويجب عليك دائمًا الامتثال لهذه العملية ، والأهم من ذلك ، أن العملية مفيدة لك!
بالنسبة لمعظم المطورين ، العملية ليست سيئة للغاية. تحتاج فقط إلى التعود على ذلك. املأ النموذج ، احصل على الموافقة ، سجل خطة اختبار ، اكتب وثائق التجميع - كل هذا صحيح. ومع ذلك ، كما اكتشف كيفن قريبًا ، كانت هناك عمليات في Townbank لم يستطع المحاربين القدامى ولا المبتدئين التكيف معها.
عامل شيفا
كانت مهمة Kevin الأولى هي العمل في مجموعة شاركت في أكبر مشروع في ذلك الوقت لإدارة قسم تكنولوجيا المعلومات في Townbank - وهي عملية انتقال واسعة النطاق من نظام رئيسي متقادم إلى عدة أنظمة VAX جديدة. من الناحية النظرية ، بدت العملية جيدة - التقى الاستشاريون مع العميل واكتشفوا الأنظمة التي سيتم نقلها ، وكان من الضروري كتابة المواصفات وتعيين المهام للمطورين ، وكان على قسم مراقبة الجودة أن يؤكد أن النظام الجديد يعمل مثل النظام القديم ، وبعد ذلك سيتم وضع الشفرة قيد الإنتاج .
عندما طور مديرو المشروع العملية ، كان من المتوقع أن تستغرق الإجراءات غير المتوقعة دائمًا جزءًا صغيرًا فقط من إجمالي التكاليف أو مقدار الوقت اللازم لتنفيذ المهمة ، وكان ذلك في البداية. ومع ذلك ، استمر تطور المشروع ، وكلما تم تشغيل بيئات أكثر ، كلما اضطر Kevin وزملاؤه للمطورين إلى إضافة وقت إضافي لتقديراتهم. من الناحية الرسمية ، أطلق عليها المطورون اسمًا مختلفًا - اختبار تكامل النظام ، وتكوين الخوادم ، واختبار توافق الوسائط ، ولكن فيما بينهم أطلقوا على مثل هذه التأخيرات باسمهم الحقيقي: "عامل شيفا".
العمل الجاد!
ليس هذا هو أن Shiva مسؤول نظام غير كفء أو عديم الخبرة - على أي حال. في الواقع ، عندما قرر Townbank الترحيل من المركزية إلى VAX ، كان اسم Shiva في بداية قائمة قصيرة جدًا من الأشخاص الذين يمكنهم التعامل مع مثل هذه البنية التحتية. تولى شيفا هذه المسألة بكل مسؤولية ، وقدم سياساته الخاصة التي يمكن أن تساعد في القضاء على عيوب العملية. على سبيل المثال ، كل صباح ، كان على جميع المطورين أو المحللين أو موظفي إدارة التحكم ، قبل الدخول يوم الأربعاء ، التوقيع حرفيًا على السبورة في مكتب شيفا لتأكيد وجودهم الفعلي. بالإضافة إلى ذلك ، فقد شعر بأنه قد تم تنفيذ تتبع إجراءات المطور بتفاصيل غير كافية ، وقدم حماية من التحكم في الإصدار: لكل تغيير رمز ونقل بين البيئات ، كانت هناك حاجة إلى مذكرة. ويجب إجراء جميع التغييرات بواسطة معرف المستخدم الخاص به. ومن محطة له.
في يوم هادئ ، يمكن إجراء تغيير بسيط في يوم واحد فقط ، ولكن غالبًا ما تقع أيام الهدوء في أيام العطلات أو عطلات نهاية الأسبوع. اشتكى المطورون المزعجون للإدارة العليا ، بحجة أن هذه السياسات تبطئ المشروع وتبدو عديمة الفائدة تمامًا. ردا على ذلك ، تجاهلت الإدارة أكتافهم - حدد Shiva أهدافه في بداية المشروع - بيئات آمنة ، محمية من التلوث المتبادل مع الكود الآخر ومن عدم كفاءة المطورين. في النهاية ، كانت خوادم VAX لا تزال جديدة ، وحتى العديد من كبار المطورين لم يتقنوا استخدامهم بالكامل.
لقد أغمضت الجماهير المصير واللعن ، لكن بدلاً من التمرد والإطاحة بشيفا وإنهاء حكمه القاسي ، استقال الجميع واستمروا في العمل. على الرغم من معوقات Shiva وجهودها ، استمرت العملية ، ولكن كان هناك موقف بدا أن Shiva أهمله - ماذا لو كان هو نفسه يتعذر الوصول إليه؟
مساعد مبرمج صغير
على الرغم من أن محطة Kevin أظهرت أنه كان يعمل في استنساخ لبيئة الإنتاج ، إلا أن أسماء عملاء Nosmo King و Joe Blow أوضحت أنه قد حدث خلل كبير - تم توصيل التطبيق عن طريق الخطأ بقاعدة بيانات بيئة التطوير ، وبعد الغداء اضطر إلى اختباره قسم مراقبة الجودة. في الحالة العادية ، سيكون من الأسهل إصلاح الخطأ - لإجراء تغييرات على ملف التكوين في بيئة التطوير واستئناف العمل ، ولكن المصير كان يود أن يكون Shiva في اجتماع طويل ويجب أن يظهر في اليوم التالي فقط.
على أمل أن يعود شيفا في وقت مبكر ، ذهب كيفن إلى مكتبه ، لكنه لم ير سوى كرسي فارغ. ومع ذلك ، اشتعلت لوحة المفاتيح شيفا انتباهه. تم مسح الحروف A و S و V و H و I أكثر من البقية. عرف كيفن أن شيفا كان في حالة سكر مع السلطة ، ولكن هل كان نرجسيًا لدرجة أنه مستعد لطباعة اسمه مرارًا وتكرارًا؟ ... أو ربما هذا هو فكرة؟ للمتعة ، ذهب كيفن إلى سطر الأوامر وأدخل "شيفا" كاسم المستخدم وكلمة المرور. توقعًا أن يتمكن شيفا من دخول المكتب في أي وقت ، نقر كيفن على "أدخل" وصدم لأنه قادر على إكمال الإدخال.
كان ذلك مذهلا. كان رائعا. عرف كيفن أنه يحتاج إلى مشاركة اكتشافه مع شخص ما. أخبر ذلك لأحد المحاربين القدامى ، الذي كان معلمه ، لكن رد فعله كان مفاجأة لكيفن.
اتضح أن الجمع بين اسم المستخدم وكلمة المرور لـ Shiva كان "السر" المفضل لدى Townbank ، والذي كان معروفًا منذ أن عمل Shiva كمسؤول رئيسي.
"حتى لا يتعرف شيفا ،" أوضح مطور آخر أكثر خبرة لكيفن ، "نحن نلعب هذه اللعبة في كل مرة نرفعها".
"بالمناسبة ، من أجل المستقبل" ، يتابع قائلاً: "إذا كنت لا ترغب في أن يتم القبض عليك وتدميرها من قبل حياة أي شخص آخر ، فعليك الدخول من مبنى المطار وليس من مكتبه".
القصة الثالثة. تكلم اليونانية لي
[
الأصل ]
منذ عدة عقود ، وحتى قبل ظهور طابعات الليزر وأنظمة التشغيل الرسومية وتنسيقات الصور المستقلة عن الأجهزة ، عمل
جوس في قسم تكنولوجيا المعلومات بالكلية المحلية. كمشروع شخصي لحظات التوقف ، قرر معرفة كيفية طباعة النص باللغة اليونانية. بعد حوالي أسبوع ، قام بوضع برنامج قادر على طباعة النص اليوناني الكلاسيكي إلى طابعة.
عمل رئيس Gus كمدير لتكنولوجيا المعلومات ، ولكن على الرغم من ذلك ، اتضح أنه متخصص في فقه اللغة القديم. لم يكن عليه أبدًا أن يرى نصًا يونانيًا مطبوعًا على طابعة عادية ، وكان سعيدًا. أخبر الرئيس أصدقائه حول هذا الموضوع ، وأخبروه بأنفسهم ، وما إلى ذلك. سرعان ما تحول عالم العلماء في اليونان الكلاسيكية إلى ندوة متحمسة وصاخبة.
تلقى جوس مرة واحدة رسالة بريد إلكتروني من أستاذ جامعي غير معروف في ولاية أريزونا. سمع من غوس شيف عن برنامج أسطوري رائع. هل يمكنه الحصول عليها أيضًا؟
سوف يوافق Gus بكل سرور ، ولكن نشأت مشكلة. كان برنامجه مخصصًا للإصدار السابق من نظام التشغيل VAX / VMS ومترجم Pascal ، وقام بإخراج النص إلى طابعة VERSAMOD-200 واحدة محددة ، والتي يمكن تحويلها إلى وضع المصفوفة ،
وإلى برنامج تشغيل طباعة محدد ، والذي تم ترقيته بدقة برمز ثنائي ، حتى لا يفسد مصفوفة الصور. شكك جوس في أن الأستاذ لديه المعرفة التقنية الكافية لتقدير تفسيره ، لذلك أجاب بأدب ودون الخوض في التفاصيل التقنية: آسف ، ولكن البرنامج ببساطة لن يعمل على أي جهاز آخر.
بعد أسبوع ، جاء رئيس إلى مكتبه ، وذكر صديقه من ولاية أريزونا ، وسأل بلطف Gus عما إذا كان يمكن أن يجد أي طريقة لإرسال البرنامج إليه. محاولات جوس لشرح استحالة تشغيل الكود على أي كمبيوتر آخر في العالم لم تسمع.
"أنت عبقري ، جوس! أنا متأكد من أنك ستخرج بشيء ما. شكرا لكم مقدما! "، - راضيا عن تفاؤله ، غادر رئيسه.
بدأ جوس يفكر في كيفية تلبية طلب رئيسه أو على الأقل تلبية طلبه. وأخيرا ، حصل على فكرة. دخل سطر الأوامر في جهاز الكمبيوتر الخاص به:
DUMP /HEX "PRINTGREEK.EXE" /LIST=VERSAMOD-200 .
بعد فترة وجيزة ، أخذ
تفريغ برنامجه
الست عشري بمظهر ورقي ملموس. جمع جوس نسخة مطبوعة بابتسامة وذهب إلى مكتب الرئيس. "ها هي! هذا هو البرنامج ، كما طلبت ".
"أوه!" بدا رئيسه مندهشًا ، لكنه تفهم.
"إذا واجهوا أي مشاكل في التثبيت ، فدعهم يتصلون بي وسأقوم بالمساعدة."
"! ممتاز شكراً جزيلاً لك! "، نظر الرئيس إلى المائدة ، بحثاً عن مظروف بريد مناسب.
بعد ذلك بقليل ، تم تسليم أحد زملائنا المحترمين في مجال تكنولوجيا المعلومات في ولاية أريزونا وطلب منهم تثبيت هذا التفريغ المطبوعة على الورق. يجب أن يكون قد مر بلحظة مروعة إلى حد ما في WTF ، لكنه نجح بشكل واضح. مرت ثلاثون عامًا على الأقل منذ ذلك الحين ، ولم يسمع جوس أبدًا أي أسئلة من الأستاذ أو غيره من أعضاء هيئة التدريس. ربما أبرم شخص ما للتو صفقة مع Hades أو طلب من Kronos نقلها في وقت لم تعد فيه طباعة الأحرف الخاصة مثل Sisyphus labour.
القصة الرابعة. فاكسات الطوارئ
[
الأصل ]
الفاكسات قديمة في المرحلة الحالية من تطوير التكنولوجيا. لقد تم اختراعها قبل الهاتف
بأكثر من عشرة أعوام ، ولكن على الرغم من التقدم الهائل في تقنيات المسح والبريد الإلكتروني ، فإنها لا تزال الشكل القياسي للاتصال.
عند إرسال البيانات ، يمكن أن يؤدي التعثر العشوائي أو الضوضاء على الخط إلى تدمير الفاكس. تحتوي معظم أجهزة الفاكس الحديثة على وظائف بدائية لمعالجة الأخطاء تنبه المستخدم إلى وجوب إعادة إرسال الفاكس.
طريقة العمل هذه مع الأخطاء عملت بشكل جيد بحيث لم يحدث لأي شخص تغييره. لكن محلل أعمال واحد من الشركة التي عمل عليها
توم كان لديه فكرة رائعة.
"ماذا لو لم يكن المستخدم جالسًا بجوار جهاز الفاكس في انتظار رسالة؟" "ماذا لو لم يكتشف جهاز فاكس المرسل المشكلة؟" يجب علينا إرسال تقرير بالأخطاء إليه عبر الفاكس! "
على الرغم من أن مخاوف المحللين كانت قوية ، فقد اعترض توم ومجموعته على أن إرسال رسالة فاكس فاشلة لن يجعل الحياة أسهل للجميع بالضرورة.
قالوا إنه لهذا السبب ، ستكون آلة المرسل مشغولة ولن يتمكن من إعادة إرسال الفاكس الأصلي.
وقال المحلل "هذا طبيعي" ، حيث يمكن لبرنامجنا إرسال واستقبال رسائل الفاكس بشكل متوازٍ. هذه الفكرة هي
الأفضل التي جاءت بعد iPod ! إنها
موثوقة تمامًا ! "
لكن النقاش كان بلا معنى: في نظر الإدارة ، كان محللو الأعمال دائمًا على حق ، وقد تم تنفيذ هذه الوظيفة على وجه السرعة. تم تسمية البرنامج "FaxBack" ، وأدى الوظيفة المقابلة للاسم: لقد أرسل الإرسال الفاشل مرة أخرى إلى المرسل (المحدد بواسطة معرف المتصل) في وقت قصير بعد حدوث الفشل.
لفترة طويلة ، كان كل شيء يعمل دون أدنى مشكلة ، حتى يتم إيقاف تشغيل سيارتي شرطة صفارات الإنذار بالقرب من مكتب توم. قالت الشرطة إنها ردت على مكالمة طوارئ على الرقم 911 ، لكن لم تكن هناك حالة طارئة ولم يعترف أحد بأنهم طلبوا الرقم 911.
وسرعان ما غادر الضباط ، ولكن في وقت مبكر من صباح اليوم التالي ، توجهت سيارتان أخريان من الشرطة بسرعة إلى المكتب. لم تكن هناك حالة طوارئ مرة أخرى ولم يتصل أحد باسم 911 ، لذلك غادروا المكتب بهدوء.
لكن في المرة الثالثة ، عندما ظهرت السيارة بعد ظهر اليوم التالي ، رفض الضباط المغادرة حتى تم العثور على مصدر "القلق". كانت دائرة الشرطة على يقين من أن المكالمة جاءت من رقم الشركة ، وطالبت بمعرفة ما كان يحدث.
بعد قضاء بقية اليوم وجزءًا من المساء في تتبع المكالمات الهاتفية داخل الشركة ، اكتشف توم أن المكالمات إلى 911 تأتي من مركز البيانات ، وبشكل أكثر تحديدًا من FaxBack.
كان على أجهزة الفاكس ، مثل الهواتف المكتبية ، الاتصال بالرقم "9" للوصول إلى الخط الخارجي. لذلك ، عندما أجاب FaxBack على فاكس فاشل من نيودلهي ، طلب الرقم تسعة ، أعقبه الرمز الدولي للهند - 11 ، وعملت "القاعدة الخاصة" لنظام الاتصالات.
جاء الشخص الذي قام بتثبيت نظام الاتصالات السلكية واللاسلكية بفكرة مشرقة للتعامل مع 911 كحالة خاصة ، لأن المتصل قد لا يفكر في حالة الطوارئ للاتصال بأول تسعة آخرين. يتم تطبيق قاعدة خاصة أيضًا على الخطوط الموجودة في تجمع الفاكس ، حتى لو كان المتصل مجرد كمبيوتر.