Media is too big
VIEW IN TELEGRAM
Ставь 💀 если спортсмен
Ставь🔥 если музыкант
Ставь
Please open Telegram to view this post
VIEW IN TELEGRAM
1
This media is not supported in your browser
VIEW IN TELEGRAM
Записываем нормальный подкаст в нормальном офисе с нормальным светом.
Media is too big
VIEW IN TELEGRAM
Network: Мобильная связь и квота пропускного канала
Зачем думать о 2G интернете? Ведь далеко не все тестят свои апки в этой сети.
Тема мобильной сети — гиперчувствительная. И при этом сильно недооцененная в мобильной разработке.
Недавно я брал консультацию у core команды Яндекс Плеера о том, как оптимизировать видео. Формально разговор был про форматы, коллекции и устройство плеера. Но самым откровенным и очевидным для меня оказался совсем другой пласт — это нетворк-квоты и приоритизация запросов. Казалось бы, очевидно. Но почему мы не задумываемся об этом?
Об этом редко задумываются, когда речь идет об обычной верстке или стандартных апи-запросах. Но в видео все иначе: общий трафик, количество соединений и их приоритет критически важны.
Да, в некоторых крупных компаниях есть платформенные или перфоманс-команды (Авито, Т-Банк), которые глубоко оптимизируют нетворк-слой клиента. Но возникает логичный вопрос: почему обычному мобильному разработчику важно понимать, как работает сеть?
Многие разработчики воспринимают сеть как что-то простое: отправил запрос и получил ответ. В реальности мобильная сеть: нестабильная, медленная, непредсказуемая. Именно поэтому в системном дизайне ей всегда уделяют отдельное место. Игнорировать сеть значит проектировать приложение для идеальных условий, которых у пользователя чаще нет.
О сети можно говорить часами. В этой серии постов я хочу детально разобрать, как работает network в мобильных приложениях и с какими проблемами мы сталкиваемся на практике.
Начнем с базовых, но очень важных сложностей:
1️⃣ Соединение постоянно меняется
Этот вопрос очень важен. Особенно при звонка, которые должны работать даже из парковки и в лифте. Тот же Zoom удивляет многих как работает стабильно с 3G или плохим интернетом, когда же конкуренты, телега или ватсап, еще до замедлений, работали плоховато.
Здесь множество оптимизаций: от хитрых алгоритмов сжатия, то заигрывания с соединениями.
2️⃣ Высокая задержка (latency)
Есть cold и hot ответы. И чаще ответы CDN или других хранилищ нужно заранее "прогревать". Ведь даже при хорошем соединении холодный старт может быть отдавать первый байт долго.
3️⃣ Ограниченный и дорогой трафик
В некоторых регионах, странах, трафик может быть дорогой. В том же Пакистане интернет в 2 раза хуже РФ, но некоторые сервисы уже получают денег больше, чем у себя в стране. Чтобы конкурировать нужно уметь подстраивать под их сеть и быть быстрее конкурентов.
4️⃣ Нетворк квота устройства
Устройство условно на момент соединения имеет доступную пропускную способность 5 Мбит/с. Это общий канал, которым пользуются все процессы сразу: ваше приложение, системные сервисы, другие приложения в фоне. Под наше приложения нет отдельного канала. Все делят один и тот же ресурс.
Если одновременно идут загрузка видео, аналитика, картинки, обработка данных — все запросы конкурируют за один канал. Видео хочет 4 мб/с, аналитика 0.1 мб/с, апи запросы 0.9 мб/с. Канал полностью забит. Если появляется еще один запрос, то появляются лаги и зависания.
И тут еще сложность, что ОС распределяет ресурсы, а не приложение.
В след постах разберем все детальнее
Зачем думать о 2G интернете? Ведь далеко не все тестят свои апки в этой сети.
Тема мобильной сети — гиперчувствительная. И при этом сильно недооцененная в мобильной разработке.
Недавно я брал консультацию у core команды Яндекс Плеера о том, как оптимизировать видео. Формально разговор был про форматы, коллекции и устройство плеера. Но самым откровенным и очевидным для меня оказался совсем другой пласт — это нетворк-квоты и приоритизация запросов. Казалось бы, очевидно. Но почему мы не задумываемся об этом?
Об этом редко задумываются, когда речь идет об обычной верстке или стандартных апи-запросах. Но в видео все иначе: общий трафик, количество соединений и их приоритет критически важны.
Да, в некоторых крупных компаниях есть платформенные или перфоманс-команды (Авито, Т-Банк), которые глубоко оптимизируют нетворк-слой клиента. Но возникает логичный вопрос: почему обычному мобильному разработчику важно понимать, как работает сеть?
Многие разработчики воспринимают сеть как что-то простое: отправил запрос и получил ответ. В реальности мобильная сеть: нестабильная, медленная, непредсказуемая. Именно поэтому в системном дизайне ей всегда уделяют отдельное место. Игнорировать сеть значит проектировать приложение для идеальных условий, которых у пользователя чаще нет.
О сети можно говорить часами. В этой серии постов я хочу детально разобрать, как работает network в мобильных приложениях и с какими проблемами мы сталкиваемся на практике.
Начнем с базовых, но очень важных сложностей:
1️⃣ Соединение постоянно меняется
Этот вопрос очень важен. Особенно при звонка, которые должны работать даже из парковки и в лифте. Тот же Zoom удивляет многих как работает стабильно с 3G или плохим интернетом, когда же конкуренты, телега или ватсап, еще до замедлений, работали плоховато.
Здесь множество оптимизаций: от хитрых алгоритмов сжатия, то заигрывания с соединениями.
2️⃣ Высокая задержка (latency)
Есть cold и hot ответы. И чаще ответы CDN или других хранилищ нужно заранее "прогревать". Ведь даже при хорошем соединении холодный старт может быть отдавать первый байт долго.
3️⃣ Ограниченный и дорогой трафик
В некоторых регионах, странах, трафик может быть дорогой. В том же Пакистане интернет в 2 раза хуже РФ, но некоторые сервисы уже получают денег больше, чем у себя в стране. Чтобы конкурировать нужно уметь подстраивать под их сеть и быть быстрее конкурентов.
4️⃣ Нетворк квота устройства
Устройство условно на момент соединения имеет доступную пропускную способность 5 Мбит/с. Это общий канал, которым пользуются все процессы сразу: ваше приложение, системные сервисы, другие приложения в фоне. Под наше приложения нет отдельного канала. Все делят один и тот же ресурс.
Если одновременно идут загрузка видео, аналитика, картинки, обработка данных — все запросы конкурируют за один канал. Видео хочет 4 мб/с, аналитика 0.1 мб/с, апи запросы 0.9 мб/с. Канал полностью забит. Если появляется еще один запрос, то появляются лаги и зависания.
И тут еще сложность, что ОС распределяет ресурсы, а не приложение.
В след постах разберем все детальнее
Forwarded from Стой под стрелой (Nikita Prokopov)
Почему-то считается, что дизайнеру или программисту круто бы думать об интересах бизнеса, что инженер, который о них думает, ценнее, чем тот, который не думает.
А мне кажется наоборот. У вас уже есть бизнесмен, пусть он о них думает. Зачем компании два бизнесмена, один хороший, другой плохой? Мне кажется, дизайнер должен думать про дизайн, программист — про программы. И целью своей себе ставить сделать хороший дизайн или хорошую программу, а не угодить бизнесу. И вот в их конфликте возникнет некое целое, которое больше частей, их синтез.
Грубо, дизайнера должно заботить, чтобы интерфейс хорошо выглядел и им было удобно пользоваться, а не метрики. Метрики будут заботить бизнес. Если дизайнера будут заботить метрики, и бизнес будут заботить метрики, получится не конфликт и поиск его решения, а повторение и топтание на месте.
Я много раз разговаривал с инженерами, которые жаловались, что бизнес не дает им времени на рефакторинг или сделать нормально. Ну так он и не должен давать! Бизнес интересует бизнес, а вас, как инженера, должно интересовать, как сделать качественно, устойчиво, эффективно. К вам никто никогда снаружи с этим запросом не придет, это должна быть ваша собственная мотивация, ваши собственные ценности, ваши собственные стандарты, понимаете?
И к вам приходят, чтобы вы их продавливали. А бизнес бизнес и без вас сделает.
А мне кажется наоборот. У вас уже есть бизнесмен, пусть он о них думает. Зачем компании два бизнесмена, один хороший, другой плохой? Мне кажется, дизайнер должен думать про дизайн, программист — про программы. И целью своей себе ставить сделать хороший дизайн или хорошую программу, а не угодить бизнесу. И вот в их конфликте возникнет некое целое, которое больше частей, их синтез.
Грубо, дизайнера должно заботить, чтобы интерфейс хорошо выглядел и им было удобно пользоваться, а не метрики. Метрики будут заботить бизнес. Если дизайнера будут заботить метрики, и бизнес будут заботить метрики, получится не конфликт и поиск его решения, а повторение и топтание на месте.
Я много раз разговаривал с инженерами, которые жаловались, что бизнес не дает им времени на рефакторинг или сделать нормально. Ну так он и не должен давать! Бизнес интересует бизнес, а вас, как инженера, должно интересовать, как сделать качественно, устойчиво, эффективно. К вам никто никогда снаружи с этим запросом не придет, это должна быть ваша собственная мотивация, ваши собственные ценности, ваши собственные стандарты, понимаете?
И к вам приходят, чтобы вы их продавливали. А бизнес бизнес и без вас сделает.
Network: 2G, 3G, LTE, 5G
Еще одно заблуждение, что типы мобильных сетей == это просто скорость. В реальности это совершенно разные условия, ограничения и проблемы, с которыми сталкивается приложение.
Иногда 4G может дать больше проблем, чем 3G.
1G
Только голос. В 1G не существовало понятия “скорость интернета” потому что интернета не было.
2G
Во времена какой-нибудь нокиа 3310 это была связь и минимум данных. Скорость была в пределах 100–200 кбит/с
Проблемы: экономия каждого запроса
3G
Расвет мобильного браузинга. iPhone 3G. Социальные сети мой мир, первые фейсбуки и вк. Скорость могла быть на пике до 2–10 мбит/с.
Проблемы: борьба с latency. Первый байт приходит долго. Нужны прогревы запросов.
4G
От 20–100 до 300+ мгбит/с. Покрытие интернета стало массовым. Появились онлайн игры и видеостриминги. Весь трафик перешел из веба в мобилку.
Проблемы: нестабильность сети и появляются потери пакетов. Качество сети прыгает и приходится адаптироваться.
5G
От 100–1000 мбит/с до 10–20 гб/с. Видосы 8к. Автопилоты тачек и роботы. Инфраструктура смарт сити. Мобильный облачный гейминг.
Проблемы: конкурекция за каналы. Один канал делят все приложения. Видео, аналитика, API конкурируют между собой
Каждое поколение сети бросало новые вызовы. В идеале хорошее приложение должно стабильно работать в каждой.
Интересные статьи:
- What are the differences between 2G, 3G, 4G LTE, and 5G networks?
- Exploring Mobile Technology from 1G to 5G
- Ликбез 11-5. Поколения сотовой связи (5G)
Еще одно заблуждение, что типы мобильных сетей == это просто скорость. В реальности это совершенно разные условия, ограничения и проблемы, с которыми сталкивается приложение.
Иногда 4G может дать больше проблем, чем 3G.
1G
Только голос. В 1G не существовало понятия “скорость интернета” потому что интернета не было.
2G
Во времена какой-нибудь нокиа 3310 это была связь и минимум данных. Скорость была в пределах 100–200 кбит/с
Проблемы: экономия каждого запроса
3G
Расвет мобильного браузинга. iPhone 3G. Социальные сети мой мир, первые фейсбуки и вк. Скорость могла быть на пике до 2–10 мбит/с.
Проблемы: борьба с latency. Первый байт приходит долго. Нужны прогревы запросов.
4G
От 20–100 до 300+ мгбит/с. Покрытие интернета стало массовым. Появились онлайн игры и видеостриминги. Весь трафик перешел из веба в мобилку.
Проблемы: нестабильность сети и появляются потери пакетов. Качество сети прыгает и приходится адаптироваться.
5G
От 100–1000 мбит/с до 10–20 гб/с. Видосы 8к. Автопилоты тачек и роботы. Инфраструктура смарт сити. Мобильный облачный гейминг.
Проблемы: конкурекция за каналы. Один канал делят все приложения. Видео, аналитика, API конкурируют между собой
Каждое поколение сети бросало новые вызовы. В идеале хорошее приложение должно стабильно работать в каждой.
Интересные статьи:
- What are the differences between 2G, 3G, 4G LTE, and 5G networks?
- Exploring Mobile Technology from 1G to 5G
- Ликбез 11-5. Поколения сотовой связи (5G)
Опенсорс-библиотека Implicits от Яндекс Браузера: новый шаг в передаче зависимостей Swift
У коллег из яндекс браузера вышла огромная статья на 49 (!) минут чтения(теперь не говорите мне что мои статьи большие) . Много кода и аргументаций зачем пишут свое решение с DI.
Тема DI очень актуальная. Знаю что как минимум 4 компании в этом году занимались переосмыслением и актуализацией своих DI.
Это понятно. Особенно когда у тебя сложный продукт, который стал держать в себе много технологий и модулей: UIKit и SwiftUI для UI слоя. Множество зависимостей и чужих SDK. Кроссплатформы и BDUI.
Почитайте, очень интересно
У коллег из яндекс браузера вышла огромная статья на 49 (!) минут чтения
Тема DI очень актуальная. Знаю что как минимум 4 компании в этом году занимались переосмыслением и актуализацией своих DI.
Это понятно. Особенно когда у тебя сложный продукт, который стал держать в себе много технологий и модулей: UIKit и SwiftUI для UI слоя. Множество зависимостей и чужих SDK. Кроссплатформы и BDUI.
Почитайте, очень интересно
Хабр
Опенсорс-библиотека Implicits от Яндекс Браузера: новый шаг в передаче зависимостей Swift
Когда iOS‑приложение вырастает до сотен тысяч строк, появляется проблема: добавление зависимости в глубокий компонент требует изменений во всех промежуточных функциях. Эти функции...
Ваше отношение к BDUI/SDUI?
С учетом глобального тренда многих компаний хочу разобрать эту тему глубоко. Собрать все мнения и детально разобрать отношение и опыт
С учетом глобального тренда многих компаний хочу разобрать эту тему глубоко. Собрать все мнения и детально разобрать отношение и опыт
Anonymous Poll
10%
Нет опыта. Мнение положительное. Считаю это наше светлое будущее писать 90% на BDUI
39%
Нет опыта. Отношусь скептично по отзывам коллег
6%
Есть большой опыт. Все нравится.
11%
Есть большой опыт. Не нравится.
22%
Есть небольшой опыт. Не нравится.
6%
Есть небольшой опыт. Все нравится
12%
Другое
Подборка статей про BDUI
Хочу сделать глобальный и детальный опрос про использование BDUI. Лично я знаю множество разработчиков с разными мнениями. Кто-то даже использовал данные и опросы из моего канала в реальных докладах. Поэтому будем идти по data driven development. Отбрасывая эмоции, пузыри и слепые догмы. Идем за объективностью.
Но сначала решил собрать самые "честные статьи". И здесь не будет докладов с конференций. Все чаще слышу, что конференции умирают и никто туда не ходит. Почему? Мне отвечают, потому что там мало искренности и правды. Поэтому поищу самые на мой взгляд детальные и наполненные разными мнениями.
1️⃣ Почему BDUI актуален именно сейчас в e‑commerce
Эта статья мне понравилась тем, что можно взглянуть кому именно продается BDUI. А это владельцы е-commerce приложений. А ведь чаще так и есть. Если у тебя сложный лайаут, мессенджер, карты, навигации, то BDUI ложится очень плохо. Но вот если у тебя какой-то маркетплейс, то в целом можно заменить 90% нативщиков.
Вкратце, если вы хотите работать с BDUI, то идите в e-commerce
2️⃣ Server-Driven UI vs Native: Data Sync Speed
Здесь идет классический разбор Server-Driven UI и натива. Особый упор делается, что SDUI сильно зависим от хорошего интернета. Для меня лично является очень странным решением выбирать онли SDUI если у нас в регионах очень плохо с интернетом. Когда же натив лучше работает с оффлайном (некоторые маркетплейсы идут в эту сторону тоже).
Если вам важен оффлайн (мессенджеры, видео, медиа) то тут выбор очевидный — натив. Пусть даже ценой медленного изменения UI.
3️⃣ Пост на реддите "Server Driven UI - is this really worth it?"
На удивление, форумы и чаты, стали новым источником искренности. Туда еще не проник маркетинг и фальш из конференций. Не добралась рука модераторов и программных комитетов, которые обрезают всю неудобность. Что пишут? Много разных мнений. Можно почитать самому.
Хочу сделать глобальный и детальный опрос про использование BDUI. Лично я знаю множество разработчиков с разными мнениями. Кто-то даже использовал данные и опросы из моего канала в реальных докладах. Поэтому будем идти по data driven development. Отбрасывая эмоции, пузыри и слепые догмы. Идем за объективностью.
Но сначала решил собрать самые "честные статьи". И здесь не будет докладов с конференций. Все чаще слышу, что конференции умирают и никто туда не ходит. Почему? Мне отвечают, потому что там мало искренности и правды. Поэтому поищу самые на мой взгляд детальные и наполненные разными мнениями.
1️⃣ Почему BDUI актуален именно сейчас в e‑commerce
Эта статья мне понравилась тем, что можно взглянуть кому именно продается BDUI. А это владельцы е-commerce приложений. А ведь чаще так и есть. Если у тебя сложный лайаут, мессенджер, карты, навигации, то BDUI ложится очень плохо. Но вот если у тебя какой-то маркетплейс, то в целом можно заменить 90% нативщиков.
Вкратце, если вы хотите работать с BDUI, то идите в e-commerce
2️⃣ Server-Driven UI vs Native: Data Sync Speed
Здесь идет классический разбор Server-Driven UI и натива. Особый упор делается, что SDUI сильно зависим от хорошего интернета. Для меня лично является очень странным решением выбирать онли SDUI если у нас в регионах очень плохо с интернетом. Когда же натив лучше работает с оффлайном (некоторые маркетплейсы идут в эту сторону тоже).
Если вам важен оффлайн (мессенджеры, видео, медиа) то тут выбор очевидный — натив. Пусть даже ценой медленного изменения UI.
3️⃣ Пост на реддите "Server Driven UI - is this really worth it?"
На удивление, форумы и чаты, стали новым источником искренности. Туда еще не проник маркетинг и фальш из конференций. Не добралась рука модераторов и программных комитетов, которые обрезают всю неудобность. Что пишут? Много разных мнений. Можно почитать самому.
Зачем ходишь на конференции и согласен ли, что они умирают?
Anonymous Poll
9%
Хожу за докладами. Не согласен, что вымирают
12%
Хожу за нетворком. Не согласен, что вымирают
10%
Хожу за докладами. согласен, что вымирают
13%
Хожу за нетворком. согласен, что вымирают
29%
Ходил, перестал ходить.
17%
Никогда не был на конференциях и не хочу
19%
Никогда не был на конференциях, но хочу побывать
8%
Другое
Проектирование реальных фич: Feed App ч 2
В первой части мы поговорили про требования и про главный выбор: pull vs push. Во второй спускаемся на уровень "а что конкретно проектируем?".
Какие экраны, какие API, какие модели, как пагинировать, как устроить клиент, чтобы все было быстрым и живым.
1️⃣ Все начинается с уточнения скоупа работ:
- Feed: бесконечный скролл, лайк и шаринг, тапы, детальная страница, форма для создания поста.
- Create Post: текст + вложения (картинки/видео)
- Post Detail: полный контент + действия
И отдельно важная скрытая фича, которую часто ждут на интервью — это prefetching (подгрузить посты заранее, чтобы открыть ленту быстрее)
2️⃣ API
Дальше идем в проектирования API-контракта. Смысл API-дизайна в интервью простой. Вот вы договорились как клиент и сервер будут говорить, и дальше не спорите “а откуда это берется”. Здесь очень важно не перезагружать данными модели. Нужно их обрезать чтобы не перегружать сеть; не убивать память/CPU клиента; не тянуть тяжелые вложения без необходимости
Особенно когда с интернетом беда.
3️⃣ Пагинация
Для ленты почти всегда выбирают cursor-based pagination. Я еще делился прикольным докладом про пагинацию тут.
Почему offset не идеальный вариант:
- лента часто обновляется: пока ты листаешь, сверху приходят новые посты, а окно может смещаться
- чем глубже offset, тем хуже производительность запросов на больших объёмах данных
Cursor-подход лучше, потому что опирается на индексируемое поле и дает стабильный следующий блок даже если сверху добавились новые посты
4️⃣ Архитектура клиента: слои и поток данных
Классический подход в структуре — разделять на слои
UI layer — это экраны (Feed / Detail / Create). А за состояниями овечаются ViewModel и Presentor. Навигация должна быть в отдельном компоненте.
Data layer — желательно разделять все на репозитории, data source'ы, а медиа хранить на CDN.
5️⃣ Offline-first и “Single Source of Truth” на клиенте
В той самой книге по проектированию автор говорит, что для мобильной ленты это прям must-have, потому что сеть бывает медленная, нестабильная и пропадает во время скролла. Автор советует:
- все, что пришло с бэка, нужно сразу писать в локальную БД
- UI читает данные из локальной БД, даже когда интернет есть
- при оффлайне показываем кэш и аккуратно сообщаем, что обновиться не можем. Это и есть "Backend -> Local Storage -> UI" как единый стабильный пайплайн
✅ Что интервьюер хочет услышать?
- Нужно отдавать в ленту Preview, чтобы не тянуть тяжелые данные
- Пагинация cursor, потому что лента часто обновляется
- Клиент offline-first, local DB — SSOT, UI читает из нее
- Статику раздаем через CDN, чтобы ускорить ленту и снять нагрузку
В первой части мы поговорили про требования и про главный выбор: pull vs push. Во второй спускаемся на уровень "а что конкретно проектируем?".
Какие экраны, какие API, какие модели, как пагинировать, как устроить клиент, чтобы все было быстрым и живым.
1️⃣ Все начинается с уточнения скоупа работ:
- Feed: бесконечный скролл, лайк и шаринг, тапы, детальная страница, форма для создания поста.
- Create Post: текст + вложения (картинки/видео)
- Post Detail: полный контент + действия
И отдельно важная скрытая фича, которую часто ждут на интервью — это prefetching (подгрузить посты заранее, чтобы открыть ленту быстрее)
2️⃣ API
Дальше идем в проектирования API-контракта. Смысл API-дизайна в интервью простой. Вот вы договорились как клиент и сервер будут говорить, и дальше не спорите “а откуда это берется”. Здесь очень важно не перезагружать данными модели. Нужно их обрезать чтобы не перегружать сеть; не убивать память/CPU клиента; не тянуть тяжелые вложения без необходимости
Особенно когда с интернетом беда.
3️⃣ Пагинация
Для ленты почти всегда выбирают cursor-based pagination. Я еще делился прикольным докладом про пагинацию тут.
Почему offset не идеальный вариант:
- лента часто обновляется: пока ты листаешь, сверху приходят новые посты, а окно может смещаться
- чем глубже offset, тем хуже производительность запросов на больших объёмах данных
Cursor-подход лучше, потому что опирается на индексируемое поле и дает стабильный следующий блок даже если сверху добавились новые посты
4️⃣ Архитектура клиента: слои и поток данных
Классический подход в структуре — разделять на слои
UI layer — это экраны (Feed / Detail / Create). А за состояниями овечаются ViewModel и Presentor. Навигация должна быть в отдельном компоненте.
Data layer — желательно разделять все на репозитории, data source'ы, а медиа хранить на CDN.
5️⃣ Offline-first и “Single Source of Truth” на клиенте
В той самой книге по проектированию автор говорит, что для мобильной ленты это прям must-have, потому что сеть бывает медленная, нестабильная и пропадает во время скролла. Автор советует:
- все, что пришло с бэка, нужно сразу писать в локальную БД
- UI читает данные из локальной БД, даже когда интернет есть
- при оффлайне показываем кэш и аккуратно сообщаем, что обновиться не можем. Это и есть "Backend -> Local Storage -> UI" как единый стабильный пайплайн
- Нужно отдавать в ленту Preview, чтобы не тянуть тяжелые данные
- Пагинация cursor, потому что лента часто обновляется
- Клиент offline-first, local DB — SSOT, UI читает из нее
- Статику раздаем через CDN, чтобы ускорить ленту и снять нагрузку
Please open Telegram to view this post
VIEW IN TELEGRAM
Кстати, по ленте. Еще около года назад скинули фотку как результаты опроса из нашего канала использовали в докладе
Тогда это был доклад Саши Сычева @headOfMobile. Он был кросс-лидом Feed в Яндекс Го
По выбранному ответу можно сделать все же выводы, что не всегда Feed можно комфортно сделать на BDUI🫣
Тогда это был доклад Саши Сычева @headOfMobile. Он был кросс-лидом Feed в Яндекс Го
По выбранному ответу можно сделать все же выводы, что не всегда Feed можно комфортно сделать на BDUI
Please open Telegram to view this post
VIEW IN TELEGRAM
Fucking Approachable Swift Concurrency
Достали занудные правильные документации? Хочется чего-то народного и без цензуры? Устали от корпоративного дресскода?
Если хочешь наконец разобраться в теме и понять все простыми словами, без тяжелого профессионального жаргона, то поможет этот сайт.
Мне, если честно, гораздо ближе такая форма. Прямая, простая, без лишних терминов.
Не отвлекает от сути и быстро вводит в курс дела без лишних аккуратностей
Достали занудные правильные документации? Хочется чего-то народного и без цензуры? Устали от корпоративного дресскода?
Если хочешь наконец разобраться в теме и понять все простыми словами, без тяжелого профессионального жаргона, то поможет этот сайт.
Мне, если честно, гораздо ближе такая форма. Прямая, простая, без лишних терминов.
Не отвлекает от сути и быстро вводит в курс дела без лишних аккуратностей
Fucking Approachable Swift Concurrency
A no-bullshit guide to Swift concurrency. Learn async/await, actors, Sendable, and MainActor with simple mental models. No jargon, just clear explanations.
Итоги 2025 года часть 1
Потихоньку решил писать итоги года и разделю это на несколько частей.
Этот год для меня является годом переездов.
Я наконец переехал, выбравшись из небольшого городка. Мигрирую за границы своего телеграм канала. Делаю трансфер в сторону разных форматов. И становлюсь смелее с каждым шагом, вырываясь из стеклянных потолков и невидимых стен, которые сам себе когда-то поставил.
Перестал скептично относиться к нейронкам. Занялся активно изучением проектирования сложных систем. Но парадоксально поменял отношение к потреблению контента.
Я уже года полтора не читаю другие каналы про иос разработку, а твиторы никогда не читал. Меня не привлекает ютуб контент. А с всплеском нейродерьма стало еще хуже. Теперь мое потребление заменили книги и коллеги.
Я хочу развивать навык дип ресерча и поэтому весь мой контент, который я профессионально потребляю, часто связан с книгами. Мне не хочется становиться книжным блогером, но много беру по структуре и форме именно там. Навык долгой концентрации и усидчивости на тиктоках не прокачаешь.
Чтением в этом году я не сильно доволен, мог бы лучше, но наконец сделал в своей комнате огромную книжную полку. В детстве у моей бабушки была огромная стена книг, где подходя к ней, я чувствовал свою незначительность и глупость. Сейчас моя полка напоминает мне, что следующий год нужно поднажать, чтобы прочитать хоть половину.
Потихоньку решил писать итоги года и разделю это на несколько частей.
Этот год для меня является годом переездов.
Я наконец переехал, выбравшись из небольшого городка. Мигрирую за границы своего телеграм канала. Делаю трансфер в сторону разных форматов. И становлюсь смелее с каждым шагом, вырываясь из стеклянных потолков и невидимых стен, которые сам себе когда-то поставил.
Перестал скептично относиться к нейронкам. Занялся активно изучением проектирования сложных систем. Но парадоксально поменял отношение к потреблению контента.
Я уже года полтора не читаю другие каналы про иос разработку, а твиторы никогда не читал. Меня не привлекает ютуб контент. А с всплеском нейродерьма стало еще хуже. Теперь мое потребление заменили книги и коллеги.
Я хочу развивать навык дип ресерча и поэтому весь мой контент, который я профессионально потребляю, часто связан с книгами. Мне не хочется становиться книжным блогером, но много беру по структуре и форме именно там. Навык долгой концентрации и усидчивости на тиктоках не прокачаешь.
Чтением в этом году я не сильно доволен, мог бы лучше, но наконец сделал в своей комнате огромную книжную полку. В детстве у моей бабушки была огромная стена книг, где подходя к ней, я чувствовал свою незначительность и глупость. Сейчас моя полка напоминает мне, что следующий год нужно поднажать, чтобы прочитать хоть половину.
📺 Swift Concurrency + Swift 6 на практике
Предновогодний подгон. Опубликовали в открытый доступ видос по Swift 6 + Swift Councurrency.
Пообщались о том, как в реальной практике живется на современном стэке.
В выпуске:
🟣 с какими неожиданностями пришлось столкнуться при переводе боевоего проекта
🟣 насколько документация Swift Councurrency помогает в реальных задачах
🟣 что изменилось в правилах языка и почему об этом важно знать
🟣 практическими советами и лайфхаками для разработки
🟣 лучшие материалы для обучения
Доступ к другим видео и материалам💰 тут или ⭐️ тут
Предновогодний подгон. Опубликовали в открытый доступ видос по Swift 6 + Swift Councurrency.
Пообщались о том, как в реальной практике живется на современном стэке.
В выпуске:
Доступ к другим видео и материалам
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Swift Concurrency + Swift 6 на практике
Канал об iOS разработке от практиков: https://t.me/iosmakesmehate/
Канал спикер: https://t.me/ios_iss_blog/
Наш ДОРОГОЙ друг Савва — ведущий инженер, который уже перевел несколько крупных приложений на Swift Concurrency и Swift 6. В своем канале он подробно…
Канал спикер: https://t.me/ios_iss_blog/
Наш ДОРОГОЙ друг Савва — ведущий инженер, который уже перевел несколько крупных приложений на Swift Concurrency и Swift 6. В своем канале он подробно…
Не смог не побыть corporate girl не захватить хайповый мерч от яндекса
Нужен ли чистый код в эпоху его гниения? Эволюция отношения к коду.
Есть правило, что никакой код не вечный. У него есть инфляция, энтропия и гниение.
1️⃣ Меняется контекст.
Требования, продукт, команда, интеграции. То, что было элегантно при задаче А, становится обузой при задаче B. В стартапах или продуктах с низкой определенностью писать сразу "понятный и идеальный" код - опасно и неблагодарно.
2️⃣ Меняется платформа и язык.
Swift быстро развивается: concurrency, macros, новые API, новые бест практики. Код, который был правильным в 2020, в 2025 может выглядеть как кусок говна.
3️⃣ Меняешься ты.
Ты начинаешь видеть вещи, которых не видел раньше: границы модулей, места для инверсии зависимостей, контрактов, тестируемости. Прошлый ты не был херовым. У него были другие ограничения.
4️⃣ AI генерация
Читать напрямую код стало всем меньше людей. Даже по нашему опросу люди чаще читают чужой код (и даже книги) с помощью нейронок. Фронтенд может писать код для бэкенда. И наоборот.
Пока ты джун, ты реально часто не знаешь, что ты не знаешь. И либо пишешь "как получится". Либо пытаешься писать "как в книжке", но без понимания контекста и цены абстракций. Для меня чистый код это не про "правильно потому что правильно". Это когда всем становится понятнее.
Да и я вообще считаю, что по-настоящему чистый код ты не можешь писать если сам:
- не пишешь автотесты всех уровней пирамиды
- не проектируешь архитектуры
- нет общепринятого стандарта "понятности и чистоты" в команде
- нет культуры избавления от легаси
Интересные статьи:
- Entropy — Why Code Rots And Technical Debt Grows
- Is writing clean code overrated
- Why Clean Code is Overrated: The Data-Driven Reality Check
Ставьте 🖤 если пишите "чистый" код, и 💀 когда "достаточно понятный"
Есть правило, что никакой код не вечный. У него есть инфляция, энтропия и гниение.
1️⃣ Меняется контекст.
Требования, продукт, команда, интеграции. То, что было элегантно при задаче А, становится обузой при задаче B. В стартапах или продуктах с низкой определенностью писать сразу "понятный и идеальный" код - опасно и неблагодарно.
2️⃣ Меняется платформа и язык.
Swift быстро развивается: concurrency, macros, новые API, новые бест практики. Код, который был правильным в 2020, в 2025 может выглядеть как кусок говна.
3️⃣ Меняешься ты.
Ты начинаешь видеть вещи, которых не видел раньше: границы модулей, места для инверсии зависимостей, контрактов, тестируемости. Прошлый ты не был херовым. У него были другие ограничения.
4️⃣ AI генерация
Читать напрямую код стало всем меньше людей. Даже по нашему опросу люди чаще читают чужой код (и даже книги) с помощью нейронок. Фронтенд может писать код для бэкенда. И наоборот.
Пока ты джун, ты реально часто не знаешь, что ты не знаешь. И либо пишешь "как получится". Либо пытаешься писать "как в книжке", но без понимания контекста и цены абстракций. Для меня чистый код это не про "правильно потому что правильно". Это когда всем становится понятнее.
Да и я вообще считаю, что по-настоящему чистый код ты не можешь писать если сам:
- не пишешь автотесты всех уровней пирамиды
- не проектируешь архитектуры
- нет общепринятого стандарта "понятности и чистоты" в команде
- нет культуры избавления от легаси
Интересные статьи:
- Entropy — Why Code Rots And Technical Debt Grows
- Is writing clean code overrated
- Why Clean Code is Overrated: The Data-Driven Reality Check
Ставьте 🖤 если пишите "чистый" код, и 💀 когда "достаточно понятный"
Хабр
Как избежать гниения ПО
Недавно я наткнулся на историю столь же удивительную, сколь и ужасную: Один из моих клиентов занимался поддержкой нескольких пенсионных фондов, входящих в сотню лучших по миру. У него была еженочная...