palacsint blogja

Betűtorony szabályok

Ami a játékhoz (Hasbro) mellékelt szabályban nem lett explicit kimondva:

  • Egy körben több szót is kirakhatsz, nem kell minden betűt egy szóba belezsúfolni a plusz 10 pontért.
  • Csak meglévő szót lehet folytatni.

Felhasznált irodalom:

UTF-8-e vagy?

Egy érdekes probléma: hogyan döntsük el egy fájlról, hogy milyen karakterkódolással készült? Igazából algoritmus kellene rá, a Total Commander F3-as nézőkéje nem mindig jó megoldás. Főleg a bemenet gépi ellenőrzésekor nem.

Kis keresgélés után a Mozilla-féle karakterkódolás-detektáló algoritmus java verziójára akadtam. Kipróbáltam, de nem jött be. A latin2 és ASCII kódolást felismerte, az UTF-8-at és a latin1-et nem. Pedig az UTF-8 lenne a legérdekesebb. Igazából egy boolean isUtf8(byte[]) metódus is elegendő lehet a legtöbb feladatra.

Aztán találtam belőle egy fejlettebb változatot, ami már az UTF-8-cal is megbirkózik.

Egy másik jó választás a GuessEncoding. Ez ugyan csak az UTF-8 kódolást ismeri (meg néhány másikat a BOM-ból képes kitalálni), de cserébe viszonylag egyszerű, könnyen módosítható.

Kipróbáltam a Java API idevágó osztályait is, hátha jelzik a hibát, ha UTF-8 helyett valami mást találnak. Fájlok beolvasásával kapcsolatban három módszert nézegettem. Az első a FileReader volt, de a dokumentációja szerint az alapértelmezett karakterkódolással dolgozik, ha nem erre van szükségünk, akkor az InputStreamReader és a FileInputStream kombinációját kell alkalmaznunk. A harmadik jelölt pedig a Scanner osztály volt.

Mivel a FileReader-nek nincs olyan konstruktora, amelynek meg lehetne adni a karakterkódolást, így ezzel nem is foglalkoztam tovább. A rendszer alapértelmezett karakterkódolása biztos, hogy rendszerről-rendszerre változhat, úgyhogy erre nem érdemes építeni. Az InputStreamReader és Scanner osztályok rendelkeznek olyan konstruktorral, ami karakterkészletet vár. Ezeknek mindig UTF-8-at adtam meg.

A Scanner nem jelzi, ha hibát talál az UTF-8 fájlban. Egyszerűen csak onnantól kezdve nem ad vissza semmit. Az InputStreamReader visszaad valamit, de nem az igazi. A Scanner reakciója szimpatikusabb, legalább utalni fog valami a hibára, ami lehet, hogy egyébként észrevehetetlen lenne. Például ha egy nagyobb adatfájl belsejében fordul elő egy hibás kódolású karakter.

Az eddigiek miatt tanácsos lehet a tényleges adatfeldolgozás megkezdése előtt az egész fájl UTF-8 megfelelőségét ellenőrizni. Erre a GuessEncoding váza tökéletes, csupán néhány módosítás szükséges hozzá:

  • Ha nem sikerül detektálni a karakterkódolást, akkor ne a rendszer alapértelmezett karakterkódolását adja vissza, hanem dobjon mondjuk egy UnknownCharsetException-t.
  • Az egész fájlt be kell olvasnunk, nem elég csak a fájl első néhány kilobájtja alapján tippelni. (Ahogyan azt egyébként a Mozilla-féle algoritmus is teszi.)

A magyar ékezetes karakterekhez egyébként egy reguláris kifejezés is elegendő lehet. (Csak ne Scannerrel olvassuk be a fájlt, mert akkor csak az első hibás karakter előtti tartalmat kapjuk meg, amire valószínűleg illeszkedni fog a kifejezés.)

SCJP csapdák

Néhány dolog ami eszembe jutott a Sun Certified Java Programmer (SCJP) vizsgára való tanulás közben, kérdezték valamelyik tesztkérdésben, érdemes megjegyezni, vagy épp elrontottam a valamelyik feladatban.

SCJP lettem

Ma túlestem a régóta halogatott SCJP vizsgán. Számalk, Etele út. Korrektek voltak. A cég megszokásból 310-055-re vett vouchert, amit szerencsére módosítottak 310-065-re, ami már Java 6 SCJP, nem Java 5. Könyvem is már a Java 6-hoz van. Kimaradt a System.gc(), volt helyette NavigableSet és NavigableMap. Legalábbis ez a két változás tűnt fel.

A vizsga egész könnyűnek tűnt a könyvben, CD mellékleten, vagy a netről pluszban letölthető feladatsorokhoz képest. A hibákat nem mutatják meg sajna, bár talán jobb is, mert biztos csak felhúztam volna magam rajta.

A netről letölthető feladatsoron már sikerült kiakadnom a hétvégén. Nem igazán élvezem a többoldalas kódban a fordítási hibák keresgélését. Keresse meg a javac, azért van. A „fejből javadoc-ot” feladatokat sem szeretem, de élesben kevés ilyen volt, azok is egyszerűek.

A netes tesztnél az tette be a kaput, amikor a végén közölte, hogy „failed”. A CD-sek előtte simán megvoltak. Aztán jobban megnéztem, itt 80 százalék a minimum, nem 65. Para ezerrel: akkor most mennyi is kell? A netes frissebb lenne? A 80 azért kicsit izgulós. Könyv elő, abban 65 százalékot írnak, meg azt, hogy ez változhat, pontos infó a suned.sun.com-on. Ott 65-öt írnak. Huhh...

A 65 százalék pedig ennél a próbatesztnél is simán megvolt, ráadásul pár hosszabb forráskódot egyszerűen kihagytam, mert nem volt már kedvem végigolvasni sem őket. (Aztán persze fordítási hibás volt egyik-másik...)

A legjobban az a megoldókulcsbeli hiba tetszett (volt pár...), amikor a „Compilation fails due to a single error in the code” és ugyanez „multiple errors”-szal is igaz volt egyszerre. Legalábbis szerintük.

A vizsgán emberi méretű forráskódok voltak, nem egy 800x600 pixeles ablakban kellett görgetni (egérgörgő nélkül) a forrást, mint a CD-ről felrakható MasterExam-ban. Teljes képernyő, rendes betűtípus a forráskódok alatt, stb. Volt drag&drop is. A feladatok negyede talán nem (mint ahogy a könyv írja), de mondjuk 10-12 kérdés volt ilyen a 72-ből. Egyszer próbáltam újra megnézni egy ilyen kérdést, de szólt a progi, hogy ha megteszem, akkor elvesznek a korábbi válaszok (ha jól értelmeztem), úgyhogy inkább hagytam az eredeti verziót.

Eredményt csak a nyomtató mutat a végén, a képernyőre már nem írják ki. Gondolom így izgalmasabb.

private

Kapunk fordítási hibát a kommentelt soroknál a Java fordítótól?

class A {
	private int a;
	
	class InnerA {
		private int b;
		
		void m2() {
			a = 9; // #1
		}
	}

	void m1() {
		InnerA innerA = new InnerA();
		innerA.b = 8; // #2
	}

}

Válasz hajtás után.

Sanyi

Gondolom mindenki ismeri a következő képet:

Hajtás után pedig egyszerűen készíthetsz saját névvel ellátott verziót belőle.

Code review után

Eclipse 99+ megnyitott fájllal.

Titkosított partíciók elérése Ubuntu CD-vel

sudo apt-get install cryptsetup lvm2
sudo /etc/init.d/cryptdisks start
sudo cryptsetup luksOpen /dev/sdXX name

Ezután a /dev/mapper alatt megtalálhatóak lesznek a titkosított partíciók eszközfájljai.

Szoftveres vagy hardveres RAID1?

Szoftveres! Mert:

  • Az asztali gépek alaplapjain lévő, esetleg olcsóbb PCI-os RAID kártyák nem sokat csinálnak amúgy sem hardverből, ez is szoftveres RAID – álcázva. Mert különben minek is kellene hozzá külön driver?
  • Ha elfüstöl az alaplap, RAID kártya, vagy egyszerűen csak szeretnél újabb deszkát, akkor sincs probléma – a szoftveres RAID ugyanúgy fog tovább működni az új alaplappal is, míg az (ál)hardveres lehet, hogy hardverfüggő. Megéri kockáztatni? Nem az adatok a fontosak? Elvileg azért RAID1, hogy az egyik winyó hibája esetén az adatok még megmaradjanak, ne legyen SPoF. Ha ilyen olcsó (ál)RAID vezérlőt használsz, akkor a RAID vezérlő lesz az SPoF. Pár év múlva szinte lehetetlen lesz egy mai alaplapot beszerezni, ha más lappal, vezérlővel mégsem lennének elérhetőek az adatok.
  • Sebesség szempontjából ugyanott vannak.
  • A winyót át lehet vinni másik gépbe is minden gond nélkül, még RAID vezérlő sem kell hozzá.
  • Jobban konfigurálható. Nem kell hozzá kliensprogram, az oprendszer alapból tudja. Linux és Windows is. Akár menet közben is állíthatod, nem kell hozzá újraindítani a gépet.
  • Nem kell az egész lemezt bevonni a tömbbe. Lehet csak egy-egy partícióból (partíciópárból) RAID1-et építeni, a nem túl fontos adatoknak így több hely marad.
  • Nem kell RAID vezérlő sem.

Ettől függetlenül legyen biztonsági mentésed! Ha ellopják a gépet szőröstül-bőröstül, akkor ... – nos, az ellen nem véd. Az se baj, ha a biztonsági mentés helyileg is máshol van, nehogy a géppel együtt vigyék a hordozgató winyót, vagy a DVD táskát is. A biztonsági mentés pedig legyen titkosítva, mert ha ellopják, akkor rossz kezekbe kerülhet minden személyes adatod.

(A fentiekben természetesen csak az otthoni, asztali gépek esetéről van szó.)

throw null

Nemrég összefutottam a következőhöz erősen hasonlító kódrészlettel:

} catch (final Exception e) {
	if (e != null)
		e.printStackTrace();
}

Tipikus „mitírki”-t lehet belőle készíteni, mondjuk egy ilyet:

try {
	throw null;
} catch (final Exception e) {
	if (e == null) {
		System.out.println("null");
	} else {
		System.out.println("nemnull");
	}
	System.out.println("e: " + e);
}

Eredmény hajtás után.

Tartalom átvétel