В июне на конференции РИТ++ мы с коллегой Игорем Должиковым делились опытом автоматизации процесса разработки сервисов на Go — от первого коммита и до релиза в продакшн-окружение Kubernetes (да-да, видео начинается с 07:16, и нам тоже это не нравится). С момента публикации мастер-класса время от времени я получаю вопросы по тем или иным темам, затронутым в нем. Пожалуй, самые горячие вопросы достойны отдельного рассмотрения, и сегодня я хотела бы поговорить о процессе сборки приложения. Затрагиваемые темы актуальны не только при подготовке сервисов, но и вообще для любых приложений, написанных на Go.

Всё, что описано в этой статье, актуально для текущей версии Go — 1.9.

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

Rocky Runs Up The Stairs

Привет, Хабр. Вы, наверно, меня помните: я – Марко Кевац, системный программист в Badoo. Недавно я наткнулся на небольшой рассказ о том, как новичок сделал изменение в рантайме языка Go. Несмотря на то, что этот пост, наверное, довольно неожиданно встретить в хабраблоге Badoo, и многие могут сказать, что он банален и переполнен наивной радостью, я считаю, что такие истории демонстрируют, насколько сообщество Go доброжелательно и внимательно по отношению ко всем его участникам. Поэтому и перевел его.

А ещё в посте есть два интересных факта, связанных с внутренностями языка. Приятного чтения!

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

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

Тема различных криптовалют и блокчейнов на сегодняшний день стала уже достаточно популярной и перестала быть уделом гиков, бубнящих про революцию в сфере финансов. Но как только вы попытаетесь вникнуть в эту тему, сразу же столкнетесь с информационным дефицитом: очень мало материала, где описывается доступным, в меру техническим языком о концепции и механизмах работы этих технологий. Условно, все материалы можно поделить на две категории: либо хардкорно технические, где с первого предложения начинается жуть про криптографию, p2p, “цифровое золото” и т.д., либо маркетинговая чушь про новый интернет, капитализацию Биткойна или как некая компания/страна внедрила блокчейн и решила все свои проблемы. Если вы хотите понять, как это все работает и что можно сделать с этими технологиями, то эти статьи для вас.

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

В последнее время вокруг блокчейна, криптовалют, умных контрактов и связанных с ними технологий поднялся небывалый хайп. Создается ощущение, что даже самые ленивые и пассивные обыватели трубят об этом из каждого болота. Огромное количество стартапов и компаний с историей и опытом из сферы ИТ, услуг, ритейла и реального сектора экономики задумываются о внедрении блокчейна в свою деятельность, а более 100 000 компаний уже сделали это.

Механизм Initial Coin Offering не только способствовал новой волне интереса к краудфандингу, увеличив объем привлекаемых с его помощью инвестиций, но и подхлестнул интерес к криптовалютам и технологии блокчейн. Сегодня все чаще и чаще попадаются новые вакансии в этой области, а также просьбы о помощи в проведении ICO в целом и разработке смарт-контрактов в частности.

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

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

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



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

Джентльменский набор терминов

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

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

---

Перевод статьи Sashko Stubailo GraphQL vs. REST

---

Два способа отправки данных по протоколу HTTP: в чем разница?

GraphQL часто представляют как революционно новый путь осмысления API. Вместо работы с жестко определенными на сервере конечными точками (endpoints) вы можете с помощью одного запроса получить именно те данные, которые вам нужны. И да — GraphQL гибок при внедрении в организации, он делает совместную работу команд frontend- и backend-разработки гладкой, как никогда раньше. Однако на практике обе эти технологии подразумевают отправку HTTP-запроса и получение какого-то результата, и внутри GraphQL встроено множество элементов из модели REST.

Так в чем же на самом деле разница на техническом уровне? В чем сходства и различия между этими двумя парадигмами API? К концу статьи я покажу вам, что GraphQL и REST отличаются не так уж сильно, но у GraphQL есть небольшие отличия, которые существенно меняют процесс построения и использования API разработчиками.

Так что давайте сразу к делу. Мы определим некоторые свойства API, а затем обсудим, как они реализованы в GraphQL и REST.

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

В этот раз мы погрузимся в пучины Spring фреймворка, разоблачим его магию, посмотрим как базовое веб приложение выглядит изнутри, и разберемся, какую-же задачу и как решает Spring Boot.

Однажды в рассылке Golang Weekly мне попался проект Bleve. Это полнотекстовый поиск, который написан на Go. Проект интересный, и появилось бешеное желание получить с ним опыт работы.

Bleve может хранить данные в разных embedded БД:

• BoltDB (использует по умолчанию)
• LevelDB
• RocksDB
• Goleveldb
• forestdb
• Gtreap

---

Перевод. Автор оригинала Samer Buna. Оригинал статьи.

---

Когда я впервые узнал о GraphQL после долгого использования различных REST API, то не мог удержаться от твитов такого содержания:

Rest API превратился в REST-in-Peace API. Долгих лет жизни GraphQL

Примечание переводчика – Rest In Peace, RIP – распространенная эпитафия "Покойся с миром". Первое слово в ней пишется так же, как акроним REST.

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

Поймите правильно. Я не собираюсь обвинять GraphQL в убийстве REST или чём-то таком. REST не умрет никогда, также как XML будет жить вечно. Но кто в здравом уме станет использовать XML вместо JSON? На мой взгляд, GraphQL сделает для REST то же самое, что JSON сделал для XML.

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

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

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

Список лекций:

• Лекция 1. Введение
• Лекция 2. Функции, структуры, интерфейсы. Объектная модель
• Лекция 3. Асинхронная модель
• Лекция 4. Web. Работа с сетью
• Лекция 5. Работа с СУБД
• Лекция 6. Система тестирования
• Лекция 7. Reflect or generate?
• Лекция 8. Производительность
• Лекция 9. Context, unsafe, cgo

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

Лицо моей жены, когда она вычитывала эту статью

Я решил написать цикл статей, который и сам был бы счастлив найти где-то полгода назад. Он будет интересен в первую очередь тем, кто хотел бы начать разрабатывать классные приложения на React.js, но не знает, как подступиться к зоопарку разных технологий и инструментов, которые необходимо знать для полноценной front-end разработки в наши дни.

Я хочу с нуля реализовать, пожалуй, наиболее востребованный сценарий: у нас есть серверная часть, которая предоставляет REST API. Часть его методов требует, чтобы пользователь веб-приложения был авторизован.

Введение

8-9-го декабря 2016 года была проведена первая конференция по Angular в Бельгии. Игор Минар (ведущий разработчик Angular) выступил в качестве основного докладчика с несколькими интересными объявлениями относительно того, по какому графику будет выпускаться Angular. И представьте себе, в марте 2017 года нас ждет релиз Angular 4. При этом, на данный момент уже опубликована бета-версия.

От переводчиков

Всем привет, с вами Максим Иванов и Дмитрий Сергиенков, и сегодня мы выясним куда делась третья версия, и почему мы по-прежнему можем быть верны Angular. Сейчас начинающему фронтенд-разработчику, изучающему JavaScript, довольно трудно определиться: какой же фреймворк или библиотеку им взять и изучить, оставаясь в тренде? Конечно, без слова React, сейчас не обходится ни один разговор на тему фронтенда, однако, в свое время я начал с первой версии Angular, начитался много руководств по написанию фронтенда на ES6 (с классами и прочим добром) и до сих пор не жалею. Да, вы можете писать корпоративные приложения с использованием только jQuery, но по мере развития и сложности проекта вы начнете закапывать себя в спагетти-коде, смешивая логику и представление, MV*-фреймворки же этого сделать вам не дадут.

Команды разработчиков ПО часто принимают решения о программной архитектуре или технологическом стеке, основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты. Я называю эту тенденцию «Hype Driven Development (HDD)», считаю ее вредной и выступаю за более профессиональный подход. Давайте посмотрим, как обстоят дела, и что мы можем противопоставить.

Новые технологии — новые надежды

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

Залп скосил 50 офицеров и 760 рядовых. Французы дрогнули, запаниковали и — обратились в бегство. «Тут дела наши пошли не вполне хорошо», — описывает этот момент битвы официальная французская депеша.

Келли Дж. Порох. От алхимии до артиллерии.

Формирование Scrum команды всегда сопряжено со многими трудностями. Почти все справляются с тем, чтобы изменить порядок рабочего процесса и начать проводить некоторые из необходимых по Scrum событий. Но получить от этих формальных изменений видимую пользу и начать действительно менять рабочий процесс удается меньшинству. В результате у команды формируется следующее мнение о Scrum: “Мы без толку тратим время на митинги. Scrum не работает. Нужно что-то менять”.

Пытаясь как-то спасти положение, активисты Scrum вспоминают, что Scrum — это же еще и framework. Объявляется новая стратегия: “Мы не только Scrum, мы еще и Agile! Мы используем best practices, берем из Scrum только самое лучшее, то, что подходит конкретно для нашей ситуации, а все остальное лишнее и необязательно”. А раз так — “Мы — молодцы и все делаем правильно”.