Спасибо за дополнение! Цель статьи — показать, как получить соответствующие данные. Как ими воспользоваться, каждый волен решать самостоятельно. Можно отображать для пользователя, сразу после получения, можно, как вы предложили, разбить по слоям и только потом использовать.
Swagger будет всегда содержать актуальную документацию, как и если использовать, например, файл XML-документации, который будет находиться в той же директории, что и скомпилированный файл DLL или EXE. Имя файла будет соответствовать имени сборки, например MyProject.xml. XML-документация может быть использована для создания HTML-документации при помощи инструментов, таких как DocFX или Sandcastle.
xml
<PropertyGroup>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>
Добрый день! Спасибо за дискуссию. Поясним: п. 1-3. В статье указан простой пример и функция может быть большего размера. Да, я согласен, что имя функции должно отражать, "что я выполняю", но xml-комментарии не только помогают быстрее прочитать назначение, но и быстрее интерпретировать его на родной язык разработчиков. То же самое относится к параметрам и возвращаемым значениям. Так же с легкостью импортируются, например, в swagger или с помощью другого инструмента импорта xml-документации. п. 4-5. Описывать ошибки — дополнительный способ защиты. Внутри его так же можно описать. Сам эксепшн по сути также создан для того, чтобы уберечь нас от неожиданных событий.
Спасибо, что поделились! Никто не запрещает использовать любые удобные для вас методы. Автор рассказал о своем личном опыте, который может кому-то помочь и упростить его код.
Выше написал ответ на первый комментарий, на второй тоже есть что добавить:
зачастую можно встретить задачи, где оба вида каналов можно использовать, Если часто приходится перекидываться сообщениями, через каналы лишнее выделение буфера будет однозначно плюсом. В статье и не сказано, что следует использовать только буферизованные каналы, речь идет о случаях, где увеличение буфера не будет пустой траты памяти
Вы полностью правы. 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/
Спасибо за дополнение! Цель статьи — показать, как получить соответствующие данные. Как ими воспользоваться, каждый волен решать самостоятельно. Можно отображать для пользователя, сразу после получения, можно, как вы предложили, разбить по слоям и только потом использовать.
Swagger будет всегда содержать актуальную документацию, как и если использовать, например, файл XML-документации, который будет находиться в той же директории, что и скомпилированный файл DLL или EXE. Имя файла будет соответствовать имени сборки, например MyProject.xml. XML-документация может быть использована для создания HTML-документации при помощи инструментов, таких как DocFX или Sandcastle.
Добрый день! Спасибо за дискуссию. Поясним:
п. 1-3. В статье указан простой пример и функция может быть большего размера. Да, я согласен, что имя функции должно отражать, "что я выполняю", но xml-комментарии не только помогают быстрее прочитать назначение, но и быстрее интерпретировать его на родной язык разработчиков. То же самое относится к параметрам и возвращаемым значениям. Так же с легкостью импортируются, например, в swagger или с помощью другого инструмента импорта xml-документации.
п. 4-5. Описывать ошибки — дополнительный способ защиты. Внутри его так же можно описать. Сам эксепшн по сути также создан для того, чтобы уберечь нас от неожиданных событий.
Спасибо, что поделились! Никто не запрещает использовать любые удобные для вас методы. Автор рассказал о своем личном опыте, который может кому-то помочь и упростить его код.
Спасибо за внимательность, исправлено
Всем спасибо за замечания! Внесли изменения, теперь статья более актуальна)
К сожалению, из-за 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/
Спасибо за примечание! Добавил в статью