Michał Przytulski blog

Od jakiegoś czasu zastanawiałem się jaka jest faktyczna różnica w szybkości działania poszczególnych wersji PHP. Przeglądając zasoby Internetu natrafiłem na ciekawą stronę - http://shootout.alioth.debian.org/ zawierającą porównanie wydajności różnych języków w tych samych zastosowaniach. Niestety testy zamieszczone na w/w witrynie ograniczają się tylko do jednej wersji PHP, więc nie jest to, to czego poszukiwałem. Postanowiłem jednak skorzystać z zgromadzonych tam skryptów i przeprowadzić własne testy porównawcze.

(more…)

W poście tym chciałbym obalić jeden z popularnych mitów w programowaniu PHP - mianowicie przekonanie, iż wszelkiego rodzaju wywołania statyczne są bardzo powolne. W celu zbadania efektywności wykonywanie poszczególnych zadań skorzystałem z:

• - PHP 5.2.0 (cli) (built: Nov 2 2006 11:57:36)
  Copyright (c) 1997-2006 The PHP Group
  Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
  with Xdebug v2.0.0RC3, Copyright (c) 2002, 2003, 2004, 2005, 2006, 2007, by Derick Rethans
• - WinCacheGrind 1.0.0.12

Testy zostały przeprowadzone na laptopie Asus M6870Ne (Pentium Mobile 1,8 GHz, 1536MB RAM), poniżej wyniki.

(more…)

Dziś miałem do czynienia z dość niespodziewanym, jednak bardzo pozytywnym zachowaniem bazy danych Oracle. Mianowicie w odróżnieniu od pozostałych (większości) baz danych, Oracle w bardzo prosty, a zarazem ciekawy sposób radzi sobie z różnicą kodowania znaków pomiędzy klientem, a serwerem. Większość systemów RDBM w takich sytuacjach dostarcza różnego rodzaju ślaczki, tak Oracle zamienia je na ich odpowiedniki z standardowego zbioru ASCII. Oczywiście pisze tutaj o domyślnym rozwiązaniu konfiguracyjnym nie określającym kodowania znaków, na szczęście zmiana zachowania bazy danych to ustawienie tylko jednej zmiennej, chodź i ta może przyjmować nieco egzotyczne wartości, i tak znane:

• WIN1250 (CP1250) odpowiada EE8MSWIN1250, czy bardziej pełna wersja POLISH_POLAND.EE8MSWIN1250
• LATIN2 (ISO-8859-2) - POLISH_POLAND.EE8ISO8859P2

Zmienne te ustawiamy dla PHP poprzez funkcje putenv();

Rozwiązanie to ma jedną moim zdaniem wadę- “ładna” konwersja znaków mniej “rzuca” się w oczy, co utrudnia wykrycie ewentualnych błędów związanych z tą funkcją.

Nigdy nie byłem dobry z języka polskiego, dlatego tez nie ma co się spodziewać dobrej recenzji na temat “php|architect’s Guide to PHP Security” autorstwa Ilia Alshanetsky. Ksiązka ta dostępna jest poprzez internetowa witrynę phparchitect.com w wersji PDF jak również papierowej - osobiście preferuje wydania drukowane niemniej jednak tutaj postanowiłem zrobić wyjątek - i jestem z tego w 100% zadowolony - blisko 200 stronnicowe (po odliczeniu index i okładek) wydanie elektroniczne przetrawiłem przez jeden z styczniowych weekendów. Ksiązka ta z pewnością dostarcza cały arsenał informacji jak zabezpieczyć się przed problemami, porusza tematy związane z bezpieczeństwem chyba każdego z elementów aplikacji web. Początkowo spodziewałem się szerokiej publikacji na temat tego dlaczego złe jest używanie registry_globals, i dlaczego warto walidować dane wejściowe - jednak juz po pierwszych stronach mogłem się przekonać ze ksiązka porusza temat znacznie szerzej. Omówione zostały w niej zagadnienia związane z XSS, SQL Injection, Code Injection, Command Injection oraz bezpieczeństwo sesji i kilka innych nie mniej ważnych zagadnień związanych z bezpieczeństwem. Każdy z 10 rozdziałów prezentuje się w podobny sposób - omówienie problemu, przykłady ataków, oraz omówienie sposobów zabezpieczania się przed nimi - począwszy od prostych wbudowanych w php rozwiązań (których wady są przedstawiane dokładnie - jeśli takowe są) po indywidualne rozwiązania. Ksiązka ta układa się w logiczną całość, a zapoznanie się z jej zawartością moim zdaniem powinno być obowiązkiem każdego programisty PHP. Cóż więcej mogę na ten temat powiedzie - książka jest bardzo cennym uzupełnieniem mojej dotychczasowej wiedzy i zapewne każdy znajdzie cos dla siebie.