Разработка через [закрытый] Удаленный рабочий стол
В этом случае вы можете использовать данные JSON. Вы можете сохранить свои данные JSON в файле, перехватить ваш запрос в Interceptors и отправить имитирующие данные из файла, как показано ниже.
@Injectable()
export class SampleInterceptor implements HttpInterceptor {
constructor(private http: HttpClient) {}
intercept(
request: HttpRequest<any>,
next: HttpHandler
): Observable<HttpEvent<any>> {
const httpRequest = new HttpRequest(
<any>request.method,
"./../../assets/sample.json"
);
request = Object.assign(request, httpRequest);
request = request.clone();
return next.handle(request);
}
}
14 ответов
Я видел ситуацию, где была предпринята попытка, чтобы сделать это с sattelite офисом. Это было сделано для группы разработчиков Java, использующей различные инструменты IDE Java. Результат не рассматривался как успех, и компания возвратила команду в центральный лондонский офис за значительный счет.
Для кого-то делающего это на день за днем основании на интерактивном программном обеспечении, результат не действительно очень приятен. Для чего-то, что главным образом использует основанные на тексте инструменты, такие как энергия и инструменты командной строки Unix, она работает несколько лучше. Однажды у меня был осмотр XVNC через 128 ссылок Kbit DSL (типа, который был распространен в Новой Зеландии в то время), и мог сделать работу над основанным на Oracle хранилищем данных в удаленном местоположении вполне с готовностью. Уровень интерактивности, требуемой инструментами, сделал их намного менее чувствительными к медленному каналу, чем IDE на базе Windows.
Так, я вызову спор 'it depends' с некоторыми квалификациями:
Я не рекомендовал бы это для современного IDE, и конечно не для чего-то в большой степени графического как DreamWeaver, BI Development Studio или Informatica.
Для текстовой среды как традиционные средства разработки Unix это могло, вероятно, быть сделано работать вполне хорошо. Эти пользовательские интерфейсы намного менее чувствительны к задержке, чем пользовательский интерфейс непосредственного управления.
Я - что-то вроде сторонника 'лучших инструментов' принцип. Старание изо всех сил дать второразрядный пользовательский интерфейс группе разработчиков испустит отрицательные сигналы. Снижение расходов от выполнения этого, вероятно, будет минимально, и оно будет раздражать некоторых Ваших членов команды. Даже если это может быть сделано работать обоснованно хорошо, Вы все еще делаете оператор значения путем выполнения этого. Взвесьте снижение расходов против стоимости замены одного или нескольких Ваших ключевых сотрудников разработки.
Как со всеми вещами, ответ на Ваш вопрос является "Вашим Milage, Может Варьироваться" или YMMV. Это зависит от того, что делают разработчики. Они тратят большую часть своего написания кода времени, или они делают много больших компиляций? Им нужен прямой доступ к оборудованию?
Им нужна отладка прав? После того как Вы предоставляете им отлаживающий права, они в основном собственный машина и можете вмешаться в других пользователей.
Обычно намного лучше позволить пользователям разрабатывать на их собственных компьютерах и использовать VPN, чтобы позволить им получать доступ к системе управления версиями. Затем они могут контроль файлы к их локальным компьютерам и делают то, что они хотят, затем регистрация изменения.
Но, RDP имеет, это - преимущества также. Действительно необходимо взвесить pro's и недостатки и решить, какой список длиннее или более "тяжел".
То, что важно для рабочей станции разработки, является чистой вычислительной мощностью. В нашем месте у разработчиков есть большинство высокопроизводительных рабочих станций с точки зрения CPU, памяти, диска, и т.д. а не с точки зрения аудио и графики. Это - последние, которые больше всего затронуты RDP.
Пока сервер, к которому Вашими разработчиками является RDP-луг, достаточно быстр для обработки нескольких компиляций, сборки одновременно, необходимо быть в порядке.
Интересно, какова причина этого была бы. Центральный сервер (серверы) имеет доступ к некоторым ресурсам, к которым не могли получить доступ машины отдельного разработчика?
Я использую RDP для соединения с моего домашнего компьютера на мой рабочий компьютер время от времени. Я должен сказать - возможно кодировать, но это - путь, более удобный, чтобы сделать это, когда IDE находится на Вашей собственной машине. Даже когда на LAN на 100 Мбит существует некоторая значимая задержка. Недостаточно беспокоить работу, но раздражающий, тем не менее.
Если люди должны работать от удаленных мест регулярно, я предпочел бы установку, где центральное управление исходным кодом доступно через некоторый защищенный протокол (HTTPS, VPN, и т.д.), но разработка может произойти локально на машинах разработчика. При использовании чего-то как SVN, который работает хорошо даже с офлайновой разработкой, затем это должен быть путь, более удобный для самих программистов.
Я ежедневно использую RDP для разработки, я оставляю свой ноутбук на дома с моей рабочей средой открытым и готовым пойти. Когда я взялся за работу, и все загружают их проекты и открывают их программы I просто RDP в, и я готов пойти. Необходимо иметь в виду определенные сочетания клавиш, которые изменяются, хотя (CTRL+ALT+DEL, например), это является раздражающим сначала, но Вы привыкаете к нему.
Для сведения задержки к минимуму я рекомендую...
- выключая цвета к 256 (в конце концов, только необходимо видеть текст),
- Оставьте обои в другом компьютере
- Отпуск звучит в другом компьютере
- Оставьте любые темы на другом компьютере
- Выберите более низкую скорость соединения, даже если Ваш выше. Windows минимизирует отправленные данные.
Одним из преимуществ, которые Вы могли бы также рассмотреть, является вычислительная мощность. Если Ваша машина дома имеет намного лучшие спецификации, чем Ваша рабочая станция на задании, время компиляции улучшено немного. Так как Ваша локальная машина только должна обновить изображение от удаленной машины, Ваш локальный компьютер не является объектом загрузки.
Используя эту опцию также позволяет мне сохранять на ходу. В то время как другие входят в систему и просматривают Интернет и напрасно тратят время, я настраиваюсь и готов пойти. Быть более продуктивным помогает Вам платиться большие баксы (если Ваш работодатель замечает), в то время как другие все еще застревают в своих младших ролях программирования.
Пред2000 я делал это в течение 3 лет каждый день несколько часов в день. Это было, когда пропускная способность высосала также.
В наше время это намного намного лучше.
И если Вы используете жизнь NxMachine, становится еще лучше :)
Я, однако, не использовал машину с многочисленными пользователями. Мое беспокойство с этим было бы то, что разработчики являются привередливым набором (самостоятельно включенный), и мы склонны продвигать машины действительно трудно как есть.
Не может вообразить несколько человек на одном поле всем решением скомпилировать :)
G-человек
Я использовал его для работы из дома (удаленный вход в систему моего в офисе ПК через VPN).
Производительность зависит от Вашего ISPs, конечно.
Это немного менее надежно (потому что, а также то, что вы имели время простоя, когда/если когда-либо офис LAN снижается, существует теперь дополнительный риск времени простоя, в то время как любое из интернет-соединений снижается).
Я использую Удаленный рабочий стол для управления моей машиной Windows на работе. Я использую Параллели, которые VM на Mac и моем соединении 2.5M вниз, 256k.
Это работает действительно действительно хорошо. Я делал это в течение 2 лет в течение 1-3 дней в неделю. Медленный upspeed не является проблемой - я не могу ввести это быстро.
Я имею 3 экрана на работе, но все еще нахожу, что 20-дюймовый экран Mac выше. Цвета являются намного более чистыми, и я могу работать дольше в Mac, чем мои экраны работы!
Вещью, которая является уничтожителем, является Flash на браузере. Если я случайно открываю браузер на своей удаленной машине с Flash, это уничтожает соединение. Решение состоит в том, чтобы использовать FlashBlock (дополнение Firefox).
Я использую Eclipse и Visual Studio без проблем вообще.
Я использовал и VNC и RDP по соединению DSL, пробегая туннель SSH, и не имел никаких реальных проблем.
Существуют определенно некоторые задержки, особенно при перерисовке значительных частей экрана. Но большая часть разработки включает маленькие редактирования и оба из этих протоколов дескриптор это очень хорошо.
Я работал в среде, где мы иногда редактировали бы некоторый существующий код через удаленный рабочий стол. Не было никаких значительных вызовов этому. Как разработчик я положительно очень не хотел делать ту работу. Все чувствовавшее себя, медленное и безразличное. Однако мы сделали работу.
К счастью они часто были заданиями коротких 3-4 часов..., главным образом прикрепляет к существующим системам на удаленных сайтах для клиентов. Я не думаю, что мог рекомендовать это как нормальный способ сделать работу, но ее, конечно, возможный.
Если Вы не будете волноваться по поводу задержки на аудио и стремительном формировании изображений, и Вы не разрабатываете ничего зависящего от 3D аппаратных средств, то Вы, вероятно, будете в порядке.
Я никогда не использовал его в среде команды, но я использую свой ноутбук RDP'd в мою рабочую станцию весь день и люблю его.
Мы соединяемся с нашими средами разработки с помощью RDP, и локально производительность является большой. Это замедляется немногим выше VPN, но является все еще приемлемо быстро реагирующим.
Выключите всю функциональность анимации окон, настольный фон, и т.д. и это значительно поможет.
У меня есть удаленный сервер на 1 Мбит/с, в восходящем направлении передают по каналу, который я RDP к (по VPN) и он работает просто великолепно. Я даже использую разрешения с большим экраном (1600x1200) без проблем производительности. Конечно, я не уверен, как такая установка тарифицировала бы для нескольких параллельных пользователей, как бы то ни было.
Преимущество разработки по RDP, который я не ожидал, - то, что можно сохранить сессии - поэтому после того, как Вы получаете сделанную разработку в течение дня, Вы выходите из своего клиента RDP и выключаете Ваш компьютер, и когда Вы входите в следующий день свою сессию, является правильным, где Вы оставили его.
Как добавленная премия, клиенты RDP доступны для Linux и OS X.