2024. március 28., csütörtök

Gyorskeresés

Útvonal

Cikkek » Számtech rovat

Irodai munka másképp 1.

  • (f)
  • (p)
Írta: |

1. Előzmények Szakmai életemet nagygépeken kezdtem, CM52 (ciril betűkkel értve), R55,...

[ ÚJ TESZT ]

1. Előzmények

Szakmai életemet nagygépeken kezdtem, CM52 (ciril betűkkel értve), R55, S/360, DOS, CMS, OS, PTS és hasonló operációs rendszerek alatt. Egyetemista koromban meg kellett tanulni az xedit nevű 3270-es terminálon futó editor használatát. Amikor vax/vms-en lettem rendszergizda, az már kész havaj volt ezekhez képest. Így azután elég bambán néztem, amikor windowsok kezdtek szivárogni az egyetemre meg az otthonokba, nem is szoktam meg, nem is szerettem meg soha. Viszont mondtam már annyi kritikát róla, hogy időszerűnek látszik azt is megmondani, hogyha nem msoffice, akkor mi? Így tehát most egy szakmainak szánt cikk megírása a szándék (nem teszek erőszakot magamon, a flamelést nem zárom ki teljesen), ahol egy másik megoldás irányvonalait szeretném felvázolni. Teljes megoldásra nyilván nincs lehetőségem, de az irányokat talán meg tudom mutatni.

2. Microsoft Office

2.1 Szövegszerkesztés

Nekem minden bajom volt már vele, ahogy mondani szokták: a szó elszáll, de néha a word is. A legfontosabb bajom vele az, hogy olyan dolgokra kényszeríti rá a felhasználót, amihez a felhasználónak nincs se érzéke (a legtöbbnek) se szakképesítése. Egy levél, könyv nem nézhet ki akárhogyan, azt tipográfusnak illene megterveznie. (Mint ahogy rendesebb multinál csinálnak arculati tervet, ami a levélpapíról a vállalati autók oldalfestésén keresztül a budipapírig mindennel foglalkozik, csak azzal nem, hogyha idejön az agyhalott multi, akkor miért nincs a hivatalosan megvásárolt hivatalos vállalati betűkészletben ékezetes karakter, mert ő olyat még nem látott a nagy pocsolyán túl).

Emiatt számomra az, hogy egyes szövegszerkesztőkben milyen egyszerű megváltoztatni a margót vagy a fejlécet, nem előny, hanem hátrány. Mert ez azt jelenti, hogy egy normális tipográfiai tervet milyen egyszerű lerombolni. Egyébként is: ha én levelet akarok írni, engem a levél tartalma érdekel, nem a formája. Válasszuk végre el a tartalmat és a formát. Nem akarok wysiwyg szövegszerkesztőt, értelmetlennek tartom (nem is láttam még olyat egyet se, amelyik minden nyomtatón és minden feltelepített rendszeren ugyanúgy nézne ki).

Ha szétválasztottuk a tartalmat és a formát, akkor már csak a tartalom beírása marad. Erre mindenki olyan szövegszerkesztőt használ, amilyet akar, feltétel, hogy ascii szövegfile-ba lehessen menteni. Nekem jó a krómozott nyelű kőbalta, a vim. A vim az eredeti visuak editorból lett vi továbbfejlesztett változata, vi improved néven. [link] Én elhiszem, hogy ezt sokan fapadosnak találják, de ez a program akkor is működik, ha lassú telefonvonalon kell távoli gépen dolgozni és akkor is használható, ha mindenféle varázslás szerű dolgokat kell csinálni. Meg nyilván benne van a megszokás faktor is. Ki mivel találkozott először, azt szokta meg. A vim filozófiája, ''életérzése'' nagyon közel áll ahhoz, amilyen régen a norton editor meg a pe2 volt.

Ha vim-ben írjuk be a tartalmat, akkor ott pontosan az lesz benne, amit beleírtunk. Se több, se kevesebb. Az igazi programozó [link] szerint az azt kapod, amit látsz elv ugyanolyan helytelen a szövegszerkesztőknél, mint a nőknél. Ezt akartad, hát nesze!

Ha bekerült a tartalom a gépbe, akkor azt meg kell formázni. Itt kerül a képbe Erdős Pali bácsi (szegény már nincs közöttünk) mint egyik leghíresebb magyar matematikus és Donald E. Knuth [link], aki többek között A számítógépprogramozás művészete című művével (amit a programozók a bibliájuknak tartanak) lett híres. Hogyan függ össze a kettő? A legendák szerint Knuth megunta, hogy nem tudják normálisan kiszedni a nyomdában a könyvét és mérgében megalkotta a TeX dokumentumformázó rendszert. Mivel nagy barátja és tisztelője volt Erdős Pali bácsinak és sértésnek gondolta volna, ha nem tudja leírni helyesen a nevét, ezért a TeX már akkoriban tudott ékezethelyesen hibátlanul magyarul, amikor a windows még csak 1.0-ás verziójában botladozott.

Gondoljunk csak bele, amikor nálunk még csodaszámba ment a 20 megabyte-os vinyó, az st-225 még húha dolog volt, akkor a TeX már 14 megabyte-ban elfért a diszken és tudott magyarul. Most, amikor a terabyte-os diszkek jönnek a piacra, 500-asokat már simán lehet venni, a vista megelégszik 4-5 giga diszkkel, a TeX még mindig csak néhány megabyte és még mindig hibátlanul tud magyarul.

A TeX-ről azt tartják, hogy hibátlan program. Ennek előmozdítása érdekében Knuth feldobott egy ígéretet: aki hibát talál a TeXben, kétszer annyi dollárt kap érte, mint az előző ''nyertes''. Tudtommal a 10240 dolláros csekket már kiosztotta évek óta, de azóta semmi.

Persze azért ''gyalog'' TeX-ben tördelni meglehetősen favágó munka. Nem merném titkárnők kezébe adni. A TeX-hez nagyon sok makrócsomag, kiegészítés készült, az egyik legismertebb ilyen a Leslie L. Lamport által készített LaTeX csomag, ami teljesen emberbaráti szintre hozza a tex-es munkát. Erről később még többet írok.

2.2 Táblázatkezelés

Nekem táblázatkezelésben a gnumeric jött be eddig, ritkábban az openoffice.org calc-ja. A gnumericben az tetszik, hogy tud latex kimenetbe exportálni. Így triviálisan tudom táblázataimat a doksijaimba belerakni. A másik, ami nekem fontos, hogy az openoffice.org calc-ja és a gnumeric is hajlandó ascii txt-be menteni. Hogy miért, erről is később.


2.3 A drótok. egyebek

Sokszor van szükségem olyan rajzokra, amik hálózati struktúrát ábrázolnak. Erre nekem a linuxos dia a legjobb [link] (figyelem: azt írtam, *nekem* a dia a legjobb, nem azt, hogy úgy általában mindenkinek a dia a legjobb).

3. Az svn

Az én irodai melómban a nagy csodákat az svn, eredeti nevén a Subversion szerverek csinálják. [link]. Aki a következő szakkifejezések közül bármelyiket is ismeri, az az svn alfejezetet kihagyhatja: cvs, sccs, rcs.

3.1 Mi ez?

A subversion úgynevezett verzió követő rendszer. Az alapvető feladata, hogy programfejlesztői projektekben a forráskód adminisztrálását megoldja. Magyarul sok ember sok-sok forráskód részleten dolgozik egyszerre és ezeknek a párhuzamos kezelését, összeegyeztetését végzi.

Az svn-hez tartozik egy közös kódtár, amit leginkább az egyéb munkák esetén a munkadarabok raktárához lehet hasonlítani. Ha egy programozó dolgozni akar, ebből a raktárból kiveszi azt a forráskód részletet, amivel dolgoznia kell (eredeti kifejezés szerint checkout-olja), elvégzi a szükséges munkát, majd visszapakolja a raktárba (eredeti kifejezéssel commit-olja).

Felmerülhetnek konkurrencia kérdések, mi van, ha ugyanazt a forráskód darabot többen is kivették a raktárból? Erre egyrészt van zárolási lehetőség, tehát meg lehet akadályozni ezt, másrészt van úgynevezett háromutas különbségképzés a rendszerben, Ez azt jelenti, hogy van egy darab forráskód a raktárban, azt kivettem a saját merevmelezemre, arról rögtön készül egy biztonsági másolat a saját merevlemezemre (ez a második példány) plusz kapok egy munkapéldányt is (ez a 3. példány). Az svn rendszer képes nyomon követni, hogy az én munkapéldányom mennyiben változott az én biztonsági mentésemhez képest (egyik út), a biztonsági mentésemhez képest változott-e a központi raktár (mert másik programozó kolléga szintén belenyúlt), és a kettő folyományaként van-e különbség a munkapéldányom és a központi állapot között (nyilván van, ezért kapom a fizetésem).

Az svn ezt a három különbséget képes úgy lekezelni, hogy ha elvileg megoldható a három verzió összeolvasztása, akkor simán összeolvasztja, ha nem, akkor egyesével lehet dönteni, hogy melyik változtatás marad érvényben.

A másik kedvenc svn tulajdonságom, hogy létezik hozzá alkalmazásszintű mirror program, tükröző rendszer. Fel tudok telepíteni két különböző gépre két svn szervert (elsődleges és másodlagos verzióban) és meg tudom oldani, hogy ha az elsődlegesre betoltak valami változtatást, azt a másodlagosra tükrözze át, hajtsa végre. A változások rögzítése atomi művelet, tehát nem fordulhat elő olyan, hogy egy hálózati probléma miatt csak félig kerül be egy kód a rendszerbe. Vagy teljesen bekerül, vagy teljesen kimarad.

3.2 Mire jó?

Az svn szervernek fogalma sincs arról, hogy az a file, amit én beletolok, mit tartalmaz, nem is érdekli. Csak annyi érdekli, hogy tud-e három utas diffet csinálni rajta vagy sem. Ez a tulajdonsága alkalmassá teszi arra, hogy programkódok mellett dokumentumokat, táblázatokat, grafikákat is tároljunk benne verziókövetéssel.

4. Példa1

Tegyük fel, hogy Gipsz Jakab diplomázni készül, szakdolgozatot ír. (itt most jön egy kis fikció, később megmagyarázom, miért). Tegyük fel, hogy Jakabunknak van olyan ismerőse, aki ehhez az egész miskulanciához ért. Tegyük fel továbbá, hogy Jakab számára nagyon fontos az adatbiztonság, nagyon nem szeretné leadás előtt 2 nappal elveszíteni a teljes szakdolgozatát, mérési eredményeit, grafikonjait. Ez utóbbi feltétel azért nem annyira fikció

Gipsz úr, segítséggel, tehát a következő megoldásra jut. Csinálnak számára egy svn szervert (no, ez a pont a fikció kicsit). Jakabunk ezek után bármelyik gép elé leülhet, ott jelszóval védett helyről előkaphatja hálózaton keresztül a saját munkáját és dolgozhat vele. Ha elkészült az aznapra tervezett feladattal, visszatolja a raktárba az egészet. Ha rendes helyen van az az svn szerver, akkor a munkáját központilag biztonsági mentik.

Jakabunk esetleg hazautazik hétvégére a szülőkhöz, de gépet nem cipel magával. De az svn szervert otthon is eléri, otthonra is ki tudja kérni a munkáját, dolgozhat, visszatöltheti, amit csinált.

4.1 Miért jobb ez?

Felmerülhet a kérdés: miért jobb ez így, mint a hagyományos módszerek?

A kérdés jogos. A tapasztalat az, hogy az átlag felhasználónak fogalma sincs arról, hogy az adatait védenie kellene. Felirogatja a cuccát egy pendrive-ra és bambán néz, ha a kulcs kikészül vagy elveszti. Nagyon sokan nem gondolnak arra, hogy rendszeresen mentsék a munkájukat, valamiből az adatmentő cégeknek is meg kell élniük...

A fikcióról: svn szervert csinálni nem egy nagy durranás. Értem ezalatt azt, hogy nem kell hozzá extra tudás (jó, bölcsész nem feltétlenül fogja megcsinálni magától), de egy kis doksi olvasással mehet. Mindenhol lehet csinálni svn szervert, ahol magát az svn programot telepítették, nem kell hozzá rendszergazdai jogosultság. Tehát ha van az egyetemen egy linuxos vagy unixos accountja, oda minden további nélkül csinálhat svn raktárat. Ezért mégsem akkora fikció ez, mint ahogy elsőre tűnik.

5. Példa2

Tegyük fel, hogy van a vállalatnak több olyan dokumentuma, amit sok mindenkinek kell olvasnia, javítania, szerkesztenie és rendszeresen használják mások. Egy szabályzat, egy szerződésminta lehet ilyen tipikusan.

Egy ilyennek a szerkesztése más rendszereken, mint pl. ms word, úgy történne, hogy valaki megírja az alap dokumentumot, majd ezt szétküldi x darab embernek véleményezésre. Az x darab ember bekapcsolja a változtatások nyomkövetése (track changes, ctrl shift e, ha jól tudom) gombot a word-ben és belefirkálja a véleményét a doksiba. Majd visszaküldi a doksit az eredeti feladónak, aki sok gomb megnyomogatása után egyesíti a doksikat wordben. Ekkor elvileg kap a főnök egy olyan docot, amiben egy-egy mondatra akár több variáció is olvasható, monogrammal jelölve, hogy ki mit javított és eldöntheti, hogy melyik verziót tartja meg. Ha minden olyan mondatnál eldöntötte, hogy melyik maradjon meg, akkor a doksit véglegesítheti (ezt nem szokták politikusaink tudni, így kerül ki a sok anyázási alapanyag a netre, ők töltik fel a benne maradt track changes infóval). Na ez az, amit nekem meg az ismerőseim között többeknek még soha nem sikerült megcsinálni. Valahol mindig megomlott az egész terv, maradt a kézi újragépelés meg a cutandpaste.

Ugyanez latexben meg svn-nel: checkout, javítás, commit. közben senki nem tölti az idejét feleslegesen a tördeléssel, kinézettel. Majd jön a főnök, aki a változtatásokat elfogadja, csinál egy svn release-t és kész.

Ne feledjük: a hivatalosan elfogadott verzió mindig az svn szerverben van. Nincs olyan gond, hogy Kis Pista már a saját diszkjén levő verzióba beleirkált, amit a főnök jóváhagyott, de erről Nagy Pista nem tud és ő is beleirkál, és akkor jön a zájgenzi zűrzavar. Nem commitoltál, mehecc sóhivatalba félliteres okmánybélyeggel.

(Úgy látom, az eddigiek mérete indokolja, hogy másik cikkben folytassam. A kedves olvasó tehát megkapja az ígéretet: záros határidőn belül prezentálom a folytatást.)

Hirdetés

Copyright © 2000-2024 PROHARDVER Informatikai Kft.