PHP.SU

 Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи

Страниц (1): [1]

> Найдено сообщений: 6
Balancer Отправлено: 25 Октября, 2016 - 13:24:53 • Тема: Вопрос по использованию asset в Composer • Форум: Программирование на PHP

Ответов: 2
Просмотров: 610
caballero пишет:
Посему никаких боверов.


bower [как пакетный менеджер] в теме и не упоминается Улыбка
Balancer Отправлено: 24 Октября, 2016 - 23:52:38 • Тема: Вопрос по использованию asset в Composer • Форум: Программирование на PHP

Ответов: 2
Просмотров: 610
 В Composer нет штатного инструментария для работы с ресурсами/asset.

Есть несколько более-менее популярных решений со своими достоинствами и недостатками.

libra/libra-assets-installer — умер и оживлению не подлежит.

robloach/component-installer — отлично подходит для раздачи собственных ресурсов. Но задача чаще стоит в том, чтобы подключать сторонние пакеты, в первую очередь — bower. Можно, конечно, собирать свои сборки, даже автоматизировать процесс, но придётся постоянно следить за выходом новых версий. Когда пакетов становится хотя бы десяток, это уже утомительно.

Есть средства для работы напрямую с bower-asset:

fxp/composer-asset-plugin — очень популярное решение, отчасти из-за простоты использования, отчасти из-за использования в Yii. Минус в очень долгой работе и необходимости первого глобального включения (или в новых версиях composer/plugin стали такое разруливать? — давно не натыкался на ошибку зависимостей, но специально руки не доходили проверить). Главный же для меня минус — это то, что пакет из bower тянется целиком. Со всеми исходниками, примерами, документацией... Иногда они занимают место в десятки раз больше, чем сами рабочие файлы .min.js/.min.css... И всё это вываливается на боевой сервер!

asset-packagist.org — практически то же самое решение, даже совместимое по форматам, только требует указания отдельного репозитория, что в дополнительный минус, но работает быстро, что в плюс. Главный же минус загрузки уймы мусора остаётся таким же.

Так вот, у меня возникает вопрос. Может, я что-то упустил? Может, есть решения, типа fxp/composer-asset-plugin/asset-packagist.org, но позволяющие на уровне пакета (не composer.json проекта!) указать дополнительно, какие файлы и каталоги нужно реально задействовать из bower-пакета? Или есть какое-то решение третьего типа?
Balancer Отправлено: 10 Сентября, 2013 - 22:27:20 • Тема: Большие файлы и нагрузка на сервер • Форум: Работа с файловой системой и файлами

Ответов: 17
Просмотров: 4763
 Даже если размер «файловой базы» будет в считанные килобайты — и то БД будет уже быстрее. В случае мегабайтных размеров разница в скорости будет вообще несопоставимая.
Balancer Отправлено: 10 Сентября, 2013 - 17:09:17 • Тема: React PHP • Форум: HTTP и PHP

Ответов: 0
Просмотров: 1538
 Кто-нибудь практиковал?

React PHP
Event-driven, non-blocking I/O with PHP.
http://reactphp[dot]org/
https://github[dot]com/reactphp/react

Пощупал на тестах. Понравилось — действительно высокая скорость работы и есть параллелизация (на тестовом ноуте с i3 выдаёт 500 rps в один поток и 1400 rps в четыре потока).

Не понравилось — не перезагружает контент при изменении файла (в отличие, скажем, от встроенного в PHP сервера — но тот однопоточный).

И, главное, не понял, как реализовать неблокируемость. Ставлю перед HelloWorld паузу — все последующие запросы ждут, пока выполнятся предыдущие и только тогда начинают отрабатывать свою паузу… Есть подозрение, что я на уровне теста что-то не так готовлю Улыбка

А, может, есть у кого-нибудь мысли, как сделать асинхронным встроенный web-сервер?
Balancer Отправлено: 15 Апреля, 2013 - 19:17:43 • Тема: Консольные интерактивные приложения на PHP под Linux. • Форум: Операционная система и системные вызовы

Ответов: 3
Просмотров: 3154
 Ну, обмен данными — это не вопрос, я тоже на сигналах делал обмен, когда gearman-демона делал.

Тут вопрос именно в проблеме запуска, обмениваться данными процессам после запуска не требуется.

Я сейчас решил задачу костылём. Использую первый вариант (интеграция PHP-скрипта в bash-скрипт), а мусор вычищаю вызовом ob_end_clean(); в начале PHP-части:
PHP:
скопировать код в буфер обмена
  1.  
  2. #!/bin/bash
  3. #<?PHP /*
  4. php -S localhost:12345 $0 &> /dev/null &
  5. sleep 0.2 # Пауза, чтобы сервер успел стартовать
  6. elinks http://localhost:12345 # запуск браузера
  7. killall php # закрытие сервера
  8. exit
  9. */
  10.  
  11. // Тут пошёл PHP-код роутера
  13.  
  14. define('BORS_CORE', '/var/www/bors-test/bors-core');
  15.  
  16. require BORS_CORE.'/init.php';
  17.  
  18. class app_test extends bors_meta_sendform
  19. {
  20.     function form_fields()
  21.     {
  22.         return array(
  23.             'film_id' => 'Идентификатор фильма',
  24.             'description' => array(
  25.                 'title' => 'Описание',
  26.                 'type' => 'text',
  27.             ),
  28.         );
  29.     }
  30. }
  31.  
  32. echo bors_load('app_test', NULL)->body();
  33.  



Нажмите для увеличения


С одной стороны, работает, при чём быстро, удобно и как требуется, с другой — всё равно костыль. Так что если кто предложит более изящное решение, то буду рад Улыбка
Balancer Отправлено: 15 Апреля, 2013 - 16:58:40 • Тема: Консольные интерактивные приложения на PHP под Linux. • Форум: Операционная система и системные вызовы

Ответов: 3
Просмотров: 3154
 Периодически возникает задача сделать интерактивное приложение под PHP. Обычно делается всё тупо и некрасиво — echo/fgets. Есть, понятно, и готовые библиотеки на этот счёт, но там, в общем-то, всё также некрасиво.

Следующая мысль — сделать что-то на ncurses. Но придётся делать целую прослойку для стандартных элементов интерфейса и взаимодействия их с приложением. Тоже долгая история. Но на её пути родилась такая цепочка. Для языка разметки форм хорошо бы задействовать тот же HTML → Надо писать хотя бы примитивный парсер форм → Хорошо бы для этого задействовать уже имеющиеся консольные браузеры → Консольный браузер итак может показывать HTML-страницы, выданные скриптом и отсылать запросы в него же, при этом в PHP5.4 появился неплохой встроенный Web-сервер.

И, вот, основная идея готова. Скрипт запускает web-сервер, потом — консольный браузер с запросом к этому серверу. Работаем привычно, как с любым Web-приложением, когда завершаем работу и выходим из браузера, сервер убивается. Получается удобно, красиво (для консоли) и без велосипедостроения.

А вот на практической реализации уткнулся в проблемы.

Хочется иметь автономный запускающий скрипт. С состоящим из двух частей — никаких проблем. Например, bash-запускалка и php-роутер, который проинициирует систему. Но удобно, когда скрипт один. Соответственно, в голову приходит два варианта:

— Комбинированный скрип, запускающийся как bash, продолжающийся как php. Ну, грубо говоря (концепт):
PHP:
скопировать код в буфер обмена
  1.  
  2. #!/bin/bash
  3. #<?PHP /*
  4. php -S localhost:12345 $0 &> /dev/null &
  5. sleep 0.2 # Пауза, чтобы сервер успел стартовать
  6. lynx http://localhost:12345 # запуск браузера
  7. killall php # закрытие сервера
  8. exit
  9. */
  10.  
  11. // Тут пошёл PHP-код роутера
  12.  
  13. echo "Run!";
  14.  


Этот вариант прекрасно работает, но, увы, мусорит на экран двумя хэшами. Я так и не поборол пока эту проблему.

Следующий вариант более «полноценный». Всё засунуть целиком в нормальный PHP-скрипт, из него запустить фоновым процессом php с web-сервером, запустить браузер, после выхода из последнего — всё за собой подчистить. Тут вылезла другая проблема. Единственный способ запустить браузер интерактивно, который я нашёл — это pcntl_exec(). Во всех остальных случаях он тупо ждёт ввода, ничего не выводя на экран, пока его не прибить (пробовал lynx, links, w3m).

Кроме того, возникали постоянные проблемы с работой фонового web-сервера, пока не засунул его запуск в pcntl_fork(). Текущий вариант такой:
PHP:
скопировать код в буфер обмена
  1.  
  2. #!/usr/bin/env php
  3. <?PHP
  4.  
  5. $self = $_SERVER['SCRIPT_NAME'];
  6. if(empty($_SERVER['HTTP_HOST']))
  7. {
  8.     // Это часть-запускалка
  9.     if($child = pcntl_fork())
  10.     {
  11.         // Мы запустили дочерний процесс. Тут — работает основной процесс
  12.         usleep(300000); // Чтобы сервер запустился
  13.         // Запуск браузера
  14.         pcntl_exec("/usr/bin/lynx", array("http://localhost:58671/"));
  15.         // Убиваем процесс сервера
  16.         posix_kill($child, 15);
  17.     }
  18.     else
  19.     {
  20.         // Это — дочерний процесс
  21.         // Запуск сервера в фоновом режиме
  22.         pcntl_exec("/usr/bin/php", array("-S", "localhost:58671", $self));
  23.     }
  24.  
  25.     exit();
  26. }
  27.  
  28. // Часть web--сервера
  29. // Тут — роутер
  30.  


Тут вылезла другая проблема. Всё отлично работает, пока не сделаешь выход. После выхода из браузера php-скрипт вываливается, не доходя до выполнения убийства web-сервера. Если после pcntl_exec("/usr/bin/lynx") поставить логгирование в файл, то оно никогда не вызывается. Соответственно, после выхода из браузера мы оказываемся в консоли, но у нас в фоне остаётся запущенный web-сервер.

Есть у кого-нибудь мысли, как решить первую или вторую проблемы?

Страниц (1): [1]
Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB