Просто поставь wordpress.
Править
ShortUrlВнутренняя ссылка
На похапэ можно писать довольно быстрый код. Конечно, не такой резкий, как заточенный под конкретную задачу инстанс nodejs или, не дай бог, что-нибудь для веб на няшной с ассемблерными вставками.
Можно банально придерживаться паттерна mvc и не погрязнуть в паутине спагетти-скриптов с сотнями инклюдов. Код будет хотя бы структурирован и изолирован локальными кучками говнеца. Это идеальное состояние, если большую часть рабочего времени вы добавляете в общую свалку новые, независимые друг от друга конвертики с тухлятиной.
Можно написать классы объектов, там где они необходимы и наполнить их методами. Опять же, всё ради структурирования кода, для вполне сносной и быстрой навигации по разрастающейся выгребной яме проекта.
Можно вооружиться профайлером, раскурить исходники ядра фреймворка, который вам предписало начальство, и частично переписать его, снизив время выполнения этого хитросплетения пиздеца на 80%. Вырезать конфиг веб-приложений, сделанный в xml. Уничтожить миллионы вызовов __call() и call_user_func(), от которых кровоточат глаза. Большинство макак знает, что обычное веб-приложение на похапэ инициализируется каждый раз с нуля. Поэтому уменьшить на 90% время инициализации - это очень хорошая идея.
Можно искать узкие места и куски рендерера, где хтмл генерится недостаточно быстро. Вооружиться memcached и реализовать грамотные схемы самообновляющегося блочного кеширования. Избавиться от пары дюжин лишних запросов к бд на каждый чих. Получить 80% страниц, выхлоп которых отрабатывает без запросов к бд вообще.
Можно заняться очередями сообщений и перенести на них особенно тяжёлые куски процессинга картинок, видео, музычки, почты и прочего хлама, чтобы всё упиралось в длину очереди, количество воркеров и машины, эти очереди разгребающие, а не в число клиентов и их терпение к времени отклика от сервера.
Можно навесить плюшки в виде аякса, где это уместно, и местами перенести генерацию контента вовсе на клиент, вместе с тем сэкономив десятки тяжёлых запросов на отрисовку страницы целиком.
Можно взять сверхбыстрое простое хранилище типа redis и использовать его для сегментов системы, которые создают большую плотность не очень важных запросов к бд, типа учёта баннеропоказов, трекинга статусов online и логирования всякой поебистики.
Можно придти к мысли, что mysql с её слоупочными table locks и transactional safety и с её возможностью масштабирования только при помощи анальных расширителей не очень-то, собственно, и нужна в большинстве задач. Потратить 2 месяца и перенести огромную смердящую кучу наваленных друг на друга небольших пакетиков с говном на mongodb, на небольшой, но няшный кластер из нескольких replica sets по тройке лёгких машин. Ощутить невесомое изящество, с которой она похрустывает сотнями тысяч записей, прелесть schema-free и отсутствие дрожи в коленях, когда раньше ты запускал alter table на рабочей копии бд, глубокой ночью, потому что оно кладёт сервер на час-другой. А потом часами напролёт в умилении смотреть на графики munin, которые резко перебежали из погранично-красной зоны в самый низ зелёной. Финально включить eaccelerator и наслаждаться запасом в сотни запросов в секунду на отдельно взятом сервере начального уровня.
Можно дополнительно озаботиться настройкой nginx, убрать из конфига логгирование для файлопомойки, включить пяток жизненно-важных параметров, указать нормальные значения для буферов. Окончательно уничтожить апач, для которого был прописан reverse proxy для некоторых урлов. Выкинуть SATA-винты на помойку. Поставить дополнительно недорогих SSD и развернуть на них кэш для самой мелкой статики.
Только это всё не нужно. Ваш сайт, результат вашей работы никогда не получит хоть какой-то нагрузки. Когда на ресурс заходит 10 человек в день, а 90% хитов совершают боты гугла, можно хуярить страницы на 50, и даже на 150 SQL-запросов, ведь все таблицы бд влезают в оперативку, и страница даже на каком-нибудь позапрошлогоднем zend framework без твиков соберётся менее, чем за секунду. Да какой там фреймворк! Какой там MVC! Проще дёргать по необходимости разнородные готовые куски, часть кода бросить голодным доширак-макакам, и склеить всё воедино лишь-бы-работало спагетти-кодом. Ведь проект нужно было сдать ещё вчера, а завтра он будет навсегда забыт. И останется крутиться на задрипанном, надолго предоплаченном vps, в cron которому прописана ежедневная перезагрузка.
Я кончил.
используй готовое решение, с допиленной до нужного состояния мордой. Да, на PHP их дофига.
Зачем? Сайт состоит из одной страницы и админки. Ради формы отправления заказа и загрузки фоток в портфолио нужно ставить тяжелую и неповоротливую CMS??
Ок, спасибо за мнение.
На node можно сделать хороший динамический сайт, но это считается нестандартным подходом. Зато не придётся настраивать apache/nginx etc. Только node & npm.
Нода сильна пакетами из npm, там есть на любой случай. Для создания сайта тебе понадобится модуль Express, а также, вероятно, обвесы для него (раньше шли в комплекте, но теперь ставятся отдельно — в целях модульности и легковесности) типа Body-Parser & Cookie-Parser.
Нода сильна пакетами из npm, там есть на любой случай. Для создания сайта тебе понадобится модуль Express, а также, вероятно, обвесы для него (раньше шли в комплекте, но теперь ставятся отдельно — в целях модульности и легковесности) типа Body-Parser & Cookie-Parser.
Подход при создании веб-сайта (веб-сервиса) на node.js отличается от такового при использовании php.
php: .htaccess для перенаправления запросов (/article1488.html -> ?module=article&id=1488), серверная логика в .php-файлах, echo html-разметки на выходе.
node.js: за http-сервер отвечает модуль http (встроен в node), подключаешь к нему логику модуля express, в котором расписываешь логику своего сайта. В express выбираешь также предпочитаемый "движок шаблонов", отвечающий за связывание шаблонных страничек с твоими динамическими данными. Я предпочитаю ejs.
php: .htaccess для перенаправления запросов (/article1488.html -> ?module=article&id=1488), серверная логика в .php-файлах, echo html-разметки на выходе.
node.js: за http-сервер отвечает модуль http (встроен в node), подключаешь к нему логику модуля express, в котором расписываешь логику своего сайта. В express выбираешь также предпочитаемый "движок шаблонов", отвечающий за связывание шаблонных страничек с твоими динамическими данными. Я предпочитаю ejs.
зачти этот гайд, мне лично он понравился http://www.nodebeginner.ru/
если ты можешь в jquery, то для тебя всё будет просто, иначе будет фейл
вот ещо антоны зачтите http://habrahabr.ru/post/151117/
вангую нужно пиарить эту технологию
Ты перечислил лишь модули, реализующие веб-сервер. Это очень далеко от «любой случай» и я не понимаю, какую выгоду ты получаешь заменив уже готовый и зачастую установленный на хостинге Апач на самопоальный сервер.
> .htaccess для перенаправления запросов
Твои знания устарели лет на 15. Я никогда htaccess не использовал, а использовал роутинг в приложении
> echo html-разметки
стереотипы-стереотипчики
PHP программист берет готовый движок с готовйо админкой и меняет шаблон дизайна.
Node.JS программист делает npm install express body-parser (гораздо быстрее чем php-программист скачает и установит движок) и идет в кофешоп сидеть в твиттере.
> ejs
Отстой же. Его разработчики не учли опыт разработчиков PHP:
> <% } %>
Вот это вот кошмар. Twig (клон jinja) и встроенный в PHP шаблонизатор используют endif/endfor и т.д.
В JS кстати тоже есть клон jinja и twig под странным названием swig. Все остальные шаблонизаторы (microtemplating и клоны, mustache) отличаются каким-то самобытным неудобным синтаксисом, видимо их авторы не захотели изучать опыт других разработчиков, а захотели написать велосипед.
Ради экономии твоего времени (и увеличения отношения прибыль/затраченное время).
Часто быстрее подключить костыльный кеш страниц на memcache к wordpress, чем писать свое. И то это в том случае если хостинг дохлый или десятки тысяч посещений в день, если меньше то не надо.
>Ради формы отправления заказа и загрузки фоток в портфолио нужно ставить тяжелую и неповоротливую CMS??
Судя по твоему объему знаний осилить ноду или php-фреймворк и написать на этом хоть что-то работающее у тебя получится не раньше чем через месяц. Еще месяц ты это деплоить будешь, сервер настраивать, и в итоге получится хуже чем на вордпрессе.
К вордпрессу, как уже сказали, можно прикрутить кэширующий плагин, который будет сразу статику отдавать.
Хотелось бы закончить проект через несколько дней. Я уже почти сверстал, остался только сервер-сайд.
Итак, вопрос. Что будет легче освоить человеку, девственно нетронутому в области серверных технологий? Напоминаю, мне не нужно писать второй фейсбук, обрабатывать тысячи запросов в секунду... Простота, скорость освоения, многочисленное коммьюнити - вот что главное.
Вот мои варианты:
- PHP, который я не знаю совсем, но который вроде как простой и популярный,
- JS, с которым я хорошо знаком, но в душе не чаю как писать серверные приложения.
Что мне больше пригодится в будущем? Может, стоит пожертвовать дедлайном проекта (который я придумал себе сам, лол), но разобраться таки с нодом? Или пхп для общей эрудиции тоже будет полезен, да и напишу я на нем быстрее? Может быть, ты, Анон, хочешь предложить свой вариант? Feel free to comment.