Новичкам в разработке мы обычно советуем начать с этих книг, независимо от языка программирования: • «Чистый код» Р.Мартина • «Грокаем алгоритмы» А.Бхаргава — очень помогает с базовыми пониманием, что такое алгоритмы, какие бывают и т.д. • «2022. System Design. Подготовка к сложному интервью» — очень рекомендуем прочитать 1 и 2 главу всем, кто планирует работать с микросервисами и т.д. • «TDD Экстремальное программирование» К.Бека — нужно ознакомиться с водной частью (1 и 2 глава), дальше идет уже сильно специфическая тематика.
Для тех, кто только задумался о том, чтобы освоить Golang, можем порекомендовать «Head First. Изучаем Go» Джея Макгаврен, после которой лучше сразу читать «Go на практике» Мэтта Батчера и Мэтта Фарина.
Все остальные книги и последовательность опциональны от выбора и предпочтений молодого бойца на Go :)
Спасибо, работает! Пока работала над этой задачей, тестировала на собственных ссылках, и всегда открытая фигма как раз иконку не отдает :) У них иконки лежат по другому урлу —static.figma.com. Вашим способом фигмовскую иконку я добыла :) Правда, страшненькая, маленькая, но все-таки! Это хороший повод поискать еще несколько вариантов добычи иконок и написать вторую часть статьи :)
Спасибо за комментарий! Действительно, часто иконку не находим, но для наших нужд этого пока хватает. А вот искать иконку с указанием размеров — это идея! Уже думаю :)
В нашем проекте нет такой функции, чтобы обмениваться личными сообщениями. Если появится такая тема, я обязательно учту этот момент, спасибо за то, что обратили внимание :)
Спасибо, что так погрузились! Про «парсить код страницы» — это возможно после того, как ты этот код получишь, а как его получить? Опять запрос, от них отказались. Насчет кэшировать — пока считается, что пользователи пользуются нашим приложением не для хранения ссылок, так что по идее нагрузки большой не должно быть, если появится необходимость, будем думать. Маленький размер картинки тоже пока устраивает :)
Статья про Linux, который используется для десктопных приложений или автономных устройств. Всякие высоконагруженные системы, обрабатывающие миллионы запросов в секунду, управляющие сотней другой девайсов и прочее — это все же отдельная тема. Поддержка GPS, Wi-Fi и управление батареей тоже ведь могут быть частью ядра Linux. А кроссплатформенными кутишными апи решается, но не всегда. Обращу внимание, что мы ограничили стек используемых технологий С++ Qt 5.12. Это то, что мы использовали на реальном проекте, и поверьте, возможности данной версии Qt весьма ограничены.
Спасибо за дополнение! Цель статьи — показать, как получить соответствующие данные. Как ими воспользоваться, каждый волен решать самостоятельно. Можно отображать для пользователя, сразу после получения, можно, как вы предложили, разбить по слоям и только потом использовать.
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 параметрам, где все они не обязательно могут присутствовать. Соответственно, нужно делать разные запросы, которые будут содержать в себе разный набор параметров, либо сильно всё усложнять.
Спасибо за замечание! На самом деле мы изначально хотели тестировать без внешних вызовов. Но вы правы — оба варианта могут быть использованы)
Новичкам в разработке мы обычно советуем начать с этих книг, независимо от языка программирования:
• «Чистый код» Р.Мартина
• «Грокаем алгоритмы» А.Бхаргава — очень помогает с базовыми пониманием, что такое алгоритмы, какие бывают и т.д.
• «2022. System Design. Подготовка к сложному интервью» — очень рекомендуем прочитать 1 и 2 главу всем, кто планирует работать с микросервисами и т.д.
• «TDD Экстремальное программирование» К.Бека — нужно ознакомиться с водной частью (1 и 2 глава), дальше идет уже сильно специфическая тематика.
Для тех, кто только задумался о том, чтобы освоить Golang, можем порекомендовать «Head First. Изучаем Go» Джея Макгаврен, после которой лучше сразу читать «Go на практике» Мэтта Батчера и Мэтта Фарина.
Все остальные книги и последовательность опциональны от выбора и предпочтений молодого бойца на Go :)
Спасибо за то, что переводите и издаете такие полезные книги :)
Спасибо, работает! Пока работала над этой задачей, тестировала на собственных ссылках, и всегда открытая фигма как раз иконку не отдает :) У них иконки лежат по другому урлу —static.figma.com.
Вашим способом фигмовскую иконку я добыла :) Правда, страшненькая, маленькая, но все-таки! Это хороший повод поискать еще несколько вариантов добычи иконок и написать вторую часть статьи :)
Спасибо за комментарий! Действительно, часто иконку не находим, но для наших нужд этого пока хватает. А вот искать иконку с указанием размеров — это идея! Уже думаю :)
В нашем проекте нет такой функции, чтобы обмениваться личными сообщениями. Если появится такая тема, я обязательно учту этот момент, спасибо за то, что обратили внимание :)
Спасибо, что так погрузились! Про «парсить код страницы» — это возможно после того, как ты этот код получишь, а как его получить? Опять запрос, от них отказались. Насчет кэшировать — пока считается, что пользователи пользуются нашим приложением не для хранения ссылок, так что по идее нагрузки большой не должно быть, если появится необходимость, будем думать. Маленький размер картинки тоже пока устраивает :)
Статья про Linux, который используется для десктопных приложений или автономных устройств. Всякие высоконагруженные системы, обрабатывающие миллионы запросов в секунду, управляющие сотней другой девайсов и прочее — это все же отдельная тема. Поддержка GPS, Wi-Fi и управление батареей тоже ведь могут быть частью ядра Linux.
А кроссплатформенными кутишными апи решается, но не всегда. Обращу внимание, что мы ограничили стек используемых технологий С++ Qt 5.12. Это то, что мы использовали на реальном проекте, и поверьте, возможности данной версии Qt весьма ограничены.
Спасибо за дополнение! Цель статьи — показать, как получить соответствующие данные. Как ими воспользоваться, каждый волен решать самостоятельно. Можно отображать для пользователя, сразу после получения, можно, как вы предложили, разбить по слоям и только потом использовать.
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 параметрам, где все они не обязательно могут присутствовать. Соответственно, нужно делать разные запросы, которые будут содержать в себе разный набор параметров, либо сильно всё усложнять.