1. Go в production.
2. Профилирование Go-приложений.
3. Медиасервер трансляций на Go.
4. Pipeline поиска по Почте на Go.
5. Синхронизация данных в Go с помощью mysql binlog.
6. Как мы начали использовать Go в Ответах Mail.ru.
7. Pub/Sub и 1 миллион WebSocket’ов.
8. Программирование на Go (курс).
9. Кому нужен язык Go и микросервисы.

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

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

Привет. Меня зовут Сергей, последние пять лет я работаю в Яндексе. За это время участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал код-ревью.

С помощью код-ревью я постоянно узнаю что-то новое. Иногда, глядя на чужой код, хочется воскликнуть: "А что, так тоже можно?". В чужом коде я нахожу интересные приёмы и беру их себе на вооружение. Много новых знаний черпаю из комментариев к моему коду. Для меня стало открытием, что люди любят делиться своим опытом. Даже когда я разрабатываю проект в одиночку, то прошу ребят из другой команды посмотреть мои пулреквесты. Это мотивирует писать красивый и понятный код.

Но так было не всегда. Когда-то ревью было для меня наказанием. Я мог неделю с вдохновением писать код, вкладывая в него все силы. Отправлял пулреквест, трижды пинговал ревьювера, а в ответ получал сухое "вроде ок" или, что ещё хуже, десятки комментариев не по существу.

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

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

Зачем?

Я знаю, о чём вы подумали: «Ещё одна скучная статья про DRY? Нам их мало, что ли?».

Возможно, вы правы. Но я встречаю слишком много разработчиков (junior и senior), применяющих DRY так, словно они охотятся на ведьм. Либо совершенно непредсказуемо, либо везде, где можно. Так что, судя по всему, в интернете никогда не будет достаточно статей о принципе DRY.

Если кто не знает: принцип DRY — это "Don't Repeat Yourself" (не повторяйся), и впервые о нём упомянуто в книге The Pragmatic Programmer. Хотя сам по себе этот принцип был известен и применялся задолго до появления книги, однако в ней ему было дано название и точное определение.

Итак, без лишних рассуждений отправимся в путешествие по чудесной стране DRY!

Всем привет!
В этой статье я хочу рассказать о своем опыте переезда на “отвечающую современным трендам” платформу в одном legacy проекте.

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

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

Написать сетевой сервис на Go очень просто: в стандартной библиотеке есть куча инструментов, а если чего-то и не хватает, то на Github есть много модных библиотек для удовлетворения большинства нужд.

Но что, если необходимо написать с десяток разных сервисов, работающих в одной инфраструктуре?

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

У нас в Badoo крутятся >30 самописных демонов, написанных на разных языках, и ~10 из них – на Go. Все эти демоны работают на порядка 300 серверах. Как мы к этому пришли, не получив в итоге «зоопарк», как админы с мониторингом умудряются спать спокойно, не ограничивая при этом никого в смузи, а девелоперы, QA и релизеры живут дружно и до сих пор не переругались – читайте под катом.

Игорь Сысоев ( isysoev )

Как устроена MySQL-репликация

Андрей Аксенов (Sphinx), shodan

Мой доклад предназначен для тех людей, которые знают слово «репликация», даже знают, что в MySQL она есть, и, возможно, один раз ее настроили, 15 минут потратили и забыли. Больше про нее они не знают ничего.

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

Что такое репликация, в принципе? Это копирование изменений. У нас есть одна копия БД, мы хотим с какой-то целью еще одну копию.

Репликация бывает разных видов. Разные оси сравнения:

• степень синхронизации изменений (sync, async, semisync);
• количество серверов записи (M/S, M/M);
• формат изменений (statement-based (SBR), row-based (RBR), mixed);
• теоретически, модель передачи изменений (push, pull).