Go *

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

В этой статье вы узнаете:

• в чем отличие от интерфейсов в Java
• важные и неочевидные последствия этих отличий
• как устроены интерфейсы под капотом
• вспомним про пустой интерфейс (interface{})
• затронем сакральную тему про дженерики
• разберемся, кто и зачем должен создавать интерфейс
• и постараемся научиться не абьюзить интерфейсы и начать жить

(artwork by Svitlana Agudova)

Некое продолжение статьи Go и Protocol Buffers толика практики (или быстрый старт, для тех кто ещё не знаком). Процессы кодирования/декодирования в определённые форматы в Go тесно связяны с рефлексией. А как мы с Вами, дорогой читатель, знаем — рефлексия — это долго. О том какие методы борьбы существуют эта статья. Думаю что, искушённые вряд ли найдут в ней, что-либо новое.

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

Эта инфраструктура порождает метрики на всех технологических уровнях — нагрузка на железо, состояние ОС, метрики приложений. Исходные данные собираются в один большой кластер Graphite. Сейчас у нас есть миллион уникальных метрик, по которым суммарно генерируется 20 тысяч значений в секунду.

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

Одной из самых сильных сторон языка программирования Go является встроенная поддержка concurrency, основанная на труде Тони Хоара «Communicating Sequential Processes». Go создан для удобной работы с многопоточным программированием и позволяет очень легко строить довольно сложные concurrent-программы. Но задумывались ли вы когда-нибудь, как выглядят различные паттерны concurrency визуально?

Конечно, задумывались. Все мы, так или иначе, мыслим визуальными образами. Если я попрошу вас о чём-то, что включает числа «от 1 до 100», вы мгновенно их «увидите» в своей голове в той или иной форме, вероятно даже не отдавая себе в этом отчёт. Я, к примеру, ряд от 1 до 100 вижу как линия с числами уходящая от меня, поворачивающая на 90 градусов вправо на числе 20 и продолжающая до 1000+. И, покопавшись в памяти, я вспоминаю, что в самом первом детском саду в раздевалке вдоль стены были написаны номерки, и число 20 было как-раз в углу. У вас же, вероятно, какое-то свое представление. Или вот, другой частый пример — представьте круглый год и 4 сезона года — кто-то их видит как квадрат, каждая грань которого принадлежит сезону, кто-то — как круг, кто-то ещё как-то.

Так или иначе, позвольте мне показать мою попытку визуализировать основные паттерны concurrency с помощью Go и WebGL. Эти интерактивные визуализации более-менее отражают то, как я вижу это в своей голове. Интересно будет услышать, насколько это отличается от визуализаций читателей.

Язык Go в последнее время неоднократно обсуждался на хабре — его и критиковали , и хвалили. Мы в Intel любим Go и участвуем в open-source разработке этого проекта. Если вы тоже используете Go, интересуетесь его внутренним строением и вопросами наиболее эффективного программирования на этом замечательном языке, то добро пожаловать под кат. Статья будет о том, каким образом в Go реализован механизм внешних вызовов, и насколько быстро он работает.

Указываем в скрипте путь на книгу в txt — на выходе получаем папку с озвучкой хорошим синтезом.

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

В последнее время на хабре стало популярно делать собственные поисковики по RuTracker. Мне это показалось прекрасным поводом для того, чтобы отойти от скучной enterprise разработки и попробовать что-нибудь новое.



Итак, задача: реализовать на локалхосте поисковик по базе The Pirate Bay и попутно попробовать, что же такое frontend разработка и с чем её едят. Задача осложняется тем, что TPB не публикует своих дампов, в отличие от RuTracker, и для получения дампов требуется распарсить их сайт. В результате гугления и осмысления задачи я решил в качестве поисковика использовать Elasticsearch, для которого написать client-side only фронтенд на AngularJS. Для получения данных я решил написать собственный парсер сайта TPB и отдельный загружатель дампа в индекс, оба на Go. Пикантность выбору придавал тот факт, что ни к Elasticsearch, ни к AngularJS я до этого ни разу не прикасался и именно их опробывание было моей настоящей целью.

В этой части я дойду до момента, когда пришла смс-ка «Не звони и не пиши мне больше!!!!»

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

Суть

Разработал программу для простого расширения раздела и файловой системы (xfs, ext3,4) без потери данных. github.com/rekby/fsextender/releases/latest

Исходная проблема

После расширения диска виртуальной машины c ос семейства linux расширить внутри неё раздел данных.

После того как наигрались с Revel и поняли что это за чудик, пора учиться готовить его к production в части безопасности. Данная заметка вполне может использоваться в любом веб-приложении, но рассказывать буду на примере простого приложения на Revel.

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

Для упрощения интеграции мною была предложена идея создания обобщённой библиотеки для сохранения структурированных diff-ов для (почти) произвольного XML. Поскольку эти diff-ы будут сохраняться с учётом структуры документа, это дало бы возможность очень экономно аккумулировать изменения состояния устройств, а также в будущем генерировать отчёты с аналитикой, диаграммами, и т.п. После недели запойного программирования я набросал работающий proof-of-concept, которым и хочу поделиться в данной статье.

Здарова! Короче, последнее время на хабре было много срачей вокруг Go: хороший-плохой, нужен-ненужен, много сравнивали с питоном, много сравнивали с растом, divan0 даже додумался перевести высер «Go vs Haskell» ну и в таком ключе. У меня сложилось ощущение, что из-за хайпа и агрессивного маркетинга языка некоторыми Иванами Данилюками очень мало кто понял, кому и зачем вообще Go может пригодиться, зачем его делали и стоит ли вообще его учить. Я тоже долгое время участвовал в этих срачах, принимая посменно сторону «фанов» языка и сторону оппозиции, но в конце-концов допер, в чем фокус. Сегодня немного потупил у дивана в посте и решил написать вот эту заметочку.

Давайте, пацаны, проходим в пост.

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

Стал я замечать, что из 15 гигабайт бесплатного месте, предоставленного Google, у меня почта занимает уже почти 12 гигабайт. И такая тенденция меня не радует.
С другой стороны я в качестве почтового клиента использую Thunderbird с полной синхронизацией. Т.е. все письма должны быть закачены. Так вот папка Thunderbird со всеми письмами и индексами занимает всего 3 гигабайта. Хотя по логике вещей размер должен не просто более менее совпадать с занятым местом на GMail, а быть побольше, т.к. Thunderbird не архивирует письма, а хранит как есть и еще индексы строит для ускорения поиска.
Проблема на лицо! Начинаем докапываться до сути.

Перевод статьи технического директора компании CrowdStrike, о том, как и почему они перешли со Scala на Go по мере роста компании с 5 до 200+ человек.

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

Я перешёл из компании Gravity, которая достаточно активно использовала Scala. Это был основной язык в компании. Я привык к нему, мне он нравился, я видел его мощь и был уверен, что смогу предотвратить некоторые из сложностей, которые я видел в Scala, по мере того, как CrowdStrike будет расти. Мы делали высоконагруженную аналитику, batch-задачи на Hadoop и наш Chief Architect (привет, Биссел!) использовал лямбда-архитектуру задолго до того, как это стало модно.

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

2-я часть истории, которая началась с смс-ки от Кати «Не звони и не пиши мне больше!!!!»

«Не звони и не пиши мне больше!!!!» — пришла смс-ка от моей девушки Кати. Через пару часов я осознал, что теперь у меня появилась куча свободного времени и я решил переписать Dcoin на Go.

Я кратко расскажу о процессе разработки Cloud Foundry (CF), особенностях open source модели и немного личного опыта.

В 2013 году я стал активным пользователем платформы, когда IBM запустила внутреннюю бету Bluemix, в начале этого года я принял участие в портировании Cloud Foundry на архитектуру POWER8, а с середины октября я стал членом CF core team, пройдя CF Dojo. Но обо всем по порядку.

Не буду углубляться в историю или объяснять что такое Cloud Foundry, но вот необходимый минимум фактов. CF — это Platform as a Service (PaaS), разработанная VMWare и позднее переданная Pivotal Software. Исходный код был открыт, сейчас еще есть отдельный инкубатор CF проектов. Чуть позже была создана Cloud Foundry Foundation, в которую вошли Pivotal, IBM, VMWare, EMC, GE, Intel, SAP, настоящее время в нее входит более 50 организаций. Изначально платформа была написана на Ruby, позднее часть компонент были переписаны на Go.