Выше написал ответ на первый комментарий, на второй тоже есть что добавить:
зачастую можно встретить задачи, где оба вида каналов можно использовать, Если часто приходится перекидываться сообщениями, через каналы лишнее выделение буфера будет однозначно плюсом. В статье и не сказано, что следует использовать только буферизованные каналы, речь идет о случаях, где увеличение буфера не будет пустой траты памяти
Вы полностью правы. Grow выделяет нужную память под срез, который находится внутри strings.Builder, чем ускоряет конкатенацию в моем примере в целых два раза
Спасибо, ценное замечание. В этой статье sync.Pool не рассматривается в полной мере, как и некоторые остальные приемы. Был предоставлен минимум, необходимый для понимания. Если пользователя заинтересует этот инструмент, он пойдет и изучит его подробнее. В примере с sync.Pool я и правда не показал всю работу, но это сделано было в угоду простоте.
Если бы я в каждом примере дополнительно сервера запускал или с БД работал, было бы труднее донести информацию. А так люди, которые впервые увидят этот же sync.Pool, заинтересуются и начнут искать иные источники информации для понимания. Отдельное спасибо за ссылку на статью!
sync.Pool предназначен для повторного использования объектов между горутинами, благодаря чему нет необходимости выделять новую память. Мы берем уже выделенную память, используем и кладем назад.
В первую очередь, sync.Pool снижает нагрузку на сборщик мусора (не отслеживает и не очищает объекты). В случае использования обычного слайса сборщик мусора будет очищать уже использованные объекты. То есть sync.Pool выгодно использовать, когда приложение требует работы с короткоживущими объектами.
Я запустил ваш бенчмарк — и да, в этом случае sync.Pool будет немного, но все же проигрывать в скорости (протестировал на двух устройствах)
func BenchmarkDefault(b *testing.B) {
var dataDefault = make([]int, 0, 10000)
for i := 0; i < b.N; i++ {
dataDefault = processDefault(dataDefault[:])
}
}
func BenchmarkPool(b *testing.B) {
for i := 0; i < b.N; i++ {
data := dataPool.Get().([]int)
data = processPool(data)
dataPool.Put(data)
}
}
goos: linux
goarch: amd64
pkg: test/benchmarks
cpu: 11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz
BenchmarkDefault-12 356412 3235 ns/op
BenchmarkPool-12 341449 3453 ns/op
goos: windows
goarch: amd64
pkg: awesomeProject
cpu: Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz
BenchmarkDefault-4 207806 5642 ns/opBenchmarkPool-4 207349 5705 ns/op
Тем, что нужно прописывать много сущностей и их взаимосвязи, а потом их поддерживать, так как они могут меняться. Маленькая вариативность для запросов. Например, у нас есть поиск по 5 параметрам, где все они не обязательно могут присутствовать. Соответственно, нужно делать разные запросы, которые будут содержать в себе разный набор параметров, либо сильно всё усложнять.
В статье мы рассматриваем запрос заказчика на конкретный инструмент, который собирает статистику по эмоциях. С одной стороны, как клиент будет интерпретировать полученную информацию — это уже его дело :) С другой — если глубже и детальнее погрузиться в тонкости физиогномики, можно допилить систему и сделать результаты более детальными.
Напомним, что это пет-проект :) Ситуация с учениками и преподавателями вымышленная, но она дает четкое понимание, как можно проработать и использовать такой механизм использования ИИ до внедрения в приложения.
Интерпретировать работу преподавателя по таким показателям можно по-разному. Например, 90% эмоций «хэппи» можно трактовать так, будто студенты не слушали преподавателя, а просто веселились. А вот соотношение «нейтральных» и «веселых» 50 на 50 может говорить, что преподаватель интересно и с юмором вел занятие :)
Да всё верно, это функции, но алгоритмами они называются, так как реализуют конкретную последовательность действий, например: поиск, сортировку, разбиение и т.д.
Насколько я смог раскопать, кодогенерацию используют только в связке с интерфейсами для создания «классических» мапперов. Возможно, я что-то упустил, но могу еще посоветовать другую статью, где некоторые аспекты освещены более подробно: https://code-maze.com/mapster-aspnetcore-introduction/
Составление отчета из отбора, допустим, 50 позиций номенклатуры — не считается признаком хаоса в учете. Этим часто занимаются бухгалтеры, когда необходимо посмотреть оборотно-сальдовую ведомость. И поскольку в бухгалтерии одним из важных инструментов является Excel, то удобно сформировать типовой отчет, загрузив значения для отбора непосредственно из Excel-документа.
Стоит учитывать тот момент, что 1С-системы могут отличаться, сочетая в себе несколько разных конфигураций. К примеру, справочник номенклатуры может иметь структуру не от бухгалтеров, а от производственников, поэтому может возникнуть необходимость в таких отборах. Также бухгалтер может только приступить к работе на предприятии, не успев обновить структуру справочников.
Кроме того большая часть отчетов построена на СКД.
Обработка в конфигурации «1С: Бухгалтерия предприятия 3.0» предназначена для таких типовых отчетов, как ОСВ, Обороты, Карточка счета и т.д. Разумеется, все они построены на СКД и обработка прекрасно работает с ними.
Есть более простые и удобные как для пользователя так и для программиста методы.
Поделитесь примерами? Описанный в статье способ решает простую, но довольно частую проблему, облегчая формирование отбора в стандартных бухгалтерских отчетах. Если вы знаете неручной способ, как загрузить отбор в отчет, пожалуйста, поделитесь.
Спасибо, что обратили внимание. У нас точно не было цели запутать читателей. Поэтому уточнили формулировку — речь идет именно о необлагаемом доходе. Подробный пример расчета такого налога приводим в посте.
Мы выносили большинство данных, которые могут меняться, в отдельные файлы, поэтому с минорной поддержкой могут справиться DevOps или разработчики клиента.
Но если на сервисе появятся новые сценарии, то понадобится сотрудник, который будет заниматься тестами. Лучше, если это будет не совмещающий разработчик, а отдельный SDET. Так задачи разработки и написания тестов будут идти параллельно, и проект реализуется быстрее.
то все просто — на момент разработки этого кода мы только начинали свое знакомство с электронными подписями и просто не знали об его существовании. Наше решение покрывало наши потребности, поэтому не было необходимости использовать что-то другое.
Всем спасибо за замечания! Внесли изменения, теперь статья более актуальна)
К сожалению, из-за NDA нет возможности опубликовать код целиком
Выше написал ответ на первый комментарий, на второй тоже есть что добавить:
зачастую можно встретить задачи, где оба вида каналов можно использовать, Если часто приходится перекидываться сообщениями, через каналы лишнее выделение буфера будет однозначно плюсом. В статье и не сказано, что следует использовать только буферизованные каналы, речь идет о случаях, где увеличение буфера не будет пустой траты памяти
Вы полностью правы. Grow выделяет нужную память под срез, который находится внутри strings.Builder, чем ускоряет конкатенацию в моем примере в целых два раза
Спасибо, ценное замечание. В этой статье sync.Pool не рассматривается в полной мере, как и некоторые остальные приемы. Был предоставлен минимум, необходимый для понимания. Если пользователя заинтересует этот инструмент, он пойдет и изучит его подробнее. В примере с sync.Pool я и правда не показал всю работу, но это сделано было в угоду простоте.
Если бы я в каждом примере дополнительно сервера запускал или с БД работал, было бы труднее донести информацию. А так люди, которые впервые увидят этот же sync.Pool, заинтересуются и начнут искать иные источники информации для понимания. Отдельное спасибо за ссылку на статью!
Рад, что вам было полезно!
sync.Pool предназначен для повторного использования объектов между горутинами, благодаря чему нет необходимости выделять новую память. Мы берем уже выделенную память, используем и кладем назад.
В первую очередь, sync.Pool снижает нагрузку на сборщик мусора (не отслеживает и не очищает объекты). В случае использования обычного слайса сборщик мусора будет очищать уже использованные объекты. То есть sync.Pool выгодно использовать, когда приложение требует работы с короткоживущими объектами.
Я запустил ваш бенчмарк — и да, в этом случае sync.Pool будет немного, но все же проигрывать в скорости (протестировал на двух устройствах)
Тем, что нужно прописывать много сущностей и их взаимосвязи, а потом их поддерживать, так как они могут меняться. Маленькая вариативность для запросов. Например, у нас есть поиск по 5 параметрам, где все они не обязательно могут присутствовать. Соответственно, нужно делать разные запросы, которые будут содержать в себе разный набор параметров, либо сильно всё усложнять.
В статье мы рассматриваем запрос заказчика на конкретный инструмент, который собирает статистику по эмоциях. С одной стороны, как клиент будет интерпретировать полученную информацию — это уже его дело :) С другой — если глубже и детальнее погрузиться в тонкости физиогномики, можно допилить систему и сделать результаты более детальными.
Напомним, что это пет-проект :) Ситуация с учениками и преподавателями вымышленная, но она дает четкое понимание, как можно проработать и использовать такой механизм использования ИИ до внедрения в приложения.
Интерпретировать работу преподавателя по таким показателям можно по-разному. Например, 90% эмоций «хэппи» можно трактовать так, будто студенты не слушали преподавателя, а просто веселились. А вот соотношение «нейтральных» и «веселых» 50 на 50 может говорить, что преподаватель интересно и с юмором вел занятие :)
Спасибо, хорошая тема, согласны)
Да всё верно, это функции, но алгоритмами они называются, так как реализуют конкретную последовательность действий, например: поиск, сортировку, разбиение и т.д.
Спасибо за замечание! Добавил еще один раздел с примерами поинтереснее)
Насколько я смог раскопать, кодогенерацию используют только в связке с интерфейсами для создания «классических» мапперов. Возможно, я что-то упустил, но могу еще посоветовать другую статью, где некоторые аспекты освещены более подробно: https://code-maze.com/mapster-aspnetcore-introduction/
Спасибо за примечание! Добавил в статью
Наличие такие отборов признак хаоса в учете.
Составление отчета из отбора, допустим, 50 позиций номенклатуры — не считается признаком хаоса в учете. Этим часто занимаются бухгалтеры, когда необходимо посмотреть оборотно-сальдовую ведомость. И поскольку в бухгалтерии одним из важных инструментов является Excel, то удобно сформировать типовой отчет, загрузив значения для отбора непосредственно из Excel-документа.
Стоит учитывать тот момент, что 1С-системы могут отличаться, сочетая в себе несколько разных конфигураций. К примеру, справочник номенклатуры может иметь структуру не от бухгалтеров, а от производственников, поэтому может возникнуть необходимость в таких отборах. Также бухгалтер может только приступить к работе на предприятии, не успев обновить структуру справочников.
Кроме того большая часть отчетов построена на СКД.
Обработка в конфигурации «1С: Бухгалтерия предприятия 3.0» предназначена для таких типовых отчетов, как ОСВ, Обороты, Карточка счета и т.д. Разумеется, все они построены на СКД и обработка прекрасно работает с ними.
Есть более простые и удобные как для пользователя так и для программиста методы.
Поделитесь примерами? Описанный в статье способ решает простую, но довольно частую проблему, облегчая формирование отбора в стандартных бухгалтерских отчетах. Если вы знаете неручной способ, как загрузить отбор в отчет, пожалуйста, поделитесь.
Спасибо, что обратили внимание. У нас точно не было цели запутать читателей. Поэтому уточнили формулировку — речь идет именно о необлагаемом доходе. Подробный пример расчета такого налога приводим в посте.
Мы выносили большинство данных, которые могут меняться, в отдельные файлы, поэтому с минорной поддержкой могут справиться DevOps или разработчики клиента.
Но если на сервисе появятся новые сценарии, то понадобится сотрудник, который будет заниматься тестами. Лучше, если это будет не совмещающий разработчик, а отдельный SDET. Так задачи разработки и написания тестов будут идти параллельно, и проект реализуется быстрее.
Истинно быль) Конечно, у нас по процессам обязательна полная передача всего кода и документации при завершении работ, так было и здесь
Если вы говорите про этот метод:
x500name.getRDN()то все просто — на момент разработки этого кода мы только начинали свое знакомство с электронными подписями и просто не знали об его существовании. Наше решение покрывало наши потребности, поэтому не было необходимости использовать что-то другое.
А вообще соглашусь, что, например, через
x500name.getRDNs(BCStyle.SURNAME)получать фамилию проще