BackEnd

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

- Автоматизация поиска по крупнейшим торговым

площадкам Японии

- Реализация автоматизированной системы

управления переводами

- Автоматизация складского учета

- Реализация микросервисной архитектуры проекта

- Автоматизация взаимодействия с почтой Японии

через симуляцию пользовательских действий

- Автоматизация построения системы оплат и обработки сделок с онлайн-поставщиками

Что если вам нужно сделать быстрый, и не слишком сложный сервис, который при этом хорошо вертикально масштабируется? Как избежать ненужных внешних очередей на redis? Как обойтись без gunicorn? Как уместить все в один процесс? Обо всем этом я расскажу на примере построения API Gateway на Python, Flask и Gevent

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

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

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

Я присоединился к компании Lazada 2 года назад, когда уже были сделаны первые шаги в сторону микросервисной архитектуры, но мы были еще в самом начале пути. За это время мы прошли путь от 5-ти до 60-ти микросервисов, написанных на Golang, набили шишек и получили опыт, которым я и хочу с вами поделиться.

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

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

Мой доклад будет вам интересен, если вы думаете начать строить что-то основанное на микросервисной архитектуре, ищите способы решение эксплуатационных проблем или просто интересуетесь темой микросервисов.

В этом докладе я хочу осветить следующие аспекты разработки на языке Golang:

- Фреймворк

- Управление зависимостями

- CI

- Профилирование

- Конфигурирование

- Code style

- Статический анализ кода

- Типичные ошибки

- Производительность Golang приложений

- Вопросы найма Golang программистов

Любой крупной компании при реализации web-проекта необходимо в каком-либо виде настроить интеграцию с внутренними учетными системами. Каждая такая интеграция подразумевает плотное взаимодействие нас как подрядчика для разработки клиентской стороны с IM IT заказчика и содержит в себе много неочевидных рисков. В докладе мы осветим: - Работа над большими интеграционными проектами. С чего начать и как закончить. - Техническая документация на проекте: что, кто и когда. - Проблемы веб-сервисов, методы реагирования и способы их устранения. - Инфраструктура проекта: типовые схемы расположения компонентов системы.

В своем докладе расскажу

- как мы почти полностью автоматизировали процесс разработки ФРИИ

- как облегчить взаимодействие с QA

- как не повторять одно и то же для каждого нового члена команды

- расскажу какая боль лежала в основе https://github.com/achempion/software_process_fram...

Думаю, что многие, кто по каким-либо причинам стал писать на Go сталкивались с `if err != nil { return err }`. Некоторым (не)повезло и их код состоит из этих проверок чуть ли не целиком. И тут мнения разделяются: одни ссылаются на канонические писания и говорят, что такая проверка ошибок - гарант правильного кода и они счастливы. У других судьба больше похожа на "Мыши плакали, кололись, но продолжали грызть кактус". Мне хочется поделиться решениями часто возникавшими проблемами с кодом в backend'е стартапа DICE.FM. DICE.FM - ведущая платформа по продаже билетов на музыкальные концерты в Великобритании, а я там собственно отвечаю за серверную часть.

В этом докладе я расскажу, как мы в Почте@mail.ru разрабатывали и внедряли новую систему хранения аттачей из писем. Доклад состоит из трех частей. 1. Я расскажу, как построить систему, которая принимает 80 000 файлов в минуту, на лету вычисляет дубли и сохраняет их. 2. Как для этого организована система хранения метаинформации, чтобы на нее хватило оперативной памяти. 3. Какие нужны инструменты для обеспечения своевременного нахождения проблем в холодных данных. Жесткие диски, к сожалению, не вечны, а данные пользователя терять нельзя.