TCZ

Ez mekkora WTF már?

Olvasom a Weblabor blogmarkok között, hogy megjelent (október 29-én) az Emotion Markup Language 1.0-ás verziója. Érdemes beleolvasni a specifikációba, ilyenek vannak benne mint:

<emotion>
    <dimensions set="myFriendlinessDimension">
        <friendliness value="-0.7"/><!-- a pretty unfriendly person -->
    </dimensions>
</emotion>

Bölcsész beállÍtottságú ismerőseimet és rokonaimat mindig húzom azzal, hogy mennyie felesleges áltudány az, amit űznek. És erre tessék. Ki az, aki erre ráér? Vagy ki az, aki ezt főállásban végzi?

(Mellesleg szerintük ezekre lehet használni többek között.)

Mostanában szinte semmire nem volt időm az új munkahely miatt, és ez is csak egy kis szÍnes… But stay tuned (subscribed).

Minden ember egyenlőnek születik – jogilag, és úgy is csak papíron.

Földrajzilag például biztosan nem. Sokat szoktam gondolni azokra a gyerekekre, akik mondjuk Közép-Afrika vagy Ázsia nyomorúságos életkörülményeibe születnek bele, és akiknek felfoghatatlan álom csupán a napi elengedő, tiszta ivóvíz, vagy megfelelő táplálék. Nekik mesésen gazdag paradicsom egy olyan ország, mint Magyarország. De ők oda születtek, és minden bizonnyal ott is fognak meghalni.

Aztán az ember magára gondol. Elmorfondírozik azon, hogy milyen óriási szerencse, isteni áldás, hogy egy olyan országba született, ami ugródeszka lehet szinte bárhova, a ma ismert világunk legfejlettebb, legnagyobb jólétben élő országaiba, a jelen civilizáció csúcstermékeibe. Vagy éppen oda, ahova akar.

Néhány hónapja megkeresett egy spanyol fejvadász cég, hogy lenne-e kedvem Barcelonában dolgozni – volt, méghozzá nagyon, gyermekkori álmom egy mediterrán országban élni. Kissé döcögős felvételiztető procedúra és interjúk vannak mögöttem: felvettek. Az új munkahelyem az egyik legnagyobb látogatottságú spanyol website fejlesztője.

A következő időszakban onnan fogok írni, biztosan rengeteg új dolgot tanulok majd és örülök, ha megoszthatom ezeket a blogom olvasóival.

Tanuljatok ti is, szerezzetek szakmai elismerést, és dobbantsatok azon a bizonyos ugródeszkán! Ha mégis honvágyatok lesz, bármikor hazajöhettek, de a lehetőség, hogy ott éljetek, ahol akartok, ritka ajándék.

Stay tuned, hasta pronto!

Ismeritek a Mesterlogika (Mastermind) nevű – offline – játékot?

A Microsoftnak néhány éve volt egy nagyon jó kezdeményezése. Anno én is részt vettem a Kódpárbaj nevezetű versenyen, ahol az internetes küzdőtéren egymásnak eresztettünk jó pár “robotot”, hogy kő-papír-ollót játsszanak. A robotok tulajdonképpen webservice-ek voltak, és az volt a feladat, hogy stratégiát állítsunk fel velük egy alapvetően szerencsére épülő játékban – a kő-papír-ollóban.

A verseny nagyon izgalmas volt, igazi geek olimpia. Sajnos a csoportkörök után hamar kiestem, de nem volt gond, a részvétel így is nagyon nagy élmény volt, és még egy webservice-ekről szóló könyet is nyertem. Akkor egyedüliként indultam PHP-vel (4-essel!), ugyanis a verseny az ASP.NET webszolgáltatás funkcióinak népszerűsítése indult, és a PHP sem volt még alapvetően felkészítve erre a protokollra.

Azóta már mindenki 5-ös PHP-t használ (én is), és tudjuk, hogy a SOAP osztályokkal a webszolgáltatások írása és használata nagyon egyszerű. Elhatároztam, hogy megpróbálok egy kis Kódpárbaj klónt szervezni az alábbi különségekkel:

• A verseny kliens-szerver felállása változik: a szervező a szerver, a játékosok a kliensek
• A játék nem kő-papír-olló, hanem egy sokkal jobban “gépiesíthető” játék, a Mesterlogika (Mastermind)

Biztos lesz még jópár különbség a lebonyolításban, de alapvetően ez a két fő változás.

Megírod a klienst, ami megpróbálja kitalálni, hogy a szerver milyen színeket ötölt ki feladványnak. Mindenki játszott kiskorában mesterlogikát, akinek volt gyerekszobája. Aki nem, annak a kiírásban lesz részletes játékszabály. Minden bot X játékot játszhat, és a aggregált eredmények alapján rangsorolunk. Weben követhető lesz minden játék.

Felhívás

Hol tart most a dolog? Megvan a webservice nagy része. A webes felület még készül. Négy dologban kérek segítséget a blog olvasóitól:

• Tesztelés, fejlesztés – az egész dolog nyílt, aki akar, bekapcsolódhat a tesztelésbe, illetve a fejlesztésbe is
• Nyeremények, szponzoráció – felajánlott nyereményeket szívesen fogadunk a leendő verseny győzteseinek logókihelyezés, promótálás fejében
• Visszajelzés – kommentben vagy akárhogy jelezze, akit későbbiekben érdekel a verseny, és képesnek érzi magát egy robot összerakására. Példaprogramok lesznek.
• Terjesztés – osszátok meg a Readerben vagy küldjétek el ezt a bejegyzést annak, akit érdekelhet

Remélem legalább olyan izgalmas versenyt szervezünk, mint anno a kódpárbaj.

Hamarosan munkahelyet váltok, és ezzel összefüggésben keressük az utódomat a cégnél. A fejlesztési munkák nagy része LAMP alapon történne, plusz el kell látni némi sitebuilder munkakört is.

Az állás “PHP fejlesztő” címmel lett meghirdetve, és viszonylag sokan jelentkeztek is az alábbi kulcsszavakkal a CV-jükben: PHP, MySQL, HTML, CSS, JavaScript. Be is hívtunk néhány szimpatikusnak látszó úriembert (tényleg, lányok, miért nem tanultok meg programozni???), és összeállítottam egy rövid tesztet, a szokásos IQ teszt mellé, hogy gyorsan le tudjuk mérni a kompetenciát.

Az egyik kérdés így hangzott: “Mi az SQL injection? Mi a session fixation?”

Nagyon egyszerű, kíváncsi voltam, hogy az illető ismeri-e ezt a két gyakori webes sebezhetőséget, és képes-e kivédeni ezeket a munkája során. A jelentkezők közül mindegyik azt állította magáról, hogy “PHP fejlesztő”, ennek ellenére a 80%-uk nem tudta megmondani, hogy mi az az SQL injection, a session fixationt pedig – nem vicc – senki nem ismerte.

Volt néhány delikvens, aki a szóösszetétel értelmezésével próbált rátapintani, hogy mi lehet ez, de gyakorlatileg egyikük sem ismerte, nem is beszélve a kivédés módjairól.

Nem szeretnék autofellációt elkövetni ezzel a poszttal, és a demagógiát is megvetem, de könyörgöm, ne nevezze már magát PHP fejlesztőnek az, akinek ezek a kifejezések semmit nem mondanak. Így védjük magunkat a weben? Ezekkel a “szakértőkkel”?

A többi kérdést ki sem vesézem, pedig azoknál is voltak említésre méltó hiányosságok.

Azokhoz az emberekhez szólok, akik magukra ismertek a fentebbi bekezdésekben. Tanuljatok! Képezzétek magatokat! Ha másban nem is, legalább security témakörben! Annyi jó anyag érhető el a hálón, kérésre én is tudok küldeni jópár írást.  A PHP egy remek nyelv, és szükség is van jó fejlesztőkre, akik értenek hozzá. De olyanokra, akik csak azt hiszik, hogy értenek hozzá, olyanokra egyszerűen nincs.

Olykor előfordulhat, hogy egy hibás program megduplázza (triplázza, kvadplázza) a rekordokat egy adatbázistáblában. MySQL egyszeregy következik.

Nagyon egyszerűen elkerülhetjük ezt az esetet. A bejegyzés végén persze azt is elárulom, hogyan töröljük ki a felesleget, ha már megtörtént a dolog, ám előbb a megelőzés: azokra a mezőkre, amelyeket együtt csak egyszer akarunk látni (pl. termékazonosító, ár és ár érvényessége) csinálunk egy közös unique indexet.

ALTER TABLE `arak` ADD UNIQUE `egyedi` ( `termekid` , `ar`, `ervenyes` )

Ezzel biztosítottuk, hogy ugyanolyan felállás az adott mezőket tekintve nem fordulhat elő egy újabb rekordban. Ezután csak annyi a dolgunk, hogy eldöntsük, mit tegyünk hasonló rekord beszúrásakor. Ugyebár két lehetőségünk van, a felülírjuk a már létező rekordot az új adatokkal, vagy hagyunk mindent a régiben. A titkos harmadik lehetőség a kivétel generálása.

1. INSERT INTO `arak` SET `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′ ON DUPLICATE KEY UPDATE `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′

Mi történik itt? Az “ON DUPLACATE KEY UPDATE” kifejezés annyit csinál, hogy ha már létezik a táblában olyan kulccsal (vagy unique index-szel) rekord, amit be akarunk szúrni, akkor megelőzi a beszúrást, és felülírja a megadott mezők értékét. Esetünkben a frissítéshez minden mezőt felülírunk, ami az INSERT-ben eredetileg szerepelt.

Megjegyzem ennek a módszernek csak akkor van értelme, ha a fenti három mellett vannak még más mezők is a táblában. Például egy megjegyzés mező, vagy egy akciós flag, amit egyáltalán felül tudunk írni. Hiszen ha ilyen nincs, akkor a rekord nem változik. Apropó nem változik…

2. INSERT IGNORE INTO `arak` SET `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′

Itt az IGNORE kulcsszó hatására a MySQL a beszúrás során fellépő hibákat figyelmeztetésként kezeli, és nem akasztja meg az egész tranzakciót, például. Ezzel a módszerrel tehát azt érhetjük el, hogy a beszúrt rekord ütközés esetén ne íródjon felül, tehát az új rekord beszúrása ne történjen meg, és ne legyen hatással a régire.

3. INSERT INTO `arak` SET `termekid`=15, `ar`=990, `ervenyes`=’2009-08-01 0:00:00′

Ez a harmadik eset, ilyenkor – már létező kulcs esetén – a végrehajtás hibát fog generálni. Ez is hasznos lehet olykor.

Mindhárom módszer nagyon fontos olyan esetekben, amikor például különböző adatbázisokat szinkronizálunk.

Ha viszont már elb*sztuk, és a táblánk tele van mindenféle hasonló rekorddal, amelyekből nekünk csak egy kell per fajta, akkor itt egy kis elsősegély:

CREATE TABLE `uj_arak` AS SELECT * FROM `arak` GROUP BY `termekid` , `ar`, `ervenyes`

Ezzel létrehozunk egy ugyanolyan táblát, mint az eredeti, és beletettük az eredetiből az egyedi rekordokat – legalábbis amelyeknél a termekid, az ar és az ervenyes mező együttesen egyedi. Ez lesz a cseretáblánk.

Nem szabad megfeledkeznünk arról, hogy az indexek ilyenkor nem jönnek át a régi táblábból! Ezeket újra el kell vennünk.

Ha ez megtörtént, akkor már csak a cserét kell végrehajtanunk.

DROP TABLE `arak`;
RENAME TABLE `uj_arak` TO arak;

Ennyi az egész.

… még egyszer ránézni a kreatívra, nehogy nemkívánatos asszociációkat ébresszünk. Vagy csak én vagyok túl mocskos?

http://wop.hp.hu/

Tovább…

Mindössze egy sort írok, hogy megköszönjem a zsűrinek, hogy a Goldenblog IT szekciójának 7. helyére mélónak ítélt. Hatalmas megtiszteltetésnek és elismerésnek veszem. Köszönöm, erre nem is számítottam.

Mindenki hallotta már, jövőre jön a Google OS. Kíváncsian várjuk. Meg is születtek az első szkeptikus posztok ezzel kapcsolatban – egyébként pont emiatt praktikusabb titkolni egy projektet, amíg nincs valami kézzel fogható, megszemlélhető, megszaglászható eredménye.

Mi a fikázás (újabban “fikázódás“) fő mondanivalója? Az, hogy senki nem fog használni egy olyan operációs rendszert, ami képességeit tekintve alulmarad a versenytársaktól, pehelysúlyú, “semmire se jó”. Ezzel pedig egyáltlaán nem értek egyet.

A Google mindig is megelőzte korát. Az egyetlen nagy hibája az lehet a ChromeOS-nek, hogy túl hamar jön. Hogyhogy?

Valamikor az 50-es évek elején az IBM-nél úgy számoltak, hogy a világon összesen évi 5 db számítógépre lehet kereslet. A mai szemmel nevetségesnek tűnő elképzelésnek új értelmet ad a 21. század és a szélessávú internet. Annak, hogy a személyi számítógépek (nem csak PC-k) ilyen mértékű technológiai (és mennyiségi) fejlődésen mentek át az elmúlt évtizedekben, egyetlen oka van. A Földet behálózó számítógépes hálózatok fejletlensége. Úgy sávszélesség mint penetráció tekintetében.

A világ a webbel az élén ma affelé tart, hogy egyre kevesebb desktop alkalmazást használunk. Sok felhasználó egyetlen, saját gépén futtatott szoftvere a böngésző. Ott fut a “gémél”, a Spreadsheets, ott a youtube, a facebook. Rengeteg játék van, és sok olyan webes szolgáltatás, amely kiváltja az asztaliakat. Én például már nem használok konvertáló programokat, kizárólag weben. Ráadásul – ami még szebb – egyre kevesebb kód fut le kliens oldalon. Egyre több olyan webes szolgáltatás létezik, ami intenzíven használja az AJAX technológiát akár olyan feladat elvégzésére, ami kliens oldalon is elvégezhető lenne.

A számítási feladatok szépen áttevődnek a szerverekre. Nemsokára nehéz lesz különbséget tenni a webes illetve az asztali felhasználói élmény között, hiszen a webes GUI-k reagálási ideje nagy mértékben meg fogja közelíteni az desktop alkalmazásokét. Csak a vak nem látja, hogy milyen irányba megyünk. Egy fog érkezni az idő, amikor egy átlagos internetkapcsolat sebessége lehetővé teszi, hogy kifogástalan minőségű képet és hangot stream-elünk a szerverről, és késleltetés nélkül küldünk vissza user inputokat. Mintha csak a saját gépünk képét látnánk. Ha ez megvalósul, akkor a teljes számítási teljesítmény áttevődik az óriási szerverparkokra, melyeken videókat játszhatunk le, 3D-t renderelhetünk, dokumentumokat szerkeszthetünk.

Az egész világ egy nagy terminál kliens és szerver tömeg lesz.

Hogy ez miért szükségszerű? Mert az egész rendszer számtalan előnnyel jár; Takarékos - nem kell drága hardverekre költeni a végfelhasználóknak. Nem pazarol az erőforrásokkal – a szerverek számítási teljesítménye sokkal ügyeseben elosztható, mint egy-egy kliensé. Teljes mobilitást biztosít – ugyanazt a teljesítményt érhetjük el mobilon, mint PC-n, és bármelyik terminálhoz odaülve ugyanazt kaphatjuk. Gyors - ha az éppen bérelt szerver teljesítménye nem kielégítő, kibérelek egy helyet egy gyorsabb kiszolgálón mondjuk egy hétre.

Persze ez egy nagyon utópisztikus, középtávlati vízió, de a folyamat már elindult. Ezt pontosan láthatjuk a hardverpiac megtorpanásán, és az olyan próféták lépésein, mint a Google. Szerintem egy pehelysúlyú operációs rendszer, mellyel könnyedén és biztonságosan érhetjük el a webet, ennek a folyamatnak az előfutára. Szükség van rá? Igen. Sikeres lesz? Valószínűleg.

Az összes félelmem tényleg csak annyi, hogy koraszülött lesz a ChomeOS.

Azért elképesztő, ahogy szemrebbenés nélkül képes hazudni egy marketingszakember, amikor arra kérik, hogy próbálja a halva született IE8 rönoméját feltornászni egy kicsit.

http://www.microsoft.com/windows/internet-explorer/get-the-facts/browser-comparison.aspx

Ez egy összehasonlítás a Firefox, a Chrome és az IE8 között figyelembe véve a legfontosabb jellemzőket, amelyeket egy böngészőnél vizsgálhatunk. Ilyen mondatokkal, mint pl. “Of course Internet Explorer 8 wins this one.” Web standards? Nézzünk már meg egy ACID3 tesztet! A legszebb az egészben ez a pipás megjelenítés, ahol a “Developer Tools”-ra egy Firefox üres cellát kaphat. Ur’st’n…

Gyorspost következik.

Nagyon szeretem a singleton design patternt (erre van magyar kifejezés? “egyke tervsablon”?), mert nagyon könnyen összefoghatóak vele egy moduláris PHP rendszer egyes elemei. Olykor felmerül a szükség, hogy semi-singleton (”félegyke???”) osztályokat alkossunk. Mit értek ez alatt?

Olyan osztályokra gondolok, amelyekből bizonyos tulajdonságok alapján csak egy példányt engedünk kreálni, de ha ezek a tulajdonságok eltérnek, akkor lehet belőlük bármennyi. Például egy termékkel kapcsolatban végzett műveletekre használt osztály vagy egy vásárló tranzakcióit nyilvántartó és lebonyolító osztály.

Hogyan csináljunk semi-singleton osztályt? Nagyon egyszerű:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class TermekMuveletek {
	private static $_singleton = array();
	public $termekid;
 
 	private function __construct($termekid) {
		$this->termekid=$termekid;
	}
 
	public static function Get($termekid) {
		if (is_null (self::$_singleton[$termekid])) {
			self::$_singleton[$termekid] = new TermekMuveletek($termekid);
		}
		return self::$_singleton[$termekid];
	}
}

Ennyi az egész. Szebb lenne, ha termekid read-only lenne, de ez PHP-ból csak __set és __get használatával valósítható meg, ami jócskán lassít. Gyorspostunkat olvashatták.