Manapság minden valamirevaló keretrendszerben elérhető valamilyen eseménykezelő, ami a publish/subscribe mintát követi. Ezekkel az eszközökkel flexibilisebb alkalmazásokat írhatunk, alacsonyabb lesz a “coupling” az osztályain között.
Tovább olvasomJava fejlesztőként találkoztam az slf4j-vel, ami nem más, mint egy logging facade. Önmagában nem sok mindenre jó: mint ahogy a neve is sejteti, elrejti előlünk a konkrét megvalósítást, absztrakt felületet ad. Használatával bármikor válthatunk egyik logging keretrendszerről a másikra. Innen vettem az ötletet, és nem titkoltan az slf4j forráskódját bújva készítettem el az lf4php-t. Egy korábbi írásomban már megemlítettem, most bemutatom, hogyan kell használni, illetve milyen irányelvek vezettek a tervezése és fejlesztése során.
Tovább olvasomA tranzakciókezelés alapvetően nem bonyolult dolog, már ami a használatát illeti. Ha minden művelet rendben végrehajtódik, akkor nincs teendőnk. Az érdekesebb viszont az, amikor valamilyen hiba lép fel. Ugye ilyenkor rollbackelni kell. Önmagában ez sem nagy szám, az adatbázis elintézi, amit el kell (ugye nem myisam-ot használunk!), viszont sokszor ez nem elég: el is kell takarítanunk magunk után. Hogy miket? Például a létrehozott/elmozgatott/törölt(!) fájlokat és minden egyéb olyat, amit a tranzakción belül hajtottunk végre.
Tovább olvasomNem tudom, ki hányszor hallott rosszat PHP programozókról, én személy szerint rengetegszer. A PHP programozók gányolnak. Ez az általános vélekedés. Valójában nagyjából minden script nyelv esetén ez a megítélés, kisebb-nagyobb eltérésekkel. Miért mondják ezt a Java, C++, C# programozók? Nos tény, hogy bár gányolni minden nyelven lehet, a PHP erre kifejezetten alkalmas is. Az viszont, hogy alkalmas, nem azt jelenti, hogy máshogy nem lehet. Tény, hogy a nyelvből sok dolog hiányzik, az API nem feltétlenül konzisztens, azért lehet benne jó kis weboldalakat írni. De valóban csak weboldalakat írunk PHP-ben? A legtöbbször ebből indulunk ki, és rengeteg félreértéshez vezet.
Tovább olvasom