DF
Книга устарела, как по мне. LYSE гораздо лучше.
Size: a a a
2020 October 30
DF
Правда я не знаю почему моё мнение тут интересно :)
2020 October 31
PG
кстати, в свежем докладике вот чувак говорит что тае себе у gtk поддержка wayland https://static.sched.com/hosted_files/osseu2020/e0/Oct%2027_Graphical%20User%20Interface%20Using%20Flutter%20in%20Embedded%20Systems_Hidenori%20Matsubayashi.pdf
а, точно, sony
G
Есть желание перевести рельсвой сайт на феникс, постепенно. Смотрю в интернетах рекомендуют использовать реверс-прокси. Феникс принимает все запросы, какие то сам обслуживает, другие рельсам перенаправляет. Хочется всеж ввести третий элемент, типа API gateway. Поделитесь своим сетапом, в котором есть слой распределяющий запросы между сервисами. Конги, nginx'ы и кибернетисы, все интересно :)
LL
mix.task больше к логике приложения относится, когда оно уже работоспособно. Собирать ассеты с помощью mix.task я бы не хотел, для таких целей идеально подходит makefile или install.sh (как про это говорили выше)
но, makefile разбит на атомарные куски (используй что хочешь) и считай стандарт
но, makefile разбит на атомарные куски (используй что хочешь) и считай стандарт
Почему
У них одинаковый функционал, только
Во-первых,
Во-вторых, чтобы использовать
В-третьих,
В-четвёртых, у скриптов реально проблемы с
В-пятых, для маленьких скриптов есть
Makefile подходит лучше чем Mix.Task ?У них одинаковый функционал, только
Mix.Task встроен в elixir и хорошо с ним интегрирован, когда Makfile нетВо-первых,
Makefile создавался как супертупая билд система для компилируемых языков. Поэтому $ make у любого человека воспринимается как $ сбилди что-то. Использовать Makefile как просто один файл со скриптами - немного нелогично. Почему бы просто не хранить папочку с шеллскриптами?Во-вторых, чтобы использовать
Makfile, нужно ставить make, когда чтобы использовать эликсировские таски, нужен elixir. На unix с этим проблем нет, но вот на windows с Makfile будет немного проблемВ-третьих,
Mix.Task интегрирован в elixir, что значит что, если понадобится, можно вызывать эликсировский код в нём, таска будет нормально работать если добавлять проект как зависимостьВ-четвёртых, у скриптов реально проблемы с
MIX_ENV, потому что его нельзя перегрузить. Вот у вас есть скрипт, внутри которого написано MIX_ENV=dev и не меняя скрипт вы это не сможете исправить, тогда как в эликсире есть preffered_cli_envВ-пятых, для маленьких скриптов есть
aliases, которые пишутся не сложнее чем шеллскрипты, даже собирать ассеты можно в aliasesPG
Почему
У них одинаковый функционал, только
Во-первых,
Во-вторых, чтобы использовать
В-третьих,
В-четвёртых, у скриптов реально проблемы с
В-пятых, для маленьких скриптов есть
Makefile подходит лучше чем Mix.Task ?У них одинаковый функционал, только
Mix.Task встроен в elixir и хорошо с ним интегрирован, когда Makfile нетВо-первых,
Makefile создавался как супертупая билд система для компилируемых языков. Поэтому $ make у любого человека воспринимается как $ сбилди что-то. Использовать Makefile как просто один файл со скриптами - немного нелогично. Почему бы просто не хранить папочку с шеллскриптами?Во-вторых, чтобы использовать
Makfile, нужно ставить make, когда чтобы использовать эликсировские таски, нужен elixir. На unix с этим проблем нет, но вот на windows с Makfile будет немного проблемВ-третьих,
Mix.Task интегрирован в elixir, что значит что, если понадобится, можно вызывать эликсировский код в нём, таска будет нормально работать если добавлять проект как зависимостьВ-четвёртых, у скриптов реально проблемы с
MIX_ENV, потому что его нельзя перегрузить. Вот у вас есть скрипт, внутри которого написано MIX_ENV=dev и не меняя скрипт вы это не сможете исправить, тогда как в эликсире есть preffered_cli_envВ-пятых, для маленьких скриптов есть
aliases, которые пишутся не сложнее чем шеллскрипты, даже собирать ассеты можно в aliasesMIX_ENV=${MIX_ENV-dev}LL
MIX_ENV=${MIX_ENV-dev}?
$ MIX_ENV=${MIX_ENV-dev} ./x.sh
dev
$ cat x.sh
export MIX_ENV=dev
echo $MIX_ENVPG
MIX_ENV=${MIX_ENV-dev}Нет, вот так надо в скрипте писать
LL
Нет, вот так надо в скрипте писать
А, ну ето-то да
V
Нет, вот так надо в скрипте писать
и что это даст?
PG
V
и что это даст?
То же, что и preferred cli env
V
То же, что и preferred cli env
как это должно работать-то?
V
предлагаешь указывать перед запуском скрипта
MIX_ENV-dev=dev?PG
${var-def} раскрывается в значение var, если переменная var определена, и в def если нет
V
это где такое?
V
в баше синтаксис
${VAR:-def}, а не ${VAR-def}PG
Почти везде
PG
Минус это синтаксис POSIX sh, если что
V
Действительно, можно и так, и так, сорян
DP
Почему
У них одинаковый функционал, только
Во-первых,
Во-вторых, чтобы использовать
В-третьих,
В-четвёртых, у скриптов реально проблемы с
В-пятых, для маленьких скриптов есть
Makefile подходит лучше чем Mix.Task ?У них одинаковый функционал, только
Mix.Task встроен в elixir и хорошо с ним интегрирован, когда Makfile нетВо-первых,
Makefile создавался как супертупая билд система для компилируемых языков. Поэтому $ make у любого человека воспринимается как $ сбилди что-то. Использовать Makefile как просто один файл со скриптами - немного нелогично. Почему бы просто не хранить папочку с шеллскриптами?Во-вторых, чтобы использовать
Makfile, нужно ставить make, когда чтобы использовать эликсировские таски, нужен elixir. На unix с этим проблем нет, но вот на windows с Makfile будет немного проблемВ-третьих,
Mix.Task интегрирован в elixir, что значит что, если понадобится, можно вызывать эликсировский код в нём, таска будет нормально работать если добавлять проект как зависимостьВ-четвёртых, у скриптов реально проблемы с
MIX_ENV, потому что его нельзя перегрузить. Вот у вас есть скрипт, внутри которого написано MIX_ENV=dev и не меняя скрипт вы это не сможете исправить, тогда как в эликсире есть preffered_cli_envВ-пятых, для маленьких скриптов есть
aliases, которые пишутся не сложнее чем шеллскрипты, даже собирать ассеты можно в aliasesчтобы запустить mix нужно чтобы был установлен elixir
так можно договориться до того, чтобы из .exs файлов генерить код, и писать его через
так можно договориться до того, чтобы из .exs файлов генерить код, и писать его через
File.write