Vim .netrc i nie musisz pamiętać haseł

Dodałem sobie pliczek ~/.netrc do katalogu domowego. Wrzuciłem tam:

machine serwer.pl login dziubdziub password haslodziubdziuba
machine linux.pl login dziubdziub password nextpasswordofdziubdziub

Zrobiłem jeszcze chmod 0600 ~/.netrc i nie muszę się już użerać z pamiętaniem haseł w vim :] po prostu mnie loguje !

Vim i FTP

Dziś musiałem zabrać się za projekt - zdalnie. Wchodzę do vima. Wklepuję :e ftp://.... i błąd - nie działa... Co jest ? Zacząłem szukać po necie - nic. Zajrzałem w końcu w źródła wtyczki netrw i zobaczyłem, że błąd, który był zwracany this system doesn't support remote directory listing via ftp występuje gdy nie ma w systemie polecenia ftp. No to rozpoczęły się poszukiwania... Po jakimś czasie doszedłem do tego, że odpowiedzialny jest za to pakiet netkit-ftp. Przy okazji zainstalowałem jeszcze net-tools... kurcze - Arch jest dla mnie troszkę zbyt szczegółowy - żeby polecenia ftp nie było :]

Arch Linux - krzaczki w Midnight Commander

No tak :) Ja tutaj się męczę a wystarczy zamiast mc zainstalować mc-utf8 i nie ma krzaczków :]

Smplayer na archlinux

Przed momentem zainstalowałem sobie mplayera i smplayer. Miałem problem z dźwiękiem. Po ustawieniu w "Opcje/Ustawienia" Główne / Główne:

Wideo: xv
Audio: alsa

Wszystko zaczęło ładnie działać. Pomogło również skasowanie katalog ~/.smplayer i odpalenie programu.

Arch Linux on Board

W końcu pozwoliłem dotrzeć do mojej świadomości faktowi, że choć Ubuntu jest wygodne - to jako Linuksowca ten system mnie nie rozwija. Wszystko "jest" i "działa".

Postanowiłem więc przesiąść się wczoraj na Arch Linuksa. Zachęcił mnie fakt, że wydawany był już w Czerwcu. Wydrukowałem sobie nawet instrukcję instalacji.

Kiedy spojrzałem, że podczas instalacji systemu będę musiał edytować pliki konfiguracyjne "by hand" to powiedziałem sobie "Nie wracamy na Ubuntu". Pomimo tego podjąłem wyzwanie.

Dokumentacja jest po prostu świetna. To co skomplikowane okazało się proste - trzeba było tylko spróbować i - zadziałało :] Pliki konfiguracyjne są dobrze opisane i po chwili czytania już wiadomo co w nich zmienić i jaka sekcja jest za co odpowiedzialna. Pacman - działa dokładnie tak jak go zaprojektowano. Jest szybki i działa :) naprawdę nie ma z nim problemów. Co do aktualności paczek - jestem w szoku. Biją na głowę te z Ubuntu.

System był potrzebny do pracy z projektem na LAMP. Zamiast A wybrałem L(ighttpd). Tutaj były już problemy.

1) W php.ini musiałem zmienić konfigurację ponieważ w lighttpd pojawiał się błąd "No input file specified". Rozwiązanie znalazłem w FAQ : [ http://trac.lighttpd.net/trac/wiki/FrequentlyAskedQuestions#IgettheerrorNoinputfilespecifiedwhentryingtousePHP ] (u mnie chodziło o ustawienie cgi.fix_pathinfo i dodanie odpowiedniego katalogu do open_basedir)

2) PHP w ogóle nie mogło połączyć się z bazą danych. Okazało się, że jest to wina tego iż MySQL nie nasłuchuje na porcie TCP ale używa socketów unixowych. Po zakomnetowaniu:

# skip-networking

i zrestartowaniu demona : [ /etc/rc.d/mysqld restart ] MySQL nasłuchiwał już na localhoście i można się było połączyć.

3) Zrobienie aliasu do phpmyadmin :

alias.url = ("/phpmyadmin" => "/srv/www/phpMyAdmin/")

oczywiście odkomentowując moduł aliasów w lighttpd. Niestety działa tylko link http://localhost/phpmyadmin/ czyli z ukośnikiem na końcu.

Z systemu korzysta się systematycznie. Porządna dokumentacja w języku angielskim - to jest to co lubię. Naprawdę o systemie można czytać i czytać. Wszystko konfiguruje się w plikach konfiguracyjnych i działa ! to chyba najważniejsze. Czuję się troszkę jakby to było gentoo, ale takie szybsze :) i mniej "dziwne". Osobiście n systemie zrobiłem sobie tutorial z całego "OpenBox" i jestem szalenie zadowolny ze środowiska, które teraz mam. Jest lekkie, nowoczesne, szybkie, ciekawe :) i proste. Dodatkowo w systemie nie mam "pierdół", które nie są mi potrzebne - ale dokładnie to z czego korzystam. Po prostu miodzio. Oczywiście - cena tego wszystkiego istnieje. Na konfigurację systemu poświęciłem wczorajszy dzień. To nie to co Ubuntu - ale ... coś za coś :)

Gdy zapomnisz hasła root-a

Do tej pory gdy zapominałem hasła root-a próbowałem się chrootować z jakiegoś live-cd na system i zrobić jako root passwd. Problemy pojawiały się gdy trzeba było zadbać o zgodność wersji jądra - aby się chrootować. Jednak ostatnio doceniłem potęge single user mode. Po prostu wchodzi się do GRUBa, edytuje się linijkę zaczynającą się od "kernel" we wpisie w GRUBie (guziczek e) , dopisuje na jej końcu słówko single a następnie bootuje się z niej (guziczek b). Dostajemy bez hasła konsolę z root-a, któremu możemy zmienić hasło :] A potem po wyjściu z powłoki: [CTRL]+[D] na przykład następuje pozostała "część" bootowania i wgrywa się normalnie system - bomba nie ?

Inny pomysł to dodać z jakiegoś live czy innego systemu linijkę do /etc/sudoers, która pozwoli po wykonaniu sudo su z jakiegoś konta dostać konsolę z rootem bez hasła.

Geany - ciekawy edytor

Kolega pokazał mi swojego czasu edytor Geany. Pisze, albo pisał swojego czasu, w nim programy do Pythona. Edytor przypomina troszkę zwykły edytor spod Gnome. Szalenie użyteczną opcją jest moim zdaniem, opcjonalnie włączane, okienko plików w prawym panelu oraz "konsola" w jednej z dolnych zakładek, z której możemy podręcznie korzystać lub zarzyczyć sobie aby w niej były wykonywane skrypty. Program posiada system wtyczek i chyba tyle. Jest prosty, przejrzysty a praca z nim to naprawdę przyjemność. Polecam każdemu kto szuka lekkiego, prostego, schludnego środowiska.

Ruby i Python w jednym żyli domu ...

Kolega, z którym przez ostatni rok miszkałem, zaczął pisać swoje projekty w Pythonie. Mnie natomiast, choć i ja w pythonie coś pisałem, wzięło na Rubego. Miałem więc w różny sposób styczność z obydwoma języka programowania. Chciałem napisać dwa zdania o moich przemyśleniach.

Chciałbym zacząć od tego, że kiedy zabierałem się za którykolwiek z tych języków czułem się dziwnie. Wcześniej programowałem w Java, PHP, C, C++ ... i w każdym z nich mogłem szukać jakiś analogii do poprzedniego. Korzystać ze zdobytej wcześniej wiedzy czy też patrzeć na nowe rozwiązania (przykładowo foreach w PHP) jak na załatanie "dziur" niewygody z poprzednich języków (C, C++). Jednak do Pythona i Rubego - po prostu masakra ! Nic nie mogłem z siebie wykrzesać. Nic !  Dla mnie osobiście był to tak "inny świat", że zabierając się za te języki, wciąż miałem jakby umysł na uwięzi. Spętany nawykami sprzed lat obowiązującymi we wszystkich innych języka programowania, które poznałem starałem się przebrnąć, zrozumieć - nie mogłem. Ratunek był tylko jeden: książką lub dobry kurs do języka idący kroczek po kroczku. Musiałem zacząć się uczyć tych języków tak, jakbym nigdy wcześniej nie programował. Potrzebowałem dobrego kursu lub książki oraz społeczności, która pomogłaby w stawianiu pierwszych kroków.

Przygodę z Pythonem zaczęliśmy z kolegą od rozmówek. Pomysł okazał się jednak nie trafiony. Oczywiście rozmów, kiedy już programuje się jakiś czas w pythonie, są świetne - jeżeli zaś chodzi o dobre poznanie języka - okazały się zbyt zwięzłe i ogólnikowe. Potem trafiłem na kurs Jakuba Swacha, który okazał się strzałem w dziesiątkę. Po prostu - z niego nauczyłem się podstaw pythona. Z różnymi zagadnieniami czy problemami pojawiającymi się w trakcie rozwiązywania zadań do kursu zwracałem się do forum polish python coder group, gdzie zawsze mogłem otrzymać wsparcie i pomoc. Później kolega zakupił już sam "Python Podstawy". Książka okazała się rzeczywiście robieniem wszystkiego "krok po kroku". Jednak nawet jako początkujący znaleźliśmy w niej kilka błędów. Omawiająca szeroki zakres zagdanień, od podstaw, do problemów związanych z dystrybucją komercyjnych programów pisanych w pythonie.

Python jest prosty. Nie łatwy (choć może też), ale prosty. Jeżeli w Pythonie coś robi się "tak" to tak się to robi i nie powinno stosować się żadnego innego sposobu aby to wykonać. Programy wyglądają przejrzyście, są logiczne i zrozumiałem. Osobiście przeszkadza mi tylko fakt iż ogólnikowo nie wszystko jest obiektowe. Pojawiające się tu i ówdzie funkcje czasem utrudniają - bo wydają się "nie pasować". Często, wiele funkcji, które sprawdzają czegoś długość, ilość elementów itd ... mogłyby być po prostu metodami obiektu - jednak tak nie jest i często zapędzając się w "obiktówkę"... zastanawiamy się "czemu nie działa ?" a dlatego, że takiej metody nie ma - trzeba użyć funkcji.

Jeżeli o Rubego chodzi na start kupiłem Ruby On Rails. Próba przebranięcia przez tą książkę bez znajomości języka to była porażka. Na urodziny od rodziców dostałem "Ruby. Tao programowania w 400 przykładach". Jestem osobą, kra czyta wstępy do książek. Przeczytałem i tutaj. Na starcie dowiedziałem się, że "książka ta nie nadaje się dla osób, które chciałyby nauczyć się języka Ruby" - bomba ... a po to ją kupiłem. Spróbuję ! Przecież jestem zdolny ... Po siedmiu rozdziałach się poddałem: "Co to za syf ? Ile tu składni ?! Za dużo ! Po co tyle możliwości. O co chodzi !?" ... Zbawieniem okazała się dla mnie książeczka "Ruby. Wprowadzenie". Tutaj autor bardzo powoli zaczął omawiać język - książka okazała się dla mnie idealna... Naprawdę solidnie pozwoliła mi pojąć nie tylko sam język ale również jego "filozofię" i dostrzec w tym całym "bałaganie" pewien sens. Dodatkowo moje wątpliwości szybko rozwiewała społeczność na forum RubyOnRails.pl.

Ruby nie jest językiem prostym. Jest jak system operacyjny. Możesz administrować systemem od 10 lat, spotkać kolegę po fachu i dowiedzieć się, że wykonuje te same czynności w zupełnie inny sposób. Z Rubym jest jeszcze ciekawiej. Posiada on nazwałbym to bardzo rozbudowaną składnię. Twórcy języka jakby dopieścili każdy jego najdrobniejszy element. Nie wystarczyło im że stworzyli już coś co działa, ale z pietyzmem starali się zrobić tego tyle wariantów... na tyle sposobów - ilu programistów na świecie tak, aby każdy znalazł sposób na wykonania swojego zadania tak jak lubi. Nie nazwałbym Rubego językiem programowania - bo języki programowania to język stworzony po to aby maszyna nas rozumiała. Ruby został stworzony nie dla maszyny, ale dla człowieka, aby mógł ekspresywnie, twórczo, kreatywnie oraz precyzyjnie wyrażać swoje myśli i intencje pisząc kod programu. Czytając kod Rubego możesz spojrzeć na niego i zobaczyć coś więcej poza samymi instrukacji - możesz zobaczyć styl, osobę, która pisała ten kod oraz Jej finzję w wyrażaniu myśli.

Wiele osób uważa, że duża ilość możliwości jaką daje Ruby powoduje problemy ze zrozumieniem kodu. Teoretycznie możemy czytać właśnie kod, który czyta plik kompletnie go nie rozumiejąc, bo przez całe życie robiliśmy to inaczej - i nie znamy "tej metody". Jednak moim zdaniem Ruby jest tak skonstruowany, że dzięki samym nazwom metod oraz operatorów - nawet takich, które widzimy pierwszy raz na oczy - będziemy w stanie zrozumieć co wykonuje dany program.

Oczywiście wiele zależy również do programisty. Jakiego zapisu użyje w tej sytuacji, jak ponazywa zmienne, czy to co zrobi będzie miało sens. Święte wojny o to czy klasy w Ruby powinny byc otwarte - czy nie przypominają mi dyskusje związane z bezsensownym przeładowywaniem opratorów różnych obiektów w C++. Moje zdanie jest takie: Dobry programista będzie umiał wykorzystać nawet potencjalnie "niebezpieczne" mechnizmy na rzecz czytelności i zrozumiałości kodu - nie mądry, nawet ograniczony składnią języka może natłóc kod z którego nic nie wynika. Tak więc nie winiłbym języka za to iż przy otwrtych klasach w Ruby można "nieźle nagmatwać", ale raczej składałby odpowiedzialność na barki programistów. Dynamit też był wynaleziony by służyć dobru - tylko od ludzi zależy czemu tak naprawdę będzie służył, sam w sobie - nie jest zły.

Pylons - moje przemyślenia

Całkiem niedawno postanowiłem poznać ciut bliżej pylons - pewien framework Pythona. Czytałem w różnych opisach (dat nie pamiętam), że pylons nie ma dokumentacji... Rzeczywiście - pewnych rzeczy w dokumentacji oficjalnej na witrynie http://wiki.pylonshq.com/display/pylonsdocs/Home się nie doszukałem, jednak nie są to jedyne źródła informacji !

Po pierwsze pogłoski iż jakoby pylons miał kiepską dokumentacje są nie trafione. Ten framework tak silnie korzysta z zewnętrznych, tworzonych w ramach osobnych projektów rozwiązań, że gdyby przestały istnieć framework przestałby funkcjonować przynajmniej na jakiś czas. Rozwiązania te, takie jak : SQLAlchemy czy Mako - mają własną dokumentację. Obszerną, dokładną, przerzystą dokumentację. Nie ma co się dziwić ... skoro to zewnętrzne projekty to czemu miałoby być inaczej ?

Dokumentacja istnieje, jest więc tylko troszkę rozproszona, ponieważ pylons korzystając z konkretych rozwiązań pokazuje tylko coś  "na start" i zaprasza do zapoznania się z dokumentacją np. SQLAlchemy w celu pogłębienia swojej wiedzy. Moim zdaniem to rozwiązanie jest rozsądne i słuszne - po co robić kopiuj wklej opracowania jakiegoś projektu z którego korzystasz jeżeli możesz po prostu do niego odesłać.

Zastanawia mnie tylko jedna rzecz. Django i Pylons, z nieznanych mi powodów, ale zapewne jakieś są, idą łeb w łeb ... gdzie jednak Django ma napisane wszystko "od siebie" a Pylons sam napisał może 2% tego co djangowcy bo przecież 98% to zewnętrzne rozwiązania z naklejką "ready to go !". Logicznie myśląc skoro pylons i tak "wykorzystuje" cudzą pracę to mogłoby rozwijać się znacznie szybciej niż django, w którym wszystko jest implementowane po djanogowemu na potrzeby frameworka.

I jeszcze na koniec - to nie prawda, że Pylons ma słabą dokumentację. Dokumentacja jest wystarczająca - choć oczywiście mogłaby być lepsza. Dla zapaleńców polecę jeszcze tylko polski tutorial do Pylons: http://python.rk.edu.pl/w/p/pylonsindex/

I kto mówił, że Pylons ma słabą dokumentacje ?

Polski literki w napisach mplayer

Nie pamiętam już który raz z kolei musiałem uporać się z polskim znaczkami w filmach oglądanych pod Mplayerem. Opis, z którego zawsze korzystam znajduje się na stronie http://mplayer.typeria.net/ w rozdziale "Polskie znaki". Zazwyczaj plik z napisami kodowany jest właśnie w cp1250 - jednak możemy to łatwo zmienić. Gdybyśmy chcieli otrzymać napisy w utf8 wystarczy, że wklepiemy do konsoli:

iconv -f cp1250 -t utf8 plik.txt > plik-utf8.txt

I problem mamy z głowy. Oczywiście trzeba czasem strzelać z tym jakie kodowanie plik miał na początku - jednak gdy się już trafi możemy sobie konwertować do woli.