fbpx

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

Opublikowane przez Jerzy Wickowski w dniu

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

  1. Stan początkowy, dioda: zielona, stan: wolny
  2. Gracz przychodzi i naciska przycisk, dioda: czerwona, stan: zajęty
  3. Gracz naciska przycisk i odchodzi, dioda: zielona, stan: wolny

Wstępne wymagania

  1. 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.
  2. 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.
  3. 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.

A tak wygląda gotowa konstrukcja.
istablebusy-device



Czy to był wartościowy artykuł? Zapisz się, a wyślę Ci dwa ebooki o czystym kodzie oraz będę informował Cię o nowych postach

0 Komentarzy

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

[contact-form-7 404 "Nie znaleziono"]

Zapisz się

Wyślę Ci dwa dokumenty mówiące o jakości kodu. Dodatkowo będę Cię informował o nowych postach i nowościach.