Всем привет!

Я занимаюсь разработкой и поддержкой сервиса уведомлений в Ostrovok.ru. Сервис написан на Python3 и Django. Помимо транзакционных писем, пушей и сообщений, сервис также берёт на себя задачи по массовым рассылкам коммерческих предложений (не спам! trust me, отписки у нас работают лучше подписок) пользователям, давшим на это согласие. Со временем база активных получателей разрослась до более миллиона адресов, к чему почтовый сервис не был готов. Я хочу рассказать о том, как новые возможности Python позволили ускорить массовые рассылки и сэкономить ресурсы и с какими проблемами нам пришлось столкнуться при работе с ними.

Всем привет!

У нас уже есть одна статья про развитие типизации в Ostrovok.ru. В ней объясняется, зачем мы переходим с pyContracts на typeguard, почему переходим именно на typeguard и что в итоге получаем. А сегодня я расскажу подробнее о том, каким образом происходит этот переход.

Скорее всего, сегодня уже ни у кого не возникает вопрос, зачем нужно собирать метрики сервисов. Следующий логичный шаг – настроить алертинг на собираемые метрики, который будет оповещать о любых отклонениях в данных в удобные вам каналы (почту, Slack, Telegram). В сервисе онлайн-бронирования отелей Ostrovok.ru все метрики наших сервисов льются в InfluxDB и отображаются в Grafana, там же настроен базовый алертинг. Для задач типа «нужно посчитать что-то и сравнить с этим» мы используем Kapacitor.


Kapacitor – часть TICK-стека, который умеет обрабатывать метрики из InfluxDB. Он может соединить несколько измерений между собой (join), из полученных данных вычислить что-то полезное, записать результат обратно в InfluxDB, отправить алерт в Slack/Telegram/почту.

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

Поехали!

Всем привет! Это вторая часть серии статей от IT-команды сервиса бронирования отелей Ostrovok.ru об организации онлайн-трансляции корпоративных презентаций и мероприятий в одном отдельно взятом помещении.

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



И вроде всё было хорошо, но спустя некоторое время в наш отдел прилетела новая задачка – давайте сделаем наши трансляции более интерактивными! Всё наше ТЗ заключалось в одном предложении – нужно было дать удаленным сотрудникам возможность подключаться к встречам команд, то есть не только смотреть, но и активно участвовать: показывать презентацию, задавать вопросы в режиме реального времени и т.д. Проанализировав ситуацию, мы решили использовать конференцсвязь Zoom.

Всем привет! В этой статье я бы хотел рассказать о том, как IT команда сервиса онлайн-бронирования отелей Ostrovok.ru настраивала онлайн-трансляции различных корпоративных мероприятий.

В офисе Ostrovok.ru существует особая переговорная комната – «Большая». Каждый день в ней проходят рабочие и неформальные мероприятия: встречи команд, презентации, тренинги, мастер-классы, интервью с приглашенными гостями и прочие интересные события. Штат компании насчитывает более 800 человек – многие из них работают удаленно в других городах и странах, и далеко не у всех есть возможность физически присутствовать на каждой встрече. Поэтому задача организовать онлайн-трансляции внутренних встреч не заставила себя долго ждать и прилетела в команду IT. Расскажу подробнее о том, как мы это делали.

Не ORMом единым

Всем привет! Я руковожу отделом партнерской разработки (Partners Development) в сервисе бронирования отелей Ostrovok.ru. В этой статье я хотел бы рассказать про то, как на одном проекте мы использовали Django ORM.

На самом деле я слукавил, название должно было быть "Не ORMом единым". Если вам интересно, почему я так написал, а также если:

• У вас в стеке Django, и вам хочется выжать из ORM максимум возможностей, а не просто Model.objects.all(),
• Вы хотите перенести часть бизнес-логики на уровень баз данных,
• Или вы хотите узнать, почему самая частая отмазка разработчиков в B2B.Ostrovok.ru "так исторически сложилось",

… добро пожаловать под кат.

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

Всем привет!

Я работаю тимлидом команды Integration Development в сервисе онлайн-бронирования отелей Ostrovok.ru и сегодня хотел бы поделиться своим опытом работы с различными API.

Как разработчик системы, работающей с внешними поставщиками, я часто встречаюсь с различными API – чаще всего это SOAP/REST или что-то на них похожее. Однако от работы со многими из них остается впечатление, что их писали, не руководствуясь ни техническими правилами, ни здравым смыслом – как будто бы по книге “Вредные советы” Григория Остера. В данной статье я постараюсь описать такие случаи в стиле “вредных советов” и рассмотрю примеры, связанные с XML. Комментарии и обсуждение приветствуются.

Всем привет! Сегодня я расскажу вам историю развития типизации на примере одного из проектов в Ostrovok.ru.



Эта история началась задолго до хайпа о typing в python3.5, более того, она началась внутри проекта, написанного еще на python2.7.

2013 год: совсем недавно был релиз python3.3, мигрировать на новую версию смысла не было, так как каких-то конкретных фичей она не добавляла, а боли и страдания при переходе принесла бы очень много.

Я занимался проектом Partners в Ostrovok.ru – этот сервис отвечал за все, что связано с партнерскими интеграциями, бронированиями, статистикой, личным кабинетом. У нас использовались как внутренние API для других микросервисов компании, так и внешнее API для наших партнеров.

Приветствую, друзья!

В предыдущих двух статьях (раз, два) мы погружались в сложность выбора между технологиями и искали оптимальные настройки для нашего решения в Ostrovok.ru. Какую тему поднимем сегодня?

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

И снова здравствуйте!

В прошлый раз мы рассказывали о выборе инструмента в Ostrovok.ru для решения задачи проксирования большого количества запросов к внешним сервисам, никого при этом не положив. Статья закончилась выбором Haproxy. Сегодня я поделюсь нюансами, с которыми мне пришлось столкнуться при использовании этого решения.

Всем привет!

Сегодня мы хотим рассказать о том, как команда сервиса бронирования отелей Ostrovok.ru решала проблему роста микросервиса, задачей которого является обмен информацией с нашими поставщиками. О своем опыте рассказывает undying, DevOps Team Lead в Ostrovok.ru.

Всем привет. Меня зовут Макс Дегтерев (у меня тут нет аккаунта, так что вот мой twitter: @suprMax и сайт maxdegterev.name ). Мы недавно запустили новую классную версию мобильного сайта. Про него-то я вам сейчас и расскажу.

Привет, хабр!

Мы запустили новую фичу в нашем мобильном приложении — «Отель на ночь!». Это функция, которая помогает человеку забронировать отель в последнюю минуту. Зачем мы это сделали, как и что из этого получилось мы решили рассказать на хабре. Будем рады вашем отзывам и комментариям о том, что можно еще улучшить в новой функции и в целом в приложениях.

В Островке при разработке сайта используется модульная структура. Логические элементы состоят из разметки, стилей и javascript-файлов.

После перехода на такую структуру, пару месяцев все было хорошо. Потом в IE начали пропадать стили из разных блоков, и мы осознали, что столкнулись с проблемой всех крупных проектов – в IE9 и младше не грузится больше 31го css файла разом.

Привет, меня зовут Евгений Селезнев (evgenyseleznev), я дизайнер и руководитель команды мобильной разработки в Островке.

Мы в компании Ostrovok.ru недавно выпустили мобильное приложение для бронирования отелей по всему миру. В нем мы постарались преподнести богатый функционал в удобном интерфейсе. Как был устроен процесс работы, расскажу подробнее.

Привет, меня зовут Игорь (iamo0), я старший фронт-энд разработчик в Островке. Я занимаюсь нашим основным продуктом: сайтом Ostrovok.ru. С помощью нашего сайта ежедневно бронируют отели тысячи человек, поэтому для нас очень важно, чтобы качество нашего продукта было на высоте. А для этого нужно не отвлекаться на разного рода мелочи и уметь эффективно решать поставленные задачи.

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

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

Федя Шумов и Арсений Заречнев, фронт-енд разработчики из команды Островка, рассказали о
«Всей соли одностраничных приложений» на 404fest в Самаре.

Содержание доклада:

Когда я работал над сервисом заметок jotsky.com, еще до работы в Островке, надо было сделать ввод телефонного номера из двух инпутов. Примерно такой:



Я сделал навигацию с помощью стрелочек. Сделал, чтобы по мере заполнения фокус переключался к следующем инпуту. А вот сделать правильную вставку из буфера обмена у меня никак не получалось.

В Островке есть два основных продукта: для пользователей (ostrovok.ru) и «админка» для отелей (экстранет), куда подписанные нами отели заносят данные. Это отдельные продукты, со своими командами и различным отношением к разработке через тестирование (TDD). Одинаковая платформа: django и postgres. В экстранете используют TDD и у них куча тестов. Поначалу тесты были и в ostrovok.ru, но ввиду ухода части адептов в экстранет и очень интенсивного развития их перестали поддерживать. В общем передо мной встала задача внедрить тестирование. Первые шаги сделаны и хочу поделиться этим опытом и решениями, которые были применены.

У нас есть отдел QA и Selenium автотесты, но это отдельно.

С django и тестами вообще дела обстоят довольно хорошо и конечно лучше с самого начала все покрывать тестами, наращивая функционал и делая рефакторинги.

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

С недавнего времени в команде Островка работает Райан, разработчик из Кремниевой долины. Чаще всего его спрашивают, зачем он приехал работать в Россию и как вобще здесь оказался. Он рассказал об этом, о работе в американских стартапах, о работе в Островке, и о том, почему he feels like there is a shift happening in Russia.