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

Wed Jul 28 12:52:55 PDT 2010

Спасибо за ответы.

Тут-бы еще услышать точку зрения начальника транспортного отдела (кто управляет хостингом) ;)

Лично у меня соображения такие:
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 есть поиск, но только по названиям страниц.