Myśli na temat programowania przy użyciu maszyn wirtualnych [zamknięte]

Będę pracował jako lider programistyczny dla startupu i zasugerowałem, abyśmy używali maszyn wirtualnych do programowania. Nie mówię o tym, że każdy programista ma komputer stacjonarny z maszynami wirtualnymi do testowania / programowania, mam na myśli szafę serwerową, w której wszystkie maszyny wirtualne są zarządzane, a programiści pracują z microPC (ktoś z ChromeOS?) Lokalnie, a nawet zdalnie z domu komputer.

Dla mnie korzyściami jest to, że jest niezwykle skalowalny, tańszy na dłuższą metę, łatwiejszy w zarządzaniu i że wykorzystujemy sprzęt o jego maksymalnym potencjale. Jeśli chodzi o wady, nie mogę wymyślić żadnego konkretnego showstoppera, poza tym, że potrzebujemy kogoś do skonfigurowania / utrzymania wspomnianej konfiguracji.

Miałem nadzieję, że niektórzy z was mogliby mieć podobną konfigurację w miejscu zatrudnienia i być w stanie pochwalić się swoimi opiniami. Dzięki.

Co chcesz zaoszczędzić jako ułamek budżetu na rozwój? Wydaje mi się, że martwisz się o epsilon. Koszt maszyn dla programistów wynosi mniej niż 5% całkowitego kosztu utrzymania programisty wśród personelu. Dlatego jedynym ważnym pytaniem jest: „czy zaoszczędzi to czas programistom?” Może, jeśli nie będą musieli tracić czasu na instalowanie i aktualizowanie oprogramowania programistycznego. Lub może to kosztować czas, jeśli sieć przestanie działać, serwer przestanie działać, lub, najprawdopodobniej, jeśli brak reakcji w sieci. Współczesny rozwój zależy od interakcji klawiszy po klawiaturze z IDE lub co najmniej bardzo inteligentnym edytorem. Opóźnianie tej interakcji nawet o kilkadziesiąt milisekund niszczy produktywność programistów. Programiści muszą nauczyć się tego nowego sposobu pracy.

Nie są to zastrzeżenia do maszyn wirtualnych, ale potencjalne zastrzeżenia do zdalnego programowania.

Myślę, że zachowujesz się jak grosz i jesteś głupi.

Przede wszystkim koszty maszyn są trywialne w porównaniu z kosztami programisty. Powinieneś pracować nad maksymalizacją wydajności, a nie minimalizacją kosztów maszyny.

Po drugie, opóźnienie (nie przepustowość) jest kluczem do wielu zadań programistycznych - zwłaszcza edycji tekstu. Za każdego dolara / funta / euro, które zaoszczędzisz na maszynach dla programistów, wydasz co najmniej dziesięć na modernizacje sieci, aby utrzymać nawet pozór wydajności - i nawet wtedy byłyby one bardziej produktywne, gdybyś oszczędzał na dostarczaniu je z Pentium III, które znalazłeś gdzieś w śmietniku.

Sądzę również, że istotną korzyścią jest to, że programiści używają środowiska przynajmniej rozsądnie zbliżonego do oczekiwanego przez docelowego użytkownika końcowego. Niezależnie od oficjalnych celów wydajności w specyfikacji i większość programistów opiera się dość mocno na tym, jak „czuje się” kod, gdy go testuje. Kiedy korzystają z zupełnie innego środowiska niż użytkownik końcowy, prawdopodobnie tracą czas na trywialności, całkowicie ignorując poważne problemy.

Z punktu widzenia wsparcia brzmi to tak atrakcyjnie, jak jednorodne środowisko, i ogólnie rzecz biorąc, powinieneś ogólnie zachęcać do jak największej różnorodności w maszynach programistów. Programiści i tak rzadko potrzebują dużo wsparcia, a wiedza o tym, kiedy masz kod, który zawiedzie z innym układem graficznym, procesorem, kartą sieciową itp., To więcej niż spłata minimalnej inwestycji.

Konkluzja: jeśli piszesz kod, który jest przeznaczony (przynajmniej przede wszystkim) do użycia w zwirtualizowanym środowisku serwerowym, prawie musisz podać go swoim programistom. Jeśli i tak robisz to w celu testowania, może to (ale niekoniecznie) mieć sens również dla rozwoju. Podobnie, jeśli trzeba (lub przynajmniej mieć) poważnie nad-speced serwer i sieć tak, to może mieć sens, aby wykorzystać, że za pomocą tego, co masz już dostępny.

Jednak w najbardziej typowych okolicznościach wydaje mi się, że może to wprowadzić więcej problemów niż rozwiązuje.

To był jeden z moich pomysłów w przeszłości: posiadanie wysokowydajnego serwera, który ma całe wymagane oprogramowanie, oraz kilka mało wydajnych komputerów stacjonarnych, które byłyby używane tylko do łączenia się z serwerem za pośrednictwem Pulpitu zdalnego.

Korzyści byłyby następujące:

• Solidna kopia zapasowa. Niektórzy programiści mogą nie chcieć regularnie wykonywać kopii zapasowych swoich komputerów stacjonarnych, więc centralne rozwiązanie byłoby bardziej niezawodne,
• Możliwość, dla każdego programisty, pracy z dowolnego miejsca. Rozumiem przez to także pracę z dowolnego komputera w firmie. Powiedzmy, że rano deweloper chce cichych warunków pracy. Idzie do swojego pokoju i tam pracuje. Potem chce zrobić parę programowania lub pracować w bardziej społecznym środowisku. Po prostu wyłącza komputer stacjonarny, idzie do innego pokoju, w którym jest dziesięć komputerów, i łączy się z nim. Nie „Muszę ponownie załadować wszystkie moje aplikacje”.

Cóż, jest z tym kilka poważnych problemów, co sprawia, że ​​myślę, że nigdy nie będę używać takich rzeczy przez następne lata.

• Specyfika rozwiązań zdalnych. Co powiesz na pracę na odległość przy użyciu kilku ekranów jednocześnie? Mam na myśli, czy to łatwe? Czy to oczywiste? Czy skróty, których używam codziennie, są włączone, gdy pracuję na odległość? Nie jestem tego taki pewien. Co się stanie, jeśli naciskam Ctrl + Shift + Esc, aby zobaczyć listę aktualnie uruchomionych programów? O tak, to nie działa, więc teraz muszę pamiętać, że robiłem to w inny sposób.

• Hit wydajności. Nie jestem pewien, czy w ogóle nastąpi spadek wydajności. I pamiętaj, że programista korzystający z wolnego komputera jest niezadowolonym programistą. A firma, która sprawia, że ​​programiści są niezadowoleni z kiepskich warunków, nigdy nie będzie produkować oprogramowania wysokiej jakości.

• Większy wpływ katastrofy. Czy umieścisz rozwiązanie na nadmiarowym serwerze? Czy masz w swojej firmie nadmiarową sieć? Powiedzmy, że router przestaje działać i nie jest zbędny. Oznacza to, że wszyscy programiści nie mogą teraz pracować. W ogóle. Ponieważ nie mają oprogramowania zainstalowanego lokalnie. Ponieważ nawet nie mają kodu źródłowego: jest na serwerze. Więc wszyscy się zatrzymują, a płacisz wszystkim tym osobom za godzinę, tylko po to, by poczekać na wymianę routera.

• Koszty sprzętu Jeśli jest to jedyny serwer, ile to będzie kosztowało? Jeśli masz, powiedzmy, dwudziestu programistów, czy 64 GB pamięci RAM na serwerze wystarczy? Nie tak pewny. Czy wystarczy czterordzeniowe rozwiązanie z dwoma procesorami? Znów mam pewne wątpliwości. W przeciwnym razie o czym myślisz? Jakaś chmura? A może masz skalowalne rozwiązanie, które działa na kilku serwerach? Czy jesteś gotów zapłacić koszt systemu Windows Server (jeśli korzystasz z systemu Windows) za komputer?

• Koszt energii elektrycznej. Jeśli pracujesz całkowicie zdalnie, oznacza to, że spędzasz prawie taką samą ilość energii po stronie serwera, jak podczas pracy lokalnej, plus ilość energii zmarnowanej przez lokalną maszynę i sieć.

• Licencje Nie jestem pewien, czy muszę to potraktować jako korzyść czy problem, ale wydaje mi się, że koszt licencji na oprogramowanie w tym przypadku będzie znacznie wyższy.

I jeszcze raz pomyśl o wszystkich kosztach zarządzania, wsparcia, wdrożenia i konserwacji. Dzięki takiemu niestandardowemu rozwiązaniu może łatwo stać się ogromne, nie licząc, że za każdym razem, gdy coś zawiedzie, zobaczysz, że każdy programista NOP kręci się wokół, czekając, aby móc kontynuować swoją pracę.

Używamy instancji Amazon EC2 na żądanie jako maszyn deweloperskich. Nie ma to nic wspólnego z kosztami. Mamy „pulę programistów” pracujących nad kilkoma projektami i potrzebujemy zdolności szybkiego przemieszczania się między projektami.

Ogólnie rzecz biorąc, maszyna wirtualna oszczędza czas początkowej konfiguracji. Ale w dłuższej perspektywie marnuje czas z powodu utraty wydajności. Koszt jest nieosiowy, ponieważ koszt programisty to znacznie więcej niż koszt maszyny.

Koszty produktywności obejmują - czas potrzebny na uruchomienie obrazu maszyny wirtualnej (kilka minut), słabą szybkość reakcji oraz ograniczenia zasobów / pamięci. Początkowo nie jest to wiele, ale z czasem stają się denerwujące.

W jednym z naszych projektów zmieniliśmy kod, aby uprościć wstępną konfigurację w celu „pobierania kodu i uruchamiania maven”. Dzięki tej zmianie nowy programista mógł łatwo rozpocząć pracę nad projektem - a teraz nikt nie korzysta z obrazu VM Amazon. Chcemy to naśladować również w innych projektach, ale zajmie to trochę czasu. Do tego czasu mamy nasze obrazy ec2.

Bądź BARDZO ostrożny tutaj. Niedawno zostałem wdrożony u klienta, w którym wszyscy w dziale IT mieli swoją maszynę wirtualną zasadniczo z tego samego powodu - aby umożliwić im posiadanie niższych komputerów PC na biurku, a następnie zdalne sterowanie maszyną wirtualną i wykonywanie swojej normalnej pracy.

Doświadczenie nie było ładne. Przynajmniej raz w tygodniu działaliśmy bardzo wolno z różnych powodów. Zasadniczo mogliśmy stwierdzić, kiedy ktoś w zespole korzystał z zestawu pakietów SSIS intensywnie wykorzystujących procesor. W końcu przenieśli kilku z nas na różne serwery, co pomogło niektórym, ale wydajność nigdy nie była odpowiednia.

Myślę, że jeśli masz zamiar to zrobić - dołóż należytej staranności do mocy serwera, potrzeb w zakresie przetwarzania, liczby maszyn, które zamierzasz obsługiwać itp. Może to zaoszczędzić trochę pieniędzy, ale jeśli nie zostanie poprawnie zaimplementowane, może spowodować DUŻO bólów głowy.

Uwaga: to NIE jest płomień architektury VM - tylko ostrzeżenie dla ludzi, którzy się w nią zaglądają - upewnij się, że masz kaczki w rzędzie przed wdrożeniem.

Programowanie na maszynach wirtualnych może działać całkiem nieźle, ale tylko pod warunkiem prawidłowego wykonania:

• To, że używanie maszyn wirtualnych pozwala mieć jeden komputer dla całego zespołu zamiast jednego na programistę, nie oznacza, że ​​jest to dobry pomysł
• Ponowne uruchomienie nie powinno wymagać otwarcia zgłoszenia do pomocy technicznej z 24-godzinnym czasem reakcji
• Maszyny wirtualne programowania nie powinny znajdować się w centrum danych 5000 mil od programistów.
• Chociaż maszynami wirtualnymi mogą zarządzać programiści i dlatego nie są one obsługiwane, nie oznacza to, że nie powinni oni mieć dostępu do usług sieciowych, takich jak kontrola źródła.
• Połączenie ze zdalnym pulpitem powinno być standardowe, a nie niestandardowy aplet „wysokiego bezpieczeństwa”, który konwertuje wszelkie cytaty wpisane w umlaut.
• Uzyskanie nowej maszyny wirtualnej lub przebudowanie istniejącej powinno zająć minuty, a nie tygodnie

Widziałem wszystkie te problemy i nie bardzo lubię z nimi pracować. Jednak mam również konfigurację maszyny wirtualnej w domu, której używam z wyboru. Działa to szybciej niż instalacja lokalna i pozwala na takie rzeczy jak oddzielne środowiska dla różnych projektów i szybkie przebudowy, gdy środowisko staje się niestabilne.

Pracuję z maszynami wirtualnymi, ale nie polecam tego do twojego głównego projektu.

Powodem, dla którego używam maszyn wirtualnych do programowania, jest to, że muszę obsługiwać starsze projekty (np. VB6, .NET 1.1 itp.) I nie chcę brudzić mojego głównego komputera przez instalację VS2003 / 2005 / vb6 / etc ... Wszystko działa dobrze, ale tu i tam pojawiają się sporadyczne problemy.

Ponadto interakcja jest wolniejsza, maszyny wirtualne potrzebują czasu na uruchomienie / zamknięcie, nie mają natywnych efektów interfejsu użytkownika (takich jak Aero w Win7) itp.

Cokolwiek zaoszczędzisz pod względem pieniędzy, które zmarnujesz, a więcej kłopotów, które zamierzasz nałożyć na swój zespół. Plus, jak ktoś tu wspomniał, brak obsługi wielu ekranów. Potrzebuję co najmniej 3 ekranów, aby uzyskać jak największą produktywność.

Zasadą rozwoju nr 1 jest zadowolenie programistów. Przekonasz się, że jest to prawie niemożliwe w przypadku zdalnych maszyn wirtualnych. Obsługa wielu monitorów jest nierówna, opóźnienia sieci i zakłócenia są kłopotliwe, a oszczędności kosztów są na ogół minimalne.

Oczywiście, pracuj na maszynach wirtualnych, ale zezwól także na lokalne maszyny wirtualne i spraw, by komputer fizyczny był także absurdalnie szybką bestią.

Telepracuję w 100%, a między moim osobistym usługodawcą internetowym a VPN - pomimo wysokiej niezawodności - mają wystarczającą liczbę blipów, które doprowadzą mnie do szału, jeśli nie będę mógł pracować w trybie offline.

Generalnie po prostu rozbijam różne obrazy VirtualBox i pracuję na ich podstawie. Kopiowanie kilkuset MB przewodowo nie jest zbyt czasochłonne, jeśli potrzebujesz lokalnie nowego.

Mój zespół pomyślnie wdrożył konfigurację „powolnego serwera PC / Fast VM”. Dla zespołu 20 programistów mieliśmy 8-procesorowy serwer RAM 256 GB podłączony światłowodem do bardzo szybkiej sieci SAN. Było to drogie, ale tańsze niż zapewnienie każdemu deweloperowi stacji roboczej o podobnej wydajności. W przypadku niewielkiego zespołu (4 programistów) nie jestem pewien, czy korzyści skali przyniosą efekt i faktycznie coś was uratują.

Warto zwrócić uwagę na maszyny wirtualne do programowania, ale koszt finansowy jest niewłaściwym powodem.

Zostało to krótko omówione w Expert Marc. Holmes .NET Delivery przy użyciu NAnt & CruiseControl.net - w skrócie argumentem za rozwojem na maszynie wirtualnej jest to, że zniechęca ona do uzależnienia dowolnego aspektu pracy od konkretnej konfiguracji dewelopera. Rozpraszasz swoją maszynę wirtualną na początku każdego projektu i chyba, że ​​faktycznie potrzebujesz konkretnego narzędzia, nie będzie się ono kręciło. Minimalizuje to prawdopodobieństwo, że zmiany, które wprowadzisz, będą się odnosić na czyimś komputerze, oprócz twojego. Programiści mogą płakać z powodu zabrania zabawek - ale ostatecznie poleganie na narzędziach jest słabością i wszystko, czego nie można zrobić intuicyjnie w czystym otoczeniu, to zapach.

Zauważ, że niekoniecznie wierzę w argumenty przedstawione powyżej. Rozumiem i do pewnego stopnia się z nimi zgadzam, ale robię to dla argumentów, w celu wywołania dyskusji.

Potencjalne wady

• Jeśli host VM ulegnie awarii ... wszyscy jesteście wkurzeni. Jeśli kiedykolwiek miałeś zespół składający się z 20 osób, krzycz „GAH! HOST NOT RESPONDING !?” zgodnie… nie jest zabawnie.
• Jeśli zezwalasz na migawki ... szybko zjadają zasoby. 20 osób * 10–20 migawek zapewnia dużo miejsca na dysku twardym (lub przynajmniej tyle, aby zacząć powodować problemy).
• Jeśli wystąpią problemy z wykorzystaniem zasobów na hoście, ponownie wszyscy odczuwają ból.

IME, to dobre rozwiązanie i działa, ale potrzebujesz porządnego sprzętu na hoście, a gdy zdarzają się złe rzeczy, zdarzają się wszystkim.

To nie spełnia jednego z najważniejszych kryteriów testu Joela.

Upewniam się, że wszyscy moi programiści mają co najmniej i3 lub lepszy laptop lub komputer stacjonarny z taką ilością pamięci RAM, jaką może pomieścić.

Staram się o 8 GB.

Dzięki temu są bardziej produktywni i mogą faktycznie uruchamiać Virtual Box na swoich lokalnych komputerach w celu programowania i testowania, zamiast na kosztownych w utrzymaniu serwerach. Mogą wykonać migawkę instalacji Virtual Box, a także przetestować różne przeglądarki i instalatory, a wszystko w kilka sekund powróci do znanej dobrej konfiguracji bez konieczności kontaktowania się z usługami „IT”.

Programiści potrzebują najszybszych komputerów w firmie, z największą ilością pamięci RAM i uprawnień root na swoich komputerach lokalnych. Koniec opowieści.

Pracowałem wcześniej na maszynach wirtualnych do programowania, zarówno lokalnych maszyn wirtualnych (działających na lokalnym komputerze), jak i zdalnych. Lokalne były o wiele ładniejsze do pracy niż odległe.

Zdalne maszyny wirtualne, z którymi łączyliśmy się za pomocą protokołu RDP, miały niewielkie opóźnienie między każdym naciśnięciem klawisza i akcją. W takich warunkach można się rozwijać przez krótki czas, ale z dnia na dzień stało się to bardzo frustrujące.

Z radością rozwijałem się na lokalnej maszynie wirtualnej na VMWare, ponieważ musiałem uruchamiać Flash Builder na maszynie z Linuksem i byłem z tego zadowolony, o ile miał wystarczającą ilość pamięci - był całkiem użyteczny.

Robimy to dla naszych zdalnych maszyn i działa całkiem dobrze. Najrzadziej pracują z domu (zwykle tylko w celu naprawy awaryjnej tu i tam), więc po prostu używamy dość niskich netbooków, przeniesionych do naszych szybkich komputerów stacjonarnych w biurze. Są zdecydowanie wolniejsze (prawdopodobnie ograniczone przez sieć bardziej niż cokolwiek innego), ale od czasu do czasu działają na krótkie zadania. Nie byłoby to jednak do przyjęcia dla konia pracującego w pełnym wymiarze godzin, ponieważ VM często powoduje opóźnienia, które nawet przy najlepszym sprzęcie, IMHO, są nieco rozpraszające.

W mojej ostatniej pracy zrobiliśmy dokładnie to:

Użyliśmy Windows Terminal Server, na którym każdy programista miał konto. Deweloperzy nadal mieli zwykłe komputery PC (ponieważ już tam były), ale komputery PC obsługiwały tylko klienta RDP.

Zajęliśmy się tworzeniem oprogramowania Java, więc oprogramowanie wykorzystywało kompilator Java + IDE (głównie Eclipse), a także przeglądarkę internetową, narzędzia do zapytań DB, klienta kontroli wersji, a czasem także biuro sw (w naszym przypadku OpenOffice.org).

Nie napotkaliśmy żadnych prawdziwych problemów, a wydajność była całkiem przyzwoita.

Jedynym prawdziwym problemem było to, że naprawdę musisz uważać, aby nie zakłócać innym w niektórych sytuacjach, ponieważ dzielisz jeden system. Kiedy operacje IT wymagały wykonywania dużych kopii plików lub wykonywania kopii zapasowych na serwerze, wydajność spadła dla wszystkich. Kiedy to zidentyfikowaliśmy i rozwiązaliśmy (kopiując z niskim priorytetem lub z dnia na dzień), wszystko działało dobrze.

Dlatego zastrzeżeniem jest: Oceń wydajność tak szybko, jak to możliwe, i odpowiednio zaplanuj swój sprzęt i jego użycie.

TL; DR: Zrobiłem to przy wielu zadaniach i teraz wolę.

Koszt to zły powód, dla którego warto się skupić. Oto kilka lepszych.

Powody

• Spójność platformy w różnych środowiskach (programistycznych, testowych i produkcyjnych).
  • Dlaczego: Całkowicie eliminuje wektor wad, wady wynikające z różnic platform w różnych środowiskach.
• Umożliwia zmiany systemowe, takie jak uaktualnienia, najpierw w vms programistycznych, być weryfikowane, testować, testować, wdrażać do produkcji; wszystko znacznie łatwiejsze dzięki rozwojowi (i testowaniu) vms.
  • Dlaczego: Kontrola. Mogę robić migawki, wycofywać, identyfikować delty, wprowadzać zmiany na jednym serwerze i propagować sukces, po prostu kopiując vm itp.
• Czasami systemy, na których się rozwijasz, są dostępne tylko w zabezpieczonej sieci. Alternatywnie serwer, na którym będzie działać twoje oprogramowanie, może mieć ograniczony dostęp lub inne cechy sieci.
  • Powód: VM programistyczna może znajdować się w sieci VLAN, która ma dostęp do zablokowanego systemu lub usługi. Alternatywnie, jeśli serwer deweloperski ma taki sam ograniczony dostęp jak serwer testowy i produkcyjny, nigdy nie będzie mowy o przypadkowym zakodowaniu wymagań dotyczących charakterystyki sieci lub dostępu, który nie będzie dostępny.

Wyzwania

Największym wyzwaniem jest zdalny rozwój, szczególnie jeśli musisz przejść przez bramę lub serwer przeskoku. Utrudnia to, zwłaszcza jeśli programiści nie są dobrze zaokrągleni (posiadają pewną wiedzę z zakresu inżynierii systemów, znajomość sieci itp.).

Istnieje wiele odmian zdalnego programowania, ale zwykle sprowadzają się one do 2 głównych różnic.

• Uruchom narzędzia programistyczne w zdalnym środowisku i korzystaj z protokołów, takich jak klienci RDP, zdalni klienci X11 itp.
• Uruchom narzędzia programistyczne lokalnie i użyj protokołów, aby transparentnie synchronizować lub uruchamiać się na zdalnym serwerze, często używając ssh jako warstwy transportowej.

Przybory

Istnieją narzędzia, które pomogą w zdalnym rozwoju, i istnieją środowiska IDE, które to ułatwiają. Będziesz musiał zbadać, w jakim stopniu jest on zdolny do zdalnego programowania, wiele z nich nie jest uruchomionych na tym samym serwerze, na którym opracowywany jest kod. Istnieją jednak inne narzędzia.

• Bezpieczna powłoka: najbardziej udane konfiguracje zdalnego programowania używają ssh w większym stopniu, używając loginów bez hasła (przy użyciu uwierzytelniania klucza), przezroczystych multi-hopów (rozwiązuje problem z serwerem skoku) i innych opcji konfiguracyjnych, aby skrócić czas odpowiedzi. Uwaga: zawsze miałem problemy z korzystaniem z implementacji SSH innych niż OpenSSH.
• GNU Screen / TMUX: Multipleksery terminali. Screen jest ich dziadkiem i wciąż ma się dobrze, ale myślę, że większość ludzi zaczęła przełączać się (lub nawet uruchamiać) na TMUX.
• Vim / Emacs : Stara gwardia, ale oba działają świetnie na zdalny rozwój na różne sposoby. To Vim, więc wszystko czego potrzebuje to powłoka, podczas gdy Emacs może działać lokalnie i używać TRAMP do zdalnego programowania.

Z nieco innej zasady - czy przekazałeś swoim menedżerom / księgowym arkusz kalkulacyjny podkreślający koszty korzystania z tych powolnych maszyn? Wskaż im, że rozwiązanie VM (o ile nie zostanie wykonane właściwie, a to nie jest łatwe) może po prostu umieścić programistów, a tym samym firmę, na tej samej łodzi.

Będzie to zależeć od tego, ile masz mocy administracyjnej w stosunku do instalacji VMware, jeśli zostaniesz umieszczony w puli o niskim priorytecie, będziesz mieć wolne maszyny w zależności od aktywności innych pul.

Sprzęt jest tani, programiści są kosztowni.

Dlaczego chcesz, aby programiści byli sfrustrowani, dając im maszyny do powolnego programowania? Koszt aktualizacji bladego sprzętu w porównaniu do korzyści, jakie zyskają.

Zapytaj o lepsze maszyny. Przynajmniej poproś o RAM 4 GB. Dodanie kolejnego tabletu 2 GB zostanie zwrócone za niecały tydzień.

Brak obsługi podwójnego ekranu zawsze zabijał. Po prostu nie wyobrażam sobie wykonywania znaczących prac rozwojowych na jednym ekranie.

Teraz robią rocka do testowania / wdrażania / majstrowania, więc nie sądzę, że powinni też spaść ze stosu.

Jeśli masz komputer mainframe z 50 dyskami SSD w macierzy RAID10 i używasz tylko 3-4 komputerów na tym komputerze, to może działać.

W przeciwnym razie są opóźnione, naprawdę opóźnione (chociaż w niektórych rzadkich przypadkach migawki mogą to zrównoważyć).

Mam w biurze przyzwoitą maszynę stacjonarną, do której mogę się podłączyć z laptopa za pośrednictwem VPN za pomocą udostępniania ekranu.

Działa w przypadku incydentów związanych z obsługą poza godzinami pracy oraz sporadycznych przymusowych zdalnych działań. Jest to z pewnością lepsze niż utrzymywanie w pełni skonfigurowanego środowiska na drugim komputerze lub opracowywanie rzeczy wymagających małego opóźnienia w centrum danych w sieci WAN.

Praca w ten sposób przez długi czas jest frustrująca. Czasami wjechałem do pracy przez drugą połowę dnia, kiedy wszystko, co trzymało mnie w domu, zostało usunięte.

Opóźnienie i nieruchomości ekranowe są dla mnie dwoma zabójcami.

Nie sądzę, że chcesz korzystać ze zdalnego rozwiązania VM. Połączenie sieciowe będzie wąskim gardłem, a nawet w przypadku szybkiego połączenia może wystarczyć do spowodowania frustracji. Odchodzimy od tej techniki do korzystania z lokalnych środowisk programistycznych.

Tworzymy na iMacach, co jest naprawdę fajne, ale nasze aplikacje internetowe działają w środowisku Linux w środowisku produkcyjnym. Problem polega na tym, że ostatecznie możemy napotkać problem, który występuje tylko w systemie Linux i może być trudny do rozwiązania. W tym tkwi moc maszyn wirtualnych. Jednak nawet nie podoba mi się pomysł używania maszyny wirtualnej w 100% przypadków.

Niedawno dowiedziałem się o Vagrant (http://vagrantup.com/docs/getting-started/why.html) i szefie kuchni za ułatwienie pracy z VirtualBox. Vagrant daje możliwość łatwego uruchomienia maszyny wirtualnej, gdy jej potrzebujesz, i zburzenia maszyny wirtualnej, gdy jej nie potrzebujesz. Więc mogłem cały swój rozwój przy użyciu komputera Mac. Następnie, gdy jestem gotowy do przetestowania mojego kodu, mogę uruchomić maszynę wirtualną, aby go przetestować i utrzymywać go tak długo, jak go potrzebuję. Vagrant daje również możliwość łatwego udostępniania maszyn wirtualnych współpracownikom, dzięki czemu wszyscy mogą być pewni, że pracujesz w tym samym środowisku.

Polecam sprawdzenie Vagrant, abyś był przynajmniej świadomy dostępnych opcji, jeśli chodzi o programowanie i pracę z maszynami wirtualnymi.

Pracowałem nad starszym projektem dotyczącym 5 maszyn, z których każda ma rolę w potoku obliczeniowym (maszyna 1 wysyła żądanie do maszyny 2, a ta z kolei wysyła żądanie do maszyny 3 itp.). Wdrożenie ustawień na maszynie wirtualnej pozwoliło nam OGROMNIE zaoszczędzić czas: 1. System był niemożliwy do uruchomienia, ponieważ deweloperzy byli leniwi / nie mieli czasu na włączenie testów w projekcie. 2. Wdrożono zbyt wiele ustawień i musiałem poświęcić czas na ich układanie w grupy.

Teraz używam go, ponieważ pracuję nad zbyt wieloma projektami jednocześnie. Główny problem, który mam teraz, to: 1. Maszyny wirtualne zużywają zdecydowanie za dużo czasu na utrzymanie. 2. Maszyny wirtualne zużywają ogromne ilości pamięci do działania

Ten rodzaj sprawia, że ​​maszyny wirtualne są trudne w użyciu, gdy próbujesz ich użyć, aby uzyskać porządek. Zachowaj jedną główną maszynę z e-mailem i tekstem, rozwijaj się na dedykowanych maszynach wirtualnych. Utrzymuje porządek i czystość życia kosztem.

Jak twierdzą inni, tak naprawdę zależy to od problemu, który próbujesz rozwiązać za pomocą komputerów stacjonarnych VM, a następnie rozważenia korzyści wynikających z rozwiązania tego problemu w stosunku do wad środowiska VM.

Zmierzamy w kierunku środowiska hybrydowego, w którym wszyscy nasi programiści onshore będą mieli tradycyjne maszyny fizyczne, ale programiści offshore (obecnie współpracujący z małą firmą outsourcingową) będą korzystać z wirtualnych pulpitów. Problemy, które próbujemy rozwiązać za pomocą zdalnych komputerów, są związane z bezpieczeństwem i wydajnością. Środowisko wirtualne zapewni nam oczywiście większą kontrolę z punktu widzenia bezpieczeństwa, a dla wydajności będziemy przesyłać tylko „zmienione piksele” zamiast pełnego kodu źródłowego i będziemy musieli wdrożyć serwery proxy i tym podobne.

Nadal nie jestem pewien, czy to właściwy sposób, ale właśnie tam zmierzamy.