JUG.ua

Комбинирование JavaScript с кодом Java™ на сервере позволяет свободно использовать одни и те же программы JavaScript как в серверных, так и в клиентских системах. Кроме того, методы, представленные в этой серии статей, позволяют работать с одной и той же базой кода как на Ajax-, так и на не-Ajax клиентских системах. Так как большая часть кода для сервера все равно пишется на языке Java, функции Java Platform, Enterprise Edition (Java EE) желательно сделать доступными для JavaScript. В этих статьях показано, как исполнять файлы JavaScript со стороны сервера, вызывать функции JavaScript с помощью Ajax и использовать API Java Scripting с технологией JavaServer Pages (JSP).

На стороне клиента типичные приложения Ajax используют JavaScript, а на стороне сервера — другие языки, такие как Java. В результате разработчикам приходится создавать некоторые программы дважды, используя для Web-браузера JavaScript, а для сервера другой язык. Этой двойной работы можно избежать, воспользовавшись на стороне сервера языком JavaScript в сочетании с Java, чтобы получить полную поддержку языков сценариев через API javax.script. К тому же Java SE Development Kit (JDK) 6 уже содержит механизм JavaScript Rhino от Mozilla, поэтому дополнительно устанавливать ничего не нужно.

В этой первой статье данной серии мы воспользуемся простым сценарием, который позволяет исполнять файлы JavaScript внутри приложений Java ЕЕ. Сценарии будут иметь доступ к так называемым “неявным объектам” (implicit objects), которые используются в страницах JSP, таким как application, session, request и response. Большинство примеров состоит из многократно используемого кода, так что вам будет легко перейти к применению JavaScript на сервере в своих собственных приложениях.

Подробнее на IBM developerWorks Россия

nanoHUB — это виртуальный вычислительный центр, созданный для поддержки исследований в области нанотехнологий. Он использует компоненты с открытым исходным кодом для получения гораздо более впечатляющих результатов, чем используемые ранее средства удалённого доступа. Эта статья подробно описывает частные настройки и усовершенствования, необходимые для получения максимальной производительности, безопасности и удобства в использовании от применения такого известного программного обеспечения, как VNC и WebDAV.

nanoHUB.org использует уникальную систему ПО Middleware, в которой обеспечен точный баланс безопасности, производительности и гибкости для поддержки распределённых публичных исследований в области нанотехнологий. Учёные, которые используют этот «исследовательский шлюз», могут больше внимания уделять своим исследованиям, а не вычислительным задачам.

Между тем, помимо явных важных преимуществ, nanoHUB дает представление о том, как можно настроить и улучшить хорошо известные в мире открытого ПО программы для значительного расширения возможности виртуальных вычислений. Говоря об этом проекте, Суприйо Датта, директор института наноэлектроники вычислений NASA/Purdue, подчеркнул: “Приложив совсем немного усилий, мы сделали наши инструменты моделирования доступными для наших коллег. Теперь наши коллеги могут легко запускать программу молекулярного электронного моделирования”. Как видно из рисунка 1, nanoHUB приятно сочетает в себе простоту использования для учёных, которые публикуют с его помощью свои работы, и для их коллег, которые знакомятся с этими публикациями.

Источник IBM developerWorks Россия

Для успешного восстановления IT-ресурсов после сбоя в AIX-системах персонал должен все усилия направить на тщательную подготовку плана действий в случае нештатных ситуаций, поскольку ошибки в этом плане могут сорвать аварийное восстановление. Часто такие ошибки являются следствием недостаточно строгого соблюдения стратегии непрерывности бизнеса, руководящих принципов, стандартов и процедур. Эта статья посвящена типичным конфликтам ресурсов, происходящим во время выполнения аварийного восстановления и предлагает способы разрешения этих конфликтов.

При осуществлении аварийного восстановления крайне нежелательны неожиданные аппаратные и программные конфликты ресурсов, отнимающие время, людские ресурсы и приводящие к невыполнению ранее намеченных задач. Целью этой статьи является определение наиболее общих причин конфликтов ресурсов и механизмов их предотвращения или разрешения. Наиболее приемлемое решение — избегать таких конфликтов в целом, чтобы не потребовалось их разрешать во время аварийного восстановления.

Многие IT-отделы пытаются поддерживать многочисленные стандарты реализации, одни — для кластерных систем, другие — для систем, не объединённых в кластер, третьи — для катастрофоустойчивых систем. Поддержка многочисленных стандартов сама по себе может быть источником и причиной конфликтов во время выполнения аварийного восстановления. Объединение множества стандартов в единый стандарт должно стать целью планирования проекта аварийного восстановления и общей стратегией непрерывности бизнеса.

Можно выделить несколько типичных проблем, возникающих во время аварийного восстановления систем AIX:

* Резервные системы по своим характеристикам (тип, число процессоров и емкость) отличаются от продукционных систем; обычно это более новые системы с обновленными ОС
* Проблемы прав доступа пользователей и групп
* Множество экземпляров одного приложения (каждое приложение развертывается на отдельной продукционной системе, но в резервной системе может быть установлено несколько приложений)
* Проблемы с сетевыми именами и проблемы адресации
* Продукционные приложения (привязанные к конкретному сетевому адресу или сетевому имени во время установки)
* Конфликты между именами узлов и именами хостов в сети (конфликты между системами, установленными в ЦОДе, и новыми системами, которые запускаются при аварии)
* Многочисленные стандарты реализации для разной функциональности (автономность, отказоустойчивость и восстановление после катастроф)

Конфликты ресурсов и их решения, обсуждаемые здесь, предполагают, что в организации имеется множество ЦОДов, на которых запущены продукционные системы, и каждый ЦОД является резервным для одного или нескольких других ЦОДов. Информация, представленная здесь, применима к любым ЦОДам и планам аварийного восстановления.

Подробнее на IBM developerWorks Россия

pureQuery – это высокопроизводительная Java™-платформа для доступа к данным, предназначенная для упрощения решения задач по разработке, управлению и оптимизации приложений и служб, которые обращаются к данным. Она состоит из инструментальных средств, API и среды исполнения. В предыдущих статьях этой серии были представлены два стиля программирования, которые помогают обращаться к базе данных посредством простых, но мощных API. В этой статье приводятся некоторые практические рекомендации по разработке с применением API pureQuery и содержатся реальные сценарии, демонстрирующие, как пользоваться этими рекомендациями.

Первые две статьи данной серии содержали подробное описание двух стилей API, предлагаемых IBM pureQuery: на основе встроенных методов и на основе аннотированных методов. В третьей статье мы рассмотрим разнообразные практические приемы разработки с использованием API pureQuery. В большинстве этих приемов применяются сложные функции API pureQuery. По возможности, для иллюстрации использования описываемых функций приводятся примеры из реальной жизни. Фрагменты кода включены исключительно в демонстрационных целях, но должны дать вам представление о том, как использовать API.

Источник IBM developerWorks Россия

В этой статье рассказывается о популярной CMS Joomla! и ее аналоге Mambo, о том, как ими пользоваться и как с их помощью можно строить и управлять динамичными Web-сайтами.

Во второй части цикла будет рассмотрена тема, посвященная основам создания собственных шаблонов для сайта на базе Joomla!

Ни у кого не возникает сомнений в том, что на сегодняшний день наличие CMS (Content Menagement System) является стандартом «де-факто» для любого более или менее крупного сайта, точнее, специалиста, его обслуживающего. Вопросы организации «сайтостроения», размещения контента, управления пользователями и их привилегиями – вот далеко не полный перечень всего того, что можно выполнять с помощью CMS.

На сегодняшний день одно из лидирующих мест в мире занимает совершенно бесплатная CMS Joomla!. Она является зрелым продуктом с очень широкими возможностями, и очень многие организации и предприятия отдают предпочтение этому продукту с открытыми исходными текстами. Одно из основных ее преимуществ – это гибкость, что и подтверждает то многообразие организаций, которые построили свои сайты на ее основе. Joomla! позволяет быстро развертывать такие сайты, как корпоративные, школьные и университетские, электронной коммерции и малого бизнеса, сайты общественных и правительственных организаций, – и это далеко не весь перечень возможностей этой удивительно производительной CMS.

При этом следует обратить внимание на то, что пользование Joomla! на базовом уровне не требует знаний ни PHP, ни CSS, ни javascript, хотя владение этими технологиями никогда не будет излишним для разработчика сайтов.

Вот краткий перечень возможностей Joomla!.

1. Простота создания содержимого с помощью текстового редактора, доступного в открытой и закрытой части сайта.
2. Регистрация пользователей и ограничение доступа к страницам в соответствии с их правами.
3. Контроль за редактированием и публикацией содержимого.
4. Голосования.
5. Создание контактных форм.
6. Статистики сайта.
7. Подключение механизмов поиска по сайту.
8. Возможность распечатать или отправить статью в формате PDF по электронной почте.
9. Подключение каналов RSS.
10. Наличие возможности отображать ленты новостей с других сайтов.

В настоящее время очень сложно найти какой либо сайт, сделанный на Joomla!, который не пользовался бы функциональной расширяемостью за счет подключения дополнительных расширений – модулей. В наиболее общем смысле под словом модули имеется в виду компоненты, разного рода дополнения и языки программирования. Сейчас существуют сотни таких расширений, распространяемых коммерческим путем или созданных для свободного использования. И те, и другие имеют свои положительные и отрицательные стороны и могут применяться в зависимости от ваших потребностей и вкусов.

Источник IBM developerWorks Россия

В некоторых случаях при пересылке документов XML достаточно просто передать массив байтов из точки А в точку Б. При этом необязательно разбирать содержимое документа, однако следует определить его кодировку, чтобы правильно задать метаданные. Эффективным средством достижения этой цели являются потоковые API, такие как SAX и XNI, которые позволяют проанализировать кодировку, проигнорировав остальное содержимое.

В спецификации XML используется Unicode, однако при передаче и хранении в памяти компьютеров символы представляются в виде байтов, анализируемых XML-процессорами (парсерами). Для этого существует ряд различных схем кодировки: UTF-8, UTF-16, ISO-8859-1, Cp1252, SJIS и многих других.

Как правило, но не всегда, можно не заботиться о том, какая кодировка используется, поскольку парсер автоматически преобразует содержимое документа в массивы строк и символов Unicode. В этой статье рассматриваются реже встречающиеся случаи, в которых особенности кодировки необходимо учитывать.

* Чаще всего это происходит, если требуется сохранить исходную кодировку документа.
* Другим примером может служить сохранение документа в базе данных в виде строки или крупного символьного объекта (Character Large Object – CLOB) без предварительного разбора.
* Некоторые приложения пересылают документы XML по протоколу HTTP, не анализируя их. Тем не менее при этом необходимо задать правильный тип содержимого в заголовке HTTP, поэтому приходится определять тип кодировки.

Чаще всего вы и так знаете кодировку документа, поскольку сами же его создали. Однако если вы просто получили документ из некоего источника (например, обратившись к ленте Atom), то для определения кодировки лучше всего использовать потоковые API, такие как простой API для XML (SAX), потоковый API для XML (StAX), либо собственный интерфейс Xerces (XNI). Разумеется, можно воспользоваться и интерфейсами, строящими представление документа в виде дерева, например DOM (объектная модель документа), но не забывайте, что они будут считывать в память все содержимое документа, даже если для определения кодировки достаточно просмотреть первые 100 байтов. В отличие от них потоковые API прочитают ровно столько, сколько необходимо, и вернут результат сразу после того как он получен. Это значительно более эффективный способ.

Источник: http://www.ibm.com/developerworks/ru/library/x-tipsaxxni/index.html?S_TACT=105AGX99&S_CMP=GR01

Эта статья написана для администраторов систем IBM RS/6000, которые хотят улучшить безопасность своих серверов, работающих под управлением AIX, заменив стандартные незащищенные сетевые службы на службы, предоставляемые реализацией OpenSSH протокола Secure Shell.

В этой статье не рассматриваются подробно основы сетевой безопасности или использование клиентского ПО SSH. Основная цель этого курса – подробно описать необходимые компоненты, действия и конфигурации, необходимые для компиляции OpenSSH, и детально рассмотреть необходимые условия для установки OpenSSH на AIX-системы.

Подробнее на IBM developerWorks Россия

В этой статье идет речь о том, как консультант по программному обеспечению может использовать объективный измеримый метод в процессе совершенствования организационной культуры предприятия. Анализируя ряд факторов, включая мотивацию, стратегическое согласование позиций и открытость, автор показывает, как можно добиться позитивных изменений.

В роли кураторов нам часто приходится рассказывать о том, из каких элементов состоит изменение процесса. Некоторые специалисты утверждают, что в основе мотивации к постоянному совершенствованию процесса лежит знание объективных показателей бизнеса. Но зачастую трудно получить представление о перерасходах средств и нарушениях сроков, производительности и эффективности продуктов на предприятии клиента; эти сведения обычно чуть более конфиденциальные, чем те, которыми клиенты с готовностью поделятся с вами. Кроме того, всестороннее обсуждение этой информации само по себе вряд ли вдохновит клиента на внедрение изменения.

Другие считают, что убедить клиента согласиться на внедрение усовершенствований процесса – это искусство, точно так же, как и любое руководство, стимулирующее человека изменить свое поведение, требует своего рода артистизма. Как, например, можно сформировать у человека мотивацию к какой-либо деятельности?

.Хорошо продуманный подход должен не только сформировать, но и поддерживать такую мотивацию. Далее я поделюсь своими мыслями по поводу того, как лучше сочетать это искусство и науку убеждения, чтобы процесс на самом деле превратился в процесс внедрения.

Источник: http://www.ibm.com/developerworks/ru/library/r-spencer/index.html?S_TACT=105AGX99&S_CMP=GR01

Многие Web-приложения используют схему “модель-отображение-контроллер” (Model-View-Controller – MVC), чтобы разделить эти три задачи. На уровне представления такие приложения часто используют технологию PHP или JavaServer™ Pages (JSP). Хотя эти технологии широко применяются и безусловно эффективны, они не дают не зависящего от языка средства представления данных. В противоположность этому, язык XQuery, подобно языку Structured Query Language (SQL), предоставляет спецификацию преобразования, связанную со стандартом XML и не зависящую от языка и платформы. Использование XQuery для представления данных позволяет разработчикам, которые занимаются отображением данных, создавать эффективные представления данных, не привязанные к нижележащим серверам приложений или языкам программирования. В этой статье детально рассматриваются преимущества использования XQuery перед другими технологиями отображения данных, способ реализации XQuery на уровне представления и жизненный пример такой реализации.

Преимущества использования XQuery для представления данных

Сегодня почти все сообщество Web-разработчиков понимает преимущества подхода MVC. Этот подход отделяет модель (информационное содержание) от представления (того, что пользователь видит на экране) и от контроллера (того, что происходит в ответ на действия пользователя или обращения браузера по URL)

Большинство разработчиков, выбирая тот или иной вариант подхода MVC, обычно предпочитают технологию Java Platform, Enterprise Edition 5 (Java EE). Это безусловно эффективное решение, так как язык программирования Java представляет собой самую современную технологию. Кроме того, такие популярные структуры, как Spring и Struts, облегчают реализацию подхода MVC в распределенных объектных приложениях.

Однако непреложный закон разработки программного обеспечения гласит, что лучшие подходы постоянно развиваются. В противном случае Twitter был бы написан на языке Pascal. Стандарты совершенствуются, и прежние лучшие подходы модернизируются, а иногда и полностью вытесняются новейшими технологиями и решениями. Коротко говоря, несмотря на популярность технологии Java Enterprise, это все же вчерашний день. То же можно сказать и о других реализациях MVC, отличных от языка программирования Java.

Так каков же современный ответ?

XQuery в качестве средства представления, используемый в сочетании с XML для отображения данных – еще лучший способ разделения задач. Этому есть причины, которые я объясню.

Подробнее на IBM developerWorks Россия

В этом году Ciklum приглашает представителей украинских IT-сообществ, а также непартийных докладчиков, поделиться опытом.

Темы мини-barcamp’ов (http://it-jam.ciklum.net/index.php/component/content/article/8) :

• Dynamic Programming Languages
  Ruby on Rails, Python, Perl
• Mobile Development
  iPhone, Android, Blackberry
• Agile
  Scrum, XP, kanban
• RIA
  Flash, Silverlight, Flex
• CMS
  Drupal, EPiServer, Joomla

Другая особенность программы – возможность задать вопросы и узнать мнение представителей ведущих украинских IT-компаний, организованная в виде panel discussions: http://it-jam.ciklum.net/index.php/component/content/article/7 .

В финале мероприятия – неофициальная часть: неформальное общение с коллегами, живая музыка, пиво-закусь :)

Регистрация уже открыта: http://it-jam.ciklum.net/index.php/component/user/register

upd: внимание, новая дата! Мероприятие переносится с 31 октября на 5 декабря.