Однажды я наткнулся на книгу под названием «Создай свою нейросеть», под авторством Тарика Рашида. В отличие от многих других книг по нейронным сетям, в этой все подавалось простым языком, c достаточным количеством примеров и советов

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

Всем привет!

Кратко о себе. По образованию я математик, а вот по профессии — программист. В сфере разработки с 2006 года. Хотя, поскольку программирование начали изучать ещё в школе, свои первые программки и игры я начал писать ещё в школе (примерно, с 2003). Так сложилось, что пришлось выучить и поработать на нескольких языках. Если не брать во внимание ВУЗ-овские лекции по С, С++, Бэйсику, Паскалю и Фортрану, то реально я работал с Delphi (более 6 лет), PHP (более 5 лет), Embedded (Atmel + PIC около 2.5 лет) и последним временем Python + чуть-чуть Scala. Конечно же без баз данных тоже никак не обойтись.

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

Прим. перев.: Неделю назад Aymen El Amri, руководящий компанией eralabs и создавший обучающий курс «Безболезненный Docker», опубликовал свой Docker Cheat Sheet — шпаргалку по основным командам Docker. Git-репозиторий этого документа на GitHub уже набрал 1000+ stars и несколько сторонних контрибьюторов, что подтвердило его актуальность и пользу.



Представленные здесь команды описаны минимально (с акцентом на читаемость как есть) и включают в себя установку Docker, работу с реестрами и репозиториями, контейнерами, образами, сетью, Docker Swarm. Ниже представлен перевод шпаргалки в её состоянии на 2 сентября с дополнениями из комментариев ниже.

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

В процессе работы мы установим агенты cAdvisor на каждой ноде для сбора метрик хоста и контейнеров. Метрики будут сохраняться в InfluxDB. Для построения графиков на основе этих метрик воспользуемся Grafana. Эти инструменты распространяются с открытым исходным кодом и могут быть развернуты в виде контейнеров.

Для построения кластера мы будем использовать Docker Swarm Mode и развернем необходимые сервисы в виде стека. Это позволит организовать динамическую систему мониторинга, которая способна автоматически начинать мониторинг новых нод по мере их добавления в рой (swarm). Файлы проекта можно найти здесь.

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

От переводчика: публикуем для вас статью Даррена Барнса, который делится своим опытом работы с GitHub. Его советы будут полезны, в первую очередь, новичкам. Возможно, и опытный кодер найдет что-то для себя.

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

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

Так повелось, что в процессе работы в МегаФоне, приходится сталкиваться с однотипными задачами при работе с RabbitMQ. Закономерно возникает вопрос: «Как упростить и автоматизировать выполнение таких задач?»

Первое решение, которое приходит в голову, использовать интерфейс HTTP, и, безусловно, из коробки RabbitMQ обладает хорошим веб-интерфейсом и HTTP API. Тем не менее, использование HTTP API не всегда удобно, а иногда и вообще невозможно (допустим у вас недостаточно прав доступа, а опубликовать сообщение ну очень хочется) в такие моменты возникает необходимость работы именно по протоколу AMQP

Не найдя подходящих мне готовых решений на просторах сети, было решено написать небольшое приложение для работы с RabbitMQ по протоколу AMQP

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

Предполагается, что студент должен страдать самостоятельно освоить ноты, путем многократного повторения. И вообще, если «ниасилил», значит у тебя нет Таланта — иди мести двор.

Представьте что было бы, если бы обычной грамоте учили так же. Но мы, почему-то, в большинстве своем читать и писать таки научились.

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

Если вы интересуетесь искусственным интеллектом и прочим распознаванием, то наверняка уже видели эту картинку:


А если не видели, то это результаты Хинтона и Крижевского по классификации ImageNet-2010 глубокой сверточной сетью

Давайте взглянем на ее правый угол, где алгоритм опознал леопарда с достаточной уверенностью, разместив с большим отрывом на втором и третьем месте ягуара и гепарда.

Это вообще довольно любопытный результат, если задуматься. Потому что… скажем, вы знаете, как отличить одного большого пятнистого котика от другого большого пятнистого котика? Я, например, нет. Наверняка есть какие-то зоологические, достаточно тонкие различия, типа общей стройности/массивности и пропорций тела, но мы же все-таки говорим о компьютерном алгоритме, которые до сих пор допускают какие-то вот такие достаточно глупые с человеческой точки зрения ошибки. Как он это делает, черт возьми? Может, тут что-то связанное с контекстом и фоном (леопарда вероятнее обнаружить на дереве или в кустах, а гепарда в саванне)? В общем, когда я впервые задумался над конкретно этим результатом, мне показалось, что это очень круто и мощно, разумные машины где-то за углом и поджидают нас, да здравствует deep learning и все такое.

Так вот, на самом деле все совершенно не так.

Здравствуй, Хабр!

Осталось несколько дней до дня программиста и, конечно, в эту 13-ю пятницу, многие из пользователей хабра буду отмечать этот праздник. Буду отмечать и я.

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

Все началось вот с чего: моя супруга увлекается кулинарией и ведет небольшой кулинарный блог. В прошлом году на мой день рождения она пригласила к нам в гости на кухню настоящего бармена из барного startup-проекта БАРаДОМа.нет. С момента знакомства с Артёмом (барменом который превратил мой день рождения в домашнюю барную вечеринку), у меня появилась идея: найти рецепты (или придумать самим) коктейлей, которые бы вписались в IT-тематику.

Итогом нескольких дней активной переписки с Артёмом стала вот такая небольшая коктейльная карта:

• Ruby
• Python
• Суровый Perl
• JMP (aka Assembler)
• Profit!
• Epic fail
• Memory leak

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

Предисловие

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

За время работы в этой области у меня накопился некоторый опыт использования различных вычислительных технологий. На некоторые вопросы, которые могут быть интересны не только мне, я постараюсь отвечать в рамках этой публикации.

Продолжаем публикацию наиболее интересных глав из книги Magnus Lie Hetland «Python Algorithms». Предыдущая статья расположена по адресу habrahabr.ru/blogs/algorithm/111858. Сегодня же речь пойдет об эффективной работе с графами и деревьями и особенностях их реализации в Python. Базовая терминология теории графов уже обсуждалась (например здесь: habrahabr.ru/blogs/algorithm/65367), так что я не включил часть главы о терминах в эту статью.

Реализация графов и деревьев

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

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

Менеджер памяти

В отличие от других популярных языков, Python не освобождает всю память обратно операционной системе как только он удаляет какой либо объект. Вместо этого, он использует дополнительный менеджер памяти, предназначенный для маленьких объектов (размер которых меньше чем 512 байт). Для работы с такими объектами он выделяет большие блоки памяти, в которых в дальнейшем будет хранится множество маленьких объектов.

Как только один из маленьких объект удаляется — память из под него не переходит операционной системе, Python оставляет её для новых объектов с таким же размером. Если в одном из выделенных блоков памяти не осталось объектов, то Python может высвободить его операционной системе. Как правило, высвобождение блоков случается когда скрипт создает множество временных объектов.

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

Этим постом начинается разбор задачек по алгоритмам, которые крупные IT-компании (Mail.Ru Group, Google и т.п.) так любят давать кандидатам на собеседованиях (если плохо пройти собеседование по алгоритмам, то шансы устроиться на работу в компанию мечты, увы, стремятся к нулю). В первую очередь этот пост полезен для тех, кто не имеет опыта олимпиадного программирования или тяжеловесных курсов по типу ШАДа или ЛКШ, в которых тематика алгоритмов разобрана достаточно серьезно, или же для тех, кто хочет освежить свои знания в какой-то определенной области.

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

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

Введение

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

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

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

Не так давно мне предложили вести курс основ теории алгоритмов в одном московском лицее. Я, конечно, с удовольствием согласился. В понедельник была первая лекция на которой я постарался объяснить ребятам методы оценки сложности алгоритмов. Я думаю, что некоторым читателям Хабра эта информация тоже может оказаться полезной, или по крайней мере интересной.

Предлагаю обсудить такую интересную, но мало используемую возможность python, как сопрограммы (coroutines).
Сопрограммы в питоне основаны на генераторах (ими, они, собственно и являются).
Поэтому, предлагаю начать именно с генераторов, в общем понимании. А потом разберём как написать свою сопрограмму.

И снова доброго времени суток всем читателям!
Спасибо, за проявленый интерес к первой части перевода, надеюсь, вторая вас так же не разочарует.

Итак, в первой части данной статьи мы совершили базовое знакомство с декораторами, принципами их работы и даже написали свой вручную.
Однако, все декораторы, которые мы до этого рассматривали не имели одного очень важного функционала — передачи аргументов декорируемой функции.
Что ж, исправим это недоразумение!

На Хабре множество раз обсуждалась тема декораторов, однако, на мой взгляд, данная статья (выросшая из одного вопроса на stackoverflow) описывает данную тему наиболее понятно и, что немаловажно, является «пошаговым руководством» по использованию декораторов, позволяющим новичку овладеть этой техникой сразу на достойном уровне.

Итак, что же такое «декоратор»?

Впереди достаточно длинная статья, так что, если кто-то спешит — вот пример того, как работают декораторы:

def makebold(fn):
    def wrapped():
        return "<b>" + fn() + "</b>"
    return wrapped
 
def makeitalic(fn):
    def wrapped():
        return "<i>" + fn() + "</i>"
    return wrapped
 
@makebold
@makeitalic
def hello():
    return "hello habr"
 
print hello() ## выведет <b><i>hello habr</i></b>

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

Upd 1: изменил несколько категоричное утверждение о несходстве паттерна Декоратор и одноимённой языковой конструкции на более мягкое.