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

Например, Лаплас в 1805 году, используя формулы Ньютона, посчитал, что скорость гравитации должна быть минимум в 7·106 раз выше скорости света — иначе орбиты планет не совпадали бы с тем, что мы видим на небе. Расчеты Лапласа используются до сих пор, и были одним из аргументов противников теории относительности Эйнштейна, предложенной на сотню лет позже.

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

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

А это сразу ссылка на часть 2.

Этой ночью представят новую версию Kubernetes. Среди главных изменений на первое место разработчики поставили стабилизацию функции CSI Migration — отказ от внутренних плагинов хранилищ в пользу CSI-драйверов. Также в этой версии устаревший контроллер PodSecurityPolicy заменен на новый PodSecurity Admission.

По традиции в обзоре рассказываем обо всех новых функциях (alpha), а также упоминаем те, что перешли на уровень выше (beta, stable).

NSA в соавторстве с еще несколькими организациями подготовила доклад (Kubernetes Hardening Guide) на 59 страниц на тему: Гайд по улучшению безопасности в Kubernetes.

Почему это может быть важно ?

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

Продолжаем обзор паттернов интеграции микросервисов. В первой части мы рассказали, зачем IT-специалистам нужны шаблоны интеграции, и для каких задач они подходят. Подробно остановилисьна Circuit Breaker, Sidecar, Ambassador, Anti-Corruption Layer и Async Request-Reply. Сегодня по плануразобрать Backends for Frontends, Cache-Aside, Gateway, Gateway Aggregation и Gateway Routing. 

АПИКС – название информационной системы автоматизации процессов ипотечного кредитования и сопровождения в Банке ДОМ.РФ (рис. 1). Система предназначена для управления ипотечными продуктами, автоматизации процесса предоставления клиентам ипотечного кредита, а также выкупа и сопровождения закладных до полного исполнения обязательств. Я, Алексей Прутик, чаптер-лид системного анализа, в данной статье расскажу, как мы на базе АПИКС строим единый кредитный конвейер, совершенствуем наши ИТ-процессы и архитектуру.

Перед тем, как запускать свой сайт или приложение, в котором вы собираетесь использовать cookies или иные идентификаторы (local storage, AAID, UDID и т.д.) устройств/сессии пользователя, необходимо выполнить требования законодательства о персональных данных.

Зачем? Во-первых, вы выстраиваете открытые и честные отношения со своими пользователями. Во-вторых, вы будете готовы к проверкам регуляторов. В-третьих, вы сможете избежать штрафов, которые могут достигать 4% годового оборота своей компании.

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

Согласно ФЗ «О персональных данных» и GDPR куки-файлы и иные идентификаторы пользователя относятся к персональным данным, поскольку позволяют теоретически определить конкретного субъекта или выделить его среди других лиц.

Наиболее известным делом по рассматриваемой нами теме стал судебный спор Vidal-Hall v. Google (2015). Используя сookieы-файлы, компания Google осуществляла сбор информации об интернет-трафике пользователей. Заявители, не будучи осведомлены о незаконных действиях ответчика, настаивали на привлечении последнего к ответственности за нарушение порядка использования сookies – персональных данных, которые позволяют вычислить пользователей.

Суд занял позицию истцов и положительно ответил на вопрос об отнесении Cookie-файлов к персональным данным, так как они, «не называя прямо субъекта … позволяют выделить его из всей массы пользователей, следовательно, отвечают критерию идентификации» [1].

Следовательно, в отношении cookies и прочих идентификаторов необходимо соблюдать требования законодательства.

Пространственно-временно́й континуум обходится одним временны́м и тремя пространственными измерениями. M-теория струн расширяет физическую модель до невообразимых девяти пространственных измерений, но сохраняет время линейным.

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

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

Банковские сервисы по умолчанию не должны падать, и даже прилечь на секундочку, и даже когда мы обновляемся. Ведь даже секунды могут привести к потерям с множеством нулей. Чтобы этого не произошло мы используем blue-green deployment.

Простым языком blue-green deployment - способ развертывания, который позволяет обновлять приложения не отклоняя ни одного запроса, без остановок. Как это сделать, расскажу и покажу на примере. Статья подойдет DevOps-инженерам и бэкенд-разработчикам, особенно на HighLoad-проектах, а также моим будущим коллегам, как методичка по безрисковым релизам, чтобы прод не падал каждые 2 недели по графику релизов (а такое тоже бывало).

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

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

Сейчас будет «Но», правда?

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

Прим. перев.: автор данного исследования — Marc Richards, Solutions Architect и DevOps-инженер — продемонстрировал потрясающую настойчивость и тщательность в тотальной оптимизации производительности веб-приложения. Получившийся материал — кладезь полезных знаний для расширения своего кругозора в области оптимизации, особенностей сетевого стека в Linux и не только, даже вне зависимости от практической заинтересованности в конечном результате автора. Приготовьтесь к по-настоящему длинному техническому путешествию с обилием терминологии, увлекательных графиков и полезных ссылок.

Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:

• состояли из 3-10 JOIN-ов по коррелирующим запросам;

• уielded от 10 до 1,000,000 строк;

• должны были выполняться в течение времени, определенного UX-ом;

• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;

• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.

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

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

Единая биометрическая система (ЕБС) с 2018 года используется для идентификации человека по его биометрическим характеристикам: голосу и лицу.

Чтобы получать услуги по биометрии, пользователю необходимо зарегистрироваться в системе в одном из 13,1 тысяч отделений банков. Там операционист сделает его фотографию, запишет голос и отправит эти данные в систему. А для того чтобы компании могли оказывать по биометрии различные услуги, им необходимо провести интеграцию с ЕБС.

Оператором системы является «Ростелеком», а разработкой занимаемся мы – дочерняя компания РТЛабс .

Меня зовут Сергей Браун, я заместитель директора департамента цифровой идентичности в РТЛабс. Вместе с Артуром Душелюбовым, начальником отдела развития и разработки департамента цифровой идентичности, мы расскажем, как мы создавали платформу для любой биометрии, с какими проблемами встретились и как их решали.