среда, 27 июля 2011 г.

KDE как образец организации обратной связи

Некоторое время пользуюсь дистрибутивом Debian Squeeze со штатной графической оболочкой KDE4. Хочу вкратце описать как устроен фидбек по багам в этом софте и поделиться своим восхищением =)
На примере сбойнувшего приложения Blogilo. Это штатная для KDE утилита , позволяющая отправлять посты в блоги с декстопа. Сегодня я ей решил воспользоваться, ну и напоролся на аварийное завершение в одном из сценариев ее использования.
Поначалу ругнулся, но когда увидел, как система отреагировала на сбой , то все заскриншотил, специально повторив crash приложения для этого =)
Итак, сразу после сбоя, я увидел довольно функциональное окно с возможностью зарепортить баг, посмотреть причину сбоя и т.д.

Далее "окошко вежливости":

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


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



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

Далее самое интересное..

До чего дошел прогресс (с)

Недавно открыл для себя очень полезную и простую фичу в python-e.
Буквально одной строчкой в консоли поднимается простенький веб-сервер:


python -m http.server 8000 (для 3-x версий питона)

python -m SlimpleHTTPServer (для 2.X версий питона)


Если явно не указать порт, то будет висеть на 8000.

В итоге при запросе http://:8000/ видим листинг директории, в которой он был запущен.

Как минимум умеет:
1. отображать статические страницы, подхватывает index.html
2. если нет индексной страницы, то показывает листинг текущей директории

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

четверг, 21 июля 2011 г.

Как быстро снять скриншот на гуглофоне

Недавно потребовалось оперативно снять скриншот на Android-смартфоне. Компьютера с SDK под рукой не было. Выручило приложение ShootMe. Доступно на маркете, бесплатно.
Чтобы снять скриншот надо запустить приложение и просто потрясти аппарат :)
Снимки получаются хорошего качества, можно выбрать формат jpg или png (по-умолчанию):

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

понедельник, 18 июля 2011 г.

Насколько может быть важен robots.txt

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

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


http://yandex.ru/yandsearch?p=6&text=url%3Awww.sendsms.megafon.ru*+|+url%3Asendsms.megafon.ru*&fyandex=1&lr=213

красовались сотни страниц выдачи с номерами телефонов и текстами сообщений - было забавно почитать некоторые)

В общем, кто хотел, информацию слил на совершенно законных основаниях с совершенно открытого источника.

А Вы пользовались этим сервисом этого оператора ? :)

p.s. утечка произошла из-за особенностей сервиса и невнимательного отношения к настройке robots.txt , а может незнания того, что для "паука" все разрешено, что не запрещено :)


UPD 21/07/2011:
"Оказались в паблике" потому , что:
1. либо не было файла robots.txt
2. либо в нем не было директив запрещающих индексацию "секретного" URL. Все что не запрещено явно - разрешено для индексации
3. возможно для user-agent 'Yandex' правила и были, только Яндекс , насколько я знаю при индексации иногда заходит на сайты с "левым" агентом. Делается это для борьбы с черными сеошниками (отдельная интересная , но объемная тема)

Вопрос 2: как поисковик узнал о секретном урле со временными смсками?
Тут все просто - для этого не обязательно наличие ссылки со страницы. Тут возможны по меньшей мере 2 варианта, откуда Яша узнал:

1. Кто-то сообщил , используя Яндексовскую-же форму "Сообщить о новом сайте" , где можно указывать произвольный URL, который поисковик попытается обойти при следующем обходе.
2. Поисковик "отреверсил" структуру ресурса. Это не очень сложная задача, а для Яндекса тем более.

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

понедельник, 20 июня 2011 г.

Откуда не ждешь...

Вот сидишь, бывает, тестируешь что-то очень важное и срочное, ищешь ошибки, недочеты в том, что скоро будет продавать твоя фирма. А баги вылезают там, откуда ты этого совсем не ждешь - в софте, который ты для этого используешь. Иногда даже в очень дорогом и "надежном" софте. Бывает, такие "сюрпризы" существенно осложняют жизнь и тормозят процесс... Например, сегодня требовалось организовать эскпорт данных для нагрузочного тестирования и одной СУБД Oracle в другую.
Как любая уважающая себя СУБД Oracle предоставляет собственный инструмент для этого : пара утилит expdp, impdp. Сложность оказалась лишь в том, что запуск expdp приводит к безнадежному Segmentation Fault:

Program terminated with signal 11, Segmentation fault.
#0 0x0000000000409b43 in udcTrace ()
(gdb) bt
#0 0x0000000000409b43 in udcTrace ()
#1 0x0000000000413558 in udcScrubParam ()
#2 0x0000000000407877 in udeProcessLMParam ()
#3 0x0000000000403918 in __libc_csu_init ()
#4 0x00007fff00009fc0 in ?? ()
#5 0x0000000000000000 in ?? ()


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

среда, 1 июня 2011 г.

08.06.2011 - день тестирования ipv6


Более 30 лет назад основоположники Интернета изобрели 32-битную адресацию - всем нам привычный ipv4-адрес. С самого начала можно было предположить, что рано или поздно свободные адреса закончатся. Но до этого момента было очень-очень далеко. И вот он уже вот-вот настанет. Адреса будут исчерпаны уже в этом году. Чем это грозит нам, как простым пользователям Интернета? Да , собственно, ничем. Все существующие ресурсы будут продолжать резолвиться по их ipv4-адресам.
А чем для нас , как тестировщиков, обернется переход на ipv6? Многим из нас предстоит приступить к тестированию поддержки ipv6 в ПО, потому что разработчики (и их менеджеры), которые не подумали об этом ранее , уже начали шевелиться, готовиться. Особо попотеть придется разработчикам и тестировщикам системного по, биллинговых систем, а также различного рода сетевых приложений. В любом случае будет интересно. Это в общем.

Так что же такого будет происходить 8-го июня? Ничего особенного. Просто те компании, которые заявили о своем участии в "дне тестирования ipv6" на 24 часа включат поддержку ipv6 на своих первичных ресурсах, а принимающие участие в эксперименте провайдеры (ISP) сделают соответствующие апгрейды софта на своем сетевом оборудовании.

Посмотреть список компаний-участников можно здесь. На этом же сайте можно заявить о своем желании поучаствовать, а также в целом ознакомиться с проблематикой.

Ждем 8-го)

Приятная неожиданность )

Все мы часто пользуемся личными кабинетами у своих интернет-провайдеров.
У каких-то операторов они удобные, функциональные, у каких-то не очень. Частой фичей этих самых кабинетов стала возможность подписки по SMS на различные типы событий. Например, о поступлении средств на счет или предупреждения о скорой блокировке аккаунта и т.д. и т.п.
Мой провайдер по слухам когда-то предоставлял такую функцию, но для некоторых групп абонентов почему-то ее заблокировал. Сегодня я узнал, что я тоже в этой группе, не найдя возможности подписаться на SMS в своем личном кабинете.
В общем, уж не знаю, что меня заставило открыть исходный код главной страницы личного кабинета, но факт в том, что в этом самом коде я заметил закомментированный пункт меню "Подписка на SMS оповещения". Я машинально скопировал я ссылочку из этого "заблокированного" пункта меню, вставил в адресную строку броузера и очень удивился , когда увидел соответствующую web-форму ) (очень надежный способ блокирования функционала =)
Ну и подписался, конечно. Еще более удивительным оказалось то, что подписка реально заработала и услуга эта оказалась бесплатна. Ничего не остается теперь, как пользоваться втихоря )))

четверг, 26 мая 2011 г.

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-версии...

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

понедельник, 16 мая 2011 г.

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

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

воскресенье, 8 мая 2011 г.

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



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

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

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

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

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

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