Программисттердин жана инженерлердин фольклору (1-бөлүк)

Программисттердин жана инженерлердин фольклору (1-бөлүк)

Бул каталардын кээде укмуштуудай көрүнүштөрү тууралуу Интернеттеги окуялардын тандоосу. Балким сиздин да айта турган нерсеңиз бардыр.

Ваниль балмуздактарына унаа аллергиясы

Ачык-айкын нерсе ар дайым эле жооп боло бербестигин жана фактылар канчалык алыс көрүнбөсүн, баары бир чындык экенин түшүнгөн инженерлер үчүн окуя. General Motors корпорациясынын Понтиак бөлүмү даттануу алды:

Мен сага экинчи жолу жазып жатам, жооп бербегениң үчүн сени күнөөлөгөн жокмун, анткени бул жинди угулат. Биздин үй-бүлөдө ар күнү кечки тамактан кийин балмуздак жеген салт бар. Балмуздактын түрлөрү ар дайым өзгөрүп турат, кечки тамактан кийин бүт үй-бүлө кайсы балмуздак сатып алууну тандашат, андан кийин мен дүкөнгө барам. Мен жакында жаңы Pontiac сатып алдым, ошондон бери балмуздак алууга болгон сапарларым көйгөйгө айланды. Көрдүңүзбү, мен ванильдүү балмуздак сатып алып, дүкөндөн келген сайын машина отпойт. Башка балмуздак алып келсем, машина эч кандай кыйынчылыксыз ишке кирет. Канчалык акылсыз угулбасын, мен олуттуу суроо бергим келет: "Понтиактын эмнеси мен ванильдүү балмуздак алып келгенде башталбай, балмуздактын башка даамын алып келгенде оңой башталат?"

Сиз элестетип тургандай, бөлүмдүн президенти катка шектенген. Бирок, кандай болгон күндө да мен инженерди текшерүүгө жибердим. Анын алдынан кооз жерде жашаган бай, билимдүү адам чыкканына таң калды. Экөө дүкөнгө балмуздак жеш үчүн кечки тамактан кийин дароо жолугууга макул болушту. Ошол күнү кечинде ваниль болчу, алар кайра машинага отурушканда ал иштебей калды.

Инженер дагы үч жолу кечинде келди. Биринчи жолу балмуздак шоколад болгон. Машина башталды. Экинчи жолу кулпунай балмуздак болду. Машина башталды. Үчүнчү күнү кечинде ал ванилин алууну суранды. Машина откон жок.

Акылдуу ой жүгүрткөн инженер машинада ванильдүү балмуздактан аллергия бар дегенге ишенүүдөн баш тартты. Ошондуктан, мен машинанын ээси менен макулдаштым, ал маселенин бир жолун тапмайынча сапарларын уланта берет. Жолдо баратып, ал жазып баштады: бардык маалыматтарды, сутканын убактысын, бензиндин түрүн, дүкөндөн келген жана кайткан убактысын ж.б.

Инженер көп өтпөй унаанын ээси ванильдүү балмуздак сатып алууга азыраак убакыт короторун түшүнгөн. Буга дүкөндөгү товарлардын макети себеп болгон. Ваниль балмуздак эң популярдуу болгон жана аны оңой табуу үчүн дүкөндүн маңдайындагы өзүнчө тоңдургучта сакталган. Ал эми калган бардык сорттор дүкөндүн арткы жагында болчу, туура сортту табуу жана төлөө үчүн дагы көп убакыт талап кылынды.

Эми инженерге суроо туулду: кыймылдаткыч өчүрүлгөн учурдан бери аз убакыт өтүп кетсе, эмне үчүн машина иштебей калды? Көйгөй ванильдүү балмуздак эмес, убакытта болгондуктан, инженер тез эле жооп тапты: бул газ кулпусу. Бул күн сайын кечинде болгон, бирок унаа ээси балмуздак издөөгө көбүрөөк убакыт сарптаганда, мотор жетиштүү муздап, оңой эле иштей баштаган. Ал эми адам ванильдүү балмуздак сатып алганда, мотор дагы эле ысып, газ кулпусу эригенге үлгүрбөй калган.

Моралдык: Ал тургай, таптакыр жинди көйгөйлөр кээде реалдуу болуп саналат.

ката: Migrating

Муну башынан өткөрүү оор. Программист катары сиз өзүңүздүн кодуңузду биринчи, экинчи, үчүнчү... жана он миңинчи жерде компиляторду күнөөлөгөнгө көнүп каласыз. Ал эми тизменин ылдый жагында сиз жабдууларды күнөөлөп жатасыз.

Бул жерде аппараттык ката жөнүндө менин окуя.

Crash Bandicoot оюну үчүн мен эстутум картасына жүктөө жана сактоо үчүн код жаздым. Мындай шылуун оюн иштеп чыгуучу үчүн бул паркта сейилдөө сыяктуу эле: мен жумуш бир нече күнгө созулат деп ойлогом. Бирок, мен алты жума бою кодду оңдоону аяктадым. Жолдо мен башка көйгөйлөрдү чечтим, бирок бир нече күн сайын мен бир нече саатка бул кодго кайтып келдим. Бул азап эле.

Симптом төмөнкүдөй көрүндү: сиз оюндун учурдагы ойноосун сактап, эстутум картасына киргенде, бардыгы дээрлик дайыма жакшы болот... Бирок кээде окуу же жазуу операциясы эч кандай түшүнүксүз себептерден улам токтоп калат. Кыска жазуу көбүнчө эстутум картасына зыян келтирет. Оюнчу сактап калууга аракет кылганда, ал сактай албай эле койбостон, картаны да жок кылат. Crap.

Бир аз убакыт өткөндөн кийин Sonyдеги продюсерибиз Конни Бус дүрбөлөңгө түшө баштады. Биз бул мүчүлүштүк менен оюнду жөнөтө алган жокпуз жана алты жумадан кийин мен көйгөйгө эмне себеп болгонун түшүнгөн жокмун. Конни аркылуу биз башка PS1 иштеп чыгуучулары менен байланыштык: кимдир бирөө окшош нерсеге туш болдубу? Жок. Эч ким эстутум картасы менен көйгөйлөр болгон эмес.

Мүчүлүштүктөрдү оңдоо боюнча эч кандай идеяңыз жок болгондо, бир гана ыкма "бөлүү жана жеңүү" болуп саналат: көйгөйдү жаратып жаткан салыштырмалуу кичинекей фрагмент калганга чейин, туура эмес программадан барган сайын көбүрөөк кодду алып салыңыз. Башкача айтканда, мүчүлүштүктөрдү камтыган бөлүгү калганга чейин программаны бөлүк-бөлүктөн кесип саласыз.

Бирок эң негизгиси, видео оюндун бөлүктөрүн кесип алуу абдан кыйын. Гравитацияны эмуляциялаган кодду алып салсаңыз, аны кантип иштетүү керек? Же каармандарды тартуу?

Ошондуктан, биз бүт модулдарды пайдалуу бир нерсе кылып жаткандай түр көрсөткөн, бирок чындыгында каталарды камтыбаган өтө жөнөкөй бир нерсени жасашыбыз керек. Оюн жок дегенде иштеши үчүн ушундай балдактарды жазышыбыз керек. Бул жай жана азаптуу процесс.

Кыскасы, мен жасадым. Оюнду иштетүү үчүн тутумду конфигурациялоочу, рендеринг жабдыгын инициализациялоочу ж. Албетте, бул этапта мен сактоо жана жүктөө менюсун түзө алган жокмун, анткени бардык графикалык коддор үчүн stub түзүшүм керек болчу. Бирок мен өзүмдү (көрүнбөгөн) сактоо жана жүктөө экранын колдонуп, колдонуучумун деп көрсөтүп, сактоону жана эстутум картасына жазууну суранам.

Бул мага кичинекей кодду калтырды, анда дагы эле жогорудагы көйгөй бар - бирок ал дагы эле туш келди болуп жатты! Көбүнчө баары жакшы иштеген, бирок кээде каталар болгон. Мен дээрлик бардык оюн кодун алып салдым, бирок мүчүлүштүк дагы деле тирүү болчу. Бул табышмактуу болду: калган код иш жүзүндө эч нерсе кылган жок.

Качандыр бир убакта, балким, таңкы саат үчтөр чамасында мага бир ой келди. Окуу жана жазуу (киргизүү/чыгарма) операциялары так аткаруу убакыттарын камтыйт. Катуу диск, эстутум картасы же Bluetooth модулу менен иштегенде, окуу жана жазуу үчүн жооптуу төмөнкү деңгээлдеги код муну сааттын импульстарына ылайык аткарат.

Сааттын жардамы менен процессорго түз байланышпаган түзүлүш процессордо аткарылуучу код менен синхрондолот. Саат маалымат берүүнүн ылдамдыгын аныктайт. Убакыт менен баш аламандык болсо, анда аппараттык же программалык камсыздоо, же экөө тең чаташкан. Жана бул абдан жаман, анткени маалыматтар бузулушу мүмкүн.

Эгерде биздин кодубуздагы бир нерсе убакытты чаташтырсачы? Мен тестирлөө программасынын кодунда буга байланыштуу бардыгын текшерип көрдүм жана биз PS1де программалануучу таймерди 1 кГцке (секундасына 1000 кене) койгонубузду байкадым. Бул абдан көп; демейки боюнча, консол башталганда, ал 100 Гцте иштейт. Жана көпчүлүк оюндар ушул жыштыкты колдонушат.

Оюнду иштеп чыгуучу Энди кыймылдар так эсептелиши үчүн таймерди 1 кГцке койду. Энди чектен чыгып кетүүгө умтулат жана эгерде биз тартылуу күчүн туурасак, биз аны мүмкүн болушунча так кылабыз!

Бирок таймерди тездетүү кандайдыр бир түрдө программанын жалпы убактысына, демек, эстутум картасынын ылдамдыгын жөнгө салган саатка таасир этсечи?

Мен таймер кодун комментарийлеп бердим. Ката кайра пайда болгон жок. Бирок бул биз аны оңдоп койдук дегенди билдирбейт, анткени ката кокусунан болуп калды. Мен жөн гана бактылуу болсомчу?

Бир нече күндөн кийин мен тест программасы менен кайрадан эксперимент жасадым. Ката кайталанган жок. Мен оюндун толук коддук базасына кайттым жана эстутум картасына кирүү алдында программалануучу таймер баштапкы маанисине (100 Гц) кайра орношу үчүн, сактоо жана жүктөө кодун өзгөрттүм, андан кийин кайра 1кГцге кайтарылды. Мындан ары кыйроолор болгон жок.

Бирок эмне үчүн мындай болду?

Мен кайрадан тест программасына кайтып келдим. Мен 1 кГц таймер менен катанын пайда болушунун кандайдыр бир үлгүсүн табууга аракет кылдым. Акыры, ката кимдир бирөө PS1 контроллери менен ойногондо пайда болгонун байкадым. Мен муну өзүм сейрек жасай тургандыктан, сактоо жана жүктөө кодун сынап жатканда контролер эмне үчүн керек болот? - Мен бул көз карандылыкты байкаган жокмун. Бирок бир күнү биздин артисттер менин тестирлөө аякташымды күтүп жатыптыр – мен ошол маалда сөгүнүп жатсам керек – колундагы контроллерду кыжаалаттай айлантты. Ката кетти. "Токто, эмне?!" Мейли, кайра кыл!»

Бул эки окуянын бири-бири менен байланышы бар экенин түшүнгөндө, мен катаны оңой эле кайталай алдым: эстутум картасына жаздыра баштадым, контроллерди жылдырдым жана эстутум картасын талкаладым. Мен үчүн бул аппараттык ката сыяктуу көрүндү.

Мен Конниге келип, ага өзүмдүн ачылышымды айтып бердим. Ал маалыматты PS1ди иштеп чыккан инженерлердин бирине айтып берди. "Мүмкүн эмес," деп жооп берди ал, "Бул аппараттык көйгөй болушу мүмкүн эмес." Мен Конниден биз үчүн сүйлөшүү уюштурууну сурандым.

Инженер мени чакырды, биз анын бузулган англис тилинде жана менин (өтө) сынган япон тилинде талашып-тартышты. Акырында мен: "Мага 30 саптык тестирлөө программамды жөнөтөйүн, анда контроллерди жылдыруу мүчүлүштүктөрдү жаратат" дедим. Ал макул болду. Бул убакытты текке кетиргенин жана ал жаңы долбоордун үстүндө иштөө менен абдан алек экенин, бирок биз Sony үчүн абдан маанилүү иштеп чыгуучу болгонубуз үчүн багынарын айтты. Мен тестирлөө программамды тазалап, ага жөнөттүм.

Эртеси кечинде (биз Лос-Анжелесте, ал Токиодо болчу) ал мага чалып, кечирим сурады. Бул аппараттык көйгөй болгон.

Мен мүчүлүштүктүн так эмне болгонун билбейм, бирок Sony штаб-квартирасында уккандарыма караганда, эгер сиз таймерди жетишерлик жогорку мааниге койгон болсоңуз, ал таймердин кристаллына жакын жердеги аналык платадагы компоненттерге тоскоол болгон. Алардын бири эстутум картасы үчүн ылдамдыктын контроллери болгон, ал контроллерлор үчүн ылдамдыкты да койгон. Мен инженер эмесмин, ошондуктан бир нерсени бузуп алгандырмын.

Бирок негизги линия - энелик платадагы компоненттердин ортосунда кийлигишүү болгон. Ал эми контроллердин порту жана эстутум картасынын порту аркылуу 1 кГц жыштыкта ​​иштеген таймер аркылуу маалыматтарды бир убакта өткөрүп жатканда биттер жоголуп, маалыматтар жоголуп, карта бузулган.

Жаман уйлар

1980-жылдары менин устатым Сергей ПДП-1800дин советтик клону болгон SM-11 үчүн программалык камсыздоону жазган. Бул микрокомпьютер СССРдеги маанилуу транспорттук борбор болгон Свердловскинин жанындагы темир жол станциясына жакында эле орнотулду. Жацы система вагондорду жана жук ташууларды багыттоо учун иштелип чыккан. Бирок анда кокустуктарга жана кыйроого алып келген тажатма ката камтылган. Кимдир бирөө кечинде үйгө барганда дайыма кулап түшчү. Бирок эртеси кылдат иликтөөгө карабастан, компьютер бардык кол менен жана автоматтык сыноолордо туура иштеген. Бул, адатта, белгилүү бир шарттарда пайда болгон жарыш абалын же башка атаандаштык катасын көрсөтөт. Түн бир оокумда чалуулардан тажаган Сергей мунун түпкүрүнө кирүүнү чечти жана эң оболу, компьютердин бузулушуна маршалдагы кандай шарттар алып келгенин түшүндү.

Биринчиден, ал бардык түшүндүрүлбөгөн кулоолордун статистикасын чогултуп, датасы жана убактысы боюнча графикти түзгөн. Үлгү ачык эле көрүнүп турду. Дагы бир нече күн байкоо жүргүзгөндөн кийин, Сергей келечектеги системанын бузулуу убактысын оңой эле алдын ала болорун түшүндү.

Ал көп узабай станция Украинанын түндүгүнөн жана батыш Россиядан келген малды поезд жүктөрүн иргеп жаткан учурда гана үзгүлтүккө учурагандыгын билди. Мунун өзү таң калыштуу болду, анткени мал союучу жайды Казакстандан бир топ жакын жайгашкан чарбалар жеткиришкен.

1986-жылы Чернобыл атомдук электр станциясы жарылып, радиоактивдүү чачуулар анын айланасындагы аймактарды жашоого жараксыз кылып салган. Украинанын түндүгүндө, Белоруссияда жана Орусиянын батышында кеңири аймактар ​​булганган. Келген вагондордо радиациянын жогорку деңгээлинен шектенген Сергей бул теорияны текшерүүнүн ыкмасын иштеп чыккан. Калкка дозиметрлерди алууга тыюу салынгандыктан, Сергей темир жол вокзалында бир нече аскер кызматкерлерине катталган. Бир нече жолу арак ичип алгандан кийин ал жоокерди шектүү вагондордун биринде радиациянын деңгээлин өлчөөгө көндүрүүгө жетишкен. Көрсө, деңгээл нормадагыдан бир нече эсе жогору экен.

Мал радиацияны көп бөлүп чыгарганы гана эмес, анын деңгээли ушунчалык жогору болгондуктан, станциянын жанындагы имаратта жайгашкан СМ-1800дун эсинде биттердин туш келди жоголушуна алып келген.

СССРде азык-түлүк тартыштыгы болуп, бийлик Чернобылдын этин өлкөнүн башка аймактарынын этине аралаштырууну чечти. Бул баалуу ресурстарды жоготпостон радиоактивдүүлүктүн жалпы деңгээлин төмөндөтүүгө мүмкүндүк берди. Бул тууралуу билген Сергей дароо эмиграция үчүн документтерди толтурган. Ал эми радиациянын деңгээли убакыттын өтүшү менен азайганда компьютердин бузулушу өзүнөн өзү токтоду.

түтүктөр аркылуу

Бир жолу Movietech Solutions кинотеатрлар үчүн программалык камсыздоону түзүп, бухгалтердик эсепке, билеттерди сатууга жана жалпы башкарууга арналган. Флагмандык колдонмонун DOS версиясы Түндүк Америкадагы чакан жана орто өлчөмдөгү кинотеатр чынжырларынын арасында абдан популярдуу болгон. Демек, Windows 95 версиясы жарыяланганда, эң акыркы сенсордук экрандар жана өзүн-өзү тейлөө киосктары менен интеграцияланган жана ар кандай отчеттук куралдар менен жабдылганда, ал тез эле популярдуу болуп кеткени таң калыштуу эмес. Көбүнчө жаңыртуу көйгөйсүз өттү. Жергиликтүү IT кызматкерлери жаңы жабдууларды орнотушту, маалыматтарды көчүрүп, бизнести улантышты. Бул созулбаган учурларды кошпогондо. Мындай болгондо компания "Тазалыкчы" деген лакап атка ээ Жеймсти жибермек.

Лакап аты жаман түрүн көрсөтүп турат да, тазалоочу жөн гана инструктор, орнотуучу жана бардык соода-сатыктардын айкалышы. Джеймс бир нече күн кардардын сайтында бардык компоненттерди чогултуп, анан дагы бир-эки күндү кызматкерлерге жаңы системаны кантип колдонууну үйрөтүп, пайда болгон аппараттык көйгөйлөрдү чечип, программалык камсыздоого жаңыдан эле жардам берчү.

Ошондуктан, таң калыштуу эмес, ушул ызы-чуу маалында Джеймс кеңсеге эртең менен келип, ал столуна жете электе, адаттагыдан ашыкча кофеинге толуп, менеджер тосуп алды.

"Мен мүмкүн болушунча тезирээк Аннаполиске, Жаңы Шотландияга барышыңыз керек деп корком." Алардын бүт системасы иштебей калып, инженерлери менен бир түн иштегенден кийин эмне болгонун түшүнө албайбыз. Тармак серверде иштебей калды окшойт. Бирок система бир нече мүнөт иштегенден кийин гана.

— Алар эски системага кайтып келишкен жокпу? – деп жооп берди Жеймс, акылы менен таң калып көздөрүн бакырайтып.

— Так: алардын IT адиси "артыкчылыктарды өзгөрттү" жана эски сервери менен кетүүнү чечти. Джеймс, алар системаны алты сайтка орнотушкан жана жөн гана премиум колдоо үчүн төлөшкөн жана алардын бизнеси азыр 1950-жылдардагыдай башкарылууда.

Джеймс бир аз түздөлдү.

- Бул башка кеп. Макул, баштайлы.

Ал Аннаполиске келгенде биринчи жолу кардардын көйгөйү бар биринчи театрын тапкан. Аэропортто алынган картада баары жакшы көрүнгөн, бирок каалаган даректин айланасы шектүү көрүнгөн. Гетто эмес, нукура кинону эске салат. Жеймс шаардын бордюруна токтоп турганда, анын жанына сойку келди. Аннаполистин көлөмүн эске алганда, ал, кыязы, бүткүл шаарда жалгыз болгон. Анын сырткы көрүнүшү дароо эле чоң экранда акчага секс сунуштаган атактуу каарманды эстеди. Жок, Джулия Робертс жөнүндө эмес, Жон Войт жөнүндө ["Түнкү ковбой" тасмасына ишарат - болжол менен. тилке].

Сойку кызды жолго салып, Жеймс кинотеатрга жөнөдү. Айлана-чөйрө жакшырып калганы менен, ал дагы эле чөгүп бараткандай таасир калтырды. Жеймс өтө тынчсызданган эмес. Ал буга чейин жаман жерлерге барган. Ал эми бул Канада болгон, ал тургай тоноочулар капчыгыңды алгандан кийин “рахмат” деп сылык мамиле кылышат.

Кинотеатрдын капталдагы кире бериши нымдуу аллеяда болчу. Джеймс эшикти көздөй басып келип, тыкылдатты. Көп өтпөй ал кычырап, бир аз ачылды.

- Сен тазалоочусуңбу? – ичинен карылдаган үн чыкты.

- Ооба, менмин... Мен баарын оңдоо үчүн келдим.

Джеймс кинотеатрдын фойесине кирди. Башка аргасы жок окшойт, кызматкерлер келгендерге кагаз билеттерин тарата башташты. Бул кызыктуураак деталдарды айтпаганда да, финансылык отчеттуулукту кыйындаткан. Бирок кызматкерлер Жеймсти жеңилдетип тосуп алышып, дароо сервердик бөлмөгө алып кетишти.

Бир караганда баары жакшы болчу. Джеймс серверге кирип, кадимки шектүү жерлерди текшерди. Эч кандай көйгөй жок. Бирок, көп кылдаттык менен Джеймс серверди өчүрүп, тармак картасын алмаштырып, системаны артка кайтарды. Ал дароо толук иштей баштады. Кызматкерлер кайрадан билеттерди сата башташты.

Джеймс Маркка телефон чалып, абалды билдирди. Жеймс күтүлбөгөн жерден кандайдыр бир нерсе болуп кетсе көргүсү келет деп элестетүү кыйын эмес. Ал тепкичтен түшүп, кызматкерлерден эмне болгонун сурай баштады. Албетте, система иштебей калды. Аны өчүрүп-күйгүзүштү, баары иштеди. Бирок 10 мүнөттөн кийин система иштебей калды.

Дал ушул маалда окшош нерсе болду. Күтүлбөгөн жерден, билет системасы каталарды ыргыта баштады. Кызматкерлер үшкүрүнүп, кагаз билеттерди кармашты, Жеймс сервердик бөлмөгө шашылды. Серверде баары жакшы көрүндү.

Анан кызматкерлердин бири кирип келди.

— Система кайра иштеп жатат.

Жеймс эч нерсе кылбаганы үчүн таң калды. Тагыраак айтканда, системаны иштете турган эч нерсе жок. Ал чыгып, телефонун алып, компаниясынын колдоо линиясына чалды. Көп өтпөй ошол эле кызматкер сервердик бөлмөгө кирген.

- Система иштебей калды.

Джеймс серверди карап койду. Экранда көп түстүү фигуралардын кызыктуу жана тааныш үлгүсү бийледи - баш аламандык менен бурулуп, чырмалышкан түтүктөр. Бул экран сактагычты баарыбыз бир убакта көрдүк. Бул сонун берилип, гипноздоштуруучу.


Джеймс кнопканы басып калып, үлгү көрүнбөй калды. Ал кассага шашып баратып, жолдон кайтып келе жаткан кызматкерге жолугуп калат.

— Система кайра иштеп жатат.

Эгер сиз акыл-эс менен бет ала алсаңыз, анда Джеймс дал ушундай кылды. Экран сактагыч. Бул OpenGL колдонот. Ошентип, иш учурунда, ал сервер процессорунун бардык ресурстарын жалмап кетет. Натыйжада, серверге ар бир чалуу тайм-аут менен аяктайт.

Джеймс сервердик бөлмөгө кайтып келип, кирип, экран сактагычты бош экраны бар кооз түтүктөр менен алмаштырды. Башкача айтканда, процессордун ресурстарын 100% жалмап турган экран сактагычтын ордуна мен ресурстарды керектебеген башкасын орноттум. Анан болжолумду текшерүү үчүн 10 мүнөт күттүм.

Жеймс кийинки кинотеатрга келгенде, экран сактагычты өчүрүү үчүн жаңы эле 800 км учуп келгенин менеджерине кантип түшүндүрөм деп ойлонуп жаткан.

Айдын белгилүү бир фазасында кыйроо

БОЛГОН ОКУЯ. Күндөрдүн биринде айдын фазасына жараша программалык камсыздоодо ката пайда болду. Айдын чыныгы фазасына жакындоону эсептөө үчүн MITтин ар кандай программаларында кеңири колдонулган бир аз тартип бар болчу. GLS бул тартипти LISP программасына курган, ал файлды жазып жатканда 80 белгиден турган убакыт белгиси бар сапты чыгарат. Билдирүүнүн биринчи сабы өтө узун болуп, кийинки сапка алып барышы өтө сейрек болгон. Ал эми программа кийинчерээк бул файлды окуганда, ал каргышка калды. Биринчи саптын узундугу так датага жана убакытка, ошондой эле убакыт белгиси басылып чыккан убактагы фаза спецификациясынын узундугуна жараша болгон. Башкача айтканда, ката түзмө-түз айдын фазасына көз каранды!

Биринчи кагаз басылышы Жаргон файлы (Стил-1983) сүрөттөлгөн мүчүлүштүккө алып келген мындай саптын мисалын камтыган, бирок терүүчү аны "оңдоп" койгон. Бул ошондон бери "ай фазасынын катасы" катары сүрөттөлгөн.

Бирок, божомолдордон сак болуңуз. Бир нече жыл мурун CERN (Европалык ядролук изилдөө борбору) инженерлери Чоң электрон-позитрон коллайдеринде жүргүзүлгөн эксперименттерде каталарга туш болушкан. Окумуштууларга натыйжаны көрсөткөнгө чейин компьютерлер бул аппарат тарабынан түзүлгөн эбегейсиз көлөмдөгү маалыматтарды активдүү иштетип жаткандыктан, көптөр программалык камсыздоо кандайдыр бир деңгээлде айдын фазасына сезгич болгон деп ойлошкон. Бир нече айласы кеткен инженерлер чындыктын түбүнө жетти. Ката Айдын өтүшү учурунда Жердин деформациясынан улам 27 км узундуктагы шакектин геометриясынын бир аз өзгөрүшүнөн келип чыккан! Бул окуя физика фольклоруна “Ньютондун бөлүкчөлөр физикасынан өчү” деген ат менен кирди жана физиканын эң жөнөкөй жана эң эски мыйзамдары менен эң алдыңкы илимий түшүнүктөрдүн байланышынын мисалы.

Ажаткананы жууп салуу поездди токтотот

Мен уккан эң мыкты аппараттык мүчүлүштүк Франциядагы ылдам жүрүүчү поездде болгон. Мүчүлүштүк поездди шашылыш тормоздоого алып келди, бирок бортто жүргүнчүлөр болгондо гана. Ар бир мындай учурда поезд иштен чыгарылып, текшерилип, бирок эч нерсе табылган эмес. Анан кайра линияга жөнөтүлүп, ал дароо токтоп калган.

Текшерүүлөрдүн биринде поездде бараткан инженер ажатканага барган. Ал бат эле жууп кетти, BOOM! Шашылыш токтотуу.

Инженер айдоочу менен байланышып:

— Тормоздун алдында эмне кылып жүрдүңүз эле?

- Ооба, ылдыйда жайладым...

Бул таң калыштуу болду, анткени нормалдуу иштөө учурунда поезд түшүүдө ондогон жолу жайлайт. Поезд алдыга жылды да, кийинки түшкөндө машинист эскертти:

- Мен жайлайм.

Эч нерсе болгон жок.

— Акыркы тормоздо эмне кылдың? – деп сурады айдоочу.

- Мейли... мен туалетте болчумун...

- Болуптур, анан дааратканага барып, биз кайра түшкөндө эмне кылсаң ошону кыл!

Инженер ажатканага барып, айдоочу: «Мен жайладым» деп эскерткенде, ал сууну агызып жиберди. Албетте, поезд дароо токтоду.

Эми алар көйгөйдү кайра жаратып, себебин табышы керек болчу.

Эки мүнөттөн кийин алар мотордун тормозунун пультунун кабели (поезддин эки учунда бирден кыймылдаткыч бар) электр шкафынын дубалынан ажыратылып, туалеттин шнурунун электромагнитин башкарган реледе жатканын байкашты... Реле качан күйгүзүлгөн, ал тормоздук кабелде тоскоолдуктарды жараткан жана системаны бузулуулардан коргоо жөн гана авариялык тормозду камтыган.

FORTRANды жек көргөн шлюз

Бир нече ай мурун биз материкте (бул Гавайиде болгон) тармактык байланыштар өтө жай болуп жатканын байкадык. Бул 10-15 мүнөткө созулуп, анан күтүлбөгөн жерден кайталанышы мүмкүн. Бир нече убакыт өткөндөн кийин, менин кесиптешим материк боюнча тармак байланыштары мага нааразы жалпы иштебейт. Анын материктеги машинага көчүрүлүшү керек болгон бир нече FORTRAN коду бар болчу, бирок аны кыла алган жок, анткени "тармак FTP жүктөө аягына чейин жетишерлик узакка созулган эмес."

Ооба, бир кесиптеши FORTRANдагы баштапкы коду бар файлды материктеги машинага FTP кылууга аракет кылганда тармак каталары болгон. Биз файлды архивдегенге аракет кылдык: андан кийин ал жылмакай көчүрүлдү (бирок максаттуу машинада таңгактан чыгаруучу жок болгондуктан, маселе чечилген жок). Акыры, биз FORTRAN кодун өтө кичинекей бөлүктөргө "бөлүп", аларды бирден жөнөттүк. Фрагменттердин көбү көйгөйсүз көчүрүлдү, бирок айрымдары өтпөй калды, же андан кийин өттү көп сандаган аракеттер.

Көйгөйлүү үзүндүлөрдү карап чыкканыбызда, биз алардын жалпылыгы бар экенин байкадык: алардын бардыгында C тамгасынан турган саптар менен башталган жана аяктаган комментарий блоктору бар (кесиптешим FORTRAN тилинде комментарий берүүнү туура көргөн). Биз материктеги тармактык эксперттерге электрондук кат жөнөтүп, жардам сурадык. Албетте, алар биздин файлдардын FTP аркылуу өткөрүлбөй калган үлгүлөрүн көргүсү келген... бирок каттарыбыз аларга жеткен жок. Акыры, биз жөнөкөй ойлоп таптык сүрөттөөөткөрүлбөгөн файлдар кандай болот. Бул иштеди :) [Бул жерде көйгөйлүү FORTRAN комментарийлеринин бирине мисал кошууга батынамбы? Кыязы, татыктуу эмес!]

Акырында биз аны түшүнүүгө жетиштик. Жакында кампустун биздин бөлүгү менен материк тармагынын ортосунда жаңы шлюз орнотулду. Ал баш тамганын кайталанган биттерин камтыган пакеттерди өткөрүүдө ЗОР кыйынчылыкка дуушар болгон! Бул пакеттердин бир нечеси гана шлюз ресурстарынын баарын ээлеп, башка пакеттердин өтүшүнө жол бербейт. Биз шлюз өндүрүүчүсүнө арыздандык... алар мындай деп жооп беришти: “Ооба, сиз кайталануучу C катасына туш болуп жатасыз! Биз ал жөнүндө мурунтан эле билебиз ». Акыр-аягы, биз башка өндүрүүчүдөн жаңы шлюз сатып алуу менен маселени чечтик (мурункусун коргоодо FORTRAN программаларын өткөрүп бере албагандыгы айрымдар үчүн артыкчылык болушу мүмкүн!).

катаал жолу

Бир нече жыл мурун, 40-фазалык клиникалык сыноолордун чыгымдарын азайтуу үчүн Perlде ETL системасын түзүүнүн үстүндө иштеп жатып, мен 000ге жакын даталарды иштетүүгө туура келди. Алардын экөө сынактан өтпөй калган. Бул мени көп деле түйшөлткөн жок, анткени бул даталар кардар берген маалыматтардан алынган, бул көбүнчө таң калыштуу. Бирок оригиналдуу маалыматтарды текшергенимде бул даталар 1-жылдын 2011-январы жана 1-жылдын 2007-январы экени билинди. Жаңы эле жазган программада ката бар деп ойлогом, бирок 30 жыл болуп чыкты. эски. Бул программалык камсыздоонун экосистемасы менен тааныш болбогондор үчүн табышмактуу угулушу мүмкүн. Башка компания көптөн бери акча табуу чечимин чыгаргандыктан, менин кардарым бир компания кокусунан, экинчиси атайын киргизген мүчүлүштүктөрдү оңдоо үчүн мага акча төлөп берди. Эмне жөнүндө айтып жатканымды түшүнүшүңүз үчүн, мен катага айланган функцияны кошкон компания, ошондой эле мен оңдогон сырдуу мүчүлүштүктөргө салым кошкон бир нече башка кызыктуу окуялар жөнүндө айтышым керек.

Эски жакшы күндөрдө, Apple компьютерлери кээде өзүнөн-өзү 1-жылдын 1904-январына датасын калыбына келтиришчү. Себеби жөнөкөй эле: ал күн менен убакытты эсепке алуу үчүн батарея менен иштеген “системалык саатты” колдонгон. Батарея өлүп калганда эмне болду? Компьютерлер датаны бир доордун башталышынан бери секунданын санына карай башташты. Доор деп биз маалымдама түпнуска датасын билдиргенбиз, ал эми Macintoshes үчүн бул 1-жылдын 1904-январы болчу. Батареясы өчүп калгандан кийин, учурдагы дата көрсөтүлгөн күнгө кайра коюлду. Бирок эмне үчүн мындай болду?

Мурда Apple баштапкы күндөн тартып секунданын санын сактоо үчүн 32 бит колдонгон. Бир бит эки маанинин бирин сактай алат - 1 же 0. Эки бит төрт маанинин бирин сактай алат: 00, 01, 10, 11. Үч бит - сегизден бир маани: 000, 001, 010, 011, 100 , 101, 110, 111, ж.б. Ал эми 32 232 маанинин бирин, башкача айтканда, 4 секунданы сактай алган. Apple даталары үчүн бул болжол менен 294 жылга барабар, андыктан эски Macтар 967-жылдан кийинки даталарды кармай албайт. Ал эми системанын батарейкасы өчүп калса, доордун башынан бери дата 296 секундга кайра коюлат жана сиз компьютерди күйгүзгөн сайын (же жаңы батарейканы сатып алганга чейин) күндү кол менен коюуңуз керек.

Бирок, Apple компаниясынын даталарды доордон кийинки секундалар катары сактоо чечими, биз көрө тургандай, биз доордун алдындагы даталарды иштете албайбыз дегенди түшүндүрдү, анын кесепеттери өтө чоң болгон. Apple мүчүлүштүктөрдү эмес, функцияны киргизди. Башка нерселер менен катар, бул Macintosh операциялык системасы "миң жылдык мүчүлүштүккө" каршы иммунитетке ээ экенин билдирген (бул чектөөлөрдү айланып өтүү үчүн өздөрүнүн дата системалары болгон көптөгөн Mac тиркемелери жөнүндө айтуу мүмкүн эмес).

Уланта бер. Биз Lotus 1-2-3 колдондук, IBMдин “өлтүргүч тиркемесин” компьютердик революцияны баштоого жардам берди, бирок Apple компьютерлеринде жеке компьютерди ийгиликтүү кылган VisiCalc бар болчу. Адилеттүүлүк үчүн айтсам, 1-2-3 пайда болбогондо, ЖКлар араң чыгып, персоналдык компьютерлердин тарыхы такыр башкача өнүгүп кетмек. Лотос 1-2-3 1900-жылды жаңы жыл катары эсептеген. Microsoft өзүнүн биринчи электрондук жадыбалын, Multiplan чыгарганда, ал рыноктун бир аз үлүшүн басып алган. Жана алар Excel долбоорун ишке киргизгенден кийин, алар Lotus 1-2-3тен саптарды жана мамычаларды атоо схемасын көчүрүп гана тим болбостон, 1900-жылды атайын секирик жыл катары кароо менен мүчүлүштүктөрдүн шайкеш келишин камсыз кылууну чечишти. Бул көйгөй бүгүнкү күндө дагы бар. Башкача айтканда, 1-2-3-те бул ката болгон, бирок Excelде бул аң-сезимдүү чечим болгон, ал бардык 1-2-3 колдонуучулары туура эмес болсо да, маалыматтарды өзгөртпөстөн, Excelге өз таблицаларын импорттошуна кепилдик берген.

Бирок дагы бир көйгөй бар эле. Биринчиден, Microsoft 1-жылдын 1904-январына чейинки даталарды тааныбаган Macintosh үчүн Excelди чыгарды. Ал эми Excelде 1-жылдын 1900-январы доордун башталышы деп эсептелген. Ошондуктан, иштеп чыгуучулар алардын программасы доордун түрүн таанып, керектүү доорго ылайык маалыматтарды сакташ үчүн өзгөртүү киргизишти. Microsoft бул тууралуу түшүндүрмө макала да жазган. Жана бул чечим менин катама алып келди.

Менин ETL системасы кардарлардан Windows'до түзүлгөн, бирок Mac'та да түзүлүшү мүмкүн болгон Excel электрондук жадыбалдарын алды. Демек, таблицада доордун башталышы 1-жылдын 1900-январы же 1-жылдын 1904-январы болушу мүмкүн. Кантип билсе болот? Excel файл форматы керектүү маалыматты көрсөтөт, бирок мен колдонгон талдоочу аны көрсөткөн жок (азыр көрсөттү) жана сиз белгилүү бир таблица үчүн доорду билесиз деп ойлоду. Мен Excel бинардык форматын түшүнүүгө жана талдоочу авторго патч жөнөтүүгө көбүрөөк убакыт коротмокмун, бирок кардар үчүн дагы көп нерсем бар болчу, андыктан доорду аныктоо үчүн тез эле эвристика жаздым. Ал жөнөкөй эле.

Excelде 5-жылдын 1998-июлундагы дата "07-05-98" (пайдасыз америкалык система), "5-июль, 98", "5-июль, 1998-жыл", "5-июль-98" же форматында көрсөтүлүшү мүмкүн. кандайдыр бир башка формат, дагы бир пайдасыз формат (тамаша, менин Excel версиям сунуштабаган форматтардын бири ISO 8601 болгон). Бирок, таблицада форматталбаган дата 35981-жыл үчүн "1900" же доор-34519 үчүн "1904" катары сакталган (сандар доордон кийинки күндөрдүн санын билдирет). Мен жөн гана форматталган күндөн жылды чыгаруу үчүн жөнөкөй талдоочуну колдондум, андан кийин форматталбаган күндөн жылды чыгаруу үчүн Excel талдоочуну колдондум. Эгерде эки баалуулук тең 4 жылга айырмаланса, анда мен 1904 доорундагы системаны колдонуп жатканымды билчүмүн.

Эмне үчүн мен жөн гана форматталган даталарды колдонгон жокмун? Анткени 5-жылдын 1998-июлунда ай күнү жоголгон "Июль, 98" деп форматтаса болот. Биз көптөгөн компаниялардан таблицаларды алдык, алар аларды ар кандай жолдор менен жараткандыктан, даталарды аныктоо бизге (бул учурда мен) көз каранды. Мындан тышкары, Excel туура түшүнсө, анда биз да ошондой кылышыбыз керек!

Ошол эле маалда мен 39082ге туш болдум. Эске сала кетейин, Lotus 1-2-3 1900-жылды кибис жыл деп эсептеген жана бул Excelде ишенимдүү түрдө кайталанган. Жана бул 1900-жылга бир күн кошулгандыктан, көптөгөн даталарды эсептөө функциялары ошол күнү туура эмес болушу мүмкүн. Башкача айтканда, 39082 1-жылдын 2011-январы (Mac компьютерлеринде) же 31-жылдын 2006-декабрында (Windows'до) болушу мүмкүн. Эгерде менин "жыл талдоочу" форматталган мааниден 2011-жылды чыгарса, анда баары жакшы. Бирок Excel талдоочусу кайсы доор колдонулуп жатканын билбегендиктен, ал демейки 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 000 дата туура талданды.

Чоң басма иштеринин ортосунда

1980-жылдардын башында атам Storage Technology, азыр иштебей калган бөлүмдө иштеген, ал ленталарды жогорку ылдамдыкта берүү үчүн пневматикалык системаларды түзгөн.

Алар жети "В" дискине туташкан бир борбордук "А" дискине ээ болушу үчүн, ал эми "А" дискин башкарган оперативдүү эс тутумдагы кичинекей ОС бардык "В" дисктерине окуу жана жазуу операцияларын өткөрүп бере тургандай кылып дисктерди кайра конструкциялашты.

Ар бир жолу "А" диски иштетилгенде, операциялык системаны анын эс тутумуна жүктөө үчүн "А" менен туташтырылган перифериялык дискке дискет киргизүү керек болчу. Бул өтө примитивдүү болгон: эсептөө күчү 8 биттик микроконтроллер тарабынан берилген.

Мындай жабдуулар үчүн максаттуу аудитория абдан чоң маалымат кампалары менен компаниялар болгон - банктар, чекене чынжырлар, ж.б.

Бир кардар көйгөйгө туш болду. Басып чыгаруу тапшырмасынын ортосунда бир "А" диски иштебей калышы мүмкүн, бул бүт жумуштун токтоп калышына алып келет. Дискинин иштешин калыбына келтирүү үчүн кызматкерлер бардыгын кайра жүктөө керек болчу. Ал эми бул алты сааттык иштин ортосунда болгон болсо, анда кымбат баалуу компьютердик убакыттын эбегейсиз көлөмү жоголуп, бүт операциянын графиги бузулган.

Storage Technologies компаниясынан техниктер жөнөтүлдү. Бирок, алардын аракетине карабастан, сыноо шарттарында катаны кайра чыгара алышкан жок: бул чоң басып чыгаруу иштеринин ортосунда пайда болгон сыяктуу. Көйгөй аппараттык камсыздоодо эмес, алар колунан келгендин баарын алмаштырышты: оперативдүү эс тутум, микроконтроллер, дискета диск, магниттик дисктин ар бир мүмкүн болгон бөлүгү - көйгөй сакталып кала берди.

Анан техниктер штабга телефон чалып, Экспертти чакырышты.

Эксперт отургуч менен бир чөйчөк кофени кармап, компьютер бөлмөсүндө отурду — ал убакта компьютерлер үчүн бөлмөлөр бар болчу — кызматкерлердин чоң басып чыгаруу ишинде кезекте турганына карап турду. Эксперт ийгиликсиздиктин пайда болушун күтүп жаткан - жана ошондой болду. Баары Экспертке карады, бирок ал эмне үчүн мындай болгонун түшүнгөн жок. Ошентип, ал жумушту кайрадан кезекке коюуга буйрук берип, бардык кызматкерлер жана техникалык кызматкерлер жумушка кайтып келишти.

Эксперт кайрадан отургучка отуруп, ийгиликсиздикти күтө баштады. Алты саатка жакын убакыт өтүп, ката кетти. Эксперттин эч кандай ою жок, бирок баары эл толгон бөлмөдө болгон. Ал миссияны кайра баштоону буйруду, кайра отурду жана күттү.

Үчүнчү ката менен Эксперт бир нерсени байкады. Катачылык кызматкерлер чет өлкөлүк дисктеги ленталарды алмаштырганда болгон. Анын үстүнө, иштебей калган кызматкерлердин бири полдо кандайдыр бир плитканы басып өткөндө эле пайда болгон.

көтөрүлгөн пол 6 8 дюйм бийиктикте коюлган алюминий плиткалар жасалган. Эч ким кокустан маанилүү кабелди басып калбашы үчүн бийик полдун астынан компьютерлердин көптөгөн зымдары өткөн. Көтөрүлгөн полдун астына таштандылар кирбеши үчүн плиткалар абдан бекем төшөлгөн.

Эксперт плиткалардын бири деформацияланганын түшүнгөн. Кызматкер анын бурчуна басканда плитканын четтери жанындагы плиткаларга сүрүлүп калган. Плиталарды туташтырган пластик бөлүктөрү да алар менен сүртүлүп, радио жыштык тоскоолдуктарын жараткан статикалык микроразряддарды пайда кылган.

Бүгүнкү күндө RAM радио жыштык кийлигишүүсүнөн алда канча жакшыраак корголгон. Бирок ал жылдары андай болгон эмес. Эксперт бул кийлигишүү эс тутумун жана аны менен бирге операциялык системанын иштешин бузуп жатканын түшүндү. Ал колдоо кызматына телефон чалып, жаңы плиткаларды заказ кылып, өзү орнотуп, көйгөй жоюлган.

Бул жогорку толкун!

Окуя сервердик бөлмөдө, Портсмуттагы кеңсенин төртүнчү же бешинчи кабатында (менимче), док зонасында болгон.

Бир күнү негизги маалымат базасы бар Unix сервери кыйрады. Алар аны кайра жүктөштү, бирок ал сүйүнүп кайра-кайра кулай берди. Биз колдоо кызматынан кимдир бирөө менен байланышууну чечтик.

Колдоочу жигит... Менимче анын аты Марк болчу, бирок бул маанилүү эмес... Мен аны тааныбайм деп ойлойм. Бул маанилүү эмес, чынында. Марк менен кармашалы, макулбу? Абдан жакшы.

Ошентип, бир нече сааттан кийин Марк келди (бул Лидстен Портсмутка чейин узак эмес, билесиз), серверди күйгүзүп, баары көйгөйсүз иштеди. Типтүү каргыш колдоо, кардар буга абдан капа болот. Марк журнал файлдарын карап чыгып, эч кандай жагымсыз эч нерсе тапкан жок. Ошентип, Марк поездге кайра отурат (же ал кандай транспорт менен келсе да, мен билгендей, бул аксак уй болушу мүмкүн эле... баары бир, баары бир, макулбу?) жана Лидске кайра жөнөйт, ысырап кылып. күн.

Ошол эле күнү кечинде сервер кайра бузулат. Окуя баягы эле... сервер көтөрүлбөйт. Марк алыстан жардам берүүгө аракет кылат, бирок кардар серверди иштете албайт.

Дагы бир поезд, автобус, лимон меренге же башка шылуун, Марк Портсмутка кайтып келди. Мына, сервер эч кандай көйгөйсүз жүктөлөт! Керемет. Марк бир нече саат бою операциялык системада же программалык камсыздоодо баары туура экенин текшерип, Лидске жөнөйт.

Күндүн орто ченинде сервер бузулуп калат (жайланыңыз!). Бул жолу серверди алмаштыруу үчүн аппараттык колдоочуларды тартуу акылга сыярлык. Бирок жок, болжол менен 10 сааттан кийин ал да түшөт.

Кырдаал бир нече күн кайталанды. Сервер иштейт, болжол менен 10 сааттан кийин бузулат жана кийинки 2 саатта иштебейт. Алар муздатууну, эс тутумдун агып кетишин текшеришти, бардыгын текшеришти, бирок эч нерсе тапкан жок. Андан кийин кыйроолор токтоду.

Апта бейкапар өттү... баары бактылуу. Баары кайра башталганга чейин бактылуу. Сүрөт ошол эле. 10 саат жумуш, 2-3 саат токтоп калуу...

Анан бирөө (менимче, алар мага бул адамдын IT менен эч кандай тиешеси жок деп айтышты) деди:

— Бул толкун!

Ындоо бош тиктөөлөр менен кабыл алынды, балким, бирөөнүн колу коопсуздук чалуу баскычынан тартынса керек.

"Ал толкун менен иштөөнү токтотот."

Кофе ичип отурганда Tide Жылдык китебин окуй албаган IT колдоо кызматкерлери үчүн бул таптакыр чет элдик түшүнүк болуп көрүнөт. Алар мунун эч кандай түрдө толкунга байланыштуу болушу мүмкүн эмес, анткени сервер бир жумадан бери үзгүлтүксүз иштеп жатканын түшүндүрүштү.

"Өткөн аптада суунун деңгээли төмөн болгон, бирок бул жумада ал жогору."

Яхтага лицензиясы жоктор үчүн бир аз терминология. Толкундар Айдын циклине жараша болот. Ал эми Жер айланган сайын ар бир 12,5 саат сайын Күн менен Айдын тартылуу күчү толкунду пайда кылат. 12,5 сааттык циклдин башталышында бийик толкун болот, циклдин орто ченинде суунун агымы, акырында кайрадан толкун болот. Бирок Айдын орбитасы өзгөргөн сайын, ылдый жана бийик суунун ортосундагы айырма да өзгөрөт. Ай Күн менен Жердин ортосунда же Жердин карама-каршы тарабында болгондо (ай толгон же ай жок), биз Сызыгын толкундарын алабыз - эң жогорку толкундарды жана эң төмөнкү төмөнкү толкундарды. Жарым айда биз квадратуралык толкундарды алабыз - эң төмөнкү толкундар. Эки чектин ортосундагы айырма абдан азаят. Айдын цикли 28 күнгө созулат: сызыгиан - квадратура - сызыгиан - квадратура.

Техниктерге толкундун маңызын түшүндүргөндө, алар дароо полицияны чакыруу керек деп ойлошкон. Жана абдан логикалык. Бирок жигиттин айтканы туура экен. Эки жума мурда кеңседен анча алыс эмес жерде эсминец байланып калган. Толкун аны белгилүү бир бийиктикке көтөргөн сайын, кеменин радар посту сервердик бөлмөнүн полунун деңгээлинде аяктады. Ал эми радар (же электрондук согуш жабдуулары, же башка аскердик оюнчук) компьютерлерде баш аламандыкты жараткан.

Ракета үчүн учуу миссиясы

Мага чоң (400 миң линияга жакын) ракетаны учурууну башкаруу жана көзөмөлдөө системасын операциялык системанын, компилятордун жана тилдин жаңы версияларына өткөрүү милдети жүктөлдү. Тагыраак айтканда, Solaris 2.5.1ден Solaris 7ге чейин жана Ada 83-те жазылган Verdix Ada өнүктүрүү тутумунан (VADS), Ada 95-те жазылган Rational Apex Ada системасына чейин. VADS Rational тарабынан сатылып алынган жана анын продуктусу эскирген, бирок Rational Apex компиляторуна өтүүнү жеңилдетүү үчүн VADS-спецификалык пакеттердин шайкеш версияларын ишке ашырууга аракет кылган.

Үч адам мага кодду таза түзүүгө жардам беришти. Бул эки жума болду. Анан системанын иштеши үчүн өз алдымча иштедим. Кыскача айтканда, бул мен туш болгон программалык камсыздоо тутумунун эң начар архитектурасы жана ишке ашырылышы болду, ошондуктан портту бүтүрүү үчүн дагы эки ай талап кылынды. Андан кийин система дагы бир нече айга созулган тестирлөөгө берилген. Мен тестирлөө учурунда табылган мүчүлүштүктөрдү дароо оңдоп койдум, бирок алардын саны тез эле азайып кетти (булак коду өндүрүш системасы болгон, андыктан анын функционалдуулугу абдан ишенимдүү иштеген, мен жаңы компиляторго көнүү учурунда пайда болгон мүчүлүштүктөрдү алып салууга туура келди). Акыры баары өз нугунда турганда мени башка долбоорго которушту.

Ал эми Ыраазычылык майрамынын алдындагы жума күнү телефон шыңгырады.

Ракетаны учуруу болжол менен үч жуманын ичинде сыналышы керек болчу, ал эми артка эсептөөнүн лабораториялык сыноолору учурунда буйруктардын ырааттуулугу бөгөттөлгөн. Чыныгы жашоодо бул сыноону токтотот, ал эми блокировка кыймылдаткычты ишке киргизгенден кийин бир нече секунданын ичинде пайда болсо, жардамчы системаларда бир нече кайтарылгыс аракеттер пайда болот, бул ракетанын узак жана кымбат даярдыгын талап кылат. Бул башталмак эмес, бирок көп адамдар убакытты жана көптү, көп акчаны жоготконуна абдан капа болушмак. Коргоо министрлиги акчаны ойлонбостон сарптайт деп эч ким айтпасын — мен бюджетти биринчи же экинчи орунга койбогон, андан кийин графикти койбогон подряддык менеджерди эч качан көргөн эмесмин.

Мурунку айларда бул артка саноо чакырыгы көптөгөн вариацияларда жүздөгөн жолу аткарылып, бир нече кичинекей ыкыктар гана болгон. Ошентип, бул пайда болуу ыктымалдыгы өтө төмөн болгон, бирок анын кесепеттери абдан маанилүү болгон. Бул эки факторду тең көбөйтүңүз, ошондо сиз бул жаңылык мен үчүн жана ондогон инженерлер менен менеджерлер үчүн кыйратылган майрамдык жуманы алдын ала айтканын түшүнөсүз.

Ал эми системаны көчүргөн адам катары мага көңүл бурулду.

Көпчүлүк коопсуздук үчүн критикалык системалардагыдай эле, көптөгөн параметрлер катталган, андыктан система бузулганга чейин аткарылган бир нече код саптарын аныктоо оңой эле. Анан, албетте, аларда эч кандай адаттан тыш эч нерсе жок болчу, ошол эле сөз айкаштары бир эле мезгилде миңдеген жолу ийгиликтүү аткарылган.

Биз Apexтеги адамдарды Rational деп атадык, анткени алар компиляторду иштеп чыгышкан жана алар иштеп чыккан кээ бир көнүмүш иш-аракеттер шектүү коддо аталган. Аларга (жана башкалардын бардыгына) сөзмө-сөз мамлекеттик маанидеги маселенин түпкү тамырына баруу зарылдыгы бар экенине таң калышты.

Журналдарда кызыктуу эч нерсе болбогондуктан, маселени жергиликтүү лабораторияда кайра чыгарууну чечтик. Бул оңой иш болгон жок, анткени окуя болжол менен 1000 чуркоодо бир жолу болгон. Шектүү себептердин бири - сатуучу тарабынан иштелип чыккан mutex функциясына чалуу (VADS миграция пакетинин бир бөлүгү) Unlock ачууга алып келген жок. Функция деп аталган иштетүүчү жип ар бир секунд сайын номиналдуу түрдө келип турган жүрөктүн согушу кабарларын иштетет. Жыштыкты 10 Гцге, башкача айтканда секундасына 10 жолуга чейин көтөрүп, иштей баштадык. Болжол менен бир сааттан кийин система өзү кулпуланган. Журналда биз жазылган билдирүүлөрдүн ырааттуулугу ийгиликсиз сыноо учурундагыдай болгонун көрдүк. Биз дагы бир нече чуркоолорду жасадык, система башталгандан кийин 45-90 мүнөттөн кийин үзгүлтүксүз бөгөттөлүп турду жана ар бир жолу журналда бир эле маршрут камтылган. Биз техникалык жактан башка кодду иштетип жатканыбызга карабастан - билдирүү жыштыгы башка болгон - системанын жүрүм-туруму бирдей болгон, ошондуктан бул жүктөө сценарийи бир эле көйгөйдү жаратып жатканына ишенчүбүз.

Эми биз туюнтмалардын ырааттуулугунда бөгөт коюу кайсы жерде болгонун аныкташыбыз керек болчу.

Бул системаны ишке ашыруу Ada тапшырма системасын колдонгон жана аны укмуштуудай начар колдонгон. Тапшырмалар - бул Ададагы жогорку деңгээлдеги бир эле учурда аткарылуучу конструкция, аткаруу жиптери сыяктуу, тилдин өзүнө гана орнотулган. Эки тапшырманы байланышуу керек болгондо, алар "жолугушууну белгилешет", керектүү маалыматтарды алмашат, андан кийин жолугушууну токтотуп, өз алдынча аткарууларына кайтып келишет. Бирок, система башкача ишке ашырылган. Максаттуу тапшырма жолугушуу болгондон кийин, ал максаттуу тапшырма башка тапшырма менен жолугушту, ал үчүнчү тапшырма менен жолугушту жана кээ бир процесстер аяктаганга чейин уланат. Ушундан кийин, бул жолугушуулардын баары аяктады жана ар бир тапшырма өзүнүн аткарылышына кайтуу керек болчу. Башкача айтканда, биз дүйнөдөгү эң кымбат функцияларды чалуу системасы менен иштешип жатканбыз, ал киргизилген маалыматтардын бир бөлүгүн иштетип жатканда бүт “көп тапшырма” процессин токтотту. Ал эми буга чейин өткөрүү жөндөмдүүлүгү өтө төмөн болгондуктан гана көйгөйлөргө алып келген эмес.

Мен бул тапшырма механизмин сүрөттөп бердим, анткени жолугушуу суралганда же бүтүшү күтүлгөндө, "тапшырманы алмаштыруу" пайда болушу мүмкүн. Башкача айтканда, процессор аткарууга даяр болгон башка тапшырманы иштете башташы мүмкүн. Көрсө, бир тапшырма башка тапшырма менен жолугушууга даяр болгондо, такыр башка тапшырма аткарыла башташы мүмкүн жана акыры башкаруу биринчи жолугушууга кайтып келет. Ал эми тапшырманын которулушуна себеп болгон башка окуялар болушу мүмкүн; ушундай окуялардын бири - бул мутексти басып чыгаруу же аткаруу сыяктуу системанын функциясына чакыруу.

Коддун кайсы сабы көйгөйдү жаратып жатканын түшүнүү үчүн, мен кыйроонун алдын ала турган тапшырманы которгучту иштетпестен, билдирүүлөрдүн ырааттуулугу аркылуу прогрессти жаздыруунун жолун табышым керек болчу. Ошондуктан мен пайдалана алган жокмун Put_Line()киргизүү/чыгаруу операцияларын аткарбоо үчүн. Мен эсептегич өзгөрмө же ушуга окшош нерсени орното алмакмын, бирок аны экранда көрсөтө албасам, анын маанисин кантип көрө алам?

Ошондой эле, журналды карап чыкканда, процесстин бардык киргизүү/чыгаруу операцияларына бөгөт койгон жана башка процесстерди аткарууга тоскоол болгон жүрөктүн согушу жөнүндө билдирүүлөрдү иштеп чыгууда тоңуп калганына карабастан, башка көз карандысыз тапшырмалар аткарыла бергени белгилүү болду. Башкача айтканда, иш толугу менен тосулган эмес, бир гана (критикалык) тизмек.

Бул бөгөттөөчү сөздү баалоо үчүн зарыл болгон ачкыч болду.

Мен тапшырманы, саналган түрүн жана ошол түрдөгү глобалдык өзгөрмөлөрдү камтыган Ada пакетин жасадым. Саналган литералдар көйгөйлүү ырааттуулуктун конкреттүү туюнтмаларына байланган (мис. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), андан кийин ага глобалдык өзгөрмөгө тиешелүү санды дайындаган дайындоо туюнтмаларын киргизиңиз. Мунун бардыгынын объект коду жөн гана эс тутумда туруктуу сакталгандыктан, анын аткарылышынын натыйжасында тапшырманы алмаштыруу өтө күмөн болчу. Биз, биринчи кезекте, тапшырманы алмаштыра турган туюнтмалардан шектенчүбүз, анткени бөгөттөө тапшырманы артка которууда (бир нече себептерден улам) кайтып келүү эмес, аткаруу учурунда болгон.

Көз салуу тапшырмасы жөн гана циклде иштеп, глобалдык өзгөрмөнүн мааниси өзгөргөн-өзгөрбөгөнүн текшерүү үчүн мезгил-мезгили менен текшерилип турду. Ар бир өзгөртүү менен, маани файлга сакталды. Андан кийин бир аз күтүү жана жаңы текшерүү. Мен файлга өзгөрмө жаздым, анткени тапшырма көйгөйлүү аймактагы тапшырманы которууда система аны аткаруу үчүн тандап алганда гана аткарылды. Бул тапшырмада эмне болгон күндө да башка, байланышы жок бөгөттөлгөн тапшырмаларга таасир этпейт.

Система көйгөйлүү кодду аткаруу чекитине жеткенде, ар бир кийинки туюнтмага өткөндө глобалдык өзгөрмө баштапкы абалга келтирилет деп күтүлгөн. Андан кийин тапшырманын которулушуна себеп болгон бир нерсе болот жана анын аткарылыш жыштыгы (10 Гц) мониторинг тапшырмасынан төмөн болгондуктан, монитор глобалдык өзгөрмөнүн маанисин кармап, аны жаза алат. Кадимки кырдаалда, мен санап чыгуулардын бир нече ырааттуулугун ала алмакмын: тапшырманы которуу учурундагы өзгөрмөнүн акыркы маанилери. Асылып жатканда, глобалдык өзгөрмө мындан ары өзгөрбөшү керек жана жазылган акыркы маани кайсы туюнтма аягына чыкпай калганын көрсөтөт.

Мен кодду көзөмөлдөө менен иштеттим. Ал катып калды. Ал эми мониторинг сааттын жебеси сыяктуу иштеди.

Журналда күтүлгөн ырааттуулук камтылган, ал мутекс чакырылганын көрсөткөн маани менен үзүлгөн. Unlock, жана тапшырма аткарылган жок - мурунку миңдеген чалуулардагыдай.

Apex инженерлери бул учурда алардын кодун кызуу талдап жатышкан жана мутексте теориялык жактан кулпу пайда боло турган жерди табышкан. Бирок анын ыктымалдыгы өтө төмөн болгон, анткени белгилүү бир убакта болгон окуялардын белгилүү ырааттуулугу гана бөгөт коюуга алып келиши мүмкүн. Мерфи мыйзамы, балдар, бул Мерфинин мыйзамы.

Мага керектүү коддун бөлүгүн коргоо үчүн, мен мутекс функциясынын чалууларын (OS мутекс функционалдуулугунун үстүнө курулган) кичинекей жергиликтүү Ada mutex пакети менен алмаштырдым, бул бөлүккө мутекс мүмкүнчүлүгүн башкаруу.

Мен аны кодго киргизип, тестти өткөрдүм. Жети сааттан кийин код дагы эле иштеп жатты.

Менин коду Rationalга тапшырылды, ал жерде алар аны түзүп, демонтаждап, көйгөйлүү mutex функцияларында колдонулган ыкманы колдонбогонун текшеришти.

Бул менин карьерамдагы эң жыш коддуу кароо болду 🙂 Мени менен бөлмөдө онго жакын инженерлер жана менеджерлер бар болчу, дагы он адам конференц-байланышта болушту - жана алардын бардыгы 20га жакын код саптарын карап чыгышты.

Код каралып, жаңы аткарылуучу файлдар чогултулуп, формалдуу регрессиялык тестирлөөгө тапшырылды. Бир-эки жумадан кийин артка эсептөө сыноосу ийгиликтүү өтүп, ракета учуп кетти.

Макул, баары жакшы, бирок окуянын мааниси эмнеде?

Бул таптакыр жийиркеничтүү маселе болчу. Жүз миңдеген код саптары, параллелдүү аткаруу, ондон ашык өз ара аракеттенүү процесстери, начар архитектура жана начар ишке ашыруу, орнотулган системалар үчүн интерфейстер жана миллиондогон долларлар сарпталган. Кысым жок, туура.

Бул маселенин үстүндө жалгыз мен иштеген жокмун, бирок мен көчүрүү учурунда элдин көңүл чордонунда болчумун. Бирок мен муну жасасам да, бул мен жүз миңдеген код саптарын түшүндүм, жада калса аларды карап чыктым дегенди билдирбейт. Кодду жана журналдарды бүткүл өлкөнүн инженерлери талдап чыгышкан, бирок алар мага бузулуунун себептери жөнүндө гипотезаларын айтканда, аларды жокко чыгарууга жарым мүнөт гана убакыт кетти. Жана менден теорияларды талдоону суранышканда, мен аны башка бирөөгө өткөрүп бермекмин, анткени бул инженерлер туура эмес жолго түшүп жатышканы мага ачык эле көрүнүп турду. Менменсинип жатабы? Ооба, бул туура, бирок мен башка себеп менен гипотезаларды жана өтүнүчтөрдү четке кактым.

Мен маселенин маңызын түшүндүм. Кайда, эмне үчүн болгонун так билчү эмесмин, бирок эмне болуп жатканын билчүмүн.

Бул жылдар аралыгында мен көп билим жана тажрыйба топтодум. Мен Аданы колдонуунун пионерлеринин бири болгом жана анын жакшы жактарын жана кемчиликтерин түшүндүм. Мен Ada Runtime китепканалары тапшырмаларды кантип аткарарын жана параллелдүү аткарууну билем. Ал эми төмөнкү деңгээлдеги программалоону эс, регистр жана ассемблер деңгээлинде түшүнөм. Башкача айтканда, өз кесибим боюнча терең билимге ээмин. Мен аларды көйгөйдүн себебин табуу үчүн колдондум. Мен мүчүлүштүктүн тегерегинде эле иштебестен, аны өтө сезгич иштөө чөйрөсүндө кантип табууга болорун түшүндүм.

Код менен күрөштүн мындай окуялары мындай күрөштүн өзгөчөлүктөрүн жана шарттарын жакшы билбегендер үчүн анча кызык эмес. Бирок бул окуялар чындап эле татаал маселелерди чечүү үчүн эмне керек экенин түшүнүүгө жардам берет.

Чынында эле кыйын маселелерди чечүү үчүн, сиз жөн гана программист эмес болушуңуз керек. Сиз коддун "тагдырын" түшүнүшүңүз керек, анын айлана-чөйрөсү менен кандайча өз ара аракеттенишет жана айлана-чөйрөнүн өзү кантип иштейт.

Ошондо сиздин өзүңүздүн кыйраган майрам аптаңыз болот.

Уландысы бар.

Source: www.habr.com

Комментарий кошуу