Здесь собраны лучшие и самые полезные репозитории Github, которые будут служить вам долгое время.
Екатерина @FeRvent
Пользователь
Как проходит собеседование Python-разработчика: вопросы для джуниоров и мидлов
7 мин
Собеседование — одна из наиболее стрессовых тем для разработчиков, но только первые двадцать раз.
Привет! Меня зовут Руслан, я один из наставников курса «Мидл Python-разработчик» в Яндекс.Практикуме. Около 12 лет я занимаюсь разработкой, из них девять — на Python. За это время я собеседовался на разные позиции десятки раз и сам провёл примерно пару сотен собеседований. Не всегда успешно :/ В этой статье поговорим о том, как снизить вероятность провалов и к чему быть готовым.
Предположим, что вы уже определились с потенциальным работодателем и вам предстоит собеседование.
В посте я расскажу про три основных этапа:
Привет! Меня зовут Руслан, я один из наставников курса «Мидл Python-разработчик» в Яндекс.Практикуме. Около 12 лет я занимаюсь разработкой, из них девять — на Python. За это время я собеседовался на разные позиции десятки раз и сам провёл примерно пару сотен собеседований. Не всегда успешно :/ В этой статье поговорим о том, как снизить вероятность провалов и к чему быть готовым.
Предположим, что вы уже определились с потенциальным работодателем и вам предстоит собеседование.
В посте я расскажу про три основных этапа:
- Подготовка к собеседованию: какую домашнюю работу провести, чтобы собеседование прошло легче.
- Собеседование: как оно проходит и какие вопросы ждать джунам и мидл-разработчикам.
- Что делать после собеседования и как быть, если вам отказали.
Pycon Weekend 2022: как прошла конференция по python в горах
2 мин
25-26 марта в Сочи прошла конференция для python-разработчиков Pycon Weekend. Мы были на курорте Красная Поляна, два дня слушали доклады, общались и катались на живописных горных склонах. Получилось, как всегда, очень душевно и полезно.
В программе конференции было 9 докладов, спикерам задавали очень много вопросов из зала. В кулуарах вопросы и обсуждения продолжались. Оба дня после официальной части нашей программы мы устраивали традиционные lightning talks, где за короткое время можно было рассказать о чем угодно: ребята рассказывали про свои проекты на питоне, про путешествия, про любимого питомца, а кто-то все отведенное время острил веселыми шуточками и веселил всех участников.
Сейчас мы готовим нашу следующую, самую большую и душевную конференцию для pythton-разработчиков Pycon Russia. Она пройдет 30-31 июля в Москве. Программный комитет уже ведет активную работу по формированию программы, успевайте подавать заявки на выступления до 15 мая, чтобы стать спикером. А билеты можно купить по ранней цене до 1 июня.
А пока мы готовим для вас Pycon Russia 2022, предлагаем вам посмотреть доклады с Pycon Weekend 2022.
? Василий Копытов (Avito, Москва): «Как и почему мы перешли от Python к Go в нашем основном сервисе рекомендаций»
VictoriaMetrics и мониторинг приватных облаков. Павел Колобаев
9 мин
VictoriaMetrics — быстрая и масштабируемая СУБД для хранения и обработки данных в форме временного ряда (запись образует время и набор соответствующих этому времени значений, например, полученных через периодический опрос состояния датчиков или сбор метрик).
Python. 10 вопросов на знание языка
1 мин
Несколько вопросов, которые помогут составить общее впечатление о знании языка, к примеру, на собеседовании
Screen — текстовый оконный менеджер
4 мин
Людям, которые в Линуксе часто работают с консолью приходилось сталкиваться с проблемой необходимости нескольких терминалов, например в одном из них пользователь правит текстовый файл, а в другом идет компиляция программы. Существует много способов решения данной проблемы, например открыть несколько псевдо-терминалов или открыть несколько вкладок. В данной статье я хотел бы рассмотреть способ, не связанный с каким-то конкретным терминалом: использовать консольный оконный менеджер Screen.
Итак, что же представляет из себя Screen?
Итак, что же представляет из себя Screen?
Некоторые (полезные) советы по Windows 7
4 мин
Содержание:
1. Быстрый запуск приложений с правами администратора
2. Отчет об использовании электроэнергии
3. Поиск в интернете из меню «пуск»
4. Навигация по панели задач
5. Скрытие значка Windows Live Messenger
6. Сворачивание окон
7. Быстрое открытие и закрытие копии приложения
8. Копирование файлов из командной строки в несколько потоков
9. Быстрое управление окном
1. Быстрый запуск приложений с правами администратора
2. Отчет об использовании электроэнергии
3. Поиск в интернете из меню «пуск»
4. Навигация по панели задач
5. Скрытие значка Windows Live Messenger
6. Сворачивание окон
7. Быстрое открытие и закрытие копии приложения
8. Копирование файлов из командной строки в несколько потоков
9. Быстрое управление окном
Изучение Node.js от начала до конца на практике. Часть 1
14 мин
Туториал
Предыстория
Различной документации по Node.js его модулях огромное количество, всякого рода готовых решений тоже хватает, но начав писать сайт сталкиваешься с проблемой: «А с чего начать?». Хочу вам рассказать свой опыт изучения Node.js на практике. Задача стоит довольно простая и понятная — GPS Трекер с интернет сервисом, отображающим наши передатчики на карте, рисующим маршрут перемещения и т.д., на сколько разгуляется фантазия. Проект не коммерческий и пишется
Последние 15 недель 
Заметки для построения эффективных Django-ORM запросов в нагруженных проектах
11 мин
Написано, т.к. возник очередной холивар в комментариях на тему SQL vs ORM в High-Load Project (HL)
В заметке Вы сможете найти, местами, банальные вещи. Большая часть из них доступна в документации, но человек современный часто любит хватать все поверхностно. Да и у многих просто не было возможности опробовать себя в HL проектах.
Читая статью, помните:
И-и-и да, в статье будут показаны ошибки понимания ORM, с которыми я столкнулся за три с лишним года работы с Django.
Преамбула
В заметке Вы сможете найти, местами, банальные вещи. Большая часть из них доступна в документации, но человек современный часто любит хватать все поверхностно. Да и у многих просто не было возможности опробовать себя в HL проектах.
Читая статью, помните:
- Никогда нельзя реализовать HL-проект на основе только одной манипуляции с ORM
- Никогда не складывайте сложные вещи на плечи БД. Она нужна Вам чтобы хранить инфу, а не считать факториалы!
- Если вы не можете реализовать интересующую Вас идею простыми средствами ORM — не используйте ORM для прямого решения задачи. И тем более не лезте в более низкий уровень, костыли сломаете. Найдите более элегантное решение.
- Извините за издевательски-юмористический тон статьи. По другому скучно :)
- Вся информация взята по мотивам Django версии 1.3.4
- Будьте проще!
И-и-и да, в статье будут показаны ошибки понимания ORM, с которыми я столкнулся за три с лишним года работы с Django.
Настройка кластера с несколькими регионами для облачного хранилища объектов с OpenStack Swift
8 мин
Автор: Олег Гельбух
Прошлой осенью в блоге команды SwiftStack появился интересный обзор их подхода к созданию мультирегиональных кластеров Объектного хранилища OpenStack (кодовое название проекта — Swift). Этот подход хорошо сочетается со схемой географически распределенного кластера Swift с сокращенным числом реплик (3+1 вместо 3+3, например), над которой мы совместно работали с компанией Webex примерно в это же время. Я хотел бы кратко описать наш подход и остановиться на плане внедрения и предлагаемых изменениях кода Swift.
Я хотел бы начать с краткого обзора текущих алгоритмов Swift, чтобы затем пояснить, что именно требуется сделать, чтобы создать кластер из нескольких географически разделенных регионов.
Прошлой осенью в блоге команды SwiftStack появился интересный обзор их подхода к созданию мультирегиональных кластеров Объектного хранилища OpenStack (кодовое название проекта — Swift). Этот подход хорошо сочетается со схемой географически распределенного кластера Swift с сокращенным числом реплик (3+1 вместо 3+3, например), над которой мы совместно работали с компанией Webex примерно в это же время. Я хотел бы кратко описать наш подход и остановиться на плане внедрения и предлагаемых изменениях кода Swift.
Текущее состояние OpenStack Swift
Я хотел бы начать с краткого обзора текущих алгоритмов Swift, чтобы затем пояснить, что именно требуется сделать, чтобы создать кластер из нескольких географически разделенных регионов.
Обеспечение бесперебойности (HA) с платформой OpenStack: варианты топологий
9 мин
Автор: Piotr Siwczak
Когда я разрабатывал свою первую инфраструктуру OpenStack, я с трудом находил информацию о том, как следует распределять многочисленные ее компоненты по оборудованию. Я изучил множество документов, в том числе справочник по архитектуре Rackspace (который ранее был размещен по ссылке referencearchitecture.org, но сейчас, похоже, эта ссылка устарела). Я также просмотрел проектные схемы в документации OpenStack. Должен признать, что тогда у меня были только базовые знания о том, как взаимодействуют компоненты, поэтому я остановился на достаточно простой схеме: один “управляющий узел”, который включал все компоненты, в том числе API-сервисы, nova-scheduler, Glance, Keystone, базу данных и RabbitMQ. Под управление узла я поместил ферму “рабочих лошадок” — вычислительных узлов. Я также организовал три сети: частную (для трафика с фиксированным IP-адресом и управления серверами), общедоступную (для трафика с динамическим IP-адресом) и для хранения (для трафика по протоколу iSCSI сервиса nova-volume).
Когда я начал работать в Mirantis, я значительно изменил свой подход. Я понял, что все мои идеи по созданию фермы выделенных вычислительных узлов с одним или двумя управляющими узлами, были неверными. С одной стороны, мой подход был хорош в плане разделения компонентов, но на практике мы можем с легкостью смешивать и компоновать рабочие компоненты без перегрузки OpenStack (например, сервис nova-compute с сервисом nova-scheduler на одном узле). Оказывается в OpenStack “управляющий узел” и “вычислительный узел” могут иметь разные значения в зависимости от того, как гибко распределены компоненты OpenStack.
В общем, можно предположить, что в каждой установке OpenStack должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:
Когда я разрабатывал свою первую инфраструктуру OpenStack, я с трудом находил информацию о том, как следует распределять многочисленные ее компоненты по оборудованию. Я изучил множество документов, в том числе справочник по архитектуре Rackspace (который ранее был размещен по ссылке referencearchitecture.org, но сейчас, похоже, эта ссылка устарела). Я также просмотрел проектные схемы в документации OpenStack. Должен признать, что тогда у меня были только базовые знания о том, как взаимодействуют компоненты, поэтому я остановился на достаточно простой схеме: один “управляющий узел”, который включал все компоненты, в том числе API-сервисы, nova-scheduler, Glance, Keystone, базу данных и RabbitMQ. Под управление узла я поместил ферму “рабочих лошадок” — вычислительных узлов. Я также организовал три сети: частную (для трафика с фиксированным IP-адресом и управления серверами), общедоступную (для трафика с динамическим IP-адресом) и для хранения (для трафика по протоколу iSCSI сервиса nova-volume).
Когда я начал работать в Mirantis, я значительно изменил свой подход. Я понял, что все мои идеи по созданию фермы выделенных вычислительных узлов с одним или двумя управляющими узлами, были неверными. С одной стороны, мой подход был хорош в плане разделения компонентов, но на практике мы можем с легкостью смешивать и компоновать рабочие компоненты без перегрузки OpenStack (например, сервис nova-compute с сервисом nova-scheduler на одном узле). Оказывается в OpenStack “управляющий узел” и “вычислительный узел” могут иметь разные значения в зависимости от того, как гибко распределены компоненты OpenStack.
В общем, можно предположить, что в каждой установке OpenStack должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:
Пишем своё первое приложение на Android
10 мин
Предисловие
Цель данного поста — с одной стороны поделиться своим успешным опытом старта разработки приложений на платформе Android и с другой стороны поспособствовать развитию рынка софта для этой замечательной и бурно растущей платформы за счёт (без ложной скромности скажу) возможно Вас, прочитавших данный пост. В сети, конечно, можно найти материалы на тему разработки приложения «чуть сложнее, чем helloworld», но как правило они разрозненные и в них не описываются различные мелкие подводные камешки. В данном посте мы рассмотрим полный цикл разработки приложения, начиная с чистого компьютера до готового apk-файла. Под катом скрины.
Автоматизированное тестирование мобильных приложений
6 мин
Я провел настоящее исследование ситуации с автоматизированным тестированием интерфейса мобильных приложений. Речь идет не о тестировании модулей, а именно о тестировании интерфейса финального приложения. И, да, прямо на телефоне!
Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.
В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…
Такие тесты проводятся после каждого релиза и занимают очень много времени.
В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.
По сравнению с вебом мобильная разработка еще очень молодая область, и я не ожидал увидеть хороших решений для автоматизированного тестирования интерфейсов. Оказалось, что их более чем достаточно. Хочу рассказать вам о некоторых из них.
Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.
В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…
Такие тесты проводятся после каждого релиза и занимают очень много времени.
В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.
По сравнению с вебом мобильная разработка еще очень молодая область, и я не ожидал увидеть хороших решений для автоматизированного тестирования интерфейсов. Оказалось, что их более чем достаточно. Хочу рассказать вам о некоторых из них.
Тестирование в Mail.Ru Group
12 мин
Эта статья написана по мотивам одноименного доклада на В статье я расскажу, о том, каким на самом деле может быть тестирование, как мы сделали тестирование продуктивной и интересной работой, какие задачи мы решаем, и почему работать у нас хорошо.
SALT – ПО для управления конфигурациями на Python
4 мин
Уважаемые коллеги, хочу представить вашему вниманию одну из систем управления конфигурациями, полностью написанную на Python. Она достаточно новая, но уже заслуживает внимания. Если вам интересно как можно управлять парком серверов и рабочих станций как единой системой с помощью этого приложения – прошу под кат.
Code Like a Pythonista: Idiomatic Python (part0)
12 мин
Перевод
От переводчика:
Я только начал изучать Python. С самого первого знакомства язык порадовал симпатичными конструкциями и синтаксически-гарантированной удобностью к чтению и пониманию кода.
В процессе освоения, при написании своего кода, бывает, сомневаюсь в правильности выбранных способов с точки зрения Python-way ( PEP 8 — Style Guide for Python Code, если угодно). Для вникания в идеологию программирования, в Python-сообществе кроме исчерпывающей документации, ко всеобщей радости, накоплено уже немало вспомогательных материалов, таких как статья Python Tips, Tricks, and Hacks, перевод которой недавно появился на Хабре
Мне понравилась статья Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python» (David Goodger «Code Like a Pythonista: Idiomatic Python»). Для лучшего её усвоения решил оформить (в силу умения) полноценный перевод, потом показалось здравой идеей поделиться с Хабром.
Пока работал над переводом, пришло понимание, что статья существенно больше, чем показалась при прочтении ее в оригинале, поэтому постить буду частями, чтобы не выпасть из формата Хабра-статьи.
Продолжение и окончание перевода.
Code Like a Pythonista: Idiomatic Python (part1)
9 мин
Перевод
Это продолжение перевода статьи Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python»
Начало и окончание перевода.
Спасибо всем хабраюзерам за оценки первой части, ценные замечания и положительные комментарии. Постарался учесть ошибки, снова жду конструктивного обсуждения.
Тестирование — это не поиск ошибок!
5 мин
Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?
А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.
А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.
Как я сам научился программировать за 8 недель
3 мин
Для многих, кто никогда не программировал, обучение программированию кажется невероятно сложной задачей. Как бы то ни было, спасибо тому огромному количеству ресурсов, которые недавно стали доступны в Интернет и являются бесплатными — самообучение программированию никогда еще не было таким простым.
Я начал изучать программирование в начале этого года, и могу сказать по своему опыту, что изучение достаточного количества материала, чтобы создать свой собственный прототип не такая уж и сложная задача, как вам кажется. В самом деле, если вы хотите иметь рабочий прототип в течение двух месяцев, не прибегая к использованию отгулов, это абсолютно выполнимая задача.
Ниже я описал простой путь от ничего не зная о разработке программного обеспечения до обладания рабочим прототипом за восемь недель, который примерно повторяет шаги, которые я выполнил.
Я начал изучать программирование в начале этого года, и могу сказать по своему опыту, что изучение достаточного количества материала, чтобы создать свой собственный прототип не такая уж и сложная задача, как вам кажется. В самом деле, если вы хотите иметь рабочий прототип в течение двух месяцев, не прибегая к использованию отгулов, это абсолютно выполнимая задача.
Ниже я описал простой путь от ничего не зная о разработке программного обеспечения до обладания рабочим прототипом за восемь недель, который примерно повторяет шаги, которые я выполнил.