В прошлой статье мы рассказали, почему Compo Soft решила уйти от привычного PHP‑стека и перейти на Java ради выхода в сегмент Enterprise. Но если кто‑то подумал, что за этим решением последовал массовый найм Java‑разработчиков — нет. Мы пошли по куда более хардкорному пути: взяли всю свою PHP‑команду и начали переобучать ее на Java. Полностью c нуля. И без отрыва от производства.
Статья о реализации параллельных SOAP запросов в PHP с использованием кастомного HTTP транспорта и Guzzle promises.
Я PHP-разработчик с восьмилетним коммерческим опытом. Долгое время я не видел смысла в микросервисах — пока не перешёл на Python и не столкнулся с его архитектурными особенностями.
Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.
Последние 4 года я занимаюсь реализациейпроектов на PHP по DDD, используя слоистую архитектуру. Каждый раз я сталкиваюсь с одной из самых насущных проблем DDD: определение границ агрегата. Ведя разработку «как удобно», очень легко не заметить, как вся бизнес логика сосредоточилась в один «божий класс».
В этой статье я поделюсь своим опытом, как проектировать и разрабатывать по DDD, не скатываясь в «один агрегат, чтобы править всеми». Поговорю о проблемах определения границ агрегата и цены чтения, гидрации и содержания больших объектов в памяти PHP процесса.
На протяжении многих лет команда Compo Soft успешно создавала eCommerce‑решения, клиентские порталы, PIM‑системы и другие решения малого и среднего бизнеса. Для этих задач было достаточно привычного стека на PHP и связанных с ним технологий. Когда в 2018 компания приняла стратегическое решение о выходе в сегмент Enterprise — встал вопрос о новом стеке. Им стала Java. В этой статье решили поделиться своим пониманием и опытом — почему сделан такой выбор, и почему PHP «не вывозит» Enterprise‑решения.
Enum’ы в PHP с нами уже давно, но вы задумывались, как они реально работают внутри? Давайте разберёмся, что там происходит под капотом.
Привет, Хабр!
Redis Streams давно перестали быть экзотикой для любителей CLI и стали нормальным способом гонять события между сервисами. Но у PHP есть своя специфика: один код — два способа конкурентности. Либо Amp с неблокирующим I/O и семафорами, либо Swoole с корутинами. В обоих случаях хочется одного и того же: устойчивые consumer-группы, ручной ack, автоматический claim зависших сообщений, backpressure, экспоненциальные ретраи и внятный дед-леттер.
Берем два разных больших числа (отличаются на 1) и проверяем равны ли они. Должно быть false – не равны. Но на самом деле – true! Они «равны» 😊
Эта статья для тех, кого удивляет данное поведение.
На одной из конференций по разработке ПО я разговорился с коллегой о современных подходах и архитектурных паттернах. В ходе беседы он задал мне, казалось бы, простой вопрос:
«Какой архитектурный паттерн используется в твоём текущем проекте?»
Этот вопрос заставил меня задумать и взглянуть на проблему выбора архитектуры под другим углом. Возможно, повлияла атмосфера конференции (всё-таки они должны приносить пользу), но я задумался: почему при разработке приложений мы чаще всего закладываем один архитектурный паттерн, а не комбинацию нескольких? Однако, как показал личный опыт и обсуждения в профессиональном сообществе, этот вопрос часто подразумевает поиск единственного правильного ответа. В реальности же, на практике, мы нередко видим, как команды стремятся придерживаться одного доминирующего подхода — будь то акцент на CQRS, строгое следование Hexagonal Architecture или применение DDD в объеме текущего понимания и опыта команды. Но мало кто пытаеться применить сразу несколько подходов, где каждый паттерн решает свою задачу.
Гибридные подходы, комбинирующие сильные стороны различных архитектурных решений, становятся не просто возможной опцией, но часто необходимостью. Каждое из этих решений способно эффективно решать специфические проблемы:
Разработка на Laravel становится максимально эффективной, если использовать автоматизацию на каждом этапе: от настройки окружения до проверки кода и тестирования. В этой статье я покажу, как построить процесс разработки, который снижает количество ручной работы, повышает качество кода и ускоряет выпуск функционала.
Материал рассчитан на разработчиков с опытом работы с Laravel, которые хотят внедрить автоматические проверки, статический анализ, единый стиль кода и готовую сборку Docker Compose для быстрого старта проектов. Я поделюсь своим опытом, конкретными инструментами и практическими примерами.
Привет, Хабр! Одна из ключевых задач performance-маркетинга — понять, какая реклама реально приводит клиентов. Для кликов есть Яндекс.Метрика, но когда одно из целевых действий — звонок, анализировать источники сложнее, а значит и понять какой креатив работает лучше.
Использование динамических виртуальных номеров позволяет сопоставить звонки с конкретным рекламным источником. Для каждого визита система подставляет уникальный номер телефона и фиксирует обращение. Когда клиент звонит, мы связываем его звонок с конкретной рекламой.
В Rusprofile наш домен — регтех, мы помогаем компаниям оценивать надежность контрагентов. Каждый день сотни скриптов качают данные из официальных открытых источников, парсят и строят кеши.
В какой‑то момент суммарное время работы скриптов стало неподобающим — задача заканчивалась, условно, к обеду следующего дня, в то время, когда нам нужно было к утру.
Эта статья — о том, как «проклятье масштаба» оказалось алгоритмической задачей; решение — получилось благодаря принципам обхода ориентированных графов; а запаса прочности решения хватило, чтобы с момента появления на протяжении лет не требовалось дополнительных ресурсов и каких‑либо доработок.
Надеемся, эта история будет интересна тем, кому близки темы работы с зоопарком скриптов, управления связанными задачами, алгоритмических решений инженерных проблем, а также всем, кому любопытно, как различные сервисы устроены под капотом и какие особенности есть в регтех.
Будут технические детали, теория графов и немного рефлексии.
Доброго времени суток дорогой читатель!
Всё последующее содержание статьи очевидно является некой формой садизма, так что если если вы пришли за чоколадкой golangом, питоном, ванильным чапманом или другими формами сладкой жизни, лучше уходите.
Тема изоляции данных клиентов (мультитенантность) в saas или подобных продуктах исторически считается если не самой, то одной из наиболее сложных и требующих архитектурных извращений, тем в веб-разработке.
Существует несколько разных подходов, от банального tenant_id в каждой таблице базы данных, до физического разделения данных на разные сервера под разных тенантнов.
Компромиссным решением является выделение идентичных по содержимому (таблицам) схем для каждого нового клиента в одной базе данных. Таким образом мы получаем относительную защиту от утечек данных между клиентами с минимальными затратами на аренду новых серверов. Именно этот вариант мы и будем рассматривать.
Привет, Хабр! Мы — команда проекта ChameleonLab, и это история о том, как мы начали создавать полномасштабный образовательный центр по стеганографии и криптографии, отправной точкой которого стал наш desktop-инструмент.
По просьбам пользователей мы начали трансформацию в онлайн-сервис. Расскажем, как мы создали сайт на собственном микро-движке, который работает на JSON-файлах, почему отказались от популярных CMS и как планируем переносить сложную логику с Python в веб.
Это статья — пример небольшого личного опыта, где я пытался решить одну чисто техническую задачу для одного из моих текущих проектов. Задача в конце‑концов была решена, насколько правильно — не знаю, но надеюсь многим будет интересен и полезен мой опыт. Итак, небольшая драма в 5-ти актах.
Хочется быстрый кеш или общение между процессами? Хочется использовать фишки long-running PHP, но без long-running?
Давайте разберёмся, как работать прямо с оперативной памятью: от System V до MapViewOfFile; От shmop до FFI.
Недавно мы с командой работали с клиентом из финансового сектора: у него есть сайт и личный кабинет, давно написанные на PHP (бэк и фронт), и задача — обновить дизайн и пользовательский опыт без глобальных изменений «под капотом».
Мы начали исследовать, насколько целесообразно сейчас поддерживать фронт на PHP. Пока разбирались, собралось много аргументов и наблюдений. Делимся ими, чтобы помочь компаниям и разработчикам, оказавшимся в такой же ситуации.
Массивы — это хлеб и масло PHP-разработчика. Мы используем их постоянно, но редко задумываемся, как они устроены внутри. А от этого устройства напрямую зависит скорость и память нашего приложения. Давайте разберемся.
Столкнулись с необходимостью работать со смайликами как в Telegram: группировать, искать и хранить в базе? — Готовых решений на PHP не нашлось.
Рассказываю, как я создал библиотеку Emoji PHP для решения этих задач
