System śledzenia czasów

[majkel]

Majkel, znajdzie jakiś hosting na to cholerstwo?

http://online.miataminichallenge.pl/

powinien się synchronizować z gitmastera. ssl będzie potem, jak certyfikat dogeneruję.

Po
eM

[nick.es]

Dzięki, Majkel!

Majkel, znajdzie jakiś hosting na to cholerstwo?

powinien się synchronizować z gitmastera.

Na ten moment to nam w zupełności wystarczy. Na jesień będziemy potrzebować wjazdu na serwer przez SSH i/lub Twojego supportu w konfiguracji/utrzymaniu środowiska serwerowego i bazy danych.

ssl będzie potem, jak certyfikat dogeneruję.

W tej chwili nie ma to dla mnie żadnego znaczenia.


To jeszcze mi powiedz, że umiesz tam postawić jakiś sprawny WebSocket server
A może ktoś inny reflektowałby na tego questa? Jak coś, to zapraszam do naszego jam session: https://github.com/MX-5ClubPoland/MMCLapTimer/issues/24

[majkel]

Na jesień będziemy potrzebować wjazdu na serwer przez SSH i/lub Twojego supportu w konfiguracji/utrzymaniu środowiska serwerowego i bazy danych.

No problem my friend Niedługo sprzątanie w środowisku testowym, chyba trzeba będzie trochę zasobów tam od razu przewidzieć

To jeszcze mi powiedz, że umiesz tam postawić jakiś sprawny WebSocket server

Rozpędzasz się Ale bardzo dobrze, lubimy takie klocki Coś wykombinujemy, ograniczeń środowiskowych praktycznie nie mamy, dopóki nie ruszamy parametrów kernela.

Po
eM

[nick.es]

Spokojnie, spokojnie, to tylko plany. Deadline milestone'a postawiłem wstępnie na marzec 2017

(https://github.com/MX-5ClubPoland/MMCLa ... middleware)

[majkel]

wstępnie na marzec 2017

[nick.es]

wstępnie na marzec 2017

To nie są tanie rzeczy!

Mój pedantyzm nie pozwala mi na napisanie takiego modułu w normalnym, nieodpłatnym czasie ( ). Ale tak się składa, że w moim otoczeniu rusza właśnie podobny projekt i możliwe, że WebSocket server będzie całkowicie autonomicznym modułem. Przy dobrych wiatrach mogłoby się udać z tego skorzystać. Nie wiem jeszcze na jakich zasadach, ale przecież od czego są dotacje unijne?

Jeśli projekt, o którym mówię, dojdzie do skutku, to taki moduł serwera będzie pewnie gotowy przed końcem roku. Może będzie się dało podciągnąć nasz użytek pod beta testy, czy coś w tym stylu...

[wroclover]

dotacje unijne?

tak, słucham.

[majkel]

To nie są tanie rzeczy!

To akurat dobrze wiem
Deadline na marzec 2017 oznacza raczej że wtedy muszą być testy gotowego rozwiązania zakończone, jeśli miałoby pracować w sezonie 2017

Jeśli projekt, o którym mówię, dojdzie do skutku, to taki moduł serwera będzie pewnie gotowy przed końcem roku. Może będzie się dało podciągnąć nasz użytek pod beta testy, czy coś w tym stylu...

Albo jednak wykorzystać coś z otwartą licencją maksymalnie ile się da. Ale to bardziej dyskusja na na gita, czytam historię, jutro do paru punktów coś dopiszę.

Po
eM

[nick.es]

Albo jednak wykorzystać coś z otwartą licencją maksymalnie ile się da.

A są takie? W fabryce szukamy już jakiś czas i wszystko wskazuje na to, że trzeba będzie napisać coś swojego...

[majkel]

A są takie?

Tak na szybko z pamięci. Open to na przykład Achex albo jwebsocket.org. Jest też ciekawy komercyjny lightstreamer, oprócz licencji płatnych jest licencja open (ze zredukowanym zakresem funkcjonalności co prawda ale jak czegoś brakuje to dla projektow non-profit można spróbować coś wyszarpać extra). Jak przejrze moje zabałaganione zakładki to pewnie coś się jeszcze znajdzie.

Po
eM

[jqb]

Ja się nie znam, ale na Node.js'ie to jest chyba sporo rozwiązań? Np. socket.io

[nick.es]

Ale Wy mówicie o usłudze korzystania z WebSocket servera, a ja ma na myśli produkt, który można odpalić u siebie.

[majkel]

a ja ma na myśli produkt, który można odpalić u siebie.

no ja też, zupełnie własne instalacje.

Po
eM

[jqb]

+1, przecież to odpalasz u siebie.

[majkel]

+1, przecież to odpalasz u siebie.

nickesh chyba spojrzał na wersje licencjonowania w trybie wynajmu usług. Te, które wyżej wrzuciłem mają też taki tryb, ale nie wyłącznie. O node.js zupełnie zapomniałem Zrobimy reasearch i jakiś poligon doświadczalny dla sprawdzenia funkcjonalności, coś się na bank znajdzie nam odpowiadającego

Po
eM

[majkel]

Open to na przykład Achex

EDIT: Achexa wrzuciłem na nasze środowisko testowe. Z broadcastem nie będzie problemu. Konfiguracja jeszcze monent potrwa, bo dokumentacja jest tak żadna, że formaty niektórych plików konfiguracyjnych trzeba ustalać na podstawie analizy źródeł. Ale coś z tego bedzie na pewno.

Po
eM

[nick.es]

Działaj, działaj, Majkel. Jak tylko spadnie deszcz, ja też biorę się do roboty

[nick.es]

Czy jest tu ktoś od MSSQL-a?

Potrzebuję wypychać dane z bazy MSSQL do jakiejś usługi online (innej bazy SQL, albo Firebase'a, albo jakiegoś mojego własnego API). Jakaś replikacja, albo procedura... Istotne jest to, że baza MSSQL ma niestabilne połączenie z siecią, więc potrzebna jest jakaś kolejka, potwierdzanie odbioru danych i ponawianie wysyłki w razie niepowodzenia. Danych nie jest dużo (najwyżej kilka kB/s). Jednak muszą być wysyłane niezwłocznie, jak tylko wpadną do tabeli w bazie.

Podsumowując: "one-way-synchro" małych porcji danych jednej tabeli MSSQL-a do jakiejś usługi online, z gwarancją dostarczenia, trigerowane pojawieniem się danych w tej tabeli.

Robiłem to kiedyś replikacją w MySQL-u. Spełniało to wszystkie w/w wymagania. Jednak z microsoftowym SQL-em mi nie po drodze. Przydałaby się pomoc.

[mike_d]

hej - ja w tym siedzę, wyślij jakies namiary do siebie na priv - wieczorem możemy pogadać

[nick.es]

Mike_d dołącza do projektu. Stworzy oprogramowanie, które będzie eksportować czasy okrążeń z bramki Geparda do bazy danych online. Dziękujemy za zaangażowanie

Z technicznego punktu widzenia, będzie to polegało na zapisywaniu plików z wynikami do jednego folderu na laptopie podłączonym do bramki. Ten folder podepniemy do Google Drive'a, albo Dropboxa (czy czegoś w tym stylu). A więc kolejny etap projektu...

Potrzebujemy oprogramowania, które będzie pobierać wyniki z chmury Google Drive. Najlepiej, gdyby dało się w tym celu podpiąć pod triggery (eventy, wyzwalacze) Google'a. Po każdej pomyślnej synchronizacji Google Drive, przenosimy nowe wyniki do REST-owego API.

Może ktoś z Was chciałby się tym zająć?

Trzeba sprawdzić, jakie możliwości ma API Google Drive, napisać oprogramowanie kolektora, które podepnie się pod eventy, wyciągnie dane i wypchnie je do REST-owego API. A może da się to zrobić samą konfiguracją Drive'a? Albo wykorzystać Firebase'a? Rozwiązanie musi zagwarantować dostarczenie wszystkich danych do API. Szybkość działania nie jest aż tak istotna. Jeśli soft ma być backendowy, to najlepiej, jak będzie w PHP7.

[TerminatorPi]

Z technicznego punktu widzenia, będzie to polegało na zapisywaniu plików z wynikami do jednego folderu na laptopie podłączonym do bramki. Ten folder podepniemy do Google Drive'a, albo Dropboxa (czy czegoś w tym stylu). A więc kolejny etap projektu...

Jest jakaś całościowa rozpiska z architekturą? Bo z tego kawałka odnoszę wrażenie, że straszliwie usiłujecie się złapać lewą ręką przez prawe ucho.

[mike_d]

Jest jakaś całościowa rozpiska z architekturą? Bo z tego kawałka odnoszę wrażenie, że straszliwie usiłujecie się złapać lewą ręką przez prawe ucho.

Też mi się na początku tak wydawało ale mówimy tu o wyjątkowo specyficznym systemie i otoczeniu sprzętowym . Coś więcej będzie można powiedzieć jak "wejdziemy" do bazy źródłowej.

Właśnie, Nickesh - masz już dostępy?

[nick.es]

Bo w sumie trochę tak jest - masz rację . Jednak to wynika z dwóch istotnych powodów.


1. Ograniczony dostęp deweloperski.
Cały system pomiarowy Gepard jest, powiedzmy, trudno dostępny. Nie mam do niego wglądu. Bramka i laptop używają zamkniętego, nieudostępnionego i nieudokumentowanego oprogramowaniu firmy RFID Solutions. Do tej pory nie udało mi się pozyskać żadnych informacji na ten temat. Wiem tylko, że bramka pomiarowa jest podłączona do laptopa, na którym jest jakieś oprogramowanie, używające jakiejś bazy danych MSSQL. Nie wiem jaka to wersja, ani licencja SQL Servera. Nie wiem w czym jest napisane to oprogramowanie. Czekam na możliwość zdalnego zalogowania się do tego laptopa, żeby dowiedzieć się czegokolwiek. Developowanie na tym laptopie odpada. Jakakolwiek ingerencja musi być jak najprostsza i jak najbardziej standardowa, uniwersalna. Czas na testowanie też jest ograniczony. Pojedyncza procedurka w SQL-u wydaje się najprostszym i najbezpieczniejszym sposobem wydobycia danych z tej bazy.

2. Niestabilność systemu i połączenia sieciowego.
System pracuje w polowych warunkach, często na mobilnym łączu, które często timeoutuje. Oprogramowanie bramki też się czasem lubi wywalać. Laptop jest na Windowsie 7. Czasem mocno zmula i się wiesza. Normalnie musielibyśmy napisać jakiś program, który będzie odkładał wyniki do jakiejś offline'owej kolejki i commitował ją po odzyskaniu połączenia, przez niestabilne połączenie. Musiałby to robić transakcyjne - oczekiwać potwierdzenia odbioru, ponawiać nieudane doręczenia, zachowywać kolejność kolejki itd... Nie mamy czasu, żeby samemu takie coś kodować. No i po co? Szybkość działania nie jest tu priorytetem. Najważniejsze jest, żeby synchronizacja była w pełni skuteczna i stabilna - odporna na przerwy w działaniu sieci i systemu operacyjnego. Po prostu nie może pomijać żadnych zarejestrowanych wyników. Dlatego zainstalowanie tam jakiegoś gotowca, typu Dropbox, załatwiłoby sprawę.


Tu masz kształt systemu w wersji z 2016 roku:

MMC 2016 Overall Architecture & Deployment

MMC Overall Architecture & Deployment.png (75.7 KiB) Przejrzano 1581 razy

Dawid (operator) przepisywał ręcznie czasy z ekranu laptopa (z GUI do Geparda) do arkuszy kalkulacyjnych Google'a. Appka w JavaScriptcie pobierała je bezpośrednio ze spreadsheetów, przeliczała i wyświetlała rankingu.


A tak to jest projekt wersji na 218:

MC 2018 Overall Architecture & Deployment

MC Overall Architecture & Deployment.png (139.75 KiB) Przejrzano 1581 razy

Teraz appka będzie pobierać dane biznesowe (dane kierowców, samochodów, harmonogram trackdaya itd.) z REST-owego API (obsługiwanego w backendzie przez PHP z bazą MySQL). Ten sam backend będzie streamował czasy okrążeń z bazy MySQL do appki, za pośrednictwem Firebase'a, albo jakiegoś innego serwera WebSocketowego. Operator nie będzie już korzystał z czasów, wyświetlanych na laptopie. Nie będzie nic przepisywał. Będzie mógł odrzucać niepoprawne wyniki prosto z appki (ona będzie informowała backend przez REST-owe API, a ten wtórnie będzie przekazywał odrzucenie wyniku przez stream do pozostałych instancji appek).


Schemat bazy danych MySQL na serwerze z logiką biznesową:

Business Logic MySQL Database scheme

database_scheme_20180128.png (144.76 KiB) Przejrzano 1498 razy

EDIT 28.01.2018: Update schematu bazy danych.

[nick.es]

Właśnie, Nikesh - masz już dostępy?

Nie. Wciąż czekam, aż Dżunior będzie miał wolne 10 minut. Dżunior?!

[TerminatorPi]

Ok. To ma sens (chociaż na mój gust za dużo magicznych nowoczesnych rzeczy, które dzieją się same, ale ja już chyba stary jestem )

[nick.es]

Takie czasy. Cała infrastruktura na autonomicznych, hermetycznych mikroserwisach.

To jak z tym API do Google Driver? Ktoś ogarnia temat?

[Alex]

ale o czym wy w ogole mowicie? Bedzie jakis nowy automagiczny super-system pomiaru czasu na MC2018 ?

[nick.es]

No tak. To drugi i trzeci etap projektu. Chcemy wyręczyć Dawida, który ręcznie przepisuje czasy. Mają się publikować w appce automatycznie.

Tylko przydałaby się pomoc w ogarnięciu API Google Drive.

[Alex]

Niestety nie pomogę, nie moja dziedzina

A jakiś lifting apki na tel jest przewidziany?

wytapatalkowane

[nick.es]

Tak, zupełnie nowa appka. Bogatsza i lepiej przystosowana do telefonów. Z podglądem wszystkich rankingów na żywo, w tym generalki sezonowej. Będzie można z niej wydrukować uzupełnione oświadczenia i BK. Organizatorzy nie będą musieli już wklepywać chipów RFID, ani czasów okrążeń do excela. Będą mogli moderować wyniki z telefonu, przez appkę właśnie. Docelowo to cały sezon będzie można zorganizować przez appkę. Razem z zapisami na rundy i sezon, włącznie z płatnościami. Ale to dopiero etap czwarty.