Этот текст (не осмелюсь назвать «статьей») стал побочным продуктом моего «грандиозного» замысла — попытки пересказать понятным языком содержание одного из эпизодов The Huberman Lab podcast, который «Как ставить цели и достигать их». И, как все прочие эпизоды, он начинается со слов «Welcome to the Huberman Lab podcast where we discuss science and science‑based tools for everyday life. »

Мне захотелось провести на себе эксперимент, проверить, сработают ли советы и «science‑based tools» от Andrew Huberman в моей повседневной жизни, жизни простого и заурядного человека. Была выбрана цель — «Написать статью "Как ставить цели и достигать их"» и дан старт.

К сожалению (или к счастью), кавалерийским наскоком взять крепость не удалось: любопытство и занудство, умудряющиеся много лет во мне уживаться, не позволили просто «взять и пересказать эпизод». Я пытался (и до сих пор пытаюсь) разобраться в непонятных мне терминах, концепциях и взаимосвязанных процессах. Их, непонятных, оказалось очень много. Так много, что через две недели ежедневного труда я решил: для начала хватит и статьи о роли в процессе достижения цели концепта «Random Intermittent Reinforcement». Потом появились мысли, что и здесь стоит умерить пыл и ужаться до описания роли Reward Prediction Error в Random Intermittent Reinforcement. С чем я себя и поздравляю. И периодически задаю вопрос: интересно, будет ли момент, когда попробую «сделать отдельную статью» из одного абзаца? Из одного предложения? Слова? Ответов нет. Двигаюсь вперед, а там — как получится.

Зачем нужен OpenID

Пример кросс-авторизации

• IIFE модуль: шаблон JS модуля
• Открытый модуль: шаблон открытого JS модуля
• CJS модуль: CommonJS модуль или Node.js модуль
• AMD модуль: асинхронное определение модуля или RequireJS модуль
• UMD модуль: универсальное определение модуля или UmdJS модуль
• ES модуль: ECMAScript2015 или ES6 модуль
• ES динамический модуль: ECMAScript2020 или ES11 динамический модуль
• Системный модуль: SystemJS модуль
• Webpack модуль: транспиляция и сборка CJS, AMD и ES модулей
• Babel модуль: транспиляция ES модуля
• TypeScript модуль: транспиляция CJS, AMD, ES и SystemJS модулей

Comparing PHP-FPM, NGINX Unit, and Laravel Octane - what to choose for developing microservices.

Сравнение производительности php-fpm, nginx-unit и laravel-octane - что выбрать для разработки микросервисов.

После выхода PHP7 появилась возможность сравнительно небольшой ценой писать долгоживущие приложения. Для программистов стали доступны такие проекты, как prooph, broadway, tactician, messenger, авторы которых берут на себя решение наиболее частых проблем. Но что если сделать небольшой шаг вперёд, углубившись в вопрос?

Попробуем разобрать судьбу ещё одного велосипеда, который позволяет реализовать Publish/Subscribe приложение.

Привет! Меня зовут Олег Мифле. Одной из команд, где удалось поработать за 7 лет с PHP, стала Customer Support. Мы автоматизировали анализ тысяч задач в день и оператору больше не нужно думать и включать голову для того, чтобы понять, какая задача прямо сейчас важна. О том, как работает приоритизация и что такое дерево игры, расскажу в статье.

На старте погружу в предметную область. Она непростая, но постараюсь быстро. Эта статья по моему докладу с PHP Russia 2022. Вот запись.

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

Эта половина статьи сосредоточится на опыте нашей команды BellSoft. Поговорим о том, каким образом мы взаимодействуем с миром микросервисов: здесь будет и про универсальный Java-рантайм, и про крошечные контейнеры, и про Spring. Я разложу микросервис на слои, соберу в образ, запущу и покажу, что влияет на его скорость.

Слово «микросервисы» на слуху последние несколько лет. Технология активно развивается, на онлайн-конференциях о ней говорят, да и сами мы пишем их каждый день. Когда-то новый подход уже стал рутиной. Но мне как Java-архитектору интересно то, каким код был раньше, как он менялся, какие способы исполнения популярны сейчас и будут использоваться в 2021 году: асинхронность, контейнеры, FaaS. 

Так родился этот пост в двух частях, который я подготовил для Хабра на основе своих статей в блоге компании BellSoft и круглого стола Joker 2020, где мы обсуждали будущее джавы. Актуальное сегодня улучшение экосистемы для бэкендов не может существовать без понимания того, как создавать микросервисы: писать с нуля или вырезать скальпелем из монолитов? Предлагаю в первой части поговорить об их сущности, а во второй — разложить микросервисный контейнер на слои и посмотреть на вклад каждого слоя.

Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

Привет, Хабр! В статье расскажу о том, с какими трудностями можно столкнуться при разработке ORM на PHP и поделюсь опытом по их преодолению.

Рассказывать буду только о том, о чём знаю сам. У вас может быть абсолютно другое мнение. Поэтому если вы нашли ошибку или хотите обсудить — свяжитесь со мной.

Продолжаем публикацию лекций Олега Степановича Козлова по предмету "Управление в Технических Системах".

В этой лекции мы покажем как наши деды без компьютрера и "цифровых двойников" строили ракеты и отправляли человека в космос. Но сначала краткое содержание предыдущих серий:

1. Введение в теорию автоматического управления.2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13. 

3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ РЕГУЛИРОВАНИЯ. 3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ. 3.2. Типовые звенья систем автоматического управления регулирования. Классификация типовых звеньев. Простейшие типовые звенья. 3.3. Апериодическое звено 1–го порядка инерционное звено. На примере входной камеры ядерного реактора. 3.4. Апериодическое звено 2-го порядка. 3.5. Колебательное звено. 3.6. Инерционно-дифференцирующее звено. 3.7. Форсирующее звено.  3.8. Инерционно-интегрирующее звено (интегрирующее звено с замедлением). 3.9. Изодромное звено (изодром). 3.10 Минимально-фазовые и не минимально-фазовые звенья. 3.11 Математическая модель кинетики нейтронов в «точечном» реакторе «нулевой» мощности. 

4. Структурные преобразования систем автоматического регулирования.

5. Передаточные функции и уравнения динамики замкнутых систем автоматического регулирования (САР).

6. Устойчивость систем автоматического регулирования. 6.1 Понятие об устойчивости САР. Теорема Ляпунова. 6.2 Необходимые условия устойчивости линейных и линеаризованных САР. 6.3 Алгебраический критерий устойчивости Гурвица. 6.4 Частотный критерий устойчивости Михайлова. 6.5 Критерий Найквиста.

После этой лекции, даже не имея компьютера, а только милиметровую бумагу вы сможете рассчитать устойчивость любых САР.

В университетские времена я столкнулся с такой математической абстракцией, как конечный автомат (КА). Эта модель была полезна для понимания и создания комбинированной логики. Спустя 15 лет КА вернулся в мою жизнь в виде компонента Symfony Workflow. В этой статье я расскажу, как наша команда при помощи Symfony Workflow улучшила код продукта Links.Sape, переводя его с legacy.

Хотел я написать о багах и разработчиках но подумал, что это никому не надо и напишу о том как я настроил себе удобное место для поиграть на linux.