Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?

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

Hello world!

Представляю вашему вниманию третью часть практического руководства по Rust.

• Первая часть
• Вторая часть
• Четвертая часть
• Бонус

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

Руководство основано на Comprehensive Rust — руководстве по Rust от команды Android в Google и рассчитано на людей, которые уверенно владеют любым современным языком программирования. Еще раз: это руководство не рассчитано на тех, кто только начинает кодить 😉

"Краткость - сестра таланта" - именно так сказал Антон Павлович Чехов, и теперь говорю я. Сегодня, завтра и до конца дней habr-а речь пойдет о WebSocket-ах: "Что это?", "Как работает?" и главное - "Как это взламывать?" (в целях этичного хакинга конечно). Начнем с простого и будем идти к более сложному, пробираясь через тернии к звёздам.

Серверные компоненты React – это большой кусок работы. Недавно мы переосмыслили нашу документацию и устроили ребрендинг Mux. Пока мы этим занимались, мы перенесли весь материал сайтов mux.com и docs.mux.com на серверные компоненты. Так что, поверьте мне… я знаю. Знаю, что это возможно, не так страшно и, в принципе, что дело того стоит.

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

Видео от автора на ту же тему.

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

Поможет нам в этом Дмитрий Смаль, руководитель подразделения Managed MySQL и SQL Server в Yandex Cloud. Каждый день он занимается эксплуатацией и автоматизацией СУБД, а до этого делал нагруженные и не очень web-приложения. В целом любит делать разные интересные штуковины, которые работают! Сегодня мы с ним будем говорить про решение для высокодоступного MySQL.

Я достаточно давно занимаюсь Backend разработкой и последние несколько лет, все больше и больше пишу разные блокчейн проекты (Solidity на EVM). Погружение в блокчейн мне давалось непросто и мой бэкендерский мозг несколько раз ломался, и я решил поделиться своим взглядом на погружение в блокчейн-разработку.

У этого поста также есть видеоверсия.

Feature-Sliced Design — это архитектурная методология, активно набирающая популярность в последнее время. И не зря: организация разработки по её правилам позволяет упростить процессы, сделать их быстрее и гибче. Больше не нужно будет переживать из-за совместной работы в одном домене и конфликтов кода, долго искать ответ на вопрос «А куда же впилить новую фичу, тут и так намешано…» 

О том, как устроена Feature-sliced Design, чем она отличается от «классической» организации кода, плюсах и минусах от её внедрения — в этой статье.

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

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

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

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

Существует множество разных подходов к построению архитектуры серверных приложений. В данной статье рассмотрим Event-driven архитектуру (она же событийно-ориентированная). Рассмотрим основные принципы, как перейти от связей Компонент А <-> Компонент В, к связям через события Компонент А -> Событие А -> Компонент Б и зачем это нужно?

Это вторая часть моих копаний во внутренностях MySQL. В первой части [habr] были затронуты запись страниц данных на диск (с промежуточной записью в DoubleWrite buffer) и запись бинлогов (с батчингом в виде group commit). В этой части я расскажу про redo log и как все части MySQL координируются для достижения надежной работы.

Сегодня особую популярность получила микросервисная архитектура веб-приложений. У такого подхода есть много известных сторонников. К ним относятся Facebook, Uber, Groupon, Klarna, Amazon, Netflix, eBay, Comcast и другие. Но насколько необходим подобный подход в каждом конкретном случае?

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

В прошлой статье мы рассмотрели реализацию эффективной очереди на основе "эластичного" кольцевого буфера, а в этой попробуем разобраться с особенностями использования модуля Worker threads в Node.js - какие проблемы внедрения многопоточности будут нас ждать при попытках сделать код более производительным, и узнаем, как их можно обойти, применяя типовые концепты.

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