Przenośne środowisko programistyczne — Git, NPM, Grunt i Edytor (uniwersalne IDE)

Gdy skaczemy z komputera na komputer i na każdym chcielibyśmy móc pracować równie sprawnie i wydajnie bez zmiany przyzwyczajeń. Do tego również bez konieczności instalacji za każdym razem potrzebnych programów które większość jak nie wszyscy programiści używają, trzeba pomyśleć właśnie o stworzeniu takiego przenośnego środowiska pracy.

Nie ma znaczenia jakie są powody dla których potrzebujemy takiego tworu. Czy zmusza nas sytuacja lub zwyczajnie przydatne jest dla nas mieć pod ręką, np. na pendrive lub na dysku zewnętrznym gotowe do pracy środowisko developerskie. Problem jakoś trzeba rozwiązać w sposób elegancki i praktyczny, do tego bez zmiany przyzwyczajeń i niepotrzebnych frustracji i nerwów występujących podczas pracy na takim "czymś".

Żale autora ...

W moim przypadku zmusiła mnie sytuacja, padł mój główny komputer i niestety naprawa nie jest opłacalna. Zastępczego za bardzo niestety nie posiadam, a na coś nowego chwilowo brak środków. Jedyne co posiadam to dostęp do 2 komputerów względnie wydajnych, a przynajmniej nadających się do pracy lecz niestety z których korzystają inne osoby. Tym sposobem mogę ich używać gdy są nieużywane. Jest jeszcze jeden komputer, praktycznie nieużywany. Niestety jest nieużywany nie bez powodu, powodem jest wiek tego laptopa. Jest on bardzo stary i ledwo nadaje się do "internetu". Jednak jak się nie ma co się lubi to się lubi co się ma ;), w końcu do pisania kodu nie potrzeba nie wiadomo jak wydajnej maszyny. Niestety nie wszystko jestem w stanie wykonać na tak starym i słabym komputerze stąd potrzeba możliwości przesiadki z całą pracą na inną maszynę bez żadnych zgrzytów i problemów. Nie chciałem również instalować potrzebnych programów na każdym komputerze bo zwyczajnie uważam że jest to niepotrzebne zaśmiecanie komputera na którym domyślnie pracuje ktoś inny. Jednak głównym powodem jest problem z synchronizowaniem ustawień środowiska developerskiego pomiędzy komputerami, a ponieważ i tak muszę biegać z dyskiem na którym mam dane projektów pomiędzy komputerami mogę na nim też przenieść potrzebne mi programy ;).

Wymagania i założenia

Założenia są takie by stworzyć środowisko developerskie składające się z potrzebnych narzędzi do pracy nad projektami które będzie można przenieść na zewnętrznym nośniku pamięci i uruchomić na je na dowolnym komputerze pracującym pod kontrolą systemu Windows. Narzędzia jakie potrzebuje praktycznie każdy programista to Git i jakiś dobry edytor kodu z podpowiadaniem składni. Do pracy nad projektami webowymi będą potrzebne dodatkowo jeszcze NPM i Grunt. Ponieważ zależy nam też na ergonomii pracy ważne będzie to by w jednym oknie konsoli był dostęp do wszystkich narzędzi czyli: git'a, npm i grunt'a. Ważne jest też by całość łatwo uruchomić bez potrzeby ciągłej konfiguracji i powtarzania jakichkolwiek czynności w momencie startu.

Struktura plików

Wszystkie narzędzia chcę mieć na zewnętrznym dysku. Dla utrzymania porządku wszystkie pliki środowiska developerskiego będą trzymane w specjalnym folderze o nazwie Portable. Ponieważ liczy się wygoda to bezpośrednio w tym katalogu musi być możliwość uruchomienia naszego środowiska. W kolejnych katalogach będą pliki poszczególnych narzędzi. Wszystkie operacje jakie będą wykonywane będą wykonywane w odniesieniu właśnie do naszego najważniejszego katalogu Portable.

Git

Dodanie Git'a do przenośnego środowiska jest praktycznie bezproblemowe ponieważ jest on oficjalnie dostępny w wersji portable. W teorii wystarczyłoby go pobrać, wypakować pliki i używać. Niestety jeśli chcemy mieć możliwość przenoszenia Git'a pomiędzy systemami 32 bitowymi a 64 bitowymi nie wystarczy zaopatrzyć się tylko w wersję 32‑bitową. No chyba że zadowala nas używanie Git'a z poziomu Windowsowego wiersza poleceń czyli CMD, jeśli tak i rezygnujemy z alternatywnej konsoli i emulowanej powłoki Bash którą zapewnia MinGW to nie mamy żadnego problemu. Niestety ja za CMD nie przepadam i dużo bardziej wolę linuksową konsolę, nie tylko ze względu na lepszą czytelność, ale chyba też to że dużo lepiej znam Bash'a niż CMD czy PowerShell od Microsoftu. Jeśli tak jak ja też wolisz używać Bash'a i nie chcesz zobaczyć takiego okienka jak ja przy pierwszych próbach stworzenia tego środowiska podczas gdy uruchamiałem Git'a w wersji dla systemów 32 bitowych na systemie 64 bitowym to niestety trzeba trochę pokombinować.

Pobieramy pliki Git'a

Wchodzimy na stronę główną git-scm.com, następnie przechodzimy na podstronę pobierania i wybieramy wersję dla systemu Windows. Spośród dostępnych opcji downloadu interesować nas będą przenośne wersje Git'a. Będziemy potrzebowali zarówno wersji dla systemu 32 bitowego oraz 64 bitowego.

Pobieramy obie i zapisujemy na dysku.

Wypakowujemy pobrane pliki

W naszym katalogu Portable tworzymy katalog GitPortable, a w nim dwa kolejne 32-bit i 64-bit. Do nich wypakowujemy pliki poszczególnych wersji Git'a. Wersję dla systemu 64 bitowego najlepiej wypakować na tej właśnie wersji systemu.

Po tym etapie powinniśmy mieć następującą strukturę katalogów:

Uruchamianie Git'a

W naszym głównym katalogu Portable tworzymy plik git-bash.cmd ze skryptem do uruchamiania odpowiedniej wersji Git'a.

SET git-dir=%~dp0%GitPortable\

if %PROCESSOR_ARCHITECTURE% == x86 (
	SET git-dir=%git-dir%32-bit\
) else (
	SET git-dir=%git-dir%64-bit\
)

START %git-dir%git-bash.exe

Słowem wyjaśnienia ważniejszych rzeczy:

[list] [item]zmienna %~dp0% przechowuje lokalizację z której uruchomiony został nasz skrypt. Jest to dla nas ścieżka relatywna do uruchomienia wszystkich programów. Nie możemy podać stałej ścieżki ponieważ nasz dysk lub pendrive na różnych komputerach może mieć inną literę przydzieloną przez system, a to by uniemożliwiło uruchamianie aplikacji[/item][item]Jedyna instrukcja warunkowa

if %PROCESSOR_ARCHITECTURE% == x86 (
	SET git-dir=%git-dir%32-bit\
) else (
	SET git-dir=%git-dir%64-bit\
)

odpowiada za wykrycie z jaką wersją systemu mamy do czynienia i zbudowanie ścieżki do odpowiedniej wersji Git'a[/item][item]ostatnia linijka odpowiada za uruchomienie interesującej nas aplikacji[/item][/list]

Oczywiście jeśli preferujemy pracę z CMD możemy to osiągnąć w bardzo prosty sposób poprzez edycję ostatniej linii skryptu na:

START %git-dir%git-cmd.exe

Przydatne może być też stworzenie kolejnego skryptu do uruchamiania Git'a z GUI, wystarczy utworzyć nowy plik git-gui.cmd z lekko zmodyfikowanym naszym skryptem:

SET git-dir=%~dp0%GitPortable\

if %PROCESSOR_ARCHITECTURE% == x86 (
	SET git-dir=%git-dir%32-bit\
) else (
	SET git-dir=%git-dir%64-bit\
)

START %git-dir%cmd/git-gui.exe

NPM

Ponieważ NPM jest dystrybuowane wraz z Node.js musimy pobrać właśnie Node'a. Na szczęście tutaj sprawa jest dość prosta i możemy pobrać tylko wersję przeznaczoną na systemy 32 bitowe, również i w tym przypadku mamy oficjalną wersję portable.

Pobieranie plików Node

Udajemy się na oficjalną stronę projektu nodejs.org i przechodzimy do sekcji download. Tutaj proponuję pobrać ostatnią wersję ponieważ będziemy używać go jako narzędzia, a nie środowiska programistycznego dla aplikacji. Oczywiście pobieramy skompresowaną wersję binarną, ja pobieram tylko wersję dla systemu 32 bitowego.

Wypakowujemy pobrane pliki

Jak w przypadku Git'a tak i tym razem w naszym katalogu Portable tworzymy katalog Node.js i do niego wypakowujemy pliki Node'a.

Teraz struktura naszych katalogów prezentuje się jak poniżej, należy jednak pamiętać iż w naszym katalogu głównym Portable mamy jeszcze skrypty uruchomieniowe, w moim przypadku są to: git-bash.cmd oraz git-gui.cmd

Korzystanie z NPM

Aby mieć dostęp do NPM z poziomu jednej konsoli wraz z GIt'em musimy dodać kolejną ścieżkę w systemie z lokalizacją naszych programów. Niestety nie możemy tego zrobić poprzez dodatnie kolejnej zmiennej systemowej ponieważ musielibyśmy to zrobić na każdym komputerze, a dodatkowo pojawiłby się problem ze zmieniającą się literą naszego wolumenu. Istnieje jednak rozwiązanie tego problemu możemy edytować zmienną systemową PATH w ramach konkretnej instancji naszej konsoli. Wystarczy do skryptu uruchamiającego naszą konsolę z Gite' dodać jedną linijkę:

SET PATH=%PATH%;%~dp0%Node.js\

Cały nasz skrypt git-bash.cmd wygląda teraz następująco:

SET git-dir=%~dp0%GitPortable\

SET PATH=%PATH%;%~dp0%Node.js\

if %PROCESSOR_ARCHITECTURE% == x86 (
	SET git-dir=%git-dir%32-bit\
) else (
	SET git-dir=%git-dir%64-bit\
)

START %git-dir%git-bash.exe

Możemy przetestować jego działanie uruchamiając go dwukrotnym kliknięciem i wykonując komendę npm -v.

Aktualizacja NPM

Jak mogliśmy zobaczyć podczas testowania działania NPM'a nie mamy obecnie zainstalowanej najnowszej wersji. Niestety nie możemy zaktualizować go standardową komendą, ponieważ nie zakończy się ona powodzeniem

npm install npm@latest -g

Ale możemy zaktualizować NPM ręcznie - trochę okrężną drogą, ale grunt, że wszystko zadziała. W tym celu musimy zainstalować w jakimś katalogu NPM tak jakbyśmy instalowali pakiet lokalnie. Dlatego tworzymy nowy katalog, przechodzimy do niego, a następnie instalujemy w nim pakiet NPM.

Teraz zamykam konsolę. Udajemy się do katalogu w którym znajduje się Node.js i przechodzimy do katalogu z zainstalowanymi globalnie pakietami, czyli przechodzimy do katalogu:

Portable\Node.js\node_modules

Tutaj powinniśmy mieć tylko jeden katalog npm. Zmieniamy jego nazwę na, np. npm_back, usuniemy go po udanej aktualizacji NPM'a. Zmieniamy jego nazwę by mieć na wszelki wypadek działającą wersję NPM. Teraz musimy przenieść pliki z najnowszą wersją NPM, znajdują się one w:

Portable\npm-latest\node_modules

Wystarczy że przeniesiemy katalog npm obok npm_back.

Teraz uruchamiamy konsolę i sprawdzamy wersję NPM, jeśli wszystko działa i mamy zaktualizowaną wersję NPM możemy usunąć już niepotrzebne katalogi czyli:

Portable\Node.js\node_modules\npm_back
Portable\npm-latest

Grunt (Grunt-CLI)

Tutaj nie ma żadnej filozofii, pomimo iż konfigurujemy przenośne środowisko developerskie postępujemy standardowo czyli instalujemy pakiet globalnie. Globalnie czyli w naszym przypadku jest to w katalogu w którym mamy pliki Node'a. Konkretniej w katalogu:

Portable\Node.js\node_modules

Instalacja globalnie

Uruchamiamy naszą konsolę i wydajemy polecenie

npm install -g grunt-cli

Edytor czyli uniwersalne IDE

Jak wiadomo nie ma środowiska develperskiego bez dobrego edytora kodu, najlepiej by miał jeszcze cechy IDE czyli podpowiadanie składni czy sprawdzanie poprawności kodu. Owszem można kodzić w przysłowiowym Notatniku, ale po co? Ja rozważałem kilka opcji jeśli chodzi o wybór edytora kodu.

Visual Studio Code

Początkowo chciałem użyć Visual Studio Code na które w ostatnim czasie zacząłem się przesiadać. Powodem przesiadki było to że uznałem iż Sublime Text umarł, brak od ponad roku czasu jakichkolwiek aktualizacji czy informacji od autora o dalszych planach pozwalał mi dojść do takiego wniosku. Z tego powodu zacząłem rozglądać się za alternatywą i tak postanowiłem spróbować VS Code pomimo jego ogromnej wady - technologi w jakich został stworzony. Jednak kuszące były dostępne funkcje out of the box oraz dostępne pluginy. Szybko się z nim zakolegowałem ze względu na podobieństwa do Sublime Text'a i dlatego chciałem go wykorzystać podczas tworzenia środowiska developerskiego. Jednak podczas pierwszych prób skonfigurowania środowiska zauważyłem pewien problem jaki występował nawet w wersji portable tego edytora. Mianowicie pomimo iż korzystałem z wersji portable wszystkie ustawienia i zainstalowane pluginy zapisywały się lokalnie na danym komputerze w katalogu AppData. To był duży problem i uniedogodnienie ... całe szczęście kilka dni później pojawiła się aktualizacja Sublime Text 3, a zarazem pierwsze stabilne wydanie tej wersji.

Sublime Text 3

Od razu gdy dowiedziałem się o aktualizacji i stabilnym wydaniu Sublime'a wiedziałem którego edytora trzeba użyć. Nie dość, że jest on wydajniejszy od VS Code to jeszcze nie ma z nim problemu z przenoszeniem konfiguracji i pluginów pomiędzy komputerami. Dostępna jest też oficjalna wersja portable (VS Code również ją posiada) więc nad czym się tu zastanawiać, nic tylko pobierać ;).

VIM

Ze względu na to że całkowicie padł mi komp i konfiguruję na nowo całe środowisko zastanawiałem się czy nie przesiąść się przy okazji na VIM'a. Jest on naprawdę kuszącą alternatywą dla wszystkich innych edytorów, ale jednak wymaga poświęcenia trochę czasu na naprawdę gruntowne poznanie tego edytora by móc w nim naprawdę wydajnie pracować. Trzeba też poświęcić naprawdę dużo czasu na konfigurację i dostosowanie go do swoich potrzeb. Dodatkowo nie czuję się dość wystarczająco doświadczoną osobą by już się na niego przesiąść. Owszem używam VIM'a, ale tylko w konsoli serwera, nie dojrzałem jeszcze chyba do używania go na co dzień dlatego postanowiłem na razie jeszcze zostać przy tym co znam :).

Sublime Text 3 - pobieranie i konfiguracja

Chyba najprostsza i najprzyjemniejsza część całej pracy. Wystarczy udać się na stronę edytora i pobrać wersję portable dla systemu Windows. Tak jak w przypadku Node najlepiej wybrać wersję dla systemu 32 bitowego.

Tworzymy katalog Sublime Text 3 i wypakowujemy do niego pobrane pliki.

Jedyne co nam pozostało to instalacja Package Control dla Sublime'a aby w łatwy sposób móc instalować i usuwać pluginy. Instalacja jednak niczym nie różni się od instalacji w przypadku instalacyjnej wersji, dlatego nie będę tego tutaj opisywał. Dodatkowo możemy stworzyć skrypt w naszym katalogu Portable do szybszego uruchamiania Sublime'a. Jego kod będzie analogiczny jak w przypadku skryptu do otwierania Git'a z GUI. Ja ten skrypt nazwałem po prostu sublime_text.cmd, jego kod prezentuje się następująco:

SET st3-dir=%~dp0%"Sublime Text 3\"

START %st3-dir%sublime_text.exe

Podsumowanie

Na tym etapie pozostało mi jedynie usunięcie pobranych plików ponieważ zapisywałem je w katalogu Portable. To jak będzie się całe środowisko sprawowało w praktyce dopiero będę mógł powiedzieć za jakiś czas. Na tą chwilę mój katalog Portable prezentuje się jak widać niżej.

Oczywiście to nie jest moment na którym można zakończyć tworzenie naszego środowiska developerskiego. Można by jeszcze dodać jakiś serwer HTTP i MySQL który z całą pewnością przyda się web developerom, ale o ile NPM i Grunt może mieć zastosowanie w przypadku innych projektów niż webowe o tyle WAMP już jest typowo używane w przypadku web developmentu. Być powstanie kontynuacja tego wpisu dodająca właśnie do tego co już mamy przenośny serwer HTTP i serwer baz danych ;), ale to już czas pokaże.

Nie skupiałem się też w tym wpisie na konfiguracji samego Sublime Text'a ponieważ jest to temat nawet na serię wpisów i jest to dość indywidualna kwestia.

Kilka słów wyjaśnienia ... małe Q&A

• Dlaczego użyłem dwóch wersji Git'a dla różnych architektur systemu? - ponieważ gdy bawiłem się i sprawdzałem czy w ogóle da się takie środowisko stworzyć miałem problem z uruchomieniem git-bash.exe w wersji 32 bitowej pod systemem 64 bitowym, git-cmd.exe działał natomiast bez problemu. Teraz gdy to jeszcze raz sprawdzałem zadziałał bez problemu, jednak nie chcę zostawić tego szczęściu i wolę mieć coś działające praktycznie zawsze.
• Czy można dodać Node.js w wersji 64 bitowej analogicznie jak to jest z Git'em? - nie ponieważ pakiety instalowane globalnie będą instalowane tylko w aktualnie włączonej wersji, więc trzeba by pamiętać o potrzebie instalacji pakietów w momencie przesiadki na system o innej architekturze.
• Czy można dodać Sublime Text 3 w wersji 64 bitowej analogicznie jak to jest z Git'em? - niestety również nie z tego samego powodu co nie można dodać Node, tym razem jednak kwestią jest konfiguracja programu i zainstalowane pluginy.