Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Блог компании альфа-банк

Перевод Как протоколы ARPANET повлияли на развитие TCPIP

25.03.2021 12:22:32 | Автор: admin

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

Протоколы ARPANET, как и современные Интернет-протоколы, были упорядочены в слои. Протоколы верхних слоёв работали поверх протоколов нижних слоёв. Сегодня стек TCP/IP имеет пять слоёв (физический, канальный, сетевой, транспортный и прикладной), но у ARPANET было всего три слоя (или четыре, смотря как считать).

Ниже я расскажу, как работал каждый из этих слоёв, но для начала сделаем краткое отступление, чтобы рассказать, кто создавал ARPANET и чем конкретно занималась каждая из сторон. Это поможет вам понять, почему слои были разделены именно так.

Краткая историческая справка


ARPANET финансировался федеральным правительством США, и в частности Управлением перспективных исследовательских проектов (Advanced Research Projects Agency, ARPA), подчинённым Министерству обороны (отсюда и название ARPANET). Правительство США не создавало сеть самостоятельно; вместо этого оно отдало работу на аутсорс бостонской консалтинговой фирме Bolt, Beranek and Newman, более известной как BBN.

BBN, в свою очередь, взяла на себя бОльшую часть задач по реализации сети, но не весь проект целиком. BBN занималась проектированием и поддержкой машины, называемой Interface Message Processor (IMP). IMP представлял собой модернизированный микрокомпьютер Honeywell, каждый из таких компьютеров отправлялся в те учреждения по всей стране, которые должны были подключаться к ARPANET. IMP использовался в качестве шлюза в ARPANET для четырёх хостов в каждой из точек. BBN контролировала выполняемое на компьютерах IMP ПО, передающее пакеты от одного IMP к другому IMP, однако фирма не имела непосредственного контроля над машинами, подключавшимися к IMP и становившимися истинными хостами ARPANET.

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

То есть если представить единичное успешное сетевое взаимодействие через ARPANET (допустим, отправку электронного письма), то за некоторые части её реализации, обеспечивающие успешное взаимодействие, отвечал один коллектив людей (BBN), а за другие части отвечал другой коллектив (Network Working Group и инженеры в каждой из точек размещения хостов). Такое организационное и логистическое стечение обстоятельств, вероятно, сыграло важную роль в выборе слоистой архитектуры протоколов ARPANET, что, в свою очередь, повлияло на реализацию TCP/IP в виде слоёв.

Итак, вернёмся к протоколам



Иерархия протокола ARPANET.

Слои протокола были упорядочены в иерархию. В самом низу находился уровень 0 (level 0). Это слой, который в каком-то смысле не считается, потому что в ARPANET его целиком контролировала фирма BBN, а значит, нужда в стандартном протоколе отсутствовала. Level 0 управлял тем, как данные передаются между IMP. У BBN были внутренние правила о том, как IMP должны это делать; для всех, кто не работал в BBN, подсеть IMP оставалась чёрным ящиком, просто передающим любые отправленные ему данные. То есть level 0 был слоем без настоящего протокола, не являлся публично открытым и общепринятым перечнем правил и его существование могло полностью игнорироваться программами, работающими на хостах ARPANET. Грубо говоря, он обрабатывал всё, что сегодня относится к физическому, канальному и сетевому слоям стека TCP/IP, и даже выполнял довольно большую часть функций транспортного слоя, но к этому мы вернёмся в конце поста.

Слой level 1 устанавливал интерфейс между хостами ARPANET и IMP, к которым они были подключены. Можно сказать, что это был API для чёрного ящика level 0, созданного BBN. В то время его также называли IMP-Host Protocol. Этот протокол нужно было написать и опубликовать, потому что при первоначальной подготовке ARPANET каждое учреждение с хостами должно было писать собственное ПО, обеспечивающее интерфейс с IMP. Они бы не знали, как это сделать, без помощи BBN.

Спецификация IMP-Host Protocol была записана BBN в длинном документе под названием BBN
Report 1822. В процессе эволюции ARPANET было выпущено много новых версий документа; в посте я приблизительно опишу то, как работала изначальная версия IMP-Host Protocol. Согласно правилам BBN, хосты могли передавать компьютерам IMP сообщения длиной не более 8095 бит, и каждое сообщение содержало leader (заголовок), в котором указывался номер хоста-получателя, а также нечто под названием link number (номер канала). IMP считывал номер хоста-получателя и послушно переправлял сообщение в сеть. При получении сообщений от удалённого хоста принимающий IMP заменял номер хоста-получателя на номер хоста-отправителя, а потом передавал его на локальный хост. Между самими IMP передавались не сами сообщения IMP разбивали сообщения на мелкие пакеты для передачи по сети, однако эта особенность была сокрыта от хостов.

1969 Host-IMP Leader

Формат заголовка сообщений, передаваемых между хостом и IMP, каким он был в 1969 году. Схема из BBN Report 1763.

Номер канала, который мог быть любым числом от 0 до 255, выполнял две задачи. Он использовался протоколами более высокого уровня для установки нескольких каналов связи между любыми двумя хостами в сети, потому что в текущий момент времени с хостом-получателем вполне могло общаться несколько локальных пользователей. (Другими словами, номера каналов позволяли мультиплексировать связь между хостами.) Однако также он использовался в слое level 1 для управления объёмом трафика, который можно передавать между хостами, это было необходимо для того, чтобы быстрые компьютеры не перегружали сообщениями медленные. В изначальном проекте IMP-Host Protocol ограничивал каждый хост, позволяя одновременно передавать по одному каналу всего одно сообщение. После того, как хост передал сообщение по каналу удалённому хосту, ему нужно было ждать от удалённого IMP специальное сообщение под названием RFNM (Request for Next Message), прежде чем отправлять следующее сообщение по тому же каналу. Следующие версии этой системы, созданные для повышения пропускной способности, позволяли хосту одновременно передавать другому хосту по одному каналу до восьми сообщений.

Самое интересное начинается в слое level 2, потому что этот и последующий слои BBN и Министерство обороны отдали на откуп учёными и Network Working Group, позволив изобретать их самостоятельно. Слой level 2 представлял собой Host-Host Protocol, черновик которого изначально был выпущен в RFC 9, а первая его официальная спецификация появилась в RFC 54. Более удобочитаемое объяснение Host-Host Protocol представлено в ARPANET Protocol Handbook.

Host-Host Protocol управлял тем, как хосты создавали соединения друг с другом и управляли ими. Соединение это односторонняя линия передачи данных между сокетом записи одного хоста и сокетом считывания другого. Концепция сокетов (socket) была добавлена поверх имевшей ограничения системы каналов level 1 (не забывайте, что номер канала иметь только 256 значений), чтобы предоставить программам возможность адресации определённого процесса, работающего на удалённом хосте. Сокеты считывания имели нечётные номера; функция сокета (считывание или запись) назывались его гендером. В протоколе не было номеров портов, как в TCP. Соединения можно было открывать, манипулировать ими и закрывать их при помощи специально отформатированных контрольных сообщений Host-Host, передаваемых между хостами по каналу 0, зарезервированному для этой цели. После того, как был произведён обмен сообщениями по каналу 0 для установки соединения, дальнейшие сообщения с данными можно было передавать по каналу с другим номером, выбранным получателем.

Контрольные сообщения Host-Host идентифицировались трёхбуквенной мнемоникой. Соединение устанавливалось, когда два хоста обменивались сообщением STR (sender-to-receiver) и соответствующим сообщением RTS (receiver-to-sender) эти контрольные сообщения назывались сообщениями Request for Connection (запроса на подключение). Соединения можно было закрывать контрольным сообщением CLS (close). Существовали и другие контрольные сообщения, менявшие частоту передачи сообщений с данными от отправителя к получателю, что опять-таки нужно было для того, чтобы быстрые хосты не перегружали медленные. Управление потоками, реализованное в протоколе level 1, очевидно, было недостаточным для level 2; я подозреваю, что так получилось из-за того, что получение RFNM от удалённого IMP гарантировало только то, что удалённый IMP передал сообщение на хост-получатель, а не то, что хост полностью его обработал. Также существовали контрольные сообщения INR (interrupt-by-receiver) и INS (interrupt-by-sender), которые в основном использовались протоколами более высокого уровня.

Все высокоуровневые протоколы находились на level 3, то есть на прикладном слое ARPANET. Вероятно, самым важным из этих протоколов был Telnet, обеспечивавший виртуальное телетайпное подключение к другому хосту, но на этом уровне было и много других протоколов, например, FTP для передачи файлов и различные эксперименты с протоколами для отправки электронной почты.

Один протокол с этого уровня не походил на остальные, это Initial Connection Protocol (ICP). ICP считался протоколом level 3, но на самом деле был протоколом level 2.5, поскольку от него зависели другие протоколы level 3. ICP был необходим потому, что соединения, обеспечиваемые Host-Host Protocol на level 2, были только односторонними, однако большинству приложений для выполнения каких-то интересных задач требовалось двустороннее (т.е. полнодуплексное) соединение. ICP задавал двухэтапный процесс, при котором запущенный на одном хосте клиент подключался к долговременно работающим процессом-сервером на другом хосте. Первый этап заключался в установке одностороннего подключения от сервера к клиенту при помощи известного номера сокета процесса-сервера. После установки соединения сервер отправлял по нему клиенту новый номер сокета. Затем установленное соединение прекращалось и открывалось два новых соединения, одно для считывания, использующее переданный номер сокета, другое для записи, использующее тот же переданный номер плюс один. Этот небольшой танец был необходимой прелюдией для большинства действий, например, он был первым этапом установки соединения Telnet.

На этом наш подъём по иерархии протоколов ARPANET завершён. Вы могли ожидать, что рано или поздно я упомяну Network Control Protocol. Прежде чем я приступил к исследованиям для подготовки к этому посту, я считал, что ARPANET управлялся протоколом под названием NCP. Этой аббревиатурой иногда обозначали протоколы ARPANET в целом. Вероятно, именно поэтому у меня появилась такая мысль. Например, в RFC 801 говорится о переходе ARPANET с NCP на TCP, и это заставляет думать, что NCP это протокол ARPANET, эквивалентный TCP. Но Network Control Protocol для ARPANET никогда не существовало (хоть так и считает Encyclopedia Britannica), и я подозреваю, что люди ошибочно расшифровывали NCP как Network Control Protocol, но на самом деле это означало Network Control Program. Программа Network Control Program была программой уровня ядра, работающей на каждом хосте, отвечающем за управление сетевыми коммуникациями. Она была эквивалентом стека TCP/IP в современных операционных системах. Аббревиатура NCP, используемая в RFC 801, это псевдоним, а не протокол.

Сравнение с TCP/IP


Позже все протоколы ARPANET были вытеснены протоколами TCP/IP (за исключением Telnet и FTP, которые легко адаптировали для работы поверх TCP). Все протоколы ARPANET основывались на предположении о том, что сеть создавалась и управлялась одной организацией (BBN), а стек протоколов TCP/IP проектировался под Интер-нет, сеть сетей, где всё будет более гибким и ненадёжным. Это привело к появлению одних из наиболее очевидных отличий между современными протоколами и протоколами ARPANET, а именно к тому, как сегодня мы разделяем сетевой и транспортный слои. В ARPANET функции транспортного протокола частично выполняли IMP, а позже за них стали отвечать исключительно хосты в конечных точках сети.

Однако самым интересным в протоколах ARPANET мне кажется то, что большой объём функций транспортного слоя, присутствующий сегодня TCP, прошёл этап незрелой юности ARPANET. Я не специалист по сетям, поэтому мне пришлось достать свой учебник по сетям из колледжа (Куросе и Росс, на помощь!), и в нём нашлось достаточно неплохое краткое описание того, за что в целом отвечает транспортный слой. Протокол транспортного слоя минимально должен выполнять следующие задачи. Сегмент здесь, по сути, является термином, аналогичным сообщению в ARPANET:

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

Кроме того, транспортный слой, как и TCP, может обеспечивать надёжную передачу данных, то есть:

  • Сегменты доставляются по порядку
  • Потерянные сегменты отсутствуют
  • Сегменты не доставляются так быстро, что отбрасываются получателем (управление потоками)

Похоже, в ARPANET существовала некоторая запутанность в способе реализации мультиплексирования и демультиплексирования для обмена данными процессов BBN реализовала для этого номер канала на уровне IMP-Host, но оказалось, что всё равно поверх него требуются номера сокетов на уровне Host-Host. Поэтому номер канала использовался только для управления потоками на уровне IMP-Host, но BBN, похоже в дальнейшем отказалась от этой схемы в пользу управления потоками между уникальными парами хостов, то есть изначально номер канала был перегруженным элементом, а позже, по сути, стал рудиментарным. Сегодня TCP использует вместо них номера портов, выполняя управление потоками отдельно для каждого TCP-соединения. Мультиплексирование и демультиплексирование уровня процесс-процесс происходит целиком внутри TCP и не утекает на нижний слой, как это было в ARPANET.

К тому же, в свете того, как Куросе и Росс развивают идеи, лежащие в основе TCP, любопытно было увидеть, что ARPANET начинались с того, что авторы учебника назвали бы реализацией надёжной передачи данных на уровне IMP-Host при помощи строгого подхода остановиться и ждать. Принцип остановиться и ждать заключается в том, что после передачи сегмента узел отказывается передавать любые другие сегменты, пока не получит подтверждение получения последнего переданного сегмента. Это простое решение, но оно означает, что в любой момент времени по сети передаётся только один сегмент, из-за чего протокол оказывается очень медленным. Именно поэтому Куросе и Росс назвали подход остановиться и ждать просто переходным этапом на пути к полнофункциональному протоколу транспортного слоя. В ARPANET какое-то время использовался подход остановиться и ждать, поскольку на уровне IMP-Host перед отправкой дальнейших сообщений нужно было получить Request for Next Message в ответ на каждое исходящее сообщение. Но надо отдать должное BBN, поначалу она считала, что это будет необходимо для обеспечения управления потоками между хостами, поэтому замедление было намеренным. Как я говорил выше, требование RFNM позже было смягчено ради повышения скорости, а IMP начали прикреплять к сообщениям порядковые номера и отслеживать окна передаваемых сообщений примерно так же, как сегодня это делается в реализациях TCP.

Итак, пример ARPANET продемонстрировал, то обмен данными между неоднородными вычислительными системами возможен, если всем сторонам удастся договориться об общих правилах. Как говорилось ранее, это и есть самое важное наследие ARPANET. Но я ещё и надеюсь на то, что внимательное изучение этих правил показало вам, что принципы протоколов ARPANET ещё и сильно повлияли на протоколы, которые мы используем сегодня. Разумеется, разделение функций транспортного слоя между хостами и IMP было очень неуклюжим, а иногда и избыточным. И сегодня нам может показаться забавным, что хосты поначалу могли одновременно отправлять друг другу по любому из каналов только одно сообщение. Однако эксперименты с ARPANET стали уникальной возможностью получить эти уроки благодаря реализации настоящей сети и управления ею; похоже, эти уроки пошли впрок, когда пришло время совершенствования системы и превращения её в тот Интернет, который мы используем сегодня.
Подробнее..
Категории: Информационная безопасность , Сетевые технологии , История it , Блог компании альфа-банк , Arpanet , Tcp/ip , Протоколы

Памятка для удостоверяющих центров и других участников PKI

26.04.2021 14:21:23 | Автор: admin

Памятка для удостоверяющих центров и других участников PKI

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

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

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

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

В этом посте я хочу рассказать, с какими критическими проблемами и нарушениями в работе УЦ часто приходится сталкиваться, а также о том, как их избежать.

У полноправного участника Public Key Infrastructure, должна быть информационная система со встроенными СКЗИ, которая позволяет вести электронный документооборот с клиентами и партнерами, обмениваясь с ними документами с электронной подписью (ЭП) или зашифрованными данными.

Когда партнер присылает документы с ЭП, система выполняет ряд действий. Она проверяет электронную подпись на документе и партнерский сертификат открытого ключа проверки этой подписи.

В частности, для сертификата партнера строится путь сертификации - цепочка сертификатов, от его конечного пользовательского, на котором проверилась ЭП, до корневого центра сертификации.

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

Для квалифицированных сертификатов также выполняются проверки согласно 63-ФЗ Об электронной подписи и Приказа ФСБ РФ 795. Контролируется наличие и правильность заполнения всех необходимых атрибутов в сертификате пользователя.

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

Сбои и некорректная работа УЦ в части публикации CRL

В сертификатах есть атрибут CDP - CRL Distribution Points, в нем УЦ публикует ссылки на свой список отозванных сертификатов - Certificate Revocation List

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

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

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

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

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

То же самое касается контроля клиентских и серверных сертификатов, которые используются для построения защищенного канала связи TLS ГОСТ или TLS RSA по протоколу HTTPS. Если системам партнеров не удается проверить их на отзыв, то защищенное и 100% доверенное соединение партнеры установить между собой не смогут.

Какие сбои и нарушения здесь может допустить УЦ?

1. Перенаправление ссылок (Redirect)

УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.

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

private static final String ATTENTION_CRL_REDIRECT_DETECTED = "Attention CRL redirect detected: ";    private static final String LOCATION = "Location";   URL url = new URL(crlURL);        InputStream crlStream = null;        URLConnection connection = url.openConnection();        String redirect = connection.getHeaderField(LOCATION);        if (redirect != null) {            throw new DownloadCRLException(                    ATTENTION_CRL_REDIRECT_DETECTED + crlURL + STRING_DIRECTION + redirect);        }

2. HTTPS в CDP атрибуте сертификата и ни одной общедоступной ссылки

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

Попадались сертификаты с https://, ldap:// или защищенный SFTP, также были просто URL с IP адресами из внутренней подсети. Все эти ссылки допустимы при наличии хотя бы одной ссылки HTTP или FTP (без логина и пароля) доступной из сети Internet всем.

Почему HTTPS к свободным не относится?

За списками отзыва могут обращаться далеко не только интернет-браузеры, имеющие обширное хранилище корневых доверенных сертификатов международных УЦ, которое позволяет им поднимать защищенное соединение по HTTPS-ссылке и принимать ресурс как доверенный.

Другие информационные системы могут не иметь такого хранилища с предустановленными корневыми сертификатами и не обязаны поднимать контекст защищенного соединения к HTTPS-ссылкам.

Просто невозможно во все системы установить все корни для всего многообразия УЦ, выпускающих SSL/TLS-сертификаты.

По понятным причинам информационные системы также не могут знать логин и пароль от FTP и не будут иметь доступ к внутренней службе Active Directory по LDAP-протоколу.

Поэтому принято, что CRL публикуется в свободном доступе.

3. HTTP перенаправление (redirect) на HTTPS

Это гибридная ситуация, с которой приходилось сталкиваться, состоящая из приведенных выше пунктов 1 и 2.

Как такое возможно?

Сайт компании, где УЦ публикует свои списки отзыва, или просто веб-сервер, который используется удостоверяющим центром для этих целей, запущен, например, на Nginx.

Администратор сайта, желающий исключительно добра и защитить сайт и пользователей, совершенно забыв, а может, и не зная про публикацию CRL, включает безусловный redirect всего сайта на HTTPS.

server {    listen 80 default_server;    listen [::]:80 default_server;    server_name _;    return 301 https://$host$request_uri;}

Получается, что в сертификате приведен URL с http://, а системы, которые чувствительны к такому факту подмены подписанной информации из сертификата и справедливо защищаются от атак посредников, перестают загружать списки отзыва данного УЦ, пока администратор не настроит на сайте исключения для CRL.

4. Фильтрация по User Agent

Данная проблема и нарушение доступа к спискам отзыва сильно перекликается с приведенной в пункте 3.

Тот же администратор сайта, на том же Nginx включает фильтрацию по User Agent. Например, все системы на Java будут получать ошибку HTTP 403 при обращении к ресурсу.

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

if ($http_user_agent = "Mozilla/5.0 (Linux; Android 4.2.2; SGH-M919 Build/JDQ39) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.169 Mobile Safari/537.22"){    return 403;}if  ($http_user_agent ~* "^Java"){ return 403; }

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

5. Просроченный CRL

Сертификат может содержать несколько ссылок на списки отзыва. Внутри каждого CRL могут быть вложены ссылки на его дельты с иными, более короткими сроками жизни, а следовательно, обновляемые чаще.

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

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

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

Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.

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

6. Сбои на сетевом и транспортном уровне

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

В сертификате, выпущенном УЦ, может быть прописано два URL с http:// и разными host именами. Такой подход правильный, он позволяет иметь резерв и всегда держать одну ссылку в доступе, если требуется провести какие-то работы на другом сервере.

Но вот незадача. Вызывающая система вдруг начинает получать IOException: ConnectionTimeOut при попытке подключения к одной из ссылок. Вторая ссылка при этом работает и отдает CRL. А вызывающая система все равно начинает замедляться на настроенное в ней время, например, ConnectionTimeOut=15000 mSec, потому что проверяет обе ссылки, и ей приходится ждать ответа от недоступной в настоящий момент.

А если в CDP сертификата четыре, пять разных ссылок на CRL и при этом две или три из них оказываются недоступны с ConnectionTimeOut?

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

А что, если обмен нашей информационной системы идет с этим УЦ или партнером, организацией, аффилированной с данным УЦ? И система партнера имеет свой таймаут на вызов нашей информационной системы, который заведомо меньше того времени, которое наша система тратит на проверку их сертификата?

Получается коллизия.

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

Почему может происходить ConnectionTimeOut?

Как вариант, это регламентные работы, сетевая атака или повышенная нагрузка на сайт УЦ, что привело к неконсистентному состоянию:

  • какой-то брандмауэр, файрвол на пути, который просто начал съедать сетевые пакеты, не сообщая отправителю такие вещи, как "No Route to host"

  • началась потеря пакетов из-за неправильной конфигурации сети или перегрузки линии

  • слишком много запросов, перегружающих сервер

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

Как с этим справляться?

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

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

Если точка публикации будет корректно отключена, то вызывающая система, мгновенно получив от этой ссылки, например, IOException Connection Refused: connect, сразу перейдет к загрузке по следующему URL.

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

Чем должны руководствоваться УЦ при публикации CRL

RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.

В частности, пунктом 8. Security Considerations из RFC 5280

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.

CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server's certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.

УЦ не должны включать HTTPS или LDAP-ссылки для публикации своих списков отзыва.

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

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

Другими словами, клиент и сервер будут пытаться поднять защищенное HTTPS-соединение друг с другом. Для этого им потребуется проверить сертификаты на отзыв. А чтобы это сделать, тоже нужно поднять защищенное соединение по HTTPS-ссылке к CRL, которую УЦ неосмотрительно опубликовал в атрибуте сертификата.

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

Протокол онлайн-проверки статуса сертификата OCSP - Online Certificate Status Protocol.

Такие сертификаты также включают в себя стандартный атрибут CDP и могут проверяться обычным способом.

А для работы с сервером OCSP они должны включать еще и расширение OCSP Server Client.

Но это материал для отдельнойстатьи.

Обязательные атрибуты квалифицированных сертификатов

Состав квалифицированного сертификата регулируется Федеральным законом "Об электронной подписи" от 06.04.2011 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2011 г. N 795 "Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи".

Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject - субъект сертификации отсутствовал атрибут L Местоположение.

Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.

Удостоверяющий центр данную ситуацию комментировал так:

атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа 795

На конкретный пункты Закона и Приказа в УЦ не ссылались.

Собственный повторный анализ юридических аспектов показал:

63-ФЗ от 06.04.2011 "Об электронной подписи"

Статья 14. Сертификат ключа проверки электронной подписи

2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:

2) фамилия, имя и отчество (если имеется) - для физических лиц, наименование и место нахождения - для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;

Статья 17. Квалифицированный сертификат

2. Квалифицированный сертификат должен содержать следующую информацию:

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

Приказ ФСБ РФ от 27 декабря 2011 г. 795

III. Требования к порядку расположения полей квалифицированного сертификата

5) stateOrProvinceName (наименование штата или области).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;

6) localityName (наименование населенного пункта).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;

7) streetAddress (название улицы, номер дома).

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

В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).

И не указано localityName (наименование населенного пункта).

locality - Местонахождение

В Законе 63-ФЗ и Приказе 795 нет информации, что для города Москва не нужно заполнять атрибут locality - Местонахождение.

Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)

После данного разбора удалось найти документ ФСБ РФ ИЗВЕЩЕНИЕ ОБ ИСПОЛЬЗОВАНИИ АТРИБУТА ИМЕНИ LOCALITYNAME ПОЛЯ SUBJECT В СТРУКТУРЕ КВАЛИФИЦИРОВАННОГО СЕРТИФИКАТА КЛЮЧА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ

Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя юридического лица.

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

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

Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.

Прошу использовать данную информацию в работе.

Желаю всем участникам PKI удачи и успехов!

Подробнее..
Категории: Информационная безопасность , It-инфраструктура , It-стандарты , Криптография , Блог компании альфа-банк , Ietf , Rfc , Pki , Электронная подпись , Public key infrastructure , X.509 , Удостоверяющий центр , Инфраструктура открытых ключей , Rfc5280 , Электронные сертификаты

Перевод 2000 строк кода

09.03.2021 10:13:46 | Автор: admin
Анекдот с сайта Folklore.org рассказывает историю разработки внутри Apple в первые годы жизни компании.

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

Билл Аткинсон, автор Quickdraw, один из главных дизайнеров пользовательского интерфейса и явно самый важный разработчик Lisa, посчитал число строк кода глупой оценкой продуктивности. Билл видел своей целью писать как можно более маленькие и быстрые программы. Показатель в число строк кода наоборот побуждал писать небрежный, раздутый и кривой код.

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

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

Не знаю, как на это отреагировали менеджеры. Одно мне известно точно: ещё через пару недель Билла уже не просили заполнять форму, и он с радостью её игнорировал.
Подробнее..
Категории: Управление проектами , Управление персоналом , Управление разработкой , История it , Блог компании альфа-банк , Управление , Дизайн программного обеспечения , Lisa , Эффективные менеджеры

Перевод Финансирование Гражданской войны (США против КША)

26.06.2020 14:09:33 | Автор: admin
Перевод статьи Michael A. Martorelli про источники финансирования войны США против КША история печати долларов обеих сторон, подделка купюр, займы и облигации, сбор налогов и многое другое.


Введение


К моменту инаугурации Авраама Линкольна в должности Президента Соединённых Штатов (США) в марте 1861 года семь отколовшихся южных штатов уже сформировали Конфедеративные Штаты Америки (КША). Политические лидеры этой территории, а также большинство их противников в северных и пограничных штатах считали, что каким бы ни был период борьбы за установление легитимности нового Конфедеративного государства, он окажется довольно коротким. Новые Секретари Казначейства США (Салмон Портленд Чейз) и КША (Кристофер Густав Меммингер) не ожидали, что им придётся собирать несколько миллиардов долларов для ведения четырёхлетней войны. Но даже при решении задачи финансирования короткой войны они оба понимали, что государства традиционно используют три основных источника средств для ведения военных действий: заёмные деньги, печать денег и сбор денег через налоги. С 1861 по 1865 год и США, и КША использовали все эти механизмы, хоть и в разных пропорциях. Данные исторических источников разнятся относительно точных процентных соотношений этих военных затрат, полученных от разных источников.

Во многих смыслах описание этих финансовых операций раскрывает нам историю двух стран.

Финансирование Союза


Заёмные деньги


До 1861 года основную часть доходов США составляли пошлины и таможенные сборы. Большое значение важности неувеличения долга характеризовало администрации президентов от Томаса Джефферсона до Франклина Пирса. Федеральное правительство полагалось на продажу облигаций и кредитных нот банкирам, брокерам и их крупным клиентам только во времена войн. Когда в марте 1857 года президентом стал Джеймс Бьюкенен, федеральный долг составлял скромные 28 миллионов долларов. Финансовая паника, охватившая страну в конце того же года, вызвала резкое падение доходов от пошлин и сборов; для покрытия дефицита Казначейство было вынуждено выпустить большие объёмы облигаций и кредитных нот. Кроме того, Президент Бьюкенен был вынужден использовать заёмные фонды для финансирования своих операций в отношении Кубы и территории мормонов, а также для расширения ВМФ и почтовой службы. В промежутке с 1857 до 1861 года Казначейство выпустило облигации и ноты на сумму более чем 142 миллионов долларов; за эти годы правительство создало совокупный дефицит в 76 миллиона.


Авраам Линкольн

В феврале и марте 1861 года раскол между Севером и Югом усиливался, а вероятность войны росла. Из-за очень низкого уровня средств в Казначействе Конгресс утвердил два отдельных законопроекта, разрешающих выпуск правительственных облигаций на сумму 35 миллионов долларов. Когда в марте 1861 года Авраам Линкольн принял Президентскую присягу, федеральный долг находился на необычайно высоком уровне почти 77 миллионов. В первые дни администрации Линкольна интерес к любым новым долгам был довольно низок; обычные клиенты банкиров и брокеров приобрели всего 16 миллионов (45%) вышеупомянутых десятилетних и двадцатилетних облигаций. В течение следующих нескольких месяцев повышенные пошлины и новые умеренные продажи кредитных нот принесли Казначейству ещё примерно 15 миллионов. Однако первоначальные затраты на расширение Федеральной Армии и Флота в ответ на неприкрыто агрессивные действия КША составили в сумме 24 миллиона долларов.

Чтобы заручиться поддержкой Конгресса в финансировании, необходимого для ведения войны, в июле 1861 года Президент собрал этот законодательный орган на особое совещание. В это время Секретарь Казначейства Чейз предложил собрать средства на беспрецедентную сумму в 320 миллионов долларов для финансирования войны; эта сумма должна была включать в себя продажу правительственных облигаций (240 миллионов), повышение пошлин (57 миллионов), новые пошлины или сборы (20 миллионов), а также продажу общественных земель (3 миллиона).

В ответ на это предложение Конгресс одобрил продажу облигаций на 250 миллионов долларов и введение подоходного налога. Оба механизма финансирования доказали несоответствие требованиям. Введение подоходного налога было назначено только в середине 1862 года, а Секретарь Чейз смог договориться о продаже облигаций всего на 150 миллионов группе банков в Нью-Йорке, Бостоне и Филадельфии. В конце 1861 года администрация Линкольна повторно оценила потребность в финансировании федерального правительства для ведения конфликта, который официальными лицами теперь считался долгим и затратным.

В феврале 1862 года Конгресс одобрил продажу облигаций ещё на 500 миллионов долларов. Но Казначейство испытывало проблемы с продажей правительственных облигаций. Во второй половине 1861 года фирма Jay Cooke & Company оказала Казначейству довольно большую помощь в продаже облигаций, поэтому в феврале 1862 год Секретарь Чейз уполномочил Джея Кука распространять новые одобренные двадцатилетние облигации на сумму 500 миллионов. За последующие два года фирма продала этих ценных бумаг на сумму в 511 миллионов долларов. Это удалось ей благодаря новой кампании по повышению популярности облигаций при помощи рекламы в газетах и сети из 2,5 тысяч агентов по продажам, работавших по всей стране. Кук писал редакторские колонки, в которых сообщал, что приобретение таких облигаций (некоторые из них имели номинал всего 50 долларов) является патриотическим действием и что о нём стоит задуматься каждому гражданину, пекущемуся о сохранении Союза. Его огромный успех в продаже этих облигаций заставил Конгресс одобрить ещё один выпуск в начале 1865 года облигаций на сумму 830 миллионов. К лету того же года фирма Кука продала их все. К концу Гражданской войны США финансировала продажей облигаций примерно две трети своих прямых издержек на сумму 3,4 миллиарда.

Печать денег



20 долларов США 1861 года

Накануне Гражданской войны объём находящихся в обращении США средств состоял в основном из банкнот на 200 миллиона долларов, выпущенных более чем 1,5 тысячами банков штатов. Такая система с независимыми эмитентами денег имела свои недостатки, но всё же позволяла справляться с финансовыми потребностями страны. Однако к концу 1861 года Секретарь Казначейства Чейз пришёл к выводу, что существование такого количества банкнот, эмитированных банками с лицензиями штатов, каждый из которых имел разные номиналы и степень защиты, неблагоприятно для финансирования войны. Даже несмотря на выпуск упомянутых выше облигаций, он предложил федеральному правительству выпустить новую бумажную валюту на сумму 150 миллионов долларов без обеспечения золотом, но всё равно являющуюся обязательством государства. Эти гринбеки (greenbacks), печатаемые на зелёной бумаге, должны были конвертироваться в равную сумму правительственных облигаций и считаться законным средством платежа по всем государственным и частным долгам. Спустя два месяца горячих дискуссий Конгресс одобрил этот план. Новая валюта стала считаться фиатным платёжным средством, принимаемым и продавцами, и потребителями. В июле 1862 года Конгресс одобрил ещё один выпуск гринбеков на сумму 150 миллионов, призвав напечатать примерно 25% банкнот номиналом от одного до пяти долларов. Затраты на войну постоянно росли, а правительство было ограничено в возможностях продажи облигаций, поэтому Конгресс одобрил продажу дополнительных 150 миллионов гринбеков в начале 1863 года. К концу войны на территории Союза в обращении находилось примерно 450 миллионов этой новой национальной валюты.

Повышение налогов



Салмон Портленд Чейз

Федеральное правительство и штаты уже давно использовали различные виды налогов, например, поголовные налоги, акцизные сборы, налог на имущество, налоги на коммерческую деятельность и ввозные пошлины. Однако, как было сказано выше, необычно большой объём дохода, необходимый для финансирования военных действий, заставил правительство задуматься о дополнительных налогах, несмотря на начало поисков других источников средств. Секретарь Казначейства Чейз убедил Конгресс ввести налог на доходы в августе 1861 года, однако этот закон не требовал никого платить такие налоги до середины 1862 года. В июле того же года Конгресс принял новый Акт о внутренних доходах 1861 года, устанавливающий ставку в 3% налога на ежегодный доход от 600 до 10 000 долларов и 5% налога на доходы выше этой суммы. В 1863 году доход от этого источника составил менее 20 миллионов. К середине 1864 года Конгресс увидел необходимость повышения ставок налогов на доходы выше 5 000 долларов, повышения других налогов (налог на наследство, акцизные сборы, налог на коммерческий валовый доход, на лицензии, личную собственность и так далее) и внедрения чрезвычайного налога (сверх новых ставок) на доходы выше 600 долларов.

Налог на доходы принёс всего 2 миллиона общего дохода федерального правительства от всех налогов, составившего в конце фискального года 30 июня 1863 года 38 миллионов. Доход от налога на доходы увеличился до 20 миллионов в фискальном 1864 году и до 32 миллионов в фискальном 1865 году. В сумме все налоги составили примерно 21% от дохода федерального правительства на протяжении всех лет войны.

Финансирование Конфедерации



Президент КША Джефферсон Дэвис

Заёмные деньги


В отличие от давно сложившихся США, у молодых КША ещё не было опыта в сборе денег на поддержку своих действий. Однако их грамотные политические лидеры-основатели определённо считали удовлетворение финансовых потребностей нового государства одной из наиболее важных задач. 8 февраля 1861 года Временное конфедеративное правительство приняло от штата Алабама заём в 500 тысяч долларов. 19 февраля 1861 года, на следующий день после своей инаугурации, Президент Конфедерации Джефферсон Дэвис объявил о назначении Секретарём Казначейства Кристофера Г. Меммингера. У нового правительства, не имевшего собственной валюты, опыта и органов налогообложения, выбор вариантов финансирования был довольно ограниченным. В конце февраля Конгресс Конфедерации согласовал первый выпуск облигаций Казначейства для финансирования правительственных операций. Правительство предложило этот так называемый займ банкиров региональным коммерческим и банковским кругам, попросив их приобретать облигации за наличные деньги. Конгресс установил небольшую пошлину на вывоз хлопка, доход от которой предназначался для выплаты и процента (8%) и основной суммы займа (на десять лет). Со временем подписчики из таких ведущих коммерческих центров, как Новый Орлеан и Чарльстон, приобрели все облигации.


Облигации Конфедерации 1861 года

В мае Конгресс Конфедерации разрешил ещё один выпуск облигаций на 50 миллионов. На этот раз законодательный акт гласил, что облигации можно приобретать за наличные средства, военное имущество или за ожидаемые поступления от продажи сырья и промышленных изделий. В этом так называемом продуктовом займе была учтена нехватка значительного количества твёрдой валюты у классов южных плантаторов и фермеров. В нём было учтено, что эти люди имели большие объёмы хлопка, табака и других продуктов, которые бы они хотели позаимствовать правительству. Таким образом, благодаря изобретательному применению ипотеки (при которой заёмщик предоставляет залог для обеспечения долга), фермер в обмен на получение конфедеративных облигаций мог отдать ожидаемые поступления от продажи своего урожая Казначейству Конфедерации. В августе Конгресс Конфедерации увеличил объём и сроки этого продуктового займа до 100 миллионов; в апреле 1862 года он снова расширил его до 250 миллионов. После большого первоначального успеха в сборе этих средств, военные неудачи армии Конфедерации оказали подавляющий эффект на способность КША финансировать себя при помощи таких инструментов. К концу 1864 года Конфедерации удалось собрать с помощью продуктового займа всего 34 миллиона.

В октябре 1862 года, частично руководствуясь успехами армий КША на полях битвы, парижская Emile Erlanger and Company предложила представителям Конфедерации разместить её правительству займ. В марте 1863 года, после длительных переговоров, эта компания подписала соглашение о том, что станет брокером облигаций на 15 миллионов для различных подписчиков в Англии и нескольких странах Европы. Займы должны были погашаться хлопком при условии, что вкладчик принимает этот товар в пределах границ Конфедерации. В первые несколько месяцев реализации (т.е. перепродажи) займов Erlanger была довольно успешна. Однако в августе, после битвы при Геттисберге, спрос европейцев на эти облигации начал падать. К тому времени Erlanger прекратила реализацию облигаций, и эта сделка принесла Конфедерации всего около 8,8 миллионов вместо ожидаемых 15 миллионов долларов.

В марте 1865 года Конгресс Конфедерации одобрил ещё один выпуск облигаций на 30 миллионов, которые можно было приобрести только за наличные. Он обещал, что обратно облигации будут тоже выкупаться за наличные, и что это решение будет выполняться в течение двух лет после завершения войны. Нет никаких свидетельств о том, что удалось продать какой-то объём этих облигаций. Не удалось ему продать и меньший объём облигаций на 3 миллиона, выпущенный чуть позже в том же месяце. В свои последние дни КША получили 300 тысяч наличными от группы банков Ричмонда.

В сумме к концу войны КША осуществила более четырнадцати выпусков облигаций, позволивших профинансировать чуть больше одной трети их расходов.

Печать денег



50 долларов штата Луизиана

Хоть Казначейство Конфедерации и стремилось продавать в феврале 1861 года облигации за наличные, его руководство понимало, что потенциально высокие затраты на неминуемую войну заставят искать иные источники финансирования. Выпуск бумажных денег в виде банкнот Казначейства решал несколько задач, наиболее практической из которых было создание средства обмена для свободного обращения. Печать банкнот также создала деньги для формирования финансовой инфраструктуры КША и для платы поставщикам военной продукции. Правительство начало распространять эти банкноты (часть из них были векселями, по которым выплачивался процент) в марте 1861 года и печатало их номиналом от пяти долларов. С ростом военных затрат увеличивался выпуск и этих банкнот. Конгресс Конфедерации одобрял их печать в несколько траншей. Общая сумма выпущенных банкнот выросла к концу лета 1861 года до 300 миллионов, а к концу 1864 года до более чем 1,5 миллиарда.


5 долларов КША

Серьёзной проблемой стала подделка банкнот. Пытаясь бороться с этой проблемой, правительство несколько раз, с конца 1861 года до начала 1865 года, принуждало держателей банкнот обменивать один тип банкнот на другой, выводя из оборота процентные вексели и заменяя их беспроцентными банкнотами. Чиновники надеялись, что копящие вексели вкладчики будут использовать в качестве средств расчёта банкноты. Также Конфедерация выпустила новые вексели с другими условиями и датами погашения, и несколько раз пыталась превратить все эти вексели в законное средство платежа. В конечном итоге большинство банков Юга начали рассматривать их как приемлемый способ расплаты по всем видам долгов. Секретарь Казначейства Меммингер сказал, что назначение банкнот и векселей законными средствами платежа (legal tender) необязательно. Более того, он заявил, что подобные действия повредят самой сути Конфедерации, в основе которой лежат права штатов, и вызовут подозрения в том, что национальное правительство сильнее, чем необходимо. К его заявлению присоединились и другие голоса, сомневавшиеся в способности объявления законного средства платежа противодействовать высокому уровню инфляции и большим объёмам фальшивок, наносившим вред экономике Юга на протяжении всей войны.

Давление инфляции на экономику усугублялось печатью и обращением денег в виде банкнот, выпускавшихся почти всеми южными штатами, многими крупными городами региона, а также частными компаниями железными дорогами, частными магистралями, страховыми компаниями и т.д. На самом деле, потребность в дополнительных средствах обмена была настолько сильна, что многие независимые бизнесмены тоже выпускали собственные банкноты. Эти так называемые шинпластеры (shinplasters) позволяли их держателю получать определённое количество товаров или услуг от бакалейщиков, плотников, трактирщиков и т.п. Секретарь Казначейства Меммингер официально признал, что в обращении таких банкнот штатов/городов/бизнесов находится примерно на 20 миллионов долларов; однако историкам не удалось определить истинные объёмы таких коллективных видов денег.

Повышение пошлин и налогов



Кристофер Густав Меммингер

В мае 1861 года Секретарь Казначейства Меммингер предположил, что существующие тарифные законы и одобренные в феврале повышения ставок принесут КША в этом году 25 миллионов дохода. Однако из-за успешной блокады Союзом большей части побережья Юга общая полученная сумма была ближе к 1 миллиону. За весь период с 1861 по 1865 годы ввозные пошлины в сумме составили всего лишь 3,5 миллиона. Законопроект, одобривший в феврале 1861 года банковский займ, также налагал на весь хлопок, отправленный после 1 августа, вывозную пошлину, выплачиваемую наличными. Блокада Союза также ограничила экспорт хлопка и множества других продуктов. Несмотря на довоенные оценки в 20 миллионов, общая сумма доходов из этого источника была незначительной.

Ещё в мае 1861 года Секретарь Меммингер начал предполагать необходимость введения налогов на собственность, капитал, торговлю, запасы и т.п. В августе Конгресс одобрил налог на список из определённых пунктов, в том числе на недвижимость и стоимость рабов. Он должен был собираться в мае 1862 года на основании оценочной стоимости на конец 1861 года. Однако к моменту оплаты полную оценку выполнили всего два из одиннадцати штатов; шесть штатов даже к этому не приступали. В конечном итоге правительство начало собирать эти налоги; записи показывают, что к середине 1863 года было получено примерно 90% от общего оценённого объёма в 20 миллионов. Однако восемь из одиннадцати штатов заимствовали деньги (посредством банкнот штатов) для оплаты долгов по налогам своих граждан, испытывающих нехватку наличности. Поэтому общая сумма полученных от налогов средств оказалась значительно ниже ожидаемой.

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

В феврале 1864 года Конгресс Конфедерации был вынужден принять ещё один налоговый закон, вводящий новые налоги на большинство материальных активов физических и юридических лиц Юга. Как и в другие годы, урон, нанесённый боями, неэффективной системой сборов, большими масштабами мошенничества и вопиющим неповиновением привёл к тому, что сумма налогов составила всего 80% от 145 миллионов, предполагавшихся при введении закона. На протяжении военных лет, несмотря на множество политических, организационных и инфраструктурных препятствий, КША собрали более 200 миллионов в виде пошлин и налогов чуть больше 9% от своего общего дохода.

Заключение


Решения, принятые США и КША относительно источников финансирования во время Гражданской войны, отражают укоренившиеся идеологические воззрения этих двух территорий. Северяне обычно поддерживали традиционные идеи (увеличение федерального долга), а также новые концепции (национальная валюта и федеральный подоходный налог). Удачное появление банкира Джея Кука и его изобретательной схемы продажи облигаций сделало распространение различных долговых обязательств правительства гораздо более эффективным и действенными, чем могли предполагать официальные лица в начале войны. Южане, опасавшиеся национального политического и экономического доминирования центрального штата, не были заинтересованы в выпуске национальной валюты. Тем не менее, и центральное правительство, и сами штаты вполне охотно печатали разные типы платёжных средств в виде как беспроцентных банкнот, так и процентных векселей. Члены Конгресса Конфедерации противились общенациональному налогообложению и никогда не стремились получать значительный процент дохода Конфедерации из этого источника. Чиновники Казначейства с охотой выпускали долговые инструменты и часто применяли изобретательные концепции наподобие продуктовых и хлопковых займов для избавления от необходимости их погашения в дефицитных наличных средствах.

В конечном итоге, чиновники и США, и КША добились впечатляющих успехов в нахождении значительных финансовых ресурсов на поддержку своих армий на протяжении большей части четырёх долгих и кровавых лет. Северные штаты не были ареной серьёзных боёв, поэтому они могли сохранять продуктивность своих сельскохозяйственных, промышленных и коммерческих предприятий. Федеральное правительство имело и желание, и возможность использовать высокий уровень заёмной финансовой силы для финансирования военных затрат. Большинство бизнесменов, землевладельцев и торговцев продолжало вести достаточно продуктивную экономическую жизнь, поэтому могло выдерживать довольно высокий уровень налогов, введённых правительством для сбора дополнительных средств. Эксперимент по печати обеспечиваемых государством бумажных билетов, олицетворяющих деньги, тоже оказался довольно успешным, в основном благодаря вере населения в федеральное правительство. В конечном итоге, США смогли использовать заимствованные средства и денежные средства, полученные от повышения налогов, для удовлетворения почти 90% своих финансовых потребностей.

Южные штаты, которые со всей определённостью сделали свой вклад в экономическую мощь нации до войны, оказались просто не способны сохранить или расширить свою экономическую базу в условиях боевых действий. К сожалению, с ростом потребностей заёмных средств Конфедерации падала её кредитоспособность, поэтому займы, обеспеченные в начале конфликта, в его конце опустились до уровня номинала. Более того, политические лидеры и влиятельные граждане опасались давать центральному правительству достаточно власти для повышения налогов или создания национальной валюты. Хоть КША и смогли заимствовать средства на покрытие чуть более трети своих финансовых потребностей, обстоятельства вынудили их печатать и выпускать долговые обязательства (деньги) на сумму чуть больше половины их связанных с войной затрат.
Подробнее..
Категории: Научно-популярное , Финансовые инструменты , Читальный зал , Сша , Блог компании альфа-банк , Деньги , История денег , Налоги , История финансов , Кша , Конфедерация , Гражданская война , Civil war , Авраам линкольн , Джефферсон дэвис

27 июня, стрим-конференция Кодинг будущего

25.06.2020 14:15:14 | Автор: admin
Привет!

Если вы читали наши предыдущие посты, то уже знаете про Alfa Battle для Java-разработчиков. Послезавтра в прямом эфире можно будет посмотреть финал чемпионата, с 12.00 до 18.00.

Параллельно стриму с финалом мы запустим стрим-конференцию под названием Кодинг будущего, где с партнерами чемпионата (Билайн и X5 Retail Group) поговорим о футуристических прогнозах в IT. От компаний будут ведущие разработчики и топ-менеджеры.



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

Основных модулей стрим-конференции у нас получилось 6 штук:

  1. AI
  2. Web-банкинг
  3. Growth hacking
  4. Mobile banking
  5. Продуктовый дизайн
  6. Архитектуры Java-проектов

А вот сами доклады и спикеры.

Начнётся стрим в 12:00, вместе со стартом чемпионата Alfa Battle

12:05
Футуристический прогноз: российская IT-индустрия завтра
Михаил Тюрганов, Руководитель дирекции развития цифровых сервисов, Альфа-Банк
Павел Дерендяев, Руководитель центра компетенций Java, Альфа-Банк

Модуль #1. Java Alfa Digital


12:15
Технологии и инфраструктура Альфа-Мобайл
Максим Шатунов / Java Tech Lead, Альфа-Мобайл, Альфа-Банк

12:35
Эволюция корпоративного банка
Никита Хренов / Ведущий разработчик, Альфа-Банк

12:55
Внутреннее устройство сайта alfabank.ru
Максим Чернухин / Архитектор направления, Альфа-Банк

Модуль #2. AI Билайн


13:15
Интеллектуальная обработка звонков в реальном времени
Донат Фетисов / Head of Architecture and Infrastructure department, Билайн

Модуль #3. X5 Retail Group


13:40
Цифровизация помидора
Руслан Каймаков / Head of Web&Mobile Development, X5 Retail Group

14:05
От Java до Scala на грузовике Х5
Вадим Ануфриев, Senior Scala Developer, X5 Retail Group

Модуль #4. Кодинг будущего


14:30
Дискусcионная панель Кодинг будущего
Иван Пятков / Директор по цифровому бизнесу, член Правления Альфа-Банка
Донат Фетисов / Руководитель департамента по архитектуре и инфраструктуре данных, Билайн
Антон Вальков / Директор по IT, член правления X5 Retail Group

Модуль #5. Alfa Digital Products


15:15
Alfa Digital: Новый взгляд на банкинг
Дамир Баттулин / Head of Digital Channels, Альфа-Банк

15:30
Web-банкинг в эпоху Mobile 1st
Нина Красавина / Digital product owner, Альфа-Банк

15:40
Voice UX. Практическая магия
Владимир Китляр / Digital CPO, Альфа-Банк
Елена Грунтова / Руководитель продукта в ML сервисах Яндекс.Облака

16:00
Как мы делаем из Альфа-Мобайл лучший мобильный банк в стране
Евгений Тонкошкуров /СРО Альфа-Мобайла, Альфа-Банк

16:15
Роль лида дизайнеров цифровых продуктов
Анастасия Попова / Руководитель направления продуктового дизайна, Альфа-Банк

16:30
Дизайн нового Альфа-Мобайла
Вячеслав Киржаев / Lead Product Designer, Альфа-Банк

16:45
Про страшные ругательства: Growth Hacking и Dual-track Agile
Илья Кузнецов / CPO Digital Innovations, Альфа-Банк

Модуль #6. Alfa Digital Products


17:00
Финиш чемпионата Alfa Battle

17:15
Интервью с Владимиром Верхошинским
Главный управляющий директор, член Наблюдательного совета Альфа-Групп

17:45
Подведение итогов и награждение победителей
Владимир Верхошинский

Подробнее..
Категории: Конференции , Java , Дизайн мобильных приложений , Финансы в it , Исследования и прогнозы в it , Блог компании альфа-банк , Alfa battle , Стрим-конференция , Дизайн веб-интерфейсов , Билайн , X5 retail group

21 и 22 января два бесплатных онлайн-митапа (QA и iOS)

14.01.2021 16:09:15 | Автор: admin

Привет! Новый год новые митапы.

Уже через неделю мы проведём два первых в этом году митапа, первый из которых будет полезен тестировщикам, а второй iOS-разработчикам. Спикеры будут из Альфа-Банка, а вот участники круглого стола по теме из Сбера, Тинькофф и Райффайзенбанка.

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

Программа под катом

21 января, 19.00 МСК QAчественное общение

В программе 3 доклада от Альфа-Банка и викторина с призами. Мы постараемся сделать эти пару часов максимально полезными для всех собравшихся.

Чтобы принять участие в митапе, обязательно зарегистрируйтесь. Мы отправим вам напоминание и ссылку на трансляцию.

19:05-19:40, Дмитрий Гадеев, Kubernetes. Жизнь ДО и ПОСЛЕ

Руководитель направления сопровождения инфраструктурных сервисов, Альфа-Банк

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

19:40-20:10, Ксения Коломиец, Сайт-конструктор. Тестирование без боли

Старший специалист по тестированию, Альфа-Банк

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

20:10-20:40, Александр Долинский, Тестирование API в большой команде

Руководитель группы тестирования, Альфа-Банк

Пройдем по истории развития тестирования мобильного банка. Соберем некоторые грабли большого проекта.

20:40-21:00, Викторина в Kahoot с розыгрышем призов

Страница регистрации

22 января, 19.00 МСК Mobile Talks

19:05-19:40, Василий Пономарев, Техническая сторона UI-компонентов

iOS-разработчик, Альфа-Банк

Василий расскажет о реализации UI-компонентов, принятых на вооружение архитектурных решениях. А также покажет пример из практики и разберет преимущества и недостатки данного подхода.

19:40-20:15, Евгений Онуфрейчик, Новый разработчик. От старта до выхода на орбиту

iOS-разработчик, Альфа-Банк

Женя расскажет о процессе погружения нового разработчика в проект мобильного приложения Альфа-Банка, о сложностях адаптации и как мы с ними справляемся. Объяснит, как выглядит процесс со стороны новичка что он ощущает и как понимает происходящее. А также расскажет, какова в этом роль и зоны ответственности наставника.

20:15-20:35, Викторина в Kahoot с розыгрышем призов

20:35-21:35, Круглый стол Качество vs скорость разработки как найти баланс?

  • Сергей Нанаев, Head of iOS, Альфа-Банк

  • Роман Голофаев, Mobile Community Lead, Райффайзенбанк

  • Александр Поломодов, Руководитель управления разработки цифровых экосистем, Тинькофф

  • Иван Бубнов, Руководитель направления мобильной разработки, Сбер

Страница регистрации.

Подробнее..
Категории: Конференции , Разработка под ios , Тестирование it-систем , Тестирование , Митапы , Ios , Qa , Блог компании альфа-банк , Альфа-банк , Ios-разработка

23 июня, 1900 онлайн-митап QAчественное общение

15.06.2021 14:10:21 | Автор: admin

Привет!

Вы уже догадались по названию, какой теме будет посвящен этот митап.

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

Меняется лишь состав спикеров и обсуждаемые вопросы. Вот они:

19:05 19:35, Контрактное тестирование Rest API

Семен Ковалев, старший специалист по тестированию, Альфа-Банк

Семен расскажет отом, что такое контрактное тестирование, иразберет простой пример контрактного теста наPostman.

19:35 20:05, Структурированный подход к организации тестов

Анна Сотниченко, специалист по тестированию, Альфа-Банк

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

20:05-20:35, Построение модели Onboarding в QA

Иван Боклач, руководитель группы тестирования,Альфа-Банк

Подключайтесь, будет интересно.

Подробнее..
Категории: Конференции , Тестирование it-систем , Тестирование , Тестирование веб-сервисов , Qa , Блог компании альфа-банк , Quality assurance

Перевод Расширение кластера PostgreSQL размером 5,7ТБ и переход с версии 9.6 на 12.4

26.01.2021 16:05:52 | Автор: admin

Фото Ричарда Джекобса на Unsplash

В ноябре 2020 года мы начали крупную миграцию для обновления кластера PostgreSQL с версии 9.6 на 12.4. В этом посте я вкратце расскажу про нашу архитектуру в компании Coffee Meets Bagel, объясню, как даунтайм апгрейда удалось снизить ниже 30 минут, и расскажу про то, что мы узнали в процессе.

Архитектура


Для справки: Coffee Meets Bagel это приложение для романтических знакомств с системой курирования. Каждый день наши пользователи получают в полдень по их часовому поясу ограниченную партию высококачественных кандидатов. Это приводит к хорошо предсказуемым закономерностям нагрузки. Если посмотреть данные за последнюю неделю от момента написания статьи, у нас в среднем получается 30 тысяч транзакций в секунду, в пике до 65 тысяч.



До обновления у нас работали 6 серверов Postgres на инстансах i3.8xlarge в AWS. Они содержали одну главную ноду, три реплики для раздачи веб-трафика только для чтения, балансируемые с помощью HAProxy, один сервер для асинхронных воркеров и один сервер для ETL [Extract, Transform, Load] и Business Intelligence.

Для поддержания парка реплик в актуальном состоянии мы полагаемся на встроенную в Postgres потоковую репликацию.



Причины для апгрейда


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


Мой кандидат для подреддита r/uptimeporn

Как итог, накопилось множество странностей, которые заставляют понервничать. К примеру, новые сервисы в systemd не запускаются. Пришлось настраивать запуск агента datadog в сессии screen. Иногда SSH переставал отвечать при загрузке процессора выше50%, а сам сервер исправно отдавал запросы базы данных.

А ещё свободное место на диске начало подходить к опасным значениям. Как я упоминал выше, Postgres работал на инстансах i3.8xlarge в EC2, у которых 7,6ТБ хранилища NVMe. В отличие от EBS, здесь размер диска динамически менять нельзя что заложено изначально, то и будет. И мы заполнили примерно 75% диска. Стало понятно, что для поддержания будущего роста размер инстанса придётся менять.

Наши требования


  1. Минимальный даунтайм. Мы поставили целью ограничение в 4 часа суммарного даунтайма, включая незапланированные отключения, вызванные ошибками при обновлении.
  2. Собрать новый кластер баз данных на новых инстансах для замены текущего парка стареющих серверов.
  3. Перейти на i3.16xlarge, чтобы был простор для роста.

Нам известны три способа выполнить обновление Postgres: создание резервной копии и восстановление из неё, pg_upgrade и логическая репликация pglogical.

От первого способа, восстановления из резервной копии, мы отказались сразу: для нашего датасета на 5,7ТБ он занял бы слишком много времени. При своей скорости приложение pg_upgrade не удовлетворяло требованиям 2 и 3: это инструмент для миграции на той же машине. Поэтому мы выбрали логическую репликацию.

Наш процесс


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


Мы создали новый primary-сервер Postgres 12 и с помощью pglogical синхронизировали все наши данные. Когда он синхронизировался и перешёл к репликации входящих изменений, мы начали добавлять за него потоковые реплики. После настройки новой потоковой реплики мы включали её в HAProxy, а одну из старых версии 9.6 удаляли.

Этот процесс продолжался до полного отключения серверов Postgres 9.6, кроме мастера. Конфигурация приняла следующий вид.



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

  1. Перевод сайта в режим технических работ;
  2. Смена записей DNS мастера на новый сервер;
  3. Принудительная синхронизация всех последовательностей (sequences) первичных ключей (primary key);
  4. Ручной запуск контрольной точки (CHECKPOINT) на старом мастере.
  5. На новом мастере выполнение некоторых процедур валидации данных и тестов;
  6. Включение сайта.

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

Извлечённые уроки


При общем успехе операции пара проблем по пути всё же встретилась. Самая страшная из них чуть не убила наш мастер Postgres 9.6

Урок 1: медленная синхронизация может быть опасной


Обозначим для начала контекст: как работает pglogical? Процесс передачи (sender) на поставщике (provider, в данном случае наш старый мастер 9.6) декодирует упреждающий журнал WAL [write-ahead log], извлекает логические изменения и посылает их на подписчика (subscriber).

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

При первом добавлении таблицы в поток репликации приложению pglogical сначала нужно синхронизировать данные таблицы. Это выполняется с помощью команды Postgres COPY. После этого сегменты WAL начинают копиться на поставщике, чтобы изменения за время работы COPY получилось передать на подписчика после изначальной синхронизации, гарантируя отсутствие потери данных.

На практике это означает, что при синхронизации большой таблицы на системе с большой нагрузкой по записям/изменениям нужно тщательно следить за использованием диска. При первой попытке синхронизации нашей самой крупной (4ТБ) таблицы команда с оператором COPY работала больше суток. За это время на ноде поставщика набралось больше одного терабайта упреждающих журналов WAL.

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


Доступное дисковое пространство на старом мастере при первой попытке синхронизации

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

  • Удалили все индексы в синхронизируемой таблице;
  • fsynch переключили на off;
  • Поменяли max_wal_size на 50GB;
  • Поменяли checkpoint_timeout на 1h.

Эти четыре действия значительно ускорили процесс синхронизации на подписчике, и наша вторая попытка синхронизации таблицы завершилась за 8 часов.

Урок 2: каждое изменение строк журналируется как конфликт


Когда pglogical обнаруживает конфликт, приложение оставляет в логах запись вида CONFLICT: remote UPDATE on relation PUBLIC.foo. Resolution: apply_remote.

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

Эту проблему удалось решить заданием параметра pglogical.conflict_log_level = DEBUG в файле postgresql.conf.

Об авторе


Томми Ли старший инженер программного обеспечения в компании Coffee Meets Bagel. До этого он работал в Microsoft и канадском производителе систем автоматизирования бухгалтерского учёта Wave HQ.
Подробнее..
Категории: Postgresql , Sql , Администрирование баз данных , Базы данных , Блог компании альфа-банк , Amazon web services , Aws , Ec2 , Coffee meets bagel , Миграция базы данных , Pglogical , Postgresql 9.6 , Postgresql 12.4 , Postgresql 12

Перевод Сервисы с подпиской должны давать своим пользователям уйти

09.06.2021 14:20:05 | Автор: admin
Никто не любит, когда человек бросает все и уходит. Я говорю не (только) о ситуации, когда тренер школьной команды норовит пристыдить спортсмена, который решает её покинуть. Я имею в виду момент, когда пользователь решает перестать пользоваться услугой или сервисом и хочет отменить свою подписку эта модель бизнеса в настоящее время является наиболее популярной. Ее использует многие компании, начиная от таких гигантов как Spotify и заканчивая мелкими стартапами, такими как Stitch Fix.


Картинка: Tom Guilmard

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

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

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

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

Возможно, такое мнение Мэриана объясняется его личной заинтересованностью в вопросе и не является полностью объективным, но в его точке зрения определенно есть смысл. Он отмечает примеры, когда компании (важно: не являющиеся его клиентами) весьма творчески подошли к процессу отмены подписки. Например, ему понравилось, как компания Audible, предоставляющая подписку на аудиокниги, выяснила, что у нее есть целая прослойка клиентов (студенты университетов) которые не хотят платить за подписку летом. Компания предложила своим клиентам новую опцию Заморозка абонемента. Компания Netflix, стремясь предложить своим пользователям альтернативный вариант вместо стандартных продолжить использование или отписаться, стала предлагать желающим отписаться опцию перейти на более дешевый тариф вместо того, чтобы просто потерять клиента. Эти опции предлагаются в очень простой и понятной манере, в отличие от запутанных и сложных условий использования пакетов интернет + ТВ, и это то, что может заставить клиента передумать отписываться.

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

Смысл в том, чтобы пользователь получил приятный опыт, когда он отменяет подписку, заявляет Мэрион из компании Brightback. Процесс отписки клиента с многолетней историей использования сервиса должен отличаться от процесса того, кто подписался три недели назад. Но в любом случае при отмене подписки нужно задать клиенту несколько вопросов, чтобы получить базовые сведения, почти по той же схеме, как это делается при уходе сотрудника из компании: к кому уходит бывший клиент, почему он уходит, есть ли вероятность, что он вернется позднее. Цель такого опроса выяснить, что стоит изменить.

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

Каждой IT-компании известно, как дорого обходится каждый новый лид, и эта стоимость растет. Согласно исследованию компании по анализу маркетинга AdStage, в 2017 цена за клик в рекламе на Facebook выросла на 136% за 6 месяцев.

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

Когда в CleverTap обратился индийский сервис мобильных платежей MobiKwik, CleverTap провела исследования и обнаружила, что 30% новых клиентов удаляло приложение в течение первой недели использования. Когда MobiKwik добавили различные акции и выгодные предложения для новых пользователей в первые три-четыре дня после скачивания приложения, количество удалений сократилось на 10%. Затем были разработаны стратегии, направленные на удержание клиентов, которые решили перестать пользоваться сервисом. По данным CleverTap, в результате этих изменений компания отвоевала 23%25% пользователей, которые раньше просто удаляли приложение.

Рассмотрим, как устроена работа сервисов подписок на коробки с неким содержимым так называемые subscription box. В настоящее время насчитывается более 3500 компаний, предоставляющих помесячную подписку на нечто-в-коробке (это может быть одежда, бьюти-продукты и т.д.). Большинство из них вначале делают какое-то заманчивое предложение, чтобы заинтересовать новых клиентов и побудить их попробовать сервис. Это могут быть скидки, бесплатный пробный период, ограниченные предложения то, что в идеале приведет к долгосрочным отношениям с клиентом. Я общался со многими подобными компаниями, говорит Мэрион, и часто отток составляет у них от 50% до 60% клиентов в течение первых трех месяцев использования сервиса.

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

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

Мэрион цитирует результаты исследования примеров из его практики, куда входит кейс одного из его первых его клиентов компании веб-аналитики Crazy Egg. (Следует отметить, что чаще всего клиенты Brightback занимаются B2B, но они также работают с двумя стартапами B2C в качестве пробного проекта). Используя программное обеспечение Brightback для анализа процедуры отмены подписки, компания Crazy Egg обнаружила, что значительное число клиентов отменяют подписку не обязательно по причине того, что они не удовлетворены качеством сервиса. Клиентам просто не хватило времени, чтобы разобраться в том, как пользоваться продуктом, или получить желаемые результаты. До этих клиентов еще можно дотянуться, чтобы сохранить их.

Несмотря на то, что бизнес-модель компании Brightback весьма специфична, у них есть ценная идея о том, что стоит уделять внимание пользователям, которые решили отписаться. Это особенно актуально для компаний, которые больше заинтересованы в сохранении клиентов, повышении их лояльности и как следствие, постепенном и уверенном росте дохода, а не в пустых (но впечатляющих) цифрах новых подписок. Цель компании должна заключаться в том, чтобы понять, почему клиент решил уйти, и сделать ему выгодное предложение, которое заинтересует его и побудит его продолжить пользоваться сервисом, считает Мэрион. У клиента не должно остаться неприятных впечатлений.
Подробнее..
Категории: Маркетинг , Сервисы , Реклама , Разработка под e-commerce , Блог компании альфа-банк , Повышение конверсии , Интернет-маркетинг , Контекстная реклама , Подписки , Доколе

6 мифов о разработке в финтехе

19.06.2020 16:07:35 | Автор: admin
Привет!

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



Как обычно, всё немного не так, как кажется на первый взгляд. Под катом мы расскажем о 6 самых распространенных заблуждениях, о том, как всё работает у нас в Альфе, и причём тут Alfa Battle.

Миф #1. Банки используют только старые версии Java, 68


На восьмёрке мы стали писать примерно лет 5 назад, это была первая версия нашего интернет-банка, собранного на микросервисной инфраструктуре. И сейчас это минимально используемая версия, обычные будни же это 13 и 11.

В чем польза:

  • Получаем быстрый доступ к новым JEP и возможность использовать новые фичи сразу, без задержек при переходе на новую версию.
  • Оптимизируем работы в docker-контейнере.
  • Получаем более функциональные стримы с каждым релизом.

Чтобы разработчик не скучал в ожидании сборки проекта и мог заняться решением более интересных задач, для старта java-приложения мы используем jvm-параметры (например, *RAMPercentage), что позволяет быстро задавать размер памяти в процентах, отталкиваясь от памяти контейнера, и оптимизировать работу приложения в нем.

А ещё мы храним в распакованном виде JAR-архивы, чтобы закешировать часто используемые библиотеки, которые не применяются от сборки к сборке, и в целом ускорить запуск проекта. Раньше старт контейнера со Spring Boot занимал 40 секунд, теперь 15. Сейчас думаем попробовать JEP 351 ZGC Uncommit Unused Memory (Java 13), чтобы ещё больше оптимизировать работу сервисов.

Подробнее о Java в Альфе мы будем рассказывать на стриме нашего онлайн-чемпионата Alfa Battle, он будет вот на этой странице 27 июня (суббота).

Миф #2. Оркестраторы помнят доллар по 30


У нас Mesos Marathon и более 10 больших Mesos-кластеров под проекты банка, которых несколько сотен. И всё бы ничего, но современным требования разработки Mesos отвечает, прямо скажем, с трудом. Возможен ли переход в рамках банка на новый оркестратор?

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

Миф #3. Финтех это легаси


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

Поэтому частично монолитное легаси все еще с нами, но мы продолжаем расколупывать его на микросервисы. Понемногу, аккуратно и с напильником вместо перфоратора, но процесс идет. И опять же, это если говорить о возрастных и критичных проектах. Новые же проекты сразу пишутся на Java 11 и 13, Kotlin, SpringBoot 2, Kafka, Spring Reactor/WebFlux.

Миф #4. Финтех это корпоративная почта only и запрет других коммуникаций


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

Самый же рабочий с точки зрения активности канал в Альфа-Банке это Slack. Причем используем там почти всё, что только дает делать сервис: напоминания, уведомления, привязки к тестовым средам, алерты от мониторинга и многое другое. Это реально удобно.

Миф #5. Если мониторинг то вендорский и дорогой


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

Но ещё у нас есть Zabbix, например. Микросервисы же мониторятся с помощью Grafana, Micrometer и Prometheus. Последний, кстати, подкупил нас тем, что возможностей там уйма, а интеграция при этом довольно проста. Вообще, мониторинга много не бывает, и с помощью Prometheus мы мониторим почти всё, включая лаг синхронизации Kafka-кластеров через MirrorMaker.

Миф #6. Любая доставка на продакшн в банке это бюрократический ад


Судя по ситуации на рынке, это сильно зависит от банка. Мы пошли по пути пайплайнов на Jenkins и Bamboo. Когда процесс доставки в достаточной мере автоматизирован с помощью CI/CD, то почти никогда не нужны дополнительные письма, согласования, заявки и прочее добро. То есть, процесс выглядит примерно так:

  • Разработчик запускает процесс.
  • Проходят автоматические тесты.
  • Инженер саппорта одобряет раскатку на прод.
  • Новая функция улетает на ограниченное количество пользователей.

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

Alfa Battle


Как мы уже писали, скоро пройдёт Alfa Battle, онлайн-чемпионат по прикладному программированию на Java от нас и наших партнеров Билайн, X5 Retail Group и Jug.ru.

Если хотите присоединиться и попробовать свои силы вот страница регистрации. Отбор ещё идёт, до 25 июня.

Если же хочется просто посмотреть, то 27 июня будет стрим, с 12.00 до 18.00.
Подробнее..
Категории: Разработка , Devops , Хакатоны , Java , Финансы в it , Блог компании альфа-банк , Альфа-банк , Alfa battle

Техдолг нельзя копить, закрывать

05.05.2021 14:10:44 | Автор: admin

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

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

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

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

В этот момент вы вспоминаете: Почему я не выполнил сразу работы по ремонту, а отложил их подальше?!

Вот и с техдолгом похожая ситуация.

Какими могут быть последствия накопления техдолга?

  • Снежный ком документов

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

  • Отсутствие экспертизы для будущих поколений

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

  • Время разбора дефектов увеличивается

Наташ, мы все уронили!

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

  • Негатив от команды

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

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

Что мы сделали?

  1. Собрали рабочую группу, в которую включили аналитиков от каждого направления из центра компетенций аналитики удаленных каналов доступа (Альфа-Мобайл, Сайт, Интернет-банк и др);

  2. Определили, что такое техдолг, и как выбирать приоритеты;

  3. Расписали процесс ведения, включения задач по техдолгу в бэклог, ответственных;

  4. Сформулировали ситуации, сигнализирующие, что техдолг растет, и определили, что делать в таких случаях;

  5. Собрали задачи по техдолгу в рамках направлений.

Что такое техдолг и как выбирать приоритеты?

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

......

Приоритет

Ситуация

важный

На функционал в промышленной среде нет документации;

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

средний

Существующий документне соответствует актуальному шаблону. Документ сложно читать и понимать. Приоритет выбирается совместно с техлидом аналитика;

неактуальный; не полностью описывает функционал в проде.

низкий

Существующий документ не соответствует актуальному шаблону. Документ понятен, но визуально выглядит иначе. Приоритет выбирается совместно с техлидом аналитика;

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

Как завести задачу по техдолгу в backlog?

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

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

Правила ведения задач в jira

Поле

Как заполнить

Тип

task

Приоритет

Важный

Средний

Низкий

Метки

Техдолг_команда_функциональность

Тема

[вид функциональности] Описание работ

Вид функциональности: фронт, сервис (имя), архитектура

Описание работ: написать/актуализировать

Описание

Цель: опционально, когда необходимо обосновать приоритет

Что: написать/актуализировать + ссылки на материалы

Dod: аналитика подготовлена, согласована

В качестве инструкции и отчета в первой версии создали статью в Confluence с содержанием:

  • Что такое техдолг

  • Почему важно закрывать техдолг

  • Ответственность

    • Кто добавляет задачи

    • Как задача попадает в техдолг

  • Процесс работы с техдолгом

  • Как ведем задачи в Jira

    • Кто закрывает техдолг

    • Кто следит за выполнением

  • Список задач

    • Срез задач на 2 квартал 2021

Список задач собрали автоматически с помощью макроса Jira и настроили возможность фильтрации с помощью макроса Фильтр таблиц. Для визуального отображение использовали макрос Jira круговая диаграмма

Что делать, если техдолг растет

Ситуация 1 растет тех.долг

Решение: Бери задачи по техдолгу в работу в sprint.

Ситуация 2 увеличилось время разборов дефектов из-за отсутствия документации

Решение: Выполняй задачи по техдолгу.

Ситуация 3 хочешь повысить оценку компетенций для продвижения по карьерной лестнице

Решение: Помогай другим направлениям закрывать их техдолг.

Как закрывать техдолг, а не копить

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

Каждый аналитик из рабочей группы в рамках своего направления:

  • создал задачи в JIRA по текущему техдолгу;

  • написал статью по шаблону. Пример статьи был выше;

  • обсудил с аналитиками из своего направления, кто какие задачи возьмет в работу в следующем квартале;

  • рассказал аналитикам из своего направления, какие правила заведения задач по техдолгу.

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

Это процесс легко могут переиспользовать другие направления: разработчики, тестирование.

Следующим шагом будет настройка dashboard для мониторинга прироста задач по техдолгу.

Предупрежден значит вооружен.

А на какой стадии принятия вы, в вашей компании есть тех.долг по аналитике? Возможно, у вас есть средство, которое позволяет не иметь тех.долга и быстро доставлять изменения до промышленной среды вместе с документацией?

Подробнее..
Категории: Разработка , Карьера в it-индустрии , Учебный процесс в it , Управление разработкой , Аналитика , Статистика в it , Блог компании альфа-банк , Альфа-банк , Техдолг , Системный анализ , Процесс

Как мы унифицировали онбординг аналитиков удалённых каналов доступа

20.11.2020 12:14:59 | Автор: admin
Испытательный срок это не только время, за которое компания проверяет, правильного ли сотрудника взяли на ставку, справляется ли он с обязанностями и как в целом работает. Это в том числе (об этом часто забывают) период, за который сотрудник не менее пристально оценивает компанию: соответствуют ли задачи озвученным на собеседовании, как дела с командой, адекватно ли выстроены рабочие процессы, да и вообще нравится работать тут или нет.

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



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

Зачем вообще унифицировать онбординг


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

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

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

Чего хотелось добиться


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

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

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

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

Результатом виделось вот такое положение дел.

  • с первых дней выхода человека в штат максимально насыщаем его всей нужной информацией
  • при этом помогаем наставникам проводить на самом деле качественный онбординг
  • унифицируем систему оценки качества проведенного онбординга


Как решили всего этого добиться


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

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

Все картинки кликабельны







Во-вторых, было сформулировано 6 критериев для оценки аналитика УКД архитектура, документация, техника, процессы, работа с ошибками и коммуникации. По каждому критерию выделены требования к аналитику и приведены ссылки на справочные материалы.



И наконец, на основе требований к аналитику мы разработали шаблоны планов на испытательный срок (мы их называем планами на 100 дней). Шаблоны были разработаны в привязке к каналам и учитывали как общие требования, так и специфику канала.



Что же в итоге


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

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

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

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

Спасибо, что дочитали. Было бы интересно узнать, как устроен процесс онбординга в других организациях, какие материалы используются для помощи новичку и наставнику. Будет здорово, если поделитесь вашим опытом в комментариях.
Подробнее..
Категории: Управление персоналом , Карьера в it-индустрии , Учебный процесс в it , Аналитика , Блог компании альфа-банк , Альфа-банк , Обучение , Карьера в it , Системный анализ

Онбординг наставников или быстрое погружение в наставничество

08.02.2021 16:12:50 | Автор: admin

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

При этом я в Екатеринбурге, а новый сотрудник в Москве. Страх, испуг и непонимание.

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

Что мы сделали

  1. Придумали формат общения руководителя и наставника.

  2. Подготовили памятку для наставника.

  3. Создали обучение для новых наставников.

  4. Разработали процесс онбординга с шаблонами планов на 100 дней (испытательный срок).

Формат общения руководителя и наставника

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

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

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

За неделю до выхода новичка руководитель передает всю информацию наставнику в формате:

  • ФИО

  • Мобильный телефон

  • Адрес офиса

  • Формат работы (удаленно или рабочее место)

  • Дата выхода

  • Команда и контакты product owner/project manager

  • Дополнительная информация

За неделю наставник успевает подготовиться к выходу сотрудника.

Памятка для наставника

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

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

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

  • Желание передавать опыт. Поставьте себя на место новичка и поймите, как важно передавать накопленный у наставника опыт

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

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

Еще в памятке мы описали шаги на каждый день испытательного срока.

До выхода новичка

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

За 2-3 дня до выхода наставник

  • Отправляет новичку SMS :

Привет! Меня зовут , ятвой наставник вАльфа-Банке. Твое рабочее место икартинку спояснением, как найти это место. Сейчас наставники работают удаленно, анекоторым новичкам приходится приехать впервый день вофис.

  • Проверяет, подготовлено ли рабочее место.

  • Отправляет приветственное письмо с полезными ссылками на первый день.

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

День первый (выход новичка)

Вот он, день Х. Наставник в ожидании, уточняет у новичка, удалось ли ему найти рабочее место, получилось ли зайти в учетную запись на ПК.

В первый день у новичка стресс, волнение, поэтому рекомендуется не слишком грузить его информацией, поэтому наставник:

  • проводит установочную встречу (созвон) не более 30 минут. На этой встрече рассказывает верхнеуровнево, как все устроено в команде, что примерно предстоит делать;

  • добавляет новичка в каналы коммуникации и знакомит с командой

  • добавляет в обязательные встречи;

  • создает план на испытательный срок по шаблону;

  • добавляет задачи в jira для прохождения обязательных курсов и испытательного срока;

  • создает обязательные встречи 45 дней, 90 дней прохождение испытательного срока.

День второй

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

Наставник во второй день проводит встречу (не более часа), на которой рассказывает:

  • как устроена система, которой будет заниматься новичок ;

  • как будет проходить испытательный срок;

  • знакомит новичка с планом на испытательный срок и критериями его прохождения (это важно, чтобы новичок не нервничал);

  • рассказывает о организационной структуре компании (отдела);

  • показывает задачи в jira;

  • находит бизнес задачу с product owner команды на испытательный срок.

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

3-4 дни

Новичок знакомится с информацией в плане на 100 дней, а у наставника есть время заняться своими командными задачами и поставить еженедельную встречу 1-to-1 (не более 30 минут)

На встречах 1-to-1 наставник и новичок обсуждают вопросы по плану 100 дней, закрывают задачки из него. Также наставник интересуется, нравится он новичку или нет, так как наставник = друг. Эти встречи рассказывать информацию порционно. Новичок при этом чувствует поддержку и нет ситуации "Меня бросили и плыви как хочешь". Регулярность встреч поначалу 1-2 в неделю, потом уменьшается спустя месяц до 1-2 раз в неделю..

45-й день

Экватор, половина испытательного срока.

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

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

90-й день

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

Презентация состоит из трех частей:

  • слушаем нового сотрудника;

  • наставник показывает итоги опроса, подсвечивает зоны роста, плюсы и минусы;

  • техлид и product owner команды дают обратную связь.

Скриншоты опроса (много картинок)
Скрины презентации

В день Х все собираются (наставник, руководитель, новичок и команда).

Встреча проходит по формату:

  • Говорит новичок что удалось сделать за испытательный срок, что понравилось, а что нет.

  • Руководитель и команда дает обратную связь.

  • Наставник показывает план 100 дней и презентацию с итогами прохождения.

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

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

Обучение наставников

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

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

Мы смогли привлекать к наставничеству большое количество аналитиков, потому что ребята перестали бояться неизвестности.

Сталкивались ли вы с подобным, когда впервые были наставниками?

Подробнее..
Категории: Управление персоналом , Карьера в it-индустрии , Учебный процесс в it , Блог компании альфа-банк , Альфа-банк , Карьера в it , Наставничество

Перевод Один год удалённой работы в Figma

13.04.2021 16:13:10 | Автор: admin
image

Оптимизация удалённой работы


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

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

image

Использованный в эксперименте подборщик шаблонов

Наши открытия


Мы выяснили, что пользователи, получившие подборщик шаблонов, имели показатель сотрудничества на 5% больше. Он измеряется как процент пользователей, вносящих правки или комментарии в общий файл. Кроме того, мы заметили, что при помощи подборщика шаблонов пользователи обнаруживали новые функции на 10% больше пользователей обнаружило пресеты кадров, а на 90% больше пользователей использовало в своём процессе творчества файлы Figma Community. Это относилось и к дизайнерам, и к их коллегам, не занимающимся дизайном в число наиболее популярных файлов вошли и специализированные дизайнерские шаблоны (для организации удалённых дизайнерских спринтов), и более общие, например, шаблоны whiteboarding и тим-билдинга.

Даже несмотря на то, что эксперимент проводился с частью нашей пользовательской базы, он не остался незамеченным. Мы получили положительные отзывы в социальных сетях и просьбы о добавлении в подборщик шаблонов документов для других сценариев использования. Рабочие коллективы не просто использовали этот контент, но и благодарили за него. Основная задача Figma Community объединять пользователей, чтобы они могли делиться, учиться и общаться. Это стало идеальным примером того, как мы можем находить способы сотрудничества в мире, где так важна стала удалёнка, полагаясь на работу друг друга.

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

Карта сотрудничества


Отметив положительную реакцию сообщества, мы решили оценить изменения количественно и сопоставить шаблоны с компаниями и регионами, особенно учитывая тот факт, что больше 80% пользователей Figma находится за пределами США. Мир движется в сторону удалённой работы, а мы наблюдаем рост сотрудничества между странами и часовыми поясами. На изображении ниже показаны приглашения и обмены файлами между пользователями в разных странах. Каждая связь обозначает обмен, а каждая страна раскрашена в соответствии с объёмом международного сотрудничества чем темнее страна, тем больше совместной работы.

image

Подробнее о том, что мы выяснили:

Между регионами


В 2020 году Европа была регионом с самым активным ростом международного сотрудничества: в феврале 2021 года количество обменов файлами удвоилось по сравнению с тем же месяцем прошлого года. На глобальном уровне количество файлов, над которыми работают совместно в разных часовых поясах в феврале 2021 года, по сравнению с тем же месяцем прошлого, выросло в 3,5 раза (а для всех файлов в целом рост составил 2,6 раза).

Между дизайнерами и их коллегами


В рамках команд мы наблюдаем тенденцию к тому, что всё больше недизайнеров присоединяется к дизайнерским рабочим пространствам своих коллективов и становятся частью процесса дизайна. В профессиональных коллективах и организациях соотношение дизайнеров и недизайнеров выросло с февраля 2020 года по февраль 2021 года, и на каждого дизайнера в коллективе стало приходиться на 25% больше недизайнеров. С ростом необходимости асинхронных коммуникаций дизайнеры делятся своими файлами в режиме только просмотр с коллегами, чтобы получать обратную связь в реальном времени. Эта тенденция отражается и в росте количества файлов, к которым дизайнеры открывают доступ для своих коллег-недизайнеров (+140%), и в увеличении отношения редактирующий/просматривающий (+12%), произошедших за последний год.

В рамках дизайнерского процесса


Также мы заметили, что большее количество коллективов начало сотрудничать в Figma на более ранних этапах жизненного цикла файлов. В течение 90 дней мы замеряли метрику время до начала сотрудничества измеряемую как количество дней, прошедшее между датой создания файла и первым случаем открытия файла другим сотрудником (не тем, кто создал файл). Среднее время до начала сотрудничества упало на 11% с периода перед началом пандемии COVID до второго квартала года (когда большинство компаний начало работать удалённо), и оставалось стабильным до конца 2020 года.

image

Перенос офлайн-процессов в онлайн


Изучая полученные данные (в дополнение к своему опыту удалённой работы в Figma), мы обратили внимание, что дизайнеры всё активнее делятся файлами со своими коллегами из смежных отраслей, и что это сотрудничество более гибко перетекло в структуры организаций и коллективов. Мы связались с представителями Atlassian и Dropbox, чтобы ознакомиться с их наблюдениями и сопоставить статистику сотрудничества до и после COVID.

Сотрудничество между людьми разных профессий в Atlassian


В начале марта 2020 года Atlassian активно начал использовать Figma сразу после того, как закрыл свои офисы из-за пандемии. Дизайнер Джейк Миллер сказал нам, что переход к работе над файлом в Figma сильно напомнил ему ощущения от работы в офисе с коллегами. Наблюдение за тем, как движутся курсоры, вселяет в тебя ощущение сотрудничества, а не просто сдачи готовой работы по частям, говорит Джейк. Процесс дизайна становится социализированным. И такой уровень сотрудничества выходит за рамки команды дизайнеров, он междисциплинарен. Благодаря использованию файлов Figma в Confluence, каждый становится частью процесса дизайна, рассказывает Джейк. Никто не остаётся исключённым из цикла.

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

image

Граф сотрудничества команды Atlassian в Figma до и после появления COVID

Асинхронность в первую очередь в Dropbox


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

Хотя сотрудники, естественно, стремились решать рабочие вопросы через видеозвонки, это приводило к усталости от Zoom, перегруженности коммуникациями, постоянным контактам и нехватке времени для фокусировки на стратегической и творческой работе, рассказывает вице-президент Dropbox по дизайну Алистер Симпсон.

image

Граф сотрудничества команды Dropbox в Figma до и после появления COVID

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

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

За последний год очень многие компании фундаментально изменили способ своей работы, а то и в корне поменяли свою бизнес-модель. Хотя удалённая работа в какой-то степени определённо была усовершенствованием, мы надеемся, что часть таких изменений открытое взаимодействие, более широкая включённость сотрудников в процессы и обмен между разными командами останутся и после неё.
Подробнее..
Категории: Управление персоналом , Удаленная работа , It-компании , Управление продуктом , Управление командой , Блог компании альфа-банк , Figma , Удалёнка , Atlassian , Dropbox

Нейросетевой подход к моделированию карточных транзакций

19.04.2021 14:06:47 | Автор: admin

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

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

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

Описание данных

Участникам соревнования был предоставлен датасет по 1.5 миллионам выдач кредитных продуктов. К каждому объекту выборки было подтянуто признаковое описание в виде истории клиентских транзакций глубиной в год. Дополнительно был представлен тип выданного продукта. Обучающая выборка состоит из выдач за период в N дней, тестовая выборка содержит выдачи за последующий период в K дней. Всего в датасете содержалось 450 миллионов транзакций, объемом порядка 6 гигабайт в формате parquet. Понимая, что такой объем данных может стать серьезным порогом для входа, мы разбили датасет на 120 файлов и реализовали методы пакетной предобработки данных, что позволило решать задачу соревнования с личного ноутбука.

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

Признаки карточных транзакций

название признака

описание

Кол-во уникальных значений

currency

Идентификатор валюты транзакции

11

operation_kind

Идентификатор типа транзакции

7

card_type

Уникальный идентификатор типа карты

175

operation_type

Идентификатор типа операции по пластиковой карте

22

operation_type_group

Идентификатор группы карточных операций, например, дебетовая карта или кредитная карта

4

ecommerce_flag

Признак электронной коммерции

3

payment_system

Идентификатор типа платежной системы

7

income_flag

Признак списания/внесения денежных средств на карту

3

mcc

Уникальный идентификатор типа торговой точки

108

country

Идентификатор страны транзакции

24

city

Идентификатор города транзакции

163

mcc_category

Идентификатор категории магазина транзакции

28

day_of_week

День недели, когда транзакция была совершена

7

hour

Час, когда транзакция была совершена

24

days_before

Количество дней до даты выдачи кредита

23

weekofyear

Номер недели в году, когда транзакция была совершена

53

hour_diff

Количество часов с момента прошлой транзакции для данного клиента

10

amnt

Нормированная сумма транзакции. 0.0 - соответствует пропускам

inf

Целевой переменной в соревновании была бинарная величина, соответствующая флагу дефолта по кредитному продукту. Метрикой для оценки качества решений была выбрана AUC ROC.

Базовый подход к решению задачи

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

В случае категориальных признаков можно использовать счетчики вхождений каждого значения каждой категориальной переменной или пойти дальше и использовать вектора из матричных разложений или основанных на них методах: LDA, BigARTM. Последний из которых позволяет получить векторное представление сразу для всех категориальных признаков за счет поддержи мультимодальности. Признаки можно отобрать на основе важности, полученной популярным методом permutaion importance или менее популярным target permutation. С базовым подходом, приносящим 0.752 AUC ROC на public LB, можно ознакомиться на git.

Архитектура нейронной сети

Решать задачу классификации многомерных временных рядов можно методами, используемыми в классификации текстов, если мысленно заменить каждое слово текста набором категориальных признаков. В области обработки естественного языка принято ставить каждому слову в соответствие числовой вектор, размерности сильно меньше, чем размера словаря. Обычно вектора слов предобучают на огромном корпусе текстовых документов методами обучения без учителя: word2vec, FastText, BERT, GPT-3. Основной мотивацией предобучения являются огромное количество параметров, которое нужно выучить в виду большого размера словаря и обычно небольшого размеченного датасета для решения прикладной задачи. В данной задаче ситуация обратная: менее 200 уникальных значений для каждой категориальной переменной и большой размеченный датасет.

Резюмируя вышесказанное, векторного представление для каждого категориального признака можно получить, используя стандартный Embedding Layer, работающий по следующему алгоритму: в начале задается желаемый размер векторного представления, затем инициализируется LookUp матрица из некоторого распределения, далее ее веса учатся вместе с остальной сетью методом backpropagation. Размер эмбеддинга обычно выбирается равным или меньше половины числа уникальных значений категориального признака. Любой вещественный признак можно перевести в категориальный операцией бинаризации. Вектор для каждой транзакции получается из конкатенации эмбеддингов, соответствующих значениям ее категориальных признаков.

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

Обучение нейронной сети

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

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

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

Допустим, ваша сеть одновременно учится быстро и не переобучается. Предлагаем проверить, что вы используете все идеи из следующего списка, для получения наилучшего качества:

  1. Cyclical Learning Rate благодаря стратегии изменения LR позволяет не переобучаться на первой эпохе за счет низкого базового LR и не застревать в локальных минимумах за счет пилообразной-затухающей стратегии. Гиперпараметры base_lr и max_lr можно задать при помощи алгоритма LRFinder. Дополнительно стоит обратить внимание на One Cycle Policy и Super-Convergence.

  2. Макроэкономические показатели и платежное поведение клиентов могут измениться за N дней, за которые собрана обучающая выборка, относительно последующих K дней, отведенных для теста. В качестве простой стратегии моделирования смещения по времени можно использовать экспоненциальное затухание для весов объектов в зависимости от времени.

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

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

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

Продакшн

Транзакции в hadoop обновляются раз в день, поэтому online-обработка не требуется, в худшем случае нужно успевать прогонять pipeline за 24 часа. Pipeline реализован в виде DAG на airflow, состоящем из следующих этапов:

  1. Дозагрузка и агрегация новых данных на pyspasrk. В модели используется история транзакции по каждому пользователю за предыдущий год. Оптимальным сценарием является поддержание исторических предобработанных данных на момент предыдущего запуска модели с добавлением новых данных. На выходе: относительно-компактный parquet-датафрейм.

  2. Предсказание на python с использованием одного из фреймворка: tensorfow, pytorch. На выходе: tsv-таблица, содержащая id и множество полей с предсказаниями моделей.

  3. Выгрузка предсказаний в hadoop и на вход финальной модели.

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

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

Полезные ссылки и материалы

smirnovevgeny/AlfaBattle2.0
github.com
aizakharov94/AlfaBattle_task2
github.com
Подробнее..
Категории: Хакатоны , Машинное обучение , Big data , Нейросети , Data engineering , Nlp , Блог компании альфа-банк , Альфа-банк , Alfa battle , Карточные транзакции

Перевод Утерянная, но не забытая история 3Dfx Interactive

02.10.2020 12:06:25 | Автор: admin
В Альфе любят киберспорт, наши команды участвуют в чемпионатах по StarCraft II, LoL, Hearthstone, FIFA 20, CS:GO и другим играм. Предлагаем вам в эту пятницу вспомнить историю компании 3Dfx, которая вложила существенный вклад в графику для ПК.



Компания 3Dfx, основанная в Сан-Хосе (Калифорния) в 1994 году тремя бывшими сотрудниками Silicon Graphics, начала с разработки оборудования для аркадных автоматов. Чипсет Voodoo первого поколения использовался в таких хитовых автоматах, как San Francisco Rush, ICE Home Run Derby и Wayne Gretzkys 3D Hockey. Но к ко второй половине 1996 года значительно снизились цены на память, заставив 3Dfx обратить своё внимание на потребительский рынок PC.

Графическое оборудование 3Dfx Voodoo состояло из дополнительной карты, выполнявшей только 3D-вычисления. Карте был необходим VGA-кабель, передававший данные с отдельной 2D-карты на Voodoo, которая затем подключалась к дисплею. Эти карты продавались множеством компаний. Orchid Technologies первой выпустила на рынок Orchid Righteous 3D за 299 долларов, это устройство было примечательным своими механическими реле, которые щёлкали при работе чипсета. За этой картой последовали Diamond Multimedia Monster 3D, Canopus Pure3D, Colormaster Voodoomania, Quantum3D Obsidian, Miro Hiscore, Skywell Magic3D и другие продукты.

Voodoo Graphics совершила революцию в графике для персональных компьютеров, почти за одно мгновение превратив множество продуктов в устаревшие, в том числе и огромный ассортимент карт только для 2D. Рынок 3D-оборудования в 1996 году благоприятствовал компании S3, занявшей примерно 50% рынка. Однако вскоре ситуация должна была измениться. По оценкам, на пике популярности Voodoo 80-85% рынка 3D-ускорителей владела компания 3Dfx.



Со временем основными конкурентами 3Dfx стали компании, уже выпускавшие на рынок оборудование для 2D-графики и намеревавшиеся создавать комбинированные карты, способные отображать 2D и 3D. Хоть эти продукты не дотягивали до качества изображения и производительности Voodoo, их дешевизна и простота использования привлекли многих OEM-производителей. Спрос был создан, а интерес у покупателей уже возник.

В то же время 3Dfx находилась в уникальном положении она не изготавливала графические карты сама, а продавала чипсеты сторонним OEM, производившим карты под своим брендом. Компания считала, что это проблема, и она попытается решить её в будущем, однако подробнее мы расскажем об этом ниже.

Свой ответ на выпуск комбинированных карт 3Dfx подготовила годом спустя, создав Voodoo Rush, объединившую на одной плате ускоритель Voodoo с чипом 2D-графики. Rush имела те же параметры, что и Voodoo, но из-за того, что ей приходилось делить шину с 2D-чипом, страдала производительность. 3Dfx пыталась решить эту проблему в новых версиях карты, добавив в них больше памяти и увеличив тактовые частоты, но попытка оказалась неудачной. Менее года спустя выпуск линейки Voodoo Rush был завершён.

Пиком относительно недолгой жизни 3Dfx стал 1998 год, как раз когда с ней пересеклась моя личная история. Тогда была выпущена очень успешная Voodoo2. Она изготавливалась по 350-нанометровому техпроцессу, получила более быстрое ядро и тактовую скорость памяти (90 МГц, Voodoo первого поколения имела 50 МГц). С ней не могла конкурировать ни одна другая карта, не говоря уже о тех случаях, когда в играх применяли проприетарный Glide API (в то время Direct3D и OpenGL ещё не рассматривались в качестве стандарта).



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

Многие считают чипсеты Voodoo и Voodoo2 причиной зарождения компьютерного 3D-гейминга. Кое-кто рассматривает то время как золотой век PC-игр, в который появились такие проекты, как Quake, Quake 2, Need for Speed II: SE, Virtua Fighter 2, Resident Evil, Tomb Raider, Diablo II, Unreal и Rainbow Six. Все они эффективно использовали возможности Glide API.

Как красноречиво сказал Шеймус Янг, это было после каменного века DOS, но до появления четырёх всадников Апокалипсиса: багов, DRM, фиксированных графических режимов и консолизации игр, породивших настоящий хаос. Чтобы лучше погрузиться в эту тему, прочитайте нашу статью о лучших играх с 3Dfx Glide.



Также Voodoo2 был примечателен тем, что в нём появился SLI (Scan-Line Interleave) процесс, при котором две карты Voodoo 2 можно было подключить друг к другу, чтобы они работали одновременно и, теоретически, удваивали производительность обработки графики. SLI позволял использовать более высокие разрешения, до 1024 x 768, но проблемы с совместимостью и высокая цена, связанная с необходимостью покупки двух мощных карт, оставили эту функцию уделом фанатов и хардкорных геймеров.

Спустя много лет SLI получил второй шанс благодаря Nvidia. Теперь он известен под названием Scalable Link Interface, но идея в основе современной реализации осталась такой же, несмотря на то, что её технологии сильно отличаются от реализованных компанией 3Dfx.


Документальный фильм о 3Dfx Interactive 1997 года. В этом видео показаны первые успехи компании непосредственно перед выпуском очень успешной карты Voodoo2

" мы провели тесты с очень популярной игрой GL Quake, и оказалось, что она работает с частотой 120 кадров в секунду, что попросту глупо: никто не будет стремиться запускать игру с таким количеством кадров; однако это демонстрирует потенциал, доступный для разработчиков"

3Dfx вернулась к идее карты с комбинированным 2D/3D, реализованным в Voodoo Banshee, и даже попробовала предложить свою архитектуру для игровой консоли Sega Dreamcast, но в результате от неё отказались в пользу чипсета NEC. С тех пор дела компании пошли под уклон: 3Dfx решила приобрести за 141 миллион долларов производителя видеокарт STB Systems, стремясь изготавливать собственные видеокарты, а не служить OEM-поставщиком.

В сырой 3D-производительности Voodoo 2 не было равных, но конкуренция быстро нарастала. Давление со стороны ATI и Nvidia продолжало увеличиваться, и 3Dfx решила повысить свои прибыли, продавая платы самостоятельно, а не отдавать, как ранее, эту работу длинному списку партнёров. В этом смысле приобретение STB имело смысл, но это мероприятие оказалось огромным просчётом, потому что используемая компанией фабрика не могла конкурировать по качеству и стоимости изготовления с TSMC (производившей платы для Nvidia) и UMC (работавшей с ATI).

Многие из бывших партнёров 3Dfx наладили связи с Nvidia.



Первые карты серии 3Dfx Voodoo3 появились в 1999 году при поддержке массовой телевизионной и печатной рекламной кампании, новым логотипом (теперь со строчной d) и ярким дизайном коробок. Voodoo3 и следующие продукты компании перестали быть доступными партнёрам-производителям, что фактически превратило их в конкурентов, не имеющих иного выбора, кроме как покупать чипсеты у других компаний, например, у Nvidia.

На рынке появились различные модели с чипсетом 3Dfx Voodoo3, рассчитанные на несколько ценовых ниш. Летом того же года Nvidia нанесла ответный удар, выпустив GeForce 256, позиционировавшийся как первый в мире GPU (graphics processing unit).

Революция, которую за три года до этого начала 3Dfx, теперь оставляла её за бортом.



Последней попыткой 3Dfx стал графический процессор VSA-100, который должен был превратиться в фундамент следующего поколения карт компании. На рынок удалось вывести только две из них, Voodoo 4 4500 и Voodoo 5 5500.

Когда-то название 3dfx было синонимом сырой производительности, а теперь главной сильной стороной компании стало качество изображения с полноэкранным сглаживанием. В Voodoo 5 появилась технология T-buffer как альтернатива возможностям GeForce 256 по T&L (transformation and lighting): по сути, она брала несколько отрендеренных кадров и объединяла их в одно изображение. Так создавалась немного размытая картинка, которая при воспроизведении последовательности кадров сглаживала движение анимации.

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



Voodoo5 5000, которая должна была стать версией 5500 с уменьшенным в два раза объёмом ОЗУ, так и не выпустили. То же самое произошло и с Voodoo 5 6000, мощной картой с четырьмя процессорами VSA-100 и 128 МБ памяти. 3Dfx изготовила около тысячи прототипов для тестирования, но ни одна карта снова не была продана. Некоторые из этих легендарных предпроизводственных карт выжили, однако сегодня известно лишь о нескольких рабочих образцах. Они считаются одними из святых граалей игрового оборудования. Если вы найдёте желающего расстаться с такой картой, то будьте готовы заплатить несколько тысяч долларов.

В марте 2000 года 3Dfx решилась на покупку за 186 миллионов долларов владельца графических технологий GigaPixel, надеясь ускорить выпуск своей продукции, но оказалось, что уже слишком поздно.

Вскоре после выпуска на рынок в том же году первых моделей Voodoo4 кредиторы 3Dfx инициировали процедуру банкротства. Не имея особого выбора, в декабре 2000 года 3Dfx выбросила белый флаг и продала большинство своих активов Nvidia. Почти 13 лет спустя основатели 3Dfx записали интервью об истории компании для Музея компьютерной истории.

Если вы любитель ретро-гейминга, то подержанные карты на основе Voodoo по-прежнему можно приобрести в Интернете, например, на eBay. Они чуть дороже, чем можно было бы предположить (ностальгия стоит денег), но доступны любому.

Личные воспоминания


В выпуске журнала GamePro за декабрь 1995 года опубликовали статью о DigiPen ванкуверском колледже, обучающем программированию видеоигр. Новости об этом колледже прикладной компьютерной графики оказались как нельзя кстати мой преподаватель информатики только что дал нам задание, касающееся работы нашей мечты и того, как она могла быть связана с технологиями. Я сразу же понял, в чём моё предназначение.

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

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


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

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

Первый компьютер у меня появился в 1998 году, и это в буквальном смысле изменило всю мою судьбу. Я по-прежнему был увлечён играми, но моё внимание мгновенно переключилось с консолей на PC, и мне не потребовалось много времени, чтобы осознать, что моему процессору AMD K6-2 CPU с набором инструкций 3DNow! требуется помощь по графической части.

Так я узнал о 3Dfx Interactive.
Подробнее..
Категории: Старое железо , История it , Игры и игровые приставки , Игры , Блог компании альфа-банк , Видеокарты , 3dfx , Voodoo , 3dfx voodoo , Vga , Orchid technologies

Июньские заметки о виртуальной реальности. Часть 2

04.06.2021 16:20:58 | Автор: admin
Продолжение, первая часть тут

А что кроме игр?


Прежде всего я сфокусирован на играх, но для меня мой шлем должен стать ещё и персональным кинотеатром у меня трое детей, и редко когда получается уединиться, чтобы посмотреть ужасы, например. Я ещё не смотрел кино в VR, но огромное окно в YouTube мне нравится. Тем более, сейчас есть приложения, которые позволяют смотреть кино в VR вместе с друзьями, в одном пространстве.

Мне также интересен Virtual Desktop у меня появится доступ к стационарному компьютеру, прямо с дивана. Это не сильно изменит мою работу на удалёнке, так как удалённый рабочий стол не готов к VR. У меня всё так же будет одно окно терминала я не смогу в VR расположить почту справа, а ssh в левой части.

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

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


Вот тут больше разных впечатляющих видео с софтом для рисования.

Порно, кино для взрослых


Кино для взрослых в VR тоже довольно интересная тема как для одиноких людей, так и для пар. Я думаю что у таких видео должен появиться API, который будет управлять вибраторами/мастурбаторами. Либо такие видео будет размечать нейросеть, чтобы изменять режимы стимуляции и их интенсивность.

Что касается пар это может быть довольно интересным опытом. В шлеме ты смотришь взрослое видео, а в реальности занимаешься сексом с женой, которая повторяет действия женщины из видео. Если пойти дальше, то взрослое видео может быть снято с двух точек (со стороны мужчины и женщины) и тогда уже два человека могут заниматься сексом в шлемах.

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

Я полагаю, что реальности это может пойти только на пользу. Но пока нет ответа сможет ли, например, педофил или зоофил заниматься сексом с женой/мастурбатором в реальности, в то время как в виртуальности он будет заниматься сексом со свиньей или несовершеннолетней? Достаточно ли ему того будет? Или богатые возможности виртуала смогут толкнуть на эту дорожку даже тех, кто в эту сторону и не смотрел? Или вообще побудит к осуществлению запретных фантазий в реальной жизни? Возможна ли терапия для педофилов, если каждый раз при виртуальном сексе очень постепенно и незаметно заменять части тела vr-куклы на более взрослые? А что, если это делать в сочетании с психоделической терапией, которая, судя по всему, даёт возможность перепрограммирования?

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

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

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

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

Феномены погружения


Когда я играл в Rust 5-8 лет назад я понял, насколько мир может стать живее в случае если игрок начинает молить о пощаде (или угрожать) голосом, а не в чате. Но в полную силу это раскрылось в игре MMO шутере Will to Live.

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


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

Виртуальная реальность добавляет новое измерение, которое делает игровой опыт реальнее. Она добавляет нам руки, которыми мы можем взаимодействовать с виртуальным миром и с другими игроками. И это даёт куда больший эффект, чем, возможно, мы можем себе представить. Также мы можем осматриваться и даже передвигаться естественным образом. Мы полностью сосредоточены на игровом мире, т.к мир не заканчивается за рамками монитора.

Игрок в VR слишком сильно отличается от управляемого компьютером персонажа и именно поэтому в Pavlov VR и других играх люди могут вести себя странно и несообразно игре. Они системно игнорируют игровые правила, по которым они должны просто стрелять друг в друга. Я посмотрел достаточно материала, чтобы это заметить и этот эффект отмечают сами игроки.


У меня есть впечатление, что игроки в VR более дружелюбны, чем эти же игроки, но в плоских играх.

Когда мир перестал быть плоским и появилось больше механизмов для взаимодействия с ним, это стало генератором для самых разных забавных ситуаций. Например, когда один игрок со стола успевает схватить пистолет без патронов, а второй игрок обойму. Благодаря тому, что в игре видно, что в руках у другого персонажа, это становится сразу очевидно. Игроки естественным образом (т.е, даже не нажимая клавишу Push to talk) на это реагируют и смеются.

Эффекты, о которых я говорю так же заметны в игре Echo Arena:


*Кстати, очень понравилось, как в Echo Arena сделаны удары по игрокам. Эти удары субъективно хорошо ощущаются, даже если просто смотришь видео этой игры.

Игроки в игре Echo Arena дружелюбны. Мне кажется, что корень этого явления в том, что люди в игре легко позволяют другим людям заходить в их личное пространство и прикасаться в себе (потому что VR это безопасно и не чувствуется как угроза) и это здорово повышает уровень доверия между игроками.

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

Именно поэтому моё отношение к жилетам обратной связи*, которые позволяют почувствовать прикосновение или удар, или ощутить звук выстрела телом, далеко от скептического. Я думаю, что мы пока слабо осознаем, насколько он реально может влиять на наше восприятие и погружение. Мы можем только сказать, как жилет реагирует на те или иные игровые события.

Демонстрация жилета:


Есть и более сдержанные отзывы, в том числе на русском. К слову, Tacticsuit на 40 точек прикосновения стоит 500$. Это стоимость жилета, но есть крепления для рук, ног и даже головы. Наверное, может быть полезно использовать его в шутере, чтобы понять, откуда тебе прилетело.

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

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

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

Мне также очень интересно возможно ли в haptic vest проводить телесную психотерапию? Или это не сработает?

Спортивный аспект игр


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

Вот видео, где VR бокс пробуют профессиональные боксеры:


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

Для VR фитнеса уже начали продавать интересные железки Icarus.







Выглядит интересно, но стоит от 2000 до 9000 евро за ПРО версию. Для мышц пресса штука классная и, как мне кажется, это не такая уж большая цена для большого спортзала. Тем более, что в нём есть игры с мультиплеером и соревновательный элемент.

Есть стартапы велосипедов с возможностью подключения VR, но, как по мне, так это тупиковый путь. А вот устройство к акселерометром, которое можно было бы использовать на любом вело-тренажёре, могло бы взлететь.

Поэтому я даже написал письмо в поддержку DecaMove (проект, о котором я расскажу ниже).

Good day! I really like your startup DecaMove and I even ordered it myself.
But it seems to me that you have not noticed the potential of this device in vr sports. Please note that exercise bikes connected to virtual reality are now being sold. I think that they are too expensive, and secondly a lot of people already have exercise bikes or treadmills that just stand somewhere in the corner and are not used.
I think it's easy enough to position your device as a sports device. You simply connect the decamove to your leg, record the acceleration determine the potential speed at which the person is pedaling. Faster you pedal, the faster your car/bike/horse goes in the vr game.
I think you need to release a video showing this application of your device.
I also really like your device DecaGear, it will be cool if a device with such functionality comes out for such a price and I wish you the best of luck with this cool project.

Цена велосипедов с играми для VR:
Holodia VR 400$
VirZoom 400$

DecaMove



Как обычно происходит свободное передвижение в VR? Куда смотришь в шлеме туда и двигаешься, зажав контроллер. DecaMove, небольшое и не сильно дорогое устройство, которое вешается на пояс позволяет передвигаться более естественно. Вы сможете смотреть в одну сторону, а передвигаться другую. Я думаю, что это одна из самых важных вещей для VR если вы используете его для игр оно позволяет передвигаться относительно естественным образом.

Небольшой обзор:


Развернутый обзор:


Заказать можно здесь, с доставкой он обошелся мне в 5700р.

Но покупать DecaMove вовсе не обязательно! Ведь вместо него можно использовать обычный смартфон+приложение, если в нём есть акселерометр и компас:


В третьей части поговорим о позиционировании, трекинге, Full body tracking, существующих решениях и ценах на них, и о многом другом.
Подробнее..
Категории: Ar и vr , Будущее здесь , Игры и игровые приставки , Игры , Блог компании альфа-банк , Vr , Разработка под ar и vr , Виртуальная реальность , Decamove

Июньские заметки о виртуальной реальности. Часть 3

11.06.2021 16:11:37 | Автор: admin
Часть 1
Часть 2

Позиционирование, трэкинг. Full body tracking. Решения и цены


Основное, что нужно знать.

Всё, что вы можете получить, используя Oculus Go, Google Dream, Samsung Gear или мобильный телефон вложенный в шлем это 3DoF, вращение головой. То есть вы не сможете перемещаться в пространстве, двигаясь вперед, в шлеме вроде Oculus Go. У полноценных шлемов типа HTC или Quest 2 куда больше степеней свободы:



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

Подробнее о принципах FBT можно почитать в этих статьях: раз, два.

Чем хорош и интересен Full Body Tracking?


Лично меня он заинтересовал после просмотра видео, где блогер использует пинки в игре Blade and Sourcery:


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

Vive trackers + LightHouse


Довольно дорогое удовольствие. Один vive tracker стоит от 10 до 17 тысяч рублей в зависимости от версии. Третий релиз трекеров легче и работают они значительно дольше. Базовая станция 2.0 обойдётся в 25 тысяч рублей, б/у станцию 1.0 можно купить за 8-12 тысяч рублей. Советуют использовать не менее 3-х трекеров.

Датчики обратно-совместимы. Можно использовать трекеры 3.0 с базовыми станциями 1.0 и 2.0. Непонятно, с какой частотой они обновляются (отслеживаются). Но вот тут есть обсуждение этого вопроса.

Базовые станции первых и вторых версий отличаются довольно сильно:

sdvuh, IXBT:
Главное, пожалуй, что БС 2 поколения могут работать до 4 штук вместе и обеспечивать трекинг до 10*10 метров, а первого только 4*4 на 2 штуках. Но для обычного пользователя это, имхо, малоприменимо. Ну и точность трекинга выше, типа не 1 мм, а 0,1 мм, тоже не слишком важно)

Whisper, IXBT:
1. 2 бски могут стоять друг от друга по диагонали на 10 метров против 5 метров у первых
2. Заявляли большую точность по сравнению с первыми станциями. В целом мне и первых БСок тут хватает при стрельбе из снайперки на большое расстояние в Pavlov этого достаточно.
3. Поддержка до 4-х БСок для одной зоны (вот тут точно не помню уже, может и больше). Первые только 2 б-ски поддерживают.
4. Ещё заявляли, что меньше движущихся частей и из-за этого выше надежность. Но тут у меня сомнения, так как много слышал про поломки вторых БС-ок и очень мало про первые.

Senso Suit

Преордер костюма с 15 трекерами, в каждом из которых вибромотор для обратной связи + базовая станция), обойдется в 600$. На русских порталах продают за 200 000.




Senso известна также своими перчатками Senso Gloves DK3 1000$ за комплект.

Tundra tracker

На кикстартере появился Tundra tracking с более демократичными ценами, прямой конкурент HTC.

Комплекты уже включают в себя базовую станцию для отслеживания трекеров:

3 трекера 300$, 22 500р
5 трекеров 456$, 34 200р
7 трекеров 630$, 47 250р

SlimeVR Full Body Tracker Crowdfunding Pre-Launch

Также готовится к выходу SlimeVR, комплект из 5 датчиков за 140$. Про него можно сказать только то, что частота обновления будет 100 герц, и они могут работать без подзарядки до 15 часов.


Cookie-Body Tracking DK1 180

Главная цель проекта сделать FBT как можно более дешевым.
Работает в 120 герц, 1 cm precision, 85x55 FOV, 3m range. Обещают отдать комплект за 600 SEK (5400 руб).
Преордер обещают на Kickstarter к концу апреля.
Латенси в районе 3-5мс и трекеры не требуют батареек.

Судя по всему, это трекинг при помощи распознавания маркеров (?). В Driver4VR, например, недавно появился такой режим.

Может быть, CookieBody будет работать лучше/быстрее, чем Driver4VR?

Демонстрация.


Shockwave-костюм

Костюм из спандекса за 265$ c 12 IMU-трекерами и 64 точками для имитации прикосновения (ну или для ощущений от взрыва гранат) при помощи вибромоторов.
Первые, кто вложился в проект, могли заказать за 195$.

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



Костюм нативно поддерживает SteamVR, может использоваться через Driver4VR. Указано, что поддерживает следующие игры: The Age of Monsters, Sci-WAR: 2220 и Ghost Assassin VR, VR Chat, Skyrim VR, Fallout 4, Alyx.

К сожалению, не нашёл частоту обновления. Если вас заинтересует костюм поищите у них в дискорде или в комментах на кикстартере.

Почему так дёшево? Думаю, основная причина в том, что Shockwave не использует внешний трекинг, а использует IMU (Инерционно измерительный блок) то есть акселерометры. Такой вид трекинга можно назвать инерционным.

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

Самый доступный трекинг для VR

Driver4vr позволяет использовать Kinect (1500р с авито) или PS Eye для полного трекинга тела.



Кроме того, при помощи Driver4vr можно использовать и обычные вёб-камеры + маркеры из кубиков, прикреплённые к телу.

Нативно Driver4vr не поддерживает несколько кинект-камер, а ведь именно это приходит сразу в голову. Однако это не фантастика:


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

Что именно выбрать, зависит от размеров вашего кошелька. Один Kinect справляется с трекингом хуже, чем две базовых станции HTC. Но и стоимость HTC больше чуть ли не в 10 раз.

Вот здесь попытались сравнить качество трекинга Kinect/HTC:

Отмечу также, что на форумах писали, что Kinect+Driver 4VR потребляет довольно много CPU, так что непонятно, потянет ли компьютер сразу два кинекта.
*Driver 4VR не поддерживает 2 кинекта, но на ютубе можно найти демонстрацию, где задействовано несколько кинектов.

Системы перемещения в VR


Virtux Omni



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

10 500$ платформа, два пояса, 4 пары обуви.
13 000$ платформа, датчики, два пояса и 8 пар обуви.

Пока проходим мимо.

ROVR



Гораздо более демократичные цены, чем у Omni ROVR1 обойдётся в 700 евро.

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

Cyberith Virtualizer



600-1000$ в зависимости от комплекта.


Kat Walk



Первое, что хочется узнать про платформу для VR это цена. У KAT WALK C она не то чтобы совсем неподьёмная 1499$ (164 т.р)

Про Kat Walk на Pikabu я увидел следующий отзыв:
1) В комплекте идут резиновые накладки на ноги разных размеров с пластиковыми (скорее всего) шайбами на подошвах. Резина рвётся, шайбы царапают поверхность.
2) Делая большой шаг (а в очках естественно вы не видите края платформы ) будут постоянные зацепы за этот край. Это бесит
3) Нельзя поиграть в любую игру которую захочешь. Надо чтобы игра была оптимизирована их разработчиками. Список таких игр на прошлый год был весьма скромный. В их магазине есть и простенькие игры с уровнем графики относительно современных мобильных телефонов, НО! бесплатных там всего пару штук. За все остальные надо платить, при чём ты не можешь купить эту игру. Ты покупаешь время, которое проведёшь в игре. И цены по лично моим меркам дурные.
4) После каждого перезапуска надо делать калибровку, чтобы при физическом передвижении вперёд персонаж не двигался назад. Калибровка иногда дико выпендривается и надо ковырять вручную ПО, чтобы прописывать положение пояса.
5) Сам пояс в плане комплекции игрока вообще не универсальный, как по обхвату талии, так и по высоте человека.
6) Херовы датчики 6 если быть точнее. Один ресивер получает данные с двух датчиков ног и ещё один получает данные с металлической оси, на которой висит пояс + датчик позади пояса в области поясницы. Далеко не всегда вся эта песня хочет синхронизироваться друг с другом.
7) Опять же, не знаю как сейчас, но мы покупали две установки, которые комплектуются терминалом, похожим на тот, в котором пополняется мобильный счёт и оплачиваются всякие гос.услуги. Большая тяжелая е**ла с отвратительной антивандальной клавиатурой, которой невозможно пользоваться.
8) Поверхность чаши покрыта несколькими трапециевидными листами то ли пластика, то ли тонкого металла. И не дай б**ь боже начнутся задираться уголки этого материала (а они априори начнут). Всё, пиз**ц. Плюс эту поверхность надо постоянно смазываться перед игрой какой-то силиконовой полиролью.
9) Ох сколько раз в кураже мы бились руками и геимпадами о металлическую трубу, которая идёт от платформы вверх и держит всю конструкцию
Не знаю где вы нашли их за $1500, мы покупали примерно за 120000 грн каждую + растаможка и доставка обошлась примерно столь же

Kat Loco



Гораздо интереснее и доступнее выглядит Kat loco. Комплект состоит из трёх трекеров, которые крепятся на ногах и поясе и позволяют перемещаться по VR вполне естественно. Однозначно не у всех найдется место дома, куда можно поставить большую платформу типа KAT Walk C, поэтому Kat Loco вариант. Более подробно о нём напишу чуть ниже.


Цена вопроса 230$

Впечатления по Kat Loco от Ивана Ивко (IXBT):


Кто не в курсе, это набор датчиков из 3 штук, на пояс и лодыжки, которые позволяют двигаться в играх за счет перемещения ног. Это шагание на месте и некоторые другие опции. Kat Loco помогают освободить руки а так же использовать датчики для захвата движений.

Сразу предупрежу, я тестил часа 2, и в игре из этого времени был минут 15, т.е. это скорее впечатления от процесса настройки, чем от игрового процесса.

1) Базовая настройка и подключение. В целом, все достаточно просто и по инструкции, но было 2 момента, на которые я убил основное время, это Kat gateway (утилита управления) должна стартовать от имени администратора, иначе она не может взаимодействовать со SteamVR (считывать положение шлема, эмулировать контроль, встраиваться в оверлей). Это, в принципе, в FAQ на сайте описано (на 4 странице, ага), но не очевидно и без привязки к главным симптомам (только к части), как будто это редкая ситуация.

При этом сама утилита никак не сообщает, что у нее какие-то проблемы взаимодействия, просто не делает то, что должна. Минут 20 убил на эксперименты и переустановки.

Датчики беспроводные, но для связи с компьютером и отслеживания в пространстве используется собственная базовая станция, поэтому требуется калибровка при первой установке и смене места игры (кстати, в инструкции указано, что отслеживание гарантируется при расстоянии до базовой станции от 1 до 2 метров, 1,5 оптимально).

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

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

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

Вероятно, крепить надо на ремень или т.п., чтобы жестко держалось, позже это проверю.

2) Возможности

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

Даже когда датчик шагов срабатывал, была явная задержка между началом шагов и началом движения в игре, по ощущениям что то типа 0,5 1 секунды. Насчет быстроты остановки не скажу. Замечал при движении рывки (т.е. шагаю, двигаюсь вперед, остановился, снова начал двигаться, хотя я не прекращал шагать). Мб это было связано как раз с неправильным шаганием.

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

Про возможность бега не скажу. Заявлено, что чтобы бежать в игре, надо шагать еще чаще, но у меня пока и с просто перемещением проблемы)). Буду дальше тестировать.

  • Привязка направления перемещения. По умолчанию привязано к направлению шлема, однако есть опция независимого осмотра. Т.е. можно идти куда-то и при этом вертеть головой по сторонам, смотреть в другую сторону. Фича работает.
  • Режим бокового перемещения (опция). Отставляешь ногу вбок, движется вбок. (есть еще какой-то альтернативный режим с поворотом лодыжки но я его пока не вкурил)
  • Режим Движения назад (опция). Отставляешь ногу назад, движется назад.
  • Режим Круиза (опция). Выставляешь ногу вперед, движется вперед.

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

Минусы

  • То, что я писал выше про необходимость калибровки направления. Выставляешь вперед левую ногу, движешься вперед. Чуть покрутишься, выставляешь правую начинаешь двигаться не вперед, а вперед и вбок.
  • (главный на мой взгляд минус) движение в этих трех режимах дискретное. Т.е. Вперед назад влево вправо. Нельзя держа ногу впереди сдвинуть ее правее и начать двигаться вперед вправо все равно будешь двигаться вперед. Только когда совсем вправо ногу сдвинешь, начнешь двигаться уже только вправо. Написал по этому поводу разрабам, чтобы сделали непрерывную (а не дискретную) смену движения в зависимости от положения ног (что, ИМХО, логично), мб пофиксят. Это бы решило и первую проблему (калибровки), т.е. движешься чуть не туда ну сдвинул ногу вбок и норм.

3) Поддержка в играх, возможность конфигурирования

Система, по сути, эмулирует нажатие определенных кнопок с контроллеров. Т.е. указываешь в профиле для игры, какой джойстик используется для локомоции и какая кнопка за это отвечает и вперед. ОФициальный список поддерживаемых (т.е. для которых профили протестировали) игр довольно велик, порядка 100 штук. Но наблюдаются несостыковки, к примеру, в No Man's Sky у меня перемещение не работало, а потом я понял, что это потому, что профиль сделан под раскладку вайв махалок (т.е. движение по нажатию курка), а у меня индекс контроллеры (движение по стику). Но кастомные профили как для существующих, так и для отсутствующих игр создаются очень легко, так что это не проблема. Т.е. я бы сказал что проблем совместимости быть не должно,

Еще интересно, что нет выбора кнопки для бега, хотя возможность перехода на бег заявлена (и даже можно указать для игры, зависит ли скорость перемещения от скорости шага или же сразу максимальная). Просто в той же NMS на индексе это не банальное нажатие на левый стик, а нажатие при беге на правый стик.

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

Погонял еще Kat Loco.
Пока 10 часов не наиграл, так что не буду спешить с впечатлениями.

Кратко

1) Если шагать как в рекламном ролике (т.е. часто и мелко, а не редко и высоко) отслеживает хорошо, можно ходить без рывков.

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

3) Как работает отвязка от направления контроллеров/шлема.
Судя по всему, кат считывает положение тела и (в зависимости от настроек) шлема и контроллеров. Далее если выставлена настройка отвязать перемещение от взгляда при получении сигнала движение передает команду наклон стика (условно, в зависимости от того, какой контроллер используется со шлемом), причем не вперед, а в таком направлении и под таким углом, чтобы компенсировать поворот контроллеров/шлема, и двигаться в направлении тела. Видно, если бежишь вперед и машешь контроллером влево вправо, этакие рыскания, когда Кат вносит поправки на лету.

В разных играх работает по разному, в Павлове и НМС хорошо (игра была в библиотеке от разработчика), а в ходячих работает странно ведешь контроллером правее, начинаешь двигаться слишком сильно левее и наоборот корректировки некорректно работают. Но при этом вполне нормально работает, если выставить в настройках Кат Локо привязка к HMD (в игре остается привязка к направлению контроллера). Когда идешь, если смотреть в сторону, небольшое смещение вбок добавляется, но несущественно.

WalkOVR



От 84$ за один датчик до 229$ за 5 датчиков.

Обзор:

Принцип примерно тот же, что у Kat Loco.

Сравнение Kat Loco и Walkovr:
WalkOVR


Kat Loco


На последней минуте обзора ютубер говорит, что ему больше нравится Kat Loco.

Virtusphere

Нельзя не вспомнить и про ВиртуСферу. Поставляется развлекательным паркам, скорее всего, ценник 10 000$+



Это, видимо, ранняя версия:



Infinadeck

Большая, громоздкая, дорогая всенаправленная беговая дорожка.


Real Go

Создается студентами ИТМО, выглядит недурно, но сколько будет стоить непонятно.




Устройства для игр в сидячем положении


Cybershoes



Принцип действия вы сидите на стуле (он должен уметь вращаться вокруг оси) и перебираете ногами. Цена 369$. Непонятно, почему так дорого вроде, относительно простое устройство.

3Drudder



Давишь на пятки идёшь назад, давишь носками идёшь вперёд. Чем больше наклон тем выше скорость. За 100 баксов можно купить на Amazon.

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

Оптимальным устройством для передвижения в VR кажется Kat Loco, но к нему есть ряд вопросов.


Система не имеет своего трекинга и базируется на акселерометрах. Kat Loco может срабатывать ложно, либо не срабатывать совсем.

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

Но мне кажется, для того, чтобы это устройство корректно работало на нём должен быть трекинг. Было бы неплохо, если бы софт работал вместе с внешним трекингом. Также вполне логично ожидать акселерометры сразу в трекерах, чтобы обходиться без покупки Kat Loco.

С другой стороны нужно ли будет такое управление, если мы сможем управлять движением в VR с помощью мысли? Или передвижение с помощью мыслей, а не движения ног может убить погружение? Возможно, мы так и продолжим использовать в VR наши руки и ноги, даже когда мы сможем управлять персонажем с помощью мысли.

На ютубе, кстати, есть видео Home Made VR BOOTS, в котором парень сделал примерно тот же Kat Loco. И главное, что его побудило на это тошнота при перемещении в VR при помощи обычных контроллеров:


Мне кажется логичным попробовать создать контроллеры для ног. Что-то вроде педалей, которые можно было бы использовать стоя, чтобы не терять мобильности. Большие пальцы ног, например, вполне можно использовать, чтобы нажимать на кнопки. Это может быть сделано в виде тапок/стелек с кнопкой, или в виде контроллера, который бы надевался на большой палец и был направлен кнопкой к полу. Чтобы было меньше ложных срабатываний, можно использовать даблклики.

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

На Ali есть готовы сенсоры для Arduino.

Как может выглядеть игра, которая это использует:


Тут видео с созданием одного из таких контролеров:



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

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

И ещё одна интересная самоделка для передвижения в VR:




В главе Motion Sickness можно увидеть, что есть также любопытные программно-аппаратные решения, которые решают проблему перемещения в VR.

Костюмы с обратной связью


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

Демонстрация:


Цена на Теслу, как и в случаев одноименного автомобиля, не бюджетная более 5000$

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


4*4 см/5*9 см EMS электрода колодки стимулятор нервной мышцы силиконовый гель десятки электродов цифровой акупунктурный физиотерапия десятки подушек с али-экспресса.

Весьма бюджетно, как и сам китайский прибор.

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

На тему применения электродов для обратной связи есть довольно интересные и перспективные исследования.



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


Что интересно, пока я гуглил про EMS в VR, я нашёл видео, где пытаются ускорить человеческую реакцию посредством электростимуляции:


А вот это уже интереснее:

Об этом эксперименте я узнал благодаря каналу VR Studio.

Mean Gene Hacks выложил видео, как он испытывал гальваническую стимуляцию вестибулярного аппарата малыми токами, играя в гонки:


Самое устройство было изобретено давно, он лишь его немного допилил и сделал современным.

Подробнее о самом устройстве, где есть схема сборки:


Стоимость сборки около 50 баксов.

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

Аналогичная сборка.

Тут я могу порекомендовать походить по профилям учёных, участвующих в проекте. Например по проектам, в которых участвует Pattie Maes из MIT. У него много работ по HCI (Human Computer Interaction):

Вернёмся к жилетам.

На рынке есть относительно бюджетные Tactot и TactSuit от bhaptics.

Жилеты используют вибромоторы для симуляции тактильных ощущений.

TactSuit X40 (40 вибромоторов) 499$
TactSuit X16 (16 вибромоторов) 299$
Haptic face (6 вибромоторов) 149$
Arms (6 вибромоторов для каждой руки) 249$
Hands (3 вибромотора для каждой руки) 249$
Feet (3 вибромотора для каждой ноги) 249$.

В комплекте получается совсем уже не детская цена в 1 395$, 104 т.р.



Из плюсов жилета можно отметить возможность подключения аудиокабеля. Это позволяет использовать их при просмотре фильмов вы будете чувствовать все басы.

Есть также Vest Pro Woojer с 6 точками обратной связи за 500$.

Эти жилеты используют запатентованный, мощный, полифонический и бесшумный тактильный преобразователь Osci . Я так понимаю, это что-то типа мини-сабвуферов.

Но всё, что есть сейчас на рынке, это только вершина айсберга.

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

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

Haptic gloves. Перчатки для VR с обратной связью


В целом, перчатки становятся дешевле и выбор довольно большой. 2-3 года назад я не видел перчаток дешевле 300-500 т.р, сейчас перчатки появились и в потребительском сегменте.

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

Haptic-перчатки, которые могут оказывать серьезное сопротивление (т.н силовые), пока находятся в районе профессионального сегмента их используют для работы хирургов, спасателей и обучения космонавтов. Сопротивление осуществляется при помощью магнитных тормозов или через шумный компрессор. Стоимость выше 5000 $.

Самые интересные и продвинутые модели, заслуживающие внимания, это HaptX Gloves DK2, Senseglove Nova и Teslasuit Glove.

HaptiX Gloves DK2





Sensogloves Nova



В этом видео по таймкоду видны ранние прототипы Sensogloves Nova, это довольно любопытно:


Teslasuit Glove



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

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

Давайте рассмотрим одну из таких перчаток.

Manus gloves



Это Manus Gloves за 5000 $ и вот впечатления пользователя.


А так выглядят Senso Gloves DK3 за 500$



Основа перчаток 7 IMU-датчиков и 5 вибромоторов. Считывание 150 FPS с отзывчивостью 10мс.

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

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





В целом, чтобы отслеживать движение пальцев, VR-перчатки не обязательны. Это умеют делать контроллеры HTC и Valve Index.

Есть также Etee контроллеры за 260 евро:


Есть поделки в виде трекинга рук и пальцев на основе Leap Motion


Oculus Quest 2 умеет отслеживать руки и пальцы посредством камеры. Я попробовал, и мне понравилось работает вполне сносно, думал, будет гораздо хуже.


Технологии будущего


У VR есть ещё очень много проблем и ограничителей, они только-только начали массово входить в нашу жизнь. Видеокарт нету, либо они очень дороги. Даже самые топовые видеокарты с трудом тянут разрешение 4-5k, а ведь уже есть возможность купить шлемы с 8k разрешением и 200 FOV.

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

И это всё ещё очень дорогая технология, особенно, если ты хочешь не только качественный шлем, но и полный трекинг. С OLED-экранами шлемы делать перестали и делают на LCD, у которого есть свои особенности. DPI оставляет желать лучшего. Но всё же свет в конце тоннеля виден движение и развитие есть, прогресс уже не остановить. Давайте расскажу, что может изменить VR в будущем.

CREAL

Это копипаста, к сожалению не нашёл источник:

Современные дисплеи это такие цветные плоские экраны, и они к сожалению не способны передавать свет таким же образом, как он поступает в глаза в реальной жизни. Эту проблему и пытаются разрешить швейцарские инженеры из стартапа CREAL. Ну типа See Real смотри реально.

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

Ну а пока разрешение таких дисплеев составляет 1000 х 1000 пикселей в области обзора 60 градусов.

Управление силой мысли, Brain Computer Interface.


Да, мы все ждём Neurolink, но уж сейчас у геймеров появляются первые гарнитуры, которые способны вполне сносно работать.


MindControl от Next-mind обойдётся в 400$.
Обзор на Habr.

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

В области BCI происходит примерно то же самый замкнутый круг, что был со шлемами для VR 10-15 лет назад. Пока не будет потребителей в достаточном количестве не будет и игр. Пока не будет игр не будет потребителей.

Надо отметить, что Next-mind далеко не первый стартап. Есть также Neurosky Mindwave.

О BCI и его значимости очень много говорит Гейб.

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

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

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


Подробнее о Oculus Quest 2


Заказ с Амазона

Адрес доставки указывать на английском:
Baranov Vladimir Vladimirovich
Taganskaya 12-12 (Улица, дом, квартира)
Ekaterinburg,
Sverdlovsk region (Свердловская область)
620011
Russian Federation

С вас далеко не сразу после заказа спишут деньги, и после покупки на Ali это было не привычно. У меня деньги списали через 3-5 дней.

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

Через некоторое время придет новое письмо, с требованием оплатить таможенную пошлину, которая составляет 15% от стоимости товара свыше 200$.



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

Кабель и роутер я заказал на Ali. Кабель обошелся в 1200р, роутер в 5.2т.р
(Xiaomi Redmi AX6 WiFi 6 6-ядерный 512M сетчатый домашний IoT 6 усилитель сигнала 2,4G 5 ГГц оба 2 двухдиапазонных OFDMA).

Что касается моделей роутеров, VR-комьюнити сделало вот такую табличку.

SideQuest


Игры в магазине Oculus Quest 2 очень дорогие, бесплатных вообще единицы. Включив режим разработчика и поставив SideQuest, можно поиграть в неплохие игры бесплатно или за относительно небольшую плату.

Для установки необходимо сделать несколько шагов:

1 Шаг. Аккаунт разработчика.
2 Шаг. Установка ADB драйвера.
3 Шаг. Активируем режим разработчика в Oculus app на смартфоне
4 Шаг. Качаем и устанавливаем SideQuest
5 Шаг. Коннектимся по кабелю. Разрешаем отладку по USB, надев шлем.

Подробный гайд по настройке.


SideQuest можно установить даже на телефоне, недавно появился экспериментальный режим передачи игр на гарнитуру без кабеля, через wifi.

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

Из приложений могу порекомендовать Pavlov VR Shack компьютер для игры не нужен, хотя мобильная графика шлема, конечно, гораздо слабее ПК-версии. Она сейчас где-то на уровне 2000-2003 года (Half Life-1, Halo).

В этом видео как раз рассматривают самые популярные шутеры Oculus в плане технологичности графики:


Motion Sickness


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

После игры дискомфорт остается на 30-40 минут.

После 20-30-минутной сессии игры реальность ощущается как VR. Сложно объяснить это ощущение, но я не чувствую полного слияния со своим телом. Как будто руки до сих пор виртуальные, немного чужие, и я не чувствую полную и безоговорочную связь с ними. Иногда возникает импульсивное движение взаимодействовать с реальностью так, как я бы это сделал в VR (проскролить или меню вызвать).

Про укачивание и приёмы борьбы с ним хорошо написано на ixbt.

Отдельно хочется привести пост sdvuh, как он отчаянно боролся и учился передвигаться в VR играх:
Решил написать финальный отчет по своим тренировкам smooth locomotion. Сразу предупреждаю от попытки перенять мой опыт без критики и осторожности все люди разные и что русскому хорошо, то немцу может быть смерть.
Изначально после покупки моей первой VR гарнитуры (HP reverb g2) у меня выявилась острая непереносимость smooth locomotion (хождения со стика), при первой попытке в своей первой игре (Alyx) при нажатии на стик я сразу же потерял равновесие и чуть было не упал. Попытки как то приспособиться привели к печальным последствиям я не смог в этот день продолжить игру, а мысли о продолжении подобного издевательства вызывали отвращение.

Более месяца я играл с teleport locomotion и проблем никаких не имел, но было очевидно, что большая часть VR игр для меня недоступна, что меня категорически не устраивало и я был уверен в том, что проблему буду так или иначе решать. Я надеялся, что накопление опыта в VR само по себе решит проблему, но я ошибался это так совершенно не работает, по крайней мере со мной.

13 дней назад я утвердился в своих целях, окончательно понял, что VR для меня это серьезно и что время решительных действий пришло.
Первый день тренировок был очень коротким, я начал новое прохождение Alyx, со smooth locomotion. Я смог 20 секунд походить по стартовому балкону, покрылся холодным потом, ощутил рвотные позывы и на этом решил (был вынужден) прерваться.

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

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

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

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

12-й день (вчера), был первый, когда я смог поиграть полтора часа без последствий вообще (полное прохождение Alyx со smooth locomotion я завершил), а сегодня (13-й), я себе устроил экзамен, целенаправленно пытаясь раздолбать себе вестибулярный аппарат теми средствами, которые может предложить Alyx я ходил спиной зигзагами по поверхности с перепадами высот, старался фиксировать взгляд по разным сторонам, в конце даже выставил через консоль 200% рендеринг и отправился в большую открытую и светлую (я заметил, что чем светлее, тем сильнее укачивает) локацию, которая перед Джеффом. Игра начала лагать, картинка подергиваться. Вестибулярный аппарат местами срывался, плыл, но быстро восстанавливался без каких-либо последствий для самочувствия. Считаю, что я победил. Теперь собираюсь поиграть в blade and sorcery, потом пройти medal of honor и, наконец, грозу тошнотиков boneworks.


Также пройдемся по приложениям, которые занимаются реализаций передвижений в VR. Они так же могут помочь с MS.

Natural Locomotion, которое позволяет двигаться естественно. Для движения необходимо махать контроллерами, а для прыжков прыгать:

Можно также ходить при помощи ног, используя для отслеживания массу девайсов от смартфона и Vive трекера до PS и Switch контроллеров:



Также имеется PocketStrafe, которые использует смартфон:


И Freedom Locomotion VR от Huge robot vr.

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


К сожалению, PocketStrafe и Freedom Locomotion VR заброшены.

Игра в облаке


Одна из самых перспективных вещей для автономных шлемов типа Oculus Quest 2 это игра в облаке. Будет здорово, если можно будет поиграть в PCVR из любой точки мира. Сейчас в SideQuest доступно Shadow VR, но я пока его не пробовал и есть сомнения, что мне хватит 100 Мбит от провайдера для качественной трансляции потока.

Что ещё полезного из софта для пользователя VR?

Vorpx
Позволяет играть на шлеме в обычные игры, но в 3D.

Trueopen vr drivers. Позволяет использовать контроллеры для создания бюджетного VR.

У разраба есть канал на Youtube, там есть довольно много забавного. Например, вот такой контроллер:


На этом заканчиваю, надеюсь было интересно.
Подробнее..
Категории: Ar и vr , Будущее здесь , Игры и игровые приставки , Игры , Блог компании альфа-банк , Vr , Разработка под ar и vr , Виртуальная реальность , Haptic , Haptic gloves , Haptic vest

Перевод Как работали кредиты в Древнем Риме

30.07.2020 14:08:36 | Автор: admin

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

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

(Перевод М. Л. Гаспарова.)

Во времена Рима крупные суммы денег меняли хозяев. Люди покупали недвижимость, торговали и инвестировали в провинции, захваченные римскими легионами. Как же это происходило? В своих Письмах Fam., V, 6 и Письмах Att., XIII, 31 Цицерон пишет: Я купил за 3500000 сестерциев тот самый дом через некоторое время после твоего поздравления и ближайший сосед Гай Альбаний; он купил тысячу югеров [625 акров] у Марка Пилия, насколько я помню, за 11500000 сестерциев. Как?, задаётся вопросом историк Харрис (в своей книге "The Nature of Roman Money"), Как Цицерон заплатил три с половиной миллиона сестерциев, которые он выложил за свой знаменитый дом на Палатине Для этого бы понадобилось погрузить и переместить три с половиной тонны монет по улицам Рима. Когда Гай Альбаний купил имение у Марка Пилия за одиннадцать с половиной миллионов сестерциев, он физически отправил ему эту сумму в серебряных монетах? Харрис отвечает на это так: Почти без малейших сомнений, по крайней мере бОльшая часть суммы передавалась через документальные [т.е. бумажные] транзакции. Самая популярная процедура покупки крупной собственности в тот период упоминается Цицероном [Об обязанностях. Книга II, 3.59] nomina facit, negotium conficit предоставление кредита [или обязательства nomina] завершает покупку.


Марк Туллий Цицерон

Что же такое эти nomina, от которых, между прочим, произошло понятие номинальный, обычно используемое в экономике? В своей диссертации на степень Ph.D. "Bankers, Moneylenders, and Interest Rates in the Roman Republic" Чарльз Барлоу пишет (стр. 156-156): Запись в счётной книге назывался nomen. Изначально слово обозначало именно это имя с какими-то числами. Ко времени Цицерона [n]omen могло также обозначать долг, относящийся к записям в счётных книгах кредитора и должника. И этот долг на самом деле был кровью экономики Рима на всех уровнях nomina были совершенно стандартной частью жизней владеющих собственностью, а также повседневным фактом для большого количества прочих людей (Харрис, стр. 184). Плиний Младший, например, писал (в Письмах): Возможно, ты спросишь, смогу ли я без трудов получить эти три миллиона. Почти весь мой капитал вложен в землю, но у меня есть деньги, вложенные под процент, и я могу позаимствовать тебе их без затруднений.


Реконструкция зданий на холме Палатин

Ради конкретности представим, что некий друг Семпроний должен вам один миллион сестерциев. Вы сами, или в случае, если вы богатый сенатор или эквит, то ваш финансовый советник (прокуратор для Цицерона это был Тит Помпоний Аттик) запишет долг в книгу учёта. Что если вам понадобятся деньги на покупку какой-то собственности? Вам придётся ждать, пока Семпроний принесёт вам мешок с миллионом сестерциев? Нет! Так как Семпроний надёжный кредитор (bonum nomen [см. Барлоу, стр. 156]; в современной терминологии агентств кредитной классификации AAA-кредитор), вы сделаете так, как описал Цицерон: передадите nomina и заключите сделку. Например, Цицерон пишет своему финансовому советнику Аттику (Письма Att., XII, 31): Если бы я продал обязательство Фаберия, я не поколебался бы приготовить даже наличные деньги для Силиевых, если бы только удалось склонить его к продаже. Харрис (стр. 192) замечает: Nomina были обращаемыми и ко второму веку до нашей эры, если не раньше, привычно использовались как средство оплаты других активов На латыни процедура, по которой плательщик передаёт nomen того, что ему должны, продавцу, называется delegatio.

Итак, мы поняли, что римляне могли проводить расчёты передачей nomina. Но существовал ли рынок для nomina, как в современном мире существуют, например, ценные бумаги с ипотечным покрытием? По мнению и Барлоу, и Харриса, можно дать положительный ответ. Они утверждают, что римляне сделали ещё один шаг в сторону обращаемости и, по сути, превратили простые записи из счётных книг в оборотные вексели (см. Барлоу, стр. 159, и Харрис, стр. 192). С этим согласны не все. Экономический историк П. Темин ("Financial Intermediation in the Early Roman Empire") тоже сообщает о наличии свидетельств возможности переуступки долгов, открывающей возможности более широкой обращаемости. Но, добавляет он, у нас нет никаких свидетельств того, что это происходило (стр. 721). Тем не менее, косвенные доказательства есть. Например, смысл оборотных векселей, похоже, был хорошо понятен римским юристам, в частности, Ульпиану (Дигест Юстиниана XXX.I.44): Сторона, передающая вексель, передаёт долговое требование, а не только материал, на котором оно записано. Фактом продажи подтверждается, что при продаже векселя продаётся и задолженность, которой она подтверждается.

А что если нам нужно перевести деньги кому-то в другой части мира? Когда доминионы
Рима расширились до Греции, Испании, Северной Африки и Азии, финансы Рима столкнулись с этой логистической проблемой. Если вы находитесь в Риме и, допустим, хотите профинансировать шахты Гая в североафриканском Тапсе, то как передать ему деньги? Ему нужно серебро для покупки материалов, рабов и других товаров, но вы, естественно, очень не хотите отправлять деньги в Африку морем их шансы добраться туда невысоки (им угрожают пираты, кораблекрушения и т.д.). Замечательным вкладом Рима в банковское дело античности стала permutatio передача средств при помощи бумажных транзакций (Барлоу, стр. 168). Она работала следующим образом: публиканы были частными компаниями, занимавшимися сбором налогов в провинциях (а также многими другими делами; см. статью "Publicani" Ульрика Малмендиера). У них существовал филиал в Риме и ещё один в Тапсе. Поэтому если вы давали им серебро в Риме (или передавали им nomina), то часть собранных в Северной Африке налогов они направляли Гаю. Точно таким же образом Республика финансировала свои государственные расходы на внешних территориях. Так как налоги собирались во всех провинциях, обменивая долговые обязательства на налоги, римляне могли переводить средства по всему миру или, по крайней мере, по той его части, которую захватил Древний Рим.


Рим в 40 году до нашей эры

Любопытно, что некоторые историки измеряют развитость финансовой системы Рима по степени присутствия банков (Темин, стр. 719). Разумеется, если мы не найдём в первом веке до нашей эры свидетельств существования нашего банка, то это не обязательно подразумевает отсутствие развитости. До Великой рецессии в США [финансового спада 2007-2009 годов] большая часть финансового посредничества не задействовала банки оно происходило через "теневую банковскую систему". Финансовая аристократия Рима действовала в основном при помощи брокерства (К. Вербовен "Faeneratores, Negotiatores and Financial Intermediation in the Roman World", стр. 12), а потому немного напоминала предшественника теневой банковской системы. Как и теневая банковская система США, она была хрупкой. Вернёмся к нашему первому примеру: стоит заметить, что если тот, кто желает приобрести собственность, начнёт сомневаться в кредитоспособности Семпрония, то не примет его платёж в nomina и потребует наличных. Это заставит вас потребовать возврата долга у Семпрония, которому в свою очередь придётся требовать возврата долга у Тита, и так далее. Однако финансовые кризисы Древнего Рима это тема для отдельной статьи.

Мы выражаем благодарность Кэмерону Хокинсу из Чикагского университета за помощь в поиске литературы.
Подробнее..
Категории: Читальный зал , Финансы в it , Финансы , Блог компании альфа-банк , Деньги , История денег , Кредиты , Древний рим

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru