Загрузить миллион записей в питон за секунду?
Нет. Получилось еще быстрее!

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

Недавно я проходил очередное интервью, и меня спросили, пишу ли я на flask, на что я ответил, что я себя люблю, и поэтому пишу на django. Меня не взяли, потому что, кхм, у них, оказывается, много чего было на фласке, и вышло неловко. Да-да, я знаю, фласк крут, потому что он простой, всё что надо ставишь сам, а чего не надо там и так нет, но как по мне, всё равно потом получается django.

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

Во время ежегодного спринта разработчиков ядра Python мы встретились с Сэмом Гроссом, автором nogil — fork в Python 3.9, который удаляет GIL. В статье — итоги встречи.

Среди вопросов, на которые ответил Сэм:

— Какова вероятность того, что nogil в итоге окажется нежизнеспособным для включения в CPython?
— Как вы планируете синхронизировать свою работу с main? Есть ли какие-то советы по порядку коммитов?
— Включение nogil во время запуска — это долгосрочная опция, или только на переходное время?
— В финале предполагается исключительно nogil, без вариантов вернуть GIL обратно?
— Что вы думаете о параллельном запуске нескольких интерпретаторов Python с одним GIL для каждого?

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

Если опустить первое и самое главное предубеждение относительно питонячьей многопоточности у большинства программистов — что её не существует из-за GIL, — то остается другое, и, наверное, вполне достоверное: что многопоточность — это сложно, и нам этого, пожалуйста, не надо. И знаете что? Так оно и есть. Многопоточность — это сложно, особенно когда выбираешься за пределы стандартных руководств и попадаешь со своей многопоточной поделкой в реальный мир. И, возможно, вам не нужно. Ни здесь, ни далее я не буду обсуждать целесообразность написания многопоточного кода на Python и сразу перейду к тому, как это делать.

Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.

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

Легко ли разработать новый API? На что обратить внимание, чтобы не ошибиться при реализации, и к каким компромиссам стоит быть готовым?

Привет, Хабр! Меня зовут Иван Ивашковский. Я руковожу группой разработки международных проектов в Яндекс Go. Этот пост — продолжение цикла историй о вымышленном стажёре Васе. Предыдущий материал, про идемпотентность, можно почитать здесь. В посте я расскажу, как Вася разрабатывал API для новой фичи и с какими проблемами он столкнулся в процессе. В конце приведу чеклист с советами, как проверить себя на каждом этапе разработки, если вы решаете похожую задачу.

Django - отличный фреймворк, но он, на самом деле, толком не дает, да и не должен давать, ответ на вопрос, каким образом лучше всего хранить вашу бизнес-логику. Хранение бизнес-логики в моделях или views имеет множество недостатков, которые обычно начинают проявляться при росте кодовой базы проекта. Чтобы решить эти проблемы, разработчики часто начинают искать способы выделения бизнес-логики в своем приложении.

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

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

На самом деле, изложенный далее текст относится не только к Django-проектам. Разрабатывая веб-приложения, используя другие инструменты, вроде Flask, люди используют те же концепции веб-разработки, причём часто именно в таком же виде, как они реализованы, в Django - views, request-response объекты, middlewares, модели, формы.

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

В этом руководстве продемонстрирован способ тестирования интеграции с внешним API при помощи мок-объектов на Python.

Интеграция со сторонним приложением — это отличный способ расширить функционал продукта.

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

В этом руководстве предполагается, что у вас есть опыт работы с FastAPI и Postgres с помощью Docker. Вам нужна помощь, чтобы ускорить работу с FastAPI, Postgres и Docker?

Привет!

В прошлой статье мы познакомились с aiohttp и написали на нем свое первое веб-приложение: стену с отзывами.

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

Если вам интересно асинхронное программирование, приходите к нам на курс в KTS, где мы гораздо подробнее разберем эту тему.

Привет, меня зовут Артём. Я работаю бэкендером в KTS и веду курсы по разработке в KTS Metaclass. Заметил, что труднее всего студентам даются темы по асинхронному программированию.

Основываясь на своём преподавательском опыте, я написал туториал, рассказывающий о создании базового aiohttp-сервиса с нуля и затрагивающий самые сложные для студентов вопросы: как сделать асинхронное python-приложение, как работать с базой данных и как разложить свой проект в интернете.

Это первая статья цикла, в ней мы напишем небольшое веб-приложение на aiohttp  — стену с отзывами, где каждый может оставить свое мнение о каком-то продукте.

В последний год (примерно) появилось много постов, как сделать таблички в Google Sheets/MS Excel для отображения актуальной информации о своем инвестиционном портфеле и т.п. Действительно хочется видеть, что там творится. Особенно актуально для продвинутых подписок/тарифных планов, когда требуется определенная сумма на счетах, и будет обидно, если из-за падения акций или курса доллара сумма снизится ниже пороговой…

Я попробовал несколько вариантов от электронных таблиц до записи в MySQL скриптом на python, и на текущий момент остановился на отображении моих инвестиционных счетов в Grafana.

Кому интересны плюсы/минусы разных вариантов, с какими нюансами я столкнулся – добро пожаловать под кат.

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

11 Советов самому себе в джуновское прошлое

В моей практике не раз были ситуации, когда хотелось посмотреть, какие именно запросы долго тупили в базе в определённый (конкретный) момент времени. А может, запросы не тупили, но каких-то запросов было слишком много.

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

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

На удивление, сделать такой мониторинг самому занимает всего полчаса времени, буквально с помощью нескольких строк Go-кода и палок.

Привет, Хабр! Меня зовут Владимир, я работаю программистом в компании Quadcode. Вот уже почти полтора десятилетия я при помощи доброго десятка языков программирования разрабатываю приложения - от простых, вроде маленького плагина для Emacs, до сложных распределенных систем. Последние 4 года своей жизни я посвятил компании Quadcode, где занимаюсь разработкой транспортной подсистемы. Лет пять назад я вплотную столкнулся с адептами TDD (test-driven development) и это произвело на меня настолько сильное впечатление и оставило так много эмоций, что я написал “для своих” критический разбор наиболее часто встречаемых мною тезисов об этой технике (я бы даже сказал - учении). До сих пор мое мнение о TDD не изменилось, так что хотел бы описать его под катом и предлагаю обсудить вместе спорные моменты в комментариях.