Хабр Курсы для менеджеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 8
Сайт потыкал - типичный нейрослоп. А статья - запрос на Code Review.
Только вы бы свой Claude и просили вам ревью делать.
Ну и на кой продакту System Design? Или теперь продакт + клод = архитект?
Продакту System Design нужен, чтобы понимать ограничения системы, обсуждать с разработчиками варианты решений и учитывать их последствия для продукта. В моём случае это ещё и был этап собеседования, к которому я готовилась. На роль архитектора я не претендую.
В статье я делюсь учебным инструментом, который сделала для себя и судя по добавлению в закладки, возможно, пригодится кому-либо для собеса (на это и была рассчитана статья). Запроса на code review там нет
Моему "нишевому проекту" уже почти 30 лет.
Начинался как "фото-альбом", а привёл к альтернативе Вики-энциклопедиям. Своё устройство каталогизации информации и связей с другой информацией.
Сделал только небольшой пример того, как могла бы выглядеть информация в такой системе
На полноценный пример моих знаний и возможностей не хватило
Много слов на эту тему по ссылке
Так ли я понимаю, что, если обобщить, то смысл в том, что UI адаптируется на какую-то подсекцию/ тему, которая всегда остается на экране? Т.е. как если бы Wikipedia была разделена на миллиард под-сайтов?
упс...
Интересно, а что в моих словах могло привести к подобному выводу???
Вообще-то там много разных "смыслов" и основной в том, что на каждую тему/смысл будет не одна статья, как в Вики, а множество разных источников.
И все "предки" каждой темы будут определять "контекст" её понимания, а "потомки" - объяснять тему/смысл
Что касается оформления - то оно может изменяться под необходимые условия - попробуйте понажимать на "кнопочки" правом верхнем углу и подвигать горизонтальный разделитель экрана
Сам формат тренажёра мне нравится: даже как результат подготовки это хороший способ зафиксировать свои решения, проверить их на прочность и передать следующему человеку уже не просто набор мыслей, а основу, которую можно развивать дальше.
Но на собеседовании я бы начал с вопроса: почему здесь вообще Kafka? Какую именно проблему она решает? Какие гарантии доставки нам нужны? Что произойдёт при повторной доставке? Где и как обеспечивается порядок сообщений? Что будет с сообщением, отправленным из метро без сети? А если пользователь одновременно сидит с телефона и ноутбука? Как синхронизируются прочтение и уведомления?
То есть System Design мессенджера я бы начинал не с Kafka и Cassandra, а с того, что именно мы обещаем пользователю. Где хранится история? Что будет, если телефон утонет? Кто способен прочитать переписку? Совместима ли сегодняшняя модель шифрования с теми требованиями, которые могут появиться завтра?
Дальше медиа: превью, MIME type, докачка, транскодирование, хранение, backup. И пользовательские примитивы тоже часть архитектуры: телеграмовские кружочки стали самостоятельным форматом общения. В нашем независимом мессенджере, разумеется, будут пятиугольнички.
И ещё эксплуатация. Добавление нод, замена упавших серверов, обновления и восстановление должны быть рутинными операциями, а не подвигом дежурного администратора.
Вот после того, как определены гарантии, пользовательские свойства и эксплуатационная модель, уже интересно обсуждать Kafka, Cassandra и остальные прямоугольники.
Я себе такие курсы тоже штампую, но руки не доходят почистить их от нейрослопа. ))) Поэтому пока прячу
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А какое у вас нишевое хобби? Я вот сделала курс по архитектуре мессенджера, пока готовилась к собесу