🎃 Полночь.
Пустой офис.
Монитор — единственный источник света.

💻 Xcode завис.
Слишком долго...

На экране появляется надпись:
Cleaning DerivedData…

Ты вздрагиваешь.
Кожа на затылке стынет.
Проект оживает — и будто сопротивляется тебе.

🌀 Indexing. Rebuilding. Re-indexing.
Симулятор падает.
Память исчезает быстрее, чем надежда.
8… 4… 2 ГБ…

Ты решаешь удалить DerivedData вручную.
Но закрываешь Finder — и она появляется снова.
Папка возрождается, как нечто живое.

🕯 Консоль мерцает:
“Preparing build environment…”
Шёпот за спиной.
Ты оборачиваешься — никого.

И тогда ты понимаешь:
в этом аду нет выхода.

В темноте офиса вспыхивает последнее сообщение:
🪦 Build failed.

#R

👏

💻 "жиза", это когда половина рабочих встреч со всей недели, сьехали на рабочую субботу. 😒

#L

👏

👍 🧠 “Specification-Driven Development” и размышления о будущем AI-разработки

Многие из нас, кто работает с AI-агентами, уже не раз задавались вопросами:

«Как структурировать свой knowledge base?»
«Как писать спецификацию и проектную документацию так, чтобы с ней мог работать ИИ?»

И вот отличная статья в блоге Martin Fowler, где разбирается подход Specification-Driven Development (SDD) — создание систем и агентов на основе детализированных спецификаций.
Автор показывает инструменты и практики, помогающие связать описания требований, память, итерации и код, формируя понятный процесс разработки с участием LLM.

Однако важно отметить — термин SDD пока не имеет строгого определения.
Он уже стал зонтичным, объединяя и RAG-сценарии, и агентную разработку, и AutoGen-подходы.
То есть комьюнити пока только нащупывает, что именно значит “разработка на основе спецификаций” и куда она эволюционирует.

Лично я считаю статью полезной прежде всего для расширения кругозора — особенно если вы размышляете над архитектурой ИИ-агентов, памятью и контекстом.
Но насколько далеко мы зайдём, и как будет выглядеть «SDD» через пару лет — пока вопрос открытый 🤷‍♂️

P.S. Особенно с учётом растущего интереса к самостоятельным и независимым AI-кодерам в корпоративных контурах.
На днях, накопал инструмент Continue.dev, который позволяет разворачивать полностью локального AI-кодера с собственной моделью — без зависимости от внешних API.
Пока просто на уровне изучения, может быть попробуем и получится поделиться опытом.

#L #AI #RAG #SDD

👏

👍 🧩 Про модуляризацию и границы между фичами
Чтение выходного дня натолкнуло на статью "Building Modular and Scalable iOS Apps".

Не сказать, что она очень подробная, но она поднимает важные темы:
- слоистость архитектуры,
- правила взаимодействия между модулями,
- DI и тестирование в контексте модульной структуры.

Я несколько лет назад писал цикл статей про модуляризацию — вот одна из них:
Там я подробнее разбирал вопросы, связанные с build critical path, графом зависимостей, подходом API/Impl, и тем, как всё это влияет на скорость сборки и масштабируемость архитектуры.

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

#L #Arch #Modularity #apiimpl

👏

😒 ⏳Как ускорить сборку в Xcode и перестать ждать часами

🔗 Статья: How to speed up Xcode build time

Основные идеи:

1️⃣ ИМХО, самая важная - использовать Build Time Summary (и его ассистента/визуализатора) — мощный встроенный способ увидеть узкие места на сборке, для того чтобы принимать решения не вслепую.
Для детализации на CI: попробуйте xclogparser или xcode-build-times.
Как уже не раз говорил, наблюдаемость и инспекция - наше все и то с чего всегда стоит начинать.

2️⃣ Проверить флаги сборки, оптимизации и параллельные билды.

3️⃣ Правильно чистить DerivedData — мы недавно подробно писали об этом тут.

4️⃣ Компилировать только, то что нужно для текущего запуска:
Автор предлагает проверить конфигурацию схемы.
А я бы предложил в том числе, смотреть на уровне исходников и анализа компиляции, например: исключать моки из сборок для Debug-а, если вы их модуляризуете.

5️⃣ Тоже имба в случае верной настройки:
input/output files в кастомных скриптах/фазах сборки (например, для SwiftLint: настройте фазу и используйте параметры --use-noscript-input-file-lists и --cache-path) — чтобы Xcode не перезапускал всё подряд, на каждом прогоне.

💡 От себя также добавлю:

1️⃣ Bitcode — мёртв. Apple официально отключила его поддержку с iOS 16 (см. release notes), поэтому можно смело его выкидывать из головы.

2️⃣ Оптимизация графа зависимостей: через API/Impl, Dependency Inversion и контроль build critical path — мощнейший рычаг (я писал об этом здесь).

3️⃣ Build cache (локальный или remote) — просто имбовый импакт на многомодульном проекте.

🔥 В сумме это всё может дать десятки процентов прироста при правильном использовании.

#L #Xcode #CompileTime

👏

☺️ 💻 Ваш MacBook vs время сборки: что реально влияет?

Занимаемся сейчас апдейтами процесса анализа время сборки на компьютерах разработчиков и на CI.
Да и вчерашний пост, про время компиляции хотелось бы развить.
Поэтому чуть мыслей еще своих:

Недавно сравнивал время сборки на двух маках, и заодно посмотрел, что говорят бенчмарки.

💡 Существует интересный бенчмарк компиляции синтезированного, но около, реального проекта:

💻MacBook Pro 14" (2023, M2 Pro, 10-core, 16 ГБ RAM)
— средний результат по XcodeBenchmark ~119 сек.

💻MacBook Pro 16" (2023, M3 Pro, 12-core, 36 ГБ RAM) ~134 сек
В идеальных услвоиях прирост небольшой, но реальная разница может ощущаться в реальных условиях. Так, в моем кейсе проблемы были из-за памяти.

❓ Что подтверждают бенчмарки (цифры осознанно усреднены):
- переход с M1 → M2 даёт ~10–15% прироста;
- M2 → M3 — ещё +10–20% в зависимости от конфигурации и RAM.
При одинаковом объёме оперативной памяти отрыв между поколениями минимален.
Решает не только CPU, но и стабильность под нагрузкой, на что может влиять: RAM, тех процесс (на M3 - 3нм), sustained performance per watt.

🧠 Про память:
Если Xcode, Slack, Zoom, браузер и антивирус живут одновременно — 16 ГБ быстро заканчиваются, macOS уходит в swap и сборка резко замедляется.
Не раз читал, что при unified memory (в M-чипах работает как общая шина между CPU/GPU), нехватка RAM мгновенно сказывается на производительности.
📎 Apple Silicon memory architecture

❗️ Вывод
Количество ядер, тех процесс, количество RAM - каждый из параметров важен.
Нельзя создавать узких горлышек нагружая свою рабочую машину.
Так при исчерпывании RAM можно, как в моему случае столкнуться с проблемами и тратить время на анализ. 👍 
Следите за процессами, которые могут отъедать память, если хотите предсказуемое время сборки и комфортный DX.

P.S.: Отдельно можно говорить про скорость SSD и другие параметры, может сталкивались с другими проблемами и есть решения?

#L #Macbook #UnifiedMemory #Benchmark #CompileTime

👏

🤔 🧠 А что откликается у вас?

Наткнулся на статью о жизни с СДВГ.
Без клише, без «мотивационных советов» — про то, как это чувствуется, когда ты или твои подопечные в IT и необходимо «держать фокус».

1. Гиперактивность.
2. Невнимательность, когда теряешь мысль посреди задачи или выключаешься из разговора.
3. Гиперфокус (обратная сторона п.2) когда настолько погружен в задачу, что сложно переключится на что-то другое, в том числе, на внимание к себе и близким.
4. «Паралич задачи», когда даже простое действие кажется непреодолимым.
5. «Временная слепота», когда теряешь ощущение часов.
6. «Низкая самооценка», из-за особенностей взаимодействия с людьми с самого раннего возраста.

Читаешь — и понимаешь, что многое из этого, должно быть знакомо даже тем, кто без диагноза.
По крайней мере у меня отликается чуть ли не каждый пункт.
Иногда мы просто перегружены контекстами, уведомлениями, ожиданиями.
Но где-то между этим всем теряется простая штука — внимание к себе.

P.S.: Нащупывается важная тему, где техника в IT встречается с эмпатией и people-management-ом.
Если пост найдет отклик, можно будет погрузится в особенности работы с людьми, включая учёт личных характеристик, при планировании и коммуникации.

#L #Management #Teamwork #СДВГ

😄 🧭 Что такое технологический радар и зачем он нужен разработчикам

Когда технологий становится слишком много — языков, фреймворков, библиотек, инструментов — легко потеряться. Именно поэтому команды всё чаще создают технологический радар (Tech Radar).

Концепцию популяризировала компания ThoughtWorks, у которой регулярно выходит публичный Technology Radar

🚀 Что это такое?

Tech Radar — это карта технологий компании.
Она помогает понять:

• Какие технологии мы уже используем
• Какие пробуем
• За какими следим
• И от каких лучше отказаться

Выглядит это как диаграмма с секторами и кольцами.
Например:

• Сектора: Languages & Frameworks, Tools, Platforms, Techniques
• Кольца: Adopt, Trial, Assess, Hold

💡 Зачем нужен тех радар?

• Создаёт единое техническое видение для всех команд
• Помогает приоритизировать эксперименты
• Делает прозрачным, почему выбрана та или иная технология
• Борется с техническим долгом — видно, что пора заменить или вывести из использования

⚙️ Как использовать?

• Обновляйте радар раз в квартал
• Обсуждайте его на технических встречах
• Используйте как ориентир для развития команды и найма
• Ведите историю изменений — это покажет эволюцию технологического стека

📍 Итог: Tech Radar — это не просто таблица. Это инструмент осознанного выбора технологий и стратегического развития. Он помогает не гнаться за хайпом, а строить системную, зрелую инженерную культуру.

#D #Architecture #BestPractices #TechManagement

👏