Skocz do zawartości

sebas86

Użytkownicy
  • Zawartość

    3
  • Rejestracja

  • Ostatnio

Reputacja

3 Neutralna

O sebas86

  • Ranga
    1/10
  1. To wszystko fajnie brzmi ale w rzeczywistości ciężko jest zrobić to dobrze. TDD wymaga czasu, rygoru, doświadczenia. Nie wyobrażam sobie używać TDD do prototypowania w momencie kiedy nie wiem jak, po co i dlaczego coś ma działać tak a nie inaczej, a jest to warunek konieczny aby sformalizować rezultat działania kodu, który ma być przetestowany. TDD jest wspaniałe do typowo książkowych przykładów, takie rdzenne biblioteki jak w artykule są po prostu idealnym materiałem - to jest kod, który ma się zachowywać w ściśle określony sposób, jest łatwy do odizolowania, robi bardzo konkretną rzecz i praktycznie nie ma zależności zewnętrznych - korzysta tylko z podstawowych elementów języka, w jakim pisany jest kod. Ba, łatwiej napisać kod, który dowiedzie, że działa prawidłowo niż przetestować go ręcznie... Schody się zaczynają z kodem, który musi coś spinać, korzystać z zewnętrznych bibliotek, które nie są zbyt dobrze udokumentowane, nikt nie stworzył ich z myślą o automatyzacji i testowaniu, nie jesteśmy w stanie w pełni na nich polegać bo jeszcze zbyt słabo je poznaliśmy albo generują wyniki, które ciężko interpretować maszynowo. W takich przypadkach aby zastosować TDD trzeba się uciekać do sztuczek, rozbijać proste obiekty na osobne komponenty i zmuszać przyszłych użytkowników do specyficznej ich inicjalizacji, kolokwialnie mówiąc zrobić mały bajzel w architekturze aby część rzeczy w ogóle mogła zostać przetestowana na niskim poziomie, a i tak czasami gdzieś trzeba coś przepchnąć aby kod w ogóle działał. To wszystko wymaga czasu. Czasami jest to naturalne, bo trzeba i tak napisać kawałek kodu, który dowiedzie, że mamy coś co działa ale niektóre rzeczy są ciężko mierzalne jeśli dają efekt poza kontrolowanym systemem. Sam z chęcią bym usłyszał więcej też o tym gdzie warto, a gdzie nie warto używać TDD. A jeśli warto wszędzie to chciałbym usłyszeć jak radzić sobie z typowymi problemami, chociaż nie wierzę, że mając do zrobienia prototyp i sprawdzenia czy fajnie się w coś gra ktoś klepałby testy do każdej jednej funkcji mając czas na projekt ograniczony do kilku roboczodni - jak dla mnie to jest strata po prostu z definicji bo w pewnych przypadkach chcemy właśnie testować UX a nie poprawność działania kodu.
  2. Nie demonizowałbym klonów. Arduino jest otwartym sprzętem, z otwartym oprogramowanie, każdy kto ma ochotę może zrobić sobie taką płytkę, ktoś pamięta kojarzy polskie bieduino? Co innego, że Chińczycy mają wywalone na prawa autorskie i bez wyrzutów sumienia posługują się zastrzeżonym znakiem Arduino. I to nie do końca rozumiem, przecież nic złego by się nie stało gdyby wyprodukowali płytkę identyczną z Ardu ale bez logotypu i wyraźnie się powołali na to, że jest z nim w 100% zgodna... No ale to taka nasza smutna rzeczywistość. Swoją drogą Ardu jest bardzo bliskie rozwiązaniom referencyjnym, fenomenem było zrobienie gotowca ułatwiającego start w świat mikrokontrolerów. Nota bene ta bliskość referencji pogrążyła też wspomniane USBee, fakt zrobili kawał dobrego oprogramowania ale sam sprzęt to nic nadzwyczajnego, niestety nie zabezpieczyli najbardziej istotnej rzeczy czyli oprogramowania. No i jeszcze pozostaje kwestia ceny. Ktoś ma może klona Raspberry Pi albo chociaż widział takowe? Fakt, że można kupić na Ali tańsze wersje na rynek azjatycki ale z tego co kojarzę to są nadal oryginalne malinki ale produkowane poza UK. Sam mam kilka malinek i ani jednego oryginalnego Ardu, właściwie to przez długi czas nawet nie miałem klonów bo wystarczający zestaw do zabawy z tą platformą to płytka stykowa, garść elementów pasywnych, scalak AVR i tani programator albo kolega, który wgra program rozruchowy...
  3. Dla mnie to naturalny krok i wręcz niezbędny element dla rozwiązań IoT. Nawet zwykły czujnik temperatury czy ruchu powinien szyfrować komunikację z centralką żeby nie dawać fajnego narzędzia choćby dla włamywaczy... Samo szyfrowanie wbudowane w protokół to trochę mało, niestety nie jestem eskeprtem od bezpieczeństwa więc nie będę rzucał przykładami ale... na popularnych portalach zajmujących się tą tematyką można było poczytać o podatnościach w implementacji WiFi. Druga sprawa to taki silnik szyfrujący i miejsce do przechowywania kluczy przydałby się już dawno dla bardziej wymagających użytkowników projektujących urządzenia odporne na piractwo. Procesory AVR miały co prawda opcję zabezpieczenia fuse bitami ale to jest mechanizm chroniący tylko przed odczytem, problematyczna staje się implementacja bezpiecznego mechanizmu aktualizacji. No i trzecia sprawa, teoretycznie są biblioteki pełniące tą samą rolę ale zabierają one cenną przestrzeń mikrokontrolera i znacznie obciążają go obliczeniowo, tym bardziej, że spory odsetek mikrokontrolerów nie ma instrukcji sprzętowych przyspieszających tego typu obliczenia.
×
×
  • Utwórz nowe...