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 имеются макросы и возможность достучаться до БД, хотя вообще документ по идее должен быть статическим и переносимым, иначе он становится программой, а не документом.

[potan.livejournal.com]

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

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

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

[taki-net.livejournal.com]

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

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

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

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

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

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

[ramendik]

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

[behrk.livejournal.com]

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

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

[behrk.livejournal.com]

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

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

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

Баг репорт

[ramendik]

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

Что я вижу. URL:

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

Текст:

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

[os80.livejournal.com]

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

Вопрос

[ramendik]

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

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

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

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

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

[(Anonymous)]

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

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

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

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

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

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

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

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

[shadow-aka-hf.livejournal.com]

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