Мы решили объединить все наши знания в единый труд, в котором будут рассмотрены сразу все вопросы, касающиеся 64-битного программирования. Для оформления в виде статьи материала оказалась слишком много и мы решили представить его в виде курса уроков.

Кратко опишу курс "Уроки разработки 64-битных приложений на языке Си/Си++" и приведу его содержание.

Курс посвящен созданию 64-битных приложений на языке Си/Си++ и ориентирован на разработчиков, использующих среду Visual Studio 2005/2008. Разработчики для других 64-битных операционных систем также узнают много интересного. В курсе будут рассмотрены все этапы, позволяющие создать новое надежное 64-битное приложение или выполнить миграцию существующего 32-битного кода на 64-битную систему.

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

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

Содержание курса:

• Урок 01. Что такое 64-битные системы.
• Урок 02. Поддержка 32-битных приложений.
• Урок 03. Перенос кода на 64-битные системы. За и против.
• Урок 04. Создание 64-битной конфигурации.
• Урок 05. Сборка 64-битного приложения.
• Урок 06. Ошибки в 64-битном коде.
• Урок 07. Проблемы выявления 64-битных ошибок.
• Урок 08. Статический анализ для выявления 64-битных ошибок.
• Урок 09. Паттерн 01. Магические числа.
• Урок 10. Паттерн 02. Функции с переменным количеством аргументов.
• Урок 11. Паттерн 03. Операции сдвига.
• Урок 12. Паттерн 04. Виртуальные функции.
• Урок 13. Паттерн 05. Адресная арифметика.
• Урок 14. Паттерн 06. Изменение типа массива.
• Урок 15. Паттерн 07. Упаковка указателей.
• Урок 16. Паттерн 08. Memsize-типы в объединениях.
• Урок 17. Паттерн 09. Смешанная арифметика.
• Урок 18. Паттерн 10. Хранение в double целочисленных значений.
• Урок 19. Паттерн 11. Сериализация и обмен данными.
• Урок 20. Паттерн 12. Исключения.
• Урок 21. Паттерн 13. Выравнивание данных.
• Урок 22. Паттерн 14. Перегруженные функции.
• Урок 23. Паттерн 15. Рост размеров структур.
• Урок 24. Фантомные ошибки.
• Урок 25. Практическое знакомство с паттернами 64-битных ошибок.
• Урок 26. Оптимизация 64-битных программ.
• Урок 27. Особенности создания инсталляторов для 64-битного окружения.
• Урок 28. Оценка стоимости процесса 64-битной миграции Си/Си++ приложений.

Сначала я ждал, пока привезут джойстик. Заказывал по принципу "приличный, но недорогой", потому что связываться с чем-то серьезным из-за неведомой игры как-то не улыбалось. В конце концов, если влюблюсь, никогда не поздно купить другой. По рекомендации знающих парней остановился на Genius Flight 2000 F-23, стоящем в розницу около 600 рублей. Последний раз я подключал дома джойстик в детстве, когда у меня был советский компьютер "Сура". С тех пор в этой сфере, оказывается, произошло немало изменений, и, вопреки низкой цене, Genius F-23 произвел на меня глубокое впечатление. Здоровый такой, добротный, кнопок туча. Установился безо всяких драйверов, чем порадовал безмерно.

А вот с игрой веселье началось с самого начала. Коробку-то с ней мне выделили, но категорически не рекомендовали устанавливать Rise of Flight с диска: дескать, там совсем старая версия, и придется качать апдейтов ровно столько же, сколько весит первоначальный дистрибутив. Дали секретный линк на обновленный образ, который я за ночь и утянул. Устанавливаю, запускаю, и тут же ощущаю в полной мере русский размах: милая игрушечка без лишних слов находит и начинает тянуть апдейтик на... 971 мегабайт. Правда здорово? Уверен, пользователи в регионах просто взвоют от такого счастья.

Дожидаюсь установки "патча", запускаю Rise of Flight и наслаждаюсь классическим интерфейсом российской игры в стиле "Это мы обзовем и засунем так, чтобы вы никогда в жизни не нашли". Не, я понимаю, что хардкорному любители авиасимуляторов все будет понятно с первого взгляда, но сколько их, таких суровых парней? А нас, нюбов, довольно много, и нельзя ли к нам чуть-чуть понежнее? Ну пожалуйста? Я не ропщу по поводу того, что взлететь первый раз мне удалось лишь через добрый час тыканий по кнопкам, это как раз нормально для произведений подобного жанра. Но когда за то же время не удается найти в меню пункт, которого просто не может не быть - это уже перебор. Нет, серьезно - я смог отыскать опции, несколько облегчающие игру для начинающего, только после подробного - по пунктам! - инструктажа моего товарища из neoqb. Иначе, пардон, никак.

Сама игра очень красивая, ничуть не хуже, чем ролике, на который я давал линк в прошлом посте. Но, как говорится, есть нюанс: даже на могучем Core i7-965 Extreme Edition, пяти гигабайтах памяти и GeForce 275 Rise of Flight периодически подтормаживает. И это - далеко не при всех графических опциях на максимуме. Одно хорошо: все ядра процессора используются достаточно эффективно, чему косвенное подтверждение - приз зрительских симпатий в Level Up 2009.

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

Но есть у Rise of Flight одно неоспоримое достоинство. По разным вопросам, с ней связанным, я переговорил с кучей людей, причем со многими из них за неделю мы написали друг другу в "аське" больше, чем за весь прошлый год. И даже договорились встретиться живьем.

Побольше бы таких игр.

P.S. Кстати, я уже купил билеты, и планирую 18 февраля выдвинуться в Нижний Новгород, чтобы побывать в филиале Intel и встретиться с читателями, настоящими и будущими. Записаться на встречу можно у Дмитрия Оганезова

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

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

Можно выделить 2 типа грид-систем:

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

Для создания гридов рабочих станций используется следующее программное обеспечение:

1. системы добровольных вычислений: BOINC, XWHEP, Folding@home
2. системы внутрикорпоративных вычислений: Condor

Для сервисных гридов в свою очередь используется следующее промежуточное программное обеспечение:

1. gLite
2. Globut Toolkit
3. Unicore

В России создано несколько крупных грид-систем: RDIG, РИСП, СКИФ-ГРИД (Unicore). Также наша страна принимает участие в работе и международных, европейских гридов: EGEE (gLite), DEISA.

Ссылки:

gridclub.ru - сайт, посвященный грид-вычислениям

По мотивам лекции "Введение в распределенные и параллельные вычисления", прочитанной М.А. Посыпкиным 25 января 2010 г. в МИИТ.

На самом деле, опуская технику программирования с использованием MPI/OpenMP и т.д., кому нужны большие вычислительные ресурсы, описанные, например, тут parallel.ru/russia/russian_clusters.html? Что именно считают на гигантах из этого списка - www.top500.org?

Top 500 еще как-нибудь показывает срезы использования в "Областях применения" ( Application Area), что, конечно, помогает составить некое представление, но… как узнать больше?

Ответ есть, причем довольно хорошо описанный и на большом количестве примеров. Рекомендую посмотреть вот на эту страницу hpc-russia.ru/book_ready.html

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

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

Но помимо сказанного, у ключа /Wp64 есть еще один недостаток, который путает программистов, которые не знакомы с ним. Это касается проблемы разбора кода, содержащего некоторые шаблоны. Рассмотрим пример.

На просторах интернета, можно найти в комментариях к блогу разработчиков Visual C++ следующий пример:

vector<size_t> vs; // создаем вектор элементов size_t
vector<unsigned int> vi; // создаем вектор элементов unsigned int
size_t s; // есть переменная типа size_t
unsigned int i; // есть переменная типа unsigned int
vs[0] = s; // не должно быть warning
vs[0] = i; // не должно быть warning
vi[0] = s; // должно быть warning (*0)
vi[0] = i; // не должно быть warning
s = vs[0]; // не должно быть warning
i = vs[0]; // должно быть warning (*1)
s = vi[0]; // не должно быть warning
i = vi[0]; // не должно быть warning (*2)

Обращаю внимание, что в 32-битном режиме типы size_t и unsigned int должны совпадать.

Теперь скомпилируем этот код в 32-битном режиме в Visual C++ 2005 и получим следующие сообщения. В строке отмеченной (*1) как и должно:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Но в строке (*2) выдается также:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Хотя никакого сообщения здесь быть не должно.

И при этом в строке (*0) "забыто" сообщение.

Если же скомпилировать код в 64-битном режиме, то на строки, отмеченные как (*0) и (*1) как и должно выдается сообщение:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Автор примера Stephan T. Lavavej говорит о проблемах с реализацией ключа в /Wp64 в шаблонах. Дело в том, что технически ключ компилятора /Wp64 реализуется через специальное ключевое слово __w64, добавляемое к описанию типа:

#ifdef _WIN64
  typedef __int64 MySSizet;
#else
  typedef int __w64 MySSizet; // Add __w64 keyword
#endif

Однако это ключевое слово не вводит нового типа данных, поэтому шаблонные классы vs и vi из этого кода одинаковы:

typedef __w64 unsigned int   size_t;
vector<__w64 unsigned int> vs;
vector<unsigned int> vi;

И хотя вроде бы vs и vi имеют разный тип, компилятор считает их не без оснований одинаковыми и выдает неправильную диагностику.

Что делать? В Microsoft Connect заведена ошибка, но как там написано, править ее не будут. Во-первых, не понятно как, а, во-вторых, это актуально только для ключа /Wp64, который объявлен deprecated и будет удален.

Разрабатываемый нами анализатор Viva64 (входящий в состав PVS-Studio), хотя тоже не идеален при работе с шаблонами, в данном случае успешно выдает предупреждения для данного кода, но основываясь на других правилах. В частности, если не отключено предупреждение V101, то он выдает предупреждение при попытке неявного расширения unsigned до типа size_t, что может также скрывать ошибку. Таким образом, анализатор Viva64 выдаст следующее:

std::vector<size_t> vs;
std::vector<unsigned int> vi;
size_t s;
unsigned int i;
vs[0] = s;
vs[0] = i; //V101: Implicit assignment
           //type conversion to memsize type.
vi[0] = s; //V103: Implicit type conversion
           //from memsize to 32-bit type.
vi[0] = i;
s = vs[0];
i = vs[0]; //V103: Implicit type conversion
           //from memsize to 32-bit type.
s = vi[0]; //V101: Implicit assignment
           //type conversion to memsize type.
i = vi[0];

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

std::vector<unsigned int> vi;
for (size_t i = 0; i < 10; i++)
  vi[i] = i;

Здесь компилятор выдает предупреждение:

warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data

Анализатор Viva64 в свою очередь учитывает, что значение переменной "i" лежит в диапазоне [0..10] и данный код не может привести к ошибке. В результате никакие диагностические сообщения не выдаются.

Статический анализ в Team System можно включить не только из командной строки, но и из оболочки. Для этого в настройках C++-проекта надо выбрать вкладку Configuration Properties->C/C++->Advanced и включить "Enable Code Analysis For C/C++", как показано на рисунке.

Этот статический анализ довольно хорошо работает и действительно позволяет найти проблемы в коде. Однако все это до тех пор, пока однажды вы не получите сообщение D9040:

Command-Line Warning D9040

Error Message

ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler

The /analyze command line option is supported only on x86 versions of Visual Studio Team System. It is not available for x64 or Itanium compilers, or for other versions of Visual Studio besides Visual Studio Team System. To remedy this warning, either switch to the x86 version of Visual Studio Team System, or remove the command line option.

Увы, но опция /analyze, которая только начала набирать популярность среди программистов, не доступна для x64 и Itanium компиляторов. Причем это ограничение есть и в Visual Studio 2005, и в Visual Studio 2008.

Поэтому если нужно использовать статический анализ при использовании x64 и Itanium компиляторов, то решение только одно – использовать сторонний инструмент. Например, анализатор кода Viva64, входящий в состав PVS-Studio, который помимо x86, поддерживает и x64, и Itanium платформы.

Мы решили разобраться с терминологией, чтобы придерживаться наиболее правильного толкования этих понятий. В ходе исследования, мы нашли работу В.В. Кулямина "Методы верификации программного обеспечения" [1]. В ней дается развернутое описание этих терминов, и мы приняли решение в дальнейшем опираться на определения, данные в этой работе. Приведем некоторые выдержки их этой работы, относящиеся к верификации и валидации.

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

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

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

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

Различие между верификацией и валидацией проиллюстрировано на рисунке 1.

Рисунок 1 – Соотношение верификации и валидации

Приведенные определения получены некоторым расширением определений из стандарта IEEE 1012 на процессы верификации и валидации [2]. В стандартном словаре терминов программной инженерии IEEE 610.12 1990 года [3] определение верификации по смыслу примерно то же, а определение валидации несколько другое – там говорится, что валидация должна проверять соответствие полученного в результате разработки ПО исходным требованиям к нему. В этом случае валидация являлась бы частным случаем верификации, что нигде в литературе по программной инженерии не отмечается, поэтому, а также потому, что оно поправлено в IEEE 1012 2004 года, это определение следует считать неточным. Частое использование фразы B. Boehm'а [4]:

также добавляет путаницы, поскольку афористичность этого высказывания, к сожалению, сочетается с двусмысленностью. Однако многочисленные труды его автора позволяют считать, что он подразумевал под верификацией и валидацией примерно те же понятия, которые определены выше. Указанные разночтения можно проследить и в содержании стандартов программной инженерии. Так, стандарт ISO 12207 [5] считает тестирование разновидностью валидации, но не верификации, что, по-видимому, является следствием использования неточного определения из стандартного словаря [3].

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

Библиографический список

1. В.В. Кулямин "Методы верификации программного обеспечения". Институт системного программирования РАН 109004, г. Москва, ул. Б. Коммунистическая, д. 25.http://www.viva64.com/go.php?url=282
2. IEEE 1012-2004 Standard for Software Verification and Validation. IEEE, 2005.
3. IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology, Corrected Edition. IEEE, February 1991.
4. B. W. Boehm. Software Engineering; R&D Trends and Defense Needs. In R. Wegner, ed. Research. Directions in Software Technology. Cambridge, MA:MIT Press, 1979.
5. ISO/IEC 12207 Systems and software engineering - Software life cycle processes. Geneva, Switzerland: ISO, 2008.

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

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

Я это к тому, что в скором времени мы можем фактически лишиться ряда любимых игровых жанров. Например, кто сейчас вспомнит, что еще 15 лет назад авиасимуляторы выходили по несколько десятков ежегодно? Что 10 лет назад регулярно и в изобилии появлялись качественные, "дорого" сделанные квесты? Замечаем ли мы, как обмелела ее недавно полноводная река 3D-шутеров?

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

Но я сам никогда не смирюсь с кончиной сериала про Ларри Лаффера. И очень надеюсь поиграть в Crysis IV.

Вчера утром коллега Мария Осеева, менеджер проекта Intel® Academic Research Team (ART), пригласила меня рассказать представителям нескольких российских университетов о проектах ISN, и в частности – об академическом сообществе.

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

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

Что такое академическое сообщество ISN?

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

В чем фишка?

Главная ценность для тех, кто преподает – возможность открытого обмена учебными материалами. Тексты лекций, полные курсы, лабораторные работы со всего мира – от Кембриджа и Стэнфордского университета и до Бангалора. Впрочем, мы потихоньку движемся от PDF и PPT к подкастам, видео и вебинарам. Поэтому не исключено, что кого-то образовательное видео из серии Teach Parallel заинтересует больше, чем задания к лабораторным работам.

Кто есть кто в академическом сообществе?

Комьюнити менеджер академического сообщества – мой коллега Пол Штанберг из Америки (Paul Steinberg). Его можно увидеть и услышать на этой странице, а что-то ему написать – вот на этой. Хорошо нам знакомый Клэй-Судья Бришерс (Clay Breshears) также работает Intel Software College, что по сути есть "скрытая" часть академического сообщества. За наши активности в Европе отвечает Стефани Брюмат (Stephanie Brumat). Кстати, она же по совместительству занимается французским ISN.
В России, вплоть до особых распоряжений, можно обращаться ко мне или Светлане.

Что дает регистрация?

Формально доступ к материалам сообщества не требует регистрации в программе Intel® Academic Community, но зарегистрироваться все-таки стоит. Почему? Во-первых, зарегистрировавшись, вы можете получить бесплатный пакет лицензий на программное обеспечение для лабораторий, а так же скидки на коммерческие лицензии. Во-вторых, появится шанс попасть на специальные тренинги. Ну и наконец, вы просто улучшите статистику: приятно будет видеть название родного ВУЗа по соседству с Кембриджом и Стэнфордом.

Сколько стоит регистрации?

Нисколько. Это совершенно бесплатно.

Адрес сайта?

• Главная страница сообщества.
• Бета-версия главной русской страницы.
• Страница, посвященная материалам о параллельных вычислениях.
• Стоит заглянуть в блог академического сообщества и его форум.
• То же на русском: блог, форум.

Сколько учебных заведений уже участвует программе?

На данный момент в академическом сообществе зарегистрировано 3000 преподавателей из 1700+ университетов, из 80+ стран. К сожалению, в этом списке пока только 37 Российских университетов. Надеюсь, что после публикации этого поста Россия будет представлена существенно шире .

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

Всем удачи!

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

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

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

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

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

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

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

Что получаем:

• Достойна статья быть ВАКовской или нет, она быстро публикуется, причём становится доступной через интернет. А поэтому автор получает быстрый фидбек.
• Публикация автором множества схожих статей будет быстро замечена, а значит это скорее всего будет невыгодно авторам. Получаем решение ещё одной проблемы, о которой я ещё не упоминал: некоторые авторы просто "работают на статистику", публикуют кучу никому не нужных статей, вместо одной-двух действительно содержательных. Мне лично это мешает искать нужную информацию, так как это само по себе увеличивает объём всей информации, поэтому считаю это проблемой.
• Научные материалы концентрируются на одном ресурсе, и притом как-то классифицируются и ранжируются. С точки зрения поиска - красота.
• Оценка статьи будет более объективной как мне кажется.

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

Я конечно не надеюсь, что в скором времени что-то такое можно будет сделать. Скорее всего это станет возможно, когда все члены РАН будут иметь год рождения не раньше 1970-80-хх. Т.е. будут уверенными и регулярными пользователями интернета.

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