Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.

Что имеется в наличии из железа:

32bit win машинка — E8400@3.0Ghz 2 cores, 4GB ram
64bit linux машинка — i7@3.7Ghz 8 cores, 8GB
несколько дев серваков (64 bit linux) — по 20-30 cores, 50-100GB памяти каждый,

Вопрос — как настроить систему чтобы процесс разработки был удобен и быстр?

Пока в голову приходит очевидное — win компьютер оставить для имейлов,
код держать и собирать удаленно на сервере[ах], редактировать и удаленно отлаживаться
на linux копьмютере.

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

Советы/Наставления?

13.09.2013 15:14, Igor Sukhov пишет:

> Советы/Наставления?
Зачем это все городить? Спроси разрабов, что им удобнее, проведи митинг
и решите.
Кому-то удобнее в Студии писать, кому-то в Емаксе, кому в, прости
господи, Еклипсе. Просто обсудите и примите единое решение.

Здравствуйте, Vzhyk, Вы писали:

V>13.09.2013 15:14, Igor Sukhov пишет:

>> Советы/Наставления?
V>Зачем это все городить? Спроси разрабов, что им удобнее, проведи митинг
V>и решите.
V>Кому-то удобнее в Студии писать, кому-то в Емаксе, кому в, прости
V>господи, Еклипсе. Просто обсудите и примите единое решение.
какой митинг, с кем? я и сам могу принять такое решение (базируясь на ваших советах) — я для себя лично спрашиваю.

13.09.2013 15:36, Igor Sukhov пишет:

> какой митинг, с кем? я и сам могу принять такое решение (базируясь на
> ваших советах) — я для себя лично спрашиваю.
С сотрудниками.
Можешь — это называется волюнтаристское решение и оно как правило
гарантирует сильное понижение производительности труда, пока все не
привыкнут.

13.09.2013 15:14, Igor Sukhov пишет:

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

Здравствуйте, Vzhyk, Вы писали:

>> какой митинг, с кем? я и сам могу принять такое решение (базируясь на
>> ваших советах) — я для себя лично спрашиваю.
V>С сотрудниками.
V>Можешь — это называется волюнтаристское решение и оно как правило
V>гарантирует сильное понижение производительности труда, пока все не
V>привыкнут.
я для себя спрашиваю — только свою машинку так скофигурирую, никого больше не буду мучить своими идеями или советами често. обещаю.

p.s. Vzhyk, мне импонирует твоя плодовитость, но всему есть предел — это не форум политика или жизнь — пожалуйста попытайся быть более конструктивным.

13.09.2013 15:53, Igor Sukhov пишет:

> я для себя спрашиваю — только свою машинку так скофигурирую, никого
> больше не буду мучить своими идеями или советами често. обещаю.
>
> p.s. Vzhyk, мне импонирует твоя плодовитость, но всему есть предел — это
> не форум политика или жизнь — пожалуйста попытайся быть более
> конструктивным.
Попытаюсь объяснить еще раз. Ни один человек не способен угадать, что
для тебя удобнее. Максимум, что из твоей ветки при таком подходе
получится еще один срач, которому место в священных войнах.
От себя скажу, я работал в куче разных IDE и в общем пофиг какую
выбирать, в каждой есть свои плюсы и минусы. Но, есть время перехода с
одной на другую, когда твоя производительность сильно падает.
Посему ты можешь посмотреть несколько и выбрать ту, что удобнее, также и
с остальными инструментами.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.

У нас обычный си, так что нам попроще. У каждого ноут (с внешним монитором + клавой) и в серверной стойка с машинами — два сервака для сборки (на 15 человек где то) и с десяток тестовых машин, в 10гигабитной сетке. Стойка доступна снаружи по vpn.

А дальше народ ходит с ноутов на те билд-серверы и там vim/emacs, сборка и rsync собранного туда, где тестим. А то и на тестовой машине можно все собирать сразу (git склонировать туда и всех делов). Ну, вам можно запускать eclipse через xforwarding, внутри локалки оно покатит вполне.

Почту все держат на ноутах, да.

Здравствуйте, aik, Вы писали:

aik>Здравствуйте, Igor Sukhov, Вы писали:

IS>>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.

aik>У нас обычный си, так что нам попроще. У каждого ноут (с внешним монитором + клавой) и в серверной стойка с машинами — два сервака для сборки (на 15 человек где то) и с десяток тестовых машин, в 10гигабитной сетке. Стойка доступна снаружи по vpn.
т.е. на локальных машинах вы ничего не собираете и не тестируете, и используете только для редактирования кода?

aik>А дальше народ ходит с ноутов на те билд-серверы и там vim/emacs, сборка и rsync собранного туда, где тестим. А то и на тестовой машине можно все собирать сразу (git склонировать туда и всех делов). Ну, вам можно запускать eclipse через xforwarding, внутри локалки оно покатит вполне.
ага — спасибо за информацию. у нас используются похожие подходы, хочу понять какой же лучше. часть собирают и тестируют код локально, кто-то откровенно не примемлет редактирование на юниксе и редактирет в visual studio с keyhole интеграцией изменений на build server и там уже собирает, отлаживает.

eclipse черех x11 я пробовал, есть заметные лаги при работе с большими (3000+ lines) файлами исходников, не знаю упирается ли это в скорость файловой системы на общем сервере (памяти и вычислительной мощности должно хватать по сути дела) или в xforwarding — не понятно.
ну и на linux не нашел ничего сравнимого с Araxis Merge/Compare для визуального 3-way сравнения и мержинга изменений.

aik>Почту все держат на ноутах, да.
а ноуте что стоит linux;win?

Здравствуйте, Igor Sukhov, Вы писали:

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

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

а что за проект-то? его точно нельзя гонять под виндой? я вот пять лет занимался разработкой движка для аппаратно-программного комплекса и 99% времени проводил на виндовой машине, на которой оно собиралось и даже исполнялось благодаря "затычкам". пару раз в месяц его можно собрать на целевой системе для тестов и отчетности.

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

Здравствуйте, Igor Sukhov, Вы писали:

IS>>>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>>>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.
aik>>У нас обычный си, так что нам попроще. У каждого ноут (с внешним монитором + клавой) и в серверной стойка с машинами — два сервака для сборки (на 15 человек где то) и с десяток тестовых машин, в 10гигабитной сетке. Стойка доступна снаружи по vpn.
IS>т.е. на локальных машинах вы ничего не собираете и не тестируете, и используете только для редактирования кода?

Да даже код не редактируют по большей части (я так вообще никогда), все делается на билд-серверах. vim/emacs хорошо работают по сетке

aik>>А дальше народ ходит с ноутов на те билд-серверы и там vim/emacs, сборка и rsync собранного туда, где тестим. А то и на тестовой машине можно все собирать сразу (git склонировать туда и всех делов). Ну, вам можно запускать eclipse через xforwarding, внутри локалки оно покатит вполне.
IS>ага — спасибо за информацию. у нас используются похожие подходы, хочу понять какой же лучше. часть собирают и тестируют код локально, кто-то откровенно не примемлет редактирование на юниксе и редактирет в visual studio с keyhole интеграцией изменений на build server и там уже собирает, отлаживает.

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

IS>eclipse черех x11 я пробовал, есть заметные лаги при работе с большими (3000+ lines) файлами исходников, не знаю упирается ли это в скорость файловой системы на общем сервере (памяти и вычислительной мощности должно хватать по сути дела) или в xforwarding — не понятно.

xforwarding в локалке не должен тормозить вообще, как я понимаю. Тот же самый проект на локальной машине — не лагает?

IS>ну и на linux не нашел ничего сравнимого с Araxis Merge/Compare для визуального 3-way сравнения и мержинга изменений.

aik>>Почту все держат на ноутах, да.
IS>а ноуте что стоит linux;win?

linux, мы ж ядром занимаемся, мне винду сначала не разрешили, потом сказали что пошутили и винду можно, но "ватсон уже не мог без трубки" Но реально для почты и терминалов — как то по барабану — все одинаково, а вот бесплатного нормально xserver'а под винду — не уверен что есть.

Здравствуйте, aik, Вы писали:

IS>>>>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>>>>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.
aik>>>У нас обычный си, так что нам попроще. У каждого ноут (с внешним монитором + клавой) и в серверной стойка с машинами — два сервака для сборки (на 15 человек где то) и с десяток тестовых машин, в 10гигабитной сетке. Стойка доступна снаружи по vpn.
IS>>т.е. на локальных машинах вы ничего не собираете и не тестируете, и используете только для редактирования кода?
aik>Да даже код не редактируют по большей части (я так вообще никогда), все делается на билд-серверах. vim/emacs хорошо работают по сетке
для редактировая vim конечно пойдет, но это же все такие редактор текста, а не кода, рефакторинг он не понимает, итд

IS>>eclipse черех x11 я пробовал, есть заметные лаги при работе с большими (3000+ lines) файлами исходников, не знаю упирается ли это в скорость файловой системы на общем сервере (памяти и вычислительной мощности должно хватать по сути дела) или в xforwarding — не понятно.
aik>xforwarding в локалке не должен тормозить вообще, как я понимаю. Тот же самый проект на локальной машине — не лагает?
тоже лагает, но не так заметно.

IS>>ну и на linux не нашел ничего сравнимого с Araxis Merge/Compare для визуального 3-way сравнения и мержинга изменений.
aik>>>Почту все держат на ноутах, да.
IS>>а ноуте что стоит linux;win?

aik>linux, мы ж ядром занимаемся, мне винду сначала не разрешили, потом сказали что пошутили и винду можно, но "ватсон уже не мог без трубки" Но реально для почты и терминалов — как то по барабану — все одинаково, а вот бесплатного нормально xserver'а под винду — не уверен что есть.
ясно. а xserver можно и за деньги купить — exceed тотже, хотя я не заметил разницы между xming-ом.

Здравствуйте, мыщъх, Вы писали:

IS>>Вопрос — как настроить систему чтобы процесс разработки был удобен и быстр?
М>git? вполне подходит для синхронизации, а так же локальной разработки пока недоступен основной репр.

М>чтобы окружение было везде одинаковым, лично я перешел на вм варю даже на основной машине, что дает возможность автоматической синхронизации образа на любой другой машине (это на случай, если я решил чего-то доустановить).
ну это мне не нужно — тебе наверно важно ездить по клиентам, и работать у них, или иметь возможнотсь быстро показать / пофиксиить на месте.
у меня требование другое — максимальное удобсвто при разработке на стационаре. мне проще пользователя/аналитика к себе дернуть так как он в штате.

М>а что за проект-то? его точно нельзя гонять под виндой? я вот пять лет занимался разработкой движка для аппаратно-программного комплекса и 99% времени проводил на виндовой машине, на которой оно собиралось и даже исполнялось благодаря "затычкам". пару раз в месяц его можно собрать на целевой системе для тестов и отчетности.
под виндой его вроде бы можно гонять, я просто не уверен зачем — если можно гонять на линуксе... ну и собирать проект для тестов приходится по несокольку раз на дню —
континьюос интергрейшен... ну или почти.

М>кстати, если позволяют финансы рекоменую попробовать в качестве среды разработки мак и TextMate, привыкнув к которому я уже не могу вернуться в вынь/линух, т.к. там нет кошерной ИДЕ.
ты зачем меня ввел заблуждение — TM оказывется только под MacOS, а то я уже почти его запросил установить.

Здравствуйте, Igor Sukhov, Вы писали:

IS>ну и на linux не нашел ничего сравнимого с Araxis Merge/Compare для визуального 3-way сравнения и мержинга изменени

Araxis — сила, согласен. Я для простых изменений использую текствовый мерж, а для более сложных meld. Этот единственный тул, который не выглядит вырвиглазно, ну и чем-то на araxis похож.

Здравствуйте, andrey.desman, Вы писали:

IS>>ну и на linux не нашел ничего сравнимого с Araxis Merge/Compare для визуального 3-way сравнения и мержинга изменени
AD>Araxis — сила, согласен. Я для простых изменений использую текствовый мерж, а для более сложных meld. Этот единственный тул, который не выглядит вырвиглазно, ну и чем-то на araxis похож.

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

Здравствуйте, Igor Sukhov, Вы писали:

IS>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.

IS>Советы/Наставления?
Зависит от привычек. Если привыкли работать с Visual Studio, можно воспользоваться нашим продуктом. Вот здесь расписан по шагам процесс создания простого проекта под Linux из VS. Автоматическая синхронизация файлов, сброка и отладка, разумеется, поддерживается.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.
Я использую ObjC IDE от JetBrains на Mac OS X. Они обещают осенью выпустить С++-ную версию под Linux — стоит посмотреть как выйдет.

Здравствуйте, bazis1, Вы писали:

IS>>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.

IS>>Советы/Наставления?
B>Зависит от привычек. Если привыкли работать с Visual Studio, можно воспользоваться нашим продуктом. Вот здесь расписан по шагам процесс создания простого проекта под Linux из VS. Автоматическая синхронизация файлов, сброка и отладка, разумеется, поддерживается.

привык к студии — но не уверен что это будет хорошая привычка под линуксом.

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

Здравствуйте, Igor Sukhov, Вы писали:

IS>привык к студии — но не уверен что это будет хорошая привычка под линуксом.

IS>про твой сайт я помнил — вопросов два — сколько будет стоить на одного разработчика, можно ли будет вернуть деньги если не понравится (unlikely, потому как это лишний геморой, но все же) и умеет ли такой подход работать со сложными проектами — иерархические makefile-ы, самодельные тулы вызывающиеся при сборке, итд.
На одного разработчика — $99 за Linux Edition либо $199 за Custom Edition. Custom Edition позволяет добавлять дополнительные команды (например, передачу выбранных файлов между машинами) в процесс сборки и отладки.
Сложные проекты поддерживаются, но чем сложнее проект, тем больше настроек нужно поменять. Например, если в иерархическом проекте списки файлов раскиданы по нескольким Makefiles, то при добавлении нового файла в проект студии VisualGDB не будет знать, в какой из Make-файлов его добавить и это нужно будет делать либо руками, либо с помощью Build Extension.
Если сборка уже хорошо настроена, можно переключить Build Subsystem в Custom Build, и указать VisualGDB команду для сборки, директорию с исходниками, которую нужно синхронизировать и сервером и местонахождение бинарного файла для отладки.

Деньги можно вернуть в течение 30 дней, но я бы советовал проверить все в Trial-версии (она ограничена исключительно по времени) и покупать, убедившись, что все работает. Техподдержка для trial работает точно так же, как и после покупки.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Преамбула — есть большой с++ проект под linux, нужно настроить машинк[и] для разработчика.
IS>чтобы было удобно и писать код, и тестировать, и переписываться с пользователями/аналитиками/начальством.
IS>Надо что-то придумать для случая когда сервера будут или недоступны, скоро станут недоступны
IS>(исчезнут результаты долговыполняющегося теста) или сильно загружены, и тогда придется собирать и
IS>гонять проект локально (тут видимо надо будет придумать как синхронизировать
IS>изменения файлов — сервер/локальная машина).
IS>Советы/Наставления?

У нас так организовано:
1. Код лежит в git.
2. Разработчики клонируют код на свои машины и ведут разработку локально.
3. Для сборки используется cmake. Это удобнее make и, в добавок, позволяет собирать код и на Windows тоже.
4. Используется система peer review Gerrit. Это бесплатный открытый проект, используется в Google для разработки Android. Все изменения сначала проверяются, код обсуждается и патчится, если необходимо. Потому все попадает в основную ветку разработки.
5. Для построения проектов запущен сервер TeamCity. У него для проектов настроены обычные Vbox виртуалки, на которых крутятся целевые системы для сборки. Gerrit можно настроить таким образом, чтобы при комите разработчиком кода в репозиторий выполнялся скрипт-перехватчик, который запускает на TeamCity билд в соответствующем окружении. Алгоритм построения сначала запускает скрипт проверки стиля кодирования, потом сборку кода, а затем -- запуск юнит-тестов. Каждый из шагов алгоритма устанавливает в Gerrit для данного изменения кода свой флажок проверки, прошла проверка или нет. В результате, когда код приходит на ревью, у него уже есть три флага, которые обязательно должны быть исполнены. Ну понятно, что есть еще и релизные билды, которые запускаются по времени.
6. Код сервера и базу Gerrit периодически бэкапим, чтобы в случае чего восстановить. Ну, бэкап можно настроить и по другому.

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

На стороне локальной машины лучше дать разработчику возможность настроить окружение так, как ему удобно. Я, например, использую gvim + make прямо из консоли. Но многие разработчики используют инструменты для проектной разработки.