Специализированными моделями не пользовался, пробовал для кодинга ChatGPT, и для задач типа "напиши код, который делает то-то" примерно в 30% случаях получал рабочий код. Примерно треть случаев - код не работал сразу, как надо, но логика была понятна, и после ручного рефакторинга использовать было можно (хотя, ценность, конечно, резко падает). В остальных случаях нейросеть фигню какую-то выдавала.
Но попробовал ставить задачу под конкретный фреймворк - Laravel, и тут дела гораздо лучше пошли. Описал сущности, их свойства, и получил код миграций, моделей и контроллера. Потом попросил дать код blade-шаблонов для CRUD и получил их. Прикольно, что ГПТ запоминает контекст, и когда попросил добавить доп.поле, то получил в ответ и миграцию, и обновленные модель с контроллером.
В итоге получил небольшое работающее приложение, где я не написал ни строчки кода, был сплошной копипаст, хотя, и не бездумный - местами копипаст был фрагментарный.
А вот GigaChat от Сбера тупеньким оказался, он сильно старался, но код был совсем нерабочий.
Было как-то, что я пропустил оплату сервера (несмотря письма), так мой хостер звонил по телефону и спрашивал, буду ли продлевать. А я в поездке был и сильно занят, так мне поставили "условное продление" на несколько дней, пока я не освободился и оплатил. Вот это, я понимаю, клиентоориентированность
У меня аккурат этой ночью проводной интернет от ростелекома отвалился, еще думал, что с утра надо будет их дергать, а оно само к утру ожило. Мобильный интернет работал
Интересно, меняется ли что-либо в зависимости от того, оказываешь ли ты услуги юрлицу или физикам? Как входящие платежи фиксируются? Есть ли что-то вроде обязательных чеков, которые надо выдавать физикам?
Соглашусь, что в случае с Nested Sets обновлять ключи Left/Right у какого-то количества записей надо будет почти всегда. Но какие операции выполняются чаще - вставки или выборки? Насколько я знаю, выборка выполняется гораздо чаще - тут и выборка поддерева структуры, и получение списка элементов на определенном уровне конкретного дистрибьютора и пр. В случае с хранением пути это все выборки через LIKE '%x%', а в Nested Sets - выборка по индексированным числовым ключам, что однозначно быстрее будет. А уж если речь о бинарном дереве, которое очень быстро и неравномерно растет в глубину, и, стало быть, увеличивает длину пути, то выборка по путям особо тормозить будет
В данном случае худший случай это какой, вставка узла в корень? Во-первых, это крайне редкий случай в МЛМ. А, во-вторых, в таком кейсе у автора также будет апдейт всех записей (т.к. надо будет обновить путь для всех узлов)
Где же тут наглядность? Если нет нормального человеческого интерфейса, то наглядно лишь представление аплайна (что требуется не так уж и часто), больше никакой наглядности нет. Но если nested sets сложен для понимания, и увеличение времени запросов в разы (если не на порядки) не смущает, то можно и так, конечно.
А чем не подошел метод nested sets? Да, он чуть более ресурсоемкий при добавлении новых записей, но зато очень эффективен на выборках. Тем более, что при работе с MLM-структурами нередко требуются специфические выборки, например, сравнение двух веток, подсчет дочерних дистрибьюторов на определенных уровнях и т.д., и такой метод хранения структуры позволяет все эти операции выполнять одним запросом. И все это без LIKE, а на числовых индексированных полях
У нас все сложнее было - львиная часть кода вообще на ассемблере (во-первых, экономия памяти и производительность, во-вторых - управление всяким оборудованием, трудно было обойтись без ассемблера), а эта реализация Паскаля позволяла ассемблерный код вставлять прямо в тело процедуры, при этом из ассемблерного кода можно было обращаться к переменным и вызывать процедуры и функции прямо по их именам. Поэтому процедуры и функции оформлялись в синтаксисе Паскаля (заголовки, объявление типизированных переменных), а само тело - ассемблер. На чистом Паскале только интерфейс пользователя писался
Ой, прям ностальгия пробила! У нас, кстати, СМ-4 поставлялись с операционной системой ОСРВ СМ - "Операционная система реального времени для серии СМ", которая позволяла работать в многопользовательском многотерминальном режиме. По факту это была криво переведенная RSX-11 ("процесс из цомплетед"). Мы даже умудрились где-то найти оригинальную RSX-11 и работали с ней, а заодно с Pascal-2 для PDP-11, когда все кругом писали на Фортране
Вброс на вентилятор засчитан. Если принять все описанное за чистую монету, то можно сделать вывод, что, автор так и не смог найти нормальной работы ни на PHP, ни на Ruby, автор получал "фидбэки", но не получил работу (иначе не было б такой статьи, или она была бы совсем другой). Может, тогда проблема не в языках?
Немного смущает термин "быстрый" в заголовке. Если я верно понял из описания, то алгоритм, в целом, такой: 1) разбиваем поисковую строку на слова 2) находим записи по каждому слову из поиска 3) по всем найденным записям вычисляем релевантность 4) дергаем из базы записи в соответствии с релевантностью
Звучит все просто и логично (возникло даже желания в одном из своих проектов такой подход попробовать). Но насколько быстро это работает на больших объемах? Ведь п.2 может вернуть овердофига записей
Ладно, народ, потерпите немного, осенью обещали выдать отечественный сериал про Чернобыль. Судя по анонсам, там все будет закручено вокруг героя советского контрразведчика, который стремится вычислить американского шпиона, готовившего диверсию на АЭС.
Даже интересно, вызовет ли российский фильм такую же бурю негодования, будут ли так же громко возмущаться «лживой пропагандистской поделкой» те, кто недоволен сериалом от HBO, или это будет «ок, норм»?
Специализированными моделями не пользовался, пробовал для кодинга ChatGPT, и для задач типа "напиши код, который делает то-то" примерно в 30% случаях получал рабочий код. Примерно треть случаев - код не работал сразу, как надо, но логика была понятна, и после ручного рефакторинга использовать было можно (хотя, ценность, конечно, резко падает). В остальных случаях нейросеть фигню какую-то выдавала.
Но попробовал ставить задачу под конкретный фреймворк - Laravel, и тут дела гораздо лучше пошли. Описал сущности, их свойства, и получил код миграций, моделей и контроллера. Потом попросил дать код blade-шаблонов для CRUD и получил их. Прикольно, что ГПТ запоминает контекст, и когда попросил добавить доп.поле, то получил в ответ и миграцию, и обновленные модель с контроллером.
В итоге получил небольшое работающее приложение, где я не написал ни строчки кода, был сплошной копипаст, хотя, и не бездумный - местами копипаст был фрагментарный.
А вот GigaChat от Сбера тупеньким оказался, он сильно старался, но код был совсем нерабочий.
Было как-то, что я пропустил оплату сервера (несмотря письма), так мой хостер звонил по телефону и спрашивал, буду ли продлевать. А я в поездке был и сильно занят, так мне поставили "условное продление" на несколько дней, пока я не освободился и оплатил. Вот это, я понимаю, клиентоориентированность
Вороватый ру-центр радостно потирает ручонки - тысячи новых непуганных клиентов, которым можно втихаря подключать ненужные услуги и тырить по мелочи
Поясните насчет 8.1, возможно, я от жизни отстал, но работаю локально под php 8.1 (и именно под OSP) и проблем пока не испытывал.
А если говорить о максимально приближении, то под Линуксом пилить надо (если, конечно, у вас прод не под Виндой и не под OSP)
Если речь про установку на локальном компе сугубо для разработки, то зачем возиться с ssl?
У меня аккурат этой ночью проводной интернет от ростелекома отвалился, еще думал, что с утра надо будет их дергать, а оно само к утру ожило. Мобильный интернет работал
Интересно, меняется ли что-либо в зависимости от того, оказываешь ли ты услуги юрлицу или физикам? Как входящие платежи фиксируются? Есть ли что-то вроде обязательных чеков, которые надо выдавать физикам?
Я не соглашусь. Во всяком случае, я такого тренда не вижу.
Соглашусь, что в случае с Nested Sets обновлять ключи Left/Right у какого-то количества записей надо будет почти всегда. Но какие операции выполняются чаще - вставки или выборки? Насколько я знаю, выборка выполняется гораздо чаще - тут и выборка поддерева структуры, и получение списка элементов на определенном уровне конкретного дистрибьютора и пр. В случае с хранением пути это все выборки через LIKE '%x%', а в Nested Sets - выборка по индексированным числовым ключам, что однозначно быстрее будет. А уж если речь о бинарном дереве, которое очень быстро и неравномерно растет в глубину, и, стало быть, увеличивает длину пути, то выборка по путям особо тормозить будет
В данном случае худший случай это какой, вставка узла в корень? Во-первых, это крайне редкий случай в МЛМ. А, во-вторых, в таком кейсе у автора также будет апдейт всех записей (т.к. надо будет обновить путь для всех узлов)
Если есть желание, то можно, конечно, поспорить, что будет отрабатывать быстрее: LIKE по строкам или поиск по индексированным числовым полям
Где же тут наглядность? Если нет нормального человеческого интерфейса, то наглядно лишь представление аплайна (что требуется не так уж и часто), больше никакой наглядности нет. Но если nested sets сложен для понимания, и увеличение времени запросов в разы (если не на порядки) не смущает, то можно и так, конечно.
А чем не подошел метод nested sets? Да, он чуть более ресурсоемкий при добавлении новых записей, но зато очень эффективен на выборках. Тем более, что при работе с MLM-структурами нередко требуются специфические выборки, например, сравнение двух веток, подсчет дочерних дистрибьюторов на определенных уровнях и т.д., и такой метод хранения структуры позволяет все эти операции выполнять одним запросом. И все это без LIKE, а на числовых индексированных полях
Вы не поверите, но я застал то время, когда платили за ПРОСМОТР банеров. И это были мои первые деньги, который я заработал в онлайне
У нас все сложнее было - львиная часть кода вообще на ассемблере (во-первых, экономия памяти и производительность, во-вторых - управление всяким оборудованием, трудно было обойтись без ассемблера), а эта реализация Паскаля позволяла ассемблерный код вставлять прямо в тело процедуры, при этом из ассемблерного кода можно было обращаться к переменным и вызывать процедуры и функции прямо по их именам. Поэтому процедуры и функции оформлялись в синтаксисе Паскаля (заголовки, объявление типизированных переменных), а само тело - ассемблер. На чистом Паскале только интерфейс пользователя писался
Ой, прям ностальгия пробила! У нас, кстати, СМ-4 поставлялись с операционной системой ОСРВ СМ - "Операционная система реального времени для серии СМ", которая позволяла работать в многопользовательском многотерминальном режиме. По факту это была криво переведенная RSX-11 ("процесс из цомплетед"). Мы даже умудрились где-то найти оригинальную RSX-11 и работали с ней, а заодно с Pascal-2 для PDP-11, когда все кругом писали на Фортране
Вброс на вентилятор засчитан. Если принять все описанное за чистую монету, то можно сделать вывод, что, автор так и не смог найти нормальной работы ни на PHP, ни на Ruby, автор получал "фидбэки", но не получил работу (иначе не было б такой статьи, или она была бы совсем другой). Может, тогда проблема не в языках?
Немного смущает термин "быстрый" в заголовке. Если я верно понял из описания, то алгоритм, в целом, такой:
1) разбиваем поисковую строку на слова
2) находим записи по каждому слову из поиска
3) по всем найденным записям вычисляем релевантность
4) дергаем из базы записи в соответствии с релевантностью
Звучит все просто и логично (возникло даже желания в одном из своих проектов такой подход попробовать). Но насколько быстро это работает на больших объемах? Ведь п.2 может вернуть овердофига записей
Даже интересно, вызовет ли российский фильм такую же бурю негодования, будут ли так же громко возмущаться «лживой пропагандистской поделкой» те, кто недоволен сериалом от HBO, или это будет «ок, норм»?
Т.е. Вы считаете зрителей дебилами, которые не могут отличить художественный фильм от документального? Что ж так плохо о людях думаете?