Сейчас рано делать ставку на эту технологию. Кроме того пройдет немало времени, прежде чем все клиенты будут поддерживать ее. Поэтому лучше использовать оболочку для дуплексных коннекшнов, которая снизу умеет работать как с Comet, так и с WS. Для серверной части это фреймворк Atmosphere. К нему существует куча клиентов, например JQuery plugin: jfarcand.wordpress.com/2010/06/15/using-atmospheres-jquery-plug-in-to-build-applicationsupporting-both-websocket-and-comet
В своем проекте я использовал GWT Comet. В итоге не придется адаптировать логику на сервере и на клиенте под каждый тип коннекшна.
> WebSocket — протокол полнодуплексной двунаправленной связи поверх TCP соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.
Один реализуется поверх другого. Отличие примерно такое же как между JavaScript и JQuery. Но цель у них одна — дуплексный обмен данными в реальном времени. Использовать голый TCP в окружении браузера проблематично — это не юникс, и с тредами здесь проблемы. Поэтому добавили асинхронный JavaScript API для пакетного обмена.
Основная идея — прикинуться обычным http-запросом и как бы обойти корпоративные файрволы, для того, чтобы чатиться на фейсбуке или в gtalk-е. Реально же файрволы попросту обрежут непонятые хидеры и все.
У меня такое ощущение, что развитие IT-технологий — это вечное переизобретение велосипеда, только каждый раз более грузного и медленного. Изначально существовали обычные TCP-сокеты, которые решали и до сих пор решают поставленную задачу. Вебсокеты — это очередной велосипед, только средствами браузера.
Возможно я ошибаюсь, но графические библиотеки на пайтоне и руби — это всего лишь обертка для native-виджетов плюс некоторая прикладная функциональность типа байндинга данных, лейаутов и все такое. Сильно тормзить от этого не должно.
«Вязкость» же интерфейса получается от того, что ленивые студенты обрабатывают потенциально долгое действие (например запись на диск или поиск в БД) синхронно, то есть в том же треде, где происходит отрисовка и обработка событий. В результате гуй «висит» пока не выполнится действие. Вот веб-программисты уже изначально надрючены писать асинхронные обработчики, ибо сам браузер и платформа обязуют.
Java — это отдельный случай. Там вся отрисовка виджетов сделана программно с мимикрией под платформу. Все это тормозило до последней ветки (1.6 u10), где прикрутили полное аппаратное ускорение через DirectX. Хотя например в Eclipse сделана своя библиотека с байндингом в native-виджеты, поэтому у него свегда был интерфейс. Несколько лет юзаю eclipse, скоростью работы доволен. Да и нынешние Netbeans и Idea имеют более чем адекватный отклик для своего уровня сложности (юзеры Linux отсасывают, особенно с OpenJDK. Там до сих пор рендеринг сделан через тормозной X-api, хотя уже давно обещаны XRender и OpenGL).
Проблема отнюдь не в пайтоне или руби. Скриптового языка для написания гуя более чем достаточно (раз уж на на JavaScript под браузер десктопы пишут...)
Проблема в тормознутости низлежащих библиотек, в частности X Window с его левыми экстеншнами и рудиментарной уже ориентацией на сетевую архитектуру. Сейчас есть попытки заменить иксы на новый Wayland, даже Убунту заикнулись, что в 11.04 они сделают эту замену. Но что-то плохо верится — слишком радикально.
В каментах лучше всего записывать основные идеи алгоритма или реализации на человеческом языке. Я пишу каменты так, как-будто объясняю код другому человеку.
Пока все изменения — чисто сахар. Где-то даже видел пруф. Да и в статье же написано: лямбды транслируются в SAM-объекты.
Плохо то, что все нововведения в джаве смотрятся как пятое колесо, без единой идеи и унифицированного синтаксиса. Просто как взяли отдельную фичу из груви и засандалили в язык. По этой причине мне больше нравится Scala.
Аналогично! Критические моменты для меня — это перерывы в работе, например конец дня или пятница. В понедельник вообще бывает сложно загрузиться, и иногда вся неделя бывает непродуктивной. Либо когда поставишь точку в какрй-то подзадаче или модуле, бывает трудно перключиться на другую. Виной всему — память. Если забываешь структуру, над которой работал, так сказать «теряешь волну», то потом сложно втянуться. Скролишь туда-сюда написанный код и хрен проссышь что к чему.
Идея рецепта — максимально приблизить то состояние, в котором была максимальная работоспособность. Помогает следующее:
1. Ведите свой блог. Записывайте все мысли и ключевые идеи, которые возникли при реализации, даже если тогда они кажутся очевидными. Несмотря на то, что его будете читать только Вы, делайте это так, как-будто объясняете другому человеку. Чтение последних постов в блоге в понедельник поможет «загрузиться» и освежить кеш. Пишите «для себя», т.е. максимально просто, без цензуры и корректировки.
Раньше я вел обычную тетрадь, потому что было удобно рисовать схемки. Теперь я веду дневник в электронном формате, а рисунки часть рисую на бумаге, фотографирую и вставляю в пост.
2. Комментируйте код. Не бойтесь, если текст коментариев будет превышать сам код. Важно: несработавшую идею или ошибочную идею не удаляйте из кода, а закоменьте и пометьте записью почему она ошибочна, дабы потом не наступать на эти же грабли второй раз.
3. Создайте планировщик, в который будете добавлять задачи, которые требуется сделать. У меня это обычный файл, ибо меня напрягают трекеры типа Redmine и Jira. Разбейте задачи иерархически, например по модулям, и сортируйте их по приоритету. Если Вы заняты одной задачей и стало необходимо изменить что-то в другом модуле, не перепрыгивайте, а просто добавьте задачу.
Планировщик поможет быстро вспомнить что еще нужно делать, пока вы на пике, а также всегда наглядно представляет весь объем работ.
4. Самое важное правило девелопера: НЕ ПЫТАЙТЕСЬ СДЕЛАТЬ ВСЕ И СРАЗУ. Запал кончится быстро, а результат еще в конце тунеля — опускаются руки. Как правило актуально для новых проектов. Выпуск верси 1.0 — аццкий труд. Разбейте прокет на фазы так, чтобы в конце каждой фазы у вас всегда что-то запускалось.
Да знаю я этот мануал от Andries Inzé. Есть куча способов засандалить движок jBPM в программу на спринге. Я говорю о Spring 3.0 dm — сервере. У меня на нем вся ESB построена (Apache Camel). Вобщем что до сих пор ищется, это: Opensource BPMN с визуальными средствами моделирования и OSGI-deployment.
Что мне было нужно, так это бандлить процессы в отдельные OSGI-модули, имеющие свой цикл жизни и поддерживающие нативно версионность. Для этого необходимо было иметь jBPM, запакованный в OSGI-модуль с API доступным на уровне OSGI-сервисов. Тем не менее, прототип был состряпан и даже вроде работал. Однако начальство сделало ошибочную ставну на Websphere.
Хорошо, что есть автоматические конвертеры BPMN в BPEL, а то в нашем проекте все делается вручную: аналисты используют Tibco Studio BPMN, а программисты переписывают BPEL на WebSphere. Однако схема конвертации BPMN в BPEL обладает одним существенным недостатком: зачастую администратор хочет видеть наглядно что произошло с его процессом и где он в данный момент находится. А машинно-сгенерированный BPEL будет сильно отличаться от модели процесса.
> Родная интеграция со Spring-ом
Прошу прощения, где это родная интеграция со спрингом в jBPM 4? По-моему на офсайте лежит ссылка на левый мануал от одного чувака, который смог прикрутить jbpm к спрингу, и то версии 2.5. Нормального бандла для 3.0 до сих пор не существует в природе (оно и понятно). В свое время это меня остановило.
jBPM убил jPDL и ужасный плагин для начертания процессов. Работать неудобно и отвратно. Нужно раньше было смотреть в сторону BPMN (BPEL изначально был мертворожденный), хотя бы тулзы сторонних разработчиков можно было бы использовать. Сам по себе движок JBPM неплохой, достаточно простой и расширяемый. Но в Activi есть все, что так не хватало — интергация со спрингом, BPMN 2.0 и неплохой дизайнер процессов.
Теоретически Workflow — это конечный автомат. Не более, не менее. Описывается набором своих состояний и действиями которая, которые нужно совершить при переходе от одного состояния к другому. Чаще всего представляется графически как ориентированный граф, где узлы — определенные действия (activity), а связи — условия переходов (transitions). Иногда используется обратная схема, где узлы — это устойчивые состояния, а связи — действия для перехода от одного состояния к другому. Можно обойтись вообще без графа, создав матрицу состояний. Можно использовать декларативный язык, что делают различные Rule Engines.
Технически Workflow Engine обеспечивает выполнение конечного автомата (процесса). Одно важное отличие от обычной программы это то, что workflow как правило ориентирован НА ДЛИТЕЛЬНОЕ выполнение БОЛЬШОГО числа процессов, когда основное время процесс находится в состоянии ожидания внешнего события. Для этого Workflow Engine умеет сохранять состояние процесса и восстанавливать при необходимости. Таким образом основа любого Workflow — это асинхронное выполнение.
Чаще всего Workflow используется для организации работы персонала в компании, а также его взаимодействия для решения типовой для компании задачи (бизнес процессы). Бизнес процесс — это своего рода конвейер. Для этого Workflow предоставляет интерфейс пользователя для решения типовой задачи (формочка), а также специфический тип узлов, называемый human task.
Для описания процессов были созданы стандарты BPEL, BPMN и другие. Для связи Workflow с другими системами в расово верных системах используют стандарты SOA и соответственно WebServices для описания интерфейсов. Основная идея, чтобы дяденька-бизнесаналист мог мышкой думать как у него будут работать люди, а индийский программист потом вместо фигаринья быдлокода, также мышкой подцеплял сервисы и делал меппинг данных. Реально же от такого «содрудничества» нанимают еще штат обезьян, чтобы на продакшне решали проблемы и ставили подпорки.
Система не развалится. Развалятся ваши 50 интеграционных тестов и некоторые из 3000 юнитов. Не потому что плохо запрограммировано, а наоборот, потому что функционал изменился, и тесты нужно пересматривать.
Чем больше тестов в эволюционирующей системе, тем бОльшая часть времени тратится на их поддержку.
> Решение свое власти объяснили тем фактом, что Microsoft Office Live является более безопасным «облачным» офисным пакетом, чем решения других компаний. Понятно, что в Google не согласились с такой формулировкой, и ринулись доказывать обратное.
И это вполне может оказаться так. МВД США рассматривают безопастость не только и даже не столько в техническом смысле. Судя по некоторым заявлением Google не отличается большой лояльностью к правительству США и считает себя транснациональной корпорацией. Диктует свои условия, нарушает интересы многих важных дядей, грозилась перевести офисы из штатов в другие страны, вывезти сервера в море и т.д. Национальная безопасность негодуе!
А у меня вопрос: почему до сих пор ни в Rhytmbox ни в Banshee не сделали эквалайзер? По-моему для плеера это принципиальная вещь. Есть только Amarok и Exile.
Хехе, секретные API. Гослинг хитрит, и мы это знаем! ))
Не секретные API мешают нормальному портированию сановской джавы. И никакое не «сглаживание». Нет проблем имплементировать Graphics2D rendering pipe стандартными средствами MacOS X. Кроме того уже давно есть почти допиленный OpenGL rendering pipe, который будет работать на маке.
А вот что мешает портировать Java на Mac, так это создать маковский look-and-feel для свинга. «Секретные API» — это не что иное как метод отрисовки нативных виджетов, который остается за кадром. Если в Windows XP/Vista/7 Java научилась вытаскивать битмапы для кнопочек из ресурсов ОС, то для мака это, видимо, не так просто (если вообще возможно). А на джаву с неродными виджетами пользователи маков будут смотреть как на дерьмо.
Гослинг обходит стороной факт, что его идея мимикрии виджетов под нативные была изначально провальной. Она потребовала кучу сил и ресурсов, а в итоге принесла только проблемы. AWT должен был развиться до SWT и использовать нативные виджеты платформы в апликациях, а Swing должен быть light-weight библиотечкой, ориентируемой исключительно на веб.
С одной стороны, печальное известие. С другой, Apple давно уже упрекают в том, что они заморозили развитие jvm (1.6 вышла на год позже виндовой и линуксовой версий).
Портировать саму core-jvm достаточно просто. Основаная сложность — графика. У Mac OS свое графическое ядро, поэтому придется писать новый rendering pipe, а это задача не из простых (сколько времени они писали быстрый XRender pipeline). Впринципе, java умеет работать через универсальный OpenGL rendering pipe, но до сих пор вроде бы это экспериментальная фича.
Так или иначе, пока выйдет официальная версия для мака, пройдет еще куча времени.
В своем проекте я использовал GWT Comet. В итоге не придется адаптировать логику на сервере и на клиенте под каждый тип коннекшна.
Один реализуется поверх другого. Отличие примерно такое же как между JavaScript и JQuery. Но цель у них одна — дуплексный обмен данными в реальном времени. Использовать голый TCP в окружении браузера проблематично — это не юникс, и с тредами здесь проблемы. Поэтому добавили асинхронный JavaScript API для пакетного обмена.
Основная идея — прикинуться обычным http-запросом и как бы обойти корпоративные файрволы, для того, чтобы чатиться на фейсбуке или в gtalk-е. Реально же файрволы попросту обрежут непонятые хидеры и все.
«Вязкость» же интерфейса получается от того, что ленивые студенты обрабатывают потенциально долгое действие (например запись на диск или поиск в БД) синхронно, то есть в том же треде, где происходит отрисовка и обработка событий. В результате гуй «висит» пока не выполнится действие. Вот веб-программисты уже изначально надрючены писать асинхронные обработчики, ибо сам браузер и платформа обязуют.
Java — это отдельный случай. Там вся отрисовка виджетов сделана программно с мимикрией под платформу. Все это тормозило до последней ветки (1.6 u10), где прикрутили полное аппаратное ускорение через DirectX. Хотя например в Eclipse сделана своя библиотека с байндингом в native-виджеты, поэтому у него свегда был интерфейс. Несколько лет юзаю eclipse, скоростью работы доволен. Да и нынешние Netbeans и Idea имеют более чем адекватный отклик для своего уровня сложности (юзеры Linux отсасывают, особенно с OpenJDK. Там до сих пор рендеринг сделан через тормозной X-api, хотя уже давно обещаны XRender и OpenGL).
Проблема в тормознутости низлежащих библиотек, в частности X Window с его левыми экстеншнами и рудиментарной уже ориентацией на сетевую архитектуру. Сейчас есть попытки заменить иксы на новый Wayland, даже Убунту заикнулись, что в 11.04 они сделают эту замену. Но что-то плохо верится — слишком радикально.
Плохо то, что все нововведения в джаве смотрятся как пятое колесо, без единой идеи и унифицированного синтаксиса. Просто как взяли отдельную фичу из груви и засандалили в язык. По этой причине мне больше нравится Scala.
Идея рецепта — максимально приблизить то состояние, в котором была максимальная работоспособность. Помогает следующее:
1. Ведите свой блог. Записывайте все мысли и ключевые идеи, которые возникли при реализации, даже если тогда они кажутся очевидными. Несмотря на то, что его будете читать только Вы, делайте это так, как-будто объясняете другому человеку. Чтение последних постов в блоге в понедельник поможет «загрузиться» и освежить кеш. Пишите «для себя», т.е. максимально просто, без цензуры и корректировки.
Раньше я вел обычную тетрадь, потому что было удобно рисовать схемки. Теперь я веду дневник в электронном формате, а рисунки часть рисую на бумаге, фотографирую и вставляю в пост.
2. Комментируйте код. Не бойтесь, если текст коментариев будет превышать сам код. Важно: несработавшую идею или ошибочную идею не удаляйте из кода, а закоменьте и пометьте записью почему она ошибочна, дабы потом не наступать на эти же грабли второй раз.
3. Создайте планировщик, в который будете добавлять задачи, которые требуется сделать. У меня это обычный файл, ибо меня напрягают трекеры типа Redmine и Jira. Разбейте задачи иерархически, например по модулям, и сортируйте их по приоритету. Если Вы заняты одной задачей и стало необходимо изменить что-то в другом модуле, не перепрыгивайте, а просто добавьте задачу.
Планировщик поможет быстро вспомнить что еще нужно делать, пока вы на пике, а также всегда наглядно представляет весь объем работ.
4. Самое важное правило девелопера: НЕ ПЫТАЙТЕСЬ СДЕЛАТЬ ВСЕ И СРАЗУ. Запал кончится быстро, а результат еще в конце тунеля — опускаются руки. Как правило актуально для новых проектов. Выпуск верси 1.0 — аццкий труд. Разбейте прокет на фазы так, чтобы в конце каждой фазы у вас всегда что-то запускалось.
Что мне было нужно, так это бандлить процессы в отдельные OSGI-модули, имеющие свой цикл жизни и поддерживающие нативно версионность. Для этого необходимо было иметь jBPM, запакованный в OSGI-модуль с API доступным на уровне OSGI-сервисов. Тем не менее, прототип был состряпан и даже вроде работал. Однако начальство сделало ошибочную ставну на Websphere.
Хорошо, что есть автоматические конвертеры BPMN в BPEL, а то в нашем проекте все делается вручную: аналисты используют Tibco Studio BPMN, а программисты переписывают BPEL на WebSphere. Однако схема конвертации BPMN в BPEL обладает одним существенным недостатком: зачастую администратор хочет видеть наглядно что произошло с его процессом и где он в данный момент находится. А машинно-сгенерированный BPEL будет сильно отличаться от модели процесса.
Прошу прощения, где это родная интеграция со спрингом в jBPM 4? По-моему на офсайте лежит ссылка на левый мануал от одного чувака, который смог прикрутить jbpm к спрингу, и то версии 2.5. Нормального бандла для 3.0 до сих пор не существует в природе (оно и понятно). В свое время это меня остановило.
jBPM убил jPDL и ужасный плагин для начертания процессов. Работать неудобно и отвратно. Нужно раньше было смотреть в сторону BPMN (BPEL изначально был мертворожденный), хотя бы тулзы сторонних разработчиков можно было бы использовать. Сам по себе движок JBPM неплохой, достаточно простой и расширяемый. Но в Activi есть все, что так не хватало — интергация со спрингом, BPMN 2.0 и неплохой дизайнер процессов.
Технически Workflow Engine обеспечивает выполнение конечного автомата (процесса). Одно важное отличие от обычной программы это то, что workflow как правило ориентирован НА ДЛИТЕЛЬНОЕ выполнение БОЛЬШОГО числа процессов, когда основное время процесс находится в состоянии ожидания внешнего события. Для этого Workflow Engine умеет сохранять состояние процесса и восстанавливать при необходимости. Таким образом основа любого Workflow — это асинхронное выполнение.
Чаще всего Workflow используется для организации работы персонала в компании, а также его взаимодействия для решения типовой для компании задачи (бизнес процессы). Бизнес процесс — это своего рода конвейер. Для этого Workflow предоставляет интерфейс пользователя для решения типовой задачи (формочка), а также специфический тип узлов, называемый human task.
Для описания процессов были созданы стандарты BPEL, BPMN и другие. Для связи Workflow с другими системами в расово верных системах используют стандарты SOA и соответственно WebServices для описания интерфейсов. Основная идея, чтобы дяденька-бизнесаналист мог мышкой думать как у него будут работать люди, а индийский программист потом вместо фигаринья быдлокода, также мышкой подцеплял сервисы и делал меппинг данных. Реально же от такого «содрудничества» нанимают еще штат обезьян, чтобы на продакшне решали проблемы и ставили подпорки.
Чем больше тестов в эволюционирующей системе, тем бОльшая часть времени тратится на их поддержку.
И это вполне может оказаться так. МВД США рассматривают безопастость не только и даже не столько в техническом смысле. Судя по некоторым заявлением Google не отличается большой лояльностью к правительству США и считает себя транснациональной корпорацией. Диктует свои условия, нарушает интересы многих важных дядей, грозилась перевести офисы из штатов в другие страны, вывезти сервера в море и т.д. Национальная безопасность негодуе!
Не секретные API мешают нормальному портированию сановской джавы. И никакое не «сглаживание». Нет проблем имплементировать Graphics2D rendering pipe стандартными средствами MacOS X. Кроме того уже давно есть почти допиленный OpenGL rendering pipe, который будет работать на маке.
А вот что мешает портировать Java на Mac, так это создать маковский look-and-feel для свинга. «Секретные API» — это не что иное как метод отрисовки нативных виджетов, который остается за кадром. Если в Windows XP/Vista/7 Java научилась вытаскивать битмапы для кнопочек из ресурсов ОС, то для мака это, видимо, не так просто (если вообще возможно). А на джаву с неродными виджетами пользователи маков будут смотреть как на дерьмо.
Гослинг обходит стороной факт, что его идея мимикрии виджетов под нативные была изначально провальной. Она потребовала кучу сил и ресурсов, а в итоге принесла только проблемы. AWT должен был развиться до SWT и использовать нативные виджеты платформы в апликациях, а Swing должен быть light-weight библиотечкой, ориентируемой исключительно на веб.
Портировать саму core-jvm достаточно просто. Основаная сложность — графика. У Mac OS свое графическое ядро, поэтому придется писать новый rendering pipe, а это задача не из простых (сколько времени они писали быстрый XRender pipeline). Впринципе, java умеет работать через универсальный OpenGL rendering pipe, но до сих пор вроде бы это экспериментальная фича.
Так или иначе, пока выйдет официальная версия для мака, пройдет еще куча времени.