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

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

На практике даже в случае больших сложных и долгосрочных программных проектов встречается абсолютно наплевательское отношение к архитектуре и коду. Особенно это свойственно аутсорсинговым проектам, где пишут «не для себя». Здесь главная задача — именно результат. Работу сдал, деньги получил и забыл. А с программой потом будут мучаться уже другие. Причем, это правило действует как в масштабе фирмы-аутсорсера, так и в масштабе конкретного разработчика.

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

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

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

Но справедливости ради, надо заметить, что в последнее время аутсорсеры стараются выходить на путь качества, а не количества. Многие заказчики стали понимать, что им подсовывают каку и искать более серьезных партнеров. Так что похоже на то, что в среднесрочной перспективе 80% (по принципу Паретто) разработок должны быть по качеству архитектуры и кода выше среднего.

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

• количественный: много слабых разработчиков пишут много кода — получаем ожидаемый результат;
• качественный: мало сильных разработчиков пишут среднее количества кода — получаем такой же ожидаемый результат.

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

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

Все написанное выше является моим ИМХО и основано на личных наблюдениях. Контраргументы принимаются и тема подлежит обсуждению для выяснения истины.

Да, питонисты — тихие спокойные ребята, а пхп-шники — агрессивные дурачки, потому что:

1) Питонисты и Рубироиды при каждом удобном случае лезут в топики про php и кричат, что php — гавно, а руби/питон — круто!

2) На форумах и в IRC-чатах, когда кто-то задает вопрос `как это сделать в php/java/с++/c#` тут же находятся рубироиды и питонщики, которые кричат, что это не надо делать на данном языке, а надо делать на руби или питоне! А автор вопроса — мудак!

3) Когда дается ответ на вопрос `как это сделать в php/java/с++/c#` в несколько строк кода, тут же находится довольный рубироид и пишет все в одну только ему понятную строчку и кричит `вот как все просто на руби, а вы мудаки все еще пишете на ХХХ`!

Как же это уже раздражает…

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

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

Существуют как минимум 3 профайлера PHP-кода: Xdebug, Advanced PHP Debuger и DBG. Скажу честно, два последних я даже не рассматривал по двум причинам: Xdebug — самый популярный, Xdebug встроен в сборку xampp, которая стоит на моей локальной машине.

Установка Xdebug

Интеграция Xdebug’а в PHP очень проста. С сайта www.xdebug.org необходимо скачать DLL-extension для вашей версии PHP. Вот файл для PHP 5.2.1-5.2.6 под Windows. Скачанный файл необходимо положить в каталог расширений PHP (extension_dir). А в php.ini добавить следующие строки:

extension=php_xdebug.dll

[XDebug]
;; Only Zend OR (!) XDebug
zend_extension_ts=»c:\php\ext\php_xdebug.dll»
xdebug.remote_enable=true
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.profiler_enable=1
xdebug.profiler_output_dir=»c:\temp»

При этом строки секции [Zend] требуется закомментировать (поставить ; в начале каждой строки):

[Zend]
;zend_extension_ts = «c:\php\zendOptimizer\lib\ZendExtensionManager.dll»
;zend_extension_manager.optimizer_ts = «c:\php\zendOptimizer\lib\Optimizer»
;zend_optimizer.enable_loader = 0
;zend_optimizer.optimization_level=15

Установите правильные пути в параметры zend_extension_ts и xdebug.profiler_output_dir секции XDebug. Путь xdebug.profiler_output_dir — это каталог, в который будет записан файл отчета.

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

Установка KCachegrind под Windows

Открываем любую страницу вашего сайта и в каталоге xdebug.profiler_output_dir появляется файл отчета. Открывать его в Блокноте или другом средстве просмотра текстовых файлов нет никакого смысла. Его формат невозможно воспринять в текстовом виде. Для просмотра файла отчета понадобится средство KCachegrind, которое требует наличия KDE для запуска.

Есть, правда, еще WinCachegrind, но эта программулина глючная, слабенькая и с 2005 года не обновляется. Мой файл отчета она прочитать не смогла (parse error).

Итак, приступаем к установке KCachegrind под Windows. Благо, она абсолютно простая.

1. Зайдите на www.winkde.org/pub/kde/ports/win32/installer/ и скачайте самую последнюю версию установщика.
2. Запустите установщик (есть картинки процесса установки), выберите каталог установки (например в C:\KDE), скачайте то, что вам нужно (я выбрал все пакеты — это около 230 Мб).
3. Добавьте переменную окружения KDEDIRS (Пуск > Панель управления > Система > Дополнительно > Переменные среды, нажмите «Создать» в разделе Пользовательские переменные и создайте переменную с именем KDEDIRS и значением равным папке, в которую Вы установили KDE4, напр. C:\KDE).
4. Добавьте папку библиотек, %KDEDIRS%\lib, и папку исполняемых файлов, %KDEDIRS%\bin, к переменной %PATH% Windows. (Пуск > Панель управления > Система > Дополнительно > Переменные среды, дважды щелкните на системной переменной Path и добавьте эти строки, разделяя их точкой с запятой.)
5. Если у Вас не установлена Visual Studio 2005 (или 2008), то скачайте и установите «Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)«.
6. Попробуйте запустить какое-нибудь Qt приложение в папке bin, например linguist.exe.
7. Если получилось, попробуйте запустить любое приложение KDE, такое как kwrite.exe.

Дополнительная информация по установке.

На этом установка закончена. Вы можете запустить KCachegrind (c:\KDE\bin\kcachegrind.exe) и скормить ей файл вашего отчета профайлера.

Дополнительную информацию по профилированию PHP-кода можете почитать на сайте Zend’а, а я планирую написать еще статейку на эту тему, может даже завтра.

Следующий пример абсолютно работоспособен:

<?php

$name = ‘что угодно — 1 + 44.4’;

$$name  = ‘ДА!’;

echo $$name;

Оказывается, шаблонизатор для PHP-сайтов Smarty еще жив! 17 октября на сайте появилась новость о том, что доступен альфа-релиз 3-й версии со значительными изменениями, который не совместим с версией 2.

Так как самомуписать обзор изменений лень, приведу выжимку из обсуждения темы на habrahabr’e.

Интерфейс шаблонизатора особо не изменился. Это всё те же display(), fetch() и assign(), которые покрывают процентов 99 всех потребностей. Исчез метод assign_by_ref().

Внутренности же претерпели более существенные изменения:

• Отказ от поддержки PHP4 и полное использование объектно-ориентированных возможностей PHP5. То есть в шаблонах можно использовать разыменования объектов без костылей;
• Объектно-ориентированный подход затронул и плагины: теперь каждый плагин является классом, отнаследованным от Smarty_Internal_PluginBase
• Файл основного класса — Smarty.class.php — стал подозрительно маленьким: всего 11 кб, включая здоровенные спойлеры лицензии LGPL ;)
• Все требуемые элементы, исключённые из ядра, подгружаются лишь по мере необходимости (lazy loading)
• Маленькая приятность — встроенная реализация паттерна singleton.
• Поддержка нативных PHP-шаблонов.

Надо сказать, что по сравению с веткой 2.x, дистрибутив значительно потолстел: папка libs, экспортированная из SVN, заняла немногим менее 800 кб, в то время как в версии 2.6.20 её вес был был порядка 320 кб.

Подробности о релизе — в официальном README.

Желающие могут вытащить версию из SVN:
svn checkout smarty-php.googlecode.com/svn/branches/Smarty3Alpha/

Вот тут groups.google.com/group/smarty-developers/browse_thread/thread/c29ae569842882cd немного про синтаксис:

PHP: <?= $foo ?>
Smarty: {$foo} // same as Smarty 2

PHP: <?= $foo[‘bar’] ?>
Smarty: {$foo[‘bar’]} // no more {$foo.bar}

PHP: <?= $foo[$bar][$foo[‘bar’]] ?>
Smarty: {$foo[$bar][$foo[‘bar’]] ?> // identical to PHP

PHP: <?php foreach($foo as $bar) {… } ?>
Smarty: {foreach $foo as $bar}… {/foreach} // just a delimiter
adjustment

PHP: <?php for($x = 0; $x<$y; $x++) {… } ?>
Smarty: {for $x=0; $x<$y; $x++}… {/for} // get rid of {section}

PHP: <?php if($foo == $bar && $blah !== ‘ziggy’) {… } ?>
Smarty: {if $foo == $bar && $blah !== ‘ziggy’}… {/if}

Zend Framework — это круто. Круто, потому что удобно и логично. Потому что в нем нет ничего лишнего: можно использовать как весь фреймворк целиком, так и отдельные его компоненты. Все компоненты можно заменить своими, не нарушая целостности фреймворка. Зенд не представляет готовые части сайта, и тем более — сайты. Zend Framework — это помощник в создании сайта, не более того. Очень гибкий, масштабируемый.

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

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

Изучать ZF начал с версии 1.6. Почитал Quick Start, затем начал читать мануал. Обратил внимание, что большинство идей ZF сходятся с теми идеями, на которых я строил свой движок, причем автономно, не изучая особенности других фреймворков. Только вот реализация этих идей, естественно, у ZF гораздо лучше, полнее. Факт схожести идей заложил в моем сознании доверие к этому фреймворку. Кроме того, слышал хорошие отзывы о нем от других программистов, которые использовали раньше и используют сейчас разные фреймворки и имеют достойный опыт сравнения.

Может быть эта запись в блоге подвигла вас на изучение ZF? Тогда расскажу вам вот что. Прежде всего, сходите на сайт Zend Framework‘а и оглядитесь вокруг :) Изучение начинайте с Quick Start‘а. Там все довольно хорошо описано, но с большего. Т.е. вы сможете подготовиться к восприятию тонкостей и деталей подробного мануала. Соберите на вашем сервере сайт, который предлагает Quick Start, поэкспериментируйте с ним. Только после этого переходите к полному руководству программиста.

Так как руководство состоит из описания отдельных компонентов фреймворка (52 главы-компонента на данный момент), нужно определиться, с чего начать. Поможет опредлитсья вам как раз Quick Start. Я приведу свой порядок изучения: Introduction, Zend_Controller, Zend_Cache, Zend_Loader, Zend_View, Zend_Layout, Zend_Config, Zend_Db. Дальнейший порядок, в принципе, значения не имеет.

Выпустил новую версию программы Калькус для КПК на базе Windows Mobile. Доработана арифметическая база, исправлены многие баги в ее работе. Интерфейс пока затронут не был, но в следующих версиях, когда руки дойдут и до него, все поменяется основательно. Пока предлагаю потестировать вычислительную часть программы.

Подробнее о программе в предыдущей записи. Баги шлите на feedbee@gmail.com. Программа бесплатная в использовании.

В архиве (23 Кб) инсталляционный cab и отдельно exe + const-файл версии 0.3.2 beta.

Единственный нюанс по использованию программы: если сделать тап (долгое нажатие) на область, где печатаются цифры, выпадет меню для ввода предустановленных констант из файла calcus.const.

Во время отпуска решил занять себя написанием программы для КПК под управлением Windows Mobile (PPC) калькулятор. Писал на C#.NET.

Памяти программа много не отъедает, на моем Gigabyte i350 не тормозит совсем. Написана для себя. Бета-версия (0.1.2) доступна для скачивания и свободного использования. Баги шлите на feedbee@gmail.com.

Программа бесплатная в использовании.

В архиве (24 Кб) инсталляционный cab и отдельно exe +const-файл.

Единственный нюанс по использованию программы: если сделать тап (долгое нажатие) на область, где печатаются цифры, выпадет меню для ввода предустановленных констант из файла calcus.const.

Статья с пошаговой инструкцией по установке memcached под ОС Windows. Скачать дистрибутив для Win32 можно отсюда: http://jehiah.cz/projects/memcached-win32/

Мануал по пользованию memcached из PHP: http://www.php.net/memcache.

Что кэшируем?

1. Самое важное: кэширование тяжелых запросов к БД, которые при нагрузке тормозят выполнение и грузят сервер. Обычно проблема кэширования запросов заключается в том, что надо знать, когда кэш уже не актуален. Для этого есть два пути: «срок хранения» кэша по времени и сброс кэша во время добавления/изменения записей, влиящих на него. Первый способ имеет смысл только тогда, когда не обязательно отображать данные самой последней свежести. В большинстве же случаев, нужно использовать второй способ.

2. Кэширование результатов запросов, которые очень редко меняются. Например, если вы храните настройки сайта в базе, то при каждой загрузке страницы эти настройки надо получить из базы. Такой запрос отработает моментально быстро, и очевидной необходимости его кешировать нет. Но если выделить с десяток таких запросов, то их суммарное время уже можно считать значительным. При этом нагрузка ложится на часто самое узкое место в производительности сайта — демона базы данных. По-этому, может иметь смысл хранить результаты таких запросов на сервере кэширования. Для такого кэширования подойдет только способ 2 из пункта 1. Кстати, сюда же можно отнести кэширование «статических страниц», которые динамически генерирует CMS.

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

Юзерозависимость

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

В случае юзерозависимой сущности кэширования надо хранить не один элемент данных (например, число), а массив этих элементов, в котором ключ — id пользователя. И операции с такой сущностью должны быть следующие: а) получение/установка/удаление данных сущности для данного пользователя, б) получение/удаление данных сущности для всех пользователей. Для обеспечения автоматизации работы такого функционала удобно написать класс-оболочку для memcached, заточенную под конкретный фреймворк/cms (так как подсистема пользователей у всех реализована по-разному).

Чего не хватает в memcache?

Вобщем-то всего там хватает, потому что сама библиотека (представленная как extionsion в php) представляет собой лишь инструмент для хранения кэшированных данных. Чтобы обеспечить удобную работу с кэшем, необходимо надстроить над механизмом хранения контроллер взаимодействия (интерфейс). В первую очередь он должен обеспечить функционал «пространств имен» для создания условий модульной разработки, что очень важно в MVC. Так же он должен обеспечить работу с юзерозависимыми данными через пару «ключ—id пользователя» и соответствующие связанные операции, упомянутые выше. Нужна и возможность пометки данных по принадлежности к некоему классу, чтобы потом очистить сразу весь кэш, относящийся к данному классу (например, при обновлении таблицы, от которой зависит вся хранимая в кэше информация данного класса).

Думаю, что завтра реализую оболочку для API memcached в PHP, которая реализует эти три дополнения, и открою ее для всех желающих.

С самого начала сообщаю, что для SVN есть подробное руководство. Называется оно svn-book и доступно на сайте и идет вместе с CollabNet Subversion-server. Так же про установку и настройку svnserv с Apache есть описание в учебнике по TortioseSVN (довольно хорошая подробная помощь на русском).

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

Если работа ведется в команде или требуется удаленный доступ к репозиторию (через Интернет, например), нужно устанавливать SVN-сервер. Он может работать самостоятельно, либо через веб-сервер Apache. В первом случае доступ к репозиториям будет по протоколу svn://, во втором — http(s)://. Доступ через веб-сервер нужен при проблемах с файрволом, когда он пропускает только HTTP-трафик, а так же для работы некоторых утилит-примочек к SVN-серверу.

Установка сервера

Самую свежую версию svn-cервера всегда можно найти на сайте subversion.tigris.org. Чистый svn-сервер без Apache в комплекте, и без визуальных примочек доступен только для версии 1.4.6, в то время как текущая версия 1.5.0. Для версии 1.5.0 есть выбор между CollabNet Subversion-server-1.5.0 (~11 MB) и VisualSVN Server (~5 MB). Первый идет в комплекте с Apache, второй — с Apache и плагином для Windows Management Console. Так же для VisualSVN есть платная возможность интеграции с Visual Studio.

A. Установка и настройка сервера VisualSVN (svn-сервер + Apache + консоль управления) самая простая. Эту версию нельзя установить без Apache.

1) Скачиваем файл VisualSVN-Server-1.5.1.msi или новее. Запускаем установку.
2) В мастере установки указываем, использовать ли для доступа HTTPS, либо просто HTTP. Указываем порт для прослушивания по выбранному протоколу и способ аутентификации. Так же указываем каталог, в котором будут храниться репозитории.
3) После установки открываем Management Console (через Пуск, например) и создаем пользователей и репозитории.

Теперь ваши репозитории доступны через выбранный протокол (HTTP или HTTPS) по указанному при установке хосту:порту (например, https://localhost:8443/svn/). Их можно просматривать как из браузера (через xsl), так и из SVN-клиета.

Работа с сервером VisualSVN безусловно самая простая.

B. Установка CollabNet Subversion Server (svn-сервер + Apache опционально).

1) Скачиваем файл CollabNetSubversion-server-1.5.0-23.win32.exe или версию новее. Запускаем его на установку.
2) Шаг Choose Components. Устанавливаем флажок SVNSERVE в любом случае. Если требуется установить так же Apache для SVN, устанавливаем флажок напротив него.
3) На шаге sunserve Configuration устанавливаем порт для sunserve (по умолчанию 3690, менять его смысла нет, если он не занят) и путь к репозиториям (каталог, где вы будете создавать отдельные репозитории в виде подкаталогов).
4) Затем настраивается Apache: хост/порт, путь к репозиториям (тот же, что и для svnserve) и префикс для URL (http://host:port/prefix). Префикс нужен на случай, если Apache будет использоваться не только для обслуживания SVN.

После установки появятся две новых службы Windows: Subversion Server (наш svnserv.exe) и Apache2.2 (если он был включен при установке). Чтобы все заработало их нужно запустить.

С. Установка svnserve 1.4.6 (чистый svn-сервер).

1) Скачиваем файл svn-1.4.6-setup.exe. Запускаем его на установку. При установке ничего кроме целевого каталога указывать не надо. После установки этот каталог надо добавить в переменную среды PATH (не помню, возможно это делается автоматически).
2) Создаем репозитории командой: svnadmin create c:\repositories\example-repository
3) Создаем сервис. Команда в консоли: sc create svn_svr binpath= «c:\Program Files\Subversion\bin\svnserve.exe —service -r C:\repositories» displayname= «Subversion Svr»
Здесь -r C:\repositories — адрес каталога с репозиториями, т.е. от него потом будут вычисляться пути. Например, если есть 2 репозитория: C:\repositories\proj1 и C:\repositories\proj2, то указав параметром -r C:repositories потом пути к репозиториям будут: svn://localhost:3690/proj1 и svn://localhost:3690/proj2 соответственно. Порт 3690 устанавливается по умолчанию, но его можно поменять (подробности в svn book).
4) Запускается сервис автоматически при старте Windows или из списка служб.

Именно эту работу (если не считать установку Apache) сделал за вас установщик CollabNet Subversion Server. В случае установки svnserve 1.4.6 доступ к репозиторию будет только по протоколу svn://.

D. Создание репозитория. Выделяю этот пункт отдельным разделом. Если в VisualSVN создание репозитория производится кликом мыши, то для svnserve (в том числе в версии от CollabNet) репозиторий создается из консоли. В поставке snv-сервера есть файл snv-install-folder\bin\svnadmin.exe. Если путь к snv-install-folder\bin еще не прописан в PATH, сделайте это.

Чтобы создать репозиторий, откройте консоль (cmd) и перейдите в каталог для хранения репозиториев, который вы указывали при установке (CollabNet) или создании сервиса (svnserve 1.4.6). Создайте новый пустой подкаталог (например, example-repository). В консоли выполните команду: svnadmin create example-repository. В только что созданном каталоге появится структура файлов svn. В них есть много полезных «штук», о которых можно почитать в svn-book и учебнике.

В подкаталоге conf можно настроить основные параметры репозитория. Прежде всего требуется закрыть доступ в репозиторий кому-попало. В файле svnserve.conf раскомментируем строки
# anon-access = read
# auth-access = write
Не забудьте убрать так же пробел после #, т.к. иначе будет ошибка чтения конфига. anon-access определяет доступ анонимным пользователям, auth-access — зарегистрированным. Они могут принимать значения «write», «read» и «none». Обычно anon-access = none и auth-access = write.

Далее надо раскомментировать # password-db = passwd, а в файл passwd в этом же каталоге добавить строку user = password.

Для начала такое определение доступа годится, но в последствии конечно пароли надо шифровать (читаем svn-book).

На этом установка сервера закончена и можно установить клиент.

Установка клиента.

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

Самым популярным и признанным клиентом SVN под Windows является TortoiseSVN. После его установки вы не получите отдельной программы, которую можно «классически запустить», клиент встраивается в проводник Windows, а команды для него доступны из контекстного меню файла (в т.ч. и в Total Commander).

Описывать установку клиента нет никакого смысла, там все элементарно просто.

О том, как работать с TortoiseSVN, подробно расписано в руководстве TortoiseSVN Клиент Subversion для Windows.

Дублировать это подробное руководство, конечно, желания нет, но все же super-fast-start work with tsvn опишу.

1) Для просмотра любого репозитория после установки TortoiseSVN вызовите контекствное меню на любом файле в системе, выберите меню TortoiseSVN→Repo-browser.  В открывшемся окошке введите адрес репозитория с протоколом (например, https://localhost:8443/svn/test или svn://someserver:3690/proj1/trunc). Откроется окно просмотра репозитория (с помощью кнопки напротив строки адреса можно выбрать, какую ревизию просмотреть; HEAD — это последняя ревизия).

2) Для создания локального репозитория (не используя сервер) запускается пункт меню TortoiseSVN→Create repository here… на нужном каталоге. В Repo-browser такой репозиторий доступен по протоколу file:///.

3) Для скачки себе версии из существующего репозитория запускается пункт меню TortoiseSVN→SVN Checkout на каталоге, в который сольется версия.

4) Если вы еще не использовали SVN и хотите залить на сервер свою текущую версию исходников, запустите пункт меню TortoiseSVN→Import… на каталоге, в котором лежит версия (при этом не забудьте, что разрабатываемую ветку надо лить в trunk).

5) TortoiseSVN→Export… используется для получения чистой версии исходников из репозитория (без служебных файлов контроля версий).

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

На последок рекомендую почитать интересную серию статей Работа с Tortoise SVN.

Теперь рассмотрим преимущества реестра в применении к веб-сайту.

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

Во-вторых, сайту, как и обычному приложению для ОС, требуется где-то хранить ряд своих настроек. Одни из них в процессе жизни сайта не меняются (такие настройки часто устанавливают прямо в коде в виде констант), другие можно менять (в CMS обычно есть страничка «настройки»; примерами таких настроек может служить информационное сообщение на всех страницах сайта или количество записей на одной странице в списках). Третье настройки зависят от текущего пользователя (обычно это какие-либо привилегии, часть которых часто реализуется в системе прав доступа, и персональные установки пользователя).

Настройки всегда касаются либо всего приложения в целом (например, путь к www_root), либо отдельных его компонентов (например, количество новостей в блоке на главной странице).

Когда разложена по полочкам классификация настроек, можно прикинуть предположительную структуру реестра настроек сайта:

• ветвь глобальных настроек приложения, которые касаются всех пользователей;
• ветвь локальных настроек модулей, которые касаются всех пользователей;
• ветвь настроек текущего пользователя (подставляется в зависимости от залогиненного пользователя);
• ветвь настроек пользователя по умолчанию (all users).

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

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

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

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

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

Итак, сразу к практике. Как по вашему мнению в $_GET будет отображена строка такого вида: «?aa[bb][cc=11»? Вариантов в принципе не так мало, среди них и логичные, и не очень. В результате в PHP получим такие ключи массива: $_GET[‘aa’][‘bb’]=11. Куда делось «cc»? Что даст «?aa[bb]cc=11»? Тоже самое ($_GET[‘aa’][‘bb’]=11). Куда опять делось «cc» не понятно. Но самое интересное впереди!

Что даст «?aa[bbb=11»? Конечно $_GET[‘aa_bbb’]=11, как же можно было не угадать, это же интуитивно-понятное продолжение примеров выше :)
«?aa[bb[ccc]]=11» дает $_GET[‘aa’][‘bb[ccc’]=11. Вторую скобку опять украли!

Ну и пик программы: «?[aa]=7». var_dump($_GET) выдаст: Array() — пустой массив. «А-а-а, где же мой гет?..» Наверное, логичне было бы как минимум создать ключ $_GET[»]. Врочем, во всех этих спорных случаях вариантов много и спорить об их правильности можно долго.

Вот такие метаморфозы. Частично такое поведение объясняет то, что в первых версиях языка параметры парсились не в массив, а в переменные. Тогда запретные символы было принято заменять подчеркиванием. В одном из примеров выше наблюдается такая замена. Она действует, когда данный параметр не считается массивом. А вот если параметр распознан как массив, включается новая хитрая логика, которая в одних случаях просто откидывает лишнее, в других откидывает только часть неугодного, а часть целиком пихает в ключ. Не интуитивно, не логично.

О самой библиотеке подробно описано в записи, посвященной ее появлению на свет.

Вот пример изображения, подготовленного библиотекой:

Страница класса — https://valera.ws/proficaptcha/. Там его можно скачать и посмотреть on-line demo.

Таким образом, пришлось остановиться на базе CNGeoIP. Была куплена версия базы и на ней был построен алгоритм получения кода города для информера по IP посетителя. Написанный скрипт работает тут: http://ru.commontools.net/geoip/ya.w.js. Определяется город по IP пользователя, проводится сравнение с базой Яндекса и выводится id города и страны для информера в виде: var yaCountry=20;var yaCity=26850; Скрипт естественно работает на стороне сервера и выводит только id для JS. А на странице с информером скрипт включается в HTML-код страницы через <script src=»…»>. Далее другой незамысловатый скриптик подставляет переменные в код вызова информера и на картинке отображается погода в городе, в котором находится посетитель сайта. Под ней ссылка на настройки информера, где посетитель сможет выбрать другой город, а информация сохранится в cookies.

Итак, результат трудов доступен в виде оттестированной stable-версии. Страничка получения кода находится здесь: http://ru.commontools.net/geoip/ya.weather.get.html. Это страница для получения кода информера. На ней описано, как код получить и прикрутить к сайту.

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

Посмотреть, как информер работает, можно уже сейчас в моем блоге.

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

UPD. Стадия бета-тестирования завершена. Уже более 7 месяцев информер успешно работает на множестве сайтов, по этому заявляю о стабильности версии. Обновлений пока не планируется, потому что обновлять-то нечего. Если Яндекс поменяет свой алгоритм, тогда-то и будем обновлять.

Постоянно обновляется база IP. На декабрь 2008 работает ноябрьская версия.
UPD2. Сервис обновлен.

А вот таблица по количеству поисковых запросан на Яндексе за месяц:

Выводы (кратко). Не забывайте, что статистика рабочих мест касается только Беларуси, а поиска — только рунета.

1. PHP все еще актуален и в лидерах. В то же врмемя, раз много ищут в яндексе, значит много новичков и чайников им интерисуются.
2. C# жжот.
3. HTML ищут много. Профессионалам по HTML искать почти нечего, вывод — студенты, новички все еще атакуют :)
4. Java-программеры давно поняли, что помощь надо просить у гугла. Тех, кто еще не понял, осталось мало :)
5. JavaScript солидно отстает по популярности от того же PHP.

Теперь выводы из поиска вакансий/резюме.

1. Ищут в основном Java-девелоперов. Причем, как спрос, так и предложение (относительно других языков) велики. Специалисты могут выбирать, имеют возможность менять работу в поиске лучших условий и з/п.
2. С#: спрос в 3 раза превышает предложение. Ищут много, большенство уже нашли себе теплые места и сидят там :) Ждем лета-осени, когда работу начнут искать выпущенные студенты… (тут сказали, что нихера не ждем, потому что распределение и все дела. Ну и ладно, значит не ждем :)
3. Delphi: мест мало, резюме много. Дельфи знают многие, это популярный язык у чайников. Но серьезные конторы не работают с этой средой.
4. C++: все хорошо, все на своих местах…
5. PHP-программистов не хватает. Всех хороших разобрали, плохие никому не нужны. Однако, и спрос, и предложение, меньше традиционных системных языков. Сайт-бум прошел.
6. Python и Ruby: есть мизерный спрос, предложение нулевое. Эти языки у нас не популярны. Больше как хобби расматриваются.
7. SQL жив. Правда программировать на нем довольно грустно и сложно (имеется в виду программирование бизнес-логики в хранимых процедурах), потому предложение в 3 раза меньше спроса. Но при этом, в большенстве вакансий ищут не SQL-разработчика, а c++, php, c#, а SQL только прилагается. Это объясняет второе место после Java. А вообще, банки атакуют :)
8. JavaScript и HTML получили 3-е и 4-е места только потому, что они вечно к чему то прилагаются. В основном к PHP и C#.

Короче говоря, лучше всех живется джаверам: огромный спрос, относительно спроса малое предложение :)