Chess Events Oy

[Jussi Hämäläinen]

Joukkueblikstit on datamäärältään äärimmäisen pieni tapahtuma. Siis kun vertaa tyypillisiin järjestelmäprojekteihin, joissa tallennetaan miljoonia (nykyään miljoona on jo vähän) datapisteitä.

Swiss Manager on huono siksi, että se ei ole optimoitu blikstien tulospalveluksi. Toki sillä saa väännettyä blikstit läpi. Kyllähän blikstit saisi ajettua vaikka Powerpointilla jos on tarpeeksi luovia ja osaavia henkilöitä saatavilla.

SM-blixtit ei ole mikään järjestelmäprojekti, vaan urheilukilpailu, joka järjestetään harrastuspohjalta. Palkattu henkilökunta varmaan saa aikaan miljoonia datapisteitä (mitä ne nyt sitten ovatkaan; atk-slangia tähän keskusteluun juuri kaivattiinkin), mutta SM-blixteissä tällaista vaihtoehtoa ei liene käytettävissä.

Hieman turhauttaa, kun vastauksia pitää kiskoa hohtimilla, mutta jatketaan silti: Mitä Swiss-Managerista puuttuvia ominaisuuksia olisi blixtejä varten optimoidussa ohjelmassa?

Onhan noita.

Esimerkiksi SMS-viestit pelaajille kilpailun aikana. Joukkueiden kapteenit saavat aamulla ennen pelien alkamista viestin, jossa päivän aikataulu hänen joukkueensa osalta.

Samanlainen voisi olla katsojille. Tyyliin "valitse kerhosi ja syötä puhelinnumero/sähköposti". Järjestelmä lähettää molempien pelipäivien päätteeksi viestin, jossa kerrotaan kerhon kaikkien joukkueiden sijoitukset.

Entä reaaliaikainen pelolaskenta? Kaikki data on olemassa joten ei kummoinen juttu suorittaa lennosta.

Tai monipuolisemmat tilastot*, joiden pohjalta järjestelmä generoisi tiedotteita. Vaikka reaaliaikainen tiedote Facebookiin, jossa lukee "Mikko Mikkola voitti juuri yhdeksännen pelinsä putkeen! Pystyisitkö sinä samaan?".

Turnauksen päätyttyä järjestelmä lähettäisi kauniit PDF-generoidut mediatiedotteet kaikkiin uutispalveluihin ja muille kiinnostuneille.

Yksi hauska lisävirike kustomoidulle tulospalvelulle on, että sen läpiajon voisi testata vaikka laittamalla 600 tietokonetta (ei fyysistä tietenkään) muodostamaan joukkueet ja pelaamaan "tietokoneiden joukkueblikstit" toisiaan vastaan. Eipä ole kummoinen juttu. Siinä näkee hyvin miten kisa ajetaan läpi ja järjestävä seura pääsee ennen varsinaista koitosta harjoittelemaan ja tsekkaamaan miltä tulospalvelu näyttää loppuasiakkaan (pelaajat ja kotiväki) silmin.

Uusi järjestelmä pitää ehdottomasti suunnitella siten, että se antaa pelivaraa tulevaisuutta ajatellen. Siksi kustomoitu on paljon joustavampi kuin Swiss Managerin päälle pakkoahdetut viritelmät.

*ChessResultsillakin on ihan kivat tilastot, mutta selkeästi ei optimoitu joukkueblikstejä varten. Todella turhauttavan vaikeaa saada selkoa miten tietyllä kerholla on kilpailu sujunut kun pitää sijoitusryhmien tuloksia yksitellen käydä katsomassa. En löytänyt mistään näkymää, josta näen kaikkien kerhon joukkueiden kaikki pelaajasuoritukset kerralla.

[Petri Pitkänen]

Aika outo olisi ajatus kokonaan oman softan tekeminen tulospalveluun. Ohjelmisto projektit maksaa noin 100€/h ja 100 tunnilla ei saa juuri mitään aikaiseksi. Pelkkä määrittely veisi tuon määrän työtä. Eli näillä volyymeilla sen pitää olla valmist ohjelmisto. Ja Swiss-managerissa on se hyvä puoli, että löytyy ihmisiä jotka osaavat sitä käyttää. Tilastoinnit voi kiinnostuneet tehdä sitten omin voimin.

[Jussi Hämäläinen]

Aika outo olisi ajatus kokonaan oman softan tekeminen tulospalveluun. Ohjelmisto projektit maksaa noin 100€/h ja 100 tunnilla ei saa juuri mitään aikaiseksi. Pelkkä määrittely veisi tuon määrän työtä. Eli näillä volyymeilla sen pitää olla valmist ohjelmisto. Ja Swiss-managerissa on se hyvä puoli, että löytyy ihmisiä jotka osaavat sitä käyttää. Tilastoinnit voi kiinnostuneet tehdä sitten omin voimin.

Tässä on pointtinsa. Kertakustannus on suurehko, mutta jos sen saa tasattua seuraavalle 10-15 vuodelle, niin se saattaa olla taloudellisesti perusteltavissa. Uskon, että on.

Koko projektin läpivienti lienee luokkaa 300-400 työtuntia. Tuo 100 tuntia pelkkään määritykseen on tyypillinen yliarvio, joka perustunee valtion IT-projektien vaatimuksiin. Ei tässä mitään ydinreaktoria suunnitella.

[Jari Järvenpää]

Aika outo olisi ajatus kokonaan oman softan tekeminen tulospalveluun. Ohjelmisto projektit maksaa noin 100€/h ja 100 tunnilla ei saa juuri mitään aikaiseksi. Pelkkä määrittely veisi tuon määrän työtä. Eli näillä volyymeilla sen pitää olla valmist ohjelmisto. Ja Swiss-managerissa on se hyvä puoli, että löytyy ihmisiä jotka osaavat sitä käyttää. Tilastoinnit voi kiinnostuneet tehdä sitten omin voimin.

Outous on suhteellista Onhan tota yhteistyötä ainakin periaatteessa kaavailtu Shakkiliitossa eri tahojen kanssa ja puhuttu myös medianäkyvyyden lisäämisestä. Joukkueblikstejä varten kun ollaan jo uutta yritystä perustamassa, niin tulisi mieleen samalla muokata softaa hieman muutakin yleisöä varten ja samalla turnaustakin varten vielä käyttökelpoisemmaksi. Chess-results ei luultavasti ole monen mielestä kovin kiinnostava: on turhaa informaatiota ja myös puuttuu jotakin kiinnostavaa. Käyttökelpoisia toki ovat Swiss manager ja Chess-results noin yleisesti turnauskäytössä, mutta joukkuebliksteihin voisi miettiä muitakin ratkaisuja.

JHamilla oli aikaisemmassa viestissä (22.8. 7:15) ihan järkeviä ideoita.

[ojk54]

Kiinnittäisin ensinnäkin huomiota aiemmin sivulauseessa olleeseen huomautukseen talkooväen tarpeellisuudesta eli shakkiporukkaa tarvitaan kuitenkin - talkoisiin toivottavasti edes ruokapalkalla.
Onhan aiemminkin shakkiliitto myöntänyt kisat shakkiseuroille korvausta vastaan eli tulonmuodostus on täten toteutunut, kuten oy:lläkin on aina tavoitteena.

Yksi pelon aihe on kustannukset eli nyt jo aika suuret osanottomaksut eivät ainakaan pienene, kun ne vedetään ehkä vaikka kapeankin organisaation ja ilmaisen talkooporukan läpi rahankiilto silmissä.
Ja kuka ne oheistapahtumat kustantaa? Kannattaisko shakkiväeltäkin hieman kysellä, millaisia oheistapahtumia joukkuepikapelaajat haluavat lauantain klo 20 ja sunnuntaiaamun klo 10 välillä?

Sitten vielä tästä oy:stä eli jarjestetäänkö jonkinlainen suunnattu osakeanti esimerkiksi shakkikerhoille, jolloin kaikki pääsevät mukaan rahantekoon osinkojen muodossa, joka voi tapahtua useammankin kerran vuodessa.

OK

[Jarmo Sorvari]

Hei

Mielenkiintoista keskustelua, osuu omiin mielenkiintoihin aika lailla.

Olen vetänyt (ja ohjelmoinut) jsm-blixtien tulospalvelun kolme kertaa, ensimmäisen kerran joskus 90-luvulla. Aina se saatiin läpi ja onneksi parannettiin kerta kerralta.

Viimeisimpään Tampereella järjestettyyn kisaan sain siitä jo aika kivan, mutta paljon jäi kaivamaan. Noista kolmesta kerrasta on aika hyvin jäänyt mieleen, miten hyvän systeemin tulisi pelata.

Olen JHamin kanssa täsmälleen samaa mieltä. Swiss-Manager + Chess-results on ratkaisu, jolla homma saadaan vedettyä toki läpi (onhan se näytetty toteen), mutta omassa mielessäni se on korkeintaan B-suunnitelma.

JSM-blixtit tuottaa paljon dataa, joista voi rouhia vaikka mitä, JOS TIETOKANTA ON OMISSA KÄSISSÄ. Chess-results antaa dataan aika kapean näkökulman. Oikeasta relaatiotietokannasta voi toisaalta tehdä vaikka mitä koosteita.

JHam totesi tarkasti syyn, miksi ei ole syytä olla tyytyväinen SM-CR -yhdistelmään: sitä ei siis ole tehty sm-blixtejä varten. Yksi ihan konkreettinen (joskin muihin verrattuna aika pieni) ongelma selviää kuvasta, jonka ainakin yritin liittää tähän viestiin (näyttökaappaus tämänvuotisen kisan tulosnäytöstä).

Lauantain ja sunnuntain välinen yö on tulospalveluhemmon ja monien muiden painajainen. Ei taida SM suoraan tukea sijoitusryhmien muodostamista. Pöytälappujen laadintaan ja printtamiseen tulee kuitenkin olla omat ohjelmansa. Entä ennen turnausta osanottajien tietojen saaminen järjestelmään? Sekin vaatii SM:n ulkopuolisen virittelyn, joka pahimmillaan kuormittaa jotakuta manuaalityöllä. Tampereen turnaukseen sain jo toteutettua ennakkoilmoittautumista, ei tarvinnut lauantaiaamuna hakata sormet kipeinä (kuten silloin ensimmäisessä skabassa 90-luvulla). Tulosten syötön helppouden turnauksen aikana tulee olla äärimmilleen viritetty, jotta pärjätään mahdollisimman vähällä syöttöhenkilökunnalla. Unelmissani on se, että joukkueet ilmoittaisivat tulokset jotenkin kännyköillä, päästäisiin lappurumbasta. Mutta tämäkin on joko mahdotonta, vaikeaa tai kömpelöä, jos ollaan tyytyväisiä SM+CR -yhdistelmään.

Jos tietokantaan tehdään REST-rajapinnat (nykyiseen avoin data -tyyliin), jotkut innokkaat voivat tehdä appeja, jotka käyttävät tuota dataa. Innokkaat shakkia pelaavat tietotekniikan opiskelijat saisivat vaikka mitä kivaa aikaan tuollaisessa ympäristössä. Mutta ei, jos data säilötään jonnekin Itävaltaan ilman asianmukaisia rajapintoja.

Minulla oli ajatus luovuttaa ohjelmistoni laajempaan käyttöön (jollain järjestelyllä), kunhan tekisin sen vielä uudelleen. Sellaisena kuin se viimeksi ilmeni, sitä ei voi antaa, se ei ollut kovin tuotteistettu. Olin toivonut, että kerhomme vielä kerran järjestäisi blixtit, johon uuden version voisi tehdä. Täytyy sanoa, että petyin, kun luin tästä osakeyhtiöstä.

Itse asiassa olenkin jo alkanut tehdä sitä. Jos ei muuten, niin teen sen huvikseni ja mielenkiinnosta (haluan päivittää tiettyjen teknologioiden osaamistani). Teen sitä toistaiseksi ilman aikataulupaineita ja sitoimuksia, mutta luultavasti teen siitä niin sanotusti tarpeeksi hyvän. Tullaan sitä sitten käyttämään tai ei.

Jarmo

[Jari Järvenpää]

Pettynyt olen minäkin tällaisesta Chess Eventsistä. Miten käy shakkilehden julkaisemisenkaan: väheneekö sivumäärä, julkaisujen määrä vielä entisestään ym.? Sitä varmasti ei moni haluaisi. Kuka tietää, jos turnausten järjestäminen laajenee joukkuebliksteistä muihinkin turnauksiin.

Hienoa, jos Jarmo jaksaa tehdä vapaaehtoistyötä ohjelmoinnin suhteen!

[Jarmo Sorvari]

Täytyy sanoa, että petyin, kun luin tästä osakeyhtiöstä.

Tarkennan vielä, että en tarkoita että lyttäisin oy-ajatuksen sinänsä heti -- en ole perehtynyt aiheeseen riittävästi. Keskustelua tuosta tarvitaan.

Pettymys on enemmän henkilökohtaista, olin henkisesti valmistamassa itseäni vetämään vielä yhdet kisat.

Myöskin harmittaa se, että SM+CR -yhdistelmää tunnutaan pidettävän aivan riittävänä ratkaisuna niin, ettei ole edes tarvetta parantaa. Toivottavasti olen väärässä. Parannettavaa on niin paljon (heitin esimerkiksi lappurumban korvaamista mobiililaitteilla joita jokaisella jo on). Tässä pitäisi porukalla olla edes kunnollinen visio, vaikka sellaisen tavoittaminen olisi kaukanakin.

Toki keskustelussa täytyy ottaa huomioon myös se, että nyt puuhaamani systeemi on vielä promisewarea. Siksi täytyy aina olla myös B-suunnitelma, ja niitähän on jo syntynytkin.

Jos tulospalvelu olisi selaimella käytettävä pilvessä pyörivä palvelu, vaikuttaisiko se osakeyhtiösuunnitelmiin? Onko tulospalvelun järjestäminen se isoin syy kisojen keskitetyn järjestämisen tarpeeseen?

[Jussi Hämäläinen]

Hyviä pointteja yarmoe:lta.

Minä tekisin tämän seuraavasti:

- MySQL-tietokanta
- PHP-applikaatio, joka generoi HTML-käyttöliittymän ja toimii REST-rajapintana.
- Zoner SMS-rajapinta tekstiviestejä varten
- Mailgun-rajapinta sähköposteja varten
- Pusher-rajapinta reaaliaikaista tulospalvelua varten

Itse PHP-applikaation ydinlogiikka on hyvin yksinkertainen. Periaate on seuraava:

1) vastaanota + tallenna yksittäisen pelin tulos
2) laske kaikki tilastot alusta asti uusiksi
3) lähetä päivitetyt tilastot katsojille

Tuon pohjalla joku relaatiomalli (Pelaaja, Joukkue, Ottelu, Kierros, yms.). Thats it. Helppo koodata ja vielä helpompaa testata. Tämä periaate on mahdollinen juuri siksi, että joukkueblikstit on niin tajuttoman piskuinen tapahtuma. Koko viikonlopun aikana pelataan noin 15 000 peliä. Se on todella vähän.

Paperisten lippulappusten generointi on luultavasti työläin osuus koko tulospalvelun kehityksestä. Mutta siihenkin on lisäosia olemassa PHP:lle. Tai sitten erillinen Node.js-ohjelma, joka hoitaa lippulappusten generoinnin. Node.js:lle ainakin on tuhoton määrä lisäosia tuota varten.

[Pekka Pietinen]

Tuon pohjalla joku relaatiomalli (Pelaaja, Joukkue, Ottelu, Kierros, yms.). Thats it. Helppo koodata ja vielä helpompaa testata. Tämä periaate on mahdollinen juuri siksi, että joukkueblikstit on niin tajuttoman piskuinen tapahtuma. Koko viikonlopun aikana pelataan noin 15 000 peliä. Se on todella vähän.

Jos kerran kyseessä on "niin tajuttoman piskuinen tapahtuma", niin miksi pitäisi rakentaa em. kaltainen hankala systeemi, kun homma tuntuu ihan hyvin pelittävän nykyiselläkin SwissManagerin systeemissä? USA:ssa sanotaan usein, että "If it works, dont fix it!"