Catputer

Уже пару месяцев я работаю в Facebook — думаю, пришло время рассказать о том, что я тут забыл и чем занимаюсь. И, в целом, начать писать в блог чаще!

Facebook Audience Network занимается рекламой вне Facebook Family of Apps (Facebook, Instagram, WhatsApp, Messenger), то есть рекламодатели, используя интерфейс Facebook-a, могут создавать рекламу на сторонних сайтах и приложениях. Зачем это надо и почему бы не обращаться напрямую к создателям приложений или использовать какие-то другие сервисы наподобие рекламы от Google? Все дело в таргетинге: можно показывать релевантную рекламу пользователям Facebook-a вне самого Facebook-a, тем самым повышая клики или конверсию.

Я работаю в команде, которая делает bidding. Из предыдущего параграфа появляется закономерный вопрос: какую рекламу показывать в приложении, если его юзер не пользуется Facebook-ом? Вы, как владелец приложения, предпочли бы, чтобы реклама показывалась вообще всем пользователям, будь они зарегистрированы в Facebook, Twitter, любой другой социальной сети или просто если пользуются поиском Google. В конце-концов, от этого зависят ваши доходы! Тут в дело вступают сервисы медиации рекламы: они объединяют рекламные сети и показывают юзерам только самую выгодную рекламу для владельцев приложений. Как они это делают? Методом аукциона (bidding), как описано по ссылке выше. Facebook, Twitter, Google и остальные получают предложение от сервиса медиации о том, что появилось место для рекламы. Каждый из этих сервисов делает ставку: сколько он готов заплатить за этом рекламное место. Тот, кто сделает самую ставку, получает это место. Моя команда делает примерно это — интеграция с сервисами медиации, работа с создателями приложений и все в таком духе.

Вышло немного больше, чем я планировал, и пост превратился в обзор AdTech индустрии, но надеюсь вам было полезно. Думаю, начать серию постов каждую неделю или две о моей работе под тэгом #работаFacebook. Постараюсь не нарушать NDA, но в то же время рассказывать какие-то полезные вещи, которые узнал на работе. Примерно такую серию постов я уже делал когда стажировался до этого — можно почитать посты под тэгами ​#стажировкаGoogle и #стажировкаBloomberg. Как вам идейка? Wikipedia Real-time bidding means by which advertising inventory is bought and sold on a per-impression basis, via programmatic instantaneous auction

1.3K 16:29

#работаFacebook

В комментариях к предыдущему посту огромное количество людей (нет) спросило меня, какие команды есть в Лондонском офисе Facebook. Поэтому вот их шортлист! Команды я подсмотрел на официальном сайте вакансий компании, сравнивая со своим опытом Bootcamp. Почти все команды пишут в основном на Hack и JavaScript, если я не упомянул обратное.

Community Integrity. Команда занимается защитой community Facebook-а от вредоносного контента. Спам, обнаженка, кража личности и прочие непотребства удаляются разными способами именно этой командой. Очень много человек работают над этим в Лондоне, одна из самых больших команд.

Ads and Business. Тоже одна из больших команд в Лондонском офисе. Помните недавнее обновление Instagram? Там добавили страничку Shops — ее делают в этой команде. Плюс, тут делают рекламу (как понятно из названия), и я работаю здесь. Эта команда и раньше была большой, но недавно Facebook приоритезировал онлайн-торговлю, так что и сама команда сильно выросла.

Workplace. Это корпоративный продукт компании — корпоративная социальная сеть для enterprise. Каждая компания покупая этот продукт, покупает для своих работников отдельную социальную сеть, чтобы они могли общаться. Мы в Facebook используем ее, и мне нравится: очень напоминает саму соц сеть Facebook.

WhatsApp. Скорее всего, вы слышали об этом мессенджере. Несколько команд находятся в Лондоне. А еще они пишут на Erlang, так что если вам нравится функциональное программирование, то смело сюда!

AR/VR/Portal. Есть несколько команд в этой области, включая Infrastructure. Команды Oculus я не встречал, зато есть Spark AR (это которые занимаются масками в Instagram) и Portal (новое hardware решение от Facebook для удаленного общения). Кодят в основном на С++ (куда тут без него!).

Infra. Последний в списке, но не по значению, я поставил Infrastructure команды. Они занимаются почти всем, что не видят обычные пользователи Facebook. Тулзы для разрабов? Оркестрация серверов? Деплой приложений? Это все делают команды infrastructure. Соответственно и языки они используют очень разные: классические Hack и Javascript, C++, Python и даже Haskell!

Напомню, что это только шортлист лондонских команд. Я выбрал только самые большие. На самом деле их очень много. К тому же, есть много команд, поделенных между офисами в США и Лондоне.

Для работников Facebook: список я составлял основываясь на публичной информации, доступной в поиске Google, но если я случайно добавил что-то внутреннее, то feel free to ping me 😄

Скиньте этот список друзьям: может они загорятся идеей податься в Facebook!

Обсуждение в комментариях только приветствуется!👇 Markman on Tech Best New Online Retailer Might be Facebook Latest acquisition shows that investors should switch out to resurgent social media giant as its retail business explodes.

1.1K 12:53

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

https://istories.media/investigations/2020/12/07/kirill-i-katya-lyubov-razluka-ofshori-i-neogranichennii-resurs-istoriya-samoi-tainoi-pari-rossii/ istories.media Кирилл и Катя: любовь, разлука, офшоры и неограниченный ресурс. История самой тайной пары России Журналисты «Важных историй» изучили переписку зятя и дочери Владимира Путина и узнали, как члены семьи президента зарабатывали сотни миллионов долларов из воздуха, тратили состояние на роскошный быт за границей и использовали свои связи с высшим руководством…

1.2K 15:56

Я импульсивно купил в черную пятницу кольцевую лампу и небольшой микрофон. Почему бы не воспользоваться ими и не провести стрим в ближайшую неделю? Что думаете?

1.1K 19:24

А еще можете оставлять предложения по темам стрима в комментариях к этому посту 😉

1.2K 19:24

Завтра в 9 вечера по Астане я проведу стрим со своим другом Анваром Умаровым(@arpychan). Поговорим о кибербезопасности, блокировках и интернете. Анвар контрибьютил в организацию Internet Freedom (@internetfreedomkz). Это чуть ли не единственная организация в Казахстане, которая борется за свободный Интернет. Вместе с ним мы разберемся в том, что же происходит с блокировками, что такое сертификат безопасности, разберем его интервью для одного крупного телеканала, и как государство влияет на наш доступ в интернет. И все это понятным языком. Подключайтесь - будет интересно!

YouTube (можете поставить напоминалку): https://youtu.be/XMG1H-Omx2M
Twitch: https://www.twitch.tv/tg_catputer YouTube #1 КИБЕРБЕЗОПАСНОСТЬ, БЛОКИРОВКИ И ИНТЕРНЕТ: СТРИМ С АНВАРОМ УМАРОВЫМ Поговорим о блокировках интернета. Как они работают в Казахстане, какие есть методы их обхода, и как государство не хочет терять контроль над интернетом. И поговорим о сертификате безопасности конечно же!

2.0K 15:08

❗️Начинаем через 5 минут❗️

1.4K 14:55

#работаFacebook

Мой первый oncall был на прошлой неделе! Это что-то наподобие дежурства, когда ты следишь за тем, чтобы системы работали исправно. После опыта в Google и Facebook я заметил, что у них совершенно отличаются подходы к этому. В Google есть специальные инженеры (Site Reliability Engineers), в обязанность которых входит в том числе и oncall. SRE не разрабатывают приложения, а скорее обязуются поддерживать уже разработанное. То есть по сути за oncall приложения отвечают совсем не те люди, которые его разрабатывают. В Facebook же разработчики участвуют в oncall своего приложения и не делегируют его посторонним. Как по мне, это заставляет людей стараться «не лажать», т.к. в случае чего за это придется расплачиваться всей команде.

Что вы думаете об oncall? Подход какой компании вам нравится больше?

1.1K 20:00

#работаFacebook

Facebook уже вторая компания, в которой я работаю, где я сталкиваюсь с такой вещью, как feature flags (toggles, switches). Предыдущая была Bloomberg, думаю, в Google они тоже есть, просто я был в SRE.

Что же такое feature flags? Если коротко, то это переменная, которая контролирует включение или выключение той или иной фичи в коде. Выглядит это примерно так: if(flag) {/* do new feature */} . Значение этого флага может контролироваться разными способами, но обычно это делается централизованно: есть какой-то отдельный сервер, который возвращает эти флаги. Выглядит просто, но в действительности это очень мощная DevOps практика, которая помогает вам пушить код в продакшн с меньшими рисками. Для примера, представим, что вы хотите сделать редизайн своего сайта. Для этого вам нужно поменять дизайн множества страничек, компонентов и прочих атрибутов. Как вы поступите? Вы можете сделать все одним коммитом на 10К+ строк кода и запушить все в продакшн. Если что-то сломается, то вам или сис. админу придется откатывать этот коммит на сервере или же экстренно искать ошибку в коде. Стресс, стресс, стресс. С другой стороны, можно было бы воспользоваться feature flag-ами: делать все маленькими, digestible коммитами, которым реально провести нормальный code review, попутно покрывая каждый кусок нового кода флагом и используя старый код, если флаг выключен. Как только придет час X, то весь этот код можно просто включить нажатием одной кнопки, сделав тем самым релиз. Если же что-то пойдет не так, то фичу достаточно просто выключить, а дебажить можно будет уже потом. Плюсы feature флагов не ограничиваются только удобством релиза новых фич - их также можно использовать с A/B тестированием. То есть можно пилить фичи и сражу же замерять impact твоего кода на разные бизнес-метрики!

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

Резюмируя, feature флаги очень мощная штука если вы хотите иметь возможность деплоить быстро и без проблем код, у которого уже есть множество юзеров. С другой стороны, если вы стартап на стадии создания MVP/прототипа, то feature флаги только затормозят процесс разработки. Это в принципе объясняет, почему я не сталкивался с ними в Казахстане, потому что работал только в стартапах.

А как вы деплоите в продакшн? Используете ли feature флаги? В какой компании/проекте? Пишите в комментариях к этому посту!

635 16:14