этому не уделяют никакого внимания в реальных продуктах
Раз комментарий набрал столько лайков – отвечу. Наверное, если бы прям "никакого" – ничего бы не работало вообще. Сложно представить условный Youtube на монолите Ruby on Rails с одной базой на одном сервере.
То же самое касательно любого другого крупного продукта. Оно математически не сходится с этим утверждением.
Просто это все большая и сложная штука. Над каждой штукой работают тысячи людей. Никто не хочет ничего ломать (особенно продукты с гигантским продакшеном, где каждая секунда простоя это потеря денег и репутации). Но при этом что-то где-то иногда ломается. Жизнь такова и больше никакова
Я там постарался себе стрелочками разного цвета время отобразить.
Идея такая: Есть крон-джоба, запускающаяся раз в час в 00 минут, 00 секунд. Она обычно отрабатывает 2 секунды (из головы пример. "Некое незначительное время"), либо мало данных (ночью пришло 1к вместо 100к днем, и быстрее завершаем работу). Сценарий:
.1 Зарезервировали инстанс (например, spot в AWS) .2 Сделали работу .3 Вернули инстанс (освободили ресурсы, не платим за него деньги) .4 Пришел запрос за метриками, инстанса нет (уже)
В случае с Pull если между 1 и 3 происходит мало времени - это проблема. В случае с Push - нет
Ну, то есть больше по конкретным сценариям? Про выбор СУБД не всегда есть даже. Пару примеров:
.1 Web Crawler – вообще про СУБД особо не обсуждалось в нем на практике. Там больше про то, как нагрузку размазать аккуратно .2 Саджест (подсказки поисковая строка) - там Trie, и тоже СУБД не обсуждается.
В общем, делаю пока вывод, что Push/Pull получилось хорошо, но этого мало, и есть запрос больше по кейсам пройтись.
Было бы здорово расширить мысль, чего конкретно не хватает. Я старался подсветить общий подход, и немножко углубился в конкретный пример.
Больше примеров наподобие Push/Pull вроде и не добавит ценности (нуок, понятно, что нужно уметь сравнивать). Сухой список тем – тоже вроде не здорово, такого, полагаю, и так навалом.
В общем, обратная связь приветствуется, может, чего-нибудь допишу еще в другой заход
Могут быть сценарии, когда можно сделать через одно либо через другое. Аналитика / постпроцессинг каких-нибудь заявок в E-commerce.
Да вообще на самом деле много сценариев, когда мы можем данные сразу передать в очередь, либо складывать куда-то в хранилище, и раз в какое-то время придет джоба, чтобы обработать накопившееся (раз в час/раз в день).
Во всяком случае, у меня точно были ситуации, когда я между ними выбирал, и ошибался
С таким майндсетом, к сожалению, далеко не уехать. Можно посмотреть на условную конференцию TED, и вспомнить нелюбимого преподавателя в универе, и сравнить навык подачи информации.
Какой-нибудь ревьюер вас когда-нибудь зарубит, это правда.
Значит ли это, что не стоит развиваться в этом направлении - вопрос хороший
Хотя конечно если не целиться на бигтех, где по 5 техсобесов с хард-задачками, которые надо решить без ошибок за минимальное время
На моем опыте обычно medium дают, либо 1 easy и 1 medium. Хард не припомню даже
Базовый уровень и основные алгоритмы, думаю вполне можно запомнить надолго
Мне кажется это основная польза для человека, который не целится в бигтех. А то, что рука местами не набита – и ладно. Как-то что-то где-то все равно решишь при необходимости
Как это всё совмещать с работой над реальным проектом и каким-то отдыхом после работы - решительно непонятно.
Я, кстати, не знаю, откуда люди берут силы после работы. Я наоборот свеженький с утра делаю что-то для себя, потом работа. Отдыхом так вообще пренебрегать опасное дело
Ну... Я бы тут не согласился. Невозможно находиться всегда на пике формы. Периодически проседать – абсолютно нормально. Перед заходом на цикл собеседований 2-3 недели каждый день нужно порешать, чтобы руку набить. В остальное время можно прокачивать что-нибудь другое
Я говорил о 5-10 минут страданий перед пустым листком и 0 идей. Если даже не появляется мыслей как подступиться к задаче то нет смысла сидеть и страдать 25-30 минут без прогресса. Лучше открыть подсказки, открыть решение, разобрать. В этом был посыл. Я очень много лишнего времени потерял на таком и сил.
Я точно не монстр из видосов, где экран моргает, код появляется огромными кусками за доли секунды и все сразу зелененькое и пройденное.
Но ведь разборы для дейли задач обычно бесплатные и не требуют подписки
Выше тоже про дейли задачи где-то было в комментариях. Решать что-то каждый день != решать только дейли.
Есть замечательный блок "Editorial", там по темам здорово сгруппировано. Отдельно про графы, даже про сортировку неожиданно для меня было интересно (например, Counting Sort). Думаю, что у конкурентов есть похожие штуки. Не хотел бы на конкретной платформе акцентировать
ведь на собеседование в бигтех его не всегда дают и заставляют в обычном блокноте писать
У меня было 6 собеседований в бигтех за последние 2 года. На некоторых был дебаггер, но нужно было прям работающее решение, на некоторых действительно код не запускали. "В обычном блокноте писать" – мне кажется это какая-то старая байка, я ни разу с таким не встречался (хотя тоже слышал).
Это верно. Для реляционных как правило используют B-tree. Из второй ссылки, к слову: "The B-tree generalizes the binary search tree, allowing nodes to have more than two children"
А буквально BST используются в виде красно-черных деревьев.
Ну вот именно. Нет хотя бы зачаточного бизнес-плана на пальцах. Звучит ну очень утопически
Там где есть аудитория – ее можно монетизировать.
В случае с сайтами как правило размещаются рекламные блоки. Тогда за каждый клик администратор сайта получает процент с рекламы. Доход делается за счет большого количества визитов и кликов.
Ну и "продавать" в статье имелось в виду не буквально. Речь про привлечение аудитории. Нужно было в кавычки взять, пожалуй
Так у меня, кстати, не было проблем с Wordpress самим. Ну и да, я бы next.js тоже бы в докер заворачивал ровно по тем же причинам, что и Wordpress завернул :)
Вам бы хватило элементарного шаблона и программы, которая умеет из этого шаблона странички рендерить
Это звучит как CMS :) К тому же поверх описанной функциональности там есть плагины, которые могут быть полезными
У вас докер, база и прочие страшные вещи там, где они вот вообще не нужны
То, что можно было по FTP залить это факт. И в продакшен доехало бы точно быстрее. В то же время мне достаточно сложно НЕ закладывать горизонтальное масштабирование и контейнеризацию, дающих мне больше гибкости в перспективе
Если совсем откровенно – я не верю, что сайт вырастет до таких масштабов, и самым эффективным было бы масштабировать Nginx (потому-что больше 99% запросов – чтение), затем MySQL (вертикально/горизонтально), затем Wordpress. И если бы пришлось решать эту проблему – я был бы вероятнее всего достаточно богат =)
Но все же, если рассуждать, то первый заход был бы такой: сделал бы master ноду для записи, и разливал бы на все secondary (остальные ноды). В лоб – rsync. После изменений в wp-content и доставки файлов на secondary возможно secondary нодам понадобился бы рестарт, тоже решаемо в принципе
классический дедовский «статический хтмл с картинками» тут бы не подошел?
Совсем без CSS не самый привлекательный вариант. В любом случае какие-то шаблоны нужно. В плане удобства написания/добавления формат WYSIWYG достаточно практичен. Сходу видится больше минусов чем плюсов
Отвечу так – при желании рынок можно прожать и без Бигтехов
Раз комментарий набрал столько лайков – отвечу. Наверное, если бы прям "никакого" – ничего бы не работало вообще. Сложно представить условный Youtube на монолите Ruby on Rails с одной базой на одном сервере.
То же самое касательно любого другого крупного продукта. Оно математически не сходится с этим утверждением.
Просто это все большая и сложная штука. Над каждой штукой работают тысячи людей. Никто не хочет ничего ломать (особенно продукты с гигантским продакшеном, где каждая секунда простоя это потеря денег и репутации). Но при этом что-то где-то иногда ломается. Жизнь такова и больше никакова
Про алгоритмы вот тут писал: https://habr.com/ru/articles/980270/
Я как раз сначала хотел покрыть темы подготовки, а затем уже личной историей поделиться. Так что подписывайтесь, ставьте лайк :) Все будет
Я там постарался себе стрелочками разного цвета время отобразить.
Идея такая: Есть крон-джоба, запускающаяся раз в час в 00 минут, 00 секунд. Она обычно отрабатывает 2 секунды (из головы пример. "Некое незначительное время"), либо мало данных (ночью пришло 1к вместо 100к днем, и быстрее завершаем работу). Сценарий:
.1 Зарезервировали инстанс (например, spot в AWS)
.2 Сделали работу
.3 Вернули инстанс (освободили ресурсы, не платим за него деньги)
.4 Пришел запрос за метриками, инстанса нет (уже)
В случае с Pull если между 1 и 3 происходит мало времени - это проблема. В случае с Push - нет
Ну, то есть больше по конкретным сценариям? Про выбор СУБД не всегда есть даже. Пару примеров:
.1 Web Crawler – вообще про СУБД особо не обсуждалось в нем на практике. Там больше про то, как нагрузку размазать аккуратно
.2 Саджест (подсказки поисковая строка) - там Trie, и тоже СУБД не обсуждается.
В общем, делаю пока вывод, что Push/Pull получилось хорошо, но этого мало, и есть запрос больше по кейсам пройтись.
Было бы здорово расширить мысль, чего конкретно не хватает. Я старался подсветить общий подход, и немножко углубился в конкретный пример.
Больше примеров наподобие Push/Pull вроде и не добавит ценности (нуок, понятно, что нужно уметь сравнивать). Сухой список тем – тоже вроде не здорово, такого, полагаю, и так навалом.
В общем, обратная связь приветствуется, может, чего-нибудь допишу еще в другой заход
Могут быть сценарии, когда можно сделать через одно либо через другое. Аналитика / постпроцессинг каких-нибудь заявок в E-commerce.
Да вообще на самом деле много сценариев, когда мы можем данные сразу передать в очередь, либо складывать куда-то в хранилище, и раз в какое-то время придет джоба, чтобы обработать накопившееся (раз в час/раз в день).
Во всяком случае, у меня точно были ситуации, когда я между ними выбирал, и ошибался
С таким майндсетом, к сожалению, далеко не уехать. Можно посмотреть на условную конференцию TED, и вспомнить нелюбимого преподавателя в универе, и сравнить навык подачи информации.
Какой-нибудь ревьюер вас когда-нибудь зарубит, это правда.
Значит ли это, что не стоит развиваться в этом направлении - вопрос хороший
На моем опыте обычно medium дают, либо 1 easy и 1 medium. Хард не припомню даже
Мне кажется это основная польза для человека, который не целится в бигтех. А то, что рука местами не набита – и ладно. Как-то что-то где-то все равно решишь при необходимости
Я, кстати, не знаю, откуда люди берут силы после работы. Я наоборот свеженький с утра делаю что-то для себя, потом работа. Отдыхом так вообще пренебрегать опасное дело
Ну... Я бы тут не согласился. Невозможно находиться всегда на пике формы. Периодически проседать – абсолютно нормально. Перед заходом на цикл собеседований 2-3 недели каждый день нужно порешать, чтобы руку набить. В остальное время можно прокачивать что-нибудь другое
Я говорил о 5-10 минут страданий перед пустым листком и 0 идей. Если даже не появляется мыслей как подступиться к задаче то нет смысла сидеть и страдать 25-30 минут без прогресса. Лучше открыть подсказки, открыть решение, разобрать. В этом был посыл. Я очень много лишнего времени потерял на таком и сил.
Я точно не монстр из видосов, где экран моргает, код появляется огромными кусками за доли секунды и все сразу зелененькое и пройденное.
А вообще спасибо на добром слове :)
Выше тоже про дейли задачи где-то было в комментариях. Решать что-то каждый день != решать только дейли.
Есть замечательный блок "Editorial", там по темам здорово сгруппировано. Отдельно про графы, даже про сортировку неожиданно для меня было интересно (например, Counting Sort). Думаю, что у конкурентов есть похожие штуки. Не хотел бы на конкретной платформе акцентировать
У меня было 6 собеседований в бигтех за последние 2 года. На некоторых был дебаггер, но нужно было прям работающее решение, на некоторых действительно код не запускали. "В обычном блокноте писать" – мне кажется это какая-то старая байка, я ни разу с таким не встречался (хотя тоже слышал).
Это верно. Для реляционных как правило используют B-tree. Из второй ссылки, к слову:
"The B-tree generalizes the binary search tree, allowing nodes to have more than two children"
А буквально BST используются в виде красно-черных деревьев.
Одним из самых первых шагов вкручивал. Пропустил, что убрали
Там где есть аудитория – ее можно монетизировать.
В случае с сайтами как правило размещаются рекламные блоки. Тогда за каждый клик администратор сайта получает процент с рекламы. Доход делается за счет большого количества визитов и кликов.
Ну и "продавать" в статье имелось в виду не буквально. Речь про привлечение аудитории. Нужно было в кавычки взять, пожалуй
Так у меня, кстати, не было проблем с Wordpress самим. Ну и да, я бы next.js тоже бы в докер заворачивал ровно по тем же причинам, что и Wordpress завернул :)
Это звучит как CMS :) К тому же поверх описанной функциональности там есть плагины, которые могут быть полезными
То, что можно было по FTP залить это факт. И в продакшен доехало бы точно быстрее. В то же время мне достаточно сложно НЕ закладывать горизонтальное масштабирование и контейнеризацию, дающих мне больше гибкости в перспективе
Если совсем откровенно – я не верю, что сайт вырастет до таких масштабов, и самым эффективным было бы масштабировать Nginx (потому-что больше 99% запросов – чтение), затем MySQL (вертикально/горизонтально), затем Wordpress. И если бы пришлось решать эту проблему – я был бы вероятнее всего достаточно богат =)
Но все же, если рассуждать, то первый заход был бы такой: сделал бы master ноду для записи, и разливал бы на все secondary (остальные ноды). В лоб –
rsync. После изменений вwp-contentи доставки файлов на secondary возможно secondary нодам понадобился бы рестарт, тоже решаемо в принципеСовсем без CSS не самый привлекательный вариант. В любом случае какие-то шаблоны нужно. В плане удобства написания/добавления формат WYSIWYG достаточно практичен. Сходу видится больше минусов чем плюсов