Привет! Меня зовут Марко, я работаю в Badoo в отделе «Платформы». У нас довольно много всего написано на Go, и зачастую это критичные к производительности системы. Именно поэтому сегодня я предлагаю вашему вниманию перевод статьи, которая мне очень понравилась и, я уверен, будет вам очень полезна. Автор пошагово показывает, как он подходил к проблемам производительности и как их решал. В том числе вы познакомитесь с богатым инструментарием, доступным в Go для такой работы. Приятного чтения!

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

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

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

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

Автор — из старой школы. По разным причинам. Мне нравится заниматься «всем», помогать себе и компании, и я рассчитываю на отдачу — не только, и не столько, на финансовую. Я постоянно учусь. Но не только своей «основной», узкой специальности (=программирование), за которую платят, и ниже объясню, почему…

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

Дальше я постараюсь обобщить личный и известный мне опыт по этой проблеме.

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

Этот раз не стал исключением и я задумал создать бота, который позволял бы с наибольшим комфортом и минимумом усилий смотреть любимые фильмы и сериалы, да еще и предоставлял контент в нескольких вариантах озвучки. Сказано — сделано. И теперь, когда железный друг человека радостно раздает пользователям их любимые шоу, я бы хотел поговорить о том, что сопутствовало созданию бота, какие проблемы вставали на моем пути и как они были решены. В первой главе я расскажу о Go глазами PHP-разработчика, во второй главе о поиске дзена для парсинга Кинопоиска, а в третьей — о недокументированной фиче Telegraph.

За пять дней, с 24 по 28 июля 2017 года, я прошел собеседования в LinkedIn, Salesforce Einstein, Google, Airbnb и Facebook; все пять компаний предложили мне работу. Это был замечательный опыт и я понимаю, как мне повезло, что мои усилия оправдали себя, поэтому решил написать об этом. Здесь я расскажу о том, как готовился к собеседованиям, как они проходили и какое впечатление произвели на меня компании.

Как все началось

Я отработал в Groupon почти три года. Это моя первая работа, там были и прекрасные люди, и отличные проекты. Мы делали всякие интересные штуки, вводили перемены внутри компании, публиковали материалы и все в таком духе. Но со временем я стал ощущать, что темп моего самообразования стал затухать (попросту говоря, замедляться), мне не хватало пищи для ума. К тому же, как и всякого разработчика ПО из Чикаго, меня тянуло в Область залива Сан-Франциско — ведь там столько известных компаний.

Жизнь коротка, а профессиональная жизнь еще короче. Обговорив все с женой и заручившись ее полной поддержкой, я решил сделать решительный шаг и в первый раз в жизни поменять работу.

Аникин Денис ( danikin, Mail.Ru)

Доклад будет посвящен Tarantool. Я всегда рассказывал про use case, про что-то такое, что видит пользователь. Сегодня буду больше рассказывать про внутренности.

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

Поэтому, прежде чем начать применять его в продакшне, в Почте mail.ru и в Облаке, я все очень внимательно изучил и выяснил, как Tarantool устроен внутри, и что его делает таким оптимальным. И я подозреваю, что, наверное, у других пользователей Tarantool тоже есть такое же подозрение — что-то он какой-то слишком быстрый, и как-то это подозрительно…

В предыдущей статье я описала как создать простую лямбду на Golang, которая принимает на вход простой объект из двух полей и такой же простой объект отдает на выходе. Теперь немного усложним задачу, подсоединив к лямбде в качестве источника данных Kinesis, а результат обработки записей Kinesis мы будем перекидывать в CloudSearch. Никакой особенной логики в лямбде не будет для упрощения: просто примем запросы от Kinesis, залогируем их в CloudWatch, преобразуем и отправим в CloudSearch.

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

Прим. перев.: Этот материал, написанный опытным разработчиком, не задаётся целью похоронить идею микросервисов, как можно подумать, глядя на заголовок. Статья — разумное предупреждение для тех, кто решил, что микросервисы — это «серебряная пуля», которая сама по себе решает все архитектурные и эксплуатационные проблемы. Для демонстрации этого автор собрал и систематизировал популярные проблемы, зачастую встречающиеся в сегодняшних проектах, уже использующих микросервисы или мигрирующих на них.



В последние годы микросервисы стали очень популярной темой. «Микросервисное безумие» выглядит примерно так:

«Netflix хороши в DevOps. Netflix делают микросервисы. Таким образом, если я делаю микросервисы, я хорош в DevOps».

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

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

Приветствую вас, хабровчане, решил поделиться с сообществом переводом довольно часто (по личным наблюдениям) упоминаемого поста SOLID Go Design из блога Dave Cheney, который выполнял для собственных нужд, но кто-то говорил, что нужно делиться. Возможно для кого-то это окажется полезным.

SOLID дизайн Go

Этот пост на основе текста из основного доклада GolangUK прошедшего 18-ого Августа 2016.
Запись выступления доступна в YouTube.

Содержание

1. Blockchain на Go. Часть 1: Прототип
2. Blockchain на Go. Часть 2: Proof-of-Work
3. Blockchain на Go. Часть 3: Постоянная память и интерфейс командной строки
4. Blockchain на Go. Часть 4: Транзакции, часть 1
5. Blockchain на Go. Часть 5: Адреса
6. Blockchain на Go. Часть 6: Транзакции, часть 2
7. Blockchain на Go. Часть 7: Сеть

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

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

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

У меня была такая мысль — “Вот сейчас я сделаю так, как должно быть”. Так появился мой проект. Так появляются тысячи проектов, созданных программистами.

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

А главная задача — это сделать поиск работы простым и полезным занятием.

История из жизни. Девушка предложила своему парню-программисту пройти психологический тест:

Девушка: Нарисуй дерево.
Программист: (рисует бинарное дерево)
Девушка: Нет, другое.
Программист: Я и красно-черное дерево могу нарисовать.

Итак, сегодня хочу немного рассказать о красно-черных деревьях. Рассказ будет кратким, без рассмотрения алгоритмов балансировки при вставке/удалении элементов в красно-черных деревьях.

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

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

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

«Это все только для хайлода» — скажет вдумчивый и прозорливый читатель. Плох тот веб-проект, который не мечтает стать популярным хайлодом.

Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2016.

Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.

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



Сегодня мы поговорим о React.js и Vue.js. Это – одни из самых популярных JavaScript-библиотек в мире. Взгляните на этот список, посмотрите их репозитории на GitHub. И та, и другая обладают впечатляющими возможностями и служат для создания пользовательских интерфейсов. Работать с ними довольно просто, главное – сразу понять, что к чему, сделать правильный первый шаг. Собственно говоря, этому вот первому шагу в разработке с использованием React и Vue и посвящён данный материал.

За последний год я много слышал о Virtual DOM и React JS.
React работает действительно быстро и очень прост, но как он работает? Что такое Virtual DOM? Почему я должен беспокоиться об этом, и что случилось со старым добрым обычным DOM?

Что такое DOM

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