Когда у вас CSR, вы отдаёте клиенту пустой html. Он вызывает какой-то набор CSS и js. Они вызывают картинки, шрифты, получение каких-то данных от API.
Следовательно вы нагружаете сервер на открытие коннекта под каждый фаил, на всевозможные выборки из БД. Вы тратите время на сетевую передачу. Плюс этот код собственно собирается у клиента.
Как вы думаете, что рендерят все эти люди? Какое-то уникальное, кастомизированное веб приложение или в большинстве случаев это одно и тоже?
Следовательно возникает вопрос - а нафига делать кучу раз то, что можно сделать 1 раз?
На этот вопрос возникает примерно 2 родственных ответа - SSG и SSR.
SSG говорит "возьми все файлы, собери из них готовый HTML и отдай клиенту". Подход особенно хорош, если нет динамики.
SSR делает примерно тоже самое, но обычно там добавляется всё же какие-то запросы к бекенду. Вот, собственно, сервер идёт 1 раз к бекенду, собирает в приложение все возможные запросы (ну, кроме прямых) и точно так же отдаёт потом готовый HTML файл.
Ну, конечно, я упрощаю очень сильно, не вдаюсь в синхронизацию состояний и всё такое, но в любом случае мы занимаем меньше ресурсов на рендеринг (по сути делаем это 1 раз), тратим меньше ресурсов на открытие соединений, передаём меньший объём данных.
На самом деле вторая ассоциация может быть даже не про плащ, а про сорт яблок, по которому компьютер и назвали. Просто потому, что они продаются и в массе люди с ними сталкиваются чаще.
Тут такой вопрос - существует-ли вероятность того, что "белые" имена тупо популярнее? Например Jake это всё ещё производная от Jacob. Данное имя было на 1 месте по популярности в 30 штатах, второе место в 12 штатах и третье место в двух штатах. Ещё в 4х штатах США входит в десятку. Напоминаю, что штатов 50. Плюсуем Австралию, Канаду, Великобританию. Потом добавляем Греков и Евреев, вспоминая, что Яков и прочие это тоже Jacob и тоже Jake как следствие. А значит вероятность нарваться на такое имя ну просто статистически выше и оно выше тупо из-за повальной популярности, независимо от представителей? Например имя Jake весьма популярное на Филиппинах имя. Они уже белые или как?
Т.е. окей, мы ещё как-то можем, наверное, прикинуть, что имя Connor в какой-то мере "белое" (хотя не уверен, что Ирландцы согласятся вписать себя в один ряд с WASP, которых, традиционно и называют "белыми"), но есть предположение, что даже в вашем списке имена крайне трудно идентифицировать однозначно по принадлежности, особенно в нашем мире, где Andre может быть хоть Французом, хоть представителем Южной Америки, хоть чернокожим из Комптона или Outcast или НБА.
Нужно и? В чём проблема их обслуживать? Вам даже не нужно никакой тренированной команды, вам просто надо понять, как работает "модный" инструмент, который на деле уже лет 10 как обыденный. И как работает IaC. А идея там очень простая - мы не ручками делаем окружение, а описываем его в файлике для воспроизводимости. Вы же обновляете систему? Ну вот, там она обновляется так же, только не через команду в консоли, а через команду в файле.
Конечно заменяются. И через Н итераций на паре десятков проектов вы приходите к аду и к необходимости тратить кучу времени на поддержание, к отсутствию идемпотентности и ещё к очень большому количеству проблем.
И да, скрипты можно запускать из putty. Но скрипты из putty это если вы студент или дяденька 40+, который просто не осилил в обучение и устарел лет на 15.
Просто я вам говорю как опытный специалист - все эти штуки, они не просто так получились и чем больше выхотите зарабатывать бабок, тем больше вы задумаетесь об эффективности и надёжности. И поверьте, чем выше уровень, тем меньше баша и putty в ваших проектах. Я бы вообще сказал, что при нормальном развитии баша должно стать 0 какой-то момент. Как и scp, zip и всего прочего хлама, который любят за собой таскать устаревшие, неопытные специалисты.
Я скажу. И мои знакомые тоже говорят. Да, а вы как думали? Это называется нести ответственность. Вообще-то свою неправоту и неудачность идей опытные спецы озвучивают очень часто и это норма. Именно эти люди в глазах казуалв от мира ИТ что-то и переусложняют, так как уже имеют опыт и набитые шишки и понимают, к чему это приводит.
Не знаю, какой безопасник придёт через 3-4 года. У меня таких нет. Я сам приду через 3-4 месяца и буду требовать подтягивать. Вот именно чтобы через 3-4 года это не стало реальной проблемой.
Найти получится даже запросто. Вообще-то \то хороших денег стоит.
Да, перепишут на нуктс, который просто фреймворк над вуе, который живёт, здравствует, активно развивается и на который есть и спецы и спрос.
Да, известны. Потому и говорю - есть опытные спецы, которые уже знают, как это нормально делать, а есть дедуганы, которым сложно и они умеют только трындеть.
Нет, я имею ввиду, что разработчик проверяет функционал без нагрузок, без сетевого взаимодействия, без фаерволов, балансировщиков, WAF и чего угодно ещё. Плюс, скорее все, проверяет ещё и не задумываясь о протоколах, о шифровании траффика и много о чём. Он даже не знает о существовании этих вещей. Его не волнуют очень многие вещи.
Вообще не понимаю, в чём клиника, если есть разница между тем, что у разработчика и тем, что в проде? Это как раз не клиника, это как раз обыденная норма. Разные ОС, разные IDE - это в порядке вещей.
Не очень понятно "ничего сложного" это что? Окей, допустим кубер не нужен (хотя в чём проблема этот сервис запустить как 1-3 воркера в уже существующем?) но в докере в чём проблема? Он просто пакует окружение. Что тут сложного? ОПять же - а почему не ребит, если он уже под рукой и не надо с нуля поднимать?
Люди и сейчас в блокноте пилут, если надо. Вы крайне сильно утрируете и пытаетесь выдавать ложную альтернативу, т.е. только крайностей. Вариантов многим больше.
Есть одна проблема - точность оценки. То, что неопытный или не особо компетентный специалист может считать переусложнением, человек более опытный может считать необходимой нормой, так как видит проблемы, которые возникнут, если не "переусложнять".
Мы все немного ограничены своими рамками и некоторые думают, что если ничего не происходит и идёт по плану, то это норма, а не потому, что кто-то предусмотрел проблемы и принял меры.
Притом это касается не только разработки, это касается очень много чего.
Вопрос в том, кто будет нести ответственность за решения и какие риски. Разработчику в вакууме, который не приносит денег и который, в случае неудачи, просто уволится и пойдёт на другое место работы, очень легко рассуждать о каком-то переусложнении. Вы никогда не увидите что такой человек скажет "я бы л неправ". И когда наступят последствия от его дурацких решений, в эпицентре будут другие люди. Разруливать будут другие и оплачивать будут другие. А разработчик будет и дальше плакаться и кричать о переусложнении и необходимости простых схем, но уже в другом месте. от и всего лишь.
Есть не только стартапы и банки. Стартап, который пилит сервис, однажды может вырасти и таки стать тем, кто уже не может ломать свой продукт по 20 раз в день.
Идея сделать быстро и улучшить выглядит здравой, пока это пет-проект.
По факту же обычно это заканчивается на "сделать быстро", а потом ещё 20 задач "сделать быстро". И на улучшение никто не будет стремиться дать ни денег, ни времени, ни рук. итоге проект может так и остаться сделанным на коленке, когда следующим этапом будет "сделать с нуля, нормально". А это означает, что предыдущая работа, т.е. деньги и время, только в мусорку. И хорошо, когда есть новые деньги и время, но ведь часто бывает так, что люды на сделанном пытаются зарабатывать. А не получается.
Плюс если говорим про API, то там вообще не очень хорошо делать "лучше потом". Просто ломать совместимость потом будет болью.
Как бы, а чего не жить какой-нибудь простой функции, или простому сервису, который не поменял ни логику, ни функциональность? С чего ему, внезапно, отвалится через 2 года?
Ну, кстати вот да. Разработчики часто думают, что код который они запустили у себя, это вот тоже самое, что будет в эксплуатации. Но нет, это ведь не так.
Собственно как раз хорошо, когда продукт, как нечто конечно, формируется всеми, от идей до собственно деплоя, когда сразу все участники могут сказать о возможных проблемах и сразу пустить развитие в нужном направлении. И это не переусложнение, а норма.
Но она не призывает задуматься, а действительно-ли можно было обойтись функцией или нужно было обойтись меньшим числом абстракций и наследований, которые действительно необходимы.
Статья о крайностях, а работа инженера о поиске оптимального варианта.
По ряду причин. Во-первых у вас абстрактный конь в жидком вакууме на ложке, которой нет.
Проекты, они разные и это очевидно. Один начинают писать с нуля сегодня, не зная, что ждёт его в будущем. У другого проекта бекграунд в 20 лет.
Один проект это MVP стартапа, у которого есть только идея, а другой это огромная система по решению всего, что хочет заказчик.
В итоге в одних случаях будет переусложнение по одним пунктам, но в других этого не будет.
Как правило, переусложнение возникает не когда вы на ранних этапах пытаетесь лучше понять продукт, а когда вы "просто делаете". Да и вы оказываетеся в моменте, когда ваш проект это куча кода, сшитого из кучи кусков, притом недокументированного и никто не понимает, как он работает, работает оно так себе, а самое главное - дальше уже просто никак.
И вы с вашим подходом как раз и придёте ко всем описанным вами рискам, примтом гарантировано. В смысле я это буквально кучу раз видел.
То, что у вас описано во "вредителях" это прям то, за что надо бить. Во-первых, с какого перепугу вы обзываете кого-то вредителями?
Во-вторых, почему вы всё пытаетесь подогнать под шаблоны? Технари бывают разными, а если человек закладывает риски, это не значит, что он любит всё переусложнять. Человек может просто неверно рассчитывать риски, это да, но остальное чушь.
То, что вы назвали "грамотным подходом" это как раз и есть вредительство и полная хрень.
Дальше вообще забавно:
РПС может вырасти. Что значит вырасти? Он что, растет внезапно? На сколько он может вырасти. Вы делали проект на коленке дома как стартап, бахнули его в гугл-плей и он взял 200 млн юзеров за 2 недели? С какой вер-стью это случится? Надо ли на такие доли процентов создавать сложные системы, способные держать такие нагрузки? Большинство компаний и команд и 10к РПС видели лишь во снах.
Ну, во-первых то и значит - вырасти. На сколько - да хз. Давайте начнём с вопроса, что у вас вообще за сервис. Абстракции обсуждать смысла нет. Если вам надо отдавать статику для фронта, это один вопрос. Если к вам прилетает POST запрос, который запускает динамику на сервисе, это совершенно другой вопрос и проблема тут не в РПС, к которому вы так привязались, а к утилизации мощностей.
Будут добавлять новые фичи. Я не представляю себе синьера или мидла, которому дадут писать сервисы и фичи и он напишет так, что туда невозможно будет добавить фичу. Какие фичи? Перекрасить кнопку? Поменять название? Или новая фича уровня, вчера это был гугл, а сегодня это стал сайт по приюту для собак?
Вы не представляете, а я представляю. Я такие проекты видел. И то? О чём разговор? О реальности или о ваших фантазиях?
Перекрасить кнопку, серьёзно? Это главное, что знаете в разработке? Это у вас ровень синиора или что? Фичи бывают очень разные и работать они могут очень по разному. Я запросто представляю, как приходится костылить, чтобы реализовать новый функционал.
Если ошибемся придется все переписать. Еще раз, если вам пришлось все переписать, то даже 5 лет проектирования и описание каждой строчки аналитиком и тех. писателем - вас бы не спасло. Я не говорю сразу броситься кодить и собрать непонятно что, грумминг 1-2 часа - это ок, не надо только каждую строчку холиварить и каждый новый сервис гонять через 20 комитетов.
Не очень понятна тяга к утрированию. А вы знаете, что для подумать не обязательно планировать каждую строчку и собирать какие-то комитеты? И да, вообще-то нормальные изначально подходы очень даже спасают от необходимости всё переписывать. Например нормальная архитектура, вместо Feature factory вполне спасают от такого. Я понимаю, что некоторые разработчики видят продукт как просто большой набор фич... Ну, результаты я тоже видел.
В общем, я не знаю, к чему там призывает автор в выводе, я просто вижу, что здесь неопытный специалист пытается делать вид, что он опытный и не понимает последствий тех или иных решений. А так же не понимает, сколько времени и сил (ну и нервов) будет выкинуто на помойку, просто потому, что на ранних этапах было лень что-то продумать и что-то показалось сложным.
Домашняя директория в чистом виде толком ничего не занимает. Цфиры не существенно и растут цифры не из-за ОС.
Swap файл это штука с переменным объёмом и он не связан с ОС и может быть и 0.
Действительно, смысл при сравнении ОС, сравнивать именно ОС?
Если корень занимает 32 и вы возьмёте диск на 32, вы сможете установить и работать это будет. Но вы действительно не получите полноценного именно пользовательского опыта. Но это буде вообще ни разу не проблема ОС или её роста.
Нет, системные требования никогда не берутся из такого рассчёта, так как это просто нелепо.
ОС это ОС. Это базовая штука, со своими требованиями к железу. Если мы сравниваем ОС, то надо сравнивать ОС. Я вообще не понимаю, каким образом вам пришло в голову при сравнении ОС сравнивать допом пакеты ПО. И я не понимаю ваших странных аргументом про 32 ГБ диск. Они настолько очевидно неуместные, что даже странно о них говорить.
Более того, изначально мы говорили о том, что существует некоторое требование, так ещё и рост в процессе. Я ставил вин 7 в 2011 году и прошёл с неё до 2024 и вин 11 все обновления. Я её не вычищал специальным образом и не готовил как-то к жизни. Тем не менее, я привожу пример опровергающий слова автора коммента. Нет, винда не требует 64 ГБ и да, она растёт в процессе. Есть логи, обновления, временные файлы, но даже этот рост в рамках погрешности.
Смотрите, у меня на винде, максбуке и лине везде под системой ССД и везде на 512. Но вот именно что везде разный объём данных и разные программы, кроме ряда пересечений. И везде на этом диске занято примерно 200-250 гб.
Но считать по каталогу Windows как раз очень корректно, ведь автор выше заявил, что именно вниде надо именно 64 ГБ и она растёт. Но ни стим, ни хром, ни телеграм не являются частью винды. Они сделаны не авторами винды. У них свои авторы и всё прочее тоже своё. Т.е. енсли в винде что-то из этого, внезапно, начнёт занимать больше места, то крайне спорный вопрос, стоит-ли считать виновницей винду.
Плюс мы не можем воссоздать полностью аналогичный надор программ. Например на маке у меня нет GeForce Expirience, который не умеет нормально удалять паки старых драйверов после обновления. На линуксе у меня нет League of Legends, каталог которой расползся до 25 гигов за годы, из которых файлы игры это порядка 18. Следовательно в вашей парадигме вы предлагаете приписать винде то, в чём она не виновата.
Как я уже отметил, можно ещё как-то попинать винду за достаточно последственный механизм установки и отслеживания ПО на компе, но остальное это некорректно, в рамках разговора именно про винду.
Не могу оценивать, хорошая она или плохая, но она развивается и многое меняется.
Обновления не такие уж и постоянные. В ubuntu пакеты обновляются чаще. Открыл win 11 - в среднем один пакет обновлений раз в 2 недели. По расходу траффика - тоже как бы нет, обновления не такие уж и большие.
Это бизнес и не более. И производителям это самим выгодно. Что не мешает им делать и продавать ноуты без ОС
Ну, как бы, возьмите десктопную убунту с KDE, ей надо тоже порядка 4 ГБ. ДА и маку. Про 64 не тру - у меня винда древнейшая, не чистая, прямо сейчас каталог Windows занимает 36 ГБ и никуда оно особе не растёт. Я бы скорее отметил слабую систему обновлений, так как основное место занимают все эти пакеты от драйверов, темпы и прочая шляпа
Наверное плохо, что она неотключаемая, но в остальном проблема весьма спорная. Спорно то, что телеметрия вообще проблема.
Лол, ну она всегда была платная и что? Только для не корп юзеров она разовая. Я купил себе ключик году в 2011, когда ещё была 7 и прообновлялся все эти годы. Т.е. тоже такое себе.
Смысл простой - экономить на всех. И на сотрудниках и на налоговой. Не надо платить страховые и налоги? Ещё больше экономят на обслуживании. А ещё от сотрудника проще избавится, не нужна возня и доп выплаты.
Компании уходят в серую не для того, что бы экономя на надоговой отдавать свои деньги наёмникам.
Да и давайте честно, если не считать ОМС и ДМС, человеку выгоднее получать на руки больше денег сейчас, чем ждать мифическую пенсию
Ну, что такое, по вашему, рендеринг?
Грубо скажем, рендеринг это отрисовка страницы.
Когда у вас CSR, вы отдаёте клиенту пустой html. Он вызывает какой-то набор CSS и js. Они вызывают картинки, шрифты, получение каких-то данных от API.
Следовательно вы нагружаете сервер на открытие коннекта под каждый фаил, на всевозможные выборки из БД. Вы тратите время на сетевую передачу. Плюс этот код собственно собирается у клиента.
Как вы думаете, что рендерят все эти люди? Какое-то уникальное, кастомизированное веб приложение или в большинстве случаев это одно и тоже?
Следовательно возникает вопрос - а нафига делать кучу раз то, что можно сделать 1 раз?
На этот вопрос возникает примерно 2 родственных ответа - SSG и SSR.
SSG говорит "возьми все файлы, собери из них готовый HTML и отдай клиенту". Подход особенно хорош, если нет динамики.
SSR делает примерно тоже самое, но обычно там добавляется всё же какие-то запросы к бекенду. Вот, собственно, сервер идёт 1 раз к бекенду, собирает в приложение все возможные запросы (ну, кроме прямых) и точно так же отдаёт потом готовый HTML файл.
Ну, конечно, я упрощаю очень сильно, не вдаюсь в синхронизацию состояний и всё такое, но в любом случае мы занимаем меньше ресурсов на рендеринг (по сути делаем это 1 раз), тратим меньше ресурсов на открытие соединений, передаём меньший объём данных.
На самом деле вторая ассоциация может быть даже не про плащ, а про сорт яблок, по которому компьютер и назвали. Просто потому, что они продаются и в массе люди с ними сталкиваются чаще.
Тут такой вопрос - существует-ли вероятность того, что "белые" имена тупо популярнее? Например Jake это всё ещё производная от Jacob. Данное имя было на 1 месте по популярности в 30 штатах, второе место в 12 штатах и третье место в двух штатах. Ещё в 4х штатах США входит в десятку. Напоминаю, что штатов 50. Плюсуем Австралию, Канаду, Великобританию. Потом добавляем Греков и Евреев, вспоминая, что Яков и прочие это тоже Jacob и тоже Jake как следствие. А значит вероятность нарваться на такое имя ну просто статистически выше и оно выше тупо из-за повальной популярности, независимо от представителей?
Например имя Jake весьма популярное на Филиппинах имя. Они уже белые или как?
Т.е. окей, мы ещё как-то можем, наверное, прикинуть, что имя Connor в какой-то мере "белое" (хотя не уверен, что Ирландцы согласятся вписать себя в один ряд с WASP, которых, традиционно и называют "белыми"), но есть предположение, что даже в вашем списке имена крайне трудно идентифицировать однозначно по принадлежности, особенно в нашем мире, где Andre может быть хоть Французом, хоть представителем Южной Америки, хоть чернокожим из Комптона или Outcast или НБА.
Нужно и? В чём проблема их обслуживать? Вам даже не нужно никакой тренированной команды, вам просто надо понять, как работает "модный" инструмент, который на деле уже лет 10 как обыденный. И как работает IaC. А идея там очень простая - мы не ручками делаем окружение, а описываем его в файлике для воспроизводимости. Вы же обновляете систему? Ну вот, там она обновляется так же, только не через команду в консоли, а через команду в файле.
Конечно заменяются. И через Н итераций на паре десятков проектов вы приходите к аду и к необходимости тратить кучу времени на поддержание, к отсутствию идемпотентности и ещё к очень большому количеству проблем.
И да, скрипты можно запускать из putty. Но скрипты из putty это если вы студент или дяденька 40+, который просто не осилил в обучение и устарел лет на 15.
Просто я вам говорю как опытный специалист - все эти штуки, они не просто так получились и чем больше выхотите зарабатывать бабок, тем больше вы задумаетесь об эффективности и надёжности. И поверьте, чем выше уровень, тем меньше баша и putty в ваших проектах. Я бы вообще сказал, что при нормальном развитии баша должно стать 0 какой-то момент. Как и scp, zip и всего прочего хлама, который любят за собой таскать устаревшие, неопытные специалисты.
Я скажу. И мои знакомые тоже говорят. Да, а вы как думали? Это называется нести ответственность. Вообще-то свою неправоту и неудачность идей опытные спецы озвучивают очень часто и это норма. Именно эти люди в глазах казуалв от мира ИТ что-то и переусложняют, так как уже имеют опыт и набитые шишки и понимают, к чему это приводит.
ДА, разруливать.
С чего бы это? Нет, не случится.
Не знаю, какой безопасник придёт через 3-4 года. У меня таких нет. Я сам приду через 3-4 месяца и буду требовать подтягивать. Вот именно чтобы через 3-4 года это не стало реальной проблемой.
Найти получится даже запросто. Вообще-то \то хороших денег стоит.
Да, перепишут на нуктс, который просто фреймворк над вуе, который живёт, здравствует, активно развивается и на который есть и спецы и спрос.
Да, известны. Потому и говорю - есть опытные спецы, которые уже знают, как это нормально делать, а есть дедуганы, которым сложно и они умеют только трындеть.
Нет, я имею ввиду, что разработчик проверяет функционал без нагрузок, без сетевого взаимодействия, без фаерволов, балансировщиков, WAF и чего угодно ещё. Плюс, скорее все, проверяет ещё и не задумываясь о протоколах, о шифровании траффика и много о чём. Он даже не знает о существовании этих вещей. Его не волнуют очень многие вещи.
Вообще не понимаю, в чём клиника, если есть разница между тем, что у разработчика и тем, что в проде? Это как раз не клиника, это как раз обыденная норма. Разные ОС, разные IDE - это в порядке вещей.
Эм... Сейчас умеют делать просто.
Не очень понятно "ничего сложного" это что? Окей, допустим кубер не нужен (хотя в чём проблема этот сервис запустить как 1-3 воркера в уже существующем?) но в докере в чём проблема? Он просто пакует окружение. Что тут сложного? ОПять же - а почему не ребит, если он уже под рукой и не надо с нуля поднимать?
Люди и сейчас в блокноте пилут, если надо. Вы крайне сильно утрируете и пытаетесь выдавать ложную альтернативу, т.е. только крайностей. Вариантов многим больше.
Есть одна проблема - точность оценки. То, что неопытный или не особо компетентный специалист может считать переусложнением, человек более опытный может считать необходимой нормой, так как видит проблемы, которые возникнут, если не "переусложнять".
Мы все немного ограничены своими рамками и некоторые думают, что если ничего не происходит и идёт по плану, то это норма, а не потому, что кто-то предусмотрел проблемы и принял меры.
Притом это касается не только разработки, это касается очень много чего.
Вопрос в том, кто будет нести ответственность за решения и какие риски. Разработчику в вакууме, который не приносит денег и который, в случае неудачи, просто уволится и пойдёт на другое место работы, очень легко рассуждать о каком-то переусложнении. Вы никогда не увидите что такой человек скажет "я бы л неправ". И когда наступят последствия от его дурацких решений, в эпицентре будут другие люди. Разруливать будут другие и оплачивать будут другие. А разработчик будет и дальше плакаться и кричать о переусложнении и необходимости простых схем, но уже в другом месте. от и всего лишь.
Есть не только стартапы и банки. Стартап, который пилит сервис, однажды может вырасти и таки стать тем, кто уже не может ломать свой продукт по 20 раз в день.
Идея сделать быстро и улучшить выглядит здравой, пока это пет-проект.
По факту же обычно это заканчивается на "сделать быстро", а потом ещё 20 задач "сделать быстро". И на улучшение никто не будет стремиться дать ни денег, ни времени, ни рук. итоге проект может так и остаться сделанным на коленке, когда следующим этапом будет "сделать с нуля, нормально". А это означает, что предыдущая работа, т.е. деньги и время, только в мусорку. И хорошо, когда есть новые деньги и время, но ведь часто бывает так, что люды на сделанном пытаются зарабатывать. А не получается.
Плюс если говорим про API, то там вообще не очень хорошо делать "лучше потом". Просто ломать совместимость потом будет болью.
Как бы, а чего не жить какой-нибудь простой функции, или простому сервису, который не поменял ни логику, ни функциональность? С чего ему, внезапно, отвалится через 2 года?
Ну, кстати вот да. Разработчики часто думают, что код который они запустили у себя, это вот тоже самое, что будет в эксплуатации. Но нет, это ведь не так.
Собственно как раз хорошо, когда продукт, как нечто конечно, формируется всеми, от идей до собственно деплоя, когда сразу все участники могут сказать о возможных проблемах и сразу пустить развитие в нужном направлении. И это не переусложнение, а норма.
Но она не призывает задуматься, а действительно-ли можно было обойтись функцией или нужно было обойтись меньшим числом абстракций и наследований, которые действительно необходимы.
Статья о крайностях, а работа инженера о поиске оптимального варианта.
Почитал и не убедили.
По ряду причин. Во-первых у вас абстрактный конь в жидком вакууме на ложке, которой нет.
Проекты, они разные и это очевидно. Один начинают писать с нуля сегодня, не зная, что ждёт его в будущем. У другого проекта бекграунд в 20 лет.
Один проект это MVP стартапа, у которого есть только идея, а другой это огромная система по решению всего, что хочет заказчик.
В итоге в одних случаях будет переусложнение по одним пунктам, но в других этого не будет.
Как правило, переусложнение возникает не когда вы на ранних этапах пытаетесь лучше понять продукт, а когда вы "просто делаете". Да и вы оказываетеся в моменте, когда ваш проект это куча кода, сшитого из кучи кусков, притом недокументированного и никто не понимает, как он работает, работает оно так себе, а самое главное - дальше уже просто никак.
И вы с вашим подходом как раз и придёте ко всем описанным вами рискам, примтом гарантировано. В смысле я это буквально кучу раз видел.
То, что у вас описано во "вредителях" это прям то, за что надо бить. Во-первых, с какого перепугу вы обзываете кого-то вредителями?
Во-вторых, почему вы всё пытаетесь подогнать под шаблоны? Технари бывают разными, а если человек закладывает риски, это не значит, что он любит всё переусложнять. Человек может просто неверно рассчитывать риски, это да, но остальное чушь.
То, что вы назвали "грамотным подходом" это как раз и есть вредительство и полная хрень.
Дальше вообще забавно:
РПС может вырасти. Что значит вырасти? Он что, растет внезапно? На сколько он может вырасти. Вы делали проект на коленке дома как стартап, бахнули его в гугл-плей и он взял 200 млн юзеров за 2 недели? С какой вер-стью это случится? Надо ли на такие доли процентов создавать сложные системы, способные держать такие нагрузки? Большинство компаний и команд и 10к РПС видели лишь во снах.Ну, во-первых то и значит - вырасти. На сколько - да хз. Давайте начнём с вопроса, что у вас вообще за сервис. Абстракции обсуждать смысла нет. Если вам надо отдавать статику для фронта, это один вопрос. Если к вам прилетает POST запрос, который запускает динамику на сервисе, это совершенно другой вопрос и проблема тут не в РПС, к которому вы так привязались, а к утилизации мощностей.
Будут добавлять новые фичи. Я не представляю себе синьера или мидла, которому дадут писать сервисы и фичи и он напишет так, что туда невозможно будет добавить фичу. Какие фичи? Перекрасить кнопку? Поменять название? Или новая фича уровня, вчера это был гугл, а сегодня это стал сайт по приюту для собак?Вы не представляете, а я представляю. Я такие проекты видел. И то? О чём разговор? О реальности или о ваших фантазиях?
Перекрасить кнопку, серьёзно? Это главное, что знаете в разработке? Это у вас ровень синиора или что? Фичи бывают очень разные и работать они могут очень по разному. Я запросто представляю, как приходится костылить, чтобы реализовать новый функционал.
Если ошибемся придется все переписать. Еще раз, если вам пришлось все переписать, то даже 5 лет проектирования и описание каждой строчки аналитиком и тех. писателем - вас бы не спасло. Я не говорю сразу броситься кодить и собрать непонятно что, грумминг 1-2 часа - это ок, не надо только каждую строчку холиварить и каждый новый сервис гонять через 20 комитетов.Не очень понятна тяга к утрированию. А вы знаете, что для подумать не обязательно планировать каждую строчку и собирать какие-то комитеты? И да, вообще-то нормальные изначально подходы очень даже спасают от необходимости всё переписывать. Например нормальная архитектура, вместо Feature factory вполне спасают от такого. Я понимаю, что некоторые разработчики видят продукт как просто большой набор фич... Ну, результаты я тоже видел.
В общем, я не знаю, к чему там призывает автор в выводе, я просто вижу, что здесь неопытный специалист пытается делать вид, что он опытный и не понимает последствий тех или иных решений. А так же не понимает, сколько времени и сил (ну и нервов) будет выкинуто на помойку, просто потому, что на ранних этапах было лень что-то продумать и что-то показалось сложным.
Домашняя директория в чистом виде толком ничего не занимает. Цфиры не существенно и растут цифры не из-за ОС.
Swap файл это штука с переменным объёмом и он не связан с ОС и может быть и 0.
Действительно, смысл при сравнении ОС, сравнивать именно ОС?
Если корень занимает 32 и вы возьмёте диск на 32, вы сможете установить и работать это будет. Но вы действительно не получите полноценного именно пользовательского опыта. Но это буде вообще ни разу не проблема ОС или её роста.
Нет, системные требования никогда не берутся из такого рассчёта, так как это просто нелепо.
ОС это ОС. Это базовая штука, со своими требованиями к железу. Если мы сравниваем ОС, то надо сравнивать ОС. Я вообще не понимаю, каким образом вам пришло в голову при сравнении ОС сравнивать допом пакеты ПО. И я не понимаю ваших странных аргументом про 32 ГБ диск. Они настолько очевидно неуместные, что даже странно о них говорить.
Более того, изначально мы говорили о том, что существует некоторое требование, так ещё и рост в процессе. Я ставил вин 7 в 2011 году и прошёл с неё до 2024 и вин 11 все обновления. Я её не вычищал специальным образом и не готовил как-то к жизни. Тем не менее, я привожу пример опровергающий слова автора коммента. Нет, винда не требует 64 ГБ и да, она растёт в процессе. Есть логи, обновления, временные файлы, но даже этот рост в рамках погрешности.
Смотрите, у меня на винде, максбуке и лине везде под системой ССД и везде на 512. Но вот именно что везде разный объём данных и разные программы, кроме ряда пересечений. И везде на этом диске занято примерно 200-250 гб.
Но считать по каталогу Windows как раз очень корректно, ведь автор выше заявил, что именно вниде надо именно 64 ГБ и она растёт. Но ни стим, ни хром, ни телеграм не являются частью винды. Они сделаны не авторами винды. У них свои авторы и всё прочее тоже своё. Т.е. енсли в винде что-то из этого, внезапно, начнёт занимать больше места, то крайне спорный вопрос, стоит-ли считать виновницей винду.
Плюс мы не можем воссоздать полностью аналогичный надор программ. Например на маке у меня нет GeForce Expirience, который не умеет нормально удалять паки старых драйверов после обновления. На линуксе у меня нет League of Legends, каталог которой расползся до 25 гигов за годы, из которых файлы игры это порядка 18. Следовательно в вашей парадигме вы предлагаете приписать винде то, в чём она не виновата.
Как я уже отметил, можно ещё как-то попинать винду за достаточно последственный механизм установки и отслеживания ПО на компе, но остальное это некорректно, в рамках разговора именно про винду.
Не могу оценивать, хорошая она или плохая, но она развивается и многое меняется.
Обновления не такие уж и постоянные. В ubuntu пакеты обновляются чаще. Открыл win 11 - в среднем один пакет обновлений раз в 2 недели. По расходу траффика - тоже как бы нет, обновления не такие уж и большие.
Это бизнес и не более. И производителям это самим выгодно. Что не мешает им делать и продавать ноуты без ОС
Ну, как бы, возьмите десктопную убунту с KDE, ей надо тоже порядка 4 ГБ. ДА и маку. Про 64 не тру - у меня винда древнейшая, не чистая, прямо сейчас каталог Windows занимает 36 ГБ и никуда оно особе не растёт. Я бы скорее отметил слабую систему обновлений, так как основное место занимают все эти пакеты от драйверов, темпы и прочая шляпа
Наверное плохо, что она неотключаемая, но в остальном проблема весьма спорная. Спорно то, что телеметрия вообще проблема.
Лол, ну она всегда была платная и что? Только для не корп юзеров она разовая. Я купил себе ключик году в 2011, когда ещё была 7 и прообновлялся все эти годы. Т.е. тоже такое себе.
Только одни вопрос - а зачем для яблок смотреть устаревшую ФС? ОНи уже несколько лет как перешли на APFS
А у нас что, профсоюзы начали работать, а не только собирать мзду и выдавать конфетки детям на НГ?
Смысл простой - экономить на всех. И на сотрудниках и на налоговой. Не надо платить страховые и налоги? Ещё больше экономят на обслуживании. А ещё от сотрудника проще избавится, не нужна возня и доп выплаты.
Компании уходят в серую не для того, что бы экономя на надоговой отдавать свои деньги наёмникам.
Да и давайте честно, если не считать ОМС и ДМС, человеку выгоднее получать на руки больше денег сейчас, чем ждать мифическую пенсию