web dizájner

Mostanában nézegetem az álláshirdetéseket és a nézegetés közben találtam ezt a gyönyörűséget:
http://www.graphisoft.hu/ceginfo/allaslehetosegek/web-designer/

Mi a probléma? Aki ezt kiírta nem igazán konyít a témához. Miért?
Webdesigner a szakmán belül a grafikust szokta jelenteni. Nézzük hány szakterület van egy álláshirdetésen belül:

  • “A Graphisoft internetes megjelenésének megtervezése, menedzselése, Weboldalak tervezése, készítése”: ez eddig ok. Bár a készítésnél már rezeg a léc.
  • “adminisztrálása, koordinálása”: Vagyis ő frissíti? Tologaja a cms-t és teszi ki az anyagot?
  • “Weboldalak lokalizálásának menedzselése”: Hát ezt a munkát se szokta grafikus végezni. Vagy Kelemen Gábor egy webdesigner! :)))
  • “Webes marketing kampányok támogatása”: Ez is egy szakterület.
  • “jól ismersz valamilyen webes script nyelvet,”: Ajaj.
  • “keresőoptimalizálási ismeretekkel (Google)”: SEO szaki…

Én ilyeneket olvasva mindig elbizonytalanodom. Most akkor kit is keresnek? Mert lehet, hogy egy 20 kezű mindenhez értő jómunkásembert, de akkor azt ne nevezzük már webgrafikusnak. Legyen mondjuk internetes szakember (Webmanager :)). Vagy jó, legyen webgrafikus de akkor határoljuk csak grafikára a követelményt. Kíváncsiságból belenéztem a szoftverfejlesztő oldalra is. Na! Ott már látszik hogy a cég szakterülete alapvetően a c/cpp szoftverfejlesztés! Nincs is hatalmas mellélövés, csak az ami egy szoftverfejlesztő számára szükséges. Talán egy kicsit kevés is. 🙂

name based virtual host és az ssl

Ezidáig a címben szereplő témára nem igazán volt lehetőség. Az volt a gond, hogy a http protokoll fölött ment az ssl kapcsolat létrehozása, az ssl kapcsolat létrehozásakor viszont a TLS handshake nem közvetítette hogy melyik virtualhosthoz szeretne csatlakozni majdan a http. Kb így zajlik rendesen:
K: Kapcsolódás
Sz: Nyilvános kulcs küldése (host1.hu)
K: Fogadás után a nyilvános kulcs segítségével elkezdi küldeni a titkosított http folyamot.
K: (titkosított adat, host1.hu PK) HTTP Kérés
Sz: (titkosított adat, host1.hu PK) HTTP válasz

Az okosok viszont kitalálták, mi lenne ha a TLS handshake során (mint az SMTP során a hello-val), elküldené azt is a kliens hogy kihez szeretne csatlakozni (host2.hu u.a. mint host1.hu):

K: Kapcsolódás (host2.hu -t küldi, a többi kötelező adat mellett).
Sz: Megkapott adatok alapján host2.hu nyilvános kulcsának küldése.
K: (titkosított adat, host2.hu PK) HTTP Kérés
Sz: (titkosított adat, host2.hu PK) HTTP válasz

Ennek a technikának a neve Server Name Indication (SNI). Mindehhez a TLS 1.1-t kell támogatnia a kliensnek. Nézzük milyen kliensek támogatottak (kapcsolódó wiki alapján):

  • Mozilla Firefox 2+
  • Opera 8.0+ (TLS 1.1-t be kell kapcsolni)
  • Internet Explorer 7+ (csak Vista!)
  • Google Chrome (Vista, XP nem)
  • Safari 3.2.1 Mac OS X 10.5.6

Szerver oldalon:

  • Apache 2.2.12+ vagy mod_gnutls mod_ssl helyett. (OpenSSL esetén 0.9.8f+, j-től default)
  • Utolsó lighttpd

Azok a kliensek akik nem támogatják továbbra is kapják az ssl_error_bad_cert_domain -t a többiek számára megoldódik az ilyen jellegű probléma.
Rossz hír az ubuntusok számára, hogy a Karmic ugyan az apache 2.2.12-t fogja szállítani, viszont OpenSSL-ből csak a 0.9.8f-et ami bizony a funkcionalitás backportja nélkül édes kevés…
Szóval megoldás már van csak meg kell várni míg elterjed!

adatbázis-szerkezet “verziókövetése”

Egy ideig gondot okozott, hogy vajon mivel tudnám a címben lévő problémát orvosolni. Adott az éppen aktuális fejlesztés amihez verziókövetőt használok, viszont az adatbázissal eddig nem sok mindent tudtam csinálni. Önálló részegység aminek a szerkezetváltozása elég nehezen követhető. Volt, eddig. Most úgy tűnik sikerült végre megoldást találnom a problémára.
A megoldást a binlog fogja szállítani. A mysql binlog követi és loggolja az insert update alter és hasonló, változással járó parancsokat. A másik hasznos tulajdonsága amit most használni is fogunk, hogy képes a rendelkezésre álló adathalmazból szűrni adatbázisra és időpontra (tól ig intervallumban is akár). Nézzük hogyan is valósul meg az elképzelés.
Egy fájlba fogunk dolgozni, legyen mondjuk dev/mysql_changes.sql. Ha commitolni akarunk akkor a fájl történetéből ki tudjuk deríteni azt, hogy mikor commitoltunk utoljára, tehát van egy dátumunk. Ezt így kapjuk meg:

user="connor"
revdate="$(svn log dev/mysql_changes.log | grep "| $user |" | awk '{ print $5 " " $6 }' | head -n1)"

M.j.: Ezen a ponton van az első pontatlansága a jelen megvalósításnak, hiszen ha egy futó projectbe érkezik egy új fejlesztő nála ez üres lesz. Így kézzel kellene megadni egy dátumot. Ez a dátum mondjuk lehet a fájl létrehozásának időpontja (hiszen ha saját checkoutja van a fejlesztőnek, akkor a co utáni változásokra vagyunk kíváncsiak). Így ha az elgondolás helytálló akkor ez is megteszi: stat -c “%Z” dev/mysql_changes.log

Majd a kapott dátummal listázunk a binlogokból és szükség esetén commitolunk:

database="folkradio"
mysqlbinlog /var/log/mysql/mysql-bin.0* -d $database --start-datetime="$revdate" | grep -e "^insert" -e "^update" -e "^#" -vi > dev/mysql_changes.log
svn commit -m "adatbázis szerkezet változott" dev/mysql_changes.log

Eddig a fejlesztő oldaláról. A szerver oldalon és az éles rendszeren szintúgy végig lehet szambázni a változásokon. Akkor az “svn log” parancs segítségével értelem szerűen revíziók vagy ágak közötti változásokat kell listáznunk. Ekkor egy ciklusra és az svn cat parancsra van szükség. Mivel viszont a fejlesztés közben adódhatnak hibák és fölösleges kódok a kimenetet éles rendszer frissítése előtt mindenképpen érdemes egy fájlba összehozni és végigfutni. Ha minden rendben akkor lehet rá áment mondani.

Mik az elgondolás hibái?

  • Elgondolás szinten létezik. Gyakorlatba még csak most fogom átültetni.
  • Nem tesztelt.
  • Nem tűri az olyan szerkezeteket ahol az adatbázis táblája, vagy annak sora a program számára fontos elemet tárol, amit szintúgy mozgatni, verziózni kell. Ekkor nyilvánvalóan filter (pl awk) kell a binlog kimenetére amiben táblára is tudunk szűrni.
  • Éles szerver és a fejlesztői szerver scriptjei nincsenek kidolgozva így lehetnek nem látható akadályok

Összességében viszont már így is több mint ami eddig volt. A tapasztalatot a használat fogja meghozni, így ha beválik akkor mindenképpen referálok az elkészült scriptekkel egyetemben.

arc

Megműtötték a bölcsességfogam és egyre csak dagad az arcom. Ha tükörbe nézek eszembe jut a régi vicc:
– Nagymama! Miért olyan nagy az arcod?
– Mert Debiant használok!
🙂

client cert auth és a phpmailer

A Cultura Nostra kapcsán a phpmailer-t ki kellett bővítenem kliens hitelesítés alapú azonosításhoz a szükséges kódokkal. Meglepően egyszerű. Folt az 5.0-hoz.

Használata rém egyszerű:

$mailer = new phpmailer();
$mailer->From = '...';
$mailer->FromName = '...';
$mailer->Host = 'srv.host.hu';
$mailer->Port = 465;
$mailer->SMTPSecure = 'ssl';
$mailer->SMTPAuth = false;
$mailer->SMTPCert = '/path/to/cert.pem';
$mailer->CharSet = 'utf-8';
$mailer->IsSMTP();
$mailer->AddAddress('...');
$mailer->Subject = 'proba';
$mailer->Body = 'body';
$mailer->Send();

El lehetne bonyolítani, hiszen a stream_context_set_option() fv képes kezelni passphrase-t.

wordpress memória használata

Van pár weboldal a szerveren ami WP-t használ. Ezeket rendszerint én tartom karban. Frissítéskor mindegyik elszáll mert nem elég neki 20 Mb memória. Megnéztem mit lehet javítani az ügyön.
A kódot megvizsgálva azt tapasztaltam, hogy a teljes zipet egyszer, és a teljes ziptartalmat még egyszer beolvassa memóriába. Namármost ez nem túl memóriabarát megoldás így kicsit átírtam (trac ide vonatkozó javítása, nevetséges).
A fő ághoz készült javítást megpróbálom majd keresztülnyomni a rendszeren, hátha elfogadják.

csipetnyi bunkóság egy adag tahósággal fűszerezve

Történt az Úr 2009. esztendejének Új kenyér havának 17. napján egy mulatságos, tragikomikus epizód az kedves családom és jómagam életében. Sógoromnak van egy Skodája. Felicia. Benzines. Ez utóbbi tény lesz érdekes történetünk folyamán. Pár napja, tudván hogy előbb-utóbb be fog következni egy tankolás megkérdeztem az autó folyadékszükségletének jellemzőit. Kérdésemre rávágta, hogy dízel. Majd még poénkodott valamit, de mivel az információt már megkaptam több másra már nem figyeltem, lévén birtokában vagyok minden infónak mit nekem más apróság??!
Ma útra keltem üzlettársamhoz vinni és hozni ezt-azt. Indulás előtt a benzinszint jelző alacsony szintje miatt a kagylónál töltöttem bele egy keveset. Szerencsémre csak 5 litert. Dízelt, mi mást?! Eljutottam kerepesre. Majd mikor indultam vón haza az autó nem akarta az igazságot. Egynehány próbálgatás majd az utca aljáig gurulás után feladtam a dolgot szóltam bátyámnak. Kiderült a turpisság és sógorom jó humorát áldva szedtük össze a kellékeket a leszíváshoz és az újratöltéshez. Utólag okos vagyok mert elég lett volna csak rátankolni. Ezt viszont akkor még nem tudtam. Betoltuk az autót egy építkezés bejáratához majd elsétáltunk a szerszámokért és bátyám bevárásába kezdtünk.
Megérkezése után realizáltuk a leszívás próbálgatása után hogy ez biz’ dupla tankos. Nem fog menni. Hajrá hátsó ülés alól kiszedtük a tank szivattyút majd elkezdtük leengedni. Ez így leírva egy mondat kivitelezve kicsit több volt. A leengedés végéhez közeledtén megérkezett sógorom a teherautóval. Már öten szurkoltunk hogy sikerüljön a haditerv. Nem sokra rá megérkezett az építkezés gazdája. Itt kezdődtek az érdekességek. Ahelyett hogy a jóember megkérdezte vón, hogy segíthet-e, mi történt vagy ezek szabad variációi, “ja csak lerobbantak” megjegyzéssel sarkon fordult bevárta a fehér-dzsippes társát és elviharoztak. Láttam már érdekes embereket, no para. Hamarosan végzünk aztán irány haza!
Leszívás után rátöltöttünk egy keveset, majd megpróbáltuk az indítást. Köhögött még ugyan de erős gáz után tisztulni látszott. Leáll, töltés tovább. Ekkor érkezett meg a következő delikvens, a szembe szomszéd. Hogy mi mi a frászt csinálunk itt és hogy kuss és hogy aludni szeretne és hogy gyerek meg mittom én. Mintha mi a hullócsillagok utáni vágyunktól vezérelvén épp bulihoz készülődünk ott és igazából senki nem akart már rég otthon ülni egy üveg sör kíséretében! Zajongani és a környezetben élőket idegesíteni volt éppen kedvünk! Ez már a fáradtságot se vette hogy akármit is megkérdezzen. Nem is azért jött. Ha még vár 5 percet már nem is talált vón ott minket. Fölösleges műbalhé.
Most jönne a dolgok ilyetén summázása: “na ezért tart itt ez az ország”. De inkább ezt most kihagyom. Komolyan ennyire nehéz megkérdezni, hogy “bocs segíthetek?”.
Ha másért nem, azért egy nagy haszna volt ennek a kis kiruccanásnak. Jobb hatással van ránk egy ilyen esti kaland mint egy hetes “teambuilding”. 🙂

kézzel gzippelt tartalom

A mod_gzip és a hasonló on-the-fly tartalomtömörítéssel az a gondom, hogy a processzort eszi (ha nem is nagyon de azért jobban mintha nem tenné). Statikus tartalom esetén is jó ha sávszélességet spórolunk. Ez a megoldás pont ezt a tartalomtípust veszi célba. Ha létezik tömörítve az eredeti helyett azt szolgálja ki, így spórolva a processzoridővel és a sávszélességgel. A megoldás bővíthető a végtelenségig bármilyen fájltípusra.

AddType image/jpg jpg jpgz
AddEncoding gzip jpgz

RewriteEngine on
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_URI} ^(.*).jpg$
RewriteCond %{DOCUMENT_ROOT}%{SCRIPT_FILENAME}.jpgz -f
RewriteRule ^(.*)$ $1.jpgz [L]

mj: ModRewrite debuggolás.
RewriteLog “logpath.log”
RewriteLogLevel 9

tracker magyar stopwords hiba

Úgy tűnik a mai nap a hibakeresésé. 🙂
Tracker-ben ha keresést indítottam a daemon egyszerűen kilépett. Ennyit hagyott maga után:

0xb7ce08f8 in sb_stemmer_stem (stemmer=0x0, word=0x8f4d820 "hup", size=3) at libstemmer.c:91
91  libstemmer.c: No such file or directory.
  in libstemmer.c

A stemmer lib a szótövezésért felelős. A magyart átírva angolra rögtön jó lett. Belenéztem kíváncsiságból a magyar fájlba és azt láttam hogy az utf8 nem áll a helyzet magaslatán. Feltettem egy javított változatot:
http://workshop.connor.hu/src/stopwords.hu

Egyenlőre nem bizonyított, hogy ezért szállt el, az újraindexelés még zajlik.

érdekes vino/xdg hiba

Frissítés óta/egy ideje elkezdte pörgetni a procit az ubuntu. A hibakeresés nyomán oda jutottam, hogy a dbus gconf páros miatt megy átlag közel 50%-os procihasználattal a gép. Mivel sem a dbus sem a gconfd nem lehet önmagában hibás (mind a kettőt használja/hívogatja valami ezért elkezdtem random kilőni a programokat. A vino-server lett a hibás. A vino-server -t a /desktop/gnome/remote_access/enabled kulcs módosítása indítja el/állítja le. Ezt a kulcsot az xdg autostart funkciója figyelia (lásd: /etc/xdg/autostart/vino-server.desktop).
Valahogy sikerült az xdg-nek kétszer elindítania a vino-t. A második indulással mivel a dbus már foglalt volt az adott néven ezért ez a folyamat kilépett. A xdg ezt látva viszont rápróbált és megint elindította. Így végtelen ciklusba került és folyamatosan próbálta indítani a második változatot. Ilyenkor persze dbus-hoz és gconfd-hez próbál csatlakozni, ezért a nagy procihasználat azoknál a programoknál. Egyenlőre úgy tűnik sikerült megjavítani (desktop fájl áthelyezése máshova, X restart, fájl vissza, X restart), de reprodukálni még nem tudtam a hibát. És hogy melyik program a ludas? Jó kérdés. Önmagában a vino nem, hiszen kilép ha kétszer indul. Az xdg talán (?) nem hiszen ha egy program hibával elszáll helyes elvárás, hogy indítsa újra. A kettő találkozásakor ilyen ciklus alakulhat ki. A hiba itt van, no meg ott hogy miért indította kétszer az xdg a folyamatot?!

jetpack tapasztalatok

Pár hete olvastam a mozilla blogban a jetpack kezdeményezésről. Anno a terminológiaszótárnak készíteni akartam egy firefox kiterjesztést. Idő hiányában ez elmaradt, így késztetést éreztem megnézni mit tud ez a jetpack. Ha tényleg gyorsan lehet vele fejleszteni akkor rögtön két legyet ütök egy csapásra. Megnézem mit tud a jetpack és elkészül a kiterjesztés.

Az egész elképzelés arra épít, hogy ha egyszer webesek használják weboldalak fejlesztésére a firefox-ot akkor miért ne lehetne webes eszközökkel firefox kiterjesztést írni? Hogy a fejlesztőnek ne kelljen teljesen új API-t megtanulni, behozták a jquery-t mint JS API, így gyorsítva meg a kezdeti lépéseket. És tényleg! A megírt minta alkalmazások alig nagyobbak pár száz sornál és azok megírásához sem kell több idő mint egy két óra. Tapasztalat, hogy egy hagyományos kiterjesztést megírni, csak a környezet kialakítása ennyi idő (fejlesztésről debuggolásról még szó se esett). A firefox felületi elemeit (fülek, értesítési funkció, állapotsor) a jetpack-en keresztül lehet elérni.

Sajnos a program még nagyon kezdeti fázisban van. Annyira, hogy az ember hol az API alul-dokumentáltságával küzd, hol azzal, hogy az adott funkcióhoz nem létezik API, hol pedig a kettővel egyszerre. Ha mindezt legyőzi, tényleg nagyszerű keretrendszerré válik. Ezek után már csak egy kérdéses rész maradt: hogy lesz a jetpack kiterjesztésből terjeszthető kiegészítő? Azt csak remélni tudom, hogy nem kell majd a felhasználókra rátukmálni a jetpack kiterjesztést ahhoz hogy futtatni lehessen az ebben megírt kiegészítőket…

Szumma szummárum a dolog tetszik! Hajrá mozilla!