Конфиги для bash

Практически у каждого гуманоида, обреченного возиться с консолью, есть набор конфигурационных файлов, который собирается годами и содержит мудрость предков и пыль веков. И каждый неофит, постигший необходимость настройки bash под свои нужды, прежде всего стучится в гугл и тратит достаточно большое количество времени на чтение чужих конфигов.
Огромное число их можно откопать на GitHub. Есть даже специальный сайт, где сложено 1474 (на данный момент) конфиг-файла (там правда все в кучу .vimrc, .bashrc, .zshrc и т.д.).
Но в хранении конфигов есть один тонкий момент, с которым приходится сталкиваться любому, кто растит их некоторое время. Во-первых, они становятся довольно объемными и, следовательно, трудно поддерживаемыми, а во-вторых, часты бывают нужны разные настройки для разных машин.
Если обратиться к интернетам в поисках мудрости, то довольно часто рекомендуют простейший расклад, когда создается три файла:

aliases - разные удобные сокращения (alias lsa='ls -lha')
config  - настройки самого bash (export HISTSIZE=10000)
env     - настройки среды окружения (export LANG=en_EN.UTF-8)

Плюс еще пара файлов, которые это все загружают: bashrc и bash_profile
Данное решение нацелено на структуризацию и просто предлагает не сваливать все в кучу, а как-то разнести по темам. В принципе, это лучше, чем один .bashrc на 1500 строк.
Но проблема того, что на linux-сервере нам совершенно невозможно иметь TextMate, который стоит редактором по-умолчанию на mac-машине остается в силе, не говоря уже о различных PATH-переменных окружения, которые могут внести некоторую путаницу.
При этом я предполагаю, что мы храним все где-то в системе контроля версий на удаленном сервере (я храню на GitHub) и используем на каждой машине, где нам выдают шелл. Можно поколдовать с .gitignore и не пушить в репозиторий host-specific файлы, но не хочется их разом потерять вместе с внезапно сгоревшим хардом. Поэтому я решил немного допилить напильником изначальный расклад и вот, что получилось:

aliases         - общие aliases
config          - общий config 
hostname        - директория для host-specific файлов
    server-1    - очень боевой сервер
    dev-1       - сильно разработческая машина
platform        - директория для platform-specific файлов
    darwin      - все, что относится к миру mac
    linux       - все, что относится к миру суровых linux
scripts         - директория со вспомогательными скриптами
bashrc          - файл, который подгружает весь этот зоопарк

В самом bashrc есть только загрузка нужных файлов, выглядит это так:

droot=~/.dotfiles/bash

# Load common files
. ${droot}/config
. ${droot}/aliases

# Load platform-specific shortcuts
platform=`uname | awk '{print tolower($0)}'`
if [ -f ${droot}/platform/${platform} ]; then
    . ${droot}/platform/${platform}
fi

# Load machine-specific files, if presented
hostname=`hostname -s`
if [ -f ${droot}/hostname/${hostname} ]; then
    . ${droot}/hostname/${hostname}
fi

Теперь можно продолжать наращивать парк серверов и не бояться, что конфиги для bash распухнут до полной неюзабельности. А я, тем временем, все еще посматриваю в сторону zsh и все надеюсь как-нибудь перебраться на него в качестве каждодневного шелла.

Изучаем Computer Science в MIT, Berkley, Stanford, etc.

Образование 2.0

Как-то так сложилось, что программирование я изучал по книжкам и интернетам. Мне кажется, что это довольно распространенная практика, учитывая культ высшего образования в нашей стране и слабые представления абитуриентов о том, чем они хотят заниматься в дальнейшем. Есть, конечно, люди, которые выбирают себе увлечение в 10 лет и спокойно развиваются в выбранном направлении, но таких меньшинство.
Программинг — штука очень многогранная с большим количеством уровней абстракции и возможностями для саморазвития. Т.е. учиться программированию можно спокойно всю жизнь и все равно узнавать что-то новое. В какой-то момент на собеседовании выпускник Гарварда попросил меня решить одну задачку, а после того, как я не смог предоставить ему решение, объяснил, что надо было использовать модифицированный алгоритм Дейкстры. Тогда я понял, что в моем книжно-интернетном образовании есть провалы =).
Книги по околокомпьютерам я читаю постоянно, но ни одна из них не претендует на фундаментальность. Именно эта фундаментальность закладывается в университетских курсах, о которых я сегодня кратко расскажу.
Все началось с того, что где-то я наткнулся на сайт Academic Earth, на котором собраны записи с лекций в ведущих американских ВУЗах. Погуглив эту тему вглубь, я понял, что в америках давно существует практика выкладывания этих самых лекций и прочего сопроводительного материала в глобальную сеть, надо просто знать, где искать. Потом я вспомнил, что в iTunes есть раздел iTunesU, где оказались все те же лекции, только их там намного удобнее смотреть. Поэтому я здесь выложу подборку того, что мне показалось интересным со ссылками на оба источника, а вы сами решайте что по вам лучше. Сразу скажу, что все это курсы базового уровня, которые призваны устранить именно пробелы и дать немного пищи для размышлений. К сожалению, продвинутые курсы никто не расшаривает, чтобы люди не переставали платить деньги =)

MIT

Introduction to Computer Science and Programming
Раньше в качестве введения в программирование там читали легендарный Structure and Interpretation of Computer Programs и Scheme давали в качестве первого языка. Сейчас используют Python, и читают курс пара мужиков, один очень веселый и интересные, а второй суровый и я от него засыпаю.
Страничка с материалами к курсу
AcademicEarth
iTunesU

Introduction to Algorithms
Тем, кто уже прочел Осла или Кнута этот курс не даст ничего нового, но остальным может пригодиться как популярное введение в классические алгоритмы
AcademicEarth
iTunesU

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

Stanford

CS106a Programming Methodology
Курс для тех, кто в глаза не видел программирования, но уже знает как включать компьютер. Примечательно, что курс идет на Java и, в принципе, в конце там довольно приличные приложения пишутся. Ведет очень веселый индус, которого позитивно смотреть за завтраком.
AcademicEarth
iTunesU

CS106b Programming Abstractions
Это уже посерьезнее, там C++ и довольно нескучная тетка. Является логическим продолжением предыдущего курса.
AcademicEarth
iTunesU

CS107 Programming Paradigms
Последний из CS курсов, доступных от Stanford, самый продвинутый. Но даже в нем не обсуждают еще Design Patterns.
AcademicEarth
iTunesU

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

Berkley

До этих курсов я пока не добрался, но в списке они у меня есть, поэтому кратко:
The Structure and Interpretation of Computer Programs
Это курс по той самой легендарной книжке, от которой отказались в MIT. Хотя я бы рекомендовал смотреть оригинальные записи с их лекций, благо они доступны на их сайте.
AcademicEarth
iTunesU

Operating Systems and System Programming
Курс по системному программированию, для общего развития
AcademicEarth
iTunesU

Data Structures
Курс по классическим структурам данных.
AcademicEarth
iTunesU

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

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

Немного про ExtJS

Надо сказать, что я не использовал ExtJS около полутора лет. За это время сменился мажорный номер версии (на 3) и у библиотеки добавилось приятных возможностей, которые упрощают жизнь. Самым значительным изменением для меня стала доступность Ext.data.Writer, который сильно облегчает задачу сохранения данных. Вообще заметно, что библиотека становится все более зрелой и фишко-насыщенной. Но, одновременно со всем этим, у нее остались теже проблемы, которые меня всегда в ней немного раздражали. При всей ее зрелости, любой шаг вправо-влево от того, что предлагает библиотека все так же карается расстрелом, багами и жестокими оверрайтами, которые потом вылезают боком. Я, конечно, соглашусь с теми, кто скажет, что я просто не умею ее готовить и с любой библиотекой так получается. Но весь прикол как раз в том, что для того, чтобы эффективно писать на ExtJS, надо с ней жить =) Т.е. тратить значительное строить и строить на ней приложения, запоминать хлипкие куски и знакомые паттерны багов и так далее. А что-то не хочется. А теперь немного речей от моего внутреннего героя Стэна, который в очередной раз многое понял.

Про архитектуру приложений на ExtJS написано уже достаточно много (раз, два на вскидку), я ничего добавлять не буду. Для собирающих модулей я предпочитаю, так называемый Revealing Module Pattern, который является продолжением идей Yahoo про Module Pattern, но по структуре мне нравится больше. А так все тоже, создаем свои компоненты, наследуя из от экстовских и оживляем их =)

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

Довольно часто сталкиваешься с тем, что обновив ExtJS что-то перестает работать. В первую очередь, надо следить за тем, что вы обновили плагины, которые входят в поставку ExtJS (например RowEditor). Затем надо проследить, что все внешние плагины обновлены. Если ничего не помогло, то стоит отправится на форум. Часто там уже вовсю обсуждают, как починить вашу проблему =), потому что она не только ваша. Ну и потом уже можно вооружаться FireBug и писать на форум.

Вот список самых интересных плагинов, с которыми я работал в этот раз:
Ext.ux.form.DateTime — позволяет выбирать дату и время, а не просто дату.
Ext.ux.form.GroupingCombobox — позволяет использовать группировку значений, как обычный <optgroup>.
Ext.ux.form.XCheckbox — в отличие от обычного чекбокса, всегда отправляет значение, вне зависимости от того, отмечен он или нет.
Ext.ux.grid.CheckColumn — позволяет делать колонку из чекбоксов
Ext.ux.grid.ItemDeleter — добавляет колонку по нажатию на ячейки которой можно удалять строки
Ext.ux.grid.RowEditor — из официальной поставки, удобно редактировать строки в гриде
Ext.ux.gird.Search — старый-старый плагин, который позволяет осуществлять поиск по разным колонкам грида
Ext.ux.PanelCollapsedTitle — плагин, который добавляет заголовки на свернутые панели BorderLayout (причем и для IE, и для остальных вменяемых браузеров)
Ext.ux.grid.Filter — семейство фильтров, который вешаются в меню колонки и позволяют не загромождать тулбар всякими поисковыми формами

TextMate. Причины использования

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

Сразу оговорюсь, что я рассуждаю о выборе редактора для удобной работы с обычными веб-языками (php, ruby, python). Когда живешь под линуксом и не используешь всю мощь Vim или Emacs, не подружился с jEdit (который по слухам очень хорош для разработки на surprise-surprise! Java), то остается только Eclipse. Причем кто-то может по ленности сразу взять Aptana, которая по заверениям ее самой прекрасна для php, python и ruby. На мой взгляд, при всех достоинствах этого редактора, построенного на Eclipse, у него плохая совместимость с плагинами для самого эклипса. Поэтому если уж использовать эклипс, то в чистом виде, доставляя куски аптаны(тот же PyDev и RadRails). Для эклипса существует огромное число интересных плагинов, но это уже тема другой статьи =).

На маке эклипс выглядит немного чужеродно и ведет себя не очень хорошо. Not a good citizen. Это все проистекает из самой идеи Java, которая везде одинаковая, а следовательно сама по себе. Ну и какой-то неповоротливый он, но это его фишка уже. Зато на маке полно других смешных редакторов. Я, признаться, был лояльно настроен по отношению к TextMate, поэтому сразу стал осваивать его, но краем глаза видел красиви Espresso, который мне достался в комплекте с MacHeist, но это такой детский редактор. Для очень позитивных html-верстальщиков или типа того. Совсем не для программистов, хотя со своими интересными задумками.

Вообще при выборе любого «инструмента» надо думать о его возможностях и удобстве расширения и настройки. С этой точки зрения Vim и Emacs являются признанными лидерами. Вы редко услышите «мне уже не хватает Vim для ежедневной работы», потому что всегда можно сесть и на встроенном языке реализовать то, что вам необходимо. Их возможности действительно поражают, посмотрите какие-нибудь подкасты от джедаев этих редакторов, чтобы поразиться тому, что происходит с текстом под их умелыми пальцами. Проблема в них в том, что надо потратить реально много времени на освоение. Как писали на Stackoverflow, «я использую vi и vim уже 20 лет и все еще узнаю что-то новое».

В этом отношении TextMate намного проще. У него ненавязчивый интерфейс, который позволяет сразу начать редактировать тексты, и при этом неописуемое число возможностей. Мануала на его сайте хватит на первое время. Если хочется почитать книжку, то можно купить или найти TextMate: Power Editing for the Mac, в которой все довольно подробно описано. При этом надо понимать, что что-нибудь читать придется в любом случае, иначе вы рискуете просто не использовать этот редактор даже на 10%. На этом вводная часть заканчивается. В следующей мы поговорим про самые интересные бандлы, а дальше — посмотрим.

И да, кстати, этот текст подготовлен и опубликован прямо из TextMate =)

Софт как религия.

Программное обеспечение довольно часто становится объектом религиозных споров. Чаще всего адептов того или иного софта можно встретить в никсовой среде и в маковской. Среди наиболее часто встречающихся споров в никсах можно вспомнить «KDE против Gnome», «Vi против Emacs», «Midnight Commander против всех». Адепты каждой стороны выдвигают «неопровержимые» доказательства свой правоты и кидаются какашками в своих противников. Это все происходит из-за прекрасной штуки, которая называется «отождествление». Т.е. человек какбэ говорит тебе «я есмъ Emacs» и ты понимаешь, что возразить ему нечего. Брендов, которые вызывают у людей подобные эмоции не очень много, зато создать такой бренд мечта любого маркетолога.

В принцип, в этом нет ничего плохого, но не надо забывать, что программное обеспечение – это всего лишь инструмент, как и сам компьютер, как и языки программирования, которые тоже очень часто являются поводом для священных войн. Хороши те инструменты, которые ты освоил, которыми ты умеешь пользоваться. Если перед тобой открыто семь редакторов исходных кодов, про которые ты ничего не знаешь, то тебе понравится тот, которые будет ближе к тому, что ты использовал до этого. Каждый инструмент требует времени, у каждого своя кривая обучения. Именно поэтому люди мира Vi и Emacs с презрением смотрят на других, потому что они знают, что их редакторы имеют вертикальные кривые обучения. Я в свое время с исступлением неделю посвятил изучению vi. Просто потому что этот редактор есть почти везде и в какой-то момент мне надоело просто «бибикать и портить текст».

Так же происходит и с языками программирования. Если у тебя есть некоторые нейронные цепочки, которые называются «программерским складом ума», то тебе, в принципе, пофигу на чем писать. Проблема в том, что без глубокого освоения, ты будешь писать одинаково плохо на всех языках. Не изучая их особенностей, ты везде будешь исопльзовать те конструкции, к которым привык. Так что не важно какой язык исспользовать или в каком текстовом редакторе писать (в разумных пределах, конечно, я не призываю использовать BASIC и Notepad), главное постараться изучить то, что он умеет. Потому что его часто писал не один человек и идей в нем может быть заложено на несколько жизней.

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

Установка Xdebug поверх MAMP на Mac OS X

Как-то я некоторое время обходился без дебагера, видимо, мало работал =) Но время пришло и пришлось искать в сети руководства по установке, потому что я был (и остаюсь) ленив и использую MAMP забыв радости ./confugure&&make&&make install.
Все оказалось до банального просто. Существует такая IDE Komodo, которая есть на всех платформах и на всех платформах предоставляет возможность использования Xdebug. А для этого у них есть прекомпиленные версии Xdebug для всех ОС и они их безвозмездно раздают. Вот такие чудесные люди, спасибо им. Идем и забираем. Они заботливо компилят дле всех активных веток PHP, так что каждый найдет то, что ему нужно.
Дальше все слишком просто, местами скучно =)
Копируем xdebug.so в MAMPовскую директорию с extensions (/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/)
Добавляем в php.ini (/MAMP/conf/php5/php.ini) строчки

[xdebug]
zend_extension=\
/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so

И все остальное, что вы хотите попросить его делать, например немного попрофайлить код. Вот здесь я словил просветление. Я всегда использовал KCacheGrind и считал, что он единственные и неповторимый. К счастью, я ошибался, клиент для мака есть и он даже иногда развивается. Он, конечно, не такой клеви, как K, но зато нативен и не принуждает к сексу с портами. KISS.

DateJS и Jeditable.

Некоторое время назад, задавшись вопросом, как самым удобным образом предоставить оператору вводить дату, я наткнулся на Datejs, которая парсит «человеческие» даты и делает из них «машинные». Т.е. вы ей пишите «today», «after 3 days» или «next friday», а она транслирует это в какое-нибудь «2009-03-13» соответственно. Очень удобно. При этом она понимает так же «17 2 2007», т.е. подходит не только для дат, которые поблизости. Это было то, что нужно.
А недавно, мне захотелось сделать «in-place edit», т.е. чтобы поле выглядело как текст, а при клике на него превращалось в input, checkbox или select. Мне больше всего понравился plug-in к jQuery под названием Jeditable. Все в нем было так, как нужно и даже был API для написания «custom inputs». Поэтому я незамедлительно скрестил Jeditable и Datejs, что здесь и выложу. Может кому-то пригодится, а может кто-то мне подскажет, как обработать «cancel on blur» =)
js-code

$.editable.addInputType('datejs', {
    element : function(settings, original) {
        rand = new Date().getTime();
        var input_date = $('');
        var guess_date = $('');
        var real_date = $('');
        $(this).append(input_date);
        $(this).append(real_date);
        $(this).append(guess_date);
        
        var messages = ["o_O"];
        var date = null;
        var input_empty = "Вводим дату сюда";
        var empty_string = "Пока угадывать нечего";
        if (input_date.val() == "") {
            input_date.val(input_empty);
            guess_date.val(empty_string);
        }
        input_date.keyup( 
            function (e) {
                if (input_date.val().length > 0) {
                    date = Date.parse(input_date.val());
                    if (date !== null) {
                        guess_date.val(date.toString("
                        ddd, dd MMMM, yyyy
                        "));
                        real_date.val(date.toString("yyyy-MM-dd"));
                    } else {
                        guess_date.val("o_O");
                    }
                } else {
                    guess_date.val(empty_string);
                }
            }
        );
        input_date.focus( 
            function (e) {
                if (input_date.val() === input_empty) {
                    input_date.val("");
                }
            }
        );
        input_date.blur( 
            function (e) {
                if (input_date.val() === "") {
                    input_date.val(input_empty);
                }
            }
        );

        return(real_date);
    },
    submit: function(settings, original) {
        var value = $('#rd_').val();
        $("#rd_" + rand, this).val(value);
    },
    content: function(string, settings, original) {
        $("#id_" + rand, this).val(string);
        $("#rd_" + rand, this).val(string);
        $("#id_" + rand, this).keyup();
    }
});

ПКМГ. Немного про ssh.

Напишу-ка я еще один пост про путьКМировомуГосподству. В прошлый раз мы обсуждали однокнопочный накат на продуктивный сервер, сегодня подговорим про ssh и туннели (не в ушах).

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

1. ssh-keygen -t dsa
2. scp id_dsa.pub ux@ux.ssh.host.ru:/home/ux/.ssh/my.key.pub
3. ssh ux@ux.ssh.host.ru -p 22 'cat ~/.ssh/my.key.pub >> ~/.ssh/authorized_keys2'
4. echo -e "Host host\nHostName ux.ssh.host.ru\nUser ux\nPort 22" ~/.ssh/config

Здесь мы создаем ключ на локальной машине, по scp заливаем его на удаленную и добавляем содержания нашего ключа в файл authorized_keys2, чтобы удаленный хост нас опознал. Затем настраиваем конфиг на локальной машине, чтобы не писать каждый раз user@host -p 22 для коннекта, а просто написать ssh host. Немного перлоОбразно, но зато можно просто копировать в терминал и запускать =)

Еще для встроенного напоминателя. Довольно часто хостер предоставляет доступ к БД только через ssh-туннель. Оно и понятно и приветствуется, только вот мануал по консольному доступу выкладывают только для виндузоидов, видимо считая, что никсоиды сами разбирутся =) То, что под виндой делается с помощью puTTy или ей подобных программ, в nix достигается парой комманд:

1. ssh -fNg -L 8600:ux.mysql.host.ru:3306 host
2. mysql -h127.0.0.1 -P8600 -u ux -p

В данном случае мы создаем туннель с нашей машины (с порта 8600) до удаленной (ux.mysql.host.ru, где mysql крутится на порту 3306, а «host» — это тот самый alias, который мы создали в конфиге ssh), а затем просто коннектимся какбэ к себе на локальную машину, а попадаем на удаленную (не забываем только правильного пользователя и пароль поставить, а то не пустит). Магия чистой воды. Вот за это мы и любим консоль ^_^

Zend Certified Engineer — HowTo

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

Для чего это нужно, каждый решает сам для себя, но хочу отметить активность, которая наблюдается в последнее время в русском сегменте PHP Yellow Pages. За сентябрь-октябрь-ноябрь количество сдавших экзамен увеличилось до 36. Я был 31, а думал быть 23 =) Выводы делайте сами, но мне кажется, что народ вкладывает деньги в себя, чтобы попроще пережить кризис. И надо сказать, штука это полезная, учитывая то количество хороших резюме, которые я наблюдаю на рынке.

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

Подготовка

Если вы ответили себе на вопрос «зачем», самое время ответить теперь на вопрос «как». Для начала стоит отправиться на сайт Zend и приобрести там ваучер на сдачу экзамена. Это сэкономит вам немного денег, т.к. сертификационные центры продают экзамен чуть дороже. Ваучер обойдется вам в $125 и действует он год с момента покупки.

Теперь у вас есть год, чтобы как следует подготовиться к экзамену 😉 Если вы «зубр» и сами всех засертифицируете до смерти, то читайте только про сам процесс сдачи, а мы пока поговорим про подготовку. Для начала стоит обзавестись почти официальным учебником, любители «вареза» отправляются в гугл, но надо сказать, что в продаже сейчас 2-ое дополненное, улучшенное издание, которое на торрентах еще не засветилось =) Зато с торрентов можно слить предыдущий Study Guide, посвященный PHP4. Надо сказать, что он намного полнее освещает многие моменты и рекомендуется к прочтению пару раз.

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

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

После того, как вы перед сном можете быстро проговорить все функции работы со строками, а утром легко вспоминаете десяток параметров из php.ini, можно начинать готовится к самому тестированию =) Здесь есть 2 пути. Можно откопать из неисчерпаемых торрентов The Zend PHP Certification Practice Test Book,который по PHP4, но есть способ лучше. Лучше всего приобрести набор «тестовых тестов», которые проходят в том же режиме, что и настоящий экзамен. 70 вопросов на 90 минут. Но, в отличие от экзамена, где выдают «passed/failed», здесь результат разбит на 12 предметных тем, за каждую из которых показана отметка по 3х-бальной шкале. Сами зендовцы говорят, что они тщательно скрывают систему оценки, чтобы никто не зубрил какую-нибудь одну тему, желая выехать только на ней. А так приходится учить все =)

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

Сдаем экзамен

Для того, чтобы сдавать экзамен, надо отправляться на сайт VUE, подбирать себе тестовый центр и звонить им. Потому что, например в Инвенте, где я сдавал этот экзамен сдают в Пн и Чт. После предварительной договоренности, шедулим экзамен на сайте и начинаем грызть ногти =) Есть, кстати, один нюанс. Экзамен можно отменить за один «бизнес-день» до сдачи. Т.е. если сдаете в Пн, то отменять можно лишь в Пт. Так что если вы склонны к алко-туризму, то стоит назначать на какой-нибудь другой день 😉

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

Интерфейс экзамена заметно более убогий (аскетичный), чем в тестовых тестах, зато можно мышкой вообще не пользоваться =) Времени дается с избытком, если хорошо готовится, я уложился в 75 минут со всеми проверками-перепроверками, и когда понял, что начинаю феерично меня ответы на рандомные, нажал кнопку «финиш». Дальше было 3 секунды, за которые я вспомнил весь пых сразу и одновременно и, заметив слово «конгратьюлэйшнс», понял, что эксперимент удался. Дальше нам дают распечатку о том, что мы молодцы и можно идти в кафе праздновать.

Плюшке?

Диплом обещают прислать как-нибудь, я пока не дождался, хотя прошел месяц (дефолтСити, если кто не понял еще). Зато можно бомбардировать certification@zend.com с требованиями разместить вас в PHP YellowPages, можно вступить в группу в линкедИне (просто так =), можно повесить у себя везде красивую картинку и отправиться дописывать профили в разных соцСетях =) Каждому свое.

Если есть вопросы — пишите в комменты, отвечу.

ПКМГ. rsync по ssh для обновления сайта.

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

CIS — continuous integration server

Начинать придется с этой малопонятной штуки. Насколько я понял из русской и английской (лучше) Wiki эту штуку придумали незабвенные Фаулер с Беком. Где-то на рубеже веков. Придумали для всеяЫнтерпрайзЖавы, но идея ожила и распространилась дальше. Даже книга на русском есть.

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

Но для начала я вытащил из всей этой идеи Phing. Те, кто работал с всеяЫнтерпрайзЖабой, знают, что есть такая штука, как Ant. Это такой трудолюбивый муравей, которого создали люди, считающие, что xml намного понятнее, чем файлы make. В двух словах, он нужен для того, чтобы билдить из исходного кода то, что можно потом задеплоить. Вы ещё здесь? =)

Так вот меня этот Phing здорово зацепил, ибо я всегда любил всё автоматизировать. Ведь однажды обученный компьютер ошибается гораздо реже, чем человек. Надо просто объяснить ему что делать =) В принципе, у нас в пыхоРазработке не сильно много проблем, не то что в ынтырпрайзЖабе. Но тоже хватает. И среды dev/prd отличаются, и изменения в DB надо учитывать, короче, есть где развернуться автоматизатору. Можно держать все изменения в голове и обновлять только нужные файлики, а базы обновлять одновременно. Можно вообще на prd разрабатывать =) Но не зря же мы svn используем и вообще пытаемся отмыться от приставки «быдло» в слове кодинг =)

Временным решением пробдем с конфигами и прочими паролями к БД может быть привязка к рабочей директории. Об этом хорошо писал Кузьма Феськов в последнем PHPInside. Где-то год назад. Костыль, но всё ж лучше, чем каждый раз вспоминать, что не надо заливать разработческий конфиг на продуктивный сервер =)

Далеко меня уже занесло, постараемся вернуться назад. Итак. План теперь таков:

1. Пишем код, тестируем, отлаживаем. Добиваемся работоспособности.
2. Коммитим в svn
3. В post-commit hook вызываем phing
4. Phing пакует наш проект в продуктивный вид, заменяя файлики конфигов, убирая ненужные всякие фишки svn и Eclipse.
5. Лезем (не сами, скриптом) на продуктив. Пакуем текущую версию сайта в архив. Сливаем себе.
6. Заливаем изменения с помощью rsync over ssh.

По-моему неплохой план =) первые 2 пункта уже вроде как отлажены. Осталось разрбраться с остальными. Так как сегодня вечер воскресенья, пришлось взять самый маленький и скучный шестой пункт =)

Rsync over ssh

Ну наконец-то. Процедура беспарольного соединения с удаленным сервером обсосана уже вдоль и поперек (да, именно так =) на просторах инета и рунета. Например, здесь.

А дальше чистая bash-магия, которая выглядит вот так (подсмотрено здесь, одна строка!):
rsync -zrptL --delete-after -e "ssh" /local/folder/ remote-server.ru:/remote/folder

За разъяснениями — в man или источник. Только будте аккуратны. Оно удаляет без права переписки. Именно поэтому я хочу для начала бэкап наладить, а потом уже это использовать это заклинание =) Кстати, обращайте внимание на слэшики в конце путей. Они важнее, чем вы думаете.

Именно за это я люблю *nix. Весь вечер ты читаешь маны, бродишь по сайтам, читаешь чуть ли не китайские форумы. Зато потом одной строкой ты захватываешь мир. Продложение следует.