Неплохо перекликается с опытом, галочки нужны для ощущение объективного выбора у заказчика )
Как считаешь лучше всего уводить диалог от "сравнивалки" в сторону ценностей и долгосрочной пользы, если от заказчика на встрече специалист, который не слишком смотрит в эту сторону? Попросить кого-то другого на встречу вряд ли получится.
Замечу, что курсор и уже vs code умеют генерировать сообщение для коммита и в процесс можно вмешаться, а это довольно важно. И у курсора есть возможность ссылаться на репозиторий, на отдельные коммиты например, чтобы что-то на их базе сделать. Может быть альтернативным иснтрументом при решении той же задачи, но в более ручном и контролируемом режиме.
Думаю это в большей мере зависит от промпта, а тут есть над чем поработать:
content: "Вы — ассистент, который расширяет и улучшает сообщения коммитов. Сделайте их более описательными и профессиональными, сохраняя исходный замысел. Переводите сообщение коммита на русский язык. Делайте это максимально коротко и понятно."
content: Пожалуйста, расширьте и улучшите это сообщение коммита: "${commitData}"
от Vercel, тот жде самый, что и в третьем пункте и который сделал Next.js и shadcn
И мне лично пока не удалось с помощью всех этих инструментов сверстать пользовательский интерфейс разработанный в Figma в Next.js, с компонентами, тестами, мок-данными и сторибуком, как в реальном проекте разработки и так, чтобы код был поддерживаемым. При этом интерфейс не самый сложный, много элементов вроде полей ввода, календари, слоты и т.п. Описаны требования к продукту, к элементам пользовательского интерфейса есть комментарии. Однако контекста моделей агентов явно не хватает для того, чтобы одновременно охватить и правила разработки и требования к продукту и архитектуру системы и согласованность с другими компонентами.
В общем далеко еще до промышленного применения, когда это станет реальностью и станет ли загадывать не берусь.
Получилось обо всем понемногу, но полезно, спасибо!
Добавлю, что когда встает вопрос, как проектировать новую систему, то чаще всего правильный ответ -- монолит, в первую очередь потому что сам вопрос возник. Еще Фаулер лучше меня сформулировал, что если не знаешь, что собираешься делать, делай монолит: https://martinfowler.com/bliki/MonolithFirst.html
Микросервисы можно проектировать сразу если в голове у архитектолра уже есть устойчивая картина как будет выглядеть конечная система, а это значит, что он дорлжен хорошо понимать требования к продукту (а чаще всего этого нет для новых продуктов) и у него должен быть опыт реализации подобных систем.
"Паразиты" -- неудачный пример. В фильем несколько эпизодов посвящены тому, чтобы показать квалификацию героев. Для отца -- проверка чашкой кофе, матери -- эпизод с внезапной готовкой рамена, парень явно неплохо знает английский, а девушка хороший воспитатель. При этом в начале повествования они бесперспективно сидят в подвале.
Рассуждения чересчур категоричны, но это неплохо для того чтобы обратить внимание на часто необоснованную сложность систем.
В поднятом вопросе я согласен с Макконнеллом, если принятые архитектурные или другие решения упрощают поддержку результирующей системы, то это качественные решения и наоборот: Программные проекты редко терпят крах по техническим причинам. Чаще всего провал объясняется неадекватной выработкой требований, неудачным планированием или неэффективным управлением. Если же провал обусловлен все-таки преимущественно технической причиной, очень часто ею оказывается неконтролируемая сложность. Иначе говоря, приложение стало таким сложным, что разработчики перестали по-настоящему понимать, что же оно делает. Если работа над проектом достигает момента, после которого уже никто не может полностью понять, как изменение одного фрагмента программы повлияет на другие фрагменты, прогресс прекращается.
Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.
Полезный материал, инструментов куча, не знаешь на что обратить внимание. Было бы здорово еще пару слов о стоимости добавить, понимаю, что информация есть на сайтах, но личное впечатления дорого/дешево было бы полезно, может какой-то freemium есть.
> Для зарегистрировавшихся пользователей у нас предусмотрен telegram-канал, в котором можно позадавать вопросы, пообщаться и предложить свои фичи.
В телеграм-канале я уже высказывал свое мнение. Одно занудное сообщение про сравнение цен с FirstVDS от меня было.
> Что же касается публичного бэклога, краткая выжимка сейчас есть на сайте, страница «О проекте».
Да, я видел, извините, но там обо всем сразу и непонятно в каком порядке и почему. Я предложил вам спросить у пользователей их мнения, делать это или нет, конечно решать вам.
Пока функциональных возможностей для пользователя еще совсем немного, но потенциал у продукта есть.
Может вам стоило бы больше рассказать про сам продукт, какие цели стоят, на какие вопросы еще не нашли ответа, ограничения, риски и т.п. Также можно выложить основные фичи из беклога для голосования, чтобы сравнить ожидания с пользователями? Я вот, к примеру, думаю, что вы планируете сделать местный digital ocean, а у вас может другие виды.
Неплохо перекликается с опытом, галочки нужны для ощущение объективного выбора у заказчика )
Как считаешь лучше всего уводить диалог от "сравнивалки" в сторону ценностей и долгосрочной пользы, если от заказчика на встрече специалист, который не слишком смотрит в эту сторону? Попросить кого-то другого на встречу вряд ли получится.
Замечу, что курсор и уже vs code умеют генерировать сообщение для коммита и в процесс можно вмешаться, а это довольно важно.
И у курсора есть возможность ссылаться на репозиторий, на отдельные коммиты например, чтобы что-то на их базе сделать. Может быть альтернативным иснтрументом при решении той же задачи, но в более ручном и контролируемом режиме.
А на дейлики ходить полезно )
Думаю это в большей мере зависит от промпта, а тут есть над чем поработать:
content: "Вы — ассистент, который расширяет и улучшает сообщения коммитов. Сделайте их более описательными и профессиональными, сохраняя исходный замысел. Переводите сообщение коммита на русский язык. Делайте это максимально коротко и понятно."content: Пожалуйста, расширьте и улучшите это сообщение коммита: "${commitData}"от Vercel, тот жде самый, что и в третьем пункте и который сделал Next.js и shadcn
И мне лично пока не удалось с помощью всех этих инструментов сверстать пользовательский интерфейс разработанный в Figma в Next.js, с компонентами, тестами, мок-данными и сторибуком, как в реальном проекте разработки и так, чтобы код был поддерживаемым.
При этом интерфейс не самый сложный, много элементов вроде полей ввода, календари, слоты и т.п. Описаны требования к продукту, к элементам пользовательского интерфейса есть комментарии.
Однако контекста моделей агентов явно не хватает для того, чтобы одновременно охватить и правила разработки и требования к продукту и архитектуру системы и согласованность с другими компонентами.
В общем далеко еще до промышленного применения, когда это станет реальностью и станет ли загадывать не берусь.
Получилось обо всем понемногу, но полезно, спасибо!
Добавлю, что когда встает вопрос, как проектировать новую систему, то чаще всего правильный ответ -- монолит, в первую очередь потому что сам вопрос возник.
Еще Фаулер лучше меня сформулировал, что если не знаешь, что собираешься делать, делай монолит:
https://martinfowler.com/bliki/MonolithFirst.html
Микросервисы можно проектировать сразу если в голове у архитектолра уже есть устойчивая картина как будет выглядеть конечная система, а это значит, что он дорлжен хорошо понимать требования к продукту (а чаще всего этого нет для новых продуктов) и у него должен быть опыт реализации подобных систем.
Выглядит привлекательно, был у кого-то опыт использования anytyoe.io? Как он в сравнении с notion, confluence, obsidian, к кому и в чем ближе?
"Паразиты" -- неудачный пример. В фильем несколько эпизодов посвящены тому, чтобы показать квалификацию героев. Для отца -- проверка чашкой кофе, матери -- эпизод с внезапной готовкой рамена, парень явно неплохо знает английский, а девушка хороший воспитатель.
При этом в начале повествования они бесперспективно сидят в подвале.
Есть только предположение (дальше содержимое комментария удалил по совету друга).
Что касается проекта, мы опираемся на список аккредитованных https://cctld.ru/ регистраторов.
Будем развивать и для других зон.
Комментарий хорош.
Добавлю, что ваша точка зрения мне очень симпатична, ее бы куда-нибудь в принципе сообщества вывести, лаконично и емко выражена.
Рассуждения чересчур категоричны, но это неплохо для того чтобы обратить внимание на часто необоснованную сложность систем.
В поднятом вопросе я согласен с Макконнеллом, если принятые архитектурные или другие решения упрощают поддержку результирующей системы, то это качественные решения и наоборот:
Программные проекты редко терпят крах по техническим причинам. Чаще всего провал объясняется неадекватной выработкой требований, неудачным планированием или неэффективным управлением. Если же провал обусловлен все-таки преимущественно технической причиной, очень часто ею оказывается неконтролируемая сложность. Иначе говоря, приложение стало таким сложным, что разработчики перестали по-настоящему понимать, что же оно делает. Если работа над проектом достигает момента, после которого уже никто не может полностью понять, как изменение одного фрагмента программы повлияет на другие фрагменты, прогресс прекращается.Управление сложностью — самый важный технический аспект разработки ПО. По-моему, управление сложностью настолько важно, что оно должно быть Главным Техническим Императивом Разработки ПО.Вот это правда и оттого ещё грустнее )
Начало интересное, посмотрю внимательней, спасибо!
С идеями согласен, донесено хорошо.
Было бы совсем круто, если бы приведи примеры хорошей или плохой документации, с указанием, что именно хорошо и плохо.
В телеграм-канале я уже высказывал свое мнение. Одно занудное сообщение про сравнение цен с FirstVDS от меня было.
> Что же касается публичного бэклога, краткая выжимка сейчас есть на сайте, страница «О проекте».
Да, я видел, извините, но там обо всем сразу и непонятно в каком порядке и почему. Я предложил вам спросить у пользователей их мнения, делать это или нет, конечно решать вам.
Пока функциональных возможностей для пользователя еще совсем немного, но потенциал у продукта есть.
Может вам стоило бы больше рассказать про сам продукт, какие цели стоят, на какие вопросы еще не нашли ответа, ограничения, риски и т.п. Также можно выложить основные фичи из беклога для голосования, чтобы сравнить ожидания с пользователями? Я вот, к примеру, думаю, что вы планируете сделать местный digital ocean, а у вас может другие виды.
В любом случае удачи в реализации проекта!
Ваша позиция вполне обоснована и понятна мне.