Facebook-on nem rég felfedeztem a farmville alkalmazást. Nagy általánosságban elmondható hogy nem játszom. Bár néha amikor már nagyon sok a gőz és elkap a nosztalgia, akkor előveszem az age of empires-t vagy a settlers-t. De ez is minden 20. szökőévben 1x van.
A játék lényege annyi, hogy van egy x*x méretű táblád amire ültethetsz és vásárolhatsz mindenféle kelléket. Kezdetben jól kiszámoltam hogy mit érdemes és mostanra szépen gyarapodó gazdaság van… egy 12*12-es mezőn ami annyit jelent, hogy aratáskor, felásáskor és ültetéskor kell kattintani egyet. Ez ugye 12*12 (-1 mert csak 143 van valójában) * 3 kattintás lenne. Mivel azért továbbra sem vagyok időmilliomos, lusta is egy picit és kiváltképp nem vagyok titkárnő hogy kattintgassak tegnap este írtam egy programot ami mindezt megcsinálja. Már úgyis régóta meg szerettem volna nézni hogy mivel lehet kattintásokat, billentyű leütéseket és egérmozgást imitálni linux alatt. A megoldást a xlib-ben és a gdk-ban találtam meg.
Gdk segítségével nézem meg egy adott pixel színét:

import pygtk
pygtk.require('2.0')

import gtk

screen = gtk.gdk.screen_get_default()
img = screen.get_root_window().get_image(int(x), int(y), 1, 1)
print screen.get_system_colormap().query_color(img.get_pixel (0, 0))

Míg a mozgatást…

from Xlib import display, X, XK

self.display = display.Display()
self.root = self.display.screen().root

pointer = self.root.query_pointer()
pointer.root_x, pointer.root_y

… a kattintást…

#1 left, 2 middle, 3 right
Xlib.ext.xtest.fake_input(self.display, Xlib.X.ButtonPress, 1)
self.display.sync()

Xlib.ext.xtest.fake_input(self.display, Xlib.X.ButtonRelease, 1)
self.display.sync()

és a billentyűleütést az xlib végzi.

Üzleti(bb) felhasználásban is látom némi értelmét a programnak. Komplexebb felületteszteléshez lehet(ne) használni oly módon, hogy a böngésző szabványos csatornán kommunikálva kérné a programtól a műveletet majd ezek után ellenőrizné a végrehajtás eredményét. Így meg lehetne oldani sárkánydobás (drag’n’drop), gépelés, billentyűleütések, egérmozgások (akár gesztikulációk) emulálását és ezáltal webalkalmazások tesztelését.
Több X indítással meg akár tesztfarm létrehozása sem lehetetlen elképzelés.
Másik elvetemült ötlet szerint akár a követett és felvett felhasználói műveletek is visszajátszhatóvá válnak.

connor@tudor:~$ resolveip goolge.hu
IP address of goolge.hu is 193.28.86.55
connor@tudor:~$ resolveip google.hu
IP address of google.hu is 74.125.77.104
IP address of google.hu is 209.85.229.104
IP address of google.hu is 216.239.59.104
connor@tudor:~$ resolveip 193.28.86.55
Host name of 193.28.86.55 is netem.hu

tapasztalatok webprogramozó okj-s tanfolyásról:

infó órán feladat: csináljunk egy szöveges dokumentumot az asztalra
előttem ülő srác a következő:
start -> office -> word
tanár “nem-nem, asztal jobb klikk -> új -> szöveges dokumentum”
srác jobb klikk a start menü gombjára
“nem-nem, felette”
srác jobb klikk az asztal egyik ikonjára
“nem-nem, mellé”
ok, végre megtalálta
csinálni kellett egy vbs scriptet
van benne egy olyan h msgbox
nah srác beírja ‘msg box’
és nem megy
“biztos szar a gép” és újraindította

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. 🙂

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!

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.

gnome-mount -vbd /dev/sdb1

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.

Azért a linux eléggé tűri a hülyeséget:
svn commit -m “csak akkor fusson ha kézzel indítjuk dev/migrate/gallery

… és simán vette hogy mi hova tartozik. (gyk: egy ” van csak)

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”. 🙂

http://thedesigninspiration.com/articles/top-45-creative-anti-smoking-advertisements/ Marha jó!!

Ú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.

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?!

apt-get install libjmac-java

IFS=$’\n’; for i in $(ls *.ape); do java -jar /usr/share/java/jmac.jar d “$i” $(basename “$i” ape)wav; ffmpeg -y -i $(basename “$i” ape)wav -ab 320000 $(basename “$i” ape)mp3; rm *.wav; done