Работа для программистов » web http://job-interview.ru/articles вакансии, вопросы, статьи Thu, 29 Mar 2012 20:53:41 +0000 http://wordpress.org/?v=2.8 en hourly 1 Разработка в среде WEB: Java или PHP? http://job-interview.ru/articles/post/356 http://job-interview.ru/articles/post/356#comments Tue, 28 Feb 2012 18:31:26 +0000 /articles/?p=356 Вместо предисловия.

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

Начнем.

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

Порог вхождения.

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

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

PHP считается простым языком. Это не удивительно: от открытия учебника до первого “HelloWorld-a” проходит не больше 5 минут. С одной стороны это хорошо. Но подводных камней не мало.

Потратив неделю на изучение PHP, можно научиться базовым приемам ввода-вывода, примитивной выборке из БД и парочке других алгоритмов обработки информации. С усложнением задач появляется соблазн изобретать “велосипеды” и “костыли” на основе старых знаний, делая код нечитабельным, уничтожая возможность дальнейшей поддержки на корню.

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

Что касается Java, порог вхождения очень высокий. Вместо “Установка LAMP под Ubuntu” и “Скачать самоучитель PHP“, необходимо вникнуть в сервлеты, взаимодействие между ними, jsp, научиться работе с каким-нибудь фреймворком.

Плюс ООП, который в Java обязателен. Если проводить аналогию, начало работы сравнимо с высшей математикой в ВУЗ-е: всех неспособных отправить на службу родине.

Подобный подход к оценке языка не панацея. Достаточно много серьезных проектов, написанных на PHP. Более того, на данный момент в сфере WEB-разработок он доминирует.

Синтаксис и код.

Одна из обсуждаемых проблем Java – длиннейшие названия классов и стандартных методов. Чего только стоит “System.out.println()” оного вместо “echo” на PHP. Конечно, это легко решается “import-ом” в начале документа или выбором современной IDE, в которой достаточно написать первую букву метода или поля, как появится возможность выбора нужного из списка. Тем не менее, отрицать впечатляющий объем кода на Java – предвзято.

PHP тоже не идеален. Взять к примеру обязательный знак доллара перед переменной. Конечно, рациональное зерно различия между обозначениями переменных и методами(функциями) присутствует. Лично у меня это вызывает жуткую головную боль. В первую очередь от созерцания самого знака. Плюс, я так и не сумел привить у себя
привычки ставить доллар перед каждой переменной. Слишком меркантильно, что-ли…

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

Здесь принудительное ООП Java и Javadoc для документации дают ощутимый прирост в копилке аргументов “За Java”.

В PHP эти возможности так же есть. Сравнительно недавно я узнал о аналогах Javadoc в PHP- phpdoc/PhpDocumentor.

С известных версий PHP поддерживает объектный подход(ООП). Правда он смешанный, и соблазн написать простую функцию без обертки очень большой.

Техническая площадка.

С кодом мы разобрались. А вот что касается хостинга, Java в проигрыше. PHP-хостинг распространен и он дешевле.

Правда под вопросом, стоит ли экономить на хостинге, если проект серьезный? Тем не менее, то, что заменить техническую основу проекта на PHP проще – факт.

Другой вопрос, если проект используется в интрасети. Стоимость хостинга отпадает. И программирование на стороне клиента дает плюс в сторону Java. Интеграция апплетов на нем в сети интернет потерпела крах, так как для запуска они требуют имплементатор на локалхосте. Но когда клиенты доступны физически, проблем нет.

Единая платформа, без связки разных языков – очевидный плюс.

Вместо заключения.

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

Претензий на объективность у меня нет. Я попытался, насколько успешно- не знаю. Буду рад аргументированной критике.

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

]]> http://job-interview.ru/articles/post/356/feed 513 Ускоряем проект на 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 /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 561 Как я проводил собеседование http://job-interview.ru/articles/post/290 http://job-interview.ru/articles/post/290#comments Sun, 23 Jan 2011 17:44:01 +0000 /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 194 Хочу открыть интернет-магазин http://job-interview.ru/articles/post/271 http://job-interview.ru/articles/post/271#comments Sun, 30 May 2010 13:31:35 +0000 /articles/?p=271 Наверное, многие, проработав определенное время в какой-то отрасли, приходят к мыслям о том, что нужно попробовать что-то свое. С некоторых пор такие мысли стали посещать и меня.

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

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

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

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

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

  • Фриланс.

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

  • Web-студия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планы

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

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

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

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

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

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

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

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

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

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

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

]]> http://job-interview.ru/articles/post/271/feed 346 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 /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 5538 Вопросы на собеседовании для PHP-программиста (часть 1) http://job-interview.ru/articles/post/12 http://job-interview.ru/articles/post/12#comments Tue, 30 Jun 2009 19:49:54 +0000 /articles/?p=12 С некоторых пор я решил записывать все задаваемые мне вопросы на собеседованиях.
В этой статье хотел бы поделиться ими с аудиторией job-interview. За весь мой опыт прохождения собеседований вопросов набралось немало. Во всяком случае на одну статью не хватит, поэтому здесь я выложу часть из них. Остальные вопросы буду выкладывать в последующих статьях.

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

  • PHP
  • Задачи по составлению различных запросов SQL
  • Администрирование СУБД (обычно это MySQL)
  • Основные принципы ООП
  • Регулярные выражения
  • Основные протоколы интернета
  • Работа в командной строке Linux

Итак, начнем.

PHP

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

2.  

1
2
3
4
5

<?php
$i = 10;
$i += ++$i + $i + $i++;
print $i;
?>

     Сколько выведет? Почему?

3.  

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
class ListItem {
var $next;
}
 
$a = new ListItem();
$b = new ListItem();
$c = new ListItem();
 
$a->next = $b;
$b->next = $c;
$c->next = null;
?>

     Необходимо написать функцию, которая на вход получает объект $а, а возвращает перевернутый список.

4.  Как реализовать множественное наследование в PHP?

5.  Чем отличается наследование в javascript от наследования в PHP?

Запросы SQL

  1. Есть таблица currency_course, в которой перечислены курсы валют за конкретную дату.
    Поля таблицы currency_course:
    currency (тип валюты — USD, EUR и т.д.),
    date (дата установленного курса),
    course (курс валюты)

    Требуется выбрать последние курсы по каждой валюте.
  2. В таблице 1 000 000 записей. Необходимо предложить варианты выбора 10 случайных записей. Запрос вида select * from table order by rand() limit 10 не подойдет, т.к. очень «тяжелый».
  3. В таблице 1 000 000 записей. Есть поле, которое принимает только одно из двух значений. Стоит ли индексировать по этому полю?
  4. Необходимо предложить структуру базы данных для хранения древовидных комментариев.
  5. Имеется таблица покупателей с полями: id, name
    А также таблица продаж: id, cust_id, date, summ_pay
    Необходимо:
    а) Вывести лучшего покупателя.
    б) Вывести лучших покупателей за каждый месяц.

Пока все. Продолжение следует…

]]> http://job-interview.ru/articles/post/12/feed 181 Нужны ли логические задачи на собеседовании? http://job-interview.ru/articles/post/7 http://job-interview.ru/articles/post/7#comments Sun, 28 Jun 2009 11:51:16 +0000 /articles/?p=7 Не так давно я занялся поисками работы на должность web-программиста. Скажу сразу, что мой опыт работы в этой области составляет 2 года. Я просмотрел все имеющиеся вакансии в интернете, разослал свое резюме.

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

  • PHP
  • MySQL
  • JavaScript
  • ООП

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

Интерес к этой вакансии у меня был огромный – в описании к ней было указано, что компания работает в игровой индустрии и производит различные MMORPG и flash игры, а к играм я с детства неравнодушен.

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

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

Привожу эти задачи с собеседования.

  1. В стакан положили бактерии. Каждую секунду бактерии увеличиваются в 2 раза. Известно, что стакан заполняется полностью за минуту. За какое время стакан наполнится наполовину?
  2. Представьте себе, что земной шар обмотали веревкой по экватору. Потом веревку увеличили на 1 метр и расположили так, что любая точка экватора равноудалена от веревки. Сможет ли между веревками пролезть мышь?

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

По моему 10 минут — это слишком мало для таких задач, тем более на собеседовании, где человек в любом случае волнуется.

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

Придя домой, я решил их и потратил на поиски решения примерно час.

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

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

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

Также жду варианты решений задач.

]]> http://job-interview.ru/articles/post/7/feed 1024 Добро пожаловать на сайт, посвященный поиску работы для программистов. http://job-interview.ru/articles/post/1 http://job-interview.ru/articles/post/1#comments Mon, 15 Jun 2009 14:12:35 +0000 http://jo-in.ru/blog/?p=1 Предполагаемая аудитория – это люди, занимающиеся web-разработками, системным программированием и всем тем, что связано с IT.

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

В разделе “Вопросы на собеседовании” мы будем выкладывать самые распространенные вопросы, которые задает работодатель соискателю, откликнувшемуся на его вакансию программиста. Раздел будет постоянно пополняться, сейчас в нем можно найти вопросы по PHP, C++, .NET и базам данных.

В разделе “Вакансии” вы сможете найти самые свежие объявления от работодателей для программистов. Раздел обновляется несколько раз в день.

Мы также предлагаем вам проверить свои знания, посетив раздел “Тесты”. Зарегистрированные пользователи при желании могут разместить свой тест, который им предлагали пройти на собеседовании, а затем в личном кабинете следить за статистикой прохождения теста другими пользователями сайта.

В разделе “Книги” собраны книги для программистов. Здесь можно найти литературу по самым разным IT-тематикам: устройство компьютера и работа с “железом”, языки программирования и алгоритмы, компьютерные сети, а также многое другое.

Если вы опытный программист:

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

Если вы начинающий программист:

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

Итак,

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

Присоединяйтесь к нашей группе Вконтакте.

Следите за нашими вакансиями в Twitter  

Желаем удачи,
Команда Job-Interview.ru

]]> http://job-interview.ru/articles/post/1/feed 8328