Zoli Ruby programozásról szóló posztján felbuzdulva magam is megosztanám a magyar nyelven elérhető Ruby programozásban segítő és ingyenesen elérhető tananyagok listáját. A Ruby-ról, és a Ruby alapokon nyugvó Rails-ről lesz szó. – De már most itt az elején figyelmeztetnék mindenkit, hogy mielőtt engednénk a kísértésnek, hogy magával ragadjon a Rails csodálatos világa: ne legyünk restek, hogy alaposan ki- és megismerjük a Ruby nyelvet, mert saját tapasztalatból is tudom, hogy minden Rails-el ismerkedni vágyó bicskája ott törik bele, hogy a gyönyörű építmény alapjait nagyon felületesen futotta át.
2010. augusztus 29.
Könyvismertető: Meyer; English Corpus Linguistics
Mivel egyre nagyobb teret nyer az empirikus adatokon alapuló kutatás, természetes hogy egyre többen érdeklődnek a korpusznyelvészet iránt. Meyer könyve nem ígér többet mint hogy bemutatja a korpusznyelvészet területét (az angol nyelvű munkákon keresztül), és ezt korrektül meg is teszi.
188 oldal
Cambridge University Press, 2002
Angol nyelvű
ISBN-10: 052100490X
Charles F. Meyer
Kiknek ajánlható a könyv?
Szerencsére mindenkinek! Nem igényel különösebb nyelvészeti előképzettséget hogy megértse az ember, ezért bátran ajánlható nyelvészeknek akiket érdekel az adatgyűjtés és feldolgozás folyamata, illetve számítástudományi szakemberek is hasznosnak találhatják. Azonban akit a hard core statisztikai elemzése érdekelnek és már rendelkezik biztos alapokkal, csalódni fog mivel ezekkel csak érintőlegesen foglalkozik a könyv.
Pro és kontra
A kötet nagy erénye hogy rengeteg példán keresztül mutatja be hogy a korpusznyelvészeti megközelítés a nyelvészet minden területén alkalmazható - ez alól még a generatív nyelvészet sem kivétel. Ezután a korpusztervezés folyamatát mutatja be, részletesen a közismert Brown, ICE, London-Lund és egyéb korpuszok tervezésével kapcsolatos példákkal illusztrálva milyen problémák merülhetnek fel. A korpusz kompilációjáról és annotációjáról szóló fejezetek már elnagyoltabbak, igaz nehéz is lenne a különböző technikák részletes bemutatása. A kazettás magnók problémáiról szóló részeket manapság már megmosolyogja az ember, de nem szabad elfelejtenünk hogy a legtöbb használatban lévő korpusz beszéltnyelvi részét még bizony ilyen technikával rögzítették és gépelték be. Az ötödik fejezet szól a korpusz használatáról, azaz hogy milyen módon tesztelhetjük hipotéziseinket. Számomra ez a könyv leggyengébb része, mivel teljesen hiányzik a statisztikai módszerek bemutatása. Habár nyilvánvaló hogy a szerzőnek visszafogottan kellett ezt kezelnie egy kezdőknek írt könyvben, és döntése hogy az ún "pseudo-titles" használatának elemzésével egy gyakorlati példát mutat elfogadható, az olvasóban hiányérzetet hagy hogy egy-egy elemzés nevét é eredményét olvashatja, de hogy pontosan mit is fed az a kötetből nem tudja meg.
Összegzés
A kötet mindenkinek ajánlható, ám ára az átlagos magyar olvasónak szerintem magas, ezért inkább a könyvtári kölcsönzését ajánlom. Aki elolvassa kap egy átfogó képet arról mi is az a korpusznyelvészet, mire jó és hogyan dolgoznak a korpusznyelvészek. Senki nem lesz tőle profi nyelvész (persze egy könyv elolvasásától ezt ne is várja senki) és kézikönyvnek sem használható, mivel nem ad pontos recepteket. Viszont remek előkészítés komolyabb munkák befogadásához, vagy párhuzamosan is forgatható pl Gries Quantitative Corpus Linguistics with R kötetével.
2010. augusztus 21.
Kreatív Ruby programozás kezdőknek
Augusztus 19-én a világ, de legalábbis a Ruby-t ismerő része, ünnepelt. A kiváló hacker why the lucky stiff pont egy éve tűnt el a virtuális világból, ám hagyatékát soha nem fogjuk elfelejteni, és hála a lelkes közösségnek, elherdálni sem. Hogy ki is volt _why, arról a neten sokat olvashatsz, a lényeg hogy kiválló pedagógiai érzékkel rendelkezett és sokat tett azért hogy a programozás csodás világa könnyen hozzáférhetővé váljon a fiatalok (és lelkes idősebbek) számára.
Ha szeretnél megismerkedni egy szép, teljesen objektum-orientált szkriptnyelvvel a Ruby remek választás. Könnyű tanulhatósága és megbízhatósága miatt (is) napjainkban nagyon népszerű a webprogramozók körében és az egyik legelterjedtebb framework a Ruby alapú Ruby on Rails. Persze a könnyű tanulhatóság relatív, kinek? Ezt ismerte fel _why. Míg régen a C64-esek világában amikor nagylemezt és magnókazettás beolvasót használtak az emberek és a BASIC és társai voltak a menő nyelvek (és hazánkban a Süni magazinban két oldalas játékprogramok kódjait olvashattad) még egyszerű volt programozni. Nyilván azért is mert nem hatvanhatezer nyelv közül kellet választani, hanem azt használtad ami éppen adott volt, meg nem hatszáz oldal útmutatót adtak a neten a nyelvhez hanem kb tíz oldalon elfért minden. Szépen kipróbálhattad hogy ha ezt csinálod, ezt és ezt az eredményt kapod és ennyi. Most meg törheted a fejedet hogy akkor itt ez van, de akkor egy hibakezelési blokkot is iderakok ami ugye dob egy ilyen hibát vagy mi a szösz és akkor nekem String kell, de nem olyan sima mert az "immutable", hanem amit tudok dinamikusan változtatni és akkor a legvégén még kell egy statikus változó és őőőőőőő.....
Egy kezdőnek nem ez kell! A másik irányzat "lebutított" nyelvekkel próbálkozott. Azok akik ismerik a Java-t gondolják végig hogy az egyszerű inputot milyen körülményes elérni! Sokan pedagógiai célból csomagokat alkottak hogy leegyszerűsítsék ezt és csak a programozás "logikáját" tanítsák. De így nem egy "élő" és "igazi" nyelvet tanul meg az ember. _why nagy ötlete éppen az hogy egy jó nyelvet kiválasztva, annak egy töredékére koncentrálva és a megfelelő eszközöket megalkotva olyan tudást adhatunk a kezdők kezébe amivel már tudnak haladni. Ha nem kell egy évig azon rágódni hogy milyen típus kezelés is megy végbe akkor a programban, hogyan tanulhatom meg egy IDE használatát, a GUI programozás nem jelent egy szinte teljesen új nyelvet, ha a webprogramozás és az MVC keret tényleg csak egy megközelítési mód és nem megint egy új probléma, akkor a tanuló képes tényleg alkotni, felfedezni. Ha van visszacsatolás, ha képes a tanuló pozitív élményként megélni a programozás folyamatát, akkor gyorsabban fog haladni, bátrabban fedezi fel a számára ismeretlen területeket és sokkal magabiztosabb és kreatívabb lesz.
Eszközök
Egy kezdők számára készített programozási környezet, ami nem csak a programok szerkesztését könnyíti meg, hanem futtatni is lehet benne az elkészült művet.
A legegyszerűbb és szerintem legintuitívabb GUI amit valaha készítettek. Elég egy kis Ruby tudás, és remek grafikus felülettel ellátott programokat készíthetünk vele. A HacketyHack rendszerbe integrálták a készítők, de önállóan is használható.
A Ruby on Rails kistestvére. Kevesebb mint 4kB a forráskódja mégis használható oldalakat programozhatunk vele. Az MVC filozófiát követi, mégis mellőz minden olyan elemet ami csak túlbonyolítja a dolgokat egy kezdő számára. A Heroku ingyenes tárhelyet is biztosít Camping appjeink számára, feltöltés előtt érdemes elolvasni ezt a kis tutorialt.
Olvasnivaló
Ne egy hagyományos könyvet várj! Nem ez egy posztmodern alkotás, ami (sajnos) nem emészthető mindenkinek. Semmi gond! Ha nem érted, nyugodtan használhatsz más forrást. Gondolom a címéből kiderül hogy a Ruby nyelvbe vezeti be olvasóját.
A Poignant Guide stílusában, a Shoes használatába nyújt bevezetést. (A link egy pdf verzióra mutat).
Összegzés
_why hagyatéka rendkívül szerteágazó (pl a Poignant Guide-hoz még zenei CD-t is készített!). Kétségkívül szoftverei nagyobb hatást értek el (nem csak pedagógiai fejlesztései, hanem a Ruby gems-ei is!), stílusa azonban sokak számára érthetetlen. Ezen nem kell csodálkozni és szerintem felesleges vitatkozni, akinek nem tetszik, az olvassa Chris Pine Learn to Program könyvét, vagy annak netes verzióját. A legfontosabb ami ránk maradt a hozzáállás. A programozás világát sokan azért szerették meg mert nyílt, demokratikus és meritokratikus egyben. Bárki elkezdheti a tanulást viszonylag kis befektetéssel, a neten formálódó közösségek nyíltak és segítőkészek és mindenkit érdemei szerint ismernek el. Azon lehet vitatkozni hogy tényleg veszélyben vannak-e ezek az alapértékek, de nem árt ha megjegyezzük bizony ezek egy nyílt és demokratikus társadalom jellemzői is. A programozással nem csak szakmát tanulhat az ember, hanem kreatív módon kifejezheti magát, megtanul másokkal együttműködni és elviselni a kritikát.
A számítógépes nyelvészet és digitális bölcsészet iránt érdeklődők számára mindenképp hasznos tapasztalat a Ruby elsajátítása, különösen az objektum orientált paradigma alapjainak megismerése. Sajnos azonban a közösség a nyelvészeti munkákhoz használatos könyvtárak és csomagok fejlesztésében nem jeleskedik és kezdőknek nagyon nehéz maguknak megírni ezeket, ezért ajánlatos az alapok elsajátítása után az nltk-ra átnyergelni.
Ha szeretnél megismerkedni egy szép, teljesen objektum-orientált szkriptnyelvvel a Ruby remek választás. Könnyű tanulhatósága és megbízhatósága miatt (is) napjainkban nagyon népszerű a webprogramozók körében és az egyik legelterjedtebb framework a Ruby alapú Ruby on Rails. Persze a könnyű tanulhatóság relatív, kinek? Ezt ismerte fel _why. Míg régen a C64-esek világában amikor nagylemezt és magnókazettás beolvasót használtak az emberek és a BASIC és társai voltak a menő nyelvek (és hazánkban a Süni magazinban két oldalas játékprogramok kódjait olvashattad) még egyszerű volt programozni. Nyilván azért is mert nem hatvanhatezer nyelv közül kellet választani, hanem azt használtad ami éppen adott volt, meg nem hatszáz oldal útmutatót adtak a neten a nyelvhez hanem kb tíz oldalon elfért minden. Szépen kipróbálhattad hogy ha ezt csinálod, ezt és ezt az eredményt kapod és ennyi. Most meg törheted a fejedet hogy akkor itt ez van, de akkor egy hibakezelési blokkot is iderakok ami ugye dob egy ilyen hibát vagy mi a szösz és akkor nekem String kell, de nem olyan sima mert az "immutable", hanem amit tudok dinamikusan változtatni és akkor a legvégén még kell egy statikus változó és őőőőőőő.....
Egy kezdőnek nem ez kell! A másik irányzat "lebutított" nyelvekkel próbálkozott. Azok akik ismerik a Java-t gondolják végig hogy az egyszerű inputot milyen körülményes elérni! Sokan pedagógiai célból csomagokat alkottak hogy leegyszerűsítsék ezt és csak a programozás "logikáját" tanítsák. De így nem egy "élő" és "igazi" nyelvet tanul meg az ember. _why nagy ötlete éppen az hogy egy jó nyelvet kiválasztva, annak egy töredékére koncentrálva és a megfelelő eszközöket megalkotva olyan tudást adhatunk a kezdők kezébe amivel már tudnak haladni. Ha nem kell egy évig azon rágódni hogy milyen típus kezelés is megy végbe akkor a programban, hogyan tanulhatom meg egy IDE használatát, a GUI programozás nem jelent egy szinte teljesen új nyelvet, ha a webprogramozás és az MVC keret tényleg csak egy megközelítési mód és nem megint egy új probléma, akkor a tanuló képes tényleg alkotni, felfedezni. Ha van visszacsatolás, ha képes a tanuló pozitív élményként megélni a programozás folyamatát, akkor gyorsabban fog haladni, bátrabban fedezi fel a számára ismeretlen területeket és sokkal magabiztosabb és kreatívabb lesz.
Eszközök
Egy kezdők számára készített programozási környezet, ami nem csak a programok szerkesztését könnyíti meg, hanem futtatni is lehet benne az elkészült művet.
A legegyszerűbb és szerintem legintuitívabb GUI amit valaha készítettek. Elég egy kis Ruby tudás, és remek grafikus felülettel ellátott programokat készíthetünk vele. A HacketyHack rendszerbe integrálták a készítők, de önállóan is használható.
A Ruby on Rails kistestvére. Kevesebb mint 4kB a forráskódja mégis használható oldalakat programozhatunk vele. Az MVC filozófiát követi, mégis mellőz minden olyan elemet ami csak túlbonyolítja a dolgokat egy kezdő számára. A Heroku ingyenes tárhelyet is biztosít Camping appjeink számára, feltöltés előtt érdemes elolvasni ezt a kis tutorialt.
Olvasnivaló
Ne egy hagyományos könyvet várj! Nem ez egy posztmodern alkotás, ami (sajnos) nem emészthető mindenkinek. Semmi gond! Ha nem érted, nyugodtan használhatsz más forrást. Gondolom a címéből kiderül hogy a Ruby nyelvbe vezeti be olvasóját.
A Poignant Guide stílusában, a Shoes használatába nyújt bevezetést. (A link egy pdf verzióra mutat).
Összegzés
_why hagyatéka rendkívül szerteágazó (pl a Poignant Guide-hoz még zenei CD-t is készített!). Kétségkívül szoftverei nagyobb hatást értek el (nem csak pedagógiai fejlesztései, hanem a Ruby gems-ei is!), stílusa azonban sokak számára érthetetlen. Ezen nem kell csodálkozni és szerintem felesleges vitatkozni, akinek nem tetszik, az olvassa Chris Pine Learn to Program könyvét, vagy annak netes verzióját. A legfontosabb ami ránk maradt a hozzáállás. A programozás világát sokan azért szerették meg mert nyílt, demokratikus és meritokratikus egyben. Bárki elkezdheti a tanulást viszonylag kis befektetéssel, a neten formálódó közösségek nyíltak és segítőkészek és mindenkit érdemei szerint ismernek el. Azon lehet vitatkozni hogy tényleg veszélyben vannak-e ezek az alapértékek, de nem árt ha megjegyezzük bizony ezek egy nyílt és demokratikus társadalom jellemzői is. A programozással nem csak szakmát tanulhat az ember, hanem kreatív módon kifejezheti magát, megtanul másokkal együttműködni és elviselni a kritikát.
A számítógépes nyelvészet és digitális bölcsészet iránt érdeklődők számára mindenképp hasznos tapasztalat a Ruby elsajátítása, különösen az objektum orientált paradigma alapjainak megismerése. Sajnos azonban a közösség a nyelvészeti munkákhoz használatos könyvtárak és csomagok fejlesztésében nem jeleskedik és kezdőknek nagyon nehéz maguknak megírni ezeket, ezért ajánlatos az alapok elsajátítása után az nltk-ra átnyergelni.
2010. augusztus 14.
Piac és Oktatás: a nyelvtechnológia Magyarországon
A napokba interjút készíthettünk Jóföldi Endrével, a Weblib egyik ügyvezetőjével, az általunk is naponta szemlézett Kereső Világ blog szerzőjével. A Weblib.hu címen tájékozódhattok az „okos keresők” specialistájaként ismert cég teljes profiljáról. Technológiájuk és termékeik például a Polymeta keresőjük, a PolySpell, a helytelenül megadott keresőszavak kiszűrésére és korrigálására szolgáló rendszer, megemlítendő, és megemlítésre méltó a HealthMash, az egészségügyi tudásbázisuk. Továbbá talán a legismertebb pedig a Johu.hu keresőrendszerük, ami mindenki számára elérhető, használható már évek óta az Interneten.
Megkezdődik tehát a folytatásos interjúsorozatunk, ahol igyekszünk a nyelvtechnológiával foglalkozó, abban érdekelt emberek, cégek legtöbbjét megszólaltatni, hogy a lehető legszélesebb körben és mélységben ismerkedhessünk meg az interjúkban legtöbbet firtatott hazai oktatás és a piac kapcsolata, a kezdőkkel szembeni elvárások és úgy általában a nyelvtechnológiai ipar állapotáról.
1) Sok bölcsészkaron nyelvszakosok, magyarosok, pszichológusok és nyelvészet főszakosok számára felvehető a nyelvtechnológia minor. Viszont nem tudják hogy mennyire ismert ez az ipar számára, jelent-e valamit, tudják-e a munkáltatók hogy mit várhatnak egy ilyen végzettségű emberkétől? Jelent-e egyáltalán valamit, vagy csak mérnök-informatikus, programtervező informatikus végzettséggel érdemes próbálkozni. Ide sorolnánk továbbá a nagy kérdést is: BA/BSc vagy MA/MSc nélkül ne is induljanak állást keresni ezen a területen?
Ez valószínűleg a cégmérettől is függhet. Számunkra, akik egy egészen kicsi 10 fő alatti cég vagyunk nyilván nagyon fontos, hogy lehetőleg minél univerzálisabb emberek legyenek a cégünkben. Tehát egyelőre nem nagyon engedhetjük meg magunknak, hogy valaki csak elméleti szinten értsen a nyelvtechnológiához. Mindenképpen előnyös, ha legalább gyors prototípusokat tud készíteni valamilyen elméleti kérdés gyakorlati megvalósíthatóságának igazolására.
2) Sok nyelvész és nyelvtechnológus hallgató vágott bele (és leveleik szerint szerezte meg) a Sun Certified Java Programmer illetve a mySQL Developer/Associate certifikátokba. Ahogy kivettem a levelekből, így szeretnék kiemelni magukat, hogy nem csak az egyetemen oktatott prolog és python iránt érdeklődnek és ismerik, hanem a de facto standard Java nyelvet, és rendelkeznek adatbázis kezelési ismeretekkel is (ami hiányzik a tantervükből). Van értelme, hogy megszerezték ezeket a papírokat? Számít valamit? Van még valami, amit érdemes megszerezniük?
A programozási gyakorlatban természetesen van értelme a hasonló papíroknak, bár természetesen minket a gyakorlatban valóban alkalmazható tudás érdekel. Kevésbé az, hogy van-e hasonló papírja. Az tény, hogy a felsőfokú szintű informatikai, illetve programozó matematikusi oktatás szemléletbeli dolgokat is megtanít optimális esetben, amit a gyorstalpalók kevésbé. Az SQL illetve Java ismeretek mindenképpen nagyon fontosak, hiszen ezek az eszközök amivel a valóságban általában dolgoznak ezeken a problémákon. Persze a keresés során már legtöbbször el kell szakadni az SQL-től, de az adatok összegyűjtése és előfeldolgozása során mindenképpen szükség van rá.
3) Az informatikus olvasók arra panaszkodnak, hogy habár tanulnak mesterséges intelligenciát és nyelvfeldolgozást, ez inkább elméleti és hiányzik nekik a gyakorlati oldal a képzésből. Meglepő, de az érdeklődők még a nyelvtechnológusoknál is pesszimistábbak, nekem úgy jön le, hogy ők jobban látják a hiányosságaikat. Sokukat érdekli, hogy érdemes-e akár spontán írni a nyelvtechnológiai cégeknek és gyakorlati lehetőség iránt érdeklődni.
Sajnos itt a cégméret komoly problémát jelent. Egy hozzánk hasonló mikrocégben nincsenek meg a szükséges létszámbeli erőforrások ahhoz, hogy valakinek könnyedén gyakorlati időt tudjunk biztosítani. Ezzel együtt nem zárkóznánk el olyantól például, ha valaki akár kutatási vagy éppen Phd témát keres és valami olyannal szeretne foglalkozni, ami akár aztán gyakorlati módon egy valódi működő keresőrendszer részévé válhatna.
4) Szintén az informatikus olvasók kérdezik érdemes-e nekik a nyelvtechnológia minort felvenni? Azt vettem ki, hogy nagyon érdekli őket a téma, de nem tudják, hogy megéri-e ezt ilyen formális keretbe terelni (és időt, fáradtságot meg némi pénzt fektetni ebbe)?
Nem követtem, hogy milyen más minorok vannak, tehát ez függ nyilván az érdeklődéstől. Számunkra úgy tűnik, hogy csak nyelvtechnológiából nem egyszerű a magyar piacon megélni. Mi éppen ezért a kezdetektől fogva külföldre dolgoztunk. Ha valaki tehát ilyen irányban indul, akkor rögtön érdemes az angol nyelvterülettel (is) foglalkoznia, hiszen valószínűbb, hogy a gyakorlatban angol nyelvi megoldásokra lesz szükség.
5) Milyen egy ideális pályakezdő jelölt egy nyelvtechnológiai cégnél? Tudom, hogy ez túl általános, de körülbelül milyen is legyen?
Megint csak saját szemszögből megközelítve. Elvárás, hogy önállóan tudjon témákat kutatni, angolul is abszolút olvasás és ha csak lehet írásképes is legyen. Képes legyen a témából néhány oldalas összegzést, és aztán implementációs tervet is készíteni, ami aztán a programozók munkájának alapja lehet. Az nagy előny, ha tud valamilyen eszközzel gyors prototípusok készítésére, ahol kipróbálhatok pl egy témában a különböző algoritmusok és teljes kidolgozásra éppen ezért csak a már valószínűleg beváló megoldás kell, hogy kerüljön.
6) Hogyan lehet egyáltalán a „tűz közelébe kerülni”? Miért nem hirdetnek az ismert cégek a nagy állásportálokon? Miért nincs sok cégnek a honlapján információ a karrierlehetőségekről? Ennyire zárt ez az ipar?
Nem könnyű a terület. A magyar nyelvű piac rendkívül kicsi, az igényesebb, több munkával járó és éppen ezért természetesen drágább megoldásokat nem könnyű eladni, hiszen a megtérülést egy ilyen kis piacon nehezebb produkálni. Ha valaki pedig nemzetközi vizekre evez Magyarországról elindulva, akkor hamarosan azzal kell szembesülnie, hogy az ottani kis cégek nagyobbak a mi nagy cégeinknél. Tőkeerő és fejlesztési kapacitás tekintetében ez mindenképpen komoly korlát.
7) Számít-e hogy hol végzett az ember? A vidékieket ez különösen érdekli, ők a levelek alapján azt hiszik hogy a Pesten tanulók szereznek gyakorlatot a képzés során (hisz a nyelvtechnológiai cégek 99%-ban ott vannak és hátha bekerülnek a srácok ott).
A végzés helye elsősorban a diploma minősége miatt számít. Ezt a felvételi ponthatárok idén is elég jól tükrözték. Nézzétek meg például a mérnök informatika szakok ponthatárait. Sok helyen rendkívül alacsony. Szerintem nem véletlenül.
Köszönjük Jóföldi Endrének, hogy válaszolt a kérdéseinkre! Hozzá segítve minket a számítógépes nyelvészet piacának feltérképezéséhez, és betekintést engedve olvasóinknak a piaci igények felmérésében egy hazai cég, a Weblib szempontjából.
2010. augusztus 12.
Hogyan tovább? - mihez kezdhet magával a magunkfajta
Az elmúlt hetekben rengeteg levelet kaptunk (köszönjük). Sokan kértek egy kis útmutatást hogy mit is csinál egy számítógépes nyelvész, milyen esélyei vannak a munkaerőpiacon, mit kell tudnia és merre mehet tovább valaki egy nyelvész BA vagy infós BSc után. A blognak nem célja hogy pályaválasztási tanácsadással és munkaerő közvetítéssel foglalkozzon, de a kérdéseket megértjük és elfogadjuk. Amit mi tehetünk értetek megtettük!
Elindult egy sorozat, Toma Tasovac írásával kezdődött. Ebben ismerőseinket kérjük fel hogy röviden írjanak munkájukról. Reméljük hogy így egy kis képet kaptok arról ki-mit csinál ezen a területen, mennyire színes és változatos kedvenc elfoglaltságunk. A sorozatban főleg az akadémai világban mozgó emberek munkáját tudjuk bemutatni, mivel ismerőseink között a kutatók vannak többségben, de keressük a lehetőséget hogy másokat is elérhessünk.
Hamarosan felkerül első interjúnk, a magyar nyelvtechnológiai ipar szereplővel készített sorozatunkból. Nem tettünk mást mint a tipikus kérdéseiteket összeszedtük és elküldtük pár hazai cégnek. Reméljük ezzel is segíteni tudunk nektek.
Sajnos ennyi telt tőlünk, reméljük az írásokat élvezni fogjátok és valami hasznosat is találtok majd bennük. A következő írás a témában Jóföldi Endrével (Kereső Világ, WebLib) folytatott beszélgetésünk, amit szombaton töltünk fel.
Elindult egy sorozat, Toma Tasovac írásával kezdődött. Ebben ismerőseinket kérjük fel hogy röviden írjanak munkájukról. Reméljük hogy így egy kis képet kaptok arról ki-mit csinál ezen a területen, mennyire színes és változatos kedvenc elfoglaltságunk. A sorozatban főleg az akadémai világban mozgó emberek munkáját tudjuk bemutatni, mivel ismerőseink között a kutatók vannak többségben, de keressük a lehetőséget hogy másokat is elérhessünk.
Hamarosan felkerül első interjúnk, a magyar nyelvtechnológiai ipar szereplővel készített sorozatunkból. Nem tettünk mást mint a tipikus kérdéseiteket összeszedtük és elküldtük pár hazai cégnek. Reméljük ezzel is segíteni tudunk nektek.
Sajnos ennyi telt tőlünk, reméljük az írásokat élvezni fogjátok és valami hasznosat is találtok majd bennük. A következő írás a témában Jóföldi Endrével (Kereső Világ, WebLib) folytatott beszélgetésünk, amit szombaton töltünk fel.
2010. augusztus 9.
The Anxiety of Digital Humanities
A guest post by Toma Tasovac
Digital humanities is an anxiety-ridden set of practices at the intersection of humanities research and computer technology. But the worst thing that could befall DH is forced collective psychotherapy or free prescriptions for Prozac. As long as we are anxious, we will try to find new and interesting things to do.
Zoltan asked me to write a post about my work in field of digital humanities (DH) and I am happy to do so. Not because I know ahead of time what I will say, but because thinking about one's own work -- and by thinking, i mean: reasoning more or less comprehensibly, without necessarily writing a multi-volume, self-aggrandizing novel -- is a fun and useful exercise. Mostly for myself.
DH is an anxiety-ridden set of practices at the intersection of humanities research and computer technology. It is an exciting but troubled discipline-in-the-making, uncertain about its own boundaries and purpose. Is it a field or a fad? Does it have a future or is it the future? Is it "emerging" or simply "peripheral"? Practitioners of DH are no weirder than your average academic (who is, by the standards of the "outside world" already pretty weird), but I think that an average DHer hears more voices in their head than a typical Slavist, for instance. With some notable exceptions.
The DH community is obsessed with trying to justify what it is that they are doing. A great deal of that soul-searching is unfortunately not very soulful: it is prompted by academic power games, grant opportunities and vicious self-promotion. But some aspects of this disciplinary (and sometimes undisciplined) introspection are fascinating: What should we do with a million books? Is there such a thing as a philosophy of text encoding? What are the limits of digital representation? What is digital history?
Academia in general is anxiety central: a place where insecure and often snobbish people disguise their distaste for manual labor as a kind of intellectual and quasi-moral superiority. The anxiety of digital humanities, however, is better: it is the anxiety about the very basics of professional intellectual work and models of representation and self-representation. Not being entirely certain about one's status or level of academic acceptance keeps one alert, active and safely tucked away from the oceanic feeling of complacency. That is why the worst thing that could happen to DH is forced collective psychotherapy or free prescriptions for Prozac. As long as we are anxious, we will try to find new and interesting things to do.
In my own work, I focus on a traditional tool of humanistic research: the dictionary, both as a material object, cultural product and a model of language. In lexicographic literature, you will find very little anxiety about what a dictionary is: it is usually defined as a list of words with some kind of explanation attached to them. For me, however, the dictionary is first and foremost a kind of text. As such, it is already a problem: a meaning potential that can be realized though its use, but also a field of contradictions that can not always be reconciled. That is why my work is focused on the interplay between electronic textuality and our notion of what a dictionary is (and ought to be). I am exploring ways in which the methods of digital humanities and digital libraries could alter our idea of what a dictionary can (and should) do.
At the Belgrade Center for Digital Humanities, we are working on a Wordnet-based bilingualized Serbian-English dictionary that will be deployed as a web service to interact with digital libraries. That project is called Transpoetika. We have also started digitalizing Serbian historical dictionaries with the goal of exploring the creation of a Serbian meta-dictionary. I am interested not only in the interaction of digital texts and digital dictionaries, but also in lexicographic serendipity: the Transpoetika dictionary, for instance, uses Twitter feeds as sources of "live quotes" and tagged Flickr images as on-the-fly illustration. Our experiment in lexicographic community-building called Reklakaza.la ("Hearsay") has drawn more than 22,000 fans on Facebook.
And, still, we are only at the very beginning. I have no idea how far we will be able to go and where we will end up. I don't know which of our experiments will be successful and which will fail: lexicographic text mining or dictionary visualizations? Spatial mappings of the lexicon or ludic explorations of the dictionary's narrative potential? What I do know for certain is that I have become good friends with my own anxiety and that I plan to keep that relationship going as long as I can.
Digital humanities should embrace their anxiety, too.
About the author
Toma Tasovac has a B.A. in Russian Literature from Harvard and M.A. in Comparative Literature from Princeton. He is the director of the Belgrade Center for Digital Humanities, a media trainer for DW-Akademie in Berlin and Bon, and a self-proclaimed dictionary freak. He meddles into all sorts of things, mostly digital.
Digital humanities is an anxiety-ridden set of practices at the intersection of humanities research and computer technology. But the worst thing that could befall DH is forced collective psychotherapy or free prescriptions for Prozac. As long as we are anxious, we will try to find new and interesting things to do.
Zoltan asked me to write a post about my work in field of digital humanities (DH) and I am happy to do so. Not because I know ahead of time what I will say, but because thinking about one's own work -- and by thinking, i mean: reasoning more or less comprehensibly, without necessarily writing a multi-volume, self-aggrandizing novel -- is a fun and useful exercise. Mostly for myself.
DH is an anxiety-ridden set of practices at the intersection of humanities research and computer technology. It is an exciting but troubled discipline-in-the-making, uncertain about its own boundaries and purpose. Is it a field or a fad? Does it have a future or is it the future? Is it "emerging" or simply "peripheral"? Practitioners of DH are no weirder than your average academic (who is, by the standards of the "outside world" already pretty weird), but I think that an average DHer hears more voices in their head than a typical Slavist, for instance. With some notable exceptions.
The DH community is obsessed with trying to justify what it is that they are doing. A great deal of that soul-searching is unfortunately not very soulful: it is prompted by academic power games, grant opportunities and vicious self-promotion. But some aspects of this disciplinary (and sometimes undisciplined) introspection are fascinating: What should we do with a million books? Is there such a thing as a philosophy of text encoding? What are the limits of digital representation? What is digital history?
Academia in general is anxiety central: a place where insecure and often snobbish people disguise their distaste for manual labor as a kind of intellectual and quasi-moral superiority. The anxiety of digital humanities, however, is better: it is the anxiety about the very basics of professional intellectual work and models of representation and self-representation. Not being entirely certain about one's status or level of academic acceptance keeps one alert, active and safely tucked away from the oceanic feeling of complacency. That is why the worst thing that could happen to DH is forced collective psychotherapy or free prescriptions for Prozac. As long as we are anxious, we will try to find new and interesting things to do.
In my own work, I focus on a traditional tool of humanistic research: the dictionary, both as a material object, cultural product and a model of language. In lexicographic literature, you will find very little anxiety about what a dictionary is: it is usually defined as a list of words with some kind of explanation attached to them. For me, however, the dictionary is first and foremost a kind of text. As such, it is already a problem: a meaning potential that can be realized though its use, but also a field of contradictions that can not always be reconciled. That is why my work is focused on the interplay between electronic textuality and our notion of what a dictionary is (and ought to be). I am exploring ways in which the methods of digital humanities and digital libraries could alter our idea of what a dictionary can (and should) do.
At the Belgrade Center for Digital Humanities, we are working on a Wordnet-based bilingualized Serbian-English dictionary that will be deployed as a web service to interact with digital libraries. That project is called Transpoetika. We have also started digitalizing Serbian historical dictionaries with the goal of exploring the creation of a Serbian meta-dictionary. I am interested not only in the interaction of digital texts and digital dictionaries, but also in lexicographic serendipity: the Transpoetika dictionary, for instance, uses Twitter feeds as sources of "live quotes" and tagged Flickr images as on-the-fly illustration. Our experiment in lexicographic community-building called Reklakaza.la ("Hearsay") has drawn more than 22,000 fans on Facebook.
And, still, we are only at the very beginning. I have no idea how far we will be able to go and where we will end up. I don't know which of our experiments will be successful and which will fail: lexicographic text mining or dictionary visualizations? Spatial mappings of the lexicon or ludic explorations of the dictionary's narrative potential? What I do know for certain is that I have become good friends with my own anxiety and that I plan to keep that relationship going as long as I can.
Digital humanities should embrace their anxiety, too.
About the author
Toma Tasovac has a B.A. in Russian Literature from Harvard and M.A. in Comparative Literature from Princeton. He is the director of the Belgrade Center for Digital Humanities, a media trainer for DW-Akademie in Berlin and Bon, and a self-proclaimed dictionary freak. He meddles into all sorts of things, mostly digital.
2010. augusztus 6.
Könyvismertető: Getting Started with Processing
Sokan kérték hogy egy egyszerű, mindenki számára érthető bevezető könyvet ajánljak. Dióhéjban: a Processing nyelvet egyszerűen, példákon keresztül el lehet sajátítani akár egyedül is, hiszen alapvetően vizualizációkat készít vele az ember és "látásra"
el tudjuk dönteni hogy azt érte-e el a kódunk amit akartunk. A Processing-et tekinthetjük speciális Javanak, elsajátítása után könnyen áttérhetünk a nagy testvér használatára is. Ne feledjük azt sem hogy nagyon szórakoztató bütykölni egy ilyen nyelvet!
Mi is az a Processing?
Saját ön meghatározása szerint a Processing " is an open source programming language and environment for
people who want to create images, animations, and interactions" azaz egy nyílt forráskódú programozási nyelv és környezet azok számára akik képeket, animációkat és interakciókat akarnak készíteni.
Ezt a meghatározást nem árt kiegészíteni. A szokványos komparatív programnyelv tanulmányokban két táborra oszlanak a szakik a Processing kapcsán. Mivel a Processing sokkal inkább egy környezet (egy IDE és pár hasznos cucc) és egy Java könyvtár, hiszen majdnem 100%-ban standard Java szintaxist használ, Java byte code-ot produkál és a JVM-en fut. Ugyanakkor nem tiszta Java, mind a strukturált, mind az objektum orientált paradigmát támogatja. Ha ehhez még hozzá vesszül hogy akadnak egyéb JVM-en futó nyelvek (Groovy, Scala, Clojure) akkor csak nagyobb a homály. Maradjunk annyiban hogy a Processinget itt nyelvnek nevezzük és észben tartjuk szoros kapcsolatát a Javahoz.
Minek nekünk egy újabb nyelv?
Szerintem gyakran ennek nincs más oka mint hogy a készítő szeretett volna egy saját nyelvet, ami neki megfelel. A Processing alapvetően Casey Reas és Ben Fry fejéből pattant ki, akik híres MIT Media Lab-ben John Maeda doktoranduszai voltak. Maeda a kilencvenes években érdeklődött hogy miképp lehetne a digitális művészek, dizájnerek és nem-programozók számára megkönnyíteni a belépést a programozás világába, ennek eredménye lett a Design by Numbers nyelv lett, ami habár már nem egy aktív projekt, inspirálta a Processing alkotóit.
Reas és Fry koncepciója szerint a nem technikai háttérrel rendelkező (de kellően motivált) alkotó emberek nem egy játékot akarnak. Egy eszközre van szükségük, amivel elintézhetik amit akarnak. Többek között ezért nem áldozhatták fel a gyorsaságot (ne feledjük egy grafikus program bizony számításigényes) és választották a Java-t kiindulási alapul. Ugyanakkor törekedniük kellett a használhatóságra, amit szerintem az egyszerű programozási környezettel el is értek. Habár a Processing megengedi hogy a feladat nehézsége és tudásunk szintje szerint megválasszuk milyen paradigmát használunk (szimpla parancsokat adunk, procedurális modorban függvényeket definiálunk vagy objektum orientáltan alkotunk) a használó nagyon gyorsan el fog jutni az OO módhoz ha naponta pár kis programot megír. Így habár egy kontinuumot képzelhetünk el az első Processing sketch és az első Java programunk között, sokan megmaradnak a rugalmas környezetben.
Fontos kiemelni hogy pedagógiai szempontból is jó ötlet egy grafikus programozási nyelvvel kezdeni. Hasonló elveken (csak más korosztálynak) épült fel a Scratch is. Ha a kód manipulálását direkt vizuális visszajelzés követi egyszerűbben és gyorsabban halad a programozás elsajátítása is.
Nézzük a könyvet
A könyv vékony és nem is olyan drága, sok ábrával és példa programmal van megspékelve, vizuálisan kifejezetten hívogató. Nem is beszélve hogy a Processing két atyja mint szerző meggyőzőnek hangzik. Egy ilyen vékony kötettől persze ne várja senki hogy hacker lesz mire a végére ér, de ha valaki szépen végig csinálja a példa programokat és veszi a fáradságot hogy egy kicsit módosítgassa őket, akkor képes elsajátítani mind a Processing nyelv, mind pedig a programozás alapjait (mi egy változó, mi az hogy iteráció, kondicionális, mi a különbség egy osztály és egy objektum között stb). Ennél nem is ígérnek többet a szerzők az előszóban.
Grafikus nyelvként az alapokkal indul a könyv (pont, vonal, kör koordinátákkal való képernyőre rajzolása), majd szépen halad az alapvető kontroll struktúráktól az osztályokig. Minden fejezet végén egy nagyobb projekt várja az olvasót; egy robotot készíthetünk ami egyre szebb és több képességgel rendelkezik. Ez nem csak mókás, de meg is mutatja hogyan használhatjuk egy hosszabb kódban (vagy mini projektben) megszerzett tudásunkat.
Az utolsó fejezet inkább arról szól hogy merre tovább, alapvetően az Arduino és a processing honlapja ajánlható ha tényleg jobban el akarsz mélyedni ezen a területen, de nem árt persze elolvasni azt a néhány oldalt.
Pro és kontra
Ami nekem kifejezetten tetszett az egyrészt hogy tele van a könyv jó tanácsokkal, apró trükkökkel hogyan kell programozni (kommenteld ki a kód egy részét, használd a println() függvényt hogy lásd a koordinátákat stb) és egy külön függeléket szentelnek a további, általános praktikáknak. Mivel a a változók hatóköre sokszor okoz problémát a kezdők számára, ennek is külön függeléket szántak, továbbá a különböző beépített típusoknak is, érdemes ezt a részt elővenni ha valami nem világos. Ez már csak azért is fontos, mert a könyvben gyakran találkozunk olyan változó deklarációkkal amikor nincs érték rendelve a változóhoz explicite (sőt ez tovább van bonyolítva egy autoincrement operátorral is).
Összevetve más könyvekkel
Természetesen nem ez az egyetlen jó könyv amiből megtanulhatsz programozni és a Processinget használni. A Processing honlapján találsz egy komplett listát a megjelent (és hamarosan megjelenő) könyvekről, érdemes megnézni hogy a számodra legmegfelelőbbet kiválaszthasd. Itt most csak az általam ismert, főleg kezdőknek szánt könyvekre szorítkozom.
Processing: A Programming Handbook for Visual Designers and Artists, Reas and Fry, MIT Press, 2007
Címéből adódóan ez egy kézikönyv. Rengeteg hasznos példát találsz benne, ha van egy kis programozási gyakorlatod akkor pusztán ezzel a könyvvel is elindulhatsz. Viszont az ára egy magyar átlag ember/diák számára nem barátságos.
Learning Processing: A Beginner's Guide to Programming Images, Animation, and Interaction, Daniel Shiffman, Morgan Kaufmann, 2008
Ez a KÖNYV minden kezdőnek, kiváló támogató oldallal és sok-sok feladattal. Viszont az ára húzós (nekem legalábbis az) és ha tényleg gyorsan akarsz valami használhatót, akkor ez talán kicsit hosszú. Ha nem követed teljes figyelemmel könnyen elveszhetsz.
Processing: Creative Coding and Computational Art (Foundation), Ira Greenberg, Friends of Ed., 2007
Nekem nagyon vegyes benyomásaim vannak ezzel kapcsolatban. Nyilván nem tartozom a célcsoportjába (művészlelkek). A stílusa nem a szokványos technikai, száraz, tömör leírás, hanem szép elbeszélés.
Visualizing Data, Ben Fry, O'Reilly, 2007
Nem kezdőknek való, de mindenképpen hasznos. Amolyan tutorialba öntött ötlettár hogy hogyan prezentáld adataidat.
Összegezve
A Getting Started with Processing azt teszi amit ígér, elindít a kódolás világába mindezt magas színvonalon és még nekünk is elérhető áron.
el tudjuk dönteni hogy azt érte-e el a kódunk amit akartunk. A Processing-et tekinthetjük speciális Javanak, elsajátítása után könnyen áttérhetünk a nagy testvér használatára is. Ne feledjük azt sem hogy nagyon szórakoztató bütykölni egy ilyen nyelvet!- O'Reilly/Make, 2010
- Angol nyelvű
- ISBN-10: 144937980X
- Szerzők: Casey Reas, Ben Fry
Mi is az a Processing?
Saját ön meghatározása szerint a Processing " is an open source programming language and environment for
people who want to create images, animations, and interactions" azaz egy nyílt forráskódú programozási nyelv és környezet azok számára akik képeket, animációkat és interakciókat akarnak készíteni.
Ezt a meghatározást nem árt kiegészíteni. A szokványos komparatív programnyelv tanulmányokban két táborra oszlanak a szakik a Processing kapcsán. Mivel a Processing sokkal inkább egy környezet (egy IDE és pár hasznos cucc) és egy Java könyvtár, hiszen majdnem 100%-ban standard Java szintaxist használ, Java byte code-ot produkál és a JVM-en fut. Ugyanakkor nem tiszta Java, mind a strukturált, mind az objektum orientált paradigmát támogatja. Ha ehhez még hozzá vesszül hogy akadnak egyéb JVM-en futó nyelvek (Groovy, Scala, Clojure) akkor csak nagyobb a homály. Maradjunk annyiban hogy a Processinget itt nyelvnek nevezzük és észben tartjuk szoros kapcsolatát a Javahoz.
Minek nekünk egy újabb nyelv?
Szerintem gyakran ennek nincs más oka mint hogy a készítő szeretett volna egy saját nyelvet, ami neki megfelel. A Processing alapvetően Casey Reas és Ben Fry fejéből pattant ki, akik híres MIT Media Lab-ben John Maeda doktoranduszai voltak. Maeda a kilencvenes években érdeklődött hogy miképp lehetne a digitális művészek, dizájnerek és nem-programozók számára megkönnyíteni a belépést a programozás világába, ennek eredménye lett a Design by Numbers nyelv lett, ami habár már nem egy aktív projekt, inspirálta a Processing alkotóit.
Reas és Fry koncepciója szerint a nem technikai háttérrel rendelkező (de kellően motivált) alkotó emberek nem egy játékot akarnak. Egy eszközre van szükségük, amivel elintézhetik amit akarnak. Többek között ezért nem áldozhatták fel a gyorsaságot (ne feledjük egy grafikus program bizony számításigényes) és választották a Java-t kiindulási alapul. Ugyanakkor törekedniük kellett a használhatóságra, amit szerintem az egyszerű programozási környezettel el is értek. Habár a Processing megengedi hogy a feladat nehézsége és tudásunk szintje szerint megválasszuk milyen paradigmát használunk (szimpla parancsokat adunk, procedurális modorban függvényeket definiálunk vagy objektum orientáltan alkotunk) a használó nagyon gyorsan el fog jutni az OO módhoz ha naponta pár kis programot megír. Így habár egy kontinuumot képzelhetünk el az első Processing sketch és az első Java programunk között, sokan megmaradnak a rugalmas környezetben.
Fontos kiemelni hogy pedagógiai szempontból is jó ötlet egy grafikus programozási nyelvvel kezdeni. Hasonló elveken (csak más korosztálynak) épült fel a Scratch is. Ha a kód manipulálását direkt vizuális visszajelzés követi egyszerűbben és gyorsabban halad a programozás elsajátítása is.
Nézzük a könyvet
A könyv vékony és nem is olyan drága, sok ábrával és példa programmal van megspékelve, vizuálisan kifejezetten hívogató. Nem is beszélve hogy a Processing két atyja mint szerző meggyőzőnek hangzik. Egy ilyen vékony kötettől persze ne várja senki hogy hacker lesz mire a végére ér, de ha valaki szépen végig csinálja a példa programokat és veszi a fáradságot hogy egy kicsit módosítgassa őket, akkor képes elsajátítani mind a Processing nyelv, mind pedig a programozás alapjait (mi egy változó, mi az hogy iteráció, kondicionális, mi a különbség egy osztály és egy objektum között stb). Ennél nem is ígérnek többet a szerzők az előszóban.
Grafikus nyelvként az alapokkal indul a könyv (pont, vonal, kör koordinátákkal való képernyőre rajzolása), majd szépen halad az alapvető kontroll struktúráktól az osztályokig. Minden fejezet végén egy nagyobb projekt várja az olvasót; egy robotot készíthetünk ami egyre szebb és több képességgel rendelkezik. Ez nem csak mókás, de meg is mutatja hogyan használhatjuk egy hosszabb kódban (vagy mini projektben) megszerzett tudásunkat.
Az utolsó fejezet inkább arról szól hogy merre tovább, alapvetően az Arduino és a processing honlapja ajánlható ha tényleg jobban el akarsz mélyedni ezen a területen, de nem árt persze elolvasni azt a néhány oldalt.
Pro és kontra
Ami nekem kifejezetten tetszett az egyrészt hogy tele van a könyv jó tanácsokkal, apró trükkökkel hogyan kell programozni (kommenteld ki a kód egy részét, használd a println() függvényt hogy lásd a koordinátákat stb) és egy külön függeléket szentelnek a további, általános praktikáknak. Mivel a a változók hatóköre sokszor okoz problémát a kezdők számára, ennek is külön függeléket szántak, továbbá a különböző beépített típusoknak is, érdemes ezt a részt elővenni ha valami nem világos. Ez már csak azért is fontos, mert a könyvben gyakran találkozunk olyan változó deklarációkkal amikor nincs érték rendelve a változóhoz explicite (sőt ez tovább van bonyolítva egy autoincrement operátorral is).
Összevetve más könyvekkel
Természetesen nem ez az egyetlen jó könyv amiből megtanulhatsz programozni és a Processinget használni. A Processing honlapján találsz egy komplett listát a megjelent (és hamarosan megjelenő) könyvekről, érdemes megnézni hogy a számodra legmegfelelőbbet kiválaszthasd. Itt most csak az általam ismert, főleg kezdőknek szánt könyvekre szorítkozom.
Processing: A Programming Handbook for Visual Designers and Artists, Reas and Fry, MIT Press, 2007
Címéből adódóan ez egy kézikönyv. Rengeteg hasznos példát találsz benne, ha van egy kis programozási gyakorlatod akkor pusztán ezzel a könyvvel is elindulhatsz. Viszont az ára egy magyar átlag ember/diák számára nem barátságos.
Learning Processing: A Beginner's Guide to Programming Images, Animation, and Interaction, Daniel Shiffman, Morgan Kaufmann, 2008
Ez a KÖNYV minden kezdőnek, kiváló támogató oldallal és sok-sok feladattal. Viszont az ára húzós (nekem legalábbis az) és ha tényleg gyorsan akarsz valami használhatót, akkor ez talán kicsit hosszú. Ha nem követed teljes figyelemmel könnyen elveszhetsz.
Processing: Creative Coding and Computational Art (Foundation), Ira Greenberg, Friends of Ed., 2007
Nekem nagyon vegyes benyomásaim vannak ezzel kapcsolatban. Nyilván nem tartozom a célcsoportjába (művészlelkek). A stílusa nem a szokványos technikai, száraz, tömör leírás, hanem szép elbeszélés.
Visualizing Data, Ben Fry, O'Reilly, 2007
Nem kezdőknek való, de mindenképpen hasznos. Amolyan tutorialba öntött ötlettár hogy hogyan prezentáld adataidat.
Összegezve
A Getting Started with Processing azt teszi amit ígér, elindít a kódolás világába mindezt magas színvonalon és még nekünk is elérhető áron.
Feliratkozás:
Bejegyzések (Atom)