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...

W ostatnim wpisie przybliżyłem zestaw dobrych praktyk w pisaniu unit testów. Dzisiaj będę kontynuować ten temat z trochę innej perspektywy i opowiem o antywzorcach. Dzięki charakterystycznym nazwom, piętnującym konkretne złe praktyki, antywzorce zostają w pamięci i mamy je przed oczami pisząc podejrzany kod. Podejście do testów Pierwsza grupa wzorców nie wiąże się z pisaniem konkretnych testów, tylko raczej z nastawieniem, jakie nam towarzyszy podczas pisania i wynikającymi z tego zachowaniami.Obywatel...

W poprzednich częściach cyklu skupiałem się na korzyściach płynących z TDD. Jeżeli ta metoda wejdzie nam w krew, te korzyści zachęcą nas, abyśmy pisali w ten sposób zawsze i wszędzie. Motywują nas do tego również eksperci mówiący, że każda linia kodu powinna być przetestowana. Okazuje się jednak, że nie zawsze testowanie wszystkiego na siłę jest dobrym rozwiązaniem. W tym artykule opiszę sytuacje, kiedy nie opłaca się używać TDD. Programując czasem natrafiamy na problemy, co do których nie mamy z góry...

Przestawienie się na Test Driven Development z pisania metodą tradycyjną nie jest łatwym zadaniem. Szczególnie na początku musimy walczyć ze starymi nawykami, a kiedy napotykamy trudności, naturalnym rozwiązaniem jest stosowanie metod, które znamy i rozumiemy. Poza tym początkowo TDD może nam się wydawać nieintuicyjne, a wkład pracy wydaje się większy. Jak to zwykle bywa w takich przypadkach, kluczem jest wytrwałość. Każda umiejętność wymaga czasu, aby ją dobrze opanować. Kiedy już nam się to uda, zauważ...

Kiedy uczyłem się programować, pisałem metodą code and fix. Czyli najpierw pisałem jakiś fragment kodu – mogła to być jedna funkcja, moduł albo nawet cały program. Następnie uruchamiałem go i ręcznie sprawdzałem czy działa, przechodziłem kod debuggerem sprawdzając wartości zmiennych i przepływ sterowania. Następnie poprawiałem znalezione błędy, dodawałem funkcjonalności i znowu sprawdzałem. Na pewno każdy programista zaczynał w ten sposób. W miarę jak moje umiejętności rosły i pisałem trudniejsze progra...