Работа для программистов http://job-interview.ru/articles вакансии, вопросы, статьи Sun, 27 Nov 2011 16:31:28 +0000 http://wordpress.org/?v=2.8 en hourly 1 Программист на фрилансе http://job-interview.ru/articles/post/332 http://job-interview.ru/articles/post/332#comments Tue, 31 May 2011 19:51:38 +0000 Pablo Monteagudo /articles/?p=332

В этой статье я хочу описать свой опыт работы на фрилансе.

Что за фриланс?

Может быть есть люди, которые не знают, что такое фриланс? “Freelance” буквально переводится как “внештатно”, соответственно “freelancer” — “внештатный сотрудник”. Обычно это подразумевает поиск заказов через интернет, выполнение их дома за компьютером (хотя некоторые ловко трудятся во время основной работы :) ) и оплату выполненной работы через интернет. Существуют специальные сайты — фриланс-биржы — на которых происходит общение заказчиков, имеющих какие-либо задания, и исполнителей, готовых эти задания выполнить.

А зачем это нужно?

Наверное каждый программист замечал, что работая постоянно, у него не хватает времени заниматься какими-то своими проектами. А различные идеи периодически приходят, и думаешь: “Вот было бы время, обязательно бы это реализовал”. Да и на работе бывают времена, что приходится заниматься неинтересными делами. Тем более в мои планы не входило всю жизнь работать “на дядю”, рано или поздно пришлось бы уходить на вольные хлеба, и во время особо скучного периода на тогдашней постоянной работе я и решил это сделать.

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

Биржи? Биржи. Биржи…

Фриланс-бирж существует множество, как российских, так и зарубежных, в итоге я зарегистрировался на трех — freelancer.com, free-lance.ru и weblancer.net.

freelancer.com я выбрал, так как прочитал довольно интересную статью, описывающую прелесть работы на ней. Здесь я решил представиться веб-студией, по идее такой подход вызывает больше доверия у заказчиков, придумал “конторе” название, сделал простенький логотип, зарегистрировался и начал осматриваться.
Если описать в общем, сайт представляет собой типичную фриланс-биржу – страницы разделов по возможным IT-работам, например создание сайтов “под ключ”, создание дизайнов, работа с различными CMS, написание скриптов, системное администрирование и т.д. Заказчик выбирает нужный ему раздел, создает проект, на который откликаются заинтересовавшиеся фрилансеры.

На freelancer.com ищут заказы очень много фрилансеров, среди которых немало выходцев из Азии. Качество работы большинства этих товарищей, как и знание английского языка, оставляет желать лучшего (кто не слышал про программистов-индусов :) ), но они берут ценами, иногда демпинг с их стороны вызывает даже не недоумение, а смех. Вполне реально найти “исполнителя” на сложный специфичный портал за сумму например 100$ и сроком исполнения 3 дня. И это предложение еще могут перебить!
Естественно, есть и мастера своего дела, с высочайшим профессионализмом, большим опытом и умением подойти к клиенту.

К сожалению, на этом сайте мне так и не удалось получить ни одного заказа, наверное из-за окончательной переориентации на отечественный рынок. Свою роль сыграли и не очень удовлетворительный английский, и разница во времени с многими заказчиками.

Российские биржи, на которых я зарегистрировался — free-lance.ru и weblancer.net. free-lance.ru – самая известная из отечественных, держит первенство по количеству проектов и активных фрилансеров. Содержит много платных услуг, жизнь без которых затруднена, например не имея pro-аккаунта можно подавать только три заявки на понравившиеся проекты в сутки. Но таким ограничением страдают все биржи, которые я встречал. Впрочем это мне не очень мешало, с первых дней мне хотелось насладится преимуществом выбора интересных заданий. К сожалению, появлялись они не так часто, как хотелось бы, а при подаче заявки меня всегда обходили более опытные исполнители, с отзывами и более долгим временем нахождения на сайте.

Про это стоит упомянуть подробнее. Практически все заказчики смотрят на количество отзывов, имеющихся у фрилансера, которые оставили прошлые работодатели. Хорошо выполнил работу — написали положительный, плохо, не выполнил или исчез — отритцательный. Наверное уже с 3-мя отритцательными отзывами лучше завести новый аккаунт, так же как и если первый отзыв — негативный. То же самое и с временем, прошедшим после регистрации, некоторые не доверяют людям, у которых оно меньше месяца. Сначала порой приходилось работать и за еду просто за отзыв.

Когда подходящий проект найден, встает задача, чтобы заказчик выбрал именно вас. Тут у каждого свой подход, кто-то просто называет цену и оставляет сообщение “пишите в личку”, кто-то строчит простыни текста, в подробностях расписывая все свои предыдущие достижения, кто-то выбирает нечто среднее. По-моему стоит писать, какие подобные задания уже приходилось выполнять и по-возможности дать понять, что понимаешь задание и чуть ли не начал его делать.

Но вот первый проект получен, наконец-то меня выбрали исполнителем! Обсудив все детали задания, пора начинать работать! Но, что все не так просто, стало понятно через пару проектов. ТЗ и детали нужно обговаривать ОЧЕНЬ подробно, выясняя все до последних мелочей, иначе дорабатывать и изменять казалось бы незначительные и неважные детали и наводить красоту по вкусу заказчика можно вечно, либо, неправильно поняв суть задания, вообще выбрать неверный путь решения задачи. Был случай, когда недели две работы потратились впустую из-за непонимания и несогласованности между мной и заказчиком, в итоге я потерял деньги, а клиент время, хорошо, что в результате разошлись мирно, без написания отритцательных отзывов друг другу.

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

Не биржей единой

Поиск заказов не ограничивается только биржами.
У многих заказчиков постоянно появляются новые задания, и если ты хорошо выполнил одно, наверняка следующее также достанется тебе, плюс этот заказчик будет рекомендовать тебя своим знакомым, у которых возникла необходимость в привлечении стороннего сотрудника.
Постепенно знакомые и бывшие коллеги узнают о твоей работе на фрилансе и заказы начинают приходить через них.
Через некоторое время я перестал заходить на биржи и выполнял только подобные задания, потому что они скорее всего будут интересные, с заказчиком уже сложились более-менее неплохие отношения, почти нет недоверия и настороженности, как у тебя, что прокатят с деньгами, так и у него, что работа не будет выполнена.

Также не стоит забывать про свои задумки, отводить какое-то время на них, даже если пока ни одна из них еще не приносит какой-либо ощутимой отдачи, ведь это только пока :) Главное, что для них находится время.

Ожидания и реальность

Для кого-то работать дома в кайф, но я знал, что постоянно находиться в четырех стенах мне будет затруднительно, однако утешал себя мыслью, что можно будет выйти, например, в парк и работать там. Но на практике зарядки ноутбука хватает не намного времени, у нетбука маленький экран, а на лавке в парке с этими девайсами неудобно сидеть. Если еще вспомнить, каким жарким было лето 2010, то можно понять, как я завидовал людям, сидящим в прохладных офисах с кондиционерами, тогда как дома был только плохо спасающий от этого ада вентилятор.

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

По поводу рабочего времени происходило примерно так, как я и думал: то работы нет, то работать приходится по ночам, не говоря уже про выходные. Если на постоянной работе знаешь, что в субботу-воскресенье отдыхаешь, на фрилансе все смешивается и иногда удивляешься радости друзей о том, что завтра выходной.
Можно безболезненно с утра покататься на велосипеде, посреди рабочего дня прерваться, например, на гантели или прогулку (это если нет срочной работы, конечно :D ).

Волнующий денежный вопрос. Честно говоря, когда я уходил на фриланс, то ожидал, что буду зарабатывать больше. Очень сложно назвать среднюю сумму заработка, в первые месяцы у меня выходило не более 10-15 тысяч ежемесячно.

Итого

Что же в итоге? Не жалею ли я о том, что ушел с постоянной работы на фриланс? Нет.
Сейчас я частично (5 часов в день) работаю в офисе на постоянной работе, которая нашла меня через фриланс, остальное время практически полностью посвящаю своим делам, лишь иногда откликаясь на работу от постоянных заказчиков, приобретенных на фрилансе.

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

]]> http://job-interview.ru/articles/post/332/feed 0 Ускоряем проект на Symfony через nginx+memcached http://job-interview.ru/articles/post/300 http://job-interview.ru/articles/post/300#comments Wed, 23 Feb 2011 15:11:09 +0000 tiger /articles/?p=300

Symfony — популярный фреймворк, использующий язык PHP, для ускорения процесса разработки web-приложений. Благодаря гибкой и продуманной структуре классов Symfony, программировать под этот фреймворк становится одним удовольствием, это действительно очень удобно.

Однако, плату за универсальность никто не отменял. И, хотя Symfony предоставляет обширные возможности для кэширования, оно не всегда спасает, особенно на нагруженных проектах и особенно на страницах, которые состоят из часто меняющихся блоков.

В этой статье я постараюсь описать минусы кэширования в Symfony и приемы их обхода.

Представьте ситуацию, когда есть страница, на которой данные могут меняться только раз в 1-2 суток, тогда мы смело можем ее закэшировать на 24 часа. В Symfony это делается очень просто установкой параметров в файле cache.yml для модулей:

enabled: true
with_layout: true
lifetime: 86400

Это означает, что раз в 24 часа при заходе одного пользователя страница будет перестраиваться, т. е. выполнять запросы к базе данных, исполнять код PHP, еще какие-то действия, после этого результат будет записан в кэш и отдан клиенту. После этого все последующие 24 часа каждый пользователь будет получать эту страницу из кэша — никаких запросов к базе, минимальное исполнение только самого необходимого кода. Красота!

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

Проблема в том, что блок с последними комментариями может обновиться как через минуту, так и через 2-3 часа, поэтому кэшировать всю страницу мы не можем, т. к. не понятно какое время жизни выставлять для кэша. Вообще это типичный случай, когда следует применять блочное кэширование, т. е. делим страницу на блоки (или компоненты в Symfony), каждому блоку задаем свои параметры кэширования.

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

Однако, есть другой способ применения кэширования для случая, описанного выше. Для этого нам понадобится (я также привожу описание установки нужного ПО, для тех, кому оно понадобится, все примеры я проверял у себя на Linux SUSE 11.3):

  • Nginx в качестве web-сервера

    Как установить и настроить Nginx

  • Фреймворк Symfony

    Как установить Symfony и настроить связку Nginx+Symfony

  • Memcached и расширение для PHP

    Как установить memcached и расширение PHP к нему.

Сейчас после открытия в браузере http://localhost мы видим страницу нашего проекта на Symfony.

Итак, у нас все есть для работы, начнем ускорять наш проект. За основу берется то, что Nginx умеет обращаться к memcached по ключу и отдавать значение, которое содержится по этому ключу, в качестве ответа web-сервера.

Memcached — это демон, который хранит данные в оперативной памяти, обращаться к этим данным мы можем по определенному ключу.

Воспользуемся всеми вышеописанными возможностями memcached и nginx. В качестве ключа в memcached мы будем использовать URL-адрес страниц нашего сайта, а в качестве содержимого HTML страницы. Теперь нам нужно настроить nginx так, чтобы он при наличии в memcached значения (html) по ключу (url страницы) отдавал его сразу же в ответе клиенту, в противном случае запрос должен передаваться к Symfony, который его обрабатывает, сохраняет в memcached и отдает ответ для клиента. Таким образом, если в данный момент страница не в кэше, то его добавит в кэш Symfony, и при следующем запросе к этой странице ответ будет получен еще на стороне nginx, не доходя даже до Symfony.

Итак, добавим в наш проект возможность записи ответа сервера в memcached. Для этого воспользуемся механизмом фильтров в Symfony. Создадим в директории lib нашего проекта поддиректорию cache, а в ней создадим файл sfHtmlCacheFilter.class.php. Содержимое этого файла будет следующее: 

<?php
 
class sfHtmlCacheFilter extends sfFilter
{
    private static $replacement = array();
    private static $multi_replacement = array();
    private static $pageLimit = array();
    private static $host = '';
 
    /**
     * Метод вызывается после того, как страница полностью сформирована,
     * здесь содержимое страницы записывается в memcached, если она указана в конфиге html_cache.yml.
     *
     * @param <Object> $filterChain
     * @return <NULL>
     */
    public function execute ($filterChain)
    {
        $filterChain->execute();
 
        $response = $this->getContext()->getResponse();
        $request = $this->getContext()->getRequest();
 
	// Если в наших конфигах прописано не использовать кэширование или мы находимся в debug-режиме, то прекращем выполнение.
	// Здесь также проверяется код ответа - если он не равен 200, то прекращем выполнение.
        if (
          (!sfConfig::get('sf_cache') || count($request->getGetParameters()) || count($request->getPostParameters()))
          ||
          (sfConfig::get('sf_debug') || !sfConfig::get('sf_no_script_name') || $response->getStatusCode() != 200)
        )
        {
          return;
        }
 
        $uri = $this->getContext()->getRouting()->getCurrentInternalUri();
        self::$host = 'http://'.$request->getHost();
	// Получаем запрошенный URI - будущий ключ для memcached
        $webUri = str_replace(self::$host, '', $request->getUri());
        $uriCacheParams = null;
	// Получаем из конфига страницы, которые подлежат кэшированию
        $config = self::getConfig();
        foreach($config as $item)
        {
            foreach($item as $key=>$uriParams)
            {
                $routing_uri = preg_replace('/^(.*)\?.*$/i', '$1', $uri);
		// Сравниваем запрошенный URI с записями в конфиге
                if(preg_match('#^'.$key.'$#', $webUri))
                {
                    $uriCacheParams = $uriParams;
                    break;
                }
            }
 
	    // Если запрошенная страница есть в конфиге, то прекращаем цикл
            if($uriCacheParams)
            {
                break;
            }
        }
        $webUri = self::_decodeUri($webUri);
        if ($uriCacheParams && $response->getStatusCode() == '200')
        {
	    // Записываем содержимое ответа в кэш
            self::setUri(self::$host.$webUri, $response->getContent(), $uriCacheParams['lifetime']);
        }
 
        return;
    }
 
    /**
     * Получить конфиг тэгов
     *
     * @return <Array>
     */
    private static function getConfig() {
        $conf = sfYaml::load(sfConfig::get('sf_config_dir') . '/html_cache.yml');
 
        return $conf;
    }
 
    /**
     * Вызывается из методов save() моделей,
     * удаляет из кэша все страницы, зависящие от заданной модели
     *
     * @param <Object> $model - объект, для которого вызывается метод save в модели
     */
    public static function deleteCache($model)
    {
        $request = sfContext::getInstance()->getRequest();
        $model_name = get_class($model);
        $config = self::getConfig();
 
        $arUri = array();
 
        // Получаем страницы из конфига по этой модели
        $arCacheParam = $config[$model_name];
        self::$host = 'http://'.$request->getHost();
        // Обходим в цикле страницы, строим из них ключи для memcache
        foreach($arCacheParam as $uri=>$param)
        {
            self::$replacement = array();
            self::$multi_replacement = array();
            self::$pageLimit = array();
 
            $pageLimit = null;
            $attr = (isset($param['attributes']) ? $param['attributes'] : null);
            settype($attr, 'array');
            foreach($attr as $prop)
            {
                $method = 'get'.$prop;
                $value = false;
                /**
                 * method_exists не работает для Doctrine,
                 * но работает для Propel, is_callable всегда будет
                 * возвращать true для Doctrine, поэтому существование
                 * метода проверяется таким образом.
                 */
                try {
                        $value = $model->$method();
                }
                catch (Exception $e) {}
 
                if($value !== false)
                {
                    if (is_string($value) && strpos($value, ' ') !== false) {
                        $value = self::_decodeUri($value, false);
                    }
                    self::$replacement[] = $value;
                }
                elseif(preg_match('/^pageLimit:(\d+)$/', $prop, $matches))
                {
                    $pageLimit = $matches[1];
                    self::$replacement['pageLimit'] = range(1, $pageLimit);
                }
            }
 
            $isCachable = true;
            $beforeDeleteCache = (isset($param['beforeDeleteCache']) ? $param['beforeDeleteCache'] : null);
            settype($beforeDeleteCache, 'array');
            foreach($beforeDeleteCache as $callback)
            {
                $method = $callback;
                $isCachable = $model->$method();
            }
 
            if($isCachable)
            {
                $uri = preg_replace_callback('/\(.*\)/U', array('self', 'replace_attr_callback'), $uri);
                if(self::$multi_replacement)
                {
                    self::replace_multi_attr(self::$multi_replacement, $uri, $arUri);
                }
                else
                {
                    $arUri[] = self::$host.$uri;
                }
            }
        }
 
        // Удаляем массив страниц из memcached
        if($arUri)
        {
            self::deleteUri($arUri);
        }
    }
 
    /**
     * Используется для парсинга конфига при удалении страницы из memcached
     *
     * @param <Array> $matches
     * @return <String>
     */
    private static function replace_attr_callback($matches)
    {
        $expr = $matches[0];
        $arKeys = array_keys(self::$replacement);
        $key = $arKeys[0];
        if(!is_array(self::$replacement[$key]) && $key !== 'pageLimit' && isset(self::$replacement[$key]) && preg_match('/'.$expr.'/', self::$replacement[$key]))
        {
            $expr = self::$replacement[$key];
        }
        else
        {
            self::$multi_replacement[] = self::$replacement[$key];
            $expr = '%MULTI_REPLACEMENT_'.(count(self::$multi_replacement) - 1).'%';
        }
 
        unset(self::$replacement[$key]);
 
        return $expr;
    }
 
    /**
     * Используется для парсинга конфига при удалении страницы из memcached
     *
     * @param <Array> $attr
     * @param <String> $uri
     * @param <Array> $arUri
     * @param <Integer> $key
     */
    private static function replace_multi_attr($attr, $uri, &$arUri, $key = 0)
    {
        if(isset($attr[$key]))
        {
            foreach($attr[$key] as $ind=>$i)
            {
                self::replace_multi_attr($attr,
                                str_replace('%MULTI_REPLACEMENT_'.$key.'%', $i, $uri),
                                $arUri,
                                $key+1);
            }
        }
        if($key == count($attr))
        {
            $arUri[] = self::$host.$uri;
        }
    }
 
    /**
     * Возвращает объект для работы с memcached.
     *
     * @return <Object>
     */
    private static function getMemcache()
    {
        $memcache = new Memcache();
        $con = $memcache->connect('127.0.0.1', 11211);
	return $memcache;
    }
 
    /**
     * Записываем содержимое страницы в memcached
     *
     * @param <String> $uri - ключ в memcached
     * @param <String> $data - значение в memcached
     * @param <Integer> $lifetime - время жизни кэша
     */
    private static  function setUri($uri, $data, $lifetime)
    {
	$memcache = self::getMemcache();
	$memcache->set($uri, $data, 0, $lifetime);
    }
 
    /**
     * Удаляет страницу из memcached
     *
     * @param <Array> $arUri - массив ключей memcached,
     * которые следует удалить
     */
    private static function deleteUri($arUri)
    {
        settype($arUri, 'array');
        $memcache = self::getMemcache();
        foreach($arUri as $uri)
        {
            $memcache->delete($uri);
        }
    }
 
 
    /**
     * Метод декодирует URI через rawurldecode,
     * но символ пробела оставляет в прежнем виде,
     * т.к. nginx его не декодирует в своей переменной $uri
     *
     * @param <string> $uri
     * @param <boolean> $decode
     * @return <string>
     */
    private static function _decodeUri($uri, $decode = true)
    {
        $url = ($decode ? rawurldecode($uri) : $encodedUri);
 
        return str_replace(' ', '%20', $url);
    }
}

Пока нас будет интересовать только первый метод класса execute. Он вызывается после того, как закончено формирование страницы, в этом методе у нас есть возможность обратиться к содержимому страницы, еще до того, как она отправлена клиенту.

Все, что делается в методе execute — это получение текущего адреса страницы, проверка его в конфиге html_cache.yml и, если он там есть, записываем содержимое в memcached.

Теперь создадим сам конфиг html_cache.yml и положим его в папку config нашего проекта: 

Index:
  /: { lifetime: 86400 }

Здесь мы задаем адрес запрошенной страницы («/» – запрос главной страницы сайта), в фигурных скобках перечислены параметры кэширования, мы указали время жизни кэша 86400 секунд, т. е. сутки. Параметр Index сейчас используется только лишь в качестве группировки адресов страниц, но здесь можно также указывать названия моделей Symfony, об этом будет рассказано ниже.

По части Symfony у нас почти все готово, осталось включить использование кэширования и активировать наш фильтр.

Чтобы включить кэширование для секции prod прописываем в файле apps/frontend/config/settings.yml (изменения выделены жирным шрифтом): 

1
2
3
4
5

prod:
  .settings:
    no_script_name:         true
    cache:               true
    logging_enabled:        true

А теперь активируем фильтр, добавляем в файл apps/frontend/config/filters.yml пару строчек:

1
2
3
4
5
6
7
8
9
10

rendering: ~
security:  ~
 
# insert your own filters here
 
htmlcache:
    class: sfHtmlCacheFilter
 
cache:     ~
execution: ~

Тем самым мы активировали наш класс-фильтр.

Теперь сбрасываем кэш Symfony: 

# php symfony cache:clear

И заходим на страницу http://localhost/ . Если все правильно сделали главная страница нашего сайта должна оказаться в memcached, проверяем: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

# telnet localhost 11211
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get http://localhost/
VALUE http://localhost/ 0 2026
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
 
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title></title>
<link rel="stylesheet" type="text/css" media="screen" href="/css/main.css" />

<link rel="stylesheet" type="text/css" media="screen" href="/sf/sf_default/css/screen.css" />
 
<link rel="shortcut icon" href="/favicon.ico" />

 
<!--[if lt IE 7.]>
<link rel="stylesheet" type="text/css" media="screen" href="/sf/sf_default/css/ie.css" />

<![endif]-->
 
</head>
<body>
<div class="sfTContainer">
  <a href="http://www.symfony-project.org/"><img alt="symfony PHP Framework" class="sfTLogo" src="/sf/sf_default/images/sfTLogo.png" height="39" width="186" /></a>

<div class="sfTMessageContainer sfTMessage">
  <img alt="ok" class="sfTMessageIcon" src="/sf/sf_default/images/icons/ok48.png" height="48" width="48" />  <div class="sfTMessageWrap">

    <h1>Symfony Project Created</h1>
    <h5>Congratulations! You have successfully created your symfony project.</h5>
  </div>
</div>
<dl class="sfTMessageInfo">

  <dt>Project setup successful</dt>
  <dd>This project uses the symfony libraries. If you see no image in this page, you may need to configure your web server so that it gains access to the <code>symfony_data/web/sf/</code> directory.</dd>
 
  <dt>This is a temporary page</dt>

  <dd>This page is part of the symfony <code>default</code> module. It will disappear as soon as you define a <code>homepage</code> route in your <code>routing.yml</code>.</dd>

 
  <dt>What's next</dt>
  <dd>
    <ul class="sfTIconList">
      <li class="sfTDatabaseMessage">Create your data model</li>

      <li class="sfTColorMessage">Customize the layout of the generated templates</li>
      <li class="sfTLinkMessage"><a href="http://www.symfony-project.org/doc">Learn more from the online documentation</a></li>
    </ul>

  </dd>
</dl>
</div>
</body>
</html>
 
END
quit
Connection closed by foreign host.

Отлично! Теперь наш проект может перед отдачей ответа клиенту записывать в memcached HTML страниц.

Ну а теперь осталось настроить nginx, чтобы он мог сам отвечать клиенту, если запрошенная страница присутствует в memcached.

Для этого нам надо добавить еще один upstream для memcached в конфиг nginx и задать правила для проксирования в него запросов. Вот каким должен получиться конфиг для Nginx (изменения выделены жирным шрифтом): 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132

worker_processes  1;
 
 
events {
    worker_connections  1024;
}
 
 
http {

    include       mime.types;
    default_type  application/octet-stream;
 
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '

                      '"$http_user_agent" "$http_x_forwarded_for"';
 
    access_log  logs/access.log  main;
    error_log  logs/error.log info;
 
    sendfile        on;
    keepalive_timeout  65;

 
    upstream memcached_backend {
	server 127.0.0.1:11211;
    }
 
    upstream fcgi_www {
	server 127.0.0.1:9000;
    }

 
    server {
        listen       80;
        server_name  localhost;
 
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {

            root   html;
        }
 
	root /srv/www/symfony/web; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/web
 

	location ~ "^(/css/|/images/|/js/|/uploads/)" {
	    expires 3d;
	}
 
	location /sf/ {
	    root /srv/www/symfony/lib/vendor/symfony/data/web; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/lib/vendor/symfony/data/web

	}
 
	location / {
	    fastcgi_param REQUEST_URI            $request_uri;
	    fastcgi_param DOCUMENT_URI           $document_uri;
	    fastcgi_param DOCUMENT_ROOT          $document_root;
	    fastcgi_param GATEWAY_INTERFACE      CGI/1.1;
	    fastcgi_param SERVER_SOFTWARE        nginx/$nginx_version;
	    fastcgi_param REMOTE_ADDR            $remote_addr;
	    fastcgi_param REMOTE_PORT            $remote_port;
	    fastcgi_param SERVER_ADDR            $server_addr;
	    fastcgi_param SERVER_PORT            $server_port;
	    fastcgi_param SERVER_NAME            $server_name;
	    fastcgi_param SERVER_PROTOCOL        $server_protocol;
	    fastcgi_param CONTENT_TYPE           $content_type;
	    fastcgi_param CONTENT_LENGTH         $content_length;
	    fastcgi_param HTTP_ACCEPT_ENCODING   gzip,deflate;
	    fastcgi_param QUERY_STRING           $query_string;
	    fastcgi_param REDIRECT_STATUS        200;
	    fastcgi_param REQUEST_METHOD         $request_method;
	    fastcgi_param SCRIPT_FILENAME        /srv/www/symfony/web/index.php; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/web/index.php

	    fastcgi_param SCRIPT_NAME            /index.php;
	    fastcgi_param PATH_INFO              $request_uri;
 
            # Если это POST-запрос, то передаем обработку сразу в Symfony
	    if ($request_method = POST) {

		fastcgi_pass  fcgi_www;
		break;
	    }
 
           # Если на предыдущем шаге мы не вышли из location'а, то это GET-запрос.
           # Устанавливаем ключ для memcached, по которому будем искать значение
	    set $memcached_key "http://$host$uri";
           # Задаем upstream для memcached

	    memcached_pass  memcached_backend;
 
           # Устанавливаем тип содержимого, полученного от memcached, у нас хранится HTML
	    default_type text/html;
           # Указываем nginx'у переходить в именованный location @symfony в случае отсутствия ключа 
           # в memcached или в случае возникновении ошибки при запросе к memcached
	    proxy_intercept_errors  on;
	    error_page 404 502 = @symfony;
	}

 
       # Здесь описан именованный location, куда nginx переходит в случае отсутствия ключа или                                          
       # возникновении ошибки при обращении к memcached. Здесь просто перечислены параметры 
       # fastcgi так же, как было сделано выше.
	location @symfony {
	    fastcgi_param REQUEST_URI            $request_uri;
	    fastcgi_param DOCUMENT_URI           $document_uri;
	    fastcgi_param DOCUMENT_ROOT          $document_root;
	    fastcgi_param GATEWAY_INTERFACE      CGI/1.1;
	    fastcgi_param SERVER_SOFTWARE        nginx/$nginx_version;
	    fastcgi_param REMOTE_ADDR            $remote_addr;
	    fastcgi_param REMOTE_PORT            $remote_port;
	    fastcgi_param SERVER_ADDR            $server_addr;
	    fastcgi_param SERVER_PORT            $server_port;
	    fastcgi_param SERVER_NAME            $server_name;
	    fastcgi_param SERVER_PROTOCOL        $server_protocol;
	    fastcgi_param CONTENT_TYPE           $content_type;
	    fastcgi_param CONTENT_LENGTH         $content_length;
	    fastcgi_param HTTP_ACCEPT_ENCODING   gzip,deflate;
	    fastcgi_param QUERY_STRING           $query_string;
	    fastcgi_param REDIRECT_STATUS        200;
	    fastcgi_param REQUEST_METHOD         $request_method;
	    fastcgi_param SCRIPT_FILENAME        /srv/www/symfony/web/index.php; #%ПУТЬ_ДО_ВАШЕГО_ПРОЕКТА%/web/index.php

	    fastcgi_param SCRIPT_NAME            /index.php;
	    fastcgi_param PATH_INFO              $request_uri;
	    fastcgi_pass  fcgi_www;
	}
    }
 
}

Теперь проверяем нет ли ошибок в конфигах Nginx после внесения изменений: 

# /etc/init.d/nginx configtest
the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful

И говорим Nginx, чтобы он перечитал конфиг: 

# /etc/init.d/nginx reload
Reloading nginx:  reloaded

Проверяем! Заходим на страницу http://localhost/ , она у нас уже должна лежать в memcached. Лично я в своем браузере Mozilla Firefox даже на примере такой простой странички вижу, что она стала загружаться гораздо быстрее!

Но не будем доверять всему тому, что видим. Проведем небольшой бенчмарк, в этом нам поможет утилита ab2 — инструмент от разработчиков web-сервера Apache.

Сначала закомментируем наши настройки в Nginx, чтобы он перенаправлял все на Symfony.

Вносим следующие изменения в наш конфиг для Nginx, начиная с 71-й строки: 

71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

	    fastcgi_param SCRIPT_NAME            /index.php;
	    fastcgi_param PATH_INFO              $request_uri;
	    fastcgi_pass  fcgi_www;
 
#	    if ($request_method = POST) {

#		fastcgi_pass  fcgi_www;
#		break;
#	    }
 
#	    set $memcached_key "http://$host$uri";
#	    memcached_pass  memcached_backend;
 
#	    default_type text/html;
#	    proxy_intercept_errors  on;

#	    error_page 404 502 = @symfony;
	}
 
	location @symfony {

Затем стандартные команды: 

# /etc/init.d/nginx configtest
the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful
# /etc/init.d/nginx reload
Reloading nginx:  reloaded

И запускаем утилиту от Apache, отправим на наш сайт 1000 запросов, причем 10 будем выполнять параллельно: 

# ab2 -n 1000 -c 10 http://127.0.0.1:80/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
 
Server Software:        nginx/0.8.54
Server Hostname:        127.0.0.1
Server Port:            80
 
Document Path:          /
Document Length:        2026 bytes
 
Concurrency Level:      10
Time taken for tests:   26.412 seconds
Complete requests:      1000
Failed requests:        646
   (Connect: 0, Receive: 0, Length: 646, Exceptions: 0)
Write errors:           0
Non-2xx responses:      646
Total transferred:      1142110 bytes
HTML transferred:       964622 bytes
Requests per second:    37.86 [#/sec] (mean)
Time per request:       264.116 [ms] (mean)
Time per request:       26.412 [ms] (mean, across all concurrent requests)
Transfer rate:          42.23 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     0  264 349.9      3     827
Waiting:        0  264 349.9      3     810
Total:          1  264 349.9      3     827
 
Percentage of the requests served within a certain time (ms)
  50%      3
  66%    703
  75%    713
  80%    716
  90%    748
  95%    788
  98%    790
  99%    796
 100%    827 (longest request)

У меня после таких тестов отваливался через некоторое время fastcgi. Во время выполнения ab2 попробуйте проверить загрузку страницы в браузере — можно наблюдать постепенное нарастание тормозов при загрузке страницы.

Итак, если вас настигла беда с fastcgi, как и у меня, то запускаем его снова: 

php-cgi -a -b 127.0.0.1:9000 -c /etc/php5/fastcgi/php.ini

Далее убираем наши комментарии, сделанные перед запуском теста, релоадим nginx и запускаем ab2 с теми же параметрами: 

# /etc/init.d/nginx configtest
the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful
# /etc/init.d/nginx reload
Reloading nginx:  reloaded
# ab2 -n 1000 -c 10 http://127.0.0.1:80/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
 
Server Software:        nginx/0.8.54
Server Hostname:        127.0.0.1
Server Port:            80
 
Document Path:          /
Document Length:        2026 bytes
 
Concurrency Level:      10
Time taken for tests:   0.337 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      2170000 bytes
HTML transferred:       2026000 bytes
Requests per second:    2971.65 [#/sec] (mean)
Time per request:       3.365 [ms] (mean)
Time per request:       0.337 [ms] (mean, across all concurrent requests)
Transfer rate:          6297.35 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.4      0       3
Processing:     1    3   0.6      3       5
Waiting:        0    3   0.6      3       4
Total:          1    3   0.5      3       6
 
Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      4
  80%      4
  90%      4
  95%      4
  98%      4
  99%      4
 100%      6 (longest request)

Тут даже говорить нечего, все сказано в первом и втором выводах ab2. Достаточно взглянуть хотя бы на параметр «Time taken for tests», который показывает общее время проведения тестов. В первом случае он равен 26.412 секунд, во втором - 0.337 секунд. Прирост производительности почти в 80 раз!

Конечно, тестирование на локальном компьютере — это не есть тестирование в условиях, приближенных к реальным, однако какое-то представление оно все же дает.

А теперь вернемся к примеру, который был описан в самом начале статьи. Есть страница с постоянным контентом и есть блок с последними комментариями.

Как кэширование, которое мы только что внедрили в Symfony, поможет нам с кэшированием такой страницы? Пока никак. Наш кэш живет только какое-то определенное время, указанное в параметре lifetime, поэтому блок с комментариями будет обновляться только, когда истечет время жизни кэша. Но нас это не устраивает, нужно, чтобы страница обновлялась каждый раз после того, как добавился комментарий. Хорошо бы после добавления комментария удалять из кэша страницу.

Зададимся вопросом: «В какой момент у нас обычно должен обновляться кэш?». Обычно в момент, когда что-то меняется в базе данных. При чем, если изменения производятся в таблице, где хранятся комментарии, то обновляться должны страницы, где выводятся блоки, связанные с комментариями.

Для начала подключим к нашему проекту на Symfony базу данных. Не имеет значения какую базу данных использовать. Если вы знакомы с Symfony, то без труда сможете подключить свою базу данных. В своих же примерах я использую MySQL, пользователь root с паролем secretpass, имя базы данных — symfony. 

# mysqladmin -uroot -psecretpass create symfony
# php symfony configure:database "mysql:host=localhost;dbname=symfony" root secretpass

Теперь опишем нашу будущую базу данных в Symfony, для этого отредактируем файл config/doctrine/schema.yml: 

Comment:
  columns:
    text: { type: string(255), notnull: true }

Далее воспользуемся готовыми инструментами Symfony и сгенерируем код для моделей, SQL для базы данных. 

# php symfony doctrine:build --model
# php symfony doctrine:build --sql
# php symfony doctrine:insert-sql

Последняя команда выполняет SQL, чтобы создать необходимые таблицы в базе данных. Вместо этих трех команд можно было бы выполнить php symfony doctrine:build —all, которая выполняет те же 3 действия, но за один раз.

Теперь сгенерируем стандартную функциональность для добавления, удаления, редактирования и просмотра списка объектов модели: 

# php symfony doctrine:generate-module --with-show --non-verbose-templates frontend comment Comment

Здесь мы говорим сгенерировать код для нового модуля comment, код генерируется для существующей модели Comment.

Далее необходимо переопределить метод save() для моделей, участвующих в кэшировании. У нас это одна модель Comment, поэтому открываем файл lib/model/doctrine/Comment.class.php и добавляем в класс Comment метод save(): 

class Comment extends BaseComment
{
    public function save(Doctrine_Connection $conn = null) {
        parent::save($conn);
        sfHtmlCacheFilter::deleteCache($this);
    }
}

Мы добавили метод save(), который переопределяет метод save() класса Doctrine_Record. В нашем методе мы вызываем метод save() родительского класса, которым и окажется Doctrine_Record::save().

Далее вызывается метод нашего класса-фильтра sfHtmlCacheFilter::deleteCache($this), которому в качестве параметра передается сохраняемый объект. Таким образом, этот новый метод не делает ничего нового, кроме как добавляется метод для очистки кэша при каждом сохранении объекта.

Удаляем кэш Symfony, чтобы наши изменения вступили в силу. 

# php symfony cache:clear

Все, теперь зайдем по адресу http://localhost/comment и увидим сгенерированную Symfony страницу. Нажимаем на ссылку «New», добавляем первую запись, возвращаемся назад к списку и видим только что добавленный комментарий.

Выше уже упоминалось, что в конфиге html_cache.yml можно прописывать зависимости страниц от моделей. Пришло время рассказать об этом подробнее.
Настройки в файле html_cache.yml используется следующим образом.

Перед отдачей любой страницы клиенту проверяется наличие адреса этой страницы в конфиге. Если он есть, то происходит запись содержимого страницы в кэш.
При сохранении модели вызывается метод класса-фильтра для удаления из кэша страниц, зависящих от текущей модели. Модели перечислены, как элементы первого уровня, на втором уровне перечислены зависящие от этих моделей адреса страниц.

Сейчас у нас в файле html_cache.yml на первом уровне прописана несуществующая модель Index, на втором уровне прописана главная страница. Т. к. модели Index у нас нет, то эта настройка просто говорит о том, что неоходимо записывать в кэш содержимое главной страницы, но никакого удаления ее из кэша не происходит.

Для такой главной страницы это и не нужно, т. к. там выводится всегда одна и та же информация. А вот со страницей списка комментариев ситуация иная — если для нее мы применяем кэширование, то необходимо удалять кэш этой страницы при каждом добавлении комментария.

Добавим такую настройку. Страница со списком комментариев располагается по адресу http://localhost/comment. Добавляем в файл config/html_cache.yml следующую запись: 

Comment:
  /comment: { lifetime: 86400 }

Теперь наша страница http://localhost/comment будет отдаваться клиенту еще на стороне nginx при наличии ее в кэше. В противном случае nginx передаст управление Symfony, который сформирует и запишет содержимое страницы в кэш.

Таким образом, мы организовали зависимость страниц от изменяющихся моделей — при изменении определенных моделей очищается кэш зависящих от этих моделей страниц.

В файле html_cache.yml можно использовать регулярные выражения, а также подставлять в адреса страниц результаты выполнения методов объектов. Применим кэширование к детальным страницам комментариев, которые располагаются по адресам вида - http://localhost/comment/show/id/1 .

Добавим к модели Comment следующую зависимость: 

1
2
3
4

Comment:
  /comment: { lifetime: 86400 }
  /comment/show/id/(\d+): { lifetime: 86400, attributes: [Id] }

Здесь мы указали в адресе регулярное выражение, которое пропускает только числовые значения ID комментариев. Мы также указали новый параметр attributes, который является массивом. В этом массиве объявляются методы модели, возвращаемые значения которых будут подставлены по порядку вместо регулярных выражений, заключенных в скобки. Причем методы могут возвращать не только обычные значения, но и массивы, в этом случае для удаления из кэша будет сформирован массив адресов страниц.

В данном примере вместо регулярного выражения (\d+) будет подставлен результат вызова метода getId() для объекта модели Comment. Это справедливо только при сохранении объекта и удалении кэша для него. При добавлении страницы в кэш будет произведено лишь сравнение текущего адреса страницы с регулярным выражением /comment/show/id/(\d+) и, если адрес пройдет проверку, то страница добавится в кэш.

После произведенных изменений в файле html_cache.yml страницы вида http://localhost/comment/show/id/1 постигнет участь предыдущих рассматриваемых страниц — они будут писаться в кэш.

Помимо параметров lifetime и attributes можно использовать параметр beforeDeleteCache, в который передается название метода модели (полное название). Этот метод должен возвращать true или false. При получении false кэш для записи с этим параметром удаляться не будет.

На этом все. Теперь наш проект на Symfony стал не просто быстрым, а мегабыстрым. Ответы клиент получает не от php-скриптов на сервере и даже не с диска, а из памяти сервера.

Спасибо за внимание! Чтобы ваши сайты всегда летали!

UPD: Спасибо Sergei за найденную ошибку. Все описанное работало только с латинскими буквами в url'е, но не работало с русскими. Внесены нужные изменения в класс-фильтр для Symfony, а также в конфиге nginx в качестве ключа для memcached теперь используется переменная $uri, а не $request_uri

]]> http://job-interview.ru/articles/post/300/feed 0 Как я проводил собеседование http://job-interview.ru/articles/post/290 http://job-interview.ru/articles/post/290#comments Sun, 23 Jan 2011 17:44:01 +0000 tiger /articles/post/290 Вот уже прошло почти полтора года, как я в поисках работы посещал собеседования в разных компаниях, после чего мною была написана статья Нужны ли логические задачи на собеседованиях?. И вот совсем недавно мне самому пришлось набирать команду программистов и проводить с ними собеседования. Как вы могли бы догадаться, собеседования без задач на логику. ;)

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

Цель: найти 2-х программистов, один должен быть опытным, другой начинающим.

Хочу сразу сказать, эта статья не содержит никаких советов о том, как проводить «правильное собеседование». Здесь я рассказываю о своем опыте проведения собеседований и, как показало время, в моем случае эти собеседования оказались правильными, т.к. я подобрал тех людей, которых и хотел. Но обо всем по порядку.

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

Пришлось быстро вспомнить какие вопросы задавали мне на собеседованиях, поискать по интернету и т.д. В общем кое-как я подготовил 7 вопросов. 3 вопроса, на мой взгляд, были вообще элементарными, 2 — довольно простыми при наличии опыта, еще 2 — SQL-запросы, не из самых легких.

Итак, начали собеседование, я дал 15 минут на подготовку ответов на вопросы. По истечении этого времени кандидат дал 3 правильных ответа из 7 — 1 из категории элементарных, 2 из категории «простые при наличии опыта».

Такие ответы не давали полного понимания о знаниях человека. Вроде бы ответил на вопросы, которые должны были показать его опыт, но не ответил на 2 из 3-х элементарных вопросов. А что с SQL? Ответы были неправильными, но и вопросы не из легких.

Очевидно, что мною были неправильно подготовлены вопросы, они не позволяли понять знания кандидата. К слову сказать, в этот же день приходил еще один соискатель, с ним была примерно та же история — правильно ответил на 2 простых вопроса и 1 на проверку опыта.

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

Я решил, что все вопросы нужно разделить на несколько частей:

  1. Пара простейших вопросов, с которыми справится любой программист.

    2. Чтобы сразу же выявить тех, кто по своим знаниям нам точно не подходит. Должен сказать, что из всех собеседуемых таких оказалось 3 человека. С ними я сразу прощался, не переходя к более сложным вопросам.

  2. Вопросы, на которые ответит любой программист с опытом.

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

  3. Немного теории и вопросы по проектированию.

    4. Эта часть вопросов должна была показать на сколько человек способен работать самостоятельно, сможет ли он без тотального контроля решить задачу наиболее оптимальным способом. Сюда относятся составление правильной структуры БД еще до начала реализации, написание кода, который хорошо впишется в существующий. И не забываем про нагрузки — задача может быть реализована, прекрасно работать на девелоперских серверах, но после выката на продакшн может положить весь сайт.

  4. Несложные SQL-запросы.

    5. Ну и немного поломать мозг. Но только совсем слегка. Эта часть вопросов на составление SQL-запросов, все запросы довольно простые и при знании операторов SQL решаются быстро. Также здесь можно понять на сколько правильно человек выбирает методы решения — при незнании каких-то возможностей SQL, некоторые начинали составлять мегазапросы с огромным количеством подзапросов, join’ов и т.д.

  5. Вопросы не для всех.

    6. Эти вопросы я задавал только тем, кто с легкостью ответил на все предыдущие вопросы. Если они для соискателя очень простые, то хочется копнуть глубже и понять на сколько хороши его знания. Как правило, положительное решение по кандидатам, дошедших до этой части вопросов, у меня формировалось еще в середине собеседования.

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

По началу после 1-2 собеседований я корректировал часть вопросов — некоторые вопросы были не понятны соискателям (криво составлены мной), некоторые я просто заменял, считая, что новые лучше подойдут для собеседования. В результате у меня сформировался список вопросов, с которым я ходил на каждое собеседование.

Для начала человек должен был ответить на 2 простых вопроса из 1-й части:

  1. jQuery
    • выбрать элементы с атрибутом id=”myID”
    • выбрать элементы с атрибутом class=”myClass”
    • выбрать все input’ы с атрибутом id=”myID”, которые находятся внутри <div class=”myClass”>
  2. Javascript

    Необходимо выполнить команду alert(’!’) перед отправкой данных формы нажатием кнопки “ОК”.

    Какой из перечисленных фрагментов кода позволит решить поставленную задачу?

    • 1
2
3
4

       <FORM ACTION="test.pl" onSubmit="alert(’!’)">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="submit" VALUE="OK">
</FORM>
    • 1
2
3
4

      <FORM ACTION="test.pl">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="button" VALUE="OK" onClick="alert(’!’);this.submit()">
</FORM>
    • 1
2
3
4

      <FORM ACTION="test.pl">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="submit" VALUE="OK" onSubmit="alert(’!’)">
</FORM>
    • 1
2
3
4

      <FORM ACTION="test.pl" onBeforeSubmit="alert(’!’)">
<INPUT TYPE="text" NAME="txt">
<INPUT TYPE="submit" VALUE="OK">
</FORM>

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

  3. Memcached. Что это такое? В каких случаях применяется?

    4. Здесь я также просил рассказать соискателя вообще о кэшировании: как устроена система кэширования? Что обычно кэшируют? Когда кэширование не применимо?

    Подавляющее большинство было знакомо с кэшированием, но никогда не слышали про memcached, и рассказывали о хранении кэша в файлах. В основном соискатели использовали кэширование только результатов SQL-запросов.

  4. Что такое паттерн проектирования singleton и как он реализуется?

    5. Стандартный ответ на этот вопрос был такой: «Я слышал про singleton, применяется в ООП, но как реализуется и для чего нужен не помню». Примерно каждый 4-й полностью отвечал на этот вопрос.

  5. Командная строка *nix. Напишите команду, которая убьет все процессы, начинающиеся на «proc».

    6. Из всех кандидатов на этот вопрос правильно ответили 2 человека. В основном все сразу говорили, что с командной строкой не особо знакомы, знают несколько команд, но не более.

  6. Зачем нужен HAVING в SQL?

    7. Для меня это было удивительно, но на этот вопрос правильно ответили лишь человека 2-3. Когда я включал этот вопрос в свой список, у меня были сомнения нужен ли он вообще, но, как оказалось, очень даже нужен и показывает опыт работы с SQL.

    После этого один вопрос на теорию, здесь же я пытался выяснить, как человек будет справляться с задачами проектирования.

  7. Что такое нормализация БД? Что такое денормализация БД? Для чего она нужна?

    8. Здесь пополам, кто-то отвечал, кто-то нет. Почти каждого, особенно тех, кто не помнил или не слышал этих слов, после этого вопроса я просил набросать структуру БД для хранения товаров интернет-магазина, у каждого товара может быть от одного и более разделов.

  8. Расскажите о способах хранения деревьев в таблице? Например, когда нужно реализовать древовидные комментарии к статье.

    9. Большинство отвечали стандартно — у каждого комментария есть поле parent_id и т.д. Некоторые были знакомы с различными методами хранения деревьев, а были люди, которые прямо на собеседовании придумывали эти методы.

    Далее следовали вопросы по составлению запросов SQL. Я не задавал ни одного сложного запроса, все они были простые, для правильного ответа требовалось только знание SQL.

  9. Имеется таблица пользователей следующей структуры: 
    1
2
3
4
5

    CREATE TABLE users ( 
id INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
username CHAR(16) NOT NULL,
city_id INT(11) NOT NULL 
);
    • id – целочисленный первичный ключ последовательной нумерации
    • username – логин пользователя
    • city_id – город проживания пользователя

    Необходимо выбрать города, в которых проживает не менее n пользователей

  10. Имеется таблица для хранения информации о посещениях страниц пользователями: 
    1
2
3
4
5
6
7

    CREATE TABLE `page_visit` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`page` varchar(200) NOT NULL,
`date` datetime DEFAULT NULL,
PRIMARY KEY  (`id`)
)

    Необходимо вывести:

    1. последних 10 пользователей, посетивших страницу «/about/»
    2. всех пользователей, посетивших страницу «/about/», с указанием следующих данных:
      • ID пользователя
      • Количество посещений страницы
      • Время первого посещения страницы
      • Время последнего посещения страницы
  11. Есть 2 таблицы: 
    1
2
3
4

    CREATE TABLE users (
id INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY,
username CHAR(16) NOT NULL
);
    1
2
3
4
5

    CREATE TABLE user_email (
id INT( 11 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
user_id INT( 11 ) NOT NULL,
email CHAR(16) NOT NULL
);

    Необходимо вывести все email’ы пользователей, а также их логины.

    12. Далее был вопрос для тех, кто без особых проблем справился со всеми предыдущими:

  12. Пользовались telnet? Напишите, как при при помощи telnet обратиться к главной странице example.com.

    13. На этот вопрос ответил только один человек из всех соискателей. Кстати, он был сисадмином и решил переквалифицироваться в web-программиста.

Для последней части, возможно, следовало бы придумать вопросов побольше, но у меня так и не дошли руки до этого, да и задавать их пришлось всего раза 2-3.

Помимо этих вопросов, некоторых соискателей по ходу собеседования я спрашивал о том, с какими фреймворками они работали, работали ли с системами контроля версий (svn, cvs, git), смогут ли настроить web-сервер (nginx, apache).

В итоге мне пришлось провести около 20-ти собеседований, после которых в нашу компанию были взяты на работу 2 программиста. Мне удалось выполнить поставленную цель: один программист — начинающий, сейчас он учится и растет каждый день нереальными темпами, второй программист — уже поработавший в нашей профессии достаточно времени и в данный момент решает наши повседневные задачи самостоятельно и без чьей-либо помощи, он в ней и не нуждается.

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

Мне даже известны случаи, когда сложные вопросы только мешали правильному пониманию возможностей человека. Рассказывал один знакомый, который любит выносить мозг соискателю на собеседовании: к ним приходил человек, ответивший на очень сложный вопрос, вся их команда была удивлена этому факту. В итоге его взяли, а потом пришлось уволить, т.к. этот новый сотрудник начал просто разрушать их проекты своим качеством кода, неправильным подходом в самом начале задачи. Проще говоря, за ним нужен был глаз да глаз, что не входило в планы команды.

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

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

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

А что вы думаете о простых и сложных собеседованиях для программистов? Каким оно должно быть?

]]> http://job-interview.ru/articles/post/290/feed 0 Хочу открыть интернет-магазин http://job-interview.ru/articles/post/271 http://job-interview.ru/articles/post/271#comments Sun, 30 May 2010 13:31:35 +0000 tiger /articles/?p=271 Наверное, многие, проработав определенное время в какой-то отрасли, приходят к мыслям о том, что нужно попробовать что-то свое. С некоторых пор такие мысли стали посещать и меня.

Я web-программист, проработал уже достаточное время на этой должности и, честно говоря, порядком подустал. К тому же я не вижу каких-то особых перспектив, к которым мне хотелось бы стремиться.

Нет, они, конечно, есть. Программист перерастает в руководителя группы, потом в руководителя отдела, возможно, потом еще в кого-то, потом «потолок». Кого-то может такая ситуация устраивает, но она не для меня.

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

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

Где web-программист может проявить себя самостоятельно?

  • Фриланс.

    • Возможно, стоило бы попробовать, но все-таки по рассказам знакомых фрилансеров больших денег там не заработаешь. Особенно первое время придется усиленно экономить. Да и все же это не совсем работа на себя, а работа на заказчика.

  • Web-студия.

    • Для ее открытия нужен какой-то стартовый капитал, которого у меня нет. Кроме того, большие риски, что вложенные на начальном этапе средства так и не окупятся. Опять же в этом варианте присутствуют заказчики, на которых тебе придется вкалывать.

  • Интернет-магазин.

    • На данный момент самый подходящий для меня вариант. Его я и выбрал.

Почему я хочу открыть интернет-магазин?

Почему я хочу открыть интернет-магазин?
Устал от работы на дядю, надоели начальники, которые вечно самоутверждаются за счет своих подчиненных.

Ситуацию можно описать известной фразой: «Я начальник, ты дурак, ты начальник, я дурак». Причем как-то получается так, что «дураком» ты становишься автоматически, независимо от объема твоих знаний, опыта и т.д. Начальник все равно знает больше, чем ты, только он может принять единственно верные решения.

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

Если он бывший программист, то да, я согласен. Однако, очень часто в роли начальников выступают совсем не программисты, а менеджеры, которые считают, что разбираются в твоей области гораздо лучше, чем ты, а все программисты — это обычные кодеры, которые реализовывают их гениальные идеи.

Найдется ли такой программист, который никогда не попадал на такой диалог?
– Сколько займет времени, чтобы это сделать?
– Думаю, что где-то полдня нужно будет.
– Почему так долго? Здесь же просто кнопку поставить.

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

В ответ на твои объяснения ты получаешь примерно следующую фразу: «Ну не знаю, мне кажется, что все равно это очень долго».

Кроме того, много денег при работе на кого-то не заработаешь. Все равно есть потолок.

Доход от интернет-магазина будет зависеть только от тебя и от его развития. Теоретически предела доходам здесь нет.

Еще одна причина, по которой я хочу начать свое дело — устал от работы в коллективе. Возможно, эта причина относится только ко мне, а может и нет.

На мой взгляд, каждому коллективу присуща определенная доля лживости. Вроде как все говорят: «Мы вместе, мы одна команда». Все друг другу улыбаются, все друзья, все классно. Однако, это только на поверхности.

Как люди могут быть друзьями, когда они всеми силами стараются показать себя выше других, чтобы начальство их заметило? А этим приходится заниматься, все ведь хотят продвинуться вверх по службе.

Коллективу часто приходится объяснять начальству, почему не выдерживаются сроки в том или ином проекте. А начальству важно знать, кто конкретно тормозит проект. В таких ситуациях приходится закладывать кого-то из своих «друзей».

Когда в коллективе решают, кому конкретно доверить очередной проект, тут то и выясняется, чьи знания и опыт ценят, а чьи нет.

Но ведь на поверхности то все равны, все сотрудники одинаково ценятся.

В общем эта как-бы «дружба» не для меня. Чисто с психологической точки зрения я бы себя чувствовал спокойнее, занимаясь своим делом и не отвлекаясь на всякие закулисные склоки.

А что продавать?

А что продавать?
Вот это очень трудный и самый важный вопрос на начальном этапе. На данный момент в интернете можно купить почти все. Конкуренты есть везде. Но выбирать что-то нужно.

Я для себя определил следующие критерии моего будущего товара:

  • Он должен быть легким, чтобы не было проблем при доставке.
  • Его стоимость не должна быть очень низкой. Большого объема заказов в первое время не предвидится, поэтому даже один заказ должен приносить более менее приличную сумму (не 1 рубль, а, скажем, 200).
  • Он должен быть приспособлен для интернета. Например, продавать продукты питания через интернет, на мой взгляд, не самая лучшая идея. Все-таки некоторые товары люди хотят «пощупать», когда его выбирают.
  • В идеале этот товар должен быть интересен мне, чтобы я мог иметь какое-то мнение по нему. Тогда я бы мог составлять описания к товарам, а это поможет продвижению в поисковиках.

Осталось теперь найти товар, удовлетворяющий этим моим критериям. Пока я нахожусь в поиске.

Под эти пункты очень подходят книги, но здесь очень высока конкуренция, поэтому их я не рассматриваю.

Определиться с товаром — это одна проблема. Решив ее, придется еще найти поставщиков, которые готовы этот товар поставлять. Кроме того, т.к. у меня нет никакого начального капитала, то закупать товар оптом я не смогу. Поэтому нужно найти поставщика, который будет готов поставлять товар по факту заказа. Т.е. мне представляется следующая схема: мне пришел заказ, я еду к поставщику, забираю у него товар, доставляю товар клиенту.

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

Итак, товар выбран, поставщик найден. Чем мой магазин будет отличаться от других? Нужно придумать уникальное торговое предложение (УТП). Возможно, в моем магазине цены будут ниже, чем у конкурентов, возможно, что-то еще, но клиента нужно будет чем-то зацепить, чтобы, совершив один раз покупку у меня, он вернулся ко мне же за следующей.

На эту тему я пока даже не думаю, сначала надо определиться с товаром.

Планы

Планы
Перед открытием магазина я зарегистрирую ИП. Скорее всего воспользуюсь услугами какого-нибудь агентства, но, похоже, что даже в этом случае придется помотаться по всяким гос. учреждениям. Ну а что делать, без этого в нашей стране никуда.

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

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

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

Доставкой буду заниматься первое время сам. Придется как-то совмещать с текущей работой, но это, надеюсь, продлится не долго, т.к. за первые 1-2 месяца станет более менее понятно, что получится из магазина в итоге.

Если заказов будет не мало, то возьму отпуск, может даже за свой счет.

Моя первоначальная цель — достичь дохода от магазина, равного половине моей текущей зарплаты. Если добьюсь этого, то планирую уволиться, а часть денег зарабатывать на фрилансе. В итоге мой месячный доход будет равен текущему доходу на постоянной работе.

Давно хочу изучить язык программирования python и фреймворк django. Как раз мой магазин поможет мне в этом. Даже, если ничего путного не выйдет, то, как минимум, будет опыт программирования на python.

Ну вот вроде и все. Я хотел в этой статье поделиться своими мыслями и планами по поводу открытия своего интернет-магазина. Как только приступлю к реализации этих планов, поделюсь полученным опытом в следующей статье.

Жду любых ваших мнений в комментариях.

Также интересно было бы узнать мнение программистов, которые уже прошли путь открытия своего бизнеса (не обязательно интернет-магазин).

]]> http://job-interview.ru/articles/post/271/feed 4 CMS Битрикс. За и против. http://job-interview.ru/articles/post/234 http://job-interview.ru/articles/post/234#comments Thu, 04 Feb 2010 21:45:56 +0000 sasha84 /articles/?p=234 Проработав 2 года с CMS Битрикс, у меня сформировалось свое отношение к этому движку. Есть как плюсы, так и минусы, но все же негатива накопилось гораздо больше.

В этой статье я поделюсь своим мнением с читателями и постараюсь описать и хорошие, и плохие стороны этой CMS.

Во-первых, хочется сказать пару слов о тормозах этой системы. В этом ее любят обвинять очень многие.

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

Тормоза начинаются, когда от сайта требуется что-то большее, нежели обычный текстовый контент. В этом случае проектировщик сталкивается с неуклюжестью движка.
В битриксе все основывается на понятии инфоблока. Давайте рассмотрим что же на самом деле из себя представляет инфоблок.

Диаграмма инфоблоков Битрикс

Инфоблок — это такая сущность, которая объединяет элементы с определенным набором свойств. Часть свойств, такие как название элемента, раздел, даты активности и т.п., присутствует у элементов всех инфоблоков. К этим свойствам проектировщик может добавить еще и свои свойства, но они уже будут рассматриваться в контексте каждого конкретного инфоблока.

Существует также понятие типа инфоблока, который объединяет в себе инфоблоки.
Поясню на примере. Допустим, мы создаем сайт, на котором будут размещены вакансии.. В этом случае нам будут необходимы 3 инфоблока: «Вакансии», «Отрасли», «Компании».

После создания инфоблока «Вакансии» мы можем создать в нем элементы со стандартным набором свойств:

  • Название
  • Активность (да/нет)
  • Период активности (активен в указанный период времени)
  • Краткое описание
  • Подробное описание
  • Изображение-превью
  • Увеличенное изображение
  • Раздел

Этих свойств будет достаточно для обычного текстового контента (статьи, новости и т.д.), но нам для вакансий этого не хватит. Мы создадим еще свойства:

  • Компания (свойство, ссылающееся на инфоблок «Компании»)
  • Отрасль (свойство, ссылающееся на инфоблок «Отрасли»)
  • Опыт работы (свойство типа список с значениями «до 2-х лет», «от 2-х до 4-х лет», «более 4 лет» и т.д.)

В инфоблоке «Отрасли» и «Компании» ограничимся стандартным набором свойств, которые предоставляет нам битрикс.

Вот, что у нас получилось:

Структура инфоблоков Битрикс для размещения вакансий

Вроде бы с точки зрения теории баз данных у нас все верно. Все сущности разделены, избыточности нет и т.д. Но давайте взглянем на структуру базы.

Рассмотрим как работает выборка из инфоблоков на простом примере. В битриксе существует часть таблиц в базе данных, которые хранят данные, связанные с инфоблоками — сами инфоблоки (b_iblock), их элементы(b_iblock_element), свойства(b_iblock_property), значения свойств (b_iblock_element_property).

Это не все таблицы, связанные с инфоблоками, но для простоты понимания нас будут интересовать именно они.

ER-диаграмма некоторых таблиц Битрикса, хранящих данные об инфоблоках

Как видим, элементы всех инфоблоков хранятся в одной таблице, все свойства этих элементов так же хранятся в одной таблице.

Как же так! Зачем СУБД копаться в вакансиях, отраслях, если нам нужно будет выбрать всего лишь список всех компаний, вакансии которых храняться в базе ?!

А что будет, если нашему сайту необходим более сложный функционал? Вот тогда то и начнутся тормоза.

Теперь воспользуемся АПИ битрикса и выберем список вакансий конкретной компании, но те вакансии, которые не относятся к определенной отрасли.

В примере происходит выборка из инфоблока «Вакансии», ID которого 23, а также происходит фильтрация по компании, ID которой 373, и по отрасли, ID которой 317. В последнем параметре метода GetList передается список выбираемых полей — ID, компания, опыт работы, начало периода активности вакансии.

$arFilter = Array(
"IBLOCK_ID"=>23, // выбираем элементы из инфоблока, ID которого 23
"ACTIVE"=>"Y", // выбираем только активные элементы
"PROPERTY_COMPANY"=>373, // вакансии будут принадлежать компании с ID=373
"!PROPERTY_BRANCH" =>317 // вакансии, принадлежащие отрасли с ID=317, нас не интересуют
);
$res = CIBlockElement::GetList(Array("DATE_ACTIVE_FROM"=>"ASC"), $arFilter, false, false, Array("ID", "PROPERTY_COMPANY", "PROPERTY_EXPERIENCE", "DATE_ACTIVE_FROM"));

Выглядит красиво, прямо как-будто один безобидный SQL запрос, но заглянем внутрь:

SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('COMPANY')
 
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('EXPERIENCE')
 
SELECT BP.*
FROM
b_iblock_property BP, b_iblock B
WHERE
BP.IBLOCK_ID=B.ID AND B.ID IN (23) AND UPPER(BP.CODE)=UPPER('BRANCH')
 
SELECT BE.ID AS ID, FPV0.VALUE AS PROPERTY_COMPANY_VALUE, FPV0.ID AS PROPERTY_COMPANY_VALUE_ID, FPEN0.VALUE AS PROPERTY_EXPERIENCE_VALUE, FPEN0.ID AS PROPERTY_EXPERIENCE_ENUM_ID, FPV1.ID AS PROPERTY_EXPERIENCE_VALUE_ID,IF(EXTRACT(HOUR_SECOND
FROM
BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'), DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) AS DATE_ACTIVE_FROM,IF(EXTRACT(HOUR_SECOND
FROM
BE.ACTIVE_FROM)>0, DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y %H:%i:%s'), DATE_FORMAT(BE.ACTIVE_FROM, '%d.%m.%Y')) AS ACTIVE_FROM
FROM
b_iblock B
INNER JOIN b_lang L ON B.LID=L.LID
INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID
INNER JOIN b_iblock_property FP0 ON FP0.IBLOCK_ID = B.ID AND FP0.CODE='COMPANY'
LEFT JOIN b_iblock_property FP1 ON FP1.IBLOCK_ID = B.ID AND FP1.CODE='EXPERIENCE'
LEFT JOIN b_iblock_property FP2 ON FP2.IBLOCK_ID = B.ID AND FP2.CODE='BRANCH'
INNER JOIN b_iblock_element_property FPV0 ON FPV0.IBLOCK_PROPERTY_ID = FP0.ID AND FPV0.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV1 ON FPV1.IBLOCK_PROPERTY_ID = FP1.ID AND FPV1.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV2 ON FPV2.IBLOCK_PROPERTY_ID = FP2.ID AND FPV2.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_property_enum FPEN0 ON FPEN0.PROPERTY_ID = FP0.ID AND FPV1.VALUE_ENUM = FPEN0.ID
WHERE
1=1 AND ( ((((BE.IBLOCK_ID = '23')))) AND ((((BE.ACTIVE='Y')))) AND ((((FPV0.VALUE_NUM = '373')))) AND ((( FPV2.VALUE_NUM IS NULL OR NOT (FPV2.VALUE_NUM = '317')))) ) AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL)))
ORDER BY
BE.ACTIVE_FROM ASC

Ужас! А что же тогда творится с СУБД на реальных сайтах.

Мы при написании метода GetList использовали 3 свойства (ключи значений массивов, начинающиеся с «PROPERTY_») и в SQL-запросах, которые сгенерил битрикс, видим 3 запроса для каждого из 3-х свойств. А что будет, если создать десятки свойств? А будет ровно столько запросов сколько участвует в методе GetList.

Ну и в конце мы видим громадный запрос, напичканный join’ами. Если приглядеться к этому запросу, то можно догадаться, что количество join’ов зависит от количества свойств, участвующих в методе GetList.

Понятно, что все это плата за универсальность. Все те, кто используют битрикс любят повторять, что это далеко не идеальная система, но это лучшая CMS из всех существующих. А чем она лучше? Да только, пожалуй, тем, что у нее присутствует больше всевозможных модулей по сравнению с другими CMS. Еще есть удобная админка, в которой быстро разберутся модераторы. Так же битрикс постоянно обновляется и пополняется новыми модулями, в этом тоже его плюс.

Как я уже сказал, мое мнение, что битрикс сгодится только для простых сайтов. Если требуется какой-то более менее сложный функционал, то приходится ломать голову как обойти эти издержки универсальности.

Возникает вопрос. Зачем простому сайту, на котором в основном статьи и новости, дополнительные модули в виде магазина, форума, блогов, тормозной статистики (которую к тому же предлагают многие бесплатные сервисы). А ведь такой сайт программист может без проблем создать, например, на бесплатном фреймворке symfony, в котором админка генерится одной командой. Так зачем платить больше?

Ну а сайт со сложным функционалом, как я уже сказал, по моему мнению начинать делать на битриксе лучше не стоит. Эта затея перерастет в поиски путей обхода битриксовых фич.
И все-таки смысл создавать сайты на битриксе, как мне видится, есть. Но прежде, чем описать свою точку зрения на этот счет, нужно сказать несколько слов о многочисленной армии кодеров-битриксоидов.

Это такие люди, в основном студенты, которые еще не слышали ни о теории баз данных, ни о паттернах проектирования, не работали с существующими фреймворками. Для них битрикс — это все, что стоит за сайтом. Они даже о новых технологиях узнают только тогда, когда она будет включена в очередную версию CMS.

Как-то раз ко мне подошел один из сотрудников за помощью. Он парсил файл CSV, но этот процесс у него отрабатывал не верно. Стали смотреть скрипт и тут программист высказывает свое предположение: «Может быть битрикс где-то закрался?». Может быть всемогущий битрикс каким-то магическим образом и мог бы закрасться в его скрипт, но дело в том, что он его запускал без подключения движка. На самом деле потом нашли обычную ошибку в логике самого скрипта.

Еще был случай. Отмечали чей-то день рождения и двое программистов начали обсуждать все достоинства битрикса. Один из них кинул фразу: «Ну битрикс — это очень мощная система, он внутри себя и язык Си использует, и ассемблер». Второй округлил глаза и не поверил. А тот ему: «Ну ты залезь в код битрикса, посмотри». Тут вообще без комментариев.

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

Таким образом, на свет появляются web-студии, которые штампуют на битриксе сайт за сайтом. Их основной задачей в итоге становиться увеличение штата сотрудников, способных делать сайты на битриксе. Дешевая рабочая сила. Чем больше штат, тем больше сайтов они смогут клепать.

И напоследок хотелось бы дать совет начинающим программистам. Не устраивайтесь на работу в web-студии, которые в своих описаниях вакансий упоминают слово «Битрикс». Если вы начнете свой карьерный путь с этого движка, то потом соскочить с него будет не просто. Пройдет года 2 и ваши друзья уже неплохо продвинуться в программировании, кто-то перерастет в проектировщика, а вы будете жить одними инфоблоками и не понимать что происходит внутри.
Я сейчас не говорю о всех, но именно таких программистов я встречал часто. Конечно, все люди разные, кто-то может на работе использовать битрикс, но дома в целях самообразования тренироваться в других областях программирования. Но все же лучше набираться знаний на работе, где человек проводит большую часть своего времени.

На этом все. Спасибо за внимание. В комментариях жду ваших мыслей по поводу использования битрикса.

]]> http://job-interview.ru/articles/post/234/feed 80 “Многопоточность” в PHP (socket) http://job-interview.ru/articles/post/194 http://job-interview.ru/articles/post/194#comments Sun, 27 Dec 2009 13:21:34 +0000 Pablo Monteagudo /articles/?p=194 Использование асинхронных сокетов.

Предлагаю вашему вниманию третью статью из цикла “Многопоточность” в PHP. В данной статье мы рассмотрим асинхронные или неблокирующие сокеты.

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

Но сначала давайте разберем само понятие “сокет”. Что такое сокет?

Сокеты — это название программного интерфейса для обеспечения информационного обмена между процессами. Процессы при таком обмене могут исполняться как на одном компьютере, так и на различных, связанных между собой сетью. Сокет — абстрактный объект, представляющий конечную точку соединения.

В нашем случае сокет будет представлять собой соединение между нашей программой и компьютером, с которого требуется получить необходимую информацию.

Работа с сокетами достаточно проста:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
$url = 'www.mail.ru';
// создаем сокет
$sh = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
// определяем ip хоста
$ip = gethostbyname($url);
// открываем сокет
socket_connect($sh, $ip, '80');
// формируем http-заголовки
$headers  = "GET / HTTP/1.0\r\n";
$headers .= "Host: ".$url."\r\n";
$headers .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.6) Gecko/2009011913 MRA 5.3 (build 02557) Firefox/3.0.6\r\n";
$headers .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n";
$headers .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n";
$headers .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n";
$headers .= "\r\n";
// записываем данные в сокет
socket_write($sh, $headers, strlen($headers));
// читаем данные из сокета
$result = '';
while ($r = socket_read($sh, 1024)) $result .= $r;
?>

Сначала функцией socket_create инициализируем сокет и задаем его характеристики – флаг AF_INET, переданный в качестве первого параметра, указывает, что создается сокет для интернета, второй параметр – тип сокета (самые распространенные – TCP и UDP) нам нужен TCP-сокет – SOCK_STREAM, и третий параметр задает протокол (TCP).
Затем с помощью функции socket_connect происходит соединение к указанному адресу и порту. Надо заметить, что эта функция принимает в качестве параметра не сам адрес хоста, а его ip адрес, поэтому сначала мы должны его определить функцией gethostbyname.
Теперь нам надо сформировать запрос, который мы отправим на сервер (подробнее о http-заголовках можно почитать в статье PHP и HTTP). Собственно отправку производит функция socket_write, второй параметр которой – это то, что мы отправляем и третий – длина отправляемой строки (т.е. всех сформированных заголовков).
Запись произведена, теперь функцией socket_read читаем данные, переданные для нас сервером.
В результате в переменной $result хранится хтмл, который нам необходим.

Задача у нас стоит та же, что и в предыдущих примерах: получить содержимое нескольких html-страниц. Вот код, реализующий это:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

<?php
// страницы, содержимое которых надо получить
$urls = array('www.yandex.ru', 'www.google.ru', 'www.mail.ru', 'www.rambler.ru');
 
$rtasks = array(); // задачи чтения
$wtasks = array(); // задачи записи
$results = array(); // результаты
 
foreach ($urls as $url) {
	// открываем отдельный сокет
	$sh = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
	if (!$sh) continue;
 
	// таймаут для чтения
	socket_set_option($sh, SOL_SOCKET, SO_RCVTIMEO, array("sec" => 10, "usec" => 0));
	// таймаут для записи
	socket_set_option($sh, SOL_SOCKET, SO_SNDTIMEO, array("sec" => 10, "usec" => 0));
	// задаем неблокирующий режим сокетов
	socket_set_nonblock($sh);
	// определяем ip хоста
	$ip = gethostbyname($url);
	// соединяемся
	socket_connect($sh, $ip, 80);
 
	// добавляем в задачи для записи
	$wtasks[$url] = $sh;
}
 
// продолжаем, пока есть задачи для записи или чтения
while ($wtasks || $rtasks) {
	// массив для сокетов с возможностью чтения
	$rtasks_ = $rtasks;
	// массив для сокетов с возможностью записи
	$wtasks_ = $wtasks;
 
	// ждем результатов из сокетов
	$n = socket_select($rtasks_, $wtasks_, $e=null, 10);
	if ($n > 0) {
		// сокеты, доступные для записи
		foreach ($wtasks_ as $sh) {
			// ищем урл страницы по дескриптору сокета в массиве задач записи
			$url = array_search($sh, $wtasks);
			// удаляем из задач записи
			unset($wtasks[$url]);
			// добавляем в задачи чтения
			$rtasks[$url] = $sh;
			// формируем http-заголовки
			$headers  = "GET / HTTP/1.0\r\n";
			$headers .= "Host: ".$url."\r\n";
			$headers .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.6) Gecko/2009011913 MRA 5.3 (build 02557) Firefox/3.0.6\r\n";
			$headers .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n";
			$headers .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n";
			$headers .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n";
			$headers .= "\r\n";
 
			// записываем в сокет
			if (socket_write($sh, $headers) === false) fclose($sh);
		}
 
		// сокеты, доступные для чтения
		foreach ($rtasks_ as $sh) {
			// ищем урл страницы по дескриптору сокета в массиве задач чтения
			$url = array_search($sh, $rtasks);
			if (!$url) continue;
			// считываем результат из сокета
			$result = '';
			while ($r = socket_read($sh, 1024)) $result .= $r;
			// закрываем сокет
			socket_close($sh);
			// удаляем из задач чтения
			unset($rtasks[$url]);
			// заносим html в массив результатов
			$results[$url] = $result;
		}
	}
	else {
		break;
	}
}
?>

Можно заметить, что код несильно отличается от кода для stream-функций.

В общих словах здесь происходит следующее. Каждый сокет инициализируется и переводится в неблокирующий режим. Затем в цикле производится проверка готовых к чтению или записи сокетов, и если такие существуют, производится соответствующая операция. Все действия протекают в асинхронном порядке, т.е не ждут окончания предыдущей операции. Например, если данные с мэйл.ру поступили раньше, чем от яндекса, то будут обрабатываться именно они, хотя коннект к яндексу мог произойти до коннекта к мэйлу. Можно сказать, что все происходит в несколько “потоков”, когда параллельно ожидается готовность каждого сокета к какому-либо действию.

Теперь разберем код более подробно.
Итак, у нас есть массив с адресами страниц. В строке 9 запускается цикл для инициализации соединения с каждым хостом. В 11 строке создается сокет, затем в 15 и 17 строках мы задаем таймауты для чтения и записи соответственно. В 19 строчке функцией socket_set_nonblock задаем неблокирующий режим, превращающий каждый наш сокет в асинхронный. Это необходимо для того, чтобы после очередной операции над сокетом не происходило ожидание ее окончания, а продолжал работу остальной код программы. В 26 строке заносим инициализированный сокет в массив сокетов для записи.

Основной цикл начинается в 30 строчке. Он будет продолжаться до тех пор, пока у нас остаются сокеты, в которые нужно записать или из которых надо прочитать.
В 32 строке массиву $rtasks_ присваиваем массив сокетов, из которых должна быть прочитана информация. В 34-ой в $wtasks_ заносится массив с сокетами, в которые необходимо произвести запись.
Главная функция в этом цикле – socket_select. Она принимает на вход массивы сокетов, ожидающих чтения, ожидающих запись и массив для исключительных ситуаций, четвертый параметр, передаваемый в данную функцию – таймаут. Параметры-массивы передаются по ссылке, т.е когда произойдет ожидаемое событие (socket_select в этом случае вернет число больше 0), в них появятся соответствующие дескрипторы.
Если нашлись сокеты, доступные для записи, ищем урл, соответствующий каждому из готовых сокетов, и функцией socket_write записываем в него заголовки для получения хтмл страницы в ответе. Так же в 44-ой строке удаляем дескриптор из массива для записи, так как она будет произведена, и заносим его в строке 46 в массив для чтения, чтобы потом получить интересующий нас ответ.
Если же имеются сокеты, готовые нам ответить, считываем из них информацию функцией socket_read.
Profit! В массиве $results содержится вожделенный хтмл-код!

Замечание:
При вызове функции socket_connect, когда сокет переведен в неблокирующий режим функцией socket_set_nonblock, выдается предупреждение “Operation now in progress” (”Операция на незаблокированном сокете не может быть завершена немедленно”), а socket_connect возвращает false. Несмотря на это, код нормально отрабатывает.

]]> http://job-interview.ru/articles/post/194/feed 26 Отладка программ в командной строке Linux http://job-interview.ru/articles/post/160 http://job-interview.ru/articles/post/160#comments Sat, 31 Oct 2009 18:08:33 +0000 tiger /articles/?p=160 Как известно, все программисты при написании программ допускают ошибки. Не думаю, что найдется хоть один разработчик, который,как-то решив разработать более-менее сложное приложение, сел за свой компьютер, открыл любимый редактор, набрал нужный код, скомпоновал его и после запуска программа сделала все то, что от нее требовалось.

Все это из области фантастики. Каждый из нас допускает ошибки, поэтому нам нужно их как-то отлавливать.

Если ошибка синтаксическая, то в большинстве случаев на это укажет компилятор. Но, если ошибка логическая, то часто программист сам не в состоянии определить ее.

Конечно, если программа не сложная, то можно самостоятельно, не прибегая ни к каким дополнительным средствам, выявить ошибку.

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

В этой статье рассказывается об отладке программ, написанных на языке C, в командной строке Linux с использованием утилиты GDB.

Многие программисты, которые с успехом разрабатывали свои приложения на языках C/C++ для Windows, после перехода к разработке программ на том же языке, но под ОС семейства Linux с удивлением обнаруживают, что отсутствует возможность той отладки, которой они пользовались в редакторах при написании программ для Windows.

Однако, такая возможность есть и это отладчик GDB.

Как следует из документации к этой утилите «цель отладчика GDB – это позволить вам увидеть, что происходит внутри программы пока она выполняется, или что программа делает в момент ее краха.».

На момент написания этой статьи отладчик GDB работает с программами, написанными на языках C, C++, Modula-2. Мы будем отлаживать приложение, написанное на языке C.

Давайте начнем с приведения кода программы, которая в качестве аргумента принимает число и высчитывает факториал этого числа при помощи рекурсии. Ее мы и будем отлаживать.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
int fact(int num)
{
    if(num <= 1)
    {
      return 1;
    }
 
    return num * fact(num - 1);
}
 
int main(int argc, char **argv)
{
  int a = atoi(argv[1]);
  printf("%d! = %d\n", a, fact(a));
 
  return 0;
}

Теперь скомпилируем ее с включением отладочной информации. Для этого в командной строке заходим в директорию, в которой лежит наш файл с расширением .c и выполняем команду:

g++ -g fact.c -o fact

Опция -g сообщает компилятору о том, что в программу нужно включить отладочную информацию, которой и воспользуется отладчик GDB.

Опция -o сообщает компилятору g++ путь до исполняемого файла. Если ее не указать, то, по умолчанию, компилятор создаст исполняемый файл в той же директории, где находится наша программа, и назовет его a.out.

Теперь запустим нашу программу в режиме отладки:

gdb -q fact

Опцию -q можно не указывать, она используется лишь для того, чтобы при первом заходе в отладчик не выводилась информация о версии, лицензионное соглашение и т.д.

Итак, мы запустили отладчик. Теперь мы можем выполнять его команды.

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

(gdb) list 10
5       int fact(int num)
6       {
7           if(num <= 1)
8           {
9             return 1;
10          }
11
12          return num * fact(num - 1);
13      }

Также можно передать название функции, после чего будет выведен код, окружающий эту функцию.

(gdb) list fact
1       #include <stdio.h>
2       #include <stdlib.h>
3       #include <unistd.h>
4
5       int fact(int num)
6       {
7           if(num <= 1)
8           {
9             return 1;
10          }

Давайте запустим теперь выполнение программы под отладчиком. Это можно сделать одной из двух команд: run или start.

Отличие между этими двумя командами в том, что, вызвав команду start, отладчик останавливается на входе в функцию main, а команда run выполняется до тех пор, пока не наткнется на точку останова (о них чуть позднее).

Обе эти команды принимают в качестве параметра аргументы программы так же, как если бы программа запускалась из командной строки.

Итак, запустим программу на выполнение в режиме отладки:

(gdb) start 4
Temporary breakpoint 2 at 0x8048556: file fact.c, line 17.
Temporary breakpoint 2, main (argc=2, argv=0xbffffa24) at fact.c:17
17        int a = atoi(argv[1]);

Как видим, отладчик остановился сразу же на входе в функцию main, а также вывел код и номер строки, перед которой остановился.

Используя команду print, мы можем вывести значения переменных и выражений. Посмотрим какие входные аргументы приняла наша программа:

(gdb) print argv[0]
$1 = 0xbffffb41 "/home/user/cpp/fact"
(gdb) print argv[1]
$2 = 0xbffffb5f "4"

В нулевом элементе массива argv содержится путь до выполняемой программы, а в первом элементе наш переданный аргумент — 4.

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

Используя эти команды, можно передвигаться по программе. Отличие этих команд состоит в том, что step будет заходить внутрь функции каждый раз, когда ее встретит, а next пойдет дальше.

Перейдем к следующей строке:

(gdb) step
18        printf("%d! = %d\n", a, fact(a));

Мы сделали один шаг и остановились перед 18-ой строкой.

Пойдем дальше:

(gdb) step
fact (num=4) at fact.c:7
7           if(num <= 1)

Мы вошли в функцию fact с входным параметром 4 и оказались перед 7-ой строкой.

Т.к. мы имеем дело с рекурсией, то, вероятно, нам будет интересно значение переменной num, которое будет изменяться при каждом рекурсивном входе в функцию fact.

Добавим в процесс отладки слежение за переменной num. Для этого существует команда display, которой необходимо передать название переменной. В нашем случае это будет переменная num.

Выполним команду display и перейдем на один шаг вперед:

(gdb) display num
1: num = 4
(gdb) step
12          return num * fact(num - 1);
1: num = 4

Как видим, теперь при каждой остановке программы отладчик GDB сообщает нам значение переменной num.

Сейчас мы находимся перед рекурсивным входом в функцию fact. Заходим в нее и делаем еще один шаг вперед:

(gdb) step
fact (num=3) at fact.c:7
7           if(num <= 1)
1: num = 3
(gdb) step
12          return num * fact(num - 1);
1: num = 3

Отладчик сообщает нам значение переменной num, которое уже равно 3. Сейчас мы снова находимся перед заходом в функцию fact.

Скорее всего, не имеет смысла каждый раз проделывать эти шаги в функции fact. Нам достаточно было бы отслеживать какие значения принимает переменная num в 12-ой строке, т.к. в этой строке происходит рекурсивный вызов функции, а также возвращается результат ее выполнения.

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

Однако, в реальных программах программисты отлаживают код, который содержит в себе тысячи строк. Если бы для отладки такого кода пришлось бы обойти каждую строку, то это превратилось бы в долгую и муторную работу.

Расставив точки останова, отладчик может «перепрыгивать» к строкам, на которых они поставлены, минуя весь остальной код. Для этого можно использовать команду continue, которая продолжает выполнение программы до тех пор, пока не встретится точка останова. Если их нет, то программа выполнится до конца.

Итак, давайте поставим точку останова в строке 12 и выполним команду continue, чтобы продолжить программу до тех пор, пока не наткнемся на строку 12:

(gdb) break 12
Breakpoint 2 at 0x8048529: file fact.c, line 12.
(gdb) continue
Continuing.
 
Breakpoint 2, fact (num=2) at fact.c:12
12          return num * fact(num - 1);
1: num = 2

Мы прошли все шаги, которые до этого проделывали командой step. Теперь, каждый раз выполняя команду continue мы будем оказываться на 12-ой строке, а, благодаря выполненной ранее команде display, мы сможем наблюдать как изменяется значение переменной num на каждом шаге.

Есть и другой способ следить за изменением переменной в ходе работы программы с использованием команды watch. В отличие от команды display, эта команда при каждом изменении переменной, переданной в качестве параметра, будет останавливать выполнение программы и выводить старое и новое значение переменной.

Обе команды display и watch могут в качестве параметра принимать не только переменные, но и выражения.

Продолжим выполнение программы:

(gdb) continue
Continuing.
4! = 24
 
Program exited normally.

Отладчик показал вывод нашей программы, а именно подсчитанный факториал от 4. Последняя строка в выводе отладчика сообщает, что программа завершилась. Отладчик также вывел бы код возврата программы в восьмеричной форме, если бы программа возвращала число, отличное от нуля.

Очень полезной может оказаться команда set variable, которая позволяет изменять значение переменной по ходу выполнения программы:

user@linux-hn2z:~/cpp/> gdb -q fact
(gdb) start 4
Temporary breakpoint 1 at 0x8048556: file fact.c, line 17.
Starting program: /home/user/cpp/fact 4
 
Temporary breakpoint 1, main (argc=2, argv=0xbfffef84) at fact.c:17
17        int a = atoi(argv[1]);
(gdb) step
18        printf("%d! = %d\n", a, fact(a));
(gdb) set variable a=10
(gdb) c
Continuing.
10! = 3628800

В этом примере мы запустили программу с входным параметром — 4, но по ходу выполнения программы мы заменили этот параметр на 10, и программа подсчитала факториал от 10.

Команду set variable можно применять, например, когда вы на каком-то шаге обнаружили, что программа ведет себя не верно, но путем изменения значения переменной можно исправить ситуацию и посмотреть как программа будет вести себя дальше.

В настоящей статье описаны далеко не все возможности отладчика GDB. За более подробными руководствами обращайтесь к документации по утилите, кроме того, находясь в отладчике, можно вывести список всех команд и описаний к ним, воспользовавшись командой help.

На этом все. Удачной отладки.

]]> http://job-interview.ru/articles/post/160/feed 1 Вопросы на собеседовании для PHP-программиста (часть 3) http://job-interview.ru/articles/post/104 http://job-interview.ru/articles/post/104#comments Sat, 01 Aug 2009 17:49:23 +0000 tiger /articles/?p=104 Это заключительная статья, о вопросах на собеседованиях для PHP-программиста, на которые мне приходилось отвечать.

В первых двух статьях я уже выкладывал список вопросов.

В первой статье были вопросы по темам:

  • PHP
  • Задачи по составлению различных запросов SQL

В второй статье были вопросы по темам:

  • Администрирование MySQL
  • Основные принципы ООП

В этой статье я выкладываю вопросы с собеседований для PHP — программиста по следующим темам:

  • Регулярные выражения
  • Основные протоколы интернета
  • Работа в командной строке Linux

Итак, представляю список вопросов.

Регулярные выражения

  1. Напишите регулярное выражение для проверки E-mail.
  2. С использованием регулярных выражений напишите скрипт, который в заданном тексте ищет все слова, начинающиеся на «Str», и переворачивает эти слова. На выходе скрипта должен быть текст с перевернутыми словами.
  3. Напишите регулярное выражение, которое ищет все ссылки в документе HTML.

Основные протоколы интернета

  1. По какому протоколу передаются данные в интернете?
  2. Назовите уровни модели OSI.
  3. В чем основные отличия протокола HTTP/1.1 от HTTP 1.0 ?
  4. Что такое заголовки HTTP?
  5. В чем состоит преимущество постоянных соединений?
  6. Какие методы запроса протокола HTTP вы знаете?

Работа в командной строке Linux

  1. Напишите команду, которая убьет все процессы, начинающиеся на «proc».
  2. Напишите команду, которая поставит папке и всем папкам и файлам, которые в ней хранятся права: чтение, запись, выполнение для владельца, чтение, запись для группы, выполнение для всех остальных.
  3. Какими средствами будете пользоваться, если нужно отслеживать запросы к web-серверу в реальном времени?

На этом все. Надеюсь мой список вопросов поможет кому-то подготовиться к прохождению собеседования на должность PHP-программиста.

Вопросы на собеседовании для PHP-программиста (часть 1)

Вопросы на собеседовании для php-программиста (часть 2)

]]> http://job-interview.ru/articles/post/104/feed 2 “Многопоточность” в PHP (stream) http://job-interview.ru/articles/post/92 http://job-interview.ru/articles/post/92#comments Tue, 28 Jul 2009 07:24:35 +0000 Pablo Monteagudo /articles/?p=92 Использование stream-функций.

Это вторая статья из серии “Многопоточность” в PHP.

В прошлый раз мы рассмотрели curl, теперь давайте поговорим о stream-функциях.

Вольный перевод документации:

Streams (потоки) были введены в PHP 4.3.0 как способ обобщить работу с файлами, сетью, сжатием данных и другими процессами, которые совместно используют единый набор функций. В простейшем определении, поток – объект ресурса, имеющий “потокообразное” поведение, т.е. из которого можно читать, в который можно писать и внутри которого можно перемещаться.

stream_socket-функции являются частью streams, при помощи них мы можем коннектиться или писать/читать данные, не дожидаясь завершения предыдущей операции.

Итак, дано: массив с урлами. Задача: непоследовательно получить их содержимое.

Давайте рассмотрим код, который решает поставленную нами задачу:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

<?php
// страницы, содержимое которых надо получить
$urls = array('www.yandex.ru', 'www.google.ru', 'www.mail.ru', 'www.rambler.ru');
 
$rtasks = array(); // задачи чтения
$wtasks = array(); // задачи записи
$results = array(); // результаты
 
foreach ($urls as $url) {
    // открываем отдельный сокет
    $sh = stream_socket_client($url.':80', $errno, $errstr, 10,
        STREAM_CLIENT_ASYNC_CONNECT|STREAM_CLIENT_CONNECT);
    if (!$sh) continue;
    // добавляем в задачи для записи
    $wtasks[$url] = $sh;
}
 
while ($wtasks || $rtasks) {
    // массив для сокетов с возможностью чтения
    $rtasks_ = $rtasks;
    // массив для сокетов с возможностью записи
    $wtasks_ = $wtasks;
 
    // ждем результатов из сокетов
    $n = stream_select($rtasks_, $wtasks_, $e=null, 10);
    if ($n > 0) {
        // сокеты, доступные для записи
        foreach ($wtasks_ as $sh) {
            // ищем урл страницы по дескриптору сокета в массиве задач записи
            $url = array_search($sh, $wtasks);
            // удаляем из задач записи
            unset($wtasks[$url]);
            // добавляем в задачи чтения
            $rtasks[$url] = $sh;
            // формируем http-заголовки
            $headers  = "GET / HTTP/1.0\r\n";
            $headers .= "Host: ".$url."\r\n";
            $headers .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.6) Gecko/2009011913 MRA 5.3 (build 02557) Firefox/3.0.6\r\n";
            $headers .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n";
            $headers .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n";
            $headers .= "Accept-Encoding: gzip,deflate\r\n";
            $headers .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n";
            $headers .= "\r\n";
            // записываем в сокет
            if (fwrite($sh, $headers) === false) fclose($sh);
        }
 
        // сокеты, доступные для чтения
        foreach ($rtasks_ as $sh) {
            // ищем урл страницы по дескриптору сокета в массиве задач чтения
            $url = array_search($sh, $rtasks);
            if (!$url) continue;
            // считываем результат из сокета
            $result = '';
            while ($r = fread($sh, 8192)) $result .= $r;
            // закрываем сокет
            fclose($sh);
            // удаляем из задач чтения
            unset($rtasks[$url]);
            // заносим html в массиы результатов
            $results[$url] = $result;
        }
    }
    else {
        break;
    }
}
?>

Сначала инициализируются три массива: $rtasks – в него будут заноситься сокеты, из которых можно читать данные, $wtasks – для сокетов, готовых к записи, и $results – массив для сохранения содержимого заданных страниц.

Затем в цикле функцией stream_socket_client открываются сокеты для каждого из урлов, при этом ставится флаг STREAM_CLIENT_ASYNC_CONNECT, который указывает, что каждое следующее соединение надо открывать не дожидаясь завершения открытия предыдущего. Флаг STREAM_CLIENT_CONNECT указывает, что мы создаем именно клиентское подключение.
Дескрипторы сокетов заносятся в массив $wtasks.

В 18-ой строке начинается главный цикл, и сразу массивам $rtasks_ и $wtasks_, передаваемым в функцию stream_select, присваиваются массивы, в которых хранятся сокеты для чтения и записи соответственно. Функция stream_select отслеживает наличие данных в потоках и принимает на вход несколько параметров: первый – это массив дескрипторов, в которых ожидается завершение операции чтения, второй – массив с дескрипторами, ожидающими завершение записи, третий – для особых случаев (поступление “out-of-band data” – внеполосных данных) и четвертый параметр – это таймаут. Массивы передаются в функцию по указателям, и как только функция возвращает число больше 0, в них будут находится сокеты, готовые к действиям.

В 28-ой строке мы смотрим, в какие сокеты можно записать данные (надо что-то отправить, прежде чем нам придет ответ-результат), и если такие сокеты есть, то удаляем из массива для записи текущий дескриптор, помещаем его в массив для чтения, и отправляем заголовки, необходимые для получения контента.
Далее, в 49-ой строчке, просматриваем сокеты, готовые для считывания из них данных, забираем содержимое, удаляем дескриптор из масива для чтения и закрываем сокет. Результат заносим в массив $results. Повторяем эти операции до тех пор, пока у нас остаются какие-либо открытые сокеты.

После работы скрипта нужный нам контент находится в массиве $results.

В статье рассмотрен пример работы с функциями stream_socket_*, на очереди асинхронные сокеты.

]]> http://job-interview.ru/articles/post/92/feed 9 PHP и HTTP http://job-interview.ru/articles/post/86 http://job-interview.ru/articles/post/86#comments Mon, 27 Jul 2009 19:00:02 +0000 tiger /articles/?p=86 В этой статье я постараюсь описать работу с HTTP-запросами в языке программирования PHP.

Очень часто на собеседованиях приходится слышать вопрос:

Что происходит, когда пользователь в адресной строке браузера, вводит адрес сайта и нажимает enter?

Ответ должен звучать примерно так:

Отправляется HTTP-запрос по протоколу TCP/IP на сервер, на котором расположен сайт. Далее программа web-сервер (обычно Apache, nginx или lighttpd) принимает этот запрос и в случае, если вызываемый файл — это обычный HTML, то посылает в ответ браузеру свой HTTP-ответ, в котором содержится этот HTML.

Если вызываемый файл — это скрипт, например PHP, то сначала передается управление этому скрипту, который после всех своих операций на выход подает HTML, который web-сервер отсылает HTTP-ответом обратно браузеру.

Получив от сервера HTML, браузер его преобразовывает в удобочитаемый вид согласно стандарту W3C, отправляет дополнительные запросы для отображения изображений или flash и пользователь видит содержимое сайта — текст, картинки, flash и т.д.

В этой статье я дам подробное описание HTTP-запросов и параметров, которые могут в нем содержаться. Потом представлю реализацию обмена HTTP-запросами посредством языка PHP — мы напишем простой прокси-сервер, при обращении к которому он возвращает браузеру страницу сайта, адрес которого был указан в GET-параметре.

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

Кстати, очень полезными бывают утилиты, отображающие HTTP-запросы, которые отправляет и получает браузер. Я пользуюсь для этого браузером Mozilla Firefox и утилитой HttpFox.

Итак, давайте рассмотрим пример.

Введем в адресную строку браузера http://example.com и нажмем enter.

В результате браузер отправит HTTP-запрос вида: 

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

В приведенном примере браузер хочет получить индексную страницу сайта example.com.

Получив запрос от браузера, web-сервер проверяет в своих настройках что является индексным файлом для сайта example.com.

Если это обычный HTML, например файл index.html, то просто возвращается его содержимое.

При запросе индексной страницы сайта http://example.com браузер получает от сервера следующий ответ:

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8 

<HTML>
<HEAD>
  <TITLE>Example Web Page</TITLE>
</HEAD>
<body>
<p>You have reached this web page by typing "example.com",
"example.net",
  or "example.org" into your web browser.</p>
<p>These domain names are reserved for use in documentation and are not available
  for registration. See <a href="http://www.rfc-editor.org/rfc/rfc2606.txt">RFC
  2606</a>, Section 3.</p>
</BODY>
</HTML>

Обратите внимание на 2 перевода строки в ответе сервера. Они являются разделением между параметрами ответа и телом сообщения, содержащего html, который и отображается в окне браузера.

В случае какого-либо скрипта, сначала происходит выполнение этого скрипта, который возвращает web-серверу HTML. Web-сервер в свою очередь отправляет этот HTML браузеру.

Представим себе, что индексной страницей сайта example.com является файл index.php. Web-сервер в этом случае, получив запрос от браузера, сначала передает управление интерпретатору PHP, который выполняет код, содержащийся в этом файле.

Например, в файле index.php содержался бы следующий код:

1
2
3
4
5
6
7
8
9
10

<?php
	if($GET['category'] == 1)
	{
		echo "<p>This is a category of example.com</p>";
	}
	else
	{
		echo "<p>This is a main page of example.com</p>";
	}
?>

Если ввести в адресной строке браузера http://example.com?category=1 и нажать enter, то браузер отправит примерно следующий запрос:

GET /index.php?category=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

От сервера придет в этом случае следующий ответ:

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 39
Connection: close
Content-Type: text/html; charset=UTF-8 

<p>This is a category of example.com<p>

Однако, если в адресной строке браузера ввести http://example.com/index.php, то ответ сервера будет таким: 

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 40
Connection: close
Content-Type: text/html; charset=UTF-8 

<p>This is a main page of example.com</p>

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

Начнем с HTTP-запроса, который отправляет браузер.

Первая строка – это строка запроса. Она содержит следующие поля, разделенные через пробел:

  • Метод запроса. Может принимать значения: OPTIONS, GET, HEAD, POST, DELETE, TRACE. Целью настоящей статьи не является рассмотрение всех методов. Нам будет достаточно метода GET. Если вы хотите получить описание каждого из методов, то советую обратится к документу RFC 2068
  • Запрашиваемый URI — путь до запрашиваемого ресурса на сервере. Если запрашивается главная страница сайта, то указывается путь до корневого каталога сервера – «/».
  • Версия HTTP-протокола. В этом поле содержится строка вида: «HTTP/1.1». О различных версиях протокола HTTP также можно прочитать в документе RFC 2086.

Далее после строки запроса следуют HTTP-заголовки. Описание каждого заголовка начинается с новой строки и представлено в виде:
ЗАГОЛОВОК: ЗНАЧЕНИЕ.

Рассмотрим заголовки, которые отсылает браузер в нашем примере.

  • Host. Значением для этого заголовка должно быть доменное имя и порт запрашиваемого ресурса. Значение представляется в виде:

    ДОМЕННОЕ_ИМЯ:ПОРТ

    Порт можно не указывать. В этом случае предполагается, что используется порт по умолчанию — в нашем случае это порт 80.

    В нашем последнем примере для этого заголовка устанавливается значение example.com, т.е. браузер отправляет запрос на сервер example.com и хочет обратиться к файлу /index.php с переданным GET-параметром category=1.

  • User-Agent. Содержит информацию о клиенте, который инициировал запрос к серверу, а также его программное обеспечение. Значение этого поля описывает ряд компонентов клиента. Оно может быть множественным, где все значения отделены друг от друга через пробел.

    В нашем последнем примере значением этого заголовка является:

    Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8

    Здесь описываются параметры браузера и операционной системы — браузер Mozilla Firefox 3.0.8, основанный на движке Gecko, операционная система Linux Suse 11.1 оконной системой X11, процессор с архитектурой i686.

    Этот заголовок используется для статистических целей.

  • Accept. В этом заголовке клиент передает список форматов, которые допустимы для ответа. Значение этого поля хранит список допустимых форматов, разделенных через запятую. Кроме того, для каждого формата можно указать уровень предпочтения от 0 до 1. Если уровень предпочтения не указан, то он считается равным 1. Значение в этом поле должно соответствовать виду:

    ФОРМАТ1[;q=УРОВЕНЬ_ПРЕДПОЧТЕНИЯ1],ФОРМАТ2[;q=УРОВЕНЬ_ПРЕДПОЧТЕНИЯ2]…

    В нашем примере браузер в этом заголовке посылает значение:

    text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

    Его можно прочитать следующим образом: браузер предпочитает ответы в форматах text/html, application/xhtml+xml. Если сервер не может послать ответ в этих форматах, то браузер будет ожидать ответ в формате application/xml. Если же и в этом формате сервер не может послать ответ, то браузер примет ответ в любом формате.

  • Accept-Language. Этот заголовок аналогичен заголовку ACCEPT, только здесь браузер сообщает серверу о своих предпочтениях о естественных языках, в которых должен приходить ответ.

    В нашем примере значением заголовка является:

    ru,en-us;q=0.7,en;q=0.3

    Браузер сообщает серверу, что ждет ответ на русском языке, но также примет ответ на «американском английском» и английском языках.

  • Accept-Encoding. Подобен ACCEPT. В этом заголовке браузер указывает какое кодирование к содержимому допустимо в ответе. Кодирование содержимого необходимо для сжатия или других его преобразований.

    В нашем примере в ответе для браузера допустимо сжатие программой gzip и механизмом deflate:

    gzip,deflate

  • Accept-Charset. Этот заголовок браузер посылает, чтобы сообщить серверу о своих предпочтениях кодировки ответа.

    В нашем примере этот заголовок принимает значение:

    windows-1251,utf-8;q=0.7,*;q=0.7

    Браузер ждет ответ от сервера в первую очередь в кодировке windows-1251, но также примет ответ в любой кодировке.

  • Keep-Alive. Заголовок Keep-Alive содержит значение, которое означает в течение какого времени в секундах будет удерживаться соединение. Этот заголовок следует отправлять только в том случае, если заголовок Connection содержит значение keep-alive.

    Поддерживается только для протокола HTTP версии 1.1.

    В нашем примере этот заголовок содержит значение 300, т.е. браузер сообщает серверу, что намерен удерживать постоянное соединение с сервером в течение 300 секунд.

  • Connection. Информация о проводимом соединении. В нашем примере этот заголовок принимает значение keep-alive, которое говорит серверу о том, что браузер хочет установить постоянное TCP соединение.

    До появления постоянных соединений для запроса каждой страницы сайта устанавливалось отдельное соединение. Открытие каждый раз отдельного соединения требует дополнительной нагрузки на сервер.

    Например, браузер может запрашивать какую-то страницу с изображениями. После получения HTML страницы ему нужно будет запросить с сервера каждое изображение. При каждом запросе изображения будет открываться отдельное TCP соединение, что приведет к дополнительной нагрузке.

    Использование постоянных соединений решает эту проблему. Если обе стороны (клиент и сервер) их поддерживают, то, в случае приведенного примера, HTML страницы и каждое изображение могут быть получены за одно TCP соединение.

    Заголовок Connection поддерживается только для протокола HTTP версии 1.1.

    Этот заголовок также может принимать значение close. В этом случае клиент сообщит серверу, что после принятия HTTP-запроса соединение должно быть разорвано.

А теперь давайте рассмотрим параметры HTTP-ответа, который отправляет сервер браузеру.

Первая строка — это строка состояния, которая состоит из следующих полей, разделенных пробелом:

  • Версия протокола HTTP. В нашем ответе от сервера в этом поле содержится HTTP/1.x. Сервер поддерживает протоколы HTTP 1.0 и 1.1.
  • Код состояния ответа. С возможными кодами состояния можно ознакомиться в документе RFC 2068. В нашем случае от сервера нам необходим код состояния ответа, равный 200, который означат, что запрос браузера был выполнен удачно.
  • Комментарий. Комментарий для кода состояния. Если код состояния 200, то комментарий будет «OK».

За строкой состояния следуют HTTP-заголовки, каждый начинается с новой строки. В нашем примере сервер отсылает следующие HTTP-заголовки:

  • Date. В этом заголовке хранится дата в формате RFC 822, описывающее когда отправляемый ответ был сгенерирован. Но это теория, на практике значением этого заголовка может быть любое время.

    В нашем примере в этом заголовке содержится:

    Tue, 21 Jul 2009 17:09:54 GMT.

  • Server. В этом заголовке содержится информация о программном обеспечении, которое используется на сервере, а также его компонентах. Если ответ от сервера направляется через proxy, то используется заголовок «Via».

    В ответе от сервере на наш запрос содержится следующее:

    Apache/2.2.3 (CentOS)

    Это означает, что на сервере используется web-сервер Apache версии 2.2.3. В качестве операционной системы используется дистрибутив Linux CentOS.

  • Last-Modified. В этом заголовке сервер сообщает дату последнего изменения какой-либо сущности — файла, базы данных и т.п. В нашем случае сервер отправляет дату последнего изменения файла index.php.

    Этот заголовок важен для браузера при использовании механизма кеширования. При обращении к какой-либо странице браузер кеширует ее. При повторном обращении к этой странице браузер, основываясь на заголовке Last-Modified проверит не устарела ли страница, сохраненная в кеше. Если нет, то браузер не будет еще раз считывать данные, а выведет страницу из кеша.

    В ответе сервера из нашего примера в этом заголовке хранится:

    Tue, 15 Nov 2005 13:24:10 GMT

  • Etag. В этом заголовке содержится метка объекта ресурса. В нашем случае в качестве объекта выступает файл index.php.

    Наряду с заголовком Last-Modified значение этого заголовка используется при кешировании браузером. При первом запросе страницы браузер сохраняет значение Etag для страницы. При повторном запросе страницы значение Etag, которое пришло от сервера, сравнивается с тем, которое хранится в кеше браузера. Если они равны, то браузеру нет смысла считывать еще раз данные страницы, он просто возьмет их из кеша.

    В нашем примере в ответе сервера Etag имеет следующее значение:

    “b80f4-1b6-80bfd280″

  • Accept-Ranges. Этот заголовок сообщает клиенту о том, что он может запрашивать данные с сервера фрагментами, указывая их смещение в байтах.

    Используется для реализации скачивания файлов с докачкой.

    В нашем примере сервер поддерживает эту возможность, о чем он и сообщает, передав в заголовке Accept-Ranges значение bytes.

    Зная эту возможность, браузер может передать серверу смещение в байтах, с которого необходимо начать передачу файла. Для этого браузер посылает заголовок Range с параметром bytes, значение которого и является смещением в байтах. Например:

    Range: bytes=2048

    Этот заголовок означает, что браузер запросил у сервера содержимое файла, начиная с 2-го мегабайта.

  • Content-Length. Этот заголовок содержит размер тела HTTP-ответа сервера.
    В нашем примере размер тела сообщения 40.

  • Connection. Как и в случае для клиента, этот заголовок предоставляет информацию о проводимом соединении. В нашем примере этот заголовок принимает значение close, которое говорит клиенту о том, что сервер либо не поддерживает постоянное TCP соединение, либо он просто отказывает браузеру в постоянном соединении.

  • Content-Type. В этом заголовке содержится формат тела HTTP-ответа сервера.

    В нашем примере в этом заголовке содержится:

    text/html; charset=UTF-8

    Это означает, что сервер отвечает браузеру данными в формате text/html и кодировке UTF-8.

    В этом заголовке сервера также может храниться, например, «text/css; charset=utf-8» при ответе браузеру на запрос файла CSS. Или, например, может храниться «image/gif» при ответе браузеру на запрос GIF-изображения.

    О других форматах тела сообщения в ответах сервера читайте в RFC 822.

После HTTP—заголовков в ответе сервера содержится 2 перевода строки, за которыми следует само тело сообщения. 2 перевода строки служат разделением между параметрами ответа сервера и телом сообщения, в котором содержится html, отображаемый браузером.

В нашем примере в теле сообщения ответа от сервера содержится:

<p>This is a main page of example.com</p>

Ну а теперь напишем простой прокси-сервер на PHP, который покажет практическое использование упомянутых HTTP-заголовков. 

<?php
$body = "";
// доменное имя передаем в GET-параметре $_GET['host']
$host = $_GET['host'];
// открываем сокет на стандартном для HTTP порту 80
$hSocket = fsockopen($host, 80, $errno, $errstr, 30); 
if ($hSocket)
{
    // первой строкой идет строка запроса
    $request = "GET / HTTP/1.1\r\n";
    // указываем доменное имя
    $request .= "Host: $host\r\n"; 
     // пусть мы будем для сервера браузером Mozilla Firefox
    $request .= "User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.\r\n";
    // указываем форматы, в которых будем ожидать ответ от сервера
    $request .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"; 
    // языки, на которых ожидаем ответ
    $request .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n"; 
    // указываем какое кодирование к содержимому допустимо в ответе. 
    //Только в этом случае нужно будет раскодировать содержимое.
    //$request .= "Accept-Encoding: gzip,deflate\r\n"; 
    // выставляем предпочтения для кодировок ответа
    $request .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n"; 
    // будем удерживать постоянное соединение в течение 300 секунд
    $request .= "Keep-Alive: 300\r\n";
    // открываем постоянное соединение
    // здесь мы завершаем передачу HTTP-заголовков, 
    // поэтому в конце обязательно указываем 2 перевода строки
    $request .= "Connection: keep-alive\r\n\r\n"; 
    // посылаем HTTP-заголовки через открытый сокет
    fwrite($hSocket, $request); 
    // флаг, указывающий на то, что считывается тело запроса
    $bIsData = false; 
    while (!feof($hSocket)) // считываем ответ от сервера
    {
        $str = fgets($hSocket, 128); // построчно
        if($bIsData)
        {
            $body .= $str; // тело запроса записываем в переменную $body
        }
        // встретилась строка, содержащая только перевод строки, это означает, 
        //что дальше пойдет тело запроса
        elseif($str == "\r\n") 
        {
            $bIsData = true;
        }
    }
    fclose($hSocket); // закрываем сокет
 
    // указываем на то, чтобы web-сервер отправил браузеру заголовки 
    // Last-Modified, Connection и Keep-alive
    header("Last-Modified: Tue, 21 Jul 2009 17:09:54 GMT", true);
    header("Connection: Keep-Alive", true); //
    header("Keep-Alive: timeout=30, max=100", true);
    // передаем тело запроса
    echo $body;
}
 
// работа php-скрипта закончена, теперь web-сервер отправляет ответ браузеру
?>

Чтобы отправить заголовки серверу, необходимо сначала открыть сокет. Сокет — это программный интерфейс, который позволяет обмениваться данными между процессами. При этом процессы могут выполняться на разных компьютерах, связанных сетью.

В нашем случае один процесс — это процесс браузера, второй — это процесс web-сервера, запущенный на удаленном компьютере.

В PHP сокет открывается функцией fsockopen. Далее в переменную $request мы записываем все нужные нам заголовки и отправляем их серверу функцией fwrite. После этого мы построчно считываем ответ сервера пока не будет достигнут конец данных (feof). После получения ответа мы отправляем этот ответ браузеру вместе с заголовками, которые в PHP выставляются функцией header.

Этот скрипт принимает через GET-параметр доменное имя сайта и отправляет к нему HTTP-запрос, считывает ответ и отдает этот ответ web-серверу, который отправляет его браузеру.

При помощи подобного скрипта вы можете сами поиграться с отправляемыми HTTP-запросами.

Нам этом все. Спасибо за внимание.

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

http://ru.wikipedia.org/wiki/HTTP – статья, подробно описывающая HTTP.

http://www.faqs.org/rfcs/rfc2068.html – документ RFC 2068.

]]> http://job-interview.ru/articles/post/86/feed 4