Gdy piłkarzyki zajęte są – pomysł

W wielu firmach IT dość często można spotkać piłkarzyki. Jest to doskonały sposób na odświeżenie umysłu i dobry sposób na poprawienie relacji w zespole. Pomimo, że jest to świetna rozgrywka, może czasami irytować. Nie mam na myśli przegranej, lecz coś gorszego. Kiedy już uda się zebrać pełny czteroosobowy zespół. Dochodzicie na miejsce rozgrywki. I czujecie się zaskoczeni niczym niemiec w okopie. Stół jest zajęty. Możecie teraz iść szukać innego stołu, który też może być zajęty, albo czekać. W każdym razie zapał opada. Czas się marnuje i tracą na tym wszyscy, i pracownicy, i pracodawca. Co z tym zrobić?
Pomysł na rozwiązanie
Sam podirytowany pewnego dnia pomyślałem, że przecież szkoda tak chodzić na darmo. Przecież osiem informatycznych nóg nie musi się niepotrzebnie nadwyrężać. Narodziła się myśl w mojej głowie, aby to jakoś zooptymalizować. Przecież świetnie by było abym mógł sprawdzić wcześniej, czy stół jest wolny, czy zajęty. I zacząłem układać jak by to mogło wyglądać. Kilkukrotnie musiałem przystopować, bo udawało się nieźle odjechać z pomysłami. Na szczęście utrzymałem projekt stosunkowo prosty. Zdefiniowałem zatem MVP. Poprzez wstępne stany aplikacji i podstawowe wymagania.
Stany aplikacji
- Stan początkowy, dioda: zielona, stan: wolny
- Gracz przychodzi i naciska przycisk, dioda: czerwona, stan: zajęty
- Gracz naciska przycisk i odchodzi, dioda: zielona, stan: wolny
Wstępne wymagania
- Sprawdzanie stanu
Tutaj miałem dwa warunki. Po pierwsze to musi być proste, a po drugie musi być dostępne z każdego urządzenia. W związku z tym wybór był dość oczywisty. Interfejsem użytkownika będzie strona internetowa. Dodatkowo doszedłem do wniosku, że konieczne będzie jeszcze dodanie odświeżana na żywo oraz informacji ile upłyneło od rozpoczęcia meczu. - Zmiana stanu
Nad tym rozwiązanuem myślałem najwięcej. Przemknęło mi wiele pomysłów, takich jak: wykrywanie ruchu piłki, wykrywanie ruchu w okolicy stołu, detektor wstrząsów, czujniki na rączkach. Część z nich wciaż mi się podoba, jednak wybrałem wersję najprostrzą, czyli przycisk + dwie diody, czerwona zajęte, zielona wolne. Ma to oczywiście pewne wady, by gracze muszą pamiętać, aby włączyć przed meczem oraz wyłączyć po. Jednak działa. - Backend
Tutaj spędziłem najmniej czasu nad rozwiązaniem. Lubię .NET, więc wybrałem WebAPI + EF + SignalR
Co dalej?
Taki był pomysł, udało mi się go zrealizować. Działa on na produkcji już 9 miesięcy. Mogę zatem, na podstawie danych, stwierdzić, że średno mecz trwa pomiędzy 18, a 21 minut. W następnym wpisie opiszę dlaczego wybrałem RaspberyPi oraz kilka zdań o elektronice.
0 Komentarzy