Проблемы, из которых состоят дизайн-секции, можно встретить в любом проекте, который не помещается на одной машине. Когда это уже существующая система в большой компании, там будут и специально обученные люди, и дизайн-ревью, и все такое, но когда дело происходит в стартапе из 0.5 человек, или просто в новом экспериментальном проекте, все не так радужно. Самое интересное происходит в тот момент, когда мечты сбываются, и приходит миллион юзеров. Если система была спроектирована хорошо, то в нее можно насыпать еще 10^n машин и она продолжит работать и радовать пользователей, а если нет, то окажется, что нужно «срочно переписывать мультиплеер» и на это нужен месяц и тд. Пользователи при этом не будут ждать, пока вы прочитаете нужные книжки и сделаете все как надо. Собственно умение проектировать системы, которые не разваливаются под нагрузкой, проверяется на дизайн секции :)
В большой живой системе будет нечто среднее. Несколько наводящих вопросов:
1. Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени? Сколько может жить закэшированная версия? Какие события приводят к обновлению ленты?
2. Сколько места нам потребуется, чтобы хранить заранее вычисленные ленты для всех пользователей? Нужно ли нам хранить всю ленту? Для каких пользователей ленту можно не хранить?
3. Что делать с юзерами, которые подписаны на 10^n других юзеров? Что делать с Ким Кардашьян?
Часть ответов на эти вопросы можно найти в видео про twitter.
До «тренировочного лагеря» я бы оценил success rate процентов в 80%, после него у меня было не так много секций, но все прошли очень удачно. Собеседовался в G и F. А сейчас я пойду погуглю эти новый буквы после FAANG.
Мне кажется за работу в таком режиме нужно или получать яхты, усыпанные кокаином (условно), или есть большой риск за полгода-год выгореть так, что потом придется еще довольно долго читать душеспасительные книжки и кушать таблетки.
Не знаю, как в этом смысле дела обстоят у других участников команды, но я стараюсь организовать время так, чтобы каждый день у меня был буфер из 2-3 часов, когда можно поиграть в Ведьмака, посмотреть какие-нибудь лекции, попрогать в свое удовольствие. В течение двух недель пока шел джем, я полностью расходовал этот буффер на разработку игры. Надо сказать, что производительность на работе в это время даже возросла. Совет про совмещение приятного с полезным видимо возник не просто так )
Если хочется С++, можно скачать голый Cocos2d-x и писать на нем. Документации на самом деле хватает, но даже если бы ее не было вообще, в кокосе есть тесты. Там можно увидеть все-все возможности и фишки, которые есть в движке.
1. Сколько времени юзеру придется ждать, если его лента будет строиться каждый раз в реальном времени? Сколько может жить закэшированная версия? Какие события приводят к обновлению ленты?
2. Сколько места нам потребуется, чтобы хранить заранее вычисленные ленты для всех пользователей? Нужно ли нам хранить всю ленту? Для каких пользователей ленту можно не хранить?
3. Что делать с юзерами, которые подписаны на 10^n других юзеров? Что делать с Ким Кардашьян?
Часть ответов на эти вопросы можно найти в видео про twitter.
export DYLD_LIBRARY_PATH=PATH_TO_LIBOMP/libomp/exports/mac_32e/lib/:$DYLD_LIBRARY_PATH
Не знаю, как в этом смысле дела обстоят у других участников команды, но я стараюсь организовать время так, чтобы каждый день у меня был буфер из 2-3 часов, когда можно поиграть в Ведьмака, посмотреть какие-нибудь лекции, попрогать в свое удовольствие. В течение двух недель пока шел джем, я полностью расходовал этот буффер на разработку игры. Надо сказать, что производительность на работе в это время даже возросла. Совет про совмещение приятного с полезным видимо возник не просто так )