Makesure тоже можно сказать не нужно: это маленький (~20 KB) самодостаточный POSIX-shell скрипт, который хранится в репозитории вместе с проектом и сразу доступен любому разработчику. То есть он всегда локален проекту и не нужно устанавливать глобально.
Так а с чем Вы, собственно, спорите? Что на make можно сделать все то же самое? Естественно, можно. Полагаю, Вас сбил с толку слишком кликбейтный заголовок моей статьи, виноват.
Я утверждаю, что makesure удобнее именно для целей task runner, то есть когда вам нужно иметь простой набор утилитных команд для проекта. То есть я позиционирую этот инструмент как более удобную и универсальную альтернативу npm run scripts. Например в этой презентации https://www.youtube.com/watch?v=a6gcWjj5MQc докладчик описывает практику применения make для Ruby on Rails проекта. Это именно тот случай, где makesure мог бы стать лучшей альтернативой.
Подчеркиваю, это не build tool (как make, ninja, cmake и т.д.) и он не заменяет эти инструменты там где вам нужна специфичная логика сборки, характерная для C/C++.
Как-то выглядит переусложненным, так что за деревьями не видно леса. Вот пример одного из моих ботов https://github.com/xonixx/bookmark-telegram-bot - гораздо проще в реализации, реализует реальный сценарий и даже имеет тесты.
До конца так и не понял, зачем необходим такой функционал мержинга конфигов. Есть стойкое ощущение, что или задача надуманная, или она решается гораздо проще.
Хотел откомментировать корневой пост, но Ваш комментарий, в принципе, передаёт и мои мысли.
Действительно, гораздо важнее написать корректный код и покрыть его тестами. Так вы обретаете широкую свободу изменять код (оптимизация, прочий рефакторинг) не боясь поломать корректную логику.
Кстати, по поводу скорости. Вообще говоря, а как вообще понять что программа тормозит? Нужны метрики скорости для начала. Очевидно, чтоб добавить такие метрики нужен некий готовый код. Возможно, самая наивная реализация будет достаточно быстра для типичного использования. Так зачем напрягаться?
И не забываем про принцип Парето. Оптимизировать имеет смысл только самые «горячие» участки кода.
Иными словами, наиболее эффективно можно ускорять что-то осязаемое, причём закреплённое тестами и покрытое метриками производительности. Без этого писать абстрактный «быстрый» код — гиблое дело. Зачастую эти оптимизации будут путаться под ногами и всеми силами мешать, пока вы будете пытаться достичь целевого функционала вашей программы.
На самом деле синтаксис простой, если понять строительные блоки, коих немного. Это:
field1.field2.field3 — доступ по полям
[ expression ] — фильтрация
{ expression } — трансформация (map)
[ from:to:step ] — срезы в стиле Python
s( expression ) — сортировка
Где expression — выражение с "_" которое под капотом соответствует JS функции function(_) { return expression }. Например, фильтр [ _ > 5 ] соответствует предикату function(_) { return _ > 5 }. Все, этого знания достаточно чтоб написать 90% типовых запросов.
Возможно, я не вполне понятно описал, но ноды как рантайм-среды там нет ни в каком виде. Утилита представляет собой самодостаточный исполняемый файл, который имеет составной частью движок QuickJS для реализации логики DSL.
Процитирую себя 5 лет назад https://habr.com/ru/post/258767/comments/#comment_8436035
«Наблюдаю краем глаза за лавинообразным развитием пхп последних лет, и сделал парадоксальный вывод. Чем быстрее пхп развивается, тем быстрее он умрет. Очень просто. Из него сделают недо-яву (без юникода, потоков, толковой типизации, тормозную, с «шумным» синтаксисом), и люди получат больше оснований сравнивать.
А сравнив, сделают очевидный вывод.
Процесс запущен.
Мой прогноз: пхп умрет, когда отменят доллар в имени переменных.»
Советую в подобных статьях вот это "Самый простой и ёмкий ответ — это база данных. В основе которой — хранилище "ключ-значение"; грубо говоря, ConcurrentDictionary, в котором данные расположены на нескольких машинах." помещать в шапку. Жутко бесит когда сперва идет простыня о продукте, но даже не понятно о каком :)
В остальном, спасибо.
А можете, если возможно, сказать пару слов о том, как соотносятся ClickHouse и Amazon Redshift? На работе есть юзкейс под который как будто идеально ложится ClickHouse, но босс хочет Redshift. По позиционированию смотрятся близкими продуктами, так ли это?
Ну это философский спор. Но, например, разработчики angularjs сделали так же.
Forgiving: In JavaScript, trying to evaluate undefined properties generates ReferenceError or TypeError. In Angular, expression evaluation is forgiving to undefined and null
Makesure тоже можно сказать не нужно: это маленький (~20 KB) самодостаточный POSIX-shell скрипт, который хранится в репозитории вместе с проектом и сразу доступен любому разработчику. То есть он всегда локален проекту и не нужно устанавливать глобально.
Еще списочек аналогов https://github.com/xonixx/makesure#similar-tools
Так а с чем Вы, собственно, спорите? Что на make можно сделать все то же самое? Естественно, можно. Полагаю, Вас сбил с толку слишком кликбейтный заголовок моей статьи, виноват.
Я утверждаю, что makesure удобнее именно для целей task runner, то есть когда вам нужно иметь простой набор утилитных команд для проекта. То есть я позиционирую этот инструмент как более удобную и универсальную альтернативу npm run scripts. Например в этой презентации https://www.youtube.com/watch?v=a6gcWjj5MQc докладчик описывает практику применения make для Ruby on Rails проекта. Это именно тот случай, где makesure мог бы стать лучшей альтернативой.
Подчеркиваю, это не build tool (как make, ninja, cmake и т.д.) и он не заменяет эти инструменты там где вам нужна специфичная логика сборки, характерная для C/C++.
Из коробки отсутствует возможность сделать листинг доступных целей
По умолчанию цели не .PHONY, а значит такой кейс не будет работать как хотелось бы
Потому что
Неудобно использовать многострочные шелл-скрипты в качестве тела целей
Необходимость использовать $$ вместо $ для переменных окружения
Обязательные табы
Несовместимость разных реализаций make
А была ли эта архитектура испытана на хоть одной реальной реализации бота?
Как-то выглядит переусложненным, так что за деревьями не видно леса. Вот пример одного из моих ботов https://github.com/xonixx/bookmark-telegram-bot - гораздо проще в реализации, реализует реальный сценарий и даже имеет тесты.
До конца так и не понял, зачем необходим такой функционал мержинга конфигов. Есть стойкое ощущение, что или задача надуманная, или она решается гораздо проще.
Данный комментарий StackOverflow хорошо раскрывает тему: https://stackoverflow.com/a/28938235/104522
Да, верное замечание. Есть даже принцип такой https://ru.wikipedia.org/wiki/Чем_хуже,_тем_лучше.
Хотел откомментировать корневой пост, но Ваш комментарий, в принципе, передаёт и мои мысли.
Действительно, гораздо важнее написать корректный код и покрыть его тестами. Так вы обретаете широкую свободу изменять код (оптимизация, прочий рефакторинг) не боясь поломать корректную логику.
Кстати, по поводу скорости. Вообще говоря, а как вообще понять что программа тормозит? Нужны метрики скорости для начала. Очевидно, чтоб добавить такие метрики нужен некий готовый код. Возможно, самая наивная реализация будет достаточно быстра для типичного использования. Так зачем напрягаться?
И не забываем про принцип Парето. Оптимизировать имеет смысл только самые «горячие» участки кода.
Иными словами, наиболее эффективно можно ускорять что-то осязаемое, причём закреплённое тестами и покрытое метриками производительности. Без этого писать абстрактный «быстрый» код — гиблое дело. Зачастую эти оптимизации будут путаться под ногами и всеми силами мешать, пока вы будете пытаться достичь целевого функционала вашей программы.
На самом деле синтаксис простой, если понять строительные блоки, коих немного. Это:
field1.field2.field3— доступ по полям[ expression ]— фильтрация{ expression }— трансформация (map)[ from:to:step ]— срезы в стиле Pythons( expression )— сортировкаГде
expression— выражение с "_" которое под капотом соответствует JS функцииfunction(_) { return expression }. Например, фильтр[ _ > 5 ]соответствует предикатуfunction(_) { return _ > 5 }. Все, этого знания достаточно чтоб написать 90% типовых запросов.$ echo '[1,2,3,4,5]' | jq 'map(select(.>2)) | map(.+100) | sort_by(-.) | .[-2:]'
[
104,
103
]
$ echo '[1,2,3,4,5]' | jsqry '[_>2] {_+100} s(-_) [-2:]'
[
104,
103
]
Тут больше сравнительных примеров: gist.github.com/xonixx/d6066e83ec0773df248141440b18e8e4
Процитирую себя 5 лет назад
https://habr.com/ru/post/258767/comments/#comment_8436035
«Наблюдаю краем глаза за лавинообразным развитием пхп последних лет, и сделал парадоксальный вывод. Чем быстрее пхп развивается, тем быстрее он умрет. Очень просто. Из него сделают недо-яву (без юникода, потоков, толковой типизации, тормозную, с «шумным» синтаксисом), и люди получат больше оснований сравнивать.
А сравнив, сделают очевидный вывод.
Процесс запущен.
Мой прогноз: пхп умрет, когда отменят доллар в имени переменных.»
Недавно удивился, обнаружив в разрабатываемой спецификации Java Value Classes куски кода описания на прологе http://cr.openjdk.java.net/~dlsmith/values.html
Советую в подобных статьях вот это "Самый простой и ёмкий ответ — это база данных. В основе которой — хранилище "ключ-значение"; грубо говоря, ConcurrentDictionary, в котором данные расположены на нескольких машинах." помещать в шапку. Жутко бесит когда сперва идет простыня о продукте, но даже не понятно о каком :)
В остальном, спасибо.
А можете, если возможно, сказать пару слов о том, как соотносятся ClickHouse и Amazon Redshift? На работе есть юзкейс под который как будто идеально ложится ClickHouse, но босс хочет Redshift. По позиционированию смотрятся близкими продуктами, так ли это?