palacsint weblapja

A fenti három székkel volt alkalmam találkozni az elmúlt néhány évben. Az egyértelmű nyertes közülük (mind funkciók száma, mind kényelem szempontjából) a Kinnarps 5000-es sorozatból az 5284M, de lássuk sorban a versenyzőket.

IKEA Markus: Őt szerettem a legkevésbé. Előny a fejtámla és a puha karfa. Hátránya, hogy a karfa fix, az ülés mélysége nem állítható, a csillagról lecsúszik az ember lába, túl meredeken emelkedik. A fix karfa miatt nem lehet túl közel ülni az asztalhoz, vagy a magasságával kell játszani. Kollégák közül páran inkább leszedték a karfát.

IKEA Volmar: A csillagról nem csúszik le a láb, viszonylag alacsony az emelkedési szöge. Az ülés mélysége állítható, de nem túl nagy a játéktér. A karfák egymástól való távolsága nem állítható kézzel, imbuszkulcs kell hozzá. A karfa anyaga kemény műanyag és elég vékony is (legalábbis a Kinnarpshoz viszonyítva). A karfa magassága kézzel állítható, és előre-hátra is tolható, így nem a karfa szabja meg, hogy milyen közel ülj az asztalhoz.

Kinnarps 5284M: Kényelmes, zselés karfa (puha, nem kemény műanyag), amelyek egymástól való távolsága kézzel állítható (imbuszkulcs nélkül). Szélességük jóval nagyobb, mint a Volmaré, és vízszintesen is állítható a szöge, ami külön plusz. A csillag teljesen lapos, van rajta csúszásgátló is. Látszik, hogy direkt arra találták ki, hogy azon pihentesse az ember a lábát.

Epub fájlok helyett PDF-ekkel is egész jól használható a Sony PRS-650, csak az oldalméretet, margót és betűméretet kell jól beállítani.

Alapadatok a Sony PRS-650 6 colos kijelzőjéhez:

• Oldalméret: kb. 118 mm x 90 mm
• Margó: 1 mm, igény szerint
• Betűméret: 11-13, igény szerint

Pár megjegyzés:

• Doc, RTF fájlok probléma nélkül átalakíthatóak LibreOffice-szal, rögtön látszik a végeredmény, nem kell az olvasón ellenőrizni. Ha végeztünk, akkor a Fájl menüben lehet PDF-be exportálni a dokumentumot.
• A képek problémásak így is, de kezelhetőbbek, mint epub esetén. (Ezt is lehet LibreOffice-ban ellenőrizni.)
• Ha csak egy eszközre (képernyőméretre) készítjük el, akkor nagyon gyors és kényelmes módszer.
• A forrásfájlt megtartva (LibreOffice odt) könnyedén módosítható a lapméret (képernyőméret), betűméret.
• Forráskódok, nem folyószövegek formázása sokkal egyszerűbb WYSIWYG szövegszerkesztővel.
• Weboldalak is könnyedén átmásolhatóak egy új LibreOffice dokumentumba a formázásokkal együtt.
• A tartalomjegyzék automatikusan elkészül a címsorokból.
• Nem kell külön belepakolni a fontokat az elkészült fájlba, PDF export megteszi automatikusan.

Akad néhány hátrány is:

• Kevésbé hordozható, más eszközre átvíve a könyvet biztos, hogy nem megfelelően fog megjelenni, ha különböző a képernyőméret.
• Nagyítást (betűméret változtatását) jobban kezelik az olvasók az epub fájlokban, itt viszont muszáj megadni a számítógépes formázáskor a betű- és lapméretet.

Igaz, hogy már több, mint egy éve megjelent a 7-es Java, de még mindig nem késő megismerkedni az újdonságaival. Egész konkrétan az új íves és hajlított építőelemekre gondolok.

Céges gépen:

• Thunderbird Portable feltelepítve titkosított lemezre (TrueCrypt)

Thunderbird-ben, céges gépen:

• Szerkesztés / Postafiók beállításai / Kiszolgáló beállításai /
  • Üzenetek megtartása a kiszolgálón: bepipálva
  • Legfeljebb X napig: nincs bepipálva
  • Letörlésükig: nincs bepipálva
• Szerkesztés / Postafiók beállításai / Kiszolgáló beállításai / Másolatok és mappák /
  • Rejtett másolatot kap (Bcc): Saját cím beírva

Otthoni gépen, szintén Thunderbird-ben:

• Szerkesztés / Postafiók beállításai / Kiszolgáló beállításai
  • Üzenetek megtartása a kiszolgálón: bepipálva
  • Legfeljebb 5 napig: bepipálva
  • Letörlésükig: nincs bepipálva

Így a leveleket csak az otthoni Thunderbird törli a szerverről, valamint az öt nap miatt a hosszú hétvégéken érkező levelek is meglesznek a céges gépen arra az esetre, ha esetleg kellene valami régebbi dolog munkaidőben.

A céges gépről küldött levelek pedig az otthoni postafiókba is megérkeznek, csak át kell őket pakolni az Elküldött elemek mappába. Túl sokat nem írok, úgyhogy ezt általában kézzel csinálom, bár biztos lehet rá automatikus szabályt is létrehozni.

Néhány triviális és kevésbé triviális dolog, amibe bele szoktak kötni a bírálók, vagy csak úgy simán hasznos – nem csak diplomaterv írásakor. Nem feltétlenül ebben a sorrendben.

• A bevezető és az összegzés jó megírása kritikus. Legtöbben csak ezt fogják elolvasni. Nyugodtan lehet belőle két-három változatot is írni, aztán összegyúrni őket.
• Legyen róla legalább napi mentésed. Lehetőleg másik szerveren, adathordozón. Ne legyen rá szükséged, de nem kerül sokba, viszont ha kellene, akkor nagyon tud fájni a hiánya.
• Ne hagyj TODO, XXX és FIXME kommenteket a kódban. Egy nagyházinál valószínűbb, hogy megnézik, mint egy diplomatervnél, de jobb nem égetni magad. Persze ha valamiről nagyon látszik, hogy gány megoldás, akkor még pluszt is jelenthet, ha látja az értékelő, te is tudsz róla, de nem volt már időd javítani.
• A release, DVD melléklet stb. mindenképp automatikusan készüljön, a csak kézzel megtehető lépésekről (képzavar) pedig legyen ellenőrzőlistád, hogy ne az utolsó nagy hajrában hagyj ki valami fontosat véletlenül.
• Az irodalomjegyzék ne csak webcímeket tartalmazzon. Nem szokták túl megbízhatónak ítélni a webet a bírálók. Nyilvánvalóan van különbség a hivatalos dokumentáció és Pistike blogja között, de akkor sem mutat jól, ha csak webről dolgoztál. Néhány könyvet mindenhova lehet találni, és nem is kell feltétlenül borítótól borítóig végigolvasni mindet, hogy beírhasd a hivatkozások közé. Bőven elég csak a releváns fejezeteket, oldalakat hivatkozni.
• A túl rövid fejezetek kerülendők. Ha nem tudsz valamiről két bekezdést írni, akkor annak talán máshol lenne a helye.
• Minden fejezet- és alfejezetcímhez tartozzon legalább egy mondat. Nem mutat túl jól rögtön egymás után egy fejezet-, és rögtön a következő sorban egy alfejezetcím úgy, hogy nincs köztük egy sor szöveg sem. Néha annyi is elég, hogy „a következőkben bemutatjuk, összefoglaljuk ezt és ezt”, csak legyen valami.
• A beadott PDF-ek megnyitásakor a pdf olvasó címsorában ne a „Diplomaterv” szó szerepeljen csak. Cseréld ki valami értelmesebbre, mondjuk a nevedre és a mű címére. Ugyanígy a fájlnévnek megadott „diplomaterv.pdf” sem túl beszédes.
• Használd ki a szövegszerkesztőd szolgáltatásait: irodalomjegyzék, ábrák hivatkozásai automatikusan számozódjanak, mert utólag nagyon fárasztó és unalmas ilyeneket javítani.
• Nyugodtan használj elválasztást, tördelésben sokat segíthet. Persze ha kell az oldalszám, akkor ez inkább ront a helyzeten, viszont profi munkához hozzátartozik a szép oldalkép is. Ne legyenek félig üres oldalak, nagyon rosszul mutatnak. Lehetőleg ne kezdd a fejezeteket automatikusan új oldalon, ez is sok félig üres oldalhoz vezet.
• Beadás előtt hagyj magadnak időt a doksa pihentetésére, hogy valamennyire idegen szemmel tudj ránézni a munkádra. Pár napig ne foglalkozz vele, aztán nézd át újra. Biztosan fogsz pár olyan elgépelést találni amin azelőtt simán átsiklottál. Ugyanígy add oda átnézésre barátoknak, rokonoknak a művet. Saját műben nehezebben veszi észre az ember az elgépeléseket.

Néhány önéletrajzos gondolat, leginkább szoftverfejlesztői pozíciókra kihegyezve, de nagy része más állásokra is igaz lehet:

• Nyugodtan lehet több önéletrajzod. Célszerű egy hosszabb master példányt tartani, és kihúzni belőle az adott álláshoz nem annyira lényeges dolgokat, és ezt a szűrt változatot elküldeni. Másolatot ments belőle magadnak is, ha behívnak, akkor tudd, hogy mit osztottál meg velük, ne az interjún kelljen egyeztetni, hogy mi is van a saját CV-dben, és mi nincs.
• Ha mondjuk Java fejlesztőnek jelentkezel, és még sosem dolgoztál Java-s projekten, akkor is célszerű, ha szerepel valahol a java substring a dokumentumban. Lehet az bármilyen hobbi projekt, önálló labor, egyetemi tantárgy stb. kapcsán, de legalább látszódjon belőle, hogy kicsit is érdekel a téma.
• Szoftverfejlesztői állásnál fontosabb, hogy mi a hobbiprojekted, mint az, hogy melyik multinál mennyi árut töltöttél fel a fősuli előtti nyarakon.
• Monotonitástűrés nem feltétlenül előny. Nem lenne jobb inkább automatizálni a monoton dolgokat?
• A legfontosabb, hogy mit csináltál, mit bíztak rád, miért feleltél, mit értél el az eddig munkahelyeiden. Ez mindenképp derüljön ki a dokumentumból.
• Az ötven oldalas, PDF-ben elküldött, baromi lassan renderelődő bemutató anyagtól lehetőleg külön legyen a CV, mert nincs ennyi időm. Bocs.
• Ne küldd el többször ugyanarra a hirdetésre a pályázatod, eléggé komolytalanná tesz. Inkább kérdezz rá a korábbira, ha nem kapsz választ. Ha szükséges, akkor vezess nyilvántartást, vagy legalább keress rá az elküldött leveleid között küldés előtt.
• Nem számíts mindig villámgyors válaszra. Ha egy cég új kollégát keres, akkor az általában azért van, mert sok a munka a meglévő emberek számára. Vagy a jövőben várhatóan sok lesz, de leginkább már most is sok. Ha a sok munka mellé még bejön a toborzás is feladatként, akkor ügyesen kell egyensúlyozni az ügyfélnek végzett munka és a felvételiztetés között. Nem nagy csoda, ha ilyenkor inkább az ügyfél kerül előtérbe, hiszen ő fizet, ő generálja az új pozíciót is. Másrészt ha fel is veszik az új munkatársat, a betanulási idő miatt csak később fogja tudni átvenni a meglévő feladatokat, valamint addig is csökkenteni a meglévő emberek hatékonyságát.
• A mondatvégi írásjelek és vesszők elé nem kell szóköz . Eléggé zavaró , valamint nyelvtanilag is helytelen .
• Derüljön ki, hogy befejezted-e az egyetemet, főiskolát. Ha nem, akkor legyen nyilvánvaló, hogy mikorra várható. Ha nincs beleírva, akkor az ember a legrosszabbra gondol.
• Nem különösebben lényeges, de azért vicces, amikor nem tudja az ember, hogy nő vagy férfi áll-e a CV mögött. Angol önéletrajz esetén vajon milyen sorrendben írta a családi és utónevét az illető? Ha összetéveszthető neved van, akkor érdemes kiemelni a családnevet.
• A vicces e-mail címek még mindig kerülendők. Akkor is, ha angolul vannak.
• Fénykép, pontos lakcím, születési hely és időpont nagyrészt felesleges. Van ezeknek bármilyen jelentősége, kellene, hogy befolyásoljanak bármit is? E-mail cím és telefonszám elég. Egy amerikaival beszélgetve szóba került, hogy ők a főiskola, egyetem és a korábbi munkahelyek kezdésének és befejezésének évszámát sem tüntetik fel az önéletrajzukban, csak annyit, hogy hány évet és hónapot tanultak, illetve dolgoztak az adott helyen. Aki akar ebből is találgathat a jelölt korára, de amúgy nem kellene, hogy jelentősége legyen ezeknek az adatoknak, csak tudja ellátni a munkakört az illető.
• A fájl neve ne CV.pdf legyen, valamint a megnyitott ablak címsorában is szerepeljen a neved.

Az, hogy túl zöld. Mondhatni sötétzöld. De ne legyünk ilyen durvák, nézzük a tényeket, spekulációkat.

Az SPCR fórumára bevágott WD Support által írt levelek és SMART adatok szerint a WD GP winyók 8 másodperc inaktivitás után parkolják a fejet. A másfél éve létező SCPR fórum után az elmúlt egy évben valamikor felkerült a hivatalos Western Digital tudástárba is egy bejegyzés a problémáról (The S.M.A.R.T Attribute 193 Load/Unload counter keeps increasing on a SATA 2 hard drive).

A funkció előnye, hogy kevesebb áramot fogyaszt a merevlemez, ellenben növekszik a SMART Load_Cycle_Count (LCC) számláló értéke. A winyó adatlapja szerint ezekből a parkolásokból legalább 300 ezret ki kellene bírnia. Ha azonban pechesek vagyunk, és mondjuk pont 10 másodpercenként nyúlunk a lemezhez (vagy megteszi egy programunk 10 másodpercenként), akkor ezt a 300 ezres számot viszonylag hamar elérhetjük (kb. 35 nap folyamatos üzem esetén).

Persze ez nem jelenti azt, hogy a 300 001-edik parkolás már biztosan nem fog sikerülni, és utána a winyón tárolt adatok sosem lesznek elérhetőek, de akkor is idegesítő. Főleg, ha a parkolás hangját is halljuk. A fentebb említett fórumon egyébként van néhány felhasználó, akiknek több milliónál jár ez a számláló és a winyó hibátlanul működik.

De nézzük, hogy miért nem túl fair a helyzet:

• A winyó adatlapján, weblapján, és általában úgy sehol sincs feltüntetve, hogy rendelkezik ezzel a funkcióval. A felhasználók egy része nem azért vett WD GP winyót, mert annyira zöld, hanem mert csak 5400-at fordul percenként, ami jóval csendesebb működést és kevesebb hőt eredményez, mint a szokásos 7200-as változatok. Tényleg érdekel valakit az a pár Watt? Tegyük hozzá, hogy a parkolás sem teljesen zajtalan művelet.
• A Raid Edition 2-es Green Power winyókhoz a gyártó kiadott egy firmware frissítést és egy programot, amivel ezt a funkciót testre lehet szabni (beállítható a timeout értéke), illetve teljesen ki is kapcsolható a parkolás. Ez a nem RE2-es változathoz nem készült el. Miért?
• Egyeseknek egy nem támogatott wdidle3.exe nevű program segítéségével sikerült kikapcsolni a funkciót. Másoknál ugyanez nem működik. Viszont valószínűleg ugrik a garancia, ha ezt használjuk.
• A fentebb linkelt tudástári bejegyzés szerint Linux alatt kikapcsolható a hdparm -B 255 paranccsal a funkció. Nálam HDIO_DRIVE_CMD failed: Input/output error hibával leáll a hdparm, és tovább nő az LCC értéke. Támogatás nincs, mert a WD nem támogatja a merevlemezeit Linux/Unix alatt.

Saját tapasztalat: Egy éves WD10EADS, 70 ezer körüli Load_Cycle_Count érték, tökéletes működés.

---

Frissítés, 2011. augusztus 12.:

A témáról a Prohardver is cikkezett nemrég. Ők is a WD egyik support oldalára hivatkoznak (Answer ID 5357), ami szerint lehet használni a wdidle3.exe-t Caviar Green lemezekkel. Pontosan idézve a support oldalt: „Set Idle3 to max time (effectively turns off load/unload power saving feature thus will use more power) per below link.”

A „below link”-et követve eljutunk az RE2GP Idle Mode Update Utility oldalára, ahonnan letölthető a wdidle3.exe egy figyelmeztetés mellett, mely szerint csak a WD1000FYPS-01ZKB0, WD7500AYPS-01ZKB0, WD7501AYPS-01ZKB0 modellekkel használható. Nem Raid Edition Green Power merevlemez nincs a listában. Az első lapon (Answer ID 5357) viszont Raid Edition merevlemez egyáltalán nincs említve.

Az anomáliáról kérdeztem a hivatalos supportot is, szerintük nem támogatott a WD10EADS, és a többi nem Raid Edition lemezek használata wdidle3.exe-vel: „Unfortunately this software was made for a specific model of internal drives and the Caviar Green GP drive is not one of them. It was made for RE3 drives.” (Igen, RE3-at írtak a levélben.) A support oldalt persze azóta sem tették egyértelművé, hiába kértem.

További adalék, hogy az eredeti, NGOHQ-n megjelent cikket a Western Digital PR is kommentálta, de a kommentben nyoma sincs tiltakozásnak, hogy a wdidle3.exe használata Caviar Green lemezekkel nem támogatott.

Ezek után nem könnyű eldönteni, hogy merjük-e a használni a wdidle3.exe-t, esetlegesen kockáztatva a garanciát, vagy inkább hagyjuk szépen növekedni az LCC-t.

Lentebb egy biztonsági mentést készítő szkript Sony PRS-650-hez. Amit tud: automatikus mount/umount, könyvtárlétrehozás dátum alapján, md5sum az elkészült mentésről, a database/media/audio/ alatti tartalmak kihagyása.

#!/bin/bash

### Sony PRS-650 backup script by palacsint, 2011. 07. 14.
### http://palacsint.hu/

INPUT_DIR=/mnt/prs650_internal
BACKUP_BASE_DIR=/backup/sony-prs-650


mkdir --parents $BACKUP_BASE_DIR || exit -1

BACKUP_DIR=$BACKUP_BASE_DIR/sony-prs-650-$(date +%Y-%m-%d)
echo "Backup directory: $BACKUP_DIR"
if [ -d $BACKUP_DIR ]; then
    echo "Backup directory already exists, skip backup"
    exit -1
fi

echo "Free space on backup drive: $(df -h $BACKUP_BASE_DIR | tail -1 | awk '{print $4}')"

MOUNTED=false
if mountpoint -q $INPUT_DIR; then
    echo "Input directory $INPUT_DIR already mounted"
    MOUNTED=true
else
    mount $INPUT_DIR || exit -1
fi


mkdir --parents $BACKUP_DIR || exit -1

rsync --whole-file --recursive --filter='exclude, database/media/audio/**' $INPUT_DIR/ $BACKUP_DIR

find $INPUT_DIR | sed "s:$INPUT_DIR::" | sed 's:/::' > $BACKUP_DIR/file-list

cfv -q -C -t md5 -rr -p $BACKUP_DIR || exit -1

echo "Backup size: $(du -sh $BACKUP_DIR | awk '{print $1}')"

if [ "x$MOUNTED" = "xfalse" ]; then
    umount $INPUT_DIR
    sync
fi
echo "Backup OK"

Adott a következő könyvtár, amely napi mentéseket tartalmaz negyedévenként külön szülőkönyvtárban:

...
backup-2011q1/backup-2011-03-31
backup-2011q1/backup-2011-04-01
backup-2011q2/backup-2011-04-02
...

Az egyes napi mentések nem túl nagyok, de azért jó lenne egy idő után hatékonyan tömöríteni őket. Tart és gzipet vagy bzip2-t használva nem nyerünk sokat, a jelen esetben néhány száz megás, minimálisan eltérő napi mentések tömörített mérete csak 10-20 százalékkal kisebb, mint a könyvtárak tömörítetlen mérete.

A tar fájl a benne lévő fájlokat elérési útjuk szerinti ábécé sorrendben tárolja. Így a mindegyik napi mentésben előforduló azonos fájlok egymástól távol kerülnek a tar fájlban. A távolság miatt a gzip/bzip2 nem ismeri fel az ismétlődő mintákat, ezért nem tömörít hatékonyan. (Aki otthon van a témában, nyugodtan javítson ki, pontosítson kommentben.)

Gyors megoldás, ha gzip/bzip2 helyett 7-Zip-et használunk. Sajnos a gzip/bzip2 párost semmilyen paraméterrel nem sikerült rávennem, hogy maguktól felismerjék ezeket az ismétlődéseket, de a tar tartalmának megfelelő sorrendezésével segíthetünk a dolgon.

Erre két javasolt megoldás a credentiality blogon található. Az MD5 hash alapján történő sorrendezés megtalálható az előbbi linken, a fájlnév alapú sorrendezésre pedig egy példamegoldás a következő:

$ cat ~/bin/tar2 
#!/bin/bash
export GZIP=-9
find "$1" -type f | awk '{split($0, pathElements, "/"); print pathElements[length(pathElements)] "\t" $0 }' | sort | cut -f 2- | tar czvf "$1.tar.gz" -T -

Sajnos a tar tartalmának megfelelő sorrendezése nem segít az ismétlődő, de túl nagy fájlok tömörítésén, ezen ismétlődéseket a gzip/bzip2 továbbra sem fogja felismerni. A 7-Zip használata erre is megoldást jelent.

Az Effective Java című könyvben is szerepel, hogy nem ajánlott nullt visszaadni, inkább részesítsük előnyben az üres tömböket és az üres kollekciókat, ha tömb vagy kollekció a visszatérési érték típusa. Lentebb arra látható egy példa, hogy JAXB használatakor hogyan kell annotálni az osztályunkat, hogy az unmarshall után a JAXB ne hagyjon maga után nullokat a kollekciók értékeként.

import java.util.LinkedList;
import java.util.List;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlElementWrapper;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
@XmlAccessorType(XmlAccessType.NONE)
public class Data {

    @XmlElementWrapper(name = "list")
    @XmlElement(name = "list-element")
    private final List<String> list = new LinkedList<String>();

    public Data() {
    }

    public List<String> getList() {
        return new LinkedList<String>(list);
    }

    public void setList(final List<String> list) {
        if (list == null) {
            throw new IllegalArgumentException("list cannot be null");
        }
        this.list.clear();
        this.list.addAll(list);
    }
}

Érdemes megjegyezni, hogy ha a getter metódusra kerülne a @XmlElement annotáció, akkor a metódus által visszaadott listába kerülnének a JAXB által felvett elemek, emiatt a getterben nem lehetne másolatot visszaadni a belső listáról.