Я бы сказал, что прежде всего работу скучной делает отсутствие цели. Когда по полгода толчешь в ступе одну и ту же воду без видимого результата.
Как этого избежать? Нужен так называемый «leadership». Не «доработать приложение для интеграции с клиентом XYZ», а донести до всех и понимание смыла, и эмоции. Как этому клиенту эту интеграцию продавали. Что эта интеграция значит и для него, и для компании. Какие люди будут счастливы иметь эту интеграцию и почему. Дать четкие сроки и четкое направление движения. И сделать так, чтобы при достижении цели все понимали, что это была Цель. Для технических целей всё примерно то же самое.
Как этого добиться? Я не знаю. Этот талант у руководителя или есть, или нет.
Очень похоже на метод сверху вниз, только с пляской от интерфейса, а не от кода.
Еще есть метод «снизу вверх» — когда программист сначала пишет кусочки конкретного функционала, а потом собирает их в работающую программу.
Сам по себе rebase не меняет автора коммита, так что если у ревьювера есть право пушить коммиты с чужим именем, то все ок.
Мердж коммиты плохи по двум причинам — сильно загромождают историю правок, т.к. по хистори не всегда можно понять, где был мастер, а где добавленное изменение. И второе — при разработке отдельной фичи считается хорошим тоном коммитить часто, но в хистори мастера лучше иметь фичу целиком в виде одного коммита. Автор пулл реквеста конечно может сквошить сам, но это неудобно, т.к. пулл реквест еще может дорабатываться после создания.
Хотя дело вкуса конечно. Можно потратить какие-то усилия и иметь чистую историю, а можно и не тратить и не иметь — это не критично для разработки в конце концов.
Зачем усложнять-то? Лично я против merge-commit-ов в мастере, так что делаю примерно так:
$ git remote add alice git://bitbucket.org/alice/bleak.git
$ git checkout master
$ git fetch alice
$ git merge --ff-only alice/master < — если упадет из-за конфликта или старого пулл реквеста, то просим Алису переделать пулл реквест
$ git diff origin/master < — смотрим вносимые изменения
$ git rebase -i origin/master < — опционально, если хотим поменять коммиты Алисы, собрать их в один коммит например
$ git push origin master < — готово
Собственно причины, по которым я это сделал:
— не требует установки, вся конфигурация в одном месте (чтобы всё не перенастраивать при переустановке системы)
— поддержка инкрементальных бэкапов
— возможность исключать файлы и каталоги по маске (очень актуально при бэкапе своих исходников, чтобы артефакты сборки не захватывать)
— если у двух пользователей одинаковые пароли, то и хеши у них будут одинаковые. Т.е. если хакеры слили базу паролей, то посчитав хеши по 1000 самых популярных паролей, они сразу смогут найти пользователей, у которых такие пароли. При наличии соли каждого пользователя пришлось бы брутить индивидуально
— простой sha1 плох тем, что в современных процессорах есть аппаратная поддержка этого хеша. Т.е. на разных системах скорость расчета хеша может отличаться на порядки, что усложняет выбор количества раундов — и чтобы было безопасно, и чтобы ресурсы сервера экономить.
Мораль — ставьте единичку в начало пароля, а не в конец)
А если серьезно — программистам, не юзающим хеширование с солью (даешь bcrypt!), нет оправдания. Кроме доработки старой системы, но и там возможны варианты.
В качестве дешевого и сердитого варианта я использую OTTP пароли через Google Authenticator — есть и сайты, которые его поддерживают, и библиотеки для написания своего софта с совместимой авторизацией. Правда, безопасен он только для тех, кто никогда не логинится с телефона, на котором установлен Google Authenticator.
Окончательно ушел с аськи на скайп лет 5 назад по трем причинам:
— в скайпе клевые групповые чаты, в аське их не было
— в аське окончательно доломали поиск людей по возрасту и городу
— голосовые звонки
В последнем скайпе жадный майкрософт начал показывать рекламу. Куда теперь уйти?
«Even though TLS specifications require servers to check the padding, some implementations fail to validate it properly, which makes some servers vulnerable to POODLE even if they disable SSL 3.0.»
И еще такой вопрос: В Википедии написано, что TLS требует всегда проверять, что при дешифровании padding заполнен правильными данными. Чем опасно отсутствие такой проверки?
Интересно про Padding Oracle и нестойкий CBC. Получается, что если мы хотим хранить на клиенте зашифрованные данные, ключ от которых есть только на сервере, то имеет смысл всегда добавлять к ним HMAC?
Как этого избежать? Нужен так называемый «leadership». Не «доработать приложение для интеграции с клиентом XYZ», а донести до всех и понимание смыла, и эмоции. Как этому клиенту эту интеграцию продавали. Что эта интеграция значит и для него, и для компании. Какие люди будут счастливы иметь эту интеграцию и почему. Дать четкие сроки и четкое направление движения. И сделать так, чтобы при достижении цели все понимали, что это была Цель. Для технических целей всё примерно то же самое.
Как этого добиться? Я не знаю. Этот талант у руководителя или есть, или нет.
Еще есть метод «снизу вверх» — когда программист сначала пишет кусочки конкретного функционала, а потом собирает их в работающую программу.
Мердж коммиты плохи по двум причинам — сильно загромождают историю правок, т.к. по хистори не всегда можно понять, где был мастер, а где добавленное изменение. И второе — при разработке отдельной фичи считается хорошим тоном коммитить часто, но в хистори мастера лучше иметь фичу целиком в виде одного коммита. Автор пулл реквеста конечно может сквошить сам, но это неудобно, т.к. пулл реквест еще может дорабатываться после создания.
Хотя дело вкуса конечно. Можно потратить какие-то усилия и иметь чистую историю, а можно и не тратить и не иметь — это не критично для разработки в конце концов.
$ git remote add alice git://bitbucket.org/alice/bleak.git
$ git checkout master
$ git fetch alice
$ git merge --ff-only alice/master < — если упадет из-за конфликта или старого пулл реквеста, то просим Алису переделать пулл реквест
$ git diff origin/master < — смотрим вносимые изменения
$ git rebase -i origin/master < — опционально, если хотим поменять коммиты Алисы, собрать их в один коммит например
$ git push origin master < — готово
— не требует установки, вся конфигурация в одном месте (чтобы всё не перенастраивать при переустановке системы)
— поддержка инкрементальных бэкапов
— возможность исключать файлы и каталоги по маске (очень актуально при бэкапе своих исходников, чтобы артефакты сборки не захватывать)
А то я в свое время поискал-поискал, и, страшно сказать, написал собственную софтину, делающую инкрементальные бэкапы на внешний HDD в формате zip
— простой sha1 плох тем, что в современных процессорах есть аппаратная поддержка этого хеша. Т.е. на разных системах скорость расчета хеша может отличаться на порядки, что усложняет выбор количества раундов — и чтобы было безопасно, и чтобы ресурсы сервера экономить.
А если серьезно — программистам, не юзающим хеширование с солью (даешь bcrypt!), нет оправдания. Кроме доработки старой системы, но и там возможны варианты.
В качестве дешевого и сердитого варианта я использую OTTP пароли через Google Authenticator — есть и сайты, которые его поддерживают, и библиотеки для написания своего софта с совместимой авторизацией. Правда, безопасен он только для тех, кто никогда не логинится с телефона, на котором установлен Google Authenticator.
— в скайпе клевые групповые чаты, в аське их не было
— в аське окончательно доломали поиск людей по возрасту и городу
— голосовые звонки
В последнем скайпе жадный майкрософт начал показывать рекламу. Куда теперь уйти?
«Even though TLS specifications require servers to check the padding, some implementations fail to validate it properly, which makes some servers vulnerable to POODLE even if they disable SSL 3.0.»