Работа

Около года назад мы с Олей переехали из Москвы в Берлин. В Москве Оля работала на немецкую компанию. Летом 2020 года компания решила закрыть российский офис и Оле предложили релоцироваться в Берлин. Обстоятельства сложились очень удачно: мы давно подумывали попробовать пожить за пределами России, но хотелось чтобы мы оба имели работу. Так как я программист, казалось, что мне найти работу будет проще и мы хотели чтобы сначала работу нашла Оля. В итоге, всё примерно так и сложилось: сначала около трех месяцев после переезда я потратил на подготовку к собеседованиям и около месяца прошло с момента когда я отправил первое резюме до момента когда я получил оффер в компанию своей мечты.

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

Здесь и далее фотографии просто чтобы разбавить рассказ, но к событиям в тексте они имеют косвенное отношение

Задача

Есть консольная команда вида:

./do-something.sh -x 1

Значение аргумента x может меняться в диапазоне от 1 до 30 000. Выполнение команды для одного аргумента занимает от 30 секунд до 15 минут. Нужно максимально быстро выполнить эту команду для заданного диапазона аргументов на N-ядерном сервере максимально используя ресурсы сервера.

Возможные варианты решения

1. Простой цикл от 1 до 30 тысяч с запуском команды на каждой итерации будет использовать только 1 ядро. Это решение неприемлемо: оно будет работать слишком долго и не задействует все доступные ресурсы сервера.
2. Можно вручную разбить диапазон на N частей и запустить N циклов вида:

  for i in `seq 1 1000`
  do
      ./do-something.sh -x $i
  done

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

Перевод статьи Майка Веста An Introduction to Content Security Policy от 15 июня 2012 года. Несмотря на то, что статье уже больше 2 лет, информация все еще актуальна и полезна. Об интересном опыте внедрения CSP в Яндексе можно почитать в этой статье.

Модель безопасности в вебе базируется на политике одинакового источника (same origin policy). Только код сайта https://mybank.com должен иметь доступ к данным https://mybank.com, а https://evil.example.com ни при каких условиях не должен получить такого доступа. Каждый источник остается изолированным от остального веба, что дает разработчикам безопасную песочницу, в которой можно разрабатывать и экспериментровать. Теоретически, это бриллиант без изъяна, но на практике, злоумышленники могут найти способы обойти эту систему.

Например, такие атаки как межсайтовый скриптинг (Cross-site scripting, XSS) позволяют обойти политику одного источника, обманным путем заставив сайт доставить вредоносный код вместе легитимным контентом. Это большая проблема, так как браузеры доверяют всему коду, который показывается на странице, так как он является частью страницы доставленной из доверенного источника. XSS Cheat Sheet — это старый, но весьма актуальный список методов, которые могут быть использованы злоумышленниками для внедрения зловредного кода. Если злоумышленнику успешно удается внедрить любой код в страницу, то игру можно считать оконченной: данные сессии пользователя становятся скомпроментированными и информация, которая должна оставаться в секрете, попадает в руки к Плохим Парням™. Мы, конечно же, хотим предотвратить такую возможность.

Этот туториал освящает один многообещающий механизм защиты, который может значительно снизить риск и вред от XSS-атак в современных браузерах — Content Security Policy (CSP).

Цитата из книги Стива Макконелла "Совершенный код":

Разница между философией «удобства» и философией «интеллектуальной управляемости» сводится к различию между ориентацией на написание программы и ориентацией на ее чтение. Максимизация области видимости может облегчить написание программы, но программу, в которой каждый метод может вызвать любую переменную в любой момент времени, сложнее понять, чем код, основанный на грамотно организованных методах. Сделав данные глобальными, вы не сможете ограничиться пониманием работы одного метода: вы должны будете понимать работу всех других методов, которые вместе с ним используют те же глобальные данные. Подобные программы сложно читать, сложно отлаживать и сложно изменять.