aktuba.com

Понадобилось мне для тестов определять, с мобильного ли устройства зашел пользователь. Набросал простейший класс для себя, а потом (странно, что потом ) решил посмотреть готовые решения.

Честно, удивился. Большинство использует (или рекомендует использовать) детектор Яндекса. Кто-то юзает монстров, а кто-то вообще подобное покупает!

Для меня реально остается загадкой, как можно додуматься при каждом запросе клиента делать запрос по апи к яндексу. Я понимаю, что запросы простые и быстрые, но ведь еще есть накладные расходы на сам запрос.

Так же не понимаю, КТО покупает подобные скрипты. Если покупатель не программер — тебе скрипт не нужен, проще нанять программера. Если-же покупатель программер, то как он мог додуматься купить скрипт, а не сделать самому или хотя бы не поискать???

УРА! Нашел в бекапе одну из своих старых программ. Как-же приятно видеть, что я когда-то, давным-давно, подобное сделал! Вот теперь бы подобное в вебе реализовать — было бы классно. Нет js-спецов, желающих помочь?

Саша в твиттере подкинул интересную ссылку: новую парадигму создания микро-фреймворков, а именно — массиво-ориентированную парадигму (array-oriented programming). Кому лень идти по ссылке, вот пример реализации:

$app = array(
	'session' => array(),
	'request' => array(
		'method' => 'GET',
		'uri' => '',
		'data' => array()
	),

	'response' => array(
		'body' => '',
		'headers' => array()
	),

	'errors' => array(
		404 => function(&$request, &$response) {
			$response['body'] = '404 Not Found';
			$response['headers'][] = 'Status: 404';
		}
	),

	'routes' => array(
		'/' => function(&$request, &$response) {
			$response['body'] = 'GET /';
		},

		'/test' => function(&$request, &$response) {
			$response['body'] = 'GET /test';
		}
	),

	'route' => null,

	'bootstrap' => array(
		'request' => function(&$app) {
			if ($_SERVER['REQUEST_METHOD'] == 'POST') {
				$app['request']['is_post'] = true;
			}
			$app['request']['uri'] = '/' . trim($_SERVER['REQUEST_URI'], '/');
			$app['request']['method'] = strtoupper($_SERVER['REQUEST_METHOD']);
			$app['request']['data'] = $_REQUEST;
		},

		'router' => function(&$app) {
			$route = $app['request']['uri'];
			if (!isset($app['routes'][$route])) {
				$app['route'] = $app['errors'][404];
				return;
			}
			$app['route'] = $app['routes'][$route];
		}
	),

	'dispatch' => function(&$app) {
		$route = $app['route'];
		$route($app['request'], $app['response']);
	}
);

foreach ($app['bootstrap'] as $bootstrap) {
    $bootstrap($app);
}
$app['dispatch']($app);

foreach ($app['response']['headers'] as $header) {
    header($header);
}
if ($app['response']['body'] !== null) {
    echo $app['response']['body'];
}

Не правда-ли, выглядит очень интересно! Конечно-же, есть свои минусы и они довольно ощутимые, но иногда такой подход более чем полезен. Например, когда важны скорость выполнения и потребляемые ресурсы. Код выше, на локальной машине, дает следующие результаты:

time: 0.000189065933228 ms;
memory: 4216 b

Как вам в сравнении с ko3, например? )

Не так давно я представил набросок простейшего фреймворка, предназначеного для изучения новичками и для создания простейших сайтов. Комментарий, оставленный к тому посту уважаемым мною Иваном Броткиным, заинтриговал. Стало очень интересно, чего же можно добиться, если поднастроить ko3 на скорость работы. Интерес чисто академический, поэтому и настройки, по ходу дела, будут такие же. Единственное условие, которое я поставил для себя: фреймворк должен остаться полностью работоспособным, без ограничений!

Итак, начнем. Для начала, отключаем все, что можно: кеш, логирование, все доп.модули. Вывод из контролера в браузер делаем через echo, чтобы избежать использование доп. кода в самой кохане. Смотрим результат:

time: 0.0273728370667;
memory: 749360

Совсем-совсем не плохо, если сравнивать с ko3.2 и дефолтными настройками (напомню: time: 0.0946259498596; memory: 1330864). Но, данные параметры все-равно довольно высоки, поэтому идем дальше.

Тюнинг kohana 3.0 >

Давно хотел сравнить между собой обычные методы классов и статичные, но все руки не доходили. Сегодня вот столкнулся с приватным фреймворком, в котором ВСЕ методы и параметры статичные. Вообще все, т.е. нет ни одного обычного объекта! Откладывать сравнение было уже нельзя, чем я и занялся утром. Результаты неоднозначные, даже странные для меня, местами. В общем, «непоняно» что и как… На Ваш суд выношу результаты тестов, а Вы попробуйте мне объяснить почему результаты именно такие. Кстати, я не буду сравнивать размер используемой памяти, т.к. тут как-раз все понятно — статичные методы и свойства явно будут меньше кушать памяти. Это понятно.

Итак, начнем. Для начала, попробуем сравнить между собой «сферических конец в вакууме», т.е. классы-пустышки. Код у нас получится примерно такой:

<?php

class ClassStatic {

	public static function test() {
		;
	}

}

class ClassDinamic {

	public function test() {
		;
	}

}

$static = array();
$dinamic = array();

for ($count = 0; $count < 100; $count++) {
	$start = microtime(TRUE);
	for ($i = 0; $i <= 1000; $i++)
		ClassStatic::test();
	$static[$count] = microtime(TRUE) - $start;

	$start = microtime(TRUE);
	$obj = new ClassDinamic();
	for ($i = 0; $i <= 1000; $i++)
		$obj -> test();
	$dinamic[$count] = microtime(TRUE) - $start;
}

echo 'Static: min - ' . min($static) . '; max - ' . max($static) . '; avg - ' . array_sum($static) / 100 . "<br />\n";
echo 'Dinamic: min - ' . min($dinamic) . '; max - ' . max($dinamic) . '; avg - ' . array_sum($dinamic) / 100 . "<br />\n";

Сравниваем классы в php >