Брызги сознания

 

Тема: СУКи

Закон Головача о СУКах

Все хорошие СУКи выглядят по-разному, все плохие СУКи — одинаково.

20.04.04 | Комментариев: 2

CityDesk

Сверстал для общего развития сайт в CityDesk. Выводы:

1. UT8 — штука хорошая. Надо на неё переходить массовидным порядком. Важно: эксперимент показал, что отечественный хостер жизни не мыслит без того чтобы настроить Апач на выдачу в заголовке кодировки Windows-1251. Лечится это, правда, легко.

2. Даже такой дикой СУКой можно сделать много хорошего. Если бы по мощности макроязык CityDesk сравнялся, к примеру, с MT, вообще наступила бы эра всеобщего счастья.

Особенности CityDesk, которые нужно учитывать при разработке:

1. Синтаксис ограничений (всякие И, ИЛИ, НЕ) просто ужасен. Насколько я понимаю, там при каждом новом условии количество скобок в строке увеличивается больше, чем вдвое.

2. А вот настройка вывода списков очень симпатична. Я даже не знаю, что там еще можно захотеть.

3. Нельзя автоматически сделать многоуровневый список. Вообще.

4. Встроенный редактор HTML очень убогонький. WYSYWIG убог и портит разметку, так что лучше бы его вовсе не было.

5. Нет таблиц.

6. Сослаться автоматически можно только на файл, а не на каталог. От этого фактически невозможно скрывать файлы из строки адреса, как я очень люблю.

7. Ключевые слова есть, но нет главного: автоматического построения списка статей, у который ключевые слова совпадают с набором текущей статьи.

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

9. В некоторые поля можно вводить только текст, в некоторые — HTML. Проблема в том, что нет никакой индикации, куда что можно вводить, и, что еще хуже, в HTML-полях невозможно переключиться на редактирование кода. Т.е. на практике HTML в полях не бывает.

10. Смешно — в редакторе нету заголовков.

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

07.11.03 | Комментариев: 1

Опять СУКи

Ещё два текста про СУКи: раз (ссылка уже не работает, см. ниже) и два.

Оба текста вызывают определенное отторжение (проведем по ведомству интеллектуального спора). По поводу первого текста:

Суммируя всё вышесказанное: я считаю, что т.н. Content Management Systems не (достаточно) эффективны. Именно поиском эффективности обусловлено их развитие.

Исключительной глубины мысль. Зияющие вершины.

Действительную эффективность веб-сайту приносит грамотный ИАрхитектор…

Я, хоть и кормлюсь с интерфейсов, не нахожу в себе силы сказать, что интерфейсы — это самое главное (или, тем паче, единственное). Вижу, знаете ли, и другие метрики. А вот оппонент не видит, что удивительно.

…права пользователя…

Никто и никогда не мог (доселе) доказать мне, что права пользователя есть вещь, достойная включения в мой активный лексикон. Ну да, я знаю, что лучший способ не дать пользователю сделать ошибку, заключается в том, чтобы не дать ему возможности её совершить. Я регулярно пользуюсь этим методом. Но причины думать о правах пользователя я не вижу. На мой взгляд, разброска прав это естественное действие того же порядка, что и, к примеру, дыхание — все постоянно это делают, но говорят об этом крайне редко.

…необходимость IA для нормального проекта, как и необходимость UID, я думаю, объяснять не нужно…

Поскольку никто не знает, что такое IA (или, во всяком случае, не могут договориться между собой о точном значении этого термина), зато все знают, что т.н. “нормального проекта” со времен Платона в принципе не существует, то да, совершенно не нужно. Кстати, что такое UID? Unique Identificator?

По поводу второго текста:

Возможно, что сайтом должна управлять система, самостоятельно мыслящая и питающаяся информацией, а не питаемая ею.

Существует любопытная теория, будто бы мысли сильно формируются их носителем (Medium is Message). Т.е. все мысли человека имеют две ноги, две руки, два глаза, два уха, сфинктер, головогрудь и ступни — а не замечаем мы это только потому, что иных мыслей мы никогда и не думали. В этом смысле приведенный выше тезис имеет существенный недостаток: самостоятельная (по мере сил) система действительно имеется, но предлагать этой системе питаться информацией я не советую — система очень уважает наваристый борщ (триумф энтропии, если разобраться) и на предложение может обидеться.

В остальном второй текст (в общем и целом) верен (особенно тезис номер 3).

И последнее. Товарищи, ну зачем же так наукообразно писать? Будьте проще и люди к вам потянутся…


Обновление: Не выдержав когнитивного диссонанса, учитель Манучаров тоже вступил в дискуссию. В результате акценты сместились на обсуждение вопроса о том, верно ли утверждение что У мудацкой компании немудацкого сайта быть не может (как и учителю Манучарову, мне кажется, что тут двух мнений быть не может: из говна легко можно сделать конфетку, но конфетка — вот незадача — получится из говна). Дискуссия стала столько поэтичной, что тов. Медуза ея вынул из открытого просмотра (как и породивший её текст) и правильно сделал, поскольку держать черновики в открытом доступе по меньшей мере некультурно. Выдержки из дискуссии выложены учителем Манучаровым у себя, настоятельно рекомендую всем их прочитать.

Мораль всего этого проста. Хватит молча смотреть на голого короля. Пользователь ЖЖ moedusa — обычный дурак. Не мудак, не идиот, не дебил, не придурок. Просто — глупый и эмоционально незрелый человек.

21.07.03 | Комментариев: 7

10 тезисов о СУКах

Поскольку писать связный текст лениво, а спрос есть, вот несколько отдельных мыслей по теме:

1. Нет идеального СУКа. Нет же у нас идеальной верстальной системы. Под разные цели и разных пользователей нужны разные системы.

2. Только тот СУК будет успешен, который сделан под конкретную целевую аудиторию и конкретный тип сайтов. Интересная, кстати, задача, сделать классификацию сайтов…

3. Сложные, но мощные СУКи уже есть. Например, Frontier. Простые неспециализированные тоже есть. Причем, есть давно, так что можно рассчитывать, что в них всё уже есть и всё, что есть, работает хорошо. Значит, бесполезно делать мощные и сложные или простые неспециализированные СУКи. Нужно делать простые, дешевые и крайне специализированные системы.

4. Очень многое упирается в технические подробности. Техническая подробность — это всё, что нужно знать для успешной деятельности, но отчего можно было бы безболезненно отказаться. Характернейший пример техподробности — различие между строчными и прописными в Юниксе. Чем больше технических подробностей — тем хуже система, поскольку изучение этих подробностей, по делу, имеет нулевой КПД.

5. Идеальная база данных для большинства СУКов — обычная файловая система (вы не забыли, надеюсь, что файловая система это тоже бататаза?). Во-первых, она не ограничивает пользователя в средствах редактирования, во-вторых, она обладает минимумом техподробностей.

6. Динамический сайт не ценен сам по себе. А статический сайт дешевле в эксплуатации (для него подходит даже самый дурной хостинг) и малочувствителен к атакам кулхацкеров (ну, залезли, ну и что? обновил файло и все опять путём). Про скорость и не говорю.

7. Некоторые сайты, действительно, не удастся сделать статическими. Но большинство сайтов могут быть сделаны статическими или полустатическими. Этот блог, например, полностью статический (как и все блоги на MT).

8. СУК, работающий на сервере, всем хорош, но неизбежно отягощен техподробностями, кроме того, отладка такого СУКа нелегка. Проблема решаема (в поставку СУКа можно впендюрить нечто вроде Денвера, чтобы пользователь работал локально, время от времени обновляя данные на сервере, а уж сервер сам обновлял статику). Но зачем её решать? Большинство сайтов обновляются редко или очень редко. Прекрасно подходит и обычное обновление контента через FTP. В особенности, автоматическое.

9. СУК — это шаблонирование и построение оглавлений. Не более.

10. Шаблонирование уже есть везде, в особенности в Дримвивере. Значит, нужно сфокусироваться на построении оглавлений (если мы не будем отличаться, нас не будет вовсе).

30.05.03 | Комментариев: 8

К вопросу о СУКах

Я планировал написать большой текст о системах управления контентом, но, написав введение, утомился. Не верится, что это кому-то нужно. Однако если я не прав, вот наводка: я знаю, как сделать два разных, технически простых и дешёвых в производстве СУКа, которые имеют свои рынки и которые можно продавать за деньги. Если интересуетесь, за 100 баков сообщу детали о любом из них.

Когда веб только начал(а) свой(е) победное шествие, страницы делались в Ноутпаде. Потом появились специализированные редакторы, вроде BBEdit. Потом появились редакторы визуальные, поначалу фантастически убогие (так, на Vermeer Frontpage, потом зачем-то купленной MS, без слез нельзя было смотреть — а ведь она была лучшей!), но затем здорово улучшившиеся (пример — Dreamweawer). Перед нами отчетливый пример эволюции, предсказанной ещё Дарвином.

СУКи, напротив, до сих пор Дарвина опровергают. История их развития пошла по совершенно другому пути.

Технически, все просто. У нас есть массив информации, и для этого массива нужен аппарат поиска и механизм редактирования этого массива. Рассмотрим, в качестве примера, книгу.

Книга есть массив информации. У этого массива есть аппарат поиска, называемый книжным аппаратом, в который входят оглавления, предметные указатели, номера страниц, собственно структура книги. Все это придумано очень давно и вполне стандартизировано: все оглавления выглядят по-разному, но работают одинаково (и, что немаловажно, любой человек, глядя на оглавление, сразу видит, что это оглавление). В результате, все системы подготовки книг обладают примерно одинаковыми возможностями: у кого-то их меньше, у кого-то больше, но различия сугубо количественные, а не качественные. Кроме того, для книги нужен механизм редактирования её содержимого (сюда входит и верстка). Здесь, наоборот, полный разнобой: есть Quark, есть PM и InDesign, есть FM, есть TeX и Ventura, есть, наконец, DocBook. Все это разнообразие объясняется двумя факторами: во-первых, работа по модификации содержимого занимает львиную долю времени работы над книгой, так что здесь уместны личные вкусовые предпочтения, во-вторых, книги разные, так что им нужно разное оформление, оформление же есть функция от самой программы (некоторые вещи удобно, грубо говоря, делать в FM, другие — в InDesign).

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

Объясняется это несколькими причинами:

  • Ажиотаж, вызванный интернет-бумом, не способствовал желанию продавать СУКи (достаточно было просто кричать о своем СУКе на всех углах, чтобы распродать акции, например, в тучные годы в Documentum не было сейла, к счастью, они успели опомниться раньше других). Там, где нет продаж, нет качества.
  • Системы делали программисты, а программисты по своей природе не склонны делать сколько-нибудь полезные системы (предпочитают делать системы интересные лично им, уж такие они люди).
  • Все СУКИ выросли из заказных систем, разработанных для конкретного клиента и потом по мере сил адаптированных для универсального использования. “По мере сил” обозначает, что многие СУКи до сих до(пере)писываются для каждого нового клиента.
  • Никто из разрабочиков СУКов никогда не задумывался о техническом КПД своих творений. Средний СУК требует сервера, достаточного для полной автоматизации большого автомобильного завода и стоит больше, чем ручная работа нескольких человек в течение пары лет. Малопонятно, как среднестатистический СУК может окупиться.

Главной же проблемой СУКов является не это, а ошибка в направлении их действия. СУКи продавались и продаются до сих пор под лозунгами “сделаем обновление материалов простым для каждого” и “нет ничего лучше обновления через браузер”. На самом деле это бесполезно, поскольку, как было сказано выше, сделать хороший универсальный редактор невозможно. Но главное, зачем делать “обновление материалов простым для каждого”? Какой смысл подпускать к сайту неквалифицированного идиота? Чтобы он там ошибок понаставил? Хороший сайт может получиться только в том случае, если над ним работает по крайней мере не идиот. Не идиот, в свою очередь, может не только научиться какой-либо системе редактирования, но даже и выбрать её себе по вкусу. Обновление же через браузер убого потому, что подразумевает убогий интерфейс. Кто бы что ни говорил, но сколько-нибудь сложный, ориентированный на документы, и к тому же работающий в браузере интерфейс является на данный момент несбыточной мечтой.

Но самое интересное, что лозунги про простое для каждого обновление и про обновление через браузер на самом деле маскируют настоящую причину для использования СУК. СУК нужен для удешевления производства и обновления сайта. Ключевое слово здесь - удешевление. СУКи к этому не готовы, поскольку давным-давно делаются под другими лозунгами (см. выше).

29.05.03 | Комментариев: 7

 

 
 
 
 
 
 
 

По темам:

Movable Type

А вы знаете, что

Велосипед

Декларации

Дизайн

Дневник наблюдений

Есть идея!

Жаль выкидывать

Идиоты первыми

Интерфейс

Интерфейс — делаю так

Интерфейс — документации

Интерфейс — казусы

Интерфейс — плохой

Интерфейс — спросите доктора Акопяна

Интерфейс — терминология

Интерфейс — хороший

Личное

Музыка

Названия

Объекты реальности

Поисковые запросы

Размышления

СУКи

Спонтанный русский язык

Ссылки

Типа девушки

Цитаты

Это Россия, сынок

Это случилось со мной

 
 

Вы будете смеяться, но всё, что есть на этом сайте (если не указано обратное) создано Владом В. Головачом, простым ховринским либертеном, и этот либертен страшно не любит, когда у него воруют интил­лик­дуаль­ную соб­ствен­ность; не воруйте её и Влад В. Головач будет вас любить и (если вы не мальчик) даже поцелует.