Coder must die

[vitus_wagner]

Тут Алексей Печников замучал меня вопросами, почему для StillLife выбрана именно такая архитектура.

Поэтому я решил признаться в своем тайном замысле. Основная цель - убить web-кодера, как профессию.

Первым пристрелочным выстрелом в эту сторону был Communiware. Это был очевидный перелет. Концепция "информационного супа" предложенная для Коммунивера Андреем Акопянцем настолько велика и могуча, что освоить её в совершенстве могут только отдельные гении вроде ailev. Ну и ресурсов тоже кушает будь здоров.

Это не то, что нужно отдельному юзеру.

Поэтому StillLife в значительной мере Communware наоборот. Если в Communiware в базе хранились не только данные, но и программы их представления (шаблоны), то в StillLife базы данных нет вообще, если не считать пары DBM-ок, используемых для аутентификации пользователей.

Если язык шаблонов Communiware был весьма мощным декларативным языком с условными конструкциями, обработкой список и т.д., то в StillLife шаблоны представляют собой обычный html всего лишь с некоторыми предопределенными именами классов.

В общем, классическая попытка взять цель в вилку.

Понятно, что получится недолет. Даже сейчас видны целые классы сайтов, реализация которых на базе концепции StillLife принципиально невозможна, например Internet-магазины. Web-форум - это предел интерактивности, которого можно добиться на базе такой концепции. Именно поэтому разработка StillLife начата именно с форумного движка. Дальнейшее - блоги и средства управления контентом традиционного сайта - будет проще.

Основное, что лежит в основе - антитеза концепции, выдвинутой ailev лет 6-7 назад "Сайт - это программа".
Как раз эта концепция, которая в общем-то в то время носилась в воздухе, приводит к тому, что вокруг WWW кормится армия криворуких кодеров. Раз сайт это программа (при этом каждый сайт - отдельная, уникальная программа), каждому сайту нужен программист. Хороших программистов на все сайты не напасешься, значит большая часть сайтов, в том числе и интересных содержательно, будут написано плохими программистами, а следовательно будут плохими, неудобными для пользователя программами.

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

Примерно в этом направлении сейчас двигаются Google, SixApart и другие подобные крупные сервисы.
Но они - злобные проприетарщики. Хотя сейчас очевидно, что создать хорошее web-приложение без использование OpenSource технологий практически невозможно, они ухитрились обойти GPL посредством исполнения программ только у себя на сайте. Раз пользователь не получает исполняемой копии программы, он не вправе требовать и доступа к исходным текстам, даже если 90% кода - GPL.

Кроме того, решения применяемые LJ, Google и другими крупными сервисныи компаниями в WWW требуют соответствующей аппаратной базы. Именно этим объясняется незначительный успех клонов ЖЖ, базирующихся на его коде. Вербицкий может взять исходники ЖЖ, которые Фитцпатрик честно открыл, но у него нету и не может быть денег для создания датацентра, аналогичного калифорнийскому датацентру ЖЖ. Поэтому Vendor Lock In в классическом виде.

Для полноценной реализации концепции "сайт - это документ", требуется программа обработки этого документа, способная выполняться на любом, доступном пользователю компьютере - будь то shared hosting, будь то домашний компьютер с широкополосным подключением к интернету. Лучше конечно, иметь несколько разных программ, адаптированных к разным средам выполнения, но работающих с одинаковым форматом документа. Именно работающих с одинаковым форматом документа. Поэтому столь распространенные нынче в веб-строительстве РСУБД не годятся. Можно создать схему БД, которая будет работать в mySQL, PostgreSQL и Oracle, но с перетаскиванием её будут некоторые проблемы - потребуются специальные срества импорта/экспорта. Да и работать она будет неэффективно, так как она будет вынуждена на каждом сервере не использовать именно те возможности, которыми он наиболее силён - из-за отсутствия этих возможностей в других серверах, совместимость с которыми поддерживается.

Comments

[metaclass.livejournal.com]

Нутром чую, что все кончится прикручиванием к этому движку модулей доступа к БД, с более-менее обобщенным интерфейсом.
Точно так же, как в документах MSOffice имеются макросы и возможность достучаться до БД, хотя вообще документ по идее должен быть статическим и переносимым, иначе он становится программой, а не документом.

[vitus_wagner]

Да запросто. Если это будет на своем месте (в тех же интернет-магазинах, к примеру) то почему бы и нет.
Тем более что в выбранном инструментарии уже есть обобщенный интерфейс DBI.

Проблема существующих движков не в том, что они используют БД. А в том, что они пытаются распространить на сайт концепцию хранения данных в БД. Вот тут она начинает предъявлять свои требования и налагать свои ограничения, а потом админы хостингов плачут "Вот, яндексбот пришел, сайт за-DoS-ил".
Думаю, что если ко мне на StillLife яндекс-бот в 50 параллельных запросов придет, я и не замечу (разве что канал выжрет).

[metaclass.livejournal.com]

Странно, БД вообще-то в норме должны до сотни запросов на запись в секунду выполнять (мелкое бухгалтерское приложение у меня столько съедает), а уж чтение так и вообще летать должно.
Хотя PHP и MYSQL я в таких условиях не испытывал, но думаю, что для веба оно должно быть еще более производительным, там же количество пользователей формально ничем не ограничено, в отличие от всяких интранетовских клиент-серверных приложений.

[potan.livejournal.com]

Эта проблема может быть решена кешированием на стороне сервера.

[potan.livejournal.com]

Я работал над этой проблемой примерно в коммуниверовские времена (в Доте).
На язык шаблонов я старался наложить строгие ограничения - в частности запрет условных конструкций. Наборы шаблонов объединялись в репозиторий и могли ссылаться друг на друга.
Репозитории могли наследоваться друк от друга. Вместо условных конструкций было предложено условное наследование.
Практика показала, что верстальщики осваивали эту систему очень быстро - примерно за неделю.
Правда, когда я оставил этот проект, он ушел в другую сторону - условное выражение вернулось, а наследование было оставлено только одиночное безусловное. (Хотя оставалась ветка со множественным наследованием.)

Позднее, jsn предложил очень интересное обобщение наследования, но реализовывать его в своей аналогичной системе не стал, ограничелся простым одиночным наследованием.
Я описал его подход здесь.

Из известных мне решений похожий подход применен в Zope. Но множественное наследование там сделано через ж, язык слишком императивен и предлогаемый в те времена стиль кодирования не раскрывал всей мощи подхода. И Python я не слишком люблю.

[taki-net.livejournal.com]

Хосспади. Опять...

От того, что мы переназовем нечто так, чтобы оно называлось не "программой", а "документом", изменится/не изменится вот что:

1. по-прежнему количество людей, способных создать ЭТО с умом - останется малым;

2. по-прежнему будут появляться сайты, сделанные криво, но с разумным наполнением;

3. работодатели испытают очередной приступ восторга о идеи переназвать "веб-кодера" в "веб-секретаршу" и в процессе переназвания вдвое понизить зарплату.

После реализации наиболее вострыми и быстрыми работодателями п.3 почему-то (вот сюрприз!) резко обостряются проблемы 1 и 2:-)))

[vitus_wagner]

1. по-прежнему количество людей, способных создать ЭТО с умом - останется малым;
Важно не количество, а пересечение множества тех, кто способен освоить технологию использования данного инструмента с множеством тех, кто способен создавать разумный контент. У Microsoft с вордом более-менее получилось, а с PowerPoint-ом уже нет.
2. по-прежнему будут появляться сайты, сделанные криво, но с разумным наполнением;
Вопрос в том, что такое "криво". Если понятие "криво" не будет в себя включать "сайт ложится нафиг от перегрузки при появлении ссылки на него на lenta.ru", то это будет уже большой прогресс, по сравнению с существующим состоянием.

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

[ramendik]

Очевидные возможные грабли - развитие по пути PHP. Когда к _документу_ потихоньку добавляются элементы _программы_, а в результате получается система без разделения программы и данных - причём именно там, где классической "архитектуры Фон Неймана" изначально не было и она реально не нужна.

[vitus_wagner]

Да, в Communware я уже на эти грабли наступал, и пробовал три или четыре разных способа борьбы с ними.
Там ни один из них не оказался удачным. Здесь - посмотрим.

[behrk.livejournal.com]

в первом URL отсутствует 'http://'

или наоборот: документ -- это сайт

[behrk.livejournal.com]

Сразу ассоциация: TiddlyWiki.
HTML-документ хранит в себе странички вики, плюс код на JavaScript, который делает то, что обычно ассоциируется с "полновесными" сайтами, использующими БД и application server.

Re: или наоборот: документ -- это сайт

[vitus_wagner]

Да, похожий подход. Но к сожалению, на мой взгляд Wiki в негиковской среде не может иметь большого успеха. И вообще информационная модель Wiki сильно ограничена.
Я тут пробовал использовать TWiki для задачи где существенно важно обсуждение, получалось плохо.

[geomapx.blogspot.com (from livejournal.com)]

Есть простые инструменты - лопата, к примеру. Но людей, _умеющих_ пользоваться этим инструментом, мало. Есть инструменты очень сложные - микроволновка, к примеру. Мало кто понимает, что такое СВЧ-излучение и как оно воздействует на вещество, почти никто не представляет, что происходит с людьми или разными зверушками при интенсивном облучении,... и все радостно пользуются. Сдается мне, речь идет о создании лопаты, которая проста и эффективна, но использование которой требует _обучения_ и _навыка_, в противовес жутким монстрам, которые как-то там работают после нажатия первой же кнопки. Боюсь, что дисциплина ума в западной цивилизации отсутствует в принципе и технологии это не в силах исправить.

[ramendik]

Лично я стремлюсь обсуждать с Витусом варианты развития, ведущие скорее к микроволновке. Или даже к моему любимому инструменту для готовки - slow cooker. Он и очень прост, и одновременно не требует умения пользоваться.

Нагревать до фиксированной не очень большой температуры надолго - это простая техника.

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

На выходе - неплохая еда, рекомендую. Практически эмулятор русской печи, готовка "томлением". Да, это не ультравкусные изыски, но это _просто_ и более чем съедобно. Вот я то же самое для CMS хотел бы :)

Баг репорт

[ramendik]

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

Что я вижу. URL:

http://vitus.wagner.pp.ru/cgi-bin/forum/stilllife/doc/00000170.html?edit=1

Текст:

Тестовый форум Still Life
Произошла неустранимая ошибка
Невозможно редактировать неопознанный объект

Re: Баг репорт

[vitus_wagner]

Это еще не реализованная функциональнось. Точнее реализованная несколько частично. Заглушка процедуры уже написана, поэтому internal server error не происходит. Но вот страница юзеру не выдается, и исполнение проваливается в обработку ошибки когда ничего вывести не удалось.

[os80.livejournal.com]

Убить бы ещё профессию Debian Linux-админа...

[vitus_wagner]

Над этим я тоже думал. Но это сложнее. Это надо вселить в машину бессмертную душу наделить операционную систему инстинктом самосохранения.

Вопрос

[ramendik]

Я постил тему про багрепорт и запрос фичи.

Теперь не могу её найти. То ли ты её удалил, то ли я не помню где она.

Во-первых, таки удалил или нет?

Во-вторых, мне вот _уже_ не хватает "найти все постинги юзера". В данном случае юзер - это я сам. Я не могу всегда помнить, что куда написал.

Re: Вопрос

[ramendik]

Нашёл на верхней странице :) Первый вопрос снят, про поиск осталось. Также предлагаю создать подфорум "сообщения о проблемах и запросы возможностей".

А вот теперь я совсем ничего не понимаю

[ramendik]

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

Re: Вопрос

[ramendik]

Снова нашёлся. Странно. Я буду ещё проверять

О БД и криворуких кодерах

[(Anonymous)]

Vitus, поскольку я уже интересовался Stilllife, хочу высказать сугубое imho на тему "движков сайтов" вообще, причем, на мой взгляд, мнение в общем-то тривиальное.

Потребность в том или ином способе хранения данных ( строго-табличный или свободно-текстовый; внутри приложения типа "сервер" или отдельными файлами на файловой системе ) определяется характером этих данных и сценариями их использования.

То есть, действительно, при наличии "строгих" и сильно друг с другом связанных наборов "букв и цифр", при том, что букв и цифр много, а собственно html-документов мало ( интернет-магазин, интернет-банк и т. п. )
вполне естественно сочетание БД+server-side-scripting.

При наличии слабо связанных "данных" в более-менее свободном формате, естественно, статичные HTML-файлы правильнее и эффективнее.

Это суть два инструмента для двух разных задач. Однако, существует "серая" зона", где сочетаются "свободные тексты", их какая-то "каталогизация", и - не последнее по значимости - различные виды отображения этих текстов
( различные ВЫБОРКИ документов по метаданным, различные отображения - скажем, текст целиком, или только заголовок, или еще как-то, и различные стили оформления ) Т. е. форумы, всякие wiki, и т. п.

В принципе, если бы я делал такой сайт, или движок к сайту, то я бы постарался весь ТЕКСТ держать именно как текстовые файлы, а не совал бы его в базу. Скажем, для того, чтобы этим проще было управлять, и можно было бы иметь доступ к конкретным документам, даже если все остальное сломалось.
Но представляется сложным поддерживать метаданные об этих документах ( кто написал, когда, зачем, в ответ на что, актуально, неактуально, рейтинг, ссылки и т. д. ) без какого-то рода БД.

Подозреваю, что если полностью реализовывать концепцию "сайт-это документ", то в итоге, наверное, получится "Client-side Content Management Engine", нечто вроде сочетания Web-редактора, публикатора, и (!) своего, внутреннего каталога в виде БД. Эдакий MS FontPage+База+HTTP server extensions. При этом принципиальное отличие будет в том, что вся связность и целостность поддерживается локально, а на сайт выгружаются скорее не отдельные страницы, а блоки страниц, которые генерятся заново после изменения какой-то одной. ( В принципе, ничто не мешает представить одну большую кнопку "выгрузить сайт" и решать все глюки на хосте методом вытирания и создания всей файловой структуры заново )

Только почему-то кажется, что такая штука окажется намного тяжелее проблемы.

Re: О БД и криворуких кодерах

[vitus_wagner]

Проблема заключается на самом деле в том, что если у тебя есть молоток, любую задачу ты рассматриваешь как гвоздь. Современное поколение web-кодеров было выращено программистами in-house корпоративных информационных систем. Там базы данных были на месте - еще со времен Кобола и Codasil. И эти люди, которые ничего кроме БД не умели, пришли с этим умением в Web, когда он возникал. И уже вырастили следующее поколение, которое убеждено что web-сайт - это база данных.

Вот разработчики WebDAV (тех самых HTTP server extensions) думали в более другой парадигме. Поэтому DAV сейчас настолько малопопулярен - его готовить не умеют.
Впрочем, в рамках парадигмы файловой системы и файловых операций существует уйма других способов выгрузить контент на сайт - ftp, sftp, rsync. Если БД у нас yet another файл (что возможно c Berkeley DB или SQLite) то нет никаких проблем кэши метаинформации синхронизировать по тем же протоколам.

Вот только убеждение что метаданные нужно обязательно хранить отдельно мне представляется вредным. XML/SGML - достаточно структурированный формат, чтобы с ним можно было работать.

[shadow-aka-hf.livejournal.com]

Есть такое Perspective Wiki, безотносительно технологии, там достаточно любопытная архитектура.
Все данные складываются в виде файлов в определенный каталог, каталог регулярно индексируется, и на его основе строится статический сайт.