Dlaczego NIE Linuks

Wciąż trwająca wojna Windows(owcy) vs Linuks(owycy) to tylko fala na morzu... a co siedzi w głębi ?

Chęci... No właśnie... na czym Ci zależy. Wielu użytkowników Windows stwierdzają "działa" i to im wystarcza. W gruncie rzeczy o to tylko chodzi i żadne argumenty w stylu "Linuks ma to to to i tamto, lepiej zarządza pamięcią, siecią, jest bezpieczniejszy ..." (i ta cała lista plusów) nic nie zmienią jeżeli gość w życiu nie miał problemu z komputerem, albo nie był on dotkliwy to po co mu Linuks, który ... nie działa ? No tak ! Bo ile razy wejdzie się na forum linuksowe, widać tylko wątki "nie działa mi", "jak zrobić żeby", "dlaczego ...", "wyskakuje mi błąd", "error", "zawiesz mi się przy..." i pierwsza myśl, która się nasuwa to "To nie działa !"... Po co komu system, w którym może robić "cuda", które wcale mu nie są potrzebne...
Użytkownicy Linuksa to pewni perfekcjoniści, puryści, ideliści, którzy lubią mieć wszystko cacy, bomba i po swojemu... Ale Polacy to społeczeństwo raczej ... leniwe :P więc po co się "męczyć" skoro DZIAŁA w Windows... Dla grafika komputerowego, dla którego Corel i Photoshop to chleb powszedni tłumaczenie się GIMPem czy WINEem to porażka... Bo przecież to działanie jest takie "wymuszone" i nie stabilne, a tutaj po prostu wygoda działania i przyzwyczajenia. W gruncie rzeczy wychowaliśmy się w większości na Windows, na programach, które w nim są i często poszukiwanie tak wygodnych aplikacji jak PSPad, eSkiMoS, Foobar czy innych oznacza przesiadkę na mniej wygodną aplikację, korzystanie z kilku z nich, albo pogodzenie się z okrojoną funkcjonalnością... no i nie pomoże, że boli.

Myślę, że na Linuksa trzeba chcieć się przesiąść. W gruncie rzeczy nie ma wielu logicznych argumentów, dla których nie należałoby używać Windows kiedy jest się szarym użytkownikiem. Windows ma wiele wygodnych mechanizmów, na których człowiek się wychował, przyzwyczajenie staje się jego drugą naturą i zmiana powoduje obniżenie wydajności jego pracy. To na czym mu zależy działa, antywirus jak coś nie gra zgłosi co trzeba, firewall popyta o aplikacje i czuje się bezpiecznie... więc po co mu coś więcej ?

Linuks nie jest dla wszystkich i dla wielu użytkowników Windows to znaczenie leprze rozwiązanie, czasem z przyzwyczajenia, czasem z wygody, innym razem z powodu dostępnego oprogramowania... I denerwujące "aktulizacje" Windows... są denerwujące tylko dlatego, że zmusić do nich to jedyna metoda Microsoftu aby zadbać o bezpieczeństwo systemu LENIWYCH użytkowników, gdzie każdy świadomy użytkownik Linuks zadba o to sam... :) Więc nie narzekajmy tylko głowa do góry i czyńmy nasze aplikacje dla Linuksa jeszcze bardziej użytecznymi :) aby był to system, na który na prawdę warto się przesiąść.

Kilka słów o instalowaniu ze źródeł

Czasami naprawdę trzeba zainstalować coś ze źródeł. Po prostu nie ma naszego kochanego programu w żadnym repozytorium i nie pozostaje nam nic innego. Jest kilka rzeczy, które mogą nam pomóc, jeżeli wcześniej zwrócimy na nie uwagę.

Źródła rozpakowuje się zazwyczaj:

tar -xf nasz-program-10.tar.gz

a czasami jeżeli spakowane są bz2

bunzip2 nasz-program.tar.gz.bz2
tar -xf nasz-program-10.tar.gz

Po wypakowaniu źródeł zazwyczaj powstaje katalog nasz-program. Po wejściu do niego koniecznie przeczytaj pliki INSTALL i README. To bardzo dużo ułatwia. Często programy używają innych bibliotek, które ktoś już opracował i na ich podstawie budują swoją funkcjonalność. Zamiast denerwować się, że coś się nie kompiluje sprawdź najpierw te dwa pliki (jak są inne wyglądające podejrzanie, których nazwy napisane są wielkimi literami też je sprawdź). Użyteczna przydaje się komenda:

vim INSTALL README -p

która otwiera nam nasze pliki w zakładkach, po których możemy poruszać się [gt] (jak go tab). Przeczesz stronę internetową, FAQ, manual, dokumentację (część z instalacją), aby zanim wykonasz pierwszy krok być pewnym, że w systemie jest już wszystko co jest niezbędne do działania tej aplikacji. Warto jest jeszcze zweryfikować czego możemy od programu oczekiwać, z jakimi opcjami kompiluje się domyślnie, jakich brakuje. Po lekturze ./configure --help | less lektura tego help-a jest niezbędna aby dopasować funkcjonalnośc programu (co ma obsługiwać co nie, jakich bibliotek się spodziewać jakich nie, czy ma korzystać z ALSA czy z JACKa itd...) Oczywiście możesz próbować robić podchody w stylu:

updateos -i brakująca-biblioteka

a jak nie znajdzie:

updateos -f brakująca-biblioteka

Czasami jednak trzeba wpisać nazwę biblioteki w googlach, z dodatkiem home page,albo bez i ściągnąć ją i kompilować ze źródeł. Po katalogu ze źródłami warto się jeszcze rozejrzeć po plikach konfiguracyjnych aplikacji, themah i innych gadżetach (pliki konfiguracyjne, themy i skróty klawiszowe znalazłem na przykład w źródłach MOCa). Później zaczynamy ./configure (będąc w katalogu ze źródłami). Programik sprawdza sobie biblioteki dostępne w systemie i patrzy czy są te przez niego wymagane. Jeżeli instalowałeś jakieś biblioteki do systemu (potrzebne do aplikacji) to aby system je "zobaczył", czy łyknął warto dla pewności po ich instalacji, a przed kompilacją źródeł programu wydać polecenie ldconfig. Configure może czegoś nie znaleść. niektóre biblioteki jeżeli nie zostaną znalezione nie spowodują błędu. Program je po prostu pominie, kosztem mniejszej funkcjonalności programu. Aby dowiedzieć się co dokładnie w trawie piszczy możemy wydać polecenie ./configure --help | less i z bliska przyjrzeć się co możemy sobie w programie "włączyć" lub wyłączyć. Często bywa tak że configure albo make generuje jakieś błędy przy jakiejś nazwie. Po przejrzeniu
./configure --help | less widzimy gdzieś tą nazwę a obok nie coś w stylu --disable-to_cos_co_nas_nie_lubi albo --to_cos_co_nas_nie_lubi=no albo --to_cos_...=disable. Wydanie polecenia ./configure --disable-cos. Spowoduje, że do programu nie zostanie włączona obsługa tego czegoś, nie zostanie to wogóle wzięte pod uwagę, program skompiluje się z mniejszą funkcjonalnością, ale w 90% przypadków w ogóle tego nie odczujemy :) bo programy pisane są tak, że jedną rzecz robią na 10 różnych sposobów i jak nie jednym to drugim. Często aby program skompilować pod nasze potrzeby albo pod nasz system piszemy spory tasiemiec: ./configure --disbale-options --enable-gtk --disable-qt [...] --prefix=/usr. No właśnie opcja prefix powoduje, że przed każdym katalogiem do którego będzie kopiowany plik (przed jego nazwą) dopisywane jest /usr. Co to znaczy ? Domyślnie prefix ustawiony jest na /usr/local (chyba, że w programie albo INSTALL albo README albo gdzie indziej jest napisane inaczej). I jak będziesz miał binarki tego progamu to znajdą się one w /usr/local/bin, zasoby w /usr/local/share. Mi to nawet pasuje i wszystko co nie pochodzi z systemu ładuję właśnie tam, wiem przynajmniej gdzie szukać plików w /usr/local. Jednak możesz chcieć władować to do /usr (bin, share itd...). Wtedy dajesz --prefix=/usr i wsio. Po ./configure kiedy system wie co jest i czego nie ma a dzięki temu wie jak skompilowac program tak aby się skompilował robimy polecenie make. To jest kompilacja źródeł. Czasami dopiero tutaj okazuje się, że biblioteki są w złej wersji albo coś nie działa. Możemy znowu instalować biblioteki, aktualizować je albo brutalnie wycinać przez przełączniki przy ./configure. Kiedy make już przejdzie mamy dwie opcje. Albo pokopiować pliki, które właśnie się utworzyły do systemu na łyso przez make install, albo zrobić paczkę. Make install wymaga uprawnień dostępu do katalogów systemowych a więc tu, należy wydać polecenie su i dopiero make install. Pokopiuje on pliki do katalogów i wsio. Wszystkie poprzednie czynności należy wykonywać z uprawnieniami zwykłego użytkownika ponieważ gdyby w kodzie źródłowym był jakiś wirus zadziała on z bardzo ograniczonymi uprawnieniami a nie uprawnieniami superużytkownika. make install ma pewną wadę - otóż, nie działa On jak paczka. Dzisiaj Linuxy mają swój system paczek. Make install nic nikomu nie mówi, gdzie i czy coś skopiowało. Tylko ono wie, że coś się działo. Jedynym sposobem aby potem odinstalować taki program jest zachować sobie katalog, w którym wszystko kompilujemy i w momencie chęci odinstalowania wejść do niego i wydać polecenie Jednak jeżeli katalog ten skasujemy czeka nas ponowna kompilacja z poprzednio ustawionymi flagami i po kolejnym zainstlowaniu do czasu kiedy jeszcze istnieją źródła wydanie natychmiast po tym komendy make uninstall. Jednak istnieje narzędzie checkinstall które pozwala robić paczki. W Kasi paczuszkę slackową (czyli nawet dość pasującą do naszych potrzeb) możemy zrobić wykonując zamiast make install checkinstall -S. Jeżeli nie chcemy być pytani o drobiazgi, i robimy paczkę tylko na chwilkę, aby ją zainstalować możemy kazać programowi stworzyć podstawową dokumentację i odpowiedzieć na pytania twierdząco poprzez checkinstall -S --nodoc -y. Po tym zabiegu powstanie ładna paczuszka tgz, która po pkg -i nasz-program.tgz zarejestruje się w systemie i pozwoli ładnie usunąć przez pkg -r nasz-program, a my źródła kompilacji będziemy mogli wyrzucić do kosza. Ma to jeszcze jeden plus. Możemy za w czasu podejrzeć paczuszkę i sprawdzić gdzie po kopiują się nam pliki i w razie czego prze konfigurować i skompilować ponownie program z innym, bardziej odpowiadającym nam prefiksem. Jeżeli dużo mieszamy ze źródłami, przerwaliśmy make-a bo zapomnieliśmy o dodanie do configure jakiś drobiazgów i przy tym zaczynają się dziać jakieś niespodziewane rzeczy, błędy możemy wyczyścić wszystko co do tej pory pozostawiło po kompilacji swoje pozostałości przez wydanie polecenie make clean co spowoduje, że zaczniemy kompilację od zera.

Jeżeli chcesz wyjść do sklepu i mieć po powrocie działający programik w systemie możesz łączyć polecenia w sprytne łańcuszki. na przykład:
./configure && make && checkinstall -S --nodoc -y && pkg -i nasza-paczka.tgz

Wracasz do domu, terminal zaśmiecony :) ale programik działa :P (o ile po drodze nie wyskoczył żaden błąd).

Powodzenia i miłego kompilowania programów !

Gdzie pójdzie po make install ?

Często chcielibyśmy mieć pewność gdzie umieści pliki make install. Ostatnio nieciekawy numer wywinęło mi qingy :| Jeżeli jesteś na etapie kompilowania źródeł to w miejscu make install możesz wydać polecenie checkinstall -S --nodoc -y:

-S - paczka slackware (czyli coś jak Kasia)
--nodoc - bez dokumentacji (tworzy domyślną dokumentację, w tym przypadku w ogóle nie potrzebne)
-y - Nie męczy Cię zbędnymi pytaniami i na wszystkie odpowiada yes

Powstanie paczuszka tgz, której zawartość możemy obejrzeć sobie dość dokładnie w mc lub innym programem pozwalającym na podejrzenie tgz-ów. Jeżeli chcemy sprawdzić gdzie ulokował się już zainstalowany program możemy podejrzeć: /var/log/packages/ --- program ---

Gmail notifier

Trafiłem właśnie na bardzo sympatycznego gmail notifier-a:

http://gmail-notify.sourceforge.net/


Ściągnąłem źródełka. Wypakowałem wszystkie pliki do /usr/local/gmail. Dodałem do mojego ~/.zshrc:

export PATH=$PATH:/usr/local/gmail

Wykonałem . ~/.zshrc później notifier.py i ... okazało się , że brakuje pygtk. No to szybciutko:

su
updateos -i pygtk
[CTRL]+[D]
[ALT]+[F2]
/usr/local/gmail/notifier.py

Wypełnieł username, password, Save user name and password (check) i mogłem się już cieszyć pięknym gmail notifierem w mojej nowej Kasi :)

XFCE może zapamiętywać podczas zamykania systemu sesję, czyli co jest odpalone co nie i uruchamiać to ponownie lub wchodząc w ustawienia autormatyczne uruchamianie aplikcji możesz dodać Gmail notifier-a podając: /usr/local/gmail/notifier.py

Kary za reklamy

Kiedyś znajomy opowiedział mi o zamiarze kupna breloczka, który umie wyłączyć kilkaset tysięcy modeli telewizorów. Wchodzicie do MediaMarkt, stajecie przy ścianie zapełnionej gadającymi telewizorami, wyciągacie breloczek, naciskacie guziczek i ... cisza.

W perspektywie ciszy reklamowej w Media Markt spojrzałem na dzisiejsze reklamy, które "witają mnie" na strona portali internetowych. Reklama, często zajmująca 50-100% mojego ekranu i nie działający guziczek, który ją wyłącza. Ktoś powinien za to zapłacić ! Za co ? Za czas, który poświęcam, aby dotrzeć do treści, które są dla mnie w danym momencie ważniejsze aniżeli, reklama, której TEORETYCZNIE mam PRAWO nie oglądać. Ktoś narusza nie tylko moją wolność i zabiera mi mój bezcenny czas, ale dodatkowo PŁACĘ ZA TO, że ktoś mi COŚ reklamuję. Jak to płacę ? A no tak ! Kilka kilo-bajtów tekstu i kilkaset kilo-bajtów reklamy na pół strony ! Ciekaw jestem ile transferu HTTP to reklamy. Jestem prawie pewien że ponad 50%, a kto za ten transfer płaci ? Ja ! Czyj czas zżera ? Mój ! Ktoś powinien zrobić z tym porządek.

Zatruwanie switcha

Dziś razem z jednych z doktorów z uczelni na której studiuję postanowiliśmy zatruć switcha. Był to jakiś 3com, podobno miał 8MB pamięcie... Postawiliśmy dwa laptopy, na jednym na Windowsie postawiliśmy WireShark-a, na drugim zapuściliśmy Knoppix STD.

Troszkę się namęczyłem z napisaniem skryptu, który by pozwolił tego switcha zapchać. Początkowo pomysł był taki, że ponieważ do switcha podłączone były tylko dwa komputery, słać jednym ramki na jakiś lewy MAC, drugim zaś czekać, aż zacznie wyłapywać te ramki, przy czym MAC źródłowy był preparowany.

Wstępnie napisałem w bash-u prosty skrypt generujący MACi - nic trudnego... Problemy zaczęły się gdy trzeba było preparować MACi źrółowe. Chłopacy z Matrixa zapodali wersję z ifconfigiem jednak kilka dni później trafiłem na Knoppix STD z arpingiem :)

Już na samym początku okazało się jednak, że jak się wyśle na lewy MAC to on go nie ma w pamięci i wysyła wszędzie... no to 3 komputer :| by był potrzebny, ale nie. Podszyliśmy się pod jakiś dobrze znany nam MAC, puściliśmy z niego arpinga i router to łyknął ;) Mogliśmy więc słać na MAC, którego w sieci nie ma, a switch go zna i wie co z nim robić.

Okazało się, że wersja bash-a na Knoppix STD jest tak stara, że skrypt trzeba było przepisać :| (szkoda, że nie rozwijają już Knoppix STD - świetna dystrybucja ! A byłaby jeszcze lepsza, gdyby ktoś ją odświerzył) Po przepisaniu skryptu - udało się, zapodaliśmy skrypt ... i czekamy, komunikaty się pojawiają, a my czekamy.

Doszliśmy do wniosku, że tak średnio to idzie 1 na sekundę więc przy 8MB switcha przyjdzie nam czekać 1200 godzin (szacunkowo i to z dużym błędem)... Zwiększenie ilości wątków do 400 pozwoliłoby nam liczyć na 4 godziny. Dopisaliśmy pętlę while odpalającą skrypt 400 razy i aby przyśpieszyć pracę wysłaliśmy wszystko do /dev/null. A co ! Niech sobie działa ! System trochę przysiadł i zaczął działać "w zwolnionym tempie" długo zastanawiając się nad każdym ruchem myszki jednak efekt był widoczny już po 15 minutach rozmowy - WireShark został zasypany mnóstwem pakietów :)

To było piękne :)

Rozmyślania o MVC

Od jakiegoś już czasu ludzie męczą mnie o to abym zaczął programować używając MVC. Podobno łatwiej. Ale ja w tym, żadnego sensu nie wiedziałem ... No bo co to za sens ? pisać tylko:

<title> <?=$tytul?> </title>

czy

<title>${tytul}</title>

Jakiś piekielnie skomplikowany mechanizm, który dba o przekazywanie zmiennych do odpowiednich plików, dodatkowo o to, aby to wszystko pozamieniać, generując tylko narzuty czasowe ... więc o co chodzi ?

Ale może najpierw co to jest MVC. Za wikipedią:

MVC (ang. Model-View-Controller - Model-Widok-Sterownik) to wzorzec projektowy w informatyce, którego głównym założeniem jest wyodrębnienie trzech podstawowych komponentów aplikacji:

• modelu danych,
• interfejsu użytkownika,
• logiki sterowania
  

Czyli tak dla ludzi. Chodzi o to, aby jak najbardziej oddzielić logikę prezentacji PHP od logiki kontrolera HTML (tak w dużym uproszczeniu). No tak miało być dla ludzi. Otóż chodzi o to aby oddzielić to co skrypt robi od tego jak skrypt to pokazuje. Ja sam sobie mówiłem: "Ale co to za problem ... przecież <php? include ('licznik.php'); ?> czy <php? $licznik->show(); ?> nikomu jeszcze nie zaszkodziło !".

Jednak nie o takie podejście w całym tym przedsięwzięciu chodzi. Aby mówić o MVC trzeba po prostu dojrzeć do niego - inaczej to będzie wciskanie ci "dobrego" rozwiązania, do którego w cale nie jesteś przekonany i jest Ci wciskane na siłę ! :)

Moim ideałem programowania jest pewien ideał nabyty z C++. Jeżeli piszę klasę, to chcę ją napisać tak, aby ktoś sobie wziął pliczek z moją klasą skopiował do swojego katalogu, includował i już mógł jej używać - jak swojej. Tak też starałem się robić w PHP - i tu pojawia się problem - oprócz PHP jest przecież ... HTML :|. No właśnie :| W C++ sprawa jest prosta, możemy nie martwić się o "prezentację danych" (pod konsolą) robimy cout. A jeszcze lepiej zwracamy po prostu wynik nic nie wyświetlając. Jednak w PHP Dochodzi HTML. Opowiem wam historyjkę z życia wziętą.

Musiałem kiedyś przerobić portal oparty o XOOPSa. Chodziło o zmianę layoutu. Kiedy zagłębiłem się w kod okazało się, że jego fragmentu porozrzucane są po najróżniejszych zakamarkach tabel baz danych ... Uwierzcie ! grzebanie i dochodzenie w jakim rekordzie znajduje się ten konkretny fragment MENU doprowadzało mnie do szału ! A wyobraźcie sobie, że poza tym kod HTML mógłby być porozrzucany po najróżniejszych metodach używanych tam klas... po prostu masakra ! W takiej sytuacji prosty plik HTML z jasno powstawianymi elementami pochodzącymi z PHP byłby idealny zamiast grzebanie się po metodach klas i bazie danych - udręka !

O wiele łatwiej jest stworzyć własny formularz do bazy danych mając:

<form action="${action}" method="${method}">
<fieldset>
<legend>${tytul}</legend>
<label>${login}: <input name="${login}" type="text"></label>
</fieldset>
</form>

niż jakąś czarną skrzynkę pod tytyłem:

$login->pokaz_formularz();


Niby też ładnie, ale dla osoby, która chciałaby nasz formularz zupełnie przerobić (bo nie pasuje Jej do jego layout) kompletnie nie pasuje. Wtedy znacznie łatwiej jest powstawiać sobie kilka pól (nasze zmienne ${nazwa}) w nowe miejsca, do przez siebie przygotowanego pliku niż szukać po klasach i bazie danych - gdzie on mógł to wcisnąć ?

A więc klasa musi się już tylko zająć przetworzeniem danych i wrzuceniem ich w odpowiedni szablon. Może to wyglądać na przykład tak:

$zmienne = array {
'tytul' => 'Moje MVC',
'nazwa' => 'firma',
}

$controller->parse('formularz.html', $zmienne);

No i tu pojawia się kolejny element. Kontroler - czyli element, który zajmie się włożeniem odpowiednio przez nas wcześniej napisanych zmiennych w odpowiedni szablon HTML.

Z praktycznego punktu widzenia wygląda to tak:

• HTML - zajmuje się formą w jakiej prezentowane są dane.
• PHP - naprawdę zajmuje się tylko obróbką danych.
• Jakiś parser - czyli klasa (albo funkcja, czy co tam sobie chcecie) zajmuje się tym, żeby włożyć suche zmienne PHP w odpowiednie miejsca w pliku HTML.

Możemy spróbować sami napisać parser, albo spróbować używać frameworku.

No właśnie i tu pojawia się kolejna kwestia. Framework. O co chodzi ? Myślę, że wiele osób pisząc o MVC zaczyna pisać o jakimś konkretnym frameworku i przez to wprowadza tylko bałagan, gdyż framework to pojęcie o wiele szerszym znaczeniu.

Framework to tak po ludzki napisany w jakimś języku mechanizm, zbiór biblitotek, którego używa się jak języka programowania... czyli buduje się w opraciu o nie swój kod. To znaczy tak jakbyś napisał swój własny język programowania w PHP i go opublikował. Na początku wydawało mi się to głupotą do kwadratu ! Po co mi język napisany w PHP do obsługi PHP. Żadnych więcej możliwości nie daje, a tylko powoduje, że wszystko działa wolniej ... głupie. A jednak nie zawsze, tylko trzeba wiedzieć kiedy z niego korzystać, a kiedy nie. A powodów może być kilka.

Frameworki pisane są do różnych języków programowania np. do JavaScript i jedną z korzyści z nich wynikających opiszę właśnie na tym przykładzie. Dwa dobrze znane mi frameworki w JavaScript to jquery i prototype. Ładuje się do przeglądarki pliczek w poprzez na przykład i ... pisząc w JavaScript od tej pory ma się dwie możliwości. Albo używamy JavaScript, albo używamy framework-a...

Przykładowy kod, który powoduje zniknięcie elementu na stronie (będzie to element

) w jquery wygląda następująco.

$('div.cos').hide('slow');

i tyle ! Proste nie ? Teraz zastanów się. Gdybyś nie używał jquery jak chciałbyś to zrobił ? Ja nie wiem... Jednak wiem jedno - znając burzliwe dzieje przeglądarek internetowych pisząc w JavaScript wcześniej czy później natknąłbym się na moment, w którym coś pod konkretną przeglądarką przestałoby działać ... :( Byłbym wtedy zmuszony do próby zaprogramowania tego samego na dwa, a może nawet trzy czy cztery (a może nawet więcej) sposobów, tylko po to aby obsłużyły to wszystkie przeglądarki... Powiedzmy, że się udało - napisałem skrypt... przychodzi rok 2008 i na rynku pojawia się kIEpska 8 nie zgodna z niczym ... i mój skrypt nie działa :( i co znowu siadam do kodu i rzeźbię ....

I tu pojawia się nasz framework. Działa jak język programowania, czyli pozwala nam pisać program... pod spodem jednak siedzą rzeczywiste funkcje JavaScript, które wszystko robią za nas :) Jaki jest z tego plus - nie my, ale twórcy frameworka zadręczają się problemem "nie działa na nowej przeglądarce :(" My piszemy nasz kod RAZ, wrzucamy na stronę, a o zgodność i całą resztę martwi sie framework :) i działa. Takie rozwiązanie (w przypadku JavaScript) ma wiele więcej plusów. Wymienię kilka:

• Nie obchodzi nas jak obsługiwana jest wersja JS w przeglądarce.
• Nie martwimy się gdy wychodzi nowy standard JS - o to martwią się twórcy frameworka.
• Nie martwimy się gdy wychodzi nowa przeglądarka. Czekamy aż wyjdzie nowa wersja frameworka, podmieniamy jeden pliczek z nim zawarty i wszystko działa :)
  

We frameworkach chętnie pisane są też najróżniejsze dodatki i pluginy, do odsłuchiwania muzki mp3, tworzenia zakładek, generowania grafiki i wiele innych.

Dlatego wybierając framework należy zwrócić uwagę na kilka drobiazgów:

• Jak często aktualizowany jest framework i czy w ogóle jest jeszcze rozwijany.
• Jak wygląda jego dokumentacja i czy jest często wykorzystywany.
  

Framework z kiepską, albo żadną dokumentacją może sprawić nam więcej problemu aniżeli pomóc. Natomiast jeżeli framework kiepsko się rozwija to w przypadku znalezienia w nim błędu lub nowej przeglądarki jesteśmy zmuszeni na samodzielne grzebanie w kodzie, albo długie czekanie ... ew. męczenie twórców mailami.

Dodatkowo w JS frameworki mogą oferować obsługę fajnych efektów, animacji, składnię dużo przejrzystrzą i prostą aniżeli samo JS (dużo łatwiej czytać kod), kod może być w nich krótszy i bardziej zwięzły. Często framework posiada dodatkowe możliwości i dostępne w sobie użyteczne algorymty, których na próżno szukać w suchym JavaScript. Nie musimy wtedy pisać własnych funkcji. Przykładowo w jquery obsługa AJAXa jest bajecznie prosta a kod obsługujący go jest bajecznie prosty, przejrzysty i pisze się całkiem przyjemnie :) Nie martwię się o to, że AJAX w IE obsługiwany jest totalnie inaczej niż w FireFox czy w Operze, nie muszę też zagłębiać się też wszczegóły techniczne i sposób działania. Piszę sobie:

$('div.tresc').load('rozdzial.php?rozdzial=1');

a w uzyskanym dzięki frameworkowi czasie piję sobie kakao ;)

Istnieją też frameworki do PHP. Starają się one eliminować niedogodności języka oraz platform, na których jest uruchamiany. Dostarczają także użytecznych mechanizmów, które często są wykorzystywane w programowaniu, a które nie jeden z nas musiałby opracowywać na własną rękę:

• Często nie wiemy na jakim PHP będziemy pracować, albo przychodzi nam zmienić serwer. Wszystko było napisane w PHP 5, funkcje czystego DOMu działały świetnie a tu klops :( usługodawca zapodaje na serwer PHP4 a my ... kwiczymy. Może przyjść nam tutaj z pomocą framework ! Jeżeli jest tak zaprogramowany piszemy mu wtedy "php5" i kod napisany we frameworku działa używając funkcji z php5. Zmienia się sytuacja musi działać na php4 podajemy frameworkowi "php4" i działa na php4. Zmieniamy tylko jedną literkę ! zamiast kilkuset linijek aplikacji.
• Frameworki, także te w PHP mogą wspomagać programowanie od strony baz danych czy AJAX-a (np. symfony wspiera AJAX). Przykładowo baza danych - zmieniamy silnik z MySQL na Postgresa ... Framework może oferować nam swoją własną klasę dostępu do bazy danych, która działa tak samo bez względu na to z jakiego mechanizmu bazodanowego korzystamy.
  
• Jeżeli pojawi się PHP 6 ... to my nadal pracujemy w naszym frameworku a o poprawność męczą się ludzie tworzący go.
• Często framework wspomaga programowanie w MVC udostępniając nam klasy, które w sprytny i zgrabny sposób potrafią przetransportować informacje z klasy do odpowiedniego szablonu w PHP i powstawiać wszystko na swoje miejsce.

Ma to też swoje minusy. Największy to ten, że aby programować czasami musimy uczyć się praktycznie "nowego języka programowania", czyli frameworka, który nie oferuje specjalnie nic ponad to co PHP generując tylko narzuty czasowe (czyli wszystko to wykonuje się wolniej niż napisane w suchym PHP). Często więc przydaje się napisanie własnej klasy wkładające dane z PHP do szablonu HTML czy obsługującej w sposób transparentny bazę danych tak, aby nie ważne było czy to Postrges czy MySQL.

Wszystko zależy od stopnia skomplikowania naszego projektu. Jeżeli tworzymy prostą stronę internetową prawdopodobnie framework będzie tylko zawracaniem głowy i może nam tylko utrudnić to co jest proste. Jeżeli jednak decydujemy się na bardziej skomplikowany projekt, używanie MVC pozowli wywalić z kodu klas zbędnych HTML (który często zawala miejsce) co sprawi, że kod w metodach stanie się bardziej jasny, przejrzysty i czysty. Poskutkuje to łatwiejszym zrozumieniem tego co robi dana metoda oraz zwiększy czytelność kodu a przez to ułatwi modyfikowanie go ... co tylko się opłaci ! Czytając kod klas skupimy się na tym co klasa robi i co zwraca, a uwolnimy się od zastanawiania się nad tym jak to wyświetla co zdecydowanie pozwoli nam skoncentrować naszą uwagę na rozwiązaniu problemu.

Jeżeli już decydujemy się na skorzystanie z MVC następuje pytanie, czy piszemy własne klasy do obsługi tego co potrzebujemy ponieważ na przykład używamy tylko MVC czy może przydadzą nam się dodatkowe mechanizmy pozwalające na niezależność od rodzaju bazy danych (nie wiemy na czym będziemy pracować), dodatkowe opracowane już przez kogoś mechanizmy czy w końcu niezależność od wersji PHP :)

Moje programy - Linux

Komunikatory:

Ekg2 - świetnie mi się go używa. Jest prosty i po prostu działa. Obsługuje mi pocztę (gmail), jabbera, IRCa, Tlena i GaduGadu. Jest po prostu idealny.

Pidgin - świetny komunikator, który potrafi obsłużyć bardzo wiele sieci. Estetycznie wykonany pod GTK na Kasi wygląda naprawdę bomba !

Kadu - Nie trzeba przedstawiać. Przeszkadza mi tylko to, że napisany jest pod QT, ale to dla mnie w sumie jego jedyna wada, wada związana z estetyką - a dokładniej Jej brakiem.

Psi (daisy) - Świetnie nadaje się do Jabbera. Sam używam na chromie.

Skype - Znajomi i rodzice używają, więc czemu nie ja :) w sumie miło się gada :)

Przeglądarki:

Opera, Firefox -nie trzeba przedstawiać.

IEs4linux - używam do testowania stronek internetowych pod Linuksem - bardzo wygodne.

Odtwarzacz muzyki:

MOC - po prostu urzekł mnie swoją prostotą i genialnym rozwiązaniem - klient serwer. Jak doinstalować zgodnie ze wskazówki na stronie dodatkowe kodeki to można posłuchać muzyki w najbardziej pstrokatych formatach.

AmaroK - Lubię to w jaki sposób kataloguje muzykę, jak na mnie zbyt ociężały. Na dzień dzisiejszy używam go tylko do słuchania radia internetowego do momentu, w którym nie poprawią MOCa aby też to potrafił.

Inne multimedia:

mplayer - razem z wtyczką do FireFox-a po prostu super ! Odtwarzam prawie wszystko.

VLC - wiem, że mogę na nim polegać. Czasem nie działają mi pliki WMP ... wtedy używam VLC i idzie jak burza. Poza tym ma świetne opcje do streamingu :) mi oczywiście nie potrzebne, ale może komuś się przydadzą :)

Edytory programistyczne:

vim - podoba mi się jego funkcjonalność i kolorowanie składni, umie sprawnie sprawdzać pisownię ASPELLem - w sumie wszystko czego człowiekowi do szczęścia potrzeba.

Eclipse (dokładnie PDT - dedykowane dla PHP) - jak na mój komputer do bólu ociężały, ale wybajerzony. Podoba mi się wsparcie dla wpisywanych funkcji, dostęp do manuala oraz menadżer klas - bardzo pomaga przy pisaniu kodu.

Bluefish - świtny edytor, jednak jego głównym mankamentem jest brak uzupełniania składni poleceń oraz strasznie brakuje mi wbudowanego klienta FTP.

Kate - Lekki, napisany w QT edytor. Najwygodniejsze jest to, że jak każda aplikacja w QT umie obsłużyć prawie każdy protokół, który się Jej zaserwuje - to jest bardzo wygodne. Wkurza mnie tylko jego tempota na zapisywanie stanu środowiska pracy i uparte proszenie o hasło do kont zdalnych przy uruchamianiu.

Quanta Plus - rozbudowana wersja Kate dziedzicząca po niej swoje wady i zalety ! Dużo bardziej rozbudowana pod kątem tworzenia stron www.

Klienci FTP:

gftp - po prostu lekki i przyjemny w użyciu, typowy, dwu panelowy klient FTP.

konqueror - dzięki obsłudze protokołów zaimplementowanej w QT niesamowicie wygodnie używa się go ponieważ zdalny system plików jest transparentny i używa się go jak lokalnego.

Menadżer logowania:

qingy - świetne możliwości graficzne, fajne motywy i możliwość stworzenia naprawdę WŁASNEGO niepowtarzalnego ekranu logowania, także do konsoli :) jest naprawdę świetny !

Pulpit zdalny:

rdesktop - świetny sposób na dobranie się do swojego Windowsowego przyjaciela :)

Grafika:

JAlbum - świetny program do generowania miniaturek - nic dodać, nic ująć :)

GIMP - Darmowy program do obróbki grafiki - bardzo użyteczny :)

GTKSee - świetny program do pokazu slajdów.

GQView - genialnie nadający się do wybierania zdjęć programie z kapitalną opcją kopiowania aktualnie oglądanego zdjęcia do wcześniej ustalonego katalogu.

Menadżer plików:

Thunar - świetne podglądy plików i nie do pobicia system masowej zmiany nazw plików :) oraz świetna możliwość dodawania swoich miejsc w panelu po lewej stronie.

Konqueror - nie do przebicia, wszystko co QT oferuje znajduje się tutaj - trochę przeciążony, ale obsługuje kapitalne podglądy, metody sortowania i dostępu do zdalnych zasobów.