Ну продвинутый ai-intellisense неплохо работает. И вполне в 20-30% (а то и больше) вписывается в моей текущей разработке. Подправлять, конечно, надо, но время - экономит. Если начать писать функцию на "до 10 строк" и дать её название говорящее, типа "daysAndHoursAgo" - то почти справляется (в этом случае забыл, что количество часов - это остаток от деления общего количества часов на 24*количество дней). Если быть внимательным - то в процессе генерации это замечаешь и сразу исправляешь. Ну или каждую функцию тестами покрывать. даже такую простую, можно вообще от ttd идти. Может быть в этом случае будет получше. Правда это тоже целиком нельзя отдавать на откуп ИИ, надо проверять то, что он генерит прям сразу. Мозг выключать нельзя, надо сразу корректировать что он творит - и всё будет ок.
Повторюсь - на генерации минимальных кусков прямо в процессе того, как ты сам пишешь код - неплохо экономит время.
Да, в данном случае аргументация автора немного странная. Вообще партиции это решение уже для следующего этапа роста, когда ну совсем много данных. В большинстве случаев частичного индекса должно хватить. Иногда можно добавить несколько полей без упорядочивания для того, чтобы он стал в частых запросах покрывающим.
Не "в общем случае", а вообще только при самых минимальных скоростях. При чуть более сильных ударах часть "продольного" движения идет в завинчивание шара, что делает простой геометрический расчет трудным, в реальных партиях прицеливание и сила удара от борта идет "от ощущения", т.е. из наработанного автоматизма.
Q - это просто индекс скорости, на которой производитель гарантирует сохранение соответствия стандарту. А при превышении может, например, начать изменяться геометрия поверхности из плоской в выгнутую. Или шипы вылетать. Или еще что.
Для бездорожья другое обозначение. Например MT - как раз для "легкого бездорожья" или AT для грунтовок. Но и у таких шин запрета выезда на автомагистраль нет.
А индекс нагрузки - это число перед индексом скорости - и его тоже надо подбирать к автомобилю.
Кто же мешает? для гита есть относительно удобный формат https://plantuml.com/ с автоматическим рендерингом в картинки + есть плагин для маркдауна, чтобы напрямую текст туда вставлять и на выходе получать документ с картинками.
Бред сивой кобылы пошёл :(
Ну не знаю. Мне пример в конце почему-то напомнил недоделанный cucumber/gherkin и это один реально один "прецедент" он же "сценарий", он же юзер-стори в том плане, что это одна "фича" (или feature файл в gherkin), при этом продукт, как и use-case диаграмма содержит множетсво и акторов и сценариев.
И опять ошибка думать, что я имел ввиду то, что use-case это диаграмма, а не диаграмма - это удобное представление use-case. Вообще в данной статье идет речь больше о user-story. А use-case - это совокупность различных прецедентов/user-story, которые можно представить в различных диаграммах типа activity или sequence, например.
главный результат — время оформления заказа сократилось с 3-4 минут до 30-40 секунд
Когда пользователь точно знает, что он хочет и не заказывает что-то по акциям или комбо или не модифицирует ничего.
Я заказал недавно в приложении комбо из 7 пицц, изменив каждую и это заняло у меня меньше пяти минут. Как бы это выглядело с голосовым управлением, когда у меня не было бы меню перед лазами - даже не представляю, какое это было бы мучение.
Банально сделать в приложении строку поиска чуть умнее, чем "LIKE '%мясная%'" с голосовым вводом (хотя глобально и он не нужен - эта функция во всех клавиатурах есть уже) - и вот уже вся потребность этого бота закрыта с сохранением скорости модификации, информации об акциях и прочими преимуществами приложения.
Думаю, учитывая объем сгенеренного кода (через пару итераций - и снижение квалификации) - это не главный промпт инженер, а техножрец будет. Ибо понимания, как оно работает не останется.
Ну продвинутый ai-intellisense неплохо работает. И вполне в 20-30% (а то и больше) вписывается в моей текущей разработке. Подправлять, конечно, надо, но время - экономит. Если начать писать функцию на "до 10 строк" и дать её название говорящее, типа "daysAndHoursAgo" - то почти справляется (в этом случае забыл, что количество часов - это остаток от деления общего количества часов на 24*количество дней). Если быть внимательным - то в процессе генерации это замечаешь и сразу исправляешь. Ну или каждую функцию тестами покрывать. даже такую простую, можно вообще от ttd идти. Может быть в этом случае будет получше. Правда это тоже целиком нельзя отдавать на откуп ИИ, надо проверять то, что он генерит прям сразу. Мозг выключать нельзя, надо сразу корректировать что он творит - и всё будет ок.
Повторюсь - на генерации минимальных кусков прямо в процессе того, как ты сам пишешь код - неплохо экономит время.
Да, в данном случае аргументация автора немного странная. Вообще партиции это решение уже для следующего этапа роста, когда ну совсем много данных. В большинстве случаев частичного индекса должно хватить. Иногда можно добавить несколько полей без упорядочивания для того, чтобы он стал в частых запросах покрывающим.
Удаление замедлит, но, кажется, чтение происходит намного чаще? Случаи, конечно, разные бывают, но в основном так.
del
я буду читать комментарии перед ответом
Не "в общем случае", а вообще только при самых минимальных скоростях. При чуть более сильных ударах часть "продольного" движения идет в завинчивание шара, что делает простой геометрический расчет трудным, в реальных партиях прицеливание и сила удара от борта идет "от ощущения", т.е. из наработанного автоматизма.
Главное, чтобы http://www.kids.kremlin.ru/ открывался
Так а кто-нибудь написал в гугл что домены *.spb.ru к подсанкционному Public Joint Stock Company SPB Exchange не имеют отношения?
plantuml позволяет добавлять на диаграммы название, через title, а также есть колонтитулы, легенда и подпись, см пример: https://www.plantuml.com/plantuml/uml/ZL4xJiD04Etd52DHKq2980eqdCCaIs9fuqNEKY2vI8Bu54YKb5p1X1Wv3eOhlBaHJyW5KA0KezMypzCyRNyQapnUJhoCNJ9qkMA9ocPsWnOrree67zXmMbkWjeLTOoCIq-YTuWabNZj-oMb4paE8JFbsl_sRuTt8PKF1ErfIZB4vgHdVEoAbFGez5OcAwmgbsbpfB_52lBPRuckHuaZjdk0d6fHx-clTrqAAmvtJtBciz-EAJle7wTIZFBdQMZnD_2HicIrigrrf6IGNCGsPufcI5S-jsVv1v2ISwMvFZtqwS7gWO-Tza3uj_A4l
Документация: https://pdf.plantuml.net/PlantUML_Language_Reference_Guide_ru.pdf#subsection.21.3
Прочитал с удовольствием, спасибо!
Жаль, нельзя поставить второй плюс (за plantuml)
Много лет использую раскладку Чистова https://1c.chistov.pro/2012/11/1.html
ЕМНИП какой-то из TTD (3?) был на движке RCT
Q - это просто индекс скорости, на которой производитель гарантирует сохранение соответствия стандарту. А при превышении может, например, начать изменяться геометрия поверхности из плоской в выгнутую. Или шипы вылетать. Или еще что.
Для бездорожья другое обозначение. Например MT - как раз для "легкого бездорожья" или AT для грунтовок. Но и у таких шин запрета выезда на автомагистраль нет.
А индекс нагрузки - это число перед индексом скорости - и его тоже надо подбирать к автомобилю.
Кто же мешает? для гита есть относительно удобный формат https://plantuml.com/ с автоматическим рендерингом в картинки + есть плагин для маркдауна, чтобы напрямую текст туда вставлять и на выходе получать документ с картинками.
Ну не знаю. Мне пример в конце почему-то напомнил недоделанный cucumber/gherkin и это один реально один "прецедент" он же "сценарий", он же юзер-стори в том плане, что это одна "фича" (или feature файл в gherkin), при этом продукт, как и use-case диаграмма содержит множетсво и акторов и сценариев.
ну у меня сейчас зимние с индексом Т (190 кмч), но это относительно дорогие. куча вариантов с индексом Q (160кмч)
Похоже, что Igo в навигаторе так умел. по крайней мере он не терялся на развязках и перекрестках в тоннелях в поездках по скандинавии.
И опять ошибка думать, что я имел ввиду то, что use-case это диаграмма, а не диаграмма - это удобное представление use-case. Вообще в данной статье идет речь больше о user-story. А use-case - это совокупность различных прецедентов/user-story, которые можно представить в различных диаграммах типа activity или sequence, например.
Когда пользователь точно знает, что он хочет и не заказывает что-то по акциям или комбо или не модифицирует ничего.
Я заказал недавно в приложении комбо из 7 пицц, изменив каждую и это заняло у меня меньше пяти минут. Как бы это выглядело с голосовым управлением, когда у меня не было бы меню перед лазами - даже не представляю, какое это было бы мучение.
Банально сделать в приложении строку поиска чуть умнее, чем "LIKE '%мясная%'" с голосовым вводом (хотя глобально и он не нужен - эта функция во всех клавиатурах есть уже) - и вот уже вся потребность этого бота закрыта с сохранением скорости модификации, информации об акциях и прочими преимуществами приложения.
Опять нейросеть.
И ни одного примера use-case диаграмм в различных нотациях, например UML.
Думаю, учитывая объем сгенеренного кода (через пару итераций - и снижение квалификации) - это не главный промпт инженер, а техножрец будет. Ибо понимания, как оно работает не останется.