Собрали в одном месте самые важные ссылкичитайте авторский блог
На производстве важно следить за качеством продукции, причем как приходящей от поставщиков, так и той, что мы выдаем на выходе. Для этого у нас часто проводятся пробоотборы — специально обученные сотрудники берут пробоотборники и по имеющейся инструкции собирают пробы, которые затем передают в лабораторию, где их и проверяют на качество.
QlikView и его младший брат QlikSense — замечательные BI инструменты, достаточно популярные у нас в стране и "за рубежом". Очень часто эти системы сохраняют "промежуточные" результаты своей работы — данные, которые визуализируют их "дашборды" — в так называемые "QVD файлы". Часто QVD файлы используются в качестве основного хранилища в многоэтапных ETL процессах, построенных на базе Qlik. И тогда у некоторых (у меня, например, — я занимаюсь в компании вопросами инженерии данных) возникает вопрос — можно ли и как воспользоваться этими данными без QlikView/QlikSense? Или другой — а что там и правильно ли "оно" посчиталось?
Сегодня мы обсудим, зачем кому-то понадобилось писать замену стандартному питонячему логеру logging и как этой штукой пользоваться.
Так уж сложилось, что на Python пишут много веб-приложений. Эту нишу Python разработки почти полностью поделили между собой два здоровых игрока — Django и Flask. Поэтому большой процент программистов, пишущих на Python, заточен на работу с этими двумя фреймворками.
По этой причине у многих Python-разрабов складывается некое подобие тунельного зрения — их инженерный подход заперт между этими двумя библиотеками.
Если вы когда-нибудь работали с такими низкоуровневыми языками, как С или С++, то наверняка слышали про указатели. Они позволяют сильно повышать эффективность разных кусков кода. Но также они могут запутывать новичков — и даже опытных разработчиков — и приводить к багам управления памятью. А есть ли указатели в Python, можно их как-то эмулировать?
Как сделать решатель (солвер) нонограмм на Python, переписать его на Rust, чтобы запускать прямо в браузере через WebAssembly.
На Boosters.pro в течении двух месяцев с 18 февраля по 18 апреля проходило соревнование по построению рекомендательной системы на реальных данных одного из крупнейших российских онлайн-кинотеатров Okko. Организаторы преследовали цель улучшить существующую рекомендательную систему. На данный момент соревнование доступно в режиме песочницы, в которой вы можете проверить свои подходы и отточить навыки в построении рекомендательных систем.
Это одиннадцатая подборка советов про Python и программирование из авторского канала @pythonetc
Словари являются одной из наиболее важных и полезных структур данных в Python. Они могут помочь вам решить широкий спектр задач программирования. Из этой статьи вы узнаете, как итерировать словарь в Python.
Знакома ли вам ситуация, когда на выбор фильма вы тратите гигантское количество времени, сопоставимое со временем самого просмотра? Для пользователей онлайн-кинотеатров это частая проблема, а для самих кинотеатров — упущенная прибыль.
К счастью, у нас есть Rekko — система персональных рекомендаций, которая уже год успешно помогает пользователям Okko выбирать фильмы и сериалы из более чем десяти тысяч единиц контента. В статье я расскажу вам как она устроена с алгоритмической и технической точек зрения, как мы подходим к её разработке и как оцениваем результаты. Ну и про сами результаты годового A/B теста тоже расскажу.
Для начала немного истории. Okko начал своё существование в 2011 году как часть Йоты, запустившись под именем Yota Play.
Если вы когда-нибудь работали с такими низкоуровневыми языками, как С или С++, то наверняка слышали про указатели. Они позволяют сильно повышать эффективность разных кусков кода. Но также они могут запутывать новичков — и даже опытных разработчиков — и приводить к багам управления памятью. А есть ли указатели в Python, можно их как-то эмулировать? Указатели широко применяются в С и С++. По сути, это переменные, которые содержат адреса памяти, по которым находятся другие переменные. Чтобы освежить знания об указателях, почитайте этот обзор.
Как развивалось пакетирование в Python, что в нём на текущий момент оставляет желать лучшего, какие системы для управления зависимостями актуальны и в какую сторону они развиваются?
С одной стороны, предмет действительно был квадратным. C другой стороны он был круглым. Но с третьей стороны, с которой должен быть треугольник, предмет вышел кривой и косой.
— Алешенька идет на совещанку? — в дверь просунулась Леночкина заинтересованная физиономия. — Алешенька на совещанку не идет. Алешенька пишет статью. — О кубиках? — Каких еще кубиках? — я опустил глаза, в руках и правда был злосчастный кубик. То есть шарик. То есть ромбик. — Не о кубиках! И не о шариках. О шаблонах. — Я им так и скажу! Шаблон, ах. — Леночка уже бежала дальше по коридору.
"О шаблонах. Даже о трех разных шаблонах". Точнее, о трех причинах использовать шаблоны в серверном коде. И ни одна из этих причин не будет про HTML.
Недавно мне попалась классическая задачка для собеседований: поиск максимального числа точек, стоящих на прямой линии (на плоскости, координаты целочисленные). В голову сразу пришла идея полного перебора, которая имеет очевидную сложность по времени в O(n^2), но мне показалось, что здесь обязано быть что-то ещё, хоть какая-то альтернатива в O(n*log(n)). Через полчаса нашлось даже нечто лучшее!
Богатая литература по археоакустике и звуковым ландшафтам помогает воссоздать звук места, каким он был (например, см. Виртуальный Собор Святого Павла или работу Джеффа Вейча по древней Остии). Но мне интересно «озвучить» сами данные. Я хочу определить синтаксис для представления данных в виде звука, чтобы эти алгоритмы можно было использовать в исторической науке. Друкер сказал знаменитую фразу, что «данные» — это на самом деле не то, что дано, а скорее то, что захвачено, трансформировано, то есть 'capta'. При озвучивании данных я буквально воспроизвожу прошлое в настоящем. Поэтому на передний план выходят допущения и преобразования этих данных. Полученные звуки являются «деформированным исполнением», которое заставляет по-новому услышать современные пласты истории.
Около полугода наша команда работает над Predictive Maintenance Platform — системой, которая должна предсказывать возможные ошибки и поломки оборудования. Это направление стоит на стыке IoT и Machine Learning, работать здесь приходится и с железом и, собственно, с программным обеспечением. О том, как мы строим Serverless ML с библиотекой Scikit-learn на AWS, и пойдет речь в этой статье. Я расскажу о сложностях, с которыми мы столкнулись, и об инструментах, используя которые, сэкономили время.