JUG.ua

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

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

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

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

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

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

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

ibm_dw программирование AIX, восстановление системы

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

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

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

ibm_dw программирование Data Studio, Java, pureQuery

Язык XML Schema получил широкое распространение в самых разных задачах, что, в частности, привело к большому числу запросов на тему новых возможностей. Наиболее популярные из них были реализованы в новом стандарте XML Schema 1.1, разработанном рабочей группой в W3C. В новой версии языка также устранены некоторые недостатки XML Schema 1.0. В этой статье – первой части серии – авторы Нил Делима, Сэнди Гао, Майкл Главассевич и Халед Ноумен познакомят вас с XML Schema 1.1, кратко рассмотрев возможности, появившиеся в этой версии, а также уделив особое внимание изменениям в спецификации, которые коснулись типов данных.

Достоинства и недостатки XML Schema обсуждаются с 2001 года, когда этот язык стал официальной рекомендацией W3C. После этого рабочая группа W3C начала работать над следующей версией XML Schema. В 2005 году, после того как он получил широкое распространение и был интегрирован с другими стандартизованными языками, в частности XSLT, XQuery и WSDL, W3С организовала специальный семинар для обсуждения стандарта и получения достаточного числа отзывов от пользователей, которые должны были определить путь его дальнейшей эволюции. Благодаря этому семинару, а также другим запросам, сформулированным представителями XML-сообщества, был определен круг возможностей XML Schema 1.1.

В этой статье будет приведен обзор некоторых новинок XML Schema 1.1, а затем будут подробно рассмотрены расширения спецификации, касающиеся типов данных. На сегодняшний день стандарт известен под официальным названием “Язык определения XML-схем” (XML Schema Definition Language). В этой и последующих статьях серии мы будем чаще использовать аббревиатуру XSD, хотя в некоторых случаях вам могут встретиться “XML Schema” или просто “схема”, которые обозначают тот же самый язык.

Имейте в виду, что на момент написания этой статьи работа над XML Schema 1.1 еще не была завершена, поэтому некоторые детали могут измениться до выпуска официальной рекомендации W3C.

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

ibm_dw документация Schema, xml

Планирование и реализация Web-сайтов всегда сопровождается большими затратами усилий. Django представляет собой один из лучших на сегодняшний день фреймворков, который позволяет быстро вести разработку высокопроизводительных и полнофункциональных сайтов. С помощью django легко выстаиваются масштабируемые и легко расширяемые приложения для Web с дизайном любой степени сложности.

Абстрагируясь от низкоуровневого процесса Web-строительства, django позволяет разработчикам быстро создавать основанные на базах данных динамичные Web-сайты. Одним из основных преимуществ django является переносимость созданных на ее основе продуктов в силу переносимости их базиса – языка высокого уровня Python.

Произносится слово django мягко, без выраженного звука «д», как «жан-го».

Django включает в себя Model View Controller (MVC) – инструмент, позволяющий разделить общую архитектуру на отдельные части. При этом управляющая логика разделена на три отдельных компонента так, что модификация одного из них оказывает минимальное воздействие на другие части. К таким компонентам относят разделяемые данные, логику и слои визуализации (view layers). В общем случае такая концепция позволяет разделить разработку информационного наполнения на уровне базы данных и разработку Web-страниц.

Django базируется на классе Python django.db.models.Model, который задает данные модели так, чтобы они были пригодны к использованию на Web-сайтах. Эти данные определяются соответствующими атрибутами объектов, которые сохраняются в базе данных в процессе работы. При создании сайта создается подкласс класса Model и добавляется поле членов в класс для задания специфических данных.

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

Изменение отображения содержимого в зависимости от принимаемого URL-запроса является многоступенчатым процессом. Когда django-сервер получает URL-запрос, он парсит его и, используя предыдущие установки шаблонов, определяет, какой участок кода Python будет выполняться для требуемого отображения.

Парсер шаблонов в django позволяет самостоятельно настраивать свои шаблоны, которые используют функции отображения Web-страниц при построении ответа на URL-запросы. Это позволяет разработчикам Python сфокусироваться на создании данных, которые будут отображаться, а программистам HTML – сфокусироваться на дизайне Web-страниц.

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

ibm_dw документация django, сайт, фремворк, web

В этой статье рассказывается о популярной 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 Россия

ibm_dw программирование Joomla!, Mambo, XAMPP

В некоторых случаях при пересылке документов 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_dw программирование SAX, xml, XNI

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

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

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

ibm_dw программирование AIX, OpenSSH

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

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

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

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

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

ibm_dw программирование информационные технологии

Организаторы мероприятия – инициативная группа coffee’n'code – приглашает всех заинтересованных принять участие в мероприятии Ruby Shift 2010.

Возможности, открываемые Ruby Shift

• Поддержка Украинского Ruby Community
• Новые знакомства в IT
• Обмен опытом
• Новые идеи, неформальное общение с коллегами Read more…

admin анонс

Многие 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 Россия

ibm_dw программирование xml, XQuery