Dolgok, amikről a programozók azt hiszik, hogy tudják, de tévednek
Nap mint nap rendszereket építünk, amik legtöbbször felhasználók elé kerülnek. Életünk során akár felhasználóként, akár fejlesztőként egy csomó dolgot megtapasztalunk, amikből azután általánosítunk és alapul vesszük a szoftverfejlesztéshez. Néha fel sem merül bennünk, hogy valami nem úgy van, mint ahogyan 20 éve hisszük. Összegyűjtöttem néhány tényt, illetve igyekszem életszerű példákkal szemléltetni, hogy ez mikor nincs így.
Tévhit: Az e-mail címben mindig van legalább egy pont
Az egész a domain nevek miatt van. Jellemzően kéttagú domain névvel szoktunk találkozni: office.com, ritkábban hárommal: outlook.office.com, de olyannal, amiben csak egy van (tehát a TLD = Top Level Domain része), szinte soha. Pedig nemcsak, hogy léteznek, van, amelyiken weboldal is van, sőt, még e-mail-t is tudnak rajta fogadni! Bár a világ piacvezető böngészője (chrome) nem képes megküzdeni vele, a http://ai/ például probléma nélkül bejön Firefoxban vagy w3m-ben.
Mivel az e-mail címek usernév@domain formában léteznek, a két dolog együttállásából következik, hogy a root@ai egy valós cím, amire minden szabványkövető levelezőprogrammal lehetőségünk van üzenetet küldeni.
Statisztikailag egyébként ma összesen 1480 top level domain (elsőszintű domain) van, ebből 1329 használja a latin ABC betűit (mert, meglepetés: vannak arab, kínai, koreai, stb TLD-k is!), ebből 10-hez tartozik IP cím (ai, arab, cm, music, pn, store, tk, uz, work, ws), 14-hez pedig e-mail kezelő (ai, cf, gp, gt, hr, km, lk, mq, pa, ph, sr, tt, ua, ws) és összesen 3 esetén jön be valóban egy weboldal (ai, pn, uz).
Ritka? Az. Szabványos? Kétség kívül. De tekintve, hogy a legtöbbünk által használt böngészőnek beletörik a bicskája, vajon hány e-mail küldő szoftver nem engedi egyáltalán elküldeni sem a levelet, ha a címben nincs legalább egy pont? Tippre 50%.
Tévhit: Minden embernek van neve
Tegyük félre azt az esetet, hogy a névvel nem rendelkező emberek weboldalakra akarnak regisztrálni és közelítsük meg onnan, hogy egy egyszerű családfát akarunk összerakni. Léteznek kisebb népcsoportok, törzsek, ahol egymásra nem névvel, hanem rokoni viszonnyal hivatkoznak, például "a bátyám legidősebb fia".
Érdekes kisszínes az is, hogy miért alakultak ki családnevek a történelem során. Mivel kicsi volt a népsűrűség, kis közösségek voltak, a keresztnév tökéletesen elegendő volt az egymásra hivatkozás során. Azután megteremtették az adóhivatalt, akinek fogalma nem volt, hogy a Pista a harmadik utcából ugyanaz-e, mint a Pista, a falu kovácsa, így formálissá vált a családnév (például foglalkozás alapon, de sok más is előfordult).
Tévhit: A házszám csak arab számokat tartalmazhat
Erre Magyarországon is nagyon könnyű példát lelni, minden bizonnyal találkoztál már a "Fő utca 2/A"-val vagy a "Teve utca 4-6"-tal. Mindegyik érvényes postai cím, éppencsak a számokon kívül betűket vagy jeleket is tartalmaz.
Tévhit: az autóknak négy kerekük van
Noha a wikipedia idevágó oldala (https://en.wikipedia.org/wiki/Three-wheeler) számos példát vonultat fel, a valóságban relatív ritkán találkozunk ilyen járművekkel. Mindenesetre, ha felni- vagy gumikereskedést tervezel, nem árt számolni azzal a lehetőséggel, hogy a "szett" nem feltétlenül 4 darabból áll.
Tévhit: 0.1 + 0.2 = 0.3
A számítógépek csak bináris alapon tudnak működni (na ez vajon tévhit?). Minden egyéb reprezentáció ezen kell, hogy alapuljon, legyen szó akár szövegről (pl. az "A" betű az ASCII kódtábla szerint binárisan 1000001), egész számokról (a 29-es érték binárisan 11101) vagy törtekről. A tört számokat ún. "lebegőpontos" (floating point) módon tároljuk és számolunk vele. A két világ közötti átjáráskor bizonyos hibák fordulhatnak elő, mint a fent említett példában is, ugyanis a
0.1 + 0.2 = 0.30000000000000004
De nem minden programnyelven és eszközben! Ez a weboldal a fent említett problémának szenteli a lényegét: https://0.30000000000000004.com/
Tévhit: Bármilyen néven elmentheted a fájljaidat
A fájlnevezéktannak egyébként rengeteg aspektusa van, hogy milyen karaktereket tartalmazhat, milyen hosszú lehet, milyen mély könyvtárstruktúrában helyezkedhet el, stb. Mégis, ami főleg a Windows-t használóknak kell figyelembe venniük: nem nevezhetik el a fájljaikat az alábbi listából: CON, PRN, AUX, NUL, COMx (x = 1-9), LPTx (x = 1-9). Ezek ugyanis fenntartott nevek, speciális funkcionalitással bírnak (pl. régen egy egyszerű szöveges fájlt olyan könnyen ki lehetett nyomtatni, hogy "type info.txt > prn"). Velem egyidősek emlékezhetnek a "copy con info.txt" parancsra is, amivel tetszőleges fájl lehetett létrehozni és begépelni a tartalmat (copy parancs: honnan, mit, hová, ezesetben a honnan: con, azaz konzol, mit: amit begépelünk, hová: az info.txt-be).
Volt régen egy vicc is, miszerint az igazi programozó így kezdi: "copy con program.exe" (utalva arra, hogy az igazi programozók gépi kódot írnak fejből, ami elsőre működik).
Tévhit: A piros szín minden monitoron pirosan jelenik meg
Egy halom példa van arra, hogy ez mikor nincs így, vegyük csak a legegyszerűbbet: e-ink képernyő, ami csak fekete-fehér kijelzőjű, és modern eszközökön is fellelhető (e-book olvasók, takarékos mobiltelefonok, stb). De még színes kijelzőn is akadhatnak eltérések az eszköz állapota, minősége, beállítása (pl. szemkímélő mód be van-e állítva?), kalibrálása miatt. Egy designer ismerősöm karriere kezdetén belefutott abba, hogy sajnos olcsó eszközöket volt kénytelen használni és ami színvilágot ő megtervezett, az sehol máshol nem nézett ki úgy, ahogy nála - kalibrálhatta újra az egész tervet.
Tévhit: Ha a piros szín valóban pirosként jelenik meg a képernyőn, akkor mindenki pirosnak látja
Kicsit már rákanyarodunk az akadálymentesség (accessibility) témakörére, de bizonyos látási nehézségek, színtévesztés esetén a fenti tévhit nagyon hamar megdől. Itt is hangsúlyos, hogy amíg az ember nem találkozik ilyesmivel testközelből, hajlamos róla megfeledkezni.
Ami kimaradt
Próbáltam minél hétköznapibb és megfoghatóbb példákat hozni annak érdekében, hogy minél közelebb érezzük az egyes eseteket magunkhoz, de a lista közel sem teljes. Ez a zseniális gyűjtés és annak minden hivatkozása egy-egy hasonló tévhitet sorol, amit minden, a témával foglalkozó fejlesztőnek (de sokkal inkább: rendszertervezőnek!) ismernie kellene: https://github.com/kdeldycke/awesome-falsehood