Хорошо, но если jetty continuation второй вариант, то как быть с недостатком — «браузер отправляет запрос каждую секунду»? Это ведь неправильно в данном случае, соединение устанавливается и клиент ждет пока сервер найдет для него данные.
Да и второй недостаток под вопросом — «тяжело отследить онлайн-статус пользователя». Вы же храните в памяти набор открытых сокетов, точно также можно continuation хранить активные.
Конечно у jetty continuation есть недостатки (низкий уровень абстракции, открытие нового соединения для следующего запроса). Но в принципе они преодолимы и не так страшны, да и работают практически везде где есть xmlhttprequest. К тому же не стоит забывать что jetty continuation используются как библиотека для построения websocket.
Вы в посте утверждаете что для решения поставленной задачи есть три варианта. Почему вы не рассматривали вариант jetty continuation? Почему данный вариант вам не подошел?
Вы меня конечно извините, но в чем смысл писать конструкции вида — «case SCENARIO_ONE: scenarioOne(); break;». Это для экономии места чтобы в одном методе больше операторов на один экран помещалось? Просто обычно принято оператор = новая строка, так читать код проще.
Также довольно сомнителен выигрыш от enum, это просто вопрос привычки как лучше писать. У нас пишут на ifelse и не жужжат, так всем проще и понятнее.
И напоследок о производительности и добавлении новых типов обработчиков: а почему бы не использовать Map<String, ICommand>? И динамически добавлять новые команды на лету?
За перевод конечно спасибо, но выигрыш при использовании LambdaJ невелик.
Во первых надо себя переучивать думать их категориями (глаз набит на стандартные шаблонны циклов с ифами). Но тут конечно можно старперов лесом отправить.
Во вторых большинство кода уже написано без LambdaJ (помнить два способа обработки расточительно, а поддерживать-переписывать утомительно). Хотя тут все можно отрефакторить (красота в коде это красиво).
В третьих некоторые вещи (оптимально написанный код, который действительно нужен) сделать на LambdaJ — это немного оверхед (конструкция по сложности будет впечатлять не меньше циклов с ифами).
В четвертых отладка станет немного адом, хотя тут очень сильно зависит от специфики кода и программиста.
Плюс к тому производительность, как вы уже упоминали, да и исходный код у LambdaJ не очень…
По мне так придумывание лишних-новых сущностей и уровней есть зло. В общем случае стоит свести все к взаимодействию субъекта над объектом, и тут можно выделить три базовых уровня: над чем оперируем (модель), как оперируем (вид), правила взаимодействия (контроллер). В таком случае клиент-сервер стоит рассматривать не как множество разных слоев, а как иерархическую модель mvc.
Например, классы данных (entity) на сервере будут моделью, классы для получения данных (dao, service) будут видом, а связующая логика (interceptors, security, ioc) будет являться контроллером. Причем в данном случае вид (можно взять другой термин) не будет иметь визуального представления, он будет только предоставлять интерфейс для работы с данными. Тоже самое можно сказать и об интерфейсе пользователя (модель — данные с сервера, вид — интерфейс пользователя, контролер — связующий фреймворк).
А далее надо агрегировать нижние уровни иерархии в общую сущность, на этом уровне абстракции можно рассматривать вид как весь клиентский код, модель как всю серверную логику, а контроллером будет правила их взаимодействия (часть серверного и клиентского кода по согласованию).
Кстати, в данную модель идеально ложатся отдельные компоненты пользовательского интерфейса (базовые компоненты, например компоненты для отображения таблиц). Также, можно подвести базу со стороны хранилища данных (если там есть логика, упаси меня бог от этого мракобесия).
В итоге рассматривать систему в иерархическом виде удобнее и полезнее для мозга, да не придется запоминать частные (вырожденные) случаи (которых более 9 тысяч).
p/s
Кстати, большое количество кода бизнес логики на клиенте (клиентский javascript толкает к этому) ведет к еще одной проблеме: надо валидировать не только данные на клиенте и сервере, но и правила вызова методов (функций) на клиенте и сервере. Но такова судьба…
Я абсолютно также себя веду, плюс спрашиваю Имена и Фамилии людей с кем буду работать (интернет нам поможет). И конечно прошу показать рабочее место. Люди такого не ожидают обычно :)
Вы меня конечно извините, но покажите мне программистов которые укладываются в заранее оговоренные сроки, и менеджеров которые всегда согласны со сроками которые говорят программисты. Где этот Эдем?
А если серьезно, то как уже говорили выше, надо чтобы менеджер знал все значительные вещи в проекте, это его стезя. И его цель всегда договариваться о срываемых и уточняемых сроках с заказчиком и программистом. И если одна из сторон с которой он общается неадекватна, то не повезло менеджеру и надо приводить все к общему знаменателю (или начать пить).
p/s
Кстати, ежедневные отчеты исполнителей (которые можно иногда не читать), и постоянный контакт с воспитанием заказчика это то без чего сложно жить.
Просто было интересно понять какие есть общепринятые паттерны использования функциональных языков. Кстати, правильно ли я понимаю что на чистых функциональных языках никто не пишет? Только вставки и интеграция с другим кодом?
Эх, теория это конечно хорошо. Но охота «мяса». Можно по подробнее про использование функциональных языков в пром разработке. Как например они интегрируются с обычными языками? Или обычных языков нет совсем?
У всех опытных программистов, которых я встречал, есть код со всех мест их работы. Я пока не встретил ни одного программиста уровня senior, который бы не таскал код за собой.
Да и сложно полностью забыть код который был написан ранее. Конечно флеш память надежнее органической памяти, но все же…
Кстати, нормальный заказчик платит за решение проблем, а не за строчки кода. Так почему нельзя пользоваться написанным ранее кодом?
Да все нормально, к тому что большинство тупо пишет код (не улучшая процесс) надо просто привыкнуть.
Кстати, есть такая забавная книга Алена Картера — Программистский камень, и там предлагается разделить программистов на паковщиков (обычные рабочие лошадки) и картостроителей (необычные рабочие лошадки, которые помогают обычным эффективно работать).
И что вы делаете с «ложными срабатываниями»? Бывает что тесты просто идут «под нож»? Просто я работал в одной компании, где было принято просто удалять неправильные тесты, без переделывания.
А почему тестеры не смогли писать функциональные тесты? Интересно ваше мнение :)
Кстати, а какое у вас соотношение тестировщиков к разработчикам?
Да и второй недостаток под вопросом — «тяжело отследить онлайн-статус пользователя». Вы же храните в памяти набор открытых сокетов, точно также можно continuation хранить активные.
Конечно у jetty continuation есть недостатки (низкий уровень абстракции, открытие нового соединения для следующего запроса). Но в принципе они преодолимы и не так страшны, да и работают практически везде где есть xmlhttprequest. К тому же не стоит забывать что jetty continuation используются как библиотека для построения websocket.
Также довольно сомнителен выигрыш от enum, это просто вопрос привычки как лучше писать. У нас пишут на ifelse и не жужжат, так всем проще и понятнее.
И напоследок о производительности и добавлении новых типов обработчиков: а почему бы не использовать Map<String, ICommand>? И динамически добавлять новые команды на лету?
Во первых надо себя переучивать думать их категориями (глаз набит на стандартные шаблонны циклов с ифами). Но тут конечно можно старперов лесом отправить.
Во вторых большинство кода уже написано без LambdaJ (помнить два способа обработки расточительно, а поддерживать-переписывать утомительно). Хотя тут все можно отрефакторить (красота в коде это красиво).
В третьих некоторые вещи (оптимально написанный код, который действительно нужен) сделать на LambdaJ — это немного оверхед (конструкция по сложности будет впечатлять не меньше циклов с ифами).
В четвертых отладка станет немного адом, хотя тут очень сильно зависит от специфики кода и программиста.
Плюс к тому производительность, как вы уже упоминали, да и исходный код у LambdaJ не очень…
Например, классы данных (entity) на сервере будут моделью, классы для получения данных (dao, service) будут видом, а связующая логика (interceptors, security, ioc) будет являться контроллером. Причем в данном случае вид (можно взять другой термин) не будет иметь визуального представления, он будет только предоставлять интерфейс для работы с данными. Тоже самое можно сказать и об интерфейсе пользователя (модель — данные с сервера, вид — интерфейс пользователя, контролер — связующий фреймворк).
А далее надо агрегировать нижние уровни иерархии в общую сущность, на этом уровне абстракции можно рассматривать вид как весь клиентский код, модель как всю серверную логику, а контроллером будет правила их взаимодействия (часть серверного и клиентского кода по согласованию).
Кстати, в данную модель идеально ложатся отдельные компоненты пользовательского интерфейса (базовые компоненты, например компоненты для отображения таблиц). Также, можно подвести базу со стороны хранилища данных (если там есть логика, упаси меня бог от этого мракобесия).
В итоге рассматривать систему в иерархическом виде удобнее и полезнее для мозга, да не придется запоминать частные (вырожденные) случаи (которых более 9 тысяч).
p/s
Кстати, большое количество кода бизнес логики на клиенте (клиентский javascript толкает к этому) ведет к еще одной проблеме: надо валидировать не только данные на клиенте и сервере, но и правила вызова методов (функций) на клиенте и сервере. Но такова судьба…
А если серьезно, то как уже говорили выше, надо чтобы менеджер знал все значительные вещи в проекте, это его стезя. И его цель всегда договариваться о срываемых и уточняемых сроках с заказчиком и программистом. И если одна из сторон с которой он общается неадекватна, то не повезло менеджеру и надо приводить все к общему знаменателю (или начать пить).
p/s
Кстати, ежедневные отчеты исполнителей (которые можно иногда не читать), и постоянный контакт с воспитанием заказчика это то без чего сложно жить.
Просто было интересно понять какие есть общепринятые паттерны использования функциональных языков. Кстати, правильно ли я понимаю что на чистых функциональных языках никто не пишет? Только вставки и интеграция с другим кодом?
Вот для себя подобное можно писать, но лишь очень изредка…
Да и сложно полностью забыть код который был написан ранее. Конечно флеш память надежнее органической памяти, но все же…
Кстати, нормальный заказчик платит за решение проблем, а не за строчки кода. Так почему нельзя пользоваться написанным ранее кодом?
Кстати, есть такая забавная книга Алена Картера — Программистский камень, и там предлагается разделить программистов на паковщиков (обычные рабочие лошадки) и картостроителей (необычные рабочие лошадки, которые помогают обычным эффективно работать).
Это жизнь.
А почему тестеры не смогли писать функциональные тесты? Интересно ваше мнение :)
Кстати, а какое у вас соотношение тестировщиков к разработчикам?