My articles published in IT press (abstracts in polish).

Jingle Bells czyli Jabber i VoIP

Software Developer’s Journal nr 05/2007 (149) (PL) Maj 2007

Telefonia internetowa, wideokonferencje, rozgrywki w trybie multiplayer, zdalna współpraca grupowa. To tylko niektóre z usług, które z dnia na dzień stają się coraz bardziej powszechne. Mimo, że wydają się być całkowicie odmienne to mają one jednak jedną wspólną cechę - podczas działania wykorzystują informację o “dostępności” (ang. presence information) danego użytkownika, a komunikacja przebiega w czasie rzeczywistym. Ponadto do przesyłania strumienia danych z oczywistych przyczyn ustanawiane są połączenia bezpośrednie (ang. peer-to-peer) pomiędzy klientami usługi.
Powstało wiele rozwiązań (protokołów) realizujących z mniejszym lub większym powodzeniem takie zadania, lecz duża część z nich bazuje na zamkniętych standardach, które są ściśle powiązane z danym produktem lub firmą.
My skupimy się na tym jak są zestawiane połączenia bezpośrednie, a w szczególności sesje VoIP, między klientami Jabbera wspierającymi rozszerzenie Jingle protokołu XMPP. Przyjrzymy się również architekturze oraz przykładom zastosowania biblioteki libjingle.

Wątki i synchronizacja w Linuksie część 2

Linux Developer’s Journal nr 01/2006 (1) (FR) Listopad 2006

Przy obecnym postępie technologicznym większość systemów operacyjnych posiada zaimplementowaną wielozadaniowość. I nie ważne czy mówimy tu o naszej komórce, odtwarzaczu DVD, inteligentnym tosterze czy superkomputerze - każde z tych urządzeń potrzebuje w mniejszym lub większym zakresie obsługiwać wiele kontekstów wykonania jednocześnie. Oprócz wielkich możliwości, które daje nam wielozadaniowość, pod pojęciem tym kryje się też wiele problemów i pułapek, z którymi od lat borykają się programiści i naukowcy.
Głównym problemem jest to, iż wątki (tudzież procesy) korzystają z reguły ze wspólnych zasobów. Aby jednak było to bezpieczne, dostęp ten musi być w jakiś sposób uporządkowany. Wyobraźmy sobie sytuację, gdy chcemy wyjąć płytę DVD z odtwarzacza, który aktualnie czyta z niej dane. Jeśli operacja ta zostałaby wykonana bez uprzedniego porozumienia z wątkiem obsługującym napęd, płyta mogłaby bez zatrzymania wyjechać na tacce. Niezbyt przyjemne uczucie, szczególnie, gdy był to film z wypożyczalni.
Twórcy systemów operacyjnych wraz z rozwojem wielozadaniowości oraz wprowadzaniem obsługi wątków zadbali również o odpowiednie metody służące do ich synchronizacji. Te, które okazały się najlepsze, czy też zdobyły najwięcej zwolenników, zostały opisane przez standard POSIX, który jest w tej chwili implementowany przez większość systemów uniksowych i nie tylko.

Wątki i synchronizacja w Linuksie część 1

Programowanie w Linuksie nr 05/2006 (6) (FR) Październik 2006

W zamierzchłych czasach, jeszcze zanim wszystko stało się plikiem, rozpoczęto prace nad implementacją systemów wielozadaniowych - czyli takich, które potrafią wykonywać wiele programów jednocześnie. Aby to zrealizować przy użyciu tylko jednej centralnej jednostki obliczeniowej (ang. CPU) zastosowano pewne małe oszustwo - emulację - procesor przełącza się w krótkich odstępach czasu pomiędzy kontekstami wykonywania dając złudzenie użytkownikom, że wykonuje jednocześnie wiele zadań. Zadania te w systemach uniksowych nazywamy procesami.
Fenomen ten trwa po dzień dzisiejszy, i chociaż coraz częściej spotykane są maszyny dwu- i więcej procesorowe to liczba wykonywanych procesów w systemie z reguły waha się pomiędzy parędziesiąt, a paręset.
Wykonywanie kilku zadań jednocześnie powoduje jednak wiele problemów. Jeśli korzystamy ze wspólnych danych prowadzić może to do utraty ich integralności, a niezsynchronizowany dostęp do urządzeń z reguły kończy się dla nas utratą możliwości dalszej komunikacji. Poza tym aplikacje, które uruchamiają wiele procesów pożerają dużo zasobów systemowych.
W tym artykule skupimy się na tym jak uniknąć tych problemów stosując wątki (ang. threads) oraz odpowiednie metody synchronizacji.

Dynamiczne rozszerzanie aplikacji.

Software Developers Journal (SDJ) nr 9 (141) Wrzesień 2006

Mając do czynienia z oprogramowaniem o otwartym kodzie źródłowym problem rozszerzania aplikacji nie jest duży - zawsze możemy zmodyfikować ogólnodostępne źródła, po czym skompilować program od nowa. Jest to jednak dość kłopotliwe oraz zmusza nas do zapoznania się dokładnie ze źródłami oraz sposobem działania aplikacji.
W przypadku oprogramowania o zamkniętym kodzie jedynym wyjściem jakie nam pozostaje jest stworzenie specjalnego interfejsu pozwalającego na wzbogacanie programu o nowe opcje - o ile oczywiście zależy nam na tym, aby nasz program stał się bardziej atrakcyjny i mógł stać się częścią większych systemów informatycznych.
Na łamach tego artykułu zgłębimy wiedzę z zakresu projektowania i implementacji mechanizmu rozszerzania aplikacji zwanego najczęściej obsługą wtyczek (ang. plug-ins) bądź modułów.

Stwórz własny serwer HTTP.

Software Developers Journal (SDJ) nr 7 (139) Lipiec 2006

Jednym z najbardziej rozpowszechnionych protokołów warstwy aplikacji używanych w dzisiejszym internecie jest HTTP. Dzięki swojej prostocie i stosunkowo dużych możliwościach został on zaadoptowany do wielu różnych celów, choć oczywiście największą popularnością cieszy się sieć www. Na łamach tego artykułu przyjrzymy się zagadnieniom związanym z pisaniem serwerów usług sieciowych na przykładzie implementacji prostego serwera HTTP.

Internacjonalizacja aplikacji.

Software Developers Journal Extra (SDJ Extra) nr 3/2006 (9) Kwiecień/Maj 2006 (DE, FR)

Żyjemy w czasach wszechobecnej globalizacji i unifikacji. Wprowadzane są nowe standardy, dąży się do ujednolicenia przepisów i prawa, upraszcza się reguły gramatyczne języków. Pewnych rzeczy jednak nie da się narzucić. Nie pozwala na to przede wszystkim mnogość współistniejących kultur oraz języków1. Wprawdzie w społeczeństwie informacyjnym dosyć duży odsetek stanowią ludzie posługujący się, lepiej lub gorzej, językiem angielskim, ale nie zmienia to faktu, że użytkownicy z reguły wolą korzystać z aplikacji w swoim ojczystym języku. Co więcej nie chodzi tu tylko o przetłumaczony interfejs użytkownika i obsługę znaków narodowych. Problem tkwi równie głęboko jak wiele występuje różnic pomiędzy krajami i kręgami kulturowymi. Różnice te obejmują m.in. waluty, jednostki miar i wag, rozmiary papieru, tytuły naukowe, strefy czasowe, formaty dat, adresów i liczb. Ponadto niektóre treści nie wzbudzające kontrowersji w jednym kraju mogą być obraźliwe i nie do przyjęcia w innym.
Proces, który polega na przystosowaniu aplikacji do użytkowania w różnych krajach i kulturach nazywany jest internacjonalizacją (ang. internationalization). Często również mówimy o lokalizacji (ang. localization) aplikacji. Mimo tego, że terminy te często są używane wymiennie to nie oznaczają dokładnie tego samego. Lokalizacja polega na przystosowaniu aplikacji do konkretnego rynku i potrzeb danego regionu. Internacjonalizacja natomiast jest pojęciem bardziej ogólnym, mającym na celu zaprojektowanie aplikacji w taki sposób, aby mogła być przetłumaczona i przystosowana do lokalnych potrzeb bez wprowadzania zmian w kodzie źródłowym.
W tym artykule przyjrzymy się z bliska różnym aspektom internacjonalizacji oraz związanym z nią problemom.

Narzędzia C/C++ w Linuksie. Techniki debugowania i optymalizacji aplikacji.

Software Developers Journal (SDJ) nr 4 (136) Kwiecień 2006 (PL)

Tworzenie oprogramowania staje się coraz bardziej skomplikowanym procesem. Wymaga on wiele wysiłku oraz systematycznej, często wielomiesięcznej pracy zespołu ludzi, aby osiągnąć żądany efekt końcowy. Poza tym ciągle zmieniające się potrzeby rynku zmuszają programistów do wykazania się wielką elastycznością. Ponaglani przez swoich pracodawców niejednokrotnie wprowadzają spore zmiany w istniejącym oprogramowaniu w przeciągu bardzo krótkich odcinków czasu.
Prowadzi to do wielu problemów, ale przede wszystkim do powstawania błędów. Zarówno dla tych mniej, jak też bardziej zaawansowanych programistów ich szukanie i poprawianie jest pracochłonnym i nielubianym zajęciem. Na łamach tego artykułu postaram się przedstawić podstawowe techniki i narzędzia wspomagające pracę programistów podczas debugowania i optymalizacji oprogramowania w systemie Linux.

Filtr pakietów we FreeBSD.

Zapchane łącza, wyciek informacji z firmy, nieautoryzowany dostęp do zasobów sieci wewnętrznej. To tylko niektóre rzeczy, z którymi na co dzień borykają się administratorzy. Rozwiązanie tych problemów wymaga włożenia wiele pracy w przygotowanie odpowiedniej polityki bezpieczeństwa oraz przede wszystkim skutecznego egzekwowania jej.
Jednym z elementów zabezpieczenia sieci jest skonfigurowanie zapory sieciowej. Szereg firm oferuje swoje sprzętowe rozwiązania komercyjne, jednak nie zawsze są one w stanie spełnić wszystkie nasze wymagania. Poza tym decydując się na kupno ?magicznego pudełeczka? firmy X reklamowanego jako wydajna i bezpieczna zapora sieciowa robimy to, ponieważ ufamy producentowi. Potem możemy mieć tylko nadzieję, że ów producent będzie szybko reagował na wykryte błędy oraz że za rok nie będziemy musieli kupić nowej zapory, bo aktualna nie jest w stanie sprostać zwiększającemu się natężeniu ruchu w sieci.
Budując zaporę sieciową na FreeBSD zyskujemy dość sporo. Oprogramowanie dostajemy za darmo, więc możemy zainwestować więcej pieniędzy w sprzęt. FreeBSD obsługuje w tej chwili popularne architektury 64-bitowe takie jak amd64, ia64 czy sparc64 oraz wspiera dobrze maszyny wieloprocesorowe. Poza tym dzięki otwartym źródłom mamy pewność, iż oprogramowanie jest wysokiej jakości, a ewentualne błędy będą szybko naprawione - nad projektem FreeBSD pracują setki deweloperów w tym firmy, które wybrały właśnie ten system jako platformę dla swoich rozwiązań.
W artykule tym skonfigurujemy zaporę sieciową w oparciu o system FreeBSD.

Aktualizacja i przebudowa systemu FreeBSD.

Instalując oprogramowanie bierzemy na siebie zobowiązanie nie tylko za jego prawidłowe działanie, ale również za jego aktualizację. Dopóki jest to nasz prywatny komputer to odpowiedzialność ta jest porównywalna do żonglowania własną komórką - jeśli przypadkiem spadnie na ziemie nikt nam nic nie będzie zarzucał tylko sami będziemy żałować poniesionej straty. Jednak w przypadku, gdy administrujemy serwerami jesteśmy również odpowiedzialni za bezpieczeństwo danych ludzi, którzy nam zaufali.
Tak naprawdę nie możemy obwiniać autorów oprogramowania za popełnienie błędów podczas jego tworzenia. Wbrew pozorom, programiści to też ludzie. Nawet ci najlepsi popełniają czasem błędy. Ponadto jeśli używamy Wolnego Oprogramowania to godzimy się z warunkami licencji, która zawsze jasno określa, że autorzy nie ponoszą żadnej odpowiedzialności za wynikłe z tego straty - instalujemy je na własną odpowiedzialność. W licencjach aplikacji komercyjnych wcale nie jest lepiej - występują w nich podobne stwierdzenia z tym, że są czasem lepiej zakamuflowane. Co zatem możemy zrobić?

9 kroków, aby podwyższyć bezpieczeństwo systemu FreeBSD.

Pojęcie ‘bezpieczeństwo’ stało się na przestrzeni lat względne i niejednoznaczne. Możemy przeczytać o systemach, w których często wykrywane są dziury, oraz o takich, w których dzieje się to rzadziej. Jednak poziom bezpieczeństwa maszyny zależy tak naprawdę w większości od administratora. To on zna system i powinien orientować jakie są jego czułe punkty. Spoczywa na nim również odpowiedzialność za odpowiednią konfigurację i aktualizację systemu.
Instalując FreeBSD zdecydowaliśmy się na system, który w opinii ekspertów jest stabilny i gwarantuje wysokie bezpieczeństwo. Potrzeby użytkowników są jednak różne, a płyta instalacyjna tylko jedna. Dlatego nie możemy oczekiwać, że po zainstalowaniu systemu będzie on stanowił fortecę nie do zdobycia - musimy wpierw poświęcić kilka chwil na konfigurację oraz włączenie przynajmniej podstawowych mechanizmów bezpieczeństwa.
W tym artykule przyjrzymy się 9 podstawowym krokom i technikom, które warto zastosować na administrowanych przez nas maszynach zanim trafią one do środowisk produkcyjnych.

Z życia administratora: Zaawansowany serwer WWW na FreeBSD.

Stało się to w pewne słoneczne, piątkowe popołudnie. Wszyscy w firmie myślami byli już na weekendzie ze swoimi najbliższymi - niektórzy żeglując po jeziorze, inni z kolei spędzając weekend z ukochaną w górach. Może tylko John nie miał żadnych planów - pewnie jak zwykle układał listę filmów do obejrzenia. Jedno było pewne - nikt już o pracy nie myślał. Wszyscy czekali, aż zegar wybije godzinę 16.00.
Mnie również ciągnęło do domu. Rozważałem nawet wcześniejszą ucieczkę z firmy. W końcu należy mi się trochę odpoczynku za te wszystkie nadgodziny w ostatnich tygodniach. Kiedy już zmierzałem w kierunku drzwi odezwała się komórka służbowa. Przeczuwałem, że nie będą to dobre wieści. Mimo wszystko odebrałem.
Zgodnie z prawami Murphy’ego wieści były jeszcze gorsze niż przewidywałem. Za 10 minut miała przyjechać nowa maszyna klienta, na której trzeba skonfigurować w pełni funkcjonalny serwer. Mówi się trudno - pomyślałem - taki zawód, że pewnie dziś znowu wyjdę jako ostatni.
Decyzja o wyborze systemu była dla mnie oczywista, więc nie tracąc czasu zacząłem ściągać obraz płyty instalacyjnej FreeBSD. Byłem przekonany, że przy odrobinie szczęścia uda mi się skończyć o normalnej porze. W końcu demon nigdy mnie jeszcze nie zawiódł.