План и является способом формализовать то, как нейронка планирует разбить задачу (“что”) на шаги (“как”). Этот план - не ваша интенция, а её, как она поняла задачу. Тот же Cursor из коробки рисует как высокоуровневые схемы, так и указывает на изменениях в конкретных файлах. Детализацией плана вы вольны управлять.
Ультимативную защиту с одними лишь планами не обещаю, но перехватывать подозрительные действия “дурака” - чем раньше, тем лучше.
Режим полезен тем, что вы заранее видите, что собирается делать агент. И гипотезы будут проверяться согласно плану. Если чеклист не прошел - результаты на столе, план корректируется - идем дальше.
Да, вычитывать план - это не вайбово, но определённости будет больше и обратной связью нейроразведчика отлаживаются сами требования.
А ведь весь этот функионал уже есть в других инструментах. Может таки делать развернутые коммит-месседжи и выдать нейронке доступ на чтение в таск-треккере? И поддерждивать разнородных журналов меньше придется, и появится дополнительный стимул подробно документировать этапы работы.
Да и нефункциональные требования могут накладывать отпечаток: описывая развесистые системы неплохо бы понимать, какие технические подробности можно опустить на этом уровне абстракции, а какие - критичны с точки зрения понимания бизнеса и их нужно тащить наверх. В коде этой информации взяться неоткуда.
Пока проект работает сколь либо похоже на DDD - это может работать. Но если логические модели бизнес-процессов разъезжаются с техническими моделями, делая последние однобокими проекциями первых, то тут нейронки разве что галлюцинациями помогут.
Например: не самая простая система, которая позволяет много вольностей по “поломке” данных (нарушения инвариантов) в угоду гибкости разруливания нестандартных ситуаций (aka впихивание невпихуемого и натягивание реальных земных сов на идеальные лунные глобусы), в расчете на опытного оператора, который знает, за какие ручки в какой ситуации дёргать => добрая часть бизнес-правил стандартного/штатного флоу в коде не отражается. Если бизнес жопится на общую описательную документацию, то и на полновесные e2e, требующие активной поддержки, расчитывать не приходится.
Изученный чужой опыт - тоже опыт. Чем больше насмотренность по проектам, по их проблемам и способам их решений, тем больше личный багаж шаблонов SD. Другое дело, что не в каждом проекте найдутся сложные нефункциональные требования, вроде нагрузок и высокой доступности. Не каждый стартап доживет и переживет масштабирование, поэтому тут скорее путь в бигтехи с налаженными процессами с работой за опыт или в теорию - доклады с конференций и профильная литература, вроде книги с кабаном.
Операционная система - это вообще история про монопольный контроль ресурсов, разного рода изоляции, абастракции и прочие рантаймовые проверки. Эти вещи почти всегда оплачиваются производительностью, в сравнении с программированием на голом железе.
Согласен, технически возможность создавать потоки действительно есть, но там же будут разные рантаймы, общей памяти ни у потоков, ни у корутин все равно нет - нельзя передавать ссылки на объекты между потоками.
View в MVC - это презентационный слой для данных, визуальным он может быть, но не обязан. REST API своему клиенту могут презентовать данные в виде JSON - фронтенду или другому (микро)сервису. Визуализируются они дальше или нет - не важно.
В ASP.NET Core средства создания REST API лежат в сборке Microsoft.AspNetCore.Mvc.Core, поэтому логично было бы считать их частью ASP.NET Core MVC-сабфреймворка. Раньше этому у MS было отдельное название - Web API, а сейчас в документации скупое Controller-based APIs.
Это значит, что ASP и ASP.NET - разные технологии. Ссылку я привел выше.
У актуального дотнета уже несколько лет нет слова Core в названии
У дотнета - уже нет, а у библиотек и фреймворков - так и осталось. ASP.NET Core, EF Core и т.п.
У MS всю дорогу проблемы с неймингом =3
MVC - это шаблон проектирования Model-View-Controller, и я затрудняюсь представить, кто и как пишет с его помощью микросервисы.
В чем именно тут затруднение? Микросервисы накладывают ограничения на архитектурные паттерны? Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?
ASP, еще до дотнета который? Нет, речь идет об актуальном ASP.NET Core MVC, хотя автор в посте по почему-то отбросил слово "Core", но из контекста понятно, что речь идет не про оригинальный ASP.NET MVC под .NET Framework.
План и является способом формализовать то, как нейронка планирует разбить задачу (“что”) на шаги (“как”). Этот план - не ваша интенция, а её, как она поняла задачу. Тот же Cursor из коробки рисует как высокоуровневые схемы, так и указывает на изменениях в конкретных файлах. Детализацией плана вы вольны управлять.
Ультимативную защиту с одними лишь планами не обещаю, но перехватывать подозрительные действия “дурака” - чем раньше, тем лучше.
Режим полезен тем, что вы заранее видите, что собирается делать агент. И гипотезы будут проверяться согласно плану. Если чеклист не прошел - результаты на столе, план корректируется - идем дальше.
Да, вычитывать план - это не вайбово, но определённости будет больше и обратной связью нейроразведчика отлаживаются сами требования.
Полезно активнее пользоваться Plan mode, чтобы бороться с причиной, а не последствиями.
В стоимости токенов, там прогресс разительнее всего.
А ведь весь этот функионал уже есть в других инструментах. Может таки делать развернутые коммит-месседжи и выдать нейронке доступ на чтение в таск-треккере? И поддерждивать разнородных журналов меньше придется, и появится дополнительный стимул подробно документировать этапы работы.
JS - это просто целевая платформа для TS =3 Львиная часть семантики типов никак не маппится на JS, поэтому линтить там нечего.
Да и нефункциональные требования могут накладывать отпечаток: описывая развесистые системы неплохо бы понимать, какие технические подробности можно опустить на этом уровне абстракции, а какие - критичны с точки зрения понимания бизнеса и их нужно тащить наверх. В коде этой информации взяться неоткуда.
Пока проект работает сколь либо похоже на DDD - это может работать. Но если логические модели бизнес-процессов разъезжаются с техническими моделями, делая последние однобокими проекциями первых, то тут нейронки разве что галлюцинациями помогут.
Например: не самая простая система, которая позволяет много вольностей по “поломке” данных (нарушения инвариантов) в угоду гибкости разруливания нестандартных ситуаций (aka впихивание невпихуемого и натягивание реальных земных сов на идеальные лунные глобусы), в расчете на опытного оператора, который знает, за какие ручки в какой ситуации дёргать => добрая часть бизнес-правил стандартного/штатного флоу в коде не отражается. Если бизнес жопится на общую описательную документацию, то и на полновесные e2e, требующие активной поддержки, расчитывать не приходится.
Всё, что нужно знать о надежности рандомных сервисов в интернете)
Наоборот же: отделена логика инициализации состояния объекта в конструкторе, а описание функций - вынесено отдельно.
Не вижу использования свойства
prototypeв примере с функцией-конструктором, это ведь не эквивалентный код.Бонус - это синтаксис, а сами аксессоры можно добавлять через
Object.defineProperty.Изученный чужой опыт - тоже опыт. Чем больше насмотренность по проектам, по их проблемам и способам их решений, тем больше личный багаж шаблонов SD. Другое дело, что не в каждом проекте найдутся сложные нефункциональные требования, вроде нагрузок и высокой доступности. Не каждый стартап доживет и переживет масштабирование, поэтому тут скорее путь в бигтехи с налаженными процессами с работой за опыт или в теорию - доклады с конференций и профильная литература, вроде книги с кабаном.
Операционная система - это вообще история про монопольный контроль ресурсов, разного рода изоляции, абастракции и прочие рантаймовые проверки. Эти вещи почти всегда оплачиваются производительностью, в сравнении с программированием на голом железе.
За счет чего операционка должна ускоряться от версии к версии?
Зумеры изобрели Dial-up?😁
Согласен, технически возможность создавать потоки действительно есть, но там же будут разные рантаймы, общей памяти ни у потоков, ни у корутин все равно нет - нельзя передавать ссылки на объекты между потоками.
Там же по факту костыли на многопроцессносности, а не многопоточность. Нет возможности прямо в том же процессе сделать поток и управлять им.
Бойан
View в MVC - это презентационный слой для данных, визуальным он может быть, но не обязан. REST API своему клиенту могут презентовать данные в виде JSON - фронтенду или другому (микро)сервису. Визуализируются они дальше или нет - не важно.
В ASP.NET Core средства создания REST API лежат в сборке
Microsoft.AspNetCore.Mvc.Core, поэтому логично было бы считать их частью ASP.NET Core MVC-сабфреймворка. Раньше этому у MS было отдельное название - Web API, а сейчас в документации скупое Controller-based APIs.Это значит, что ASP и ASP.NET - разные технологии. Ссылку я привел выше.
У дотнета - уже нет, а у библиотек и фреймворков - так и осталось. ASP.NET Core, EF Core и т.п.
У MS всю дорогу проблемы с неймингом =3
В чем именно тут затруднение? Микросервисы накладывают ограничения на архитектурные паттерны? Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?
ASP, еще до дотнета который? Нет, речь идет об актуальном ASP.NET Core MVC, хотя автор в посте по почему-то отбросил слово "Core", но из контекста понятно, что речь идет не про оригинальный ASP.NET MVC под .NET Framework.