На этом блоге в меру своих сил я буду делать следующее:

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

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

Для начала немного теории.

Есть два термина, которые разработчики часто путают: интернационализация и локализация программы. Интернационализация — это адаптация продукта для потенциального использования в любой стране, а локализация — это добавление специальных функций для использования программы в некотором определённом регионе. Интернационализация производится на начальных этапах разработки. Локализация делается для каждого целевого языка отдельно (подробнее смотрите здесь). Разработчики shareware занимаются обычно как раз интернационализацией, потому что у них просто недостаточно ресурсов для создания отдельных версий приложений для разных языков или стран, как делает, например, Microsoft.

При интернационализации важно еще на стадии проектирования не привязываться к конкретным языкам и странам во избежание конфликтов на национальной почве. Если вы хотите, чтобы продажи программы пошли в ОАЭ, надо, как минимум, вставлять в нее текстовые редакторы с поддержкой двунаправленного письма, использовать Unicode-строки во всех местах и, соответственно, Unicode-шрифты. Также следует озаботиться запросом у операционной системы изменяющихся от страны к стране региональных стандартов представления чисел, даты, денежной единицы и всем остальным, что на русском языке по-идиотски называют “культура приложения”, очевидно криво переведя английский термин “software culture”.

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

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

Способов решения два:

1. Платный. Вынести все используемые в программе строки в файл ресурса, раздать его переводчикам, заплатив примерно от $5 до $10 за каждые 1000 символов, и включить переведенные ресурсы в программу.
2. Бесплатный. Сделать файлы с переводными строками доступными для изменения “на ходу” всем желающим, и поощрять самостоятельное выполнение переводов заинтересованными пользователями с постепенным включением их в дистрибутивы новых версий.

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

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

Мы нашли способ объединить эти два решения.

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

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

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

CloseButton.Caption := SS('Close')

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

1. Как идентифицировать используемые языки?
2. Как переводить множественные формы в предложениях с числительными?

Рассмотрим эти вопросы подробнее.

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

С этими буквенными кодами языков не все просто.

Имеется несколько версий стандарта буквенного кодирования языков под названием ISO 639, и каждая последующая версия расширяет их доступный набор. Стандарт ISO 639-1 регламентирует двухбуквенные коды для основных мировых языков (en, ru, fr и т.д.), ISO 639-2 расширяет код до трех символов, значительно увеличивая набор доступных языков (eng, rus, fra и т.д.) и вводя тонкости их модификаций (например, fre/fra — современный французский, а frm — средневековый французский), ISO 639-3 тоже трехбуквенный, но покрывает также десятки диалектов и наречий, включая все разновидности наречий американских индейцев. Гигантскую сводную таблицу этих стандартов можно посмотреть здесь.

Кстати, многие делают ошибку, путая код языка с кодом страны. Хотя они иногда и совпадают (например, для России и русского языка, ru-RU), но в общем случае они должны отличаться. Коды стран должны соответствовать стандарту ISO 3166, и их записывают обычно большими буквами, если они стоят в паре с кодом языка (en_US, en_GB, uk_UA). Код страны важен для определения региональных настроек, но, поскольку предполагается, что интернационализация программы была сделана вдумчиво, и все региональные настройки типа даты и валюты выбираются из операционной системы, мы отбросили код страны за ненадобностью. Единственное место, где он может пригодиться в таком случае — это поддержка “местных” особенностей языков и локальных диалектов. Характерный пример: британский и американский английский могут отличаться используемыми наборами слов. Однако, если ваше приложение не содержит больших объемов связного текста, этот аспект можно игнорировать, все равно текстовые метки над полями ввода из трех слов правильно поймут и американцы, и англичане.

Мы приняли за основу языкового кодирования стандарт ISO 639-2, как наиболее распространенный трехбуквенный код, который описывает большинство языков. А если его недостаточно для идентификации языка (или диалекта), то дополнительно к этому коду используется код ISO 639-3. Посмотреть, как строится наш переводной XML-файл с секцией описания доступных языков, можно по этой ссылке.

Автоматический выбор языка в таком случае слегка затруднен тем, что привычный программистам двухбуквенный код текущего языка операционной системы (en, ru и т.д.), возвращаемый системной функцией GetLocaleInfo() с параметром LOCALE_SISO639LANGNAME, соответствует двухбуквенному стандарту ISO 639-1, поэтому пришлось построить таблицу соответствия между ISO 639-1 и ISO 639-2. Так что для большинства языков автоматический выбор все равно сработает. А если не сработает, то пользователю придется его выбрать вручную в меню один раз, ничего не поделаешь.

Переходим к множественным формам.

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

Пример: дана переводная строка «Было задано x вопросов», где x — числовая переменная. При обычной подстановке x = 1 получается строка, как будто написанная роботом, который не знает, как правильно согласовывать предложения с числами: «Было задано 1 вопросов». Некоторые разработчики используют убогую схему подстановки вроде такой «Было задано x вопрос(ов)», или вообще «Было задано x вопрос(-а, -ов)», т.е. право выбора правильной формы великодушно предоставляется пользователю.

А если все делать, как следует, то переводная строка должна была бы меняться так:

• (x = 1) «Был задан x вопрос»

• (x = 2) «Было задано x вопроса»

• (x = 5) «Было задано x вопросов»

• (x = 21) «Был задан x вопрос»

• (x = 35) «Было задано x вопросов»

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

Особой формы обычно требует также нулевое значение переменной:

• (x = 0) «Не было задано ни одного вопроса»

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

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

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

msgid "%d day ago"
msgid_plural "%d days ago"
msgstr[0] "%d день назад"
msgstr[1] "%d дня назад"
msgstr[2] "%d дней назад"

Здесь msgid — это оригинальная английская строка для одиночной формы, msgid_plural — оригинальная английская строка во множественном числе, %d — целочисленная переменная, по которой будет производиться выбор нужной формы в целевом языке, а массив msgstr[n] представляет все одиночные и множественные формы переведенной строки.

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

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

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

{%номер_переменной|форма_0|форма_1|форма_2|…|форма_N}

где

• номер_переменной — порядковый номер целочисленной переменной, по значению которой будет выбрана нужная форма предложения;

• форма_0 — нулевая форма, которая будет выбрана при нулевом значении переменной;

• форма_1…форма_N — все множественные формы предложения в данном языке.

Пример использования в наших переводных файлах:

   <id text="{%1|No right answers|1 right answer|%1 right answers},
             {%2|no wrong answers|1 wrong answer|%2 wrong answers}">
     <rus>{%1|Нет правильных ответов|%1 правильный ответ|%1 правильных ответа|%1 правильных ответов},
          {%2|нет неправильных ответов|%2 неправильный ответ|%2 неправильных ответа|%2 неправильных ответов}</rus>
   </id>

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

Например, при подстановке %1 = 0, а %2 = 5 получим «No right answers, 5 wrong answers».

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

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

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

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

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

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

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

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

Теперь у меня есть правило: если я не могу при регистрации пройти CAPTCHA за 3 попытки, то я иду искать другой аналогичный веб-сервис, благо сейчас их очень большой выбор. Да здравствует конкуренция!

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

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

Особенно глупо этот лозунг выглядит, если применяется к коммерческим веб-сайтам. То, что сайт работает круглосуточно, еще не значит, что компания, которая стоит за этим сайтом, никогда не спит. И было бы странно, если бы сайт компании работал с 8:00 до 17:00, а не 24 часа в сутки. Но не ждите, что заявки, оставленные вами на сайте в 3 часа ночи, будут рассмотрены и обработаны сразу же.

Немного отличается ситуация для дешевого shareware, которое продается через онлайн-магазины. Если после перевода денег через электронную платежную систему автоматический кодогенератор сразу же высылает клиенту регистрационную информацию с ключом, то это может считаться круглосуточным сервисом, если вся система работает без проблем. Но если вдруг где-то в цепочке автоматического обслуживания появляется сбой (например, сервер неожиданно упал и кодогенератор стал не доступен), то клиенту все равно придется ждать, пока вы проснетесь, проверите e-mail и придумаете решение проблемы.

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

Электронная ловушка представляет собой чёрный сундучок, на задней стенке которого имеются две лесенки. Взобравшись по ним, мышь попадает прямиком в "камеру сгорания", именуемую Shock N’ Drop Chamber.

Там её со 100-процентной гарантией за 3-5 секунд убивает электрический заряд. Затем камера переворачивается и сбрасывает бездыханное тельце в ящик, вмещающий трупики 10 грызунов. О том, что ящик переполнен, владельцу мышеловки "сообщит" световой индикатор.

Помимо скорбной процедуры опустошения ящика от человека требуется лишь регулярно класть в "Виктора" приманку и включать устройство.

Комплекта из четырёх батареек типа C хватает для уничтожения 150 мышей.

Прочитать полностью

Сразу вспомнилось, как я боролся с мышами, работая банковским админом.

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

Начальница выдала мне разрешение на ликвидацию мыши и я пошел покупать мышелоку.

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

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

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

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

Уверен, что мыши мерзко хихикали за стенкой, пока я, матерясь под 100-вольтными ударами тока телефонной линии в момент дозвона, скручивал провода синий-к-синему, зеленый-к-зеленому и т.д. (и так очень много раз).

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

Так вот, я к чему, собственно: если вы будете ставить этот "Victor Multi-Kill" из новости, подумайте о том, как мыши могут отомстить вам, если меня они так довели за простую дедовскую пружинную мышеловку.

Вот яркий пример. MS Word с его знаменитыми двумя пунктами меню "Сервис", которые мало того, что являются полными синонимами в сознании пользователя, но еще и расположены рядом.

Пункты "Настройка…" и "Параметры…". Кто их не путал никогда, пусть первым бросит в меня камень.

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

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

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

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

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

Если у вас картинка не загрузилась, или шрифт мелковат, я еще раз напишу текстом

—————
Предупреждение
—————
Некоторые задания по проверке или отправке почты еще не завершены.
Вы хотите выйти из программы по их завершении?
—————
Да, Нет, Отменить
—————

(Кстати, не все знают, что можно скопировать в буфер обмена текст из любого стандартного диалогового окна Windows, просто нажав Ctrl+C)

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

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

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

• Пользователь нажал кнопку получения почты, потому что с нетерпением ждет письмо от возлюбленной.
• Почтовый клиент полез на POP-сервер и выполняет длительное действие по перекачиванию спама (с рекламой средств для увеличения кое-чего на 5 см) из почтового ящика на компьютер.
• Пользователю это надоело, потому что 10 Мбайт спама загружаются медленно даже на выделенных линиях, и нужного письма все не видно.
• Пользователь нажимает кнопку-крестик в заголовке окна TheBat для его закрытия.

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

Ведь пользователь может не знать, что прием/отправка писем — это в общем случае длительный фоновый процесс, и его прерывание будет означать, что письма не дойдут до адресата или не скачаются с сервера. Тогда вместо того, чтобы немедленно прекратить пересылку, пользователя следует проинформировать об этом и намекнуть, что правильнее все-таки подождать до завершения передачи, а только потом уже выйти из программы. Но пользователь может не захотеть выходить из программы после того, как пересылка закончится, так как он может при этом получить важную почту, и ему будет необходимо время на ее прочтение. Фраза "Вы хотите выйти из программы по их завершении?" демонстрирует полную уверенность разработчиков в том, что после того, как идиоту-пользователю объяснили, чем сейчас компьютер занимается, у него даже не возникнет мысль о досрочном прекращении процесса. А вдруг ему как раз не нужно ожидать завершения передачи, и надо все-таки выйти прямо сейчас? Может, добавить кнопку "Отменить" на всякий случай?

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

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

Что мешало перестроить запрос, например, так:

—————
Предупреждение
—————
Идет получение/отправка почты. 
Выйти из программы сейчас? 
—————
Да, Нет
—————

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

P.S.

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

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

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

Внутреннее ПО обладает несколькими характеристиками, которые меня доводят больше всего:

1. Масса логических ошибок.

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

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

2. Морально устаревший пользовательский интерфейс.

   Вызывает смех сквозь слезы, когда организация закупает новейшие компьютеры с многоядерными 64-разрядными процессорами, 20-дюймовыми TFT-мониторами и предустановленной Windows XP OEM, а потом на них запускают 16-разрядное ПО от Васи Пупкина из второго отдела в окне MS-DOS и текстовом режиме 80х25. Это малюсенькое окошко одиноко торчит в углу экрана (не все знают, что надо нажать Alt+Enter для его максимизации), и людям приходится вводить данные в кошмарные текстовые формы с псевдографикой, которые были лучшим образцом юзабилити в 1985 году. Конечно, без использования мышки и без возможности скорректировать введенную информацию.

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

   Еще один пример идиотской концепции интерфейса — все виденные мною системы разделения доступа во внутренних приложениях. Когда-то, в конце восьмидесятых — начале девяностых годов, в СНГ сложился стиль разработки ПО с расчленением приложения на задачи-оверлеи. Каждая такая «задача» запускалась в отдельном окне, в котором она принимала команды от пользователя, делала что-то с данными из локальной БД и клала их обратно. Разделение доступа заключалась в том, что создавалось огромное меню задач, и каждому пользователю давался доступ только на определенное их подмножество. Меню обычно хранилось в текстовом файле на каждом рабочем месте, и администратору безопасности, чтобы расширить/ограничить кому-то разрешения, приходилось оббегать все компьютеры, вручную внося исправления в эти текстовые файлы, «закомментировав» несколько строк. Защитить саму базу данных (будьте прокляты, тысячи dbf-ок!) не представлялось возможным, и она регулярно убивалась нечаянными действиями пользователей. Спасали только частые резервные копии. С тех пор в архитектуре внутреннего софта ничего не изменилось. Факт того, что сейчас рулят многозвенные клиент-серверы и веб-интерфейсы, разработчикам внутреннего ПО совершенно неизвестен.

3. Абсолютная негибкость конфигурации.

   Очень мало или совсем нет параметров внутреннего софта, которые можно изменить для повышения удобства работы пользователя. У программиста почему-то никогда не возникает мысль, что условия на рабочих местах могут отличаться от того, на котором он пишет программу. Разрешение экрана — только 800х600, ни пикселя больше. Битов на пиксель — только 8, ведь 256 цветов — это очень даже много. Каталог, в который должна быть установлена программа — только «C:\ARM\», даже не обсуждается. Веселье начинается, когда две программы должны быть установлены в каталог C:\ARM\, потому что это очень популярное название. Экспорт данных — только на дискету под буквой «А:», пожалуйста, потому что выходное устройство намертво забито в исходном коде, а исходный код программист-пенсионер унес с собой в могилу. Я видел, как несчастные пользователи работали с такой программой, не вынимая дискету из дисковода, используя ее как промежуточный буфер между базой данных и сетевой папкой. Иногда после экспорта данных из приложения дискета не считывалась, поэтому приходилось ее форматировать и повторно запускать процесс экспорта с предварительной настройкой в течение получаса.

4. Невозможность понять, как это работает, без непосредственного общения с программистом.

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

5. Невозможность самому разработать альтернативное, лучшее ПО.

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

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

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

Почему внутренний софт такой?

Причины, в общем-то, очевидны:

• Программисты не заинтересованы в качестве своего продукта.

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

• Внутреннее ПО не разрабатывает молодежь.

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

• Если внутреннее ПО заказывают на стороне, то на него тратят минимально возможные средства.

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

Вы можете спросить: «Автор, ты зачем все это рассказываешь? Мне вот все это было и так понятно, но я не думаю, что об этом стоит беспокоиться, ведь низкое качество внутреннего ПО — это вполне естественно, и тут ничего не поделаешь».

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

Так зачем нужно улучшать внутреннее ПО?

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

1. Некачественный софт усиливает текучку кадров.

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

2. Некачественный софт снижает эффективность работы сотрудников.

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

3. Вы будете терять деньги из-за ошибок софта.

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

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

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

То же самое относится и к пользовательскому интерфейсу! Программа не должна быть кричащей истеричкой! Если у вас вместо кнопки "Пуск" будет написано "Пуск!", то мне будет страшно на нее нажимать: кто знает, на какие последствия нажатия вы намекаете этим восклицательным знаком!

Вам не тяжело читать этот пост?!!!

А этот сайт?!!

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

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

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

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

Из платных программ мне понравилась HyperCam (стоит 35 $, но единственным ограничением демо-версии является вывод предупреждающего текста в углу снятого видео, что для тестирования, в принципе, безразлично). HyperCam при записи почти не влияет на работу компьютера и пишет видеоряд сразу в avi-файл сносного качества (вполне можно разобрать мелкий текст). Минус программы в том, что она не поддерживает WPF-приложения.

Тестировщикам под WPF мне, к сожалению, порекомендовать нечего. Хорошим решением был бы SnagIt (50 $), но эта программа не захватывает окна с полупрозрачностью, которые в WPF-приложениях могут встречаться довольно часто.

А для тестировщиков, которые работают с полноэкранными DirectX и OpenGL приложениями (игры и другие мультимедиа), будет полезной программа скоростного видеозахвата Fraps (37 $).

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

P.S. Недавний выход игры S.T.A.L.K.E.R. Clear Sky очень явно показал, что далеко не все отечественные тестировщики доходят хотя бы до второго этапа из перечисленных. Вы же не хотите, чтобы на вас потом так же плевались пользователи? Если не хотите, то ловите случайные ошибки, не пускайте их в мир.