суббота, 18 января 2014 г.

[life.humour] Игрушечное оружие для стрельбы резинками

В G+ ленте в последние дни часто встречается упоминание какого-то чудо-пулемета, стреляющего резинками.

Однако, выяснилась интересная вещь. Есть забавный сайтик oggcraft.jp, на котором собрана целая коллекция описаний/фотографий/видеороликов подобных вещей. Вот некоторые фотографии оттуда:

Видеозаписи моделей в действии можно найти на YouTube.

Там же на YouTube обнаружился еще один вариант пулемета Гатлинга для стрельбы резинками.

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

В общем, народ развлекается :)

пятница, 17 января 2014 г.

[prog.c++] Мысли по подпискам и отсылке сообщений в SObjectizer-5

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

Вот это описание. Выкладываю в общий доступ по двум соображениям.

Во-первых, кому-то это может быть интересно узнать, как actor model может воплощаться в жизнь на низком уровне. И, если мне повезет, кто-то найдет в моей идее недостатки или обратит мое внимание на более интересные варианты.

Во-вторых, в своей недавней заметке по поводу The Reactive Manifesto я дал совет брать готовые инструменты. Отчасти это пояснение данного совета. Стоит только взяться за разработку своего велосипеда, как оглянуться не успеешь и окажешься в такой же ситуации: есть работающий, оттестированный код. Но который нужно переписать. А вокруг других забот полно. Да и сам код со временем стал не таким уж тривиальным, и требуется некоторая осторожность, чтобы новое решение не поломало старый код. Вот и приходится семь раз отмерять, чтобы один раз отрезать именно там, где нужно :)

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

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

[prog.c++] Несколько ссылок на тему lock-free

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

libcds: http://libcds.sourceforge.net/

liblfds: http://liblfds.org/

Boost.Lockfree: http://www.boost.org/doc/libs/1_55_0/doc/html/lockfree.html

Concurent Building Blocks: http://amino-cbbs.sourceforge.net/

FastFlow: http://calvados.di.unipi.it/dokuwiki/doku.php?id=ffnamespace:about#fastflow_v2.0

DKit: https://github.com/drbobbeaty/DKit

sim-synch: https://code.google.com/p/sim-universal-construction/

Upd. Concurrency Kit: http://concurrencykit.org/. Чисто С-шная библиотека под BSD-лицензией и реализацией кучи всякой всячены (atomic operations, hardware transactional memory, memory barriers, hash tables, list, ring, stack, fifo, bitmap, safe memory reclamation, scalable locks, execution barriers, asymmetric synchronization). Похоже, что не поддерживает Windows и Visual C++.

Каталог разной полезной информации: http://www.1024cores.net/home/lock-free-algorithms/links (вообще сайт Дмитрия Вьюкова 1024cores настоятельно рекомендую).

Каталог разной полезной информации: http://yinsochen.com/thread-safe-and-or-lockless-data-structures/

Подборка статей на тему низкоуровневого многопоточного программирования: http://locklessinc.com/articles/

среда, 15 января 2014 г.

[prog] Несколько раздраженных комментариев по ходу чтения "The Reactive Manifesto"

Критиковать всегда легче, чем создавать что-то свое. Поэтому я опасаюсь писать исключительно критические посты. Но читая документ под названием "The Reactive Manifesto" эмоции захватывали настолько сильно, что удержаться не смог. Поскольку это очередной призыв вида "Лучше быть здоровым и богатым, чем бедным и больным" или, ближе к программерской теме, пустой выхлоп на тему "Программы должны быть быстрыми, отзывчивыми и надежными", без полезной для разработчиков конкретики. За исключением, разве что, рекламы очередной серебряной пули под названием "event-driven programming", без каких-либо конкретных деталей, понятное дело.

Что дает мне право так жестко говорить на счет изложенных в манифесте вещей? То, что к тому самому event-driven я имею непосредственное отношение уже около двадцати лет. А года с 2001-го только тем и занимался, что разрабатывал ПО, базирующееся на асинхронном обмене сообщениями. Наблюдал за развитием написанного с использованием этого подхода ПО в течении длительного времени, занимался поиском багов, устранением узких мест, масштабированием, добавлением нового функционала, сопровождением и серьезными переделками. Так что прочувствовал всю прелесть этого подхода на себе. И твердо могу сказать: чудес не бывает. Event-driven и asynchronous messaging -- это не пустые слова, в ряде предметных областей успешно работают. Но никакого волшебства нет, есть обычная кропотливая работа. Поэтому, если у кого-то есть надежда, что стоит только взять на вооружение event-driven+async messages, так сразу на него обрушится огромное щасте с большой буквы Щ, тот сильно заблуждается :)

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

Итак, документ декларирует четырех "китов" всей идеи реактивных приложений:


React to events. Приложение должно строится на обмене асинхронными сообщениями и на обработке событий. Мол, если в основе приложения будет лежать неблокирующие друг друга операции, то приложение будет более отзывчивым и будет демонстрировать выполнение своих действий лучше, чем когда те же операции выполняют параллельно работающие процессы/потоки, общающиеся между собой посредством синхронных (т.е. блокирующих) вызовов.

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

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

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


React to load (да еще с пояснением focus on scalability by avoiding contention on shared resources). Ну в прямом смысле "лучше быть богатым, чем бедным". Работа с shared resources возникает не из-за того, что все прям горят желанием делать именно так. Либо из-за того, что по-другому не умеют в принципе. А потому, что такие ресурсы, ну бывает так в жизни, оказываются в ограниченном количестве.

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

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


React to failure. Ну это вообще мой любимый пункт, поскольку кратко он раскрывается следующим образом: build resilient systems with the ability to recover at all levels. Т.е. писать системы нужно так, чтобы они могли восстанавливаться на каком бы логическом уровне не произошла ошибка.

Нет цензурных слов, чтобы комментировать такое. Проблема отказоустойчивости и восстановления работоспособности приложения настолько сложна, что в двух словах о ней не расскажешь. Интересующихся адресую на несколько своих старых заметок: о fail fast, restart quickly; о принципе let-it-crash; о защищенном программировании.

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

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


React to users (с пояснением honor response time guarantees regardless of load). Вновь благие намерения. Поведение системы и нагрузка на систему тесно связаны и сильно зависят от назначения системы. Например, если вы делаете систему он-лайн платежей через банкомат, то время обслуживания транзакции для вас очень важно: вы не можете держать клиента перед банкоматом слишком долго (счет идет на десятки секунд). Для выполнения операции вам придется провзаимодействовать с кучей внешних систем с непредсказуемым временем реакции. И при этом обеспечить надежность проведения финансовых операций. Правда, нагрузка на вашу систему, в приципе, ограничена размером банкоматной сети, хотя и здесь бывают варианты ;)

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

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


В завершении вот чего хочу сказать.

Если вы никогда не слышали про actor model, event-driven programming, asynchronous messaging и пр. вещи, то можно для общего развития этот The Reactive Manifesto и прочитать. Если же слышали и более-менее представляете себе, где это все уместно и чем это чревато, то лучше не читать. Там только лозунги и декларация благих намерений. Ничего полезного вы для себя не найдете.

И еще одна важная вещь. Времена, когда модель агентов и обмен сообщениям были чем-то новым и неизведанным давным давно минули. Так же минули времена, когда удовлетворить желание использовать эти вещи можно было лишь написав собственный фреймворк. Теперь вопрос инструментов не стоит в принципе. Хотите попробовать? К вашим услугам Erlang, Akka для Java/Scala, Cloud Haskell для Haskell-я, SObjectizer для C++ и еще много инструментов. Берете себе подходящий инструмент и вперед набивать шишки и накапливать опыт.

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

[prog.bug] Непростое это дело: подсчитать количество комментариев :)

Давеча у Гоблина указали, что всего комментариев 549, тогда как прямо над этим числом расположен комментарий с порядковым номером 551. Либо задача числа комментариев совсем не проста. Либо счетчик порядковых номеров комментариев у них начинается не с нуля и даже не с единицы ;)

вторник, 14 января 2014 г.

[life.book] Некоторые впечатления от книги "(Не)совершенная случайность"

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

Теперь чуть подробнее. Тервер и матстатистику нам читали в течении двух семестров, если не ошибаюсь, осенью 1993 и весной 1994. Из того курса самым ярким впечатлением для меня оказалась разница между объективной оценкой вероятности и моего субъективного отношения к ней. Например, когда лектор демонстрировал нам простейшую задачу "мы находимся на 6-м этаже 9-ти этажного дома, какова вероятность того уже вызванный кем-то лифт остановится на нашем этаже?" я был поражен тем, что вероятность остановки лифта на 6-м этаже равна вероятности остановки лифта на любом другом этаже. Т.е. логически я соглашался с этим строгим математическим выводом, а вот эмоционально принять это было сложнее: меня ведь интересует только 6-й этаж и неприятно было столкнуться с тем, что эта "важность" 6-го этажа никак не выражается в математической формуле :)

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

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

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

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

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

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

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

А если перейти еще к более высоким материям, то как вообще определить, что является следствием закономерности, а что результатом случайного процесса? Скажем, было ли случайным создание теории относительности? Было ли случайно, что именно Альберт Энштейн стал ее автором? А для самого Альберта Энштейна создание теории относительности оказалось случайностью или закономерным итогом его научной работы?

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

Ну а в завершении неожиданный для меня полезный практический выхлоп.

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

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

Во-вторых, любые подобные замеры делаются на слишком маленьком временном участке. И, поэтому, могут оказаться крайне недостоверными. Особенно это касается различных stack ranking систем, где по итогом ограниченного временного интервала делается заключение о полезности сотрудника для организации. Например, кто-то пытается оценить результаты года моей работы на какой-то должности. Мой профессиональный стаж -- 20 лет. Один год из этого стажа это всего лишь небольшой отрезок. И, если предположить, что успехи и неудачи в карьере в бОльшей степени определяются случайным распределением (что, вероятно, и есть на самом деле), то насколько показательна оценка 1/20 участка профессиональной деятельности для серьезных выводов? Может это был худший год в моей карьере и следующий будет лучше. А может наоборот? Может это фрагмент небольшого спада или же фрагмент очередного подъема?

Вот как-то так. Книга интересная, при чтении заставляет напрягать мозги. А после прочтения заставляет еще больше задуматься и несколько переосмыслить свой жизненный опыт, сложившиеся стереотипы и отношение к происходящему. А так же увидеть неожиданные прикладные применения прочитанной теории. Как, например, только что показанная дискредитация систем "объективных" и "беспристрастных" математически-обоснованных оценок сотрудников ;)

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

[work] Не могу не процитировать пример долговременного планирования

На мой взгляд, просто шикарный пример из книги Леонарда Млодинова "(Не)совершенная случайность":

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

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

воскресенье, 12 января 2014 г.

[life.history] Интересно про Луи Пастера и его эксперимент с колбой с изогнутым носиком

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

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

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

...Луи Пастер в 1865 году хитроумным экспериментом сумел доказать, что никакой жизненной силы нет. Этот опыт, показанный в парижской Академии наук во время знаменитого диспута с Пуше, вошел в школьные учебники всех стран. Пастер предложил не запаивать наглухо прокипяченный бульон, а оставить в стеклянной колбе тонкий, дважды изогнутый открытый носик. Если жизненная сила есть, то даже узкий извилистый проход не помешает ей проникнуть в колбу и породить микробов. Если же такой силы нет, то микробы из воздуха будут оседать на изгибах стеклянного носика, и бульон останется стерильным. Оппонент Пастера Феликс Пуше утверждал, что в колбе с тонким изогнутым носиком в питательном бульоне микробы все равно появятся. И это означало бы присутствие жизненной силы.

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

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

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