Александр Кубинцев

Если решать проблему технически, то сперва надо определиться с частотой обновления или точностью. Что значит пользователь сейчас смотрит эту страницу? Активная вкладка браузера? А если он отвёл взгляд? )) И нужно ли действительно иметь такую высокую точность, какую бизнес-задачу это решает?
На вскидку есть 3 способа:
1) "дедовский": строить логи nginx таким образом, чтобы их удобно было парсить и брать число запросов на нужные страницы в интервал сканирования
2) собирать статистику на уровне роутера приложения в redis (как предложили недавно выше)
3) самый точный, но слишком накладный, это вебсокеты открывать на странице и считывать откуда они.

Прежде всего веб-сайт компании это канал продаж. Всё остальное выстраивается вокруг этого положения.

Как показал мой немалый опыт, больше года сидеть на подобных местах вредно с профессиональной точки зрения.
Однако всё зависит от вашей жизненной стратегии.
Если вы планируете создавать собственный бизнес или понимаете, что работа не-бей-лежачего, а деньги хорошие, то это может быть неплохим фундаментом, чтобы освободить руки для работы на себя и не терять источник доходов.

Ставим IDE, ставим xdebug в т.ч. включаем его и для php CLI.
Прописываем переменную окружения:
export XDEBUG_CONFIG="idekey=phpstorm"
, где idekey тот, который прописан в конфигурации модуля xdebug и IDE.
Ставим брейкпоинты, запускаем демона и трассируем.

Есть два способа решения задачи.
1) Сделать прикрепление файла непосредственно в обработчике формы обратной связи
2) Сделать крон-задачу, которая будет сканировать почтовый ящик, парсить письма и отвечать на них.

Проще конечно сделать первое. Берете composer и любую библиотеку для работы с мылом, к примеру swiftmailer

По-моему идея с вебсокетом не очень хороша.
Лучше послать команду и указатель на ресурс для воспроизведения, а остальное пусть возьмет на себя традиционный HTTP. Вам лишь потребуется настроить на бекенде потоковую трансляцию в нужный файл.

Если стоят подобные вопросы перед вами, то возникают сомнения в компетенции разработчиков. Поскольку профессионалы сами выбирают те инструменты, с которыми им удобнее работать. А у руководителя должны быть совсем другого рода вопросы и метрики.

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

CI - это автоматизированная сборка проекта на основе версионного контроля и прогон тестов.

Собственно, начинать надо с задачи реализации деплоя.
Деплой сделать - задача нетривиальная. Есть для этого разные инструменты и универсального решения нет. Отладить процедуру деплоя нужно для сборок в CI и для продакшена/стейджа.
Лично я для своего последнего маленького проекта для выкладки в продакшн выбрал deploybot.com - в принципе всё, что нужно есть, в том числе и хорошая интеграция с DigitalOcean.

Что касается инструмента для CI, то из бесплатных обычно пользуются Jenkins. Я пробовал в последнем проекте PHP CI - тоже годно, но не настолько гибкий инструмент.

Выкладку на продакшн/стейдж можно настроить по-разному. Например по коммиту в специальную ветку, по ключевым словам в коммите или вообще вручную. На прод однозначно стоит делать выкладку вручную.

А, еще один немаловажный момент. Для успешного функционирования этого всего дела нужно внедрить версионирование схемы БД и фикстуры (для CI).

Жизненный цикл у нас был такой. Тимлид определяет некий не большой, но и не очень маленький набор фич, которые должны попасть в новую версию приложения. Все тикеты связаны с версиями. И поэтому может случится так, что даже готовую фичу он определит в другую версию продукта.
Каждая готовящаяся к релизу версия получает свою ветку в git и там делается мердж нужных коммитов с фичами. Каждый коммит автоматически тестируется в CI.
Когда все фичи сделаны и коммиты слиты, то можно залить на стейдж сервер и погонять вживую версию в условиях близких к боевым. И наконец, если всё хорошо, то делается деплой на продакшн.

Было бы желание - можно хоть только по одному гуглу написать.
Вопрос лишь в том, как быстрее получить практические навыки.
Мне лично книги по программированию вообще очень мало помогли.
Я рекомендую записаться на курсы программирования. Живое общение всегда эффективнее, чем чтение технической литературы, которая устаревает очень быстро. Всегда сможете задать вопрос преподу, нередко выходящий за рамки курса и хоть какую-то ясность получить.
Из того, что мне попадалось на глаза (искал, поскольку сам подумываю сделать свой курс), наиболее приличной показалась программа здесь geekbrains.ru/professions/13

Каково быть программистом?
Я не стану писать про идейно-мотивационную часть, этого всегда хватает в ответах на такие вопросы. Только прагматичный взгляд.
Да всего хватает. И мартышкиного труда, и действительно интересных задач, связанных с проектированием. Много зависит от того, какой проект и на какой фазе своего существования. Поэтому вы и увидели частые смены работ у наших коллег.

Немного могу ободрить на тему начальных зарплат в веб-деве. 25-30к - это для студентов. С ходу же можно найти место за 50-60к, но конечно должна быть хоть какая-то минимальная база знаний, чтобы пройти собеседование. Надо только понимать, что в одной конторе за зарплату X рублей будут искать чуть ли не тимлида, а в другой - джуниора. Немного терпения или везения и найдёте, что желаете. Главный вопрос задайте только себе "чему я смогу тут научиться (и у кого)?", иначе в пустую потеряете время и нервы.

Но в работе стажировщика-студента есть плюс - дадут реально фундаментальную базу и прыгнуть потом можно спокойно уже на уровень 80к (вы только не сознавайтесь, если спросят, сколько платили на прошлом месте :)))

У каждого свой workflow сложился и имеется своя специфика отрасли. У меня, к примеру, часто бывает так, что скидывают большой талмуд технической документации по какому-нибудь внешнему сервису, с которым нужно начать работать как можно быстрее. Так что требуются навыки быстро ориентироваться в такой информации и её применять Однако, я работаю удаленно и числюсь штатным сотрудником с рыночной зарплатой специалиста моего уровня.

По поводу фриланса. Не стоит питать иллюзий. Это среда высококонкурентная со своей спецификой. Часто можно услышать, что можно заработать кучу денег таким образом, но это в самом идеальном варианте. Я не первый месяц наблюдаю за Upwork/Odesk и не вижу особого разнообразия интересных задач, подходящих под мои скиллы. Считается к тому же, что один из лучших вариантов это получить долгосрочный контракт. Да вот только не так их много в сравнении с тем, что может предложить локальный рынок труда, не говоря уж о входном пороге. Опять же, сидя в офисе будут периоды, когда можно будет плевать в потолок, а с фрилансом такое не прокатит.

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

Думаю самым разумным решением будет либо искать другую ПС, либо написать прослойку на web-сервере, которая будет формально выступать для PoL как интернет-магазин. Со стороны андроид-приложения шлёте запрос сперва на генерацию номера заказа, затем запрос с этим номером заказа + суммой + прочее на создание платежной формы (www.payonline.ru/developers/SDK/php/) и проблем быть не должно: всё по фэн-шую, то есть PCI DSS.

Если python дружите, то посмотрите на tornado

Соблазнять низкой стоимостью труда. Полгодика хотя бы побатрачить и идти дальше. Просто потому что наиболее вероятно вы попадёте в говноконтору, в которой можно набить руку только на простейших задачах.
Может правда и повезти: попадёте стажером в контору поприличнее. Но в моё время этого не было.

Если речь идёт об интернет-банкинге, то прежде всего надо отталкиваться от PCI DSS.

Этот способ нарушает принцип когда GET запросы используются только для чтения.

Не стоит так заморачиваться в данном случае. Но если хотите, сформируйте в HTML форму с POST запросом по сабмиту.

По таким ссылкам могут ходить боты. Если у пользователя почта на yandex или google, то боты читают почту и переходят по ссылкам из писем.

А валидация почты вовсе не для защиты от ботов. Основная цель - удостовериться, что почта была введена корректно и с ней работать дальше.
Можно конечно попытаться отсеять ботов, но ценой юзабилити: сделать переход на страницу, где будет требоваться ввод капчи для окончательного подтверждения.

Есть два пути:
1) объяснять зачем нужен единый и адекватный стиль кода
2) использовать административный ресурс

Второй путь более эффективен с точки энергозатрат и результата. Но, соответственно, нужно иметь утвержденные стандарты стиля кода.

Как хост-система OS X или Windows. Потому что более стабильны, чем большинство десктопных дистрибутивов Linux, потому что имеют вылизанную эргономику UI, потому что если надо верстать, то не учитывать IE нельзя, а работать с макетом дизайна в PSD весьма проблематично без Photoshop.
А вот виртуальная машина для веб-сервера однозначно на Linux благодаря удобству конфигурирования пакетами. Тем более, что можно настроить несколько разных сред.