Voltam ugyebár ezen a Champs Scalar Coupling nevű versenyen. Menet közben volt néhány “ahaaa” pillanat, amikor rádöbbentem valamire, és amit jó lett volna tudni verseny elején. Úgy érzem ezeket érdemes összeszedni, hasznos lehet azok számára, akik első Kaggle versenyükre készülnek.

De mielőtt belevágnánk, egy fontos megjegyzés: minden verseny más, nagyon. Nincs egységes recept. És persze én sem vagyok veterán, másoknak más lehetett a tapasztalata. Na de akkor vágjunk bele.

Cross-Validation mindenek felett

Számomra a legnagyobb tanulság volt, hogy a jó kereszt-validáció nagyon nehéz. Ezt egyébként már sokan mondták, de olvasni és megtapasztalni egész más.

Én a verseny utolsó pillanatáig azt hittem, hogy a CV (Cross-Validation) stratégiám jó. De kiderült, hogy nem volt tökéletes, csak amíg kis pontossággal becsült a modell, addig nem volt gond. A kereszt validáció azért fontos, hogy meg lehessen állapítani a modellről, hogy mennyire képes generalizálni, azaz mennyire működik jól ismeretlen adatokon.

Éppen ezért érdemes minél hamarabb, minél több becslést beküldeni, mert így a teszt adathalmazról és a készülő modellről is szerzünk információt.

A kaggle.com egy közösségi oldal

Egy másik fontos tapasztalat, hogy rengeteg hasznos információ, trükk, ötlet, stb… található a verseny fórumában és a publikus notebookookban (kernelekben). Én tulajdonképpen úgy értem el a “bronz” eredményt, ami amúgy egyáltalán nem egy nagy szám, hogy semmi mást nem csináltam, csak próbáltam minél több dolgot kipróbálni majd beépíteni az elérhető anyagokból.

Eltérő modellek kellenek

Végül pedig egy közismert dolog, a “kiátlagolás” tényleg nagyon hatékony eszköz. A saját modellem pontszáma -1.7 volt (a kisebb szám a jobb). Ezt kevertem -1.3 és -1.5 pontos becslésekkel, és a végeredmény -1.9 körüli eredmény lett, tehát sokkal jobb, mint bármelyik külön komponense.

Éppen ezért nagyon megtérül, ha nem csak egy modellt építünk, hanem minél többet. Egy GBM, egy neurális háló, stb, stb… Akkor is sokat fognak hozzátenni a végeredményhez, ha külön-külön nem annyira erősek.

Én ennyi tanáccsal tudtam szolgálni, végül két linket osztanék meg, korábbi nyertesekkel készült interjúk. Érdemes elolvasni, mit mondtak, tudhatnak valamit, elvégre győztek :)

"Bestfitting"-gel készült interjú, 2018-ban Kaggle #1

Abhishek Thakur interjú, Competition Grandmaster, Kernel Grandmaster és Discussion Grandmaster

Zárásként még annyit, hogy én elképesztően jól éreztem magam a verseny közben, végre valami olyannal foglalkozhattam amiért 110%-ig lelkesedni tudtok. És közben rengeteget tanultam. Mindenkinek csak ajánlani tudom, hogy belevágjon.

Először is szeretném felhívni a figyelmet, hogy a címben jelzett versus idézőjelben van. A cikk pont arról szól, hogy az miért is van úgy írva.

Egy kedves ismerősömmel éppen a szegedi Networkshop 2017 konferenciáról visszafelé tartottunk Budapestre. Valamiről beszélgetni kellett, és igencsak jó téma került elő. A Symfony keretrendszerről kezdtünk beszélgetni, nem ismerte, de lelkes érdeklődő volt, sok-sok kérdéssel. Elmondtam neki mindent töviről hegyire. Elmondtam, hogy ez egy keretrendszer, ami azt jelenti, hogy telepítés után nem tud még semmit, magunknak kell megírni amit szeretnénk. Szóba került a Drupal is, tudja, hogy abban is otthon vagyok. Azt is elmondtam, hogy az meg egy tartalomkezelő, tehát már telepítés után is bőven van hova kattintgatni.

… És akkor feltette a nagy kérdést:

Hogyan lehet a Drupalt és a Symfonyt együtt használni, lehet-e egyáltalán keverni ezeket?

Már majdnem mondtam a standard választ, hogy hát az egyiket lehet telepíteni a másik alkönyvtárába, és akkor bizonyos URL-eket az egyik, a többit meg a másik fogja kiszolgálni. Persze ez nagyon messze van attól, hogy igazán egyszerre használjuk a kettőt. Ezt a fajta egymás mellett élést bármelyik két webes rendszerrel meg lehet tenni, teszem azt akár egy Rails-es alkalmazás és egy java SpringBoot-os alkalmazással is.

De …

… a Symfony és a Drupal ennél sokkal mélyebb integrációja is lehetséges, legalábbis akkor, ha Drupal alatt D8-at értünk. Kedves olvasó, van már ötleted, hogy mire akarok kilyukadni? Ha nincs, akkor mutatom a következő elképzelt „beszélgetést”:

– Hé, Te Symfony! Van ötleted, hogy a felhasználó milyen tartalmat kér most éppen rajtunk számon? Nesze, itt egy Request objektum, benne van az URL, a sütik, a böngésző típusa, és még vagy 28 millió másik dolog.

– Nekem aztán fogalmam sincs, itt egy 404-es Response objektum. Csak most, csak neked, nagy szeretettel.

– Hé, Te Drupal8! Neked csak van valami ötleted, hogy mit akarhat a user, ugye? Itt a Request objektum, tessék.

– Passz, fogalmam sincs. Tőlem is kapsz egy friss – ropogós, 404 Response-t.

– Na, te házilag barkácsolt FityfirityCMS, te már biztosan tudni fogod, hogy mit kér a user.

– Háááát biza`, ötletem az nekem sincs.

– Na jó, Laravel, utoljára téged még megkérdezlek! Neked már tényleg tudnod kéne, mi a fenét akarhat a user.

– Nekem van egy tippem, tessék itt egy Response. Van benne minden, HTTP fejlécek, tartalom, és még sok egyéb jóság. A változatosság kedvéért ez pont nem 404.

PSR-7

Amire utalni próbálok az a PSR-7 ereje. Arról van szó ugyanis, hogy okos emberek kitalálták, hogy legyen egy standard interfész, ami leír egy HTTP kérést és egy HTTP választ. És bármelyik rendszer, ami ezeket az interfészeket implementálja, az tud egymással érdemben kommunikálni, és el tudják dönteni egymás között például azt is, hogy egy adott kérést kinek kellene kiszolgálni. Erre volt egy példa, a fenti kis szösszenet.

Symfony HttpFoundation

A PSR-7 csak egy interface. A Symfony HttpFoundation pedig egy implementációja. Bár nem muszáj ezt használni, bárki újraimplementálhatja a PSR-7-et, csak éppen túl sok értelme nincs. Aki a saját kis keretrendszerét, tartalomkezelőjét, vagy akármilyen egyéb kis szkriptecskéjét úgy építi fel, hogy az a Symfony HttpFoundation-t használja a HTTP kérések és válaszok kezelésére, az alkalmas lesz becsatlakozni és együtt dolgozni minden olyan rendszerrel, ami hasonlóan tesz.

Nincs vége

A beszélgetésünk előtt is ismertem a PSR-7-et és a Symfony HttpFoundation-t, de ez a beszélgetés döbbentett rá ezek igazi erejére és hasznosságára. Ugyanis a történet nem áll meg ott, hogy URL alapján eldöntjük, hogy kinek kell kiszolgálni a kérést. A kooperáció ennél sokkal-sokkal komplexebb is lehet. El tudok képzelni például olyat, hogy a tartalmat a Drupal állítja elő, de az autentikációt a Symfony végzi. Majd az elkészült végleges Response válaszhoz, a saját kis fityfirity alkalmazásunk még hozzá tesz egy extra HTTP fejlécet, amiben a teljes tartalmat egy titkos kulccsal még aláírja. Mi is hallottunk már a HTTPS-ről, de tegyük most fel, hogy az nem elég, annál többet akarunk. És az egész elé még bedobunk egy gyors user sapce reverse proxy-t, amivel gyönyörűen felturbózzuk az alkalmazásunk sebességét. És mindezt okosan, tartalom és user függő módon, nem vagyunk kénytelenek kizárólag az URL-re és az időre hagyatkozni a gyorstárazható-e vagy sem kérdés eldöntésekor.

Összegezve tehát a PSR-7 szabvány és annak implementációja, a HttpFoundation segítségével képesek vagyunk arra, hogy egymástól független, akár egymásról nem is tudó alkalmazások összedolgozzanak azon, hogy a felhasználó által indított HTTP kérésre megszülessen egy válasz. A lehetőségek tárháza ezzel igencsak kitárul. Annak oka, hogy ez nincsen széles körben kihasználva, véleményem szerint mindössze azért van, mert a keretrendszerek és tartalomkezelő rendszerek önmagukban is elég eszközkészletet adnak ahhoz, az átlagos igényeket kielégítsék. De biztosan van olyan eset, amikor erre szükség lehet. Nekem például eszembe is jutott egy alkalmazási lehetőség, amire a Sztakiban biztosan lenne igény. De ez már egy másik mese.

További olvasnivaló:

• http://www.php-fig.org/psr/psr-7/
• https://github.com/php-fig/http-message
• https://github.com/php-fig/http-message-util
• http://symfony.com/doc/current/components/http_foundation.html

Pontosan 1 évvel ezelőtt, 2013. április 22.-én kezdtem dolgozni az MTA Sztaki-ban. Magam sem gondoltam volna, hogy eddig húzom egy helyen :) De maradtam, mert jól érzem magam. Az elmúlt egy év sok különböző érdekes feladatot és számomra még ismeretlen technológiát tartogatott, így bőven volt kihívás és szakmai előrelépés is. Egyszóval mozgalmas év volt.

Jelenleg is keresünk tapasztalt vagy tanulni képes PHP és Java fejlesztőket, Drupal-os projekt is bőven. Részletekért Héder Michályt vagy Rigó Ernőt keressétek.