[Erdeklodes] Webes alkalmazas TrinityCore - hoz

Indította Shyro, 2015 szeptember 22, 04:17:22 DÉLUTÁN

Előző téma - Következő téma

Shyro

Az elmult napokban ugye felvetettem ezt a temat, de bennem is csak idovel kezdett pontosabban megfogalmazodni, hogy mit is szeretnek. Ezert lehetseges, hogy nem volt annyira vilagos a kezdemenyezes, mint ahogy szerettem volna. Ezert szeretnek irni egy osszefoglalot, hogy mire is gondolok pontosan.

Esettanulmany:

Mielott barmi szo esne a viziorol mutatnek egy peldat, ahol hasonlo API - t alakitottak ki, mint amire en is gondolok, es a felhasznalasa is hasonlokeppen tortenik, mint amire en is gondolok. Ez egy eszkoz, megpedig a Docker. Aki meg nem hasznalta az egy minimalis koltsegu virtualis gepkent tekinthet ra (mielott barki megkovezne erte, a Docker eseten nem beszelhetunk virtualizaciorol, de igy konyebb elkepzelni). Az eszkoz segitsegevel tudsz a kulvilagtol (host) teljesen izolalt kornyezetet, container - eket letrehozni. En peldaul kulonbozo nyelvekben irt programok tesztelesere hasznalom, igy nem kell a host gepre feltelepitenem 10 darab futtato kornyezetet, forditot. Ugy tudok haskell es javascript kodokat is tesztelni egyszerre, hogy a host gepemre nincs felteve se Node.js se Haskell fordito. Ezt a szerepet is kezdi kinoni, es egy teljes szoftvercsalad epul kore, meg tobb lehetoseggel.

Van egy CLI - je, amivel tudsz tobbek kozott container - eket letrehozni: docker run -i -t ubuntu /bin/bash
A parancs vegrehajtasa igazabol a Docker daemon - nek fog szolni, ami figyel a hatterben es ha kell vegrehajtja a parancs altal kiadott feladatot. A Docker csapat ennek a Docker daemon - nak adott egy API - t is, ami rengeteg mindent ad:

  • Az osszes funkcionalitas, ami a CLI - ben megtalalhato, elerheto az API - n keresztul is
  • Sokkal konyebben valik programozhatova a Docker menedzselese
  • A Docker - t tavolrol is el lehet erni es akar egy masik gepen futo szoftver is vezerelheti
  • Szinte teljesen mindegy, hogy milyen nyelven programozol, az API - t meg fogod tudni szolitani barmely nyelvben
  • etc...

En pl. nem voltam elegedett a NPM package - ekkel, amiket eddig irtak a Docker vezerlesehez az API - n keresztul, ezert elkezdtem egy sajat package - en dolgozni, amiben egy Docker container letrehozasa mar csak igy nez ki:
var container = new Container('image_name');
container.run({ ...options... }).then((output, error) => ...);


Azt, hogy ilyen egyszeruen, ennyire programozhatova valt a Docker, akar Node.js - en futo JavaScript alkalmazas szamara, az az API - nak koszonheto. Ha nem lenne az API, az, hogy ez a kod egy masik gepen fusson elkepzelhetetlen lenne, illetve teljesen mas megoldasra lenne szukseg (string - konkatenalgatasa egy exec() fuggveny szamara, hogy parancsokat futtassunk).

Ami meg szinten szepen latszik ebbol a peldabol az az, hogy a Docker ugyanugy tarol adatokat, viszont arrol, hogy miket, hogyan es miert, neked mint felhasznalonak (CLI) es mint programozonak (API) fogalmad sincs. Mert nincs is ra szukseged. Eleg baj lenne, hogyha egy container letrehozasanal azzal kellene foglalkoznom, hogy milyen fajlokat kell atirnom, vagy kicsit a jelen esetunkre visszakanyarodva, milyen SQL lekerdezeseket kellene kiadnom.

Vizio:

Egy, a TrinityCore - hoz irt API minimum ugyanezeket tenne lehetove, mint amiket a Docker eseten felsoroltam. Az, hogy en ezt mikent hasznalnam fel, azt mar az eddigi posztokban probaltam reszletezni, de fussunk neki meg egyszer. Egy API a TDB felett lehetove tenne azt, hogy barmely nyelven irj programokat, amelyek - addig amig van internet kapcsolatod - barhol futhatnak. A barmely nyelven irt, barhol futo program nem tudom elegge nyomatekositani, hogy mennyire eros erv. Aki alkalmazast szeretne irni a TrinityCore - hoz, az onnantol kezdve, hogy ki tud kuldeni egy HTTPS  kerest es ossze tud allitani egy JSON - t, nyert ugye van.
Ez a megoldas azt is lehetove tenne, hogy adott szerveren jatszo jatekos sajat maganak irhatna egy mini alkalmazast, amivel a sajat karakterenek aktualis adatait lekerdezi, vagy a szerver publikus adatait. Kerdes, miert irna valaki ilyet? Csak egy pelda akart lenni.
Egy JavaScript - hez irt SDK - val (itt csak egy wrapper osztalykonyvtarra gondolok a keresek fole), egy single - page application alkalmazasban, peldaul egy uj karakter letrehozasa idaig egyszerusodne:
...
CharacterManager.createCharacter({ ...options... });
...

(Az alkalmazas adja a logikat, hogy mikor hozol letre uj karaktert, az SDK adja a CharacterManager osztalyt es a keres kikuldesenek logikajat, az API adja az uj karakter letrehozasanak lehetoseget es biztositja, hogy adott SQL lekerdezes lefusson. Az alkalmazasodnak goze sincs, hogy a karakter mikent jon letre es nem is kell tudnia. Az alkalmazas irojanak az SDK - t kell ismernie, es tudnia hasznalnia es az alkalmazas logikara koncentralnia. Csak ezzel egyszerusodhet az alkalmazasfejlesztes.)

Ennek a megvalositasa jelenleg elkepzelhetetlen. Ilyen alkalmazasok jelenleg nincsenek. Minden alkalmazas ami eddig szuletett vagy a host gepen fut, vagy PHP altal van kiszolgalva es kozvetlenul buzeralja az adatbazist. Az, hogy nem csinal e valami baromsagot az az alkalmazas irojatol fugg.

Mar rengeteg helyen lattam ilyen megoldast (Facebook API, etc...), a Docker csak 1 pelda a sok kozul. Lattam is mar ilyen megvalositast, sokkal de sokkal tobb adattal az adatbazisban, sokkal bonyolultabb szituacioban. Jol mukodik, kivitelezheto, es a vegeredmeny a konnyu alkalmazasfejlesztes. Ahhoz, hogy TrinityCore - hoz normalis alkalmazasok szulethessenek, szerintem erre van szukseg.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Ez az bonyolitsuk még tovább, nem használhatunk Docker-t vagy akármilyen cél programot, mert a PHP+Mysql minden szerveren elérhető, ezt kell használni.

Ha egy valamit biztosan nem lehetne API-n keresztül csinálni az a Karakter generálás, hogy ezt meg lehesen csinálni az API-t a Trinity Cora-ba kéne implementálni.

Ezt mondom, ez egy konkrét rendszer ismert ne áltlánositsd!, a Character DB-be például nagyon minimálisan lehet belenyulkálni, mert az aktív részét a Core a memóriába tárolja, amit nem lehet:
- Item adás bárhogyan, ezzel a levél küldés is kilőve.
- Guildek modositása bárhogyan.
- Online karakternél a teljes character tábla modositása, ha Offline akkor lehet.

Jó lenne ha nem általánositanál tovább ez itt a Trinity Core a DB ismert, a müködése ismert a probléma adott:

- Questek szerkesztése egyszerübben.
- Smart AI készitése.
- Creature és Gameobject-ek szerkesztése.
- Loot-ok kezelése (creature,gameobject,reference,item,spell)
- Conditionok készitése
- Spell Proc Eventek kezelése
- Game Event táblák kezelése.

Ha ezt a 7 dolgot már tudja a program gyakorlatban is kliens oldalon akkor lehet tovább lépni.

Shyro

Egyszeruen nem tudom hova tenni azt, amirol beszelsz. Nincs koze ahhoz, amit irtam. A peldakat amiket meg emlitettem azok egyszeruen peldak, nem kell beloluk hibas kovetkeztetest levonni. Internal tablakat meg nyilvan nem szeretnek felulirni, de olyan adatokat nincs is ertelme nyilvanossa tenni. Azt meg nyilvan figyelembe kell venni, hogy az adatbazisban tortent valtozasokat a Core mikent, mikor es egyatalan fogja e figyelembe venni. A TrinityCore - nak es az API - nak nem kell tudniuk egymasrol, annyi a kozos bennuk, hogy egy adatbazison dolgoznak. De mint mondtam, nem szeretnek alkalmazasbol karaktert letrehozni, az egy pelda volt. Irhattam volna ItemManager.create() - t is, a mondandom szempontjabol teljesen mindegy volt.
Illetve, amiket felsoroltal:
Idéz- Questek szerkesztése egyszerübben.
- Smart AI készitése.
- Creature és Gameobject-ek szerkesztése.
- Loot-ok kezelése (creature,gameobject,reference,item,spell)
- Conditionok készitése
- Spell Proc Eventek kezelése
- Game Event táblák kezelése.
...ezekkel meg nem akarok foglalkozni. Mar leirtam tobbszor, hogy nem akarok adatbazis szerkeszto alkalmazast kesziteni. Nem ertem, hogy miert nem lehet ettol eltekinteni.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Igazad van ötletem sincs mit is akkarsz fejleszteni.

De inkább becommitolom a gyerek TC-s PHP API-jába a módositásokat.

Zoltan

https://github.com/Plexis/Wowlib  ezt probaltad mar?

igaz 3 eve nem volt updatelve, de  picit jobban nez ki mint  pistike elso  wowos account managere :)

nem sokaig tart kiboviteni..

a kerdes hogy erdemes -e ezzel szenvedni, van-e  eleg hely a piacon?
Ne erts felre de 8-9 evvel ezelott  jo kis gondolat lett volna.. :)  de most mar inkabb azt latjuk, hogy egyre kevesebb ember foglalkozik ezzel, kevesebb ember jatszik,  egyre nehezebb kovetni az uj wow kiegeszitoket..



Shyro

@Zoltan

Meg nem lattam, de koszi, hogy linkelted. Nekem egy sima wrapper/helper library - nak tunik az adatbazis fole, ami nem rossz, de az, hogy 3 eve latott utoljara commit - ot az tenyleg kiabrandito. Az elozo beszelgeteseknek annyi ertelme mindenkeppen volt, hogy az megfogalmazodott bennem, hogy a fuggosegeket erdemes minimalisan tartani. Ennek az eredmenye lett az, hogy erdemes lenne egy sajat API - t implementalni es azt tisztessegesen megirni/karbantartani. Az azt hasznalo alkalmazasokat pedig csak utana.

Nem erzem szenvedesnek a dolgot, mert erdekel a tema. Az sem zavar, ha senki nem fogja hasznalni. Nyilvan azt fel lehet hozni, hogy fordithatnam masra az idoben, ami esetleg meg penzben is megterul, ilyesmi. De ez nalam az n + 1. hobbi szintu elfoglaltsag, ami meg belefer ugy erzem. Ha esetleg megis felkapottabb lenne a dolog, mint aminek most tunik, akkor meg novelni kell a prioritasat a projektnek. Csak agilisan.  :)

Most egy ideje nem irtam a forum - ra, de az nem azt jelenti, hogy ennyi volt. Mivel innen nem kaptam meg visszajelzest a nyelvek/technologiak teren, ezert magam kezdtem el utanajarni. Elso sorban Ruby - val kezdtem el ismerkedni, End-to-End tesztelesnel kerult a kepbe, ugyanis a JavaScript - es eszkozok nem voltak tul meggyozoek. (watir/cucumber/rspec kombinacio eddig meggyozott) Tovabbra is opcio a nyelv, framework/library (elnezest, gem - ek) meg van dogivel hozza. PHP - rol is erdeklodtem, ott a Laravel tenyleg jo. JavaScript nalam meg adott, ott kezdtem el korbenezni eszkozok teren, szinten van mire epiteni.

Az API - nak szerintem ket sarkalatos pontja van. Az egyik, hogy a DB felett egy olyan reteg legyen, ami azert elkapja a hibas adatokat, ne nagyon engedje szetbaszni az adatbazist, mar elnezest. Illetve az autentikacio es a biztonsag. Ezek mar leragott csontok, nem is akarom ujrafeltalalni a kereket, de ket kattintassal se letudni a dolgot. Ezeknek ugy erzem, hogy erdemes utanajarni, rengeteg jo anyag van arrol, hogy hogy is erdemes ezt csinalni, az pedig ido. Igy jelenleg itt tartunk.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

Zoltan

Idézetet írta: Shyro Dátum 2015 október 15, 12:22:16 DÉLELŐTT
@Zoltan

Meg nem lattam, de koszi, hogy linkelted. Nekem egy sima wrapper/helper library - nak tunik az adatbazis fole, ami nem rossz, de az, hogy 3 eve latott utoljara commit - ot az tenyleg kiabrandito. Az elozo beszelgeteseknek annyi ertelme mindenkeppen volt, hogy az megfogalmazodott bennem, hogy a fuggosegeket erdemes minimalisan tartani. Ennek az eredmenye lett az, hogy erdemes lenne egy sajat API - t implementalni es azt tisztessegesen megirni/karbantartani. Az azt hasznalo alkalmazasokat pedig csak utana.

Nem erzem szenvedesnek a dolgot, mert erdekel a tema. Az sem zavar, ha senki nem fogja hasznalni. Nyilvan azt fel lehet hozni, hogy fordithatnam masra az idoben, ami esetleg meg penzben is megterul, ilyesmi. De ez nalam az n + 1. hobbi szintu elfoglaltsag, ami meg belefer ugy erzem. Ha esetleg megis felkapottabb lenne a dolog, mint aminek most tunik, akkor meg novelni kell a prioritasat a projektnek. Csak agilisan.  :)

Most egy ideje nem irtam a forum - ra, de az nem azt jelenti, hogy ennyi volt. Mivel innen nem kaptam meg visszajelzest a nyelvek/technologiak teren, ezert magam kezdtem el utanajarni. Elso sorban Ruby - val kezdtem el ismerkedni, End-to-End tesztelesnel kerult a kepbe, ugyanis a JavaScript - es eszkozok nem voltak tul meggyozoek. (watir/cucumber/rspec kombinacio eddig meggyozott) Tovabbra is opcio a nyelv, framework/library (elnezest, gem - ek) meg van dogivel hozza. PHP - rol is erdeklodtem, ott a Laravel tenyleg jo. JavaScript nalam meg adott, ott kezdtem el korbenezni eszkozok teren, szinten van mire epiteni.

Az API - nak szerintem ket sarkalatos pontja van. Az egyik, hogy a DB felett egy olyan reteg legyen, ami azert elkapja a hibas adatokat, ne nagyon engedje szetbaszni az adatbazist, mar elnezest. Illetve az autentikacio es a biztonsag. Ezek mar leragott csontok, nem is akarom ujrafeltalalni a kereket, de ket kattintassal se letudni a dolgot. Ezeknek ugy erzem, hogy erdemes utanajarni, rengeteg jo anyag van arrol, hogy hogy is erdemes ezt csinalni, az pedig ido. Igy jelenleg itt tartunk.

Shyro

Kiegesziteskent erdemes elolvasni ezt a posztot is:
https://community.trinitycore.org/topic/12112-the-tc-family-has-a-new-member-aowow/#comment-76547

Az API implementalasara a JavaScript nyelv mellett dontottem, Node.js platformon persze. Igy elkezdtem gondolkodni a kivitelezesen:
- MySQL drivernek ezt neztem elsore: https://github.com/felixge/node-mysql Meg sosem hasznaltam, igy nem tudom, hogy milyen. Elso ranezesre jonak tunik abbol a szempontbol, hogy van valamennyi hasznalhato dokumentacio, a projekt aktiv, az issue - kra reagalnak. Egy probat meger. Az egyetlen ami zavar az a callback hivasok. Ezt nehez atlatni, ronda kodhoz vezethet, stb. Igy ekore mindenkeppen szeretnek egy wrapper - t irni, amivel lehetne a package - t async fuggvenyekkel hasznalni.
- Web framework - nek a mar emlegetett Koa.js - t fogom hasznalni. Ez egy nagyon minimalis package, viszont rengeteg middleware/plugin talalhato hozza. Tamogatja az async fuggvenyeket. Nem ismerem az osszes middleware/plugin - t hozza, ez konkretan feladat: megtalalni azt a minimalis stack - et, amire szuksegunk van es jol hasznalhato. Pl. az autentikacio kezeleseben meg nem vagyok biztos, hogy sajatot lenne e erdemes irni vagy behasznalni valamit.
- Mint projekt fuggosegeket a babel - t es a gulp - t mindenkeppen be akarom hasznalni. Azaz szeretnem a legujabb JavaScript feature - oket hasznalni, es automatizalni a folyamatokat. Pl. a kod stilus ellenorzeset eslint  - el. Bar ezek mar inkabb development specifikus fuggosegek, nem a feladathoz kapcsolodnak, erdekesek lehetnek abbol a szempontbol, hogy szeretnek egy olyan projektet osszetenni, amivel a fejlesztes minel gordulekenyebb, meg akar az uj fejlesztok szamara is. Automatikus kod ellenorzes egy git hook - kent megvalositva pl. rengeteget segit. Ezt mondhatom, hogy tapasztalatbol tudom, ezekre erdemes odafigyelni.

Ezeket azert irtam le, hogy legyen lenyomata annak, hogy fejben hol tartok. Illetve tovabbra is varom a hozzaszolasokat, akar kiegesziteseket, akar megcafolasokat, vagy akar aki csak egy egy pont irant erdeklodne, vagy technologia irant.

Udv,
Shyro
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Idézetet írta: Shyro Dátum 2015 november 17, 01:04:07 DÉLUTÁN
Kiegesziteskent erdemes elolvasni ezt a posztot is:
https://community.trinitycore.org/topic/12112-the-tc-family-has-a-new-member-aowow/#comment-76547

Az API implementalasara a JavaScript nyelv mellett dontottem, Node.js platformon persze. Igy elkezdtem gondolkodni a kivitelezesen:
- MySQL drivernek ezt neztem elsore: https://github.com/felixge/node-mysql Meg sosem hasznaltam, igy nem tudom, hogy milyen. Elso ranezesre jonak tunik abbol a szempontbol, hogy van valamennyi hasznalhato dokumentacio, a projekt aktiv, az issue - kra reagalnak. Egy probat meger. Az egyetlen ami zavar az a callback hivasok. Ezt nehez atlatni, ronda kodhoz vezethet, stb. Igy ekore mindenkeppen szeretnek egy wrapper - t irni, amivel lehetne a package - t async fuggvenyekkel hasznalni.
- Web framework - nek a mar emlegetett Koa.js - t fogom hasznalni. Ez egy nagyon minimalis package, viszont rengeteg middleware/plugin talalhato hozza. Tamogatja az async fuggvenyeket. Nem ismerem az osszes middleware/plugin - t hozza, ez konkretan feladat: megtalalni azt a minimalis stack - et, amire szuksegunk van es jol hasznalhato. Pl. az autentikacio kezeleseben meg nem vagyok biztos, hogy sajatot lenne e erdemes irni vagy behasznalni valamit.
- Mint projekt fuggosegeket a babel - t es a gulp - t mindenkeppen be akarom hasznalni. Azaz szeretnem a legujabb JavaScript feature - oket hasznalni, es automatizalni a folyamatokat. Pl. a kod stilus ellenorzeset eslint  - el. Bar ezek mar inkabb development specifikus fuggosegek, nem a feladathoz kapcsolodnak, erdekesek lehetnek abbol a szempontbol, hogy szeretnek egy olyan projektet osszetenni, amivel a fejlesztes minel gordulekenyebb, meg akar az uj fejlesztok szamara is. Automatikus kod ellenorzes egy git hook - kent megvalositva pl. rengeteget segit. Ezt mondhatom, hogy tapasztalatbol tudom, ezekre erdemes odafigyelni.

Ezeket azert irtam le, hogy legyen lenyomata annak, hogy fejben hol tartok. Illetve tovabbra is varom a hozzaszolasokat, akar kiegesziteseket, akar megcafolasokat, vagy akar aki csak egy egy pont irant erdeklodne, vagy technologia irant.

Udv,
Shyro

Hajrá.

Powered by EzPortal