Megállók keresése

Re

Az utobbi pár napban nem volt kedvem, időm nagyobb volumenő dolgokat alkotni, így csak "bütykölgettem", főkéne a szakdolgozat környékét. Jó lenne már működés készen, egészben látni a dolgot.

Tegnap és ma a keresési felületet pakoltam össze. Azt hiszem elég korrekt lett - ha van ellenvetés hallgatom - bár a végső szót úgy is a Tanár Úr, mint legnagyobb kritikus mondja ki. Csináltam két képet róla, szerintem elég egyértelműek az egyes részei.

Itt szeretném megjegyezni, hogy aki szeretne segíteni a tesztelésben annak a munkáját szívesen fogadom. Mindössze járatokat kell bepötyögni az asztali gépra írt programba.

Mio A701 biztonsági beállításainak hangolása

Re

Frissítettem a Miom romját. Van némi fenakadás a programozásban, és gondoltam lehet a rom a rossz, de nem. Viszont a rom frissítéssel előjött egy dolog, amit most leírok.

Ha új programot telepítünk a WM5-re akkor ő figyelmeztet, hogy nem biztonságos helyről származik. Ez fejlesztésnél is előjön sajnos. Minden futatáskor engedélyezni kell, hogy megbízható. Elég idegesítő. Ez beállítható, egy külön progival, aminek a neve Security Configuration. Innen tölhető le.

A bonyolultnak nem nevezhető. Le lehet menteni a WM5 jelenlegi beállítási szintjét, és egy újat lehet rá állítani. Én a "Security off"-ot használom, így fejlesztésnél semmit nem krédez, csak futatja amit szeretnék. Természetesen mindenki a saját felelőségére piszkálja a PDA-ját! :)

Elérési utak útvesztőjében

Re

Este felé már kellően untam magam, hogy nekikezdej kszakdolgozatot írni. A keresést kicsit jegelem, így nekifogtam a mobilos részhez (újra ?). Amikor elkezdtem újraírni a rendszert 3 részre szedtem a dolgot. Ha most nagyot akarnék mondani azt mondanám, hogy MVC alapokra helyezve. Így 3 részre esett a programozás. Az MVC M és C részét igyexem egy külön projektbe pakolni. A V-ét pedig két külön alkalmazásra bontani. Kis magyarázat (elnézést ha túl pongyola lesz):

A két alkalmazást írok. Az egyik ami tárgyát képezi a szakdolgozatnak a WP5-re készül. A másik egy asztali alkalamzás, amivel a menetrendet könnyen, nagy gépnél elő lehet állítani. Könnyű kitalálni, hogy a két alkalmazás körülbelül ugyan azokkal az adatokkal dolgozik (illetve az egyik a másiknak készíti el a megfelelő fájlokat). Felesleges - és nagy hibaforrás - lenne tehát két külön fájlkezelő részt írni, külön begépelni az algoritmusokat (esetleg másolni) stb. Ezért amit mind a két program használni fog azokat külön választottam. Ezek alkotják az Modelt és a Controllt. A két alkalmazás, ami csak amolyan kinézet, azok a View-t.

A dolog érdekessége, hogy az asztali gépen "hagyományos" .netes dolgokat lehet írni. Ebből mi most legújabb az a 3.5 (amit használok belőle az kb már az 1.1-ben is benne volt :) ). "Sajnos" azonban ezt a WM5 nem igazán érti, ezért a WM5-nek írtak egy külön .net-et amit a CF-el rövidítenek, mint compact framework. A CF tulajdon képen egy "hagyományosnak" a butított verziója, direkt PDA-kra optializálva.

Csak egy példa, amibe én is belefutottam. Az asztali .netben vannak halmazok, ezeket a CF-ből kihagyták. Listákkal helyetesíthető, valószínűleg azért maradhatott ki.

Ezek tudatában könnyű volt eldönteni, hogy a közös dolgokat a "butább" rendszerre kell elkészítenem, ha nagyon kell akkor az asztali alkalmazásban kibővítem (erre nem volt szükség sehol eddig).

Ha a közös dolgok a CF-ben futnak, és a nagy gond nélkül kezeli, akkor gondoltam nem lesz baj. Tévedtem :) Az elérési utakkal elszórakoztam egy jó fél órát, mire rájöttem, hogy tudom megszüntetni a hibát. Arra nem jöttem rá mi a hiba, de legalább kikerültem :)

Az elérési utak ugyan a közös részhet tartoznak, viszont máshogy kell megadni a mobil és az asztali alkalmazásnál is, ezért módosíthatónak kell lenniük.

Eredeti koncepció szerint valahogy így adtam meg őket:

static string gyoker = "c:\\";

static string tmp = "tmp\\";

static string zdatFileName = gyoker + "data.zdat";

static string nevekFileName = gyoker + tmp + "nevek.txt";

static string menetrendFileName = gyoker + tmp + "menetrend.dat";

static string koordinatakFileName = gyoker + tmp + "koordinatak.dat";

static string csoportokFileName = gyoker + tmp + "csoportok.dat";

Én azt hittem, hogy ez sima összefűzés, semmi gond nem lehet belőle. Mikor fordítottam WM5-re a dolgot, hogy majd megnézem PDA-n jött a sokatmondó hibaüzenet: NotSupportedException

Legalább azt megmondta, hog mivel van baja :) A neves sorokat jelölte meg hibásnak. Fél óra próbálgatás után rájöttem, hogy ha simán beírom őket, akkor megy. Most lefixáltam őket, csak hát ugye most az asztali nem találja meg a dolgokat :) Majd kitalálok még valami megoldást, amivel állítható lesz a dolog.

Most jöhet a gyagyázás a GPS-el és a hasonló funkciókkal :)

Szakdolgozat, AAR

Re

Mostanában nem túl sokat haladtam a dolgaimmal.

Szakdogában legutóbb leprogramoztam a dijkstra algoritmust. Tegnap megpróbálkoztam a módosításával, mely ahol a súlyok már az aktuális időhöz igazodnak ("röptében" számolni a súlyokat), de valamit elrontottam. Nyugis pillanatomban átnézem majd.

AAR-rel sem nagyon haladtam. Ugyan az oracle osztályok már 95%-ban készen vannak, de túl monoton és unalamas összekötni őket a C#-al. Ugyan azt kell csinálni pici módosításokkal és UUUUNCSI. Hétfő este tényleg már azt is megcsinálom, és Zoli is tud haladni.

Elvállaltam, hogy segítek pár kötelező program megírásában is. Lehet kezdem túlvállalni magam... ejjj fene a jó szívemet :)

Szakdolgozat adatfájlok

Re
Írtam már hogy milyen funkciói lesznek a szakdogának, most jön némi háttér információ. Úgy gondolom, hogy mai PDA-knak nem kottyan meg pár száz kilobyte-nyi adat a memóriában, ezért minden adatot betöltök induláskor a memóriába. Amikor épp nem fut a program az információk 4 fájlban vannak. A fájlokat egy zip-fájlban fogom össze, hogy könnyebb legyen a mozgatásuk.
Minden osztály külön ID-vel rendelkezik. Először a fájlban elhalyezett sorrendre hagyatkoztam, de rá kellett jönnöm, hogy a módosítás és törlés azokban a fájlokban nagy gubancot fog okozni, így a picit több helyet, de sokkal nagyobb stabilitást adó megoldás mellett maradtam.
Külön fájlban tárolom az összes osztály "hétköznapi" nevét.. Kezdés képpen letárolom a járatok számát, majd soronként elválasztva a járat ID-jét és a nevét. Utána hasonló struktúrában a megállókat, a csoportokat, az érdekes helyeket majd a végén a jármű típusokat.
A menetrend külön fájlban tárolódik, ez már nem olvasható csak úgy, mert csak bináris számokat tartalmaz. Járat centrikusan tárolom az adatokat, ezért a fájl elején a járatok száma szerepel, majd utána következik az első járat id-je. Ezután azon megállók szám, amiket a járat érint. Fel is sorolom őket, a következő megállótól való távolsággal együtt. A megállók után megadom hányféle menet nap van, majd h az első menetnaphoz hány indulási időpont tartozik. Letárolom az időpontokat, majd jön a következő menetnap. Ha a végére értem, jöhet a második járat ID-je és így sorban egészen az utolsóig.
A megállók csoportjai egy másik fájlban vannak. Szintén binris, de nem ilyen bonyolult az olvasása. Először megint csak a csoportok száma, majd az első ID-je, és hogy mennyi megállót fog össze és a felsorolásuk. Utána jön a második megálló ID-je stb stb...
Az utolsó fájlba maradtak a koordináták. Koordinátái egyébként a csoportoknak, a megállóknak és természetesen az érdekes helyeknek vannak. Ezeket is ID-jükkel tárolom.
Véleményem szerint - persze elfogult vagyok - kellően stabil és egyszerű ez a tárolási módszer, de vannak hiányosságai. Ezek a hiányosságok olyanok, amik nem veszélyeztetik a szakdolgozat sikerét és nem csökkentik az értékét, ugyanakkor pótlásuk bonyolítana a kódon és csökkentené az átláthatóságát. Kicsi az esély, hogy elsőre működő képes kódot tudnék írni, a hibák javítása sok időt elvenne és fenn állna a veszélye, hogy észrevétlen hiba marad benne.
Tehát a hiányosságok:

• Pazarló tárolás, a koordináták kivételével mindehol 32 bites inteket használok, mert az a legkézreállóbb. Az időpontok, és az ID-k tárolására szerintem elég lenne bőségesen 16 bit is, ami jelentősen csökkentené az adatfájlok méretét. Persze relatívan nézve... 500kB-ot ha le tudok csökkenteni 250 kB-ra az nem rossz, de most egy gigás kártyán fel sem tűnik... Ha a program belső szerkezetét is átvariálnám 32 bites számokról 16-osra valamennyit csökkenne a memóriában lévő adat, de megint csak nem tartom jelentősnek, hogy ezzel szöszöljek.
• Az időpontok tárolását is lehetne módosítani. Minden időpontot külön értékként tárolok. De a városi közlekedére jellemző, hogy a járatok egymást adott időközönként követik. Ha mondjuk egy járat 8-tól este 6-ig 5 percenként indul, akkor az az én tárolási rendszerem szerint 96 bejegyzés. Ha csak azt tárolnám, hogy "8-tól 6-ig 5 percenként" az 3 bejegyzés lenne. Persze ha valamelyik járatnak sűrűn vátozik a követési ideje, akkor ott elveszik ez az előny, sőt! Ha mondjuk a busz menerendeje olyan, hogy a páros járatok 5 a páratlanok 10 perc múlva követik az előzőt, akkor egy buta algoritmus képes lenne 3-szor több adatot generálni, mint a jelenlegi. Persze választhatóvá is lehetne tenni, hogy legenerálja mindkét verziót, aztán eldönti h melyik gazdaságosabb.

Ezek a pótlások olyanok, hogy szép és elegáns megoldások lennének, de talán fel sem tünnének a különbségek a felhasználónak viszont a megvalósításuk eltartana pár napig biztosan.

AAR, Oracle

Re
Mai napon elméleti síkon léptem egyet előre az Oracle objektum-relációs témában. Rájöttem, hogy ha objektumokat akarok bepakolászni, akkor azoknak illik konstruktort is csinálni. Meg is csináltam egyik osztlynak, ment is a ki-be pakolászás. Megcsináltam másiknak, annak is ment a bepakolása, aztán csak bumm, elromlott mindkettő :D Oracle persze mélységesen hallgat, hogy mit rontottam el... Kiderítem ha belerokkan akkor is :)
Jó lenne haladni vele...

Mio A701, WM5, Igo8

Re

A szakdogához kötődően be kellett szereznem egy pda-t is, ami GPS képes és Windows Mobile fut rajta. "Választásom" (ez volt) egy Mitac Mio A701-esre esett. Gondoltam, ha már van benne gps, akkor miért ne próbáljam ki, milyen egy navigáció program. Igo8-at tettem rá. Mivel luxos lett volna kipróbálás miatt eredeti, telepítőset venni, ezért csak Intézőből futattam. Ennek hátránya, hogy bele kell bóklászni, keresgetni, stb stb.
Kerestem egy megoldást, amivel gyorsabbá tehető az indítás.
Amire szükségünk van, az egy WM Registry Editor program. Ami innen beszerezhető ingyenesen az ARM procis verzió.
Figyelem! Muszáj leírnom, h akármilyen rossz módosítás tönkre tegeti a PDA-n lévő rendszert!
Tehát letöltjük a CAB fájlt, felmásoljuk a PDA-ra, majd mint ha hagyományos telepítő lenne rábökünk, beállítjuk hova szeretnénk telepíteni és már kész is. A programok között megtaláljuk az indító ikonját.
Amit találtam módszert, az a kijelző alján látható két, úgynevvezett soft gomb tulajdonságát változtatja meg.
Ehhez meg kell keresni a következő kulcs útvonalat:
HKEY_CURRENT_USER\Software\Microsoft\Today\Keys\
Ha valamilyen okból kifolyólag nem lenne meg a Keys, akkor Edit / New key menüponttal hozzuk létre. Ha a Keys-be nállunk, akkor szintén hozzunk létre egy kulcsot. A kulcs neve 112 legyen, ha a bal, illetve 113, ha a jobb gombhoz akarunk új programot rendelni. Természetesen mindkettőt is létrehozhatjuk, ha azt szeretnénk.
Én a jobb oldalit változtattam meg, tehát így nézett ki:
HKEY_CURRENT_USER\Software\Microsoft\Today\Keys\113\
Ha kiválasztjuk a 113-as kulcsot, akkor az editor alsó felében látjuk, hogy teljesen üres.
Edit / New String Value menüvel tehetünk bele új értéket.
Kezdés képen az alap értéket határozzuk meg, ami a gomb felirata lesz. Ehhez töröljük ki a Value name mevőz, és a Value data mezőbe írjuk be azt a szöveget amit a gombon szeretnénk látni. Nálam ez Igo8 lett. Ha ezzel megvagyunk nyomjunk egy okot. Az alsó mezőbe be is került egy érték (default) névvel. Ha most bezárjuk az editort, már látható az új felirat, de még mindig a gyárilag programozott program v. funkció indul el.
Létre kell hozni a korábban (default) névvel létrehozott érték mellé egy újabbat, szinén a New String Value menüvel. A Value name mezőbe írjuk be: "open" (idézőjelek nélkül). Majd a Value data mezőbe azt amit szeretnénk, hogy elinduljon. Nálam ez:
"\Storage Card\IGO8\iGO8.exe" (természetesen idézőjelek nélkül). Ha ez is megvan okézzük le, és kész. Program bezárása után a gombra kattintva elindul a program, ha jól adtuk meg az elérési útját.
Mindenkinek jó piszkálgatást! :)

Szakdolgozat

Re
Mit is csináltam ma... Elkezdtem szórakozni a pc bolt adatbázisával, és sajnos rá kellett jönnöm, hogy az objektum-relációs dolog nem egészen úgy működik, ahogy azt elképzeltem így némi komplikáció adótott. Sajnos magyar leírás 0 ilyen szinten, az angolt meg nem 100%-osan értem és így nem találom meg a nekem megfelelő infókat, így már írtam egy forumra is. Remélem ott majd megmondják a pofon egyszerű választ a kérdésre, hogy hogy lehet egy objektum típusát ellenőrizni Oracle alatt.
Elgondokoztam rajta, és beszéltem is Zolival is róla, hogy mi lenne ha feladnánk az objektum-relációt és sima relációs adatbázissal csinálnánk meg a dologt. Valószínáleg nem járna sokkal több gépeléssel és munkával sem, viszont valamilyen szinten meghátrálás lenne... Még gondolkozom rajta, és bízom a forumos gurukban.



Szakdolgozat téren viszont előrléptem, szerintem egy egész nagyot. Sikerült írnom egy butácskább kereső algoritmust. A leírásokban amit Tanár úr küldött szinte mindenhol a Dijkstra algoritmust használják és javasolják. Akinek nem volt alga tárgya, annak röviden a Dijkstra algoritmusról elég azt tudnia, hogy egy gráfban, egy adott pontból megkeresi minden ponthoz a legrövidebb utat. Szemléletesen a képen látszik. Valami hasonlót próbáltam én is lemásolni.
Még persze nem tökéletes, mert az élek, ami alapján a távolságot számolja még mindehol 1-esek. Következő verzióban már muszáj lesz az időt is figyelnie, ötletem van, majd meglátom hogy sikerül kivitelezni, remélhetőleg holnapi postban már pozitív eredményekről számolhatok be. Utána már csak a csomopontokat kell belevinni a játékba, arról még nincs elképzelésem, hogy hogyan, de mivel a megállokhoz nagyon hasonlóan viselkednek, szerintem nem lesz probléma velük.
Gondolkozom az iránytű megfalósításán, eredeti tervekben nem szerepel, pedig érdekes lenne a leprogramozása, már csak azért is oda grafikusan kell valamit alkotni :)

PC bolt projekt, Oracle junior képzés

Re

Mint említettem ma az Adatbázis alapú rendszerek (röviden: aar) tárgyam projektjét mutatom be, a teljesség igénye nélkül.
A tárgy témáját nem nehéz kitalálni. Úgy is lehet rá tekinteni, mint az Adatbázisok folytatása. A téma viszont nem MySql, hanem annál valamivel komolyabb: Oracle. Tanár úr hasonlíta, amivel úgy lehet szédíteni a hozzá nem értőket: "Az Acces olyan mint a bicikli, MySql az autó, az Oracle pedig a repülő". Ezen kívül tanulunk még egy tervezési technikát az úgynevezett SSADM-et. Amit "nem szabad komolyan venni, és nem szabad figyelmen kívül hagyni".
A tárgy teljesítésének feltétel egy projekt munka, amit csapatban kell elkészíteni (van pár egyéni versenyző). A félév első felében a tervezés a már megnevezett technikával, majd az egészet lekódolni. A csapatban 3-an vagyunk. Árpi dokumentál, Zoli és én kódolunk. Indulásnál úgy kezdtünk neki h enyém a felhasználói felület, Zolié az adatbázis, de ez most megfodulni látszik.
Tehát a cél egy PC bolt e-boltos felületének megvalósítása, raktár kezelői funkciókkal és pár plusz funckióval.
Alap funkciónak tekinthető a termékek karban tartása, azok böngészése, felhasználók regisztrálása és a vásárlás lebonyolítása. Ami plusz funkció, az a termékek értékelhetősége és a hozzászólás írása a felhasználók részéről. Ezek olyan funkciók amik megvalósítása nem tünt túlságosan bonyolultnak, mégis érdekesebbé teszik a kész projektet.
Még indulás előtt úgy kerestem csapatot, hogy Oracle alapokon, lehetőleg C# nyelven csináljuk a dolgot, ha már ez a kurzus témája. Oracla és a C#-ot Zoli is támogata és első alkalommal asztali alkalmazásban gondokoztunk, de rá kellett jönni, hogy nem túl életszerű egy e-bolt asztali alkalmazás ként, ekkor jött az ötlet, hoyg akkor miért nem csináljuk asp.net felületen. Nem sokkal bonyolultabb, mint egy desktop gui (grafikus felhasználó felület), de mégis hátránya, hogy még egyikünk se dolgozott benne, de még csak nem is tanították.
A követelmény specifikáció, amit már vázoltam viszonylag gyorsan megvolt, és a gyakvezérünk is értékelhetőnek találta, tehát következett az adatbázis tervezése. Amiben ismét rá kellett jönnünk, hogy a hagyományos relációs adatbázis (~táblázatokban való matatás) nem túl hatékony, jobb lenne valami objektum szerű, mert a termékeknek sok közös tulajdonsága van, amit jó lenne együtt kezelni. Gyakvezető tanácsára elkezdtem objektum-relációs témában nézelődni és mivel nem tünt (hangsúlyozom tünt) túl bonyolultnak ezt határoztuk meg alapnak.
Tehát így indult a projekt. Fejlesztő környezetről nem sok ismeret, adatbázisról szinte 0 ismeret, de hát merjünk nagyot álmodni.
Az sql-be elég jól belejöttem, annyira, hogy a tervek után nem sokkal el is készítettem a típusokat, táblákat, szekvenciákat, triggereket.
Közben csináltuk a projekt többi részének tervezését, amiben szintén benne van pár óra munka.
Szerdán le kell adni a dokumentációkat, amiket Árpi a hétvégén fog megcsinálni.
Én jelen pillanatban - blogíráson kívül - igyexem összekapcsolni az adatbázis az asp-s felülettel. Vannak belőle problémák, de csak h leküzdhessük őket.

Emellett még jelentkeztem egy Oracle junior képzésre. Az előadások csütörtökönként este 6-tól vannak a BME-n. Mivel nem utazgathatom fel on-line próbálnám követni, de a közvetítéssel vannak problémák. Így általában egy hét késéssel tudom megnézni az előadásokat. Igyexem követni, hátrányom nem származhat belőle, sőt :)

Cantata, AutoCad, Szakdolgozat

A mai nap egy kis Cantataval indult. Befejeztem vagy inkább újra írtam a kötelező programom. Suliban megcsináltam már, de valamiért itthon nem akart menni normálisan így újra kezdtem. Másodszor már nem volt nehéz :) A feladat maga sem volt túl nehéz, két képet kellett egyre illeszteni, ami Gimpben v. PS-ben két perc kb - különösen, hogy az egyik kép háttere fehér - viszont Cantataban nem olyan triviális. Ha lezárult a feltöltési idő, majd felteszem a blokkvázlatát, nagyon szép :)

Cantata után befejeztem a Számítógéppel támogatott tervezés című tárgyra is a beugró "kötprogot". AutoCadben kell elkészíteni egy tervrajzot. Én egy Honda Dio robogó dugattyút kaptam aputól, azt rajzoltam le. Ez a kép nem végleges változat. Erre még tettem sraffozást (bevonalkáztam a süllyesztéseket), berajzoltam a méretezést és tettem neki egy keretet is.

A délután többi részében igyekeztem a szakdolgozattal foglalkozni. Azt hiszem teljesen elkészült az adatbázis elkészítéséhez szükséges felhasználói felületek. Működnek is. Mindez annak ellenére, hogy így estefelé eszméltem arra a - másoknak biztosan nyilvánvaló - tényre, hogy a közlekedében vannak hétköznapok, munkaszünetinapok és ünnepnapok. Szerencsére ennek lekezelése már nem volt problémás, csak egy tömbbel kellett kiegészíteni a rendszert.

A rendszer újabb képességei:

• Időpontok felvétele, különböző menetnapokra is
• Csoportok letrehozása, szerkesztése
• Koordináták felvétele megállókhoz, megálló csoportokhoz, érdekes helyekhez

Ezeken kívül a belső szerkezeten is módosítottam egy picit, de elenyésző módon.

A következő lépés egyrészt a rendszer átültetése PDA-ra. Ez inkább csak GUI-val való játék, mert sok újdonságot már nem kell belevinnem. Ami nehezebb lesz az a keresés megvalósítása. Elkezdtem olvasni a cikket, amit Tanár úr küldött a témával kapcsolatban. Nem hosszú, de elég lesz megemészteni és átültetni az én redszeremre.

Holnap valószínűleg az Adatbázis alapú rendszerek tárgyam projektjével foglalkozom. Valszeg írok majd arról is.

Szakdolgozat

Re

Mint írtam lefogom írni a jelenlegi munkáimat. Ma mondjuk a szakdolgozatomat.
Tehát a szakdogám mobilon futtatható menetrend alkalmazás, extra funkciókkal. Először úgy indult a dolog, hogy folyamtosan az orrom előtt mentek el a vilik és buszok Szegeden. Gondoltam kellene egy ilyesmi program a telefonomra. Aztán jött a szakdoga választás és gondoltam, hogy ez talán jó lenne.
Tanár úr azt mondta és végül is egyet értek vele, hogy amit én elképzeltem Java MIDP-ben megvalósítani az munkában elég szakdogának, de látványilag elég kevés. Tanár úr android alapú rendszert javasolt volna, de mivel a készülékek elég húzós árban vannak inkább egy Windows Mobile rendszer néztem ki magamnak. Némi probléma volt is az eszköz beszerzésével (Mitac Mio A701), de ez is megoldódott.
Tehát a rendszert WM5-re írom, Microsoft .NET CF 3.5-ös (Compact Framework) környezetben C# nyelvben. Visual Studiot használok fejlesztő környezetnek, nagyon barátságos, gond nélkül együtt működik a Mio-val és az emulátorral is.
A rendszer kiemelkedik egy hagyományos papír alapú menetrendből, mert beleveszek hely meghatározást is. Tárolom a megállók helyét, érdekes pontok helyét így az alkalmazás ezek figyelembe vételével tesz javaslatot arra, hogy a felhasználó melyik megállóba menjen. (most jutott eszembe, lehet kéne iránytűt is beletenni :D)
Nem csak a mobilra készülő alkalmazást kell megírni, hanem egy asztali programot is, amivel a menetrendet lehet szerkeszteni, és magát az adatbázist létrehozni.
Eddig volt egy kezdetleges struktúrám, ami több sebből is vérzett.
Hétfő óta fellelkesültem, és újra írtam az egészet, szerencsére sok mindent már nem kellett kitalálni, szal inkább csak kódolás volt, így ma estére elkészült az asztali program olyan szinten, ahogy körülbelül eddig is állt. Persze további fejlesztés szempontjából sokkal átláthatóbb, dokumentáltabb, következetesebb, mint eddig volt.
Az asztali alkalmazásban eddig a következő funkciók vannak meg:

• Járatok, megállók, jármű típusok, megálló csoportok, érdekes helyek elmentés fájlokba a memóriában lévő strukturából, illetve fájból visszatöltés a megfelelő struktúrába
• Járatok , megállók, jármű típusok létrehozása, azok egymással összekötése, magyarán a menetren elkészítése.

Ez így elsőre persze nem sok és lehet kérdezni, hogy mit csináltam ezen 4 napig... Igyexem...

Első bejegyzés

Üdv annak aki erre tévedt!

Bár az oldal első sorban nem rajongó tábor gyűjtését szolgálja, sőt mi több valószínűleg anti-rajongó tábor kialakulása a valószínűbb, azért mégis úgy illik, h köszöntöm az erre járót.
Tehát, mint a bemutatóban mérnök informatikus BSc hallható vagyok, és az blog szakmai szempontból tartalmaz majd postokat.
A posztok stílusát és szakmaiságát tekintve valahol az átlag felhasználó és igazi programozó között helyezkedik el. A programozás gyakorlata sokkal jobban foglalkoztat, mint az elmélete, ezért elsősorban érthető, működő kódokra törexem, és nem foglalkozom a 16. kapcsoló és a 22. paraméter jelentésével, aminek speciális esetekben van értelme. Persze szeretnék olyan szintre fejlődni, hogy ismerjem ezeket is, de nem tartom célszerűnek elveszni a részletekben, ráérek ha már a nagy egészet valamilyen szinten átlátom.
Tudnék még regélni, de majd...
Kvetkező pár bejegyzésemben valószínűleg az éppen folyó "projektjeimről" fogok beszámolni.