Если вы на Day&Night приходите на доклады еды на первом и втором этажах 🍔

Как использовать Cursor для iOS разработки

AI-шки — наше будущее. Те, кто их не использует уже проигрывают гонку. А те, кто использует неправильно — тупеют 🤤

В ноушене я уже начал собирать отдельный блок с интересными и важными практиками для AI. Я думаю, что ручной кодер по объему и скорости контрибьютинга будет сильно проигрывать даже вайб-кодерам, а тем более инженерам, которые умееют приумножать свой скилл с помощью LLM.

В этой статье отличный туториал по основным моментам:
🟣Настройка среды разработки
🟣Разбор основных функций Cursor
🟣Разные практические применения

Отличная обзорная статья для воскресного вечера

UPD: Есть немного устаревшей инфы по окружению. Некоторые фичи уже объеденены

О контенте про собесы. И как с этим связан Яндекс практикум, Авито, литкод и волки.

Иногда спрашивают почему много контента про собесы. Давайте пройдемся по хронометражу и как я к этому пришел.

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

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

В каждой компании я активно принимал участие в найме. Начиная с мелких компаний, где я был тимлидом, и понимал сколько хороший найм экономит времени или денег. Заканчивая каждой следующей.

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

Тогда последние пол года мы занимались проработкой критериев и наполнением банка вопросов. В итоге база вопросов увеличилась в х5 раз, а шаблон и критерии сильно поменялись. Возможно, ближе к концу года, когда этот шаблон раскатится, иосеры будут его активно обсуждать в кулуарах и считать собесы в Авито самыми жесткими :) кто знает? Но мы искренне старались сделать их полезными. Как это дойдет до прода уже не знаю.

Опыт же Яндекс практикума до этого мне тоже помог. Где методисты сильно душили за каждую статью и требовали после каждой теории давать закрепляющие задачи. А как мотивировать людей их выполнять? Придумывать и миксовать с тем, что спрашивают на собеседованиях. Позже, смотря на процент успеха кагорт, я понял, что теория без практики ничего не значит. Об этом же говорит и таксономия Блума.

Как связан тут литкод? Тут все просто. На литкоде у меня уже ~400 задач, но лучше проходить собесы я не стал. Ну и вы все помните 365 дней Богу алгоритмов. Вся геймфикация литкода основана на игре и челендже. Воспитания умственной дисциплины и тренировки фокуса. Там даже есть отдельные подборки задач под компании.

Ну и волки. Мне искренне хочется работать с сильнейшими сотрудниками. Спорт научил меня, что важна группа, в которой ты занимаешься.

Так мне не хотелось и не хочется, чтобы кто-то из стаи скамеров и балаболов залетел в мою команду. А как сильно это рушит технобренд вам расскажут деврелы. Это как ложка дегтя в бочке с медом. В мусорку пойдет весь труд. В итоге же, критикуя курсы, блогеров и школы за скам, они сами стали худшими скамерами с репутацией накрученных отзывов их менторов (как же херово, что это мои тезки). Пытаясь быть копиями с накрученным скилом ты не станешь оригиналом. А жалкой фальшивкой и худшей копиркой. Ауф.

Так на каждое действие находится противодействие. Чем больше ты начинаешь играть в сомнительные игры, чем больше накапливается долг. Он будет давить на тебя в самые ответственные моменты. Страх быть раскрытым будет отягощать. Это лишняя нагрузка на менталку. Долго так не продержишься. Даже в волчьем сообществе, по их же голосованию, каждый второй из опрошенных страдает синдромом самозванца. Не трудно заметить откуда корни.

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

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

Ну и потихоньку это стало как кроссворды и ежедневные задачи для тонуса.

В каждом развитии вопрос адекватности и честности метрик — критический. Ведь весь твой успех или неудачи могут быть случайными.

Ну и как же без этого — получить самую большую подборку практических задач и вопросов можно тут 😂

Claude Code: Лучшие практики для инженеров

Как уже заметили в комментариях прошлых постов — влияние яндекса меня уже облучило 🧠 Не удивительно, только за эту неделю внутри компании будет >3 внутренних образовательных воркшопов как использовать ИИ для работы.

Считаю ИИ сильным геймченджером. Наступает новая промышленная революция, где старые правила уходят в прошлое. Среди немаленького кол-ва инженеров есть заблуждение, что использовать ИИ — это что-то казуальное и простое. Но это не всегда так. Опыт всех обещаний с SwiftUI, Swift Concurrency, Swift 6, BDUI, KMP нас научил, что если где-то что-то упрощается, то где-то также что-то усложняется. Приходят новые проблемы.

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

В этой статье очередная настройка еще одного инструмента. Claude Code отлично подходит для тех, кто хочет использовать AIшки как трушный инженер — через терминал.

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

💩 Vibe-coding не оправдание говнокоду

Прежде чем обсуждать статью сразу разделим программирование на два термина:
🟣вайб-кодинг, где человек пытается путем комбинаторики подобрать наугад рабочее чужое/сгенерированное решение.
🔘intentional coding — где каждое решение принимается с ясной целью.

Вайб-кодинг был и раньше, до популярности ИИ. Где множество копировало решения бездумно из статей, гугла, стэкоферфлоу или докладов. А процессов принятия решений не было. Менялся лишь источник.

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

Теперь к статье. Автор делится мнением, что бездумное использование пилотов и сам вайб-кодинг приводит к еще большим проблемам на проекте. АИшки в разы увеличивают объемы контрибьютинга, но также приводит и к растущим проблемам. Ускоряется накопление сомнительных решений:

🌟“Vibe coding” != качественная разработка
“Vibe coding” может быть полезен для прототипов или личных проектов, но не подходит для серьёзных, долгосрочных решений.

🌟Необходимость контроля качества
Даже при использовании ИИ важно проводить ревью кода, писать тесты и следовать лучшим практикам разработки.

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

Так что не смотря на уже мощные функции аи-пилоты не такой простой в освоении инструмент. Для эффективного использования потребуется даже больше инженерности, скиллов и насмотренности чем раньше. Тут наш скилл будет уже зависеть от того стиля и подхода программирования, которое мы выберем.

Архитектуры SwiftUI: MVP vs MVVM

Немного отвлеклись на LLM благодаря яндексу, но напомню, что весь этот месяц мы вдумчиво изучаем SwiftUI и собираем полезный роадмап.

Писать про View, HStack, VStack и тп — скучно. Это легко найти в любом туторе, гпт или чатах для новичков. Нужно делиться тем, что стоит за изучением фреймворка и либ — опытом. Здесь я хочу делать акценты на важных вещах для коммерческого разработчика и опыте.

Когда говорят “архитектура” в мобильных приложениях, чаще всего говорят о паттернах, которые помогают организовать логику в UI. Так как именно с ним мы и работаем в 90% задач. Например: MVC, MVP, MVVM и тп.

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

Мы уже прошлись с критикой по TCA. Но почему столько споров вокруг MVVM?

MVVM — один из самых популярных паттернов в SwiftUI. Но есть громкое мнение: "Stop using MVVM with SwiftUI". Потому что:
🟣SwiftUI сам по себе уже привносит много реактивности.
🟣А MVVM, если использовать неправильно, может только усложнить код.

В комментах к прошлому посту даже обвиняли автора в пренебрежении SOLID, DI, CI/CD и других смертных грехах. Поэтому, нужно быть осторожным выссказывая свое мнение, что что-то не нужно.

Что же делать, если у каждой архитектуры тысячи критиков? Слушать самым подходящих нам и основываться на своем опыте 😂

Как же без богов архитектуры из The Essential Developer. Мы уже говорили про них тут, если вкратце ребята работают в фаангах и у них есть самый дорогой курс в iOS за 2500$ про систем дизайн. Когда-нибудь я накоплю бабки и разберу его для подписчиков, а пока делюсь закрытым видосом из их базы.

Скоро ждите отдельную статью в ноушене с разборами архитектур в SwiftUI.

Ну че, неделю я ежедневно кодил фичи и не редко пользовался Cursor.

Давайте поговорим про vibe coding. Где мне было кайфово, а где минус вайб.

За это время на нативке я закодил больше, чем бы за месяц в Авито 🙂 при всей моей любови, но мне там этого не хватало. Я почти все задачи писал на BDUI или бэк на Go, а в Яндексе чистый Swift. Соскучился по нему. Иногда кодинг меня засасывал до двух ночи. Авито отлично подходит качать софты, но с хардами надо чтоб повезло. Инженерно же сложные задачи для меня критически важные, тк в какой-то степени я стал заложником своего блога и историй у костра про технический контент.

Здесь же я чуть изменил свой старый опыт и экспериментировал с пилотами. Тут есть даже чаты поддержки по ним, разрешено пользоваться курсором, но только в private mode и в тех файлах, где нет чувствительных персональных или важных данных. Поделюсь какие вайб трюки мне больше всего помогли.

🟣Начнем с первого вайба: вынесения констант.

Верстка. Верстать я люблю меньше, чем писать сложную логику. В отличии от многих разрабов мне не доставляют кайф анимашки, металы и UI. Я отношусь скорее к этому нейтрально. Мне нравится строить системы или дизайнить архитектуры. Сложность сделанной задачи для меня в объеме и комплексности выбранных решений. И когда появляется что-то, что помогает мне упростить процесс верстки — я сразу этим пользуюсь.

Самое бесявое в верстки это когда ты набросал экран, а потом все константы отступов, разметки и размеров нужно выносить в отдельный enum, структуру или класс со статичными свойствами. Лишняя рутина, которая меня бесила. Это простая, но супер утомительная работа.

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

⭐️ Оценка: твердые 4 вайба из 5.

Решил сделать вайбовые ролики про вайбовые трюки. Уходит на них немного времени, но прикольно.

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

Вкратце, когда одно чувство перестает работать, то все остальные обостряются.

Новый раздел в ноушене: AI & LLM для инженеров в мобильной разработки

Это должно было случиться. LLM и пилоты настолько стремительно вошли в нашу профессию, что многие уже не могут программировать без них. Уж слишком много где упрощений. Это как писать без автоисправлений или обучаться без гугла.

В этом разделе будут пополняться и собираться:
🟣Как и зачем использовать LLM в работе
🟣разбор популярных и не очень пилотов
🟣советы и трюки (рефакторинг, упрощение кода, замена констант и тп)
🟣Минусы вайбкодинга и как можно запороть проект без осознанного использования

А также многое другое. Это огромная тема, которая еще наберет свой пик популярности. Она также требует скиллов и внимательности.

🧬 Получить доступ к разделу и другой контент можно 💰 тут или ⭐️ тут

How to measure productivity?

Очень советую эту статью.

Те, кто работал в Авито, наверное ловят флешбэки от таких слов как output/outcome. На каждом перфоманс ревью вы с вашим лидом оцениваете свою работу. В итоге, он вам помогает определить что полезно, а что нет.

Этот процесс болезненный, но отрезвляющий. Тк тебе нужно понять, что некоторые задачи которые ты делал, не так важны с точки зрения бизнеса, как ты думаешь.

Концепция outcome/output набирает популярность. Колличественные метрики заменяются качественными. Многие перестали считать коммиты, задачи, часы, сторипоинты и начали оценивать конечный результат.

🌟Output — это всё, что физически создаётся в процессе разработки: код, тесты, документация и т.д. Это результат работы команды, но сам по себе он не гарантирует ценности для пользователя.

🌟Outcome — это то, что происходит после того, как Output попадает к пользователю: изменения в его поведении, рост удовлетворённости, увеличение продаж и т.д. Outcome отражает реальную ценность продукта.

Пример: Если вы добавили новую функцию на сайт (Output), но пользователи ей не пользуются, то Outcome равен нулю.

В статье отлично выражено фундаментальное правило:

Продуктивность в разработке — это не количество строк кода, а ценность, которую получает пользователь. Важно стремиться к максимальному Outcome при минимальном Output

🌟 Большая подборка задач на SwiftUI

Месяц заканчивается и впереди майские праздники и отпуска. А я не успел отдать некоторые долги. Поэтому догоняю упущенное.

Подготовил большую подборку важных задач для закрепления теории SwiftUI. Это поможет лучше набить руку и понять базовые особенности фреймворка. Большинство из задач встречаются на реальных собеседованиях:
🌟Решение задач на утечки памяти
🌟Вопросы и задачи по навигации
🌟Вопросы и задачи по перфомансу (оптимизация LazyStack, и тп)
🌟А также практические советы и рецепты по верстке разных элементов (анимации, фильтрация элементов, drag&drop и тп)

Еще больше материала про SwiftUI:
🌟Воркшоп SwiftUI: Оптимизация и перфоманс коллекций часть 1
🌟Большая статья SwiftIU: State, Binding, Observable и частые ошибки
🌟SwiftUI: Подборка лучших задач для изучения часть 1

🧬 Получить это и весь другой контент по щедрой скидке 💰 тут. Проведи майские с пользой

Также ищу желающих провести/пройти мок-собес по SwiftUI

🌟 SwiftUI: AttributeGraph

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

Тогда перейдем в поднаготную SwiftUI. На собесах в СНГ рынке есть такая особенность, что у нас особо никто не любит спрашивать базу, а сразу лезут в кишки. Для меня это спорный подход, но все же быть готовым к нему нужно. Поговорим про AttributeGraph.

AttributeGraph — это закрытый фреймворк SwiftUI. Он отслеживает зависимости между данными и вьюхами.

Когда вы используете свойства, такие как @State, @Binding или @ObservedObject, SwiftUI создает граф зависимостей, чтобы понимать, какие части интерфейса нужно обновить при изменении данных. Вместо того чтобы пересчитывать весь UI, SwiftUI благодаря AttributeGraph обновляет только те части, которые действительно изменились. Это делает апки более производительными.

Понимание работы AttributeGraph помогает:
🌟Избегать лишних обновлений интерфейса.
🌟Оптимизировать данные и вьюхи для лучшей производительности.

Позже сделаю более детайльный пост с инфографикой.

Доп.статьи:
🌟Untangling the AttributeGraph
🌟Making Friends with AttributeGraph
🌟видео objc: Attribute Graph (Part 1)
🌟Demystifying SwiftUI: Attributed Graph