Mostanában szórakoztam egy picit Java programozással. A Minecraft játék egy nyílt forráskódú szerveréhez írtam plugint. Ennek során futottam egy érdekes hibába.

Adott egy véletlenszerű int szám. Ennek a számnak a segítségével kell választanom 6 lehetőségből, amit így oldottam meg:

		Random rnd = new Random();
		String command = "";
		for (int i = 0; i < 50; i++) {
			int a = rnd.nextInt() % 6;
			switch (a) {
			case 0:
				command += "r";
				break;
			case 1:
				command += "o";
				break;
			case 2:
				command += "w";
				break;
			case 3:
				command += "y";
				break;
			case 4:
				command += "g";
				break;
			case 5:
				command += "b";
				break;
			}

			a = rnd.nextInt() % 2;
			if (a == 1)
				command += "'";
		}

A probléma a következő: Valamilyen ismeretlen oknál fogva előfordul, hogy a switch-nek egyik ágába sem(!) jut el a program! Én személy szerint nem értem, hogy miért.

A megoldás az volt, hogy beletettem egy default ágat is így:

			default:
				i--;
				continue;

Ez persze nem igazi megoldás, de legalább a kód innentől azt csinálja, amit szeretnék...

Ha valakinek van valami ötlete, hogy ez miért van, vagy hogy hogyan lehet felesleges iterációk nélkül megoldani a problémát, kérem írjon ide kommentbe, vagy emilben, mert erre nagyon kíváncsi lennék...

rOzzy

Nemrégiben egy újabb melónak köszönhetően volt szerencsém találkozni egy számomra új keretrendszerrel: PRADO.

A fejlesztők alapvető elgondolása az volt, hogy a .NET framework-höz hasonló, eseményvezérelt felhasználói felületet mutassanak a webes alkalmazások. Ezzel persze semmi baj addig, amíg ezt stabilan biztosítani tudják. Ezzel ellentétben az én tapasztalatom az, hogy a keretrendszer egyáltalán nem stabil, sőt tele van hibával. Munkám során többször kellett átülnöm másik géphez, mert a PRADO minden gépen különböző hiba-/parajelenségeket produkált UGYANOLYAN környezetben.

Az ugyanolyan környezet jelen értelmezésben a következő:

• Ugyanaz az Apache verzió szintén azonos modulokkal (azonos telepítőből)
• Ugyanaz a MySQL verzió
• Ugyanaz a PHP verzió ugyanazokkal a modulokkal (azonos telepítő)
• Ugyanaz az Oprendszer (Windows XP, automatikus frissítések kikapcsolva, de naprakészen tartva)
• Ugyanaz a php.ini és apache httpd.conf(!)

Az egyetlen különbség a vhosts.conf fájlban volt, érthető okok miatt...

A második problémám a keretrendszerrel az, hogy minden egyes hibára, legyen az exception vagy mezei PHP error, megáll, és egy csodálatos majmolt Asp.NET hibajelentést generál. Teljesen mindegy neki a hiba mértéke, az E_NOTICE ugyanúgy megállítja a futást, mint az E_ERROR, vagy akármi más hiba szint. Teszi mindezt úgy, hogy önmaga is tartalmaz jóegynéhány E_NOTICE-t. Nevetséges...

Összegzésként a véleményem: A HTTP egy állapot nélküli protokoll. Így lett kitalálva, ez van. A session kezeléssel valamennyire áthidalták ezt, de ettől függetlenül még egy állapotmentes protokoll marad. A PHP szintén egy kvázi állapot nélküli nyelv, hiszen két oldallekérés között tulajdonképpen semmilyen kapcsolat nincs, csak logikai síkon. Ezek ismeretében kérdezném meg a kedves alkotókat, hogy mégis milyen alapon gondolták, hogy "tegyünk úgy, mintha a PHP egy állapottal rendelkező, folyamatosan futó programkód lenne!" ? A válasz után pedig csak annyit mondanék: "Srácok! Ami nem megy, ne erőltessük!"

rOzzy

Érdekes dologra lettem figyelmes az admin oldal modularizálása közben. A kérdéses modul összes funkciója után a programozó kért egy oldalfrissítést. Na de hogy... 

print('<META HTTP-EQUIV="refresh" CONTENT="0;URL=index.php?mode=cikkek&sub=edit&cikk_id='.$cikk_id.'">'); 

 Ez így bele az oldal közepébe a vakvilágba. Erről egy pár szót:

1. A META-tag helye a HEAD-en belül van
2. a refresh-t nem illik manapság használni
3. ott a php-s header() parancs... az miért nem jó? (mondjuk hozzáteszem, mivel tele volt az egész oldal print-tel, ezért ez a megoldás nem működhet)

ejnye... Az oldal tartalma jelenleg egy bufferbe töltődik, úgyhogy az oldalfrissítések megoldása a header() lett.

fp

...na ez az, ami itt nincs. Kedves kollegám a főlapon már javította a hasonló jellegű problémákat, de ha már kaptam egy accot a bloghoz, nem tudtam elmenni amellett, hogy ennek a szarnak az oldalnak az adminisztrációs lapja is tele van hasonló jellegű problémákkal, amelyeket az alábbi kép szemléltet:

Értemén persze... a php az meglehetősen típustalan nyelv, no de azért ejnye...

(A pirosas-narancssárgás dizány a figyelmeztetéseknél az XDEBUG műve. Mielőtt még valaki azt hinné, nem a rendszer kapja el a hibákat, és formázza meg ilyen szépen! — rOzzy)

fp

Mostanában nagyon sokan — megjegyzem, nagyon helyesen — igyekeznek valid (szabályos) HTML, esetleg XHTML kódot generálni a webes alkalmazásaikkal. Legyen az PHP, Asp.Net, vagy akármilyen más nyelv, a generált kód validitása mindenképp fontos. 

Egy valid HTML, vagy XHTML kód — vagy legalábbis a törekvés rá — onnan ismerszik meg, hogy az első sora valahogy így néz ki:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

A mostanában sokat emlegetett E-learning rendszer is hasonlóan kezdi a generálást. Leszámítva, hogy a kódjában alapvető hibákat találtam. Íme a legsúlyosabb:

...
</head>
<script>
function mozgat(irany, ker, val)
{
    document.forms.vizsga_form.action.value = irany;
    document.forms.vizsga_form.kerdes.value = ker;
    document.forms.vizsga_form.valasz.value = val;
    document.forms.vizsga_form.submit();
}
function countdown()
{
    document.vizsga_form.mperc.value--;
    if (document.vizsga_form.mperc.value == -1)
    {
        document.vizsga_form.perc.value--;
        document.vizsga_form.mperc.value=59;
    }
    if (document.vizsga_form.mperc.value == 0 && document.vizsga_form.perc.value == 0)
    {
        mozgat('kuldes' , 0, 0);
    }
    setTimeout("countdown()", 1000);
}
</script>
<BODY bgcolor="#FFFFFF" text="#000000" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0" onLoad="countdown()"> 
<body>
...

Félreértés ne essék, a második <body> tag nem is akart lezáró tag lenni, az eredetileg is nyitó tag, csak éppen az illető, aki ezt írta, nem számolt azzal, hogya script már egy másik helyen kiírt egy <body> taget. Persze emiatt nincs is meg mindkét tag lezáró párja.

A másik orbitális hiba az, hogy a <html> tagen belül csak kétféle tag lehet, ezek a <head> és a <body>. A <script> tag csak ezek közül valamelyikben szerepelhet, önállóan nem. itt mégis sikerült beékelni a kettő közé.

Arról nem is beszélek, hogy a CSS használat mellett nem értem, miért van szükség a bgcolor, és a text attribútumokra. Méginkább érthetetlen, hogy mi az a sok marginos attribútum, amire az összes általam látott HTML értelmező kiakadt, hogy ilyen nincs. 

rOzzy