Egy sima egy fordított

Az utóbbi időben kapcsolatba kerültem néhány fordítási projekttel.

Az egyik a Facebook magyarítása volt, ami azon az elven alapult, hogy a fordítást maguk a felhasználók végzik el a közösségi oldalba integrált felület (minialkalmazás) segítségével. A fordítás szavazás alapú volt, azaz a lefordított kifejezések közül mindenki megszavazhatta a neki tetszőt vagy nem tetszőt. Viszonylag jó fordítást sikerült csinálni. Teljesen tetszik az ötlet. Egy-két szót én is bedobtam a köztudatba, de azt hiszem egyik sem nyert. Viszont jó a tudat, hogy a szavazataimmal legalább hozzájárultam a projekt minőségének javításához. (Vagy rontásához. :))

A másik a Scarab (issue tracker szoftver) fordítása volt, de ahogy tudom ez kicsit lefulladt, vagy legalábbis erősen stagnál az állapota. Részemről azért, mert eléggé el vagyok havazva mostanában melóval és a szabadidőbe pedig nem fér bele. De ha valaki folytatni akarja, akkor ez alapján bekapcsolódhat. Egyébként több érdekessége is volt a dolognak, pl. rögtön elakadtunk ott, hogy az issue-t hogyan fordítsuk magyarra, hiszen a hibákat és a fejlesztési kérelmeket is issue-nak nevezik. Mi feladat-nak fordítottuk. Másik érdekesség -ami nem konkrétan fordítással kapcsolatos- a Scarab disztribúciójának módja, ugyanis nem egy sima war-t vagy ear-t kell letölteni, hanem egy komplett Tomcat-be ágyazott struktúrát kapunk. Hát, nem tudom mennyire ez a követendő példa.

Loggolás: E blogbejegyzés alapján a kommentelők mellett bennem is felmerült hogy mi a franc értelme van lokalizáltan loggolni. Ha szuahéli nyelvű logokat mellékelne nekem valaki egy hibajelentéshez annak bizonyára nagyon örülnék. Az persze igaz hogy nem muszáj használni a funkciót.

A javalistán is tombol egy thread "Tervezési minták" címmel a témában. Előjön az ősi kérdés, hogy ugyebár lefordítsunk-e magyarra valamit vagy ne. Singleton vs. Egyke, Abstract Factory vs. Absztrak Gyár vs. Elvont Gyár, Session Bean vs. Munkafolyamat Bean. Elég sok oldaláról kivesézik a kérdést. Néhány év gyakorlattal az én véleményem az, hogy lehetőleg minél kevesebb szakkifejezést fordítsunk (vagy inkább ferdítsünk) magyarra. Aki komolyan akar programozni az tanuljon meg legalább ennyire angolul.

Megkérdezték a véleményemet egy elég komoly fordítási projekt kapcsán is, hogy milyen technikai kifejezéseket hogyan látnék szívesen az adott szoftverben. Ott is kötöttem az ebet a karóhoz, hogy minél több angol kifejezés legyen arra, amire nincs magától értetődő magyar szavunk.

Blogot írni programozásról jó, mert szabadon keverhetem a kifejezéseket, megválaszthatom a stílust. Könyv írásánál is viszonylag szabad keze van a szerzőnek - gondolom én. Nem elhanyagolandó, hogy aki könyvet ír az viszonylag nagy valószínűséggel érti amit leír. Amikor viszont kiosztják a tonnányi fordítást egy nem kimondottan IT-s végzettségű társaságnak anélkül hogy élesben találkoznának a szoftverrel, na abból lesznek a szörnyűségek.

A Scarab fordításra visszakanyarodva én folyamatosan használtam a szoftvert és csak akkor kezdtem fordításba amikor egy címke szerkezetét és helyét pontosan megtaláltam. Néha 5-10 percet kellett tesztelnem, mire pontosan kitaláltam egy-egy címke funkcióját. Ugyebár vannak ilyen kifejezések, hogy: This {0} is {1} {3}. Na most találd ki hogy ez micsoda, melyik mezőbe mi fog kerülni. Mellesleg hasznos lenne a bundle fájlokat megkommentelni, hogy melyik bejegyzés milyen esetben hol jelenik meg, de ez akkora plusz meló fejlesztés közben, hogy úgysem csinálja meg soha senki. Utána meg már elég nehéz.

Külön öröm lehet, ha a fordításnál rendelkezésre áll egy vállalati policy a felhasználandó kifejezésekkel vagy egy ügyeletes Kazinczy Ferenc aki IT kérdésekben nem kimondottan járatos, ennek ellenére bekiabálja a pálya mellől az okosságait. Értem én hogy foggal-körömmel védeni kell a szép magyar nyelv értékeit, nade pont ezen a területen, ahol a bit-től kezdve minden az angolból jön?

Múltkor belenéztem egy szoftverfejlesztési eszköz vállalati policy-vel és nyelvésszel készült megmagyarított súgójába és komolyan mondom, nem értettem az ott leírtakat. Mintha kódolt Navaho nyelven lett volna leírva. Nem tudtam eldönteni hogy verjem a fejem az asztalba vagy sírva röhögjek. De végülis ezektől a dolgoktól vicces az élet, úgyhogy aki tud valami vicces fordítást az egyébként ne fogja vissza magát, nyugodtan írja a kommentek közé.

Visszatérve a rögvalósághoz, még egyetlen dolgon töröm a fejem a fordításokkal -azon belül a bundle fájlokkal- kapcsolatban. Ha van egy szó vagy kifejezés, ami több (~sok) oldalon ugyanúgy szerepel érdemes-e csinálni neki több bejegyzést. Több bejegyzés esetén a bejegyzéshez tartozó kulcs hierarchikus szerkezetű és lehet tudni hogy az alkalmazás melyik részében, melyik oldalon esetleg milyen funkcióval fog megjelenni a címke. Csakhát egyvalamit tízszer le kell írni. Gondolok itt az általános címkékre, mint "OK", "Mégsem", de gondolok az adott rendszer entitásaira is, mint "Alkalmazott", "Gépjármű", "Kutya", "Termék". Azt gondolnám hogy nem érdemes külön bejegyzést csinálni, de mi minden projektben mégis így csináljuk, mert megvan a minimális esélye, hogy egyik oldalon mégis kicsit máshogy kell majd kiírni az adott dolgot. Ez ha jól emlékszem tíz év alatt egyszer sem fordult elő.

Cloud Computing

Megvan az új Buzzwörd amit a különböző típusú és beosztású managgerek és sáleszesek feljegyezhetnek a noteszükbe a prezentációkon puffogtatható kifejezések közé. Igaz hogy nem történt semmi a világban, marad a kliens-szerver architektúra jó eséllyel cluster-ezett szerverekkel és lazán egymáshoz kapcsolódó szolgáltatásokkal, ennek ellenére némelyek ezt világratörő innovációnak élik meg az MS-től kezdve a G-ig.

A Wikipedia szerint - nagyon nagy vonalakban- onnan jön a kifejezés, hogy a meetingeken az internetet felhőnek szokták ábrázolni. Update: sg.hu-s cikk, idézet belőle: "A számítási felhők hívei szerint a jövő útja központi szervereken futtatni a szoftvereket, és az elérésükért pénzt szedni a felhasználóktól." Jó nem?

A Web 2.0 kifejezés elterjedésénél még éreztem valami paradigmaváltást, hogy a request-reply formok helyére bejönnek a rich client alkalmazások. Mások teljesen a szociális oldaláról közelítették meg a kérdést, tehát hogy a közösség építi a fellelhető tudásbázist, de végülis a lényeg, hogy ha nem is hirtelen, de végbement valami ami az internet felhasználásának az elveit változtatta meg. Mások szerint persze ez is marhaság.

Ezzel az új kifejezéssel kapcsolatban éppen az zavar, hogy nincs szó semmilyen paradigmaváltásról, csak kitaláltak egy szinonímát egy régóta meglévő általános dologra.

Ráadásul a Cloud Computing -ról én az elosztott számítási rendszerekre asszociáltam eddig, mint pl. amelyek a személyi számítógépek üresjáratát kihasználva földönkívüli rádióadásokat keresnek, DNS-t kutatnak, kódokat törnek vagy ütköző részecskéket elemeznek. Ide sorolnám még a p2p fájlmegosztókat is tágabb értelemben. Ezeknél az architektúráknál a kliens aktívan részt vesz a rendszer működésében.

Mint a Wikipedia szócikkből kiderül, ez valójában Grid Computing. A grid-ről viszont inkább egy statikusan összeállított viszonylag homogén és szabályos szuperszámítógépre asszociáltam eddig, a felhő pedig egy olyan rendszer volt nálam, amibe szabadon becsatlakozhatnak különféle munkaállomások, tehát topológiai kérdés.

A Cloud Computing architektúrájában a kliens valójában nem része a felhőnek ami a szolgáltatásokat biztosítja, ad abszurdum nem osztja ki a rendszer a gépemre a feladatot, hogy XYZ emailjait tárolja el.

Boncolgathatnánk még a kérdést, hogy miért Computing, de végülis az emailek vagy dokumentumok tárolása és szinkronizálása is valamilyen szinten "computing", akárcsak a legbonyolultabb matematikai problémák megoldása.

Tehát:

• internet, kliens-szerver architektúra (régi, elavult)
• cloud computing (modern, trendi)

De a kettő ugyanaz.

Update 2009.01.21: Harangoztak a merevlemeznek, cikk az It-Café-n. A Google-nek, a Microsoft-nak és még másoknak is van tervezett megoldásuk személyes fájlok központi helyen való tárolására. Megemlítik a cikkben a problémákat is. Két dolog nekem is eszembe jutott: mit szólnának a kedves szolgáltatók, ha valaki kapásból csinálna egy lokálisan futtatható titkosító eszközt és így a központi tárhelyre csak értelmetlen bithalmazok kerülnének fel, amit nem lehet vizsgálgatni, indexelgetni, mazsolázgatni? Másrészről környezetvédelmi aggályaim is vannak, mert a saját gépemet lekapcsolom amikor nem használom, egy központi szerver viszont folyamatosan pörög, nem is beszélve a hálózati struktúráról és annak a terheléséről amíg az adatok átérnek a felhőből az aktuális eszközömre. Akkor inkább legyen olyan szolgáltatás amivel be tudom kapcsolni és vezérelni, adatokat lekérni az otthon hagyott eszközeimről. Ja és köszi a szamitasifelho.lap.hu-nak hogy belinkeltek!

Mercurialozom

Ideje volt már feltennem a sajátgépemre egy elosztott verziókezelő rendszert. Miért is? Saját használatra Windows-on nem akartam CVS-t vagy SVN-t izzítani, viszont a fejlesztőkörnyezet history szolgáltatása elég Mórickás, ráadásul lehet hogy más is be fog csatlakozni a fejlesztésbe. E írás alapján a Mercurial mellett döntöttem. Dióhéjban: git-re nincs Windows támogatás, Bazaar nem rossz, de a Mercurial mégiscsak ismertebb.

Írás még róluk a Javaworld-ön. Összegyűjtve dolgok még a JHacks-en.

1 perc múlva már ott figyelt az installált Mercurial 1.0.1 verzió a Windows-os gépemen.

A 3.3-as Eclipse-hez pedig lehúztam egy plugint.
E levél szerint Zingo Andersen fejlesztgeti pár éve szabadidejében.
Először nem működött valami jól, mert nem tudtam visszanézni a régi verziókat, de végül uninstall után a béta update site-ről szedtem le a legfrissebbet, ami már jól működik. Az ikonok dekorálását explicit be kell kapcsolni a preferences label decorations-nél. Itt van a plugin fejlesztői oldala, itt van a béta update site URL-je is.

http://home.zingo.org/trac/mercurialeclipse

Megvan az SVN-ből vagy CVS-ből megszokott kellemes funkcionalitás. History, diff, annotation. Ezeket használom én, amikor verziókontrollozok. Persze a commit, update és társain kívül.

De van másik plugin is: Merclipse.
Ezt is kipróbáltam, de 5 perc után leszedtem, mert elsőre nem állt kézre a funkcionalitás. (Valami vagy nem működött, vagy nem találtam meg és nem volt jól ledokumentálva hogy hol keressem.)

Team - Share Project-tel lehet varázsolni hamar a meglévő projektből Mercurial repositoryt. Aztán még add-olgatni kell a fájlokat és kommit-olni. Anélkül hogy ismerném a belső működését kijelenthetem, hogy a verziózott fájlok a projektben a .hg könyvtárban kerülnek eltárolásra. Nem szemeteli össze az összes könyvtárat mint az SVN vagy CVS, csak a gyökeret.

Hogy hogyan kell több gépet együttműködésre bírni azzal egyelőre nem foglalkoztam.

A következőn gondolkodtam el: mivel nincs központi repó és minden fejlesztő gépén fenn van a teljes anyag, elvileg nehezebben vesznek el az adatok. Viszont ha tönkremegy valaki vinyója és senki más nem szedte le az aktuális változtatásait az gáz. (Tapasztalt DVCS júzerek cáfoljanak meg ha nincs igazam.) Szóval elosztott rendszer ide vagy oda, mégiscsak jó ha rávésődnek az adatok egy-két masszív központi vasra is. Nyilván meg lehet oldani valahogy.

Mivel egyelőre saját célra használom egyedül, kiélvezhetem a commit comment-ek és a branch-ek előnyeit, de gondoskodnom kell róla, hogy néha kiírjam a repót CD-re vagy valami hasonlóra.

A Selenic-es Wiki-ben volt egy link egy nagyon jó ingyenes elektronikus könyvre, de már nem él: http://hgbook.red-bean.com/hgbook.pdf

(Zárójelben megemlítem hogy most háromféle verziókezelő plugin működik aktívan az Eclipse-emben gond nélkül. Ebből a Mercurial és a CVS egy workspace-en belül van, de úgy emlékszem az egyéb kombinációk is jól működtek eddig.)

Különben pedig valóban. Amíg intraneten SVN-ezik az ember addig mindegy, mert jönnek az adatok mint az olajozott villám, de ahogy pl. mostanában rákapcsolódtam egy távoli Google-s SVN trunk-re https-sel kicsit kényelmetlen lett hirtelen a sebesség, vagyis annak a hiánya. Intraneten néha passzióból history-t nézek vagy compare to-zok. Távoli trunk-on már jobban meg kell gondolni van-e fél percem és sávszélességem ilyen műveletekre. Szóval ja: hasznos lehet az elosztott verziókezelő néhanapján.

JavaCard Classic

Volt egy projekt egy-két hónapja, amiben JavaCard technológiát használtunk. Most már teljes a skála, JavaCard-tól MIDP-n és Standard Edition-on keresztül a J2EE-ig mindent programoztam Java-ban. Igaz, a JavaCard-nak éppenhogy csak karcoltam a felszínét, de arra ez is elég hogy rálátás legyen. Most csak konyhanyelven írom le hogy megy ez a dolog:

Gyakorlatilag java-t kell programozni, de az osztálykönyvtár irdatlanul le van csupaszítva és csak 2 bytes-os adatszerkezetek vannak, tehát tele van az egész kód short kasztolásokkal és tömbműveletekkel. Úgynevezett javacard appleteket kell programozni, amiknek saját primitív tranzakciókezelésük és belső security managementjük van, lényegében perzisztens szerkezetűek és byte alapú módon kell kommunikálni velük. A kártyában pár kilobájt EEPROM áll rendelkezésünkre a programhoz és az eltárolt adatokhoz. Egy kártyára több appletet is installálhatunk. Sok firkálás után a kártya szépen tönkremegy.

A kártya valójában nem igazi bájtkódot futtat, hanem speckó eszközzel kell lefordítani a java forrást egy jobban megemésztett formátumra. Például a standard java-val ellentétben a linkelési információk nem kerülnek be a lefordított bináris állományba, hanem azokat egy másik állományban tárolják kb. név, index párokként. Az eszköz és a doksik letölthetőek a netről, van valami plugin Eclipse-hez (JCOP) ami szimulálni tudja a kártyát és kommunikálni tud magasabb szinten a géphez csatlakoztatott kártyaolvasókkal.

Az appletnek van egy belépési metódusa, ami egy az egyben megkapja azokat a bájtokat, amiket a kártya vett a külvilágtól akár a felületre integrált csatlakozási pontok, akár egyéb átviteli módszerrel. Pl. vannak RFID-vel vagy NFC-vel kommunikáló kártyák. Az RFID egyébként hasonlóan működik mint egy trafó. Váltakozó áram indukálódik a kártyában, ami egyben magát az adatot is jelenti, emellett a kártya áramellátását is megoldja arra az időre amíg az adatok feldolgozódnak. vicces nem?

Visszatérve a bájt tömbre: van egy viszonylag kötött formátumú fejléce, amit a kártya mini oprendszere kiértékel. Ez az első körben max kb 256 byte hosszú bájtsorozat használható az authentikációra, új applet telepítésére, törlésére, kiválasztására, befixálására. Megfelelő számú partizán kísérlet után a kártyát jól le lehet tiltani örökre. Ugyanezt a bájtsorozatot használhatjuk az appletben a saját protokoll kialakításához. Hosszabb bájtsorozatokra van valami összeillesztős mechanizmus.

A konvencionális java SE programokkal ellentétben a javacard applet mezőváltozói perzisztensek, azaz ha valamit beállítok az úgy is marad magától. Tehát mezőváltozóban lehet tárolni ilyeneket, hogy hányszor használták a kártyát. Ha jól emlékszem van valami commit-szerű művelet is, amivel gondoskodni lehet (kell?) róla, hogy a beírt értékek valóban perzisztálódjanak, és ezt ráadásul egyszerre tegyék. A változtatásokat a javacard egy kb 256 byte-os RAM pufferben gyűjti és a commit-nál beírja az EEPROM-ba. Ha túl sok változtatást akarunk csinálni, a puffer túlcsordul és hibát kapunk.

A kimenet szintén egy bájtsorozat. Össze kell rakni és elküldeni. PC oldalon vannak driverek, amikkel meg lehet hajtani mindenféle csatlakoztatott kártyaolvasókat, de most hirtelen nem is tudom milyen interfész van hozzájuk.

Ahogy a Sun Java Cafés postban írtam, a 3-as JavaCard verzióban bevezetnek egy új programozási módot, amiben magasabb szinten, szervletekkel (ezek sem igazi szervletek) lehet programozni a kártyákat. Ezt nevezik Connected Edition-nek.

Amiről én írtam az még a régebbi spec, amit meghagytak és Classic Edition-nek hívják.

Eredményhirdetés

Köszi hogy 31-en nyilvánítottatok véleményt! A végeredményt idemásolom, hogy akkor is látható legyen, amikor az oldal széléről majd eltűnik és a múlt homályába vész:

• 7 ember (22%) 100%-ban szXrt lapátol.
• 10 ember (32%) 80%-ban szXrt lapátol, de 20%-ban király dolgokkal foglalkozik.
• 9 embernél (29%) fele-fele ez az arány.
• 1 embernél (3%) inkább a király dolgok felé dől a mérleg, 80%-ban ezzel foglalkoznak.
• 3-an (9%) folyamatosan király dolgokat csinálnak profi csapatban.
• 1 szavazó pedig nem szoftverfejlesztő.

Mivel ez egy egyszerű közvéleménykutatás volt, nem derülnek ki bizonyos dolgok, például:

-Milyen szakterületekre koncentrálódik a lapátolás nagy része? Azt gyanítom, hogy főként az ügyviteli és banki szoftverekre. Technológiai és akadémiai/kutatás témakörben készült szoftvereket gondolom jobban összeraknak. Például több idő van a tesztelésre. Emellett úgy gondolom az open source szoftverekben kevesebb a szégyellendő, rejtegetnivaló megoldás.

-Milyen programnyelvre koncentrálódik a gányolás nagy része? Igaz hogy C-ben, C++-ban életveszélyesebb dolgokat lehet összehozni mint Java-ban vagy PHP-ben, de talán pont ezért a C, C++ programozóknál precízebb munkára van szükség. Modernebb nyelveknél/platformoknál, vagy legalábbis a Bábel torony felsőbb emeletein nagyvonalúbban dobálóznak rétegekkel, konverziókkal, magasszintű komponensekkel. Felhígul a társaság, divat van, nincs meg az elhivatottság. Nem utolsósorban műszakilag műveletlenebb megrendelőkkel konfrontálódnak ezen a szinten a fejlesztők és jobban beleszól a politika a tervezésbe ami kimondja mikor mit kell használni -függetlenül attól hogy az eszköz alkalmas-e az adott feladatra. Itt már visszakanyarodunk lassan a szakterületekre.

-A válaszok nyilván szubjektívek és önkritikán alapulnak. Az is lehet hogy valaki bepipálta hogy király dolgokat csinál profi csapatban, közben pedig a TheDailyWTF-nek kimeríthetetlen témaforrást tudna biztosítani. A fordítottját nehezebben tudom elképzelni, hogy egy elégedetlen munkásember valójában egy nagyon irigylésre méltó team-ben dolgozik. Ki mennyire becsüli meg a melóját? Erről is szólt ez a szavazás.

-Ha valaki szXrt lapátol, miért nem koccol le? Ez csak költői kérdés. Pár dolog közrejátszhat a maradásban. Pl. lojalitás (muhaha), pénz, van aki hisz benne hogy jobbra fordul a helyzet, a következő projekt jobb lesz és ne titkoljuk: van aki belekényelmesedik a helyzetébe.

-Végül ahol király csapatban profi dolgokat csinálnak az emberek az vajon melyik cég lehet és keresnek-e mostanában náluk munkaerőt? És vajon lehet-e itt a blogon privát üzenetet küldeni nekem ezügyben? :)