Wow, мне рассказали, что проект с моей прошлой стажировки всё ещё используют.

Из заметок, рабочее: пока что больше всего бесит, что после каждого вопроса хосту количество вариантов решений увеличивается, а не уменьшается :/
Например: мне надо хранить метрики и я придумываю, надо ли их как-то агрегировать или хранить как есть.
В качестве решающего фактора мы смотрим на количество памяти, которое мы займем за год (и для не агрегированной даты это порядка 1 петабайта, что многовато даже для Гугла).
Так вот, после очередного вопроса выясняется, что, возможно, можно хранить и дату за 3 месяца, а потом и выкидывать, а может, и часть метрик не нужны, и опять ничего непонятно :(

В фитнес центре лежит пачка одноразовых тапочек для душа (вообще, у нас в фитнес центре лежит СТОЛЬКО ВСЕГО для общего пользования, что потом немного грустно приходить в обычные фитнес клубы). В субботу я взяла последнюю пару тапочек. И тут же в голове заговорили суровые российские голоса: "Припаси на потом! Потом не будет!", И я положила эту пару тапочек себе в локер.
Разумеется, в понедельник снова была полная пачка тапочек, а я продолжаю искоренять советские привычки.

Проблемы первого мира:
Мэры Сан Франциско и Маунтин Вью (это всё Силиконовая Долина) в один голос предложили отменить бесплатную еду в больших компаниях (e.g. Гугл и Фб кормят своих сотрудников, а Амазон – нет). Почему? Потому что, по их мнению, это убивает кафешки и продуктовые магазины вокруг офисов, а они хотят живое коммьюнити в городе.
Как предлагается накормить 20к сотрудников Гугла в кафешках вокруг – интересный вопрос, и я не имею на него ответа.

Про налоги.
Два самых важных параграфа из письма от штата Пенсильвания.
Суть: "нам плевать, гражданин вы США или нет, наши налоги мы никому не отдадим".

Привет.
Внезапные новости: нашу команду расформировывают, до конца 2018 года все наши задачи будет выполнять другая команда в Долине, а все наши инженеры сменят команду.
Как это повлияет на меня и мой проект? Судя по планам другой команды, которая забирает наши задачи, мой проект им совершенно не нужен.
Возможности, которые набросали мы с хостом:
1. Остаться и закончить проект, хотя его никто не будет использовать
2. Остаться и помочь команде с передачей задач. Это будет гораздо меньше кода, гораздо больше документации.
3. Пойти в другую команду и сделать маленький проект на 8 недель. Что было бы очень уж грустно, потому что у меня один из самых классных хостов so far.
Проблема ещё в том, что я-то хочу стать с этих стажировок фулл-таймером, а это означает, что у меня должны быть очень хорошие отзывы о моей работе.
Вот такие дела.
Я написала координатору интернских проектов, завтра ещё поговорю с менеджером команды, а потом мне надо будет принять решение.

Разумеется, если вы хотите мне что-то посоветовать, вы можете написать сюда: @Loulett

Спасибо всем, кто мне написал, я в итоге поговорила с менеджером команды, моим бывшим хостом и членом hiring committee.
В результате, я остаюсь в команде и продолжаю делать свой проект.
Почему я остаюсь?
1. Мы всё же нашли юзкейс, когда мой проект может быть полезен.
2. Очень сомнительно, что мне быстро найдутся другая команда и проект (особенно в таком маленьком офисе).
3. То, что действительно важно для конвертации в фулл-таймера - код и отзыв от 2 гуглеров (по этому коду). Уже написанный дизайн док - конечно, круто, но не очень важно. Поэтому переход в другую команду просто сожжёт к чертям эти 4 недели.

При этом из-за премещения продукта часть вещей значительно упростились:
1. Мы больше не будем хранить дату в течении года (видели бы вы выражение лица нашего менеджера, когда я сказала, что мы собираемся съедать петвбайт в год), а в течении 3 месяцев или даже меньше
2. Стало гораздо проще с UI - нам больше не нужен кастомный (с классными фишками для моего хоста), а достаточно просто стандартных дашбордов, которые делаются средствами Гугла гораздо проще.

А ещё я сегодня презентовала дизайн док всей команде. Всё вроде бы окей, на все вопросы ответила, но выяснила, что когда я волнуюсь и говорю на английском, то начинаю ужасно заикаться.

P.S. Ответственная за стажировки ("main point of contact"!) так и не ответила на письмо и на сообщения в чате :(
Придется завтра её ловить лично, потому что это совершенно не дело.

Ну и последнее об этой неприятной ситуации – мне ЛИЧНО написал глава Ads Quality в нашем офисе (Ads Quality – самое большое подразделение в нашем офисе, это оооочень важный человек, у него встречи в 4 слоя и всякое такое), чтобы убедиться, что я не сильно пострадала от этого решения, что со мной всё хорошо, и если нет, то он готов поговорить и помочь.

Это невероятно мило (и очень-очень правильно), по-моему.

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

Поэтому теперь немного и вам расскажу (буду более-менее расплывчата, потому что НДА). Зато будут ПРОБЛЕМЫ и РЕШЕНИЯ, всё как вы просили.
Внутри сервиса, который делает моя команда, нужно рендерить веб странички, и это мы умеем делать. Проблема в том, что иногда страничка рендерится хорошо, а на следующий день уже вылетает по таймауту. Что случилось? Увеличилось количество JS файлов? Или на страничке стали майнить биткоины? Непонятно.
Поэтому мне нужно собирать метаинформацию, которая приходит вместе с отрендереной страничкой, хранить её в датабазе и показывать на дашбордах, это делает дебаггинг рендеринга значительно легче.
Казалось бы, в чём проблема? Взял датабазу, кладешь туда данные, потом с помощью SQL достаешь данные и рисуешь графики.
Проблема в том, что гугловский SQL лучше всего работает с особенным типом файлов. Этот особенный тип файлов можно только создавать и удалять, дописывать в него нельзя.
Ну хорошо, тогда давайте некоторое время хранить данные в памяти, потом разом сохранять файлики, потом к ним обращаться с запросами.
Тут возникает вопрос - а как долго надо хранить данные в памяти? Тут несколько факторов:
1. Чтобы SQL работал быстрее всего, файлы должны быть достаточно большие.
2. Чтобы написать такой большой файл, одному процессу надо писать файл 20 часов.
3. Процессы иногда умирают, поэтому надо бы сохраняться почаще. На всякий случай.
4. При этом, писать на диск надо бы пореже, потому что это дорогая операция.
5. Данные должны быть доступны для SQL через час (требование проекта).
Что-то не сходится, верно? Или надо делать маленькие файлы и страдать от медленных запросов или не выполнять ограничения проекта? Но нет.
Решение такое: полчаса процессы пишут данные себе в память, потом записывают в файл на диск. Поскольку процессов много, то и файлов получилось много, поэтому после этого мы мерджим все файлы и перекладываем в новое хранилище, а вот это хранилище уже доступно для SQL.

"Америка – совершенно религиозная и патриархальная страна. У нас этого совсем не понимают" – Екатерина Шульман.

Вот вам в тему этого высказывания церкви Питтсбурга.

Сложный этический вопрос: если хозяин в моё отсутствие пришел в мою комнату и поставил туда второй вентилятор, то он молодец, что принес вентилятор или не очень молодец, что зашёл в чужую комнату?
Я в смешанных чувствах.