четверг, 17 апреля 2014 г.

Леви-Брюль — Первобытное мышление

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

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

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

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

Одна из интересных особенностей — это отражение мышления в языке. У первобытных людей нет обобщающих понятий, у них все конкретное. Так, они не могут сказать «дай мне палку» — нужно обязательно указать какую палку (артикль, чья, эта, вон та) и пр.. Аналогично по этим причинам есть много падежей. Что интересно, с развитием мышления меняется и язык, поэтому отваливаются артикли и падежи.

Мышление первобытных людей хоть как-то понять очень сложно, и для его описания Леви-Брюль используется понятие «пра-логического» мышления (в нем нет логики, только ассоциации). Некоторые проявления этого мышления:

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

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

Кэтлин подробно описал «танец бизона», «исполнявшийся с целью заставить бизонов появиться... Приблизительно 5 или 15 манданов сразу принимают участие в пляске. У каждого из них на голове шкура, снятая с головы бизона (или изображающая ее маска) с рогами. В руке туземец держит лук или копье, оружие, которым он обычно пользуется в охоте на бизонов... Танец продолжается без перерыва до тех пор, пока не появляются бизоны: иногда танец затягивается на две или три недели, не прекращаясь ни на минуту. Пляска изображает охоту, во время которой ловят и убивают бизона... Когда один из туземцев устает, он дает об этом знать другим, наклоняясь телом вперед и делая вид, что он падает; тогда другой туземец выпускает в него из лука стрелу с притупленным кончиком. Первый падает как бизон, присутствующие вытаскивают его из круга за пятки, размахивая над ним ножами и жестами изображая обдирание и свежевание бизона. Затем его отпускают, а место в кругу занимает сейчас же другой, который, наряженный в маску бизона, также вступает в танец... Так продолжается до тех пор, пока не появляются бизоны».


среда, 9 апреля 2014 г.

Смерть начальникам!

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

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

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

Flat-флагманами с данной организацией являются Valve , Atlassian и Github. Сложно спорить с компаниями в сотни человек, выпустившими на рынок такие продукты как Half-Life, Steam, Counter-Strike, JIRA, Confluence и GitHub, имеющими в наличии сотни сотрудников и существующих на рынке почти 20 лет.

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

Для движения в эту сторону в ряде компаний сотрудникам позволяется выделать какой-то процент своего времени на свои проекты (например в Google это 20%). Но как другой пример это Valve, где этот показатель составляет 100%, и такая организация для привычных иерархий может видится контринтуитивной. Здесь никто не может заставить работать над каким-то проектом — вы сами себе задаете вопросы над чем хотите работать и приступаете — присоединяетесь к какому-либо проекту или стартуете свой. При этом постоянно имеются сильные проекты, в которые требуются новые люди, и поиск новых людей внутри компании всегда ведется — в случае отсутствия сильных людей или недостатка ресурсов работать всегда есть над чем.

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

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

Valve очень долгое время была flat, и её организация такова практически с самого начала. Однако сейчас имеются фирмы, которые провели процесс конвертации из пирамиды в flat. Например компания Treehouse (60 сотрудников) летом 2013-го года превратилась в flat, и есть описание причин и подробностей этого процесса, как в конечном счете компания начала работать.

Следующий пример — компания Crisp, 35 человек, и описание того, как осуществляются решения в их flat-структуре.

И ещё одно сообщение о впечатлении после года работы в Github.


четверг, 13 марта 2014 г.

Способы улучшения качества сна от MyZeo

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

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

Основными признаками и целями о улучшения являются: Total Sleep, Deep, REM, Wake и Time to Z. Каждый из факторов имеет свои особенности — способы определения и решения проблемы.

Total Sleep
Общая продолжительность сна. Здесь проблема появляется тогда, когда время, отведенного на сон, недостаточно (дела, внешние факторы, …) либо физиологически спать больше не получается (бессонница). Но это бессонница общей продолжиельности сна, а не его прерывания.
Deep
Недостаток глубокого сна. Если вы не спите днем, то эта фаза сна хорошо выражена в первые фазы цикла (например первые 3 часа ночного сна; здесь темно-зеленые области). Иначе — проявляется слабее. Во время этой фазы идет физическое восстановление (например иммунной системы).
REM
Фаза быстрого сна (REM). Еслине спим днем, то REM проявляется ближе к утру. Если спим днем, то днем эта фаза существенно проявляется. Во время этого типа сна восстанавливается психика. Т.е. если работа умственная или напряженная, то улучшение этого сна критически важно.
Wake
Фактор просыпания. Проявляется если вы просыпаетесь ночью, как на продолжительное (десятки минут), так и короткое время (пара минут). Что отдельно следует сказать, это то, что многие люди не помнят, как они просыпались на короткое время, и данный факт можно установить только с помощью прибора, снимающего электроактивность мозга (MyZeo это умел, приложения смартфонов этого не умеют; для снятия надо надевать какую-нибудь штуку на голову, обычно на лоб). Например я наблюдал такое у себя на ночных гафиках от MyZeo — малые красные полоски.
Time to Z
Это время, которое требуется на то, чтобы заснуть. Это может быть как длительное валяние (например 0.5-1.5 часа), так и долгое бессознательное засыпание (10-15 минут без памяти этого факта).

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

    

пятница, 27 декабря 2013 г.

Olympus BioScapes

И ещё один известный мне квази-научный фотоконкурс — конкурс Art of Failure.

Каждый год компания Olympus, являющаяся одним из ведущих мировых производителей фототехники, микроскопов и других оптических инструментов, проводит конкурс Olympus BioScapes Digital Imaging Competition. В этом конкурсе принимают участие снимки различных микроскопических форм жизни, сделанные при помощи оптических микроскопов с использованием различных технологий съемки.

  • "Жуки-братья", Два экземпляра насекомых вида Gonocerus acuteangulatus, размерами по 3 миллиметра, которые появились на свет два часа назад.

  • Открытая ловушка водного насекомоядного растения Utricularia gibba с одноклеточными организмами внутри.

  • Эмбрион летучей мыши вида Molossus rufus.

  • Зародыш цветка лилии, поперечное сечение.

  • Микроорганизм Paramecium.


четверг, 14 ноября 2013 г.

Защита от Злого гения Декарта

Которой не существует. Но все таки я его нашёл!

Понятие

Регулярно как минимум в инженерной среде при проектировании (а точнее, при валидации) чего-нибудь складывается следующая ситуация. Разработчики придумывают какое-нибудь решение, а критики вокруг начинают придумывать разные идеи по поводу того, «а что будет если …». Изначально предлагаются осмысленные варианты поведения (здравомыслящие и логические), далее идет рассмотрение крайних случаев, потом идут какие-либо безобидные ситуации (как некорректный ввод пользователя), но в дальнейшем начинается нечто более серьезное. Что будет если закончится место на диске? Как разруливать ситуацию, если мы имеем нагрузку X, а нам дадут 10*X? А если задача зависнет? Однако, на этом дело не заканчивается. Идут вопросы о том, что делать если сыпется диск? А что если CPU будет не успевать? А если откажет таймер и часы переведутся? А если выйдет из строя тактовый генератор процессора? … где-то в конце этого списка молния попадает в компьютер, но он все равно должен выжить и выполнить боевую задачу.

В литературе по отказоустойчивым системам (fault-tolerance systems) между строк и сквозь все пронзает мысль о том, что нельзя построить систему, которая была бы оказоустойчивая и безопасная ко всему. Только сейчас в статье Marco Schneider'a нашел понятие того, кто пытается любыми способами сломать систему и с фактом того, что всегда есть возможность ему это сделать. То есть, если мы рассматриваем действующую систему, то мы можем находясь извне всегда придумать такую ситуацию, чтобы эту систему сломать, т.е. сделать так, чтобы она перестала функционировать. В статье такая роль называется malicious adversary или evil demon, последнее из которых — Злой гений Декарта.

Опытные и неопытные разработчики

Уровень 1. Новички в инженерии совершенно лишены тормозов и не знают о том, что вообще этот Злой гений существует. В связи с этим то, что они хотят сделать, они реализуют быстро, как придется и так, чтобы работало (классический Cowboy). У них нет в сознании множества граблей, на которые можно наступить. Нужно отправить e-mail? Где процедура… какие параметры? … сейчас подставим и всё! Готово! (пора рапортавать менеджерам о своей высокоэффективности). Однако то, что SMTP-сервер может быть не доступен, не обрабатывается. Письмо может не влезть в ящик, e-mail совсем не e-mail, пароль захордкожен и в открытом виде, бесконечный запрос отправки вешает всю систему, а ошибки сервера забыты, и это далеко не полный список.

Уровень 2. Более опытные разработчики имеют карту местности с множеством граблей, и отлично понимают, что наступить на новые, или на старые, можно в любой момент. Злой гений Декарта присутствует, но он есть интуитивно: уровень проработанности определяется на глазок, по срокам и ресурсам, а те, кто будет аргументировать методом «а что, если молния в компьютер?», будет мягко говоря, проигнорирован. Но даже для весьма опытных специалистов вопросы Злого гения ставят в тупик. Я несколько раз наблюдал ситуацию, когда в кругу матёрых инженеров (один пример на IT-конференции, второй в обществе специалистов по отказоустойчивым системам, третий в общении программистов со стажем порядка 10 лет) имел место диалог вида:

— Вот вы столько всего рассказали, все так интересно, но все равно ваша система не сможет спасти от всего?

— Да, не сможет.(с виноватым видом без акцента на то, что так вообще-то не сможет любая система)

Такой вот универсальный троллинг 2-го уровня.

Уровень 3. Понимание того, что Злой гений Декарта есть, универсальной защиты от него нет, но с ним можно бороться. А тот, кто предлагает универсальные способы решения — алхимик современности.

А как бы вы решали проблему защиты от Злого гения Декарта?

Мне известны два широкополосных способа, позволяющие эффективно решать данную проблему.

Решение 1: На основе анализа предыдущего опыта

В качестве иллюстрации данного способа решения мне нравится пример Титаника (его же и не только использует Leveson в своих статьях и книгах).

Когда спроектировали и пустили на воду Титаник, он считался непотопляемым. Данный вывод был сделан не а пустом месте. В качестве доказательства в пользу имелся ряд аргументов и фактов. Для упрощения (там было много всего), Титаник был спроектирован в качестве корабля с множеством независимых отсеков, который остается на плаву в случае пробоин и затопления 4-х из них. Исторический опыт того времени говорил о том, что во всех катастрофах было так, что корабли не получали повреждений более, чем на заполнение 4-х отсеков. К сожалению, в результате столкновения у Титаника было затоплено 5 отсеков.

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

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

Решение 2: Вероятностная защита

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

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

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

Если используем простейший CRC, то он позволяет также сделать так, что проявление сбоя будет замечено с высокой вероятностью, и не замечено — с пренебрежимо малой. Мы не защищаемся от всех сбоев, но зато защита идет от абсолютного большинства из них. И, если например CRC32, то следует помнить, что в случае сбоя если один из TCP/IP пакетов или запакованных архивов будет распакован или разобран в битом виде, при этом с вероятностью 2-32 мы этого не заметим и никто нам об этом не скажет.

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

Завершение

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

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