пятница, 6 ноября 2015 г.

Заимствование через перевод

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

Открываем введение диссертации Промского А. В. «Формальная семантика C-Light программ и их верификация методом Хоара» и смотрим:

Тысячекратный рост производительности компьютеров за последние 25 лет привел к росту размеров программ в тех же пропорциях. Область применения огромных программ (от 1 до 40 млн. строк) значительно увеличилась за последнее десятилетие. Для таких больших программ является необходимым требование разработки по разумной цене и дальнейшей модификации и поддержки в течении всего их жизненного цикла (часто более 20 лет). Размеры и эффективность программ и коллективов, занимаюш;ихся их проектированием и сопровождением, не могут расти в одинаковых пропорциях. При достаточно устоявшейся (и зачастую оптимистичной) оценке в одну ошибку на тысячу строк кода такие программы быстро могут стать неуправляемыми. Поэтому в ближайшие 10 лет проблема надейюности программного обеспечения может стать одним из основных вызовов для современных компьютерно-зависимых обществ.

Никаких ссылок, просто текст. Теперь открываем статью P Cousot, «Abstract Interpretation Based Formal Methods and Future Challenges»:

The evolution of hardware by a factor of 106 over the past 25 years has lead to the explosion of the size of programs in similar proportions. The scope of application of very large programs (from 1 to 40 millions of lines) is likely to widen rapidly in the next decade. Such big programs will have to be designed at a reasonable cost and then modified and maintained during their lifetime (which is often over 20 years). The size and efficiency of the programming and maintenance teams in charge of their design and follow-up cannot grow in similar proportions. At a not so uncommon (and often optimistic) rate of one bug per thousand lines such huge programs might rapidly become hardly manageable in particular for safety critical systems. Therefore in the next 10 years, the software reliability problem is likely to become a major concern and challenge to modern highly computer-dependent societies.

И перевод не нужен, т.к. был дословно взят кусок, переведен, и вставлен прямо в начало введения, т.е. всей диссертации. Правда только, копирование почему-то из 106 роста сделало 103 рост, единственная разница. Остальное 100%-ное попадание.

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


четверг, 3 сентября 2015 г.

Новые книги по геронтологии

Неожиданно в короткий промежуток времени вышли две книги по геронтологии на русском. Это перевод (читать онлайн забесплатно) Transcend'a (Курцвейл и Гроссман), и российская книга «Профилактика старения для всех» (pdf).

Здесь Transcend описан достаточно подробно. В связи с этим, в данном сообщение информация о книге «Профилактика старения для всех» и её сравнение с Transcend'ом.

Основные особенности «Профилактика старения для всех» следующие:

  • Высказаны и обоснованы основные тезисы геронтологии. Т.е. существенная часть посвящена тому, чтобы уговорить читателя, что биологически можно жить дольше.
  • Описаны основные механизмы старения (описание) на доступном обычному читателю языке. Т.е. основые теории-рабочие-гипотезы, на основании которых строятся различные стратегии по продолжению качественной и здоровой жизни.
  • В целом информация более свежая. Т.е. есть больше данных новых исследований и вероятных подходов, хотя разница не большая.
  • Книга приближена к практике, т.е. значительное количество информации применимо, и в этом плане книга методична. Но вот с Transcend её не сравнить — Transcend он готовое руководство к действию, а здесь все придется собирать самому и не факт, что останется желание все довести до конца. Но с другой стороны, по сравнению с «120 лет только начало», она практичнее, т.к. книга Москалева весьма научно-специфична и из неё сложно обычному читателю взять что-то практичное.

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

Есть и там и там много ссылок на научные и не только источники (>1000 для Transcend и >400 для «Профилактика старения для всех»).

Transcend более ориентиирован на американскую специфику. Это мало чего решает, но в «Профилактика старения для всех» есть дополнительная информация, локализованная для РФ.

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

Коллеги подсказывают, что на неделях должна выйти книга Стефана Таннебергера «Искусство стареть» (Stephan Tanneberger, Alt werden) — перевод с немецкого, 2013. Как появится информация, обновлю пост.

UPD: Вышла, доступна в магазине.


среда, 2 сентября 2015 г.

Нерасширение НАТО на Восток: американский профессор истории Питер Кузник

Есть в последней политической истории такой вопрос о том, что НАТО обещало Горбачеву не расширяться на восток. Как на любую политическую тему есть много спекуцляций, когда два лагеря говорят совершенно противоположные утверждения, и здесь не исключение.

Если хочется разобраться, а не просто иметь Мнение ради того, чтобы принадлежать какой-то социальной Группе с дополнительными очками ЧСВ, то понятно, что поверхностное мнение вряд ли что-то дает. Соответственно, приходится копать. А политика такая вещь, что вообще раскопать и более-менее достоверно понять что-то очень сложно.

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

Т.о., ещё раз, это сообщение не предназначено для подтверждения или опровержения какой-либо точки зрения.

Изначально началось все с цитаты из фильма Питера Кузника «Нерассказанная история США» [1]:

Горбачев надеялся, что новая степень доверия между странами позволит отказаться от НАТО и Варшавского договора. Он был готов пойти на объединение Восточной и Западной Германии при условии, что НАТО не будет расширяться на восток. Буш дал ему слово, но в 1993-м году он покинул свой пост, а Горбачев поплатился за свое доверие к Америке когда Клинтон и Буш-младший преддвинули НАТО вплотную к границам России. Русские поняли, что их предали. США долгое время утверждали, что не давали никаких обещаний. Но недавно обнародованные документы посла США в СССР, а также рассекреченные британские и западно-германские документы подтверждают существование четкой договоренности.

Когда американский профессор истории говорит так, оно звучит иначе, нежели из политизированных источников. Но вот для более детальной иллюстрации цитата из книги Кузника, отражающая более подробно [2]:

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

  1. Нарассказанная история США. часть 9: «Буш и Клинтон: Растрата мира – Новый мировой порядок», 15-я минута.
  2. O. Stone, P. Kuznick. The Untold History of the United States. — Gallery Books. — 2012.

понедельник, 13 июля 2015 г.

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

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

Данная разница визуально проявляется в количестве ссылок на литературу. При рассмотрении статьи в русскоязычном типично наличие 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, половина из которых статьи автора.

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

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


вторник, 9 июня 2015 г.

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

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

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


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

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

Это было в небольшом посте блога, написанном 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. "Иногда они дерутся как кошки и собаки. Разработчики хотят поймать все свои ошибки. Верификаторы возмущаются, что это забирает их время, выделенное на проверку программного обеспечения."

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