emacs, работа с кодом на сервере разработки

> Ты представляешь себе многозвенную сложную систему уровня гугла?

Вы хотите сказать, что в Гугл так и работают? Т.е. у них работают «настоящие крутые профессионалы», которые занимаются параллельной разработкой сразу всех существующих у них там компонент и постоянно скачут с сервера на сервер?

Все равно работа будет происходить фактически удаленно.

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

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

А как это называеть, если твой локальный компонент завязн на кучу других компонентов, которые запущены на других машинах?

> А как это называеть, если твой локальный компонент завязн на кучу

других компонентов, которые запущены на других машинах?

Это называется «сеть». И?

Ну и в чем смысл мой компонент разрабатывать локально? У меня может быть ноутбук с wifi и я обмениваюсь гигабайтами с другими компонентами. Гораздо проще использовать ssh. Тем более я вообще не вижу никакой разницы между локальной разработкой и удаленной. Неудобств нет никаких. Разве что на локальной машине железо может быть дохлое (по сравнению с серверным) и канал тонкий, что создает как раз неудобства локальной разработки.

Тем более я вообще не вижу никакой разницы между локальной разработкой и удаленной. Неудобств нет никаких

Проблема в другом. Тебе неудобно работать локально. Этот факт говорит о том, что с проектом не всё ладно.

не у каждого разработчика есть возможность локально выделить несколько ТБ под данные и использовать несколько десятков ГБ памяти

Да я знаю. Сам пользуюсь. Просто, по-моему, в описываемом случае не лучшее решение. Если уж всё равно git, то зачем что-то ещё?

> не у каждого разработчика есть возможность локально выделить

несколько ТБ под данные и использовать несколько десятков ГБ памяти

Неужели ваши программы занимают сколько места на диске и жрут столько оперативки?

> Тебе неудобно работать локально. Этот факт говорит о том, что с проектом не всё ладно.

Это говорит о том что проекты бывают разные.

проекты бывают разные.

Да, да, особые секретные проекты на которых нужны петафлопсы и террабайты. Чушь! Не можете смасштабировать проект в обратную сторону, до тачки разработчика? Грош вам цена.

> Не можете смасштабировать проект в обратную сторону, до тачки разработчика? Грош вам цена.

А зачем мне это делать? :)

А зачем мне это делать? :)

Если это сделает только один, то незачем. Если команда, это даст профит в виде документации и отлове багов. Плюс проект станет банально удобно поддерживать, появится нормальная система конфигов. Также облегчит интеграционное тестирование. Оздоровит процесс разработки в конце концов. Так-то.

А если ты ищешь сугубо персональные преимущества, то для каждого они свои. Для меня это возможность работать в оффлайне, где угодно и когда угодно. Более быстрый цикл разработки. Способность оперативно поменять настройки окружения.

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

Ты представляешь себе многозвенную сложную систему уровня гугла?

сдаётся мне, что тут всё гораздо банальней

Ну поднимешь ты один из узлов у себя на машине локально, а дальше что?

то, что нестабильное и в разработке — пускай отстаивается в локальных sandbox.

Все равно работа будет происходить фактически удаленно.

а удалённо пусть заливается уже протестированное. А то дальше они вдвоём-втроём будут по ssh одни и те же файлы править.

а удалённо пусть заливается уже протестированное. А то дальше они вдвоём-втроём будут по ssh одни и те же файлы править.

Почему одни и те же? Для тестирования есть тестовая среда, состоящая из нескольких серверов.

> Неужели ваши программы занимают сколько места на диске и жрут столько оперативки?

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

// тот же анонимус

baverman, а у меня это не работает, потому что есть допустим разработчик Пётр с windows у которого система локально просто не запустится и таким образом мне всё равно нужно поддерживать сервер разработки, а заставлять его переходить на GNU я не хочу.

а у меня это не работает

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

> Можно настроить емакс там и работать из консоли. Но это еще хуже.

А про X11 forwarding в ssh Вам известно? :)

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

Для распределенных систем это не работает.

Назови три причины почему разработчик должен работать с точнейшей копией продакшена?

Почему с точной? Чтобы полностью нормально проверить работоспособность системы надо поднимать по крайней мере по два узла каждого типа. Чтобы проверить масштабируемость, то узлов надо больше и для этого есть бета-кластер. Цикл юниттесты_на_локалхосте->бета->продакшен существенно проще чем поднимать аналог (а не копию!) продакшена у себя на локалхосте.

Чтобы полностью нормально проверить работоспособность системы

Надо прогнать интеграционные тесты. И для этого, обычно, девелоперские машины слишком слабые.

Чтобы проверить масштабируемость

Нужны стресс тесты.

Цикл юниттесты_на_локалхосте->бета->продакшен существенно проще чем поднимать аналог (а не копию!) продакшена у себя на локалхосте.

Что прикажешь делать разработчикам фронтэндов? Им результат нужен здесь и сейчас.

С фронтэендам как раз все просто, ибо они легко поднимаются где угодно.

При условии если разработчику фронтенда не надо вносить изменения в вдругие компоненты системы. Если надо, то будет жопа :)

Так, погоди, мы начинаем говорить об одном и том же.

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

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