Aktywne Wpisy
rales +178
#ralesnatinderze <-- tag do obserwowania
EDYCJA 4
Dziewczyna nr 30 (spotkanie pierwsze i drugie)
Zgodnie z założeniami, obiecałem sobie, że tym razem podejdę bardziej jakościowo. Mniej dziewczyn przesuwałem w prawo, jeżeli w konwersacji widziałem, że druga strona odpisuje bez chęci czy zainteresowania, to nie ciągnąłem, tylko usuwałem parę lub przestawałem dalej pisać.
Nr 30 mieszka ok. 80 km ode mnie. Zesparowało nas przypadkiem, gdy przejeżdżałem obok jej miejscowości. Nie zaprosiłem jej na
EDYCJA 4
Dziewczyna nr 30 (spotkanie pierwsze i drugie)
Zgodnie z założeniami, obiecałem sobie, że tym razem podejdę bardziej jakościowo. Mniej dziewczyn przesuwałem w prawo, jeżeli w konwersacji widziałem, że druga strona odpisuje bez chęci czy zainteresowania, to nie ciągnąłem, tylko usuwałem parę lub przestawałem dalej pisać.
Nr 30 mieszka ok. 80 km ode mnie. Zesparowało nas przypadkiem, gdy przejeżdżałem obok jej miejscowości. Nie zaprosiłem jej na
Kryspin013 +129
Kiedy twoją jedyną cechą osobowości jest błona dziewicza...
#najka #bekazprawakow #neuropa #heheszki #bekazkatoli
#najka #bekazprawakow #neuropa #heheszki #bekazkatoli
Zrobiłem prosty system IoT bazujący na MQTT i JSONach. Serwer odbiera wiadomość, robi dispatch i przekazuje żądanie do konkretnego interfejsu, który parsuje requesta, składa odpowiedź i publikuje na MQTT. Kolekcjonowanie danych do złożenia odpowiedzi naturalnie odbywa się na różne sposoby (komunikacja po fizycznych interfejsach z czujnikami) w zależności co jest żądane. Jednak czuję, że architektonicznie mogłoby coś zagrać lepiej jeśli chodzi o budowanie odpowiedzi.
Chodzi mi po głowie stworzenie jakiegoś generycznego buildera, ale każdy pomysł finalnie kończy się wnioskiem o braku korzyści z takiego rozwiązania, bo jest już zrobiony dispatch i włożenie dodatkowej warstwy abstrakcji jest zbędne. Czy znacie jakieś dobre wzorce na tego typu problemy?
Zdaje sobie sprawę, że komunikacja po MQTT powinna wyglądać w inny sposób, ale przez pewne ograniczenia musi tak to wyglądać.
#programowanie #programista15k #cpp #iot #embedded
Zewnętrzny interfejs zatrzymaj w aplikacji serwera i tam zrób logikę która będzie parsować requesty i na tej podstawie, delegować konkretne zadania do
Dzięki Panowie za wyczerpujące odpowiedzi, generalnie komunikacja powinna odbywać się tak jak napsaliście. MQTT kładzie raczej nacisk na podejście asynchroniczne. Faktycznie obecnie jest tak, że jeśli zmieni się jakieś pole requesta, to pokłosiem tego są zmiany w zbyt wielu miejscach.
@SpinOff Chodzi mi tutaj o problem czysto software'owy, tzn. jak skonstruować buildera dla tych odpowiedzi. W tym przypadku chodzi mi o jakąś klasę
@Parseval: jak nie masz wspólnego zachowania dla wiadomości to co możesz abstrachować? Powinieneś mieć dispatchera, który robi switch po typie wiadomości przychodzącej i tak robisz logikę dla każdej wiadomości