Всем привет! Сегодня мы напишем своего первого боевого торгового робота для игры на бирже. Криптобирже. Почему криптобирже?

а) хайповая тема;
б) у них как-то все попроще.

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

Во-вторых, Вы заработаете. Просто немного.

Недавно я познакомился с замечательной серией статей "Thinking in Ramda", которые проясняют на простых и ясных примерах способы написания кода в функциональном стиле с использованием библиотеки Ramda. Эти статьи показались мне настолько прекрасными, что я не смог удержаться от того, чтобы не перевести их на русский язык. Надеюсь, что в этом будет польза для многих людей :) Давайте начнём перевод с первой вступительной статьи.

1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение

Данный пост — это начало серии статей «Мышление в стиле Ramda» о функциональном программировании.

Я буду использовать библиотеку Ramda в этих статьях, хотя многие из обсуждаемых идей применимы также к множеству других библиотек, таких как Underscore и Lodash, а также к другим языкам программирования.

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

Кого можно назвать «пиксельных шейдеров начальник и пикселов командир»? Дениса Радина, работающего в Evolution Gaming над фотореалистичными веб-играми с использованием React и WebGL: он известен многим как раз под именем Pixels Commander.

В декабре на нашей конференции HolyJS он выступил с докладом о том, как использование GLSL может улучшить работу с UI-компонентами по сравнению с «обычным джаваскриптом». А теперь для Хабра мы подготовили текстовую версию этого доклада — добро пожаловать под кат! Заодно прикладываем видеозапись выступления:

Введение

Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.

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

Терминология

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


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

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

Многие уже научились строить чистые интерфейсы и писать «undo-redo» в несколько строчек. Но как быть с анимациями? Часто их обходят стороной, и они не всегда вписываются в подход (state) ↦ DOM. Есть отличные решения вроде React Motion, но что если вам нужно делать сложные анимации или работать с Canvas, используя физический движок?

В нашем тексте рассказывается, как работать с анимациям в React-приложениях, и сравнивается несколько подходов (D3, React-Motion, «грязные компоненты»). А также о том, как «запускать» анимации в Redux-приложениях. Материал основан на расшифровке доклада Алексея Тактарова с нашей декабрьской конференции HolyJS 2017 Moscow. Прилагаем заодно видеозапись этого доклада:


Осторожно, трафик: под катом много картинок и гифок (сами понимаете, материал про анимации).

Я присоединился к Uber два года назад в качестве мобильного разработчика, имеющего некоторый опыт разработки бекенда. Здесь я занимался разработкой функционала платежей в приложении — и по ходу дела переписал само приложение. После чего я перешёл в менеджмент разработчиков и возглавил саму команду. Благодаря этому я смог гораздо ближе познакомиться с бэкендом, поскольку моя команда несёт ответственность за многие системы нашего бэкенда, позволяющие осуществлять платежи.

До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости — такие, например, как согласованность (consistency), доступность (availability) или идемпотентность (idempotency).

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

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

Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.

Product Manager очень часто выступает первым представителем продукта или сервиса для внешнего мира. Для этого успешному PM требуется опыт, энтузиазм и, конечно, профессиональные управленческие навыки, коммуникативные и другие способности. Набор этих качеств помогает специалисту грамотно представить продукт и вывести его на рынок.

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

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

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

В этой статье мы с нуля разработаем React-приложение, обсудим домен и его сервисы, хранение, сервисы приложения и представление (view).