Добавить репо?
cd ~/repos; git clone ....where...new...repo...is…
Или у вас все репы лежат в одном экаунте в Гитхабе? Ну это вам пока повезло.
Практика показывает, что нужная репа внезапно может оказаться на чьем-то личном ГитЛабе или еще непойми где.
git pull делает что обычно.
Там есть еще перед ней команда cd и еще перед ними for… `ls`.
Но если это вызывает вопросы, то пролистайте какой-нибудь тюториал по башу —
сэкономите себе кучу времени.
С точки зрения программиста баш выглядит ужасно, но я этой одной строкой решаю практически аналогичную задачу у себя. А у вас там пара страниц кода написана, который еще как-то там настраивать надо.
Странная проблема, конечно.
Если предположить, что на компьтере уже есть ключи для гитхаба.битбакета, и имена репозиториев известны.
(Было бы странно, если бы разработчики не знали, какие у них репы. Да ведь?).
То весь бэкап делается примерно так:
cd ~/repos/; for i in `ls`; do (cd $i; git pull) done
Как это внезапно алгоритм (b-tree) для доступа к записи на двух сильно отличающихся по скорости средах (ram/disk) вдруг стал напрямую связан с отношениями между сущностями?
Дело даже не в том. Лично я с удовольствием использую и Монгу и Постгрес, но автор статьи не вникая в суть вопроса пытается строить какие-то таблички с да/нет, которые выглядят в результате притянутыми за уши.
То есть мотив написания статьи примерно такой — «многие люди хвалят Монгу, а я альтернативный чувак, похвалю Постгрес». А в результате фигня получается.
Но в примере у автора wrap-params, а это такая штука, которая принимает на вход request и на выход отдает тоже request. То есть речь о том, что автор за уши притягивает абсолютно не подходящие аргументы.
Или возьмем такую другой вариант передергивания — «какой DSL лучше всего описывает HTML?»
А кому вообще надо описывать html? Ведь у девелопера обычно совсем другая задача, а именно,
«каким-то образом запихать мою структуру данных в браузер, чтобы он ее понял».
Цепочка выглядит так
mydata -> templater -> html -> http(tcp,gzip,...) -> html -> parser -> dom
или вот так (в случае Clojure)
mydata -> hiccup -> html -> http(tcp,gzip,...) -> html -> parser -> dom
причем, во втором случае hiccup — это по сути тривиальное проеобразование теми же средствами, которые уже работают с mydata безо всяких дополнтельных «языков шаблонов» и т.п.
И ключевые моменты здесь «тривиальное» и «теми же средствами».
Вы это где-то в интернетах прочитали или самостоятельно внедрением/сопровождением занимаетесь?
Дело в том, что я-то как раз занимаюсь и разработкой и сопровождением, не первый десяток лет, причем. На старье желают сидеть только те, у кого просто нет выбора. И то до поры до времени, когда появится альтернатива.
Вообще, создается впечатление, что у многих людей Alt-Enter на клавиатуре туго нажимается.
Битва за throws у методов идет просто не на жизнь, а на смерть!
Да где они пишут про вред-то?!
Есть возможность — можно использовать при желании. Можно не использовать, если не нравится. Дело вкуса — Одерски одно говорит, Блох другое.
Или я вот на Clojure пишу, а Scala мне не нравится. Мне теперь говорить, что Scala это вред?
Ну так о чем статья-то тогда?
Вред от разного вида эксепшенов очевиден только для тех, кто не понял как и для чего их использовать.
Вместо слова «эксепшен» здесь можно поставить практически любой другой термин.
Я так понял, что основной поинт статьи в том, что приходится много писать в списке throws при объявлении метода.
Но это как бы не совсем правда и очень зависит от того, как сделана иерархия. Пример с тривиальным вебсервером, возвращающим либо 4хх либо 5хх при ошибке здесь не очень подходит.
Возьмем приложение, которое для своей работы пользуется данными из app_config и host_config. Получением этих данных занимается отдельный модуль, инкапсулирующий в себя всю мутотень ввода-вывода. Снаружи этого модуля мы точно не желаем видеть все богатство ioexception (формат, пути, файлы, права доступа, енкодинг и т.п.), а хотим видеть нечто более понятное. Собственно, для того мы и пишем этот модуль.
Что-нибудь в виде AppException и унаследованные от него ConfigVersionException, ConfigFormatException, ConfigReadException. Причем, часть из них может быть фатальными, а часть нет, в зависимости от ситуации — например, неправильная версия app_config это в морг, а для host_config возможно есть варианты.
Внутри же эт ого модуля FileNotFound может быть совсем не фатальным случаем ioexception, а поводом попробовать почитать другой файл (это сплошь и рядом).
Это я все к тому, что сложные вещи нельзя рассматривать на примере hello-world'а.
Насчет обилия разных типов исключений в Java я немного согласен с автором.
Но в остальном, создается впечатление, что про иерархии исключений он не слышал, и ничего кроме простейших вебсайтиков не писал. А лейтмотив всей статьи — «разработчики дураки, ничего сложнее одинокого try/catch правильно написать не муогут».
Несомненно, ключевым аргументом ipfs в статье смотрится фрагмент конфига Голого Деда. Куда же сейчас без него!
При всем моем уважении, упоминанине Фидонета в подобных случаях выглядит как проявление некоей латентной некрофилии. Сильно плохого в этом ничего нет, однако, рецидивы настораживают.
Никакое.
Если я сохранил платеж для чего-то, то я предполагаю, что буду использовать его в дальнйшем.
И если возникает мысль «надо заплатить ...», то тогда первая мысль тыкнуть в избранное, но ни в каком другом случае мне нет надобности смотреть в «избранное», что я там не видел?
Подумайте над поисковой строкой. В идеале, чтобы по набору в ней работал suggest по данным в порядке приоритета — избранное, история платежей, партнеры и т.п.
То есть если мне надо пополнить телефон тёщи, то я начинаю набирать его и в подсказке выскакивает последний платеж на этот телефон. Если я хочу перекинуть немного денег на Тинькова, то по набору «тинь» у меня однозначно бы определялся платеж из «избранного».
В общем, что тут объяснять, эта практика уже привычна и хорошо работает во многих местах.
Тут уже писали где-то, что хорошо бы выделить отдельный пункт меню под информацию о счете, реквизиты, карты и т.п.
Понятно, что можно внезапно найти это, тыкнув в «баланс» и запомнить, что оно лежит там.
Но такой расклад по первости ставит в тупик, видимо не только меня.
Какой, вообще, смысл так экономить на боквой менюшке?
Но если нужны разные ветки, то вполне можно пробежаться git checkout'ом по списку
git branch -a | grep remotes | grep -v HEAD | grep -v master
cd ~/repos; git clone ....where...new...repo...is…
Или у вас все репы лежат в одном экаунте в Гитхабе? Ну это вам пока повезло.
Практика показывает, что нужная репа внезапно может оказаться на чьем-то личном ГитЛабе или еще непойми где.
git pull делает что обычно.
Там есть еще перед ней команда cd и еще перед ними for… `ls`.
Но если это вызывает вопросы, то пролистайте какой-нибудь тюториал по башу —
сэкономите себе кучу времени.
С точки зрения программиста баш выглядит ужасно, но я этой одной строкой решаю практически аналогичную задачу у себя. А у вас там пара страниц кода написана, который еще как-то там настраивать надо.
Если кто не в курсе, то юзера, хосты, ключи и алиасы замечательно настраиваются в ~/.ssh/config
Если предположить, что на компьтере уже есть ключи для гитхаба.битбакета, и имена репозиториев известны.
(Было бы странно, если бы разработчики не знали, какие у них репы. Да ведь?).
То весь бэкап делается примерно так:
cd ~/repos/; for i in `ls`; do (cd $i; git pull) done
Я сегодня просто пытался пользоваться «личным кабинетом» в качестве клиента (лишнюю подписку на Фотошоп отменял) — это пинцет какой-то!
То есть мотив написания статьи примерно такой — «многие люди хвалят Монгу, а я альтернативный чувак, похвалю Постгрес». А в результате фигня получается.
Но в примере у автора wrap-params, а это такая штука, которая принимает на вход request и на выход отдает тоже request. То есть речь о том, что автор за уши притягивает абсолютно не подходящие аргументы.
Или возьмем такую другой вариант передергивания — «какой DSL лучше всего описывает HTML?»
А кому вообще надо описывать html? Ведь у девелопера обычно совсем другая задача, а именно,
«каким-то образом запихать мою структуру данных в браузер, чтобы он ее понял».
Цепочка выглядит так
mydata -> templater -> html -> http(tcp,gzip,...) -> html -> parser -> dom
или вот так (в случае Clojure)
mydata -> hiccup -> html -> http(tcp,gzip,...) -> html -> parser -> dom
причем, во втором случае hiccup — это по сути тривиальное проеобразование теми же средствами, которые уже работают с mydata безо всяких дополнтельных «языков шаблонов» и т.п.
И ключевые моменты здесь «тривиальное» и «теми же средствами».
С идиотскими аргументами типа —
«Посмотрите на этот метод! Пежде чем его использовать придется посмотреть в документацию!»
Напрашивается вопрос — «а при чем тут типизация?».
Дело в том, что я-то как раз занимаюсь и разработкой и сопровождением, не первый десяток лет, причем. На старье желают сидеть только те, у кого просто нет выбора. И то до поры до времени, когда появится альтернатива.
Сейчас тебе расскажут, как в стране есть 100500 довольных клиентов сидящих на платформах столетней давности.
Битва за throws у методов идет просто не на жизнь, а на смерть!
Если уж так хочется ничего не ловить, а про все ошибки читать в логах вебсервера.
Как тут уже писали другие товарищи, этот вариант далеко не всегда является наиболее подходящим.
Есть возможность — можно использовать при желании. Можно не использовать, если не нравится. Дело вкуса — Одерски одно говорит, Блох другое.
Или я вот на Clojure пишу, а Scala мне не нравится. Мне теперь говорить, что Scala это вред?
Вред от разного вида эксепшенов очевиден только для тех, кто не понял как и для чего их использовать.
Вместо слова «эксепшен» здесь можно поставить практически любой другой термин.
Но это как бы не совсем правда и очень зависит от того, как сделана иерархия. Пример с тривиальным вебсервером, возвращающим либо 4хх либо 5хх при ошибке здесь не очень подходит.
Возьмем приложение, которое для своей работы пользуется данными из app_config и host_config. Получением этих данных занимается отдельный модуль, инкапсулирующий в себя всю мутотень ввода-вывода. Снаружи этого модуля мы точно не желаем видеть все богатство ioexception (формат, пути, файлы, права доступа, енкодинг и т.п.), а хотим видеть нечто более понятное. Собственно, для того мы и пишем этот модуль.
Что-нибудь в виде AppException и унаследованные от него ConfigVersionException, ConfigFormatException, ConfigReadException. Причем, часть из них может быть фатальными, а часть нет, в зависимости от ситуации — например, неправильная версия app_config это в морг, а для host_config возможно есть варианты.
Внутри же эт ого модуля FileNotFound может быть совсем не фатальным случаем ioexception, а поводом попробовать почитать другой файл (это сплошь и рядом).
Это я все к тому, что сложные вещи нельзя рассматривать на примере hello-world'а.
Но в остальном, создается впечатление, что про иерархии исключений он не слышал, и ничего кроме простейших вебсайтиков не писал. А лейтмотив всей статьи — «разработчики дураки, ничего сложнее одинокого try/catch правильно написать не муогут».
При всем моем уважении, упоминанине Фидонета в подобных случаях выглядит как проявление некоей латентной некрофилии. Сильно плохого в этом ничего нет, однако, рецидивы настораживают.
Искренне ваш,
ex. 2:5070/44
Если я сохранил платеж для чего-то, то я предполагаю, что буду использовать его в дальнйшем.
И если возникает мысль «надо заплатить ...», то тогда первая мысль тыкнуть в избранное, но ни в каком другом случае мне нет надобности смотреть в «избранное», что я там не видел?
Подумайте над поисковой строкой. В идеале, чтобы по набору в ней работал suggest по данным в порядке приоритета — избранное, история платежей, партнеры и т.п.
То есть если мне надо пополнить телефон тёщи, то я начинаю набирать его и в подсказке выскакивает последний платеж на этот телефон. Если я хочу перекинуть немного денег на Тинькова, то по набору «тинь» у меня однозначно бы определялся платеж из «избранного».
В общем, что тут объяснять, эта практика уже привычна и хорошо работает во многих местах.
Понятно, что можно внезапно найти это, тыкнув в «баланс» и запомнить, что оно лежит там.
Но такой расклад по первости ставит в тупик, видимо не только меня.
Какой, вообще, смысл так экономить на боквой менюшке?