•  

    pokaż komentarz

    Niestety, z pewnych względów, dokładność obliczeń zmiennoprzecinkowych, wykonywana w tym celu, była daleka od ideału. W efekcie, 1 sekunda wyliczana przez baterię nie była równa rzeczywistej sekundzie. Po 100 godzinach pracy, system mylił się już o 0,34 sekundy.

    To nie tak. Oni zapamiętywali pomiary czasu w postaci liczby zmiennoprzecinkowej (konkretnie typu float). Liczba zmiennoprzecinkowa ma ograniczoną liczbę cyfr. W pewnym uproszczeniu im więcej cyfr jest przed przecinkiem tym niej można zapisać po przecinku. Ponieważ zegar doliczył już do przeszło 360 000 sekund, zostało już mało miejsca na to co może znaleźć się po przecinku. Rakieta od jednego punktu pomiarowego do następnego przelatuje w ułamku sekundy a ze względu na ograniczoną liczbę cyfr po przecinku okazuje się, że czas w punkcie A jest taki sam jak czas w punkcie B (bo oba ulegają zaokrągleniu do takiej samej liczby), program chce wyliczyć prędkość i dostaje dzielenie przez zero.

    Błąd okazał się jednak o tyle poważny, że doprowadził do nieprawidłowej pracy dopalaczy lądownika. Konsekwencją tego było zbyt bliskie podejście, a co za tym idzie, spalenie się sondy w atmosferze Marsa.

    To tez nie tak. Oni zauważyli, że jednostki się nie zgadzają przy obliczeniach dotyczących ciągu silników i to poprawili. Ale przeoczyli, to że odchyłek kursu wywołany wiatrem słonecznym też był liczony w niewłaściwych jednostkach, to była tak mała liczba w skali kosmicznej, że nikomu nie rzuciła się w oczy. Wiatr słoneczny w ciągu kilkuletniej misji przemieścił sondę o 100km - czyli tyle co nic, no ale przy wchodzeniu na orbitę planety nawet przesunięcie o te 100km ma znaczenie i trzeba dokonać odpowiedniej korekty kursu.

  •  

    pokaż komentarz

    Tak to jest jak robisz coś na zamówienie i działu handlowego nie obchodzi, że nie da się zrobić porządnego softu w takim czasie jak deklarują, więc tnie się tam, gdzie się da. Czyli na testach (╯°□°)╯︵ ┻━┻

  •  

    pokaż komentarz

    Co za poj@#!na logika winny programista za to że trzymali je 100h zamiast 8 to tak jakby obwiniac producenta noża że klient sam się dzgnal XD a nawet jeszcze bardziej absurdalne

    •  

      pokaż komentarz

      @Krafti: bo wiesz, dev powinien przewidzieć że user trzyma nóż za ostrze, właśnie dla takich wysrywów są te wszystkie debilne ostrzeżenia w stylu "nie rób tostów w kąpieli, bo ci prąd przypierdzieli".

    •  

      pokaż komentarz

      @Krafti: to nie do konca trafna analogia. Dzialanie noza jest dosyc oczywiste. Dzialanie oprogramowania nie zawsze jest przewidywalne. Stad tez kilkadziesiat lat rozwoju calych dziedzin zapobiegania nieprzewidzianym sytuacjom

    •  

      pokaż komentarz

      @Krafti: Oczywiście że błąd jest programistów. Urządzenie nie miało mieć ograniczenia do pracy tylko przez 8 godzin ale taka była specyfika jego pracy w terenie. I już mniejsza z tym, że było to znaczne ograniczenie możliwości urządzenia, to nie mieli pojęcia przez tyle lat, że taki błąd istnieje a co za tym idzie nikt nie został poinformowany o konsekwencjach tak długiej pracy.

    •  

      pokaż komentarz

      @tomaszs @tomaszs no dlatego kupują oprogramowanie za fch?# milionów z pełną dokumentacja które ma spełniać funkcje x i być obsługiwane przez przeszkolonych ludzi za kolejne kilka baniek XD no ta działa 8h plus margines błędu ludzkiego, a ch?# tam zostawimy na 100h xD

    •  

      pokaż komentarz

      Komentarz usunięty przez autora

    •  

      pokaż komentarz

      @tomaszs programista ma przewidzieć że użytkownik debil Nie posłucha się instrukcji XD dlatego w UK zakazuja noży bo zamiast kroić chleb jak producent chciał to ludzi dzgaja XD wina producenta noży

    •  

      pokaż komentarz

      @Tasde no to jak to jest zamówili urządzenie co miało działać 8h. Programista napisał. Sprawdzili. Działa 8h. Wymogi przetargu spełnione. Kilka szczebli przyklepalo każdy gruby Chajs zgarnął XD ch?$ wypadek wina programisty szkoda że nie tego co zamawiał ani tych co podpisy pod wyplatami składali xD

    •  

      pokaż komentarz

      @Krafti: Co ty za bzdury wygadujesz xD Oczywista wina programistów, oni są od pisania programów i mają się na tym znać, nie znali się i to oni spieprzyli robotę. Program nie miał w specyfice, że ma działać 8 godzin, tylko realnie tak był wykorzystywany bo system był mobilny co NIE MA oznaczać, że program może się wysypać po dłuższym czasie pracy niż zakładała doktryna - bo to jest wojsko a nie gra komputerowa i masz tutaj realną sytuację w której konieczne było używanie go dłużej ponieważ stacjonowali i nie mogli go wyłączyć przez strasznie długi czas włączania.
      I co ważniejsze i nie wiem czemu to pomijasz: w instrukcji nie było informacji że nie może tyle godzin pracować ponieważ NIE WIEDZIELI o złym liczeniu czasu przez system.

    •  

      pokaż komentarz

      Co za poj$@$na logika winny programista za to że trzymali je 100h zamiast 8 to tak jakby obwiniac producenta noża że klient sam się dzgnal XD a nawet jeszcze bardziej absurdalne

      @Krafti:
      Albo tak jakby obwiniać projektanta który wykonał projekt domu dla dwojga że ten dom się zawalił w sytuacji gdy do tych dwojga przybyli goście bądź pojawiło się potomstwo.
      Jeśli od programisty oczekuje się myślenia i pracy głową to branie pod uwagę konsekwencji nieoczywistych dla klienta własności kodu jest chyba niezbędne.
      Prace niewymagające używania mózgu są zazwyczaj niżej wyceniane .

    •  

      pokaż komentarz

      @Krafti: mysle ze w ogole jesli ktos uwaza ze wine za cokolwiek ponosi uzytkownik to nie nadaje sie na programiste. Wine zawsze ponosi zle zaprojektowany system. Nie mowie tego jak obarczanie kogokolwiek bledami drugiej strony. Ale tylko wytworca oprogramowania ma zdolnosc do zapobiegania bledom przez rozwijanie oprogramowania i wprowadzanie zabezpieczen. Uzytkownik tej zdolnosci nie ma. Wiec obwinianie strony bez mozliwosci przez strone z mozliwosciami jest po prostu niedorzeczne. Oczywiscie mozna liczyc na to ze uzytkownik przejdzie szkolenie, przeczyta instrukcje itd. Ale to nie jest zaden wymog korzystania z oprogramowania. Nikt takich wymogow nigdy nie wprowadzil i nie wprowadzi. Poniewaz odbiorca systemu ma korzysc gdy system dziala a on nie marnuje czasu. Oczywiscie moznaby tez przyjac ze jednak jest obowiazek doglebnej znajomosci systemu przed jego uzyciem, rowniez zalozen ukrytych. Tylko wtedy uzytkownik musialby byc programista i to bardzo zaawansowanym. Pytanie jaki bylby wtedy cel programowania jesli nikt poza tworca oprogramowania i kilkoma osobami by nie moglo z niego korzystac...

  •  

    pokaż komentarz

    nikt też nie patrzy na jakość kodu, a co za tym idzie, na łatwość utrzymania i rozwijania oprogramowania
    Nie no, wcale.

    Sprawia to, że dużo łatwiej jest wprowadzić nowe błędy podczas rozwoju tak skonstruowanego oprogramowania.
    Po to się testy pisze. No, ale jak programiści są z łapanki...

    •  

      pokaż komentarz

      @tarrin: Myślisz, że kadrę zarządzającą obchodzą jakieś praktyki czystego kodu? Ma działać i to jak najszybciej i tyle. Zresztą do niedawna praktyką było zlecanie pracy zdalnie Hindusom, więc o jakich testach tu mowa.

    •  

      pokaż komentarz

      @Legion616:

      Myślisz, że kadrę zarządzającą obchodzą jakieś praktyki czystego kodu?
      CIO w tym głowa, żeby to wytłumaczyć. Jeżeli uważa, że testy są niepotrzebne to rzeczony CIO jest dupa.

      Ma działać i to jak najszybciej i tyle.
      Z doświadczenia ci powiem, że pisanie testów równolegle z kodem produkcyjnym(a jeszcze lepiej, używając TDD) skraca czas wytworzenia oprogramowania.

      Zresztą do niedawna praktyką było zlecanie pracy zdalnie Hindusom, więc o jakich testach tu mowa.
      Hindusom zazwyczaj zleca się pracę tylko raz. Pierwszy i ostatni :D

      więc o jakich testach tu mowa.
      Masz tutaj przykład testu, wytworzonego przez hinduskich programistów:

      @Test
      public void someTest()
      {
      assert(true);
      }

      I tak kilka tysięcy razy... i potem tylko słyszysz "Hello my friend, we are written too too many tests, they is work too too good"
      A Cobertura pokazuje pokrycie na poziomie 5% :D

    •  

      pokaż komentarz

      @tarrin:

      a jeszcze lepiej, używając TDD

      Mówisz o obecnych czasach, sytuacje z artykułu były z lat 80 - 90, gdzie tam miało być TDD i JUnity.

      Hindusom zazwyczaj zleca się pracę tylko raz. Pierwszy i ostatni

      Za to ja z doświadczenia powiem, że Hindusom powierzano zadania przez długi okres i każdy doskonale widział jakość ich pracy, ale góra miała to gdzieś, no bo byli tani i przecież działało. Dopiero później się ogarnęli, jak zobaczyli, że utrzymanie i naprawianie błędów jest jednak droższe od posiadania własnego działu IT. Po Hindusach jeszcze w niektórych miejscach odbywa się sprzątanie. W sektorze bankowym choćby.

      Łatwo powiedzieć o jakości kodu, jeśli tworzy się program dzisiaj od zera, inaczej sprawa wygląda jak otrzymujesz projekt, który rozpoczął życie w latach 90 i stary kod siedzi w jarach.

    •  

      pokaż komentarz

      Myślisz, że kadrę zarządzającą obchodzą jakieś praktyki czystego kodu?

      @Legion616: przy kodzie od którego zależy zdrowie i życie ludzi stosuje sie troche inne podejście niż przy klepaniu CRUDa. Tak, zależy. Koszty popełnienia błędu przez który ktoś ginie są wielokrotnie wyższe niz koszt napisania porządnego kodu.

      Ma działać i to jak najszybciej i tyle.

      @Legion616: no nie bardzo. jak pracowałem w firmie która pisała bezpieczny soft to były dwie niezależne implementacje, prowadzone przez dwa niezależne zespoły(nie wiedzące kto jest w drugim zespole, 0 kontaktu poza specyfikacją wejścia/wyjścia) ze 100% pokryciem testami i przejściem każdej ścieżki w kodzie. koszt napisania softu był 8-9 razy wyższy niż napisanie tego na pałę, ale soft na pewno działał zgodnie ze specyfikacją. a potem było głosowanie komputerów czy wyniki obu implementacji są takie same, gdyby się różniły to system przechodzi w stan bezpieczny.

    •  

      pokaż komentarz

      100% pokryciem testami i przejściem każdej ścieżki w kodzie

      @blackphoenix: No cóż, to pozazdrościć fajnego projektu. Może kiedyś też do takiego trafię.

    •  

      pokaż komentarz

      no bo byli tani i przecież działało

      @Legion616:
      Tani może i byli, sęk w tym że NIE działało. Znaczy coś tam niby się robiło, ale nie zawsze i nie do końca. Czasami aplikacja ni z gruszki, ni z pietrzuszki się zamykała - żadnego komunikatu, wyjątku, po prostu okno znikało. I nikt nie wiedział, dlaczego.
      Po dekompilacji okazało się, że wszystkie wyjątki są połykane.

    •  

      pokaż komentarz

      @tarrin: Luzik, nie musisz mi tłumaczyć, że Hindusi byli kiepscy, ja o tym wiem. Ale jak programiści po naszej stronie stawali na głowie, by na bieżąco załatać co się dało, jak sam napisałeś, to góra dalej widziała to tak, że mają produkcję oprogramowania za pół darmo, po naszej stronie ktoś upewni się, że nie ma błędów, a więc proces wytwórczy działa, jest tani i nie trzeba nic zmieniać. Przynajmniej do czasu.