Știu, știu … soclul din imaginea de pe copertă nu este chiar tipul de soclu despre care vorbim în această postare, dar am fost preocupat în ultima vreme de ideea construirii unei noi stații de lucru și de ThreadRipper este un monstru! Vreau să spun că ar putea fi de fapt soluția pentru a nu simți niciodată că computerul meu nu este niciodată suficient de rapid, indiferent de ce folosesc (în prezent este un procesor Intel I7 8th Gen).

Fiecare desktop / stație de lucru pe care am folosit-o vreodată de-a lungul anilor (bine că a existat una) a lăsat întotdeauna mult de dorit. Așteptarea computerului pentru a calcula este o problemă! Problemele ecranului, aparentele de filare de progres aparent, timpul de întârziere și altele asemenea distrug cu adevărat productivitatea și fluxul de lucru.

Oricum, pe subiect și departe de …

Tangentă

NodeBB (Node.js Forum) Hacking

Așa cum am scris despre recent, timpul meu de piratare a fost petrecut în ultima vreme pe software-ul forumului NodeBB. Procesul de compilare pe care dezvoltatorii NodeBB l-au pus în funcțiune se bazează pe alergătorul de sarcini Grunt, care însuși este construit și cu Node.js. Este minunat când poți lucra într-un ecosistem construit în principal pe cadrele de care te bucuri cel mai mult (de exemplu, Node.js ❤️).

Cu toate acestea, când vine vorba de depanare și când instrumentele de construire și alte straturi de software sunt construite cu Node.js, uneori lucrurile devin puțin dificile. Ca atunci când vrei să treci --inspect flag to node executabil pentru a începe o sesiune de depanare, având intenția de a depana codul pluginului și nu straturile de deasupra acestuia (Grunt, NodeBB).

Nu știu nicio opțiune de linie de comandă specifică cli Grunt care poate fi folosită pentru a vă trece intenția de a începe o sesiune de depanare a nodului până la nivelul sarcinii. Am încercat mai multe lucruri fără rezultat, cu toate acestea, mai existau câteva opțiuni pentru a o face:

  1. Porniți Grunt apelând direct Node, ala node --inspect /path/to/grunt
  2. Porniți programatorul Node Inspector utilizând încă experimentul API inspector
  3. Porniți Node Inspector după ce utilizați semnale Linux, SIGUSR1 mai exact.

Compensări

Desigur, fiecare dintre aceste soluții a oferit obstacole proprii și, ca în cazul majorității lucrurilor, a inclus atât aspecte pozitive, cât și aspecte negative!

În această postare voi vorbi despre fiecare dintre aceste soluții, detaliind problemele cu care m-am confruntat folosind fiecare. Vom vedea cum a fost folosită API-ul Inspector Modulul NPM fiveo posibil și modul în care acest instrument face ca utilizarea semnalelor Linux cu Node.js să fie și mai puternică. Și, în cele din urmă, voi arăta cum, în scenariul prezentat aici, opțiunea # 3 s-a dovedit a fi cea mai bună soluție. Și modul în care alegerea opțiunii # 3 a servit drept catalizator pentru a scrie plugin-ul grunt-swatch, ce face acel plugin în prezent și ce ar putea face cu ceva mai multă muncă.

1. Steagul Inspect --inspect

Deci, această comandă funcționează perfect pentru a porni depanatorul:

node --inspect /home/batman/.nvm/versions/node/v10.16.0/bin/grunt

ad-banner

și grunt va continua să facă ceea ce este acela de a efectua o grămadă de pași de construire înainte de a porni de fapt serverul NodeBB. Totuși, rețineți faptul important că porniți acel proces inițial de nod apelând nodul cu --inspect va prezenta propriile provocări atunci când Grunt lansează procese complet noi.

În mod minunat când procesele copil nod sunt pornite și procesul părinte a fost apelat cu semnalizarea inspect setată, copiii vor moșteni acea setare. Dar este din același motiv că dacă apelezi nodul cu --inspect la fel ca noi, vă confruntați cu aceste mesaje frumoase? privindu-vă în consolă:

failed: address already in use

1611284530 26 Cum sa inspectati Nodejs cu Grunt SWATCH Ceas si Fiveo

Acestea failed: address already in use mesajele apar deoarece inspectorul, care este un server socket, a fost deja pornit în procesul părinte care în cazul nostru este Grunt. Astfel, atunci când copiii încep cu moștenirea --inspect semnalează argumentele implicite ale cui sunt setate la localhost:9229, Node încearcă să pornească serverul socket inspector (îl vom numi „inspectează procesul“de acum înainte) folosind portul implicit 9229.

O soluție pentru acest lucru ar fi schimbarea comenzii noastre inițiale în:
node --inspect=0 /home/batman/.nvm/versions/node/v10.16.0/bin/grunt

„= 0” face ca procesul de inspecție să aleagă un port aleatoriu, după cum puteți vedea 39380 și 46704 au fost alese.

Porturi aleatorii de insector

Ceea ce este grozav, deoarece acum avem două procese de inspector în desfășurare! Partea care nu este atât de grozavă este că nu ne pasă de niciunul dintre ei … încă.

Configurarea construirii NodeBB

Nu pot explica complet DE CE din Flux de grunt care alcătuiește Gruntfile-ul lui NodeBB:

NodeBB Gruntfile.js snipit

Dar pot spune asta CE face este în esență forking o secvență de inițializare care are grijă de construirea css, fișiere de limbă, șabloane, construirea / gruparea Javascript, etc … și apoi un al doilea proces este forțat pentru a porni serverul NodeBB cu active gata și bune a merge.

Mergând mai departe, de fiecare dată când este detectată o modificare datorită procesului de ceas (grunt-contrib-watch), procesul actual NodeBB este ucis și unul nou a început. Și odată cu acest nou proces vine … exact, un nou port de depanare aleatoriu va fi generat la fiecare ciclu.

Ceea ce complică din nou eforturile noastre de depanare și ridică câteva întrebări.

  • Cum ținem evidența tuturor acestor porturi de inspectori aleatorii?
  • Mai mult, pe măsură ce lucrăm la un server la distanță, cum ne ocupăm de redirecționarea porturilor?
  • Chiar ne pasă de sesiunile de inspector intermediar?

În timp ce ne gândim? pe acestea, să ne bifurcăm să …

2. Utilizați API-ul Inspector al nodului

A face acest lucru necesită o abordare mai „invazivă” atunci când vine vorba de dorința noastră inițială de a depana propriul cod. Această opțiune necesită includerea modulului inspector, care în sine nu este o problemă mare. Avem nevoie de cod tot timpul, iar modulul inspector este un modul de bază Node.js și nu o parte de cod de la terți.

Dar, pentru ca acel modul să fie într-adevăr de orice folos, trebuie adăugat cod suplimentar și adăugat la baza noastră de coduri.

const inspector = require('inspector')

A fi destul de …

s-a îndepărtat pentru a trece la un alt cod …

Noaptea trecuta!

Așadar, aseară, în timp ce scriam asta, începusem să scriu asta a fi destul sincer, nu mai aruncasem prea mult modulului inspector. Și în timp ce făceam acest lucru în efortul de a scrie această postare în modul cel mai informat posibil, am fost trimis în jos o mică gaură de iepure.

Unul dintre care am ieșit din faptul că am scris o mică bibliotecă care adaugă niște zahăr deasupra modulului inspector de bază, care, după cum se dovedește, este destul de cool. Acum, după ce am scris această minusculă bibliotecă, aș recomanda ca în loc să necesită modulul inspector, ar fi mai bine să folosiți fiveo ceea ce, la rândul său, face asta pentru dvs., în timp ce adăugați câteva caracteristici inteligente, cum ar fi utilizarea unui alt port decât 9229 această problemă GitHub este despre.

Fiveo Demo Gif

Totuși, s-ar putea să nu-ți placă mica mea bibliotecă? Și s-ar putea să nu fii interesat să scrii propria ta. Faptul că utilizarea API-ului inspector necesită adăugarea unui cod suplimentar la propriul dvs. există încă. Și acesta ar putea fi un factor care face ca această a doua opțiune să fie o alegere proastă pentru proiectul dvs. Ceea ce ne conduce la a 3-a și ultima opțiune …

3. SIGUSR1… Stai, vreau să spun SIGUSR2!

Deci, în cele din urmă, cea mai bună soluție pe care am găsit-o a fost să folosesc UNIX / Linux semnale. Acesta este un link către pagina de manual care vă oferă o imagine de ansamblu asupra a ceea ce sunt exact semnalele. Lung și scurt este că semnalele pot schimba comportamentul proceselor care le primesc. Rețineți că semnalele nu sunt acceptate pe Windows. Și din documentele oficiale ale lui Node:

Node.js va începe, de asemenea, să asculte mesajele de depanare dacă primește un semnal SIGUSR1. (SIGUSR1 nu este disponibil pe Windows.)

Planul

Ideea generală este că putem livra semnalul SIGUSR1 către procesul Node specific codului nostru în momentul în care avem nevoie de el, și nu înainte, eliminând astfel tot zgomotul care nu ne interesează. Zgomot precum ceea ce face NodeBB în faza de inițiere (amintiți-vă că bifurcă o grămadă de lucruri) sau în ce se introduce codul Grunt etc.

Punctul în care suntem gata să pornim depanatorul este punctul după ce Grunt își îndeplinește sarcinile de inițiere, pornește serverul NodeBB și forumul poate fi accesat prin portul pe care este configurat să ruleze tcp/45670. În acel moment, trebuie să determinăm ID-ul procesului pe care îl ascultă NodeBB, deoarece avem nevoie de un id de proces pentru a ne transmite semnalul la locul potrivit. La primirea SIGUSR1, Node va începe procesul inspectorului și putem începe depanarea!

Ceea ce tocmai am descris în paragraful precedent este exact ceea ce pluginul nostru Grunt grunt-swatch face. Este similar cu grunt-contrib-watch prin faptul că urmărește continuu schimbările din mediul dvs., diferența constă în aceea grunt-swatch nu urmărește sistemul de fișiere, ci mai degrabă rețeaua, deci numele, derivat din ceas cu soclu.

grunt-contrib-watch

Rulați sarcini predefinite ori de câte ori sunt adăugate, modificate sau șterse modele de fișiere urmărite

Unul ar trebui să poată scrie alte „acțiuni” pentru plugin, totuși am scris doar nim (numit în mod adecvat, dar și un apel invers la NiM) acțiune nim.js:

Cod pentru acțiunea nim care arată SIGUSR1

Puteți vedea că este destul de simplu în ceea ce face, dar exact ceea ce avem nevoie. Folosește Linux kill comanda (de asemenea o Sci-Fi distractivă apropo!) să trimită SIGUSR1 semnalul nostru arătat proces. După cum puteți vedea close() funcția în prezent nu face nimic și asta pentru că înainte de a scrie fiveo, nu a existat nicio modalitate de a închide inspectorul nodului prin metoda semnalului. Cu toate acestea, cu cinci incluse, avem acces la SIGUSR2 care poate închide procesul inspectorului … lăsând lucrurile puțin mai ordonate?

Cod pentru acțiunea nim care arată SIGUSR2

Iată ieșirea de unde puteți vedea din swatch:nim ieșire jurnal, că acțiunea nim închide de fapt soclul inspectorului nodului care a fost deschis anterior. În captura de ecran de mai jos puteți vedea ciclul complet de deschidere / închidere a acestui websocket: ws://localhost:9230/b26fc131-af5e-4943-b911-a25b4261e43c

Jurnal pentru acțiunea nim care arată SIGUSR2

Grunt cu sarcina mea grunt-swatch încărcat și configurat corespunzător va asigura că în timpul procesului meu de dezvoltare, inspectorul va fi oprit și pornit în mod inteligent atunci când am nevoie.

grunt.loadNpmTasks('grunt-swatch')

Mai departe NiM Mă voi asigura că DevTools este întotdeauna exact acolo unde am nevoie, deschis la internetul corect al inspectorului și gata de plecare.

Captură de ecran NiM Popup

Și acolo îl avem. Folosind grunt-swatch, fiveo, împreună cu NiM Extensie crom, fluxul nostru de lucru pentru dezvoltarea pluginului NodeBB este mult îmbunătățit! Cu siguranță nu pierd procesul manual de executare a acestei comenzi peste și peste,? și încă o dată:

pid=`netstat -lnp|grep 45670|awk 'BEGIN {FS=" "}{print $7}'|cut -f1 -d"/"'`
kill -SIGUSR1 $pid

Câțiva pași următori ar putea fi conceperea unei metode de comunicare cu procesul de debugee pentru a schimba dinamic portul de depanare. Pentru a putea seta portul de depanare din configurația Grunt și, în esență, forțați aplicația Node să deschidă un depanator pe un port preconfigurat (în curs de dezvoltare, după runtime) ar fi ideal!

Concluzie

Sper că ți s-a părut utilă această postare. Iată linkurile relevante către lucruri: