Всё равно надо писать свои функции CRUD-операций (Create+Read+Update+Delete), ORM эти функции сам не пишет, он только помогает их легче написать. Программисту нужны готовые CRUD-операции, а не ORM. ORM это лишняя прослойка между программистом и БД. А готовые функции CRUD-операций сам напишет кодогенератор: https://github.com/ManyakRus/crud_generator
1) Не надо останавливать БпЛА, надо чтоб он взорвался на сетке, не долетев куда надо это расстояние до сетки 10-20 метров - тогда ущерб будет всего 5-10% от возможного - этого достаточно :-) 2) ниже метталической сетки повесить и обычную мелкую сеть от мелких сбрасываемых гранат
1) Всё правильно написано для случая если я единственный программист, или хотя бы основной, или главный, или методы приватные которые точно никто не будет вызывать... 2) Если несколько программистов: ты должен доказать что виноват не ты а кто-то другой, если ты согласишься принять и использовать неправильное значение - значит ты сам и виноват.
Ничего не понял, в новом формате такой же JSON как и было с кучей фигурных скобок = ужасно.
Самое хорошее: 1) для мелких конфигов: .ENV (до 100 строк) 2) для средних конфигов: .INI (до 1000 строк) 3) для сложных конфигов: .TOML (не пользовался, но это улучшенный .INI) 4) для данных (не конфигов): .JSON 5) для данных в виде таблиц: .CSV 6) YAML - надо знать, но лучше не внедрять самому
Я покупаю TMON в 23:49, и продаю в 10:00 каждый день. Какая польза банку от этих денег, которые лежат там только ночью ? Днём деньги ещё можно как-то использовать, а ночью вообще никак...
Если продолжить, для n≥4 дальше сдвиг будет отрицательным (влево), чтобы удержать равновесие, поэтому максимальное достигается при n=4 (т.е. 4 кирпича в конструкции), и оно равно 3L/4.
"Вдруг получится дебаг..." Осознанные сни не предназначены для этого (я умею выходить в осознанный сон) А вот перед сном и во сне подсознание может решить много чего :-)
1-ое правило нормализации БД: "Запрещается хранить разные по смыслу значения в одной колоноке" !
status: "active" | "inactive" | "deleted" Все три значения разные по смыслу, это то же самое что дату рождения и дату смерти хранить в одной колонке...
Если базы данных разные - то конечно надо каждому сервису делать свой crud service. Если база данных одна - то хватит одного crud service для всех микросервисов
Мой круд кодогенератор работает хорошо, используем в работе. Экономит очень много времени программиста. Также его скачивают (используют) по 100 человек/каждые 2 недели (статистика из гитхаба)
Не написали самое главное:
Выводы ?
- какая ИИ лучше
- какая ИИ дешевле
- у кого есть API
- и др.
без выводов это всё бесполезно :-(
С тегами итак всё хорошо, не надо их трогать.
Можно сделать "стандартизацию" тегов чтоб было у всех похоже
Можно сделать проверку синтаксиса тегов, только не линтерами, а каждая внешняя библиотека сама будет описывать список своих тегов.
Такие простые запросы вообще писать не надо вручную,
кодогенератор должен их написать сам,
без ORM, на чистом pgx:
https://github.com/ManyakRus/crud_generator
Сделали то от чего пытались уйти: "...это уже тень прошлого, постфактум."
прекрасно, я тоже такую очередь хочу :-)
если ссылка на github ?
Всё равно надо писать свои функции CRUD-операций (Create+Read+Update+Delete),
ORM эти функции сам не пишет, он только помогает их легче написать.
Программисту нужны готовые CRUD-операции, а не ORM.
ORM это лишняя прослойка между программистом и БД.
А готовые функции CRUD-операций сам напишет кодогенератор:
https://github.com/ManyakRus/crud_generator
На MSSQL всегда делали REBUILD индексов каждую ночь :-)
А на PostgreSQL это тоже надо делать ?
Стоит ли его делать для больших не 1С баз ?
1) Не надо останавливать БпЛА,
надо чтоб он взорвался на сетке, не долетев куда надо это расстояние до сетки 10-20 метров -
тогда ущерб будет всего 5-10% от возможного - этого достаточно :-)
2) ниже метталической сетки повесить и обычную мелкую сеть от мелких сбрасываемых гранат
Logrus пишет в лог ещё и имя функции, имя файла .go, номер строки в исходном коде где была ошибка :-)
Поэтому Logrus до сих пор лучше всех
1) Всё правильно написано для случая если я единственный программист,
или хотя бы основной, или главный, или методы приватные которые точно никто не будет вызывать...
2) Если несколько программистов: ты должен доказать что виноват не ты а кто-то другой,
если ты согласишься принять и использовать неправильное значение - значит ты сам и виноват.
1) для этого надо покупать платный Postgres Pro ?
2) есть такие же очереди и для бесплатного PostgreSQL :-)
тоже через расширения устанавливаются.
Ничего не понял, в новом формате такой же JSON как и было с кучей фигурных скобок = ужасно.
Самое хорошее:
1) для мелких конфигов: .ENV
(до 100 строк)
2) для средних конфигов: .INI
(до 1000 строк)
3) для сложных конфигов: .TOML
(не пользовался, но это улучшенный .INI)
4) для данных (не конфигов): .JSON
5) для данных в виде таблиц: .CSV
6) YAML - надо знать, но лучше не внедрять самому
Я покупаю TMON в 23:49, и продаю в 10:00 каждый день.
Какая польза банку от этих денег, которые лежат там только ночью ?
Днём деньги ещё можно как-то использовать, а ночью вообще никак...
Задача 1.
Deepseek:
Для n=4: D=L/2+L/4+0=3L/4.
Если продолжить, для n≥4 дальше сдвиг будет отрицательным (влево), чтобы удержать равновесие, поэтому максимальное достигается при n=4 (т.е. 4 кирпича в конструкции), и оно равно 3L/4.
Ответ:
3L/4
Всё правильно написано.
Не надо привыкать к глюкам, надо чтоб глюков не было.
Но это всё равно мелкие недостатки, не страшно
"Вдруг получится дебаг..."
Осознанные сни не предназначены для этого (я умею выходить в осознанный сон)
А вот перед сном и во сне подсознание может решить много чего :-)
Моё предложение:
1) сделать "+=" для error, чтоб ошибки складывались (конкантенация)
err := One()
err += Two()
2) сделать "?=" для error, чтоб функция не вызывалась если уже есть ошибка
err := One()
err ?= Two()
1-ое правило нормализации БД:
"Запрещается хранить разные по смыслу значения в одной колоноке" !
status: "active" | "inactive" | "deleted"Все три значения разные по смыслу,
это то же самое что дату рождения и дату смерти хранить в одной колонке...
Если базы данных разные - то конечно надо каждому сервису делать свой crud service.
Если база данных одна - то хватит одного crud service для всех микросервисов
Мой круд кодогенератор работает хорошо, используем в работе.
Экономит очень много времени программиста.
Также его скачивают (используют) по 100 человек/каждые 2 недели
(статистика из гитхаба)