The "Mojave Experiment"

http://www.mojaveexperiment.com

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

Последний дюйм

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

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

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

Oldies but goodies

Слайды из презентации IBM 1975 года

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

Ещё об индустриализации отрасли

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

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

Greg the Architect - SOA This. SOA That.

Отношение в сообществе постепенно складывается вполне определённое.

"Мы продаём или покупаем?"

Почему статистические методы не могут заменить моделирования (комментарии также имеет смысл прочесть)

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

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

Process recess

Nick Malik пишет, что автоматизации бизнес-процессов мешает ориентированность языков их описания на человека, а не на машину.

Во-первых, мне кажется, что это не столько проблема языка, сколько проблема подхода тех, кто на этом языке пишет - язык в данном случае может помогать или мешать в тех или иных аспектах, но не самодостаточно определять этот подход. Как есть шутка про отдельных "технических программистов" о том, что "я на любом языке могу написать программу на Фортране", так и про некоторых аналитиков бизнес-процессов можно сказать, что у них на любом языке получается должностная инструкция. Хотя и сложно спорить с тем, что существующие языки сами по себе недостаточно совершенны - это показывает хотя бы то, что повсеместно до сих пор используются собственные неформализованные нотации (к примеру, вряд ли кому сейчас придёт в голову проектировать алгоритм на АЯРНе при наличии существующих ЯП - а с BP* такое случается сплошь и рядом).

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

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

Sails management

В конце июля NASA планирует запуск NanoSail-D - концепт-аппарата под солнечным парусом площадью около девяти с половиной квадратных метров.

Аналогичную попытку уже предпринимали в России по заказу Planetary Society (тот аппарат обладал парусом в 600 квадратных метров), но попытка была не слишком удачной. Ракета-носитель, стартовавшая летом 2005 года с подводной лодки в Баренцевом море, отказала через 83 секунды. До этого в 2001 году аппарат также не смог отделиться от носителя.

P.S. У NanoSail-D есть собственный аккаунт в twitter - видимо, там будет что-то выкладываться, но всё же кому интересно, следить лучше тут.