[life.photo] Танго у лебяжьего пруда в гомельском парке

Вчера утром увидел на onliner.by новость о танцевальной акции у лебяжьего пруда в нашем городском парке. Решил сходить, поучиться репортажной фотографии.

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

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

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

[management.flame] Анонс бесплатного курса от happy-pm просто убил

Успешные менеджеры программистов (с) рекламируют у себя на сайте бесплатный курс:

Не смотря на то, что сейчас окажусь в роли "Пастернака не читал, но осуждаю", скажу две категоричные вещи тем, кто хочет вырасти до менеджера в ИТ и планирует воспользоваться этим четырехчасовым(!) видеокурсом:

• не тратьте свое время на продукцию людей, которые не смогли вместо 4-х часов видео сделать брошюру на 20-30 страниц с лаконичным изложением основных моментов своего курса. Прочитайте лучше что-нибудь из ДеМарко и Листера. В первую очередь "Человеческий фактор"/"Peopleware: Productive Projects and Teams";
• когда вы станете менеджером у вас НИКОГДА не будет 4-х часов на то, чтобы во что-нибудь глубоко вникнуть. Никогда. Привыкайте экономить свое время, всасывать в себя новое и принимать решения в условиях жесткого цейнота.

PS. "Peopleware" ДаМарко и Листера -- это фундаментальная книга. Хотя из-за своего небольшого объема, простоты и очевидности изложенного в ней материала, он явно недооценена. А может и специально, для того, чтобы впаривать новичкам намного более объемные и менее полезные толмуды и видеокурсы.

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

PPPS. Таки да, я не перестану стебаться над Клубом Успешных Менеджеров Программистов (с). Хотя бы из-за неумения придумать что-нибудь более вменяемое, чем "Менеджеров Программистов". И уж тем более за приставку "Успешных" к этому корявому словосочетанию.

[management] Про оптимизм разработчиков (с отсылкой к Манхэттенскому проекту)

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

Есть даже вполне универсальный коэффициент -- значение Пи. C частично юмористическим обоснованием: движение из точки A в точку B при разработке происходит не по прямой, а по дуге, при вычислении же длины дуги требуется умножение на Пи :) Мастерство настоящих эффективруководителей разработки ПО состоит в том, чтобы уметь со временем вычислять коэффициенты для оценок своих ведущих экспертов. Эти индивидуальные коэффициенты будут отличаться друг от друга из-за степени новизны задачи, личностных особенностей экспертов, их предыдущего опыта, состояния их психикиздоровья и фазы луны ;) *

Однако, если смотреть на мир шире, проблема слишком оптимистичных оценок и надежд присуща не только разработчикам ПО. Но и разработчикам ВООБЩЕ. Действительно, когда предстоит сделать то, чего еще нет, то откуда брать оценки? Даже в случае, когда что-то подобное уже делали в прошлом, но сейчас требуется пришить перламутровые пуго что-то как-то поменять. Но что и как до конца не понятно. Вот мы и озвучиваем свои ожидания. А уже человеческая природа обуславливает то, что наши ожидания оптимистичны. Или ну очень оптимистичны :)

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

Среди сотрудников лаборатории имелась также группа ученых в основном европейского происхождения и, следовательно, ближе знакомых с промышленностью, чем их американские коллеги, которые считали, что всеми инженерно-проектными работами должны руководить они. Причем некоторые из них считали себя подготовленными даже для руководства строительством. Во время моих посещений лаборатории Комптона я неоднократно выслушивал предложения о выделении 50--100 инженеров и проектантов для обеспечения быстрого строительства плутониевого завода. (Абсурдность этих предложений особенно очевидна, если вспомнить, что впоследствии на строительстве такого завода было занято до 45 тысяч человек и даже ресурсы такой компании, как "Дюпон", были на грани истощения, несмотря на громадную поддержку и помощь правительства США.)

И если здесь Гровс говорит о чрезмерном оптимизме ученых, то чуть позже он признается и в чрезмерном собственном оптимизме (речь идет о найме персонала для завода по обогащению урана в Ок-Ридж):

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

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

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

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

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

Но, честно говоря, у меня нет уверенности в том, что в своей оценке чужой твердолобости Гровс прав. Если вспомнить некоторые уточняющие детали про безопасность производства на тех самых заводах в Ок-Рижд, которые раскрыл Ричард Фейман, то лично у меня закрадывается совсем другая мысль: а ведь может быть ученые были правы, когда предлагали начать проектирование завода небольшой группой инженеров и проектантов?

---

* Действительно успешные менеджеры программистов крайне подозрительно относятся к точным оценкам. Если разработчик начинает точно предсказывать и, более того, еще и точно укладываться в называемые им сроки, значит он занимается надувательством. Он заранее применяет уточняющий коэффициент, обеспечивает себе требуемый запас по времени, и работает не слишком напрягаясь. К таким умникам нужно относиться крайне осторожно :)))

[life.history] Прочел "Историю Манхэттенского проекта" Лесли Гровса.

Закончил читать книгу "Теперь об этом можно рассказать. История Манхэттенского проекта" Лесли Гровса, руководителя проекта по созданию атомной бомбы в США. Впечатление скорее негативное, чем позитивное. Начинал читать с интересом. Ближе к середине книги интерес угас. Дочитывал уже "для галочки". Так что никому рекомендовать не буду. Если кто-то рассчитывает найти в ней секреты успешного управления большими проектами, то напрасно, в этом смысле чтение "Истории Манхэттенского проекта" будет напрасной тратой времени.

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

Лично мне показалось, что ключевыми факторами успеха стали:

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

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

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

Советским научным специалистам, которых в 1944-45-х годах отправляли на оккупированные территории для захвата научно-технической базы (например, в ракетной области) так же присваивали воинские звания. Но мне не приходилось слышать, чтобы по отношению к кому-нибудь это выглядело "нелепым" и он отправлялся в Германию как штатское лицо. В чем же здесь состояла нелепость? Этот специалист был инвалидом, геем или рукопожатым журналистом? ;)

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

В окончательном виде завод Y-12 состоял из пяти альфа-установок (каждая из девяти рейстреков), трех бета-установок с восьмью рейстреками по 36 магнитов, химических и других вспомогательных корпусов. Установки были огромные. Например, два здания для альфа-установок занимали площадь по 18 тысяч квадратных метров каждое; внутри они представляли собой сложнейший лабиринт из труб и другого оборудования. Большая часть оборудования превосходила по масштабам и точности изготовления все, что до сих пор когда-либо разрабатывалось. Многие узлы были созданы заново. Из-за трудностей в снабжении и кадрах, постоянной спешки и перегруженности фирм-поставщиков другими заказами все это уникальное оборудование изготовлялось в тяжелейших условиях.

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

Можно ли представить себе, чтобы в СССР в середине или даже ближе к окончанию Великой отечественной была возможность "опросить 400 тысяч человек", чтобы завербовать наиболее опытный руководящий персонал?!!!

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

В этой связи очень понравилась ремарка редактора русского издания книги:

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

Ну и еще одно впечатление, возможно, главное. Гровс так часто говорил о стараниях США ни в коем случае не допустить утечки информации и/или ученых-ядерщиков к русским, что в очередной раз становится очевидным: США никогда не были и, вероятно, никогда не будут дружественной России страной.

[prog.flame] И это говорит хаскелист, который раньше программировал на тикле?!!!

Вот здесь:

Я не собираюсь тратить на vim и/или git время большее, чем они того заслуживают.

Заслуживают же они совсем немного. От git надо умение хранить данные и синхронизироваться с удаленным репозиторием, от vim - не портить мой файл без бибикания.

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

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

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

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

А вообще вспоминается: "Вам не нравятся кошки потому, что от них шерсть и запах? Вы просто не умеете их готовить!" :)

PS. ViM -- рулез!!!

PPS. Моя небольшая история о том, как я пришел к ViM-у. До сих пор с удовольствием им пользуюсь, хотя в последний год больше приходилось использовать Word и редактор Thunderbird-а. Но по удобству они ViM-у и в подметки не годятся.

[life.photo] Фото с Дня Нептуна-2013. Пейзажное

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

[prog] Мое решение упражнения Web Crawler из A Tour of Go

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

Прежде чем что-то писать, язык Go нужно сначала выучить. Начал изучение с A Tour of Go. Вещь прикольная, но в процессе накапливаются некоторые вопросы и недопонимание. Надеюсь, что ответы найдутся по ходу чтения более серьезных материалов.

Вчера добрался до упражнения Web Crawler. Его смысл в том, чтобы модифицировать некую функцию Crawl так, чтобы:

• один и тот же URL дважды не обрабатывался;
• обработка URL велась в параллель.

Собственно, вот полное условие задачи:

In this exercise you'll use Go's concurrency features to parallelize a web crawler. Modify the Crawl function to fetch URLs in parallel without fetching the same URL twice.

И все описание. А вот исходный код этой функции:

// Crawl uses fetcher to recursively crawl // pages starting with url, to a maximum of depth. func Crawl(url string, depth int, fetcher Fetcher) {     // TODO: Fetch URLs in parallel.     // TODO: Don't fetch the same URL twice.     // This implementation doesn't do either:     if depth <= 0 {         return     }     body, urls, err := fetcher.Fetch(url)     if err != nil {         fmt.Println(err)         return     }     fmt.Printf("found: %s %q\n", url, body)     for _, u := range urls {         Crawl(u, depth-1, fetcher)     }     return }

Честно признаюсь, впал в ступор. Поскольку для меня было очевидно, что если сохранять рекурсивную природу Crawl, да еще допускать ее запуск в разных потоках (goroutine-ах), то нельзя обойтись без общей структуры данных (вроде map-а), доступ к которой нужно синхронизировать. А из примитивов синхронизации в Tour of Go описывались только каналы. Еще одна загвоздка была в том, чтобы контролировать моменты завершения параллельных вызовов Crawl. Ведь об этом в Tour of Go ничего не говорилось, а простейший эксперимент показал, что функция main спокойно себе завершается не дожидаясь работы запущенных потоков.

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

Сегодня, на свежую голову, решил отказаться от сохранения рекурсии в Crawl. Crawl превращается в менеджера, который запускает обход конкретных URL в параллель посредством простой нерекурсивной функции fetchUrl. Для обмена результатами работы используются Go-щные каналы. Более того, если вчера мне казалось, что потребуется несколько информационных каналов, то сегодня стало очевидно, что достаточно только одного, через который fetchUrl будут сообщать Crawl-у о результате обработки URL-а. В общем, где-то за час-полтора удалось переписать пример, скомпилировать его и убедится, что полученное решение вроде бы работает.

После чего погуглил аналогичные решения. С ходу нашлось три: #1, #2, #3 (наверняка их больше). Мне кажется, что мое не хуже :)

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

Свои же впечатления от языка Go пока описывать не стану, еще рано, нужно поднабраться опыта.

[life] Выглядит дико

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

[life.photo] Фото с Дня Нептуна-2013. Лошадки

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

[life.photo] Фото с Дня Нептуна-2013. Репортажное

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

[management] Из воспоминаний Ричарда Феймана: важность объяснение цели для стимулирования команды

На мой взгляд, очень хороший фрагмент из книги "Вы, конечно, шутите, мистер Фейнман!". Речь идет о работе команды вычислителей, которые в Лос-Аламосе делали расчеты мощности атомной бомбы:

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

Затем ребята пришли на работу, и единственное, что они должны были делать, это работать на машинах IBM - пробивать дырки в карточках, манипулировать с числами, которых они не понимали. Никто не объяснил им, для чего все это нужно. Дело двигалось очень медленно. Я сказал, что первое, что необходимо предпринять, это дать людям понять, чем все-таки они занимаются. Тогда Оппенгеймер переговорил в отделе безопасности и получил специальное разрешение, и в результате я смог прочесть техническому персоналу хорошую лекцию о том, что именно мы делаем. Они все пришли в страшное возбуждение: "Мы тоже сражаемся на войне, мы понимаем, что это такое!" Теперь они знали, что означают числа. Если выходило, что давление становится выше, значит, высвобождается больше энергии и т.д., и т.п. Они знали, что делают.

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

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

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

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

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

[life.history] "Поправки на ветер" по ходу чтения истории Манхэттенского проекта Лесли Гровса

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

Вот, например, по ходу чтения главы об обеспечении секретности и цензуры. Мнение Лесли Гровса:

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

Очень странно, подумалось мне. По своему опыту работы знаю, как быстро "замыливается глаз", когда ты вынужден заниматься каким-то узким кругом задач. И как необходима бывает помощь людей, работающих совсем в других областях, просто потому, что они могут окинуть твою проблему свежим взглядом. В воспоминаниях Ричарда Феймана тут же нашелся отличный пример "замыливания" как раз в Манхэттенском проекте (признаюсь, я искал в книге Феймана совсем другой, связанный с Лос-Аламосом фрагмент, а на этот наткнулся случайно, но очень "в тему"):

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

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

Забавно еще и то, что чуть ранее в своей книге Гровс приводит аналогичный пример, рассказывая о том, как появилась идея объединять разные способы разделения изотопов урана для повышения эффективности этого процесса:

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

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

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

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

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

Я пошел на железнодорожную станцию и заявил: "Хочу поехать в Альбукерки, штат Нью-Мексико". Железнодорожный служащий воскликнул: "Ага, значит, все эти груды для вас!" В течение недель мы отправляли туда контейнеры, полные счетчиков, и ожидали, будто никто и не заметит, что адресатом значился Альбукерки.

Т.е. усилия по засекречиванию переезда большого количества ученых из Принстона в Альбукерки были обесценены перевозкой туда большого количества научного оборудования.

Как-то после этого слова Гровса начинаешь воспринимать если не как бахвальство, то как хорошую мину в попытке доказать, что "ничего страшного не случилось же" ;)

PS. Книгу "Вы, конечно, шутите, мистер Фейнман!" читал довольно давно. Помнится, Фейман там серьезно прошелся по теме хранения секретов и цензуры. Думаю, что если бы я помнил ее содержание по-лучше, то воспоминания Гровса казались бы мне еще забавнее.

UPDATE! Действительно, беглый просмотр воспоминаний Фейнмана, касающихся работы на Манхэттенском проекте, выявил еще один эпизод, который заставляет смотреть на изложенным Гровсом принцип "каждый должен знать только то, что касается его работы" совсем, совсем по-другому:

В конце концов Эмилио Сегре сказал, что для него единственная возможность гарантировать правильность процесса - это поехать и посмотреть на месте, как все делается. Однако военные заявили: "Нет, наша политика состоит в том, чтобы вся информация о Лос-Аламосе была только в одном месте - в Лос-Аламосе".

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

- Вот это да! И что же, вы собираетесь таким же манером обращаться с этой водичкой и когда уран будет очищен? Вы именно это собираетесь делать?
Они остановились:
- Конечно, а почему бы и нет?
- Разве все не взорвется?
- Что? Взорвется?
Потом военные говорили:
- Вот видите! Нам нельзя было допускать никакого просачивания информации в Ок-Ридж. Ведь теперь там все деморализованы.

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

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

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

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

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

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

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

[life.photo] Танцы под дождем

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

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