Но это не попало в мои первые 3 действия. Можно объяснять пользователю, что возможность была, но какой смысл, если он уже ушёл. Эта статья нужна чтобы обратить внимание на важность получения обратной связи от пользователей, и на проверку багов, а не для того чтобы убедить, что в Кошельке невозможно найти способ связаться с поддержкой.
Действительно интересная статья, и вправду нужно использовать ИИ чтобы обрести суперсилу, а не бояться, что ИИ заменит. Пускай заменяет и ускоряет рутину! И более того – сейчас особо выбора нет, можно бояться, а можно учиться использовать ИИ чтобы быть эффективным. Если не учиться – обгонят. И именно учиться, т.к. не умея пользоваться ИИ, можно даже ухудшить рабочий процесс 🧐 Но как говорится – это не rocket science, главное действовать, изучать, применять.
В статье очень простые примеры, т.к. и уровень сложности указан "простой". Опытный разработчик может вручную спроектировать БД, или же написать промптом какие конкретно таблицы создать, прописать текстом все столбцы, и их типы данных – может кому-то удобнее "рассказать как человеку" какая должна быть бд, чем кликать по интерфейсу? Даже когда БД так или иначе спроектирована, опытный разработчик может попросить ИИ внести разом изменения в несколько таблиц (тот же банальный пример про добавление created/updated/deleted_at), или попросить сгенерировать по схеме дамп, чтобы не писать вручную запросы. Попросить сгенерировать миграции, CRUD для таблиц/таблицы на любом языке программирования. В общем тоже может найти как упростить и ускорить себе рабочий процесс.
В первом же скриншоте из статьи – супер простой пример, я бы даже назвал его "антипримером", так как промпт недостаточно детальный, там бегло и очень приблизительно описано что должно быть. И не смотря на это, схема получилась, можем пока обсудить её.
А по поводу углублённого промптинга БД, как нибудь выделю насколько часов, и напишу статью или видео засниму. Такая мысль ещё больше подкрепилась после ажиотажа в комментариях под этой статьёй, и налётом атакующих минусовщиков-ненавистников ИИ. Прямо вот сесть и разобрать реальный пример более сложной БД. И сделать сравнение, как бы например это сделал я вручную, и как сгенерит ИИ, и подытожить. Так что материалу быть, осталось время найти
Стирать это хорошо. Это гораздо лучше чем не стирать. На этапе доски ошибки почти бесплатны. Любая пойманная ошибка экономит море денег.
В наше время уже можно не стирать на доске, а более удобным образом редактировать через современные онлайн-инструменты
Фотографии доски после совещаний это вообще ценный артефакт. Он вероятно поможет кому-то через 10 лет понять как до такого дошли.
Я и говорю, вы мыслите консервативно. Гораздо лучше и удобнее отправить ссылку на визуальную схему базы данных в современном онлайн-сервисе, где любой человек на любом устройстве – хоть на ноутбуке, хоть на телефоне или планшете, хоть на проекторе на стену, сможет увидеть схему, приближать её и отдалять, как ему будет удобно, читать все комментарии. Чем открыть... фото маркерной доски... и пытаться разобрать почерк...
Когда БД спроектирована человек садится и пишет create table под все что придумали и согласовали.
И писал бы create table под каждую таблицу, коих и 50 может быть и 70 на крупном проекте, и сколько бы на это ушло времени...
А если спроектировать базу данных да хоть в том же инструменте, с которого скрины в этой статье, не нужно будет описывать каждую таблицу отдельно в SQL, достаточно нажать одну кнопку экспорта, и пожалуйста, готовый SQL-дамп из визуальной схемы.
А сколько БД крупных (допустим от человекогода на разработку бекенда) прод сервисов вы спроектировали? Я несколько.
Я тоже несколько. Для крупных международных корпоративных клиентов, и не только. И если бы я проектировал БД рисуя на маркерной доске, сравнивая это с опытом проектирования в данном инструменте, можно сравнить с выстрелом себе в ногу перед участием в беговом марафоне (не в пользу доски)
Поймите, я не говорю, что доска это плохо. Она сильно помогала, когда не было более удобных альтернатив. И в любом случае важнее знания и опыт, чем инструмент, который используется для реализации. Но нельзя отрицать тот факт, что лучше всего – знания и опыт плюс удобный инструмент.
Более того. в развитие темы — если он, как проверенный ценнейший специалист, для рисования моков запросит спины белых девственниц, то вопрос будет не "а зачем это тебе надо?", а "какую площадь обеспечить единовременно?"
Это уже на белую горячку похоже. Давайте, пусть ему или вам так ответят и предоставят, я посмотрю на это.
Инструмент не важен, важно — решается задача или нет.
С первой частью утверждения не соглашусь, задача даже если решается, может решаться эффективно и не эффективно. И есть инструменты для того чтобы решать задачу эффективно. Вы же письма по email или в мессенджерах отправляете а не голубем, и не конницей?
Чисто теоретический вопрос - вы представляете себе, что такое НФ? От 3 до 6? И как одна физическая сущность может развертываться в произвольное число таблиц и всего прочего, описывающего ее? А связи сущностей? Нарезать это в отдельные промты? Ну, удачи
Ну конечно я представляю себе что такое нормальные формы, и не просто представляю а проектирую базы данных с учётом нормализации, чтобы данные не дублировались, и оптимально хранились в базе.
Не поверите, но ИИ способен разбивать сущность на несколько таблиц в случае необходимости, и устанавливать связи между ними. Даже первый скриншот из статьи тому в подтверждение, там конечно простой пример, но можно и посложнее. Вопрос в том, как сформулируете промпт, и сможете ли, увидев результат, точно понять, удовлетворяет ли он требованиям, или нет.
Вот в статье на первом скриншоте скорее анти-пример промпта – он весьма абстрактен, и то ИИ в целом вполне справился с задачей. Я специально именно этот пример привёл в статье, чтобы было видно, что даже по простому описанию можно получить удовлетворительный результат. Если же более детально и точно описать все требования, пожелания, и видение результата, то и результат будет соответствующий.
LLM - технология генерации контента, поэтому Вам неоднократно написали о том, что результат генеративных моделей надо валидировать, что в свою очередь требует неопределенного количества времени, которое игнорируется в контексте "экономии времени".
Так я и сам пишу, что требует валидации. Вот часть текста одного из моих комментариев под этой же статьёй:
Я на личном практическом опыте многократно убедился, что экономия существенная, и эффект ускорения значительный. Да, именно при правильном использовании, с последующей верификацией. И я не говорю о том, чтобы делать всё-всё при помощи ИИ. Нужно понимать, какие задачи будет быстрее запромптить и отверифицировать, чем продумать и написать самому. Если ставить перед собой цель написать весь код проекта исключительно с помощью ИИ, то на более менее среднем-крупном проекте это доставит больше проблем, чем пользы. Однако реализацию отдельных моментов, которые можно эффективно ускорить с помощью ИИ, не жертвуя качеством и излишними время-затратами, рациональнее реализовывать с помощью ИИ. И да, это облегчит и ускорит процесс.
Вы так уверены, что именно я "не сталкивался" или "слишком поверхностно"? И на чем же основана ваша уверенность? Ну расскажите
@BoomerCore я тут скорее не про вас, а про тех, насчёт которых вы утверждаете:
Вам уже тут неоднократно объясняли, что если делать задачу правильно (ваш пример), то экономия "на спичках" даст настолько незначительный эффект ускорения
А по поводу подобных комментариев, именно такое впечатление и сложилось. Когда человек не пробовал, не знает какие сейчас возможности у нейросетей, и результаты какого качества они могут давать, но предполагает, что заведомо не могут ничего полезного сгенерировать, и пишет комментарии отталкиваясь от своих теоретических размышлений. А уверенность моя в этом основана, повторюсь, на личном практическом опыте.
Я уже несколько раз здесь писал, что именно декомпозируя "собственным интеллектом" задачи на мелкие, и делегируя их ИИ, и то не все, а те в которых экономия времени будет существенной, при том что процесс включает не только написание промпта, но и проверку результата, то общая экономия будет тоже существенной. И опять же, это личный практический опыт, а не предположения. И нет, не по ХХП.
Shit in - shit out согласен, об этом я и в статье пишу:
Чем подробнее и точнее будет текстовый промпт, тем лучше будет результат
Небольшой кнопки в подвале каждого экрана было бы достаточно.
Но это не попало в мои первые 3 действия. Можно объяснять пользователю, что возможность была, но какой смысл, если он уже ушёл. Эта статья нужна чтобы обратить внимание на важность получения обратной связи от пользователей, и на проверку багов, а не для того чтобы убедить, что в Кошельке невозможно найти способ связаться с поддержкой.
Рад привествовать, уважаемый
Прошёлся по тексту ещё раз, благодарю за замечание
Они такие :-)
Я смотрю тут под каждой статьёй не дадут расслабиться господа орфографисты-пунктуологи! Бдят изо всех сил!
Я стараюсь писать грамотно, правда! :D
Действительно интересная статья, и вправду нужно использовать ИИ чтобы обрести суперсилу, а не бояться, что ИИ заменит. Пускай заменяет и ускоряет рутину! И более того – сейчас особо выбора нет, можно бояться, а можно учиться использовать ИИ чтобы быть эффективным. Если не учиться – обгонят. И именно учиться, т.к. не умея пользоваться ИИ, можно даже ухудшить рабочий процесс 🧐 Но как говорится – это не rocket science, главное действовать, изучать, применять.
Да, всё в точности так!
Хабр – стадия "ненависть" ко всем кто пишет что нейросети могут как то помочь 😁
Вы напишите свой вопрос так чтобы его нормальные люди поняли
Какой курсор? Какая структура? Какой косяк? Куда упорол?))
вы сами поняли что написали?
Благодарю за комментарий! Рад, что статья понравилась!
А то тут налетели ненавистники ИИ и айда тухлыми помидорами кидаться) Я уж в один момент подумал не зря ли я написал статью))
Я не хочу чтобы меня блокировали за рекламу. В правилах написано — упоминать название можно, ссылки давать нельзя. Так что это я не из вредности...
В статье очень простые примеры, т.к. и уровень сложности указан "простой". Опытный разработчик может вручную спроектировать БД, или же написать промптом какие конкретно таблицы создать, прописать текстом все столбцы, и их типы данных – может кому-то удобнее "рассказать как человеку" какая должна быть бд, чем кликать по интерфейсу? Даже когда БД так или иначе спроектирована, опытный разработчик может попросить ИИ внести разом изменения в несколько таблиц (тот же банальный пример про добавление created/updated/deleted_at), или попросить сгенерировать по схеме дамп, чтобы не писать вручную запросы. Попросить сгенерировать миграции, CRUD для таблиц/таблицы на любом языке программирования. В общем тоже может найти как упростить и ускорить себе рабочий процесс.
В первом же скриншоте из статьи – супер простой пример, я бы даже назвал его "антипримером", так как промпт недостаточно детальный, там бегло и очень приблизительно описано что должно быть. И не смотря на это, схема получилась, можем пока обсудить её.
А по поводу углублённого промптинга БД, как нибудь выделю насколько часов, и напишу статью или видео засниму. Такая мысль ещё больше подкрепилась после ажиотажа в комментариях под этой статьёй, и налётом атакующих минусовщиков-ненавистников ИИ. Прямо вот сесть и разобрать реальный пример более сложной БД. И сделать сравнение, как бы например это сделал я вручную, и как сгенерит ИИ, и подытожить. Так что материалу быть, осталось время найти
В наше время уже можно не стирать на доске, а более удобным образом редактировать через современные онлайн-инструменты
Я и говорю, вы мыслите консервативно. Гораздо лучше и удобнее отправить ссылку на визуальную схему базы данных в современном онлайн-сервисе, где любой человек на любом устройстве – хоть на ноутбуке, хоть на телефоне или планшете, хоть на проекторе на стену, сможет увидеть схему, приближать её и отдалять, как ему будет удобно, читать все комментарии. Чем открыть... фото маркерной доски... и пытаться разобрать почерк...
И писал бы create table под каждую таблицу, коих и 50 может быть и 70 на крупном проекте, и сколько бы на это ушло времени...
А если спроектировать базу данных да хоть в том же инструменте, с которого скрины в этой статье, не нужно будет описывать каждую таблицу отдельно в SQL, достаточно нажать одну кнопку экспорта, и пожалуйста, готовый SQL-дамп из визуальной схемы.
Я тоже несколько. Для крупных международных корпоративных клиентов, и не только. И если бы я проектировал БД рисуя на маркерной доске, сравнивая это с опытом проектирования в данном инструменте, можно сравнить с выстрелом себе в ногу перед участием в беговом марафоне (не в пользу доски)
Поймите, я не говорю, что доска это плохо. Она сильно помогала, когда не было более удобных альтернатив. И в любом случае важнее знания и опыт, чем инструмент, который используется для реализации. Но нельзя отрицать тот факт, что лучше всего – знания и опыт плюс удобный инструмент.
Кто такой Клод?) Я Андрей Рик 🤠
Полностью согласен с вышеописанным
В статье указано название инструмента, попробуйте его найти самостоятельно в поисковиках.
Это уже на белую горячку похоже. Давайте, пусть ему или вам так ответят и предоставят, я посмотрю на это.
С первой частью утверждения не соглашусь, задача даже если решается, может решаться эффективно и не эффективно. И есть инструменты для того чтобы решать задачу эффективно. Вы же письма по email или в мессенджерах отправляете а не голубем, и не конницей?
Ну конечно я представляю себе что такое нормальные формы, и не просто представляю а проектирую базы данных с учётом нормализации, чтобы данные не дублировались, и оптимально хранились в базе.
Не поверите, но ИИ способен разбивать сущность на несколько таблиц в случае необходимости, и устанавливать связи между ними. Даже первый скриншот из статьи тому в подтверждение, там конечно простой пример, но можно и посложнее. Вопрос в том, как сформулируете промпт, и сможете ли, увидев результат, точно понять, удовлетворяет ли он требованиям, или нет.
Вот в статье на первом скриншоте скорее анти-пример промпта – он весьма абстрактен, и то ИИ в целом вполне справился с задачей. Я специально именно этот пример привёл в статье, чтобы было видно, что даже по простому описанию можно получить удовлетворительный результат. Если же более детально и точно описать все требования, пожелания, и видение результата, то и результат будет соответствующий.
Так я и сам пишу, что требует валидации. Вот часть текста одного из моих комментариев под этой же статьёй:
@BoomerCore да вы правы, эта статья никому не может принести пользу 😇 в отличие от ваших комментариев 😁
@BoomerCore я тут скорее не про вас, а про тех, насчёт которых вы утверждаете:
А по поводу подобных комментариев, именно такое впечатление и сложилось. Когда человек не пробовал, не знает какие сейчас возможности у нейросетей, и результаты какого качества они могут давать, но предполагает, что заведомо не могут ничего полезного сгенерировать, и пишет комментарии отталкиваясь от своих теоретических размышлений. А уверенность моя в этом основана, повторюсь, на личном практическом опыте.
Я уже несколько раз здесь писал, что именно декомпозируя "собственным интеллектом" задачи на мелкие, и делегируя их ИИ, и то не все, а те в которых экономия времени будет существенной, при том что процесс включает не только написание промпта, но и проверку результата, то общая экономия будет тоже существенной. И опять же, это личный практический опыт, а не предположения. И нет, не по ХХП.
Shit in - shit out согласен, об этом я и в статье пишу: