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

Привет, Habr!

Хочу поделиться решением, которое упростило мне организацию поддержки пользователей через Telegram. Я написал Telegram-бота на Laravel, который работает как прослойка между клиентами и менеджерами, обеспечивая структурированную переписку внутри одной группы с использованием тем (топиков).

Репозиторий проекта (open source):
👉 https://github.com/prog-time/tg-support-bot

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

Одно из самых интересных дел, которыми мне приходится заниматься на работе — это обратная разработка Excel. Я выискиваю причуды в его поведении и решаю, как поступать с ними в нашем фирменном табличном редакторе. Благодаря моему повседневному труду, наши пользователи, возможно, и не подозревают, сколько недокументированных грехов совершила Microsoft ради совместимости. Приглашаю вас одним глазком взглянуть на те ужасы, с которыми мне приходится тягаться — и тогда вы тоже станете бояться Microsoft Excel — не потому, что чего-то не знаете, а наоборот, так как знаете слишком много.

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

В этой статье рассмотрим, как в PHP управлять контекстом замыканий: подменять $this, менять область видимости, получать доступ к приватным свойствам, оборачивать методы, реализовывать мини-AOP и использовать замыкания как ленивые фабрики в DI-контейнерах.

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

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

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

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

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

В этой статье мы разберём:

Практические кейсы, когда действительно нужно использовать несколько СУБД

Пошаговую настройку подключений к разным базам в Laravel

Реализацию моделей и отношений между ними

Плюсы и минусы такого подхода

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

Привет! Меня зовут Ивасюта Алексей, я техлид команды Bricks в Авито в кластере Architecture, а это мой цикл статей о протоколе HTTP. В первой части мы уже познакомились с версией протокола 1.0 и поговорили о структуре ответов и запросов. Теперь пришло время узнать, что такое Cookies и для чего нужен CORS.

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

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

Статья нацелена в первую очередь на PHP backend-разработчиков уровня junior/middle, чтобы познакомить с теорией, которую спрашивают на собеседованиях, и с практическими примерами/советами, полезными для разработки.

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

Наверное, каждый, кто сталкивался с frontend`ом, хотя бы раз использовал адаптивную flex-сетку на N-ном количестве колонок. В данной статье мы не станем рассматривать область применения такого подхода, его плюсы и минусы, а разберем теорию и напишем собственное решение, с брейкпоинтами и настраиваемым спейсингом!

Данная статья, в первую очередь, будет полезна новичкам, однако надеюсь, что и опытные разработчики найдут в ней что-то интересное. Для упрощения жизни, будем использовать SCSS, продублировав CSS «под спойлер».

Привет, Хабр! Сегодня я хочу рассказать о новом пакете для Laravel, который может значительно упростить вашу жизнь, если вы часто работаете с FormRequest классами. Пакет называется desole/laravel-generate-request, и он позволяет автоматически генерировать FormRequest классы на основе ваших моделей. Давайте разберем, как это работает и почему это может быть полезно.

Привет, Хабр! Меня зовут Сережа Сахаров, я PHP-разработчик в Lamoda Tech. Одной из первых задач в компании для меня стал рефакторинг крупной части кодовой базы. Тогда я уже знал о Rector, но использовать его долгое время не доводилось. И в тот момент, что для решения моей задачи он хорошо подойдёт, если добавить еще несколько кастомных правил.
В процессе я получил интересный опыт, который выходит за рамки шаблонного применения инструмента, разобрался во внутреннем устройстве и механизмах работы, и хочу поделиться этим с PHP-сообществом. Если вам часто приходится сталкиваться с рефакторингом старых PHP-проектов, при этом их потребности выходят за пределы штатного набора правил, эта статья для вас.

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

Сейчас Yandex хорошо проиндексировал SPA сайт на Vue 3.

К сожалению, в последнее время всё больше и больше людей советуют использовать JWT для управления пользовательскими сессиями в веб-приложениях. Это ужасная идея, и в этом посте я объясню, почему.

Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.

Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:

1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?

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