Дома бился пару дней чтобы поставить Nagios на Debian.
Оказалось не всё так тривиально.
Хотел отметить пару моментов, с которыми мне пришлось столкнуться и какие решения я принял:
1. Когда ставишь библиотеку libjpeg-v6b для GD, то файлы не копируются автоматически в /user/local/lib & /user/local/include, т.е. надо их из распакованной папки надо копировать ручками.
2. Для установки GD надо предустановленную библиотеку gd-devel, так вот - я делал в директории Nagios пару дней ./configure и он мне выдавал ошибку что нет библиотеки GD, оказалось, надо ставить библиотеку libgd-dev с которой конфигурация нагиоса прошла “на ура” вообще без параметров.
3. Не работала обработка cgi-bin на apache2. Т.е. после запуска нагиоса, и прохождения базовой аутентификациии я видел главную страницу, но не мог открыть ни одной страницы, для которой путь значился как /nagion/cgi-bin. Для начала оказалось, что надо включить в apache2.conf строку “addhandler cgi-script .cgi”
4. Ну и последний момент, который пришлось долго гуглить: надо добавить в конфигурацию апача алиас для cgi-bin, приблизительно так:

ScriptAlias /cgi-bin/nagios /user/local/nagios/sbin
ScriptAlias /nagios/cgi-bin /user/local/nagios/sbin

Теперь надо понять как настроить мониторинг

Дальше по планам:
1. Буду ставить шифрованный впн
2. Буду переводить сайты на связку Apache + Nginx
3. Настроить безопасность.

Связанные записи

• Нет связанных записей.

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

• Установка APC на Дебиан. APC - это Alternative PHP Cache.
• Применить хотя бы часть из советов на этом сайте - например, включение gzip в Apache, компрессия css и js файлов, оптимизация изображения
• ПереСжать картинки

Касательно APC: запустив

ab -n 1000 -c 2 -w http://iamqa.com

до и после установки APC, я получил значительные изменения в лучшую сторону(connection time уменьшился в 57%, transfer rate увеличился на 64%, количество обработанных запросов в секунду увеличилось на 63%).

upd. следующий факт изрядно попортил мне крови: при переносе базы из локального вордпресса к хостеру, у меня постоянно вываливались разного рода ошибки, на maxsite рекомендовали удалить пустую строку после директивы ?> для php секции.. всё оказалось банально - phpmyadmin на локальной машине просто криво экспортировал дамп базы. Задача быстро решилась с помощью плагина для Wordpress: DB-backup.

Связанные записи

• тестовое сообщение

проверка связи

Связанные записи

• Строить не ломать

Периодически у меня возникают проблемы взаимопонимания с людьми. И вроде говорим мы оба на русском языке - ан нет, не понимаем, начинаем говорить громче и быстрее со всеми отсюда вытекающими..
В чем причина?
За последние пару недель мне пару человек подсказали в чем может быть дело и сегодня я наткнулся на статью, которая частично покрывает пробел.
Итак,

Пример 1:
Пошёл старик к синему морю. Стал он кликать золотую рыбку. А какую рыбку - не уточнил. Приплыла к нему золотая акула. Ну… и всё..

Пример 2:
Жил некий праведный человек. Праведную жизнь вёл же он для того, чтобы возымела силу молитва его, вознесённая к небу. И когда решил он, что пришло время, истово помолился он и возопил:
- Господи, пошли мне богатства!
В небесах хихикнуло, и хрипловатый голос, копируя интонации Вахтанга Кикабидзе, торжественно сказал:
- Твои года - твоё богатство!
И человек мгновенно поседел, одряхлел, сморщился и, прямо скажем, недолго прожил…

Пример 3:
Ты совершил великий подвиг, рыцарь. Что желаешь ты получить в дар?
- Волшебные доспехи хочу! Чтобы ни один меч на свете не мог их пробить!
- Угу. Есть такие. Сейчас найдём. Сейча-а-ас… Ага, вот. Носи на здоровье. Не в силах повредить их ни Дюрандаль, ни Эскалибур, ни любой меч на свете!
В ближайшей же стычке рыцарь был пробит насквозь копьём…

Когда-то давно мне объясняли, что у каждого человека существуют понятийные метаполя. Разговор двух людей в одном понятийном поле позволяет понимать друг друга “с полуслова”.

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

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

Классическим решением обоих проблем является “толмач”. Который, не только переводит с русского на английский фразу: “Мой папа секретарь обкома”, - но и трансформирует ее с учетом другого культурного контекста: “Данный проект имеет огромные шансы на успех, поскольку на него будут выделены все необходимые административные, материальные и людские ресурсы”. Или, если хотите “У него шило в …” трансформирует в фразу “Он занимает активную жизненную позицию”

Точно так же этот человек переводит фразу разработчика “Там это захардкожено в пяти десятках мест”, - в: “Наша система не отвечает требованиям качества по такому показателю, как расширяемость и поэтому выполнение вашей пустяковой заявки потребует 1500$ при допустимом риске пропущенных ошибок, которые обойдутся нам еще в 4000$ на пострелизной поддержке. Итого, это изменение встанет нам в 5500 плюс-минус 1500″.

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

PS. Официант должен свободно ориентироваться в понятийном поле клиента. И автоматически должен трансформировать фразу “Гребешков мне! И побольше.” в то, что клиент хочет на самом деле. Иначе он плохой официант. Ну, вы их регулярно наблюдаете в естественно среде обитания.

PSS. “У вещей есть понятия, не требующие объяснений, по-умолчанию.” - это утопия. Я хотел бы побывать на таком глобусе. В этой стране мои совершенно недвусмысленные заказы исполнитель не понимает. И чаще мне приходится переходить на язык исполнителя, нежели наоборот.

На самом деле, статья покрывает сразу 2 понятия: “необходимость точно формулировать мысли” и “нахождение общего языка”, но от этого не стает менее интересной

авто статьи

Связанные записи

• Нет связанных записей.

Банальные команды вида cd, dir и так далее пропустим, рассмотрим наиболее популярные и часто используемые:
“ping” - командой проверяем, есть ли удаленный хост в сети. Бывают случаи, когда firewall режет icmp пакеты, и тогда можно использовать утилиту telnet.

“telnet” - утилита позволяет управлять удаленным хостом, на котором выполняется telnet сервер либо для проверки сервисов на разных портах. Например, чтобы проверить, есть ли на удаленном хосте web сервер запускаем “telnet <хост> 80“. Подобным образом можно проверить наиболее популярные сервисы: POP3(110), SMTP(25), SSH(22), FTP(21) и так далее…
“ipconfig” - показывает сетевую конфигурацию. В основном использую для обновления сетевых настроек “ipconfig /release” для сброса настроек всех сетевых интерфейсов и “ipconfig /renew” для получения настроек. MAC адрес можно получить либо набрав “ipconfig /all” либо командой “getmac”

“net use” - команда отображает ваши соединения к удаленным хостам

“net use * /delete” - эта команда используется когда, например, вы зашли на удаленный хост под одним именем(локальным или доменным) но по какой-то причине вам надо зайти на тот же хост, но уже под другим именем.
“net share” - команда показывает какие ресурсы отданы в общий доступ. Если добавить ключ “/delete” то можно удалить ресурсы из общего доступа за исключением системных C$, D$, …
“tracert” - проследить путь маршрута от локального хоста до удаленного.
“nslookup” - используется когда необходимо получить ip адрес по доменному имени.
“route” - команда работает с таблицей маршрутизации

“shutdown” - утилита позволяет выключить или перезагрузить хост

Интересные, но не такие известные команды:
tree - строит в консоли дерево каталогов
taskkill - позволяет убить процессы или дерево процессов по фильтрам
tasklist показывает список процессов
systeminfo - выводит суммарную информацию по хосту
sfc - полезная команда - сканирует важные системные файлы на изменения и в случае изменений подменяет на оригинальные, которые были в установке Windows
netstat - показывает сетевые подключения
bootcfg - показывает содержимое boot.ini
at - утилита для запуска команд по расписанию

Связанные записи

• Нет связанных записей.

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

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

1. Всегда сообщайте о теме совещания заранее. Мозг любит формировать связи и находить закономерности. Заранее давая ему пищу для размышлений, вы позволяете связать проблему с уже известными схемами и предложить новые идеи.
2. Обеспечьте четкую структуру совещания. Мозг предпочитает располагать вещи в определенном порядке.
3. Хвалите людей. Похвала повышает самооценку человека и создает атмосферу, способствующую генерации новых идей. Полезно поддерживать соотношение похвалы и критики в пропорции 4:1.
4. Потратьте время на приведение участников совещания в должное эмоциональное состояние. В условиях стресса мозг работает только на примитивном уровне, необходимом для выживания организма. Если мы не добились состояния спокойной сосредоточенности, то эффективность нашей работы будет невелика.
5. Делите обсуждаемую тему на более мелкие вопросы. Наш мозг работает лучше, когда получает возможность сосредоточиться на конкретных элементах. Подобная разбивка также улучшает запоминание.
6. Используйте юмор. При смехе наш мозг вырабатывает нейротрансмиттеры, которые усиливают внимание и память.
7. Используйте такую форму, как диалог. Наш мозг нуждается в обратной связи, непосредственным и постоянным источником которой служит именно диалог. Если вы что-то сказали человеку во время совещания, это вовсе не означает, что ваши слова оказали желаемое воздействие.
8. Делайте выводы и устанавливайте связь с предыдущими и последующими совещаниями. Стремление мозга устанавливать связи и его способность отбирать главное говорят о том, что полезно предлагать идеи, над которыми можно работать после окончания совещания. С точки зрения запоминания схемы могут оказаться предпочтительнее традиционных записей.
9. Наблюдайте за степенью концентрации людей. Время концентрации у всех различно, но регулярные перерывы позволят обеспечить мозг кровью, богатой кислородом и питательными веществами. Тем не менее увлеченное обсуждение иногда лучше не прерывать.
10. Потратьте время на осмысление того, какие из приемов сработали, а какие нет. Еще один важный и часто игнорируемый элемент обратной связи заключается в обсуждении прошедшего совещания и планировании изменений для исправления ошибок.

Желаю Вам проводить совещания, связанные исключительно с положительными событиями и переменами, и всегда быть на высоте в этом нелегком ремесле!

Автор

Связанные записи

• Нет связанных записей.

Как проводить собеседование на тестировщика соискателя, который еще не имеет опыта тестирования?

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

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

Для начала, советую прочитать статью “Теоретик или практик” - это поможет определится с тем, на что делать упор во время собеседования. Как и в тестировании, интересней и полезней находить “пробелы в знаниях”, нежели прийти к выводу, что соискатель всё знает. И потому теоретиков мы спрашиваем практические решения, практиков - спрашиваем теорию.

Определение кругозора соискателя.
Спрашиваем по несколько простых и по несколько сложных вопросов по разным областям: операционные системы(Windows, *nix), сети, программирование, БД, технологии, веб.

Затем определяем его знания в области, которая необходима для проекта.
Тут все ясно
Пример: мой проект завязан на SNMP, сетях, вебе и разных операционных системах. От этого и пляшем.

Далее, в соответствии с требованиями к тестировщикам, проверяем остальные качества.

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

Решительность и уверенность. Задаем вопрос, на который соискатель дает правильный ответ и начинаем его переспрашивать, уверен ли он в ответе. Часто бывает, что человек, вначале абсолютно уверенный в ответе начинает жутко сомневаться и менять свой ответ. Чем это чревато? Тем, что в критической ситуации, человек может растеряться и выдать неверный ответ под стрессом.

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

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

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

Связанные записи

• Требования к тестировщикам
• Плохой и хороший тестировщик
• Авторы

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

Хорошие технические знания. Компьютер не должен быть иконой, это должен быть инструмент для выполнения работы.
Внимательность. Важно замечать лююбое поведение тестируемого продукта и делать выводы о наличии дефектов.
Решительность и уверенность. Без этих качеств, трудно отстоять свою точку зрения. В итоге много времени(и своего и чужого) будет тратится чтобы решится на submit дефекта или написание письма руководителю.
Инициатива. Без этого качества у нас будет отряд хороших роботов, способных хорошо(допустим) выполнять только те задачи, которые мы перед ними ставим.
Стрессоустойчивость. Накануне релиза, все начинают очень быстро шевелится и часто нервозность приводит к неадватным постановкам заданий, напряженному общению, потери внимательности и так далее.
Умение работать в коллективе. Очень важная характеристика потому как вся работа строится на взаимоотношениях с коллегами.
Умение логически мыслить. Здесь все ясно.

Связанные записи

• Собеседование для соискателя в QA
• Плохой и хороший тестировщик
• Авторы

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

Сама статья без изменений:

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

Так уж повелось, что собеседование у нас было построено на 4-ех уровневой основе. То есть проводили его 4 человека по очереди, у каждого были свои вопросы на свои темы, были свои тестовые задания ну и свой стиль, такой как “плохой и хороший полицейский”… шутка…

Ну а теперь ближе к телу. Была определенная группа соискателей, причем выделенная не только мной, но и моими коллегами, - это выходцы из Беларуси. Что в ней было особенного? А вот пример, конечно не 100% из жизни, но аналогию сразу можно будет провести:
- Что такое тестированием производительности?
- не знаю
- Ну может быть вы писали какие-нибудь скрипты на Лодранере, уж очень нам нужен такой специалист?
- ах вы про это… Ну конечно писал скрипты и гонял их.

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

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

Как можно брать на работу руководителя тестеровщиков, который никогда не писал тест кейсы или баг репорты? - я вот тоже не знаю…

В результате, вы познакомились с 2-мя категориями работников: практиками и теоретиками.

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

Связанные записи

• Отличия между QA и QC
• Авторы
• FAQ по QA

Simtec HttpWatch - интегрируется в Internet Explorer, предназначен для анализа загружаемых веб страниц. Показывает детали запросов по HTTP протоколу в том числе и посланных по SSL каналам, что позволяет вам точно определить расположение на удаленном сервере файлов, просмотреть содержимое cookies, headers и кода страниц. Также, в отличии от других программ подобного рода, он может показывать детали запросов сделанных с использованием каналов SSL (для тех сайтов, у которых адрес начинается с https).

HttpWatch интегрируется в Internet Explorer как панель, которая позволяет вам просматривать активность во время просмотра сайтов в интернете или в локальной сети:
Полученная информаци включает:

1. URL к которому было создано соединение.
2. HTTP метод: GET, POST, прочее…
3. Mime тип ответа, например, “text/html” или “image/gif”.
4. Время, затраченное для завершения запроса.
5. Размер загруженной страницы, изображения или файла.
6. HTTP код возврата.
7. Cookies которые были посланы или приняты.
8. HTTP заголовки, которые были приняты или отправлены.
9. Параметры, которые были отосланы в строках запросов или в методе POST.
10. Можно увижеть был ли контент загружен с HTTP сервера или из кеша браузера.

Требования: Windows 2000, XP, 2003 Server или Windows Vista с Internet Explorer 6 или 7.

Применение.

1. Анализ страниц веб-приложения на скорость загрузки - снифер прекрасно покажет самые “тяжелые” компоненты страницы
2. Анализ response кодов: можно серфить по сайту, выполняя обычное тестирование, а потом проанализировать логи снифера на предмет 404, 301, 302 и так далее response кодов
3. Можно смотреть путь, откуда тянутся картинки во флешевых галереях ну и потом их грабить оттуда - самое корыстное примение

Связанные записи

• Что такое тестирование?