Как это внезапно алгоритм (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 по данным в порядке приоритета — избранное, история платежей, партнеры и т.п.
То есть если мне надо пополнить телефон тёщи, то я начинаю набирать его и в подсказке выскакивает последний платеж на этот телефон. Если я хочу перекинуть немного денег на Тинькова, то по набору «тинь» у меня однозначно бы определялся платеж из «избранного».
В общем, что тут объяснять, эта практика уже привычна и хорошо работает во многих местах.
Тут уже писали где-то, что хорошо бы выделить отдельный пункт меню под информацию о счете, реквизиты, карты и т.п.
Понятно, что можно внезапно найти это, тыкнув в «баланс» и запомнить, что оно лежит там.
Но такой расклад по первости ставит в тупик, видимо не только меня.
Какой, вообще, смысл так экономить на боквой менюшке?
Попробую еще раз объяснить основную проблему.
Захожу на money.yandex.ru и вижу на странице
— сумма (справа вверху)
— 7 пунктов «сохраненного»
— под ними «показать еще»
— и где-то внизу виднееется заголовок «история»
Из всего этого многообразия полезной информацией является только «сумма», а чтобы посмотреть «историю» необходимо мотать страницу до низу. «Сохраненные» нужны лишь один-два раза в месяц, надо сделать хотя бы возможность сворачивать их полностью, чтобы было видно «историю» без промотки.
Видно, что поработали, по дизайну стало лучше, но по юзабилити хуже.
Поясняю:
Заходим money.yandex.ru, видим слева менюшку
«История», «Избранное», «Товары», «Переводы», «прием платежей», подсвечен первый пункт «История».
И теперь там на всю страницу расписаны «Сохраненные»!!!
Какого фига мне теперь каждый раз любоваться на них?!
Я и так прекрасно знаю, что у меня есть в «избранном», и когда понадобится я кликну этот пункт,
мне вовсе не надо при каждом визите в Яндекс.Деньги платить что-либо по «избранным».
Зато теперь до «Истории» надо мотать страницу.
Куда делся удобный «дашборд», где можно и «товар» выбрать, и историю оглядеть, и номер телефона/емалйа вбить для перевода?
В конце концов, поисковая компания могла бы сделать более умный поиск, чтобы по нескольким введенным символам можно было сразу отобразить подходящее из недавних платежей/избранного/и др.
Если я не очень понятно объясняю, то посмотрите, как это в телефоне работает.
Каждый раз читая про РеактОС уношусь в мир молодости… ДОС бокс, мощнейший 386SX25 рядом с моей рабочей лошадкой AT286/2/16МГц/52Мб Quantum/VGA/косые… Сетевые драйвера, работающие только в реал моде и все такое прочее.
Я сегодня просто пытался пользоваться «личным кабинетом» в качестве клиента (лишнюю подписку на Фотошоп отменял) — это пинцет какой-то!
То есть мотив написания статьи примерно такой — «многие люди хвалят Монгу, а я альтернативный чувак, похвалю Постгрес». А в результате фигня получается.
Но в примере у автора 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 по данным в порядке приоритета — избранное, история платежей, партнеры и т.п.
То есть если мне надо пополнить телефон тёщи, то я начинаю набирать его и в подсказке выскакивает последний платеж на этот телефон. Если я хочу перекинуть немного денег на Тинькова, то по набору «тинь» у меня однозначно бы определялся платеж из «избранного».
В общем, что тут объяснять, эта практика уже привычна и хорошо работает во многих местах.
Понятно, что можно внезапно найти это, тыкнув в «баланс» и запомнить, что оно лежит там.
Но такой расклад по первости ставит в тупик, видимо не только меня.
Какой, вообще, смысл так экономить на боквой менюшке?
Захожу на money.yandex.ru и вижу на странице
— сумма (справа вверху)
— 7 пунктов «сохраненного»
— под ними «показать еще»
— и где-то внизу виднееется заголовок «история»
Из всего этого многообразия полезной информацией является только «сумма», а чтобы посмотреть «историю» необходимо мотать страницу до низу. «Сохраненные» нужны лишь один-два раза в месяц, надо сделать хотя бы возможность сворачивать их полностью, чтобы было видно «историю» без промотки.
«Сохраненные (9 штук) [показать] [избранное/напоминания/автоплатежи]»
«История ...»
Поясняю:
Заходим money.yandex.ru, видим слева менюшку
«История», «Избранное», «Товары», «Переводы», «прием платежей», подсвечен первый пункт «История».
И теперь там на всю страницу расписаны «Сохраненные»!!!
Какого фига мне теперь каждый раз любоваться на них?!
Я и так прекрасно знаю, что у меня есть в «избранном», и когда понадобится я кликну этот пункт,
мне вовсе не надо при каждом визите в Яндекс.Деньги платить что-либо по «избранным».
Зато теперь до «Истории» надо мотать страницу.
Куда делся удобный «дашборд», где можно и «товар» выбрать, и историю оглядеть, и номер телефона/емалйа вбить для перевода?
В конце концов, поисковая компания могла бы сделать более умный поиск, чтобы по нескольким введенным символам можно было сразу отобразить подходящее из недавних платежей/избранного/и др.
Если я не очень понятно объясняю, то посмотрите, как это в телефоне работает.
О! Вспомнил, у меня же программы для РеактОС сохранились — penzin.ru/retro/
Это специально для тех, кто не любит закапывать стюардессу :)