Вот какое дело: как показывают мои изыскания, большинство веб-разработчиков поразительно мало знают об HTTP-заголовках или, в целом, о стандарте HTTP. Я имею в виду, что я понимаю то, что во многих университетах и школах, вероятно, этому не учат (там, где я учился, определённо, так и было). А кто будет, сидя дома праздным воскресным утром, думать о том, чтобы развлечь себя чтением стандарта HTTP? Да никто. Знаю, но… есть одно важное обстоятельство: отсутствие хоть какого-то понимания стандарта HTTP — это зияющая дыра в знаниях веб-разработчиков, в знаниях многих из тех, кто это читает. Предлагаю это исправить.

https://habr.com/ru/post/713142/?utm_source=habrahabr&utm_medium=rss&utm_campaign=713142

Публикуем седьмую часть (1, 2, 3, 4, 5, 6) перевода руководства по модулю asyncio в Python. Здесь представлены разделы исходного материала с 17 по 19.

https://habr.com/ru/post/711012/?utm_source=habrahabr&utm_medium=rss&utm_campaign=711012

Привет, Хабр! Публикуем пятую часть (первая, вторая, третья, четвёртая) перевода руководства по модулю asyncio в Python. Здесь представлены разделы оригинала с №10 по №13.

https://habr.com/ru/post/709272/?utm_source=habrahabr&utm_medium=rss&utm_campaign=709272

Сегодня, в четвёртой части (первая, вторая, третья) перевода учебного руководства по модулю asyncio в Python, представляем вашему вниманию разделы оригинала №8 и 9.

https://habr.com/ru/post/707558/?utm_source=habrahabr&utm_medium=rss&utm_campaign=707558

Примечание Wunder Fund: мы very early adopters Ноушена и большие его фанаты. Поэтому решили перевести нетипичную для нас статью о том, как он создавался, как рос, как развивалась его стратегия. В статье есть ряд интересных мыслей про развитие продуктов.

Сегодня публикуем вторую часть перевода материала о стратегиях роста платформы Notion.

-> Головокружительная первая часть

https://habr.com/ru/post/707372/?utm_source=habrahabr&utm_medium=rss&utm_campaign=707372

Примечание Wunder Fund: мы very early adopters Ноушена и большие его фанаты. Поэтому решили перевести нетипичную для нас статью о том, как он создавался, как рос, как развивалась его стратегия. В статье есть ряд интересных мыслей про развитие продуктов.

Что можно узнать о стратегиях роста бизнеса, в основе которых лежит продукт и формируемое вокруг него сообщество пользователей, проанализировав SaaS-стартап стоимостью 10 миллиардов долларов?

https://habr.com/ru/post/705386/?utm_source=habrahabr&utm_medium=rss&utm_campaign=705386

Сегодня публикуем третью часть (первая, вторая) перевода учебного руководства по модулю asyncio в Python. Здесь представлены разделы оригинала №5, 6 и 7.

https://habr.com/ru/post/702484/?utm_source=habrahabr&utm_medium=rss&utm_campaign=702484

Публикуем вторую часть руководства по модулю asyncio в Python, в которой представлены разделы оригинала №3 и 4. Читать головокружительную первую часть.

https://habr.com/ru/post/701982/?utm_source=habrahabr&utm_medium=rss&utm_campaign=701982

Python-модуль asyncio позволяет заниматься асинхронным программированием с применением конкурентного выполнения кода, основанного на корутинах. Хотя этот модуль имеется в Python уже много лет, он остаётся одним из самых интересных механизмов языка. Но asyncio, при этом, можно назвать ещё и одним из модулей, которые вызывают больше всего недоразумений. Дело в том, что начинающим разработчикам бывает трудно приступить к использованию asyncio.

Перед вами — подробное и всестороннее руководство по использованию модуля asyncio в Python. В частности, здесь будут рассмотрены следующие основные вопросы:

https://habr.com/ru/post/700474/?utm_source=habrahabr&utm_medium=rss&utm_campaign=700474

Методология Twelve-Factor App (Приложение двенадцати факторов), которую создал сооснователь платформы Heroku Адам Уиггинс, направлена на разработку SaaS-приложений. Документ, описывающий эту методологию, включает в себя множество идей, применение которых сделало использование и, я уверен, создание платформы Heroku, увлекательным и благодарным трудом.

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

Как, со времени представления методологии Twelve-Factor App в 2011 году, эволюционировали принципы, положенные в её основу? Чему они могут нас научить сегодня? Как эти принципы изменили положение дел в недавнем прошлом?

https://habr.com/ru/post/699170/?utm_source=habrahabr&utm_medium=rss&utm_campaign=699170

Подошёл к концу 25-летний период, когда в компании Netflix придерживались подхода, в соответствии с которым все инженеры-программисты находились на одном карьерном уровне. Что можно сказать о новой системе карьерных уровней Netflix? Как их воспринимают сотрудники компании?

В апреле сего года я, в The Scoop #9, рассказал о том, как Netflix собирается ввести у себя систему карьерных уровней для инженеров-программистов:

Netflix рассматривает вопрос о введении следующей системы карьерных уровней:

— Engineer 1 (Инженер-программист 1)
— Engineer 2 (Инженер-программист 2)
— Senior (Старший инженер-программист)
— Staff (Ведущий инженер-программист)
— Principal (Главный инженер-программист)

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

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

https://habr.com/ru/post/695572/?utm_source=habrahabr&utm_medium=rss&utm_campaign=695572

Система, основанная на GPT-3, сообщает о том, что заголовок для этой статьи (How to Create a Blog Post Title Optimizer with GPT-3 and Hacker News Data) очень плох.

Я, с объективной точки зрения, очень плохо умею придумывать заголовки для своих статей. И это — проблема, так как в наши дни всем известно, что хороший заголовок может оказаться единственным фактором, влияющим на то, «завирусится» ли статья, или останется никем не замеченной. Особенно это справедливо для таких сфер, как наука о данных и машинное обучение. Пишу я обычно именно об этом.

Почему бы мне не воспользоваться приёмами из вышеупомянутых областей знаний для создания оптимизированных заголовков для блог-постов?

https://habr.com/ru/post/695228/?utm_source=habrahabr&utm_medium=rss&utm_campaign=695228

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

https://habr.com/ru/post/693592/?utm_source=habrahabr&utm_medium=rss&utm_campaign=693592

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

Сегодня, правда, мы не собираемся говорить о кулинарных изысках. Мы говорим о системе очередей, которую используют рестораны. Если вам повезло и вы прибыли в ресторан тогда, когда столик пуст, и когда никого в очереди нет, вы можете прямо сразу за него сеть. В противном случае хозяин даст вам специальный пейджер (из бескрайней кучи таких пейджеров!) и вы можете бродить вокруг ресторана до тех пор, пока этот пейджер не подаст сигнал. Дело хозяина ресторана — обеспечить, чтобы посетители попадали бы за столик в порядке их прибытия. Когда настанет ваша очередь, хозяин отправит сигнал на ваш пейджер, а вы вернётесь в ресторан, где сможете усесться за столик.

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

https://habr.com/ru/post/692292/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692292

Базы данных (БД) существуют с первых дней программирования, а появились они ещё раньше. Это — неотъемлемые части любых приложений. Хорошо спроектированная БД — это один из важнейших компонентов, влияющих на производительность программных проектов. Из-за этого множество архитекторов программных решений исследовали массу подходов к управлению данными, пытаясь выяснить то, какие из этих подходов работоспособны в определённых сценариях, а какие — нет. Выбор подходящей архитектуры БД обычно сводится к выбору между SQL и NoSQL, между реляционными и нереляционными базами данных. А иногда в одном проекте используют и то, и другое.

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

https://habr.com/ru/post/691178/?utm_source=habrahabr&utm_medium=rss&utm_campaign=691178

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

Если вы когда-либо попадали в одну из следующих ситуация — тогда эта статья, определённо, написана для вас.

https://habr.com/ru/post/688134/?utm_source=habrahabr&utm_medium=rss&utm_campaign=688134

В Python списковые включения (и генераторы списков) — замечательные механизмы, способные серьёзно упрощать программный код. Правда, чаще всего их используют в форме, предусматривающей наличие единственного цикла for и, возможно, одного условия if. И это всё. Но если попытаться немного вникнуть в эту тему, то окажется, что у списковых включений Python имеется гораздо больше возможностей, чем можно подумать, возможностей, разобравшись с которыми, можно, по меньшей мере, кое-чему научиться.

https://habr.com/ru/post/687520/?utm_source=habrahabr&utm_medium=rss&utm_campaign=687520

Недавно я сделал опрометчивый твит, в котором намекнул на то, что у меня имеется глубоко продуманное мнение по одному важному вопросу. Я написал, что пакет pytest-subtests достоин того, чтобы им пользовалось бы больше программистов. Я даже дошёл до того, что, говоря о подтестах (subtests), сказал, что они были единственным, что мне по-настоящему нравилось в unittest до появления их поддержки в pytest. И, как на грех, Брайан Оккен предложил мне поучаствовать в подкасте Test and Code, чтобы подробнее обсудить подтесты. Я могу лишь догадываться о том, что он это сделал, дабы преподнести мне урок, показать мне, что я не должен, накачавшись продуктами Splenda и травяным чаем, выдавать скороспелые мнения о тестировании кода.Но, тем не менее, когда Брайан взглянет на меня со своей хитрой улыбкой и скажет: «Итак, ты готов поговорить о подтестах?», я планировал ответить: «Да, я готов — сделал обширные заметки и набрал справочных материалов». А когда мы вместе будем стоять на сцене, получая Дневную премию «Эмми» за лучший подкаст о тестировании, я шепну ему: «Я раскрыл твою хитрость, и хотя я тебя обыграл, ты реально показал мне — что такое скромность», а по его щеке скатится одинокая слеза.

Или, что скорее всего так и есть, ему просто хотелось пригласить кого-то, с кем можно поговорить об этом конкретном аспекте Python-тестирования, а я оказался одним из тех немногих, встретившихся ему, кто высказывал по этому поводу своё мнение. В любом случае, этот пост будет играть роль моих заметок по механизму подтестов из unittest, который появился в Python 3.4. Здесь же пойдёт речь о сильных и слабых сторонах подтестов, о сценариях их использования. Этот материал можно считать дополнением к подкасту Test and Code Episode 111.

https://habr.com/ru/post/685890/?utm_source=habrahabr&utm_medium=rss&utm_campaign=685890

Этот материал представляет собой глубокое исследование всего, что связано с Redis. В частности — речь пойдёт о различных способах организации хранилищ Redis, о постоянном хранении данных, о форках процессов.

https://habr.com/ru/post/685894/?utm_source=habrahabr&utm_medium=rss&utm_campaign=685894

Сталкивались ли вы с трудностями при отладке Python-кода? Если это так — то изучение того, как наладить логирование (журналирование, logging) в Python, способно помочь вам упростить задачи, решаемые при отладке.

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

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

Вы, кроме того, узнаете о том, как Sentry Python SDK способен помочь вам в мониторинге приложений и в упрощении рабочих процессов, связанных с отладкой кода. Платформа Sentry обладает нативной интеграцией со встроенным Python-модулем logging, и, кроме того, предоставляет подробную информацию об ошибках приложения и о проблемах с производительностью, которые в нём возникают.

https://habr.com/ru/post/683880/?utm_source=habrahabr&utm_medium=rss&utm_campaign=683880

Pandas — это мощная библиотека для анализа данных, API которой обладает широкими функциональными возможностями. Этот API позволяет решить любую задачу, связанную с обработкой данных, несколькими способами. Некоторые из подходов к решению задач лучше других. Часто бывает так, что пользователи pandas узнают о подходах, не отличающихся особой эффективностью, привыкают к ним и постоянно их применяют. Этот материал посвящён разбору четырёх анти-паттернов pandas и рассказу о приёмах работы, которые стоит использовать вместо них.

Автор черпал вдохновение из многих источников, ссылки на которые даны в статье. В частности — из замечательной книги Effective Pandas.

https://habr.com/ru/post/682388/?utm_source=habrahabr&utm_medium=rss&utm_campaign=682388

Вот вам задача: надо проверить, входит ли число 200 миллионов в диапазон от 0 до 1 миллиарда. Знаю, что на Python её решение выглядит до крайности примитивно — достаточно воспользоваться функцией any и списковым включением:

https://habr.com/ru/post/681426/?utm_source=habrahabr&utm_medium=rss&utm_campaign=681426