પ્રોગ્રામરો અને એન્જિનિયરોની લોકવાયકા (ભાગ 1)

આ ઇન્ટરનેટ પરથી વાર્તાઓની પસંદગી છે કે કેવી રીતે બગ્સ કેટલીકવાર સંપૂર્ણપણે અવિશ્વસનીય અભિવ્યક્તિઓ ધરાવે છે. કદાચ તમારી પાસે પણ કંઈક કહેવાનું છે.

વેનીલા આઈસ્ક્રીમ માટે કારની એલર્જી

ઇજનેરો માટે એક વાર્તા જેઓ સમજે છે કે સ્પષ્ટ હંમેશા જવાબ નથી હોતો, અને હકીકતો ભલે ગમે તેટલી દૂરની લાગે, તે હજી પણ હકીકતો છે. જનરલ મોટર્સ કોર્પોરેશનના પોન્ટિયાક ડિવિઝનને ફરિયાદ મળી:

આ બીજી વખત છે જ્યારે હું તમને લખી રહ્યો છું, અને જવાબ ન આપવા માટે હું તમને દોષી ઠેરવતો નથી, કારણ કે તે પાગલ લાગે છે. અમારા પરિવારમાં દરરોજ રાત્રે જમ્યા પછી આઈસ્ક્રીમ ખાવાની પરંપરા છે. દર વખતે આઈસ્ક્રીમના પ્રકારો બદલાય છે, અને રાત્રિભોજન પછી, આખો પરિવાર પસંદ કરે છે કે કયો આઈસ્ક્રીમ ખરીદવો, તે પછી હું સ્ટોર પર જાઉં છું. મેં તાજેતરમાં એક નવું પોન્ટિયાક ખરીદ્યું છે અને ત્યારથી આઈસ્ક્રીમ મેળવવાની મારી ટ્રિપ્સ એક સમસ્યા બની ગઈ છે. તમે જુઓ, જ્યારે પણ હું વેનીલા આઈસ્ક્રીમ ખરીદું છું અને સ્ટોરમાંથી પાછો આવું છું, ત્યારે કાર શરૂ થશે નહીં. જો હું અન્ય કોઈ આઈસ્ક્રીમ લાવીશ, તો કોઈ સમસ્યા વિના કાર ચાલુ થઈ જશે. હું એક ગંભીર પ્રશ્ન પૂછવા માંગુ છું, ભલે તે ગમે તેટલું મૂર્ખ લાગે: "પોન્ટિયાક વિશે એવું શું છે કે જ્યારે હું વેનીલા આઈસ્ક્રીમ લાવું ત્યારે તે શરૂ થતું નથી, પરંતુ જ્યારે હું આઈસ્ક્રીમનો બીજો સ્વાદ લાવું છું ત્યારે તે સરળતાથી શરૂ થાય છે?"

જેમ તમે કલ્પના કરી શકો છો, વિભાગ પ્રમુખ પત્ર વિશે શંકાસ્પદ હતા. જો કે, માત્ર કિસ્સામાં, મેં તપાસ કરવા માટે એક એન્જિનિયરને મોકલ્યો. તેને આશ્ચર્ય થયું કે તે એક સુંદર વિસ્તારમાં રહેતા એક શ્રીમંત, સુશિક્ષિત માણસ દ્વારા મળ્યો હતો. તેઓ રાત્રિભોજન પછી તરત જ મળવા માટે સંમત થયા જેથી તે બંને આઈસ્ક્રીમ માટે સ્ટોર પર જઈ શકે. તે સાંજે તે વેનીલા હતી, અને જ્યારે તેઓ કાર પર પાછા ફર્યા, ત્યારે તે શરૂ થશે નહીં.

એન્જીનીયર વધુ ત્રણ સાંજે આવ્યા. પ્રથમ વખત આઈસ્ક્રીમ ચોકલેટ હતો. ગાડી ચાલુ થઈ. બીજી વાર સ્ટ્રોબેરી આઈસ્ક્રીમ હતો. ગાડી ચાલુ થઈ. ત્રીજી સાંજે તેણે વેનીલા લેવા કહ્યું. કાર સ્ટાર્ટ ન થઈ.

તર્કસંગત રીતે, એન્જિનિયરે એ માનવાનો ઇનકાર કર્યો કે કારને વેનીલા આઈસ્ક્રીમથી એલર્જી છે. તેથી, હું કારના માલિક સાથે સંમત થયો કે જ્યાં સુધી તેને સમસ્યાનો ઉકેલ ન મળે ત્યાં સુધી તે તેની મુલાકાતો ચાલુ રાખશે. અને રસ્તામાં, તેણે નોંધ લેવાનું શરૂ કર્યું: તેણે બધી માહિતી, દિવસનો સમય, ગેસોલિનનો પ્રકાર, સ્ટોરમાંથી આવવાનો અને પાછા ફરવાનો સમય વગેરે લખી નાખ્યો.

એન્જિનિયરને ટૂંક સમયમાં સમજાયું કે કારના માલિકે વેનીલા આઈસ્ક્રીમ ખરીદવામાં ઓછો સમય પસાર કર્યો. કારણ સ્ટોરમાં માલસામાનનું લેઆઉટ હતું. વેનીલા આઈસ્ક્રીમ સૌથી વધુ લોકપ્રિય હતો અને તેને શોધવાનું સરળ બનાવવા માટે સ્ટોરની આગળના ભાગમાં અલગ ફ્રીઝરમાં રાખવામાં આવ્યું હતું. અને અન્ય તમામ જાતો સ્ટોરની પાછળ હતી, અને યોગ્ય વિવિધતા શોધવા અને ચૂકવણી કરવામાં ઘણો વધુ સમય લાગ્યો.

હવે પ્રશ્ન એંજીનિયર માટે હતો: જો એન્જિન બંધ થયું ત્યારથી ઓછો સમય વીતી ગયો હોય તો કાર કેમ સ્ટાર્ટ ન થઈ? સમસ્યા વેનીલા આઈસ્ક્રીમની નહીં પણ સમયની હોવાથી, એન્જિનિયરને ઝડપથી જવાબ મળ્યો: તે ગેસ લોક હતો. તે દરરોજ સાંજે બનતું હતું, પરંતુ જ્યારે કારના માલિકે આઈસ્ક્રીમ શોધવામાં વધુ સમય પસાર કર્યો, ત્યારે એન્જિન પૂરતું ઠંડું થઈ ગયું અને સરળતાથી ચાલુ થઈ ગયું. અને જ્યારે માણસે વેનીલા આઈસ્ક્રીમ ખરીદ્યો, ત્યારે એન્જિન હજી પણ ખૂબ ગરમ હતું અને ગેસ લોકને ઓગળવાનો સમય નહોતો.

નૈતિક: સંપૂર્ણ ઉન્મત્ત સમસ્યાઓ પણ ક્યારેક વાસ્તવિક હોય છે.

ક્રેશ ઘૂસ

આનો અનુભવ કરવો દુઃખદાયક છે. પ્રોગ્રામર તરીકે, તમે તમારા કોડને પ્રથમ, બીજા, ત્રીજા... અને દસ હજારમા સ્થાને તમે કમ્પાઈલરને દોષી ઠેરવવા ટેવાયેલા છો. અને સૂચિમાં આગળ તમે પહેલેથી જ સાધનોને દોષ આપો છો.

હાર્ડવેર બગ વિશેની મારી વાર્તા અહીં છે.

Crash Bandicoot ગેમ માટે, મેં મેમરી કાર્ડ લોડ કરવા અને સાચવવા માટે કોડ લખ્યો છે. આવા સ્મગ ગેમ ડેવલપર માટે, તે પાર્કમાં ચાલવા જેવું હતું: મેં વિચાર્યું કે કામ ઘણા દિવસો લેશે. જો કે, મેં છ અઠવાડિયા માટે કોડ ડીબગ કરવાનું સમાપ્ત કર્યું. રસ્તામાં, મેં અન્ય સમસ્યાઓ હલ કરી, પરંતુ દર થોડા દિવસે હું થોડા કલાકો માટે આ કોડ પર પાછો ફર્યો. તે વેદના હતી.

લક્ષણ આના જેવું દેખાતું હતું: જ્યારે તમે રમતના વર્તમાન પ્લેથ્રુને સાચવો છો અને મેમરી કાર્ડને ઍક્સેસ કરો છો, ત્યારે બધું લગભગ હંમેશા બરાબર થઈ જાય છે... પરંતુ કેટલીકવાર કોઈ સ્પષ્ટ કારણોસર વાંચવા અથવા લખવાની કામગીરીનો સમય સમાપ્ત થઈ જાય છે. ટૂંકું રેકોર્ડિંગ ઘણીવાર મેમરી કાર્ડને નુકસાન પહોંચાડે છે. જ્યારે કોઈ ખેલાડી બચાવવાનો પ્રયાસ કરે છે, ત્યારે તે માત્ર બચાવવામાં નિષ્ફળ જતો નથી, પરંતુ નકશાનો પણ નાશ કરે છે. વાહિયાત.

થોડા સમય પછી, સોની ખાતેના અમારા નિર્માતા, કોની બસ, ગભરાવા લાગ્યા. અમે આ બગ સાથે રમતને મોકલી શક્યા નથી, અને છ અઠવાડિયા પછી હું સમજી શક્યો નહીં કે સમસ્યાનું કારણ શું હતું. કોની દ્વારા, અમે અન્ય PS1 વિકાસકર્તાઓનો સંપર્ક કર્યો: શું કોઈને સમાન કંઈપણ મળ્યું છે? ના. મેમરી કાર્ડ સાથે કોઈને સમસ્યા ન હતી.

જ્યારે તમારી પાસે ડિબગીંગ માટે કોઈ વિચાર ન હોય, ત્યારે "વિભાજિત કરો અને જીતી લો" એ એકમાત્ર અભિગમ બાકી છે: ખામીયુક્ત પ્રોગ્રામમાંથી વધુ અને વધુ કોડ દૂર કરો જ્યાં સુધી પ્રમાણમાં નાનો ટુકડો બાકી ન હોય જે હજી પણ સમસ્યાનું કારણ બને છે. એટલે કે, તમે પ્રોગ્રામને ટુકડે ટુકડે કાપી નાખો જ્યાં સુધી બગનો ભાગ રહે.

પરંતુ વાત એ છે કે, વિડીયો ગેમમાંથી ભાગ કાઢવો ખૂબ જ મુશ્કેલ છે. જો તમે ગુરુત્વાકર્ષણનું અનુકરણ કરતા કોડને દૂર કર્યો હોય તો તેને કેવી રીતે ચલાવવું? અથવા અક્ષરો દોરવા?

તેથી, આપણે આખા મોડ્યુલોને સ્ટબ્સથી બદલવા પડશે જે કંઈક ઉપયોગી કરવાનો ડોળ કરે છે, પરંતુ હકીકતમાં કંઈક ખૂબ જ સરળ કરવું જોઈએ જેમાં ભૂલો ન હોઈ શકે. ઓછામાં ઓછા કામ કરવા માટે આપણે રમત માટે આવા ક્રેચ લખવા પડશે. આ એક ધીમી અને પીડાદાયક પ્રક્રિયા છે.

ટૂંકમાં, મેં તે કર્યું. મેં કોડના વધુ અને વધુ ટુકડાઓ દૂર કર્યા જ્યાં સુધી મારી પાસે પ્રારંભિક કોડ બાકી ન હોય જે રમત ચલાવવા માટે સિસ્ટમને ગોઠવે છે, રેન્ડરિંગ હાર્ડવેરને પ્રારંભ કરે છે, વગેરે. અલબત્ત, આ તબક્કે હું સેવ અને લોડ મેનૂ બનાવી શક્યો નથી, કારણ કે મારે બધા ગ્રાફિક્સ કોડ માટે સ્ટબ બનાવવો પડશે. પરંતુ હું (અદૃશ્ય) સેવ અને લોડ સ્ક્રીનનો ઉપયોગ કરીને વપરાશકર્તા હોવાનો ડોળ કરી શકું છું અને સાચવવાનું કહી શકું છું અને પછી મેમરી કાર્ડ પર લખી શકું છું.

આનાથી મને કોડનો એક નાનો ટુકડો મળ્યો જેમાં હજી પણ ઉપરોક્ત સમસ્યા હતી - પરંતુ તે હજી પણ રેન્ડમલી થઈ રહ્યું હતું! મોટેભાગે બધું સારું કામ કરે છે, પરંતુ પ્રસંગોપાત અવરોધો હતા. મેં લગભગ તમામ ગેમ કોડ દૂર કર્યા છે, પરંતુ બગ હજુ પણ જીવંત હતો. આ કોયડારૂપ હતું: બાકીના કોડે ખરેખર કંઈ કર્યું નથી.

અમુક સમયે, કદાચ સવારના ત્રણ વાગ્યાની આસપાસ, મને એક વિચાર આવ્યો. વાંચો અને લખો (ઇનપુટ/આઉટપુટ) કામગીરીમાં ચોક્કસ એક્ઝેક્યુશન સમયનો સમાવેશ થાય છે. જ્યારે તમે હાર્ડ ડ્રાઈવ, મેમરી કાર્ડ અથવા બ્લૂટૂથ મોડ્યુલ સાથે કામ કરો છો, ત્યારે વાંચવા અને લખવા માટે જવાબદાર નીચા-સ્તરના કોડ ઘડિયાળના ધબકારા અનુસાર આવું કરે છે.

ઘડિયાળની મદદથી, એક ઉપકરણ જે પ્રોસેસર સાથે સીધું જોડાયેલ નથી તે પ્રોસેસર પર એક્ઝિક્યુટ થતા કોડ સાથે સિંક્રનાઇઝ થાય છે. ઘડિયાળ બૉડ રેટ નક્કી કરે છે - જે ઝડપે ડેટા ટ્રાન્સફર થાય છે. જો સમય સાથે મૂંઝવણ હોય, તો પછી હાર્ડવેર અથવા સોફ્ટવેર, અથવા બંને, પણ મૂંઝવણમાં છે. અને આ ખૂબ જ ખરાબ છે, કારણ કે ડેટાને નુકસાન થઈ શકે છે.

જો અમારા કોડમાં કંઈક સમયને ગૂંચવણમાં મૂકે તો શું? મેં ટેસ્ટ પ્રોગ્રામ કોડમાં આને લગતી દરેક વસ્તુ તપાસી અને જોયું કે અમે PS1 માં પ્રોગ્રામેબલ ટાઈમરને 1 kHz (1000 ટિક પ્રતિ સેકન્ડ) પર સેટ કર્યું છે. આ ઘણું બધું છે; મૂળભૂત રીતે, જ્યારે કન્સોલ શરૂ થાય છે, ત્યારે તે 100 Hz પર ચાલે છે. અને મોટાભાગની રમતો આ આવર્તનનો ઉપયોગ કરે છે.

એન્ડી, ગેમ ડેવલપર, ટાઈમરને 1 kHz પર સેટ કરે છે જેથી હલનચલન વધુ ચોક્કસ રીતે ગણવામાં આવે. એન્ડી ઓવરબોર્ડ જવા માટે વલણ ધરાવે છે, અને જો આપણે ગુરુત્વાકર્ષણનું અનુકરણ કરીએ છીએ, તો અમે શક્ય તેટલી ચોક્કસ રીતે કરીએ છીએ!

પરંતુ જો ટાઈમરને ઝડપી બનાવવાથી પ્રોગ્રામના એકંદર સમયને કોઈક રીતે અસર થાય છે, અને તેથી ઘડિયાળ જે મેમરી કાર્ડ માટે બાઉડ રેટને નિયંત્રિત કરે છે?

મેં ટાઈમર કોડની ટિપ્પણી કરી. ભૂલ ફરીથી આવી નથી. પરંતુ આનો અર્થ એ નથી કે અમે તેને ઠીક કર્યું છે, કારણ કે નિષ્ફળતા રેન્ડમલી આવી છે. જો હું નસીબદાર હોત તો?

થોડા દિવસો પછી મેં ટેસ્ટ પ્રોગ્રામ સાથે ફરીથી પ્રયોગ કર્યો. ભૂલ પુનરાવર્તિત થઈ નથી. હું સંપૂર્ણ ગેમ કોડબેઝ પર પાછો ગયો અને સેવ અને લોડ કોડમાં ફેરફાર કર્યો જેથી કરીને પ્રોગ્રામેબલ ટાઈમર મેમરી કાર્ડને એક્સેસ કરતા પહેલા તેના મૂળ મૂલ્ય (100Hz) પર રીસેટ થઈ જાય અને પછી 1kHz પર ફરીથી સેટ થઈ જાય. ત્યાં કોઈ વધુ ક્રેશ નહોતા.

પણ આવું કેમ થયું?

હું ફરીથી ટેસ્ટ પ્રોગ્રામ પર પાછો ફર્યો. મેં 1 kHz ટાઈમર સાથે ભૂલની ઘટનામાં કેટલીક પેટર્ન શોધવાનો પ્રયાસ કર્યો. આખરે મેં જોયું કે ભૂલ ત્યારે થાય છે જ્યારે કોઈ PS1 નિયંત્રક સાથે રમે છે. કારણ કે હું ભાગ્યે જ આ જાતે કરીશ - સેવ અને લોડ કોડનું પરીક્ષણ કરતી વખતે મને શા માટે નિયંત્રકની જરૂર પડશે? - મેં આ નિર્ભરતાની નોંધ પણ લીધી નથી. પરંતુ એક દિવસ અમારા કલાકારોમાંથી એક મારી પરીક્ષણ સમાપ્ત થવાની રાહ જોઈ રહ્યો હતો - હું કદાચ તે ક્ષણે શાપ આપી રહ્યો હતો - અને ગભરાટથી તેના હાથમાં કંટ્રોલર ફેરવ્યો. એક ભૂલ આવી છે. "રાહ જુઓ, શું?!" સારું, તે ફરીથી કરો!"

જ્યારે મને સમજાયું કે આ બે ઘટનાઓ એકબીજા સાથે જોડાયેલી છે, ત્યારે હું ભૂલને સરળતાથી પુનઃઉત્પાદિત કરવામાં સક્ષમ હતો: મેં મેમરી કાર્ડ પર રેકોર્ડ કરવાનું શરૂ કર્યું, કંટ્રોલર ખસેડ્યું અને મેમરી કાર્ડને બગાડ્યું. મારા માટે તે હાર્ડવેર બગ જેવું લાગતું હતું.

હું કોની પાસે આવ્યો અને તેને મારી શોધ વિશે જણાવ્યું. તેણીએ PS1 ડિઝાઇન કરનાર એન્જિનિયરોમાંથી એકને માહિતી રીલે કરી. "અશક્ય," તેણે જવાબ આપ્યો, "તે હાર્ડવેર સમસ્યા હોઈ શકે નહીં." મેં કોનીને અમારા માટે વાતચીત ગોઠવવા કહ્યું.

એન્જિનિયરે મને બોલાવ્યો અને અમે તેની તૂટેલી અંગ્રેજી અને મારી (અત્યંત) તૂટેલી જાપાનીઝમાં દલીલ કરી. અંતે મેં કહ્યું, "મને મારો 30 લાઇન ટેસ્ટ પ્રોગ્રામ મોકલવા દો જ્યાં કંટ્રોલરને ખસેડવાથી બગ થાય છે." તે સંમત થયો. તેણે કહ્યું કે તે સમયનો વ્યય હતો અને તે નવા પ્રોજેક્ટ પર કામમાં ખૂબ જ વ્યસ્ત હતો, પરંતુ તે સ્વીકારશે કારણ કે અમે સોની માટે ખૂબ જ મહત્વપૂર્ણ વિકાસકર્તા છીએ. મેં મારો ટેસ્ટ પ્રોગ્રામ સાફ કર્યો અને તેને મોકલ્યો.

આગલી સાંજે (અમે લોસ એન્જલસમાં હતા અને તે ટોક્યોમાં હતો) તેણે મને ફોન કર્યો અને ઘોરતાથી માફી માંગી. તે હાર્ડવેર સમસ્યા હતી.

મને ખબર નથી કે બગ બરાબર શું હતું, પરંતુ સોની હેડક્વાર્ટરમાં મેં જે સાંભળ્યું તેના પરથી, જો તમે ટાઈમરને પર્યાપ્ત ઊંચા મૂલ્ય પર સેટ કરો છો, તો તે ટાઈમર ક્રિસ્ટલની નજીકમાં મધરબોર્ડ પરના ઘટકોમાં દખલ કરે છે. તેમાંથી એક મેમરી કાર્ડ માટે બૉડ રેટ કંટ્રોલર હતો, જે કંટ્રોલર માટે બૉડ રેટ પણ સેટ કરે છે. હું એન્જિનિયર નથી, તેથી મેં કંઈક ગડબડ કરી હશે.

પરંતુ નીચે લીટી એ છે કે મધરબોર્ડ પરના ઘટકો વચ્ચે દખલગીરી હતી. અને જ્યારે 1 kHz પર ચાલતા ટાઈમર સાથે કંટ્રોલર પોર્ટ અને મેમરી કાર્ડ પોર્ટ દ્વારા વારાફરતી ડેટા ટ્રાન્સમિટ કરતી વખતે, બિટ્સ ખોવાઈ ગયા હતા, ડેટા ખોવાઈ ગયો હતો અને કાર્ડને નુકસાન થયું હતું.

ખરાબ ગાય

1980ના દાયકામાં, મારા માર્ગદર્શક સર્ગેઈએ SM-1800 માટે સોફ્ટવેર લખ્યો, જે PDP-11નો સોવિયેત ક્લોન હતો. આ માઈક્રો કોમ્પ્યુટર હમણાં જ Sverdlovsk નજીકના રેલ્વે સ્ટેશન પર સ્થાપિત કરવામાં આવ્યું છે, જે USSR માં એક મહત્વપૂર્ણ પરિવહન કેન્દ્ર છે. નવી સિસ્ટમ વેગન અને માલવાહક ટ્રાફિકને રૂટ કરવા માટે ડિઝાઇન કરવામાં આવી હતી. પરંતુ તેમાં એક હેરાન કરનાર બગ છે જે રેન્ડમ ક્રેશ અને ક્રેશ તરફ દોરી જાય છે. જ્યારે કોઈ સાંજે ઘરે જાય ત્યારે હંમેશા ધોધ થતો હતો. પરંતુ બીજા દિવસે સંપૂર્ણ તપાસ કરવા છતાં, કમ્પ્યુટરે તમામ મેન્યુઅલ અને ઓટોમેટિક પરીક્ષણોમાં યોગ્ય રીતે કામ કર્યું. આ સામાન્ય રીતે રેસની સ્થિતિ અથવા અમુક અન્ય સ્પર્ધાત્મક બગ સૂચવે છે જે અમુક શરતો હેઠળ થાય છે. મોડી રાત્રે કોલ્સથી કંટાળીને, સેરગેઈએ તેના તળિયે જવાનું નક્કી કર્યું, અને સૌ પ્રથમ, સમજો કે માર્શલિંગ યાર્ડમાં કઇ પરિસ્થિતિઓ કમ્પ્યુટર ભંગાણ તરફ દોરી ગઈ.

પ્રથમ, તેણે તમામ ન સમજાય તેવા ધોધના આંકડા એકત્રિત કર્યા અને તારીખ અને સમય પ્રમાણે ગ્રાફ બનાવ્યો. પેટર્ન સ્પષ્ટ હતી. થોડા વધુ દિવસો સુધી અવલોકન કર્યા પછી, સર્ગેઈને સમજાયું કે તે ભવિષ્યની સિસ્ટમ નિષ્ફળતાના સમયની આગાહી સરળતાથી કરી શકે છે.

તેને ટૂંક સમયમાં જ ખબર પડી કે સ્ટેશન ઉત્તરી યુક્રેન અને પશ્ચિમી રશિયામાંથી પશુઓના ટ્રેન લોડને સૉર્ટ કરી રહ્યું હતું ત્યારે જ વિક્ષેપો સર્જાયો હતો. આ પોતે જ વિચિત્ર હતું, કારણ કે કઝાકિસ્તાનમાં કતલખાના ખૂબ નજીક સ્થિત ખેતરો દ્વારા પૂરા પાડવામાં આવતા હતા.

ચેર્નોબિલ પરમાણુ પાવર પ્લાન્ટ 1986 માં વિસ્ફોટ થયો, અને કિરણોત્સર્ગી પડવાને કારણે આસપાસના વિસ્તારો વસવાટ માટે અયોગ્ય બન્યા. ઉત્તર યુક્રેન, બેલારુસ અને પશ્ચિમ રશિયાના વિશાળ વિસ્તારો દૂષિત હતા. આવતા વાહનોમાં રેડિયેશનના ઉચ્ચ સ્તરની શંકા, સેર્ગેઈએ આ સિદ્ધાંતને ચકાસવા માટે એક પદ્ધતિ વિકસાવી. વસ્તીને ડોસીમીટર રાખવાની મનાઈ હતી, તેથી સેર્ગેઈએ રેલ્વે સ્ટેશન પર ઘણા સૈન્ય માણસો સાથે પોતાની નોંધણી કરાવી. વોડકાના ઘણા પીણાં પછી, તે એક સૈનિકને શંકાસ્પદ ગાડીઓમાંના રેડિયેશનનું સ્તર માપવા માટે સમજાવવામાં સફળ રહ્યો. તે બહાર આવ્યું છે કે સ્તર સામાન્ય મૂલ્યો કરતા અનેક ગણું વધારે હતું.

પશુઓ માત્ર ઘણું રેડિયેશન બહાર કાઢતા હતા એટલું જ નહીં, તેનું સ્તર એટલું ઊંચું હતું કે તેને કારણે SM-1800ની સ્મૃતિમાં બિટ્સનું રેન્ડમ નુકસાન થયું હતું, જે સ્ટેશનની બાજુમાં આવેલી બિલ્ડિંગમાં સ્થિત હતું.

યુએસએસઆરમાં ખોરાકની અછત હતી, અને સત્તાવાળાઓએ દેશના અન્ય પ્રદેશોના માંસ સાથે ચાર્નોબિલ માંસને મિશ્રિત કરવાનું નક્કી કર્યું. આનાથી મૂલ્યવાન સંસાધનો ગુમાવ્યા વિના રેડિયોએક્ટિવિટીનું એકંદર સ્તર ઘટાડવાનું શક્ય બન્યું. આ વિશે જાણ્યા પછી, સેરગેઈએ તરત જ સ્થળાંતર માટે દસ્તાવેજો ભર્યા. અને જ્યારે સમય જતાં રેડિયેશનનું સ્તર ઘટ્યું ત્યારે કમ્પ્યુટર ક્રેશ તેમના પોતાના પર બંધ થઈ ગયું.

પાઈપો દ્વારા

એક સમયે, મૂવીટેક સોલ્યુશન્સે સિનેમા માટે સોફ્ટવેર બનાવ્યું હતું, જે એકાઉન્ટિંગ, ટિકિટ વેચાણ અને સામાન્ય સંચાલન માટે રચાયેલ હતું. ફ્લેગશિપ એપનું DOS વર્ઝન ઉત્તર અમેરિકામાં નાની અને મધ્યમ કદની મૂવી થિયેટર ચેઇન્સમાં ખૂબ લોકપ્રિય હતું. તેથી તે આશ્ચર્યજનક નથી કે જ્યારે વિન્ડોઝ 95 સંસ્કરણની જાહેરાત કરવામાં આવી હતી, જે નવીનતમ ટચ સ્ક્રીનો અને સ્વ-સેવા કિઓસ્ક સાથે સંકલિત હતી, અને તમામ પ્રકારના રિપોર્ટિંગ સાધનોથી સજ્જ હતી, તે ઝડપથી લોકપ્રિય પણ બન્યું હતું. મોટાભાગે અપડેટ સમસ્યા વિના ચાલ્યું. સ્થાનિક IT સ્ટાફે નવા સાધનો ઇન્સ્ટોલ કર્યા, ડેટા સ્થાનાંતરિત કર્યો અને વ્યવસાય ચાલુ રાખ્યો. સિવાય કે જ્યારે તે ટકી ન હતી. જ્યારે આ બન્યું, ત્યારે કંપની જેમ્સને મોકલશે, જેનું હુલામણું નામ "ધ ક્લીનર" હતું.

જો કે ઉપનામ એક અપ્રિય પ્રકાર સૂચવે છે, ક્લીનર એ ફક્ત પ્રશિક્ષક, સ્થાપક અને જેક-ઓફ-ઓલ-ટ્રેડનું સંયોજન છે. જેમ્સ ક્લાયન્ટની સાઇટ પર તમામ ઘટકોને એકસાથે મૂકીને થોડા દિવસો વિતાવશે, અને પછી સ્ટાફને નવી સિસ્ટમનો ઉપયોગ કેવી રીતે કરવો તે શીખવવામાં, કોઈપણ હાર્ડવેર સમસ્યાઓનું નિરાકરણ કરવામાં અને તેના બાળપણથી જ સૉફ્ટવેરને અનિવાર્યપણે મદદ કરવામાં બીજા થોડા દિવસો પસાર કરશે.

તેથી, તે આશ્ચર્યજનક નથી કે આ વ્યસ્ત સમયમાં, જેમ્સ સવારે ઓફિસે પહોંચ્યો, અને તે તેના ડેસ્ક પર પહોંચે તે પહેલાં, મેનેજર દ્વારા તેનું સ્વાગત કરવામાં આવ્યું, જે સામાન્ય કરતાં વધુ કેફીનથી ભરેલું હતું.

"મને ડર છે કે તમારે શક્ય તેટલી વહેલી તકે અન્નાપોલિસ, નોવા સ્કોટીયા જવાની જરૂર છે." તેમની આખી સિસ્ટમ ઠપ થઈ ગઈ, અને તેમના એન્જિનિયરો સાથે કામ કર્યા પછી, અમે સમજી શકતા નથી કે શું થયું. એવું લાગે છે કે સર્વર પર નેટવર્ક નિષ્ફળ થયું છે. પરંતુ થોડીવાર સુધી તંત્ર દોડતું થઇ ગયું હતું.

- તેઓ જૂની સિસ્ટમમાં પાછા ફર્યા નથી? - જેમ્સે સંપૂર્ણ ગંભીરતાથી જવાબ આપ્યો, જોકે માનસિક રીતે તેણે આશ્ચર્યમાં આંખો પહોળી કરી.

— બરાબર: તેમના IT નિષ્ણાતે "પ્રાયોરિટીઝ બદલી" અને તેમના જૂના સર્વર સાથે જવાનું નક્કી કર્યું. જેમ્સ, તેઓએ છ સાઇટ્સ પર સિસ્ટમ ઇન્સ્ટોલ કરી અને માત્ર પ્રીમિયમ સપોર્ટ માટે ચૂકવણી કરી, અને તેમનો વ્યવસાય હવે 1950 ના દાયકાની જેમ ચાલે છે.

જેમ્સ સહેજ સીધો થયો.

- તે બીજી બાબત છે. ઠીક છે, ચાલો શરૂ કરીએ.

જ્યારે તે અન્નાપોલિસ પહોંચ્યો, ત્યારે તેણે સૌથી પહેલું કામ ગ્રાહકનું પહેલું થિયેટર શોધી કાઢ્યું જેમાં સમસ્યા હતી. એરપોર્ટ પર લીધેલા નકશા પર, બધું યોગ્ય દેખાતું હતું, પરંતુ ઇચ્છિત સરનામાની આસપાસનો વિસ્તાર શંકાસ્પદ લાગતો હતો. ઘેટ્ટો નહીં, પણ ફિલ્મ નોયરની યાદ અપાવે છે. જેમ્સ કર્બ ડાઉનટાઉન પર પાર્ક કરે છે, એક વેશ્યા તેની પાસે આવી. અન્નાપોલિસના કદને જોતાં, આખા શહેરમાં તે એકમાત્ર હતું. તેણીનો દેખાવ તરત જ પ્રખ્યાત પાત્રને ધ્યાનમાં લાવ્યો જેણે મોટા પડદા પર પૈસા માટે સેક્સની ઓફર કરી. ના, જુલિયા રોબર્ટ્સ વિશે નહીં, પરંતુ જોન વોઈટ વિશે [ફિલ્મ "મિડનાઇટ કાઉબોય" માટે સંકેત - આશરે. લેન].

વેશ્યાને તેના રસ્તે મોકલ્યા પછી, જેમ્સ સિનેમા ગયો. આજુબાજુનો વિસ્તાર સારો થઈ ગયો હતો, પરંતુ તે હજી પણ નીચે દોડી જવાની છાપ આપે છે. એવું નથી કે જેમ્સ ખૂબ ચિંતિત હતા. તે પહેલા પણ દુ:ખદ સ્થળોએ ગયો છે. અને આ કેનેડા હતું, જ્યાં લૂંટારુઓ પણ તમારું વૉલેટ લીધા પછી "આભાર" કહેવા માટે પૂરતા નમ્ર છે.

સિનેમાની બાજુનું પ્રવેશદ્વાર ખીચડી ગલીમાં હતું. જેમ્સ દરવાજા પાસે ગયો અને ખખડાવ્યો. ટૂંક સમયમાં તે ધ્રુજારી અને સહેજ ખુલી.

- શું તમે ક્લીનર છો? - અંદરથી કર્કશ અવાજ આવ્યો.

- હા, તે હું છું... હું બધું ઠીક કરવા આવ્યો છું.

જેમ્સ સિનેમાની લોબીમાં ગયો. દેખીતી રીતે અન્ય કોઈ વિકલ્પ ન હોવાથી, સ્ટાફે મુલાકાતીઓને કાગળની ટિકિટો આપવાનું શરૂ કર્યું. આનાથી નાણાકીય રિપોર્ટિંગ મુશ્કેલ બન્યું, વધુ રસપ્રદ વિગતોને છોડી દો. પરંતુ સ્ટાફે જેમ્સનું સ્વાગત કરીને રાહત અનુભવી અને તરત જ સર્વર રૂમમાં લઈ ગયા.

પ્રથમ નજરમાં, બધું સારું હતું. જેમ્સે સર્વરમાં લોગ ઇન કર્યું અને સામાન્ય શંકાસ્પદ જગ્યાઓ તપાસી. કોઇ વાંધો નહી. જો કે, પુષ્કળ સાવધાનીથી, જેમ્સે સર્વર બંધ કર્યું, નેટવર્ક કાર્ડ બદલ્યું અને સિસ્ટમ પાછી ફેરવી. તેણીએ તરત જ સંપૂર્ણ રીતે કામ કરવાનું શરૂ કર્યું. સ્ટાફે ફરી ટિકિટ વેચવાનું શરૂ કર્યું.

જેમ્સે માર્કને ફોન કરીને પરિસ્થિતિની જાણ કરી. તે કલ્પના કરવી મુશ્કેલ નથી કે જેમ્સ આસપાસ વળગી રહેવા માંગે છે અને જો કંઈપણ અણધારી બને છે કે કેમ. તે સીડી નીચે ગયો અને કર્મચારીઓને પૂછવા લાગ્યો કે શું થયું. દેખીતી રીતે તંત્રએ કામ કરવાનું બંધ કરી દીધું છે. તેઓએ તેને બંધ કર્યું અને ચાલુ કર્યું, બધું કામ કર્યું. પરંતુ 10 મિનિટ બાદ સિસ્ટમ ઠપ થઈ ગઈ હતી.

બસ આ જ ક્ષણે કંઈક આવું જ થયું. અચાનક, ટિકિટિંગ સિસ્ટમમાં ભૂલો થવા લાગી. સ્ટાફે નિસાસો નાખ્યો અને કાગળની ટિકિટો પકડી લીધી, અને જેમ્સ સર્વર રૂમમાં દોડી ગયો. સર્વર સાથે બધું સારું લાગતું હતું.

પછી એક કર્મચારી અંદર પ્રવેશ્યો.

- સિસ્ટમ ફરીથી કામ કરી રહી છે.

જેમ્સ મૂંઝવણમાં હતો કારણ કે તેણે કંઈ કર્યું ન હતું. વધુ સ્પષ્ટ રીતે, એવું કંઈ નથી જે સિસ્ટમને કાર્ય કરશે. તેણે લોગ આઉટ કર્યો, તેનો ફોન ઉપાડ્યો અને તેની કંપનીની સપોર્ટ લાઇન પર ફોન કર્યો. થોડી જ વારમાં એ જ કર્મચારી સર્વર રૂમમાં દાખલ થયો.

- સિસ્ટમ ડાઉન છે.

જેમ્સે સર્વર તરફ નજર કરી. બહુ-રંગીન આકારોની એક રસપ્રદ અને પરિચિત પેટર્ન સ્ક્રીન પર નૃત્ય કરે છે - અસ્તવ્યસ્ત રીતે રાઇથિંગ અને એકબીજા સાથે જોડાયેલા પાઈપો. આપણે બધાએ આ સ્ક્રીનસેવરને અમુક સમયે જોયા છે. તે સુંદર રીતે પ્રસ્તુત કરવામાં આવ્યું હતું અને શાબ્દિક રીતે હિપ્નોટાઇઝિંગ હતું.

જેમ્સે એક બટન દબાવ્યું અને પેટર્ન ગાયબ થઈ ગઈ. તે ઉતાવળમાં ટિકિટ ઓફિસ તરફ ગયો અને રસ્તામાં તેની પાસે પાછો ફરતો એક કર્મચારી મળ્યો.

- સિસ્ટમ ફરીથી કામ કરી રહી છે.

જો તમે મેન્ટલ ફેસપામ કરી શકો, તો જેમ્સે તે જ કર્યું. સ્ક્રીન સેવર. તે OpenGL નો ઉપયોગ કરે છે. અને તેથી, ઓપરેશન દરમિયાન, તે સર્વર પ્રોસેસરના તમામ સંસાધનોનો ઉપયોગ કરે છે. પરિણામે, સર્વર પરનો દરેક કૉલ સમયસમાપ્તિ સાથે સમાપ્ત થાય છે.

જેમ્સ સર્વર રૂમમાં પાછો ફર્યો, લૉગ ઇન થયો અને સ્ક્રીનસેવરને ખાલી સ્ક્રીન સાથે સુંદર પાઈપોથી બદલ્યો. એટલે કે, 100% પ્રોસેસર સંસાધનોનો ઉપયોગ કરતા સ્ક્રીનસેવરને બદલે, મેં બીજું ઇન્સ્ટોલ કર્યું જે સંસાધનોનો ઉપયોગ કરતું નથી. પછી મેં મારું અનુમાન ચકાસવા માટે 10 મિનિટ રાહ જોઈ.

જ્યારે જેમ્સ આગામી સિનેમામાં પહોંચ્યો, ત્યારે તે વિચારી રહ્યો હતો કે તેના મેનેજરને કેવી રીતે સમજાવવું કે તેણે સ્ક્રીન સેવર બંધ કરવા માટે માત્ર 800 કિમી ઉડાન ભરી હતી.

ચંદ્રના ચોક્કસ તબક્કા દરમિયાન ક્રેશ

સાચી વાર્તા. એક દિવસ એક સોફ્ટવેર બગ ઉભો થયો જે ચંદ્રના તબક્કા પર આધારિત હતો. ચંદ્રના સાચા તબક્કાના અંદાજની ગણતરી કરવા માટે વિવિધ MIT કાર્યક્રમોમાં સામાન્ય રીતે ઉપયોગમાં લેવાતી થોડી દિનચર્યા હતી. GLS એ આ રૂટિનને LISP પ્રોગ્રામમાં બનાવ્યું છે, જે ફાઇલ લખતી વખતે, લગભગ 80 અક્ષરો લાંબી ટાઇમસ્ટેમ્પ સાથે લાઇન આઉટપુટ કરશે. તે ખૂબ જ દુર્લભ હતું કે સંદેશની પ્રથમ લાઇન ખૂબ લાંબી હોય અને તે પછીની લાઇન તરફ દોરી જાય. અને જ્યારે પ્રોગ્રામે પાછળથી આ ફાઇલ વાંચી, ત્યારે તેણે શાપ આપ્યો. પ્રથમ લાઇનની લંબાઈ ચોક્કસ તારીખ અને સમય પર આધારિત છે, તેમજ ટાઇમસ્ટેમ્પ છાપવામાં આવી હતી તે સમયે તબક્કા સ્પષ્ટીકરણની લંબાઈ પર આધારિત છે. એટલે કે, ભૂલ શાબ્દિક રીતે ચંદ્રના તબક્કા પર આધારિત હતી!

પ્રથમ પેપર આવૃત્તિ જાર્ગન ફાઇલ (સ્ટીલ-1983) માં આવી લાઇનનું ઉદાહરણ છે જે વર્ણવેલ બગ તરફ દોરી જાય છે, પરંતુ ટાઇપસેટર તેને "નિશ્ચિત" કરે છે. ત્યારથી આને "મૂન ફેઝ બગ" તરીકે વર્ણવવામાં આવ્યું છે.

જો કે, ધારણાઓ સાથે સાવચેત રહો. થોડા વર્ષો પહેલા, CERN (યુરોપિયન સેન્ટર ફોર ન્યુક્લિયર રિસર્ચ) ના એન્જિનિયરોએ લાર્જ ઈલેક્ટ્રોન-પોઝિટ્રોન કોલાઈડર પર કરવામાં આવેલા પ્રયોગોમાં ભૂલોનો સામનો કરવો પડ્યો હતો. વૈજ્ઞાનિકોને પરિણામ બતાવતા પહેલા કમ્પ્યુટર્સ સક્રિય રીતે આ ઉપકરણ દ્વારા જનરેટ કરવામાં આવેલ પ્રચંડ ડેટાની પ્રક્રિયા કરે છે, ઘણા લોકોએ અનુમાન કર્યું હતું કે સોફ્ટવેર કોઈક રીતે ચંદ્રના તબક્કા માટે સંવેદનશીલ હતું. કેટલાક ભયાવહ એન્જિનિયરો સત્યના તળિયે ગયા. ચંદ્રના પસાર થવા દરમિયાન પૃથ્વીના વિરૂપતાને કારણે 27 કિલોમીટર લાંબી રિંગની ભૂમિતિમાં થોડો ફેરફાર થવાને કારણે આ ભૂલ ઊભી થઈ હતી! આ વાર્તા ભૌતિકશાસ્ત્રની લોકસાહિત્યમાં "કણ ભૌતિકશાસ્ત્ર પર ન્યૂટનનો બદલો" તરીકે દાખલ થઈ છે અને ભૌતિકશાસ્ત્રના સૌથી સરળ અને સૌથી જૂના નિયમો અને સૌથી અદ્યતન વૈજ્ઞાનિક ખ્યાલો વચ્ચેના જોડાણનું ઉદાહરણ છે.

ટોયલેટ ફ્લશ કરવાથી ટ્રેન અટકી જાય છે

મેં ક્યારેય સાંભળ્યું છે તે શ્રેષ્ઠ હાર્ડવેર બગ ફ્રાન્સમાં હાઇ સ્પીડ ટ્રેનમાં હતું. બગને કારણે ટ્રેનની ઇમરજન્સી બ્રેકિંગ થઈ, પરંતુ જો તેમાં મુસાફરો હોય તો જ. આવા દરેક કિસ્સામાં, ટ્રેનને સેવામાંથી બહાર કાઢવામાં આવી હતી, તપાસવામાં આવી હતી, પરંતુ કંઈ મળ્યું ન હતું. પછી તેને લાઇન પર પાછો મોકલવામાં આવ્યો, અને તે તરત જ સ્ટોપ પર તૂટી પડ્યો.

એક ચેકિંગ દરમિયાન ટ્રેનમાં મુસાફરી કરી રહેલો એક એન્જિનિયર ટોયલેટ ગયો હતો. તે તરત જ ધોવાઇ ગયો, બૂમ! તત્કાલીન બંધ.

એન્જિનિયરે ડ્રાઇવરનો સંપર્ક કર્યો અને પૂછ્યું:

- બ્રેક મારતા પહેલા તમે શું કરી રહ્યા હતા?

- સારું, મેં નીચે ઉતરવાનું ધીમુ કર્યું ...

આ વિચિત્ર હતું, કારણ કે સામાન્ય કામગીરી દરમિયાન ટ્રેન ડઝનેક વખત ઉતરતી વખતે ધીમી પડી જાય છે. ટ્રેન આગળ વધી, અને પછીના ઉતરતા ડ્રાઇવરે ચેતવણી આપી:

- હું ધીમું થવા જઈ રહ્યો છું.

કઈ જ નથી થયું.

- છેલ્લી બ્રેકિંગ દરમિયાન તમે શું કર્યું? - ડ્રાઈવરને પૂછ્યું.

- સારું... હું શૌચાલયમાં હતો...

- સારું, પછી શૌચાલય પર જાઓ અને જ્યારે અમે ફરીથી નીચે જઈએ ત્યારે તમે જે કર્યું તે કરો!

એન્જિનિયર શૌચાલયમાં ગયો, અને જ્યારે ડ્રાઇવરે ચેતવણી આપી: "હું ધીમું છું," તેણે પાણી ફ્લશ કર્યું. અલબત્ત, ટ્રેન તરત જ ઉભી રહી ગઈ.

હવે તેઓ સમસ્યાનું પુનઃઉત્પાદન કરી શકે છે અને તેનું કારણ શોધવાની જરૂર છે.

બે મિનિટ પછી, તેઓએ જોયું કે એન્જિન બ્રેક રિમોટ કંટ્રોલ કેબલ (ટ્રેનમાં દરેક છેડે એક એન્જિન હતું) ઇલેક્ટ્રિકલ કેબિનેટની દિવાલથી ડિસ્કનેક્ટ થઈ ગયું હતું અને તે રિલે પર પડેલું હતું જે ટોયલેટ પ્લગ સોલેનોઈડને નિયંત્રિત કરે છે... જ્યારે રિલે ચાલુ કરવામાં આવ્યું હતું, તેણે બ્રેક કેબલમાં દખલગીરી ઊભી કરી હતી, અને નિષ્ફળતા સામે સિસ્ટમના રક્ષણમાં ઇમરજન્સી બ્રેકિંગનો સમાવેશ થાય છે.

ગેટવે જે FORTRAN ને ધિક્કારે છે

થોડા મહિના પહેલા અમે નોંધ્યું હતું કે મેઇનલેન્ડ પર નેટવર્ક કનેક્શન્સ [આ હવાઈમાં હતું] ખૂબ જ ધીમા થઈ રહ્યા હતા. આ 10-15 મિનિટ સુધી ટકી શકે છે અને પછી અચાનક ફરીથી થાય છે. થોડા સમય પછી, મારા સાથીદારે મને ફરિયાદ કરી કે મેઇનલેન્ડ પર નેટવર્ક કનેક્શન છે સામાન્ય રીતે કામ કરતું નથી. તેની પાસે કેટલાક FORTRAN કોડ હતા જેને મુખ્ય ભૂમિ પરના મશીનમાં નકલ કરવાની જરૂર હતી, પરંતુ તે થઈ શક્યું નહીં કારણ કે "નેટવર્ક FTP અપલોડ પૂર્ણ કરવા માટે પૂરતો સમય રોકી શક્યું ન હતું."

હા, તે બહાર આવ્યું છે કે જ્યારે કોઈ સાથીદારે મુખ્ય ભૂમિ પરના મશીન પર FORTRAN માં સ્રોત કોડ સાથેની ફાઇલ FTP કરવાનો પ્રયાસ કર્યો ત્યારે નેટવર્ક નિષ્ફળતાઓ આવી. અમે ફાઇલને આર્કાઇવ કરવાનો પ્રયાસ કર્યો: પછી તે સરળતાથી કૉપિ કરવામાં આવી હતી (પરંતુ લક્ષ્ય મશીનમાં અનપેકર ન હતું, તેથી સમસ્યા હલ થઈ ન હતી). અંતે અમે FORTRAN કોડને ખૂબ જ નાના ટુકડાઓમાં "વિભાજિત" કર્યો અને તેને એક સમયે એક મોકલ્યો. મોટાભાગના ટુકડાઓ સમસ્યા વિના નકલ કરવામાં આવ્યા હતા, પરંતુ થોડા ટુકડાઓ પસાર થયા ન હતા, અથવા પછી પસાર થયા હતા અનેક પ્રયાસો

જ્યારે અમે સમસ્યારૂપ ફકરાઓની તપાસ કરી, ત્યારે અમને જાણવા મળ્યું કે તેઓમાં કંઈક સામ્ય છે: તે બધામાં કોમેન્ટ બ્લોક્સ છે જે કેપિટલ C (ફોરટ્રાનમાં કોમેન્ટ કરવાનું પસંદ કરનાર સહકર્મી તરીકે) ની લીટીઓ સાથે શરૂ અને સમાપ્ત થાય છે. અમે મુખ્ય ભૂમિ પરના નેટવર્ક નિષ્ણાતોને ઇમેઇલ કર્યા અને મદદ માટે પૂછ્યું. અલબત્ત, તેઓ અમારી ફાઈલોના નમૂનાઓ જોવા માંગતા હતા જે FTP દ્વારા ટ્રાન્સફર કરી શકાતા ન હતા... પરંતુ અમારા પત્રો તેમના સુધી પહોંચ્યા ન હતા. છેલ્લે અમે એક સરળ સાથે આવ્યા વર્ણન કરોટ્રાન્સફર ન કરી શકાય તેવી ફાઇલો કેવી દેખાય છે. તે કામ કર્યું :) [હું અહીં સમસ્યારૂપ ફોર્ટ્રેન ટિપ્પણીઓમાંથી એકનું ઉદાહરણ ઉમેરવાની હિંમત કરું? કદાચ તે યોગ્ય નથી!]

અંતે અમે તેને શોધવામાં સફળ થયા. અમારા કેમ્પસના ભાગ અને મેઇનલેન્ડ નેટવર્ક વચ્ચે તાજેતરમાં એક નવો ગેટવે ઇન્સ્ટોલ કરવામાં આવ્યો હતો. તેને પેકેટો ટ્રાન્સમિટ કરવામાં ભારે મુશ્કેલી હતી જેમાં અપરકેસ C ના પુનરાવર્તિત બિટ્સ હતા! આમાંના થોડાક પેકેટો તમામ ગેટવે સંસાધનો લઈ શકે છે અને મોટાભાગના અન્ય પેકેટોને પસાર થતા અટકાવી શકે છે. અમે ગેટવે ઉત્પાદકને ફરિયાદ કરી... અને તેઓએ જવાબ આપ્યો: “ઓહ, હા, તમને વારંવાર Cની ભૂલનો સામનો કરવો પડી રહ્યો છે! અમે તેના વિશે પહેલેથી જ જાણીએ છીએ. ” અમે આખરે અન્ય ઉત્પાદક પાસેથી નવો ગેટવે ખરીદીને સમસ્યાનું નિરાકરણ કર્યું (અગાઉના બચાવમાં, FORTRAN પ્રોગ્રામ્સ સ્થાનાંતરિત કરવામાં અસમર્થતા એ કેટલાક લોકો માટે ફાયદો હોઈ શકે છે!).

કપરો સમય

થોડા વર્ષો પહેલા, જ્યારે ફેઝ 40 ક્લિનિકલ ટ્રાયલ્સનો ખર્ચ ઘટાડવા માટે પર્લમાં ETL સિસ્ટમ બનાવવા પર કામ કરી રહ્યો હતો, ત્યારે મારે લગભગ 000 તારીખો પર પ્રક્રિયા કરવાની જરૂર હતી. તેમાંથી બે પરીક્ષા પાસ કરી શક્યા ન હતા. આનાથી મને બહુ પરેશાન નહોતું થયું કારણ કે આ તારીખો ક્લાયન્ટ દ્વારા આપવામાં આવેલ ડેટામાંથી લેવામાં આવી હતી જે ઘણી વાર હતી, શું આપણે કહીએ કે આશ્ચર્યજનક છે. પરંતુ જ્યારે મેં મૂળ ડેટા તપાસ્યો, ત્યારે તે બહાર આવ્યું કે આ તારીખો જાન્યુઆરી 1, 2011 અને જાન્યુઆરી 1, 2007 છે. મેં વિચાર્યું કે મેં હમણાં જ લખેલા પ્રોગ્રામમાં બગ શામેલ છે, પરંતુ તે બહાર આવ્યું કે તે પહેલેથી જ 30 વર્ષનો છે. જૂનું સૉફ્ટવેર ઇકોસિસ્ટમથી અજાણ્યા લોકો માટે આ રહસ્યમય લાગી શકે છે. પૈસા કમાવવાના અન્ય કંપનીના લાંબા સમયથી ચાલતા નિર્ણયને કારણે, મારા ક્લાયન્ટે મને એક બગને ઠીક કરવા માટે ચૂકવણી કરી હતી જે એક કંપનીએ અકસ્માતે અને બીજી હેતુપૂર્વક રજૂ કરી હતી. હું જેની વાત કરી રહ્યો છું તે તમે સમજી શકો તે માટે, મારે તે કંપની વિશે વાત કરવાની જરૂર છે કે જેણે બગ બનવામાં સમાપ્ત થયેલ સુવિધા ઉમેરી, તેમજ કેટલીક અન્ય રસપ્રદ ઘટનાઓ કે જેણે મેં સુધારેલ રહસ્યમય ભૂલમાં ફાળો આપ્યો.

સારા જૂના દિવસોમાં, Apple કોમ્પ્યુટર કેટલીકવાર સ્વયંભૂ રીતે તેમની તારીખ 1 જાન્યુઆરી, 1904 પર ફરીથી સેટ કરી દેતા હતા. કારણ સરળ હતું: તે તારીખ અને સમયનો ટ્રૅક રાખવા માટે બેટરી સંચાલિત "સિસ્ટમ ઘડિયાળ" નો ઉપયોગ કરે છે. જ્યારે બેટરી મરી ગઈ ત્યારે શું થયું? કોમ્પ્યુટર યુગની શરૂઆતથી સેકન્ડની સંખ્યા દ્વારા તારીખને ટ્રેક કરવાનું શરૂ કર્યું. યુગ દ્વારા અમારો અર્થ મૂળ તારીખનો સંદર્ભ હતો, અને મેકિન્ટોશ માટે તે જાન્યુઆરી 1, 1904 હતી. અને બેટરી મૃત્યુ પામ્યા પછી, વર્તમાન તારીખ ઉલ્લેખિત તારીખ પર ફરીથી સેટ કરવામાં આવી હતી. પણ આવું કેમ થયું?

અગાઉ, Apple મૂળ તારીખથી સેકંડની સંખ્યાને સંગ્રહિત કરવા માટે 32 બિટ્સનો ઉપયોગ કરતી હતી. એક બીટ બે મૂલ્યોમાંથી એકને સંગ્રહિત કરી શકે છે - 1 અથવા 0. બે બિટ્સ ચારમાંથી એક મૂલ્યને સંગ્રહિત કરી શકે છે: 00, 01, 10, 11. ત્રણ બિટ્સ - આઠમાંથી એક મૂલ્ય: 000, 001, 010, 011, 100 , 101, 110, 111, વગેરે. અને 32 232 મૂલ્યોમાંથી એક સંગ્રહ કરી શકે છે, એટલે કે, 4 સેકન્ડ. Apple તારીખો માટે, આ લગભગ 294 વર્ષ જેટલું છે, તેથી જૂના Macs 967 પછીની તારીખોને હેન્ડલ કરી શકતા નથી. અને જો સિસ્ટમની બેટરી મૃત્યુ પામે છે, તો યુગની શરૂઆતથી તારીખ 296 સેકન્ડ પર રીસેટ કરવામાં આવે છે, અને જ્યારે પણ તમે કમ્પ્યુટર ચાલુ કરો ત્યારે તમારે મેન્યુઅલી તારીખ સેટ કરવી પડશે (અથવા તમે નવી બેટરી ખરીદો ત્યાં સુધી).

જો કે, એપલના યુગ પછીની તારીખોને સેકન્ડ તરીકે સંગ્રહિત કરવાના નિર્ણયનો અર્થ એ થયો કે અમે યુગ પહેલાની તારીખોને નિયંત્રિત કરી શકતા નથી, જેના દૂરગામી પરિણામો હતા, જેમ કે આપણે જોઈશું. એપલે એક ફીચર રજૂ કર્યું, બગ નહીં. અન્ય બાબતોમાં, આનો અર્થ એ થયો કે મેકિન્ટોશ ઓપરેટિંગ સિસ્ટમ "મિલેનિયમ બગ" (જેના પર પ્રતિબંધોને ટાળવા માટે તેમની પોતાની તારીખ સિસ્ટમો ધરાવતી ઘણી મેક એપ્લિકેશનો વિશે કહી શકાય નહીં).

આગળ વધો. અમે લોટસ 1-2-3નો ઉપયોગ કર્યો, IBM ની "કિલર એપ્લિકેશન" જેણે પીસી ક્રાંતિ શરૂ કરવામાં મદદ કરી, જોકે એપલ કમ્પ્યુટર્સમાં VisiCalc હતું, જેણે વ્યક્તિગત કમ્પ્યુટરને સફળ બનાવ્યું. વાજબી રીતે, જો 1-2-3 દેખાયા ન હોત, તો PC ભાગ્યે જ ઉપડ્યા હોત, અને વ્યક્તિગત કમ્પ્યુટરનો ઇતિહાસ ખૂબ જ અલગ રીતે વિકસિત થઈ શક્યો હોત. લોટસ 1-2-3 ને ખોટી રીતે 1900 ને લીપ વર્ષ તરીકે ગણવામાં આવે છે. જ્યારે માઇક્રોસોફ્ટે તેની પ્રથમ સ્પ્રેડશીટ, મલ્ટીપ્લાન બહાર પાડી, ત્યારે તેણે બજારનો એક નાનો હિસ્સો કબજે કર્યો. અને જ્યારે તેઓએ એક્સેલ પ્રોજેક્ટ શરૂ કર્યો, ત્યારે તેઓએ માત્ર લોટસ 1-2-3 માંથી પંક્તિ અને કૉલમ નામકરણ યોજનાની નકલ કરવાનું જ નહીં, પણ 1900 ને જાણીજોઈને લીપ વર્ષ તરીકે ગણીને બગ સુસંગતતા સુનિશ્ચિત કરવાનું પણ નક્કી કર્યું. આ સમસ્યા આજે પણ છે. એટલે કે, 1-2-3 માં આ એક બગ હતી, પરંતુ Excel માં તે એક સભાન નિર્ણય હતો જે સુનિશ્ચિત કરે છે કે તમામ 1-2-3 વપરાશકર્તાઓ ડેટા બદલ્યા વિના એક્સેલમાં તેમના કોષ્ટકો આયાત કરી શકે છે, ભલે તે ખોટો હોય.

પરંતુ બીજી સમસ્યા હતી. સૌપ્રથમ, માઈક્રોસોફ્ટે મેકિન્ટોશ માટે એક્સેલ બહાર પાડ્યું, જે 1 જાન્યુઆરી, 1904 પહેલાની તારીખોને ઓળખતું ન હતું. અને એક્સેલમાં, 1 જાન્યુઆરી, 1900 એ યુગની શરૂઆત માનવામાં આવે છે. તેથી, વિકાસકર્તાઓએ ફેરફાર કર્યો જેથી તેમનો પ્રોગ્રામ યુગના પ્રકારને ઓળખે અને ઇચ્છિત યુગને અનુરૂપ ડેટાને પોતાની અંદર સંગ્રહિત કરે. માઇક્રોસોફ્ટે આ વિશે એક સ્પષ્ટીકરણ લેખ પણ લખ્યો હતો. અને આ નિર્ણયથી મારી ભૂલ થઈ.

મારી ETL સિસ્ટમને ગ્રાહકો પાસેથી એક્સેલ સ્પ્રેડશીટ્સ પ્રાપ્ત થઈ છે જે Windows પર બનાવવામાં આવી હતી, પરંતુ Mac પર પણ બનાવી શકાય છે. તેથી, કોષ્ટકમાં યુગની શરૂઆત 1 જાન્યુઆરી, 1900 અથવા 1 જાન્યુઆરી, 1904 હોઈ શકે છે. કેવી રીતે શોધવું? એક્સેલ ફાઇલ ફોર્મેટ જરૂરી માહિતી બતાવે છે, પરંતુ મેં જે પાર્સરનો ઉપયોગ કર્યો હતો તેણે તે દર્શાવ્યું નથી (હવે તે કરે છે), અને ધાર્યું છે કે તમે ચોક્કસ કોષ્ટક માટે યુગ જાણો છો. હું કદાચ એક્સેલ દ્વિસંગી ફોર્મેટને સમજવામાં અને પાર્સર લેખકને પેચ મોકલવામાં વધુ સમય પસાર કરી શક્યો હોત, પરંતુ મારી પાસે ક્લાયન્ટ માટે ઘણું કરવાનું હતું, તેથી મેં યુગને નિર્ધારિત કરવા માટે ઝડપથી એક સંશોધનાત્મક લખ્યું. તેણી સરળ હતી.

એક્સેલમાં, તારીખ 5 જુલાઈ, 1998 ફોર્મેટમાં રજૂ કરી શકાય છે "07-05-98" (નકામું અમેરિકન સિસ્ટમ), "જુલાઈ 5, 98", "જુલાઈ 5, 1998", "5-જુલાઈ-98" અથવા અન્ય કોઈ ફોર્મેટ. અન્ય નકામું ફોર્મેટ (વ્યંગાત્મક રીતે, એક્સેલનું મારું વર્ઝન ઑફર કરતું ન હતું તેમાંથી એક ISO 8601 હતું). જો કે, કોષ્ટકની અંદર, અનફોર્મેટેડ તારીખ ક્યાં તો epoch-35981 માટે "1900" અથવા epoch-34519 માટે "1904" તરીકે સંગ્રહિત કરવામાં આવી હતી (સંખ્યા એ યુગ પછીના દિવસોની સંખ્યા દર્શાવે છે). મેં ફોર્મેટ કરેલી તારીખમાંથી વર્ષ કાઢવા માટે સરળ પાર્સરનો ઉપયોગ કર્યો, અને પછી અનફોર્મેટ કરેલી તારીખમાંથી વર્ષ કાઢવા માટે એક્સેલ પાર્સરનો ઉપયોગ કર્યો. જો બંને મૂલ્યો 4 વર્ષથી અલગ હોય, તો હું જાણતો હતો કે હું epoch-1904 સાથે સિસ્ટમનો ઉપયોગ કરી રહ્યો છું.

શા માટે મેં ફક્ત ફોર્મેટ કરેલી તારીખોનો ઉપયોગ કર્યો નથી? કારણ કે 5 જુલાઈ, 1998 ને "જુલાઈ, 98" તરીકે ફોર્મેટ કરી શકાય છે અને મહિનાનો દિવસ ગુમાવ્યો છે. અમને ઘણી બધી કંપનીઓ પાસેથી કોષ્ટકો પ્રાપ્ત થયા છે જેણે તેમને ઘણી અલગ અલગ રીતે બનાવ્યાં છે કે તારીખો શોધવાનું અમારા પર (આ કિસ્સામાં, મારા પર) હતું. આ ઉપરાંત, જો એક્સેલ તે બરાબર મેળવે છે, તો આપણે પણ જોઈએ!

તે જ સમયે મેં 39082 નો સામનો કર્યો. ચાલો હું તમને યાદ અપાવી દઉં કે લોટસ 1-2-3 એ 1900 ને લીપ વર્ષ માન્યું હતું, અને એક્સેલમાં આનું નિષ્ઠાપૂર્વક પુનરાવર્તન થયું હતું. અને આનાથી વર્ષ 1900 માં એક દિવસનો ઉમેરો થયો હોવાથી, તે જ દિવસ માટે તારીખની ગણતરીના ઘણા કાર્યો ખોટા હોઈ શકે છે. એટલે કે, 39082 જાન્યુઆરી 1, 2011 (Macs પર) અથવા ડિસેમ્બર 31, 2006 (Windows પર) હોઈ શકે છે. જો મારા "વર્ષ પાર્સર" એ ફોર્મેટ કરેલ મૂલ્યમાંથી વર્ષ 2011 કાઢ્યું હોય, તો બધું સારું છે. પરંતુ એક્સેલ પાર્સર જાણતું નથી કે કયા યુગનો ઉપયોગ કરવામાં આવી રહ્યો છે, તે વર્ષ 1900 પરત કરીને epoch-2006 માં ડિફોલ્ટ થાય છે. મારી અરજીએ જોયું કે તફાવત 5 વર્ષનો હતો, તેને એક ભૂલ ગણી, તેને લોગ કર્યું અને અનફોર્મેટેડ મૂલ્ય પરત કર્યું.

આની આસપાસ જવા માટે, મેં આ લખ્યું (સ્યુડોકોડ):

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

અને પછી બધી 40 તારીખો યોગ્ય રીતે વિશ્લેષિત કરવામાં આવી હતી.

મોટા પ્રિન્ટ જોબ્સ મધ્યમાં

1980 ના દાયકાની શરૂઆતમાં, મારા પિતાએ સ્ટોરેજ ટેક્નોલોજીમાં કામ કર્યું, જે હવે બંધ થઈ ગયેલ વિભાગ છે જેણે હાઇ-સ્પીડ ટેપ ફીડિંગ માટે ટેપ ડ્રાઇવ્સ અને ન્યુમેટિક સિસ્ટમ્સ બનાવી છે.

તેઓએ ડ્રાઈવોને ફરીથી ડિઝાઈન કરી જેથી તેમની પાસે સાત "B" ડ્રાઈવો સાથે જોડાયેલ એક સેન્ટ્રલ "A" ડ્રાઈવ હોઈ શકે અને "A" ડ્રાઈવને નિયંત્રિત કરતી RAM માં નાની OS બધી "B" ડ્રાઈવોને રીડ અને રાઈટ ઓપરેશન્સ સોંપી શકે.

દરેક વખતે જ્યારે ડ્રાઇવ “A” શરૂ કરવામાં આવી હતી, ત્યારે ઓપરેટિંગ સિસ્ટમને તેની મેમરીમાં લોડ કરવા માટે “A” સાથે જોડાયેલ પેરિફેરલ ડ્રાઇવમાં ફ્લોપી ડિસ્ક દાખલ કરવી જરૂરી હતી. તે અત્યંત આદિમ હતું: કમ્પ્યુટિંગ પાવર 8-બીટ માઇક્રોકન્ટ્રોલર દ્વારા પ્રદાન કરવામાં આવ્યું હતું.

આવા સાધનો માટે લક્ષ્ય પ્રેક્ષકો ખૂબ મોટા ડેટા વેરહાઉસ ધરાવતી કંપનીઓ હતી - બેંકો, છૂટક સાંકળો વગેરે - જેને ઘણા બધા સરનામાં લેબલ્સ અથવા બેંક સ્ટેટમેન્ટ છાપવાની જરૂર હતી.

એક ગ્રાહકને સમસ્યા હતી. પ્રિન્ટ જોબની મધ્યમાં, એક ચોક્કસ ડ્રાઈવ “A” કામ કરવાનું બંધ કરી શકે છે, જેના કારણે આખું કામ અટકી જાય છે. ડ્રાઇવની કામગીરીને પુનઃસ્થાપિત કરવા માટે, સ્ટાફે બધું રીબૂટ કરવું પડ્યું. અને જો છ કલાકના કાર્યની મધ્યમાં આ બન્યું, તો કમ્પ્યુટરનો ખર્ચાળ સમયનો મોટો જથ્થો ખોવાઈ ગયો અને સમગ્ર કામગીરીનું શેડ્યૂલ ખોરવાઈ ગયું.

સ્ટોરેજ ટેક્નોલોજીસ તરફથી ટેકનિશિયન મોકલવામાં આવ્યા હતા. પરંતુ તેમના શ્રેષ્ઠ પ્રયાસો છતાં, તેઓ પરીક્ષણ પરિસ્થિતિઓમાં બગનું પુનઃઉત્પાદન કરવામાં અસમર્થ હતા: તે મોટા પ્રિન્ટ જોબ્સની મધ્યમાં બનતું હોય તેવું લાગતું હતું. સમસ્યા હાર્ડવેરની ન હતી, તેઓએ તેઓ જે કરી શકે તે બધું બદલી નાખ્યું: RAM, માઇક્રોકન્ટ્રોલર, ફ્લોપી ડ્રાઇવ, ટેપ ડ્રાઇવનો દરેક કલ્પનાશીલ ભાગ - સમસ્યા યથાવત રહી.

પછી ટેકનિશિયનોએ હેડક્વાર્ટર બોલાવીને એક્સપર્ટને બોલાવ્યા.

નિષ્ણાતે ખુરશી અને કોફીનો કપ પકડ્યો, કોમ્પ્યુટર રૂમમાં બેઠો - તે દિવસોમાં કોમ્પ્યુટરને સમર્પિત રૂમ હતા - અને સ્ટાફની કતારમાં મોટી પ્રિન્ટ જોબ જોયા. નિષ્ણાત નિષ્ફળતાની રાહ જોઈ રહ્યો હતો - અને તે થયું. બધાએ એક્સપર્ટ તરફ જોયું, પણ આવું કેમ થયું તેની તેને કોઈ જાણ નહોતી. તેથી તેણે ફરીથી કતારમાં કામ કરવાનો આદેશ આપ્યો, અને તમામ સ્ટાફ અને ટેકનિશિયન કામ પર પાછા ફર્યા.

નિષ્ણાત ફરીથી ખુરશીમાં બેસી ગયો અને નિષ્ફળતાની રાહ જોવા લાગ્યો. લગભગ છ કલાક વીતી ગયા અને નિષ્ફળતા આવી. નિષ્ણાતને ફરીથી કોઈ વિચાર નહોતો, સિવાય કે બધું જ લોકોથી ભરેલા રૂમમાં થયું. તેણે મિશનને ફરીથી શરૂ કરવાનો આદેશ આપ્યો, પાછો બેસી ગયો અને રાહ જોવા લાગ્યો.

ત્રીજી નિષ્ફળતા દ્વારા, નિષ્ણાતે કંઈક નોંધ્યું. જ્યારે કર્મચારીઓએ વિદેશી ડ્રાઇવમાં ટેપ બદલ્યા ત્યારે નિષ્ફળતા આવી. તદુપરાંત, એક કર્મચારી ફ્લોર પરની ચોક્કસ ટાઇલમાંથી પસાર થતાંની સાથે જ નિષ્ફળતા આવી.

ઊંચું માળખું 6 થી 8 ઇંચની ઊંચાઈએ નાખવામાં આવેલી એલ્યુમિનિયમ ટાઇલ્સથી બનેલું હતું. કોઈ મહત્વપૂર્ણ કેબલ પર આકસ્મિક રીતે પગ મૂકે નહીં તે માટે કોમ્પ્યુટરના અસંખ્ય વાયર ઊંચા માળની નીચે દોડ્યા હતા. ઉંચા માળની નીચે કાટમાળ ન આવે તે માટે ટાઇલ્સ ખૂબ જ ચુસ્ત રીતે નાખવામાં આવી હતી.

નિષ્ણાતને સમજાયું કે એક ટાઇલ્સ વિકૃત હતી. જ્યારે કોઈ કર્મચારી તેના ખૂણા પર પગ મૂકે છે, ત્યારે ટાઇલની કિનારીઓ બાજુની ટાઇલ્સ સામે ઘસવામાં આવી હતી. પ્લાસ્ટિકના ભાગો કે જે ટાઇલ્સને જોડે છે તે પણ તેમની સાથે ઘસવામાં આવે છે, જેના કારણે સ્થિર માઇક્રોડિસ્ચાર્જ થાય છે જેણે રેડિયો ફ્રીક્વન્સીમાં દખલગીરી ઊભી કરી હતી.

આજે, RAM રેડિયો ફ્રીક્વન્સી દખલથી વધુ સારી રીતે સુરક્ષિત છે. પણ એ વર્ષોમાં એવું નહોતું. નિષ્ણાતને સમજાયું કે આ હસ્તક્ષેપ મેમરીને વિક્ષેપિત કરે છે, અને તેની સાથે ઑપરેટિંગ સિસ્ટમની કામગીરી. તેણે સપોર્ટ સર્વિસને કૉલ કર્યો, નવી ટાઇલ્સનો ઓર્ડર આપ્યો, તેને જાતે ઇન્સ્ટોલ કર્યો અને સમસ્યા અદૃશ્ય થઈ ગઈ.

તે ઉચ્ચ ભરતી છે!

વાર્તા સર્વર રૂમમાં બની હતી, પોર્ટ્સમાઉથ (મને લાગે છે), ડોક્સ વિસ્તારમાં ઓફિસના ચોથા કે પાંચમા માળે.

એક દિવસ મુખ્ય ડેટાબેઝ સાથેનું યુનિક્સ સર્વર ક્રેશ થયું. તેઓએ તેને રીબૂટ કર્યો, પરંતુ તે ખુશીથી વારંવાર પડતો રહ્યો. અમે સપોર્ટ સર્વિસમાંથી કોઈને કૉલ કરવાનું નક્કી કર્યું.

સહાયક વ્યક્તિ... મને લાગે છે કે તેનું નામ માર્ક હતું, પણ તેનાથી કોઈ ફરક પડતો નથી... મને નથી લાગતું કે હું તેને ઓળખું છું. તે વાંધો નથી, ખરેખર. ચાલો માર્ક સાથે વળગી રહીએ, ઠીક છે? મહાન.

તેથી, થોડા કલાકો પછી માર્ક આવ્યો (તે લીડ્ઝથી પોર્ટ્સમાઉથ સુધીનો લાંબો રસ્તો નથી, તમે જાણો છો), સર્વર ચાલુ કર્યું અને બધું સમસ્યા વિના કામ કર્યું. લાક્ષણિક ડેમ સપોર્ટ, ક્લાયંટ તેના વિશે ખૂબ જ નારાજ થઈ જાય છે. માર્ક લોગ ફાઈલો દ્વારા જુએ છે અને તેને કંઈપણ અપ્રિય નથી મળ્યું. તેથી માર્ક ટ્રેનમાં પાછો ફરે છે (અથવા તે ગમે તે પરિવહનના માર્ગ પર પહોંચ્યો હોય, હું જાણું છું તે બધા માટે તે એક લંગડી ગાય હોઈ શકે છે... કોઈપણ રીતે, તે વાંધો નથી, ઠીક છે?) અને બગાડ કરીને, લીડ્ઝ તરફ પાછો જાય છે. દિવસ.

તે જ સાંજે સર્વર ફરીથી ક્રેશ થાય છે. વાર્તા એક જ છે... સર્વર વધતું નથી. માર્ક દૂરથી મદદ કરવાનો પ્રયાસ કરે છે, પરંતુ ક્લાયંટ સર્વર શરૂ કરી શકતું નથી.

બીજી ટ્રેન, બસ, લેમન મેરીંગ્યુ અથવા અન્ય કોઈ વાહિયાત, અને માર્ક પોર્ટ્સમાઉથ પાછા ફર્યા છે. જુઓ, સર્વર કોઈપણ સમસ્યા વિના બૂટ થાય છે! ચમત્કાર. માર્ક ઓપરેટિંગ સિસ્ટમ અથવા સોફ્ટવેર સાથે બધું વ્યવસ્થિત છે કે નહીં તે તપાસવામાં ઘણા કલાકો વિતાવે છે અને લીડ્ઝ માટે રવાના થાય છે.

દિવસના મધ્યમાં સર્વર ક્રેશ થાય છે (તેને સરળ લો!). આ વખતે સર્વર બદલવા માટે હાર્ડવેર સપોર્ટ લોકોને લાવવાનું વ્યાજબી લાગે છે. પણ ના, લગભગ 10 કલાક પછી તે પણ પડી જાય છે.

ઘણા દિવસો સુધી પરિસ્થિતિનું પુનરાવર્તન થયું. સર્વર કામ કરે છે, લગભગ 10 કલાક પછી ક્રેશ થાય છે અને આગામી 2 કલાક સુધી શરૂ થતું નથી. તેઓએ ઠંડક, મેમરી લીક્સ તપાસ્યું, તેઓએ બધું તપાસ્યું, પરંતુ કંઈ મળ્યું નહીં. પછી ક્રેશ બંધ થઈ ગયા.

અઠવાડિયું બેદરકાર પસાર થયું... બધા ખુશ હતા. જ્યાં સુધી તે બધું ફરી શરૂ ન થાય ત્યાં સુધી ખુશ. ચિત્ર એ જ છે. 10 કલાક કામ, 2-3 કલાકનો ડાઉનટાઇમ...

અને પછી કોઈએ (મને લાગે છે કે તેઓએ મને કહ્યું કે આ વ્યક્તિને IT સાથે કોઈ લેવાદેવા નથી) કહ્યું:

"તે ભરતી છે!"

ઉદ્ગાર ખાલી તાકીને મળ્યા હતા, અને કોઈનો હાથ કદાચ સુરક્ષા કૉલ બટન પર અચકાયો હતો.

"તે ભરતી સાથે કામ કરવાનું બંધ કરે છે."

આઇટી સપોર્ટ વર્કર્સ માટે આ સંપૂર્ણપણે વિદેશી ખ્યાલ હશે, જેઓ કોફી માટે બેસીને ટાઇડ યરબુક વાંચવાની શક્યતા નથી. તેઓએ સમજાવ્યું કે આ કોઈપણ રીતે ભરતી સાથે સંબંધિત ન હોઈ શકે, કારણ કે સર્વર નિષ્ફળતા વિના એક અઠવાડિયાથી કામ કરી રહ્યું હતું.

"ગયા અઠવાડિયે ભરતી ઓછી હતી, પરંતુ આ અઠવાડિયે તે વધારે છે."

જેમની પાસે યાટ લાયસન્સ નથી તેમના માટે થોડી પરિભાષા. ભરતી ચંદ્ર ચક્ર પર આધાર રાખે છે. અને જેમ જેમ પૃથ્વી ફરે છે, દર 12,5 કલાકે સૂર્ય અને ચંદ્રનું ગુરુત્વાકર્ષણ ખેંચાણ ભરતી તરંગ બનાવે છે. 12,5-કલાકના ચક્રની શરૂઆતમાં ઊંચી ભરતી હોય છે, ચક્રની મધ્યમાં એક ભરતી હોય છે, અને અંતે ફરીથી ઊંચી ભરતી હોય છે. પરંતુ જેમ જેમ ચંદ્રની ભ્રમણકક્ષા બદલાય છે તેમ તેમ નીચા અને ઉચ્ચ ભરતી વચ્ચેનો તફાવત પણ બદલાય છે. જ્યારે ચંદ્ર સૂર્ય અને પૃથ્વીની વચ્ચે હોય છે અથવા પૃથ્વીની વિરુદ્ધ બાજુએ હોય છે (પૂર્ણ ચંદ્ર અથવા કોઈ ચંદ્ર નથી), ત્યારે આપણને સિઝીજીન ભરતી મળે છે - સૌથી વધુ ઊંચી ભરતી અને સૌથી ઓછી નીચી ભરતી. અડધા ચંદ્ર પર આપણને ચતુર્થાંશ ભરતી મળે છે - સૌથી નીચી ભરતી. બે ચરમસીમાઓ વચ્ચેનો તફાવત ઘણો ઓછો થાય છે. ચંદ્ર ચક્ર 28 દિવસ ચાલે છે: સિઝીજીયન - ચતુર્થાંશ - સિઝીજીયન - ચતુર્થાંશ.

જ્યારે ટેકનિશિયનોને ભરતીના દળોનો સાર સમજાવવામાં આવ્યો, ત્યારે તેઓએ તરત જ વિચાર્યું કે તેઓએ પોલીસને બોલાવવાની જરૂર છે. અને તદ્દન તાર્કિક. પરંતુ તે તારણ આપે છે કે મિત્ર સાચો હતો. બે અઠવાડિયા પહેલા, એક વિનાશક ઓફિસથી દૂર ન હતો. દર વખતે જ્યારે ભરતી તેને ચોક્કસ ઊંચાઈ સુધી ઉભી કરે છે, ત્યારે જહાજની રડાર પોસ્ટ સર્વર રૂમના ફ્લોરના સ્તરે સમાપ્ત થાય છે. અને રડાર (અથવા ઈલેક્ટ્રોનિક યુદ્ધના સાધનો, અથવા કોઈ અન્ય લશ્કરી રમકડા) એ કમ્પ્યુટર્સમાં અંધાધૂંધી ઊભી કરી.

રોકેટ માટે ફ્લાઇટ મિશન

મને એક મોટી (લગભગ 400 હજાર લાઇન) રોકેટ લોંચ કંટ્રોલ અને મોનિટરિંગ સિસ્ટમને ઓપરેટિંગ સિસ્ટમ, કમ્પાઇલર અને ભાષાના નવા વર્ઝનમાં પોર્ટ કરવાનું કામ સોંપવામાં આવ્યું હતું. વધુ સ્પષ્ટ રીતે કહીએ તો, સોલારિસ 2.5.1 થી સોલારિસ 7 સુધી, અને એડા 83 માં લખાયેલ વર્ડિક્સ એડા ડેવલપમેન્ટ સિસ્ટમ (વીએડીએસ) થી, એડા 95 માં લખાયેલ રેશનલ એપેક્સ એડા સિસ્ટમ સુધી. VADS રેશનલ દ્વારા ખરીદવામાં આવ્યું હતું, અને તેનું ઉત્પાદન હતું. અપ્રચલિત, જોકે Rational એ એપેક્સ કમ્પાઈલરમાં સંક્રમણને સરળ બનાવવા માટે VADS-વિશિષ્ટ પેકેજોના સુસંગત સંસ્કરણોને અમલમાં મૂકવાનો પ્રયાસ કર્યો હતો.

ત્રણ લોકોએ મને કોડને સ્વચ્છ રીતે સંકલિત કરવામાં મદદ કરી. બે અઠવાડિયા લાગ્યા. અને પછી મેં સિસ્ટમને કામ કરવા માટે મારા પોતાના પર કામ કર્યું. ટૂંકમાં, તે સોફ્ટવેર સિસ્ટમનું સૌથી ખરાબ આર્કિટેક્ચર અને અમલીકરણ હતું જેનો મેં સામનો કર્યો હતો, તેથી પોર્ટને પૂર્ણ કરવામાં બીજા બે મહિના લાગ્યા. સિસ્ટમ પછી પરીક્ષણ માટે સબમિટ કરવામાં આવી હતી, જેમાં ઘણા મહિનાઓ લાગ્યા હતા. મેં પરીક્ષણ દરમિયાન મળી આવેલ બગ્સને તરત જ સુધારી દીધા, પરંતુ તેમની સંખ્યામાં ઝડપથી ઘટાડો થયો (સ્રોત કોડ એક પ્રોડક્શન સિસ્ટમ હતી, તેથી તેની કાર્યક્ષમતા તદ્દન વિશ્વસનીય રીતે કામ કરતી હતી, મારે ફક્ત નવા કમ્પાઇલરમાં અનુકૂલન દરમિયાન ઉદ્ભવેલી ભૂલોને દૂર કરવી પડી હતી). આખરે, જ્યારે બધું જોઈએ તે પ્રમાણે કામ કરતું હતું, ત્યારે મને બીજા પ્રોજેક્ટમાં ટ્રાન્સફર કરવામાં આવ્યો.

અને થેંક્સગિવીંગ પહેલા શુક્રવારે ફોન રણક્યો.

રોકેટ લોન્ચનું પરીક્ષણ લગભગ ત્રણ અઠવાડિયામાં થવાનું હતું, અને કાઉન્ટડાઉનના પ્રયોગશાળા પરીક્ષણો દરમિયાન, આદેશોનો ક્રમ અવરોધિત કરવામાં આવ્યો હતો. વાસ્તવિક જીવનમાં, આ પરીક્ષણને અટકાવી દેશે, અને જો એન્જિન શરૂ થયાની થોડીક સેકન્ડોમાં અવરોધ આવી જાય, તો સહાયક પ્રણાલીઓમાં ઘણી બદલી ન શકાય તેવી ક્રિયાઓ થશે, જેના માટે રોકેટની લાંબી - અને ખર્ચાળ - તૈયારીની જરૂર પડશે. તે શરૂ થયું ન હોત, પરંતુ ઘણા લોકો સમય અને ઘણા બધા પૈસા ગુમાવવાથી ખૂબ જ નારાજ થયા હોત. ડિપાર્ટમેન્ટ ઑફ ડિફેન્સ અવિચારી રીતે નાણાં ખર્ચે છે એવું કોઈને તમને કહેવા દો નહીં—હું ક્યારેય એવા કોન્ટ્રાક્ટિંગ મેનેજરને મળ્યો નથી કે જેણે શેડ્યૂલ પ્રમાણે બજેટ પ્રથમ કે બીજું ન રાખ્યું હોય.

પાછલા મહિનાઓમાં, આ કાઉન્ટડાઉન ચેલેન્જ ઘણી વિવિધતાઓમાં સેંકડો વખત ચલાવવામાં આવી હતી, જેમાં માત્ર થોડીક નાની અડચણો હતી. તેથી આ બનવાની સંભાવના ઘણી ઓછી હતી, પરંતુ તેના પરિણામો ખૂબ જ નોંધપાત્ર હતા. આ બંને પરિબળોનો ગુણાકાર કરો, અને તમે સમજી શકશો કે સમાચાર મારા અને ડઝનેક એન્જિનિયરો અને મેનેજરો માટે બરબાદ રજાના સપ્તાહની આગાહી કરે છે.

અને સિસ્ટમને પોર્ટ કરનાર વ્યક્તિ તરીકે મને ધ્યાન આપવામાં આવ્યું હતું.

મોટાભાગની સુરક્ષા-નિર્ણાયક સિસ્ટમોની જેમ, ઘણા બધા પરિમાણો લૉગ કરવામાં આવ્યા હતા, તેથી કોડની કેટલીક લાઇનોને ઓળખવી એકદમ સરળ હતી જે સિસ્ટમ ક્રેશ થાય તે પહેલાં એક્ઝિક્યુટ કરવામાં આવી હતી. અને અલબત્ત, તેમના વિશે કંઈપણ અસામાન્ય નહોતું; સમાન અભિવ્યક્તિઓ એક જ દોડ દરમિયાન શાબ્દિક રીતે હજારો વખત સફળતાપૂર્વક ચલાવવામાં આવી હતી.

અમે એપેક્સમાંથી લોકોને Rational માં બોલાવ્યા કારણ કે તેઓએ જ કમ્પાઈલરનો વિકાસ કર્યો હતો અને તેઓએ વિકસાવેલી કેટલીક દિનચર્યાઓને શંકાસ્પદ કોડમાં બોલાવવામાં આવી હતી. તેઓ (અને બીજા બધા) પ્રભાવિત થયા હતા કે શાબ્દિક રીતે રાષ્ટ્રીય મહત્વની સમસ્યાના મૂળ સુધી પહોંચવાની જરૂર છે.

જર્નલ્સમાં કંઈપણ રસપ્રદ ન હોવાથી, અમે સ્થાનિક પ્રયોગશાળામાં સમસ્યાનું પુનઃઉત્પાદન કરવાનો પ્રયાસ કરવાનું નક્કી કર્યું. આ એક સરળ કાર્ય ન હતું કારણ કે આ ઘટના 1000 રન દીઠ લગભગ એક વખત બની હતી. એક શંકાસ્પદ કારણ એ હતું કે વિક્રેતા દ્વારા વિકસિત મ્યુટેક્સ ફંક્શન (VADS સ્થળાંતર પેકેજનો ભાગ) પર કૉલ Unlock અનલૉક કરવા તરફ દોરી ન હતી. પ્રોસેસિંગ થ્રેડ કે જે ફંક્શનને પ્રોસેસ કરે છે તે હાર્ટબીટ સંદેશાઓ પર પ્રક્રિયા કરે છે, જે દર સેકન્ડે નજીવા રીતે આવે છે. અમે ફ્રીક્વન્સી વધારીને 10 હર્ટ્ઝ કરી, એટલે કે પ્રતિ સેકન્ડમાં 10 વખત, અને દોડવાનું શરૂ કર્યું. લગભગ એક કલાક બાદ સિસ્ટમે તાળું મારી દીધું હતું. લોગમાં, અમે જોયું કે રેકોર્ડ કરેલા સંદેશાઓનો ક્રમ નિષ્ફળ પરીક્ષણ દરમિયાન જેવો જ હતો. અમે ઘણા વધુ રન બનાવ્યા, સિસ્ટમ શરૂ થયાના 45-90 મિનિટ પછી સતત અવરોધિત કરવામાં આવી હતી, અને દરેક વખતે લોગમાં સમાન માર્ગ શામેલ હતો. ભલે અમે તકનીકી રીતે જુદા જુદા કોડ ચલાવતા હતા - સંદેશની આવર્તન અલગ હતી - સિસ્ટમનું વર્તન સમાન હતું, તેથી અમને વિશ્વાસ હતો કે આ લોડ દૃશ્ય સમાન સમસ્યાનું કારણ બની રહ્યું છે.

હવે આપણે એ સમજવાની જરૂર છે કે અભિવ્યક્તિના ક્રમમાં બ્લોકિંગ બરાબર ક્યાં થયું છે.

સિસ્ટમના આ અમલીકરણમાં Ada ટાસ્ક સિસ્ટમનો ઉપયોગ કરવામાં આવ્યો, અને તેનો અતિશય ખરાબ રીતે ઉપયોગ થયો. Ada માં કાર્યો એ ઉચ્ચ-સ્તરની એકસાથે એક્ઝિક્યુટેબલ રચના છે, જે એક્ઝેક્યુશનના થ્રેડો જેવું કંઈક છે, જે ફક્ત ભાષામાં જ બનેલ છે. જ્યારે બે કાર્યોને વાતચીત કરવાની જરૂર હોય, ત્યારે તેઓ "એક અડ્ડો સેટ કરે છે", જરૂરી ડેટાનું વિનિમય કરે છે, અને પછી મુલાકાતને અટકાવે છે અને તેમના સ્વતંત્ર અમલ પર પાછા ફરે છે. જો કે, સિસ્ટમ અલગ રીતે લાગુ કરવામાં આવી હતી. ટાર્ગેટ ટાસ્ક રેન્ડેઝવસ થયા પછી, તે ટાર્ગેટ ટાસ્ક બીજા ટાસ્ક સાથે રેન્ડેઝવાઉઝ થાય છે, જે પછી ત્રીજી ટાસ્ક સાથે રેન્ડઝવાઉઝ થાય છે, અને એવી જ રીતે અમુક પ્રોસેસિંગ પૂર્ણ થાય ત્યાં સુધી. આ પછી, આ બધી મુલાકાત પૂર્ણ થઈ અને દરેક કાર્ય તેના અમલમાં પાછા ફરવું પડ્યું. એટલે કે, અમે વિશ્વની સૌથી મોંઘી ફંક્શન કોલ સિસ્ટમ સાથે કામ કરી રહ્યા હતા, જેણે ઇનપુટ ડેટાના એક ભાગની પ્રક્રિયા કરતી વખતે સમગ્ર "મલ્ટીટાસ્કીંગ" પ્રક્રિયાને અટકાવી દીધી હતી. અને આ પહેલા ફક્ત સમસ્યાઓ તરફ દોરી ન હતી કારણ કે થ્રુપુટ ખૂબ ઓછું હતું.

મેં આ કાર્ય મિકેનિઝમનું વર્ણન કર્યું છે કારણ કે જ્યારે મુલાકાતની વિનંતી કરવામાં આવી હતી અથવા પૂર્ણ થવાની અપેક્ષા રાખવામાં આવી હતી, ત્યારે "ટાસ્ક સ્વિચ" થઈ શકે છે. એટલે કે, પ્રોસેસર અન્ય કાર્ય પર પ્રક્રિયા કરવાનું શરૂ કરી શકે છે જે ચલાવવા માટે તૈયાર છે. તે તારણ આપે છે કે જ્યારે એક કાર્ય બીજા કાર્ય સાથે મળવા માટે તૈયાર હોય છે, ત્યારે એક સંપૂર્ણપણે અલગ કાર્ય ચલાવવાનું શરૂ કરી શકે છે, અને આખરે નિયંત્રણ પ્રથમ મુલાકાતમાં પરત આવે છે. અને અન્ય ઘટનાઓ આવી શકે છે જે કાર્યને સ્વિચ કરવાનું કારણ બને છે; આવી એક ઘટના એ સિસ્ટમ ફંક્શન માટે કૉલ છે, જેમ કે મ્યુટેક્સ પ્રિન્ટિંગ અથવા એક્ઝિક્યુટ કરવું.

કોડની કઈ લાઇન સમસ્યાનું કારણ બની રહી છે તે સમજવા માટે, મારે ટાસ્ક સ્વિચને ટ્રિગર કર્યા વિના નિવેદનોના ક્રમ દ્વારા પ્રગતિ રેકોર્ડ કરવાનો માર્ગ શોધવાની જરૂર છે, જે ક્રેશ થવાથી અટકાવશે. તેથી હું લાભ લઈ શક્યો નહીં Put_Line()I/O કામગીરી કરવાનું ટાળવા માટે. હું કાઉન્ટર વેરીએબલ અથવા તેના જેવું કંઈક સેટ કરી શકું છું, પરંતુ જો હું તેને સ્ક્રીન પર પ્રદર્શિત ન કરી શકું તો હું તેની કિંમત કેવી રીતે જોઈ શકું?

ઉપરાંત, લોગની તપાસ કરતી વખતે, તે બહાર આવ્યું કે, હૃદયના ધબકારા અટકી ગયેલા સંદેશાઓની પ્રક્રિયા હોવા છતાં, જેણે પ્રક્રિયાના તમામ I/O ઑપરેશન્સને અવરોધિત કર્યા હતા અને અન્ય પ્રક્રિયાઓને કરવામાં આવતા અટકાવ્યા હતા, અન્ય સ્વતંત્ર કાર્યો ચલાવવાનું ચાલુ રાખ્યું હતું. એટલે કે, કાર્ય સંપૂર્ણપણે અવરોધિત કરવામાં આવ્યું ન હતું, ફક્ત કાર્યોની (જટિલ) સાંકળ.

આ અવરોધિત અભિવ્યક્તિનું મૂલ્યાંકન કરવા માટે જરૂરી ચાવી હતી.

મેં એક Ada પેકેજ બનાવ્યું જેમાં એક કાર્ય, એક ગણતરી કરેલ પ્રકાર અને તે પ્રકારનું વૈશ્વિક ચલ હતું. અસંખ્ય અક્ષરો સમસ્યારૂપ ક્રમના ચોક્કસ અભિવ્યક્તિઓ સાથે બંધાયેલા હતા (દા.ત. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), અને પછી તેમાં સોંપણી અભિવ્યક્તિઓ દાખલ કરી કે જે વૈશ્વિક વેરીએબલને અનુરૂપ ગણતરી અસાઇન કરે છે. આ બધાનો ઑબ્જેક્ટ કોડ ફક્ત મેમરીમાં સતત સંગ્રહિત હોવાથી, તેના અમલના પરિણામે કાર્ય સ્વિચિંગ અત્યંત અસંભવિત હતું. અમે મુખ્યત્વે અભિવ્યક્તિઓ વિશે શંકાસ્પદ હતા જે કાર્યને સ્વિચ કરી શકે છે, કારણ કે કાર્યને પાછું સ્વિચ કરતી વખતે (ઘણા કારણોસર) પાછા ફરવાને બદલે એક્ઝેક્યુશન પર અવરોધિત થયો હતો.

ટ્રેકિંગ કાર્ય ફક્ત લૂપમાં ચાલ્યું હતું અને વૈશ્વિક ચલનું મૂલ્ય બદલાયું છે કે કેમ તે જોવા માટે સમયાંતરે તપાસ કરવામાં આવે છે. દરેક ફેરફાર સાથે, મૂલ્ય ફાઇલમાં સાચવવામાં આવ્યું હતું. પછી થોડી રાહ જુઓ અને નવો ચેક. મેં ફાઇલમાં વેરીએબલ લખ્યું છે કારણ કે કાર્ય ત્યારે જ એક્ઝિક્યુટ કરવામાં આવ્યું હતું જ્યારે સિસ્ટમે તેને એક્ઝેક્યુશન માટે પસંદ કર્યું હતું જ્યારે સમસ્યા એરિયામાં ટાસ્કને સ્વિચ કરતી વખતે. આ કાર્યમાં જે કંઈ થયું તે અન્ય, અસંબંધિત અવરોધિત કાર્યોને અસર કરશે નહીં.

એવી અપેક્ષા રાખવામાં આવી હતી કે જ્યારે સિસ્ટમ સમસ્યારૂપ કોડને એક્ઝિક્યુટ કરવાના તબક્કે પહોંચી જશે, ત્યારે દરેક આગામી એક્સપ્રેશન પર જતી વખતે વૈશ્વિક ચલ રીસેટ થશે. પછી કંઈક એવું થશે જે કાર્યને સ્વિચ કરવા માટેનું કારણ બને છે, અને તેની એક્ઝેક્યુશન ફ્રીક્વન્સી (10 Hz) મોનિટરિંગ ટાસ્ક કરતા ઓછી હોવાથી, મોનિટર વૈશ્વિક વેરીએબલની કિંમત મેળવી શકે છે અને તેને લખી શકે છે. સામાન્ય પરિસ્થિતિમાં, હું ગણતરીના સબસેટનો પુનરાવર્તિત ક્રમ મેળવી શકું છું: ટાસ્ક સ્વિચના સમયે ચલના છેલ્લા મૂલ્યો. જ્યારે લટકાવવામાં આવે ત્યારે, વૈશ્વિક ચલ હવે બદલાવું જોઈએ નહીં, અને લખાયેલ છેલ્લું મૂલ્ય સૂચવે છે કે કઈ અભિવ્યક્તિ પૂર્ણ થઈ નથી.

મેં ટ્રેકિંગ સાથે કોડ ચલાવ્યો. તે થીજી ગયો. અને મોનીટરીંગ ઘડિયાળની જેમ કામ કર્યું.

લોગમાં અપેક્ષિત ક્રમ છે, જે મ્યુટેક્સને બોલાવવામાં આવ્યો હોવાનું દર્શાવતા મૂલ્ય દ્વારા વિક્ષેપિત થયો હતો. Unlock, અને કાર્ય પૂર્ણ થયું નથી - જેમ કે અગાઉના હજારો કૉલ્સની બાબતમાં છે.

એપેક્સ એન્જિનિયરો આ સમયે તેમના કોડનું તાવપૂર્ણ રીતે વિશ્લેષણ કરી રહ્યા હતા અને તેમને મ્યુટેક્સમાં એક સ્થાન મળ્યું જ્યાં, સૈદ્ધાંતિક રીતે, લોક થઈ શકે. પરંતુ તેની સંભાવના ખૂબ જ ઓછી હતી, કારણ કે ચોક્કસ સમયે બનતી ઘટનાઓનો માત્ર ચોક્કસ ક્રમ જ અવરોધ તરફ દોરી શકે છે. મર્ફીનો કાયદો, મિત્રો, તે મર્ફીનો કાયદો છે.

મને જરૂરી કોડના ભાગને સુરક્ષિત કરવા માટે, મેં મ્યુટેક્સ ફંક્શન કૉલ્સ (OS મ્યુટેક્સ કાર્યક્ષમતાની ટોચ પર બનેલ) ને નાના મૂળ Ada mutex પેકેજ સાથે બદલ્યું છે જેથી તે ટુકડા પર મ્યુટેક્સ એક્સેસ નિયંત્રિત થાય.

મેં તેને કોડમાં દાખલ કર્યો અને ટેસ્ટ ચલાવ્યો. સાત કલાક પછી પણ કોડ કામ કરી રહ્યો હતો.

મારો કોડ રેશનલને સબમિટ કરવામાં આવ્યો હતો, જ્યાં તેઓએ તેનું સંકલન કર્યું, તેને ડિસએસેમ્બલ કર્યું અને તપાસ્યું કે તે સમસ્યારૂપ મ્યુટેક્સ કાર્યોમાં ઉપયોગમાં લેવાતા સમાન અભિગમનો ઉપયોગ કરતું નથી.

આ મારી કારકિર્દીની સૌથી ગીચ કોડ સમીક્ષા હતી 🙂 મારી સાથે રૂમમાં લગભગ દસ એન્જિનિયર અને મેનેજર હતા, અન્ય દસ લોકો કોન્ફરન્સ કૉલ પર હતા - અને તેઓ બધાએ કોડની લગભગ 20 લાઇનની તપાસ કરી.

કોડની સમીક્ષા કરવામાં આવી હતી, નવી એક્ઝિક્યુટેબલ ફાઇલો એસેમ્બલ કરવામાં આવી હતી અને ઔપચારિક રીગ્રેસન પરીક્ષણ માટે સબમિટ કરવામાં આવી હતી. થોડા અઠવાડિયા પછી, કાઉન્ટડાઉન પરીક્ષણ સફળ થયું અને રોકેટ ઉપડ્યું.

ઠીક છે, તે બધું સારું અને સારું છે, પરંતુ વાર્તાનો અર્થ શું છે?

તે એકદમ ઘૃણાસ્પદ સમસ્યા હતી. કોડની હજારો રેખાઓ, સમાંતર અમલ, એક ડઝનથી વધુ ક્રિયાપ્રતિક્રિયા પ્રક્રિયાઓ, નબળી આર્કિટેક્ચર અને નબળી અમલીકરણ, એમ્બેડેડ સિસ્ટમ્સ માટે ઇન્ટરફેસ અને લાખો ડોલર ખર્ચવામાં આવ્યા છે. કોઈ દબાણ નથી, બરાબર.

હું એકલો જ આ સમસ્યા પર કામ કરતો ન હતો, જોકે હું પોર્ટિંગ કરતી વખતે સ્પોટલાઇટમાં હતો. પરંતુ તેમ છતાં મેં તે કર્યું, તેનો અર્થ એ નથી કે હું કોડની તમામ સેંકડો હજારો લાઇનોને સમજી ગયો છું, અથવા તો તેને સ્કિમ કરી રહ્યો છું. કોડ અને લૉગ્સનું સમગ્ર દેશમાં ઇજનેરો દ્વારા વિશ્લેષણ કરવામાં આવ્યું હતું, પરંતુ જ્યારે તેઓએ મને નિષ્ફળતાના કારણો વિશે તેમની પૂર્વધારણાઓ જણાવી, ત્યારે તેમને રદિયો આપવામાં મને માત્ર અડધી મિનિટ લાગી. અને જ્યારે મને સિદ્ધાંતોનું પૃથ્થકરણ કરવાનું કહેવામાં આવ્યું, ત્યારે હું તેને બીજા કોઈને આપીશ, કારણ કે તે મારા માટે સ્પષ્ટ હતું કે આ એન્જિનિયરો ખોટા માર્ગે જઈ રહ્યા હતા. અહંકારી લાગે છે? હા, આ સાચું છે, પરંતુ મેં અન્ય કારણસર પૂર્વધારણાઓ અને વિનંતીઓને નકારી કાઢી.

હું સમસ્યાનું સ્વરૂપ સમજી ગયો. મને બરાબર ખબર ન હતી કે તે ક્યાં થઈ રહ્યું છે અથવા શા માટે, પરંતુ હું જાણતો હતો કે શું થઈ રહ્યું છે.

વર્ષોથી, મેં ઘણું જ્ઞાન અને અનુભવ મેળવ્યો છે. હું અડાનો ઉપયોગ કરવામાં અગ્રણીઓમાંનો એક હતો અને તેના ફાયદા અને ગેરફાયદાને સમજતો હતો. હું જાણું છું કે Ada રનટાઇમ લાઇબ્રેરી કેવી રીતે કાર્યોને હેન્ડલ કરે છે અને સમાંતર અમલ સાથે વ્યવહાર કરે છે. અને હું મેમરી, રજિસ્ટર અને એસેમ્બલરના સ્તરે લો-લેવલ પ્રોગ્રામિંગ સમજું છું. બીજા શબ્દોમાં કહીએ તો, મને મારા ક્ષેત્રમાં ઊંડું જ્ઞાન છે. અને મેં સમસ્યાનું કારણ શોધવા માટે તેનો ઉપયોગ કર્યો. મેં માત્ર બગની આસપાસ કામ કર્યું ન હતું, હું સમજી ગયો કે તેને અત્યંત સંવેદનશીલ રનટાઇમ વાતાવરણમાં કેવી રીતે શોધવું.

કોડ સાથેના સંઘર્ષની આવી વાર્તાઓ એવા લોકો માટે ખૂબ રસપ્રદ નથી જેઓ આવા સંઘર્ષની સુવિધાઓ અને શરતોથી પરિચિત નથી. પરંતુ આ વાર્તાઓ અમને તે સમજવામાં મદદ કરે છે કે તે ખરેખર મુશ્કેલ સમસ્યાઓ ઉકેલવા માટે શું લે છે.

ખરેખર મુશ્કેલ સમસ્યાઓ હલ કરવા માટે, તમારે ફક્ત પ્રોગ્રામર કરતાં વધુ બનવાની જરૂર છે. તમારે કોડના "ભાગ્ય"ને સમજવાની જરૂર છે, તે તેના પર્યાવરણ સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે અને પર્યાવરણ પોતે કેવી રીતે કાર્ય કરે છે.

અને પછી તમારી પાસે તમારી પોતાની બરબાદ રજા સપ્તાહ હશે.

ચાલુ રાખવા માટે.

સોર્સ: www.habr.com