Re: Re: Re: Re: Re: Re: Проект "Perl Certified Hosting"

[Sergeev Serge]

29.07.10, 11:10, "Vladimir Vasilenko" :
> А глобальная идея "Откуда будут деньги" уже прозвучала?

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

>  Я о чём: для внутренних нужд можно установит всё, что хочешь, но, если  
>  "вязать" идею о продвижении Perl и технологии Perl, то стоит, IMHO,  
>  задуматься о вот о чём - существует несколько дальнейших путей:
>  	- мы ставим то, что нравится нам, делаем так, как нравится нам и  
>  отправляемся на "религиозную войну");
>  	- мы ищем коммерческое рещение, цепляемся к нему, и, в рамках стратегии  
>  разработчиков, выполняем собственные задачи;
>  	- мы берём за основу масштабируемый пакет с интересной функциональностью,  
>  адекватной поддержкой и подходящей лицензией, "двигаем" его, одновременно  
>  создавая (возможно, просто адаптируя на первых порах "под себя") наше  
>  уникальное решение.

Дело в том, что технологичность Perl, вместе с нашим опытом и умениями, позволяют объединить все эти пути.

>  Мне импонирует Bricolage (http://bricolagecms.org): Perl, (modperl),  
>  PostgreSQL, панковская лицензия BSD. Поддержка осуществляется вот так:  
>  http://bricolage.lighthouseapp.com/projects/29601/tickets/188-bricolage-apache-itk_2215

Ну, "на вкус и цвет..", то вобщем такое..
Мы же сейчас обсуждаем технологичность, которая складывается из несколько других обстоятельств.

>  С предидущим постом практически согласен, разве что, цитирую:
>  
>  > - Хотя twiki весьма вероятно будет лучше той-же mojowka исполнять наши  
>  > текущие задачи, но я думаю что нужно думать и о пиарной стороне - мы  
>  > ведь это все затеяли для продвижения Perl, и лучше если мы поддержим  
>  > решение, которое лучше масштабируется, проще и быстрее инсталлируется, и  
>  > выглядит правильнее.
>  
>  в текущей ситуации Perl в сознании большинства людей значительно уступает  
>  php в простоте и интегрированным средствам в "легкоте", и фразу "проще и  
>  бытрее" я бы вычеркнул из лексикона на какое-то время точно:-).

"Вы не любите кошек? - Вы просто не умеете их готовить!" (с)
Понимаете, если вы неправильно или просто недостаточно умело используете инструмент - вполне нормально, если он будет уступать другим, более простым и привычным инструментам.
- Научитесь готовить "кошек", и вы сами поймете что ошибаетесь - Perl при правильном применении ПРЕВОСХОДИТ PHP по простоте, да и с легкостью у него все в порядке.

PS Вообще, у меня складывается впечатление, что вы просто не понимаете идеологию нашего нынешнего мира.
- Сейчас все строится вокруг одного - удовлетворять потребности как можно большего числа (клиентов) людей, затрачивая на это как можно меньше ресурсов (денег, энергии, времени).
И для этого достаточно часто имеет смысл "вместо три дня идти, за один день сделать самолет и за 5 минут долететь".
И вот как раз сила Perl в том, что самолет не нужно изобретать с нуля, а есть очень мощные инструменты - Catalyst, Mojo, итд. Точнее, богатый инструментарий Perl, позволяет сделать новый экземпляр самолета очень быстро и с минимальными затратами ресурсов.

Лично я не видел на поле PHP инструментов, сравнимых например с Catalyst и Mojo.
И я думаю, что в PHP такого и не может появиться, потому что идеология другая - там и сам язык не позволяет исполнять такое как в Perl, и сообщество совсем другого уровня.

Но PHP выезжает именно на готовых решениях - за счет легкого вхождения, есть очень сильное сообщество, породившее много готовых решений, и также и бизнесу тоже нравится что легко найти программиста.
А у Perl народ намного большую долю времени/сил тратит на красивые инструменты, и намного меньше делают готовых решений.
Фактически, недостаток PHP - сложное расширение (в сравнении с Perl), превращается в достоинство, потому что оно сдерживает людей от создания новых инструментов, а у Perl наоборот - легкость расширения языка (и отсутствие изначального стандарта), привела к тому, что на самом деле единого Perl уже нет - есть ЕМНИС почти десяток (!!!!) различных вариантов ООП, часть из которых взаимно совместима часть нет.
То есть фактически, в результате такой свободы есть ОДИН язык PHP и есть по крайней мере ЧЕТЫРЕ варианта Perl:
1. устаревший, но по сути уже классический, описанный в книге с верблюдом
2,3 - различные пакеты ООП, такие как class:accessormaker, Class::MethodMaker, Object::InsideOut
4. Moose/Mouse - кстати так даже 5 получается, тк тоже часть народа живет на одном а часть на другом :-/

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

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

>  В.
>  
>  On Wed, 28 Jul 2010 22:52:55 +0300, Sergeev Serge  wrote:
>  
>  > Спасибо за ответы.
>  >
>  > Тут-бы еще услышать точку зрения начальника транспортного отдела (кто  
>  > управляет хостингом) ;)
>  >
>  > Лично у меня соображения такие:
>  > 1. Сейчас каждое приложение имеет собственную аутентификацию, потому что  
>  > каких-либо действительно стандартных решений нет, точнее то что  
>  > действительно стандартно, имеет какие-то очень серьезные недостатки.
>  > Например, в htpasswd нет механизма восстановления забытых паролей и  
>  > изменения пароля, не говоря уже о современных методах аутентификации по  
>  > ключу или одноразовым паролем; практически почти то-же и с  
>  > mod_auth_ldap/mod_auth_mysql..
>  > И хотя написать аутентификацию как правило несложно, но лучше когда есть  
>  > хорошо отлаженный прототип, чтобы было с чего начинать.
>  > Опять-же, встроенная аутентификация позволяет делать какую-то не совсем  
>  > тривиальную логику работы - а тут вот тот-же htpasswd элементарно не  
>  > позволяет сделать операцию logout, тк броузерная basic authentification  
>  > так и не была доведена до продакшен уровня.
>  > 2. СУБД разумно использовать для хранения изменяемой информации, а в  
>  > файлах хранить только то что изменяется очень редко - логику, верстку,  
>  > статическую графику.
>  > Для особо быстрого доступа к изменяемой информации разумно использовать  
>  > различные кэши (memcached).
>  > Да, еще вспомнил: развитые СУБД еще и обычно позволяют сделать какую-то  
>  > часть логики средствами самой СУБД, не трогая исходники приложения, что  
>  > тоже очень полезно.
>  > 3. Использование внешних приложений для важной системной логики тоже  
>  > нехорошо, тк на хостинге этих приложений просто может не быть, и полиси  
>  > хостера имеет все основания не разрешить такие приложения инсталлировать.
>  >
>  > То есть я думаю, что twiki это тру юникс вэй, что вообще говоря мне  
>  > нравится, но я бы такое своим клиентам не стал ставить, тк с ним  
>  > возникает слишком много ненужных вопросов и слишком много ограничений,  
>  > тк такой юникс вэй, насколько я знаю, сейчас крайне мало кто использует  
>  > - сейчас все строится вокруг классической архитектуры, такой как  
>  > например LAMP.
>  >
>  > - Хотя twiki весьма вероятно будет лучше той-же mojowka исполнять наши  
>  > текущие задачи, но я думаю что нужно думать и о пиарной стороне - мы  
>  > ведь это все затеяли для продвижения Perl, и лучше если мы поддержим  
>  > решение, которое лучше масштабируется, проще и быстрее инсталлируется, и  
>  > выглядит правильнее.
>  >
>  > Да, а насчет корпораций, я общался с людьми, хорошо знающими эту  
>  > сторону, так вот там буквально такая картина:
>  > 1. Мелкие капиталисты действительно обычно охотно используют готовые  
>  > решения, и на них сильнее всего действует прямая реклама.
>  > 2. Средние капиталисты нередко охотно платят разработчику удачного  
>  > решения за допиливание решения под их технологии и/или бизнес-процессы,  
>  > и они уже более ориентируются на личные связи.
>  > 3. Крупные капиталисты (корпорации), обычно легко находят внутренние  
>  > ресурсы, чтобы сделать что-то совсем свое с нуля, или самостоятельно  
>  > допиливают под себя практически с любого уровня. И они как правило не  
>  > покупают отдельно например те-же CMS, а покупают "создание и  
>  > обслуживание сайта", которое включает в себя и допиливание и обучение  
>  > людей и все прочее, вплоть до того, что могут ради сайта купить с  
>  > потрохами фирму-разработчика CMS.
>  >
>  > То есть само по себе использование twiki корпорациями, что-то может  
>  > сказать только о популярности собственно Perl, ну и еще о связях  
>  > разработчиков twiki в бизнес-кругах.