К теме архитектур
короче понял, что самый главный буст памяти и удержании больших картин в голове — это стратегии и книги.
Ща читаю снова кучу книг и материалов про system design для большой статьи. И самое сложное это удерживать и связывать все в голове. Дип ресерчить и комбинировать.
Особенно на контрасте это с клиповым и зумерским (не в обиду) мышлением. Где короткие видосы сделали нашу ОЗУ головного мозга размером с рыбки.
Или пытаюсь осилить стратегию Crusader Kings 3 уже третий раз. Не потому что прикалывает, а просто понимать все нюансы и стратегии для тренировки нейронки мозга.
Братья, что можете посоветовать из хороших книг или стратегий? А может чего-то другого
короче понял, что самый главный буст памяти и удержании больших картин в голове — это стратегии и книги.
Ща читаю снова кучу книг и материалов про system design для большой статьи. И самое сложное это удерживать и связывать все в голове. Дип ресерчить и комбинировать.
Особенно на контрасте это с клиповым и зумерским (не в обиду) мышлением. Где короткие видосы сделали нашу ОЗУ головного мозга размером с рыбки.
Или пытаюсь осилить стратегию Crusader Kings 3 уже третий раз. Не потому что прикалывает, а просто понимать все нюансы и стратегии для тренировки нейронки мозга.
Братья, что можете посоветовать из хороших книг или стратегий? А может чего-то другого
Какой вы бы сделали совет по входу в ит в 2025?
Anonymous Poll
37%
Херачить пока молодой. Вписываться в любую движуху
14%
Ебл@нить. Крутить опыт. Читерить.
28%
Не иди в ит в 2025.
21%
Изучай базу. Иди в ML.
18%
Алгосы. Систем дизайн. Харды.
19%
Софты. Коммуникация. Менеджмент.
19%
Хз.
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
В мобилке наверное до 2023 года систем дизайн не был популярен. В вопросах архитектур многие путали организацию ui слоя как VIPERы или задавали вопросы чем отличается прокси от декоратора. Когда же требования и задачи начали усложняться, то начала меняться сама тема.
Например раньше, если разраб брал фичу, то он думал ТОЛЬКО О КОДЕ. Реализует по Clean Architecture. Выделяет все в слои Use Cases, Repository, Entities. Все четко по SOLID.
Такой подход был рутиным и похожим на гонку "кто затащит самый хайповый фреймворк себе в проект". Ответить на вопрос "зачем мы юзаем VIPER, а не MVP?" толком никто не мог. Просто потому что "модно".
Такое давало много разных проблем. Фреймило на определенной парадигме, где следование жестким границам привычных поведний вредило больше, чем помогало. Иногда приложение на два экрана усложнялось и превращалось в переусложненное дерьмо просто потому что "так правильно академически", когда же практически проект вымирал из-за своей медлительности и неповоротности.
Систем дизайн же дал осознанности. Теперь инженеры больше думают о РЕЗУЛЬТАТЕ:
Сейчас разрабам критически важно выходить за рамки кода и своей платформы. Не просто как разделять 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
GeeksforGeeks
System Design vs. Software Design - GeeksforGeeks
Your All-in-One Learning Portal: GeeksforGeeks is a comprehensive educational platform that empowers learners across domains-spanning computer science and programming, school education, upskilling, commerce, software tools, competitive exams, and more.
System Design-интервью: зачем они нужны и почему не всегда работают
В интернетах ходят советы заменить все секции собесов на одну — систем дизайн. Мы немного поштормили и выдали топ ответов почему сисдиз не для всех:
1️⃣ Time to Offer
Сегодня 60% собеседований — это типовые задачи и вопросы. Часть из них кочует из компании в компанию.
Банально, задача с написанием юнит-теста на аналитику мне попадалась за 5 лет в нескольких разных компаниях. Казалось бы, найм супер упрощен. Есть сборник вопросов, достаточно пару раз сходить на собесы и ты уже +- понял правила игры. Да и интервьюров обучать не сложно. Просто есть методичка — проверяй по ней.
Но даже с таким простым подходом time to offer (время на получение оффера) обычно от 2 до 8 недель. Теперь представьте как увеличится время, если прогонять каждого не по максимально шаблонному собесу, а по сложному процессу. Где и критерии оценки очень размыты. Да и каждый интервьюр — это дорогой спец без свободных слотов на 1.5 часа собесов. Time to offer легко станет х2
2️⃣ Сложность критериев
Следующая проблема — это кол-во интервьюеров, кто смог пройти и обучился проводить секцию. Ведь обучение проводить собесы тоже важно.
Сис диз сложнее в оценке. Чтобы секция работала, нужно:
- подготовить интервьюеров,
- выровнять критерии оценки,
- договориться о «весе» каждого аргумента.
На практике же часто один интервьюер занижает оценку, другой завышает, и на финальном этапе нанимающий менеджер нивелирует часть разногласий. Это допустимо на обычных секциях, но в системном дизайне оценку сделать еще сложнее.
3️⃣ Кандидаты разного уровня
Не все кандидаты в принципе готовы к интервью. Мидл может быть сильным в коде и фичах, но никогда не сталкиваться с задачами по масштабированию, оффлайн-сценариям или интеграциям. Для него это будет "разговор вслепую".
Короче, Вывод:
Сисдиз собесы нужны и полезны. Они показывают, как кандидат мыслит системно и работает в условиях неопределенности. Но делать их обязательными для всех компаний и всех уровней — ошибка.
В найме цель не в том, чтобы провести "модное" интервью. Цель нанять подходящего инженера вовремя. Если систем дизайн удваивает Time to Offer и отталкивает кандидатов, он превращается не в инструмент, а в тормоз бизнеса.
В интернетах ходят советы заменить все секции собесов на одну — систем дизайн. Мы немного поштормили и выдали топ ответов почему сисдиз не для всех:
1️⃣ Time to Offer
Сегодня 60% собеседований — это типовые задачи и вопросы. Часть из них кочует из компании в компанию.
Банально, задача с написанием юнит-теста на аналитику мне попадалась за 5 лет в нескольких разных компаниях. Казалось бы, найм супер упрощен. Есть сборник вопросов, достаточно пару раз сходить на собесы и ты уже +- понял правила игры. Да и интервьюров обучать не сложно. Просто есть методичка — проверяй по ней.
Но даже с таким простым подходом time to offer (время на получение оффера) обычно от 2 до 8 недель. Теперь представьте как увеличится время, если прогонять каждого не по максимально шаблонному собесу, а по сложному процессу. Где и критерии оценки очень размыты. Да и каждый интервьюр — это дорогой спец без свободных слотов на 1.5 часа собесов. Time to offer легко станет х2
2️⃣ Сложность критериев
Следующая проблема — это кол-во интервьюеров, кто смог пройти и обучился проводить секцию. Ведь обучение проводить собесы тоже важно.
Сис диз сложнее в оценке. Чтобы секция работала, нужно:
- подготовить интервьюеров,
- выровнять критерии оценки,
- договориться о «весе» каждого аргумента.
На практике же часто один интервьюер занижает оценку, другой завышает, и на финальном этапе нанимающий менеджер нивелирует часть разногласий. Это допустимо на обычных секциях, но в системном дизайне оценку сделать еще сложнее.
3️⃣ Кандидаты разного уровня
Не все кандидаты в принципе готовы к интервью. Мидл может быть сильным в коде и фичах, но никогда не сталкиваться с задачами по масштабированию, оффлайн-сценариям или интеграциям. Для него это будет "разговор вслепую".
Короче, Вывод:
Сисдиз собесы нужны и полезны. Они показывают, как кандидат мыслит системно и работает в условиях неопределенности. Но делать их обязательными для всех компаний и всех уровней — ошибка.
В найме цель не в том, чтобы провести "модное" интервью. Цель нанять подходящего инженера вовремя. Если систем дизайн удваивает Time to Offer и отталкивает кандидатов, он превращается не в инструмент, а в тормоз бизнеса.
Считаешь ли ты, что текущие процессы собеседований сломаны?
Anonymous Poll
41%
Сломаны в край, людей оценивают рандомно. Нужно все переделать
8%
Сломаны, но частично. Собесы задизайнены норм, но интервьюеры плохо справляются
12%
Сломаны, виноваты рекрутеры. Они пьют нашу кровь
10%
Сломаны и поломал их AI и чатгпт
7%
Не сломаны, собесы работают нормально.
22%
Не сломаны, но немного устарели. Их нужно актуализировать
В одном из прошлых постов мы уже разбирали советы когда нужен актор. Но советов много не бывает.
В этой автор предлагает конкретный чеклист из трех пунктов.
Если все три "да", то создавай отдельный actor. Если хотя бы одно "нет", то actor не нужен.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Что бы вы сделали первым для оптимизаций?
Anonymous Poll
77%
Проверил нагруженность MainThread'а
28%
Добавил логи
32%
Искал бы утечки памяти
17%
Смотрел бы ответы сервера по данным и сеть
15%
Копнул бы в сторону Render Server и рендеринг компонентов
15%
Поискал бы Lazy оптимизации
12%
Пошел бы в сторону батчинга и кэширования
9%
Другое
Мы уже поднимали глубже тему кишков как 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
Как вайбкодинг убивает твое критическое мышление
Первое правило it — перепроверяй. Себя, других, статьи из интернета, слова менеджера, обещания руководителей, лозунги компании.
Доверие — дорогая валюта и часто ценится теми, кто ей не разбрасывается.
Для меня все советы «не верьте всему что пишет чатгпт» выглядят очевидными. Банально от того, что есть баги везде. Заканчивая конспирологией и теориями о полит-инструментах.
Вот и в статье, наш любимый SwiftUI-архитектор, рассказывает как бездумное копирование мешает развитию критического мышления:
1️⃣ не заменяй свое мнение на ответы ChatGPT
2️⃣ истинный рост происходит когда самостоятельно борешься с трудностями 🥷
3️⃣ в сложных знаниях доменной области не всегда важен навык кодинга
4️⃣ Вставляя бездумно код ты не понимаешь обьемы технического долга
Итого: вайбкодинг хороший инструмент делать прототипы и быстрые мвп, но только при очень вдумчивом использовании
Первое правило it — перепроверяй. Себя, других, статьи из интернета, слова менеджера, обещания руководителей, лозунги компании.
Доверие — дорогая валюта и часто ценится теми, кто ей не разбрасывается.
Для меня все советы «не верьте всему что пишет чатгпт» выглядят очевидными. Банально от того, что есть баги везде. Заканчивая конспирологией и теориями о полит-инструментах.
Вот и в статье, наш любимый SwiftUI-архитектор, рассказывает как бездумное копирование мешает развитию критического мышления:
1️⃣ не заменяй свое мнение на ответы ChatGPT
2️⃣ истинный рост происходит когда самостоятельно борешься с трудностями 🥷
3️⃣ в сложных знаниях доменной области не всегда важен навык кодинга
4️⃣ Вставляя бездумно код ты не понимаешь обьемы технического долга
Итого: вайбкодинг хороший инструмент делать прототипы и быстрые мвп, но только при очень вдумчивом использовании
AzamSharp
How Vibe Coding Is Hurting Your Critical Thinking
Пишите ли вы код на другой платформе (кроме iOS)?
Anonymous Poll
11%
Да, на работе пишу бэк
7%
Да, на работе пишу андроид
12%
Да, на работе пишу кроссплатформу
8%
Да, другое
26%
Да, но не на работе. Изучаю для себя
51%
Нет, только пишу только на iOS
Одна из главных метрик хорошего ответа в 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
This media is not supported in your browser
VIEW IN TELEGRAM
АУФ ПАЦАНЫ
Музыка взята из интернета
Три пощечины от легенды — путь к величию!
Легендарный Антонио Иноки отвешивает три пощечины молодому Лиото Мачиде после победы.
Это не оскорбление, а знак уважения, путь самурая.
Так Иноки признает потенциал бойца стать великим. Честь, уважение и никакой ненависти - только традиции.
Forwarded from Mobile Developer (Алексей Гладков)
Опрос: Какие технологии вы используете?
Большинство знаний о нашем мире IT мы получаем из глобальных опросов, откуда потом уже приземляем общие тенденции на наши реалии, поэтому я решил провести серию опросов с целью выяснить что происходит в нашем мире мобильной разработки/разработки/IT в широком смысле (в таком порядке)
И я запускаю первый опрос - Какие технологии вы используете? Он направлен на то, чтобы выяснить какие технологии используют мобильные разработчики в России.
Опрос займет буквально 5-7 минут. Результаты в общем виде мы опубликуем для всех и у нас будут вполне себе реальные данные по нашем рынку
Пройти опрос можно по ссылке ниже 👇
https://forms.yandex.ru/cloud/68c443e8068ff07b9709a29d
P.S. Опрос валиден для нативных андроид и иос разработчиков, а также почти для любой кроссплатформы
Большинство знаний о нашем мире IT мы получаем из глобальных опросов, откуда потом уже приземляем общие тенденции на наши реалии, поэтому я решил провести серию опросов с целью выяснить что происходит в нашем мире мобильной разработки/разработки/IT в широком смысле (в таком порядке)
И я запускаю первый опрос - Какие технологии вы используете? Он направлен на то, чтобы выяснить какие технологии используют мобильные разработчики в России.
Опрос займет буквально 5-7 минут. Результаты в общем виде мы опубликуем для всех и у нас будут вполне себе реальные данные по нашем рынку
Пройти опрос можно по ссылке ниже 👇
https://forms.yandex.ru/cloud/68c443e8068ff07b9709a29d
P.S. Опрос валиден для нативных андроид и иос разработчиков, а также почти для любой кроссплатформы