gettext

Наконец-то я окончательно разобрался с модулем gettext. Все работает, хак против кеширования показал себя отлично, правда в винде нужно заклюшить (@) некоторые setlocale.

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

Hello world!

Позавчера после до-о-о-олгого перерыва (лет 10, если честно) взял в руки С++ и сделал  свой не первый "Hello world": небольшую тулзовину, которая позволяет получить unix timestamp.

Вот она:


P.S.: Кстати, очень удачная подсветка синтаксиса.
Как прикрутить такую же себе можно узнать тут: подсветка синтаксиса для blogger

DrupalCamp Kyiv 2010

В этом году снова будет проходить DrupalCamp. Увидимся на месте!

Вебинар "Людям о менеджерах"

Вчера прошел вебинар под названием "Людям о менеджерах", докладчик Денис Войханский, aka "dva".

Общее впечатление от вебинара достаточно неприятное. Если позволите, вкратце о багах:
Баг номер один (самый главный) - время. Вебинар планировался на один час. Перед началом Денис честно предупредил: в час не уложимся, тема большая и интересная, поэтому будет два. "Ок" - подумал я и раздвинул свой тайм-лайн на час. Потом так же честно предупредил, что можем не влезть и в два часа и разрешил уходить кому надоест. "Хм" - подумал я. Когда по окончанию второго часа мы дослушали вопрос 4 из 11 мне, к сожалению, пришлось вернуться к делам. Очень обидно прерывать какой-то интересный процесс на середине и именно это испортило мне все впечатление от вебинара.
Ирония ситуации заключается в том, что вебинар посвящен менеджменту и менеджерам. Конечно, менеджмент это не всегда управление временем, точнее не только это, но если исходить из слов мотивационной части о том, что "вам нужны менеджерские навыки, потому что вы менеджер самого себя", то докладчик явно недостаточно "менеджер себя" :-)
Очень жаль, что в вебинаре нашлось время на многократное повторение одинаковых примеров, экивоки, остроты в адрес гугла, коллег и уходящих из зала участников, на живое общение с залом и рассказ о похудении на 30кг и йоге, но не нашлось времени этот вебинар закончить.
Второй баг - визуальное сопровождение доклада. Для людей сидящих в зале был установлен флип-чарт (или доска, я не знаю) и проектор. Для вебинарщиков транслировался только проектор (может быть флип-чарт тоже, а я просто не осилил включить?) Так вот проектор, как правило, транслировал название текущего топика и комикс к нему. Не будем упоминать небольшую нестыковку с порядком слайдов, все бывает. Но ужасно было то, что на флип-чарте рисовались "барчики" и "дырки", и по ним было многое рассказано. А проектор в это время показывал "ктулху". В итоге о некоторых вещах приходилось догадываться. Почему нашлось время нарисовать комиксы, но не нашлось времени как-то нарисовать и подписать эти "барчики" и "дырки" в презентации - не понятно. Хотя, я немного приврал. На одном слайде была цитата из "Звездного десанта" (да-да, "специализация - для насекомых", привет Agile), а на другом диаграммы (видимо "барчики", во всяком случае мне так хочется думать).
В итоге второй баг стал для меня очень хорошим опытом. Я в очередной раз убедился, что доклад надо строить так, как будто доски и проектора не существует.

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

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

Кстати, он упоминал компанию GlobalLogic и Романа, но не совсем понятно в каком контексте, там часть мысли где оно упоминалось где-то зажевало.

Так же были ссылки на: Теорию ограничений, на Друкера и на Ицхака Адизеса. На последнего особенно.

Итого. Двух часов не жалко, но бывает и лучше.

Проблема с интернационализацией.

В процессе написания небольшого скрипта на PHP решил, что будет хорошо, если скрипт будет поддерживать несколько языков.
По первому взгляду вопрос решается обычным ассоциативным массивом. Но в этом мире и без меня достаточно изобретателей велосипедов, поэтому следовало посмотреть gettext. Инструмент мне понравился, особенно утилита xgettext, но его настройка пока мне не дается.
Возникли таки проблемы:

1. Хороший плагин для eclipse gted по-умолчанию формирует .po/.mo-файлы в папке ./locale/<код_языка>, а скрипт (считай модуль апача) подтягивает файлы из папки ./locale/<код_языка>/LC_MESSAGES. Неудобно то, что файлы приходится перекладывать.
2. На моем EasyPHP  файлы перевода подтягиваются только после перезагрузки сервера. Понятно, что для продакшн-сервера это будет неудобно.
3. Ну, и никто таки не смог мне внятно объяснить смысл установки локали (setlocale) и переменной окружения (putenv, LANG). Этот вопрос явно мной недокурен в достаточной степени.

Если эти вопросы не решатся, то мой велосипед будет функцией, которая парсит .po-файлы. Удобно тем, что можно использовать тот же xgettext, но не нужен отдельный модуль для Apache. С другой стороны быстродействие... Не знаю, не знаю...

P.S.: Кстати, для модуля i18n, например для drupal, файлы перевода это только .po-файлы. К чему бы это?

P.P.S.: Я был прав насчет перегрузки сервера. Но есть интересный хак при помощи которого можно обойти кеширование .mo-файлов. И с локалью все стало понятно.

Немного о сценарном тестировании

На замечательном сайте www.software-testing.ru есть небольшая статья о 1С:Сценарное тестирование

Деньги-дребеденьги

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

Иконка Админа-угодника

У нас на работе запретили RAdmin и иже с ним. Теперь выкручиваемся через скриншоты и батники. Мой коллега, который задолбался каждый раз рассказывать, в каком сетевом каталоге находится файл, который надо запустить, сделал всем на рабочем столе ярлык «Волшебная иконка».

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

echo "Извините, но без благословения волшебная иконка не работает."
pause

Вот и пошло-поехало у нас: запрос в сервис-деск — помолиться, рассказать о проблеме — покаяться.

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

Барышня щёлкает по иконке, и админу пересылается нужная информация.

— Молитва ваша услышана, ждите благословения.

Если же батниками не исправить:

— Бес вселился в машину вашу, придётся посетить вас лично.

С такими шутками-прибаутками и живём — не сочтите уж за богохульство.

(c) it-happens

The Rise And Fall of Waterfall

Это чрезвычайно любопытно! Чрезвычайно!



Спасибо Максу Дорофееву

И мы не лыком шиты.

Для 1С тоже есть инструменты тестирования (и TDD и юнит-тесты). Например, FuncTest Федора Езеева предоставляет хорошие возможности для тестирования проектов 7.7
Для 8.x есть продукт "1С:Сценарное тестирование 8".

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

Обезьянки, роботы и почему QA не Agile?

Открытый семинар по тестированию оказался очень интересным.
Начнем с того, что основной темой семинара было то, что QA-шникам (Quality Assurance) надоело что их все чмырят и теперь они пропагандируют мысль о том, что они - часть команды не менее важная, чем все остальные и равноправная со всеми. И, конечно, ответственность за результат теперь лежит на всей команде. При этом часто звучала мысль о том, что девелоперы в свободное время могут помогать тестерам писать автоматизированные тесты, и таким образом один тестер может обслуживать нескольких девелоперов лишь определяя общую структуру тестов. Ну, как их можно не чмырить и рассматривать, как равноправных членов команды, если предложение сделать так, чтобы несколько тестеров обслуживало одного девелопера в свободное время помогая ему писать код ни разу не было даже упомянуто. =)

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

И в завершение хочу привести кое-что с самого семинара:

• Во-первых совершенно замечательная презентация Макса Дорофеева "Обезьянки против роботов".
• Во-вторых точное определение проектов, где не ведется тестирование или ведется вручную: "Регрессионная спираль смерти". Очень обнадеживает, не так ли?
• В-третьих я узнал о существовании таких инструментов, как Selenium и системы тайм-менеджмента Pomodoro. И с тем и с другим, я считаю, следует ознакомиться, а может и использовать.
• Ну и, наконец, наблюдение о том, что среди тестеров очень много девушек (и есть даже очень милые). По-моему это прекрасно.

И немного фото:

Где ваши гарантии?

На сайте IT Happens есть одна поучительная история о тупом завкафе и умном студенте. В ней есть одна интересная фраза, которая "как бы" говорит о том, насколько недалек завкаф и насколько умен студент.
Вот она: "C каких пор протокол TCP гарантирует доставку пакетов?"

Давайте разберемся. Честно ответьте на вопрос: а гарантирует ли TCP доставку пакетов? Все, кто ответил "да", станьте справа, те кто ответил "нет" (или "нет, но...") - слева.

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

Ребята справа (те, кто ответил "да, гарантирует"), эта встреча у нас, увы, последняя. Возможно наши дороги еще пересекутся, но сегодня нам явно не по пути. Напоследок, давайте разберемся.

Я разделил наши "разбирательства" на три этапа:

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

Этап второй: переводческий.
Будем прагматичны, обратимся к RFC.
В частности к RFC1122. Для начала я захотел понять, откуда же взялось выражение "гарантирует доставку" и произвел поиск по включению "guar". Итак, слово "guarantees" встречается в документе:

1. В разделе "1.1.3 Internet Protocol Suite" (1.1.3 Стек протоколов Internet) в описании Internet Layer, где говорится о том, что протокол IP не гарантирует доставки пакета.

2. В разделе "3.3.1.4 Dead Gateway Detection" (3.3.1.4 Обнаружение мертвых шлюзов), где говорится о том, что успешный пинг гарантирует то, что адресный интерфейс и сама машина включена, но не гарантирует того, что она будет выполнять роль шлюза.

3. В разделе "4.1.1 USER DATAGRAM PROTOCOL - UDP (INTRODUCTION)", где говорится что протокол UDP не гарантирует доставку дейтаграмм и практически предоставляет приложениям прямой доступ к протоколу IP.

На этом "гарантии" упомянутые в RFC заканчиваются. Т.е. мы понимаем, что в оригинальном документе нам никто ничего не гарантирует. Значит? Обратимся к переводу. Не уверен, существуют ли какие-то "праведные" переводы RFC (вроде Муравьевского перевода Толкиена или Маршаковского Бернса), но нам подойдет первый же выдаваемый Яндексом с сайта rfc.com.ru: RFC1122 на русском.

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

Первый раз мы сталкиваемся в том же разделе 1.1.3, но на один пункт раньше, на транспортном уровне:

TCP представляет собой основанный на соединениях (connection-oriented) транспортный сервис с гарантированной доставкой пакетов, обеспечивающий надежную доставку с сохранением порядка пакетов и управлением потоком данных.Протокол UDP не использует соединений (connectionless) и передает данные в виде дейтаграмм (datagram) без гарантии доставки.

Этот же абзац в английской версии выглядит так:

TCP is a reliable connection-oriented transport service that provides end-to-end reliability, resequencing, and flow control. UDP is a connectionless ("datagram") transport service.

Уважаемый Drop-bear и здравая логика буквально переводят это так:

TCP это надежная модель обмена данными от точки к точке с повторным упорядочиванием и управлением. UDP это модель обмена данными без установки соединения (дейтаграммами).

Заметьте, никаких гарантий.

Второе упоминание (про настройку параметров и их загрузку я опустил) мы встречаем в разделе 4.2.1 (Протокол управления передачей TCP - Введение):

Протокол управления передачей - TCP (Transmission Control Protocol) [TCP:1] представляет собой транспортный протокол стека Internet для работы с виртуальными соединениями. TCP обеспечивает гарантированную доставку с сохранением порядка для полнодуплексных потоков данных (октеты или байты).Протокол TCP используется теми приложениями, которым нужен ориентированный на соединения транспортный сервис с гарантией доставки (например, электронная почта SMTP, передача файлов по протоколу FTP, служба виртуальных терминалов Telnet); требования к таким протоколам прикладного уровня описаны в работе [INTRO:1].

Английский текст:

The Transmission Control Protocol TCP [TCP:1] is the primary virtual-circuit transport protocol for the Internet suite. TCP provides reliable, in-sequence delivery of a full-duplex stream of octets (8-bit bytes). TCP is used by those applications needing reliable, connection-oriented transport service, e.g., mail (SMTP), file transfer (FTP), and virtual terminal service (Telnet); requirements for these application-layer protocols are described in [INTRO:1].

Который можно было бы перевести как (опять спасибо John-1123 и Drop-bear):

Transmission Control Protocol TCP [TCP: 1] является основным виртуальным протоколом транспортной схемы для сети Интернет. TCP обеспечивает надежную, последовательную полнодуплексную доставку потока октетов (8-битный байт). TCP используется приложениями, нуждающимися в надежных способах доставки, ориентированных на соединения между клиентами, например, электронной почтой (SMTP), при передаче файлов (FTP), службы виртуального терминала (Telnet); требования к этим протоколам прикладного уровня описаны в [INTRO:1].

Снова никаких гарантий.

Можно предположить зачем же переводчик добавил эти мнимые гарантии. Возможно, он хотел подчеркнуть отличие TCP от UDP (а как следствие и от IP), а может решил обобщить слова "надежность", "контроль" и другие хорошие (и надежные) слова  в хорошее (и надежное) слово "гарантии".

"И что из этого?" - спросите вы.

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

А из этого следует:

Этап третий: практический.

Если предыдущий этап не убедил вас в том, что TCP все-таки не гарантирует доставки, то давайте проведем эксперимент:
Откройте любое приложение использующее TCP и начните обмен данными (скачивание музыки, получение почты подойдет). TCP гарантирует доставку? Похоже, что да? А теперь вытащите кабель подключения к сети, выключите модем и отключите WiFi (или что у вас там?) Ну, как? Гарантии TCP все еще в силе? =)

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

Т.е. просто написать TCPSocket.Send(*data); и ожидать, что все будет хорошо, строить дальнейший код исходя из посылки о том, что есть "гарантия доставки" в корне не верно.

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

Друзья, читайте RFC в оригинале. Это действительно хороший совет.
(Да, перестаньте плеваться те, кто УЖЕ читают RFC в оригинале, я и сам знаю, что оно сложно переваривается и не менее сложно усваивается. Тем не менее это RFC)

Эпилог: правильные гарантии.

Что же на самом деле гарантирует протокол TCP? Об этом очень хорошо сказано в статье википедии о TCP/IP:

TCP — «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных. TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.

Слово "гарантированный" (вначале) забрано  в кавычки и все остальное определение на редкость точно и лаконично.

И особенно вкусен конец абзаца, не удержусь и повторю его еще раз:

Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.

Вот это - правильные гарантии.


Спасибо.

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

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

Напоминаю о тренинге по тестированию

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

Мануал по RegExp

Совершенно непонятно зачем с php.net убрали толковый ман по regexp-ам и заменили его бестолковым.
Зато в википедии появился замечательный ман. Ходите туда, товарищи.

Календарь 2010

Тень легче и светлее. И дальше?

Недавно я писал пост об Эйфелевой башне. Как вполне справедливо заметил Алексей, я не учел в расчетах того, что тень от башни не абсолютно черная, но слегка серая от отраженного и рассеянного света. Если честно, я ума не приложу где можно было бы найти коэффициент, описывающий отличие "настоящей" тени погожий в летний день, от абсолютно черной тени. Можно было бы самому поставить опыт, но опять-таки, не совсем понятно с какой стороны подступиться, чтобы опыт был однозначным, не зависящим от качества светочувствительной техники.
Однако в Новый Год мне довелось познакомится с одним замечательным полиграфистом из Москвы. Конечно, он не дал мне готового коэффициента, но исходя из его опыта работы с изображениями, насыщенность тени на фото в летний день составляет от 60%-80% от абсолютно черного. Возьмем среднее - 70%. С учетом этой поправки вес будет равен 2,95г. (70% от 4,22г.)

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