Исходники

Какое бы заключение мы не обрели в сторону такого либо иного дизайна кухни, хоть какой человек стремится изготовить её очень удобной, комфортной и, естественно, ведь модной. О том, какие в…

JiBX — это инструмент для установления соответствия между данными XML и объектами Java. JiBX давно известен как самый быстрый и гибкий способ установления соответствия между кодом Java и XML. Однако сложность этих определений соответствия и ограниченная поддержка все более широко используемых определений XML-схемы иногда расхолаживали пользователей. К счастью, в версии JiBX 1.2 многое сделано для решения этих проблем. Из этого руководства вы узнаете об использовании новых функций JiBX 1.2 для простой генерации определений XML-схемы из существующего кода Java и чтении и записи XML-документов в соответствии со сгенерированными определениями схемы — и все это без необходимости вдаваться в детали определений соответствия JiBX. Во второй части описан обратный процесс преобразования определений XML-схемы в код Java.

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

Целевая аудитория экзамена SCJP 6 программисты, желающие стать Certified Java Programmer (сертифицированными JAVA программистами). Экзамен SCJP 6 содержит вопросы проверяющие фундаментальные знания, для сдачи сертификационного экзамена Java от компании Sun.

Стать сертифицированным программистом может каждый. Экзамен SCJP показатель профессионализма в данном направлении, кто-то сдает исключительно для расширения своих знаний, кто-то идет на экзамен, потому что сертификат — обязательное требование работодателя. Главная цель SCJP сертификация фундаментальных знаний, опыта и умений каждого в области программирования на Java и Java платформы в целом. Для получения сертификата необходимо успешно сдать экзамен и для допуска к нему не обязательно наличие статуса Sun Certified Java Associate.

Несмотря на то, что в мире Java имеется много Web-инфраструктур, все они, прямо или косвенно, основаны на инфраструктуре Java Servlets. Java Servlets API предоставляет набор полезных возможностей, включая управление состоянием с помощью объектов HttpSession и ServletContext, которые позволяют приложению сохранять данные на протяжении нескольких запросов от пользователя. Однако для Web-приложений существует ряд тонких (и по большей части недокументированных) правил, регулирующих работу с совместно используемыми объектами, из-за которых во многих приложениях появляются трудноуловимые ошибки. В результате во многих Web-приложениях, хранящих свое состояние в сеансе пользователя, возникают запутанные ситуации и проблемы.

Я горячий сторонник принципа разработки программного обеспечения через тестирование (test-driven development – TDD). Нил Форд (Neal Ford, автор книги «The Productive Programmer»), утверждает, что «написание непротестированного кода является примером профессиональной безответственности» (см. раздел Ресурсы). Майкл Физерс (Michael Feathers, автор книги «Working Effectively with Legacy Code»), определяет устаревший код (legacy code) как любой код, для которого не существует тестов. Из этого следует, что написание кода без тестов является старомодной практикой. Лично я не устаю утверждать, что любой проект должен содержать две строки тестового кода на каждую строку кода, который будет отправлен в эксплуатацию.

В статьях серии Изучение Grails пока не затрагивалась тема TDD, поскольку основное внимание уделялось способам использования базовой функциональности Grails. В тестировании кода инфраструктуры (т.е. кода, написанного не вами) также есть определенные преимущества, но на практике мне редко приходится этим заниматься. Я уверен, что Grails корректно сериализует мои объекты POGO в XML, а также сохранит объект Trip в базе данных при вызове trip.save(). В основном необходимость в тестировании возникает при проверке работоспособности вашего собственного кода. При реализации сложного алгоритма необходимо создать один или несколько юнит-тестов, чтобы гарантировать, что алгоритм работает именно так, как от него требуется. В этой статье рассказывается о том, какие средства предоставляет Grails для создания тестового кода для ваших приложений.

Реляционные СУБД занимают лидирующие позиции уже более 30 лет, однако эта ситуация может измениться в связи с растущей популярностью баз данных, не имеющих реляционных схем данных (или баз данных типа NoSQL). РСУБД предоставляют надежные средства хранения данных в системах с традиционной клиент-серверной архитектурой, которые, к сожалению, не всегда легко и дешево масштабируются путем добавления новых вычислительных узлов. Это становится весьма серьезным ограничением в эпоху таких Web-приложений, как Facebook и Twitter, которым хорошая масштабируемость крайне необходима.

Проблему масштабируемости не удалось решить ранним альтернативам реляционных СУБД (помните объектно-ориентированные базы данных?). В отличие от них СУБД NoSQL, подобные Bigtable и SimpleDB (от Google и Amazon соответственно), проектировались именно в расчете на высокую масштабируемость Web-приложений. NoSQL вполне могут оказаться решением критически важной проблемы масштабируемости, которая будет становиться все более актуальной по мере развития Web 2.0.

В этой статье серии Вторая волна разработки Java-приложений приводится введение в проектирование баз данных без использования схем, что представляет собой одну из главных трудностей при переходе на NoSQL для разработчиков, ранее работавших с реляционными СУБД. Вы увидите, что самое главное в этом процессе – начать проектирование с создания модели предметной области, а не реляционной модели. При работе с Bigtable (как в примерах ниже) вы можете рассчитывать на помощь Gaelyk – легковесной инфраструктуры, расширяющей возможности платформы Google App Engine.