Huu ni uteuzi wa hadithi kutoka kwa Mtandao kuhusu jinsi mende wakati mwingine huwa na maonyesho ya ajabu kabisa. Labda una jambo la kusema pia.
Mzio wa gari kwa ice cream ya vanilla
Hadithi kwa wahandisi ambao wanaelewa kuwa dhahiri sio jibu kila wakati, na kwamba haijalishi ukweli unaweza kuonekana kuwa wa mbali, bado ni ukweli. Kitengo cha Pontiac cha General Motors Corporation kilipokea malalamiko:
Hii ni mara ya pili ninakuandikia, na sikulaumu kwa kutokujibu, kwa sababu inaonekana kama wazimu. Familia yetu ina desturi ya kula ice cream kila usiku baada ya chakula cha jioni. Aina za ice cream hubadilika kila wakati, na baada ya chakula cha jioni, familia nzima huchagua ice cream ya kununua, baada ya hapo ninaenda kwenye duka. Hivi majuzi nilinunua Pontiac mpya na tangu wakati huo safari zangu za kupata aiskrimu zimekuwa tatizo. Unaona, kila nikinunua aiskrimu ya vanila na kurudi kutoka dukani, gari haliwashi. Nikileta ice cream nyingine, gari huwashwa bila shida yoyote. Ninataka kuuliza swali zito, haijalishi linasikika la kijinga jinsi gani: "Ni nini kuhusu Pontiac ambayo inafanya isianze wakati ninaleta ice cream ya vanilla, lakini huanza kwa urahisi ninapoleta ladha nyingine ya ice cream?" "
Kama unavyoweza kufikiria, rais wa kitengo alikuwa na mashaka juu ya barua hiyo. Walakini, ikiwa tu, nilituma mhandisi kuangalia. Alishangaa kukutana na mtu tajiri na msomi anayeishi katika eneo zuri. Walikubaliana wakutane mara baada ya chakula cha jioni ili wawili hao waende dukani kuchukua ice cream. Jioni hiyo ilikuwa vanila, na waliporudi kwenye gari, haikuwaka.
Mhandisi alikuja jioni tatu zaidi. Mara ya kwanza ice cream ilikuwa chokoleti. Gari ilianza. Mara ya pili kulikuwa na ice cream ya strawberry. Gari ilianza. Jioni ya tatu aliomba kuchukua vanila. Gari haikuanza.
Akiwaza kwa busara, mhandisi huyo alikataa kuamini kuwa gari hilo lilikuwa na mzio wa ice cream ya vanilla. Kwa hiyo, nilikubaliana na mwenye gari hilo kwamba angeendelea na ziara zake hadi apate suluhu ya tatizo hilo. Na njiani, alianza kuandika maelezo: aliandika habari zote, wakati wa siku, aina ya petroli, wakati wa kuwasili na kurudi kutoka duka, nk.
Mhandisi huyo hivi karibuni aligundua kuwa mmiliki wa gari alitumia wakati mdogo kununua ice cream ya vanilla. Sababu ilikuwa mpangilio wa bidhaa kwenye duka. Aiskrimu ya Vanila ndiyo iliyokuwa maarufu zaidi na iliwekwa kwenye friza tofauti mbele ya duka ili kurahisisha kupatikana. Na aina nyingine zote zilikuwa nyuma ya duka, na ilichukua muda zaidi kupata aina sahihi na kulipa.
Sasa swali lilikuwa kwa mhandisi: kwa nini gari halikuanza ikiwa muda mdogo ulikuwa umepita tangu wakati injini ilizimwa? Kwa kuwa shida ilikuwa wakati, sio ice cream ya vanilla, mhandisi alipata jibu haraka: ilikuwa kufuli kwa gesi. Ilifanyika kila jioni, lakini wakati mmiliki wa gari alitumia muda zaidi kutafuta ice cream, injini iliweza kupoa vya kutosha na kuanza kwa urahisi. Na wakati mtu huyo alinunua ice cream ya vanilla, injini bado ilikuwa moto sana na kufuli ya gesi haikuwa na wakati wa kuyeyuka.
Maadili: Hata matatizo ya kichaa kabisa wakati mwingine ni ya kweli.
Crash Bandicoot
Ni chungu kupata hii. Kama mpanga programu, unazoea kulaumu msimbo wako kwanza, pili, tatu... na mahali pengine katika elfu kumi unalaumu mkusanyaji. Na zaidi chini ya orodha tayari unalaumu vifaa.
Hapa kuna hadithi yangu kuhusu mdudu wa vifaa.
Kwa mchezo Crash Bandicoot, niliandika msimbo wa kupakia na kuhifadhi kwenye kadi ya kumbukumbu. Kwa msanidi programu kama huyo wa mchezo wa smug, ilikuwa kama kutembea kwenye bustani: Nilifikiri kazi ingechukua siku kadhaa. Walakini, niliishia kurekebisha msimbo kwa wiki sita. Njiani, nilitatua shida zingine, lakini kila siku chache nilirudi kwenye nambari hii kwa masaa machache. Ilikuwa uchungu.
Dalili ilionekana kama hii: unapohifadhi uchezaji wa sasa wa mchezo na kufikia kadi ya kumbukumbu, kila kitu karibu kila wakati huenda sawa ... Lakini wakati mwingine muda wa kusoma au kuandika huisha bila sababu dhahiri. Rekodi fupi mara nyingi huharibu kadi ya kumbukumbu. Wakati mchezaji anajaribu kuokoa, yeye sio tu kushindwa kuokoa, lakini pia kuharibu ramani. Crap.
Baada ya muda, mtayarishaji wetu katika Sony, Connie Bus, alianza kuogopa. Hatukuweza kusafirisha mchezo na hitilafu hii, na wiki sita baadaye sikuelewa ni nini kilisababisha tatizo. Kupitia Connie, tuliwasiliana na watengenezaji wengine wa PS1: kuna mtu yeyote amekutana na kitu kama hicho? Hapana. Hakuna mtu aliyekuwa na matatizo na kadi ya kumbukumbu.
Wakati huna mawazo ya kutatua, mbinu pekee iliyobaki ni "kugawanya na kushinda": ondoa msimbo zaidi na zaidi kutoka kwa programu mbovu hadi kuna kipande kidogo kilichosalia ambacho bado husababisha tatizo. Hiyo ni, unakata programu kipande kwa kipande hadi sehemu ambayo ina mdudu inabaki.
Lakini jambo ni kwamba, ni vigumu sana kukata vipande kutoka kwa mchezo wa video. Jinsi ya kuiendesha ikiwa umeondoa nambari inayoiga mvuto? Au kuchora wahusika?
Kwa hiyo, tunapaswa kuchukua nafasi ya moduli nzima na stubs ambazo hujifanya kufanya kitu muhimu, lakini kwa kweli kufanya kitu rahisi sana ambacho hakiwezi kuwa na makosa. Lazima tuandike magongo kama haya kwa mchezo angalau kufanya kazi. Huu ni mchakato wa polepole na wenye uchungu.
Kwa kifupi, nilifanya hivyo. Niliondoa vipande vingi zaidi vya msimbo hadi nikabaki na msimbo wa awali ambao husanidi mfumo wa kuendesha mchezo, kuanzisha maunzi ya uwasilishaji, nk. Kwa kweli, katika hatua hii sikuweza kuunda menyu ya kuokoa na kupakia, kwa sababu ningelazimika kuunda msimbo wa msimbo wote wa picha. Lakini ningeweza kujifanya mtumiaji kutumia (isiyoonekana) kuokoa na kupakia skrini na kuomba kuokoa na kisha kuandika kwa kadi ya kumbukumbu.
Hii iliniacha na kipande kidogo cha msimbo ambacho bado kilikuwa na shida hapo juu - lakini bado ilikuwa ikitokea nasibu! Mara nyingi kila kitu kilifanya kazi vizuri, lakini mara kwa mara kulikuwa na makosa. Niliondoa karibu nambari zote za mchezo, lakini mdudu bado alikuwa hai. Hii ilikuwa ya kutatanisha: nambari iliyobaki haikufanya chochote.
Wakati fulani, pengine karibu saa tatu asubuhi, wazo lilinijia. Shughuli za kusoma na kuandika (ingizo/pato) huhusisha nyakati mahususi za utekelezaji. Unapofanya kazi na gari ngumu, kadi ya kumbukumbu au moduli ya Bluetooth, msimbo wa kiwango cha chini unaohusika na kusoma na kuandika hufanya hivyo kwa mujibu wa mapigo ya saa.
Kwa usaidizi wa saa, kifaa ambacho hakijaunganishwa moja kwa moja na kichakataji kinasawazishwa na msimbo unaotekelezwa kwenye kichakataji. Saa huamua kiwango cha baud-kasi ambayo data hupitishwa. Ikiwa kuna machafuko na nyakati, basi ama vifaa au programu, au zote mbili, pia zimechanganyikiwa. Na hii ni mbaya sana, kwa sababu data inaweza kuharibiwa.
Je, ikiwa kitu katika msimbo wetu kitachanganya nyakati? Niliangalia kila kitu kinachohusiana na hii kwenye nambari ya programu ya jaribio na nikagundua kuwa tuliweka kipima saa kinachoweza kupangwa katika PS1 hadi 1 kHz (tiki 1000 kwa sekunde). Hii ni nyingi sana; kwa msingi, wakati koni inapoanza, inaendesha kwa 100 Hz. Na michezo mingi hutumia mzunguko huu.
Andy, msanidi wa mchezo, aliweka kipima muda hadi kHz 1 ili mienendo ihesabiwe kwa usahihi zaidi. Andy huwa na mwelekeo wa kupita juu, na ikiwa tunaiga mvuto, tunafanya kwa usahihi iwezekanavyo!
Lakini vipi ikiwa kuharakisha kipima saa kwa namna fulani kumeathiri muda wa jumla wa programu, na kwa hiyo saa ambayo inasimamia kiwango cha baud kwa kadi ya kumbukumbu?
Nilitoa maoni kuhusu nambari ya saa. Hitilafu haikutokea tena. Lakini hii haimaanishi kuwa tuliirekebisha, kwa sababu kutofaulu kulitokea kwa nasibu. Ikiwa ningekuwa na bahati tu?
Siku chache baadaye nilijaribu tena programu ya majaribio. Hitilafu haikutokea tena. Nilirudi kwenye msingi kamili wa mchezo na kurekebisha msimbo wa kuhifadhi na kupakia ili kipima saa kiweke upya hadi thamani yake ya asili (100Hz) kabla ya kufikia kadi ya kumbukumbu, na kisha kuweka upya hadi 1kHz. Hakukuwa na ajali tena.
Lakini kwa nini hii ilitokea?
Nilirudi kwenye programu ya majaribio tena. Nilijaribu kupata muundo fulani katika tukio la kosa na kipima saa cha 1 kHz. Mwishowe niligundua kuwa hitilafu hutokea wakati mtu anacheza na mtawala wa PS1. Kwa kuwa singefanya hivi mwenyewe - kwa nini ningehitaji kidhibiti wakati wa kujaribu kuokoa na kupakia nambari? - Sikuona hata utegemezi huu. Lakini siku moja mmoja wa wasanii wetu alikuwa akiningoja nimalize majaribio - labda nilikuwa nikitukana wakati huo - na kwa woga akazungusha kidhibiti mikononi mwake. Kosa limetokea. "Subiri, nini?!" Naam, fanya hivyo tena!β
Nilipogundua kuwa matukio haya mawili yameunganishwa, niliweza kuzalisha kosa kwa urahisi: Nilianza kurekodi kwenye kadi ya kumbukumbu, nikisonga mtawala, na kuharibu kadi ya kumbukumbu. Kwangu ilionekana kama mdudu wa vifaa.
Nilikuja kwa Connie na kumwambia kuhusu ugunduzi wangu. Aliwasilisha habari hiyo kwa mmoja wa wahandisi waliobuni PS1. "Haiwezekani," akajibu, "haiwezi kuwa shida ya vifaa." Nilimwomba Connie atuandalie mazungumzo.
Mhandisi aliniita na tukabishana kwa Kiingereza chake kilichovunjika na Kijapani changu (kilichoharibika sana). Mwishowe nilisema, "Acha nitume tu programu yangu ya majaribio ya laini 30 ambapo kusonga kidhibiti husababisha mdudu." Alikubali. Alisema ilikuwa ni kupoteza muda na kwamba alikuwa na shughuli nyingi sana kufanya kazi kwenye mradi mpya, lakini angekubali kwa sababu tulikuwa wasanidi muhimu sana wa Sony. Nilisafisha programu yangu ya mtihani na kumpelekea.
Jioni iliyofuata (tulikuwa Los Angeles na yeye alikuwa Tokyo) alinipigia simu na kuniomba msamaha kwa unyonge. Ilikuwa ni tatizo la maunzi.
Sijui ni nini hasa mdudu, lakini kutokana na kile nilichosikia kwenye makao makuu ya Sony, ikiwa unaweka timer kwa thamani ya juu ya kutosha, iliingilia kati na vipengele kwenye ubao wa mama karibu na kioo cha timer. Mmoja wao alikuwa mdhibiti wa kiwango cha baud kwa kadi ya kumbukumbu, ambayo pia iliweka kiwango cha baud kwa watawala. Mimi si mhandisi, kwa hivyo huenda nimeharibu kitu.
Lakini jambo la msingi ni kwamba kulikuwa na kuingiliwa kati ya vipengele kwenye ubao wa mama. Na wakati wa kusambaza data wakati huo huo kupitia bandari ya mtawala na bandari ya kadi ya kumbukumbu na timer inayoendesha saa 1 kHz, bits zilipotea, data ilipotea, na kadi iliharibiwa.
Ng'ombe mbaya
Katika miaka ya 1980, mshauri wangu Sergei aliandika programu kwa SM-1800, clone ya Soviet ya PDP-11. Kompyuta ndogo hii imesakinishwa tu kwenye kituo cha reli karibu na Sverdlovsk, kitovu muhimu cha usafiri huko USSR. Mfumo huo mpya uliundwa kuelekeza mabehewa na trafiki ya mizigo. Lakini ilikuwa na mdudu wa kuudhi ambao ulisababisha ajali na ajali. Maporomoko ya mara kwa mara yalitokea wakati mtu alienda nyumbani jioni. Lakini licha ya uchunguzi wa kina siku iliyofuata, kompyuta ilifanya kazi kwa usahihi katika vipimo vyote vya mwongozo na moja kwa moja. Hii kawaida huonyesha hali ya mbio au mdudu mwingine wa ushindani ambao hutokea chini ya hali fulani. Akiwa amechoshwa na simu usiku sana, Sergei aliamua kufikia mwisho wake, na kwanza kabisa, kuelewa ni hali gani kwenye yadi ya marshalling iliyosababisha kuvunjika kwa kompyuta.
Kwanza, alikusanya takwimu za maporomoko yote ambayo hayajaelezewa na kuunda grafu kwa tarehe na wakati. Mchoro ulikuwa dhahiri. Baada ya kutazama kwa siku chache zaidi, Sergei aligundua kuwa angeweza kutabiri kwa urahisi wakati wa kushindwa kwa mfumo wa siku zijazo.
Punde si punde aligundua kwamba usumbufu ulitokea tu wakati kituo kilikuwa kikipanga mizigo ya treni ya ng'ombe kutoka kaskazini mwa Ukrainia na magharibi mwa Urusi kuelekea kwenye kichinjio kilicho karibu. Hii yenyewe ilikuwa ya kushangaza, kwa sababu kichinjio kilitolewa na mashamba yaliyo karibu zaidi, huko Kazakhstan.
Kiwanda cha nguvu za nyuklia cha Chernobyl kililipuka mnamo 1986, na mionzi ya mionzi ilifanya maeneo ya karibu kutoweza kukaliwa. Maeneo makubwa kaskazini mwa Ukrainia, Belarusi na Urusi magharibi yalichafuliwa. Akishuku viwango vya juu vya mionzi katika magari yanayowasili, Sergei alibuni mbinu ya kujaribu nadharia hii. Idadi ya watu ilikatazwa kuwa na dosimeters, kwa hivyo Sergei alijiandikisha na wanajeshi kadhaa kwenye kituo cha reli. Baada ya vinywaji kadhaa vya vodka, aliweza kumshawishi askari kupima kiwango cha mionzi katika moja ya magari yanayotiliwa shaka. Ilibadilika kuwa kiwango kilikuwa cha juu mara kadhaa kuliko maadili ya kawaida.
Sio tu kwamba ng'ombe walitoa mionzi mingi, kiwango chake kilikuwa cha juu sana hadi kilisababisha upotezaji wa bahati nasibu katika kumbukumbu ya SM-1800, ambayo ilikuwa katika jengo karibu na kituo.
Kulikuwa na uhaba wa chakula huko USSR, na viongozi waliamua kuchanganya nyama ya Chernobyl na nyama kutoka mikoa mingine ya nchi. Hii ilifanya iwezekanavyo kupunguza kiwango cha jumla cha radioactivity bila kupoteza rasilimali muhimu. Baada ya kujifunza juu ya hili, Sergei mara moja alijaza hati za uhamiaji. Na ajali za kompyuta zilisimama peke yao wakati kiwango cha mionzi kilipungua kwa muda.
Kupitia mabomba
Hapo zamani za kale, Movietech Solutions ilitengeneza programu kwa ajili ya sinema, iliyoundwa kwa ajili ya uhasibu, uuzaji wa tikiti na usimamizi wa jumla. Toleo la DOS la programu kuu lilikuwa maarufu sana miongoni mwa misururu ya ukumbi wa sinema ndogo na wa kati huko Amerika Kaskazini. Kwa hiyo haishangazi kwamba wakati toleo la Windows 95 lilipotangazwa, lililounganishwa na skrini za hivi karibuni za kugusa na vibanda vya huduma binafsi, na vifaa vya kila aina ya zana za kuripoti, haraka ikawa maarufu, pia. Mara nyingi sasisho lilikwenda bila shida. Wafanyikazi wa ndani wa IT waliweka vifaa vipya, data iliyohamishwa, na biashara ikaendelea. Ila wakati haikudumu. Wakati hii ilifanyika, kampuni ingemtuma James, aliyeitwa "Msafishaji."
Ingawa jina la utani linapendekeza aina chafu, safi ni mchanganyiko tu wa mwalimu, kisakinishi na jack-of-all-trades. James angetumia siku chache kwenye tovuti ya mteja akiweka vipengele vyote pamoja, na kisha kutumia siku kadhaa kufundisha wafanyakazi jinsi ya kutumia mfumo mpya, kutatua matatizo yoyote ya maunzi yaliyotokea na kimsingi kusaidia programu kupitia uchanga wake.
Kwa hiyo, haishangazi kwamba katika nyakati hizo za taharuki, James alifika ofisini asubuhi, na kabla hajafika kwenye meza yake, alipokelewa na meneja huku akiwa amejawa na kafeini kupita kawaida.
"Ninaogopa unahitaji kwenda Annapolis, Nova Scotia, haraka iwezekanavyo." Mfumo wao wote ulipungua, na baada ya usiku wa kufanya kazi na wahandisi wao, hatuwezi kujua nini kilifanyika. Inaonekana mtandao umeshindwa kwenye seva. Lakini tu baada ya mfumo huo kufanya kazi kwa dakika kadhaa.
- Hawakurudi kwenye mfumo wa zamani? - James alijibu kwa umakini kabisa, ingawa kiakili alitoa macho kwa mshangao.
- Hasa: mtaalamu wao wa IT "alibadilisha vipaumbele" na akaamua kuondoka na seva yao ya zamani. James, walisakinisha mfumo katika tovuti sita na kulipia tu usaidizi wa kulipiwa, na biashara yao sasa inaendeshwa kama ilivyokuwa miaka ya 1950.
James akajiweka sawa kidogo.
- Hiyo ni jambo lingine. Sawa, tuanze.
Alipofika Annapolis, jambo la kwanza alilofanya ni kupata jumba la maonyesho la kwanza la mteja ambalo lilikuwa na tatizo. Kwenye ramani iliyochukuliwa kwenye uwanja wa ndege, kila kitu kilionekana kuwa cha heshima, lakini eneo karibu na anwani inayotaka lilionekana kutiliwa shaka. Sio ghetto, lakini ukumbusho wa noir ya filamu. James alipokuwa akiegesha kando kando ya jiji, kahaba mmoja alimsogelea. Kwa kuzingatia ukubwa wa Annapolis, kuna uwezekano mkubwa ilikuwa ni moja tu katika jiji zima. Muonekano wake mara moja ulimkumbusha mhusika maarufu ambaye alitoa ngono kwa pesa kwenye skrini kubwa. Hapana, si kuhusu Julia Roberts, lakini kuhusu Jon Voight [dokezo la filamu "Midnight Cowboy" - takriban. njia].
Baada ya kumpeleka kahaba njiani, James alikwenda kwenye sinema. Eneo jirani lilikuwa limepata nafuu, lakini bado lilitoa hisia ya kuendeshwa chini. Sio kwamba James alikuwa na wasiwasi sana. Hapo awali alienda mahali pabaya. Na hii ilikuwa Kanada, ambapo hata wanyang'anyi wana heshima ya kutosha kusema "asante" baada ya kuchukua pochi yako.
Lango la kuingilia kwenye ukumbi wa sinema lilikuwa kwenye uchochoro wa dank. James aliusogelea mlango na kugonga. Muda si mrefu ilisikika na kufunguka kidogo.
- Je, wewe ni msafishaji? - sauti ya kutisha ilitoka ndani.
- Ndio, ni mimi ... nilikuja kurekebisha kila kitu.
James aliingia kwenye ukumbi wa sinema. Inavyoonekana, hawakuwa na chaguo lingine, wafanyikazi walianza kutoa tikiti za karatasi kwa wageni. Hii ilifanya kuripoti fedha kuwa ngumu, achilia mbali maelezo zaidi ya kuvutia. Lakini wafanyakazi walimkaribisha James kwa utulivu na mara moja wakampeleka kwenye chumba cha seva.
Kwa mtazamo wa kwanza, kila kitu kilikuwa sawa. James aliingia kwenye seva na kuangalia sehemu za kawaida za kutiliwa shaka. Hakuna shida. Walakini, kwa tahadhari nyingi, James alizima seva, akabadilisha kadi ya mtandao, na kurudisha mfumo. Mara moja alianza kufanya kazi kikamilifu. Wafanyikazi walianza kuuza tikiti tena.
James alimpigia simu Mark na kumjulia hali. Si vigumu kufikiria kwamba James anaweza kutaka kukaa karibu na kuona ikiwa jambo lolote lisilotarajiwa litatokea. Alishuka ngazi na kuanza kuwauliza wafanyakazi nini kilitokea. Ni wazi mfumo umeacha kufanya kazi. Walizima na kuwasha, kila kitu kilifanya kazi. Lakini baada ya dakika 10 mfumo ulianguka.
Wakati huu tu kitu kama hicho kilitokea. Ghafla, mfumo wa tikiti ulianza kutupa makosa. Wafanyikazi walipumua na kukamata tikiti za karatasi, na James akakimbilia kwenye chumba cha seva. Kila kitu kilionekana vizuri na seva.
Kisha mmoja wa wafanyakazi akaingia.
- Mfumo unafanya kazi tena.
James alichanganyikiwa kwa sababu hakuwa amefanya chochote. Kwa usahihi, hakuna kitu ambacho kingefanya mfumo kufanya kazi. Alitoka nje, akachukua simu yake na kupiga simu ya usaidizi wa kampuni yake. Punde mfanyakazi yule yule aliingia kwenye chumba cha seva.
- Mfumo uko chini.
James alimtazama seva. Mchoro wa kuvutia na unaojulikana wa maumbo ya rangi nyingi ulicheza kwenye skrini - mabomba ya kuchanganya na kuunganisha. Sote tumeona skrini hii wakati fulani. Ilitolewa kwa uzuri na ya kudanganya.
James akabonyeza kitufe na muundo ukatoweka. Aliharakisha hadi kwenye ofisi ya tikiti na njiani akakutana na mfanyakazi anayerudi kwake.
- Mfumo unafanya kazi tena.
Ikiwa unaweza kufanya kiganja cha akili, ndivyo James alivyofanya. Bongo. Inatumia OpenGL. Na kwa hiyo, wakati wa operesheni, hutumia rasilimali zote za processor ya seva. Kwa hivyo, kila simu kwa seva inaisha na kuisha kwa muda.
James alirudi kwenye chumba cha seva, akaingia, na akabadilisha skrini na bomba nzuri na skrini tupu. Hiyo ni, badala ya skrini ambayo hutumia 100% ya rasilimali za processor, niliweka nyingine ambayo haitumii rasilimali. Kisha nikasubiri dakika 10 ili kuangalia nadhani yangu.
James alipofika kwenye jumba lililofuata la sinema, alikuwa anafikiria jinsi ya kumueleza meneja wake kwamba alikuwa ametoka tu kukimbia kilomita 800 ili kuzima skrini.
Kuanguka wakati wa awamu fulani ya mwezi
Hadithi ya kweli. Siku moja hitilafu ya programu iliibuka ambayo ilitegemea awamu ya mwezi. Kulikuwa na utaratibu mdogo ambao ulitumika sana katika programu mbali mbali za MIT kuhesabu makadirio ya awamu ya kweli ya Mwezi. GLS iliunda utaratibu huu katika programu ya LISP ambayo, wakati wa kuandika faili, inaweza kutoa laini iliyo na muhuri wa muda wa karibu herufi 80 kwa urefu. Ilikuwa nadra sana kwamba mstari wa kwanza wa ujumbe ungeishia kuwa mrefu sana na kusababisha mstari unaofuata. Na wakati programu ilisoma faili hii baadaye, ililaani. Urefu wa mstari wa kwanza ulitegemea tarehe na wakati halisi, pamoja na urefu wa vipimo vya awamu wakati muhuri wa muda ulichapishwa. Hiyo ni, mdudu alitegemea awamu ya mwezi!
Toleo la kwanza la karatasi (Steele-1983) ilikuwa na mfano wa mstari kama huo ambao ulisababisha mdudu ulioelezewa, lakini kiboreshaji "kilisasisha". Hii imeelezewa kama "mdudu wa awamu ya mwezi".
Hata hivyo, kuwa makini na mawazo. Miaka michache iliyopita, wahandisi kutoka CERN (Kituo cha Ulaya cha Utafiti wa Nyuklia) walikutana na makosa katika majaribio yaliyofanywa kwenye Collider Kubwa ya Electron-Positron. Kwa kuwa kompyuta huchakata kwa bidii kiasi kikubwa cha data inayotolewa na kifaa hiki kabla ya kuonyesha matokeo kwa wanasayansi, wengi walikisia kwamba programu hiyo ilikuwa nyeti kwa namna fulani kwa awamu ya mwezi. Wahandisi kadhaa waliokata tamaa walipata ukweli. Hitilafu ilitokea kutokana na mabadiliko kidogo katika jiometri ya pete ya urefu wa kilomita 27 kutokana na deformation ya Dunia wakati wa kupita kwa Mwezi! Hadithi hii imeingia katika ngano za fizikia kama "Kisasi cha Newton kwenye Fizikia ya Chembe" na mfano wa uhusiano kati ya sheria rahisi na kongwe zaidi za fizikia na dhana za juu zaidi za kisayansi.
Kusafisha choo husimamisha treni
Kidudu bora zaidi ambacho nimewahi kusikia kilikuwa kwenye treni ya mwendo wa kasi nchini Ufaransa. Hitilafu hiyo ilisababisha treni hiyo kukatika kwa dharura, lakini tu ikiwa kulikuwa na abiria kwenye bodi. Katika kila kesi hiyo, treni ilitolewa nje ya huduma, ikaangaliwa, lakini hakuna kitu kilichopatikana. Kisha akarudishwa kwenye mstari, na mara moja akaanguka na kusimama.
Wakati wa ukaguzi mmoja, mhandisi aliyesafiri kwa treni alikwenda kwenye choo. Hivi karibuni alinawa, BOOM! Kusimamishwa kwa dharura.
Mhandisi aliwasiliana na dereva na kumuuliza:
Ulikuwa unafanya nini kabla tu ya kufunga breki?
- Kweli, nilipunguza kasi ya kushuka ...
Hii ilikuwa ya kushangaza, kwa sababu wakati wa operesheni ya kawaida treni hupunguza kasi ya kushuka mara kadhaa. Treni iliendelea, na katika mteremko uliofuata dereva alionya:
- Nitapunguza kasi.
Hakuna kilichotokea.
- Ulifanya nini wakati wa breki ya mwisho? - aliuliza dereva.
- Kweli ... nilikuwa kwenye choo ...
- Kweli, basi nenda kwenye choo na ufanye kile ulichofanya tunaposhuka tena!
Mhandisi alikwenda kwenye choo, na wakati dereva alionya: "Ninapunguza mwendo," alimwaga maji. Bila shaka, treni ilisimama mara moja.
Sasa wangeweza kuzaliana tatizo na walihitaji kutafuta sababu.
Baada ya dakika mbili, waligundua kuwa kebo ya udhibiti wa kijijini ya breki ya injini (treni ilikuwa na injini moja kila mwisho) ilikuwa imekatwa kutoka kwa ukuta wa kabati ya umeme na ilikuwa imelala kwenye relay ambayo ilidhibiti solenoid ya kuziba choo ... Wakati relay iliwashwa, iliunda usumbufu kwenye kebo ya breki, na ulinzi wa mfumo dhidi ya kutofaulu ulijumuisha tu kuvunjika kwa dharura.
Lango ambalo lilichukia FORTRAN
Miezi michache iliyopita tuliona kwamba miunganisho ya mtandao kwenye bara [hii ilikuwa Hawaii] ilikuwa ikienda polepole sana. Hii inaweza kudumu kwa dakika 10-15 na kisha kutokea tena ghafla. Baada ya muda, mwenzangu alinilalamikia kuwa miunganisho ya mtandao bara kwa ujumla haifanyi kazi. Alikuwa na msimbo fulani wa FORTRAN ambao ulihitaji kunakiliwa kwa mashine ya bara, lakini haikuweza kwa sababu "mtandao haukushikilia muda wa kutosha ili upakiaji wa FTP ukamilike."
Ndio, ikawa kwamba hitilafu za mtandao zilitokea wakati mwenzako alijaribu FTP faili na msimbo wa chanzo katika FORTRAN kwa mashine ya bara. Tulijaribu kuweka faili kwenye kumbukumbu: kisha ilinakiliwa vizuri (lakini mashine inayolengwa haikuwa na kifungua, kwa hivyo shida haikutatuliwa). Hatimaye "tuligawanya" msimbo wa FORTRAN katika vipande vidogo sana na tukatuma moja kwa wakati mmoja. Vipande vingi vilinakiliwa bila matatizo, lakini vipande vichache havikupita, au kupita baada wengi majaribio.
Tulipochunguza vifungu vyenye matatizo, tuligundua kuwa vilikuwa na kitu sawa: vyote vilikuwa na vizuizi vya maoni vilivyoanza na kumalizia na mistari iliyojumuisha herufi kubwa C (kama mwenzako alipendelea kutoa maoni katika FORTRAN). Tulituma barua pepe kwa wataalam wa mtandao wa bara na kuomba msaada. Bila shaka, walitaka kuona sampuli za faili zetu ambazo hazingeweza kuhamishwa kupitia FTP... lakini barua zetu hazikuwafikia. Hatimaye tulikuja na rahisi kuelezeafaili zisizohamishika zinaonekanaje. Ilifanya kazi :) [Nathubutu kuongeza mfano wa mojawapo ya maoni yenye matatizo ya FORTRAN hapa? Labda haifai!]
Mwishowe tulifanikiwa kubaini. Lango jipya liliwekwa hivi majuzi kati ya sehemu yetu ya chuo na mtandao wa bara. Ilikuwa na ugumu KUBWA wa kusambaza pakiti zilizokuwa na vijisehemu vinavyorudiwa mara kwa mara vya herufi kubwa C! Ni vifurushi vichache tu vya hivi vinaweza kuchukua rasilimali zote za lango na kuzuia pakiti zingine nyingi kupita. Tulilalamika kwa mtengenezaji wa lango ... na wakajibu: "Oh, ndio, unakabiliwa na mdudu wa C unaorudiwa! Tayari tunajua kumhusu.β Hatimaye tulitatua tatizo kwa kununua lango jipya kutoka kwa mtengenezaji mwingine (katika utetezi wa awali, kutokuwa na uwezo wa kuhamisha programu za FORTRAN kunaweza kuwa faida kwa baadhi!).
Nyakati ngumu
Miaka michache iliyopita, nilipokuwa nikifanya kazi ya kuunda mfumo wa ETL huko Perl ili kupunguza gharama za majaribio ya kimatibabu ya awamu ya 40, nilihitaji kuchakata takriban tarehe 000. Wawili kati yao hawakufaulu mtihani. Hili halikunisumbua sana kwa sababu tarehe hizi zilichukuliwa kutoka kwa data iliyotolewa na mteja ambayo mara nyingi, tutasema, ya kushangaza. Lakini nilipoangalia data ya awali, ikawa kwamba tarehe hizi zilikuwa Januari 1, 2011 na Januari 1, 2007. Nilidhani kwamba mdudu ulikuwa katika mpango ambao nilikuwa nimeandika, lakini ikawa tayari ni miaka 30. mzee. Hili linaweza kusikika kuwa la fumbo kwa wale wasiofahamu mfumo ikolojia wa programu. Kwa sababu ya uamuzi wa muda mrefu wa kampuni nyingine kupata pesa, mteja wangu alinilipa ili kurekebisha hitilafu ambayo kampuni moja ilileta kwa bahati mbaya na nyingine kwa makusudi. Ili uelewe ninachozungumzia, ninahitaji kuzungumza kuhusu kampuni iliyoongeza kipengele ambacho kiliishia kuwa mdudu, na pia matukio machache ya kuvutia ambayo yalichangia hitilafu ya ajabu niliyorekebisha.
Katika siku nzuri za zamani, kompyuta za Apple wakati mwingine ziliweka upya tarehe yao hadi Januari 1, 1904. Sababu ilikuwa rahisi: ilitumia "saa ya mfumo" inayoendeshwa na betri ili kufuatilia tarehe na wakati. Nini kilifanyika wakati betri ilipokufa? Kompyuta zilianza kufuatilia tarehe kwa idadi ya sekunde tangu mwanzo wa enzi. Kwa enzi tulimaanisha tarehe asili ya marejeleo, na kwa Macintoshes ilikuwa Januari 1, 1904. Na baada ya betri kufa, tarehe ya sasa iliwekwa upya kwa ile iliyobainishwa. Lakini kwa nini hili lilitokea?
Hapo awali, Apple ilitumia bits 32 kuhifadhi idadi ya sekunde tangu tarehe ya awali. Biti moja inaweza kuhifadhi moja ya thamani mbili - 1 au 0. Biti mbili zinaweza kuhifadhi moja ya maadili manne: 00, 01, 10, 11. Biti tatu - thamani moja kati ya nane: 000, 001, 010, 011, 100 , 101, 110, 111, nk. Na 32 inaweza kuhifadhi moja ya maadili 232, ambayo ni, sekunde 4. Kwa tarehe za Apple, hii ililingana na takriban miaka 294, kwa hivyo Mac za zamani haziwezi kushughulikia tarehe baada ya 967. Na ikiwa betri ya mfumo itakufa, tarehe imewekwa upya hadi sekunde 296 tangu mwanzo wa enzi, na lazima uweke tarehe kila wakati unapowasha kompyuta (au hadi ununue betri mpya).
Walakini, uamuzi wa Apple wa kuhifadhi tarehe kama sekunde tangu enzi ulimaanisha kuwa hatukuweza kuchakata tarehe kabla ya enzi, ambayo ilikuwa na matokeo makubwa, kama tutakavyoona. Apple ilianzisha kipengele, sio mdudu. Miongoni mwa mambo mengine, hii ilimaanisha kwamba mfumo wa uendeshaji wa Macintosh ulikuwa na kinga dhidi ya "mdudu wa milenia" (ambayo haikuweza kusema kuhusu programu nyingi za Mac ambazo zilikuwa na mifumo yao ya tarehe ili kukwepa vikwazo).
Endelea. Tulitumia Lotus 1-2-3, "programu ya muuaji" ya IBM ambayo ilisaidia kuzindua mapinduzi ya Kompyuta, ingawa kompyuta za Apple zilikuwa na VisiCalc, ambayo ilifanya kompyuta ya kibinafsi kufanikiwa. Kwa haki, ikiwa 1-2-3 haikuonekana, Kompyuta hazingeondolewa, na historia ya kompyuta za kibinafsi ingeweza kuendeleza tofauti sana. Lotus 1-2-3 ilishughulikia vibaya 1900 kama mwaka wa kurukaruka. Wakati Microsoft ilitoa lahajedwali yake ya kwanza, Multiplan, ilichukua sehemu ndogo ya soko. Na walipozindua mradi wa Excel, waliamua sio tu kunakili mpango wa kutaja safu na safu kutoka Lotus 1-2-3, lakini pia kuhakikisha upatanifu wa mdudu kwa kutibu 1900 kwa makusudi kama mwaka wa kurukaruka. Tatizo hili bado lipo hadi leo. Hiyo ni, katika 1-2-3 hii ilikuwa mdudu, lakini katika Excel ilikuwa uamuzi wa ufahamu ambao ulihakikisha kwamba watumiaji wote wa 1-2-3 wanaweza kuingiza meza zao kwenye Excel bila kubadilisha data, hata ikiwa haikuwa sahihi.
Lakini kulikuwa na tatizo jingine. Kwanza, Microsoft ilitoa Excel kwa Macintosh, ambayo haikutambua tarehe kabla ya Januari 1, 1904. Na katika Excel, Januari 1, 1900 ilionekana kuwa mwanzo wa zama. Kwa hiyo, watengenezaji walifanya mabadiliko ili programu yao itambue aina ya enzi na kuhifadhi data ndani yake kwa mujibu wa enzi inayotaka. Microsoft hata iliandika nakala ya maelezo kuhusu hili. Na uamuzi huu ulisababisha mdudu wangu.
Mfumo wangu wa ETL ulipokea lahajedwali za Excel kutoka kwa wateja ambazo ziliundwa kwenye Windows, lakini pia zinaweza kuundwa kwenye Mac. Kwa hivyo, mwanzo wa enzi kwenye jedwali inaweza kuwa Januari 1, 1900, au Januari 1, 1904. Jinsi ya kujua? Fomati ya faili ya Excel inaonyesha habari muhimu, lakini kichanganuzi nilichotumia hakikuonyesha (sasa kinaonyesha), na kudhani kuwa unajua enzi ya jedwali maalum. Labda ningetumia wakati mwingi kuelewa umbizo la binary la Excel na kutuma kiraka kwa mwandishi wa kichanganuzi, lakini nilikuwa na mengi zaidi ya kumfanyia mteja, kwa hivyo niliandika haraka utabiri ili kubaini enzi. Alikuwa rahisi.
Katika Excel, tarehe ya Julai 5, 1998 inaweza kuwakilishwa katika muundo "07-05-98" (mfumo usio na maana wa Marekani), "Jul 5, 98", "Julai 5, 1998", "5-Jul-98" au umbizo lingine. umbizo lingine lisilofaa (kwa kushangaza, mojawapo ya umbizo ambalo toleo langu la Excel halikutoa ilikuwa ISO 8601). Walakini, ndani ya jedwali, tarehe ambayo haijaumbizwa ilihifadhiwa kama "35981" kwa epoch-1900 au "34519" kwa epoch-1904 (nambari zinawakilisha idadi ya siku tangu enzi). Nilitumia tu kichanganuzi rahisi kutoa mwaka kutoka tarehe iliyoumbizwa, kisha nikatumia kichanganuzi cha Excel kutoa mwaka kutoka tarehe ambayo haijaumbizwa. Ikiwa maadili yote mawili yalitofautiana kwa miaka 4, basi nilijua kuwa nilikuwa nikitumia mfumo na epoch-1904.
Kwa nini sikutumia tu tarehe zilizoumbizwa? Kwa sababu Julai 5, 1998 inaweza kuumbizwa kama "Julai, 98" na siku ya mwezi kupotea. Tulipokea meza kutoka kwa kampuni nyingi ambazo ziliziunda kwa njia nyingi tofauti kwamba ilikuwa juu yetu (katika kesi hii, mimi) kujua tarehe. Mbali na hilo, ikiwa Excel itaipata sawa, basi sisi pia tunapaswa!
Wakati huo huo nilikutana na 39082. Napenda kukukumbusha kwamba Lotus 1-2-3 ilizingatia 1900 mwaka wa kurukaruka, na hii ilirudiwa kwa uaminifu katika Excel. Na kwa kuwa hii iliongeza siku moja hadi mwaka wa 1900, vitendaji vingi vya kukokotoa tarehe vinaweza kuwa vibaya kwa siku hiyohiyo. Hiyo ni, 39082 inaweza kuwa Januari 1, 2011 (kwenye Macs) au Desemba 31, 2006 (kwenye Windows). Ikiwa "mchanganuzi wangu wa mwaka" alitoa mwaka wa 2011 kutoka kwa thamani iliyopangwa, basi kila kitu ni sawa. Lakini kwa kuwa kichanganuzi cha Excel hajui ni enzi gani inatumika, inabadilika kuwa epoch-1900, ikirudisha mwaka wa 2006. Maombi yangu yaliona kuwa tofauti hiyo ilikuwa miaka 5, ikachukuliwa kuwa kosa, ikaingia, na ikarudisha thamani ambayo haijafomatiwa.
Ili kuzunguka hii, niliandika hii (pseudocode):
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
Na kisha tarehe zote 40 zilichanganuliwa kwa usahihi.
Katikati ya kazi kubwa za uchapishaji
Mwanzoni mwa miaka ya 1980, baba yangu alifanya kazi katika Teknolojia ya Uhifadhi, mgawanyiko ambao sasa haufanyi kazi ambao uliunda anatoa za tepi na mifumo ya nyumatiki ya kulisha tepi ya kasi.
Walitengeneza upya anatoa ili waweze kuwa na gari moja la kati la "A" lililounganishwa na viendeshi saba vya "B", na OS ndogo katika RAM iliyodhibiti gari la "A" inaweza kugawa shughuli za kusoma na kuandika kwa viendeshi vyote vya "B".
Kila wakati gari "A" lilianza, ilikuwa ni lazima kuingiza diski ya floppy kwenye gari la pembeni lililounganishwa na "A" ili kupakia mfumo wa uendeshaji kwenye kumbukumbu yake. Ilikuwa ya zamani sana: nguvu ya kompyuta ilitolewa na kidhibiti kidogo cha 8-bit.
Walengwa wa vifaa hivyo walikuwa makampuni yenye ghala kubwa sana za data - benki, minyororo ya rejareja, n.k. - ambazo zilihitaji kuchapisha lebo nyingi za anwani au taarifa za benki.
Mteja mmoja alikuwa na tatizo. Katikati ya kazi ya uchapishaji, gari moja maalum "A" inaweza kuacha kufanya kazi, na kusababisha kazi nzima kukwama. Ili kurejesha uendeshaji wa gari, wafanyakazi walipaswa kuanzisha upya kila kitu. Na ikiwa hii ilitokea katikati ya kazi ya saa sita, basi kiasi kikubwa cha muda wa gharama kubwa wa kompyuta kilipotea na ratiba ya operesheni nzima ilivunjwa.
Mafundi walitumwa kutoka Storage Technologies. Lakini licha ya jitihada zao bora, hawakuweza kuzalisha mdudu chini ya hali ya mtihani: ilionekana kutokea katikati ya kazi kubwa za uchapishaji. Tatizo halikuwa vifaa, walibadilisha kila kitu walichoweza: RAM, microcontroller, floppy drive, kila sehemu inayofikiriwa ya gari la tepi - tatizo liliendelea.
Kisha mafundi wakapiga simu makao makuu na kumwita Mtaalamu.
Mtaalamu huyo alinyakua kiti na kikombe cha kahawa, akaketi kwenye chumba cha kompyutaβkatika siku hizo kulikuwa na vyumba vilivyotengwa kwa ajili ya kompyutaβna akawatazama wafanyakazi wakipanga foleni kazi kubwa ya kuchapisha. Mtaalam alikuwa akingojea kutofaulu - na ilifanyika. Kila mtu alimtazama Mtaalamu, lakini hakujua kwa nini hii ilitokea. Hivyo akaamuru kazi hiyo ipangwe tena foleni, wafanyakazi na mafundi wote wakarejea kazini.
Mtaalam huyo akaketi tena kwenye kiti na akaanza kusubiri kushindwa. Takriban masaa sita yalipita na kushindwa kulitokea. Mtaalamu tena hakuwa na mawazo, isipokuwa kila kitu kilitokea kwenye chumba kilichojaa watu. Aliamuru misheni ianzishwe tena, akaketi na kusubiri.
Kwa kushindwa kwa tatu, Mtaalam aliona kitu. Kushindwa kulitokea wakati wafanyikazi walibadilisha kanda kwenye gari la kigeni. Aidha, kushindwa kulitokea mara tu mmoja wa wafanyakazi alipopitia tile fulani kwenye sakafu.
Sakafu iliyoinuliwa ilitengenezwa kwa vigae vya alumini vilivyowekwa kwa urefu wa inchi 6 hadi 8. Waya nyingi kutoka kwa kompyuta zilienda chini ya sakafu iliyoinuliwa ili kuzuia mtu yeyote kukanyaga kebo muhimu kwa bahati mbaya. Tiles ziliwekwa kwa nguvu sana ili kuzuia uchafu usiingie chini ya sakafu iliyoinuliwa.
Mtaalam aligundua kuwa moja ya vigae ilikuwa imeharibika. Wakati mfanyakazi alipanda kona yake, kingo za tile zilisugua dhidi ya tiles zilizo karibu. Sehemu za plastiki ambazo ziliunganisha vigae pia zilisugua nazo, ambazo zilisababisha kutokwa kwa mikrofoni tuli ambayo iliunda kuingiliwa kwa masafa ya redio.
Leo, RAM inalindwa bora zaidi kutokana na kuingiliwa kwa mzunguko wa redio. Lakini katika miaka hiyo haikuwa hivyo. Mtaalam aligundua kuwa uingiliaji huu ulivuruga kumbukumbu, na kwa hiyo uendeshaji wa mfumo wa uendeshaji. Aliita huduma ya usaidizi, akaamuru tiles mpya, akaiweka mwenyewe, na shida ikatoweka.
Ni wimbi kubwa!
Hadithi hiyo ilifanyika katika chumba cha seva, kwenye ghorofa ya nne au ya tano ya ofisi huko Portsmouth (nadhani), katika eneo la docks.
Siku moja seva ya Unix iliyo na hifadhidata kuu ilianguka. Walimuanzisha tena, lakini kwa furaha aliendelea kuanguka tena na tena. Tuliamua kumpigia simu mtu kutoka kwa huduma ya usaidizi.
Yule jamaa anayemuunga mkono... nadhani jina lake lilikuwa Mark, lakini haijalishi... Sidhani kama namfahamu. Haijalishi, kwa kweli. Hebu tushikamane na Mark, sawa? Kubwa.
Kwa hiyo, saa chache baadaye Mark alifika (sio njia ndefu kutoka Leeds hadi Portsmouth, unajua), akageuka kwenye seva na kila kitu kilifanya kazi bila matatizo. Usaidizi wa kawaida, mteja hukasirika sana kuhusu hili. Alama hutazama faili za kumbukumbu na haoni chochote kibaya. Kwa hivyo Mark anarudi kwenye gari-moshi (au njia yoyote ya usafiri aliyofika, inaweza kuwa ng'ombe aliye kilema kwa yote ninayojua ... hata hivyo, haijalishi, sawa?) na kurudi Leeds, baada ya kupoteza. siku.
Jioni hiyo hiyo seva inaanguka tena. Hadithi ni sawa ... seva haifufui. Mark anajaribu kusaidia akiwa mbali, lakini mteja hawezi kuwasha seva.
Treni nyingine, basi, meringue ya limau au ujinga mwingine, na Mark wamerudi Portsmouth. Angalia, buti za seva bila matatizo yoyote! Muujiza. Mark hutumia saa kadhaa kuangalia kama kila kitu kiko sawa na mfumo wa uendeshaji au programu na kuanza kuelekea Leeds.
Karibu katikati ya siku seva inaanguka (chukua rahisi!). Wakati huu inaonekana ni sawa kuleta watu wa usaidizi wa maunzi kuchukua nafasi ya seva. Lakini hapana, baada ya masaa 10 pia huanguka.
Hali hiyo ilijirudia kwa siku kadhaa. Seva hufanya kazi, huacha kufanya kazi baada ya takriban saa 10 na haianzi kwa saa 2 zinazofuata. Waliangalia baridi, uvujaji wa kumbukumbu, waliangalia kila kitu, lakini hawakupata chochote. Kisha migongano ikakoma.
Wiki ilipita bila wasiwasi ... kila mtu alikuwa na furaha. Furaha hadi yote yaanze tena. Picha ni sawa. Saa 10 za kazi, masaa 2-3 ya kupumzika ...
Na kisha mtu (nadhani waliniambia kuwa mtu huyu hakuwa na uhusiano wowote na IT) akasema:
"Ni wimbi!"
Mshangao huo ulikumbana na macho yasiyo na mtu, na mkono wa mtu labda ulisita kwenye kitufe cha kupiga simu.
"Inaacha kufanya kazi na wimbi."
Hili linaweza kuonekana kuwa wazo geni kabisa kwa wafanyikazi wa msaada wa IT, ambao kuna uwezekano wa kusoma Kitabu cha Mwaka cha Tide wakiwa wameketi kwa kahawa. Walielezea kuwa hii haiwezi kuhusishwa na wimbi kwa njia yoyote, kwa sababu seva imekuwa ikifanya kazi kwa wiki bila kushindwa.
"Wiki iliyopita wimbi lilikuwa chini, lakini wiki hii ni kubwa."
Istilahi kidogo kwa wale ambao hawana leseni ya yacht. Mawimbi hutegemea mzunguko wa mwezi. Na kadri Dunia inavyozunguka, kila baada ya saa 12,5 mvuto wa Jua na Mwezi huunda wimbi kubwa. Mwanzoni mwa mzunguko wa saa 12,5 kuna wimbi la juu, katikati ya mzunguko kuna ebb, na mwisho kuna wimbi la juu tena. Lakini jinsi mzunguko wa mwezi unavyobadilika, ndivyo tofauti kati ya mawimbi ya chini na ya juu yanavyobadilika. Wakati Mwezi uko kati ya Jua na Dunia au upande wa pili wa Dunia (mwezi kamili au hakuna mwezi), tunapata mawimbi ya Syzygyn - mawimbi ya juu zaidi na mawimbi ya chini kabisa. Katika nusu mwezi tunapata mawimbi ya quadrature - mawimbi ya chini kabisa. Tofauti kati ya hizo mbili kali hupungua sana. Mzunguko wa mwezi huchukua siku 28: syzygian - quadrature - syzygian - quadrature.
Wakati mafundi walipoelezwa kiini cha nguvu za mawimbi, mara moja walifikiri kwamba walihitaji kuwaita polisi. Na mantiki kabisa. Lakini ikawa kwamba dude alikuwa sahihi. Wiki mbili mapema, mharibifu alifika mbali na ofisi. Kila wakati wimbi lilipoiinua hadi urefu fulani, nguzo ya rada ya meli iliishia kwenye kiwango cha sakafu ya chumba cha seva. Na rada (au vifaa vya vita vya elektroniki, au toy nyingine ya kijeshi) iliunda machafuko kwenye kompyuta.
Ujumbe wa ndege kwa roketi
Nilipewa jukumu la kusambaza mfumo mkubwa wa udhibiti na ufuatiliaji wa kurusha roketi (kama laini elfu 400) kwa matoleo mapya ya mfumo wa uendeshaji, mkusanyaji na lugha. Kwa usahihi zaidi, kutoka Solaris 2.5.1 hadi Solaris 7, na kutoka kwa Verdix Ada Development System (VADS), iliyoandikwa katika Ada 83, hadi mfumo wa Rational Apex Ada, ulioandikwa katika Ada 95. VADS ilinunuliwa na Rational, na bidhaa yake ilinunuliwa. kizamani, ingawa Rational ilijaribu kutekeleza matoleo yanayolingana ya vifurushi mahususi vya VADS ili kurahisisha mpito kwa mkusanyaji wa Apex.
Watu watatu walinisaidia kupata tu nambari iliyokusanywa kwa usafi. Ilichukua wiki mbili. Na kisha nilifanya kazi peke yangu kufanya mfumo ufanye kazi. Kwa kifupi, ilikuwa ni usanifu mbaya zaidi na utekelezaji wa mfumo wa programu ambayo nilikuwa nimekutana nayo, kwa hiyo ilichukua miezi miwili zaidi kukamilisha bandari. Mfumo huo uliwasilishwa kwa majaribio, ambayo ilichukua miezi kadhaa zaidi. Mara moja nilirekebisha mende ambazo zilipatikana wakati wa majaribio, lakini idadi yao ilipungua haraka (msimbo wa chanzo ulikuwa mfumo wa uzalishaji, kwa hivyo utendaji wake ulifanya kazi kwa uhakika kabisa, ilibidi tu niondoe mende zilizotokea wakati wa kuzoea mkusanyaji mpya). Hatimaye, kila kitu kilipokuwa kikifanya kazi inavyopaswa, nilihamishiwa kwenye mradi mwingine.
Na siku ya Ijumaa kabla ya Shukrani, simu iliita.
Uzinduzi wa roketi ulipaswa kujaribiwa katika muda wa wiki tatu, na wakati wa majaribio ya maabara ya muda uliosalia, mlolongo wa amri ulizuiwa. Katika maisha halisi, hii ingeondoa mtihani, na ikiwa kizuizi kilitokea ndani ya sekunde chache za kuanzisha injini, vitendo kadhaa visivyoweza kutenduliwa vitatokea katika mifumo ya msaidizi, ambayo ingehitaji utayari wa muda mrefu na wa gharama kubwa wa roketi. Isingeanza, lakini watu wengi wangefadhaika sana kuhusu upotevu wa muda na pesa nyingi sana. Usiruhusu mtu yeyote akuambie kwamba Idara ya Ulinzi hutumia pesa bila kujali-sijawahi kukutana na meneja wa kandarasi ambaye hakuweka bajeti kwanza au pili, ikifuatiwa na ratiba.
Katika miezi iliyopita, changamoto hii ya kuhesabu kurudi nyuma ilikuwa imeendeshwa mamia ya mara katika tofauti nyingi, na hiccups chache tu. Kwa hiyo uwezekano wa jambo hili kutokea ulikuwa mdogo sana, lakini matokeo yake yalikuwa makubwa sana. Zidisha mambo haya yote mawili, na utaelewa kuwa habari zilitabiri wiki ya likizo iliyoharibiwa kwangu na kadhaa ya wahandisi na wasimamizi.
Na umakini ulilipwa kwangu kama mtu ambaye alisambaza mfumo.
Kama ilivyo kwa mifumo mingi muhimu ya usalama, vigezo vingi viliwekwa, kwa hivyo ilikuwa rahisi kutambua mistari michache ya msimbo ambayo ilitekelezwa kabla ya mfumo kuharibika. Na kwa kweli, hakukuwa na kitu cha kawaida kabisa juu yao; misemo kama hiyo ilikuwa imetekelezwa kwa mafanikio maelfu ya mara wakati wa kukimbia sawa.
Tuliwaita watu kutoka Apex kuwa Rational kwa sababu wao ndio walitengeneza mkusanyaji na baadhi ya taratibu walizoanzisha ziliitwa katika kanuni ya kutiliwa shaka. Wao (na kila mtu mwingine) walivutiwa kwamba kulikuwa na haja ya kupata mzizi wa tatizo la umuhimu wa kitaifa.
Kwa kuwa hapakuwa na kitu cha kuvutia katika majarida, tuliamua kujaribu kuzalisha tatizo katika maabara ya ndani. Hili halikuwa kazi rahisi kwani tukio lilitokea takriban mara moja kwa kila mikimbio 1000. Sababu moja inayoshukiwa ilikuwa kwamba simu kwa kazi ya bubu iliyoendelezwa na muuzaji (sehemu ya kifurushi cha uhamiaji cha VADS) Unlock haikuongoza kwa kufungua. Uzi wa kuchakata ulioita chaguo za kukokotoa ulichakata ujumbe wa mapigo ya moyo, ambao kwa jina ulifika kila sekunde. Tulipandisha mzunguko hadi 10 Hz, yaani, mara 10 kwa sekunde, na tukaanza kukimbia. Takriban saa moja baadaye mfumo ulijifunga. Katika logi, tuliona kwamba mlolongo wa ujumbe uliorekodi ulikuwa sawa na wakati wa mtihani ulioshindwa. Tulifanya mara kadhaa zaidi, mfumo ulizuiwa mara kwa mara dakika 45-90 baada ya kuanza, na kila wakati logi ilikuwa na njia sawa. Ingawa tulikuwa tukiendesha msimbo tofauti kiufundi - marudio ya ujumbe yalikuwa tofauti - tabia ya mfumo ilikuwa sawa, kwa hivyo tulikuwa na uhakika kwamba hali hii ya upakiaji ilikuwa ikisababisha tatizo sawa.
Sasa tulihitaji kujua ni wapi hasa kuzuia kulitokea katika mlolongo wa maneno.
Utekelezaji huu wa mfumo ulitumia mfumo wa kazi wa Ada, na ukautumia vibaya sana. Majukumu ni muundo wa hali ya juu unaoweza kutekelezwa kwa wakati mmoja katika Ada, kitu kama nyuzi za utekelezaji, iliyojengwa katika lugha yenyewe. Wakati kazi mbili zinahitaji kuwasiliana, "huweka mkutano", hubadilishana data muhimu, na kisha kusimamisha mkutano na kurudi kwenye utekelezaji wao wa kujitegemea. Hata hivyo, mfumo huo ulitekelezwa kwa njia tofauti. Baada ya kazi iliyokusudiwa kukusanyika, kazi hiyo iliyolengwa iliunganishwa tena na kazi nyingine, ambayo ilijipanga tena na kazi ya tatu, na kadhalika hadi usindikaji fulani ukamilike. Baada ya hayo, mikutano hii yote ilikamilishwa na kila kazi ilibidi irudi kwenye utekelezaji wake. Hiyo ni, tulikuwa tukishughulika na mfumo wa simu wa gharama kubwa zaidi wa utendakazi duniani, ambao ulisimamisha mchakato mzima wa "multitasking" huku ukichakata sehemu ya data ya ingizo. Na kabla ya hii haikusababisha matatizo tu kwa sababu throughput ilikuwa chini sana.
Nilielezea utaratibu huu wa kazi kwa sababu wakati mkutano ulipoombwa au kutarajiwa kukamilika, "badiliko la kazi" linaweza kutokea. Hiyo ni, processor inaweza kuanza kusindika kazi nyingine ambayo iko tayari kutekelezwa. Inabadilika kuwa wakati kazi moja iko tayari kukutana na kazi nyingine, kazi tofauti kabisa inaweza kuanza kutekelezwa, na mwishowe udhibiti unarudi kwenye mkutano wa kwanza. Na matukio mengine yanaweza kutokea ambayo husababisha kazi kubadili; tukio moja kama hilo ni wito kwa utendaji wa mfumo, kama vile kuchapisha au kutekeleza bubu.
Ili kuelewa ni mstari gani wa msimbo ulikuwa unasababisha tatizo, nilihitaji kutafuta njia ya kurekodi maendeleo kupitia mlolongo wa taarifa bila kuanzisha swichi ya kazi, ambayo ingezuia ajali kutokea. Kwa hivyo sikuweza kuchukua faida Put_Line()ili kuepuka kufanya shughuli za I/O. Ningeweza kuweka kigeu cha kutofautisha au kitu kama hicho, lakini ninawezaje kuona thamani yake ikiwa siwezi kuionyesha kwenye skrini?
Pia, wakati wa kuchunguza logi, ikawa kwamba, licha ya kufungia kwa usindikaji wa ujumbe wa moyo, ambayo ilizuia shughuli zote za I / O za mchakato na kuzuia usindikaji mwingine usifanyike, kazi nyingine za kujitegemea ziliendelea kutekelezwa. Hiyo ni, kazi haikuzuiwa kabisa, ni mlolongo tu wa kazi (muhimu).
Hiki kilikuwa kidokezo kinachohitajika kutathmini usemi wa kuzuia.
Nilitengeneza kifurushi cha Ada ambacho kilikuwa na kazi, aina iliyoorodheshwa, na tofauti ya kimataifa ya aina hiyo. Fasihi zinazoweza kuhesabika zilihusishwa na usemi maalum wa mlolongo wenye matatizo (k.m. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), na kisha kuingiza misemo ya mgawo ndani yake ambayo ilikabidhi hesabu inayolingana kwa utaftaji wa ulimwengu. Kwa kuwa nambari ya kitu cha haya yote ilihifadhi kumbukumbu ya kila wakati, ubadilishaji wa kazi kama matokeo ya utekelezaji wake haukuwezekana sana. Kimsingi tulishuku misemo ambayo inaweza kubadilisha jukumu, kwa kuwa kizuizi kilitokea wakati wa utekelezaji badala ya kurudi wakati wa kurudisha jukumu nyuma (kwa sababu kadhaa).
Kazi ya kufuatilia ilienda kwa kitanzi na kukaguliwa mara kwa mara ili kuona kama thamani ya utofauti wa kimataifa imebadilika. Kwa kila mabadiliko, thamani ilihifadhiwa kwenye faili. Kisha kusubiri kwa muda mfupi na hundi mpya. Niliandika kutofautisha kwa faili kwa sababu kazi hiyo ilitekelezwa tu wakati mfumo uliichagua kwa utekelezaji wakati wa kubadilisha kazi katika eneo la shida. Chochote kilichotokea katika kazi hii hakitaathiri kazi zingine, ambazo hazihusiani na zilizozuiwa.
Ilitarajiwa kwamba mfumo utakapofikia hatua ya kutekeleza msimbo wenye matatizo, utofauti wa kimataifa ungewekwa upya wakati wa kuhamia kwa kila usemi unaofuata. Kisha kitu kitatokea ambacho kinasababisha kazi kubadili, na kwa kuwa mzunguko wa utekelezaji wake (10 Hz) ni wa chini kuliko ule wa kazi ya ufuatiliaji, mfuatiliaji anaweza kukamata thamani ya kutofautiana kwa kimataifa na kuiandika. Katika hali ya kawaida, ningeweza kupata mlolongo unaorudiwa wa sehemu ndogo ya hesabu: maadili ya mwisho ya kutofautisha wakati wa kubadili kazi. Wakati wa kunyongwa, tofauti ya kimataifa haipaswi kubadilika tena, na thamani ya mwisho iliyoandikwa itaonyesha ni usemi gani haukukamilika.
Niliendesha nambari na ufuatiliaji. Aliganda. Na ufuatiliaji ulifanya kazi kama saa.
Logi ilikuwa na mlolongo uliotarajiwa, ambao ulikatizwa na thamani inayoonyesha kuwa bubu lilikuwa limeitwa. Unlock, na kazi haijakamilika - kama ilivyo kwa maelfu ya simu zilizopita.
Wahandisi wa Apex walikuwa wakichambua nambari zao kwa joto kwa wakati huu na wakapata mahali kwenye bubu ambapo, kinadharia, kufuli kunaweza kutokea. Lakini uwezekano wake ulikuwa mdogo sana, kwa kuwa tu mlolongo fulani wa matukio yanayotokea kwa wakati fulani unaweza kusababisha kuzuia. Sheria ya Murphy, jamani, ni Sheria ya Murphy.
Ili kulinda kipande cha nambari nilichohitaji, nilibadilisha simu za kazi za mutex (zilizojengwa juu ya utendakazi wa OS mutex) na kifurushi kidogo cha Ada mutex ili kudhibiti ufikiaji wa mutex kwa kipande hicho.
Niliiingiza kwenye nambari na nikaendesha jaribio. Saa saba baadaye kanuni ilikuwa bado inafanya kazi.
Nambari yangu iliwasilishwa kwa Rational, ambapo waliitunga, wakaitenganisha, na kukagua kuwa haikutumia njia ile ile ambayo ilitumika katika kazi za mutex zenye shida.
Huu ulikuwa uhakiki wa msimbo uliosongamana zaidi wa kazi yangu π Kulikuwa na wahandisi na wasimamizi wapatao kumi chumbani nami, watu wengine kumi walikuwa kwenye simu ya mkutano - na wote walichunguza takriban mistari 20 ya msimbo.
Nambari hiyo ilikaguliwa, faili mpya zinazoweza kutekelezeka zilikusanywa na kuwasilishwa kwa majaribio rasmi ya urejeshaji. Wiki chache baadaye, jaribio la kuhesabu kurudi lilifanikiwa na roketi ikapaa.
Sawa, hiyo ni sawa na nzuri, lakini ni nini maana ya hadithi?
Lilikuwa ni tatizo la kuchukiza kabisa. Mamia ya maelfu ya mistari ya kanuni, utekelezaji sambamba, zaidi ya michakato kadhaa ya kuingiliana, usanifu duni na utekelezaji duni, violesura vya mifumo iliyopachikwa na mamilioni ya dola zilizotumika. Hakuna shinikizo, sawa.
Sio mimi pekee niliyeshughulikia shida hii, ingawa nilikuwa kwenye uangalizi nilipokuwa nikifanya kazi ya kusafirisha. Lakini ingawa nilifanya hivyo, hiyo haimaanishi kuwa nilielewa mamia ya maelfu ya mistari ya msimbo, au hata niliifupisha. Kanuni na kumbukumbu zilichambuliwa na wahandisi kote nchini, lakini waliponiambia nadharia zao kuhusu sababu za kutofaulu, ilinichukua nusu dakika tu kuzikanusha. Na nilipoombwa kuchambua nadharia, ningemkabidhi mtu mwingine, kwa sababu ilikuwa dhahiri kwangu kwamba wahandisi hawa walikuwa wakienda vibaya. Sauti ya kimbelembele? Ndiyo, hii ni kweli, lakini nilikataa dhana na maombi kwa sababu nyingine.
Nilielewa asili ya tatizo. Sikujua ni wapi hasa ilikuwa inatokea au kwa nini, lakini nilijua nini kilikuwa kinatokea.
Kwa miaka mingi, nimekusanya ujuzi na uzoefu mwingi. Nilikuwa mmoja wa waanzilishi wa kutumia Ada na nilielewa faida na hasara zake. Ninajua jinsi maktaba za wakati wa utekelezaji wa Ada hushughulikia kazi na kushughulikia utekelezaji sambamba. Na ninaelewa programu ya kiwango cha chini katika kiwango cha kumbukumbu, rejista na mkusanyiko. Kwa maneno mengine, nina ujuzi wa kina katika uwanja wangu. Na nilizitumia kutafuta sababu ya shida. Sikufanya kazi tu kuzunguka mdudu, nilielewa jinsi ya kuipata katika mazingira nyeti sana ya wakati wa kukimbia.
Hadithi kama hizo za mapambano na nambari hazifurahishi sana kwa wale ambao hawajui sifa na masharti ya pambano kama hilo. Lakini hadithi hizi hutusaidia kuelewa ni nini kinahitajika ili kutatua matatizo magumu sana.
Ili kutatua shida ngumu sana, unahitaji kuwa zaidi ya programu tu. Unahitaji kuelewa "hatma" ya kanuni, jinsi inavyoingiliana na mazingira yake, na jinsi mazingira yenyewe yanavyofanya kazi.
Na kisha utakuwa na wiki yako ya likizo iliyoharibiwa.
Ili kuendelea.
Chanzo: mapenzi.com