Блог Юрия Акопова

"Не нравится" не значит "невыгодно"

2008-11-19T21:44:00.005+03:00

Довольно интересный пост на мою любимую тему о том, как ИТ относится к инженерии (заслуживают внимания также ссылки на обсуждения в нём по смежным вопросам).

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

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

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

Шарообразный ресурс в вакууме

2008-11-17T15:01:00.005+03:00

При планировании проекта довольно часто используются характеристики частичной занятости ресурса ("загружен на 50%").

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

Такое упрощение, однако, многие начинают понимать буквально, то есть в понимании менеджера проекта сотрудник не занят 2 часа задачей А, а 6 часов - задачей B, а занят в один и тот же рабочий день на всём его протяжении на 25% задачей A и на 75% задачей B одновременно.

Это, в свою очередь, приводит, например, к тому, что от сотрудника могут потребовать текущих результатов выполнения задачи A в середине дня - ведь прошло уже 4 часа, из которых час (25%) он должен был, по идее, потратить на это задание. Однако работнику могло показаться более логичным запланировать более тяжёлую и рискованную задачу на первые 6 часов (чтобы в случае чего, иметь резерв на доводку), а более простой задаче A уделить последние два часа. Соответственно, результаты по этому заданию он сможет продемонстрировать только через 8 рабочих часов.

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

Солнце, воздух и вода

2008-11-16T23:37:00.005+03:00

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

При влажности же 80% и температуре около 30°C заражение практически невозможно.

Mimic-Me

2008-11-07T13:59:00.012+03:00

Мимикрирующие под муравьёв пауки:

[источник и другие фотографии]

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

Upd. Под подписью "Ant" на фото тоже паук.

Prince of Persia

2008-10-23T22:14:00.002+04:00

То самое видео (1985 год):

Сама игра вышла в 1989-ом.

"Заранее обречённый на полнейший провал"

2008-10-21T13:34:00.002+04:00

UD2 - undefined instruction

Разработка и творчество

2008-10-18T19:18:00.005+04:00

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

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

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

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

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

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

LEGO Jonah

2008-10-13T16:36:00.008+04:00

Диагностический робот глотается пациентом по частям и сам собирается в желудке.

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

Электронное правительство

2008-10-11T02:07:00.002+04:00

Примеры решений по раскрытию информации государством

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

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

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

Макет или прототип?

2008-09-25T11:16:00.005+04:00

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

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

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

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

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

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

Caesar's to Caesar

2008-09-21T11:39:00.002+04:00

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

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

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

"What I aspired to be and was not, comforts me"

2008-09-17T10:29:00.006+04:00

Вчера побывал по случаю на семинаре Toshio Obi (надо сказать, сам он говорил немного и не слишком оригинально, и большего внимания заслуживало выступление его коллеги Taro Kamioka).

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

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

В качестве одного из подтверждений был приведёт следующий пример - в Японии, по словам докладчиков, около половины ИТ-директоров не имели отношения к ИТ вообще в ходе своей карьеры, т.е. являются абстрактными менеджерами, брошенными "на всё это компьютерное хозяйство". Одновременно велико число японских компаний, где CIO является де-факто вторым лицом в правлении, которому отчитываются (technology), CFO (finance), CAO (asset), CKO (knowledge). Мне это показалось довольно странным, т.к. на мой взгляд пример не подтверждает сказанное, а скорее его опровергает - если ему верить, компетенции в бизнесе ИТ-директору действительно нужны, но берутся эти компетенции из бизнеса же, а не из ИТ.

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

По ходу обсуждения мельком вспомнили книжку "Does IT matter?" - в том ключе, что на самом деле, мол, автор не совсем прав, но да, сама по себе ИТ-компетенция, конечно, успешного перехода в бизнес не гарантирует. Я счёл это замешательство положительной характеристикой, и, видимо, с книгой стоит ознакомиться.

GNU 25

2008-09-09T21:14:00.007+04:00

Стивен Фрай выступает с поздравлением:

Разумеется, иллюстрацией к статье о Фрае в Википедии уже служит кадр из выступления.

Это, кстати, не единичный случай такого участия: вот, к примеру, февральская статья в Guardian - хотя, конечно, каких-либо откровений специалистам там искать не стоит.

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

Helicopier

2008-09-07T20:00:00.003+04:00

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

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

Презентация проекта на сайте выложена в одном архиве с видео и имеет размер около 50 Мб, поэтому на всякий случай выкладываю её здесь в облегчённом виде:

Механический калькулятор

2008-09-07T19:19:00.001+04:00

Карманный арифмометр Curta - видео и подборка фотографий:

Характерные отличия веб-проектов

2008-09-01T10:09:00.001+04:00

- Кто такой Карл Маркс?
- Экономист.
- Как наша тётя?
- Нет, наша тётя - главный экономист.

Ещё свободою горим

2008-08-27T10:57:00.003+04:00

Неплохая статья Сполски о "менеджерах среднего звена".

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

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

Беда, коль сапоги начнёт тачать

2008-08-26T14:49:00.008+04:00

Увидел ссылку на воспоминания Дмитрия Донского, претендующие, ни много, ни мало, на описание развития профессии программиста от момента её появления.

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

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

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

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

По мере того, как автор переходит к более современным реалиям, утверждения становятся всё более смелыми - от объявления "Юникса" (какого? Bell Labs 1969?) "лучшей операционной системой" (лучшей для чего?) до декларирования туманной "сдерживающей роли HTML". Это вполне объяснимо - по мере карьерного роста автор всё больше занимался руководящей и проектной деятельностью и всё меньше следил за техническими деталями - но тогда и в рассказе имело бы смысл удержаться от соблазна попытаться объять всё сразу.

Заслуживает внимания также описание Palm OS, в которой "не было нормальной файловой системы" - в то время как её файловая система во многом опередила своё время, а куда более важной проблемой было отсутствие прикладной многозадачности.

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

Везти с поклажей воз взялись

2008-08-25T10:17:00.008+04:00

Увидел полезную для "причёсывания" слабо формализованных обычно понятий табличку и привёл её к более удобному виду:

	Information	Functional	Concurrency	Development	Deployment	Operational
System Architect	Co-ordination	Co-ordination	Co-ordination	Accountable	Co-ordination	Co-ordination
Application Architect	Input providing	Accountable	Input providing	Input providing	Input providing	Input providing
Data Architect	Accountable	Input providing	Input providing	Participant	Participant	Participant
Information Architect	Input providing	Input providing	Input providing	Participant	Participant	Participant
Integration Architect	Input providing	Input providing	Accountable	Participant	Input providing	Input providing
Security Architect	Participant	Participant	Accountable	Participant	Participant	Participant
Process Architect	N/A	N/A	N/A	Input providing	Input providing	Input providing
Network Architect	Participant	Participant	Participant	Participant	Accountable	Accountable
Server Architect	Participant	Participant	Participant	Participant	Accountable	Accountable
Runtime Architect	Participant	Participant	Participant	Participant	Accountable	Accountable

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

Управление и разработка

2008-08-21T10:34:00.003+04:00

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

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

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

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

Biomoney

2008-08-12T12:32:00.004+04:00

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

Вполне возможно, это даёт основания говорить о том, что подобный процесс становится коммерчески выгодным, а не просто интересным (в этом году компания собирается открыть в США сразу несколько ферм водорослей).

Передозировка

2008-08-11T14:20:00.003+04:00

Витамин C вдвое снижает темпы роста опухолей без вреда для здоровых тканей

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

А вот от простуды витамин C не защищает.

Terrify to certify

2008-08-07T11:05:00.007+04:00

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

CERN Rap

2008-08-04T23:37:00.001+04:00

Все уже видели, конечно, но удержаться сложно:

(домашняя страница автора)

The "Mojave Experiment"

2008-07-29T21:35:00.001+04:00

http://www.mojaveexperiment.com

Испытуемым пользователям, наслышанным о недостатках Windows Vista, показывали её под видом новой "Windows Mojave".