On Wednesday, July 29, 2015 at 12:10:56 PM UTC+2, Piotr Chamera wrote:
> a "ekstremalna sytuacja", to rzeczywisty efekt działania takiego
> nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
> wyborów.
Rozmawiamy o jednym elemencie tego systemu: zbieranie danych.

> > Zaczęli projektować i skopali, jakby po prostu zrobili
>
> to nie jest proste (albo może precyzyjniej byłoby powiedzieć, że to nie
> jest wielki system [czyli w pewnym sensie prosty], ale jednak kilka
> rzeczy wymaga przemyślenia i zaprojektowania).
Jak pisałem kilka postów wcześniej: nie dziwię się że padło jako
całość. Dziwię się, że stracili dane, że trzeba było wprowadzać od
nowa, że czekali aż tak długo... i nie wiem jakie tam jeszcze były problemy.

>
> > 1) połączenie
>
> obsługujemy tylko jedno połączenie jednocześnie? czy więcej? jeśli
> więcej, to ile? wszystkie 2500 jednocześnie (bo tak też może się
> zdarzyć)? jeśli jedno, to co jeśli klient się połączył i nie przesyła
> danych, a inni czekają? jeśli pula połączeń jest ograniczona, to co
> robimy z nadmiarowymi? itd...
Co masz na myśli, pisząc 'itd'? Nie znam specyfikacji tegoż systemu.
Uczepiłem się tych 2500 paczek danych na 3600 sekund, co nie wydaje się
zbytnio trudne. Jaki średni rozmiar miała paczka? Jeśli mamy ograniczoną
pulę połączeń, to co jest złego w odrzuceniu?


> na dalszych etapach masz podobne wybory, które wpływają na przyjęte
> rozwiązania i musisz wybrać tak, aby żadna sekwencja możliwych zdarzeń
> nie prowadziła do awarii...
Zgodzę się, że zgranie każdego, w pobieżnej ocenie 'łatwego', systemu w
jedną niezawodną całość, może okazać się bardzo trudne. Ale żeby padło na
etapie zbierania danych i straciło spójność, jakoś wydaje mi się dziwne.

Ja miałem tego typu problemy, gdy łączyłem zbieranie danych z ich opracowaniem.
Gdy te etapy rozdzielam, to ilość problemów na etapie pobierania danych
spadła prawie do zera. Z dalszym opracowaniem danych też mam nie mało
problemów, ale cóż, każdemu zdarzają się błędy w kodzie.

Pozdrawiam