А на тему того, чтобы предлагать заказчику потом доплатить за безопасность проэкта… Если по-честному, то неплохо было бы предлагать сразу 2 варианта различные по стоимости: безопасный и небезопасный, но тогда будет сложно объяснить, почему ваш безопасный вариант дороже варианта Васи Пупкина, который клянётся в идеальности своего кода. Вобщем, я считаю, что это не самый лучший вариант. Особенно для фрилансера. Выпуск сырого кода, как конечного продукта, может подорвать вашу репутацию, и с вами просто не захотят потом работать. Впрочем, это всё уже философия. А так… ждём статьи – интересно. Может и я для себя узнаю что-то новое, увижу оригинальную идею.

На счёт умников, это задротня (хуесосы)извиняюсь за маты!
Обсирать одно а помогать начинающим это другое, я тоже могу не прочитавши статью обосрать по самое не могу, но я уважаю труд! Короче поддерживаю DimoninG мужик давай ЗА РУСЬ продолжай, я всегда посылаю, критиков открытым текстом на хуй, поверь благодарных тебе намного больше, 90% кто это читал, так что давай я блин пол года ожидаю, :lol: продолжения банкета! :smile:

Хотелось бы увидеть продолжение. Очень хотелось бы :).

——-
PS
——-
Автору еще раз респект.

При работе на заказчика я обычно не показываю промежуточный этап. Даже больше – я не забочусь о безопасности и предлагаю за это доплатить отдельно, т.к. я искренее считаю, что «безопасность» – не входит в «стандартный комплект». Простите, но жить тоже нужно на что-то.

Но Ваш подход (только в плане работы с заказчиком! так я остаются при своем мнении) – гораздо лучше. Даже хороший программист может такой «случайностью» заслужить репутацию ужасного, что… ужасно :)

Может еще рефакторинга коснемся

Сначала нужно будет о TDD говорить :-)

потом подумаем, что будет, если разложить нагрузку на несколько серверов

Сначала рефакторинг :-) В Вашем случае даже репликацию будет сделать проблематично.

Я вообще довольно импульсивный и Вы меня определенно выводите из себя.

«Спокойствие, только спокойствие», как говаоривал небезызвестный мультперсонаж.

По какой, еще раз объясните мне, причине я не могу заняться безопасностью в конце?

Мы просто вкладываем разный смысл в понятие безопасность.
Сама «безопасность» – аудит сайта, выявление уязвимостей, стрессовое тестирование и т.п. – действительно идет в конце проекта. Просто, как показывает практика, полное тестирование (в прямом смысле этого слова) – это миф: в мало-мальски серьезном проекте очень трудно протестировать все возможные пути в коде (очень показательна в этом плане история о том, как школьник обнаружил XSS-уязвимость в GMail).

А всякие простые вещи – наподобие intval/addslashes/htmlspecialchrs – имеет смсыл использовать сразу при написании кода :-) Мое мнение :-)

Я бы назвал Ваш подход – головной болью на ровном месте.

Попробую с другой стороны: где именно при «моем» подходе головная боль? В идеале при использовании обоих подходов мы получим одинаковый результат. Но в «моем» случае я один раз написал и забыл, в Вашем – написал, вернулся и переписал. Видите ли, на практике очень трудно убедить заказчика (я сейчас говорю о забугорных заказчиках) почему мне нужен еще один час (который он оплачивает), чтобы расставить везде всякие там addslashes. Раз я их там изначально не поставил (при условии, что они нужны) – это моя ошибка (что с радостью подтвердят тестеры/программисты заказчика), следовательно, свои ошибки я должен исправлять за свой счет. Так вот работаю серьезные компании.

Я уверен, убежден и никто меня в этом не переубедит, что просто у меня другой подход.

Да я не спорю, я просто указываю на некоторые недостатки такого подхода и чем они грозят при работе в серьезной конторе.

Единственная ошибка, которую я допустил – это выложил промежуточный результат, получается так?

Посмотрим с точки зрения заказчика: я потребовал промежуточную версию, чтобы посмотреть, как у программиста идут дела, в состоянии ли он сделать то, что обещал и пр. – в общем, обычная проверка для человека, который не хочет зря тратить деньги. Я даю этот прмежуточный результат своему тестеру (предупреждаю его о том, что это сырая альфа). Тестер – он тоже человек, ему тоже нужно показать, что он работает, а не штаны просиживает. Он лезет в код. Код аккуратный, признаю. Лезет в запросы. А там – никаких проверок данных – потенциальные критические уязвимости. Он смотрит другие запросы. Там такая же картина. Для запросов используется mysql_query(), следовательно, для того, чтобы закрыть все дырки, нужно в любом случае лазить по всем запросам. Что в этом случае сообщит тестер заказчику? Видимо то, что code is vulnerable by design. После этого заказчик либо отберет у Вас проект, либо заставит бесплатно исправлять. Не раз такое видел. Ни одно, ни другое хорошей репутации Вам не прибавит, согласитесь.

Это я Вам рассказал с точки зрения заказчика. Опять же, основываясь на своем восемнадцатилетнем опыте. А так как заказчик – это тот, кто платит, его обычно трудно переубедить, если имеются серьезные косяки.

Я не буду вдаваться в подробности, где именно была допущена «та самая» ошибка, каждый сделает выводы для себя сам.

Если человек пишет правой рукой, Вы будите его переучивать писать левой?

Нет, а смысл?

В любом случае, это сравнение некорректное. Более того, переучивать – не моя задача, я просто указал на некоторые недостатки. Ведь мы учимся именно на ошибках :-)

А вот Ваша статья http://blog.sjinks.org.ua/mysql/9-security-they-talk-so-much-about/ – очень наглядная, приятно почитать.

Начну с того, что в нормальной команде, как ни странно, мне поработать так и не вышло. То есть для меня «работа в команде» означает постоянное переключение задач, доработку чуждого кода, ругань и маты. Видимо, не повезло. Я уж не говорю о том, что нормально поиспользовать всякие системы контроля версий и прочее – не довелось. Аналогично, в фирмах, где работал – обычно кодил сайт я один, или какие-то мелкие детали потом доделывали другие ребята.

Поэтому с некоторого времени я решил работать только один – это оказалось легче. С удовольствием бы поработал в команде и посмотрел, как это делается у нормальных людей.

> О безопасности думать в любом случае придется, просто с Вашим подходом это называется “недостаточное планирование”.

Я бы назвал Ваш подход – головной болью на ровном месте. Назвать всякими умными словами (мерчендайзер! андронный коллайдер! +) ) всегда можно. При этом половина прочитавших наверняка решит, что «фу, да он недостаточно спланировал!» не понимая вообще, что это значит.

Я уверен, убежден и никто меня в этом не переубедит, что просто у меня другой подход. Стиль, если хотите.

Никто не запрещает заниматься безопасностью в конце, с чего бы это? По своему опыту я знаю, что у меня – наоборот! – меньше ошибок, если я только безопасностью и занят.

> Или вообще при жестком дедлайне/бюджете не выполняется.

Если честно, да, бывало. Обычно я предупреждал заказчика, что если хочет еще и безопасность – давайте расширим сроки или увеличим бюджет. 100% заказчиков отказывались. Их дело.

> И они не исправят эти ляпы.

Я во всех частях говорю, что будет идти дальше. Если они не дождутся безопасности – в этом виноват уже не я. Аналогично, если кто-то решил, что моя капча – это «мега-находка», я честно всех предупредил, что ломается она легко, но пока что уникальна.

> Элементарные проверки должны быть везде. Иначе, как минимум, складывается негативное впечатление о программисте.

Я вообще довольно импульсивный и Вы меня определенно выводите из себя. По какой, еще раз объясните мне, причине я не могу заняться безопасностью в конце? Единственная ошибка, которую я допустил – это выложил промежуточный результат, получается так? Не надо еще раз о мифическом «планировании». Если человек пишет правой рукой, Вы будите его переучивать писать левой?

> Специально пересмотрел статью, и не нашел этого упоминания.

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

> Ну и как бывший препод программирования в универе

Вооот, вооот в чем дело ;)

> а чем оправдано использование die() вместо возвращения ошибки? В конце концов, даже exceptions в PHP есть…

Исключения – вроде бы только в пятой ветке. А «дай» я использую, т.к. нет смысла возвращать ошибку и использовать тот же «дай» :) Или, не знаю, echo «вротмненоги»; exit; – аналог «даю».

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

Да и еще. По поводу педагогического эффекта моих статей. Несомненно он есть. Но еще несомненно, что это БЛОГ, а не университет (то есть – «что хочу, то и ворочу, а недовольные могут не читать» – концепция блога, не так ли?).

подумаю о безопасности в следующих частях

О безопасности думать в любом случае придется, просто с Вашим подходом это называется «недостаточное планирование». Объясняю: Вы добавляете «действия с постами и категориями, действия с комментариями и комментирование», потом «вывод всего этого на сайт». Потом начинаете заботиться о безопасности. То есть Вам придется открыть каждый файл, во все запросы добавлять addslashes, проверку данных и т.п. Такая работа чревата ошибками: недоглядел. Или вообще при жестком дедлайне/бюджете не выполняется. В результате получается это (из машин, на которых стоит ArticleDashboard, получается неплохой ботнет, но это к слову). Короче, на добавление элементарного addslashes() в части 4, Вы потратите больше времени, чем если бы Вы это делали в самом начале. Потом, подумайте о пользователях, которые не дождутся последней части. Они будут уверены, что код хороший, ибо его писал «реальный программист» с трехзначным числом RSS-подписчиков. И они не исправят эти ляпы.

Мораль истории в том, что «everything worth doing, worth doing well». Если Вы хотите кому-то что-то показать (хотя бы как концепт), делайте это правильно. Не забывайте о педагогическом эффекте ваших статей. Элементарные проверки должны быть везде. Иначе, как минимум, складывается негативное впечатление о программисте.

говорил, что не буду использовать модель разделения логики и представления

Специально пересмотрел статью, и не нашел этого упоминания.

переменные и так существуют, они и без того глобальные

DimoninG, Вы работали над большими проектами и в команде? Вам знакомо понятие «системный подход»? Вы знаете, что такое «повторное использование кода»? Вы же где-то писали о себе как о фрилансере с большим стажем. Лично я, выступая в роли HR (а у меня были мысли пригласить Вас в команду после статьи с капчей) или даже заказчика, не взял бы Вас в команду, после того, как посмотрел бы на код движка. Это я говорю как программист/системотехник с более чем 18-летним стажем. Ну и как бывший препод программирования в универе :wink:

Поэтому нет смысла захламлять память лишними параметрами функций

Ну да, теоретики программирования были неправы :-) Еще в далеком 1973 году считалось, что использование глобальных переменных – муветон.

Ладно, параметры занимают лишнее место в памяти :lol:, а чем оправдано использование die() вместо возвращения ошибки? В конце концов, даже exceptions в PHP есть…

единственный достойным комментарием считаю только пункт 2

Значит, по пункту 4 ничего-таки не заметили? Эх…

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

Да и еще что странно – один человек уже пристал ко мне с безопасностью. А то, что я ей займусь в конце – внимание на это не обратил.

Гы, addslashes() нужно приучаться сразу ставить, а не оставлять на потом.

Секрет, лучше бы “влез” с подробными

Если с первого взгляда:
1. Отсутствие addslashes()/htmlspecialchars()
2. Использовать в функциях $_GET/$_POST – очень плохо. Функции должны передаваться аргументы, а использование (супер)глобальных переменных без всякой необходимости является дурным тоном и вводит лишние зависимости.
3. Разделение управляющей логики и презентационной части. Почитайте про MVC. Если человек будет пытаться подстроить дизайн под себя, сколько файлов ему нужн будет перелопатить в Вашем случае? Малейшая ошибка в functions.php может привести к неработоспособности всего кода. И использование die() вместо возврата ошибки тоже впечатляет.
4. show_post() – вообще «гениальное» творение. Посмотрите на if, ничего не находите?
…

Задача здесь все же – показать как можно сделать свой блог

В том-то и дело. Учить нужно на хороших примерах. На тех, которые можно использовать с минимальными изменениями.

Вообще гря, это все писалось очень быстро и что-то там придумывать совершенно не хотелось. Задача здесь все же – показать как можно сделать свой блог, а не написать эталонный код. Хотя я лично вообще не делю код на плохой и хороший. Мы тут, в самом деле, не автопилот для самолета пишем. И всякие там педантичные маньяки, которые считают выигрыши по производительности в десятую секунды – не по адресу, не для этого проекта :)

Незнаю как у других, а для меня создание админки – самое сложное. Понимаю, что как раз и нужно начинать с самого сложного, но у меня так не получается. Все время пишу сайт начиная с пользовательской части… а на админку потом … забиваю :lol: )))))) Приходится потом редактировать через phpMyAdmin :lol: