Антон

Сканеры штрих-кода (из тех, с которыми мне довелось работать) обычно работают в двух вариантах:
1) Эмуляция клавиатуры (те, кто подключаются через PS/2 или работают как USB HID)
2) Эмуляция COM-порта (те, которые соответственно втыкаются в компорт либо являются USB Serial Device)

Взаимодействие с первыми аналогично клавиатуре. В чем их плюс — возможность работы даже с тем софтом который не знает что такое «сканнер штрих-кода». Для программы это будет выглядеть полностью аналогично как если бы оператор набрал на клавиатуре артикул товара. (то есть полностью прозрачно для программ)
Соответственно, сериальные устройства для тех программ, которые знают что такое сканнер штрих-кода и умеют с ним работать.

Соответственно, вопрос. Вам для каких нужд? Если Вы хотите минимальными затратами организовать «рабочее место оператора» с взаимодействием через веб — то вариант с USB HID — это ваш вариант. Вы просто с помощью PHP рисуете форму, с полем, куда JS-ом выставляете фокус. Оператор «пикнув» сканнером штрихкода просто введет туда цифры. (И незабываем, какой еще ОГРОМНЫЙ плюс возникает, если штрихкод потерт и нечитается — оператор просто набивает артикул на клавиатуре в это поле.)

Вариант с Serial-подключением имеет плюсы лишь когда вы организуете выделенное узкозаточенное рабочее место.

Comet

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

> Также может посоветуете какую-нибудь opensource баннерную систему на PHP?
OpenX попробуйте. Очень «тяжелая», но весьма функциональная.

Немного хочу сказать за Zend. Последние 3 года работаю с ним. Так вот что хочу сказать, часто вижу что пишут какой же он большой, он не подходит для проектов с большой нагрузкой. Из своего опыта могу с уверенностью сказать:

Большой? Это фреймворк — одно из его предназначений набор готовых классов, вас же не просят использовать их все, к тому же autoload решает. Другой вопрос когда идёт этап оптимизации кто вам мешает что-то подточить под конкретный проект даже если это будет код самого фреймворка, это уже конкретный проект и там есть конкретные задачи, не обязательно везде использовать универсальный вариант да и по моему такое в больших проектов редко вообще можно сделать.

И более того всё это применимо к любому фреймворку, тут зависит от человека что ему предпочтительнее дополнять что-то или менять и удалять ненужное. Я для себя выбрал второе.

Для вашего совещания(если я правильно понял что выбор не для разработки проекта) стоит отметить ZF dev версии 2.0 (инфа есть на wiki и gihub) про другие фреймворки сказать не могу, но считаю более логично рассматривать dev-версий их плюсы и минусы, ну и конечно же перспективы.

В Zend Framework в отличии от других фреймворках реализовано больше типовых задач, огромное количество модулей, хорошо поставленный процесс разработки, и есть у него ещё одно преимущество.

Вам не обязательно использовать фреймворк целиком. Вы можете взять из него один класс и спокойно юзать его, и не будет никакой монструозности. Symfony только вступила на этот путь, выделив 5 компонентов (http://components.symfony-project.org/). ZF идёт по нему с самого начала. Попробуйте, и вам понравится ;-)

Мы используем CakePHP, по стилю основан на Ruby on Rails, почему то мало кто о нем знает. Документация вполне не плохая. Не сложен в освоении. Так же распространяется Yii фреймворк, на него уже не одна организация переводит свои высоконагруженные проекты, например, знаю что как раз с того же Codeigniter.
Zend Framework и Symphony на мой взгляд тяжелые и больше способствует бренд.

4 года работал с symfony, могу сказать что он очень быстро развивается. Будьте готовы к тому, что через год–полтора выбранная ветка станет неподдерживаемой.

Комьюнити у symfony намного демократичней нежели у зенда: нет такой странной бюрократии с их proposals, соответственно быстро вносятся все изменения.

Symfony 1й ветки (хотя, кто на ней сейчас станет что-то писать) очень неаккуратно работала с системными вызовами, не кешировала лишний раз кучу stat'ов например. Во второй ситуация, видимо, изменилась, судя по очень значительному увеличению скорости.

Может мне так показалось, но в сравнении при написании кода symfony выглядит както более нативно чем zend, в котором чувствуется некоторая угловатость. Хотя, это мой сугубо личный взгляд.

Я сам работаю с Yii и по мне он все выше указанные фреймворки если не провосходит то демонстрирует схожий набор ф-сти.

Но зенд фактически это что-то типа энтерпрайз солюшн, со всеми плюшками что он дает от зенд сервера до зенд иде и т.д.

Зенд наиболее часто востребован на западе, в том числе из-за указанных мною причин. Но он монстропободобный.

Все зависит от задач, если Вы не сможете расписать точно Ваши цели и задачи, я не думаю что чей либо совет будет адекватным :)

В кратце:
CI только не давно перешел на 5й пхп.

Symfony юзает страшный и могучий ОРМ (пропел и доктрин) очень ресурсоемкие.

Зенд вероятно обладает наиболее широкими возможностями.

А вот Yii имеет возможно меньший набор библиотек — хотя нет никаких проблем использовать их от зенд фреймворка :), ОРМ в Yii более «легкая», и он давно на 5м ПХП (и по мому с самой первой версии). Мой выбор Вы уже знаете :), дело за Вами.

Для начала вы решите для себя что нужно Вам?

• Выучить просто фреймверк какой нибудь?
• Фреймверк с кучей модулей?
• Быстрый фреймверк?
• Гибкий фреймверк?
• Надежный фреймверк?
• Хорошую поддержку?
• Простоту обучения фреймверку?

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

Думаю что паттерн синглетон + любое хранилише
Синглетон чтобы случайно не менять значения из 2х мест сразу
хранилище — хоть какое
— База данных
-memcache
-файлики можно как нибудь хитро распихать по дирректориям
-xml
-twitter )

Реализацию можно подсмотреть в Zend_Registry

zabbix?

munin или ручками настроить snmp и mrtg
по настройке munin — goo.gl/TUyav

monit/nagios/zenoss?

www.domain.com/* — для основной языковой аудитории
www.domain.com/lang/* — для дополнительной языковой аудитории.

С поддоменами — это уже совершенно разные сайты получаются, очень редко используется.

А вообще, многие CMS и такое выдают:

www.domain.com/index.html?lang=ru

Лично мне приятен вариант, когда www.domain.com отображает английский вариант сайта, а www.domain.ru — русский. Но не всегда бывает доступны оба домена.

Тогда вариант с www.domain.com/ru (или /en/) подойдет.

Вариант с ru.domain.com мне не особо нравится. И уж точно www.ru.domain.com будет смотреться очень странно

Хороший мануал по PHP — manual.pohape.ru