Привет, Хабр! Мы в Badoo стараемся активно участвовать в жизни IT-сообщества: используем многие open-source-технологии и инструменты, а также делимся своими разработками.

Один из таких инструментов – Pinba – сервис для получения realtime-статистики от работающих приложений без накладных расходов на её сбор. Узнать побольше вы можете в этой статье.

Мы стараемся помочь всем, кто использует Pinba в своих проектах и всегда рады слышать success stories, связанные с Pinba. Этот перевод – одна из подобных историй от разработчиков Dailymotion.

Введение

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Я довольно давно участвую в разработке web-приложений. Это не высоконагруженные приложения (типа Facebook или Gmail) — там, разумеется, своя специфика. Мои приложения были небольшими (можно было уместить на одном физическом сервере), но функционально насыщенными — финансовые, e-commerce. Я не работал в больших командах, зато пощупал весь спектр технологий, начиная от сборки аппаратуры в стойке и заканчивая редактированием CSS.

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

Под катом я попытался собрать своё видение относительно наиболее важных с моей точки зрения аспектах в разработке web-приложений.

Предупреждение: проверьте, как установлена версия Webpack в package.json. Возможно скоро ваш continuous integration сломается.

Наконец-то Webpack 2 преодолел рубеж beta и release candidate. Это значит, что всё работает стабильно, и можно без опаски использовать его в production.

Список изменений/улучшений:

• Нативная поддержка ES6-модулей;
• Разбиение кода на чанки — Code Splitting with ES6;
• Поддержка динамических выражений при загрузке модулей — Dynamic expressions;
• Изменения при работе с Babel;
• ES6-специфичные оптимизации;
• Breaking Changes;
• Новый сайт с документацией.

Подробности под катом.

Оглавление:

1. Объединение строк, кортежей, списков, словарей без изменения исходных.
2. Объединение множеств без изменения исходных.
3. Объединение списка, словаря и изменяемого множества с изменением исходной коллекции.
4. Добавление и удаление элементов изменяемых коллекций.
5. Особенности работы с изменяемой и не изменяемой коллекцией.

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

Когда мы имеем дело с финансовой системой на основе блокчейна, то процесс денежного перевода выглядит совершенно иначе. В Bitcoin не существует никакой общей таблицы вида <адрес, баланс>, ровно как и не существует регулятора, который бы эту таблицу редактировал. В этой статье я покажу, что из себя представляет транзакция в Bitcoin, как она строится, и объясню, зачем же внутри Bitcoin добавлен свой язык программирования, про который все слышали, но никто не видел.

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

Ниже я объясню, каким образом формируется транзакция, покажу как она подписывается и продемонстрирую механизм общения между нодами.

Вступление никому не интересно, поэтому начну сразу с примеров использования

% cat log.json

{"type": "hit", "client": {"ip": "127.1.2.3"}}
{"type": "hit", "client": {"ip": "127.2.3.4"}}
{"type": "hit", "client": {"ip": "127.3.4.5"}}
{"type": "hit", "client": {"ip": "127.3.4.5"}}
{"type": "hit", "client": {"ip": "127.1.2.3"}}
{"type": "click", "client": {"ip": "127.1.2.3"}}
{"type": "click", "client": {"ip": "127.2.3.4"}}

Выполняем запрос:

% cat log.json | jl-sql 'SELECT client.ip, COUNT(*) AS count WHERE type = "hit" GROUP BY client.ip'

{"client":{"ip":"127.1.2.3"},"count":2}
{"client":{"ip":"127.2.3.4"},"count":1}
{"client":{"ip":"127.3.4.5"},"count":2}

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

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

n! = n * (n — 1) * (n – 2) * … * 3 * 2 * 1

1! 1
2! 2
3! 6
4! 24
5! 120
6! 720
7! 5 040
8! 40 320
9! 362 880
10! 3 628 800
11! 39 916 800
12! 479 001 600
13! 6 227 020 800
14! 87 178 291 200
15! 1 307 674 368 000

Новое открытие TFS

Какая первая ассоциация возникает, когда слышишь словосочетание Microsoft TFS? Что-то большое, неповоротливое и корпоративное. Именно так и было до появления Visual Studio Team Services и выхода MS TFS 2015. Первый — это облачная версия Team Foundation Server, которая опережает в развитии частную (private) версию примерно на три месяца. Одним из главным нововведений обновленного TFS/VSTS стала новая система сборок. Эта система позволяет достаточно просто писать свои шаги сборок, которые могут делать что угодно — от собственно сборки проекта до автоматического заведения дефектов и рассылки нотификаций. Кроме этого новая версия предоставляет развитый REST API для манипулирования задачами, дефектами и практически любыми сущностями в базе данных TFS.

Именно поэтому когда перед нами встал выбор новой системы управления жизненным циклом разработки, мы остановились именно на этой новой версии MS TFS. Мы используем TFS для полного цикла — планирование-разработка-тестирование-развертывание, и, поначалу все шло достаточно гладко. С ростом сложности задач, которые мы ставили перед системой сборки, появлялись и проблемы. К счастью, REST API и собственные шаги сборки позволили их с успехом решить. Далее я расскажу о проблемах и о том, как мы их решили.