В single page app самое трудное — правильно организовать кеширование на клиенте + асинхронно подготавливать DOM немного раньше, чем пользователь выбрал действие. :-) Это, конечно, серьезный технический вызов, но если сразу об этом думать, все вполне получается.
Вот это правильно!
Только тут дело не в single page или не single page.
ИМХО, можно и так, и эдак, но если не single page, то лучше REST.
И POST-запросы лучше AJAX'ом с обновлением контента или redirect'ом, чтобы URL всегда можно было скопировать и потом открыть то же самое, что и было :-)
Если «случайно обнаружили», то, стало быть, либо раньше не следили (что печально), либо что-то случилось (и нужно разбираться). Иначе это не случайность, а вполне ожидаемая закономерность, которую можно обнаружить намного раньше достижения этих самых 80%.
Чтобы реализовать такое, придется немного подумать :-) Определения все помню, принципы тоже…
Вы имеете в виду многопоточный вариант с заданным числом потоков? :-)
Плюсы checked exception понимаешь только тогда, когда тебе в production прилетел системный RuntimeException из недр framework'а с совершенно неадекватным сообщением об ошибке. :-)
P.S. К сожалению, довольно частая ситуация во всяких решениях, построенных на SAX-парсерах.
Тип исключения должен соответствовать уровню абстракции, на котором оно выкидывается.
Более того, код должен перехватывать и обрабатывать исключения с нижнего уровня, приводя их к должному уровню абстракции. Это верно для любых независимых компонентов.
Перед тем, как писать что-то адекватное, нужно прочитать не менее адекватный учебник по языку.
В каждом языке свои тонкости, без знания которых гарантировано напишешь 100-500 багов.
См. коммент выше.
Если в chaining упал NPE, то очень трудно однозначно интерпретировать причину.
Количество причин равно длине chain'а, и в итоге нужно анализировать гораздо больше сценариев.
Не проще ли написать несколько операторов присваивания, и точно знать причину?
IMHO, chaining необходимо запрещать на уровне code style, и требовать присваивать отдельным переменным.
Кстати, это и код делает более читабельным в 50% случаев, т.к. по коду одного и того же блока часто раскиданы одинаковые chaining-и вида getTable().getCurrent().getValue().
IMHO, их могут добавить на уровне платформы, и не включать в язык (точнее, включать только для поддержки Generic-ов на примитивных типах).
Как промежуточный вариант вполне себе нормально.
Микс знаковых и беззнаковых типов рождает хаос везде и всюду :-)
Не надо так делать в Java. Иначе на каждой арифметической операции придется думать об ошибках переполнения.
Разработчики получат за достижения? :-)
И сколько раз на вашей памяти такое случалось?
P.S. Имеется в виду ощутимая доля прибыли, а не символическое вознаграждение в виде премии, не превышающей размер ЗП.
Конечно, не самый типичный случай, но тем не менее.
Вот это правильно!
Только тут дело не в single page или не single page.
ИМХО, можно и так, и эдак, но если не single page, то лучше REST.
И POST-запросы лучше AJAX'ом с обновлением контента или redirect'ом, чтобы URL всегда можно было скопировать и потом открыть то же самое, что и было :-)
Столько всего узнаешь нового.
:-)
Чтобы реализовать такое, придется немного подумать :-) Определения все помню, принципы тоже…
Вы имеете в виду многопоточный вариант с заданным числом потоков? :-)
А не на решение задач. Решение задач, как правило, проверяют испытательным сроком.
P.S. К сожалению, довольно частая ситуация во всяких решениях, построенных на SAX-парсерах.
ИМХО, вполне нормально, если в JavaDoc описаны ВСЕ возможные случаи получения такого NPE.
Более того, код должен перехватывать и обрабатывать исключения с нижнего уровня, приводя их к должному уровню абстракции. Это верно для любых независимых компонентов.
В каждом языке свои тонкости, без знания которых гарантировано напишешь 100-500 багов.
Если в chaining упал NPE, то очень трудно однозначно интерпретировать причину.
Количество причин равно длине chain'а, и в итоге нужно анализировать гораздо больше сценариев.
Не проще ли написать несколько операторов присваивания, и точно знать причину?
Кстати, это и код делает более читабельным в 50% случаев, т.к. по коду одного и того же блока часто раскиданы одинаковые chaining-и вида getTable().getCurrent().getValue().
Как промежуточный вариант вполне себе нормально.
Не надо так делать в Java. Иначе на каждой арифметической операции придется думать об ошибках переполнения.
И сколько раз на вашей памяти такое случалось?
P.S. Имеется в виду ощутимая доля прибыли, а не символическое вознаграждение в виде премии, не превышающей размер ЗП.