Nowa wersja plugina do WordPressa pokazującego statusy z Blip!a. Zmiany:
- update BlipApi.php do nowej wersji
- linkowanie tagów i użytkowników
- dodanie pliku README z podstawową dokumentacją
Zainteresowanych zapraszam ściągania i aktualizowania :)
Kilka dni temu Tomasz Tybulewicz (http://tybulewicz.com/) podesłał mi wersję BlipApi.php z dodaną obsługą operacji na obrazkach, jakie zaczęło oferować Blip!owe API :) Tomek równocześnie dołączył do “zespołu” tworzącego i rozwijającego BlipApi, które obecnie jest tylko w wersji PHP, a docelowo, o ile czas pozwoli, pojawi się w jeszcze kilku językach. Nie będę na razie mówił w jakich, bo to dość niepewna przyszłość ;)
Nową wersję można pobrać ze specjalnie utworzonego w tym celu projektu na Google Code: blipapi.googlecode.com (jeśli ktoś kojarzy projekt blipapi-php na Google Code, to niech wymaże go ze swoich bookmarków, został usunięty).
Dokopałem się właśnie do pewnego wpisu na PeHaPowym Wiki omawiającego status i różne ciekawostki dotyczące PHP6. Można się dowiedzieć fajnych rzeczy… Ale po kolei.
Od jakiegoś czasu wymyślam sobie różne udoskonalenia dla Vima, i piszę je zazwyczaj w Pythonie :) Niedawno opisywałem jak wyświetlić listę funkcji z edytowanego pliku, później zrobiłem sobie wygodne komentowanie kodu (wersje które znalazłem na sieci nie satysfakcjonowały mnie), teraz przyszedł czas na sprytne (w sensie: wygodne) uruchamianie właśnie edytowanego skryptu/programu :)
Do niedawna używałem prostego Pythonowego skryptu, który wywoływem z Vima:
!$ %Wykrzyknik to polecenie wywołania programu z shella, $ to nazwa skryptu, a % jest rozwijany przez Vima do pełnej ścieżki bieżącego pliku. Było to o tyle wygodne, że nieważne w jakim języku pisałny był skrypt/program, $ uruchamiał odpowiedni interpreter, ze skonfigurowanymi parametrami i wyświetlał wyjście. Tą funkcjonalność oczywiście potrzebowałem zachować, ale wykonywanie zewnętrznego programu jest strasznie niewygodne ;) Więc zrobiłem sobie wygodniejszą, i nieco bardziej rozbudowaną wersję. Inne założenia to możliwość przekazywania parametrów do wykonywanego programu, oraz dla niektórych języków możliwość wcześniejszej, automatycznej kompilacji.
Jakiś czas temu napisałem artykuł o setterach i getterach w PHP5. Może warto poruszyć podobny temat dotyczący Pythona? :)
Przede wszystkim, model obiektowy Pythona jest zupełnie inny niż PHP. Nie będę go tu omawiał, ponieważ to temat na dość obszerną książkę :) Generalnie obiektówka Pythona jest pełniejsza, ma większe możliwości przeciążania zarówno metod, jak i operatorów (których w PHP przeciążyć nie można).
Już od jakiegoś czasu deweloperzy Pythona przygotowują nową, niekompatybilną z poprzednimi, wersję Pythona. Python, gdyby ktoś nie wiedział, to jeden z najfajniejszych języków jakie wymyślono ;) (oczywiście to mocno subiektywne uczucie, ale może kogoś zachęci ;) ). Napiszę tutaj o dwóch ważnych zmianach, co do których nie byłem zupełnie przekonany (a konkretnie: w ogóle nie byłem przekonany), a które spodobały mi się po dzisiejszej krótkiej zabawie z wersją alpha3 Pythona 3000 :)
Developerzy PHP, projektując “nową” implementację OOP (nową w cudzysłowiu, bo raz że to było już kilka lat temu, a dwa, że dotyczy tylko i wyłącznie samego PHP), dość mocno wzorowali się na Javie. Czy to dobrze czy to źle to kwestia gustu, jednak wynika z tego kilka znaczących drobiazgów. Jednym z nich jest jednodziedziczenie (czyli że jedna klasa w PHP może mieć tylko jedną klasę bazową). Od zawsze uważałem to za dużą niewygodę ;) Jak widać, nie tylko ja.
Padła propozycja dołączenia systemu “Cech” (ang. Traits) do PHP (podejrzewam że do wersji 6, ale to tylko moje zgadywanie – w każdym bądź razie są gotowe łatki m.in. do 5.2 i 5.3). Do czego służą Traitsy? W sumie… do obejście problemu jednodziedziczenia, czyli do wprowadzenia wielodziedziczenia.
Trzeba pamiętać, że ten mechanizm został podobno (nie sprawdzałem osobiście) sportowany także do Javy i C#, natomiast nie istnieje jeszcze ofiacjalna wersja dla PHP. Sam “wygląd” kodu, słowa kluczowe etc nie są jeszcze ustalone, ale to tylko szczegóły.
Szczegóły są dostępne w oficjalnym RFC: stefan-marr.de/artikel/rfc-traits-for-php.html. Ja tylko powiem, że da się często obejść niedogodność wynikajacą z braku wielodziedziczenia, ale problem leży właśnie w konieczności obchodzenia braków w języku (tak, wiem, to akurat jedna z typowych wojen wyższości jednych świąt nad drugimi ;) ale to akurat moje zdanie ;) ). Prostszym wyjściem byłoby wprowadzenie po prostu możliwości posiadania kilku klas bazowych, ale w to nie wnikam. Ja ogólnie jestem na tak.
Już od jakiegoś czasu używałem TrueCrypta, do przechowywania dość wrażliwych danych. Niedawno wyszła wersja 5.0, więc trzeba było się przesiąść ;) Jakkolwiek pierwsze odczucie nie było zbyt pozytywne, o tyle później już mniej więcej wróciło do normy.
Domyślnie, TrueCrypt dla linuksa potrafi sformatować nowy wolumen tylko jako FAT32. Można to nieco obejść, samemu formatując wolumen, a w oknie wyboru typu systemu plików, wybrać None (cały proces tworzenia wolumenu wraz ze zrzutami obrazów na jarzebski.pl). Następnie trzeba zamontować stworzony wolumen, ale zaznaczając opcję w oknie dialogowym ‘Do not mount’. Teraz pozostaje sformatować urządzenie loopbackowe (w moim przypdku było to /dev/loop0 – można podejrzeć wynik polecenia mount) na wybrany system plików (ext3 w moim wypadku), odmontować, zamontować ponownie już bindując pod wybrany katalog, i zacząć używać tak stworzonego wolumenu.
Problemy także występują przy próbie użycia kluczy. Jeśli wybrałem dowolny klucz (klucze teraz działają nieco inaczej niż w poprzedniej wersji TrueCrypta – do wersji 4.3 były generowane przez sam program, w tej chwili wskazuje mu się dowolną ilość plików i te pliki są traktowane jako klucze) przy tworzeniu wolumenu, to nie dało się podmontować go – krzyczał że niewłaściwy klucz. Okazało się, że klucze zostały olane, i montować trzeba bez nich ;) Za to po dodaniu kluczy do już stworzonego wolumenu wszystko działa jak powinno.
Od długiego czasu używałem swojego skryptu do montowania zaszyfrowanych wolumenów TrueCrypta. Oczywiście, jako zatwardziały zwolennik konsoli, działa on w trybie tekstowym :) Mam stworzony mały pliczek mapujący konkretną nazwę (alias) na plik zaszyfrowanego wolumenu, klucz użyty do zaszyfrowania go, i katalog pod który należy podmontować wolumen. Tutaj wyszedł problem – po każdym wywołaniu truecrypta z wybranymi opcjami, otwierało mi się okienko GUIowe i kazało klikać :/ Tutaj pomogło dodanie parametru -t do wywołania TrueCrypta.
Pozostał jeszcze jeden kłopot. Teoretycznie, nie można pod linuksem stworzyć “ukrytego wolumenu” – na etapie tworzenia wyskakuje monit “The selected feature is currently not supported on your platform.”. Więc, niech mi ktoś wyjaśni, dlaczego po próbie zamontowania zaszyfrowanego pliku w trybie tekstowym, dostaję jeszcze pytanie o włączenie ochrony ukrytego wolumenu? :/ I nie da się tego wyłączyć (OK, ja nie znalazłem, jeśli komuś się udało to proszę o info).
No dobra, powyżej skłamałem. Obeszłem problem brzydkim hackiem – w swoim skrypcie po prostu pobieram hasło samodzielnie, a następnie przekazuję je do odpowiednio wywołanej instancji TrueCrypta poprzez STDIN. Brzydkie, brudne, i źle działa przy błędnie wpisanym haśle, ale to akurat szczegół. Ważne że chwilowo działa…
To by było na tyle moich bojów z nową wersją programu. Zainteresowanych tematem odsyłam do dwóch artykułów:
- wspomniany wcześniej artykuł na jarzebski.pl
- bardzo ciekawy artykuł na temat starszej wersji TrueCrypta na jakilinux.org
