Joel Spolsky: Öt Világ

Mert olvasni jó…

 
Bevezető:

"Van egy nagyon fontos dolog, amit egyszer sem említenek a programozásról és szoftverfejlesztésről szóló könyvek, és amiért néha félreértjük egymást. Te szoftverfejlesztő vagy. Én is. Ám nem biztos, hogy ugyanolyan céljaink és követelményeink vannak. Tulajdonképpen a szoftverfejlesztésből több fajta létezik, és mindegyik külön világra más és más szabályok érvényesek. Ha egy UML-ről szóló könyvet olvasol, sehol sem találod meg benne, hogy az alkalmatlan lenne az eszközmeghajtók írásához. Vagy olvashatsz egy olyan cikket, ami azt írja, hogy „A 20MB-s futtatókörnyezet (a .NET-hez) nem lehet akadály, de nem mondja ki a nyílvánvalót: ha csak egy 32KB ROM-al rendelkező csipogóba írsz, akkor igenis van jelentősége! Úgy gondolom, öt különálló világról beszélhetünk, amik néha átfedik egymást, de gyakran nem."

 

A teljes, eredeti cikk (magyarul) itt.

A teljes, eredeti cikk (angolul) itt.

Az elektronikus aláírás-IV.

Akit érdekel az előzmény is, az itt olvashatja.

Hogyan igényelhetünk tanúsítványt?

Regisztrálni kell a saját vagy céges adatainkat hitelesítő szervezet honlapján (pl.: NetLock, MÁV Informatika). Aztán be új nyújtani egy új tanúsítványkérelmet. A kérelem kézhezvétele után a hitelesítő szervezet eMail-t küld, mely leírja a szükséges tennivalókat. Ahogy a levélben leírt lépések megtörténnek (pl. cégjegyzék másolatának vagy postai adategyeztetés benyújtása) a kész, hitelesített tanúsítvány letölthető vagy személyesen is elhozható, majd  azonnal használható.

A kérelemhez természetesen tartozik egy nyilvános (public) és egy magán (private) kulcspár is, hiszen az elektronikus aláírás PKI (Public Key Infrastructure) alapú. A publikus kulcsot maga a tanusítvány tartalmazza, de a privát kulcsot külön lehet és kell elhozni (vagy https segítségével letölteni) . Ez azért fontos, mert a privát kulcs kizárólag az aláíró tulajdonát képezheti és csakis az ő számítógép(ein) létezhet.

Mennyibe kerülnek a tanúsítványok (2003-as NetLock árak)?

Különböző biztonsági szintű és típusú tanúsítványok léteznek. A legolcsóbb tanúsítvány az Expressz (C osztályú), személyes tanúsítvány ára egy évre 4.800 Ft + ÁFA, míg a legdrágább Közjegyzői (A osztályú), SSL szerver tanúsítványé 36.000 Ft + ÁFA. A tesztelési célból 1  hónapig érvényes tanusítvány ingyenes.

 

Próba (akit érdekel…)

 

Ezen a helyen egy NetLock varázsló várja a próbálkozókat és végigvezet mindenkit a teszt-tanusítvány letöltés, illetve Windows-alapú beüzemelés lépésein.

 

Megjegyzés: Tavaly az egyik kollégámmal együtt volt szerencsém megismerkedni és tárgyalni a NetLock ügyvezetőjével. Szimpatikus, értelmes fickó volt. Az ember el se tudja képzelni milyen szigorúak egy ilyen cég létrehozási és üzemeltetési szabályai. Én már tudom (egyszer majd mesélek erről is)…

 

A következő rész: Mi az a tanusítvány visszavonási lista?
 
Folytatjuk…

Egy pici JMS

Ugorjunk egy pict bele a a JMS világába. Én magam nem használom, csak egy kérdés megválaszolása végett foglalkoztam vele picit. Úgy gondoltam talán másoknak is hasznos lehet.

 

A JMS – Java Message System egy Java-szabvány, amely a szükséges üzenetkezelő alaptechnológiát határozza meg.

 

Az üzenetkezelés megvalósítása azonban általában harmadik félre marad, akik az általuk készített köztesszoftverekkel (middleware) valósítják meg a technológia szerinti üzenetkezeléseket. Ilyen szoftver van bőven (zárt és nyílt fortráskódú egyaránt). JMS middleware példák: BEA, IBM, iPlanet, Oracle, Software AG, TIBCO vagy JBoss, objectCube, Joram, OpenJMS.
 
Jelenleg a piacvezető üzenetkezelők: IBM MQ-Series, BEA MessageQ, MSMQ (Microsoft Message Queue).
 
A JMS specifikáció webszolgáltatások segítségével lehetővé teszi az üzenetkezelő rendszerek együttműködését vagy összekapcsolódását (pl.: MSMQ-val), amennyiben azok képesek az említett webszolgáltatások kezelésére. Az ELTE TTK szakértői szerint e téren az irányt a heterogén üzenetkezelő rendszerek együttműködése jelenti. Ennélfogva a JMS és MSMQ rendszerek szabványos módon képesek kommunikálni egymással – már amennyiben ez valahol szükséges.
 
A JMS kétféle működési módot ismer:
  – Point to Point modell: két pont közötti aszinkron üzenetátvitel egy üzenetsor (queue) segítségével. Vagyis
    egy adott sorba továbbított üzenetet legfeljebb egy ügyfélalkalmazás használhat fel (LIFO lista).
  – Publish – Subscribe modell: kiadó-megrendelő architektúra, ahol az egyik fél kibocsátja az adatokat,
    melyeket az összes többi is megkap (ha előfizet rá). Vagyis minden előfizetőhöz külön-külön sor tartozik, az
    üzenetek több példányban jönnek létre, vagyis ahány ügyfél előfizetett az adott témára.
 
Perzisztens üzenetsorok esetén címtárat kell alkalmazni, amelyhez a JNDI – Java Naming and Directory Interface használata szükséges (Megjegyzés: az MSMQ "privat queue" esetén nem, de "public queue" esetén már szintén igényli valamely címtár meglétét, pl.: LDAP, AD, de a .NET System.Messaging névtér a szükséges metódusokat, jellemzőket már eleve tartalmazza).
 
Igény esetén, tranzakciókezelt üzenetvezérléskor pedig egy újabb Java-technológiát,
a JTA – Java Transaction API-t is be lehet vonni a fejlesztésbe.
 
A JMS-ben osztályokban minden üzenettípusra külön "Message" osztály lett létrehozva, pl.: TextMessage, BytesMessage, ObjectMessages és StreamMessages és az üzeneteket az adott típusnak megfelelően kell bennük elhelyezni. Pl.: az XML adatokat a TextMessage-be, stb.
 
A JMS-ben külön figyelőosztály van kiképezve az üzenetek fogadására (MessageListener), amely "callback" függvény (onMessage) meghívásával üzen, ha van olyan adat, amit fogadni lehet a queue-ból. A JMS képes szinkron módon is fogadni adatokat, ekkor a fogadás ideje alatt, illetve a várakozás alatt az alkalmazás nem kapja meg a vezérlést (ez érdekes, mert pl. tudtommal az MSMQ – .NET System.Messaging-ben szinkron fogadásra nincs lehetőség).
 
A JMS jelenleg HTTP protokollon keresztül, SOAP segítségével tud kommunikálni egy másik JMS irányába.

 
A JMS kissé összetett, cserébe viszont az operációs rendszer platformfüggetlenséget adja, habár ez a jelenleg a webszolgáltatás-alapú, integrációs és együttműködési korszakban már majdnem elhanyagolható előny (Megjegyzés: a Microsoft és Sun külön, önálló projektet hozott létre a .NET – J2EE együttműködésre).
 
JMS példák (melyek JTA – tranzakciókezelést nem tartalmaznak):
 
// Point to Point JMS Queue – The Sender – BilboRingQueueSender.java
import javax.jms.*;
import javax.naming.*;

public class BilboRingQueueSender {

    public static void main(String[] args) {
        String ringMessage[] = {"One Ring to rule them all," ,
                                "One Ring to find them," ,
                                "One Ring to bring them all" ,
                                "And in the darkness bind them"};
                               
        QueueConnectionFactory queueConnectionFactory = null;
        Queue ringQueue = null;
                               
        try {                       
            Context jndiContext = new InitialContext();
            queueConnectionFactory = (QueueConnectionFactory)
               jndiContext.lookup("QueueConnectionFactory");
            ringQueue = (Queue) jndiContext.lookup("RingQueue");
        } catch (NamingException nameEx) {System.out.println(
            "Naming Exception: " + nameEx.toString());}
           
        QueueConnection queueConnection = null;
                                
        try {   
            queueConnection=queueConnectionFactory.createQueueConnection();
            QueueSession queueSession=queueConnection.createQueueSession
              (false,Session.AUTO_ACKNOWLEDGE);
            QueueSender queueSender = queueSession.createSender(ringQueue);
            TextMessage textMessage = queueSession.createTextMessage();

            for (int msgCount = 0; msgCount < ringMessage.length; 
                 msgCount++)
            {
                textMessage.setText(ringMessage[msgCount]);
                queueSender.send(textMessage);
                System.out.println(" sending line " + msgCount + " : " +
                   ringMessage[msgCount]);
            }
           
            textMessage.setText("end of message");
            queueSender.send(textMessage);
            System.out.println(" sending last line " + " : " +
               textMessage.getText());           
       
            queueConnection.close();
           
            System.out.println(" ring sender closed");           
           
        } catch (javax.jms.JMSException jmsEx) {System.out.println(
            "JMS Exception: " + jmsEx.toString());
        } finally { if (queueConnection != null)
            {   try
                { queueConnection.close();
                } catch (javax.jms.JMSException jmse) {}
            }
        }
                
    }
}

 
Összefoglalásként elmondható, hogy egy adott üzenetkezelési feladat elvégzésére többféle technológia és eszköz is lehet jó megoldás. Minden esetben a megoldandó feladat, a lehetőségek, a támogatott platform és a megvalósítás várható költsége/ideje dönti el, hogy az adott körülmények között épp melyiket érdemes alkalmazni. Általában az a véleményem, hogy Windows platformon MSMQ-t kell alkalmazni. Máshol pedig azt, ami ott a leg célravezetőbb. Az integrációra pedig egyszerű SOAP hívásokat kell készíteni.
 
Akit érdekelnek a részletek is az olvassa el a "J2EE – Utikalauz Java programozóknak" című könyvet.

 

Ja, és hogy mi az az "üzenet"? Hát… nagyon leegyszerűsítve mondjuk adatok aszinkron továbbítása egy "A" pontból egy "B"-be.

WLan, Wi-Fi, mifi?

A kábelnélküli hálózatok terén régebben én is csak a "WLan" fogalmát ismertem. Sokan, akár divatból viszont állandóan "Wi-Fi"-t emlegetnek. Nosza, öntsünk szőke kólát a pohárba.

 

"A WLan (Wireless Local Area Network) kifejezés gyűjtőnév, amellyel a vezeték nélküli helyi hálózatokat jelöljük. Ezeknek a hálózatoknak méretezhetőknek, megfizethetőknek kell lenniük, és meg kell felelniük bizonyos általánosan elfogadott szabványoknak.

A Wi-Fi azt jelenti, hogy a vezeték nélküli eszköz Wireless Fidelity tanúsítvánnyal van ellátva. Ez garantálja, hogy a WECA (Wireless Ethernet Compatibility Alliance) elvégezte a szükséges hálózati teszteket a termékeken, és úgy találta, hogy azok megfelelnek az előírt szabványoknak, valamint betartják a kompatibilitás elvét.

 

A mai legelterjedtebb WLAN-technológia az IEEE 802.11 szabványra épül, amelyet az IEEE (Institute of Electrical and Electronic Engineers) fogadott el. Ez a rádiós adathálózatok alapja, és ez biztosítja a különböző eszközök kompatibilitását.

 

Az alapszabványnak két változata létezik. Az elterjedtebb a 802.11b jelű műszaki specifikáció, amely a 2,4 GHz-es, szabadon felhasználható frekvencián 11 Mbps sebességű átvitelt tesz lehetővé. A 802.11a specifikációnak megfelelő eszközök az 5 GHz-es sávban biztosítanak adatátvitelt, méghozzá 54 Mbps sebességig, de kisebb hatósugárban.

 

2003 nyarán jelent meg a 802.11g szabvány, amely a 802.11b-hez hasonlóan 2,4 GHz-en működik, így azzal visszafelé kompatibilis. Ez viszont már 54 Mbps sebességre képes, a 802.11a-hoz hasonlóan, viszont annál jóval nagyobb hatókörben, optimális körülmények között akár 550 méteres távolságig. (Az adatátviteli sebesség viszont a távolság növekedésével csökken, az 54 Mbps csak az első útszakaszon, kb. 35 méterig érvényes.) Várhatóan idén ősszel jelennek meg azok az eszközök, amelyek már 100 Mbps feletti sebességet tesznek lehetővé."

 

Eredeti hír itt.

 

És ez még csak a kezdet…

Ingyenes IBM DB2

Ebben a kérdésben a Microsoft SQL Server volt az úttörő az 1998-ban megjelent 7.0 verzióval, pontosabban annak kistestvérével, az MSDE 1.0-val (MSDE = Microsoft Data Engine). Ez ingyenesen ott volt az Office 2000 telepítőben (az Access kiváltására). Aztán jött a Microsoft SQL Server 2000 és az MSDE 2.0 (ez is rajta volt ingyen az újabb Office CD-n), most pedig itt a Microsoft SQL Server 2005 Express Edition.

 

Aztán jött az Oracle XE, most pedig az IBM DB2 ingyenes változata. 

 

"Az IBM tegnap kiadta a DB2 adatbáziskezelő ingyenes változatát, amelyet elsősorban szoftverfejlesztőknek szán. A vállalat célja, hogy közvetlen vetélytársat állítson a nyílt forrású adatbázisoknak, mint amilyen a MySQL vagy a PostgreSQL, illetve a Microsoft és az Oracle hasonló ingyenes megoldásaiknak, amelyek szintén a fejlesztők elcsábítására hivatottak."

 

Eredeti hír itt.

 

Ők azok az adatbázis-kezelő gyártók, akik a piac közel 100%-át uralják. Részemről rendkívül hasznosnak tartom ezt a kezdeményezést (ellentétben a sok openmatyival). Ugyanis akinek nincs pénze vidáman elvan 3-5 évig ezekkel a rendszerekkel, sőt. Aztán amikor kinövik (mert nő az adat és remélhetőleg a cég bevétele is), akkor rögtön átállhatnak az ingyenes változatok nagy testvéreire – persze jó pénzért (amiért viszont teljes támogatás jár). A nagyobb fejlesztő cégek többsége (mi is) ezen három rendszer valamelyikét alkalmazza. Egyrészt azért, mert már 10-15 éve megvannak és folyamatosan fejlődnek, másrészt pedig nekik van a legnagyobb és legjobb támogatottságuk, elterjedtségük és a  Microsoft, Oracle, IBM őrületes mennyiségű pénzt öl bele az adatbázisok termékfejlesztésbe.

 

Innováció nincs pénz nélkül, pénz pedig nincs üzlet nélkül. Ilyen egyszerű. Hobbiprogramozásból és lelkesedésből soha sem lehet eljutni idáig, hiszen ezek a dolgok nem ellensúlyozzák a több milliárd befektetett dollárt, amit a nagyok magukra áldoznak. Ggondoljunk csak arra, hogy mindegyikbe be van építve egy teljes OLAP elemző rendszer szerver oldali kezelése, amit rengeteg ember több évig és sok-sok pénzt beleölve fejlesztett ki.

 

Nekem azonban mégis a cikkben lévő utolsó rész tetszik a legjobban.

 

"Az adatbáziskezelő beszerzési és üzemeltetési költségei azonban gyakran köszönőviszonyban sincsenek egymással, az akvizíció a birtoklási összköltségnek gyakran a 10 százalékát sem teszi ki. A szervezetek sokszor hajlamosak megfeledkezni erről és azt a megoldást választják, amelynek megszerzése egyszerűbb, ezért később jóval magasabb üzemeltetési költséggel fizetnek."

 

Ez itt a lényeg. Tapasztalatból mondom, soha nem az a fontos, hogy egy adatbázis-kezelő (vagy operációs rendszer) pillanatnyilag mennyibe kerül! A kutya ugyanis a TCO – teljes üzemeltetési költségek mögött van elásva (oktatási-betanítási költség, szakemberek képzése, automatizáltság, rendelkezésre állás támogatása, szoftvertámogatás, segítségnyújtás, hibaelhárítás, teljesítményhangolás, stb).

 

Egyébként meg… nekem teljesen mindegy, hogy ki mit használ. Tőlem lehet MySQL, PostgreSQL, Firebird, akármi. Én nem ezeket használom. Mindent a maga helyén a maga idejében.

Van rajta sapka, nincs rajta sapka…

Azt monják ezek a bürokratikus EU-köcsögök, meg a dicsőséges szoftverkommunisták, hogy "Nem elég a Windows forrásának megnyitása". Igaz, hogy a birodalmi gépezet nem egy vasárnapi cserkészbanda, de azért ez, amit velük művelnek (a Media Player nélküli Windows-ról nem is beszélve)  már túlzás.

 

Óóóó, hogy én mennyire rühellem az idiótákat…

 

Eredeti hír itt.

Torvalds: a Linux nem vált GPLv3-ra

Kiborult a bili GPL-ügyben. Olyan régóta megy a herce-hurca, hogy az ember már csak nagyikat ásít, amikor ilyen híreket olvas. Ez is csak olyan, mint a többi szabványosítási testület tesze-toszasága. Nem véletlen, hogy sokan inkább saját "szabványt" a hivatalos helyett. Erre jó példa volt a Microsoft korábban (mára már azért jócskán visszafogták magukat). A tötymörgés nem hoz pénzt, márpedig pénz nélkül…

 

"A Linux kernel (rendszermag) levelezőlistáján folyó vitába bekapcsolódva Linus Torvalds kategorikusan kijelentette, hogy egyáltalán nem tetszik neki a készülőben lévő General Public License 3-as változata, és a Linux nem fog az új licencre átállni."

 

Részletek itt.

 

Amíg ezek vitatkoznak, addig érdemes elgondolkodni az utolsó mondaton, íme:

 

"Bár elemzők a GPLv3-at sokkal fejlettebbnek, jobbnak tartják a már 15 éves GPLv2-nél, a DRM kérdése törést hozhat létre a nyílt szoftverek között, hiszen az ipar sem fog energiát fektetni olyan szoftverek használatában és fejlesztésébe, amely üzleti lehetőségeit csorbítja." 

 

Még szép!

Joel Spolsky: Lord Palmerston és a programozás

Korábban ezen a helyen már említettem, hogy ki az a Joel Spolsky. A lenti cikket (is) javaslom elolvasásra.

 

Bevezető:

"Valaha az IBM PC-k programozását az ember egyetlen Peter Norton-könyv elolvasásával kimerítően megismerhette. Az elmúlt 20 évben pedig egyre újabb és újabb, a PC-programozást könnyítő és segítő absztrakciók kerültek ki szorgos programozók kezei alól. A szivárgó absztrakciók törvénye következtében azonban a programozást könnyíteni hivatott absztrakciók szaporodásával párhuzamosan a programozói hivatáshoz (pláne egy jó szakembernek) szükséges tudásanyag is egyre csak nő. Egyetlen programozási nyelv kiismerése (annak minden zegzugával együtt) is évekbe telik. Sok fürge eszű tizenéves persze egy hét alatt meg tudja tanulni a Delphi-t, a rákövetkezo héten a Python-t, ezek után újabb egyhetes elfoglaltságnak beférhet a Perl is, és ettől tapasztalt kódiparosnak hiszik magukat, miközben halványlila fogalmuk sincs a tudásuk tényleges hiányosságairól."

 

A teljes, eredeti cikk (magyarul) itt.

A teljes, eredeti cikk (angolul) itt. 

TOP-lista

Sokszor lehetett már olvasni a Netcraft nevű vállalkozás webszerverekkel kapcsolatos felmérési eredményeiről, melyek mindig az Apache webszervert hozzák ki "győztesnek". Nos, ami a számosságot illeti igazuk van. Sajnos azonban én ezeket a felmérési eredményeket meglehetősen súlytalannak tartom. Sok lúd disznót győz? Aligha, úgyhogy javaslom vizsgáljuk meg más szemszögből is a dolgokat.

 

Kevesen tudjék, hogy a Netcraft mellett léteznek más, hasznosabb adatok is, pl. amit a Port80 nevű csapat szolgáltat. Ők azok, akik 2003 óta készítenek felméréseket de nem az összes megtalált, hanem csakis kizárólag a Fortune 1000  listájban szereplő legnagyobb vállalatok alapján.

 

E szerint az 1000 legnagyobb vállalatok közül a web és alkalmazás szerverek aránya a következő:

 

Webszerverek:

  – Microsoft IIS   53.7%

  – Apache           22.7%

  – Netscape        10.8%

  – Egyéb             12.8%

 

Eredeti adatok itt.

 

Alkalmazásszerverek:

  – Microsoft (ASP., ASP.NET)                         43.6%

  – Java (J2EE, JSP, WebLogic, WebSphere)  12.2%

  – PHP                                                               5.2%

  – Egyéb                                                            6.1%

 

Eredeti adatok itt.

 

A megadott webhelyen részletesen leírják a felmérés körülményeit, illetve megtekinthető az is, hogy melyik nagyválallat milyen web vagy alkalmazásszervert használ. 

 

A Netcraft és Port80 statisztikák eltéréseinek oka abban rejlik, hogy a Netcraft az eredményeit nem súlyozza, azaz minden webkiszolgálót egyenértékűnek tekint a legforgalmasabb weblapok szervereivel. Ezen kívül a Netcraft például az ún. parkolt, tényleges használaton kívüli domain-nevek tízezreit is beszámítja statisztikáiba, miközben azok legtöbbje mögött ugyanaz a néhány webszerver rejtőzik.

 

Ráadásul nagyon nem mindegy, hogy egy webszervert a Kaland Bt. vagy mondjuk a Coca-Cola Company üzemeltet. Nem egy súlycsoport. Ezzel természetesen nem azt akartam mondani, hogy az egyik vagy másik jobb, mivel ez a kijelentés értelmetlen. Csak arra szerettem volna utalni, hogy a Netcraft felmérése alaposan megvezeti a naív, de lelkes emberek többségét.

Honnan jöttem, merre tartok-II.

Nemrégiben itt írtam arról, hogy kezdődött a pályám. 

 

A folytatás már elég unalmasan alakult, ugyanis munkahelyet váltottam. A váltás következménye az lett, hogy főmunkaidőben, napi 9-12 órában végre szoftverfejlesztéssel foglalkozhattam. Hurrá! Igaz nem írhattam operációs rendszert, adatbázis-kezelőt vagy ilyesféle izgalmas dolgokat, ugyanis ezért nem fizetnek egy kanyi vasat se. Helyette írhattam unalmas ügyviteli szoftvereket, kevésbé unalmas adatbázis-menedzsment rendszereket, meg minden ilyesmit.

 

A programozói munka Dx486-os PC-ken folyt, 4 MB RAM-al, merevlemez nélkül. Egyetlen Novell Netware szerverünk volt, rajta egyetlen egy Windows 3.1-el. Hálózaton keresztül jelentkeztünk rá és az összes programozó azon az egy szerveren meg Windows-on dolgozott. Ugye nem kell ecsetelnem a helyzet komikumát. Mégis, arra jó volt, hogy az ember tapasztalatot szerezzen, fejlődjön és némi pénzt is keressen. A cég fejlődésnek indult, több rendszerbevezetésünk is volt, ami megteremtette az alapot a bővítésre. Ami alatt természetesen létszám és hardvereszközöket kell érteni. Mindenkinek lett saját gépe, 8 MB RAM-al és önálló merevlemezzel, melynek a DOS-os parancssorába boldogan gépeltem be minden regge azt, hogy "win" (fiatalabbak kedvéért a "win" a Windows 3.1 indítását jelentette). A programozási környezet egy igen ritka, 4GL-es, amerikai cucc volt, mely akkor, 1994-ben már évek óta ugyanazt tudta, mint a rákövetkező évben megjelenő Delphi 1.0 vagy Visual Basic 3.0 (az eszköz nevét most inkább nem említem). A mai nap is ennek a továbbfejlesztett változatával dolgozunk.

 

Természetesen otthon saját számítógépem is volt, illtve van is. Végigjártam velük a teljes evolúciós folyamatot a PC-XT-től (x086-os processzor, 640 KB RAM, 20 MB merevlemez) egészen a napjainkban megszokott gépig (kétmagos Pentium IV.-es processzor, 1.5 GB RAM, 160 GB merevlemez, stb). Később, a munkahelyen amikor jobban ment a szekér, a főnököm elsőként engem kért fel arra, hogy egy új projektben vegyek magam mellé három programozó kollégát és fogjam össze a programozói csapatot. Ez amúgy egy böszme nagy termelésirányítási rendszer volt, melyet 1 éven át kódoltunk. Nekem kellett a munkát kiosztani, beszedni, a programot összeépíteni (build), a problémákat megoldani, segíteni a többieket, dokumentálni és felelősséget vállalni a tetteinkért.

 

Ekkortájt az egyik kiváló kollégám már készített egy olyan osztálykönyvtárat (az általunk alkalmazott 4GL-es fejlesztői környezetben megírva), amely rengeteg segítséget nyújtott az alkalmazásfejlesztésben. Biztosította az egységes programműködést, a szabványos felhasználói felületet, a biztonságos adatbázis-kezelést és számos mást is, pl. jogosultság-kezelést. A mai napig használjuk, csak annak már egy jóval fejlettebb változatát. Ami egyébként annyira hatékony, hogy vele egy nap alatt, egy programozó 6-10 egyszerű karbantartó funkciót (ablakot, menüt) tud elkészíteni, listával együtt.

 

Aki hozzám hasonlóan a magánszektorban dolgozik az tudja, hogy vannak jobb és rosszabb időszakok. A folyamatos harc az új projektekért (értsd: pénzért) rengeteg energiát és erőforrást emészt fel, valamint roppant költséges móka. Hónapról hónapra legalább 50 mFt-ot kell bevételként összehoznunk ahhoz, hogy fenntartsuk magunkat, no meg az összes dolgozót a kereskedőtől a hardveresen át egészen az adminisztratív személyzetig. Ez pedig maga a rettenet. A szoftverért az ügyfelek egyre inkább nem akarnak fizetni, a szolgáltatásért még csak-csak, de már azért is egyre kevesebbet. Elvárják az ingyen munkát és ingyen szolgáltatást. Sarkítva írtam ugyan, de majdnem ez az igazság.

 

Folytatjuk…

Innen-onnan Linux-VI.

Az utolsó téma következik, de akit érdekel az előzmény is, az itt olvashatja.
 
X Window System (vagy röviden: "X")

Így hívják a Unix/Linux/BSD, stb. rendszerek grafikus kezelőrendszerét. Valamikor 1984 tájékán egy "Athena" nevű projekt keretében jött létre, 1988-tól az X konzorcium felügyeli. A specifikációja szabadon hozzáférhető, így vannak ingyenes megvalósításai, pl.: XFree86 (A Linux, de a korábban a jól ismert IBM-OS/2 is használta). Az XFree86 fejlődési lassúsága miatt néhány Linux disztribúció átváltott az XFree86-ról az "X.org"-ra (ami ugyanúgy X, csak épp mások fejlesztik).
 
Az X semmi mást nem csinál, mint alacsonyszinten kezeli a képernyő, billentyű, egér és egyéb hasonló eszközöket. Tehát önmaga nem egy felhasználói felület, nincs ablakkezelője, menükezelője, stb. "csak" hardveresztközöket vezényel. Ezt pedig klasszikus kliens/szerver architektúrában teszi. Még akkor is, ha csak egy számítógépről van szó, hiszen ezesetben a kliens és a szerver ugyanazon a gépen van.
 
Minden ablakkezelő program közvetett módon az adott X kliensen keresztül fér hozzá az általa igényelt hardvereszközökhöz. Az ablakkezelő programok minden hardveren ugyanúgy működnek, a műszaki különbözőségeket az X (pontosabban annak a nyílt forráskódú XFree86 vagy éppen X.org szerinti megfelelője) fedi el. Az X-et szövegfájl segítségével lehet paraméterezni, de ezt még az ellenségemnek se kívánnám. Létezik egy parancssoros program is, amely kicsit egyszerűsíti a dolgot. Sőt, hovatovább valami irgalmatlan IQ-t igénylő grafikus alapfelülete is elérhető, használtam is tán egyszer, de többnyire inkább a szomszéd kisgyerekek riogatására.
 
Az X-nek a C-nyelvű programozói könyvtárát "XLib"-nek hívják.
 
Ablakkezelők
Az ablakkezelők az X-nek a kliens-oldali felhasználói megvalósítása. Ablak mozgatás, átméretezés, minimalizálás, maximalizálás, stb. Mind-mind olyan dolgok, melyeket az X nem kezel. Egy ablakkezelő további feladata, hogy segédkezzen a programok elindításában is. Mivel az ablakkezelő kliensprogram, így szabadon cserélgethető. Az XLib-el, habár lehet, de nagyon nehézkes és fáradságos a grafikus műveletek végrehajtása.
 
Léteznek az XLib-re ráépülő, úgynevezett "Widget"-könyvtárak (közismertebb nevén vezérlőobjektumok programozói könyvtára). A widget-ek felelnek minden elem megrajzolásáért, kezeléséért, ezért a programok viselkedése nagyban függ a választott widget-könyvtártól. Az első ilyen egy Athena nevű volt, majd később, a 90-es évek elejéig az Open Software Foundation "Motif" csomagját használták. Manapság inkább a"Gtk" (Gimp Toolkit) és a "Qt" grafikus programkönyvtárak vannak elterjedőben.
 
A KDE a "Qt"-t, a GNOME pedig a "Gtk" grafikus könyvtárakat használja.
 
Asztali környezet
A rendszer kialakításakor elsősorban a rugalmasság és a felhasználói szabadság volt a cél, ellentétben a MacOS és Windows megkötöttségével, illetve zártságával. Ez a szabadság azonban oda vezetett, hogy…
 – a kliensprogram írója határozza meg a widget-könyvtár típusát (ami sok elétérést okoz a különböző kezelési
   módok miatt),
 – a widget könyvtárak általában dinamikusan linkelődnek a programokhoz, azonban ha a az egy gépen lévő
   kliensprogramok egymástól eltérőeket használnak, akkor az plusz memóriát igényel,
 – a különböző ablakkezelők koncepciója eltérő,
 – az egész felület nem áll össze egy egséges egépsszé, nem lehet egyben konfigurálni a kinézetét, kezelését.

A fent említett esetek miatt jöttek létre az asztali környezetek, melyek szolgáltatásokat és módszertanokat is tartalmaznak. Ezek közül a legnépszerűbb a KDE (K Desktop Environment), a CDE (Common Desktop Environment) és a GNOME (GNU Network Object Model Environment). Segítségükkel a fentebb említett problémák valamelyest enyhíthetők.

Fejlesztés KDE környezetben

A KDE 1996-ban született (szerzője Mathias Ettrich). A csomag tartalmaz egy "kwm" nevű ablakkezelőt, a "Qt" grafikus könyvtárat, valamint további grafikus komponenseket (pl.: klauncher, konqueror, vezérlőpult, stb). A vezérlőelemeket a KDE és Qt könyvtárak C++ -ban valósítják meg. Az objektum oreintált módszerek miatt lehetőség van saját osztályok kialakítására is. Az eseményekre történő reagálást "Qt szignál-szlotnak" hívják. Ez lehet a visszahívásos (callback) módszer egyik szinonímája.

 

Tulajdonképen minden ablaktípusra, vezérlőelemre (widget) létezik egy saját osztály. A forrásba ezeket használva állíthatjuk össze a képernyőket. A képernyőn bekövetkezett eseményekre (billentyűleütés, egérmozgás, stb) a szignál-szlot függvényeken keresztül  avatkozhatunk be. Minden objektum egy "QObject" illetve egy ‘QWidget" őstől származik, így pl. egy szöveges kontrol (label) közvetlen őse a "QLabel" osztály, aminek a "QWidget", aminek pedig a "QObject" a szülője, stb.

 

Példa egy egyszerű, ablakon belüli adatmező-szöveg megjelenítésre:

 

  int main(int argc, char* argv[])
  {
    KApplication khello(argc,argv, "khello");
    KLineEdit* helloedit=new KLineEdit();
    QString hellostring("Szia világ!");

    helloedit->setText(hellostring);
    helloedit->setReadOnly(true);
    helloedit->setAlignment(Qt::AlignCenter);
    helloedit->show();

    khello.setMainWindow(helloedit);
    return khello.exec();
  }

 

Mint említettem egy adott eseményre (nyomógomb megnyomás, stb) az úgynevezett szignál-szlot eseménykezelő modell hivatott reagálni. A szignál maga az esemény, a szlot pedig az a függvény, amely meghívódik egy esemény hatására. Minden egyes ilyen szlotot hozzá kell kapcsolni egy szignálhoz, melyre a "QObject::connect()"  metódus szolgál (nagyon hasonló lehet a .NET eseményeknél szokásos "Esemeny++=UjEsemeny()"-szerű  feliratkozáshoz). A leválasztást a "QObject::disconnect()" végzi el.

 

A "Qt" sok olyan új programnyelvi elemet vezetett be (pl.: a "slot" kulcsszó), amely a C++ -ban nem is létezik, ezért a végső fordítás előtt egy Meta Object Compiler-en (MOC) keresztül kell engedni magát a forrást. Ez a MOC hozza végső, C++ fordító által értelmezhető formára a dolgainkat (természetesen a végső, ily módon, generált forrásba nem célszerű belenyúlni, mert a következő MOC futattás és generálás a korábbit felülírja). A KDE-ben (mint, ahogy a Windowsban) is léteznek előre gyártott dialógus ablakok (fájl nyitás, betűtípus, színválasztó, üzenet ablak, stb). Mindegyik egy-egy C++ osztály, amelyből leszármaztathatunk, és szükség esetén sajátot is készíthetünk. Az üzenetablakoknál (MessageBox) minden egyes üzenet típushoz (kérdés, figyelmeztetés, információ, stb) külön-külön metódushívás tartozik.

 

Példa az üzenetablak hívásokra:

 

  If (KMessageBox::warningContinueCancel(0, "Biztos vagy benne?", "Fejléc",
      "Help") == KMessageBox::Cancel)…

   vagy

 

  KMessageBox::error(0, "Gáz van hé!", "Fejléc");

 

A KDE-ben is ismert az SDI és MDI jellegű felső szintű ablakok fogalma, valamint a dialógus ablak is. Más jellegű, felső szintű objektumról nem olvastam. Az SDI/MDI ablakkezelés meglehetősen összetett, ezért ebből most nem idéznék.

 

Fejlesztés GNOME környezetben

A GNOME 1997-ben született (projekt alapítók: Miguel de Icaza, Federico Mena). A csomag korábban egy "Sawfish", a 2.0 verziótól pedig a "Metacity"-t nevű nevű ablakkezelőt használja. Grafikus alapkönyvtárként a "Gtk" -ra építkezik. A KDE-től eltérően az alacsonyszintű "XLib" (X Windows System) környezet mellett egy arra ráépülő "GLib" könyvtárat is használnak (a GLib az XLib-nek egy becsomagolt "wrapper" változata). A GNOME könyvtárak C-ben íródtak. Most sem fogok példákat írni, mert hát jó magam eléggé megrémültem amikor megláttam a mintaforrásokat. Lényeg az, hogy a KDE-hez képest teljesen más módon kell mindent csinálni. A felhasználói felületet és a programozási lehetőségeket figyelembe véve én inkább a KDE-t részesítem előnyben (véleményemmel szerencsére nem vagyok teljesen egyedül, igaz, hogy mindenki más-más dologgal elégedetlen).

No, hát röviden ennyi. Forrásként a "Linux programozás" c. könyv szolgált. Aki szeretne többet tudni, az olvassa el. Kiváló könyv, ajánlom mindenkinek.

 

Vége.

Adakozás

Billibá az egyik legnagyobb adakozó. Legalább jó helyre megy a pénz(ünk) egy része.

 

"Nagy-Britannia, Nigéria és Bill Gates milliárdos pénteken, Davosban bejelentették, hogy nagy méretű programot léptetnek életbe a tuberkolózis leküzdésére. A program célja 14 millió emberélet megmentése az elkövetkező évtizedben. 56 milliárd dollárt szánnak erre a célra – jelenti az AFP, hozzáfűzve: ez az összeg a háromszorosa a 400 szervezetet tömörítő Harc a tuberkolózis ellen nevű szervezet várható bevételeinek…"

 

Eredeti hír itt.

Rekordbevétel

Sajnos nem az én cégemnél (és nem is nálam személyesen), annál inkább a birodalmi pénztárosoknál. Évek óta megjósolták a Microsoft hanyatlását, aztán évek óta növekszik és csak növekszik…

Persze az is lehet, hogy az ellenfelek úgy próbálják elpusztítani, hogy előtte jól felhízlalják? Hátha szétdurran, mint a túlnyomásos béka a pocsolyában. Nem mondom, ez is egy stratégia, bár nem biztos, hogy beválik.

 

"A világ legnagyobb számítógépprogram-gyártója, az amerikai Microsoft pénteken 11,837 milliárd dolláros forgalmat jelentett az üzleti éve decemberrel zárult második negyedéről. Ez 9 százalékkal több az egy évvel korábbi 10,818 milliárdnál, és a legnagyobb negyedéves bevétel a cég történetében, mindazonáltal elmaradt mind a cég saját, mind az elemzők előrejelzéseitől, az új játékkonzol vártnál lassúbb piaci indulása miatt. Ezt a cégnél nem kereslethiánnyal, hanem éppen fordítva, a kereslettől kezdetben elmaradt gyártókapacitással indokolták…"

 

Eredeti hír itt.

Az elektronikus aláírás-III.

Akit érdekel az előzmény is, az itt olvashatja. 

 

Egy kis unalmas emlékeztető.

 

1. Sértetlenség: annak biztosítása, hogy a küldött és a kapott üzenetet egy külső támadó ne változtathassa meg.

2. Hitelesség: a kommunikációban résztvevo felek személyazonosságának egyértelmű bizonyítása. Ide sorolható a hozzáférés védelem, jogosultság vizsgálata is. Általában jelszavakat menedzselo, ellenőrző és hozzáférési jogosultságot kezelő részekből áll.

3. Letagadhatatlanság: annak biztosítása, hogy a küldő az eredeti üzenetet a későbbiek során ne cserélhesse ki egy másikra.

4. Titkosság (de ez opcionális): az adatok láthatóságának védelme az illetéktelen felhasználókkal szemben.

A klasszikus értelemben vett elektronikus aláírást az 1-3 pontok valósítják meg. A 4. lépés választható, de nem fontos része az elektronikus aláírásnak (azaz mégis, mert a hash-kivonat az titkosítva van, de erről majd később…).

 

Na és akkor most jön a lényeg…

 

Az elektronikus tanúsítvány

A tanúsítvány olyan elektronikus, szabványos adatszerkezet (X.509), amely tartalmazza a tanúsítványt kibocsátó (hitelesítés szolgáltató) valamint a tanúsítvány tulajdonos adatait, a tanúsítvány tulajdonos nyilvános kulcsát, valamint a kibocsátónak a tanúsítványt hitelesítő elektronikus aláírását. A tanúsítvány olyan igazolás, amely igazolja a benne foglalt adatok valódiságát, valamint a tanúsítvány tulajdonosának illetve a tanúsítvány tulajdonos publikus kulcsának összetartozását.

 

Az X.509-es elektronikus tanusítvány szerkezete:

Név
– kötelező adat
– hierarchikus szerkezetű

Kulcs azonositó (ID)

Publikus kulcs

CA – Certificate Authority (hitelesítő szervezet) saját információ (pl.: Matáv, NetLock, VeriSign, stb.)

Érvényesség időtartama (egy dátum)

Aláírás
– Csak egy!

 

Mit garantálhat egy X.509 tanúsítvány?

Hát azt, hogy kogy köze van a névnek és a kulcsnak egymáshoz, de…
– Nem biztos, hogy ellenőrzik, hogy alá is tud írni a kliens
– Nem garantálhatják, hogy másnak nincs birtokában a kulcs
– Nem biztos, hogy megfelelően ellenőrzik a névhasználat jogosságát

 

A következő rész: Hogyan igényelhetünk tanusítványt és mennyibe kerül?

 

Folytatjuk…

Linux kernel kódot írni C++ -ban véresen hülye dolog…

Azt mondják az okosok, hogy "Linux kernel kódot írni C++ -ban véresen hülye dolog…"

 

1.
Pár gondolat erről:
 • Miért kellene?
 • Amikor a Linux elkezdődött, nem volt hatékony "gcc" C++ fordító és néhányan azzal érvelnek,
   hogy ma sincs.
 • Sokkal több C programozó van, mint C++ -os.
 • A C++, a C-vel ellentétben nem kompatibilis 100%-ban visszafelé.
 • A C++ szabványosítók nem eléggé elkötelezettek a 100%-ig történő visszafelé kompatibilitás ügyében.
 • A kernelt újraírni C++ -ban hatalmas mennyiségű munkával járna és óriási erőfeszítést követelne.
 • A C++ nagyon összetett nyelv, de nem olyan érett, mint a C.
 • Amíg Linus a kernel karbantartója, csak ő szólíthatna fel erre, neki viszont az alábbi véleménye van:
     – 1992-ben már egyszer megpróbáltuk átírni.
     – Szívás volt, mert kernel kódot írni C++ -ban egy véresen hülye dolog.
     – A tény az, hogy a C++ fordítók megbízhatatlanok.
     – A C++ kivételkezelése alapvetően tönkretesz mindent – különösen a kernelt.
     – Bármely fordító vagy nyelv, amely elrejt dolgokat a memóriafoglalásról, nem jó választás a kernelhez.
  • Stb.

Eredeti írás itt.

 

2.
A reykjaviki egyetem hallgatói azért implementáltak egy kernelszintű Linux "run-time support" lehetőséget, viszont Linus Torvalds ezzel nem igazán akar foglalkozni és nem is támogatja (lásd fentebb az idézetet tőle).

Eredeti írás itt és itt.
 

3.
Mások is nagyon sokat foglalkoztak már ezzel a kérdéssel.

• A Linuxot C++ -ra konvertálni abszurd gondolat. Ahhoz, hogy a C++ erőssége igazán ki legyen használva,
  a kernelt belülről teljesen újra kellene tervezni.
  Eredeti írás itt.
• Writing a Kernel in C
  Eredeti írás itt.

 

4.
A Sun is próbálkozott valamivel, aminek a neve: SpringOS
Eredeti írás itt.

 

Ezek már pár évvel ezelőtti történtek. Vajon változott-e azóta valami?