Triki z PowerShellem #2 – Szybki upload

Oto zadanie: mamy plik, który chcemy komuś przesłać przez Internet i mieć przy tym jak najmniej zawracania głowy. Jest oczywiście e-mail, są komunikatory, podprotokół IRC-a o nazwie DCC serwisy typu RapidShare, itd. Każdy z tych sposobów wymaga jednak albo wymiany jakichś informacji typu adres czy numer identyfikacyjny, albo nie zawsze chce działać w różnych konfiguracjach sieci (zwłaszcza gdy jedna ze stron jest ukryta za NAT-em), albo... wymaga wpatrywania się w literki celem odróżnienia psów od kotów :)
Jeśli jednak dysponujemy serwerem FTP z zawartością dostępną przez HTTP (czyli po prostu hostingiem strony WWW), to możemy dzielić się plikami w prostszy i szybszy sposób. W tym celu posłużyć się można odpowiednim skryptem w PowerShellu, który potrafi samodzielnie połączyć się z serwerem FTP i wgrać na niego podany plik, a potem zwrócić jego URL. Następnie możemy przekazać go osobie, której chcemy przekazać plik.

Całkiem zmyślnie, prawda? Wystarczy jedynie odczytać lokalny plik, a następnie użyć .NET-owej klasy System.Net.FtpWebRequest w celu wykonania "żądania FTP" w postaci uploadu tegoż pliku na serwer.

Co jednak zrobić z takim skryptem, aby był użyteczny?... Jako że jego parametrem jest ścieżka do lokalnego pliku, który chcemy załadować, możemy użyć następującej komendy:

w celu jego wywołania - o ile potrafimy sprawić, by system Windows zamienił nam symbol zastępczy %1 na rzeczoną ścieżkę. Jest to możliwe przynajmniej na dwa sposoby:

1. Możemy dodać nowe polecenie do podmenu kontekstowego Wyślij do, wyświetlanego dla każdego pliku w Eksploratorze Windows. W tym celu wystarczy stworzyć plik wsadowy (.bat) w katalogu SendTo, zawierający powyższą komendę, i nazwać go odpowiednio intuicyjnie. Po odświeżeniu Eksploratora, we wspomnianym menu pojawi się nowa pozycja, której wybór uruchomi nam nasz skrypt dla wybranego pliku.
2. Innym wyjściem jest po prostu dodać nową akcję dla każdego typu plików, przez co będzie ona wyświetlania w głównym menu kontekstowym, obok innych: Otwórz, Edytuj, Drukuj, itd. Aby tego dokonać, najwygodniej jest po prostu otworzyć Edytor Rejestru i przejść do klucza HKEY_CLASSES_ROOT/*/shell. Tworzymy tam nowy podklucz, nazywając go jakoś odpowiednio (np. upload) i wpisując jako wartość domyślną tekst polecenia, który chcemy zobaczyć w menu (np. Upload). Następnie tworzymy tam podklucz command, ustawiając jego wartość domyślną na polecenia uruchomienia skryptu. Odświeżamy Eksplorator i mamy już nowe polecenie w menu kontekstowym.

Sprytne i wygodne. I kto teraz powie, że tylko w systemach linuksowych można bezustannie kombinować, by dostosowywać je do swoich potrzeb ;-)

PS. Użyty w skrypcie program clip jest bardzo prosty: kopiuje on po prostu swoje wejście do Schowka. Niestety, to malutkie narzędzie nie jest obecne w Windows XP. Nie ma tam więc prostego sposobu na wpisanie tekstu do Schowka z poziomu PowerShella. Alternatywą jest wypisanie URLa- do załadowanego pliku bezpośrednio w oknie konsoli PSh. Wystarczy po prostu zmienić clip na Out-Host, a także zmienić wywołanie skryptu, dodając parametr -NoExit:

To sprawi, że o wykonaniu operacji konsola PowerShella pozostanie otwarta wraz z wypisanym w niej URL-em, który można z niej skopiować.

Rozdzielanie pakietów

Protokół TCP ma to do siebie, że możemy mu zaufać - zawsze mamy gwarancję, że dane wysłane trafią do odbiorcy (a jeśli nie trafią, to będziemy o tym wiedzieli). Dlatego możliwe jest traktowanie przesyłu danych tą drogą podobnie, jak chociażby wymiany danych między pamięcią operacyjną a plikiem na dysku. Z tego też powodu wiele języków programowania pozwala na opakowanie połączeń TCP/IP w strumienie o identycznym interfejsie jak te służące na przykład do manipulowania zawartością pliku.
W praktyce jednak nie da się pominąć zupełnie tego prostego faktu, iż odbierane dane pochodzą z sieci i wysyłane także tam trafiają. Dotyczy to na przykład takiej kwestii jak dzielenie informacji na małe porcje u nadawcy i ich interpretacja po stronie odbiorcy.

Jak bowiem wiadomo, dane przesyłane przez TCP/IP mogą być po drodze dzielone i składane, a zagwarantowana jest jedynie ich kolejność. Nie ma natomiast pewności, że kawałek danych wysłany jednym wywołaniem w rodzaju Send zostanie odebrany także jednym wywołaniem Receive. Granice między porcjami danych każdy protokół musi więc ustalać samodzielnie. Można to zrobić na kilka sposobów, jak chociażby:

• Jawne zapisanie długości pakietu. Polega to na wysłaniu przed właściwymi danymi nagłówka o stałym rozmiarze, który ma ustalony format i którego częścią jest długość następującej dalej porcji danych. W najprostszym wypadku może być po prostu wysłanie najpierw np. czterobajtowej liczby z długością pakietu, a następnie reszty danych. Dzięki temu program odbierający zawsze będzie wiedział, ilu bajtów należy się spodziewać (a więc najpierw czterech, a potem tylu, ile wynosi odebrana długość).
• Używanie ustalonego rozdzielacza. To rozwiązanie polega na określeniu jakiejś sekwencji bajtów jako znacznika końca pakietu. Bardzo często (HTTP, FTP, IRC, itd.) jest to znak końca wiersza, oddzielający poszczególne żądania i odpowiedzi, lub znak o kodzie zero (\0). Odbieranie danych polega wtedy na odczytywaniu kolejnych bajtów do bufora i interpretacji pakietu dopiero po otrzymaniu końcowego znacznika.
• Korzystanie z własności pewnych formatów danych. Można mianowicie przesyłać informacje wyłącznie w określonym formacie, którego struktura pozwala określić, gdzie kończy się jedna porcja, a zaczyna druga. Jeśli przykładowo wykorzystamy XML i będziemy przesyłali wyłącznie pojedyncze jego elementy - np. <foo>...</foo> - to koniec takiego elementu będzie jednocześnie wiadomością o końcu pakietu. Można to więc traktować jak nieco bardziej skomplikowany wariant znaczników końca.

Jeśli tworzymy nowy protokół dla własnych aplikacji, to który wariant wybrać? Pierwszy wydaje się być dobry dla protokołów binarnych; tych jednak generalnie nie powinno się używać ze względu na liczne problemy z kodowaniem i pakowaniem danych. Druga opcja jest bardzo szeroko stosowana w wielu powszechnie używanych usługach sieciowych i wydaje się sprawdzać całkiem dobrze. Trzecia jest w gruncie rzeczy podobna, ale nieco bardziej złożona i może być kłopotliwa od strony kodu odbierającego dane.

Nowe twarze

Jednym z zabawnych aspektów konferencji takich jak IGK jest możliwość spotkania ludzi, których dotąd znaliśmy jedynie za pośrednictwem internetowych form kontaktu, takich jak fora czy komunikatory. Przez ten czas zdążyliśmy zapewne wyrobić sobie jakieś wyobrażenia o tym, kto kryje się pod ciągiem znaków składających się na dany nick. Zależnie od tego, czego te przypuszczenia dotyczą, ich trafność może wahać się od całkiem wysokiej do niemal zerowej.
Zawsze jednak jest to ciekawe przeżycie, a ich mnogość to jeden z argumentów przemawiających za uczestniczeniem w konferencjach w rodzaju IGK :) Przybycie po raz pierwszy na tą imprezę jest często oznaką, że dana osoba zabawi na Warsztacie nieco dłużej, nie zniknie bez śladu i nie straci zainteresowania tematyką programowania gier. Od reguły są oczywiście wyjątki, które, jak wiemy, głównie ją potwierdzają.

Nie da się jednak ukryć, że konferencja - mająca od początku swoje korzenie w pomyśle na "zjazd Warsztatu" - stała się najważniejszym, corocznym wydarzeniem tego community. I fakt, że co roku widzimy na niej nowe - warsztatowe - twarze oznacza, że jako społeczność trzymamy się mimo wszystko całkiem dobrze :)

Magazyn o Warsztacie

k_b wcielił w życie bardzo ciekawy pomysł, polegający na wydawaniu co jakiś czas magazynu opisującego wydarzenia dziejące się na Warsztacie. Chodzi tu na przykład o postępy w amatorskich projektach, które są z tym community związane, interesujące screeny, ciekawostki z forum i inne warte odnotowania fakty. W o wiele skromniejszej formie coś takiego już występowało w postaci tzw. Community News, ale ostatecznie niezbyt się to przyjęło.

Miejmy nadzieję, że z WMagiem - bo tak w skrócie się to wydawnictwo nazywa - będzie inaczej. Pierwszy numer nie grzeszy może zachwycającą szatą graficzną, ale i tak warto mu się przyjrzeć. Do czego zachęcam, prezentując poniższe linki:

• Warsztat Mag w wersji PDF
• notka na blogu k_b
• wątek na forum Warsztatu

Forumowa numerologia

Internetowe fora to podobno następny stopień ewolucji list i grup dyskusyjnych Usenetu. Na pewno mają niezaprzeczalne zalety - jak choćby to, że można się do nich dostać przy pomocy zwykłej przeglądarki (nie potrzeba specjalnych klientów), a ich zawartość jest indeksowana przez co sprytniejsze wyszukiwarki. Ale razem z tymi zaletami "w pakiecie" mają też pewną cechę, którą osobiście uważam za wadę - wprawdzie niezbyt ciężką gatunkowo, lecz stanowiącą według mnie pewien mankament.
Mam tu na myśli panujący na forach kult numerków, którego najważniejszym obiektem jest oczywiście licznik postów opublikowanych przez danego użytkownika. Liczba ta, niby ważna dana osobowa, prezentowana jest prawie zawsze po lewej stronie każdej wypowiedzi (w miejscu, które żartobliwie nazywam 'nagrobkiem' :]).

Co w niej takiego złego? Obiektywnie patrząc, to tylko statystka, która nie niesie żadnej znaczącej informacji. Nie mówi ani o stażu danego delikwenta na forum, ani o jego codziennej aktywności, ani o jego poziomie zaawansowania w temacie, którego forum dotyczy, ani o umiejętności stosowania przezeń zasad netykiety. Część z tych informacji można odnaleźć, przyglądając się profilowi ze szczegółowymi informacjami o danym użytkowniku. Jednak one nie są pokazywane przy każdym poście - w przeciwieństwie do wspomnianego licznika postów. Czym więc on jest? Otóż jest to taki "magiczny numerek", kojarzący się nieodparcie z dziesiątkami liczb występujących w grach (MMO)RPG i których mozolne podbijanie zajmuje wiele godzin. Prawie nic nie znacząca wartość, która może być co najwyżej skorelowana z samooceną tego, który zwraca na nią uwagę. Notabene zdarzało mi się widzieć rozwinięcie owego numerka do karykaturalnej postaci RPG-owej: z paskami życia, many i doświadczenia! Na całe szczęście na warsztatowe forum takie wynalazki (jeszcze) nie dotarły :)
Ażeby dodać przeciwwagę dla licznika postów (podbijanego zarówno przez wartościowe, jak i bezsensowne wypowiedzi), na wielu forach - włączając Warsztat - istnieje karma (choć są warianty tego mechanizmu o innych nazwach). W założeniu każdy użytkownik forum może innemu użytkownik dodać jeden punkt owej karmy, jeśli uzna jakąś jego wypowiedź za pomocną, interesującą lub wartościową. Akt ten nazywa się 'dokarmianiem', chociaż użyta w tym znaczeniu nazwa 'karma' nie ma rzecz jasna nic wspólnego z jedzeniem :) Tak czy owak, sumaryczna wartość zebranej przez forumowicza karmy jest, podobnie jak licznik postów, wyświetlana obok każdej jego wypowiedzi.

Pomysł na pierwszy rzut oka wydaje się znacznie lepszy niż licznik postów, ale ja uważam, że skutki istnienia obu tych mechanizmów są w gruncie rzeczy podobne. Oba są związane z jakimiś rzekomo znaczącymi liczbami, które mają w jakiś sposób opisywać użytkownika, którego się tyczą - co w domyśle znaczy oczywiście, że im większe one są, tym forumowa twórczość danej osoby jest bardziej wartościowa. Oba są też bardzo narzucające się innym użytkownikom; w końcu nie sposób przeoczyć czegoś, co jest wyświetlane obok każdej wypowiedzi.
I oba mogą sprawić, że będziemy - choćby podświadomie - zwracali uwagę na to, aby "przy okazji" dyskusji na forum podbijać te współczynniki jak najwyżej. Samo to nie będzie dobrze jej służyło, a poziom i przydatność forum może wręcz na tym ucierpieć. Zwiększenie licznika postów polega przecież na, niespodzianka, pisaniu postów - a wiadomo przecież, ze ilość nie musi przekładać się bezpośrednio na jakość. Z kolei polowanie na każdy dodatkowy punkt karmy oznacza dopisywanie swoich pięciu centów do każdego pojawiającego się wątku - zwłaszcza takiego z pytaniem lub prośbą o pomoc - nawet jeśli nie mamy w temacie zbyt wiele do powiedzenia (co może wręcz ograniczać się do zakamuflowanego powtarzania wypowiedzi przedmówców). Trudno się nie zgodzić, że podobne praktyki nie służą dobrze funkcjonowaniu forum jako źródła wiedzy i miejsca do rzeczowej dyskusji oraz zadawania pytań i otrzymywania na nie pożytecznych odpowiedzi.

I dlatego przyznam się do radykalnego poglądu. Gdybym dysponował odpowiednią mocą sprawczą, czym prędzej pozbyłbym się tego rodzaju pseudostatystyk - a przynajmniej schował je głęboko i nie eksponował przy każdej okazji. Na forum wymowni powinni być ludzie, a nie liczby :P

Łapacz pakietów

Oprogramowanie open source nie grzeszy zazwyczaj jakością, lecz od każdej reguły istnieją przecież wyjątki. Ostatnio znalazłem właśnie taki wyjątek; należy on do tej kategorii programów, które wymagają pewnego przygotowania, jeśli chcemy z nich korzystać efektywnie. Lecz mimo tego, iż jest to dość specjalistyczne narzędzie, nie sposób przy jego pomocy zrobić krzywdy swojemu systemowi. Warto się więc mu przyjrzeć, bo wśród tego rodzaju programów jest ono prawdopodobnie jednym z najlepszych.
Mam na tu na myśli analizator pakietów sieciowych Wireshark. Przy jego pomocy możemy bez większych problemów podejrzeć, cóż takiego jest przesyłane wzdłuż biegnących od naszego komputera kabli (względnie fal radiowych). Takie programy są popularnie nazywane snifferami i mogą służyć do bardzo wielu pożytecznych celów oraz kilku innych, mniej chwalebnych ;-)

Wśród wyróżniających cech Wiresharka trzeba na pewno wymienić interfejs, który jest przejrzysty, a przy tym funkcjonalny - co nie zdarza się często nawet wśród nie-GPL-owych programów. Bez większych problemów możemy złapane pakiety przeglądać i filtrować według wielu różnych kryteriów. Mogą one obejmować także cechy dot. specyficznych protokołów sieciowych (możemy np. wyświetlić pakiety HTTP z żądaniami typu GET). A tych wspieranych przez program jest zresztą całkiem sporo. Pakiety należące do znanych protokołów są oczywiście automatycznie rozkodowywane i pokazywane w przyjaznej postaci z podziałem na warstwy OSI, pola w nagłówkach oraz zasadniczą treść.

To oczywiście nie wszystko; do innych bardzo użytecznych funkcji należy chociażby możliwość wyodrębnienia całego strumienia TCP (czyli np. "rozmowy" jakiejś aplikacji ze zdalnym serwerem). Podobnie przydatnych narzędzi jest zresztą więcej i ciężko byłoby je wszystkie tu wymienić.
Dodatkowo program ten jest wybitnie wszędobylski i posiada równoważne wersje dla prawie każdego sensownego systemu operacyjnego, z Windows i przeróżnymi Linuksami włącznie. Biorąc pod uwagę to, że działa sprawnie, szybko i intuicyjnie, trzeba przyznać, że to nieoceniony instrument dla programisty piszącego aplikacje sieciowe.

Polityka spójności

Fakt jest oczywisty: moderatorzy są tylko ludźmi i mogą popełniać błędy. Dotyczy to nawet tak wybitnych osobistości, jak moderatorzy forum Warsztatu :) Co więcej, można mylić się na całego i globalnie - czyli na przykład w tak fundamentalnej kwestii jak to, czy wobec tzw. lamerstwa przyjmować postawę ostrą czy względnie łagodną.
Można to jednak zawsze poprawić. Ale sytuacja wygląda o wiele gorzej, jeśli moderatorzy przestają działać jako drużyna i zaczynają wchodzić sobie nawzajem w drogę.

W ten sposób dorobiliśmy na Warsztacie dwóch swego rodzaju "frakcji" moderatorskich. Pierwsza z nich opowiada się za literalnym stosowaniem dość restrykcyjnego regulaminu i stanowczym reagowaniem na wszelkie przejawy wspomnianego już lamerstwa. Druga zaś preferuje raczej łagodne podejście do problemu i służenie pomocą nowo przybyłym, którzy niekoniecznie potrafią jeszcze dostosować się do panujących zasad,
Nietrudno zauważyć, że te dwie grupy mogą często wykonywać sprzeczne ze sobą działania. A to na pewno nie poprawia skuteczności ani jednej, ani drugiej. Dodajmy do tego jeszcze spore grono zwolenników każdej z tych opcji wśród zwykłych użytkowników forum i mamy niewielki chaos.

Poglądowa ilustracja, obrazująca dwa różne podejścia do problemu lamerstwa :)

Nie twierdzę oczywiście, że wśród moderatorów nie mogą występować nawet najmniejsze różnice opinii, bo taki stan rzeczy jest z założenia idealny i niemożliwy do osiągnięcia w rzeczywistości. Według mnie wypadałoby jednak prezentować w miarę spójne stanowisko przynajmniej "na zewnątrz". W sytuacji, gdy dwie grupy wykonują względem siebie mniej lub bardziej krecią robotę, utrzymanie porządku staje się o wiele trudniejsze. A poza tym przysparza to jeszcze większych dylematów tym moderatorom, którzy chcą zachować jako taką 'neutralność', do których to zaliczam swoją skromną osobę :]