Пользователь
Готофобия – это боязнь использовать инструкции goto. Обычно возникает из-за непонимания и незнания контекста этой проблемы, а также из-за историй о незапамятных временах в истории программировании. Разработчики, страдающие готофобией, готовы жертвовать удобочитаемостью своего кода, только бы не прибегать к goto.
Эта заметка о том, зачем нам нужен пакет coroutine для Go и как он будет выглядеть. Но прежде всего, что такое корутины?
Сегодня каждый программист знаком с вызовами функций (подпрограмм): F вызывает G, которая останавливает F и запускает G. G выполняет свою работу, потенциально вызывая и ожидая другие функции, и в конце концов возвращается. Когда G возвращается, G уже нет, а F продолжает работать. В этой схеме одновременно выполняется только одна функция, а ее вызывающие ожидают, поднимаясь вверх по стеку вызовов.
В отличие от подпрограмм, корутины выполняются конкурентно на разных стеках, но все равно верно, что одновременно выполняется только одна функция, а ее вызывающая сторона ждет. F запускает G, но G не выполняется немедленно. Вместо этого F должен явно возобновить (resume) выполнение G, который затем начинает выполняться. В любой момент G может развернуться и вернуться (yield) назад к F. Это приостановит G и продолжит F операцию возобновления. В конце концов F снова вызывает resume, который приостанавливает F и продолжает G после выхода. И так далее, туда-сюда, пока G не вернется, что приведет к очистке G и продолжению F с последней операции возобновления, с некоторым сигналом для F, что G закончена и F больше не должна пытаться возобновить G. В этом паттерне одновременно выполняется только одна корутина, а ее вызывающая сторона ждет на другом стеке. Они выполняются по очереди в четко определенном, скоординированном порядке.
Это несколько абстрактно. Давайте посмотрим на реальные программы.
В этой статье мы научимся писать полноценный gRPC сервис на Go на примере сервера авторизации с полноценной архитектурой, готовой к продакшену. Мы напишем как серверную часть, так и клиентскую. В качестве клиента мы возьмём мой сервис — URL Shortener, о котором у меня также есть статья и видео-гайд на ютубе. Попутно мы познакомимся с базовыми подходами к работе с авторизацией. И в конце настроим автоматический деплой сервиса с помощью GitHub Actions на удалённый сервер.
Видео-версия этого гайда с более подробными объяснениями
Исходный код проекта: https://github.com/GolangLessons/sso
Итого, наш план:
На выходе мы получим полноценный рабочий сервис авторизации, который вы сможете по аналогии подключать к своим пет-проектам.
Кратко обо мне: меня зовут Николай Тузов, я много лет занимаюсь разработкой на Go, очень люблю этот язык. Также веду свой YouTube-канал.
Тут мы создаем формат для описания Сущностей и Компонентах в отдельных файлах, вместо класса. Это позволит упростить разработку и поможет начинающим программистам проще освоить ECS.
Алгоритмы важны. Но реализовать их можно очень по-разному.
При одном и том же алгоритме, оптимизированная библиотека будет в тысячу раз быстрее наивной.
Любите оптимизации, специализированные структуры данных и трюки с битами? Тогда скорее под кат!
После выхода PHP7 появилась возможность сравнительно небольшой ценой писать долгоживущие приложения. Для программистов стали доступны такие проекты, как prooph, broadway, tactician, messenger, авторы которых берут на себя решение наиболее частых проблем. Но что если сделать небольшой шаг вперёд, углубившись в вопрос?
Попробуем разобрать судьбу ещё одного велосипеда, который позволяет реализовать Publish/Subscribe приложение.
Эта статья представляет собой краткий (шутка!) конспект одноименного (почти) вебинара, недавно проведенного автором.
Цель и вебинара и статьи - дать начинающим представление о тех понятиях, которые вынесены в заголовок, чтобы помочь из избежать повсеместной путаницы, сопровождающей эти темы.
Ну и немного раскрыть глаза на то, что, оказывается в PHP есть и асинхронность, и многопоточность, и в общем-то не нужно ждать мифической версии PHP 10, чтобы начать их использовать уже прямо сейчас!
Привет! В статье поделюсь, как инструмент автоматического рефакторинга Rector помогает обуздать легаси и автоматизировать обновление PHP проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью.
Статья написана на основе доклада с PHP Russia 2022.
Доброго всем дня!
Хочу рассказать о своём практическом опыте реализации взаимодействия между процессами в среде Linux в условиях, когда вычислительных ресурсов существенно не хватает. По условию, один из процессов написан на C++, второй на PHP, потому дополнительно мы рассмотрим доступность соответствующих API из PHP а также варианты действий в случае, когда для нужного API PHP-обёртка отсутствует.
Ещё одна статья на избитую тему? Да! Потому что за два часа поиска не нашёл ни одной, по которой можно было пройтись от и до и получить работающее окружение.
Шагов, на самом деле, немного, все очень простые, нужно лишь...
Привет.
Сегодня хочу поговорить о том, как ускорить приложение через конфигурирование PHP-FPM.
Сейчас самый популярный (из тех с которыми я сталкивался) стек на котором поднимается PHP приложение это веб сервер nginx и процесс-менеджер php-fpm.
Я хочу поднять простое приложение с Laravel проектом, которое устанавливается со всеми параметрами по умолчанию. Попробуем это приложение нагрузить пользователями с помощью простого Javascript скрипта и посмотрим как ему удастся справиться с нагрузкой и как мы можем повысить обрабатываемую нагрузку только конфигурированием php-fpm. В конце статьи можно будет найти ссылку на GitHub и попробовать своими руками.
Для начала посмотрим на стандартную конфигурацию php-fpm и попытаемся понять где могут быть проблемы в производительности с коробки.
Итак, у меня есть простое приложение на PHP с NGINX и PHP-FPM предустановленными в стандартных конфигурациях и маршрут Laravel.
Представьте, что вы начали разработку нового Android-приложения. Поначалу особых проблем не будет. Вы реализовали лишь самые базовые функции. Экранов немного, и все они простые. Вам легко ориентироваться в коде. Вы бодро добавляете одну фичу за другой. Но со временем разработка усложняется: кода становится много, главный экран обрастает большим количеством UI-элементов и логики, экраны образуют сложные цепочки переходов. Приходится ломать голову, чтобы добавить что-то новое, не сломав ничего из старого. Скорость разработки падает. Знакомая ситуация?
Существует эффективный способ борьбы со сложностью — компонентный подход. Мы в MobileUp применили его в трех крупных Android-приложениях и теперь не представляем, как жили без него раньше.
Меня зовут Артур, я тимлид в компании MobileUp. Я помогу вам освоить компонентный подход. Постараюсь сделать это как можно проще и увлекательнее.
Вас ждет серия статей. Это первая из них — теоретическая. В ней мы рассмотрим, какие сложности встречаются в Android-приложениях, и почему MVVM и Clean Architecture не панацея против них. Я расскажу, что такое компонентный подход и в чем его преимущества. А в конце статьи будут ссылки на материалы для углубленного изучения.
Представьте, что вы отвечаете за большой веб-сервис со сложным интерфейсом, замысловатой навигацией, авторизацией, платежной системой. Представьте, что однажды к вам приходит ваш PO и просит сделать не одну его часть, не один конкретный бизнес-процесс, а весь этот сервис встраиваемым. И конечно по пути ни один из сотен тысяч пользователей вашего сервиса не должен пострадать. Возможно ли это и насколько это дорого?
Эта статья — переработанная версия доклада Отказоустойчивая работа с Redis с прошедшего 17 октября 2020 митапа PHP-разработчиков Йошкар-Олы.
Мы поговорим о подводных камнях использования Redis в системе, где важна отказоустойчивость — на примере хранения сессий в условном веб-сервисе, написанном на PHP, но многие замечания будут справедливы и для других платформ — например для микросервисов на Go. Статья будет полезна, если вы проектируете микросервисы или монолитные приложения с достаточно большой нагрузкой и интенсивно работаете с Redis либо столкнулись с потребностью в перепроектировании механизмов аутентификации и сессий.
Всем привет! В этой статье хочу поделиться опытом построения системы доменных событий (domain events) в нашем модульном монолите и микросервисах, рассказать о том, как мы гарантируем их доставку, следим за консистентностью в рамках транзакций, используя transactional outbox, чем доменные события отличаются от интеграционных и всё это в рамках multi tenant приложения. Подробнее под катом.
Статья написана по мотивам моего доклада на митапе. В нем я рассказываю историю того, как мы взяли и не распилили монолит на микросервисы, и что сделали вместо этого.
На тот момент наша команда работала над приложением, начало которому было положено еще в 2009 году не искушенными в архитектуре студентами. К 2018 это уже был типичный big ball of mud (большой ком грязи), или, этакий «монолит-копролит», как выразился один наш коллега. Думаю, многим знакомо.
Мы занимаемся разработкой огромного количества сложного ПО для автоматизации и энтерпрайза и Workflow для нас — это большая и больная проблема. Если для вас тоже — я расскажу, как писать и оркестрировать очень сложные процессы на масштабах, и как убедиться, что они не падают. А также как делать таймеры на 30 дней внутри процессов. И самое главное, как всё это пилить на PHP.
Меня зовут Антон Титов. Я более 17 лет занимаюсь коммерческой разработкой. Являюсь соавтором Spiral Framework, RoadRunner и Cycle ORM. Основной стек: PHP и Golang. Разговор пойдет про нашу разработку Temporal PHP SDK, которая и помогает решать все вышеперечисленные сложные задачи.