Дистанционное обучение

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

Ключевой проблемой в этом тренде является то, что online-обучение с помощью ИТ- технологий слепо копирует offline’новые технологии обучения. Потенциал ИТ при таком подходе, фактически, не задействован. Проблема усугубляется тем, что учителя не знают о возможностях ИТ, а ИТшники не знают как разрабатывать новые методики преподавания. Типичный сценарий “разговора слепого с глухим”. Что в результате получается?

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

И нигде: ни у нас, ни за границей чего-то нового, прорывного в области обучения не видно. Лучше книги с тетрадью не придумано еще ничего. Поэтому, пусть “умные дядьки” умничают и дальше, а тому, кто хочет заняться самообучением настоятельно рекомендую учиться традиционными способами: книга, тетрадь. Если надо, то: репетитор, заочное обучение, курсы.

Полный P&P

Пятого октября прошла конференция Microsoft Patterns and Practices Summit Russia 2012 для архитекторов программных систем и руководителей. Докладчики были из Редмонда, из группы “Patterns and Practices”, и из российского офиса компании.

Я сначала распланировал посещение секций так, чтобы по Windows 8 больше информации получить, но потом понял, что наши “евангелисты” от MS больше, чем я уже знаю, не скажут. Быстро переориентировался- и, вуаля- выудил кое-что полезное из выступлений.

Первое. Запомнилось (даже записал и хочу поиграться с этим) организация вложенных вызовов в линейную цепочку: start(a).then(b).then(c).done;. Вместо

if (a(b(c))) { done; },

где a, b, c- могут быть анонимные функции.

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

Второе. В Window 8 в ресурсы приложения одну и ту же картинку можно будет записать с разным разрешением и размером. ОС сама будет вытаскивать и отображать ту из картинок, которая наиболее подходит для данного монитора (с учетом его размеров и разрешения).

Третье. Какую они удобную локализацию сделали- закачаешься! Может это и раньше было, я про это на конференции узнал. Просто создаете папочки вида “en-en”, “ru-ru” и т.д. и кладете туда файлы с ресурсами в которых пишите что-то вроде:

button1.name = …

button.width = …

button.font.style = …

Еще к этому верификацию прикрутить, чтобы проверять к каким текстам, заголовкам сделаны переводы, а к каким- нет, то вообще “бомба”.

Четвертое. Мысль вроде простая, но я нигде (Word, Visio, AutoCAD и т.д.) пока не видел реализации. Зачем на мелком масштабе пытаться отрисовывать маленькие элементы? Там же ничего уже не разглядеть. Куда эффективней заменять изображение более крупными информационными блоками с большими подписями. Ткнул в блок мышкой- масштаб увеличился, блок “раскрылся”.

И еще. Явно об этом нигде не говорится- народ только по форумам судачит. Но я лично на конференции почувствовал, что предпочтение отдается JavaScript. C# вроде как не задвигают, то существенно меньше о нем говорят. Неужто опять будет эпопея с очередной сменой мейнстримового языка? Так что я предупредил- а вы держите “ушки востро”.

Потом, конечно, Вы сами сможете посмотреть выступления на www.techdays.ru, но я вам скажу, что через экран монитора вы упустите “ауру” тусовки- на уровне эмоций, жестов очень многое передается. А это редко в кадр попадает, а если и попадает, то как-то “не ловится” мозгом. Ну, и приятно иногда взять докладчика “за пуговичку” и из “первых уст” получить информацию.

По организации конференции:

1. Очень понравилось. Хорошо все продумано, четко сработано- ну, просто мастера.
2. Для уровня архитекторов программных систем откровенно слабовато. Хотя, судя по уровню вопросов из зала, может это я слишком многого хочу.

Развернутый комментарий к статье “Где мы?”

Статья: http://trv-science.ru/2012/07/17/gde-my/

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

В мою бытность преподавателем в ВУЗе, где я работал, уже такой эксперимент был проведен. Ввели рейтинг, где публикациям отдали повышенный коэффициент. Думаете, публикаций стало больше? Да. Их стало больше. В цифрах на бумаге, а не реальных статьей. Все очень просто. Преподаватели стали договариваться друг с другом о соавторстве: я включу тебя в соавторы моей статьи, а ты меня включи в соавторы твоей статьи. В результате, нам обоим в зачет пойдёт по две публикации. Все в выигрыше. Норматив выполнен “на ровном месте”.

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

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

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

Да и с первоочередными мерами совершенно фантазировать не надо. Практически все статьи по данной проблеме говорят об одном и том же: достойная, высокая зарплата. Буквально, очень высокая. Ну, допустим, 50-70 тысяч долларов в год чистыми на руки всему преподавательскому составу для любого провинциального ВУЗа. Это первый шаг. Про остальные шаги и говорить не хочу, т.к. и этот первый шаг десятилетиями не делается.

На словах высокие чиновники говорят об увеличении финансирования, а на самом деле ВУЗы ходят сокращать. Без всякой конкурентной борьбы между ВУЗами, административными мерами объединить и/или закрыть. Чтобы уменьшить расходы на содержание. И все. Вот такая вам наука.

Что почитать

Решил поделиться мнением о  том, что прочел в последнее время.

1. “Совершенный код”, С. Макконелл. Книга хороша для программистов с опытом работы 1-2 года. Совсем уж начинающим программистам голову этим забивать не стоит- им надо научиться базовым вещам, а уж потом Макконелл. Опытным программистам книга по большей части будет бесполезна- перечисленные в ней приёмы программирования тривиальны и быстро осваиваются в первые годы программирования. Так что, если вы 1-2 года уже программируете- берите, читайте- много нового и интересного узнаете.
2. “Психбольница в руках пациентов”, Алан Купер. Плохая книга. Может, проектировщикам она понятна и нравится, но программистам эта книга точно не нужна. Раздражительно много “воды”, набор тривиальных мыслей и ни одной методики решения перечисленных в книге проблем.
3. Журнал MSDN Magazine. Да, в нем большинство статей о технологиях Microsoft. Но, кроме того, в каждом номере есть статьи, посвященные алгоритмам, тенденциям. Материал подается очень четко, без “воды”, профессионально, с хорошим переводом. Например, оцените такие статьи:
1. Использование Windows Azure Service Bus для… вещей! Вместо Azure используйте любое другое облако. Оцените саму идею- подключение приборов в “облако”.
2. Bacterial Foraging Optimization. Забавнейшая штука. И для кругозора полезно.
3. Ant Colony Optimization. Муравьиный алгоритм.

Заметки о форуме Microsoft Innovation Day 2011

Ссылка на сайт форума: http://www.microsoft.com/ru/ru/isv/forum/innovationday.aspx.

Форум состоял из двух частей: для технарей и для руководителей. Подробности, видео смотрите на сайте. Я по пунктам перечислю свое ощущение от увиденного.

1. Очень интересно свел вместе разнородные данные выступающий от IDC. Привел график по численности населения- видно, что в перестроечные времена рождаемость резко упала (“на глазок”- раза в два). Теперь это поколение подросло, и к 2020 году должно заменить на рынке труда уходящее на пенсию старшее поколение. Вот и получается, что, фактически, не кем заменять будущих пенсионеров! Кадры станут дефицитным и, видимо, дорогим ресурсом. Следующий график- рост численности серверов. Их надо кому-то обслуживать- а не кому! Т.е. проблема высококвалифицированных кадров к 2020 году будет просто “аховая”: потребности растут, а специалистов становится все меньше и меньше. Понимаете теперь почему хотят поднять пенсионный возраст в правительстве? Но меня, как программиста, этот доклад успокоил: цена моей работы возрастет, и работы будет много.
2. Оказывается по данным NIST их MS SQL Server является самым безопасным: SQL Server- 49 уязвимостей; Oracle- ~300 уязвимостей; DB2-121; MySQL- 98. За последние 6 месяцев уязвимостей не найдено вообще. Вау! NIST- это вам “не хухры-мухры”. Уважаю.
3. Один из недостатков “облаков”- это привязка софта к конкретному “облаку”. Перепрыгнуть в другое “облако” очень тяжело. Ситуация, как бы, выгодная для Microsoft. Но, тем не менее, Дмитрий Мартынов поднял тему миграции между “облаками”, а также обратной миграции из “облака” к клиент-серверу или локальному решению. Удивила такая готовность предложить обратную миграцию.
4. Не знал про Azure, что их “облако” умеет работать в 3 режимах. Можно вообще образ системы залить, и он там будет “раскатываться” по серверам. Т.е., реально, можно любое ПО таким образом в “облако” засунуть. Грубо, но можно. Молодцы, круто сделали. И про миграцию подумали, и про обратную миграцию. С ходу и не подкопаешься.
5. Миграция- то ладно, а вот непривычно было, что сотрудники Microsoft не только хвалят, но и про недостатки своих продуктов говорят. Смело так говорят: “Как было можно сделать…! Я возмущался, пинал их…. Обещают сделать.” В таком духе. А я-то думал, что у них с этим строго- никакого негатива и точка. Это очень хорошо, что про недостатки рассказывают тоже- когда сам, лично, на них напарываешься, то это создает гораздо более сильный негатив, чем если просто послушать про это на форуме.
6. Я привык, что главные докладчики- директора, руководители- после выступления сразу сматываются. А тут, смотрю, Ложечкин сидел всю “пленарку”. Хотя после своего первого 15-минутного доклада мог и уйти. Непривычно.
7. Если на “пленарке” сидели все вместе- и программисты, и руководители, то потом разбились по секциям. И прямо до смешного стала видна разительная разница во внешнем виде. На секции для технарей сидели люди в свитерах, рубашках, брюках, с длинными волосами- свободный стиль одежды. На секции для руководителей народ сидел в пиджаках, при галстуках, весь из себя чинный- формальнее некуда.

В целом, все, о чем говорили докладчики, давно уже опубликовано. Как источник информации форум скучен, не интересен и бесполезен. Но вот там, в программке есть последний пунктик: фуршет на 1,5 часа. Это неформальное общение, заведение знакомств. Т.е., как одну из задач форума, можно указать стимулирование создания и поддержания экосистемы вокруг продуктов компании. Чтобы люди встречались, обсуждали, знакомились, сотрудничали, чтобы их сотрудничество порождало синергетических эффект, усиливающий экосистему вокруг продуктов Microsoft. Наверное как-то так. А еще, это информационный повод, чтобы о Microsoft писали СМИ. С этих позиций организация форума имеет смысл.

Агентство "Мы ищем таланты"

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

Зачем это нужно?

Возьмем в качестве примера фонд "Сколково". У фонда не много проектов на сегодняшний день (апрель 2011 года). Поток их явно падает. Это естественный процесс, связанный с тем, что прошел первоначальный интерес к проекту. С другой стороны, все используемые на сегодняшний день способы привлечения стартапов можно отнести к пассивным. Т.е. фонд, выставив условия, ждет, когда к нему придут стартапы. Тут надо заметить, что частные инвесторы действуют гибче, устраивая выездные сессии. “Топтаться на этой поляне” всем уже тесно. “Сливки” сняты и нужно делать следующий ход- самим заняться активным поиском талантов и созданием вокруг них стартапа.

Почему это надо делать?

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

Как это сделать?

1. Сформировать пул потенциальных инвесторов. Например, гранты на исследования уже выдаются компанией Microsoft. Выразили заинтересованность в сотрудничестве с фондом многие крупные компании. Такая работа уже проводится- с “нуля” делать ничего не придется.
2. В ВУЗами фонд подписаны меморандумы о сотрудничестве. В рамках этих меморандумов следует договориться о получении в электронном виде тезисов докладов с научных конференций. Тут же можно подумать о формировании базы данных и публикации на сайте фонда этих тезисов, чтобы инвесторы могли сами “попастись” на сайте в поиске интересных идей. Это будет способствовать созданию комьюнити вокруг фонда.
3. Доклады могут делаться как самими учеными, так и студентами, у которых ученый является руководителем проекта. Интересные с точки зрения доклады отбирать для более детального анализа.
4. По отобранным докладам провести детальный анализ (включая выезд к ученому и устное обсуждение деталей), подготовив аналитический отчет. В отчете отразить степень готовности исследования к коммерциализации и примерную область применения.
5. Из пула инвесторов выбрать потенциально заинтересованных, которым предложить выделить грант на исследование с последующей коммерциализацией. Фонд может выступать как соинвестор.
6. Антрепренёр, т.е. человек который нашел ученого, свел его с инвестором и добился инвестирования получает вознаграждение.

Достоинства моего предложения

1. Данный механизм отлично “ложится” на деятельность фонда и укладывается в уже существующие договоренности между фондом, ВУЗами, инвесторами.
2. Поиск талантов переходит на качественно новую стадию- он становится активным. Вместо пассивного ожидания, когда сам исследователь со своей разработкой придет в фонд за финансированием, фонд сам его ищет и предлагает ему все готовое. Исследователю останется только подпись в договоре под галочкой поставить и получить деньги на свой счет для исследований. В то время как сейчас он должен проявить “коммерческую жилку”, отвлечься от исследований: зарегистрировать юридическое лицо, найти иностранного участника (требование фонда), подать заявку в фонд и пройти все формальные процедуры оформления.
3. Формирование базы данных исследовательских проектов будет способствовать формированию “Сколковской общины”, создание которой декларируется фондом.
4. Это всем выгодный подход: компании-инвесторы получают информацию по исследованиями, которые могут заинтересовать их R&D подразделения; фонд выполняет свою миссию, существенно наращивая свой портфель проектов, антрепренёр получает свой процент от сделки. Полный “win-win”, как говорится.
5. Сам план прост, и его возможно в течение нескольких месяцев начать реализовывать.

Грезы о будущем сквозь дым пожаров

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

Первая история.
В университете нам философию преподавал молодой очень умный и талантливый преподаватель. Речь шла об Абсолюте. Он говорил ярко и в перерыве обсуждение было продолжено. Мы, как технари, попросили "мяса"- на примере показать что есть Абсолют? Уж не признает ли философия существование Бога, как воплощение этого самого Абсолюта?
-Конечно же, нет! - воскликнул учитель.
-Например, что можно считать Абсолютом? - спросили мы его, не улавливая суть вопроса.
-Ну, например, цвет- красный мы воспринимаем как красный.
-Нет, это не Абсолют! - ответили мы - цвет красный только потому, что наш мозг так обрабатывает длину волны 620-740 нанометров. Дальтоники, например, его не так воспринимают.
Задумался он. А мы продолжили мысль:
-Абсолюта не бывает. Все в мире относительно: абсолютная температура 0 градусов по Кельвину не достижима- всегда будет 0.1 градус или 0.0001 градус. Но не чистый, абсолютный нуль. Не бывает абсолютной пустоты даже в глубоком космосе - Абсолюта нет, все относительно.
Возразить этому он не смог.

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

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

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

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

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

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

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

Итак, что-то похожее сегодня уже делается: пересадка органов; анализ ДНК детей, еще находящихся в утробе; искусственные руки, ноги, сердце. Пока что это весьма несовершенные разработки. Вы бы хотели заметить свою настоящую руку на искусственную? А сердце? Боже упаси! Искусственная рука не чувствительная, некрасивая, не такая же гибкая- родную руку ей не заменить. А про сердце уж помолчим. Но это все примеры не совсем ИТшные. Все же меня читают больше ИТ-специалисты, и будет более понятен пример с мозгом. Ведь именно компьютер часто ставят на противоположном конце аналогии с мозгом. Хорошо, тогда попытайтесь догадаться, о чем следующие несколько предложений.

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

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

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

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

Пример второй.
Несмотря на то, что все больше людей выходят в интернет через iPhone, iPad, где есть технология мультитача, я не встречал пока адаптированных под мультач веб-сайтов. Про наших российских веб-программистов и дизайнеров я вообще промолчу- они до сих пор клепают странички а-ля web 2.0, считая это вершиной прогресса. Про возможности, открывающиеся при использовании мультитача и того же акселерометра в вебе, вроде пока никто не задумался. Да это я еще слишком круто взял- тут древнюю технологию флэша от adobe только-только вот начали использовать не только в рекламных баннерах. Совсем недавно в почте mail.ru я заметил, что при переходе между письмами страничка уже не перегружается, а мигая флэшовской ромашкой, подгружает письма на ту же страничку. Круто! Всего-то лет десять технологии исполнилось, и вот, уже внедрили. Так глядишь, лет через 30 и html5 увидим на страницах mail.ru. Ладно, чего это я на mail.ru накинулся? Они только как пример- у других не лучше.
Ну, есть смелые стартаперы и инвесторы, готовые поразить нас сногшибательными интерфейсами, умеющими и на компьютере и на смартфоне великолепно подать нам информацию (почта, поиск, соц. сети)?

Пример третий.
Сегодня из-за границы к нам приходят удивительные технологии, показывающие то, что инженерная мысль в иностранных компаниях идет по пути совершенствования человеко-машинных интерфейсов.
Например, в офисном пакете от Microsoft лента Ribon. В разработке этого интерфейса проводилось широкое тестирование, изучались сценарии работы пользователя. Т.е. это не просто инженерная разработка, это результат большого междисциплинарного исследования.
3D-телевидение, ранее существовали только 3D-кинотеатры. Теперь 3D доступно каждому дома: уже и у нас продаются 3D-телевизоры. Трехмерное телевидение стало возможным благодаря исследованию биологов, исследовавших устройство человеческого зрения. Тоже междисциплинарный подход.
Технология распознавания жестов MS Kinnect. Более простой аналог существовал уже у Nintendo. Теперь ждем к Новому году в продаже и эту великолепную технологию. А представляете себе игру на 3D-экране + Kinnect? Да тут уже до "Матрицы" недалеко!
Про iPad, iPhone с их мультитачем, акселерометром, компасом и прочими технологиями и говорить нечего- и так все понятно.

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

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

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

Еще о молодых перспективных специалистах и обо мне

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

Первый пример. Без малого 10 лет назад под большой проект писал я ПО. В одиночку, быстрыми темпами. Потом еще несколько лет были мелкие доделки, версия программ доросла до 3.5. И, в общем, все- работало годами без переделок. Я уже уволился оттуда лет пять назад, но, общаясь со знакомыми, периодически интересовался судьбой своих программ. Новые программисты, молодые и горячие, приходили, "махали шашкой": "Кто писал ЭТО?! Да мы сейчас за три дня перепишем..." И далее звучал список самых последних крутых технологий программирования, с помощью которых собирались переписать. Я спрашивал, а что не устраивает? В основном, только то, что использовалась БД Interbase, а не MS SQL Server, что доступ к базе был через специализированные компоненты доступа, а не через ADO, что пользовательский интерфейс был построен на базе стандартных компонент, а не на DevExpress. Когда молодые программисты брезгливо морщили носики от всего этого "старья", то они не учитывали время, когда это все писалось. В конце девяностых MS SQL Server был совсем другим- его Microsoft только купила у Sybase и по функционалу и производительности тот же Interbase делал его как сосунка, DevExpress просто не существовало и т.д. Функциональность устраивала, код не был "лапшой" (все примитивно- обычное накидывание компонент на форму и простая логикой). Реально, желание переписать ПО было не более, чем амбицией молодых перспективных специалистов (см. п. 2 исходной статьи). Я тогда еще, пару лет назад сказал, что ничего из этого не выйдет- там не то, что 3 дня, там реально минимум на год было работы, а с учетом того, что надо было, помимо переписывания, еще и текущую работу выполнять, то и все 3 года занял бы процесс переписывания. Да и смысла не было в этом совсем.

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

А мое ПО уже десятый год, без существенных модификаций, продолжает работает. С одной стороны приятно, и я испытываю гордость за созданное мною ПО, но с другой-сколько ж ему, горемычному, еще пахать? Давно пора б заменить другим, более современных ПО, уже все разумные сроки эксплуатации вышли. Представьте себе БД, с которой молодые специалисты не хотят связываться из-за брезгливости, работает в автономном режиме уже десяток лет! На время моего ухода там уже было 1,5 млн. записей, а теперь и все 5 млн. будет- ее же никто не чистит, не обслуживает... а только ухудшает.

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

Занавес. Минута молчания.

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

Вот и сейчас я пишу код, пока не понимая до конца зачем я именно такой вариант выбрал. Я просто чувствую, что так правильней, и знаю, что я не ошибаюсь в своей интуиции.

Гляжу на код более молодых коллег: он правильный, логичный, но... он ошибочный. Раньше я старался подобрать слова, чтобы объяснить, почему лучше сделать по-другому. Это очень трудно сделать потому, что надо суметь объяснить невидимые в рамках нынешнего задания вещи. То, что возникнет через месяц, через год и потребует полного переписывания ныне кажущегося логичным кода. Теперь я уже просто говорю: "Сделай так, приятель!" Без объяснений- придет время, и этот приятель поймет, что я был прав.

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

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

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

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

Молот ненависти

Ученье- свет, а неученье- тьма.

Для быстрого старта в мире ИТ я давал рекомендации. Однако, лет через пять успешного труда и продвижения по карьерной лестнице, многие почувствуют ЭТО. Сначала не обратят внимания, потом ЭТО вызовет раздражение, потом ненависть, уныние, депрессию. Затем в каком-либо программистском форуме появится вопрос: "Что делать, куда двигаться дальше?" Да, все верно, ЭТО он- "стеклянный потолок". Это когда вы чувствуете, что дальнейшие усилия для продвижения по карьерной лестнице, для повышения зарплаты приносят все меньше и меньше денег. В конечном итоге, вы понимаете, что можно все 24 часа работать, и при этом, реально, существенного улучшения материальных условий у вас не произойдет. Теряется смысл дальше ударно работать, быть инициативным, креативным. Блеск в глазах тускнеет, пульс замедляется… Мозг сверлит вопрос: «Это конец»?

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

Конечно, всегда есть крайние случаи: кто-то решает радикально сменить профессию, и уходит в менеджеры. Однако все менеджерами и руководителями стать не смогут– хотя бы потому, что всем мест не хватит. Так что же делать остальным?

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

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

1. Пожалуй, как основное, я выделил бы совершенствование знаний в выбранной области деятельности. Научитесь не просто программировать, а узнайте тонкости компилятора. Изучите технологическую основу, на базе которой разработан компилятор и используемые вами в работе библиотеки. Ведь используемые технологии определяются назначением языка программирования, а все вместе формирует область применения. В этой области применения использование вашего инструментария будет наиболее эффективным, а четкое знание назначения, области применения, технологий позволит точно определять свои возможности, правильно позиционироваться на рынке труда. К тому же это отучит вас от глупой мысли: «Мне все равно, на чем программировать - я выбираю тот инструмент, на котором мне удобно решить задачу». Чтобы понять, почему это- глупость несусветная,  прочтите эту статью (п. 6).

2. Учите английский язык. Знание языка открывает широкие перспективы поездить, поработать по всему миру. Кроме того, вы без труда сможете читать англоязычные профессиональные форумы, читать документацию из первоисточников. Это реальное,  конкурентное преимущество на рынке труда. Даже если вас не привлекает перспектива работы за границей, то у вас появляется возможность трудоустройства в российские представительства иностранных компаний. Там, как правило, требуется обязательно знать английский язык. Учтите к тому же, что зарплата в представительствах повыше будет, чем в среднем по рынку. Как видите, знание языка- сильнейший удар по «стеклянному потолку».

3. Научитесь усидчивости. Мой научный руководитель в университете постоянно сетовал, что нынешняя молодежь не умеет читать. Это правда. Очень важно научится читать внимательно, вдумчиво. Выжимая по максимуму информацию из каждой строчки. К своему стыду, я вспомнил свою историю на заре трудовой карьеры. У меня была английская документация по микросхеме. Я, в соответствии с ней, программировал микросхему, мне возвращался статус «ОК», но ничего не работало. Микросхема редкая, в России я, похоже, был первым, кто с ней работал – я на уши поставил форумы, поднял все свои связи. Никто не мог мне помочь. Через ПОЛГОДА я таки разобрал документацию. Вся проблема заключалась в одном слове. Я не мог его перевести. Оно было очень маленькое, короткое и я придавал мало ему внимания, считая, что это какая-то частица или междометие. Я ПОЛГОДА КАЖДЫЙ день бился с этой микросхемой, но как только понял смысл этого слова, я в этот же день смог ее запустить.

4. Учитесь понимать других людей. Вдумывайтесь в то, что говорят вам. Приведу в качестве примера привычку отвечать буквально на каждое предложение оппоненту в дискуссии на форумах. Весь текст разбивается на цитаты, и по каждой цитате пишется ответ, прямо вот как сверху вниз читается текст, так сразу пишется ответ. При этом текст не воспринимается целостно, вырванные из контекста цитаты становятся бессмысленными и часто даже противоречащими друг другу. Дочитайте мысль оппонента до конца. Обдумайте и напишите целостный ответ, не рванный на цитаты. Сохраните в черновиках. Вернитесь к ответу через часик-другой. В 90% случаев вы поймете, что ответили чушь, и, что вообще лучше не отвечать. И, если после этого всего равно вы увидели, что дали достойный ответ, то тогда и отправляйте его оппоненту. В своем блоге я очень часто сталкиваюсь с этим. Вот и с предыдущей статьей про MS Dynamics так получилось. Ее прочли несколько сотен человек, но нашлись несколько человек, которые не поняли ее мысли, оценив ее по шаблону. Идея статьи в том, что я, как дилетант, взглянул на продукт и сказал, что мне там непонятно и помечтал о том, как бы я его развивал (я так и написал в статье «пофантазируем»). Однако, это было воспринято как неквалифицированная критика ПО и вызвало резкую реакцию. Пока не раздулся излишний флейм, я быстренько еще раз жирным буквами разжевал смысл статьи. Я, в свою очередь, буду стараться попроще, пояснее доносить свои мысли, но все же и комментарии мне желательно оставлять подумавши.

5. Последнее, что бы я посоветовал для общего развития – изучайте прикладную математику. Алгоритмы. Читайте Кнута. Это из разряда вечных ценностей.

А теперь, резюмируя все выше сказанное, посмотрите, как заманчиво выглядит все это: «Специалист в своей области. Знающий досконально соответствующие стандарты и технологии. Внимательный и тщательный. Имеющий широкую алгоритмическую подготовку. Бегло говорящий на английском языке.» Даже такое абстрактное описание у работодателя уже вызовет слюнки. А вы, вооруженные собранными воедино перечисленными знаниями, без труда пробьете, как молотом, этот ненавистный «стеклянный потолок».

Багаж знаний. Часть 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.

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

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

Багаж знаний. Часть 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.

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

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

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

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

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

Наблюдение 1

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

Наблюдение 2

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

Наблюдение 3

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

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

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

Наблюдение 4

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

Наблюдение 5

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