Nagyon kellemes ünnepeket kívánok mindenkinek, és részvétemet fejezem ki azok számára, akik ezt nem megkésve olvassák 
Kis technikai váltás volt: új szerverre költözött az oldal. Ha minden jól megy, ezt senki sem vette észre, azaz sikerült nulla downtime-mal megoldani. Az egyetlen reális kockázat, hogy valaki a régi szerverre ír kommentet az átmeneti időszakban, de ezt meg éppen ezért próbáltam minimalizálni.
A költözés meglepően simán ment. Adatbázis backup régi szerveren, restore új szerveren, fájlok átmásolása, és végül az adatbázisparaméterek átállítása a konfigurációs fájlokban. Ahogy az a nagykönyvben is meg van írva.
Nem emlékszem rá, hogy lett volna bármikor ennyire sima migrációm szerverek között. Ráadásul egy Drupal költöztetéshez képest kevés adatot kellett vinni: az adatbázis két wordpress telepítéshez volt 6 MB, míg Drupal adatbázisnál egy darab elérte ezt a méretet – feltéve, hogy a cache és az indexelés a kereséshez ki volt kapcsolva. Egyébként még sokkal nagyobb. A fájlméretnél körülbelül hasonlóan teljesítenek.
Mindenesetre köszönetet nyilvánítanék mindenkinek, akinek segítsége nélkül ez a költözés sokkal gyorsabban és egyszerűbben lezajlott volna.
PS.: ha látod ezt a hírt, akkor már az új szerveren vagy. Ha még ezt is el tudod olvasni, nincs szükséged szemüvegre.
A múltkori, nagy sikerű írásom hatására Tompika küldött nekem egy hasonlóan izgalmas problémát.
1 2 3 4 | while (true) { Process p = Runtime.getRuntime().exec("macska"); p.waitFor(); } |
A kód eredeti, Tompika kedvenc állatait, a macskákat felemlegetve. A kód elméletben a következőt kellene, hogy csinálja: az első sor a p referenciával elérhető módon indít egy processzt; míg a második sor vár, amíg a processz fut.
Ha megnézzük a kapcsolódó JavaDoc kommenteket, ez így működőképes is lehet. Ezzel szemben futásidőben problémák léptek fel, amiket feltehetőleg a következő kódrészletre való kicserélés javított:
1 2 3 4 5 6 7 8 9 | while (true) { Process p = Runtime.getRuntime().exec("macska"); p.waitFor(); p.getErrorStream().close(); p.getOutputStream().close(); p.getInputStream().close(); p.destroy(); } |
A kódrészlet utolsó sora vicces. Idézném a Javadoc kommentet:
public abstract void destroy()Kills the subprocess. The subprocess represented by this
Processobject is forcibly terminated.
Amit én úgy értelmeznék, hogy a függvényt meghívva explicite lezárom a Processt. Viszont állítólag nem így történik. Valaki tudja a magyarázatot? Kíváncsi lennék rá.
PS.: ha valaki hozzájut hasonló gyöngyszemekhez, és eljuttatja hozzám, szívesen közzéteszem.
Rég volt vicces kis videó az oldalon. Ennek megfelelően itt az ideje (szüneteltetve a kocka témákat), hogy egyet bemutassak. Ezért kapóra jött, hogy találkoztam a Pigeon Impossible című “kémtörténettel”. Pixar, rettegj.
Kicsit megkésve (november 6-án már olvastam a dologról, csak azóta nem igazán volt időm/energiám erre is reagálni) szeretnék megemlékezni az OOMouse nevű csodáról. Ez, mint a neve is mutatja, egy egér, és az OpenOffice csomaghoz van köze.
Először is szeretném leszögezni, hogy nem az OpenOffice fejlesztőinek munkája az egér, hanem az egeret készítő cég készített nyílt forrású, OpenOffice-t támogató drivert a cucchoz. Ezt azért éreztem fontosnak, mert ugyan az OpenOffice nem az ergonomikus szoftvertervezés csúcsa, de ez messze alulmúlja azt a szintet.
A leírás első körben bizalomgerjesztő: sok gomb (18), külön joystick az egéren, különböző módok, és mindez szoftveresen testreszabható.
Viszont ezután jött a fotó az egérről: a gombok az egér tetején helyezkednek el, rács mentén elhelyezve. Mi is ezzel a gondom?
Egy egyszerű, fehér egér 18 gombbal, görgővel és joystickkel
Egyrészt a gombok mérete feltehetőleg viszonylag kicsi: a görgő két oldalán 3-3 oszlopnyi gomb van (és gyk. 3-3 sornyi is). Ha ennyi a gomb, akkor hogyan oldják meg, hogy nehéz legyen mellényúlni?
A másik fő problémám az, ami miatt a távirányítón is megszüntették a rács szervezést: ha sok a gomb, akkor jobb, ha a gyakran használt gombok egyedi formájúak, és nagyok, mert akkor anélkül tud a felhasználó választani, hogy odapillanata, merre van (igen, a billentyűzetek “f” és “j” gombjain levő jelzés – tipikusan kidomborodás vagy bemélyedés is erre való – ezek segítségével az ember tudja, hogy hol van az ujja).
Ha megnézzük, a joystick helye is érdekes: a hüvelykujjnál, egy gomb(!) mellett. Jó kérdés, hogy ez a kilógó elem mennyire piszkálja az ujjamat, amivel az egeret kell irányítanom, illetve mennyire könnyen tudom véletlenül megnyomni. A mellette levő gomb meg érzésre teljesen használhatatlan – nem férek hozzá.
Mielőtt valaki megvádolna, hogy Apple-fanként csak egygombos egérrel boldogulok, kijelentem, hogy volt dolgom többgombos egérrel – olyan 5-6 gombig. Alapvetően nem volt gondom vele, eltekintve attól, hogy a 4-5-6. gombokat nagyon ritkán sikerült kihasználni. A tapasztalatom az, hogy a bal gomb, jobb gomb, görgő (aminek lenyomása lehet a harmadik gomb) triónál többet nagyon kevés alkalmazás támogat, és viszonylag kellemetlen is használni. Az egyetlen, aminek látnám értelmét, az 1D mozgást leíró görgő helyett valami 2D-s eszközt betenni (mint az Apple Mighty Mouse eszközében a golyó – most már Magic Mouse).
És ami a legszebb, az ára: $74.99. Vezetékkel. Ezzel szemben az Apple új, vezeték nélküli, érintőfelületű egere $69. Amit szintén sokallok azért az egérért… De ez már az én egyéni, szociális problémám.
Amikor a múltkor felhasználói felületekről írtam, akkor is hasonló mennyiségű kritikát írtam – de szemben azzal ez a kritika határozottan negatív.
Összességében: az egér elképesztően bonyolult. Sok gomb, sok mód, sokféle operációs lehetőség. A szoftverét nem láttam, az lehet, hogy a legkirályabb cucc a szeletelt kenyér óta, de a hardverről egy képet látva nagyon nem bizakodom.
Körkérdés: kedves olvasók, ti látjátok értelmét ennek a 18 gombos egérnek?
