Вы это где-то в интернетах прочитали или самостоятельно внедрением/сопровождением занимаетесь?
Дело в том, что я-то как раз занимаюсь и разработкой и сопровождением, не первый десяток лет, причем. На старье желают сидеть только те, у кого просто нет выбора. И то до поры до времени, когда появится альтернатива.
Вообще, создается впечатление, что у многих людей 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 по данным в порядке приоритета — избранное, история платежей, партнеры и т.п.
То есть если мне надо пополнить телефон тёщи, то я начинаю набирать его и в подсказке выскакивает последний платеж на этот телефон. Если я хочу перекинуть немного денег на Тинькова, то по набору «тинь» у меня однозначно бы определялся платеж из «избранного».
В общем, что тут объяснять, эта практика уже привычна и хорошо работает во многих местах.
Тут уже писали где-то, что хорошо бы выделить отдельный пункт меню под информацию о счете, реквизиты, карты и т.п.
Понятно, что можно внезапно найти это, тыкнув в «баланс» и запомнить, что оно лежит там.
Но такой расклад по первости ставит в тупик, видимо не только меня.
Какой, вообще, смысл так экономить на боквой менюшке?
Попробую еще раз объяснить основную проблему.
Захожу на money.yandex.ru и вижу на странице
— сумма (справа вверху)
— 7 пунктов «сохраненного»
— под ними «показать еще»
— и где-то внизу виднееется заголовок «история»
Из всего этого многообразия полезной информацией является только «сумма», а чтобы посмотреть «историю» необходимо мотать страницу до низу. «Сохраненные» нужны лишь один-два раза в месяц, надо сделать хотя бы возможность сворачивать их полностью, чтобы было видно «историю» без промотки.
Видно, что поработали, по дизайну стало лучше, но по юзабилити хуже.
Поясняю:
Заходим money.yandex.ru, видим слева менюшку
«История», «Избранное», «Товары», «Переводы», «прием платежей», подсвечен первый пункт «История».
И теперь там на всю страницу расписаны «Сохраненные»!!!
Какого фига мне теперь каждый раз любоваться на них?!
Я и так прекрасно знаю, что у меня есть в «избранном», и когда понадобится я кликну этот пункт,
мне вовсе не надо при каждом визите в Яндекс.Деньги платить что-либо по «избранным».
Зато теперь до «Истории» надо мотать страницу.
Куда делся удобный «дашборд», где можно и «товар» выбрать, и историю оглядеть, и номер телефона/емалйа вбить для перевода?
В конце концов, поисковая компания могла бы сделать более умный поиск, чтобы по нескольким введенным символам можно было сразу отобразить подходящее из недавних платежей/избранного/и др.
Если я не очень понятно объясняю, то посмотрите, как это в телефоне работает.
Каждый раз читая про РеактОС уношусь в мир молодости… ДОС бокс, мощнейший 386SX25 рядом с моей рабочей лошадкой AT286/2/16МГц/52Мб Quantum/VGA/косые… Сетевые драйвера, работающие только в реал моде и все такое прочее.
Из этого описания ничего не следует про неподтвержденную пакетную запись, lastError просто статус последней операции по данному коннекшену.
Cейчас они просто унесли эту функциональность внутрь вызова write, так как пользователей задолбало каждый раз самим звать getLastError —
«A new protocol for write operations integrates write concerns with the write operations, eliminating the need for a separate getLastError».
«при getLastError монга должна гарантировано ждать записи всех пакетов» — а это где-то написано для случая unacknowledged bulk? Как-то это мало вероятно, особенно если там пакеты кто-то реордерит внутри. Просто юзкейс не очень понятен.
Вот что они внесли getLastError внутрь вызова — это вполне понятно и обосновано, как наиболее используемая практика.
Не буду переслушивать еще раз, но попробую что-нибудь вспомнить по горячим следам :)
В целом, доклад довольно длинный, но по объему содержащейся информации его стоило бы сократить раза в два — восприятие улучшилось бы. (Это я сужу по тому, где находился бегунок в плеере, когда я пошел смотреть — «а не промотать ли немного подальше?»).
Как-то стоит конкретизировать примеры до частных случаев, так как если говорить в общем, то всегда найдется масса контрпримеров.
Когда говорите о чем-нибудь, например об npm, узнайте о его особенностях. Он как раз по дефолту складывает все чужие исходники в явном виде прямо к вам в директорию проекта. Мало того, он для каждого подмодуля может вытягивать свою отдельную версию какой-нибудь библиотеки. Кстати, эта часть у него идеологически лучше сделана, чем у Питона.
То, что править чужой отлаженный код — весьма ответственное занятие и надо перед этим сто раз подумать и передумать — это совсем другой вопрос, к количеству репозиториев никак не относящийся.
Проблемы деплоя в общем тоже весьма опосредованно связаны со структурой репозиторием и их количеством. Грубо говоря, если у вас проект класса hello-world, то там пофиг, как деплоиться. А если проект на десятки тысяч строк, то «rsync / ln -s» скорее всего будет последним по важности вопросом, над которым придется задумываться.
Аналогинчно насчет virtualenv — чтобы не стать поклонниками cargo-культа, надо понимать что и для чего нужно. К примеру, если вы не абстрактный веб-опенсорс разработчик, а делаете проект под конкретное стабильное окружение, то легко можно залить/поставить все себе без плясок вокруг virtualenv и т.п.
Очень странно звучит тезис в начале и в конце доклада о том, что «любой большой проект начинается с одного файла».
Это не так в подавляющем большинстве случаев, если это файл не readme, конечно :)
Если говорить о веб-опенсорс, то там гораздо более типична ситуация — «а версию 2.0 мы перепишем заново на Рельсах/Джанго/Ерганге/Кофескипте, перейдем с меркуриала на гит, переделаем деплоймент под Амазон и т.п.». И расклад кода по модулям/репозиториям происходит заново сам собой.
Вообще-то, про размер bulk пакета однозначно написано в документации —
"""
Each group of operations can have at most 1000 operations. If a group exceeds this limit, MongoDB will divide the group into smaller groups of 1000 or less. For example, if the bulk operations list consists of 2000 insert operations, MongoDB creates 2 groups, each with 1000 operations.
"""
Не пробовали вместо getLastError просто ставить acknowledge на последний bulk-пакет?
Насколько я понимаю ваш getLastError именно так и срабатывает.
Дело в том, что я-то как раз занимаюсь и разработкой и сопровождением, не первый десяток лет, причем. На старье желают сидеть только те, у кого просто нет выбора. И то до поры до времени, когда появится альтернатива.
Сейчас тебе расскажут, как в стране есть 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 по данным в порядке приоритета — избранное, история платежей, партнеры и т.п.
То есть если мне надо пополнить телефон тёщи, то я начинаю набирать его и в подсказке выскакивает последний платеж на этот телефон. Если я хочу перекинуть немного денег на Тинькова, то по набору «тинь» у меня однозначно бы определялся платеж из «избранного».
В общем, что тут объяснять, эта практика уже привычна и хорошо работает во многих местах.
Понятно, что можно внезапно найти это, тыкнув в «баланс» и запомнить, что оно лежит там.
Но такой расклад по первости ставит в тупик, видимо не только меня.
Какой, вообще, смысл так экономить на боквой менюшке?
Захожу на money.yandex.ru и вижу на странице
— сумма (справа вверху)
— 7 пунктов «сохраненного»
— под ними «показать еще»
— и где-то внизу виднееется заголовок «история»
Из всего этого многообразия полезной информацией является только «сумма», а чтобы посмотреть «историю» необходимо мотать страницу до низу. «Сохраненные» нужны лишь один-два раза в месяц, надо сделать хотя бы возможность сворачивать их полностью, чтобы было видно «историю» без промотки.
«Сохраненные (9 штук) [показать] [избранное/напоминания/автоплатежи]»
«История ...»
Поясняю:
Заходим money.yandex.ru, видим слева менюшку
«История», «Избранное», «Товары», «Переводы», «прием платежей», подсвечен первый пункт «История».
И теперь там на всю страницу расписаны «Сохраненные»!!!
Какого фига мне теперь каждый раз любоваться на них?!
Я и так прекрасно знаю, что у меня есть в «избранном», и когда понадобится я кликну этот пункт,
мне вовсе не надо при каждом визите в Яндекс.Деньги платить что-либо по «избранным».
Зато теперь до «Истории» надо мотать страницу.
Куда делся удобный «дашборд», где можно и «товар» выбрать, и историю оглядеть, и номер телефона/емалйа вбить для перевода?
В конце концов, поисковая компания могла бы сделать более умный поиск, чтобы по нескольким введенным символам можно было сразу отобразить подходящее из недавних платежей/избранного/и др.
Если я не очень понятно объясняю, то посмотрите, как это в телефоне работает.
О! Вспомнил, у меня же программы для РеактОС сохранились — penzin.ru/retro/
Это специально для тех, кто не любит закапывать стюардессу :)
В остальном, allmychanges меня интересует только как стророннего наблюдателя, а рсс такой я бы заюзал.
Cейчас они просто унесли эту функциональность внутрь вызова write, так как пользователей задолбало каждый раз самим звать getLastError —
«A new protocol for write operations integrates write concerns with the write operations, eliminating the need for a separate getLastError».
Вот что они внесли getLastError внутрь вызова — это вполне понятно и обосновано, как наиболее используемая практика.
В целом, доклад довольно длинный, но по объему содержащейся информации его стоило бы сократить раза в два — восприятие улучшилось бы. (Это я сужу по тому, где находился бегунок в плеере, когда я пошел смотреть — «а не промотать ли немного подальше?»).
Как-то стоит конкретизировать примеры до частных случаев, так как если говорить в общем, то всегда найдется масса контрпримеров.
Когда говорите о чем-нибудь, например об npm, узнайте о его особенностях. Он как раз по дефолту складывает все чужие исходники в явном виде прямо к вам в директорию проекта. Мало того, он для каждого подмодуля может вытягивать свою отдельную версию какой-нибудь библиотеки. Кстати, эта часть у него идеологически лучше сделана, чем у Питона.
То, что править чужой отлаженный код — весьма ответственное занятие и надо перед этим сто раз подумать и передумать — это совсем другой вопрос, к количеству репозиториев никак не относящийся.
Проблемы деплоя в общем тоже весьма опосредованно связаны со структурой репозиторием и их количеством. Грубо говоря, если у вас проект класса hello-world, то там пофиг, как деплоиться. А если проект на десятки тысяч строк, то «rsync / ln -s» скорее всего будет последним по важности вопросом, над которым придется задумываться.
Аналогинчно насчет virtualenv — чтобы не стать поклонниками cargo-культа, надо понимать что и для чего нужно. К примеру, если вы не абстрактный веб-опенсорс разработчик, а делаете проект под конкретное стабильное окружение, то легко можно залить/поставить все себе без плясок вокруг virtualenv и т.п.
Очень странно звучит тезис в начале и в конце доклада о том, что «любой большой проект начинается с одного файла».
Это не так в подавляющем большинстве случаев, если это файл не readme, конечно :)
Если говорить о веб-опенсорс, то там гораздо более типична ситуация — «а версию 2.0 мы перепишем заново на Рельсах/Джанго/Ерганге/Кофескипте, перейдем с меркуриала на гит, переделаем деплоймент под Амазон и т.п.». И расклад кода по модулям/репозиториям происходит заново сам собой.
"""
Each group of operations can have at most 1000 operations. If a group exceeds this limit, MongoDB will divide the group into smaller groups of 1000 or less. For example, if the bulk operations list consists of 2000 insert operations, MongoDB creates 2 groups, each with 1000 operations.
"""
Не пробовали вместо getLastError просто ставить acknowledge на последний bulk-пакет?
Насколько я понимаю ваш getLastError именно так и срабатывает.