Tóth Tamás, EWYXK4 BME-VIK Automatizálási és Alkalmazott Informatikai Tanszék Konzulensek: Dávid Zoltán, Gincsai Gábor Budapest, tavaszi félév

Bevezető  A modern világ egyik problémája az egészséges étkezés megoldása  A projekt célja ennek segítése:  Tudástár létrehozása  Étrendkészítés  Kézi összeállítás, kalória számlálás  Automatikus generálás (személyre szabott)  Közösség kialakítása

Kutatás  Meglévő megoldások (táblázatok, diéták)  Tartalomkezelők (Wordpress, Drupal, Joomla)  Keretrendszerek (Zend, Symfony, Yii)  Kiszolgálók:  DB: MySQL, MSSQL, Oracle, PostgreSQL  NoSQL: APC, Memcache, Repcache, Redis, Cassandra, Riak, MongoDB  Web: Apache, nginx, lighttpd, Varnish  Verziókövetők: svn, hg, git

Saját keretrendszer 1/2  A szükséges mélységig általánosított egységek, a kiszolgáló környezet bonyolultságának elfedésére, alkalmazás ősosztályok a szabványos felépítéshez  Moduláris alkalmazás felépítés:  Komponensek: fő vezérlők teljes MVC felépítéssel  Modulok: egységbe zárt kisebb részek  Beépülők: segéd funkciók

Saját keretrendszer 2/2  Egységtípusok:  Application, ClassLoader, Config, Error, Exception, Log, MVC, Request, Response, Router, Language, Validator, Cache, Resource, Session, User, ACL, Mail, Export, Pattern  Statisztika:  20 névtér, 63 osztály, 358 metódus, 4441 sor kód  Részek:  application, batch, common, framework, media, resource  + tools, vendor

Étrendkészítő webalkalmazás 1/5 Alkalmazások: portal, user-api, diet-api *LVS = Linux Virtual Server – Load Balancer, Terhelés elosztó szerver

Étrendkészítő webalkalmazás 2/5  Entitások:  Kategóriák, címkék  Alapanyagok, élelmiszerek, receptek  Felhasználók, üzenetek  Ajánlások, értékelések  Étrendek  Statisztika:  38 névtér, 96 osztály, 352 metódus, 6542 sor kód

Étrendkészítő webalkalmazás 3/5 Nyitólap

Étrendkészítő webalkalmazás 4/5 Étrend

Étrendkészítő webalkalmazás 5/5 További felületek

Mobil optimalizálás 1/3  Az új generációs okos telefonokra és tabletekre optimalizált verzió, mely egyszerűbb felülettel, kényelmes használatot tesz lehetővé  A kijelző mérettől függő, annak változására reagáló webalkalmazás felület kialakítása, melyet ugyanazok a szerverek ki tudnak szolgálni, mint az asztali változatot

Mobil optimalizálás 2/3 Étrend mobil méretben

Mobil optimalizálás 3/3 A lenyíló menü mobil nézetben

Tesztelés, élesítés  PHPUnit + Codeception tesztek:  Egység, API és szimulált böngészős elfogadási tesztek  Élesítés:  Verziózott csomag előállítása  Most egyszerű ellenőrzött másolás (ütemezve)  Később központi irányítású, közel párhuzamos idejű élesítés minden kiszolgálón

Bírálat kérdései 1/2 „A követelményekkel foglalkozó fejezetben hangsúlyozza a teljesítmény és az elosztott működés fontosságát, a szerver azonban mégis használ session- öket. Mellőzni tudná-e a webes és/vagy az API-n hívható szerverben a session-ök használatát? Hogyan? Ez milyen előnyökkel járna?”  Főként felhasználói adat gyorstár  Tehermentesít: nem kell mindig auth, a Frontend réteg direktben elérheti – kihagyható az API  Elhagyható lenne mindenhonnan, így teljesen állapotmentes lenne a kiszolgálás, ugyanakkor ezáltal több kérésre és plusz paraméterekre lenne szükség (lassabb és nagyobb támadási felület)

Bírálat kérdései 2/2 „A dolgozat kiemeli a gyorsítótárazás lehetőségét. Ezt melyik komponensben oldja meg? A webalkalmazásban vagy az API-n hívható szerverben? Melyik megoldás milyen előnyökkel jár?”  Mindkettő esetén van APC opcode cache: kód futás, konfiguráció, nyelvesítés, előgenerálás  API: adatbázistól lekérdezett adatok saját és/vagy közös gyorstárba írása – DB tehermentesítés  Frontend: közös cache olvasása – API tehermentesítés  CDN: statikus fájlok kiszolgálása – dinamikus kiszolgálók tehermentesítése, elérés gyorsítása

Köszönöm a figyelmet!