Chcąc "wodne" pole tekstowe umieścić na swojej stronie, możemy skorzystać z jednego z gotowych rozwiązań. Wiele z nich używa jQuery - darmowej biblioteki ułatwiającej pisanie w JS. Jeśli jednak nie korzystamy z niej w innych miejscach strony, to wymaganie jej obecności nie musi się nam podobać. A ponieważ watermark textbox jest efektem łatwym do zakodowania, spokojnie możemy napisać go własnoręcznie. Prześledźmy zatem, jak da się to zrobić.

Definiujemy najpierw styl naszego pola tekstowego, określający jego wygląd podczas wyświetlania wskazówki-znaku wodnego:

Szary kolor jest oczywiście tylko propozycją. Potrzebujemy w każdym razie osobnej klasy CSS, by oznaczać nią te textboksy, które mają wyświetlać znak wodny. Jako wskazówkę będziemy pokazywali początkową wartość pola tekstowego, czyli to co zostało fabrycznie przypisane atrybutowi value elementu input:

To właściwie tyle, jeśli chodzi o statyczny HTML; resztę musimy załatwić JavaScriptem. Interesują nas dwa zdarzenia: zyskania oraz utraty fokusu przez kontrolkę. Są to odpowiednio: onfocus i onblur. (Właśnie za takie nieintuicyjne nazwy "kochamy" JavaScript ;P). W reakcji na pierwsze z nich powinniśmy ukryć nasz szary tekst i pozwolić użytkownikowi na wpisanie nowego. Jeśli jednak tego nie zrobi, to w drugim zdarzeniu wykrywamy, że textbox jest wciąż pusty i ponawiamy wyświetlanie znaku wodnego. Oto procedury zdarzeniowe, które wykonują te czynności:

Jak można zauważyć, rzecz polega na dodaniu lub usunięciu nazwy uprzednio zdefiniowanej klasy CSS z listy klas pola tekstowego. Zakładamy tutaj, że atrybut watermark zawiera jego etykietę, czyli znak wodny. Żeby jednak tak było, musimy go ustawić, przy okazji podpinając (fuj, nie lubię tego słowa) przypisując powyższe funkcje do zdarzeń kontrolki. Czynimy to podczas wczytywania strony:

Przechodzimy po prostu po wszystkich tagach input, szukając zwykłych pól tekstowych (type równe "text"), które mają przypisaną "wodną" klasę CSS. Ustawiamy im następnie m.in. watermark na ich aktualną zawartość.

I właściwie to już wszystko. Okazuje się więc, że czasami JavaScript nie jest taki straszny ;) A jeśli chodzi o działający przykład praktyczny, to można go oglądać gdzieś nieopodal w postaci długo oczekiwanego formularza wyszukiwarki :)

Disclaimer: rozwiązanie testowane na najnowszych wersjach dwóch najsensowniejszych przeglądarek, czyli FF3.6 i IE8. Za Opery, Safari i inne chromy nie ręczę ;P

Okazuje się jednak, że to zupełnie wykonalne. Istnieją serwisy, które właśnie na coś takiego pozwalają. Jednym z najstarszych i najbardziej znanych jest Last.fm, zawierający chyba wszystkie feature'y, jakich można oczekiwać (łącznie ze stacjonarnym klientem), Niestety, jest on płatny.
Osobiście polecam darmowe Jango. Potrafi on dokładnie tyle, ile potrzeba - tj. tworzy wirtualne stacje radiowe (w dowolnej ilości, o ile mi wiadomo) grające muzykę wybranych wykonawców (z możliwością określenia preferencji do pojedynczych utworów) oraz artystów zbliżonych gatunkowo. To wyszukiwanie podobieństw działa przy tym całkiem dobrze, więc mamy spore szanse na odkrycie ciekawych, nieznanych wcześniej wykonawców. Wady?... Jak to bywa w przypadku takich serwisów, może to być niewystarczająco bogata biblioteka zarówno utworów, jak i artystów. Brakuje też desktopowego klienta, co może niektórym przeszkadzać; można wówczas spróbować zewnętrznego programu Jango Desktop.

Jak widać w obu przypadkach nie jest to specjalnie absorbujące zajęcie. Z gier pierwszego typu do gustu przypadła mi Word Challenge, dzięki której wydatnie (czyli o jakieś 5%) poszerzył się mój zasób angielskich słówek (niestety jedynie takich, które mają co najwyżej sześć liter). Wybraną przeze mnie pozycją z kategorii drugiej jest z kolei Castle Age - coś w rodzaju MMORPG-a przez przeglądarkę, całkiem zresztą udanego. I właśnie z tym związany jest pewien ciekawy problem...

W rzeczonej grze oprócz niewątpliwie ekscytującego odklikiwania kolejnych questów mamy też - że powiem nieco na wyrost - wątek ekonomiczny. Należy tam bowiem kupować nieruchomości, które później co godzinę generują nam przypływ świeżej gotówki. Budynki różnią się ceną i uzyskiwanym z nich przychodem, a ponadto możemy kupować je nie tylko pojedynczego, ale i w pakietach (po 5 lub 10).
Jak pewnie nietrudno się domyślić, nasuwającym się tu od razu pytaniem jest to o optymalną strategię nabywania kolejnych budynków, skutkującą największym zyskiem w dłuższej perspektywie czasowej. Tak naszkicowany problem inwestycji (nazwa brzmi cokolwiek poważnie!) miałby więc następujące założenia:

• Istnieje rodzajów budynków z przypisanymi cenami początkowymi i zyskiem generowanym na jednostkę czasu: . Początkowo posiadamy budynków i pieniędzy, ale w każdej jednostce czasu możemy dokonać dowolnej liczby zakupów, o ile posiadane środki na to wystarczają.
• Każdorazowo po dokonaniu zakupu budynku danego rodzaju, jego cena wzrasta o ustaloną wartość dla . Zakupu możemy dokonywać pojedynczo lub też w ilościach określonych przez zbiór (w Castle Age mamy ), jednak zawsze tylko jednego rodzaju budynków naraz.
• Istnieje ograniczenie na maksymalną posiadaną liczbę budynków jednego rodzaju - zatem zawsze zachodzi: . Dla ułatwienia możemy przyjąć, że ograniczenie to jest stałe (w Castle Age jest ono związane z poziomem doświadczenia).

Pytamy tutaj o to, kiedy, ile i jakie budynki powinniśmy kupować, aby zmaksymalizować swój zysk w długim (najlepiej dowolnie długim) przedziale czasu. W szczególności zastanawiamy się, czy działa tu prosta strategia zachłanna - podobna do rozwiązania ciągłego problemu plecakowego - polegająca na zbieraniu zawsze takiej ilości gotówki, aby kupować maksymalną ilość najbardziej "efektywnych" budynków, tj. tych o największym ilorazie zysku do bieżącej ceny. Intuicja podpowiadałaby, że nie dla wszystkich zestawów danych musi tak być...

Zostawiam więc to zadanie jako materiał do przemyśleń na wolne dni. Nagroda za jego rozwiązanie będzie wielka: udowodni się w ten sposób, że gry z Facebooka mogą się do czegoś przydać!

Stuprocentowo uzasadnione.

Może nie jestem w stanie tego zrozumieć, ale przynajmniej potrafię się z tym pogodzić - po części pewnie dlatego, że sprzątanie po tego rodzaju twórczości nie jest specjalnie kłopotliwe. Jest jednak przynajmniej jedna rzecz, która skłania mnie do poważnych rozważań na temat intelektualnej kondycji rodzaju ludzkiego - a przynajmniej tej jego części, która się na forum pojawia - połączonych z co najmniej jednokrotnym wykonaniem znanego i lubianego gestu kapitana Picarda.

O co chodzi?... O dołączanie nowych pytań do istniejących wątków, z uzasadnieniem, że czyni się tak po to, aby nie zaśmiecać forum nowymi tematami. Czy jest to dobra praktyka? Czy ma to jakikolwiek sens? I wreszcie, czy skutkiem jej stosowania jest faktycznie większy porządek forum?
Otóż nie - i to po trzykroć nie. Paradoks tu występujący polega właśnie na tym, że - dokładnie przeciwnie do intencji osób tak postępujących - podczepianie się pod istniejące tematy skutkuje tylko i wyłącznie jeszcze większym bałaganem! Dzieje się tak co najmniej z kilku powodów:

• Wprowadzanie nowego pytania w istniejący wątek odcina możliwość dodania czegokolwiek do oryginalnego tematu dyskusji. Jeśli ktoś mimo wszystko będzie próbował to robić, najprawdopodobniejszym rezultatem jest przeplatanka odpowiedzi na stare i nowe pytanie. Czytanie czegoś takiego to czysta przyjemność, nieprawdaż? 8-)
• Jeśli jeden wątek zawiera więcej niż jeden temat/dyskusję/pytanie, to jego tytuł staje się mylący. Po niedługim czasie podczepione posty mogą być już zupełnie niezwiązane z tym, o czym wątek był oryginalnie. Istny synonim porządku, co nie? :)
• Podczepione pytanie jest o wiele trudniejsze do znalezienia przez forumową wyszukiwarkę - jeśli to w ogóle jest możliwe. Co więcej, utrudnia ono też wyszukanie wszystkich informacji z oryginalnej dyskusji - choćby dlatego, że trzeba wpierw ustalić, gdzie się ona kończy...
• Przywrócenie radośnie zepsutego wątku do stanu używalności jest pracochłonne: wymaga zlokalizowania wszystkich postów odnoszących się do nowego pytania (które mogą się przeplatać z tymi od pierwotnego), wydzielenia ich do nowego wątku i nadania mu sensownego tytułu. To wszystko da się zresztą zrobić tylko przy założeniu, że nie istnieją już posty, które odwołują się do obu pytań naraz. Jeszcze bardziej daleko idące jest przypuszczenie, że istnieje jakikolwiek moderator, któremu chciałoby się takich podziałów dokonywać :)

Widać zatem wyraźnie, że skutek doczepiania się do istniejących wątków jest dokładnie odwrotny do zamierzonego. Nie ma to najmniejszego sensu i jest wybitnie niepożądane. Wciąż jednak nie mogę się nadziwić, jakaż to dziwna logika podsuwa ludziom pomysły, że może być inaczej...

Pewnie coś w tym jest. Jednak ostatnio ku mojemu zaskoczeniu (i pełnej aprobacie) pojawiło się też kilka dyskusji na tematy związane ze sztuczną inteligencją. Niby taki dział też jest, ale jakoś dotąd nie zauważyłem, by był zanadto aktywny.
A tu proszę: kilka ciekawych wątków w ciągu paru dni. Może to nic wielkiego i może niespecjalnie nawet jest tu o czym pisać, bo ich tematyka jest dość ograniczona (głównie sieci neuronowe), a dziedzina raczej akademicka i pewnie nawet niekoniecznie związana z gamedevem. Ale...

Ale myślę, że jednak warto o tym wspomnieć :) Przede wszystkim po to, by nikt nie zapomniał, że gry to nie tylko ładna grafika i że w dzisiejszych czasach powinny one być choć trochę - z braku lepszego słowa - 'inteligentne'.
A poza tym miałem też ochotę zwrócić uwagę na istnienie tego właśnie działu forum Warsztatu - więc niniejszym właśnie to czynię :]

Rok 1999 to nie były jakieś zamierzchłe czasy sieci w Polsce (nie wspominając już o sieci w ogóle), lecz mimo to podejrzewam, że niezbyt duża część obecnych jej użytkowników dobrze je pamięta. Cechą wyróżniającą Internetu w tamtym okresie była przede wszystkim oszczędność. Szerokopasmowe łącza nikomu się wtedy nie śniło, a część internautów musiała płacić za sam czas spędzony w sieci (sławetny numer 0202122). Dlatego też podstawową zasadą netykiety było możliwie najskuteczniejsze zmniejszanie rozmiarów przesyłanych danych. Objawiało się to dość spartańskim wyglądem ówczesnych stron, z rzadka składającym się z większej ilości obrazków, a często wykorzystującym takie niefortunne wynalazki HTML jak choćby ramki.
Jak nietrudno zauważyć dzisiaj jest zupełnie inaczej. Główna strona typowego portalu może spokojnie ważyć kilka megabajtów i być okraszona kilkoma reklamowymi animacjami typu Flash, często zresztą niczym nie różniących się od spotów telewizyjnych. Wymaga ona więc znacznie większej przepustowości łącza, a także o wiele lepszej i efektywniejszej przeglądarki.

To też zresztą znak rozpoznawczy Internetu końca dekady: jest on niemal tożsamy z WWW, a inne protokoły komunikacji są w głębokim odwrocie. Kilka lat wcześniej było pod tym względem inaczej. Przeglądanie stron było tylko jedną z wielu sieciowych aktywności, do których należało też korzystanie z e-maila, ściąganie plików przez FTP, czytanie grup dyskusyjnych (Usenet) czy pogaduszki za pośrednictwem IRC. Dzisiaj prawie każdy z tych kanałów komunikacji został pochłonięty lub zastąpiony przez tzw. aplikacje webowe, czyli po prostu trochę bardziej interaktywne wersje stron WWW.

I wreszcie trzeci aspekt zmian, jakie w sieci się dokonały: jej umasowienie. Nie chodzi tu tylko o sam wzrost liczby osób korzystających z sieci, który w ciągu ostatnich 10 lat był prawie czterokrotny. Chodzi o pewne zmiany w samej "strukturze" sieci, które są przynajmniej częściowo jego wynikiem.
Kiedyś w Przekroju czytałem artykuł reklamowany na okładce wiele mówiącą frazą: "Jak idioci zepsuli nam Internet". Dotyczy ona oczywiście całego sieciowego trendu znanego pod ogólnym określeniem Web 2.0, nad którym zresztą pastwiłem się już przy innej okazji. W skrócie chodzi mniej więcej o to, że połączenie masowości dostępu do Internetu (w krajach rozwiniętych to już przynajmniej połowa populacji) z łatwością umieszczania w nim nowych treści (coraz mniejsza konieczność znajomości takich "technikaliów" jak choćby HTML) powoduje zalanie sieci contentem bez żadnej wartości, czyli jej zwyczajne zaśmiecenie.
W sumie jednak jest to nic nowego; już przed 10 laty mówiło się, że zawartością Internetu są w większości bzdury. Różnica między stanem z tego czasu a dniem dzisiejszym jest jednak taka, że mimo bezwzględnego (a pewnie i względnego) wzrostu ilości treściowych odpadów znalezienie poszukiwanych informacji jest paradoksalnie łatwiejsze niż kiedykolwiek wcześniej. Zawdzięczamy to jednak tylko i wyłącznie gwałtownemu rozwojowi internetowych wyszukiwarek.

Ogólny bilans tej dekady w sieci nie jest więc jednoznaczny. Z jednej strony stoją rzecz jasna MySpace, Facebooka, 4chana czy inne sieciowe szkodniki, ale z drugiej jest przecież Google, Wikipedia i całe mnóstwo wartościowych serwisów tematycznych, z których część nie powstałaby pewnie w warunkach "elitarnego" Internetu sprzed dekady.
Jesteśmy więc w innym miejscu - lecz niekoniecznie gorszym. Trzeba się do niego po prostu przyzwyczaić :)

Ponieważ podobne sytuacje zdarzają mi się dość często, postanowiłem im zaradzić przy pomocy najlepszego narzędzia na takie okazje, czyli PowerShella rzecz jasna :) Wynikiem jest poniższy skrypt do sprytniejszego rozpakowywania archiwów:

Jego działanie polega wpierw na zwykłej dekompresji archiwum. Jak można zauważyć, używa do tego obiektu COM-owskiego Shell.Application. To sprawia, że skrypt ma pod tym względem te same możliwości co zwykły windowsowy Eksplorator (dla większych plików pokaże nawet pasek postępu ;]).
Później wypakowana zawartość jest poddawana operacji, którą nazywam tutaj 'skróceniem ścieżki'. Polega ona wyrzuceniu jednego poziomu drzewa folderów, o ile tylko pewien katalog jest jedynym elementem swojego katalogu nadrzędnego. Takie właśnie sytuacje powstają przy dekompresji do nowego folderu archiwów źle zapakowanych (przynajmniej z mojego punktu widzenia ;P). Wynikiem działania skryptu będzie więc w sumie jeden nowy podkatalog zawierający bezpośrednio całą interesującą zawartość archiwum.

Oczywiście używanie powyższego skryptu tylko z poziomu linii komend PowerShella nie jest specjalnie wygodne; lepiej jest dodać go do menu kontekstowego archiwów, czyli np. plików .. O tym, jak można tego dokonać, napisałem dość obszernie przy okazji prezentacji skryptu do wysyłania przez FTP.

Fakt sprawił rzecz jasna, że zaraz zachciało mi się wypróbować go w jakimś nowym zastosowaniu. Padło na wysyłanie update'ów do Twittera, w którym to zresztą niedawno się zarejestrowałem (i wciąż nie wiem, dlaczego ;)). Sprawa na oko nie jest trudna, bo sprowadza się do wykonania jednego żądania HTTP POST. Ale jak wiadomo, diabeł zwykle tkwi w szczegółach. Oto skrypt:

Jednym z owych detali było kodowanie statusu algorytmem dla URL-i (zamieniającym spacje na %20 itd.), wykonywane poprzez System.Web.HttpUtility.UrlEncode - stąd konieczność importowania assembly System.Web. Ale to jest w sumie pikuś.
Znacznie większym "trikiem" jest linijka oznaczona gwiazdką (*). Powoduje ona obejście domyślnego zachowania .NET, który do każdego żądania HTTP typu POST dodaje nagłówek:

Powoduje on wysłanie tak naprawdę dwóch requestów: w pierwszym serwer ma tylko sprawdzić poprawność nagłówków (logowania, na przykład) i zwrócić status 100 (Continue). Dopiero w drugim klient wysyła właściwe dane. Mechanizm ten jest w .NET opakowany przezroczyście i ma zapobiegać niepotrzebnemu przesyłaniu dużych ilości danych w żądaniu, które i tak byłoby odrzucone.
API Twittera jednak tego nie obsługuje i jest to właściwe. Trudno przecież nazwać status, mający maks. 160 znaków, "dużą ilością danych". Lepiej więc przesyłać go od razu, a domyślne zachowanie .NET-a obejść. To właśnie robi zaznaczony wiersz.

Przypomnę jeszcze tylko - gdy ktoś zechciał powyższego skryptu używać do przesyłania tweetów - że uruchomienie skryptu PSh z poziomu zwykłej linii poleceń wymaga parametru -Command i kropki:

Do takiej komendy można np. utworzyć skrót i przypisać mu kombinację klawiszy w celu szybkiego uruchamiania.

No i voila - to już się dzieje. Oto powstała strona internetowa, z której można się dowiedzieć... czym są przeglądarki, dlaczego nie są tym samym co internetowe wyszukiwarki i czym różnią się od reszty systemu operacyjnego. Tę wiedzę możemy posiąść między innymi poprzez oglądnięcie wielce interesującego filmiku. Żeby było jeszcze zabawniej, wspomnę, że tę edukacyjną witrynę przygotował nie kto inny, jak tylko sam... Google!
W rzeczywistości jednak nie ma się z czego śmiać. Skoro już nawet tam dostrzegana jest potrzeba szerszego informowania o tym, że Firefox jest czym innym niż Windows, a pasek adresu to nie to samo co pole zapytań wyszukiwarki, to ze stanem tej wiedzy wśród tzw. przeciętnych użytkowników musi być naprawdę źle. A skoro granica między online i offline tak bardzo się zatarła, to ani się obejrzymy i zawód programisty zostanie zastąpiony przez web developera...Brr! Chciałbym, żeby tym razem moje przewidywania w tej dziedzinie się nie sprawdziły :P

Bywa jednak tak, że chcemy dokonać takiego przekierowania - z ustalonymi parametrami - po zwykłym kliknięciu na link, z pominięciem wypełniania formularza przez użytkownika. Dobrym przykładem jest sytuacja, gdy nasza strona korzysta w jakiś sposób z innego serwisu, do którego przejście wymaga logowania. Jeśli chcielibyśmy, by odbywało się ono automatycznie - po kliknięciu jakiegoś linku - to musimy wysłać odpowiednie żądanie HTTP z parametrami przesłanymi metodą POST. Do tego nie wystarczy niestety sam znacznik <a>.

Rozwiązaniem jest wtedy użycie dodatkowej strony przekierowującej, na której umieścimy już odpowiednio "wypełniony" formularz:

Oczywiście nazwy i wartości parametrów (zapewne generowane dynamicznie po stronie serwera) zależą ściśle od tego, dokąd chcemy nasz wyrób formularzopodobny wysłać. Wszystkie je deklarujemy jednak jako <input type="hidden" />, bo w założeniu użytkownik nie powinien ich (łatwo) zobaczyć. Ponadto, jeśli - tak jak wyżej - mówimy o loginie/haśle czy innych danych, które powinno się chronić przed niepowołanym dostępem, to powinniśmy jeszcze wysyłać razem z naszą stroną nagłówki HTTP zabraniające cache'owania:

W końcu, skoro mamy już gotowy "formularz", to trzeba jeszcze zadbać o to, by wysłał się on sam natychmiast po załadowaniu strony przekierowującej. Do tego już trzeba wykorzystać skrypt uruchamiany w przeglądarce:

Tak przygotowaną stronę możemy podlinkować pod nasz serwis. Jak widać trochę z tym zabawy, ale tak to jest, gdy chcemy zrobić coś niestandardowego :)