Повторение — мать учения. Мы уже прошлись по теории, теперь перейдем к практике.
Чтобы не отставать от рынка я и пишу в этом канале. В этой подборке мы узнаем:
Другие подборки задач:
- Сборник задач по синхронизации асинхронных тасок: GCD
- Шаблон для собеседований № 2
- Подборка задач на Swift Concurrency
- Вопросы для собесов по Swift Concurrency | часть 1
Please open Telegram to view this post
VIEW IN TELEGRAM
Isolation, actors, sendable… a concurrency deep dive
Для любителей видео есть топ контент. Здесь автор доступно объясняет в чем же соль изоляции. Напомню, что эта ментальная концепция с Swift 6 станет ключевой. Настолько, что даже попадаются вакансии для временных подработок по обновлению Swift Concurrency чекера на разных проектах.
Так что GCD и правда становится чем-то архаичным и опасным для тех, кто прошел огонь и воду борясь с ошибками компиляции SC в крупном проекте.
Короче, если вы в эту тему еще не погрузились и у вас еще нет цели избавиться от варнингов в проекте — самое время)
Для любителей видео есть топ контент. Здесь автор доступно объясняет в чем же соль изоляции. Напомню, что эта ментальная концепция с Swift 6 станет ключевой. Настолько, что даже попадаются вакансии для временных подработок по обновлению Swift Concurrency чекера на разных проектах.
Так что GCD и правда становится чем-то архаичным и опасным для тех, кто прошел огонь и воду борясь с ошибками компиляции SC в крупном проекте.
Короче, если вы в эту тему еще не погрузились и у вас еще нет цели избавиться от варнингов в проекте — самое время)
YouTube
Isolation, actors, sendable… a concurrency deep dive
Speaker: Donny Wals
With Swift 6 being available in Xcode right now, more and more people are taking the plunge and trying out the Swift 6 language mode in their projects. And often they switch back to Swift 5 quickly. The errors, the warnings, how does…
With Swift 6 being available in Xcode right now, more and more people are taking the plunge and trying out the Swift 6 language mode in their projects. And often they switch back to Swift 5 quickly. The errors, the warnings, how does…
Деградация кодовой базы или code rot
Еще одно популярное заблуждение среди программистов — это код, написанный один раз, всегда остается свежим и рабочим. Забавное совпадение. Почти все мои сложные фичи были большими и с долгим релизным циклом от пары кварталов до года. Я это не выбирал, а как-то само тянуло.
Это значит, что фичи, которые я делал, долго лежали и ждали своего запуска. Накапливая много бизнес-логики и фичей. И только потом был жирный и большой релиз. В динамичном меняющимся проекте, где десятки пулл-реквестов в день, это очень стрессовые условия. И если ты изначально не позаботишься о защите, то будет очень больно. Например фичи:
🔴 Безопасность нетворк слоя и пин-коды. Это фича была в сберздоровье. Где основная логика была в том, что время жизни любого нетворк запроса было равно 5 минутам. Для его "прогрева" мы юзали пинкод как в банке. Здесь мало верстки, но много запутанной логики от чего рождался не менее запутанный код 😄
🟣 Мультипрофиль и авторизация. Еще одна большая фича, которую мы делали год в Авито — это мультипрофили. Это сложная логика которая меняла флоу и всю инфу об аккаунте: мессенджер, избранное, тарифы и тп. А аккаунты могут быть личные или компании.
🔘 Текущая фича (пока под NDA)
Везде желательно продумывать архитектуру так, чтобы code rot был минимальным. Чтобы в момент запуска мы не обнаружили, что пока код лежал год в пыли, он сломался и развалился. Не сломали соседние команды ключевой функционал, а на релизе не всплыло тысячи багов.
В книге Mobile System Design есть крутые правила как минимизировать ущерб:
1️⃣ Проектируй архитектуру, поддерживающую рост. И нет, архитектура — это не про TCA/VIPER/MVP. Это про модуляризацию и масштабируемость.
- Нужно делить фичи на независимые модули
- задумываться о меньшей связи (low couplin)
- упрощать тестирование и замену отдельных модулей.
2️⃣ Делай Self-sufficient features. Это фичи, которые минимально зависят от других фичей напрямую. Общались либо через абстракции, либо через протоколы. И не протекали друг в друга (leaky boundaries)
3️⃣ Использовать BFF (Backend For Frontend). BFF позволяет адаптировать API под конкретные нужды клиента, не нагружая мобильное приложение избыточной логикой.
4️⃣ Фичатоглы, автотесты, contract-first программирование, четкие границы ответственности модулей и инкапсуляция логики. Все это не просто "догмы", а при осознанном программировании и долгих релизах — спасение.
Какие антипаттерны приводят к быстрой деградации?
- Использование глобального состояния (Привет TCA и синглтоны)
- Сквозные зависимости между модулями.
- Повторение бизнес-логики в разных частях приложения.
- Сильная связанность UI и логики (fat ViewControllers).
Полезные статьи:
- Choose Boring Technology
- Coupling and Cohesion
- Legacy Code Rescue: Taming a Thousand-Line View Controller
Еще одно популярное заблуждение среди программистов — это код, написанный один раз, всегда остается свежим и рабочим. Забавное совпадение. Почти все мои сложные фичи были большими и с долгим релизным циклом от пары кварталов до года. Я это не выбирал, а как-то само тянуло.
Это значит, что фичи, которые я делал, долго лежали и ждали своего запуска. Накапливая много бизнес-логики и фичей. И только потом был жирный и большой релиз. В динамичном меняющимся проекте, где десятки пулл-реквестов в день, это очень стрессовые условия. И если ты изначально не позаботишься о защите, то будет очень больно. Например фичи:
Везде желательно продумывать архитектуру так, чтобы code rot был минимальным. Чтобы в момент запуска мы не обнаружили, что пока код лежал год в пыли, он сломался и развалился. Не сломали соседние команды ключевой функционал, а на релизе не всплыло тысячи багов.
В книге Mobile System Design есть крутые правила как минимизировать ущерб:
1️⃣ Проектируй архитектуру, поддерживающую рост. И нет, архитектура — это не про TCA/VIPER/MVP. Это про модуляризацию и масштабируемость.
- Нужно делить фичи на независимые модули
- задумываться о меньшей связи (low couplin)
- упрощать тестирование и замену отдельных модулей.
2️⃣ Делай Self-sufficient features. Это фичи, которые минимально зависят от других фичей напрямую. Общались либо через абстракции, либо через протоколы. И не протекали друг в друга (leaky boundaries)
3️⃣ Использовать BFF (Backend For Frontend). BFF позволяет адаптировать API под конкретные нужды клиента, не нагружая мобильное приложение избыточной логикой.
4️⃣ Фичатоглы, автотесты, contract-first программирование, четкие границы ответственности модулей и инкапсуляция логики. Все это не просто "догмы", а при осознанном программировании и долгих релизах — спасение.
Какие антипаттерны приводят к быстрой деградации?
- Использование глобального состояния (Привет TCA и синглтоны)
- Сквозные зависимости между модулями.
- Повторение бизнес-логики в разных частях приложения.
- Сильная связанность UI и логики (fat ViewControllers).
Полезные статьи:
- Choose Boring Technology
- Coupling and Cohesion
- Legacy Code Rescue: Taming a Thousand-Line View Controller
Please open Telegram to view this post
VIEW IN TELEGRAM
Dan McKinley :: Math, Programming, and Minority Reports
Dan McKinley :: Choose Boring Technology
О спорте.
Кто не знал, но я много занимался спортом. Мой батя - учитель физкультуры и тренер по самбо. С 11 лет 3 года я занимался дзюдо, потом еще 3 боевым самбо. Даже достиг неплохих результатов и занимал призовые места в серьезных турнирах Казахстана.
Спорт был напарником в учебе. Батя всегда говорил, что это для характера и дисциплины. Хотя я не всегда любил то, чем занимался, он не обманул)
Спорт правда дал какой-то фундамент принципов и базы, которая независимо от профессии и дисциплины всегда была основой. Да и в целом канал пропитан темой боевых единоборств.
Приехав в Москву и уже месяц утопая в рутине я понял как мне его не хватает. Хотя я и забыл многие вещи и сильно растерял форму за многие годы без единоборств, но записаться в крутой зал бразильского джиу джитсу хочется до сих пор. В Москве говорят это не просто спорт, а братство. Да и в целом отсутствие регулярных спортивных сильно забирает силы. Делает вялым.
У меня будто начинает развиваться болезнь сдвгшника.
Если у вас тоже есть желание закалять себя через мужицкие потные занятия, то пишите в лс. Скооперируемся пока вообще не раскуфели.
Кто не знал, но я много занимался спортом. Мой батя - учитель физкультуры и тренер по самбо. С 11 лет 3 года я занимался дзюдо, потом еще 3 боевым самбо. Даже достиг неплохих результатов и занимал призовые места в серьезных турнирах Казахстана.
Спорт был напарником в учебе. Батя всегда говорил, что это для характера и дисциплины. Хотя я не всегда любил то, чем занимался, он не обманул)
Спорт правда дал какой-то фундамент принципов и базы, которая независимо от профессии и дисциплины всегда была основой. Да и в целом канал пропитан темой боевых единоборств.
Приехав в Москву и уже месяц утопая в рутине я понял как мне его не хватает. Хотя я и забыл многие вещи и сильно растерял форму за многие годы без единоборств, но записаться в крутой зал бразильского джиу джитсу хочется до сих пор. В Москве говорят это не просто спорт, а братство. Да и в целом отсутствие регулярных спортивных сильно забирает силы. Делает вялым.
У меня будто начинает развиваться болезнь сдвгшника.
Если у вас тоже есть желание закалять себя через мужицкие потные занятия, то пишите в лс. Скооперируемся пока вообще не раскуфели.
This media is not supported in your browser
VIEW IN TELEGRAM
Ну и мотивирующего вайба вам из инстаграмов🤣
Please open Telegram to view this post
VIEW IN TELEGRAM
Подборка статей про развитие своего «визибилити»
Слово визибилити мне не нравится. Его использовали уже лет 5, но сейчас еще чаще. Да и я напрямую его не качал. Все как-то само и органически. Но вижу как много «блогов» начало развиваться в эпоху чатгпт и хочется не скатиться в такую же посредственность в гонке за видимость.
В чате сообщества мы часто обсуждаем современные проблемы найма. Последний год стало еще хуже:
🔘 огромное число фейковых резюме сломало поиск всем. И новичкам, и старичкам. Даже сеньоры не могу пройти фильтр рекрутеров и попасть на собесы под тысячами однотипных резюмешек
🔘 работодатель перестал пользоваться хх и другими старыми инструментами. После функции «авто-отклик» ему за час прилетают тысячи спам сообщений, в которых не хочется разбираться.
🟡 Резюме — уже не главный источник правды.
Решения этим проблемам логичные:
- начали появляться закрытые клубы, сообщества, конференции. Да да, на конфы нужно ходить не ради докладов, а чтобы выйти напрямую к рекрутерам. Для этого конфы и делают.
- реферальные системы стали эффективными. Теперь к словам проверенных инженеров доверяются лучше, чем к прошлым системам найма.
- менторство. Слышал Авито начал делать коллабы с менторами солвери и гетментор, чтобы те сразу призывали подготовленных спецов за хорошие реферальные бонусы. Хорошая стратегия.
- начали смотреть не только на визибилити твоего резюме, но и тебя как инженера: коммиты в опенсоурс перестали быть шуткой, выступления на конфах стали лучше цениться. Да и в целом твои цифровые следы стали более важными в общей метрики видимости.
Мир изменился. Просто быть хорошим инженером уже недостаточно. Важно быть заметным. Видимость это ваш новый способ пройти сквозь шум, обойти фильтры и показать, кто вы есть на самом деле.
Вот в целом полезные статьи как с умом качать видимость:
- Personal Branding for Developers – A Step‑by‑Step Handbook
- How to gain visibility as a software developer?
- What does visibility really mean for engineering teams?
Слово визибилити мне не нравится. Его использовали уже лет 5, но сейчас еще чаще. Да и я напрямую его не качал. Все как-то само и органически. Но вижу как много «блогов» начало развиваться в эпоху чатгпт и хочется не скатиться в такую же посредственность в гонке за видимость.
Visibility — это ваша узнаваемость, доверие и репутация. Это то, что помогает вам не утонуть среди тысяч других кандидатов.
В чате сообщества мы часто обсуждаем современные проблемы найма. Последний год стало еще хуже:
Решения этим проблемам логичные:
- начали появляться закрытые клубы, сообщества, конференции. Да да, на конфы нужно ходить не ради докладов, а чтобы выйти напрямую к рекрутерам. Для этого конфы и делают.
- реферальные системы стали эффективными. Теперь к словам проверенных инженеров доверяются лучше, чем к прошлым системам найма.
- менторство. Слышал Авито начал делать коллабы с менторами солвери и гетментор, чтобы те сразу призывали подготовленных спецов за хорошие реферальные бонусы. Хорошая стратегия.
- начали смотреть не только на визибилити твоего резюме, но и тебя как инженера: коммиты в опенсоурс перестали быть шуткой, выступления на конфах стали лучше цениться. Да и в целом твои цифровые следы стали более важными в общей метрики видимости.
Мир изменился. Просто быть хорошим инженером уже недостаточно. Важно быть заметным. Видимость это ваш новый способ пройти сквозь шум, обойти фильтры и показать, кто вы есть на самом деле.
Вот в целом полезные статьи как с умом качать видимость:
- Personal Branding for Developers – A Step‑by‑Step Handbook
- How to gain visibility as a software developer?
- What does visibility really mean for engineering teams?
Please open Telegram to view this post
VIEW IN TELEGRAM
freeCodeCamp.org
Personal Branding for Developers – A Step by Step Handbook
In this handbook, you'll learn how to build your personal brand as a developer to help you make your mark in the tech industry. With a focus on practicality and professionalism, this guide is designed for developers at all levels, from industry vete...
Swift Concurrency: Swift 6 и чекеры
Swift 6 сломает ваш код. Это заключительный пост почему GCD будет считаться архазимом и почему после Swift 6 многие будут опасаться использовать его и брать разрабов только со знанием Swift Concurrency.
Это не просто обновление, а полноценный геймченджер в плане тред-сейфти. Теперь этот язык по-настоящему strict by default.
Что это значит?
Инженер теперь должен думать "А безопасно ли это для многопоточности?" на каждом шаге при работе с async, Task, class, var, и замыканиями:
1. переменные класса должны быть защищены от одновременного доступа
2. Все замыкания в Task должны быть безопасны для многозадачности
3. объекты с изменяемым состоянием нельзя бездумно передавать между тасками
4. нужно захватывать self безопасно: или через @MainActor, или через actor, или избегай shared mutable state.
Что должен переосмыслить инженер?
- изоляция уже часть архитектуры. Теперь появится actor mindset и нужно думать что будет актором, а что просто структурой или классом.
- thread safety уже обязательно. Теперь комплиятор будет не запускать приложение, если увидит потенциальную проблему.
- теперь нужно юзать TaskGroup, DetachedTask, async let почти всегда
Это значит, что придется не просто писать и проектировать "хороший код", а "хороший безопасный код".
Важные ресурсы:
🔘 SE‑0302 — Sendable и @Sendable замыкания. Основа потокобезопасности.
🔘 Strict concurrency for global variables. Чуть про глобальные свойства
🔘 Incremental migration to concurrency checking. Полезный инструмент для миграции.
5/5
Swift 6 сломает ваш код. Это заключительный пост почему GCD будет считаться архазимом и почему после Swift 6 многие будут опасаться использовать его и брать разрабов только со знанием Swift Concurrency.
Это не просто обновление, а полноценный геймченджер в плане тред-сейфти. Теперь этот язык по-настоящему strict by default.
Что это значит?
Инженер теперь должен думать "А безопасно ли это для многопоточности?" на каждом шаге при работе с async, Task, class, var, и замыканиями:
1. переменные класса должны быть защищены от одновременного доступа
2. Все замыкания в Task должны быть безопасны для многозадачности
3. объекты с изменяемым состоянием нельзя бездумно передавать между тасками
4. нужно захватывать self безопасно: или через @MainActor, или через actor, или избегай shared mutable state.
Что должен переосмыслить инженер?
- изоляция уже часть архитектуры. Теперь появится actor mindset и нужно думать что будет актором, а что просто структурой или классом.
- thread safety уже обязательно. Теперь комплиятор будет не запускать приложение, если увидит потенциальную проблему.
- теперь нужно юзать TaskGroup, DetachedTask, async let почти всегда
Это значит, что придется не просто писать и проектировать "хороший код", а "хороший безопасный код".
Важные ресурсы:
5/5
Please open Telegram to view this post
VIEW IN TELEGRAM
Лучший вывод из конфы Авито - вопрос из зала: «какая судьба мобильного разработчика в мире BDUI?». Какой ответ вы бы дали?
iOS Makes Me Hate
Лучший вывод из конфы Авито - вопрос из зала: «какая судьба мобильного разработчика в мире BDUI?». Какой ответ вы бы дали?
Лучший ответ — идите в мессенджеры или в видео
Forwarded from Записки инженера
This media is not supported in your browser
VIEW IN TELEGRAM
Новое приложение рокет банка, или что получается, когда дизайнер забывает пить таблетки
P.s. Весит на устройстве это чудо 500 мб, больше сбера
P.s. Весит на устройстве это чудо 500 мб, больше сбера
Непредвзято о BDUI
Вы уже знаете мое личное мнение о нем. Я целый год писал на разных версиях BDUI в своих предыдущих компаниях. Сейчас я пишу преимущественно на нативе и инженерно за пару месяцев забустился больше, чем за год.
Но хочется быть объективным, рассмотреть вопрос с разных сторон и убрать предвзятость. Давайте я подниму основные тезисы и разберем насколько же по-настоящему хороший этот инструмент и так ли на самом деле все ок.
Чтобы узнать мнения о BDUI я собирал опрос "скама в мобильной разработке", а также отношения самих разрабов к технологии. Можно посмотреть реальные цифры от практиков. А почитать некоторые интересные мнения можно тут. Еще на технобренд компаний, где bdui 99% работы можно посмотреть тут.
Но хватит о критике и опустим острые вопросы в стиле "а как искать работу на рынке рабам внутренних велосипедов?" или "почему только разрабы bdui довольны bdui?", и попробуем найти плюсы:
🟣 Если ты разраб BDUI — это хорошо. Так сказали в нашем чате. Один из популярных ответов в комьюнити это мнение, что разрабатывая свой BDUI движок ты легко получишь премии и повышения. Свой BDUI уже начали делать и Х5, и т-банк. Это отличный трамплин для тех, кто хочет быстрых и хороших повышений.
🟣 Быстрый Time-to-market. Действительно, после этапа активной разработки, некоторые фичи на уже обкатанных виджетах и компонентах, можно быстрее заделиверить в прод. Мы опускаем некоторые вопросы по тестированию и поддержке, кол-ву багов на проде перед релизом (ведь релизный цикл мобилки давал плюсы к строгому обеспечению качества). Но в целом да, ценной качества ttm чаще быстрее.
Для быстрых MVP решений это хороший выбор.
🟣 Повышение уровня абстракции. Тебе правда о многом в простой верстке не нужно думать. Это похоже на лего, где ты делаешь однотипные экраны не думая о сложной верстке.
🟣 Консистентность интерфейсов. Визуальный стиль, отступы, размеры, цвета — стандартизировано.
🟣 Ты можешь вырасти за пределы мобилки. Я реально знаю инженеров, кто приходил в компанию где BDUI, чтобы расти потом условно в бэк. Мобилка была для них временным местом и если в таких компаниях тебе дают писать бэк, то это для них был идеальный вариант.
Согласны с этими плюсами и какие бы вы выделили отдельно? Может быть что-то забыли?
Вы уже знаете мое личное мнение о нем. Я целый год писал на разных версиях BDUI в своих предыдущих компаниях. Сейчас я пишу преимущественно на нативе и инженерно за пару месяцев забустился больше, чем за год.
Но хочется быть объективным, рассмотреть вопрос с разных сторон и убрать предвзятость. Давайте я подниму основные тезисы и разберем насколько же по-настоящему хороший этот инструмент и так ли на самом деле все ок.
Чтобы узнать мнения о BDUI я собирал опрос "скама в мобильной разработке", а также отношения самих разрабов к технологии. Можно посмотреть реальные цифры от практиков. А почитать некоторые интересные мнения можно тут. Еще на технобренд компаний, где bdui 99% работы можно посмотреть тут.
Но хватит о критике и опустим острые вопросы в стиле "а как искать работу на рынке рабам внутренних велосипедов?" или "почему только разрабы bdui довольны bdui?", и попробуем найти плюсы:
когда ты пишешь сам bdui - хорошо.
когда на нем фичи верстаешь - плохо.
когда ты продакт - хорошо, когда разраб - плохо.
когда ты хочешь стагнировать - хорошо, когда развиваться - плохо. (с) из чата
Для быстрых MVP решений это хороший выбор.
Согласны с этими плюсами и какие бы вы выделили отдельно? Может быть что-то забыли?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ТЕХНО: Яндекс про технологии
Meta* разрешит кандидатам на некоторые IT-вакансии пользоваться ИИ-ассистентами прямо во время собеседования по написанию кода. В компании считают, что это лучше отражает реальные условия работы современного разработчика, а заодно делает бессмысленным списывание с помощью нейросетей.
При этом компания Anthropic, которая сама разрабатывает нейросети и сервисы для программистов, наоборот, запрещает использовать ИИ на собеседованиях.
Как вы считаете, есть ли смысл оценивать специалиста в отрыве от ИИ, если в работе он всё равно будет им пользоваться? И какие навыки проверяет такое собеседование? Напишите в комментариях.
* Meta признана экстремистской организацией и запрещена в РФ
Подписывайтесь 👉 @techno_yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
Смерть практикующих авторов
Забавный факт, мы тут в чате поисследовали и выяснили, что среди ios-блогеров больше 5к подписчиков — нет практиков. Это уже либо манагеры, либо продакты, либо бизнесмены. Это очень грустно, когда в мобильной разработке нет обычных работяг программистов, которые пишут или делают контент для таких же работяг.
Поэтому мы запускаем операцию "старикам тут не место" и если вы начинающий автор и практикующий спец — пишите статьи или выпускайте контент. Мы обязательно его опубликуем, если это годная штука. Ну либо пишите мне и мы сделаем коллабу ахахах
Мобильный рынок должен двигаться практиками, кто решает реальные проблемы на работе и делится живым опытом. А не теми, кто пересказывает чужие статьи. Не будем overeducated & underexperienced. Ищем практику.
Молодые душой, будьте дерзкими.
Забавный факт, мы тут в чате поисследовали и выяснили, что среди ios-блогеров больше 5к подписчиков — нет практиков. Это уже либо манагеры, либо продакты, либо бизнесмены. Это очень грустно, когда в мобильной разработке нет обычных работяг программистов, которые пишут или делают контент для таких же работяг.
Поэтому мы запускаем операцию "старикам тут не место" и если вы начинающий автор и практикующий спец — пишите статьи или выпускайте контент. Мы обязательно его опубликуем, если это годная штука. Ну либо пишите мне и мы сделаем коллабу ахахах
Мобильный рынок должен двигаться практиками, кто решает реальные проблемы на работе и делится живым опытом. А не теми, кто пересказывает чужие статьи. Не будем overeducated & underexperienced. Ищем практику.
Молодые душой, будьте дерзкими.
Полезные ссылки по миграции на Swift 6
Мы уже выяснили, что переход на Swift 6 — сломает проект. Он просто не будет собираться, если вы ничего не сделали. Поэтому давайте подготовимся к этому и пошарим хорошие материалы друг другу.
1. Migrating to Swift 6. Дока от Apple по миграции. Весь необходимый минимум для подготовки с примерами.
2. How to plan a migration to Swift 6? Для фанатов Donny Wals у него есть отдельное видео с пошаговыми инструкциями
3. The Swift Concurrency Migration Guide. Официальный репозиторий от Swift с подробным гайдом
4. Migrate your app to Swift 6. Секция WWDC как мигрировать приложение на Swift 6
💎 Ну и если вам этого не хватает я сделал подробный гайд. Получить доступ можно 💰 тут или ⭐️ тут
Мы уже выяснили, что переход на Swift 6 — сломает проект. Он просто не будет собираться, если вы ничего не сделали. Поэтому давайте подготовимся к этому и пошарим хорошие материалы друг другу.
1. Migrating to Swift 6. Дока от Apple по миграции. Весь необходимый минимум для подготовки с примерами.
2. How to plan a migration to Swift 6? Для фанатов Donny Wals у него есть отдельное видео с пошаговыми инструкциями
3. The Swift Concurrency Migration Guide. Официальный репозиторий от Swift с подробным гайдом
4. Migrate your app to Swift 6. Секция WWDC как мигрировать приложение на Swift 6
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
How to plan a migration to Swift 6?
Learn how you can start migrating over to Swift 6 in a responsible manner.
Async/Await is super nice in Swift but at the same time it's essential that you plan a migration to Swift 6 carefully. With a completely new concurrency paradigm you'll run into tons…
Async/Await is super nice in Swift but at the same time it's essential that you plan a migration to Swift 6 carefully. With a completely new concurrency paradigm you'll run into tons…
Что я посмотрел/поиграл/почитал в июле
Решил сделать ежемесячную рубрику интересного контента за месяц. И вам интересно, и мне отследить свой рацион культурного питания. Здесь будет мое субьективное мнение к которому прошу не сильно относиться серьезно. Погнали.
Месяц был сложным. Переезд в Москву. Приемка квартиры. Простуда. Суета по мебели и микро-ремонтам, недочетам. Но все равно я успел во что-то поиграть и даже что-то посмотреть и почитать.
1. Clair Obscur: Expedition 33. Я не мог не пройти мимо. Начало было бодрым. Французская грусть отдавала своим шармом. Начало интриговало и это казалось отличным летним путешествием. Но ближе к середине второго акта я начал скучать из-за долгой истории. В итоге, понизив сложность быстро прошел ради сюжета.
Итого 7/10 французов с хромой. Ренуар единственный топ персонаж. Пару треков сохранил.
2. Декстер: Первородный грех. Сразу два сериала по Декстеру вышло за год. Последний раз я его смотрел в детстве лет 20 назад по ДТВ. Тогда мне он не зашел, но как это часто бывает приквелы дали новый аппетит.
итого 7.5/10 маньков
3. Игры, в которые играют люди. Долго возвращаюсь к книгам и пока до конца не прочитал, но эту книгу много кто советовал и ежемесячную подписку надо было как-то отбить. Прочитал 60% и много интересных деталей нашел в себе.
итого 8/10 терапий
Решил сделать ежемесячную рубрику интересного контента за месяц. И вам интересно, и мне отследить свой рацион культурного питания. Здесь будет мое субьективное мнение к которому прошу не сильно относиться серьезно. Погнали.
Месяц был сложным. Переезд в Москву. Приемка квартиры. Простуда. Суета по мебели и микро-ремонтам, недочетам. Но все равно я успел во что-то поиграть и даже что-то посмотреть и почитать.
1. Clair Obscur: Expedition 33. Я не мог не пройти мимо. Начало было бодрым. Французская грусть отдавала своим шармом. Начало интриговало и это казалось отличным летним путешествием. Но ближе к середине второго акта я начал скучать из-за долгой истории. В итоге, понизив сложность быстро прошел ради сюжета.
Итого 7/10 французов с хромой. Ренуар единственный топ персонаж. Пару треков сохранил.
2. Декстер: Первородный грех. Сразу два сериала по Декстеру вышло за год. Последний раз я его смотрел в детстве лет 20 назад по ДТВ. Тогда мне он не зашел, но как это часто бывает приквелы дали новый аппетит.
итого 7.5/10 маньков
3. Игры, в которые играют люди. Долго возвращаюсь к книгам и пока до конца не прочитал, но эту книгу много кто советовал и ежемесячную подписку надо было как-то отбить. Прочитал 60% и много интересных деталей нашел в себе.
итого 8/10 терапий
Мои любимые ит-блогеры
Ты то, что ты ешь.
В этом году я буду делать больше изменений в блоге. Из любительского уровня и быстрых набросков — выйти на чуть более серьезную инфлюенсерскую ступень. Мне повезло попасть в крутой отдел яндекса User Generated Content, где есть создание инструментов социальных сетей. Можно сказать, что блоги теперь часть моей профессии) Я увидел здесь СИГНАЛ С КОСМОСА и поэтому надо не упускать шанса поэкспериментировать с этим всем.
Но при этом оставить тот живой запал. Не только делиться тем, что накипело и набухло внутри, но и уже слушать и слышать аудиторию. Лучше понимать ее как работяга работяг. Сближаться и коммуницировать. Качать эмпатию.
Вчера, на одной из встреч с крутыми людьми, профессионалами своего дела, меня спросили: "Какие твои любимые блогеры?". А я даже и не знаю. В подписках канала у меня всего 2-3 профессиональных автора из СНГ, а остальные — это западные эксперты с отдельным сайтом или порталом. Забавно, что копируя их, нас начали копировать начиная с бусти, приложением, а теперь уже и с сайтом (хотя было предсказуемо). Но как бы ты не пытался скопировать по глубокой ссылке — ты всегда будешь копией. Можно легко зафактчекнуть время анонсов, релизов и тп.
И так, кто меня вдохновляет как эксперт, и чьи методы мы будем переосмысливать:
1. Gergely Orosz. Мобильный инженер с большим опытом, автор многих книг и статей. Фокусируется на архитектурах и систем дизайне. Здесь я убедился, что лучшие эксперты в сисдизе и архитектурах — это те, кто работал на проекте с 30 и более iOS инженерами и сотнями модулями. У них другое качество контента. Не обросшее неактуальным академическим багажом или не копирует рефакторинг гуру.
2. Tanishq Abraham. Автор neetcode. Инженер, работающий в гугле. Сделал свою альтернативу литкоду, которая начала приносить сотни тысяч $ в месяц. Это не просто копия, а переосмысление платформы.
3. Авторы Essential Developer. Практиков сразу видно. Еще один сайт, где лучшие инженеры делятся лучшими знаниями про систем дизайн и архитектуру. На их полноценный курс я не накопил деньги, но когда-нибудь сделаем полноценный обзор. В их словах чувствуется опыт долгих запусков, а раставленные акценты помогают почувствовать их глубокое понимание проблем практикующих спецов.
4. Bruno Rocha. Автор SwiftRocks и Senior iOS инженер в моем любимом приложении Spotify. Это единственный автор, который скорее пишет рандомные статьи, а не выстраивает сложную образовательную систему, но мне нравится его контент и можно сказать что это единственный позновательный сайт на тему "обо всем" для меня.
5. objc.io. Я не покупал подписку у pointfree, потому что считаю objc.io на порядок лучше. Они делают крутой контент, пишут свои аналоги движков SwiftUI и подходят более инженерно к решениям проблемы. Не используя стратегию монетизации "вилка и комплектующие"
6. Tjeerd in ’t Veen. Еще один эксперт по mobile system design. Нравится комплексность подхода и акценты на важных производственных деталях.
Копируйте лучших. Пусть мы не будем похожими на них, но хоть не будем выглядить кринжово. А какие референсы у тебя?
Ты то, что ты ешь.
В этом году я буду делать больше изменений в блоге. Из любительского уровня и быстрых набросков — выйти на чуть более серьезную инфлюенсерскую ступень. Мне повезло попасть в крутой отдел яндекса User Generated Content, где есть создание инструментов социальных сетей. Можно сказать, что блоги теперь часть моей профессии) Я увидел здесь СИГНАЛ С КОСМОСА и поэтому надо не упускать шанса поэкспериментировать с этим всем.
Но при этом оставить тот живой запал. Не только делиться тем, что накипело и набухло внутри, но и уже слушать и слышать аудиторию. Лучше понимать ее как работяга работяг. Сближаться и коммуницировать. Качать эмпатию.
Вчера, на одной из встреч с крутыми людьми, профессионалами своего дела, меня спросили: "Какие твои любимые блогеры?". А я даже и не знаю. В подписках канала у меня всего 2-3 профессиональных автора из СНГ, а остальные — это западные эксперты с отдельным сайтом или порталом. Забавно, что копируя их, нас начали копировать начиная с бусти, приложением, а теперь уже и с сайтом (хотя было предсказуемо). Но как бы ты не пытался скопировать по глубокой ссылке — ты всегда будешь копией. Можно легко зафактчекнуть время анонсов, релизов и тп.
И так, кто меня вдохновляет как эксперт, и чьи методы мы будем переосмысливать:
1. Gergely Orosz. Мобильный инженер с большим опытом, автор многих книг и статей. Фокусируется на архитектурах и систем дизайне. Здесь я убедился, что лучшие эксперты в сисдизе и архитектурах — это те, кто работал на проекте с 30 и более iOS инженерами и сотнями модулями. У них другое качество контента. Не обросшее неактуальным академическим багажом или не копирует рефакторинг гуру.
2. Tanishq Abraham. Автор neetcode. Инженер, работающий в гугле. Сделал свою альтернативу литкоду, которая начала приносить сотни тысяч $ в месяц. Это не просто копия, а переосмысление платформы.
3. Авторы Essential Developer. Практиков сразу видно. Еще один сайт, где лучшие инженеры делятся лучшими знаниями про систем дизайн и архитектуру. На их полноценный курс я не накопил деньги, но когда-нибудь сделаем полноценный обзор. В их словах чувствуется опыт долгих запусков, а раставленные акценты помогают почувствовать их глубокое понимание проблем практикующих спецов.
4. Bruno Rocha. Автор SwiftRocks и Senior iOS инженер в моем любимом приложении Spotify. Это единственный автор, который скорее пишет рандомные статьи, а не выстраивает сложную образовательную систему, но мне нравится его контент и можно сказать что это единственный позновательный сайт на тему "обо всем" для меня.
5. objc.io. Я не покупал подписку у pointfree, потому что считаю objc.io на порядок лучше. Они делают крутой контент, пишут свои аналоги движков SwiftUI и подходят более инженерно к решениям проблемы. Не используя стратегию монетизации "вилка и комплектующие"
6. Tjeerd in ’t Veen. Еще один эксперт по mobile system design. Нравится комплексность подхода и акценты на важных производственных деталях.
Копируйте лучших. Пусть мы не будем похожими на них, но хоть не будем выглядить кринжово. А какие референсы у тебя?