{"version": "https://jsonfeed.org/version/1.1", "title": "Душный JonFir", "home_page_url": "https://t.me/that_jonfir", "feed_url": "https://tg.davvie.com/static/that_jonfir.json", "description": "Душный JonFir", "items": [{"id": "https://t.me/c/2107544821/66", "url": "https://t.me/c/2107544821/66", "title": "Неизолированная изоляция. #swift Я перечитал всю документацию по Swift Concurrency от корки до кор", "content_html": "Неизолированная изоляция.

#swift

Я перечитал всю документацию по Swift Concurrency от корки до корки, залез в исходники Swift, сделал курс и пару докладов на эту тему. Думал, что знаю про неё всё, что только можно. Но плотно поработать с ней в продакшене раньше не доводилось.

И вот завёл я пет-проект, где решил использовать самые новые технологии. Конечно, он весь на Swift Concurrency, без какого-либо GCD, локов и всего такого прочего.

И тут натолкнулся на интересный кейс.

Написал класс для уведомления подписчиков актора:

(упрощённая, не рабочая версия)


    
        
public final class Observers<T> where T: Sendable {
    private var observers: [Observer<T>] = []

    public func notify(_ value: T) async {
        for observer in observers {
            await observer.value?.callback(value)
        }
    }
}
{}


И использовал его в акторе:


    
        
actor Provider {
    func set(_ string: String) async {
        await observers.notify(string)
    }
}
{}


Согласно доке, notify — это просто асинхронный метод без конкретной изоляции. В моём понимании он должен наследовать изоляцию по call stack’у.

Так как экземпляр Observers используется только внутри Provider и не помечен как Sendable, я ожидаю, что он:

а) не сможет безопасно покинуть Provider;
б) его методы будут наследовать изоляцию Provider, так как вызываются только из этого актора.

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

Я знатно удивился и пошёл искать решение. А нашёл аж целых два.

1. Передать изоляцию явно через isolated


    
        
public func notify(_ value: T, isolatedBy actor: isolated Actor) async {
    observers.removeAll { $0.value == nil }

    for observer in observers {
        await observer.value?.callback(value)
    }
}
{}


И вызываем с передачей self:


    
        
await observers.notify(string, isolatedBy: self)
{}


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

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


2. Включить SWIFT_APPROACHABLE_CONCURRENCY

Я вспомнил про флаг компиляции SWIFT_APPROACHABLE_CONCURRENCY. Я читал о его влиянии на nonisolated методы актора, но решил проверить, как он повлияет на мою ситуацию.

И с SWIFT_APPROACHABLE_CONCURRENCY = YES мой изначальный код заработал так, как я и ожидал. То есть notify начал наследовать изоляцию без всяких isolated и прочих приседаний.

Вот такие особенности современной разработки на Swift.

Как будто бы Apple исправляет свои баги, внося усложнения в язык.", "date_published": "2025-11-18T18:34:09+00:00"}, {"id": "https://t.me/c/2107544821/65", "url": "https://t.me/c/2107544821/65", "title": "Код как хранилище знаний Есть у нас в индустрии такая вещь, как «самодокументируемый код». Это код,", "content_html": "Код как хранилище знаний

Есть у нас в индустрии такая вещь, как «самодокументируемый код». Это код, который написан так, что с первого взгляда понятно, что он делает.
Я же сильно сомневаюсь, что такой код вообще существует.

Конечно, понятность кода — вещь не бинарная. И user.auth_token = "123" несомненно понятнее, чем a = "123".

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

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

Для примера: в моём текущем проекте в кодовой базе 31 848 сущностей называются key. Что это за ключи — понять очень сложно.
Или вот другой пример — из одного из моих прошлых проектов: класс AccountProvider с методами invalidateToken, tryRemoveToken, resetAccount, logout. Попробуйте понять из названий, что они делают. Думаю, у вас не выйдет. На самом деле даже читая код этих методов, не очень понятно, какой будет результат их вызова.

Можно сказать, что люди просто плохо назвали методы и разложили их по классам. Такая проблема действительно существует, но нужно понимать: у человека в голове был свой контекст — он дал название в соответствии с ним. У других этого контекста нет.
А ещё мы помним, что это большой проект, и людей в нём много. Код постоянно пишется, меняется, сроки горят. Никто не будет проводить анализ тысяч строк кода, чтобы понять, как лучше назвать метод, а затем рефакторить код, который всё это затронет. Это долго, сложно, требует тестирования и кучи ресурсов.

В итоге мы имеем кодовую базу, в которой невероятно трудно ориентироваться, и «самодокументируемый код» по большей части не работает.

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

К этой проблеме добавляется ещё одна: нельзя полагаться на современные инструменты. IDE не может найти все вызовы метода, потому что не справляется с таким объёмом кода. А связанные методы могут быть вообще в другом микросервисе.

Выше я писал, что в моём проекте 31 848 сущностей называются key. Как я могу узнать, где используется конкретно нужный мне key? Только путём тщательного анализа кода. Сколько времени потребуется, чтобы изучить все 31 848 мест? Очень много.

Что же с этим делать?

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

А при работе с кодовой базой — давать всем сущностям длинные и уникальные имена. Например:


    
        
AuthModule (имя модуля)
    └── AuthModuleAuthFeature (имя фичи)
          └── AuthModuleAuthFeatureAuthStorage (имя класса)
                └── AuthModuleAuthFeatureAuthStorage.authModuleAuthFeatureAuthStorageLoadUserIdFromDisk (имя метода)
{}


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

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

И, наконец, вишенка на торте — с таким кодом намного проще работать LLM-агентам, которые, по сути, и читают код как обычный текст.", "date_published": "2025-10-22T07:07:29+00:00"}, {"id": "https://t.me/c/2107544821/64", "url": "https://t.me/c/2107544821/64", "title": "Не нужно писать код по ощущениям #Философское Я часто замечаю за собой (и за другими разработчикам", "content_html": "Не нужно писать код по ощущениям

#Философское

Я часто замечаю за собой (и за другими разработчиками), что мы оцениваем код по ощущениям.
Не по фактам, не по метрикам, не по статистике — а просто по внутреннему чувству «это хорошо» или «это плохо».

- Пример 1
Реализовал задачу — всё просто, минимально, работает.
Потом требования поменялись, и теперь нужно сделать сложное решение.
Переписываешь и думаешь: "Надо было сразу делать сложнее, не пришлось бы сейчас всё ломать"

- Пример 2
Пишешь новый класс, раскладываешь код по мелким функциям.
Каждая делает что-то одно, красиво, аккуратно. Ты доволен — всё читаемо, всё чисто.

А потом проходит время, и другой человек открывает этот код.
У него другая задача, другие приоритеты, и его «план в голове» не совпадает с твоим.

Чтобы внести правку, ему приходится читать все твои методы, пробрасывать параметры, искать, где что меняется.
И вот уже твоя красивая декомпозиция превращается в «говнокод».

- Пример 3
Нужно поменять вызов метода в 500 местах.
В каждом — добавить новый параметр. Боль, страдания, желание переписать всё.
Кажется, что код ужасен.

Но если посмотреть на реальность — этот метод за 10 лет проекта менялся всего один раз.


Почему «по ощущениям» — не инженерный подход

Код — это не произведение искусства, а инструмент.
Когда мы оцениваем его «на вкус», мы игнорируем контекст и статистику.

Возьмём пример с простым и сложным решением:

- Сначала сделали простое — потратили 0 времени.
- Потом переписали на сложное — потратили N времени.
- В сумме — N времени.

А если бы сразу сделали сложное? Тоже N. Мы ничего не потеряли.

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

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


Что я хочу сказать

То, что «ощущается» как хороший код, не всегда хорошо в долгосрочной перспективе.
И наоборот — то, что сейчас выглядит «кривым», может быть оптимальным решением в реальном контексте проекта.

Инженерия — это не про ощущения.
Это про данные, частоту изменений, стоимость поддержки и конкретный контекст.

Красивый код — не тот, который приятно писать.
А тот, с которым удобно жить.", "date_published": "2025-10-16T12:47:44+00:00"}, {"id": "https://t.me/c/2107544821/62", "url": "https://t.me/c/2107544821/62", "title": "Поиск сетевого запроса в приложении #iOS Представьте что вам нужно найти место в коде, где происх", "content_html": "Поиск сетевого запроса в приложении

#iOS

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

С помощью брейкоинтов.

Ставим бряк символ:

-[NSURLSessionTask resume]

Добавляем в кондишен условие:

(BOOL)[[[((NSURL *)[((NSURLRequest *)[((id)$arg1) originalRequest]) URL]) absoluteString] uppercaseString] containsString:[@"some_string" uppercaseString]]

где some_string - строка которая содержится в url искомого запроса.

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

И да, узнать информацию о запросе можно вот такой командой в отладчике

po [((id)$arg1) originalRequest]", "date_published": "2025-07-11T09:53:25+00:00"}, {"id": "https://t.me/c/2107544821/61", "url": "https://t.me/c/2107544821/61", "title": "Когда работаешь с LLM очень важно уделять внимание промпту. От этого зависит как будет решена задача", "content_html": "Когда работаешь с LLM очень важно уделять внимание промпту. От этого зависит как будет решена задача. Промпт может быть специфичен задаче, проекту, языку, фреймворку, а может быть довольно общий.

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

Rule 1 (Limit Quantity):
Use the fewest number of components necessary—variables, functions, classes, or external dependencies. Simplify by eliminating anything not essential to fulfilling the requirements.

Rule 2 (Minimize Variability):
Avoid complex control flows such as deep branching, excessive conditionals, or multiple behavioral paths. Aim for linear, consistent logic with minimal surprises.

Rule 3 (Optimize for Execution Time):
Among functionally equivalent options, prefer the one with better performance. Prioritize faster solutions that do not compromise correctness.

Rule 4 (Use Known Constructs):
Leverage standard libraries, established patterns, and widely understood algorithms. Avoid unconventional or overly clever solutions unless clearly justified.

Rule 5 (Maximize Clarity):
Write code that is straightforward and understandable to a mid-level developer. Strive for obvious behavior, intuitive naming, and clear structure.

Rule 6 (Prioritize Readability and Predictability):
Choose forms and patterns that are easy to follow. Avoid implicit behavior or overly compact syntax that may confuse readers.

Rule 7 (Minimize Abstractions per Function):
Restrict the use of layers of abstraction within a single unit of functionality. Keep each function or module as direct and concrete as possible.

Rule 8 (Prefer Low Coupling, Ensure High Cohesion):
Design components so that they are self-contained and focused on a single purpose (high cohesion), while minimizing dependencies and interactions with other components (low coupling). This improves modularity, testability, and maintainability.

Rule 9 (Minimize Cognitive Complexity):
Write code that is easy to read and understand by reducing structural and nesting complexity. Avoid deep nesting, frequent breaks in control flow (such as loops, conditionals, switches, exceptions), and overly compact or terse syntax. Favor a linear, top-to-bottom logic structure that minimizes mental burden for the reader. Aim for intuitive design over clever shortcuts.

Rule 10 (Use Minimal Available Scope):
Limit the scope of variables and functions to the smallest context in which they are needed. Declare identifiers as locally as possible to avoid unintended interactions and make the code easier to reason about.

Rule 11 (Analyze Before Use):
Before using any project-specific class, method, or component, read and understand how it works. Do not assume intent or behavior—consult the implementation and any available documentation or usage examples.

Rule 12 (Trace Data and Control Flow):
When analyzing code, follow both data flow (what gets passed and modified) and control flow (how the logic moves). This ensures accurate understanding of side effects, dependencies, and responsibilities.

Rule 13 (Understand Contracts and Constraints):
Identify and respect any assumptions, preconditions, postconditions, and invariants defined explicitly or implicitly by the code you're analyzing. This helps you use the components correctly and safely.

Rule 14 (Avoid Blind Integration):
Never integrate or rely on code you don’t understand. Doing so risks introducing subtle bugs or misusing abstractions. Take time to understand the purpose and limitations of reused logic.", "date_published": "2025-07-04T06:15:37+00:00"}, {"id": "https://t.me/c/2107544821/60", "url": "https://t.me/c/2107544821/60", "title": "AI тулы растут как грибы, нашёл "курсор" для терминала. https://forgecode.dev", "content_html": "AI тулы растут как грибы, нашёл "курсор" для терминала.

https://forgecode.dev", "date_published": "2025-06-27T17:05:07+00:00"}, {"id": "https://t.me/c/2107544821/59", "url": "https://t.me/c/2107544821/59", "title": "Диплинки в телеграмм чаты В последнее время стало сложно ориентироваться в рабочих чатах в Telegram", "content_html": "Диплинки в телеграмм чаты

В последнее время стало сложно ориентироваться в рабочих чатах в Telegram. Я решил сделать себе каталог, где все чаты удобно разделены по категориям, чтобы всё было перед глазами и в одном месте — в Obsidian.

Самое сложное было понять, как открывать нужные мне чаты. В итоге я нашёл deeplinks:

* tg://privatepost?channel=<id> — открывает приватный чат;
* tg://privatepost?channel=<id>&thread_id=<id> — открывает приватный чат с топиками;
* tg://resolve?domain=<name> — открывает пользователя, публичный чат или канал.

ID приватного чата легко узнать, если включить галочку "Показывать ID чатов в профиле".", "date_published": "2025-06-27T09:05:50+00:00"}, {"id": "https://t.me/c/2107544821/58", "url": "https://t.me/c/2107544821/58", "title": "Мы с товарищами-блогерами решили раскрутить трафик, рассказать миру друг о друге и собрали для этого", "content_html": "Мы с товарищами-блогерами решили раскрутить трафик, рассказать миру друг о друге и собрали для этого специальную папку с каналами.

Внутри — несколько каналов на iOS-тематику, но с разными авторами и контентом. Заходите, смотрите — возможно, найдёте что-то интересное для себя!

Папка с каналами", "date_published": "2025-06-20T09:37:45+00:00"}, {"id": "https://t.me/c/2107544821/57", "url": "https://t.me/c/2107544821/57", "title": "Увидел топовую футболку про старейшину, решил узнать как бы звучал техлид -"Главный кузнец кодо", "content_html": "Увидел топовую футболку про старейшину, решил узнать как бы звучал техлид -"Главный кузнец кодового горна" (если представить, что программирование – это ковка железа, а техлид – старший кузнец).

Попрошу занести в трудовую книжку
\"media\"/", "date_published": "2025-06-20T05:11:57+00:00", "attachments": [{"url": "https://tg.davvie.com/static/-1002107544821--57-0.jpg", "mime_type": "image/jpeg"}]}, {"id": "https://t.me/c/2107544821/56", "url": "https://t.me/c/2107544821/56", "title": "Уже почти век назад психолог Джордж Келли описал понятие аккумулятивного фрагментализма — это, если ", "content_html": "Уже почти век назад психолог Джордж Келли описал понятие аккумулятивного фрагментализма — это, если совсем просто, такая картина мира, в которой человек не ищет цельного понимания, а просто собирает маленькие кусочки опыта, не особо заботясь о том, чтобы они как-то стыковались друг с другом. Типа «вот тут я решил вот так — сработало», «тут не сработало — ну и ладно», «а вот это вроде умная мысль — пусть полежит, может, пригодится». Получается не мозаика, а свалка. Но уютная. Как балкон в старой хрущевке. По сути, Келли описал клиповое мышление за четверть века до Тоффлера.

Примерно так сегодня и управляют. Только это называется «аджайл». Или, в особо тяжёлых случаях, «product mindset». Клиповое мышление в менеджементе — это не баг, а признак кризиса смыслов позднего модерна, маскируемый под гибкость. Когда ты не строишь стратегию, потому что «мир слишком быстро меняется». Зато строишь дашборд. Ты не думаешь о целях — ты просто очень быстро реагируешь. Причём на всё. Метрика упала — фиксим. Конкурент выпустил фичу — копируем. Часто мелькает в новостях что-то про «GPT» — срочно внедряем.

В итоге всё управление сводится к крафту несвязанных между собой решений, каждое из которых кажется разумным в моменте. Главное, чтобы каждое решение сопровождалось презентацией. Ну и лучше — графиками. Всё остальное необязательно. Продукт становится всего лишь набором фичей, а бренд — набором постов. Аккумулятивный фрагментализм вообще удобная позиция: можно делать, не понимая, зачем. А если что — всегда можно сказать: «Мы действуем итеративно». То есть идём вслепую, но с диким рвением.

В клиповом мышлении стратегия — это пережиток — не нужен как сюжет в TikTok-ролике. Зачем понимать общую картину, если можно просто быстро листать дальше? Стратег — мёртв. Остались только груды метрик и модные фреймворки. Но, если честно, иногда всё же хочется, чтобы кто-то вышел и сказал: «Ребята, а мы идем туда!»
Но он не выйдет. У него митинг. Через пять минут. По другому поводу и совсем про другое.", "date_published": "2025-06-19T13:20:03+00:00"}, {"id": "https://t.me/c/2107544821/55", "url": "https://t.me/c/2107544821/55", "title": "Опять в сердечко — как часто я это видел за свою карьеру. 😞", "content_html": "Опять в сердечко — как часто я это видел за свою карьеру. 😞", "date_published": "2025-06-19T13:20:03+00:00"}, {"id": "https://t.me/c/2107544821/54", "url": "https://t.me/c/2107544821/54", "title": "Закину вам без уведомления мой пост про наушники https://jonfir.github.io/blogs/irl/xiaomi_bone_con", "content_html": "Закину вам без уведомления мой пост про наушники

https://jonfir.github.io/blogs/irl/xiaomi_bone_conduction_headphones/

Кстати сайт целиком курсор написал)", "date_published": "2025-06-17T14:32:36+00:00"}, {"id": "https://t.me/c/2107544821/53", "url": "https://t.me/c/2107544821/53", "title": "Слушаю подкаст о том, как AI меняет подход к разработке, и там прозвучали интересные тезисы: * Испо", "content_html": "Слушаю подкаст о том, как AI меняет подход к разработке, и там прозвучали интересные тезисы:

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

И меня во время прослушивания не отпускает один вопрос: а почему раньше так было нельзя? Ведь людям тоже так было бы проще, и фичи делались бы быстрее. Но почему-то должен был прийти AI, чтобы это стало нормой.

В подкасте, кстати, тоже подняли этот вопрос и сказали, что раньше разница в скорости была, но не настолько большая, как сейчас. Я, конечно, с этим не согласен...", "date_published": "2025-06-14T18:25:10+00:00"}, {"id": "https://t.me/c/2107544821/52", "url": "https://t.me/c/2107544821/52", "title": "Интересный выпуск подкаста про то что на острие атаки - нейронки в "языках будущего" http", "content_html": "Интересный выпуск подкаста про то что на острие атаки - нейронки в "языках будущего"

https://music.yandex.ru/album/7570122?utm_medium=copy_link
\"media\"/", "date_published": "2025-06-12T06:27:07+00:00", "attachments": [{"url": "https://tg.davvie.com/static/-1002107544821--52-0.jpg", "mime_type": "image/jpeg"}]}, {"id": "https://t.me/c/2107544821/51", "url": "https://t.me/c/2107544821/51", "title": "Мы пишем хороший код. #Философское Я часто пишу или говорю, что что-то сделано не так, что тут мож", "content_html": "Мы пишем хороший код.

#Философское

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

И да, это действительно так. Но идеала не бывает — к нему можно только стремиться.

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

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

А по-настоящему плохой код, который я встречал:

Проект целиком написанный на шаблонизаторе для java. Авторы были уверены, что Java — это хорошо, но не понимали, что это такое. В шаблонизаторе почти не было логики — только урезанные циклы и переменные. Если логику нельзя было реализовать из-за ограничений шаблонизатора, её писали на стороне клиента на JS. И весь этот проект был написан в одной функции — просто огромные вложенные if и switch.

Проект сделаный как тема для Wordpress. Название кнопки из трёх слов собиралось по частям: в JS, в PHP (из нескольких файлов) и в БД (из нескольких полей). Причём JS, PHP и SQL были перемешаны в строках. Переменные a, b, c считались нормальными. Код был раскидан по файлам вроде start.php, additional.php и т. д. Никакой логики, структуры, следования конвенциям WordPress — просто функции, вызывающие другие функции. Я бы не смог написать такое, даже если бы старался.

Проект написанный на Perl с использованием метапрограммирования. Perl и так не самый читаемый язык (вот валидный код: @~# +$1), но когда код меняет сам себя через регулярки, потому что «так компактнее», — это ад.

Последний раз я видел плохой код в 2016 году, когда брал фриланс-проект: вёрстку, которую нужно было натянуть на Bitrix. Кажется, у меня были кровавые слёзы от него. Дикая вложенность блоков. Нейминг в стиле a, b, c. Игнорирование типов. Никакой обработки ошибок. Функции с большой буквы, смешение camelCase и snake_case. И конечно отсутствие какой либо структуры или логики в организации кода.

Можно сказать, что это было давно или что это писали джуны. Но нет — это продакшен-код, который до сих пор пишут.", "date_published": "2025-06-04T11:58:32+00:00"}, {"id": "https://t.me/c/2107544821/50", "url": "https://t.me/c/2107544821/50", "title": "Как писать эффективные промпты для AI 🤖 #AI Чтобы получить качественный результат от нейросети, ва", "content_html": "Как писать эффективные промпты для AI 🤖

#AI

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

Ситуация (контекст) + Задача + Экшен-поинт + Пример решения = Успешный результат

✅ Хорошо:

Есть вёрстка формы на UIKit + NSLayoutConstraints. Форма находится внутри UIScrollView.
Нужен класс кнопки для использования в этой форме — наследник UIControl. Кнопка должна соответствовать контракту UIButton:
• Эффекты нажатия (изменение цвета на X, добавление тени Y)
• Не конфликтовать с жестами UIScrollView
• Контент: UILabel + UIImageView + UIImageView
• Контент передаётся через инициализатор и остаётся неизменяемым
• Спецификация лейаута (отступ, шрифт, цвет — указано подробно)
• Публичные элементы снабжены докстрингами

🛠️ Напиши класс кнопки, соответствующий вышеуказанным требованиям.

(Прикладываю пример референсного класса)

❌ Плохо:

Сделай кнопку для формы

— Формулируйте запросы так, будто общаетесь с обезьянкой. Чем точнее ввод — тем лучше вывод", "date_published": "2025-05-31T09:13:01+00:00"}], "icon": "https://tg.davvie.com/static/avatars/that_jonfir.jpg"}