Re: Системы управления сервером?

[artiom]

>  >> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
>  >> если тест сломался, то багу надо чинить. Если бага сломала сразу много
>  >> тестов, починка приоритетна, и все дела.
>  >> 
>  > Ладно, умолчу про тех, кто "чинит" тесты в таком случае.
>  > Такие тоже бывали.
>  > Но очень редко тестовое покрытие полное.
> 
> Практически никогда. Но требуется не полнота, а хорошая вероятность
> вылавливания баги раньше, чем на нее наступит заказчик.
> 
Что обеспечивается полнотой...

>  >>  >>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью 
> и
>  >>  >>  > ждать ответов автора (который в этом время уже над другим 
> работает), к
>  >>  >>  > тому же, ревьюверов бывает несколько.
>  >>  >> 
>  >>  >> Я про прерывания не процесса ревью, а про прерывания процесса своей
>  >>  >> работы необходимостью ревью.  Для ревью надо загрузить в голову 
> контекст
>  >>  >> той задачи, к которой относится просматриваемый код.  Он там неизбежно
>  >>  >> заменит контекст своей задачи.  После ревью придется снова грузить 
> свой.
>  >>  >> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
>  >>  >> часа каждая перегрузка, а их тут две.
>  >>  > Ну час - это явный перебор.
>  >> 
>  >> Это значит, у тебя все задачи простые.
>  >> 
>  > Не сказал бы. Ревью компактные относительно. И, естественно, что я не
>  > вникаю в весь код: только в изменения.
> 
> То есть как раз неочевидные грабли, которые вносит изменение, ты
> пропустишь с вероятностью, близкой к 1.
> 
Частично. Но смотрят несколько человек. В общем-то спор ни о чём: ревью
помогает, но имеет свои минусы, это очевидно.

>  >>  > А отрыв на 15 минут - не критично: вы же не соревновательным
>  >>  > программированием занимаетесь, надеюсь?
>  >> 
>  >> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в 
> контекст.
>  >> 
>  > Есть вечер, утро и обед, если не критично.
> 
> В обед надо обедать. И мозгом тоже. Иначе очень быстро огребешь гастрит.
> 
Надо...

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

>  >>  >> Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
>  >>  >> на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
>  >>  >> окупалось?
>  >>  >> 
>  >>  > Запаренные.
>  >> 
>  >> Я не видел, чтоб окупалось.  Ревьюеры-то при этом - те же разработчики, и
>  >> точно так же запаренные.  Да еще надо ревью делать, что еще больше
>  >> запаривает...
>  >> 
>  >> В вышепоскипанном примере с байкой про Боинг как раз запаренности-то и
>  >> нет.  Там регламент устроен так, чтобы затормозить именно запарку.
>  >> 
>  > Ну хорошо Боингу, а когда "давай сократим срок до месяца, хотя можно
>  > делать шесть", а в реальности не помешало бы два, постоянно "атмосфера
>  > гонки" и ощущение того, что ничего не успеваешь.
> 
> На "давай сократим срок до месяца" я отвечаю "давай тогда делать работу
> будет тот, кто сделает ее за месяц".  Способствует просветлению.
> 
Пока не поспособствовало. На практике. Видимо, я не умею особо доходчиво
объяснять.
Впрочем, какая разница? Ну сократили, вылезли критичные ошибки, сроки
продлились.

>  >>  >>  >> Менталитет программиста тоже интернационален. С менталитетом 
> "кодера по
>  >>  >>  >> обезьяньей работе" хуже, но extreme programming - технология для
>  >>  >>  >> программистов.
>  >>  >>  >> 
>  >>  >>  > Ну что-то мне подсказывает, что русским и китайцам ужиться будет
>  >>  >>  > несколько сложно, и не для всех эта техника подходит.
>  >>  >> 
>  >>  >> А никто не утверждал, что для всех.  А вот русский с китайцем, скорее
>  >>  >> всего, в паре как раз неплохо уживутся.  Только роли будут не
>  >>  >> переменные, а ближе к постоянным.  Китаец кодит, русский следит и
>  >>  >> корректирует.  Характерного китайца не надо подгонять, зато надо
>  >>  >> своевременно тормозить и/или поворачивать.  Тогда он будет выдавать
>  >>  >> качественный продукт, а быстро он его и так будет выдавать.
>  >>  >> 
>  >>  > Что-то динамика развития Китая по отношению к РФ показывает: роли
>  >>  > меняются. :-/
>  >> 
>  >> Ой, да ладно...  Может, лет через несколько русский тут просто станет
>  >> лишним, но заменить китайца как работник...
>  >> 
>  > Я как-то уже писал: китайцы свою процессорную архитектуру отгрохали,
>  > реализовали на ней процессоры и построили из них самый быстрый в мире
>  > суперкомпьютер, обогнав США (сейчас, вроде Япония первая).
>  > Где здесь русский?
> 
> А я этого в оригинале не видел, и не знаю, насколько тыренная (вряд ли
> из России, скорее всего, из Штатов) та архитектура.  А типичный 

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sun, 8 Apr 2018 11:55:37 +0300:

 >> Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как
 >> раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки
 >> находится тысяча первый ревьюер, который таки замечает багу и делает
 >> эксплойт.
 >> 
 > Может быть из-за ревью он находится через 10-15 лет, а не каждый год на
 > их протяжении?

И это тоже, но это ревью, опять же, в духе байки про Боинг, и задолго до
начала реализации.

А баги в реализации обычно ловят тесты.

 >> А обычно бага либо легко правится, либо быстро замечается. В идеале и
 >> то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
 >> реализации фичи, но так бывает не всегда :)
 >> 
 > Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о
 > чём как-то давно вы сами и писали.

Если считать только время реализации, отдельно от размышлений об
архитектуре, то больше 50%. На глазок, примерно 70. Оно, правда, часто
окупается.

 >>  >>  >>  >> Практика показывает, что читать код _до_ попадания в 
 >> репозиторий - не
 >>  >>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, 
 >> откатить.
 >>  >>  >>  >> 
 >>  >>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не 
 >> лучше
 >>  >>  >>  > ли - не допустить?
 >>  >>  >>  > Какая практика?
 >>  >>  >>  > В чём нехорошесть данной идеи?
 >>  >>  >> 
 >>  >>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
 >>  >>  >> будет изменен, проходит время.
 >>  >>  > Как минус, так и плюс.
 >>  >> 
 >>  >> В течение этого времени в системе присутствуют и старые, и новые баги.
 >>  >> Где плюс?
 >>  >> 
 >>  > Нет, присутствуют только старые баги, которые уже известны, проверены и
 >>  > одеты в пиджак, так что стали напоминать фичи.
 >> 
 >> В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И
 >> поверх них уже идет работа.
 >> 
 > Да не идёт поверх них работы, пока их нет в репозитории, иначе процесс
 > неверно построен.

То есть в верно построенном процессе эти два дня никто ничего не делает
ни в чем, завязанном на это место кода? Верно построен процесс, что и
говорить...

 >> И не факт, кстати, что старые баги известны. Мы можем говорить о ревью,
 >> например, фикса свеженаступленной грабли. Она, может, в коде и пару лет
 >> уже, но важный заказчик наступил на нее только сегодня, а до него просто
 >> никому не приходило в голову проделать именно эту последовательность
 >> действий.
 >> 
 > Главное, чтобы фикс не внёс два других ещё более неочевидных бага и
 > ничего не сломал.

А это по коду фикса очень трудно понять. Нужен контекст гораздо большего
объема. Тут как раз набор автоматизированных тестов работает не в пример
лучше - в нем этот контекст зафиксирован.

 >>  > А тут новые баги, которые успеют сломать тестирование, например, в
 >>  > результате чего могут не пройти другие тесты и т.п..
 >>  > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
 >>  > однако есть факты на практике).
 >> 
 >> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
 >> если тест сломался, то багу надо чинить. Если бага сломала сразу много
 >> тестов, починка приоритетна, и все дела.
 >> 
 > Ладно, умолчу про тех, кто "чинит" тесты в таком случае.
 > Такие тоже бывали.
 > Но очень редко тестовое покрытие полное.

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

 >>  >>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
 >>  >>  > ждать ответов автора (который в этом время уже над другим работает), 
 >> к
 >>  >>  > тому же, ревьюверов бывает несколько.
 >>  >> 
 >>  >> Я про прерывания не процесса ревью, а про прерывания процесса своей
 >>  >> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
 >>  >> той задачи, к которой относится просматриваемый код.  Он там неизбежно
 >>  >> заменит контекст своей задачи.  После ревью придется снова грузить свой.
 >>  >> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
 >>  >> часа каждая перегрузка, а их тут две.
 >>  > Ну час - это явный перебор.
 >> 
 >> Это значит, у тебя все задачи простые.
 >> 
 > Не сказал бы. Ревью компактные относительно. И, естественно, что я не
 > вникаю в весь код: только в изменения.

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

 >>  > А отрыв на 15 минут - не критично: вы же не соревновательным
 >>  > программированием занимаетесь, надеюсь?
 >> 
 >> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в 
 >> контекст.
 >> 
 > Есть вечер, утро и обед, если не критично.

В обед надо обедать. И мозгом тоже. Иначе очень быстро огребешь гастрит.

 >>  > Иногда вообще полезно от задачи оторваться, бывает.
 >> 
 >> В моем опыте оторваться от задачи полезно, а вот заменять в голове ее
 >> контекст контекстом другой задачи как раз 

Re: Системы управления сервером?

[artiom]

>  > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
>  > репозитория, на которую уже понакоммитили и заложили функционал.
> 
> Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую
> очень не сразу удалось обнаружить, не брали никакие разумные тесты, и
> трудоемко было потом починить. Так и не починили, кстати. Причем по
> крайней мере два первых ревью (два разных человека, входивших в разное
> время в проект, внимательно читали этот код) она тоже успешно
> проскочила.
> 
Ну да, бывает.

> Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как
> раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки
> находится тысяча первый ревьюер, который таки замечает багу и делает
> эксплойт.
> 
Может быть из-за ревью он находится через 10-15 лет, а не каждый год на
их протяжении?

> А обычно бага либо легко правится, либо быстро замечается. В идеале и
> то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
> реализации фичи, но так бывает не всегда :)
> 
Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о
чём как-то давно вы сами и писали.

>  >>  >>  >> Практика показывает, что читать код _до_ попадания в репозиторий 
> - не
>  >>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, 
> откатить.
>  >>  >>  >> 
>  >>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не 
> лучше
>  >>  >>  > ли - не допустить?
>  >>  >>  > Какая практика?
>  >>  >>  > В чём нехорошесть данной идеи?
>  >>  >> 
>  >>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
>  >>  >> будет изменен, проходит время.
>  >>  > Как минус, так и плюс.
>  >> 
>  >> В течение этого времени в системе присутствуют и старые, и новые баги.
>  >> Где плюс?
>  >> 
>  > Нет, присутствуют только старые баги, которые уже известны, проверены и
>  > одеты в пиджак, так что стали напоминать фичи.
> 
> В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И
> поверх них уже идет работа.
> 
Да не идёт поверх них работы, пока их нет в репозитории, иначе процесс
неверно построен.

> И не факт, кстати, что старые баги известны. Мы можем говорить о ревью,
> например, фикса свеженаступленной грабли. Она, может, в коде и пару лет
> уже, но важный заказчик наступил на нее только сегодня, а до него просто
> никому не приходило в голову проделать именно эту последовательность
> действий.
> 
Главное, чтобы фикс не внёс два других ещё более неочевидных бага и
ничего не сломал.

>  > А тут новые баги, которые успеют сломать тестирование, например, в
>  > результате чего могут не пройти другие тесты и т.п..
>  > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
>  > однако есть факты на практике).
> 
> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
> если тест сломался, то багу надо чинить. Если бага сломала сразу много
> тестов, починка приоритетна, и все дела.
> 
Ладно, умолчу про тех, кто "чинит" тесты в таком случае.
Такие тоже бывали.
Но очень редко тестовое покрытие полное.

>  >>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
>  >>  > ждать ответов автора (который в этом время уже над другим работает), к
>  >>  > тому же, ревьюверов бывает несколько.
>  >> 
>  >> Я про прерывания не процесса ревью, а про прерывания процесса своей
>  >> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
>  >> той задачи, к которой относится просматриваемый код.  Он там неизбежно
>  >> заменит контекст своей задачи.  После ревью придется снова грузить свой.
>  >> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
>  >> часа каждая перегрузка, а их тут две.
>  > Ну час - это явный перебор.
> 
> Это значит, у тебя все задачи простые.
> 
Не сказал бы. Ревью компактные относительно. И, естественно, что я не
вникаю в весь код: только в изменения.
А задача делается не один день. Я её помню и хотя бы иногда надо
отвлекаться.

>  > А отрыв на 15 минут - не критично: вы же не соревновательным
>  > программированием занимаетесь, надеюсь?
> 
> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст.
> 
Есть вечер, утро и обед, если не критично.
Обычно срочно закрывать не приходится.
Вполне себе нормальный способ оторваться от задачи.

>  > Иногда вообще полезно от задачи оторваться, бывает.
> 
> В моем опыте оторваться от задачи полезно, а вот заменять в голове ее
> контекст контекстом другой задачи как раз вредно.  Ну да люди разные,
> задачи тоже.
> 
Ну это возможно. Просто обычно на ревью "отдыхаешь". Хотя...

>  > Другое дело, если ревью много. Тогда да, на них забивают.
> 
> И это, кстати, тоже. Не написанный тест ловится хотя бы coverage, а
> забитое ревью от выполненного без претензий к коду не отличить никак.
> 
Да, тут правда.

>  >> Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
>  >> на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
>  >> окупалось?

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sat, 31 Mar 2018 14:18:00 +0300:

 >>  >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, 
 >> человек
 >>  >>  >>  >> либо обучается, либо идет искать работу в другом месте.
 >>  >>  >>  >> 
 >>  >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, 
 >> код
 >>  >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
 >>  >>  >> 
 >>  >>  >> В одной из контор у нас были любители почитать код, уходящий в
 >>  >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать 
 >> коммиты
 >>  >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
 >>  >>  >> 
 >>  >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем 
 >> случае,
 >>  >>  > любым web интерфейсом), и код не проходит в репозиторий без 
 >> одобрения.
 >>  >> 
 >>  >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
 >>  >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
 >>  >> происходит.
 >>  >> 
 >>  > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
 >>  > практики.
 >> 
 >> Собственно, системы управления версиями придуманы ровно для этой
 >> ситуации.  Чтобы заменить трехслойную бюрократию ревью, которая работает
 >> месяц, но тоже пропускает баги, возможностью найти и откатить изменение,
 >> если оно оказалось неудачным.
 >> 
 >> А чтобы неудачное изменение не долетело до заказчика, существует
 >> релизный цикл.  И ревью его необходимости не отменяет.
 >> 
 > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
 > репозитория, на которую уже понакоммитили и заложили функционал.

Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую
очень не сразу удалось обнаружить, не брали никакие разумные тесты, и
трудоемко было потом починить. Так и не починили, кстати. Причем по
крайней мере два первых ревью (два разных человека, входивших в разное
время в проект, внимательно читали этот код) она тоже успешно
проскочила.

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

А обычно бага либо легко правится, либо быстро замечается. В идеале и
то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе
реализации фичи, но так бывает не всегда :)

 >>  >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - 
 >> не
 >>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
 >>  >>  >> 
 >>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не 
 >> лучше
 >>  >>  > ли - не допустить?
 >>  >>  > Какая практика?
 >>  >>  > В чём нехорошесть данной идеи?
 >>  >> 
 >>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
 >>  >> будет изменен, проходит время.
 >>  > Как минус, так и плюс.
 >> 
 >> В течение этого времени в системе присутствуют и старые, и новые баги.
 >> Где плюс?
 >> 
 > Нет, присутствуют только старые баги, которые уже известны, проверены и
 > одеты в пиджак, так что стали напоминать фичи.

В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И
поверх них уже идет работа.

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

 > А тут новые баги, которые успеют сломать тестирование, например, в
 > результате чего могут не пройти другие тесты и т.п..
 > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
 > однако есть факты на практике).

На практике тесты для того и существуют, чтобы баги их ломали. Один фиг,
если тест сломался, то багу надо чинить. Если бага сломала сразу много
тестов, починка приоритетна, и все дела.

 >>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
 >>  > ждать ответов автора (который в этом время уже над другим работает), к
 >>  > тому же, ревьюверов бывает несколько.
 >> 
 >> Я про прерывания не процесса ревью, а про прерывания процесса своей
 >> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
 >> той задачи, к которой относится просматриваемый код.  Он там неизбежно
 >> заменит контекст своей задачи.  После ревью придется снова грузить свой.
 >> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
 >> часа каждая перегрузка, а их тут две.
 > Ну час - это явный перебор.

Это значит, у тебя все задачи простые.

 > А отрыв на 15 минут - не критично: вы же не соревновательным
 > программированием занимаетесь, надеюсь?

Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст.

 > Иногда вообще полезно от задачи оторваться, бывает.

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

Re: Системы управления сервером?

[artiom]

>  >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, 
> человек
>  >>  >>  >> либо обучается, либо идет искать работу в другом месте.
>  >>  >>  >> 
>  >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
>  >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
>  >>  >> 
>  >>  >> В одной из контор у нас были любители почитать код, уходящий в
>  >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
>  >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
>  >>  >> 
>  >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
>  >>  > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
>  >> 
>  >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
>  >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
>  >> происходит.
>  >> 
>  > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
>  > практики.
> 
> Собственно, системы управления версиями придуманы ровно для этой
> ситуации.  Чтобы заменить трехслойную бюрократию ревью, которая работает
> месяц, но тоже пропускает баги, возможностью найти и откатить изменение,
> если оно оказалось неудачным.
> 
> А чтобы неудачное изменение не долетело до заказчика, существует
> релизный цикл.  И ревью его необходимости не отменяет.
> 
Есть минусы, есть плюсы: не так легко откатить сломавшую правку из
репозитория, на которую уже понакоммитили и заложили функционал.

>  >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - не
>  >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
>  >>  >> 
>  >>  > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
>  >>  > ли - не допустить?
>  >>  > Какая практика?
>  >>  > В чём нехорошесть данной идеи?
>  >> 
>  >> Тормозной путь. Между моментом изменения кода и моментом, когда код
>  >> будет изменен, проходит время.
>  > Как минус, так и плюс.
> 
> В течение этого времени в системе присутствуют и старые, и новые баги.
> Где плюс?
> 
Нет, присутствуют только старые баги, которые уже известны, проверены и
одеты в пиджак, так что стали напоминать фичи.
А тут новые баги, которые успеют сломать тестирование, например, в
результате чего могут не пройти другие тесты и т.п..
На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты,
однако есть факты на практике).


>  > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
>  > ждать ответов автора (который в этом время уже над другим работает), к
>  > тому же, ревьюверов бывает несколько.
> 
> Я про прерывания не процесса ревью, а про прерывания процесса своей
> работы необходимостью ревью.  Для ревью надо загрузить в голову контекст
> той задачи, к которой относится просматриваемый код.  Он там неизбежно
> заменит контекст своей задачи.  После ревью придется снова грузить свой.
> Это время, и в случае сложной задачи весьма изрядное.  От 15 минут до
> часа каждая перегрузка, а их тут две.
Ну час - это явный перебор. А отрыв на 15 минут - не критично: вы же не
соревновательным программированием занимаетесь, надеюсь?
Иногда вообще полезно от задачи оторваться, бывает.
Другое дело, если ревью много. Тогда да, на них забивают.

> 
>  >>  >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
>  >>  >> там такова, что оно окупается.
>  >>  >> 
>  >>  > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
>  >>  > привязана задача, после чего проверяются (перед репозиторием).
>  >> 
>  >> А "в случае того, что есть сейчас" непонятно, окупается ли этот
>  >> тормозной путь.
>  >> 
>  > Продукт окупается.
>  > "Тормозной путь", скорее всего, да.
>  > Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.
> 
> Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
> на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
> окупалось?
> 
Запаренные.

>  >> Менталитет программиста тоже интернационален. С менталитетом "кодера по
>  >> обезьяньей работе" хуже, но extreme programming - технология для
>  >> программистов.
>  >> 
>  > Ну что-то мне подсказывает, что русским и китайцам ужиться будет
>  > несколько сложно, и не для всех эта техника подходит.
> 
> А никто не утверждал, что для всех.  А вот русский с китайцем, скорее
> всего, в паре как раз неплохо уживутся.  Только роли будут не
> переменные, а ближе к постоянным.  Китаец кодит, русский следит и
> корректирует.  Характерного китайца не надо подгонять, зато надо
> своевременно тормозить и/или поворачивать.  Тогда он будет выдавать
> качественный продукт, а быстро он его и так будет выдавать.
> 
Что-то динамика развития Китая по отношению к РФ показывает: роли
меняются. :-/

>  >>  >>  > В любом случае, если я такое (чисто теоретически) предложу 
> менеджеру,
>  >>  >>  > он только у виска покрутит. Это же получается, что каждый 
> программист
>  >>  >>  > работает, условно половину 

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Tue, 27 Mar 2018 23:35:21 +0300:

 >>  >>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
 >>  >>  >> грабли :) Код на Haskell и Scala даже и не тестируется 
 >> автомагически,
 >>  >>  >> настолько мало там багов, что написание тестов не окупается.
 >>  >>  >> 
 >>  >>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
 >>  >> 
 >>  >> Если тесты нельзя написать, то код негодный. Другое дело, что на
 >>  >> написание тестов не всегда хватает ресурса.
 >>  >> 
 >>  > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
 >>  > делать?
 >> 
 >> Не каждый. Для unit-тестирования да, а для acceptance подключать
 >> аппаратуру, ага.
 >> 
 > А она бажная. Как факт. Потому что тоже разрабатывается.

Именно поэтому для acceptance, или, точнее, для integration, ее надо подключать.

 >>  >> Если более тысячи программистов отвечают за одно место в коде, код
 >>  >> работать не будет. В больших конторах за каждое место в коде отвечает
 >>  >> очень небольшое количество людей, а протоколы взаимодействия между кодом
 >>  >> разных отделов компактны.
 >>  >> 
 >>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, 
 >> человек
 >>  >>  >> либо обучается, либо идет искать работу в другом месте.
 >>  >>  >> 
 >>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
 >>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
 >>  >> 
 >>  >> В одной из контор у нас были любители почитать код, уходящий в
 >>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
 >>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
 >>  >> 
 >>  > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
 >>  > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
 >> 
 >> Тут важный момент - не веб или почта "код не проходит в репозиторий без
 >> одобрения". У нас проходил. Мой point в том, что проблем от этого не
 >> происходит.
 >> 
 > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
 > практики.

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

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

 >>  >> Практика показывает, что читать код _до_ попадания в репозиторий - не
 >>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
 >>  >> 
 >>  > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
 >>  > ли - не допустить?
 >>  > Какая практика?
 >>  > В чём нехорошесть данной идеи?
 >> 
 >> Тормозной путь. Между моментом изменения кода и моментом, когда код
 >> будет изменен, проходит время.
 > Как минус, так и плюс.

В течение этого времени в системе присутствуют и старые, и новые баги.
Где плюс?

 >> Либо это очень большое время, либо
 >> ревьюер работает с частыми прерываниями. Если у него содержательная
 >> работа не обезьянья, то частые прерывания очень сильно снижают его
 >> продуктивность. Так и так изрядно падает КПД.
 >>
 > Ну, допустим, пара дней на ревью - это большое время?

Офигительно.  За это время я успею еще много чего сделать, и оно будет
пересекаться по коду с теми изменениями, и если изменение не примут как
есть, то попытка что-то там подкрутить приведет к конфликтам с точки
зрения VCS.  А разбор конфликта - одно из самых багопродуцирующих
действий.  И результатом его оказывается патч, разбираться в котором -
уже два полных рабочих дня, а не просто задержка на пару дней.

 > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
 > ждать ответов автора (который в этом время уже над другим работает), к
 > тому же, ревьюверов бывает несколько.

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

 >>  >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
 >>  >> там такова, что оно окупается.
 >>  >> 
 >>  > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
 >>  > привязана задача, после чего проверяются (перед репозиторием).
 >> 
 >> А "в случае того, что есть сейчас" непонятно, окупается ли этот
 >> тормозной путь.
 >> 
 > Продукт окупается.
 > "Тормозной путь", скорее всего, да.
 > Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.

Вот тут уже сомнения.  Если сжатые сроки, то потеря в среднем получаса
на каждое ревью...  Это какие же должны быть разработчики, чтобы оно
окупалось?

 >>  >>  >>  

Re: Системы управления сервером?

[artiom]

> artiom -> debian-russian@lists.debian.org  @ Mon, 26 Mar 2018 20:53:38 +0300:
> 
>  >>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
>  >>  >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
>  >>  >> настолько мало там багов, что написание тестов не окупается.
>  >>  >> 
>  >>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
>  >> 
>  >> Если тесты нельзя написать, то код негодный. Другое дело, что на
>  >> написание тестов не всегда хватает ресурса.
>  >> 
>  > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
>  > делать?
> 
> Не каждый. Для unit-тестирования да, а для acceptance подключать
> аппаратуру, ага.
> 
А она бажная. Как факт. Потому что тоже разрабатывается.

>  > А работа при загрузке ОС?
> 
> И это тоже надо тестировать. Ну да, придется контейнер тюнить.
> 
>  >>  > Плюс, на ревью проверяется читабельность кода и его логическая
>  >>  > корректность (и тесты, и код возможно написать некорректно).  Плюс, в
>  >>  > два раза больше работы.  В общем, одно другое не заменяет.
>  >> 
>  >> Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в
>  >> процессах, которые применяются там, где я работал, ревью отсутствует.
>  >> 
>  > Понял вас. Хотя, всё-равно не могу представить. У меня опыт поменьше, но
>  > всё-таки, в трёх достаточно известных конторах, где я работал, ревью
>  > имеется, причём через WEB GUI.
> 
> Известная контора - еще далеко не гарантия качества результата :)
> 
Ну, я точно в курсе.

>  >> Если более тысячи программистов отвечают за одно место в коде, код
>  >> работать не будет. В больших конторах за каждое место в коде отвечает
>  >> очень небольшое количество людей, а протоколы взаимодействия между кодом
>  >> разных отделов компактны.
>  >> 
>  >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
>  >>  >> либо обучается, либо идет искать работу в другом месте.
>  >>  >> 
>  >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
>  >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
>  >> 
>  >> В одной из контор у нас были любители почитать код, уходящий в
>  >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
>  >> желающим. По почте. Тем же способом присматривали за джуниорами.
>  >> 
>  > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
>  > любым web интерфейсом), и код не проходит в репозиторий без одобрения.
> 
> Тут важный момент - не веб или почта "код не проходит в репозиторий без
> одобрения". У нас проходил. Мой point в том, что проблем от этого не
> происходит.
> 
Возможно. Надо подумать над этим. Раньше я даже не предполагал такой
практики.

>  >> Практика показывает, что читать код _до_ попадания в репозиторий - не
>  >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
>  >> 
>  > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
>  > ли - не допустить?
>  > Какая практика?
>  > В чём нехорошесть данной идеи?
> 
> Тормозной путь. Между моментом изменения кода и моментом, когда код
> будет изменен, проходит время.
Как минус, так и плюс.

> Либо это очень большое время, либо
> ревьюер работает с частыми прерываниями. Если у него содержательная
> работа не обезьянья, то частые прерывания очень сильно снижают его
> продуктивность. Так и так изрядно падает КПД.
>
Ну, допустим, пара дней на ревью - это большое время?
Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и
ждать ответов автора (который в этом время уже над другим работает), к
тому же, ревьюверов бывает несколько.

>  >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки
>  >> там такова, что оно окупается.
>  >> 
>  > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним
>  > привязана задача, после чего проверяются (перед репозиторием).
> 
> А "в случае того, что есть сейчас" непонятно, окупается ли этот
> тормозной путь.
> 
Продукт окупается.
"Тормозной путь", скорее всего, да.
Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков.

>  >>  >>  >> В общем, даже модель pull request не использовали, не говоря уже 
> о code
>  >>  >>  >> review. А вот работу в паре как раз использовали.
>  >>  >>  >> 
>  >>  >>  > А подробнее? Это из области "экстремального программирования"?
>  >>  >> 
>  >>  >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
>  >>  >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
>  >>  >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
>  >>  >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
>  >>  >> такие грабли".
>  >>  >> 
>  >>  >> Результаты различного качества, в зависимости в основном от дисциплины
>  >>  >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
>  >>  >> вылетает аппаратура, чем вылезают не дающие работать баги.
>  >>  >> 
>  >>  > Только читал об этом, не думал, что в РФ 

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Mon, 26 Mar 2018 20:53:38 +0300:

 >>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
 >>  >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
 >>  >> настолько мало там багов, что написание тестов не окупается.
 >>  >> 
 >>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
 >> 
 >> Если тесты нельзя написать, то код негодный. Другое дело, что на
 >> написание тестов не всегда хватает ресурса.
 >> 
 > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
 > делать?

Не каждый. Для unit-тестирования да, а для acceptance подключать
аппаратуру, ага.

 > А работа при загрузке ОС?

И это тоже надо тестировать. Ну да, придется контейнер тюнить.

 >>  > Плюс, на ревью проверяется читабельность кода и его логическая
 >>  > корректность (и тесты, и код возможно написать некорректно).  Плюс, в
 >>  > два раза больше работы.  В общем, одно другое не заменяет.
 >> 
 >> Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в
 >> процессах, которые применяются там, где я работал, ревью отсутствует.
 >> 
 > Понял вас. Хотя, всё-равно не могу представить. У меня опыт поменьше, но
 > всё-таки, в трёх достаточно известных конторах, где я работал, ревью
 > имеется, причём через WEB GUI.

Известная контора - еще далеко не гарантия качества результата :)

 >> Если более тысячи программистов отвечают за одно место в коде, код
 >> работать не будет. В больших конторах за каждое место в коде отвечает
 >> очень небольшое количество людей, а протоколы взаимодействия между кодом
 >> разных отделов компактны.
 >> 
 >>  >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
 >>  >> либо обучается, либо идет искать работу в другом месте.
 >>  >> 
 >>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
 >>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
 >> 
 >> В одной из контор у нас были любители почитать код, уходящий в
 >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
 >> желающим. По почте. Тем же способом присматривали за джуниорами.
 >> 
 > Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
 > любым web интерфейсом), и код не проходит в репозиторий без одобрения.

Тут важный момент - не веб или почта "код не проходит в репозиторий без
одобрения". У нас проходил. Мой point в том, что проблем от этого не
происходит.

 >> Практика показывает, что читать код _до_ попадания в репозиторий - не
 >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
 >> 
 > Но сборки уже будут собраны и отправлены на тестирование, так не лучше
 > ли - не допустить?
 > Какая практика?
 > В чём нехорошесть данной идеи?

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

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

А "в случае того, что есть сейчас" непонятно, окупается ли этот
тормозной путь.

 >>  >>  >> В общем, даже модель pull request не использовали, не говоря уже о 
 >> code
 >>  >>  >> review. А вот работу в паре как раз использовали.
 >>  >>  >> 
 >>  >>  > А подробнее? Это из области "экстремального программирования"?
 >>  >> 
 >>  >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
 >>  >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
 >>  >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
 >>  >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
 >>  >> такие грабли".
 >>  >> 
 >>  >> Результаты различного качества, в зависимости в основном от дисциплины
 >>  >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
 >>  >> вылетает аппаратура, чем вылезают не дающие работать баги.
 >>  >> 
 >>  > Только читал об этом, не думал, что в РФ используется.
 >> 
 >> Это парадигма, ей чихать на государственные границы.
 >> 
 > Границы не при чём, имеет значение "менталитет", в общем и, в частности:
 > культура разработки и стоимость такого подхода.

Менталитет программиста тоже интернационален. С менталитетом "кодера по
обезьяньей работе" хуже, но extreme programming - технология для
программистов.

 >>  > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
 >>  > он только у виска покрутит. Это же получается, что каждый программист
 >>  > работает, условно половину времени, а половину сидит "и что-то там
 >>  > смотрит".

 >> А если тебе не результат а имитацию бурной деятельности для менеджера,
 >> то да, подход ровно обратный.
 > В конкретном 

Re: Системы управления сервером?

[artiom]

Ok, буду смотреть.
От Proxmox я отказался.
LDAP тоже, получается, не сильно нужен: он требуется разве что потому,
что многие софтины с LDAP серверами работают, да и пользователей
nix-овых городить не придётся.

24.03.2018 21:19, Павел Марченко пишет:
> Как раз наоборот, легкий и работает без агента. не нужны ни службы ни демоны
> 
> 
> ср, 21 мар. 2018 г. в 22:39, artiom  >:
> 
> Ansible - тяжёлый и сложный?
> Не исключаю, но стоит учесть, что у меня не крупный сервер, а прежде
> всего NAS, предоставляющий дополнительные сервисы ограниченному
> количеству людей.
> А про Cockpit что-нибудь можете сказать?
> 
> 21.03.2018 15:56, Павел Марченко пишет:
> > Ansible  как вариант, у него полно модулей по управлению облычными
> > платформами
> > http://docs.ansible.com/ansible/latest/list_of_cloud_modules.html
> > Ну и стандартные, типо юзера
> > http://docs.ansible.com/ansible/latest/user_module.html
> > Аклы
> > http://docs.ansible.com/ansible/latest/acl_module.html
> >
> > P.S. прошу прощение, за сообщение в личку
> >
> >
> > пн, 19 мар. 2018 г. в 23:57, artiom  
> > >>:
> >
> >     Впечатлился статьёй.
> >     Айн: https://habrahabr.ru/post/328048/
> >     Цвайн:
> >   
>  
> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
> >
> >     Помимо Proxmox, есть такая штука, как Cockpit:
> >     http://cockpit-project.org
> >
> >     О нём я ничего не знаю.
> >     Собственно, Proxmox я тоже не использовал.
> >
> >     Основные задачи:
> >
> >     - Отделение сервисов путём контейнеризации (docker+lxc,
> возможно будет
> >     использован kvm в редких случаях).
> >     - Централизованное управление пользователями: их несколько
> (менее 10),
> >     надо им давать права к сервисам (облако (seafile), gitlab,
> медиа-сервер
> >     (типа kodi), каталоги с медиа-данными и просто данными), каталоги
> >     выделять в пуле и подобное.
> >
> >     Что для этого используют?
> >     Подходит ли Cocpkit (там есть управление контейнерами) или лучше
> >     использовать Proxmox и вариант, как в статье?
> >     Как вообще лучше организовать такую систему (изначально не
> >     предполагалось давать пользователям какие-то возможности,
> кроме доступа
> >     к gitlab)?
> >
> >
> >
> > --
> > Regards, Pavel.
> 
> 
> 
> -- 
> Regards, Pavel.

Re: Системы управления сервером?

[artiom]

24.03.2018 20:24, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 17:00:47 +0300:
> 
>  >> Artem Chuprina  wrote:
>  >> 
>  >> Артем, при работе с джунами очень удобно ткнуть мышой в место в
> 
> ...
> 
>  >> Так что не надо топить вебинтерфейсы, у них иногда действительно есть 
> плюсы.
>  >> 
>  > В каком смысле? Что я "топлю"? Я так и делаю обычно (комментирую
>  > строчки, либо показываю, что не так), а сейчас ищу для себя подходящий
>  > интерфейс.
> 
> Ты просто читаешь не все буквы. Иногда зря. Имя в письме прочел, а
> фамилию в квоте - нет.
> 
Блин, не заметил.

Re: Системы управления сервером?

[artiom]

>  >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
>  >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
>  >> настолько мало там багов, что написание тестов не окупается.
>  >> 
>  > Ну это две параллельные задачи. Часто тесты нельзя написать.
> 
> Если тесты нельзя написать, то код негодный. Другое дело, что на
> написание тестов не всегда хватает ресурса.
> 
Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз
делать?
А работа при загрузке ОС?

>  > Плюс, на ревью проверяется читабельность кода и его логическая
>  > корректность (и тесты, и код возможно написать некорректно).  Плюс, в
>  > два раза больше работы.  В общем, одно другое не заменяет.
> 
> Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в
> процессах, которые применяются там, где я работал, ревью отсутствует.
> 
Понял вас. Хотя, всё-равно не могу представить. У меня опыт поменьше, но
всё-таки, в трёх достаточно известных конторах, где я работал, ревью
имеется, причём через WEB GUI.

> Если более тысячи программистов отвечают за одно место в коде, код
> работать не будет. В больших конторах за каждое место в коде отвечает
> очень небольшое количество людей, а протоколы взаимодействия между кодом
> разных отделов компактны.
> 
>  >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
>  >> либо обучается, либо идет искать работу в другом месте.
>  >> 
>  > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
>  > сложный, хотелось бы видеть, что уйдёт в репозиторий.
> 
> В одной из контор у нас были любители почитать код, уходящий в
> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты
> желающим. По почте. Тем же способом присматривали за джуниорами.
> 
Примерно так и есть, но почта заменяется ccollab (или, в общем случае,
любым web интерфейсом), и код не проходит в репозиторий без одобрения.

> Практика показывает, что читать код _до_ попадания в репозиторий - не
> очень хорошая идея. Благо репозиторий позволяет, если что, откатить.
> 
Но сборки уже будут собраны и отправлены на тестирование, так не лучше
ли - не допустить?
Какая практика?
В чём нехорошесть данной идеи?

> Не, мне рассказывали байку о техпроцессе в Боинге с кодом, который идет
> в авионику. Там ревью есть, но начинается оно не с would-be коммита, а с
> обоснования, почему надо менять именно это место в коде, и как его
> менять. Только там питона, баша и луа быть не может - их интерпретаторы
> не удовлетворяют требованиям к тому техпроцессу.
> 
Согласен.

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

>  >>  >> В общем, даже модель pull request не использовали, не говоря уже о 
> code
>  >>  >> review. А вот работу в паре как раз использовали.
>  >>  >> 
>  >>  > А подробнее? Это из области "экстремального программирования"?
>  >> 
>  >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
>  >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
>  >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
>  >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
>  >> такие грабли".
>  >> 
>  >> Результаты различного качества, в зависимости в основном от дисциплины
>  >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
>  >> вылетает аппаратура, чем вылезают не дающие работать баги.
>  >> 
>  > Только читал об этом, не думал, что в РФ используется.
> 
> Это парадигма, ей чихать на государственные границы.
> 
Границы не при чём, имеет значение "менталитет", в общем и, в частности:
культура разработки и стоимость такого подхода.

>  > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
>  > он только у виска покрутит. Это же получается, что каждый программист
>  > работает, условно половину времени, а половину сидит "и что-то там
>  > смотрит".

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

> Берем софт для совместной работы,
> выбираем его по критерию "наиболее красочная презентация", закупаем под
> него сервер, месяц инсталлируем, три месяца настраиваем.  Менеджер от
> презентации в экстазе, и всё согласовывае.  Если бизнес-процесс
> позволяет, покупаем платный саппорт, чтобы жопу прикрыть.  Потом
> заставляем всех им пользоваться.  Все дружно заняты все 8 часов, а то и
> 12...
> 
Как ни печально, наблюдаю подвижки в этом направлении.

> И кстати, code review более чем подходит под определение "что-то там
> смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время
> code review?
> 

Re: Системы управления сервером?

[Artem Chuprina]

Alexander Gerasiov -> debian-russian@lists.debian.org  @ Sun, 25 Mar 2018 
19:16:36 +0300:

 >>  > Артем, при работе с джунами очень удобно ткнуть мышой в место в
 >>  > коде/диффе и написать, что тут не так и как поправить. Особенно,
 >>  > когда таких мест десяток. Без этого приходится либо сажать рядом и
 >>  > показывать, либо в ядерном стиле, когда дифф в почте комментируется
 >>  > инлайн.
 >>  > Так что не надо топить вебинтерфейсы, у них иногда действительно
 >>  > есть плюсы.  
 >> 
 >> Эффективнее всего - именно сажать рядом и показывать.
 > Но для этого хорошо бы предварительно откомментировать, иначе сам потом
 > сходу не вспомишь, когда будешь объяснять, все замечания - это раз, и
 > джуниор не вспомнит все замечания, когда будет их править - два.

Ну, да, полезно. Нет, не в браузере - как текстовый редактор он очень неудобен.

Re: Системы управления сервером?

[Alexander Gerasiov]

Hello Artem,

On Sat, 24 Mar 2018 20:22:25 +0300
Artem Chuprina  wrote:

>  > Артем, при работе с джунами очень удобно ткнуть мышой в место в
>  > коде/диффе и написать, что тут не так и как поправить. Особенно,
>  > когда таких мест десяток. Без этого приходится либо сажать рядом и
>  > показывать, либо в ядерном стиле, когда дифф в почте комментируется
>  > инлайн.
>  > Так что не надо топить вебинтерфейсы, у них иногда действительно
>  > есть плюсы.  
> 
> Эффективнее всего - именно сажать рядом и показывать.
Но для этого хорошо бы предварительно откомментировать, иначе сам потом
сходу не вспомишь, когда будешь объяснять, все замечания - это раз, и
джуниор не вспомнит все замечания, когда будет их править - два.


Самому переписать всё правильно и показать на примере - далеко не
всегда вариант.

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Re: Системы управления сервером?

[artiom]

Я уже его поставил, понял, что у него своё ядро, откатил обратно.
В данном случае Proxmox вообще не нужен.
Для управления контейнерами хватит плагина к OMV.

24.03.2018 20:49, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 16:46:36 +0300:
> 
>  >>> Впечатлился статьёй.
>  >>> Айн: https://habrahabr.ru/post/328048/
>  >>> Цвайн:
>  >>> 
> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
>  >>>
>  >>> Помимо Proxmox, есть такая штука, как Cockpit:
>  >>> http://cockpit-project.org
>  >>>
>  >>> О нём я ничего не знаю.
>  >>> Собственно, Proxmox я тоже не использовал.
>  >>>
>  >>> Основные задачи:
>  >>>
>  >>> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
>  >>> использован kvm в редких случаях).
>  >> Используем Proxmox.
>  >> 
>  > Вот ещё насчёт Proxmox: возможно ли его поставить в Docker контейнер и
>  > стоит ли это делать?
> 
> А потом все это запустить на VirtualBox, запущенном под VmWare?
> 

Re: Системы управления сервером?

[Павел Марченко]

Как раз наоборот, легкий и работает без агента. не нужны ни службы ни демоны


ср, 21 мар. 2018 г. в 22:39, artiom :

> Ansible - тяжёлый и сложный?
> Не исключаю, но стоит учесть, что у меня не крупный сервер, а прежде
> всего NAS, предоставляющий дополнительные сервисы ограниченному
> количеству людей.
> А про Cockpit что-нибудь можете сказать?
>
> 21.03.2018 15:56, Павел Марченко пишет:
> > Ansible  как вариант, у него полно модулей по управлению облычными
> > платформами
> > http://docs.ansible.com/ansible/latest/list_of_cloud_modules.html
> > Ну и стандартные, типо юзера
> > http://docs.ansible.com/ansible/latest/user_module.html
> > Аклы
> > http://docs.ansible.com/ansible/latest/acl_module.html
> >
> > P.S. прошу прощение, за сообщение в личку
> >
> >
> > пн, 19 мар. 2018 г. в 23:57, artiom  > >:
> >
> > Впечатлился статьёй.
> > Айн: https://habrahabr.ru/post/328048/
> > Цвайн:
> >
> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
> >
> > Помимо Proxmox, есть такая штука, как Cockpit:
> > http://cockpit-project.org
> >
> > О нём я ничего не знаю.
> > Собственно, Proxmox я тоже не использовал.
> >
> > Основные задачи:
> >
> > - Отделение сервисов путём контейнеризации (docker+lxc, возможно
> будет
> > использован kvm в редких случаях).
> > - Централизованное управление пользователями: их несколько (менее
> 10),
> > надо им давать права к сервисам (облако (seafile), gitlab,
> медиа-сервер
> > (типа kodi), каталоги с медиа-данными и просто данными), каталоги
> > выделять в пуле и подобное.
> >
> > Что для этого используют?
> > Подходит ли Cocpkit (там есть управление контейнерами) или лучше
> > использовать Proxmox и вариант, как в статье?
> > Как вообще лучше организовать такую систему (изначально не
> > предполагалось давать пользователям какие-то возможности, кроме
> доступа
> > к gitlab)?
> >
> >
> >
> > --
> > Regards, Pavel.
>
>

-- 
Regards, Pavel.

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 16:46:36 +0300:

 >>> Впечатлился статьёй.
 >>> Айн: https://habrahabr.ru/post/328048/
 >>> Цвайн:
 >>> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
 >>>
 >>> Помимо Proxmox, есть такая штука, как Cockpit:
 >>> http://cockpit-project.org
 >>>
 >>> О нём я ничего не знаю.
 >>> Собственно, Proxmox я тоже не использовал.
 >>>
 >>> Основные задачи:
 >>>
 >>> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
 >>> использован kvm в редких случаях).
 >> Используем Proxmox.
 >> 
 > Вот ещё насчёт Proxmox: возможно ли его поставить в Docker контейнер и
 > стоит ли это делать?

А потом все это запустить на VirtualBox, запущенном под VmWare?

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 16:59:02 +0300:

 >>  >> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
 >>  >> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких сложностей, и
 >>  >> код работает.
 >>  >> 
 >>  > 1. Сейчас, где я работаю, используется TFS, прости Господи. Под Linux.
 >>  > Ревью проводится через CodeCollaborator. Это наследие такое. Гит тоже
 >>  > есть, но пока не везде.
 >>  > 2. Объективно лучше, чем ccollab, интерфейсы gitlab и bitbucket. Для
 >>  > всех без исключений. Даже те, кто больше всех матерился из-за перехода
 >>  > на git, в разных конторах, в итоге признавали, что "эти web-интерфейсы
 >>  > удобнее".
 >> 
 >>  > Не опровергаю ваш опыт, но узнать было бы интересно: как так?
 >>  > Т.е.:
 >> 
 >>  > - Первый вопрос: это код на Haskell, не C/C++ + Python + Lua + Bash + 
 >> etc.?
 >> 
 >> C, C++, Smalltalk, Haskell, Scala, tcl.
 >> 
 >>  > - Как проводится процесс контроля и устранения недостатков?
 >> 
 >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
 >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
 >> настолько мало там багов, что написание тестов не окупается.
 >> 
 > Ну это две параллельные задачи. Часто тесты нельзя написать.

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

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

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

 >>  > - Если несколько ревьюверов, как они просматривают код и вносят 
 >> замечания?
 >> 
 >> Их нет. Ревьюеров, в смысле. В одной из предыдущих контор был мем "кто
 >> первый встал, того и грабли". В смысле, багу исправляет тот, кто на нее
 >> наступил (или взялся за багрепорт). Это обеспечивает коллективное
 >> владение кодом. В отличие от code review, которое все-таки нет. При
 >> необходимости {git,svn,cvs} annotate и зовем автора проблемного
 >> места. Но это нужно очень не всегда.
 >> 
 > Но если в конторе более тысячи программистов, а за код отвечают разные
 > отделы, причём часть людей, его написавших, уже давно не работает, будет
 > ли такая схема эффективна (это не к моему случаю, а в общем)?

А в общем задача неразрешима. Это еще Гёдель доказал :) Решается всегда
в конкретном.

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

 >> За коммитами джуниоров просто присматривают вручную. Недолго, человек
 >> либо обучается, либо идет искать работу в другом месте.
 >> 
 > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
 > сложный, хотелось бы видеть, что уйдёт в репозиторий.

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

Практика показывает, что читать код _до_ попадания в репозиторий - не
очень хорошая идея. Благо репозиторий позволяет, если что, откатить.

Не, мне рассказывали байку о техпроцессе в Боинге с кодом, который идет
в авионику. Там ревью есть, но начинается оно не с would-be коммита, а с
обоснования, почему надо менять именно это место в коде, и как его
менять. Только там питона, баша и луа быть не может - их интерпретаторы
не удовлетворяют требованиям к тому техпроцессу.

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

 >>  >> В общем, даже модель pull request не использовали, не говоря уже о code
 >>  >> review. А вот работу в паре как раз использовали.
 >>  >> 
 >>  > А подробнее? Это из области "экстремального программирования"?
 >> 
 >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
 >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
 >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
 >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
 >> такие грабли".
 >> 
 >> Результаты различного качества, в зависимости в основном от дисциплины
 >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
 >> вылетает аппаратура, чем вылезают не дающие работать баги.
 >> 
 > Только читал об этом, не думал, что в РФ используется.

Это парадигма, ей чихать на государственные границы.

 > В любом случае, если я такое (чисто теоретически) предложу менеджеру,
 > он только у виска покрутит. Это же получается, что каждый программист
 > работает, условно половину времени, а половину сидит "и что-то там
 > смотрит".

А если тебе не результат а имитацию бурной деятельности для менеджера,
то да, подход 

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 17:00:47 +0300:

 >> Artem Chuprina  wrote:
 >> 
 >> Артем, при работе с джунами очень удобно ткнуть мышой в место в

...

 >> Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.
 >> 
 > В каком смысле? Что я "топлю"? Я так и делаю обычно (комментирую
 > строчки, либо показываю, что не так), а сейчас ищу для себя подходящий
 > интерфейс.

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

Re: Системы управления сервером?

[Artem Chuprina]

Alexander Gerasiov -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 
14:45:18 +0300:

 >>  >> В зависимости от сценария разработки - пуш на приватную ветку или
 >>  >> в свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит
 >>  >> дифф, оставляет комментарии (но не к строчкам кода/диффа, а
 >>  >> только к реквесту в целом) и аксептит или реджектит.
 >>  >> 
 >>  >>   
 >>  > Ладно, хотя бы реквесты есть.
 >>  > Но если больше 10 файлов в мердже, не особенно представляю, как с
 >>  > этим работать.
 >>  > Сам я работал с гитовыми репозиториями через gitlab и с bitbucket
 >>  > (ну да, если считать, что гогс повторяет интерфейс гитхаб, то и с
 >>  > ним, только с ревью), и без комментариев к строчкам, как-то
 >>  > коллективно работать с кодом было бы весьма сложно.  
 >> 
 >> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
 >> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких
 >> сложностей, и код работает.
 >> 
 >> В общем, даже модель pull request не использовали, не говоря уже о
 >> code review. А вот работу в паре как раз использовали.

 > Артем, при работе с джунами очень удобно ткнуть мышой в место в
 > коде/диффе и написать, что тут не так и как поправить. Особенно, когда
 > таких мест десяток. Без этого приходится либо сажать рядом и
 > показывать, либо в ядерном стиле, когда дифф в почте комментируется
 > инлайн.
 > Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.

Эффективнее всего - именно сажать рядом и показывать.

А если говорить о переписке, то логичнее поправить, закоммитить, и
прокомментировать _свой_ коммит.

Re: Системы управления сервером?

[artiom]

24.03.2018 14:45, Alexander Gerasiov пишет:
> Hello Artem,
> 
> On Sat, 24 Mar 2018 10:11:47 +0300
> Artem Chuprina  wrote:
> 
>>  >> В зависимости от сценария разработки - пуш на приватную ветку или
>>  >> в свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит
>>  >> дифф, оставляет комментарии (но не к строчкам кода/диффа, а
>>  >> только к реквесту в целом) и аксептит или реджектит.
>>  >> 
>>  >>   
>>  > Ладно, хотя бы реквесты есть.
>>  > Но если больше 10 файлов в мердже, не особенно представляю, как с
>>  > этим работать.
>>  > Сам я работал с гитовыми репозиториями через gitlab и с bitbucket
>>  > (ну да, если считать, что гогс повторяет интерфейс гитхаб, то и с
>>  > ним, только с ревью), и без комментариев к строчкам, как-то
>>  > коллективно работать с кодом было бы весьма сложно.  
>>
>> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
>> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких
>> сложностей, и код работает.
>>
>> В общем, даже модель pull request не использовали, не говоря уже о
>> code review. А вот работу в паре как раз использовали.
> 
> Артем, при работе с джунами очень удобно ткнуть мышой в место в
> коде/диффе и написать, что тут не так и как поправить. Особенно, когда
> таких мест десяток. Без этого приходится либо сажать рядом и
> показывать, либо в ядерном стиле, когда дифф в почте комментируется
> инлайн.
> Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.
> 
В каком смысле? Что я "топлю"? Я так и делаю обычно (комментирую
строчки, либо показываю, что не так), а сейчас ищу для себя подходящий
интерфейс.

Re: Системы управления сервером?

[artiom]

24.03.2018 11:47, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 10:58:11 +0300:
> 
>  >> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
>  >> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких сложностей, и
>  >> код работает.
>  >> 
>  > 1. Сейчас, где я работаю, используется TFS, прости Господи. Под Linux.
>  > Ревью проводится через CodeCollaborator. Это наследие такое. Гит тоже
>  > есть, но пока не везде.
>  > 2. Объективно лучше, чем ccollab, интерфейсы gitlab и bitbucket. Для
>  > всех без исключений. Даже те, кто больше всех матерился из-за перехода
>  > на git, в разных конторах, в итоге признавали, что "эти web-интерфейсы
>  > удобнее".
> 
>  > Не опровергаю ваш опыт, но узнать было бы интересно: как так?
>  > Т.е.:
> 
>  > - Первый вопрос: это код на Haskell, не C/C++ + Python + Lua + Bash + etc.?
> 
> C, C++, Smalltalk, Haskell, Scala, tcl.
> 
>  > - Как проводится процесс контроля и устранения недостатков?
> 
> В идеале пишутся тесты. Часть заранее, часть по мере наступания на
> грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
> настолько мало там багов, что написание тестов не окупается.
> 
Ну это две параллельные задачи. Часто тесты нельзя написать. Плюс, на
ревью проверяется читабельность кода и его логическая корректность (и
тесты, и код возможно написать некорректно).
Плюс, в два раза больше работы.
В общем, одно другое не заменяет.

>  > - Если несколько ревьюверов, как они просматривают код и вносят замечания?
> 
> Их нет. Ревьюеров, в смысле. В одной из предыдущих контор был мем "кто
> первый встал, того и грабли". В смысле, багу исправляет тот, кто на нее
> наступил (или взялся за багрепорт). Это обеспечивает коллективное
> владение кодом. В отличие от code review, которое все-таки нет. При
> необходимости {git,svn,cvs} annotate и зовем автора проблемного
> места. Но это нужно очень не всегда.
> 
Но если в конторе более тысячи программистов, а за код отвечают разные
отделы, причём часть людей, его написавших, уже давно не работает, будет
ли такая схема эффективна (это не к моему случаю, а в общем)?

> За коммитами джуниоров просто присматривают вручную. Недолго, человек
> либо обучается, либо идет искать работу в другом месте.
> 
Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код
сложный, хотелось бы видеть, что уйдёт в репозиторий.

>  > - Сколько людей работают с репозиторием?
> 
> Десятка полтора-два.
> 
Ну больше, чем в моём случае.

>  >> В общем, даже модель pull request не использовали, не говоря уже о code
>  >> review. А вот работу в паре как раз использовали.
>  >> 
>  > А подробнее? Это из области "экстремального программирования"?
> 
> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
> такие грабли".
> 
> Результаты различного качества, в зависимости в основном от дисциплины
> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
> вылетает аппаратура, чем вылезают не дающие работать баги.
> 
Только читал об этом, не думал, что в РФ используется. В любом случае,
если я такое (чисто теоретически) предложу менеджеру, он только у виска
покрутит. Это же получается, что каждый программист работает, условно
половину времени, а половину сидит "и что-то там смотрит".

Re: Системы управления сервером?

[artiom]

20.03.2018 16:23, Alexander Gerasiov пишет:
> Hello artiom,
> 
> On Mon, 19 Mar 2018 23:56:26 +0300
> artiom  wrote:
> 
>> Впечатлился статьёй.
>> Айн: https://habrahabr.ru/post/328048/
>> Цвайн:
>> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
>>
>> Помимо Proxmox, есть такая штука, как Cockpit:
>> http://cockpit-project.org
>>
>> О нём я ничего не знаю.
>> Собственно, Proxmox я тоже не использовал.
>>
>> Основные задачи:
>>
>> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
>> использован kvm в редких случаях).
> Используем Proxmox.
> 
Вот ещё насчёт Proxmox: возможно ли его поставить в Docker контейнер и
стоит ли это делать?

Re: Системы управления сервером?

[Sergey Matveev]

*** Alexander Gerasiov [2018-03-24 14:48]:
>при работе с джунами очень удобно ткнуть мышой в место в
>коде/диффе и написать, что тут не так и как поправить. Особенно, когда
>таких мест десяток. Без этого приходится либо сажать рядом и
>показывать, либо в ядерном стиле, когда дифф в почте комментируется
>инлайн.
>Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.

А я вот подобное делаю через самописный плагин для Vim:
https://git.stargrave.org/cgit.cgi/gerrvim.git/tree/doc/gerrvim.txt
Используется для работы с Gerrit, в котором есть JSON API. Суть
плагина проста: открываем файлы в коммите которые нужно
откомментировать, выделяем конкретные строки визуальным выделением, \cc,
появляется окно с вводом комментария,  и оно закрывается, сохраняя в
временный файл все аггрегированные комментарии, затем запускаем скрипт
преобразующий их в JSON и посылающий в Gerrit. Раньше он применялся не
только для Gerrit, но для подготовки комментариев к коду и для других
систем.

Я много лет комментировал код, как вы это назвали, inline-ом в патчах и
оставлял в виде комментария в Redmine/Trac системах. Потом не один год
провёл в Gerrit, где web-интерфейс в котором можно тыкнуть на строчки и
написать комментарий. Лично мне web-интерфейс не кажется удобным и нигде
не видел чтобы он был удобен. Если это нужно выполнить раз в полгода, то
тогда да, почему бы и нет. Но если с этим сталкиваться каждый день, если
это постоянный инструмент для ежедневного ревью, то ничто не сравнится с
окружением настроенным лично под себя, в удобном виде в редакторе
(Vim/Emacs) и почтовом клиенте. Не бывает инструментов одинаково удобных
для всех -- а web-интерфейсы это как-раз насильно диктуемая одна
программа для всех.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: Системы управления сервером?

[Alexander Gerasiov]

Hello Artem,

On Sat, 24 Mar 2018 10:11:47 +0300
Artem Chuprina  wrote:

>  >> В зависимости от сценария разработки - пуш на приватную ветку или
>  >> в свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит
>  >> дифф, оставляет комментарии (но не к строчкам кода/диффа, а
>  >> только к реквесту в целом) и аксептит или реджектит.
>  >> 
>  >>   
>  > Ладно, хотя бы реквесты есть.
>  > Но если больше 10 файлов в мердже, не особенно представляю, как с
>  > этим работать.
>  > Сам я работал с гитовыми репозиториями через gitlab и с bitbucket
>  > (ну да, если считать, что гогс повторяет интерфейс гитхаб, то и с
>  > ним, только с ревью), и без комментариев к строчкам, как-то
>  > коллективно работать с кодом было бы весьма сложно.  
> 
> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких
> сложностей, и код работает.
> 
> В общем, даже модель pull request не использовали, не говоря уже о
> code review. А вот работу в паре как раз использовали.

Артем, при работе с джунами очень удобно ткнуть мышой в место в
коде/диффе и написать, что тут не так и как поправить. Особенно, когда
таких мест десяток. Без этого приходится либо сажать рядом и
показывать, либо в ядерном стиле, когда дифф в почте комментируется
инлайн.
Так что не надо топить вебинтерфейсы, у них иногда действительно есть плюсы.



-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 10:58:11 +0300:

 >> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
 >> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких сложностей, и
 >> код работает.
 >> 
 > 1. Сейчас, где я работаю, используется TFS, прости Господи. Под Linux.
 > Ревью проводится через CodeCollaborator. Это наследие такое. Гит тоже
 > есть, но пока не везде.
 > 2. Объективно лучше, чем ccollab, интерфейсы gitlab и bitbucket. Для
 > всех без исключений. Даже те, кто больше всех матерился из-за перехода
 > на git, в разных конторах, в итоге признавали, что "эти web-интерфейсы
 > удобнее".

 > Не опровергаю ваш опыт, но узнать было бы интересно: как так?
 > Т.е.:

 > - Первый вопрос: это код на Haskell, не C/C++ + Python + Lua + Bash + etc.?

C, C++, Smalltalk, Haskell, Scala, tcl.

 > - Как проводится процесс контроля и устранения недостатков?

В идеале пишутся тесты. Часть заранее, часть по мере наступания на
грабли :) Код на Haskell и Scala даже и не тестируется автомагически,
настолько мало там багов, что написание тестов не окупается.

 > - Если несколько ревьюверов, как они просматривают код и вносят замечания?

Их нет. Ревьюеров, в смысле. В одной из предыдущих контор был мем "кто
первый встал, того и грабли". В смысле, багу исправляет тот, кто на нее
наступил (или взялся за багрепорт). Это обеспечивает коллективное
владение кодом. В отличие от code review, которое все-таки нет. При
необходимости {git,svn,cvs} annotate и зовем автора проблемного
места. Но это нужно очень не всегда.

За коммитами джуниоров просто присматривают вручную. Недолго, человек
либо обучается, либо идет искать работу в другом месте.

 > - Как и кем производится слияние feature-ветки в основную?

Релиз-менеджером. В смысле, тем, кто сегодня релиз-менеджер.

 > - Сколько людей работают с репозиторием?

Десятка полтора-два.

 >> В общем, даже модель pull request не использовали, не говоря уже о code
 >> review. А вот работу в паре как раз использовали.
 >> 
 > А подробнее? Это из области "экстремального программирования"?

Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй
рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем
абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность
сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот
такие грабли".

Результаты различного качества, в зависимости в основном от дисциплины
написания тестов. Но так, чтобы было неработоспособно - нет. Чаще
вылетает аппаратура, чем вылезают не дающие работать баги.

Re: Системы управления сервером?

[artiom]

> artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 08:32:41 +0300:
> 
>  >> gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
>  >> как-то запуститься и всё равно тормозит. Используем gogs.
>  >> 
>  > В gogs же нет code review?
>  > Это единственная причина, по которой я думаю о том, чтобы
>  > использовать гитлаб.
>  > Как без этого?  
>   Без этого боль, да. Но зато он работает в отличие от.
>     
>  >>> Да как работает? Я же не смогу посмотреть, что хотят в репозиторий
>  >>> залить. Это не работает.
>  >> В зависимости от сценария разработки - пуш на приватную ветку или в
>  >> свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит дифф,
>  >> оставляет комментарии (но не к строчкам кода/диффа, а только к реквесту
>  >> в целом) и аксептит или реджектит.
>  >> 
>  >> 
>  > Ладно, хотя бы реквесты есть.
>  > Но если больше 10 файлов в мердже, не особенно представляю, как с этим
>  > работать.
>  > Сам я работал с гитовыми репозиториями через gitlab и с bitbucket (ну
>  > да, если считать, что гогс повторяет интерфейс гитхаб, то и с ним,
>  > только с ревью), и без комментариев к строчкам, как-то коллективно
>  > работать с кодом было бы весьма сложно.
> 
> Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
> никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких сложностей, и
> код работает.
> 
1. Сейчас, где я работаю, используется TFS, прости Господи. Под Linux.
Ревью проводится через CodeCollaborator. Это наследие такое. Гит тоже
есть, но пока не везде.
2. Объективно лучше, чем ccollab, интерфейсы gitlab и bitbucket. Для
всех без исключений. Даже те, кто больше всех матерился из-за перехода
на git, в разных конторах, в итоге признавали, что "эти web-интерфейсы
удобнее".

Не опровергаю ваш опыт, но узнать было бы интересно: как так?
Т.е.:

- Первый вопрос: это код на Haskell, не C/C++ + Python + Lua + Bash + etc.?
- Как проводится процесс контроля и устранения недостатков?
- Если несколько ревьюверов, как они просматривают код и вносят замечания?
- Как и кем производится слияние feature-ветки в основную?
- Сколько людей работают с репозиторием?

> В общем, даже модель pull request не использовали, не говоря уже о code
> review. А вот работу в паре как раз использовали.
> 
А подробнее? Это из области "экстремального программирования"?

Re: Системы управления сервером?

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sat, 24 Mar 2018 08:32:41 +0300:

 >> gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
 >> как-то запуститься и всё равно тормозит. Используем gogs.
 >> 
 > В gogs же нет code review?
 > Это единственная причина, по которой я думаю о том, чтобы
 > использовать гитлаб.
 > Как без этого?  
  Без этого боль, да. Но зато он работает в отличие от.
    
 >>> Да как работает? Я же не смогу посмотреть, что хотят в репозиторий
 >>> залить. Это не работает.
 >> В зависимости от сценария разработки - пуш на приватную ветку или в
 >> свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит дифф,
 >> оставляет комментарии (но не к строчкам кода/диффа, а только к реквесту
 >> в целом) и аксептит или реджектит.
 >> 
 >> 
 > Ладно, хотя бы реквесты есть.
 > Но если больше 10 файлов в мердже, не особенно представляю, как с этим
 > работать.
 > Сам я работал с гитовыми репозиториями через gitlab и с bitbucket (ну
 > да, если считать, что гогс повторяет интерфейс гитхаб, то и с ним,
 > только с ревью), и без комментариев к строчкам, как-то коллективно
 > работать с кодом было бы весьма сложно.

Больше 15 лет работаю с кодом в коллективах. Ни разу не использовали
никаких гитлабов и вообще никаких уеб-интерфейсов. Никаких сложностей, и
код работает.

В общем, даже модель pull request не использовали, не говоря уже о code
review. А вот работу в паре как раз использовали.

Re: Системы управления сервером?

[artiom]

23.03.2018 11:26, Alexander Gerasiov пишет:
> Hello artiom,
> 
> On Thu, 22 Mar 2018 19:27:15 +0300
> artiom  wrote:
> 
> gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
> как-то запуститься и всё равно тормозит. Используем gogs.
> 
 В gogs же нет code review?
 Это единственная причина, по которой я думаю о том, чтобы
 использовать гитлаб.
 Как без этого?  
>>> Без этого боль, да. Но зато он работает в отличие от.
>>>   
>> Да как работает? Я же не смогу посмотреть, что хотят в репозиторий
>> залить. Это не работает.
> В зависимости от сценария разработки - пуш на приватную ветку или в
> свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит дифф,
> оставляет комментарии (но не к строчкам кода/диффа, а только к реквесту
> в целом) и аксептит или реджектит.
> 
> 
Ладно, хотя бы реквесты есть.
Но если больше 10 файлов в мердже, не особенно представляю, как с этим
работать.
Сам я работал с гитовыми репозиториями через gitlab и с bitbucket (ну
да, если считать, что гогс повторяет интерфейс гитхаб, то и с ним,
только с ревью), и без комментариев к строчкам, как-то коллективно
работать с кодом было бы весьма сложно.

Re: Системы управления сервером?

[Alexander Gerasiov]

Hello artiom,

On Thu, 22 Mar 2018 19:27:15 +0300
artiom  wrote:

> >>> gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
> >>> как-то запуститься и всё равно тормозит. Используем gogs.
> >>> 
> >> В gogs же нет code review?
> >> Это единственная причина, по которой я думаю о том, чтобы
> >> использовать гитлаб.
> >> Как без этого?  
> > Без этого боль, да. Но зато он работает в отличие от.
> >   
> Да как работает? Я же не смогу посмотреть, что хотят в репозиторий
> залить. Это не работает.
В зависимости от сценария разработки - пуш на приватную ветку или в
свой репозиторий и дальше пулл-реквест, где мейнтейнер смотрит дифф,
оставляет комментарии (но не к строчкам кода/диффа, а только к реквесту
в целом) и аксептит или реджектит.


-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Re: Системы управления сервером?

[artiom]

 - Централизованное управление пользователями: их несколько (менее
 10), надо им давать права к сервисам (облако (seafile), gitlab,
 медиа-сервер (типа kodi), каталоги с медиа-данными и просто
 данными), каталоги выделять в пуле и подобное.  
>>> Пользователи в ldap, управляются вручную скриптами поверх
>>> ldapscripts 
>> Но у вас много пользователей?
>> У меня более 10 не планируется.
>> Недостаточно ли просто создавать их на уровне ОС какими-либо штатными
>> средствами (остаётся только вопрос синхронизации для сервисов)?
> Можно, но именно синхронизация для сервисов будет напрягать. Для 3
> может и не надо, а вот для 10 я бы уже поднял.
> 
Понял вас.
Но хотелось бы мышкотыкательный интерфейс "всё в одном".
Потому и смотрю на Cockpit.


 Что для этого используют?
 Подходит ли Cocpkit (там есть управление контейнерами) или лучше
 использовать Proxmox и вариант, как в статье?
 Как вообще лучше организовать такую систему (изначально не
 предполагалось давать пользователям какие-то возможности, кроме
 доступа к gitlab)?  
>>> gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
>>> как-то запуститься и всё равно тормозит. Используем gogs.
>>>   
>> В gogs же нет code review?
>> Это единственная причина, по которой я думаю о том, чтобы использовать
>> гитлаб.
>> Как без этого?
> Без этого боль, да. Но зато он работает в отличие от.
> 
Да как работает? Я же не смогу посмотреть, что хотят в репозиторий залить.
Это не работает.

Re: Системы управления сервером?

[Alexander Gerasiov]

Hello artiom,

On Tue, 20 Mar 2018 22:49:43 +0300
artiom  wrote:

> 20.03.2018 16:23, Alexander Gerasiov пишет:
> > Hello artiom,
> > 
> > On Mon, 19 Mar 2018 23:56:26 +0300
> > artiom  wrote:
> >   
> >> Впечатлился статьёй.
> >> Айн: https://habrahabr.ru/post/328048/
> >> Цвайн:
> >> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
> >>
> >> Помимо Proxmox, есть такая штука, как Cockpit:
> >> http://cockpit-project.org
> >>
> >> О нём я ничего не знаю.
> >> Собственно, Proxmox я тоже не использовал.
> >>
> >> Основные задачи:
> >>
> >> - Отделение сервисов путём контейнеризации (docker+lxc, возможно
> >> будет использован kvm в редких случаях).  
> > Используем Proxmox.
> >   
> Почему именно его?
Потому что исторически использовали его кластер, когда было несколько
узлов и привыкли к нему. (Достаточно удобный и продуманный интерфейс и
т.п.) Когда виртуалки создаются раз в пару месяцев, то очень приятно,
что есть мастера создания, а не надо каждый раз крутить маны.

> 
> >> - Централизованное управление пользователями: их несколько (менее
> >> 10), надо им давать права к сервисам (облако (seafile), gitlab,
> >> медиа-сервер (типа kodi), каталоги с медиа-данными и просто
> >> данными), каталоги выделять в пуле и подобное.  
> > Пользователи в ldap, управляются вручную скриптами поверх
> > ldapscripts 
> Но у вас много пользователей?
> У меня более 10 не планируется.
> Недостаточно ли просто создавать их на уровне ОС какими-либо штатными
> средствами (остаётся только вопрос синхронизации для сервисов)?
Можно, но именно синхронизация для сервисов будет напрягать. Для 3
может и не надо, а вот для 10 я бы уже поднял.

> 
> >>
> >> Что для этого используют?
> >> Подходит ли Cocpkit (там есть управление контейнерами) или лучше
> >> использовать Proxmox и вариант, как в статье?
> >> Как вообще лучше организовать такую систему (изначально не
> >> предполагалось давать пользователям какие-то возможности, кроме
> >> доступа к gitlab)?  
> > gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
> > как-то запуститься и всё равно тормозит. Используем gogs.
> >   
> В gogs же нет code review?
> Это единственная причина, по которой я думаю о том, чтобы использовать
> гитлаб.
> Как без этого?
Без этого боль, да. Но зато он работает в отличие от.


-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Re: Системы управления сервером?

[artiom]

Ansible - тяжёлый и сложный?
Не исключаю, но стоит учесть, что у меня не крупный сервер, а прежде
всего NAS, предоставляющий дополнительные сервисы ограниченному
количеству людей.
А про Cockpit что-нибудь можете сказать?

21.03.2018 15:56, Павел Марченко пишет:
> Ansible  как вариант, у него полно модулей по управлению облычными
> платформами
> http://docs.ansible.com/ansible/latest/list_of_cloud_modules.html
> Ну и стандартные, типо юзера
> http://docs.ansible.com/ansible/latest/user_module.html
> Аклы
> http://docs.ansible.com/ansible/latest/acl_module.html
> 
> P.S. прошу прощение, за сообщение в личку
> 
> 
> пн, 19 мар. 2018 г. в 23:57, artiom  >:
> 
> Впечатлился статьёй.
> Айн: https://habrahabr.ru/post/328048/
> Цвайн:
> 
> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
> 
> Помимо Proxmox, есть такая штука, как Cockpit:
> http://cockpit-project.org
> 
> О нём я ничего не знаю.
> Собственно, Proxmox я тоже не использовал.
> 
> Основные задачи:
> 
> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
> использован kvm в редких случаях).
> - Централизованное управление пользователями: их несколько (менее 10),
> надо им давать права к сервисам (облако (seafile), gitlab, медиа-сервер
> (типа kodi), каталоги с медиа-данными и просто данными), каталоги
> выделять в пуле и подобное.
> 
> Что для этого используют?
> Подходит ли Cocpkit (там есть управление контейнерами) или лучше
> использовать Proxmox и вариант, как в статье?
> Как вообще лучше организовать такую систему (изначально не
> предполагалось давать пользователям какие-то возможности, кроме доступа
> к gitlab)?
> 
> 
> 
> -- 
> Regards, Pavel.

Re: Системы управления сервером?

[artiom]

Ansible - тяжёлый и сложный?
Не исключаю, но стоит учесть, что у меня не крупный сервер, а прежде
всего NAS, предоставляющий дополнительные сервисы ограниченному
количеству людей.
А про Cockpit что-нибудь можете сказать?

21.03.2018 15:56, Павел Марченко пишет:
> Ansible  как вариант, у него полно модулей по управлению облычными
> платформами
> http://docs.ansible.com/ansible/latest/list_of_cloud_modules.html
> Ну и стандартные, типо юзера
> http://docs.ansible.com/ansible/latest/user_module.html
> Аклы
> http://docs.ansible.com/ansible/latest/acl_module.html
> 
> P.S. прошу прощение, за сообщение в личку
> 
> 
> пн, 19 мар. 2018 г. в 23:57, artiom  >:
> 
> Впечатлился статьёй.
> Айн: https://habrahabr.ru/post/328048/
> Цвайн:
> 
> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
> 
> Помимо Proxmox, есть такая штука, как Cockpit:
> http://cockpit-project.org
> 
> О нём я ничего не знаю.
> Собственно, Proxmox я тоже не использовал.
> 
> Основные задачи:
> 
> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
> использован kvm в редких случаях).
> - Централизованное управление пользователями: их несколько (менее 10),
> надо им давать права к сервисам (облако (seafile), gitlab, медиа-сервер
> (типа kodi), каталоги с медиа-данными и просто данными), каталоги
> выделять в пуле и подобное.
> 
> Что для этого используют?
> Подходит ли Cocpkit (там есть управление контейнерами) или лучше
> использовать Proxmox и вариант, как в статье?
> Как вообще лучше организовать такую систему (изначально не
> предполагалось давать пользователям какие-то возможности, кроме доступа
> к gitlab)?
> 
> 
> 
> -- 
> Regards, Pavel.

Re: Системы управления сервером?

[Павел Марченко]

 Ansible  как вариант, у него полно модулей по управлению облычными
платформами
http://docs.ansible.com/ansible/latest/list_of_cloud_modules.html
Ну и стандартные, типо юзера
http://docs.ansible.com/ansible/latest/user_module.html
Аклы
http://docs.ansible.com/ansible/latest/acl_module.html

P.S. прошу прощение, за сообщение в личку


пн, 19 мар. 2018 г. в 23:57, artiom :

> Впечатлился статьёй.
> Айн: https://habrahabr.ru/post/328048/
> Цвайн:
>
> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
>
> Помимо Proxmox, есть такая штука, как Cockpit: http://cockpit-project.org
>
> О нём я ничего не знаю.
> Собственно, Proxmox я тоже не использовал.
>
> Основные задачи:
>
> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
> использован kvm в редких случаях).
> - Централизованное управление пользователями: их несколько (менее 10),
> надо им давать права к сервисам (облако (seafile), gitlab, медиа-сервер
> (типа kodi), каталоги с медиа-данными и просто данными), каталоги
> выделять в пуле и подобное.
>
> Что для этого используют?
> Подходит ли Cocpkit (там есть управление контейнерами) или лучше
> использовать Proxmox и вариант, как в статье?
> Как вообще лучше организовать такую систему (изначально не
> предполагалось давать пользователям какие-то возможности, кроме доступа
> к gitlab)?
>
>

-- 
Regards, Pavel.

Re: Системы управления сервером?

[artiom]

20.03.2018 16:23, Alexander Gerasiov пишет:
> Hello artiom,
> 
> On Mon, 19 Mar 2018 23:56:26 +0300
> artiom  wrote:
> 
>> Впечатлился статьёй.
>> Айн: https://habrahabr.ru/post/328048/
>> Цвайн:
>> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
>>
>> Помимо Proxmox, есть такая штука, как Cockpit:
>> http://cockpit-project.org
>>
>> О нём я ничего не знаю.
>> Собственно, Proxmox я тоже не использовал.
>>
>> Основные задачи:
>>
>> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
>> использован kvm в редких случаях).
> Используем Proxmox.
> 
Почему именно его?

>> - Централизованное управление пользователями: их несколько (менее 10),
>> надо им давать права к сервисам (облако (seafile), gitlab,
>> медиа-сервер (типа kodi), каталоги с медиа-данными и просто данными),
>> каталоги выделять в пуле и подобное.
> Пользователи в ldap, управляются вручную скриптами поверх ldapscripts
> 
Но у вас много пользователей?
У меня более 10 не планируется.
Недостаточно ли просто создавать их на уровне ОС какими-либо штатными
средствами (остаётся только вопрос синхронизации для сервисов)?

>>
>> Что для этого используют?
>> Подходит ли Cocpkit (там есть управление контейнерами) или лучше
>> использовать Proxmox и вариант, как в статье?
>> Как вообще лучше организовать такую систему (изначально не
>> предполагалось давать пользователям какие-то возможности, кроме
>> доступа к gitlab)?
> gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
> как-то запуститься и всё равно тормозит. Используем gogs.
> 
В gogs же нет code review?
Это единственная причина, по которой я думаю о том, чтобы использовать
гитлаб.
Как без этого?

Re: Системы управления сервером?

[Alexander Gerasiov]

Hello artiom,

On Mon, 19 Mar 2018 23:56:26 +0300
artiom  wrote:

> Впечатлился статьёй.
> Айн: https://habrahabr.ru/post/328048/
> Цвайн:
> https://forum.level1techs.com/t/how-to-create-a-nas-using-zfs-and-proxmox-with-pictures/117375
> 
> Помимо Proxmox, есть такая штука, как Cockpit:
> http://cockpit-project.org
> 
> О нём я ничего не знаю.
> Собственно, Proxmox я тоже не использовал.
> 
> Основные задачи:
> 
> - Отделение сервисов путём контейнеризации (docker+lxc, возможно будет
> использован kvm в редких случаях).
Используем Proxmox.

> - Централизованное управление пользователями: их несколько (менее 10),
> надо им давать права к сервисам (облако (seafile), gitlab,
> медиа-сервер (типа kodi), каталоги с медиа-данными и просто данными),
> каталоги выделять в пуле и подобное.
Пользователи в ldap, управляются вручную скриптами поверх ldapscripts

> 
> Что для этого используют?
> Подходит ли Cocpkit (там есть управление контейнерами) или лучше
> использовать Proxmox и вариант, как в статье?
> Как вообще лучше организовать такую систему (изначально не
> предполагалось давать пользователям какие-то возможности, кроме
> доступа к gitlab)?
gitlab офигительно тяжелый, ест 2-4 гига памяти просто чтобы хоть
как-то запуститься и всё равно тормозит. Используем gogs.


-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: g...@cs.msu.su  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1