Перевод: Этика Code Review

Ну вот вроде все правильно, но уже не раз в своей практике сталкивался с тем, что человек, код которого проверяется, просто морально не готов слушать критику и тем более смириться с отказом в принятии пачта, даже если он в проекте «15 минут». бОльшая часть замечаний проход под лозунгом «Окей, я учту в следующих задачах». Тут еще, как мне кажется, важна разница в возрасте — старшие товарищи по цеху хуже воспринимают критику. Доходило до того, что мне тыкали поездкой на "… всесоюзную олимпиаду по программированию для школьников, аж в Москву ездил". А ты, мол, тогда еще пешком под стол ходил.

фуу, накипело :)

посоветуете что-нибудь?

Перевод: Этика Code Review

Я с мобильного приложения смотрел, не нашел. Но все-равно спасибо :)

Перевод: Этика Code Review

Спасибо!

Перевод: Этика Code Review

а можно ссылку на оригинальную статью?

Composer — the right way

Не могу согласиться, к сожалению: при маленьком изменении в вашем коде с большим изменением (например — мажорная версия) в вендорском коде, вы ревьюер в diff-е ничего путного не увидит. Сам change вашего кода может быть вообще в этой куче потерян.

Composer — the right way

На боевом сервере никто билды ранить не будет, туда переносится уже готовый и протестированный пакетс test/stage. Так что эта проблема не рассматривается в контексте данного обсуждения.

Composer — the right way

За ссылочку спасибо!

Composer — the right way

Но ведь эта дискуссия как раз о рабочих проектах, а не библиотеках, которые вы выкладываете на GitHub. С ними, в свою очередь, тоже все понятно.

Composer — the right way

Не понятно, кто этим будет заниматься.

ну почему же — в каждой команде есть обычно ответственный человек, aka team-lead / architect который должен принимать подобные решения.

По хорошему это должно решать на уровне некоего центрального репозитория.

на уровне компании / проекта или всего php сообщества?

Composer — the right way

вы злой

Composer — the right way

У меня тоже была мысль привести его в качестве примера. Вопрос только в том, что он платный, а значит обосновать придется хорошенечко. Пробовали его в своих проектах?

Composer — the right way

где-то рядышком

так ведь это ключевое замечание. Обсуждение подразумевает хранение вендорского кода прямо в репозитории с проектом. В одном репозитории.

Composer — the right way

Ну это скорее вопрос выбора библиотек, получается. Понятно, что не нужно тянуть в проект все, что «подходит по теме». В данном случае имеются в виду официальные SDK для сторонних API, например, или инструменты автоматизации.

Composer — the right way

Мне не хватило доводов в пользу отказа от хранения вендорского кода локально, именно по этому я написал сюда, а не на тостер. Мне нужны аргументы за и против + статистика по опросу. По-моему Хабр для этого и создан, разве нет?

А вот про Sphinx 3.0

> В документации есть куча информации про SQL, но вот инструмента в котором можно этот sql ввести я не нашёл. Как щупать это чудо?

mysql -P9306 --protocol=tcp --prompt='sphinxQL> '

Ну еще можно добавить хост соответственно.

9 бесплатных тестов для профориентации

Согласен, тест хороший. Осталось только понять что теперь делать с результатами :)

А чем, кстати, на графике отличается цвет полосок? У вас оранжевые, у undestroyer синие с оранжевым, у меня зеленые…

Статический анализ кода в PHP: регулярные выражения

Settings -> Editor -> Inspections -> PHP -> Php Inspections (EA Extended)

Спасибо, именно то, что искал.

Статический анализ кода в PHP: регулярные выражения

Спасибо, поставил. Будем пробовать.

А подскажите еще, пожалуйста, где найти настройки плагина?

Введение в разработку слайд-шоу на JavaScript

О чем вы? просто используйте checkb-box хак и css. Например вот так: www.warface.com/en

А вот про Sphinx 3.0

Спасибо за объяснения.

dict=keywords + docinfo=extern

ну тут все понятно, а

отсутствие hitless итп

— это что? Где можно почитать?