Archive for augusztus, 2011

Megemlékezés a legeredményesebb magyar pilótáról

A Haborumuveszete.hu –n jelent meg cikk, hogy megemlékeztek vitéz Szentgyörgyi Dezső haláláról. Ő jelenleg is a legsikeresebb magyar vadászpilóta, aki a 2. Világháború idején 220 bevetést repült, ahol 33 ellenséges repülőgépet lőtt le!

Komoly eredmény, hisz az ellenséges pilótáknál az 5-10 győzelem számított komoly teljesítménynek. Hihetetlen túlerővel szálltak szembe, nem a náci eszme, hanem a Magyar haza, a nép és az esküjük kötelezte Őket erre!

Szentgyörgyi Dezső: http://hu.wikipedia.org/wiki/Szentgy%C3%B6rgyi_Dezs%C5%91

bf109hu

Sztorizgatunk, sztorizgatunk? :)

Hát igen, megint bele vágtam a fejszémet valamibe, amit remélem jó sokáig csinálni is fogok. Méghozzá elkezdtem leírni Il-2 es történetünket egy blogba. Igaz, ha minden jól megy akkor lesz segítségem, habár Ő erről még nem igén tud.

Mi is ez?
Ugye eléggé komolyan játszottunk annak idején az IL-2 Sturmovik nevű 2. Világháborús repülőgép szimulátorral, ahol ha szabad mondanom, azért egészen szép eredményeket értünk el. Nemrégiben megjelent az IL-2 Cliffs of Dover nevű játék, ami az eredeti második kiadása, sokkal komolyabb grafikával, repülési modellel.

Persze sok idő nem kellett, már el is kezdtünk vele repkedni, persze még jelentősen fékezett habzással, ámbár annál nagyobb bátorsággal, és hát ezen repüléseknek a történeteit szeretném leírogatni, hogy esetleg mások is kedvet kapjanak hozzá, vagy csak kicsit olvasgassanak ilyen történeteket.

A blog itt érhető el: http://12dd.twilek.hu

Jó olvasgatást!

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.

WP Pluginok

Na aki erre téved és eléggé figyelmes megfigyelhet pár újdonságot a weblapon.
Kicsit nézelődtem és telepítettem pár érdekes plugint a WordPress hez. Meglepődtem, hogy ezek a pluginok milyen jól meg vannak csinálva, de még jobban meglepődtem azon, hogy ezekből a pluginokból van ingyenes és fizetős verzió is! Persze nem mindegyik fizetős, de van.

Az új pluginok:

  • Rating-Widget – ha megnézitek a bejegyzések, hozzászólások alján megjelent 5db csillag, amivel lehet szavazni, hogy mennyire tetszik neked az adott iromány. Nagyon profi felülete van, ahol lehet állítgatni. Ez is az egyik ingyenes / fizetős plugin
  • SFC – Comment – végre nem kell belépned, hogy commentet írj a blogomra, habár eddig is csak Blekinek okozott gondot :). Mostantól elég a Facebook accountodal belépned. Ugyan ez a plugin adja a Like buttont, és minden egyébb Facebook os dolgot, teljesen ingyenes
  • SFC – Register – regisztráció a Facebook accountdal! Csak egy kattintás.
  • WPtouch – na ez egy komoly plugin! Ha bizonyos okos telefonos böngészővel érkezel Blogra, akkor nem az itt látható theme-t fogod látni, hanem a telefonodra optimalizált változatot, ami nem mellesleg nagyon igényesen néz ki, és ami kicsit még meg is lepett, hogy működött! (Phone, iPod touch, Android, Palm Pre, Samsung touch and BlackBerry Storm/Torch)

Mindegyik plugin nagyon jó, és meglepő módon mindegyik működik is. Annak idején nagyon nem értettem egyet azzal, hogy ilyen open source eszközt használjak, mindenképpen csak saját magam által írt dolgok lehettek jók, de azt mindenképpen el kell ismerni, hogy ha meg is tudnám írni ezeket a dolgokat (amiben kicsit kételkedem) akkor sem végeznék ebben az életben.

Scriptnyelvek a gyakorlatban …

Rettentően elmés címem mellett valójában azt szeretném ma leírni, hogy hogyan is kell beépíteni a Pythont illetve a Lua-t saját C++ projectünkbe. Ha eddig nem is lett volna egyértelmű, most már biztos, hogy ez megint egy technikai írás lesz, amit remélem sikerül legalább annyira érdekesre, vagy viccesre megírnom, hogy azért ne aludjon el mindenki a monitor mögött.

LUA

Kezdjük először a Lua val, mivel ez a script áll hozzám közelebb és sokkal jobban is ismerem mint a Pythont, így talán a későbbi botlásokat könnyebben elnézik.

A Lua jelenleg az 5.1 es verziónál tart, C ben fejlesztik és egy eléggé egyedi (már a scriptnyelvek terén) nézőpontot támogat, méghozzá a stack kezelést. Gyanítom ebben rejlik hihetetlen sebességének kulcsa.

A sebességnek viszont mindig ára van, jelen esetben a kicsit sem egyszerű C interface, amivel sajnos meg kell birkóznunk.

#include <stdio.h> 
#include <stdlib.h> 
#ifdef __cplusplus
   extern "C" {
#endif // __cplusplus 

 #include <lua.h> 

#ifdef __cplusplus
    };
#endif // __cplusplus 

int main( int argc, char** argv )
{

    // Lua VM letrehozasa   
    lua_State* State = lua_open();

    // Lua alap libek betoltese 
    lua_openlibs( State );

    // myfile.lua fajl futtatase 
    lua_dofile( "myfile.lua" );

    // MyFunc fuggveny elovetele
    lua_getfield( State, LUA_GLOBALSINDEX, "MyFunc" ); 

    // elso parameter 
    lua_pushinteger( State, 10 );

    // a MyFunc fuggveny felhivasa 1 parameterrel, 0 result al 
    lua_call( State, 1, 0 ); 

    // Lua State lezarasa 
    lua_close( State ); 

    return 0;
}

Mint a kódon láthatjuk egy egyszerű függvényhívás is már egy összetettebb probléma, hát még az objektum orientált függvények, tömb, table változók.

Szerencsére vannak megoldások arra, hogy a Lua is elfogadható és könnyen használható legyen. Mivel a projectekben fontos az, hogy ne hetek, hónapok menjenek el egy egy feladattal, hanem minél rövidebb idő alatt álljon elő olyan eredmény, ami kielégítő működést ad, ezért nem mindegy, hogy mennyire nehézkes a választott scriptnyelv importálása az alkalmazásunkba.

A Lua általam legkedveltebb C++ interface-e a LuaPlus. (Dokumentáció: http://wwhiz.com/LuaPlus/LuaPlus.html)

A LuaPlus al sokkal könnyedebbé válik a Lua használata, úgy, hogy nem vesztünk jelentős sebességet.

#include <stdio.h> 
#include <stdlib.h> 
#include "LuaPlus.h" 

using namespace LuaPlus;

int main( int arcg, char** argv )
{
    // Lua VM letrehozasa es alap libek betoltese 
    LuaState* State = LuaState::Create( true );

    // myfile.lua fajl futtatasa 
     State->DoFile( "myfile.lua" );

    // MyFunc fuggveny elovetele 
    LuaFunction<> MyFuncObject = State->GetGlobal( "MyFunc" );

    // a MyFunc fuggveny felhivasa 1 parameterrel, 0 result al 
    MyFuncObject( 10 );

    // Lua State lezarasa 
    LuaState::Destroy( State );

    return 0;
}

Remélem a példával jól látható, hogy a LuaPlus egy sokkal egyszerűbb, érthetőbb interface, mint az alap C Api. Rengeteg olyan lehetőséget biztosít, amivel komoly Lua bindet építhetünk össze úgy, hogy nem megy el rengeteg felesleges idő a fejlesztésre.

Ami még nagyon hasznos a LuaPlus ban, az az, hogy Nativ és Managed kódhoz is van DLL je, így amit C++ alkalmazásunkban használunk, majdnem ugyan úgy használhatjuk C# toolunk ban is! Ez megint csak csökkenti a fejlesztési időt.

Persze ez is olyan, mint sok más interface, az ember szeret belőle sajátot írni, ami jól is hangzik elsőre, de amint próbálunk a Lua C Api mélyére ásni, rá kell jöjjünk, hogy nem olyan egyszerű feladat.

 

Python

A Python jelentősen más fajta mint a Lua. Személyes véleményem szerint itt sokkal inkább a használhatóság, beépíthetőség volt a fő szempont, mintsem a gyorsaság. Ez egyben előnye, de hátránya is a scriptnek. Előny, a már említett fejlesztési idő miatt és hátrány, a sebesség vesztés miatt. A  Python körülbelül 2 szer lassabb és 1.5 ször több memóriát eszik meg mint a Lua, habár vannak esetek, amikor Ő teljesít jobban. Jelenleg ugye a Pythonból úgymond 2 verzió létezik a 2.7 és a 3.2. Az itt megadott mérési eredmények a 3 as Pythonra vonatkoznak: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=lua (az oldal nehézkesen működik, úgyhogy néha sokat kell próbálkozni)

De akkor lássuk hogy is építsük be a Pythont a kódunkba:

#include <Python.h> 

 int main( int argc, char** argv )
{
    // Python VM letrehozasa 
    Py_Initialize();

    // hozzaadas a path hoz az aktualis konyvtarat
    // erdemes azt, ahol a python fajljaink vannak 
    PyRun_SimpleString("import sys");
    PyRun_SimpleString("sys.path.append(\".\")");

    PyObject* ModName = PyString_FromString( "my_file" );

    // a sajat fajlunk betoltese mint modul 
    PyObject* Module = PyImport_Import( ModName );
    if ( Module == NULL )
    {
        // ha nem sikerult volna, akkor error es kilepes 
        PyErr_Print();
        return 1;
    }

    PyObject* Dict = PyModule_GetDict( Module );
    // a fuggvenyunk lekerese 
    PyObject* Func = PyDict_GetItemString( Dict, "MyFunction" );

    // ellenorzes, hogy felhivhato-e 
     if ( PyCallable_Check( Func ) )
    {
        // parameter eloallitasa 
        PyObject* Args = Py_BuildValue( "(i)", 14 );
        // a fuggvenyunk felhivasa 
        PyObject_CallObject( Func, Args );
    }
    else {
        // hiba eseten hiba kiirasa es kilepes 
        PyErr_Print();
        return 1;
    }

    Py_XDECREF( Module );
    Py_DECREF( ModName );

    // VM torlese 
    Py_Finalize();
    return 0;
}

Hát elsőre úgy tűnhet, hogy jóval hosszabb kód állt elő, de ennek egy része a fájlunk és annak függvényeinek betöltése, plusz itt van hiba kezelés is, ami jóval egyszerűbb, mint a Lua ban.

A kódból nekem az jött le, hogy sokkal “felhasználó” barátabb, könnyebb a kezelése, pointerekkel dolgozik, így talán kevesebb objektum létrehozás van, mint a LuaPlus ban.

Konklúzió

Mindazok mellett, hogy milyen komoly szavakat ismerek, azt kell mondjam, hogy mindkét script nyelv nagyon érdekes, a használatuk izgalmas és rengeteg sok lehetőség rejlik bennük. Igazából nem is nagyon tudnék dönteni, hogy most melyik tetszik jobban.

Mindkét nyelvhez található IDE és Debugger is szép számmal:

LUA

  • IntellijIDEA– egy multi platform editor, eléggé sok feature el, LUA supportal, ahol saját(!) libeket lehet hozzá adni (van hozzá WoW és Rift Library). Ez nagyon hasznos tud lenni, mert így a saját projectunk függvényeit könnyedén be tudjuk illeszteni, ami segíti a fejlesztést
  • LuaEdit– teljesen ingyenes és eléggé igényes editor és debugger a Luahoz, solution fájlokat kezel
  • Scite– eléggé komoly, multi platform editor minden féle nyelvhez
  • Addon Studio– érdemes megnézni, mit is lehet csinálni egy IDE vel és egy jó script engine el. Persze ez csak egy editor, de itt látható, hogy a WoW Addon / GUI rendszere mennyire flexibilis
  • LuaStudio– egy eléggé komoly és letisztult Lua IDE és debugger
  • Decoda – sajnos fizetős, de természetesen a legjobb IDE és debugger. Előző írásomban már áradoztam róla. Mindent tud, amit kell, főleg a remote debug a kielégítő benne!

Python

  • GDB– most lehet páran megrökönyödnek, hogy hogy lehetséges, hogy a gdb-t valaha is szóba hozom, de jelenlegi munkám során találkozom vele és nem árt, ha a debugger rendszerekből nincs tíz féle. Persze egy designer vagy tester nem biztos, hogy valaha megbirkózna vele, de ettől még egy lehetőség
  • WinPdb– egy multi platformos Python debugger, persze Python ban. Ingyenes, és egyszerűen mindent tud, amit egy debuggernek tudnia kell, mindamellett, hogy még igényes is! Természetesen alapból remote debugging, úgyhogy nagyvalószínűséggel a szerveren futó Python scripteket is gond nélkül debuggolja
  • PyScripter– open source IDE és debugger, meglepően jó syntax highlight al és code completition el!
  • WingWare – fizetős program nem is próbáltam ki, a WinPDB és PyScripter után azt hiszem teljesen felesleges

 

Mindent összevetve mindkét nyelvhez vannak iDE-k és Debuggerek is, mindkettőhöz jól használhatóak a programok, viszont a Pythonnak 1 nagy előnye van: GDB, hisz nem árt, ha az ember egyből tudja debuggolni, ha akár a saját alkalmazásában hal el a script.

Nekem személy szerint az újdonság erejével tetszik a Python nagyon és abban a szerencsés helyzetben vagyok, hogy szórakozhatok mindkettővel, de hogy melyiket használnám egy projectben … az még számomra is kérdéses, ehhez azért sokkal több konkrétum kell és egy jól megfontolt döntés!

 

Addig is remélem van akinek felkeltettem az érdeklődését az alábbi 2 irományommal és kedvet csináltam némi scriptelgetéshez! Jó szórakozást mindenkinek!

Go to Top