Про ретроспективы конференций в Plesk ещё Сергей Лысцев писал вот здесь: https://t.me/program_man/47
(Надеюсь, правила Хабра не запрещают ссылки на Телеграм давать)

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

Вот action items на скриншотах нет, а мне кажется, это как раз самое ценное в наших ретрах. Не просто «хорошо бы если кто-нибудь сделал бы это» а «Вася Петров обязался сделать прототип и рассказать о результатах».

Спасибо за этот цикл статей, задача нужная.

Скачать готовую программу – здесь.

А почему не GitHub? Там было бы сильно удобнее смотреть на код.

А можно ли в такое исследование включать аккумуляторные батарейки? В качестве цены взять, например (цену батайрейки + цену электричества на N циклов перезарядки) / N. Подозреваю, что по соотношению цены и ёмкости они будут очень хороши.

Вот про это пост в блоге Cloudflare: How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today

«Дизайн органического искусственного интеллекта от Gleb Kuznetsov»

Но… это же просто анимация! В ней нет ни искусственного интеллекта, ни дизайна. Дизайн — это решение задач, а не украшательство.

Действительно, про задачи и настройки я не подумал. Тогда экспорт/импорт выглядит довольно неплохим решением.

Речь о «squash and merge»? Странно, что гитлабовцы не написали об этом в релизном посте. Фича действительно удобная, её не хватало в CE.

Можно же просто форкать шаблонный проект и потом «отвязывать» форк. Лишних действий на пять-десять минут, зато всем доступно.

Вот это:

git checkout -b future-branch
git checkout master

эквивалентно этому:

git branch future-branch

Не все знания можно извлечь из кода. Если кратко, в нём есть знание «как» он написан, но часто нет знания «почему» и «зачем».

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

Чтобы хранить диаграммы рядом с кодом. Чтобы версионировать их вместе с кодом. Чтобы по git diff видеть изменения, а по git blame видеть их причину. Чтобы не засорять репозиторий кучей устаревающих PNG.

Я не сотрудник GitLab и не отслеживаю планы разработки. Но, как обычный пользователь, сильно сомневаюсь, что когда-либо будет автодевопс для конкретного монолитного репозитория. Это же шаблоны, они рассчитаны на типовое приложение Ruby, типовое приложение Python и т.п.

Однако вы сами можете написать .gitlab-ci.yml под любое приложение, хоть с десятками сервисов.

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

Порядковые номера не будут работать, потому что коммиты не делаются строго последовательно. Обычно разработчики делают коммиты в ветки для реализуемых ими задач, а потом сливают эти ветки в основную (например, master). Разработка идёт одновременно и порядковые номера не будут иметь смысла.

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

Чтобы удобно и понятно искать, присваивайте коммитам понятные и подробные описания. Подробнее об этом:

• https://habrahabr.ru/company/Voximplant/blog/276695/
• https://habrahabr.ru/post/183646/
• https://chris.beams.io/posts/git-commit/

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

git tag -m'Version 1.0' 1.0

Теперь, когда собираете релиз, используйте тег вместо хеша коммита.

Добавлю, что слияние без конфликтов совсем не означает, что полученный код не содержит багов. Как выше писали, если в одной ветке функция удалена или переименована, а в другой ветке её код никак не менялся, вполне вероятно, что после слияния код сломается.

Видимо, будет комбинаторный взрыв if-ов.

Для простых проектов есть GitHub Flow и GitLab Flow, но они и на сложных хорошо работают.

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

Думаю, что «это ведь не сложно» — это сарказм.

Не могли бы вы поделиться кодом вашей команды (алиаса) git ri?

Алексей, это я там холиварю )

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

В строках UI на translate.gitlab.com многие термины отличаются. Это будет запутывать пользователей. Мы, конечно, прокосячились, что не подключились к переводу с самого начала. Давайте хотя бы на этом этапе опомнимся и разработаем единый глоссарий и стайлгайд.

Я там заявку кинул на редактора, подключайтесь. https://gitlab.com/gitlab-org/gitlab-ce/issues/39770

del