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

Thu Jul 29 00:10:51 PDT 2010

А глобальная идея "Откуда будут деньги" уже прозвучала?

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

Мне импонирует 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 в простоте и интегрированным средствам в "легкоте", и фразу "проще и  
бытрее" я бы вычеркнул из лексикона на какое-то время точно:-).

В.

On Wed, 28 Jul 2010 22:52:55 +0300, Sergeev Serge <simne at yandex.ru> 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 в бизнес-кругах.
>
> 28.07.10, 11:35, "Sergii Biloshytskyi" <alariq at gmail.com>:
>> попытаюсь ответить на все по порядку: (см. коменты ниже)
>>
>>  2010/7/28 Sergeev Serge :
>>  > Вы могли-бы написать кратенькую характеристику twiki?
>>  >
>>  > Я честно, еще не смотрел код, но читая документацию, мне уже не  
>> нравятся такие вещи:
>>  > 1. Я не понял, чем они обрабатывают шаблоны? - Ну не понимаю я, как  
>> сейчас может быть серьезная система без шаблонизатора.
>>
>>  честно не могу сказать, не смотрел, но по списку необходимых модулей
>>  таких нет. Хотя Customize Look and Feel стоит у них в мейн фичерсах.
>>
>>  > 2. Они что, работают с статикой? - Нигде не вижу упоминания  
>> подключения к СУБД, но постоянно упоминаются какие-то загадочные  
>> решения, вроде некоторой странички, на которой полный актуальный список  
>> всех зарегистрированных пользователей, и также аналогичная страничка,  
>> где лежат настройки..
>>
>>  для документов у них применяется обычная система контроля версий. все
>>  хранится в файлах, как я понял.
>>  настройки все в конфиге - могуте менятся через веб (страничку). с
>>  пользователями аналогично. пользователи не хранятся в базе скорее
>>  всего потому, что у них куча разных методов аутентификации и зачем
>>  дублировать например существующих пользователей домена у себя?
>>  вообще только что глянул - нету для twiki базы у меня в MySQL :-)
>>
>>  > Также меня очень настораживает предложение использовать для  
>> аутентификации htpasswd, mod_auth, mod_auth_mysql..
>>  > Честно сказать, это ОЧЕНЬ достойные инструменты, а скажем там-же  
>> упоминаемый mod_auth_ldap это вообще по нынешним временам считается не  
>> просто круто, а суперкруто, но я не представляю, как я буду на простом  
>> обычном хостинге с этим всем упражняться..
>>
>>  я использовал, разные методы, все работали, сейчас использую
>>  mod_auth_ldap чтобы не заставлять существующих юзверей Юби
>>  регистрироваться.
>>
>>  > Кстати, как раз на прошлой неделе общался с знакомым админом, и он в  
>> выражениях рассказывал, как одна всем известная корпорация хорошо  
>> соблюдает стандарты, что такие вещи как та-же аутентификация через  
>> ldap, которая казалось-бы должна идеально работать, в реальной жизни  
>> работает далеко не идеально..
>>  >
>>  > Плюс, возвращаясь к нашим животным, я вот например собираюсь делать  
>> контент не только для десктопов (ноутбуков), но также и для разных  
>> мобильных устройств, и также я хочу использовать эти-же освоенные  
>> технологии и для связи с всяческими (условно)  
>> холодильниками/микроволновками/стиральными машинами (например, отдавать  
>> им через какой-нить SOAP рецепты и режимы хранения продуктов, и также  
>> режимы стирки).
>>  > И я честно говоря не вижу применения для того что я изучу в twiki, а  
>> вот Catalyst/Mojo как раз точно включают в себя инструменты для таких  
>> работ, и допилив ту-же Mojowka я уже буду значительно ближе к созданию  
>> контента для устройств с ограниченными возможностями.
>>  >
>>
>>  здесь ничего сказать немогу. Я вообще программист, это так в свободное
>>  от работы время поставил, поэтому руководствуюсь чисто личными
>>  впечатлениями. Хотя судя по тому каки корпорации используют твики -
>>  система должна быть достаточно гибкой.
>>
>>  А да еще она на перле :)
>>
>>  а по поводу: "Дело в том, что UbiSoft серьезная контора, а им нужно
>>  серьезное решение:)))"
>>  Серега, ты не прав :) Я ни у кого не спрашивал, когда выбирал это
>>  решение просто выбрал, которое мне понравилось.
>>
>>
>>
>>  > 27.07.10, 21:33, "Sergii Biloshytskyi" :
>>  >> могу еще посоветовать твики, установил у себя на работе, доволен. Я
>>  >>  его у себя на ЖЖ описал http://alariq.livejournal.com/19080.html
>>  >>
>>  >>  2010/7/27 Sergeev Serge :
>>  >>  > По наводке vti попробовал mojowka.
>>  >>  > http://github.com/shoorick/mojowka
>>  >>  >
>>  >>  > Вобщем мне понравилось - очень легкое и простое.
>>  >>  > Требования, из того чего у меня не было - только sqlite,  
>> Text::Textile.
>>  >>  >
>>  >>  > Но есть нюансы, которые, думаю, важно допилить, если хотим его  
>> серьезно использовать:
>>  >>  > 1. работает на sqlite (в принципе во всей системе всего 11  
>> запросов, то есть их переделать на тот-же mysql, займет несколько часов  
>> неспешно, но думаю было-бы неплохо на будущее перевести проект на DBIC).
>>  >>  > 2. нет элементарного добавления пользователя и изменения пароля  
>> (все это делается прямо через консоль SQL).
>>  >>  >
>>  >>  > И также желательно:
>>  >>  > 1. сделать diff логи, кто, чего и когда изменял
>>  >>  > 2. сделать быстрый (индексированный) полнотекстовый поиск -  
>> вообще в mojowka есть поиск, но только по названиям страниц.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/