pobierz w .pdf(przeznaczone do wydruku)

Wczoraj kodując jeden z projektów napotkałem na problem z @font-face w Firefoxie (tak, tak tym razem nie w IE ). Mianowicie FF nie odczytuje plików .eot ani .ttf. Na szczęście problem ten możemy rozwiązać w bardzo prosty sposób – dodając inne formaty czcionki do @font-face:

@font-face {
    font-family: "Ubuntu";
    src: url('fonts/Ubuntu.eot?') format('eot'), 
	 url('fonts/Ubuntu.woff') format('woff'), 
	 url('fonts/Ubuntu.ttf')  format('truetype'),
	 url('fonts/Ubuntu.svg#fonts/Ubuntu') format('svg');
}

Teraz musimy tylko wygenerować pliki w odpowiednim formacie. Osobiście używam tego narzędzia. Z moich testów wynika, że reguła ta działa we wszystkich popularnych przeglądarkach (FF/Chrome/Opera/IE/Safari)

ach ten pehape...

Jedyną rzeczą, której naprawdę nie mogę przeboleć w PHP, to fakt, że nie posiada on typowania. Oczywiście można "umówić się" z innymi programistami w zespole, że "typujemy" tzn. w komentarzach określamy typ przyjmowany i zwracany i się tego trzymamy, ale jest to jedynie obejście problemu, a nie jego rozwiązanie.Dobra, niestety świat nie jest idealny i musimy jakoś z tym żyć. W dodatku, jeżeli kod jest rzeczywiście obiektowy, to w większości przypadków typowania rzeczywiście można używać na tyle często, że zapomina się o problemie. Jednak tylko do czasu...Czytaj więcej »

przesada jest twoim wrogiem

Żaden z nas nie posiadł całej wiedzy, którą posiada obecnie, wraz z pierwszym kontaktem z programowaniem obiektowym. To oczywiste, że wszystkiego trzeba się nauczyć. Trwa to dłużej lub krócej, uczymy się na własnych błędach, doświadczeniu innych itp. Czasami odkrywamy "coś", co na zawsze zmienia nasz sposób postrzegania kodu. Zdarza się, że danego rozwiązania, konstrukcji etc. używaliśmy wcześniej, ale dopiero w pewnym momencie odkrywamy wszystkie tajemnice stojące za danym zagadnieniem, ich piękno i wartości. A przynajmniej tak nam się wydaje:)Czytaj więcej »

what's the problem?

Czasami zdarza nam się zauważyć w kodzie metody, które posiadają takie same deklaracje. Jest to nieuniknione, dziesiątki, setki i więcej tysięcy linii kodu sprawia, że niekiedy "powtórzenia" tego typu się zdarzają.Dlaczego "powtórzenia" w cudzysłowie? Ponieważ nie jest to wynik duplikacji logiki, a jedynie użycia języka w celu opisania danej funkcjonalności. Tylko czy rzeczywiście nie jest?Czytaj więcej »

Załóżmy, że w pliku application.ini mamy wpis:

; Paginator
paginator.linesperpage = 10

Jak się do niego dostać w aplikacji?

• w kontrolerze:

$bootstrap = $this->getInvokeArg('bootstrap');
$pConfig = $bootstrap->getOption('paginator');

•  gdziekolwiek:

$front = Zend_Controller_Front::getInstance();
$bootstrap = $front->getParam('bootstrap');
$pConfig = $bootstrap->getOption('paginator');

Polecenie:

Zend_Debug::dump($pConfig);

Daje wynik:

array(1) {
  ["linesperpage"] => string(2) "10"
}

Zend Framework ma to do siebie, że gdy obejrzymy zawartość plików jego biblioteki, zauważymy, że nagminnie korzysta z require_once. Pomimo, że wyrażenie to zabezpiecza  przed ponownym załadowaniem tego samego pliku do pamięci, to rozwiązanie ma swoje wady wydajnościowe. Za każdym razem, gdy parser PHP napotyka na swojej drodze require_once, czesze po dysku celem sprawdzenia czy dany plik istnieje. Nieważne, że ten plik został chwilę wcześniej załadowany do pamięci.

W przypadku, gdy w aplikacji opartej o zf używamy autoloadera, choćby poprzez wywołanie:

require_once 'Zend/Loader/Autoloader.php';
Zend_Loader_Autoloader::getInstance();

możemy zakomentować wszystkie wystąpienia w bibliotece Zenda wyrażenia require_once. Służy do tego np. zgrabna komenda:

cd /path/to/ZendFramework/library
find . -name '*.php' -not -wholename '*/Loader/Autoloader.php' \
      -not -wholename '*/Application.php' -print0 | \
      xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g'

Żeby nie być gołosłownym zrobiłem prosty test programem Apache Benchmark wywołując 10 tysięcy razy aplikację lokalnie utworzoną poprzez

zf create project zf-stat .

Po podlinkowaniu biblioteki frameworka wywołałem dwukrotnie polecenie:

ab -n 10000 localhost/stat-zf/public

Najpierw na „gołej” instancji Zend Framework 1.12.0, za drugim razem po zakomentowaniu require_once w bibliotece.

Zend Framework 1.12.0 z require_once:

Time taken for tests:   2.725 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Non-2xx responses:      10000
Total transferred:      5700000 bytes
HTML transferred:       3150000 bytes
Requests per second:    3669.87 [#/sec] (mean)
Time per request:       0.272 [ms] (mean)
Time per request:       0.272 [ms] (mean, across all concurrent requests)
Transfer rate:          2042.80 [Kbytes/sec] received

Zend Framework 1.12.0 bez require_once:

Time taken for tests:   2.003 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Non-2xx responses:      10000
Total transferred:      5700000 bytes
HTML transferred:       3150000 bytes
Requests per second:    4992.42 [#/sec] (mean)
Time per request:       0.200 [ms] (mean)
Time per request:       0.200 [ms] (mean, across all concurrent requests)
Transfer rate:          2778.98 [Kbytes/sec] received

Jak widać już przy tak trywialnym teście czas jego trwania wzrósł prawie o połowę, żądania wzrosły z liczby 3669.87 do 4992.42,  średni czas żądania spadł z 0.272 ms do 0.200 ms, a transfer wzrósł z 2042.80 [Kbytes/sec] do 2778.98 [Kbytes/sec].

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Półtora roku temu przedstawiłem Wam skomplikowany sposób sprawdzenia platformy/mobilnej przeglądarki za pomocą WURFL (Wireless Universal Resource File) w Zend Framework. Rozwiązanie to wymagało wielu zależności i nie było proste w obsłudze.

Tym razem coś o wiele prostszego. Wykorzystamy do tego wbudowaną w PHP funkcję get_browser(). Jedyne co potrzebujemy z zewnątrz jest to biblioteka browscap, która „nauczy” PHP rozpoznawania platform. Oto przepis:

1. Ściągamy browscap.ini na nasz serwer i zapisujemy jako /etc/php_browscap.ini.
2. Edytujemy php.ini dodając/od komentując:

   [browscap]
   browscap = /etc/php_browscap.ini
   

3. Teraz w PHP możemy w prosty sposób rozpoznać platformę, na której otworzona jest nasza strona:

   $browser = get_browser($request['http_user_agent'], true);
   $platform = isset($browser['platform']) ? $browser['platform'] : null;
   
   switch($platform) {
           case 'iOS':
                   $url = 'http://www.matipl.pl/site-for-ios';
                   break;
           case 'Android':
                   $url = 'http://www.matipl.pl/site-for-android';
                   break;
           case 'SymbianOS':
                   $url = 'http://www.matipl.pl/site-for-symbian';
                   break;
           case 'BlackBerry OS':
                   $url = 'http://www.matipl.pl/site-for-bb';
                   break;
           default:
                   $url = 'http://www.matipl.pl/';
                   break;
   }
   

Prawda, że prosto? Co jakiś czas możemy zaktualizować browscap, w którym co jakiś czas pojawia się „obsługa” nowych urządzeń.

PS: W minionym tygodniu ekipa PHP znów połatała błędy. Polecam update do PHP 5.4.8 i PHP 5.3.18.