Ты немного путаешь. Если твой друг пишет такие мини erp, без знания процесса производства, и не используя это всë самому, это одно. А тут человек для себя написал, под свои задачи и под свои конкретные процессы, и протестировать может эту систему на практике.
Была статья на хабре касаемо данной делемы, называлась вроде "вайбкодим своë приложение", где автор сделал электронный журнал для оценок по экзамену, который каскадно удалял все записи)))
Чаще всего, "переусложненный интерфейс и лишние кнопки", нужны для специфического поведения системы. Вдруг у вас поменяется часть бизнес логики или нужно будет что то настроить, без переписывания всей системы. Этот тейк скорее относится не к жирности erp систем, а к ui дизайну.
Интересное замечание, только почему то вайб кодинг не способен нормально сделать алгоритмы уровня джун+
Был у меня опыт, для проекта нужно было написать алгоритм передачи пароля с нулевым разглашением данных. И в этом момен нейронки воротили костыли, путая версии данного алгоритма, путая клиентские и серверные стороны. И пытаясь доказать мне что у них всë четко а код почему то не работает.
Как итог, около двух суток я пытал модели, по итогу забил и за 3 часа по документациям, написал сам
При всём уважении, грунт для теплоотвода вообще не подойдет, так как нагреется только то место, с которым контактирует горячий элемент/трубы/радиаторы. И как было сказано, из-за низкой теплопроводности грунта, охлаждения как такого не будет.
Есть конечно в этом логика, но вопрос зачем? Так-же стоит учитывать что "сэкономленная" энергия так-же будет потрачена но другими процессами, да и тут так-же стоит вопрос об эффективности, ведь в основном процессорное время и жрет большую часть энергии.
Кэш — палка о двух концах
Память не чиститься просто так, и оперативка работает просто как ловушка для электрона, другие же процессы в операционке резервируют некоторые места под свои задачи, а именно то что определенный процесс будет контактировать именно с этим участком, а после его перезапишет другой процесс, как только область станет доступной. Поправьте меня если я не прав.
UI и графика: экран тоже ест
Ну начнем с того, что да, это ест много энергоресурсов, особенно если есть какие-то анимации или 3д графика. Яркость же одна наверное не самое большое зло, которое могло бы быть, тем более если я условно беру телефон или монитор с 140+ гц.
Насчет того, что в бд хранится хэш, а не пароль, я прекрасно понимаю, так-как сливы базы из-за sql инъекций с нынешними библиотеками маловероятны, но не равны нулю.
Насчет-же преподавателей. Была целая дискуссия между мной и преподавательницей, которая вела у нас проектирование ПО, поэтому я отчетливо запомнил её доводы и предложения. Конечно я могу согласиться с доводами о том что пароль просто так передавать не безопасно по обычному http или при SSL 3.0 и 2.0, TLS 1.1 и 1.0, так как они являются устаревшими
Одно дело читать статьи о том, как там всё "хорошо", другое дело тыкаться самому. По сути аналогия с играми, кто-то летсплеи любит смотреть, кто-то играть
Там еще один из минусов, это то что они идут впаянные в материнку, и от ее характеристик, цена сильно варьируется. А насчет тиража и партий, я не знал, спасибо
Ты немного путаешь. Если твой друг пишет такие мини erp, без знания процесса производства, и не используя это всë самому, это одно. А тут человек для себя написал, под свои задачи и под свои конкретные процессы, и протестировать может эту систему на практике.
Была статья на хабре касаемо данной делемы, называлась вроде "вайбкодим своë приложение", где автор сделал электронный журнал для оценок по экзамену, который каскадно удалял все записи)))
Чаще всего, "переусложненный интерфейс и лишние кнопки", нужны для специфического поведения системы. Вдруг у вас поменяется часть бизнес логики или нужно будет что то настроить, без переписывания всей системы. Этот тейк скорее относится не к жирности erp систем, а к ui дизайну.
Интересное замечание, только почему то вайб кодинг не способен нормально сделать алгоритмы уровня джун+
Был у меня опыт, для проекта нужно было написать алгоритм передачи пароля с нулевым разглашением данных. И в этом момен нейронки воротили костыли, путая версии данного алгоритма, путая клиентские и серверные стороны. И пытаясь доказать мне что у них всë четко а код почему то не работает.
Как итог, около двух суток я пытал модели, по итогу забил и за 3 часа по документациям, написал сам
А что полезного в TT? Вспомнил политику трампа, на возврат ценностей хоть каких то. Ну а эта платформа наоборот повлияла их разложению.
Рутуб только на пиратских видео и живет. Больше в нëм ничего толкового нет
в данном случае, лучший способ протестировать систему - закинуть ее в релиз, и предустановить на все телефоны
Конечно ядерный реактор на луне это круто, но вопрос, а на кой черт это нужно? Каких-то весомых доводов и проектов где это необходимо, я не увидел
При всём уважении, грунт для теплоотвода вообще не подойдет, так как нагреется только то место, с которым контактирует горячий элемент/трубы/радиаторы. И как было сказано, из-за низкой теплопроводности грунта, охлаждения как такого не будет.
Как человек знакомый с данной проблемой, могу посочувствовать, но из названия да и целом, я думал тут будет про фишки завлечения аудитории.
В помощь, могу предложить статью для ознакомления: https://habr.com/ru/articles/908466/
Спорный на самом деле момент, и имеет множество факторов
Эмм, может я что-то не понимаю, но хабр имеет другую наклонность, а именно техническое сообщество. Тут лучше пойти на другую площадку
Есть конечно в этом логика, но вопрос зачем? Так-же стоит учитывать что "сэкономленная" энергия так-же будет потрачена но другими процессами, да и тут так-же стоит вопрос об эффективности, ведь в основном процессорное время и жрет большую часть энергии.
Память не чиститься просто так, и оперативка работает просто как ловушка для электрона, другие же процессы в операционке резервируют некоторые места под свои задачи, а именно то что определенный процесс будет контактировать именно с этим участком, а после его перезапишет другой процесс, как только область станет доступной. Поправьте меня если я не прав.
Ну начнем с того, что да, это ест много энергоресурсов, особенно если есть какие-то анимации или 3д графика. Яркость же одна наверное не самое большое зло, которое могло бы быть, тем более если я условно беру телефон или монитор с 140+ гц.
были телефоны, потом появились смартфоны с функцией телефона, а теперь домофоны с этой функцией)
Насчет того, что в бд хранится хэш, а не пароль, я прекрасно понимаю, так-как сливы базы из-за sql инъекций с нынешними библиотеками маловероятны, но не равны нулю.
Насчет-же преподавателей. Была целая дискуссия между мной и преподавательницей, которая вела у нас проектирование ПО, поэтому я отчетливо запомнил её доводы и предложения. Конечно я могу согласиться с доводами о том что пароль просто так передавать не безопасно по обычному http или при SSL 3.0 и 2.0, TLS 1.1 и 1.0, так как они являются устаревшими
Я не отзываюсь о своих преподах высокомерно в данной статье, хотя это и могло так выглядеть.
Да, я полностью согласен с вашим ходом мысли. Спасибо за указанный недостаток
Спасибо, в следующий раз учту. А статья да, задумывалась как раз для тех кто не знает что такое TLS, и как работает базовая безопасность в вебе
Одно дело читать статьи о том, как там всё "хорошо", другое дело тыкаться самому. По сути аналогия с играми, кто-то летсплеи любит смотреть, кто-то играть
Там еще один из минусов, это то что они идут впаянные в материнку, и от ее характеристик, цена сильно варьируется. А насчет тиража и партий, я не знал, спасибо
Интересно, а каждый год будут "перевыпускать" данную игру и требовать деньги за новую циферку в названии?
Это конечно замечательно, но кто пользуется Эльбрусом с учетом его высокой цены и низкой производительностью?
Я конечно рад, что отечественный IT сегмент пытается развиваться и думал купить себе Эльбрус чтобы потестировать, но не с учетом такой заоблачной цены