Muhammad

> В связи с этим, мне кажется, что профессия веб разработчика становиться через чур высококонкуретной, я бы даже сказал профессия веб разработчика дискредетирует себя (недавно зашёл на сайт в какой-то канадский колледж, посмотреть сколько стоит обучиться на веб разработчика

Попробуйте устроиться веб-разработчиком даже не в Facebook, а, например, в Yandex или Badoo.
По результатам попытки мы можем обсудить вопрос уменьшения престижа профессии и увеличения конкуренции. :)
Далеко не весь спектр задач, решаемых инженерами-разработчиками (в том числе, и на PHP), представлен на биржах фриланса.

конфликты мерджей очень сильно тормозят

1) Дробите задачи, делайте ветки короткоживущими
2) Хорошая идея делать ребейз принятых веток
3) Попробуйте адаптировать под себя git-flow, как альтернатива хорошо себя показывает feature-toggles вместо feature-branches

Да и бд экспорт/импорт постоянно приходится делать.

1) Миграции
2) Старайтесь делать миграции так, что бы они не ломали предыдущие релизы. Ну мол если вам надо добавить колонку, хорошей мыслью будет в первом релизе сделать ее nullable что бы старая версия приложения еще могла работать с новой версией базы, и потом уже следующим релизом добивать этот кусок. Основная идея - желательно что бы две последние версии приложеньки могли работать с последней версией базы данных. Если у вас база нормализована нормально, то проблем с этим быть не должно.

Если второй пункт соблюдается то вакатка новых релизов будет происходить по такому алгоритму:

- выкатывается новый билд приложеньки в отдельную директорию (можно автоматизировать, организовать ротацию билдов и т.д.)
- накатываем миграции на базу, в этом случае у нас старая версия приложения будет работать с уже новой структурой базы
- переключаем webroot на новую версию. В случае с контейнерами (docker) тушим старый контейнер
- если что-то идет не так, мы можем быстро поменять симлинк обратно и запустить откат миграции

При таком сценарии даунтайм будет минимальным.

вопрос с выкатыванием новых релизов

Вот вам варианты в порядке сложности и мощности (от простого к сложному).
- capistrano/capifony
- ansible/puppet/chief/etc
- docker + docker-machines + docker-compose

Ну и да, тесты тесты тесты. Все самое критичное должно быть покрыто хотя бы интеграционными/функциональными тестами. В идеале же вся бизнес логика должна быть покрыта быстрыми юнит тестами и UI/инфраструктура функциональными (читать про пирамиду тестирования).

README.md файл с описанием проекта, особенностями и мануалом как его собрать
git репозиторий
+gitignore
gulp/grunt/make/bash скрипт для сборки и минификации
изображения по согласованию с заказчиком:
- оптимизирутся на месте
- оптимизирутся только для продакшена

+ humans.txt

Передается все вместе в готовом виде в зип архиве (если заказчик продвинутый - tar.gz)

Побуду диванным критиком, что-ли.

1. Обратите внимание на шрифты - они у Вас на сайте ужасны. Если с фронт-эндом работаете, то это важно.
2. Верно выше подметили, что не надо указывать навыки в процентах. Что это вообще должно значить? Лучше обычным перечнем, примерами - что могу, что не могу. А так - вроде красиво, но толку ноль.
3. В опыте работы долго не мог понять что за бредовое слово "Констракшин". Думал-думал что за скилл такой, оказалось это часть названия конторы. Может, логичнее было бы всё название в скобки засунуть и сделать ссылкой на их сайт?
4. Личные навыки: Целеустремлённость, быстро-обучаемость, ответственность, усидчивость." - люблю такое, вроде молодец, а вроде все такие. Если позиционируете себя как новичка в фронт-энде - пишите об этом, типа "За полгода перешел на 100% валидный бутстрап-хтмл5-ксс3 код с говно-табличной верстки на коленке". Это более важный факт, чем усидчивость - она в туалете хороша, а верстальщику важнее работу свою любить и стандарты уважать.
5. Портфолио, конечно, смех да и только. 3 готовых чужих темы и сайт кремлевского дворца, который выглядит как поделка с урока информатики в школе. Это всё, серьезно? 30.000 рублей с таким портфолио предложит только совершено конченный руководитель.

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

1. Один создает, за ним и все права
2. Закачивает все свои файлы
3. Другие разработчики скачивают все файлы
4. Правят/добавляют что им надо.
5. Перед тем как закачать изменения, проверяют кто-нибудь закачал что, если да то скачивают и проверяют нет ли конфликтов или не ломает чего их код
6. Если все хорошо то проталкивают свои изменения

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

1. Параллельные потоки загрузки и обработки данных
2. Управление уровнем ошибок для продолжения или прерывания обработки ресурса.
3. Обработка и сегментация данных из ошибочных и неверных структурированных данных (например, HTML/XML).
4. "Решето" (правила) для предотвращения дальнейшей обработки ресурса на основе уже полученных данных (условия алгоритма прописываются в конфиге).
Например, контент размером более 5 кб со словом "toster" или url содержит "toster.ru" - пропустить и перейти к обработке следующего.

Зачем вам подобная мертвячина?))

давно он появился на php.net в разделе stable releases?

Как сделал я.

От классических сессий при работе через API отказался.

1. Для авторизации пользователь вводит логинпароль, устройство отправляет их по https на account/auth
2. account/auth выдает token (token_id:token_val) и secret
3. все дальнейшие запросы устройство отправляет по http указывая token и подписывая запросы с помощью secret

Как работает.

Сервер получает запрос, видит что пришел token, разбивает его через двоеточие на input_id и input_val. Выбирает из базы токен с пришедшим input_id, получает из базы значение token_val и secret. Сравнивает input_val и token_val. Если в базе нашелся токен с нужным id и значения val равны, пришло время проверить достоверность запроса.

Клиент помимо токена передал sign (подпись), которую сформировал так (например) secret+api_path+query_param. На стороне сервера вам известно api_path и api_param, а secret выбрали из базы. Хешировать подпись принято через hmac().

Помимо токена и подписи можно передавать time и так же класть его в sign, и на стороне сервера отсекать запросы запросы которым больше 60 сек.

Таким образом.

Если кто то слушает ваш канал, он не сможет подделывать запросы (а значит компроментировать), и из-за проверки времени жизни запроса не сможет вечно получать данные по однажды перехваченного запроса.

А в базе токены можете хранить пока клиент сам не запросит их уничтожения и сохранить время последного обращения через токен, и удалять токены которые не использовались более 60 дн.

bcrypt в помощь.

// EDIT

Крайне неэффективно.

// EDIT2

Генерация случайной строки (вместо вашей функции salt, длину отрегулируйте):

bin2hex(openssl_random_pseudo_bytes(21));

Тестировал на L5 такой код:

<?php

use Illuminate\Foundation\Testing\WithoutMiddleware;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;

class HomeControllerTest extends TestCase
{
    public function testIndexPage()
    {
      \View::shouldReceive('make')->with('home')->andReturn('test');
      View::shouldReceive('share');

      $response = $this->action('GET', 'HomeController@getIndex');

      $this->assertResponseOk();
      $this->assertEquals('test', $response->getContent());
    }
}

Ошибки которые были:
- Нужно мокать еще метод share, он там где-то вызывается.

Вообще я не вижу смысла тестировать View фасад - там нечего тестировать.

Стоит. Однозначно.
В L5 множество различных плюшек (один улучшенный DI чего стоит).
Так же L5.1 объявлен как LTS, что очень хорошо для больших проектов.

>К примеру, насколько он быстрее/медленнее, чем 4.2?
Нельзя сказать однозначно. Зависит от используемых пакетов. Но в L5 улучшенно кеширование + добавили кеширование роутов, что значительно его ускоряет.

В основно Сергей Протько всё правильно ответил, дополню несколько пунктов:

5) Валидацию нужно делать в контроллере на уровне FormRequest. Метод register в модели не нужен. Можно сделать сервис UserRegistration, или использовать команды (раздел Jobs).

6) Отправку Email не нужно тестировать. Максимум что можно сделать, это замокать фасад или интерфейс Mailer и проверить что он вызывается.

для начала перестаньте мыслить папками и начните мыслить пространствами имен

1) где хотите. Простой вариант - в неймспейсе Repository. В целом почитайте про шаблон репозиторий
2) А какой в этом смысл? Есть смысл делить по поддерживаемым хранилищам (Database, InMemory, etc), только так у нас могут быть две реализации UserRepository
3) в сервис провайдере логичнее.
4) Там и храните, еще можно переименовать в ServiceProvider
5) Обычно регистрация юзера это new User, или в случае Laravel - статическая фабрика... или сервис. Вообще валидация тоже должна происходить на уровне контроллера, но тут уж как выходит.
6) без различных катчеров - у swift mailer есть spool, но как по мне это не столь удобно.