Vitaly Karasik

С минимальным простоем - да, репликация. Выключаете на старом месте, включаете на новом. Блокировать ничего не нужно.

Первая мысль: а зачем вообще здесь нужен ИИ?
Можно ведь построить графики средствами самого Google Sheets. Ну или экспортировать в CSV и оттуда в какую-то СУБД, чтобы сделать запрос.

А, вообще, вроде бы, при помощи Amazon Bedrock можно создавать запросы к СУБД, на основе которых уже можно строить любые графики.
AWS Bedrock Gen AI - Generate SQL Code

Дополнение

Но мне интересно проверить, может ли "AI" упростить это.

насколько я понимаю, речь идёт о составлении запросов на основе набора данных в Google Sheets. Используя питоновский пакет LangChain, можно подключить к СУБД и составлять запросы от ИИ человеческим языком. Получив ответ на запрос, нужно программно вставить данные ответа и график.
В https://developers.google.com/sheets/api/samples/charts описано как программно создавать графики.

На сколькой я знаю с gpt, ты не можешь взаимодействовать с google sheets, только вопросы задавать как сделать то или иное. А вот с Gemini ты можешь взаимодействовать, с google workspace и как следствие с google sheets. На сколько это все качественно там не знаю, но начиная от официальной поддержки, ютуб мануалов, да и сам Gemini может подсказать, как с этим делом взаимодействовать.

Не думаю что google даст api для выполнения скриптов от LLM для своих сервисов. Так что предполагаю что только gemini.

И нет и, может быть, да. Помимо llama существует лучше модели, например mistral и основанные на нем типа openchat35 или лучше mixtral (он неожиданно умный и скорости как 7b) или или еще лучше от databrix (по скорости как llama30b).

У разработчиков языковых моделей например есть chat версии, есть instruct, а есть base. Общий смысл каждой определяется тем, на какое именно использование их заточили. Например instruct позволяет описывать инструкции на естественном языке и главное получать ответ тоже на естественном языке, со всеми вытекающими от сюда неудобствами (api предполагает стандартизацию форматов вывода). chat ожидает что с ним будут общаться в формате user: xxx, ну а base модели изначально работают только как completion, и их обычно дообучают до своих форматов и наборов знаний.

Кстати, к примеру модели, которые обучали программированию (а это почти все, ищи в бенчмарках HumanEval, потому что openai говорили что именно с этого начинали свою модель обучать и это очень было ей полезно), можно буквально попросить давать ответ в виде json, описав в промпте его формат и оно будет пытаться это делать, точно помню что прбовали за основу взять принцип - модель генерирует готовую программу, решающую вашу задачу, бакэнд ее запускает и выдает ответ и так на каждый запрос. Но чем глупее и проще модель, тем с большей вероятностью она будет отходить от строгого формата, а значит бакэнд приложение, которое будет обслуживать уже твой api должно ожидать эти расхождения и обрабатывать их не как ошибка (например лишнее текстовое описание типа "вот вам ответ в формате json: ...".

Так как llm это посимвольная (по токенам точнее) генерация ответа, на каждом из них, в момент когда происходит выбор следующего токена, можно вставить свой алгоритм, ограничивающий доступный список своими, по своему правилу. Например можно описать регулярное выражение, которое будет применяться к сгенерированному тексту плюс выбираемый токен и если оно не подходит, отказывать в выборе этого токена. Например какая то реализация этого есть в llama.cpp ищи grammar, это ключ у api вызова к server.

Использование llm это в первую очередь исследовательская работа, возможности языковых моделей иногда шокируют но часто раздражают. Например языковую модель научили играть в дум, причем максимально странным способом. Можно представить что описывая специфический запрос, можно заставить модель управлять роботом и т.п.

Есть общепринятые лайфхаки, повышающие качество ответа. Это добавление примеров (вопрос+ответ+вопрос+ответ+вопрос+...) т.е. one-shot/multi-shot, именно так слабые модели могут встать по бенчмаркам с zero-shot у сильных моделей, без примеров. Или попросить в запросе модель поразмышлять (think step by step), надавить на эмоции (найти ответ очень важно для меня, от этого зависит моя жизнь), ценой места в окне контекста. Еще есть подход, делать один и тот же запрос (или кстати слегка менять prompt) много раз, и сделать какой то механизм валидации ответа (например большая часть одних и тех же ответов считать верной) - как защита от галлюцинаций (был пример когда модель заставили миллион раз генерировать программу, запускать ее и проверять результат - так сделали реальное научное открытие)

НО! Просто не будет.

этот вопрос у меня относится к удобству чтения кода и просмотра сайта другими пользователями, чтобы они удостоверились в разработке на React.

В репу заливается весь проект, исключая зависимости, так, чтобы можно было скопировать проект себе на локалку, поставить зависимости и:
- Запустить в режиме разработки одной командой.
- Собрать проект одной командой.
- Выполнить тесты одной командой.

Либо, чтобы из репы можно было скопировать лишь dist/ и сразу опубликовать это как приложение в любом месте, без дополнительных команд.

От такого способа не будет видно, что применялся Реакт?

Слепой не увидит ничего, в остальном - все чекается на раз-два.

Рекомендую изучить крупные репы и обратить внимание на то, что там в рамках одной репы имеются исходники (src), сборки разных видов (dist/build), опубликованы все необходимые команды так, чтобы даже не зрячая обезьянка могла скопировать и выполнить эту команду, чтобы получить желаемый результат.

Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

Теперь что такое кластерный индекс... сначала почти то же. Берём выражение индекса, считаем его значение для каждой записи, сортируем и... а вот теперь не записываем по порядку эти значения с номерами соответствующих записей в отдельную структуру, а сами записи располагаем в этом порядке. Теперь, когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи, как это было, когда записи не сортированы, сразу половинным делением быстренько найдём нужное значение. Но нам уже не надо получать номер записи и обращаться за ней - мы нашли саму нужную запись.

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

Выглядит так, как будто это просто физическая сортировка данных по индексируемому полю.

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

Не создаётся. Но при изменении первичного индекса таблица полностью пересоздаётся с новым физическим порядком записей.

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

Представь такой (на самом деле невозможный, но не суть) случай - ты запросил таблицу. Вторая половина её ещё лежит в кэше, а первая уже выдавлена оттуда данными другой таблицы, нужными для выполнения запроса. Конечно, наиболее оптимальным будет начать передачу данных клиенту с этих записей, а пока они передаются, подчитать остальные, и передать их позже. Вот тебе порядок-то и поломался...

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

Любой сайт фриланса. Там за денюшку Вам составят подробный план и проект)
Насчет технических моментов - это не Ваша проблема, а реализатора

Разница в бинарях - Python на хостовой машине собран без отладочной информации, а тот, который в образе python:3.10.4 собран с нею.

Выходом из ситуации будет - взять базовый образ Debian и установить в него Python из штатного репозитория с помощью штатного пакетного менеджера, тогда результат теста бенчмарка на хостовой машине и в контейнере не будет отличаться.

Можно пойти дальше и собрать Python из исходников самому, но самостоятельная сборка это такое себе развлечение (хотя с помощью pyenv делать это довольно просто), а выигрыш не такой уж и значительный - устанавливать бинарные пакеты сильно проще.

PS
Никогда не используй образы Alpine - там вместо glibc суррогат под названием musl. В прочем для статически слинкованных бинарей на Go использовать можно, но тогда уж выгоднее использовать scratch

Я за семь минут сформулировал три разных ответа. Это ж надо так умудриться задать вопрос, что хрен поможешь.

(я использую MAMP) без него, вместо желаемого результата на странице появляется весь код PHP,

Ну. конечно будет появляться исходный код, ибо интерпретатора нет и никто исходники не обрабатывает.

когда подключается PHP код выходит ошибка (не находит страницу)

Ошибки - это нормально! Нужно найти причину и устранить ее.

Правильно заданый вопрос - 50% ответа. Тренируйтесь излагать мысли - полезно для кодинга

Можно указывать в названии PR:

feature/front/books-added-author-field
feature/back/books-added-author-field

Нужно/не нужно - скорее организационный вопрос. Если проект большой и народу много, то тогда вообще репозиторий следует делить на более маленькие для разных команд разработчиков, а не держать все в одной куче. Если же один-два - то вообще не принципиально.