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

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

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



За последние несколько лет мы видели целый ряд идей относительно архитектуры систем. Каждая из них на выходе давала:

1. Независимость от фреймворка. Архитектура не зависит от существования какой-либо библиотеки. Это позволяет использовать фреймворк в качестве инструмента, вместо того, чтобы втискивать свою систему в рамки его ограничений.
2. Тестируемость. Бизнес-правила могут быть протестированы без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего компонента.
3. Независимоcть от UI. Пользовательский интерфейс можно легко изменить, не изменяя остальную систему. Например, веб-интерфейс может быть заменен на консольный, без изменения бизнес-правил.
4. Независимоcть от базы данных. Вы можете поменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не связаны с базой данных.
5. Независимость от какого-либо внешнего сервиса. По факту ваши бизнес правила просто ничего не знают о внешнем мире.

Диаграмма в начале этой статьи — попытка объединить все эти идеи в единую эффективную схему.

Я решил написать этот материал после того, как увидел твит Дэна Абрамова, за который хочу сказать ему огромное спасибо. Дэн задал своим подписчикам вопрос о самых интересных событиях в мире JavaScript, которые достойны внимания широкой общественности.


Любители JS на вопрос откликнулись, под твитом собралась целая гора ответов. Каждый говорил о том, на что, по его мнению, стоит обратить внимание в 2017-м году. В результате получилась весьма занимательная подборка, из которой я выбрал всё лучшее и добавил пояснения.

Если вы разрабатываете веб-приложения на го, то эта статья, возможно, будет вам интересна. До того, как перейти на go, я в основном программировал на PHP и мне всегда нравилось то, что можно сохранить файл, перезагрузить страницу и увидеть результат, который сгенерирован уже новым кодом. Большие программы на go могут компилироваться несколько десятков секунд, что весьма быстро, но всё равно ощутимо. Возможно ли сделать аналог Java hotswap (замена тела метода в runtime), ведь Go компилируется в нативный код? Ответ — да, возможно, но только для разработки. В данный момент мне неизвестно о готовых инструментах, которые бы позволяли это автоматизировать. В этой статье я хотел бы продемонстрировать proof-of-concept «живой перезагрузки» с использованием пакета plugin в go1.8beta2 и пакета github.com/bouk/monkey. Пытливый читатель скорее всего уже догадывается, что мы будем делать.

Два месяца труда одним URL: ru.vuejs.org
Кроме того, переведена документация Vuex: vuex.vuejs.org/ru
И vue-router: router.vuejs.org/ru

Огромное спасибо Konojoto и всем остальным, кто помогал переводить и вычитывать документацию (полный список контрибьюторов см. в репозиториях на github.com/translation-gang)

Документация выполнена небольшим (хотелось бы верить, что это не надолго) сообществом энтузиастов open-source перевода Translation Gang. Если вы хотели бы помочь с переводами документации какого-либо проекта с открытыми исходными кодами на русской язык, милости просим в наши ряды.

Приходит ветеринар к терапевту. Терапевт: — На что жалуетесь? Ветеринар: — Нет, ну так каждый может!

Искусственные нейронные сети способны обучаться. Воспринимая множество примеров, они могут самостоятельно находить в данных закономерности и выделять скрытые в них признаки. Искусственные нейронные сети во многих задачах показывают очень неплохие результаты. Закономерный вопрос — насколько нейронные сети похожи на реальный мозг? Ответ на этот вопрос важен главным образом для того, чтобы понять, можно ли, развивая идеологию искусственных нейронных сетей, добиться того же, на что способен человеческий мозг? Важно понять, носят ли различия косметический или идеологический характер.

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

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

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

Итак, магия:


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

Как вы думаете, чего в апельсине больше — кожуры, или, хм, апельсина?



Предлагаю, если есть возможность, пойти на кухню, взять апельсин, очистить и проверить. Если лень или нет под рукой — воспользуемся скучной математикой: объем шара мы помним из школы. Пусть, скажем, толщина кожуры равна от радиуса, тогда , ; вычтем одно из другого, поделим объем кожуры на объем апельсина… получается, что кожуры что-то около 16%. Не так уж мало, кстати.

Как насчет апельсина в тысячемерном пространстве?

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

• во-первых, в тысячемерном гиперапельсине кожуры больше, чем мякоти
• а во-вторых, ее больше примерно в 246993291800602563115535632700000000000000 раз

То есть, каким бы странным и противоречивым это ни казалось, но почти весь объем гиперапельсина содержится в ничтожно тонком слое прямо под его поверхностью.

Начнем с этого, пожалуй.

Часть 2 — градиентный спуск начало

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

Существует и другая версия алгоритма — стохастический градиентный спуск. Стохастический = случайный.

Часть 1 — линейная регрессия

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

Градиентный спуск

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

Оглавление

Часть 1 — линейная регрессия
Часть 2 — градиентный спуск
Часть 3 — градиентный спуск продолжение

Введение

Этим постом я начну цикл «Нейронные сети для новичков». Он посвящен искусственным нейронным сетям (внезапно). Целью цикла является объяснение данной математической модели. Часто после прочтения подобных статей у меня оставалось чувство недосказанности, недопонимания — НС по-прежнему оставались «черным ящиком» — в общих чертах известно, как они устроены, известно, что делают, известны входные и выходные данные. Но тем не менее полное, всестороннее понимание отсутствует. А современные библиотеки с очень приятными и удобными абстракциями только усиливают ощущение «черного ящика». Не могу сказать, что это однозначно плохо, но и разобраться в используемых инструментах тоже никогда не поздно. Поэтому моей первичной целью является подробное объяснение устройства нейронных сетей так, чтобы абсолютно ни у кого не осталось вопросов об их устройстве; так, чтобы НС не казались волшебством. Так как это не математический трактат, я ограничусь описанием нескольких методов простым языком (но не исключая формул, конечно же), предоставляя поясняющие иллюстрации и примеры.

Цикл рассчитан на базовый ВУЗовский математический уровень читающего. Код будет написан на Python3.5 с numpy 1.11. Список остальных вспомогательных библиотек будет в конце каждого поста. Абсолютно все будет написано с нуля. В качестве подопытного выбрана база MNIST — это черно-белые, центрированные изображения рукописных цифр размером 28*28 пикселей. По-умолчанию, 60000 изображений отмечены для обучения, а 10000 для тестирования. В примерах я не буду изменять распределения по-умолчанию.

Только закончив проект
вы обладаете полноценным знанием,
как его надо было реализовывать.
(С) Том Демарко

Мне всегда ходелось попробовать написать приложение, модули которого между собой общаются с помощью обмена сообщениями. В принципе, это вполне даже в духе классического понимания ооп его основоположниками. Однако до Erlang я не дорос и знаком только с Golang, поэтому именно на нём и попробовал создать немного причудливую, но тем не менее любопытную архитектуру web-приложения.

Вырубка карт. Интересна пыль: она на бумажном производстве покрывает всё очень быстро.

Меня уже много раз спрашивали, как коробка резанного картона может стоить 1500 рублей. Что в ней такого?

Цену любого товара можно посчитать тремя способами:

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

Вы будете чудовищно удивлены, когда придёте с макетами в типографию и попросите их напечатать. У нас три экземпляра игры к выставке получаются за 20 тысяч. Сейчас объясню, почему.

1 Почему JavaScript отстой
• 1.1 Плохая конструкция
• 1.2 Система типов
• 1.3 Плохие функции
• 1.4 Отсутствующие функции
• 1.5 DOM
2 Почему Lua отстой
3 Почему PHP отстой
• 3.1 Исправлено в поддерживаемых в настоящее время версиях
4 Почему Perl 5 отстой
5 Почему Python отстой
• 5.1 Исправлено в Python 3
6 Почему Ruby отстой
7 Почему Flex/ActionScript отстой
8 Почему скриптовые языки отстой
9 Почему C отстой
10 Почему C++ отстой
11 Почему .NET отстой
12 Почему C# отстой
13 Почему VB.NET отстой
15 Почему Objective-C отстой
16 Почему Java отстой
• 16.1 Синтаксис
• 16.2 Исправлено в Java 7 (2011)
• 16.3 Модель
• 16.4 Библиотека
• 16.5 Обсуждение
17 Почему Backbase отстой
18 Почему XML отстой
19 Почему отстой XSLT/XPath
20 Почему CSS отстой
• 20.1 Исправлено в CSS3
21 Почему Scala отстой
22 Почему Haskell отстой
23 Почему Closure отстой
24 Почему Go отстой
• 24.1 Базовые средства программирования (базовый язык)
• 24.2 Взаимосовместимость
• 24.3 Стандартная библиотека
• 24.4 Набор инструментальных средств
• 24.5 Сообщество
25 Почему Rust отстой
• 25.1 Безопасность
• 25.2 Синтаксис
• 25.3 Конструкция API и система типов
• 25.4 Сообщество
• 25.5 Набор инструментальных средств

Почему JavaScript отстой

Учтите, что некоторые положения относятся не к самому JavaScript, а к программным интерфейсам веб-приложений (https://developer.mozilla.org/en/docs/Web/API).

Плохая конструкция

• Каждый скрипт исполняется в едином глобальном пространстве имён, доступ в которое возможен в браузерах с оконным объектом.
• Camel-регистр никуда не годится:

XMLHttpRequest
HTMLHRElement

В будущем денег не будет. И совсем не потому, что наступит всеобщий коммунизм. Просто место денег займут обещания денег, выраженные или воплощенные в рейтингах субъектов оборота. Конечно это не более чем прогноз. В наиболее продуманном и обоснованном виде я его видел у известного журналиста и по совместительству футуролога Константина Фрумкина. Не повторяя весь ход его рассуждений приведем только итог.

Сколько нужно времени, чтобы просто вывести на экран большой список, используя современные фреймворки?

Напишем нехитрое приложение — личный список задач. Какие у него будут характеристики?

Небольшая головоломка: перед вами синхронный код, загружающий и обрабатывающий содержимое 4 файлов, но с сервера они грузятся параллельно. Как такое может быть?

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

Это первая часть, вот вторая.
За всеми архитектурами нейронных сетей, которые то и дело возникают последнее время, уследить непросто. Даже понимание всех аббревиатур, которыми бросаются профессионалы, поначалу может показаться невыполнимой задачей.

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

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

Генеральный директор CityAds Михаил Балакин считает, что в современном мире побеждают не те, у кого лучше секретарши, аккаунт-менеджеры и креативные концепции, а те, у кого «бородатее» программисты. Михаил пообщался с нами и рассказал о том, как работает performance-marketing, какие у него перспективы, о том, как компании удалось привлечь крупных и известных клиентов — Booking, AliExpress, Microsoft, eBay.

Кроме того, мы выяснили, считает ли он конкурентом CityAds компанию Google.

Даниил Подольский (Git in Sky)

Рассказ о том, что каждый инженер должен сделать в своей жизни после того, как он родил ребенка, посадил дерево и построил дом – это сделать свое файловое хранилище.

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

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

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


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