index0h

Самая сложная задача - вести nn-летний HL проект по критериям: производительность / безопасность / покрытость тестами / новизна с эдак сотней разработчиков. )))
Но это все равно проще, чем читать не-сформированные мысли людей о "магии"

Не существует систем которые нельзя взломать. Цель любой защиты - сделать ее взлом не выгодным, не более того.

Нужно придумать название возможно в будущем своей студии. Это готово: Creativix

Простите, но первое что пришло на ум:
- Ало, это Internation World SMM digital group?
- (шепотом) Да
- А почему шепотом?
- Я на математике.

Аренда VDS хостинга

DO

Нужно сделать свой сайт, продвигать его, и реклама....

Вы определитесь, кто вы. Developer/PR/Manager/Sales. Слово "компания" предполагает, что у вас есть сотрудники.

..., а так же на Bitrix-е

nooooooooooooooo

Разработать свою CMS.

Не стоит, результат будет говном 99.99%

Свой движок в какой то степени привязывает клиентов ко мне.

Клиенту обычно побоку. Единственное, чего вы такими действиями добьетесь - лишний литр крови из глаз у следующего программиста и большую цену за его услуги.

А так же мне кажется на бесплатных движках далеко не уедешь, для более крупных проектов нужно сделать удобную CMS под себя.

У более крупных проектов, как правило, не используется CMS вообще.

А дальше по мере развития, открытие ООО, покупка своих серваков, переезд в офис и тд

Замечательно звучит, на сколько лет вперед проработан ваш бизнес план?))

Определитесь с тем, кто ваши заказчики и что вы им можете дать.
Подписывайте договор и ТЗ.
Берите предоплату.
Акты приема-сдачи работ оформляйте итерационно, например дизайн - Х-денег, верстка - Y-денег, программная часть Z-денег, интеграция M-денег, поддержка N-денег. При такой схеме - ваши риски минимальны и вы можете разорвать договор с минимальными убытками для себя. Заказчик тоже не в обиде, на каждой из итераций он получает готовый результат, с которым может делать все что угодно, вплоть до обращения к вашим конкурентам. Каждая итерация обговаривается и утверждается вместе с заказчиком.
Если заказ 50к вам не выгоден - вежливо скажите об этом, если получите пену у рта - завершайте общение.
В принципе не плохим поинтом может быть открытие для заказчика баг трекера по конкретно его проекту (но с правами не более баг репортера, или наблюдателя), учтите заказчик MUST NOT заниматься микроменеджментом. Если у него возникнут замечания/пожелания на уровне "поправить-за-5-мин" - просто сделайте это, если же из сайта визитки захочет свой гугл - договоритесь до одного из:
- пересмотра итераций и изменений в ТЗ, без этого не продолжайте работу
- завершение текущей и создания новой итерации + ТЗ
- завершения итерации и договора

Обзаведитесь хорошим сейлом))

И самое главное - не делайте говно.

UPD

Тут littleguga добавил дельный комментарий)) Помните, госконтора - это ящик Пандоры

Фикстуры

Часто это пример привожу, приведу еще раз:
Вы каким прибором еду кушаете: вилкой, ложкой, ножом, или руками? Мне так кажется, что в зависимости от блюда.

С backend то же самое: одни технологии круты для одного, другие - для другого. Вы скажите, что именно хотите делать, уже на базе этого стоит подбирать компоненты.

Например чатики и системы, завязанные на событийность - под nodejs будут себя не плохо чувствовать.
Под файловые распределенные хранилища - mogilefs.
Под процессинг данных - все, кроме nodejs и php.
Под очень серьезную мультипоточность - erlang.
Под быструю разработку И высокую скорость - golang.
Под еще более быструю разработку - php.

Не используйте слово "простой" и его синонимы, никогда))

Алгоритмы поиска пути по множеству измерений (время, пробки, расписание транспорта, маршруты этого же транспорта, топология местности, пдд и другие) - не самая простая штука.

Где данные по каждому из измерений брать будете?

Вы на какую нагрузку рассчитываете 0.1 rps, или 10000rps? Это тоже играет не малую роль.

На какой бюджет вы рассчитываете?

Что на счет масштабирования горизонтального/вертикального?

Сколько планируете нанять прогеров / безопасников / базюшников / тестрировщиков / менеджеров / бухгалтеров / маркетологов / сеошников / smm-щиков?

----

Если ваша цель "на коленке" - пишите на том, что знаете, так вы хоть время съэкономите поняв, что это гиблое дело))

В случае, если шаблонизатор не используется - это вполне нормальная практика.

С помощью какого прибор быстрее всего можно съесть много еды?)) Вы предположили, что это ложка, но тут вам приносят стейк.

ЯП выбирается под проект. Если вы ориентированы на сверх хайлод уровня высокочастотного трейдинга - то вам даже железо специальное покупать нужно будет и БД использовать специфические, например kdb+.

При выборе ЯП на самом деле вы выбираете инфраструктуру, которая должна прежде всего решать бизнес задачи. Например вы таки психанули и написали проект на Erlang, ок рано, или поздно - упретесь в железо, для ХЛ - это вполне норм ситуация. С точки зрения бизнеса прошаренный эрлангист стоит довольно дорого, а команда - тем более, на много дешевле выбрать другой ЯП с большим сообществом + более дешевыми специалистами, даже с несколькими лишними серверами.

Открой резюмешку любого синьйора - там будет примерно 10-я часть того, что он использовал))

Перефразирую ваш вопрос: почему машина не едет? Дворники работают, колеса накачаны, даже когда жена за руль села - не едет.

Веду к тому, что сайт может "не работать" по дохреналлиону причин, а вы ищите ответ не там.

ping - отвечает на вопросы:
* доступен ли с клиентской машины в принципе сервер на уровне сети
* сколько времени занимает запрос/ответ

CMS стоит использовать если она в полной мере решает основные требования ТЗ, в противном случае - не стоит. Например если вам нужен блог - выбор очевиден, это wp, если вам нужен эл. магазин - PrestaShop, если сайт-визитка MODx. В случае, когда задача сильно отличается от того, что предлагает CMS , ее использоуавть не стоит потому, что в основном будете бороться с самой CMS.

"С нуля" пишут только:
* для получения опыта
* что-то быстрое на 50 строк
* "что-то уникальное" (к сожалению 95% этого - шлак)
* программисты, считающие себя Д'Артаньянами

Обычно система строится на базе фреймворка, он в свою очередь подбирается под ТЗ, например Symfony хорош для сервис-ориентированной архитектуры, Zend - как набор библиотек, Yii - для средних целостных проектов, Silex - для небольших проектов, так же не плох Laravel.

Вы правда считаете, что в одном комментарии можно изложить 3-х летний (как минимум) опыт?

Вы для начала почитайте, что такое API в принципе. CMS без API вообще-то нету.

1) отслеживать медленные страницы на сайте

StatsD

2) понятность в просмотре результатов

Graphite / Logstash + Elasticsearch + Kibana / Sentry

3) на выходе - график/табличная статистика:
4) ссылка
5) среднее/максимальное время загрузки
6) возможность задавать маски (многие ссылки имеют динамические параметры)

Все зависит от того что и как будет логгировать

7) мониторить коды ответа сервера.

Парсинг логово apache/nginx через Logstash

Ваш вопрос - сплошное противоречие))

Посоветуйте онлайн справочник для работников sale отдела по ведущих веб технологиях.

Перефразирую: посоветуйте справочник для грузчиков по ведущих направлениях современного дизайна.

В идеале что-то типа FAQ.

Справочник и FAQ это абсолютно разные вещи.

Википедия хорошо, но очень тяжело для не специалиста.

Если тяжело получить представление самое базовое о технологии на основе wiki... Это бессмысленная трата времени.

Бомбануло... Дело в том, что ведущих технологий огромнейшее множество, часть из которых обычный человек даже не поймет зачем.
Например: зачем в проекте может одновременно работать множество разных систем кэширования?

По сути то, что вы спрашиваете для sale отдела с вероятностью 99% либо не даст профита, либо только навредит. Был как-то случай забавный: система пилилась на протяжении 4-х лет, кода немеренно, и тут пришел новый глава sale отдела и говорит: "а давайте все перепишем на %cms_name%, там все просто", к слову 60% web отдела заявило сразу "если это произойдет - мы увольняемся". Проблема тут не в том, что sale ничего не смыслит в web-программировании, а в том, что думает что что-то смыслит.

1. Правки на проде (хостинге) - это только диплой, или решение экстренных проблем уровня "не работает главная страница" и выше. Другие правки обычно признак говнаря))
2. VCS - обязательно, например git. В случае, если ваш сайтик взломают у вас будет возможность быстро понять, какие файлы были потроганы, в противном же - нет.
3. Ведите разработку на окружении максимально приближенном к проду, если там ОС Win7 и Denwer - используйте их, в противном случае НЕ используйте. Вполне норм решением является разработка под vagrant-ом. По поднятию окружения можете посмотреть тут.
4. Для изменений БД обязательно используйте миграции.

Копайте в направлении HTTP + HTML + PHP

Какие технологии веб-разработки лучшие на данный момент?

Я вам по секрету: каждая технология лучшая для своего стека задач.
То, что вы спрашиваете - примерно как: что лучше, ложка, или вилка? Для борща вилка не очень то подходит, но это не значит, что вилка хуже ложки.

какой стек технологий максимально эффективно использовать сегодня для создания SPA?

Frontend: JS+HTML+CSS, из фреймворков: подберите под свои задачи из Angular/Backbone/Ember/...
Backend: полностью зависит от ТЗ
Могут быть интересны и комплексные решения, например Catberry.