Смешно читать длиннющие безапелляционные каменты в полном отрыве от проектов, их жизненных циклов, исполнителей, заказчиков, задач, да и от самой сути и приципов разработки ПО.
Безотносительно блокировки, WhatsApp это ужасный мессенджер, дырявый и гарантировано сливающий инфу, нормальным людям лучше держаться в стороне. Причем об этом известно стало не вчера и не сегодня, достаточно вбить в гугл и увидеть например такое: "19 ноября 2025 Восьмилетняя уязвимость в WhatsApp раскрывала данные 3,5 млрд аккаунтов". И таких новостей, cve вагон и маленькая телега за годы его существования. С таким же успехом можно было оставаться сидеть в ICQ.
Проблема с ИИ фидбэком в том, что он предлагает сделать что-то, но вот причину предлагаемых изменений толком не дает, настроек анализа нет. В более менее сложном коде дает много false positive, не нужных изменений по стилю кода. За ним все надо перепроверять.
Идеальный инструмент для галочки.
В этом ключевое отличие от всяких линтеров и анализаторов кода, где есть настраиваемые правила с подробным описанием.
Если уж делать такое, то надо было инcтрументировать RestTemplate, что уже сделано до нас. И проблема с этой готовой телеметрией такая, что хоть данных и пишется много, а все равно для сколько-нибудь хитрых вещей нужна дополнительная информация, без которой баг сходу не выловить.
Когда надо эти выступления носят излишне критический характер, а когда не надо - все хорошо, просто вы не так пользуетесь. У них было 30 лет подумать, поисправлять, закрыть дыры. Вопросы будут всегда с любой сериализацией, особенно если есть желание посидеть на всех стульях сразу.
В оригинальном каменте речь шла про джаву, виртуальная машина которой действительно может перекомпилировать метод несколько раз, если посчитает нужным. В виртуальную машину(ы) джавы вбухано нереальное количество времени и оптимизаций и этот процесс продолжается, дотнет только-только начал шевелится в этом направлении.
Если ты автор библиотеки или апи, то да, не хочется сюрпризов и хочется пользователей ограничить, в то же время, часто приходится наследоваться для обхода проблем в библиотеках и тогда открытость здорово выручает.
У DevExpress весьма сомнительные решения были (вроде загрузки всех данных в память), не знаю как сейчас. Telerik Reports тоже не лишены недостатков, очень мутный редактор, тормоза на линуксе (может исправили), как мне кажется не стоит своих денег. У NPOI адекватные авторы и вы всегда можете им заслать PR, это немного отстающий клон джавовой POI. Еще одна либа для Excel - EPPlus, платная, обновлять надо аккуратно - часто ломают. Если pdf простой, то и старого itext хватит, QuestPDF тоже ничего. В приципе никто не мешает использовать разор для генерации html и конвертить потом в pdf как тут описано, это может быть удобнее при работе с большим количеством данных.
Гибридный подход говорит о недостатке ресурсов, в то же время о каких-то трудностях нет упоминания, выходит проект был не сложный, ну и без причин перехода трудно что-то обсуждать.
Выглядит как-будто неплохо, но много типов, много конструкторов, в целом выглядит сложно еще до написания кода. Вот зачем отдельный тип ModelSignal, WritableSignal ничем не хуже, почему не протянуть его автоматом?
Форсят реактивные формы (теперь уже сигнальные), для декларативных форм удобства не завезли (есть сигнал со сложным объектом внутри - как раскидать его по writable сигналам на каждое поле?). Я вижу реактивные формы скорее как костыль из-за отсутствия каких-либо механизмов в шаблонах для сигналов или RxJs. А между тем, проблемы с типизацией control value accessor так и не решены, то есть проверка типов в форме не работает, инпут ждет число - мы даем строку и ничего - скомпилируется. А что есть важнее форм в вебе? Далее, ngModel принимает сигнал как функцию, в других местах шаблона надо явно вызывать, странно это, выглядит как-будто компилятор мог бы сам сгенерировать вызов там где надо, а нас избавить от шума скобок. Да и в целом эти модули форм надо бы выкинуть и переписать по-человечески.
Ситуация та же, что и с RxJs, интеграция с фреймворком минимальная, самая базовая. Почти десять лет понадобилось, чтобы в дополненение к async пайпу они добавили такой мизер как let в шаблоны, хотя у них в руках все возможности. В итоге, если кто-то использовал RxJs по максимуму - получал кучу приседаний, бойлерплейт, и вынужден был юзать сторонние либы и странные решения, чтобы как-то с этим бороться.
Взять такую банальную вещь, как ViewChild или сигнал viewChild, почему бы не прокинуть автоматически ссылку в класс компонента в виде поля (причем можно даже понять когда нужен массив), когда в шаблоне проставили # ? Зачем писать этот сигнал или декоратор руками каждый раз, импорты, да еще думать, когда его можно юзать, а когда еще рано? Если надо прям какой-то специфический селектор - тогда только определять руками. Аналогично можно было бы прокидывать эмиттер/сигнал из любого компонента шаблона в класс компонента (ну например #click="loginClick" и все, можно юзать в коде сигнал или емиттер this.loginClick, я даже колхозил нечто подобное, но без поддержки компилятора - не то). Это минус миллиарды строк кода.
Разумеется есть случаи, где надо что-то платформо-специфичное, но 90% прилаг это просто клиент для апишки, что там может быть такого, что прям требует нативности? При этом разработка на флаттере и быстрее и проще.
Просто попробуйте этот текст дать обычному школьнику почитать.
Смешно читать длиннющие безапелляционные каменты в полном отрыве от проектов, их жизненных циклов, исполнителей, заказчиков, задач, да и от самой сути и приципов разработки ПО.
Безотносительно блокировки, WhatsApp это ужасный мессенджер, дырявый и гарантировано сливающий инфу, нормальным людям лучше держаться в стороне. Причем об этом известно стало не вчера и не сегодня, достаточно вбить в гугл и увидеть например такое: "19 ноября 2025 Восьмилетняя уязвимость в WhatsApp раскрывала данные 3,5 млрд аккаунтов". И таких новостей, cve вагон и маленькая телега за годы его существования. С таким же успехом можно было оставаться сидеть в ICQ.
Проблема с ИИ фидбэком в том, что он предлагает сделать что-то, но вот причину предлагаемых изменений толком не дает, настроек анализа нет. В более менее сложном коде дает много false positive, не нужных изменений по стилю кода. За ним все надо перепроверять.
Идеальный инструмент для галочки.
В этом ключевое отличие от всяких линтеров и анализаторов кода, где есть настраиваемые правила с подробным описанием.
Непонятно в чем заключается обработка отчетов.
Это очень удобно, потому что отвязывает от винды при разработке.
Неприятным языком написана статья, пренебрежительно, гаденько.
Если уж делать такое, то надо было инcтрументировать RestTemplate, что уже сделано до нас. И проблема с этой готовой телеметрией такая, что хоть данных и пишется много, а все равно для сколько-нибудь хитрых вещей нужна дополнительная информация, без которой баг сходу не выловить.
Когда надо эти выступления носят излишне критический характер, а когда не надо - все хорошо, просто вы не так пользуетесь. У них было 30 лет подумать, поисправлять, закрыть дыры. Вопросы будут всегда с любой сериализацией, особенно если есть желание посидеть на всех стульях сразу.
В оригинальном каменте речь шла про джаву, виртуальная машина которой действительно может перекомпилировать метод несколько раз, если посчитает нужным. В виртуальную машину(ы) джавы вбухано нереальное количество времени и оптимизаций и этот процесс продолжается, дотнет только-только начал шевелится в этом направлении.
Если ты автор библиотеки или апи, то да, не хочется сюрпризов и хочется пользователей ограничить, в то же время, часто приходится наследоваться для обхода проблем в библиотеках и тогда открытость здорово выручает.
Да, для гита лучше использовать сторонний софт (удивительно конечно, что так плохо сделали в вскоде), например, SourceGit.
Собирал как-то виндовый докер образ - это сплошное мучение и хождение по граблям.
У DevExpress весьма сомнительные решения были (вроде загрузки всех данных в память), не знаю как сейчас. Telerik Reports тоже не лишены недостатков, очень мутный редактор, тормоза на линуксе (может исправили), как мне кажется не стоит своих денег. У NPOI адекватные авторы и вы всегда можете им заслать PR, это немного отстающий клон джавовой POI. Еще одна либа для Excel - EPPlus, платная, обновлять надо аккуратно - часто ломают. Если pdf простой, то и старого itext хватит, QuestPDF тоже ничего. В приципе никто не мешает использовать разор для генерации html и конвертить потом в pdf как тут описано, это может быть удобнее при работе с большим количеством данных.
Текст имеет все признаки гпт (да и код), читать невозможно.
ЗЫ. https://github.com/piotrstenke/Durian
Гибридный подход говорит о недостатке ресурсов, в то же время о каких-то трудностях нет упоминания, выходит проект был не сложный, ну и без причин перехода трудно что-то обсуждать.
Выглядит как-будто неплохо, но много типов, много конструкторов, в целом выглядит сложно еще до написания кода. Вот зачем отдельный тип ModelSignal, WritableSignal ничем не хуже, почему не протянуть его автоматом?
Форсят реактивные формы (теперь уже сигнальные), для декларативных форм удобства не завезли (есть сигнал со сложным объектом внутри - как раскидать его по writable сигналам на каждое поле?). Я вижу реактивные формы скорее как костыль из-за отсутствия каких-либо механизмов в шаблонах для сигналов или RxJs. А между тем, проблемы с типизацией control value accessor так и не решены, то есть проверка типов в форме не работает, инпут ждет число - мы даем строку и ничего - скомпилируется. А что есть важнее форм в вебе? Далее, ngModel принимает сигнал как функцию, в других местах шаблона надо явно вызывать, странно это, выглядит как-будто компилятор мог бы сам сгенерировать вызов там где надо, а нас избавить от шума скобок. Да и в целом эти модули форм надо бы выкинуть и переписать по-человечески.
Ситуация та же, что и с RxJs, интеграция с фреймворком минимальная, самая базовая. Почти десять лет понадобилось, чтобы в дополненение к async пайпу они добавили такой мизер как let в шаблоны, хотя у них в руках все возможности. В итоге, если кто-то использовал RxJs по максимуму - получал кучу приседаний, бойлерплейт, и вынужден был юзать сторонние либы и странные решения, чтобы как-то с этим бороться.
Взять такую банальную вещь, как ViewChild или сигнал viewChild, почему бы не прокинуть автоматически ссылку в класс компонента в виде поля (причем можно даже понять когда нужен массив), когда в шаблоне проставили # ? Зачем писать этот сигнал или декоратор руками каждый раз, импорты, да еще думать, когда его можно юзать, а когда еще рано? Если надо прям какой-то специфический селектор - тогда только определять руками. Аналогично можно было бы прокидывать эмиттер/сигнал из любого компонента шаблона в класс компонента (ну например #click="loginClick" и все, можно юзать в коде сигнал или емиттер this.loginClick, я даже колхозил нечто подобное, но без поддержки компилятора - не то). Это минус миллиарды строк кода.
Разумеется есть случаи, где надо что-то платформо-специфичное, но 90% прилаг это просто клиент для апишки, что там может быть такого, что прям требует нативности? При этом разработка на флаттере и быстрее и проще.
Противоречащий сам себе вывод в конце, кмп это не нативное решение [в смысле платформы].
Алюр под .net сырой и плохо поддерживаемый продукт, а жаль.