Витя пишет код
Media is too big
VIEW IN TELEGRAM
🎉 Результаты розыгрыша
🏆4
А есть тут кто-то, у кого проблемы с работой? Расскажите свою историю, вдруг я смогу вам помочь 😌
Скоро скорость генерации будет очень большая, а сама генерация будет очень дешевая ⚡️
Тибо, сотрудник OpenAI, который постоянно сбрасывает лимиты, говорит о том, что через пол года текущий кодекс будет казаться примитивным.
А вообще, чтобы не опоздать от Клоды, ребята из OpenAI свернули с десяток продуктов.
Мы можем наблюдать, что рынок консолидируется в кризис. Почему это происходит.
Начинать новый бизнес это рисковая операция, а вот взять существующий, купить и продать его на текущую базу - это хороший вариант, ведь текущая база уже купила продукт, купит и усиление.
Ещё одна тенденция, которая наблюдается заключается в том, что побеждают те бизнесы, которые делают своих клиентов успешными. Если ваш продукт привел к тому, что ваш клиент стал успешным - это хороший продукт
Тибо, сотрудник OpenAI, который постоянно сбрасывает лимиты, говорит о том, что через пол года текущий кодекс будет казаться примитивным.
А вообще, чтобы не опоздать от Клоды, ребята из OpenAI свернули с десяток продуктов.
Мы можем наблюдать, что рынок консолидируется в кризис. Почему это происходит.
Начинать новый бизнес это рисковая операция, а вот взять существующий, купить и продать его на текущую базу - это хороший вариант, ведь текущая база уже купила продукт, купит и усиление.
Ещё одна тенденция, которая наблюдается заключается в том, что побеждают те бизнесы, которые делают своих клиентов успешными. Если ваш продукт привел к тому, что ваш клиент стал успешным - это хороший продукт
Please open Telegram to view this post
VIEW IN TELEGRAM
Проблема:
В больших проектах сложно сходу понять, где происходит изменение данных, а где только чтение.
UseCase - сценарий использования - у меня лично ассоциируется с бизнес-правилами и изменением данных.
Для сценариев чтения данных UseCase → Service → Repository кажется избыточным, тем более, что данные приходится перекладывать в DTO на границе слоев.
Предложение:
Внести изменения в naming - политику. Добавить поддержку command-query segregation.
FooBarUseCase - то, что записывает, изменяет данные - Command.
BarBazQuery - то, что только читает данные - Query. Любая модицикация бизнес данных запрещена (кроме логов, метрик, трейсинга)
В доменные директории добавляется поддиректорий queries:
apps/
repositories/
services/
queries/
use_cases/
Для Query разрешить получать данные напрямую из репозитория, в обход Service.
В больших проектах сложно сходу понять, где происходит изменение данных, а где только чтение.
UseCase - сценарий использования - у меня лично ассоциируется с бизнес-правилами и изменением данных.
Для сценариев чтения данных UseCase → Service → Repository кажется избыточным, тем более, что данные приходится перекладывать в DTO на границе слоев.
Предложение:
Внести изменения в naming - политику. Добавить поддержку command-query segregation.
FooBarUseCase - то, что записывает, изменяет данные - Command.
BarBazQuery - то, что только читает данные - Query. Любая модицикация бизнес данных запрещена (кроме логов, метрик, трейсинга)
В доменные директории добавляется поддиректорий queries:
apps/
repositories/
services/
queries/
use_cases/
Для Query разрешить получать данные напрямую из репозитория, в обход Service.
Интересно, а что нужно сделать, чтобы открыть свой телеканал? 🧐
PS: вино снова со мной
PS: вино снова со мной
🕊1
Витя пишет код
Интересно, а что нужно сделать, чтобы открыть свой телеканал? 🧐 PS: вино снова со мной
Если что - телеканал это вот https://leva.tv
тут нет практически ничего, вообще ничего, но это целый мать его телеканала!!!!
тут нет практически ничего, вообще ничего, но это целый мать его телеканала!!!!
leva.tv
Телеканал Лёва
Пора, наверное, рассказать про RICH Domain Model. Как делать и зачем оно надо 🙂
❤9🔥3👀2🤔1
OpenAI временно перестали продавать подписки за $200 долларов. Не хватает у ребят пока мощности))
2💩2
🐸 Rybbit — open-source аналитика вместо Google Analytics
Если GA4 раздражает интерфейсом, а Plausible кажется слишком аскетичным — посмотрите на Rybbit. За полтора года проект набрал ~13k звёзд на GitHub и выглядит как редкий случай, когда «опенсорсная замена» реально приятнее оригинала.
Что умеет:
- Базовые метрики: сессии, уникальные пользователи, просмотры, bounce rate, длительность сессии
- Session replay — записи сессий прямо в дашборде
- Воронки, user journeys, retention, кастомные цели
- Кастомные события с JSON-свойствами
- Фильтры по 15+ измерениям
- География в трёх уровнях (страна → регион → город) с картами
- Трекинг ошибок и real-time дашборд
- Организации и неограниченное число сайтов
ℹ️ Почему это интересно:
Работает без cookies — то есть без баннеров согласия и плясок вокруг GDPR. Под капотом ClickHouse, так что на больших объёмах не задохнётся. Разворачивается на своём VPS через docker compose за пару минут, либо берёте облако, если возиться не хочется.
Лицензия AGPL-3.0, стек — TypeScript. Web Vitals, правда, только в платном облаке.
🔗 GitHub: https://github.com/rybbit-io/rybbit
👀 Живое демо: https://demo.rybbit.com/81
Если GA4 раздражает интерфейсом, а Plausible кажется слишком аскетичным — посмотрите на Rybbit. За полтора года проект набрал ~13k звёзд на GitHub и выглядит как редкий случай, когда «опенсорсная замена» реально приятнее оригинала.
Что умеет:
- Базовые метрики: сессии, уникальные пользователи, просмотры, bounce rate, длительность сессии
- Session replay — записи сессий прямо в дашборде
- Воронки, user journeys, retention, кастомные цели
- Кастомные события с JSON-свойствами
- Фильтры по 15+ измерениям
- География в трёх уровнях (страна → регион → город) с картами
- Трекинг ошибок и real-time дашборд
- Организации и неограниченное число сайтов
ℹ️ Почему это интересно:
Работает без cookies — то есть без баннеров согласия и плясок вокруг GDPR. Под капотом ClickHouse, так что на больших объёмах не задохнётся. Разворачивается на своём VPS через docker compose за пару минут, либо берёте облако, если возиться не хочется.
Лицензия AGPL-3.0, стек — TypeScript. Web Vitals, правда, только в платном облаке.
🔗 GitHub: https://github.com/rybbit-io/rybbit
👀 Живое демо: https://demo.rybbit.com/81
GitHub
GitHub - rybbit-io/rybbit: 🐸 Rybbit - open-source and privacy-friendly alternative to Google Analytics that is 10x more intuitive.
🐸 Rybbit - open-source and privacy-friendly alternative to Google Analytics that is 10x more intuitive. - rybbit-io/rybbit
Что мы ожидаем от Unit Lead (ИТ-лидер 3-5 команд)
Главная задача Unit Lead — повышать способность команд решать приоритетные задачи бизнеса: быстрее адаптироваться, завершать больше ценной работы и сохранять качество и надёжность продукта.
Для меня это пять зон ответственности.
1️⃣ Развивать продуктовых инженеров и команды
Помогать людям расти профессионально и понимать бизнес эквайринга. Создавать условия для обмена знаниями и взаимозаменяемости, сохраняя глубокую экспертизу. Поддерживать доверие, сплочённость и самостоятельность команд.
2️⃣ Отвечать за результативность разработки
Обеспечивать прозрачные и достоверные метрики производительности, доступной ёмкости команд, скорости поставки и качества. Добиваться устойчивого улучшения без перегрузки людей. Развивать Agile, Scrum, LeSS и CI/CD в своих командах и продвигать полезные изменения на уровне банка.
3️⃣ Встраивать техническое развитие в продукт
Вместе с менеджерами продукта объяснять технический долг через бизнес-эффекты: снижение рисков и затрат, повышение надёжности, ускорение будущих изменений. Добиваться приоритизации этой работы в едином продуктовом бэклоге, наравне с продуктовыми задачами. Обеспечивать соблюдение согласованных DoR и DoD.
4️⃣ Разрешать межкомандные зависимости и конфликты
Представлять команды в обсуждениях архитектуры, границ ответственности и НМА. Добиваться решений и исполнения договорённостей с другими командами и руководителями, включая CTO. Устранять системные препятствия и помогать командам взаимодействовать напрямую, сохраняя их самостоятельность.
5️⃣ Отвечать за соблюдение SLA продукта
Обеспечивать измерение уровня сервиса, надёжность и готовность продукта к эксплуатации. Организовывать реагирование на инциденты и восстановление сервиса. Добиваться устранения причин нарушений, в том числе в зависимых системах, и включения необходимых изменений в продуктовый бэклог.
ℹ️ Результат работы Unit Lead — команды, которые становятся сильнее и самостоятельнее, устойчиво приносят пользу бизнесу и поддерживают надёжный продукт.
Главная задача Unit Lead — повышать способность команд решать приоритетные задачи бизнеса: быстрее адаптироваться, завершать больше ценной работы и сохранять качество и надёжность продукта.
Для меня это пять зон ответственности.
Помогать людям расти профессионально и понимать бизнес эквайринга. Создавать условия для обмена знаниями и взаимозаменяемости, сохраняя глубокую экспертизу. Поддерживать доверие, сплочённость и самостоятельность команд.
Обеспечивать прозрачные и достоверные метрики производительности, доступной ёмкости команд, скорости поставки и качества. Добиваться устойчивого улучшения без перегрузки людей. Развивать Agile, Scrum, LeSS и CI/CD в своих командах и продвигать полезные изменения на уровне банка.
Вместе с менеджерами продукта объяснять технический долг через бизнес-эффекты: снижение рисков и затрат, повышение надёжности, ускорение будущих изменений. Добиваться приоритизации этой работы в едином продуктовом бэклоге, наравне с продуктовыми задачами. Обеспечивать соблюдение согласованных DoR и DoD.
Представлять команды в обсуждениях архитектуры, границ ответственности и НМА. Добиваться решений и исполнения договорённостей с другими командами и руководителями, включая CTO. Устранять системные препятствия и помогать командам взаимодействовать напрямую, сохраняя их самостоятельность.
Обеспечивать измерение уровня сервиса, надёжность и готовность продукта к эксплуатации. Организовывать реагирование на инциденты и восстановление сервиса. Добиваться устранения причин нарушений, в том числе в зависимых системах, и включения необходимых изменений в продуктовый бэклог.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1