Привет, Хабр!

Это третья часть в серии статей "Учимся разворачивать микросервисы", и сегодня речь пойдет о Helm 3. В прошлой части мы создали Kubernetes конфигурацию для учебного проекта из 2 микросервисов (бекенда и шлюза) и задеплоили все это в Google Kubernetes Engine. В этой статье мы напишем Helm-чарт для нашей системы, создадим для него репозиторий на основе GitHub Pages и задеплоим проект в GKE с помощью Helm.

Предлагаю ознакомиться с расшифровкой доклада Ивана Пономарёва «Ansible playbooks — это код: проверяем, тестируем, непрерывно интегрируем».

Рефакторинг кода может быть увлекательным, особенно если это код вашей инфраструктуры. К тому же Ansible-роли почему-то имеют тенденцию к быстрому увеличению сложности. И это добавляет «изюминку» в вашу задачу. Иван расскажет, как можно преодолевать сложность Ansible-кода с помощью тестирования. В Docker-контейнерах.
По мере разрастания кодовой базы в Ansible приходят знакомые проблемы: сложность поддержки кода, ошибки и страх изменений. У знакомых проблем есть знакомое решение: автоматическое тестирование и CI. В докладе Иван покажет, как с использованием ряда инструментов решить проблемы «хрупкости» Ansible-кода, выполнить статический анализ, протестировать Ansible-скрипты и настроить CI-системы для публикации ролей в Ansible Galaxy.

Привет, Хабр!

Это вторая часть из серии статей "Учимся разворачивать микросервисы". В предыдущей части мы написали 2 простеньких микросервиса — бекенд и шлюз, и разобрались с тем, как их упаковать в docker-образы. В этой же статье мы будем организовывать оркестрацию наших docker-контейнеров с помощью Kubernetes. Мы последовательно составим конфигурацию для запуска системы в Minikube, а затем адаптируем ее для деплоя в Google Kubernetes Engine.

Прим. перев.: Эта статья входит в состав опубликованных в свободном доступе материалов проекта learnk8s, обучающего работе с Kubernetes компании и индивидуальных администраторов. В ней Daniele Polencic, руководитель проекта, делится наглядной инструкцией о том, какие шаги стоит предпринимать в случае возникновения проблем общего характера у приложений, запущенных в кластере K8s.



TL;DR: вот схема, которая поможет вам отладить deployment в Kubernetes:

Статья доработана с учетом ценных комментариев, дополнен список источников.
Данный чек-лист — компиляция нескольких источников, я его делал для себя, когда в конце 2019 года покупал 13" б/у макбук 2015 года, последний из имевших нормальную клавиатуру и набор портов, перед тем как Apple перешла на клавиатуру-бабочку и usb-с порты.

Какую модель б/у макбука стоит брать? Вместо введения

На этот вопрос нет однозначного ответа, поскольку все зависит от ваших задач. Для начала 2020 года и задач «офисной» работы и серфинга я бы сформулировал ответ так — можно брать любой мак от 2014 и более позднего года выпуска, на полноценном процессоре (m5 и m7 брать скорее нежелательно). Macbook pro таким образом предпочтительнее macbook air, поскольку у последних процессор и система охлаждения обычно проигрывает в сравнении.

Оптимальный выбор, который проработает еще несколько лет без проблем — это модели с четырехядерным процессором (не путать с четырехпоточным!), такие ставили обычно в 15" модели. Оперативки не менее 8 Гб, SSD лучше 256 Гб и больше, хотя на 128 с определенными неудобствами жить тоже можно. Батарея оптимально с менее чем 500 циклами перезарядки.

Стоимость 13" макбуков 2014-2016 годов колеблется от 40 до 55 тыс. рублей, причем варианты в хорошем состоянии около 40-45 тыс. мне кажутся наиболее выгодными с точки зрения дилеммы «взять б/у или доложить и взять новый».

Надо иметь ввиду, что все модели 2013-2015 года включительно очень ограничены с точки зрения апгрейда, а апгрейд моделей с 2016 и более поздних вовсе невозможен, поэтому берите сразу конфигурацию, которой вам хватит на ближайшие 2-3 года.

Моделей с клавиатурой-бабочкой (2016-2019 гг) не то что бы надо избегать, но надо отдавать себе отчет, что они требуют радикально более бережного к себе отношения, чтобы клавиатура проработала дольше. Сейчас полно предложений продажи mac mini — это тоже хороший вариант, особенно если он базируется на нормальном четырехядерном процессоре.

Mock на английском значит «имитация», «подделка». Модуль с таким названием помогает сильно упростить тесты модулей на Питоне.

Принцип его работы простой: если нужно тестировать функцию, то всё, что не относится к ней самой (например, чтение с диска или из сети), можно подменить макетами-пустышками. При этом тестируемые функции не нужно адаптировать для тестов: Mock подменяет объекты в других модулях, даже если код не принимает их в виде параметров. То есть, тестировать можно вообще без адаптации под тесты.

Такое поведение — уже не надувные ракетные установки, а целая надувная земля, вокруг которой могут летать испытуемые ракеты и самолёты.

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

Это перевод 1.17 версии руководства от Rafe Kettler.

Содержание

1. Вступление
2. Конструирование и инициализация
3. Переопределение операторов на произвольных классах
   • Магические методы сравнения
   • Числовые магический методы
4. Представление своих классов
5. Контроль доступа к атрибутам
6. Создание произвольных последовательностей
7. Отражение
8. Вызываемые объекты
9. Менеджеры контекста
10. Абстрактные базовые классы
11. Построение дескрипторов
12. Копирование
13. Использование модуля pickle на своих объектах
14. Заключение
15. Приложение 1: Как вызывать магические методы
16. Приложение 2: Изменения в Питоне 3

Вступление

Что такое магические методы? Они всё в объектно-ориентированном Питоне. Это специальные методы, с помощью которых вы можете добавить в ваши классы «магию». Они всегда обрамлены двумя нижними подчеркиваниями (например, __init__ или __lt__). Ещё, они не так хорошо документированны, как хотелось бы. Все магические методы описаны в документации, но весьма беспорядочно и почти безо всякой организации. Поэтому, чтобы исправить то, что я воспринимаю как недостаток документации Питона, я собираюсь предоставить больше информации о магических методах, написанной на понятном языке и обильно снабжённой примерами. Надеюсь, это руководство вам понравится. Используйте его как обучающий материал, памятку или полное описание. Я просто постарался как можно понятнее описать магические методы.

Вернуться Дальше

Вы узнаете, как организовать тесты в классы, модули и каталоги. Затем я покажу вам, как использовать маркеры, чтобы отметить, какие тесты вы хотите запустить, и обсудить, как встроенные маркеры могут помочь вам пропустить тесты и отметить тесты, ожидая неудачи. Наконец, я расскажу о параметризации тестов, которая позволяет тестам вызываться с разными данными.

Автор иллюстрации — Magdalena Tomczyk

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

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

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

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

Для кого: для изучающих Python и уже имеющих начальное представление о коллекциях и работе с ними, желающих систематизировать и углубить свои знания, сложить их в целостную картину.

Будем рассматривать стандартные встроенные коллекционные типы данных в Python: список (list), кортеж (tuple), строку (string), множества (set, frozenset), словарь (dict). Коллекции из модуля collections рассматриваться не будут, хотя многое из статьи должно быть применимым и при работе с ними.

ОГЛАВЛЕНИЕ:

1. Классификация коллекций;
2. Общие подходы к работе с коллекциями;
3. Общие методы для части коллекций;
4. Конвертирование коллекций.

Часть 1	Часть 2	Часть 3	Часть 4

Данная статья является продолжением моей статьи "Python: коллекции, часть 1: классификация, общие подходы и методы, конвертация".

В данной статье мы продолжим изучать общие принципы работы со стандартными коллекциями (модуль collections в ней не рассматривается) Python.

Для кого: для изучающих Python и уже имеющих начальное представление о коллекциях и работе с ними, желающих систематизировать и углубить свои знания, сложить их в целостную картину.

ОГЛАВЛЕНИЕ:

1. Индексирование
2. Срезы
3. Сортировка

Часть 1	Часть 2	Часть 3	Часть 4

Продолжим изучать общие принципы работы со стандартными коллекциями (модуль collections в ней не рассматривается) Python. Будут рассматриваться способы объединения и обновления коллекций с формированием новой или изменением исходной, а также способы добавлять и удалять элементы в изменяемые коллекции.

Для кого: для изучающих Python и уже имеющих начальное представление о коллекциях и работе с ними, желающих систематизировать и углубить свои знания, сложить их в целостную картину.

Оглавление:

1. Объединение строк, кортежей, списков, словарей без изменения исходных.
2. Объединение множеств без изменения исходных.
3. Объединение списка, словаря и изменяемого множества с изменением исходной коллекции.
4. Добавление и удаление элементов изменяемых коллекций.
5. Особенности работы с изменяемой и не изменяемой коллекцией.

Часть 1	Часть 2	Часть 3	Часть 4

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

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

Будут рассмотрены: выражения-генераторы, генераторы списка, словаря и множества, вложенные генераторы (5 вариантов), работа с enumerate(), range().
А также: классификация и терминология, синтаксис, аналоги в виде циклов и примеры применения.

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

Оглавление:

1. Определения и классификация.
2. Синтаксис.
3. Аналоги в виде цикла for и в виде функций.
4. Выражения-генераторы.
5. Генерация стандартных коллекций.
6. Периодичность и частичный перебор.
7. Вложенные циклы и генераторы.
8. Использование range().
9. Приложение 1. Дополнительные примеры.
10. Приложение 2. Ссылки по теме.

Вернуться Дальше

Я обнаружил, что Python Testing с pytest является чрезвычайно полезным вводным руководством к среде тестирования pytest. Это уже приносит мне дивиденды в моей компании.

Chris Shaver
VP of Product, Uprising Technology

Данная статья о том как настроить современный почтовый сервер.
Postfix + Dovecot. SPF + DKIM + rDNS. С IPv6.
С шифрованием TLS. С поддержкой нескольких доменов — часть с настоящим SSL сертификатом.
С антиспам-защитой и высоким антиспам-рейтингом у других почтовых серверов.
С поддержкой нескольких физических интерфейсов.
С OpenVPN, подключение к которому через IPv4, и которое даёт IPv6.

Если вы не хотите изучать эти все технологии, но хотите настроить такой сервер — тогда эта статья для вас.

В статье отсутствуют попытки пояснить каждую деталь. Пояснение идёт к тому, что настроено не стандартно или важно с точки зрения потребителя.

Я только что завершил шестинедельный процесс трудоустройства на должность middle-senior разработчика на рынке, где сейчас ведется активная охота за талантами (Амстердам). Иными словами, я побывал на куче собеседований. Чтобы аккуратно разведать, какие компании мне больше всего подходят, я старался задавать побольше вопросов. Тут нужно найти правильный баланс, исходя из своих потребностей и того, кто с вами общается.

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

Об этом нет туториалов и объявлений на Avito. Об этом не пишут на хабре (уже пишут?). Обзор вашего приложения хоть и мог быть несправедлив, но явно был неподкупен. Или вам так казалось?
Если вы следите за конкурентами, или, не дай бог, вкладываете силы в ещё одно приложение-гороскопы, то сталкивались с нарушениями конкурентами гидлайнов. Я расскажу то, что знаю.

blog.miguelgrinberg.com

Miguel Grinberg

---

>>> следующая глава >>>

Эта статья является переводом нового издания учебника Мигеля Гринберга. Прежний перевод давно утратил свою актуальность.

Автор планирует завершить его выпуск в мае 2018. Я, со своей стороны, постараюсь не отставать с переводом.

Поддержка огромной кодовой базы с одновременным обеспечением высокой производительности большого числа разработчиков — это серьезный вызов. В течение последних 5 лет в Яндексе идет разработка особой системы непрерывной интеграции. В данной статье мы расскажем про масштаб кодовой базы Яндекса, про перенос разработки в единый репозиторий с trunk-based подходом к разработке, про то, какие задачи должна решать система непрерывной интеграции для эффективной работы в таких условиях.

Много лет назад в Яндексе никаких особенных правил в разработке сервисов не было: каждый отдел мог использовать любые языки, любые технологии, любые системы деплоя. И как показала практика, такая свобода не всегда помогала двигаться вперед быстрее. В то время для решения одних и тех же задач часто существовало несколько собственных или open-source разработок. С ростом компании такая экосистема работала всё хуже. При этом мы хотели остаться одним большим Яндексом, а не разделиться на множество независимых компаний, потому что это дает массу преимуществ: много людей делают одни похожие задачи, результаты их труда можно использовать повторно. Начиная от разнообразных структур данных, типа распределённых хеш-таблиц и lock-free очередей, и заканчивая множеством разного специализированного кода, который мы написали за 20 лет.