Разбор читаемости
При решении алгоритмических задач в нашем чате постоянно споры по читаемости. Как мы знаем, тема алгоритмов это не только зубрежка самых популярных ответов из чатгпт или ответов из литкода. Это множество скиллов.
Один из них читаемость. Считается, что лаконичный код — признак сеньора. Давайте проведем опрос какой код более вам приятен на примере задачи:
Сравним два решения
Ссылка на задачу в литкоде
При решении алгоритмических задач в нашем чате постоянно споры по читаемости. Как мы знаем, тема алгоритмов это не только зубрежка самых популярных ответов из чатгпт или ответов из литкода. Это множество скиллов.
Один из них читаемость. Считается, что лаконичный код — признак сеньора. Давайте проведем опрос какой код более вам приятен на примере задачи:
Дана строка s, состоящая из английских букв в нижнем регистре. Нужно удалить все соседние одинаковые символы, пока в строке не останется повторов.
📌 Если после удаления образовались новые соседние дубликаты, их тоже нужно удалить – процесс повторяется до тех пор, пока в строке
не останется повторяющихся символов.
Вход: s = "abbaca"
Выход: "ca"
Вход: s = "azxxzy"
Выход: "ay"
Сравним два решения
Ссылка на задачу в литкоде
Есть ли в структурах deinit?
Это один из старых вопросов на собесах. Он показывал насколько кандидат разбирается в памяти. Ответ на этот вопрос был:нет. В структурах нет deinit.
Пропозал SE-0390 вводит концепцию структур и enum'ов, которые нельзя скопировать. А вместо этого позволяет использовать один экземпляр во многих местах.
Появляется новый синтаксис ~Copyable, который означает, что тип не может быть скопирован. Все это, вкупе с borrowing & consuming довольно мощные концепции и сильно помогут в работе. Позже разберем детально.
Есть ли в структурах deinit? Бывает.
Подробнее тут:
- WWDC24: Consume noncopyable types in Swift | Apple
- Noncopyable types in documentation
- Copyable
💰 В ноушене сделал обзор на borrowing, consuming и ~Copyable. А также разобрал частые задачи. Они правда топовые.
Это один из старых вопросов на собесах. Он показывал насколько кандидат разбирается в памяти. Ответ на этот вопрос был:
Пропозал SE-0390 вводит концепцию структур и enum'ов, которые нельзя скопировать. А вместо этого позволяет использовать один экземпляр во многих местах.
Появляется новый синтаксис ~Copyable, который означает, что тип не может быть скопирован. Все это, вкупе с borrowing & consuming довольно мощные концепции и сильно помогут в работе. Позже разберем детально.
Есть ли в структурах deinit? Бывает.
Подробнее тут:
- WWDC24: Consume noncopyable types in Swift | Apple
- Noncopyable types in documentation
- Copyable
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Ваш главный канал демотивации идти в ит
Media is too big
VIEW IN TELEGRAM
Составив 100 вопросов по управлении памятью я понял, что теория < практики. Она полезна для оценки понимания, но всегда важнее практика. Так я начал амбициозную задачу составить 100 задач по каждой теме (память, многопоточка и тп).
В этом сборнике первые 10 задач из цикла. Это новый формат, где я вдохновился литкодом и методичками крупных компаний, шаблонам яндекс.практикума (где я был автором нескольких тем). И в компаниях, где помогал улучшению процессов собеседований.
Формат включает себя:
Так понятнее не только кандидату для подготовки, но и интервьюеру для прохождения. Со временем дойдем и до 100 задач.
А я потихоньку практикуюсь для будущего видеоконтента. Музон для задротов конференций Apple.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Преобразование порядка из хаоса — величайшая черта образования.
Сильнейшей идеей потока оказалась не очевидное и понятное состояние удовольствия от процесса. А куда более глубокая система конструктивных ценностей. Она пронзает множество слоев: от историй государств до семейных отношений. Возможно, эту мысль мне помогла увидеть моя терапия с психологом, но она является ключевой.
Представьте мальчика. Рожденный в этот мир он полон наивности и веры. Но сталкиваясь с трудностями он становится циником.
Обездоленный. Он ищет вину своих неудач в родителях, системе, боге. Такое поведение очень близко особенно в пост-советской культуре.
Его реакция, на пережитую в детстве сильную боль, оказалась деструктивной. Отец заслужил такое поведение и он просто слаб. А я должен разбогатеть. По инерции экстраполируя эту установку на начальника, систему, государство и мир. Только так я выйду из цикла страданий. Но в этой установке нет правды и так мы не исцелимся.
В таких целях мы не найдем счастья. И единственное, что нас накроет — волна хаоса и энтропии. Которая затянет на дно. Ложь на ложь. Месть на месть. Кровь за кровь. Зуб за зуб приводят к бесконечной петли саморазрушения.
Поддаться эмоциям очень просто. Но инерция заведет в ловушку.
Образование — лучшая терапия для менталки. Нужно учиться преобразовывать травмирующие события в цель. А для этого нужно уметь делать порядок из хаоса.
В этом и есть ключевое отличие потока от цикла.
Please open Telegram to view this post
VIEW IN TELEGRAM
Тебе не дадут дополнительную ответственность, если ты не выполняешь хорошо основную
Хард скиллы важнее софт скиллов. Софты переоценены. Каким бы ты не был обаятельным и какие бы смешные анекдоты на работе ты не говорил, но тебя всегда оценивают по результату работы твоей функции.
Во многих компаниях есть правило, что только хороший инженер может стать менеджером. Хотя это два абсолютно разных навыка: менеджерить и инженерить.
Почему тогда это важно? Если ты не справляешься со своей прямой ответственностью, то тебе не дадут дополнительную. Ты не компенсируешь плохой результат смежной работой.
Нужно дойти до определенного уровня качества, чтобы получить новую роль: начать писать бэк не дадут, если плохо красишь кнопки; расти в менеджмент тоже. Плохой инженер не станет хорошим менеджером.
Софт скиллы стоит развивать, когда вышел на удовлетворительный уровень хардов. Никто не захочет брать к себе сотрудника, который отлично веселит команду у кулера, но подставляет срывая дедлайны
Хард скиллы важнее софт скиллов. Софты переоценены. Каким бы ты не был обаятельным и какие бы смешные анекдоты на работе ты не говорил, но тебя всегда оценивают по результату работы твоей функции.
Во многих компаниях есть правило, что только хороший инженер может стать менеджером. Хотя это два абсолютно разных навыка: менеджерить и инженерить.
Почему тогда это важно? Если ты не справляешься со своей прямой ответственностью, то тебе не дадут дополнительную. Ты не компенсируешь плохой результат смежной работой.
Нужно дойти до определенного уровня качества, чтобы получить новую роль: начать писать бэк не дадут, если плохо красишь кнопки; расти в менеджмент тоже. Плохой инженер не станет хорошим менеджером.
Софт скиллы стоит развивать, когда вышел на удовлетворительный уровень хардов. Никто не захочет брать к себе сотрудника, который отлично веселит команду у кулера, но подставляет срывая дедлайны
Essential Developer
Если проводить опрос у iOS разработчиков "какой ютуб канал они считают лучшим для технического роста", то большинство ответит про Essential Developer. Пару человек из нашего чата даже купили на их курсы годовую подписку за 2.5к$.
О чем их тема и откуда такой успех? Ребята правда делают крутые разборы с настоящими практиками. Их контент не очередной курс для вката от менторов с 0.1 годами опыта в стартапах, а мощный в бигтехах. Где они разбирают настоящие проблемы, с которыми сталкиваются рядовые инженеры.
Собрал подборку лучших открытых роликов:
1. Рефакторинг большого проекта. Очень похожая секция, которую дают сейчас на рынке.
2. Clean iOS Architecture: UI Design Patterns. Серия роликов с разбором архитектурных паттернов.
3. Топ вопросов на собеседованиях про архитектуры. Тут все по классике. Возможно, некоторые вопросы устарели, но большинство остаются актуальными.
Тема вката всех заебала. Для своего контента я точно много идей заберу себе.
Если проводить опрос у iOS разработчиков "какой ютуб канал они считают лучшим для технического роста", то большинство ответит про Essential Developer. Пару человек из нашего чата даже купили на их курсы годовую подписку за 2.5к$.
О чем их тема и откуда такой успех? Ребята правда делают крутые разборы с настоящими практиками. Их контент не очередной курс для вката от менторов с 0.1 годами опыта в стартапах, а мощный в бигтехах. Где они разбирают настоящие проблемы, с которыми сталкиваются рядовые инженеры.
Собрал подборку лучших открытых роликов:
1. Рефакторинг большого проекта. Очень похожая секция, которую дают сейчас на рынке.
2. Clean iOS Architecture: UI Design Patterns. Серия роликов с разбором архитектурных паттернов.
3. Топ вопросов на собеседованиях про архитектуры. Тут все по классике. Возможно, некоторые вопросы устарели, но большинство остаются актуальными.
Тема вката всех заебала. Для своего контента я точно много идей заберу себе.
YouTube
Working with legacy iOS codebases: architecture, testing, build times | iOS Dev Live Mentoring
To become a complete Senior iOS Developer, you also need to know how to work effectively with legacy codebases...
And this is what this mentoring session is all about. Including:
- Initializing SDKs lazily (after getting a remote config)
- Inheritance…
And this is what this mentoring session is all about. Including:
- Initializing SDKs lazily (after getting a remote config)
- Inheritance…
Будет ли тут утечка памяти? Если вызовем в методе функцию loadView
Anonymous Poll
28%
Да
46%
Нет
3%
50/50
3%
По ситуации
20%
Посмотреть ответ
Тестирование и понимание условий при решении алгозадач
Чаще самая сложная работа, чтобы решить задачу, — это понять условие. А написание кода всегда вторичное.
В своей компании, с прошлой пятницы, я начал входить в комитет секции алгоритмов. Мы будем развивать и улучшать процесс. Одной из идей на первом созвоне было пересоздать новую секцию, заменив старую. Которая уже отстает от вызовов рынка. Она будет называться программирование 2.0.
Она не будет учитывать знание ОСОБЫХ АЛГОРИТМОВ (красно-черные деревью, динамическое программирование и тп). Но оставит многое из дисциплины problem solving. В ней будут оценки очень важных скиллов для программиста: умение рассуждать, понимать условия, тестировать и находить пограничные кейсы.
Когда вы проходите алгосекцию, то основная задача интервьюера не только оценить конечное ваше решение. Правильное решение очень важно, но куда важнее КАК вы его написали и какие навыки продемонстрировали во время решения.
Решать задачи в тепличных условиях дома и под ограниченное время перед интервьюером — два разных уровня сложности.
На интервью все в разы сложнее. Поэтому мы в чате рекомендуем такой шаблон:
Вот например яндекс дает с одной стороны очень простые задачи, но всегда с бесячим кол-вом пограничных кейсов. В литкоде таких тоже много.
Разберем задачу Simplify Path на скриншотах. Она попадалась в некоторые команды яндекса.
Чаще самая сложная работа, чтобы решить задачу, — это понять условие. А написание кода всегда вторичное.
В своей компании, с прошлой пятницы, я начал входить в комитет секции алгоритмов. Мы будем развивать и улучшать процесс. Одной из идей на первом созвоне было пересоздать новую секцию, заменив старую. Которая уже отстает от вызовов рынка. Она будет называться программирование 2.0.
Она не будет учитывать знание ОСОБЫХ АЛГОРИТМОВ (красно-черные деревью, динамическое программирование и тп). Но оставит многое из дисциплины problem solving. В ней будут оценки очень важных скиллов для программиста: умение рассуждать, понимать условия, тестировать и находить пограничные кейсы.
Когда вы проходите алгосекцию, то основная задача интервьюера не только оценить конечное ваше решение. Правильное решение очень важно, но куда важнее КАК вы его написали и какие навыки продемонстрировали во время решения.
Решать задачи в тепличных условиях дома и под ограниченное время перед интервьюером — два разных уровня сложности.
На интервью все в разы сложнее. Поэтому мы в чате рекомендуем такой шаблон:
🟣 Ставить таймер на каждую задачу в 20-30 минут🟣 Проговаривать решение вслух. Стараться это делать последовательно🟣 Сдавать максимально проработанное решение. На интервью — как на экзамене. Каждая пересдача неправильного решения это минус балл.🟣 Учитывать все корнер кейсы.
Вот например яндекс дает с одной стороны очень простые задачи, но всегда с бесячим кол-вом пограничных кейсов. В литкоде таких тоже много.
Разберем задачу Simplify Path на скриншотах. Она попадалась в некоторые команды яндекса.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы думаете что знаете Swift?
Swift становится очень мощным языком и выходит за границы мира iOS. Все больше пишется кроссплатформ и серверов на нем.
Знание языка и владение им на продвинутом уровне — признак скилла разработчика. Я не думаю, что ИИ заменит разработчиков во всем. Люди все равно знают лучше редкие фичи языка, которые будут считаться более качественным кодом.
Вот и в этом видео разбираются интересные и редкие особенности языка:
🟣 работа с опционалам в цикле for
🟣 выход из всех вложенных циклов с помощью outer
🟣 closure это не reference type
🟣 inout не выделеяет структуру в куче
🟣 другие особенности языка
Дьявол, как говорится, в деталях
Swift становится очень мощным языком и выходит за границы мира iOS. Все больше пишется кроссплатформ и серверов на нем.
Знание языка и владение им на продвинутом уровне — признак скилла разработчика. Я не думаю, что ИИ заменит разработчиков во всем. Люди все равно знают лучше редкие фичи языка, которые будут считаться более качественным кодом.
Вот и в этом видео разбираются интересные и редкие особенности языка:
Дьявол, как говорится, в деталях
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Kostya Gorsky’s Channel
Андрей Карпаты — известный разработчик, бывший директор по машинному обучения Tesla, а также сооснователь и бывший сотрудник OpenAI — написал тут твит (на скриншоте), из-за которого уже третий день бурлят сообщества.
Очень рекомендую прочитать оригинал.
Cуть примерно в следующем: появился новый способ программировать — Андрей назвал этот способ «вайб-кодингом». Это когда ты просто говоришь LLM, что хочешь сделать, и она пишет код. (Голосом, кстати, говоришь, через superwhisper.com или wisprflow.ai.) Модель отдаёт код, ты его даже не читаешь. Если возникают ошибки, копируешь их, и LLM обычно их исправляет. «Это уже не совсем кодинг — я просто что-то вижу, что-то говорю, что-то запускаю и что-то копипащу, и оно в основном работает.»
Я может и не обратил бы такого внимания на этот твит, если бы не бурление сообществ. И не тот факт, что наш СТО Слава (будучи очень опытным разработчиком, вообще одним из самых сильных, с кем мне доводилось работать), уже какое-то время рассказывает про похожий стиль программирования, и в целом как будто идёт тем же путём. Ему даже cursor.com уже мало, потому что Курсор не учитывает контекст всей кодовой базы одновременно.
Мне кажется, это всё — самый настоящий проблеск будущего работы.
Разработчик — это теперь скорее такой тимлид AI-агентов. Код можно самому не писать, надо только хорошо ставить задачи и уметь оценивать результат работы. Для этого всё ещё желательно уметь писать код, но может скоро и это требование отпадёт.
У разработчиков будущее наступает уже в 2025, у дизайнеров наступит может в 2026 или 2027.
И у всех нас наступит в какой-то момент.
Очень рекомендую прочитать оригинал.
Cуть примерно в следующем: появился новый способ программировать — Андрей назвал этот способ «вайб-кодингом». Это когда ты просто говоришь LLM, что хочешь сделать, и она пишет код. (Голосом, кстати, говоришь, через superwhisper.com или wisprflow.ai.) Модель отдаёт код, ты его даже не читаешь. Если возникают ошибки, копируешь их, и LLM обычно их исправляет. «Это уже не совсем кодинг — я просто что-то вижу, что-то говорю, что-то запускаю и что-то копипащу, и оно в основном работает.»
Я может и не обратил бы такого внимания на этот твит, если бы не бурление сообществ. И не тот факт, что наш СТО Слава (будучи очень опытным разработчиком, вообще одним из самых сильных, с кем мне доводилось работать), уже какое-то время рассказывает про похожий стиль программирования, и в целом как будто идёт тем же путём. Ему даже cursor.com уже мало, потому что Курсор не учитывает контекст всей кодовой базы одновременно.
Мне кажется, это всё — самый настоящий проблеск будущего работы.
Разработчик — это теперь скорее такой тимлид AI-агентов. Код можно самому не писать, надо только хорошо ставить задачи и уметь оценивать результат работы. Для этого всё ещё желательно уметь писать код, но может скоро и это требование отпадёт.
У разработчиков будущее наступает уже в 2025, у дизайнеров наступит может в 2026 или 2027.
И у всех нас наступит в какой-то момент.