А тем временем уже конец 2022 года, а я всё использую GitHub в России без VPN. И GitFlic пользуюсь. Правда больше по приколу, потому как он заметно менее функциональный.
Прошу прощения, если я задел Вас. Я просто уточнил про варианты использования Exposed без DAO. А на счёт того, что написано в статье, я согласен. Там далеко не всё норм. В частности, методы расширения для ResultRow меня самого напрягли, но я не стал уже придираться.
А по поводу производительности DAO я говорю из личного опыта. Я использовал Exposed+PostgreSQL. И на нём пакет вставок происходит значительно быстрее, чем много одиночных вставок, по понятным, надеюсь, причинам. И я в своём комментарии писал именно о таком использовании. Кроме того, DAO ещё нужно создать, а это дополнительная работа. Да она не велика, но при плотном потоке данных становится заметна. При достаточно плотном потоке данных с максимальной оптимизацией и корутинами мне удавалось выжимать разницу в разы (2-3 раза) в сравнении с DAO. Собственно, так я и пришёл к этому. Изначально я использовал только DAO. Но в некоторых местах мне сильно не хватало производительности и, что было самое странное, БД выжимала далеко не всё, что могла. Я начал экспериментировать, сначала с оптимизацией DAO, потом и с Exposed SQL DSL. Не только документацию, но даже исходники Exposed DAO изучал. Сильно уж мне в этих узких местах нужна была большая производительность.
Иногда, всё же, есть причины делать так, как описано в данной статье. Дело в том, что DAO несколько медленнее. Плюс для DAO класса нельзя нормально настроить сериализацию, потому как у него всего-то одно поле хранится непосредственно в экземпляре - это id. Поэтому способ доступа весьма похожий на то, что описано в этой статье, я сам иногда использую в случае, если нужно сохранять большое количество сущностей в БД сразу из сети. То есть десериализовал и сразу в таблицу. Большими пачками в Batch запросах. В таком случае Вы заметите сильное преимущество перед DAO по скорости. В других же случаях вполне можно использовать и DAO. Особенно хорош DAO, если он один раз читается из БД и долго потом используется без изменений.
Очень полезная статья. Я, конечно, понимаю, что статья четырёхлетней давности, но вдруг автор захочет сделать продолжение? Особенно интересно что в Kodein есть для серверных приложений. Так сказать "Переезд с Spring на Kodein".
Почитайте их заявление на официальном сайте. Там написано, что JetBrains полностью Чешская компания и к России не имеет отношения. Вообще. По их словам их вообще ничего не связывает с Россией. Так, только небольшой рынок сбыта и всё. Я, честно говоря, раньше думал иначе, но раз они официально так заявили, значит это правда и у JetBrains с Россией ничего общего нет.
Да бог с ним с курсом. Если Вы на этих инструментах работаете, то цена не выглядит сильно уж большой. Даже при росте курса доллара. А вот принципиальная недоступность данных инструментов для России, если они реально её введут, станет реальной проблемой. Во всяком случае для меня.
И, да. Я понимаю, что вся эта истерия на западе создана искусственно, потому как американцы в кучу стран вторгались по ошибке и ничего страшного. Потом даже не извинялись. И мне плевать на официальную риторику компаний. Пусть говорят, что хотят и мне не холодно и не жарко от их заявлений. Это всё исключительно их моральные проблемы. Главное, что бы инструменты не банили.
Если проблема чисто техническая, то что мешает принимать платежи через Китай. Китайцы будут только рады заработать. Тем более, что Китайцы уже подсуетились со своей платёжной системой.
Я говорю именно о грантах. Как правило требованием по ним являются только публикации статей, но в ходе исследований создаётся куча потенциально полезного кода, который по окончании гранта, в лучшем случае, убирается в стол. Сам в таких участвовал. Таких наработок кучи создаётся и все в никуда. Вот эти-то результаты и будут выкладываться.
Вы неверно смотрите на суть данного проекта. Он не призван полностью заменить существующие аналоги (коих, кстати, целая куча и всё прибавляются и прибавляются). Наше государство, на самом деле, выделяет кучи денег на различные исследования в различных ВУЗах, но все их наработки уходят в стол, потому как нет официального требования публикации самих наработок. Есть лишь требование публикации статей. А требовать такое, не предоставляя соответствующего инструмента, государство не может. Как только эту штуку запустят, то, скорее всего, заставят все ВУЗы все программы от курсовых до Кандидатских публиковать на этом портале. И это, надо сказать, было бы довольно удобно. Я когда в универе учился мы свой сервер для этих целей подымали. Ох как нам было бы проще, если бы государство предоставляло бы нам его в готовом виде.
Только я опасаюсь, что это всё может либо совсем не заработать, либо заработает, но через известное всем место. Благо, они уже пытались такую штуку сделать и что-то пошло не так.
Хорошая штука. Но я искал максимально универсальный метод. Для изложенного мною метода нужно всего две вещи: GCC и BASH. Всё! Оба есть на любом Linux. Я понимаю, что можно придумать кучи специализированных методов работы с ресурсами, которые будут лучше во всём. Но они не будут универсальны. Мне нужен был именно универсальный метод. Я его нашёл. Подумал, что он ещё кому-то может быть нужен (ну мало-ли).
И, опять же, Вам нужно будет придумывать удачный принцип разбиения. Я же писал, что данный способ выбран как наиболее универсальный. И как любой универсальный способ он имеет кучу недостатков, при сравнении с более специализированными.
Естественно, что для более узких задач можно придумать более удобные способы работы с ресурсами. И эти способы будут и проще и быстрее на своих задачах, но они не будут универсальны.
В ходе своих поисков я рассматривал все эти способы и, если это будет кому-то интересно, возможно сделаю в будущем статьи и по другим способам работы с ресурсами в программах для Linux.
Тоже хороший вариант, но я, к сожалению, работаю без Qt. Во всяком случае, данный способ я искал именно исходя из требования максимально возможной универсальности.
PS: Хотя против Qt я ничего не имею и очень даже его люблю.
Явно указывать имя ресурса было бы неплохо. По сути ради этого все эти «кривые скрипты» и написаны. А если бы они ещё и заголовочник для ресурсов генерировали, то вообще офигенно было бы. Но такого функционала я, в частности, в официальных манах не нашёл. Возможно плохо искал.
PS: И по поводу правки символов: а что Вам конкретно не нравится? Если Вы видите в моих скриптах ошибки или потенциально опасные места, то пожалуйста поделитесь со всеми. Если же Вам просто не нравится использование скриптов, при сборке, то, хочу заметить, что это лишь дело вкуса.
Спасибо. Полезная статья.
Да ладно Вам. Все же знают, что самое интересное там - это защита от призыва. А скидка по налогам просто приятный бонус.
А тем временем уже конец 2022 года, а я всё использую GitHub в России без VPN. И GitFlic пользуюсь. Правда больше по приколу, потому как он заметно менее функциональный.
Прошу прощения, если я задел Вас. Я просто уточнил про варианты использования Exposed без DAO. А на счёт того, что написано в статье, я согласен. Там далеко не всё норм. В частности, методы расширения для ResultRow меня самого напрягли, но я не стал уже придираться.
А по поводу производительности DAO я говорю из личного опыта. Я использовал Exposed+PostgreSQL. И на нём пакет вставок происходит значительно быстрее, чем много одиночных вставок, по понятным, надеюсь, причинам. И я в своём комментарии писал именно о таком использовании. Кроме того, DAO ещё нужно создать, а это дополнительная работа. Да она не велика, но при плотном потоке данных становится заметна. При достаточно плотном потоке данных с максимальной оптимизацией и корутинами мне удавалось выжимать разницу в разы (2-3 раза) в сравнении с DAO. Собственно, так я и пришёл к этому. Изначально я использовал только DAO. Но в некоторых местах мне сильно не хватало производительности и, что было самое странное, БД выжимала далеко не всё, что могла. Я начал экспериментировать, сначала с оптимизацией DAO, потом и с Exposed SQL DSL. Не только документацию, но даже исходники Exposed DAO изучал. Сильно уж мне в этих узких местах нужна была большая производительность.
Иногда, всё же, есть причины делать так, как описано в данной статье. Дело в том, что DAO несколько медленнее. Плюс для DAO класса нельзя нормально настроить сериализацию, потому как у него всего-то одно поле хранится непосредственно в экземпляре - это id. Поэтому способ доступа весьма похожий на то, что описано в этой статье, я сам иногда использую в случае, если нужно сохранять большое количество сущностей в БД сразу из сети. То есть десериализовал и сразу в таблицу. Большими пачками в Batch запросах. В таком случае Вы заметите сильное преимущество перед DAO по скорости. В других же случаях вполне можно использовать и DAO. Особенно хорош DAO, если он один раз читается из БД и долго потом используется без изменений.
Очень полезная статья. Я, конечно, понимаю, что статья четырёхлетней давности, но вдруг автор захочет сделать продолжение? Особенно интересно что в Kodein есть для серверных приложений. Так сказать "Переезд с Spring на Kodein".
Благодарю за точную цитату.
Почитайте их заявление на официальном сайте. Там написано, что JetBrains полностью Чешская компания и к России не имеет отношения. Вообще. По их словам их вообще ничего не связывает с Россией. Так, только небольшой рынок сбыта и всё. Я, честно говоря, раньше думал иначе, но раз они официально так заявили, значит это правда и у JetBrains с Россией ничего общего нет.
Да бог с ним с курсом. Если Вы на этих инструментах работаете, то цена не выглядит сильно уж большой. Даже при росте курса доллара. А вот принципиальная недоступность данных инструментов для России, если они реально её введут, станет реальной проблемой. Во всяком случае для меня.
И, да. Я понимаю, что вся эта истерия на западе создана искусственно, потому как американцы в кучу стран вторгались по ошибке и ничего страшного. Потом даже не извинялись. И мне плевать на официальную риторику компаний. Пусть говорят, что хотят и мне не холодно и не жарко от их заявлений. Это всё исключительно их моральные проблемы. Главное, что бы инструменты не банили.
Если проблема чисто техническая, то что мешает принимать платежи через Китай. Китайцы будут только рады заработать. Тем более, что Китайцы уже подсуетились со своей платёжной системой.
Ой, да ладно вам придираться. Хоть бы так уже сделали.
Ну это уже маленькие детали. Их, думаю, будут чинить по ходу дела. Так же, как это в своё время с ЕГЭ было.
А по поводу того, что проще было бы сделать форк от GitLab. Думаю, что да. Проще. Но на это, к сожалению, не спишешь 2 миллиарда.
Я говорю именно о грантах. Как правило требованием по ним являются только публикации статей, но в ходе исследований создаётся куча потенциально полезного кода, который по окончании гранта, в лучшем случае, убирается в стол. Сам в таких участвовал. Таких наработок кучи создаётся и все в никуда. Вот эти-то результаты и будут выкладываться.
Вы неверно смотрите на суть данного проекта. Он не призван полностью заменить существующие аналоги (коих, кстати, целая куча и всё прибавляются и прибавляются). Наше государство, на самом деле, выделяет кучи денег на различные исследования в различных ВУЗах, но все их наработки уходят в стол, потому как нет официального требования публикации самих наработок. Есть лишь требование публикации статей. А требовать такое, не предоставляя соответствующего инструмента, государство не может. Как только эту штуку запустят, то, скорее всего, заставят все ВУЗы все программы от курсовых до Кандидатских публиковать на этом портале. И это, надо сказать, было бы довольно удобно. Я когда в универе учился мы свой сервер для этих целей подымали. Ох как нам было бы проще, если бы государство предоставляло бы нам его в готовом виде.
Только я опасаюсь, что это всё может либо совсем не заработать, либо заработает, но через известное всем место. Благо, они уже пытались такую штуку сделать и что-то пошло не так.
Только вот опасения у меня есть, что опять ни чем это не закончится. Или же сделают какое-то страхолюдие, которым будет невозможно пользоваться.
Хотя, если всё же сделают, думаю что я обязательно зайду посмотреть. Может, даже, что и Выложу.
Естественно, что для более узких задач можно придумать более удобные способы работы с ресурсами. И эти способы будут и проще и быстрее на своих задачах, но они не будут универсальны.
В ходе своих поисков я рассматривал все эти способы и, если это будет кому-то интересно, возможно сделаю в будущем статьи и по другим способам работы с ресурсами в программах для Linux.
PS: Хотя против Qt я ничего не имею и очень даже его люблю.
PS: И по поводу правки символов: а что Вам конкретно не нравится? Если Вы видите в моих скриптах ошибки или потенциально опасные места, то пожалуйста поделитесь со всеми. Если же Вам просто не нравится использование скриптов, при сборке, то, хочу заметить, что это лишь дело вкуса.