Jeszcze jeden blog o programowaniu

Radosne twórczości leniwego programisty

Archive for the ‘JavaScript’ Category

Ręczna instalacja Node.js i npm w Ubuntu

leave a comment »

Standardowa instalacja node.js w Ubuntu z dostępnych repozytoriów poprzez sudo apt-get install nodejs nie zawsze pozwala uzyskać nam najświeższą wersję. Dla Ubuntu 16.04 zapytanie o paczkę nodejs zwraca nam wersję 4.2.6:

 

Jednym słowem, smuteczek.
Po wejściu na stronę projektu nodejs.org w oczy rzucają się od razu 2 wersje: 8.9.4 (Long Time Support, stabilna i zalecana dla większości użytkowników) oraz 9.6.1 – Current – PRAWIE najświeższa z możliwych, bo są jeszcze tzw. Nightly Build dla ludzi z dużą ilością czasu wolnego :).

Jednym ze sposobów sprawdzenia wersji paczki zainstalowanej aktualnie w systemie – oczywiście o ile jest zainstalowana – jest:

My jednak chcielibyśmy korzystać z najświeższej stabilnej wersji – 8.9.4.

Z wcześniej podanej strony pobieramy archiwum i rozpakowujemy:

Rozpakowany katalog node-v8.9.4-linux-x64 wrzucamy na przykład do katalogu /opt/:

Opcjonalnie zmieniamy rekurencyjnie właściciela katalogów i plików w lokalizacji /opt/node-v8.9.4-linux-x64:

Może to być przydatne, gdybyśmy chcieli kiedyś w tym katalogu coś zapisywać (np. inne pliki binarne) oraz instalować pakiety z npm.
Pozostaje nam utworzyć dowiązania symboliczne:

Jeśli próba uruchomienia poleceń node i npm się nie powiedzie jest dość prawdopodobne, że te ścieżki nie są dodane do naszej zmiennej środowiskowej PATH. Może to być przydatne w przyszłości, gdy w katalogu bin znajdzie się więcej plików wykonywalnych.
Aktualną zawartość zmiennej PATH możemy wyświetlić poleceniem echo $PATH i aby rozszerzyć tą zmienną o nowe katalogi zmieniamy w pliku ~/.bashrc zmienną środowiskową:

Żeby wprowadzone zmiany w ramach ~/.bashrc odniosły skutek powinniśmy go „przeładować”: source ~/.bashrc

Przydatny okazać się może poniższy skrypt, który w sumie spina wszystko w całość i pozwala prześledzić wykonane akcje krok po kroku:

Written by Filip Górczyński

2018.02.26 at 17:00:00

VueJS 2 – dostęp do konfiguracji środowiska

leave a comment »

vuejs logoW każdym co bardziej złożonym projekcie zachodzi potrzeba przechowywania różnych konfiguracji w zależności od środowiska: developerskiego, produkcyjnego, testowego, eksperymentalnego, niebieskiego i każdego innego. Oczywiście framework VueJS nie odstaje od normy i również oferuje możliwość takiej konfiguracji.

Na początku od razu zaznaczam, że zmiany w plikach konfiguracyjnych lub tworzenie nowych plików wymaga ponownego przebudowania i uruchomienia aplikacji – brak odzwierciedlania jakichkolwiek zmian w aplikacji może się okazać dość frustrujące jeśli zapomnimy o tej czynności – a często w konsoli widzimy, że się przebudowało – tylko jednak coś zmian z konfiguracji nie chwycił.

Konfiguracja dla różnych środowisk przechowywana jest domyślnie w 3 plikach (po utworzeniu czystego projektu):

Wyżej wymienione pliki ładowane są dokładnie w tej kolejności ewentualnie rozszerzając lub nadpisując dotychczasowe wartości zmiennych, więc w czystej instalacji na początku wczytywany jest plik prod.env.js, stałe w nim zawarte nadpisywane są plikiem dev.env.js a te z kolei test.env.js. Proste i logiczne (…długie jak drzewo genealogiczne naszej rasy…)

Oczywiście nic nie stoi na przeszkodzie aby, jeśli zajdzie taka potrzeba, dodawać swoje pliki konfiguracyjne definiujące ustawienia dla nowych środowisk. Np. staging – dodając przykładowo plik staging.env.js o przykładowej treści:

i wtedy np. w pliku dev.env.js rozszerzamy środowisko stagingEnv – a nie prodEnv jak to jest domyślnie.

Samo ustawienie bieżącego środowiska – wg którego budowany i uruchamiany jest VueJS odbywa się w pliku ./projekt/src/main.js w linijce:

chociaż lepszą z praktycznego punktu widzenia wersją byłaby poniższa:

I teraz, jeśli zawsze (we wszystkich środowiskach) potrzebujemy w aplikacji jakieś stałe to definiujemy je w pliku prod.env.js odpowiednio nadpisując w pozostałych plikach, jeśli oczywiście jakieś zmiany będą potrzebne.

W komponentach nic nie musimy importować, a dostęp do zmiennej jest wygląda w taki sposób: process.env.API_URL

Jeśli zbudujemy teraz projekt dla odpowiedniego środowiska, np.: dla produkcji npm run build otrzymamy katalog dist, w którym to znajduje się zbudowana chwilę temu aplikacja. Przechodząc w linii poleceń do tego katalogu cd ./projekt/dist i uruchamiając tymczasowy serwer python3 -m http.server 8181, w przeglądarce pod adresem 127.0.0.1:8181 powinna być dostępna nasza aplikacja – warto w tym miejscu potwierdzić różniące się między środowiskami zmienne, żeby nie było nieprzyjemnych niespodzianek.

Written by Filip Górczyński

2018.02.26 at 16:50:47

Czysty projekt VueJS 2 i używanie średników a zgodność ze standardami ESLint

leave a comment »

vuejs logo

JavaScript jako bardzo elastyczny język programowania nie wymaga używania średników na końcu instrukcji. Nie wymaga – i nawet zgodnie z zaproponowanym standardem JavaScript, nie zaleca się ich stosowania.

Jednak moim skromnym zdaniem – jako kogoś, kto kiedyś popełnił trochę kodu w C i Perlu – z jakiegoś powodu średniki zostały do składni wprowadzone, a ich stosowanie powoduje (ponownie – to tylko moje osobiste odczucie), że kod staje się też czytelniejszy i ładniejszy.

Utwórzmy zatem czysty projekt z ustawieniami jak poniżej – istotna jest linijka "Pick an ESLint preset Standard", gdyż różne standardy mogą się czepiać nadmiarowych średników lub ich braku.

VueJS – podczas inicjowania czystego projektu pozwala wybrać standard ESLint, w ramach którego sprawdzana będzie zgodność kodu z tym standardem, m. in. po uruchomieniu serwera deweloperskiego. Przy wyborze standardowego sprawdzania składni, dodanie średników na końcach instrukcji będzie skutkowało następującym  błędem:

Szczegóły błędu dostępne są pod adresem wskazanym w ramach ostrzeżenia: Extra semicolon.

Rozwiązaniem jest dodanie 'semi': [2, 'always'] do pliku .eslintrc.js:

Ponowne uruchomienie aplikacji będzie wymagało poprawienia (dodania) średników we wszystkich wskazanych miejscach, jednak nadal twierdzę, że nadmiarowy średnik jest lepszy niż jego pominięcie – gdyż próby zastępowania elementów składni wartościami domyślnymi mogą skutkować kodem podobnym do tego z Perla:

Całość dostępna w repozytorium.

Dodatkowe źródła i (głównie) kontrargumenty:

  1. JavaScript Style: Semicolons, or No?
  2. StandardJS#Semicolons
  3. JavaScript Semicolon Insertion. Everything you need to know
  4. An Open Letter to JavaScript Leaders Regarding Semicolons
  5. Understanding Automatic Semicolon Insertion in JavaScript

Written by Filip Górczyński

2018.02.22 at 09:23:51

Zmiana kolejności zakładek w Chrome DevTools

leave a comment »

Jako programiści webowi dużą część czasu spędzamy w DevToolsach, czy jak kto woli – w „narzędziach programisty” – wbudowanych w przeglądarki (osobiście jestem zwolennikiem Chrome’a). W związku z tym dobrze jest skonfigurować to narzędzie – chociaż w niewielkim stopniu – pod siebie.

O ile dobrze jest wykorzystywać dobrodziejstwo skrótów klawiaturowych (do szybkiego podglądu których dostęp uzyskujemy poprzez kliknięcie 3 pionowych kropek [nie znam profesjonalnej nazwy, chociaż spotkałem się z „hamburger menu”] w prawym górnym narożniku DevTools – chodzi dokładnie o przycisk   ). Pełna lista skrótów dostępna jest na stronie chrome-devtools. Używanie skrótów klawiaturowych może znacznie przyspieszyć naszą pracę z tym narzędziem.

To o czym chciałbym jednak napisać to możliwość dostosowania zakładek w DevTools – nie wiem na ile znana jest to funkcja, ale może okazać się dość przydatna. Otóż jeśli nie korzystamy zbyt często z jakiejś zakładki to po prostu ją klikamy i przeciągamy, natomiast te, które wykorzystywane są przez nas najczęściej możemy przeciągnąć na początek, czego kolejnym plusem jest ich widoczność przy zmianie (głównie zmniejszaniu) okna Chrome.

Written by Filip Górczyński

2018.02.14 at 13:59:30

CORS Headers – komunikacja VueJS i Django

leave a comment »

vuejs logoCross-Origin Resource Sharing (CORS) to mechanizm wykorzystujący dodatkowe nagłówki HTTP pozwalające różnym agentom (np. przeglądarkom) na dostęp do zasobów znajdujących się na innej domenie, porcie czy protokole niż aktualna. 

Na potrzeby wpisu zakładam, że framework (Django) i biblioteki (Vue.js i axios) z których będziemy korzystać – mamy już zainstalowane w projekcie.

W projekcie Vue wprowadźmy następujące zmiany:

W pliku App.vue:

W pliku config/dev.env.js:

Pliki src/assets/logo.png i src/components/HelloWorld.vue możemy wyrzucić, jako w tej chwili nie używane.

W backendzie natomiast, w pliku views.py naszej aplikacji (movies):

i dodajemy routing dla naszej aplikacji w pliku urls.py (plik ten domyślnie nie istnieje i należy go utworzyć):

Następnie dokunujemy zmian w plikach urls.py – głównym pliku routingu całego projektu Django:

oraz settings.py:

Startujemy serwery poniższymi poleceniami w odpowiednich katalogach:

Uruchamiamy przeglądarkę i otwieramy 2 zakładki. W pierwszej zweryfikujemy tylko, czy serwer Django zwraca prawidłową odpowiedź – JSON (http://127.0.0.1:8000) i jeśli tak, to od razu można ją zamknąć. W drugiej zakładce otwieramy narzędzia programisty i przechodzimy pod adres aplikacji Vue (http://127.0.0.1:8080).
Dziwne – w zakładce Network zobaczyć możemy, że żądanie GET do serwera się udało i nawet możemy podejrzeć zwrócone wyniki:

Czyli wszystko jest prawidłowo? No nie do końca niestety. O ile domena (host) – w tej sytuacji 127.0.0.1 nie są problemem – to sprawa komplikuje się właśnie w przypadku niezgodności portów i przeglądarka może nam w konsoli sypnąć następującym błędem:

Problem nasz rozwiązać możemy paczką django-cors-headers, jej instalacja nie odbiega za bardzo od instalacji innych paczek Pythona:

pip install django-cors-headers==2.1.0

Zmieniamy trochę w pliku settings.py (ale naprawdę ciut-ciut):

… restartujemy serwer Django i już, wchodząc na adres naszej aplikacji powinniśmy cieszyć się pobranymi z serwera danymi.

Wymagane paczki do postawienia projektu Django znajdują się  w katalogu backend/requirements/base.txt, natomiast całość kodu źródłowego bezpośrednio w repozytorium VueJS-Django-CORS.

Dla zainteresowanych można jeszcze poszukać informacji na temat Same Origin Policy.

Dodatkowe źródła (często z fajnymi obrazkami):

  1. MDN CORS
  2. Understanding CORS
  3. Understanding CORS: Cross-Origin Resource Sharing
  4. Understanding and using CORS

 

Written by Filip Górczyński

2018.02.09 at 13:42:07

Angular 5 i Font-Awesome

leave a comment »

Jedną z możliwości integracji font-awesome z Angular jest użycie gotowych paczek z repozytoriów npm. Przegląd kilku – oraz szybki rzut oka na datę publikacji ostatnich zmian w tych paczkach wyłonił `angular-font-awesome’. I o ile instrukcja instalacji dostępna jest na stronie repozytorium tej paczki – nie jestem zwolennikiem ponownego szukania samej nazwy paczki ani jak jej użyć.

Dla porządku tworzymy sobie czysty projekt w Angularze:

Instalujemy wybrane przez nas paczki (jako, że jestem zwolennikiem yarna to tego będę używał):

yarn add od razu załatwi nam sprawę dodania tych paczek z odpowiednimi wersjami do pliku package.json.

Dodajemy odpowiednie importy w pliku app.module.js:

oraz ładujemy style globalnie dla całej aplikacji w pliku .angular-cli.json w sekcji styles:

I to już wszystko – powinniśmy mieć możliwość korzystania z ikonek font-awesome w naszej aplikacji wrzucając do szablonu, przykładowo:

Bonus: Bulma CSS Framework

Wartym uwagi jest niewielki framework CSS – Bulma. Instalujemy odpowiednią paczkę (oczywiście nie jest to jedyny sposób instalacji):

W pliku .angular-cli.json dodajemy odpowiednią referencję do pliku CSS naszego frameworka, aby był dostępny globalnie w całej aplikacji:

I oczywiście aby zobaczyć, czy wszystko działa, uzupełniamy np.: app.component.html przykładowym szablonem:

Uruchamiamy serwer i weryfikujemy w przeglądarce, czy wszystko śmiga.

Całość kodu źródłowego dostępna jest też w repozytorium NG5-FontAwesome-Bulma-Boilerplate. Klonujemy (git clone git@github.com:filipgorczynski/NG5-FontAwesome-Bulma-Boilerplate.git), przechodzimy do katalogu projektu (cd NG5-FontAwesome-Bulma-Boilerplate), odpalamy yarn aby zainstalować zależności z package.json i startujemy serwer (ng serve).

Written by Filip Górczyński

2018.02.07 at 10:49:21

Drupal 6 i najnowsza wersja jQuery

leave a comment »

Od kilku już projektów w Drupalu spotykałem się z problemem przy wykorzystaniu najaktualniejszej wersji jQuery. Drupal w wersji 6 wykorzystuje jQuery w wersji 1.2.6. Instalacja modułu jquery_update trochę poprawia tą sytuację jednak nadal pozostajemy z wersją 1.3.2. W chwili pisania tego tekstu najnowszą wersją jQuery jest 1.7.1, więc jak widać sporo rzeczy mogło ulec zmianie. Korzystając z najnowszej wersji jQuery mamy w dodatku pewność, że znalezione błędy zostały poprawione (i ewentualnie, powstały nowe), kod został przepisany by działać szybciej, zwiększył się asortyment funkcji.

/*! jQuery v1.7.1 jquery.com | jquery.org/license */
// źródło najaktualniejszej wersji jQuery

$$ = jQuery.noConflict();

console.log('o1. ', $.fn.jquery);
// o1. 1.2.6
// LUB
// o1. 1.3.2

(function($) {
// W tej przestrzeni znajdzie się nasz kod
console.log('o2. ', $.fn.jquery);
   // o2. 1.7.1
})($$);

Co się tutaj dzieje?

Poprzez funkcję jQuery.noConflict() obiektu jQuery utworzymy referencję $$, która będzie przechowywała nowy obiekt biblioteki jQuery (1.7.1 w tym wypadku). Zmienna $$ będzie dostępna w zasięgu globalnym (window), a my będziemy posiadać zmienne $$ (wersja  1.7.1) oraz $ (wersja 1.2.6/1.3.2).

Tworzymy następnie kolejny zasięg poprzez wywołanie kolejnej funkcji anonimowej, do której przekazujemy wcześniej utworzony obiekt jQuery 1.7.1. Drugie wywołanie funkcji anonimowej moglibyśmy pominąć i odwoływać się w naszym kodzie do jQuery wykorzystując zmienną $$, ale osobiście uważam to za mało wygodne.

Written by Filip Górczyński

2012.02.20 at 20:47:31

%d blogerów lubi to: