Forwarded from Tati's Wonderland (Tanya)
#career #faang #interview #карьера #интервью
МЛ дизайн, работа над ошибками
Общий план выше, сейчас посмотрим на распространенные ошибки, которые я видела на МЛ дизайне.
1. Самое ключевое.
Мы не поняли задачу: в чем именно проблема, ЗАЧЕМ, почему нужно её решать. Какие бизнес метрики важны, какие не очень...
И... полезли её решать.
2. Мы не узнали какие у нас данные, есть ли они. Сразу предположили, что все есть в красивом виде и с разметкой, и давай решать (спойлер. Так не бывает)
3. Мы решаем задачу сразу сота LLMкой /LLM+GNN, etc. не уточнив, что там по бюджетам и железу, и не рассмотрев другие подходы.
4. Мы выбрали один любимый подход и рассматриваем только его. Не агрументируем, почему этот подход. Не рассматриваем альтернативы, их proc and cons. На вопрос: "почему так", ответ "СОТА" без чёткого понимания trade-offs.
МЛ дизайн проверяет ваше знание методов, понимание их плюсов-минусов. Если гиперфокусироваться на одном любимом подходе, вы не сможете это показать.
5. Мы выписали разные метрики, но не знаем их толком.
Если вы не можете произнести на интервью NDCG полными словами - не прозносите! Скажите аббревиатурой. Если не можете объяснить метрику (быстро, понятно, четко) - лучше даже не упоминайте ее, утоните.
Если вы написали на интервью Matthew correlation, будьте готовы ответить за неё и помнить формулу 😁.
6. И наоборот: их никто не спрашивал, а они начинают как прилежные школьники рассказывать формулы для precision and recall (на позицию тех лида).
Не лезте в такие детали. Интервьюер спросит, если захочет. Предполагается, что тех лид с опытом 10 лет знает, что такое recall, не надо тратить время и писать эти формулы. Тратьте время очень грамотно.
7. Time management тоже очень частая проблема.
Рассказать весь дизайн за 45 минут (5 на интро, 5 на follow up, 5 на ваши вопросы), при этом не тараторить со скоростью 100500 слов в сек, достаточно нетривиально. Нужно тренироваться. Поэтому тренировочные интервью так важны.
Часто кандидаты не укладываются во время совершенно, приходится их направлять и навигировать вопросами, чтобы успеть осветить важные пункты. На миддла норм, но на тех лида вы должны вести это интервью, а не наоборот.
8. Отсутствие гибкости. Слишком stick to the plan и не считывают сигналы интервьюера. Я говорю, инфру и data engineering часть можно опустить. А человек все равно по плану... не может отклониться, в итоге теряет время и не успеваем то, что нужно было успеть.
9. Отсутсвие гибкости. Или так: "У вас есть 5 минут на вопросы нам". В ответ, "Ой, давайте я тогда лучше дорасскажу про инфраструктуру 🙈", которую не успел.
Ваши вопросы на уровень тех лида куда важнее, чем дорассказать, что вы там не успели по вашему плану. Этот план важен вам. Гибкость важна, в работе тоже.
10. Мы не знаем, что делать с дисбалансом классов, trade offs, как навигировать precision recall trade off, что делать, если AUPR высок, а AUC близок к 0.5, как делать анализ предиктов, что делать с cold starts, и т.д. дополнительные вопросы всегда будут, будьте готовы.
Вот такие ошибки пришли сходу в голову.
Дальше будут ресурсы для подготовки.
Всем удачи на всяких интервью!
МЛ дизайн, работа над ошибками
Общий план выше, сейчас посмотрим на распространенные ошибки, которые я видела на МЛ дизайне.
1. Самое ключевое.
Мы не поняли задачу: в чем именно проблема, ЗАЧЕМ, почему нужно её решать. Какие бизнес метрики важны, какие не очень...
И... полезли её решать.
2. Мы не узнали какие у нас данные, есть ли они. Сразу предположили, что все есть в красивом виде и с разметкой, и давай решать (спойлер. Так не бывает)
3. Мы решаем задачу сразу сота LLMкой /LLM+GNN, etc. не уточнив, что там по бюджетам и железу, и не рассмотрев другие подходы.
4. Мы выбрали один любимый подход и рассматриваем только его. Не агрументируем, почему этот подход. Не рассматриваем альтернативы, их proc and cons. На вопрос: "почему так", ответ "СОТА" без чёткого понимания trade-offs.
МЛ дизайн проверяет ваше знание методов, понимание их плюсов-минусов. Если гиперфокусироваться на одном любимом подходе, вы не сможете это показать.
5. Мы выписали разные метрики, но не знаем их толком.
Если вы не можете произнести на интервью NDCG полными словами - не прозносите! Скажите аббревиатурой. Если не можете объяснить метрику (быстро, понятно, четко) - лучше даже не упоминайте ее, утоните.
Если вы написали на интервью Matthew correlation, будьте готовы ответить за неё и помнить формулу 😁.
6. И наоборот: их никто не спрашивал, а они начинают как прилежные школьники рассказывать формулы для precision and recall (на позицию тех лида).
Не лезте в такие детали. Интервьюер спросит, если захочет. Предполагается, что тех лид с опытом 10 лет знает, что такое recall, не надо тратить время и писать эти формулы. Тратьте время очень грамотно.
7. Time management тоже очень частая проблема.
Рассказать весь дизайн за 45 минут (5 на интро, 5 на follow up, 5 на ваши вопросы), при этом не тараторить со скоростью 100500 слов в сек, достаточно нетривиально. Нужно тренироваться. Поэтому тренировочные интервью так важны.
Часто кандидаты не укладываются во время совершенно, приходится их направлять и навигировать вопросами, чтобы успеть осветить важные пункты. На миддла норм, но на тех лида вы должны вести это интервью, а не наоборот.
8. Отсутствие гибкости. Слишком stick to the plan и не считывают сигналы интервьюера. Я говорю, инфру и data engineering часть можно опустить. А человек все равно по плану... не может отклониться, в итоге теряет время и не успеваем то, что нужно было успеть.
9. Отсутсвие гибкости. Или так: "У вас есть 5 минут на вопросы нам". В ответ, "Ой, давайте я тогда лучше дорасскажу про инфраструктуру 🙈", которую не успел.
Ваши вопросы на уровень тех лида куда важнее, чем дорассказать, что вы там не успели по вашему плану. Этот план важен вам. Гибкость важна, в работе тоже.
10. Мы не знаем, что делать с дисбалансом классов, trade offs, как навигировать precision recall trade off, что делать, если AUPR высок, а AUC близок к 0.5, как делать анализ предиктов, что делать с cold starts, и т.д. дополнительные вопросы всегда будут, будьте готовы.
Вот такие ошибки пришли сходу в голову.
Дальше будут ресурсы для подготовки.
Всем удачи на всяких интервью!
Forwarded from Concise Research (Sergey Kastryulin)
Reconstruction vs. Generation: Taming Optimization Dilemma in Latent Diffusion Models
[код и веса]
Выбор представления для обучения латентной диффузии - важнейший фактор качества и скорости обучения модели.
Более высокая размерность
латентного пространства улучшает качество реконструкции. Обычно она достигается путём увеличения числа каналов. VAE первых моделей семейства SD имели 4 канала, у FLUX и SD3 уже 16, а SANA - 32.
Более низкая размерность
латентного пространства упрощает задачу обучения генеративной модели. Если размерность все-таки хочется держать высокой, то можно компенсировать сложность увеличением модели и компьюта, но это дорого.
Интересно, что проблемы связанные с большой размерностью ранее обсуждали в основном для дискретных токенизаторов. Для них известно, что большие кодбуки плохо утилизируются. Авторы этой работы анализируют распределение латентов непрерывных VAE и приходят к такому же выводу. Идея работы в том чтобы заалайнить латенты с фичами visual foundation model, тем самым улучшив их качество с точки зрения обучения на них генеративных моделей.
Метод
Основной вклад работы - двухкомпонентный лосс, который алайнит VAE латенты
1️⃣ Поэлементно минимизируют косинусное расстояние между
2️⃣ Минимизируют разницу косинусных расстояний между элементами
Оба компонента считают с отступом так, чтобы только большие отклонения вносили вклад в лосс, а между собой компоненты взвешивают пропорционально их вкладу.
Эксперименты
За основу берут ванильный LDM сетап с VQ-GAN токенизатором (f16d32, f16d16), но без квантизации. На его латентах учат DiTы от 0.1B до 1.6В c полным фаршем из RF, подбора adam.beta2, bfloat16 и RMSNorm для стабилизации, SwiGLU и RoPE. Полученная серия моделей LightningDiT сходится к FID 1.35 на ImageNet 256, причем значение 2.11 получается всего за 64 эпохи.
Выводы
В статье настораживает почти полное отсутствие примеров реконструкций предложенных VAE и аблейшенов влияния примочек для DiT на рост качества относительно бейзлайнов. Нравится движение в сторону недоизученной темы оптимальных пространств для обучения генеративок
[код и веса]
Выбор представления для обучения латентной диффузии - важнейший фактор качества и скорости обучения модели.
Более высокая размерность
латентного пространства улучшает качество реконструкции. Обычно она достигается путём увеличения числа каналов. VAE первых моделей семейства SD имели 4 канала, у FLUX и SD3 уже 16, а SANA - 32.
Более низкая размерность
латентного пространства упрощает задачу обучения генеративной модели. Если размерность все-таки хочется держать высокой, то можно компенсировать сложность увеличением модели и компьюта, но это дорого.
Интересно, что проблемы связанные с большой размерностью ранее обсуждали в основном для дискретных токенизаторов. Для них известно, что большие кодбуки плохо утилизируются. Авторы этой работы анализируют распределение латентов непрерывных VAE и приходят к такому же выводу. Идея работы в том чтобы заалайнить латенты с фичами visual foundation model, тем самым улучшив их качество с точки зрения обучения на них генеративных моделей.
Метод
Основной вклад работы - двухкомпонентный лосс, который алайнит VAE латенты
Z с фичами DINOv2 F. Для этого Z линейно отображают в размерность F получая Z’, после чего:1️⃣ Поэлементно минимизируют косинусное расстояние между
Z’ и F2️⃣ Минимизируют разницу косинусных расстояний между элементами
Z’ и FОба компонента считают с отступом так, чтобы только большие отклонения вносили вклад в лосс, а между собой компоненты взвешивают пропорционально их вкладу.
Эксперименты
За основу берут ванильный LDM сетап с VQ-GAN токенизатором (f16d32, f16d16), но без квантизации. На его латентах учат DiTы от 0.1B до 1.6В c полным фаршем из RF, подбора adam.beta2, bfloat16 и RMSNorm для стабилизации, SwiGLU и RoPE. Полученная серия моделей LightningDiT сходится к FID 1.35 на ImageNet 256, причем значение 2.11 получается всего за 64 эпохи.
Выводы
В статье настораживает почти полное отсутствие примеров реконструкций предложенных VAE и аблейшенов влияния примочек для DiT на рост качества относительно бейзлайнов. Нравится движение в сторону недоизученной темы оптимальных пространств для обучения генеративок
Forwarded from Лига Хруща // League of Hrusch
Spent last half a year rejecting the idea of switching to cursor.sh. Tried it today, and it has the most important feature that is missing from all other major competitors: You can directly use RAG within your prompt. Example use case: I need to convert class names from simplified nomenclature to a normal one, and they are stored in 3 different sources: website with documentation, json file with training data, csv file with labels. Only in cursor you can tag specific sources (and even specific places within those sources like fields in json etc.) and give as precise instructions as possible
Forwarded from Knowledge Accumulator
О чём нам говорят результаты O3?
Пару недель назад были опубликованы первые эвалы новой флагманской модельки от OpenAI. Она совершила прорыв на semi-private eval в ARC и в нескольких других бенчмарках про код и математику, Какой вывод мы из этого можем сделать?
Я не знаю всех слухов и деталей, так что, поправьте в комментариях, если не прав. Сконцентируюсь на ARC, так как понимаю про него больше всего.
Прорыв при переходе от O1 к O3 произошёл от трёх изменений:
1) Увеличение ресурсов на Chain of Thought
2) Добавление тренировочных ARC-задач в обучение модели
3) Неизвестные нам изменения между моделями.
Отрывочные данные выглядят так, что ключ к успеху именно в первых двух пунктах.
В RLHF (я её не очень давно разбирал) существует 2 компоненты, отвечающие за её качество. Первая - это Reward Model (RM) - "оценщик" текста, который смотрит на него и предсказывает, несколько он "хорош". Задача оценки сильно проще задачи генерации, и такую модель обучают на больших объёмах человеческой разметки из разных источников.
Итоговая RM является потолком того, что может достичь языковой генератор, поскольку всё, что делают при его обучении - это максимизируют фидбек от RM. При этом, можно предполагать, что сам генератор умеет полностью эмулировать RM при применении к уже сгенерированному ответу.
Что делает Chain of Thought? Грубо говоря, модель генерирует рассуждение и множество вариантов ответов на запрос, а затем сама же выбирает из них финальный. Если бы RLHF работал хорошо и генератор умел генерировать текст, который ему же самому понравится в конце (т.е. и RM), то CoT бы ничего особо не давал.
Таким образом, если увеличение затрат с 20 долларов до 2000 на запрос серьёзно увеличивает профит (как в O3), то у меня для вас плохая новость - RL и тут работает, как обычно.
Тем не менее, не вижу ничего страшного. Для меня важной является принципиальная способность решить задачу, а не потраченный компьют. Если сегодня задачу можно решить за 2к долларов, значит, через 10 лет такой же алгоритм решит её за 100.
Когда тренировочные задачи из ARC добавили в обучающий датасет для O3, то задача для RM сильно упростилась. Бенчмарк вместо вопроса "Умеет ли модель решать принципиально новые задачи?" начинает задавать "Умеет ли модель решать новые задачи, похожие на обучающую выборку?". То, что O3 стала настолько лучше после добавления задач в тренировочный датасет, говорит о двух вещах:
1) Если добавлять принципиально новые задачи в тренировочный датасет, то модель как-то сможет обобщать их решения - это хороший знак
2) Если похожих задач в данных вообще нет, то модель будет работать гораздо хуже - это плохая новость для тех, кто хочет, чтобы модель с 1 пинка решала новую уникальные задачи, тем более, такие, которые в принципе не решены человеком.
Что касается использования на практике, то вряд ли я буду трогать O3 - сомневаюсь в том, что она выдаст что-то настолько интересное, за что можно заплатить 10+ долларов за ответ. Даже O1 с его 1 долларом за ответ мне было жалко дёргать, и я не смог вымолить у неё один нестандартный кусок кода за вечер. С бытовыми задачами генерации текста справлялась даже GPT-4, а писать код на работе помогает Copilot, который на основе O3 будет думать непозволительно долго. Посмотрим, как оно будет выглядеть после релиза.
@knowledge_accumulator
Пару недель назад были опубликованы первые эвалы новой флагманской модельки от OpenAI. Она совершила прорыв на semi-private eval в ARC и в нескольких других бенчмарках про код и математику, Какой вывод мы из этого можем сделать?
Я не знаю всех слухов и деталей, так что, поправьте в комментариях, если не прав. Сконцентируюсь на ARC, так как понимаю про него больше всего.
Прорыв при переходе от O1 к O3 произошёл от трёх изменений:
1) Увеличение ресурсов на Chain of Thought
2) Добавление тренировочных ARC-задач в обучение модели
3) Неизвестные нам изменения между моделями.
Отрывочные данные выглядят так, что ключ к успеху именно в первых двух пунктах.
В RLHF (я её не очень давно разбирал) существует 2 компоненты, отвечающие за её качество. Первая - это Reward Model (RM) - "оценщик" текста, который смотрит на него и предсказывает, несколько он "хорош". Задача оценки сильно проще задачи генерации, и такую модель обучают на больших объёмах человеческой разметки из разных источников.
Итоговая RM является потолком того, что может достичь языковой генератор, поскольку всё, что делают при его обучении - это максимизируют фидбек от RM. При этом, можно предполагать, что сам генератор умеет полностью эмулировать RM при применении к уже сгенерированному ответу.
Что делает Chain of Thought? Грубо говоря, модель генерирует рассуждение и множество вариантов ответов на запрос, а затем сама же выбирает из них финальный. Если бы RLHF работал хорошо и генератор умел генерировать текст, который ему же самому понравится в конце (т.е. и RM), то CoT бы ничего особо не давал.
Таким образом, если увеличение затрат с 20 долларов до 2000 на запрос серьёзно увеличивает профит (как в O3), то у меня для вас плохая новость - RL и тут работает, как обычно.
Тем не менее, не вижу ничего страшного. Для меня важной является принципиальная способность решить задачу, а не потраченный компьют. Если сегодня задачу можно решить за 2к долларов, значит, через 10 лет такой же алгоритм решит её за 100.
Когда тренировочные задачи из ARC добавили в обучающий датасет для O3, то задача для RM сильно упростилась. Бенчмарк вместо вопроса "Умеет ли модель решать принципиально новые задачи?" начинает задавать "Умеет ли модель решать новые задачи, похожие на обучающую выборку?". То, что O3 стала настолько лучше после добавления задач в тренировочный датасет, говорит о двух вещах:
1) Если добавлять принципиально новые задачи в тренировочный датасет, то модель как-то сможет обобщать их решения - это хороший знак
2) Если похожих задач в данных вообще нет, то модель будет работать гораздо хуже - это плохая новость для тех, кто хочет, чтобы модель с 1 пинка решала новую уникальные задачи, тем более, такие, которые в принципе не решены человеком.
Что касается использования на практике, то вряд ли я буду трогать O3 - сомневаюсь в том, что она выдаст что-то настолько интересное, за что можно заплатить 10+ долларов за ответ. Даже O1 с его 1 долларом за ответ мне было жалко дёргать, и я не смог вымолить у неё один нестандартный кусок кода за вечер. С бытовыми задачами генерации текста справлялась даже GPT-4, а писать код на работе помогает Copilot, который на основе O3 будет думать непозволительно долго. Посмотрим, как оно будет выглядеть после релиза.
@knowledge_accumulator
Forwarded from Katser
В посте раскрою одноименный пункт своего доклада на Datafest'е 2024 "Открытые промышленные данные: зачем нужны, почему так мало и где брать?" и поделюсь конкретными примерами.
В докладе подробно рассказал, зачем нужны открытые датасеты и какие проблемы есть с существующими промышленными данными. А вот подробная инструкция, где и как искать датасеты:
· Сайт группы
· Репозиторий института
· Обзорная статья про поиск аномалий в сетевом трафике
· Статья с последнего NIPS'а
· Сайт проекта timeseriesclassification.com
· Awesome Public Industrial Datasets
· Awesome TS anomaly detection
· Industrial ML Datasets
· Public industrial datasets and benchmarks
А еще я создал на гитхабе на основе своих лайков отдельную папку с датасетами.
· Вот пример с датасетами от блогера в нефтегазе.
· Еще один пример — большое число датасетов от компании NASA.
· Да и мой блог — тоже неплохой пример
Конечно, я как всегда буду рад вашим рекомендациям — добавлю в подборку.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Юрий Кацер | Открытые промышленные данные: зачем нужны, почему так мало и где брать?
Спикер: Юрий Кацер, Рокет Контрол, DS team lead, эксперт по анализу данных и машинному обучению в задачах промышленности, автор тг-канала @datakatser
Полезные ссылки:
https://github.com/YKatser/Industrial-ML
Data Fest 2024: https://ods.ai/events/datafest2024…
Полезные ссылки:
https://github.com/YKatser/Industrial-ML
Data Fest 2024: https://ods.ai/events/datafest2024…
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Правильный ответ: Результат работы программы зависит от версии и интерпретатора Python.
Дело в том что в старых версиях CPython (до версии 3.10). оператор +=. работал с точки зрения интерпретатора как две операции. И несмотря на наличие GIL и отсутствие параллелизма получался data race и значение счетчика не соответствует ожидаемому.
В CPython 3.10 внесли изменения в интерпретатор и подобный код выдает стабильно правильное значение.
Но если видоизменить пример то все ломается:
Этим квизом я хотел наглядно продемонстрировать, что не всегда наличие GIL защищает от неконсистентности. Использование мьютексов необходимо, чтобы гарантировать корректную работу программы.
Об этом интересном кейсе я писал статью на хабре, там внутри больше экспериментов + ссылка на коммит в интерпретатора CPython + ссылка на репозиторий с кодом, который можно запустить и проверить поведение. Даже в комментариях мы с ребятами придумывали варианты как бы еще сломать код и находили интересные кейсы😊
https://habr.com/ru/articles/764420/
Дело в том что в старых версиях CPython (до версии 3.10). оператор +=. работал с точки зрения интерпретатора как две операции. И несмотря на наличие GIL и отсутствие параллелизма получался data race и значение счетчика не соответствует ожидаемому.
В CPython 3.10 внесли изменения в интерпретатор и подобный код выдает стабильно правильное значение.
Но если видоизменить пример то все ломается:
class CounterWithConversion:
def __init__(self):
self.val = 0
def change(self):
self.val += int(1) # единственное отличие - операция преобразования типа
Этим квизом я хотел наглядно продемонстрировать, что не всегда наличие GIL защищает от неконсистентности. Использование мьютексов необходимо, чтобы гарантировать корректную работу программы.
Об этом интересном кейсе я писал статью на хабре, там внутри больше экспериментов + ссылка на коммит в интерпретатора CPython + ссылка на репозиторий с кодом, который можно запустить и проверить поведение. Даже в комментариях мы с ребятами придумывали варианты как бы еще сломать код и находили интересные кейсы😊
https://habr.com/ru/articles/764420/
Хабр
Многопоточность в Python: очевидное и невероятное
В данной статье я покажу на практическом примере как устроена многопоточность в Python, расскажу про потоки, примитивы синхронизации и о том зачем они нужны. Изначально я планировал что это будет...
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Забыл рассказать про еще один вывод на который натолкнул меня пример с счетчиком в многопоточной среде.
Ранее мы разобрались в том что на уровне железа у нас есть определенные гарантии и мы когда пишем код знаем какое поведение с точки зрения работы с памятью ожидать (или наоборот) от программы на x86 или например ARM процессоре.
В языках программирования с этим сложнее. Вот если взять Python - пример выше демонстрирует что с точки зрения памяти в многопоточной среде нет каких то строгих и фиксированных правил. Корректный код на одной версии Python не обязательно будет корректным на другой версии, а если запускать на другом интерпретаторе то шансы словить багулю ещё выше. Пример с счетчиком лишь вершина айсберга.
Как с этим жить? Мой опыт говорит:
- Не использовать Concurrency без четкого понимания зачем.
- Если используешь то минимизировать общее состояние.
- Общее состояние которое осталось покрыть блокировками.
На этом завершаю разбор языка Python с точки зрения Concurrency, следующим языком будет либо Ruby либо Java😊
Если вам хочется больше примеров кода и практики то прикрепляю хорошие ссылки:
- Практический гайд по процессам и потокам (и не только) в Python - бенчмаркаю и делаю выводы о производительности процессов, потоков и корутин.
- Python behind the scenes #13: the GIL and its effects on Python multithreading - офигенный пост в рамках не менее офигенного цикла статей. Горячо рекомендую если не видели.
———
А если интересно как я изучал Python то здесь всё:
🐍 Как я изучал Python. Step 1 - Изучение языка.
🐍 Как я изучал Python. Step 2 - Инструменты и библиотеки.
🐍 Как я изучал Python. Step 3 - Concurrency
Ранее мы разобрались в том что на уровне железа у нас есть определенные гарантии и мы когда пишем код знаем какое поведение с точки зрения работы с памятью ожидать (или наоборот) от программы на x86 или например ARM процессоре.
В языках программирования с этим сложнее. Вот если взять Python - пример выше демонстрирует что с точки зрения памяти в многопоточной среде нет каких то строгих и фиксированных правил. Корректный код на одной версии Python не обязательно будет корректным на другой версии, а если запускать на другом интерпретаторе то шансы словить багулю ещё выше. Пример с счетчиком лишь вершина айсберга.
Как с этим жить? Мой опыт говорит:
- Не использовать Concurrency без четкого понимания зачем.
- Если используешь то минимизировать общее состояние.
- Общее состояние которое осталось покрыть блокировками.
На этом завершаю разбор языка Python с точки зрения Concurrency, следующим языком будет либо Ruby либо Java😊
Если вам хочется больше примеров кода и практики то прикрепляю хорошие ссылки:
- Практический гайд по процессам и потокам (и не только) в Python - бенчмаркаю и делаю выводы о производительности процессов, потоков и корутин.
- Python behind the scenes #13: the GIL and its effects on Python multithreading - офигенный пост в рамках не менее офигенного цикла статей. Горячо рекомендую если не видели.
———
А если интересно как я изучал Python то здесь всё:
🐍 Как я изучал Python. Step 1 - Изучение языка.
🐍 Как я изучал Python. Step 2 - Инструменты и библиотеки.
🐍 Как я изучал Python. Step 3 - Concurrency
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
🐍 Как я изучал Python. Step 1 - Изучение языка.
Цикл постов посвящённый языкам программирования с которыми я работал в production близится к концу. Ранее я подробно рассказал о том как изучал Ruby и Go.
Пришло время Python - языка в который я перекатывался из Ruby и на котором до сих пор прохожу алгоритмические собеседования. В этом посте расскажу о погружении в базу и фундамент языка.
1️⃣ Full Speed Python: a book for self-learners
Великолепная бесплатная методичка с упражнениями. Читается за пару часов, не нудно, с обилием примеров. Мне особенно понравилось как автор красиво провел линию повествования от итераторов коллекций до генераторов и asyncio. Супер доходчиво и понятно.
2️⃣ Python Koans - Learn Python through TDD
Еще один ресурс для тех кому лень читать огромные книги и хочется учиться на практике. Нужно лишь склонировать репозиторий и исправлять код пока все тесты не станут зелеными. Комбо: Git + Python + Tests
3️⃣ Comprehensive Python Cheatsheet
Очень подробная бесплатная шпаргалка по различным конструкциям языка
4️⃣ WTF Python - сборник примеров "магии" и особенностей языка
На этом мой минимальный набор окончен. Пишите в комментарии, каким был ваш путь в изучении Python?)
В следующих постах расскажу про тулинг и экосистему😊
Цикл постов посвящённый языкам программирования с которыми я работал в production близится к концу. Ранее я подробно рассказал о том как изучал Ruby и Go.
Пришло время Python - языка в который я перекатывался из Ruby и на котором до сих пор прохожу алгоритмические собеседования. В этом посте расскажу о погружении в базу и фундамент языка.
1️⃣ Full Speed Python: a book for self-learners
Великолепная бесплатная методичка с упражнениями. Читается за пару часов, не нудно, с обилием примеров. Мне особенно понравилось как автор красиво провел линию повествования от итераторов коллекций до генераторов и asyncio. Супер доходчиво и понятно.
2️⃣ Python Koans - Learn Python through TDD
Еще один ресурс для тех кому лень читать огромные книги и хочется учиться на практике. Нужно лишь склонировать репозиторий и исправлять код пока все тесты не станут зелеными. Комбо: Git + Python + Tests
3️⃣ Comprehensive Python Cheatsheet
Очень подробная бесплатная шпаргалка по различным конструкциям языка
4️⃣ WTF Python - сборник примеров "магии" и особенностей языка
На этом мой минимальный набор окончен. Пишите в комментарии, каким был ваш путь в изучении Python?)
В следующих постах расскажу про тулинг и экосистему😊
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
🐍 Как я изучал Python. Step 2 - Инструменты и библиотеки.
После изучения основных конструкций языка я начал погружаться в тулинг, так как понимал по опыту с Ruby - сам язык это всего лишь часть картины, и программисту важно не только писать код но и пользоваться инструментами написанными другими.
🔹The Hitchhiker’s Guide to Python! (MUST HAVE)
Великолепная бесплатная книга обо всем. Начиная с того как правильно установить язык на свой компьютер заканчивая best practices по написанию качественного кода. Если вы начинающий питонист - переходите по ссылке и на многие вопросы найдете ответы😊
🔹Python Packaging User Guide
Оказывается в официальной доке Python есть целый цикл статей о том как правильно оборачивать свой код в пакеты для дальнейшего переиспользования. Если перед вами стоит задача на работе требующая переиспользования кода советую присмотриться чтобы сделать всё по красоте
🔹Pyenv - Simple Python version management
Невероятно полезная утилита для размещения нескольких версий Python на одной машине. Удобно если работаешь с несколькими проектами + для тестирования различных корнер кейсов. Мне эта утилита помогла обнаружить undefined behaviour в Python, о котором я писал на Хабре.
Code Quality Tools
🔹Black - The uncompromising Python code formatter
🔹WemakePythonStyleGuide - The strictest and most opinionated python linter ever!
Как видите список не то чтобы большой, все таки не так долго по времени удалось поработать с Python, наверняка многие современные тулы я упустил из виду😁
Расскажите в комментариях про полезные инструменты и библиотеки которые помогают вам в ежедневной работе🙃
После изучения основных конструкций языка я начал погружаться в тулинг, так как понимал по опыту с Ruby - сам язык это всего лишь часть картины, и программисту важно не только писать код но и пользоваться инструментами написанными другими.
🔹The Hitchhiker’s Guide to Python! (MUST HAVE)
Великолепная бесплатная книга обо всем. Начиная с того как правильно установить язык на свой компьютер заканчивая best practices по написанию качественного кода. Если вы начинающий питонист - переходите по ссылке и на многие вопросы найдете ответы😊
🔹Python Packaging User Guide
Оказывается в официальной доке Python есть целый цикл статей о том как правильно оборачивать свой код в пакеты для дальнейшего переиспользования. Если перед вами стоит задача на работе требующая переиспользования кода советую присмотриться чтобы сделать всё по красоте
🔹Pyenv - Simple Python version management
Невероятно полезная утилита для размещения нескольких версий Python на одной машине. Удобно если работаешь с несколькими проектами + для тестирования различных корнер кейсов. Мне эта утилита помогла обнаружить undefined behaviour в Python, о котором я писал на Хабре.
Code Quality Tools
🔹Black - The uncompromising Python code formatter
🔹WemakePythonStyleGuide - The strictest and most opinionated python linter ever!
Как видите список не то чтобы большой, все таки не так долго по времени удалось поработать с Python, наверняка многие современные тулы я упустил из виду😁
Расскажите в комментариях про полезные инструменты и библиотеки которые помогают вам в ежедневной работе🙃
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Продолжаю цикл постов о том как изучал Python. Сегодняшний лот - конкурентность(многопоточность / мультипроцессинг / асинхронщина).
Основы по этой теме я изучил в университете, а практиковался уже когда работал на Ruby (в Купибилете бэкэнд был написан поверх асинхронной библиотеки).
При изучении аналогичной темы в Python мне было достаточно лишь грамотно провести параллели между абстракциями. И помогли мне в этом великолепные бесплатные статьи с сайта superfastpython
https://superfastpython.com/learning-paths/
Будучи ментором заметил что у начинающих специалистов возникает довольно много вопросов по этой теме, несмотря на обилие ресурсов в сети.
И написал на Хабр супер короткую заметку Практический гайд по процессам и потокам (и не только) в Python. Теперь перед любыми консультациями скидываю её ученикам, и мы созванивались только при условии что даже она не смогла помочь.
Bonus: В прошлом году у меня была мысль сделать цикл постов в виде задачек и решать их вместе с вами. В итоге я придумал задачку на многопоточность и нашел неочевидное поведение Python. Так я получил полноценную учетку на хабре😁 И в дополнение от учеников получал отзывы, что мои статьи на хабре читали даже их интервьюеры☺️
Расскажите в комментариях о вашем опыте работы с Concurrency, мне будет очень интересно ознакомиться)
Please open Telegram to view this post
VIEW IN TELEGRAM
Super Fast Python
Start Here - Super Fast Python
Python concurrency learning paths that you can use to get started and get really good at threading, multiprocessing, and asyncio.