Responder Chain, или как правильно передавать действия пользователя между компонентами
В данной статье, вам расскажут о том, как предельно легко перенаправлять действия пользователя внутри приложения без ненужных усложнений — с помощью нативного инструмента под названием Responder Chain.
В данной статье, вам расскажут о том, как предельно легко перенаправлять действия пользователя внутри приложения без ненужных усложнений — с помощью нативного инструмента под названием Responder Chain.
This media is not supported in your browser
VIEW IN TELEGRAM
SwiftUI Custom Drop Down Menu Component
Делюсь с вами пользовательским компонентом выпадающего меню. Вьюха представляет собой простой, интерактивный и удобный способ представления списка опций, из которых пользователь может выбирать что-то. Этот компонент полезен для упрощения форм, фильтров и интерфейсов настроек, обеспечивая компактное представление для множества вариантов.
Делюсь с вами пользовательским компонентом выпадающего меню. Вьюха представляет собой простой, интерактивный и удобный способ представления списка опций, из которых пользователь может выбирать что-то. Этот компонент полезен для упрощения форм, фильтров и интерфейсов настроек, обеспечивая компактное представление для множества вариантов.
This media is not supported in your browser
VIEW IN TELEGRAM
SwiftUI custom loading indicator
Этот кастомный лоадер — лишь отправная точка. Вы можете экспериментировать с различными анимациями, формами и цветами, чтобы создать свой кастомный лоадер.
Этот кастомный лоадер — лишь отправная точка. Вы можете экспериментировать с различными анимациями, формами и цветами, чтобы создать свой кастомный лоадер.
Всем привет!
Сегодня у меня 25-й день рождения. И в этот день для меня ценным подарком является то, что я делаю, и ваша поддержка. Если вы хотите поддержать меня и Катю, присоединяйтесь к нашему сообществу. Будем ждать в закрытом чате, где каждый день к нам присоединяются новые люди, и мы делаем классное комьюнити.
Мы сняли для вас выпуск про карьеру и лидерство в IT. И уже скоро выложим его, а также на следующей неделе будет mock system design interview и много других выпусков.
Всем спасибо!
Сегодня у меня 25-й день рождения. И в этот день для меня ценным подарком является то, что я делаю, и ваша поддержка. Если вы хотите поддержать меня и Катю, присоединяйтесь к нашему сообществу. Будем ждать в закрытом чате, где каждый день к нам присоединяются новые люди, и мы делаем классное комьюнити.
Мы сняли для вас выпуск про карьеру и лидерство в IT. И уже скоро выложим его, а также на следующей неделе будет mock system design interview и много других выпусков.
Всем спасибо!
Удобная навигация в SwiftUI для iOS 16 и выше
Для тех, кто хочет решить вопрос с навигацией в SwiftUI на iOS 16 и выше, предлагаю ознакомиться с этой статьей. Здесь подробно рассматривается NavigationStack с гибким подходом, примерами кода и готовой реализацией.
Для тех, кто хочет решить вопрос с навигацией в SwiftUI на iOS 16 и выше, предлагаю ознакомиться с этой статьей. Здесь подробно рассматривается NavigationStack с гибким подходом, примерами кода и готовой реализацией.
Улучшения TextField в SwiftUI
С самого первого выпуска фреймворка SwiftUI текстовые поля были слабым местом. На протяжении многих лет Apple вносила несколько улучшений в текстовые поля, чтобы облегчить работу разработчиков.
В статье приводятся примеры наиболее распространённых проблем, с которыми сталкиваются разработчики при работе с TextField и их постепенное решение по мере развития фреймворка.
С самого первого выпуска фреймворка SwiftUI текстовые поля были слабым местом. На протяжении многих лет Apple вносила несколько улучшений в текстовые поля, чтобы облегчить работу разработчиков.
В статье приводятся примеры наиболее распространённых проблем, с которыми сталкиваются разработчики при работе с TextField и их постепенное решение по мере развития фреймворка.
Карьера и лидерство в IT
🎧 Выпустили новый эпизод подкаста о лидерстве и карьере в IT! Вместе с Дмитрием мы обсудили эффективные стратегии построения карьеры, ключевые лидерские качества для успеха в IT-сфере, и разобрали сложный вопрос о "накрутке" опыта: плюсы, минусы и реальные последствия.
💬 Телеграм-канал Дмитрия
💬 Менторство Дмитрия
#digest
🎧 Выпустили новый эпизод подкаста о лидерстве и карьере в IT! Вместе с Дмитрием мы обсудили эффективные стратегии построения карьеры, ключевые лидерские качества для успеха в IT-сфере, и разобрали сложный вопрос о "накрутке" опыта: плюсы, минусы и реальные последствия.
💬 Телеграм-канал Дмитрия
💬 Менторство Дмитрия
#digest
С днём рождения, Катя!🔥
Желаю тебе интересных проектов, творческого вдохновения, легких дедлайнов и всегда позитивного настроя! Пусть все твои задумки реализуются, а жизнь будет полна ярких красок и успехов. Счастья тебе, здоровья и всего самого наилучшего!
Желаю тебе интересных проектов, творческого вдохновения, легких дедлайнов и всегда позитивного настроя! Пусть все твои задумки реализуются, а жизнь будет полна ярких красок и успехов. Счастья тебе, здоровья и всего самого наилучшего!
Forwarded from Путь к CEO (18+) | Борцов Дмитрий
Всех уволю к чертям собачьим!
Вчера наткнулся на занимательный пост (читать только психически стабильным), в котором некто Денис Теплов (директор по продукту в Лиге Ставок) похвастался, что уволил сотрудника, когда узнал, что у него есть вторая работа, попутно назвав эту компанию «куколдами» и предложил сделать «реестр пидорасов», куда бы попадали все, кто работает в IT на нескольких работах сразу.
Хочу объяснить своим подписчикам, ведь среди вас есть те, кто планирует расти в руководящие позиции, почему главный «куколд» в этой истории — автор поста.
Специфика IT такова, что у разработчика существует условный КПД. Возьмём за эталон 100%. Это тот случай, когда разработчик пишет безошибочно код и не отвлекается на ютубчик и чатики ровно 8 часов в день. Надеюсь, всем понятно, что это утопия. В реальности ожидаемый КПД разработчика — 60%.
Это будет отличный результат для компании.
Но процессы и планирование, особенно в хороших компаниях, учитывают ещё и то, что от 60% отнимается ещё около 40% на организационные моменты: встречи, обсуждения, раскопки в коде и другие активности, не направленные на движение продукта вперёд.
Итого мы получаем цифру продуктивности в 40% от «утопического КПД». Путем нехитрых манипуляций, мы с вами узнали, что из 8 часов среднестатистический разработчик двигает компанию вперёд +- 3,5 часа.
Видите, к чему я веду? Правильно. Если у разработчика две работы, где есть прозрачные процессы, то у него получается 3,5 ч. + 3,5 ч. продуктивной и спокойной работы разработчика. Ровно из-за того, что такие расчёты применимы в большинстве компаний, практически всё IT или работает на двух работах, или основа + какой-то фриланс. Если кто-то не работает на двух работах в текущий момент времени, значит, он работал, но устал. Так как всё-таки ему нужно работать вдвое больше, чем его «базовый КПД».
Давайте попробуем понять логику Дениса. Он НЕ ставит тезис, что задачи разработчик начинает выполнять долго и с низким качеством, что побудило его инициировать увольнение. Единственный пункт, который там есть — две работы у сотрудника.
Какие основные задачи и KPI у бизнеса? Верно. Развитие и стабильность продукта плюс соблюдение сроков и квартальных планов.
Если у тебя всё работает как часы, тебе важно, сколько работ у твоих сотрудников? Адекватному руководителю/директору — нет.
Если у тебя в компании ставят заранее завышенные требования к развитию продукта (не учитывая ни capacity команд, ни рост бизнес-отдела, не закладывает форс-мажоры), то тут, извините, вопросы не к сотрудникам. Когда компания вместо ожидаемых 40% КПД требует от сотрудников 80%, то она заранее соглашается на то, что сотрудники начнут выгорать, уставать, класть болт, и на дистанции это неминуемо приведёт к провалу всех сроков и/или снижению качества продукта и текучке в компании. В итоге все разговоры с Денисом свелись к тому тезису:"Качество страдает!! И вообще у него офф.договор с нами!11!!1! пыщ-пыщ-пыщ (слюна полетела во все стороны)". Но в процессе лёгкого обсуждения выяснилось, что они и так и так уволили бы сотрудника, ведь к его качеству и скорости были вопросы. Причина тут абсолютно не важна. Будь то вторая работа, просто усталость, потеря вовлеченности или любая другая альтернативная причина — работник перестал справляться с обязанностями. Компания с ним прощается.
Не будьте как Денис.
Путь к СЕО (18+). Подписаться
Другие соц.сети:
📷 Instagram
Вчера наткнулся на занимательный пост (читать только психически стабильным), в котором некто Денис Теплов (директор по продукту в Лиге Ставок) похвастался, что уволил сотрудника, когда узнал, что у него есть вторая работа, попутно назвав эту компанию «куколдами» и предложил сделать «реестр пидорасов», куда бы попадали все, кто работает в IT на нескольких работах сразу.
Хочу объяснить своим подписчикам, ведь среди вас есть те, кто планирует расти в руководящие позиции, почему главный «куколд» в этой истории — автор поста.
Специфика IT такова, что у разработчика существует условный КПД. Возьмём за эталон 100%. Это тот случай, когда разработчик пишет безошибочно код и не отвлекается на ютубчик и чатики ровно 8 часов в день. Надеюсь, всем понятно, что это утопия. В реальности ожидаемый КПД разработчика — 60%.
Это будет отличный результат для компании.
Но процессы и планирование, особенно в хороших компаниях, учитывают ещё и то, что от 60% отнимается ещё около 40% на организационные моменты: встречи, обсуждения, раскопки в коде и другие активности, не направленные на движение продукта вперёд.
Итого мы получаем цифру продуктивности в 40% от «утопического КПД». Путем нехитрых манипуляций, мы с вами узнали, что из 8 часов среднестатистический разработчик двигает компанию вперёд +- 3,5 часа.
Видите, к чему я веду? Правильно. Если у разработчика две работы, где есть прозрачные процессы, то у него получается 3,5 ч. + 3,5 ч. продуктивной и спокойной работы разработчика. Ровно из-за того, что такие расчёты применимы в большинстве компаний, практически всё IT или работает на двух работах, или основа + какой-то фриланс. Если кто-то не работает на двух работах в текущий момент времени, значит, он работал, но устал. Так как всё-таки ему нужно работать вдвое больше, чем его «базовый КПД».
Давайте попробуем понять логику Дениса. Он НЕ ставит тезис, что задачи разработчик начинает выполнять долго и с низким качеством, что побудило его инициировать увольнение. Единственный пункт, который там есть — две работы у сотрудника.
Какие основные задачи и KPI у бизнеса? Верно. Развитие и стабильность продукта плюс соблюдение сроков и квартальных планов.
Если у тебя всё работает как часы, тебе важно, сколько работ у твоих сотрудников? Адекватному руководителю/директору — нет.
Если у тебя в компании ставят заранее завышенные требования к развитию продукта (не учитывая ни capacity команд, ни рост бизнес-отдела, не закладывает форс-мажоры), то тут, извините, вопросы не к сотрудникам. Когда компания вместо ожидаемых 40% КПД требует от сотрудников 80%, то она заранее соглашается на то, что сотрудники начнут выгорать, уставать, класть болт, и на дистанции это неминуемо приведёт к провалу всех сроков и/или снижению качества продукта и текучке в компании. В итоге все разговоры с Денисом свелись к тому тезису:"Качество страдает!! И вообще у него офф.договор с нами!11!!1! пыщ-пыщ-пыщ (слюна полетела во все стороны)". Но в процессе лёгкого обсуждения выяснилось, что они и так и так уволили бы сотрудника, ведь к его качеству и скорости были вопросы. Причина тут абсолютно не важна. Будь то вторая работа, просто усталость, потеря вовлеченности или любая другая альтернативная причина — работник перестал справляться с обязанностями. Компания с ним прощается.
Не будьте как Денис.
Путь к СЕО (18+). Подписаться
Другие соц.сети:
Please open Telegram to view this post
VIEW IN TELEGRAM
Apple работает над складывающимся планшетом
По словам Марка Гурмана из Bloomberg, Apple намерена выпустить свой первый складной планшет в 2028 году. Гурман описывает его как «нечто сродни гигантскому iPad, который раскладывается до размеров двух iPad Pro».
Слухи о складных устройствах Apple ходят уже несколько лет, но, по данным Bloomberg, Apple наконец-то остановилась на одном продукте, который будет выпущен через несколько лет.
В отчете также говорится, что Apple хочет избежать складок на своих устройствах, и этому уделялось большое внимание во время разработки. В настоящее время складки практически незаметны, но Apple еще предстоит устранить их полностью:
В развернутом виде дисплей будет иметь размер около 20 дюймов. Гурман описывает его как «единый, непрерывный кусок стекла». Устройство также описывается как «higher-end устройство».
По словам Марка Гурмана из Bloomberg, Apple намерена выпустить свой первый складной планшет в 2028 году. Гурман описывает его как «нечто сродни гигантскому iPad, который раскладывается до размеров двух iPad Pro».
Слухи о складных устройствах Apple ходят уже несколько лет, но, по данным Bloomberg, Apple наконец-то остановилась на одном продукте, который будет выпущен через несколько лет.
В отчете также говорится, что Apple хочет избежать складок на своих устройствах, и этому уделялось большое внимание во время разработки. В настоящее время складки практически незаметны, но Apple еще предстоит устранить их полностью:
В развернутом виде дисплей будет иметь размер около 20 дюймов. Гурман описывает его как «единый, непрерывный кусок стекла». Устройство также описывается как «higher-end устройство».
iOS Такой в сетке
Пишем про iOS и не только. Подписывайтесь на нас в сетке =)
Что вы найдете на нашей странице:
Новости и обзоры устройств Apple
Советы и инструкции по использованию iOS
Обсуждения актуальных тем и тенденций
Пишем про iOS и не только. Подписывайтесь на нас в сетке =)
Что вы найдете на нашей странице:
Новости и обзоры устройств Apple
Советы и инструкции по использованию iOS
Обсуждения актуальных тем и тенденций
SRNetworkManager — современный сетевой слой
SRNetworkManager — это мощный и гибкий сетевой уровень для приложений Swift. Он обеспечивает ориентированный на протоколы и дженерики подход к обработке API-запросов, поддерживая как Combine, так и парадигму async/await. Этот пакет разработан как простой в использовании, хорошо настраиваемый и полностью совместимый со Swift 6 и протоколом Sendable.
SRNetworkManager — это мощный и гибкий сетевой уровень для приложений Swift. Он обеспечивает ориентированный на протоколы и дженерики подход к обработке API-запросов, поддерживая как Combine, так и парадигму async/await. Этот пакет разработан как простой в использовании, хорошо настраиваемый и полностью совместимый со Swift 6 и протоколом Sendable.
GitHub
GitHub - siamakrostami/SRNetworkManager: SRNetworkManager is a powerful and flexible networking layer for Swift applications. It…
SRNetworkManager is a powerful and flexible networking layer for Swift applications. It provides a generic, protocol-oriented approach to handling API requests, supporting both Combine and async/aw...
Interview System Design
Сегодня у нас в гостях вновь наш старый друг Александр Сычёв, и мой коллега по работе Влад Бац. Ребята провели мок-интервью, mobile system design. Совместно спроектировали фичу мобильного приложения. Участники определили требования к фиче приложения.
Разработали архитектуру, обсудили различные альтернативные подходы и оценили масштабируемость и надежность проектируемой системы.
Для тех, у кого плохо работает ютуб, мы добавили выпуск в ВК видео, рутуб и на наш бусти.
Смотрите данный выпуск, будет очень интересно!
💬 Т-Г канал Саши @headOfMobile
😎 Школа разработчиков KTS @metaclass
Сегодня у нас в гостях вновь наш старый друг Александр Сычёв, и мой коллега по работе Влад Бац. Ребята провели мок-интервью, mobile system design. Совместно спроектировали фичу мобильного приложения. Участники определили требования к фиче приложения.
Разработали архитектуру, обсудили различные альтернативные подходы и оценили масштабируемость и надежность проектируемой системы.
Для тех, у кого плохо работает ютуб, мы добавили выпуск в ВК видео, рутуб и на наш бусти.
Смотрите данный выпуск, будет очень интересно!
Please open Telegram to view this post
VIEW IN TELEGRAM
SwiftUI: Всё, что вам нужно знать о модификаторе containerRelativeFrame (и немного больше)
На WWDC 2023 компания Apple представила модификатор представления containerRelativeFrame для SwiftUI. Этот модификатор упрощает некоторые операции размещения элементов на экране, которые ранее было сложно выполнить обычными методами. В этой статье мы подробно рассмотрим модификатор containerRelativeFrame, его определение, правила компоновки, примеры использования и важные соображения. Чтобы еще больше расширить наше понимание его функциональных возможностей, в конце статьи мы также создадим обратно совместимую реплику containerRelativeFrame для старых версий SwiftUI.
На WWDC 2023 компания Apple представила модификатор представления containerRelativeFrame для SwiftUI. Этот модификатор упрощает некоторые операции размещения элементов на экране, которые ранее было сложно выполнить обычными методами. В этой статье мы подробно рассмотрим модификатор containerRelativeFrame, его определение, правила компоновки, примеры использования и важные соображения. Чтобы еще больше расширить наше понимание его функциональных возможностей, в конце статьи мы также создадим обратно совместимую реплику containerRelativeFrame для старых версий SwiftUI.
Сегодня в 18:00 с Катей проведём прямой эфир. Подведем итоги года, поговорим про iOS, рынок, новые технологии и тд. Подключайтесь, задавайте вопросы ☺️🫶