iOS Makes Me Hate
3.92K subscribers
1.23K photos
174 videos
15 files
1.37K links
Авторский канал про iOS разработку. Путь продуктовых самураев в MAANG.

Самое больше iOS сообщество практиков: https://boosty.to/lionbond/

Автор: @lvbond Senior iOS Yandex, ex-Avito, VK
Download Telegram
К теме архитектур

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

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

Особенно на контрасте это с клиповым и зумерским (не в обиду) мышлением. Где короткие видосы сделали нашу ОЗУ головного мозга размером с рыбки.

Или пытаюсь осилить стратегию Crusader Kings 3 уже третий раз. Не потому что прикалывает, а просто понимать все нюансы и стратегии для тренировки нейронки мозга.

Братья, что можете посоветовать из хороших книг или стратегий? А может чего-то другого
7
System Design vs Software Architecture: результат vs код

В мобилке наверное до 2023 года систем дизайн не был популярен. В вопросах архитектур многие путали организацию ui слоя как VIPERы или задавали вопросы чем отличается прокси от декоратора. Когда же требования и задачи начали усложняться, то начала меняться сама тема.

Например раньше, если разраб брал фичу, то он думал ТОЛЬКО О КОДЕ. Реализует по Clean Architecture. Выделяет все в слои Use Cases, Repository, Entities. Все четко по SOLID.

Такой подход был рутиным и похожим на гонку "кто затащит самый хайповый фреймворк себе в проект". Ответить на вопрос "зачем мы юзаем VIPER, а не MVP?" толком никто не мог. Просто потому что "модно".

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

Систем дизайн же дал осознанности. Теперь инженеры больше думают о РЕЗУЛЬТАТЕ:
🟣Пользователь видит не архитектуру, а результат. Ему все равно, что у тебя MVVM или VIPER, если приложение тормозит или падает.
🟣Mobile System Design учитывает взаимодействие с дизайнерами, бэкендерами, тестировщиками. Теперь нет нелепых оправданий от разрабов "это нарушает архитектуру iOS проекта". Архитектура должна отражать бизнес, а не сковывать его
🟣Компании стали хотеть видеть инженеров, которые думают шире, чем просто "экранчики и кнопки".

Сейчас разрабам критически важно выходить за рамки кода и своей платформы. Не просто как разделять UI и бизнес логику или выбрать между MVC или Clean Architecture. А понимать как iOS работает с бэкендом? Что будет в оффлайне? Как работают пуши или диплинки? Как тестировать систему целиком, а не только маленькими кусками кода? Как разбивать фичу на модули? И это как раз помогает развивать и оценить дисциплина System Design.

Архитектура — про код.
Системный дизайн — про ценность для продукта и пользователя.

- System Design vs. Software Design
- System Design vs. Software Architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
101
System Design-интервью: зачем они нужны и почему не всегда работают

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

1️⃣ Time to Offer

Сегодня 60% собеседований — это типовые задачи и вопросы. Часть из них кочует из компании в компанию.

Банально, задача с написанием юнит-теста на аналитику мне попадалась за 5 лет в нескольких разных компаниях. Казалось бы, найм супер упрощен. Есть сборник вопросов, достаточно пару раз сходить на собесы и ты уже +- понял правила игры. Да и интервьюров обучать не сложно. Просто есть методичка — проверяй по ней.

Но даже с таким простым подходом time to offer (время на получение оффера) обычно от 2 до 8 недель. Теперь представьте как увеличится время, если прогонять каждого не по максимально шаблонному собесу, а по сложному процессу. Где и критерии оценки очень размыты. Да и каждый интервьюр — это дорогой спец без свободных слотов на 1.5 часа собесов. Time to offer легко станет х2

2️⃣ Сложность критериев

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

Сис диз сложнее в оценке. Чтобы секция работала, нужно:
- подготовить интервьюеров,
- выровнять критерии оценки,
- договориться о «весе» каждого аргумента.

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

3️⃣ Кандидаты разного уровня

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

Короче, Вывод:
Сисдиз собесы нужны и полезны. Они показывают, как кандидат мыслит системно и работает в условиях неопределенности. Но делать их обязательными для всех компаний и всех уровней — ошибка.

В найме цель не в том, чтобы провести "модное" интервью. Цель нанять подходящего инженера вовремя. Если систем дизайн удваивает Time to Offer и отталкивает кандидатов, он превращается не в инструмент, а в тормоз бизнеса.
61
This media is not supported in your browser
VIEW IN TELEGRAM
Когда сломал индустрию
326
🧑 Чеклист когда использовать Actor?

В одном из прошлых постов мы уже разбирали советы когда нужен актор. Но советов много не бывает.

В этой автор предлагает конкретный чеклист из трех пунктов.

Если все три "да", то создавай отдельный actor. Если хотя бы одно "нет", то actor не нужен.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
52
🌄 SwiftUI Redraw System In Depth: Attributes, Recomputation, Diffing and Observation

Мы уже поднимали глубже тему кишков как SwiftUI работает изнутри, SwiftUI: View Trees vs Render Trees, а также как работает Observable под капотом.

Даже делали подборку говнокода. Это все очень помогает, чтобы выжать весь перфоманс с SUI.

Теперь попалась статья, где автор чуть систематизирует систему отрисовки:
- Invalidation / Outdating
- body recomputation
- Diffing

Статья понравилась тем, что здесь есть объективные замеры.

Другие полезные материалы по теме:
- Вопросы для собеседований SwiftUI: Layout Engine
- Вопросы для изучения SwiftUI: Основы построения UI и приложения
- Большая подборка задач на SwiftUI

🧬 Получить доступ можно 💰 тут или ⭐️ тут
Please open Telegram to view this post
VIEW IN TELEGRAM
6
Как вайбкодинг убивает твое критическое мышление

Первое правило it — перепроверяй. Себя, других, статьи из интернета, слова менеджера, обещания руководителей, лозунги компании.

Доверие — дорогая валюта и часто ценится теми, кто ей не разбрасывается.

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

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

1️⃣ не заменяй свое мнение на ответы ChatGPT

2️⃣ истинный рост происходит когда самостоятельно борешься с трудностями 🥷

3️⃣ в сложных знаниях доменной области не всегда важен навык кодинга

4️⃣ Вставляя бездумно код ты не понимаешь обьемы технического долга

Итого: вайбкодинг хороший инструмент делать прототипы и быстрые мвп, но только при очень вдумчивом использовании
9
🥲 AI инженеринг: Температура

Одна из главных метрик хорошего ответа в LLMках — это значение температуры.

Вкратце, чем ниже температура, тем более предсказуемые и строгие ответы. А чем выше — тем креативнее.

У Claude даже есть крутой дашборд, который помогает оценить температуру и делать нейронку более предсказуемой.

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


Методика называется Self-Consistency.

Полезные ссылки:
- Understanding How to Configure LLM Temperature Settings
- A Comprehensive Guide to LLM Temperature
- LLM Temperature Effects

🧬 И кстати, со следующей недели в закрытом чате мы начинаем неделю практики.

Еще больше насыщенного контента про промтинг 💰 тут или ⭐️ тут
Please open Telegram to view this post
VIEW IN TELEGRAM
4
This media is not supported in your browser
VIEW IN TELEGRAM
АУФ ПАЦАНЫ

Три пощечины от легенды — путь к величию!

Легендарный Антонио Иноки отвешивает три пощечины молодому Лиото Мачиде после победы.
Это не оскорбление, а знак уважения, путь самурая.
Так Иноки признает потенциал бойца стать великим. Честь, уважение и никакой ненависти - только традиции.


Музыка взята из интернета
42
Forwarded from Mobile Developer (Алексей Гладков)
Опрос: Какие технологии вы используете?

Большинство знаний о нашем мире IT мы получаем из глобальных опросов, откуда потом уже приземляем общие тенденции на наши реалии, поэтому я решил провести серию опросов с целью выяснить что происходит в нашем мире мобильной разработки/разработки/IT в широком смысле (в таком порядке)

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

Пройти опрос можно по ссылке ниже 👇
https://forms.yandex.ru/cloud/68c443e8068ff07b9709a29d

P.S. Опрос валиден для нативных андроид и иос разработчиков, а также почти для любой кроссплатформы
2