pár hónapja találtam egy álláshirdetést (már nem emlékszem, hol, de ez volt az), amire jelentkeztem. végül fölvettek, így múlt pénteken fölmondtam az EPAM-nál. november 29-én már az Intlandnál kezdek Stuttgartban. az első pár hetet kint fogom tölteni, aztán pedig távmunkában dolgozom (azt tervezem, hogy bérelek egy irodát a belvárosban). a cégnél a codebeamer fejlesztésében fogok részt venni, ami szerintem nagyon érdekes és izgalmas lesz.
az EPAM-ot nem azért hagyom ott, mert probléma volt vele. eddigi munkahelyeim közül ez volt a legjobb. viszont az intland most minden szempontból sokkal jobb lehetőség.
a blogra nézve ez azt jelenti, hogy ezután ismét gyakrabban jönnek a bejegyzések (legalábbis azt tervezem). az utóbbbi tíz hónapban főleg PHPztam, abban próbáltam elmélyedni, így nem nagyon volt időm írogatni. most viszont visszatérek a régi ösvényre és folytatom, ahol abbahagytam. szóval hamarosan jelentkezem!
a project coin egyik eleme az ARM, azaz automatikus erőforrás kezelés. ez sokkal egyszerűbb dolog annál, mint amit a neve sugall. tömören arról van szó, hogy bizonyos objektumokra ezután nem kell kézzel meghívnunk a close() metódust. erre egy új nyelvi konstrukciót vezetnek be és az API is megújul kicsit.
vannak olyan erőforrások, amiket használat után mindenképp fel kell szabadítanunk, le kell zárnunk. ilyenek a különböző fájlleírók, socketek stb. ezt eddig körülményesen, egy finally blokkban tehettük meg. ezen segít az új szintaxis, ami így néz ki:
try (resource) {
// resource itt használható
} catch (Exception ex) {
}
resource az automatikusan lezárandó erőforrás. ilyenből több is lehet, pontosvesszővel elválasztva sorolhatjuk föl őket. a zárójelek között álló összes erőforrás típusának implementálnia kell az AutoCloseable interfészt. ennek egy close() metódusa van throws Exception kitétellel.
az erőforrások lehetnek korábban létrehozott objektumok, de deklarálhatjuk őket a try zárójelei között is. egy itt deklarált változó hatásköre a deklarációtól kezdődik, tehát egy későbbi erőforrásnál már felhasználhatjuk. például
try (DimmyDummy d = new DimmyDummy(); d.getDummy())
ha a getDummy() metódus egy AutoCloseable példányt ad vissza, akkor ezzel a kóddal minden rendben.
a működés nagyon egyszerű.: a blokk végén meghívódik a close() metódus. ha valamelyik erőforrás létrehozásakor kivétel dobódik, vagy a bezáráskor van probléma, akkor az egész blokk kivétellel fejeződik be. ezeket a catch ágakban el tudjuk kapni.
az egész fenti kód igazából így íródik át:
try {
try (resource) {
// resource itt használható
}
} catch (Exception ex) { }
a kivételek működését így a legegyszerűbb megérteni.
ha tesztelnétek ezt a funkciót, a szükséges binárisokat innen tölthetitek le, a részletes speckót (amit mindenképp érdemes elolvasni) itt találjátok.
ezt az apróságot johannes schneider blogjában olvastam nemrég. bár viszonylag egyszerű a megoldás, azért el lehet rajta gondolkodni. adott az alábbi osztály:
class Car {
private final List<Tire> tires = new ArrayList<Tire>();
public void setTires( List<Tire> tires ) {
this.tires.clear();
this.tires.addAll( tires );
}
public void addTire( Tire tires ) {
this.tires.add( tires );
}
public List<Tire> getTires() {
return Collections.unmodifiableList( tires );
}
}
ezután a kérdés: mit ír ki az alábbi kód?
Car car = new Car(); car.addTire( new Tire() ); car.addTire( new Tire() ); List<tire> carTires = car.getTires(); System.out.println( "before: " + carTires.size() ); car.setTires( carTires ); System.out.println( "after1: " + car.getTires().size() ); System.out.println( "after2: " + carTires.size() );
a megoldást és a magyarázatot megtaláljátok Java Surprise: Setters/Getters and Collections.
java/xml fejlesztőt keresünk a debreceni epam irodába. a kritériumok:
- Java and Java EE development experience
- Insight to the XML/XSLT
- Good English communicating and writing skills
ami pluszpontot ér:
- Ant/Maven experience
- Business Analyst experience/attitude
ha érdeklődsz, írj és küldj cv-t az akos.tajti giliszta gmail.com címre.
a 2010-es goldenblog versenyen második lett a blog. nagyon meglepődtem, nem gondoltam, hogy ilyen témával idáig lehet jutni :) köszönöm a zsűrinek és gratulálok a többieknek! a szöveges értékeléseknek külön örültem, hájjal kenegettek :)
a BA-nk, aki nagy c++ programozó, küldött nekem egy linket a “duff’s device” wikipedia szócikkre. “ne csak javáról szóljon” – mondta, és igaza is van. bemutatom tehát az első C témájú bejegyzést a blog történetében.
a duff-féle megoldás tulajdonképpen egy egyszerű loop-unrolling. különlegessé az teszi, ahogyan a kód a fejet megkerülve egyenesen a ciklus közepébe lép. biztos vagyok benne, hogy sokan elgondolkodnak majd az alábbiak láttán, hogy egyáltalán létezik-e fordító, ami ezt megeszi. én is elgondolkodtam, ezért kipróbáltam: hiba nélkül fordul. így néz ki:
send(to, from, count)
register short *to, *from;
register count;
{
register n=(count+7)/8;
switch(count%8){
case 0: do{ *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
}while(--n>0);
}
}
ha bárki kételkedne, hogy jól lát: ez tényleg a do-while tényleg a switch utasításba van ágyazva. ez teljesen helyes szintaktikailag, a hatásai pedig egészen különlegesek.
a működés nagyon egyszerű (ha az ember végre túllép azon a beágyazott cikluson). az első lépésben vesszük a számláló maradékát nyolccal. azután a megfelelő case ágra ugrunk, még ha az a ciklus közepén áll is. tehát mindig végrehajtódik a *to = *from++; kódrészlet maradékszor. ezután még annyiszor hajtjuk végre az összes case ágat, ahányszor a számláló osztható nyolccal. összeadva pontosan count ismétlés történt.
az optimalizált ciklus így nézett ki:
do {
*to = *from++;
} while (--count > 0);
az átírás célja nyilvánvaló: növelni a kód sebességét. ez sikerült, még ha a kód csúnyább is. mindenesetre nagyon ritkán látni ilyen leleményes megoldást.
amióta elkezdtem programozással foglalkozni, rengeteg algoritmussal találkoztam és volt pár, ami nagyon megtetszett. volt amelyik a neve miatt, másik az újdonsága miatt, egy újabb pedig azért, mert nem értettem. hosszú lenne felsorolni az összeset, így most csak a négy kedvencem mutatom be. ha valaki szereti az informatikát, akkor valószínűleg talákozott ezek nagy részével, de remélem, tudok újat is mondani.
soundex
a soundex algoritmust egy nagyon érdekes probléma megoldására találták ki. ez a népszámlálásokhoz köthető, pontosabban a polgárok neveihez. sokszor előfordul olyan, hogy azonos nevű embereket más írásmódban jegyeznek le (esetleg valóban másképp írják a nevüket). hogy egy közeli példát mondjak: a tág családomban könnyen találnék olyat, aki tajthy-ként írja a nevét. nyilvánvaló, hogy az ilyen hasonlóságok általában nem véletlenek, egyezőként kell kezelni őket. ez azonban egy alkalmazásban nagyon nehéz - amíg meg nem ismerjük a soundex algoritmust.
a módszer nagyon egyszerűen leírható: minden névhez egy négy karakteres (egy betű, három számjegy) kódot rendel. persze nem akárhogy. az azonos hangzású nevek ugyanazt a kódot kapják. a négykarakteres sztringek előállításának hivatalos lépéseit (angol nyelvre) a NARA őrzi pecsét alatt. persze a wikipedia szócikk is részletesen leírja, lehet vele kísérletezni.
kupacrendezés
nem tudom, mennyire ismert ez a rendezés, de az biztos, hogy a legtöbb ismerősöm még nem hallott róla. pedig szerintem ez a legszebb rendezési algoritmus (a dual-pivot quicksort mellett). ráadásul nagyon könnyen megérthető. a rendezés a kupac (angolul heap) adatszerkezetre és annak egy nagyon fontos tulajdonságára épít.
egy kupac egy olyan bináris fa, aminek a gyökerében áll a (valamilyen összehasonlítás szerinti ) legnagyobb elem (min-kupac esetén a legkisebb). innen már látható, hogyan tudjuk ezt rendezésre használni: vesszük a rendezendő tömb elemeit és felépítünk egy kupacot belőlük. a gyökérben álló elemet ezután a tömb végére helyezhetjük, mivel tudjuk, hogy nincs annál nagyobb elem. ezt addig folytatjuk a maradék tömbre, amíg el nem fogy. a kupacrendezés általában lassabb, mint a gyorsrendezés, viszont a legrosszabb esetre jobban teljesít. és nem mellesleg: sokkal szebb konstrukció.
jarvis menetelése
ez az az algoritmus, amit ahogy meglát az ember a tartalomjegyzékben, azonnal szerelembe esik. egyszerűen nem lehet nem odalapozni és implementálni. pedig egy viszonylag egyszerű algoritmusról van szó, de ez a név..
a jarvis menetelése egy adag pont konvex burkának kiszámítására szolgál. tehát szeretnénk az összes pontot egy olyan konvex sokszögbe csomagolni, aminek a csúcsai szinték a pontok közül kerülnek ki.
az algoritmus nagyon egyszerű. kezdő lépésként kiválasztjuk a legbaloldalibb pontot. ő biztosan ott lesz a csúcsok között. a következő pont megkereséséhez az összes többi ponttal összekötjük az elsőt és szögeket számolunk. az a pont lesz a nyertes, amelyik a legkisebb szöghöz tartozik. ezt addig folytatjuk, amíg a sokszög be nem zárul.
ez a leírás persze nem teljes, pár dolgot kihagytam. a pontos algoritmust megtaláljátok a fenti linken.
burrows-wheeler transzformáció
ezzel elérkeztem a kedvencemhez. emlékszem, amikor az egyetemen tanultunk erről, a csoporttársaimmal kipróbáltuk, mert nem hittünk benne. de működött. persze ma már értem, hogyan és a wikipedia is leírja, de ezt fölösleges magyarázni. szinte csoda.
a burrows-wheeler transzformáció leginkább egy tömörítést segítő algorimtus. léteznek ugyanis olyan tömörítési eljárások, amik az egymás után sokszor ismétlődő, azonos karaktereknek köszönhetik méretcsökkentő képességüket. ezek a különböző run-length encoderek és például az MTF transzformáció. azonban ezek mit sem érnek, ha kevés az ilyen ismétlődés. ezen tud segíteni a burrows-wheeler transzformáció. azaz: átalakítja a tömörítendő sorozatot úgy, hogy ilyen ismétlődések jelenjenek meg benne.
a legérdekesebb az egészben az átalakítás módja. az algorimtus megfogja a transzformálandó sztringet és előállatja az össze lehetséges balra forgatását. például ha az ALMA sztringet eggyel balra forgatjuk, akkor az LMAA sztringet kapjuk. ha az összes lehetőség megvan, ezeket rendezzük ábécé sorrendbe majd írjuk őket egymás alá. a transzformáció eredményét úgy kapjuk meg, ha a sztringek utolsó karaktereit sorban összeolvassuk. meglepő módon az így kapott sztring tele lesz ismétlődésekkel (persze ez a bemenettől is függ). ezt már egyszerűen és hatékonyan tömöríthetjük. az algoritmus leírását példákkal együtt itt olvashatjátok el.
ennyit a kedvenc algoritmusaimról. remélem pár (főleg a legutóbbi) felkeltette az érdeklődéseteket. nektek van kedvenc algoritmusotok?
iratkozz fel!
