archiwum tematu „software engineering” z roku 2004

Kryzys wartości - odsłona trzecia i ostatnia

Ciąg dalszy dywagacji (powiadają, że straszliwych) na koniec roku.

Kryzys wartości - odsłona druga

Nie ma programu bez błędów — każdy, kto się zetknął z jakimkolwiek programowaniem czegokolwiek dobrze o tym wie. A jednak jest na takie buble popyt, więc z powodzeniem zajmujemy się ich komercyjną produkcją. Osobiście wątpię w uczciwość takiego zajęcia.

Kryzys wartości - odsłona pierwsza

Inżynieria oprogramowania (pomijając cokolwiek akademickie rozważania na temat zasadności samego słowa „inżynieria” w tym kontekście) jest jedną z najszybciej rozwijających się dziedzin działalności gospodarczej. Jeśli zagapisz się przez rok w innym kierunku, to właściwie nie masz szans wrócić w to samo środowisko — inne narzędzia, inne techniki, inne wymagania. Do spółki z wciąż szaleńczo galopującym rozwojem sprzętu tworzy to sytuację, w której tzw. „przeciętni ludzie” mimo, że mają coraz więcej powodów do korzystania z komputerów, rozumieją je coraz mniej. Nie potrafią powiedzieć jak to działa ani jak powstał program, który widzą „tam w środku”. A to są idealne wręcz warunki do rozwoju kilku zawodów i pojawiania się profesjonalistów — tam, gdzie szaleją demony, potrzebni są szamani, magicy i specjaliści wszelkiej maści.

Nie całuję nigdy w usta (aka: Kryzys wartości - wstęp)

Kod programów pisanych zawodowo (w sensie: przez profesjonalistów w celach zarobkowych) jest nader często pisany na szybko, źle zaprojektowany, pełen nieprzemyślanych fragmentów i łat, skomentowany słabo lub wcale, brzydki jak nieszczęście, a nawet zaskakująco nieprofesjonalny.

Ten Most Wanted Design Bugs

Dzięki genialnym wynalazkom, jakimi są RSS i Bloglines, oraz spostrzegawczym ludziom, do jakich należy Simon Willison, napotkałem w sieci listę Ten Most Wanted Design Bugs.

chwała frajerom

Twórcy Wolnego Oprogramowania udostępniają je bez ograniczeń, gdyż cenią sobie te wartości, które są fundamentem rozwoju nauki: współpracę, wzajemną krytykę i wymianę idei. Sądzą, że satysfakcja z dzieła cenionego i użytecznego dla innych jest warta więcej niż można kupić za pieniądze.

i co? i ... so

System zarządzania jakością — potężne narzędzie, bez którego trudno sobie wyobrazić utrzymanie w ryzach czegoś tak złożonego jak projekt informatyczny. Istnienie firmy zajmującej się tworzeniem wielu projektów bez takiego systemu wydaje się w ogóle nie poważne.

Best Software Essays of 2004

Lista nominacji „Best Software Essays of 2004” stanowi zbiór opracowań różnorakich, dużych i małych, w większości dostępnych on-line — kawał lektury, często dobrej... :-)

jutro to dziś, tylko ma więcej błędów

W zasięgu mojego wzroku pojawiło się w ostatnich czasach kilka mniej lub bardziej humorystycznych artykułów na temat dobrego i złego raportowania błędów — np.: Testers: Are they Vegetable or Mineral?, Every time you submit a bad bug report, god kills a kitten.

naprawdę zaawansowany procesor tekstu

Produkcja oprogramowania, jak chyba każdy sformalizowany proces przemysłowy wymaga tworzenia dużej ilości tekstowych dokumentów wszelakich. Jeżeli całość jest <del>zakuta w</del> utrzymywana w ryzach za pomocą jakiejś normy z serii ISO 9000 to ilość produkowanych <del>śmieci</del> zapisów znacznie wzrasta. W takiej sytuacji „procesor tekstu” należy do podstawowych narzędzi dewelopera (a im „wyżej”, tym bardziej).

niewiele się zmienia przez lata

Wygrzebałem dzisiaj spod stosu papierów prawie nie używany firmowy kalendarz na rok 2002. Otworzyłem gdzieś w okolicach początku kwietnia i między sobotą a niedzielą naszkicowałem kilka tabelek mających stanowić protezę projektu do zadania, którym właśnie obarczałem kolegę. Krótka rozmowa i ten rysunek wystarczy.

sny o potędze

Powiem wprost: jestem zdegustowany i może nawet lekko zaniepokojony nachalną wrzawą wokół przeglądarki Firefox. Równocześnie jednak wyczuwam pewne ogólne podniecenie i wzrost napięcia, który musi doprowadzić do czegoś spektakularnego. Pytanie tylko kiedy i do czego?

Czyj to plan?

Przedsięwzięcie programistyczne, tak jak każdy inny przejaw zorganizowanej działalności zespołowej, nie może się obyć bez konkretnego planu działania. To z pozoru banał. Jednak wniknięcie w szczegóły powstawania planów lub harmonogramów na typowym grzęzawisku ujawnia znacznie mniej oczywiste zależności i konsekwencje.

free as a ...?

Zebrałem się w końcu w sobie, sięgnąłem na półkę po lekko już zakurzone 4 CD-ki i upgradeowałem nasz domowy system (z Fedora Core 1 do 2). Zupełnie przypadkowo trafiłem dokładnie w dzień, w którym FC1 przeszło do historii — jak widać intuicja działa ;-). Rzecz się odbyła stosunkowo szybko (no ok, godzinę to trwało), w miarę bezboleśnie i właściwie dosyć przyjemnie. I jak często w takich sytuacjach dopadło mnie uczucie zadziwienia nad faktem, że właśnie na moim dysku rozsiada się wygodnie kilka gigabajtów pełnowartościowego, darmowego, wolnego oprogramowania, a tymczasem komputer, na którym to instalowałem, wszystko dookoła, a nawet piwo i parówki, które podjadałem w trakcie, zostały kupione za pieniądze zarobione na bardzo płatnym i bardzo zamkniętym sofcie. Ten dysonans czasami nie daje mi spokoju...

Gmail

Fala ogólnoświatowego zainteresowania serwisem pocztowym Googla, czyli Gmail, nie słabnie, mimo że od pierwszych wersji beta minęło już kilka miesięcy. Zapewne w dużym stopniu jest to spowodowane aktualnym sposobem uzyskania tam konta, czyli koniecznością otrzymania zaproszenia od innego użytkownika — taka zasada wprowadza atmosferę elitarności, która chyba bardziej przemawia do wyobraźni niż inne cechy Gmaila (np. 1GB darmowego miejsca na pocztę). Niezły chwyt marketingowy, to im trzeba przyznać, nawet jeśli większość użytkowników nie bardzo wie co ma zrobić z uzyskanym w ten sposób kolejnym adresem e-mail. Zresztą „thanks to the generosity of folks like you” uzyskanie zaproszenia do Gmaila stało się stosunkowo proste, tak że dzisiaj nawet mój kot ma tam konto ;-). Zostawmy jednak marketing, konkursy na zaproszenia i elity, a spróbujmy spojrzeć na Gmail jak na aplikację webową.

ekstremalnie cienki klient

Sformułowanie „aplikacja webowa” zapewne razi purystów językowych. Niestety nie znam lepszego odpowiednika pojęcia „web application”, jakiejś bardziej polskiej nazwy na architekturę, w której interakcja z użytkownikiem odbywa się poprzez strony w przeglądarce internetowej. Czy to będzie się odbywało w internecie czy w intranecie, w sieci rozległej czy lokalnej — bez znaczenia. Ważne, że po jednej stronie jest użytkownik uzbrojony jedynie w przeglądarkę (mniej lub bardziej dowolną), a po drugiej serwer obsługujący żądania tego użytkownika i zapewne jakąś bazę danych. Niby klasyczna architektura klient-serwer, ale specyfika klienta powoduje, że aplikacje webowe to zupełnie nowa jakość problemów.

this is weird

Cytat, który może być pomocny w nabraniu dystansu...

smutna prawda numer jeden

„Trudno powiedzieć, kto jest większym kretynem - klient, który to wymyślił czy my, którzy się na to zgadzamy...” — takim filozoficznym przemyśleniem poczęstował nas dzisiaj kolega ślęczący nad Dziwną Funkcjonalnością. I zrobił to nie jedyny, nie po raz pierwszy i nie ostatni.

koszmar na jawie

Dla projektanta systemu informatycznego Java to całkiem przyjemne narzędzie, złego słowa nie powiem... Wystarczy opanować kilka klocków, patternów czy innych patentów i można poskładać z nich dowolnie skomplikowane rozwiązanie. Uwzględniając jeszcze fakt, że większość narzędzi CASE obsługuje kod źródłowy w Javie (i to również w zakresie reverse engineering) można ulec wrażeniu, że da się to zrobić stosunkowo łatwo. Dodatkowo odwołując się do kilku popularnych sloganów, np. o „niezależności od platformy”, można decydentom różnego szczebla sprzedać pomysł wykorzystania technologii Javy z etykietką „dobre rozwiązanie”.

anioły faktycznie nie istnieją

Kilka dni temu w małym (choć rozwlekłym) świecie blogów zaroiło się od referencji do wpisu „Why specs matter” Marka P. Śmiem podejrzewać, że w większości jest to zainteresowanie typowe dla każdej publicznej wypowiedzi zawierającej zdanie typu:

Brainfuck na śniadanie

Powrót do pracy po dwóch tygodniach urlopu niechybnie oznacza cios. Jeżeli taki powrót następuje w sytuacji balansowania między dwoma projektami to ciosy padają ze wszystkich strona równocześnie. Umysł niebezpiecznie wręcz rozluźniony, odzwyczajony zarówno od walki o utrzymanie się na powierzchni grzęzawiska jak i od ścisłej koncentracji w niesprzyjających warunkach, potrzebuje w takich chwilach szybkiego sformatowania — np. w postaci małego ćwiczenia w Brainfucku.

na notację węgierską zawsze można liczyć

...jako na dowcip, który zawsze śmieszy. A jeśli jeszcze zostanie ona zastosowana w sposób jaki odkryłem dzisiaj w ramach działań archeologicznych na "The Daily WTF" to faktycznie może rozświetlić najsmutniejszy wieczór ;-)

COOL:Gen

Pod koniec XX wieku pracowałem przez kilka lat nad systemem napisanym w środowisku COOL:Gen (wtedy jeszcze produkcji Sterling Software). Oryginalny pomysł nie był nasz, przejęliśmy projekt z całym dobrodziejstwem inwentarza. Wtedy sprawa była bardzo ciężka, klient (spora instytucja finansowa) po prostu zaczął pracować na systemie, którego jeszcze nikt nie zdążył napisać — bagno po same uszy, nie jakieś lajcikowe grzęzawisko. Przez dłuższy czas pracowaliśmy oficjalnie po 12 godzin dziennie plus soboty. Jednak dziś, patrząc na to z dystansu jestem bardzo zadowolony, że takie coś mnie w życiu spotkało. Ze względu na COOL:Gena właśnie.

PHP vs ASP.NET the world

Niedawna premiera PHP 5 spowodowała lawinowy wręcz przyrost artykułów i najróżniejszych wypowiedzi w stylu Why PHP 5 Rocks. Ogólna opinia "społeczności developerów aplikacji webowych" wydaje się sugerować, że tym razem jest to już poważne zagrożenie dla ASP.NET.

Primate Programming

O Primate Programming, czyli o antropoidach w roli programistów, mówi się bardzo mało... A szkoda, bo idea jest piękna — skoro usiłujemy nauczyć głupie maszyny pisania kodu za nas, to czemu nie moglibyśmy nauczyć tego samego prawie-tak-samo-jak-my-inteligentne małpy człekokształtne?

XML

XML — skrót robiący w ostatnich latach niewyobrażalną wręcz (i mocno niepokojącą, o czym za chwilę) karierę. I to skrót właśnie, te magiczne trzy literki, nie nazwa "eXtensible Markup Language", i z pewnością nie specyfikacja tegoż. W zbiorowej świadomości ludzi związanych z informatyką "akurat na tyle, żeby się ciężką prac nie pobrudzić" XML zagnieździł się na dobre. A że niezupełnie w tej przegródce co trzeba, to wydaje się mało istotnym szczegółem technicznym...

narysuj mi UML-a

Język UML jest dzisiaj standardem przemysłowym w projektowaniu oprogramowania i jako taki powinien być używany praktycznie wszędzie. Niestety w rzeczywistości tak nie jest z bardzo prostego powodu — programy do modelowania z użyciem UML są duże, skomplikowane i niejednokrotnie drogie, co powoduje, że nie każdy ma czas, pieniądze i ochotę używać ich na co dzień. A UML nie używany "normalnie" traci popularność, moc oddziaływania i większość sensu swojego istnienia.

parametryzacja

Problem jest stary, niemal tak stary jak systemy informatyczne w ogóle — użytkownik dla systemu czy system dla użytkownika?

zniecierpliwienie i arogancja

Biorąc pod uwagę złożoność [komputerów i programów], to zdumiewające, że ludzie w ogóle tworzą oprogramowanie. Jak rozwinęliśmy umiejętności pozwalające na sterowanie zdecydowanie logiczną maszyną? Niezbędne ku temu zdolności mają niewiele wspólnego z polowaniem, wymykaniem się zdobyczy, czy wabieniem partnera. Niemniej jednak doczekaliśmy czasów, w których oprogramowanie stanowi centralny punkt naszego życia ekonomicznego i kulturalnego i to właśnie programiści są w stanie je stworzyć.

Symbian Technical Day in Warsaw, Poland

Wczorajszy dzień w całości spędziłem na uczestnictwie w Symbian Technical Day. Rzecz się odbywała oczywiście w stolicy, a więc w moim przypadku wymagało to dodania do czasu wynikającego z agendy jeszcze 10 godzin w samochodzie, w tym ponad 2 w warszawskich korkach.

przeanalizujmy to spokojnie

Dowolny klient, odbiorca dowolnego systemu infomatycznego, mimo kilku niezaprzeczalnych zalet ma zawsze jedną podstawową wadę — nie umie powiedzieć czego chce. To jest pewnik, zagwarantowany przez definicję klienta jako takiego — sam z siebie nie umie sformułować wymagań na jakimś zadowalającym poziomie technicznej szczegółowości. A nawet jeśli czasem mu się wydaje, że umie, jeśli na przykład ma swoich informatyków, który zechcą przygotować specyfikację wymagań, to wychodzi to tak, że wszyscy byliby szczęśliwsi gdyby klient takich rzeczy w ogóle robić nie próbował.

architekt

Most people think of architecture as technical, and the architect as a technical person. And absolutely, the architect must be technical. But there's also a social aspect of the architect role that I think is not well communicated or understood. The architect is the person who will say, "This is the way we do things."

select *

Trafiłem niedawno na artykuł "The Case Against SELECT *", w którym autor podważa zasadność stosowania * w zapytaniach SQL.

Pair Programming - good intention gone bad

Pair Programming — jedna z podstawowych i jednocześnie najbardziej kontrowersyjnych praktyk stosowanych w XP. Mam wrażenie, że w przeważającej większości znanych mi przypadków to po prostu nie zadziała. Nie twierdzę, że to pomysł do niczego — Pair Programming może działać i może być wydajną techniką (może nie od razu 1+1=3, ale przynajmniej 1+1> 2). Jednak równocześnie istnieje mnóstwo powodów, dla których może się okazać absolutną klęską.

standard kodowania

O standardach pisania kodu programu powiedziano już bardzo wiele. Jest to jeden z najbardziej wyrazistych aspektów ludzkiego wymiaru programowania — styl kodu nie ma przecież żadnego znaczenia dla kompilatora i jego "jakość" to wyłącznie subiektywne odczucia programisty. A jednak sprawa od zawsze budzi wiele emocji — kod może być "elegancki" i "ładny" albo "brzydki" i wtedy taktowany jako produkt niskiej jakości (niezależnie od jakości skompilowanego programu). Nic dziwnego zatem, że powstają nawet oficjalne wytyczne na temat stylu kodowania, np. Suna dla Javy lub Microsoftu dla .NET-u oraz dziesiątki innych opracowań (prywatnych lub korporacyjnych), które zazwyczaj bazują na powyższych lub innych sławnych źródłach typu "C++ Coding Standard" Todda Hoffa.

niemodna optymalizacja

Tempo postępu technologicznego w informatyce jest (przynajmniej dla mnie) jednym z największych zaskoczeń ostatnich dziesięcioleci. Moc obliczeniowa komputerów wzrasta tak szybko, że nieraz jest to "poniżej ludzkiej godności", jak zwykł mawiać mój kolega. Znaczenie określenia "dobry sprzęt" zmienia się błyskawicznie i wyobrażam sobie, że ludzie chcący za tym nadążyć nie zajmują się niczym więcej. Niestety wraz ze sprzętem dewaluuje się pojęcie "dobrego" oprogramowania. Przyzwyczajeni do szybkich i tanich komputerów przestajemy zwracać uwagę na takie szczegóły jak optymalizacja kodu, wykorzystania pamięci czy szybkości obliczeń. Problemy z wydajnością oprogramowania nagminnie rozwiązuje się bezczelnie prostym stwierdzeniem — "poda się w specyfikacji większą ilość wymaganej pamięci, to kosztuje grosze". I niestety to jest prawda, co tylko umacnia trend ignorowania pojęcia optymalizacji. Jednak paradoksalnie rozczarowanie przychodzi w momencie kiedy zechce się napisać coś "naprawdę zgodnego z trendami", ponieważ "trendy" to dzisiaj urządzenia mobilne.

XP name considered harmful

Bez względu na to jak obiecujące byłyby koncepcje związane z Extreme Programming, nigdy nie będę w stanie wprowadzić takiego pojęcia oficjalnie w poczet technik stosowanych w firmie. Do powodów, które sobie wyobrażam, należą przede wszystkim takie:

Blog Reader Add-In for Visual Studio .NET

Blog Reader Add-In for Visual Studio .NET — czytnik RSS zintegrowany z Visual Studio, czyli co zrobić, żeby lepiej udawać, że pracujesz ;-).

IntelliSense

Najważniejsza, obok kolorowania składni, funkcjonalność edytora kodu — przewidywanie co chcesz napisać i podpowiadanie gotowych rozwiązań. Czy to się nazywa IntelliSense, code completion, code hinting czy jeszcze jakoś inaczej — bez znaczenia. Ważne, żeby było i żeby działało sprawnie, bo od tego zależy jakość, szybkość powstania, a nieraz w ogóle zaistnienie kodu.

Agile Modeling

Kiedy pierwszy raz zetknąłem się z pojęciem Agile Modeling spotkałem różne mniej lub bardziej rozbudowane wprowadzenia czy też próby skrótowego przedstawienia tego pojęcia (choć niejako z definicji skrótowo przedstawić się go nie da), w tym również poniższą listę:

programista, a może projektant?

Teoria książkowa aka sformalizowany świat idealny przedstawia taki łańcuch rozbieżnych kompetencji — klient, analityk, projektant, programista, tester. W łańcuchu tym wymagania i uwagi klienta co do funkcjonalności systemu są pieczołowicie zbierane przez analityka i przekazywane projektantowi, który tworzy szczegółowy projekt tego co ma być wykonane. Następnie projekt ten trafia do programisty w celu jego urzeczywistnienia i na końcu do testera dla konfrontacji efektu z założeniami. Taki schemat zakłada separację ról, czyli jest praktycznie wzorowany na kaskadowym modelu cyklu życia projektu informatycznego. I jest równie absurdalny jak sam model kaskadowy.

engineering?

Pytanie o zasadność słowa engineering w wyrażeniu software engineering nie jest bynajmniej nowe ani dziwne. Jest wręcz uzasadnione, a uzasadnione pytania tego kalibru zawsze są kłopotliwe. Jeśli nie niebezpieczne...

the joy of Smalltalk

Jedno mam za złe szkołom i uczelniom, do których dane mi było uczęszczać — nie nauczyli mnie Smalltalka, przez co mój kontakt z prawdziwym sensem programowania obiektowego opóźnił się o całe lata.

Poseidon for UML

W ramach poznawania nowych zabawek zainteresowałem się niedawno programem Poseidon for UML firmy Gentleware. Jest to dosyć przyjemne narzędzie CASE do modelowania UML z generacją kodu "na żywo", rozwinięte na fundamencie ArgoUML.

błąd nasz codzienny

Nie ma systemu bez błędów. Im szybciej się z tym pogodzisz tym lepiej.

zapraszam na chwilę do siebie...

Przełożony to niemal z definicji "przeszkadzacz" — weźmy np. takiego kierownika projektu.

dokumentacja kodu

Pracowałem kiedyś przy projekcie, w którym robiłem pewien moduł w znacznym stopniu niezależny od reszty systemu (sam go zaprojektowałem i sam zaprogramowałem), mogłem więc obserwować całość z boku. W sumie działało tam ośmiu programistów, o różnym stażu, różnych doświadczeniach i umiejętnościach, nawet rozmieszczonych w niemal krańcowo odległych lokalizacjach w Polsce. Oprócz mnie może jeszcze jedna osoba tworzyła w kodzie komentarze dla zwiększenia jakości kodu, a nie dla wyrażenia swoich frustracji. Oprócz mojego żaden moduł programu nie posiadał kompletu własnej dokumentacji. A całość była pisana w javie, więc stworzenie sensownej i kompleksowej dokumentacji kodu (z użyciem Javadoc) wymagało jedynie odrobiny dobrej woli...

DateTime

Wśród programistów funkcjonuje kilka takich .... skrótów myślowych, które nieodmiennie wprawiają mnie w zdumienie. Np. problem formatu liczby, lub jeszcze gorzej — formatu daty.

patent?

Patenty na oprogramowanie są dla programistów niczym miny. Każda decyzja projektowa to możliwość "stąpnięcia" na patent i zniszczenia projektu. Niebezpieczeństwo staje się bardzo poważne jeśli weźmie się pod uwagę fakt jak wiele pomysłów składa się na nowoczesny program.

OSS from Redmond

Idąc śladem wczorajszego newsa na Computerworld odkryłem z lekkim zdziwieniem, że faktycznie WiX istnieje jako Microsoft's first OSS project. Na SourceForge.net!? Od Microsoftu!? Ewenement. I nawet blog jest na ten temat.

survival test

Mierzenie jakości procesu produkcji oprogramowania jest chyba bardziej skomplikowane niż w przypadku jakiegokolwiek innego przedsięwzięcia. Istnieją na ten temat spore opracowania i rozbudowane techniki (które zawsze wymagają produkowania ogromnych stosów dokumentacji, dobrze jeśli niekoniecznie papierowej), ale istnieją też szybkie testy pozwalające zorientować się mniej więcej jak głęboko stoimy. Może zbyt to przypomina "testy psychologiczne" z gazet dla nastolatek, ale w gruncie rzeczy nie jest takie całkiem głupie...

kiedy byłem małym chłopcem, hej

Kiedy już wiedziałem, że chcę zawodowo pisać programy, że chcę być programistą, tak naprawdę nie wiedziałem i nie rozumiałem nic. Przez większość "szkolnej młodości" pisałem programy najróżniejsze, małe, średnie i "całkiem spore", na platformy wszelkie jakie się w tym czasie przewinęły przez scenę i moje łapy (począwszy od Atari 65XE, bo ZX Spectrum nie ma co wspominać). To hobby dało mi to pewne pojęcie o tym jak to się robi i chyba ogromnie ułatwiło życie na studiach. Wydawało mi się wtedy, że zawodowe tworzenie oprogramowania to podobna zabawa plus dodatkowo ktoś ci za to płaci — decyzja o wyborze zawodu była prosta. Zbyt prosta.

dwa cytaty tytułem wstępu

Smoliste grzęzawisko cytowałem już kiedyś lecz przytaczam i tutaj jako wyjaśnienie dla słabo kojarzących. Zresztą zapewne powtórzę to jeszcze nie raz, bo to tekst z gatunku ideologicznych...