د پروګرامرانو او انجینرانو فولکلور (لومړی برخه)

دا د انټرنیټ څخه د کیسې انتخاب دی چې څنګه بګ ځینې وختونه په بشپړ ډول د نه منلو وړ څرګندونه لري. شاید تاسو هم د ویلو لپاره یو څه لرئ.

د وینیلا آیس کریم سره د موټر حساسیت

د انجنیرانو لپاره یوه کیسه چې پوهیږي چې روښانه تل ځواب نه وي، او دا چې حقیقتونه څومره لرې ښکاري، دوی لاهم حقایق دي. د جنرال موټرو کارپوریشن پونټیاک څانګې شکایت ترلاسه کړ:

دا دوهم ځل دی چې زه تاسو ته لیکم، او زه تاسو د ځواب نه ورکولو لپاره ملامت نه کوم، ځکه چې دا لیونی ښکاري. زموږ کورنۍ هره شپه له ډوډۍ وروسته د آیس کریم خوړلو دود لري. د آیس کریم ډولونه هر وخت بدلیږي، او د ماښام ډوډۍ وروسته، ټوله کورنۍ غوره کوي چې کوم آیس کریم واخلي، بیا وروسته زه پلورنځي ته ځم. ما پدې وروستیو کې یو نوی پونټیاک اخیستی او له هغه وخت راهیسې د آیس کریم ترلاسه کولو لپاره زما سفرونه یوه ستونزه ګرځیدلې. تاسو ګورئ، هرکله چې زه وینیلا آیس کریم واخلم او له پلورنځي څخه بیرته راشم، موټر به نه پیل شي. که زه کوم بل آیس کریم راوړم، موټر پرته له کومې ستونزې پیل کیږي. زه غواړم یوه جدي پوښتنه وکړم، پرته له دې چې دا څومره احمقانه ښکاري: "د پونټیاک په اړه څه شی دی چې دا د وینیلا آیس کریم راوړلو سره پیل نه کوي، مګر په اسانۍ سره پیل کیږي کله چې زه د آیس کریم بل بوی راوړم؟"

لکه څنګه چې تاسو تصور کولی شئ، د څانګې ولسمشر د لیک په اړه شکمن و. په هرصورت، یوازې په قضیه کې، ما یو انجنیر لیږلی ترڅو چک وکړي. هغه حیران شو چې هغه په ​​یوه ښایسته سیمه کې د یوه شتمن، ښه تعلیم یافته سړي سره ولیدل. دوی موافقه وکړه چې د ډوډۍ وروسته سمدلاسه سره وویني ترڅو دوی دواړه د آیس کریم لپاره پلورنځي ته لاړ شي. هغه ماښام دا وینیلا وه، او کله چې دوی بیرته موټر ته راغلل، دا به پیل نه شي.

انجنیر درې نور ماښام راغی. لومړی ځل آیس کریم چاکلیټ و. موټر پیل شو. دوهم ځل د سټرابیري آیس کریم و. موټر پیل شو. په دریم ماښام هغه وغوښتل چې وینیلا واخلي. موټر پیل نه شو.

په منطقي توګه، انجنیر د دې باور څخه انکار وکړ چې موټر د وینیلا آیس کریم سره حساس و. له همدې امله، ما د موټر له مالک سره موافقه وکړه چې هغه به خپلو لیدنو ته دوام ورکړي تر څو چې هغه د ستونزې حل ومومي. او د لارې په اوږدو کې، هغه د یادښتونو اخیستل پیل کړل: هغه ټول معلومات، د ورځې وخت، د پطرول ډول، د پلورنځي څخه د رسیدلو او بیرته راستنیدو وخت، او داسې نور لیکلي.

انجینر ژر پوه شو چې د موټر مالک د وینیلا آیس کریم په اخیستلو لږ وخت تیر کړ. دلیل یې په پلورنځي کې د توکو ترتیب و. وینیلا آیس کریم خورا مشهور و او د پلورنځي مخې ته په جلا فریزر کې ساتل شوی و ترڅو موندل اسانه کړي. او نور ټول ډولونه د پلورنځي شاته وو ، او د سم ډول موندلو او تادیې لپاره یې ډیر وخت واخیست.

اوس پوښتنه د انجینر لپاره وه: که چیرې د انجن له بندیدو لږ وخت تیر شوی وي نو ولې موټر پیل نه شو؟ څرنګه چې ستونزه د وخت وه او د وینیلا آیس کریم نه، انجنیر ژر تر ژره ځواب وموند: دا د ګاز قفل و. دا هر ماښام پیښیږي، مګر کله چې د موټر مالک ډیر وخت د آیس کریم په لټه کې تیر کړ، انجن په کافي اندازه سړه او په اسانۍ سره پیل شو. او کله چې سړي وینیلا آیس کریم واخیست، انجن لاهم ګرم و او د ګاز قفل د منحل کولو وخت نه درلود.

اخلاقي: حتی په بشپړ ډول لیوني ستونزې ځینې وختونه ریښتینې وي.

د غورځېدو Bandicoot

د دې تجربه کول دردناک دي. د یو پروګرامر په توګه، تاسو د خپل کوډ لومړی، دویم، دریم ... او په کوم ځای کې په لس زره ځای کې تاسو کمپیلر ملامت کوئ. او د لیست لاندې نور تاسو دمخه تجهیزات ملامت کوئ.

دلته د هارډویر بګ په اړه زما کیسه ده.

د لوبې کریش بانډیکوټ لپاره ، ما د حافظې کارت ته د بارولو او خوندي کولو لپاره کوډ لیکلی. د داسې سپک لوبې پراختیا کونکي لپاره ، دا په پارک کې د تګ په څیر و: ما فکر کاوه چې کار به څو ورځې ونیسي. په هرصورت، ما د شپږو اونیو لپاره کوډ ډیبګ پای ته ورساوه. د لارې په اوږدو کې، ما نورې ستونزې حل کړې، مګر هر څو ورځې زه د څو ساعتونو لپاره دې کوډ ته راستون شوم. دا درد و.

نښې یې داسې ښکاري: کله چې تاسو د لوبې اوسنۍ پلیټرو خوندي کوئ او د حافظې کارت ته لاسرسی ومومئ ، هرڅه نږدې تل ښه کیږي ... مګر ځینې وختونه د کوم څرګند دلیل لپاره د لوستلو یا لیکلو عملیات وخت پای ته رسیږي. یو لنډ ریکارډ اکثرا د حافظې کارت ته زیان رسوي. کله چې یو لوبغاړی د ژغورلو هڅه کوي، هغه نه یوازې په خوندي کولو کې پاتې راغلی، بلکې نقشه هم ویجاړوي. کریپ.

یو څه وروسته، په سوني کې زموږ تولید کونکي، کوني بس، په ویره پیل وکړ. موږ نشو کولی د دې بګ سره لوبه ولیږو ، او شپږ اونۍ وروسته زه نه پوهیږم چې د ستونزې لامل څه و. د کوني له لارې ، موږ د PS1 نورو پراختیا کونکو سره اړیکه ونیوله: ایا څوک ورته ورته څه سره مخ شوي؟ نه. هیڅوک د یاد کارت سره ستونزه نه درلوده.

کله چې تاسو د ډیبګ کولو لپاره هیڅ نظر نلرئ ، یوازینۍ لاره پاتې ده چې "ویشئ او فتح کړئ": د غلط برنامې څخه ډیر او ډیر کوډ لرې کړئ تر هغه چې نسبتا کوچنۍ ټوټه پاتې وي چې لاهم د ستونزې لامل کیږي. دا دی، تاسو د پروګرام ټوټه ټوټه ټوټه کړئ تر هغه چې هغه برخه چې بګ لري پاتې شي.

مګر خبره دا ده چې د ویډیو لوبې څخه ټوټې ټوټې کول خورا ستونزمن دي. دا څنګه پرمخ وړئ که تاسو هغه کوډ لرې کړئ چې د جاذبې جذب کوي؟ یا د کرکټرونو رسم کول؟

له همدې امله، موږ باید ټول ماډلونه د سټبونو سره ځای په ځای کړو چې د یو څه ګټور کار کولو ښکارندوی کوي، مګر په حقیقت کې یو څه خورا ساده کړئ چې غلطۍ نلري. موږ باید لږ تر لږه د کار کولو لپاره د لوبې لپاره داسې کرچونه ولیکو. دا یو سست او دردناک بهیر دی.

په لنډه توګه، ما دا وکړل. ما د کوډ ډیرې برخې لرې کړې تر هغه چې زه د لومړني کوډ سره پاتې شوی نه وم چې سیسټم د لوبې چلولو لپاره تنظیموي ، د رینډرینګ هارډویر پیل کوي ، او داسې نور. البته ، پدې مرحله کې زه نشم کولی د خوندي کولو او بار کولو مینو رامینځته کړم ، ځکه چې زه باید د ټولو ګرافیک کوډونو لپاره سټب جوړ کړم. مګر زه کولی شم د (غیر مرئی) سیف او بار سکرین په کارولو سره د کارونکي په توګه ویاړم او د خوندي کولو غوښتنه وکړم او بیا د حافظې کارت ته ولیکئ.

دا ما د کوډ یوه کوچنۍ ټوټه پریښوده چې لاهم پورته ستونزه درلوده - مګر دا لاهم په تصادفي ډول پیښیږي! ډیری وختونه هرڅه سم کار کوي، مګر کله ناکله ستونزې شتون درلود. ما د لوبې نږدې ټول کوډ لرې کړ، مګر بګ لاهم ژوندی و. دا حیرانونکې وه: پاتې کوډ په حقیقت کې هیڅ شی نه دی کړی.

په یو وخت کې، شاید د سهار شاوخوا درې بجې، یو فکر زما په ذهن کې راغی. د لوستلو او لیکلو (انپوټ/آؤټ پټ) عملیات د اجرا کولو دقیق وخت لري. کله چې تاسو د هارډ ډرایو، حافظې کارت یا بلوتوت ماډل سره کار کوئ، د ټیټې کچې کوډ چې د لوستلو او لیکلو مسولیت لري د ساعت نبض سره سم ترسره کوي.

د ساعت په مرسته، هغه وسیله چې په مستقیم ډول د پروسیسر سره تړلې نه وي د پروسیسر د اجرا کوډ سره همغږي کیږي. ساعت د بوډ نرخ ټاکي - هغه سرعت چې معلومات لیږدول کیږي. که چیرې د وخت سره ګډوډ وي، نو بیا هارډویر یا سافټویر، یا دواړه هم ګډوډ دي. او دا خورا خراب دی، ځکه چې ډاټا خراب کیدی شي.

څه شی که زموږ په کوډ کې یو څه وخت ګډوډ کړي؟ ما د دې پورې اړوند هرڅه د ازموینې برنامې کوډ کې چیک کړل او ولیدل چې موږ د برنامې وړ ټایمر په PS1 کې 1 kHz (په یوه ثانیه کې 1000 ټیکونه) تنظیم کړل. دا خورا ډیر دی؛ په ډیفالټ سره ، کله چې کنسول پیل شي ، دا په 100 Hz کې پرمخ ځي. او ډیری لوبې دا فریکونسۍ کاروي.

انډي، د لوبې پراختیا کونکي، ټایمر 1 kHz ته تنظیم کړ ترڅو حرکتونه په دقیق ډول محاسبه شي. انډي د تختې څخه تیریږي، او که موږ د جاذبې تقلید وکړو، موږ دا د امکان تر حده دقیق ترسره کوو!

مګر څه که چیرې د ټایمر ګړندی کول یو څه د برنامې عمومي وخت اغیزه وکړي ، او له همدې امله هغه ساعت چې د حافظې کارت لپاره د باډ نرخ تنظیموي؟

ما د ټایمر کوډ تبصره وکړه. تېروتنه بیا نه ده شوې. مګر دا پدې معنی ندي چې موږ دا تنظیم کړی، ځکه چې ناکامي په تصادفي ډول رامنځ ته شوې. که زه یوازې نېکمرغه وم څه به وکړم؟

څو ورځې وروسته ما بیا د ازموینې برنامه تجربه کړه. بګ تکرار نه شو. زه بیرته د لوبې بشپړ کوډبیس ته لاړم او د خوندي کولو او بار کولو کوډ یې بدل کړ ترڅو د برنامه وړ ټایمر د حافظې کارت ته لاسرسي دمخه خپل اصلي ارزښت (100Hz) ته بیا تنظیم کړي ، او بیا 1kHz ته بیرته راستون شي. نور حادثې نه وې.

خو ولې داسې وشول؟

زه بیا د ازموینې پروګرام ته راستون شوم. ما هڅه وکړه چې د 1 kHz ټیمر سره د غلطۍ په پیښه کې یو څه نمونه ومومئ. په نهایت کې ما ولیدل چې تېروتنه هغه وخت رامینځته کیږي کله چې یو څوک د PS1 کنټرولر سره لوبې کوي. ځکه چې زه به په ندرت سره دا پخپله وکړم - ولې زه به کنټرولر ته اړتیا ولرم کله چې د خوندي کولو او بار کوډ ازموینه وکړم؟ - ما حتی دې انحصار ته پام نه دی کړی. مګر یوه ورځ زموږ یو هنرمند زما د ازموینې پای ته رسیدو ته په تمه و - ما شاید په هغه وخت کې لعنت ویل - او په عصبي ډول یې کنټرولر په لاسونو کې وګرځاوه. یوه تېروتنه رامنځته شوې ده. "انتظار، څه؟!" ښه، بیا یې وکړه!"

کله چې زه پوه شوم چې دا دوه پیښې یو له بل سره تړلې وې، ما په اسانۍ سره د غلطۍ بیا تولید کولو توان درلود: ما د حافظې کارت ته ثبت کول پیل کړل، کنټرولر یې حرکت وکړ، او د حافظې کارت یې خراب کړ. زما لپاره دا د هارډویر بګ په څیر ښکاري.

زه کوني ته راغلم او زما د کشف په اړه یې ورته وویل. هغې دا معلومات یو انجینر ته واستول چې PS1 یې ډیزاین کړ. "ناممکن،" هغه ځواب ورکړ، "دا د هارډویر ستونزه نه وي." ما له کوني څخه وغوښتل چې زموږ لپاره د خبرو اترو بندوبست وکړي.

انجینر ما ته زنګ وواهه او موږ د هغه په ​​مات شوي انګلیسي او زما (خورا) مات شوي جاپاني کې بحث وکړ. په نهایت کې ما وویل ، "اجازه راکړئ چې زما د 30 لاین ازموینې برنامه ولیږم چیرې چې د کنټرولر حرکت کول د بګ لامل کیږي." هغه ومنله. وویل چې دا د وخت ضایع کول دي او دا چې هغه په ​​​​ډیره توګه په نوې پروژې کار کولو بوخت و ، مګر دا به تسلیم کړي ځکه چې موږ د سوني لپاره خورا مهم پراختیا کونکی یو. ما خپل د ازموینې برنامه پاکه کړه او هغه ته یې واستوله.

بل ماښام (موږ په لاس انجلس کې وو او هغه په ​​توکیو کې و) هغه ما ته زنګ وواهه او په بې رحمۍ یې بخښنه وغوښته. دا د هارډویر ستونزه وه.

زه نه پوهیږم چې واقعیا بګ څه و ، مګر د هغه څه څخه چې ما د سوني په مرکزي دفتر کې اوریدلي ، که تاسو ټایمر خورا لوړ ارزښت ته وټاکئ ، نو دا د ټایمر کرسټال په شاوخوا کې د مور بورډ اجزاو سره مداخله کوي. یو له دوی څخه د حافظې کارت لپاره د باډ نرخ کنټرولر و ، کوم چې د کنټرولرانو لپاره د باډ نرخ هم ټاکي. زه انجنیر نه یم، نو شاید ما یو څه ګډوډ کړي وي.

مګر لاندینۍ کرښه دا ده چې په مور بورډ کې د اجزاوو ترمنځ مداخله وه. او کله چې په 1 kHz کې د ټایمر سره د کنټرولر پورټ او د حافظې کارت بندر له لارې په ورته وخت کې ډیټا لیږدول کیږي ، بټونه ورک شوي ، ډیټا ورک شوی ، او کارت خراب شوی.

بد غواګانې

په 1980 لسیزه کې، زما ښوونکي سرګي د SM-1800 لپاره سافټویر ولیکه، د PDP-11 شوروي کلون. دا مایکرو کمپیوټر یوازې د Sverdlovsk سره نږدې د اورګاډي په یوه سټیشن کې نصب شوی، چې په شوروي اتحاد کې یو مهم ټرانسپورټ مرکز دی. نوی سیسټم د واګونونو او بار وړونکو ټرافیکونو د لیږد لپاره ډیزاین شوی. مګر پدې کې یو ځورونکی بګ شتون درلود چې د تصادفي پیښو او حادثو لامل شو. زوال تل پیښیږي کله چې یو څوک په ماښام کې کور ته لاړ. مګر بله ورځ د یوې بشپړې څیړنې سره سره، کمپیوټر په ټولو لاسي او اتوماتیک ازموینو کې سم کار کاوه. دا معمولا د ریس حالت یا کوم بل رقابتي بګ په ګوته کوي چې د ځینې شرایطو لاندې پیښیږي. د شپې ناوخته د تلیفونونو څخه ستړي شوي، سرګي پریکړه وکړه چې د هغې پای ته ورسیږي، او لومړی یې پوه شو چې د مارشلینګ په انګړ کې کوم شرایط د کمپیوټر د خرابیدو لامل شوي.

لومړی، هغه د ټولو ناڅرګندو زوالونو احصایې راټولې کړې او د نیټې او وخت له مخې یې ګراف جوړ کړ. بیلګه څرګنده وه. د څو ورځو لپاره د لیدلو وروسته، سرګي پوه شو چې هغه کولی شي په اسانۍ سره د راتلونکي سیسټم ناکامۍ اټکل وکړي.

هغه ډیر ژر پوه شو چې ګډوډي یوازې هغه وخت رامینځته شوه کله چې سټیشن د شمالي اوکراین او لویدیځې روسیې څخه د غواګانو ریل ګاډي یو نږدې مسلخ ته روان و. دا پخپله عجیب و، ځکه چې د مسلخ خونه په قزاقستان کې ډیر نږدې د فارمونو لخوا چمتو شوې وه.

د چرنوبیل اټومي بټۍ په 1986 کې وچاودیده، او د راډیو اکټیو راوتلو شاوخوا سیمې ناامنه کړې. د اوکراین په شمال، بیلاروس او لویدیځه روسیه کې پراخې سیمې ککړې شوې. په راتلونکو موټرو کې د وړانګو د لوړې کچې شک سره، سرګي د دې تیوري آزموینې لپاره یوه طریقه جوړه کړه. نفوس د ډوسیمیټرونو څخه منع شوی و، نو سرګي ځان د اورګاډي په سټیشن کې د څو نظامي کسانو سره ثبت کړ. د وودکا د څو څښلو وروسته، هغه په ​​دې وتوانید چې یو سرتیری قانع کړي چې په یوه شکمن موټر کې د وړانګو کچه اندازه کړي. دا معلومه شوه چې کچه د نورمال ارزښتونو څخه څو ځله لوړه وه.

غواګانو نه یوازې دا چې ډیری وړانګې خپروي، د هغې کچه دومره لوړه وه چې دا د SM-1800 په حافظه کې د بټونو تصادفي ضایع کیدو لامل شوې، کوم چې د سټیشن څنګ ته په یوه ودانۍ کې موقعیت درلود.

په شوروي اتحاد کې د خوړو کمښت شتون درلود، او چارواکو پریکړه وکړه چې د چرنوبیل غوښه د هیواد د نورو سیمو غوښې سره مخلوط کړي. دې کار د ارزښت وړ سرچینو له لاسه ورکولو پرته د راډیو اکټیفیت عمومي کچه راټیټه کړه. د دې په اړه پوهیدلو سره، سرګي سمدستي د مهاجرت لپاره اسناد ډک کړل. او کله چې د وخت په تیریدو سره د وړانګو کچه راټیټه شوه د کمپیوټر حادثې پخپله بندې شوې.

د پایپونو له لارې

یو وخت، موویټیک حلونه د سینما لپاره سافټویر جوړ کړ، د محاسبې، ټکټ پلور او عمومي مدیریت لپاره ډیزاین شوی. د پرچم بردار اپلیکیشن DOS نسخه په شمالي امریکا کې د کوچني او مینځنۍ اندازې فلم تیاتر زنځیرونو کې خورا مشهور و. نو دا د حیرانتیا خبره نده چې کله د وینډوز 95 نسخه اعلان شوه، د وروستي ټچ سکرینونو او د ځان خدمت کیوسکونو سره مدغم شو، او د راپور ورکولو هر ډول وسیلو سره سمبال شو، دا هم په چټکۍ سره مشهور شو. ډیری وختونه تازه کول پرته له کومې ستونزې تیریږي. د معلوماتي ټکنالوجۍ محلي کارمندانو نوي تجهیزات نصب کړل، ډیټا لیږدول، او سوداګرۍ دوام درلود. پرته له دې چې دوام ونه کړي. کله چې دا پیښ شي، شرکت به جیمز وباسي، چې نوم یې "کلینر" دی.

که څه هم مستعار نوم یو ناوړه ډول وړاندیز کوي، کلینر یوازې د ښوونکي، نصب کونکي او جیک-اف-ټول تجارتونو ترکیب دی. جیمز به یو څو ورځې د پیرودونکي سایټ کې تیر کړي چې ټولې برخې سره یوځای کړي، او بیا به یو څو ورځې نورو کارمندانو ته د نوي سیسټم کارولو په اړه درس ورکړي، د هارډویر ستونزې حل کړي چې رامینځته کیږي او د ماشومتوب له لارې د سافټویر سره مرسته کوي.

له همدې امله، دا د حیرانتیا خبره نه ده چې په دې سختو وختونو کې، جیمز سهار دفتر ته راغی، او مخکې له دې چې هغه خپل میز ته ورسیږي، د مدیر لخوا هغه ته ښه راغلاست وویل شو، د معمول څخه بهر د کافین څخه ډک و.

"زه ویره لرم چې تاسو باید ژر تر ژره اناپولس، نووا سکوټیا ته لاړ شئ." د دوی ټول سیسټم ړنګ شو، او د دوی انجنیرانو سره د یوې شپې کار کولو وروسته، موږ نشو پوهیږو چې څه پیښ شوي. داسې ښکاري چې شبکه په سرور کې ناکامه شوې ده. مګر یوازې وروسته له هغه چې سیسټم د څو دقیقو لپاره روان و.

- دوی زاړه سیسټم ته نه دي راستانه شوي؟ - جیمز په جدي توګه ځواب ورکړ، که څه هم په ذهني توګه هغه په ​​حیرانتیا سره سترګې پراخې کړې.

- دقیقا: د دوی د معلوماتي ټکنالوجۍ متخصص "لومړیتوبونه بدل کړل" او پریکړه یې وکړه چې د خپل زاړه سرور سره پریږدي. جیمز، دوی سیسټم په شپږو سایټونو کې نصب کړی او یوازې د پریمیم مالتړ لپاره یې پیسې ورکړې، او د دوی سوداګرۍ اوس د 1950 په څیر پرمخ ځي.

جیمز یو څه سیده شو.

- دا بله خبره ده. ښه، راځئ چې پیل وکړو.

کله چې هغه اناپولس ته ورسید، لومړی کار یې وکړ چې د پیرودونکي لومړی تیاتر وموندل چې ستونزه درلوده. په هوایی ډګر کې اخیستل شوې نقشه کې، هر څه ښه ښکاري، مګر د مطلوب پته شاوخوا ساحه شکمن ښکاري. ګیټو نه، مګر د فلم نوری یادونه کوي. لکه څنګه چې جیمز د ښار په مرکز کې پارک شو، یوه فاحشه هغه ته نږدې شوه. د اناپولس اندازې ته په پام سره، دا ډیری احتمال په ټول ښار کې یوازینی و. د هغې بڼه سمدلاسه د مشهور کرکټر ذهن ته راوړل چې په لوی سکرین کې د پیسو لپاره جنسیت وړاندیز کوي. نه، د جولیا رابرټس په اړه نه، مګر د جون وویټ په اړه [د "د نیمې شپې کاوبای" فلم ته اشاره - نږدې. لین].

په لاره کې فاحشه لیږلو سره، جیمز سینما ته لاړ. شاوخوا سیمه ښه شوې وه، مګر دا لاهم د تیښتې احساس ورکوي. نه دا چې جیمز ډیر اندیښمن و. هغه مخکې هم بدمرغه ځایونو ته تللی و. او دا کاناډا وه ، چیرې چې حتی غله هم دومره نرم دي چې ستاسو د بټو له اخیستو وروسته "مننه" ووایی.

سینما ته د ننوتو اړخ په یوه تیاره کوڅه کې و. جیمز دروازې ته ورغی او ټک یې کړ. سمدلاسه دا ټوټه شوه او یو څه خلاص شو.

- ایا تاسو پاکونکی یاست؟ - له دننه څخه یو دروند غږ راغی.

- هو، دا زه یم ... زه راغلی یم چې هرڅه سم کړم.

جیمز د سینما لابی ته لاړ. په ښکاره ډول بل انتخاب نه درلود، کارمندانو لیدونکو ته د کاغذ ټکټونو په ورکولو پیل وکړ. دې کار مالي راپور ورکول ستونزمن کړل، نور په زړه پوري توضیحات پریږدئ. مګر کارمندانو جیمز ته په آرامۍ سره ښه راغلاست ووایه او سمدلاسه یې د سرور خونې ته بوتلو.

په لومړي نظر کې، هرڅه سم وو. جیمز سرور ته ننوتل او معمول شکمن ځایونه یې چیک کړل. هیڅ ستونزه. په هرصورت، د ډیر احتیاط څخه بهر، جیمز سرور بند کړ، د شبکې کارت یې بدل کړ، او سیسټم یې بیرته راوګرځاوه. هغې سمدلاسه په بشپړ ډول کار پیل کړ. کارمندانو بیا د ټکټونو پلور پیل کړ.

جیمز مارک ته زنګ وواهه او د وضعیت څخه یې خبر کړ. دا تصور کول ستونزمن ندي چې جیمز ممکن وغواړي شاوخوا ودریږي او وګوري چې ایا کوم غیر متوقع پیښیږي. هغه د زینو څخه ښکته شو او د کارمندانو څخه یې وپوښتل چې څه پیښ شوي؟ په ښکاره ډول سیسټم کار بند کړی دی. دوی دا بند او فعال کړل، هرڅه کار کوي. مګر د 10 دقیقو وروسته سیسټم بند شو.

په دې وخت کې ورته یو څه پیښ شوي. ناڅاپه، د ټیکټینګ سیسټم غلطۍ پیل کړې. کارمندانو ساه ورکړه او د کاغذ ټکټونه یې واخیستل، او جیمز په چټکۍ سره د سرور خونې ته لاړ. هر څه د سرور سره ښه ښکاري.

بیا یو کارمند دننه شو.

- سیسټم بیا کار کوي.

جیمز حیران و ځکه چې هغه هیڅ نه و کړی. په دقیق ډول، هیڅ شی به د سیسټم کار وکړي. هغه لاګ آوټ شو، خپل تلیفون یې پورته کړ، او د خپل شرکت مالتړ لاین ته یې زنګ وواهه. سمدلاسه هماغه کارمند د سرور خونې ته ننوت.

- سیسټم خراب دی.

جیمز سرور ته وکتل. د څو رنګه شکلونو یوه په زړه پورې او پیژندل شوې نمونه په سکرین کې نڅا شوې - په ګډوډ ډول ریټینګ او یو بل سره تړل شوي پایپونه. موږ ټولو دا سکرین سیور په یو وخت کې لیدلی دی. دا په ښکلي ډول وړاندې شوی او په لفظي ډول hypnotizing وه.

جیمز یو تڼۍ کیکاږله او نمونه ورکه شوه. هغه په ​​چټکۍ سره د ټکټ دفتر ته لاړ او په لاره کې یې یو کارمند ولید چې بیرته راستون شو.

- سیسټم بیا کار کوي.

که تاسو کولی شئ ذهني مخ وښایاست، دا هغه څه دي چې جیمز یې وکړل. سکرین سیور. دا OpenGL کاروي. او له همدې امله، د عملیاتو په جریان کې، دا د سرور پروسیسر ټولې سرچینې مصرفوي. د پایلې په توګه، سرور ته هر کال د وخت پای سره پای ته رسیږي.

جیمز د سرور خونې ته راستون شو، ننوتل، او د سکرین سیور یې د ښکلي پایپونو سره د خالي سکرین سره بدل کړ. دا د سکرین سیور پرځای چې د پروسیسر سرچینې 100٪ مصرفوي ، ما یو بل نصب کړ چې سرچینې نه مصرفوي. بیا ما 10 دقیقې انتظار وکړ چې زما اټکل وګورئ.

کله چې جیمز راتلونکې سینما ته ورسید، هغه حیران و چې څنګه خپل مدیر ته تشریح کړي چې هغه یوازې 800 کیلومتره الوتنه کړې ترڅو د سکرین سیور بند کړي.

د سپوږمۍ د یوې ټاکلې مرحلې په جریان کې ټکر

ریښتینې کیسه. یوه ورځ د سافټویر بګ راپورته شو چې د سپوږمۍ مرحله پورې اړه لري. یو کوچنی معمول و چې معمولا د سپوږمۍ ریښتیني مرحلې ته نږدې محاسبه کولو لپاره په مختلف MIT برنامو کې کارول کیده. GLS دا معمول په LISP برنامه کې رامینځته کړی چې د فایل لیکلو پرمهال به نږدې 80 حروف اوږد مهاله سټمپ سره یوه کرښه تولید کړي. دا خورا نادره وه چې د پیغام لومړۍ کرښه به خورا اوږده وي او بلې کرښې ته به یې رهبري کړي. او کله چې برنامه وروسته دا فایل ولوست ، نو لعنت یې وکړ. د لومړۍ کرښې اوږدوالی په دقیق نیټه او وخت پورې اړه لري، په بیله بیا د پړاو مشخصاتو اوږدوالی په هغه وخت کې چې د مهال ویش چاپ شوی و. دا دی، بګ په حقیقت کې د سپوږمۍ په مرحله پورې اړه لري!

لومړۍ پاڼه چاپ د جرګون دوتنه (Steele-1983) د داسې کرښې یوه بیلګه درلوده چې د بیان شوي بګ لامل شوی، مګر ټایپ سیټر دا "فکس" کړی. دا له هغه وخت راهیسې د "سپوږمۍ مرحلې بګ" په توګه تشریح شوی.

په هرصورت، د انګیرنې سره محتاط وساتئ. څو کاله دمخه، د CERN (د اټومي څیړنو لپاره د اروپا مرکز) انجنیرانو په لوی الیکټرون - پوزیټرون کولیډر کې ترسره شوي تجربو کې د غلطیو سره مخ شول. څرنګه چې کمپیوټر په فعاله توګه د دې وسیلې لخوا رامینځته شوي خورا لوی مقدار ډیټا پروسس کوي مخکې لدې چې ساینس پوهانو ته پایله وښیې ، ډیری اټکل کوي چې سافټویر یو څه د سپوږمۍ مرحلې ته حساس و. څو نا امید انجینران حقیقت ته ورسیدل. تېروتنه د سپوږمۍ د تېرېدو پرمهال د ځمکې د خرابوالي له امله د 27 کیلومتره اوږد حلقې په جیومیټري کې د لږ بدلون له امله رامینځته شوه! دا کیسه د فزیک فولکلور ته د "ذرې فزیک په اړه د نیوټن انتقام" او د فزیک د ساده او پخوانیو قوانینو او خورا پرمختللي ساینسي مفکورو ترمنځ د ارتباط یوه بیلګه ده.

د تشناب فلش کول د اورګاډي مخه نیسي

د هارډویر غوره بګ چې ما کله هم اوریدلی دی په فرانسه کې د تیز سرعت ریل وه. خرابۍ د اورګاډي د بیړني بریک کولو لامل شوې ، مګر یوازې هغه وخت چې په کې مسافر وي. په هر حالت کې، اورګاډی له خدمت څخه لیرې شوی، چک شوی، مګر هیڅ شی ونه موندل شو. بیا هغه بیرته کرښې ته واستول شو، او هغه سمدلاسه یو تمځای ته وغورځید.

د یوې چک په جریان کې، یو انجنیر چې په اورګاډي کې سفر کوي تشناب ته لاړ. هغه ژر ومینځل شو، بوم! بیړنی بند.

انجنیر د موټر چلوونکي سره اړیکه ونیوله او پوښتنه یې وکړه:

- تاسو د بریک کولو دمخه څه کول؟

- ښه، زه په ښکته کیدو کې سست شوم ...

دا عجيبه وه، ځکه چې د عادي عملياتو په ترڅ کې اورګاډي په لسگونو ځله د ښکته کیدو ورو ورو. ریل ګاډی روان شو، او په راتلونکي کښته کې ډریور خبرداری ورکړ:

- زه به سست شم.

هیڅ شی ندی شوی.

- تاسو د وروستي بریک کولو پرمهال څه وکړل؟ - چلوونکي وپوښتل.

- ښه ... زه په تشناب کې وم ...

- ښه، بیا تشناب ته لاړ شه او هغه څه وکړه چې تاسو یې وکړل کله چې موږ بیا ښکته شو!

انجنیر تشناب ته لاړ، او کله چې موټر چلوونکي خبرداری ورکړ: "زه ورو یم،" هغه اوبه وڅښلې. البته، ریل سمدلاسه ودرېد.

اوس دوی کولی شي ستونزه بیا تولید کړي او د علت موندلو ته اړتیا لري.

دوه دقیقې وروسته، دوی ولیدل چې د انجن بریک ریموټ کنټرول کیبل (د اورګاډي په هر پای کې یو انجن درلود) د بریښنایی کابینې له دیوال څخه منقطع شوی و او په ریل کې پروت و چې د تشناب پلګ solenoid کنټرولوي ... کله چې ریلی چالان شو، دا د بریک کیبل کې لاسوهنه رامینځته کړه، او د ناکامۍ په وړاندې د سیسټم محافظت په ساده ډول د بیړني بریک لګول شامل وو.

هغه دروازه چې د FORTRAN څخه نفرت کوي

څو میاشتې دمخه موږ ولیدل چې په اصلي ټاټوبي کې د شبکې اړیکې [دا په هاوایی کې وه] خورا خورا ورو کیږي. دا کیدای شي د 10-15 دقیقو لپاره دوام وکړي او بیا ناڅاپه بیا واقع شي. یو څه وخت وروسته، زما همکار ما ته شکایت وکړ چې په اصلي ځمکه کې د شبکې اړیکې په عمومي توګه کار نه کوي. هغه یو څه د فورټران کوډ درلود چې اړتیا یې په اصلي لینډ کې یو ماشین ته کاپي شي، مګر دا ونشوه ځکه چې "نیټ ورک د FTP اپلوډ بشپړولو لپاره دومره وخت نه و نیولی."

هو، دا معلومه شوه چې د شبکې ناکامي هغه وخت رامنځته شوه کله چې یو همکار هڅه وکړه چې په فورټران کې د سرچینې کوډ سره یو فایل په اصلي لینډ کې ماشین ته FTP کړي. موږ د فایل آرشیف کولو هڅه وکړه: بیا دا په اسانۍ سره کاپي شوه (مګر د هدف ماشین یو پیکر نه درلود، نو ستونزه حل نه شوه). په نهایت کې موږ د FORTRAN کوډ په ډیرو کوچنیو ټوټو ویشلو او په یو وخت کې یې یو یو لیږلو. ډیری ټوټې پرته له ستونزو څخه کاپي شوي، مګر یو څو ټوټې نه تیریږي، یا وروسته تیریږي ډیری هڅې

د ستونزو لرونکي پاسونو له معاینه کولو وروسته، موږ وموندله چې دوی یو څه مشترک لري: دوی ټول د تبصرې بلاکونه لري چې پیل او پای یې د پلازمینې C په لیکو سره پای ته رسیدلی (د یو همکار په توګه په FORTRAN کې تبصره کول غوره دي). موږ په مینلینډ کې د شبکې متخصصینو ته بریښنالیک ورکړ او د مرستې غوښتنه یې وکړه. البته، دوی غوښتل زموږ د فایلونو نمونې وګوري چې د FTP له لارې لیږدول کیدی نشي ... مګر زموږ لیکونه دوی ته ندي رسیدلي. په نهایت کې موږ یو ساده سره راغلو تشریح کړئد نه لیږدولو فایلونه څه ډول ښکاري. دا کار وکړ :) [زړه لرم چې دلته د یوې ستونزې لرونکي فورټران نظرونو مثال اضافه کړم؟ شاید د دې ارزښت نلري!]

په پای کې موږ وکولی شو دا معلومه کړو. یوه نوې دروازه پدې وروستیو کې زموږ د کیمپس برخې او اصلي ځمکې شبکې ترمینځ نصب شوې. دا د پاکټونو په لیږدولو کې لویه ستونزه درلوده چې د لوی لاس C تکرار بټونه لري! د دې کڅوړو څخه یوازې یو څو کولی شي د دروازې ټولې سرچینې ونیسي او د ډیری نورو کڅوړو له مینځه وړلو مخه ونیسي. موږ د دروازې جوړونکي ته شکایت وکړ ... او دوی ځواب ورکړ: "هو، هو، تاسو د تکرار C بګ سره مخ یاست! موږ د هغه په ​​اړه لا دمخه پوهیږو. موږ په نهایت کې د بل تولید کونکي څخه د نوي دروازې په اخیستلو سره ستونزه حل کړه (د پخواني دفاع کې ، د FORTRAN برنامو لیږدولو کې ناتواني ممکن د ځینو لپاره ګټه وي!).

سخت وختونه

څو کاله دمخه، پداسې حال کې چې په پرل کې د ETL سیسټم رامینځته کولو لپاره کار کول ترڅو د مرحلې 40 کلینیکي آزموینې لګښتونه کم کړي، زه اړتیا لرم چې شاوخوا 000 نیټې پروسس کړم. له دوی څخه دوه یې ازموینه کې بریالي نه شول. دا ما ډیر نه ځوروي ځکه چې دا نیټې د پیرودونکي لخوا چمتو شوي ډیټا څخه اخیستل شوي چې ډیری وختونه وو ، ایا موږ به ووایو ، حیرانتیا. خو کله چې ما اصلي معلومات وکتل نو معلومه شوه چې دا نیټې د جنوري 1، 2011 او د 1 کال د جنوري 2007 دي. ما فکر کاوه چې دا بګ په هغه پروګرام کې شتون لري چې ما یوازې لیکلی و، مګر دا معلومه شوه چې دا دمخه 30 کاله وه. زوړ دا ممکن د هغو کسانو لپاره پراسرار وي چې د سافټویر ایکوسیستم سره نا اشنا وي. د پیسو ګټلو لپاره د بل شرکت د اوږدې مودې پریکړې له امله، زما پیرودونکي ما ته پیسې راکړې چې یوه بګ حل کړم چې یو شرکت په تصادفي او بل په قصدي ډول معرفي کړی و. د دې لپاره چې تاسو پوه شئ چې زه د څه په اړه خبرې کوم، زه اړتیا لرم د هغه شرکت په اړه وغږیږم چې هغه خصوصیت یې اضافه کړی چې د بګ کیدو پای ته رسیدلی، په بیله بیا یو څو نورې په زړه پورې پیښې چې ما په هغه پراسرار بګ کې مرسته کړې چې ما یې حل کړی.

په ښه پخوانیو ورځو کې، د ایپل کمپیوټرونه به ځینې وختونه په ناڅاپي ډول خپل نیټه د جنوري 1، 1904 ته بیا وټاکي. دلیل یې ساده و: دا د نیټې او وخت تعقیبولو لپاره د بیټرۍ لخوا چلول شوی "سیسټم ساعت" کارولی. څه پیښ شوي کله چې بیټرۍ مړه شوه؟ کمپیوټر د یوې دورې له پیل راهیسې د ثانیو په شمیره نیټه تعقیب پیل کړ. د epoch له مخې موږ د اصلي نیټې حوالې ته اشاره کوو، او د مکینټوس لپاره دا د جنوري 1، 1904 وه. او وروسته له دې چې بیټرۍ مړ شوه، اوسنی نیټه ټاکل شوې نیټه بیا تنظیم شوه. خو ولې داسې وشول؟

پخوا، ایپل د اصلي نیټې راهیسې د ثانیو شمیر ذخیره کولو لپاره 32 بټونه کارول. یو بټ کولی شي د دوو ارزښتونو څخه یو ذخیره کړي - 1 یا 0. دوه بټ کولی شي د څلورو ارزښتونو څخه یو ذخیره کړي: 00، 01، 10، 11. درې بټ - یو له اتو څخه یو ارزښت: 000، 001، 010، 011، 100 , 101, 110, 111, etc. او 32 کولی شي د 232 ارزښتونو څخه یو ذخیره کړي، دا 4 ثانیې دي. د ایپل نیټو لپاره، دا د 294 کلونو سره مساوي دی، نو زاړه ماک نشي کولی د 967 وروسته نیټې اداره کړي. او که د سیسټم بیټرۍ مړ شي ، نیټه د دورې له پیل راهیسې 296 ثانیو ته بیا تنظیم کیږي ، او تاسو باید په لاسي ډول نیټه وټاکئ هرکله چې تاسو کمپیوټر چالان کړئ (یا تر هغه چې تاسو نوې بیټرۍ واخلئ).

په هرصورت، د ایپل پریکړه د وخت راهیسې د ثانیو په توګه د نیټې ذخیره کول پدې معنی دي چې موږ نشو کولی د وخت څخه مخکې نیټې اداره کړو، کوم چې لیرې پایلې درلودې، لکه څنګه چې موږ به یې وګورو. ایپل یو ځانګړتیا معرفي کړه، نه بګ. د نورو شیانو په مینځ کې، د دې معنی دا وه چې د مکینتوش عملیاتي سیسټم د "میلینیم بګ" څخه معاف و (کوم چې د ډیری میک غوښتنلیکونو په اړه نشي ویل کیدی چې د محدودیتونو مخنیوي لپاره خپل تاریخ سیسټمونه لري).

وړاندې ځه. موږ لوټس 1-2-3، د IBM "وژونکي غوښتنلیک" څخه کار واخیست چې د PC انقلاب په پیل کې یې مرسته وکړه، که څه هم د ایپل کمپیوټرونو VisiCalc درلود، چې شخصي کمپیوټر یې بریالی کړ. په عادلانه توګه، که چیرې 1-2-3 نه وي ښکاره شوی، کمپیوټر به په سختۍ سره له مینځه تللی وای، او د شخصي کمپیوټر تاریخ به په بل ډول وده کړې وای. لوټس 1-2-3 په غلط ډول 1900 د لیپ کال په توګه چلند وکړ. کله چې مایکروسافټ خپل لومړی سپریڈ شیټ خپور کړ، ملټيپلان، دا د بازار لږه برخه ونیوله. او کله چې دوی د ایکسل پروژه پیل کړه ، دوی پریکړه وکړه چې نه یوازې د لوټس 1-2-3 څخه د قطار او کالم نومونې سکیم کاپي کړي ، بلکه د 1900 سره په قصدي ډول د لیپ کال په توګه چلند کولو سره د بګ مطابقت ډاډمن کړي. دا ستونزه نن ورځ هم شتون لري. دا دی، په 1-2-3 کې دا یوه بګ وه، مګر په Excel کې دا یو شعوري پریکړه وه چې ډاډ ترلاسه کړي چې ټول 1-2-3 کاروونکي کولی شي خپل میزونه د ډاټا بدلولو پرته Excel ته وارد کړي، حتی که دا غلط وي.

خو بله ستونزه وه. لومړی، مایکروسافټ د Macintosh لپاره Excel خپور کړ، کوم چې د جنوري 1، 1904 څخه مخکې نیټه نه پیژني. او په Excel کې، د جنوري 1، 1900 د دور پیل ګڼل کیږي. له همدې امله ، پراختیا کونکو یو بدلون رامینځته کړ ترڅو د دوی برنامه د دورې ډول وپیژني او د مطلوب دور سره سم په خپل ځان کې ډیټا ذخیره کړي. مایکروسافټ حتی پدې اړه توضیحي مقاله لیکلې. او دا پریکړه زما د خرابۍ لامل شوه.

زما د ETL سیسټم د پیرودونکو څخه د Excel سپریډ شیټونه ترلاسه کړي چې په وینډوز کې رامینځته شوي ، مګر په میک کې هم رامینځته کیدی شي. له همدې امله، په جدول کې د دورې پیل کیدای شي د جنوري 1، 1900، یا د جنوري 1، 1904 وي. څنګه معلومه کړو؟ د ایکسل فایل ب formatه اړین معلومات ښیې ، مګر هغه پارسر چې ما کارولی و نه ښیې (اوس یې کوي) ، او داسې انګیرل کیږي چې تاسو د ځانګړي میز لپاره دورې پیژنئ. ما شاید د ایکسل بائنری ب formatه په پوهیدو او د پارسر لیکوال ته د پیچ ​​لیږلو ډیر وخت تیر کړی وی ، مګر ما د پیرودونکي لپاره ډیر څه کول درلودل ، نو ما په چټکۍ سره د دورې ټاکلو لپاره یو هوریستیک لیکلی و. هغه ساده وه.

په Excel کې، د جولای 5، 1998 نیټه د "07-05-98" (د امریکا بې ګټې سیسټم)، "د جولای 5، 98"، "د جولای 5، 1998"، "5-Jul-98" یا ځینې ​​​​نور فارمیټ. یو بل بې کاره بڼه (په ستم سره، یو له هغه فارمیټونو څخه چې زما د Excel نسخه وړاندیز نه کاوه ISO 8601 وه). په هرصورت، په جدول کې، ناببره نیټه د epoch-35981 لپاره "1900" یا د epoch-34519 لپاره "1904" په توګه زیرمه شوې (شمیرې د دورې راهیسې د ورځو شمیر څرګندوي). ما په ساده ډول د فارمیټ شوي نیټې څخه کال استخراج لپاره ساده پارسر کارولی ، او بیا د غیر فارمیټ شوي نیټې څخه کال ایستلو لپاره د Excel پارسر کارولی. که دواړه ارزښتونه د 4 کلونو لخوا توپیر ولري، نو زه پوهیدم چې زه د epoch-1904 سره یو سیسټم کاروم.

ولې ما یوازې فارمیټ شوي نیټې نه کارولې؟ ځکه چې د جولای 5، 1998 کیدای شي د "جولای، 98" په توګه د میاشتې له لاسه ورکولو سره بڼه ولري. موږ د ډیری شرکتونو څخه میزونه ترلاسه کړل چې دوی یې په ډیری بیلابیلو لارو رامینځته کړي چې دا زموږ پورې اړه لري (په دې حالت کې، زه) د نیټې معلومول. سربیره پردې ، که اکسل دا سم ترلاسه کړي ، نو موږ هم باید!

په ورته وخت کې زه له 39082 سره مخ شوم. اجازه راکړئ تاسو ته یادونه وکړم چې لوټس 1-2-3 1900 یو لیپ کال ګڼلی و، او دا په اکسیل کې په وفادارۍ سره تکرار شوی. او له هغه وخته چې دا په کال 1900 کې یوه ورځ اضافه شوه، د نیټې د محاسبې ډیری فعالیتونه د همدې ورځې لپاره غلط کیدی شي. دا دی، 39082 کیدای شي د جنوري 1، 2011 (په Macs کې) یا د دسمبر 31، 2006 (په وینډوز کې) وي. که زما "کال پارسر" د فارمیټ شوي ارزښت څخه 2011 کال راوباسي، نو هرڅه سم دي. مګر څنګه چې د ایکسل پارسر نه پوهیږي چې کوم دور کارول کیږي، دا د epoch-1900 لپاره ډیفالټ کیږي، د 2006 کال بیرته راګرځي. زما غوښتنلیک ولیدل چې توپیر 5 کاله و، دا یې یوه تېروتنه وګڼله، دا یې لاګ کړ، او یو غیر فارمیټ ارزښت یې بیرته ورکړ.

د دې شاوخوا ترلاسه کولو لپاره ، ما دا لیکلی (سیډوکوډ):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

او بیا ټول 40 نیټې په سمه توګه تجزیه شوې.

د لوی چاپ کارونو په مینځ کې

د 1980 لسیزې په لومړیو کې، زما پلار د ذخیره کولو ټیکنالوژۍ کې کار کاوه، یوه اوسنۍ څانګه چې د تیز رفتار ټیپ تغذیه کولو لپاره د ټیپ ډرایو او نیوماتیک سیسټمونه رامینځته کړي.

دوی ډرایو بیا ډیزاین کړي ترڅو دوی وکولی شي یو مرکزي "A" ډرایو ولري چې له اوو "B" ډرایو سره وصل وي ، او په RAM کې کوچني OS چې "A" ډرایو کنټرولوي کولی شي ټولو "B" ډرایو ته د لوستلو او لیکلو عملیات وټاکي.

هرکله چې "A" ډرایو پیل شو، نو اړینه وه چې د "A" سره تړل شوي پریفیریل ډرایو کې د فلاپي ډیسک داخل کړئ ترڅو عملیاتي سیسټم په حافظه کې بار کړي. دا خورا ابتدايي وه: د کمپیوټر ځواک د 8-bit مایکرو کنټرولر لخوا چمتو شوی و.

د دې ډول تجهیزاتو هدف لرونکي لیدونکي هغه شرکتونه وو چې د ډیټا لوی ګودامونه لري - بانکونه ، پرچون زنځیرونه او نور - چې د ډیری پتې لیبلونو یا بانک بیاناتو چاپ کولو ته اړتیا لري.

یو پیرودونکي ستونزه درلوده. د چاپ کار په مینځ کې، یو ځانګړی ډرایو "A" کولی شي کار ودروي، د ټول کار د بندیدو لامل کیږي. د ډرایو عملیات بحالولو لپاره، کارمندان باید هرڅه ریبوټ کړي. او که دا د شپږ ساعته کار په مینځ کې پیښ شي، نو د کمپیوټر ډیر ګران وخت ضایع شوی او د ټول عملیات مهال ویش ګډوډ شوی.

تخنیکران د ذخیره کولو ټیکنالوژیو څخه لیږل شوي. مګر د دوی د غوره هڅو سره سره، دوی ونه توانیدل چې د ازموینې شرایطو لاندې بګ بیا تولید کړي: داسې بریښي چې د لوی چاپ کارونو په مینځ کې پیښیږي. ستونزه د هارډویر نه وه، دوی هر هغه څه چې دوی یې کولی شي ځای په ځای کړي: RAM، مایکرو کنټرولر، فلاپي ډرایو، د ټیپ ډرایو هره د پام وړ برخه - ستونزه دوام لري.

بیا تخنیکانو مرکزي دفتر ته بلنه ورکړه او متخصص یې وبلل.

ماهر یوه څوکۍ او یوه پیاله قهوه ونیوله، د کمپیوټر په خونه کې کېناست - په دې ورځو کې کمپیوټرونو ته ځانګړې خونې وې - او د کارکونکو په کتار کې یې د چاپ لوی کار ته کتل. ماهر د ناکامۍ پیښیدو ته په تمه و - او دا یې وکړ. ټولو ماهر ته وکتل، مګر هغه نه پوهیده چې ولې دا پیښیږي. نو هغه امر وکړ چې دنده بیا په قطار کې ودرول شي، او ټول کارمندان او تخنیکران بیرته کار ته راستانه شول.

ماهر بیا په څوکۍ کېناست او د ناکامۍ انتظار یې پیل کړ. شاوخوا شپږ ساعته تېر شول او ناکامي رامنځته شوه. متخصص بیا هیڅ نظر نه درلود، پرته له دې چې هر څه د خلکو څخه ډکه خونه کې پیښ شوي. هغه امر وکړ چې ماموریت بیا پیل شي، بیرته ناست او انتظار یې وکړ.

د دریمې ناکامۍ سره، متخصص یو څه ولیدل. ناکامي هغه وخت رامنځ ته شوه کله چې پرسونل په بهرني ډرایو کې ټیپونه بدل کړل. برسېره پر دې، ناکامي هغه وخت رامنځ ته شوه کله چې یو کارمند په فرش کې د یو ځانګړي ټیل څخه تیر شو.

پورته شوی پوړ د المونیم ټایلونو څخه جوړ شوی و چې د 6 څخه تر 8 انچو لوړوالی کې ایښودل شوی و. د کمپیوټرونو ډیری تارونه د پورته شوي پوړ لاندې تیریدل ترڅو څوک په ناڅاپي ډول په مهم کیبل باندې د قدم وهلو مخه ونیسي. ټایلونه خورا ټینګ ایښودل شوي ترڅو د پورته پوړ لاندې د کثافاتو مخه ونیسي.

ماهر پوه شو چې د ټیلونو څخه یو یې خراب شوی و. کله چې یو کارمند د هغې کونج ته قدم کیښود، د ټایلونو څنډې د نږدې ټیلونو په وړاندې مسح شوې. هغه پلاستیکي برخې چې ټایلونه یې وصل کړي هم له دوی سره مسح شوي، کوم چې د جامد مایکرو ډیسچارجونو لامل کیږي چې د راډیو فریکونسۍ مداخله رامینځته کوي.

نن ورځ، رام د راډیو فریکوینسي مداخلې څخه خورا ښه ساتل کیږي. خو په هغو کلونو کې داسې نه وه. ماهر پوه شو چې دا مداخله حافظه ګډوډوي، او د دې سره د عملیاتي سیسټم عملیات. هغه د ملاتړ خدمت ته بلنه ورکړه، نوي ټیلونه یې امر کړل، پخپله یې نصب کړل، او ستونزه ورکه شوه.

دا لوړ څاڅکی دی!

کیسه په پورټسموت (زما په اند) کې د دفتر په څلورم یا پنځم پوړ کې د ډاکس په سیمه کې د سرور خونه کې وشوه.

یوه ورځ د یونیکس سرور د اصلي ډیټابیس سره ټکر شو. دوی هغه بیا پیل کړ، مګر هغه په ​​​​خوښۍ سره بیرته راښکته کیدو ته دوام ورکړ. موږ پریکړه وکړه چې د ملاتړ خدمت څخه یو چا ته زنګ ووهو.

ملاتړی سړی ... زما په اند د هغه نوم مارک و، مګر دا مهمه نده ... زه فکر نه کوم چې زه هغه پیژنم. دا مهمه نده، واقعا. راځئ چې د مارک سره ودریږو، سمه ده؟ غوره.

نو، یو څو ساعته وروسته مارک راورسید (دا د لیډز څخه پورټسموت ته اوږده لاره نه ده، تاسو پوهیږئ)، سرور یې بدل کړ او هرڅه پرته له ستونزو کار کوي. عادي زیانمن ملاتړ، پیرودونکي پدې اړه ډیر خپه کیږي. مارک د لاګ فایلونو له لارې ګوري او هیڅ شی نه پیدا کوي. نو مارک بیرته په ریل ګاډي کې راښکته شو (یا د ټرانسپورټ په کوم ډول چې هغه ته رسیدلی و ، دا د ټولو لپاره چې زه پوهیږم یوه لنګه غوا وه ... په هرصورت ، دا مهمه نده ، سمه ده؟) او بیرته لیډز ته ځي ، له ضایع کیدو وروسته. ورځ.

په هماغه ماښام سرور بیا ټکر کوي. کیسه همداسې ده... سرور نه پورته کېږي. مارک هڅه کوي په لیرې توګه مرسته وکړي، مګر پیرودونکي نشي کولی سرور پیل کړي.

یو بل ریل ګاډی، بس، د لیمون مرینګ یا کوم بل کریپ، او مارک بیرته په پورټسموت کې دی. وګورئ، سرور پرته له کومې ستونزې بوټ کوي! معجزه. مارک څو ساعته وخت تیروي چې وګوري چې هرڅه د عملیاتي سیسټم یا سافټویر سره سم دي او لیډز ته ځي.

د ورځې په مینځ کې سرور خرابیږي (دا اسانه کړئ!). دا ځل دا مناسب بریښي چې د سرور ځای په ځای کولو لپاره د هارډویر ملاتړ خلک راوړي. مګر نه، شاوخوا 10 ساعته وروسته دا هم راځي.

وضعیت د څو ورځو لپاره تکرار شو. سرور کار کوي، شاوخوا 10 ساعته وروسته خرابیږي او د راتلونکو 2 ساعتونو لپاره نه پیل کیږي. دوی یخ کول ، د حافظې لیکونه چیک کړل ، دوی هرڅه چیک کړل ، مګر هیڅ یې ونه موندل. بیا ټکرونه ودرول شول.

هفته بې پروا تیره شوه... هرڅوک خوشحاله وو. خوشحاله تر هغه چې دا ټول بیا پیل شي. انځور همداسې دی. 10 ساعته کار، 2-3 ساعته ځنډول ...

او بیا یو څوک (زه فکر کوم چې دوی ما ته وویل چې دا سړی د آی ټي سره هیڅ تړاو نلري) وویل:

"دا توپان دی!"

عجبه د خالي ستورو سره ولیدل شوه، او د یو چا لاس شاید د امنیتي کال تڼۍ کې ځړول.

"دا د څپو سره کار ودروي."

دا به د آی ټي مالتړ کارمندانو ته په بشپړ ډول بهرنۍ مفکوره ښکاري ، څوک چې امکان نلري د قهوې لپاره ناست په وخت کې د جوار کال کتاب ولولي. دوی څرګنده کړه چې دا په هیڅ ډول د جوار سره تړاو نلري، ځکه چې سرور د یوې اونۍ لپاره پرته له ناکامۍ کار کاوه.

"تیره اونۍ اورښت ټیټ و، مګر دا اونۍ لوړه ده."

د هغو کسانو لپاره یو کوچنی اصطلاحات چې د بیړۍ جواز نلري. جوار د قمري دورې پورې اړه لري. او لکه څنګه چې ځمکه گردش کوي، په هر 12,5 ساعتو کې د لمر او سپوږمۍ جاذبه کشش د سمندر څپې رامینځته کوي. د 12,5-ساعت دورې په پیل کې یو لوړ څپې شتون لري، د دورې په مینځ کې یو ایب شتون لري، او په پای کې بیا لوړ اورښت دی. مګر لکه څنګه چې د سپوږمۍ مدار بدلیږي، نو د ټیټ او لوړ لمر ترمنځ توپیر هم کوي. کله چې سپوږمۍ د لمر او ځمکې تر منځ وي یا د ځمکې په مقابل لوري کې وي (بشپړه سپوږمۍ یا سپوږمۍ نشته)، موږ د سیزیګین لوندونه ترلاسه کوو - ترټولو لوړې لوړې او تر ټولو ټیټ ټیټ لمبې. په نیمه سپوږمۍ کې موږ د کواډریچر څپې ترلاسه کوو - ترټولو ټیټ جورونه. د دواړو افراطونو ترمنځ توپیر خورا کم شوی. د سپوږمۍ دوره 28 ورځې دوام کوي: سیزیجیان - کواډریچر - سیزیجیان - کواډریچر.

کله چې تخنیکانو ته د سمندري ځواکونو ماهیت تشریح شو، دوی سمدلاسه فکر وکړ چې دوی باید پولیسو ته زنګ ووهي. او خورا منطقي. مګر دا معلومه شوه چې ملګري سم وو. دوه اونۍ دمخه، یو ویجاړونکی د دفتر څخه لرې نه و. هرکله چې څپې دا یو ټاکلي لوړوالی ته پورته کړ، د کښتۍ د رادار پوست د سرور خونې د پوړ په سطحه پای ته ورسید. او رادار (یا برقي جنګي تجهیزات، یا ځینې نور نظامي لوبو) په کمپیوټرونو کې ګډوډي رامینځته کړه.

د راکټ لپاره د الوتنې ماموریت

ما ته دنده وسپارل شوه چې د عملیاتي سیسټم نوي نسخو، کمپیلر او ژبې ته د راکټ لانچ کنټرول او نظارت سیسټم لوی (شاوخوا 400 زره لینونه) پورټ کړم. په دقیقه توګه، د سولاریس 2.5.1 څخه تر سولاریس 7 پورې، او د Verdix Ada پراختیایی سیسټم (VADS) څخه، چې په Ada 83 کې لیکل شوی، د Rational Apex Ada سیسټم ته، په Ada 95 کې لیکل شوی. VADS د Rational لخوا اخیستل شوی، او د هغې محصول و. متروک، که څه هم منطقي هڅه کړې چې د VADS-ځانګړي کڅوړو مطابقت لرونکي نسخې پلي کړي ترڅو د Apex کمپیلر ته لیږد اسانه کړي.

درې کسانو ما سره مرسته وکړه چې کوډ په پاک ډول ترتیب کړم. دا دوه اونۍ وخت ونیو. او بیا ما پخپله کار وکړ ترڅو سیسټم کار وکړي. په لنډه توګه، دا د سافټویر سیسټم ترټولو خراب جوړښت او تطبیق و چې زه ورسره مخ شوی وم، نو د بندر بشپړولو لپاره یې دوه میاشتې وخت واخیست. سیسټم بیا د ازموینې لپاره واستول شو، کوم چې څو میاشتې وخت واخیست. ما سمدلاسه هغه بګونه سم کړل چې د ازموینې پرمهال وموندل شول ، مګر د دوی شمیر په چټکۍ سره راټیټ شو (د سرچینې کوډ د تولید سیسټم و ، نو د دې فعالیت خورا معتبر کار کاوه ، ما یوازې هغه بګونه لرې کړل چې نوي کمپیلر ته د موافقت پرمهال رامینځته شوي). په نهایت کې، کله چې هرڅه لکه څنګه چې باید کار وکړي، زه بلې پروژې ته لیږدول شوی وم.

او د جمعې په ورځ د شکرانې دمخه ، تلیفون زنګ شو.

د راکټ لانچ په شاوخوا دریو اونیو کې ازمویل شوی و ، او د شمیرنې لابراتوار ازموینو په جریان کې ، د امرونو ترتیب بند شوی و. په ریښتیني ژوند کې، دا به ازموینه لغوه کړي، او که خنډ د انجن د پیل کولو په څو ثانیو کې واقع شي، په مرستندویه سیسټمونو کې به ډیری نه بدلیدونکي عملونه واقع شي، کوم چې به د راکټ اوږد - او ګران چمتووالي ته اړتیا ولري. دا به نه و پیل شوی، مګر ډیری خلک به د وخت او ډیرو پیسو د ضایع کیدو په اړه ډیر خپه شوي وي. چاته اجازه مه ورکوئ چې تاسو ته ووایي چې د دفاع وزارت پیسې په بې پروايي سره مصرفوي — ما هیڅکله د قراردادي مدیر سره نه دی لیدلی چې بودیجه یې لومړی یا دوهمه نه وي کړې، د مهال ویش سره سم.

په تیرو میاشتو کې، د شمیرنې دا ننګونه په سلګونو ځله په ډیری توپیرونو کې ترسره شوې وه، یوازې د څو کوچنیو خنډونو سره. نو د دې پیښې احتمال ډیر کم و، مګر د هغې پایلې خورا مهمې وې. دا دواړه فکتورونه ضرب کړئ، او تاسو به پوه شئ چې خبر زما او د لسګونو انجینرانو او مدیرانو لپاره د رخصتۍ ویجاړې اونۍ وړاندوینه کړې.

او ما ته د هغه چا په توګه پاملرنه شوې چې سیسټم یې پورټ کړی.

لکه څنګه چې د ډیری امنیتي - مهم سیسټمونو سره، ډیری پیرامیټونه لاګ شوي، نو دا د کوډ څو کرښې پیژندل خورا اسانه وو چې د سیسټم له غورځیدو دمخه اجرا شوي و. او البته، د دوی په اړه هیڅ غیر معمولي نه و؛ ورته څرګندونې په بریالیتوب سره د ورته دورې په جریان کې په زرګونو ځله په بریالیتوب سره ترسره شوي.

موږ خلک له اپیکس څخه منطقي ته وبلل ځکه چې دوی هغه څوک وو چې کمپیلر یې رامینځته کړی او ځینې معمولات چې دوی رامینځته کړي په شکمن کوډ کې ویل شوي. دوی (او نور هر څوک) متاثره شوي وو چې د لفظي ملي ارزښت د ستونزې ریښې ته د رسیدو اړتیا وه.

څرنګه چې په ژورنالونو کې هیڅ په زړه پورې نه و، موږ پریکړه وکړه چې دا ستونزه په محلي لابراتوار کې بیا تولید کړو. دا یو اسانه کار نه و ځکه چې پیښه په هر 1000 منډو کې نږدې یو ځل پیښیږي. یو شکمن دلیل دا و چې د پلورونکي لخوا رامینځته شوي mutex فنکشن ته زنګ وهل (د VADS مهاجرت کڅوړې برخه) Unlock د خلاصیدو لامل نه شو. د پروسس کولو تار چې د فنکشن په نوم یادیږي د زړه ضربان پیغامونه پروسس کوي، کوم چې په هره ثانیه کې راځي. موږ فریکونسۍ 10 Hz ته لوړه کړه ، دا په هره ثانیه کې 10 ځله ، او چلول یې پیل کړل. شاوخوا یو ساعت وروسته سیسټم پخپله بند شو. په لاګ کې، موږ ولیدل چې د ثبت شوي پیغامونو ترتیب د ناکامې ازموینې په څیر ورته و. موږ څو نورې منډې جوړې کړې، سیسټم په دوامداره توګه د پیل څخه 45-90 دقیقې وروسته بند شو، او هر ځل چې لاګ ورته لاره درلوده. که څه هم موږ په تخنیکي ډول مختلف کوډ چلولو - د پیغام فریکونسۍ توپیر درلود - د سیسټم چلند یو شان و، نو موږ ډاډه یو چې د بار بار سناریو ورته ستونزې رامینځته کوي.

اوس موږ دې ته اړتیا لرو چې معلومه کړو چې واقعیا د بیانونو په ترتیب کې بلاک کول چیرته پیښ شوي.

د دې سیسټم پلي کول د اډا کاري سیسټم کارولی، او دا یې په ناقانونه توګه خرابه کارولې. دندې په اډا کې د لوړې کچې په ورته وخت کې د اجرا وړ جوړښت دی، یو څه لکه د اجرا کولو تارونو په څیر، یوازې پخپله ژبه کې جوړ شوی. کله چې دوه دندې خبرو اترو ته اړتیا ولري ، دوی "یوه ناسته تنظیموي" ، اړین معلومات تبادله کوي ، او بیا ناسته بندوي او خپلو خپلواکو اجرااتو ته راستنیږي. په هرصورت، سیسټم په بل ډول پلي شوی. وروسته له دې چې یو هدف شوی وظیفه په لاره واچول شوه، هغه هدف وظیفه د بل کار سره یوځای کیږي، چې بیا د دریم کار سره یوځای کیږي، او داسې نور تر هغه چې یو څه پروسس بشپړ شوی وي. له دې وروسته دا ټول ملاقاتونه پای ته ورسېدل او هر کار باید خپل اجرا ته راستون شو. دا دی، موږ په نړۍ کې د خورا ګران فنکشن کال سیسټم سره معامله کوله، کوم چې د "ملټي ټاسک کولو" ټوله پروسه بنده کړه پداسې حال کې چې دا د ان پټ ډیټا برخه پروسس کوي. او مخکې له دې نه یوازې د ستونزو لامل شوی ځکه چې د تولید کچه خورا ټیټه وه.

ما د دې کاري میکانیزم تشریح کړی ځکه چې کله د ناستې غوښتنه شوې یا تمه کیږي چې بشپړ شي، د "ټاسک سویچ" واقع کیدی شي. دا دی، پروسیسر کولی شي د بل کار پروسس پیل کړي چې اجرا کولو ته چمتو وي. دا معلومه شوه چې کله یو کار د بل کار سره یوځای کیدو ته چمتو وي، یو بشپړ مختلف کار کولی شي اجرا کول پیل کړي، او په نهایت کې کنټرول بیرته لومړي ناستې ته راستانه شي. او نورې پیښې ممکن واقع شي چې د دندې د بدلیدو لامل شي؛ یوه ورته پیښه د سیسټم فعالیت ته زنګ وهل دی ، لکه د میوټیک چاپ کول یا اجرا کول.

د دې لپاره چې پوه شوم چې د کوډ کومه کرښه ستونزه رامینځته کوي ، ما اړتیا درلوده چې د بیانونو د ترتیب له لارې پرمختګ ثبتولو لپاره لاره ومومئ پرته لدې چې د ټاسک سویچ رامینځته کړي ، کوم چې به د پیښې کیدو مخه ونیسي. نو زه نشم کولی ګټه پورته کړم Put_Line()د I/O عملیاتو ترسره کولو څخه مخنیوی لپاره. زه کولی شم د کاونټر متغیر یا ورته یو څه تنظیم کړم ، مګر زه څنګه کولی شم د دې ارزښت وګورم که زه نشم کولی دا په سکرین کې ښکاره کړم؟

همچنان ، کله چې د لاګ معاینه کول ، دا معلومه شوه چې د زړه د ټکان پیغامونو پروسس کولو کې د کنګل کیدو سره سره ، کوم چې د پروسې ټول I/O عملیات بند کړي او د نورو پروسس کولو مخه یې نیولې ، نورې خپلواکې دندې اجرا کولو ته دوام ورکوي. دا دی، کار په بشپړه توګه بند شوی نه و، یوازې د دندو (مهم) سلسله.

دا د بلاک کولو بیان ارزولو لپاره اړین نښه وه.

ما د اډا بسته جوړه کړه چې پکې دنده، یو شمیرل شوی ډول، او د دې ډول نړیوال متغیر شامل وو. بې شمیره لیکونه د ستونزمن ترتیب ځانګړي بیانونو پورې تړلي وو (د بیلګې په توګه Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked)، او بیا یې په دې کې د تفویض څرګندونې داخلې کړې چې اړونده شمیره یې نړیوال متغیر ته ټاکلې. څرنګه چې د دې ټولو اعتراض کوډ په ساده ډول په حافظه کې ساتل شوی، د دې د اجرا کولو په پایله کې د دندې بدلول خورا ناشونی و. موږ په ابتدايي توګه د څرګندونو په اړه شکمن وو چې کولی شي دنده بدله کړي، ځکه چې بلاک کول د بیرته راستنیدو پر ځای په اجرا کې واقع شوي کله چې د دندې بیرته بدلول (د څو دلیلونو لپاره).

د تعقیب دنده په ساده ډول په لوپ کې روانه وه او په دوره توګه یې چک کول ترڅو وګوري چې ایا د نړیوال متغیر ارزښت بدل شوی. د هر بدلون سره، ارزښت په فایل کې خوندي شوی. بیا یو لنډ انتظار او یو نوی چک. ما فایل ته متغیر لیکلی ځکه چې دنده یوازې هغه وخت اجرا شوې وه کله چې سیسټم دا د اجرا کولو لپاره غوره کړي کله چې د ستونزې په ساحه کې دنده بدلوي. هر هغه څه چې په دې دنده کې پیښ شوي به په نورو، غیر تړلي بلاک شوي کارونو اغیزه ونکړي.

تمه کیده چې کله سیسټم د ستونزې کوډ اجرا کولو نقطې ته ورسیږي، نړیوال متغیر به بیا تنظیم شي کله چې هر بل بیان ته حرکت وکړي. بیا به یو څه پیښ شي چې د دندې بدلولو لامل کیږي ، او څنګه چې د هغې د اجرا کولو فریکونسۍ (10 Hz) د نظارت دندې څخه ټیټه ده ، نو مانیټور کولی شي د نړیوال متغیر ارزښت ونیسي او لیک یې کړي. په نورمال حالت کې ، زه کولی شم د شمیرو د فرعي سیټ تکرار ترتیب ترلاسه کړم: د ټاسک سویچ په وخت کې د متغیر وروستي ارزښتونه. کله چې ځړول کیږي، نړیوال متغیر باید نور بدلون ونلري، او وروستی لیکل شوی ارزښت به په ګوته کړي چې کوم بیان بشپړ شوی نه دی.

ما د تعقیب سره کوډ چل کړ. هغه یخ شو. او نظارت د ساعت کار په څیر کار کاوه.

په لاګ کې متوقع ترتیب شامل و، کوم چې د یو ارزښت لخوا مداخله شوې وه چې دا په ګوته کوي چې یو میټیکس بلل شوی و. Unlock، او دنده بشپړه شوې نه ده - لکه څنګه چې د زرګونو پخوانیو تلیفونونو سره قضیه ده.

د اپیکس انجینرانو په دې وخت کې د دوی کوډ په تبه سره تحلیل کاوه او په میټیکس کې یې یو ځای وموند چیرې چې په تیوریکي توګه یو قفل واقع کیدی شي. مګر د دې احتمال خورا ټیټ و، ځکه چې یوازې په یو ټاکلي وخت کې د پیښو یو مشخص ترتیب کولی شي د بندیدو لامل شي. د مرفي قانون، هلکانو، دا د مرفي قانون دی.

د کوډ برخې خوندي کولو لپاره چې زه ورته اړتیا لرم ، ما د میوټیکس فنکشن کالونه (د OS میوټیکس فعالیت په سر کې جوړ شوي) د کوچني اصلي اډا میوټیکس کڅوړې سره ځای په ځای کړل ترڅو دې برخې ته د میوټیک لاسرسي کنټرول کړي.

ما دا کوډ کې دننه کړ او ازموینه یې واخیسته. اوه ساعته وروسته کوډ لاهم کار کاوه.

زما کوډ ریشنل ته سپارل شوی و، چیرې چې دوی یې تالیف کړی، جلا یې کړی، او چک یې کړی چې دا ورته طریقه نه کاروي چې د ستونزمن میټیکس کارونو کې کارول کیږي.

دا زما د مسلک تر ټولو د ګڼې ګوڼې کوډ بیاکتنه وه 🙂 زما سره په کوټه کې شاوخوا لس انجینران او مدیران وو، نور لس کسان په کنفرانس کې وو - او دوی ټولو د کوډ شاوخوا 20 کرښې معاینه کړې.

کوډ بیاکتنه شوې، نوي اجرایوي فایلونه راټول شوي او د رسمي راجستر ازموینې لپاره سپارل شوي. څو اونۍ وروسته، د شمېرنې ازموینه بریالۍ شوه او راکټ وتوغول شو.

سمه ده، دا ټول ښه او ښه دي، مګر د کیسې معنی څه ده؟

دا په بشپړه توګه بې رحمه ستونزه وه. د کوډونو سلګونه زره کرښې، موازي اجرا، له درجن څخه زیات متقابل عمل، ضعیف جوړښت او ضعیف تطبیق، د سرایت شوي سیسټمونو لپاره انٹرفیسونه او ملیونونه ډالر مصرف شوي. هیڅ فشار نشته، سمه ده.

زه یوازینی کس نه وم چې پدې ستونزې کار کاوه ، که څه هم زه د پورټینګ کولو پرمهال په پام کې وم. مګر که څه هم ما دا وکړل، د دې معنی دا نه ده چې زه د کوډ ټول سل زره لینونه پوهیدم، یا حتی دوی سکیم کړي. کوډ او لاګونه په ټول هیواد کې د انجینرانو لخوا تحلیل شوي، مګر کله چې دوی ماته د ناکامۍ د لاملونو په اړه خپل فرضیه بیان کړه، ما یوازې نیم دقیقې وخت واخیست چې رد کړم. او کله چې له ما څخه د تیوریو تحلیل کولو غوښتنه وشوه، زه به یې بل چا ته وسپارم، ځکه چې دا زما لپاره څرګنده وه چې دا انجینران په غلطه لاره روان وو. مغرور غږ؟ هو، دا ریښتیا ده، مګر ما د بل دلیل لپاره فرضیه او غوښتنې رد کړې.

زه د ستونزې په ماهیت پوهیدم. زه دقیقا نه پوهیدم چې دا چیرې پیښیږي یا ولې ، مګر زه پوهیږم چې څه پیښیږي.

په تیرو کلونو کې، ما ډیره پوهه او تجربه راټوله کړه. زه د اډا د کارولو مخکښانو څخه وم او د هغې په ګټو او زیانونو پوهیدم. زه پوهیږم چې د اډا د وخت کتابتونونه څنګه دندې اداره کوي او د موازي اجرا کولو سره معامله کوي. او زه د حافظې ، راجسترونو او جمع کونکي په کچه د ټیټ کچې برنامې پوهیږم. په بل عبارت، زه په خپله ساحه کې ژوره پوهه لرم. او ما دوی د ستونزې لامل موندلو لپاره وکارول. ما یوازې د بګ شاوخوا کار نه دی کړی، زه پوهیدم چې دا څنګه په خورا حساس وخت چاپیریال کې ومومئ.

د کوډ سره د مبارزې دا ډول کیسې د هغو کسانو لپاره په زړه پورې ندي چې د دې ډول مبارزې له ځانګړنو او شرایطو سره بلد نه وي. مګر دا کیسې موږ سره مرسته کوي پوه شو چې واقعیا د سختو ستونزو حل کولو لپاره څه اړتیا لري.

د واقعیا سختو ستونزو حل کولو لپاره ، تاسو اړتیا لرئ یوازې د یو پروګرامر څخه ډیر اوسئ. تاسو اړتیا لرئ د کوډ "برخلیک" پوه شئ، دا څنګه د دې چاپیریال سره تعامل کوي، او چاپیریال پخپله څنګه کار کوي.

او بیا به تاسو د خپل تخریب شوي رخصتۍ اونۍ ولرئ.

دوام ته دوام ورکول.

سرچینه: www.habr.com