Stylish: RealMadrid.pl – relacja live – odświeżamy.

Postanowiłem odświeżyć wygląd relacji live z RealMadrid.pl za pomocą wtyczki Stylish dla Firefoxa. Stary miał już swoje lata i “trącił myszką”. Nie można powiedzieć, że mój modern skin (ha! +10 do lansu) jest prawdziwie web 2.0, ale moim usprawiedliwieniem jest średni zmysł artystyczny, wrodzony ciąg do minimalizmu i brak podstaw obsługi Gimpa.

Chciałem, żeby relacja:

• była spójna kolorystycznie, a jednocześnie…
• … przejrzysta
• i nie męcząca zbytnio oczu
• posiadała jakieś elementy nowoczesnego designu
• nie przewidywała miejsca na reklamy

Efekty mojej pracy wyglądają następująco:

Przed:

Po:

Chciałem pokazać krok po kroku jak powstawała ta “przeróbka”, ale na pomysł takiego pokazu slajdów wpadłem widząc go na blogu Riddle’a, będąc w połowie prac i szukając pomocy. Za późno.

Przy okazji, trzeba przyznać, że Stylish to wtyczka bardzo wydajna i posiadająca spore możliwości. Świetnie nadaje się do tunningu stron, takiej ich personalizacji,  a także potrenowania CSS’a.

Sam arkusz wygląda tak:

- arkusz dla Stylisha -  RealMadrid.pl – relacja live (KLIKNIJ)

Ze względu na specyfikę narzędzia, nie nadaje się do użycia po za Stylish’em i Firefoxem (hak na zaokrąglone okna tylko dla Firefoxa, bo po co miałem zamieszczać haki dla np. Opery?).

Świąteczne porządki: newsTXT.

Krótko. Przeglądając localhosta znalazłem to:

ŚCIĄGNIJ:  newsTXT

Jest to pseudo system newsów oparty na plikach tekstowych, stworzony przeze mnie w jakiś zamierzchłych czasach. Napisany jest obiektowo, w PHP5, ale jest to raczej opakowanie funkcji w klasę niż pełne wykorzystanie obiektówki. Całość napisana była w celach edukacyjnych, później z braku czasu pracę nad newsTXT porzuciłem. Stąd brak np. obsługi wyjątków i kilka pomniejszych niedoróbek.

Po krótkim rozpoznaniu skryptu naprawiłem błąd, który prawdopodobnie zniechęcił mnie kiedyś do dalszych prac nad tymże i uznałem, że udostępnię go. Bez żadnych licencji itp., bo skrypt po za wartościami edukacyjnymi nie prezentuje innych. Ale może komuś się przyda.

Dlaczego nie warto pisać własnych frameworków?

• Konieczność aktualizacji i rozwijania swojego tworu. Nie jest lenistwem założyć, że Ty siedzisz i tworzysz projekty, a inni pracują na chwałę frameworka dzięki któremu Tobie będzie łatwiej. To po prostu praktyczne. A tak technologie się przedawniają, tutaj trzeba coś zaimplementować. Tam trzeba poprawić. Dlaczego masz się z tym męczyć sam?
• Konieczność tworzenia dokumentacji. Jeśli nie tworzysz dokumentacji, to jak masz zamiar pracowąć na swoim fremworku w zespole? Jeśli nie pracujesz w zespole, to zajmujesz się projektami które takowego nie potrzebują (tak, wiem, zaraz ktoś powie, że nie mam racji i oni sami zajmują się ogromnymi projektami, w dodatku tak tajemniczymi, że nic więcej nie mogą powiedzieć. I tak wam nie wierzę. Zresztą, jeśli ktoś rzuca się w pojedynkę na projekt wymagający MVC i funkcjonalności frameworka to życzę powodzenia ). Koniec końców, żeby ktoś zrozumiał działanie Twojego frame-pomagiera, by mógł pracować na nim wydajnie, musi spędzić czas na poznaniu jego sposobu działania. Przydałaby się chociażby dokumentacja klas i metod. A wtedy Ty musisz spędzić nad tym trochę czasu. Autodokumentacja – okej, jest, działa, ale suchy opis metod i przyjmowanych przez nich parametrów chyba różni się nieco od przykładów, grafów zależności itp.
• Twojego kodu nie przeglądało tysiące programistów, nie był on tworzony w zespole doświadczonych phpowych wyjadaczy i testowany przez tysiące użytkowników. Nie zawiera wszystkich nowoczesnych metod projektowania i programowania oraz sposobów na zachowanie wydajności czy modularności. A jeśi tak jest i sam zaimplementowałeś wszystko, co potrzebne by framework nadążał za nowościami, to dlaczego nie pracujesz w wielkiej firmie jako starszy programista czy kierownik zespołu?

Można pójść w drugą stronę i z frameworka zrobić religię (Symfony), zanim zacznie Ci ułatwiać życie spędzisz mnóstwo czasu studiując dokumentację. Chyba nie o to chodzi?

Najlepszym IMO rozwiązaniem jest lekki szkielet MVC (KohanaPHP?) i sprawdzone oraz maksymalnie przenośne biblioteki (ZendFramework). Zawsze można napisać coś samemu nie ślęcząc nad dokumentacją przez kilka dni.

Po co o tym mówię? Używałem juz CakePHP, próbowałem się wczuć w Symfony (używałem byłoby w tym miejscu nadużyciem), próbowałem używać Kohany w której ciągle czegoś mi brakowało, oraz Zend Frameworka (gdzie każdy tutorial mówił o innej filozofii budowy aplikacji). Myślałem o własnym frameworku (za kogo ja się uważam, chcąc pisać własny framework?!). KohanaPHP rozszerzona o dowolne klasy ZendF to rozwiązanie optymalne i zapragnąłęm podzielić się tą wieścią ze światem. Dziękuję za uwagę.