15 вопросов по Python как джуниору пройти собеседование


Оглавление (нажмите, чтобы открыть):

Страница поста от канала Библиотека программиста

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Пожаловаться

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Советы сеньоров: как прокачать знания junior Python

Советы сеньоров — ежемесячная рубрика, в рамках которой опытные специалисты делятся практическими советами с джуниорами — общие лайфхаки по обучению, какие книги и ресурсы читать, какие навыки осваивать и многое другое. В этом выпуске говорим о Python разработчиках.

Александр Жаботинский, Senior Software Engineer, 8 лет опыта Python разработки

Привет, дорогой друг! Значит, ты уже джуниор Python разработчик? Полагаю, ты уже прочел PEP-8 и согласен с философией Тима Петерса? Возможно, ты читаешь эти строки, так как, поработав годик-другой, увидел, столько возможностей, сфер и направлений для этого прекрасного языка, и хочешь выбрать правильный вектор для своего развития? Увы, не существует единого мнения. И моё представление пути Python-дева основывается на личном опыте, холиварах с коллегами и положении вещей в данный момент времени. Я не стану перечислять свои настольные книги, ведь ты сам можешь открыть Amazon и выбрать всё, что понравится: от компьютерного зрения и Data Science до Embedded и администрирования. Первый шаг ты уже сделал. И если у тебя есть пару минут, я расскажу, на что следует обратить внимание.

Вспомнил эпизод из фильма «Солдат Джейн», когда нужно было написать сочинение на тему «Почему я люблю морскую пехоту» и что бы не меньше 500 слов. Вот почему же я люблю Python? Всё перечислять не стану, выделю главное для себя.

Во-первых, у него минимальный порог входа — я знаю много непрограммистов из сферы, которым однажды ночью было «видение», что они могут и должны написать новый проект на Джанге (ведь это так просто), который порешает все вопросы компании, этим же программистам так долго объяснять, их вечно нету, они вечно заняты. Такие проекты порой доходят до прод-стадии и вполне себе работают годами, что говорит о том, что любой айтишник может быстро научиться писать сайты на Python и что любой Python-разработчик обязан уметь запилить веб на этом супер-мега-популярном Web-фреймворке не хуже этого непрограммиста, при том не допуская ошибок, о которых я позже расскажу. Да, да, Django — это мастхев. И поскольку веб-разработка — это не только бекенд, то тебе придется также уметь нарисовать красивые кнопочки или хотя бы сделать всё возможное, чтобы эти кнопочки нарисовали другие разработчики. Спагетти jQuery в прошлом, тренд фронтенда — веб-компоненты, я бы уделил время на разбор хотя бы этого фреймворка (ссылка на YouTube) со всеми его производными: версткой, сборщиками фронтенда, стандартами ECMAScript и т. д.

Во-вторых, Python-код читаемый. Вспомним «видение непрограммиста» — обычно в таких видениях не показывают те его части про «хоть какие-нибудь тесты» и архитектуру. И вот потом это произведение инженерной мысли попадает тебе на поддержку и доработку! Ты знаешь, что с Python проблем не будет, ведь, повторюсь, код читаемый, даже без комментариев. Да, Python решает вопрос, где открывать фигурную скобочку вместо тебя! Конечно, понять, зачем необходимо тестирование и зачем продумывать перед написанием кода архитектуру, чтобы не делать ошибок выше, вроде как надо. Но на практике не всегда ясно, зачем. Часто начинающие разработчики берут это как правило и потом, устав от поддержки этого правила и не увидев явного профита в разработке, бросают это дело. Мой совет — постарайся найти компанию/проект, где есть поставленный процесс и есть много разных участников: от РО, РМ до разных девелоперов и дизайнеров, которые этот процесс реально используют, т. е. есть командная работа. Пусть это будет не высокооплачиваемая работа, получи профит от изучения культуры программирования. Это не должен быть Scrum по утрам, потому что так везде. Ты должен почувствовать, что без написания тестов у тебя уходит больше времени на согласование и коммуникацию, поиск ошибки, рефакторинг или объяснению коллеге на код-ревью, что ты хотел сказать в этой небольшой функции на 100 строк. Со временем твой стиль написания спагетти-кода эволюционирует, станет более структурированным и компактным.

В-третьих, Python можно применить практически везде. Мой первый язык был Delphi, потом я работал сисадмином. В Python я пришел через книгу «Python в системном администрировании UNIX и Linux», позже я начал применять Python для решения других задач. Возможно, ты ранее тоже писал на чем-то другом или окончил курсы и теперь веб-разработчик. Не останавливайся — посмотри, как еще можно применить Python, и ты сильно удивишься, ведь это и вычисления на графических адаптерах, распознавание изображений, посмотри, как с его помощью управляют разными GPIO, USB, RS232. И напоследок — Python-комьюнити. По питону проходят интересные конференции, митапы в Украине и ЕС. Сходи познакомься с ребятами, послушай доклады. Барин из-за границы одобряет Python! А значит, при желании можно будет и уехать.

Не бойся поменять работу, если появится чувство, что всё стоит на месте, надоел проект или остановилось развитие. Да, не быть джампером и продолжительно работать на одном месте работы очень важно, но еще важнее быть высококлассным специалистом, разбираться в технологиях, «решать проблемы». Одно место работы в CV навряд ли охватит многие области применения, а вот практический опыт асинхронного программирования, нагруженных, многопоточных систем ценится больше. Обязательно сходи на интервью в другую компанию, если пригласят — это тоже развитие, которое укажет на твои слабые стороны и, возможно, мотивирует на изучение нового материала. Попробуй придумать написать какой-то pet-проект/стартап с нуля или же поучаствовать в open source. Изучай, развивайся, придумывай, пиши, рефактори — в конце концов, ты ж программист.

Евгений Климов, CTO, 7 опыта Python разработки

Вчера я проводил урок по Python и около часа говорил об особенностях языка. В конце мне задали вопрос о важности глубокого понимания алгоритмов и структур данных, а я (дурак!) ответил, что крутил их вокруг того дуба из Пушкинской сказки. Во всяком случае до тех пор, пока мы не выучили, как правильно ветвиться в git, как пользоваться Sphinx и для чего нужно всегда иметь актуальное описание проекта и инструкций к запуску в README. Я чертовски устал от споров о том, какой алгоритм быстрее справится с задачей, когда внутри исходников отсутствуют docstrings, а написание unittests оставлено до лучших времен.

Соблазн написать сложнейший продукт, в котором никто кроме тебя не разберется — огромен. Но мы все создаем продукты для бизнеса, а основная ценность нашей работы — это поддерживаемость и устойчивость к изменениям. Обычно функционал постоянно дополняется, обновляется и переписывается с нуля. Программисты болеют, их хантят другие компании, они улетают на острова в поисках духовного просветления. На их место приходят другие, и у всех свое собственное видение на true-программирование. Кто-то любит singleton, кто-то считает его анти-паттерном. Но я, как владелец проекта, не хочу думать об особенностях реализации. Я хочу знать, что код хорошо задокументирован, что весь функционал полностью покрыт тестами, и нас не ждут сюрпризы в следующем релизе.

Начиная свой путь, разработчик будет большим молодцом, если вместо сложных структур данных освоит рефакторинг — «Совершенный Код», «Чистый Код». Научится правильно вести свои проекты в git — хорошая статья о ветвении. Научится тестировать свои приложения и разрабатывать через TDD — курс по тестированию, книга «Экстремальное Программирование».

Только после того, как ваш код будет читабелен и надежен, когда вы сможете гордиться тем, что не забивали на то, что вроде делать нужно, но на что постоянно нет времени. Только тогда есть смысл оттачивать свой навык и обращаться к изучению алгоритмов и сложных структур данных.

Игорь Павленко, CTO, 7 лет опыта Python разработки

Будьте Хакером. В хорошем смысле этого слова. Во всём стремитесь дойти до самой сути происходящих вещей. Понять, как устроен интернет, софт, с которым вы работаете, библиотеки, фреймворки, инструменты.

Чтобы прокачать свои знания вам необходимо быть исследователем своей предметной области и области своих коллег. Если вы прочитали о новой технологии или инструменте, попробуйте применить его на практике. Подумайте, какую пользу он может принести на проекте. Поиграйтесь с ним, нагрузите тестами и сравните с другими похожими библиотеками. Чем больше вы будете исследовать, тем шире будет ваш горизонт знаний и тем проще будет решать задачи, которые встают перед вами на реальных проектах.

Цените свой труд. Не позволяйте себе халтурить или лениться. Всегда пишите самый лучший код, который вы можете написать. Покрывайте его тестами, вычищайте и оформляйте согласно всем стилевым и корпоративным стандартам. Уважайте ваших коллег и PEP-8. Обязательно включайте pylint, sonar или другие анализаторы в самом строгом режиме.

Ищите свой путь. Все люди разные и по-разному воспринимают информацию. То, что подходит одним джуниорам, не будет подходить другим, так что никогда не сдавайтесь. Если вам сложно с какой-то книгой или туториалом — попробуйте поменять подход или руководство.

Непрерывно учитесь. Никогда нельзя переставать учиться. По статистике успешные руководители читают как минимум около 60 книг в год. Не останавливайтесь на технической литературе. Читайте книги направленные на развитие софт скиллов и просто художественную литературу. Возьмите на вооружение правило, что день прожит зря, если вы не узнали ничего нового в его течении или не прочитали хотя бы главу хорошей книги. Не забывайте про спецификации, RFC и PEP. Это поможет вам понять, как и почему именно так развивается ваш язык и инструменты.

Непрерывно тренируйтесь. Просто получать знания — мало. Нужно постоянно закреплять их на практике. Пишите код. Делайте пул реквесты в open source библиотеки, которыми пользуетесь. Просите коллег делать вам код-ревью. А ещё помните, что написание кода — это лишь малая часть работы. Куда больше времени в разработке отнимает чтение кода. Поэтому постоянно читайте хороший код. Постоянно ищите хорошие open source библиотеки и разбирайте, как они устроены. Прорисуйте модульные и компонентные их диаграммы, data-flow чарты. Попробуйте понять, почему разработчики принимали именно такие решения. Для начала хорошо подойдут Werkzeug, Django REST Framework и Requests. После этого можно попробовать проанализировать исходный код async.io и сопутствующих ей библиотек.

Научитесь пользоваться Google. Если вы сталкиваетесь с какой-то проблемой, то не бегите сразу к коллегам, потратьте 15 минут на её анализ и поиск похожих решений в сети. Научитесь формализовать проблемы и задавать правильные вопросы. Научитесь искать нужные вам ресурсы. Перед тем, как задать свой вопрос, не спешите, постарайтесь его максимально четко сформулировать. Возможно, что ответ на вопрос уже кроется в самом вопросе. Тренируйтесь излагать свои мысли максимально чётко и лаконично. Желательно сразу на английском языке. 😉

Смотрите на проблемы шире. Тренируйте способность видеть больше, чем написано в таске. Старайтесь развивать общее видение системы, анализируйте таски самостоятельно, используя диаграммы-классов, сущностей, схемы алгоритмов и т. п. Задача инженера — решать бизнес-проблемы клиентов. Старайтесь связывать конкретное задание с проблемами бизнеса. Это поможет избегать потенциальные конфликты в коде и предотвратит появление узких мест.

Думайте о своих коллегах. Когда ты сосредоточен над выполнением только конкретных задач, часто создаётся иллюзия, что менеджер, клиенты, тимлиды не всегда поступают правильно. Чаще всего это не так и это может помешать достижению целей. Старайтесь понять мотивацию своих коллег и клиентов. Поставьте себя на их место, подумайте, какие проблемы решают они и какие ограничения у них есть. Всегда задумывайтесь о бизнес-процессах всего предприятия и ваших клиентов. Не просто показывайте свою вовлечённость в проект, а будьте вовлечёнными и увлечёнными им по-настоящему. Помогите быть эффективными своим коллегам.

Мастер Йода рекомендует:  Арбитраж трафика 10 вещей, которые вы должны знать

Занимайтесь наставничеством и помощью. Не просто ориентируйтесь на своих наставников, но и постарайтесь сами стать наставником. Попробуйте начать с малого и подготовить мини-доклад для внутреннего митапа или просто напишите маленькую статью для новичков в корпоративной вики. Попробуйте помочь своему соседу с решением проблемы на его проекте. Это всё поможет ещё раз переосмыслить и осознать всё, что вы знаете. Уложить ваши знания в систему, улучшить ваше понимание.

Организуйте себя. Займитесь тайм-менеджментом. Управляйте своим временем. Обязательно стройте план своего развития, и тщательно планируйте свои задачи. Давайте эстимейты всем вашим задачам и обязательно анализируйте причины провала ваших дедлайнов и причины успехов. И помните: «К цели движется тот, кто хотя бы ползёт».

Андрій Силка, Senior Engineer, 5+ років досвіду Python розробки

Якщо спробувати відповісти на питання, як з джуна влетіти в синьйори, то крім банальщини «учиться, учиться и еще раз учиться» плюс реальні бойові завдання/проекти, коли волосся від страху стає дибки на спині, нічого не спадає на думку.

Це означає, що не боїмося, беремо на себе відповідальність і працюємо. Це як музиканти: або по 8 годин ти граєш і ти віртуоз, або йдеш в директори театру.

Якщо простіше, то запитайте в себе: як ви себе почуваєте, коли вихідні реально починаються тільки в п’ятницю ввечері «та фіча» таки взлетіла (боже, збав вам закоммітитись в мастер: я тут про задоволення, а не про бестпрактіс).

Так от, ця штука вас і витягне з джуна на інший рівень. Все інше — це тули та плюшки. Надзвичайно важливі, але все ж таки це більше атрибути та методи, ніж сама суть процесу.

Один з найулюбленіших та найдешевших способів — це вибрати собі ментора або «ну отого чувака з тіми, який ну так все класно шарить, може пояснити і з ним по кайфу разом щось запилити» і просто кататись поряд з ним. Це як перші спуски на лижах: побачив, як поряд інструктор ганяє початківців, і їдеш за ними, повторюєш і дряпаєшся на ще крутіший схил.

В процесі допомагають книжки та блоги (не боїмося витратити баксів за платні штуки):

Тренуємося на чомусь цікавому:

І, звичайно, їдемо на всякі туси, бажано тематичні:

Пробуємо Python і вибираємо до душі:

  • WEB (Flask/Django)
  • ComputerVision
  • Data Science
  • BigData
  • System tools

Отже, не боятися брати відповідальність на себе та ловити кайф від зробленого. Далі вже якось саме прилипне.

Публичное собеседование: Junior Python-программист

Сегодня в 19:00 по МСК на youtube-канале Хекслет начнётся публичное собеседование на позицию Python-программиста.


Опыт чуть более полугода, почти на нативном JS (самописный фреймворк в компании), фронтенд. Также проходил обучение по Python, сделал два учебных проекта. В основном пишу фронт, но хочу перейти в бэк, поэтому мне интересно всё, что связано с бэком. По мере сил стараюсь всё это изучать, собственно, поэтому начал изучать Питон.

Собеседующий — Алексей Пирогов, преподаватель Хекслет.

Публичное собеседование — это формат учебного собеседования в прямом эфире. Кандидат рассказывает о себе, а собеседующий задаёт наводящие вопросы с целью раскрыть навыки кандидата, его hard и soft скиллы, которые понадобятся при приёме на работу.

Примеры других публичных собеседований:

Слушатели собеседования могут задавать вопросы в ходе интервью. Вопросы принимаются в slack-коммьюнити Хекслет на канале #general.

Подготовка к собеседованию на позицию Python-разработчика

На сегодняшний день число Python-программистов продолжает расти, однако количество рабочих мест для них увеличивается не так быстро. Современному разработчику нужно быть конкурентоспособным, чтобы пробиться на желаемую позицию. Мы подготовили статью с темами и вопросами, которые работодатель может затронуть на собеседовании, и дополнили их небольшими объяснениями — по сути, это задачи по программированию на Python с решениями. Материал будет полезен продолжающим для повторения, а начинающим поможет сориентироваться, куда делать первые шаги, на что обратить внимание. Воспринимайте как своеобразный маяк.

Работа со списками

Лямбда-выражения, генераторы списков и выражения-генераторы

Лямбда-выражения — сокращённый метод создания однолинейных анонимных функций. Их простота часто (но не всегда) делает код более стройным и читабельным, чем классическое объявление функций. С другой стороны, та же простота ограничивает возможности и зоны применения лямбда-выражений.

Генераторы списков обеспечивают краткий синтаксис для создания списков. Они используются для составления списков, в которых каждый элемент — результат некоторой операции (операций) с элементами другой последовательности или итератором. Генераторы списков могут использоваться для создания подпоследовательности тех элементов, члены которых удовлетворяют определённому условию. Генераторы списков в Python — своеобразная альтернатива встроенным функциям map() и filter() .

Лямбда-выражения с функциями map() и filter() и генераторы списков схожи, поэтому выбор одного из этих инструментов субъективен и зависит от случая. Но следует отметить, что генераторы списков выполняются несколько быстрее — вызов лямбда-функции создаёт новый стековый кадр.

Выражения-генераторы синтаксически и функционально похожи на генераторы списков, но есть важные различия между их механизмами работы и областями применения. Итерация при наложении выражения-генератора или генератора списка будет делать всё то же самое, но генератор списков сначала создаст целый список в памяти, в то время как выражение-генератор будет создавать элементы на ходу по мере необходимости. Выражения-генераторы могут быть использованы в большом или даже бесконечном количестве последовательностей. А генерирование значений по требованию обеспечивает повышение производительности и снижение использования памяти. Однако следует отметить, что стандартные методы списков list в Python могут применяться на результатах выполнения генератора, но не на самом генераторе.

В чём разница между списком и кортежем?

Основная разница: список может изменяться, а кортеж — нет. Работа с кортежами быстрее, чем со списками. Если необходимо определить постоянный набор значений, и все, что с ним когда-либо надо делать, — это перебирать его элементы, рациональнее использовать кортеж вместо списка. Кортеж также может выступать в качестве ключа для словарей, в отличие от списка.

Самые продвинутые кандидаты скажут, что кортежи неоднородны и их использование аналогично использованию struct в языке программирования С. Списки же аналогичны привычным массивам.

Отладка кода и тестирование

Какой подход вы используете для модульного тестирования в Python?

Фундаментальный ответ на этот вопрос относится к использованию фреймворка Python — unittest.

Собеседование Python m > python, собеседование

Всем привет. Давненько я не проходил собеседований на вакансию разработчика. Сейчас приглашают поработать. Что сейчас спрашивают на мидла? Что повторить? Ресурсы, книги, ссылки? Python, базы данных. Может кто чем помочь?

Для Питона-то? Проходишь тест на IQ, если не ниже 40 — годишься.

очень смешно)) мне не junior’ом мартышечью работу выполнять, к счастью, этот этап давно позади. У меня за плечами c/c++, но интересуе специфика собеседований на Python.. какие-то модули, которы ну совсем прям знать надо наизусть или что-то подобное? я понимаю, у каждого работодателя свои требования, но давайте возьмем для примера, что собеседование будет проводить адекватный на 100% senior

Проходил весной тест за $5 на одном сертифицированом ресурсе — набрал, кажется, максимальный тамошний результат — 140 (могу дать пароль от кабинета, если тут будут любопытные). Для чистоты эксперимента проходило ещё несколько человек, и каждый их результат вызывал лишь ехидную ироничную улыбку с моей стороны. 🙂

Так вот, ваш комментарий меня подтолкнул на давно забытые подвиги. Вы, как мне показалось, человек в этом деле с опытом: как бы мне ненавязчиво прорекламировать свою success story на собеседовании?

они поди денег не заплатили, вот и результат вышел не очень.

сча вместо анонимуса вам отвечу)) честно сказать, такие вещи очень редко прокатывают. у меня есть несколько сертификатов от coursera, после того, как у меня пару раз спросили, что это такое, я перестал это указывать))) что касается тестов, составляются они крайне неоднозначно, да и собеседования проводятся по-разному. Я, если честно, надеялся тут увидеть ответы людей, которые сами проводили такие интервью. Случай, что называется, из жизни. Пол года назад, имея небольшой самописный проект на Джанге, решил я на работу устроиться. приглянулись 2 компании. В первой на позицию джуниора мне задавали такие вопросы, что вышел я оттуда с глазами, как у срущей собаки и кашей в голове, самооценкой ниже плинтуса. Затем все же решил сходить на второе интервью. Проводили его тим лид и ведущий программист. К моему удивлению, ответил я на все их вопросы, и зарплату мне предложили больше, чем я просил. Именно поэтому заделал тут топик, чтобы хотя бы как-то приблизительно определиться, ибо на конкретику я уже ни разу не рассчитываю.

после того, как у меня пару раз спросили, что это такое

а в остальном это были умные адекватные люди?

Python для собеседований

Однажды задолбался задавать на собеседованиях одни и те же вопросы без fun’а, родил функцию на Python. Веселился, придумывая. Кажется, решавшие задачку тоже получали свою порцию.

Собсно, вот код (Python 3.x):

Надо найти в нём ошибки. В зависимости от упоротости и перфекционизма количество ошибок от X до Z (подумал и решил таки не публиковать числа, лишняя подсказка получается). Кому и игнор PEP8 спать не мешает.

Суть упражнения (вполне типового, похожим джавистов на сертификациях кошмарят) в следующем:

  • Проверка знания языка.
  • Проверка внимательности.
  • Проверка умения думать над кодом.
  • Иногда показывает уровень чувства прекрасного.

Т.к. собираюсь написать более задорный вариант, этот “палю”. Применять его больше не буду. Развлекайтесь.

PS. Тем, кто не согласен и у кого что-то не получается: пжлст, не пишите мне, что вы не поняли код, что это плохое упражнение и прочее. Значит, не для вас. Не беда.

© — Powered by Jekyll & whiteglass — Subscribe via RSS

Начинающему программисту: есть примеры реальных заданий для джуниора Python?

django- разработка на нём всевозможных веб-сервисов. Самое простое: блог, интернет-магазин.
Честно говоря, пока не видел вакансий для работы на python вне веб-индустрии. Может их просто по Питеру нет, но мне кажется, что мало кто использует Python вне веба(в бизнесе). Примеры игр с использованием Python видел, но там он тоже для весьма узких целей служит.

UPD: junior будет делать мелкие веб-приложения, либо допиливать функционал к существующим, расширять их. Ещё может быть обычный парсинг данных с чужих сайтов. Примерно так.

О чем спросить питониста

Введение


Пару месяцев назад я сменил работу в московском офисе на удаленную работу в Toptal. Это был абсолютно новый для меня опыт, потому что мне еще не доводилось работать с американскими клиентами. Больше всего меня беспокоил языковой барьер, но по прошествии времени могу сказать, что навыки коммуникации быстро приобретаются при наличии практики и желания.

Подробнее об этом я наверно напишу в другом посте, а сейчас я хотел бы поделиться списком понравившихся мне вопросов с собеседований в различным московских компаниях. Я отобрал самые каверзные, многие из них вызвали у меня затруднения (наверное поэтому-то они мне и запомнились 🙂), так что будем считать это работой над ошибками.

Что такое meta-классы в Питоне и зачем они нужны?

Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don’t.

— Tim Peters

Я, пожалуй, не буду копировать Интернеты и просто оставлю здесь несколько ссылок (потому что мне больно говорить об этом) :

  • Первым на помощь нам спешит Хабр: Метаклассы в Python
  • Хабровчане по своей старой привычке не указывают ссылки на оригиналы статьей. Вот она: All about the metaclasses in Python!
  • Очень хороша статья на PyPix: Metaprogramming in Python, она посвежее и лучше оформлена, а в конце есть множество ссылок на другие статьи по данной теме.
  • А началось все с вопроса на StackOverflow!

Да, и не путайте meta-классы в Питоне с классом Meta в Django…

… как это сделал я!

Декораторы методов и классов в Python

Декораторы методов выступают в качестве “патчей”, который позволяют расширять поведение метода новыми возможностями. Звучит очень похоже на наследование, но технически все реализовано немного по другому.

Про декораторы классов информации мало, хотя они мало чем отличаются от декораторов методов и функций.

Вообще, про декораторы меня спрашивали практически везде, потому что это один из основных элементов языка, поэтому советую вам детально и ними разобраться.

Генераторы, итераторы и оператор yield

В питоне есть возможность итерировать объекты не загружая их все в память. Хорошим примером здесь являются функции близнецы range и xrange :

В данном случае range вернул нам список из чисел от 0 до 2, а xrange вернул нам генератор чисел от 0 до 2. Преимущество генераторов в том, что мы можем загружать объекты в память по мере необходимости, а не все сразу.

  • Jeff Knupp написал отличную статью на эту тему.
  • Старая, но еще актуальная статья на Хабре.

__slots__ для экономии память

В одном месте меня спросили про то, как можно сэкономить память при создании множества однотипных объектов. Как выяснилось, речь шла о переменной класса __slots__. Статей толковых про __slots__ я не встречал, потому что на практике это редко встречается.

Мастер Йода рекомендует:  WML - язык разметки

Суть __slots__ можно продемонстрировать следующим примером:

Этот массив жестко закрепляем список атрибутов экземпляра класса, и мы не можем добавить новые в процессе использования. Это позволяет интерпретатору оптимизировать объем памяти занимаемый экземпляром класса.

Вот что есть из доступных статей на эту тему:

Помимо __slots__ есть еще named tuples. Такой подход более распространен.

Модули threading and multiprocessing

Вопросы про потоки и процессы я слышал неоднократно, поэтому советую обратить на них особое внимание. Вопрос состоит из двух частей: понимание потоком и процессов в Unix в целом и интерфейс для работы с ними в Python.

Unix лучше изучить весь и стразу, потому что фундаментальные знания тоже очень важны. На английском языке могу посоветовать Linux System Programming: Talking Directly to the Kernel and C Library, эта книга имеет вменяемый объем и покрывает все основные аспекты.

Об интерфейсах в Python лучше читать в официальной документации:

В чем отличие open and fopen?

Опять вопрос из области системного программирования. На этот раз речь идет про буфферизованные и небуфферизованные операции с файлами. В двух словах это не описать, поэтому мой совет — читайте полноценные книги. Хороших статей я не встречал, но наверняка они тоже есть.

Что такое менеджеры контекста и как ими пользоваться?

Менеджеры контекста впервые появились в Python 2.5 с добавлением нового ключевого слова with (PEP 343). with можно сравнить с декоратором, который применяется для блоков кода. Суть этого оператора демонстрирует следующий пример:

На практике очень прижился вариант с open для работы с файлами:

Сам я писал свои менеджеры контекста всего пару раз, это не что то встречается повсеместно. Вот пара ссылок с их развернутым описанием:

Какие структуры данных в питоне вы знаете и применяли на практике?

Тема про структуры данных, конечно, безграничная. В Python есть базовые структуры данных, типа tuple, list, dict, set, они используются везде и наверняка вы с ними знакомы. Сложность различных операция над этими структурами данных можно посмотреть здесь.

Еще есть стандартная библиотека, и модуль collections в частности, там есть deque, Counter, OrderedDict, defaultdict и др. Ну и разумеется, никто не запрещает написать что-нибудь свое или стащить чужое (GitHub вам в помощь) :).

Если говорить о более продвинутых структурах данных, то могу порекомендовать эту статью. Также, настоятельно рекомендую почитать Кормана, что бы лучше понимать откуда ноги расту. Эта книга очень популярна у Javистов и Сишников, а вот питонисты её незаслуженно обходят стороной. А зря, очень хорошая книга! …хотя местами нудная

Что нового в Python 3?

Версия питона 2.7 является завершающей и дальнейшее развитие второй версии языка не планируется, поэтому многие компании начинают активно присматриваться к третьей версии. Именно присматриваться, потому что реально на третью версию питона перешли единицы. Сам я только пару раз использовал Python 3, причем это всегда были небольшие тестовые проекты.

В Python 3 появились новые структуры данных, print стал функцией, input() убрали совсем, все строки теперь в Unicode и многое другое, но самое важное это то, что третья версия не имеет обратной совместимости со второй. Поэтому…

Первым делом лучше проверить Python 3 Wall of Superpowers, там находится список популярных библиотек, которые уже портированы на Python 3. Многие уже портированы, но вот некоторые зависли в неопределенном положении. Если вы не нашли своей любимой библиотеки, то придется искать аналог.

Далее вам потребуется утилита 2to3 , что бы мигрировать код под новый синтаксис. Процесс миграции подробно описан здесь.


  • Полный список изменений доступен в официальной документации
  • Видео доклад Павла Зановкина, Миграция на Python 3
  • Знакомство с Python 3: Часть 1. Что нового в новой версии
  • Отдельно хочется отметить модуль asyncio и оператор yield from , который появился в версии 3.4
  • Видеодоклад Feihong Hsu Asynchronous I/O in Python 3 )

Цепи Маркова и машинное обучение

На собеседовании в Mail.RU меня попросили написать генератор бреда. Для этого нужно было использовать Цепи Маркова N-го порядка. С проектом я успешно справился и даже выложил его в открытый доступ.

Это был самый запоминающийся проект, ведь не каждый день интересуются твоими знаниями в машинном обучении и теории вероятности.

К питону это пункт не имеет прямого отношения, так что решайте сами, интересно вам это или нет. Тема довольно обширная и парой ссылок на статьи тут не отделаешь — нужны фундаментальные знания.

Протокол HTTP

Протокол HTTP, без преувеличения, можно назвать одной из тех черепах, на которых стоит мир Интернета. Если вы занимаетесь веб-разработкой, то вы в какой-то степени с ним знакомы.

Моя проблема заключалась в том, что долгое время я обходил его стороной, ведь для выполнения большинства задач достаточно поверхностных знаний. Я постарался закрасить это белое пятно в своих знания и могу сказать, что в этом не было ничего сложно.

Как вводная, очень хороша статья на tuts+ HTTP: The Protocol Every Web Developer Must Know (Part 2). Подробное описание протокола можно прочесть в RFC2616, сам я правда его так и не прочел.

Еще есть довольно старая книга HTTP: The Definitive Guide с хорошими отзывами. Мне её тоже пару раз рекомендовали к прочтению.

Заключение

Если вы собрались сменить работу в ближайшее время, то готовьтесь столкнуться с пробелами в своих знаниях и навыках. Конечно у каждого проекта своя специфика, но фундаментальные знания в computer science и опыт работы удовлетворяют большинство запросов работодателей.

Прохождение собеседования — это навык сам по себе. Программист, который не умеет проходить собеседования все равно что боксер, который не умеет держать удар. Многие смотрят на собеседование как на стресс, но для меня это возможность узнать что новое для себя и о себе. Пообщавшись со множеством специалистов из других компаний вам намного легче будет оценить уровень своей компетенции.

Ну и на последок еще одна ссылка на книгу Cracking the Coding Interview: 150 Programming Questions and Solutions, которая напрямую рассказывает о всех хитростях прохождения технических собеседований.

Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»

Введение

За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.

Общие идеи

Собеседование на middle-разработчика часто выглядит так же как собеседование junior-а.
Это действительно так. Это связано с тем, что многие тимлиды/тех.директоры не знают, что именно они хотят видеть в middle-разработчике. Поэтому на таких собеседованиях обычно просят «написать декоратор» или «написать сортировку пузырьком на любом языке».
Так же мало кто понимает, чем junior-разработчик отличается от middle-разработчика. Кто-то говорит, что middle – это разработчик с опытом от полутора лет, а кто-то — от трёх. В моём понимании middle-разработчик — это тот разработчик, которому можно смело отдать небольшой проект или какую-либо часть крупного проекта, и чтобы именно он был за неё ответственен. Также важным критерием для middle-разработчика является умение быть наставником для кого-либо или просто умение помогать внедриться новому сотруднику в проект.

Собеседование — это не экзамен, а возможность выявить насколько компания и кандидат подходят друг другу.
Это важное правило часто не понимают сами работодатели. Однажды я был на собеседовании, где меня заставили тянуть билет и отвечать перед собеседующим на листочке. При этом на протяжении всего этого собеседования мы общались десять минут. Такое же поведение часто прослеживается со стороны кандидата. Часто кандидат хочет на всё ответить и ведёт себя как отличница с первой парты. Но тут тоже важно понять, что работодателю не особо интересно насколько хорошо Вы знаете «отличие Python2 от Python3». Гораздо важнее для работодателя понять в целом как ты держишься на собеседовании, как рассуждаешь, как реагируешь на неудачи и т.д.

Middle-разработчиком нельзя стать без опыта.
Конечно, можно, но это повлечёт через какое-то время огромные неприятности как для начальника этого разработчика, так и для проекта. Для слишком одарённых кандидатов без опыта у HR-специалистов есть свой термин – «strong junior-разработчик». Скорее всего таким разработчикам будет предложена неплохая денежная компенсация, но обязанности у них будут как у junior-разработчиков. Возвращаясь к middle-разработчикам хочется отметить, что middle — это тот, кто хоть какое-то время проработал в разработке и понимает из каких процессов она состоит. Также middle умеет работать с различными инструментами(мониторинг, деплой, профилирование, тестирование) с которыми человек без опыта вряд ли сталкивался в учебных целях.

На позицию Middle-разработчика soft skills становятся важным фактором.
Чем выше должность, тем с большим количеством людей приходится взаимодействовать. Поэтому очень часто при приёме на позицию middle-разработчика создаются дополнительные собеседования с HR-специалистом для составления психологического портрета будущего сотрудника. К этому собеседованию надо относиться также серьёзно, как и к техническому. Надо понимать, что Вам дальше работать с этими людьми. И если Вы чувствуете, что Ваши будущие коллеги Вам не очень подходят, то лучше сразу отказаться от дальнейшего сотрудничества.

На позицию middle-разработчика реже дают тестовые задания .
Это утверждение достаточно субъективное. Лично я действительно столкнулся с таким фактом. Связываю это с тем, что работодателя больше интересует твоё резюме. Если резюме составлено неважно, то скорее всего следует ждать тестового задания.

Вопросы

В данном разделе будет представлен основной список вопросов, который я задаю работодателю на собеседовании. Возможно через какое-то время этот список будет расширяться или сужаться. Нужно отметить, что эти вопросы следует задавать именно на технических собеседованиях и желательно именно тому, с кем Вам потом взаимодействовать.

1. Как дела с тестированием? Какие тесты вы пишете? Какие библиотеки для тестирования вы используете? (фабрики, моки и т.д.)
Тестирование – очень важная часть любой разработки. В моём понимании, тесты должны писать все разработчики хотя бы в каком-то виде. Единственное, кому можно простить отсутствие тестов – это стартапы. В стартапах часто меняется курс движения из-за чего старые проекты обычно бывают никому не нужны. А значит обеспечение качеством таких проектов было впустую потраченным временем. Для всех остальных компаний пощады в этом вопросе быть не должно. Нужно понимать, что внедрение нового сотрудника в проект на первых порах будет приводить к различным ошибкам в коде. И тесты в данном случае является его личной перестраховкой и перестраховкой того, кто будет выливать его решения в production.
Когда работодатель ответит на вторую часть вопроса, Вы сможете понять насколько хорошо команда обеспечивает качеством свой продукт и также возможные обязанности разработчика о которых не было рассказано в вакансии.
Стоит отметить, что на этом вопросе технические специалисты часто начинают теряться. Кто-то иногда говорит, что команда только начала заниматься написанием тестов и еще не знакома со всеми тонкостями этого ремесла. Но иногда я слышал вот такой ответ: «Тестами должны заниматься тестировщики, а разработчик должен творить». Это абсолютно неверно. Разработчик должен писать необходимый минимум тестов, потому что именно он знает, как должен работать функционал, который он сотворил. Никто не говорит о ненужности тестировщиков. Но важно понимать, что разработчики тоже должны нести ответственность за качество своего кода.

2. Что делает разработчик с кодом перед тем, как отправить его в репозиторий?
Под этим вопросом понимается локальная проверка своего кода по различным параметрам. Вот небольшой список того, чем обычно проверяют код перед отправкой в репозиторий:

  • Flake8 – анализ кода на соблюдение PEP8,
  • Pylint – статический анализ кода,
  • Coverage – анализ кода на тестовое покрытие,
  • Tox – проверка кода на совместимость с различными версиями отдельных пакетов и с разными версиями Python.

Отсутствие данного кейса в разработке не является критичным. Также во многих компаниях этот кейс используется непосредственно в CI, и разработчик локально у себя ничего не запускает. Даже если это не используется в разработке, то было бы неплохо, чтобы люди, которые Вас собеседуют имели базовые представление об этих инструментах.

3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?
Этот вопрос не имеет никаких подводных камней и задаю я его чтобы получше понять устройство компании. Если в проектах нет CI/CD и DevOps-инженер тоже отсутствует, то есть вероятность что именно Вы будете этим заниматься. Поэтому этот момент тоже лучше обсудить на собеседовании.

4. Есть ли Code Review? Как оно проходит?
Первую часть вопроса можно оставить без комментариев, потому что все понимают важность этого мероприятия. Но стоит отметить что лично меня интересовало как именно оно проходит. Чаще бывает так, что каждый из команды ревьюит разработчика который сделал Merge Request. Но иногда встречается, что над любым разработчиком есть ментор/наставник и именно он ревьюит разработчика. Первый подход считаю более правильным, так как чем больше людей ревьюит код, тем лучше для проекта и для команды. Здесь сразу затрагиваются такие аспекты, как командное взаимодействие, коллективная ответственность, увеличение bus-фактора.

Мастер Йода рекомендует:  Думать как программист

5. Какую систему контроля версий Вы используете?
На данный момент в России существует немало компаний, которые до сих пор использует hg, svn и прочие древние системы контроля версии. Особенно это относится к компаниям, которые на рынке больше 10 лет. Этот вопрос больше проверяет насколько старая компания восприимчива к новым технологиям. Также стоит отметить, что я недолгий период времени принимал участие в разработке используя hg и особого удовольствия мне это не доставило.

6. Используете ли вы git/hg-flow или какую-либо определенную методологию при работе с git/hg?
Данный вопрос вытекает из предыдущего вопроса о системах контроля версий. Поэтому если команда не использует git/hg, то и задать его нет смысла. Если же компания использует git/hg, то этот вопрос Вам сможет показать насколько хорошо отлажен процесс разработки.

7. Используете ли Вы методологию разработки (scrum, kanban и т.д.)?
В разработке важно придерживаться какого-то определённого подхода(методологии). Самый популярный подход в разработке – итеративный. Такой подход позволяет определить Ваш вклад в проект. В моём понимании, если в команде используется какая-то методология – это однозначно хорошо. Это позволяет Вам определить Вашу эффективность. Также это помогает понимать Вам сроки выделенные на задачи. Это всё равно что у школьников есть 4 четверти в году, где им выставляют отметки, чтобы потом определить итоговую оценку за год.

8. Используются ли системы мониторинга в проектах(Sentry, NewRelic и т.д.)?
Присутствие систем мониторинга в проекте так же важно, как и присутствие тестов. Именно системы мониторинга позволяют объективно оценить работу целой системы основываясь на действиях, которые совершает конечный пользователь. Если систем мониторинга нет, то стоит задуматься о качестве производимого продукта. Это всё равно что повар, который готовит еду, но никогда не у кого не спрашивает вкусная ли она.

9. Используется ли в проекте ELK-технология?
Для меня это тоже является важным показателем. Если ELK отсутствует, то очень трудно определить причину появления сложной ошибки в системе. Данный вопрос не настолько важен, как вопрос №8, но его тоже стоит задать чтобы понять насколько богат опыт у команды в профилировании сложных ошибок.

10. Какие БД используются в проекте? Почему именно такие?
Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Такой ответ считаю неуместным. Технический специалист должен понимать минусы/плюсы используемой им БД. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.

11. Какая версия языка Python используется в проектах? Если используется версия Python2.x, то планируется ли переход на Python3.x? И как будете происходить миграция с одной версии на другую?
Этот вопрос, равно как и предыдущей, направлен на оценку компетентности собеседующего, а также на оценку его рассуждения. Надо понимать, что работодатели бывают очень безграмотны и такие вопросы позволяют это выявить уже на стадии собеседования. Прежде чем задавать такого рода вопросы, я Вам настоятельно рекомендую самим углубиться в них.

12. Компания ищет fullstack-разработчика или backend-разработчика?
Этот вопрос я задаю только в том случае, если компанию это сама не уточнила перед собеседованием. Вакансии fullstack-разработчика на рынке труда можно встретить довольно часто. Многие компании считают это выгодным для себя. Мой личный опыт говорит мне что fullstack-разработчиков не бывает, так как frontend и backend стали слишком разными направлениями с того момента как появился Веб. Иными словами, «На двух стульях не усидишь».
В большинстве случаев компанию устраивает, то что ты не знаешь frontend и рассчитывает на то, что ты его подучишь непосредственно в бою. Уточню, что вакансия fullstack-разработчика неприемлема лично для меня. Многие же находят в этом отличную возможность окунуться в богатейший мир frontend-а при это не заплатив ни рубля.

13. Используется ли технология контейнеризации в проектах?
Этот вопрос является дополнением к вопросу №3.

14. Немного поспрашивать собеседующего о том, чем он занимался до этого проекта и давно ли он в проекте.
Этот вопрос очень важен. Чем богаче опыт вашего собеседующего, тем больше это отразится на ваших умениях и навыках через какое-то время. Особенно хорошо задавать такой вопрос в небольшой компании, где медленная текучка кадров.

15. Существует ли в компании годовая/квартальная оценка сотрудников и как она происходит?
Любому сотруднику полезно получать обратную связь от своих коллег. Если в компании существуют для это специальные мероприятия, то это прекрасно. Если — нет, то в этом нет ничего страшного. В любом случае, никто не запрещает запросить обратную связь от коллег в вольной форме.


16. Есть ли у в компании переработки? Если есть, то компенсируются ли они и как часто они происходят?
Мало кому нравится перерабатывать, особенно если ты студент или кормящий отец. Существует огромное количество компаний, которые ставят переработки на первый план. Чтобы понять, что в компании нет переработок или есть но редко, необходимо задавать подобного рода вопросы. Если в компании изредка случаются переработки, то в этом нет ничего критичного. Если переработки участились, то стоит задуматься о целисообразности дальнейшего пребывания в компании.

17. Насколько в компании сильна бюрократия? (Оцените от 1 до 10)
Многие разработчики даже не догадываются о присутствии бюрократии в IT-сфере, но, к сожалению, она есть. Особенно это относится к крупным старым компаниям или к компаниям, которые работают с гос. заказами. Степень бюрократии в компании зависит только от фантазии руководства. Обычно бюрократия заключается в различных формальных заявках, визированиях, доступах, конфликтах интересов между несколькими подразделениями компании и написании скучной сырой документации в Word. Главная проблема такой бюрократии – это очень сильное торможение процесса разработки. То что в нормальной компании делается за один рабочий день, тут на это будут уходить недели. Проще говоря, чем сильнее бюрократия в компании, тем медленнее развитие продукта и Ваше развитие как специалиста.

18. Как обстоят дела с выбиванием ресурсов?
Под ресурсами понимаются новые компьютеры для сотрудников, сервера, домены, лицензии и т.д. Этот вопрос можно также отнести к предыдущему вопросу о бюрократии.

19. Как собеседующий относится к новым внедрениям в проекте?
Данный вопрос позволяет оценить демократичность внутри команды. А также данный вопрос позволит понять, насколько голос обычного разработчика имеет вес для команды и наставника.

20. Является ли компания участником каких-либо IT-конференций и есть ли у компании публикации на IT-темы?
Конференция – это отличная возможность для разработчика и для компании заявить о себе и своих достижениях. Если компания публикуется и является участником конференций, то в какой-то момент Вы тоже сможете пользоваться такой возможностью. Если Вам это не интересно, то и спрашивать об этом нет смысла.

21. Есть ли митапы внутри компании?
Здесь речь пойдет о митапах у разработчиков внутри команды или между командами. Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших soft skills.

22. Есть ли в компании стажёры и развита ли система наставничества?
Стажёры – это потенциальное будущее компании. Если в компании есть стажёры, то возможно Вы сможете быть для них наставником и делиться своим личным опытом. Наставничество – это тоже одно из направлений где Вы сможете развиваться.

Заключение

Всё вышесказанное является моими мыслями, основанными на личном опыте и не является 100-процентно верной информацией. Главная мораль статьи заключается в том, что проверять надо не только кандидата, но и работодателя. Также не стоит нервничать перед собеседованиями или на собеседованиях. Надо понимать что собеседующие такие же люди как и Вы, которые тоже ошибаются или чего-то не знают или не понимают.

Общественная записная книжка

следы для себя и потомков

четверг, 5 июля 2020 г.

Python

  • Working with Python Pandas and XlsxWriter
  • Обработка данных с помощью pandas
  • Creating Excel files with Python and XlsxWriter
  • PyMystem3 — морфологическая библиотека для русского языка
  • Logging — библиотека для удобного ведения логов в Python
  • zipapp — Manage executable python zip archives
  • доступ к Exchange (python)
  • Принимает и отправляем почту на python через outlook
  • Отправляем push-уведомления в Linux используя Python
  • Тестирование в Python [unittest]. Часть 2. TestCase
  • PyInstaller is a program that freezes (packages) Python programs into stand-alone executables, under Windows, Linux, Mac OS X, FreeBSD, Solaris and AIX
  • Automate the Boring Stuff with Python
  • Click — library for CLI interface for our python scripts
  • Kivy — Open source Python library for rapid development of applications
    that make use of innovative user interfaces, such as multi-touch apps.
  • How to decode a QR-code image in (preferably pure) Python?
  • PyAutoGUI is a Python module for programmatically controlling the mouse and keyboard.
  • Behave is behavior-driven development, Python style.
  • Хакинг FFmpeg с помощью Python — часть первая, часть вторая
  • PostgreSQL python
  • https://www.fullstackpython.com/postgresql.html
  • SqliteBrowser — sudo dnf install sqlitebrowser
  • Sqlite3
  • Python: Работа с базой данных, часть 1/2: Используем DB-API
  • SQLite в многопоточных приложениях
  • Работа с БД
  • http://qaru.site/questions/84392/python-sqlite3-and-concurrency
  • Модуль unittest: тестируем свои программы
  • Тестирование в Python [unittest] Часть1Часть2Часть3Часть4
  • Погружаемся в основы и нюансы тестирования Python-кода

  • Визуализация данных c Python
  • https://tech.yandex.ru
  • Если нужно быстро и легко расшарить файлы из директории

python3 -m http.server

Scrapy Shell is a command line tool that provides you opportunity to test your parsing code without running thee entire crawler.
Unlike the crawler which goes to all the links, Scrapy Shell save the DOM of an individual page for data extraction.
Например:
scrapy shell https://www.olx.com.pk/item/asus-eee-pc-atom-dual-core-4cpus-beautiful-laptops-fresh-stock-IDUVo6B.html#4001329891

  • sudo apt-get install libpulse-dev
  • sudo apt-get install libpcre3 libpcre3-dev
  • установить http://www.swig.org/download.html
  • pip3 install pocketsphinx

[Unit]
Description=X Virtual Frame Buffer Service
After=network.target

[Service]
ExecStart=/usr/bin/Xvfb :99 -screen 0 1024x768x24

  • Python-telegram-bot
  • https://python-telegram-bot.readthedocs.io/en/stable/
  • Пишем телеграмм бот на Python
  • Python telegram.InlineKeyboardButton() Examples
  • https://monsterdeveloper.gitbooks.io/writing-telegram-bots-on-java/lesson-7.-creating-users-database-with-mongodb.html
  • Пишем диалоговые боты
  • Как писали фриланс биржу в телеграм боте
  • Отсылка сообщений при определенных событиях
  • Telegram messenger CLI
  • Автоматизация оповещения от ТелеграммБота
  • Telethon — библиотека для работы с телеграммом

Проекты с телеграмм ботами

  • Telegram боты. Загружаем файлы больше 50мб
  • Telegram API демон — склеиваем последовательные сообщения
  • python3 −m venv название_директория
  • source env/bin/activate — активировать виртуальное окружение
  • pip install Jupyter — установка Jupyter Notebook

Использовать virtualenv! Оно создаст изолированные окружения для ваших приложений и позволит устанавливать пакеты именно в эти окружения, а не глобально.

Для установки воспользуемся pip:

$ pip3 install virtualenv

Две основные команды:

virtualenv myproject
source myproject/bin/activate

  • dnf groupinstall ‘Development Tools’
  • dnf install gcc-c++
  • dnf install rpm-build
  • dnf install python-devel
  • dnf install python3-devel
  • dnf install python-pip
  • dnf install python3-pip
  • pip3 install jupyter
  • sudo yum install -y epel-release
  • sudo yum install -y python34
  • # Install pip3
  • sudo yum install -y python34-setuptools # install easy_install-3.4
  • sudo easy_install-3.4 pip
  • yum install python34-devel.i686
  • yum install gcc gcc-c++
    yum install python34-devel

easy_install-3.4 numpy
easy_install-3.4 pandas — будет устанавливаться долго

  • ?имя_переменной — общая информация об объекте
  • ??имя_переменной — исходный код объекта
  • %run — выполнение любого файла как Python-программу (скрипт выполняется в пустом пространстве имен)
  • %cpaste — приглашение для вставки кода
  • %timeit предложение — замер времени выполнения команды несколько раз и усредняет время выполнения
  • %time предложение — время выполнения команды
  • %reset — возвращает простр-во имен в начальное состояние
  • %quickref — вывод краткую справку по IPython
  • %magic — вывести подробная док-я по магическим командам
  • %debug — вход в интерактивный отладчик в точке послед вызова
  • %hist — напечатать историю введенных команд
  • %pdb — автоматом входить в отладчик после любого исключения
  • %paste — выполнить отформатированный код из буфера обмена
  • %cpaste —
  • %page OBJECT — сформировать красиво инфу об объекте
  • %who , %who_ls , %whos — вывод переменных с разной степению детализации
  • %xdel переменная

Взаимодествие с ОС

  • !cmd — выполнить команду в оболочке
  • output = !cmd args
  • %cd каталог
  • %pwd — текущий каталог
  • %dirs
  • %pushd каталог
  • %popd
  • %env — вернуть переменные среды в виде словаря

Интересные проекты на Python

  • ShutIt — is an automation tool that models a user’s actions on a terminal
  • AutoTEST
  • quietnet — Simple chat program that communicates using inaudible sounds
  • home-assistant — Open-source home automation platform running on Python 3
  • pytube is a lightweight, Pythonic, dependency-free, library (and command-line utility) for downloading YouTube V >task management & automation tool
  • scdl — Python Soundcloud Music Downloader
  • simiki — Simiki is a simple wiki framework, written in Python
  • SpeechPy — A Library for Speech Processing and Recognition
  • face_recognition — The world’s simplest facial recognition api for Python and the command line
  • Rodeo — A data science IDE for Python
  • Gooey — Turn (almost) any Python command line program into a full GUI application with one line
Добавить комментарий