воскресенье, 30 ноября 2008 г.

Прогноз на 2009 год

Прочел я прогноз на 2009 от Сергея Орлика. Вспомнил, как сбылся мой прогноз про гугл. И решил последовать примеру и дать свой прогноз на 2009 год. А вдруг у меня чутье на прогнозы? Проверим?
Прогноз №1. Ни одного прогноза Сергея не исполнится.
Прогноз №2. Продажи ПО упадут до еще более низких уровней, чем были до начала компании по борьбе с пиратским ПО. Это связано с тем, что в ВТО мы уже вроде как не стремимся, поэтому нет потребности устраивать публичные порки (например, дело Поносова). А значит поднятая волна сойдет на нет, все вернется в свое русло, а с учетом кризиса- вообще пиратство расцветет пуще прежнего.
Прогноз №3. Существенно повысятся доходы от мобильного контента: игры, мелодии, видео, общение. Приход iphone в Россию, выпуск гуглофона и сотового телефона от Microsoft- звенья одной цепи, аналитики этих компаний-гигантов чувствуют где деньги. Пока вся эта мобильность будет работать только на индустрию развлечений, на индивидуального пользователя. Для бизнеса мобильные решения так и не созреют за 2009 год. Эта ситуация аналогична тому как развивались 3D-ускорители, широкое использование которых началось с видеоигр.
Прогноз №4. Ближе к концу кризиса производители ПО, наконец, поймут, что SaaS- это дерьмо, на которое клюнут считанные проценты дурачков. Поймут потому, что даже в условиях кризиса заманчивые предложения на базе SaaS не найдут покупателя, а что уж говорить про развитие вне кризиса. Зачем вообще за что-то платить, если бесплатное получает большее распространение? Более того, это бесплатное уже достигло весьма не плохого уровня развития: багов меньше, работает устойчивей, интерфейс дружественней, функционал полнее.
Прогноз №5. Несмотря ни на какой кризис, продолжиться переход компаний от своих собственных разработок систем автоматизации к использованию унифицированных решений, в основном на базе 1С.
Прогноз №6. Если online-продажа музыки уже превзошла продажи на CD, то цифровое ТВ только на подходе. Нас ждет быстрое развитие цифрового ТВ и всплеск интереса рекламодателей к нему. Многие в 2009 году осознанно полностью откажутся от обычного ТВ в пользу исключительно цифрового ТВ.
Короче- все будет по-старому, но чуточку хуже. Однако в области связи, общения, интерактивных услуг, развлечений чувствуется, что назревает какой-то прорыв. Пока я не понимаю к чему все идет, есть только расплывчатые ощущения: В общественном транспорте больше народу сидит за нетбуками, из которых торчат антенны мобильной связи; 3G уж раскручивают все шире; айфоны, гуглофоны- только про них и слышишь; больше народу выкладывают в интернет свои фотки, смотрят видео, общаются через интернет; популярность "одноклассников.ру". Это все отдельные кусочки пазла, которые уже высыпали из коробки на стол, но еще не приступили к собиранию из них картинки. Вот в 2009 году сборка картинки и начнется. Ясно еще ничего не станет, но синергетический эффект от объединения отдельных кусочков мы ощутим.

воскресенье, 9 ноября 2008 г.

Психологический портрет программиста

Народная мудрость: «Если ты сделаешь что-то быстро, но плохо, никто не вспомнит, что ты сделал это быстро. Но все скажут, что ты сделал это плохо. Если ты сделаешь что-либо медленно, но хорошо, никто потом не вспомнит, что ты делал это медленно. Но все потом скажут, что ты сделал это хорошо».

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

  • Быстро и хорошо.
  • Быстро и плохо.
  • Медленно и хорошо.
  • Медленно и плохо.

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

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

Тип работающих быстро, но плохо наиболее распространен. По моим ощущениям- не менее 60% от программистов, входящих в эти две группы. Эту категорию любит начальство и заказчик, потому, что они умеют прямо таки с космической скоростью клепать код. Именно, что клепать, так как такой код для дальнейшего развития вообще не пригоден. При модернизациях программ его либо полностью выкидывают, либо нанимают консультантов, которые чаще всего внешними косметическими мерами улучшают его. В таком коде, как правило, отсутствуют какие-либо проверки в функциях на корректность входных параметров, нет ни строчки комментариев и, чтобы избавится от надоедливых исключений (exception), густо натыканы их перехваты (catch) с пустыми операторными скобками. Такой код изобилует неожиданными "ходами" на ровном месте. Неожиданными, потому, что решение тривиальной задачи уже накатанным приемом решается вдруг каким-то умопомрачительным вывертом, который полдня разбираешь, а потом еще полдня цедишь сквозь зубы ругательства в адрес того м… который пару тривиальных и всем понятных строчек раздул в невесть что.

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

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

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

Самим программистам, прочитавшим эту статью, я рекомендую четко определиться с принадлежностью к тому или иному психологическому типу программистов и, в соответствии со своим типом, подбирать работу. Это повышает ваши шансы оказаться "на своем месте", получить максимальную отдачу от работы и в плане зарплаты, и в плане удовлетворения результатами своих трудов.

понедельник, 1 сентября 2008 г.

Багаж знаний. Часть 6.

Инженерная культура, командная работа

Два понятия объединены вместо, чтобы сильно не дробить тему. К тому же, командная работа в принципе невозможна без привитой каждому участнику команды инженерной культуры. Сначала об инженерной культуре.

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

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

  • "… А ты создавай компонент в "ран-тайме" и присваивай ему "парентом" главную форму…"
  • "…Подменяй в "квери" динамически условие "where", и прибей к нему план запроса…"
  • "…Отпиши в трекер про эту багу, ковыряю ее на днях…"
  • "…Слил код с cvs, просмотрел дифы и закоммитил…"
  • "…Сегодня в "ньюсах" пробегала "инфа" о выходе нового релиза…"

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

  • 1.01 (123)- версия (еще называемая мажорная версия) 1, в рамках этой версии- подверсия (минорная версия)- 01, билд- 123.
  • 3.17 (1435) - версия 3, подверсия 17, билд- 1435.

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

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

  1. Обсуждение функционала. Это когда собирается группа и обсуждает, как надо сделать. Рисуют на доске, на листках, обсуждают после совещания в коридорах. Распределяются обязанности.
  2. Делается первый черновой вариант, густо "нашинкованный" заглушками. Вариант обсуждается, учитывается первый опыт, замечания и разработка идет на второй круг.
  3. Когда руководитель видит, что пора уже делать релиз, дается команда чуть притормозить коммиты в CVS нового функционала, а усиленно "довести до ума" функционал, который должен войти в релиз. Если вы не успели "довести до ума", то страшного ничего не будет, но вам добавиться лишняя работа т.к. наступит следующий этап.
  4. Создается ветка в CVS. С этого момента новый функционал в ветку не добавляется, а коммитится в HEAD. В ветке с готовящимся релизом сидят разработчики, усиленно дорабатывающие ПО. В HEAD'e продолжает работать небольшая часть разработчиков. С этого момента начинают выкладываться так называемые "снап-шоты". Это ночные сборки всего ПО, которое должно войти в релиз. В эти сборки сходят изменения, сделанные разработчиками за день.
  5. По мере готовности версии продукта, руководитель принимает решение о выпуске альфа-версии. Эта версия позволяет широкому кругу пользователей предварительно ознакомиться с ПО, а разработчикам получить обратный отклик ("фид-бэк") о ПО, а также список обнаруженных пользователями ошибок ("багов").
  6. Когда функционал программы сформирован, выпускается RC1 (release candidate 1), т.е. предварительная версия. В ней уже нового функционала внедряться не будет, идет только исправление ошибок.
  7. По мере снижения количества обнаруженных ошибок и их исправления выпускаются RC2, RC3. Крайне редко делают RC4. RC3 уже означает, что ПО в данной версии достигло зрелой стадии и пригодно к эксплуатации. Количество разработчиков, работающих над данной веткой продукта, уменьшается, т.к. для исправления ошибок их уже много не надо. Многие переходят на разработку следующей версии, как говорят "работать в HEAD'e". Такая вот несколько необычная ситуация- еще текущую версию не выпустили, уже работают на следующей. Легко может в производстве находится 1-2 версии ПО одновременно, и еще плюс экспериментальные разработки (это уже только в очень крупных компаниях уровня Microsoft).
  8. И вот, наступает долгожданный момент, и объявляется о выпуске релиза (release). Именно релиз начинает массово распространяться, рекламироваться, а разработчики расходятся по другим проектам. Выпуск сопровождается банкетом для всех разработчиков, в каждой фирме есть свои традиции выпуска релизов: вручение памятных знаков, "золотых" дисков с релизом ПО и т.п.

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

Ночные сборки полезны сторонним разработчикам, которые будут использовать готовящийся продукт в своем ПО. Сторонние разработчики являются не просто опытными пользователям ПО, наиболее доверенным из них предоставляется доступ к части исходного кода программы. Имея доступ к низкоуровневым интерфейсам программы, они, что называется, видят ее изнутри, и могут свежим взглядом со стороны подсказать направления реализации тех или иных возможностей, указать на ошибки, и даже ошибки проектирования. Для общения с наиболее активными пользователями и сторонними разработчиками создаются специализированные форумы, нередко сторонние разработчики напрямую по e-mail обращаются к разработчикам выпускаемой версии ПО, встречаются на семинарах и конференциях, где неформально общаются и обсуждают готовящийся релиз. Сторонние разработчики стараются вместе с анонсом выпуска релиза вашего ПО, объявить о выпуске своего ПО, полностью поддерживающего функционал новой версии вашей программы.

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

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

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

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

Заключение

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

(Конец)

Багаж знаний. Часть 5.

Специализированные знания в определенной предметной области

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

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

Знания и опыт

Вы думаете что, например, программисту 1С не надо читать Страуструпа и Кнута? Вы пренебрежительно фыркали, читая главу про технологии или инструментарий? Ну тогда может вас убедят несколько случаев из моей жизни. Это не взято с других сайтов, все случаи произошли с моим участием.

История первая. У гордости российской IT-отрасли, фирмы 1С, у ее хорошо развитого ПО, есть "ахиллесова пята": огромная армия низкопрофессиональных программистов, чей уровень подготовки зачастую граничит с профанацией. На мой взгляд, это произошло из-за низкого уровня вхождения в рынок: продукт настолько прост в изучении, что многие не программисты (экономисты, кадровики и пр.) становятся программистами 1С. Так вот, был в фирме, где я работал, программист 1С Толик. Экономист по образованию. Однажды мое внимание привлекло оживленное бегание бухгалтеров к нему, и Толика к бухгалтерам. Они носили кипы бумаг, оживленно что-то обсуждали, засиживались до поздна. Это продолжалось дня два. На третий день взлохмаченный и задуренный он оглянулся вокруг в поисках ЛЮБОЙ помощи. Тут я и спросил его:
- Толик, что за "запарка" у вас? Отчетность очередная?
- Неее, 1С глючит, третий день бьюсь, не могу обойти.
- ?!
- НДС считает не правильно, суммы с НДС и без НДС не сходятся в копейках.
В общем, тут уже можно смеяться, продолжать историю нет смысла. Далее я ему провел ликбез по программе первого курса технического ВУЗа, и объяснил, что такое погрешность округления. В следующие полчаса задача, занимавшая умы всех бухгалтеров предприятия и Толика, была успешно решена.

Вторая история. Костя, сертифицированный программист по финансовым системам. Сидим в кафе, говорим о разном. Зашла речь о его работе. Он расхваливает свою систему и предлагает ее внедрить на моем предприятии. На что я говорю, что она такие объемы не потянет. Далее Костя говорит:
- Ну почему же не потянет, вот мы заканчиваем крупный проект и там все нормально с производительностью.
- А что будет через год, когда там будет много данных? - спрашиваю я.
- Купят сервер помощнее.
- Да, у вас система мощная, но почему бы вам ее не оптимизировать, чтобы не требовалось наращивать железо?
- А это умная программа: она сама себя оптимизирует.
- Такого не может быть! Что будет, если я добавлю в таблицу БД еще одно поле и буду вести по нему поиск? Если я ручками не проиндексирую поле, то поиск будет вестись медленно, перебором! Тут сама программа ни при чем.
- Неее, программа умная, там все очень хорошо продумано. Будет работать быстро.
- Но как?!
- Я точно не знаю, но думаю, что она сама будет автоматически все поля индексировать!

Следующая история. Маленький диалог:
- Я буду переписывать твою программу с нуля.
- Для чего? Там будет другой функционал?
- Нет.
- Там будет использоваться другая БД?
- Нет.
- Я потратил месяц чтобы ее написать. Зачем ты будешь еще минимум месяц тратить, на то, чтобы ее переписать?
- Я не хочу разбираться как работает твой код.

Еще одна история. Напротив меня одно время было рабочее место программиста Жени, с очень большой зарплатой, т.к. он считается очень хорошим специалистом. Он упорно работает над протоколом обмена данными между программами. У Жени в его работе возник затык. Он прогулялся, поймав меня в коридоре и, немного стесняясь, спрашивает: "А сколько бит в числе?". Так и спросил: бит в числе.

Несколько лет назад я разбирался с мистической историей. Функционал у клиента в принципе не работал. Вообще. Как будто его и вовсе не было. "Ларчик" открылся быстро- достаточно было взглянуть на исходный код. Код, который был помещен программистом в... модуль с Unit-тестами! Т.е. на тестировании все работало великолепно, но когда собирался релиз, этого кода там просто не оказывалось.

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


(Продолжение следует...)

Багаж знаний. Часть 4.

Рабочий инструментарий программиста

Как я уже писал ранее, рабочее место современного программиста оснащается, как "космический корабль", кучей различного ПО: см. "Инструменты программиста": http://www.alvosoft.com/itlife/2007/05/blog-post_30.html. По этому вопросу даю еще ссылку: http://alenacpp.blogspot.com/2008/01/wiki.html. Теперь, как и с технологиями, список с небольшими комментариями от себя (сразу извиняюсь, что в списке я не всегда корректно "на одну доску" ставлю в качестве примера два сильно разных инструментария- для кратких пояснений различия между ними можно не учитывать, общей картины это не ухудшит):

  • Система контроля версий (представители: CVS, SVN)- данные системы ведут учет версий файлов, хранят все версии и информацию о том, кто изменил файл, какие именно строчки в файле изменил и когда. Это позволяет восстановить состояние файлов на любой версии, а также организовать коллективную работу на проектом. Работа над проектом нескольких человек практически невозможна без использования какой-либо системы контроля версий. Поэтому научиться работать с CVS или SVN начинающему специалисту надо обязательно.
  • BugTracker (представители: Jira, BugZilla)- системы отслеживания ошибок. Позволяют пользователям вести учет найденных в ПО ошибок и отслеживать этапы их устранения. Это тоже обязательный элемент изучения для начинающего. В командах разработчиков багтрекеры используются незначительно реже, чем системы контроля версий.
  • Документирование (представители: Wiki, Doxygen)- эти системы позволяют документировать исходный код программы (Doxygen), а также документировать процесс разработки (wiki): обмен мнениями, идеи, планы. Системы просты в изучении, поэтому даже обсуждать не стоит, надо их изучать или нет- даю полчаса на изучение. Время пошло!
  • Profiler- позволяет замерить время выполнения отдельных функций программы с целью выявления узких мест для последующей оптимизации кода программы. Этим пользуются нечасто, чаще предпочитают купить железо помощнее. Для начинающего достаточно просто знать что есть такие штуки как "профайлеры".
  • Debugger- отладчики программ. Ну, без них отладка ПО мучение сплошное. Обязательно надо уметь не только ими пользоваться, но и великолепно владеть методами отладки. Тут учебники не помогут: практика, практика и, еще раз, практика.
  • Сборщик (представители: make, cmake, ant)- программа, которая по заданному сценарию вызывает компиляцию отдельных файлов исходного кода ПО в нужной последовательности. Конечный результат работы сборщика: собранная и готовая к запуску программа. Обычно у сборщиков бывает несколько целей работы: сборка отладочной версии ПО, сборка с тестированием, сборка релиза, сборка инсталляционного пакета. В правильно организованном процессе сборки подготовка инсталляционного пакета должна выполняться в два этапа: выгрузка из системы контроля версий нужной версии программы и запуск сборщика- все, после этого в заданном каталоге должен оказаться инсталляционный пакет. Обычно в командах программистов от 5 человек, как правило, есть отдельный человек, который занимается исключительно сборщиком. От начинающего программиста требуются общие знания о сборщиках.
  • Тестирование (например: UnitTest)- видов тестирования много, это отдельная от программирования область деятельности. В серьезных проектах обязательно есть тесты, есть люди, занимающиеся тестированием. Программисту достаточно понимать, что тестируется и как, не вникая в тонкости построения систем тестирования.
  • Написание справки (представители: Tex, Chm)- часто программистам самим приходится писать справки для пользователей. Это не любимое дело большинства из программистской братии. В серьезных организациях для этого есть отдельные люди, и даже отделы. Техническая сторона дела- формат записей, сборка справки несложна, однако косноязычность- непреодолимый барьер для большинства IT-специалистов. В общем, бегло просмотрите что это такое, чтобы знать, кто такие "течрайтеры" и как с ними общаться.
  • Инсталляторы (представители: Inno Setup, MSI)- этими программами, отвечающими за корректную установку или удаление ПО, как правило, занимаются отдельные специалисты. Программист сталкивается с ними в основном когда пробует сам продавать свое ПО (shareware). Поэтому от начинающего программиста достаточно, чтобы он знал, используемые им технологии: какие dll надо включить к инсталляционный пакет, какие значения задать в реестре и т.п., чтобы сообщить это специалисту, занимающемуся сборкой инсталляционного пакета.
  • Защита ПО (представители: Execryptor, Hasp)- в этим программист уж вряд столкнется в начале карьеры. Установкой системы защиты ПО от нелегального копирования редко занимаются в самих организациях, предпочитая отдавать эту работу на аутсорсинг. Это связано с тем, что защита обычно пересматривается перед релизом и держать на постоянной основе своего специалиста по защите большинству фирм не выгодно.
  • Проектирование (представитель: UML)- в этой области знаний больше "воды", чем реально полезной информации. UML- хорошо пропиаренный способ описания проекта. Я работал и был связан с очень крупными IT-предприятиями, имена которых у всех на слуху. Их штат сотрудников насчитывает более 1000 человек. И что характерно, они не используют ни UML, ни каких-либо других способов описания проекта. Прекрасно обходятся доской с фломастерами и живым общением. Поэтому моя рекомендация начинающим: "на первых порах" держитесь подальше от слов UML, методики проектирования- это точно не первоочередные вещи, которые надо изучать.
  • Управление разработкой (представители: MS Project, электронные таблицы)- волей-неволей, но вы все же придете к понимаю необходимости управлять процессом разработки. Даже, хотя бы лично для себя составить кратенький план: "1). написать класс…; 2). не забыть его подключить туда-то…; 3). изменить то-то…". Например, я делаю такие пометки в обычном notepad.exe. Рекомендую этот стиль работы: вы ничего не забудете сделать, что повысит качество вашей работы, а вашему начальнику вы в любой момент сможете предоставить отчет о том, что сделали, и о том, что вам еще предстоит сделать.
  • Протоколированное общение (представители: телеконференции, IM-клиенты, e-mail)- я указал именно протоколированное общение. В работе важно, чтобы общение записывалось, чтобы можно было потом что-то важное по записям вспомнить. Личный совет: никогда не удаляйте протоколы- пройдет 3-4 года и обязательно что-то всплывет, что потребует вспомнить, что же вообще-то было.
  • Обмен файлами (представители: SMB, FTP)- ну куда уж без этого! В ходе работы файлам обмениваются постоянно, начиная с внутренней документации, заканчивая личными фотками с отпуска. Я предпочитаю FTP- неприхотливый протокол. FTP-сервера у меня запущены и дома, и на работе.

Информация по перечисленному инструментарию можно найти в http://ru.wikipedia.org/. В каждом пункте я привел по паре примеров, но подобного ПО существенно больше- освойте, хотя бы перечисленное для начала. Приведенные примеры- наиболее популярные программы, зная их, на собеседовании вы будете чувствовать себя гораздо увереннее.

(Продолжение следует...)

Багаж знаний. Часть 3.

Операционные системы

На протяжении всего блога я ориентирую начинающих специалистов на мэйнстрим. Явно указываю язык программирования, который надо изучать, критерии для оценки фирм, в которых стоит работать и т.п. Да! И еще я по-прежнему утверждаю, что не надо поступать учится в ВУЗ: http://www.alvosoft.com/itlife/2007/04/blog-post_5372.html. А по операционными системами я еще "наводок" не давал.

На сегодняшний день ситуация такова, что Linux получает все более широкое распространение. Даже на дешевые ноутбуки стали ставить эту ОС, чего ранее не было вообще. Так стоит ли оставаться на Windows или надо уже потихоньку перекочевывать на Linux? Вне сомнений, что на текущий момент Windows кормит минимум 80% IT-специалистов. Я не буду проводить никаких исследований, и скажу на основании своего опыта: лучше изучать программирование под Windows. Как ни крути, а "винда"- это мэйнстрим, то, где крутятся основные деньги, выделяемые на IT. Ситуация в будущем коренным образом не изменится, т.к. любая попытка более широкого продвижения Linux за счет доли Windows упрется в сопротивление уже не только Microsoft, но и многочисленной армии программистов, откормленной на сытном рабочем столе Windows.

Если вы сделали самостоятельный выбор в пользу программирования под Linux, то переубеждать вас не буду- и там вы свой хлеб найдете, а не определившимся однозначно советую освоить программирование под Windows. Именно эта ОС на сегодняшний день лучшая в смысле перспектив развития, карьеры и заработка.

Языки программирования

Про языки программирования я уже писал: http://www.alvosoft.com/itlife/2007/04/blog-post_24.html, предлагая осваивать Java и БД Oracle. Вот моя небольшая характеристика языков:

  • Java. Синтаксис языка изящен. Программировать на нем приятно. Создан, что называется, "по уму". Для него существует огромное количество библиотек, хорошо организованно сообщество программистов, этот язык поддерживают крупные корпорации, такие как IBM, Sun, Oracle. Язык нашел широкое применение в области разработки крупных корпоративных систем.
  • С++. Лично мне он нравится за то, что его многие критикуют: за отсутствие сборки мусора. У данного языка программирования весьма широкие возможности, что позволяет с его помощью решать широчайший круг задач, которые, зачастую, трудно решаемы в рамках других языков программирования. Однако его высокая гибкость, запутанный и трудночитаемый синтаксис, сложность задают высокий барьер "вхождения", т.е. надо приложить гораздо большие усилия, чем в других языках, чтобы освоить его.
  • C#. Часто о нем говорят, как об майкрософтовской альтернативе Java. Т.е., фактически, признавая только одну причину его появления- попытка Microsoft захватить лидерство и в области инструментария для программистов. В общем-то, язык не имеет ничего выдающего по отношению к другим языкам, и, наверное, для использующих его программистов, главное- это целостная, единая поддержка его со стороны компании. Что весьма важно при разработке крупных проектов, где C# и нашел свое применение. Но, боюсь, что этот вечный ярлык его, как подражателя, оппонента Java сыграет с ним свою злую шутку, и он пойдет по пути Visual Basic, которого мало кто всерьез воспринимает.
  • Python, Ruby и др. Их стоит воспринимать как эксперимент. Основные "мэйнстримовые" языки уже сформированы и серьезные изменения в них недопустимы, т.к. это может поломать многие крупные проекты. Однако жизнь не стоит на месте, появляются новые технологии, новые идеи, которые надо где-то обкатывать. Вот и появляются новые языки программирования, реализующие некий новый функционал, который в них обкатывается. По прошествии нескольких лет успешной эксплуатации этот новый функционал появляется в основных языках программирования: C++, Java, C#. Если идея, новый функционал на деле показал себя "не очень", то язык с этим функционалом тихонько займет свою узкую нишу, где спокойно и будет доживать свои дни.
  • Узко специализированные языки программирования. Яркий и широко известный пример: встроенный язык программирования в системе 1С или, например, web-программирование. Такие языки отлично адаптированы для решения узких задач в своей области. В них во главу угла ставится не программирования как таковое, а решение бизнес-задач. Программирование здесь вторично. Благодаря своей легкости осваивания, порог "вхождения" в эту область деятельности низок. Как правило, это приводит к тому, что в данной области скапливается разношерстный народец с весьма низким уровнем познаний в области программирования. Данное "сборище" формирует высококонкурентное сообщество, что приводит в более низким зарплатам в этих областях.
  • Мало распространенные языки программирования или уже потерявшие былую славу. Это языки типа (тут сейчас будут возмущенные вопли): C, Delphi, Basic. Армия программистов на этих языках еще весьма велика, но эти языки уже явно не являются основными в целом по отрасли, и ушли в узкую нишу. Существует огромное количество ПО, написанного на них, которое надо поддерживать. Учитывая, что пополнения рядов программистов в этих языках идет крайне низкими темпами, то "старые" программисты на этих языках с каждым годом становятся все ценнее и ценнее.

По вышеуказанной вначале списка ссылке вы можете пройти простой алгоритм по которому вы можете сориентироваться, куда вам лучше всего податься. Став хорошим специалистом, вы в любой нише найдете себе высокооплачиваемую работу. Но я лично рекомендую держаться мэйнстрима, и выбирать между C++, Java, C#, 1С, web-программированием. А Python и прочие оставьте для экспериментов.

(Продолжение следует...)

Багаж знаний. Часть 2.

Технологии

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

  • Run-Time, Design-Time, Compile-Time. Эти термины означают момент, когда происходит то или иное действие: во время исполнения программы, во время разработки, во время компиляции. Эти понятия не должны вызывать ни малейших трудностей при использовании их в дискуссии.
  • RTTI- возможность во время выполнения программы (Run-Time) исследовать тот или иной объект в программе: определить список его свойств, узнать тип каждого свойства. Эта технология требуется не часто, допустимо знать про нее в общих чертах.
  • ООП- парадигма программирования, в основе которой лежит понятие объекта заданного класса. На сегодняшний день- это мэйнстрим, основной способ написания программ у подавляющего числа программистов.
  • Шаблоны- генерация кода по заданному шаблону. В принципе, общих знаний про шаблоны будет достаточно.
  • Перегрузка операторов- возможность задать свои функции для выполнения таких операций, как сложение, умножение и т.п. Используется не часто- общих знаний будет достаточно.
  • Исключения- один из способов обработки ошибок в программе. Это лучше знать- мощнейший механизм, значительно облегчающий обработку ошибок, хотя многие его избегают, в основном из-за недостаточных знаний об исключениях.
  • Call-back вызовы- когда какой-либо внешней функции передается адрес определенной функции в нашей программе, чтобы та внешняя функция могла вызвать от себя нашу функцию (типа того, как мы пишем SMS кому-то: "Перезвони мне на такой-то номер"). Знать обязательно- встречается часто, можно сказать- постоянно.
  • Лямбда-функции- смотри про лямбда-исчисление. "Зверь" относительно новый, ради эрудиции почитать стоит.
  • Компонентная модель- говоря про это емкое понятие, обычно имеют ввиду способ построения программы с помощью компонент- функционально полных программных блоков, которые являются как бы "кирпичиками" программы. Простота разработки программ с помощью компонент породила класс программистов, называемый "кнопочкокидатели на формочки".
  • Обмен сообщениями- тема очень широкая. Тут и RPC, и очереди, и посылки сообщений, сигналы. Знать обязательно. Ключевые слова для поиска информации к изучению: RPC, events, signal, queue.
  • Приемы оптимизации. Это когда что-то тормозит или "кушает" много каких-либо ресурсов, то надо улучшить показатели программы по этому "тормозному" параметру. Например, если низкая скорость работы программы, то повысить ее можно предварительным кэшированием данных. Обычно улучшение одного показателя ухудшает другой. Например, увеличение быстродействия часто требует повышенного расхода используемой памяти. Хороших книг по оптимизации я не знаю- только практика.
  • Многопоточность- это когда внутри программы может выполняться одновременно несколько функций. В наш век многоядерности и многопроцессорности про это надо знать.
  • Синхронный/асинхронный режим работы- в синхронном мы посылаем запрос и дальше не работаем пока не придет ответ, а в асинхронном- послали запрос и занимаемся "своими делами", по приходу ответа выполняем его обработку. Асинхронный в реализации сложнее. Это тему знать надо хорошо.
  • Каналы, потоки- это некоторые из способов обмена информацией. При этом технология каналов имитирует канал, трубу (pipes), по которой как бы течет информация, а потоки (stream) имитируют что-то типа потоков, рек информации из которых мы как бы черпаем нужные нам данные. Эти вещи знать надо железно.
  • Блокировки (мьютексы, критические секции)- это способ сообщить другим частям программы или другим программам, чтоб они "не лезли сюда" (к определенным данным, к "железу"), т.к. вы в своей функции уже приступили к работе с блокируемыми ресурсами и пока не закончите, никто не должен их трогать. Про блокировки надо знать, эта тема идет "рука об руку" с темой многопоточности.
  • Регулярные выражения- поиск текстовых данных по заданному образцу. Ну без этого совсем никуда.
  • XML- замечательный язык для структурирования информации. Получил широкое распространение, легок в изучении. Знать обязательно.
  • Библиотеки подпрограмм, классов. У каждого языка программирования есть свои библиотеки. Есть такая фраза, часто цитируемая в форумах: "В языке главное не знание его синтаксиса, а знание его библиотек". Говорить, что это знать обязательно, даже не имеет смысла- мимо изучения библиотек не пройти на пути повышения своей квалификации.

В этом перечне краткие пояснения мои. Я упрощал пояснения в ущерб точности определения. По большинству терминов определения можно найти в википедии: http://ru.wikipedia.org/. От программиста ожидается, что он ориентируется в большинстве из перечисленных терминов. Исключением является большая группа программистов 1С, SAP и других, им подобных. В их областях программирования первично умение решать бизнес-задачи, а не сугубо технические задачи программирования, поэтому и требуемый круг знаний там другой. НО! Другой список терминов вовсе не означает, что не надо читать Страуструпа и Кнута. Перечисленные книги надо прочесть всем- это фундаментальная подготовка. К чему может привести ее недостаток- в конце статьи.

Форумы и телеконференции

Обычно в каждой области знаний есть свои наиболее популярные форумы, телеконференции. Однако есть и несколько универсальных сайтов, на которых общаются высокопрофессиональные специалисты, активность этих сайтов высокая и спамом и флеймом там следят модераторы. Из таких универсальных сайтов я порекомендую в порядке предпочтений:

  • http://www.rsdn.ru/ - наиболее предпочитаемый мною. Тут есть и бдительные модераторы, и опытные специалисты, а особенно мне нравится наличие удобного оффлайного клиента для чтения форумов на сайте.
  • http://www.sql.ru/ - более "чайниковского" уровня форумы. Для начинающих может быть и ничего, но лично меня форумы этого сайта раздражают: слишком мало полезной информации, в основном вопросы начального уровня. Но зато можно подключиться к форумам по протоколу NNTP и просматривать их в том же Outlook'e.
  • http://groups.google.ru/ - хорошие форумы есть, но их надо поискать среди кучи практически мертвых форумов. К плюсам можно отнести возможность подключения к форумам по протоколу NNTP.

Если вы еще не были на этих форумах, то обязательно зайдите- наверняка найдете там интересное для себя.

(Продолжение следует...)

суббота, 2 августа 2008 г.

Багаж знаний. Часть 1.

Полночь. Я опять набираю свою новую статью в блог. Для меня это загадка, но самое продуктивное время для меня с 23 часов и до 2 часов ночи. Я не один такой- несколько моих друзей тоже говорят, что наиболее активны в это время. Может все же подумать над тем, чтобы удаленно работать…

Ладно, это все мысли вслух. В моем гугловском блокноте записана тема для новой статьи. Записана давно, и кратко мысли набросаны, но я все тяну с написанием, т.к. тема очень обширна, и в "один присест" ее не освоить. Вот, разминаюсь потихоньку легкими статьями про отдых (http://www.alvosoft.com/itlife/2008/07/blog-post.html), организацию рабочего места (http://www.alvosoft.com/itlife/2008/03/blog-post.html) и т.п.

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

  1. какие книги надо прочитать, а какие лучше или не читать, или отложить "на потом";
  2. какие форумы и телеконференции читать;
  3. какая ОС лучше;
  4. какой язык программирования лучший;
  5. рабочий инструментарий программиста;
  6. специализированные знания в определенной предметной области;
  7. знания и опыт, инженерная культура, командная работа.

Ну вот, сами видите: тема ужасна, как я и говорил. Приступаем к погружению в пучины "священных войн"!

Прежде всего, скажу сразу, что я не могу говорить за все специализации: 1С или PHP, ГИС или VoIP- это вещи кардинально разные. Но тем не менее единую "точку опоры", так сказать, "поле боя", выделить можно. Это- молодой специалист (собственно весь блог для этой категории и задумывался). Каков его типичный портрет? Ну все мы в школе, институте проходили уроки информатики. Нам преподавали системы счисления, машинную арифметику, базовые алгоритмы (помните, сортировка "пузырьком", операции с матрицами?). Программирование ведется и поныне на таких языках как Фортран, Бейсик, Паскаль. Те, кто решает сделать своей профессией программирование, обычно на "программистских" специальностях изучают C, C++, и, более углубленно,- алгоритмы. В итоге, "на выходе", мы имеем пылкого молодого человека (или даму), который хочет и "горы своротить" и получить за это кучу денег. Но, при этом, его опыт удручающе мал, и к реальным проектам его нельзя подпускать "на пушечный выстрел".

В итоге, получается активный (желающий сделать карьеру) специалист с нулевым опытом, чисто теоретическим знанием алгоритмов (что это такое знает, а правильно применить пока не умеет), программирующий на C, C++. Попав в реальный мир, он это осознает, и тут же перед ним встают вопросы:

  1. Какие книги прочесть, чтобы набраться практических знаний?
  2. Какую специализацию выбрать: остаться C++ программистом или пойти в 1С, уйти в область программирования банковского ПО или писать драйвера?

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

Книги

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

Сначала надо прочесть Страуструпа "Язык программирования C++. Специальное издание": http://www.books.ru/shop/books/84700. Эту книгу надо прочесть любому программисту: 1С, web-программисту, программисту баз данных и программистам других специализаций. Будьте готовы к порой весьма занудным философским отступлениями. Не пропускайте их и не забрасывайте чтение. Помните: Страуструп не только создатель C++, он преподаватель с многолетним опытом. Стиль изложения материала в книге выверен годами преподавания, все философские отступления делаются не зря: значит эти занудные места важны, и автор, видимо, не раз сталкивался в непониманием сути того, что он пытается объяснить. Уделите внимание разбору приводимых примеров: отменная подборка материала! Многие опытные программисты нередко обзывают книгу "художественным чтением на ночь", призывая читать стандарт. Однако, они забывают, для кого написана эта книга (см. ее введение). Книга полезна не только для программистов C++, но и вообще для всех программистов, т.к. в большинстве современных языков программирования реализованы и ООП, и шаблоны, и перегрузка операторов, и т.д. А похожий синтаксис у C++, Java, C# делает понятными приводимые на C++ примеры в книге большинству программистов. В общем, моя рекомендация- начинать укреплять свои знания с этой книги. После изучения этой книги вы научитесь подходить к решению задачи с правильной стороны, и уж точно избежите участи стать "кнопочкокидателем на формочки".

Для подковывания знаний в области алгоритмов: Дональд Кнут, "Искусство программирования": http://www.books.ru/shop/books/7231. Несколько томов исчерпывающего материала по различным алгоритмам. Выберите на свое усмотрение тот том, который, как вам кажется, наиболее полезен будет для вас, как в смысле применения почерпнутых знаний на работе, так и для ликвидации пробелов в ваших знаниях. А далее вы уже решите сами, надо ли вам читать остальные тома.

И все- этого уже будет достаточно, чтобы стать конкурентоспособным на рынке труда, но еще недостаточно, чтобы стать хорошим программистом. А для этого нужен еще и опыт. Опыт получается только постоянным трудом и никакие книги тут не помогут. Именно поэтому я не рекомендую к прочтению достаточно популярные книги:

  1. "Рефакторинг: улучшение существующего кода": http://www.books.ru/shop/books/30436;
  2. "Архитектура корпоративных программных приложений": http://www.books.ru/shop/books/156126;
  3. "Приемы объектно-ориентированного проектирования. Паттерны проектирования": http://www.books.ru/shop/books/8451.

Так как, прочитав эти книги, молодой специалист, не имея еще достаточного опыта применения приемов и идей, изложенных в данных книгах на практике, становится похож на "буриданова осла". В конкретной ситуации он видит возможность решить поставленную задачу несколькими способами из книги, а какой именно способ выбрать не знает из-за недостаточного опыта. Форумы по архитектуре на 99% состоят из вопросов типа: "А какой лучше применить здесь паттерн?" С другой стороны, опытному программисту эти книги уже не интересны: большинство популярных техник программирования он уже освоил. Вот и не понятно, для какой аудитории вообще эти книги написаны? Поэтому, отложите их прочтение "на потом", а там уж, будучи "в теме", сами решите, нужны ли они вам.

Для тех, кому понравился C++, советую обратить внимание и на другие рекомендации: http://alenacpp.blogspot.com/2006/09/blog-post_19.html.

(Продолжение следует...)

суббота, 12 июля 2008 г.

Про важность отдыха

Начну с такой истории в своей жизни. На заре своей трудовой деятельности работал я в небольшой фирмочке. За соседним столом сидел коллега лет 40. Я каждый день старался, выкладывался как только мог. Часто бывало, что приходил домой в 2-3 часа ночи. Я очень хотел заработать хорошую репутацию и сделать карьеру. И для этого считал, что важно работать лучше других, делать больше всех. Я внимательно следил, как продвигается работа у коллеги, опираясь в оценках своей работы на его результаты.

А коллега в это время никуда не торопился. Частенько выходил покурить, и там читал книги по полчаса, пил чаек. Тем не менее, когда подходил срок сдачи задания, у него все было готово. Я нервничал, что никак не мог толком оторваться от него по производительности, и увеличивал свои усилия для выполнения работы.

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

Я стал понимать, что не на пустом месте возникли статьи трудового кодекса: 8-часовой рабочий день, час на перерыв, 5 рабочих дней, 28 дней отпуска. И теперь, как тот мой бывший коллега, я предпочитаю пойти попить чаю, если мысль в голову не идет. Могу просмотреть телеконференции, почитать новости. И ничего страшного в плане моей работоспособности не происходит- у меня среднестатическая производительность.

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

Из своего опыта я вынес несколько правил (кстати, многие скажут про них, что это все "старые избитые истины"):

  1. Соблюдайте трудовой кодекс: 8 часов поработали- остальное время отдыхайте. Не "шабашьте" вне работы- лучше направьте все свои силы в одно русло, достигая наилучших результатов в одном деле, и не распыляясь по куче мелких делишек.
  2. Не сидите все 8 часов за компьютером- делайте перерывы, пейте чай, общайтесь с коллегами. Если мысли нет, то ее и не высидишь. По этому поводу великолепно написал Джоэль Спольски. Почитайте про его "состояние потока": http://russian.joelonsoftware.com/Articles/FireAndMotion.html.
  3. Те, кто говорят, что могут работать по 8 часов непрерывно- лгуны. Доказано, что более 4 часов человек не способен сохранять концентрацию внимания. Об этом вам наверняка говорили на лекциях ОБЖ в ВУЗе, т.к. на данном факте строится график работы всех критически важных служб жизнеобеспечения. Если вы все же утверждаете, что трудитесь каждый день по 8 часов непрерывно, то понаблюдайте за собой: через несколько часов активной работы вам захочется в туалет, либо вы вспомните, что надо срочно, пока не забыли, поговорить в аське со знакомым о чем-то, либо просто захотите проверить почту, посмотреть погоду, вспомните какую-то новость и обсудите ее с коллегами. Все это вам будет казаться важным, частью трудового процесса, однако это мозг сам "находит поводы" расслабиться, т.к. в его работе наступил спад, и на первый план вылезли второстепенные вопросы, которые, по большому счету, можно было бы и отложить, но вам они вдруг показались важными почему-то ("пока не забыл", "пока не ушел" и т.п.).
  4. Для работников умственного труда, в которым относится подавляющее большинство IT-специалистов, важны комфортные условия труда. Человек должен быть выспавшимся, не голодным, с достаточным размером оплаты труда, чтобы ему не приходилось думать о том, где достать денег. Не должно быть ни холодно, ни душно, без сквозняков, пыли и грязи. Без внешнего шума и беготни вокруг. Удобное кресло, хорошая техника. Это все совсем не дорого, а прирост производительности будет приличный. По своему опыту скажу, что как только я перешел работать из фирмы, где практикуют "open space", в фирму, где у работников даже не свой кубикл, а отдельный кабинет, то я реально увидел, что стал работать существенно производительней. Подробнее тут: http://www.alvosoft.com/itlife/2008/03/blog-post.html.
  5. А еще я заметил, что лучше всего трудятся те, кто разнообразно отдыхает: ездит в турпоходы, на курорты, а не просто весь отпуск на даче с утра до вечера грядки пропалывает.

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

понедельник, 12 мая 2008 г.

Дети, программирование и наука


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

Наблюдение 1

Рефлекс сосания груди. Он есть с рождения. Сам процесс очень занимательный. Вы видели, как дозаправляются в воздухе самолеты? Процесс похож. Ребенок щекой чувствует сосок, поворачивает голову в его сторону. Затем отклоняется от груди и, как коршун, со всего размаха, кидается на грудь, пытаясь присосаться к ней. Если попытка не удалась, то голова ребенка "отпружинивает" назад, и он снова повторяет попытку. Это показывают на видео на курсах молодых родителей, но на практике обычно мамы сами дают грудь. Но я заметил кое-что еще. У младенца голова по отношению к телу большая и тяжелая. Ребенок ее не может держать. Поэтому отклонение и набрасывание на грудь для него весьма энергозатратная операция. Буквально, после 2-3 подходов-отскоков младенцу требуется передышка. Следовательно, задача точного "прицеливания" на грудь для него важна. Попробуйте сами с завязанными глазами попить воды из фонтанчика, не облившись водой. Как решает ее малыш? Известным математическим методом деления отрезка пополам, которым он пользуется интуитивно! Вот, он ведет щекой по соску до угла рта, но не пытается захватить его сразу- сил мало, надо только с размаху. Он ведет сосок дальше, до другого угла рта. Затем, оценив размеры рта таким образом, движется в обратном направлении на половину времени: если путь через весь рот длился 1 секунду, то обратно он с такой же скоростью движется 0,5 секунды. В результате сосок оказывается примерно посередине рта. Тогда ребенок немедленно (пока прицел не сбился :) ) отклоняется и набрасывается на грудь. Если не получилось, то тут же делается еще пара попыток, как в артиллерии- с корректировкой цели.

Наблюдение 2

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

Наблюдение 3

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

Наблюдение 4

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

Наблюдение 5

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

понедельник, 21 апреля 2008 г.

Где лучше жить: провинция, Москва, заграница

Хорошо там, где нас нет.

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

Провинция

Достоинства:

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

Недостатки:

  • Небольшой рынок труда.
  • Невысокая зарплата.
  • Сильное влияние знакомств- какой бы умный ни был, а выше своего круга знакомств не прыгнешь, не пробьешься.
  • Удаленность от информационных каналов. Это значит что:
    • дорогой Интернет,
    • отсутствие в городе курсов повышения квалификации,
    • необходимость требуемую литературу заказывать по почте, долго и стоимость книги получается дороже
    • покупка техники- компьютеров, компонент разрабатываемых приборов делается под заказ, что также долго и дороже.
  • Слабо развита инфраструктура города: недостаточное кол-во больниц, школ и часто отсутствие ВУЗов (надо ехать куда-то учиться).

Москва, Санкт-Петербург

Достоинства:

  • Большой рынок труда.
  • Высокие зарплаты.
  • Возможностей пробиться без знакомств немного больше.
  • Отлично развитые информационные каналы: куча курсов, семинаров, литературы, дешевый высокоскоростной Интернет.
  • Хорошо развитая инфраструктура города.

Недостатки:

  • Плохая экология- как вариант жить в пригороде крупного мегаполиса, чтобы хоть ночью было чем дышать.
  • Много суеты, народа (хотя некоторым это нравится).
  • Высокая стоимость проживания (аренда квартиры, коммунальные услуги, транспорт).

Заграница

Достоинства:

  • Большой рынок труда.
  • Высокие зарплаты.
  • Развитые информационные каналы.
  • Развитая инфраструктура города.
  • Скорее всего экология будет на высоком уровне.
  • Можно выбрать "несуетливый", но обладающий всеми перечисленными достоинствами город.
  • Стоимость проживания вероятно будет несколько ниже, чем в Москве.
  • Спокойная политическая и экономическая обстановка.
  • Хорошие перспективы для воспитания и образования детей.

Недостатки:

  • Другая культура- трудности адаптации (по рассказам эмигрировавших- серьезнейшая проблема, "компенсирующая" 2-3 пункта достоинств).
  • При отсутствии друзей и родственников все проблемы надо решать только самому.
  • Высокая стоимость переезда.
  • Надо оформлять много всяких бумажек для переезда.

Резюме

  1. Как показала практика, человек ко всему привыкает. То, что кажется жителям провинциальных городов ужасным (цены, суета, экология), на самом деле к этому привыкаешь за полгода и перестаешь замечать. И наоборот, человек, живущий в провинции, обрастает знакомствами, связями, становится "своим" человеком, и никакая Москва ему и не нужна.
  2. Если грубо подсчитать пропорции [кол-во достоинств]/[кол-во недостатков], то получается провинция- 0,8, столица- 1,7, заграница- 1,8 (трудностям адаптации дано 2 пункта). Ясно, что выведенная оценка смешна в силу своего весьма грубого приближения, но она задает направления для дальнейшего сравнения. Тем не менее, при различных уточнениях, общая картина вряд ли существенно изменится. Что же можно заключить из полученных коэффициентов? Несколько выводов:
    • переезд в Москву, Санкт-Петербург оправдан. Коэффициенты отличаются примерно в два раза: 0,8 против 1,7.
    • Переезд заграницу сомнителен, т.к. разница составляет всего 0,1 единицу.

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

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

среда, 2 апреля 2008 г.

Называется, не прошло и года...

Примерно год назад я писал: "Основная проблема Web 2.0 не столько в скудной непривлекательности интерфейса, сколько в зависимости от удаленных серверов. Выключите Google- и все: ваша почта, документы, таблицы, календарь вам уже недоступны.Web 3.0 должен научится кэшировать данные локально, синхронизировать локальные хранилища личных данных пользователя с сетевыми хранилищами." И вот читаю новость:


http://cnews.ru/

Текстовый редактор Google заработает без интернета

Компания Google в понедельник, 1 апреля, объявила о том, что в течение ближайших нескольких недель пользователи офисного приложения Google Docs получат возможность редактировать документы без активного подключения к Сети.

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

"Это только начало. Сейчас мы работаем над тем, чтобы еще б… полный текст

Источник: CNews


Однако... Еще несколько таких предсказаний и можно в консультанты идти. :)

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

Организация рабочего места за компьютером, профессиональные заболевания и гимнастика

Постоянно слышу, что современные компьютеры далеко вперед ушли в развитии, а эти все ГОСТы, СНиПы устарели безнадежно. В подобном духе придумывается куча причин ничего не делать ради своего здоровья или здоровья сотрудников. Многие, и я в том числе, не заботятся о профилактике профессиональных заболеваний, а их много: геморрой, близорукость, головные боли, психическое расстройство, остеохондроз и т.п. В отличие от многих, я не столь безнадежен, и некоторые нормы иногда пытаюсь хотя бы начать выполнять. На протяжении своей трудовой деятельности я сформулировал для себя минимум правил, позволяющих мне обеспечить комфортабельное рабочее место и набор упражнений-разгрузок, как одни из краеугольных элементов плодотворной работы. В них нет ничего нового, в конце статьи я привожу ссылки на подробные статьи по данному вопросу. А здесь я хочу аккумулировать по наиболее важным пунктам информацию из этих объемных статей и СанНиП.

О СанНиПе

Он НЕ устарел. Последний- 2003 года. Написан достаточно обобщенно, чтобы оставаться актуальным и сегодня по большинству вопросов. Интересно, что в нем прописано:

  1. на одно рабочее место должно быть не менее 6 м2, 20 м3 (получается, потолки- от 3 м). Этим частенько интересуются в форумах.
  2. Места ДОЛЖНЫ быть оборудованы перегородками высотой 1,5-2 м. Надо же, модные "open space'ы" вне правил! Согласен- с некоторых пор у меня аллергия на работу на открытых пространствах.
  3. ДОЛЖНО быть кондиционирование, вентиляция и увлажнитель.
  4. Рабочий стул (кресло) ДОЛЖЕН быть подъемно - поворотным и регулируемым по высоте и углам наклона сиденья и спинки, а также - расстоянию спинки от переднего края сиденья.

И даже набор упражнений прописан, вот например, упражнения для глаз:

  1. Закрыть глаза, сильно напрягая глазные мышцы, на счет 1 - 4, затем раскрыть глаза, расслабив мышцы глаз, посмотреть вдаль на счет 1 - 6. Повторить 4 - 5 раз.
  2. Посмотреть на переносицу и задержать взор на счет 1 - 4. До усталости глаза не доводить. Затем открыть глаза, посмотреть вдаль на счет 1 - 6. Повторить 4 - 5 раз.
  3. Не поворачивая головы, посмотреть направо и зафиксировать взгляд на счет 1 - 4, затем посмотреть вдаль прямо на счет 1 - 6. Аналогичным образом проводятся упражнения, но с фиксацией взгляда влево, вверх и вниз. Повторить 3 - 4 раза.
  4. Перенести взгляд быстро по диагонали: направо вверх - налево вниз, потом прямо вдаль на счет 1 - 6; затем налево вверх направо вниз и посмотреть вдаль на счет 1 - 6. Повторить 4 - 5 раз.

О Тривиальном

  1. Кактусы на системном блоке от излучений от ЭВМ не спасают! :)
  2. Не садитесь работать с грязными руками, например, после жирных пирожков.
  3. Чем современнее, тем, как правило, лучше.
    Не должно быть физического дискомфорта за рабочим местом.
  4. Не забывайте про отдых.

Мои правила

Без соблюдения данных пунктов я на предлагаемую вакансию не соглашаюсь:

  1. Хороший, быстрый компьютер. Сегодня это не дорого по сравнению с зарплатой программиста. Даже в небольших городах, где зарплаты невысокие, стоимость компьютера- максимум 2-3 "провинциальные" зарплаты. Зато быстрый компьютер способствует тому, что называют "работа горит в руках".
  2. Два монитора от 19-20 дюймов. Тоже способствует тому, что "работа горит в руках". Очень удобно на одном экране собрать второстепенные вещи, а на другом- окно IDE.
  3. Не загроможденное место, так что надо ютиться в уголке, пробираясь туда бочком. Это угнетает, утяжеляет "процесс вхождения в поток" (см. Дж. Спольски). В ходе работы постоянно отвлекаешься, чтобы поправить сползший на мышку листик из стопки, при смене сидячей позы переставление клавиатуры сопровождается разгребанием места, подбиранием упавших вещей с пола и т.п.
  4. Кресло обычное, вертящееся, регулируемое, желательно с подлокотниками, но необязательно. Важно, что спинка регулировалась. Ну, за нерегулируемую спинку кресла расплата наступает быстро- пару лет, и вот вы уже сидите на приеме у врача или сетуете друзьям, что спина болит. Когда я первый раз пришел на прием к врачу в районную поликлинику, врач по описанию моих болей догадался: "Вы- программист?" Короче, наступать на грабли, на которые наступило уже куча народа- глупо.
  5. Стол самый простой- вообще без изысков, полочек, тумбочек. Буквально, столешница на ножках. Это мое личное предпочтение.
  6. Достаточно просторная комната, где я буду либо один, либо 2-3 человека. Но никак не 10 человек. Ибо постоянное хождение, обсуждение, звонки телефонов сбивают с мысли. Спасают только наушники, но это не дело- изначально мешать работе никто не должен.
  7. Кондиционер и окна. Не люблю комнаты без окон. Особенно зимой: на работу приходишь затемно, уходишь- уже темно, сидишь в замкнутом помещении. Получается в прямом смысле "света белого не видишь".
  8. Чистый опрятный офис с хорошим санузлом и "бытовкой": кофе попить, поесть и пр.
  9. Интернет без ограничений. Досадно бывает- ищешь по работе информацию, поисковик выдал ссылку с аннотацией, где, согласно краткой аннотации, есть именно то, что надо. А сайт заблокирован политикой фирмы.
  10. Нормальный коллектив.
  11. Достойная зарплата. Чтоб мне не надо было думать о шабашках и о том, как прокормить семью.

Заметьте, я не требую себе телефона, дорогого ремонта офиса (главное, чтоб опрятный был), комнаты отдыха, "корпоративок", дотаций на питание и транспорт.

Моя гигиена

Мои рабочие инструменты- глаза, мозг, руки. И я их берегу:

  1. Глазам я делаю гимнастику уже на автомате каждый час, а то и чаще: поморгать часто, потом потом помассировать глаза пальцами, затем повращать зрачками, и наконец- посмотреть вдаль, отвести на 5 минут взгляд от монитора.
  2. Мозг балую разжижающим извилины чтением журналов о путешествиях, разных странах. И кушаю хорошо. А вы можете хорошо на голодный желудок работать? Я не могу- поесть для меня важно.
  3. А еще я регулярно потягиваюсь, верчу шеей, вращаю кистями рук. Прохаживаюсь по коридору, пью чай- отвлекаюсь от работы, чтоб снять напряжение.

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

Ссылки

СанНиП:
СанНиП, 1996 г.
СанНиП, 1996 г.
СанНиП, 2003 г.

Эргономика и гигиена:
ixbit.com
Сайт врачей-аспирантов
Болезни от компьютера, профилактика и лечение
Журнал "Здоровье детей"

среда, 27 февраля 2008 г.

Дарю идею- рассылка безопасности!

Случилось печальное- я заболел. Грипп, все как положено: температура под 40, вялость и т.п. Лежа в постели я стал просматривать на своем ноутбуке информацию о гриппе: как лечить, что прогнозируют врачи по поводу спада эпидемии. Мне попадались скудные сведения, на официальном сайте Минсоцразвития про грипп я нашел только пресс-релизы. Потом я посмотрел прогноз погоды- как и всю текущую неделю сыро, пасмурно. На курс доллара по привычке уже не смотрел- он мало изменялся в последнее время, однако статья в новостях привлекла мое внимание в курсу- оказывается он сегодня сильно просел. Эх, что ж он раньше не просел- за этот месяц по долларовому кредиту за квартиру я сумму уже внес!

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

Тут температура у меня скакнула с очередной раз к 40 градусам и в голове поплыли мысли, одна краше другой. Если меня волнуют вещи связанные со мною лично, то почему бы не обобщить идею: рассылка безопасности! Как это работает?

Я регистрируюсь и указываю свое географическое местоположение (место проживания, место работы, основные точки по пути из работы домой), плюс дополнительно подписываюсь на рассылки (курсы валют, например). И далее мне отсылаются только те уведомления, которые связанны каким-либо образом со мною. Заметьте, такую информацию уже давно активно собирают социальные сервисы. И опять же, они не используют этот потенциал, например для того, чтобы не напоминать мне о дне рождения одноклассника, с которым я пару раз год назад письмами обменялся. Зачем мне его день рождения? Мне достаточно тех, с которыми я постоянно общаюсь. Мне нужна только самая критически важная информация для меня: дни рождения тех, с кем общаюсь, а не из всего списка знакомых в icq, погода, то только в плане смены циклонов- брать зонт или шубу, курс валют- только в случае 10% изменения за день и т.п.

Но и это еще не все! Мне интересно:

  1. Информация о распространении гриппа, о том, что в моей поликлинике появилась вакцина против гриппа. Может быть даже со ссылками типа "а если вы все же заболели, то..."
  2. Данные о пробках.
  3. Данные о проблемах в метро и на электричках.
  4. Программа ближайших праздников: какие веселья пройдут в моем районе.
  5. Вакансии: только самые отборные, наиболее интересные.
  6. Новости: самые важные.
  7. Экология, аварии.

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

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

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

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

А жаль!

суббота, 23 февраля 2008 г.

"Зачистка" рынка труда как метод конкурентной борьбы

В последнее время я активно занимался поиском работы. Действовал "по всем канонам", описанным в моем блоге. Работу нашел в считанные дни- проблема была больше не в наличии вакансий, а в выборе конкретных предложений, сделанных мне. Оценивая проделанную работу, я отметил интересное наблюдение. Оно субъективное. Не принимайте его за серьезное исследование. Но ответьте мне на вопрос, замечали ли вы сами подобное?

Речь в первую очередь идет о Москве, и, скорее всего, в некоторой степени ситуация реплицируется на крупные областные центры. О нехватке квалифицированных кадров не пишет только ленивый. Как правило, та или иная отрасль от IT-специалистов требует наличия определенных навыков. Например, от банковских программистов часто требуются знания системы Diasoft. Формируемое "облако" требований притягивает к себе специалистов, с определенными знаниями, и, соответственно, как бы отталкивает тех, кто "не в теме". В результате формируется определенная система взаимодействия (по аналогии с экосистемой) между работодателями, IT-специалистами в той или иной области рынка труда. Это не открытая система- есть порог вхождения в эту систему.

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

Итак, мой выбор сделан. Фирмы-конкуренты не получили меня. Если они и далее не будут более гибкими, то найм работников для них будет длительным процессом, тормозящим разработку программного продукта. Либо, за предлагаемые более скромные деньги, они смогут нанять менее квалифицированные кадры. Не думаю, что есть прямая связь между успешностью фирмы, не связанной с разработкой программ (например, банк, торговое предприятие) и кадровой политикой при найме IT-специалиста. Однако не сомневаюсь, что подобная кадровая политика распространяется и на других специалистов предприятия, в том числе, от которых зависит успешность предприятия. Для софтверных компаний связь безусловна- об этом можно почитать у Джоэля Спольски.

Таким образом, получается, что фирмам становиться выгодно завышать зарплаты- 100-200 баксов подкинуть программисту-соискателю фирме не проблема. В замен она получает быстрее, чем конкурент, специалиста. К тому же, вероятнее всего, он будет более квалифицирован. В ситуации кадрового голода конкурент будет посажен на голодный паек. Таким образом, такая небольшая доплата сверх рынка- это вклад в удушение конкурентов, которые будут вынуждены либо подбирать крохи, либо тратиться на обучение своих специалистов с "чистого листа". Т.е., фактически, все сводится к борьбе за дефицитный ресурс.

Повторюсь, что мое наблюдение я не пытаюсь распространить на все области рынка труда. Я заметил такую ситуацию в области IT в Москве. А вы что заметили?

пятница, 8 февраля 2008 г.

Единство двух противоположностей

Зашел я как-то под Новый год на сайт Яндекс.Карты. Случайно увидел. Поигрался с картой метро, попрокладывал маршруты, и тут открыл для себя небольшой сюрприз: сервис мне подсказал, что если я буду ездить на работу по другому маршруту, то съэкономлю 3 минуты. Для меня это важно, т.к. этих самых минут вечно не хватает для пересадки на другой транспорт. Я попробовал- действует! Теперь всегда успеваю на пересадку без напряга! "Какой хороший сервис!"- подумал я. И пробки показывает на карте. Но вот досада. Я уже сросся с igoogle.ru, наставил себе на нем разных виджетов. Мне очень удобно с igoogle.ru и сервисы yandex.ru хочется иметь под рукой. Как быть?

А вы пробовали пользоваться другими поисковиками (rambler.ru, yahoo.com, live.ru, gogo.ru)? Их результаты поиска являются, фактически, мусором. Я не могу этими поисковиками найти, что мне надо. В то время как Яндекс и Гугл демонстрируют поразительную сообразительность. Попробуйте, например, набрать фразу "курс доллара" во всех поисковиках. Если вы еще не знали эту фишку, то вы увидите у Гугла и Яндекса прямое указание курса, ссылка на ЦБ, график изменения курса валюты, а не набор ссылок на третьесортные сайты, на которых упоминаются эти слова. На сегодняшний день для меня выбор однозначен: по миру поиск через google, по рунету- yandex. Такой подход используют многие мои знакомые, т.к. Яндекс по рунету ищет все же лучше Гугла. И опять распутье, опять хочется и того и того в одном флаконе.

Хорошо, Гугл большой и сильный. Есть шансы, что он реализует все достоинства Яндекса и можно будет пользоваться только Гуглом. Как вариант развития событий- это реально? Реализует и метро, и пробки, и афишу, и маркет и т.д. И все русскоязычное, и не просто русскоязычное, а адаптированное под менталитет россиян. Из далекой Америки это сделать весьма затруднительно. Остается открыть офис в России, что Гугл и сделал. Но прибыль российского филиала не сравнима с прибылью Гугла в Америке. Это значит, что никто не будет вдаваться в тонкости менталитета- получите общий сервис, сделанный для всего мира, и не жужжите. Максимум, на что можно рассчитывать- перевод на русский язык. Не будет Гугл делать чисто национальные сервисы типа: Яндекс.Деньги, Катки Москвы, Яндекс.Словари. Это означает, что мои потребности всемогущий Гугл полностью перекрыть не сможет. Пользоваться только Яндексом тоже не получается- компания не настолько крупна и богата как Гугл, чтобы штамповать столько различных сервисов.

И тут взгляд падает на мою страницу igoogle.ru. Набор окошек, в которых можно разместить любой сервис. Вот оно! Будущее за подобными сервисами. Сервисы, которые объединяют достоинства различных порталов. Как сейчас делают метапоисковые машины. Так, чтобы я мог набрать строку поиска и не задумываться, что строка, содержащая русские буквы будет направлена на yandex.ru, а все остальные запросы- на google.ru. Чтобы, как в гаджетах igoogle я мог разместить на одной странице и пробки на дорогах от Яндекса, и Блокнот от Гугла, и новости от РБК. Нынешние гаджеты от Гугла не очень нравятся: размер не изменить, стили разномастные, да и поведение их под разными браузерами несколько отличается, что порой раздражает, да и тормозные они- десяток накидаешь и уже время загрузки ощутимо возрастает. Так что же мне,такому привередливому, хотелось бы увидеть?

  1. Виджеты как в Vista. Т.е. не web-интерфейс. Чтобы пошустрее были, да и единство стиля чтобы обеспечить.
  2. Чтобы настройки сохранялись где-то на сервере и кэшировались локально. Тогда можно на другом компьютере получить все свои виджеты, со всеми настройками.
  3. Чтобы виджеты можно было развернуть в полноценное приложение. Например, в маленьком окошке показывается прогноз погоды, а когда разворачиваю виджет, то окрывается приложение с подробной информацией о погоде: карты с циклонами, изотермами, интересные факты о погоде, фазы Луны и т.п. И почему-то мне не хочется, чтобы открывалось окно браузера, а хочется, чтобы это было именно приложение. Как Google Earth.

Вот тогда и можно будет объединить сервисы от различных производителей под "одной крышей"! Вот тогда и заживем!

Послесловие.

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

понедельник, 28 января 2008 г.

Поучительный пример неудачной модели торговли

Дернул меня черт в предновогодние дни пойти в магазин купить сканер. Название магазина я не скажу, но многие московские ITшники без труда его узнают по описанию. Магазин гордо себя относит к гипермаркетам, и известен не традиционным способом организации процесса покупок. Чтобы купить что-то в нем вы должны:

  1. Если хотите ознакомиться с товаром пройти в отдельный зал, и дождаться там пока его вам не вынесут, и не дадут повертеть в руках.
  2. Если вы четко знаете, что хотите купить, то этап 1 пропускаем.
  3. Идете к аппарату и нажав на нем мышкой кнопку "Распечатать" получаете квиток с номером заказа.
  4. Идете в зал, где установлены компьютеры. Ищите свободный, который не завис (а таковых там минимум процентов 30%), который не выключен (таких тоже много) и приступаете к фомированию заказа. Тут для живописности упомяну о мерзких грязных мышах, пыльных, никогда не вытираемых мониторах и об отсутствии клавиатуры (все через мышку делается, на экране есть виртуальная клавиатура) Ввели свой номер, набрали заказ, получили сумму. Идете в кассы. Например, автоматические.
  5. Там опять же ищите, что работает (работающего примерно 10%), вводите заказ с помощью мерзкой грязной мыши, вставляете купюры в купюроприемник.
  6. Автоматическая касса сдачи не дает, поэтому за сдачей вы идете в другую кассу, обычную, где уже живой человек выдает вам сдачу.
  7. Потом ваш заказ автоматически отправляется на комплектование, а вы на большом экране смотрите свой номер. Как только появился, то идете к указанной стойке, где вам выдают товар, оформляют покупку.
  8. Идете к охраннику, чтобы он расписался на чеке, чтобы вас выпустили.

Все, вы свободны.

А, да! Забыл еще сказать, что в туалет вход платный, через турникет. Если точной суммы нет, то рядом стоит автомат для размена денег. У вас еще не пошла голова кругом от обилия всех этих автоматов? Магазин расположен в огромном, видимо, бывшем цеху, и все пункты (набор заказа, касса, выдача) расположены в разных концах помещения. Внутри все пыльно, покосившиеся выцветшие рекламные плакаты, столовая в чисто совковом стиле. Декларированного там бесплатного WiFi я не обнаружил.

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

В обычные дни данная модель работает шатко-валко, но в рождественские праздники система просто не выдержала нагрузки. Каждая точка (квиток, заказ, оплата, ожидание, выдача) превратилась в "узкое горлышко". Везде приходилось стоять в очереди. В самом конце, на выдаче хвост очереди был просто умопомрачительным- 4-5 часов стояния в очереди. Уже перед моим подходом к стойке зависла БД в магазине кладовщики ушли на полчаса пить чай, пока БД ремонтируют. В итоге, я вышел таки оттуда через 6 часов со сканером в руках, с проклятиями в мыслях и со словами: "Ноги моей здесь больше не будет!" Я был не один такой. Вся очередь гудела и возмущалась. Это 100% провал. Рождественский пик продаж не использован был явно на всю катушку- многие, видя очереди, с порога разворачивались. Используемая модель торговли давала сбои, образовывались простои из-за поломок техники и нечеткого разрешения конфликтных ситуаций (если человек заявлял, что заказывал не то, то на разбор ситуации уходило много времени, притом очередь стояла). Разберем на этом наглядном примере ошибки организации бизнес-процесса и, в частности, автоматизации процессов.

  1. Явно не учтен такой факт, что зачастую традиционный "ручной" бизнес-процесс при попытке его автоматизировать "в лоб", т.е. один к одному перенося "ручные" процессы на "автоматические" никакой выгоды не дает. Автоматизация открывает новые возможности для бизнеса, которые и надо использовать, а не копировать "ручные" процессы. Например, почему бы не сделать на терминалах выбора товара сразу и оплату его по банковской карте, web money, Яндекс.Деньги? Т.е. без всяких квитков, напрямую подхожу к терминалу, формирую заказ, оплачиваю его безналичным способом, мне распечатывается тут же квитанция на получение товара, система выдает мне примерное время ожидания, я жду и иду на склад- получаю товар. Если оплата наличными, то иду в кассу сначала. Получается максимум 3 этапа, вместо 7.
  2. Система совершенно не протестирована на работу под нагрузкой. Как результат- в пик продаж система начала давать сбои, что, несомненно привело к потерям денег.
  3. В автоматизированной системе отсутствовало резервирование как класс! Магазин, который высоко автоматизирован, и не имеет резервных систем! Т.е. любой сбой, компьютерный вирус, отключение электроэнергии, прорыв трубы отопления в серверной приведет к остановке торговли, а значит к прямым потерям денег.
  4. При автоматизации потеряны ряд методов "офлайной" торговли. Например, часто при покупке одного товара рядом на полках располагают сопутствующие товары (типа "пиво- сухарики"). При формировании заказа отсутствует подсказка вида "С этим товаром часто покупают то-то, то-то...". Отсутствует подборка статей о товаре с других сайтов, форумы и прочее.
  5. Юзабельность близкая к нулю. Набор букв на виртуальной клавиатуре мышью вывело из себя и меня, весьма спокойного в жизни человека (поверьте, меня можно использовать как мерило спокойствия :) ).
  6. Дружественность нулевая. Я пришел покупать, а с меня еще и деньги за туалет берут. Притом, грязный и забитый. Пример: Макдональдс, Икея- постоянно чистят и бесплатно. Столовая совковая, куча неисправных терминалов.
  7. Уважение к клиенту- нуль. Пыль, грязь- общий вид какой-то разрухи, бестолковости.
  8. Автоматизация, "обездушивание" процесса не означает, что и к клиенту тоже можно относиться бездушно. Наоборот все- чем больше автоматизация, тем более внимательно и дружелюбно надо относиться к клиенту. Тут примером может послужить печальная история бренда "Альфа-экспресс".
  9. Использованы собственные решения- я бы часть системы отдал на аутсорсинг. Например, купил бы систему поиска товара, описания и выбора у Яндекса. У него есть очень удачный и мною любимый Яндекс.Маркет делающий все это гораздо лучше чем их система. Оплату- assist.ru.

Мое резюме. Магазин держится в основном за счет удачного месторасположения. Будь они расположены за пределами МКАД, как Мега, они бы не выжили. Низкое, совковое качество обслуживания, крайне неудачная система автоматизации, вообще не учитывающая никакого опыта... Ну что тут еще сказать?!