ICQ для Linux: сделано для галочки

Вчера на в "ленте" промелькнула новость о том, что Mail.Ru group презентовала линуксовую версию одиозного клиента ICQ. Сегодня с утра решил попробовать "это" в деле, заранее ожидая кучу подвохов..)
Итак, захожу на офсайт ICQ, действительно нахожу в списке загрузок пунктик для linux-версии, открываю соответствующую страницу - ага , вот и кнопка "Скачать". Радостно ее жму.. ничего. Не работает закачка. Мозилловский броузер под Debian... Вот они, начались подвохи. Броузеров на свете много, решаю перебрать. Запускаю штатный KDE-шный Konqueror. Этот "гадкий утенок" благополучно качает мне на винт *.air - файл.
AIR? Всего-то? Видимо, глупо было ждать полноценного портирования в виде QT-приложения. Теперяшние хозяева ICQ пошли по пути наименьшего сопротивления , сделав кросплатформенную air-версию (тогда непонятно, причем тут Linux? Ах да, маркетинговый ход =)
Двигаемся дальше..
Так как ранее запуском AIR-приложений под Linux я никогда не занимался ни в исследовательских, ни в каких бы то ни было других целях, то пришлось поставить AIR-платформу от Adobe: sudo aptitude install adobeair .
В результате в директории /opt/Adobe\ AIR/Versions/1.0/ у меня завелся Adobe-овский инсталлер для air-приложений, которым и надо открывать *.air файлы. Название у инсталлера жутко неудобное 'Adobe AIR Application Installer' - делаем симлинк в /usr/bin: cd /usr/bin; sudo ln -s '/opt/Adobe\ AIR/Versions/1.0/Adobe AIR Application Installer' aaai
Далее вызываем aaai и открываем с его помощью скаченный асечный air-контейнер.
Начинается установка, соглашаемся со всем, что нам предложат.
Установка завершена. В трее висит знакомый до боле восьмилистник. Жмем...
Увы - всего лишь пустое окошко без единого элемента управления...
Как говорится , "не смешно". Такой UI - слишком сурово даже для beta-версии...

Разбраться в причинах такой "дружелюбности" интерфейса уже нет ни времени , ни желания =)

Производительность и особенности индексирования таблиц в СУБД

Недавно столкнулся с проблемой производительности приложения, работающего с СУБД Oracle.
Есть таблица А, в ней есть строковый столбец B, для которого создан простой индекс. Есть несколько веб-форм, делающих различные запросы (в т.ч. и SELECT) к этой таблице.
Одна из этих форм, делающая простейший SELECT к указанной таблице, очень долго "откликается" на даже на единичный запрос при больших объемах данных. При этом есть и другие формы, отображающие данные из этой таблицы в том или ином виде - с этими формами проблем нет. Сравниваем запросы. В проблемной форме к индексируемому полю в секции WHERE применяется функция upper. Поле проиндексировано, но план выполнения показывает, что индекс не используется. Кто-то советует собрать статистику, кто-то советует прохинтовать запрос. А на самом деле, надо просто немножко углубиться в матчасть и понять, что при использовании функции результат становится непредсказуемым для оптимизатора, поэтому в данной ситуации необходимо либо отказаться от upper , либо создать дополнительный индекс по используемой функции.

Приносит ли тестирование деньги?

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

1. Умирающие стереотипы
Долгое время тестирование программного обеспечения действительно имело второстепенную роль и зачастую этим видом деятельности (отдельной и целенаправленной) многие производители софта пренебрегали. Рынок не диктовал таких жестких требований к качеству как сегодня, конкуренция среди производителей не была столь высока, клиенты не были столь придирчивы и требовательны. То есть, чисто экономически , многие вендоры осознанно не тратили деньги на тестирование, потому, что их софт и так "уходил как горячие пирожки". С развитием рынка ПО эта ситуация стала меняться. И на Западе давно уже стереотипам о второстепенности тестирования нет места, они отжили и умерли. Изменилось и отношение к тестировщику , как представителю отдельной профессии, носителю специфических навыков и менталитета. В нашей стране еще перемены дошли не до всех, но ситуация меняется - доказательством этому является бурный рост коммьюнити, спрос на соответствующие образовательные курсы, рост зарплат и т.д. и т.п.

2. "Само по себе"
Многие дискутирующие на тему о прибыльности тестирования (имеется ввиду прибыльность для производителя софта) чрезмерно увлекаются теоретической декомпозицией процесса разработки. Приходится слышать "безусловно , без тестирования - никуда, но оно само по себе напрямую денег в кассу не несет, потому бла бла бла бла...". Сразу хочется прервать и спросить: "А что значит "само по себе"?". Или приносит ли "само по себе" деньги та же разработка? И что такое "разработка" - только лишь кодирование? Получаешь ответ "Конечно же нет, разработка это не только кодирование но и то-то то-то и то-то"... И в итоге получается, что ни одна стадия без другой немыслима. "Входы" одних завязаны на "выходы" других и наоборот.. Так кто "сам по себе" приносит деньги? Более подходящего ответа, чем "инкассатор" у меня ничего другого на ум не приходит :) Таким образом, если признается, что в данной конкретной фирме, проекте, процессе "без тестирования нельзя", тогда и говорить о том, что "оно не приносит денег" по меньшей мере некорректно.

3. Если что-то нельзя пощупать оценить, значит этого просто нет
Часто приходится получать встречный и резонный вопрос "Хорошо, допустим, тестирование приносит прибыль. Какую конкретно ?( в процентах, рублях или любой другой количественной форме)" Действительно , вопрос на первый взгляд непростой и , как говорится , с подвохом. Пытаться на него ответить "конкретными" процентами, полагаю, просто невозможно. Такой вопрос можно смело считать провокационным и смело об этом заявлять задающему :) Таких вопросов, считаю, после достижения понимания по п.2 ("Само по себе") быть попросту не должно.

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

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

Баги , которые лучше не фиксить :)

Сегодня очень развеселил Майкрософт, вернее его продукт Outlook 2007.
Сегодня развернули внутреннюю ленту новостей с использованием Trac и его компонента Blog.
Заведомо знал , что у компонента есть Rss-лента,а у Outlook - Rss Reader.
Когда дело дошло до того, чтобы прикрутить эту ленту к outlook столкнулся с тем, что ему обязательно требовался url в формате: http://example.com/feed/main.xml - то есть линк на xml-файл.
Я расстроился, так как у Trac-a url следующий: http://trac.bm.in-line.local/blog?format=rss

Решение пришло через минуту : http://имя хоста с ,где установлен trac/blog?format=rss&blablabla.xml - и эврика! масдаевский софт на это клюнул, благополучно подгрузив в почтовик нужную мне ленту новостей)))

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

В общем, пользуйтесь ;)

Визуализатор схемы БД "на коленке"

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

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

Под рукой был python с установленным модулем sqlalchemy, а также вспомогательная python-овская библиотека для визуализации графов, средствами GraphViz.

Простейший скрипт на python:


#script: visualize.py
from sqlalchemy import MetaData
from sqlalchemy_schemadisplay import create_schema_graph
graph = create_schema_graph(metadata=MetaData('sqllite:///database.db'),
show_datatypes=False,
show_indexes=False,
rankdir='LR',
concentrate=False
)
graph.write_png('database.png')


и у меня перед глазами был png-файл , где вся схема была как на ладони.

Итак, еще раз ингридиенты:

1. python 2.5 (2.6,2.7) (aptitude install python)
2. sqlalchemy (easy_install sqlalchemy)
3. библиотека-GraphViz (aptitude install graphviz)
4. sqlalchemy_schemadisplay (wget http://pypi.python.org/packages/source/s/sqlalchemy_schemadisplay/sqlalchemy_schemadisplay-1.0.zip#md5=14b8366bb27b6abef32df65710d4380f )
5. visualize.py (см. код выше)
6. создаем произвольную директорию и кидаем туда п.5 и п.4, а также sqlite-базу)
7. запускаем: python visualize.py и получаем database.png

Все это хозяйство точно работает и с mysql (проверял лично) , а также должно теоретически работать почти со всеми известными СУБД (oracle, ms sql server, access db, postgres ...)

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

p.s. на этот раз ограничений с ОС нет. Все это работает и под Windows. Надо только скачать инсталлеры python-а graphviz-а с соответствующих офсайтов.

Миллиарды от багов не спасают )

В феврале 2007 года ВВС США решили впервые вывести F-22 за пределы страны, перегнав несколько истребителей на базу ВВС Кадена на Окинаве. Звено из шести F-22, вылетевших с Гаваев, после пересечения 180-го меридиана - международной линии перемены дат - полностью лишилось навигации и частично - связи. На базу ВВС на Гавайях истребители вернулись, визуально следуя за самолетами-заправщиками. Причиной неполадки стала ошибка в программном обеспечении, из-за которого произошел сбой в работе компьютера при смене времени.

Сказка о профессионализме... )

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

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

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

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

Начальник отдела рисования Сидоряхин торопливо кивает:

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

— Очень приятно, — говорит Морковьева. — Ну, меня вы все знаете. А это — Леночка, она специалист по дизайну в нашей организации.

Леночка покрывается краской и смущенно улыбается. Она недавно закончила экономический, и к дизайну имеет такое же отношение, как утконос к проектированию дирижаблей...........ЧИТАТЬ ДАЛЕЕ

Как говорится , сказка - ложь, да в ней намек... )

Новый сотрудник

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

1. Неточности во всевозможных HOWTO для новых сотрудников. Как правило не всегда хватает времени , чтобы держать подобные мануалы в полностью актуальном состоянии - поэтому при работе нового тестировщика с этими документами появляется неплохой шанс привести инструкции в соответствие реальному положению дел. В данном вопросе можно пойти на дополнительную хитрость: обеспечить новичка документом, заведомо содержащим изъян и понаблюдать за тем, как человек будет решать возникшую проблему, заметит ли он ее вообще? Немного по-иезуитски, но это позволяет лишний раз убедиться в правильности решения после собеседования.
2. Порция некритичных ошибок в тестируемом ПО Незашоренность взгляда,а также отсутствие груза важной и срочной работы у нового сотрудника позволяет ему замечать множество мелких ошибок и недочетов в тестируемом ПО. Как правило это незначительные ошибки в GUI, ошибки эргономики , пропущенные более опытными коллегами, а также порция замечаний и предложений по улучшению. Многое из всего, что "замечает" новый тестировщик в итоге не приводит к изменениям и улучшениям, но какой-то процент действительно полезных замечаний обеспечен в любом случае.
3. Ошибки в документации к ПО Не знаю как у других, но в число обязанностей моей команды входит и тестирование пользовательской документации к ПО. В силу разных причин пользовательская документация неизбежно начинает накапливать неточности, несоответствия с реальным поведением системы. И новый тестировщик, априори внимательно относясь к пользовательской документации (ведь зачастую именно по ней он знакомится с системой ), неизбежно натыкается на эти несоответствия , а также на отсутствие необходимых ему сведений. Это позволяет повысить качество этой самой документации.
4. Повторение - мать учения. Во время помощи новому коллеге часто приходится вспоминать некоторые аспекты функционирования тестируемого софта, пояснять и уточнять последовательности настройки, развертывания тестовых стендов и т.д. и т.п. - все это может показаться скучным, но иногда это позволяет вспоминать уже подзабытые ньюансы, освежая и закрепляя таким образом собственное знание системы.
5. Новые техники. Новый сотрудник, особенно опытный, может привнести с собой новые техники тестирования. Например, когда-то давно пришел к нам тестировщик, хорошо знакомый с техниками пентеста. Его знания и умения пошли на пользу и успешно дополнили уже имевшиеся на тот момент наборы тестов безопасности системы. Сотрудник уже давно перешел в другую компанию, но его опыт продолжает приносить нам пользу.

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

Требования: по ту сторону баррикад

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

"ПРИНЦИПЫ РАБОТЫ С ТРЕБОВАНИЯМИ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ" (Дин Леффингуэлл, Дон Уидриг)

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

lsof+gdb - надежные помощники при "трудном" моделировании

Совсем недавно в ходе попыток моделирования очередного "мигающего" и трудновоспроизводимого бага потребовалось запустить очень продолжительную серию испытаний , в ходе которой требовалось эмулировать частую потерю соединения приложения с СУБД. Эмуляция активности приложения , естественно, автоматизирована. Продолжительность теста - минимум 30 минут, максимум - 2-3 часа. В общем, понятно, что вручную "дергать" витую пару - не вариант =) Первое, что пришло в голову использовать файер (iptables). Попробовали - и по ряду причин (здесь их не описываю) вынуждены были отказаться от этого способа.

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

С помощью lsof узнаем дескрипторы соединений (у ислледуемого нами их могло быть несколько), а с помощью gdb в "batch"-режиме закрываем сокеты по их дескрипторам.


#генерируем файл с командами на закрытие нужных нам дескрипторов (в данном случае дескрипторы соединения с СУБД висящей на фиксированном порту 1521)

lsof -p 5239 | grep ':1521' | awk '{print $4}' | sed 's/u//' | awk '{print "call shutdown("$1",2)"}' > commands

#скармливаем пакет команд gdb

gdb -p 5239 -batch -x commands



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

Все это под linux, все это бесплатно , быстро и эффективно.

Возможно, кто-то спросит "Как сделать аналогичное под Windows?" - сразу не отвечу, но на досуге ничего не мешает выяснить, если это действительно кому-то понадобится =)