Исследуй неизведанные пути на О! Хакатоне

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

На О! Хакатоне, который пройдёт с 28 сентября по 5 октября, участников ждут испытания на оригинальных маршрутах по миру тревел-теха и встречи с экспертами. А победители получат призы.

Мы зовём в путь прежде всего Middle-разработчиков на Python и Go, разработчиков на других языках, девопсов, аналитиков, продактов. В путь можно отправиться как в одиночку, так и командой до пяти человек. А если у вас нет команды, но вы хотите сотрудничать на хакатоне с другими специалистами, мы поможем подобрать единомышленников после регистрации.

Участников ждут два трека, два алгоритма, которые необходимо разработать. Один должен менять стоимость бронирования, учитывая влияние на цену ряда факторов — срок до поездки, время года и других. Задача второго — собирать данные о номерах из разных отелей и категоризировать по разным параметрам. Призовой фонд каждого трека — 500 000 рублей, которые поделят три лучших решения. 

Задачи хакатона можно решать в течение всей недели. После эксперты обсудят решение обеих задач с участниками. Мы также сделаем доклад про эволюцию технологий Островка, проведём прожарку резюме и мок-интервью. 

Хотите почувствовать себя первопроходцами? Регистрируйтесь на О! Хакатон до 19 сентября.

Привет, я Иван Елфимов, Developer Advocate в Островке. Расскажу про самые полезные open source решения, которые использую я сам и Команда партнерских интеграций.

• Вообще, трудно назвать не open source решение, которое бы использовал Островок в своей разработке. Используем большей частью опенсорс с подходящими лицензиями.

• Один из самых малоизвестных и узкопрофильных компонентов, который мы используем: django-chronograph. Это приложение, позволяющее запускать management-команды из админки. Эта библиотека давно не поддерживается, поэтому мы форкнули её к себе доработали. Возможно когда-нибудь выложим в Open Source.

• Компания Astral создает (точнее пересоздает) отдельные инструменты для питона на языке Rust, заставляя их работать в разы быстрее. Мы уже начали пользоваться и ruff и uv.

• Личная рекомендация от меня: pre-commit. Инструмент очень мощный и полезный, хотя даже там встречается юмор от разработчиков. К примеру, скрипт проверки кода на случайно оставленный print называется «oops, I print it again!»

• Островок готовит к выпуску свой техрадар. Пока он работает в закрытом режиме только для сотрудников, но в планах вынести его наружу. В техрадаре будет информация о библиотеках, прошедших через тесты команды Островка. Они будут сгруппированы по направлениям (frontend, backend, ios/android, аналитика, QA, devops) и каждая из библиотек будет иметь свою стадию: adopt, trial, assess и hold.

Привет, я Иван Елфимов, Developer Advocate в Ostrovok.ru. Расскажу про наш переход на Django 5.0.

4 марта вышел третий security release, когда мы обычно переходим на новые версии библиотек. Мы были готовы к переходу: проверили на декабрьском 5.0.0. что могло сломаться. Из-за некоторых обновлений нам пришлось менять код:

• Раньше мы использовали nulls_last=False. Теперь nulls_first и nulls_last могут быть True или None, поэтому в некоторых местах вместо значений по умолчанию теперь nulls_last = None:

  - nulls_last = False
  + nulls_last = None
    if ordering_by == OrderingField.FIELD_START_AT:
        nulls_last = True

• В сигналах появился новый тип асинхронных ресиверов  (async_receivers), мы добавили его во вспомогательный класс SignalBlocker, которым временно выключаем сигналы.

• Теперь надо явно указывать USE_TZ = False, но это не проблема, мы не используем таймзоны в нашем сервисе.

• Если после refresh_from_db надо дальше по коду использовать закешированные значения из базы данных, появился такой хак:

my_model_obj._meta.private_fields = []
my_model_obj.refresh_from_db()

Новинка, которой воспользуемся в будущем, — расчетные поля по умолчанию (default) в БД. Есть сценарии, где нужно, чтобы поле по умолчанию было не скаляром, а содержало расчётное значение на основе других полей.