Re: Re: Re: Re: Проект "Perl Certified Hosting"
Vladimir Vasilenko
jeltoesolnce at aol.com
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/
More information about the Kiev-pm
mailing list