Файлы внутри скриптов или deploy на bash'е

Одним из интересных свойств bash-скриптов является то, что в них можно запихивать файлы, которые затем сам скрипт будет из себя извлекать при запуске. Таким образом, например, устроены скрипты установки JRE и JDK для Linux. Используя это свойство, можно довольно легко создавать скрипты для автоматизированного развертывания каких-либо систем, библиотек и т.п.. Приведу примеры извлечения текстовых и бинарных данных из bash-скриптов.

Диалог с bash'ем: использование kdesu и kdialog в скриптах

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

В KDE можно легко создавать диалоговые окна в bash-скриптах, используя программу Kdialog. Причем окна могут быть самые разнообразные от обычных yes-no-cancel, до диалогов открытия/сохранения файла и отображения полосы прогресса. Использование продемонстрирую на своем реальном примере.

Создание документа ODF с помощью ODFDOM Simple Java API

Документ ODF, как известно, представляет из себя ZIP-архив, который содержит xml-файлы и различные ресурсы документа, например картинки. Наиболее значимые xml-файлы это content.xml, который содержит по сути весь текст документа и его структуру, и styles.xml, который хранит стили документа.

Элементы файла content.xml, содержащие текст, могут использовать стили, описанные в файле styles.xml, обращаясь к ним по имени. Проще говоря, в элементе файла content.xml указывается имя стиля из styles.xml, которое должно применяться для текста, параграфа и т.п. Стили так же представляют из себя набор XML-элементов.

Изучать стрктуру и все элементы ODF дело скучное да и мало кому, я думаю, нужное. Для того, чтобы работать с форматом ODF на высоком уровне существует библиотека ODFDOM. На самом деле эта библиотека не такая уж и простая, и чтобы ею пользоваться нужно все же понимать устройство ODF и уметь работать с XML при помощи Apache Xerces-J. Но для действительно простой работы с ODF теперь есть надстройка над ODFDOM, которая называется Simple Java API for ODF. Раньше я писал о том, как можно работать с документами ODF из Java-программы используя OpenOffice. Использование библиотеки ODFDOM Simple Java API намного удобнее как с точки зрения написания кода, так и тем, что вам теперь не нужен установленный OpenOffice. Благодаря этой библиотеке вы сами легко можете создавать программы работающие с ODF.

Запуск внешней программы на Java

Удобным средством для запуска внешних программ из java-кода является класс ProcessBuilder. С помощью экземпляра этого класса можно указать программу для запуска, параметры её запуска, переменные окружения, рабочий каталог и включить перенаправление потока вывода ошибок на стандартный вывод.

Ниже приведу простой пример использования ProcessBuilder с комментариями.

Отключение сохранения сессий на freenx-server

Иногда freenx-server любит "терять" сессии, а потом не может их восстановить. Для того, чтобы не загонять в тупик простых пользователей непонятными вопросами от nx-клиента, можно просто запретить сохранение сессий в настройках freenx-server.

В файле настроек сервера node.conf (у меня он лежит в каталоге /etc/nxserver) можно явно установить пустым значение переменной ENABLE_PERSISTENT_SESSION:

ENABLE_PERSISTENT_SESSION=""

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

ENABLE_PERSISTENT_SESSION="all"
DISABLE_PERSISTENT_SESSION="user1,user2"

В этом случае все пользователи, кроме user1 и user2 смогут сохранять сессии.

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

ENABLE_PERSISTENT_SESSION="user1,user2"


Не забудьте перезапустить freenx-server:

# service freenx-server restart 

или

# nxserver --restart

При отключённой возможности сохранения сессии, во время выхода из nx-клиента пользователю не будет предложено разъединиться с сохранением сеанса (disconnect), а просто будет задан вопрос для подтверждения выхода.

Плагин Java и Firefox 3.6 в Linux

Оказывается, что с каких-то пор для того, чтобы прикрутить Java к Firefox 3.6 надо создать символьный линк в каталоге firefox/plugins на файл jdk/jre/lib/i386/libnpjp2.so вместо привычного jdk/jre/plugin/i386/ns7/libjavaplugin_oji.so

Когда чего кто поменял не понятно, но я этот момент упустил из виду и в результате пол дня прокопался прикручивая Java к Firefox...

Переименование сетевых интерфейсов в Linux (настройка UDEV)

Вб современных популярных дистрибутивах Linux имена сетевым интерфейсам присваиваются системой UDEV во время загрузки.

Для переименования интерфейса необходимо подправить файл /etc/udev/rules.d/70-persistent-net.rules

Например, файл 70-persistent-net.rules содержит такие строки:

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:f3:3e:b4", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

По умолчанию привязка имени осуществляется по MAC-адресу сетевой карты.

Меняем параметр NAME="eth0" на NAME="internet":

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:f3:3e:b4", ATTR{type}=="1", KERNEL=="eth*", NAME="internet"

Выполняем из под root'а следующие команды (или перезагружаемся):

Выключить интерфейс:

# ifconfig eth0 down 

Перечитать правила udev:

# udevadm control --reload-rules

Выгрузить драйвер сетевой карты:

# modprobe -r atl1

Загрузить драйвер сетевой карты:

# modprobe atl1

Поднять интерфейс с новым именем:

# ifconfig internet up

Узнать какой драйвер используется для вашей сетевой карты можно командой lspci -k

Всё.

(!) Переименование сетевого интерфейса может понадобиться, если у вас поменялась сетевая карта или вообще жесткий диск с работоспособной системой переставлен в другую машину, в которой, естественно, опять же другая сетевая карта. Т.к. привязка осуществляется по MAC-адресам, то UDEV добавит правило для новой сетевой карты, но если прошлая сетевая карта у вас была под именем eth0, то новой он присвоит имя eth1 и все ваши настройки работать разумеется не будут.

Java и MongoDB вместе

Сегодня стало очень модным использование нереляционных баз данных. Вот и мне захотелось такое подергать. Мой выбор пал на MongoDB просто потому что слышал о этой штуке много положительных отзывов. Для себя сделал эту заметку, что бы потом не пришлось все изучать по второму разу, если ещё кому-нибудь пригодится, то и замечательно.
Всё, что здесь написано, основывается на документации с официального сайта MongoDB и конкретно на разделе посвященному Java, а кое-что и вовсе является просто переводом. Некоторые примеры из документации я немного переделал для более ясной, на мой субъективный взгляд, демонстрации возможностей.

Хитрости Apache Tomcat: Кодировка

При разработке сервлетов, которые на основе запроса от HTML или JSP-страницы генерируют другую страницу, можно натолкнуться на некоторые трудности с кодировкой данных, отправляемых на сервер (request) и получаемых от него (response).

Для определения кодировки данных ответа необходимо использовать метод setCharacterEncoding объекта класса HttpServletResponse. Например, для установки UTF-8:

public class FooServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) 
    throws ServletException, IOException {
        
        response.setCharacterEncoding("UTF-8");
        
        // далее остальной код...
    }
 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
    throws ServletException, IOException {
        doPost (request, response);
    }
}

А вот с кодировкой данных, которые будут отправлены в запросе на сервер есть небольшая хитрость. Казалось бы, если страница сформирована, допустим, в кодировке UTF-8, то и данные запроса должны обрабатываться сервером, как UTF-8. Однако, этого не происходит, потому что в запросе браузер не передает информацию о кодировке данных. Если для отправки данных формы используется метод POST, то все просто - можно точно так же вызвать метод setCharacterEncoding, только для объекта класса HttpServletRequest:

request.setCharacterEncoding("UTF-8");

Проблема возникнет, если для отправки данных формы будет использоваться метод GET. В таком случае request.setCharacterEncoding("UTF-8") уже не сработает и Tomcat будет обрабатывать строку запроса так, как-будто она в кодировке ISO8859-1.

Для решения этой проблемы необходимо подправить конфигурационный файл Apache Tomcat server.xml и в тег Connector добавить параметр useBodyEncodingForURI="true":

<Connector connectionTimeout="20000" 
      port="8081" protocol="HTTP/1.1" 
      redirectPort="8443" useBodyEncodingForURI="true"/>

После этого перезагружаем Tomcat и для метода GET можно будет также использовать request.setCharacterEncoding("UTF-8") для указания кодировки запроса:

public class FooServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) 
    throws ServletException, IOException {
        
        response.setCharacterEncoding("UTF-8"); // кодировка ответа
        request.setCharacterEncoding("UTF-8");  // кодировка запроса; необходимо указать до
                                                // вызова request.getParameter()
        
        // далее остальной код...
        String param1=request.getParameter("param1");  
        String param2=request.getParameter("param2");
      
        // ...
    }
 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
    throws ServletException, IOException {
        doPost (request, response);
    }
}

В том же теге Connector, используя параметр URIEncoding вместо useBodyEncodingForURI, можно явно установить нужную для вас кодировку, например URIEncoding="UTF-8", решайте сами, что для вас удобнее.

Конвертирование физических машин в виртуальные с помощью VMware Converter

На работе у меня был случай, когда появилась необходимость перевести человека, который весьма много времени проработал под Windows XP, на Linux. Windows XP стояла на машине на удивление очень долго без переустановок, была настроена и напичкана различными программами, и человек не хотел с ней расставаться окончательно, ему необходимо было иногда одновременно работать в двух системах. Естественно, единственный нормальный выход тут один - виртуализация. Установка винды и всех необходимых программ с нуля в виртуальную машину, а так же её настройка вылились бы в очень длительную и неприятную процедуру. Но оказалось, что есть выход гораздо проще - можно виртуализировать уже установленную систему. Для этого я воспользовался программой VMware Converter. Опишу, как это можно сделать.

Добавление контейнера сервлетов Apache Tomcat в Eclipse

При разработке сервлетов и JSP в Eclipse можно настроить использование контейнера сервлетов Apache Tomcat. Это очень удобно, т.к. после этого Eclipse сам будет деплоить проекты на Tomcat, а так же запускать и перезапускать Tomcat, когда это необходимо, вдобавок к этому появляется удобная возможность управления настройками Tomcat.

Добавление Apache Tomcat

1. Качаем Apache Tomcat и распаковываем его например в каталог ~/Programs/apache-tomcat-v6

2. В Eclipse выбираем пункт меню Window -> Preferences -> Server -> Runtime Environments и нажимаем кнопку Add

3. Выбираем версию устанавливаемого контейнера сервлетов (в моем случае это Apache Tomcat v6.0) и нажимаем Next

4. Указываем имя сервера, которое удобно для нас, затем путь к каталогу с Tomcat (~/Programs/apache-tomcat-v6) и выбираем среду выполнения Java, в которой должен выполняться Tomcat (можно выбрать default JRE, т.е. ту в которой выполняется сам Eclipse, либо одну из ранее добавленных в Eclipse). После этого нажимаем Finish.

Формирование отчетов в OpenOffice.org Calc и Writer из Java-программы

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

• juh.jar, jurt.jar, ridl.jar, unoloader.jar из каталога /opt/openoffice.org3/basis-link/ure-link/share/java (если OpenOffice.org установлен не из официальных репозиториев) 
• unoil.jar из каталога /opt/openoffice.org3/basis-link/program/classes
• bootstrapconnector.jar, который можно скачать здесь

Можно скопировать данные библиотеки в директорию jre/lib/ext, но лучше подключить их в своей среде разработки, как User Libraries.
Библиотеки juh.jar, jurt.jar, ridl.jar, unoil.jar и unoloader.jar представляют собой необходимый набор классов API OpenOffice.org.
Библиотека bootstrapconnector.jar необходима для решения некоторых проблем, которые могут возникнуть во время подключения приложения к работающему экземпляру OpenOffice.org при определенных условиях. Подробнее об этих проблемах можно почитать здесь (на англ. яз), там же есть ссылка на саму библиотеку.
Когда всё установлено и все библиотеки подключены можно приступать к разработке. Приведу пример рабочих классов и методов для работы с OpenOffice.org Calc и OpenOffice.org Writer.

Интеграция Apache Derby в Java-приложение

При создании небольших прикладных программ, решающих относительно простые задачи, очень часто приходится использовать базы данных для хранения информации, потому что это очень удобно. Так же, обычно, у таких программ не предполагается обработка и хранение больших объемов информации, работа в сети и многопользовательский доступ к базе данных. В таком случае зачастую очень не хочется заморачиваться с использованием таких СУБД, как PostgreSQL или MySQL, т.к. при установки такой программы необходимо, что бы либо пользователь обладал определенными знаниями в этой области и смог настроить СУБД для работы с созданной нами программой, либо для программы придется писать дополнительную программу-установщик, что бы избавить конечного пользователя от совершенно ненужных ему плясок вокруг установки и настройки сервера базы данных.
Но есть более простой выход - использование СУБД Apache Derby, которая может быть интегрированна в Java-приложение. В этой статье я кратко расскажу как можно реализовать такой подход.
При разработке я использовал ОС Linux и среду разработки Eclipse, поэтому статья ориентированна на эти системы, но точно так же всё написанное можно переоформить для MS Windows и любой другой среды разработки.

WEB-камеры в Linux

Для работы с WEB-камерой в Linux можно использовать драйвер UVC, который, начиная с версии 2.6.27, входит в состав ядра Linux. Но для того, что бы все легко и непринужденно работало, нужно купить правильную камеру :) При покупке камеры необходимо опираться на список камер, поддерживаемых драйвером UVC

Проверка камеры:

1. Необходимо загрузить модуль ядра uvcvideo:

# modprobe uvcvideo

2. Проверяем, что модуль нормально загрузился:

# lsmod |grep uvc
uvcvideo                    59272   0
compat_ioctl32            5248  1 uvcvideo
videodev                    36992  1 uvcvideo
usbcore                   150896  9  snd_usb_audio,uvcvideo,snd_usb_lib,usb_storage,libusual,usblp,ehci_hcd,uhci_hcd

3. Проверяем камеру с помощью программы uvcview (в openSUSE 11.1 luvcview):

#  uvcview
YUV422
YUY2
MJPEG
parm.parm.capture.timeperframe.numerator    = 1
parm.parm.capture.timeperframe.denominator = 15
parm.parm.capture.timeperframe.numerator    = 1
parm.parm.capture.timeperframe.denominator = 15

Файл устройства WEB-камеры /dev/video0, /dev/video1 и т.п.