INSANE v2

Mi az a v2?

A v2 egy teljesen újraírt motor az insane alá. Ez azt jelenti, hogy a backend és a frontend teljesen nulláról van újraírva az új kor technológiáinak megfelelően. Az esetlegesen újrafelhasznált kódok teljesen át lettek nézve sorról sorra és ahol kellett javítva lett.

Az újraírás folyamán az elsődleges szempont a sebességoptimalizálás. Ebből kifolyólag bizonyos kompromisszumokat meg kellett kötni. Ezekről részletesen lejjebb lehet olvasni.

További cél volt a jó skálázhatóság is és a gyors fejleszthetőség is, az ismert modern technológiák minél jobb kihasználásával együtt (MVW pattern, frameworking, stb.).

A v2 koránt sincs kész, folyamatos fejlesztés alatt áll. Ez jelenti új funkciók bevezetését, valamint a már megírtak folyamatos modernizálását, karbantartását is.

Miért van rá szükség?

Az rövid időn belül biztossá vált, hogy a régi rendszer (v1) nem foltozgatható örökké. Olyan elavult dolgokkal van tele, amelyeket javítani nem lehet, csak cserélni. A háttérben elkezdtük az egyes funkciók modularizálását, hogy legalább azok rendben legyenek. Aztán ez a kód elkezdett egyre kiforrottabbá válni és elért egy olyan szintre, amikor már megérte külön rendszerként foglalkozni vele, ekkor vált v2-vé. Miközben a háttérben folyamatosan cseréltük ki a v1 rendszert, elkezdtük írni az alapoktól a teljesen új "framework"-öt is. Alapvetően sokkal jobb felhasználói élményt nyújt, stabilabb, biztonságosabb és jobban fejleszthető lesz, így mindenki jobban jár vele, ugyanakkor a régi rendszer nyűgjeit folyamatosan magunk mögött hagyhatjuk.

Hol tartunk?

A modulok nagy része kész vagy majdnem kész, ez azt jelenti, hogy a modulfejlesztésről áttevődik a hangsúly a controller és view fejlesztésekre. Egyre több oldal használható már. A váz elkészülte után a fejlesztési verzió már valóban használható is. Az alap torrentezési tevékenységek már gond nélkül elvégezhetők, sőt, ezek már több, mint féléves tesztidőszakon is túl vannak. Folyamatosan készülnek a kiegészítő funkciók oldalai is.

Elsődlegesen a felhasználói oldalak készülnek el. Ehhez persze a kötelező moderátori oldalak is azonnal elkészülnek. Ezen oldalak nagy része már használható, bár némelyik még hiányzik. Elsődleges cél, hogy a v1-en már működő funkcionalitás elérhető legyen, természetesen felújítva, modernizálva vagy akár teljesen újragondolva, ahol a régi rendszer elavult. Ezek az oldalak jórészt már komoly tesztelésen is átestek, így biztonságosan használhatók is.

Ezek után jönnek a kiegészítő funkciók oldalai (mozi bemutatók vagy a rádió oldala pl.). Persze folyamatosan készülnek a fontosabb moderátori és egyéb staff felületek is. Például moderálni már lehet a torrenteket, a kéréseket vagy akár a hozzászólásokat, fórumot is v2-n is.

Folyamatosan kerülnek be új felületi elemek és új skinek is.

2017. február elsején publikussá tudjuk tenni a fejlesztési verziót.

Persze a fejlesztések sosem fogynak el, akár új funkcionalitásokról, akár a régiek felújításáról legyen szó.

Hogyan készül? Kik segítenek?

Az oldal direkt fejlesztése nagyon szűk körű, nem felhő alapú fejlesztésre kell gondolni. Ennek van előnye és hátránya is. Előnye, hogy a kód egy stílusú és jól felépített, nem keveredik benne többféle kódolási stílus az egész szerkezete egységes. Nincs szükség állandó branchelésre és migrálgatásokra. Ugyanakkor emiatt kevésbé is halad.

Verziózásra SVN-t használunk. Gondolkoztunk GIT-ben is, de nem indokolta semmi, hogy átálljunk.

Szerencsére tesztelési oldalról nagyon sokan segítenek és remek tanácsokkal, hibajelzésekkel segítik a fejlesztéseket. Ugyanígy sokan és szívesen ötletelnek vagy jeleznek hibát a v1 alapjain, hogy a v2-ben már sokkal jobb legyen.

Ezúton köszönjük mindenkinek, aki csak egy jó ötletet vagy egy elgépelési hibát is jelez nekünk az oldal fórumán!

Mit "loptunk"?

Alapvetően mindent mi magunk írtunk meg. Néhány ötletet, jól bevált megoldást ellestünk más oldalakról (nem feltétlen torrent oldalakra kell gondolni), de kódot sehonnan nem vettünk át. Nem akartuk mindenhol feltalálni a spanyol viaszt, ezért pár okosságot (kisebb módosításokkal) átvettünk vagy felturbóztunk.

Skineket terveztünk mi is, de vannak tőlünk jóval nagyobb tehetségek UX/UI design területén, így kész, free (ingyenes) webtemplate-eket felhasználtunk, és a jövőben is fel fogunk használni skinezéshez.

Ha valami visszaköszön, ami ismerős máshonnan, és úgy érzed jogtalanul használtuk azt fel, mindenképp keresd a staff-et!

A backend

A rendszer hátulja továbbra is php. Ennek több oka is van. Egyrészt a php nyelv sokat fejlődött az utóbbi időben, másrészt a backward compatibility miatt is szükség volt rá, harmadrészt pedig ehhez a nyelvhez volt kellő szaktudás.

Backward compatibility

Mivel a motor teljes újraírása óriási munka, úgy döntöttünk, hogy bizonyos elkészült elemeket a már futó rendszerben is használni akarunk. Egyrészt tesztelési, másrészt modernizálási célokkal. Emiatt a már futó rendszer mögött is sok helyen a v2-es modulok tudnak futni. Ennek viszont olyan ára volt, hogy a futó rendszerrel is kompatibilisnek kellett lennie a rendszernek. Ez némi kompromisszummal járt ugyan, de megoldható volt. Persze emiatt a futó rendszerhez is sok helyen hozzá kellett nyúlni, a korábbi xbt-s kódnak már csak töredéke van jelen a rendszerben, az is inkább csak a frontenden.

PHP

A kód 5.3-as php verzióban kezdett íródni, de az idők folyamán az újabb verziók megjelenésével azokkal is kompatibilis módon folytattuk a fejlesztést, PHP 7.0-ával is futtatható, deprecated funkciók sehol sincsenek használva.

A teljes kód objektumorientált, bizonyos megkötésekkel megfelelő design patterneket is használtunk, de a backward comptibility miatt nincs például namespacing, de ettől még teljes értékűen MVW alapokon íródik a dolog.

Design

A korábbi torrent motorokkal ellentétben cél volt egy jól fejleszthető, skálázható, tesztelhető rendszer megírása. Hasonló irányt vett a whatcd-s Gazelle is egyébként, bár ott más megoldások születtek. Patternként leginkább a MVW rendszer áll legközelebb az insane v2 motorhoz. A view teljesen szeparált (template-elhető), vékony controller réteggel és heavy Model réteggel megtámogatva. Ennek segítségével nagyon gyorsan fejleszthető. Például egy bookmarking rendszer hozzáadása 1-1,5 óra volt, aminek java része a view megírása volt.

Mivel nagyon sok interakció van az oldalon, a controller réteg ketté lett választva és kapott egy auto evaluation réteget is, így a formok kezelése is villámgyors, biztonságos és igen jól skálázható, debuggolható.

Framework/nem Framework

A v2-es motor felfogható framework-ként, mivel minden általánosan lett megírva és controller rendszeren keresztül van csak példányosítva (API-zható is). Ugyanakkor, mivel cél volt a sebességoptimalizálás, bizonyos helyeken eltértünk az általános framework szabályoktól. A v2 nem készül más oldalak számára, és a fejlesztése sem nyílt. Ebből kifolyólag néhány helyen megengedtük azt a luxust, hogy speciális insane specifikus kódok legyenek a model rétegben is. Ezzel megspórolhatjuk, hogy rettenetes objektumhierarchiák keletkezzenek minden futásnál. Továbbá nem keletkezett irtózatos osztálymennyiség sem, így nincsenek interface-ek és factory-k sem, de nincs is rá szükség. Ez futásidő szempontból a nagy lekérésmennyiség miatt erősen memória és processzorkímélő megoldásnak bizonyult. Csak összehasonlításképp a korábbi xbt-s oldal generálást néhol sikerült a tizedére csökkenteni.

Adatbázis

A backward compatibility és a korábbi rendszerrel való párhuzamos futás miatt az adatbázis ugyanaz maradt, mint a korábbi, azaz egy MariaDB fork. MySQLi kompatibilitással. Erre a modern php direktívák miatt is szükség volt.

Egyébként emiatt a v1-et is teljesen ezekre az alapokra helyeztük már korábban, és nincsenek a kódban mysql_query-k sem sehol.

Adatbázis design

Sokáig hezitáltunk az InnoDB és MyISAM motorok közt, végül mégiscsak MyISAM-nál maradtunk. Egyrészt sebesség optimalizációs szempontok miatt, másrészt akkor még az InnoDB nem támogatta a FULLTEXT search-öt (azóta már igen). Így sajnos elvesztettünk pár nagyon kényelmes és hasznos funkciót, mint például az idegen kulcs kezelést vagy a rollbackinget, de a MyISAM pont arra van optimálva, ami az oldal működését is jellemzi, azaz rengeteg olvasás (select hegyek) és kevesebb írás. A szakirodalom szerint a MyISAM akár 15%-kal is gyorsabb lehet ilyen esetekben. Persze ez extra effortot jelent php oldalon, de kezelhető mennyiséget.

Adatbázis használat

Kód szinten a php csak egy saját, speciális csatolón keresztül kommunikál az adatbázissal, ezért adatbázis csatlakozás, valós adatbázis műveletek csak egyetlen ponton vannak a rendszerben. Ennek eredményeképp az adatbázis nagyon rövid időn belül lecserélhető a rendszer mögött - és persze a kód sincs tele mysql_query-kkel. A csatoló kapott pár hasznos funkciót, így nagyon könnyű lekéréseket végezni bárhol a rendszerben. Természetesen amit lehet, kivezettünk user cache-be, hogy kíméljük az adabázist és csökkentsük az egyidejű kapcsolatok számát.

A táblák nevei csak egyetlen helyen vannak megadva konstansként, így egy táblát átnevezni, vagy áttérni egy másik táblára egy modellen belül egy pillanat műve. Biztonsági okokból például a felhasznalok táblanév helyett használhatunk xyz nevet a torrentekre yxz-t, stb.

Caching

Mivel a modern PHP-s rendszerek megoldják az opcode cachinget beépítve, ezért ezzel nem kellett már külön foglalkozni. Ugyanakkor a korábbi user caching rendszereket (APC) már nem lehet használni. Egyelőre az oldal mögött APCu fut. Ez ugyan elosztott rendszerekhez nem alkalmas, de az insane még nem hízta ki az egyszerveres kiszolgálást, így megtartjuk addig, amíg fejlesztik és nem kell több szerverre költözni. Ha ez megtörténik átállunk egy elosztott caching rendszerre (memcache, Xcache, eAccelerator). User cacheben tárolunk mindent, amit csak lehet; fordításokat, kategória táblázatokat, és rengeteg minden mást is természetesen. A cache pucolás mindenhol optimálisan be van építve, ahol szükséges, így nincsenek beragadt adatok.

Egyelőre a böngészők storage rendszerébe nem vezettünk ki beállítás tárolásokat, de az is bővíti a lehetőségek körét a jövőben. Persze itt figyelembe kell venni, hogy mi kerülhet frontend tárolásba és mi nem.

Hibakezelés

A rendszerben kizárólag Exception kezelés van. A hibák kiértékelésére egy felsőszintű Exception kezelő réteg van beépítve, így nagyon egyszerű a debuggolás és a hibák megfelelő formájának mutatása felhasználói szinttől függően. Például egy átlag felhasználó egy adatbázis hiba esetén csak egy általános hibát fog látni, míg egy sysop részletes exception-t. Ugyanígy nem kell minden ponton jogosultsági és adatformátum ellenőrzéseket beiktatni, mert ezek egyetlen ponton elég, ha kezelve vannak. Így csökken a támadhatóság és a hibák lehetőségének száma is töredéke az egyébként lehetségesnek és ezzel együtt a kód bonyolultsága is minimális lesz.

Jogosultság kezelés

A felhasználók egyes jogai jogosítási mátrixokban vannak tárolva egy helyen. Ilyen például a szerkesztési jogok mátrixa, vagy az oldalelérések mátrixa, stb. Így ezek akár adatbázisba is kivezethetők (cachinggel), bár jelenleg kódban vannak tárolva a gyorsabb futás érdekében (úgysem változnak gyakran). Emiatt nem lesznek a kódban jogosításból származó ellentmondások. Például nem lesz olyan szerkesztési mező, amit a frontenden lát egy felhasználó, ugyanakkor a backenden nem lesz joga hozzá és hibát kapna.

Frontend

A frontendes fejlesztések teljesen szeparáltan vannak kezelve az MV* direktíváknak megfelelően.

HTML/CSS/JavaScript

Ahogy a backenden, úgy a frontenden is cél a minél gyorsabb futás és a minél kevesebb adatáramlás megoldása. Ebből kifolyólag a legmodernebb technológiákat igyekeztünk értelmesen felhasználni.

Az oldal mindenhol kizárólag HTML5-öt használ. Ennek megfelelően a html szerkezet szemantikusan is helyes, így könnyen skin-ezhető. Használjuk a jól scriptelhető data-* formulákat is. Aria használat cél hiányában nincs az oldalon (egyelőre). Szerkezet felépítéshez nem használunk táblázatokat, kivéve egyetlen helyen, mivel a flex még nem működik mindenhol tökéletesen.

A css a css3 szabványokat használja. Emiatt nem használunk scripteket animációkhoz, sem képeket design effektekhez (árnyékok, lekerekítések, stb.) ezzel is gyorsítva az oldalgenerálást és megjelenítést. A kód sehol sem tartalmaz inline style-okat, kizárólag class használat van mindenhol. Ez is erősen segíti a skinezést.

Javascript szintjén alapként jQuery-t használunk lib-ként, egyelőre 2.x-es verziókat. Néhány apróbb lib még bekerülhet (például webes rádió lejátszó). A rendszer egy saját iNSANE "library"-t is kapott, nem a global scope van teleszórva funkciókkal. Scriptelés csak annyira van elengedve, amennyire feltétlen szükséges.

Ajax kezelés
Az insane library kapott egy összevont ajax (igazából ajaj, mert kizárólag json kommunikáció van nem xml) kezelő rendszert, így minden ajax kérés egy ponton van kezelve általánosan, így nagyon egyszerű új ajax funkciókat beépíteni és kezelni.

Ami nem szép: a html kódban még vannak onclick-es esemény kezelések inline módon. Ez egyrészt elviselhető mennyiség, másrészt idővel ki lesznek szervezve js file-okba. Vannak oldalon belüli <script> tag-ek. Ezek ugyan teljesen szabványosak, mégsem a best practice irányába mutat. Idővel kezelve lesznek.

Ikon és kép kezelés

Az optimális letöltési sebességek eléréséhez az ikonokat egy icon fontkészletből szolgáljuk ki. Így nincsenek felesleges képletöltések, amik megnövelnék a letöltési időt. Ha valahol mégis képi ikonok vannak, akkor azok sprite-olt képek (sok ikon egy képben) a könnyebb cache-elhetőség és letöltés miatt. Ahol lehet vektoros képeket használunk svg formátumban.

Template kezelés

Jelenleg egy template (nem skin!) van a rendszerben, nem jutottunk el a többféle template megvalósításáig. Ugyanakkor akárhány template hozzáadható a rendszerhez (amennyiben van értelme), mivel a View réteg teljesen külön van választva.

Skin-ezhetőség

Igyekeztünk viszonylag egyszerű, de akár teljesen testre szabható skin rendszert építeni a meglévő template-hez. Van egy alap skin css, ami nem tartalmaz szín- és képbeállításokat, csak szerkezeti beállításokat. Ez tulajdonképp a template része. Efölé vannak behúzva az egyes skinek. Kevés munkával egy egyszerű átszínezés nagyon kevés időn belül is megoldható. Látványosabb skinek természetesen a szerkezetet is módosíthatják. A template skin css-se úgy van megírva, hogy a skinekben sehol sem kell !important definíciókat használni. A skinek használhatnak saját javascriptet, de nem kötelező. Így skineként akár bizonyos extra effektek is hozzáadhatók, amelyek css-sel nem elérhetők, bár a css3 igen tág lehetőségeket biztosít egyébként is.

Egyelőre terv szintjén felmerült (de valószínűleg meg is valósul), hogy az egyes skinek bővebb beállítási lehetőséget is kapjanak, például eltérő háttérszínnel vagy háttér rögzítéssel kontra görgethetőséggel, stb., amit akár a böngészők storage rendszerébe kivezetve böngészőnként más képet is mutathat. Ez például hasznos lehet, ha valaki többféle böngészőből használja az oldalt, annak megkülönböztetésére, hogy épp melyik böngészőt használja. De szimplán arra is jó, hogy valaki eltérjen egy általa kedvelt skin bizonyos alap beállításaitól (eltérő háttérszín, esetleg más betűszín, stb.)

Fontok

Az alap template skin a google fontsból jól ismert 'Roboto Condensed' betűtípust használja. Természetesen skinenként több betű is használható. Hogy elkerüljük a google fonts elérhetetlenségéből származó és kompatibilitásból adódó problémákat, így egy pár font családot a teljes formátum variációban (ttf, svg, woff, woff2, eot, stb.) elérhetővé tettünk az új rendszerben, így ezeket a skinekben is nyugodtan be lehet húzni egyetlen sor hozzáadásával. Ezek listáját a későbbi skin tervezőknek meg tudjuk adni, illetve a lista bővülhet is.

Responsive design

Jelenleg a v2-ben nincs kidolgozva a responsive design, de rövidesen mobilra is optimáljuk. A html szerkezet erre mindenhol alkalmas. Minimális, tesztelési jellegű media query most is van a template és a skin css-ekben is.

Miért nem Bootstrap?

A bootstrap oszlopos (grid) rendszere bár nagyon jól használható, sajnos több munkával járna beépíteni, mint kihagyni, tekintve, hogy az oldal nagyon speciális elemeket is tartalmaz. Nem szerencsés behúzni egy hatalmas css libet, hogy aztán több, mint a felét fejbecsapjuk saját kóddal. Inkább írunk egy egyszerű gridelős rendszert, amit a template-hez hozzácsatolhatunk. Így a skineknek sem kell alkalmazkodniuk a bootstraphez.

SASS/LESS

A css nem készült el sem SASS sem LESS változatban, ez még várat magára, de tervben van. Egyelőre a css-t szekciókra bontottuk, hogy idővel ezt minél gyorsabban meg lehessen oldani.

Többnyelvűsítés

Az oldal alap nyelve jelenleg a magyar és nincs is tervben, hogy ettől eltérjünk, így a hírek, a staff kommunikáció, stb. magyarul zajlik a jövőben is, vagyis a "hivatalos" nyelv a magyar lesz. Ugyanakkor az oldalt minél jobban használhatóvá szeretnénk tenni több nyelv választhatóságával, így mindenféle translator program nélkül az oldal az egyes nyelveken teljesen használható lesz. Nyilván jobban is, mint úgy.

Az oldal mögött egy viszonylag egyszerű, de hatékony fordítás menedzselő rendszer fut. A php kódban a legtöbb helyen csak nyelvi kulcsok vannak használva, melyeket egy automata rendszer a felhasználó kiválasztott nyelvén behelyettesít. Az egyes fordítások természetesen user cache-ben vannak tárolva, így nem terhelik a rendszert.

Az oldal jelenleg 5 nyelvet kezel, de a nyelvek listája korlátlanul bővíthető.

Az egyes fordítások a fordítók sebességétől függően nem egyszerre készülnek. A le nem fordított kulcsok alapból megjelennek a magyar fordítással. Az angol fordítások mindig azonnal bekerülnek új kulcs hozzáadásakor. Jelenleg nem minden van fordító kulcsokkal helyettesítve - bizonyos helyeken még vannak beégetett magyar szövegek. Ezek az idő előrehaladtával folyamatosan mindenhol cserélve lesznek.

Idővel szeretnénk a wiki bizonyos, fontosabb cikkeit is angolra lefordítani. Az elegendő lenne a szabályrendszer megértéséhez a legtöbb külföldi felhasználónak is.

Mobil applikáció

A mobil böngészők rohamos fejlődése mellett megszűnt az az igény, hogy külön mobil applikációt készítsünk, így ez nincs is tervben. Az oldal webes megjelenítését igyekszünk majd mobilra is optimalizálni mielőbb.