Вячеслав Плиско

У меня был похожий опыт, был небольшой проект и время. Клинтскую часть решили делать на angularjs. Серверную хотели сделать на yii, поковырали, попробовали стартовую сборку, в итоге плюнули и взяли nodejs+expressjs, разобрался быстрее чем с yii, были проблемы с некоторыми либами для работы с ftp и excel, но по веб части нареканий нет.
Главный плюс — научился работать с асинхронным кодом.

Недавно нужно было внести правки в часть проекта на RoR, опять же, было легко, но чуть дольше осваивался, т.к. ruby не так привычег как javascript. Но очень помогло знание php фреймворка laravel.

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

Вы, наверное, не снесли папку с настройками. Может у вас проблемы с фаловой системой, или проект битый. МОжете попробовать rc поставить, она уже достаточно стабильная и бегает быстро. Ах, да, ещё обновите java машину, проверьте, чтобы не со старой версией работало, особенно если вы пользуетесь openjdk

Для дев машины на виртуалке лучше использовать
xdebug.remote_connect_back=1
и посмотрите, пробрасывается ли XDEBUG_SESSION

dom и потоковый xmlreader умеют обрабатывать ошибки, так что валидность не такая большая проблема.

Забейте на MVC, он просто предлагает делить зоны отвественности между слоями, сами буковки для красоты и примера.

вот смотри, у тебя есть модель tariff и ты ей там же через массив передаёшь параметры.
ты пишешь $tariff = Tariff::findById(1); // SELECT * FROM tariff WHERE id =?
затем тебе нужно скривать старые тарифы.
$tariff = Tariff::findById(1); // SELECT * FROM tariff WHERE id =? AND hide <> 0
Затем у тебя тариф привязывается к городу и т.д.
Все эти правки ты делать водном месте в методе Tariff::findById, а плюсами пользуешься по всему коду.

Контроллер, у твоём варианте ты пока делаешь валидацию и работу с данными формы через него, а затем это надоест и создашь классы validator и form и постепенно через рефакторинг нафигачишь десяток слоёв, которые будут хорошо делать только свою задачу. Но не надо имея легаси код сразу продумывать как ты разделишь классы, нужно рефакторить и плесать от того, что получается.

В коммит кодируется информация о номере таска и его название. Ваш пример хорошо подходит на commit ---amend, для этого и нужны ветки, чтобы опечатки не фиксить отдельным коммитом. Я в целом стараюсь придерживаться по возможности правило — один таск, одна ветка, один коммит и amend позволяет не размазывать логику по коммитам.

гит здесь не при чём, у вас банальные зависимости, в мире php это решает через pear или composer, в других языках есть свои пакетные менеджеры. каждый пакет хранится в своём репозитории и имеет лишь файлик, прописывающий зависимости.

bootsnipp.com, особенно bootsnipp.com/resources
сходи на сервисы типа jetstrap.com/, посмотри какой код они генерят.
попробуй делать темы, для этого лучше знать less.
и т.д.

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

А как вы смотрите посланные заголовки? эта функция www.php.net/manual/ru/function.apache-request-headers.php оставляет всё как есть

А вы IDE не пользуетесь, у них локальная история есть, оттуда прекрасно всё достаётся, самого пару раз спасало от случайного удаления.

Срочно сбросьте с себя это ярмо. Пускай разработчики сами разбирают задачи, ориентируясь на свой опыт. Количество работников на проекте может быть динамичное. У нас даже джуниоры сами себе таски набирают.
Если на проекте один разработчик, то на время добрасывайте второго, пускай парнопрограммируют, чтобы проект полностью не был завязан на одном разработчике.

Я подобную систему советовал сестре для её тестеров. Правда, у них получилось, что часть важных задач всё же распределяет она. Здесь всё сильно зависит от команды и нужно подстраиваться, делая ретроспективы и обсуждая что последнее время делалось хорошо, что плохо, решать проблемы.

Работ в Сиклуме, там аутстаффинг, честное и открытое посредничество. При том особых мыслей убрать посредника ни у одних, ни у других не вохникает, так как все понимают плюсы. У меня, чесная белая работа с чесной белой зарплатой, скрам мастер помогающий общаться с заказчиком, прекрасные условия работы, куча интересных коллег, возможность для обучения и т.д и т.п. Заказчик тоже рад гарантиям и сервису.

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

Сейчас по некоторым причинам практически не работаю и лишь изреднко берусь за хороший фриланс и понимаю, что сам готов платить хорошему посреднику.

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

p.s. А откуда статистика?

[шутка]Мне всегда казалось что менеджеры резюме оформляют в PowerPoint в виде графиков.[/шутка]

Из моего опыта, параметр который качественно характеризует менеджера — продолжительность работы в компаниях, лояльность. Если менеджер работает к компании большой срок — значит он хороший менеджер, он не сбежит при трудностях и не рассорится с командой или руководством. А с пятью месяцами вам нужно хорошее объяснение почему так мало проработали, при этом не стоит гнать на компанию коллектив, идеально — завершение проекта, отсутствие нового в той же компании.

packagist.org/search/?q=fuelphp — 3 страницы
packagist.org/search/?q=laravel — 29 страниц
думаю, вывод очевиден.

я бы начал борьбу с 6-3 секундной функции, например заменив на вызов системного типа find. -print или tree, а так у вас самая большая проблема — инвалидация кеша, при том, что для файлов актуальность важнее скорости.

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