Ответ генерируется на основе входа и рандома. Фильтры не идеальны и обходятся промптами. Просто поменяв пару знаков препинания можно получить совершенно другой результат. Поэтому возможно это "сигнал", а возможно просто так рандом лег на промпт. Делать новость на основе одного скрина с реддита это кринж.
Я думаю тут, как и везде, нужно считать. Нужно понимать как именно строить арихтектуру и какие сервисы нужно использовать, чтобы было дешево. Для некоторых типов задач решение может быть крайне не очевидным.
Для сравнения, у моей команды суммарная стоимость на несколько продуктов (prod + dev каждый) выходит около $4k в месяц. У нас не дикий RPS, но сотня тысяч уникальных пользователей в месяц есть. Сравнимо с зарплатой, которую пришлось бы тратить на девопса, чтобы это поддерживать (уж не говоря про то сколько стоило бы само железо).
По моему мнению, serverless выходит дороже только в двух случаях:
Ваш проект настолько маленький, что умещается на одном VPS. Тогда можно просто купить инстанс (или хостить контейнер в Fargate) и это будет дешевле.
Ваш проект настолько большой/высоко нагруженный, что свое железо действительно получается дешевле даже с учетом всех накладных расходов. Но мне кажется, что это прям уровни всяких авито/озонов/и т.д.
Serverless подход (лямбды в облаках) сочетает удобство монолита с масштабируемостью микросервисов (во всяком случае под нагрузки 99% среднестатистических приложений). Видимо люди не доверяют облакам (хотя можно и без вендорлока делать)
Изначально GQL был создан, чтобы минимизировать время рендера веб/мобильных страниц. Подавляющее большинство более-менее сложных и взрослых приложений может делать десятки REST запросов при открытии страницы. Причем часто часть запросов могут выполняться последовательно, ещё больше увеличивая время ожидания. Очевидное решение - просить все данные разом. Реализация подобного подхода через REST потребует делать по эндпоинту на каждый чих и дичайших накладных расходов на поддержку. Поэтому пришли к концепции "пусть сами просят, что им нужно"
Я думаю тут все очень просто. Какие-нибудь мнительные политики внезапно обнаружили, что в ОС, которую используют по всему миру в том числе и в критической инфраструктуре принимают код от каких-то "русских хакеров", которые наверняка конечно же туда встраивают бекдоры.
Сложно ли представить похожую ситуацию в России? Как какой-нибудь росийский депутат внезапно обнаруживает коммиты от украинцев в скрепно-значимом отечественном программном продукте и что за этим последует. Мне очень легко представить. Дураков везде хватает.
Не понимаю к чему вы привели этот пример. Код остался открытым. Доступа никого не лишили.
Еще раз - мейнтейнеры сами решают какие изменения им принимать от сообщества, а какие нет. Те, кого это не устраивает всегда вольны сделать форк и пилить свою версию дальше. Так и работает опен сурс.
А в чем тут противоречие опенсурсу? Код как был открытый, так и есть. Бери и форкай.
Опенсурс это вовсе не значит, что мейнтейнер обязан принимать вклад любых участников и мержить все ПРы. Получается, что десятком человек, от которых принимали стало меньше.
К самому решению конечно вопросы есть, и как новость для хайпа смотрится красиво. Но в реальности, как по мне, никакого эффекта по сути нет. Выглядит как политический ход.
Передать вам эту культуру одной перепиской не получится, если вы не понимаете в чем проблема использовать «50к библиотек для CRUD‑проекта» — ну у вас этой культуры просто нет, что печально.
Я прекрасно понимаю. И именно поэтому я не пользуюсь всякими "генераторми проектов", где какие-то случайные люди решили, что они лучше меня знают, что именно нужно для моего проекта.
По результатам нашей с Вами дискуссии, я еще меньше стал понимать смысл данной статьи. Изначально я предположил, что смысл статьи - помочь начинающим программистами понять, что в больших и сложных фреймворках, которые повсеместно используются, нет никакой магии. Концептуальная идея довольно проста и минимальная реализация показана на примере.
Но Вы переводите разговор в русло производительности, заявляя про ограничения памяти и т.д. В данном контексте видимо идея статьи в том, чтобы переписать все нужные библиотеки самому, выкинув лично Вам ненужый функционал? Очередное устранение "фатального недостатка".
Или вы думаете что все эти библиотеки скачиваются просто так, для коллекции?
Во-первых, не все библиотеки используются в райнтайме и являются частью финального дистрибутива.
Во-вторых, выбор библиотек основывается на требованиях проекта. Есть много случаев, когда память не является ограничивающим фактором.
После чего появился проект Jigsaw (пила), созданный специально для задачи выпиливания всех лишних библиотек из JDK.
А для javascript, Вы не поверите, появились бандлеры с tree shake, которые выпилывают весь неиспользуемый код из финального бандла. Это не мешает Вам считать "60 тысяч библиотек".
Я думал тут статья про когнитивную сложность, к чему эти пассажи про память?
Считать непрямые зависимости не имеет никакого смысла. С таким подходом можно и JDK представить как сотни библиотек (ну а чего, так и есть, просто запакованы в одну большую)
А вы не очень умный: это надо было умудриться процитировать текст со ссылкой на JHipster и не попробовать ее даже открыть )
Исходя из текста, ссылка относится к "шаблону проекта". Не спорю с этим утверждением. Шаблон проекта может занимать и 10 Кб, и 10 Гб - личное дело каждого.
Если же Вы считаете, что результат работы какого-то конкретного генератора проектов = "самый обычный проект", то хотелось бы увидеть какую-то статистику на этот счет.
И даже при таком подходе, sample app по Вашей ссылке не имеет упомянутых "сотен библиотек".
Вывод: Автор пытается словить хайпа на громких утверждениях, которые не может подтвердить.
Ответ генерируется на основе входа и рандома. Фильтры не идеальны и обходятся промптами. Просто поменяв пару знаков препинания можно получить совершенно другой результат. Поэтому возможно это "сигнал", а возможно просто так рандом лег на промпт. Делать новость на основе одного скрина с реддита это кринж.
Вы посмотрели пример того, как высосать статью из пальца
Я думаю тут, как и везде, нужно считать. Нужно понимать как именно строить арихтектуру и какие сервисы нужно использовать, чтобы было дешево. Для некоторых типов задач решение может быть крайне не очевидным.
Для сравнения, у моей команды суммарная стоимость на несколько продуктов (prod + dev каждый) выходит около $4k в месяц. У нас не дикий RPS, но сотня тысяч уникальных пользователей в месяц есть. Сравнимо с зарплатой, которую пришлось бы тратить на девопса, чтобы это поддерживать (уж не говоря про то сколько стоило бы само железо).
По моему мнению, serverless выходит дороже только в двух случаях:
Ваш проект настолько маленький, что умещается на одном VPS. Тогда можно просто купить инстанс (или хостить контейнер в Fargate) и это будет дешевле.
Ваш проект настолько большой/высоко нагруженный, что свое железо действительно получается дешевле даже с учетом всех накладных расходов. Но мне кажется, что это прям уровни всяких авито/озонов/и т.д.
Концептуально так и есть, с некоторыми оговорками (не всегда с нуля/умирает)
Да никакого веселья нету. Подходы те же самые, что и в монолите.
Serverless подход (лямбды в облаках) сочетает удобство монолита с масштабируемостью микросервисов (во всяком случае под нагрузки 99% среднестатистических приложений). Видимо люди не доверяют облакам (хотя можно и без вендорлока делать)
Изначально GQL был создан, чтобы минимизировать время рендера веб/мобильных страниц. Подавляющее большинство более-менее сложных и взрослых приложений может делать десятки REST запросов при открытии страницы. Причем часто часть запросов могут выполняться последовательно, ещё больше увеличивая время ожидания. Очевидное решение - просить все данные разом. Реализация подобного подхода через REST потребует делать по эндпоинту на каждый чих и дичайших накладных расходов на поддержку. Поэтому пришли к концепции "пусть сами просят, что им нужно"
Удобно для работы с paginated response
Я думаю тут все очень просто. Какие-нибудь мнительные политики внезапно обнаружили, что в ОС, которую используют по всему миру в том числе и в критической инфраструктуре принимают код от каких-то "русских хакеров", которые наверняка конечно же туда встраивают бекдоры.
Сложно ли представить похожую ситуацию в России? Как какой-нибудь росийский депутат внезапно обнаруживает коммиты от украинцев в скрепно-значимом отечественном программном продукте и что за этим последует. Мне очень легко представить. Дураков везде хватает.
Не понимаю к чему вы привели этот пример. Код остался открытым. Доступа никого не лишили.
Еще раз - мейнтейнеры сами решают какие изменения им принимать от сообщества, а какие нет. Те, кого это не устраивает всегда вольны сделать форк и пилить свою версию дальше. Так и работает опен сурс.
А в чем тут противоречие опенсурсу? Код как был открытый, так и есть. Бери и форкай.
Опенсурс это вовсе не значит, что мейнтейнер обязан принимать вклад любых участников и мержить все ПРы. Получается, что десятком человек, от которых принимали стало меньше.
К самому решению конечно вопросы есть, и как новость для хайпа смотрится красиво. Но в реальности, как по мне, никакого эффекта по сути нет. Выглядит как политический ход.
Интересно было бы узнать какому % людей вообще ващен startup time браузера. Мой выключается только при перезагрузке ОС.
Зачем в таком случае вообще группы? Просто сделайте несколько окон фаерфокса на разных мониторах.
Группы удобны именно тогда, когда хочется работать с одним окном.
Пробовал как замену хромовы группам, но это не то. Совершенно неудобно табаться между несколькими окнами
Человек работал (на реальной работе!) за 14к в месяц. 10к - это реальные деньги, при таком сравнении.
appflowy.io/
Open-source self-hosted аналог notion'a
Я прекрасно понимаю. И именно поэтому я не пользуюсь всякими "генераторми проектов", где какие-то случайные люди решили, что они лучше меня знают, что именно нужно для моего проекта.
По результатам нашей с Вами дискуссии, я еще меньше стал понимать смысл данной статьи. Изначально я предположил, что смысл статьи - помочь начинающим программистами понять, что в больших и сложных фреймворках, которые повсеместно используются, нет никакой магии. Концептуальная идея довольно проста и минимальная реализация показана на примере.
Но Вы переводите разговор в русло производительности, заявляя про ограничения памяти и т.д. В данном контексте видимо идея статьи в том, чтобы переписать все нужные библиотеки самому, выкинув лично Вам ненужый функционал? Очередное устранение "фатального недостатка".
Во-первых, не все библиотеки используются в райнтайме и являются частью финального дистрибутива.
Во-вторых, выбор библиотек основывается на требованиях проекта. Есть много случаев, когда память не является ограничивающим фактором.
А для javascript, Вы не поверите, появились бандлеры с tree shake, которые выпилывают весь неиспользуемый код из финального бандла. Это не мешает Вам считать "60 тысяч библиотек".
Я думал тут статья про когнитивную сложность, к чему эти пассажи про память?
Считать непрямые зависимости не имеет никакого смысла. С таким подходом можно и JDK представить как сотни библиотек (ну а чего, так и есть, просто запакованы в одну большую)
Исходя из текста, ссылка относится к "шаблону проекта". Не спорю с этим утверждением. Шаблон проекта может занимать и 10 Кб, и 10 Гб - личное дело каждого.
Если же Вы считаете, что результат работы какого-то конкретного генератора проектов = "самый обычный проект", то хотелось бы увидеть какую-то статистику на этот счет.
И даже при таком подходе, sample app по Вашей ссылке не имеет упомянутых "сотен библиотек".
Вывод: Автор пытается словить хайпа на громких утверждениях, которые не может подтвердить.