@easy_dev991

Баги в проде неизбежны, и при чем тут тесты

2026-08-08T12:47:25.705Z

6 лет назад, когда я ходил по собесам на джуна/миддла, почти все команды говорили мне, что не пишут тесты, но при этом у них в проде "все ок". Конечно, они просто нагло врали, да и какое дело? Зарплату платят и норм, так ведь? При этом мне хочется видеть в проде меньше багов. Как бы мы ни старались, баги будут в любом случае, разберемся в этом.

И речь в основном будет про автотесты, а не ручное тестирование.

Что я понимаю под багом

Как мобильный разработчик, я называю багом то, что работает неправильно, не работает, или приводит к полной невозможности пользоваться приложением, например:

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

Первые 3 примера часто не считаются критичными, потому что приложение же работает, так?

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

Что я не считаю багом

То, что было сделано по задумке команды (дизайнеры/аналитики/продакты и т.д.). Если чтобы добраться до какого-то меню, нужно пройти 7 кругов ада из бесполезных переходов по нескольким экранам, то это не баг, а "фича". Так кто-то задумал, и разработчик сделал по требованию в задаче.

Или если в приложении используются вырвиглазные цвета, некрасивые иконки/картинки - ситуация та же.

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

Заказчиком, кстати, может быть кто-угодно - это необязательно какой-нибудь акционер или директор, или клиент. Кто-угодно может быть заказчиком в зависимости от ситуации.

Тесты

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

Хотел повеселиться немного, ведь мне такую дичь часто говорили в прошлом)

Unit-тесты

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

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

Команда напрягается и повышает процент покрытия тестами.

И баги снова возникают. Что дальше?

UI-тесты

Начинаем делать UI-тесты, у нас все получается. Да, они выполняются медленнее, чем UI-тесты, но они снижают нагрузку на тестировщиков (если они вообще были и тестировали что-то), уверенность в каждом релизе все выше и выше с повышением процента покрытия UI-тестами.

Но баги все еще возникают. Что дальше?

Больше тестов!

Делаем больше тестов, потому что всегда есть что-то, что можно протестировать. Без шуток. Интеграционные тесты, e2e тесты и прочие страшные названия видов тестов.

Реальность

Выходит новая версия iOS/Android, в которой к чертям ломают что-то давно и стабильно работающее, или просто добавляют что-то новое, что вызывает краш в любом приложении или ломает клавиатуру/модальные окна, да что-угодно.

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

Выходит новый закон или пакет санкций и часть функционала отваливается у части пользователей из-за ip-адреса и т.д.

В чем же проблема?

На мой взгляд тут комбинация факторов, главный из которых - человеческий, а потом все остальное, кому что больше нравится:

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

Человеческий фактор

Перечислю реальные случаи из моего опыта (без имен и компаний), потому что на мой взгляд это отличные примеры:

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

Обстоятельства непреодолимой силы

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

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

Что же делать?

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

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

Нужно спросить себя/команду, можно ли как-то улучшить UX путем написания тестов, добавления дополнительных сценариев в общий список тестов и т.д.

В конце-концов можно автоматизировать многое, если есть желание, и пользователю будет приятнее.

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

Заключение

Спасают ли тесты от багов? Нет.

Нужны ли тесты? Обязательно, если вам важен качественный результат ✅

Как я выбирал андроид-смартфон

2026-07-28T10:47:56.456Z

В предыдущей статье рассказал про свой переход с iOS на Android. В этой расскажу как выбирал смартфон, и что в итоге выбрал.

Критерии

Вспомним iPhone

Пользователь айфона объективно не может иметь большого набора критериев для выбора девайса, потому что айфоны есть всего нескольких типов (раскладушку не считаем, т.к. пока не было релиза):

Маленький (SE/mini)
Стандартный
Pro
Pro Max
Air

На каждой модели будет одна и та же версия системы (iOS), с примерно одинаковым набором багов.

Теперь Android

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

Легкий вес - желательно намного меньше 204гр (мой старый iPhone 13 Pro), потому что не люблю держать в руках тяжелые девайсы (все еще жду макбук про на 16 дюймов весом меньше 2кг)
Нормальный сканер пальцев - не оптический, а ультразвуковой, чтобы мокрые пальцы тоже распознавал (хотя любой сканер пальца все равно хуже, чем Face Unlock в iOS)
Постоянная память не меньше 256гб
Защита не ниже iP68 (кому нужно, чтобы под дождем телефон загнулся?)
OLED-экран 120гц с поддержкой LTPO
Экран с диагональю не больше 6.3 дюймов
Операционная система без рекламы и софта, который нельзя отключить/убрать
Хорошая автономность - не меньше двух дней при моем обычном сценарии использования
Корпус без гигантских шайб и прочих хитровыпендренных штук
Поддержка ESIM
Возможность выбрать цвет корпуса кроме черного/белого (не пользуюсь чехлами для телефона)
Было бы неплохо иметь макро-камеру и оптический зум

С критериями определились (всего-то, да?).

Варианты

Я нашел несколько вариантов, которые по характеристикам меня устраивали:

Motorola Edge 60 Neo (не нашел в продаже)
OnePlus 13s (тяжеловат)
Samsung Galaxy S24/S25/S26

Решил выбирать из самсунгов, потому что по основным моим критериям они прошли.

Выбираю из самсунгов

Выбор оказался не таким сложным, как я изначально ожидал.

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

Внимательно сравнив S24/S25/S26 можно прийти к выводу, что разницы между ними почти нет, и так и есть на самом деле.

Переплачивать за самый новый S26 не было смысла, а в S25 аккумулятор чуть более емкий, чем в S24, поэтому взял S25.

В среднем 26% заряда трачу в день, это примерно 1.5 часа времени с включенным экраном, S25 отлично держит 3 дня с запасом в моем обычном режиме использования

Заключение

Кто бы мог подумать, что при покупке смартфона на андроиде нужной модели может просто не оказаться ни в одном магазине, даже если релиз состоялся в прошлом году? А вот так оно и есть 🙂

Переход с iOS на Android

2026-07-21T18:19:17.450Z

Месяц назад я сменил основной смартфон на андроид, и сейчас расскажу почему и как все прошло.

Без паники!

Для начала успокою своих самых преданных подписчиков: айфон у меня все еще есть - использую его для рабочих задач:

проверить фичу на сборке из testflight (ручное тестирование)
задебажить хитрый сценарий, который возникает на девайсе, но не на симуляторе (по проводу в Xcode)

Причины для перехода

Процесс публикации своих приложений

Я хотел делать приложения, которыми будет приятно пользоваться, и делиться ими с другими людьми, но недавно закрыли последнюю официальную "лавочку" для оплаты подписки разработчика apple, а без этого невозможно опубликовать приложения для iOS во всеми любимом AppStore.

Теперь нельзя оплатить аккаунт со счета оператора связи, а искать новые обходные пути (менять регион аккаунта и т.д.) мне не хочется - я ведь не огромная компания с кучей платных подписчиков или постоянным притоком денег.

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

Тем, кто не публиковал приложения сам, или кто публиковал только несколько сборок, наверное сложно будет представить как это происходит.

Вкратце процесс выглядит так:

регистрируешься в качестве разработчика apple
(делаешь само приложение, что обычно не очень сложно и довольно интересно)
находишь способ оплатить подписку (8990 р/год) - да, не у всех и не с первого раза получалось ее оплатить, и если вы физ.лицо, то никаких встроенных покупок у вас в приложении не будет
заполняешь тонну полей в анкете для создания каждого приложения
загружаешь приложение в кабинет разработчика
отправляешь на модерацию
надеешься, что попадется не стремный модератор
попадается стремный модератор с идиотскими вопросами, ответы на которые есть буквально в той же самой анкете, которую ты уже заполнял ранее
отвечаешь на все вопросы и ждешь, пока модератор соизволит одобрить приложение или задаст еще какие-нибудь идиотские вопросы
в случае успешной проверки приложение через некоторое время появляется в магазине ... или не появляется несколько часов без объяснения причин, или через пару дней появится, ну как повезет

И в целом даже с таким стремным процессом (оформление приложения в кабинете apple, модерация) я готов был мириться, пока схема работала хотя бы в таком виде.

Санкции

Бац - удалили банковские приложения. Бац - удалили еще пачку приложений.

Просто потому что политика, отлично.

Я конечно поразвлекался, пока загружал приложения от крупных компаний через их обходные пути, в том числе приложение РЖД, которое они распространяют через Testflight для обычных пользователей (ни в какие ворота, ну камон), но надоело.

Еще просидел около 40 минут в зеленом банке, пока сотрудник банка с тупым взглядом пытался установить мне приложение, и нифига не получилось.

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

Операционная система

iOS уже не тот. Даже если эта фраза выглядит избитой, то сейчас я для себя это ощутил сполна, когда перешел на iOS 26.

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

Мои требования к айфону стали слишком высокими, потому что я отлично помню iPhone 5s, который классно работал, и не лагал как iPhone 13 Pro.

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

Представьте себе, перенести данные с айфона на айфон мне удалось не с первого раза, когда недавно менял айфон.

Руки кривые? Да, но не у меня, а у тех умников, которые пропустили iOS 26 в продакшен и забили на ручное тестирование (по всей видимости, уже очень давно).

Месяц на андроиде

Процесс переноса данных с айфона на андроид оказался ничем не хуже, чем перенос данных со старого айфона на новый - удалось все перенести со второй попытки (для такой же процедуры с двумя айфонами на iOS 26 пришлось потратить 3 попытки).

Что не понравилось

Сканер отпечатка пальцев

В моем смартфоне ультразвуковой сканер пальца, и это полный отстой по сравнению с face id в айфоне (а ведь еще бывают и оптические сканеры пальца, жуть). Нужно попасть в конкретную зону экрана пальцем, при этом регулярно палец не распознается даже с трех раз. В этом плане пока что андроиды сильно проигрывают айфонам (хотя есть новости о предстоящем добавлении аналога face id, но это где-то в будущем).

Системные приложения и баги

Скорее всего привычка к iOS все еще сказывается - просто не хватает некоторых мелочей, которые были удобны в iOS.

Например, галерея не индексирует фотографии без особых настроек девайса. Через 2 недели после покупки я загуглил как это поправить и за 2 ночи все фото/видео проиндексировались, но некоторые отметили людей с ошибками, а исправить эти ошибки буквально нельзя в стандартном приложении галереи (гугл фото не использую).

Темная тема не включается/выключается по расписанию при смене режима на "сон" и обратно, что является частой проблемой в купленном мной андроиде, и прочие мелкие проблемы.

Что понравилось

Публикация своих приложений

Помните ту дикую инструкцию в самом начале статьи для публикации в аппсторе на iOS?

Тут шагов всего 2:

сделать приложение (спасибо агентам за удобство и скорость в этом деле)
установить себе на девайс (и при желании поделиться со всем интернетом)

Шок-контент!

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

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

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

Сторонние магазины приложений

Я использую f-droid и repostore, и мне очень нравится!

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

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

Автоматизация

У меня в айфоне были 2 "быстрые команды", которые активировались либо голосом (как и любая быстрая команда) через Siri, либо нажатием на ярлык на рабочем столе:

выхожу из дома (для включения блютус + lte, и выключения wifi)
вернулся домой (обратный процесс)

В андроиде эти две команды включаются автоматически без необходимости нажимать на ярлык или выполнять голосовую команду, и это БЕЗ использования геолокации, чудеса!

Самое классное то, что настроить это можно было без хитровыпендренных завихрений приложения "Команды" (iOS), в котором черт ногу сломит (ну серьезно, никогда не любил процесс создания команд, но полезные команды там все же можно сделать) - просто в системных настройках есть раздел "Режимы и сценарии", где можно добавлять любые сценарии и делать это с намного более удобным UX.

А что с карьерой?

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

Заключение

Да, я знаю про предстоящие изменения в политике гугла и надвигающихся осложнениях в установке приложений не из магазина гугла, но что поделать - будем адаптироваться. В любом случае есть еще PWA, так что не пропадем 😅

Если статья соберет больше 5 лайков, расскажу про критерии, по которым я выбирал себе смартфон на андроиде, и что в итоге выбрал ✅

Краткий обзор ponytail

2026-07-12T13:00:08.746Z

Уже больше недели использую ponytail на постоянной основе в opencode, и мне нравятся результаты.

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

Предлагаю прочитать ридми - там есть достаточное количество примеров и описание этого инструмента, а сюда просто скопирую оттуда кусочек:

Перед тем как написать код, агент проводит такой анализ (скриншот из ридми)

Как я это использую

Сценарий 1

В пет-проектах, над которыми давно не работал, использую основную команду /ponytail-audit - эта команда проверяет весь репозиторий, например, проверим SwiftUI-Days:

Now I have a complete picture of the entire codebase. Here's the audit:
yagni ItemSchema.swift + ItemMigrationPlan.swift (157 lines). Three versioned schemas duplicating the model + two custom migration stages that only set optional fields to nil. SwiftData lightweight migration handles this automatically when you just add optional properties. SwiftUI-Days/Models/ItemSchema.swift, SwiftUI-Days/Models/ItemMigrationPlan.swift
shrink BackupFileDocument.swift (217 lines). RawBackupItem duplicates BackupItem with different encode/decode strategy — same 5 fields, two Codable impls. BackupWrapper envelope format + legacy flat array = two parsing paths for one export format. Merge into a single type, drop the legacy path. SwiftUI-Days/Models/BackupFileDocument.swift
yagni Analytics — 4 files (AnalyticsProvider protocol + FirebaseAnalyticsProvider + NoopAnalyticsProvider + AnalyticsService) for one real provider. The protocol has one method and one implementation in production. A single AnalyticsService with a Firebase-only init (or a log closure parameter) replaces 4 files. SwiftUI-Days/Services/Analytics/
yagni SectionTitleView.swift (35 lines). A .bold().foregroundStyle(isEnabled ? .primary : .secondary).frame(maxWidth: .infinity, alignment: .leading) modifier on Text. That's a one-line View extension, not a file. SwiftUI-Days/Screens/CommonViews/SectionTitleView.swift
yagni EditSectionView.swift (30 lines). Used in one screen (EditItemScreen). Inline the SectionTitleView + TextField pair. SwiftUI-Days/Screens/Detail/EditSectionView.swift
yagni ReadSectionView.swift (33 lines). Used in one screen (ItemScreen). Inline the SectionTitleView + Text pair. SwiftUI-Days/Screens/Detail/ReadSectionView.swift
yagni DaysEditButton.swift (13 lines). Button { action } Label(.edit, systemImage: "pencil"). Used in two places; inline Button directly is less code than the file overhead. SwiftUI-Days/Screens/Main/DaysEditButton.swift
yagni DaysDeleteButton.swift (19 lines). Same as DaysEditButton. SwiftUI-Days/Screens/Main/DaysDeleteButton.swift
yagni ItemDatePicker.swift (14 lines). A DatePicker with .bold(). Inline. SwiftUI-Days/Screens/Detail/ItemDatePicker.swift
yagni ItemDisplayOptionPicker.swift (24 lines). A Picker with SectionTitleView. Used in two screens; inline both calls. SwiftUI-Days/Screens/Detail/ItemDisplayOptionPicker.swift
yagni ColorTagFilterSheetState.swift (36 lines). Compute-only struct used by one sheet. The three computed properties + two methods can live in the sheet body. SwiftUI-Days/Screens/Main/ColorTagFilterSheetState.swift
yagni Binding+mappedToBool.swift (21 lines). Single-use extension. Inline init(bindingOptional:) at the call site in AppDataScreen. SwiftUI-Days/Extensions/Binding+mappedToBool.swift
yagni ThemeIconScreen+IconViewModel.swift IconError (10 lines). Single-case error enum. Use a descriptive string instead. SwiftUI-Days/Screens/More/ThemeIcon/ThemeIconScreen+IconViewModel.swift
delete BackupFormat.android case. iOS-only app. SwiftUI-Days/Models/BackupFormat.swift
delete AppDataError.swift (5 lines). Single-case enum used once. Use a string literal. SwiftUI-Days/Models/AppDataError.swift
delete ColorTagFilterSheet+Preview.swift (31 lines). 10 static let constants configuring hue/saturation/brightness/count for previews. The previews call static constants that equal literal numbers — use the numbers directly. SwiftUI-Days/Preview Content/ColorTagFilterSheet+Preview.swift
stdlib Color+Hex.swift body (51 lines discounting preview). Hand-rolled hex-to-UInt64 scanner. Scanner already does scanHexInt64. The bit-shifting color extraction is just CGFloat math that UIColor component accessor already provides. Could halve the line count. SwiftUI-Days/Extensions/Color+Hex.swift
shrink DisplayOption.unitsStyle (20 lines). Switch-picking .full/.short/.abbreviated based on which components are nonzero. This is polish: DateComponentsFormatter auto-selects a reasonable style. SwiftUI-Days/Models/DisplayOption.swift
shrink Item.makeDaysCount creates a new DateComponentsFormatter per call. A static let formatter saves the allocation. SwiftUI-Days/Models/Item.swift
shrink FeedbackSender.platformName — nested function inside a computed var body. Extract or inline. SwiftUI-Days/Services/FeedbackSender.swift
yagni ThemeIconScreen+IconVariant.variantNumber — manual switch self returning 1...7. A @frozen enum with Int raw value gives this for free. SwiftUI-Days/Screens/More/ThemeIcon/ThemeIconScreen+IconVariant.swift
net: -~660 lines, -1 dependency (Firebase could go closure-based but kept), -1 file (BackupFormat.android dead path)

Дальше закидываю этот анализ в другую модель и прошу составить план безопасного рефактора, чтобы ничего не сломать.

Сценарий 2

В процессе работы проверяю конкретный коммит с помощью команды /ponytail-review, например:

/ponytail-review коммит 8e82b6cad16c12c1dcca1574b6908304ef15ccc8

В результате получаю похожий отчет, с которым потом можно работать дальше:

Ponytail review — коммит 8e82b6ca
Ниже только over-engineering, не correctness.
- ColorTagFilterSheetState.swift:1 yagni Целая структура + enum для двух if-else (applyEnabled/resetEnabled/toggledColorHex/resetResult). Всё в 4 строчки в теле view. Удалить файл.
- MainScreenFilterState.swift:11 shrink itemsCountForFilterButton — синоним visibleItems.count. Убрать, заменить на visibleItems.count в isFilterButtonVisible.
- ColorTagFilterSheet+Preview.swift:9 yagni colors1 = 1, colors3 = 3, colors8 = 8, colors30 = 30 — константы, равные числу. Лишние имена. Вставить числа в вызовы.
- docs/doc-main-screen-color-tag-filter.md:1 yagni 78 строк внутренней документации, которая устареет при следующем рефакторинге. Удалить, пока не появился внешний контрибьютор, которому она нужна.
Net removable: ~40 строк

Что с рабочим проектом

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

При этом польза ощутима при выполнении конкретных задач, когда срабатывает проверка на YAGNI из раздела "Как это работает", и получается меньше кода, чем могло бы быть без этих проверок.

Заключение

Это уже пятый инструмент для агентов, который я использую на постоянной основе внутри opencode, а полный список вот: serena, codegraph, rtk, openspec, ponytail, и все складывается очень даже удобно для работы с агентом 👍

Экспорт напоминаний Apple

2026-07-05T10:10:11.486Z

Недавно перешел с ios на андроид и захотел перенести все напоминания из стандартного приложения "Напоминания" на маке/айфоне, но не нашел простого способа как это сделать, поэтому сделал инструмент для экспорта напоминаний.

Проблема

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

Однако эти приложения не позволяют бесплатно экспортировать список напоминаний, чтобы делать потом с ними что-то еще.

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

Я даже поробовал microsoft todo, но мне совсем не понравилось их приложение.

Решение

Нашел бесплатное и неплохое приложение для андроид Tasks.org, и сделал небольшой инструмент на свифте для экспорта из приложения "Напоминания" на макбуке в формат Tasks.org.

Разработку вел целиком с использованием opencode + openspec - рассказывал об этом подходе в предыдущей статье.

Доступные команды в Makefile на момент первого релиза

Как пользоваться

Клонировать репозиторий
Открыть терминал в папке проекта
Выполнить команду make export-tasks-org
Взять получившийся файл reminders_export_tasks_org.json из папки с проектом и импортировать в андроид-приложение Tasks.org
Профит

Выводы

Является ли это решение лучшим? Вряд ли. Единственным? Нет. При этом я сделал его довольно быстро, и было очень легко тестировать прямо на симуляторе в андроид-студии.

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

Удобно ли мне пользоваться приложением Tasks.org на андроиде? Вполне ✅

Было ли удобнее в стандартном приложении "Напоминания" от apple? 💯 Да

openspec в работе

2026-06-27T12:09:21.394Z

Примерно два месяца назад я узнал про openspec, и решил попробовать. Пет-проекты на тот момент были на паузе, поэтому пробовать начал сразу в рабочем проекте. В этой статье покажу как выглядит рабочий процесс с использованием openspec внутри opencode.

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

Установка в проекте

В терминале в папке с проектом выполнил команду openspec init и отметил нужные инструменты (opencode и т.д.)

Выбрал opencode

После нажатия enter нужно перезагрузить IDE, в моем случае - просто завершить сеанс opencode в терминале и запустить его заново

Теперь нужно закоммитить добавленные в проект навыки и команды, чтобы ими можно было пользоваться

Использование в работе

Запускаем opencode и начинаем вводить команду /o

Первые несколько секунд идет загрузка всех команд, а потом в списке появляются новые команды openspec

Новая мелкая фича

Если есть полное понимание, что нужно делать, то можно сразу использовать /opsx-ff - я так делал два раза для мелких задач, где все максимально очевидно и обсуждать нечего, например:

/opsx-ff task1234-toggle

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

Отправляем промпт в работу, и получаем ответ типа такого:

I found existing toggle-related code in the project (reminder settings toggle, filter dialog toggle), but "task-1234-toggle" doesn't tell me what you want to build or fix.
What do you want this change to do? For example:
- Add a new toggle for some feature
- Fix a bug with an existing toggle
- Refactor toggle logic
Describe the feature/fix and I'll create all the OpenSpec artifacts.

Дальше отправляю промпт с кратким описанием фичи (ведь она мелкая):

нужно сделать фичефлаг для настройки возможности включения или отключения экрана с логами для разработчика на экране

Агент какое-то время думает и создает все необходимые документы (артефакты) по задаче:

Окончание работы по созданию документов к задаче

Теперь нужно проверить получившиеся документы самостоятельно (т.к. там действительно немного текста) и при обнаружении нестыковок/ошибок нужно внести правки в документы (вручную или опять же через агента).

После проверки/исправления всех документов можно сразу переходить к /opsx-apply или сохранить прогресс (делаем коммит) и переключиться на что-то еще.

Новая стандартная фича

Если хочется больше контроля над процессом создания документации, или еще не до конца известны все требования для задачи, то есть смысл начинать с команды /opsx-new, например:

/opsx-new task1234-medium-feature

Отправляем этот промпт и получаем ответ:

Here's the summary:
Change: task1234-medium-feature
Location: openspec/changes/task1234-medium-feature/
Schema: spec-driven (4 artifacts)
Progress: 0/4 complete
[ ] proposal ← ready now
[-] design (blocked by: proposal)
[-] specs (blocked by: proposal)
[-] tasks (blocked by: design, specs)
First artifact: proposal.md — establish why this change is needed.
Template:
## Why

## What Changes

## Capabilities
### New Capabilities
- `<name>`: <description>

### Modified Capabilities

## Impact
<!— Affected code, APIs, dependencies -->
Ready to create the first artifact? Run /opsx-continue or describe what this change is about and I'll draft it.

В таком сценарии можно делать все документы по порядку, начиная с proposal, который является кратким описанием задачи для последующей детализации в других документах, напишем промпт с использованием команды /opsx-continue:

/opsx-continue task1234-medium-feature нужно сделать фичефлаг для настройки возможности включения или отключения экрана с логами для разработчика на экране

Отправляем этот промпт и получаем ответ:

Created: proposal.md
Schema: spec-driven | Progress: 1/4
[x] proposal ✓
[ ] design ← unlocked
[ ] specs ← unlocked
[-] tasks (blocked by: design, specs)
What's in the proposal:
- Why: Нет способа просмотреть логи внутри приложения, нужна фиче-флаг для скрытия от обычных пользователей
- Capabilities: dev-log-screen (экран логов) + dev-log-feature-flag (флаг управления)
- Impact: AppSettingsDataStore, Screen, MoreScreen, новый DevLogScreen + ViewModel
Ready to create the next artifact? Run /opsx-continue — I'll draft either design.md or the spec files next.

Теперь читаем proposal, вносим правки при необходимости, и либо продолжаем дальше работу в том же формате с командой /opsx-continue, либо ставим на паузу и переключаемся на что-то другое - главное сделать коммит, чтобы сохранить прогресс.

В нашем случае для примера я "промотаю" создание документов командой /opsx-ff, чтобы показать как работает /opsx-apply:

Агент начал работу

После окончания работы агент предлагает добавить фичу в архив как выполненную

Результат работы - тоггл "Developer logs"

Если тоггл включить, появится новая кнопка Dev Log

А вот и сам экран логов

Представим, что положение тоггла было таким и задумано изначально.

И вот пришло новое требование (ну ничего себе) - нужно тоггл переместить в нижнюю часть экрана. Правим артефакты либо вручную, либо новым промптом (без использования команд /opsx) и снова вызываем /opsx-apply для применения правок в коде:

Успех! Положение тоггла исправлено

Верификация статуса

Бывает, что задача откладывается на неопределенный срок, пока ее тестируют, обсуждают и т.д., и все это время код по задаче не пишется, но возможно меняются документы (вручную или нет, не важно).

Когда к задаче нужно вернуться, то можно проверить статус с помощью команды /opsx-verify, это я и сделал в нашем случае, вот итоги проверки:

No critical issues found.
3 warnings to consider — all minor. The implementation correctly follows all design decisions, covers all requirements and scenarios, and maintains code pattern consistency.
Ready for archive. ✓

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

Когда задачу "приняли" окончательно, ее нужно архивировать командой /opsx-archive:

Archive Complete
Change: task1234-medium-feature
Schema: spec-driven
Archived to: openspec/changes/archive/2026-06-27-task1234-medium-feature/
Specs: Delta specs preserved (new capabilities — no main specs to sync to)
All 4 artifacts complete. All 20 tasks complete.

Вот и все! Работа над задачей завершена, теперь любые доработки нужно делать через отдельные задачи (/opsx-new или /opsx-ff).

Мой отзыв

Мне нравится использовать openspec, потому что:

Стандартизируется рабочий процесс - сначала документация, потом реализация по четкому плану
Появляется документация в удобном формате прямо в папке с проектом, а не где-то далеко в отдельной системе
Удобно отслеживать работу и возвращаться к задаче после длительного перерыва

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

Нюансы

Многое зависит от используемой модели и настроек проекта (в том числе AGENTS.md) - не нужно ожидать классную реализацию плана с нужным стилем/подходом, если агент не знает ничего этого
Даже если проект настроен правильно, нейросеть может ошибиться в составлении документации (например), и потом сделать работу по неправильному плану, поэтому нужно перепроверять документацию и реализацию (как это делать - другой вопрос, кто-то будет сам читать, а у кого-то будут автоматизированные проверки)

Еще раз ссылка на репозиторий openspec, рекомендую попробовать самостоятельно 😉

Краткий обзор RTK

2026-06-08T16:46:02.849Z

Недавно нашёл ещё один полезный инструмент для использования в opencode — RTK (Rust Token Killer).

Устанавливается одной командой, встраивается через hook и автоматом сжимает вывод команд перед тем, как он попадёт в контекст нейросети.

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

RTK перехватывает команды и применяет к ним четыре стратегии:

фильтрацию шума
группировку похожих элементов
обрезку лишнего
дедупликацию повторяющихся строк.

В результате модель получает ровно ту же информацию, но в 3–10 раз меньше токенов.

Примеры

git status

Без RTK (~67 токенов):

On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.serena/
	docs/

nothing added to commit but untracked files present

С RTK (~12 токенов):

* main...origin/main
?? .serena/
?? docs/

Шесть строк превратились в три — при этом полезная информация не потерялась.

git diff

Без RTK (~200 токенов):

diff --git a/Shared SwiftUI Content/100_ScenePhaseExample.swift b/Shared SwiftUI Content/100_ScenePhaseExample.swift
index 3a4b5c6d..7e8f9a0b 100644
--- a/Shared SwiftUI Content/100_ScenePhaseExample.swift
+++ b/Shared SwiftUI Content/100_ScenePhaseExample.swift
@@ -10,6 +10,7 @@ struct ScenePhaseExample: View {
     @State private var isActive = false

     var body: some View {
+        // MARK: - Main Content
         VStack(spacing: 20) {
             Text(isActive ? "Active" : "Inactive")
                 .font(.largeTitle)

С RTK (~40 токенов):

100_ScenePhaseExample.swift: +1
  + // MARK: - Main Content

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

Установка и настройка

С помощью homebrew:

brew install rtk

После установки нужно инициализировать hook для вашего рабочего инструмента:

rtk init -g                     # Claude Code / Copilot (по умолчанию)
rtk init -g --gemini            # Gemini CLI
rtk init -g --codex             # Codex (OpenAI)
rtk init -g --agent cursor      # Cursor
rtk init -g --agent windsurf    # Windsurf
rtk init -g --opencode          # opencode

После настройки для opencode в ~/.config/opencode/plugins/ появится файл rtk.ts, который автоматически будет перехватывать вызовы Bash-инструмента и переписывать команды через RTK.

Заключение

RTK — это один из тех инструментов, которые ставишь один раз и сразу получаешь профит. Буквально за пару минут получаем экономию токенов, которая особенно заметна на длинных сессиях при работе с агентом 👍

Подключаем нейросеть к Xcode

2026-06-05T09:13:54.508Z

Xcode выдает ошибку при попытке подключить kimi

В прошлом году презентовали Xcode 26 с возможностью добавления других провайдеров нейросетей кроме chatgpt/claude, но вот незадача - это не так и просто сделать, если не погуглить дополнительно.

Для сравнения вот как выглядит настройка в Android Studio:

Подключается с первого раза без ошибок, чудеса

Если просто ввести в настройках Xcode те же данные, что в Android Studio, то ничего не выйдет.

Причина проблемы в поле URL: Xcode автоматически добавляет /v1/models или /models к URL провайдера для валидации подключения.

Поэтому нужно удалить часть URL с версией... чтобы Xcode сам подставил ее.

Гениально, не так ли?

Пример корректной настройки для kimi в Xcode

Успешно подключили kimi

Детальный экран подключенного kimi

И чтобы не было подозрений, что я рекламирую kimi для Xcode:

kimi нифига не работает в Xcode

Всем удачных подключений!

Отказ от Icon Composer

2026-04-19T14:01:16.566Z

Если у вас в приложение несколько альтернативных иконок, и все они сделаны с использованием Icon Composer, эта статья для вас.

Или если у вас простая иконка, которая почему-то получает тень или стекло при установке приложения на девайс, эта статья для вас.

Предыстория

В Xcode 26.1 добавили баг при создании сборки приложения - ассеты иконок, сделанных в Icon Composer добавляются в итоговый архив несколько раз, что приводит к заметному увеличению веса приложения. Ссылки на форум: первая, вторая.

Если иконку создать в композере, то она будет выглядеть как и задумано, вот только в итоговой сборке эта иконка будет весить в несколько раз больше, чем нужно. И если в приложении есть альтернативные иконки, то общий вес легко может вырасти в 2 раза для легкого приложения (например, этого).

Обходное решение есть - не использовать композер, и добавлять иконки в приложение старым способом (через ассеты).

Однако для простых иконок это приводит к некрасивому результату:

Иконка приложения с дефолтным градиентом

Простой я называю иконку, которая состоит из двух цветов без градиентов или прозрачности.

Получается, что либо мы снижаем вес приложения и миримся с некрасивой тенью (или стеклом, в зависимости от иконки), либо соглашаемся с повышением веса приложения, и целиком управляем тенями и стеклом (привет, композер)?

Так не пойдет.

Решение

Настройка градиента в фигме - добавляем градиент для иконки, чтобы система не считала картинку такой уж простой для накладывания своих лишних эффектов

Слева старая иконка без градиентов, справа - новая с градиентом. Глазом разницу почти не видно, зато избавляемся от некрасивой тени на экране девайса

Так выглядит новая иконка с незаметным градиентом на экране девайса - без тени и стекла

Результат в мегабайтах

Размер приложения с иконками, сделанными в Icon Composer

Размер приложения после обновления основной иконки и альтернативных

Вес приложения снизился почти на 4 мегабайта!

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

Интересный момент: в темной теме ни стекло, ни дополнительная тень на иконки не накладывается - по крайней мере в счётчике дней так.

Заключение

Если у вас в приложении много альтернативных иконок, или вы используете Icon Composer для создания ваших иконок, то будет здорово вернуться к ассетам и подождать, пока композер починят (а починить его не могут уже больше 5 месяцев).

Зачем заставлять пользователя скачивать лишние мегабайты мусора вместе с нормальным приложением?

Чиним синхронизацию Swift Data

2026-04-17T19:28:53.706Z

В моем iOS-приложении для подсчета дней используется Swift Data и в проекте все настроено для автоматической синхронизации данных между всеми девайсами пользователя в iCloud. Сегодня я починил эту синхронизацию (она давно не работала).

Проблемный сценарий

На одном девайсе создаю запись в приложении, жду, сворачиваю/разворачиваю приложение, проверяю на другом девайсе через минуту - там эта запись не появляется.

Решение

Открываем https://icloud.developer.apple.com/

Жмем CloudKit Database

Выбираем справа сверху настроенный для приложения контейнер и вариант Production

Открываем логи

Находим запись с ошибкой, например так:

Фильтруем по OverallStatus = USER_ERROR и жмем справа синюю кнопку Query

Проверяем схему (типы записей) в development и production

Жмем сюда для development и production по очереди, чтобы убедиться в наличии нестыковок

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

Вот как у меня было в прод-схеме - только один тип записи "Users"

Если найдены нестыковки, и development-схема содержит более актуальные данные, нужно ... опубликовать эти изменения в прод.

Вот как у меня было в дев-схеме (есть нужный мне тип записи "CD_Item"), и тут же выделил слева внизу кнопку для публикации изменений

Перед деплоем можно посмотреть изменения - тут в общем все поля моей модели данных, которая используется в "Счётчике дней" на iOS

После нажатия "Deploy" можно подождать пару минут и повторить тест на проблемном сценарии. У меня проблема была решена через 2 минуты после деплоя актуальной схемы в прод.

Заключение

Когда я в первый раз настраивал Swift Data, то вообще не заглядывал в консоль icloud.developer, не проверял ничего связанного со схемами, и даже статей на эту тему не искал и не читал. Оказалось, настроить синхронизацию с облаком несложно, нужно только знать как это делается 😅

Спасибо интернету! И нейросетям 😉