Dzisiaj opowieść o kolejnym znanym bugu, który miał ogromne konsekwencje. Podobnie jak w przypadku Therac-25, analiza katastrofy rakiety Ariane 5 przyczyniła się do poprawy procesów wytwarzania systemów safety-critical. We wtorek 4 czerwca 1996 roku odbył się dziewiczy lot Ariane 5 – nowej rakiety Europejskiej Agencji Kosmicznej, która była rozwijana przez ostatnie 10 lat, a budżet projektu wynosił 7 mld $. Rakieta miała wynieść na orbitę okołoziemską zespół sond do badania magnetosfery. Niestety pół ...

Ostatnio na portalu embedded.com zaczęła pojawiać się seria artykułów omawiających 10 najczęstszych problemów w projektach embedded napisana przez Jacka Gannsle. Pierwszym omówionym zagadnieniem były złudne oszczędności (link  tutaj). Czytając artykuł zgadzałem się praktycznie z każdym słowem, bo sam obserwuję to samo praktycznie od początku kariery zawodowej. Z resztą nie jest to coś specyficznego tylko dla systemów embedded, czy branży IT, Krótkowzroczne podejście do oszczędności jest chyba ogólnoświat...

Ostatnio czytałem książkę „Mit przedsiębiorczości”, która mówi, że każda firma od samego początku powinna mieć jasno określoną strukturę i dobrze zdefiniowane procesy. Skłoniło mnie to do refleksji jaki wpływ takie procesy mają na mnie jako pracownika. Jakie są zalety i wady pracy dla wielkiej korporacji oraz małego startupu. I jaki poziom strukturyzacji jest najlepszy dla mnie. Nie skupiam się tutaj na aspektach finansowych, czy multisportach, a jedynie na konsekwencjach strukturyzacji i jej wpływie na ...

W zeszłym tygodniu cały świat mówił o Elonie Musku i o SpaceX, a wszystko za sprawą startu rakiety Falcon Heavy, który odbył się 6 lutego 2018. Największe wrażenie na wszystkich wywarło synchroniczne lądowanie dwóch bocznych rakiet. Przy okazji – wiecie, że SpaceX wcale nie wykonało takiego lądowania jako pierwsze? New Shepard firmy Blue Origin należącej do Jeffa Bezosa było wcześniej, tylko widocznie mają gorszy marketing. Dzięki studiowaniu automatyki mogłem od razu docenić kunszt inżynierów projektują...

W praktykach Extreme Programming (XP) możemy przeczytać, że tydzień pracy programisty powinien wynosić 40 godzin. Możliwe są sporadyczne nadgodziny (kilka razy w roku), ale nigdy nie powinny występować przez dwa tygodnie pod rząd. Praktyka ta nosi nazwę Sustainable Pace, czyli zrównoważone tempo. Zgodnie z XP zespół powinien pracować w stałym tempie, które jest w stanie utrzymywać w nieskończoność. Nadgodziny są symptomem poważniejszych problemów z projektem i to nimi należy się zająć. Może się wydawać,...

W internecie można spotkać głosy, że programiści nie wykonują odpowiedzialnych zadań i nie ma żadnych regulacji, których muszą przestrzegać. Bo co złego może się stać, jeśli strona nie będzie działać, albo komputer wywali bluescreena. W końcu świat się od tego nie zawali. Być może jest to prawdą w 99% projektów programistycznych. Jednak tam, gdzie na szali jest ludzkie życie, bardzo restrykcyjne regulacje obowiązują już od dawna. Wiem o czym mówię, ponieważ przez ostatnie dwa lata pracowałem przy systemi...

Testowanie kodu, który nie wykorzystuje zewnętrznych zależności jest stosunkowo proste. W większości przypadków testowany moduł współpracuje jednak z innymi elementami systemu.  Stawia to przed testami dwa wyzwania – po pierwsze powinny poprawnie działać, a po drugie sprawdzać poprawność tej współpracy. Nie jest to zadanie proste, a zewnętrzne zależności są jednym z głównych czynników utrudniających testowanie. Aby radzić sobie z zależnościami posługujemy się mockami, czyli dublerami zastępującymi zal...

Często unit testy nie są przez programistów traktowane jak prawdziwy kod. Są dla nich jedynie narzędziem do osiągnięcia określonego celu – sprawdzenia poprawności implementacji. Przez to testy stają się trudne w utrzymaniu albo wykonują się zbyt długo. Przez co uniemożliwiają pracę zgodnie z TDD i nie mają wartości dokumentacyjnej. Istnieją jednak proste zasady tłumaczące, jak powinny wyglądać dobrze napisane testy. Pisząc kod powinniśmy trzymać się zasad SOLID, czyli kod powinien być solidny, a dodat...

Próbując wprowadzić TDD w projekcie najczęściej spotkamy się z oporem. Argumenty przeciwko tej technice ze strony developerów i osób decyzyjnych, które nie miały z nią do czynienia często się powtarzają. Postanowiłem więc w tym wpisie zebrać te argumenty i je omówić. Krytyka TDD ze strony osób mających doświadczenie w temacie zwykle przybiera inną formę i jest to temat na osobny wpis. Brak czasu to podstawowy argument przeciwko pisaniu testów. Jest bardzo często używany przez managerów oraz przez niek...

W poprzedniej części cyklu o TDD opisałem dlaczego sposób wytwarzania oprogramowania, który praktykowałem na początku się nie sprawdzał i co mnie skłoniło do zainteresowania się Test Driven Development. Dzisiaj opiszę jak wygląda praca zgodnie z TDD. Jak to często bywa w przypadku praktyk zwinnych zasady teoretyczne są dosyć proste, a kluczem do sukcesu jest dyscyplina. Na początku musimy sobie wyjaśnić jedną bardzo ważną kwestię. TDD to nie synonim do pisania testów jednostkowych. Owszem, unit testy ...