Co pisać żeby się nauczyć?

0

Witajcie, mam takie pytanie.
Uczę się od jakiegoś czasu JS. Chcę się w tym rozwijać ale nie mam pojęcia co pisać, żeby rozwijać swoje umiejętności.
Składnia, algorytmy itd nie są dla mnie problemem ale bardziej struktura aplikacji które miałbym pisać.
Nie wiem po prostu jak coś większego napisać, żeby nie było to tak zwanym "tasiemcem".

0

Sam JS to za mało. Jeżeli znasz w podstawowym zakresie JS to doucz się teraz jQuery, CSS i jakiegoś frameworka do niego np. Bootstrap albo Fundation i zacznij robić jakieś layouty stron (HTML zakładam, że znasz). Potem można pomyśleć nad doborem jakiejś technologii do backendu.

0

Zacznij od tego co modne w tutorialach dla wybranych frameworków/bibliotek, czyli lista zadań do zrobienia. Potem może blog, forum, tablica z ogłoszeniami, przedstawianie statystyk w formie wykresów, jakieś gry? Oczywiście nie będą to pełnoprawne serwisy, bo samemu ciężko o to, ale i tak nauczysz się wielu rzeczy.

Jak nie masz pomysłów to "kopiuj" istniejące aplikacje, dorzucaj coś od siebie.

0
Code Faster napisał(a):

Sam JS to za mało. Jeżeli znasz w podstawowym zakresie JS to doucz się teraz jQuery, CSS i jakiegoś frameworka do niego np. Bootstrap albo Fundation i zacznij robić jakieś layouty stron (HTML zakładam, że znasz). Potem można pomyśleć nad doborem jakiejś technologii do backendu.

HTML5/CSS3 znam dobrze a nawet czuję się w nich bardzo dobrze.
Chodzi mi o to jakiego typ aplikacje mogę zacząć ćwiczyć/pisać, żeby starać się o stanowisko poważnego front end'owca.
To że zrobię sobie animację w js/jquery czy jakiś slider albo inne walidacje formularzy to nie czyni mnie 'specem' od js. Chodzi mi o poważniejsze apki. I z tym właśnie jest problem, co to to mogłyby być?
Docelowo chcę iść w angulara. Ale widzę, że wszędzie mile widziane są gulpy/grunty i inne rzeczy których obecnie nie mam gdzie używać i nie wiem do jakich projektów się nadają a do jakich nie.

1
Wielki Ogrodnik napisał(a):
Code Faster napisał(a):

Sam JS to za mało. Jeżeli znasz w podstawowym zakresie JS to doucz się teraz jQuery, CSS i jakiegoś frameworka do niego np. Bootstrap albo Fundation i zacznij robić jakieś layouty stron (HTML zakładam, że znasz). Potem można pomyśleć nad doborem jakiejś technologii do backendu.

HTML5/CSS3 znam dobrze a nawet czuję się w nich bardzo dobrze.
Chodzi mi o to jakiego typ aplikacje mogę zacząć ćwiczyć/pisać, żeby starać się o stanowisko poważnego front end'owca.
To że zrobię sobie animację w js/jquery czy jakiś slider albo inne walidacje formularzy to nie czyni mnie 'specem' od js. Chodzi mi o poważniejsze apki. I z tym właśnie jest problem, co to to mogłyby być?
Docelowo chcę iść w angulara. Ale widzę, że wszędzie mile widziane są gulpy/grunty i inne rzeczy których obecnie nie mam gdzie używać i nie wiem do jakich projektów się nadają a do jakich nie.

Gulp i podobne nadają się do każdego projektu, gdy robisz coś więcej niż tylko statyczną stronę http://survivejs.com/j ma sens, to tylko narzędzia, które automatyzują Twoją pracę, np. łączą ze sobą pliki, minifikują kod, oczyszczają go, ogarniają style (LESS/SASS/Scss/CSS Modules itp.) i pare innych rzeczy. Teraz na czasie jest Webpack, tu masz fajną książkę jednego z jego twórców, która znacznie ułatwia zrozumienie tego co się tam dzieje.

0
Pietruch napisał(a):

Zacznij od tego co modne w tutorialach dla wybranych frameworków/bibliotek, czyli lista zadań do zrobienia. Potem może blog, forum, tablica z ogłoszeniami, przedstawianie statystyk w formie wykresów, jakieś gry? Oczywiście nie będą to pełnoprawne serwisy, bo samemu ciężko o to, ale i tak nauczysz się wielu rzeczy.

Jak nie masz pomysłów to "kopiuj" istniejące aplikacje, dorzucaj coś od siebie.

Miałem w sumie pomysł wyciągać statystyki z pewnej gry, której strona oparta jest o REST API, udało mi się nawet w php wysyłać odpowiednie nagłówki http i otrzymywać interesujące mnie dane w JSON.
A czy jest opcja żeby w czystym JS albo jQuery wysyłać zapytania pod dane adresy i pobierać te JSON'Y? Czy tak się powinno budować tego typu aplikację czy własnie lepiej backend trzymać w php?

0

A czy jest opcja żeby w czystym JS albo jQuery wysyłać zapytania pod dane adresy i pobierać te JSON'Y?

Można, o ile serwer strony na to pozwala (ma odpowiedno ustawione CORSy). W razie czego możesz podpiąć się pod jedno z ogólnodostępnych API wylistowanych tutaj:
https://github.com/toddmotto/public-apis
lub tutaj:
https://github.com/abhishekbanthia/Public-APIs

Ogólnie taka apka wykorzystująca zewnętrzne API to bardzo dobre ćwiczenie.

PS
Nie przywiązuj się do jQuery, większa aplikacja w jQuery to z definicji spaghetti code.

0
Wielki Ogrodnik napisał(a):

A czy jest opcja żeby w czystym JS wysyłać zapytania pod dane adresy i pobierać te JSON'Y?

Można: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

0

Czy znacie jakieś ebooki, kursy do ECMAscript 6? Dlaczego tak mało książek na helionie wychodzi w tym nowym standardzie, nie przyjął się, nikt go nie lubi czy jak.

0

ES6 to cały czas ten sam javascript. Doszło kilka nowych rzeczy, ale nie na tyle, żeby wydac o tym książkę.
Poza tym zanim ktoś coś przetłumaczy na polski i znajdzie sie to na helionie to będzie już ECMAscript 99999.
To Ci wystarczy http://es6-features.org/

Mogę od siebie polecić jeszcze https://www.udemy.com/javascript-es6-tutorial/?couponCode=1RBEF202 <- z tym kodem 10$

0

Nie wiem po prostu jak coś większego napisać, żeby nie było to tak zwanym "tasiemcem".

Zacznij od dzielenia programy na małe moduły (najlepiej nie więcej niż 50-300 linijek kodu, ale to jest względne. Po prostu tak, żebyś otwierając plik orientował się co się tam dzieje - no i przeczytaj wypowiedź @Maciej Cąderek niżej). Będziesz musiał korzystać jeszcze z jakiegoś Browserify albo Webpacka, które zamienią wiele plików z modułami na jeden plik, który sobie potem zaciągniesz przez stronę.

Docelowo chcę iść w angulara. Ale widzę, że wszędzie mile widziane są gulpy/grunty i inne rzeczy których obecnie nie mam gdzie używać i nie wiem do jakich projektów się nadają a > do jakich nie.

Trochę historii: pisząc większe aplikacje często programiści musieli uruchamiać jakieś komendy w linii poleceń, np. musieli odpalić proces kompilacji albo kopiowania plików wynikowych z jednego do drugiego katalogu. Żeby nie pisać tego z ręki ciągle, to wymyślili, że założą sobie jeden plik do tego ten plik o nazwie Makefile podzielą ten plik na odpowiednie sekcje, np. (plik wzięty z repozytorium biblioteki Babel) :
https://github.com/babel/babel/blob/master/Makefile

build: clean
	./node_modules/.bin/gulp build

build-dist: build
	cd packages/babel-polyfill; \
	scripts/build-dist.sh
	cd packages/babel-runtime; \
	node scripts/build-dist.js
	node scripts/generate-babel-types-docs.js
watch: clean
	rm -rf packages/*/lib
	./node_modules/.bin/gulp watch
lint:
	./node_modules/.bin/eslint packages/ --format=codeframe

flow:
	./node_modules/.bin/f

jak widać masz plik podzielony na sekcje build, lint, watch i każda z tych sekcji uruchamia jakieś komendy. Każda z tych komend "coś robi" z plikami projektu.

No ale ten sposób pisania i narzędzie Make jest dość stare, bo w latach 70 powstało, a JavaScriptowcy chcieli być modni i mieć własne narzędzia więc zrobili najpierw Grunta, a potem Gulpa i cała historia (a Grunt już odpadł więc w ogóle możesz sobie darować). W międzyczasie pojawił się Webpack, który różni się o tyle, że to jakby już zestaw gotowych skryptów, które wystarczy po prostu odpalić, pod warunkiem, że wyedytujesz plik konfiguracyjny i być moze będziesz musiał zainstalować jakieś paczki z NPM (jeśli miałeś do czynienia z Linuxem, to powinieneś zrozumieć jaka jest idea Webpacka, Grunta, Gulpa, NPM itp.)

Czyli generalnie stare idee w nowych piórkach.

1

Zacznij od dzielenia programy na małe moduły (najlepiej nie więcej niż 50-300 linijek kodu, ale to jest względne. Po prostu tak, żebyś otwierając plik orientował się co się tam dzieje).

Taka trochę z czapy ta rada - program należy dzieliś na moduły stosując SRP, ilość linii kodu w module to "efekt uboczny" takiego podejścia, a nie żadna reguła.

0
 Zacznij od dzielenia programy na małe moduły (najlepiej nie więcej niż 50-300 linijek kodu, ale to jest względne. Po prostu tak, żebyś otwierając plik orientował się co się tam dzieje).

Dobra rada. Ja mialem dzien probny w firmie, gdzie pliku mialy po 7 - 8K linijek kodu..i wszystko wymieszane, czyli php, html, js, jquery...koszmar. Zrezygnowalem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1