Gotowe rozwiązania w PHP – samo dobro?

06 maja 2010

Za napisanie czegoś w tym temacie zabierałem się dobre kilka lat :) Uznawałem do tej pory, że lepiej nie wdawać się w długie dyskusje tylko dalej robić swoje i po swojemu. Jednak coraz częściej spotykane, wręcz euforyczne komentarze na temat różnych gotowych rozwiązań w PHP skłaniają mnie do dodania łyżki dziegciu do tej beczki miodu…

Bez dwóch zdań, PHP to lider w tematyce tworzenia stron www. Za popularnością idzie również wzrost aplikacji open source, których w świecie PHP jest zatrzęsienie. Gdyby tak na nie wszystkie spojrzeć to można byłoby dojść do wniosku, że tworzenie stron www stało się bajecznie proste i bardzo szybkie, przecież dla każdego elementu strony mamy setkę różnych darmowych rozwiązań. Tylko czerpać garściami…

Szybko się jednak okazuje, że nie ma tak różowo. Bez względu na to czy mówimy o rozbudowanych systemach CMS czy o frameworkach to zawsze powtarzają się te same główne problemy:

  • Wydajność
  • Zbyt dużo elementów, których nie potrzebujemy a które są uruchamiane…
  • … natomiast nie ma tego co dla nas jest najważniejsze lub jest ale nie spełnia naszych wszystkich oczekiwań
  • Obciążające mechanizmy, które mają za zadanie dostosować aplikację do wszystkich popularnych serwerów, rozwiązań itd. a Tobie nigdy się nie przydadzą
  • Musisz się uczyć nowego oprogramowania, czasami jest tyle zasad, komend i funkcji do zapamiętania, że przybiera to rozmiary małego języka programowania

Oczywiście lista wad zależy od naszych potrzeb i oczekiwań. Przy malutkim projekcie mało kto zwraca uwagę na wydajność. Przy typowym projekcie bez żadnych szczególnych wymagań zadowolimy się gotowymi modułami, które są dostarczone razem z CMS’em. I tak dalej… Z drugiej strony czy potrzebujemy wytaczać tak ogromne działa jak np. Drupal do strony jakiejś firmy gdzie będzie maksymalnie 10 podstron? I jak często projekty, które tworzysz są tak typowe, że zadowalasz się gotowymi modułami do CMS’a i nic już w nich nie musisz zmieniać?

Nie byłbym obiektywny gdybym widział w gotowych rozwiązaniach tylko same wady. Podstawowe zalety to:

  • Dobra (przeważnie) dokumentacja
  • Duża społeczność gdzie wielu służy Ci pomocą gdy masz problem i jednocześnie możesz szukać pracownika/współpracownika, który nie zgubi się w Twoich projektach bo korzysta z tego samego oprogramowania
  • Sporo gotowych rozwiązań, których można używać lub się na nich uczyć
  • Bezpieczeństwo
  • Łatwość programowania

Jak widać, gotowe rozwiązania mają się czym bronić.

Dokumentacja, jaka by nie była to i tak jest lepsza od tej, którą Ty masz na starcie w swoim autorskim rozwiązaniu (a nie masz żadnej póki sobie jej sam nie stworzysz).

Społeczność i spore grono już „wyszkolonych” pracowników to też zaleta. Chociaż z tymi specjalistami to też nie jest tak różowo bo najczęściej brakuje takich, którzy już umieją dobrze sobie radzić z danym narzędziem i trzeba ich i tak douczać. A nawet jak są to się cenią…

Gotowe moduły to fajna rzecz. Niestety i tutaj jest się do czego przyczepić. Często są źle zaprojektowane, niechlujnie napisane, powodują zwiększone obciążenie, mają w sobie furtki dla włamywaczy a na ich podstawie możemy się jedynie nauczyć jak NIE programować. Nie będę jednak tak krytyczny, zdarzają się prawdziwe perełki a duża część trzyma poziom.

Bezpieczeństwo: z jednej strony błędy są szybko wychwytywane przez społeczność i developerów, z drugiej główny kod Twojej strony, tzw. „silnik” jest dostępny dla każdego i każdy teoretycznie może tam wyszukać lukę lub skorzystać z gotowej instrukcji jeżeli na czas nie załatałeś strony oficjalną łatką. Jednocześnie jednak CMS’y i frameworki najczęściej mają mechanizmy, które pilnują programistę aby nie potworzył furtek dla włamywaczy a w Twoim własnym oprogramowaniu sam się musisz pilnować lub pisać samemu mechanizm zabezpieczeń. Jeszcze inaczej podchodząc do tematu, w Twojej aplikacji może być luka ale jest niewielkie prawdopodobieństwo, że ktokolwiek na nią trafi i ją wykorzysta bo nikt nie ma Twoich kodów źródłowych :) Chociaż to nie jest oczywiście najlepsze z możliwych podejście do bezpieczeństwa…

Z łatwością programowania to już jest bardzo różnie… Takie są ogólne zasady powstawania gotowych narzędzi: ułatwiać życie programiście. Nie zawsze jednak cel jest osiągany. Nie da się jednak zaprzeczyć, że wraz z gotowymi rozwiązaniami dostajemy często moduły np. do łatwego testowania i debugowania naszych aplikacji. We własnych projektach jest z tym dużo gorzej.

Czas na kilka przykładów z życia. Pierwszy raz na blogu odniosę się do mojej ponad rocznej pracy z systemem Drupal. Nie byłem z tego wyboru jakoś wielce zadowolony chociaż rozumiałem argumenty dlaczego go wybrano w firmie. Nasz największy projekt od dnia startu do pierwszej wersji beta pochłonął kilka miesięcy pracy dwóch programistów. Dodajmy uczciwie, że cały czas uczyliśmy się tego CMS’a. Efektem była całkiem sympatyczna aplikacja i kilkadziesiąt naszych autorskich modułów. Nie wszystko jednak wyglądało tak jak powinno… To co zaliczyłbym do wad:

  • Miesiące nauki a i tak co chwila napotykaliśmy na problemy (a chyba tacy głupi nie jesteśmy… :) )
  • Niektóre rzeczy napisalibyśmy w godzinę ale głowiliśmy się kilka dni jak to ugryźć w Drupalu przez narzucone przez niego ograniczenia
  • No właśnie, ciągle ograniczenia i ograniczenia. Jasne zasady i standardy są dobre ale nie można przesadzać…
  • Wydajność… a raczej jej brak
  • Co z tego, że jest dużo gotowych rozwiązań skoro i tak wiele z nich musieliśmy poprawiać i dostosowywać do swoich potrzeb

Odniosę się tylko do wydajności bo cała reszta jest raczej jasna (a w szczegóły wchodzić nie ma sensu bo to nie wpis o Drupalu). Nie wiem dokładnie jak obciążony był serwer naszą aplikacją ale z pewnością bardzo i od początku były z tym problemy. Gdy pierwszy raz sprawdziliśmy ile zapytań do bazy danych generuje strona główna to mało nie spadłem z krzesła. Ponad tysiąc dwieście! Specjalnie napisałem słownie żeby nie było wątpliwości, że się nie pomyliłem :) Po optymalizacjach wyszło ponad 700. W Drupalu były włączone standardowe mechanizmy cachowania itp. Nie wiem czy i jak sobie z tym poradzili, wkrótce potem zająłem się innymi sprawami. Te liczby są porażające… Odnosząc się do moich autorskich rozwiązań strona główna nasztomaszow.pl generuje dziennie kilkadziesiąt zapytań do bazy. Dziennie! Kilkadziesiąt! I to bez względu na to jak duży ruch jest na stronie z racji sprytnego systemu cachowania. Poza nawiasem dodam, że standardowy system cachowania w Drupalu jest oparty o… bazę danych. Nie wiem czemu tak, może ja się nie znam i tak jest najwydajniej :)

Po tamtych doświadczeniach wiedziałem już, że mój następny projekt oprę o własne rozwiązania. Tak się składa, że NaszTomaszow.pl (a o nim właśnie mowa) można śmiało porównywać z opisywaną aplikacją w Drupalu. Obie mniej więcej odpowiadają za to samo – za prowadzenie/obsługę portali miejskich. O liczbie zapytań do MySQL strony głównej już pisałem. Niestety nie pamiętam już jakie wyniki generował XDebug dla witryny w Drupalu natomiast praktycznie goła instalacja tego CMS’a generuje się u mnie w średnio 700ms. Jak na tym tle wygląda mój system? Stronę główną NaszTomaszow.pl parser wypluwa w około 45ms. Czystą instalację w 15ms.

Zrobiłem inne testy*. Sprawdziłem jak szybko generują się strony we frameworku Yii (podobno bardzo wydajny), przetestowałem system forum IPB i CakePHP. Wiem, że to nie jest jakaś super reprezentatywna grupa ale są to raczej popularne skrypty a ja zrobiłem testy tylko z ciekawości a nie aby badać cały rynek ;) Oto wszystkie wyniki:

  • Yii (przykład blogu z oficjalnej paczki) – średnio 650ms
  • forum IPB (konfiguracja z NaszTomaszow.pl, forum puste) – średnio 420ms
  • CakePHP (czysta instalacja, tuż po wypakowaniu z oficjalnej paczki) – średnio 790ms
  • Drupal (malutka, prosta stronka, baza praktycznie pusta) – średnio 700ms
  • Mój system (na podstawie aktualnej wersji plików i bazy NaszTomaszow.pl) – 45ms
  • Mój system (czysta instalacja) – 15ms

Czy więc odradzam korzystanie z gotowców? Nie, zdecydowanie nie. Sam przecież czasami stawiam coś na Drupalu a ten blog oparty jest o WordPress’a. Warto poznać popularne rozwiązania open source, chociażby po to żeby móc mówić o ich wadach. Przy pracy z nimi zdobędziesz też wiele doświadczenia i odkryjesz ciekawe rozwiązania wielu problemów. Czasami ich wybór jest jedynym słusznym rozwiązaniem.

Ten artykuł jest bardzo lakoniczny, może nawet ktoś uzna, że amatorski. Nie chciałem porównywać konkretnych systemów, głosić jedynej słusznej teorii i nawracać niewiernych. Chciałem przypomnieć Ci, że nic nie zastąpi zdrowego rozsądku. Pogódź się z tym, że nie ma idealnych narzędzi. Zawsze to Ty musisz się wykazać znajomością problematyki i przewidzieć na jakie problemy możesz się natknąć oraz wykazać jakie rozwiązania będą efektywniejsze i spełnią Twoje założenia. Czasami potrzebna jest ekstremalna wydajność, czasami najważniejszy jest czas oddania projektu, innym razem masz wieloosobowy a może nawet międzynarodowy zespół. Czynników, które powinny wpływać na Twoją decyzję co do wyboru oprogramowania są dziesiątki.

Przypominają mi się w tej chwili stare wojny np. programowanie strukturalne versus obiektowe. Zawsze to co nowe podbijało szybko serca programistów, przychodził jednak czas opamiętania i rozsądek podpowiadał wtedy starą prawdę: stosuj wedle zapotrzebowania.

* Wszystkie testy były banalnie proste. Uruchomiony XDebug, wyniki odczytywane za pomocą WinCacheGrind, kilkanaście prób i wyciągnięta średnia.

EDIT 14.06.2010
Postanowiłem dzisiaj sprawdzić jak wydajnościowo mają się dwa frameworki, którymi jestem szczególnie zainteresowany. Oto uzupełnienie powyższej listy:

  • Symfony (przykładowa paczka Sandbox) – średnio 680ms
  • Zend Framework (oficjalne aplikacje demo) – średnio 365ms

Takiego właśnie wyniku Symfony się spodziewałem. Słyszałem narzekania na jego wydajność. Paczka Sandbox to, o ile dobrze przeczytałem, wstępnie skonfigurowane Symfony. Na tle Drupala, który po instalacji ma już wiele gotowych elementów do zaoferowania nie wygląda to imponująco (chociaż po ponad rocznej pracy z Drupalem i pięciu minutach w dokumentacji Symfony chyba w tym drugim, jako programista, czułbym się lepiej ;) ).

Testując Zend Framework skorzystałem z gotowych aplikacji demo, które znalazłem w paczce. Zdarzały się dużo lepsze czasy niż powyżej zaprezentowana średnia (poniżej 200ms a nawet poniżej 50ms) ale powiedzmy sobie szczerze, ile może trwać wyświetlenie jednego formularza? :) Dlatego wybrałem dwa czy trzy trochę bardziej wymagające wersje demo i na nich oparłem wyniki testu. Ciekaw jestem jak wyglądałyby wyniki np. przy jakimś prostym systemie newsów.


NaszTomaszow.pl – epilog

07 stycznia 2010

Logo NaszTomaszow.pl

W ostatnich dniach i tygodniach decydowała się przyszłość portalu NaszTomaszow.pl. Trzeba było podjąć pewne decyzje, obecny stan rzeczy nie mógł trwać wiecznie. Powodów było kilka:

  • Przede wszystkim w Tomaszowie jest fatalna sytuacja na rynku reklam. Długo by opowiadać…
  • Po drugie, bardzo ciężko przebić się z nowym medium. Rynek jest hermetyczny, jest wiele znajomości, układów, niepisanych umów. Wszystko już zostało podzielone i nowa konkurencja nie jest mile widziana.
  • Po trzecie wreszcie, w Tomaszowie świadomość potencjału jaki niesie ze sobą internet jest na wyjątkowo niskim poziomie. Ciężko jest przekonać do kupna reklamy czy „sprzedaniu” dobrego tematu kogoś kto nie jest pewien którym przyciskiem włącza się komputer.

Do tego dochodzi jeszcze niejasna sytuacja na samym portalu. Nie tylko ja włożyłem w niego dziesiątki a może nawet setki godzin pracy. Obowiązywały mnie pewne słowne ale dżentelmeńskie umowy o współpracy, których wypadało dotrzymać.

To wszystko spowodowało, że z nowym rokiem przestałem być właścicielem portalu NaszTomaszow.pl. Ci, którzy znają mnie trochę lepiej i/lub czytają dokładniej mojego bloga wiedzą, że to nie pierwsza taka sprzedaż w moim życiu. Tym razem jednak, oprócz zapewnień słownych, gwarancja dalszego rozwoju portalu (w czym mam brać czynny udział) została zapisana w umowie sprzedaży. Oczywiście o wszystkim decydował będzie nowy właściciel ale można mieć nadzieję, że strona nie skończy tak jak osada.pl i jeszcze przez długie lata będzie służyła mieszkańcom Tomaszowa Mazowieckiego, również mi.

Przy okazji chciałbym rozwiać pewien mit jakoby NaszTomaszow.pl powstał tylko na złość właścicielowi tomaszow.pl. Słyszałem takie oskarżenia wielokrotnie a to zupełne bzdury… Nie wiem jak bardzo nienawistnym człowiekiem trzeba byłoby być aby poświęcać tyle czasu, rezygnować przez tyle miesięcy z odpoczynku, tworzyć kod tyle tygodni i miesięcy po godzinach i robić to wszystko tylko po to aby dopiec komuś innemu.

Prawda jest taka, że NaszTomaszow.pl powstał dlatego, że była luka na rynku. Tomaszow.pl był (i nie licząc krótkiej przerwy gdy coś się tam działo, nadal jest) zaniedbany i opuszczony. Uznałem, że jest to szansa i postanowiłem ją wykorzystać. Taka działalność idealnie wpasowałaby się w moje plany ponieważ chciałem oferować usługi tworzenia i utrzymywania stron www na rynku tomaszowskim. NaszTomaszow.pl miał być moją wizytówką, portfolio i darmowym ogłoszeniem moich usług. Plany zmieniły się gdy pojawiła się ciekawa oferta sprzedaży osada.pl na którą przystałem. W ten sposób został mi osamotniony NaszTomaszow.pl z którym nie było co zrobić :)

Nieprawdą jest również, że to ja odpowiadam za upadek tomaszow.pl. Owszem, był czas gdy byłem administratorem tamtejszego forum ale z pewnych powodów zrezygnowałem z tego stanowiska na około rok przed powstaniem NaszTomaszow.pl. Sam portal otworzyłem w połowie października, gdy forum tomaszow.pl od dawna było zaspamowane przez roboty spamujące, które, jak wszyscy wiemy, są plagą internetu. Mimo to jeszcze wiele miesięcy nic się nie zmieniło i roboty zostały zablokowane dopiero w marcu (mogę się mylić ale jestem pewien na 80%, że to był marzec) następnego roku. Tak więc właściciel tomaszow.pl nie zajrzał na własne forum przez 5, może 6 miesięcy mając wiedzę, że źle się tam dzieje (wielu użytkowników go o tym informowało). Nie przeszkodziło mu to wszystko aby to mnie obarczać winą za zaistniałą sytuację… Pomijam fakt, że cała reszta strony była również opuszczona i mimo upływu lat jest tak nadal. I tak pewne osoby ostatecznie powiedzą, że to wszystko moja wina :) A przecież od tak dawna nie mam z tą stroną zupełnie nic wspólnego…

Ufff… Tyle wystarczy. Musiałem to w końcu napisać. Ktoś może stwierdzić, że wylewam tu swoje żale ale milczałem od dawna jednak minęło już kilka lat a ja nadal jestem pomawiany i obwiniany za wszystko. A prawda jest taka, że każdą stronę trzeba pielęgnować, opiekować się nią a nie zrzucać winę na innych zamiast szukać błędów we własnym postępowaniu.

Mimo sprzedaży NaszTomaszow.pl mam nadzieję, że jeszcze tomaszowianie będą mieli okazję z zadowoleniem korzystać z moich stron www :) Kroki, które podjąłem pozwalają mi myśleć z nadzieją o moim nowym, już ogólnopolskim serwisie. W odpowiednim czasie na pewno dowiecie się ode mnie na ten temat więcej :)


Dwa wnioski na temat nasza-klasa.pl

04 czerwca 2008

1. Na nasza-klasa.pl nie brakuje idiotów

Skąd taki wniosek? Otóż wczoraj miałem to „szczęście” trafić na stronie głównej nasza-klasa.pl na nagie zdjęcie jakiegoś zboczeńca. Oczywiście efekt zamazania sam dodałem…


Czytaj dalej »


Zamiana tekstu na tabelę w HTML cz. 2

18 kwietnia 2008

Okazało się, że poprzedni wpis nie wyczerpuje wszystkich możliwości. Załóżmy, że mamy poprawnie stworzoną tabelę w Wordzie i trzeba ją przenieść na swoją witrynę. Są skrypty, które potrafią czyścić zbędne formatowanie Worda. Tak jak pisałem we wcześniejszym wpisie, korzystam na stronie z edytora WYSIWYG FCKeditor i on ma opcję wklejania z Worda z usuwaniem niepotrzebnego kodu. Ale.. Już jakiś czas nie musiałem się z tym męczyć i wypadło mi z głowy, że edytor nie jest doskonały (o czym dzisiaj boleśnie sobie przypomniałem). Zostają chociażby tagi odpowiedzialne za centrowanie, wielkość i wygląd czcionek, szerokość kolumn itd. Trzeba to poprawiać ręcznie lub przez jakieś znajdź/zamień.

Ale przecież nie po to stworzono komputery żeby nam utrudniały pracę :) A więc jak poradzić sobie z problemem? Proponuję skopiować tabelkę i wkleić ją do zwykłego notatnika, jakiegoś pola textarea czy innego miejsca gdzie obiekt całkowicie straci formatowanie. Dostaniemy coś takiego:

CODE:
  1. 1.
  2.  Wojtalczyk Artur
  3. 253
  4. 2.
  5.  Wojciechowski Tomasz
  6. 251
  7. 3.
  8.  Plich Leszek
  9. 245

Tak wygląda tabelka złożona z trzech kolumn i trzech wierszy. Trzeba to teraz jakoś przywrócić do stanu używalności. Funkcja jest jeszcze prostsza niż w poprzednim wpisie. Oto ona: Czytaj dalej »


Zamiana tekstu na tabelę w HTML

16 kwietnia 2008

Na redakcyjny e-mail nasztomaszow.pl co jakiś czas przychodzą informacje do zamieszczenia na stronie. Przeważnie są pisane w Wordzie. Problem pojawia się gdy do newsa trzeba przekopiować tabelkę :/ Pół biedy gdy taka tabelka jest poprawnie stworzona w dokumencie Word bo używam wizualnego edytora online o nazwie FCKeditor. Ma on prosty w obsłudze skrypcik wywalający zbędne formatowanie i jest po sprawie. Niestety... Niektórzy nie wiedzą chyba co to tabelka w Word i nawalają mnóstwo spacji lub tabulatorów :/ Wygląda to mniej więcej tak:

CODE:
  1. 1. WIKING KADET             15        26        26:10
  2. 2. HUBAL               14        26        25:11
  3. 3. EXTOM                14        25        24:8
  4. 4. TKKF ZNP              14        25        22:8
  5. 5. POLSKÓR              14        24        22:9
  6. 6. JUNIOR               15        23        18:16

Piękne prawda? :/ Płakać mi się chce gdy dostaję info z kilkunastoma tabelami i muszę to wsadzić w HTML :/ Dzisiaj przebrała się miarka... :)
Czytaj dalej »


NaszTomaszow.pl czyli Tomaszów Mazowiecki po mojemu :)

15 lipca 2007

Postanowiłem napisać parę słów o tej stronce i przy okazji pokrótce opisać lokalny rynek. Ale najpierw trochę historii.. Czytaj dalej »