четверг, 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.

Завершение

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

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


среда, 13 ноября 2013 г.

О проблемах программного обеспечения в 1983-м году

Цитата из статьи 1983-го года:

If you look at when the Bank of America central computer crashes and start doing statistics, you find that occasionally somebody has spilled coffee in the mainframe, or something like that happened that you can understand. But, in about 95% of those crashes, they don't really know what caused it. The system goes down, somebody says "Oh, here it goes again," and they push the reboot button. It takes them a couple of minutes to bring the stuff in from disk, the system starts again, and everying is fine. So, depending on the particular prejudices of whoever is recording those things, it was either a transient hardware failure, or whatever they like to call it. But basically, they just don't really know what happened.

Если вы взглянете на статистику аварий центрального Банка Америки, то вы обнаружите, что кто-то внезапно пролил чашку кофе на центральный процессор, или что-нибудь подобное, что может произойти и при этом можно понять что именно. Где-то в 95% случаев этих аварий никто не знает что на самом деле произошло. Система падает, и кто-то говорит: «Ё-мое.. опять..», и нажимает кнопку рестарта. Это требует нескольких минут, так как требуется загрузка с диска, после чего система стартует снова, и опять все хорошо. Однако, в зависимости от пожеланий-заморочек сопровождающих, они записывают это как временный аппаратный сбой или что-то в этом духе. Но на самом деле они даже не представляют, что это было.

Такое ощущение, что за 30 лет ничего не изменилось.

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

Разное

Статья сама по себе интересная, просто отмечу тезисно несколько вещей.

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

пятница, 8 ноября 2013 г.

Фальсифицируемость спецификаций

— Какие могут быть формальности между друзьями! Вася, сделай мне программу сортировки.
— А что такое сортировка?
— Мне надо, чтобы я вводил любые числа, а программа выдавала упорядоченные числа.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а твоя программа выдает 1 2 8 9.
— Так бы и сказал, что она должна использовать введенные числа.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6.
— Так бы и сказал, что все числа должны присутствовать.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6 7 и 8 и 9.
— Я выдал все, а от себя добавил, по дружбе, чтобы ты от меня отстал, наконец.

(через неделю)

— Ты что, Вася! Я ввожу 5.4 и 7.6, а она даже два числа отказывается сортировать.
— А откуда я знал, что тебе не только целые надо сортировать? Может тебе завтра взбредет комплексные сортировать?! Последний раз!!!

(через неделю)

— Ты что, Вася! Программа больше девяти чисел не сортирует…

© Конспект лекций для Светы

Фальсифицируемость

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

Что такое фальсифицируемость подробно есть в википедии, но для моего контекста достаточно того, что. Любое утверждение должно быть проверяемо (тестируемо). Если оно не проверяемо, т.е. его нельзя протестировать, значит оно ничего не стоит и его нужно выбросить на свалку. В крайнем случае, переформулировать или заменить. То, что можно протестировать — фальсифицируемо. То что нельзя — нефальсифицируемо.

Иллюстрация первая: классическая (в качестве введения)

Приходит заказчик и говорит: «Я хочу программу, и чтобы она работала». Переводя с пользовательского на народный это означает: «У меня есть проблема, и я хочу, чтобы её не было. Разберитесь пожалуйста, что это у меня за такая проблема, и решите её, и чтобы у меня её не было. А что за проблема я знать не знаю и знать не желаю.»

Иллюстрация вторая: недавняя

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

WTF?? С каких это пор можно сделать систему, которая решает любую проблему и приспосабливается к любой ситуации?? Для меня вышенаписанное это звучит как: «Мы вас просили спроектировать непотопляемый корабль. А то, что сделали вы, утонуло после первого попадания ядерной боеголовки».

Удобные спецификации

«Так, вам задание. Система должна работать быстро. Отвечать на запросы — как можно быстрее. И не занимать много памяти. И, ещё, это…, проект должен быть готов чем скорее, тем лучше. »

Сделать универсальную систему невозможно, нужно оптимизировать по каким-либо параметрам. Но кроме этого, здесь следующее: такая формулировка очень удобна. Если вдруг окажется, что система тормозит, то всегда можно сказать «Мы же просили сделать так, чтобы система работала быстро! Почему не сделали?». «Медленно отвечает? Мы говорили вам!» …

Но с другой стороны: «Система вообще-то работает быстро. Может не так быстро, как хотелось бы, но это быстро!»

В результате никто ни в чем не виноват и никому ничего не должен.

Исторический пример неточных требований

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

В спецификации было указано следующее:

“Shut off the pumps if the water level remains above 100 meters for more than 4 seconds.”

“Выключите насос в случае, если уровень воды остается выше 100 метров в течение более чем 4-х секунд.”

Как бы вы проверяли программно эту ситуацию? Т.е. какая математическая формула выдавала бы ответ о том, нужно выключать насос или нет.

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

  1. Среднее арифметическое за последние 4 секунды больше 100 м.
  2. Среднее между минимумом и максимум за последние 4 секунды больше 100 м.
  3. Среднее квадратическое за последние 4 секунды больше 100 м.

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

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

Необходимость фальсификации

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

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

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

Позитивные сдвиги

К таким сигналам отношу следующее. В последнее время несколько раз встречал из различных источников (внутренние правила компании по качеству; слова умных людей; методологии в IT), что: в разработке необходимо 100%-е покрытие тестами; если вы не можете проверить тестами, то и не реализуйте — практически наверняка есть проблема на предыдущих этапах.

Вывод

Таким образом, фальсифицируемость решает проблему демаркации — отделения реальных требований к системе от бесконтрольных хотелок.

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