О разных научных журналах

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

Данная разница визуально проявляется в количестве ссылок на литературу. При рассмотрении статьи в русскоязычном типично наличие 5-10 штук, в то время как для англоязычных в настоящее время минимальный предел где-то 10, при этом типично 20-30, а иногда для статьи в 5 страниц можно найти более 50 ссылок.

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

В последней отправке статьи в англоязычный журнал (6 стр, 16 ссылок) одним из комментариев редактора (не рецензента) было следующее:

The reference section is a little bit weak for a journal submission. The author is encouraged to do a more diligent literature review (it would better serve the credibility of his work and highlight the meaningfulness of its contribution)

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

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

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

Для журналов постсоветского пространства такого по большей части не наблюдаю. Более того, меня два раза просили уменьшить количество ссылок (оба раза с ~40 до хотя бы 30). И даже более того, один раз мне прозвучала где-то такая фраза (хорошо что не от редактора):

— Если у вас столько ссылок, то что же вы сами сделали в статье? [типа, может быть вы вообще ничего не сделали?]

Оставил без комментариев..

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

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

Таким образом, приходится использовать индивидуальный подход…

Как тестируются программы, от которых зависит жизнь людей?

Недавно появилась статья, чем-то напоминающая много кем известную "Они пишут правильную вещь" (оригинал).

Мне кажутся интересными ряд моментов для передачи свойств предметной области. А вместо их выделения проще привести и перевести все целиком. Ниже мой перевод.

---

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

А никак. Что ставит другой вопрос: как этот тип программ тестируется?

Это было в небольшом посте блога, написанном Gene Spafford, профессором информатики в Purdue University, написанным на волне ответа на этот конкретный вопрос. Он ссылается на историю об истоках кокпитов, где началась применятся проводная связь — такие самолеты управляются в полете электроникой, внедрение чего случилось непосредственно в конце 1980х. Мы уже привыкли к таким самолетам, но тогда это был большой скачок вперед: прямой контроль был убран и передан в руки программного обеспечения, которое было разработано для телеуправления механическими приводами из кокпита. С того момента компьютер мог разбить самолет.

А фактом являлось то, что людей, которые отвечали за компьтеры, поместили непосредственно в тестируемую среду.

Spafford пишет:

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

Таким образом, программисты Боинга имели дополнительную мотивацию потому, что им в будущем приходилось отдать свою жизнь в руки своего же программного обеспечения. Там, на высоте 9 000 метров, нет возможности что-то исправить — оно должно просто работать. И с чем вы будете более комфортно чувствовать: имея чей-то личный подход к верификации программного обеспечения (прим. оценка эксперта, рецензия), или, с другой стороны, имея кучу формальных доказательств и результатов имитационных испытаний?

Я бы предпочел и то и другое, но вопрос как тестируется это все интересен сам по себе. Ветка Stack Exchange 2011-го года предоставляет много интересного внутренней кухни данного процесса и его эволюции. Для начала, подход Боинга выходит из моды и в основном вышел из моды, согласно сообщению гуглера Uri Dekel:

Там серьезный шаг вперед в плане формальной верификации по сравнению со случайным функциональным тестированием. Государственные агенства, такие как НАСА и некоторые военные ведомства, тратят больше и больше денег на развитие этих технологий. Решение задач такого уровня все ещё PITA (pain in the ass — боль в заднице) для среднего программиста, но они намного более эффективны в тестировании систем, критичных по безопасности.

Scott Whitlock, инженер-программист, который поддерживает свою библиотеку для автоматического тестирования FluentDwelling, смотрит глубже, разьясняя проектные требования для безопасных трансляторов, являющихся системами промышленного применения для мониторинга оборудования, который передает сигналы предупреждения и может остановить сложное оборудование в случае необходимости. Они включают в себя, согласно Whitlock'y, "Два резервированных процессора, которые обычно запистываются от независимых источников питания, и выполненных конструкционно по-разному. Код, работающий на каждом процессоре, разработан двумя раными командами программистов, выполнивших свою работу в изолорованных друг от друга условиях. Результат вычислений обеих процессоров должен быть одинаков, иначе срабатывает реле безопасности."

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

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

"Это программное обеспечение никогда не падает" — пишет Charles Fishman. "Оно никогда не требует перезагрузки. Это програмное обеспечение без багов. Оно совершенно настолько, насколько это возможно из всего того, что было создано человеком. Посмотрите на эту статистику: как минимум три версии программы — каждая по 420 000 строк кода, имело только по одной ошибке. Последний 11 версий имели в общей сложности 17 ошибок. Типичные программы на рынке такой сложности будут иметь 5000 ошибок."

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

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

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

И далее:

Группа разработки должна предоставить код, который полностью лишен ошибок, настолько идеальным, что тестировщики не должны ничего найти. Группа тестирования должна идти далеко во множестве сценариев полетов и моделирования, и стараются выявить настолько много недостатков, насколько это возможно. Результат — то, что Tom Peterson называет "дружественно-враждебные отношения". "Они соревнутся в том, что найдет ошибки." говорит Keller. "Иногда они дерутся как кошки и собаки. Разработчики хотят поймать все свои ошибки. Верификаторы возмущаются, что это забирает их время, выделенное на проверку программного обеспечения."

Итак, что вы думаете, астронавт будущего? Программист, который летит на орбиту под контролем своего программного обеспечения, или программист из группы НАСА?

Introduction to Astronomy

Прошел Coursera курс по астрономии, теперь есть диплом с отличием.

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

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

Курс для меня оказался объемным. Рассчитывал что нужно будет времени раза в 2-3 меньше. Но вместе с тем, по-моему и в общем, это один из самых хороших курсов на Coursera. Качественные материалы, доступный способ преподнесения, отличные задания (на то, чтобы разораться в предмете) — создают минимальный порог вхождения, подогревают интерес и позволяют самому определить глубину погружения в предмет.

Естественно, про астрономию все знать после него не получится, но общее понимание всемирных процессов будет на другом уровне.

Например, теперь знаю, что Галилей открыл первый закон Ньютона; Коперник победил Птолемея не потому что проще или точнее, а потому, что фазы Венеры и спутники Юпитера; как греются и насколько газовые гиганты изнутри; почему на Луне средняя и максимальная температура такая, она определяется физически очень точно и просто; как Юпитер выгнал остальных гигантов на более внешние орбиты; почему двойные и тройные системы важны; почему часы в подвале вашего дома идут не так, как на крыше; кто такой бозон Хиггса и зачем его искали; почему Вселенная практически наверняка плоская, и скорее всего не одна…

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

120 лет жизни — только начало

"120 лет жизни — только начало" — книга Алексея Москалёва (блогоссылка), только приехала с oz.by. Это наверно первая из книг по современной геронтологии, обладающая практическим применением, серьезностью и подтвержденностью изложения, а также не являющейся доступной для понимания обычным людям.

В oz-by варианте уже исправлены многие предыдущие опечатки.

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

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

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

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

Необходимость одного приоритета — три разных причины

Когда появляется две важные задачи, Буриданов осёл начинает судорожно щипать траву…

Мое

Рассмотрим две задачи, каждую из которых хочется или нужно сделать. Если между ними не ставить жестко приоритет, то оказывается, можно попасть в целых три ловушки.

Первая из них — Буриданов осел. Если у нас две задачи, то мы можем потерять кучу времени и сил на определение того, какую из них нужно раньше делать.

Вторую из них кажется, видел то ли у блоге, то ли на whiteboard Славы Костина. И там была такая картинка:

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

Кроме двух, ещё существует как минимум третья ловушка. Если первая была философско-логическая, а вторая организационная, то эта — психологическо-биологическая. Речь пойдет о т.н. эффекте «смещенная активность». О нем популярно показано тут, непопулярно можно почитать в книжках по дрессировке, а без популярности изложу сейчас сам (;

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

И человек, вместо того, чтобы заниматься важными А или Б, начинается заниматься фигней В.

Отличительная особенность этой штуки в том, что она прошита у нас на базовом аппаратном уровне, и если её не побеждать сознательно (усилием воли устанавливать один самый важный приоритет), то …