Silv

  1. Warszawa
Programista (front-end) bez większego doświadczenia. Pisywałem wiersze i opowiadania.
Silv
2019-09-07 04:08

#blog

Nowości na moim blogu silvuss-thoughts:

W ramach szerszych porządków na GitHubie napisałem artykuł, który w zamiarze ma być jedną z rzeczy, na których oprę (opieram) swoje próby ujednolicania wszystkich swoich projektów na GitHubie. Krótko mówiąc, opisuje on konwencje, z których korzystam (=staram się korzystać) przy tworzeniu i rozwoju swoich projektów na GitHubie. Link: https://silvuss.github.io/201[...]thub-projects-that-i-use.html

Artykuł może wydać się nieuporządkowany. Jeśli tak, przyczyną może być to, że coraz mocniej staram się wprowadzać do mojego pisania i w ogóle dewelopmentu pewną zasadę. Mówi ona, że lepiej nawet początkowo z błędami, ale cokolwiek zrobić, niż bez błędów nic nie zrobić. Jeśli artykuł wyda się taki, to niedobrze; prosiłbym o podpowiedzi, co zmienić. Jeśli nie wyda się taki, to dobrze.

Bardzo chętnie przyjmę wszelkie oceny, recenzje i w ogóle komentarze.

Miłego czytania. :)

Silv
2019-09-04 22:37

Choć moje początki z edytorem Vim nie były interesujące, okazało się, że da się wytrzymać. Więcej, da się trochę przyzwyczaić (choćby do otwierania go).

W miarę prób kończenia nauki podstaw Angulara, które to kończenie odkładam w czasie dzień po dniu, zauważam, że nie tak trudno idzie niektóre rzeczy w Vimie wykonać:

  • otworzyć: vim; można nawet oszczędzić literkę, jeśli w danym systemie operacyjnym polecenie vi jest skrótem do polecenia vim (a nie musi, może być innym programem);
  • zamknąć: :qw – zapisując zmiany w tym samym pliku; :qw [ścieżka] – zapisując zmiany w nowym pliku (takiego polecenia nie ma, mój błąd); :q! – odrzucając zmiany; :q – jeśli nie ma zmian;
  • otworzyć bufor (bufor przechowuje jeden plik) w tym samym oknie (wydzielona część okna edytora) z plikiem: :e [ścieżka] ("e" od "edit" najpewniej);
  • otworzyć okno (z nowym, pustym buforem): :new;
  • zamknąć bufor (wraz z oknem, w którym jest otwarty*): :bd! (odrzucając zmiany); :bd (jeśli nie ma zmian);
  • zamknąć okno (bez bufora, który jest w nim otwarty): (tak samo, jak zamykanie całego edytora).

Ponadto, jeśli chodzi o edycję pliku, również nie tak trudno:

  • cofnąć ostatnią zmianę: u;
  • ponowić ostatnio cofniętą zmianę: CTRL+r (samo r włącza tryb "replace");
  • zaznaczyć tekst: małe v, potem strzałka lewo/prawo/góra/dół – fragment; wielkie V – cała bieżąca linia ("v" od "visual selection");
  • skopiować zaznaczony fragment tekstu: y ("y" od yank 'szarpać, wyrywać');
  • wkleić tekst: małe p – na pozycji za kursorem; wielkie P – na pozycji przed kursorem (pojedyncze, całe linie odpowiednio linię przed i linię za bieżącą linią);
  • usunąć tekst: d – zaznaczony fragment; dd – cała bieżąca linia;
  • wyszukać tekst: / (tak samo jak np. w Firefoksie, oraz w narzędziach man oraz info na Linuksie).

* Dla potrzebujących – zawsze znajdzie się rozwiązanie alternatywne. Tutaj w postaci wtyczki do Vima, która, według opisu, pozwala zamknąć bufor bez okna: https://vim.fandom.com/wiki/D[...]er_without_closing_the_window


Niektóre źródła:


UPDATE: Opisane polecenie vim ruchamia edytor Vim w terminalu. Warto jednak wspomnieć, że jest też możliwość uruchmienia Vima w trybie graficznym: gVim.


UPDATE2: Zapomniałżebym napisać jeszcze o oknach:

  • Przełączać się między oknami można za pomocą albo: CTRL+w,CTRL+w (czyli podwojone CTRL+w), albo: CTRL+w, potem strzałka lewo/prawo/góra/dół.

UPDATE3:

O buforach jeszcze:

  • Co czasem przydatne – listę buforów można wyświetlić za pomocą: buffers.
  • Przełączać się między buforami można za pomocą:
    • bn – następny bufor (w kolejności otwarcia); bp – poprzedni bufor (w kolejności otwarcia);
    • bX – skocz do bufora numer X (w kolejności otwierania);
    • buffers, potem X – gdzie X to numer bufora (w kolejności otwierania).

Co istotne, przy zamykaniu numery są usuwane z listy, a przy otwieraniu nowych – pierwsze w kolejności są wykorzystywane brakujące numery; przykładowo, jeśli lista numerów buforów wygląda tak: 1, 2, 4, to kolejny otwarty bufor będzie mieć numer 3.

matmax

Nawet Linus nie kodzi w Vim, woli emacsem przez sendmail.

athaylean

vim lepszy niż emacs, fajnie że to opisałeś trochę rzeczy się dowiedziałem :D

Ktos

Polecam :x, robi to samo co :wq, chyba, że nie było zmian, to wtedy nie aktualizuje pliku.

Silv

PS. @Ktos: przydałoby się jakieś odniesienie do dokumentacji (najlepiej tej wbudowanej w Vima).

Ktos

@Silv: http://vimdoc.sourceforge.net/htmldoc/editing.html#:xit - co mi przypomniało o istnieniu ZZ, które robi to samo co :x, a o którym zapomniałem, a czasami jest jeszcze szybsze, bo nie trzeba sięgać do Escape. W ogóle, jeśli planujesz zostać na dłużej z vimem, wiele osób poleca przemapowanie klawisza Caps Lock na Escape.

Silv

@Ktos: myślę, że lepiej mi będzie z ESC bez przemapowania. Przy Z,Z to raczej nie trzeba sięgać do dwukropka.

Maciej Cąderek

@Silv: Ja uzywam Neovima bo ma imo lepsze defaulty (a ja nie lubię za dużo konfigurować). Poza tym polecam zainstalować wtyczkę vim do głównego edytora (każdy szanujący się edytor/IDE ma takową). Ja uzywam VS Code + vim plugin jako główny edytor i neovim jako narzedzie do szybkich edycji (+ pare pluginów jak fzf, vim-airline, NERDtree). Ba, nawet na CodePen mam właczony tryb vim :D

Maciej Cąderek

@Ktos: Potwierdzam, CapsLock jako dodatkowy Escape jest mega wygodny (zacząłem uzywać na macbooku bez fizycznego klawisza Esc, teraz uzywam wszędzie).

Maciej Cąderek

@silv A, i dzięki za poradę jak wyjść z Vima :D

WhiteLightning

@Silv: dopisz dgg i dG -> niezastapione jak potrzebujesz np. bardzo duzy log przyciac bo tylko vim sobie z nim radzi na danej maszynie :)

no_solution_found

hehe naprawdę robisz wszystko by się tego angulara nie nauczyć :D

nullpt4

vim jest moim daily IDE

rgawron

Jeśli używa się vima w terminalu, to fajnie wcześniej odpalić screena - wtedy np. na jednym wirtualnym terminalu mamy vima a na drugim kompilujemy, a na trzecim jeszcze co innego, wszystko przełączając się tylko klawiaturą. Bardzo wygodne.

https://linux.die.net/man/1/screen

no_solution_found

@rgawron ja używam zamiast screena tmux i też daje radę :)

Kokoniłaj

Krótszym odpowiednikiem:buffers jest :ls. Ctrl+6 wraca do ostatnio używanego bufora.
Ja osobiście zamiast ESC używam Ctrl+[

Spine

to do artykułów, a nie na mikrobloga :P

mlk

CAPS LOCK najlepiej przemapować na CTRL gdy go trzymamy wciśnięty, a przy pojedynczym wciśnięciu na ESC.
A co do Vima, to wiadomo, że Emacs lepszy, bo ma też Evil. ;)

rgawron

@no_solution_found: nie znałem tego, dzięki za info :)

mlk

Ucząc się Vima warto to przeczytać https://stackoverflow.com/a/1220118 - generalnie chodzi o to, że o klawiszologii w Vimie warto myśleć jako o języku służącym do edycji tekstu (kodu). Czyli np. gdy wiemy, że dd znaczy wytnij linię, to wiemy też że 4dd wytnie nam 4 linie. itd..

lion137

Jeśli chodzi o Vim, to podstawowa kombinacja to ctrl z, fg:)

Silv

@Maciej Cąderek: Ja uzywam Neovima zbyt dużo dobrego na raz, zostanę chyba przy Vimie, aż opanuję tak dobrze, jak "Zemstę" Fredry (czyli na pamięć). Poza tym polecam zainstalować wtyczkę vim do głównego edytora (każdy szanujący się edytor/IDE ma takową). – nie rozumiem, dlaczego miałbym instalować edytor w edytorze? — @WhiteLightning: dzięki za polecenia; dopisałbym, ale wolę, by ten wpis pozostał takim krótkim. Gdybym kiedyś pisał artykuł np. do naszego Kompendium, to postaram się więcej rzeczy opisać. — @no_solution_found: może... :/ Szkoda, że nie mam kogoś, kto będzie odpowiadał mi na pytania, bo samemu szukać odpowiedzi do każdej głupoty, której nie rozumiem, już mnie w tym przypadku zniechęciło. — @rgawron, @no_solution_found: jakie są przewagi otwierania kilku procesów do edycji tekstu nad otwieraniem tylko jednego? — @Kokoniłaj: kurczę, zapomniałem o tym :ls (a jest w źródłach). Jak zwykle o czymś. :) Dzięki! — @Spine: sugestia warta zastanowienia! — @mlk: odciągasz mnie takimi dobrymi postami jak ten na SO od nauki Angulara. :P

Maciej Cąderek

nie rozumiem, dlaczego miałbym instalować edytor w edytorze nie edytor w edytorze tylko key bindings

Silv

@Maciej Cąderek: Rozumiem – jeśli bym się do nich przyzwyczaił.

rgawron

@Silv: możesz ustawić tak, że np. na jednym terminalu masz vima z jednymi rzeczami, na drugim z drugimi, na trzecim kompilujesz, a na czwartym ccommitujesz/puszujesz. To wciąż jest jedno okienko, tylko klawiszami przełączasz jego zawartość, to jest szybkie i wygodne, IMHO wygodniejsze niż przełączanie się między realnymi oknami terminala.

W dodatku, jeśli screena odpalasz na zdalnym hoście, jeśli się rozłączysz, po ponownym połączeniu, możesz się do niego przypiąć, nie musisz od nowa otwierać wszystkiego. To jest super jak się łączysz przez ssh do RaspbertyPi.

Maciej Cąderek

@rgawron Screen/Tmux po ssh są spoko opcją, ale na localhoście u mnie tę role przejmuje tiling WM (i3wm) - imo najlepsza opcja.

vpiotr

Zawsze bede pelen podziwu dla ludzi lubiacych vi/vim.

kelog

Fajny post, ale jedna rzecz: żadnych strzałek, a fe! Poza sytuacjami gdy faktycznie chyba nie ma szybszej opcji (np. przy szukaniu /) to tylko hjkl i palce grzecznie na home row :)

Maciej Cąderek

Jeszcze taki tip - jak chcesz się szybko poruszać po pliku to ustaw set relativenumber w configu - dzięki temu łatwo skakać do konkretnego miejsca w kodzie za pomocą <some_number> j / k / ArrowUp / ArrowDown

Jasnowidz

Ja mialem plugin komend VIMa zainstalowany w Eclipse, ale z tego co pamietam dzialal do D, bylo kilka konflikow skrotow z innymi podstawowymi dla mnie ze wgledu na technolgie pluginami.

Silv

@rgawron: ach, w ten deseń. Może rzeczywiście. Cóż, np. VS Code ma też dużo "w jednym oknie", choć pewnie nie ma takiej elastyczności. @kelog: nie bardzo to widzę. Przy h/j/k/l trudno (mi) wciskać ENTER, łatwiej ze strzałkami (ruch dłoni góra-dół na mojej klawiaturze, a nie prawo-lewo).

mlk

@Silv: ale jak trzymasz dłonie na home row (asdf / jkl;) to do entera dosięgniesz małym prawym palcem więc w ogóle dłonią nie musisz ruszać. a druga rzecz jest taka, że choć hjkl jest bardziej efektywne od strzałek, to są lepsze sposoby nawigacji. pisałeś o /, szukać (i skakać) w drugą stronę można za pomocą ?, jeśli chcesz poruszać się wewnątrz jednej linii to f i t. Użyteczne są też w - skok do początku następnego słowa, czy e skok na koniec następnego słowa. I tak jak pisałem wyżej, każdą z tych komend można łączyć z innymi. Czyli 3w skacze o 3 słowa do przodu. A v4e zaznacza (visual mode) 4 słowa do przodu. A d/var i Enter usuwa wszystko od kursora po pierwsze następne wystąpienie stringu var. d4/var usuwa wszystko aż po 4 następne wystąpienie danego stringu.

Silv

@mlk: ale jak trzymasz dłonie na home row (asdf / jkl;) to do entera dosięgniesz małym prawym palcem więc w ogóle dłonią nie musisz ruszać. – od biedy dosięgnę, ale na mojej klawiaturze to zbyt niewygodne. Zresztą mam krótkie palce, więc nie wiem, czy na jakiejkolwiek bym wygodnie dosięgnął (poza jakimiś bardzo niestandardowymi). Użyteczne są też w - skok do początku następnego słowa, czy e skok na koniec następnego słowa – od ich używania trochę mnie odstręcza przyjęta odgórnie definicja słowa; wolę używać f (też w połączeniu z v; a t nie znałem). Reszty poleceń nie znałem, które opisujesz. ...Te polecenia to jednak użyteczne są. :)

Silv
2019-08-07 04:36

Moja aplikacja bracket-string-validator nabiera piór i kształtów nie, kształtów nie.

Mięśni raczej nie. Nadal dwie funkcjonalności: sprawdzanie poprawności wyrażenia nawiasowego oraz testowanie wydajności (benchmarking). (Co by tu można dodać?)

Ale za to część odpowiedzialną za sprawdzanie poprawności wyrażenia nawiasowego mam już napisaną (zbyt dużo powiedziane) w Angularze. (Jeszcze muszę dodać testowanie wydajności.) To raz. Dwa, że planuję przepisać część logiki na Javę, nadto dodać GUI w C oraz bazę danych obsługującą SQL.

Kłopot trochę z testami jednostkowymi i integracyjnymi. Same testy pisze się w miarę zwyczajnie, przynajmniej w JavaScripcie. Oby tylko w innych technologiach nie było innych podejść (?). W Javie to jeszcze mogę sobie to jakoś wyobrazić, "zekstrapolować" z JavaScriptu, ale w C i w Bashu nie... będę musiał się nauczyć. Nie ma rady! Też testowanie na różnych środowiskach – trzeba mi ogarnąć Travisa i jego konfigurację. Nie wiem, czy da się ustawić konkretną dystrybucję Linuksa. Zresztą, czego ja oczekuję za darmo? Przy czym jest też plan, z początków tworzenia aplikacji, by postarać się o większą generyczność implementacji, co bym nie musiał martwić się dystrybucją. Jednak to mniej ważna sprawa, dodatek w zasadzie. Aplikacja ma działać na jednym środowisku bezbłędnie; inne – opcjonalnie i w nieokreślonej przyszłości.

W tym świetle na dalszy plan schodzi rozbudowa obecnego interfejsu CLI. Planuję m.in. dodać debug mode. I tyle. Miałbym pewnie więcej pomysłów, ale w sumie nie ma sensu, dopóki (eee... albo "skoro") nikt tego nie używa.

Z bardziej operacyjnych spraw: nadal nie wiem, jak powinien u mnie wyglądać deployment (zob. też wątek na naszym forum). Przy tylu technologiach robi się skomplikowanie... ale przy tym fajnie. :) (W teorii. Najprzyjemniej rozmyślać o tym, czego to ja nie zaimplementuję.)

Myślę też... nad PHP (tak ostrożnie). Ale prawie go nie znam. Nie wiem, czy chce mi się uczyć na tę imprezę. Ale jakby... byłby przyczynek dla mnie do ruszenia Coyote. Ale to znów... Docker. A Dockera nie mam w planach. (Jeszcze?)

Dla chętnych: planowanych jest parę innych, mniej "przebojowych" spraw – można rzucić okiem: https://github.com/silvuss/si[...]acket-string-validator/issues


Nie jest to celem tego wpisu, ale – jeśli ktoś chciałby pomóc (wiedzą), to bardzo chętnie. :) Tutaj wątek, w którym proszę o ocenę: Ocena małego projektu JS (Node.js) + Bash

#bracket-string-validator #javascript #c #bash #cli #gui #web #angular #java #sql #database #deployment #php #recenzja #nodejs

baant

pierwsze co rzuca się w oczy po kliknięciu to labelka [build | error] :c

vpiotr

TL;DR. Nie wiem co jest celem tego projektu? EGSS (Enterprajs-Grejd Spoj Solution)? Czy coś w rodzaju JIT Brainf**ka?

Jeśli to drugie to można jeszcze dodać: 1) analizator gdzie brakuje nawiasów
2) generator losowego poprawnego (lub nie) ciągu
3) generatora danych testowych - czyli to co w 2 tylko cały zestaw np. wszystkich kombinacji 10-znakowych wraz z flagą czy poprawny czy nie.
4) kross-kompilator z wyrażenia nawiasowego do Whitespace

Proponowałbym się skupić na razie na jednej technologii. Na razie build ma error.
Ew. po opisaniu co to robi zachęcić innych programistów do implementacji w innych technologiach. Najłatwiej to będzie zrobić z CLI.

Shizzer

CMocka to dość przyjemny framework do testów jednostkowych w C - > https://cmocka.org/ Polecam

Silv

@baant: prawda. Rzuciłem wczoraj okiem na błąd, ale uznałem, że jego rozwiązanie leży w gestii Travisa. Jeśli będzie się przedłużać, spróbuję sam coś zrobić.
@danek: rozwiń się. ;)
@vpiotr: celem jest pokazanie, co umiem. Zresztą opisałem cele tutaj: https://silvuss.github.io/201[...]ml#ambitions-and-expectations. Hm: 1) dobre, spróbuję; 2) dobre, spróbuję; w zasadzie już mam/miałem napisany w wewnętrznym kodzie; 3) myślę, że wystarczy nr 2; 4) dobre! spróbuję; nie znałem Whitespace. Build error – napisałem wyżej. Ostatnia porada też nie od parady, ale myślę, że ten projekt będzie moim prywatnym. Niech każdy robi z nim, co chce (zgodnie z licencją, która obowiązuje/będzie obowiązywać), ale ja robię swoje.

no_solution_found

a tak z innej beczki - po co ten projekt jest potrzebny? Jaki problem to rozwiązuje?

no_solution_found

o matko, ale on skacze po wszystkim. Mam wrażenie, że dłużej pisałeś readme niż sam projekt :) Co do dockera to IMO i tak i tak Cię to czeka. Przynajmniej podstawy. Poza tym, jeśli jest dobrze skonfigurowany, to nie musisz go w ogóle znać - wystarczy docker-compose. Co do testów integracyjnych, to jakie konkretnie testy masz na myśli?

Silv

@no_solution_found: sensowne pytanie! Rozwiązuje problem braku moich projektów, w których nie ma niczego ciekawego od strony technologicznej.

Ile pisałem README? Nie wiem, ale całą dokumentację porównywalnie z kodem, myślę.

Czemu Docker mnie czeka?

Testy integracyjne – zauważyłem, że w internecie, w tym u nas na forum, panuje tendencja do nazywania tak różnych rodzajów testów. Spodobała mi się definicja @jarekr000000 z tego postu. Robię je analogicznie do jednostkowych. Jednostkowe u mnie sprawdzają, czy każda z funkcji/metod danego modułu zwraca dane wyjście dla danego wejścia lub rzuca wyjątkiem; w przypadku zależności zewnętrznych – robię ich atrapy (mówiąc oględnie; nie znam się na nazewnictwie jeszcze). Integracyjne sprawdzają to samo, przy czym w przypadku zależności zewnętrznych nie robię ich atrap. I tak, na przykład, odwołując się do innego modułu w testach jednostkowych robiłbym jego atrapę, a w testach integracyjnych nie (rozumując, że ten moduł został przetestowany przez swoje testy jednostkowe).

no_solution_found

jednostka to nie pojedyczna metoda w klasie czy nawet klasa. Raczej to jakaś grupa elementów, która łącznie daje jakąś logiczną całość. Testy integracyjne integrują jakieś elementy ze sobą. Np Aplikację z bazą danych czy zewnętrzną usługą. Dlatego się zastanawiam między jakimi elementami Ty testujesz integrację :)

Silv

@no_solution_found: rozumiem, a skąd taka definicja jednostki? Moim zdaniem jednostka to funkcja/metoda/klasa/moduł, tak jest napisane np. w Wikipedii: In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. (https://en.wikipedia.org/wiki/Unit_testing#Description) Wybrałem akurat metody/funkcje – tak jakoś najłatwiej mi było testować; np. klasa nie ma wejścia i wyjścia.

Testuję integrację między dwoma modułami. Jak napisałem, z informacji w internecie odniosłem wrażenie, że testy integracyjne mogą być zdefiniowane różnie. Wybrałem akurat taką definicję, myślę, że jest w porządku.

Ale dzięki za inny punkt widzenia, na pewno poszerza to moje spojrzenie. :)

no_solution_found

@Silv to jest właśnie mylne spostrzerzenie :) oczywiście zależy od tego jak wygląda nasza domena, Kiedyś pisałem artykuł na ten ten temat. Muszą go w końcu dokończyć! Tu masz opisane mniej więcej to o czym ja mówię: http://softwaretestingfundamentals.com/unit-testing/ `Definition by ISTQB

unit testing: See component testing.
component testing: The testing of individual software components.`

przy czym komponent może być mały jak klasa albo cały komponent np koszyka i później możesz testować czy ten komponent integruje się z zamówieniami a zamówienia z magazynem itp

Silv

@no_solution_found: nie mogę znaleźć na podanej stronie jej autorów; może Ty znalazłeś? Jak skończysz artykuł, chętnie go przeczytam. Tylko nie zapomnij podać źródeł. ;)

somekind

@Silv: definicja jednostki znajduje się w każdym słowniku. Człowiek jest jednostką i sam niezależnie może wykonać jakąś pracę. Sama ręka jednostką nie jest, bez reszty człowieka jest bezużyteczna.

Silv

@somekind: poprzez analogię: funkcja jest jednostką, metoda nie? Teoretycznie mogę się zgodzić. Jaki słownik masz na myśli, przykładowo?

danek

@Silv: czym się różni funkcja od metody?

danek

@somekind: akurat z definicją jednostki to są problemy ;)

Silv

@danek: ja je odróżniam w ten sposób, że "funkcja" jest elementem programowania proceduralnego, a "metoda" – obiektowego. To rozróżnienie w szerszym niż mój kontekście może być błędne, ale na razie nie mam podstaw, by tak twierdzić.

somekind

Na przykład słownik języka polskiego. Ani funkcja ani metoda nie jest jednostką, ale zarówno funkcja jak i metoda może nią być. Jednostka to coś, co stanowi odrębną całość, jeśli funkcja/metoda spełnia ten warunek, to jest jednostką. Jeśli nie, to nie.

Silv

@somekind: a co jest "odrębną całością"? Mam wrażenie, że każdy może sam to zdefiniować.

somekind

Czy ręka działa bez człowieka?

Silv

Wolałbym nie porównywać programu do ciała ludzkiego, w ogóle do żadnego. Czy definicja jednostki na Wikipedii, którą podałem wyżej, jest zła?

somekind

Nie widziałem jej wcześniej. Ta definicja jest nieco zbyt subiektywna jak na encyklopedię, ale nie jest zła. Jednostką może być moduł, a może być funkcja. W programowaniu obiektowym jednostką może być jedna metoda, obiekt albo zespół obiektów. Nie ma znaczenia z ilu elementów się składa, ważne jest, czy samodzielnie jest w stanie wykonać jakieś zadanie. To jest o tyle ważne, że w toku pracy może np. najpierw powstać jednostka będąca jedną wielką metodą, można napisać do niej testy, a potem można ją zrefaktoryzować i zamienić na zestaw obiektów, bez ruszania testów - to jest produktywne. W przypadku bezsensownego podejścia jednostka == klasa, refaktoryzacja jest uciążliwa.

danek

@somekind: zamiast używać określeń "jednostkowy", "integracyjny", "akceptacyjny", "cokolwiek" bardziej bym się skłaniał ku rozdzieleniu: czy mogę je odpalić w ciągu <3s przed commitem, czy odpalają się przed release

Silv

@somekind: nie rozumiem. Przecież jeśli tę wielką metodę zmieni się na zestaw obiektów bez ruszania testów, to oznaczałoby według Twojej definicji, że żaden z tych obiektów nie jest odrębną całością. Jak "obiekt" – w rozumieniu, powiedzmy, programowania obiektowego – może nie być odrębną całością?

somekind

@danek: słyszałem o takim podziale na jakieś "pre-commit' i "post-commit" testy u swoich Hindusów, niestety w ogóle nie rozumiem o co chodzi, i jaki testy mogą w ogóle mieć związek z commitem. Nie stosuję takiego rozróżnienia, ja jedne testy odpalam częściej, inne rzadziej, ale z commitami czy releasami to nie ma związku żadnego.

@Silv: Jest odrębnym obiektem, ale nie jest odrębną jednostką, a jedynie jej częścią.

danek

chodzi mi o rozdzielenie testów które odpalasz w IDE lokalnie, a jakieś dzikie regresyjne które gdzieś na serwerze działają.

danek

inne dzielenie testów jest tylko semantyką 

Silv

@somekind: w kwestii testów – może chodzi o coś takiego? -> http://eng.wealthfront.com/2012/01/26/pre-commit-tests/ W kwestii obiektów: dla mnie "obiekt" (=klasa) z definicji jest odrębną jednostką. Może oczywiście należeć do większej jednostki – przestrzeni nazw czy modułu.

Silv

@danek: dzikie regresyjne testy pustoszące zrównujące z ziemią build na serwerze – sobie wyobraziłem. :D

somekind

@danek: ja lokalnie odpalam zarówno testy jednostkowe, jak i integracyjne testujące przepływy biznesowe (zarówno w formie wywołań pojedynczych endpointów, jak i ich sekwencji). Te pierwsze, gdy uznam za stosowne, te drugie również (ale z oczywistego powodu rzadziej). No i zawsze przed pushem. Testy też są odpalane po deploymencie na testowe środowiska. I tam też działa jeszcze więcej testów regresyjnych, ale pisanych już przez testerów, nie programistów. Tak więc, w ogóle Twoje definicje nie przystają do moich realiów.

@Silv: Ty piszesz o jednostkach organizacji kodu. Tymczasem w testach jednostkowych nie chodzi wcale o testowanie organizacji kodu, ale jego zachowania.

Silv

@somekind: nie słyszałem o takim podziale (albo mi umknął). Możesz rozwinąć?

somekind

O ile dobrze zrozumiałem te Twoje słowa: dla mnie "obiekt" (=klasa) z definicji jest odrębną jednostką. Może oczywiście należeć do większej jednostki – przestrzeni nazw czy modułu., to widzę, że skupiasz się na organizacji kodu: jego podziale na funkcje, metody, klasy, moduły, przestrzenie nazw. Tymczasem jednostki w sensie testowania, to nie są elementy organizacji kodu, tylko odrębne całości, które dostarczają jakiejś funkcjonalności. Nie ma znaczenia ile mają linii kodu, czy są funkcją, klasą czy modułem, ważne jest, czy robią coś niezależnego i wartego testowania.

Silv

Ach, to już rozumiem. Chyba. W takim razie... w takim razie odpowiada to definicji z Wikipedii (która także stara się wyjść poza organizację kodu). Ale nie wiem, jakby takie rozróżnienie miało wyglądać w praktyce... w tym programie i tak testuję jednostkowo tylko to, co ma dobrze zdefiniowane wejście i wyjście.

somekind

Tzn. ja się nie odnoszę do Twojego programu, nie zaglądałem nawet do kodu. Piszę ogólnie.

Silv
2019-08-05 02:23

Sukces. Udało mi się zmusić aplikację w Angularze do zwracania poprawnej odpowiedzi, i to dynamicznie, czy podany string jest poprawnym wyrażeniem nawiasowym.

To kwalifikuje się na news miesiąca.

Angular jednak nie jest taki zły.


UPDATE:

import { Component } from '@angular/core';
import { isBracketStringValidCounter } from "../../../../logic/validation-module/testable/is-bracket-string-valid-counter";

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  title = 'bracket-string-validator';
  input = "";
  valid = undefined;

  processInput(event) {
    this.input = `You have typed: ${JSON.stringify(event.target.value)}`;
    this.valid = `Is this a valid bracket string? — ${this.validateWebGui(event.target.value)}`;
  }

  validateWebGui(string) {
    return isBracketStringValidCounter(string);
  }
}

#angular #moja-nauka-angulara #web #front-end #bracket-string-validator #success

Silv

O, a jak ten wpis dodawałem, to nie kolorowało składni TypeScript...

Silv

Kolejny sukces: Angular obsługuje pole wyboru (combo box) element <select> (jeszcze nie dynamicznie).

Akihito

ok moje uwagi :D nie wiem czy wcześniej pisałeś w czymś silnie typowanym ale dobrze jest sobie potypować i ten kod przerobić na: https://4programmers.net/Pastebin/11330. poza tym zamiast rzucac eventami ( nie znam appki) mozna skorzystac z NgOnChanges by wykonywać metodę processInput za każdą zmainą inputu :)

Silv

@Akihito: dzięki. :) Ale na razie ten komentarz trafił w próżnię, bo walczę z tym, by się nie poddać, a nieznane mi rzeczy – m.in. TypeScript – omijam najszerszym łukiem, jakim się da...

Akihito

Jeśli pisałeś w językach silnie typowanych to TypeScirpt jest naturalną koleją rzeczy

Silv

@Akihito: pisałem, ale nie wiem, czy jest naturalną dla mnie koleją. Piszę w tym, co znam.

Silv

Udała mi się kolejna rzecz: Angular obsługuje dynamicznie element <select>.

Silv

@Akihito: Właśnie sobie próbuję TypeScript od dwóch dni... nie jest taki zły. Na razie jedyna większa przewaga nad JS, jaką widzę, to "bezpieczeństwo logiki kodu": jak podstawi się niewłaściwy typ / niewłaściwą zmienną, to kompilator zakrzyczy.

Silv

PS. Przypomniała mi się Java, jak zacząłem próbować opisywać typ funkcji z nawiasami trójkątnymi.

Silv
2019-07-23 18:18

To uczucie, gdy dodajesz instrukcję if w aplikacji, by rozwiązać problem – i pamiętasz, że kiedyś generowało to trzy błędy w trzech różnych plikach, a teraz działa od razu zgodnie z oczekiwaniami.

#rozwijam-sie

furious programming

A potem dodasz kolejną insrukcję if i wyskoczy BSoD. :D

Silv

PS. A powiem Ci, że mam tendencję do zmian. Jak widzę, że w celu naprawienia jakiegoś błędu można zmienić dwie linijki... ale w zasadzie lepiej będzie zmienić strukturę trzech plików, to chcę od razu te trzy pliki zmienić. Ale uczę się, że to niekoniecznie dobre.

WhiteLightning

@Silv: jak jest dobry bug, to te trzy nowe po naprawie dopiero na produkcji wyjda...

Silv
2019-07-19 17:57

#blog

Nowości na moim blogu silvuss-thoughts:

Bardzo chętnie przyjmę wszelkie oceny, recenzje i w ogóle komentarze zarówno odnośnie wpisu, jak i aplikacji.

Miłego czytania. :)


UPDATE: W artykule wspominam również o mojej nauce Angulara.

Seme

W tym wpisie na blogu nie wszystkie linki Ci działają.

Silv

PS. @Seme masz rację, zobaczę, co się da zrobić.

Silv

@Seme: już powinno być dobrze. Sprawdź.

Seme

Ok. Teraz działa dobrze.

Silv

Dzięki za zauważenie!

no_solution_found

jak idzie nauka Angulara? :D

Silv

@no_solution_found: jest zamrożona jak sanki Sknerusa McKwacza w lodowcu. ;) Planuję dodać pierwszą moją aplikację w nim jako interfejs do aplikacji bracket-string-validator, ale na razie to odległe plany. Nawet issue nie ma w tym temacie.

no_solution_found

tak myślałem :) życzę powodzonka!

no_solution_found

@silv jakie masz problemy z nauką angulara, że nie możesz zrobić nawet pierwszej apki?

Silv

@no_solution_found: Być może nie byłoby to takie trudne od strony technicznej, ale nie mam motywacji, by każdy błąd sprawdzać w dokumentacji. Denerwuje mnie ta technologia (trochę jak nowe języki programowania), bo nie widzę dla niej zastosowania.

Silv
2019-06-29 16:50

25. rocznica powstania PHP

Dziś się dowiedziałem: w tym roku mija 25 lat od powstania PHP. :)

PHP – a właściwie jego poprzednik, PHP/FI – zostało stworzone w 1994 roku przez Rasmusa Lerdorfa. Oprogramowanie PHP/FI (Personal Home Page/Forms Interpreter) zostało zaimplementowane w C i było używane początkowo przez Rasmusa do obsługi jego własnej strony internetowej. Więcej informacji o historii PHP można znaleźć na stronie https://php.net/manual/en/history.php.php

Obecnie skrótowiec "PHP" oznacza "PHP: Hypertext Preprocessor". Maskotką PHP jest elePHPant – niebieski (mniej-więcej) słoń z logo PHP na boku, zaprojektowany przez Vincenta Pontiera w 1998. Więcej ogólnych informacji o PHP można znaleźć na stronie https://en.wikipedia.org/wiki/PHP

Z tej okazji Rasmus przygotował cykl prezentacji, każda pod tytułem "25 Years of PHP". Wygląda na to (patrząc po materiałach), że jest tam mowa o historii programowania, początkach PHP, jego ekosystemie i kilku innych rzeczach. Tegorocznych prezentacji odbyło się do tej pory 8. Więcej informacji o tych oraz innych prezentacjach nt. PHP można znaleźć na stronie http://talks.php.net/index.php/PHP


Źródła:

furious programming

Hmm… stary już jest – czas najwyższy umrzeć. ;)

light

Ale PHP7 się ponoć odrodziło w 2014, gdy przepisali od nowa jego core. Zmiótł pod dywan swoją wydajnością wszystkie Nody, Pythony czy Ruby. Szkoda, że nie pozbyli się $ i ; jak w TypeScript.

ccwrc

@light: akurat $ bardzo poprawia czytelność, w językach bez dolarka musisz poświęcić większą ilość czasu na interpretację kodu (pomijam wersje przed 7.0 bez typowania wszystkiego)

Grzyboo

@ccwrc: Chyba żartujesz, od tego jest IDE

PerlMonk

@ccwrc: Nie. IDE to kompilator. Czasem do dziś mnie ludzie pytają w jakim kompilatorze pisałem apkę w Javie.

ccwrc

@PerlMonk: i co ten IDE w PHP kompiluje? ;)

czysteskarpety

W 7.4 będzie możliwość ustalenia typu właściwości klasy już na etapie jej opisywania, oraz nowy mechanizm preload, podobno wydajność wzrośnie do 50% i pozycja backendowego staruszka jeszcze się umocni, podejrzewam, że @TomRiddle dostanie zapaści :D

axelbest

@czysteskarpety no co Ty... Ci co nic nie robili w phpie, znowu będą wysyłać manifestly z 2012 roku :) I będą twierdzić że w phpie się nie programowac, bo dwie podobne funkcje maja inna kolejność parametrów. Wzrost wydajności? A na co to komu potrzebne?

ccwrc

Nie wiedziałem, że @TomRiddle to taki zajadły hejter PHP. Skąd w człowieku bierze się tyle nienawiści? W jaki okrutny sposób PHP go skrzywdziło w młodości? Czy ta głęboka rana zostanie kiedykolwiek zagojona? Niektórzy przez całe życie podsycają w sobie ogień wojny. I przez co? Przez znak dolara przed zmienną?

axelbest

Php touched him in the places where it smells funny :)

PerlMonk

@ccwrc: Kompiluje internety :D !

PerlMonk

@ccwrc: Odnośnie znaku dolara: niejedna wojna przez ten znak została poczyniona.

ccwrc

@PerlMonk Nie wiem, czy to najwłaściwsze miejsce do dyskusji o ropie naftowej...

no_solution_found

jak idzia nauka angulara?

Silv

@no_solution_found: dzięki, właśnie próbuję wdrożyć się do pierwszej aplikacji. Ale jeszcze zanim to opiszę, opublikuję kolejną część bardziej teoretyczną.

somedev

@furious programming: mówisz, że czas umierać a nad morsem najłatwiej się człowiek do piachu przyzwyczaja ;)

furious programming

@somedev: w takim razie trzeba nad morze wysłać PHP, a nie mnie. :P

Silv
2019-06-14 18:41

Hej, PHP-owcy i ogólnie ludzie związani z programowaniem!

Szukam PHP-owców oraz wszystkich chętnych do skończenia/dokończenia zadań (issues) na GitHubie silnika Coyote (czyli naszego forum).

Dlaczego taka inicjatywa? Zdenerwowało mnie, że ciągle tylko dodaje się nowe wątki "do zrobienia" na naszym forum (vide kategoria Coyote) czy nowe issues na GitHubie, a nie ma ludzi, którzy by to robili. :/ @Adam Boduch robi, co może, ale jedna osoba...

Tutaj post, w którym wpadłem na ten pomysł.

Tutaj wątek, w którym wszystko opisuję w szczegółach.

Jeśli ktoś ma jakiekolwiek pytania lub uwagi odnośnie tej inicjatywy, niech pisze komentarze do tego wpisu, albo w podanym wyżej wątku – posty lub komentarze. Można też pisać bezpośrednio do mnie, ale uprzedzam, że mogę nie mieć możliwości odpowiedzieć szybko.

AMD64

Trzeba znać PHP 7.4?

Silv

@AMD64: nie mam pojęcia, nie przeglądałem kodu, a ponadto nie znam się na PHP. @Adam Boduch, pomożesz?

Silv

PS. Adam, jakby co, postaram się Cię nie wzmiankować za często, żeby Ci więcej pracy tą pomocą nie zapewnić niż bez niej. :P

no_solution_found

szukasz kogoś, by ktoś zaczął pracować nad coyote? To sam zacznij :)

Silv

@no_solution_found: napisałem przecież powody, dla których tego nie zrobię obecnie.

no_solution_found

@Mimik59: tak działa cały opensource. Hosting i domena kosztuje. Plus czas na moderacji itp. Gdyby nie to to tego forum mogło by nie być

no_solution_found

Ja jestem na forum od lat i nigdy bana nie dostałem. Może nie jest problem w moderatorze?

Mimik59

No chyba nie jeden miał tu problem ze świniakiem.

no_solution_found

Jak to jest ze moderatorzy się upieraja na niektórych użytkowników a na niektórych nie? Ciekawe co ich motywuje... Może ich losuja i mi po prostu się poszczescilo? :p jak się przyglądam to w lwiej części winni są sami użytkownicy

Mimik59

Pewnie na takiej samej zasadzie jak się wybiera ofiarę w podstawówce albo przedszkolu, żeby mu trochę po dokuczać.

Mimik59

Zresztą nawet nie chcę się zastanawiać, co oni mają w głowie.

no_solution_found

Serio? Myślisz że się uparl bo dla sportu lub zabawy?

Mimik59

Przeczytaj sobie jakąś książkę o socjologi tam masz wszystko wytłumaczone.

no_solution_found

Rozjasn mnie zamiast dając oskarżenia bez dowodów

Silv
2019-06-08 22:11

[ Moja nauka Angulara 7, wpis nr 4 – część 3/3 ]

Ten wpis należy do serii wpisów o mojej nauce Angulara 7.

Tu można zobaczyć poprzedni wpis z tej serii: [ Moja nauka Angulara 7, wpi...

Tutaj można zobaczyć wpis nr 1, w którym opisałem całość przedsięwzięcia w szczegółach: [ Moja nauka Angulara 7, wpi...

Jak zawsze, proszę o wypunktowanie wszelkich błędów oraz literówek (a także ewentualne recenzje, jakby ktoś miał ochotę). Może to być w komentarzach albo w wiadomości prywatnej. :)

Rekapitulacja już opisanej nauki

Do tej pory opisałem:

  • zgodnie z planem:
    • plan mojej nauki,
    • początkową wersję listy głównych źródeł materiałów (szybko stała się nieaktualna, ale nadal można zobaczyć tę wersję tutaj);
  • lekko niezgodnie z planem:
    • pierwszą część nauki podstaw podstaw;
    • drugą część nauki podstaw podstaw;
    • pierwszą część poznawania struktury początkowej aplikacji szkieletowej Angulara;
    • drugą część poznawania struktury początkowej aplikacji szkieletowej Angulara.

W tym wpisie, także lekko niezgodnie z planem, postaram się opisać trzecią i ostatnią część mojego poznawania struktury początkowej aplikacji szkieletowej (w dokumentacji: initial skeleton application) Angulara.

Plan przewidywał opisanie najważniejszych zagadnień, na jakie trafię. Jednak uznałem, że nie znając prawie w ogóle Angulara będzie trudno, i że należy jakoś zapoznać się z nim w inny sposób. Być może opis struktury początkowej aplikacji szkieletowej będzie mógł mi służyć jako wstęp do dowiedzenia się, które zagadnienia są najważniejsze.

Finalnie okazało się też, że muszę podzielić ten wpis na trzy wpisy.

W tym wpisie będę korzystać głównie z dokumentacji Angulara. W przypadkach korzystania z innych źródeł będę wzmiankować ich nazwy/linki/itp.

Struktura początkowej aplikacji szkieletowej Angulara, część 2/3

Spis treści

  • Folder {nazwa projektu}/src

Folder {nazwa projektu}/src

Dotyczy: aplikacji root-level application.

Zawiera: pliki źródłowe aplikacji root-level application.

  • Podfoldery (opisy w poszczególnych sekcjach poniżej):
    • app
    • assets
    • environments
  • Pliki:
    • Pliki wykorzystywane, utworzone lub definiowane przez narzędzia lub projekty zewnętrzne w stosunku do Angulara:
      • browsersList – jest częścią projektu Browserslist. Zawiera konfigurację target browser i ułatwia współdzielenie tej konfiguracji między różnymi narzędziami używanymi na front-endzie (np. Autoprefixer oraz eslint-plugin-compat). Więcej informacji w dokumentacji projektu Browserslist na GitHubie.
      • tslint.json – zawiera konfigurację narzędzia TSLint dla aplikacji root-level application.
      • tsconfig.app.json – zawiera konfigurację TypeScripta dla aplikacji root-level application. Więcej informacji o konfiguracji TypeScripta w dokumentacji Angulara do niej.
      • tsconfig.spec.json – zawiera konfigurację TypeScripta dla testów aplikacji root-level application (ale jakich?). Więcej informacji o konfiguracji TypeScripta w dokumentacji Angulara do niej.
    • Pliki wykorzystywane, utworzone oraz definiowane przez Angulara oraz projekty powiązane:

Więcej informacji o tym folderze: dokumentacja tego folderu na stronie Angulara.

Folder {nazwa projektu}/src/app

Dotyczy: aplikacji root-level application.

Zawiera: logikę oraz dane aplikacji root-level application (ale co dokładnie?).

  • Podfoldery (opisy w poszczególnych sekcjach poniżej): (brak)
  • Pliki:
    • Pliki wykorzystywane, utworzone oraz definiowane przez Angulara oraz projekty powiązane:
      • app.component.css – według dokumentacji Angulara zawiera "the base CSS stylesheet for the root AppComponent" (ale co to znaczy?).
      • app.component.html – zawiera szablon HTML komponentu AppComponent, czyli tzw. komponentu głównego (w dokumentacji: root component) aplikacji root-level application.
      • app.component.spec.ts – zawiera testy (czy jeden test?) dla komponentu AppComponent.
      • app.component.ts – zawiera logikę komponentu AppComponent.
      • app.module.ts – zawiera AppModule, czyli tzw. moduł główny (w dokumentacji: root module) aplikacji root-level application. (Modułem głównym może być każdy inny moduł, jak jest opisane w tym artykule na Medium.)

Więcej informacji o tym folderze: dokumentacja tego folderu na stronie Angulara.

Folder {nazwa projektu}/src/assets

Dotyczy: aplikacji root-level application.

Zawiera: zasoby programu, takie jak obrazy; zostaną one skopiowane as-is podczas budowania aplikacji.

  • Podfoldery (opisy w poszczególnych sekcjach poniżej): (brak)
  • Pliki:
    • Pliki wykorzystywane, utworzone oraz definiowane przez Angulara oraz projekty powiązane:
      • .gitkeep – umieszczenie tego pliku w folderze assets jest obejściem mechanizmu Gita. Mechanizm ten to nieśledzenie pustych folderów. Umieszczenie w pustym folderze pustego pliku spowoduje, że folder ten będzie śledzony przez Gita. Może on się nazywać .gitkeep lub jakkolwiek inaczej, nie musi też być pusty. Istotna jest sama jego obecność w (uprzednio) pustym folderze. Więcej informacji w tym wątku na Stack Overflow.

Folder {nazwa projektu}/src/environments

Dotyczy: aplikacji root-level application.

Zawiera: konfiguracje budowania aplikacji root-level application dla różnych środowisk docelowych.

  • Podfoldery (opisy w poszczególnych sekcjach poniżej): (brak)
  • Pliki:
    • Pliki wykorzystywane, utworzone oraz definiowane przez Angulara oraz projekty powiązane:
      • environment.prod.ts – zawiera konfigurację budowania dla środowiska prod (skrót od ang. production).
      • environment.ts – zawiera konfigurację budowania dla nienazwanego środowiska tzw. standard development environment.

Rekapitulacja

W tym wpisie przedstawiłem trzecią i ostatnią część mojego poznawania struktury początkowej aplikacji szkieletowej Angulara. Opisałem w nim folder {nazwa projektu}/src.

Dla porządku: wpis jest niezgodny z planem przedstawionym we wpisie nr 1. Plan w ogóle nie przewidywał tego wpisu.

Do zobaczenia!

#moja-nauka-angulara

czysteskarpety

To co ty właściwie zrobiłeś przez ten miesiąc? :)

no_solution_found

@czysteskarpety opisał to co możesz znaleźć na pierwszym lepszym wiki o angularze, bądź "domyślić się" z nazw folderów :D przez miesiąc nie zrobił nic oprócz mówieniu o tym, że będzie się uczyć :) w ciągu miesiąca zrobiłby spokojnie panel logowania z odpytywaniem backendu o to czy login/hasło jest poprawne + plus jakieś proste menu z nawigacją strona domowa/logowanie/rejestracja/wylogowanie/strona-statyczna :) ja takie coś zrobiłem w dwa wieczory :P

Silv

Robię tak szybko, jak mogę. Spokojnie. ;) Chcę się tego uczyć tak, jak umiem się uczyć. Dzięki za śledzenie wpisów, to na pewno motywuje. :)

Silv

PS. @czysteskarpety jeszcze nie ma miesiąca, około 3 tygodnie.

no_solution_found

@Silv: ja mówię serio - pisz konkretny projekt i zbieraj feedback z kodu, który napisałeś. Metoda, którą wybrałeś jest wielce nieefektywne. Poświęciłeś miesiąc by zrozumieć strukturę katalogów, zanim zrobisz deploy pierwszej dynamicznej aplikacji to minie z rok, bo będziesz musiał przeszukać wszystkie możliwe materiały o komponentach, przesyłaniu stanu w angularze między komponentami, formularze, dostępne klasy i ich zastosowanie, dobre i złe praktyki, możliwe sposoby dzielenia aplikacji na moduły, dobre praktyki co do pisania modułów, clean code, w między czasie wyjdzie z 5 nowszych wersji angulara, gdzie trzeba będzie przeanalizować co nowego, czy nie zmienia to czegoś z tego co już wcześniej napisałeś i tak dalej i tak dalej... Robisz wszystko by się nie uczyć. Serio. programowania uczysz się przez praktykę. Podobnie jak z pływaniem. Wygeneruj projekt, wrzuć na githuba, pochwal się, zrób Issue na GH z rzeczami, które planujesz zrobić i zacznij od tego, który zajmie Ci najmniej czasu. Wrzuć kod z PR na mikrobloga i zbierz feedback. Są tu na pewno wyjadacze, którzy z praktycznego punktu widzenia powiedzą Ci co zrobić lepiej i dlaczego, wrzucą link do dokumentacji czy zrobią jakieś fiddle z przykładem jak to zrobić inaczej/lepiej.

no_solution_found

poza tym - Twój plan będzie się rozjeżdżać z biegiem czasu :)

Silv

@no_solution_found: zgadzam się. A z drugiej strony: nie zgadzam się. Ja jestem inny. Chciałbym, żeby tak nie było w jakiejś części, ale jest, jak jest. Analizę matematyczną miałem przez kilka semestrów na dwóch poziomach studiów i nadal niewiele z niej rozumiem – nie uczyłem się swoim sposobem, bo "nie było czasu" (co po części było prawdą). Mam dość nauki polegającej na zbieraniu wymagań, kodzeniu i zapominaniu. Można tak działać w pracy, jeśli ktoś każe, ale jaki zysk byłby dla mnie osobiście? Co mi przyjdzie z projektu na GH, jeśli nie będę wiedzieć, dlaczego działa tak, jak działa? Albo jeśli zapomnę, jak go zrobić, po miesiącu – bo robiłem zgodnie z samouczkami?

no_solution_found

ale Ty to właśnie robisz - będziesz się uczyć masy rzeczy, których teraz i tak nie potrzebujesz i za jakiś czas o tym zapomnisz. To nie są studia. Ucz się poprzez praktykę. Jeśli coś zapomnisz, to znaczy że nie używałeś :) więc potrzebne Ci nie było. Jeśli trafisz na jakiś problem, to wtedy szukaj rozwiązania i odpowiedz sobie na pytanie "a dlaczego akurat tak" albo "czy można to zrobić inaczej". Ucz się myślenia problem-> rozwiązanie. Styknij się z konkretnymi problemami (w jaki sposób przekazywać stan między komponentami, jak zrobić by ładowało się wszystko jak najszybciej, jak zużyć jak najmniej zasobów itp). Wylisotwanie wszystkich plików w projekcie niewiele Ci da. A spróbuj na przykład zrobić własny komponent, który odpowiada za jakąś logikę (np. obsługę "Koszyka" [dodawanie elementów, obsługę błędów, walidacja danych wejściowych]), zaplanuj jakbyś podzielił tę część aplikacji na mniejsze części, wczytuj i zapisuj dane do localstorage i pochwal się tym komponentem. To są zadania, które będziesz robić na codzień w pracy. Nie nauka dla nauki. Architektura + testy + clean code - to się liczy a nie znajomość wszystkiego co się rusza :P Praktyka to klucz

no_solution_found

zobacz co zrobił choćby Disclaimer Mało wiem o RE. J... - przedstawił garść teorii i w sposób praktyczny opisał i pokazał co to znaczy na konkretnym przykładzie :)

Silv

@no_solution_found: jeśli chodzi przedstawioną przez Ciebie o praktykę w pracy, mam własne zdanie na ten temat. Dziękuję, że Ci się chce mnie przekonywać (może kiedyś mnie przekonasz, ale oczywiście nie potrafię powiedzieć, kiedy). Poza główną kwestią rozumienia jest też poboczna kwestia niechęci. Wcale nie chce mi się uczyć Angulara. Mam wrażenie, że część rzeczy z jego ekosystemu jest sztuką dla sztuki, może właśnie sam trochę tak traktuję swoją naukę. Jeśli zrozumiem, jak działa, po co i dlaczego, może jakoś przebrnę przez podstawy. Co do wpisu, nie będę go czytać (na razie?), bo jednak wolę przeznaczyć ten czas na Angulara.

no_solution_found

no właśnie widać to, że nie chcesz się go nauczyć. Co do samego angulara, to pamiętaj, że on ma rozwiązać jakiś konkretny problem. Często takie "sztuka dla sztuki" okazuje się nie głupie jak masz już sporą aplikację z setkami komponentów, czy nawet tysiącami. Wtedy niektóre rzeczy, które wcześniej wydawały się zbędne teraz dupe Ci ratują :) Jak chcesz zrobić prostą aplikację, to albo reactjs albo nawet w ...jQuery to ogarniesz :D jak masz pytania, to pisz, czy na forum czy nawet na mikroblogu

Silv

< wraca do Angulara, bo im szybciej dokończy naukę, tym lepiej >

Silv
2019-06-08 22:11

[ Moja nauka Angulara 7, wpis nr 4 – część 2/3 ]

Ten wpis należy do serii wpisów o mojej nauce Angulara 7.

Tu można zobaczyć poprzedni wpis z tej serii: [ Moja nauka Angulara 7, wpi...

Tutaj można zobaczyć wpis nr 1, w którym opisałem całość przedsięwzięcia w szczegółach: [ Moja nauka Angulara 7, wpi...

Jak zawsze, proszę o wypunktowanie wszelkich błędów oraz literówek (a także ewentualne recenzje, jakby ktoś miał ochotę). Może to być w komentarzach albo w wiadomości prywatnej. :)

Rekapitulacja już opisanej nauki

Do tej pory opisałem:

  • zgodnie z planem:
    • plan mojej nauki,
    • początkową wersję listy głównych źródeł materiałów (szybko stała się nieaktualna, ale nadal można zobaczyć tę wersję tutaj);
  • lekko niezgodnie z planem:
    • pierwszą część nauki podstaw podstaw;
    • drugą część nauki podstaw podstaw;
    • pierwszą część poznawania struktury początkowej aplikacji szkieletowej Angulara.

W tym wpisie, także lekko niezgodnie z planem, postaram się opisać drugą z trzech części mojego poznawania struktury początkowej aplikacji szkieletowej (w dokumentacji: initial skeleton application) Angulara.

Plan przewidywał opisanie najważniejszych zagadnień, na jakie trafię. Jednak uznałem, że nie znając prawie w ogóle Angulara będzie trudno, i że należy jakoś zapoznać się z nim w inny sposób. Być może opis struktury początkowej aplikacji szkieletowej będzie mógł mi służyć jako wstęp do dowiedzenia się, które zagadnienia są najważniejsze.

Finalnie okazało się też, że muszę podzielić ten wpis na trzy wpisy.

W tym wpisie będę korzystać głównie z dokumentacji Angulara. W przypadkach korzystania z innych źródeł będę wzmiankować ich nazwy/linki/itp.

Struktura początkowej aplikacji szkieletowej Angulara, część 2/3

Informacja: Foldery oraz pliki zostały przedstawione w kolejności, w jakiej są one wypisywane w terminalu za pomocą polecenia ls -la przy kodowaniu systemowym en_US.UTF-8. Jest to kolejność alfabetyczna dla alfabetu angielskiego, z tym, że ewentualna początkowa kropka w nazwie pliku jest ignorowana (tj. nazwa pliku jest umieszczana na takim miejscu na liście, na jakim byłaby, gdyby nie zaczynała się od kropki).

Spis treści

  • Folder {nazwa projektu}/e2e

  • Folder {nazwa projektu}/.git

  • Folder {nazwa projektu}/node_modules

Folder {nazwa projektu}/e2e

Dotyczy: aplikacji root-level application.

Zawiera: pliki źródłowe oraz konfiguracyjne testów end-to-end tej aplikacji.

  • Podfoldery (opisy w poszczególnych sekcjach poniżej):
    • src
  • Pliki:
    • Pliki wykorzystywane, utworzone oraz definiowane przez Angulara oraz projekty powiązane:
      • protractor.conf.js – wydaje się być częścią, a na pewno jest powiązany z frameworkiem do testów end-to-end Protractor (framework ten jest powiązany z Angularem). Zawiera konfigurację tego frameworka.
      • tsconfig.e2e.json – ?. W aktualnej dokumentacji Angulara ten folder wydaje się nazywać tsconfig.json.

Więcej informacji o testach end-to-end: 1) to hasło Techopedii, 2) to hasło TechTarget.

W przypadku gdy przestrzeń robocza zawiera wiele projektów, ten folder (tzn. {nazwa projektu}/e2e) umieszczony jest w folderze {nazwa przestrzeni roboczej}/projects/.

Folder {nazwa projektu}/e2e/src

Dotyczy: aplikacji root-level application.

Zawiera: pliki źródłowe testów end-to-end aplikacji root-level application.

  • Podfoldery (opisy w poszczególnych sekcjach poniżej): (brak)
  • Pliki:

Folder {nazwa projektu}/.git

Dotyczy: ?

Zawiera: pliki konfiguracyjne systemu kontroli wersji Git.

  • Podfoldery (opisy w poszczególnych sekcjach poniżej): (zawartość folderu .git opisana jest w dokumentacji Gita; patrz link poniżej)
  • Pliki: (zawartość folderu .git opisana jest w dokumentacji Gita; patrz link poniżej)

Więcej informacji o tym folderze: ten artykuł w dokumentacji Gita.

Folder {nazwa projektu}/node_modules

Dotyczy: całej przestrzeni roboczej.

Zawiera: pakiety npm zainstalowane dla całej przestrzeni roboczej.

  • Podfoldery (opisy w poszczególnych sekcjach poniżej): (zawartość folderu node_modules opisana jest w dokumentacji npm; patrz link poniżej)
  • Pliki: (zawartość folderu node_modules opisana jest w dokumentacji npm; patrz link poniżej)

Więcej informacji o tym folderze: dokumentacja tego folderu na stronie npm.

(A co w przypadku yarna?)

Rekapitulacja

W tym wpisie przedstawiłem drugą z trzech części mojego poznawania struktury początkowej aplikacji szkieletowej Angulara. Opisałem foldery {nazwa projektu}/e2e, {nazwa projektu}/.git oraz {nazwa projektu}/node_modules.

W kolejnej części opiszę folder src.

Dla porządku: wpis jest niezgodny z planem przedstawionym we wpisie nr 1. Plan w ogóle nie przewidywał tego wpisu.

Do zobaczenia!

#moja-nauka-angulara