Notion умеет в интеграцию со сторонними облаками через WebDAV или какой-нибудь другой протокол? Если да, то эту возможность и использовать для синхронизации шифрованными заметками. Если нет - отказаться от Notion.
Самохостинг - это суровый самурайский путь, статья же про простые обывательские решения. Если информация защищена криптографией адекватной сложности, то проблема принадлежности облаков уже перестанет стоять так остро.
Это скорее камень в огород Obsidian. Например, Joplin умеет e2ee из коробки. А если пользователь чуть более прокачан, то есть и готовое docker-friendly серверное решение для самохостинга.
Ответственность всегда несут те, кто продает. А моральная сторона вопроса - это не про рыночные отношения - всегда попытка одной стороны бесплатно получить некоторые выгоды. Врать в резюме и потом изо всех сил стараться соответствовать ожиданиям - это новый социальный контракт.
Usage:
rename [ -h|-m|-V ] [ -v ] [ -0 ] [ -n ] [ -f ] [ -d ] [ -u [enc]]
[ -e|-E perlexpr]*|perlexpr [ files ]
Options:
-v, --verbose
Verbose: print names of files successfully renamed.
-0, --null
Use \0 as record separator when reading from STDIN.
-n, --nono
No action: print names of files to be renamed, but don't rename.
-f, --force
Over write: allow existing files to be over-written.
--path, --fullpath
Rename full path: including any directory component. DEFAULT
-d, --filename, --nopath, --nofullpath
Do not rename directory: only rename filename component of path.
-h, --help
Help: print SYNOPSIS and OPTIONS.
-m, --man
Manual: print manual page.
-V, --version
Version: show version number.
-u, --unicode [encoding]
Treat filenames as perl (unicode) strings when running the
user-supplied code.
Decode/encode filenames using encoding, if present.
encoding is optional: if omitted, the next argument should be an
option starting with '-', for instance -e.
-e Expression: code to act on files name.
May be repeated to build up code (like "perl -e"). If no -e, the
first argument is used as code.
-E Statement: code to act on files name, as -e but terminated by
';'.
Почти со всеми используемыми мной CLI-программами я научился работать просто читая текст, не ползая по меню, не изучая пиктограмы и расположение кнопок. С оконными прогами такое не прокатывает. Вот и всё.
графические интерфейсы обладают свойством, которым терминал обладать не может в принципе - та самая "интуитивная понятность"
А откуда эта интуитивная понятность берется? У GUI интерактивная природа - перед глазами пользователя знакомые интерактивные элементы, с которыми можно взаимодействовать. Аналогичный опыт будет и с CLI, если вызвать theapp --help и пробежаться глазами по ключам - они типовые, зачастую.
Настолько разработчики боятся малейшей логики в бд, что вместо select max(...), загружают список записей на клиента и уже там находят максимальное значение нужного поля
Будь так, слали бы запрос с select max(...) и ХП не понадобилась бы. А тут больше похоже на то, что банально не подружились с генератором запросов в ORM.
в контексте Go роль исключений сводится к синтаксическому сахару над if err != nil {}
В Go нет исключений и они вряд ли там к месту. Забейте уже на них)
Не надо он там, только читаемость роняет
Читаемость роняет мусорный бойлерплейт.
Явное лучше неявного.
Явно указывается (оператором), что ошибка пробрасывается выше. Если сборка не падает, то очевидно, что тип совместим. Тут пространства для ошибки нет, да и негативный сценарий нужен гораздо реже, чем позитивный. Поэтому последний стараются расчищать по возможности.
ОТСУТСТВИЕ ВЫЗЫВАЮЩЕЙ ФУНКЦИИ очень сильно мешает пробрасывать в нее ошибки!
Еще раз приведу примеры из стандартной библиотеки, где это делается. Может этот код и не вызывается в горутинах, не копал, но явно противоречит вашим ультимативным заявлениям, что так никто не делает и вообще не рекомендуется.
С самого начала так декларировалось.
А потом поняли, что так жить грустно и начали фичи завозить.
ведь именно в этом (пусть и вырожденном) случае try/catch более многословен и даже местами некрасив.
В вырожденном случае можно и по-старому. Богатый синтаксис - это ведь круто.
флоу обработки "прочих ошибок" в других языках не отличается от Go-шного
Выше я приводил в пример Rust, где система обработки ошибок не идеальная, но самые больные болячки Go там побеждены.
В C# ситуация, получается, ровно такая же, как в Go, но там - красиво, а здесь - нет
В C# есть исключения, что уже добавляет гибкости. Но обработка ожидаемых ошибок там тоже не вызывает восхищения. Хотя есть некоторые приятные фичи, вроде кастомных implicit cast'ов, которые могут действовать, как трейт From<T> в Rust.
Нигде не пробрасывают, а в Go всенепременнейше надо!
вы мне всю дорогу демонстрируете красоту try/catch
Вы всю дорогу говорите про уродство, я вам оппонирую) Но недостатки исключений заключаются не в синтаксисе, они никуда не исчезли.
Исключение - это альтернативный флоу обработки исключительных ситуаций.
Не каждая ошибка - это исключительная ситуация. Поэтому для них отдельный флоу, который обладает супер-способностями, но не очень подходит для прочих ошибок.
смысл городить альтернативный флоу обработки ошибок? Просто заради "чтобы было красиво"?
Так нужна не альтернатива, а допиливание имеющегося. Чтобы в Go тоже можно было пробрасывать ошибки выше без боли.
А оно настолько круто, чтобы заради этой "фишки" целые исключения городить?
Не "ради", исключения в C# - это родной инструмент и в данном случае их использование оправдано. В случае использования try-паттерна была бы такая же грязь, как в Go.
Фантазии на тему отделения обработки ошибок от бизнес-кода
По идее, ничто не мешает задизайнить в языках такую штуку для легковесных типов: аналог try-оператора, который позволял бы типу "всплывать", но не из функции, а в до ближайшего catch внутри вызывающей функции. То есть чисто синтаксический сахар над легковесными типами ошибок в стиле исключений, но без их затрат на раскрутку стека и собирание бэктрейсов.
бизнесовые проверки, типа UserExists() или user.CanPostComments() лучше во флоу исключений не ссыпать
Не понимаю, о чем вы. Бизнес-логика выше, обработка исключений - отдельно ниже.
// чем, по сути, вот это: // отличается от вот этого:
Разделение между ожидаемыми ошибками (валидацией) и обработкой исключительных ситуаций. Исключения можно безболезненно ловить выше, а try-функции или аналогичные конструкции - для ситуативного, что необходимо обрабатывать тут же.
Notion умеет в интеграцию со сторонними облаками через WebDAV или какой-нибудь другой протокол? Если да, то эту возможность и использовать для синхронизации шифрованными заметками. Если нет - отказаться от Notion.
Самохостинг - это суровый самурайский путь, статья же про простые обывательские решения. Если информация защищена криптографией адекватной сложности, то проблема принадлежности облаков уже перестанет стоять так остро.
Это скорее камень в огород Obsidian. Например, Joplin умеет e2ee из коробки. А если пользователь чуть более прокачан, то есть и готовое docker-friendly серверное решение для самохостинга.
Фатальный недостаток этих наколеночных синхронизаций с бесплатными облаками - отсутствие e2e-шифрования.
Ответственность всегда несут те, кто продает. А моральная сторона вопроса - это не про рыночные отношения - всегда попытка одной стороны бесплатно получить некоторые выгоды. Врать в резюме и потом изо всех сил стараться соответствовать ожиданиям - это новый социальный контракт.
У вас ман про одноименный сисколл, а не про программу rename. Убедитесь, что она у вас установлена.
Путь экспериментов - это противоположность "сходу".
Более подробное описание и примеры можно найти в манах (
man rename).Интерфейс проводника
Причем, с ключом -n | --nono покажет ожидаемый результат, аналогично TC.
rename --help
Против
Total Commander Multi-Rename tool
Разве этот интерфейс можно назвать очевидным?
Гуи не дадут преимущества в поисках нужного бинарника.
Обрамление угловыми стрелками съело слово
Почтисо всеми используемыми мной CLI-программами я научился работать просто читая текст, не ползая по меню, не изучая пиктограмы и расположение кнопок. С оконными прогами такое не прокатывает. Вот и всё.Это уже вопрос дизайна. Кнопки запросто могут быть такими же.
Впрочем, там есть и более очевидный ключ
--schema.Разве?
Попробуйте тыкать в процессе набора путей, тогда может хватить одной
cd. Автокомплит - важная штука в CLI.Хороший пример не самого очевидного GUI, имхо. Много возможностей - много хитрых кнопок и хоткеев, которые таки тоже нужно разучивать.
А откуда эта интуитивная понятность берется? У GUI интерактивная природа - перед глазами пользователя знакомые интерактивные элементы, с которыми можно взаимодействовать. Аналогичный опыт будет и с CLI, если вызвать
theapp --helpи пробежаться глазами по ключам - они типовые, зачастую.Будь так, слали бы запрос с
select max(...)и ХП не понадобилась бы. А тут больше похоже на то, что банально не подружились с генератором запросов в ORM.В Go нет исключений и они вряд ли там к месту. Забейте уже на них)
Читаемость роняет мусорный бойлерплейт.
Явно указывается (оператором), что ошибка пробрасывается выше. Если сборка не падает, то очевидно, что тип совместим. Тут пространства для ошибки нет, да и негативный сценарий нужен гораздо реже, чем позитивный. Поэтому последний стараются расчищать по возможности.
Еще раз приведу примеры из стандартной библиотеки, где это делается. Может этот код и не вызывается в горутинах, не копал, но явно противоречит вашим ультимативным заявлениям, что так никто не делает и вообще не рекомендуется.
А потом поняли, что так жить грустно и начали фичи завозить.
В вырожденном случае можно и по-старому. Богатый синтаксис - это ведь круто.
Погуглите пропозалы, что ж вы так вцепились в исключения?
Да и в чем спор-то? Вы пытаетесь запретить мне называть проблему проблемой, пока у нее не появится решения?
Все пойдут с крыши прыгать - ты тоже пойдешь?Достойный довод, чтобы не язык не развивался)Все необходимое там есть и активно используется.
Нет. Вы говорите, что исключения - ерунда неудобная, я показываю, как их правильно использовать и подчеркиваю их преимущества, сравнивая подходы.
А сетую я на отсутствие в Go try-оператора, кастомных implicit cast'ов и типов-сумм.
Почему? Что мешает пробрасывать ошибки в вызывающую функцию?
А может никто не догадался или крайности: либо суровая явная явность с ручной проверкой, либо полностью неявный флоу исключений.
Если их важно отличать, то это будут разные (вложенные) try-блоки, аналогично работе с исключениями.
Выше я приводил в пример Rust, где система обработки ошибок не идеальная, но самые больные болячки Go там побеждены.
В C# есть исключения, что уже добавляет гибкости. Но обработка ожидаемых ошибок там тоже не вызывает восхищения. Хотя есть некоторые приятные фичи, вроде кастомных implicit cast'ов, которые могут действовать, как трейт
From<T>в Rust.Везде пробрасывают. И даже в Go пытаются.
Удобство - в выборе подходящего инструмента.
Вы всю дорогу говорите про уродство, я вам оппонирую) Но недостатки исключений заключаются не в синтаксисе, они никуда не исчезли.
Не каждая ошибка - это исключительная ситуация. Поэтому для них отдельный флоу, который обладает супер-способностями, но не очень подходит для прочих ошибок.
Так нужна не альтернатива, а допиливание имеющегося. Чтобы в Go тоже можно было пробрасывать ошибки выше без боли.
Не "ради", исключения в C# - это родной инструмент и в данном случае их использование оправдано. В случае использования try-паттерна была бы такая же грязь, как в Go.
Фантазии на тему отделения обработки ошибок от бизнес-кода
По идее, ничто не мешает задизайнить в языках такую штуку для легковесных типов: аналог try-оператора, который позволял бы типу "всплывать", но не из функции, а в до ближайшего
catchвнутри вызывающей функции. То есть чисто синтаксический сахар над легковесными типами ошибок в стиле исключений, но без их затрат на раскрутку стека и собирание бэктрейсов.Не понимаю, о чем вы. Бизнес-логика выше, обработка исключений - отдельно ниже.
Разделение между ожидаемыми ошибками (валидацией) и обработкой исключительных ситуаций. Исключения можно безболезненно ловить выше, а try-функции или аналогичные конструкции - для ситуативного, что необходимо обрабатывать тут же.