Сегодня небольшой праздник.
Год, как я решил продолжить себя мотивировать и делать контент. В прошлом году я уже хотел бросить медийку и этот канал, сфокусироваться на другом, уйти в затворничество. Но решил попробовать монетизироваться и стимулировать свой интерес. В итоге, это стало одним из лучших решений, что дало всему новую жизнь и продолжает генерировать идеи на годы вперед. Материальная мотивация все же работает
Ваша поддержка замотивировала меня. С ней мы:
Этот год мы находили себя. Боялись, что удалят и запретят. Заменят нейросети, кроссплатформы и bdui.
Впереди обновление контента и новые иттерации, новые категории: наконец придем в SwiftUI и Swift Concurrency. Будем больше внедрять AI. Станем чуть медийнее, смелее, а формата контента будет еще больше. Мы расширимся и углубимся.
К этой годовщине я опубликовал отрывок из 50 страниц книги, где все об управлении памятью. Я не видел нигде, где вся информация о ней была собрана в одном месте и не разделена на фрагменты.
Это первый драфт и впереди еще много работы. Написание книги процесс намного сложнее, чем я думал. Требует совсем других навыков. Но так лишь интереснее. Теперь буду каждый месяц 14 числа делиться прогрессом по книге.
Всем спасибо за вдохновение и поддержку. Вместе мы формулируем свой стиль и свой вижен. Вместе мы заходим туда и обсуждаем то, куда другие не идут.
Please open Telegram to view this post
VIEW IN TELEGRAM
Продолжаю делиться выдержкой из платного курса по алгоритмам.
Fast and Slow Pointers — это техника работы с двумя указателями, которая:
Эта техника позволяет эффективно решать задачи за O(n) времени и O(1) памяти.
Разберем на примере задач в скриншотах.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Я не случайно выбрал 2025 аркой самураев и начал с книги потока. Ведь эти две темы имеют очень много точек пересечений. Да и вообще вся эстетика японских самураев очень часто находит реинкарнации в массовой культуре: от корней киберпанка до проработки главного супергероя комиксов — бэтмена.
Но это не только эстетичная обертка, но и крутой сборник упражнений для развития. Давайте общими мазками разберем сравнения и как я вижу эти концепции, которые помогут как в жизни, так и в учебе:
Основные характеристики Потока:
Пример: художник настолько увлечён рисованием, что забывает про всё вокруг.
Основные принципы:
Пример: воин, упражняясь в фехтовании, полностью сосредоточен на движении, как на медитации.
Выбрав любой из путей можно прокачивать навыки:
- Глубокой концентрации
- Удовольствие от процесса
- Улучшение памяти и понимания
- Развитие навыков решения проблем
- Экономия временем
Please open Telegram to view this post
VIEW IN TELEGRAM
Карьерный фреймворк от Dropbox
Еще одна матрица компетенций, которая поможет определить разные ожидания от инженеров.
Для многих разработчиков это актуально. Кто-то строит свои матрицы, кто-то хочет узнать лучше рынок. В чатах это регулярный вопрос.
Интересные особенности фреймворка:
🔘 описывает не только технические ожидания, но и лидерские и командные
🔘 фреймворк помогает также оценивать и горизонтальный рост
🔘 универсальность помогает развиваться абсолютно любой роли (дизайнер, менеджер, разраб)
🔘 фреймворк сфокусирован на результатах и навыках, а не на стаже
Еще одна матрица компетенций, которая поможет определить разные ожидания от инженеров.
Для многих разработчиков это актуально. Кто-то строит свои матрицы, кто-то хочет узнать лучше рынок. В чатах это регулярный вопрос.
Интересные особенности фреймворка:
Please open Telegram to view this post
VIEW IN TELEGRAM
Непопулярные инструменты в управлении памятью: Unmanaged
Продолжаю рубрику непопулярных решений в управлении памятью. В прошлом посте мы изучали метод withExtedndedLifetime. Сегодня поиграемся с кое-чем интересным. С MRC в Swift.
Какие задачи решает?
🟣 Старые C/Objective-C API: Например, работа с CoreFoundation, где ARC не применяется.
🟣 Низкоуровневый код: Если нужно добиться максимальной производительности или работы с памятью.
🟣 Тонкая настройка времени жизни объектов: Например, если объект создается в одном потоке, а освобождается в другом.
Полезные статьи:
- How to use Swift's Unmanaged
- Unmanaged by nshipster
Продолжаю рубрику непопулярных решений в управлении памятью. В прошлом посте мы изучали метод withExtedndedLifetime. Сегодня поиграемся с кое-чем интересным. С MRC в Swift.
Unmanaged — это специальный тип в Swift, который позволяет работать с объектами, не управляемыми ARC (Automatic Reference Counting). Его задача — вручную управлять временем жизни объектов (увеличивать или уменьшать их счетчик ссылок), особенно при взаимодействии с кодом на C или Objective-C, где автоматическое управление памятью отсутствует.
Какие задачи решает?
Полезные статьи:
- How to use Swift's Unmanaged
- Unmanaged by nshipster
Please open Telegram to view this post
VIEW IN TELEGRAM
Какой формат контента вы чаще всего используете для образования?
Final Results
36%
Книги
56%
Видео
59%
Статьи
15%
Курсы
26%
Посты в телеграме
38%
Документация
27%
Код
8%
Контент индусов
20%
Сигналы из космоса
4%
Другое
Я короче психанул и сделал огромную подборку в одном месте. Мне так и легче для книги материал сшивать в одну структуру, и рефрешить знания перед любым форматом собеса.
В текущей подборке:
P.S. С комментариями от Глеба Лукьянеца
Это большая подборка вопросов без ответов. Можно использовать ее для подготовки к проведению и прохождению собеседований
Где вы такое видели? Я нигде. Впереди еще больше.
Please open Telegram to view this post
VIEW IN TELEGRAM
Инженер ли ты? Или какой главный навык оценивают на собесе
Даже правильный ответ на собесе не гарантирует успех.
На днях я проводил очередной собес и уже немного устал писать очередной отрицательный фидбэк кандидату. Ребята все приятные, неконфликтные. Часто даже выдают правильные ответы, но с совершенно пустыми глазами или без понимания своих же сказанных слов. Даже немного грустно. Это подвело сформулировать меня какой ключевой навык учат оценивать интервьюеров.
Правило, отказывать или не давать оценку выше начального за отсутствие осознанности, в разной форме написано почти в каждой методичке. Не важно рабочий ли код или правильные ответы на теорию. Интервьюер оценивает наличие навыков, а не их успешную демонстрацию. Правильные же ответы можно найти, а вот какими навыками и базой ты обладаешь для их поиска — гораздо важнее.
Например, гораздо лучше, если кандидат знает какую-то базу и с помощью этой базы может дать пусть и ошибочный ответ, но осознанный. А не выдать правильный и зазубренный, но абсолютно не понимать о чем речь. Ведь так мне сказали в интернетах, менторы или в документации. Я запомнил информацию, но совершенно не понимаю как ей владеть.
Интервьюеры оценивают инженерное мышление. Если кандидат имеет соображалку, то он может скомбинировать из кусков осознанной информации — уникальную. А если это просто набор пустых фрагментов, то непонятно куда это класть и всовывать.
Инженер может проанализировать A, B, C, D решения. Оценить их самостоятельно. Вычленить, разбить на атомы и собрать заново. Ему интересен процесс. В этом его разница от нейросети. Он может понимать контекс и делать ВЫБОР. А также нести ответственность за свое решение.
Ключевые черты инженера:
🟣 Любопытство и желание постоянно учиться. Способность анализировать проблемы и находить эффективные решения. Готовность адаптироваться к изменениям и новым условиям.
🟣 Стремление к созданию новых решений, которые упрощают сложные задачи или улучшают существующие системы. Любой код можно улучшить и сделать вторую версию, привести к редизайну.
🟣 Умение задавать вопросы, проверять предположения и рассматривать проблему с разных точек зрения.
🟣 Теоретические знания должны всегда быть связаны с реальными задачами и их решениями. Если большинство знаний кандидата основано на чужом опыте, то это плохие навыки. Подробнее можно изучить в таксономии Блума
🟣 Постоянное совершенствование. Развитие навыков, поиск новых инструментов и методов для повышения своей эффективности.
Именно это — ядро той самой мифической "инженерности". Без которого все наши навыки и знания сильно упадут в цене.
Даже правильный ответ на собесе не гарантирует успех.
На днях я проводил очередной собес и уже немного устал писать очередной отрицательный фидбэк кандидату. Ребята все приятные, неконфликтные. Часто даже выдают правильные ответы, но с совершенно пустыми глазами или без понимания своих же сказанных слов. Даже немного грустно. Это подвело сформулировать меня какой ключевой навык учат оценивать интервьюеров.
Правило, отказывать или не давать оценку выше начального за отсутствие осознанности, в разной форме написано почти в каждой методичке. Не важно рабочий ли код или правильные ответы на теорию. Интервьюер оценивает наличие навыков, а не их успешную демонстрацию. Правильные же ответы можно найти, а вот какими навыками и базой ты обладаешь для их поиска — гораздо важнее.
Например, гораздо лучше, если кандидат знает какую-то базу и с помощью этой базы может дать пусть и ошибочный ответ, но осознанный. А не выдать правильный и зазубренный, но абсолютно не понимать о чем речь. Ведь так мне сказали в интернетах, менторы или в документации. Я запомнил информацию, но совершенно не понимаю как ей владеть.
Интервьюеры оценивают инженерное мышление. Если кандидат имеет соображалку, то он может скомбинировать из кусков осознанной информации — уникальную. А если это просто набор пустых фрагментов, то непонятно куда это класть и всовывать.
Инженер может проанализировать A, B, C, D решения. Оценить их самостоятельно. Вычленить, разбить на атомы и собрать заново. Ему интересен процесс. В этом его разница от нейросети. Он может понимать контекс и делать ВЫБОР. А также нести ответственность за свое решение.
Ключевые черты инженера:
Именно это — ядро той самой мифической "инженерности". Без которого все наши навыки и знания сильно упадут в цене.
Please open Telegram to view this post
VIEW IN TELEGRAM
Набросали с @itsoveragain прототипы новой аватарки через нейросеть и получилось такое…. Промт был «если бы Apple дизайнили самурая». Понравилась фраза в одном из каналов:
Будем рисовать вручную
скоро контент, созданный
человеком, станет таким же
редким явлением, как сейчас
собранный вручную автомобиль.
Его будут ценить за уникальность,
за страсть создателя, будут
демонстрировать отдельно и
продавать дороже.
Будем рисовать вручную
Forwarded from Тимур Тибеев | BigTechDream (Timur Tibeyev)
- Не пытайся стать синьором, Нео. Это невозможно. Вместо этого просто попробуй осознать истину.
- Какую истину?
- Уровней не существует
Я в последнее время начал больше интересоваться стартапами и разными тусовками. У YCombinator есть серия лекций, под названием “Startup School”. Я бы сказал, что это обширные, но не очень глубокие лекции.
Так вот, одна из лекций называется “Why You Should Leave Your FAANG Job”. Мне прям понравился взгляд на big tech компенсации со стороны. Интересные мнения, а не эти ваши Тимуры и почему стоит идти в BigTech.
🔸Первый инсайт. Всевозможные титулы Junior/Middle/Senior/Staff и это способ вовлечь нас в игру, в бесконечную погоню за следующим уровнем. Игра никогда не кончается, меняются условия квеста.
🔸Второй инсайт. Компания пытается удержать разработчиков страхом недополученной прибыли. Даже те акции, которые еще не завестились, мы уже считаем своими, и как следствие боимся их потерять. Вдобавок к этому, каждый полгода выдают новый пакет акций и игра опять растягивается на несколько лет.
🔸Третий инсайт. “Работать у нас это единственный способ получить опыт работы над высоконагруженными системами“ - это маркетинговый ход MAANG компаний, чтобы привлечь новых сотрудников. Интервью процесс тоже отчасти является частью промо-компании.
🔸Четвертый инсайт - по сути очевидный. Работая в MAANG компаниях, нередко приходится заниматься очень незначительными задачами - перекрашивать пиксели, переписывать сервисы. В стартапах разработчики растут быстрее по хард скиллам.
https://www.startupschool.org/curriculum/why-you-should-leave-your-faang-job
Please open Telegram to view this post
VIEW IN TELEGRAM
Тимур Тибеев | BigTechDream
Помню был период, я всегда уходил в компании, которые оценивали меня ниже всех остальных и не сильно обижали зарплатой в офферах. Типа если платят мидлу как сеьнору, то это ведь круто. Всегда казалось, если я найду середину, то значит и расти есть куда в техничке и зп
Я осознанно наступал на капкан и брал вызовы «ах если вы меня недооценили то я докажу вам». Спустя время я понял, что это были все уловки реверсивной психологии…
Я осознанно наступал на капкан и брал вызовы «ах если вы меня недооценили то я докажу вам». Спустя время я понял, что это были все уловки реверсивной психологии…
Начнем понедельник с разминки.
После 100 вопросов на управлении памятью (это только первая часть) есть амбициозная задача сделать 100 задач на управление памятью. Кстати, этот сборник помог все же мне сократить содержание будущей книги на две: одна техническая, а другая профессиональная
Вот и сейчас я буду фокусироваться только на техничке. Собираю задачи из самых легких, до уникальных и экстремально сложных, которые помогут оценить как глубину теории, так и крепкость практики.
А задача выше из документации. Удивительно, но говорят и с ней бывают проблемы. Она же очень хорошо подходит для разминки и стартовой точкой для обсуждений устройства ARC. Почему и когда происходит очистка, есть ли тут retain cycle и другое.
Скидывайте свои любимые задачи
Please open Telegram to view this post
VIEW IN TELEGRAM
Используете ли вы кроссплатформу на проекте?
Anonymous Poll
7%
Да, используем Flutter
2%
Да, используем React Native
13%
Да, используем KMP
3%
Да, используем другое
1%
Да, но отказываемся
6%
Нет, но хотим
54%
Нет, и не собираемся
3%
Нет, выпилили
11%
Другое
Насколько глубоко надо зарываться
Иногда в чате мы прям пытаемся глубоко зарываться и тут нужны прям артбитры, которые разрулят. Например, Глеб Лукьянец, разработчик из JetBrains, наваливает базы о языке Swift. А кто как не он лучше всего разбирается в памяти и языках.
Вчера, составляя очередную подборку с задачами на память, я наткнулся на вопрос "Как связаны классы и структуры с диспетчеризацией (final/dynamic)". Пытался углубиться, связать кучу со стэком и диспетчеризацию (не просто рассказав о табличных методах диспетчеризации), но тут нам все объяснили в нашем чате на пальцах.
Иногда некоторые вопросы не обязательно должны иметь ответ. И уж если Глеб говорит, что не все надо знать, то стоит прислушаться
Иногда в чате мы прям пытаемся глубоко зарываться и тут нужны прям артбитры, которые разрулят. Например, Глеб Лукьянец, разработчик из JetBrains, наваливает базы о языке Swift. А кто как не он лучше всего разбирается в памяти и языках.
Вчера, составляя очередную подборку с задачами на память, я наткнулся на вопрос "Как связаны классы и структуры с диспетчеризацией (final/dynamic)". Пытался углубиться, связать кучу со стэком и диспетчеризацию (не просто рассказав о табличных методах диспетчеризации), но тут нам все объяснили в нашем чате на пальцах.
Иногда некоторые вопросы не обязательно должны иметь ответ. И уж если Глеб говорит, что не все надо знать, то стоит прислушаться
Forwarded from ermolnik — GDE, Digital Nomad, mobile team lead (Sergei Ermolaev)
Что вы знаете про Perfomance Review?
1 6 6
UIKit: viewIsAppearing
Изучать UIKit в 2к25 кажется уже для скуфов, но он продолжает развиваться и далеко не скоро уйдет с радаров.
Для тех, кто пропустил. Еще в 2023 году в iOS 17 был добавлен новый метод viewIsAppearing.
Чем отличаются viewWillAppear от viewIsAppearing и для чего же он нужен? Этот метод вызывается после viewWillAppear, но до viewDidAppear.
Ранее в viewWillAppear вьюха еще не была добавлена в иерархию и поэтому его размеры и свойства могли быть неточны. А viewDidAppear уже слишком поздный метод.
viewIsAppear дает же нам более точный метод для внесения изменений прям перед самой отрисовкой.
Разберем на примерах
Изучать UIKit в 2к25 кажется уже для скуфов, но он продолжает развиваться и далеко не скоро уйдет с радаров.
Для тех, кто пропустил. Еще в 2023 году в iOS 17 был добавлен новый метод viewIsAppearing.
Чем отличаются viewWillAppear от viewIsAppearing и для чего же он нужен? Этот метод вызывается после viewWillAppear, но до viewDidAppear.
Ранее в viewWillAppear вьюха еще не была добавлена в иерархию и поэтому его размеры и свойства могли быть неточны. А viewDidAppear уже слишком поздный метод.
viewIsAppear дает же нам более точный метод для внесения изменений прям перед самой отрисовкой.
Разберем на примерах