>Három évig zavart. Két nap alatt megoldottuk.

Három éve vettem egy futópadot, és a választásnál külön szempont volt, hogy legyen benne Bluetooth. Azt feltételeztem, hogy ez nagyjából azt jelenti, amit más eszközöknél: össze lehet kapcsolni különböző alkalmazásokkal, azok adatot tudnak olvasni róla, jobb esetben még vezérelni is lehet.

A gyakorlatban ennél jóval szűkebb volt a mozgástér. A Kinomap működött vele valamennyire, más alkalmazásokkal viszont vagy egyáltalán nem állt szóba, vagy az adatkapcsolatnál megállt a történet. A futópad sebességét és dőlésszögét normálisan vezérelni nem nagyon tudtam máshonnan. A Kinomap közben évente körülbelül negyvenezer forintba került.

Ez három évig pont megfelelő méretű probléma volt ahhoz, hogy bosszantson, de ne kezdjek vele semmit. A futópadon ott volt a Bluetooth logó, tehát technikailag nem arról volt szó, hogy a gyártó elfelejtette volna az összekapcsolhatóságot. A gép kommunikált a telefonnal, csak éppen nekem nem sok beleszólásom volt abba, hogy ezen a kapcsolaton keresztül mit lehet csinálni.

Ez önmagában nem különösebben szokatlan. Rengeteg hardver működik úgy, hogy van hozzá egy gyári vagy partneralkalmazás, azon kívül pedig sok szerencsét. Felhasználóként ezt többnyire tudomásul vesszük. Ha az adott alkalmazás megfelelő, nincs is vele különösebb gond. Ha nem az, akkor marad az alkalmazkodás.

Nálam is ez történt. Időről időre megnéztem, jelent-e meg valami más megoldás, kipróbáltam néhány appot, aztán ment tovább minden ugyanúgy. A fizikai gombok működtek, a Kinomap használható volt, a probléma tehát messze nem volt kritikus. Csak három év alatt sem lett kevésbé furcsa, hogy van előttem két eszköz, amelyek nyilvánvalóan képesek kommunikálni egymással, mégsem én döntöm el, hogyan használhatom őket együtt. Nem az alkalmazás hiányzott igazán. Az zavart, hogy nem értettük, mi történik a kettő között.

Amikor végül nekiálltunk, nem egy iPhone-appal kezdtünk. Először azt kellett kideríteni, milyen adatokat küld és fogad a futópad Bluetooth-on.

Ez eleinte elég prózai munka volt. Meg kellett figyelni a kommunikációt, majd ugyanazokat a műveleteket újra és újra elvégezni úgy, hogy közben mindig csak egy dolgot változtatunk. Beállítani egy sebességet, megnézni az adatot, aztán másik sebességet választani és összehasonlítani, mi változott. Ugyanezt végigjátszani a dőlésszöggel, az indítással, a leállítással és az állapotadatokkal.

Közben kiderült, hogy a gép a FitShow protokoll valamelyik változatát használja. Ez már adott kapaszkodót, de attól még a saját futópadon is meg kellett érteni, pontosan hogyan viselkedik az implementáció.

Az egyik első fontos pillanat nem az volt, amikor szép lett egy képernyő, hanem amikor a saját kódunkból elküldött parancsra ténylegesen megváltozott a futópad sebessége. Onnantól nem egy Bluetooth-os fekete doboz volt előttünk, hanem egy rendszer, amelynek már nagyjából értettük a nyelvét. Ez a különbség fontosabbnak bizonyult annál, mint hogy milyen alkalmazást akarunk végül építeni rá.

Ha már tudtuk vezérelni a gépet, egy nagyon egyszerű alkalmazást viszonylag könnyű lett volna összerakni: kapcsolat létrehozása, start, stop, sebesség, dőlésszög. Az eredeti bosszúságot nagyjából ez is megoldotta volna.

Csakhogy használat közben gyorsan kiderült, hogy ha már nálunk van a vezérlés, akkor érdemes egy kicsit továbbmenni. Egy futóedzésnél nem az a különösebben érdekes funkció, hogy a telefonon is meg tudom nyomni ugyanazt a gombot, ami a konzolon ott van. Sokkal érdekesebb, ha előre össze tudok állítani egy edzést, és a rendszer a megfelelő pillanatban maga váltja a sebességet vagy a dőlésszöget.

Innen már természetesen következett az edzésadatok kezelése és a többi olyan részlet, amitől az első Bluetooth-kísérlet lassan ténylegesen használható alkalmazássá vált.

Közben viszont volt egy kevésbé látványos döntési réteg is, ami több figyelmet igényelt, mint elsőre gondoltuk. Egy futópad vezérlése ugyanis nem ugyanaz a kategória, mint egy adminfelület vagy egy jegyzetalkalmazás. Ha ott hibázunk, legfeljebb rossz adat jelenik meg. Itt egy motor mozgat egy szalagot, amin közben áll valaki.

Ez egészen más súlyt ad például annak az egyszerű kérdésnek, hogy egy megszakadt Bluetooth-kapcsolat után mit tehet automatikusan az alkalmazás. Vagy annak, hogy létrejött kapcsolat esetén szabad-e bármilyen körülmények között magától elindítani a gépet. A sebesség és a dőlésszög kezelésénél sem elég annyi, hogy a protokoll szerint el lehet küldeni egy számot; azt is tudni kell, milyen értéknek van értelme az adott hardveren.

Itt elég jól látszott az a határ is, amit az AI körül hajlamosak vagyunk összemosni. Kódot nagyon gyorsan lehetett előállítani. Azt, hogy a terméknek milyen helyzetben mit szabad csinálnia, továbbra is nekünk kellett eldönteni.

Ha összeadom a tényleges fejlesztési időt, az első használható TreadPilot nagyjából két nettó nap alatt állt össze. Ebben benne volt a protokoll megértése, a Bluetooth-kommunikáció, az alkalmazás, a vezérlés és az a sok kisebb javítás, ami mindig csak akkor kerül elő, amikor az ember már valódi hardveren használja azt, amit épített.

AI-al dolgoztunk szinte végig. Segített a protokoll értelmezésében, a kódban, a hibakeresésben és abban is, hogy egy-egy irányt nagyon gyorsan ki tudjunk próbálni.

Ebből könnyű lenne azt a tanulságot levonni, hogy AI-al két nap alatt lehet appot fejleszteni. Valószínűleg ebből még egy egészen jól kattintható cím is kijönne. Csakhogy nekem nem ez maradt meg belőle.

A furcsa az, hogy a probléma három éve ugyanaz volt. Három éve is tudtuk volna, hogy mit kell csinálni: megérteni a Bluetooth-protokollt, implementálni, megírni az alkalmazást és végigtesztelni valódi hardveren. Technikailag nem vált egyik napról a másikra lehetségessé. Csak három éve nem érte volna meg nekikezdeni.

Egy évente negyvenezer forintba kerülő előfizetés lehet bosszantó, de ha a saját alternatíva heteket kér, akkor elég egyszerű a matek. Az ember fizet, használja a fizikai gombokat, vagy együtt él azzal, amit a gyártó adott. Ami most megváltozott, az számomra elsősorban ennek a munkának a belépési költsége.

Az AI itt nem csak azt tette olcsóbbá, hogy elkészüljön az első verzió. Azt tette olcsóbbá, hogy egyáltalán érdemes legyen elkezdeni. Ez finom különbségnek tűnik, de szerintem fontosabb annál, mint hogy egy adott feladatot húsz vagy ötven százalékkal gyorsabban végzünk-e el.

Amikor működni kezdett az alkalmazás, felmerült a kérdés, mi legyen vele. A legegyszerűbb válasz az lett volna, hogy semmi különös: nálam működik, arra készült, használom.

Viszont a munka egyik értékesebb része pont az volt, amit felhasználóként soha nem látni. Meg kellett érteni, hogyan kommunikál a futópad. Ha ezt bezárjuk egy saját alkalmazásba, a következő ember, akit ugyanez zavar, ugyanonnan kezdi majd a munkát.

Ezért végül úgy döntöttünk, hogy a TreadPilot ingyenes és open source lesz. Ebben nincs különösebben kifinomult üzleti stratégia. Egyszerűen furcsa lett volna egy olyan projekt végére újabb fizetős kaput építeni, amelyet részben éppen azért kezdtünk el, mert zavart egy meglévő zárt megoldás.

A publikus forrásnak ráadásul van egy másik előnye is. Mi egy konkrét futópaddal tudunk tesztelni. A FitShow protokollt viszont több gyártó és több modell használja, ráadásul nem biztos, hogy mindenhol teljesen ugyanúgy. Ezt egy zárt projektben nagyon nehéz lenne feltérképezni.

Nyílt repónál viszont megjelenhet valaki egy másik géppel, kipróbálhatja, küldhet hibajelentést, protokolladatot vagy akár javítást. Legalábbis elméletben.

Ez ugyanis az első open-source projektünk. Kódot már adtunk át sokszor, dolgoztunk saját és ügyféltermékeken is, de publikus repót úgy menedzselni, hogy elvileg bárki megjelenhet benne egy issue-val vagy pull requesttel, új helyzet lesz.

Ezért most olyan kérdések is előkerülnek, amelyeknek semmi közük a Bluetooth byte-jaihoz. Mit csinálunk, ha valaki egy olyan futópad támogatását kéri, amihez nincs hozzáférésünk? Hogyan fogadunk el olyan módosítást, amely fizikai hardvert vezérel, de nálunk nem reprodukálható? Hol legyen a projekt határa, ha valaki egészen más irányba vinné tovább?

Ezekre még nincs kiforrott válaszunk. Van contributing guide, security policy, dokumentált protokoll és igyekeztünk már az elején rendezni azokat az alapokat, amelyekről tudtuk, hogy szükség lesz rájuk. De valószínűleg az első valódi külső issue vagy contribution után többet fogunk érteni az open-source működéséből, mint most az összes előzetes szabályból együtt.

Ezt most nem problémának látom, hanem a projekt következő részének. Az első két napban azt tanultuk meg, hogyan beszél a futópad. Most majd azt tanuljuk, hogyan kell úgy továbbadni ezt a munkát, hogy más is hozzá tudjon tenni.

Három évig nem változott lényegesen sem a futópad, sem az, ami zavart benne. Ami megváltozott, az az volt, mennyi munkát kellett vállalni ahhoz, hogy érdemes legyen megoldani.

Ezért a TreadPilot után kevésbé az foglalkoztat, hogy AI-al hány százalékkal lettünk gyorsabbak. Sokkal érdekesebbnek tűnik az a rengeteg túl kicsi probléma, amelyek eddig soha nem jutottak el odáig, hogy valaki szoftvert írjon rájuk. Egy furcsa belső folyamat, egy régi gép, egy rosszul használható eszköz vagy egyszerűen valami, ami minden héten elvesz húsz percet, de soha nem annyit, hogy projekt legyen belőle.

Ezekből korábban könnyen maradt bosszúság. Most egyre többször lehet belőlük az, hogy megnézzük, mi történik a háttérben, csinálunk egy első verziót, kipróbáljuk, és csak utána döntjük el, érdemes-e továbbmenni.

Nálunk most egy futópad került át ezen a határon. Három évig zavart. Aztán végre elég olcsó lett kíváncsinak lenni.