You’ve probably found this post while searching for nginx and php (fastcgi with php-cgi) for windows. I ran into the “No input file specified.” problem and finally figured it out. The key is we are running on windows and not unix/linux. Windows paths are not /home/user/dir they are c:\cygwin\home\user\dir.
Keep reading for a complete How To nginx + php-cgi on windows :)
Так говорил учитель: ”Когда ты научишься ловить код ошибки по стеку корки, наступит твое время уходить”.
Нечто таинственное возникло, родившись из безмолвной пустоты. Одиноко и недвижимо ожидая, оно покоится и все же пребывает в постоянном движении. Это источник всех программ. Я не знаю его имени, поэтому я буду называть его Дао Программирования.
Если Дао хорошее, то операционная система хорошая. Если операционная система хорошая, то и компилятор хороший. Если компилятор хороший, приложение тоже хорошее. Пользователь доволен, и во всем мире воцаряется гармония.
Дао Программирования уплывает далеко и возвращается на утреннем ветре.
Дао породило машинный язык. Машинный язык породил ассемблер. Ассемблер породил компилятор. Теперь в мире десять тысяч языков.
У каждого языка есть свое, хоть и скромное, предназначение. У каждого языка есть отражение Инь и Янь в программах. У каждого языка есть свое место внутри Дао.
Но не пиши на Коболе, если можешь этого избежать.
Вначале было Дао. Дао породило Место и Время. Поэтому Место и Время – это Инь и Янь программирования.
У программистов, не постигших Дао, всегда не хватает времени и свободного места для своих программ. У программистов, постигших Дао, всегда достаточно времени и места для выполнения цели.
Как может быть иначе?
Мудрый программист слышит о Дао и усердно следует ему. Программист средних способностей слышит о Дао и ищет его. Неумный программист слышит о Дао и смеется над ним.
Если бы над ним не смеялись, Дао не было бы Дао.
Высокие звуки труднее расслышать. Движение вперед – пусть к отступлению. Большой талант проявляется на склоне лет. Великая белизна кажется покрытой пятнами. Даже в совершенной программе есть ошибки.
Наверное не все знают, что такое git и с чем его едят. git – это распределенная система контроля версий. Основные ее преимущества, лично для меня, распределенность и использование бинарных дифов, что упрощает работу с системой нескольких пользователей одновременно, и упрощает хранение бинарных файлов, ресурсов.
git используется во многих крупных проектах: Linux kernel, KDE и многих других.
Если вы работаете в ОС Linux, то можете собрать его из исходников или установить его средствами самой системы, например в RedHat, yum install git-all. Если вы работаете в Windows, то необходимо скачать MSysGit. Тут вы можете скачать и файлы для самостоятельной сборки дистрибутива msysgit-(net|full)install. Для пользователей MacOS есть своя разработка OSX Installer for Git. В состав сборок Eclipse или входят модули для работы с Git или их можно установить из основного репозитария платформы (EGit и JGit). В установке, я думаю, проблем не возникнет. После установки вам необходимо произвести начальные настройки git. git config --global user.name "Your Name" git config --global user.email "your_email@whatever.com"
Использовать системы контроля версий в работе это удобно и правильно. Вдаваться в плюсы не буду – если вы читаете эту заметку, то наверно уже решили установить SVN.
Собственно пошаговую настройку я и попытаюсь описать:доступ к svn будем получать через апач, так что он должен быть у вас установлен.
Для работы, да и просто для экспериментов, часто требуется отдельный сервер/VDS или же просто хостинг с Linux/Apache/MySQL/PHP, но аренда стоит определенных тугриков, а бесплатные решения в сети имеют множество ограничений, поэтому имеет смысл соорудить свой собственный виртуальный LAMP-сервер на домашнем/рабочем компьютере.
В качестве виртуальной машины (ВМ) будет использоваться VirtualBox, операционной системой хоста (т.е. нашего компьютера) у нас уже стоит десктопная Убунта, а в качестве гостевой системы возьмём Ubuntu Server (текущая версия 10.04), которая хороша тем, что в ней всё лишнее, для сервера, выпилено.
Довольно давно, я, да и наверное многие люди хранят свои конфиги на github. Оно и понятно, ибо это крайне удобно. Для хранения конфигов он подходит на ура, да и для проектов тоже, но вот бесплатный аккаунт, имеет некоторые ограничения, которые меня весьма сильно смущали. Главным из них, была невозможность бесплатно создать приватный репо. Конечно, сумма там незначительная, но платить мне ой как не хотелось, да и зачем, когда есть парочка личных серверов под рукой? Поэтому, сев писать с другом небольшой проект, решили «поднять» репо, на одном из «личных» серверов.
Я уже ни раз упоминал, и думаю будет не лишним сделать это ещё раз, что на серверах я использую Debian. Нам понадобятся: git, perl (нужен для веб интерфейса) и всё это будет под управлением lighttpd.
В последний месяц меня удивляют веб-мастера, многие просто помешались на сателлитах. Не знаю случилось это из-за On-Line Генератор Сателлитов, который быстро распространил по всему рунету интерес к сателлитам или по какой-то другой причине, но все же люди помешались. Как делается сателлит? Приведу один из способов. Есть тема. Подбираем под эту тему щаблон, для этого просто наберите "download free templates" в гугле и найдете много сайтов с такими шаблонами. Могу даже дать несколько хороших сайтов, где удобно и просто скачивать шаблоны: www.freetemplatesonline.com (при скачке указывайте свой майл и туда пришлют ссылки для загрузки шаблона), www.freshtemplates.net (раздел "Free Templates"), http://icetemplates.com/blog/42/free-templates-pack-1/.
На первый взгляд, кажется, что валидация необходима, ведь речь идет о сокращении количества ляпов разработчиков и написании «правильного» кода. На деле все обстоит гораздо сложнее и вокруг валидации до сих пор ведутся горячие споры об ее актуальности. Чтобы объективно раскрыть этот вопрос далее рассмотрим плюсы и минусы такой проверки. Плюсы валидации
Хотя HTML-код имеет достаточно простую иерархическую структуру, при разрастании объема документа в коде легко запутаться, следовательно, просто и совершить ошибку. Браузеры, несмотря на явно неверный код, в любом случае постараются отобразить веб-страницу. Но поскольку единого регламента не существует о том, как же должен быть показан «кривой» документ, каждый браузер пытается сделать это по-своему. А это в свою очередь приводит к тому, что один и тот же документ может выглядеть по-разному в популярных браузерах. Исправление явных промахов и систематизация кода приводит, как правило, к стабильному результату.
