А все-таки чертовски большой скачок совершило "тестирование" за последние лет 5-10.
Еще несколько лет назад в нашей стране "тестеры" и "тестировщики" были , чего греха таить, чуть ли не людьми второго сорта в ИТ. И это было порой заслуженно, хотя чаще - несправедливо...
Да и не было по большому счету такой ПРОФЕССИИ - "тестировщик". Этому не учили толком в наших ВУЗах, за это не давали сертификатов, и в конечном итоге за это платили смешные деньги. Такое положение дел было естественным для нашей страны, на годы отстающей от информационно-технологичного запада, сего Канером. Редко кто из кампаний-разработчиков софта выдвигал повышенные требования к качествую своих продуктов... хотя бы потому что не было таких требований со стороны рынка... Да, были такие "гиганты" типа CBOSS ( это не реклама :), которые с самого начала возвели качество во главу угла и где тестирование было организовано на отличном уровне даже много лет назад.. но это были исключения.
Но и у таких "белых ворон" рынка программного обеспечения в тестировании зачастую были люди случайные: студенты, подработчики, технари в возрасте , пытающиеся хоть как-то встроиться в набирающие обороты ИТ..., текучка , соответственно, была бешенная. Очень многие уходили в разработчики и такие, кстати, очень часто потом затмевали "штатных" разрабов... уходили и в другие сферы - смежные и не очень...
Кто остался?
Кто-то остался в профессии из-за малодушия, кто-то из-за понимания перспектив и настоящего призвания к этому делу, кто-то остался , найдя для себя приемлемые компромиссы и горизонты развития в тестировании...
Но какими бы ни были причины, думаю, из "оставшихся" сейчас мало кто жалеет о своем выборе - неплохие зарплаты , интересные и масштабные задачи, признание , большой спрос на рынке , сертификации, конференции... и самое интересное то, что это лишь только начало :)
Еще что хотелось бы отметить... В след за эволюцией профессии тестировщика эволюционировало и мышление многих разработчиков.. по крайней мере , по моим суъбективным наблюдениям. Если раньше у разрабов были нередки пренебрежительные настроения типа "как вы меня задолбали своими багами, не даете делом заниматься!", то теперь все чаще и больше слышно и видно конструктивного на подобие "ребята, прогоните пожалуйста, свои автотесты"...
четверг, 31 января 2013 г.
воскресенье, 16 декабря 2012 г.
Специфика использования open-source проектов
Как принято считать, стоимость исправления дефектов в ПО тем ниже, чем раньше стадия, на которой этот дефект был выявлен.Эта теорема не раз доказана практикой тысяч конкретных программных проектов. Тестирование идей и требований пока еще звучит как экзотика. Но стимуляция разработчиков к более тщательному выходному контролю кода уже стала нормой.
Программисты клепают unit-тесты ( и теперь уже кто-то даже до написания логики ), многие обзаводятся своими собственными тестовыми стендами, и даже прогоняют на них основные по их мнению варианты. Этому нельзя ни радоваться и это нельзя не приветствовать. Но мышление разработчика остается мышлением разработчика. О многих вариантах использования, вариациях входных данных ему думать не досуг. И это правильно.
Там, где за разработчиками стоят грамотные тестировщики, можно не беспокоиться - они позаботятся о проверке всех нужных вариантов, в том числе и довольно редких, но все-таки нужных.
Но не все программные проекты подвергаются экзекуции тестировщиками, не все проекты проходят стадию "тестирования" перед выпуском в свет.. Особенно это касается многих open-source решений. Среди них много таких, которые кроме unit-тестирования никакого более тестирования не проходят. Баги ловят реальные пользователи, кто-то постит их в открытые багтреккеры и, если проект продолжает поддерживаться, он постепенно становится лучше. Бывает так, что баг висит годами без фиксов и пользователям этого открытого софта, библиотеки приходится патчить самим. Все бы ничего, схема работает. Да здравствует open source и GPL в руки! Но когда речь идет о создании коммерческого софта с использованием открытых библиотек, то не все удосуживаются анализировать используемый сторонний (3rd party) софт на наличие ошибок. Вот и вылезают потом неожиданности в виде багов, которые непонятно кому исправлять - то ли ждать фиксов от авторов сторонней софтины, то ли самим патчить. Если самим , то как это сделать так, чтобы не сломать - а для этого надо разобораться с внутренней архитектурой стороннего решения...
В общем, не так гладко может все сложиться. А ведь даже поверхностный анализ баг-треккера той или ной открытой либы может помочь понять , стоит ее использовать в коммерческой разработке или нет.
Одно ясно точно - использовать open-source разработки в коммерческих проектах надо обязательно ( чтобы не изобретать велосипедов) , но чтобы потом не переписывать половину кода, из-за того, что "либа оказалась Г..", все сторонние решения надо тщательно анализировать.
Но не все программные проекты подвергаются экзекуции тестировщиками, не все проекты проходят стадию "тестирования" перед выпуском в свет.. Особенно это касается многих open-source решений. Среди них много таких, которые кроме unit-тестирования никакого более тестирования не проходят. Баги ловят реальные пользователи, кто-то постит их в открытые багтреккеры и, если проект продолжает поддерживаться, он постепенно становится лучше. Бывает так, что баг висит годами без фиксов и пользователям этого открытого софта, библиотеки приходится патчить самим. Все бы ничего, схема работает. Да здравствует open source и GPL в руки! Но когда речь идет о создании коммерческого софта с использованием открытых библиотек, то не все удосуживаются анализировать используемый сторонний (3rd party) софт на наличие ошибок. Вот и вылезают потом неожиданности в виде багов, которые непонятно кому исправлять - то ли ждать фиксов от авторов сторонней софтины, то ли самим патчить. Если самим , то как это сделать так, чтобы не сломать - а для этого надо разобораться с внутренней архитектурой стороннего решения...
В общем, не так гладко может все сложиться. А ведь даже поверхностный анализ баг-треккера той или ной открытой либы может помочь понять , стоит ее использовать в коммерческой разработке или нет.
- Покрыта ли библиотека unit-тестами, если да , то на сколько ?
- Проходят ли unit-тесты в окружении, в котором планируется использовать будущий коммерческий софт?
- Даже если внешне все гладко, то не стоит ли поручить тестировщикам помучать с помошью заглушек эту библиотеку и дать свою экспертную оценку о ее качестве?
Одно ясно точно - использовать open-source разработки в коммерческих проектах надо обязательно ( чтобы не изобретать велосипедов) , но чтобы потом не переписывать половину кода, из-за того, что "либа оказалась Г..", все сторонние решения надо тщательно анализировать.
вторник, 11 декабря 2012 г.
+27 к жизни
Помните песню Сюткина "ежедневно 42 минуты под землей", где он складывал в года время, потраченное на езду в метро?
Песня - песней, а для многих жителей мегаполиса и окружающих его окраин - это большая проблема... Например, я до недавнего времени тратил час - полтора на дорогу только в одну сторону. Было много причин, для того, чтобы мириться с этим положением дел. Было много компромиссов в виде аудиокниг (если в машине), читалок с полезным контентом (если на общ.тренспорте), прослушанных курсов английского и так далее...
Но простая арифметика показывала , что в год набегало что-то около 27 дней только на стояние в пробках, у которых пока не видно тенденции к уменьшению.. И когда я просто физически перестал успевать делать многие важные вещи, когда терпение лопнуло и здравый смысл перевесил все эмоции, то я перебрался поближе к основному месту работы. Какая красота - 15 минут от двери до двери!
Теперь в моем распоряжении совсем не лишних ~27 дней в году, которые можно как минимум потратить на хороший отдых )
Вот такой вот тайм-менеджмент...
вторник, 13 ноября 2012 г.
Загружаем большие объемы данных в oracle
При создании адекватных тестовых данных принято использовать интерфейсы самого приложения, его api, формы, библиотеки и т.д... Но когда необходимо создавать большие массивы тестовых данных, стандартные интерфейсы могут оказаться черезчур медлительными.
Например , вы хотите заполнить биллинговую БД десятью миллионами клиентов, которые тянут за собой другие десятки миллионов сопутствующих записей в разных таблицах схемы (речь в данном посте идет именно о реляционных субд).
Каждая реляционная субд имеет свои механизмы дампа, заливки, импорта , экспорта... Даже простецкий sqlite имеет свой .dump.
Я бы хотел поделиться некоторыми аспектами создания больших объемов тестовых данных в субд Oracle.
Существует несколько вариантов:
Самый неудачный вариант - с наскока написать скрипт, который бы генерировал данные с помощью обычного DML. Подобное решение будет работать долго и потреблять слишком много ресурсов субд, связанных с ведением redo-логов, распуханием сегмента отката, фиксацией изменений (commit).
Другой вариант - использовать штатные оракловые утилиты бекапа и восстановления : imp , exp , которые очень шустро работают. Но этот вариант применим в ситуации, когда у вас уже имеется эталонная схема с нужным количеством данных - вы просто экспортируете (в бинарный файл) из нее все или часть данных и импортируете в нужную схему из полученного бинарного дампа. Например, таким образом, можно слить данные с боевой БД заказчика, разумеется, если он дает на это добро. К тому же использовать этот метод рекомендуется для работы с БД до 50 - 60 GB.
Ну и наиболее подходящий вариант - использование SQL*Loader.
Метод относительно быстр , гибок в настройке хоть и имеет свои особенности. Загрузка осуществляется оракловой утилитой sqlldr.
Ей на вход необходимо передать обязательно: управляющий файл и файл с данными, и необязательно - файл пераметров.
Управляющий файл - это текстовый файл, который формируется загружающим вручную и содержит спецификацию того, откуда брать входные данные, каков их формат, параметры конфигурации загрузки, правила изменения данных при загрузке... Максимально детально о формате управляющего файла можно ознакомиться в официальной доке.
Файл с данными - файл, сформированный внешней программой/скриптом и который содержит данные, которые надо загрузить. Формат файла может быть как текстовый так и бинарный. Как именно интерпретировать записи этого файла - указывается в управляющем файле. Если файл текстовый, то разделители записей, признаки конца записи (для мультистрочных записей) - все это также регулируется в управляющем файле.
Файл с параметрами - текстовый файл , в котором указываются параметры командной строки. Например sqlldr PARFILE=parameters.par
Что же делает imp , sqlldr быстрыми? В первую очередь то, что они умеют использовать такую возможность Oracle, как метод "прямой вставки".
Прямая вставка - это почти тот же insert, который быстрее обычного за счет того , что при его использовании не тратится время на коммиты, redo-логи, большинство ограничений (кроме unique, primary key и not null) и insert-триггеры.
Чтобы sqlldr использовал метод прямой вставки, ему необходимо передать в командной строке или файле параметров опцию DIRECT=Y.
Кроме того, прямую вставку можно еще и распараллелить.
К слову, такой метод вставки можно использовать и самостоятельно.
Вот пример параллельного (в 2 процесса) и нежурналируемого копирования данных из одной таблицы в другую.
Наибольший выигрыш от распараллеливания загрузки достигается на тех серверах, где более одного CPU.
Ну и напоследок несколько советов о том, как сделать процесс загрузки более оптимальным:
1. подготовьте место да диске, где будут лежать dbf-ы новой базы, достаточное для будущего объема данных (посмотрите сколько занимают dbf-ы старой =)
2. отключите индексы в таблицах , которые собираетесь заполнять
3. используйте прямую и по возможности параллельную вставку
4. отключите архиватор, если включен (напарывался на ситуацию, когда архиватор отжирал место почти равное тому, что занимала новая база - это совершенно ненужное при генерации тестовых данных архивирование!):
Если же архиватор все таки не был отключен и отожрал место на диске архивными dbf-ами, то их можно легко удалить.
Для этого в папке с архивными dbf-ами удалить все ненужные архивы и после этого с помощью rman избавиться от соответствующих записей в БД:
Хорошую подборка проверенных советов по оптимизации именно SQL*Loader можно найти здесь
На полноту охвата темы не претендую, но , надеюсь, у того кто с описанными вкратце механизмами не знаком , появится вектор, куда копать в случае необходимости :)
Например , вы хотите заполнить биллинговую БД десятью миллионами клиентов, которые тянут за собой другие десятки миллионов сопутствующих записей в разных таблицах схемы (речь в данном посте идет именно о реляционных субд).
Каждая реляционная субд имеет свои механизмы дампа, заливки, импорта , экспорта... Даже простецкий sqlite имеет свой .dump.
Я бы хотел поделиться некоторыми аспектами создания больших объемов тестовых данных в субд Oracle.
Существует несколько вариантов:
Самый неудачный вариант - с наскока написать скрипт, который бы генерировал данные с помощью обычного DML. Подобное решение будет работать долго и потреблять слишком много ресурсов субд, связанных с ведением redo-логов, распуханием сегмента отката, фиксацией изменений (commit).
Другой вариант - использовать штатные оракловые утилиты бекапа и восстановления : imp , exp , которые очень шустро работают. Но этот вариант применим в ситуации, когда у вас уже имеется эталонная схема с нужным количеством данных - вы просто экспортируете (в бинарный файл) из нее все или часть данных и импортируете в нужную схему из полученного бинарного дампа. Например, таким образом, можно слить данные с боевой БД заказчика, разумеется, если он дает на это добро. К тому же использовать этот метод рекомендуется для работы с БД до 50 - 60 GB.
Ну и наиболее подходящий вариант - использование SQL*Loader.
Метод относительно быстр , гибок в настройке хоть и имеет свои особенности. Загрузка осуществляется оракловой утилитой sqlldr.
Ей на вход необходимо передать обязательно: управляющий файл и файл с данными, и необязательно - файл пераметров.
Управляющий файл - это текстовый файл, который формируется загружающим вручную и содержит спецификацию того, откуда брать входные данные, каков их формат, параметры конфигурации загрузки, правила изменения данных при загрузке... Максимально детально о формате управляющего файла можно ознакомиться в официальной доке.
Файл с данными - файл, сформированный внешней программой/скриптом и который содержит данные, которые надо загрузить. Формат файла может быть как текстовый так и бинарный. Как именно интерпретировать записи этого файла - указывается в управляющем файле. Если файл текстовый, то разделители записей, признаки конца записи (для мультистрочных записей) - все это также регулируется в управляющем файле.
Файл с параметрами - текстовый файл , в котором указываются параметры командной строки. Например sqlldr PARFILE=parameters.par
Что же делает imp , sqlldr быстрыми? В первую очередь то, что они умеют использовать такую возможность Oracle, как метод "прямой вставки".
Прямая вставка - это почти тот же insert, который быстрее обычного за счет того , что при его использовании не тратится время на коммиты, redo-логи, большинство ограничений (кроме unique, primary key и not null) и insert-триггеры.
Чтобы sqlldr использовал метод прямой вставки, ему необходимо передать в командной строке или файле параметров опцию DIRECT=Y.
Кроме того, прямую вставку можно еще и распараллелить.
К слову, такой метод вставки можно использовать и самостоятельно.
Вот пример параллельного (в 2 процесса) и нежурналируемого копирования данных из одной таблицы в другую.
ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+parallel(new_users,2)*/ INTO users NOLOGGING
SELECT * FROM old_usersНаибольший выигрыш от распараллеливания загрузки достигается на тех серверах, где более одного CPU.
Ну и напоследок несколько советов о том, как сделать процесс загрузки более оптимальным:
1. подготовьте место да диске, где будут лежать dbf-ы новой базы, достаточное для будущего объема данных (посмотрите сколько занимают dbf-ы старой =)
2. отключите индексы в таблицах , которые собираетесь заполнять
3. используйте прямую и по возможности параллельную вставку
4. отключите архиватор, если включен (напарывался на ситуацию, когда архиватор отжирал место почти равное тому, что занимала новая база - это совершенно ненужное при генерации тестовых данных архивирование!):
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE NOARCHIVELOG;
ALTER DATABASE OPEN;
Если же архиватор все таки не был отключен и отожрал место на диске архивными dbf-ами, то их можно легко удалить.
Для этого в папке с архивными dbf-ами удалить все ненужные архивы и после этого с помощью rman избавиться от соответствующих записей в БД:
rman target sys@dbsid crosscheck archivelog all;delete noprompt expired archivelog all;
Хорошую подборка проверенных советов по оптимизации именно SQL*Loader можно найти здесь
На полноту охвата темы не претендую, но , надеюсь, у того кто с описанными вкратце механизмами не знаком , появится вектор, куда копать в случае необходимости :)
четверг, 1 ноября 2012 г.
Практичный WWW::Mechanize
Так сложилось, что мне частенько приходится пользоваться различными виртуальными хостингами.
С недавнего времени среди тех, которыми я часто пользуюсь появился такой хостер, который разрешает подключаться к серверу по SSH только с одного IP.
При этом , конечно же, позволяет указывать разрешенный IP в хостинг-панели.
В целом, штука конечно-же, секьюрная , но немного неудобная.
Теперь мы все стали мобильные, наши IP-ы часто меняются - дома один, в дороге или кафе - другой, в офисе - третий.
Один раз залезешь - переключишь, другой, а на третий уже автоматизируешь.
Так поступил и я... В голове сразу мелькнули мысли от трех вариантах - Selenium, Jmeter и гипотетический perl-скрипт с использованием WWW::Mechanize.
По ряду причин решил использоватьвторой третий вариант...
Для этого нужно:
ok 7 - Get current ip from page
ok 8 - Submit ip changing form
1..8
Ну и этот "тест" потестить тоже надо бы.. Убеждаемся, что до запуска ssh-соединение не устанавливаетса, а после запуска - проблем нет.
Таким образом, скрипт реально экономит мне время и нервы, позволяя одним кликом разрешить текущий ip-с которым я вышел в сеть - не надо открывать браузер, панель, помнить и вводить логин , пароль (очень хитрый и длинный пароль)...
Разумеется, это подходит только для данного конкретного хостера и его алгоритма смены разрешенного ip ) И, конечно же, хостер может изменить названия переменных, ссылок, вообще поменять логику - это не проблема, скорректировать скрипт дело пары минут :)
Не а ежели хостер навесит капчу, то будет очень интересно решить эту задачу, тем более, что кое-какие наработки где-то в дебрях харда валялись )
p.s. в целом WWW::Mechanize очень даже применим для автоматизации сценариев , а его обертка Test::WWW::Mechanize - даже для создания функциональных автотестов.
С недавнего времени среди тех, которыми я часто пользуюсь появился такой хостер, который разрешает подключаться к серверу по SSH только с одного IP.
При этом , конечно же, позволяет указывать разрешенный IP в хостинг-панели.
В целом, штука конечно-же, секьюрная , но немного неудобная.
Теперь мы все стали мобильные, наши IP-ы часто меняются - дома один, в дороге или кафе - другой, в офисе - третий.
Один раз залезешь - переключишь, другой, а на третий уже автоматизируешь.
Так поступил и я... В голове сразу мелькнули мысли от трех вариантах - Selenium, Jmeter и гипотетический perl-скрипт с использованием WWW::Mechanize.
По ряду причин решил использовать
Для этого нужно:
- perl c установленным WWW::Mechanize, а лучше и Test::WWW::Mechanize
- Firefox с включенным плагином MozRepl ( ТОЛЬКО ЕСЛИ ЗАХОТИТЕ СНИМАТЬ СКРИНШОТЫ!)
- Пара минут времени
#!/usr/bin/perl -w
use utf8; use Test::More "no_plan"; use Test::WWW::Mechanize; use constant URL => 'нужный урл'; use constant LOGIN =>; 'логин к админ панели'; use constant PASSWORD =>; 'пароль к админ панели';
my $m = Test::WWW::Mechanize->new(autolint=>0); $m->get_ok( URL , 'Open login page'); $m->content_contains( 'Контрольная панель' , 'Check we are on right page'); $m->submit_form_ok({ form_number =>; 1, fields => { login => LOGIN, password => PASSWORD, }, }
, 'Submit login form'
); $m->follow_link_ok( { text_regex => qr/Настройки SSH/i } , 'Follow ssh settings link'); $m->content_contains( 'Настройки SSH' , "Check we are on right page");
$m-$gt;follow_link_ok( {id =>; 'user-ip' }, "Allow
current ip"); my $link =$m->find_link( id => 'user-ip' );
ok($link, 'Get current ip from page'); $m->submit_form_ok({
form_number => 1,
fields => {
ip => $link->text,
},
}
, 'Submit ip changing form'
);
$ ./ssh_switcher ok 1 - Open login page ok 2 - Check we are on right page ok 3 - Submit login form ok 4 - Follow ssh settings link ok 5 - Check we are on right page ok 6 - Allow current ip ok 7 - Get current ip from page
ok 8 - Submit ip changing form
1..8
Таким образом, скрипт реально экономит мне время и нервы, позволяя одним кликом разрешить текущий ip-с которым я вышел в сеть - не надо открывать браузер, панель, помнить и вводить логин , пароль (очень хитрый и длинный пароль)...
Разумеется, это подходит только для данного конкретного хостера и его алгоритма смены разрешенного ip ) И, конечно же, хостер может изменить названия переменных, ссылок, вообще поменять логику - это не проблема, скорректировать скрипт дело пары минут :)
Не а ежели хостер навесит капчу, то будет очень интересно решить эту задачу, тем более, что кое-какие наработки где-то в дебрях харда валялись )
p.s. в целом WWW::Mechanize очень даже применим для автоматизации сценариев , а его обертка Test::WWW::Mechanize - даже для создания функциональных автотестов.
вторник, 16 октября 2012 г.
Монтируем yandex disk
Одним из преимуществ использования этого "еще одного облачного хранилища" в том, что его можно примонтировать с помощью davfs2 (WebDAV Linux File System) ( как локальный диск без особых трудностей. Разумеется , речь идет о linux.
Перед началом опыта надо , разумеется, зарегистрировать (если еще такого нет) аккаунт у "Яндекса".
Пример для debian или debian-подобного дистрибутива:
$ mkdir /home/linuxuser/yandex #создаем у себя в хомяке директорию для содержимого "диска" $ sudo apt-get install davfs2 $ sudo mount -t davfs https://webdav.yandex.ru /home/linuxuser/yandex/
Будет запрос ввода логина и пароля к учетной записи на "яндексе" - вводим )
Чтобы избежать ввода при каждом монтировании можно добавить данные учетной записи в /etc/davfs2/secrets
$ sudo /vim/etc/davfs2/secrets #в конец файла добавляем строку https://webdav.yandex.ru "логин" "пароль", подставляя свой логин и пароль
Проверяем содержимое директории с диском
$ ls -l /home/linuxuser/yandex drwx------ 2 root root 0 Окт 16 08:16 lost+found -rw-r--r-- 1 root root 455833 Окт 4 18:44 Добро Пожаловать.pdf drwxr-xr-x 2 root root 0 Окт 4 18:44 Документы drwxr-xr-x 2 root root 0 Окт 4 18:44 Музыка -rw-r--r-- 1 root root 937311 Окт 4 18:44 Обои для рабочего стола.jpg Чтобы дать возможность пользователю linuxuser пользоваться всеми благами примонтированного "диска" делаем следующее:
$ sudo vim /etc/fstab
Прописываем строку:
https://webdav.yandex.ru /home/linuxuser/yandex davfs uid=linuxuser,file_mode=640,dir_mode=755,user,noauto 0 0 $ sudo usermod -a -G davfs2 linuxuser
$ sudo chmod 4755 /usr/sbin/mount.davfs
Теперь проверяем , что все ок от имени пользователя
$ umount /home/linuxuser/yandex $ mount /home/linuxuser/yandex $ ls -l /home/linuxuser/yandex drwx------ 2 linuxuser linuxuser 0 Окт 16 08:25 lost+found -rw-r----- 1 linuxuser linuxuser 455833 Окт 4 18:44 Добро Пожаловать.pdf drwxr-xr-x 2 linuxuser linuxuser 0 Окт 4 18:44 Документы drwxr-xr-x 2 linuxuser linuxuser 0 Окт 4 18:44 Музыка -rw-r----- 1 linuxuser linuxuser 937311 Окт 4 18:44 Обои для рабочего стола.jpg Ссылки:
WebDAV file system project
Yandex Disk
понедельник, 15 октября 2012 г.
blogger.com обнулена статистика просмотров ?
Сегодня с удивлением обнаружил обнуление статистики просмотра страниц блога у blogger.com.
Проблема , видимо, касается если не всех blogger.com-пользователей, то многих (первая реакция blogger.com).
Не смертельно, конечно, но неприятно.
Надеюсь, починят.
Проблема , видимо, касается если не всех blogger.com-пользователей, то многих (первая реакция blogger.com).
Не смертельно, конечно, но неприятно.
Надеюсь, починят.
четверг, 4 октября 2012 г.
среда, 3 октября 2012 г.
Когда теория расходится с практикой
Многим из нас , наверняка, приходилось переживать волну энтузиазма, вызванного очередной прочитанной ИТ-книгой, очередной изученной методологией, которая после осмысления удивительно удачно разрешила бы текущие производственные проблемы, вопросы, недопонимание.
Воображение строит план, перспективы применения новых знаний заманчивы.. В теории красиво и ладно. Сплошной позитив. И вот ты весь такой позитивный и вооруженный погружаешься опять в производственную текучку. А ее участникам порой нет дела то книг, которые ты прочел, навыков , которые ты прокачал, обдуманных лучших практик, которые действительно оказали бы полезны в данном конкретном процессе... Инцерция. Твоя теория сталкивается с твоей же практикой. И очень важно , столкнувшись с ней, не сбиться в критиканство, не конфликтовать с людьми и беречь свой энтузиазм, стараясь конструктивно влиять на процесс. Стоит понимать, что люди годами работают по накатанным рельсам и даже , порой понимая, что рельсы эти устарели , не могут или не хотят (а иногда и не имеют права) что-либо менять.
Ну и всегда остается шанс того, что ты , впадая в эйфорию от новых знаний и жажды их применения, чего-то такого не учел, что делает в данном конкретном случае старые ржавые рельсы гораздо привлекательнее , чем все такие раскрасивые новые...
Воображение строит план, перспективы применения новых знаний заманчивы.. В теории красиво и ладно. Сплошной позитив. И вот ты весь такой позитивный и вооруженный погружаешься опять в производственную текучку. А ее участникам порой нет дела то книг, которые ты прочел, навыков , которые ты прокачал, обдуманных лучших практик, которые действительно оказали бы полезны в данном конкретном процессе... Инцерция. Твоя теория сталкивается с твоей же практикой. И очень важно , столкнувшись с ней, не сбиться в критиканство, не конфликтовать с людьми и беречь свой энтузиазм, стараясь конструктивно влиять на процесс. Стоит понимать, что люди годами работают по накатанным рельсам и даже , порой понимая, что рельсы эти устарели , не могут или не хотят (а иногда и не имеют права) что-либо менять.
Ну и всегда остается шанс того, что ты , впадая в эйфорию от новых знаний и жажды их применения, чего-то такого не учел, что делает в данном конкретном случае старые ржавые рельсы гораздо привлекательнее , чем все такие раскрасивые новые...
вторник, 2 октября 2012 г.
yandex.browser - первое впечателение о новом игроке
Подписаться на:
Сообщения (Atom)