Pixel-perfect дизайн уходит в прошлое — пиксель теперь не разглядеть.
Но вообще идея хорошая, потому что масштабирование на маке всегда работало хорошо.
Единственное, что большее количество пикселей ведет к большему энергопотреблению. Pro серия и так не отличалась работой в автономном режиме. Наверное еще ивесить будет много.
Нет, такого там нет.
Есть стандартный c:url, или spring:url, но они к контроллеру не привязываются. Хотя IDE, типа Idea резолвит и можно перейти к коду контрлллера.
По поводу пункта 1. Вебсервису использующему SOAP ничто не запрещает быть stateful. Rest сервис таким быть не может. Да, мы сравниваем архитектуру и протокол, но стоит понимать что то что использует SOAP может работать как REST, но не все, что SOAP есть REST.
если на сокетах — смакота: установил соединение, когда нужно клиент прислал запрос серверу, а когда нужно сервер прислал кленту событие даже без запроса на это
А сколько вы сокетов-то откроете одновременно? 100 запросов в секунду и прощай пул и здравствуй Service is out of its capacity
Вообще говоря, «машина состояния» — это в высоконагруженных проектах не всегда хорошо, так как по мимо трафика приходится еще и ресурсы на память состояния трэкать. Плюс встают вопросы масштабируемости такой «машины состояния». Здесь уже не сделаешь дешевое горизонтальное масштабирование, надо продумывать миграцию сессий и данных, а также их безопасность.
1. появляются дополнительные интерфейсы
Если появляется специальной код для юниттестов — это значит, что в консеватории что-то надо менять.
Вы тестируете класс, его апи, даже если он еще не написан, связку вход-выход. Юнит тест стоит сбоку от класса и тестирует класс так, как видят его и могут использовать другие компоненты. И коду тут лишнего появится неоткуда.
Если речь идет о том, что мок можно повесить только на интерфейс, коего класс не имеет, и нужно отдельно создавать и пользовать только в юнит тесте — то это вопрос выбора тула тестирования (можно подумать об «абстракциях», но при нынешнем развитии метапрограммирования и других свистоперделок для уменьшения и ускорения кодирования это представляет собой сложную задачу аргументации). EasyMock и Mockito уже давно это имеют (со сложностями, правда, по статике, но тоже решается PowerMockом).
2. Собственно тоже самое про уровни и усложнение. Кода для юнит теста в тестируемом коде быть не должно, и код юниттестов не используется в самом коде приложения.
Вообще хороший подход такой:
1. Подумали как работает класс, придумалии что у класса будет вот такой апи, в смысле что я подам на этот компонент вот такие данные и получу оттуда только вот такой выход.
У знакомых это называлось Speclet, который отправлялся аналитику и позже вставлялся в шапку класса
2. Пишите юниттест, который реализует этот сценарий проверки.
3. Пишите логику класса, чтобы юнит тест выполнялся.
4. Делаете рефакторинг вашего класса.
Пункты 2-3-4 — это и есть TDD.
Есть резонные другие возражения.
А именно, если ли деньги на такое (это на 100% больше времени в начале, при сноровке — 40%)?
Есть ли острая необходимость иметь такое на всех уровнях вашего приложения? На каких имеет?
Эти вопросы трудны, неоднозначны и ваше мнение могут не разделять люди которые дают бюджет.
Нет, я как раз говорил о фреймворках, которые я перечислил, и о 10% задач, которые делают их непригодными.
Потому что подход «вам не надо думать о JS, пишите на уютной Java, мы все сделаем за вас» конкретно протекает, и делает он это в самый неподходящий момент. Поэтому писать что-то долгосрочное и agile — может быть рискованным.
Если это какая-то фиксированная CRUD морда, то ок — быстрее пишется именно так. Если ничего до конца не известно, берем plain HTML и навешиваем на него свисто-перделки на JS подключая JS фреймворки, код которых доступен и читаем, а также расширяем.
Поддерживаю, что это прослеживается из архитектуры.
Вообще, ИМО, такие библиотеки и надстройки (это и JSF, Wicket, Vaadin, GWT ) позволяют сделать где-то 50% функционала любой морды просто, 35% делается тяжело или очень тяжело, а 15 или 10 процентов вообще сделать не возможно, поэтому стоит прежде чем комитатся на какие-то дедлайны с этими технологиями, стоит понимать их возможности и предстоящую работу.
Спасибо, хороший обзор. Хотел уточнить вещь: бэкенд интерфейс — вы что под этим подразумеваете? Мониторинг утилизации ресурсов, судя по скриншотам?
От сбя дбавлю про jsf. Не знаю что там поменялось в версии 2, но версия 1.2 имела веселые вещи, типа различия имплементаций саном и myfaces. Вроде как richfaces работали только с одной. Так же там постоянно протекали абстракции динамических компонентов, что заставляло подписывать свой javascript с бошими трудностями по его дебагу.
Другой забавной штукой было хранени состояния view. Либо ты его хранишь на сервере, где он хранится в сессии, либо на клиенте. Состояние — это сериализоанный граф jsf компонентов. Если использовать всякие няшки от jsf по и18ции, а также например больше одной формы на странице, то просто можно получить страницу весом мегабайт 5 чистого хтмла из-за сериализованного там viewstateа. При использовании по-моему richfaces, компонент который хранит состояние на клиенте переопределен и тупо вовращает null при попытке его получить (хвала opensource).
Вообщем, можно сказать, чо jsf я готовить не умею, но впечатление он ( в купе с улучшайзерами ) произвел очень протекающей абстракции.
Но вообще идея хорошая, потому что масштабирование на маке всегда работало хорошо.
Единственное, что большее количество пикселей ведет к большему энергопотреблению. Pro серия и так не отличалась работой в автономном режиме. Наверное еще ивесить будет много.
Есть стандартный c:url, или spring:url, но они к контроллеру не привязываются. Хотя IDE, типа Idea резолвит и можно перейти к коду контрлллера.
1001 & 0001 = 1001 — это true?
1000 & 0001 = 1000 — это false?
Простите, не знаком с php truth.
И по поводу порта — это действительно miniVGA или display port? В перовом случае, о подключении внешних больших мониторов можно забыть?
А сколько вы сокетов-то откроете одновременно? 100 запросов в секунду и прощай пул и здравствуй Service is out of its capacity
Вообще говоря, «машина состояния» — это в высоконагруженных проектах не всегда хорошо, так как по мимо трафика приходится еще и ресурсы на память состояния трэкать. Плюс встают вопросы масштабируемости такой «машины состояния». Здесь уже не сделаешь дешевое горизонтальное масштабирование, надо продумывать миграцию сессий и данных, а также их безопасность.
1. появляются дополнительные интерфейсы
Если появляется специальной код для юниттестов — это значит, что в консеватории что-то надо менять.
Вы тестируете класс, его апи, даже если он еще не написан, связку вход-выход. Юнит тест стоит сбоку от класса и тестирует класс так, как видят его и могут использовать другие компоненты. И коду тут лишнего появится неоткуда.
Если речь идет о том, что мок можно повесить только на интерфейс, коего класс не имеет, и нужно отдельно создавать и пользовать только в юнит тесте — то это вопрос выбора тула тестирования (можно подумать об «абстракциях», но при нынешнем развитии метапрограммирования и других свистоперделок для уменьшения и ускорения кодирования это представляет собой сложную задачу аргументации). EasyMock и Mockito уже давно это имеют (со сложностями, правда, по статике, но тоже решается PowerMockом).
2. Собственно тоже самое про уровни и усложнение. Кода для юнит теста в тестируемом коде быть не должно, и код юниттестов не используется в самом коде приложения.
Вообще хороший подход такой:
1. Подумали как работает класс, придумалии что у класса будет вот такой апи, в смысле что я подам на этот компонент вот такие данные и получу оттуда только вот такой выход.
У знакомых это называлось Speclet, который отправлялся аналитику и позже вставлялся в шапку класса
2. Пишите юниттест, который реализует этот сценарий проверки.
3. Пишите логику класса, чтобы юнит тест выполнялся.
4. Делаете рефакторинг вашего класса.
Пункты 2-3-4 — это и есть TDD.
Есть резонные другие возражения.
А именно, если ли деньги на такое (это на 100% больше времени в начале, при сноровке — 40%)?
Есть ли острая необходимость иметь такое на всех уровнях вашего приложения? На каких имеет?
Эти вопросы трудны, неоднозначны и ваше мнение могут не разделять люди которые дают бюджет.
Потому что подход «вам не надо думать о JS, пишите на уютной Java, мы все сделаем за вас» конкретно протекает, и делает он это в самый неподходящий момент. Поэтому писать что-то долгосрочное и agile — может быть рискованным.
Если это какая-то фиксированная CRUD морда, то ок — быстрее пишется именно так. Если ничего до конца не известно, берем plain HTML и навешиваем на него свисто-перделки на JS подключая JS фреймворки, код которых доступен и читаем, а также расширяем.
Вообще, ИМО, такие библиотеки и надстройки (это и JSF, Wicket, Vaadin, GWT ) позволяют сделать где-то 50% функционала любой морды просто, 35% делается тяжело или очень тяжело, а 15 или 10 процентов вообще сделать не возможно, поэтому стоит прежде чем комитатся на какие-то дедлайны с этими технологиями, стоит понимать их возможности и предстоящую работу.
От сбя дбавлю про jsf. Не знаю что там поменялось в версии 2, но версия 1.2 имела веселые вещи, типа различия имплементаций саном и myfaces. Вроде как richfaces работали только с одной. Так же там постоянно протекали абстракции динамических компонентов, что заставляло подписывать свой javascript с бошими трудностями по его дебагу.
Другой забавной штукой было хранени состояния view. Либо ты его хранишь на сервере, где он хранится в сессии, либо на клиенте. Состояние — это сериализоанный граф jsf компонентов. Если использовать всякие няшки от jsf по и18ции, а также например больше одной формы на странице, то просто можно получить страницу весом мегабайт 5 чистого хтмла из-за сериализованного там viewstateа. При использовании по-моему richfaces, компонент который хранит состояние на клиенте переопределен и тупо вовращает null при попытке его получить (хвала opensource).
Вообщем, можно сказать, чо jsf я готовить не умею, но впечатление он ( в купе с улучшайзерами ) произвел очень протекающей абстракции.