В случае использования gzip + коротких классов и id, страницы худели в среднем на 37%, в сравнении с просто отдачей gzip. Чем больше html элементов на странице и/или css классов, тем существенней прирост.
Плюс так же публичного общения в каналах то, что он не позволяет отдельным персонажам хамски себя вести. Одно дело в личной переписке себя вести неадекватно, а другое дело публично...
MySQL может писать в binlog как SQL Statements (Statement-based replication), так и просто измененные данные (row-based replication). Для Statment-based replication сложнее гарантировать детерминированность транзакций и совпадение данных, хранящихся на разных хостах.
Кроме того, существует еще один репликации, а именно mixed, это когда по умолчанию репликация работает в statement, но в случае обнаружения опасных операторов, например, NOW, RANDOM и других, mysql переключится для этих запросов в row based.
Штука прикольная, особенно, где надо добавить немного интерактивности и при этом все рвано надо забирать/отпрвлять данные на бэкенд для синхронизации: формы и админки самое то. Я правда пользуюсь htmlx, так как hotwire только на Rubу, к сожалению
Как правило, мы в начале разрабатываем проект, как модульный монолит. И переходим к сервисной архитектуре лишь, когда в команде появляются люди с другими стэком (например ML разработка) или появляется множество технических задач, которые к бизнес-логике мало имеют отношения (множество способов авторизации).
И в большинстве случаев сервисная архитектура выглядит у нас, как "цитадель" (не помню, кто это придумал) - есть core сервис c бизнес логикой, а в все остальные обслуживающего характера функции вынесены в сервисы: авторизация, SMS/Push уведомления, файловые хранилища и т.д. Взаимодействие, тогда становится простым, а необходимость использовать сагу/хореографию сводится к минимуму.
Насколько я знаю, нативной поддержки нет. Но для решения данной проблемы подойдет любая реализация NFS: от провайдера или вручную установить. Я пользовался GlusterFS:
Мне больше всего нравится, как разработчику, вероятностный метод. С помощью него, хотя бы можно примерно вычислить насколько сильно человек переоценивает свои силы. И использовать эти коэффициенты для корректировки оценок каждого члена команды.
Больше всего ненавижу оценку задач в story point. Мне лично, очень сложно давать оценки в каких-то попугаях, ведь стоимость попугая непонятна.... Задача на 2 дня это 1 бал или 2 балла? А если мы в голове начинаем связывать баллы с каким-то реальными величинами типа времени, то зачем лишняя сущность, неясно. Кроме того, ряд Фибоначчи 1, 2, 3, 5, 8, 13, 21, 34, 55 ... довольно странное решение: сложность большинства задач не настолько сильно возрастает и нужны промежуточные значения, например, между 13 и 21 и т.д. Да, и внешний заказчик вряд ли будет готов принять оценку проекта в поинтах (проект будет сделан за 102 point?!), то есть придется все-равно конвертировать баллы в какую-ту реальную величину.
Третий – ассоциация с IP-адресов авторизованного пользователя. После успешной авторизации в payload токена можно положить какие-то однозначно идентифицирующие сведения о пользователе, например, его IP.
Лучше так не делать, ибо при использовании мобильного инета ip может часто меняться и пользователя будет постоянно выкидывать из авторизации. Можно использовать что-то более стабильное, например, user-agent.
Странно ставить в один ряд NodeJS c Rust/Golang. Последние низкоуровневые и предназначены быть в своем роде заменой для C++ в определенных нишах.
А на Node JS уже есть навороченные фреймворки: NestJS (похож на Spring) или Adonis JS (похож на Laravel) и т.д.
Да, и в эпоху микросервисов и облачных провайдеров не имеет смысла чтобы фреймворк вообще реализовывал все подряд. Зачастую авторизацией и ролями управлять будет отдельный сервис (или облачная служба), а файлы хранить и обеспечивать к ним доступ будет облачный провайдер, а вы будете пользоваться лишь SDK. И так далее.
Очень жаль, было удобно принимать платежи на сайте через WebMoney для маленьких pet-projects.
Печально, все это... Идут похороны Рунета полным ходом: домен RU судя по всему скоро продлевать только через Госуслуги, QIWI и WebMoney "замочили", а Яндекс, Wildberries, Сбер и другие строят интернет в интернете.
В случае использования gzip + коротких классов и id, страницы худели в среднем на 37%, в сравнении с просто отдачей gzip. Чем больше html элементов на странице и/или css классов, тем существенней прирост.
Плюс так же публичного общения в каналах то, что он не позволяет отдельным персонажам хамски себя вести. Одно дело в личной переписке себя вести неадекватно, а другое дело публично...
Более простой пример: один сервис пишет данные в таблицу, а второй читает из нее. Изменили схему таблицу и потенциально сломали один из них или оба.
Ну, это всего лишь частный случай, схема рано или поздно будет меняться.
Кроме того, существует еще один репликации, а именно mixed, это когда по умолчанию репликация работает в statement, но в случае обнаружения опасных операторов, например, NOW, RANDOM и других, mysql переключится для этих запросов в row based.
Спасибо, за статью, буду ждать вторую часть.
Штука прикольная, особенно, где надо добавить немного интерактивности и при этом все рвано надо забирать/отпрвлять данные на бэкенд для синхронизации: формы и админки самое то. Я правда пользуюсь htmlx, так как hotwire только на Rubу, к сожалению
Я купил на прошлой неделе RTX 3070 за 69 тыc. полгода назад она стоила 135 тыс.
А есть какая-нибудь статья на эту тему или замеры?
Как правило, мы в начале разрабатываем проект, как модульный монолит. И переходим к сервисной архитектуре лишь, когда в команде появляются люди с другими стэком (например ML разработка) или появляется множество технических задач, которые к бизнес-логике мало имеют отношения (множество способов авторизации).
И в большинстве случаев сервисная архитектура выглядит у нас, как "цитадель" (не помню, кто это придумал) - есть core сервис c бизнес логикой, а в все остальные обслуживающего характера функции вынесены в сервисы: авторизация, SMS/Push уведомления, файловые хранилища и т.д. Взаимодействие, тогда становится простым, а необходимость использовать сагу/хореографию сводится к минимуму.
Насколько я знаю, нативной поддержки нет. Но для решения данной проблемы подойдет любая реализация NFS: от провайдера или вручную установить. Я пользовался GlusterFS:
https://thenewstack.io/tutorial-create-a-docker-swarm-with-persistent-storage-using-glusterfs/
Мне больше всего нравится, как разработчику, вероятностный метод. С помощью него, хотя бы можно примерно вычислить насколько сильно человек переоценивает свои силы. И использовать эти коэффициенты для корректировки оценок каждого члена команды.
Больше всего ненавижу оценку задач в story point. Мне лично, очень сложно давать оценки в каких-то попугаях, ведь стоимость попугая непонятна.... Задача на 2 дня это 1 бал или 2 балла? А если мы в голове начинаем связывать баллы с каким-то реальными величинами типа времени, то зачем лишняя сущность, неясно. Кроме того, ряд Фибоначчи 1, 2, 3, 5, 8, 13, 21, 34, 55 ... довольно странное решение: сложность большинства задач не настолько сильно возрастает и нужны промежуточные значения, например, между 13 и 21 и т.д. Да, и внешний заказчик вряд ли будет готов принять оценку проекта в поинтах (проект будет сделан за 102 point?!), то есть придется все-равно конвертировать баллы в какую-ту реальную величину.
Да, это опечатка. Спасибо, поправил.
Ощущение, что в основном это говорят те, кто зарабатывает на продаже поддержки k8s в компании. Ну, или пользовались swarm последний раз лет 8 назад...
Лучше так не делать, ибо при использовании мобильного инета ip может часто меняться и пользователя будет постоянно выкидывать из авторизации. Можно использовать что-то более стабильное, например, user-agent.
Очень полезный туториал!
Странно ставить в один ряд NodeJS c Rust/Golang. Последние низкоуровневые и предназначены быть в своем роде заменой для C++ в определенных нишах.
А на Node JS уже есть навороченные фреймворки: NestJS (похож на Spring) или Adonis JS (похож на Laravel) и т.д.
Да, и в эпоху микросервисов и облачных провайдеров не имеет смысла чтобы фреймворк вообще реализовывал все подряд. Зачастую авторизацией и ролями управлять будет отдельный сервис (или облачная служба), а файлы хранить и обеспечивать к ним доступ будет облачный провайдер, а вы будете пользоваться лишь SDK. И так далее.
Очень жаль, было удобно принимать платежи на сайте через WebMoney для маленьких pet-projects.
Печально, все это...
Идут похороны Рунета полным ходом: домен RU судя по всему скоро продлевать только через Госуслуги, QIWI и WebMoney "замочили", а Яндекс, Wildberries, Сбер и другие строят интернет в интернете.
Очень интересная статья, теперь стало ясно как устроены АЭС.
Включение HTTP2 на стороне балансировщика разве не решает проблему ограничения кол-ва подключений?
Это относится и к рассматриваемой либе Structurae’s View