Archiwalia dla 02.2008

Kilka słów o serwisie 10przykazań

Sporo osób zauważyło nową wersję 10przykazań. To dobrze. Dziwi mnie nieco tylko, że większość z nich obawia się o starcie naszego małego serwisiku z konkurencją w postaci Blogfroga i Blogboksa.

Naszym celem (a przynajmniej moim) nie jest konkurowanie z kimkolwiek w kategoriach ogólnie pojętej lepszości, 10przykazań powstało z potrzeby rozwiązania konkretnego problemu. W polskiej części Sieci nie było wygodnego narzędzia, które pozwoliłoby śledzić naprawdę dobre blogi. Nie założyliśmy serwisu dla oklasków (z ukłonami w stronę siwych dyrygentów), nie pchamy się do wywiadów i nie szukaliśmy nigdy strategicznych sponsorów. Nie chcę tu sugerować, że nasza konkurencja (dlaczego w cudzysłowie wyjaśnię za chwilę) powstała z pobudek czysto komercyjnych, ale chciałbym, żeby wszyscy zrozumieli, że 10przykazań to nie jest nasza praca.

10przykazań to hobby, które rozwijam w wolnym czasie i które uruchomiliśmy ponownie dlatego, że jest nam potrzebne, a nie dlatego, że ktoś nam za to płaci. Dlatego właśnie prosiłbym o powstrzymanie się od komentarzy z rodzaju 10p ssie, bo mogło być zrobione lepiej. Pewnie, że mogło, ale ktoś musi na to poświęcić swój czas, poszarpać przy problemach technicznych swoje własne nerwy i starać się wykrzesać z siebie odrobinę talentu prywatnie, po godzinach pracy. Jasne, że sam fakt działania serwisu daje masę satysfakcji, ale wszyscy jesteśmy ludźmi, bywamy zmęczeni i mamy swoje życia prywatne (alkohol, kobiety, autobusy, te sprawy).

Jeśli więc uważasz, że można coś poprawić, pomóż nam i naszym użytkownikom. Opisz swój problem, zaproponuj rozwiązanie, przyłącz się, czy zbuduj konkurencyjny serwis. Tak, zbuduj konkurencyjny serwis, nie boimy się konkurencji, bo nasze życie nie zależy od tego, czy 10przykazań zdobędzie milion użytkowników w ciągu pierwszego kwartału rozliczeniowego. Serwis będzie istniał przynajmniej tak długo, jak długo będzie potrzebny trzem użytkownikom — jego autorom. Jeśli twój projekt okaże się lepszy, możesz liczyć na to, że przesiądziemy się jako pierwsi. To innowacja i konkurencja budują Sieć, a nie venture capitals.

Przy okazji pomocy muszę wspomnieć, że 10przykazań to nie tylko ja, nbw i jarv. Szczególne podziękowania należą się z pewnością jioblowi za to, że 10p ma logo i mojemu pracodawcy, ITS Ltd., za to, że utrzymuje serwis we własnej infrastrukturze i pozwala nam na rozwój tego i podobnych projektów w ramach wolnych cykli pracy.

Wracając jednak do konkurencji, porównania są nieszczególnie trafne. Blogfrogowi zawsze bliżej było do Technorati, niż do 10przykazań. Serwis ten zbiera absolutnie wszystko, co tylko przewinie się przez agregator. Z kolei Blogbox zdaje się oferować niewiele więcej niż Czytnik Google czy Netvibes — ot, załóż konto i stwórz swoją Planetę. 10przykazań od początku miało być łatwą metodą na śledzenie blogów, które warto czytać, jakkolwiek subiektywnym nie wydawałoby się to określenie. Chcemy promować blogi, ich autorów i treść, a nie naszych sponsorów i reklamodawców.

Dlatego właśnie nie publikujemy pełnych treści notek, dlatego właśnie nie otwieramy blogów w pływających ramkach, dlatego właśnie nie wymuszamy czytania notek w nowych oknach. Dlatego w końcu nie pozwalamy komentować notek — nie jesteśmy wykopem i komentarze mają swoje miejsce na blogu autora, pod oryginalnym postem.

Oferujemy za to możliwość tworzenia własnych kanałów z aktualnościami, powiadomienia o notkach za pomocą sieci komunikacyjnej Jabber i przegląd aktualności dla użytkowników Blipa, a autorom treści dajemy wsparcie dla XML-RPC, dzięki czemu publikowana treść może docierać do czytelników na bieżąco. W planach mamy dalszą rozbudowę serwisu, pojawi się między innymi możliwość zarządzania własnymi blogami (i niezbędna w związku z tym funkcja przejmij bloga), dostęp do kolejki zgłoszonych blogów i głosowanie na najbardziej wartościowe pozycje (dla właścicieli blogów już agregowanych). Bardzo prawdopodobne jest, że powyższą listę uwieńczy udostępnienie pełnego, otwartego kod źródłowego serwisu (niech to będzie dowodem, że konkurencja jest dobra).

Tymczasem zapraszam do zabawy nową wersją 10przykazań, zgłaszania nam błędów i niedociągnięć, dodawania nowych blogów do kolejki, a przede wszystkim życzę dużo ciekawej treści do czytania :)

Jak nie należy programować

Tydzień z grubsza zajęło mi doprowadzenie do używalności kodu, który otrzymałem w spadku po pewnym urlopowiczu. Dobrze, że nie mam włosów, bo z pewnością bym je dawno wyrwał, choć z — drugiej strony — na programowaniu cierpi moja broda. Kolega wypoczywa w Iranie, a my próbujemy dojść, co też podmiot liryczny miał na myśli. Kiedy czytanie źródeł dłuży się ponad lekturę Nad Niemnem, znak to, że czas na notkę.

Jak nie należy programować

Na wstępie już zaznaczę, że w ITS Ltd. zajmujemy się budowaniem aplikacji webowych w oparciu o Pythona i Django, więc niektórym poniższy tekst może wydać się płytki/nudny/pozbawiony sensu (niepotrzebne skreślić).

Poradnik niniejszy zalecany jest dla programistów, którzy w różny sposób związani są z serwisem The Daily WTF — czy to przez umiłowanie do czytania publikowanych tam historii, czy to przez bycie bohaterem tych ostatnich. Redakcja zastrzega sobie prawo do skrótów myślowych i przelotnego braku poczucia humoru.

Redundancja

Najważniejszą cechą systemów klasy Enterprise (jeden do teleportacji) jest ich wysoka dostępność (i cena). Jest to fakt tak niezaprzeczalny, jak niezaprzeczalna jest wysoka jakość produktów z rodziny Gadu-Gadu. Autorzy aplikacji klasy E (uniwersalny, automat i do tkanin czarnych) często uważają, że ich produkty z powodzeniem stawać mogą w konkury z aparaturą czasu rzeczywistego. Cóż, każdy może się mylić, ale jakież tajemne receptury zapewniają taką pewność siebie? Dziś Viagrę nabyć można na każdym bazarze, skupmy się więc na technikach programowania.

Autor aplikacji staje wielokrotnie przed trudnymi pytaniami egzystencjalnymi. Gdzie jest specyfikacja techniczna? Jak ja wczoraj wróciłem do domu? Skąd weźmiemy tyle galaretki, żeby napełnić basen? To tylko niektóre z nich. Najważniejsze pytanie, jakie zadają sobie autorzy aplikacji klasy E (E303, E301, może zawierać śladowe ilości orzechów), to jak uniknąć używania bibliotek, których sami nie napisaliśmy, wszak któregoś ranka gotowe przestać działać. Na szczęście tutaj z pomocą przychodzi dogmat Copiego-Paste’a. Wystarczy zatem skopiować kluczowe elementy frameworku do używającej go aplikacji i już możemy spać spokojnie — co dwie kopie to nie jedna, prawdopodobieństwo mówi, że obie nie popsują się jednocześnie.

Optymalizacja czasu pracy

Jeśli brać z kogoś przykłady (a klasa E czyni to niechętnie, sami wszakże stanowią elitę), to tylko z amerykańskiej marynarki. Tradycyjne pojęcia deadline’ów i zarządzania zasobami zastąpić można sprawdzonym na wielu wojnach ŻULU time. W firmie najważniejsi są ludzie, więc zawsze jest czas się napić! Pozwala to płynnie regulować stres powodowany przez pracę, a naukowcy dowodzą, że może w zupełności wyeliminować ryzyko wystąpienia nerwicy (stosujący tę metodykę rzadko dożywają czterdziestki).

Ważne jest również, by programista miał podejście analitycznie i potrafił myśleć outside the box, co w języku polskim oznacza dosłownie myśl, jak ciągle być poza kubikiem. W praktyce sprawdza się najlepiej obranie niekonwencjonalnych godzin pracy (na przykład godzin nocnych) i planowanie przestrzenne (koduję od tego kieliszka do podłogi).

Generalizacja

Generalizacja to dar patrzenia na rzeczy z dystansu. Dla przykładu pies i samochód z dystansu wyglądają podobnie. Dlaczego więc nie umieścić ich w bazie danych we wspólnej tabeli rzecz, odpowiednio pomijając kolumnę rasa w przypadku samochodu i podając zero w kolumnie liczba_drzwi w przypadku psa? Tak zbudowana baza danych jest dużo prostsza do programowania, zwłaszcza jeśli w użyciu jest szkielet ORM.

Dodatkowe punkty komisja przyzna za uproszczenie tabeli do jednego pola, w którym umieścić można zserializowany obiekt dowolnego typu.

Obfuskacja

Duży projekt klasy E często jest oczkiem w głowie korporacji. Nie można zatem dopuścić, by sekrety jego działania poznał niepowołany śmiertelnik. Lata doświadczenia w dziedzinie refaktoryzacji uczą, że najpewniejszym środkiem zapobiegawczym jest obszerne stosowanie obfuskacji. Stosowanie jednoliterowych nazw zmiennych i funkcji nie tylko uniemożliwia zrozumienie geniuszu kryjącego się za kodem, ale także znacznie zmniejsza miejsce, jakie kod zajmuje na dysku. Jest to zaleta nie do pominięcia w przypadku projektów, które korzystają dodatkowo z technik programowania życzeniowego (ale o tym za chwilę).

Niezwykle ważne jest też konsekwentne nieumieszczanie komentarzy w kodzie. Łatwo policzyć, że przeciętna metoda o długości dziesięciu ekranów, stałaby się nieznośnie długa, gdyby co drugi wiersz wstawić komentarz i przeprosiny dla naszego zastępcy.

Zaawansowane techniki zabezpieczania kodu

Kolejną techniką obfuskacji jest, pochodzący z literatury, synkretyzm językowy. Dla zmylenia potencjalnego przeciwnika i lepszego utrwalenia w pamięci dawno nieużywanych technik, staramy się co jakiś czas wtrącić ekran kodu napisanego na przykład w PHP. W tym celu ograniczamy się do części wspólnej składni obu języków, dodatkowo emulując zachowanie zupełnie innego frameworku.

Mało znaną, ale opanowaną do perfekcji przez elitę, metodą wprowadzania zakłóceń w kodzie jest tak zwane prawo wolnego rynku (import bez ograniczeń). Główne zastosowanie tej metody to naprawianie wadliwych języków, których autorzy złośliwie wprowadzili przestrzenie nazw. Wystarczy jednak kilka instrukcji from foo import * starannie porozrzucanych po kodzie (nie zapomnijmy części z nich umieścić w instrukcjach warunkowych) i jesteśmy z powrotem w starym, dobrym bashu. Przyjemny skutek uboczny to fakt, że nikt nigdy nie będzie w stanie odtworzyć zależności aplikacji poza naszym środowiskiem rozwojowym.

Programowanie życzeniowe i stubenci

Jedną z podstawowych prawd na temat programowania jest taka, że każdą aplikację trzeba utrzymywać, a rzadko która nie ewoluuje wraz z upływającym czasem. Pragmatyczny programista dba o to już od pierwszej linii kodu. Zanim jeszcze zajmie się implementacją wymaganej funkcjonalności, stara się przewidzieć możliwe przyszłe drogi rozwoju. Jeśli programista zna się na fachu, owocuje to umieszczeniem w kodzie rozlicznych z pozoru niepotrzebnych metod. Są one z natury zepsute bądź puste i nazywamy je stubami, sam zaś autor nosi fachowe miano stubenta.

Stubenci zapewniają aplikacji bezpieczny margines nadmiarowości, podobnej w naturze do redundancji, co z kolei zmniejsza ryzyko, że przyszły opiekun projektu w wyniku zmieszania niechcący usunie coś niezbędnego. Jedną z rzadziej spotykanych metryk jakości kodu klasy E jest właśnie procentowy udział kodu, który można usunąć bez wpływu na działanie aplikacji. Najlepsi w branży utrzymują się w przedziale od czterdziestu do sześćdziesięciu procent.

Testy jednostkowe i UMŁ

Jak sama nazwa wskazuje, są to testy, które przeprowadza się tylko raz. Dla pewności, że zbędne dane nie wpłyną na wynik ani czas trwania testu, najlepiej przeprowadzić go w środowisku rozwojowym, przy pustej bazie danych. Już samo słowo wdrożenie sugeruje, że klient musi liczyć się z dodatkowymi kosztami w celu późniejszego doprowadzenia produktu do działania w środowisku produkcyjnym. Testy jednostkowe, z natury, mogą być ciężkie do powtórzenia nawet w warunkach laboratoryjnych, stąd nie należy mieć oporów przed skorzystaniem z wygodnego narzędzia, jakim jest UMŁ (u mnie łaziło).

Cóż, na dziś to wszystko, do zobaczenia w kolejnym odcinku poradnika Jak nie należy programować, gdzie wspólnie wzbogacimy wachlarz stosowanych praktyk. Czytał Lucjan Szołajski.

Rhythmbox i trzeszcząca muzyka

W PLD przez dłuższy czas ludzie skarżyli się na artefakty przy odtwarzaniu muzyki przez Rhythmboksa. Problem rozwiązany został dopiero wczoraj.

Zacznę może od rozwiązania, trzeba zaktualizować pakiet alsa-lib do wersji 1.0.16.

Jeśli kogoś ciekawi przyczyna problemu, to służę informacjami. Rhythmbox do odtwarzania dźwięku używa szkieletu GStreamer. GStreamer odpowiada za dekodowanie strumieni i nakładanie efektów, sam jednak do komunikacji z urządzeniem wyjściowym wykorzystuje jedną z bibliotek audio. Najczęściej używana jest w tym przypadku wspomniana ALSA.

Na każdym styku elementów następuje negocjacja obsługiwanych formatów danych. Rhythmbox przed otwarciem pliku sprawdza, czy GStreamer potrafi go obsłużyć. Następnie tworzony jest łańcuszek elementów GStreamera. Każde dwa elementy w kolejce ustalają między sobą preferowany format przekazywanych danych. Ostatnim elementem w łańcuchu odtwarzania jest odpływ (sink), przekazujący dane do biblioteki ALSA.

Również tutaj odbywa się negocjacja i tu pojawia się problem trzeszczenia. GStreamer od niedawna oferuje wsparcie dla 32-bitowych próbek dźwięku. Zapewnia to większą precyzję przy przetwarzaniu, a w przypadku droższego sprzętu także wyższą jakość dźwięku kierowanego na głośniki. Oczywiście, większość z nas słucha muzyki w formatach kompresowanych i nie usłyszymy raczej różnicy, ale GStreamer robi WłaściwąRzecz™.

Problemem jest jednak ALSA, która również od niedawna zmieniła sposób skalowania próbek w przypadku 16-bitowych kart muzycznych. Do niedawna operacja ta polegała na obcięciu 16 mniej znaczących bitów. Zastąpił go nieco bardziej skomplikowany wzór, który — w przypadku dużej siły sygnału — podatny był na przepełnienie arytmetyczne. Ten właśnie drobny szczegół poprawiono w wersji 1.0.16.

Miłego słuchania muzyki zatem, Rhythmbox jest niewinny ;)