Apr
13
|
Пару советов по созданию проектов
|
В частности я буду иметь ввиду проекты на PHP, но некоторые советы возможно применять и к другим языкам.
Сразу оговорюсь, что мои советы — не есть последней инстанцией и каждый должен включать мозг, применяя тот или иной совет и думать, почему именно так, а не иначе и возможно есть лучшие способы сделать тоже самое.
Большая часть этих советов собрана с разных источников, что-то я для себя экспериментальным путем нашел. Часть советов касается безопасности при создании веб-приложений, т.к. это один из самых сложных моментов (как на меня) для многих программистов.
Итак, мой набор советов.
- Выключайте отображение ошибок на продакшене. Очень частая ошибка, избегайте ее, незачем давать пищу для размышлений для взломщиков. На экран пользователя не должна вообще отображаться какая-либо информация о серверной части, а тем более ошибки. Сделать это можно поместив в .htaccess строку php_flag display_errors Off
- Путь на файловой системе. Не используйте никогда директив по типу define (’PATH_ROOT’, ’/hosting/bla-bla/’) . Это глупая стратегия. Каждый раз править настройки при переносе проекта на другой сервер — абсурд. Используйте «магическую константу» __FILE__ , которая моментально вернет путь к текущему файлу (допустим конфигу), от которого можно получить нужный путь к корню проекта.
- Ядро проекта. Контроллеры, модели и прочее должно лежать как минимум на уровень выше, чем часть, доступная через веб-браузер. Хорошая стратегия строить приложение так — что директория ядра и директория, указанная в DOCUMENT_ROOT — лежали на одном уровне (у меня эти папки обычно имеются как application и public). Данное разграничение призвано обезопасить проект от перезаписи файлов через уязвимость в проекте. Хорошей практикой также будет снять бит на запись от имени пользователя, под которым запущен веб-сервер.
- Загрузка файлов, изображений и т.д. Допустим, что все загружаемые файлы кладутся в папку uploads в папке public. Тогда первым делом лучше всего положить в папку uploads файлик .htaccess со следующей строкой — php_flag engine off — это поможет защититься от любителей залить бекдор через уязвимость в коде загрузки файлов на сервер. Это конечно слабая защита от загрузки бекдоров на других языках (например на перле), но «школьники» уже не пройдут. А лучше всего конечно делать безопасную загрузку, без уязвимостей. Но на всякий случай рекомендую подстраховаться таким образом — лишним не будет. Строка запрещает выполнение пхп-кода из данной папки и подпапок.
- Мультиязычность. Планируйте возможность мультиязычности еще на этапе проектирования и создания приложения, даже если это сейчас и не нужно. Это съекономит много сил и нервов, когда «вдруг» мультиязычность понадобиться, а в ядре ничего не заложено для этого. На подобные грабли в свое время наступил проект connect.ua, не повторяйте чужих ошибок
- Оптимизируйте все до того, как появятся нагрузки. Не стоит ждать, пока проект начнет тормозить под нагрузками и только тогда решать вопрос. Поставьте изначально байт-кешеры кода, например eAccelerator (или другие по вкусу), настройте кеширование на стороне клиента (хорошие советы в этом плане можно найти на webo.in) и на сервере. Это даст существенный прирост производительности (иногда порядка 300 и более процентов), что существенно снизит нагрузки и повысит скорость загрузки страниц у пользователей.
- Настройте оповещение об измененных файлах за сутки. Я обычно это делаю через помещение в крон строки: 0 0 * * * find /path/to/public/dir -mtime 0 | mailx -s «report » my@mail.com > /dev/null 2>&1 , после этого мне раз в сутки приходит список измененных файлов в директории, анализируя который можно понять, все ли хорошо. Тоже самое можно настроить и для ядра проекта. Данный отчет однажды спас меня, когда произошел взлом одного из моих проектов и по всей фс были накиданы бекдоры — через эти списки мне легко удалось всех их удалить, без поднятия проекта из бекапа. Лично для меня — это теперь незаменимая вещь, лог которой я просматриваю раз в сутки обязательно на наличие подозрительных изменений.
- Всю разработку ведите на SVN и на дев-сервере. Не стоит делать правок «наживо» на продакшене. Я считаю оптимальным — настроить SVN так, чтобы при комите данные сразу попадали на дев-сервер, где можно еще раз протестировать сделанные изменения. Это очень удобно для разработки и тестирования. Как правило дев-сервер может быть отдельной машиной, но также это может быть и виртуал-хост на той же машине, где и продакшн. Правда последний вариант не рекомендую, т.к. при тестировании могут быть разные ситуации, вплоть до зацикливания кода и нехорошо, когда это влияет на работу текущих пользователей.
Если еще что-то вспомню важное — допишу.
Успехов!
13.04.2009 в 22:10
>2. Путь на файловой системе.
По опыту знаю что лучше всетаки прописать этот и подобные пути (путь к картинкам, путь для аплода файлов, etc) в отдельном файле-конфиге. Во-первых – если понадобится разносить все по разным серверам, то проще в конфиге переписать пути к этим серверам, чем лезть в код. Во-вторых – php-предпроцессор не напрягается при вычислении всех этих путей, хотя это экономия на спичках.
>3. Ядро проекта.
Это все конечно классно, но только в том случае, если проект крутится на своем серваке, который с легкостью можно конфигурировать. Большинство же шаред-хостингов не позволяют такое делать
>6. Оптимизируйте все до того, как появятся нагрузки.
Тут больше подойдет закладывание в проект системы кеширования (вернее адаптера для системы кеширования). Пусть даже он по началу работает просто с фалами, складывая кеш в фаловую систему. Зато в дальнейшем малыми усилиями его можно перенастроить на тот же мемкешед. Ну и большинство статей с webo.in рулят, хотя больше они пригодятся верстальщикам.
>8. Всю разработку ведите на SVN и на дев-сервере.
Лично я всегда предпочитал git , но тут уже дело вкуса. Стоит пользоваться в любом случае, даже если ведешь разработку в гордом одиночестве. Хотя в eclipse есть своя встроенная система контроля версий (это если разработчик в проекте один).
P. S. Извеняйте за много букоф, просто что-то пописать сегодня потянуло
13.04.2009 в 22:22
Так оно и есть в одном файле, просто все другие пути (к картинкам к аплоаду) строятся на основе этого пути, полученного через __FILE__ . Вопрос не в том. Вопрос в том, что указывать явно путь – нет смысла, лучше использовать эту константу.
При моем подходе не нужно будет лезть никуда вообще, мое приложение отлично разноситься по серверам без каких-либо правок конфига (только доступ к БД).
Да, глупая экономия.
Что мешает купить VPS или даже попросить хостера настроить как нужно? Врядли хостер откажет, а VPS вообще за 30 баксов можно приобрести и даже дешевле.
Собственно об этом и речь, что нужно настраиваться сразу на то, что проект будет расти.
GIT, имхо, не имеет клиента под винду, а следовательно не совсем удобен..
13.04.2009 в 22:24
На крон вешаем тесты всего что может меняться где-то наруже от кода: доступность необходимых серверов, баз данных, внешние апи и все что только можно придумать – все куда админы не заходят каждые полчаса
13.04.2009 в 22:30
daedmen:
Это тоже, но это уже больше админский гемор, поэтому я это не описывал, т.к. любой хороший админ должен знать и уметь настроить оповещение о том, что какой-то сервис упал и не поднялся и т.д.
Собственно веб-разработчика это мало должно волновать, а вот измененные файлы – это да, это не админское дело.
13.04.2009 в 23:47
[...] В частности я буду иметь ввиду проекты на PHP, но некоторые советы возможно применять и к другим языкам. Сразу оговорюсь, что мои советы – не есть последняя инстанция и каждый должен включать мозг, применяя тот или иной совет и думать, почему именно так, а не иначе и возможно есть лучшие способы сделать тоже самое. Большая часть этих советов собрана с разных источников, что-то я для себя экспериментальным путем нашел. Часть советов касается безопасности при создании веб-приложений, т.к. это один из самых сложных моментов (как на меня) для многих программистов. Дальше [...]
14.04.2009 в 14:58
По поводу последнего пункта.
“Всю разработку ведите на SVN и на дев-сервере”.
Подскажите плиз.
Скажем есть SVN-репозетарий. Можно туда проект\файл положить, выгрузить. А как сделать так, чтобы я ложил файл в svn, а он автоматом оказывался в папке, доступной для апача? Это наверное нужен какой-то скрипт, который бы определял, что в репозетории есть изменения, и изменившийся файл выгягивал и ложил в папку, где его мог взять апач?
Как это по-умному?
Спасибо.
14.04.2009 в 15:39
Как вариант можно повесить задание на cron, которое будет экпортить из репозитария последнюю версию скриптов и выкладывать ее в папку к апачу.
14.04.2009 в 15:50
У меня просто конфиги обычно в ini-фалах лежат и я не особо понимаю как в них обрабатывать php-инструкции. Да и не проблема обычно открыть ini и отредактировать пару перменных. А в апаче и нгинксе просто закрывается доступ к таким файлам как и к .htaccess
Я имел в виду по разносить на разные сервера это когда приложение работает на одном сервере, а картинки (к примеру) грузятся со второго. Конечно можно настроить web_dav или подобное расширение, но, ИМХО, просто разнести на несколько серверов проще и быстрее.
К сожалению многие админы хостеров очень ленивы, так что проще ответить нет, чем что-то сделать. А VPS (он же VDS) не всегда лучше шаред-хостинга.
Вроде как есть, только я никогда не пробовал
14.04.2009 в 16:12
Александр:
Это называется post-commit. На сервере можно на поскоммит поставить работать какой-либо скрипт, который будет делать svn update для файлов на фс, куда смотрит апач.
14.04.2009 в 16:19
vitalaw:
Для этого есть скрипты пост-коммита, не стоит изобретать велосипеды. К тому же svn import далеко не самое хорошее решение, т.к. заставляет перезаписать все файлы..
ini файлы не всегда удобны в качестве конфига, лично для меня. Да и зачем что-либо редактировать – мало ли кто будет с аппликухой работать. Чем меньше изменений требует приложение при переносе с сервера на сервер – тем оно лучше, мобильнее и гибче.
Мы про разные пути говорим. Я говорю про путь на фс, а не про веб-часть. __FILE__ возвращает путь к файлам на фс, о чем и речь, это нужно для подключения модулей, конфигов и т.д. Картинки грузятся на фронте и по указанному в конфиге пути к ним, речь не о них.
Нужно выбирать правильный хостинг, с неленивыми админами Мне трудно представляется хороший проект, с приличной посещаемостью, на шаред-хостинге. Мы наверное о разном уровне проектов говорим.
Вроде не было, когда я смотрел…
14.04.2009 в 17:04
Проекты разные бывают. Если уж проект с приличной посещаемостью, то кроме как о выделенном серваке речь даже не идет.
http://git-scm.com/download
15.04.2009 в 16:44
Пасиб, из полезного узнал только про посткоммит для SVN и отключение пхп в папке
15.04.2009 в 16:50
Артём Курапов :
И это вполне нормально. Набор советов для того и написан, чтобы тот, кто чего-то не знал из этого списка – мог для себя извлечь что-то полезное.
Написать список абсолютно новых и полезных советов, о которых никто не знал до этого, как мне кажется – невозможно
Спасибо за комментарий
04.05.2009 в 20:29
Может это всем и так понятно, но хотел бы сказать про обязательное присутствие в SVN бекапа последней версии базы данных.
База данных это тоже часть кода и многие об этом забывают.
Если база данных постоянно наполняется (что бывает еще до завершении проекта), то обязателен ежедневный бекап БД (об этом тоже все знают, но забывают).
04.05.2009 в 20:35
+ Вести документацию. Хотя бы очень краткую. В большей степени она нужна самим разработчикам.
19.05.2009 в 14:54
Очень полезно новичкам
20.05.2009 в 18:01
Чтото давно не пишите..Небось чем то важным заняты? Расскажите что за проекты) Ждем новых постов.
26.05.2009 в 17:31
jaguar:
Да, занят. Скоро напишу по этому поводу и расскажу о своих проектах.
08.06.2009 в 00:45
отключение php в папке не поможет, если файл потом будет инклудиться
08.06.2009 в 13:35
Игорь:
Куда он будет инклудиться?:)
08.06.2009 в 17:20
в sql иньекцию
09.06.2009 в 14:01
Это уже совсем другой тип ошибки.
11.06.2009 в 11:35
Довольно полезно, почерпнул для себе новго
06.07.2009 в 11:55
Извините за то, что не в тему, но почему блог так давно обновлялся? Понимаю, что у вас наверное много работы и т.д. и т.п., но так не хватает новых статей(((
06.07.2009 в 17:08
DEM:
К сожалению не хватает времени + действительно много работы. Мне самому бы хотелось чаще писать, но пока не получается.