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

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

Меня зовут Андрей Колнооченко. Я отвечаю за ядро файловой системы Яндекс Диска. Когда мы запускали сервис, то сразу ориентировались на рост и приняли решение шардировать базу метаданных о файлах. Но за 11 лет Яндекс Диск настолько вырос, что нам пришлось трижды менять подход к шардированию. В статье расскажу, с какими проблемами мы сталкивались по мере роста сервиса и как от MongoDB пришли в итоге к PostgreSQL.

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

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

Это может показаться простым, но помните, что взаимодействующие компоненты могут быть написаны на совершенно разных языках. Ситуация усложняется еще больше, если учесть, что разные аппаратные/системные архитектуры, скорее всего, имеют различные способы представления «одинаковых» значений. Простого копирования байтов из одного компонента в другой недостаточно. Даже в Java, где мы можем считать себя «защищенными» от такого рода ситуаций, нет требования, чтобы две разные реализации JVM или разные версии от одного производителя использовали одно и то же внутреннее представление для объектов.

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

Существует несколько таких «форматов передачи», начиная от текстовых стандартов, таких как YAML, JSON или XML, до бинарных вариантов, таких как Protobuf, которые включают метаданные или являются полностью неструктурированными.

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

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

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

Сегодня я поделюсь нашей историей запуска инструмента Kafka Cruise Control от LinkedIn. Наш путь по запуску на наших объёмах был тернист, и получился интересным, почти детективным рассказом. А если вы думаете, как автоматизировать рутинные операции по администрированию Kafka-кластеров, то, уверен, почерпнёте для себя что-то полезное. 

Контроль порядка запуска

version: '2'

services:
    web:
        build: .
        ports:
            - "80:8000"
        depends_on:
            - db
        entrypoint: "./wait-for-it.sh db:5432"
    db:
        image: postgres

Postgres - один из крупнейших open source проектов. Он создавался многие года. Кодовая база накопилась огромная. Мне, как программисту, всегда было интересно как он работает под капотом. Но не про SQL пойдет речь, а про язык на котором он написан. Про C. 

С общей архитектурой можно ознакомиться здесь

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

Привет, Хабр! Меня зовут Никита Летов, я тимлид бэкенд-разработки мобильного приложения Росбанка для физических лиц. Этот пост входит в серию постов по разработке бэкенд-микросервисов на Java и Spring и является адаптацией моего доклада с JPoint 2022. 

Также хочу предупредить, что данный пост не cookbook и не предоставляет идеально приготовленное решение какой-либо бизнес-проблемы. Это разбор одной технологии, которая при правильном использовании может помочь вам в решении реальной проблемы. А может и не помочь — всё зависит от ее природы.

Привет, Хабр!

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

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

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

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

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

Меня зовут Денис Исаев, и я работаю в Яндекс Go. Сегодня я поделюсь опытом решения проблем с отказоустойчивостью из-за ретраев. Основано на реальных инцидентах в системе из 800 микросервисов.

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

В этой статье разберем вариант реализации функционала перезапроса сообщений из семейства resilience шаблонов. Мы поговорим о retry. Точнее обсудим:

1. Что такое устойчивость и какое влияние на нее имеет retry?

2. Анализируем, где применять retry;

3. Реализуем retry;

4. Пишем unit-тесты с wiremock;

5.Делаем starter;

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

Разработка хорошего API требует особого внимания к деталям и соблюдения ключевых принципов программирования прикладных интерфейсов. Поэтому важно, чтобы у разработчиков были необходимые знания. Меня зовут Анастасия Иванова, я работаю в МТТ (входит в экосистему МТС) техническим писателем МТС Exolve. В этой статье я дам рекомендации по созданию API, которые помогут вам сделать его надёжным, масштабируемым и удобным в использовании. Самое интересное — под катом.

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

План статьи:

— Проблематика черного ящика и почему его вообще нужно вскрывать.
— Варианты решения проблемы.
— Подробно про мок-сервер, как один из вариантов решения проблемы: зачем нужен, в чём польза и как выбрать между готовыми и самописными решениям.
— Как написать свой мок-сервер.
— Посмотрим как он работает на реальной задаче. 
— Закрепляем материал в блоке «Польза мок-сервера».

Уверен, что многие, кто интересовался подходами к разработке микросервисной архитектуры, знакомы с трудами Криса Ричардсона на эту тему и уже встречали transactional outbox pattern. А для тех, кто не знаком, кратко расскажу основную идею:

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