Munka

Egy évvel később …

Eltelt egy év azóta, hogy utoljára írtam erre a Blogra (több mint egy év) … azóta olyan rengeteg sok minden történt, hogy felsorolni hosszú lenne, emlékezni se nagyon emlékszem mindenre … de talán a főbb lépések még megmaradtak … persze kérdés, ki az akit ez érdekel (főképp ilyen vidám bevezető után), na de ez mégiscsak az én oldalam, aki ide téved vagy bot, vagy érdekli mi van velem 🙂

Mikor utoljára jelentkeztem, éppen a Twisted Tribe vége volt, a céget úgymond megszüntették. Azóta a Nadirim is leállt és bezárták végleg. Hát … változás nincs, jelenleg a Duodecadnál vagyok (ugyancsak a Docler cégcsoport tagja) és éppen véget ér … a cég külföldre költözik, én pedig nem akarok menni, így megint munkát keresek / kerestem, ami nem is olyan egyszerű dolog …

Mivel sajnos teszt írásból valódi analfabéta vagyok, havi 150.000 nettóért meg nem akartam elmenni dolgozni, így sajnos jóval nehezebb volt találni valamit, mint gondoltam, persze volt némi zűr itt a Duodecadnál is … na de lépjünk tovább …

Sajnos azt látom, hogy kis hazánkban ma már legfontosabb az, hogy valaki nagyon olcsón dolgozzon. Az mindegy, hogy milyen minőségben, sőt! Jobb ha gyengében, mert akkor a főnökről sem derül ki, hogy csak egy kutyaütő … de hát így szép ez a dolog.

BalatonNa de mi  történt a két idő között? Huh … talán a legfontosabb, hogy megházasodom! hamarosan, de hát hogy a paparazzik elkerüljenek a dátumot nem áll módomban közölni 😉 immár több éve élünk a menyasszonyommal boldogan, úgyhogy eljött az ideje meglépni ezt a lépést … a hétvégén esküvő kiállítás … már alig várom! 😀

Emellett az Airsoft az, ami teljesen kitölti a szabadidőmet. Van hogy fent, van hogy lent, de azért megy, haladunk, egyre komolyodik a dolog, remélem még jó ideig így is marad …

Na és persze elkezdtem sportolni … idézőjelbe kellene tenni 🙂 Szóval futottam, meg fekvőtámaszoztam és hasonlók, hogy legyen kondim, majd jött a karácsony és minden elszállt 🙂 csak én nem 🙂

Voltunk persze nyaralni is, kétszer is. Egyszer a Balatonon a többiekkel, majd utána az én kedvesemmel azon a helyen, amit a legjobban szeretek: Krk, Njivice. Nagyon jó két hét volt, remélem idén sikerül megismételni.Krk

Macska fronton is van változás, azaz lett +1 … egy kandúr, így most 4 macska van otthon, 2 lány és 2 fiú … aranyosak … csak hát még kérdés Berni velem vagy Csúcsival (az új macska) fog-e “összebútorozni” 🙂 mivel nagyon anyás a cica, engem meg csak megtűr a házban.

Hát nagyon nagy vonalakban ennyi, biztos rengeteg dolgot kihagytam, de már elfelejtettem, épp nem jut eszembe, vagy jobb is nem beszélni róla.

Úgyhogy mára ennyi, remélem lesz mihamarabb valami mondandóm itt is 🙂

XML-RPC

 

Következő bejegyzésemben egy számomra érdekesnek tartott témáról szeretnék némi felvilágosítást adni. Ez nem Airsoft lesz, hanem programozás, amit lehet sokan nem szeretnek, ettől függetlenül remélem érdekes és tanulságos lesz azoknak, akik ezzel foglalkoznak.

A mai téma az XML-RPC lesz, ami 2 rövidítés, méghozzá az Extensible Markup Language és a Remote Procedure Call. Hogy mik is ezek, hát az jó kérdés, megpróbálok külön külön választ adni és egyben, hogy mi is azaz XML-RPC szerver és hogyan is kellene csinálni egyet. Mindezt C# ban, mert az könnyű és nyugos, ráadásul kész van egy nap alatt.

 

Kezdjük az XML el

Az XML-t alapvetően arra találták ki, hogy egy olyan fájlt hozzanak létre, amivel bármikor bármit le tudnak írni. Képes bármilyen adathalmaz reprezentálására, úgy, hogy a programoknak nem szükséges ismerniük a pontos felépítést, mindössze az XML szabályoknak kell megfelelnie.

Rengeteg felhasználási helye van az XML nek és valószínűleg már mindenki találkozott vele valamilyen programnál, amit használt, ha máshol nem akkor a windowsban, ami maga is rengeteg XML fájlt használ adatok és beállítások tárolására.

Egy egyszerű XML fájl:

<?xml version="1.0" encoding="iso-8859-1"?>
<XmlTest>
   <XmlValue name="nameofvalue" value="valueofvalue">
       <![CDATA[Special text]]>
   </XmlValue>
</XmlTest>

Az XML nagy előnye, hogy a saját szabályai alapján valóban bármilyen adat struktúrát le lehet benne írni, ezáltal egy teljesen általános adat tároló eszközt kapunk, amihez ma már rengeteg XML olvasó beszerezhető, illetve nem tart kifejezetten sokáig egy sajátot írni, főleg, ha a szabályok nagy részétől eltekintünk, ami legtöbbször könnyedén elengedhető egy saját project esetén.

 

Az RPC

Hát az RPC ről sokat nem is lehet mondani, hisz ez egy … talán fogalom. A lényege, hogy egy számítógépen valami módon kiadunk egy utasítást, ami végrehajtódik egy távoli számítógépen. Természetesen mielőtt bárki összeesküvés elméleteket gyártana, itt nem arról van szó, hogy fogom a Windows Notepadet és valami speciálsi billentyű kombinációval egyből lehet valaki más gépét irányítani.

Az RPC utasításokat a szerveren regisztrálják, a hozzá szükséges kliensen pedig csak ezeket lehet felhívni. Persze hiba mindig lehet a gépezetben, de feltételezzük, hogy nincs 🙂

 

XML-RPC?

Na és akkor hogy is jön ki a kettőből az XML-RPC? Egyszerűen. Itt a kettő a kommunikáció mikéntjét és a felhasználást jelöli, azaz XML ben utasítjuk a szervert a távoli eljárások felhívására. Az XML ről ugye már megbeszéltük, hogy bármilyen adat struktúrát le tud írni, így egy tetszőleges utasítást és annak paramétereit is le tudjuk írni, illetve az eljárás visszatérési értékét.

Ehhez persze az XML-RPC nek kell egy szabvány, ami megmondja, hogy az XML nek milyen formátumúnak kell lennie, hogy azt minden kliens és minden szerver valóban megértse. Ez a szabvány természetesen csak útmutatás, nem kötelező etz használni, csak akkor már nem beszélhetünk szabványos XML-RPC szerverről. Hogy ez miért fontos, mindenki döntse el magában.

Megjegyzem, hogy a WordPress is képes XML-RPC kommunikációra, ami lehetővé teszi saját WordPress szerkesztők írását (mint a Windows Live Writer), ami könnyedén tud kommunikálni a WordPress oldallal és feltölteni a legújabb bejegyzéseket, média fájlokat, stb.

Hogy mire is jó az XML-RPC valójában? A válasz egyszerű. EZ egy általános kommunikációs forma, 2 számítógép között, ahol nem számít a számítógépek felépítése és a rajtuk futó operációs rendszer típusa. A kliens egyszerűen a megadott formátumban közli a másik számítógéppel, hogy milyen függvényeket szeretne felhívni, az pedig képes válaszolni, hogy ezen függvényeknek mi volt a kimenete.

Természetesen van hátránya a rendszernek, nem is kevés. Először is az XML ugye nagyon nem tömör formátum, így a hálózati kommunikáció a sokszorosára dagad. Az XML további hátránya a feldolgozási sebessége. Jóval lassabb egy XML fájlt feldolgozni, mint egy saját bináris típust.

Egy másik hátrány maga a kommunikáció. Szabványos, HTTP kommunikáció, ami megkönnyíti az esetleges visszaéléseket, próbálkozásokat, illetve nehezíti a szerver fejlesztők munkáját ezek kivédése.

Specifikáció: http://xmlrpc.scripting.com/

Egy kérés példa:

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
    <param>
      <value><i4>41</i4></value>
    </param>
  </params>
</methodCall>

A szerver

Na de csapjunk most már bele a lecsóba kicsit. Írjunk XML-RPC szervert!
Ehhez én a C# ot választottam. Tudom, hogy nem a legoptimálisabb, nem a leggyorsabb (habár nem is olyan borzalmasan lassú, mint a Java), viszont rengeteg minden meg van már benne írva, amivel nem kell foglalkozni, csak használni, ezáltal egy több szálas, TCP / SSL kommunikációval működő szerver elkészítése nem több 1 könnyed napi munkánál. Azon esetekben ahol az XML-RPC jó megoldás és nem több tízezer felhasználót kell kiszolgálni másodpercenként, bőven elég lehet egy ilyen megoldás.

Amellett a C# most nagyon divatos 🙂

No, de kezdjük is el. Az első dolog, amire nem árt figyelni, hogy lehetőleg olyan kódot írjunk, amit a Mono is képes lefordítani, így C# ban is elmondhatjuk, hogy multi platform kódot írtunk, ráadásul jobb esetben még akár Unity3D ben is felhasználhatjuk, hisz az is Mono val fordít.

Hogy ki hol kezdi, az egyedi, én az XML felolvasóval kezdtem.

XML reader

A beépített System.XML túl rengeteg letölthető minimális XML olvasó található, vagy akár írhatunk mi is egyet saját kezűleg. Ez utóbbit inkább csak akkor javaslom, ha sok időnk van és szeretnénk ezzel szórakozni, máskülönben egyszerűbb leszedni egy működő minimál kódot. Részemről egyszerűen letöltöttem ezt: SmallXMLParser. Apró módosításokkal teljesen személyre szabható és optimalizálható.

Felmerülhet a kérdés, hogy mi értelme ennek. A válasz viszont annyira nem egyszerű. Ha kizárólag Windows ra fejlesztünk, akkor nem sok értelme van, hisz ott a System.XML, amit nyugodt szívvel használhatunk, hisz ott a Windowsban mindig. Ám mi van akkor, ha több rendszerre szeretnénk eljutni, vagy ha Unity3D vel akarjuk kombinálni. Ezen esetekben nem biztos, hogy van System.XML.dll ünk, vagy egyszerűen csak nem akarjuk letölteni az egész DLL-t. Ugyancsak a SmallXMLParser mellett szól, hogy jóval kevesebb dologgal foglalkozik mint a minden szabályt figyelembe vevő XML olvasók, ezáltal jóval gyorsabb lehet a kód!

Persze ha tudjuk, hogy egészen pontosan milyen platformra fordítunk, felmerülhet a natív kód alkalmazása, azaz C/C++ ban írhatunk saját XML olvasót, de nagyon figyeljünk, hogy a Natív – Managed kód váltás is nagyon erőforrás igényes tud lenni!

Szerver

Nem tudom nem-e túlzás szervernek nevezni mindazt, ami C# ban ahhoz kell, hogy egy porton figyeljünk és adatokat fogadjunk. Rettentően egyszerű dolgunk van, mert mint írtam a C# ban már minden készen van! Míg C/C++ ban komoly szenvedés tud lenni egy socket és az SSL layer összehozása, addig C# ban egy egyszerű beállítás (majdnem :))

public bool Start( IPAddress aIP, int aPort, IServiceProvider aServiceProvider, String aCertFile )
{
    ServiceProvider     = aServiceProvider;
    Stopping            = false;

    mConnectionCallback = new AsyncCallback( OnConnectionHandler );
    mAcceptCallback     = new WaitCallback( OnAcceptHandler );

    mListener           = new TcpListener( aIP, aPort );

    try
    {
        mListener.Start();
        mListener.BeginAcceptSocket( mConnectionCallback, null );
    }
    catch /*( System.Exception ex )*/
    {
        return false;
    }

    if ( ( aCertFile != null )
      && ( File.Exists( aCertFile ) ) )
    {
        if( !SSLInitialized )
        {
            ServicePointManager.ServerCertificateValidationCallback += ( s, cs, ca, p ) => true;
            SSLInitialized = true;
        }

        mCertificate = new X509Certificate2( aCertFile, "mycertpassword" );
        SSLEnabled = true;
    }
    else
    {
        SSLEnabled = false;
    }

    return true;
}

Íme. Egy nagyon egyszerű kódocska, ami alig 1-2 érdekességet azért tartalmaz 🙂
Az egyik ilyen fontos dolog, hogy a szerverben kiüssük az SSL certificate validálását abban az esetben, ha csak titkosítani akarunk, de nincs hiteles SSL Certification ünk.

Az alábbi sorral ezt el is végezhetjük:

ServicePointManager.ServerCertificateValidationCallback += ( s, cs, ca, p ) => true;

Hogy ez mi is? A ServicePointManager.ServerCertificateValidationCallback jéhez hozzá adunk egy új függvényt, ami mindössze annyit csinál, hogy true val visszatér.

http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.servercertificatevalidationcallback.aspx
http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback.aspx

Egyeseknek idegen lehet a ( s, cs, ca, p ) => true így leírva. Ez a C# Lambda Expression. Szépen átláthatatlanná lehet tenni vele a kódot, de azért néha jól tud jönni, ha nem akarunk annyit gépelni 🙂

Nos, a szerverünk már fut is, habár ha csatlakozunk is hozzá sok minden nem történik.
Az, hogy mi van az OnconnectionHandler ben nem írnám le, aki a témával foglalkozik hamar rá fog érezni, de azért 1-2 jó tanácsot leírnék:

Mindenképpen hozzunk létre egy osztályt, ami az új kapcsolat adatait tartalmazza. Socket, ReadBuffer, esetleges hozzá tartozó biztonsági szintek, beállítások, események, így jóval könnyebb lesz kezelnünk egy egy kapcsolatot, vagy felhasználót.

A másik a ThreadPool.QueueUserWorkItem nevű függvény, ami miatt az mAcceptCallback létre lett hozva. Elfogadott, hogy az accept kicsit lassabb, ha már létrejött a fizikai kapcsolat, úgyhogy érdemes az ezzel járó inicializálást akkor elvégezni, amikor “van szabadidőnk”.

Kommunikáció

Van XML ünk és van szerverünk, de még nem dőlhetünk hátra, hisz a hálózati kommunikáció még C# ban sem fenékig tejfel, legalábbis én még nem találtam meg benne azt a beállítást, ami mindent megoldana 🙂

Alapvető probléma, hogy a hálózaton a csomagok még TCP-n sem úgy jönnek, ahogy azokat elküldjük. Nagy könnyebbség, hogy biztosan sorba vannak rendezve és biztosan mindegyik megérkezik, de abban nem lehetünk biztosak, hogy egy olvasással a teljes elküldött adat mennyiséget felolvastuk.

Hogy kicsit talán érthetőbb legyek, elküldjük az alábbi kérést:

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
    <param>
      <value><i4>41</i4></value>
    </param>
  </params>
</methodCall>

Ekkor a szerver ugye észreveszi, hogy jött neki adat csomag az adott hálózati kapcsolaton.
Mi megpróbáljuk felolvasni a teljes adatot, ami ennyi lesz csak:

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>
<methodCall>
  <methodName

Nem az egész XML, amire nekünk szükségünk lenne, ezért várnunk kell és ha megjött a maradék, akkor feldolgozni a kérést.
Ha nem jött le az egész fejléc (aminek a vége a \r\n\r\n) akkor ezt a vezérlő karakter láncot meg kell várjuk. Ha ez megérkezett akkor a Content-length ben megadott mennyiségű bájtot kell még felolvasnunk, ennyi adatnak kell megérkeznie. Ha ezek megvannak, akkor elkezdődhet a feldolgozás.

Procedure regisztráció

Ez nem egy túl bonyolult téma, egyszerűen csak a véleményen osztom itt meg mindenkivel. Én személy szerint szeretem a C# ban létező Attribute osztályokat, ezért egyszerűen írtam egy ilyen osztályt, amit egy class függvényeihez lehet adni.

[ AttributeUsage( AttributeTargets.Method, AllowMultiple = true ) ]
public class RpcCommandAttribute : Attribute
{
    public string MethodName { get; private set;}

    public RpcCommandAttribute( string aMethodName )
    {
        MethodName = aMethodName;
    }
}

Regisztrációkor végig megyek az átadott osztály függvényein és amelyiken van RpcCommandAttribute azt feldolgozom és regisztrálom.

public void Register( IMethod aMethod )
{
  Type MethodClassType = aMethod.GetType();
  System.Reflection.MethodInfo[] Methods = MethodClassType.GetMethods();

  foreach( System.Reflection.MethodInfo Method in Methods )
  {
    RpcCommandAttribute[] Attributes = Method.GetCustomAttributes( typeof(RpcCommandAttribute ), true ) as RpcCommandAttribute[];
    foreach( RpcCommandAttribute CommandAttribute in Attributes )
    {
      MethodCallback Callback = (MethodCallback)Delegate.CreateDelegate( typeof( MethodCallback ), aMethod, Method );
      mRegisteredMethods.Add( CommandAttribute.MethodName, Callback );
    }
  }
}

Itt jegyzem meg, hogy C# ban az Attribute osztályok végéről használatukkor elhagyható az Attribute rész, azaz az RpcCommandAttribute ot használhatjuk RpcCommand ként is!

 

A procedure call

Ez az a rész, ahol multi thread nek kell lennünk. Ugye egy egy függvény futása sokáig is eltarthat (már akár 1 másodpercig is), ezért nem tehetjük meg, hogy egyszerre csak 1 kérést szolgálunk ki. Könnyű a dolgunk, ha nincs olyan rész, ahol a kérések össze akadhatnak, mert akkor nem kell minden féle lockokkal és rw mutexekkel foglalkoznunk.

Azaz ez így nem teljesen igaz, ugyanis. A szerver a feldolgozott kéréseket egy Queue ba teszi, a szálak pedig innen szedik ki és hajtják Őket végre. Ennek a Queue nak thread safe nek kell lennie, máskülönben csúf fagyások elé nézünk 🙂

Egy kényelmes megoldás: ConcurrentStack. Sajnos jön a fekete leves, kizárólag 4.5 ös .Net ben elérhető, ami azt jelenti, hogy a Mono nem ismeri ezt a tároló osztályt. Azért pánikra semmi ok, szerencsére egy egyszerűbb thread safe stack et összedobni C# ban nem több fél óránál, így azoknak, akik Linux / Unity alá is szeretnék lefordítani, ennyit még rá kell áldozni a projektre 🙂

Tehát, a szerver, a feldolgozott RPC hívás információkat egy stack be teszi, a futó worker threadek pedig ezt a stacket figyelik. Ha van benne valami, akkor az első aki hozzáfér kiszedi belőle a kérést és elkezdi végrehajtani, ezáltal lehetőséget adva a többi szálnak is, hogy egy másik kérésen dolgozzanak.

A szálak száma nem végtelen. Nem túl szerencsés a CPU szám + 1 nél többet futtatni, de természetesen ez nagyban függ az eljárások fajtájától. Ha mindegyik rengeteg IO művelet, IO megszakítással, akkor lehet több szál is, hisz IO waitekben sokat állnak, ezáltal adnak lehetőséget a többi szálnak a CPU használatára. Ha minden függvény erősen CPU függő, akkor nem tudunk többet felvenni, mert egymást akadályozzák!

 

Végszó

Íme, nagyon nagy vonalakban ennyi egy XML-RPC szerver (erős túlzással :)), de a lényeget remélem sikerült összefoglalni, illetve pár dologra felhívni a figyelmet, esetleg ötletet adni. Természetesen aki ennél is többet szeretne tudni eme remek dologról, nyugodtan hozzászólhat és leírom, amit csak tudok 🙂

A lényeg, hogy fejlesztés közben mindig mérjük fel, hogy mennyi időnk és erőforrásunk van és ez által tervezzük meg a programunkat a felhasznált programnyelvtől, a felhasznált 3rd Party eszközökön át egészen a megvalósítás apró optimalizációjáig, hogy a lehető legjobb eszközt állítsuk elő, és mindig kódoljunk szépen, átláthatóan, máskülönben a saját kódunkat sem fogjuk felismerni 🙂

Sok sok sok sok …

Már 2 hónapja?? Ilyen régóta nem írtam ide semmit. Persze rengeteg magyarázat van arra, miért hallgattam és ebből a legfontosabb, hogy azon kevés szabadidőmet és írási energiámat ami volt, elvitte a DevGru.hu. Rengeteg cikket írtam ide, aki szeretné, érdeklődik a katonai írások iránt az nyugodtan olvasgathatja.

Na de szedjem össze mi minden is változott azóta, hogy feltettem az utolsó bejegyzést.

  • Telefon
    Na igen. Letettem a Black Berryt, egyszerűen már elegem lett belőle. Nagyon lassú, semmilyen alkalmazás nincs rá, ami van az is vagy lassú, vagy bugos, vagy egyszerűen bűn ronda.
    Az asszony Androidos HTC -jét nyúltam le (persze, Ő kapott egy XPeria Mini Pro –t).
  • MMORPG
    Ebben is komoly változás állt be. Az EVE Online mizériának vége. Sajnos nincs annyi időm, amennyi kellene, egyedül, vagy inkább kettesben Fox al viszont unalmassá vált. Egyszerűen több időt igényelt volna, ettől függetlenül nagyon szép és jó játék, ha nem havidíjas lenne egészen biztos, hogy a rabja maradok.
    Az EVE helyett most a Runes of Magic el játszom. WoW klón, érdekes, izgalmas, F2P típusú játék. Először kissé zsúfolt volt, amikor Elfet indítottam, de aztán jött az ember, amivel már sokkal nyugodtabb.
    Runes of Magic Raid
  • Munka
    Ó igen. Itt is komoly változás állt be, ugyanis megszűnik a munkahelyem, úgyhogy jelenleg épp munkát keresek. Sajnos nem nagyon számit a tapasztalat, vagy a projectek, mindenféle hülyeségen kell az embernek magát átverekednie, hogy eljusson az utolsó interjúig … de remélem azért valami csak lesz, jó lenne a játék fejlesztésben maradni, de ha minden kötél szakad, akkor megyek más pályára .. habár félő ott unatkozni fogok Mosolygó arc
  • DevGru
    A DevGru ban szerencsére nincs nagy változás, egyszerűen megyünk a kijelölt úton. Lett szép egyenruhánk, fejlődtek a fegyverek, az emberek, de összességében szerencsére nem módosult az alapvetően kitűzött cél: komolyan, összeszedetten menni a cél felé!
    DevGru csoport kép
    Annyit azért megjegyzek, egyik cikkemet lemásolták, úgyhogy azt kell mondjam büszke lehetek magamra Mosolygó arc
  • Programozás
    Itt is van fejlődés. Elkezdtünk Unity3D –zni. Érdekes, izgalmas, sok dolgot lehet benne csinálni, egy kicsit lehet C# ozni, sokkal jobban belejöttem mint eddig Mosolygó arc
    egyszóval tetszik nagyon, sajnos meg már nem éri meg, hogy a Nadirim megmozduljon 3D ben. Nagy kár, jó kóder csapata volt.
  • Bleki.hu
    Hajjaj … bleki.hu igen igen, nem egy egyszerű buta weblap, hanem egy igényes WordPress oldal! Végre az “idiótája” megcsinálta normálisra a honlapját, szánt rá némi időt és még egész jól is néz ki. Még blogolni is elkezdett, pedig mennyire köpködött rá Mosolygó arc
    Gondolom főleg kocka kóder hüjeségek lesznek rajta, akit érdekel érdemes betenni a könyvjelzők közé, hátha nem hagyja abba 2 nap után Mosolygó arc

Azt hiszem, úgy nagy vonalakban ennyi hirtelen, legalább egy kis információ morzsa rólam, annak akit érdekel a dolog.
További jó olvasgatást, webezést és minden egyebet!

Luke, adj életjelt …

Szinte már már a mottóm lehetne, hogy megint milyen régóta nem írtam ide semmit. Ez részben annak köszönhető, hogy rengeteg munkám volt, plusz itt az utolsó pár napban még beteg is lettem, de ez persze közel sem jelenti azt, hogy ne történt volna egy csomó minden!

Kezdjük hát 🙂

Először is megjelent a Nadirim újabb verziója, vagy hát végre releaseltünk egy rendeset végre 🙂 Nagyon szépek az új területek, sok mindent újra állítottak, vagy végre beállítottak, így maga a játék nagyságrendekkel jobb lett! Valamelyest ez a játékos számon is megmutatkozik, de még nem az igazi, úgyhogy mindenki jöjjön NADIRIM ezni!

Viziszőrny Az első szörny, akit le kell győznünk!

 

Szemét város

Szemét város

 

nadirim_3

Az új random combat háttér 🙂

Szóval jó sok minden változott, nagyon látványos, sokkal sokkal érdekesebb, végre vannak boss fightok, értelmes itemek, questek, minden ami kell, persze sok sok feature hiányzik még, de ami késik!  😉

 

devgru DevGru! Elkészült a DevGru honlapja! Remélem sok hasznos információ lesz rajta, a rengeteg élmény beszámolóval és a frankó képekkel együtt! 🙂

Végre sok játék volt az idén, élveztem is nagyon és borzalmasan zavar, hogy most az utolsó 2 játékra, ami kifejezetten jó is volt, nem tudtam elmenni. Az egyik a munka miatt a másik ez a rohadt betegség miatt hiúsult meg …

A bátyám rengeteget segített, megcsináltatta az M4 esem, új, modern aksival, elintézte az M14 esem fejlesztését is, végre komoly mesterlövész puska lesz! Szóval jól alakulnak az Airsoftos dolgok, remélem az idén mindkét megmaradt játékra tudok menni!

 

 

Az autóval is történtek dolgok … sajnos a kuplung megadta magát, amit még a jó kis Fiat szervizbe tettek bele, jó sok pénzért, mert hát persze, hogy nem garanciális a probléma (de legalább azóta a Fiat Magyarország nem zaklat kéretlen levelekkel … hatott a feljelentés úgy látszik …).

Szóval a kuplung megadta magát, trailert kellett hívni és 3 napig BKV val kellett járnom!!!!! még szerencse, hogy Berni tartotta bennem a lelket … elszoktam a BKV csodálatos lététől …. egyszerűen borzalmas volt 🙂

 

A macskák! Igen, igen, van velük is hír, de szerencsére jó hír! Fox megmentett egy kis cicát, ami most nálunk vendégeskedik pár napig!

Macska

A kis macsek fiú, azonnal elkezdett Pöcivel és Zabival játszani, nagyon aranyos és még nincs neve!! Szóval ha van ötleted nyugodtan írd meg a megjegyzések közé!

Most is itt rohangálnak és a 2 nagy macskát kergeti, hihetetlen, hogy Zabracsek hogy fél tőle 🙂

Pár napig nálunk marad, úgyhogy lehet majd nyúzni, meg szeretgetni, kíváncsi vagyok, mennyit fogunk tudni aludni tőle, mert a másik kettővel eléggé nehéz időszak volt, amikor ekkorák voltak. Ja azt nem is említettem, még csak 3 hónapos a kisöreg 🙂

Akartam róla képet csinálni, de egyszerűen nincs olyan eszköz, ami rögzíteni tudná, ahhoz túl gyors.

 

 

FILM FILM FILM FILM! … akár egy borzalmas TV műsör is jöhetne most, de nem, megint megnéztünk pár filmet!

Először is talán a Casablanca-t említeném! Egyszerűen letaglózott a film (nem most láttam először :)) 1942 ben készült, és 1941 ben játszódik! Persze mondhatnánk, hogy nagy dolog, az NCIS is napjainkban készül és játszódik, de akkor Casablanca éppen tombolt a 2. Világháború, Európa tűzben égett és 1941. december 7, én ugye Amerikát is megtámadták a Japánok, úgyhogy nem volt olyan könnyű csak úgy kimenni a rétre, német egyenruhákat szerezni és épp erről filmet csinálni, de ettől függetlenül egyszerűen filmtörténelmi csoda készült szerintem! Ma is roppant izgalmas, pedig összesen 4 et lőnek benne (3 an :)), van benne némi szerelem, de semmi meztelenül ágyba döntés, ami nélkül azt hiszik manapság, hogy el sem lehet adni semmit …

Egyszerűen csodálatos, tökéletes film, úgyhogy, ha valaki esetleg még nem látta, akkor mindenképpen ajánlom nézze meg! Persze nem egy Tripla X, úgyhogy aki mégis csak ennyire vágyik, annak csalódás lehet 🙂 Mindenki másnak egészen biztos, hogy nagyon jó kikapcsolódást fog nyújtani! … lehet megnézem még egyszer 🙂

 The Pillars of the Earth-Gallery-Sam Claflin as Richard, Donald Sutherland as Bartholomew, Earl of Shiring, & Hayley Atwell as AlienaThe Pillars of the Earth © 2010 Tandem Productions GmbH, Pillars Productions (Ontario) Inc., Pillars Productions (Muse) Inc. All rights reserved.

A másik, amit most sikerült megnézni, az a Katedrális.

Nagyon bejönnek az ilyen filmek, ahol egy egész történetet dolgoznak fel és nem csak a főhős egy napját 🙂

A középkor Angliájában játszódik és egy katedrálist akarnak építeni, ahol a király, az egyház és az “egyszerű” nemesség próbálkozik sütögetni a saját pecsenyéjét … rengeteg intrika, cselszövés, némi harc, szerelem, szex, mindez rettentő komoly és kifejezetten tehetséges kezdő színészekkel, jó szereposztással! Úgyhogy ezt is csak javasolni tudom mint egy laza 8 órás elfoglaltságot 🙂 (8 x 1 óra az első évad)

 

Volt még pár film … Zöld lámpás, ami nézhető bőven, főleg, hogy az eredeti sztorit én nem ismerem, Koszorúslányok, ami sokszor eléggé mókás volt … és biztos van ami eszembe sem jut 🙂

 

Hát ennyi minden, és még egy csomó olyan dolog, amit már régen elfelejtettem!

Tool fejlesztés I.

Mivel az eddigi legtöbb látogatót hozó bejegyzés technikai volt, úgy döntöttem nem hagyom abba és írok még valamiről, amiről azt hiszem értek hozzá. Remélhetőleg csupa hasznos információval tele tűzdelve. Sajnos sok ilyen leírást nem csináltam még, így, ha bárkinek van javaslata, hogy és mint alakítsam az írásaimat.

Első körben arra gondoltam, hogy a tool fejlesztésről írok, mivel mostanában foglalkozom vele egy kicsit, és már nagyon régóta érdekel a téma. Könnyen lehet azt hinni, hogy a fejlesztés ezen része egyszerű, amit szinte bármilyen programozó meg tud csinálni. Hát szerencsére ezzel ellent kell mondjak. Egy jó toolt sem könnyebb csinálni, mint akár egy játékot.

Kezdjünk is bele …

Először is ki kell választanunk egy program nyelvet, amiben a toolt fejleszteni akarjuk. Ez a kérdés nem feltétlenül egyszerű, habár ma már rendelkezésünkre állnak olyan technológiák, amik azért megkönnyítik a döntést. Az első lépés, hogy kiválasszuk az operációs rendszert, ami alatt a toolt használni akarjuk. Mivel játékfejlesztő vagyok, leginkább a Microsoft Windows rendszer az, ami a környezetemben leginkább elterjedtebb és be kell látni, hogy ez az a rendszer, ami alá a legegyszerűbb és ezáltal a leggyorsabb fejleszteni (gyorsaság = olcsóság). Való igaz, hogy egy Windows 30-80.000 ft ba kerül, de ha azt vesszük, hogy ez az összes egy fejlesztő 1 heti bére, akkor hamar ki lehet kalkulálni, hogy több értelme van akár Windows rendszereket venni, mint hónapokat beleölni egy Linuxos fejlesztésbe. De azért nézzük meg miért is mondom én ezt.

Windows

  • Kiforrott fejlesztő eszközök (Visual Studio, WPF)
  • Könnyed használat
  • Széleskörű software support
  • Kiforrott, nagymennyiségű library, OS support
  • Fejlett ActiveX-es objektumok
  • Széleskörü codec lista
  • Magas generációs programnyelvek (C#, C++)
  • Kiforrott, komoly SDK-k (XNA)

Linux

  • Széleskörü Open Source megoldások
  • Integrált script nyelvek (Bash, Perl, Python)
  • Ingyenesség
  • C# támogatás

Mivel egy ilyen fejlesztés nem arról szól, hogy ki mit szeretne, itt nincs helye Linux – Windows vita. Egyszerű tények alapján kell dönteni, ami legtöbbször oda vezethető vissza, hogy melyik az olcsóbb és mivel a Windows sokkal több és sokkal kiforrottabb lehetőségeket tartalmaz ezért a választás egyértelműen rá esik.

Az OS kiválasztás után ki is lehet választani a program nyelvet, amit használni akarunk. Ezek a döntések ugyan azon alapulnak, mint maga az operációs rendszer választás. Eléggé sok mindent figyelembe kell azonban venni ahhoz, hogy jó döntést hozhassunk.

A kiválasztott nyelv legyen:

  • Magas szintű, hogy könnyen és ezáltal gyorsan lehessen benne fejleszteni
  • Legyen hozzá grafikus designer, hogy a gui elemeket könnyedén össze tudjuk állítani
  • Legyen hozzá teljeskörü debugger, hogy a hibákat minél előbb megtaláljuk
  • Legyen hozzá remote debugger
  • Legyen jól dokumentálva
  • Legyen a lehető legnagyobb a tudástára, hogy minél kevesebb dolgot kelljen nekünk lefejleszteni
  • Legyen hozzá egy jó IDE, hogy a munkát könnyítse és ne lassítsa
  • A fordító legyen minél gyorsabb
  • Az elkészült program beüzemelése legyen minél könnyebb
  • A futásbeli hibakezelés legyen minél fejlettebb
  • Könnyedén lehessen alkalmazni hozzá a fontosabb librarykat (adatbázis, 3D, script, stb)
  • Képes legyen DLL ek betöltésére (akár ctype al)
  • A könnyed fejlesztés mellett legyen gyors és ne egyen sok memóriát
  • Legyen hozzá minél több gui elem
  • Képes legyen ActiveX es objektumok használatára

ez eléggé sok feltétel, de nem árt, ha olyan nyelvet keresünk, ami mindennek megfelel. Persze, van ilyen nyelv, mert az alapján szedtem össze, hogy mit kell tudjon, azaz csaltam egy kicsit. Mivel a választott operációs rendszerünk a Windows ezért szinte csak egy nyelv jöhet szóba, de azért nézzünk meg pár lehetséges választást, megpróbálom megindokolni, hogy melyik nyelv miért nem jó.

  • C++ – mondhatni ősi nyelv, minden tud, gyors, kevés memóriát eszik, viszont kevés UI Framework van hozzá és azokhoz sincs grafikus designer. (Gtk, Gtkmm – itt megjegyezném, hogy egy magyar, Érdi Gergő eléggé kiemelt helyen van ebben a projectben, Qt – ami egy eléggé életképes alternatíva, multi platform és kifejezetten sokat tud, habár a KDE ezt a keret rendszert használja és sajnos eléggé bugos, ami nem biztos, hogy a Qt hibája, MFC – ezzel kb a kisgyerekeket kell riogatni). Maga a C++ eléggé bonyolult nyelv és nagyon sok minden nehezen implementálható, illetve saját magunknak kell megteremteni. Nincs benne védelem sok alaphiba ellen (mivel nincs saját VM je), így a memória felülírás, rossz pointer használat, mind komoly veszélyt rejt.
  • Java – a C++ al ellentétben a Javanak van saját VM je, nincs benne pointer, így memória hibákat Önmaga kivédi. A garbage collector miatt nem kell foglalkozni az objektumok menedzselésével sem. A Javahoz óriási mennyiségű library van, nem tudok olyat mondani, ami nincs megírva hozzá. Ezzel ellentétben sajnos nincs hozzá olyan editor ami valóban könnyeddé tenné a fejlesztést. Mind az Eclipse, mind a Netbeans komoly hibákkal küszködik, sem a debuggerek sem maga az IDE nem könnyen használható, nem felhasználó barát, viszont nagyon lassúak, ezáltal lassítják a fejlesztést. Mindemellett Windows alatt Java-t futtatni eléggé körülményes tud lenni, főleg a 64 bites rendszeren. UI Frameworkben nem szenved hiányt, viszont grafikus designerben annál inkább. A Netbeans és az Eclipse az elsődleges amit említenek. Az Eclipseet próbáltam, de nem működött, a weboldalán írták is, hogy jelenleg nem működik. A Netbeans pedig lassú volt, nehezen kezelhető és itt ott komoly bugokkal szenvedett.
  • Adobe Air – újszerű ötlet, de szinte azonnal ki is lehet zárni. Nem támogat multi threadinget, nem tud natív kódot hívni, nem tud dll-t betölteni, nincsenek hozzá adatbázis driverek, csak magas szintű hálózat kezelés van benne. Úgyhogy kilőve.
  • C# – igen, ez az a nyelv, amire gondoltam. Nem meglepően, mert a fentebb felsorolt elemekből minden igaz rá. Akárcsak a Javaban itt is minden meg van írva, viszont van hozzá egy nagyon komoly IDE, grafikai designer, debugger. Mivel az IDE fizetős, ezért nincsenek benne fél megoldások, nem kontárkodik bele mindenki, amitől rengeteget tud, de semmit sem jól. Képes dll ek betöltésére, képes natív kód hívására, ActiveX objektumok betöltésére, nagyon egyszerű. Mindezek mellett komoly OS supportot is kap, ami csak hab a tortán. Mindezek mellett eléri a teljes DirectX et, akár natív módon, akár a managed kódot, vagy akár az XNA-n keresztül, ami ugye multiplatformos 3D megjelenítést és még sok minden mást tesz lehetővé.

Nekem mindig egyszerű a választás és mindig a C# mellett teszem le a voksom. Egy régi munkatársam, akitől eléggé sokat tanultam, mindig azt mondta:

C# ban ha valami több mint 1 sor, akkor ott elrontottam valamit

 

Igaza is volt. Minden meg van valósítva, amire szükség lehet, és egyre több és több a már amúgy is hatalmas mennyiségű C# Managed Library, amit felhasználhatunk a toolunkhoz.

Mára ennyi, még folytatom, ahol már inkább programozás lesz, mint szövegelés.

Go to Top