Можете по поводу фасада к апи поподробнее ответить? Я не понял как фасад к апи решает проблему написания множества обработчиков роутов в REST.
Например есть 10 классов, в каждом по 3 метода: добавить, изменить, удалить. Итого 30 методов к которым может обратиться каждый клиент API.
Автор статьи пишет, что для RESTful мы должны будем прописать в коде все 30 роутов, а для JSON-RPC всего 10. Вы пишите, что нужно просто сделать фасад к апи, а не прописывать роут для каждого из 30 методов. Как вы предлагаете используя фасад к апи устранить необходимость прописывания 30 роутов?
Если статья называется "RTMP-поток",то где описание самого протокола, из чего он состоит, какие данные передает. Каким способом закодировать и предать / раскодировать и показать в своей программе? Например в приложении Android?
Так Git же тоже где-то в "облаке". Есть центральный сервер где лежат все файлы и они синхронизируются с устройствами, и этот сервер должен быть всегда включен. Если параноить, то нужно домой покупать сервер, обеспечивать ему бесперебойную работу, пару каналов от разных провайдеров, отдельный генератор на случай выключения электричества )
Когда-нибудь они распробуют каково это, общаться с учетной системой на человеческом языке
Пользователям учетных систем нужны данные хранящиеся в них и анализ этих данных, а не просить ИИ код написать. Для этого датасеты разработки на языке 1с не нужны. Нужен какой то ИИ для работы с BI, для этого ИИ должен понимать где какие данные хранятся, анализировать их и выдавать результат.
Хорошая система для ведения заметок, но со смартфонами проблема. Прежде чем открыть Obsidian необходимо синхронизировать файлы через другое приложение (пользуюсь FolderSync). А автоматически синхронизация не проходит, то ли Android вырубает фоновые задачи, то ли еще что то.
Для ПК сами файлы у меня на Яндекс.Диск и синхронизируются между всеми компами автоматом.
// Get возвращает пользователя по ID, если он существует в картеfunc (im *IdentityMap) Get(id int) *User { im.RLock() defer im.RUnlock() return im.users[id]}
При каждом обращении к методу Get сначала проверяется наличие объекта в карте, и если он есть, возвращаем его, не обращаясь к БД.
А если нет в "карте" то паника?
Должна же быть проверка на ошибку в Get. Потом если в кеше нет, обратится к БД. И там тоже обработать все возможные ошибки и т.п.
Это не статья, а просто ссылка на Github. Еще и хабы выбраны про программирование, а в статье ни одной строчки кода.
В статье нужно описать, чем ваше решение лучше аналогов (Diesel, SeaORM, Sqlx), какие походы использовали, с какими трудностями столкнулись, в чем подобие именно Hibernate и т.п.
var pending []Item // заполняется процедурой получения данных, очищается процедурой отправки отчетов о работе
// отправляем информацию о завершенной задаче в канал s.updates
for {
var first Item
var updates chan Item
if len(pending) > 0 {
first = pending[0]
updatesChan = s.updates // укажем реальный канал, чтобы разблокировать исполнение в select
}
select {
case updatesChan <- first: // отправляем первый элемент, заблокируется, если канал s.updates = nil
pending = pending[1:] // когда отправка удаласть, удаляем первый элемент из массива перерписваивая слайс без него
}
}
Зачем здесь канал updates который не используется далее по коду?
При len(pending) = 0 в канал updatesChan, который ссылается на s.updates (не nil), будет передан first который nil. При этом в данном коде переменная updatesChan выше скопа цикла, следовательно при len(pending) = 0 она все равно будет указывать на s.updates (т.е. updatesChan = s.updates в условии бесмыслено if len(pending) > 0)
В случае выявления ошибки в конфигурации 1с можно найти программиста/франч который быстро ее исправит (условно в течении часа) и бизнес продолжить работать. В случае выявления ошибки в СБИС нужно ждать дни или недели пока ее исправят. Или у вас в СБИС не бывает ошибок?
Если вдруг окажется, что выбора у вас нет и в офис ходить придется, рассмотрите вариант съема квартиры неподалеку. Это уберет часть негатива, так что на дорогу не придется тратить много времени.
А еще устроить детей в новую школу/садик, жене найти новую работу рядом с новой съемной квартирой. И так каждые несколько лет при смене работы. Ну и квартиры не покупать.
Кстати недавно была статья про зп и там указано, что больше всего получают удаленщики. С чем это связано? Возможно с тем, что уровень менеджмента в компаниях без удаленки ниже, чем в компаниях с удаленкой.
На всех языках разработки все стремятся обобщать код, делать абстракции, убирать "копи-пасту" как источник ошибок. Вы же предлагаете все делать наоборот.
Возьмём ваш же пример. Переименуем одно измерение и теперь, вместо того, что бы в одном месте изменить название мы должны сделать это, условно, 10 раз в 10 документах. Т.е. трудозатраты и вероятность ошибок выше.
В УТ у каждого документа в менеджере описаны свои процедуры для проведения. Это не одна общая процедура на все документы, это вызов конкретных процедур каждого документа через одну общую процедуру. Архитектура такая. Сделано для того, что бы разные "доработчики" не придумывали свои алгоритмы, кто во что горазд, а использовали унифицированный алгоритм. Это упрощает поддержку кода.
Можете по поводу фасада к апи поподробнее ответить? Я не понял как фасад к апи решает проблему написания множества обработчиков роутов в REST.
Например есть 10 классов, в каждом по 3 метода: добавить, изменить, удалить. Итого 30 методов к которым может обратиться каждый клиент API.
Автор статьи пишет, что для RESTful мы должны будем прописать в коде все 30 роутов, а для JSON-RPC всего 10. Вы пишите, что нужно просто сделать фасад к апи, а не прописывать роут для каждого из 30 методов. Как вы предлагаете используя фасад к апи устранить необходимость прописывания 30 роутов?
В планах есть Rust добавить в число поддерживаемых языков?
Если статья называется "RTMP-поток",то где описание самого протокола, из чего он состоит, какие данные передает. Каким способом закодировать и предать / раскодировать и показать в своей программе? Например в приложении Android?
Зачем нужен Spin?
В документации Leptos он не указан (раздел 14. Part 2: Server Side Rendering) и SSR работает без Spin
Так Git же тоже где-то в "облаке". Есть центральный сервер где лежат все файлы и они синхронизируются с устройствами, и этот сервер должен быть всегда включен. Если параноить, то нужно домой покупать сервер, обеспечивать ему бесперебойную работу, пару каналов от разных провайдеров, отдельный генератор на случай выключения электричества )
Пользователям учетных систем нужны данные хранящиеся в них и анализ этих данных, а не просить ИИ код написать. Для этого датасеты разработки на языке 1с не нужны. Нужен какой то ИИ для работы с BI, для этого ИИ должен понимать где какие данные хранятся, анализировать их и выдавать результат.
Хорошая система для ведения заметок, но со смартфонами проблема. Прежде чем открыть Obsidian необходимо синхронизировать файлы через другое приложение (пользуюсь FolderSync). А автоматически синхронизация не проходит, то ли Android вырубает фоновые задачи, то ли еще что то.
Для ПК сами файлы у меня на Яндекс.Диск и синхронизируются между всеми компами автоматом.
Самая важная часть - "Как оплатить лицензию" описана тезисно.
Как удаленно завести банковскую карту иностранного банка являясь гражданином России, еще и с правильным ФИО?
А если нет в "карте" то паника?
Должна же быть проверка на ошибку в Get. Потом если в кеше нет, обратится к БД. И там тоже обработать все возможные ошибки и т.п.
Где вы нашли такое определение DDD?
В Wiki ничего про микросервисы не сказано:
https://ru.wikipedia.org/wiki/Предметно-ориентированное_проектирование
https://en.wikipedia.org/wiki/Domain-driven_design
Это не статья, а просто ссылка на Github. Еще и хабы выбраны про программирование, а в статье ни одной строчки кода.
В статье нужно описать, чем ваше решение лучше аналогов (Diesel, SeaORM, Sqlx), какие походы использовали, с какими трудностями столкнулись, в чем подобие именно Hibernate и т.п.
Где в статье хоть один текст запроса на языке запросов 1с?
Где ответы copilot именно текстом для 1с? В статье MySQL.
Статья должна называться "Пример дивергентного мышления ИИ при использовании MySQL запрос copilot"
Зачем здесь канал updates который не используется далее по коду?
При len(pending) = 0 в канал updatesChan, который ссылается на s.updates (не nil), будет передан first который nil. При этом в данном коде переменная updatesChan выше скопа цикла, следовательно при len(pending) = 0 она все равно будет указывать на s.updates (т.е. updatesChan = s.updates в условии бесмыслено if len(pending) > 0)
В случае выявления ошибки в конфигурации 1с можно найти программиста/франч который быстро ее исправит (условно в течении часа) и бизнес продолжить работать. В случае выявления ошибки в СБИС нужно ждать дни или недели пока ее исправят. Или у вас в СБИС не бывает ошибок?
А еще устроить детей в новую школу/садик, жене найти новую работу рядом с новой съемной квартирой. И так каждые несколько лет при смене работы. Ну и квартиры не покупать.
Кстати недавно была статья про зп и там указано, что больше всего получают удаленщики. С чем это связано? Возможно с тем, что уровень менеджмента в компаниях без удаленки ниже, чем в компаниях с удаленкой.
Почему вы не обрабатываете ошибки? Ведь в случае ошибок получится неопределенное поведение.
После машинного перевода текст должен редактировать специалист, разбирающийся в теме.
Это не маршрут, а обработчик.
Обработчик - это Fn(). Fn() должен реализовывать IntoResponse ?
Эта функция - реализация перечисления?
"Переводы" такого качества не нужны! Делайте пересказ своими словами.
Но ведь 0 не передается через материальный носитель. Ничего не "долетает" до точки "B" в случае "передачи" нуля.
На всех языках разработки все стремятся обобщать код, делать абстракции, убирать "копи-пасту" как источник ошибок. Вы же предлагаете все делать наоборот.
Возьмём ваш же пример. Переименуем одно измерение и теперь, вместо того, что бы в одном месте изменить название мы должны сделать это, условно, 10 раз в 10 документах. Т.е. трудозатраты и вероятность ошибок выше.
В УТ у каждого документа в менеджере описаны свои процедуры для проведения. Это не одна общая процедура на все документы, это вызов конкретных процедур каждого документа через одну общую процедуру. Архитектура такая. Сделано для того, что бы разные "доработчики" не придумывали свои алгоритмы, кто во что горазд, а использовали унифицированный алгоритм. Это упрощает поддержку кода.
А могли бы экономить 828 млн рублей в год если бы сотрудники работали на удаленке...