Mariusz Tarnaski "MariuszT"

Czas najwyższy na jakiś wpis z konkretnymi poradami bo ostatnio jest tutaj z tym kiepsko...

Jak wiemy (albo i nie ) autoryzacja w PHP działa tylko wtedy gdy PHP jest zainstalowane jako moduł Apache (o innych serwerach dzisiaj pisać nie będę). Tak przynajmniej oficjalnie głosi dokumentacja. Jest jednak światełko w tunelu dla tych, którzy mają hosting z PHP postawionym jako CGI.

Poniżej opisane jest jedno z rozwiązań. Nie ma pewności, że będzie u Ciebie działało, zależy to od możliwości/ustawień Twojego konta hostingowego. U mnie działa W komentarzach do wyżej podlinkowanej dokumentacji znajdziesz inne rozwiązania więc próbuj do skutku.

Pierwszy wymagany krok to ustawienie w pliku .htaccess odpowiedniej regułki. Wygląda ona tak:

W ten sposób ustawiamy w PHP specjalną wartość w tablicy $_SERVER z kluczem HTTP_AUTHORIZATION i danymi autoryzacyjnymi. Teraz wystarczy w PHP odczytać to co zaserwuje nam Apache takim kodem:

Przemyśl dokładnie gdzie to wstawić w swój kod. Dzięki takiej sztuczce PHP dostanie dwie wartości, Twój login i hasło, tak jakbyś korzystał z modułu Apache.

Gdyby powyższe nie działało to można spróbować jeszcze takiego kodu w .htaccess (zamiennie do powyższego):

U siebie akurat stosuje ten drugi kod bo to było pierwsze rozwiązanie na które natrafiłem. Jednak na większości serwerów bardziej dostępny jest mod_rewrite niż mod_setenvif dlatego wybrałem taką kolejność podawanych rozwiązań.

Dzisiaj banalny wpis ale mimo to ważny. Otóż dawno temu, gdy zdarzało mi się jeszcze zaglądać do różnych kursów podstaw HTML, PHP, MySQL, książek na ten temat etc. to wszędzie (o ile autorem był polak) zalecano używanie kodowania polskich znaków ISO-8859-2. Było to uzasadnione bo w tamtych latach wielu domorosłych webmasterów zaczynało swoją przygodę z tworzeniem stron internetowych od takich programów jak Microsoft FrontPage, który to usilnie promował kodowanie CP-1250 (domyślnie ustawione). Trzeba było wszystkich edukować, że to nie jest najlepsze kodowanie dla polskich znaków diakrytycznych.

Nie wiem jakie rady padają w aktualnych kursach, książkach itd. ale "niestety" te stare materiały nadal są dostępne. I nadal namawiają do kodowania ISO-8859-2 gdzie standardem światowym już od lat jest UTF-8.

Czemu ISO-8859-2 jest be? Z dwóch głównych powodów. Ma ograniczoną liczbę znaków do dyspozycji i może powodować stany depresyjne gdy będziemy musieli np. współpracować z zewnętrznym oprogramowaniem lub popierdzielimy coś z bazą danych etc.

Czemu UTF-8 jest cacy? Bo zapominasz o problemie kodowania.

Tak, wiem wiem. Powyższe argumenty są na poziomie "Tak bo tak" czy "Ja tak mówię i tak ma być" Głównie z jednego powodu. W sieci jest bardzo dużo materiałów na temat zalet UTF-8 i bez sensu żebym to teraz powtarzał. Ja tylko chcę zasygnalizować niewtajemniczonym, że mogą robić coś lepiej i wyłysieć trochę później.

Oczywiście niektórzy twierdzą, że im ISO-8859-2 wystarcza. Pozornie przy jakiejś małej stronce firmowej z pięcioma podstronami faktycznie nie ma sensu stosować UTF-8. Pozornie... Wszystko jest pięknie dopóki szef/klient nie zażyczy sobie wersji swojej strony po grecku bo jakimś dziwnym trafem produkowane przez niego żelki zaczęły tam schodzić jak ciepłe bułeczki i facet rozgląda się za inwestorem/wspólnikiem.

Nie przekonuje Cię to? Ten sam szef/klient zobaczył na stronie konkurencji, że "tam strona nie miga" co po 10 minutach myślenia "o co mu do cholery chodzi?!" wreszcie doprowadza Cię do celu: miał na myśli AJAX. I tym sposobem masz kilka godzin z głowy bo niestety nijak nie potrafisz sprawić aby znaleziona przez Ciebie biblioteka JS do obsługi AJAX potrafiła prawidłowo sobie radzić z ISO-8859-2.

Takich przykładów można mnożyć w nieskończoność. Mnie ostatnio na przykład szlag trafiał gdy musiałem pracować jednocześnie z plikami PHP kodowanymi w ISO-8859-2 i innymi kodowanymi w UTF-8. Co chwila trzeba było przełączać edytor na inne kodowanie żeby nie było krzaków...

Standard musi być jeden. Pamiętaj o tym przy starcie Twojego nowego projektu. Powyższe przykłady to tylko banały przy tym co Cię może spotkać gdy zastosujesz ISO-8859-2 na jakiejś naprawdę bardzo dużej stronie www.

Dwa główne (dla mnie) problemy z UTF-8:

• Pamiętaj o BOM Jak widać, nie ma róży bez kolców. BOM w UTF-8 jest nieobowiązkowy ale autorzy edytorów często robią po swojemu...
• Dopiero PHP 6 będzie w pełni obsługiwał Unicode. To oznacza, że dzisiaj takie funkcje jak np. strlen() czy strpos() zwrócą błędny wynik. Jak temu zaradzić można poczytać w komentarzach w dokumentacji do poszczególnych funkcji i/lub korzystać z funkcji mb_*().

PS
O czym ja tu piszę jak onet.pl, gazeta.pl i pewnie wiele, wiele innych dużych portali i witryn nadal wita nas w ISO-8859-2... Ech... Może to być jednak dowód na to jakie problemy są z... ISO-8859-2 Przypuszczam, że chętnie przesiedliby się na UTF-8 ale przez lata zgromadzili tyle danych, trzeba byłoby przeprowadzić tyle konwersji, plików, baz danych itd., że nie ma takiego odważnego, który by się tego podjął lub wyliczyli, że im się nie opłaca w to bawić.

Pewnie wielu z Was, tak jak i ja kiedyś, ma problem z wyrażeniami regularnymi. Przez długi czas znałem tylko ich podstawy nie mogąc przemóc się do dalszej nauki. Każdy przyzna, że ich wygląd potrafi odstraszyć... Oczywiście mimo wszystko polecam kształcenie się w tym kierunku, wyrażenia rozwiązują teraz dla mnie naprawdę skomplikowane czynności. Ale pamiętając swój własny opór przed ich nauką mam dla Was ciekawą alternatywę.

W sieci można znaleźć wiele przykładowych rozwiązań najpopularniejszych problemów. Bez wysiłku znajdziemy wyrażenia do wyciągania adresów email ze stron www, do podlinkowywania adresów www w stringu itd. Problem pojawia się gdy napotykamy na nietypowe zadanie do wykonania. Wtedy musi powstać wyrażenie i albo sam je sobie napiszesz albo ubłagasz kogoś, ewentualnie mu za to zapłacisz Czytaj dalej »

PHP ma bardzo liberalne podejście do typów danych jakich możemy używać. Dzięki dynamicznemu rzutowaniu typów nie musimy się bawić w żadne deklaracje typu tuż przy inicjacji zmiennej. Zmieni się on automatycznie gdy przypiszemy do tej zmiennej jakąś wartość. W jednej chwili zmienna może być typu string aby po chwili ta sama zmienna zwracała jako typ integer.

Oczywiście są zwolennicy i przeciwnicy takiego rozwiązania. Na pewno dla niektórych brak konieczności deklarowania i zapamiętywania typu każdej zmiennej to duży plus. Z drugiej strony robi nam się lekki bałagan (programiści potrafią zrobić niezły bajzel gdy nie są dyscyplinowani przez język w którym piszą), łatwiej o pomyłkę i powstaje wiele pytań kiedy tak naprawdę zmienna jest pusta, kiedy zwróci FALSE itd.

Dwóch pierwszych problemów nie rozwiążemy, co do trzeciego to przyda nam się ściągawka. Taka jak na stronie www.blueshoes.org/en/developer/php_cheat_sheet/. Znajdują się tam ładne i wygodne w użytkowaniu tabelki, które obrazują różnice między zmiennymi z przypisanymi różnymi wartościami, jak na te wartości reagują wbudowane funkcje PHP oraz który warunek if będzie prawdziwy przy użyciu == a który przy użyciu ===.

Polecam się z tym zapoznać, może to Was uchronić przed wieloma błędami logicznymi w Waszych skryptach. A jak wiemy, takie są często bardzo trudne do wykrycia...

Przy okazji wyrażę swoje zdanie na temat tego, że PHP automatycznie zmienia typ danych.

Przyznam, że mam co do tego mieszane uczucia. W swoich skryptach staram się unikać sytuacji gdy zmienna bez jakiegoś szczególnego powodu zmienia swój typ. Co więcej, możliwość takiej automatycznej zmiany sprawia, że czasami mam tylko więcej pracy przy zabezpieczaniu swoich stron.

Z drugiej strony konieczność deklaracji typu także nastręczałaby problemów. Zawsze musielibyśmy pamiętać o typie i asekuracyjnie sprawdzać czy jest prawidłowy przy przypisywaniu wartości do zmiennej bo inaczej wygenerujemy błąd.

Jeżeli miałbym decydować o najbliższej przyszłości języka PHP to chciałbym aby wprowadzono możliwość deklarowania typu. Nie konieczność a możliwość. Tak abym mógł przy inicjacji zmiennej zadeklarować jej typ i zmienić go tylko za pomocą dostępnych funkcji rzutowania. Zmienne bez deklaracji typu zachowywałyby się tak jak dotychczas. Czekam aż ktoś się przyczepi do tego pomysłu

Nie mam w zwyczaju pisać na blogu o nowościach. Jest wystarczająco dużo stron www, które dostarczają programistom itp. codzienną dawkę informacji i silenie się przez niektórych blogerów aby pisać o wszystkich niuansach (co przeważnie sprowadza się do napisania własnymi słowami tego co przed chwilą przeczytało się na dużym portalu) jest żałosne. Tym razem jednak złamię swoją zasadę bo wydarzyło się coś naprawdę interesującego

Język PHP, mimo iż niektórzy starają się usilnie tego nie zauważać, ma sporo zalet. Najwidoczniej nie tylko ja tak uważam skoro największy portal na świecie, Facebook, jest wykonany właśnie w tej technologii. Jednocześnie nie da się ukryć niektórych wad PHP, które przy ruchu 400mld odsłon miesięcznie są z pewnością szczególnie uciążliwe. Ludzie z Facebook postanowili coś z tym zrobić i tak powstała idea HipHop for PHP.

Jak wszyscy dobrze wiemy, instrukcje PHP są interpretowane od nowa za każdym razem gdy wywołamy jakiś skrypt PHP. To niestety musi powodować zwiększone obciążenie i wolniejsze działanie od języków, które kompilujemy. HipHop for PHP ma na celu "przeczytać" kod źródłowy PHP a następnie zamienić go na wysoko wydajny kod C++, który potem możemy sobie z łatwością skompilować. Taki stwór ma nam znacząco zwiększyć wydajność naszych aplikacji.

Przyznam, że mam mieszane uczucia co do tej wiadomości. Niby jest to jakiś rozwój PHP ale nie cieszy mnie fakt, że trzeba uciekać się do takich sztuczek aby znacząco zwiększyć wydajność kodu. W ten sposób szybko dojdziemy do wniosku, że w takim razie wypadałoby pisać strony w C++ i jedynie prostota PHP nas przed tym powstrzymuje.

Należy również wspomnieć, że nie zostały upublicznione żadne informacje o metodach przeprowadzonych testów. Jedyna informacja jaką wyczytałem to około 50% mniejsze obciążenie procesorów. Ciekaw jestem jak na tej samej maszynie wypadłby Zend Optimizer i tym podobne aplikacje.

Szkoda, że ludzie z Facebook nie dogadali się z Zend i nie powstało jakieś oficjalne rozwiązanie bo może się okazać, że HipHop for PHP będzie użyteczny tylko dla garstki osób. Mam nadzieję, że twórcy PHP wyciągną pewne wnioski z tego wydarzenia. PHP 5 wniosło wiele dobrego ale od tamtego czasu rozwój tak jakby zwolnił a PHP 6 nie zapowiada się na żadną rewolucję a ponadto nie słychać nic o premierze chociaż prace zaczęły się podobno już w roku 2005.

Miło byłoby aby wreszcie pozbierać ten język do kupy. Olać kompatybilność wsteczną, zrobić porządek z nazewnictwem a być może nawet całkowicie przejść na obiektowość. Nie cieszy również mnogość niektórych rozwiązań co wprowadza tylko zamęt. Osobiście nie jestem również do końca zadowolony z postaci czy rozwoju takich narzędzi jak PEAR czy Zend Framework (chociaż ZF podobno staje się coraz lepsze ale jakoś ostatnio nie śledzę tego projektu). Oby ktoś nad tym wszystkim nareszcie zapanował bo PHP to naprawdę przyjemny język.

Mam nadzieję, że mój sceptycyzm okaże się nieuzasadniony Wkrótce HipHop for PHP zostanie upublicznione, wraz z kodem źródłowym. Właściwie to już powinno być dostępne ale jakoś się nie doszukałem

PS
Zdecydowanie polecam przeczytać oryginalny news zapowiadający HipHop for PHP na Facebook.

PS2
Jeszcze ciekawszy tekst z którego wyczytamy sporo o technicznych aspektach uruchomienia i działania HipHop for PHP.

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.