Судя по опросу в номинации «самое лучшее приложение Яндекса» - выиграло Яндекс карты.
Давайте поиграем в игру. Какой, любой технический или маркетинговый вопрос, вы бы задали их разрабам?
Нужна ваша помощь. Лучший вопрос попробую донести до них.
Давайте поиграем в игру. Какой, любой технический или маркетинговый вопрос, вы бы задали их разрабам?
Нужна ваша помощь. Лучший вопрос попробую донести до них.
Forwarded from Сиолошная
Я: пишу про необходимость изменения собеседований в эпоху AI
META: начинает шевелиться
Тот-самый-азиат:
Перевод:
META: начинает шевелиться
Тот-самый-азиат:
Перевод:
Слышал об собеседующем из ByteDance, который проводил удаленное собеседование. Способ, которым он решил поймать кандидата на жульничестве с использованием ИИ, был настолько наивным, что это даже абсурдно.
Интервьюер внезапно сказал: «Закройте глаза и ответьте на этот вопрос».
Forwarded from Young Da Code — Pizza Powered iOS (Kirill Smirnov)
Когда-то давно, лет 10 назад (у меня была задача: получать пачку данных с сервера, находить различия с кэшем и красиво обновлять UITableView, чтобы не было резких reload'ов, а всё плавно вставлялось, удалялось и двигалось.
Тогда задача обошлась мне, не в один день анализа и проектирования, чтобы научиться сравнивать старый и новый массивы.
Тогда ещё не было никакого CollectionDifference, и я просто пошёл реализовывать алгоритм Вагнера–Фишера и работать с вычислением: расстояния Левенштейна и редакционноого предписания - минимального количества действий и их последовательности чтобы из "ABC" получилось "ACD".
Ну и конечно, всё это руками прикручивалось к performBatchUpdates:
tableView.performBatchUpdates {
tableView.deleteRows(at: ...)
tableView.insertRows(at: ...)
}
Весело? Не очень. Но тогда по-другому никак.
Потом, с приходом iOS 13 и Swift 5.1, всё изменилось.
Apple выкатили DiffableDataSource, и вместе с ним — CollectionDifference.
Это была буквально революция, теперь можно просто сформировать снапшот и отдать его таблице:
var snapshot = NSDiffableDataSourceSnapshot<Section, Item>()
snapshot.appendSections([.main])
snapshot.appendItems(items)
dataSource.apply(snapshot, animatingDifferences: true)
UITableView сама всё поймёт, сама вычислит, что вставить, что удалить, что переместить — и сделает это с анимацией.
А мы — просто передаём новое состояние.
Если копнуть глубже, то под капотом лежит алгоритм Майерса.
Он также находит минимальную последовательность изменений между двумя массивами.
Apple реализует его для CollectionDifference.
Можно глянуть исходники Swift или вот обьяснение алгоритма.
Но если хочется больше контроля или скорости — есть и альтернативы.
Например, DifferenceKit, который использует алгоритм Пола Хекеля.
Вот сам код.
Он быстрее в ряде кейсов, особенно если много данных, на это влияет сложность O(n), бенчмарки можно посмотреть на gh.
И с ним сделали даже backport - DiffableDataSource для старых iOS.
Мораль истории: задача сравнения последовательностей — стара как мир.
Её решают в UI, в git, в текстовых редакторах.
А теперь и мы — наконец-то — можем делать это в UITableView, не теряя нервы на написание сложных алгоритмов и работу с indexPath-ами.
#L #UITableView #DiffableDataSource #CollectionDifference #LevenshteinDistance
Please open Telegram to view this post
VIEW IN TELEGRAM
Swiftrocks
How Collection Diffing works in Swift
Ordered Collection Diffing is a feature added in Swift 5.1 that allows you to calculate and apply the difference between two collections. Using diffing libraries is common in iOS for a few reasons, the most popular one being to handle the addition and removal…
Отпускной контент
Я же взял курс по аи-креаторству. Как делать крутые ролики и контент с помощью нейросетей. Поэтому ждите здесь первые труды. Буду спаривать образовательный контент с креативом.
Мне лично очень нравится художники, что уже не стесняются юзать аи-тулкиты. В правильных руках нейронки умножают твой талант.
Главная цель любого труда - насмотренность. Будь это аналитика конкурентов в стерильной коммерции. Живой опыт реальных экспертов. Референсы художников на кино лайк Тарантино.
Вот и я иногда культурно обогащаюсь. В полет закачал книги и фильмы, что давно хотел посмотреть и послушать.
1. The Northman (2022). Лучший дарк-фэнтези, что я посмотрел в этом году. Вайбы Берсерка и Саги о Винланде присутствуют.
Я долго откладывал кино, но являясь любителем жанра эпоса, не мог устоять. Это самый красивый фильм о викингах. Каждые 5-10 лет для меня открываются свои фавориты в фольклорных эпосах.
В 2010х - это «Вальгала» от Рефна с Миккельсеном.
В 2015 «Макбет» Курзеля с Фасбендером.
В 2020 неплохой «King» с Шалламе.
В 2025 же охеренный «The Northman» Эггерса.
2. «Человек-бензопила: История Резе». Я фанат мангаки. Мне нравится его FirePunch. Огромное кол-во отсылок на кино с прямыми заимствованиями и цитатами. Неординарный стиль и пост-модернизм.
Музыка и история первого сезона вдохновили прочитать еще пару лет назад всю мангу целиком. Тогда я очень ждал анонса этой одной из самых красивых историй. И судя по шуму в сети - экранизация очень удалась.
Перечитаю мангу.
3. «Братья Карамазовы» Достоевский. В эпоху нейронок нам все же не хватает естественности и живости. Следующий год я объявил для себя — годом классической литературы. Я хочу оживить речь и стиль.
Даже этот пост я начал писать потому что нужно размывать немного границы и уходить от фокуса только технического контента.
А почему начал с Достоевского? Потому что любимый автор.
Я же взял курс по аи-креаторству. Как делать крутые ролики и контент с помощью нейросетей. Поэтому ждите здесь первые труды. Буду спаривать образовательный контент с креативом.
Мне лично очень нравится художники, что уже не стесняются юзать аи-тулкиты. В правильных руках нейронки умножают твой талант.
Главная цель любого труда - насмотренность. Будь это аналитика конкурентов в стерильной коммерции. Живой опыт реальных экспертов. Референсы художников на кино лайк Тарантино.
Вот и я иногда культурно обогащаюсь. В полет закачал книги и фильмы, что давно хотел посмотреть и послушать.
1. The Northman (2022). Лучший дарк-фэнтези, что я посмотрел в этом году. Вайбы Берсерка и Саги о Винланде присутствуют.
Я долго откладывал кино, но являясь любителем жанра эпоса, не мог устоять. Это самый красивый фильм о викингах. Каждые 5-10 лет для меня открываются свои фавориты в фольклорных эпосах.
В 2010х - это «Вальгала» от Рефна с Миккельсеном.
В 2015 «Макбет» Курзеля с Фасбендером.
В 2020 неплохой «King» с Шалламе.
В 2025 же охеренный «The Northman» Эггерса.
2. «Человек-бензопила: История Резе». Я фанат мангаки. Мне нравится его FirePunch. Огромное кол-во отсылок на кино с прямыми заимствованиями и цитатами. Неординарный стиль и пост-модернизм.
Музыка и история первого сезона вдохновили прочитать еще пару лет назад всю мангу целиком. Тогда я очень ждал анонса этой одной из самых красивых историй. И судя по шуму в сети - экранизация очень удалась.
Перечитаю мангу.
3. «Братья Карамазовы» Достоевский. В эпоху нейронок нам все же не хватает естественности и живости. Следующий год я объявил для себя — годом классической литературы. Я хочу оживить речь и стиль.
Даже этот пост я начал писать потому что нужно размывать немного границы и уходить от фокуса только технического контента.
А почему начал с Достоевского? Потому что любимый автор.
1
Forwarded from Голос из-под шторки | Миша Левченко
Эмпатичность в собеседованиях
Пока мы на теме найма. Я сейчас обучаю парочку людей в компании проводить собеседования и хотел поделиться одним приниципом, которому я всегда следую, собеседуя людей: эмпатичность.
Цель любого технического собеседования – получить сигналы о том, подходят ли кандидаты на должность, на которую собеседуются. Ещё раз, цель – не "уничтожить" кандидатов, не "провести им экзамен", не "вывести их на чистую воду". Цель – получить достаточно информации о требуемых для позиции навыках.
Поэтому во-первых, нужно чётко сформулировать – а какие навыки мы хотим проверить и как. И явно донести кандидатам, какой навык мы сейчас проверяем, что от них требуется продемонстрировать. Если тебе кажется, что знание об этом может как-то помешать проверить навык – значит ты что-то делаешь не так. Если задача составлена таким образом что основная проблема – это ДОГАДАТЬСЯ что от тебя хотят – мы проверяем догадливость, а не какой-то рабочий навык. Ну и самое главное – нужно убедиться что задача проверяет именно "навык", а не некоторое "знание". Поэтому я терпеть не могу опросники. Можно часами рассуждать про java memory model а потом не суметь обнаружить и устранить гонку в простейшем коде.
Во-вторых: для кандидатов собеседование – это всегда новая и стрессовая ситуация. Для собеседующего – это просто обычный день на работе. Особенно если собесы поставлены на поток, как в Яндексе. Люди в стрессовых ситуациях ведут себя не так, как в обычной жизни. А нам надо проверить, как они будут себя вести в обычной каждодневной работе! Поэтому, чтобы максимизировать сигнал от кандидатов – их нужно по возможности избавить от стресса. Улыбнуться, спросить как дела, про погоду там, ещё что-то. Объяснить как будет проходить интервью, сколько задач предстоит решить. Дать выбрать порядок решения задач, если это возможно. В общем нужно провести некий ритуал общественного поглаживания и сделать обстановочку чуть более безопасной.
Казалось бы простые и очевидные вещи, но их приходится проговаривать снова и снова. Теперь хоть смогу ссылку кидать. И ты сможешь
Пока мы на теме найма. Я сейчас обучаю парочку людей в компании проводить собеседования и хотел поделиться одним приниципом, которому я всегда следую, собеседуя людей: эмпатичность.
Цель любого технического собеседования – получить сигналы о том, подходят ли кандидаты на должность, на которую собеседуются. Ещё раз, цель – не "уничтожить" кандидатов, не "провести им экзамен", не "вывести их на чистую воду". Цель – получить достаточно информации о требуемых для позиции навыках.
Поэтому во-первых, нужно чётко сформулировать – а какие навыки мы хотим проверить и как. И явно донести кандидатам, какой навык мы сейчас проверяем, что от них требуется продемонстрировать. Если тебе кажется, что знание об этом может как-то помешать проверить навык – значит ты что-то делаешь не так. Если задача составлена таким образом что основная проблема – это ДОГАДАТЬСЯ что от тебя хотят – мы проверяем догадливость, а не какой-то рабочий навык. Ну и самое главное – нужно убедиться что задача проверяет именно "навык", а не некоторое "знание". Поэтому я терпеть не могу опросники. Можно часами рассуждать про java memory model а потом не суметь обнаружить и устранить гонку в простейшем коде.
Во-вторых: для кандидатов собеседование – это всегда новая и стрессовая ситуация. Для собеседующего – это просто обычный день на работе. Особенно если собесы поставлены на поток, как в Яндексе. Люди в стрессовых ситуациях ведут себя не так, как в обычной жизни. А нам надо проверить, как они будут себя вести в обычной каждодневной работе! Поэтому, чтобы максимизировать сигнал от кандидатов – их нужно по возможности избавить от стресса. Улыбнуться, спросить как дела, про погоду там, ещё что-то. Объяснить как будет проходить интервью, сколько задач предстоит решить. Дать выбрать порядок решения задач, если это возможно. В общем нужно провести некий ритуал общественного поглаживания и сделать обстановочку чуть более безопасной.
Казалось бы простые и очевидные вещи, но их приходится проговаривать снова и снова. Теперь хоть смогу ссылку кидать. И ты сможешь
К теме собесов, часто вижу сотни критик, но 0 предложений. Давайте вместе определим Самую эффективную секцию для хорошего собеседования?
Anonymous Poll
33%
Задачи на логику и кодинг. Что-то среднее между алгоритмами и лайфкодингом
37%
Только задачи на платформу. Много лайфкодинга, мало квизов.
10%
Квизы. От лайфкодинга люди стрессуют
44%
Систем дизайн и архитектуры. Много практики и неопределености. Минимум шаблонных ответов.
9%
Скринингов на 30 минут достаточно
20%
Зачем нужны собесы? Нанимайте сразу так.
5%
Другое
Architecture & Culture инженеры
Мне безумно нравятся проекты, где команда взрослеет до того момента, когда появляются роли, отвечающие не за "закрыть задачу", а за добавить осознанности в саму разработку.
Это те люди, которые приходят в проект не с вопросом "что нужно сделать?", а "почему мы делаем это именно так?"
Ставь лайк, если в твоем проекте не хватает Architecture & Culture инженеров
Мне безумно нравятся проекты, где команда взрослеет до того момента, когда появляются роли, отвечающие не за "закрыть задачу", а за добавить осознанности в саму разработку.
Это те люди, которые приходят в проект не с вопросом "что нужно сделать?", а "почему мы делаем это именно так?"
Ставь лайк, если в твоем проекте не хватает Architecture & Culture инженеров
2
2025: Год, когда SwiftUI умер
Мне повезло. На текущем проекте я могу использовать и SwiftUI, и SC, тк минимальный таргет сейчас 16 iOS. Поэтому я могу щупать это прям на многомиллионом приложении с дедлайнами, багами, автотестами и зависимостями.
До сих пор, почти 80% кто разбирает или пишет про эти технологии — никогда не юзали это в реальном проде. Серьезно, вы даже удивитесь как мало реального опыта у тех, кто вещает на конференциях или пишет статьи.
С 2019 года идут слухи, что SwiftUI станет единственным фреймворком. Но мы уже давно пишем, что этого не будет. Всегда на больших проектах будет UIKit + SwiftUI. Что-то одно не заменит другое. Это два разных инструмента.
Вот и автор статьи уверяет, что 2025 год стал поворотным для SwiftUI. Он перестал быть общепринятым выбором.
Основные аргументы автора:
🟣 UIKit обновился. Добавился @Observable который убил один из аргументов, что UIKit не реактивен.
🟣 Скорость верстки увеличилась с ИИ. Раньше говорили, что на SwiftUI быстрее пишешь код и верстаешь, но ии-агенты обнулили аргумент и теперь скорость везде одинакова.
🟣 Ограниченный SwiftUI. Хоть на дворе 2к25, но у SwiftUI до сих пор есть проблемы с производительностью и гибкостью.
Многое из этого мы уже прямо или косвенно обсуждали в SwiftUI System Design Interview
Ну а вы как считаете cтоит ли хоронить SwiftUI?
Ставь💀 если так и не трогал SwiftUI в проде.
Мне повезло. На текущем проекте я могу использовать и SwiftUI, и SC, тк минимальный таргет сейчас 16 iOS. Поэтому я могу щупать это прям на многомиллионом приложении с дедлайнами, багами, автотестами и зависимостями.
До сих пор, почти 80% кто разбирает или пишет про эти технологии — никогда не юзали это в реальном проде. Серьезно, вы даже удивитесь как мало реального опыта у тех, кто вещает на конференциях или пишет статьи.
С 2019 года идут слухи, что SwiftUI станет единственным фреймворком. Но мы уже давно пишем, что этого не будет. Всегда на больших проектах будет UIKit + SwiftUI. Что-то одно не заменит другое. Это два разных инструмента.
Вот и автор статьи уверяет, что 2025 год стал поворотным для SwiftUI. Он перестал быть общепринятым выбором.
Основные аргументы автора:
Многое из этого мы уже прямо или косвенно обсуждали в SwiftUI System Design Interview
Ну а вы как считаете cтоит ли хоронить SwiftUI?
Ставь
Please open Telegram to view this post
VIEW IN TELEGRAM
Jacobstechtavern
2025: The year SwiftUI died
Rediscovering my love for the Classic UIKit Stack™