ModX Revolution
С выходом ModX Revolution 2.0 все мои предыдущие претензии снимаются. Она охуенна с программерской точки зрения. Все мои уважаемые комментаторы из старых постов могут спать спокойно. Макаки соснули хуйцов. Жизнь наладилась.
Netbeans
Сегодня я отказался от использования Eclipse в пользу NetBeans для разработки веб-приложений на PHP/JavaScript. Eclipse жутко заебал со своими глюками и багами. Устанавливайте NetBeans PHP и будьте счастливы.
jQuery.noop()
Меня часто спрашивают для чего нужна эта пустая функция, которая не делает ничего. Noop() — это функция-заглушка. Представим себе некий объект, который в процессе его использования может инициировать какие-либо события. Скажем, это код, который мы получаем с другого сайта. Он строит красивую кнопку на нашей странице. Но вот беда — нам совершенно не нужно знать, когда произойдет событие onclick. А сторонний код написан таким образом, что мы обязаны указать обработчик события, иначе ошибка.
Вот тут нам на помощь и приходит noop(). Вызывая инициализацию объекта, в параметре, передающем функцию обратного вызова, мы указываем jQuery.noop(). Условия выполнены, а действие не обрабатывается. И все довольны.
Кросс-доменный запрос с помощью Ajax и jQuery
Кросс-доменные запросы — головная боль разработчика. Производители браузеров сделали всё возможное, чтобы программисты выносили свой мозг. В jQuery есть набор функций для работы с AJAX, которые превосходно работают в контексте одного домена. Однако, как только дело касается межсайтового взаимодействия мы сталкиваемся с целой кучей подводной камней.
В интернете можно найти много способов решения этой проблемы, я же для себя выбрал путь на основе JSON и объясню почему.
- JSON — сериализированные данные, которые удобно читаются человеком.
- JSON данные легко преобразуются в объекты.
- Данные легко преобразуются в текст JSON.
- jQuery прекрасно работает с JSON и AJAX
- На основе JSON наиболее просто организовать API.
- JSON расходует гораздо меньше трафика, чем, к примеру XML.
Этих шести пунктов мне оказалось более чем достаточно. Однако, я так и не смог найти нормального объяснения как должен работать кросс-доменная технология и JSON, и обратился на stackoverflow.
Для того, чтобы передать данные с одного сервера на другой используется технология JSONP. Фактически это JSON с функцией обратной связи. Скрипт, формирующий JSON данные на стороне сервера, должен представить их в виде вызова функции. К примеру, представление данных
{"foo" : "bar"}
будет выглядеть таким образом:
callback({"foo" : "bar"});
где callback — имя функции, вызываемой в JavaScript на стороне клиента. В случае с jQuery имя этой функции автоматически добавляется в конец строки URL. Фактически при выполнении
$.getJSON("example.php");
URL приобретет вид example.php?=_random_name, где random_name — это функция, в аргумент которой должен быть передан JSON. Таким образом, корректно будет запрашивать скрипт, передавая ему имя этой функции в параметре.
$.getJSON("example.php?callback_name=?");
PHP должен добавить имя этой функции и в нее встроить данные.
<?php
$data=array("1","2");
$callback=$_REQUEST['callback_name'];
print("$callback(".json_encode($data)+");");
?>
Только таким образом удается передать данные кросс-доменно. На основе JSON/JSONP построены API различных онлайн-сервисов, например Flickr или Yahoo Finance. Впрочем, стоит отметить, что отправить запрос POST таким образом не удастся, для полноценного POST придуман другой метод.
Настройка Dklab Realplexor для работы на Localhost.
Realplexor — это так называемый Comet сервер, позволяющий конструировать асинхронные веб приложения. Принцип действия прост: вместо того, чтобы закрывать HTTP-соединение между клиентом и сервером, программный комплекс старается поддерживать его как можно дольше. Это позволяет построить приложение, осуществляющее двусторонний обмен данными и задействовать модель программирования на основе событий. Фактически, вместо постоянного опроса клиента сервером в ожидании смены состояния, влекущего событие, здесь событие определено изначально и инициации сервером.
Как и где применять Реалплексор сложно сказать, на его основе можно построить все что угодно, требующее мгновенного обмена данными. В интернете существует несколько аналогичных проектов (напр. APE), однако они сложны и требуют больших временных затрат. Плюс ко всему, идеологически верно поддерживать наших разработчиков.
На сайте производителя есть информация по базовой настройке сервера, я же расскажу как настроить сервер разработчика (development server) на базе ОС Ubuntu 9.10.
Идеология и безопасность.
Фактически Реалплексор это веб сервер, написанный на perl (к сожалению для меня). Он работает параллельно с Apache, ожидая соединения на свой порт, которые никогда (исключений и других правил не касаемся) не закроются. Apache работает над формированием содержимого вашего сайта, по умолчанию слушая порт 80 для входящих соединений.
Вместе с Реалплексором в комплекте идет набор API для PHP и JavaScript. PHP API мы будем использовать на стороне сервера для манипуляций с данными, а JavaScript API позволяет создать на стороне клиента соединение с сервером и берет на себя обязанности по поддержанию оного.
Логично было бы подключаться к Реалплексору просто используя его порт, например так: http://localhost:8088. Однако, производители браузеров подготовили кучу подводных камней и мы сразу же наткнемся на один из них: http://localhost:80 и http://localhost:8088 находятся в разных контекстах безопасности и соединение не пройдет. Это одна из самых известных проблем в AJAX технологии на основе XMLHttpRequest.
К примеру, Firefox порадует нас ошибкой в консоли:
Ошибка: uncaught exception: Due to the standard XMLHttpRequest security policy, hostname in URL passed toDklab_Realplexor (localhost:8088) must be equals to the current host (localhost.com) or be its direct sub-domain.
Решение проблемы.
На помощь нам придет чудо-сервер nginx. Рассказ о достоинствах этого сервера — тема для отдельного поста. Нам же, nginx позволит обойти проблему нарушения правил безопасности. Дело в том, что браузер противится соединению по другому порту, однако совершенно не против соединения с поддоменом. Таким образом нам необходимо передать nginx управление соединением и разрулить эту ситуацию.
Стоит отметить, что эту проблему можно решить и с помощью DNS, однако поднимать и настраивать DNS сервер на локальном компьютере разработчика, как минимум не рационально. Использование же связки с nginx даст очень много вкусных возможностей в будущем.
Необходимо настроить Apache на прослушивание не 80 порта, а 8080, для того чтобы освободить 80 для nginx.
Nginx будет рассматривать входящее подключение и в случае, если оно идет на поддомен, выделенный для сервера (пусть будет chat) он передаст соединение на localhost:8088, т.е. Реалплексеру. Иначе соединение уйдет к Apache на localhost:8080 если nginx не настроен иначе.
Специфика локалхоста.
Нельзя забывать, что мы работаем на локалхосте и что для нас хорошо, то немцу смерть на production сервере отвалится. Один из незаметных подводных камней это трактовка поддомена. По правилам HTTP в адресе вида chat.localhost нет поддомена, chat — это домен второго уровня, а не третьего. Поэтому нам необходимо сделать простую вещь: отредактировать файл /etc/hosts следующим образом:
127.0.0.1 chat.localhost.com 127.0.0.1 localhost.com
Таким образом выполняется требование системы безопасности по поддоменам выполняется. И мы спокойно работаем с нашим доменом localhost.com.
Настройка nginx, файл /usr/local/nginx/conf/nginx.conf:
server {
server_name localhost.com; # Для главного сайта
listen localhost.com:80; # Запрос, который получет nginx по 80 порту
location / {
proxy_pass http://127.0.0.1:8080; # Передаем обработку Apache
}
}
server {
server_name chat.localhost.com; # Для поддомена
listen chat.localhost.com:80; # На таком же порту
location / {
proxy_pass http://127.0.0.1:8088; # Запрос будет обрабатываться Реалплексором
}
}
Теперь необходимо перезагрузить все программы, участвующие в процессе.
sudo apache2ctl restart sudo /usr/local/nginx/sbin/nginx -s reload sudo service dklab_realplexor reload
Программный комплекс готов к работе.
Эпилог.
Справедливо заметить, что подобный подход может использоваться и на production-серверах. Использование nginx дает огромные перспективы по масштабированию приложения. Расход памяти составляет около 10 МБ на 1000 одновременных подключений для Реалплексора, а при грамотной настройке nginx на раздачу статики, полученный прирост производительности будет вполне ощутим.
Примеры кода доступны на сайте производителя.
Восстановление оконного менеджера GNOME
Сегодня я расскажу как восстановить случайно уроненный оконный менеджер Gnome, Metacity. Признаками его болезни может стать например такая ошибка, при нажатии на кнопку сворачивания всех окон:
Либо менеджер окон не поддерживает кнопку расчистки рабочего стола, либо менеджер окон не запущен вовсе.
Все приложения при этом выглядят без оконной рамки. Вылечить эту проблему просто: нужно переустановить Metacity, стандартный оконный менеджер. Ctrl+Alt+F2 для входа в консоль.
sudo apt-get remove metacity
sudo apt-get install metacity
sudo /etc/init.d/gdm restart
После перезагрузки Gnome система примет прежний вид.
ModX-армия. Обратная связь.
http://modxcms.com/forums/index.php/topic,44786.0.html
Некто запостил ссылочку на этот уютненький бложек в форум ModX-еров. Естественно, хомяки принялись всячески вербовать автора в свои ряды. Не знаю, рассчитывал ли автор на объективность в этом сообществе. Это ведь всё равно, что прийти к вегетарианцам, CRM-щикам или, например, на встречу работников сетевого маркетинга. Любое противоположное мнение вызывает у них адскую попаболь.
Хотелось бы прояснить маленькие детали, просто так, для галочки.
Установка Nessus
Nessus — замечательная разработка фирмы «Tenable Network Security». Это бесплатный для домашнего пользования, кроссплатформенный сетевой сканер уязвимостей. С помощью Nessus можно детектировать множество брешей безопасности в операционной системе и программных продуктах любого компьютера, доступного по сети. Это замечательный сканер используется в различных ситуациях: от благородных намерений системного администратора до злобных целей взломщиков.
Поскольку я пользователь домашний, и использую Ubuntu, я расскажу как установить и настроить Nessus под этот дистрибутив. Стоит отметить, что на сайте разработчика доступна инструкция по установке, но она слишком запутана.
Скачайте debian пакет со страницы http://www.nessus.org/download/. Разработчик предоставляет очень много сборок для различных операционных систем. На сегодняшний день актуальная версия программы — 4.2.0. Nessus установится в директорию /opt/nessus.
Программа не имеет графического интерфейса в привычном его виде, Nessus управляется через веб-интерфейс. После установки и запуска демона сканера по IP-адресу вашего компьютера станет доступен веб-сервер, который и предоставит графический интерфейс пользователя на основе Flash. К слову, Teneble Network Security предоставляет и другое решение в виде отдельной программы-клиента, но она не так удобна как интерфейс разработанный на Flash. Однако прежде чем получить к нему доступ программу нужно подготовить соответствующим образом.
Первым делом нужно создать учетную запись пользователя Nessus. Делается это с помощью программы
/opt/nessus/sbin/nessus-adduser
Наш первый пользователь будет обладать всеми правами без ограничений. В последствии, на каждого пользователя можно будет назначить ограничения разного рода. Например, вы сможете ограничить доступ только с определенного адреса для конкретного пользователя. Программа предложит ввести логи и пароль, после чего поинтересуется сделать ли этого пользователя администратором. Отвечайте утвердительно. Затем нужно будет оставить пустой строку ограничивающих правил. На этом процедура создания пользователя завершена.
Следующий этап — регистрация программы. Заполните поля на странице регистрации и вам бесплатно вышлют регистрационный код по электронной почте. Запустите программу, подставив ваш код
/opt/nessus/bin/nessus-fetch --register XXXX-XXXX-XXXX-XXXX-XXXX
Это важный момент. После этого действия Nessus начнет скачивать свои плагины, без которых он бесполезен. Плагин Nessus — это набор правил и программных кодов, которые будут применяться для детектирования той или иной уязвимости. Первый раз придется немного подождать: плагинов великое множество. По завершению этого процесса Nessus становится полностью работоспособным.
Запуск сервера производится командой
/etc/init.d/nessusd start
Теперь можно открыть браузер и набрать адрес https://127.0.0.1:8834/. Порт 8834 — это порт, по умолчанию используемый сервером. Связь проходит по SSL-защищенному соединению, поэтому принимайте сертификат и в результате увидите приветственное окно Nessus.
Nessus готов к работе!
ModX и CodeIgniter
Здравствуйте!
Все мы знаем какое говно фреймворк, предоставляемый ModX, а так же нам прекрасно известно какое говно шаблонизатор. Любой программист рано или поздно встретится с необходимостью MVC в своем проекте, для той или иной оптимизации процесса.
Лирическое отступление. Рачки и хомячки могут соснуть хуйца, потому как таких среди поклонников ModX over 9000, а вменяемых людей гораздо меньше. Почему-то хомячье страшно ведется на травлю и провокацию. Адекватный программист и ModX — очень редко встречающиеся вещи. Я таких людей знаю не больше 8-10.
Сегодня я расскажу как использовать возможности замечательного фреймворка CodeIgniter совместно с CMS ModX. Условно мы передадим ModX всю «статику»: страницы, заполняемые клиентом или контент-менеджером, а CodeIgniter оставим все динамическое содержимое и логику.
Для начала нужно скачать и установить CodeIgniter. Для того, чтобы привести адреса страниц в нормальный вид (ЧПУ) мы задействуем mod_rewrite, в файл .htaccess нужно добавить вот этот текст:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
Такая конфигурация позволит нам избавиться от некрасивых адресов и передать управление всеми страницами фреймворку CodeIgniter. Помимо этого необходимо также настроить CodeIgniter для корректной работы с mod_rewrite, сделав кое-какие изменения в конфигурационном файле. После всех настроек, убедившись в работоспособности CodeIgniter можно устанавливать ModX. Как это делается я пропускаю намеренно, в интернете полно руководств пропагандирующих установку этой CMS, поэтому я не стал вступать в ряды агитаторов. Будьте внимательны, ModX претендует на файл index.php. Переименуйте после копирования всех файлов, index.php в index.md.php.
Для чего это делается. При запросе без дополнительных параметров (example.com) будет вызван скрипт index.php который запускает CodeIgniter. Фреймворк обработает запрос и запустит контроллер, который указан таковым по умолчанию. В случае же запроса с параметром, например example.com/some/test/here также будет предпринята попытка запуска контроллера. Фактически мы передали приоритет обработки запросов фреймворку. Если фреймворк не обнаружит соответствующего контроллера по умолчанию CodeIgniter вызовет ошибку 404. Нам же необходимо, чтобы фреймворк передал запрос CMS, которая будет отвечать на все остальные запросы. Самым легким путем был бы простой redirect на index.php?q=query, однако это лишит систему дружественных путей в адресе и не очень-то обрадует поисковики (сеошники разорвут). Поэтому мы пойдем другим путем и напишем обработчик ошибок для CodeIgniter. Делается это расширением класса CI_Exceptions.
Создайте в папке system/application/libraries файл MY_Exceptions.php (префикс MY_ задается в конфигурационном файле, это обязательный момент, а не моя прихоть) и вставьте в него код:
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); /** * Класс MY_Exceptions. * Заменяет метод класса CI_Exceptions show_404 на пользовательский. * @author Баштанник А.С. */ class MY_Exceptions extends CI_Exceptions { /** * Обработчик ошибки 404. * @param $page String Не найденная страница. */ function show_404($page = '') { system('php -r \'$_REQUEST["q"]="'.$page.'"; include("../index.md.php");\''); } } ?>
Это типичная структура пользовательского расширения CodeIgniter. Интересный момент здесь только в вызове функции system. С ее помощью мы вызываем php интерпретатор, CLI-версию, которой передаем код на выполнение. Поскольку ModX берет информацию о запрошенных страницах из элемента массива $_REQUEST (или $_GET, не суть важно) с индексом q, мы присваиваем ему значение запроса, вызвавшего в CodeIgniter 404 ошибку. После чего запускается ModX, и дальнейшая обработка данных передается скрипту index.md.php.
Какие остались подводные камни? Ну во-первых, конечно же алиасы дружественных интерфейсов. Если они совпадут в ModX с именами контроллеров в CodeIgniter мы никогда не проберемся к ним, т.к. контроллеры фреймворка обладают приоритетом по вызову. Во-вторых, доступ к директориям блокирован, то есть он перенаправляется на обработку запроса фреймворком и далее по схеме. Чтобы избежать вызова скриптов при обращении к некоторым директориям в .htaccess нужно добавить строку
RewriteRule ^(manager|assets|images|css|js) - [L]
где указаны в этом случае директории, к которым будет свободный доступ по запросу, например example.com/css вызовет обращение к папке, а не к контроллеру CodeIgniter.
Пожалуй, реализация с использованием CLI PHP не самая хорошая идея, но сейчас я вижу только такой ход. Вполне возможно есть и другие способы, я попытаюсь их найти.
Где и для чего это использовать читатель разберется сам. Скажу только, что проблем в этой связке нет никаких и мы наконец-то добились гибкости. Мы можем использовать либо умный и быстрый фреймворк в связке с MVC и отказаться от ModX, либо перенести на фреймворк только логику, оставив ModX отображение данных. Простор для действий. Поживем увидим!
P.S. Обращение к хомячкам. Дорогие хомячки! Официально посылаю вас в жопу, не желаю слышать ваше блаженное фапанье на самизнаетечтоX, не желая выслушивать ни малейшей критики. Хотите поспорить? Милости просим. Если у вас среди аргументов только «Сперва добейся», желаю доброй дороги.
Почему ModX — говно собачье. Модули.
Этот пост будет коротким.
В ModX, в коде модуля нельзя вставлять HTML в нормальном его виде. Хотите нормальный интерфейс модуля? Используйте print/echo!
Для того чтобы сделать такой замечательный, просто чудесный AJAX-интерфейс, без единой строчки PHP, который я прорабатывал два дня мне нужно использовать блять include. ModX предлагает мне сохранить в коде модуля вшивую строчку include, которую она потом засунет в Базу Данных. Кто тут про разделение сущностей говорил?
Это ли не пиздец? Чтобы вытащить графический интерфейс система обратится в БД, вызовет PHP код, который в свою очередь вытащит мой HTML, с прекрасным AJAX-интерфейсом.
Тест на логику, конечно же EPIC FAIL.
