😁 🚀 Sentry выкатила в ранний доступ инструмент для анализа и визуализации размера мобильного приложения

Теперь используя Sentry можно детально разбирать, что именно раздувает размер сборки, и следить за изменениями прямо на CI — отличный способ не пропустить внезапный +50 МБ к следующему релизу 😅

💡 В блоге показали пример с open source Firefox — разработчикам удалось урезать размер на 67 МБ, просто удалив debug symbols и тестовые базы данных из релизной сборки.

📊 Инструмент позволяет:
1️⃣ анализировать размер бинарей, ассетов и debug-символов;
2️⃣ визуализировать, какие части кода занимают больше всего места;
3️⃣ проверять корректность App Thinning;
4️⃣ подключить инструменты для анализа и минификации ассетов (например imagemin-cli);
5️⃣ насколько понимаю по скринам и на CI можно будет проверку размера прикрутить из коробки.

🧠 После покупки Emerge Tools, Sentry продолжает двигаться в сторону инструментов для глубокой оптимизации мобильных приложений — вспомним их open source проекты:
💀 Reaper (анализ неиспользуемого кода) - писали про него тут.
🔍 FaultOrdering (ускорение старта приложения).

🔗 Подробнее: Sentry Blog — Monitor & Reduce Mobile App Size (Early Access)
📘 Документация: Size Analysis Insights

#L #Sentry #SizeAnalysis #AppSize #Optimizations

👏

🤫 🎯 Мысль на тему первых собеседований и подготовки к поиску работы

Наткнулся на статью Get a job as a junior developer
— автор пишет о поиске первой работы, но многие идеи отлично ложатся и на более широкий контекст.

Главная мысль, с которой полностью согласен:
🧐 👉 не бойтесь проходить собеседования.
Чем раньше начнёте — тем быстрее получите результат.
Не нужно ждать, пока «дорастёте до идеала», чтобы провалить первое интервью.

Прохождение собеседований — это отдельный скилл, который не всегда коррелирует с опытом разработчика.
Опытный инженер может провалить интервью просто из-за усталости или стресса,
а студент — пройти, потому что свеж в голове и ментально готов к конкретным задачам.

😄 Все советы автора — про резюме, портфолио, нетворкинг и присутствие в соцсетях — актуальны и для нашего рынка.

Из личного опыта: я выстраивал процессы найма как минимум в трёх командах, провёл сотни собеседований и сам проходил десятки.
И проведение, и прохождение интервью это два самостоятельных навыка.

📌 Когда-то я сделал mind-map аттестации разработчика — по сути, карту знаний, по которой можно готовиться к собеседованию на любой грейд и в любую компанию.

Думаю, её можно развить в серию постов:
1️⃣ как готовиться к интервью со стороны кандидата;
2️⃣ как выстраивать интервью со стороны интервьюера;
3️⃣ и какие материалы реально помогают подготовиться.

Как думаете, стоит ли развить эту тему и систематизировать подход к подготовке и проведению собеседований?

#L #Interview

👏

😄 💭 Lean Inception и золотая середина MVP

Философский пост в свете последних событий в моей творческой деятельности.
Задумался вот о чём.

Когда бизнесу нужен MVP — срочно, в сжатые сроки, нужно проверить гипотезу — какой минимальный срок и объём функционала мы можем реально поставить?
И с каким количеством технического долга?
Где проходит та самая грань, золотая середина, ниже которой — уже плохо, а выше — просто работа в стол?

Наткнулся на статью в блоге Мартина Фаулера — Lean Inception от Пауло Кароли (создателя термина Lean Inception).

Он описывает, как опытные команды и компании сокращают время старта нового проекта с двух недель до одной.
И эту неделю они называют Lean Inception — время, когда команда формирует видение MVP, договаривается о функционале, сроках и возможностях.
То есть на выходе есть чёткое понимание: какой именно MVP мы делаем, где эта золотая середина, и зачем.

И вот я думаю — это реальность или утопия?
Почему в одних компаниях такие осознанные процессы — это базовый минимум, а где-то это звучит как мечта?

На мой взгляд, всё упирается в направленность компании и её руководство.
В возможность нормальной коммуникации с бизнесом, в зрелость диалога и адекватную оценку результата после Lean Inception (будем считать что таковой имеется).

P.S.:
ИМХО: 🧠 Лучшие IT-бизнесы строят не бизнесмены, а инженеры, ставшие руководителями.
Потому что они глубже понимают, что стоит за решением сделать «ещё чуть-чуть» или «и так сойдёт».
И вот на этом понимании и строится реальный баланс между скоростью, качеством и смыслом.
Ну и коммникация тоже прозрачнее из-за «разговора на одном языке».

#L #LeanInception #Agile #MVP

👏

🚀 Мажорное обновление Homebrew — 5.0!
Команда выкатала крупный релиз, того самого пакетного менеджера, через который многие из нас ставят себе всё рабочее окружение.

Что нового?
⚡ Параллельные загрузки:
Brew теперь скачивает зависимости и пакеты быстрее, по умолчанию.

🛡️ Обновлена поддержка:
Tier 1 = платформы, для которых команда гарантирует полную, стабильную поддержку и на которых тестируется всё.
Теперь в Tier 1 входят:
• macOS на Apple Silicon
• macOS на Intel (пока ещё живёт)
• Linux ARM64/AARCH64 — важный шаг, учитывая рост ARM-серверов и одноплатников.

🧬 Но, определен постепенный отход от Intel/x86_64:
Это ожидаемо: Apple уходит в ARM → Brew синхронизируется.
Поддержка x86_64 остаётся, но уже как наследие, не как главная платформа.

🤖 Появился MCP-сервер:
Homebrew подружился с Model Context Protocol. Это ускоряет интеграцию локальных AI-инструментов с brew.

🔒 Безопасность: важное изменение:
Все cask-контейнеры, которые не проходят проверку Gatekeeper, будут отключены в сентябре 2026 года.
Это серьёзный шаг в сторону безопасности экосистемы: меньше неподписанных бинарей → меньше рисков.

🧰 Какие альтернативы?
Если вы ищете более «мягкого» менеджера инструментов, то обратите внимание на mise.
Он отлично подходит для проектов, где важно стандартизировать версии тулов и держать их рядом с кодом, а не глобально в системе.
Но Homebrew остаётся удобным универсальным вариантом для локальной разработки.

А вы какими пакетными менеджерами или доставщиками инструментов пользуетесь в своих проектах? 👇

#L #Homebrew #CI

👏

😏 Что такое matchedGeometryEffect и зачем он нужен (по мотивам статьи)
matchedGeometryEffect — модификатор SwiftUI, который позволяет двум разным View анимироваться так, будто это один и тот же элемент, плавно переходящий из одного состояния в другое.
Это создаёт ощущение визуальной связности и помогает пользователю понимать, что он продолжает взаимодействовать с тем же объектом.

🔍 Где реально полезно использовать?
- уменьшенное изображение → полноэкранное отображение (изображение как бы «расправляется» в большой размер)

- список → экран деталей (карточка из списка переезжает в новую позицию, а не пропадает и появляется заново)

- cворачивание / разворачивание элементов (например, компактный блок превращается в полноценный контейнер)

(Примеры анимаций можно посмотреть в оригинальной статье)

🛠 Как это работает:

@Namespace private var namespace
@State private var expanded = false

var body: some View {
    VStack {
        if expanded {
            itemExpanded
                .matchedGeometryEffect(id: "card", in: namespace)
        } else {
            item
                .matchedGeometryEffect(id: "card", in: namespace)
        }
    }
    .onTapGesture {
        withAnimation(.spring()) {
            expanded.toggle()
        }
    }
}

Два разных View получают одинаковый id и одно пространство имён.
SwiftUI сам строит между ними плавный переход.

🍕 Что стоит учитывать в 2025:
Этот эффект не анимирует всё подряд. Цвет, прозрачность и скругления могут «перепрыгивать», если их не анимировать отдельно.

Если два состояния слишком разные по структуре, анимация может выглядеть странно.

В больших списках и сложных layout’ах matchedGeometryEffect иногда тяжелеет, так что лучше использовать точечно.

✔️ Когда использовать:
- нужно показать связь между двумя состояниями одного и того же элемента
- важна плавность и понятный переход

❌ Когда проще обойтись без него:
- если нужен обычный fade или scale
- если это два разных view без смысла связывать их визуально
- если layout очень сложный и тяжёлый

🔗 Оригинальная статья

👏

#R #SwiftUI #matchedGeometryEffect #модификаторы

☺️ 🚀 OKR: инструмент эволюции мышления команды, а не KPI
Давно держал эту статью в закладках, решил достать и резюмировать.
Автор - Paulo Caroli (автора Lean Inception — того самого подхода, о котором мы уже писали.
Разбирает ошибки и рекомендации по работе с OKR.
Хочу поделиться тезисами статьи — плюс добавить своё.

🧭 1. OKR не должны спускаться сверху
Частая ошибка компаний — превращать OKR в KPI или чекбокс-менеджмент.
Автор подчёркивает: цели должны создаваться вместе с командой, а не падать на голову как свод правил.

Ориентиры для формулирования:
1️⃣ Какова стратегическая цель организации?
2️⃣ Какая часть стратегии актуальна для нашей команды?
3️⃣ Что мы реально можем сдвинуть в этом квартале?
4️⃣ Как поймём, что движемся? (опять метрики)

Фактически команда должна мыслить так:
«Исходя из того, что мы знаем и на что можем повлиять, вот чего мы можем добиться — и так будем измерять прогресс».P.S.: формулировать цели лучше по SMART, цели отраженные в статье это подтверждают, но сам автор на этом не акцентирует.

🔄 2. Вертикальное и горизонтальное выравнивание
Автор раскрывает важность вертикального и горизонтального выравнивания (между командами), но по опыту главная боль — именно горизонтальное.

Имхо:
🔸 Если менеджмент и команда не синхронизированы, то в целом ОКР не работает;
🔸 Чаще ОКР замыкается в команде и приносит пользу. Но, что сложнее: выстроить именно горизонтальную коммуникацию между командами;
🔸 На первых этапах именно менеджеры должны выравниваться между собой, после срезов внутри команды, а уже потом транслировать корректировки целей в свои команды;
🔸 Идеал: достичь само-организованность команды в том числе в коммникациях со смежникам. Используя стихийный и промежуточный контроль и поддерживая принимаемые командой решения;

📅 3. Регулярные ритуалы важнее, чем кажется
- Дейли → про ежедневный статус по задачам (но легко потерять стратегический контекст).
- Викли → фокус на прогресс по OKR, корректировка курса.
- Ретро → не статус-репорт, а обсуждение проблем и обучающее мышление.

Для статусов автор рекомендует использовать формулу GRIP:
1️⃣ Достигли ли мы того, что планировали?
2️⃣ Что узнали?
3️⃣ Что удивило?
4️⃣ Что сделаем иначе в следующий раз?

Как упражнение-механика для ретро, предлагается «Аттракторы и критики»:
✨ Аттракторы: что нас привлекает в OKR?
🪫 Критики: что отталкивает?

ИМХО: Дебаты в целом классно работают в командах, повышают вовлеченность и также влияют на "сознание команды".
Discussio mater veritas estP.S.: Всегда любил эту цитату. Еще до н.э. Сократ дело говорил

🎯 Вывод
OKR — крутой инструмент.
Но его успех зависит от опытности менеджеров и мышления команды.

Если менеджмент использует OKR как KPI — команда не поменяет подход.
Если же менеджеры формируют цели вместе с командой, связывают с видением компании и ведут честные циклы анализа → команда начинает видеть свою роль в стратегии и расти.

Это и есть настоящая ценность OKR:
Эволюция мышления, а не просто контроль результатов.

#L #OKR #KPI

👏

🏗 Немного не про SUI: хочется поделиться опытом из Satisfactory – и почему это очень похоже на мобильную разработку 😁

Недавно открыл для себя Satisfactory, и чем больше строю фабрики, тем сильнее понимаю, что игра отлично отражает то, чем мы занимаемся в мобильной разработке каждый день.

Для тех, кто не играл: Satisfactory – это про автоматизацию, конвейеры, производство и логику.
По сути – огромный симулятор архитектуры и процессов.

Я играю вместе с другом-продактом, и наше взаимодействие в игре оказалось удивительно похожим на рабочие процессы.

🔧 Этап 1 – Один конвейер, который делает всё
В начале строишь одну гигантскую линию: добыча → переплавка → крафт → сборка.
Работает, но к любому изменению очень чувствителен.
Как приложение, где одна ViewModel делает всё сразу – от сети до бизнес-логики.

🏭 Этап 2 – Отдельные заводы
Понимаешь, что так жить нельзя, и разбиваешь всё на модули:
болты отдельно, провода отдельно, пластины отдельно.
Это уже знакомо – модули, SRP, нормальная архитектура.
Удобно расширять, легче отладить.

📦 Этап 3 – Чертежи
Когда появляются чертежи – игра меняется.
Сделал чёткий работающий блок → сохраняешь → используешь повторно.
Прям как переиспользование компонентов в проекте.
Меньше ошибок, меньше копипаста, быстрее разворачивать новое.

🤝 Игра с продактом
Мы с PM подходим к игре так же, как к проекту:

- Я: «Давай оптимизируем поток, проверим эффективность, подумаем о масштабировании»

- Он: «Давай построим, запустим и посмотрим, что будет»

Оба подхода верны.
Они дополняют друг друга, помогают находить баланс между скоростью и качеством
и отлично работают через итерации, когда можно пробовать, улучшать, переделывать.

Перед строительством нового «модуля фабрики» мы реально обсуждаем – что нужно, как будет взаимодействовать с остальными цепочками.
А после запуска – устраиваем мини-ретро: где узкое место, что можно улучшить, что оказалось лишним.

Полноценная айтишная разработка, только в 3D и на другой планете.

🔄 Этап 4 – Рефакторинг
Через время база превращается в хаос, и ты перестраиваешь всё...
Выравниваешь уровни, перекладываешь конвейеры, чистишь старые решения.
Обычный рефакторинг проекта, который необходим чтобы потом можно было работать дальше.

⚙️ Этап 5 – Масштабирование
Когда порядок наведён, начинается настоящее удовольствие:
всё строится по понятным шаблонам, процессы предсказуемы.
Почти как проект с хорошей архитектурой: он не сопротивляется, а помогает.

🍕 Итог
Satisfactory удивительно точно отражает процессы мобильной разработки:
модули, автоматизация, рефакторинг, масштабирование, разные роли и разные взгляды на приоритеты.
Игра показывает, что хороший «поток» – это не про скорость, а про правильную систему.

🎮 Почему стоит попробовать 😏
Если вы пишите код, Satisfactory – отличный способ
почувствовать архитектуру руками.
Игра учит думать наперёд, проектировать модули, оптимизировать процессы и видеть узкие места там, где их не ожидаешь.

Советую попробовать: игра неожиданно хорошо прокачивает инженерное мышление

#R #модульность #архитектура

👏