Обмен культурой через социальные сети
Побыв минимально без социальных сетей прошлый месяц я понял их минусы, а главное плюсы.
Выключая этот источник информации ты выпадешь из контекста. Не сечешь в мемах как дед. Как не понимать почему среди разрабов правильно ЭйАрСи, а не АРК.
Ты далек от той практикующей среды, которая наполнена своими шутками и деталями. Ведь ее неидеальность и устройство возможно понять только находясь в ней, варясь. А не наблюдая сбоку через переводчики.
Ты слышишь, как человек говорит, какие мемы он юзает, и уже понимаешь «свой» или «чужой». Кто в тренде, а кто устарел.
Мне самому было сложно находить себя в профессии. Я не знал, у кого спросить, что нормально, а что странно. Именно поэтому мне захотелось собрать вокруг этого канала людей, у которых можно поучиться, дружески посоперничать, по-доброму позавидовать.
Профессиональная культура — это заразительно. Если работа — твой дом, то соцсети — улицы, где можно встретить единомышленников, вдохновиться витриной чужого опыта и самому стать ориентиром. Это все становится родным городом, политика которого тебе не безразлична.
Важно только стараться не задерживаться в черных районах дольше рекомендованного.
В век асинхронных коммуникаций в мессенджере и удаленных созвонов в зуме мы начали строить свои цифровые общества. Заполнять одиночество, созданным ковидом, через чаты и аватары.
Как бы мы не доказывали, что все мы работаем исключительно ради денег, но это не так.
Мы ищем атмосферу, ценности, подходы. Иначе бы конференции и блоги имели только одну тему. В сухую цифру и мертвые метрики дохода.
Культура — не только о «офис с едой по бейджу» и офферы, а про уважение, рост, поддержку, процессы. Публичность создает доверие.
Культура не живёт в вакууме. Формируется коллективная мудрость. Кто-то делится кейсом, а кто-то добавляет контрпример — рождается новое понимание.
Формулируя и делясь лучше понимаешь свои и чужие ценности и подходы.
Делитесь не только результатами, но и процессом. Не бойтесь быть уязвимыми ведь культура создается живыми людьми.
Каждый пост или коммент это не хвастовство, а вклад в общее развитие системы.
Побыв минимально без социальных сетей прошлый месяц я понял их минусы, а главное плюсы.
Выключая этот источник информации ты выпадешь из контекста. Не сечешь в мемах как дед. Как не понимать почему среди разрабов правильно ЭйАрСи, а не АРК.
Ты далек от той практикующей среды, которая наполнена своими шутками и деталями. Ведь ее неидеальность и устройство возможно понять только находясь в ней, варясь. А не наблюдая сбоку через переводчики.
Ты слышишь, как человек говорит, какие мемы он юзает, и уже понимаешь «свой» или «чужой». Кто в тренде, а кто устарел.
Мне самому было сложно находить себя в профессии. Я не знал, у кого спросить, что нормально, а что странно. Именно поэтому мне захотелось собрать вокруг этого канала людей, у которых можно поучиться, дружески посоперничать, по-доброму позавидовать.
Профессиональная культура — это заразительно. Если работа — твой дом, то соцсети — улицы, где можно встретить единомышленников, вдохновиться витриной чужого опыта и самому стать ориентиром. Это все становится родным городом, политика которого тебе не безразлична.
Важно только стараться не задерживаться в черных районах дольше рекомендованного.
В век асинхронных коммуникаций в мессенджере и удаленных созвонов в зуме мы начали строить свои цифровые общества. Заполнять одиночество, созданным ковидом, через чаты и аватары.
Как бы мы не доказывали, что все мы работаем исключительно ради денег, но это не так.
Мы ищем атмосферу, ценности, подходы. Иначе бы конференции и блоги имели только одну тему. В сухую цифру и мертвые метрики дохода.
Культура — не только о «офис с едой по бейджу» и офферы, а про уважение, рост, поддержку, процессы. Публичность создает доверие.
Культура не живёт в вакууме. Формируется коллективная мудрость. Кто-то делится кейсом, а кто-то добавляет контрпример — рождается новое понимание.
Формулируя и делясь лучше понимаешь свои и чужие ценности и подходы.
Делитесь не только результатами, но и процессом. Не бойтесь быть уязвимыми ведь культура создается живыми людьми.
Каждый пост или коммент это не хвастовство, а вклад в общее развитие системы.
CognitiveComplexity.pdf
547.6 KB
Cognitive Complexity: A New Way of Measuring Understandability
Продолжаем тему рефакторинга. На очереди разбор других инструментов, кроме знакомого всем линтера.
На очереди книга от Sonar.
Традиционная метрика Cyclomatic Complexity (1976 г.) хорошо показывает, сколько тестов нужно, чтобы покрыть код. Но она не показывает, насколько сложно человеку понять этот код.
Два метода могут иметь одинаковую цикломатическую сложность, но один из них будет понятен с первого взгляда, а другой — как клубок спагетти.
Книга предлагает когнитивную сложность — метрику, которая:
🟣 Не основывается на математических моделях, а ориентируется на интуицию разработчиков.
🟣 Учитывает, насколько код сложно читать и понимать.
🟣 Подходит для современных языков (с try/catch, лямбдами, switch и т.д.).
🟣 Дает оценку сложности не только метода, но и целого класса или приложения.
Кому и зачем читать эту книгу:
🔘 Разработчикам, кто хочет писать понятный, поддерживаемый код.
🔘 Лид-инженерам, кто ищет более точные метрики качества.
🔘 Тем, кто внедряет SonarQube или аналитику кода.
Всем, кто хочет уйти от «искусственного» счёта Cyclomatic Complexity к более реальной оценке.
Продолжаем тему рефакторинга. На очереди разбор других инструментов, кроме знакомого всем линтера.
На очереди книга от Sonar.
Книга «Cognitive Complexity: A New Way of Measuring Understandability» от SonarSource описывает новую метрику оценки сложности кода — когнитивную сложность (Cognitive Complexity), как альтернативу классической цикломатической сложности (Cyclomatic Complexity).
Традиционная метрика Cyclomatic Complexity (1976 г.) хорошо показывает, сколько тестов нужно, чтобы покрыть код. Но она не показывает, насколько сложно человеку понять этот код.
Два метода могут иметь одинаковую цикломатическую сложность, но один из них будет понятен с первого взгляда, а другой — как клубок спагетти.
Книга предлагает когнитивную сложность — метрику, которая:
Кому и зачем читать эту книгу:
Всем, кто хочет уйти от «искусственного» счёта Cyclomatic Complexity к более реальной оценке.
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
В прошлом посте канала мы разбирали немного CADisplayLink. Зачем он и где мне помогал на работе или в конкурсах телеграма.
Наш подписчик решил поделиться из своей личной базы подборкой задач на CADisplayLink. Какие-то придумал сам, какие-то похожие давали на собесах.
В них узнаете:
Please open Telegram to view this post
VIEW IN TELEGRAM
На днях в лс мне написали с вопросом:
Привет! Подскажи, пожалуйста, у тебя был пост или какая-либо информация по работе с метриками? Я сейчас стараюсь выстроить флоу работы с метриками в iOS приле (имею ввиду техническими). Как настроить мониторинг и алертинг, как это все к бизнес процессам привязать, итд )
Для меня это отдельная большая тема, которую можно и поштормить, и в канале написать. Поэтому сказал я технично ушел от ответа, сказав что напишу посты в канале на эту тему
В целом вопрос отличный и всегда актуальный: Как привязать технические метрики к бизнес значениям? Мы коммерческие разработчики, и каждый наш шаг и секунду нужно защищать перед бизнесом. Метрики без бизнес value — бесполезные.
Пока в плане таких метрик лучше всего на моем опыте был Авито. Да и опрашивая других не могу найти решений лучше на рынке.
Например:
Почему это важно для бизнеса? Любой баг — это потерянные деньги. На инцидент анализе, очень нехорошем процессе при разборе бага, могут выявить, что ваш баг можно было отловить покрыв код тестами.
А есть сын маминой подруги. Оценка его модуля 8 из 10. Все чисто, круто, новый шмот и аккуратность. Приятная и современная архитектура. Вероятно, когда ты будешь работать с ним, проблем никаких не будет.
В общем, я поделился лишь малой частью метрик. В будущем мб детально распишу это все. Как раз и для меня это актуально.
А вы можете помочь нашему подписчику и поделиться своим опытом.
Please open Telegram to view this post
VIEW IN TELEGRAM
Deploying Machine Learning Models with Vapor and Core ML
Сейчас будет абсолютно непродающий пост.
Еще немного про советы коллегам. Всем молодым ребятам, которые спрашивают нужно ли изучать iOS разработку в 16 лет я говорю — не нужно:)
Будь это знакомые, дети знакомых, родственники. На мой взгляд, популярность мобильной разработки и в целом фронтенда, особенно с развитием ИИ, сильно падает. Прошли те времена, когда за покрашенную кнопку дают кучу бабок. Сейчас мобилка становится сложнее и конкурентнее.
А вот ИИ бабки гребет и следующее десятилетие точно за ней. В среднем, я и мои знакомые только за подписки на курсоры и чатгпт отдают от 100$. Где- пользуются от силы этим всем 20% времени. Что это значит? Что в ии сейчас много пузыря и скама, как когда-то было в мобилках, фронте и бэке. А может быть и больше всех вместе взятых. Каждый ИИ плагин или обертка над чатгпт стоит от 20$ за месяц. Очевидно там много оверпрайса.
Ну в общем статья для тех, кто хочет аккуратно свитчнуться в ML и начинает с внедрения в мобилку
Стоит ли идти в иос разработку в 16 лет? Зависит от цели. Если вам нравится программирование и айфоны - да. Если нужны легкие деньги, то кмк лучше в мл:)
Сейчас будет абсолютно непродающий пост.
Еще немного про советы коллегам. Всем молодым ребятам, которые спрашивают нужно ли изучать iOS разработку в 16 лет я говорю — не нужно:)
Будь это знакомые, дети знакомых, родственники. На мой взгляд, популярность мобильной разработки и в целом фронтенда, особенно с развитием ИИ, сильно падает. Прошли те времена, когда за покрашенную кнопку дают кучу бабок. Сейчас мобилка становится сложнее и конкурентнее.
А вот ИИ бабки гребет и следующее десятилетие точно за ней. В среднем, я и мои знакомые только за подписки на курсоры и чатгпт отдают от 100$. Где- пользуются от силы этим всем 20% времени. Что это значит? Что в ии сейчас много пузыря и скама, как когда-то было в мобилках, фронте и бэке. А может быть и больше всех вместе взятых. Каждый ИИ плагин или обертка над чатгпт стоит от 20$ за месяц. Очевидно там много оверпрайса.
Ну в общем статья для тех, кто хочет аккуратно свитчнуться в ML и начинает с внедрения в мобилку
Стоит ли идти в иос разработку в 16 лет? Зависит от цели. Если вам нравится программирование и айфоны - да. Если нужны легкие деньги, то кмк лучше в мл:)
Teachable
Deploying Machine Learning Models with Vapor and Core ML
Глупый вопрос лучше глупой ошибки
Недавно я опрашивал сообщество и решил узнать какой самый главный навык выделяет джуна от сеньора.
Многие выделили навык умение задавать правильные вопросы.
На дейлике джун молчит — боится показаться глупым. Сеньор не замолкает — боится не понять.
Джун боится показаться глупым. Сеньор знает, что если не спросишь — сделаешь хуже. Джун не уверен, что имеет право на голос. Сеньор чувствует ответственность за результат.
Многие отметили, что спрашивать — это не значит быть глупым. Это значит быть честным, внимательным и готовым учиться.
Такую же проблему я замечал, когда занимался менторством. Новички часто боятся осуждений за вопрос. Не понимают можно ли его задать. Но чаще чем больше вопросов, тем больше пользы приносит процесс изучения.
Недавно я опрашивал сообщество и решил узнать какой самый главный навык выделяет джуна от сеньора.
Многие выделили навык умение задавать правильные вопросы.
Молчание джуна — это не скромность, а упущенная возможность учиться. Настойчивые вопросы сеньора — не самоуверенность, а способ глубже понимать и делать лучше. Учиться — значит задавать вопросы.
На дейлике джун молчит — боится показаться глупым. Сеньор не замолкает — боится не понять.
Джун боится показаться глупым. Сеньор знает, что если не спросишь — сделаешь хуже. Джун не уверен, что имеет право на голос. Сеньор чувствует ответственность за результат.
Многие отметили, что спрашивать — это не значит быть глупым. Это значит быть честным, внимательным и готовым учиться.
Такую же проблему я замечал, когда занимался менторством. Новички часто боятся осуждений за вопрос. Не понимают можно ли его задать. Но чаще чем больше вопросов, тем больше пользы приносит процесс изучения.
Ты не знаешь как делать задачу. Что будешь делать?
Anonymous Poll
29%
Начну делать как понял, потом разберусь
58%
Поищу решение сам
40%
Спрошу у коллег
64%
Спрошу у чатгпт
11%
Пойду в профильные чаты
35%
Вспомню как гуглить
37%
Обсужу с коллегами
4%
Другое
iOS Makes Me Hate
Ты не знаешь как делать задачу. Что будешь делать?
Кстати, заметьте как почти умерли «профильные чаты». Когда раньше форумы и сообщества были источником обмена инфы и поддержки, то с приходом чатгпт начался их закат.
Deeplink Manager по SOLID принципам
Навигация — это отдельная жопаболь любого разраба. В отличие от веба мы не рисуем по F5 дом дерево. У нас стэк из экранов + жизненный цикл приложения. Поэтому это создает кучу проблем, а также решений.
Разрабы пытались придумать кучу решений:
Паттерн Coordinator, который был популярен, а сейчас многими ненавистен. Роутеры, которые открывают экран последовательно. В SwiftUI вообще куча решений, со своими минусами и плюсами.
Для меня любая навигация, где есть огромный enum с экранами, который создает полотно из switch/case — жесткий костыль. Это не должно быть в проде.
Мобилка в итоге пришла к одному из удобных видов навигаций экранов — это диплинки. Каждый экран имеет свой идшник. Например, главная имеет путь yourapp.ru/1/main . Так мы легко управляем состоянием и создаем простую поддержку кода, не зависив от бойлер плейта.
На скриншотах набросал примерную концепцию на мой взгляд идеального диплинк хендлера. Сделаем в будущем мок-воркшоп по систем дизайну как проектировать навигацию в мобилке.
Навигация — это отдельная жопаболь любого разраба. В отличие от веба мы не рисуем по F5 дом дерево. У нас стэк из экранов + жизненный цикл приложения. Поэтому это создает кучу проблем, а также решений.
Разрабы пытались придумать кучу решений:
Паттерн Coordinator, который был популярен, а сейчас многими ненавистен. Роутеры, которые открывают экран последовательно. В SwiftUI вообще куча решений, со своими минусами и плюсами.
Для меня любая навигация, где есть огромный enum с экранами, который создает полотно из switch/case — жесткий костыль. Это не должно быть в проде.
Мобилка в итоге пришла к одному из удобных видов навигаций экранов — это диплинки. Каждый экран имеет свой идшник. Например, главная имеет путь yourapp.ru/1/main . Так мы легко управляем состоянием и создаем простую поддержку кода, не зависив от бойлер плейта.
На скриншотах набросал примерную концепцию на мой взгляд идеального диплинк хендлера. Сделаем в будущем мок-воркшоп по систем дизайну как проектировать навигацию в мобилке.
This media is not supported in your browser
VIEW IN TELEGRAM
Как я вижу всех неработающих блогеров которые дают «ультимативный гайд по росту в карьере». Предлагая джобхоппинг в 2к25….
Тренера не играют?
P.s. На видео, кстати, никого не осуждаю
Тренера не играют?
P.s. На видео, кстати, никого не осуждаю
Обложка для ронина для подписок из бусти
Почему я ими делюсь? Для меня бусти это скорее место моего развитие. Как виртуальный кабинет, библиотека или мастерская, в которых я храню книги и инструменты. В этом месте должна быть особая атмосфера. Заряжающая на поиск знаний и вдохновляющая.
Хочется, чтобы заходя на него, видно было уважение к своему труду и работу. Поэтому каждую обложку мы руками рисуем от 2-3 недель, перебирая множество вариантов. Ты должен быть доволен результатом.
Почему я ими делюсь? Для меня бусти это скорее место моего развитие. Как виртуальный кабинет, библиотека или мастерская, в которых я храню книги и инструменты. В этом месте должна быть особая атмосфера. Заряжающая на поиск знаний и вдохновляющая.
Хочется, чтобы заходя на него, видно было уважение к своему труду и работу. Поэтому каждую обложку мы руками рисуем от 2-3 недель, перебирая множество вариантов. Ты должен быть доволен результатом.
Разбор Систем дизайн интервью в FAANG
System Design — это уже база. Ушли все вопросы про зубрежку теории, теперь сеньор это не тот, кто только глубоко знает платформу, но и круто проектирует систему. Когда систем дизайн был только в 1-2 компаниях, то теперь он у всех. Так еще и усложнен и переосмыслен.
Я много встречаю заблуждений про систем дизайн:
🌟 "System Design — это про запомнить архитектуру Twitter/YouTube".
Многие думают, что нужно выучить «эталонные» решения известных систем. На самом деле важно не знать, как устроен Twitter, а понимать, как принимать архитектурные решения под конкретные требования.
Хорошая практика развивать умение задавать вопросы:
- Какие ключевые функции есть в приложении?
- Нужно ли офлайн-доступ? Если да, к каким данным?
- Есть ли встроенная авторизация? Каким способом?
🌟 "Нужно сразу прыгать в архитектуру"
Начинают рисовать схемы до того, как разобрались с требованиями. На самом деле System Design — это диалог, а не экзамен по рисованию блоков.
Когда я собесился в яндекс на моей секции мы ничего не рисовали, а общались почти 2,5 часа собирая требования в блокноте. На мой вопрос "а мы откроем миро?" интервьюер прямо сказал "мы убрали эту часть, тк многие кандидаты не на том фокусировались". Мне кажется, это правильное решение.
🌟 "Правильный ответ один"
Все ищут «идеальную» архитектуру. На самом деле почти всегда существует несколько решений, и важно уметь аргументировать свой выбор.
🌟 "System Design — это только для Senior-инженеров"
Многие джуны и мидлы думают, что им рано. System Design — это способ мышления, полезный на любом уровне.
В этом видео также очень хорошо разобраны внутренности систем дизайн интервью и их реальную цель
System Design — это уже база. Ушли все вопросы про зубрежку теории, теперь сеньор это не тот, кто только глубоко знает платформу, но и круто проектирует систему. Когда систем дизайн был только в 1-2 компаниях, то теперь он у всех. Так еще и усложнен и переосмыслен.
Я много встречаю заблуждений про систем дизайн:
Многие думают, что нужно выучить «эталонные» решения известных систем. На самом деле важно не знать, как устроен Twitter, а понимать, как принимать архитектурные решения под конкретные требования.
Хорошая практика развивать умение задавать вопросы:
- Какие ключевые функции есть в приложении?
- Нужно ли офлайн-доступ? Если да, к каким данным?
- Есть ли встроенная авторизация? Каким способом?
Начинают рисовать схемы до того, как разобрались с требованиями. На самом деле System Design — это диалог, а не экзамен по рисованию блоков.
Когда я собесился в яндекс на моей секции мы ничего не рисовали, а общались почти 2,5 часа собирая требования в блокноте. На мой вопрос "а мы откроем миро?" интервьюер прямо сказал "мы убрали эту часть, тк многие кандидаты не на том фокусировались". Мне кажется, это правильное решение.
Все ищут «идеальную» архитектуру. На самом деле почти всегда существует несколько решений, и важно уметь аргументировать свой выбор.
Многие джуны и мидлы думают, что им рано. System Design — это способ мышления, полезный на любом уровне.
В этом видео также очень хорошо разобраны внутренности систем дизайн интервью и их реальную цель
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
#FaangTalk 79 - Разбор Систем дизайн интервью
Канал с анонсами https://t.iss.one/faangtalk_news
Чат по подготовке к интервью: https://t.iss.one/faangtalk
В выпуске разбираем Систем Дизайн Интервью в FAANG на Стаф позицию
Видео https://youtu.be/-wqG7ZBoxmc
В гостях
Max Strakhov https://t.iss.one/faang_career
Dima…
Чат по подготовке к интервью: https://t.iss.one/faangtalk
В выпуске разбираем Систем Дизайн Интервью в FAANG на Стаф позицию
Видео https://youtu.be/-wqG7ZBoxmc
В гостях
Max Strakhov https://t.iss.one/faang_career
Dima…
Как мы доверили качество наших приложений AI
Делюсь видосами с Яндекс Dev Day&Night. Там было много крутых докладов, поэтому будет несколько постов.
Когда я говорил, что AI — это геймченджер индустрии, я не шутил. Крупные компании уже его пихают от кодревью кода до упрощения разработки и тестирования.
Начнем с доклада Лёши, где он рассказал, как наши команды использует AI для тестирования приложений.
В докладе вы увидете:
🔘 сможет ли AI заменить QA?
🔘 Плюсы и минусы тестирования апки с LLM
🔘 Насколько упростилось написание тестов?
🔘 Понизился ли порог входа?
🔘 сэкономились ли время и деньги?
Делюсь видосами с Яндекс Dev Day&Night. Там было много крутых докладов, поэтому будет несколько постов.
Когда я говорил, что AI — это геймченджер индустрии, я не шутил. Крупные компании уже его пихают от кодревью кода до упрощения разработки и тестирования.
Начнем с доклада Лёши, где он рассказал, как наши команды использует AI для тестирования приложений.
В докладе вы увидете:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как мы доверили качество наших приложений AI / Лёша Маслобоев
На Яндекс Dev Day&Night Лёша Маслобоев, старший разработчик мобильной платформы iOS, рассказал про продукт QA AI. Лёша показал, как можно использовать LLM для тестирования приложений, как устроена архитектура проекта и какие метрики ребята используют. А ещё…
Навигация — самая частая тема в вопросах по архитектуре. Много спрашивали в комментариях и личке, что почитать по этой теме. Раньше посоветовать было нечего, но теперь готов закрыть этот запрос.
Начинаю новый цикл статей. В нем мы затронем популярные и неочень навигации на UIKit (Coordinator, router, как работает UINavigationController и многое другое). Плавно перейдя в SwiftUI.
В этой же статье мы детально разберем как сделать Deeplink Handler по SOLID. Какие лучшие практики я видел за свой опыт и как мне они помогли.
Этот контент точно поможет не только на System Design секциях, но и в реальной жизни:
И многое другое.
В цикле будет много кода и примеров.
Please open Telegram to view this post
VIEW IN TELEGRAM
Как создатели ARC отказываются от TCA и SwiftUI
Мы уже разбирали критику TCA. О том, что это далеко неидеальная архитектура, где есть баги с удержанием памяти и исполнением бизнес логики только на главном потоке. От чего перфоманс сложных приложений сильно страдает.
Наш подписчик сообщества, лид крупного проекта, даже расписал пост с основными проблемами.
Вот и авторы браузера Arc, в своем прощальном письме о закрытии продукта, написали что в новом продукте отказываются от TCA и SwiftUI. В письме команда объясняет своё решение перейти к разработке нового продукта — Dia. Основная цель — создать более лёгкий, быстрый и отзывчивый браузер, соответствующий современным требованиям и ожиданиям пользователей.
Почему отказались от TCA и SwiftUI:
🔘 Производительность: TCA и SwiftUI, хотя и предоставляют мощные инструменты для разработки, могут приводить к снижению производительности в больших и сложных приложениях.
🔘 Сложность: С увеличением масштаба приложения архитектура TCA может становиться трудно управляемой, особенно из-за отсутствия чётких границ между экшенами и состояниями, что может приводить к ошибкам и затруднениям в поддержке кода.
🔘 Гибкость: Для реализации новых функций и улучшения отзывчивости интерфейса команда решила использовать более лёгкие и гибкие инструменты, позволяющие быстрее адаптироваться к изменениям и требованиям пользователей.
Ну а мы помним, что нет идеальных технологий. Скорость инфляции знаний или инструментов в ит бешенная. Есть технологии, библиотеки, фреймворки, которые решают хорошо только ограниченный список задач, но не являются универсальной пулей.
Мы уже разбирали критику TCA. О том, что это далеко неидеальная архитектура, где есть баги с удержанием памяти и исполнением бизнес логики только на главном потоке. От чего перфоманс сложных приложений сильно страдает.
Наш подписчик сообщества, лид крупного проекта, даже расписал пост с основными проблемами.
Вот и авторы браузера Arc, в своем прощальном письме о закрытии продукта, написали что в новом продукте отказываются от TCA и SwiftUI. В письме команда объясняет своё решение перейти к разработке нового продукта — Dia. Основная цель — создать более лёгкий, быстрый и отзывчивый браузер, соответствующий современным требованиям и ожиданиям пользователей.
Почему отказались от TCA и SwiftUI:
Ну а мы помним, что нет идеальных технологий. Скорость инфляции знаний или инструментов в ит бешенная. Есть технологии, библиотеки, фреймворки, которые решают хорошо только ограниченный список задач, но не являются универсальной пулей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Substack
Letter to Arc members 2025
On Arc, its future, and the arrival of AI browsers — a moment to answer the largest questions you've asked us this past year.