🚀 Мажорное обновление 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 #модульность #архитектура

👏

🤫 Что общего у UITableView и git diff

Когда-то давно, лет 10 назад, у меня была задача: получать пачку данных с сервера, находить различия с кэшем и красиво обновлять UITableView, чтобы не было резких reload'ов, а всё плавно вставлялось, удалялось и двигалось.
Тогда задача обошлась мне, не в один день анализа и проектирования, чтобы научиться сравнивать старый и новый массивы.

Тогда ещё не было никакого CollectionDifference, и я просто пошёл реализовывать алгоритм Вагнера–Фишера и работать с вычислением: расстояния Левенштейна и редакционноого предписания - минимального количества действий и их последовательности чтобы из "ABC" получилось "ACD".

Ну и конечно, всё это руками прикручивалось к performBatchUpdates:

tableView.performBatchUpdates {     
  tableView.deleteRows(at: ...)     
  tableView.insertRows(at: ...) 
}

Весело? Не очень. Но тогда по-другому никак.

Потом, с приходом iOS 13 и Swift 5.1, всё изменилось.
Apple выкатили DiffableDataSource, и вместе с ним — CollectionDifference.
Это была буквально революция, теперь можно просто сформировать снапшот и отдать его таблице:

var snapshot = NSDiffableDataSourceSnapshot<Section, Item>() 
snapshot.appendSections([.main]) 
snapshot.appendItems(items) 
dataSource.apply(snapshot, animatingDifferences: true)

UITableView сама всё поймёт, сама вычислит, что вставить, что удалить, что переместить — и сделает это с анимацией.
А мы — просто передаём новое состояние.

Если копнуть глубже, то под капотом лежит алгоритм Майерса.
Он также находит минимальную последовательность изменений между двумя массивами.

Apple реализует его для CollectionDifference.
Можно глянуть исходники Swift или вот обьяснение алгоритма.

Но если хочется больше контроля или скорости — есть и альтернативы.
Например, DifferenceKit, который использует алгоритм Пола Хекеля.
Вот сам код.
Он быстрее в ряде кейсов, особенно если много данных, на это влияет сложность O(n), бенчмарки можно посмотреть на gh.
И с ним сделали даже backport - DiffableDataSource для старых iOS.

Мораль истории: задача сравнения последовательностей — стара как мир.
Её решают в UI, в git, в текстовых редакторах.
А теперь и мы — наконец-то — можем делать это в UITableView, не теряя нервы на написание сложных алгоритмов и работу с indexPath-ами.

#L #UITableView #DiffableDataSource #CollectionDifference #LevenshteinDistance

👏