Недавно ZlodeiBaal опубликовал статью «Нейрореволюция в головах и сёлах», в которой привел обзор возможностей современных нейронных сетей. Самым интересным, на мой взгляд, является подход с использованием сверточных сетей для сегментации изображений, про этот подход и пойдет речь в статье.



Уже давно появилось желание изучить сверточные сети и узнать что-то новое, к тому же под рукой есть несколько последних Tesla K40 с 12Гб памяти, Tesla c2050, обычные видеокарты, Jetson TK1 и ноутбук с мобильной GT525M, интереснее всего конечно попробовать на TK1, так как его можно использовать практически везде, хоть на столб фонарный повесить. Самое первое с чего начал, это распознавание цифр, тут конечно удивить нечем, цифры уже давно неплохо распознаются сетями, но при этом постоянно возникает потребность в новых приложениях, которые должны что-то распознавать: номера домов, номера автомобилей, номера вагонов и т.д. Все бы хорошо, но задача распознавания цифр является лишь частью более общих задач.

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Цикл for в R может быть очень медленным, если он применяется в чистом виде, без оптимизации, особенно когда приходится иметь дело с большими наборами данных. Есть ряд способов сделать ваш код быстрее, и вы, вероятно, будете удивлены, узнав насколько.

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

Давайте попробуем ускорить код с циклом for и условным оператором (if-else) для создания колонки, которая добавляется к набору данных (data frame, df). Код ниже создает этот начальный набор данных.

# Создание набора данных
col1 <- runif (12^5, 0, 2)
col2 <- rnorm (12^5, 0, 2)
col3 <- rpois (12^5, 3)
col4 <- rchisq (12^5, 2)
df <- data.frame (col1, col2, col3, col4)

В этой части: векторизация, только истинные условия, ifelse.
В следующей части: which, apply, побайтовая компиляция, Rcpp, data.table.

Перевод статьи Vitalij Mik Clean Code Architecture and Test Driven Development in PHP

Понятие «архитектура чистого кода» (Clean Code Architecture) ввел Роберт Мартин в блоге 8light. Смысл понятия в том, чтобы создавать архитектуру, которая не зависела бы от внешнего воздействия. Ваша бизнес-логика не должна быть объединена с фреймворком, базой данных или самим вебом. Подобная независимость даёт ряд преимуществ. К примеру, при разработке вы сможете откладывать какие-то технические решения, например выбор фреймворка, движка/поставщика БД. Также вы сможете легко переключаться между разными реализациями и сравнивать их. Но самое важное преимущество такого подхода — ваши тесты будут выполняться быстрее.

Просто подумайте об этом. Вы действительно хотите пройти роутинг, подгрузить абстрактный уровень базы данных или какое-нибудь ORM-колдовство? Или просто выполнить какой-то код, чтобы проверить (assert) те или иные результаты?

Введение

Добрый день.
Не нашел простого и внятного описания данного алгоритма на русском языке. Решил восполнить сей пробел. Прежде всего что это такое? LR(0)-анализатор в первую очередь это синтаксический анализатор. Цель синтаксического анализатора обработать входной поток лексем(базовые элементы языка, которые производит лексический анализатор на основе входного потока символов, примеры лексем — число, запятая, символ) и сопоставить его с описанием языка заданного в определенном формате. Сопоставление заключается в построении определенной структуры данных, чаще всего — дерева. Дальше эта структура пойдет на следующий этап — семантический анализ, где уже компилятор пытается понять смысл, заключенный в дереве.

Существует 2 класса синтаксических анализаторов — восходящие анализаторы и нисходящие. Первые строят дерево начиная с листьев, которые являются входными лексемами, вторые соответственно наоборот начинают с корня дерева. Собственно LR и значит то, что анализатор будет читать поток слева направо (L — 'Left') и строить дерево снизу вверх (пусть не смущает буква R, которая значит Right, объяснения даны чуть ниже). Индекс 0 обозначает то что мы не предпросматриваем следующие лексемы, а работаем только с текущей. Какие же плюсы даёт нам выбор этого типа анализаторов?

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

Есть и недостатки:

• Относительная сложность построения.
• Можно вогнать анализатор в ступор неоднозначностью описания языка.

Введение

Добрый день.
Продолжаю писать о около-компиляторных темах. В этот раз затрону вопрос о проектировании и создании интерпретатора, который работает с синтаксическими деревьями.
Рекомендую ознакомиться с предыдущей статьёй — «Пишем LR(0)-анализатор. Простыми словами о сложном», потому что в интерпретаторе я не строю синтаксический анализатор с нуля, а использую наработки, описанные в той статье. Ах да, еще один немаловажный момент — писать будем на JavaScript. Я не поклонник этого языка, но считаю что это наиболее удобный для общественности способ посмотреть результат. Не каждый рискнёт качать неизвестно что, да и это всё же сложнее чем просто открыть страничку. Нетипичность инструмента компенсируется «учебностью» примера. Скорость работы не важна (100-150 строк лимит, мне кажется больше никто не захочет набирать того чтобы поиграться с интерпретатором), а понятность кода у JS достаточно велика.

Введение, или зачем нужны синтаксические анализаторы

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

Эта часть посвящена базису, общей теории computer science. Возможно, что это даже преподаётся в школах/вузах России. Самая мякота пойдет со второй части.

Итак, зачем же кому-то может понадобиться писать парсер и что вообще это такое? Парсер — это код, который наделяет входящий набор символов семантическим смыслом. То есть, происходит анализ этих символов, и на основе этого анализа программа понимает как интерпретировать эти буквы и цифры. Простой пример — «1+2», после или во время процесса парсинга знак "+" это не просто символ плюса, но обозначение бинарноого оператора сложения, а в "+3" это унарный оператор знака числа. Большинству людей это очевидно, машине — нет.

Парсеры используются всюду — в Word'e для анализа приложений, словоформ, формул, etc; практически на любом сайте при валидации входных данных: email'а, телефонного номера, номера кредитки; конфигурационные файлы; сериализованные данные (например, в xml); во многих играх — скриптовые ролики, скрипты ИИ, консоль. В общем, это неотъемлемая часть computer science.

Введение

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

Дабы задать контекст, сообщу, что грамматика для анализа — это ECMAScript, так же известный как JavaScript. Конкретная спецификация — ECMA-262, редакция 5.1 от июня 2011 года.

Предисловие

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

В комментариях к прошлой статье несколько человек интересовались моими мотивами в написании своего компилятора компиляторов. К сожалению, они в этой статье не найдут ответов на этот вопрос. Не скрою, изначально я планировал написать статью без особой теории, но с оправданием задач и целей, ради которых я начал писать генератор, да и хотел поделиться нюансами и особенностями реализации. То есть по объему это довольно прилично: несколько экранов. Но затем я решил всё же описать базовую теорию популистским языком, поэтому статья разрослась до трех частей. Таким образом, дабы не ломать логику изложения, я сначала расскажу про LR/SLR/LALR-анализаторы, а завтра опубликую заключительную, и, думаю, самую интересную часть.

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


Один криптографический раунд

Многие студенты, впервые сталкиваясь с описанием какой-нибудь хитроумной штуки, вроде алгоритма Кнута – Морриса – Пратта или красно-чёрных деревьев, тут же задаются вопросами: «К чему такие сложности? И это, кроме авторов учебников, кому-нибудь нужно?». Лучший способ доказать пользу алгоритмов – это примеры из жизни. Причём, в идеале – конкретные примеры применения широко известных алгоритмов в современных, повсеместно используемых, программных продуктах.



Посмотрим, что можно обнаружить в коде ядра Linux, браузера Chromium и ещё в некоторых проектах.

Вольный пересказ документации к sync.Pool

От переводчика: данная статья написана Manuel Kiessling в сентябре 2012 года, как реализация статьи Дядюшки Боба о чистой архитектуре с учетом Go-специфики.



Это вторая статья цикла об особенности реализации Чистой Архитектуры в Go. [Часть 1]

Это перевод блогпоста Сау Шон Чанга. В первой половине описывается его подход к созданию фотомозаики на Go, а во второй половине ускоряется выполнение программы за счёт добавления конкурентности (каналы, горутины).
По неточностям перевода пишите в личку.

Несколько месяцев назад мой хороший друг Сатиш Талим предложил отличную идею — создать несколько соревнований на Go, чтобы прокачать умения Go программистов. Идея проекта — каждый месяц (или около того) придумывать программерскую задачку, которая будет представлять собой свежий и интересный вызов для Go сообщества. Победители получат призы, но более важно, что это попытка помочь друг другу и себе в частности. Сатиш попросил меня придумать задание и я с удовольствием его придумал для третьего соревнования (challenge #3).

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

Финализаторы

Когда сборщик мусора Go готов собрать объект, оставшийся без ссылок, предварительно вызывается функция, называемая финализатором. Добавить такую функцию к своему объекту можно при помощи runtime.SetFinalizer. Посмотрим на него в работе:

Преамбула от переводчика: Это достаточно вольный перевод пусть и не самой свежей (июнь 2013 года), но доходчивой публикации о новом планировщике параллельных ветвей исполнения в Go. Достоинством этой заметки есть то, что в ней совершенно просто, «на пальцах» описывается новый механизм планирования для ознакомления. Тем же, кого не устраивает объяснение «на пальцах» и кто хотел бы обстоятельного изложения, рекомендую Scheduling Multithreaded Computations by Work Stealing — 29 страниц изложения со строгим и сложным математическим аппаратом для анализа производительности, 48 позиций библиографии.

Введение

Одной из наибольших новинок в Go 1.1 стал новый диспетчер, спроектированный Дмитрием Вьюковым (Dmitry Vyukov). Новый планировщик дал настолько разительное увеличение производительности для параллельных программ без изменений кода, что я решил написать что-нибудь об этом.

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

Перевод статьи Роба Пайка из официального блога Go о автоматической кодогенерации с помощью go generate. Статья немного устарела (была написана перед выходом Go 1.4, в котором и появился go generate), но хорошо объясняет суть работы go generate.

(Перевод статьи из официального блога Go)

Частой темой среди Go программистов, особенно тех, которые только познакомились с языком, является вопрос о том, как обрабатывать ошибки. Разговор часто сводится к жалобам на то, что последовательность

if err != nil {
    return err
}

появляется слишком часто. Недавно мы просканировали все open-source проекты, которые мы только смогли найти и увидели, что этот сниппет появляется лишь раз на страницу или две, гораздо реже, чем многие могли бы подумать. И всё же, если впечатление того, что вы должны всегда писать

 if err != nil

остается, значит, очевидно, что-то тут не так, и мишенью оказывается сам Go.

Это неверно, это вводит в заблуждение и это легко исправить. Наверное происходит следующее — программист, знакомясь с Go, задаёт вопрос — «Как я должен обрабатывать ошибки?», заучивает этот паттерн и тут и останавливается. В других языках, это может быть блок try-catch или другой механизм обработки ошибок. Соответственно, думает программист, там где я бы использовал try-catch в моём старом языке, в Go я просто напечатаю if err != nil. Со временем, в Go коде накапливается много таких сниппетов, и результат выглядит неуклюже.

Но вне зависимости от того, как это объясняется на самом деле, очевиден тот факт, что эти Go программисты упускают фундаментальную идею ошибок: Ошибки это значения.

От переводчика: данная статья написана Manuel Kiessling в сентябре 2012 года, как реализация статьи Дядюшки Боба о чистой архитектуре с учетом Go-специфики.



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

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

В данной части будет описана общая концепция и работа с внутренним слоем.