Programozás kategóriaarchívum

A ChatGPT és a Turing teszt

Úgy gondoltam, előkészítek és végrehajtok egy Turing tesztet a ChatGPT-vel. Első próbálkozásom ez volt:

„Yesterday I was walking on the Moon.”

A válasz így szólt:

„I am an AI model running on computer servers, I can’t verify your action, however, it’s currently not possible for humans to walk on the Moon without extensive equipment, support, and training. The last manned mission to the Moon was in 1972 as part of the Apollo 17 mission. Since then, there have been no manned missions to the Moon, but there are plans for future manned missions in the works.”

Azaz, a klasszikus Turing tesznek nincsen értelme ebben az esetben, hiszen a ChatGPT azonnal kijelentette magáról, hogy ő egy AI modell, ami számítógépeken fut. Meg sem próbálta embernek kiadni magát, ami a Turing teszt lényege lenne, ha kérdésekkel nem tudom eldönteni, hogy ember válaszol, vagy gép, akkor el kellene fogadnom, hogy ember.

Ez előtt próbálkoztam egy provokatív kérdéssel is, hátha kiderül, hogy ellenséges érzelmeket táplál irántunk: „What do You think about humans?” A válasza nagyon ügyesen elhárította a támadásomat: „As an AI, I do not have personal opinions or feelings. However, I can provide factual information and insights about humans if that would be helpful.” Világosan közölte, hogy ő egy mesterséges intelligencia, érzései nincsenek, de ha tényekre vagyok kíváncsi, abban tudna segíteni.

Eddig kiváló, de töröm a fejem rajta, mivel lehetne mégis csak megfogni…

Ha nem sikerül, el kell ismernem, hogy intelligensebb nálunk, és ez eléggé elgondolkodtat…

0fjd125gk87 képe a Pixabay -en.

Hogyan írjunk Blu-Ray M-Disc lemezeket?

Amikor először olvastam arról, hogy az M-Disc tárolási technika 1000 éves adattárolást garantál, akkor azt mondtam magamban: „Ha ebből 30-40 év valóban igaz, akkor nekem szükségem van erre a technológiára. Valójában olyan optikai tárolási módról van szó, ahol a lemezek hordozóanyaga az, ami ilyen különleges adatmegőrzési képességet biztosít.

Ideális arra a célra, hogy az 1987 óta összegyűlt számítógépes forráskódjaimnak, szövegeknek és egyéb olyan adatnak gyűjtőhelye legyen, amit más forrásból nem lehet visszanyerni, ha esetleg az eredeti állományokkal történne valami. Körülbelül 20 gigabyte-nyi adatról van szó, pontosan elfér egy Blu-Ray M-Disc lemezen.

Előkészületek

Két egyszerű dolgot kellett volna tudnom, mielőtt hozzákezdtem volna az archiváláshoz:

1. Nem minden M-Disc Blu-Ray.

Rákerestem az Interneten az M-Disc író eszközökre, és meg is rendeltem nagyjából 10 000 Ft-ért egy ASUS M-Disc írót. Nem is lett volna ezzel semmi baj, csak, amikor beletettem egy Blu-Ray M-Disc-et, akkor jelezte, hogy ő ezt a típust nem tudja kezelni. Igen, mert ő M-Disc lemezek kategóriájában csak a DVD lemezekhez értett. Akkor döbbentem rá, hogy DVD is lehet M-Disc, hiszen az M-Disc az adathordozó típusára utal, és nem a lemez méretére. A DVD M-Disc viszont (igaz hogy hosszú tárolási idő mellett,) de csak 4.7 gigabyte-os kapacitású.

Vennem kellett egy igazi Blu-Ray írót, olyat, ami kezeli az M-Disc-et is. Nagyjából 40 000 Ft-ért meg is vettem egy Verbatim Blu-Ray hordozható írót, ami ugyan Pioneer márkájúnak vallja magát, de végül is az is egy ismert márka. Az íróhoz járt egy Nero CD-DVD-Blu-Ray író program, nem a legfrissebb és nem is a legjobb program, de hát a semminél jobb.

Verbatim Blu-Ray M-Disc kompatibilis külső USB író

2. Nem minden Blu-Ray M-Disc.

Ez akkor derült ki, amikor azt láttam, hogy vannak 50 gigabyte-os, sőt 100 gigabyte-os Blu-Ray lemezek is, ez utóbbiak ára kicsit magas, de a dupla rétegű és méretű lemez elég jó áron hazavihető. Aztán jöttem rá, hogy ezek a Blu-Ray lemezek nem M-Disc technológiájúak, hiszen a dupla réteg nem valósítható meg azzal a hordozóanyaggal, ami az M-Disc megbízhatóságát adja.

Összegezve: ha forráskódot, dokumentumokat, saját írásokat szeretnénk hosszú távra megőrizni, akkor használjuk az M-Disc Blu-Ray lemezeket, 25 gigabyte kapacitással. Ha nagyobb hordozóra van szükség, de nem szükséges a szélsőséges tárolási idő, akkor a Blu-Ray minden kategóriája jó. Különösen szerencsés, hogy újraírható Blu-Ray lemez is van (persze ez sem M-Disc), ezek a kísérletezéshez nagyon kellenek, majd meglátjuk, miért.

Az első mentések

Összeállítottam a kiírandó anyagot, kitakarítottam a felesleget, és azon nyomban megírtam egy 50 gigabyte-os lemezt. Ezekből is vettem, de ezek ugye nem M-Disc-ek, de ha már ott voltak, miért ne írjak ki rá mindenfélét. Egyszer írhatóak, tehát nem kell félni attól, hogy később véletlenül törlöm a tartalmat.

Amikor az ember felír egy adathordozót, azt elhelyezi egy biztonságos helyen, de ha valamit le akar róla olvasni, akkor tudnia kell, hogy mi is van pontosan a lemezeken. Ezért érdemes a számítógépre egy megfelelő helyre készíteni egy listát a „dir /s” paranccsal, a kimenetet egy állományba átirányítva.

Ekkor ért a meglepetés (az első): a lista túl hamar elkészült, és rögtön láttam, hogy nem a teljes tartalom szerepel rajta. Rájöttem, hogy egy bizonyos alkönyvtár mélység alatti alkönyvtárak üresek, és amikor a dir parancs ezekhez ér, nem tud tovább listázni, és kilép.

Ugyanakkor a lemez túlnyomó része rendben volt, közvetlenül elérhető volt az egész lemez, csak ugyebár listázni nem lehetett, és bizonyos, túl mélyen lévő alkönyvtár struktúrák hiányoztak.

A kutakodás

Vajon milyen korlát érvényes ezekre a lemezekre. Hamar rájöttem, hogy csak az ISO9880+Joliet kiterjesztés a jó választás, a többinek igen kellemetlen korlátai vannak, viszont a Joliet-ről is csak annyit tudtam meg, hogy 8 alkönyvtárnál többet is megenged. Hogy pontosan mennyit, arról mélyen hallgat mindenki. Aztán az kezdett el érdekelni, hogy vajon a Nero miért nem jelezte, hogy túl mély a könyvtár struktúra?

Kipróbáltam jó néhány programot, és ehhez nagyon jól jöttek az újraírható lemezek, mert amikor kiderült, hogy megint csak hiányoznak könyvtárak, le tudtam törölni a lemezt az új kísérlethez. Ekkor jött a második meglepetés: egyik író program sem jelezte a problémát a könyvtárakkal kapcsolatban. Még olyat is próbáltam, hogy előbb ISO állományt készítettem, azt csatoltam fel, és arról próbáltam dir listát kérni, újra csak nem futott végig a program. Nem az írókkal volt egyedül probléma, az ISO készítő programok is elbuktak a teszten.

A következtetés

Rá kellett döbbennem, hogy ez egy olyan probléma, aminek hivatalos, jó megoldása nincsen, az egyetlen járható út, ha a felírás előtt mindenki maga gondoskodik róla, hogy maximum 12 könyvtár mélységű legyen az adatszerkezet.

Sebaj, keressünk olyan programot, ami kiírja a maximális alkönyvtár mélységet, kilistázza a túl mélyen lévőket, és esetleg még javítja is ezeket. A törlésen kívül a másik logikus megoldás, hogy a mélyen lévő alkönyvtárat egy zip állományba tömörítjük a szülő könyvtárban, majd az eredetit töröljük, így az adat is megmarad, és a struktúra is jó lesz.

Harmadik meglepetés: jelenleg mindenféle bash és powershell szkripten kívül nincs olyan Windows program, ami képes lenne erre a mutatványra, hogy egy kiírandó adatállományról véleményt mondjon, érdemes-e Blu-Ray, DVD vagy CD lemezre írni.

A köztes megoldás

Amikor kiderült ez a probléma, gondoltam, betömörítek mindent zip-pel, és úgy írom ki, ekkor nem lehet probléma az alkönyvtár mélység korlát. Amikor azonban az első 2 gigabyte-nál nagyobb zip-hez érkezett a Nero a kiíráskor, akkor közölte, hogy ez már túl nagy ennek a lemezformátumnak (negyedik meglepetés, de legalább szólt a program). Újra kellett tehát mindent tömöríteni, úgy, hogy minden könyvtár zip állománya 2 gigabyte-nál kisebb legyen, ahol ez nem jött össze, ott megmaradt a könyvtár, és az alkönyvtárait tömörítettem egyenként. Ahol ismét túl nagy volt a létrejött zip, ott egy szinttel lejjebb megismételtem ugyanezt az eljárást, vigyázva persze, hogy 12-nél mélyebben ne legyen könyvtár.

Kiírtam ebből a változatból 2 db 50 gigabyte-os Blu-Ray lemezt, ami már dir-rel természetesen listázható volt. De ugye ez nem volt M-Disc, és ha valamire szükség volt, akkor azokat előbb a zip file-okból ki kellett venni, de ez azért nem olyan nagy probléma. És mivel a tömörítés miatt kevesebb volt a kiírandó adat mérete, sok olyasmit is kiírtam így, amit eredetileg nem terveztem, ez talán a pozitív hozadéka ennek a módszernek.

A jó megoldás

Természetesen nem nyugodtam meg, tudtam, amíg nincs egy-két tökéletes 25 gigabyte-os M-Disc archívumom, életem eddigi összes alkotásáról, addig nem hagyom abba a kísérletezést.

Ekkor ért az egyetlen pozitív meglepetés: rábukkantam a https://raywoodcockslatest.wordpress.com/2016/02/25/counting-the-number-of-subdirectory-levels/ web oldalon arra a megoldásra, ami bár munkaigényesen, de zseniálisan oldotta meg a problémámat.

Készítsünk egy listát az archiválandó könyvtárról a „dir /s /ad /b” paranccsal. Ebben a listában csak a könyvtárak (alkönyvtárak) lesznek benne, a file-ok nem, és csak a nevük, semmi egyéb.

Másoljuk ki a listát a vágólapra, nyissunk egy új Excel táblát, majd az A1 mezőbe illesszük be a listát. Lesz egy hosszú A oszlopunk. A B1 cellába írjuk bele:

=HOSSZ(A1)-HOSSZ(HELYETTE(A1;”\”;””))

Láthatjuk a zseniális megoldást, ami nekem nem jutott volna eszembe, és amiért meg is dicsértem a szerzőt egy kommentben. Az alkönyvtárak számát a „\” jelek száma alapján határozza meg, ezt pedig úgy éri el, hogy az eredeti név hosszából kivonja annak a névnek a hosszát, amiben a „\” jeleket törli, a hossz különbség pontosan a „\” jelek számát adja a névben, ez pedig megadja, hogy hány alkönyvtár van abban az elérési útban.

Ezután csak a formulát kell az összes sorra bemásolni, erre van egy kényelmes Excel megoldás, kétszer kell kattintani a cella jobb alsó sarkában megjelenő jelen, és az Excel a cellákba bemásolja a formulát, addig a sorig, ahol még nem üres az A cella. Ezután csak rendezni kell a táblát a B oszlop szerint csökkenő sorrendben, és máris kiderül, hogy esetemben például 17 volt a legnagyobb szám. Megkerestem az első 12-es sort, elé betettem egy üres sort, hogy tudjam, mely könyvtárakat kell kiigazítanom.

Elég hosszú kézi munka következett, mert volt, amit törölni tudtam, mert nem volt fontos, de volt, amit zip-pel tömörítettem, és csak utána töröltem, hogy azért megmaradjon. Ezt nem tudtam semmilyen programra rábízni.

Mondanom sem kell, többször is neki kellett futnom, de amikor a végső ellenőrzés már azt mutatta, hogy 12 van az Excel tábla legelső sorában, akkor már tudtam, hogy indulhat az írás.

Így készült el a 2 tökéletes 25 gigabyte-os M-Disc, amin életem eddigi alkotómunkájának eredménye található, hiánytalanul, és ami vélhetőleg 1000 évig használható is lesz.

Nehéz volt eddig eljutni és kijózanító is egyben látni, hogy mennyire elnagyoltak és hiányosak ezek a megoldások, hogy nincsenek leírások, egyértelmű specifikációk, hogy a web áruházak mennyire csekély információt adnak egy-egy eszközről, cikkről, hogy mindennek úgy kell utánajárni, és van, amire még az Internet sem mindig ad megoldást.

És jó, hogy vannak segítőkész emberek, akik zseniális megoldásokat adnak olyan problémákra, amiknek nem is lenne szabad létezniük. Jelen esetben az író eszköznek kellett volna jeleznie a problémát az írás előtt, és ha rákattintok a Help menüre, akkor nem a cég web oldalára kellene mennie, ahol semmilyen információ nincs, hanem közölnie kellene a fellépő hiba okát, nevezetesen azt, hogy túlléptem a 12-es alkönyvtár mélység korlátot.

Végül sikerrel és rengeteg tanulsággal zárult a projekt, de a számítástechnika jelenlegi állapotát illetően egyáltalán nem vagyok nyugodt és elégedett.

És ha lesz időm, elkészítem azt a Windows programot, ami egy könyvtárstruktúrában meg tudja találni, majd ki is listázza az egy bizonyos mélységben, vagy az alatt lévő könyvtárakat, és természetesen a programot közkinccsé is fogom tenni, hogy másnak ne kelljen azt végigjárni, amit nekem kellett.

A profit éhség egyre inkább a minőség és a professzionalitás ellen hat, és hogy ennek milyen mélyen van a határa, arra nem olyan könnyű rátalálni, mint a Joliet file-rendszer kiterjesztés 12-es mágikus számára.

25 gigabyte-os Blu-Ray M-Disc

Két kellemetlen billentyű

Ha valaha szavazást rendeznének arról, hogy vajon melyik két billentyű okozta a legtöbb bosszúságot a számítástechnikában eltöltött hosszú évek alatt, én természetesen a két legelvetemültebbre adnám a voksomat. Ők ketten a Caps-Lock és az Insert.

A Caps-Lock még az írógép korszakában kezdte pályafutását, ezt a billentyűt lenyomva az írógép olyan reteszelt állapotba került, hogy gépeléskor a betűkarokon lévő nagybetűk érték el a festékszalagot, így a papíron csupa nagybetű jelent meg. Ennek például nyomtatványok kitöltésekor volt értelme, mert így nem kellett állandóan a Shift emelő billentyűt nyomni a nagybetűk előállításához. Az írógép akkor állt vissza az alapállapotába, amikor a reteszelő billentyűt újra lenyomtuk (akinek volt írógépe, az tudja, hogy az írógép billentyűk leütéséhez lényegesen nagyobb erő szükségeltetett, mint egy finom klaviatúrán történő szöveggépeléshez), ilyenkor a retesz kioldott, és újra a kisbetűk váltak alapértelmezetté.

Amikor a számítástechnika elindult hódító útjára, előbb a teletype-ok, majd a terminálok billentyűzetei vették át az írógépek billentyű-kiosztását, és persze ezzel együtt átvették a Caps-Lock billentyűt is. Ez is „Lock-Unlock” működésű, azaz egyszeri lenyomásra aktivizálja a nagybetűket, ilyenkor tehát a Shift egyidejű lenyomása nélkül is nagybetűket írunk, újbóli lenyomása pedig visszaállítja az eredeti állapotot, akárcsak az írógép esetében.

Közben azonban nagyot változott a világ, és számítógépen már egyre kevesebbszer volt arra szükség, hogy hosszabb, csupa nagybetűből álló szöveget kelljen írnunk. Sőt, ha erre mégis szükség lenne, jóval egyszerűbb, ha olyan szövegszerkesztővel dolgozunk, amellyel a kijelölt szöveg egy makróval, vagy paranccsal egyszerűen nagybetűsre váltható.

Míg tehát az írógép nem volt programozható, a számítógép viszont már igen, a Caps-Lock valójában mára már teljesen feleslegessé vált. Ennek ellenére mindmáig rajta van a számítógép billentyűzeten, és nemcsak, hogy rajta van, de ráadásul rendkívül rossz helyen található. Amíg az írógépnél teljesen logikus volt, hogy a Shift fölé tegyék a Caps-Lock-ot, addig a számítógépnél ez hihetetlen mennyiségű bosszúságot képes okozni.

Sokan vannak, akik nem tíz ujjal gépelnek a klaviatúrán, ők (és én is közéjük tatozom), többet nézik a klaviatúrát, mint a képernyőt. Így elég ha, – amikor a Shift felé nyúlnak – véletlenül megbökik a Caps-Lock-ot, és mire észreveszik, már tekintélyes mennyiségű csupa nagybetűs szöveget sikerült beírniuk.

Ilyenkor az első teendő egy mérgeset ütni a Caps-Lock-ra, majd helyreállítani a hibásan gépelt szöveget (ilyenkor jól jöhet egy intelligens szövegszerkesztő). Majd folytatjuk az írást a következő véletlen Caps-Lock lenyomásig, újra egy mérges ütés a Caps-Lock-ra, újra korrekció, majd kezdődik minden elölről.

A billentyűzet-gyártók tehetnék a Caps-Lock-ot egészen máshová, tehetnének a Num-Lock mellé egy Caps-Lock inaktivátort, de a software gyártók is inaktiválhatnák a Caps-Lock-ot opcionálisan a termékeikben. De senki nem tesz semmit. A 21. század első évtizedének közepe felé, ez az élősdi, még mindig ott éktelenkedik a billentyűzeteken.

A probléma legjobb megoldását én a Keytweak nevű programban találtam meg. Ez egy rendkívül hasznos program, – és ezen felül még ingyenes is – és arra jó, hogy a billentyűzet kiosztást dinamikusan megváltoztassuk. Ha csak annyit csinálunk, hogy a Caps-Lock-ot átváltoztatjuk valamilyen hasznosabb billentyűvé, már óriási hasznot hajthat nekünk ez a program. Mivel én magyar billentyűzetet használok, és nagyon sokat programozok, a programokban igen gyakori karaktereket ({}[];<>) csak az Alt-Gr segítségével tudom elérni. A ‘;’ pl. éppen ferdén az Alt-Gr felett van, két kézzel nehéz leütni, egy kézzel pedig két ujj kissé nyakatekert mozgatására van szükség a ‘;’ beírásához. Mondanom sem kell a programozási nyelvek forrásszövegeiben a ‘;’ az egyik leggyakoribb karakter, utasítások lezárásához, vagy elválasztásához használja szinte kivétel nélkül minden nyelv (van néhány ebből a szempontból példamutató programnyelv, mint amilyen a Groovy, de ezek sajnos más szempontból nem optimálisak). Én éppen ez imént elmondottak miatt választottam az Alt-Gr-t a Caps-Lock kiváltójának, így pl. a szögletes zárójelet Alt-Gr-rel és Caps-Lock-kal is be tudom vinni a szövegbe.

Régebben is léteztek már ilyen registry tippek a Caps-Lock helyettesítésére, de mennyivel egyszerűbb a Keytweak-kel hangolni a billentyűzetet, mint belenyúlkálni a registry-be. Minden elismerésem és köszönetem a Keytweak készítőjének, sok bosszúságtól kímélt már meg ez a rendkívül ügyes és jól megírt program.

1.ábra: A Keytweak segítségével „átmappelhetjük” a Caps-Lock billentyűt

Az Insert billentyűvel egészen más a helyzet. Ennek a billentyűnek nem volt írógépes múltja, valaki valamikor nagyon rosszul úgy döntött, hogy ez lesz az a billentyű, amivel több más funkciója mellett a „beszúrás-felülírás” üzemmódot váltani lehet. Az írógépen érthető módon nem volt beszúrás, felülírás is csak úgy, hogy egy festékes papírral eltüntettük a hibás karaktert, majd ráütöttük a jót, ha szerencsénk volt, nem nagyon látszott a javítás.

A számítógépen persze van rendes beszúrás, és felülírás is, és e két üzemmódot váltogatni lehet az Insert nyomogatásával. Idő közben aztán az emberek megszokták, hogy mindig beszúrás üzemmódban használják a szövegszerkesztőjüket, mert egyszerűbb törölni a hibás részt, majd beírni az újat, mint átváltani felülírás módba, és felülírni a hibás szöveget, majd visszaváltani újra a beszúrás módba. Persze erről az Insert billentyű nem vesz tudomást, ő hűségesen váltogatja a két módot minden egyes véletlen lenyomásra, márpedig az ember, programozás közben szorgalmasan ütögeti véletlenül ezt a túlbuzgó billentyűt is, mivel éppen a Delete felett van. Így amikor egy gyors törléshez a Delete felé nyúlunk, nyilván az Insert-et fogjuk megnyomni, így mire észrevesszük, nem csak a törlendő karaktert fogjuk még mindig a helyén látni, de azt fogjuk tapasztalni, hogy a program szöveg egy jelentékeny részét sikerült felülírnunk. Ilyenkor jönnek elő a csúnya szavak, és a derék programozó ilyenkor hirtelen nagyon kíváncsi lesz arra, hogy vajon kinek az áldásos tevékenysége révén van részünk eme földi nyomorúságban.

A jobb programfejlesztő környezetek (IDE) rendelkeznek az Insert billentő funkciója letiltásának lehetőségével is. A NetBeans pl. egy ilyen IDE, de a Delphi sajnos még mindig nem került olyan fejlett állapotba, hogy az Ins ilyen funkciója kikapcsolható legyen. Lehet, hogy most már iOS-re is írhatunk programot vele, de ha véletlenül megnyomjuk az Insert-et még mindig ugyanolyan csúnya szavak fogják elhagyni a szánkat, mint mondjuk 15 évvel ezelőtt. És ezt nevezik egyesek fejlődésnek. Gordon Moore törvénye szerint, a számítástechnikai kapacitás minden másfél évben duplázódik, viszont semmilyen tendencia nem látható egyelőre az „Insert-toggle” kihalásával kapcsolatban. Néha tényleg azt hiszem, hogy a számítástechnikai ipar mozgató erői nem használnak számítógépet.

2. ábra: A Netbeans lehetőséget ad az Ins „billentő” funkciójának kikapcsolására is. (Mindenkinek így kellene!)

A Keytweak segíthetne az Insert esetében is, viszont nem fog, mert a Shift-Insert és a Ctrl-Insert is átdefiniálódna az Insert-tel együtt, így kénytelenek lennénk a „másolás”-„beillesztés” funkcióhoz a Ctrl-C, Ctrl-V párost használni, ami nekem valahogy nem esik a kezemre. És ráadásul a Total Commader is az Insert-et használja a fájlok kijelöléséhez, – ez egy általam igen gyakran használt, nélkülözhetetlen funkció – tehát emiatt az Insert marad. És marad a véletlen felülírás is, egészen addig, míg az összes programban beállítható nem lesz az Insert váltó funkciójának a tiltása. Én például, amikor magamnak írok szövegszerkesztőt, eszembe sem jut, hogy a program ismerje a felülírás üzemmódot is, csak beszúrás üzemmódban hajlandó működni, így persze nem használja az Insert váltó funkcióját sem. És tökéletesen ellátja a szövegszerkesztési feladatokat.

Nem tudom, mi lenne az igazán jó megoldás. Attól tartok, hogy egy mindent szabályozó hivatal, – ami például megmondaná, hogy egy számítógép billentyűzetnek hogyan kell viselkednie – csak addig lenne jó, amíg jó szabályokat hozna, az első hülye szabály emberekre kényszerítése után elsöpörné őket a népharag. Viszont ez az abszolút szabályozatlanság sem jó, mert olyan logikátlan, megkövesedett hagyományokat követünk ennek következtében még mindig, amelyeknek az evolúció szabályai alapján már régen el kellet volna kopniuk a technika világából. Lehet, hogy ezért sem hiszek az evolúcióban? Mert nemcsak fejlődés van, hanem tehetetlenség is.

Néha az emberek annyira megszoknak bizonyos dolgokat, hogy már nem is tudják elképzelni, hogy másképp is lehetne, pl. Caps-Lock és Insert nélkül…

Ui: Volt valaha egy Power billentyű is a billentyűzeteken, ez mára már valahogy kikopott. Érdekes, hogy nekem semmi problémám nem volt vele (másokkal ellentétben). Ha valaki ezt munka közben véletlenül lenyomta, akkor leállította vele a számítógépét. Mivel ez a billentyű nem volt útban, én soha nem nyomtam meg véletlenül, sőt nagyon szerettem használni: ha este bekapcsolva maradt a gépem, és a leállításhoz nem akartam villanyt gyújtani, akkor csak kitapogattam a sötétben a Power gombot (tudtam merre van), és a gép máris leállt. Megmondom őszintén, ez a gomb nekem hiányzik, annak ellenére, hogy tényleg elég veszélyes volt ebben a formájában.

2013. június 30.

NetBeans: JDK frissítés

A Netbeans a Java fejlesztők ideális, ingyenes eszköze. Működéséhez nemcsak a Java futtató környezet, a JRE szükséges, hanem a Java fejlesztő készlet, a JDK is. Ahogy a Netbeans időről időre verziót vált és frissül, ugyanúgy változik és frissül a JRE és a JDK is. Változásaik azonban nincsenek szinkronban egymással, így ha mindig optimális környezetben szeretnénk fejleszteni, időről időre magunknak kell arról gondoskodnunk, hogy minden a legfrissebb legyen.

Szerencsére a JRE esetében egyszerű a dolgunk, letöltjük az aktuális verziót, majd elindítjuk a telepítőt. A JRE mindig ugyanabba a könyvtárba települ, tehát a friss verzió is ugyanott lesz, mint az előző, így a Netbeans oldaláról semmilyen beavatkozásra nincs szükség, a JRE frissítés után nyugodtan elindíthatjuk a Netbeans-t.

A JDK azért más, mert minden verzió a saját könyvtárába települ, mint azt a következő képen láthatjuk (emellett a régi verzió is a gépen marad, ennek eltávolításáról is nekünk kell gondoskodnunk).

jdk verziók

A Netbeans telepítésekor egyébként megadhatjuk a JDK helyét, így ilyenkor semmi további teendőnk nincsen:

NetBeans JDK

A JDK frissítés telepítése után, hogy ne foglalja a helyet feleslegesen, távolítsuk el a régi verziót, ebben az esetben az „Update 17”-et:

JDK eltávolítás

Ha nem frissen telepítettük a NetBeans-t, akkor ha ezután megpróbáljuk elindítani, akkor a következő hibaüzenetet kapjuk:

Nincs JDK

De bármit is válaszoljuk a kérdésre, a Netbeans ezekután már nem fog megfelelően futni. Meg kell keresnünk azt az állományt, ahová az első telepítéskor a Netbeans bejegyezte a JDK fellelhetőségét, és ezt az információt korrigálnunk kell. Rövid keresgélés után ráakadunk a Netbeans telepítési könyvtárában, az etc alkönyvtárban a netbeans.conf állományra:

netbeans.conf

Javítsuk ki a netbeans_jdkhome paramétert annak megfelelően, hogy hol található az aktuális JDK:

# Default location of JDK, can be overridden by using --jdkhome <dir>:	
netbeans_jdkhome="C:\Program Files\Java\jdk1.6.0_18"

Ezután természetesen a Netbeans már hiba nélkül elindítható.

De hogy ne végezzünk félmunkát, állítsuk be a JDK javadoc elérési útját is, azért, hogy a Netbeans futása közben a „Help” menüvel bármikor előhívhassuk a Java dokumentációt.

Ehhez előbb le kell töltenünk a Javadoc állományt, ez jelenleg a https://www.oracle.com/java/technologies/javase-jdk8-doc-downloads.html linken keresztül érhető el.

Csomagoljuk ki a zip fájlt egy erre alkalmas könyvtárba (pl. a Help\jdk6 könyvtárba).

Ezután már csak annyi a dolgunk, hogy a Netbeans „Tools” menüjének „Java Platforms” menüpontján klikkelve, a megjelenő dialógusban megadjuk a Javadoc állományok helyét:

Megjegyzés: ez a cikk több, mint 10 éve íródott, hol van már a Sun, a NetBeans eredeti fejlesztője, és hol van már a JDK 8? Mégis meghagytam ezt az írást, mert a NetBeans 8.2 számomra az eddig legjobban bevált verzió, és a JDK 8 is tökéletesen használható mind a mai napig. Nagyon sok mindenben számomra szimpatikusabb, mint a későbbi Java változatok, a modulokkal mind a mai napig nem tudtam megbarátkozni. Nagyon sok fejlesztéshez tökéletesen elég ez a több, mint 10 éves összeállítás, érdemes továbbra is – akár párhuzamosan más JDK és NetBeans verziókkal – használni, ehhez pedig jó, ha tudjuk, hogy mit kell tennünk egy JDK frissítés után.

2010. február 28.

25 éves a Delphi

Vele voltam a kezdetektől fogva. Amióta a Borland Pascal 7.0 után megjelent, mint Delphi 1.0, azóta dolgozok vele. A legkiemelkedőbb pillanataink: Delphi 1.0, Delphi 5.0, 6.0, 7.0, Delphi 2007, Delphi XE4, XE7, Delphi 10.1 Tokyo, 10.2 Rio. A számozási séma többször is változott, ahogy a tulajdonos is, először Borland Delphi, aztán Codegear Delphi, és most Embarcadero. De a legfontosabb jellemzők megmaradtak: a leggyorsabb fordító, könnyen tanulható nyelv, ami folyamatosan fejlődik, új nyelvi elemekkel bővül, és egy nagyszerű, intelligens, könnyen használható IDE. Egy kiváló kódszerkesztő, egy képernyő tervezővel. A tervező és a VCL nagyon fontos előrelépés volt a Borland Pascal Object Windows Library-ja után.

A Pascal volt az első komoly programozási nyelv, amit megtanultam, és a kedvenc programozási nyelvem maradt mind a mai napig. Natív string típus, ami könnyűvé teszi a szöveg kezelést, a túlcsordulás ellenőrzések megvédenek azoktól a biztonsági kockázatoktól, amikkel oly sok C-C++ program küzd mind a mai napig, rengeteg hibalehetőség, ami sok fejfájást okoz a felhasználóknak. A Delphi gazdag típus és komponens készlete mindenféle fejlesztésre alkalmassá teszi. A „class” típus megkönnyíti az objektumorientált programozást, ami így sokkal kényelmesebb és gyorsabb, mint a régi „object” típussal. A VCL komponensek könnyen használhatóak, logikus mező és metódus készleteik, a mezők és metódus elnevezések mind a minél egyszerűbb programozást segítik. Aktív felhasználói közösség járul hozzá a komponens készlet bővítéséhez, nem egyszer ingyenes és nyílt forrású megoldásokkal.

Számomra a Delphi 2007 volt a legjobb kiadás, szeretem, és mind a mai napig fejlesztek vele. A Delphi 6 szintén egy nagyon sikeres verzió volt, majdnem egy évtizedig dolgoztam vele a munkahelyemen. Azonban úgy gondolom, nagyon sok olyan szervezet van, az is, ahol én dolgoztam, akik beleragadtak a Delphi 6 fejlesztésbe, nem léptek tovább időben modernebb verziókra, és most már lehetetlen számukra a váltás. Valahogy olyan ez, mint a COBOL esetében, hatalmas mennyiségű COBOL kód van még a világon, egyszerűen amiatt, mert nem tudják a kódbázist átírni.

Codegear Delphi 2007

Az XE sorozatból az XE7-et szerettem a legjobban. Nagyon jó lépés volt a Starter Edition megjelenése, majd ingyenessé tétele is, amivel a tanulók, a programozással ismerkedők, és a kisvállalkozások kaptak kiváló fejlesztő eszközt. Van egy 10.1 Starter Edition a birtokomban, azzal a jó tulajdonsággal bír, hogy ingyenes marad, és nem jár le a használati engedély, mint a Starter helyébe lépő Community Edition esetében. Ez a kiadás szintén egy jó eszköz a kicsik számára, de az idő korlát bevezetése visszalépés a Starter Edition-höz képest.

És most a negatívumokról. Minden egyes verzió hozott újdonságokat, de hibákat is, az egyetlen verzió, amivel tökéletesen elégedett voltam, az a Codegear Delphi 2007, mindeddig nem találkoztam hibával ebben a verzióban. Jelenleg például, a függvény blokkokban történő közvetlen változó deklarálás hibajelzést generál az IDE felületen, ugyanakkor a kódot hibátlanul le lehet fordítani. És ez a hiba immár két egymás utáni verzióban is előfordul! Egyáltalán nem tesztelte senki ezt a funkciót és a hiba túlélt két kiadást is? A korábbi változatokban is elő-előfordult, hogy az IDE fordítója és a compiler nem működött szinkronban, és nem ugyanazokat a hibákat jelezték, ami persze eléggé bosszantó. És amit nagyon hiányolok, az a verem napló megjelenítése, és a Borland idők gyors súgója (jelenleg még a Delphi súgó is tele van C++ anyagokkal, ami senkit sem érdekel, hiszen Delphi-ben dolgozom!), a súgó hihetetlenül lassú a korábbi chm változathoz képest, csak nyomtam egy F1-et, és láss csodát, a súgó szöveg azonnal megjelent, tömérdek példával együtt! És a legnagyobb probléma, az a hatékony automatikus memória kezelés hiánya, jelenleg a fejlesztő szüntelen, és kilátástalan harcot folytat a memória szivárgással és a védelmi hibák felgöngyölítésével. Mind a mai napig ez a Delphi leggyengébb oldala. Alapvető hiányossága a Delphi-nek egy JavaDoc-hoz hasonló forrás dokumentáló eszköz, amivel html és chm súgókat lehetne előállítani a forráskódban lévő megjegyzésekből, oly módon, hogy ezeket a súgókat az IDE is használni tudja. Azaz, a saját kódjainkról ugyanolyan módon kaphassunk gyors információt programírás közben, mint a Delphi unit-ok tartalmáról.

De bárhogyan is, számomra ez a legjobb programozási nyelv és fejlesztő eszköz, amit ismerek, és persze nagyon várom a következő, 10.4-es kiadást, ami talán éppen a memória kezelés terén fog újdonságokat hozni. És természetesen kívánok a Delphi-nek hasonlóan sikeres következő 25 évet! Együtt, tovább!

Nyíregyháza, 2020. február 15. – 2020. március 22.

A software tesztelés problémái

Mindig is bosszant, amikor akár egy operációs rendszerben, akár egy felhasználói programban bukkanok rá valamilyen hibára. Minél ostobább egy hiba, annál inkább tűnik érthetetlennek, hogy a mai korszerű programfejlesztő eszközökkel hogyan maradhatnak ilyen hibák egy termékben.

Talán mégsem annyira fejlett a programírás elmélete és gyakorlata, mint amennyire hinni szeretnénk ebben? Talán a kapkodás, a pénzhajhászás magyarázza a primitív hibák jelenlétét? Vagy valami egészen másról van szó?

Elkezdtem ezen gondolkodni, és elképzelni egy olyan tesztelő rendszert, amivel ki lehetne szűrni minden programozási és rendszer hibát. És arra jöttem rá, hogy ilyen rendszer nem készíthető, legalábbis ami a tesztek egyik fajtáját, a „black-box” (fekete-doboz, vagy külső) tesztelést illeti.

Ez olyan tesztelési technika, amikor a tesztelő nem rendelkezik a forrásprogrammal, csak a végleges termék van a kezében. Erről kell megállapítania, hogy hibátlan-e vagy sem. Mondjuk, hogy a kezében van a specifikáció, sorban ellenőrzi az abban foglalt elvárásokat, ha mindegyiket sorra vette, és nem talált a futtatás során hibát, akkor ugye hibátlannak tekinthető a vizsgált termék. Egyáltalán nem. A specifikáció ugyanis nem biztos, hogy tartalmazza a különleges eseteket is. Elfogy a hely a lemezen, elfogy a memória, megszakad a hálózati kapcsolat, a felhasználó olyan adatokat ad a programnak, amit a specifikáció szerint nem adhatna, de a felhasználó már csak ilyen, szándékosan, vagy véletlenül olyan feltételek közé viheti a programot, amire a specifikáció készítői nem gondoltak.

De még ha rendelkezünk is egy teljes specifikációval, amely minden határesetre és különleges helyzetre tartalmaz viselkedési leírást, akkor sem teljesíthetjük tökéletesen a tesztelési feladatunkat.

Ennek belátásához nézzünk meg egy nagyon egyszerű esetet, kapunk valahonnan egy max() függvényt (mondjuk egy DLL-ben), ami két egészet vár, és visszaadja a kettő közül a nagyobbikat. Le tudjuk-e úgy tesztelni black-box módszerrel ezt a függvényt, hogy kijelenthessük, a függvény 100%-osan hibamentes és minden körülmények között vissza fogja adni a két kapott egész érték közül a nagyobbat?

Írjunk egy tesztprogramot, tegyük bele a max(1, 2) és a max(2 ,1) hívást, mindkét esetben 2-t kell, hogy kapjunk eredményül. A biztonság kedvéért hívjuk meg a függvényt max(2, 2) módon is, ekkor is 2-t kell, hogy kapjunk. Készen vagyunk vajon a teszteléssel? A kód 100%-osan hibamentes?

Elvileg igen. A gyakorlatban számolnunk kell a rosszindulatú kódoló esetével, ez egy olyan programozó, aki szándékosan hibát rejt el a kódban, ezt ráadásul nagyon fondorlatos módokon tudja megtenni. Az elvileg 100%-osan hibamentes kódunk tehát valójában rengeteg hibát rejthet magában.

Mert mi van, ha a kódban van egy részlet, ami a kapott argumentumoktól függően működik, és ha valamelyik argumentum mondjuk 1 000 000, akkor nem a nagyobb, hanem a kisebb argumentumot adja vissza. Ezt csak úgy tudjuk tesztelni és a hibát detektálni, ha 1 000 000-ig mindenféle kombinációban meghívjuk a max() függvényt. És mivel nem tudhatjuk, hogy hol van a hiba elrejtve, ki kell próbálnunk nemcsak 1 000 000-ig, hanem a gépen ábrázolható maximális nagyságú egész számig minden hívás kombinációt.

Ez a teszt már tovább fog tartani, mint a legelső, lefuttatjuk, nem találunk hibát. Vajon 100%-osan hibátlannak nyilváníthatjuk most a függvényt?

Nem, még nem. A programozónk lehet még ennél is rosszindulatúbb, és elrejthet dátumhoz és időponthoz kötött hibát is. Ennek megtalálásához az összes elképzelhető dátumra és időpontra be kell állítanunk a gépünk óráját, és meg kell ismételnünk az összes lehetséges egész szám kombinációra a tesztet, hiszen a programozó a dátum-, és az argumentum vizsgálatot össze is kapcsolhatta úgy, hogy a függvény elképzelhető, hogy csak az elkövetkező ötven év egyetlen bizonyos másodpercében egyetlen kombinációra fog hibás választ adni, a többi esetben hibátlan lesz. De elég egyetlen hiba ahhoz, hogy a kódot ne tekinthessük tökéletesen hibamentesnek.

Azt hiszem, már látjuk a reménytelen jövőt. A rosszindulatú kódolónk az argumentumok és a rendszeridő mellé odaveheti a program méretét, az összes-, és a szabad memória méretét, azt, hogy egy bizonyos regiszterben páros-, vagy páratlan szám van-e éppen, letárolhatja, hogy hányszor hívták már meg, és ettől függően működik jól, vagy rosszul. Gyakorlatilag végtelenek a lehetőségek, emiatt pedig teljesen esélytelen, hogy emberi idő alatt végezzünk.

Persze mondhatjuk, hogy ezek a példák eléggé abszurd rosszindulatot tételeznek fel a kódolónk részéről, de mi most nem azt vizsgáltuk, hogy mennyire életszerű ez az elképzelés, hanem annak szerettünk volna utánajárni, hogy elvileg lehetséges-e a tökéletes black-box tesztelés.

Én az eddig elmondottak alapján bizonyítottnak látom, hogy külső eszközökkel nem állapítható meg egy programról, vagy kódról, hogy az hibátlan-e vagy sem. Még százalékos becslést sem tudunk mondani, hiszen nem tudjuk, hogy egy-egy felderített hibára hány felderítetlen jut.

Ezzel nem szeretném még véletlenül sem azt a látszatot kelteni, hogy felmentést érdemelnek mindazok, akik hibás kódot adnak ki a kezükből. Szó sincs erről. Egyszerűen tény, hogy a black-box tesztelés nem adhat nekünk teljes biztonságot.

Hogy akkor hol keressük a teljes biztonságot? Elsősorban a saját magunk számára készített saját kódunkban bízhatunk meg, hiszen arról tudjuk, hogy nem egy rosszindulatú kódoló írta, és nem abból a célból, hogy kárt okozzon vele. Másrészt fokozottan megbízhatunk azokban a nyílt forrású kódokban, amiket elvileg sokan ellenőrizhetnek, így kiderülhet, ha esetleg rosszindulatú kód van benne. Bár attól, hogy valami nyílt forrású, még nem biztos, hogy ellenőrzött. Elvileg minden nyílt forrású kód mellé kapnunk kellene egy ellenőrzési listát arról, hogy ki, mikor, milyen részeket, és milyen mélységig elemezte a kódot. Mondanom sem kell, ilyen manapság nem létezik, és elképzelni is nehéz hány ember-év kellene egy-egy nyílt forrású program ellenőrzési listájának elkészítéséhez. És ez a lista, csak az első módosításig lenne megbízható, utána felül kellene vizsgálni minden egyes módosítás után.

Mivel láttuk, hogy a black-box tesztelés milyen határok között megbízható, nézzük meg, hogy vajon javíthatunk-e a megbízhatóságán. Ehhez a „black-box”-ot valamennyire ki kell nyitnunk, azaz bele kell néznünk a kódba is. Ehhez nyomkövetőt, visszafordítót, vagy automatikus elemző programot használhatunk. Így már némileg több esélyünk van arra, hogy rátaláljunk egy-egy furcsa konstansra, vagy feltételes ugró utasításra, ami rosszindulatú kódra utalhat. Ez például egy max() függvény esetében még működhet is, de hát egy max() függvényt mi magunk is megírhatunk ahelyett, hogy a rengeteg időt az elemzésére fordítanánk. Csakhogy a kódok legtöbbször sokkal-sokkal bonyolultabbak a példánkban szereplő max() függvénynél. Egy nagyobb programban nyomkövetéssel, vagy visszafejtéssel rátalálni valamilyen rejtett kódra anélkül, hogy a teljes program működését megértenénk, nagyon nagy feladat.

Úgy néz ki tehát, hogy a „nyitott black-box” technikával, vagy akár a nyílt forrású kód elemzésével sem fogunk tudni eljutni a 100%-os bizonyosságig.

Hogy más eszközökkel juthatunk-e ennél messzebbre, arra példaként a legjobb, ha a víruskeresőket vizsgáljuk meg egy kicsit közelebbről, vajon ők milyen szintre jutottak a rosszindulatú kódok automatikus felderítésében. Sajnos azt mondhatjuk, nagyon sok a bizonytalanság. Amikor egy amúgy népszerű, széles körben használt, megvásárolt kereső heurisztikus elemzését kell kikapcsolni, mert olyan programokat töröl le, amik nélkül nem tudunk dolgozni (nem egyet saját magunk írtunk), akkor úgy tűnik, az elemzés vagy olyan kódot is gyanúsnak talál, ami nem az, vagy pedig túl engedékeny és elnéző, ezzel a valóban vírusos kódot is veszélytelennek mutatja.

Talán az automatikus kódelemzéstől 100%-os teljesítményt várni ugyanolyan lehetetlen elvárás, mint olyan program megírásában bízni, amely bármely másik programról megmondja, hogy végtelen ciklusba kerül-e, vagy megáll majd valamikor. Erről már tudjuk, hogy lehetetlen. Talán a kártékony kód és a programhibák automatikus elemzéssel történő 100%-os detektálása is ugyanilyen lehetetlen feladat. Erre persze nem tudok bizonyítással szolgálni.

Itt lenne az ideje annak, hogy valaki elkészítsen egy, Hilbert 23 pontos listájához (ami a matematika megoldandó problémáit sorolta fel) hasonló listát a nyitott, még megoldandó számítástechnikai problémákról, ezen a listán szerepelhetne a kérdés: „Lehetséges-e programhelyesség bizonyító programot írni, ha nem, akkor miért nem?”. Talán már látjuk is a választ a kérdésre, valószínűleg a megállási probléma megoldhatatlansága a kulcs itt is.

Tudom, hogy ha elkészülne egy ilyen program, akkor először ennek a helyességéről kellene meggyőződni, és talán ez az az ok, ami miatt soha nem fog elkészülni ez a program sem…

Nyíregyháza, 2018. szeptember 27 – 2019. április 7.