Предисловие Около года назад я задался целью получить оффер от FAANG. Как следствие, постоянной частью моей жизни стали тематические форумы, площадки и вся сопутствующая атрибутика. Спустя какое-то время я попробовал себя на собеседованиях в околоFAANGoвые компании: Lyft, Spotify, Booking и т. д, где-то успешно, где-то не очень. В это же время мне порекомендовали попробовать пройти собеседование в Тинькофф банк, который внедрил схожий процесс. После стандартного общения с HR менеджером была получена ссылка на описание процесса собеседования. “Хм, почти что FAANG + тех. интервью по Primary Skill”, - подумал я и сказал, что готов приступать. В тот же час было назначено 2 интервью: техническое и coding, а вот 3 этап, system design, нужно было заслужить успешным прохождением первых двух. Почему именно эти 2 части являлись основополагающими, осталось неясным.

Акт первый, технический

В назначенный час я встретился со своим интервьюером. Собеседование выглядело “добротным” и стандартным в заданной проф. области, оттого местами скучным. Было много задач на ревью кода и обсуждения специфики языка, в частности...

Привет, Хабр! Представляю вашему вниманию перевод статьи "Anatomy of Channels in Go" автора Uday Hiwarale.

Что такое каналы?

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

Создание канала

Go для создания канала предоставляет ключевое слово chan. Канал может передавать данные только одного типа, данные других типов через это канал передавать невозможно.

Привет, меня зовут Иван, и я делаю Авито Доставку. Когда пользователь покупает товар с доставкой, мы показываем ему список отделений служб доставки с ценами. Цена доставки может меняться от отделения к отделению. Мы смотрим на область карты, где покупатель ищет товар и информацию по объявлению, например, координаты продавца, вес и размеры товара. И на выходе показываем человеку список отделений с адресами и ценой доставки в каждое из них.

В ходе разработки калькулятора цены доставки возникла такая задача: есть структура базы данных PostgreSQL и запрос к ней от сервиса на Go. Нужно заставить всё это работать достаточно быстро. В итоге нам удалось поднять пропускную способность сервиса с 50 до 5000 RPS и выявить пару нюансов при общении сервиса с базой. Об этом и пойдёт рассказ.

Сетевой стек — одна из самых запутанных вещей в Linux. И не только из-за сложности некоторых концепций и терминов, но и из-за изменения смысла некоторых параметров в разных версиях ядра. В этой статье приведена информация для ядра 2.2 и выше, а также, там где это возможно, указано различие между версиями вплоть до 5.5.

О том как изменять параметры ядра, описываемые здесь, можно прочитать в статье Linux Kernel Tuning for High Performance Networking: Configuring Kernel Settings.

Долгое время я терпел ограничения РосКомНадзора и соответствующие действия провайдеров по различным ограничениям доступа к сайтам - но с определённого момента устал, и начал думать как бы сделать так, чтобы было и удобно, и быстро, и при этом с минимумом заморочек после настройки... Хочу оговориться, что цель анонимизации не ставилась.

Вообще, эта проблема имеет несколько решений... Но я решил бороться с провайдером их же методом.

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

Рассмотрены, в основном, сугубо технические моменты, никакой техники продаж и прочего маркетинга.

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

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

Свежая подборка новостей и материалов со ссылками

Интересное в этом выпуске 

Поддержка ARM, Движок Diablo 2, Расшифровка паролей из браузеров, Сборщик js – аналог webpack

Приятного чтения!

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

Делюсь тем, что из этого вышло.

Всем привет! Меня зовут Сергей, я работаю в команде Тинькофф. Сегодня я хочу рассказать, как мы в Тинькофф приходили к классической пирамиде тестирования. 

Рассказ будет в трех частях:

- Трудности, с которыми нам пришлось столкнуться, и как мы их преодолевали.

- Конкретные решения по некоторым распространенным кейсам при написании интеграционных тестов.

- Подход к написанию E2E-тестов (тестов, покрывающих взаимодействие всех систем приложения, включая back-end и пользовательский интерфейс) с использованием паттерна PageObject, пришедшего к нам из мира веб-разработки.

Однажды я вел вебинар про то, как принимать 10 000 ивентов в секунду. Показал картинку, зрители увидели сиреневый слой, и началось: «Ребят, а зачем нам все эти кафки и рэббиты, неужели без них не обойтись»? Мы и ответили: «Зачем-зачем, чтобы пройти собес!»

Очень смешно, но давайте я все-таки объясню.

Потому что государство – это продукт. Со своими метриками, экономикой, жизненным циклом. У граждан-пользователей есть и лайфтайм, и отток, и средний чек. Да и цели те же: найти свою нишу на мировом рынке, решить боли пользователей, повысить выручку и капитализацию. Только вот чиновники, которые управляют нашими странами, угробили бы любой стартап примерно сразу.

Один из интересных и не очень часто освещаемых вопросов ИТ-менеджмента – расширение команды инженеров и ошибки, которые можно совершить на этом пути. Я сам активно развиваю свои проекты и поэтому интересуюсь этой темой. Мне удалось поговорить с Алиной Зурабовой, Head of Engineering and Testing в компании Smartcat. Этот стартап с российскими корнями, который развивает платформу управления переводами и привлек более $14 млн. Соответственно, за последние пару лет серьезно выросла и его техническая команда. 

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

Есть такой продвинутый инструмент Scrutinizer CI.

Для OpenSource он абсолютно бесплатный и платный для приватных репозиториев.

Вы о нем слышали, наверное, а если нет, то лично я использую его для анализа кода на различного рода уязвимости, а также в качестве замены статическому анализатору типа Psalm, ну и для покрытия конечно же, т.к. при довольно простой сквозной интеграции с GitHub оно внедряется в ваши PR и можно ревьюить код, наблюдая покрытие по аналогии с Cubertura в GitLab.

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

Поэтому я решил поделиться с вами своим опытом интеграции со Scrutinizer CI, рассказать о нюансах и тд...