Собрали в одном месте самые важные ссылки
и сделали Тренажер IT-инцидентов для DevOps/SRE
В этой статье мы хотим поговорить про конкретный кейс разработки процесса AutoML для моделей оценки вероятности дефолта клиентов (PD) в рамках экспресс-продуктов малого бизнеса. Расскажем, как выстроен наш процесс, как мы к этому пришли, с какими проблемами столкнулись, как их решили и как в дальнейшем планируем тиражировать на другие продукты банка.
Уже много лет, начиная с 1966 года, во всем мире 20 июля отмечают Международный день шахмат. В честь недавно прошедшего праздника мы решили написать статью, в которой поговорим о шахматных задачах из курсов "Поколение Python".Так получилось, что шахматные задачи являются одной из главных визиток наших курсов. Мы любим эти задачи потому, что они учат строить алгоритмы, находить закономерности, а также позволяют отточить работу с условными (if-else) и логическими (and и or) операторами.
В этой статье я хочу поделиться своими рассуждениями и описанием процесса разработки модели прогнозирования. Возможно, кому-то из вас данная информация может быть полезна.
В данной статье представляю свое видение процесса автоматического формирования проверок на коллизии в Navisworks для проекта с большим количеством моделей. Метод основан на работе с xml файлами с помощью Python. Также предлагается шаблон Power BI для визуализации отчета по полученным проверкам.
Сегодня я расскажу вам о моей системе оценивания, которая создана для проведения экзаменов и оценки знаний студентов. Система построена на Django Rest Framework (DRF) для бэкенда и React с MaterialUI для фронтенда. Я добавил множество полезных функций, включая интеграцию с ISPmanager, которые делают систему удобной и эффективной.
В итоге получился экспериментальный проект «ХрюХрюКар» — сервис для борьбы с неправильной парковкой, работающий под лозунгом «Хорошие ребята говорят 'Bla-Bla' и не ставят машину на зелёной зоне».
В этой статье мы расскажем, как выбирали проект, на решение каких задач нацелен «ХрюХрюКар», какие технологии мы использовали, какие трудности возникали и что получилось в итоге.
В первой части рассмотрим паттерны проектирования Repository и Unit of Work. С их помощью мы работаем через интерфейсы. Паттерны помогают в разделении кода на слои: основная логика приложения представляется внутренними слоями, а используемые технологии - внешними.
Сегодня я решил создать чисто практическую статью, в которой мы с нуля и максимально быстро разработаем полноценный веб-сервис с фронтендом и бэкендом. После этого мы выполним деплой этого приложения, чтобы любой пользователь мог им воспользоваться.
Учебный процесс меня вдохновлял, и казалось, что впереди меня ожидает очередь из работодателей, стремящихся нанять востребованного специалиста. Но, как оказалось, никто не спешит брать на работу junior-специалистов
Я объединил все эти фичи в реальный проект с открытым исходным кодом, чтобы у вас сложилась целостная картина. Мы с вами создадим UX/UI на Figma, напишем фронтенд на HTML, CSS, SASS, Bootstrap и JavaScript, создадим ER-диаграмму в MySQL Workbench, напишем бекэнд на Flask, создадим регистрацию через социальные сети OAuth 2.0 в один клик, используем брокер сообщений и асинхронную очередь Celery для отправки писем на электронную почту, сделаем WYSIWYG-редактор, реализуем полнотекстовый поиск Elasticsearch, закешируем Redis, покроем тестами pytest и запустим в Docker-контейнерах, поговорим о многопроцессности для WSGI-шлюза Gunicorn.
Сразу оговорюсь, что в статье речь пойдёт преимущественно о теоретической стороне проектирования батарей, нежели о практических рекомендациях по исправлению их технических проблем — жаль разочаровывать тех, кого больше интересует последнее.
Эта статья рассчитана на людей, которые уже знакомы с Python, хотя бы на уровне junior+. Я объясню, какие есть отличия и особенности в многопоточности, асинхронности и мультипроцессорности в Python, где и когда они используются. Как говорится в пословице: «Всё познаётся в сравнении», именно в таком стиле я подготовил примеры. Кроме этого, буду специально делать ошибки и рассматривать неправильные подходы, чтобы можно было сразу разобраться, убедиться и запомнить, почему так делать нельзя и какой другой подход в этом случае нужно использовать.
В двух предыдущих статьях здесь и тут мы рассказывали историю создания одного из компонентов платформы экспериментов в компании. В тех статьях говорилось о множестве изменений и улучшений, которые претерпел Python-код, чтобы работать достаточно быстро. Но как бы качественно не был написан код, все усилия могут сойти на нет, если он будет запущен в неправильной среде. В этой статье продолжим рассказ об оптимизациях и улучшениях, но в этот раз речь будет идти не столько об особенностях предметной области и решаемой бизнес-задачи, сколько о том, как мы архитектурно организовали работу сервиса для получения минимального времени ответа.
А теперь о том, что происходило в последнее время на других ресурсах.
Хочу поделиться примером‑инструкцией как получить инсайты из геоданных без регистрации, смс (только open‑source и бесплатные инструменты: OSM, python, Портал открытых данных Правительства Москвы, DataLens). Как сделать так, чтобы дашборд не "умер" от количества точек и тяжелых полигонов, работал сравнительно быстро и давал пользователю представление общей картины.
MLflow - это инструмент для управления жизненным циклом машинного обучения: отслеживание экспериментов, управление и деплой моделей и проектов. В этом руководстве мы посмотрим, как организовать эксперименты и запуски, оптимизировать гиперпараметры с помощью optuna, сравнивать модели и выбирать лучшие параметры. Также рассмотрим логирование моделей, использование их в разных форматах, упаковку проекта в MLproject и установку удаленного Tracking Server MLflow.
В Python 3.8 появился моржовый оператор (:=), который стал причиной бурных споров в сообществе. О нем и пойдет речь в этой статье. А начнем мы с истории о том, как моржовый оператор довел Гвидо ван Россума, создателя Python, до ухода с должности "великодушного пожизненного диктатора" проекта по разработке языка.
В этой статье я рассмотрю практику использования библиотек разработчиками на разных языках программирования для упрощения интеграции с API.