Детальный разбор Hashable & Equatable
Когда-то обычные работяги сами высчитывали хэш-значение у структур. Тогда приходилось быть математиком и писать свои хэш-функции. Но эпл сжалился над нами и дал инструмент, который существенно упрощает жизнь.
Протокол Hashable сильно помог. Он упростил жизнь и дал работать с коллекциями почти без коллизий, дав hasher, который легко сгенерирует уникальный хэш. Но что же сделать, если все же коллизии образовались? Тут есть еще одно решение как Equatable
Equatable помогает нам дополнительно проверить наши свойства эквивалентность. Тем самым дополнительно защищая нас от коллизии
Как он работает разберем в скриншотах, а недавно я писал детальную статью
Ссылки для чтения:
- Organize data using arrays, sets, and dictionaries.
- Hashable withe equtable
- Equatable docs
Когда-то обычные работяги сами высчитывали хэш-значение у структур. Тогда приходилось быть математиком и писать свои хэш-функции. Но эпл сжалился над нами и дал инструмент, который существенно упрощает жизнь.
Протокол Hashable сильно помог. Он упростил жизнь и дал работать с коллекциями почти без коллизий, дав hasher, который легко сгенерирует уникальный хэш. Но что же сделать, если все же коллизии образовались? Тут есть еще одно решение как Equatable
Equatable помогает нам дополнительно проверить наши свойства эквивалентность. Тем самым дополнительно защищая нас от коллизии
Как он работает разберем в скриншотах, а недавно я писал детальную статью
Ссылки для чтения:
- Organize data using arrays, sets, and dictionaries.
- Hashable withe equtable
- Equatable docs
Приходите на вечеринку Yandex Summer Mobile Party!
Яндекс устраивает летнюю вечеринку для мобильных разработчиков. Встречаемся в Санкт-Петербурге 19 июля, чтобы познакомиться и обсудить последние новости!
В этот раз обойдёмся без хардовых докладов и долгих обсуждений работы. В программе — короткие лайтнинги о жизни в мобильной разработке, много нетворкинга, вечеринка, музыка и коктейли.
А ещё вас ждёт PeerLab от команд Яндекс Такси, Про, Маркета, Еды и Доставки — камерная активность, где можно предложить свой кейс для обсуждения с топ-экспертами.
Регистрируйтесь уже сейчас. Мы рассмотрим вашу заявку и пришлём приглашение 16–17 июля.
Повеселимся на Yandex Summer Mobile Party! 🎉
Яндекс устраивает летнюю вечеринку для мобильных разработчиков. Встречаемся в Санкт-Петербурге 19 июля, чтобы познакомиться и обсудить последние новости!
В этот раз обойдёмся без хардовых докладов и долгих обсуждений работы. В программе — короткие лайтнинги о жизни в мобильной разработке, много нетворкинга, вечеринка, музыка и коктейли.
А ещё вас ждёт PeerLab от команд Яндекс Такси, Про, Маркета, Еды и Доставки — камерная активность, где можно предложить свой кейс для обсуждения с топ-экспертами.
Регистрируйтесь уже сейчас. Мы рассмотрим вашу заявку и пришлём приглашение 16–17 июля.
Повеселимся на Yandex Summer Mobile Party! 🎉
База честных отзывов о компаниях
Эту базу просили многие в комьюнити. Институт репутации должен кто-то создавать.
Врут не только кандидаты на собесах, но и компании. Я против лжи в любой форме и много раз ошибался, когда мне навешали хорошей лапши на финалке. После этого я подробно спрашиваю у всех работяг, кто там работал, прежде чем принять оффер.
Многие компании, мягко говоря, преувеличивают свои условия труда. Рассказывая на собесах, докладах, вечеринках много приукрашенной информации. Вместо честной работы над собой, внутри и своими процессами, они много инвестируют на образ снаружи.
А самая ценная и честная часто узнается на неофициальных встречах или любительских сходках. Так, например, я узнал о честных условиях только после одного из трудойстройств, где на условном кофе и коде много раз приходили разрабы этой компании и давали честные отзывы. Знал бы я их фидбэк раньше, то так бы не обжегся.
Поэтому хочу создать свою базу честных отзывов. В этом опросе мы в комьюнити хотим собрать базу честных отзывов о компаниях. Сколько твой опыт работы. Что понравилось, а что нет. Какие обещания сдерживают, а какие нет.
Пройдите его, пожалуйста. Опрос анонимный
Эту базу просили многие в комьюнити. Институт репутации должен кто-то создавать.
Врут не только кандидаты на собесах, но и компании. Я против лжи в любой форме и много раз ошибался, когда мне навешали хорошей лапши на финалке. После этого я подробно спрашиваю у всех работяг, кто там работал, прежде чем принять оффер.
Многие компании, мягко говоря, преувеличивают свои условия труда. Рассказывая на собесах, докладах, вечеринках много приукрашенной информации. Вместо честной работы над собой, внутри и своими процессами, они много инвестируют на образ снаружи.
А самая ценная и честная часто узнается на неофициальных встречах или любительских сходках. Так, например, я узнал о честных условиях только после одного из трудойстройств, где на условном кофе и коде много раз приходили разрабы этой компании и давали честные отзывы. Знал бы я их фидбэк раньше, то так бы не обжегся.
Поэтому хочу создать свою базу честных отзывов. В этом опросе мы в комьюнити хотим собрать базу честных отзывов о компаниях. Сколько твой опыт работы. Что понравилось, а что нет. Какие обещания сдерживают, а какие нет.
Пройдите его, пожалуйста. Опрос анонимный
Google Docs
Опрос для базы честных отзывов
Многие компании мягко преувеличивают свои условия труда. Рассказывая на собесах, докладах, вечеринках много приукрашенной информации. А самая ценная и честная часто узнается на неофициальных встречах или любительских сходках
В этом опросе мы в комьюнити…
В этом опросе мы в комьюнити…
Advanced Core Image
Пока лучший материал за неделю. Автор статьи погружает вглубь работы CImage и учит как делать прикольные фильтры для изображений.
В этой статье хорошо структурировано:
🟣 как работают цветовые фильтры
🟣 деформации
🟣 текстуры
Одним из моих рабочих проектов был видеоредактор. Сейчас он уже умер как проект, но его исходники ядра, которое управляет видео и аудио, я иногда изучаю и освежаю знания, чтобы глубже разобрать работу с низкоуровневой графикой. Это отличная статья для рефреша знаний
Ставь лайк, если устал от алгосов и проектирования, и хочешь чего-то с краской кнопок
Пока лучший материал за неделю. Автор статьи погружает вглубь работы CImage и учит как делать прикольные фильтры для изображений.
В этой статье хорошо структурировано:
Одним из моих рабочих проектов был видеоредактор. Сейчас он уже умер как проект, но его исходники ядра, которое управляет видео и аудио, я иногда изучаю и освежаю знания, чтобы глубже разобрать работу с низкоуровневой графикой. Это отличная статья для рефреша знаний
Ставь лайк, если устал от алгосов и проектирования, и хочешь чего-то с краской кнопок
Please open Telegram to view this post
VIEW IN TELEGRAM
Jacob’s Tech Tavern
Advanced Core Image
Use Metal to create custom Core Image kernels
Как переоценивают важность архитектурных паттернов UI
На одном собесе мне задали такой вопрос, ответ на который я так и не успел спросить что от меня ожидали, но я часто встречаю его в финтехах. Вопрос звучал как-то так:
Мой первый вопрос был "Что скрывается под словом архитектура?". Ведь странно было, если бы на сроки влиял такой вопрос как MVP или VIPER. За годы моего опыта в аутсорсах и запусков мвп в бигтехах, вопрос каким паттерном разделять UI слой никогда не стоял остро. Сроки срывали другие проблемы. Архитектура это все же гораздо более сложный вопрос чем разница VIPER vs MVC, SOLID и в чем отличия между фреймворками DI. О нем основательно задумываются на гораздо более зрелой стадии.
Но интервьюер все же сказал про MVP или VIPER. Честно, я не считаю, что это главная проблема в вопросах инвестиций проекта. Мой ответ был, что архитектура это чуть другое, а не выбор на какие слои я буду делить экран. Есть и другие слои, которые уходят в сторону нетворка, кэширования, пушей, стейт менеджмента, управление зависимостями и других модулей. В каком файле лежат мои кнопки — не самый сложный и острый вопрос.
Самым верным и дешевым решением, которое нужно для проверки гипотез, это сокращение сроков. А на сроки влияет релиз. Поэтому я бы сделал максимально простое приложение на MVC и со сторибордами. Или вообще бы ограничился webview. Потому что оно помогает нам обойти сложный процесс релизов и апрувов AppStore. Например, корни BDUI идут оттуда. А недавно Озон Банк рассказал почему сделали на вебвью. Такое решение точно бы помогло нам решить проблему раскатки быстрых гипотез и посмотреть как быстро мы получаем рост и адопшен наших фич.
Как в этом во всем нам помогают такие вопросы выбора MVP или MVC я, честно, не понимаю. Я много раз задумывался над этим вопросом и наблюдал разницу, как ребята из iOS на VIPER быстрее делали простые фичи и релизы, чем ребята из андроида на MVC, который более подходил к такому проекту. Повлияло ли кол-во абстракций на скорость? Отчасти может повлиять, VIPER я бы точно не рисковал тащить в МВП проект. Но является ли этот вопрос ключевым? Нет
Делитесь своими ответами на такой вопрос
На одном собесе мне задали такой вопрос, ответ на который я так и не успел спросить что от меня ожидали, но я часто встречаю его в финтехах. Вопрос звучал как-то так:
"Вы приходите на новый проект где будете один. Нужно в быстрые сроки сделать МВП. Где по итогам запуска будет принято решение: либо проект выстреливает и понадобится расширение команды с быстрым Т2М, либо проект не выстреливает и закрывается. Какую архитектуру вы выберете и почему"
Мой первый вопрос был "Что скрывается под словом архитектура?". Ведь странно было, если бы на сроки влиял такой вопрос как MVP или VIPER. За годы моего опыта в аутсорсах и запусков мвп в бигтехах, вопрос каким паттерном разделять UI слой никогда не стоял остро. Сроки срывали другие проблемы. Архитектура это все же гораздо более сложный вопрос чем разница VIPER vs MVC, SOLID и в чем отличия между фреймворками DI. О нем основательно задумываются на гораздо более зрелой стадии.
Но интервьюер все же сказал про MVP или VIPER. Честно, я не считаю, что это главная проблема в вопросах инвестиций проекта. Мой ответ был, что архитектура это чуть другое, а не выбор на какие слои я буду делить экран. Есть и другие слои, которые уходят в сторону нетворка, кэширования, пушей, стейт менеджмента, управление зависимостями и других модулей. В каком файле лежат мои кнопки — не самый сложный и острый вопрос.
Самым верным и дешевым решением, которое нужно для проверки гипотез, это сокращение сроков. А на сроки влияет релиз. Поэтому я бы сделал максимально простое приложение на MVC и со сторибордами. Или вообще бы ограничился webview. Потому что оно помогает нам обойти сложный процесс релизов и апрувов AppStore. Например, корни BDUI идут оттуда. А недавно Озон Банк рассказал почему сделали на вебвью. Такое решение точно бы помогло нам решить проблему раскатки быстрых гипотез и посмотреть как быстро мы получаем рост и адопшен наших фич.
Как в этом во всем нам помогают такие вопросы выбора MVP или MVC я, честно, не понимаю. Я много раз задумывался над этим вопросом и наблюдал разницу, как ребята из iOS на VIPER быстрее делали простые фичи и релизы, чем ребята из андроида на MVC, который более подходил к такому проекту. Повлияло ли кол-во абстракций на скорость? Отчасти может повлиять, VIPER я бы точно не рисковал тащить в МВП проект. Но является ли этот вопрос ключевым? Нет
Делитесь своими ответами на такой вопрос
Какое поведение ожидаем?
Anonymous Quiz
18%
Будет утечка памяти: вызовется только Setup, text
40%
Утечки памяти не будет: Setup, text, Deinit A, Deinit B
14%
Утечка памяти будет только в классе A: Setup, text, Deinit B
11%
Учетка памяти будет только в классе B: Setup, text, Deinit A
5%
Будет ошибка компляции
12%
Другой ответ
Продвинутый разбор как работает Git
Уметь работать с гитом — одно из обязательных требований разрабов любой платформы. Часто, мы почти не задумываемся как он работает. Используя готовые приложения интуитивно пушим, пулим, ребейзим и мерджим.
Но гит — мощнее, чем нам кажется.
Уметь работать с гитом — одно из обязательных требований разрабов любой платформы. Часто, мы почти не задумываемся как он работает. Используя готовые приложения интуитивно пушим, пулим, ребейзим и мерджим.
Но гит — мощнее, чем нам кажется.
YouTube
So You Think You Know Git - FOSDEM 2024
Scott Chacon's FOSDEM 2024 talk on Git Tips and Tricks and why he's working on GitButler now (https://gitbutler.com)
Scott talks about:
00:00 - Introduction
01:06 - About Me (well, Scott Chacon)
02:36 - How Well Do You Know Git?
05:09 - Our Agenda
06:25…
Scott talks about:
00:00 - Introduction
01:06 - About Me (well, Scott Chacon)
02:36 - How Well Do You Know Git?
05:09 - Our Agenda
06:25…
Новый формат разборов разных задач из реальной практики. Здесь я решил не делать всякие сборники, которые имеют минимальную усваемость. А детально разбирать какую-то одну задачу, иттеративно усложняя.
В этом примере разберем задачу с двумя классами:
Please open Telegram to view this post
VIEW IN TELEGRAM
По своему прогрессу вижу, как подход вдумчивого решения алгоритмов, гораздо более эффективный слепого решения задач в литкоде.
Так, прежде чем взяться за решение задачи, я сначала хочу определить ее паттерн. Какую технику лучше применить?
Их не очень много, но достаточно, чтобы потратить время. Одна из таких техник — это prefix sum.
Когда нужно работать с суммами элементов подмассивов.
Основная идея — создать массив prefix, где prefix[i] равно сумме всех элементов до i индекса включительно.
Статьи для изучения
Задачи для закрепления:
Please open Telegram to view this post
VIEW IN TELEGRAM
Что сложнее бэкэнд или фронт?
Я не делю людей по платформам, языкам программирования или количество синтаксиса в коде.
Все задачи сложные и требуют своих скиллсетов.
Бэкенд требует аналитического мышления и чаще работает с данными. Где нагрузка может положить сервак.
Фронтенд требует уметь видеть результат на многих устройствах, окружениях. Сверстать кнопку без потери качества на разных ОС, браузерах. Выжить среди кол-ва новых технологий.
Здесь нет единой метрики сложности. У всех задачи просто разные.
Хороший тред про frontend и backend
Я не делю людей по платформам, языкам программирования или количество синтаксиса в коде.
Все задачи сложные и требуют своих скиллсетов.
Бэкенд требует аналитического мышления и чаще работает с данными. Где нагрузка может положить сервак.
Фронтенд требует уметь видеть результат на многих устройствах, окружениях. Сверстать кнопку без потери качества на разных ОС, браузерах. Выжить среди кол-ва новых технологий.
Здесь нет единой метрики сложности. У всех задачи просто разные.
Хороший тред про frontend и backend
Reddit
ballisticbasil's comment on "Are iOS developers considered front end or back end developers?"
Explore this conversation and more from the iOSProgramming community
Сделал сборник вопросов для самопроверки.
В нем затронул:
Please open Telegram to view this post
VIEW IN TELEGRAM
Premium Book Club
Раньше я очень много читал. Книги, по сути, можно сказать, были моим главным источником образования. В 2018 году я прочитал около 100 книг. Тогда я назвал этот период "книжный запой".
Сейчас я грущу, что не могу заставить себя читать много. Либо занят работой, либо чем-то еще.
Книга — это лучший инструмент по сохранению нашей дофаминовой стабильности. Поэтому я хочу вернуть эту привычку и вытеснить все бесполезные просмотры рилсов и видосов полезной активностью.
Книга — это оружие, униформа и еда. Они дают нам связи как нейронные, так и социальные.
Я запускаю вторую версию книжного клуба. В нем мы будем по-новому внедрять эту привычку в жизнь и разбирать только самую важную и полезную литературу.
Первой книгой будет "Принципы". Очень популярная книга, которая является базой для ролевой моделью лидеров и великих людей. Недавно узнал, что это переосмысление другой великой книги "Тысячеликий герой", которая интегрирована в жизни.
Вступайте. Проведем эту жизнь с пользой. Все бесплатно и без подписок)
Раньше я очень много читал. Книги, по сути, можно сказать, были моим главным источником образования. В 2018 году я прочитал около 100 книг. Тогда я назвал этот период "книжный запой".
Сейчас я грущу, что не могу заставить себя читать много. Либо занят работой, либо чем-то еще.
Книга — это лучший инструмент по сохранению нашей дофаминовой стабильности. Поэтому я хочу вернуть эту привычку и вытеснить все бесполезные просмотры рилсов и видосов полезной активностью.
Книга — это оружие, униформа и еда. Они дают нам связи как нейронные, так и социальные.
Я запускаю вторую версию книжного клуба. В нем мы будем по-новому внедрять эту привычку в жизнь и разбирать только самую важную и полезную литературу.
Первой книгой будет "Принципы". Очень популярная книга, которая является базой для ролевой моделью лидеров и великих людей. Недавно узнал, что это переосмысление другой великой книги "Тысячеликий герой", которая интегрирована в жизни.
Вступайте. Проведем эту жизнь с пользой. Все бесплатно и без подписок)
Я понял, что всякие подборки вопросов для закрепления, почти бесполезны без большого и структурированного материала. Ничего на долго не сохраняется на вопросы и ответы. Поэтому решил писать большие и вдумчивые статьи, которые требуют глубокого погружения.
Первую статью я решил посвятить одному из самых труднопонимаемых принципов SOLID, на котором многие пробуксовывают.
В ней я постарался разобраться:
Много кода и примеров.
Please open Telegram to view this post
VIEW IN TELEGRAM
Hashable vs AnyHashable
Мы уже хорошо погружены в работу протокола Hashable. Но часто приходится слышать в чем же отличия Hashable от AnyHashable?
Можно легко разобраться, если мы знаем что такое приставка Any. В статье Type Erasure в Swift мы также детально разбирали как сделать свои контейнеры для протоколов.
🟣 Когда пригодится AnyHashable?
Представим кейс, когда нужно использовать Set с любыми типами, которые будут хэшебл.
Первое, что приходит в голову, написать код вот так:
Но мы получим ошибку компиляции. Поэтому на помощь приходит наш Type Erasure AnyHashable:
Так мы избавимся от ошибки компиляции и решим нашу задачу
Мы уже хорошо погружены в работу протокола Hashable. Но часто приходится слышать в чем же отличия Hashable от AnyHashable?
Можно легко разобраться, если мы знаем что такое приставка Any. В статье Type Erasure в Swift мы также детально разбирали как сделать свои контейнеры для протоколов.
Представим кейс, когда нужно использовать Set с любыми типами, которые будут хэшебл.
Первое, что приходит в голову, написать код вот так:
let collection = Set<Hashable>()
Но мы получим ошибку компиляции. Поэтому на помощь приходит наш Type Erasure AnyHashable:
let collection = Set<AnyHashable>()
Так мы избавимся от ошибки компиляции и решим нашу задачу
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Воробей
Сорри, одинаковые фотки скинули: разбираем новинки с презентации Galaxy Unpacked
🎧 Наушники у Samsung лучше — они двухдрайверные и Lossless поддерживают
⌚ Часы ярче и громче, чем Apple Watch. Это лайк
А вот систему One UI почти всю стыбзили у Apple. Дизлайк
А вот систему One UI почти всю стыбзили у Apple. Дизлайк
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM