Не понравилось:
— кнопки «магазин» и «справочник» внизу
— Свои и чужие сообщения не подсвечиваются по разному
— Везде торчат какие-то кнопки которые нахрен не нужны и которые не убираются
Вот мне интересно, чем они руководствовались, когда вынесли кнопку переключения режимов отображения вверх, к кнопкам maximize, minimize, close? Это типа очень важная функция и народ будет переодически туда-сюда переключаться и потом все окошки на место перетаскивать? Или может типа, глядишь промажет кто мимо минимизации да интерфейсом новым лишний раз засветить?
Знает кто-нибудь как эту хрень убрать?
Девайс крайне неудачный. Очень шумный, греется, нормальных дров под XP практически нету, живет от силы полтора часа. Вообщем даже и не думайте.
Но у меня правда t1000 может они его проапдейтили как-то.
Вы зря не дали потестить сабж своему отцу с 15-ти летним стажем. Он бы реально рассказал, какие у него возникли неудобства и что хорошо. Если у вас нету никаких проблем, связаных с неправильной посадкой, вы вряд ли сумеете обратить внимание на действительно важные вещи.
SOAP по сути это стандарт, которого нужно придерживаться для того, чтобы Ваш сервис могли использовать клиенты, написаные на совершенно разных языках программирования и под различные платформы. Над SOAP есть множество стандартных настроек для решения типичных задач (authentication/reliable messaging/transactions/security tokens/etc), использование которых сделает ваш сервис совместимым с большим количеством клиентов.
В данном обзоре пропущена важная часть, связаная с веб-сервисами. Это WS-I Basic Profile — набор рекоммендаций и стандартов к SOAP, WSDL, UDDI для девелоперов веб-сервисов, предназначеная для того, чтобы увеличить interoperability(возможность взаимодействия\совместимость?) между приложениями.
Ну вообщем SOAP это стандартизированый XML c целым набором технологий, основная суть которых — повторюсь, interoperability.
В приведенном примере используется динамическая генерация стабов в рантайме. Но в большинстве случаев конечно используется статическая генерация со всеми вытекающими заглушками.
Сталкивались ли вы с live broadcast и необходимостью организации multicast? Насколько я знаю smotri.com предоставляет только статичный контент. Если да, было бы интересно услышать, как все организовано в плане архитектуры и оборудования.
Как ни странно, но я знаю ответ на этот вопрос, хоть и не знаком с данным товарищем.
Не работает, потому что тесты у них нифига не тестируют, да и написаны они, только ради галочки, чтобы похвалиться друг перед другом, мол, у нас тесты есть. Про 100% покрытие видимо опять же, для красивого словца упомянуто.
> Совет. Понять свой код. Убедиться в том, что в программе протекают задуманные процессы. Совет. Чтобы понять свой код нужно написать тест к этому коду.
Идея всех этих портлетов конечно неплохая. Но реализация — не знаю как сейчас, но пару лет назад была полная туфта. Взаимодействие между портлетами кривое, море багов в имплементациях, везде приходится вставлять костыли.
На самом деле достаточно сложно представить себе серьезное приложение, с реальной необходимостью выполняться в качестве портлета. Все то же самое можно сделать на уровне приложения с меньшими трудозатратами. Если бы портлеты облегчали жизнь и можно было бы любое приложение выполнить в портлете не затрачивая на это усилий, это было бы ценно. Но на практике дело обстоит по другому, все это выливается в воспаленный геморройный узел самизнаетегде.
Портлеты задумывались как технология, предназначеная для реализации информационных порталов, которые содержат внутри себя некоторое количество разнообразных бизнес приложений. Т.е. на странице портала может быть несколько окон, в каждом из них располагается отдельное приложение, независимое от других. Если вы видели когда-нибудь iGoogle то концепция та-же, портлет-контейнер предоставляет единый способ управления окнами, а сами приложения уже могут выполнять конкретные функции, типа показа календаря или биржевых сводок.
Касательно ответа на вопрос — портлеты построены на базе сервлетов. Т.е. по сути — портлет контейнер это сервлет, который является враппером для вызова функций портлета. Сравнивать их неуместно, это просто надстройка над сервлетами.
Меня терзают смутные сомнения. Вообще то задача управления потоков и разруливания принципов распределения ресурсов между процессорами — задача достаточно низкоуровнего характера. Т.е. по хорошему сама среда, в которой выполняется приложение пользователя должна заниматься этими делами, предоставляя возможность программисту бизнес приложений сконцентрироваться на бизнес-задачах соответственно. А здесь вместо этого мы имеем coupling с resource management и самому разработчику предлагается а) знать, на каких машинах будет выполняться приложение, б) вставлять в код приложения подобного рода затычки, если есть вероятность, что приложение установят на многопроцессорную машину. в) менеджить это все добро со всеми вытекающими последствиями.
Вопрос — действительно ли стоит так восторгаться сим замечательным поделием? Может это просто hot-fix от микрософт перед выпуском фреймворка, который будет работать нормально на многопроцессорных системах?
Да, впринципе может быть еще какой-нибудь подтип приложений, в которых нужно руками распределять нагрузку на процессоры, и там такой подход будет несомненно полезен. Но повальное большинство проектов к такому классу не относятся.
Решению вопроса масштабируемости в этой статье как ни парадоксально, было отведено совсем мало места. Ну а про надежность такого решения речь как бы совсем не шла (и это правильно, поскольку это задача немного другого характера). Так вот, если рассмотреть представленую архитектуру, действительно получается, что каждая нода содержит некие уникальные данные, которые по хорошему должны быть защищены, если речь идет о высоконадежной системе. Поэтому для решения этой задачи понадобится делать реплицирующие сервера, на каждый существующий сервер, с возможным резделением ролей на Master-Slave\Master для оптимизации производительности. Еще одной single point of failure является сервер, на котором крутится PL/Proxy и PGBouncer, которую тоже неплохо было бы продублировать. И речь тут еще не идет о самом бизнес приложении, которое эту базу использует. Таким макаром получаем целый зоопарк дорогостоящего оборудования, который не каждая компания может себе позволить. Как результат разработчики высоконагруженых\кластерных систем выбирают для себя наиболее приемлимый уровень надежности, по соотношению цена\качество.
— кнопки «магазин» и «справочник» внизу
— Свои и чужие сообщения не подсвечиваются по разному
— Везде торчат какие-то кнопки которые нахрен не нужны и которые не убираются
Знает кто-нибудь как эту хрень убрать?
Но у меня правда t1000 может они его проапдейтили как-то.
Работает начиная с 1.6 и 5 соответственно.
В данном обзоре пропущена важная часть, связаная с веб-сервисами. Это WS-I Basic Profile — набор рекоммендаций и стандартов к SOAP, WSDL, UDDI для девелоперов веб-сервисов, предназначеная для того, чтобы увеличить interoperability(возможность взаимодействия\совместимость?) между приложениями.
Ну вообщем SOAP это стандартизированый XML c целым набором технологий, основная суть которых — повторюсь, interoperability.
Не работает, потому что тесты у них нифига не тестируют, да и написаны они, только ради галочки, чтобы похвалиться друг перед другом, мол, у нас тесты есть. Про 100% покрытие видимо опять же, для красивого словца упомянуто.
Совет. Чтобы понять свой код нужно написать тест к этому коду.
На самом деле достаточно сложно представить себе серьезное приложение, с реальной необходимостью выполняться в качестве портлета. Все то же самое можно сделать на уровне приложения с меньшими трудозатратами. Если бы портлеты облегчали жизнь и можно было бы любое приложение выполнить в портлете не затрачивая на это усилий, это было бы ценно. Но на практике дело обстоит по другому, все это выливается в воспаленный геморройный узел самизнаетегде.
Касательно ответа на вопрос — портлеты построены на базе сервлетов. Т.е. по сути — портлет контейнер это сервлет, который является враппером для вызова функций портлета. Сравнивать их неуместно, это просто надстройка над сервлетами.
Вопрос — действительно ли стоит так восторгаться сим замечательным поделием? Может это просто hot-fix от микрософт перед выпуском фреймворка, который будет работать нормально на многопроцессорных системах?
Да, впринципе может быть еще какой-нибудь подтип приложений, в которых нужно руками распределять нагрузку на процессоры, и там такой подход будет несомненно полезен. Но повальное большинство проектов к такому классу не относятся.