(10 lat temu) 21 kwietnia 2016 o 09:03
Sklepów też nie robię.
Jak strona sklepu padnie, to klient będzie niezadowolony, ale poczeka lub znajdzie inny, a na przesyłkę i tak działa. Chyba że mówisz o tradycyjnych (lista towarów na kasach, stan magazynowy itp.).
Przy wypożyczaniu roweru klient chce mieć efekt natychmiast, zwłaszcza że alternatywy nie ma. System jest medialny, więc każda awaria będzie głośno komentowana.
2000 to kosztuje porządna obudowa serwerowa lub ups bardzo entry level. 1000h ~40 dni, nie jest wybitnym wynikiem. W robocie mam serwer dyskowy za około 5000 i spokojnie robiłby roczne uptime-y, gdyby nie dłuższe przerwy w prądzie (>20min, bo tyle wytrzymuje ups, na stacjach roboczych przeważnie i tak jest krótszy, więc nie potrzeba dłuższego, bo robota leży).
Z tym wstawaniem, to ciekawa w sumie sprawa jak się system zachowa przy padnięciu serwera, np. jak zareagują rowery na utracone połączenie.
Wolę, żeby wydano milion publicznych pieniędzy na coś solidnego niż gdyby przyoszczędzili. Widzę jak to działa codziennie na naszych drogach rowerowych, gdzie w przetargach dominuje cena. Potem już w pierwszym roku po oddaniu nawierzchnia pęka i się rozłazi.
Pewnie się da za 100k oprogramować taki system, tylko to trochę brzmiało jak robota studenciaka lub pana Zdzisia w garażu.
" Pracując samemu może i nie przewidzę wszystkiego... to fakt, ale rzeczy których nie przewidze da się momentalnie poprawić...a dane na testach są nieprawdziwe? to co to za testy? rozumiem, że skoro siedzisz w branży to jesteś świadomy ilości i ile rodzajów testów wypada zrobić przed oddaiem oprogramowania... jakoś nie wierzę, żeby jakikolwiek przemyślany system się wykrzaczył gdy dostanie prawdziwe dane użytkowników"
Specyfika mojej branży jest inna, to nie są systemy bazodanowe i część rzeczy bardzo trudno się symuluje (lub trwa to bardzo długo), żeby wykonać testy. Poszczególne elementy można sprawdzać do bólu i działają stabilnie. Problem w tym jakie dane przyjdą i co algorytmy zwrócą, czy to będzie miało sens.
Generalnie mamy sensory i na podstawie przetworzonego sygnału musimy użytkownikowi podać aktualną sytuację. Już sama rozbieżność między teoretycznym działaniem sensora, a rzeczywistym sprawia problemy i trzeba wszystko stroić, dopasowywać, kalibrować. Tego na biurku nie zrobisz, trzeba zmontować cały system i uruchomić w rzeczywistych warunkach. Dodaj do tego skomunikowanie się setek elementów, logikę działania i czas rzeczywisty. Na początku mało co gada ze sobą prawidłowo.
Oczywiście, że klient bez badań i sprawdzeń nie zapłaci. Mniej więcej też orientuję się ile kasy idzie za opóźnienia i potrafi iść w miliony.
Ale przynajmniej robota ciekawa :)
0
0
