(no subject)
Tuesday, March 15th, 2005 02:05![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kastanedaЯ тут недавно закинул ссылку на интересную статью о том, как погано жить в теге <textarea>. Теперь — вторая серия: почему я считаю веб-приложения редкостной гадостью. По крайней мере, я говорю о CMS.
Нет, это на самом деле смешно. Я — веб-разработчик, последние пять лет только то и делаю, что веб-приложения. И даже с голоду не сдох. Я занимаюсь делом, которое мне нравится, чёрт возмьи! И всё равно я не люблю веб-приложения.
И вот почему.
World Wide Web — это… Ну, все знают, гипертекстовая среда. То есть, текст и ссылки, из которых всё выросло. Картинки, CSS, Flash являются довеском к.
Сеть динамична из-за децентрализованности. Сегодня где-то сервер упал, а где-то какой-то newbie выложил свою домашнюю страничку. Мне не надо даже пальцем шевелить, чтобы в сети произошло что-то: там всегда что-то происходит. Парадокс: сеть, состоящая из одних лишь статических (!) страниц и связей между ними, может быть чертовски динамичной, даже без Google и форумов. На самом деле парадокса нет, каждый статический файл может быть изменён владельцем, вот и всё.
HTML-формы понадобились. Просто понадобились сети на самой заре рождения веба, и появились ещё в HTML 2.0 (что было до того — просто не знаю). Без форм почти невозможна интерактивность (Flash и XMLHttpRequest в те времена ещё не родились). С помощью форм можно вбить свой запрос «mp3 xxx download халява crack» на ближайшей поисковой машине и надеяться на какой-то результат.
Можно зайти на web-mail из интернет-кафе и почитать свою почту. А можно даже написать. Круто! Несколько лет эволюции — и целые армии контент-менеджеров вбивают прайс-листы при помощи веб-интерфейса CMS с WYSIWYG-редактором, который они не знают, как отключить…
Стоп!
Где-то тут вкралась чудовищная ошибка планетарного масштаба.
Скажите, лично вы что предпочитаете — настроить почтовую программу или посещать сайт какого-то web-mail'а? Я уверен, что большинство из вас пользуется отдельно стоящей программой (ну, кроме фанатов Gmail'а, постоянно едущих куда-то автостопом). В этом есть очень простой смысл: как правило, специализированное решение круче универсального, когда оно существует. Исключения пока трогать не будем.
С помощью связки PHP+MySQL можно штамповать сложные решения «на потоке», особенно — если вкурить, втянуться в процесс и войти в ритм. Даже отсутствие RAD, как в ASP.NET, не мешает. Вопрос лишь в целесообразности. Итак, когда веб-приложения целесообразнее, чем традиционные «десктопные»? Ну, допустим, для примера:
А теперь возьмём какого-нибудь менеджера, отберём у него Excel и вручим ему веб-приложение. Либо отберём у дизайнера PhotoShop, и предложим отныне и навеки делать гамма-коррекцию, crop и resize какой-то приблудой на Flash'е. Есть желающие провести эксперимент? Вывод: надо десять раз подумать, вызвесить все pro и contra, и только тогда принять решение о разработке какого-то одного интерфейса (либо дублирующегося, как это у многих free mail).
Итак, к чему мы вернулись? К контент-менеджерам и веб-приложениям. Веб-студии надо делать много дешёвых сайтов, а многие заказчики терпеть не могут таких слов, как HTML, FTP, SQL и многих других. Зато заказчикам нравится, когда можно сделать copy-paste из Word'а. В результате рождается web-based клон FrontPage, основная задача которого — пудрить мозги заказчику. Побочная задача — якобы облегчить труд разработчиков той самой веб-студии. Обе задачи не выполняются. Пудрить мозги заказчику удаётся только до того момента, как сайт сталкивается с суровой реальностью. Об этом даже говорить не хочется, все и так насмотрелись.
Вторая задача — унифицировать всё и вся, хотя бы, до уровня русского народного метода copy-paste в разработке. Весь контент лежит в базе. Структура базы данных годится «для всего и ничего», потому что разрабатывалась не под специальные задачи, а под общие. В общем, и здесь полный бред. Тоже говорить не хочется.
А теперь — небольшой «ракурс» в историю. Когда не было веба и веб-приложений, средний unix-админ прекрасно обходился без веб-почты. Достаточно пойти telnet'ом (теперь только ssh) на хост, стоящий чёрт-знает-где, и запустить pine (теперь лучше mutt). Ничего не напоминает? И ходить можно откуда угодно, и настраивать на стороне клиента ничего не надо; отличается только среда. HTML+HTTP versus VT-100.
Стоп.
Меня сейчас начнут обвинять в том, что я предлагаю хранить данные только в текстовых файлах, которые заливать только по ftp или набирать в vim'е руками… Нет, ничего подобного. Я слишком уважаю database-driven сайты. Я просто предлагаю сменить среду.
Спроектируем хорошую, семантически выверенную БД для нашего сайта. Получилось? У нас новости, каталог товаров и форум перестали смешиваться в нечто аморфное? Отлично. Писать код, который работает с такими данными, интересно и не сложно. А теперь стоит десять раз подумать, а нафига нам вообще интерфейс администратора к этому сайту? Мы ведь сделали уникальный продукт (а не использовали типовой CMS), пользователь у нас всего один, так не лучше ли присмотреться к нему повнимательнее? Так ли часто нам надо обновлять прайс-листы из интренет-кафе?
Я тут дохрена текста написал. Вроде бы всё разжевал довольно подробно. Сложите два плюс два. Вспомните, что с Access'ом офисный народ вполне умеет управляться. Вспомните о том, что я — за правильную семантику БД. Вспомните о специализированных решениях.
Догадались? То, что нам нужно для публикации контента, называется database front-end. Для того же MySQL их существует немало. Меньше, чем почтовых клиентов, но значитально больше, чем броузеров с поддержкой JavaScript'а.
Нужно ли развивать такую мысль дальше? Вывод: проще, дешевле, удобнее и правильнее заменить 95% «админки» среднестатистического сайта на что-то подобное. Оставшиеся 5% будут, скорее всего, просмотром статистики и модерацией форума. Впрочем, с интересом выслушаю и другие мнения.
Нет, это на самом деле смешно. Я — веб-разработчик, последние пять лет только то и делаю, что веб-приложения. И даже с голоду не сдох. Я занимаюсь делом, которое мне нравится, чёрт возмьи! И всё равно я не люблю веб-приложения.
И вот почему.
World Wide Web — это… Ну, все знают, гипертекстовая среда. То есть, текст и ссылки, из которых всё выросло. Картинки, CSS, Flash являются довеском к.
Сеть динамична из-за децентрализованности. Сегодня где-то сервер упал, а где-то какой-то newbie выложил свою домашнюю страничку. Мне не надо даже пальцем шевелить, чтобы в сети произошло что-то: там всегда что-то происходит. Парадокс: сеть, состоящая из одних лишь статических (!) страниц и связей между ними, может быть чертовски динамичной, даже без Google и форумов. На самом деле парадокса нет, каждый статический файл может быть изменён владельцем, вот и всё.
HTML-формы понадобились. Просто понадобились сети на самой заре рождения веба, и появились ещё в HTML 2.0 (что было до того — просто не знаю). Без форм почти невозможна интерактивность (Flash и XMLHttpRequest в те времена ещё не родились). С помощью форм можно вбить свой запрос «mp3 xxx download халява crack» на ближайшей поисковой машине и надеяться на какой-то результат.
Можно зайти на web-mail из интернет-кафе и почитать свою почту. А можно даже написать. Круто! Несколько лет эволюции — и целые армии контент-менеджеров вбивают прайс-листы при помощи веб-интерфейса CMS с WYSIWYG-редактором, который они не знают, как отключить…
Стоп!
Где-то тут вкралась чудовищная ошибка планетарного масштаба.
Скажите, лично вы что предпочитаете — настроить почтовую программу или посещать сайт какого-то web-mail'а? Я уверен, что большинство из вас пользуется отдельно стоящей программой (ну, кроме фанатов Gmail'а, постоянно едущих куда-то автостопом). В этом есть очень простой смысл: как правило, специализированное решение круче универсального, когда оно существует. Исключения пока трогать не будем.
С помощью связки PHP+MySQL можно штамповать сложные решения «на потоке», особенно — если вкурить, втянуться в процесс и войти в ритм. Даже отсутствие RAD, как в ASP.NET, не мешает. Вопрос лишь в целесообразности. Итак, когда веб-приложения целесообразнее, чем традиционные «десктопные»? Ну, допустим, для примера:
- когда пользователю читать надо много, а писать мало
- когда все наши данные — текстовые
- когда бизнес-логика сложная и запутанная
- когда наши сотрудники находятся чёрт знает где
А теперь возьмём какого-нибудь менеджера, отберём у него Excel и вручим ему веб-приложение. Либо отберём у дизайнера PhotoShop, и предложим отныне и навеки делать гамма-коррекцию, crop и resize какой-то приблудой на Flash'е. Есть желающие провести эксперимент? Вывод: надо десять раз подумать, вызвесить все pro и contra, и только тогда принять решение о разработке какого-то одного интерфейса (либо дублирующегося, как это у многих free mail).
Итак, к чему мы вернулись? К контент-менеджерам и веб-приложениям. Веб-студии надо делать много дешёвых сайтов, а многие заказчики терпеть не могут таких слов, как HTML, FTP, SQL и многих других. Зато заказчикам нравится, когда можно сделать copy-paste из Word'а. В результате рождается web-based клон FrontPage, основная задача которого — пудрить мозги заказчику. Побочная задача — якобы облегчить труд разработчиков той самой веб-студии. Обе задачи не выполняются. Пудрить мозги заказчику удаётся только до того момента, как сайт сталкивается с суровой реальностью. Об этом даже говорить не хочется, все и так насмотрелись.
Вторая задача — унифицировать всё и вся, хотя бы, до уровня русского народного метода copy-paste в разработке. Весь контент лежит в базе. Структура базы данных годится «для всего и ничего», потому что разрабатывалась не под специальные задачи, а под общие. В общем, и здесь полный бред. Тоже говорить не хочется.
А теперь — небольшой «ракурс» в историю. Когда не было веба и веб-приложений, средний unix-админ прекрасно обходился без веб-почты. Достаточно пойти telnet'ом (теперь только ssh) на хост, стоящий чёрт-знает-где, и запустить pine (теперь лучше mutt). Ничего не напоминает? И ходить можно откуда угодно, и настраивать на стороне клиента ничего не надо; отличается только среда. HTML+HTTP versus VT-100.
Стоп.
Меня сейчас начнут обвинять в том, что я предлагаю хранить данные только в текстовых файлах, которые заливать только по ftp или набирать в vim'е руками… Нет, ничего подобного. Я слишком уважаю database-driven сайты. Я просто предлагаю сменить среду.
Спроектируем хорошую, семантически выверенную БД для нашего сайта. Получилось? У нас новости, каталог товаров и форум перестали смешиваться в нечто аморфное? Отлично. Писать код, который работает с такими данными, интересно и не сложно. А теперь стоит десять раз подумать, а нафига нам вообще интерфейс администратора к этому сайту? Мы ведь сделали уникальный продукт (а не использовали типовой CMS), пользователь у нас всего один, так не лучше ли присмотреться к нему повнимательнее? Так ли часто нам надо обновлять прайс-листы из интренет-кафе?
Я тут дохрена текста написал. Вроде бы всё разжевал довольно подробно. Сложите два плюс два. Вспомните, что с Access'ом офисный народ вполне умеет управляться. Вспомните о том, что я — за правильную семантику БД. Вспомните о специализированных решениях.
Догадались? То, что нам нужно для публикации контента, называется database front-end. Для того же MySQL их существует немало. Меньше, чем почтовых клиентов, но значитально больше, чем броузеров с поддержкой JavaScript'а.
Нужно ли развивать такую мысль дальше? Вывод: проще, дешевле, удобнее и правильнее заменить 95% «админки» среднестатистического сайта на что-то подобное. Оставшиеся 5% будут, скорее всего, просмотром статистики и модерацией форума. Впрочем, с интересом выслушаю и другие мнения.
no subject
Date: Tuesday, March 15th, 2005 02:21 am (UTC)Нет, я серьёзно.
У меня подавляющее большинство клиентов и их контентов ХОТЯТ, топают ножками и настаивают на том, чтобы к каждому разделу чего-там-редактировать на сайте была отдельная ссылочка. Плевать они хотели на структуры данных - не поймут, даже если им эти структуры на лбу вытатуировать.
Какая-нибудь связка класса "описание товара отдельно, цены отдельно" - и всё, пиши пропало. А ведь это совершенно нормально для средней руки магазина с несколькими ценовыми мордами (псевдоконкуренция). В общем-то, формы и отчёты к базам данных и придумывали, чтобы значительно упростить ввод.
Ну и - на закуску - подобное обращение с базой в случае чуть более сложных проектов вроде "нибелунга" просто невозможно даже на уровне "основная база без рюшечек". Вопрос в реляционности - вот у меня к единичной записи контента приторочен вагон метаданных, бинарных данных, авторские права вокруг бегают, там ещё коды сбоку и так далее.
Короче, описанная тобой штука годится для небольших и не сильно связанных табличных реестров. Уже толковая новостная система - с загрузкой нескольких картинок на статью, со ссылкой на id источника, на ветку комментариев и прочим (могу показать) - в разы проще управляется специализированным веб-интерфейсом, чем универсальным БД-клиентом.
Вот такое мнение. :)
no subject
Date: Tuesday, March 15th, 2005 04:50 am (UTC)ушёл задумчиво пить кефир.
no subject
Date: Tuesday, March 15th, 2005 10:56 am (UTC)я ни с чем, кроме SQL-ных RDBMS, не работал. что курить? :)
no subject
Date: Tuesday, March 15th, 2005 12:26 pm (UTC)для "пробы" (т.е. это далеко не идеал, но все же) - FramerD (http://www.framerd.org/)
а вообще лучше со мной по этому поводу покурить пива/глинтвейна/швепса/сигарет ну и тому подобного и потрепаться на эту тему.
О да.
Date: Tuesday, March 15th, 2005 02:37 pm (UTC)Re: О да.
Date: Tuesday, March 15th, 2005 03:16 pm (UTC)эх.
а вообще /me время от времени педалит Weta DB -- извращенческую ruby prevalence (или около того). посмотрим чё выйдет :-D
no subject
Date: Tuesday, March 15th, 2005 10:38 am (UTC)Нахрен универсальный DB-клиент. Дайош СВОЙ клиент, заточенный под свою систему. С разными уровнями абстракции, и прочее.
Вот тогда может смысл проявится.
no subject
Date: Tuesday, March 15th, 2005 10:47 am (UTC)"Универсальный DB-клиент" как Access, "СВОЙ клиент" как проект на Access'е. По крайней мере, я себе это так представляю.
no subject
Date: Tuesday, March 15th, 2005 10:56 am (UTC)Только по ходу куча гемора будет ;)
На самом деле не суть важно на чём, идея где-то рядом.
no subject
Date: Wednesday, March 16th, 2005 09:02 pm (UTC)HTML по уровню неудобства просто отдыхает.
no subject
Date: Tuesday, March 15th, 2005 02:38 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 02:45 pm (UTC)А если делать это через native mysql api, то ближайший KAV office guard начнёт волать, что тут живут вирусы — ыш ты, функции из внешней .dll импортируют!
+ скорость работы, опять же...
no subject
Date: Tuesday, March 15th, 2005 02:52 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 02:58 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 03:17 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 03:19 pm (UTC)Нафих эти ваши мета-системы, простого скриптинга хватит за глаза.
no subject
Date: Tuesday, March 15th, 2005 03:54 pm (UTC)мучайтесь .)
no subject
Date: Tuesday, March 15th, 2005 03:55 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 03:56 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 04:01 pm (UTC)На скриптовых языках (том же Lua) щас чуть ли не AI пишут. Что вам не нравится?
(кажется, начинается очередной флейм ;))
no subject
Date: Tuesday, March 15th, 2005 04:02 pm (UTC)я сам вон Weta DB на руби пишу...
no subject
Date: Tuesday, March 15th, 2005 04:06 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 04:07 pm (UTC)пока сайты будут просто "скриптить", ничего кардинально хорошего не произойдет с ними
no subject
Date: Tuesday, March 15th, 2005 04:11 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 04:14 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 10:42 am (UTC)а вот по поводу "база без рюшечек". да, я твёрдо уверен в том, что в большинстве случаев такое возможно. ты давно на MS Access смотрел? :) я специально упоминал Access, а не, допустим, Excel.
"что в таблице books поле author_id ссылается на поле id в таблице authors" - это есть во многих нормальных database front-end'ах. ситуация с тем, как у "Нибелунга" хранятся свойства объектов, чуть хуже, но есть софта, которая и это "рисует".
кстати, о картинках, - это один из клинических случаев, когда их в базе хранить удобно... (хотя потом можно кешировать на диске).
no subject
Date: Tuesday, March 15th, 2005 02:47 pm (UTC)В случае чего-нибудь вроде, ну, к примеру, постгреса мы также можем задавать формы (но я не видел понимающих это клиентов) и вообще унести всю клиентскую логику в базу. Я пока не решил, насколько это целесообразно. Грубо говоря, я могу сделать там вообще PSQL-дамп, который проинсталлирует тебе базу данных, разложит по нужным местам нужные пакеты и ещё пару приблуд соберёт. :)
В случае любимого веб-сайтоводами мускля сей номер не пройдёт. Там вообще мало что пройдёт, даже в новых и крутых версиях. А на всемирную революцию по этому поводу у меня оранжевых ленточек не хватит.
В нибелунге провязки "это ссылается на то" в таблицах стоят, там это много где используется. Но при отсутствии единой формы, где можно поредактировать свойства из разных таблиц, не заморачиваясь ненужными тебе свойствами - это мало кому на голову натянется.
И картинки, кстати, в базе. А потом, если надо, кэшируются. Впрочем, иногда - в другой базе. :)
no subject
Date: Tuesday, March 15th, 2005 02:55 pm (UTC)При чём писал на VB+external DLL+mySQL.
Что я скажу... Врагу не посоветую.
Я таки считаю, что можно нормально написать свою более-менее общую приблуду. В крайнем случае приклеять какой-то Lua и юзать его для логики.
ps: чо это за нибелунги такие?
no subject
Date: Tuesday, March 15th, 2005 03:12 pm (UTC)умеет работать с смс-ммс шлюзами, продавать по вапу, вести биллинг, рулить мобильным контентом (то бишь, товаром) и так далее. первую версию мы с
no subject
Date: Tuesday, March 15th, 2005 02:58 pm (UTC)А куда девать логику? ...
Date: Tuesday, March 15th, 2005 08:01 am (UTC)Либо - ты пойдешь придумывать, как спрятать всю логику на стороне "сервера", а в сторону клиента передавать только команды по управлению интерфейсом. Чтобы, значит, интерфейс можно было reuse-ать в разных проектах. В результате получится HTTP+JS, или X11, но - свое, ни с чем не совместимое.
Морали в моей басне нет, это скорее мысли вслух.
Re: А куда девать логику? ...
Date: Tuesday, March 15th, 2005 10:45 am (UTC)no subject
Date: Tuesday, March 15th, 2005 03:15 pm (UTC)no subject
Date: Tuesday, March 15th, 2005 03:16 pm (UTC)В который писать можно только из универсального фронта к базе данных...
no subject
Date: Friday, May 6th, 2005 01:01 pm (UTC)no subject
Date: Friday, May 6th, 2005 01:11 pm (UTC)> или посещать сайт какого-то web-mail'а? ...смысл: как правило,
> специализированное решение круче универсального, когда оно
> существует. Исключения пока трогать не будем.
у мейлинг системы есть задача: читать и отсылать почту. ну там и ещё что-то. у сайта всё сложнее. один сайт делается как средство информации, другой - продвиженя, треттий - продаж, четвёртый просто понты, пятый - всё это вместе.
то есть сравнение не корректно. вы видите оптимальное решение для самых очевидных для вас задач, а между тем есть группы других задач, которые ваше решение просто режет без ножа.
no subject
Date: Monday, September 27th, 2010 10:05 am (UTC)