പ്രോഗ്രാമർമാരുടെയും എഞ്ചിനീയർമാരുടെയും നാടോടിക്കഥകൾ (ഭാഗം 1)

ബഗുകൾക്ക് ചിലപ്പോൾ പൂർണ്ണമായും അവിശ്വസനീയമായ പ്രകടനങ്ങൾ എങ്ങനെ ഉണ്ടാകുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഇന്റർനെറ്റിൽ നിന്നുള്ള സ്റ്റോറികളുടെ ഒരു തിരഞ്ഞെടുപ്പാണിത്. ഒരുപക്ഷേ നിങ്ങൾക്കും എന്തെങ്കിലും പറയാനുണ്ട്.

വാനില ഐസ്ക്രീമിനോട് കാർ അലർജി

വ്യക്തമായത് എല്ലായ്‌പ്പോഴും ഉത്തരമല്ലെന്നും വസ്തുതകൾ എത്ര വിദൂരമാണെന്ന് തോന്നിയാലും അവ ഇപ്പോഴും വസ്തുതകളാണെന്നും മനസ്സിലാക്കുന്ന എഞ്ചിനീയർമാർക്കുള്ള ഒരു കഥ. ജനറൽ മോട്ടോഴ്‌സ് കോർപ്പറേഷന്റെ പോണ്ടിയാക് ഡിവിഷനിൽ ഒരു പരാതി ലഭിച്ചു:

ഇത് രണ്ടാം തവണയാണ് ഞാൻ നിങ്ങൾക്ക് എഴുതുന്നത്, ഉത്തരം നൽകാത്തതിന് ഞാൻ നിങ്ങളെ കുറ്റപ്പെടുത്തുന്നില്ല, കാരണം ഇത് ഭ്രാന്താണെന്ന് തോന്നുന്നു. എല്ലാ ദിവസവും രാത്രി അത്താഴത്തിന് ശേഷം ഐസ്ക്രീം കഴിക്കുന്ന ഒരു പാരമ്പര്യമുണ്ട് ഞങ്ങളുടെ കുടുംബത്തിന്. ഓരോ തവണയും ഐസ് ക്രീമിന്റെ തരങ്ങൾ മാറുന്നു, അത്താഴത്തിന് ശേഷം, ഏത് ഐസ്ക്രീം വാങ്ങണമെന്ന് മുഴുവൻ കുടുംബവും തിരഞ്ഞെടുക്കുന്നു, അതിനുശേഷം ഞാൻ കടയിലേക്ക് പോകുന്നു. ഞാൻ അടുത്തിടെ ഒരു പുതിയ പോണ്ടിയാക് വാങ്ങി, അതിനുശേഷം ഐസ്ക്രീം വാങ്ങാനുള്ള എന്റെ യാത്രകൾ ഒരു പ്രശ്നമായി മാറി. ഞാൻ വാനില ഐസ്ക്രീം വാങ്ങി കടയിൽ നിന്ന് വരുമ്പോഴെല്ലാം കാർ സ്റ്റാർട്ട് ആകുന്നില്ല. വേറെ എന്തെങ്കിലും ഐസ്ക്രീം കൊണ്ടുവന്നാൽ ഒരു കുഴപ്പവുമില്ലാതെ വണ്ടി സ്റ്റാർട്ട് ചെയ്യുന്നു. അത് എത്ര മണ്ടത്തരമാണെന്ന് തോന്നിയാലും എനിക്ക് ഗൗരവമായ ഒരു ചോദ്യം ചോദിക്കാൻ ആഗ്രഹമുണ്ട്: “ഞാൻ വാനില ഐസ്ക്രീം കൊണ്ടുവരുമ്പോൾ അത് ആരംഭിക്കാതിരിക്കുകയും മറ്റൊരു ഐസ്ക്രീമിന്റെ രുചി കൊണ്ടുവരുമ്പോൾ അത് എളുപ്പത്തിൽ ആരംഭിക്കുകയും ചെയ്യുന്ന പോണ്ടിയാക് എന്താണ്?” "

നിങ്ങൾക്ക് ഊഹിക്കാവുന്നതുപോലെ, ഡിവിഷൻ പ്രസിഡന്റിന് കത്തിൽ സംശയമുണ്ടായിരുന്നു. എന്നിരുന്നാലും, ഞാൻ പരിശോധിക്കാൻ ഒരു എഞ്ചിനീയറെ അയച്ചു. മനോഹരമായ ഒരു പ്രദേശത്ത് താമസിക്കുന്ന ഒരു ധനികനും വിദ്യാസമ്പന്നനുമായ ഒരു മനുഷ്യൻ തന്നെ കണ്ടുമുട്ടിയതിൽ അവൻ ആശ്ചര്യപ്പെട്ടു. അത്താഴം കഴിഞ്ഞ് ഉടൻ തന്നെ കാണാമെന്ന് അവർ സമ്മതിച്ചു, അങ്ങനെ രണ്ടുപേർക്കും ഐസ്ക്രീമിനായി കടയിലേക്ക് പോകാം. അന്ന് വൈകുന്നേരം വാനില ആയിരുന്നു, അവർ തിരികെ കാറിൽ എത്തിയപ്പോൾ അത് സ്റ്റാർട്ട് ആയില്ല.

മൂന്ന് വൈകുന്നേരം കൂടി എഞ്ചിനീയർ വന്നു. ആദ്യമായി ഐസ് ക്രീം ചോക്ലേറ്റ് ആയിരുന്നു. കാർ സ്റ്റാർട്ട് ചെയ്തു. രണ്ടാം തവണ സ്ട്രോബെറി ഐസ്ക്രീം ഉണ്ടായിരുന്നു. കാർ സ്റ്റാർട്ട് ചെയ്തു. മൂന്നാം ദിവസം വൈകുന്നേരം അവൻ വാനില എടുക്കാൻ ആവശ്യപ്പെട്ടു. കാർ സ്റ്റാർട്ട് ആയില്ല.

യുക്തിസഹമായി ന്യായവാദം ചെയ്തു, കാറിന് വാനില ഐസ്ക്രീമിനോട് അലർജിയുണ്ടെന്ന് വിശ്വസിക്കാൻ എഞ്ചിനീയർ വിസമ്മതിച്ചു. അതിനാൽ, പ്രശ്നത്തിന് പരിഹാരം കണ്ടെത്തുന്നത് വരെ കാറിന്റെ ഉടമയുടെ സന്ദർശനം തുടരുമെന്ന് ഞാൻ സമ്മതിച്ചു. വഴിയിൽ, അവൻ കുറിപ്പുകൾ എടുക്കാൻ തുടങ്ങി: എല്ലാ വിവരങ്ങളും, ദിവസത്തിന്റെ സമയം, ഗ്യാസോലിൻ തരം, കടയിൽ നിന്ന് എത്തിച്ചേരുകയും മടങ്ങുകയും ചെയ്യുന്ന സമയം മുതലായവ അദ്ദേഹം എഴുതി.

കാറിന്റെ ഉടമ വാനില ഐസ്‌ക്രീം വാങ്ങാൻ കുറച്ച് സമയം ചെലവഴിച്ചുവെന്ന് എഞ്ചിനീയർക്ക് പെട്ടെന്ന് മനസ്സിലായി. കടയിലെ സാധനങ്ങളുടെ ലേഔട്ട് ആയിരുന്നു കാരണം. വാനില ഐസ്ക്രീം ഏറ്റവും ജനപ്രിയമായിരുന്നു, അത് കണ്ടെത്തുന്നത് എളുപ്പമാക്കുന്നതിന് സ്റ്റോറിന്റെ മുൻവശത്ത് പ്രത്യേക ഫ്രീസറിൽ സൂക്ഷിച്ചു. മറ്റെല്ലാ ഇനങ്ങളും സ്റ്റോറിന്റെ പിൻഭാഗത്തായിരുന്നു, ശരിയായ ഇനം കണ്ടെത്തി പണം നൽകുന്നതിന് കൂടുതൽ സമയമെടുത്തു.

ഇപ്പോൾ ചോദ്യം എഞ്ചിനീയർക്കുള്ളതായിരുന്നു: എഞ്ചിൻ ഓഫാക്കിയ നിമിഷം മുതൽ കുറച്ച് സമയം കടന്നുപോയെങ്കിൽ എന്തുകൊണ്ടാണ് കാർ സ്റ്റാർട്ട് ചെയ്യാത്തത്? വാനില ഐസ്ക്രീം അല്ല സമയമായതിനാൽ, എഞ്ചിനീയർ പെട്ടെന്ന് ഉത്തരം കണ്ടെത്തി: അതൊരു ഗ്യാസ് ലോക്കായിരുന്നു. എല്ലാ വൈകുന്നേരവും ഇത് സംഭവിച്ചു, എന്നാൽ കാർ ഉടമ ഐസ്ക്രീം തിരയാൻ കൂടുതൽ സമയം ചെലവഴിച്ചപ്പോൾ, എഞ്ചിൻ വേണ്ടത്ര തണുക്കുകയും എളുപ്പത്തിൽ ആരംഭിക്കുകയും ചെയ്തു. ആ മനുഷ്യൻ വാനില ഐസ്ക്രീം വാങ്ങുമ്പോൾ, എഞ്ചിൻ ഇപ്പോഴും വളരെ ചൂടായിരുന്നു, ഗ്യാസ് ലോക്ക് പിരിച്ചുവിടാൻ സമയമില്ല.

ധാർമികത: തികച്ചും ഭ്രാന്തമായ പ്രശ്നങ്ങൾ പോലും ചിലപ്പോൾ യഥാർത്ഥമാണ്.

ക്രാഷ് Bandicoot

ഇത് അനുഭവിക്കുന്നത് വേദനാജനകമാണ്. ഒരു പ്രോഗ്രാമർ എന്ന നിലയിൽ, നിങ്ങളുടെ കോഡിനെ ആദ്യം, രണ്ടാമത്തേത്, മൂന്നാമത്തേത്... കൂടാതെ പതിനായിരത്തിൽ എവിടെയെങ്കിലും നിങ്ങൾ കംപൈലറെ കുറ്റപ്പെടുത്തുന്നത് പതിവാണ്. പട്ടികയിൽ നിന്ന് താഴെ നിങ്ങൾ ഇതിനകം ഉപകരണങ്ങളെ കുറ്റപ്പെടുത്തുന്നു.

ഹാർഡ്‌വെയർ ബഗിനെക്കുറിച്ചുള്ള എന്റെ കഥ ഇതാ.

ക്രാഷ് ബാൻഡികൂട്ട് ഗെയിമിനായി, ഒരു മെമ്മറി കാർഡിലേക്ക് ലോഡ് ചെയ്യാനും സംരക്ഷിക്കാനും ഞാൻ കോഡ് എഴുതി. അത്തരമൊരു സ്മഗ് ഗെയിം ഡെവലപ്പർക്ക്, ഇത് പാർക്കിലെ ഒരു നടത്തം പോലെയായിരുന്നു: ജോലിക്ക് കുറച്ച് ദിവസമെടുക്കുമെന്ന് ഞാൻ കരുതി. എന്നിരുന്നാലും, ഞാൻ ആറാഴ്ചത്തേക്ക് കോഡ് ഡീബഗ്ഗിംഗ് അവസാനിപ്പിച്ചു. വഴിയിൽ, ഞാൻ മറ്റ് പ്രശ്നങ്ങൾ പരിഹരിച്ചു, എന്നാൽ ഓരോ കുറച്ച് ദിവസങ്ങളിലും ഞാൻ കുറച്ച് മണിക്കൂറുകളോളം ഈ കോഡിലേക്ക് മടങ്ങി. അത് വേദനാജനകമായിരുന്നു.

ലക്ഷണം ഇതുപോലെ കാണപ്പെട്ടു: നിങ്ങൾ ഗെയിമിന്റെ നിലവിലെ പ്ലേത്രൂ സംരക്ഷിച്ച് മെമ്മറി കാർഡ് ആക്‌സസ് ചെയ്യുമ്പോൾ, എല്ലാം മിക്കവാറും എല്ലായ്‌പ്പോഴും ശരിയാകും... എന്നാൽ ചില സമയങ്ങളിൽ വ്യക്തമായ കാരണമൊന്നുമില്ലാതെ റീഡ് അല്ലെങ്കിൽ റൈറ്റ് ഓപ്പറേഷൻ ടൈംഔട്ടാകും. ഒരു ചെറിയ റെക്കോർഡിംഗ് പലപ്പോഴും മെമ്മറി കാർഡിനെ നശിപ്പിക്കുന്നു. ഒരു കളിക്കാരൻ രക്ഷിക്കാൻ ശ്രമിക്കുമ്പോൾ, അവൻ സംരക്ഷിക്കുന്നതിൽ പരാജയപ്പെടുക മാത്രമല്ല, മാപ്പ് നശിപ്പിക്കുകയും ചെയ്യുന്നു. വിഡ്ഢിത്തം.

കുറച്ച് സമയത്തിന് ശേഷം, സോണിയിലെ ഞങ്ങളുടെ പ്രൊഡ്യൂസറായ കോണി ബസ് പരിഭ്രാന്തരാകാൻ തുടങ്ങി. ഈ ബഗ് ഉപയോഗിച്ച് ഞങ്ങൾക്ക് ഗെയിം അയയ്‌ക്കാനായില്ല, ആറ് ആഴ്‌ചയ്‌ക്ക് ശേഷം എന്താണ് പ്രശ്‌നമുണ്ടാക്കുന്നതെന്ന് എനിക്ക് മനസ്സിലായില്ല. കോണി വഴി, ഞങ്ങൾ മറ്റ് PS1 ഡവലപ്പർമാരെ ബന്ധപ്പെട്ടു: ആരെങ്കിലും സമാനമായ എന്തെങ്കിലും നേരിട്ടിട്ടുണ്ടോ? ഇല്ല. മെമ്മറി കാർഡിൽ ആർക്കും പ്രശ്‌നങ്ങളുണ്ടായില്ല.

നിങ്ങൾക്ക് ഡീബഗ്ഗിംഗിന് ആശയങ്ങളൊന്നും ഇല്ലെങ്കിൽ, "വിഭജിച്ച് കീഴടക്കുക" എന്ന സമീപനം മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ: പ്രശ്‌നമുണ്ടാക്കുന്ന താരതമ്യേന ചെറിയ ശകലം അവശേഷിക്കുന്നത് വരെ തെറ്റായ പ്രോഗ്രാമിൽ നിന്ന് കൂടുതൽ കൂടുതൽ കോഡ് നീക്കംചെയ്യുക. അതായത്, ബഗ് അടങ്ങിയിരിക്കുന്ന ഭാഗം നിലനിൽക്കുന്നതുവരെ നിങ്ങൾ പ്രോഗ്രാം കഷണം കട്ട് ചെയ്യുക.

പക്ഷേ, ഒരു വീഡിയോ ഗെയിമിൽ നിന്ന് കഷണങ്ങൾ മുറിക്കുക എന്നത് വളരെ ബുദ്ധിമുട്ടാണ് എന്നതാണ് കാര്യം. ഗുരുത്വാകർഷണത്തെ അനുകരിക്കുന്ന കോഡ് നിങ്ങൾ നീക്കം ചെയ്താൽ അത് എങ്ങനെ പ്രവർത്തിപ്പിക്കാം? അതോ പ്രതീകങ്ങൾ വരയ്ക്കുകയാണോ?

അതിനാൽ, മൊഡ്യൂളുകൾ മുഴുവൻ ഉപയോഗപ്രദമായ എന്തെങ്കിലും ചെയ്യുന്നതായി നടിക്കുന്ന സ്റ്റബുകൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കേണ്ടതുണ്ട്, എന്നാൽ വാസ്തവത്തിൽ പിശകുകൾ ഉൾക്കൊള്ളാൻ കഴിയാത്ത വളരെ ലളിതമായ എന്തെങ്കിലും ചെയ്യുക. കളിയ്ക്കെങ്കിലും പ്രവർത്തിക്കണമെങ്കിൽ അത്തരം ഊന്നുവടികൾ എഴുതണം. ഇത് മന്ദഗതിയിലുള്ളതും വേദനാജനകവുമായ പ്രക്രിയയാണ്.

ചുരുക്കത്തിൽ, ഞാൻ അത് ചെയ്തു. ഗെയിം പ്രവർത്തിപ്പിക്കുന്നതിന് സിസ്റ്റം കോൺഫിഗർ ചെയ്യുന്നതും റെൻഡറിംഗ് ഹാർഡ്‌വെയർ ആരംഭിക്കുന്നതും മറ്റും തുടങ്ങിയ പ്രാരംഭ കോഡ് ബാക്കിയാകുന്നതുവരെ ഞാൻ കൂടുതൽ കൂടുതൽ കോഡ് കഷണങ്ങൾ നീക്കം ചെയ്തു. തീർച്ചയായും, ഈ ഘട്ടത്തിൽ എനിക്ക് ഒരു സേവ് ആൻഡ് ലോഡ് മെനു സൃഷ്‌ടിക്കാൻ കഴിഞ്ഞില്ല, കാരണം എല്ലാ ഗ്രാഫിക്‌സ് കോഡിനും വേണ്ടി ഞാൻ ഒരു അപൂർണ്ണത സൃഷ്ടിക്കേണ്ടതുണ്ട്. എന്നാൽ എനിക്ക് (അദൃശ്യമായ) സേവ് ആൻഡ് ലോഡ് സ്‌ക്രീൻ ഉപയോഗിച്ച് ഒരു ഉപയോക്താവായി നടിക്കുകയും മെമ്മറി കാർഡിലേക്ക് സേവ് ചെയ്യാൻ ആവശ്യപ്പെടുകയും തുടർന്ന് എഴുതുകയും ചെയ്യാം.

മേൽപ്പറഞ്ഞ പ്രശ്‌നമുള്ള ഒരു ചെറിയ കോഡ് ഇത് എനിക്ക് നൽകി - പക്ഷേ അത് ഇപ്പോഴും ക്രമരഹിതമായി സംഭവിക്കുകയായിരുന്നു! മിക്കപ്പോഴും എല്ലാം ശരിയായി പ്രവർത്തിച്ചു, പക്ഷേ ഇടയ്ക്കിടെ തകരാറുകൾ ഉണ്ടായിരുന്നു. ഞാൻ മിക്കവാറും എല്ലാ ഗെയിം കോഡും നീക്കംചെയ്‌തു, പക്ഷേ ബഗ് ഇപ്പോഴും ജീവിച്ചിരിപ്പുണ്ടായിരുന്നു. ഇത് അമ്പരപ്പിക്കുന്നതായിരുന്നു: ശേഷിക്കുന്ന കോഡ് യഥാർത്ഥത്തിൽ ഒന്നും ചെയ്തില്ല.

ചില സമയങ്ങളിൽ, മിക്കവാറും പുലർച്ചെ മൂന്ന് മണിയോടെ, ഒരു ചിന്ത എന്നിൽ ഉദിച്ചു. വായനയും എഴുത്തും (ഇൻപുട്ട്/ഔട്ട്പുട്ട്) പ്രവർത്തനങ്ങളിൽ കൃത്യമായ നിർവ്വഹണ സമയം ഉൾപ്പെടുന്നു. നിങ്ങൾ ഒരു ഹാർഡ് ഡ്രൈവ്, മെമ്മറി കാർഡ് അല്ലെങ്കിൽ ബ്ലൂടൂത്ത് മൊഡ്യൂൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുമ്പോൾ, വായനയ്ക്കും എഴുത്തിനും ഉത്തരവാദിത്തമുള്ള ലോ-ലെവൽ കോഡ് ക്ലോക്ക് പൾസുകൾക്ക് അനുസൃതമായി പ്രവർത്തിക്കുന്നു.

ഒരു ക്ലോക്കിന്റെ സഹായത്തോടെ, പ്രോസസറുമായി നേരിട്ട് ബന്ധിപ്പിച്ചിട്ടില്ലാത്ത ഒരു ഉപകരണം പ്രോസസറിൽ എക്സിക്യൂട്ട് ചെയ്യുന്ന കോഡുമായി സമന്വയിപ്പിക്കുന്നു. ക്ലോക്ക് ബോഡ് നിരക്ക് നിർണ്ണയിക്കുന്നു - ഡാറ്റ കൈമാറ്റം ചെയ്യപ്പെടുന്ന വേഗത. സമയവുമായി ബന്ധപ്പെട്ട് ആശയക്കുഴപ്പമുണ്ടെങ്കിൽ, ഹാർഡ്‌വെയറോ സോഫ്റ്റ്‌വെയറോ അല്ലെങ്കിൽ രണ്ടും കൂടി ആശയക്കുഴപ്പത്തിലാകും. ഇത് വളരെ മോശമാണ്, കാരണം ഡാറ്റ കേടായേക്കാം.

നമ്മുടെ കോഡിലെ എന്തെങ്കിലും സമയത്തെ ആശയക്കുഴപ്പത്തിലാക്കിയാലോ? ടെസ്റ്റ് പ്രോഗ്രാം കോഡിൽ ഇതുമായി ബന്ധപ്പെട്ട എല്ലാ കാര്യങ്ങളും ഞാൻ പരിശോധിച്ചു, ഞങ്ങൾ പ്രോഗ്രാമബിൾ ടൈമർ PS1 മുതൽ 1 kHz (സെക്കൻഡിൽ 1000 ടിക്കുകൾ) വരെ സജ്ജമാക്കുന്നത് ശ്രദ്ധിച്ചു. ഇത് വളരെ കൂടുതലാണ്; സ്ഥിരസ്ഥിതിയായി, കൺസോൾ ആരംഭിക്കുമ്പോൾ, അത് 100 Hz-ൽ പ്രവർത്തിക്കുന്നു. മിക്ക ഗെയിമുകളും ഈ ആവൃത്തി ഉപയോഗിക്കുന്നു.

ഗെയിം ഡെവലപ്പറായ ആൻഡി, ടൈമർ 1 kHz ആയി സജ്ജമാക്കുക, അങ്ങനെ ചലനങ്ങൾ കൂടുതൽ കൃത്യമായി കണക്കാക്കും. ആൻഡി അതിരുകടക്കാൻ പ്രവണത കാണിക്കുന്നു, ഞങ്ങൾ ഗുരുത്വാകർഷണത്തെ അനുകരിക്കുകയാണെങ്കിൽ, കഴിയുന്നത്ര കൃത്യമായി ഞങ്ങൾ അത് ചെയ്യുന്നു!

എന്നാൽ ടൈമർ വേഗത്തിലാക്കുന്നത് പ്രോഗ്രാമിന്റെ മൊത്തത്തിലുള്ള സമയത്തെ എങ്ങനെയെങ്കിലും ബാധിച്ചാലോ, അതിനാൽ മെമ്മറി കാർഡിന്റെ ബോഡ് നിരക്ക് നിയന്ത്രിക്കുന്ന ക്ലോക്കിനെയാണോ?

ഞാൻ ടൈമർ കോഡ് കമന്റ് ചെയ്തു. തെറ്റ് വീണ്ടും സംഭവിച്ചില്ല. എന്നാൽ ഞങ്ങൾ ഇത് പരിഹരിച്ചുവെന്ന് ഇതിനർത്ഥമില്ല, കാരണം പരാജയം ക്രമരഹിതമായി സംഭവിച്ചു. ഞാൻ ഭാഗ്യവാനായിരുന്നെങ്കിലോ?

കുറച്ച് ദിവസങ്ങൾക്ക് ശേഷം ഞാൻ ടെസ്റ്റ് പ്രോഗ്രാം ഉപയോഗിച്ച് വീണ്ടും പരീക്ഷിച്ചു. ബഗ് ആവർത്തിച്ചില്ല. ഞാൻ പൂർണ്ണ ഗെയിം കോഡ്‌ബേസിലേക്ക് തിരികെ പോയി സേവ്, ലോഡ് കോഡ് പരിഷ്‌ക്കരിച്ചു, അങ്ങനെ പ്രോഗ്രാമബിൾ ടൈമർ മെമ്മറി കാർഡ് ആക്‌സസ് ചെയ്യുന്നതിന് മുമ്പ് അതിന്റെ യഥാർത്ഥ മൂല്യത്തിലേക്ക് (100Hz) പുനഃസജ്ജമാക്കും, തുടർന്ന് 1kHz-ലേക്ക് പുനഃസജ്ജമാക്കും. കൂടുതൽ തകരാർ ഉണ്ടായില്ല.

എന്നാൽ എന്തുകൊണ്ടാണ് ഇത് സംഭവിച്ചത്?

ഞാൻ വീണ്ടും ടെസ്റ്റ് പ്രോഗ്രാമിലേക്ക് മടങ്ങി. 1 kHz ടൈമർ ഉപയോഗിച്ച് ഒരു പിശക് സംഭവിക്കുന്നതിൽ ചില പാറ്റേൺ കണ്ടെത്താൻ ഞാൻ ശ്രമിച്ചു. ആരെങ്കിലും ഒരു PS1 കൺട്രോളറുമായി കളിക്കുമ്പോൾ പിശക് സംഭവിക്കുന്നത് ഒടുവിൽ ഞാൻ ശ്രദ്ധിച്ചു. ഞാൻ ഇത് വളരെ അപൂർവമായേ ചെയ്യാറുള്ളൂ എന്നതിനാൽ - സേവ് ആൻഡ് ലോഡ് കോഡ് പരിശോധിക്കുമ്പോൾ എനിക്ക് ഒരു കൺട്രോളർ ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ട്? - ഈ ആശ്രിതത്വം ഞാൻ ശ്രദ്ധിച്ചില്ല. എന്നാൽ ഒരു ദിവസം ഞങ്ങളുടെ ഒരു ആർട്ടിസ്‌റ്റ് ഞാൻ ടെസ്റ്റിംഗ് പൂർത്തിയാക്കുന്നത് കാത്ത് നിൽക്കുന്നുണ്ടായിരുന്നു - ആ നിമിഷം ഞാൻ ശപിച്ചിരിക്കാം - പരിഭ്രാന്തിയോടെ അവന്റെ കൈകളിലെ കൺട്രോളർ ചുഴറ്റി. ഒരു പിശക് സംഭവിച്ചു. "എന്തിനെ കാക്കണം?!" ശരി, ഇത് വീണ്ടും ചെയ്യുക! ”

ഈ രണ്ട് സംഭവങ്ങളും പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് ഞാൻ മനസ്സിലാക്കിയപ്പോൾ, പിശക് എളുപ്പത്തിൽ പുനർനിർമ്മിക്കാൻ എനിക്ക് കഴിഞ്ഞു: ഞാൻ മെമ്മറി കാർഡിലേക്ക് റെക്കോർഡിംഗ് ആരംഭിച്ചു, കൺട്രോളർ നീക്കി, മെമ്മറി കാർഡ് നശിപ്പിച്ചു. എനിക്ക് ഇതൊരു ഹാർഡ്‌വെയർ ബഗ് പോലെ തോന്നി.

ഞാൻ കോന്നിയിൽ വന്ന് എന്റെ കണ്ടുപിടുത്തത്തെക്കുറിച്ച് അവളോട് പറഞ്ഞു. PS1 രൂപകല്പന ചെയ്ത എഞ്ചിനീയർമാരിൽ ഒരാളോട് അവൾ വിവരങ്ങൾ കൈമാറി. “അസാധ്യം,” അദ്ദേഹം മറുപടി പറഞ്ഞു, “ഇതൊരു ഹാർഡ്‌വെയർ പ്രശ്‌നമാകില്ല.” ഞങ്ങൾക്കായി ഒരു സംഭാഷണം ക്രമീകരിക്കാൻ ഞാൻ കോണിയോട് ആവശ്യപ്പെട്ടു.

എഞ്ചിനീയർ എന്നെ വിളിച്ചു, ഞങ്ങൾ അവന്റെ തകർന്ന ഇംഗ്ലീഷിലും എന്റെ (അങ്ങേയറ്റം) തകർന്ന ജാപ്പനീസിലും വാദിച്ചു. അവസാനം ഞാൻ പറഞ്ഞു, “കൺട്രോളർ ചലിപ്പിക്കുന്നത് ഒരു ബഗിന് കാരണമാകുന്ന എന്റെ 30 ലൈൻ ടെസ്റ്റ് പ്രോഗ്രാം അയയ്‌ക്കട്ടെ.” അവൻ സമ്മതിച്ചു. ഇത് സമയം പാഴാക്കുന്നതാണെന്നും ഒരു പുതിയ പ്രോജക്റ്റിന്റെ ജോലിയിൽ താൻ ഭയങ്കര തിരക്കിലാണെന്നും എന്നാൽ ഞങ്ങൾ സോണിയുടെ വളരെ പ്രധാനപ്പെട്ട ഡെവലപ്പർ ആയതിനാൽ വഴങ്ങുമെന്നും പറഞ്ഞു. ഞാൻ എന്റെ ടെസ്റ്റ് പ്രോഗ്രാം വൃത്തിയാക്കി അവന് അയച്ചു.

അടുത്ത ദിവസം വൈകുന്നേരം (ഞങ്ങൾ ലോസ് ഏഞ്ചൽസിലായിരുന്നു, അദ്ദേഹം ടോക്കിയോയിലായിരുന്നു) അദ്ദേഹം എന്നെ വിളിച്ച് ആട്ടിൻകൂട്ടത്തോടെ ക്ഷമാപണം നടത്തി. അതൊരു ഹാർഡ്‌വെയർ പ്രശ്നമായിരുന്നു.

ബഗ് എന്താണെന്ന് കൃത്യമായി എനിക്കറിയില്ല, എന്നാൽ സോണി ആസ്ഥാനത്ത് നിന്ന് ഞാൻ കേട്ടതിൽ നിന്ന്, നിങ്ങൾ ടൈമർ മതിയായ മൂല്യത്തിലേക്ക് സജ്ജമാക്കിയാൽ, അത് ടൈമർ ക്രിസ്റ്റലിന് സമീപമുള്ള മദർബോർഡിലെ ഘടകങ്ങളെ തടസ്സപ്പെടുത്തുന്നു. അവയിലൊന്ന് മെമ്മറി കാർഡിനുള്ള ഒരു ബോഡ് റേറ്റ് കൺട്രോളറായിരുന്നു, അത് കൺട്രോളറുകൾക്കുള്ള ബോഡ് നിരക്കും സജ്ജമാക്കി. ഞാൻ ഒരു എഞ്ചിനീയർ അല്ല, അതിനാൽ ഞാൻ എന്തെങ്കിലും കുഴപ്പമുണ്ടാക്കിയിരിക്കാം.

എന്നാൽ മദർബോർഡിലെ ഘടകങ്ങൾ തമ്മിൽ ഇടപെടൽ ഉണ്ടായി എന്നതാണ് ഏറ്റവും പ്രധാനം. കൺട്രോളർ പോർട്ടിലൂടെയും മെമ്മറി കാർഡ് പോർട്ടിലൂടെയും 1 kHz-ൽ പ്രവർത്തിക്കുന്ന ടൈമർ ഉപയോഗിച്ച് ഒരേസമയം ഡാറ്റ കൈമാറുമ്പോൾ, ബിറ്റുകൾ നഷ്‌ടപ്പെട്ടു, ഡാറ്റ നഷ്‌ടപ്പെട്ടു, കാർഡ് കേടായി.

ചീത്ത പശുക്കൾ

1980-കളിൽ, PDP-1800-ന്റെ സോവിയറ്റ് ക്ലോണായ SM-11-ന് വേണ്ടി എന്റെ ഉപദേഷ്ടാവ് സെർജി സോഫ്റ്റ്‌വെയർ എഴുതി. സോവിയറ്റ് യൂണിയനിലെ ഒരു പ്രധാന ഗതാഗത കേന്ദ്രമായ സ്വെർഡ്ലോവ്സ്കിനടുത്തുള്ള ഒരു റെയിൽവേ സ്റ്റേഷനിൽ ഈ മൈക്രോകമ്പ്യൂട്ടർ ഇപ്പോൾ ഇൻസ്റ്റാൾ ചെയ്തു. വാഗണുകളും ചരക്ക് ഗതാഗതവും റൂട്ട് ചെയ്യുന്നതിനാണ് പുതിയ സംവിധാനം രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. എന്നാൽ അതിൽ ക്രമരഹിതമായ ക്രാഷുകളിലേക്കും ക്രാഷുകളിലേക്കും നയിച്ച ഒരു ശല്യപ്പെടുത്തുന്ന ബഗ് അടങ്ങിയിരിക്കുന്നു. വൈകുന്നേരങ്ങളിൽ ആരെങ്കിലും വീട്ടിലേക്ക് പോകുമ്പോൾ എല്ലായ്പ്പോഴും വീഴ്ചകൾ സംഭവിച്ചു. എന്നാൽ അടുത്ത ദിവസം സമഗ്രമായ അന്വേഷണം നടത്തിയിട്ടും, എല്ലാ മാനുവൽ, ഓട്ടോമാറ്റിക് ടെസ്റ്റുകളിലും കമ്പ്യൂട്ടർ ശരിയായി പ്രവർത്തിച്ചു. ഇത് സാധാരണയായി ഒരു റേസ് അവസ്ഥയെയോ ചില വ്യവസ്ഥകളിൽ സംഭവിക്കുന്ന മറ്റേതെങ്കിലും മത്സര ബഗിനെയോ സൂചിപ്പിക്കുന്നു. രാത്രി വൈകിയുള്ള കോളുകളിൽ മടുത്ത സെർജി അതിന്റെ അടിത്തട്ടിലെത്താൻ തീരുമാനിച്ചു, ഒന്നാമതായി, മാർഷലിംഗ് യാർഡിലെ സാഹചര്യങ്ങൾ കമ്പ്യൂട്ടർ തകരാറിലേക്ക് നയിച്ചത് എന്താണെന്ന് മനസ്സിലാക്കുക.

ആദ്യം, അദ്ദേഹം വിശദീകരിക്കാത്ത എല്ലാ വീഴ്ചകളുടെയും സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുകയും തീയതിയും സമയവും അനുസരിച്ച് ഒരു ഗ്രാഫ് സൃഷ്ടിക്കുകയും ചെയ്തു. പാറ്റേൺ വ്യക്തമായിരുന്നു. കുറച്ച് ദിവസങ്ങൾ കൂടി നിരീക്ഷിച്ച ശേഷം, ഭാവിയിലെ സിസ്റ്റം പരാജയങ്ങളുടെ സമയം തനിക്ക് എളുപ്പത്തിൽ പ്രവചിക്കാൻ കഴിയുമെന്ന് സെർജി മനസ്സിലാക്കി.

വടക്കൻ ഉക്രെയിനിൽ നിന്നും പടിഞ്ഞാറൻ റഷ്യയിൽ നിന്നും ട്രെയിൻ ലോഡ് കന്നുകാലികളെ സ്റ്റേഷൻ തരംതിരിക്കുമ്പോൾ മാത്രമാണ് തടസ്സങ്ങൾ സംഭവിച്ചതെന്ന് അദ്ദേഹം ഉടൻ മനസ്സിലാക്കി, അടുത്തുള്ള അറവുശാലയിലേക്ക്. ഇത് തന്നെ വിചിത്രമായിരുന്നു, കാരണം കസാക്കിസ്ഥാനിൽ വളരെ അടുത്ത് സ്ഥിതി ചെയ്യുന്ന ഫാമുകളാണ് അറവുശാല വിതരണം ചെയ്തത്.

1986-ൽ ചെർണോബിൽ ആണവ നിലയം പൊട്ടിത്തെറിച്ചു, റേഡിയോ ആക്ടീവ് പതനം ചുറ്റുമുള്ള പ്രദേശങ്ങളെ വാസയോഗ്യമല്ലാതാക്കി. വടക്കൻ ഉക്രെയ്ൻ, ബെലാറസ്, പടിഞ്ഞാറൻ റഷ്യ എന്നിവിടങ്ങളിലെ വിശാലമായ പ്രദേശങ്ങൾ മലിനമായി. വരുന്ന വണ്ടികളിൽ ഉയർന്ന തോതിലുള്ള റേഡിയേഷൻ ഉണ്ടെന്ന് സംശയിച്ച സെർജി ഈ സിദ്ധാന്തം പരിശോധിക്കുന്നതിനുള്ള ഒരു രീതി വികസിപ്പിച്ചെടുത്തു. ജനസംഖ്യയിൽ ഡോസിമീറ്ററുകൾ ഉണ്ടായിരിക്കുന്നത് നിരോധിച്ചിരിക്കുന്നു, അതിനാൽ സെർജി റെയിൽവേ സ്റ്റേഷനിൽ നിരവധി സൈനികരുമായി സ്വയം രജിസ്റ്റർ ചെയ്തു. നിരവധി വോഡ്ക പാനീയങ്ങൾക്ക് ശേഷം, സംശയാസ്പദമായ വണ്ടികളിലൊന്നിലെ റേഡിയേഷൻ അളവ് അളക്കാൻ ഒരു സൈനികനെ ബോധ്യപ്പെടുത്താൻ അദ്ദേഹത്തിന് കഴിഞ്ഞു. ലെവൽ സാധാരണ മൂല്യങ്ങളേക്കാൾ നിരവധി മടങ്ങ് കൂടുതലാണെന്ന് ഇത് മാറി.

കന്നുകാലികൾ വളരെയധികം വികിരണം പുറപ്പെടുവിക്കുക മാത്രമല്ല, അതിന്റെ അളവ് വളരെ ഉയർന്നതാണ്, അത് സ്റ്റേഷന് അടുത്തുള്ള ഒരു കെട്ടിടത്തിൽ സ്ഥിതി ചെയ്യുന്ന SM-1800 ന്റെ മെമ്മറിയിൽ ക്രമരഹിതമായ ബിറ്റുകൾ നഷ്ടപ്പെടാൻ ഇടയാക്കി.

സോവിയറ്റ് യൂണിയനിൽ ഭക്ഷ്യക്ഷാമം ഉണ്ടായിരുന്നു, രാജ്യത്തിന്റെ മറ്റ് പ്രദേശങ്ങളിൽ നിന്നുള്ള മാംസവുമായി ചെർണോബിൽ മാംസം കലർത്താൻ അധികാരികൾ തീരുമാനിച്ചു. മൂല്യവത്തായ വിഭവങ്ങൾ നഷ്ടപ്പെടാതെ റേഡിയോ ആക്റ്റിവിറ്റിയുടെ മൊത്തത്തിലുള്ള അളവ് കുറയ്ക്കാൻ ഇത് സാധ്യമാക്കി. ഇതിനെക്കുറിച്ച് അറിഞ്ഞ സെർജി ഉടൻ തന്നെ എമിഗ്രേഷനുള്ള രേഖകൾ പൂരിപ്പിച്ചു. കാലക്രമേണ റേഡിയേഷന്റെ അളവ് കുറഞ്ഞപ്പോൾ കമ്പ്യൂട്ടർ തകരാറുകൾ സ്വയം നിലച്ചു.

പൈപ്പുകൾ വഴി

ഒരു കാലത്ത്, മൂവിടെക് സൊല്യൂഷൻസ് സിനിമാശാലകൾക്കായി സോഫ്റ്റ്വെയർ സൃഷ്ടിച്ചു, അക്കൗണ്ടിംഗ്, ടിക്കറ്റ് വിൽപ്പന, ജനറൽ മാനേജ്മെന്റ് എന്നിവയ്ക്കായി രൂപകൽപ്പന ചെയ്തിട്ടുണ്ട്. മുൻനിര ആപ്പിന്റെ ഡോസ് പതിപ്പ് വടക്കേ അമേരിക്കയിലെ ചെറുതും ഇടത്തരവുമായ സിനിമാ തിയേറ്റർ ശൃംഖലകളിൽ വളരെ ജനപ്രിയമായിരുന്നു. അതിനാൽ, ഏറ്റവും പുതിയ ടച്ച് സ്‌ക്രീനുകളും സെൽഫ് സർവീസ് കിയോസ്‌ക്കുകളും സംയോജിപ്പിച്ച്, എല്ലാത്തരം റിപ്പോർട്ടിംഗ് ടൂളുകളും സജ്ജീകരിച്ച് വിൻഡോസ് 95 പതിപ്പ് പ്രഖ്യാപിച്ചപ്പോൾ, അത് പെട്ടെന്ന് ജനപ്രിയമായതിൽ അതിശയിക്കാനില്ല. മിക്കപ്പോഴും അപ്‌ഡേറ്റ് പ്രശ്‌നങ്ങളില്ലാതെ പോയി. പ്രാദേശിക ഐടി സ്റ്റാഫ് പുതിയ ഉപകരണങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്തു, ഡാറ്റ മൈഗ്രേറ്റ് ചെയ്തു, ബിസിനസ്സ് തുടർന്നു. അത് നീണ്ടുനിന്നില്ല എന്നതൊഴിച്ചാൽ. ഇത് സംഭവിക്കുമ്പോൾ, കമ്പനി "ക്ലീനർ" എന്ന് വിളിപ്പേരുള്ള ജെയിംസിനെ അയയ്ക്കും.

വിളിപ്പേര് ഒരു മോശം തരം സൂചിപ്പിക്കുന്നുണ്ടെങ്കിലും, ക്ലീനർ എന്നത് ഇൻസ്ട്രക്ടർ, ഇൻസ്റ്റാളർ, ജാക്ക്-ഓഫ്-ഓൾ-ട്രേഡ് എന്നിവയുടെ സംയോജനമാണ്. ജെയിംസ് ക്ലയന്റിന്റെ സൈറ്റിൽ എല്ലാ ഘടകങ്ങളും ഒരുമിച്ച് ചേർക്കാൻ കുറച്ച് ദിവസങ്ങൾ ചെലവഴിക്കും, തുടർന്ന് പുതിയ സിസ്റ്റം എങ്ങനെ ഉപയോഗിക്കണമെന്ന് ജീവനക്കാരെ പഠിപ്പിക്കാനും, ഉണ്ടായ ഹാർഡ്‌വെയർ പ്രശ്നങ്ങൾ പരിഹരിക്കാനും, സോഫ്റ്റ്‌വെയറിനെ അതിന്റെ ശൈശവാവസ്ഥയിൽ തന്നെ സഹായിക്കാനും ജെയിംസ് കുറച്ച് ദിവസം ചെലവഴിക്കും.

അതുകൊണ്ട് തന്നെ, ഈ തിരക്കിനിടയിൽ, ജെയിംസ് രാവിലെ ഓഫീസിൽ എത്തിയതിൽ അതിശയിക്കാനില്ല, അവൻ തന്റെ മേശയിലെത്തും മുമ്പ്, പതിവിലും കവിഞ്ഞ കഫീൻ നിറച്ച് മാനേജർ അവനെ സ്വാഗതം ചെയ്തു.

“നിങ്ങൾ എത്രയും വേഗം നോവ സ്കോട്ടിയയിലെ അനാപോളിസിലേക്ക് പോകേണ്ടതുണ്ടെന്ന് ഞാൻ ഭയപ്പെടുന്നു.” അവരുടെ മുഴുവൻ സിസ്റ്റവും തകരാറിലായി, അവരുടെ എഞ്ചിനീയർമാരുമായി ഒരു രാത്രി പ്രവർത്തിച്ചതിന് ശേഷം, എന്താണ് സംഭവിച്ചതെന്ന് ഞങ്ങൾക്ക് മനസിലാക്കാൻ കഴിയില്ല. സെർവറിൽ നെറ്റ്‌വർക്ക് പരാജയപ്പെട്ടതായി തോന്നുന്നു. എന്നാൽ സിസ്റ്റം കുറച്ച് മിനിറ്റുകൾ പ്രവർത്തിച്ചതിന് ശേഷം മാത്രം.

- അവർ പഴയ സംവിധാനത്തിലേക്ക് മടങ്ങിയില്ലേ? - മാനസികമായി അവൻ ആശ്ചര്യത്തോടെ കണ്ണുകൾ വികസിപ്പിച്ചെങ്കിലും ജെയിംസ് പൂർണ്ണമായും ഗൗരവമായി ഉത്തരം നൽകി.

— കൃത്യമായി: അവരുടെ ഐടി സ്പെഷ്യലിസ്റ്റ് "മുൻഗണനകൾ മാറ്റി" അവരുടെ പഴയ സെർവറിനൊപ്പം പോകാൻ തീരുമാനിച്ചു. ജെയിംസ്, അവർ ആറ് സൈറ്റുകളിൽ സിസ്റ്റം ഇൻസ്റ്റാൾ ചെയ്യുകയും പ്രീമിയം സപ്പോർട്ടിനായി പണം നൽകുകയും ചെയ്തു, അവരുടെ ബിസിനസ്സ് ഇപ്പോൾ 1950 കളിലെ പോലെ പ്രവർത്തിക്കുന്നു.

ജെയിംസ് ചെറുതായി നിവർന്നു.

- അത് വേറെ കാര്യം. ശരി, നമുക്ക് ആരംഭിക്കാം.

അന്നാപൊലിസിൽ എത്തിയപ്പോൾ ആദ്യം ചെയ്തത് ഉപഭോക്താവിന്റെ പ്രശ്‌നമുള്ള ആദ്യത്തെ തിയേറ്റർ കണ്ടെത്തുകയായിരുന്നു. വിമാനത്താവളത്തിൽ നിന്ന് എടുത്ത മാപ്പിൽ, എല്ലാം മാന്യമായി കാണപ്പെട്ടു, എന്നാൽ ആവശ്യമുള്ള വിലാസത്തിന് ചുറ്റുമുള്ള പ്രദേശം സംശയാസ്പദമായി കാണപ്പെട്ടു. ഗെട്ടോയല്ല, ഫിലിം നോയറിനെ അനുസ്മരിപ്പിക്കുന്നു. ജെയിംസ് കർബ് ഡൗണ്ടൗണിൽ പാർക്ക് ചെയ്തപ്പോൾ ഒരു വേശ്യ അവനെ സമീപിച്ചു. അന്നാപോളിസിന്റെ വലിപ്പം കണക്കിലെടുക്കുമ്പോൾ, മിക്കവാറും നഗരത്തിൽ ഇത് മാത്രമായിരുന്നു. അവളുടെ രൂപം ഉടൻ തന്നെ വലിയ സ്‌ക്രീനിൽ പണത്തിന് ലൈംഗികത വാഗ്ദാനം ചെയ്ത പ്രശസ്ത കഥാപാത്രത്തെ ഓർമ്മയിലേക്ക് കൊണ്ടുവന്നു. ഇല്ല, ജൂലിയ റോബർട്ട്സിനെക്കുറിച്ചല്ല, ജോൺ വോയിറ്റിനെക്കുറിച്ചാണ് ["മിഡ്‌നൈറ്റ് കൗബോയ്" എന്ന ചിത്രത്തിലേക്കുള്ള സൂചന - ഏകദേശം. പാത].

വേശ്യയെ വഴിയിൽ അയച്ച ജെയിംസ് സിനിമയിലേക്ക് പോയി. ചുറ്റുമുള്ള പ്രദേശം മെച്ചപ്പെട്ടു, പക്ഷേ അത് ഇപ്പോഴും ഓടിപ്പോകുന്ന പ്രതീതി നൽകി. ജെയിംസ് വളരെയധികം വിഷമിച്ചു എന്നല്ല. അവൻ മുമ്പ് ശോചനീയമായ സ്ഥലങ്ങളിൽ പോയിട്ടുണ്ട്. ഇത് കാനഡയായിരുന്നു, അവിടെ മഗ്ഗർമാർ പോലും നിങ്ങളുടെ വാലറ്റ് എടുത്തതിന് ശേഷം "നന്ദി" എന്ന് പറയാൻ മര്യാദയുള്ളവരാണ്.

സിനിമയിലേക്കുള്ള പ്രവേശന കവാടം നനഞ്ഞ ഇടവഴിയിലായിരുന്നു. ജെയിംസ് വാതിലിൽ ചെന്ന് മുട്ടി. അധികം താമസിയാതെ അത് ഇളകി ചെറുതായി തുറന്നു.

- നിങ്ങൾ ഒരു ക്ലീനറാണോ? - ഉള്ളിൽ നിന്ന് ഒരു പരുക്കൻ ശബ്ദം.

- അതെ, ഇത് ഞാനാണ് ... എല്ലാം ശരിയാക്കാനാണ് ഞാൻ വന്നത്.

ജെയിംസ് സിനിമാ ലോബിയിലേക്ക് നടന്നു. പ്രത്യക്ഷത്തിൽ മറ്റൊരു മാർഗവുമില്ലാത്തതിനാൽ, ജീവനക്കാർ സന്ദർശകർക്ക് പേപ്പർ ടിക്കറ്റുകൾ കൈമാറാൻ തുടങ്ങി. ഇത് സാമ്പത്തിക റിപ്പോർട്ടിംഗ് പ്രയാസകരമാക്കി, കൂടുതൽ രസകരമായ വിശദാംശങ്ങൾ പറയട്ടെ. എന്നാൽ ജീവനക്കാർ ജെയിംസിനെ ആശ്വാസത്തോടെ അഭിവാദ്യം ചെയ്യുകയും ഉടൻ തന്നെ സെർവർ റൂമിലേക്ക് കൊണ്ടുപോകുകയും ചെയ്തു.

ഒറ്റനോട്ടത്തിൽ എല്ലാം ശരിയായി. ജെയിംസ് സെർവറിൽ കയറി സാധാരണ സംശയാസ്പദമായ സ്ഥലങ്ങൾ പരിശോധിച്ചു. ഒരു പ്രശ്നവുമില്ല. എന്നിരുന്നാലും, വളരെയധികം ജാഗ്രതയോടെ, ജെയിംസ് സെർവർ ഷട്ട് ഡൗൺ ചെയ്തു, നെറ്റ്‌വർക്ക് കാർഡ് മാറ്റി, സിസ്റ്റം പിൻവലിച്ചു. അവൾ ഉടൻ തന്നെ പൂർണ്ണമായി പ്രവർത്തിക്കാൻ തുടങ്ങി. ജീവനക്കാർ വീണ്ടും ടിക്കറ്റ് വിൽപന തുടങ്ങി.

ജെയിംസ് മാർക്കിനെ വിളിച്ച് സ്ഥിതിഗതികൾ അറിയിച്ചു. അപ്രതീക്ഷിതമായി എന്തെങ്കിലും സംഭവിക്കുമോ എന്ന് നോക്കാൻ ജെയിംസ് ആഗ്രഹിച്ചേക്കുമെന്ന് സങ്കൽപ്പിക്കാൻ പ്രയാസമില്ല. അവൻ പടികൾ ഇറങ്ങി, എന്താണ് സംഭവിച്ചതെന്ന് ജീവനക്കാരോട് ചോദിക്കാൻ തുടങ്ങി. സിസ്റ്റം പ്രവർത്തിക്കുന്നത് നിർത്തിയെന്ന് വ്യക്തം. അവർ അത് ഓഫാക്കി, എല്ലാം പ്രവർത്തിച്ചു. എന്നാൽ 10 മിനിറ്റിനുശേഷം സിസ്റ്റം തകരാറിലായി.

ഈ നിമിഷം സമാനമായ ഒന്ന് സംഭവിച്ചു. പെട്ടെന്ന് ടിക്കറ്റ് സമ്പ്രദായം തെറ്റിത്തുടങ്ങി. ജീവനക്കാർ നെടുവീർപ്പിട്ടു പേപ്പർ ടിക്കറ്റ് എടുത്തു, ജെയിംസ് വേഗം സെർവർ റൂമിലേക്ക് പോയി. സെർവറിൽ എല്ലാം നന്നായി കാണപ്പെട്ടു.

അപ്പോൾ ജീവനക്കാരിലൊരാൾ അകത്തേക്ക് കയറി.

- സിസ്റ്റം വീണ്ടും പ്രവർത്തിക്കുന്നു.

ഒന്നും ചെയ്യാത്തതിനാൽ ജെയിംസ് ആശയക്കുഴപ്പത്തിലായി. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, സിസ്റ്റം പ്രവർത്തനക്ഷമമാക്കുന്ന ഒന്നും തന്നെയില്ല. അയാൾ ലോഗ് ഔട്ട് ചെയ്‌ത് ഫോൺ എടുത്ത് കമ്പനിയുടെ സപ്പോർട്ട് ലൈനിലേക്ക് വിളിച്ചു. ഉടൻ തന്നെ അതേ ജീവനക്കാരൻ സെർവർ റൂമിലേക്ക് പ്രവേശിച്ചു.

- സിസ്റ്റം തകരാറിലാണ്.

ജെയിംസ് സെർവറിലേക്ക് നോക്കി. രസകരവും പരിചിതവുമായ ഒന്നിലധികം വർണ്ണ രൂപങ്ങൾ സ്ക്രീനിൽ നൃത്തം ചെയ്തു - കുഴഞ്ഞുമറിഞ്ഞും ഇഴചേർന്ന് കിടക്കുന്ന പൈപ്പുകൾ. നാമെല്ലാവരും ഈ സ്ക്രീൻസേവർ എപ്പോഴെങ്കിലും കണ്ടിട്ടുണ്ട്. അത് മനോഹരമായി അവതരിപ്പിക്കുകയും അക്ഷരാർത്ഥത്തിൽ ഹിപ്നോട്ടൈസുചെയ്യുകയും ചെയ്തു.

ജെയിംസ് ഒരു ബട്ടൺ അമർത്തി പാറ്റേൺ അപ്രത്യക്ഷമായി. അവൻ ടിക്കറ്റ് ഓഫീസിലേക്ക് വേഗം പോയി, വഴിയിൽ ഒരു ജീവനക്കാരനെ കണ്ടുമുട്ടി.

- സിസ്റ്റം വീണ്ടും പ്രവർത്തിക്കുന്നു.

നിങ്ങൾക്ക് ഒരു മാനസിക ഫേസ്പാം ചെയ്യാൻ കഴിയുമെങ്കിൽ, ജെയിംസ് ചെയ്തത് അതാണ്. സ്ക്രീൻ സേവർ. ഇത് OpenGL ഉപയോഗിക്കുന്നു. അതിനാൽ, പ്രവർത്തന സമയത്ത്, ഇത് സെർവർ പ്രോസസറിന്റെ എല്ലാ വിഭവങ്ങളും ഉപയോഗിക്കുന്നു. തൽഫലമായി, സെർവറിലേക്കുള്ള ഓരോ കോളും ഒരു സമയപരിധിയോടെ അവസാനിക്കുന്നു.

ജെയിംസ് സെർവർ റൂമിലേക്ക് മടങ്ങി, ലോഗിൻ ചെയ്‌ത്, സ്‌ക്രീൻസേവറിന് പകരം ശൂന്യമായ സ്‌ക്രീനുള്ള മനോഹരമായ പൈപ്പുകൾ നൽകി. അതായത്, 100% പ്രോസസ്സർ ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്ന ഒരു സ്ക്രീൻസേവറിന് പകരം, വിഭവങ്ങൾ ഉപയോഗിക്കാത്ത മറ്റൊന്ന് ഞാൻ ഇൻസ്റ്റാൾ ചെയ്തു. പിന്നെ എന്റെ ഊഹം പരിശോധിക്കാൻ ഞാൻ 10 മിനിറ്റ് കാത്തിരുന്നു.

അടുത്ത സിനിമാശാലയിൽ എത്തിയ ജെയിംസ്, സ്‌ക്രീൻ സേവർ ഓഫാക്കാൻ 800 കിലോമീറ്റർ മാത്രം പറന്ന കാര്യം മാനേജരോട് എങ്ങനെ വിശദീകരിക്കും എന്നാലോചിക്കുകയായിരുന്നു.

ചന്ദ്രന്റെ ഒരു നിശ്ചിത ഘട്ടത്തിൽ ക്രാഷ്

യഥാർത്ഥ കഥ. ഒരു ദിവസം ചന്ദ്രന്റെ ഘട്ടത്തെ ആശ്രയിച്ച് ഒരു സോഫ്റ്റ്വെയർ ബഗ് ഉയർന്നു. ചന്ദ്രന്റെ യഥാർത്ഥ ഘട്ടത്തിലേക്കുള്ള ഏകദേശ കണക്ക് കണക്കാക്കാൻ വിവിധ MIT പ്രോഗ്രാമുകളിൽ സാധാരണയായി ഉപയോഗിക്കുന്ന ഒരു ചെറിയ ദിനചര്യ ഉണ്ടായിരുന്നു. GLS ഈ പതിവ് ഒരു LISP പ്രോഗ്രാമായി നിർമ്മിച്ചു, അത് ഒരു ഫയൽ എഴുതുമ്പോൾ, ഏകദേശം 80 പ്രതീകങ്ങളുള്ള ടൈംസ്റ്റാമ്പുള്ള ഒരു ലൈൻ ഔട്ട്‌പുട്ട് ചെയ്യും. ഒരു സന്ദേശത്തിന്റെ ആദ്യ വരി വളരെ ദൈർഘ്യമേറിയതും അടുത്ത വരിയിലേക്ക് നയിക്കുന്നതും വളരെ അപൂർവമായിരുന്നു. പ്രോഗ്രാം പിന്നീട് ഈ ഫയൽ വായിച്ചപ്പോൾ, അത് ശപിച്ചു. ആദ്യ വരിയുടെ ദൈർഘ്യം കൃത്യമായ തീയതിയെയും സമയത്തെയും ആശ്രയിച്ചിരിക്കുന്നു, കൂടാതെ ടൈംസ്റ്റാമ്പ് അച്ചടിച്ച സമയത്തെ ഫേസ് സ്പെസിഫിക്കേഷന്റെ ദൈർഘ്യത്തെയും ആശ്രയിച്ചിരിക്കുന്നു. അതായത്, ബഗ് അക്ഷരാർത്ഥത്തിൽ ചന്ദ്രന്റെ ഘട്ടത്തെ ആശ്രയിച്ചിരിക്കുന്നു!

ആദ്യ പേപ്പർ പതിപ്പ് ജാർഗോൺ ഫയൽ (Steele-1983) വിവരിച്ച ബഗിലേക്ക് നയിച്ച അത്തരം ഒരു വരിയുടെ ഒരു ഉദാഹരണം അടങ്ങിയിരിക്കുന്നു, പക്ഷേ ടൈപ്പ്സെറ്റർ അത് "പരിഹരിച്ചു". അന്നുമുതൽ ഇതിനെ "മൂൺ ഫേസ് ബഗ്" എന്ന് വിശേഷിപ്പിക്കുന്നു.

എന്നിരുന്നാലും, അനുമാനങ്ങളിൽ ശ്രദ്ധാലുവായിരിക്കുക. കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്, CERN (യൂറോപ്യൻ സെന്റർ ഫോർ ന്യൂക്ലിയർ റിസർച്ച്) ൽ നിന്നുള്ള എഞ്ചിനീയർമാർ ലാർജ് ഇലക്ട്രോൺ-പോസിട്രോൺ കൊളൈഡറിൽ നടത്തിയ പരീക്ഷണങ്ങളിൽ പിശകുകൾ നേരിട്ടു. ശാസ്ത്രജ്ഞർക്ക് ഫലം കാണിക്കുന്നതിന് മുമ്പ് ഈ ഉപകരണം സൃഷ്ടിച്ച വലിയ അളവിലുള്ള ഡാറ്റ കമ്പ്യൂട്ടറുകൾ സജീവമായി പ്രോസസ്സ് ചെയ്യുന്നതിനാൽ, സോഫ്‌റ്റ്‌വെയർ ചന്ദ്രന്റെ ഘട്ടത്തോട് എങ്ങനെയെങ്കിലും സെൻസിറ്റീവ് ആണെന്ന് പലരും ഊഹിച്ചു. നിരാശരായ നിരവധി എഞ്ചിനീയർമാർ സത്യത്തിന്റെ അടിത്തട്ടിലെത്തി. ചന്ദ്രൻ കടന്നുപോകുമ്പോൾ ഭൂമിയുടെ രൂപഭേദം കാരണം 27 കിലോമീറ്റർ നീളമുള്ള വളയത്തിന്റെ ജ്യാമിതിയിൽ ചെറിയ മാറ്റം വന്നതാണ് പിശക് സംഭവിച്ചത്! ഈ കഥ ഭൗതികശാസ്ത്ര നാടോടിക്കഥകളിൽ "ന്യൂട്ടന്റെ കണികാ ഭൗതികശാസ്ത്രത്തിലെ പ്രതികാരം" എന്ന പേരിൽ പ്രവേശിച്ചു, കൂടാതെ ഭൗതികശാസ്ത്രത്തിലെ ഏറ്റവും ലളിതവും പഴക്കമുള്ളതുമായ നിയമങ്ങളും ഏറ്റവും നൂതനമായ ശാസ്ത്ര ആശയങ്ങളും തമ്മിലുള്ള ബന്ധത്തിന്റെ ഒരു ഉദാഹരണമാണ്.

ടോയ്‌ലറ്റ് ഫ്ലഷ് ചെയ്യുന്നത് ട്രെയിൻ നിർത്തുന്നു

ഞാൻ കേട്ടിട്ടുള്ളതിൽ വച്ച് ഏറ്റവും മികച്ച ഹാർഡ്‌വെയർ ബഗ് ഫ്രാൻസിലെ അതിവേഗ ട്രെയിനിലാണ്. ബഗ് ട്രെയിനിന്റെ അടിയന്തര ബ്രേക്കിംഗിലേക്ക് നയിച്ചു, പക്ഷേ യാത്രക്കാർ ഉണ്ടായിരുന്നെങ്കിൽ മാത്രം. അത്തരം ഓരോ സാഹചര്യത്തിലും, ട്രെയിൻ സർവീസ് നിർത്തി, പരിശോധിച്ചെങ്കിലും ഒന്നും കണ്ടെത്താനായില്ല. തുടർന്ന് അവനെ തിരികെ ലൈനിലേക്ക് അയച്ചു, അയാൾ ഉടൻ തന്നെ ഒരു സ്റ്റോപ്പിലേക്ക് ഇടിച്ചു.

ഒരു പരിശോധനയ്ക്കിടെ, ട്രെയിനിൽ യാത്ര ചെയ്യുന്ന ഒരു എഞ്ചിനീയർ ടോയ്‌ലറ്റിലേക്ക് പോയി. അവൻ ഉടൻ കഴുകി, ബൂം! അടിയന്തരമായി നിർത്തുക.

എഞ്ചിനീയർ ഡ്രൈവറെ ബന്ധപ്പെട്ട് ചോദിച്ചു:

- ബ്രേക്ക് ചെയ്യുന്നതിന് തൊട്ടുമുമ്പ് നിങ്ങൾ എന്താണ് ചെയ്തിരുന്നത്?

- ശരി, ഞാൻ ഇറക്കത്തിന്റെ വേഗത കുറച്ചു...

ഇത് വിചിത്രമായിരുന്നു, കാരണം സാധാരണ ഓപ്പറേഷൻ സമയത്ത് ട്രെയിൻ ഡസൻ കണക്കിന് തവണ ഇറക്കത്തിൽ വേഗത കുറയ്ക്കുന്നു. ട്രെയിൻ നീങ്ങി, അടുത്ത ഇറക്കത്തിൽ ഡ്രൈവർ മുന്നറിയിപ്പ് നൽകി:

- ഞാൻ വേഗത കുറയ്ക്കാൻ പോകുന്നു.

ഒന്നും സംഭവിച്ചില്ല.

- അവസാന ബ്രേക്കിംഗ് സമയത്ത് നിങ്ങൾ എന്താണ് ചെയ്തത്? - ഡ്രൈവർ ചോദിച്ചു.

- ശരി... ഞാൻ ടോയ്‌ലറ്റിൽ ആയിരുന്നു...

- ശരി, പിന്നെ ടോയ്‌ലറ്റിൽ പോയി ഞങ്ങൾ വീണ്ടും ഇറങ്ങുമ്പോൾ നിങ്ങൾ ചെയ്തത് ചെയ്യുക!

എഞ്ചിനീയർ ടോയ്‌ലറ്റിൽ പോയി, ഡ്രൈവർ മുന്നറിയിപ്പ് നൽകിയപ്പോൾ: "ഞാൻ വേഗത കുറയ്ക്കുന്നു," അവൻ വെള്ളം ഒഴിച്ചു. തീർച്ചയായും, ട്രെയിൻ ഉടൻ നിർത്തി.

ഇപ്പോൾ അവർക്ക് പ്രശ്നം പുനർനിർമ്മിക്കാൻ കഴിയും, കാരണം കണ്ടെത്തേണ്ടതുണ്ട്.

രണ്ട് മിനിറ്റിന് ശേഷം, എഞ്ചിൻ ബ്രേക്ക് റിമോട്ട് കൺട്രോൾ കേബിൾ (ട്രെയിനിന് ഓരോ അറ്റത്തും ഓരോ എഞ്ചിൻ) ഇലക്ട്രിക്കൽ കാബിനറ്റിന്റെ ഭിത്തിയിൽ നിന്ന് വിച്ഛേദിക്കപ്പെട്ട് ടോയ്‌ലറ്റ് പ്ലഗ് സോളിനോയിഡ് നിയന്ത്രിക്കുന്ന റിലേയിൽ കിടക്കുന്നത് അവർ ശ്രദ്ധിച്ചു... റിലേ ചെയ്യുമ്പോൾ ഓണാക്കി, അത് ബ്രേക്ക് കേബിളിൽ ഇടപെടൽ സൃഷ്ടിച്ചു, പരാജയങ്ങൾക്കെതിരായ സിസ്റ്റം പരിരക്ഷയിൽ അടിയന്തിര ബ്രേക്കിംഗ് ഉൾപ്പെടുന്നു.

ഫോർട്രാനെ വെറുക്കുന്ന കവാടം

മെയിൻലാൻഡിലെ നെറ്റ്‌വർക്ക് കണക്ഷനുകൾ [ഇത് ഹവായിയിലായിരുന്നു] വളരെ സാവധാനത്തിലാകുന്നത് കുറച്ച് മാസങ്ങൾക്ക് മുമ്പ് ഞങ്ങൾ ശ്രദ്ധിച്ചു. ഇത് 10-15 മിനിറ്റ് നീണ്ടുനിൽക്കുകയും പെട്ടെന്ന് വീണ്ടും സംഭവിക്കുകയും ചെയ്യും. കുറച്ച് സമയത്തിന് ശേഷം, മെയിൻലാൻഡിലെ നെറ്റ്‌വർക്ക് കണക്ഷനുകൾ ഉണ്ടെന്ന് എന്റെ സഹപ്രവർത്തകൻ എന്നോട് പരാതിപ്പെട്ടു പൊതുവേ പ്രവർത്തിക്കുന്നില്ല. മെയിൻലാൻഡിലെ ഒരു മെഷീനിലേക്ക് പകർത്തേണ്ട ചില ഫോർട്രാൻ കോഡ് അദ്ദേഹത്തിന്റെ പക്കലുണ്ടായിരുന്നു, പക്ഷേ "എഫ്‌ടിപി അപ്‌ലോഡ് പൂർത്തിയാകുന്നതിന് നെറ്റ്‌വർക്ക് വേണ്ടത്ര നീണ്ടുനിൽക്കാത്തതിനാൽ" അതിന് കഴിഞ്ഞില്ല.

അതെ, ഒരു സഹപ്രവർത്തകൻ ഫോർട്രാനിലെ സോഴ്‌സ് കോഡുള്ള ഒരു ഫയൽ മെയിൻലാൻഡിലെ ഒരു മെഷീനിലേക്ക് എഫ്‌ടിപി ചെയ്യാൻ ശ്രമിച്ചപ്പോൾ നെറ്റ്‌വർക്ക് പരാജയം സംഭവിച്ചതായി തെളിഞ്ഞു. ഞങ്ങൾ ഫയൽ ആർക്കൈവ് ചെയ്യാൻ ശ്രമിച്ചു: പിന്നീട് അത് സുഗമമായി പകർത്തി (എന്നാൽ ടാർഗെറ്റ് മെഷീനിൽ ഒരു അൺപാക്കർ ഇല്ല, അതിനാൽ പ്രശ്നം പരിഹരിച്ചില്ല). അവസാനം ഞങ്ങൾ FORTRAN കോഡ് വളരെ ചെറിയ കഷണങ്ങളായി "വിഭജിച്ചു" അവ ഓരോന്നായി അയച്ചു. മിക്ക ശകലങ്ങളും പ്രശ്‌നങ്ങളില്ലാതെ പകർത്തി, പക്ഷേ കുറച്ച് കഷണങ്ങൾ കടന്നുപോകുകയോ കടന്നുപോകുകയോ ചെയ്തില്ല ധാരാളം ശ്രമങ്ങൾ.

പ്രശ്‌നകരമായ ഭാഗങ്ങൾ പരിശോധിച്ചപ്പോൾ, അവയ്‌ക്ക് പൊതുവായ എന്തെങ്കിലും ഉണ്ടെന്ന് ഞങ്ങൾ കണ്ടെത്തി: അവയിലെല്ലാം ക്യാപിറ്റൽ C അടങ്ങിയ വരികളിൽ ആരംഭിക്കുകയും അവസാനിക്കുകയും ചെയ്യുന്ന കമന്റ് ബ്ലോക്കുകൾ അടങ്ങിയിരിക്കുന്നു (ഒരു സഹപ്രവർത്തകൻ ഫോർട്രാനിൽ അഭിപ്രായമിടാൻ ഇഷ്ടപ്പെടുന്നത് പോലെ). മെയിൻലാൻഡിലെ നെറ്റ്‌വർക്ക് വിദഗ്ധർക്ക് ഞങ്ങൾ ഇമെയിൽ ചെയ്യുകയും സഹായം അഭ്യർത്ഥിക്കുകയും ചെയ്തു. തീർച്ചയായും, FTP വഴി കൈമാറാൻ കഴിയാത്ത ഞങ്ങളുടെ ഫയലുകളുടെ സാമ്പിളുകൾ കാണാൻ അവർ ആഗ്രഹിച്ചു... പക്ഷേ ഞങ്ങളുടെ കത്തുകൾ അവരിലേക്ക് എത്തിയില്ല. അവസാനം ഞങ്ങൾ ഒരു സിമ്പിൾ ആയി വന്നു വിവരിക്കുകകൈമാറ്റം ചെയ്യാനാവാത്ത ഫയലുകൾ എങ്ങനെയിരിക്കും. ഇത് പ്രവർത്തിച്ചു :) [പ്രശ്നമുള്ള ഫോർട്രാൻ കമന്റുകളുടെ ഒരു ഉദാഹരണം ഇവിടെ ചേർക്കാൻ ഞാൻ ധൈര്യപ്പെട്ടോ? ഒരുപക്ഷേ അത് വിലമതിക്കുന്നില്ല!]

അവസാനം ഞങ്ങൾ അത് കണ്ടുപിടിക്കാൻ കഴിഞ്ഞു. കാമ്പസിന്റെ ഞങ്ങളുടെ ഭാഗത്തിനും മെയിൻലാൻഡ് നെറ്റ്‌വർക്കിനുമിടയിൽ അടുത്തിടെ ഒരു പുതിയ ഗേറ്റ്‌വേ സ്ഥാപിച്ചു. വലിയക്ഷരം C യുടെ ആവർത്തിച്ചുള്ള ബിറ്റുകൾ അടങ്ങിയ പാക്കറ്റുകൾ കൈമാറാൻ ഇതിന് വലിയ ബുദ്ധിമുട്ടുണ്ടായിരുന്നു! ഈ പാക്കറ്റുകളിൽ ചിലത് എല്ലാ ഗേറ്റ്‌വേ റിസോഴ്‌സുകളും എടുക്കുകയും മറ്റ് മിക്ക പാക്കറ്റുകളും അതിലൂടെ കടക്കുന്നത് തടയുകയും ചെയ്യും. ഞങ്ങൾ ഗേറ്റ്‌വേ നിർമ്മാതാവിനോട് പരാതിപ്പെട്ടു... അവർ മറുപടി പറഞ്ഞു: “ഓ, അതെ, നിങ്ങൾക്ക് ആവർത്തിച്ചുള്ള സിയുടെ ഒരു ബഗ് നേരിടേണ്ടിവരുന്നു! അവനെക്കുറിച്ച് ഞങ്ങൾക്ക് ഇതിനകം അറിയാം. ” മറ്റൊരു നിർമ്മാതാവിൽ നിന്ന് ഒരു പുതിയ ഗേറ്റ്‌വേ വാങ്ങിക്കൊണ്ട് ഞങ്ങൾ ഒടുവിൽ പ്രശ്നം പരിഹരിച്ചു (മുമ്പത്തെ പ്രതിരോധത്തിൽ, ഫോർട്രാൻ പ്രോഗ്രാമുകൾ കൈമാറാനുള്ള കഴിവില്ലായ്മ ചിലർക്ക് ഒരു നേട്ടമായിരിക്കാം!).

പ്രയാസകരമായ സമയങ്ങൾ

കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്, ഫേസ് 40 ക്ലിനിക്കൽ ട്രയലുകളുടെ ചിലവ് കുറയ്ക്കുന്നതിന് Perl-ൽ ഒരു ETL സിസ്റ്റം സൃഷ്ടിക്കുന്നതിൽ പ്രവർത്തിക്കുമ്പോൾ, എനിക്ക് ഏകദേശം 000 തീയതികൾ പ്രോസസ്സ് ചെയ്യേണ്ടിവന്നു. ഇവരിൽ രണ്ടുപേർ പരീക്ഷയിൽ വിജയിച്ചില്ല. ഇത് എന്നെ അധികം ബുദ്ധിമുട്ടിച്ചില്ല, കാരണം ഈ തീയതികൾ ക്ലയന്റ് നൽകിയ ഡാറ്റയിൽ നിന്നാണ് എടുത്തത്, അത് പലപ്പോഴും നമ്മൾ അത്ഭുതപ്പെടുത്തും. എന്നാൽ ഞാൻ യഥാർത്ഥ ഡാറ്റ പരിശോധിച്ചപ്പോൾ, ഈ തീയതികൾ ജനുവരി 1, 2011 ജനുവരി 1, 2007 ആണെന്ന് മനസ്സിലായി. ഞാൻ ഇപ്പോൾ എഴുതിയ പ്രോഗ്രാമിൽ ബഗ് അടങ്ങിയിട്ടുണ്ടെന്ന് ഞാൻ കരുതി, പക്ഷേ ഇതിനകം 30 വർഷമായി. പഴയത്. സോഫ്റ്റ്‌വെയർ ഇക്കോസിസ്റ്റം പരിചയമില്ലാത്തവർക്ക് ഇത് നിഗൂഢമായി തോന്നാം. പണം സമ്പാദിക്കാനുള്ള മറ്റൊരു കമ്പനിയുടെ ദീർഘകാല തീരുമാനം കാരണം, ഒരു കമ്പനി ആകസ്മികമായും മറ്റേത് മനഃപൂർവമായും അവതരിപ്പിച്ച ഒരു ബഗ് പരിഹരിക്കാൻ എന്റെ ക്ലയന്റ് എനിക്ക് പണം നൽകി. ഞാൻ എന്താണ് സംസാരിക്കുന്നതെന്ന് നിങ്ങൾക്ക് മനസിലാക്കാൻ, ഒരു ബഗായി മാറിയ ഫീച്ചർ ചേർത്ത കമ്പനിയെക്കുറിച്ചും ഞാൻ പരിഹരിച്ച ദുരൂഹമായ ബഗിന് കാരണമായ മറ്റ് ചില രസകരമായ സംഭവങ്ങളെക്കുറിച്ചും സംസാരിക്കേണ്ടതുണ്ട്.

നല്ല പഴയ ദിവസങ്ങളിൽ, ആപ്പിൾ കമ്പ്യൂട്ടറുകൾ ചിലപ്പോൾ സ്വയമേവ 1 ജനുവരി 1904-ലേക്ക് അവരുടെ തീയതി പുനഃസജ്ജമാക്കും. കാരണം ലളിതമായിരുന്നു: തീയതിയും സമയവും ട്രാക്ക് ചെയ്യാൻ ബാറ്ററിയിൽ പ്രവർത്തിക്കുന്ന "സിസ്റ്റം ക്ലോക്ക്" ഉപയോഗിച്ചു. ബാറ്ററി നശിച്ചപ്പോൾ എന്താണ് സംഭവിച്ചത്? ഒരു യുഗത്തിന്റെ ആരംഭം മുതൽ കംപ്യൂട്ടറുകൾ സെക്കൻഡുകളുടെ എണ്ണം കൊണ്ട് തീയതി ട്രാക്ക് ചെയ്യാൻ തുടങ്ങി. യുഗം കൊണ്ട് ഞങ്ങൾ ഉദ്ദേശിച്ചത് റഫറൻസ് ഒറിജിനൽ തീയതിയാണ്, Macintoshes ന് അത് ജനുവരി 1, 1904 ആയിരുന്നു. ബാറ്ററി മരിച്ചതിന് ശേഷം, നിലവിലെ തീയതി നിർദ്ദിഷ്ട തീയതിയിലേക്ക് പുനഃസജ്ജമാക്കി. എന്നാൽ എന്തുകൊണ്ടാണ് ഇത് സംഭവിച്ചത്?

മുമ്പ്, യഥാർത്ഥ തീയതി മുതൽ സെക്കൻഡുകളുടെ എണ്ണം സംഭരിക്കാൻ ആപ്പിൾ 32 ബിറ്റുകൾ ഉപയോഗിച്ചിരുന്നു. ഒരു ബിറ്റിന് രണ്ട് മൂല്യങ്ങളിൽ ഒന്ന് സംഭരിക്കാൻ കഴിയും - 1 അല്ലെങ്കിൽ 0. രണ്ട് ബിറ്റുകൾക്ക് നാല് മൂല്യങ്ങളിൽ ഒന്ന് സംഭരിക്കാൻ കഴിയും: 00, 01, 10, 11. മൂന്ന് ബിറ്റുകൾ - എട്ടിൽ ഒരു മൂല്യം: 000, 001, 010, 011, 100 , 101, 110, 111, മുതലായവ. 32-ന് 232 മൂല്യങ്ങളിൽ ഒന്ന് സംഭരിക്കാൻ കഴിയും, അതായത് 4 സെക്കൻഡ്. ആപ്പിളിന്റെ തീയതികളിൽ, ഇത് ഏകദേശം 294 വർഷത്തിന് തുല്യമാണ്, അതിനാൽ പഴയ മാക്കുകൾക്ക് 967 ന് ശേഷമുള്ള തീയതികൾ കൈകാര്യം ചെയ്യാൻ കഴിയില്ല. സിസ്റ്റം ബാറ്ററി മരിക്കുകയാണെങ്കിൽ, യുഗത്തിന്റെ ആരംഭം മുതൽ തീയതി 296 സെക്കൻഡിലേക്ക് പുനഃസജ്ജമാക്കും, നിങ്ങൾ കമ്പ്യൂട്ടർ ഓണാക്കുമ്പോഴെല്ലാം (അല്ലെങ്കിൽ നിങ്ങൾ ഒരു പുതിയ ബാറ്ററി വാങ്ങുന്നതുവരെ) തീയതി സ്വമേധയാ സജ്ജീകരിക്കേണ്ടതുണ്ട്.

എന്നിരുന്നാലും, യുഗം മുതൽ തീയതികൾ സെക്കൻഡുകളായി സംഭരിക്കാനുള്ള ആപ്പിളിന്റെ തീരുമാനം അർത്ഥമാക്കുന്നത്, യുഗത്തിന് മുമ്പുള്ള തീയതികൾ കൈകാര്യം ചെയ്യാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല, അത് ദൂരവ്യാപകമായ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കി, നമ്മൾ കാണും. ആപ്പിൾ ഒരു ഫീച്ചർ അവതരിപ്പിച്ചു, ഒരു ബഗ് അല്ല. മറ്റ് കാര്യങ്ങളിൽ, ഇതിനർത്ഥം മാക്കിന്റോഷ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം "മില്ലേനിയം ബഗ്" (നിയന്ത്രണങ്ങൾ മറികടക്കാൻ അവരുടേതായ തീയതി സംവിധാനങ്ങളുള്ള നിരവധി മാക് ആപ്ലിക്കേഷനുകളെക്കുറിച്ച് പറയാൻ കഴിയില്ല) പ്രതിരോധിക്കുമെന്നാണ്.

മുന്നോട്ടുപോകുക. ഞങ്ങൾ ലോട്ടസ് 1-2-3, IBM-ന്റെ "കൊലയാളി ആപ്ലിക്കേഷൻ" ഉപയോഗിച്ചു, ഇത് പിസി വിപ്ലവം ആരംഭിക്കാൻ സഹായിച്ചു, എന്നിരുന്നാലും ആപ്പിൾ കമ്പ്യൂട്ടറുകളിൽ VisiCalc ഉണ്ടായിരുന്നു, അത് പേഴ്സണൽ കമ്പ്യൂട്ടറിനെ വിജയകരമാക്കി. ന്യായമായി പറഞ്ഞാൽ, 1-2-3 പ്രത്യക്ഷപ്പെട്ടിരുന്നില്ലെങ്കിൽ, പിസികൾ ആരംഭിക്കാൻ സാധ്യതയില്ല, കൂടാതെ പേഴ്സണൽ കമ്പ്യൂട്ടറുകളുടെ ചരിത്രം വളരെ വ്യത്യസ്തമായി വികസിപ്പിച്ചെടുക്കാമായിരുന്നു. ലോട്ടസ് 1-2-3 തെറ്റായി 1900 ഒരു അധിവർഷമായി കണക്കാക്കി. മൈക്രോസോഫ്റ്റ് അതിന്റെ ആദ്യ സ്പ്രെഡ്ഷീറ്റ്, മൾട്ടിപ്ലാൻ പുറത്തിറക്കിയപ്പോൾ, അത് വിപണിയുടെ ഒരു ചെറിയ പങ്ക് പിടിച്ചെടുത്തു. അവർ എക്സൽ പ്രോജക്റ്റ് സമാരംഭിച്ചപ്പോൾ, ലോട്ടസ് 1-2-3-ൽ നിന്ന് വരിയുടെയും കോളത്തിന്റെയും പേരിടൽ സ്കീം പകർത്താൻ മാത്രമല്ല, 1900 ഒരു അധിവർഷമായി കണക്കാക്കി ബഗ് അനുയോജ്യത ഉറപ്പാക്കാനും അവർ തീരുമാനിച്ചു. ഈ പ്രശ്നം ഇന്നും നിലനിൽക്കുന്നു. അതായത്, 1-2-3-ൽ ഇതൊരു ബഗ് ആയിരുന്നു, എന്നാൽ Excel-ൽ അത് ബോധപൂർവമായ തീരുമാനമായിരുന്നു, എല്ലാ 1-2-3 ഉപയോക്താക്കൾക്കും അവരുടെ ടേബിളുകൾ ഡാറ്റ മാറ്റാതെ തന്നെ Excel-ലേക്ക് ഇറക്കുമതി ചെയ്യാൻ കഴിയുമെന്ന് ഉറപ്പുവരുത്തി, അത് തെറ്റാണെങ്കിലും.

എന്നാൽ മറ്റൊരു പ്രശ്നം ഉണ്ടായിരുന്നു. ആദ്യം, മൈക്രോസോഫ്റ്റ് മാക്കിന്റോഷിനായി എക്സൽ പുറത്തിറക്കി, അത് ജനുവരി 1, 1904 ന് മുമ്പുള്ള തീയതികൾ തിരിച്ചറിഞ്ഞില്ല. കൂടാതെ എക്സലിൽ, ജനുവരി 1, 1900 യുഗത്തിന്റെ തുടക്കമായി കണക്കാക്കപ്പെട്ടു. അതിനാൽ, ഡവലപ്പർമാർ ഒരു മാറ്റം വരുത്തിയതിനാൽ അവരുടെ പ്രോഗ്രാം യുഗത്തിന്റെ തരം തിരിച്ചറിയുകയും ആവശ്യമുള്ള യുഗത്തിന് അനുസൃതമായി അതിൽ തന്നെ ഡാറ്റ സംഭരിക്കുകയും ചെയ്തു. മൈക്രോസോഫ്റ്റ് ഇതിനെക്കുറിച്ച് ഒരു വിശദീകരണ ലേഖനം പോലും എഴുതി. ഈ തീരുമാനം എന്റെ ബഗിലേക്ക് നയിച്ചു.

എന്റെ ETL സിസ്റ്റത്തിന് Windows-ൽ സൃഷ്‌ടിച്ച ഉപഭോക്താക്കളിൽ നിന്ന് Excel സ്‌പ്രെഡ്‌ഷീറ്റുകൾ ലഭിച്ചു, പക്ഷേ Mac-ലും സൃഷ്‌ടിക്കാനാകും. അതിനാൽ, പട്ടികയിലെ യുഗത്തിന്റെ തുടക്കം 1 ജനുവരി 1900 അല്ലെങ്കിൽ 1 ജനുവരി 1904 ആകാം. എങ്ങനെ കണ്ടുപിടിക്കും? Excel ഫയൽ ഫോർമാറ്റ് ആവശ്യമായ വിവരങ്ങൾ കാണിക്കുന്നു, പക്ഷേ ഞാൻ ഉപയോഗിച്ച പാഴ്സർ അത് കാണിച്ചില്ല (ഇപ്പോൾ അത് കാണിക്കുന്നു), കൂടാതെ ഒരു നിർദ്ദിഷ്ട പട്ടികയുടെ യുഗം നിങ്ങൾക്ക് അറിയാമെന്ന് കരുതി. എക്സൽ ബൈനറി ഫോർമാറ്റ് മനസിലാക്കാനും പാഴ്‌സർ രചയിതാവിന് ഒരു പാച്ച് അയയ്ക്കാനും എനിക്ക് കൂടുതൽ സമയം ചെലവഴിക്കാമായിരുന്നു, പക്ഷേ ക്ലയന്റിനായി എനിക്ക് കൂടുതൽ കാര്യങ്ങൾ ചെയ്യാനുണ്ടായിരുന്നു, അതിനാൽ യുഗം നിർണ്ണയിക്കാൻ ഞാൻ പെട്ടെന്ന് ഒരു ഹ്യൂറിസ്റ്റിക് എഴുതി. അവൾ ലളിതയായിരുന്നു.

Excel-ൽ, ജൂലൈ 5, 1998 എന്ന തീയതി "07-05-98" (ഉപയോഗമില്ലാത്ത അമേരിക്കൻ സിസ്റ്റം), "ജൂലൈ 5, 98", "ജൂലൈ 5, 1998", "5-ജൂലൈ-98" അല്ലെങ്കിൽ മറ്റൊരു ഫോർമാറ്റ്. ഉപയോഗശൂന്യമായ മറ്റൊരു ഫോർമാറ്റ് (വിരോധാഭാസമെന്നു പറയട്ടെ, Excel-ന്റെ എന്റെ പതിപ്പ് നൽകാത്ത ഫോർമാറ്റുകളിലൊന്ന് ISO 8601 ആയിരുന്നു). എന്നിരുന്നാലും, പട്ടികയ്‌ക്കുള്ളിൽ, ഫോർമാറ്റ് ചെയ്യാത്ത തീയതി, യുഗം-35981-ന് "1900" അല്ലെങ്കിൽ യുഗം-34519-ന് "1904" ആയി സംഭരിച്ചു (അക്കങ്ങൾ യുഗം മുതലുള്ള ദിവസങ്ങളുടെ എണ്ണത്തെ പ്രതിനിധീകരിക്കുന്നു). ഫോർമാറ്റ് ചെയ്ത തീയതിയിൽ നിന്ന് വർഷം എക്‌സ്‌ട്രാക്‌റ്റുചെയ്യാൻ ഞാൻ ലളിതമായ ഒരു പാഴ്‌സർ ഉപയോഗിച്ചു, തുടർന്ന് ഫോർമാറ്റ് ചെയ്യാത്ത തീയതിയിൽ നിന്ന് വർഷം എക്‌സ്‌ട്രാക്റ്റുചെയ്യാൻ എക്‌സൽ പാഴ്‌സർ ഉപയോഗിച്ചു. രണ്ട് മൂല്യങ്ങളും 4 വർഷം കൊണ്ട് വ്യത്യസ്തമാണെങ്കിൽ, ഞാൻ എപ്പോക്ക് -1904 ഉള്ള ഒരു സിസ്റ്റം ഉപയോഗിക്കുന്നുണ്ടെന്ന് എനിക്കറിയാം.

എന്തുകൊണ്ടാണ് ഞാൻ ഫോർമാറ്റ് ചെയ്ത തീയതികൾ ഉപയോഗിക്കാത്തത്? കാരണം, 5 ജൂലൈ 1998, മാസത്തിലെ ദിവസം നഷ്‌ടപ്പെട്ടതോടെ "ജൂലൈ, 98" എന്ന് ഫോർമാറ്റ് ചെയ്യാം. നിരവധി കമ്പനികളിൽ നിന്ന് ഞങ്ങൾക്ക് ടേബിളുകൾ ലഭിച്ചു, അവ വ്യത്യസ്ത രീതികളിൽ സൃഷ്ടിച്ചു, തീയതികൾ കണ്ടെത്തേണ്ടത് ഞങ്ങളാണ് (ഈ സാഹചര്യത്തിൽ, ഞാൻ). കൂടാതെ, Excel അത് ശരിയാക്കുകയാണെങ്കിൽ, ഞങ്ങളും അങ്ങനെ ചെയ്യണം!

അതേ സമയം ഞാൻ 39082-നെ നേരിട്ടു. ലോട്ടസ് 1-2-3 1900-നെ ഒരു അധിവർഷമായി കണക്കാക്കി, Excel-ൽ ഇത് വിശ്വസ്തതയോടെ ആവർത്തിച്ചുവെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ. ഇത് 1900 എന്ന വർഷത്തിലേക്ക് ഒരു ദിവസം ചേർത്തതിനാൽ, ആ ദിവസം തന്നെ പല തീയതി കണക്കുകൂട്ടൽ ഫംഗ്‌ഷനുകളും തെറ്റായിരിക്കാം. അതായത്, 39082 ജനുവരി 1, 2011 (മാക്സിൽ) അല്ലെങ്കിൽ ഡിസംബർ 31, 2006 (വിൻഡോസിൽ) ആയിരിക്കാം. ഫോർമാറ്റ് ചെയ്‌ത മൂല്യത്തിൽ നിന്ന് എന്റെ “വർഷ പാഴ്‌സർ” 2011 എക്‌സ്‌ട്രാക്‌റ്റുചെയ്‌തെങ്കിൽ, എല്ലാം ശരിയാണ്. എന്നാൽ എക്സൽ പാഴ്‌സറിന് ഏത് കാലഘട്ടമാണ് ഉപയോഗിക്കുന്നതെന്ന് അറിയാത്തതിനാൽ, അത് എപ്പോക്ക്-1900-ലേക്ക് സ്ഥിരസ്ഥിതിയായി 2006-ൽ തിരിച്ചെത്തി. എന്റെ അപേക്ഷയിൽ വ്യത്യാസം 5 വർഷമാണെന്ന് കണ്ടു, അത് ഒരു പിശകായി കണക്കാക്കി, അത് ലോഗ് ചെയ്തു, ഫോർമാറ്റ് ചെയ്യാത്ത മൂല്യം തിരികെ നൽകി.

ഇതിനെ മറികടക്കാൻ, ഞാൻ ഇത് എഴുതി (സ്യൂഡോകോഡ്):

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

തുടർന്ന് എല്ലാ 40 തീയതികളും ശരിയായി പാഴ്‌സ് ചെയ്തു.

വലിയ പ്രിന്റ് ജോലികൾക്ക് നടുവിൽ

1980-കളുടെ തുടക്കത്തിൽ, എന്റെ അച്ഛൻ ഇപ്പോൾ പ്രവർത്തനരഹിതമായ ഒരു ഡിവിഷനായ സ്റ്റോറേജ് ടെക്നോളജിയിൽ ജോലി ചെയ്തു, അത് അതിവേഗ ടേപ്പ് ഫീഡിംഗിനായി ടേപ്പ് ഡ്രൈവുകളും ന്യൂമാറ്റിക് സിസ്റ്റങ്ങളും സൃഷ്ടിച്ചു.

അവർ ഡ്രൈവുകൾ പുനർരൂപകൽപ്പന ചെയ്‌തു, അതിലൂടെ അവർക്ക് ഏഴ് "ബി" ഡ്രൈവുകളിലേക്ക് ഒരു സെൻട്രൽ "എ" ഡ്രൈവ് കണക്റ്റുചെയ്‌തു, കൂടാതെ "എ" ഡ്രൈവ് നിയന്ത്രിക്കുന്ന റാമിലെ ചെറിയ ഒഎസിന് എല്ലാ "ബി" ഡ്രൈവുകളിലേക്കും റീഡ് ആൻഡ് റൈറ്റ് പ്രവർത്തനങ്ങൾ നിയോഗിക്കാനാകും.

ഓരോ തവണയും ഡ്രൈവ് "A" ആരംഭിക്കുമ്പോൾ, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അതിന്റെ മെമ്മറിയിലേക്ക് ലോഡുചെയ്യുന്നതിന് "A" ലേക്ക് കണക്റ്റുചെയ്‌തിരിക്കുന്ന പെരിഫറൽ ഡ്രൈവിലേക്ക് ഒരു ഫ്ലോപ്പി ഡിസ്ക് ചേർക്കേണ്ടത് ആവശ്യമാണ്. ഇത് വളരെ പ്രാകൃതമായിരുന്നു: 8-ബിറ്റ് മൈക്രോകൺട്രോളറാണ് കമ്പ്യൂട്ടിംഗ് പവർ നൽകിയത്.

അത്തരം ഉപകരണങ്ങളുടെ ടാർഗെറ്റ് പ്രേക്ഷകർ, വളരെ വലിയ ഡാറ്റ വെയർഹൗസുകളുള്ള കമ്പനികളായിരുന്നു - ബാങ്കുകൾ, റീട്ടെയിൽ ശൃംഖലകൾ മുതലായവ.

ഒരു ഉപഭോക്താവിന് ഒരു പ്രശ്നമുണ്ടായിരുന്നു. ഒരു പ്രിന്റ് ജോലിയുടെ മധ്യത്തിൽ, ഒരു പ്രത്യേക ഡ്രൈവ് "A" പ്രവർത്തിക്കുന്നത് നിർത്തിയേക്കാം, ഇത് മുഴുവൻ ജോലിയും സ്തംഭിപ്പിക്കും. ഡ്രൈവിന്റെ പ്രവർത്തനം പുനഃസ്ഥാപിക്കുന്നതിന്, ജീവനക്കാർക്ക് എല്ലാം റീബൂട്ട് ചെയ്യേണ്ടിവന്നു. ആറ് മണിക്കൂർ ജോലിയുടെ മധ്യത്തിലാണ് ഇത് സംഭവിച്ചതെങ്കിൽ, ഒരു വലിയ തുക ചെലവേറിയ കമ്പ്യൂട്ടർ സമയം നഷ്ടപ്പെടുകയും മുഴുവൻ പ്രവർത്തനത്തിന്റെയും ഷെഡ്യൂൾ തടസ്സപ്പെടുകയും ചെയ്തു.

സ്‌റ്റോറേജ് ടെക്‌നോളജീസിൽ നിന്ന് സാങ്കേതിക വിദഗ്ധരെ അയച്ചു. പക്ഷേ, അവർ എത്ര ശ്രമിച്ചിട്ടും, പരീക്ഷണ സാഹചര്യങ്ങളിൽ ബഗ് പുനർനിർമ്മിക്കാൻ അവർക്ക് കഴിഞ്ഞില്ല: വലിയ അച്ചടി ജോലികൾക്കിടയിൽ ഇത് സംഭവിച്ചതായി തോന്നുന്നു. പ്രശ്നം ഹാർഡ്‌വെയർ ആയിരുന്നില്ല, അവർ തങ്ങളാൽ കഴിയുന്നതെല്ലാം മാറ്റി: റാം, മൈക്രോകൺട്രോളർ, ഫ്ലോപ്പി ഡ്രൈവ്, ടേപ്പ് ഡ്രൈവിന്റെ എല്ലാ സങ്കൽപ്പിക്കാവുന്ന ഭാഗങ്ങളും - പ്രശ്നം തുടർന്നു.

തുടർന്ന് ടെക്നീഷ്യൻമാർ ആസ്ഥാനത്തേക്ക് വിളിച്ച് വിദഗ്ധനെ വിളിച്ചു.

വിദഗ്‌ദ്ധൻ ഒരു കസേരയും ഒരു കപ്പ്‌ കാപ്പിയുമെടുത്ത്‌, കമ്പ്യൂട്ടർ മുറിയിൽ ഇരുന്നു—അക്കാലത്ത്‌ കമ്പ്യൂട്ടറുകൾക്കായി നീക്കിവെച്ച മുറികളുണ്ടായിരുന്നു—ഒരു വലിയ പ്രിന്റ്‌ ജോലിയിൽ ജോലിക്കാർ ക്യൂവിൽ നിൽക്കുന്നത്‌ നോക്കിനിന്നു. ഒരു പരാജയം സംഭവിക്കുന്നതിനായി വിദഗ്ദ്ധൻ കാത്തിരിക്കുകയായിരുന്നു - അത് സംഭവിച്ചു. എല്ലാവരും വിദഗ്ദ്ധനെ നോക്കി, പക്ഷേ എന്തുകൊണ്ടാണ് ഇത് സംഭവിച്ചതെന്ന് അദ്ദേഹത്തിന് അറിയില്ല. അതിനാൽ ജോലി വീണ്ടും ക്യൂവിൽ നിർത്താൻ അദ്ദേഹം ഉത്തരവിട്ടു, എല്ലാ ജീവനക്കാരും സാങ്കേതിക വിദഗ്ധരും ജോലിയിലേക്ക് മടങ്ങി.

വിദഗ്ധൻ വീണ്ടും കസേരയിൽ ഇരുന്നു പരാജയത്തിനായി കാത്തിരിക്കാൻ തുടങ്ങി. ഏകദേശം ആറ് മണിക്കൂർ കഴിഞ്ഞു, പരാജയം സംഭവിച്ചു. ആളുകൾ നിറഞ്ഞ ഒരു മുറിയിലാണ് എല്ലാം നടന്നത് എന്നതൊഴിച്ചാൽ വിദഗ്ദ്ധന് വീണ്ടും ആശയങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല. ദൗത്യം പുനരാരംഭിക്കാൻ അദ്ദേഹം ഉത്തരവിട്ടു, വീണ്ടും ഇരുന്നു കാത്തിരുന്നു.

മൂന്നാമത്തെ പരാജയത്തോടെ, വിദഗ്ദ്ധൻ ഒരു കാര്യം ശ്രദ്ധിച്ചു. ഒരു വിദേശ ഡ്രൈവിൽ ഉദ്യോഗസ്ഥർ ടേപ്പുകൾ മാറ്റിയപ്പോഴാണ് പരാജയം സംഭവിച്ചത്. മാത്രമല്ല, ജീവനക്കാരിലൊരാൾ തറയിലെ ഒരു പ്രത്യേക ടൈലിലൂടെ നടന്നയുടനെ പരാജയം സംഭവിച്ചു.

6 മുതൽ 8 ഇഞ്ച് വരെ ഉയരത്തിൽ പാകിയ അലുമിനിയം ടൈലുകൾ കൊണ്ടാണ് ഉയർത്തിയ തറ. ഒരു പ്രധാന കേബിളിൽ അബദ്ധത്തിൽ ആരും ചവിട്ടുന്നത് തടയാൻ കമ്പ്യൂട്ടറുകളിൽ നിന്നുള്ള നിരവധി വയറുകൾ ഉയർത്തിയ തറയുടെ അടിയിൽ ഓടി. ഉയർത്തിയ തറയുടെ അടിയിൽ അവശിഷ്ടങ്ങൾ കയറാതിരിക്കാൻ ടൈലുകൾ വളരെ ദൃഢമായി നിരത്തി.

ടൈലുകളിലൊന്ന് രൂപഭേദം വരുത്തിയതായി വിദഗ്ധന് മനസ്സിലായി. ഒരു ജീവനക്കാരൻ അതിന്റെ മൂലയിൽ ചവിട്ടിയപ്പോൾ, ടൈലിന്റെ അരികുകൾ അടുത്തുള്ള ടൈലുകളിൽ ഉരഞ്ഞു. ടൈലുകളെ ബന്ധിപ്പിച്ച പ്ലാസ്റ്റിക് ഭാഗങ്ങളും അവ ഉപയോഗിച്ച് തടവി, ഇത് റേഡിയോ ഫ്രീക്വൻസി ഇടപെടൽ സൃഷ്ടിച്ച സ്റ്റാറ്റിക് മൈക്രോ ഡിസ്ചാർജുകൾക്ക് കാരണമായി.

ഇന്ന്, റേഡിയോ ഫ്രീക്വൻസി ഇടപെടലിൽ നിന്ന് റാം കൂടുതൽ മികച്ച രീതിയിൽ സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു. എന്നാൽ ആ വർഷങ്ങളിൽ ഇത് അങ്ങനെയായിരുന്നില്ല. ഈ ഇടപെടൽ മെമ്മറിയെ തടസ്സപ്പെടുത്തുന്നുവെന്ന് വിദഗ്ദ്ധൻ മനസ്സിലാക്കി, അതോടൊപ്പം ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ പ്രവർത്തനവും. അവൻ പിന്തുണാ സേവനത്തെ വിളിച്ചു, പുതിയ ടൈലുകൾ ഓർഡർ ചെയ്തു, അവ സ്വയം ഇൻസ്റ്റാൾ ചെയ്തു, പ്രശ്നം അപ്രത്യക്ഷമായി.

ഇത് ഉയർന്ന വേലിയേറ്റമാണ്!

പോർട്ട്‌സ്‌മൗത്തിലെ (ഞാൻ കരുതുന്നു) ഡോക്ക് ഏരിയയിലെ ഒരു ഓഫീസിന്റെ നാലാമത്തെയോ അഞ്ചാമത്തെയോ നിലയിലുള്ള ഒരു സെർവർ റൂമിലാണ് കഥ നടന്നത്.

ഒരു ദിവസം പ്രധാന ഡാറ്റാബേസുള്ള യുണിക്സ് സെർവർ തകരാറിലായി. അവർ അവനെ റീബൂട്ട് ചെയ്തു, പക്ഷേ അവൻ സന്തോഷത്തോടെ വീണ്ടും വീണ്ടും വീഴുന്നത് തുടർന്നു. പിന്തുണാ സേവനത്തിൽ നിന്ന് ആരെയെങ്കിലും വിളിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

സപ്പോർട്ട് പയ്യൻ... അവന്റെ പേര് മാർക്ക് എന്നാണെന്ന് ഞാൻ കരുതുന്നു, പക്ഷേ അത് സാരമില്ല... എനിക്ക് അവനെ അറിയാമെന്ന് ഞാൻ കരുതുന്നില്ല. സാരമില്ല, ശരിക്കും. നമുക്ക് മാർക്കിനൊപ്പം നിൽക്കാം, ശരി? കൊള്ളാം.

അതിനാൽ, കുറച്ച് മണിക്കൂറുകൾക്ക് ശേഷം മാർക്ക് എത്തി (ഇത് ലീഡ്സിൽ നിന്ന് പോർട്സ്മൗത്തിലേക്ക് വളരെ ദൂരെയല്ല, നിങ്ങൾക്കറിയാമോ), സെർവർ ഓണാക്കി, എല്ലാം പ്രശ്നങ്ങളില്ലാതെ പ്രവർത്തിച്ചു. സാധാരണ പിന്തുണ, ക്ലയന്റ് ഇതിനെക്കുറിച്ച് വളരെ അസ്വസ്ഥനാകും. മാർക്ക് ലോഗ് ഫയലുകളിലൂടെ നോക്കുന്നു, അനിഷ്ടകരമായ ഒന്നും കണ്ടെത്തുന്നില്ല. അങ്ങനെ മാർക്ക് ട്രെയിനിൽ തിരിച്ചെത്തി (അല്ലെങ്കിൽ അവൻ വന്ന ഗതാഗത മാർഗ്ഗം എന്തായാലും, എനിക്കറിയാവുന്ന എല്ലാവർക്കും അത് ഒരു മുടന്തൻ പശുവായിരിക്കാം... എന്തായാലും, അത് പ്രശ്നമല്ല, ശരിയാണോ?) പാഴാക്കി ലീഡ്സിലേക്ക് മടങ്ങുന്നു. ദിവസം.

അന്ന് വൈകുന്നേരം വീണ്ടും സെർവർ തകരാറിലായി. കഥയും അതുതന്നെ... സർവർ ഉയരുന്നില്ല. മാർക്ക് വിദൂരമായി സഹായിക്കാൻ ശ്രമിക്കുന്നു, പക്ഷേ ക്ലയന്റിന് സെർവർ ആരംഭിക്കാൻ കഴിയില്ല.

മറ്റൊരു ട്രെയിൻ, ബസ്, നാരങ്ങ മെറിംഗു അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും ക്രാപ്പ്, മാർക്ക് പോർട്ട്സ്മൗത്തിൽ തിരിച്ചെത്തി. നോക്കൂ, പ്രശ്‌നങ്ങളൊന്നുമില്ലാതെ സെർവർ ബൂട്ട് ചെയ്യുന്നു! അത്ഭുതം. ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലോ സോഫ്‌റ്റ്‌വെയറിലോ എല്ലാം ക്രമത്തിലാണോ എന്ന് പരിശോധിക്കാൻ മാർക്ക് നിരവധി മണിക്കൂറുകൾ ചെലവഴിക്കുകയും ലീഡ്‌സിലേക്ക് പുറപ്പെടുകയും ചെയ്യുന്നു.

പകലിന്റെ മധ്യത്തോടെ സെർവർ തകരാറിലാകുന്നു (എളുപ്പമെടുക്കൂ!). ഇത്തവണ സെർവറിന് പകരമായി ഹാർഡ്‌വെയർ പിന്തുണയുള്ള ആളുകളെ കൊണ്ടുവരുന്നത് ന്യായമാണെന്ന് തോന്നുന്നു. എന്നാൽ ഇല്ല, ഏകദേശം 10 മണിക്കൂറിന് ശേഷം അതും വീഴുന്നു.

കുറേ ദിവസങ്ങളായി സ്ഥിതി ആവർത്തിച്ചു. സെർവർ പ്രവർത്തിക്കുന്നു, ഏകദേശം 10 മണിക്കൂറിന് ശേഷം തകരാറിലാകുന്നു, അടുത്ത 2 മണിക്കൂറിനുള്ളിൽ ആരംഭിക്കുന്നില്ല. അവർ തണുപ്പിക്കൽ, മെമ്മറി ലീക്ക് എന്നിവ പരിശോധിച്ചു, അവർ എല്ലാം പരിശോധിച്ചു, പക്ഷേ ഒന്നും കണ്ടെത്തിയില്ല. തുടർന്ന് അപകടങ്ങൾ നിലച്ചു.

ആ ആഴ്ച്ച അലക്ഷ്യമായി കടന്നുപോയി... എല്ലാവരും സന്തോഷത്തിലായിരുന്നു. എല്ലാം വീണ്ടും ആരംഭിക്കുന്നത് വരെ സന്തോഷം. ചിത്രവും അങ്ങനെ തന്നെ. 10 മണിക്കൂർ ജോലി, 2-3 മണിക്കൂർ പ്രവർത്തനരഹിതമായ സമയം...

എന്നിട്ട് ഒരാൾ (ഈ വ്യക്തിക്ക് ഐടിയുമായി ഒരു ബന്ധവുമില്ലെന്ന് അവർ എന്നോട് പറഞ്ഞതായി ഞാൻ കരുതുന്നു) പറഞ്ഞു:

"ഇത് വേലിയേറ്റമാണ്!"

ആശ്ചര്യചിഹ്നം ശൂന്യമായ തുറിച്ചുനോട്ടങ്ങളോടെയാണ് കണ്ടത്, സുരക്ഷാ കോൾ ബട്ടണിൽ ആരുടെയെങ്കിലും കൈ മടിച്ചിരിക്കാം.

"ഇത് വേലിയേറ്റത്തിൽ പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു."

കാപ്പി കുടിക്കാൻ ഇരിക്കുമ്പോൾ ടൈഡ് ഇയർബുക്ക് വായിക്കാൻ സാധ്യതയില്ലാത്ത ഐടി പിന്തുണയുള്ള തൊഴിലാളികൾക്ക് ഇത് തികച്ചും വിദേശ ആശയമായി തോന്നും. ഒരാഴ്ചയായി സെർവർ തകരാറില്ലാതെ പ്രവർത്തിക്കുന്നതിനാൽ ഇത് വേലിയേറ്റവുമായി ഒരു തരത്തിലും ബന്ധപ്പെടുത്താൻ കഴിയില്ലെന്ന് അവർ വിശദീകരിച്ചു.

"കഴിഞ്ഞ ആഴ്ച വേലിയേറ്റം കുറവായിരുന്നു, എന്നാൽ ഈ ആഴ്ച അത് ഉയർന്നതാണ്."

യാച്ച് ലൈസൻസ് ഇല്ലാത്തവർക്കായി ഒരു ചെറിയ പദപ്രയോഗം. വേലിയേറ്റങ്ങൾ ചന്ദ്രചക്രത്തെ ആശ്രയിച്ചിരിക്കുന്നു. ഭൂമി കറങ്ങുമ്പോൾ, ഓരോ 12,5 മണിക്കൂറിലും സൂര്യന്റെയും ചന്ദ്രന്റെയും ഗുരുത്വാകർഷണം ഒരു വേലിയേറ്റ തരംഗം സൃഷ്ടിക്കുന്നു. 12,5 മണിക്കൂർ സൈക്കിളിന്റെ തുടക്കത്തിൽ ഉയർന്ന വേലിയേറ്റമുണ്ട്, സൈക്കിളിന്റെ മധ്യത്തിൽ ഒരു വേലിയേറ്റമുണ്ട്, അവസാനം വീണ്ടും ഉയർന്ന വേലിയേറ്റമുണ്ട്. എന്നാൽ ചന്ദ്രന്റെ ഭ്രമണപഥം മാറുന്നതിനനുസരിച്ച് താഴ്ന്നതും ഉയർന്ന വേലിയേറ്റവും തമ്മിലുള്ള വ്യത്യാസവും മാറുന്നു. ചന്ദ്രൻ സൂര്യനും ഭൂമിക്കും ഇടയിലോ ഭൂമിയുടെ എതിർ വശത്തോ ആയിരിക്കുമ്പോൾ (പൂർണ്ണ ചന്ദ്രൻ അല്ലെങ്കിൽ ചന്ദ്രനില്ല), നമുക്ക് സിസിജിൻ വേലിയേറ്റങ്ങൾ ലഭിക്കും - ഏറ്റവും ഉയർന്ന വേലിയേറ്റവും താഴ്ന്ന വേലിയേറ്റവും. അർദ്ധ ചന്ദ്രനിൽ നമുക്ക് ക്വാഡ്രേച്ചർ ടൈഡുകൾ ലഭിക്കും - ഏറ്റവും താഴ്ന്ന വേലിയേറ്റങ്ങൾ. രണ്ട് തീവ്രതകൾ തമ്മിലുള്ള വ്യത്യാസം വളരെ കുറയുന്നു. ചാന്ദ്ര ചക്രം 28 ദിവസം നീണ്ടുനിൽക്കും: സിജിജിയൻ - ക്വാഡ്രേച്ചർ - സിജിജിയൻ - ക്വാഡ്രേച്ചർ.

വേലിയേറ്റ ശക്തികളുടെ സാരാംശം സാങ്കേതിക വിദഗ്ധർക്ക് വിശദീകരിച്ചപ്പോൾ, പോലീസിനെ വിളിക്കേണ്ടതുണ്ടെന്ന് അവർ കരുതി. കൂടാതെ തികച്ചും യുക്തിസഹവും. പക്ഷേ ആ ചേട്ടൻ പറഞ്ഞത് ശരിയാണെന്ന് തെളിഞ്ഞു. രണ്ടാഴ്ച മുമ്പ്, ഓഫീസിൽ നിന്ന് വളരെ അകലെയല്ലാതെ ഒരു ഡിസ്ട്രോയർ കെട്ടിയിരുന്നു. ഓരോ തവണയും വേലിയേറ്റം അതിനെ ഒരു നിശ്ചിത ഉയരത്തിലേക്ക് ഉയർത്തുമ്പോൾ, കപ്പലിന്റെ റഡാർ പോസ്റ്റ് സെർവർ റൂം തറയുടെ തലത്തിൽ അവസാനിച്ചു. റഡാർ (അല്ലെങ്കിൽ ഇലക്ട്രോണിക് യുദ്ധോപകരണങ്ങൾ അല്ലെങ്കിൽ മറ്റേതെങ്കിലും സൈനിക കളിപ്പാട്ടം) കമ്പ്യൂട്ടറുകളിൽ കുഴപ്പങ്ങൾ സൃഷ്ടിച്ചു.

റോക്കറ്റിനായുള്ള ഫ്ലൈറ്റ് മിഷൻ

ഒരു വലിയ (ഏകദേശം 400 ആയിരം ലൈനുകൾ) റോക്കറ്റ് ലോഞ്ച് കൺട്രോൾ, മോണിറ്ററിംഗ് സിസ്റ്റം എന്നിവ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ പുതിയ പതിപ്പുകളിലേക്കും കമ്പൈലറിലേക്കും ഭാഷയിലേക്കും പോർട്ട് ചെയ്യാൻ എന്നെ ചുമതലപ്പെടുത്തി. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, സോളാരിസ് 2.5.1 മുതൽ സോളാരിസ് 7 വരെയും, അഡ 83-ൽ എഴുതിയ വെർഡിക്സ് അഡ ഡെവലപ്‌മെന്റ് സിസ്റ്റം (VADS) മുതൽ, Ada 95-ൽ എഴുതിയ Rational Apex Ada സിസ്റ്റം വരെയും. VADS വാങ്ങിയത് Rational ആണ്, അതിന്റെ ഉൽപ്പന്നം കാലഹരണപ്പെട്ടതാണ്, എന്നിരുന്നാലും അപെക്സ് കംപൈലറിലേക്കുള്ള മാറ്റം എളുപ്പമാക്കുന്നതിന് VADS-നിർദ്ദിഷ്ട പാക്കേജുകളുടെ അനുയോജ്യമായ പതിപ്പുകൾ നടപ്പിലാക്കാൻ Rational ശ്രമിച്ചു.

കോഡ് വൃത്തിയായി കംപൈൽ ചെയ്യാൻ മൂന്ന് പേർ എന്നെ സഹായിച്ചു. രണ്ടാഴ്ചയെടുത്തു. പിന്നെ, സിസ്റ്റം പ്രവർത്തിക്കാൻ ഞാൻ സ്വന്തമായി പ്രവർത്തിച്ചു. ചുരുക്കത്തിൽ, ഞാൻ നേരിട്ട ഒരു സോഫ്റ്റ്വെയർ സിസ്റ്റത്തിന്റെ ഏറ്റവും മോശമായ വാസ്തുവിദ്യയും നടപ്പിലാക്കലും ആയിരുന്നു അത്, അതിനാൽ പോർട്ട് പൂർത്തിയാക്കാൻ രണ്ട് മാസമെടുത്തു. ഈ സംവിധാനം പിന്നീട് പരിശോധനയ്ക്കായി സമർപ്പിച്ചു, ഇതിന് മാസങ്ങൾ കൂടി എടുത്തു. പരിശോധനയ്ക്കിടെ കണ്ടെത്തിയ ബഗുകൾ ഞാൻ ഉടനടി ശരിയാക്കി, പക്ഷേ അവയുടെ എണ്ണം പെട്ടെന്ന് കുറഞ്ഞു (സോഴ്സ് കോഡ് ഒരു പ്രൊഡക്ഷൻ സിസ്റ്റമായിരുന്നു, അതിനാൽ അതിന്റെ പ്രവർത്തനം വളരെ വിശ്വസനീയമായി പ്രവർത്തിച്ചു, പുതിയ കംപൈലറുമായി പൊരുത്തപ്പെടുന്ന സമയത്ത് ഉയർന്നുവന്ന ബഗുകൾ എനിക്ക് നീക്കംചെയ്യേണ്ടിവന്നു). ഒടുവിൽ, എല്ലാം ശരിയായി പ്രവർത്തിച്ചപ്പോൾ, എന്നെ മറ്റൊരു പ്രോജക്റ്റിലേക്ക് മാറ്റി.

താങ്ക്സ്ഗിവിംഗിന് മുമ്പുള്ള വെള്ളിയാഴ്ച, ഫോൺ റിംഗ് ചെയ്തു.

റോക്കറ്റ് വിക്ഷേപണം ഏകദേശം മൂന്നാഴ്ചയ്ക്കുള്ളിൽ പരീക്ഷിക്കപ്പെടേണ്ടതായിരുന്നു, കൗണ്ട്ഡൗണിന്റെ ലബോറട്ടറി പരിശോധനകളിൽ, കമാൻഡുകളുടെ ക്രമം തടഞ്ഞു. യഥാർത്ഥ ജീവിതത്തിൽ, ഇത് പരീക്ഷണം നിർത്തലാക്കും, എഞ്ചിൻ ആരംഭിച്ച് കുറച്ച് നിമിഷങ്ങൾക്കുള്ളിൽ തടസ്സം സംഭവിച്ചാൽ, സഹായ സംവിധാനങ്ങളിൽ മാറ്റാനാവാത്ത നിരവധി പ്രവർത്തനങ്ങൾ സംഭവിക്കും, ഇതിന് റോക്കറ്റിന്റെ ദീർഘവും ചെലവേറിയതുമായ സന്നദ്ധത ആവശ്യമാണ്. ഇത് ആരംഭിക്കുമായിരുന്നില്ല, പക്ഷേ ധാരാളം ആളുകൾ സമയനഷ്ടവും ധാരാളം പണവും നഷ്ടപ്പെടുത്തുന്നതിൽ വളരെയധികം വിഷമിക്കുമായിരുന്നു. ഡിപ്പാർട്ട്‌മെന്റ് ഓഫ് ഡിഫൻസ് പണം അശ്രദ്ധമായി ചെലവഴിക്കുന്നുവെന്ന് നിങ്ങളോട് ആരെയും അറിയിക്കരുത് - ബജറ്റ് ഒന്നാമതോ രണ്ടാമതോ നൽകാത്ത ഒരു കരാർ മാനേജരെ ഞാൻ ഒരിക്കലും കണ്ടിട്ടില്ല.

മുൻ മാസങ്ങളിൽ, ഈ കൗണ്ട്ഡൗൺ ചലഞ്ച് നൂറുകണക്കിന് പ്രാവശ്യം നിരവധി വ്യതിയാനങ്ങളിൽ പ്രവർത്തിപ്പിച്ചിരുന്നു, ചില ചെറിയ തടസ്സങ്ങൾ മാത്രം. അതിനാൽ ഇത് സംഭവിക്കാനുള്ള സാധ്യത വളരെ കുറവായിരുന്നു, പക്ഷേ അതിന്റെ അനന്തരഫലങ്ങൾ വളരെ പ്രാധാന്യമർഹിക്കുന്നതാണ്. ഈ രണ്ട് ഘടകങ്ങളും ഗുണിക്കുക, എനിക്കും ഡസൻ കണക്കിന് എഞ്ചിനീയർമാർക്കും മാനേജർമാർക്കും ഒരു നശിച്ച അവധിക്കാല ആഴ്ചയാണ് വാർത്ത പ്രവചിച്ചതെന്ന് നിങ്ങൾക്ക് മനസ്സിലാകും.

സിസ്റ്റം പോർട്ട് ചെയ്ത വ്യക്തി എന്ന നിലയിൽ എന്നെ ശ്രദ്ധിച്ചു.

മിക്ക സുരക്ഷാ-നിർണ്ണായക സിസ്റ്റങ്ങളേയും പോലെ, ധാരാളം പാരാമീറ്ററുകൾ ലോഗ് ചെയ്‌തിരിക്കുന്നു, അതിനാൽ സിസ്റ്റം ക്രാഷുചെയ്യുന്നതിന് മുമ്പ് എക്സിക്യൂട്ട് ചെയ്ത കോഡിന്റെ കുറച്ച് വരികൾ തിരിച്ചറിയുന്നത് വളരെ എളുപ്പമാണ്. തീർച്ചയായും, അവയിൽ അസ്വാഭാവികമായി ഒന്നുമില്ല; ഒരേ ഓട്ടത്തിനിടയിൽ ഒരേ പദപ്രയോഗങ്ങൾ അക്ഷരാർത്ഥത്തിൽ ആയിരക്കണക്കിന് തവണ വിജയകരമായി നടപ്പിലാക്കിയിട്ടുണ്ട്.

കംപൈലർ വികസിപ്പിച്ചെടുത്തത് അവരായതിനാലും അവർ വികസിപ്പിച്ച ചില ദിനചര്യകളെ സംശയാസ്പദമായ കോഡിൽ വിളിച്ചതിനാലും ഞങ്ങൾ അപെക്സിൽ നിന്നുള്ള ആളുകളെ യുക്തിസഹത്തിലേക്ക് വിളിച്ചു. അക്ഷരാർത്ഥത്തിൽ ദേശീയ പ്രാധാന്യമുള്ള ഒരു പ്രശ്നത്തിന്റെ വേരിലേക്ക് കടക്കേണ്ടതിന്റെ ആവശ്യകതയിൽ അവർ (മറ്റെല്ലാവരും) മതിപ്പുളവാക്കി.

ജേണലുകളിൽ രസകരമായ ഒന്നും ഇല്ലാത്തതിനാൽ, ഒരു പ്രാദേശിക ലബോറട്ടറിയിൽ പ്രശ്നം പുനർനിർമ്മിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. 1000 റണ്ണിന് ഏകദേശം ഒരു തവണ ഇവന്റ് നടന്നതിനാൽ ഇത് അത്ര എളുപ്പമുള്ള കാര്യമായിരുന്നില്ല. ഒരു സംശയാസ്പദമായ കാരണം, വെണ്ടർ വികസിപ്പിച്ച മ്യൂട്ടക്സ് ഫംഗ്ഷനിലേക്കുള്ള ഒരു കോൾ (VADS മൈഗ്രേഷൻ പാക്കേജിന്റെ ഭാഗം) Unlock അൺലോക്കുചെയ്യുന്നതിലേക്ക് നയിച്ചില്ല. ഫംഗ്‌ഷൻ എന്ന് വിളിക്കുന്ന പ്രോസസ്സിംഗ് ത്രെഡ് ഹൃദയമിടിപ്പ് സന്ദേശങ്ങൾ പ്രോസസ്സ് ചെയ്തു, അത് നാമമാത്രമായി ഓരോ സെക്കൻഡിലും എത്തുന്നു. ഞങ്ങൾ ആവൃത്തി 10 Hz ആയി ഉയർത്തി, അതായത്, സെക്കൻഡിൽ 10 തവണ, പ്രവർത്തിക്കാൻ തുടങ്ങി. ഏകദേശം ഒരു മണിക്കൂറിന് ശേഷം സിസ്റ്റം സ്വയം ലോക്ക് ചെയ്തു. ലോഗിൽ, റെക്കോർഡ് ചെയ്ത സന്ദേശങ്ങളുടെ ക്രമം പരാജയപ്പെട്ട ടെസ്റ്റ് സമയത്തിന് തുല്യമാണെന്ന് ഞങ്ങൾ കണ്ടു. ഞങ്ങൾ നിരവധി റൺസ് കൂടി നടത്തി, ആരംഭിച്ച് 45-90 മിനിറ്റിനു ശേഷം സിസ്റ്റം സ്ഥിരമായി തടഞ്ഞു, ഓരോ തവണയും ലോഗിൽ ഒരേ റൂട്ട് അടങ്ങിയിരിക്കുന്നു. ഞങ്ങൾ സാങ്കേതികമായി വ്യത്യസ്‌ത കോഡ് പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിലും - സന്ദേശത്തിന്റെ ആവൃത്തി വ്യത്യസ്തമായിരുന്നു - സിസ്റ്റത്തിന്റെ പെരുമാറ്റം ഒന്നുതന്നെയായിരുന്നു, അതിനാൽ ഈ ലോഡ് സാഹചര്യം സമാന പ്രശ്‌നമുണ്ടാക്കുന്നുവെന്ന് ഞങ്ങൾക്ക് ഉറപ്പുണ്ടായിരുന്നു.

എക്സ്പ്രഷനുകളുടെ ക്രമത്തിൽ എവിടെയാണ് തടയൽ സംഭവിച്ചതെന്ന് ഇപ്പോൾ നമുക്ക് കണ്ടെത്തേണ്ടതുണ്ട്.

സിസ്റ്റത്തിന്റെ ഈ നടപ്പാക്കൽ അഡാ ടാസ്‌ക് സിസ്റ്റം ഉപയോഗിച്ചു, മാത്രമല്ല അത് അവിശ്വസനീയമാംവിധം മോശമായി ഉപയോഗിക്കുകയും ചെയ്തു. ടാസ്‌ക്കുകൾ അഡയിലെ ഉയർന്ന തലത്തിലുള്ള ഒരേസമയം എക്‌സിക്യൂട്ടബിൾ നിർമ്മിതിയാണ്, എക്‌സിക്യൂഷന്റെ ത്രെഡുകൾ പോലെയുള്ള ഒന്ന്, ഭാഷയിൽ തന്നെ നിർമ്മിച്ചതാണ്. രണ്ട് ജോലികൾ ആശയവിനിമയം നടത്തേണ്ടിവരുമ്പോൾ, അവർ "ഒരു കൂടിക്കാഴ്ച സജ്ജമാക്കി", ആവശ്യമായ ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നു, തുടർന്ന് കൂടിക്കാഴ്ച നിർത്തി അവരുടെ സ്വതന്ത്ര നിർവ്വഹണങ്ങളിലേക്ക് മടങ്ങുന്നു. എന്നിരുന്നാലും, സംവിധാനം വ്യത്യസ്തമായി നടപ്പിലാക്കി. ഒരു ടാർഗെറ്റ് ടാസ്‌ക് ഒത്തുചേർന്നതിന് ശേഷം, ആ ടാർഗെറ്റ് ടാസ്‌ക് മറ്റൊരു ടാസ്‌ക്കുമായി കൂടിച്ചേർന്നു, അത് മൂന്നാമത്തെ ടാസ്‌ക്കുമായി ഒത്തുചേരുന്നു, അങ്ങനെ ചില പ്രോസസ്സിംഗ് പൂർത്തിയാകുന്നതുവരെ. ഇതിനുശേഷം, ഈ കൂടിക്കാഴ്ചകളെല്ലാം പൂർത്തിയാക്കി, ഓരോ ജോലിയും അതിന്റെ നിർവ്വഹണത്തിലേക്ക് മടങ്ങേണ്ടി വന്നു. അതായത്, ഇൻപുട്ട് ഡാറ്റയുടെ ഒരു ഭാഗം പ്രോസസ്സ് ചെയ്യുമ്പോൾ മുഴുവൻ "മൾട്ടിടാസ്‌കിംഗ്" പ്രക്രിയയും നിർത്തിയ ലോകത്തിലെ ഏറ്റവും ചെലവേറിയ ഫംഗ്‌ഷൻ കോൾ സിസ്റ്റമാണ് ഞങ്ങൾ കൈകാര്യം ചെയ്യുന്നത്. ഇതിനുമുമ്പ്, ത്രോപുട്ട് വളരെ കുറവായതിനാൽ മാത്രം പ്രശ്നങ്ങളിലേക്ക് നയിച്ചില്ല.

ഞാൻ ഈ ടാസ്‌ക് മെക്കാനിസം വിവരിച്ചു, കാരണം ഒരു കൂടിക്കാഴ്ച അഭ്യർത്ഥിക്കുമ്പോഴോ പൂർത്തിയാകുമെന്ന് പ്രതീക്ഷിക്കുമ്പോഴോ, ഒരു "ടാസ്ക് സ്വിച്ച്" സംഭവിക്കാം. അതായത്, എക്സിക്യൂട്ട് ചെയ്യാൻ തയ്യാറായ മറ്റൊരു ടാസ്ക്ക് പ്രോസസ്സർ പ്രോസസ്സ് ചെയ്യാൻ തുടങ്ങും. ഒരു ടാസ്‌ക് മറ്റൊരു ടാസ്‌ക്കുമായി കൂടിച്ചേരാൻ തയ്യാറാകുമ്പോൾ, തികച്ചും വ്യത്യസ്തമായ ഒരു ടാസ്‌ക് എക്‌സിക്യൂട്ട് ചെയ്യാൻ തുടങ്ങുകയും ഒടുവിൽ ആദ്യ കൂടിക്കാഴ്ചയിലേക്കുള്ള വരുമാനം നിയന്ത്രിക്കുകയും ചെയ്യും. ടാസ്‌ക് മാറുന്നതിന് കാരണമാകുന്ന മറ്റ് ഇവന്റുകൾ സംഭവിക്കാം; അത്തരത്തിലുള്ള ഒരു ഇവന്റ് ഒരു മ്യൂട്ടക്സ് പ്രിന്റിംഗ് അല്ലെങ്കിൽ എക്സിക്യൂട്ട് ചെയ്യൽ പോലെയുള്ള ഒരു സിസ്റ്റം ഫംഗ്ഷനിലേക്കുള്ള കോളാണ്.

ഏത് കോഡിന്റെ വരിയാണ് പ്രശ്‌നമുണ്ടാക്കിയതെന്ന് മനസിലാക്കാൻ, ഒരു ടാസ്‌ക് സ്വിച്ച് ട്രിഗർ ചെയ്യാതെ തന്നെ ഒരു സ്‌റ്റേറ്റ്‌മെന്റുകളുടെ ഒരു ശ്രേണിയിലൂടെ പുരോഗതി രേഖപ്പെടുത്തുന്നതിനുള്ള ഒരു മാർഗം എനിക്ക് കണ്ടെത്തേണ്ടതുണ്ട്, ഇത് ഒരു ക്രാഷ് സംഭവിക്കുന്നത് തടയും. അതുകൊണ്ട് മുതലെടുക്കാൻ കഴിഞ്ഞില്ല Put_Line()I/O പ്രവർത്തനങ്ങൾ നടത്തുന്നത് ഒഴിവാക്കാൻ. എനിക്ക് ഒരു കൌണ്ടർ വേരിയബിളോ സമാനമായ മറ്റെന്തെങ്കിലുമോ സജ്ജീകരിക്കാൻ കഴിയും, എന്നാൽ എനിക്ക് അത് സ്ക്രീനിൽ പ്രദർശിപ്പിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ അതിന്റെ മൂല്യം എനിക്ക് എങ്ങനെ കാണാനാകും?

കൂടാതെ, ലോഗ് പരിശോധിക്കുമ്പോൾ, ഹൃദയമിടിപ്പ് സന്ദേശങ്ങളുടെ പ്രോസസ്സിംഗ് മരവിപ്പിച്ചിട്ടും, പ്രക്രിയയുടെ എല്ലാ I/O പ്രവർത്തനങ്ങളെയും തടയുകയും മറ്റ് പ്രോസസ്സിംഗ് നടത്തുന്നത് തടയുകയും ചെയ്തിട്ടും, മറ്റ് സ്വതന്ത്ര ജോലികൾ തുടർന്നുകൊണ്ടിരുന്നു. അതായത്, ജോലി പൂർണ്ണമായും തടഞ്ഞില്ല, ഒരു (നിർണ്ണായക) ജോലികളുടെ ഒരു ശൃംഖല മാത്രം.

തടയൽ പദപ്രയോഗം വിലയിരുത്താൻ ആവശ്യമായ സൂചന ഇതായിരുന്നു.

ഞാൻ ഒരു അഡാ പാക്കേജ് ഉണ്ടാക്കി, അതിൽ ഒരു ടാസ്‌ക്, ഒരു എണ്ണപ്പെട്ട തരം, ആ തരത്തിലുള്ള ഒരു ആഗോള വേരിയബിൾ എന്നിവ അടങ്ങിയിരിക്കുന്നു. എണ്ണിയാലൊടുങ്ങാത്ത അക്ഷരങ്ങൾ പ്രശ്നകരമായ ശ്രേണിയുടെ പ്രത്യേക പദപ്രയോഗങ്ങളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു (ഉദാ. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), തുടർന്ന് അതിൽ അസൈൻമെന്റ് എക്സ്പ്രഷനുകൾ ചേർത്തു, അത് ഒരു ഗ്ലോബൽ വേരിയബിളിലേക്ക് അനുബന്ധ എണ്ണൽ നൽകി. ഇതിന്റെയെല്ലാം ഒബ്‌ജക്റ്റ് കോഡ് മെമ്മറിയിൽ ഒരു സ്ഥിരാങ്കം സംഭരിച്ചിരിക്കുന്നതിനാൽ, അതിന്റെ നിർവ്വഹണത്തിന്റെ ഫലമായി ടാസ്‌ക് സ്വിച്ചിംഗ് തീരെ സാധ്യതയില്ല. ടാസ്‌ക് സ്വിച്ചുചെയ്യാൻ കഴിയുന്ന എക്‌സ്‌പ്രഷനുകളെക്കുറിച്ച് ഞങ്ങൾക്ക് പ്രാഥമികമായി സംശയമുണ്ടായിരുന്നു, കാരണം ടാസ്‌ക് തിരികെ മാറ്റുമ്പോൾ (പല കാരണങ്ങളാൽ) മടങ്ങുന്നതിന് പകരം നിർവ്വഹണത്തിലാണ് തടയൽ സംഭവിച്ചത്.

ട്രാക്കിംഗ് ടാസ്‌ക് ഒരു ലൂപ്പിൽ പ്രവർത്തിക്കുകയും ആഗോള വേരിയബിളിന്റെ മൂല്യം മാറിയിട്ടുണ്ടോ എന്ന് ഇടയ്‌ക്കിടെ പരിശോധിക്കുകയും ചെയ്തു. ഓരോ മാറ്റത്തിലും, മൂല്യം ഒരു ഫയലിലേക്ക് സംരക്ഷിച്ചു. പിന്നെ ഒരു ചെറിയ കാത്തിരിപ്പും പുതിയ പരിശോധനയും. ഞാൻ ഫയലിലേക്ക് വേരിയബിൾ എഴുതി, കാരണം പ്രശ്നം ഏരിയയിൽ ടാസ്ക്ക് സ്വിച്ച് ചെയ്യുമ്പോൾ സിസ്റ്റം എക്സിക്യൂഷനു വേണ്ടി തിരഞ്ഞെടുത്തപ്പോൾ മാത്രം ടാസ്ക് എക്സിക്യൂട്ട് ചെയ്തു. ഈ ടാസ്ക്കിൽ എന്ത് സംഭവിച്ചാലും, ബന്ധമില്ലാത്ത ബ്ലോക്ക് ചെയ്ത മറ്റ് ജോലികളെ ബാധിക്കില്ല.

പ്രശ്‌നകരമായ കോഡ് എക്‌സിക്യൂട്ട് ചെയ്യുന്ന ഘട്ടത്തിൽ സിസ്റ്റം എത്തുമ്പോൾ, ഓരോ അടുത്ത എക്‌സ്‌പ്രഷനിലേക്കും നീങ്ങുമ്പോൾ ഗ്ലോബൽ വേരിയബിൾ പുനഃസജ്ജമാക്കപ്പെടുമെന്ന് പ്രതീക്ഷിച്ചിരുന്നു. ടാസ്‌ക് മാറുന്നതിന് കാരണമാകുന്ന എന്തെങ്കിലും സംഭവിക്കും, അതിന്റെ എക്‌സിക്യൂഷൻ ഫ്രീക്വൻസി (10 ഹെർട്‌സ്) മോണിറ്ററിംഗ് ടാസ്‌ക്കിനേക്കാൾ കുറവായതിനാൽ, മോണിറ്ററിന് ആഗോള വേരിയബിളിന്റെ മൂല്യം പിടിച്ചെടുക്കാനും അത് എഴുതാനും കഴിയും. ഒരു സാധാരണ സാഹചര്യത്തിൽ, എനിക്ക് ഒരു ഉപവിഭാഗത്തിന്റെ ഒരു ആവർത്തന ക്രമം ലഭിക്കും: ടാസ്‌ക് മാറുന്ന സമയത്ത് വേരിയബിളിന്റെ അവസാന മൂല്യങ്ങൾ. തൂക്കിക്കൊല്ലുമ്പോൾ, ആഗോള വേരിയബിൾ ഇനി മാറരുത്, കൂടാതെ അവസാനമായി എഴുതിയ മൂല്യം ഏത് പദപ്രയോഗം പൂർത്തിയാകാത്തതിനെ സൂചിപ്പിക്കും.

ഞാൻ ട്രാക്കിംഗ് ഉപയോഗിച്ച് കോഡ് പ്രവർത്തിപ്പിച്ചു. അവൻ മരവിച്ചു. നിരീക്ഷണം ക്ലോക്ക് വർക്ക് പോലെ പ്രവർത്തിച്ചു.

ലോഗിൽ പ്രതീക്ഷിച്ച ക്രമം അടങ്ങിയിരിക്കുന്നു, ഒരു മ്യൂടെക്‌സ് വിളിക്കപ്പെട്ടുവെന്ന് സൂചിപ്പിക്കുന്ന ഒരു മൂല്യം തടസ്സപ്പെടുത്തി Unlock, കൂടാതെ ടാസ്ക് പൂർത്തിയായിട്ടില്ല - ആയിരക്കണക്കിന് മുൻ കോളുകളുടെ കാര്യത്തിലെന്നപോലെ.

അപെക്സ് എഞ്ചിനീയർമാർ ഈ സമയത്ത് അവരുടെ കോഡ് ജ്വരമായി വിശകലനം ചെയ്യുകയായിരുന്നു, സൈദ്ധാന്തികമായി, ഒരു ലോക്ക് സംഭവിക്കാൻ സാധ്യതയുള്ള ഒരു സ്ഥലം മ്യൂട്ടക്സിൽ കണ്ടെത്തി. എന്നാൽ അതിന്റെ സാധ്യത വളരെ കുറവായിരുന്നു, കാരണം ഒരു നിശ്ചിത സമയത്ത് സംഭവിക്കുന്ന സംഭവങ്ങളുടെ ഒരു നിശ്ചിത ക്രമം മാത്രമേ തടയുന്നതിലേക്ക് നയിക്കൂ. മർഫിയുടെ നിയമം, സുഹൃത്തുക്കളേ, ഇത് മർഫിയുടെ നിയമമാണ്.

എനിക്ക് ആവശ്യമായ കോഡിന്റെ ഭാഗം പരിരക്ഷിക്കുന്നതിന്, ആ ഭാഗത്തേക്കുള്ള മ്യൂട്ടക്സ് ആക്‌സസ് നിയന്ത്രിക്കുന്നതിന് മ്യൂട്ടക്സ് ഫംഗ്‌ഷൻ കോളുകൾ (OS മ്യൂട്ടക്സ് ഫംഗ്‌ഷണാലിറ്റിയുടെ മുകളിൽ നിർമ്മിച്ചത്) ഒരു ചെറിയ നേറ്റീവ് Ada mutex പാക്കേജ് ഉപയോഗിച്ച് ഞാൻ മാറ്റി.

ഞാൻ അത് കോഡിലേക്ക് തിരുകുകയും ടെസ്റ്റ് നടത്തുകയും ചെയ്തു. ഏഴു മണിക്കൂർ കഴിഞ്ഞിട്ടും കോഡ് പ്രവർത്തിച്ചു.

എന്റെ കോഡ് യുക്തിസഹമായി സമർപ്പിച്ചു, അവിടെ അവർ അത് സമാഹരിച്ചു, വേർപെടുത്തി, പ്രശ്നമുള്ള മ്യൂട്ടക്സ് ഫംഗ്ഷനുകളിൽ ഉപയോഗിച്ച അതേ സമീപനം ഇത് ഉപയോഗിക്കുന്നില്ലെന്ന് പരിശോധിച്ചു.

എന്റെ കരിയറിലെ ഏറ്റവും തിരക്കേറിയ കോഡ് അവലോകനം ഇതായിരുന്നു 🙂 എന്റെ കൂടെ റൂമിൽ പത്തോളം എഞ്ചിനീയർമാരും മാനേജർമാരും ഉണ്ടായിരുന്നു, മറ്റൊരു പത്ത് പേർ ഒരു കോൺഫറൻസ് കോളിൽ ഉണ്ടായിരുന്നു - അവരെല്ലാം ഏകദേശം 20 ലൈനുകൾ കോഡ് പരിശോധിച്ചു.

കോഡ് അവലോകനം ചെയ്തു, പുതിയ എക്സിക്യൂട്ടബിൾ ഫയലുകൾ കൂട്ടിച്ചേർക്കുകയും ഔപചാരികമായ റിഗ്രഷൻ ടെസ്റ്റിംഗിനായി സമർപ്പിക്കുകയും ചെയ്തു. ഏതാനും ആഴ്ചകൾക്കുശേഷം, കൗണ്ട്ഡൗൺ പരീക്ഷണം വിജയിക്കുകയും റോക്കറ്റ് പറന്നുയരുകയും ചെയ്തു.

ശരി, എല്ലാം നന്നായി, പക്ഷേ കഥയുടെ അർത്ഥമെന്താണ്?

തികച്ചും വെറുപ്പുളവാക്കുന്ന ഒരു പ്രശ്നമായിരുന്നു അത്. ലക്ഷക്കണക്കിന് വരി കോഡ്, സമാന്തര നിർവ്വഹണം, ഒരു ഡസനിലധികം ഇന്ററാക്ടിംഗ് പ്രക്രിയകൾ, മോശം വാസ്തുവിദ്യയും മോശം നിർവ്വഹണവും, എംബഡഡ് സിസ്റ്റങ്ങൾക്കുള്ള ഇന്റർഫേസുകളും ദശലക്ഷക്കണക്കിന് ഡോളറുകളും ചെലവഴിച്ചു. സമ്മർദ്ദമില്ല, ശരിയാണ്.

പോർട്ടിംഗ് ചെയ്യുന്നതിനാൽ ഞാൻ ശ്രദ്ധയിൽപ്പെട്ടിരുന്നെങ്കിലും, ഈ പ്രശ്നത്തിൽ ഞാൻ മാത്രം പ്രവർത്തിച്ചിരുന്നില്ല. പക്ഷേ, ഞാൻ അത് ചെയ്‌തെങ്കിലും, ലക്ഷക്കണക്കിന് കോഡിന്റെ എല്ലാ വരികളും ഞാൻ മനസ്സിലാക്കി എന്നോ അവ ഒഴിവാക്കിയെന്നോ അർത്ഥമാക്കുന്നില്ല. കോഡും ലോഗുകളും രാജ്യത്തുടനീളമുള്ള എഞ്ചിനീയർമാർ വിശകലനം ചെയ്തു, പക്ഷേ പരാജയത്തിന്റെ കാരണങ്ങളെക്കുറിച്ചുള്ള അവരുടെ അനുമാനങ്ങൾ എന്നോട് പറഞ്ഞപ്പോൾ, അവ നിരസിക്കാൻ എനിക്ക് അര മിനിറ്റ് മാത്രമേ എടുത്തുള്ളൂ. സിദ്ധാന്തങ്ങൾ വിശകലനം ചെയ്യാൻ എന്നോട് ആവശ്യപ്പെട്ടപ്പോൾ, ഞാൻ അത് മറ്റൊരാൾക്ക് കൈമാറും, കാരണം ഈ എഞ്ചിനീയർമാർ തെറ്റായ വഴിയിലാണ് പോകുന്നത് എന്ന് എനിക്ക് വ്യക്തമായിരുന്നു. ധാർഷ്ട്യമെന്നു തോന്നുന്നുണ്ടോ? അതെ, ഇത് ശരിയാണ്, പക്ഷേ മറ്റൊരു കാരണത്താൽ ഞാൻ അനുമാനങ്ങളും അഭ്യർത്ഥനകളും നിരസിച്ചു.

പ്രശ്നത്തിന്റെ സ്വഭാവം എനിക്ക് മനസ്സിലായി. ഇത് എവിടെയാണ് സംഭവിക്കുന്നതെന്നോ എന്തിനാണെന്നോ എനിക്ക് കൃത്യമായി അറിയില്ല, പക്ഷേ എന്താണ് സംഭവിക്കുന്നതെന്ന് എനിക്കറിയാം.

വർഷങ്ങളായി, ഞാൻ ധാരാളം അറിവും അനുഭവവും ശേഖരിച്ചു. അഡ ഉപയോഗിക്കുന്നതിന്റെ തുടക്കക്കാരിൽ ഒരാളാണ് ഞാൻ, അതിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും മനസ്സിലാക്കി. Ada റൺടൈം ലൈബ്രറികൾ എങ്ങനെയാണ് ടാസ്‌ക്കുകൾ കൈകാര്യം ചെയ്യുന്നതെന്നും സമാന്തര എക്‌സിക്യൂഷൻ കൈകാര്യം ചെയ്യുന്നതെന്നും എനിക്കറിയാം. മെമ്മറി, രജിസ്റ്ററുകൾ, അസംബ്ലർ എന്നിവയുടെ തലത്തിൽ താഴ്ന്ന നിലയിലുള്ള പ്രോഗ്രാമിംഗ് ഞാൻ മനസ്സിലാക്കുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, എനിക്ക് എന്റെ മേഖലയിൽ ആഴത്തിലുള്ള അറിവുണ്ട്. പ്രശ്‌നത്തിന്റെ കാരണം കണ്ടെത്താൻ ഞാൻ അവ ഉപയോഗിച്ചു. ഞാൻ ബഗിനെ ചുറ്റിപ്പറ്റി മാത്രം പ്രവർത്തിച്ചില്ല, വളരെ സെൻസിറ്റീവ് റൺടൈം പരിതസ്ഥിതിയിൽ ഇത് എങ്ങനെ കണ്ടെത്താമെന്ന് ഞാൻ മനസ്സിലാക്കി.

അത്തരമൊരു സമരത്തിന്റെ സവിശേഷതകളും അവസ്ഥകളും പരിചയമില്ലാത്തവർക്ക് കോഡുമായുള്ള പോരാട്ടത്തിന്റെ അത്തരം കഥകൾ വളരെ രസകരമല്ല. എന്നാൽ ശരിക്കും ബുദ്ധിമുട്ടുള്ള പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ എന്താണ് വേണ്ടതെന്ന് മനസ്സിലാക്കാൻ ഈ കഥകൾ നമ്മെ സഹായിക്കുന്നു.

ശരിക്കും ബുദ്ധിമുട്ടുള്ള പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന്, നിങ്ങൾ ഒരു പ്രോഗ്രാമർ മാത്രമല്ല. കോഡിന്റെ "വിധി" നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്, അത് പരിസ്ഥിതിയുമായി എങ്ങനെ ഇടപഴകുന്നു, പരിസ്ഥിതി തന്നെ എങ്ങനെ പ്രവർത്തിക്കുന്നു.

അപ്പോൾ നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം നശിച്ച അവധി ആഴ്ച ഉണ്ടാകും.

തുടരേണ്ടത്.

അവലംബം: www.habr.com