как ведут себя люди в последние 2 недели на рабочем месте

Многим из нас приходилось менять места работы, многим приходилось видеть как увольняются коллеги.
Наблюдая за та тем , как это все происходит иногда поражаешься со знаком "+" , как некоторые профессионально ведут себя последние стандартные 2 недели... Никакого послабления в качестве, никакой расслабленности. Все дела закончены. Все инструкции написаны. Человек заботится о своей репутации. Ему дорого мнение остающихся на этом месте коллег и иногда даже друзей.
А иногда поражаешься со знаком "-" тому, как люди воплощают в жизнь "а после нас хоть потоп" в те же стандартные 2 недели... Бумага написана. "отрицательно стимулировать" уже точно никто не будет. Хочу работаю, хочу не работаю. Хочу опоздаю на 2 часа, хочу приду вовремя.
Одних провожают всем отделом, уход других или не замечают вовсе или встречают с облегчением.
Разные все-таки люди бывают при том, что "чемоданное настроение" посещает любого , кому скоро придется подписывать обходной лист )

Оборотни на собеседовании

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

Чтение логов в рамках тестирования безопасности

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

virtualenv в помощь

В этой статье хочу поделиться опытом того, как можно без лишней головной боли организовать тестирование web-приложения , написанного на python c различными версиями этого языка. И даже с различными версиями того или иного фреймворка (django, pylons etc)...если, конечно , фреймворк используется.
Итак , есть сервер , для определенности : на нем установлен linux.. для еще большей определенности - debian )
Любой linux - дистрибутив уже включает в себя ту или иную версию python. Допустим "из коробки" имеем python v2.5. Мы же хотим протестировать наше гипотетическое приложение на совместимость с python 2.5, 2.6 и 2.7 (на совместимость с версией 3 лучше не тестировать - под нее надо писать отдельно =), чтобы быть уверенным, что наше приложение будет работать на большинстве python-хостингов.

1. доставляем отсутствующие версии python. Для этого wget-ом, например, выкачиваем соответствующие исходники, распаковываем (tar), конфигурируем НЕ ЗАБЫВАЯ УКАЗЫВАТЬ ПРЕФИКС установки отдельно для каждой версии python, затем make и make install. В итоге получаем:
   • /usr/bin/python - дефолтный
   • /usr/python2.6/bin/python
   • /usr/python2.7/bin/python
2. теперь самое интересное - у нас три одинаковых бинаря python в трех разных местах. Если вызвать python из командной строки, то будет дернут тот, чей путь левее всего в PATH. Как быть? каждый раз руками менять PATH? мучаться с симлинками? Слава Богу нет. Нам на помощь приходит замечательная штукенция - virtualenv !

   
   sudo apt-get install virtualenv
   mkdir ~/projects/
   cd projects
   virtualenv --no-site-packages -p /usr/bin/python app_test_python2.5
   virtualenv --no-site-packages -p /usr/python2.6/bin/python app_test_python2.6
   virtualenv --no-site-packages -p /usr/python2.7/bin/python app_test_python2.7
   

   В результате мы имеем три директории - по одной для каждой версии питона. Интересное внутри этих директорий. Внутри же создается окружение - бинари, инсталляторы библиотек (pip , easy_install) - сюда же надо помещать и код тестируемого приложения, отсюда же и деплоить с локальным web-сервером (apache, nginx..)
3. еще не все. Чтобы работать в окружении , надо его активировать:

   
   cd ~projects/app_test_python2.6
   . env/bin/activate
   
   

   теперь можно не боясь вызвать python, pip, easy_install - будет вызвана именно версия 2.6, будут использованы именно библиотеки для версии 2.6 и ставиться будут они не в /usr/lib/python , а в ~projects/app_test_python2.6/lib !
   

Полная изоляция, никакой мороки и путаницы.
Таким образом, создавая для каждой тестовой конфигурации свое виртуальное окружение, мы не засираем систему хаотичными симлинками, конфликтующими версиями библиотек и т.д. и т.п. В общем сплошные плюсы.
Расписал, конечно, не все максимально детально. Но, думаю, тому , кто решить освоить эту технику организации тестовых стендов помогут гугл, здравый смысл и прямые руки )
p.s. только python к сожалению ( Пока писал стало интересно есть ли аналоги для perl, php ... )

Вы уверены , что хотите выполнить операцию?

На тему о том, как делать удобные приложения написано немало статей, howto, "стандартов" и так далее. С каждым днем все больше действительно качественно продуманных приложений, по-настоящему дружественных и "обходительных" пользовательских интерфейсов. Развиваемся. Радует.
Но иногда встречаются просто умопомрачительные косяки.
Чтобы не быть голословным приведу пример.
Многие, наверное, знают о нашумевшей криптовалюте bitcoin. Одной из ее особенностью является принципиальная невозможность отмены транзакции. Например , если вы переводите монеты с одного кошелька на другой и при этом ошибаетесь в номере целевого кошелька , то отменить перевод невозможно. Вы можете ошибиться так, что укажете реально существующий кошелек и тогда, маловероятно, но есть шанс вернуть , уговорив его владельца сделать обратный перевод (найти владельца будет посложнее чем иголку в стоге сена). Если ошибетесь так , что такого кошелька просто нет - то монеты просто исчезают.
При всем при этом описанное именно особенность, связанная с изначальными архитектурными принципами этой по-настоящему безопасной криптовалюты. Зная об этой особенности , разработчикам стоит проектировать и реализовывать интерфейсы для работы с этой валютой, а тестировщикам , соответственно, тестировать. Но так ли думают разработчики авторы guiminer ? Это питоновский фронтенд над питоновским же майнером криптовалюты. Занимается он тем, что "добывает золото" . Кроме того , есть у него кнопочка "withdraw", по нажатию на которую все наработанное улетает на некий кошелек. Нет предложения ввести адрес перевода, нет предупреждения о том, что монеты уйдут на такой-то кошелек (чтобы юзер мог сверить лишний раз), нет предупреждения о невозможности отменить транзакцию. Есть только обработка сабмита кнопки в виде списания монет с баланса ))
Сколько же новичков майнинга тут "полегло" ! )) Наиболее распространенные сценарии потери с трудом намайненных монет такие:

• пользователь недавно переставил винду и потерял свой кошелек, сгенерировал новый, а в настройки адресата переводов в учетной записи пула (например deepbit.net) новый адрес своего не внес, в итого withdraw на кошелек, который никогда нигде не увидеть больше
• пользователь отправлял биткойны в биржу , где для получения средств каждый раз генерируется новый адрес..Соответственно, при очередном переводе, забывает указать новый адрес. Результат тот же - видеокарта жгла мазут зря.

В общем..если абстрагироваться от этого печального примера, то на ответ "выводить окно подтверждения или нет" можно так:

1. если совершаемое действие может быть легко и без последствий отменено, то можно и не предупреждать
2. если совершаемое действие не может быть отменено, то предупреждать
3. если речь идет о финансах и клавиатура, которая может быть разбита, то ПРЕДУПРЕЖДАТЬ да еще и с описанием всех ньюансов)

"Сыпятся" диски - "валятся" тесты

Все мы привыкли к провалам автотестов из-за ошибок в тестируемом коде, в самих тестах , в конфигурации и т.д.
Но иногда случаются действительно редкие вещи. Как, например, сегодня в моей практике.
На одном из серверов автоматического тестирования часть тестов провалилась без видимых на то причин. Изменений, способных привести к провалам, не было ни в коде, ни в самих тестах , ни в тестовом окружении. Тесты имели длинную историю успешного прохождения - скучно даже было. И вот провалились.
После поверхностного анализа стало ясно, что не были созданы все тестовые данные - Oracle ругнулся так, что я никогда такого раньше не видел ) А точнее - не смог добавить extent в один из TABLESPACE-ов.
Смотрю в субд - инстанс в RO-режиме.
При попытке перезапустить бд получаю ошибку:

ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/u02/oradata/index01.dbf'

Пробую рекавери файла данных не помогает - из ругани Oracle становится ясно, что файловая система, где располагается том для файлов данных, находится также в RO-режиме. Сервер никто не трогал. Свет не отрубали (uptime сервака 52 дня). Лезу в /var/log/messages и вижу, что возникла проблема с ФС из-за проблемных блоков харда и ядро само перемонтировало раздел в RO-режиме. Теперь все встало на свои места. Далее лечение последствий в виде последовательных вызовов: umount, fsck, mount Ну и перезапуск oracle. В общем, мораль , железо тоже не выдерживает иногда :)