Спасибо, за развернутый ответ! Как то так себе все и представлял. Начинаешь внедряь по чуть и чуть и даешь людям почувствовать разницу в реальной работе, что было и как стало)
Как быть, если на проекте полный хаос и все в голове одного-двух людей, а руковдство особо не парится над введением процессов, документации и артефактов.
Как можно им доказать, что это нужно и важно т.к. я чувствую к чему все идет...
Это прям мне удачно Вашу статью в реки закинули, как раз для midsize искал как логи прикрутить.
Помню, до этого, использовал Sentry и всего хватало, того же бесплатного тарифа, но, потом, по всем известным причинам не смог его использовать больше.
Тоже были мысли, нужно что то простенькое бахнуть, без тонны фич и разверток. (да и просто, банальное, "лень")
Мериться и спорить крупностью проектов не буду. Но, говорить, что у меня проекты "маленькие и глупенькие", не стоит. Я, как написал автор, "слона по кусочкам режу". Иногда, проще самому написать код, а иногда лучше написать "доку", разбить ее на части, оперируя бизнес логикой, а дальше...ничем не отличается от ревью МРа джуна. Так что, не знаю. Все эти "поддерживать, оптимизировать и расширять" я понимаю и также придерживаюсь, НО, при этом, ничего не мешает писать код за счет AI, того же cursor. Так что, скажу еще раз: "ИМХО, не только для `холоу ворлдов`" и чуть расширю мысль - такой подход закрывает часть задач, "СВОЕГО уровня" и такие задачи могут быть на ЛЮБОГО уровня и габарита проектов.
За статью спасибо. Очень близко, т.к. действую в той же "парадигме".
В некоторых "узких местах", добавляю псевдокод или оперирую техническими компонентами. Хз как объяснить, зачем именно так, чем это лучше простого написанич кода, кроме как: "я тян - пруфов не будет"
Здравствуйте, спасибо за небольшой пост, очень знакомо и близко. Тоже хочу провести внутренний тех митап по асинхронщине и реактивы.
Правильно я понимаю, что во втором примере у вас были в основном cpu-bound задачи, поэтому обычная многопоточка, которая даёт попроще распарралелить задачи на ядра, дала больше оптимизации, нежели асинхронка, которая больше нацелена на io-bound задачи?
И приходим мы к тому что реактив по сути нужен там, где io-bound, scheduled задачи, которые большинство времени держат потоки в состоянии sleep/wait, а там, где cpu-bound задачи, нам нужен параллелизм через классическую многопотчку в жабке?
Спасибо за статью, очень было полезно узнать, что там ещё есть у Sentry!
Сам открыл для себя Sentry, когда, по большей части, искал инструмент логирования и мониторинга ошибок для небольшого проекта(фронт + бэк), чтобы видеть какие запросы и с каким телом летят).
Спасибо, за развернутый ответ! Как то так себе все и представлял. Начинаешь внедряь по чуть и чуть и даешь людям почувствовать разницу в реальной работе, что было и как стало)
Да это же не мем, это моя жизнь.
Как быть, если на проекте полный хаос и все в голове одного-двух людей, а руковдство особо не парится над введением процессов, документации и артефактов.
Как можно им доказать, что это нужно и важно т.к. я чувствую к чему все идет...
Можете накинуть идей каких то?
Спасибо Вам за статью! За "циферки", подноготную и всю способствующую инфу.
Да, как писали выше, хотелось бы 5ый сервис увидеть, на виртуальные потоки (еще бы сюда nodejs воткнуть, тоже поглядеть 👀)
Отлично, спасибо огромное!
Это прям мне удачно Вашу статью в реки закинули, как раз для midsize искал как логи прикрутить.
Помню, до этого, использовал Sentry и всего хватало, того же бесплатного тарифа, но, потом, по всем известным причинам не смог его использовать больше.
Тоже были мысли, нужно что то простенькое бахнуть, без тонны фич и разверток. (да и просто, банальное, "лень")
А тут Вы :)
Мериться и спорить крупностью проектов не буду.
Но, говорить, что у меня проекты "маленькие и глупенькие", не стоит.
Я, как написал автор, "слона по кусочкам режу".
Иногда, проще самому написать код, а иногда лучше написать "доку", разбить ее на части, оперируя бизнес логикой, а дальше...ничем не отличается от ревью МРа джуна.
Так что, не знаю.
Все эти "поддерживать, оптимизировать и расширять" я понимаю и также придерживаюсь, НО, при этом, ничего не мешает писать код за счет AI, того же cursor.
Так что, скажу еще раз: "ИМХО, не только для `холоу ворлдов`" и чуть расширю мысль - такой подход закрывает часть задач, "СВОЕГО уровня" и такие задачи могут быть на ЛЮБОГО уровня и габарита проектов.
За статью спасибо. Очень близко, т.к. действую в той же "парадигме".
В некоторых "узких местах", добавляю псевдокод или оперирую техническими компонентами. Хз как объяснить, зачем именно так, чем это лучше простого написанич кода, кроме как: "я тян - пруфов не будет"
Не соглашусь с Вами.
Действую по принципу описанному в статье.
Работаю на основном проекте и фриланс проекте.
Flow вполне рабочий, НО, для крупно-габаритных проектов, возможно, нужны улучшения.
ИМХО подход НЕ только для "холоу ворлдов"
Здравствуйте, спасибо за небольшой пост, очень знакомо и близко. Тоже хочу провести внутренний тех митап по асинхронщине и реактивы.
Правильно я понимаю, что во втором примере у вас были в основном cpu-bound задачи, поэтому обычная многопоточка, которая даёт попроще распарралелить задачи на ядра, дала больше оптимизации, нежели асинхронка, которая больше нацелена на io-bound задачи?
И приходим мы к тому что реактив по сути нужен там, где io-bound, scheduled задачи, которые большинство времени держат потоки в состоянии sleep/wait, а там, где cpu-bound задачи, нам нужен параллелизм через классическую многопотчку в жабке?
Спасибо за статью, очень было полезно узнать, что там ещё есть у Sentry!
Сам открыл для себя Sentry, когда, по большей части, искал инструмент логирования и мониторинга ошибок для небольшого проекта(фронт + бэк), чтобы видеть какие запросы и с каким телом летят).