Szeptemberi könyvajánló

"Itt van az ősz, itt van ujra, S szép, mint mindig, énnekem. Tudja isten, hogy mi okból Szeretem? de szeretem". Csodálatos mondatok ezek Petőfi Sándor virtuális billentyűzetéből származva, bár ami az igazságtartalmát illeti, némileg vitába szállnék vele. Tudom, erre a vitára a sors kegyetlenségéből már nem szakíthatunk időt, legfeljebb gondolatban. Az ősz nekem az elmúlás és a szomorúság hírnöke, mely jelzi a zord Tél tábornok hamarosan bekövetkező, és alighanem elkerülhetetlen megjelenését. Ugyanakkor jelzi azt is, hogy már szinte a nyakunkra hágnak azok a csendes esték, melyeket meleg szobában, a kanapé bugyrába süppedve tölthetünk, egy-egy jó bögre tea meg néhány kellemes könyv társaságában. Ezekhez az estékhez kívánok a kedves olvasóimnak némi munícióval szolgálni.

 

Az említett munícióhoz újfent az Amazon.com segítségével jutottam hozzá, természetesen némi pénzmagért cserébe. Lássuk röviden miről van szó.

 

1. Richard Whithead: Leading a Software Development Team (Addison Wesley kiadó, 368 oldal)

Az ember, ha már egyszer önhibáján kívül vezetői helyzetbe került, nem árt ha körbenéz a világban, hogy csinálják mások. Épp ezen okok miatt gondoltam, hogy utána nézek milyen tippek, trükkök és módszerek vezetnek el ahhoz, hogy valakiből jó fejlesztői csapatvezető legyen. Már 10 éve csinálom, de ez nem tántorít el attól, hogy tanuljak a nálam okosabbaktól és tapasztaltabbaktól. A hivatkozott könyv ígéretet tett arra, hogy hozzásegít ehhez.

 

A könyvről további információ itt olvasható.

 

2. Rozansky-Woods: Software Systems Architecture (Addison Wesley kiadó, 576 oldal)

Nem vitás, hogy a jó szoftver architektúra az élet sava-borsa. Annyiféle szoftver létezhet, melyek közül mind-mind eltérő célokkal, igényekkel, és ehhez mérten eltérő architektúrákkal is rendelkezhet, hogy úgy gondoltam elkel a polcon egy ilyen témájú könyv is. Sokan úgy vélik mindent tudnak már erről, én magam korántse vagyok így vele. Ezidáig jórészt egy adott szoftver típusra, és a hozzá kapcsolódó esetekre, módszerekre koncentráltam, de a könyv segítségével remélem, hogy részletesebben is megismerhetem az eddigiektől eltérő szoftverrendszerek lelkivilágát. Már csak azért is, mert hamarosan szükségünk lehet rá, ugyanis az eddigi technológia mellett gondolnunk kell az elkövetkezendő 8-10 évre is (de erről majd máskor).

 

A könyvről további információ itt olvasható.

 

3. Ken Pugh: Interface-oriented Design (The Pragmatic Bookshelf kiadó, 240 oldal)

A komponensek, objektumok, de még az adatbázisok és egyszerű függvények vagy eljárások világában is talán az egyik, ha nem a legfontosabb tényező az interfész. Az interfész, mely tulajdonképpen egy szerződés a szoftver komponens írója és felhasználója között, és amely befolyásolhatja a szoftver minőségét, működését. Állandó probléma és vita tárgya, hogy mitől jó egy interfész. Magam is évek óta gondolkodom ezen remélve, hogy egyszer rátalálok az igazán jó módszerre. Íme egy könyv, amely reményeim szerint ha meg nem is oldja, de legalább picit hozzásegít az igazsághoz.

 

A könyvről további információ itt olvasható.

 

4. Ron Patton: Software Testing (Sams kiadó, 408 oldal)

Nem csak fejlesztésből áll a világ, és szerintem egy fejlesztőnek (legyen az tervező vagy programozó) ugyanolyan szüksége van a tesztelési módszerek, megoldások ismeretére, mint azoknak, akik hivatásszerűen foglalkoznak ezzel. Bár hibátlan program nem volt és sose nem is lesz, azért próbáljunk meg legalább valamelyest közelíteni hozzá. Az első lépést megtettem, remélem más is így gondolja.

 

A könyvről további információ itt olvasható.

 

Szerintem egy fejlesztőnek egész életében tanulnia kell. Mese nincs, ilyen ez ami munkánk. Az internet kiváló eszköz, de azért valljuk be nem teljesen megbízható. Mindennek, amit ott olvashatunk, nagy valószínűséggel valahol máshol megtalálható az ellenkezője is. Épp ezért tanulás, fejlődés céljából én inkább a könyvekre szavazok.

 

"Mert olvasni NEM gyíkság…"

Extrém kérdések informatikusoknak

Elég régóta nyilvánvaló a számomra, hogy egy informatkusi munkához manapság a szakmai tudás önmagában már nem elegendő. Ez a mostani cikk is ugyanazt igazolja. Bár az is igaz, hogy itthon még nem elég érett hozzá a társadalom.

 

"Aki szeretne állást kapni a legjobb technológiai cégek valamelyikénél, nem árt elgondolkodnia azon, hogy hány golflabda fér egy iskolabuszba. Ilyen, és ehhez hasonló kérdésekkel bombázzák az informatikusokat a külföldi vállalatok állásinterjúin, itthon azonban még várat magára ez a trend.

[…]

A Microsoft már az 1980-as évektől kezdve használ úgynevezett nyitott végű logikai kérdéseket, amelyekre több válasz is létezik. Warren Ashtonnak, a Microsoft toborzási menedzserének például az egyik kedvence a kábelakna fedelének problémája, vagyis hogy az miért kerek, és nem négyzet alakú.

[…]

Hazánkban még nem igazán terjedtek el ezek az úgymond talányos kérdések… a kreativitás nem tartozik a legfontosabb tulajdonságok közé [mármint itthon], a legtöbb posztra jelentkező esetében, ennél sokkal többre értékelik a szakmai megfelelőséget, a motiválhatóságot, a lojalitást és a stressztűrő képességet."

 

Részletek itt.

 

Az elmúlt évtizedben (amióta inkább vezetőként és kevésbé programozóként tevékenykedek), többször volt lehetőségem új programozók interjúztatására, felvételére. Nálam soha se volt szempont az, hogy mekkora tudással rendelkezik az illető. Mindig a viselkedését, a kretavitását, a hozzáállását és a tanulási vágyát próbáltam felmérni amellett, hogy természtesen a szakmai alapképzettségét és alapképességeit is igyekeztem megtudakolni. Persze korántsem voltam/vagyok olyan céltudatos és okos, mint a fenti cikkben említett profik, de azért nagyon nem lőttem mellé.

 

Hirtelen összeszámoltam, hogy az elmúlt 9 év alatt 17 új programozót vettem fel (vagy aktív részese voltam a folyamatnak), akik közül 2 nálunk dolgozik, de nem tartozik hozzám (hanem a másik, biztonságtechnikai csapathoz), 9 már nem dolgozik nálunk, 6 viszont még mindig, nap, mint nap az én gondoskodásom alatt koptatja a forgószékeket – meg az idegrendszeremet (jelenleg összesen 13 programozó/technológus tartozik hozzám, köztük olyanok is, akik előttem vagy velem együtt érkeztek a céghez). Végiggondolva az elmúlt időszakot 1 ember kivételével (akit kirúgtunk) a maradék 8 önszántából hagyott el mindket. Vagyis abból 17-ből, akikhez e tekintetben nekem is volt némi közöm, kis jóindulattal mindössze 1-szer "nyúltam mellé", bár akkor alaposan.

 

Ez persze nem jelenti azt, hogy a most hozzám tartozó 13 ember mindegyikével vagy akár magammal meg lennék elégedve. Egy részük elkopott, más részük megváltozott az idők során, de nem előnyükre. Sok-sok év programozás kiöli a lelkesedést az emberből. Megértem őket, csak ez azok számára, akik semmi mást nem csináltak (vagy semmi máshoz nem értenek) elég kellemetlen. A cégről nem is beszélve. Kiégett, elfásult emberekkel nehéz hasznot termelni, és mint tudjuk van, aki képes változtatni, változni, és van, aki nem.

 

Egy ideje észrevettem, hogy engem is a hideg ráz akkor, amikor a könyvekben, cikkekben forráskódokat kell nézegetnem. Bezzeg régen! Emlékszem, 1988-ban a munkahelyről hazafelé a vonaton utazva, FORTRAN nyelven vetettem papírra az épp szükséges forráskódokat, melyek zömmel műszaki jellegű feldolgozások voltak (hegesztési számítások, NC-gépek vezérlése, anyagfelhasználás kalkulációk meg effélék). Az is eszembe jutott, amikor 1992-ben körbebástyáztam magam Turbo Pascal és az abból táplálkozó Turbo Vision keretrendszer dokumentációival, forráskódokkal, melyeket még a baráti összejövetelekre is magammal cipeltem arra az esetre, ha netán fogytán volna a kólavíz (alkoholt ugyanis sose iszom). Annyira előttem van az is, amikor 1995-ben, a repülőtéren a korfui indulásra várva Delphi 1.0 kézikönyvet olvastam – angolul, miközben a család meg a környezetemben lévők furcsa szemeket meresztettek rám, mondván: ki az a barom, aki nyaralásra szakkönyvet cipel magával? Hát én voltam. Az utolsó nagy, lelkes programozói fellángolásom a .NET hajnalára vezethető vissza, nagyjából 2000 vagy 2001 tájékára.

 

Nos, ezek az idők már elmúltak. Észrevettem magamon az érdeklődés hanyatlásának apró jeleit, minekután igyekeztem változtatni, új feladatok után nézni, amellett, hogy most is vannak saját moduljaim, forráskódjaim, melyeket ugyanolyan, "közönséges" programozóként karbantartok, mint az embereim a sajátjukat. Csakhogy most már – ha szabad ezt mondani – "magasabb" vagy feljebb lévő célok érdekelnek, melyekbe a forráskód bambulászása és a hajnalig tartó programozás nem fér bele. Ezek az új célok, vagy érdeklődési területek inkább a hatékonyabb szoftver projektekre és folyamatokra, a szoftverfejlesztésre (vagyis a szoftverrendszerek és nem programok fejlesztésére), és a szoftverarchitektúrára vonatkoznak. Hobbiként néha-néha foglalkozom operációs rendszer vagy adatbázis-kezelő architektúrákkal és elméletekkel is, már ha az időm engedi. Ez van.

 

Messzire kanyarodtam, abba is hagyom.

Az Excel 2007 számolási hiba oka

Pár napja nagy vihart kavart az Excel 2007 számolási "hibája", amikor  az =850*77.1 szorzat eredménye 65535 helyett 10000 lett. Most olvastam, hogy valójában nem számolási, hanem megjelenítési hibáról van szó. Tehát, ha valaki a nevezett kifejezést elosztja mondjuk 2-vel, akkor a jó eredményt fogja megkapni (és meglátni). Természetesen a hiba ettől még hiba, csak nem úgy és nem azért.

 

Részletek (angolul) itt.

Szárnyal a SUSE Linux

Ugye, ugye, ugye, hiába károgott a sok varjú. Hatékonyság, siker, profit, mint megannyi közhely. Ez kell. Persze mint tudjuk, nem árt egy gazdag "jóbarát" is a közelben, biztos, ami biztos alapon.

 

"A Novell és a Microsoft tavaly novemberi megegyezése nagy vihart kavart, de úgy tűnik, üzleti szempontból telitalálat a Novell számára. Justin Steinman, a vállalat marketingigazgatója elmondta: a pénzügyi év első három negyedévében a Novell Linux üzletágának eladásai 243 százalékkal növekedtek. A jelek szerint a növekedés üteme nem lanyhul: az október 31-én véget érő pénzügyi év lezárása után is ilyen mértékű nővülésre számítanak."

 

Részletek itt.

Bayer Linux Werke

Óóóó… Az egyik szemem sír, a másik BMW.

 

"A Microsoft és a Novell bejelentették, hogy a BMW és a Siemens is csatlakozott azokhoz a vállalatokhoz – többek között a Credit Suisse-hez és a HSBC-hez –, amelyek kihasználják a Novell és a Microsoft nemrégiben kötött együttműködésének előnyeit."

 

Részletek itt.

Erős második negyedévet zárt a Red Hat

Pénzt csinálni a linux-ból? No annak már van értelme. Hajrá.

 

"Továbbra is látványosan nő a Red Hat bevétele és nyeresége, ahogy egyre több ügyfél fizet elő a cég nagyvállalati linuxos termékeire, szolgáltatásaira. Az augusztus 31-én véget ért második pénzügyi negyedévben a Red Hat bevétele 28 százalékkal 127,3 millió dollárra emelkedett, miközben a nettó profit 18,2 millió dollárra ugrott, ami éves szinten 64 százalékos javulást jelent, de ezzel együtt is csak megfelelt az elemzői várakozásoknak, nem haladta meg azokat." 

 

Részletek itt.

Virtualizációs megtakarítás

Ezt a jövőt most még nem tudom elképzelni. Pár év múlva talán…

 

"A brit Butler Group szerint a vállalatok milliókat takaríthatnak meg a virtualizációs technológiák bevetésével, és egyértelmű, hogy az elkövetkező két évben ez lesz az adatközpontok egyik domináns technológiája. A virtualizáció segítségével csökkenthetők a működési költségek, ami felügyeleti oldalon ugyanúgy megmutatkozik, mint a villanyszámlán." 

 

Részltek itt.

Fokozottan figyelik a Wikipedia-t

A Wikipedia-ban én soha se bíztam meg igazán, úgyhogy ez egy jó kezdeményezés. Hátha segít abban, hogy a közzétett információ valóban jó minőségű és használható legyen.

 

"Németország lesz az első olyan állam, amely szigorú ellenőrzést eszközöl a szabad lexikon tartalmára vonatkozóan. A Wikipedia német nyelvű verziója korlátozza az azonnali szerkeszthetőséget, lehetőséget adva „szakértőknek”, hogy átnézzék a tartalmat, mielőtt az kikerül a webre. A módosítások körülbelül év végére lépnek életbe, és a felhasználói visszajelzéseknek megfelelően elképzelhető, hogy az angol nyelvű változatra is alkalmazni fogják." 

 

Részletek itt.

SQL Teljesítményfokozás-VIII.

Már jó régóta időzünk a rendezést biztosító ORDER BY utasításnál, ezért épp ideje, hogy egy utolsó, a rendezést támogató indexekről szóló résszel gyorsan le is zárjuk ezt a fejezetet.

 

Sokan, főleg a régebbi időkben tanult "szakik" a rendezést előszeretettel azonosítják az indexeléssel (ez valamikor így is volt, hiszen pl. a dBase rendszereknél a rendezést látszólag indexek létrehozásával hajtották végre). Manapság a rendezés önálló folyamat, a kettő között csak átmeneti kapcsolat fedezhető fel (pl.: az adatbázis-kezelő rendezést is végrehajt egy index létrehozásakor). Az biztos, hogy ha van egy index a rendezendő oszlopra, attól még nem biztos, hogy a lekérdezés eredménye is rendezett lesz.

 

Esetenként előfordulhat, hogy az ORDER BY végrehajtása gyorsabb, ha a bemenő adatok valamilyen korábbi művelet miatt előrendezettek. A sebességnövekedés nem túl nagy, ráadásul csak az esetek kis százalékában válik be. Például ha a rendezendő oszlop szerepel egy fürtözött index kulcsában, vagy rendezetten exportáljuk ki az adatokat, majd az eredményt visszaolvassuk. Az elsődleges előny ebbe az esetben az, hogy a keresés kevesebb lemezművelettel jár akkor, ha mindig előrefelé kell haladni egy sorban. Némely esetben további időmegtakarítást lehet elérni a rendezett táblák kettéosztásával (partícionálásával), mivel van olyan adatbázis-kezelő, amelyebben az esetben a két különálló táblán párhuzamos keresést is alkalmazni tud.

 

Példa az előrendezésre:

 

  1/a. eset:

   SELECT * FROM Table1

    ORDER BY column1;

             
  1/b. eset:

   SELECT * FROM Table1

    WHERE column1 <= ”

    ORDER BY column1;

   
  ELŐNY: 8/8 (vagyis 8 adatbázis-kezelőből mind a 8-nál javulást okozott)

 

A fenti 1/b. példában a WHERE záradék miatt lehetett egy hajszálnyi előnyhöz jutni azért, mert annak alkalmazása némi előrendezettséget okozott, és ez után az ORDER BY-nak már könnyebb dolga volt (az ORDER BY az előrendezettség dacára se elhagyható tényező). A rendezést tovább gyorsíthatja az a tény, hogy a feltétel kizárja a NULL értékkel rendelkező sorokat és így a rendezésnek ezekkel már nem kell foglalkoznia. Fontos tudni, hogy pl. Oracle esetén, csökkenő rendezettségnél ez nem működne hatékonyan, mivel ott nem lehet csökkenő rendezettségű index (pontosabban deklarálni lehet, de a rendszer figyelmen kívül hagyja).

 

Az adatbázis-kezelők összetett indexek használatára is képesek, például:

 

   SELECT column1, column2

     FROM Table1

    ORDER BY column1;

 

Ennek a lekérdezésnek a végrehajtása gyorsabb akkor, ha a colum1, column2 oszlopokra létezik egy összetett index (ELŐNY: 5/8).

 

Az adatbázis-kezelő esetenként képes az önálló (nem összetett) indexeket rosszul alkalmazni, például:

 

   SELECT column1, column2

     FROM Table1

    ORDER BY column1, column2;

   
Ennek a lekérdezésnek a végrehajtása viszont lassabb lesz akkor, ha a colum1 oszlopra létezik egy önálló index (ELŐNY: -3/8). A rendezés sebességének növeléséhez el kell távolítani az önálló indexet, vagy létre kell hozni egy colum1, column2 oszlopokra vonatkozó összetett indexet (ELŐNY: 3/8).

 

Azt hiszem rendezettségről, ORDER BY-ről ennyi elég is volt, legközelebb majd másról beszélünk.

 

Folytatjuk…

Magyar nyelvű szakkönyvek

Nem tudom ki, hogy van ezel, de én nagyon elégedetlen vagyok a hazai számítástechnikai szakkönyv-kínálattal. Ha röviden jellemeznem kellene őket, akkor azt mondhatnám, hogy: kevesen vannak, elavultak, és néhány kivétellel gyenge minőségűek (főleg az angolból fordítottak). Ez alól kivétel az a kétszáz darab Windows XP-ről meg MS Office-ról szóló könyv, ami a kutyának se kell.

 

Ha valaki felbattyog az Amazon-ra és a megfelelő helyen rákeres a számítástechnikai szakkönyvekre, akkor eláll szeme-szája. Bizony bárki napokig böngészhet kedvére és még akkor se ér a végére. Hihetetlen mennyiségű könyváradat mindenféle témában és árban. Sőt egy témáról akár 10-20 könyv is létezik több kiadásban (több évre visszamenőleg). Egyik jobb, mint a másik. Megnézhetjük az alapadatokat, a tartalomjegyzéket, esetenként minta fejezetet, korábbi olvasók véleményeit, stb. Sokszor vásároltam már náluk. Naprakészek és megbízhatóak.

 

Sose értettem, hogy amíg odaát ekkora a választék, nálunk miért ilyen gyenge. Komolyan foglalkoztat a gondolat, hogy valami olyan vállalkozásba kezdek, ami gyorsan és megbízhatóan fordít angol nyelvű szakkönyveket magyarra. Tudom, hogy ez nem egyszerű, de most már annyira tűrhetetlen a helyzet, hogy na. Arról nem is beszélve, hogy azon kevés fordítások közül, melyek megjelennek magyarul, némelyik egészen csapnivaló.

 

Hogy szerintem miért jobb magyarul olvasni, mint angolul? Hát elsősorban azért, mert magyarok vagyunk, másodsorban pedig sokkal gyorsabban és hatékonyabban olvasunk az anyanyelvünkön (tapasztalat), mint ángilusul. Nem tudom, hogy milyen ez a piac, azt se tudom lenne-e keletje a jobb számítástechnikai könyvek gyors és jó minőségű fordításának, de azt  tudom, hogy szívesen csinálnék ilyesmit.

Windows – Linux, mint két jó barát

Ez nem új hír, néhány napja már beszámoltak róla. Most csak arra szeretném ráirányítani mindenki figyelmét, hogy: lehet ezt így is csinálni. A mellett, hogy egymás ellenfelei, mégis képesek az együttműködésre és nem is akárhogy. Jó lenne, ha a magát "közösségnek" gondoló csür… bocs, csoportosulás is végre példát meríthetne belőle, de iziben.

 

"A Cambridge-ben található laboratóriumban a Microsoft és a Novell mérnökeiből álló csapat dolgozik majd a Windows Server és a SUSE Linux Enterprise jobb együttműködésének fejlesztésén. A laboratórium első feladata a Microsoft és a Novell virtualizációs technológiái közötti együttműködés biztosítása lesz. A további tervek között szerepel a szabványalapú rendszerfelügyelet, a személyazonosság-kezelési szövetség és az irodai dokumentumformátumok kompatibilitásának megteremtése." 

 

Részletek itt.

Új ár-teljesítmény rekord

Többféle tranzakciós mérés van, a TPC/C csak az egyik közülük. A méréseket a tpc.org végzi.

 

"A 73 dollárcent/tpmC ár-teljesítmény arány mellett elért percenkénti 102 454 tranzakciós rekorddal az Oracle Database 11g Standard Edition One a következő legjobb versenytárshoz képest mintegy 47 százalékkal nagyobb teljesítményt kínál 20 százalékkal alacsonyabb költségek mellett. A rekordot Windows operációs rendszer alatt érték el az Oracle Database 11g-vel, a hardveroldalon egy 2,66 GHz-es, négymagos Intel Xeonokra épülő HP ProLiant ML350G5 szerverrel, illetve egy HP StorageWorks 70 tárolóval." 

 

Részletek itt.

A Microsoft-büntetés hatása

A "The Wall Street Journal" újságnak biztos nem kell cégér, elég nagy tekintéllyel rendelkezik a pénzeszsákjukon gubbasztó kapitalisták köreiben, meg a világ sikeresebb felében. Állításuk szerint káros és dicstelen az EU-bíróság Microsoft-ellenes döntése, és ezt iziben meg is indokolják. Egyetértek.

 

"A vezető amerikai gazdasági napilap keddi szerkesztőségi cikkében úgy fogalmazott: a számítástechnikai ipar már bebizonyította, hogy képes önmagát szabályozni a verseny útján. A luxembourgi bírák helytelen módon úgy gondolják, hogy a kutatólaboratóriumok helyett a tárgyalótermekben kell lefolytatni ezt a versenyt.

 

Az Európai Közösségek luxembourgi székhelyű Elsőfokú Bírósága előző nap elutasította a Microsoft keresetét, és jóváhagyva az Európai Bizottság által korábban kiszabott, 497 millió eurós bírságot, megállapította, hogy számítástechnikai óriásvállalat visszaélt piaci erőfölényével.

 

A The Wall Street Journal szerint az európai szabályozók és bírák magatartása nem serkenti az innovációs tevékenységet. A döntés tulajdonképpen újabb figyelmeztetés a termékeiket fejleszteni "merészelő" információs technológiai cégeknek. A Microsoftnak tavaly például egyeztetnie kellett az EU-bizottsággal a Vista operációs rendszer egyes elemeiről, mielőtt azt piacra dobhatta volna. Ez sem a fejlesztőknek, sem a fogyasztóknak nem válik hasznára.

 

A New York-i újság szerint a luxembourgi döntés el fogja gondolkodtatni az amerikai nyugati partvidék vezető információs technológiai vállalatait: ha a Microsoft térdre kényszeríthető, senki sincs biztonságban. Brüsszel trösztellenes kopói már vizsgálják az Intel működését, és a hétfői verdikt után felbátorodva támadást indíthatnak az Apple vagy a keresőprogramokban piacvezető Google ellen is."
 

Részletek itt.

 

E helyütt már magam is többször hangot adtam annak a gondolatmenetnek, hogy mennyire nem szívlelem holmi idióta EU-bürokraták efféle törekvéseit – cégnévtől, mérettől, helyzettől és pozíciótól függetlenül. Ocsmány banda nem vitás.

 

Bár az én cégem nincs abban a helyzetben, hogy az itt elmarasztalt Microsoft-hoz hasonlíthatná magát (sajnos), de azért módfelett neheztelnék arra, aki minket, vagy engem korlátozna a termékeink előállításában, piacra vitelében. Azt meg főleg elítélném, ha arra köteleznének, hogy osszam meg az első velem szembe jövő ketymekütyü fejlesztőcéggel a saját értékeimet (mindenki értse, ahogy akarja). Az én cégem, az én felelősségem. Úgy harcolok, ahogy tudok, vagy amilyen lehetőségem van. Most egy ilyen világban élünk és ezt tudomásul kell venni (aki jobbat tud, szóljon). Emlékezzünk arra, hogy 20 évvel ezelőtt a redmondi sátánfajzatok még úttörők se voltak mondjuk az akkori nagy informatikai cégekhez képest. Nekem itt senki se merészeljen monopóliumot kiáltani akkor, mikor bárki megtehette volna azt, amit ezek megtettek az elmúlt évtizedekben. Az más kérdés, hogy mindenki töketlen idióta volt (és most is az). Na, de ezt már többször mondtam korábban, úgyhogy abba is hagyom. Mindenesetre elegem van már a nyavalygásból, hogy "így a Microsoft", meg "úgy a Microsoft" – vagy akárki légyen is. Folyton-folyvást mindenki csak világ végét kajabál, holott messze vagyunk még attól.

 

Mondok egy példát. Az általunk fejlesztett ERP-szoftverrendszer (az egyik termékünk) tartalmaz egy olyan elemző, vezetői döntéstámogató, lekérdező modult, melyet integrált részként hozzáadunk a csomagunkhoz. Egy rendkívül sikeres eszközről van szó, amit szeretnek a felhasználóink (mondjuk, hogy olyan, mint a Windows-ban a Media Player). E mellet persze bárki más telepíthet akármilyen, nem tőlünk származó lekérdező eszközt, pl.: Crystal-t vagy bánomisén (mondjuk úgy, ahogy a Windows-ra is bárki telepíthet RealPlayer-t vagy MPlayer-t). Most tételezzük fel, hogy azoknál a cégeknél, ahova mi szállítottuk az ERP-megoldásunkat (melléadva az említett lekérdező modult is), az évek során alapos előnyünk halmozódott fel, pont emiatt. Azaz mi vagyunk az erősebbek, elvégre hozzáadjuk a rendszerünk mellé azt, amit egyébiránt mások is fejlesztenek, önálló terméként (biztos mindenki érti nem ragozom tovább).

 

Namármost, jól is néznénk ki, ha megjelenne a kapuban egy másik, lekérdező, elemzőeszközt gyártó cég azzal a felkiáltással, hogy "ugyan adjuk már át neki az adatbázisunk és üzleti folyamataink részletes leírását azért, hogy ő is készíthessen a mi rendszerünkhöz, a mi ügyfeleinknél pont ugyanolyan elemzéseket vagy tán jobbat is, mint mi" (ezáltal hasznot húzva belőlünk). Rögvest a Dunának mennék. Főleg akkor, ha ez a cég fogná magát és még jól be is perelne minket azért, mert nem adtuk át neki a kívánt, saját adatbázis-információkat, meg mert elvesszük tőle a lehetőséget a saját ERP-rendszerünkhöz "ingyen" adott, egy az övéhez rendkívül hasonló lekérdező eszköz miatt. Gyomorforgató.

 

Senki se gátoljon meg abban, hogy olyan és annyi plusz szoftvert adjak a saját stratégiai termékemhez, amennyi csak jól esik nekem! Senki. A Media Player mellett is elfér más, az Internet Explorer mellett is elfér más, a mi eszközünk mellett is elfér más (de ha nem az se érdekelne, elvégre az enyém, én fejlesztem, azt csinálok vele amit akarok). Mellesleg az se érdekelne, ha miattam vagy az én üzletpolitikám miatt esetleg az összes lekérdező, elemző és vezetői döntéstámogató rendszer kipusztulna (nem fog, de tegyük fel). Miért is érdekelne? Az én cégem, az én termékem, az én módszerem, vagy ha úgy tetszik az én monopóliumom lesz előbb-utóbb. Csakis én harcoltam ki magamnak hosszú évek kemény munkájával, sok sok forintmilliárdot beleölve azt a piacot, melyen uralkodó vagyok. Nem adok semmit se belőle és kész.

 

Remélem elég világosra sikeredett a magyarázat.

Követelmények

Biztos sokan tudják, hogy a szoftverfejlesztés folyamatát, az előállított termék minőségét, sikerességét sok-sok feltétel befolyásolhatja. Akadnak olyanok, akik ismerik ezeket a feltételeket, mások csak azt hiszik, megint mások pedig

bele se gondolnak – csak kódolnak.

 

Pedig rengeteg múlik a feltételeken, és azok megfelelőségén. Az egyik, ha nem a legfontosabb feltétel a jó követelményjegyzék. Ez az, ami tartalmazza a megrendelő elvárásait. Természetesen ez a megrendelő lehet külső (ez a gyakoribb), vagy belső, de akár a programozó maga is. A követelményjegyzék lényege az, ami a neve: tartalmazon minden célt, elvárást, vélt vagy valós igényt, amit a szoftvernek tudnia kell, legyen az bármily kicsi is. Gyakran még annak is szerepelnie kell benne, hogy egy adott szoftver "hogyan" csináljon meg valamit. Egy rossz követelményjegyzék tragédiák sorához vezethet, és mérhetetlenül nagy anyagi vagy erkölcsi kárt okozhat (sajnos tapasztalatból tudom).

 

A lenti táblázat egy érdekes megállapítást tartalmaz arra nézve, hogy mekkora veszteséget okozhat az, ha a fejlesztési folyamat egyes fázisaiban kiderül, hogy egy korábbi, azt megelőző fázisban hiba volt (azaz valaki vagy valakik tévedtek). A vízszintes sor a fejlesztési fázist, a függőleges pedig az adott fázisban kiderült hiba jellegét takarja (a hiba itt nem kifejezetten programhibát jelent).

 

Probléma jelleg | Követelmény | Tervezés | Megvalósítás | Tesztelés | Utógondozás

Követelmény            1x          3x         5-10x          10x        10-100x

Tervezés               –           1x           10x          15x        25-100x

Megvalósítás           –           –             1x          10x        10-25x

 

Forrás: Steve McConnell – Code Complete

 

Mi az, ami ebből látszik? Hát… sokminden. Például az, hogy ha a megvalósítási (kódolási) szakaszban derül ki, hogy hiba van a követelményjegyzékben, akkor ez az eredeti tervekhez képest 5-10x nagyobb költséget jelent majd a végelszámoláskor. Ha azonban a probléma vagy hiányosság a fejlesztés végén, már az utógondozási fázisban bukik ki, akkor a költségnövekedés akár 10-100x nagyobb is lehet. Tehát legrosszabb esetben még az is előfordulhat, hogy egy-egy hibásan vagy hiányosan megfogalmazott követelmény bizony veszteségessé is teheti a projektet.

 

Ez azért eléggé rémisztő nem? Sajnos, esetenként nálunk is pont ilyen problémák okozzák a legnagyobb veszteséget. Van olyan projekt, ahol kevésbé, de olyan is akad, ahol nagyon (a jövőben ezen próbálunk javítani valamelyest – remélem sikerrel).

 

Vajon azok, akik pusztán szórakozásból, csak a saját fejük után fejlesztenek szoftvert, tisztában vannak-e azzal, hogy egyébként a való világban hogy mennek ezek a dolgok? Azok, akiknek nem kell megküzdeniük a folyton követelőző, vitatkozó megrendelőkkel, nem kell határidőket betartaniuk, nem kell az állandóan változó igényeknek megfelelniük, hogyan teljesítenének ilyen körülmények között? Költői kérdés volt, nem kell rá válaszolni…

A Linux-fejlesztők nem szeretik a hibajelzéseket

Na, de fiukák, ejnye-bejnye! Eddig azt hittem, hogy sok a sok lelkes programozó, ételt-italt nem véve magához, mint megannyi szorgos kínai tüsténkedig imádott bálványának jobbá tételén és erre tessék. Elvégre minden egyes Linux-hiba kigyomlálása egy újabb szög lenne a redmondi halálcsillagon ügyködő hozzánemértő, rothadt, pénzéhes, kapitalista-monopolisták koporsójába, vagy mégse? Nahát,… mekkora csalódás ért mostan engem. Éppen.

 

"Jelenleg 1 500 nyitott bug van a Linux kernel bugtracker rendszerében. Natalie ezeket tisztítgatja és eljuttatja a fejlesztőkhöz. Ha a fejlesztők válaszolnak, akkor az jó, annak lehet eredménye. De nem sok fejlesztő tesz így.

A probléma sokszor azzal van, hogy sok bugreport egyszerűen elveszik. Bejelentik az alrendszerek levlistájára, de ott elfelejtődnek. […] Jelenleg 50 megválaszolatlan bugbejelentés van a linux-kernel listán. […] Linus megjegyezte, hogy sokan már nem is olvassák az LKML-t. A forgalom akkora, hogy követhetetlen és új lista bevezetését javasolta a bugbejelentések számára." 

 

Részletek (magyarul) itt.

Eredeti hír (angolul) itt.

 

Akkor most elmesélem, hogy megy ez nálunk, hátha valakit érdekel (csak az új olvasók kedvéért – már ha akad ilyen mostanság). Előre jelzem, hogy mi (is) egy olyan… csúnya, gonosz, elmaradott, ódivatú cég vagyunk, akik nem átallanak zárt forráskódú ERP-rendszert meg egy hasonlóan zárt forráskódú biztonságtechnikai szoftvert fejleszteni, és ilyen-olyan módon még pénzt is kérni érte – lehetőleg minél többet (de ezt már sokszor írtam na).

 

Először is létezik egy önálló szervezeti egység, melyet "Minőségbiztosításnak" neveznek (ISO9001:2000 előírás, hogy legyen egy ilyen szervezet, méghozzá a fejlesztésről leválasztva). A minőségbiztosítás felel egyrészt az egész vállalaton belül az ISO előírásainak a betartásáért (több-kevesebb sikerrel), másrészt ők végzik az ERP-szoftverrendszer tesztelését (bitang nagy és összetett rendszerről van szó), valamint ők felelnek a HelpDesk szolgáltatásért is. Jelenleg 5+1 állandó létszámmal működnek (fénykorunkban több, mint tízen voltak).

 

Természetesen nekünk is van (saját fejlesztésű) hibakezelő és nyomkövető rendszerünk, mely a hibák mellett az új ügyfél igényeket is nyilván tartja, hosszú-hosszú évekre visszamenőleg. Ügyfeleink telefonon, faxon, email-en, web-en keresztül vagy személyesen jelezhetik a problémáikat és kéréseiket (persze, ahogy ez már szokás az interneten át azonnal nyomon is követhetik a bejelentéseik állapotát).

 

A bejelentések megérkezése és rögzülése elindít egy automatikus folyamatot. Minden bejelentő kap egyedi sorszámot, melyről a bejelentő személy is értesítve lesz. Ezután a minőségbiztosítás (vagyis a tesztelők) ellenőrzik a bejelentést. Ha új igény, akkor külön ágon halad tovább az illetékesek felé (akik majd eldöntik a sorsát,… de ez egy újabb történet lenne).

 

Hibabejelentés esetén azonban más a helyzet. Ekkor a tesztelés először megnézi volt-e rá megoldás, és ha igen, akkor mikor. Ha nem, akkor megpróbálják a hibát ők is előidézni (e nélkül szinte lehetetlen kijavítani). Ha nem tudják előidézni, akkor igyekeznek újabb információkat bekérni ezügyben egészen addig, amíg a hiba elő nem áll. Utána a hiba osztályozva lesz (kritikus, komoly, nagy, kicsi, lényegtelen), majd kap egy prioritást (azonnal, amint lehet, következő szervizcsomagnál, ráér, sohanapján kiskedden). Ha a hibáról kiderül, hogy tényleg az, akkor automatikus üzenet a programozónak és a főnökének is egyben (vagyis nekem).

 

Utána eldöntöm (esetleg más vezetőt is bevonva, sok-sok szempontot mérlegelve), hogy melyik programozó és mikorra javítsa ki. Figyelem! Ugye látszik, hogy NEM a programozó dönti el, hanem más mondja meg neki mit, mikorra tegyen! Neki semmi köze hozzá. Jól néznénk ki, ha a programozó kedvétől függne mikorra csináljon meg valmit (már csak azért is, mert ha rajta múlna, örökké csak újat írna). A programozó azért kapja a fizetését, hogy azt tegye, amit mondanak neki. Ennyi. Kegyetlen világ ez (még akkor is, ha néha súlyos bakik csúszhatnak be).

 

A hibajavítást a meghatározott időre vagy alkalomra (pl.: a következő szervizcsomagba) ki kell javítani. Ez alól csak akkor lehet kivétel, ha úgy döntünk, hogy valamit nem javítunk ki (indokolt esetben, apró hibáknál előfordul), vagy valami adminisztratív tévedés volt (ez is előfordult már). A folyamatból az azért látszik, hogy az ember nem javít ki mindent ész nélkül azonnal, hanem amikor annak eljött az ideje. Az az idő lehet 1 óra, 1 nap, 1 hét vagy hónap, vagy kettő, vagy fél év, de akár 1 év is (valójában az ennél régebbi hibák már nem is hibák).

 

Amikor a hiba javítva lett, akkor elindul a maga úján, ami úgyszintén egy másik történet, úgyhogy nem is tartom fel vele a tisztelt olvasót. Helyette inkább levonom a következtetést,… az én következtetésemet.

 

Az ortodox nyílt forráskódot majmolók folyton azt harsogják unos-untalan, hogy ők azért is "jobbak" zárt forráskódú társaiknál, mert sokan vannak ("de nem elegen", ahogy ezt egy klasszikus mondta vala). Szerintem pedig mennyiséggel nem lehet minőséget pótolni. Arról nem is beszélve, hogy a programozók – néhány kivételtől eltekintve – utálnak hibát javítani. Épp ezért nem is lehet rájuk bízni azt, hogy ők döntsenek ezügyben. Ha mégis, akkor az lesz belőle, mint ami a Linux esetén az eredeti hírben is olvasható volt. Úgy vélem, hogy ez a valós felelősség nélküli hobbifejleszés legsúlyosabb hátulütője, ami egy komoly zárt forráskódú helyen, vagy egy olyan nyílt forráskódot támogató vállalatnál mint a Novell vagy a RedHat (ahol zord főnökök és komoly határidők állnak a munkások mögött) NEM fordulhat elő. Vagy nagyon ritkán. Azok a lelkes hobbiprogramozók, akik szabadidejükben a Linux-ot töcskölik naphoszat, de nincs főnökük, azaz nincsenek rászorítva, sőt rákényszerítve arra, hogy valamit időre elvégezzenek, az én szememben nem túl hasznosak. Nyilván ők is másként gondolkodnának erről a hibajavítom-dologról, ha mondjuk levonnák a fizetésük felét és emiatt nem jutna pénz a gyerek iskoláztatására.

 

Úristen! Annyi mondanivalóm van, hogy még oldalakon át tudnám folytatni, de nyugi – nem teszem. Azt hiszem most inkább mindenki döntse el maga, hogy melyik megoldásban, módszerben, vállalatban, programozóban, akármiben bízik meg jobban.

 

Ez itt az én véleményem volt. Ha valaki másként gondolja az az ő baja és nem igazán hat meg vele. Írja meg a véleményét… a saját web-naplójában osz’t jóccakát. Apropó, késő este van, úgyhogy tényleg jóccakát!