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

Наверное вы уже догадались, что речь сегодня пойдет о сверточных операторах на графах.

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

На связи команда Datalore by JetBrains. Хотим поделиться с вами результатами анализа нескольких миллионов публично доступных репозиториев Github с Jupyter-ноутбуками. Мы скачали ноутбуки, чтобы немного больше узнать в цифрах о текущем статусе, пожалуй, самого популярного инструмента для data science.

Я имею самый обычный рабочий график: 5/2, 8ч/день. В настоящий момент удаленно учусь в аспирантуре (коронавирус, все дела) и единственный день, когда я могу вдоволь почувствовать себя человеком-соседом и поделать что-то по дому, – это суббота. Как вы понимаете, здесь что-то пошло не так и вместо обещанных будничных пар, которые должны были проходить по вечерам после работы, нам утрамбовали всю субботу. Но дела ведь себя не переделают, поэтому решено было написать на python простого бота-кликера, который мог бы заходить на пару, стартовать запись экрана со звуком, ожидать окончания пары, выключать записть и выходить с пары.

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

Какой бы подход вы ни выбрали, я думаю, можно с уверенностью сказать, что тесты должны оставаться ясными, краткими, читаемыми и, конечно же, их должно быть просто поддерживать. Лично у меня не возникает проблем с несколькими assert-ами в одном тесте, поскольку я фокусируюсь на одной функциональной области.

Например, возьмем форму регистрации:

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

Задача, которая здесь описана может быть хорошим упражнением для начинающих аналитиков. Тут будет всё: и python c pandas и парсинг HTML и регулярные выражегия и базы данных c SQL.

При долгой работе с большим проектом так или иначе упираешься в поиск узких мест в коде. Что только не используют для этого — от навороченных профайлеров и брейкпоинтов до выводов print и замеров времени вручную с выводом таймстампов на консоль.

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

Привет Хабр! По основной профессии я инженер по разработке нефтяных и газовых месторождений. Я только погружаюсь в Data Sciense и это мой первый пост, в котором хотел бы поделиться опытом применения машинного обучения в нефтяной сфере.

Только что вышло очередное обновление EAP 12 для плагина под названием Big Data Tools, доступного для установки в IntelliJ IDEA Ultimate, PyCharm Professional и DataGrip. Можно установить его через страницу плагина или внутри IDE. Плагин позволяет работать с Zeppelin, загружать файлы в облачные хранилища и проводить мониторинг кластеров Hadoop и Spark.

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

Предыстория

Предыдущая статья

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

В Sitri данная проблема решается достаточно просто — с помощью локального режима для ваших классов настроек, то есть вам не придётся даже переписывать ничего или дублировать код, да и структура json файла для локального режима будет почти полностью повторять структуру секретов.

Итак, ну а теперь, давайте добавим в наш проектик буквально пару строк кода + я покажу, как со всем этим можно работать, если ваш проект локально запускается в docker-compose.

Всем привет! 

Скажу сразу, эта статья не про очередное переписывание монолита на микросервисы, а о применении микросервисных практик в рамках существующего проекта с использованием интересных, как мне кажется, подходов. Наверное, уже нет смысла объяснять, почему многие проекты активно используют микросервисную архитектуру. Сегодня в IT возможности таких инструментов как Docker, Kubernetes, Service Mesh и прочих сильно меняют наше представление об архитектуре современного приложения, вынуждая пересматривать подходы и переписывать целые проекты на микросервисы. Но так ли это необходимо для всех частей проекта? 

Привет, меня зовут Александр, я тимлид команды разработки трекинговых решений компании Admitad.

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

Это мой первый пост, где я хочу рассказать про самый известный клеточный автомат "Игра жизнь", а также напишем её на Python с использованием графики Pygame.

Conways Game of life ( по русски 'Игра жизнь' ) - клеточный автомат, придуманный Джоном Конвеем в далеком 1970 году.

Правила очень просты, вся игра происходит в 2D пространстве (плоскости) на которой могут быть 2 типа клеток "Живые" - 0 и "Пустые" -1. Основные правила жизни клетки таковы Birth3 Survive23, что значит клетка рождается при трёх соседях и выживает при двух или трёх, иначе умирает.

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

Пример смотрите по ссылке https://www.emarkoff.com/dividend_aristocrats_sp500/

Многие говорят, что делать вирусы на пайтоне, по крайней мере глупо. Но автор научит вас создавать на пайтоне простейший винлокер, с помощью которого вы сможете разыграть своего друга.