вторник, 14 декабря 2010 г.

Аттестация в жизни технического человека.

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

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

среда, 1 декабря 2010 г.

[HDI] Увеличение своп-файла Linux без изменения разделов диска

Если вдруг потребовалось увеличить swap раздел на Linux'овой машинке, а править текущее разбиение диска на разделы не хочется, то можно поступить так:

# dd if=/dev/zero of=/var/swap bs=1M count=1048
# chmod 0 /var/swap
# mkswap /var/swap
# echo "/var/swap none swap defaults 0 0" >> /etc/fstab
# swapon -a


Собственно, тут создается файл, который в дальнейшем используется как swap-раздел.
Ключевой момент тут count=1048 - этот параметр определяет, какого размера файл будет создан.

P.S. честно своровано отсюда

Статистика дефектов. Спросите "Почему?"

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

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

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

четверг, 18 ноября 2010 г.

[HDI] Поиск и очистка inodes в Linux

Как известно, каждому файлу в Linux'е соответствует не только место на диске, но и некоторое количество inode. Как и место на диске, inode'ы тоже могут заканчиваться, и результат примерно тот же - создавать новые файлы становится невозможно.

Узнать, сколько inodes уже использовано можно с помощью команды
df -i

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

С определением места, где все это добро хранится, может помочь такой вот несложный скриптик:

#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$


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

P.S. своровано отсюда: http://stackoverflow.com/questions/653096/howto-free-inode-usage

вторник, 16 ноября 2010 г.

Рунглиш. Новояз. Жаргон.

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

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

Профессиональный жаргон - дело не новое, и думаю большинство с ним сталкивалось в своей работе, а уж в сфере IT - просто все. Жаргон свойственен любой профессии; где-то его больше, где-то меньше. В IT обилие жаргона связано, на мой взгляд, прежде всего с тремя аспектами:

четверг, 11 ноября 2010 г.

[HDI] Создание ISO-файла в Linux

Создание ISO файла из CD/DVD диска

dd if=/dev/cdrom of=/cdrom_image.iso
где
  • dd == "disk dump" - утилита для побитового копирования
  • if == "input file" - устройство, откуда читать
  • of == "output file" - файл, куда писать

Создание ISO файла из папки

mkisofs -D -iso-level 4 -o ./myimage.iso ./myfolder/
где
  • -D - позволяет работать с деревьями папок глубокой вложенности
  • iso-level 4 - позволяет работать с длинными именами файлов
  • /myimage.iso  - путь к создаваемому ISO-файлу
  • ./myfolder/ - путь к папке, содержимое которой надо поместиьт в ISO-файл.

воскресенье, 7 ноября 2010 г.

Скучная работа

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

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

А что, не так, что ли?

пятница, 15 октября 2010 г.

Правильный багрепорт для всех и каждого.

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

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

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

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

четверг, 7 октября 2010 г.

Почему их так много?

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

Вот что получилось.

вторник, 25 мая 2010 г.

Почему-то не я, а он

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

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

Мысли не новые, но банальные истины не перестают быть истинами :)