Creator, founder, developer
Привет, Хабр! На связи Дарья Попова, тимлид группы мониторинга в Купере. Наша миссия — минимизировать потери от инцидентов для компании и обеспечить сервис на 10/10 для клиентов. Почему это именно группа — вы поймете дальше. Сегодня я расскажу, как мы выстраивали процессы и инструменты мониторинга и автоматизации — и как это все упростило нам жизнь.
Пользователи GitHub часто используют принудительные пуши (git push --force), чтобы переписать историю коммитов — например, когда случайно закоммитили секреты и хотят удалить их из репозитория.
На первый взгляд кажется, что коммит исчез, но на самом деле GitHub его не стирает. «Удаленный» коммит остается доступен по хэшу — пусть и без прямых ссылок. GitHub продолжает хранить такие коммиты вечно.
В статье покажу, как вычислял такие коммиты с помощью GitHub Archive и вытаскивал из них секреты, за которые мне выплатили $25 000 по багбаунти. А еще поделюсь open-source инструментом, который позволит вам самостоятельно искать подобные утечки.
Привет Хабр! Меня зовут Олег, я являюсь действующим QA Engineer в компании Intelsy. Это моя вторая статья после этой (тут могла бы быть ваша реклама), уж очень понравилось делиться информацией и получать обратную связь от читателей! Статья для тех, кто хочет улучшить процессы поставки кода в прод или понять, где можно сэкономить время! Постараюсь немного раскрыть эту тему, поделиться своим мнением (которое ни в коем случае не претендует на звание "истина в последней инстанции"), и да, по традиции помним "у каждого своя кухня". Надеюсь прочтение будет интересным и полезным!
В современных IT-командах границы между ролями стираются: разработчики пишут тесты, DevOps внедряют мониторинг, а тестировщики всё чаще участвуют в процессах, выходящих за рамки классического QA. Один из самых спорных вопросов — должен ли QA инженер заниматься релиз-менеджментом?
Некоторые компании нанимают отдельного релиз-менеджера, другие доверяют этот процесс DevOps, но всё больше организаций приходят к выводу, что именно QA инженер — лучший кандидат на эту роль (Так собственно все работает и у меня на проекте).
В этой статье мы разберём:
· Почему QA идеально подходит для управления релизами?
· Плюсы и минусы
· Как внедрить релиз-менеджмент в обязанности тестировщика
· Почему отдельная роль релиз-менеджера часто избыточна
· Какие инструменты и метрики использовать для успешного контроля выпусков
1. Что такое релиз-менеджмент и почему QA должен в нём участвовать?
Релиз-менеджмент — это комплекс процессов, связанных с планированием, подготовкой и развертыванием новой версии продукта. Он включает:
Пару лет назад единственной настольной игрой, в которую я играл онлайн с друзьями, была «Монополия». Со временем она начала надоедать, и мне захотелось чего‑то нового. Моим открытием стала Machi Koro — экономическая карточная игра, где победа зависит не столько от случайности, сколько от выбранной стратегии, что выгодно отличает её от «Монополии».
На тот момент я не нашёл достойных онлайн‑аналогов Machi Koro, что и подтолкнуло меня к созданию собственной реализации. В этой статье я подробно расскажу о технической стороне проекта: от составления требований до выбора стека технологий.
Микросервисы перевернули игру в разработке приложений. Они сулят гибкость, отличную масштабируемость, командам — больше независимости. Но вот переход на них принес с собой и новые головные боли. Особенно когда дело доходит до развертывания. Управлять кучей мелких, отдельно выкатываемых кусочков — задачка та еще. Старые приемы тут часто пасуют. Нужны свежие идеи, другие инструменты, а главное — по‑другому смотреть на вещи.
В этой статье разберем, как PHP работает со строками и почему даже простой вызов strlen() может привести к неожиданным результатам. На примере крайне простой задачи "что выведет echo strlen('привет!');" посмотрим, что и как влияет на подсчет длины строки, заглянем внутрь реализации strlen() и развенчаем миф о строках как массивах.
Задача в телеге
В одной группе телеграмма с задачами по PHP недавно встретил простой вопрос: что выведет код «echo strlen(‘привет!’);»?
Был вопрос и 4 варианта ответа.
Вроде бы все просто. Но правильно ответили лишь 16%. Наиболее популярным ответом оказался «7», что неверно. Но именно его дали 71% ответивших.
Недавно состоялся у меня небольшой спор с коллегой, активно защищающим анемичные модели с размещением логики в сервисах. Несколько лет назад я и сам был последовательным фанатом такой разработки, пока не стал спотыкаться об ограничения этого подхода. В этом тексте хочу поделиться с вами плюсами и минусами анемичных моделей, как их вижу я.
В пригороде далекого города Нью-Дели жил простой индийский паренек со сложным именем Чандракант. Любил он маму, Кришну и общаться с волшебными говорящими грибами.
Вы знаете, что такое прогрессивный JPEG? Можете почитать хорошее объяснение. Идея заключается в том, что вместо загрузки изображения сверху вниз оно сначала грузится размытым, а потом постепенно становится чётче.
Что, если мы применим тот же принцип к передаче JSON?
Modulith — архитектурный стиль, при котором приложение остаётся монолитом, но код внутри разбит на модули (подпапки) по доменам.
Классическая структура проектов выглядит так:
├── src ├── Command ├── Controller │ ├── Product │ └── User ├── Doctrine ├── Entity │ ├── Product.php │ └── User.php ├── Message ├── MessageHandler └── Kernel.php
Структура modulith в Symfony выглядела б так:
├── src ├── Product │ ├── Command │ ├── Controller │ ├── Doctrine │ ├── Entity │ ├── Message │ └── MessageHandler ├── User │ ├── Controller │ └── Entity └── Kernel.php
Разница в том, что в modulith каждый модуль (например Product, User) содержит все компоненты в своей папке, а не по всему проекту.
Если нужна доработка условной корзины, вы сразу знаете где находится весь код отвечающий за корзину, меньше конфликтов при слиянии
Вдобавок исчезают портянки файлов, когда открываете Entity, а там 30 файлов в столбик
Часто самая большая сложность возникает у людей при конфигурации модулей. Ничто нам не мешает запихать всю конфигурацию в один общий файл, например config/services.yaml, но из-за этого файл быстро станет раздуваться, что снизит его поддерживаемость и в нем будет единая точка связности модулей.
Поэтому конфигурацию модулей лучше выносить в сами модули
Привет, Хабр!
Если вы тимлид или архитектор, и в команде всё чаще звучит «давай сделаем CQRS» — стоит остановиться. Этот паттерн мощный, но далеко не беспроблемный.
Как преодолеть узкие места масштабируемости Mercure HUB, заменив BoltDB на Redis, а так же собрать свою статическую сборку php сервера вместе с Caddy, Mercure, FrankenPHP
Заранее оговорюсь, всё что будет описано в данной статье, будет касаться runtime (децентрализованного) кеша и применимо не только к Gо приложениям.
Зачем нам нужен такой кеш? По нескольким причинам.
На хабре и в остальном интернете хватает статей с критикой ООП. Кто-то ругает эту концепцию за излишнюю многословность, кто-то рассуждает о плохих аспектах ООП, кто-то сравнивает реализации ООП в разных языках.
После прочтения большинства этих статей и нескольких лет кодинга на C# я заявляю: «ООП - это один большой обман. Никто не понимает, что это такое. Люди просто говорят какие-то умные термины, их собеседники с умным видом кивают, хотя на деле трактуют эти же термины совершенно по-разному».
И вот почему.
Я Диана, системный аналитик в Clevertec и экс-преподаватель. В этой нескучной лекции расскажу:
- Что такое Keycloak и для чего он нужен?
- Как Keycloak помогает с межсистемной аутентификацией?
- Какие плюсы и минусы у Keycloak при использовании в продакшене?
- Какие альтернативы есть у Keycloak?
Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.
Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.
Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?
Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.