Krótkie i długie odpowiedzi

Ostatnio doszedłem do wniosku, że odpowiadanie na z pozoru trywialne pytania początkujących programistów (głównie na forum Warsztatu, rzecz jasna) nie jest w rzeczywistości takie proste. Zwykle nie chodzi oczywiście o samą naturę problemu, który w większości ogranicza się do “tajemniczego” (głównie dla pytającego) komunikatu kompilatora, narzekającego na taką-a-taką linijkę w kodzie. Owszem, rozwiązanie często widać na pierwszy rzut oka. Gorzej jest z odpowiednim jego przekazaniem.

Z jednej strony można odpowiedzieć krótko, zwięźle i precyzyjnie, trafiając w samo sedno sprawy bez zbędnych wyjaśnień. Wtedy jednak nierzadko okazuje się, że taka odpowiedź rodzi raczej dodatkowe pytania, chociażby ze względu na odruchowe posługiwanie się pewnymi bardziej zaawansowanymi pojęciami, które dla nowicjusza będą nieznane. A stąd już niedaleko do bycia postrzeganym jako zarozumiały mądrala.
Zamiast tego można oczywiście udzielić długiej i wyczerpującej odpowiedzi, omawiającej spory zakres zagadnienia, którego dotyka problem. Można – jeśli ktoś ma na to czas i ochotę ;P Przy okazji można też niestety skutecznie oduczyć delikwenta samodzielności w znajdowaniu rozwiązań swoich programistycznych problemów.

A więc i tak źle, i tak nie(zbyt )dobrze :) Ale nie jest to w sumie zaskakujące: przecież podobno nie ma niewłaściwych pytań, a jedynie takież odpowiedzi. A przedstawiony wyżej dylemat ma też jedną poważną zaletę: jest całkiem dobrym pretekstem, aby przestać zajmować się cudzymi kłopotami i wziąć się za własny kod ;]

Sztuka zadawania zapytań

Podobno odpowiedź na (niemal) każde pytanie znajduje się tuż obok – na drugim końcu sieciowej wyszukiwarki. Tak przynajmniej utrzymują uczestnicy wielu internetowych forów. Aby jednak ją uzyskać, należy owo (za)pytanie odpowiednio sformułować, co wbrew pozorom nie musi być wcale takie łatwe.

Paradoksalnie przeróżne “usprawnienia” wprowadzane w mechanizmach wyszukujących, które mają uczynić je bardziej “inteligentnymi” i “spersonalizowanymi”, są często nieprzydatne przy poszukiwaniu konkretnych rozwiązań – zwłaszcza w dziedzinie programowania. Wydaje mi się bowiem, że o wiele ważniejszy jest właściwy dobór słów kluczowych i ich odpowiednia precyzja. Nie za mała – by nie zostać zasypanym tysiącami rezultatów, ale i niezbyt duża, by wyszukiwarka miała przynajmniej kilkadziesiąt wyników do posortowania względem trafności.
Jak więc dobierać odpowiednie słowa? Nie kreuję się oczywiście na jakiegoś eksperta w tej sprawie, ale z doświadczenia wynika mi kilka poniższych reguł:

• Należy zawsze dodawać nazwy biblioteki, systemu operacyjnego, platformy, itp., której dotyczy nasz problem. Bez tego z pewnością zostaniemy uraczeni doskonałymi rozwiązaniami, które całkowicie nie przystają do naszego środowiska.
• Ponieważ w języku angielskim (a tylko w nim jest sens wyszukiwać cokolwiek) rzeczowniki mają tę zaletę, że się nie odmieniają, dobrze jest dołączyć odpowiednią ich ilość. Muszą to być naturalnie takie wyrazy, które odnoszą się do poszukiwanego rozwiązania i nie zawężają zbytnio zakresu możliwych wyników.
• W przypadku często występujących słów, które mają kilka synonimów, najlepiej stosować ich najpopularniejsze wersje. Jeśli na przykład chcemy coś ‘pobrać’ (w sensie: uzyskać jakąś informację), to lepiej jest napisać get niż retrieve czy fetch. Może nie jest to literacka angielszczyzna, ale pamiętajmy, że dla autorów większości koderskich informacji, jakie można znaleźć w sieci, angielski prawdopodobnie nie jest językiem ojczystym… a pozostali to głównie Amerykanie ;D
• Jeśli nie poszukujemy przykładowych kodów odnoszących się do konkretnych klas czy funkcji, a raczej odpowiedzi na pytanie `Jak zrobić X na platformie Y przy użyciu biblioteki Z?`, to należy unikać podawania nazw wziętych bezpośrednio z kodu (czyli właśnie funkcji, metod albo klas). Może się bowiem okazać, że nasz problem trzeba rozwiązać przy całkowicie innych środków niż nam się pierwotnie wydawało, tj. innych metod, klas czy funkcji niż te, które podalibyśmy w zapytaniu. Dołączając je możemy łatwo uzyskać zupełnie nieprzydatne wyniki.

Chromowane gogle

Od wczoraj trudno jest zrobić cokolwiek, aby przy okazji nie usłyszeć o nowym produkcie Google’a, czyli przeglądarce internetowej Chrome. Zdaje sobie niestety sprawę, że pisząc o tym mimowolnie wpisuję się w trend, który – jak mniemam – wkrótce sprawi, że będziemy z lekkim niepokojem otwierać lodówki ;P Jak dotąd na szczęście Google tam nie wtargnął, ale i tak wygląda na to, że narobił sporo zamieszania. Głównie medialnego, rzecz jasna: jego szczytem jest stwierdzenie, że “Chrome być może stanie się wkrótce synonimem przeglądarki internetowej”, które można znaleźć w gazecie.pl. No cóż, nie od dziś mainstreamowe popisują się totalną ignorancją, gdy chodzi o IT.

Żarty żartami, ale w rzeczywistości pojawienie się Chrome’a przede wszystkim stwarza kolejny problem dla webmasterów i twórców aplikacji internetowych. Jest całkiem prawdopodobne, że na samej tylko marce Google’a (niezależnie od obiektywnej jakości) Chrome zdobędzie przynajmniej kilka procent udziału w rynku, być może zrównując się z Operą. A to oznacza ni mniej, ni więcej tylko to, że do trzech liczących się silników przeglądarek WWW, z którymi teraz muszą liczyć się twórcy stron, wkrótce dojdzie czwarty. Gdyby tak jeszcze wszystkie przynajmniej próbowały być nieco bardziej zgodne z sieciowymi standardami… ale cóż, takie życie :P
W każdym razie nowa i potencjalnie popularna przeglądarka to nowy i potencjalnie dotkliwy ból głowy dla developerów. Może więc chociaż użytkownicy dostają w zamian coś nowatorskiego? Oprócz zwiększającego stabilność otwierania zakładek w osobnych procesach – prawdopodobnie nie. Zresztą, czy czegoś podobnego nie miał przypadkiem już Eksplorator Windows i to zaledwie 10 lat temu? :)

Triki z PowerShellem #10 – XML

Obecnie magiczne trzy literki XML pojawiają się przy okazji niemal każdego aspektu programowania i informatyki w ogóle. Do przetwarzania danych zapisanych w tej postaci istnieje niezmierzona wręcz ilość różnych narzędzi. Nie jest więc niespodzianką, że nasz ulubiony PowerShell w tej dziedzinie również daleko nie odstaje :)
Jako parsera używa on oczywiście narzędzi zawartych w .NET, a dokładniej w przestrzeni nazw System.Xml. Są one jednak o wiele wygodniejsze w stosowaniu w skryptach PSh niż w zwykłych aplikacjach .NET. Spójrzmy chociażby na poniższy przykład:

To nic innego, jak najprostszy czytnik kanałów RSS. Pobiera on i wyświetla nagłówki wraz z datą ich publikacji z podanego URL-a, co wygląda choćby tak:

[Fri, 22 Aug 2008 11:21:52 +0000] Używanie nagłówków Windows
[Tue, 19 Aug 2008 10:53:24 +0000] To, czego oczekuje kompilator
[Sat, 16 Aug 2008 19:28:58 +0000] Statystyczny warsztatowicz
[Thu, 14 Aug 2008 06:24:54 +0000] Makra z wielokropkiem
[Mon, 11 Aug 2008 20:12:17 +0000] Długie ciągi odwołań
[Fri, 08 Aug 2008 20:00:57 +0000] Obiektowy szowinizm
[Tue, 05 Aug 2008 15:21:31 +0000] Czy void jest typem
[Mon, 04 Aug 2008 15:12:30 +0000] Prawie jak mapa
[Sun, 03 Aug 2008 15:33:28 +0000] Triki z PowerShellem #9 - Potokowanie
[Thu, 31 Jul 2008 14:34:14 +0000] Przeciążanie przecinka

Taka jest operacja jest całkiem łatwa do przeprowadzenia. Sparsowanie łańcucha znaków do postaci XML-owego drzewka DOM, reprezentującego jego zawartość polega na przykład na "rzutowaniu" tekstu na typ xml (będący aliasem na System.Xml.XmlDocument) - i już. Następnie możemy dostać się do poszczególnych tagów używając po prostu kropki. Zatem np. $xml.rss pozwala odwołać się do głównego elementu (<rss>) w dokumencie RSS. Jeśli zaś pod daną nazwą kryje się więcej niż jeden element, możemy je iterować tak samo, jak każdą inną kolekcję (a więc np. przez foreach).

Do bardziej zaawansowanych operacji należy zapewne wykorzystać właściwości i metody klasy XmlDocument. Ale do prostych zastosowań związanych z XML-em, jakie mniej lub bardziej systematycznie przytrafiają się każdemu, powyższy sposób postępowania może być całkowicie wystarczający.

Triki z PowerShellem #6 – Mail z załącznikami

Kiedy mamy komuś przesłać plik, możemy niekiedy użyć do tego zwykłej poczty e-mail. Nie jest to oczywiście możliwe zawsze: plik nie powinien być zbyt duży i zwykle nie może też należeć do żadnego z "niebezpiecznych" typów (np. aplikacji EXE), by serwery pocztowe mogły go przepchnąć bez narażania lub zatykania sieci.
Jeśli w naszym przypadku tak jest, to możemy wykonać całą operację na przykład przy pomocy poniższego skryptu PowerShella:

Jak widać, nie jest to nic skomplikowanego. A jak wykorzystać go w praktyce?... Podobnie jak prezentowany wcześniej skrypt do uploadu na serwer FTP, można go wywołać komendą w rodzaju:

którą podpinamy do menu kontekstowego plików lub podmenu Wyślij do.
W ten prosty sposób możemy oszczędzić sobie uruchamiania całego klienta poczty, względnie przeglądarki z webmailem. Naturalnie sporo rzeczy - jak chociażby temat wysyłanej wiadomości czy jej treść - możemy w zaprezentowanym kawałku kodu zmienić lub uzupełnić.

Lis w operze

Parę dni temu odbyła się premiera nowej wersji przeglądarki Opera, oznaczonej numerkiem 9.5. Z kolei jutro z wielką pompą opublikowana zostanie trzecia edycja Firefoksa. Przy tej zresztą okazji Mozilla organizuje Dzień Pobierania, z zamiarem ustanowienia rekordu ilości ściągnięć oprogramowania w ciągu jednej doby. (Mam aczkolwiek przeczucie, że prawdopodobne jest ustanowienie innego rekordu: najdłużej niedziałającego serwera pobierania ;]).
Zbieżność tych dwóch wydarzeń zapewne nie jest przypadkowa. Tym bardziej dziwi mnie to, że przy tej okazji zaprzysięgli fani któregoś z tych dwóch programów zajmują się głównie wykazywaniem w każdym możliwym miejscu, iż to właśnie ich ulubiona przeglądarka jest lepsza od tej drugiej. Naturalnie, argumentów jest przy tym mnóstwo: a to gesty myszki, a to współdzielenie zakładek i Ulubionych między komputerami, nie wspominając o tysiącach dostępnych rozszerzeń i wtyczek, coraz lepszych wynikach testów typu Acid3, wbudowanych klientach innych usług niż WWW, kilogramach skórek i pewnie wielu jeszcze innych zaletach. Część z nich może i jest ważna i interesująca. Rzecz w tym, że - statystycznie rzecz biorąc - nie obchodzą one psa z kulawą nogą.

Smutna prawda jest taka, że nadal większość użytkowników Internetu korzysta z "jedynie słusznej" przeglądarki pewnej znanej skądinąd firmy, a o dywagacjach na temat wyższości innych nad jeszcze innymi nigdy tak naprawdę nie słyszeli i raczej nie mają zamiaru usłyszeć. A to z wielu powodów niepokojące, chociażby ze względu na bezpieczeństwo czy powszechność stosowania standardów sieciowych. Wzajemne zwalczanie się zwolenników przeglądarek "niezależnych" (że je tak umownie nazwę...) na pewno nie zaradzi temu, iż połowa internautów wciąż używa do przeglądania Sieci programów przestarzałych i dziurawych jak ser szwajcarski.
A bliskość premier nowych edycji dwóch bezpiecznych, wygodnych i nowoczesnych przeglądarek to przecież całkiem dobra okazja, żeby coś na to poradzić. Zamiast więc bezowocnie spierać się, czy Safari jest lepsze od Opery, a ta od Firefoksa czy Camino, można by wspólnie zwiększyć wysiłki na rzecz uświadamiania użytkownikom niesłusznie najpopularniejszych przeglądarek, że istnieją dla nich o wiele lepsze alternatywy. Cóż bowiem z tego, że oto "wszyscy" przerzucą się czy na to Firefoksa, Operę czy inny tego typu program, jeśli ci 'wszyscy' to tak naprawdę ledwie 1/3 internautów?...

O (nie)zawodności TCP

Dowiadując się, czym jest protokół TCP, można przy okazji usłyszeć lub przeczytać, że jest on niezawodny (reliable). Można wtedy pomyśleć, że to jakiś rodzaj białej magii - zwłaszcza, gdy pomyślimy sobie, jakie przeszkody mogą spotkać przesyłany kawałek danych podczas podróży tysiącami kilometrów kabli (a ostatnio i bez nich). Zatory w transmisji, źle skonfigurowane routery, nagła zmiana topologii sieci, i tak dalej... Mimo to niektóre programistyczne interfejsy próbują nam wmówić, że odczyt i zapis danych "w sieci" jest w gruncie rzeczy niemal identyczny np. z dostępem do dysku. To pewnie też skutek "myślenia magicznego" na temat pojęcia niezawodności w kontekście TCP.

A w praktyce nie kryje się za nim żadna magia. Niezawodność TCP ma swoje granice i obsługuje dokładnie tyle możliwych sytuacji i zdarzeń losowych, ile zostało przewidzianych - jawnie lub nie - w specyfikacji tego protokołu. (Zawartej w RFC 793, jeśli kogokolwiek ona interesuje ;]). Analogicznie jest na przykład z dostępem do dysków wymiennych: stare wersje Windows potrafiły radośnie krzyknąć sławetnym bluescreenem, gdy użytkownik ośmielił się wyciągnąć dysk z napędu w trakcie pracy aplikacji, która z niego korzystała. Była to bowiem sytuacja nieprzewidziana na odpowiednio wysokiej warstwie systemu.
Jakie więc niespodziewane sytuacje i problemy dotyczące TCP należy przewidywać, jeśli piszemy programy sieciowe? Jest ich przynajmniej kilka:

• Pakiety TCP po drodze od nadawcy i odbiorcy mogą ulegać podzieleniu (fragmentacji) w celu przepchnięcia ich przez podsieci o różnych możliwościach przesyłu. Wszystkie kawałki są oczywiście składane przez odbiorcę w miarę ich napływania wraz z dodatkowymi informacjami, pozwalającymi na odtworzenie kolejności bajtów. Jednak fragmentacja sprawia, że nie musimy odebrać danych w porcjach tej samej długości, w jakiej były wysyłane. Dowolna ilość wywołań funkcji typu Send u nadawcy może przekładać się na równie dowolną liczbę wywołań Receive w celu odebrania wysłanych informacji. Stąd wynika konieczność rozróżniania porcji danych we własnym zakresie, o czym pisałem jakiś czas temu.
• Połączenie TCP może się zakończyć się nieoczekiwanie, jak choćby poprzez nagłe zakończenie wykorzystującego je procesu u jednej ze stron komunikacji. Wykrycie takiej sytuacji polega niestety wyłącznie na opóźnieniach (timeout) w otrzymywaniu pakietów potwierdzających (ACK) dostarczanie danych. To sprawia, że nie można odróżnić zerwania połączenia od zatorów w transmisji na poziomie samego protokołu TCP.
  Dlatego też trzeba sobie z tym radzić na wyższym poziomie, implementując w protokołach aplikacyjnych mechanizmy typu ping-pong do okresowego sprawdzania, czy połączenie "żyje". Należy przy tym sprawdzać czas odpowiedzi nie względem jakichś twardych limitów, tylko poprzednio rejestrowanych interwałów.
• 
  Diagram stanów
  połączenia TCP

  Wreszcie, połączenie TCP można też zakończyć grzecznie (wymianą pakietów z flagami: FIN, FIN/ACK i ACK), co powinno dać się wykryć przez sieciowy interfejs programistyczny. W praktyce bywają z tym problemy, a jako takie powiadamianie o rozłączeniu działa tym lepiej, im niższy poziom API jest używany. W miarę pewnie wygląda to na warstwie POSIX-owych gniazdek (w Windows zaimplementowanych jako biblioteka WinSock) oraz w ich bezpośrednim opakowaniu na platformie .NET (System.Net.Sockets.Socket) lub w Javie (java.net.Socket). Wraz ze wzrostem poziomu abstrakcji (jak chociażby w specjalizacjach "sieciowych" strumieni I/O) sprawa wygląda już nieco gorzej...

Z niezawodnością TCP nie ma co więc przesadzać. W szczególności nie powinniśmy oczekiwać, że zapewni nam ona ochronę przed wszystkimi wyjątkowymi sytuacjami, jakie mogą wydarzyć się podczas komunikacji sieciowej. O przynajmniej kilku musimy pomyśleć samodzielnie.