myGeeBlog

Jakiś czas temu, gdy spam w akismecie przekroczył barierę krytyczną (na tą chwilę mam odfiltrowane poprzez Akismet ponad 30k sztuk spamu), zrobiłem sobie mały, prosty skrypt który odwiedza mi stronę w adminie WordPressa, zbiera odfiltrowane IP postów, i zapisuje mi je, odfiltrowując klasy adresowe z Polski. Skrypcik nazwałem asipht. Dzięki niemu mam mniej więcej podgląd na to, z jakiego IP najczęściej spam dostaję, i najbardziej wybitne persony dodaję bezwarunkowo do .htaccess, w którym mam też kilka klas adresowych zerżniętych chamsko od Mikołaja :)

Skrypt nie jest doskonały, powiedziałbym wręcz że dużo mu brakuje, ale nie chce mi się dodawać więcej funkcjonalności, starcza mi to co jest. Najbardziej przydałaby się opcja porządnego logowania do serwisu, ale w zamian tego podałem mu cookiesy uwierzytelniające z WP :)

Jak ja tego używam: raz dziennie sprawdzam sobie w akismet czy coś się nie zaplątało, jeśli nie to odpalam asipht, a następnie usuwam wszystkie spamowe komentarze (circa 200 dziennie, choć zdarzało się i 1.5k). Za pomoca drugiego skryptu, asiphtstats, podglądam jakie adresy IP “wygrywają” w konkurencji najwięcej spamu z jednego adresu IP, a później ręcznie dodaję sobie zwycięzców do .htaccess, zapewniając sobie tym święty spokój od tego pismaka :)

Gdyby ktoś był zainteresowany takim skrypcikiem, to używane przeze mnie pliki można sobie pobrać z adresu urzenia.net/wp-content/asipht/.

Acha, odnośnie konfiguracji (znajdującej się pod koniec pliku asipht):

c_user_n

nazwa cookie z nazwą użytkownika (coś w stylu: wordpressuser_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)

c_user_v

zawartość tegoż cookie

c_pass_n

nazwa cookie z hasłem (np. ‘wordpresspass_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’)

c_pass_v

zawartość tegoż cookie

c_domain

nazwa domeny dla jakiej przeznaczone jest cookie

c_path

ścieżka dla cookie

url

pełen URL do strony z Akismet w naszym WP

savepath

określa ścieżkę zapisu pliku z zebranymi spamerskimi IP

whitelist

ścieżka do pliku z zakresami IP które nie będą dodawane do bazy, np: 217.119.64.0 217.119.79.255

pages

boolean, określa czy nasz Akismet stronicuje wyniki zebranego spamu (tak jak w nowej wersji), czy też nie (jak w starszej, lub zmodyfikowanej mojej :) )

Dzisiaj rzecz będzie o statystykach. Nie o odwiedzalności urzenia.net, czy jakiejkolwiek innej strony w sieci. Tym razem będę się “chwalił” o pisaninie na usenecie (grupach dyskusyjnych).

Jedyna słuszna wyszukiwarka, czyli Google, posiada takie coś jak statystyki grup dyskusyjnych. Można tam między innymi sprawdzić, kto był aktywny w danym miesiącu na danej grupie dyskusyjnej, albo na jakie grupy w ogóle pisywał etc. Dziś tam zajrzałem…

W dawnych czasach, gdy zaczynałem moją przygodę z siecią w ogóle, byłem bardzo aktywny na grupie pl.soc.seks. Do tej pory, pomimo nie pisania tam niczego już od kilku ładnych lat, jestem na 8 miejscu wśród najaktywniejszych osób na grupie. W sumie na 7, bo dwa miejsca zajmują maile Sabaziosa. Oj, to były czasy, po 1-2k postów na dobę ;)

Jakoś tak się zbiegło w czasie, że kończąc swój pobyt na pss, zaczęłem ukazywać się na pl.comp.www, gdzie też już od dłuższego czasu zbytnio się nie odzywam. Ale nie ma lekko, pomimo tego w ogólnej statystyce, jestem na drugim miejscu najczęściej udzielających się ;) Wyprzedził mnie tylko “dyżurny wróżbita”, PablO (czy też Pabl0, nigdy nie pamiętam ;) ). Ciekawe, czy wyprzedziłby mnie gdyby podliczyć moje posty z kilku innych maili, z jakich swego czasu pisałem (a raczej pseudo maili).

W sumie, Google zaindeksowało ponad 10k moich postów na newsgrupach. Pewnie w sumie było tego ze 2 lub 3k więcej, ale to już drobiazg ;) Nawet nie myślałem że aż taki produktywny byłem swego czasu :) Zajrzenie na te statystyki były drobnym szokiem, ale i przywołało przyjemne (i te mniej przyjemne też) wspomnienia :)

++$mysz;

Dziś będzie po perlowemu.

Ten kod:

	if (@_) {
		if (@_ == 1) {
			return $$CONFIG{$_[0]};
		} else {
			my $ret;
			push(@$ret, $$CONFIG{$_}) foreach (@_);
			return $ret;
		}
	} else {
		return $CONFIG;
	}

I ten kod:

	return $CONFIG		unless @_;
	return $$CONFIG{$_[0]}	if (@_ == 1);

	my @ret = @$CONFIG{@_};
	return wantarray ? @ret : \@ret;

Robią dokładnie to samo, choć dla niewprawnego oka linijka my @ret = @$CONFIG{@_}; może być nieco myląca :)

W zamierzchłych, zamierzchłych już czasach, gdy jeszcze pracowałem na co dzień z Pewnym Systemem Operacyjnym Pewnej Firmy z Redmond ™, używałem bardzo przyjemnego, tekstowego, przyjemnie mocno konfigurowalnego edytora jakim jest Edit+. Nie wyobrażałem sobie wtedy pracy z czymś innym. No, prawie - szukałem przez długi czas, nawet bardzo długi, czegoś lepszego, ale się nie dało… :)

Później nadszedł czas, kiedy zmieniłem Pewien System Operacyjny Pewnej Firmy z Redmond ™ na Jedyny Właściwy, Miłościwie Nam Panujący System Operacyjny ™. Tenże system to oczywiście Linux :)

Szukając i przeglądając rózne Linuksowe edytory, a jest ich całkiem sporo, natrafiłem (no dobra, nie dało się nie natrafić) na Vima, który, po krótkim przeszkoleniu, stał się Jedynym Prawdziwym Następcą ™ Edit+ :)

Vim pozwala na sprawną edycję, wraz z kolorowaniem składni, naprawdę wielu rodzajów plików. W sumie, nie znam takiego którego by nie umiał w konkretny sposób pokolorować :) A ja go najczęściej używam do edycji plików systemowych, albo do kodowania w językach PHP, Python, C++, C#, XHTML/HTML/CSS i JavaScript, a ostatnio także Perl, z czego języki C++ i C# znacznie rzadziej. Szczególnie ostatnio.

O ile do plików systemowych i tekstowych Vim w zupełności wystarcza, o tyle do pozostałych języków szukałem też już od dość długiego czasu czegoś, co pozwala mi w przyjemny i wygodny sposób zarządzać projektami, będzie mi co nieco podpowiadał jeśli chodzi o składnie kodu, pozwalało mi na szybkie przechodzenie między poszczególnymi kawałkami kodu (coś a la drzewo metod/funkcji) i znaczniki (bookmarki? w Vimie to się nazywa markery OIDP - chodzi o zaznaczenie linii kombinacją klawiszy, przejście gdzie indziej, znów zaznaczenie, a później za pomocą innej kombinacji klawiszy szybkie przechodzenie między tymi zaznaczonymi liniami), a do tego było wygodne jak Vim :) A jeśli już dałoby się tego używać także pod Windowsem, to już zupełnie bajka :)

Przeszedłem przez róźnego rodzaju IDE, jak Eric3 (tylko dla Pythona), Eclipse, Zend Studio, jak też mnóstwo zaawansowanych mniej lub bardziej edytorów, jak choćby jEdit czy gedit. I wciąż to nie było to ;) Albo za toporne, albo zbyt wolne, albo różne takie.

W końcu się stało. Natrafiłem na NIEGO. I się zakochałem ;)

Kilkanaście dni temu zaczęłem używać nowego, dla mnie, edytora: Komodo w wersji 4.0beta. I jak na razie, nie wliczając obsługi bugów ;) które jako wersja beta jeszcze posiada, jest prawie idealny:

• Tryb emulacji Vima daje mi swobodę, wygodę, możliwości i ułatwia przejście z Vima.
• Bardzo duże możliwości konfiguracyjne (no dobra, zdaje się że nieco mniejsze niż właśnie Vima :) ) dają mi możliwość dopasowania środowiska dla moich potrzeb (to był jeden z powodów dla których zaczęłem używać Linuksa…).
• Pełna obsługa (pełna, czyli nie tylko kolorowanie składni, ale podpowiadanie kodu, debugger, interaktywny shell i kilka takich różnych) języków JavaScript, PHP, Python, Perl i kilku innych, akurat mi niepotrzebnych, pozwala mi na swobodne poruszanie się w używanym akurat projekcie.
• Właśnie, obsługa projektów.
• Przeglądarka kodu w postaci drzewa, o czym pisałem wcześniej.
• Możliwość edycji plików znajdujących się na serwerze zdalnym (poprzez FTP, SFTP lub SCP).
• W wersji Professional obsługa systemów kontroli wersji CVS i SVN.
• Makra.
• Wstawki (snippety).
• Wieloplatformowość - zbudowany na bazie tego samego toolkitu co Firefox.
• dużo, dużo więcej….

A czemu tylko prawie idealny? No cóż, nie ma rzeczy idealnych ;) Mógłby być czasem nieco szybszy (aczkolwiek u mnie jest i tak dużo szybszy niż molochy typu Zend Studio czy Eclipse), mógłby być tańszy… Jeszcze kilka takich drobiazgów by się znalazło :) Ale mi jak na razie wystarcza. Jeśli tylko naprawią te bugi, które im zgłosiłem, a które dotyczą zarządzaniem projektem (przede wszystkim), to natychmiast po wyjściu 4.0 Full wysupłam te parę groszy na niego :) IMO warto… :)

Znalazłem także Windziany edytor, który ma jedną wg mnie niesamowitą funkcję: jest zintegrowany z systemem zarządzania wersjami, dzięki czemu jest pełne undo, także po zamknięciu pliku, możliwość tworzenia gałęzi kodu, z możliwością łatwego powrotu do któregoś z poprzednich rozgałęzienia etc. Niby nic, niby można to zrobić ręcznie, instalując sobie na localhoście choćby Subversion, ale to nie to samo: trzeba pamiętać o ręcznych commitach, o wielu nieistotnych szczegółach, a tutaj jest wszystko ładnie zintegrowane, z drzewkiem historii i takie tam. Dla mnie bomba.

PS. Ten edytor to e - Collaborative Text Editor.

Potrzebowałem ostatnio dostępu do Windowsa, ale nie zamierzałem instalować go obok mojego Ubuntu (tak tak, już od dość długiego czasu nie używam PLD ;] ), więc zabrałem się za VMware. Firma VMware udostępnia za darmo narzędzie VMware Player, którego można używać do “odtwarzania” gotowych obrazów, natomiast nie da się nim utworzyć tegoż obrazu. Do tego celu można użyć VMware Server/Workstation (bez klucza nie da się nim odtworzyć obrazu). A później tą metodą uzyskany obraz użyć pod VMware Playerem (ależ głupi Ci rzymi^W^W VMware’owianie ;) ). Spokojnie da się zainstalować potrzebnego nam Windowsa (w moim przypadku Home Edition). Gorzej później z jego używaniem… Wszystko jest maksymalnie wolne i nieprzyjemne w użyciu :)

Wersja Server czy też Workstation posiada możliwość zainstalowania czegoś, co się nazywa VMware Tools. Wchodzi się grzecznie w menu, klika odpowiednią opcję, on sam ściąga, instaluje i koniec. Dzięki temu dodatkowi system pod VMware dostaje pakiet sterowników, m.in. do karty graficznej, i wszystko zaczyna działać, wg mojej subiektywnej opinii, około 3-4x szybciej.

Super. Ale wersja Player takiego fiuczera w menu nie posiada. Więc jak przyśpieszyć system? Otóż poprzez ręczną instalację rzeczonych Toolsów.

A oto instrukcja krok po kroku:

1. trzeba ściągnąć ostatnią możliwą bez autoryzacji do pobrania wersję VMware Workstation (np. stąd: http://www.vmware.com/download/ws/)
2. znaleźć w ściągniętym archiwum plik o nazwie windows.iso (np. tar ztvf VMware-workstation-WERSJA_PLIKU.tar.gz | grep windows.iso)
3. wypakować tenże plik (np. $ tar zxvf VMware-workstation-WERSJA_PLIKU.tar.gz vmware-distrib/lib/isoimages/windows.iso)
4. podmontować wypakowany przed chwilą plik .iso pod wybrany katalog - ważne, żeby był on dostępny z poziomu zainstalowanego Windowsa - ja sobie udostępniłem go poprzez FTP (np. mount -o loop vmware-distrib/lib/isoimages/windows.iso /tmp/vmware_tools)
5. z poziomu Windowsa uruchamiamy plik setup.exe
6. cieszymy się z szybkiego i przyjemniejszego działania Windowsa :)

Po tych operacjach czasami warto zrestartować Windowsa, żeby w pełni wykorzystać możliwości Toolsów (jak np automatyczną zmianę rozdzielczości ekranu Windowsa dopasowaną do wielkości otworzonego przez nas okna :) ).

źródło

Ze względu na względy różne ;) w ogóle nie zauważyłem, że urzenia.net (jeszcze nie tak całkiem dawno diary.urzenia.net) obchodziło 23.11.2006 r. swoje drugie urodziny :).

Od poprzednich urodzin doszło równo 80 wpisów (przez pierwszy rok było ponad 2x tyle ;) ), i równe 250 komentarzy (wcześniej 278). Czyli ja mniej pisałem, w przeciwieństwie do Was ;) (oczywiście relatywnie)

Najwięcej osób odwiedziło mnie 24.10.2006 r., bo 354, a Wasz ulubiony wpis to ponownie rmvb & mplayer (choć dość ostro goni go Eclipse - to już jest koniec, nie ma już nic!).

Co by tu jeszcze… Acha. Jeśli dobrze pójdzie (czyt. jeśli znajdę na to nieco sił), to w tym miesiącu zmieni się dość znacznie design, który właśnie wykańczam (dobić chama ;) ), a ja spróbuję wyprodukować kilka nowych jeszcze mniej zrozumiałych, technicznych wpisów, które wszyscy tak lubicie ;) )

Dobra, koniec tego dobrego, czas kończyć. CUL8R :)