Эх, как эта штука у меня крови попила… В FF1-2@Linux ее просто нет (по крайней мере плеер в этом уверен), Opera@Linux говорит «да, я умею ExternalInterface!», но при первом же обращении скрипт умирает, да и под win глюки не менее интересные. Кончилось написанием костыля, который его использует только в случае ActiveX (для IE) версии, для всего остального дедовские способы коммуникации.
Не только слышал, но даже интерфейс своего сайта хотел завернуть в Gopher, ибо сам сайт разрабатывался с идеями, на которых построен Gopher. Эх, чего только не делали для этого протокола, даже 3D-смотрелки!
… а еще Gopher пример того, что более развитая технология != популярная, ибо предшественник FTP жив до сих пор, а про Gopher это сказать сложно
Если есть желание творить, то вопрос денег встает на второй план. Если же «хорошо, если за эти телодвижения платят», то действительно, «никакого творчества».
> как все попривыкали к CMS. а бывают ещё и самописные сайты…
Это которые в ворде или notepad.exe делают? Без слез на них смотреть нельзя, а если и можно, то строятся такие сайты слишком долго. В остальных случаях используют CMS в той или иной степени, даже если в итоге на хост заливается статический HTML.
> это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
А что в этом сложного? Грамотный подход к разработке — это даже скорее облегчение труда, а если профильная фирма не может обеспечить инструменты для работы, то я бы очень сильно задумался о профильности этой конторы.
> А группы пользователей и всякие админки — пережиток тоталитаризма и расовой сегрегации.
На хорошем сайте не должно быть ссылок, которые ведут на «закрытые» разделы сайта (разные админки), а если пользователь начал перебирать урлы и пытается зайти куда-то вроде example.com/admin/, то ему лучше показать 404, форму авторизации (когда к админке имеет доступ большое количество пользователей), на худой конец просто кинуть редирект на главную. Но не 403.
В случае групп, у которых разные права доступа, лучше показать форму авторизации, где предложить ввести логин/пароль пользователя, имеющего доступ а этот раздел. Причем указать, почему появилась такая форма, дабы пользователь не вводил свое имя еще раз, тем самым запутываясь. Но не 403.
Где настройки веб-сервера? Где watchdog? Где автоматическое тестирование? Упущено очень многое…
С очень многими пунктами не согласен:
> ● Вычитать тексты и проверить правописание
> ● Связность текстов
Это нужно делать при приемке контента, но никак не перед запуском.
> ● Проверить нет ли на сайте вшитых ссылок на dev-сервер (т.е. после запуска ссылки должны вести на сайт «в миру»)
А это вообще вопиющая халатность: все ссылки должны генерироваться автоматически, в крайнем случае быть относительными. В любом случае, контент со ссылками — худшее и непереносимое решение. Удачи при создании вап-версии.
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
> ● Привести формат ссылок к читабельному виду (напр. site.ru/blog/how-to-make-coffee, site.ru/user/vasya и т.д.)
Задача для ранней стадии, скорее для разработчика движка (или настройщика готового)
> ● Проверить весь заказанный/особый/сложный функционал
> ● Проверить работу поиска (включая релевантность)
> ● Протестировать все формы (контактов, комментариев, фидбека, ...), поставить на них капчу или другую защиту
>…
Все это должно тестироваться не руками, а юнит-тестами в автоматическом режиме. Формы отдельно тестировать не нужно, проверять нужен сам движек сайта на корректность обработки форм. Капча должна расставляться в полуавтоматическом режиме, причем далеко не везде (например, в формах для связи ее делать не следует: лучше пропустить 20 спам-сообщений, чем упустить 1 баг-репорт)
> ● Проверить нет ли у посетителей доступа к служебным/секретным/закрытым страницам
> ● Закрыть поисковикам доступ к служебным/секретным/закрытым разделам сайта, используя robots.txt
Если такое допускается, то автора надо без зазрения совести увольнять с заключением о проф.непригодности.
> ● Проверить и реализовать кэширование где это необходимо
Какое кеширование? Средствами вебсервера? Средствами движка? Нужно ли кеширование байт-кода? Тема кеширования не раскрыта, а это порой очень большая часть при разработке.
> ● Создать свои страницы 404/403
А где 500/503? Где был автор в момент отладки?
Да и 403 — это как плевок в пользователя, «страница есть, но не для тебя, пшел вон отсюда»
Эх, как эта штука у меня крови попила… В FF1-2@Linux ее просто нет (по крайней мере плеер в этом уверен), Opera@Linux говорит «да, я умею ExternalInterface!», но при первом же обращении скрипт умирает, да и под win глюки не менее интересные. Кончилось написанием костыля, который его использует только в случае ActiveX (для IE) версии, для всего остального дедовские способы коммуникации.
Скажите, а ваш пример под Linux работает? Везде?
… а еще Gopher пример того, что более развитая технология != популярная, ибо предшественник FTP жив до сих пор, а про Gopher это сказать сложно
Это которые в ворде или notepad.exe делают? Без слез на них смотреть нельзя, а если и можно, то строятся такие сайты слишком долго. В остальных случаях используют CMS в той или иной степени, даже если в итоге на хост заливается статический HTML.
> это далеко не у всех профильных фирм получается, а если админы-дизеры сами всё делают, то очеь даже важный пункт
А что в этом сложного? Грамотный подход к разработке — это даже скорее облегчение труда, а если профильная фирма не может обеспечить инструменты для работы, то я бы очень сильно задумался о профильности этой конторы.
про вебмани не понял юмору.
На хорошем сайте не должно быть ссылок, которые ведут на «закрытые» разделы сайта (разные админки), а если пользователь начал перебирать урлы и пытается зайти куда-то вроде example.com/admin/, то ему лучше показать 404, форму авторизации (когда к админке имеет доступ большое количество пользователей), на худой конец просто кинуть редирект на главную. Но не 403.
В случае групп, у которых разные права доступа, лучше показать форму авторизации, где предложить ввести логин/пароль пользователя, имеющего доступ а этот раздел. Причем указать, почему появилась такая форма, дабы пользователь не вводил свое имя еще раз, тем самым запутываясь. Но не 403.
403 — это оплеуха в чистом виде. Уж лучше 500.
С очень многими пунктами не согласен:
> ● Вычитать тексты и проверить правописание
> ● Связность текстов
Это нужно делать при приемке контента, но никак не перед запуском.
> ● Проверить нет ли на сайте вшитых ссылок на dev-сервер (т.е. после запуска ссылки должны вести на сайт «в миру»)
А это вообще вопиющая халатность: все ссылки должны генерироваться автоматически, в крайнем случае быть относительными. В любом случае, контент со ссылками — худшее и непереносимое решение. Удачи при создании вап-версии.
> ● Проверить не осталось ли на сайте тестового контента
> ● Отключить вывод ошибок на экран
При грамотном подходе к разработке, с разделением на дев/продакшен, это просто не имеет смысла.
> ● Привести формат ссылок к читабельному виду (напр. site.ru/blog/how-to-make-coffee, site.ru/user/vasya и т.д.)
Задача для ранней стадии, скорее для разработчика движка (или настройщика готового)
> ● Проверить весь заказанный/особый/сложный функционал
> ● Проверить работу поиска (включая релевантность)
> ● Протестировать все формы (контактов, комментариев, фидбека, ...), поставить на них капчу или другую защиту
>…
Все это должно тестироваться не руками, а юнит-тестами в автоматическом режиме. Формы отдельно тестировать не нужно, проверять нужен сам движек сайта на корректность обработки форм. Капча должна расставляться в полуавтоматическом режиме, причем далеко не везде (например, в формах для связи ее делать не следует: лучше пропустить 20 спам-сообщений, чем упустить 1 баг-репорт)
> ● Проверить нет ли у посетителей доступа к служебным/секретным/закрытым страницам
> ● Закрыть поисковикам доступ к служебным/секретным/закрытым разделам сайта, используя robots.txt
Если такое допускается, то автора надо без зазрения совести увольнять с заключением о проф.непригодности.
> ● Проверить и реализовать кэширование где это необходимо
Какое кеширование? Средствами вебсервера? Средствами движка? Нужно ли кеширование байт-кода? Тема кеширования не раскрыта, а это порой очень большая часть при разработке.
> ● Создать свои страницы 404/403
А где 500/503? Где был автор в момент отладки?
Да и 403 — это как плевок в пользователя, «страница есть, но не для тебя, пшел вон отсюда»