Вышел PHPIns!de #13, Материалы 4-ой PHP-конференции, Киев 2005

всегда радовало преобладание контента над рекламой в этом журнале, be on

мда, почитал...

можно сказать, что php подходит для небольших проектов, а потом начинается никому не нужная дурь. Кроме того, нужно использовать несколько языков программирования для разных задач в одном проекте, а не пихать php/java повсюду

кстати, разве кто-то пользуется php5?

>НУЖНО использовать несколько языков программирования

МОЖНО еще куда не шло... но с каких это пор НУЖНО? И кому?

>php подходит для небольших проектов

Да прочитав один журнал сделали такие выводы... и что есть "никому не нужная дурь" из-за которой php не подходит для больших проектов?

Можно ли его дебажить также удобно как JSP в нетбинс?

а где #12? 8)

Мы используем php5.. Он хоть на язык похож в отличие от предыдущих версий. Я уже не понимаю как можно писать что-то на php4...и +mysql...

а при чем тут ЛОР????

Бедные, столько времени ждали... вот до чего доводит лень: вместо того чтобы начать работать на python, ruby, jsp(jsf), asp - любители изобретают вечный велосипед или ждут Второго Пришествия.

> можно сказать, что php подходит для небольших проектов, а потом начинается никому не нужная дурь

вам нужно показать большие проекты на пхп, чтобы невозникало больше подобной дури?


> Кроме того, нужно использовать несколько языков программирования для разных задач в одном проекте

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

>Мы используем php5.. Он хоть на язык похож в отличие от предыдущих версий. Я уже не понимаю как можно писать что-то на php4...и +mysql... Да. PHP5 значительно лучше четверки. Но реалии таковы, что на очень большом количестве серверов все еще стоит PHP4. И если пишешь разным дядям проекты, то нужно еще задумываться о переносимости с сервера на сервер. Ибо не факт, что написанное будет лежать именно на сервере с PHP5.

Мне тоже не нравится php, и jsp куда больше по душе.
Но свое поделие потом нада выложить в инет, и сравнивать по кол-ву предложение и цене хостинка на php и jsp не приходится.

> И если пишешь разным дядям проекты, то нужно еще задумываться о переносимости

Поставить php5 всяко проще, чем жабу. Можно установить его на рядом с php4, только файлы переименовать в *.php5. Никому мешать не будешь.
Или дяди совсем нищие?

> вместо того чтобы начать работать на python, ruby, jsp(jsf), asp

Почему у нас в стране так много любителей удалять гланды через заднепроходное отверстие ? Геморройнее чем питон трудно даже придумать, а о asp в приличном обществе не говорят - нетрадиционная ориентация тут не приветствуется. Я знаю много прекрасных php проектов от небольших ботов до сложных биллинговых систем, и работает все прекрасно, ставится с полтыка, несовместимостей нет практически. Зато если какой-нибудь уникум напишет что-нибудь на питоне - это 99% процентов геморрой - нужно ставить кучу каких-то либ, для которых даже rpm нету, приходится собирать rpm, ставить, потом в 50% случаев версия не та, искать, качать, собирать... В морг, однозначно...

> Поставить php5 всяко проще, чем жабу. Можно установить его на рядом с > php4, только файлы переименовать в *.php5. Никому мешать не будешь. > Или дяди совсем нищие?

Что за дурная мода говорить "нищие" если заказчик не желает менять конфигурацию сервера? Или у тебя было тяжелое несчастное детство и одна картофелина на ужин на всю семью? Тебе не могло прийти в голову то, что на сервере заказчика уже работают несколько задач и менять конфигурацию без крайней необходимости просто глупо?

>Геморройнее чем питон трудно даже придумать... Я знаю много прекрасных php проектов от небольших ботов до сложных биллинговых систем, и работает все прекрасно, ставится с полтыка, несовместимостей нет практически.

Как раз наличием несовместимостей (в плане api) PHP может побить все рекорды. Достаточно вспомнить классы.

А тогда надо прописывать в техзадании - пхп4 - так 4, 5 - так 5. Согласовывать с администратором заказчика платформу на которой должно работать.

>Как раз наличием несовместимостей (в плане api) PHP может побить все рекорды. Достаточно вспомнить классы. Согласен на все сто :)

>>вам нужно показать большие проекты на пхп, чтобы невозникало больше >>подобной дури?

Да, пожалуйста. И отчет по затратам.

Сразу видно - админ. Это диагноз.

Разве web сайты можно называть большими проектами ? У пхп своя нисша, и лучше пхп в этой нисше сейчас ни чего нет. Почему пхп: 1. На рынке довольно большое количесво ПХП разработчиков и клиент не рискует остаться с проектом на языке Х и без разработчиков. 2. ПХП простой язык, он легко осваивается. 3. Достаточно большое количество готовых библиотек. 4. Много книг, справочной информации (просто не сравнимо с количеством книг по питону или jsp). 5. Большинство хостингов поддерживает ПХП, причем как 4 так и 5 версии. 6. ПХП легко расширяется - если нужны сложные модули - можно написать на С. 7. В отличии от java/python/.+ пхп быстр и не так требователен к ресурсам.

Тут еще дохера можно написать, но самое главное - грамотный разработчик знает когда и каким инструментом нужно пользоваться. Где надо - пхп, где не надо пхп - Си. Не станете же вы рубанком валить деревья. ,-)

долго думал?

2 insa: Ну что за привычка писать о том, чего не знаешь? Документация у Sun - это святое, поэтому 4-ый пункт смело вычёркивай... 7-ой, кстати, туда же...

Затратно. Попробуйте написать eZPublish на php и потом на java(совокупность java технологий) - посчитайте затраты. На php придется изобретать велосипеды, а на ява - использовать уже готовые стандартные(де-факто) технологии: jcr-168(Portlets API), jcr-170(Repository).

> Что за дурная мода говорить "нищие" если заказчик не желает менять конфигурацию сервера?

Дык одна строка меняется в конфигурации апаче... Это что, непосильная задача?

> На php придется изобретать велосипеды, а на ява - использовать уже готовые стандартные(де-факто) технологии

Хм, а если велосипед в виде ezPublish уже написан и готов к
использованию? Java-технологии тоже когда-то писались с нуля.
И, кстати, разработка ezPublish началась очень давно, возможно ещё
тогда, когда java сама была ещё в разработке. Короче, аргумент не
принимается.

Чукча не читатель, чукча - писатель? Ясно же сказано - затраты на разработку аналогичной системы.

> На php придется изобретать велосипеды

с какой это радости ? вам мало классов и модулей ?

А смысл в разработке аналогичной системы? Она сделана для того, чтобы на
её основе что-то делали. Это ж движок.

Тоже читать только учимся? Где аналог стандартного репозитория, портлетов? Интеграция с существующими enterprise системами? Workflow движок поддерживающий стандарт BPEL? Средство RAD разработки(типа JSF, ASP.NET)? И т.д. и т.п.

Совсем что ли разучились читать? Я говорю о затратах на разработку аналогичной системы - и только. Когда будете разрабатывать собственную систему - увидите и смысл. А пока - мы рассматриваем эффективность разработки.

> Где аналог стандартного репозитория, портлетов? Интеграция с существующими enterprise системами?

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

ничего технически невозможного для языка программирования php вы не назвали:) PHP4 был действительно языком для небольших портальчиков, сейчас с нормальной поддержкой ООП, XML, SOAP, всевозможных БД и кучей заинтересованного народа (о чем свидетельствует собственно деятельность подобных клубов и конференции, да и доминирование LAMP). Я бы не стал его списывать со счетов.

Т.е. при разработке web cms, мне придется репозиторий с нуля писать? А вместо решения бизнес логики компоненты( и контейнер) создавать? Да я лучше в Вену слетаю в Stadtpark'е месяцов на шесть - засяду с косяком.

Опять 25. Да, возможно технически это написать на php, - но затратно. Мы тут финансовую сторону обсуждаем, ровно как и вопрос эффективного использования технологий.

на что затраты то я не понял, надо кирпичик идем до репозитория PHP или PEAR классов и берем оттуда, надо готовое CMS с разделением логики и междумордия, их хоть одним местом ешь

Не шибко грамотный? Репозиторий - это не отстойник из PHP "классов", а Content Repository(стандартизирован в JCR-170).

Единственный Web CMS на php, достойный внимания - это eZPublish.

> Репозиторий - это не отстойник из PHP "классов"

если разработчики обозвали свою технологию или продукт репозиторием это не значит, что остальные памойки не имеют больше право так называться, я не сравнивал JCR-170 и онлайн репозитории, я говорил что полуфабрикатов различной степени готовности в PHP тоже навалом

>>если разработчики обозвали свою технологию или продукт репозиторием >>это не значит

Значит. Это стандартный термин в обсуждаемой предметной области(ECM/CMS). И никак не указывает на что-то другое.

>>я говорил что полуфабрикатов различной степени готовности в PHP тоже >>навалом

Приводим пример "полуфабриката" уровня JBoss и Hibernate.

http://www.google.ru/search?hl=ru&ie=windows-1251&q=php+application+s...

кстати интересные вещи former CTO of Sun's app server division по второй ссылке говорит

Нда. На процессоре html такие приложения писать... Нужно было сразу на XML'е. Хотя, собсвенно, эти приложения - for fun.

То, что пишет "former CTO of Sun's app server division" - давно не актуально. Следите за новостями.

Если бы привели пример Ruby on Rails - было бы другое дело. Этот Rails - идеален, в смысле эффективности разработки(в сочетании с интерп. языком). На презентациях от него в восторге как разработчики, так и дельцы. В свое время так же отнеслись и к LAMP(т.е. посчитали затраты, и решили - наше). Язык никого, по большому счету, не интересует.

> Этот Rails - идеален, в смысле эффективности разработки

Покажи много-много разработок, сделанных этим самым эффективным
способом. А нету их. Очень большие ограничения накладывает на
разработчика Rails. Рисовать небольшие таблички с простенькими связями -
вот предел того, на что он годится. Того же эффекта можно добиться одним
классом на php.

Понятно, - вы не в танке. Хотя слово "класс" в таком контексте вас выдает еще за того "программиста". Читайте книжки по SD, про архитектуры программ и т.д. Кстати, для начала рекомендую "Coder to Developer: Tools and Strategies for Delivering Your Software" (в сети есть).

Рассуждать с учёным видом мы все горазды. А вопрос был предельно прост:
если Rails так эффективен, покажите много разработок на нём ;)
А в ответ тишина...

Уж не знаю, что ты там понял, я под классом имел в виду реализацию
того, что в Rails называется Active Record. И все другие принципы,
на которых построен Rails реализуются в php элементарней и проще.
Я, например, когда впервые читал описание Rails сразу отметил про себя,
что большую часть так называемых "идей" активно использовал в своих
проектах на php много лет.

Ну и напоследок для тех, кто в танке вопрос на засыпку: если Rails так
эффективен, то для чего люди парятся и выдумывают такие вещи, как
Nitro? Потрудитесь почитать и понять, что им не хватало в Rails.
http://www.nitrohq.com/

И ещё. Rails создавалась как противовес программным решениям на java,
но никак не php. Это недвусмысленно отражено в любом его описании.
На php подобные решения существовали давно. Поэтому я не совсем понимаю
ажиотаж отдельных товарищей по поводу ruby on rails. А если сравнивать
чисто языки - ruby и php5, то у кого-нибудь поднимется язык заявить о
явном превосходстве того или другого? Они практически эквиваленты по
возможностям.

А вот если бы привели в пример ocaml, то я бы вас ещё послушал. Язык
действительно перспективный. Очень жаль, что мало распространён. А ruby?
Чуть улучшенный perl. Приятно было бы с ним поработать, родись он лет
на десять раньше.

Php - для старшеклассников, - на пиво заработать.