Картинки возвращаются
Продолжая про картинки в базе. Вот это сообщение.
Народ, однако, упорно комментирует, наглядно показывая выскоий уровень своего непонимания: «К тому-же у картинок могут быть другие атрибуты, которые нужно читать/менять (например счетчики)».
Господа, блин, возьмите и почитайте ДОКУМЕНТАЦИЮ. Ну хоть раз, для разнообразия, а? В частности — главу 5.
И потом — никто не мешает в базе данных хранить все нужные аттрибуты: размер картинки, счетчики, и проч. и проч., но не хранить саму картинку, а путь до нее. Разве это не понятно?
Хоть садись и заметку на тему «MySql abuse» пиши, честное слово. Да, кстати, я сейчас очень медленно и неторопливо пишу одну вещь на MySql. Так вот, например, блок разбора ЧПУ, который понимает неограниченное количество вложенных рубрик, типа site.ru/news/world/iraq/propaganda_bullshit/ — знаете, сколько раз обращается к БД, чтобы правильно разобрать подобный УРЛ по рубрикам-подрубрикам?..
Wag the Dog
Напомнили совершенно замечательный фильм — Wag the Dog с Хофманом и Де Ниро. В связи с последними событями фильм становится еще более актуальным. Пересказывать его — только все портить. Всем рекомендую к просмотру/пересмотру.
MySql vs Files
Ну, если про хранение текстовой информации еще можно поспорить — и совершенно справедливо — то некоторые вещи меня удивляют. Использовать MySql для хранения картинок... и выдавать их так...
$data = @mysql_result($result, 0, "imageinfouser");
header("Content-type: $type");
echo $data;
Мне даже сказать по этому поводу нечего.
Я не программист
Дальше я пишу о себе всякие хвалебные вещи, читать не обязательно. Как написано в качестве эпиграфа здесь. detail.phpclub.net/
Я на самом деле не программист. Я, конечно, умею программировать, но... не люблю это делать. Я просто люблю решать проблемы (ну и создавать заодно). Я скорее разработчик или дизайнер (дизайнер — это не «оформитель», а, опять таки, «разработчик»). Я умею писать такие ТЗ, что самому читать приятно. Дело в том, что я умею программировать, поэтому мои ТЗ основаны не только на «а вот хочу того и того», а еще и на знании «почему хоть то-то и то-то правильно, а то-то и то-то — нет, и как это все в конце концов реализовать».
Лирическое отступление:
На прошлом месте работы начальник как-то сказал что-то вроде (за точность не ручаюсь, но по духу примерно так) «Вот ты написал два ТЗ, а кому оно нужно? Наш программист сам знает, что нужно». Потом, увидив Spesta, он сказал (дословно): «Блин, классная статистика. Гораздо лучше Киселевской — ты ему ее показывал?». (Диме Кисилеву привет!). При этом я, с присущей мне скромностью, не считаю, что оно лучше запрограммировано. Оно лучше придумано. Именно для этого и нужно ТЗ — не смотря на то, что программист знает, «что нужно», главное — это «как нужно», потому что конечному пользователю все равно общаться с уровнем «как нужно», а «что нужно» его не интересует.
То есть пользователю совершенно не важно, что «нужно собирать такую-то статистику». Ему важно, как потом работать с этой статистикой. Ну, это мы уже залезли, опять же, в интерфейс...
Я тут пару дней думал на тему «Идеальная CMS». Здесь, опять же, проходит грань между программистом и разработчиком. Я придумал пару архитектурных решений и свежих идей, которые «программист» не придумал бы — только потому, что программисту не доводилось так плотно общаться с контентом, как мне.
Основная проблема в том, что я знаю, как ее сделать, но делать не хочу: очень уж лениво так много программировать. Есть, конечно, хороший принцип «If you want something to be done — do it yourself», но...
I actually hate programming,
but I love solving problems.
Rasmus Lerdorf
