Mariusz Tarnaski "MariuszT"

Stało się i nie ma już odwrotu. Trzeba nauczyć się JavaScript. Nie, nie mówię o sobie bo ja już go znam (na jakimś tam akceptowalnym poziomie ). Mówię do Ciebie.

Nie pamiętam kiedy pierwszy raz zetknąłem się z JavaScript ale wiem na co wtedy była moda. Implementacja tego języka w wielu przeglądarkach kulała a jeżeli nawet coś bardziej złożonego działało to w każdej przeglądarce trzeba było to napisać trochę inaczej. Z tego powodu nie było wielu zaawansowanych koderów JS a w sieci krążyły różne skrypciki, które webmasterzy dzisiaj zgodnie określają mianem wodotrysków. Implementacja zegarka albo kalkulatora, „padający śnieg” czy animowany tekst podążający za kursorem myszki – oto na co było stać większość programistów JS i czym zachwycali się twórcy stron www.

Wreszcie przyszło jednak opamiętanie i wszystkie straszydła zaczęły znikać z sieci. Bo na cholerę komuś zegarek na stronie skoro każdy ma go w prawym dolnym rogu… ?

Nadeszły gorsze czasy dla JS… co wyszło temu językowi tylko na dobre Na całe szczęście język nadal się rozwijał a producenci przeglądarek nie zapomnieli o nim i pomału programowanie ze znośnego stawało się przyjemne. Co mądrzejsi zaczęli się zastanawiać jak wykorzystać potencjał, niemały potencjał należy dodać, tego języka. Po cichu zaczęły się pojawiać jakieś bardziej ambitne próby stworzenia czegoś praktycznego w JavaScript.

Może i Google Maps nie przyniosłoby ze sobą otrzeźwienia (mimo zaawansowanego użycia JS) gdyby nie to, że wykorzystano obiekt XMLHttpRequest (wymyślony przez Microsoft) dzięki któremu od tamtej chwili webmasterzy na całym świecie mogą się cieszyć technologią znaną pod nazwą AJAX.

I zaczęło się Wchodzisz sobie na stronę, klikasz, coś się dzieje, ewidentnie pobierane są nowe informacje z serwera a strona się nie przeładowała… To była rewolucja, technika ta szybko stała się pragnieniem każdego właściciela www. JavaScript nareszcie został doceniony, to były jego drugie narodziny. Szczęśliwie zbiegło się to w czasie z już całkiem przyzwoitymi implementacjami JS w przeglądarkach.

Dalej opowiadać chyba już nie trzeba, gdyby nie powyżej opisane wydarzenia to Internet z pewnością wyglądałby dzisiaj i działał zdecydowanie gorzej. Właściwie to nawet może nie mielibyśmy dzisiaj Web 2.0? Kto wie, w końcu JS i AJAX miały w tym trendzie bardzo duży udział a nowe możliwości były inspiracją dla pierwszych pionierów.

Dzisiaj programowanie w JS to zupełnie inna bajka niż wtedy gdy pierwszy raz się nim zainteresowałem. Twórcy przeglądarek prześcigają się w implementacji ekstremalnie szybkich silników JavaScript, mamy do wyboru wiele frameworków i bibliotek ułatwiających życie webmasterom a Google jasno daje do zrozumienia swoimi rozwiązaniami (Gmail, Google Maps, Google Docs etc. oraz cała idea Chromium OS), że bez JS już się nie da…

Zachęcam wszystkich do poznawania możliwości JS. Zapewniam Cię, że jeżeli wiążesz swoją przyszłość z tworzeniem stron www to nie masz wyjścia

Na nasze szczęście istnieją takie projekty jak jQuery, dzięki któremu programowanie w JS to poezja. Wybór frameworka należy do Ciebie ale podpowiem Ci, że ja już nie zabieram się za żaden projekt bez jQuery Oczywiście czasami coś prostego lepiej zaprogramować w czystym JS niż ładować dużą bibliotekę tylko po to aby obsłużyć jeden przycisk. Pamiętaj o tym.

Jeżeli na początku Twojej przygody brakuje Ci wielu rozwiązań z PHP to polecam zainteresować się projektem php.js. Nie radzę dodawać tej biblioteki do swoich stron (chociażby z powodu jej rozmiarów) ale łatwiej będzie Ci się czegoś nauczyć gdy zobaczysz jak zaimplementowane są w JS funkcje z dobrze znanego Ci języka.

Jest też coś dla programistów Java. Napisz wszystko w Javie i użyj Google Web Toolkit a kompilator sam zbuduje całą aplikację łącznie ze skryptami JS. Chociaż nie wszyscy są zdania, że to dobre rozwiązanie…

Podsumowując, chociażbyś bardzo chciał to JavaScript nie unikniesz. Ale nie ma ku temu powodów, czasy się zmieniły zdecydowanie na korzyść tego języka. Zacznij go odkrywać a zobaczysz ile nowych możliwości otworzy się przed Tobą i jak łatwo uzyskać niektóre efekty (zwłaszcza z pomocą narzędzi typu jQuery ).

Tytuł wcale nie nawiązuje do szachów chociaż jestem zapalonym graczem. Koniec roku sprzyja podsumowaniom i z tego powodu zdecydowałem się napisać kilka słów o ruchu jaki był na tym blogu przez ostatnie kilkadziesiąt miesięcy.

Związane jest to z moimi przemyśleniami i postanowieniami czego efektem jest taki oto wykres statystyk bloga:

Już spieszę z tłumaczeniami. Otóż… Upraszczając do maksimum, każdemu właścicielowi strony www zależy na jak największym ruchu na jego stronie. Ja, mając za sobą już tyle projektów, mam niejako we krwi aby na każdym etapie tworzenia i prowadzenia strony www postępować tak aby słupki rosły… Jednak czy aby na pewno najważniejsza jest jedynie unikalna liczba użytkowników odwiedzających nasze witryny?

Jak widać na powyższym wykresie, był czas gdy statystyki tego bloga rosły jak oszalałe. Powinienem być w takim razie zadowolony. Na stronę trafiało dużo więcej mało doświadczonych użytkowników, którzy poszukiwali łatwych metod ściągania plików z wrzuta.pl (wpis na ten temat) czy komentujących działania nasza-klasa.pl (chociażby ten wpis) itp. Zastanówmy się co mi ten ruch dał:

• zwiększone opłaty za serwer
• trzeba było poświęcać więcej czasu na moderację
• mnóstwo nic nie wnoszących komentarzy pod wpisami

To te najważniejsze „zalety” wysokich słupków. Jak widać, nie ma się z czego cieszyć… Oczywiście, gdyby blog miał na celu zarabianie i byłyby tu reklamy, liczba odsłon reklam wygenerowałaby dodatkowe przychody. To jedyna zaleta takiego „pustego” ruchu. Pamiętajmy jednak, że tendencje są takie aby rezygnować z opłat za odsłony i płacić za kliknięcia. Pewnie już dawno królowałaby w internecie ta druga metoda gdyby nie problem z fałszywymi kliknięciami…

Jakie można wyciągnąć wnioski z powyższego? Oczywiście, ruch na stronie jest zawsze pożądany. Pamiętajmy jednak, że powinno nam zależeć na wartościowych odwiedzinach. Na osobach, które mogą na dłużej zadomowić się w naszym serwisie, wzbogacić go, wnieść coś od siebie.

Ja nijak tego bloga nie promuję jednak był czas gdy prostymi metodami pozycjonowałem go na wybrane, popularne frazy. Zaprzestałem tego (co łatwo zauważyć na wykresie ) gdy dotarło do mnie, że bardziej sobie i stronie szkodzę niż pomagam. Przy prowadzeniu swoich stron pamiętajcie aby nie dać się ponieść magii cyferek. Czasami naprawdę lepiej mieć mniejsze statystyki…

Na koniec nie pozostaje mi nic innego jak tylko życzyć wszystkim bardzo popularnych serwisów z bardzo zaangażowanymi społecznościami Do zobaczenia w roku 2010!

Kolejna drobna wskazówka dla programistów PHP. W kursach o tym nie przeczytacie

Bywa tak, nawet całkiem często, że musimy się upewnić, że w zmiennej mamy np. tylko same cyfry lub małe litery. Pierwsze co wszystkim przychodzi do głowy to wyrażenia regularne. Ale chyba każdy z nas słyszał nie raz przestrogę, że jak można to lepiej unikać wyrażeń bo są wolne. Czy jest jakaś alternatywa?

A jest Nazywa się to Character type checking. Funkcji do wyboru jest kilkanaście, przykładowo (za php.net):

Dostaniemy:

Lista wszystkich dostępnych funkcji znajduje się tutaj, polecam się z nimi zapoznać. Testy wykazują, że funkcje wykonują się znacznie szybciej niż wyrażenia regularne. Funkcje ctype_* są wbudowane w PHP, nie trzeba się martwić o ich dostępność.

Właśnie pracuję nad jednym małym zleceniem. Problem w tym, że jestem podwykonawcą, odpowiedzialnym tylko za jeden element, całą resztę zrobił już inny programista. Muszę teraz edytować jego kod i dostosowywać do nowych potrzeb.

No to zaczynamy. Otwieram pliki. No super... Zamykam pliki i przełączam edytor na ISO Mogliby się ludzie już przestawić na UTF.

Otwieram pliki Plik konfiguracyjny z kilkudziesięcioma definicjami stałych, dla każdej tabeli w bazie jedna definicja. Nie podoba mi się to ale niech już tak będzie.

Szukam plików odpowiedzialnych za element którym mam się zająć. Na ftp trochę bajzel, można było to chyba trochę lepiej pogrupować ale nie jest tragicznie.

Jest coś dotyczącego zlecenia, otwieram. Ech, wszystko wpakowane w funkcje. Przykład:

Funkcje fajna rzecz ale ich używanie obwarowane jest pewnymi zasadami. Każdy lepszy kurs i każda książka o tym mówi. Założę się, że są tutaj funkcje, które używane są tylko w jednym miejscu przez co funkcjami nie powinny być. Olać, idę dalej.

Przeglądam pliki, cały HTML oparty na tabelkach. Oj dostałoby się koledze za to na publicznych forach Olać, HTML w tym zleceniu to już zupełnie nie moja bajka.

O, jest jakiś kawałek o logowaniu. Od razu w oczy rzuca się ten kod (fragment zapytania do MySQL):

To już nie jest takie śmieszne, ktoś się włamie a potem powiedzą, że moja wina. Trzeba będzie poprawić...

Identyfikator połączenia z bazą danych trzymany w sesji? Przyznam, że się nie spotkałem

Przyzwyczaiłem się już do angielskiego nazewnictwa plików, zmiennych itd. dlatego rażą mnie w oczy polskie słowa. Ale tu już się czepiać nie będę, wielu programistów tak robi, sam kiedyś tak pisałem. Musiałem się potem przestawić jak zacząłem pisać kod w wielonarodowych zespołach.

Pisałem już, że kod PHP jest całkowicie wymieszany z HTML'em? Dodajmy do tego, że wszystko jest pozamykane w dziesiątkach funkcji i mamy niezły mętlik. Nie lubię programować gdy nad kodem muszę się zastanawiać jak nad wierszem: "Co autor miał na myśli?".

Jak już jesteśmy przy domyślaniu się to wspomnę, że jest zero komentarzy w kodzie.

Dobra, czas zacząć pracować. Znalazłem to co mnie interesuje. I od razu szok:

Jak z PHP mam do czynienia już 6 czy 7 rok tak jeszcze takiego cuda nie widziałem. Czy ten programista nigdy nie słyszał o warunkach WHERE w zapytaniach SQL? Wyciągać całą zawartość tabeli tylko po to żeby sprawdzić czy czasem nam się konto nie zdubluje? :/ Paranoja... Nie chce myśleć co się będzie działo z serwerem gdy na stronie zarejestruje się więcej niż kilka tysięcy ludzi.

Po powyższym wiedziałem już, że łatwo z tym zleceniem nie będzie Na tym zakończę tą "recenzję" bo chociaż są jeszcze inne błędy, niektóre naprawdę poważne, to recenzowanie nie jest celem tego wpisu. Teraz kilka pytań bez odpowiedzi.

• Czy powinienem zwrócić programiście uwagę na jego błędy?
• Czy powinienem powiadomić właściciela projektu o kwiatkach jakie zgotował im ich programista?
• Czy powinienem poprawić chociaż te błędy, które jako tako dotyczą mojego zlecenia czy pojechać szablonem, który wyznaczył główny programista i mieć zlecenie z głowy?
• Czy powinienem o tym pisać na blogu?

Odpowiedzi na pytania wcale nie są proste. Albo zacznę interweniować i wszyscy mnie znienawidzą a sam będę miał tylko więcej nerwów i pracy albo nie odezwę się ani słowem i będę miał spokój ale strona będzie przez następne trzy lata łatana, pewnie przez tego samego programistę.

Z powyższego wpisu można wyciągnąć kilka wniosków.

• Po pierwsze, trzeba naprawdę dużo praktyki żeby zacząć dobrze programować.
• Po drugie, nie należy oszczędzać na programistach Nie wiem ile temu chłopakowi płacą ale kod jest słaby a projekt ciągnie się już pół roku i pewnie jeszcze trochę potrwa nim strona pojawi się w sieci. Lepszy programista zainkasowałby odpowiednio dużo kasy ale zrobiłby to porządnie a oni już by zarabiali.
• Po trzecie, na rynku chyba nie ma wielu dobrych programistów... Dostaję na to coraz więcej dowodów.

Zachęcam do dyskusji w komentarzach. Co o tym wszystkim myślicie? Co doradzacie?

Coś ostatnio nie mam czasu na pisanie na blogu, na nic nie mam czasu... A pomysłów na tematy wiele...

Dzisiaj jest jednak okazja Uruchomiłem ogłoszenia na NaszTomaszow.pl nad którymi ostatnio pracowałem a przy okazji natrafiłem na ciekawy element PHP o którym trzeba napisać kilka słów.

Już trochę czasu minęło od premiery PHP 5.3 tymczasem jakimś sposobem nie zauważyłem bardzo ciekawego rozwiązania, które wprowadzono w PHP 5.2.

Często w procesie budowania stron www spotykamy się z problemem poprawnej walidacji adresu e-mail, adresu www czy IP. Użytkownik nam się rejestruje i my musimy być pewni, że ten e-mail to naprawdę e-mail a nie coś w stylu "pocałujcie mnie w dupę"

Jak sprawdzić poprawność danego ciągu znaków? Oczywiście kłaniają się, tak przeze mnie ostatnio lubiane, wyrażenia regularne. Przeważnie mamy kilka opcji do wyboru:

Napisać własne (jak żeś głupi to się męcz )
Poszukać czegoś w google
Poszukać czegoś w swoich poprzednich projektach

Pierwszego nie będę komentował No chyba, że się uczysz i chcesz spróbować własnych sił to możesz się pobawić... Ale lepiej poszukać gotowca w sieci lub mieć gdzieś w dalekich zakątkach swojego dysku jakąś funkcję i używać jej w razie potrzeby.

Której metody byście nie użyli to mam lepsze rozwiązanie Z pomocą przychodzi PHP 5.2 i funkcja filter_var (i ogólnie funkcje filtrujące).

Z czym to się je? Prosty przykład:

Zawsze jedna funkcja, zawsze działa tak samo, wbudowana w parser i ktoś inny martwi się żeby działała poprawnie czyli nie musisz się zastanawiać czy aby na pewno znalezione/napisane przez Ciebie wyrażenie regularne jest poprawne. Kolejna funkcja, która mi ułatwi życie a przeciwnikom PHP da argument, że język ten ma mnóstwo funkcji w których można się pogubić i które rozleniwiają programistę. Świat jest piękny

Przydatne linki:
Lista wszystkich funkcji filter_* - pl2.php.net/manual/en/ref.filter.php
Lista dostępnych filtrów i ich opisy - pl2.php.net/manual/en/filter.filters.php

PS
Z jakiegoś powodu filtr FILTER_VALIDATE_URL przepuścił u mnie taki ciąg znaków "http://111111". Dziwne... Sam dodatkowo musiałem zatroszczyć się o sprawdzenie czy jest chociaż jedna kropka. Po jej dodaniu filtr działa już sprawnie.

Dzisiaj stanąłem przed pewnym problemem, który powstał w takiej sytuacji:
- mam panel administracyjny dostępny po zalogowaniu
- informacja o zalogowanym użytkowniku trzymana jest w sesji
- ID sesji jest przekazywany wyłącznie za pomocą cookie
- potrzebuję komunikować się między PHP a Flash

Problem powstał właśnie w miejscu komunikacji między PHP i Flash. Z jakiegoś powodu plik PHP wywoływany przez Flash nie potrafił odczytać sesji, tworzył nową. A ja musiałem odczytać info z sesji czy użytkownik jest zalogowany i ma odpowiednie uprawnienia. Ten element strony odpowiada za wgrywanie zdjęć na serwer i nie mógłbym zostawić tak dużej dziury w bezpieczeństwie.

Osobiście byłem tym problemem mocno zaskoczony bo przecież ID sesji przekazywane jest w cookie i PHP nie powinno mieć żadnego problemu z odczytaniem tej wartości. W jakiś sposób przeszkadza tu Flash bo inne skrypty oparte na Ajax działają bez problemów. Niestety na budowę Flash nie mam wpływu, korzystam z gotowego rozwiązania. Gdzieś tutaj widziałem źródła Flash ale nie po to stosuję gotowca żeby teraz w nim grzebać i pamiętać o zmianach zawsze gdy będę przeprowadzał aktualizację. Czytaj dalej »

Można długo dyskutować nad tym, która z popularnych przeglądarek internetowych jest najlepsza. Oceniać ich szybkość, funkcjonalność, zgodność ze standardami. Ale jeżeli chodzi o przydatność dla osób projektujących strony internetowe to Firefox nie ma sobie równych.

Ja teraz bez niektórych wtyczek czułbym się jak bez ręki Poniżej przedstawiam listę dodatków do Firefoxa, które codziennie ułatwiają mi pracę.

Firebug (getfirebug.com)
Król królów! Nie znasz, nie używasz? Wstydź się! Dzieki Firebugowi można przeglądać w banalny sposób kod HTML/CSS, edytować go na bieżąco, monitorować ruch jaki generuje strona, debugować JS i tak dalej... Naprawdę nieocenione narzędzie.

Firecookie (addons.mozilla.org/en-US/firefox/addon/6683)
Wtyczka do wtyczki czyli dodatek do Firebug'a dzięki któremu łatwo będziemy przeglądać i zarządzać pliczkami cookie.

HTML Validator (users.skynet.be/mgueury/mozilla)
Pisanie stron według standardów to podstawa. Ciągła walidacja zewnętrznymi narzędziami jest kłopotliwa. Ta wtyczka dodaje miłe w użyciu narzędzie, które natychmiast powiadomi Cię o tym czy przeglądana strona jest zgodna ze standardami i wyświetli listę błędów jeżeli test wypadnie negatywnie. Dodatkowo jest opcja włączenia numeracji wierszy w źródle strony, wtyczka podpowiada również co można poprawić w kodzie HTML aby był lepszy, nawet jeżeli przechodzi walidację.

ColorZilla (www.colorzilla.com/firefox)
Za pomocą tej wtyczki z łatwością pobierzemy informacje o dowolnym kolorze użytym na przeglądanej stronie internetowej. Nie trzeba już robić screenów ekranu i sprawdzać kolorów w jakimś programie graficznym.

MeasureIt (addons.mozilla.org/en-US/firefox/addon/539)
Patrzysz na jakiś element strony i zastanawiasz się jakie on ma mniej więcej rozmiary? Zmierz je z poziomu przeglądarki, dzięki tej wtyczce. Na razie oferuje ona proste mierzenie "na oko" ale twórca obiecuje na swojej stronie rozwój wtyczki i dodanie kilku ciekawych funkcji.

IE Tab (addons.mozilla.org/pl/firefox/addon/1419)
Po co osobno uruchamiać przeglądarkę Internet Explorer aby sprawdzać jak Twoja strona w niej wygląda skoro można się między Firefoxem a IE przełączać za pomocą jednego przycisku?

Screengrab (www.screengrab.org)
Potrzebujesz szybko zrobić screen aktualnie przeglądanej strony? Całej witryny, fragmentu, który akurat widzisz na ekranie a może tylko wybranego elementu? Z tym dodatkiem zajmie Ci to chwilkę

Live HTTP headers (livehttpheaders.mozdev.org)
Wtyczka dla osób, które programują po stronie serwera. Raz na jakiś czas istnieje potrzeba odczytania jakie dokładnie nagłówki wysyła serwer, jakie numery błędów zwrócono itd. Oczywiście można korzystać z zewnętrznego sniffera (polecam Wireshark) ale po co zaraz z armatą na muchę... ? Omawiana wtyczka jest prosta w obsłudze i dostarczy nam dokładnie tych informacji, które potrzebujemy, bez zbędnych śmieci. PS: podobną funkcjonalność udostępnia Firebug.

Zachęcam do eksperymentów i samodzielnych poszukiwań. Dodatków ułatwiających życie webmasterom jest naprawdę wiele. Każdy znajdzie coś dla siebie

PS
Mam nieodparte wrażenie, że o jakiejś wtyczce zapomniałem Zachęcam do podawania nazw i/lub linków do innych ciekawych dodatków do Firefox.

Funkcja file_exists jest wolna. To fakt niezaprzeczalny, generalnie każde odwołanie PHP do plików/katalogów jest wolne i nie da się tego przeskoczyć.

Z drugiej strony we wszystkich kursach i książkach na temat PHP jesteśmy karmieni ładnymi bloczkami kodu gdzie nieodłącznym elementem jest sprawdzanie czy dany plik istnieje przed pobraniem jego zawartości czy dołączeniem do skryptu.

Co w takim razie robić? Używać czy nie używać file_exists? Odpowiedź brzmi: to zależy.

Jeżeli jakiś plik do którego za chwilę zamierzasz się odwołać pochodzi z niepewnego źródła lub np. pracujesz nad projektem w którym grzebie mnóstwo ludzi lub jeżeli istnieje jakikolwiek inny powód przez który nie masz 100% pewności, że ten plik tam jest to używaj file_exists.

Ale jeżeli sam wgrałeś/wygenerowałeś wcześniej ten plik i wiesz, że on tam jest to, na miłość Boską, nie używaj file_exists tylko dlatego, że tak ładniej i profesjonalniej wygląda! Nie popadaj w skrajności bo wkrótce zaczniesz sprawdzać przed każdym include/require czy interesujący Cię plik jest na dysku.

Pamiętaj, programuj z głową. Czasami trzeba pisać systemy idiotoodporne ale czasami wystarczy napisać kawałek kodu, który wykonuje to i tylko to co od niego oczekujesz, bez zbędnej uniwersalności i wodotrysków.

W każdym kursie, w każdej książce o PHP najpierw opisywana jest funkcjonalność if/elseif/else a potem pokazana jest alternatywa switch/case z komentarzem, że jeżeli mamy kilka następujących po sobie warunków to najlepiej skorzystać właśnie ze switch/case.

A ja na to: gówno prawda!

Zaletą konstrukcji switch/case w PHP jest... ładny wygląd Taki zapis wygląda na bardziej uporządkowany, w kodzie jest mniejszy zamęt. Niestety opłacamy to wydajnością...

No dobrze dobrze, nie będę przesadzał Tak naprawdę to różnice są niewielkie. Przy tysiącu prób warunki if/elseif wykonały się 2 milisekundy a switch/case 3 milisekundy. Co ciekawe, użycie w if === zamiast == przyspiesza wykonanie o 4%.

Nie namawiam do porzucenia switch/case. Wyniki szybkości mogą się znacznie różnić w zależności od tego ile i jakie warunki mamy. Ale pamiętaj żeby nie nadużywać tej konstrukcji bo wcale nie jest taka wspaniała jak ją wszyscy opisują.

Ostatnio nie mam czasu rozpisywać się na blogu więc pomyślałem, że co jakiś czas będę publikował jakąś krótką, banalną wskazówkę dotyczącą optymalizacji PHP.

Zaczynam od łączenia stringów (a raczej o tym, że nie zawsze trzeba to robić). Wielokrotnie mamy potrzebę wyświetlić jakiś ciąg znaków, wartość jakiejś zmiennej itp. Robimy wtedy tak:

Wszystko pięknie, działa. Tylko czy jest sens łączyć stringi tylko po to żeby je wyświetlić? Po co zużywać czas i pamięć serwera? Nie lepiej zrobić tak?

Różnica niewielka (jakby ktoś nie zauważył: zmieniłem kropkę na przecinek), oszczędność także nie jest piorunująca ale tak jest na pewno lepiej i warto tak robić. Zdaję sobie sprawę, że wskazówka jest banalna ale zaskakująco mało osób ją stosuje