🚀 go-pugleaf

Dnia Mon, 30 Jul 2018 11:19:03 +0200, Roman Tyczka napisał(a):

>             "runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"

Nie znam tej aplikacji, ale jak dla mnie w powyższym brakuje Ci pełnej
ścieżki do node.exe

--
Borys Pogoreło
borys(#)leszno,edu,pl

On Mon, 30 Jul 2018 14:03:37 +0200, Borys Pogoreło wrote:

>>             "runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"
>
> Nie znam tej aplikacji, ale jak dla mnie w powyższym brakuje Ci pełnej
> ścieżki do node.exe

No widzisz, rzut oka praktyka i jestem krok dalej, dzięki :-)

Kolejne pytanie.
Mam skrypt, który korzysta z jQuery, w przeglądarce skrypty się "widzą"
wzajemnie, więc mój skrypt może się odwoływać do jQuery i z niego
korzystać, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
Masz pomysł jak to ominąć? Googluje i nic sensownego nie mogę osiągnąć.

ps. czy mógłbyś polecić inne środowisko do debugowania JS?

--
pozdrawiam
Roman Tyczka

Dnia Mon, 30 Jul 2018 14:44:52 +0200, Roman Tyczka napisał(a):

> Mam skrypt, który korzysta z jQuery, w przeglądarce skrypty się "widzą"
> wzajemnie, więc mój skrypt może się odwoływać do jQuery i z niego
> korzystać, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
> Masz pomysł jak to ominąć? Googluje i nic sensownego nie mogę osiągnąć.

Wszystko zależy od tego w jaki sposób sięgasz do jQuery i jak się do niej
później odwołujesz. W przeglądarce zapewne wrzucasz tę bibliotekę do
globalnej przestrzeni nazw (czy też raczej do obiektu window), w node jej
nie masz - musisz bibliotekę zaimportować i korzystać z tak stworzonej
zmiennej. Najlepiej wrzuć kawałek swojego kodu.

> ps. czy mógłbyś polecić inne środowisko do debugowania JS?

Chrome devtools ;) Zależy co chcesz uzyskać. Korzystasz z node, ale nie
wiem czy faktycznie chcesz budować aplikację node, czy tylko ten debugger
tak działa.

--
Borys Pogoreło
borys(#)leszno,edu,pl

On Tue, 31 Jul 2018 00:08:41 +0200, Borys Pogoreło wrote:

> Dnia Mon, 30 Jul 2018 14:44:52 +0200, Roman Tyczka napisał(a):
>
>> Mam skrypt, który korzysta z jQuery, w przeglądarce skrypty się "widzą"
>> wzajemnie, więc mój skrypt może się odwoływać do jQuery i z niego
>> korzystać, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
>> Masz pomysł jak to ominąć? Googluje i nic sensownego nie mogę osiągnąć.
>
> Wszystko zależy od tego w jaki sposób sięgasz do jQuery i jak się do niej
> później odwołujesz. W przeglądarce zapewne wrzucasz tę bibliotekę do
> globalnej przestrzeni nazw (czy też raczej do obiektu window), w node jej
> nie masz - musisz bibliotekę zaimportować i korzystać z tak stworzonej
> zmiennej. Najlepiej wrzuć kawałek swojego kodu.

Sprawa wygląda tak, mam serwer restowy (napisany w Delphi), teraz chcę się
do niego podłączyć z JS. W JS napisałem przy użyciu jQury swoją klasę
klienta tegoż serwera restowego, ta klasa jest w pliku TssClient.js i
chciałbym ją podebugować, potestować. Ale marzy mi się środowisko
zintegrowane do jakiego mnie przyzwyczaiło Delphi (czy nawet PHP), z
debugerem, wygodnym edytorem, etc. Dlatego po chwili googlowania wybrałem
VS Code, ale może to błąd.

>> ps. czy mógłbyś polecić inne środowisko do debugowania JS?
>
> Chrome devtools ;) Zależy co chcesz uzyskać. Korzystasz z node, ale nie
> wiem czy faktycznie chcesz budować aplikację node, czy tylko ten debugger
> tak działa.

Nie chcę aplikacji node tylko właśnie VS Code tak działa. Dlatego pytałem o
inne sensowne środowisko, które nie jest przeglądarką. Może czegoś takiego
po prostu nie ma?

ps. NodeJS ma coś takiego jak moduły i można podobnie jak w PHP stosować
funkcję require(), ale to wymaga po stronie inkludowanego skryptu
zarejestrowania exportu, a przecież nie dopiszę do jQuery tego.

https://www.w3schools.com/nodejs/nodejs_modules.asp

--
pozdrawiam
Roman Tyczka

Dnia Thu, 2 Aug 2018 14:35:33 +0200, Roman Tyczka napisał(a):

> Nie chcę aplikacji node tylko właśnie VS Code tak działa. Dlatego pytałem o
> inne sensowne środowisko, które nie jest przeglądarką. Może czegoś takiego
> po prostu nie ma?

Jest, jest. Skoro chcesz to zrobić tak, to możesz się po prostu podłączyć
pod debugger wbudowany w node. Większość IDE to zapewnia:

https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients

> ps. NodeJS ma coś takiego jak moduły i można podobnie jak w PHP stosować
> funkcję require(), ale to wymaga po stronie inkludowanego skryptu
> zarejestrowania exportu, a przecież nie dopiszę do jQuery tego.

Wiele pakietów jest dostosowanych do takiego użycia, w tym jQuery:

https://www.npmjs.com/package/jquery#node

--
Borys Pogoreło
borys(#)leszno,edu,pl

On Thu, 2 Aug 2018 20:36:29 +0200, Borys Pogoreło wrote:

>> Nie chcę aplikacji node tylko właśnie VS Code tak działa. Dlatego pytałem o
>> inne sensowne środowisko, które nie jest przeglądarką. Może czegoś takiego
>> po prostu nie ma?
>
> Jest, jest. Skoro chcesz to zrobić tak, to możesz się po prostu podłączyć
> pod debugger wbudowany w node. Większość IDE to zapewnia:
>
> https://nodejs.org/en/docs/guides/debugging-getting-started/#inspector-clients

Odpuszczam Node, to zbyt dla mnie zagmatwane i przerośnięte. Zwłaszcza, że
odkryłem iż VSCode pozwala jednak na "lokalne" debugowanie, trzeba w nim
doinstalować rozszerzenie debugera dla Chrome lub Firefoxa, odpalić tę
przeglądarkę z parametrem  --remote-debugging-port’22 i się podłączyć
edytorem do przeglądarki, która ma API od debugowania, wtedy można w miarę
wygodnie debugować kod w sensownym edytorze choć wykonuje się po stronie
przeglądarki. Ale lepsze to niż debugowanie w samej przeglądarce.

W sumie to mnie trochę dziwi, że najpopularniejszy język świata nie ma
jakichś prostych IDE z wbudowanym debugerem i całą otoczką narzędzi
developerskich tylko trzeba się tak gimnastykować.

>> ps. NodeJS ma coś takiego jak moduły i można podobnie jak w PHP stosować
>> funkcję require(), ale to wymaga po stronie inkludowanego skryptu
>> zarejestrowania exportu, a przecież nie dopiszę do jQuery tego.
>
> Wiele pakietów jest dostosowanych do takiego użycia, w tym jQuery:
>
> https://www.npmjs.com/package/jquery#node

No to już niepotrzebne i działa tak jak chciałem. Tymczasem kolejne
problemy i nowy wątek :-)

--
pozdrawiam
Roman Tyczka

Dnia Fri, 3 Aug 2018 14:29:40 +0200, Roman Tyczka napisał(a):

> W sumie to mnie trochę dziwi, że najpopularniejszy język świata nie ma
> jakichś prostych IDE z wbudowanym debugerem i całą otoczką narzędzi
> developerskich tylko trzeba się tak gimnastykować.

Cóż, jaki język, takie narzędzia ;)

--
Borys Pogoreło
borys(#)leszno,edu,pl

On Fri, 3 Aug 2018 15:30:45 +0200, Borys Pogoreło wrote:

> Dnia Fri, 3 Aug 2018 14:29:40 +0200, Roman Tyczka napisał(a):
>
>> W sumie to mnie trochę dziwi, że najpopularniejszy język świata nie ma
>> jakichś prostych IDE z wbudowanym debugerem i całą otoczką narzędzi
>> developerskich tylko trzeba się tak gimnastykować.
>
> Cóż, jaki język, takie narzędzia ;)

E, nie taki zły, podoba mi się jego ekspresja i elastyczność.
Mam fajną książkę "JS, mocne strony" Crockforda i koleś opisuje to co uważa
za udane i dobre w JS przestrzegając przed niedoróbkami i błędami w
implementacji standardu (błędy już w definicji). Bardzo fajna pozycja, z
dystansem i bez wychwalania.

--
pozdrawiam
Roman Tyczka

Dnia Fri, 3 Aug 2018 15:47:44 +0200, Roman Tyczka napisał(a):

>> Cóż, jaki język, takie narzędzia ;)
>
> E, nie taki zły, podoba mi się jego ekspresja i elastyczność.
> Mam fajną książkę "JS, mocne strony" Crockforda i koleś opisuje to co uważa
> za udane i dobre w JS przestrzegając przed niedoróbkami i błędami w
> implementacji standardu (błędy już w definicji). Bardzo fajna pozycja, z
> dystansem i bez wychwalania.

https://i.redd.it/h7nt4keyd7oy.jpg ;)

Jeszcze zapłaczesz nad tym językiem. Zacznij od razu uczyć się Typescriptu
- prosta rzecz, a przynajmniej mocno ograniczysz problemy wynikające z
niejawnych konwersji typów.

--
Borys Pogoreło
borys(#)leszno,edu,pl

On Fri, 3 Aug 2018 19:59:22 +0200, Borys Pogoreło wrote:

>> E, nie taki zły, podoba mi się jego ekspresja i elastyczność.
>> Mam fajną książkę "JS, mocne strony" Crockforda i koleś opisuje to co uważa
>> za udane i dobre w JS przestrzegając przed niedoróbkami i błędami w
>> implementacji standardu (błędy już w definicji). Bardzo fajna pozycja, z
>> dystansem i bez wychwalania.
>
> https://i.redd.it/h7nt4keyd7oy.jpg ;)

:-)
A ta druga cegiełka to... no, konkret widzę :-)

> Jeszcze zapłaczesz nad tym językiem. Zacznij od razu uczyć się Typescriptu
> - prosta rzecz, a przynajmniej mocno ograniczysz problemy wynikające z
> niejawnych konwersji typów.

Dlatego debuger jest mi tak bardzo potrzebny, wtedy wszystko widzę jak na
dłoni.
A propos TypeScripta, na czym polega jego użycie? To się potem jakoś
przekompilowuje do JS czy przeglądarki go też kumają? No i na jakim etapie
jest kontrola typów?

--
pozdrawiam
Roman Tyczka

On 04/08/2018 23:42, Roman Tyczka wrote:
[...]
> A propos TypeScripta, na czym polega jego użycie? To się potem jakoś
> przekompilowuje do JS czy przeglądarki go też kumają? No i na jakim etapie
> jest kontrola typów?

TypeScript tak naprawdę transpiluje się do ES5/ES6/ES6. Niemniej jednak
z własnego doświadczenia mogę napisać, że na dzień dzisiejszy wszystkie
projekty rozpoczynam w TypeScripcie.

Co najmniej kilka powodów:

* Pilnuje typów danych. To powoduje, że wiem jakiego typu danych się
spodziewam. Oczywiście, to działa tylko na etapie pisania kodu w
edytorze, bo jak napiszę:

example(status: boolean): void {
  this.status = status;
}

a REST API zwróci null to taka wartość będzie zapisana pod this.status.

* Znacznie lepsze możliwości refactoringu. Zmiana nazwy metody czy pliku
powoduje zmiany w całym kodzie.

* Definicje: interface, enum, return type, public, private, static, itd.

No i ważna rzecz: możesz mieszać swobodnie TypeScript i JavaScript!

Jeszcze 1 rok temu byłem stosunkowo sceptycznie nastawiony do
TypeScriptu, ale dziś polecam go każdemu. Spróbuj, sam ocenisz po jakimś
czasie.

--
Cezary Tomczyk
http://www.ctomczyk.pl/
https://www.aslint.org/

Dnia Sat, 4 Aug 2018 22:42:11 +0200, Roman Tyczka napisał(a):

> A propos TypeScripta, na czym polega jego użycie? To się potem jakoś
> przekompilowuje do JS czy przeglądarki go też kumają?

Tak, musisz go przekształcić do standardowego JS. I z tym niestety musisz
się pogodzić - jakiekolwiek wyjście poza ramy "standardowego" JS oznacza
włączenie osobnego procesu transpilacji. Nieważne czy to będzie
TypeScript/CoffeScript, czy też cały framework typu React czy choćby użycie
kodu ES6 - czeka Cię nauka gulp / webpack / rollup (a do tego npm / yarn +
babel).

Co do samego TS - są metody na użycie go bezpośrednio w przeglądarce, ale
to bardziej w celu ułatwienia pisania i testowania kodu, niż użycia na
produkcji.

--
Borys Pogoreło
borys(#)leszno,edu,pl

On Sun, 5 Aug 2018 14:59:59 +0200, Borys Pogoreło wrote:

> włączenie osobnego procesu transpilacji. Nieważne czy to będzie
> TypeScript/CoffeScript, czy też cały framework typu React czy choćby użycie
> kodu ES6 - czeka Cię nauka gulp / webpack / rollup (a do tego npm / yarn +
> babel).

Poczytałem o tym... włosy stają dębą... to jest tak pokręcone i
przekombinowane, że podziwiam tych, co w tym się sprawnie poruszają.

Już sama idea całego procesu jest kuriozalna z punktu widzenia
"klasycznego" programowania. Piszę w nieistniejącym języku, likwidującym
wady JS czyli w TypeSripcie, potem konwertuję to do JS, a potem tegoż JS
konwertuję do ...ups... także JS ale starego, bo nie wszystkie przeglądarki
kumają nowe wersje. Jednocześnie używam podobnych patentów przy CSS. A żeby
jeszcze móc odnaleźć błąd występujący w środowisku produkcyjnym (w starym
JS lub CSS!) muszę sobie zmapować mój kod w TS na JS za pomocą Source Maps!
Ponadto całe środowisko pracy i wszystkie narzędzia opierają się o NodeJS,
bo ...nie wiem czemu. I każde z narzędzi ma inną konfigurację zapisaną w
plikach JSONowych w dziesiątkach katalogów.
Oczywiście każde narzędzie ma kilka odpowiedników z rzeszą zwolenników i
każdy developer używa innego zestawu narzędzi, z innymi parametrami, innymi
zachowaniami, innymi wadami i zaletami. Ufff...

To wszystko brzmi jak sen wariata i ogarnięcie wymaga pewnej formy autyzmu
:-)
Na razie goły VSCode i klasyczny JS mi wystarczy, nie mam dodatkowego życia
na rozkminienie tego wszystkiego :-(

--
pozdrawiam
Roman Tyczka

Dnia Sun, 5 Aug 2018 23:11:07 +0200, Roman Tyczka napisał(a):

>> włączenie osobnego procesu transpilacji. Nieważne czy to będzie
>> TypeScript/CoffeScript, czy też cały framework typu React czy choćby użycie
>> kodu ES6 - czeka Cię nauka gulp / webpack / rollup (a do tego npm / yarn +
>> babel).
>
> Poczytałem o tym... włosy stają dębą... to jest tak pokręcone i
> przekombinowane, że podziwiam tych, co w tym się sprawnie poruszają.

Polecę klasykiem:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
nic się nie zestarzało w tym tekście ;)

> To wszystko brzmi jak sen wariata i ogarnięcie wymaga pewnej formy autyzmu
> :-)

Tak, świat JS dokładnie tak wygląda. Musisz nabyć odporności i przestać
myśleć o tym całym bajzlu dziejącym się pod spodem. I mieć mocne CPU, by
proces transpilacji nie przeszkadzał aż tak bardzo.

A później się okazuje, że kodu będą używać w korpo na IE11 i załamujesz
się.

--
Borys Pogoreło
borys(#)leszno,edu,pl