Если продолжить, для n≥4 дальше сдвиг будет отрицательным (влево), чтобы удержать равновесие, поэтому максимальное достигается при n=4 (т.е. 4 кирпича в конструкции), и оно равно 3L/4.
"Вдруг получится дебаг..." Осознанные сни не предназначены для этого (я умею выходить в осознанный сон) А вот перед сном и во сне подсознание может решить много чего :-)
1-ое правило нормализации БД: "Запрещается хранить разные по смыслу значения в одной колоноке" !
status: "active" | "inactive" | "deleted" Все три значения разные по смыслу, это то же самое что дату рождения и дату смерти хранить в одной колонке...
Если базы данных разные - то конечно надо каждому сервису делать свой crud service. Если база данных одна - то хватит одного crud service для всех микросервисов
Мой круд кодогенератор работает хорошо, используем в работе. Экономит очень много времени программиста. Также его скачивают (используют) по 100 человек/каждые 2 недели (статистика из гитхаба)
Шаблоны кода можно изменять, можете сделать любой нейминг
Тимлид есть, проекты развиваются
Компания Росатом
Репозиторию уже 3 года, и реальным рабочим проектам тоже столько же.
Перешёл с языка 1С на golang 4 года назад
Слово "Otvet" любой поймёт что означает, и для чего нужно. У англицизмов неочевидное назначение, слово "Result" может означать что угодно, а слово "Ответ" означает всегда одинаково - что вернётся в результате работы функции
Debezium must Die Debezium какчает разные таблицы с разной скоростью и получается неконсистентность, когда например есть document_id=100500, а документа нет с таким id=100500 поэтому нельзя использовать Debezium.
Очень красиво, интересно, идея хорошая :-) Только надо какую-то практичную пользу от этого придумать... Например слева отображать только активы, справа пассивы, слева дебет, справа кредит у активных счетов, и наоборот для пассивных - тогда появится реальная польза :-)
есть ещё один хороший способ хранить деньги: сделать отдельные 2 колонки с целыми числами, отдельно для целой части, отдельно для дробной части * 1000000000.
Используется в Тинькофф, tinkoff api Я использую float64 т.к. мне не важны копейки :-)
Написано всё правильно :-) у меня есть много чего в гитхабе :-) https://github.com/ManyakRus остальные коллеги не пишут ничего в гитхаб т.к. не делают ничего полезного ни для работы, ни для всех, ни для себя.
Написано всё правильно, кроме отдельных случаев: а) если это большое монолитное приложение б) если много джунов, которым надо ограничить возможность всё испортить.
Все эти архитектуры написаны для больших монолитов, микросервисов в то время не было.
Если не было задания от работадателя - то всё написанное ПО принадлежит автору (программисту) :-) например nginx Работадателю принадлежит то что он просил (давал задания)
Задача 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 недели
(статистика из гитхаба)
Шаблоны кода можно изменять, можете сделать любой нейминг
Тимлид есть, проекты развиваются
Компания Росатом
Репозиторию уже 3 года, и реальным рабочим проектам тоже столько же.
Перешёл с языка 1С на golang 4 года назад
Слово "Otvet" любой поймёт что означает, и для чего нужно.
У англицизмов неочевидное назначение, слово "Result" может означать что угодно, а слово "Ответ" означает всегда одинаково - что вернётся в результате работы функции
У нас есть поля типа uuid, работает с ними хорошо, будет тип golang uuid.UUID. ID типа uuid не пробовал.
Debezium must Die
Debezium какчает разные таблицы с разной скоростью и получается неконсистентность,
когда например есть document_id=100500, а документа нет с таким id=100500
поэтому нельзя использовать Debezium.
Очень красиво, интересно, идея хорошая :-)
Только надо какую-то практичную пользу от этого придумать...
Например слева отображать только активы, справа пассивы,
слева дебет, справа кредит у активных счетов, и наоборот для пассивных -
тогда появится реальная польза :-)
https://github.com/ManyakRus/crud_generator
кодогенератор делает код для CRUD операций,
а также для сложных объектов - заполняет вложенные структуры из внешних ключей.
Так ещё лучше :-)
и в итоге вас забанят за использование нейронок :-(
это статья - чистосердечное признание в нарушении правил яндекс музыки
Очень хорошая вещь :-) теоретически.
Практически испытаю попозже,
хотел сам такое же сделать.
есть ещё один хороший способ хранить деньги:
сделать отдельные 2 колонки с целыми числами, отдельно для целой части, отдельно для дробной части * 1000000000.
Используется в Тинькофф, tinkoff api
Я использую float64 т.к. мне не важны копейки :-)
Написано всё правильно :-)
у меня есть много чего в гитхабе :-)
https://github.com/ManyakRus
остальные коллеги не пишут ничего в гитхаб т.к. не делают ничего полезного ни для работы, ни для всех, ни для себя.
Написано всё правильно,
кроме отдельных случаев:
а) если это большое монолитное приложение
б) если много джунов, которым надо ограничить возможность всё испортить.
Все эти архитектуры написаны для больших монолитов, микросервисов в то время не было.
Тут слишком много букв, поэтому ничего не понятно (и много неправильно)
Как должно быть:
а) для библиотек:
ошибки не выводить в лог, т.к. у всех логгеры разные
делать "Текстовый wrapping %w" ошибок
все ошибки возвращать
не делать панику (или fatal)
б) для остальных приложений:
все ошибки выводить в лог сразу же в месте появления ошибки, даже если ошибку возвращаем наверх.
при возвращении ошибки наверх - надо ошибку вывести в лог ещё раз, второй раз с новым "Текстовый wrapping %w" ошибок
делать "Текстовый wrapping %w" ошибок
ошибки старться обработать на месте, возвращать как можно меньше ошибок
при старте приложения при ошибке сразу делать панику, после старта паники стараться не делать.
Если не было задания от работадателя - то всё написанное ПО принадлежит автору (программисту) :-)
например nginx
Работадателю принадлежит то что он просил (давал задания)
надо делать отдельный пакет для этого, а не в main,
например вот такой:
https://github.com/ManyakRus/starter/blob/main/stopapp/stopapp.go