Адрес БЕН РАН
В начале этого года я писал о нестандартной нумерации домов на Садовой улице в Санкт-Петербурге. Именно на этой улице расположено Главное здание Российской национальной библиотеки, в которой я более 7 лет руководил информатизацией. По какому-то мистическому совпадению адрес Центрального здания БЕН РАН, которой я управлял 5 лет, тоже имеет любопытную историю.
Центральное здание БЕН РАН – угловое. Оно одновременно стоит на двух улицах – Знаменке и Малом Знаменском переулке (см. фото №1). Существует правило, в соответствии с которым для домов на нескольких улицах приоритет отдаётся той, где расположен главный вход. Раньше у БЕН РАН главный вход был на улице Знаменка (см. фото №2). Так что адрес присвоили именно на этой улице. За основу были взяты данные Почты России. Адрес получился красивым – «Знаменка 11/11».
Впоследствии Знаменка стала правительственной трассой: периодически её стали перекрывать, чтобы кортежи автомобилей беспрепятственно проезжали от Арбата в Кремль. В целях безопасности силовые структуры потребовали перенести вход со Знаменки на Малый Знаменский переулок. При этом юридический адрес менять не стали. Во-первых, учредителю было не до того, а во-вторых, «Знаменка 11/11» выглядит гораздо привлекательнее, чем «Малый Знаменский переулок, д. 11/11, стр. 2».
В 2011 году произошла адресная реформа: разрозненные базы данных адресов объединили в одну систему – Федеральную информационную адресную систему (ФИАС). В основу ФИАСа легла система КЛАДР, которая использовалась в ФНС. А кадастр, Почта России и остальные системы постарались найти для своих адресов соответствие в ФИАС. Иногда безуспешно. Как назло, почтовый адрес БЕН РАН – «Знаменка 11/11» в ФИАСе отсутствует, и добавить его туда никак нельзя (мы пытались). Получилась юридическая коллизия: библиотека располагается по адресу, которого не существует в главной адресной системе страны.
Более того, Знаменка находится на территории района Арбат, а Малый Знаменский переулок – в Хамовниках. Арбатское отделение налоговой напрочь отказалось принимать налоги и отчёты от организации, расположенной по несуществующему адресу. Хамовническая налоговая была более лояльной – налоги и отчёты от организации из другого района принимала, но постоянно штрафовала за это.
В какой-то момент у Минобрнауки, которое является учредителем БЕН РАН, дошли руки до решения этой проблемы, и оно поменяло Устав БЕН РАН, указав новый юридический адрес на Малом Знаменском переулке. Теперь официальный адрес БЕН РАН совпадает с главным входом (см. фото №3) и соответствует всем нормам, законам и правилам.
P.S. Если интересна история здания, в котором располагается БЕН РАН, то этому посвящена целая глава подарочного издания, изданного под моим руководством к 50-летию БЕН РАН. Ознакомиться с содержанием этого издания можно на моём сайте: https://olegshorin.com/ru/publications/library-for-natural-sciences/ .
#Algorithm
#DigitalTransformation
#Library
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/benran-address/
В начале этого года я писал о нестандартной нумерации домов на Садовой улице в Санкт-Петербурге. Именно на этой улице расположено Главное здание Российской национальной библиотеки, в которой я более 7 лет руководил информатизацией. По какому-то мистическому совпадению адрес Центрального здания БЕН РАН, которой я управлял 5 лет, тоже имеет любопытную историю.
Центральное здание БЕН РАН – угловое. Оно одновременно стоит на двух улицах – Знаменке и Малом Знаменском переулке (см. фото №1). Существует правило, в соответствии с которым для домов на нескольких улицах приоритет отдаётся той, где расположен главный вход. Раньше у БЕН РАН главный вход был на улице Знаменка (см. фото №2). Так что адрес присвоили именно на этой улице. За основу были взяты данные Почты России. Адрес получился красивым – «Знаменка 11/11».
Впоследствии Знаменка стала правительственной трассой: периодически её стали перекрывать, чтобы кортежи автомобилей беспрепятственно проезжали от Арбата в Кремль. В целях безопасности силовые структуры потребовали перенести вход со Знаменки на Малый Знаменский переулок. При этом юридический адрес менять не стали. Во-первых, учредителю было не до того, а во-вторых, «Знаменка 11/11» выглядит гораздо привлекательнее, чем «Малый Знаменский переулок, д. 11/11, стр. 2».
В 2011 году произошла адресная реформа: разрозненные базы данных адресов объединили в одну систему – Федеральную информационную адресную систему (ФИАС). В основу ФИАСа легла система КЛАДР, которая использовалась в ФНС. А кадастр, Почта России и остальные системы постарались найти для своих адресов соответствие в ФИАС. Иногда безуспешно. Как назло, почтовый адрес БЕН РАН – «Знаменка 11/11» в ФИАСе отсутствует, и добавить его туда никак нельзя (мы пытались). Получилась юридическая коллизия: библиотека располагается по адресу, которого не существует в главной адресной системе страны.
Более того, Знаменка находится на территории района Арбат, а Малый Знаменский переулок – в Хамовниках. Арбатское отделение налоговой напрочь отказалось принимать налоги и отчёты от организации, расположенной по несуществующему адресу. Хамовническая налоговая была более лояльной – налоги и отчёты от организации из другого района принимала, но постоянно штрафовала за это.
В какой-то момент у Минобрнауки, которое является учредителем БЕН РАН, дошли руки до решения этой проблемы, и оно поменяло Устав БЕН РАН, указав новый юридический адрес на Малом Знаменском переулке. Теперь официальный адрес БЕН РАН совпадает с главным входом (см. фото №3) и соответствует всем нормам, законам и правилам.
P.S. Если интересна история здания, в котором располагается БЕН РАН, то этому посвящена целая глава подарочного издания, изданного под моим руководством к 50-летию БЕН РАН. Ознакомиться с содержанием этого издания можно на моём сайте: https://olegshorin.com/ru/publications/library-for-natural-sciences/ .
#Algorithm
#DigitalTransformation
#Library
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/benran-address/
❤9
CodeBab.ai – помощник для код-ревью
На прошлой неделе в клубе «Цифровые лидеры бизнеса» прошла интереснейшая лекция от коллег из компании Friflex. Напомню, Friflex – это компания, в которой мы часто собираемся на так называемые «офисники».
Лекция была посвящена проблеме код-ревью. Дело в том, что раньше код писался разработчиками вручную, а потом валидировался более опытным тимлидом (см. фото №1). Теперь же код генерируется в огромаднейших масштабах с помощью ИИ, а валидировать весь этот вал продолжает человек. И именно этот человек становится узким горлышком в системе поставке кода (см. фото №2).
Генеральный директор Friflex Пётр Чернышев и его коллега Юрий Петров, который является руководителем агентной и кроссплатформенной разработки, рассказали нам о сервисе CodeBab.ai, который был ими разработан внутри компании. Суть этого сервиса заключается в том, что это глобальный оркестратор различных агентов, ставящийся поверх gitlab, который перед тем, как передать merge request тимлиду, проверяет его с помощью специальных промтов на соответствие различным правилам. В итоге тимлиду попадает на проверку только тот код, который уже прошёл предварительную «проверку на вшивость».
Решение вполне рабочее, оно справляется с поставленной задачей.
Но я считаю, что оно не является идеальным, так как с использованием CodeBab.ai качество кода повышается, но количество запросов на слияние хоть и уменьшается, но не сильно – то есть не устраняется первоначальная причина задержек при code review. А значит, при дальнейшем росте количества разработчиков, надо будет опять что-то придумывать.
Как мне кажется, произошёл существенный слом в парадигме программирования, из-за этого привычный механизм ветвления кода стал давать сбои. И мы пытаемся придумать какое-то стороннее решение, позволяющее прежнему механизму хоть как-то функционировать. Я думаю, что изящное решение должно каким-то образом поменять саму логику ветвления кода с последующими merge request’ами.
Мне почему-то сразу вспомнилась история про замену ручного труда станками. И последующее гениальное решение Форда по созданию конвейера. Немного поразмышляв, я понял, что в данном случае аналогия не применима, потому что конвейер Форда заточен на последовательные действия. А разработка ПО – параллельный процесс, осуществляемый множеством разработчиков, и терять этот параллелизм ради адаптации под конвейерное решение – глупо.
В общем, пока что я ничего гениального не придумал, но задачка эта засела у меня в мозгу, и я к ней периодически мысленно возвращаюсь. Как-нибудь на досуге почитаю научные исследования на эту тему, потому что мне, как выпускнику кафедры Системного программирования ВМК МГУ, интересно следить за эволюционным развитием языков программирования в целом, и за прогрессом в области командной разработки в частности.
#AI
#Algorithm
#Management
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/codebab-ai/
На прошлой неделе в клубе «Цифровые лидеры бизнеса» прошла интереснейшая лекция от коллег из компании Friflex. Напомню, Friflex – это компания, в которой мы часто собираемся на так называемые «офисники».
Лекция была посвящена проблеме код-ревью. Дело в том, что раньше код писался разработчиками вручную, а потом валидировался более опытным тимлидом (см. фото №1). Теперь же код генерируется в огромаднейших масштабах с помощью ИИ, а валидировать весь этот вал продолжает человек. И именно этот человек становится узким горлышком в системе поставке кода (см. фото №2).
Генеральный директор Friflex Пётр Чернышев и его коллега Юрий Петров, который является руководителем агентной и кроссплатформенной разработки, рассказали нам о сервисе CodeBab.ai, который был ими разработан внутри компании. Суть этого сервиса заключается в том, что это глобальный оркестратор различных агентов, ставящийся поверх gitlab, который перед тем, как передать merge request тимлиду, проверяет его с помощью специальных промтов на соответствие различным правилам. В итоге тимлиду попадает на проверку только тот код, который уже прошёл предварительную «проверку на вшивость».
Решение вполне рабочее, оно справляется с поставленной задачей.
Но я считаю, что оно не является идеальным, так как с использованием CodeBab.ai качество кода повышается, но количество запросов на слияние хоть и уменьшается, но не сильно – то есть не устраняется первоначальная причина задержек при code review. А значит, при дальнейшем росте количества разработчиков, надо будет опять что-то придумывать.
Как мне кажется, произошёл существенный слом в парадигме программирования, из-за этого привычный механизм ветвления кода стал давать сбои. И мы пытаемся придумать какое-то стороннее решение, позволяющее прежнему механизму хоть как-то функционировать. Я думаю, что изящное решение должно каким-то образом поменять саму логику ветвления кода с последующими merge request’ами.
Мне почему-то сразу вспомнилась история про замену ручного труда станками. И последующее гениальное решение Форда по созданию конвейера. Немного поразмышляв, я понял, что в данном случае аналогия не применима, потому что конвейер Форда заточен на последовательные действия. А разработка ПО – параллельный процесс, осуществляемый множеством разработчиков, и терять этот параллелизм ради адаптации под конвейерное решение – глупо.
В общем, пока что я ничего гениального не придумал, но задачка эта засела у меня в мозгу, и я к ней периодически мысленно возвращаюсь. Как-нибудь на досуге почитаю научные исследования на эту тему, потому что мне, как выпускнику кафедры Системного программирования ВМК МГУ, интересно следить за эволюционным развитием языков программирования в целом, и за прогрессом в области командной разработки в частности.
#AI
#Algorithm
#Management
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/codebab-ai/
❤5👍4🔥3
Первый пошёл!
В конце прошлого года я посетил ежегодное закрытое облачное мероприятие Группы Астра. Напомню, что меня туда пригласил Виктор Коноплёв – мой соклубник по сообществу ИТ-управленцев «я-ИТ-ы».
Пообщавшись с Виктором, мы много интересного узнали друг о друге. Оказалось, что Виктор ведёт подкаст, посвящённый, как бы странно это ни звучало, информационным технологиям и людям, которые эти самые информационные технологии создают и развивают.
Виктор пригласил меня принять участие в записи одного из выпусков. Я согласился, поскольку мне было интересно, что же это за зверь такой – подкаст. Раньше я только в записи интервью участвовал, о чём я в своё время уже писал.
Как говорится, не прошло и года, как мы всё-таки записали этот подкаст (см. фото). Надеюсь, что первый мой подкаст не выйдет комом.
С Виктором мы пообщались на следующие темы:
- Мой карьерный трек;
- Специфика цифровизации таких консервативных учреждений, как библиотеки;
- Нюансы применения авторского права в России;
- Особенности функционирования ФГИС «Национальная электронная библиотека»;
- Цифровая трансформация автопрокатного рынка в нашей стране.
Теперь осталось лишь немного подождать, пока будут сделаны монтаж, транскрибация, вычитка субтитров и прочие необходимые действия. Только после этого запись подкаста появится везде и всюду. Что ж, ждём!
А чтобы ждать было не так грустно, предлагаю посмотреть записи моих интервью, которые я давал телеканалу «Про Бизнес»:
- В передаче «IT-трансформация» в 2014 году: https://olegshorin.com/ru/videos/pro-business-tv-it-transformation/
- В передаче «ИТ-Директор» в 2016 году: https://olegshorin.com/ru/videos/pro-business-tv-it-director/
#DigitalTransformation
#Networking
#Shorin
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/the-first-one-is-out/
В конце прошлого года я посетил ежегодное закрытое облачное мероприятие Группы Астра. Напомню, что меня туда пригласил Виктор Коноплёв – мой соклубник по сообществу ИТ-управленцев «я-ИТ-ы».
Пообщавшись с Виктором, мы много интересного узнали друг о друге. Оказалось, что Виктор ведёт подкаст, посвящённый, как бы странно это ни звучало, информационным технологиям и людям, которые эти самые информационные технологии создают и развивают.
Виктор пригласил меня принять участие в записи одного из выпусков. Я согласился, поскольку мне было интересно, что же это за зверь такой – подкаст. Раньше я только в записи интервью участвовал, о чём я в своё время уже писал.
Как говорится, не прошло и года, как мы всё-таки записали этот подкаст (см. фото). Надеюсь, что первый мой подкаст не выйдет комом.
С Виктором мы пообщались на следующие темы:
- Мой карьерный трек;
- Специфика цифровизации таких консервативных учреждений, как библиотеки;
- Нюансы применения авторского права в России;
- Особенности функционирования ФГИС «Национальная электронная библиотека»;
- Цифровая трансформация автопрокатного рынка в нашей стране.
Теперь осталось лишь немного подождать, пока будут сделаны монтаж, транскрибация, вычитка субтитров и прочие необходимые действия. Только после этого запись подкаста появится везде и всюду. Что ж, ждём!
А чтобы ждать было не так грустно, предлагаю посмотреть записи моих интервью, которые я давал телеканалу «Про Бизнес»:
- В передаче «IT-трансформация» в 2014 году: https://olegshorin.com/ru/videos/pro-business-tv-it-transformation/
- В передаче «ИТ-Директор» в 2016 году: https://olegshorin.com/ru/videos/pro-business-tv-it-director/
#DigitalTransformation
#Networking
#Shorin
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/the-first-one-is-out/
👍7🔥2❤1
Фронтир ИИ
Недавно натолкнулся на статью о том, что вышел Grok 4.6, который при Extra High настройках Reasoning’а обходится дешевле, чем Fable 5 Max, Opus 5 Max и GPT-5.6 Sol Max. После беглого прочтения этой статьи у меня появилось стойкое ощущение дежавю.
В конце 90-х годов прошлого столетия существовало неимоверно огромное количество компиляторов. Домашние задания мы делали с помощью самых стандартных Borland С++ и/или Turbo С++. Но если надо было сделать что-то более серьёзное, то мы использовали совершенно другие компиляторы.
Например, в Paragon Software, где я работал системным программистом, было установлено, что всё компилируется только с помощью Watcom C/C++, потому что он создаёт быстрый код. А курсовую по машинной графике мы компилировали исключительно с помощью djgpp (кто-нибудь помнит этот компилятор?), поскольку сам Джон Кармак выбрал этот компилятор для своего Quake за возможность работы с protected mode через DPMI. Про всякие Cygnus/Cygwin, Mingw32 и прочие EGCS’ы я лучше помолчу.
Прошло около 30 лет. Большая часть компаний, выпускавших компиляторы, либо разорились, либо были поглощены. Сейчас у нас есть набор устоявшихся компиляторов (gcc, clang, msvc), которые, в основном, выбираются не за их супер-оптимизированный код, а за возможность создание программы для той или иной операционной системы.
Так и сейчас я наблюдаю, как различные тестеры сравнивают насколько быстрее, дешевле, глубже, чётче, развёрнутее и т.д. (можно ещё 100500 критериев придумать) одна модель превосходит другую в зависимости от размера, количества параметров, настроек ризонинга, контекстного окна, качества претрена и инференса и т.п. И даже если разобраться во всём этом «по гамбургскому счёту», то завтра выйдет новая модель, и всё снова изменится.
Мой подход прост: набор моих задач не требует наличия какого-то супер-пупер уникального свойства, которое есть только у определённой модели со специфическими параметрами. Если честно, в слепом тестировании я не отличу код, выдаваемый Luna Medium, от кода, сгенерированного Sol Extra High. Аналогично, я не отличал экзешники, скомпилированные ваткомом, от экзешников, собранных с использованием djgpp.
Поэтому я пользуюсь тем, что есть под рукой и что решает мои задачи. Гнаться за самым-пресамым ризонингом – смысла не вижу. Главное сейчас – не оказаться на обочине прогресса, игнорируя ИИ полностью. Но и пытаться быть на острие, как это модно сейчас называть, фронтира – не стоит, если, конечно, вы не профессиональный разработчик ИИ-моделей.
С учётом скорости изменений лет через пять всё устаканится, и останется 3-4 модели, каждая из которых будет решать свой класс задач.
P.S. Для тех, кому слова Watcom и Quake – не пустой набор символов, вот ссылка на атмосферный пост про программирование и игры в конце 90-х.
#AI
#DigitalTransformation
#LifeLongLearning
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/ai-frontier/
Недавно натолкнулся на статью о том, что вышел Grok 4.6, который при Extra High настройках Reasoning’а обходится дешевле, чем Fable 5 Max, Opus 5 Max и GPT-5.6 Sol Max. После беглого прочтения этой статьи у меня появилось стойкое ощущение дежавю.
В конце 90-х годов прошлого столетия существовало неимоверно огромное количество компиляторов. Домашние задания мы делали с помощью самых стандартных Borland С++ и/или Turbo С++. Но если надо было сделать что-то более серьёзное, то мы использовали совершенно другие компиляторы.
Например, в Paragon Software, где я работал системным программистом, было установлено, что всё компилируется только с помощью Watcom C/C++, потому что он создаёт быстрый код. А курсовую по машинной графике мы компилировали исключительно с помощью djgpp (кто-нибудь помнит этот компилятор?), поскольку сам Джон Кармак выбрал этот компилятор для своего Quake за возможность работы с protected mode через DPMI. Про всякие Cygnus/Cygwin, Mingw32 и прочие EGCS’ы я лучше помолчу.
Прошло около 30 лет. Большая часть компаний, выпускавших компиляторы, либо разорились, либо были поглощены. Сейчас у нас есть набор устоявшихся компиляторов (gcc, clang, msvc), которые, в основном, выбираются не за их супер-оптимизированный код, а за возможность создание программы для той или иной операционной системы.
Так и сейчас я наблюдаю, как различные тестеры сравнивают насколько быстрее, дешевле, глубже, чётче, развёрнутее и т.д. (можно ещё 100500 критериев придумать) одна модель превосходит другую в зависимости от размера, количества параметров, настроек ризонинга, контекстного окна, качества претрена и инференса и т.п. И даже если разобраться во всём этом «по гамбургскому счёту», то завтра выйдет новая модель, и всё снова изменится.
Мой подход прост: набор моих задач не требует наличия какого-то супер-пупер уникального свойства, которое есть только у определённой модели со специфическими параметрами. Если честно, в слепом тестировании я не отличу код, выдаваемый Luna Medium, от кода, сгенерированного Sol Extra High. Аналогично, я не отличал экзешники, скомпилированные ваткомом, от экзешников, собранных с использованием djgpp.
Поэтому я пользуюсь тем, что есть под рукой и что решает мои задачи. Гнаться за самым-пресамым ризонингом – смысла не вижу. Главное сейчас – не оказаться на обочине прогресса, игнорируя ИИ полностью. Но и пытаться быть на острие, как это модно сейчас называть, фронтира – не стоит, если, конечно, вы не профессиональный разработчик ИИ-моделей.
С учётом скорости изменений лет через пять всё устаканится, и останется 3-4 модели, каждая из которых будет решать свой класс задач.
P.S. Для тех, кому слова Watcom и Quake – не пустой набор символов, вот ссылка на атмосферный пост про программирование и игры в конце 90-х.
#AI
#DigitalTransformation
#LifeLongLearning
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/ai-frontier/
🔥6❤2
Авторский рисунок
На моей лекции на тему «История книг и библиотек» в разговорном клубе SpeakUP Club был задан вопрос о том, какие книги имеет смысл сейчас приобретать для того, чтобы в будущем их стоимость повышалась.
Довольно сложно предположить, какие именно книги или какой тираж в будущем станут ценными. Однако конкретный экземпляр книги автоматически становится редким, если в нём есть пометы известного человека или автора. Поэтому я каждый раз, когда мне автор дарит книгу, прошу сделать в ней дарственную надпись.
У меня уже есть отдельная полка в книжном шкафу, где я храню такие книги. Про некоторые книги я уже писал:
- Книга, побывавшая в космосе и подписанная космонавтами;
- Книга, посвящённая 50-летию БЕН РАН, которую подписала вся редколлегия;
- Книга, написанная Олегом Уткиным – в ней много пересечений с представителями отечественной библиотечной среды.
Сегодня расскажу ещё про один уникальный экземпляр из моей коллекции.
Это книга Сергея Лугинина «Две реки. Резьба по кости».
Сергей Лугинин - один их ведущих косторезов России, яркий представитель творческой интеллигенции коренных народов Севера. Основная тема творчества Сергея Лугинина - искусство и мифология древнего населения Ямала, сохранившиеся в современной традиционной культуре коренных малочисленных народов Севера. Его работы основаны на анализе культуры коренных малочисленных народов и отражают мифологию народов тюменского Севера, эскимосов, якутов и других. Книга «Две реки. Резьба по кости» является иллюстрированной частью серии "Циркумполярная цивилизация", которая рассказывает о феномене симбиоза традиционной северной духовности и современной жизни у народов Севера.
Сергей, как человек творческий, в моём экземпляре сделал не просто авторскую надпись, а добавил ещё и рисунок. Получилось очень оригинально!
Презентацию книги Сергея Лугинина «Две реки. Резьба по кости» мы проводили в БЕН РАН 23 декабря 2020 года. Ознакомиться с кратким роликом о том, как это было, можно на моём сайте: https://olegshorin.com/ru/videos/two-rivers/ .
#Library
#Book
#Preservation
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/authors-drawing/
На моей лекции на тему «История книг и библиотек» в разговорном клубе SpeakUP Club был задан вопрос о том, какие книги имеет смысл сейчас приобретать для того, чтобы в будущем их стоимость повышалась.
Довольно сложно предположить, какие именно книги или какой тираж в будущем станут ценными. Однако конкретный экземпляр книги автоматически становится редким, если в нём есть пометы известного человека или автора. Поэтому я каждый раз, когда мне автор дарит книгу, прошу сделать в ней дарственную надпись.
У меня уже есть отдельная полка в книжном шкафу, где я храню такие книги. Про некоторые книги я уже писал:
- Книга, побывавшая в космосе и подписанная космонавтами;
- Книга, посвящённая 50-летию БЕН РАН, которую подписала вся редколлегия;
- Книга, написанная Олегом Уткиным – в ней много пересечений с представителями отечественной библиотечной среды.
Сегодня расскажу ещё про один уникальный экземпляр из моей коллекции.
Это книга Сергея Лугинина «Две реки. Резьба по кости».
Сергей Лугинин - один их ведущих косторезов России, яркий представитель творческой интеллигенции коренных народов Севера. Основная тема творчества Сергея Лугинина - искусство и мифология древнего населения Ямала, сохранившиеся в современной традиционной культуре коренных малочисленных народов Севера. Его работы основаны на анализе культуры коренных малочисленных народов и отражают мифологию народов тюменского Севера, эскимосов, якутов и других. Книга «Две реки. Резьба по кости» является иллюстрированной частью серии "Циркумполярная цивилизация", которая рассказывает о феномене симбиоза традиционной северной духовности и современной жизни у народов Севера.
Сергей, как человек творческий, в моём экземпляре сделал не просто авторскую надпись, а добавил ещё и рисунок. Получилось очень оригинально!
Презентацию книги Сергея Лугинина «Две реки. Резьба по кости» мы проводили в БЕН РАН 23 декабря 2020 года. Ознакомиться с кратким роликом о том, как это было, можно на моём сайте: https://olegshorin.com/ru/videos/two-rivers/ .
#Library
#Book
#Preservation
Ссылка на оригинал поста: https://shorin.me/blog/2026/08/authors-drawing/
👍5👏1
Три уровня оптимизации
Есть у меня pet-проект – я развиваю свой сайт-портфолио и свой блог. На этих сайтах я обкатываю использование различных инструментов, которые впоследствии применяю и в своей работе.
Есть некоторые базовые вещи, без которых в 2026 году сайт не может нормально существовать:
- Для всего сайта: favicon, robots.txt, sitemap. Даже комментировать не буду.
- Для каждой страницы: title, description, OpenGraph теги. Без этого нормально ссылку на страницу никуда не вставишь и не перешлёшь.
Далее идут несколько уровней оптимизации.
Первый уровень – видимый для человека. Это тексты, расположенные на страницах сайта, и ссылки. У блога текстами выступает содержимое моих постов. А у сайта-портфолио основную часть составляют содержимое моих публикаций (для раздела публикации) и расшифровки видео (для раздела видео). Ссылки же у меня есть везде и всюду – я их планомерно вставляю во все посты на всех платформах, а также добавляю перекрёстные ссылки, если это уместно.
Второй уровень оптимизации человек уже не видит. Это использование структурированной разметки Schema.org (см. фото) в формате JSON-LD. Эта разметка предназначена для поисковых роботов, с её помощью роботам сообщается дополнительная семантическая информация об объектах на сайте. Например, Google очень сильно опирается на возможности этой разметки для выстраивания взаимосвязей среди экосистемы своих сервисов:
- Про Google Scholar я уже писал;
- Правильно размеченная страница, на которой есть ссылка на YouTube-видео, автоматически получает значительный рост при индексации. Это отчётливо видно в Google Search Console (см. фото).
Яндекс разметку Schema.org видит, но я не нашёл признаков того, чтобы он как-то её использовал, поскольку Yandex Cloud Video пока что слишком молод, а аналога Google Scholar у Яндекса нет. Если говорить про VK Видео, то он создан для того, чтобы многомиллионная аудитория соц.сети VK не уходила на сторонние ресурсы при просмотре видео, поэтому вопрос разметки, скорее всего, для этого видеохостинга не стоит на повестке дня. Про RuTube и Дзен вообще говорить не буду, чтобы не расстраиваться.
Недавно я узнал, что существует ещё и третий слой, который тоже невидим для человека - Large LanguageModel Optimization (LLMO). Он предназначен для ИИ-агентов и реализуется посредством грамотного заполнения файла llms.txt для каждой страницы сайта. Пока что LLMO я не делал. Поиграюсь, посмотрю результаты – своими наблюдениями обязательно поделюсь.
#DigitalTransformation
#AI
#Algorithm
Ссылка на оригинал поста: https://shorin.me/blog/2026/09/three-levels/
Есть у меня pet-проект – я развиваю свой сайт-портфолио и свой блог. На этих сайтах я обкатываю использование различных инструментов, которые впоследствии применяю и в своей работе.
Есть некоторые базовые вещи, без которых в 2026 году сайт не может нормально существовать:
- Для всего сайта: favicon, robots.txt, sitemap. Даже комментировать не буду.
- Для каждой страницы: title, description, OpenGraph теги. Без этого нормально ссылку на страницу никуда не вставишь и не перешлёшь.
Далее идут несколько уровней оптимизации.
Первый уровень – видимый для человека. Это тексты, расположенные на страницах сайта, и ссылки. У блога текстами выступает содержимое моих постов. А у сайта-портфолио основную часть составляют содержимое моих публикаций (для раздела публикации) и расшифровки видео (для раздела видео). Ссылки же у меня есть везде и всюду – я их планомерно вставляю во все посты на всех платформах, а также добавляю перекрёстные ссылки, если это уместно.
Второй уровень оптимизации человек уже не видит. Это использование структурированной разметки Schema.org (см. фото) в формате JSON-LD. Эта разметка предназначена для поисковых роботов, с её помощью роботам сообщается дополнительная семантическая информация об объектах на сайте. Например, Google очень сильно опирается на возможности этой разметки для выстраивания взаимосвязей среди экосистемы своих сервисов:
- Про Google Scholar я уже писал;
- Правильно размеченная страница, на которой есть ссылка на YouTube-видео, автоматически получает значительный рост при индексации. Это отчётливо видно в Google Search Console (см. фото).
Яндекс разметку Schema.org видит, но я не нашёл признаков того, чтобы он как-то её использовал, поскольку Yandex Cloud Video пока что слишком молод, а аналога Google Scholar у Яндекса нет. Если говорить про VK Видео, то он создан для того, чтобы многомиллионная аудитория соц.сети VK не уходила на сторонние ресурсы при просмотре видео, поэтому вопрос разметки, скорее всего, для этого видеохостинга не стоит на повестке дня. Про RuTube и Дзен вообще говорить не буду, чтобы не расстраиваться.
Недавно я узнал, что существует ещё и третий слой, который тоже невидим для человека - Large LanguageModel Optimization (LLMO). Он предназначен для ИИ-агентов и реализуется посредством грамотного заполнения файла llms.txt для каждой страницы сайта. Пока что LLMO я не делал. Поиграюсь, посмотрю результаты – своими наблюдениями обязательно поделюсь.
#DigitalTransformation
#AI
#Algorithm
Ссылка на оригинал поста: https://shorin.me/blog/2026/09/three-levels/
👍7❤4
Пример цифровой трансформации
Периодически меня спрашивают «чем цифровая трансформация отличается от автоматизации, информатизации, цифровизации?». Ответить на этот вопрос можно разными способами. Например, в программе по повышению квалификации «Цифровая трансформация бизнеса» в РАНХиГС, различие этих понятий объяснялось в сравнении с промышленными революциями:
- 1-я промышленная революция: использование пара – это механизация;
- 2-я: использование электричества, изобретение конвейера – это автоматизация;
- 3-я: использование компьютеров и коммуникаций – это информатизация;
- 4-я: облака, Big Data, AI, IoT – цифровая трансформация.
Это достаточно грубое сравнение, поскольку вся суть, как всегда, содержится в мелочах. Наличие облаков и AI самих по себе – ещё не означает цифровую трансформацию. Если предприятие заменило бумажную форму электронной, перешло от использования Excel в облачную ERP, а телефонные заявки стало обрабатывать с помощью виртуальной АТС, то это всё же информатизация. Цифровая трансформация начинается тогда, когда благодаря технологиям становится возможной такая организация деятельности предприятия, которая либо была невозможной до этого, либо она была экономически нецелесообразной.
Приведу пример. Возьмём автопрокат. На этапе информатизации этого вида бизнеса менеджеры регистрируют автомобили в системе (пусть даже и облачной), распределяют их по локациям, устанавливают тарифы, подключают внутреннюю систему к различным агрегаторам.
При цифровой трансформации объектом управления становится не конкретный автомобиль, а общая доступность всего автопарка, в том числе и виртуального. При этом управление происходит в разрезе множества переменных: динамическое ценообразование, автоматическое распределение парка автомобилей по локациям, управление каналами продаж, предиктивное техническое обслуживание, планирование будущих закупок, просчёт персональной риск-модели для каждого клиента.
Суть в том, чтобы спланировать равномерную загрузку всего автопарка. При этом необходимо учитывать такие параметры, которые раньше не рассматривались в принципе:
- виртуальный флот – автомобили, которые в данный момент отсутствуют в автопарке, но которые будут закуплены у дилера к определённой дате;
- овербукинг – возможность автоматического апгрейда при возникновении коллизий;
- динамическое подключение других автопрокатов, лизинговых компаний, дилеров и владельцев корпоративных парков;
- и многое другое.
Такой подход напоминает переход, произошедший в IT от управления отдельными физическими серверами к облачным вычислительным ресурсам, подмножества которых динамически выделяются для решения поставленной задачи, а затем возвращаются в общий пул.
#DigitalTransformation
#Management
#AI
Ссылка на оригинал поста: https://shorin.me/blog/2026/09/digital-transformation-example/
Периодически меня спрашивают «чем цифровая трансформация отличается от автоматизации, информатизации, цифровизации?». Ответить на этот вопрос можно разными способами. Например, в программе по повышению квалификации «Цифровая трансформация бизнеса» в РАНХиГС, различие этих понятий объяснялось в сравнении с промышленными революциями:
- 1-я промышленная революция: использование пара – это механизация;
- 2-я: использование электричества, изобретение конвейера – это автоматизация;
- 3-я: использование компьютеров и коммуникаций – это информатизация;
- 4-я: облака, Big Data, AI, IoT – цифровая трансформация.
Это достаточно грубое сравнение, поскольку вся суть, как всегда, содержится в мелочах. Наличие облаков и AI самих по себе – ещё не означает цифровую трансформацию. Если предприятие заменило бумажную форму электронной, перешло от использования Excel в облачную ERP, а телефонные заявки стало обрабатывать с помощью виртуальной АТС, то это всё же информатизация. Цифровая трансформация начинается тогда, когда благодаря технологиям становится возможной такая организация деятельности предприятия, которая либо была невозможной до этого, либо она была экономически нецелесообразной.
Приведу пример. Возьмём автопрокат. На этапе информатизации этого вида бизнеса менеджеры регистрируют автомобили в системе (пусть даже и облачной), распределяют их по локациям, устанавливают тарифы, подключают внутреннюю систему к различным агрегаторам.
При цифровой трансформации объектом управления становится не конкретный автомобиль, а общая доступность всего автопарка, в том числе и виртуального. При этом управление происходит в разрезе множества переменных: динамическое ценообразование, автоматическое распределение парка автомобилей по локациям, управление каналами продаж, предиктивное техническое обслуживание, планирование будущих закупок, просчёт персональной риск-модели для каждого клиента.
Суть в том, чтобы спланировать равномерную загрузку всего автопарка. При этом необходимо учитывать такие параметры, которые раньше не рассматривались в принципе:
- виртуальный флот – автомобили, которые в данный момент отсутствуют в автопарке, но которые будут закуплены у дилера к определённой дате;
- овербукинг – возможность автоматического апгрейда при возникновении коллизий;
- динамическое подключение других автопрокатов, лизинговых компаний, дилеров и владельцев корпоративных парков;
- и многое другое.
Такой подход напоминает переход, произошедший в IT от управления отдельными физическими серверами к облачным вычислительным ресурсам, подмножества которых динамически выделяются для решения поставленной задачи, а затем возвращаются в общий пул.
#DigitalTransformation
#Management
#AI
Ссылка на оригинал поста: https://shorin.me/blog/2026/09/digital-transformation-example/
👍4❤3🔥1
Международный технологический конгресс 2026
В прошлом году я принимал участие в Международном технологическом конгрессе - был спикером сессии, посвящённой стандартизации цифровой трансформации в различных областях. В этом году мы с моими друзьями по клубу «Цифровые лидеры бизнеса» приняли участие в работе сессии «Цифровая трансформация: триада успеха – технологии, безопасность, люди».
Модерировал эту сессию Максим Коропченко. Сначала наше обсуждение шло по вполне ожидаемому плану:
- Я рассказал про цифровую трансформацию отрасли автопроката;
- Юрий Цокало – про проекты, реализуемые в Росатоме;
- Станислав Скалабан – про использование ИИ для быстрой проверки гипотез в Русской медиагруппе;
- Пётр Чернышев – про применение ИИ и цифровую трансформацию шахматных турниров;
- Эльдар Мустафин – про проекты цифровой трансформации Ростеха.
Как обычно, мы отметили главенствующую роль вовлечённости людей и особенно первых лиц для достижения успеха в цифровой трансформации. Немного коснулись проблемы точности определений таких терминов как механизация, автоматизация, информатизация, цифровизация и цифровая трансформация.
Однако вскоре наше общение вышло на совершенно новый уровень. Мы отошли от обсуждения конкретных проектов и стали рассуждать на более абстрактные темы. В частности:
- Необходимость более тонкого разграничения слоёв доступа и зон ответственности при работе с данными;
- Экзистенциальный кризис идентичности всего человечества в эпоху ИИ;
- Необходимость применения изменений к самому процессу внедрения изменений;
- Последовательное фокусирование на цепочке взаимосвязанных элементов: цель, команда, процессы, данные, технологии;
- Ценность человеческого общения и обмена опытом для реализации проектов цифровой трансформации;
- Сокращение проектов цифровой трансформации и повышение требований к результатам их внедрения, в том числе в плане безопасности;
- Парадокс между восприятием цифровых продуктов в массовом сегменте и на производстве.
Времени, отведённого для нашей сессии, было катастрофически мало, чтобы обсудить все темы, поэтому мы продолжили нашу дискуссию уже в кулуарах конгресса.
Я получил истинное интеллектуальное удовольствие от обсуждения столь небанальных тем в кругу высокопрофессиональных экспертов, которые настолько вовлечены в процесс цифровой трансформации. Отдельное спасибо Марии Мустафаевой за организацию этого мероприятия.
#DigitalTransformation
#Conference
#AI
Ссылка на оригинал поста: https://shorin.me/blog/2026/09/itc-2026/
В прошлом году я принимал участие в Международном технологическом конгрессе - был спикером сессии, посвящённой стандартизации цифровой трансформации в различных областях. В этом году мы с моими друзьями по клубу «Цифровые лидеры бизнеса» приняли участие в работе сессии «Цифровая трансформация: триада успеха – технологии, безопасность, люди».
Модерировал эту сессию Максим Коропченко. Сначала наше обсуждение шло по вполне ожидаемому плану:
- Я рассказал про цифровую трансформацию отрасли автопроката;
- Юрий Цокало – про проекты, реализуемые в Росатоме;
- Станислав Скалабан – про использование ИИ для быстрой проверки гипотез в Русской медиагруппе;
- Пётр Чернышев – про применение ИИ и цифровую трансформацию шахматных турниров;
- Эльдар Мустафин – про проекты цифровой трансформации Ростеха.
Как обычно, мы отметили главенствующую роль вовлечённости людей и особенно первых лиц для достижения успеха в цифровой трансформации. Немного коснулись проблемы точности определений таких терминов как механизация, автоматизация, информатизация, цифровизация и цифровая трансформация.
Однако вскоре наше общение вышло на совершенно новый уровень. Мы отошли от обсуждения конкретных проектов и стали рассуждать на более абстрактные темы. В частности:
- Необходимость более тонкого разграничения слоёв доступа и зон ответственности при работе с данными;
- Экзистенциальный кризис идентичности всего человечества в эпоху ИИ;
- Необходимость применения изменений к самому процессу внедрения изменений;
- Последовательное фокусирование на цепочке взаимосвязанных элементов: цель, команда, процессы, данные, технологии;
- Ценность человеческого общения и обмена опытом для реализации проектов цифровой трансформации;
- Сокращение проектов цифровой трансформации и повышение требований к результатам их внедрения, в том числе в плане безопасности;
- Парадокс между восприятием цифровых продуктов в массовом сегменте и на производстве.
Времени, отведённого для нашей сессии, было катастрофически мало, чтобы обсудить все темы, поэтому мы продолжили нашу дискуссию уже в кулуарах конгресса.
Я получил истинное интеллектуальное удовольствие от обсуждения столь небанальных тем в кругу высокопрофессиональных экспертов, которые настолько вовлечены в процесс цифровой трансформации. Отдельное спасибо Марии Мустафаевой за организацию этого мероприятия.
#DigitalTransformation
#Conference
#AI
Ссылка на оригинал поста: https://shorin.me/blog/2026/09/itc-2026/
1❤6🆒4