[FIX] fix some minor typo bugs

This commit is contained in:
Ane Diaz de Tuesta
2021-02-01 20:48:21 +01:00
parent bfca68cddd
commit ef04754cb7
24 changed files with 178 additions and 170 deletions

View File

@ -112,7 +112,7 @@ Irakurri beste hizkuntza batzuetan: [![CN](/assets/flags/CN.png)**CN**](/README.
<p align="right"><a href="#edukien-aurkibidea">⬆ Itzuli hasierara</a></p>
# `2. Akatsen kudeaketa`
# `2. Erroreen kudeaketa`
## ![✔] 2.1 Erabili Async-Await edo errore asinkronoak kudeatzeko promesak
@ -174,7 +174,7 @@ Irakurri beste hizkuntza batzuetan: [![CN](/assets/flags/CN.png)**CN**](/README.
<br/><br/>
## ![✔] 2.7 Erabili erregistratze tresna heldu bat erroreen ikusgaitasuna handitzeko
## ![✔] 2.7 Erabili erregistratze tresna helduak erroreen ikusgaitasuna handitzeko
**TL;PL:** erregistratze tresna helduen sortak erabiltzen badituzu [Pino](https://github.com/pinojs/pino) edo [Log4js](https://www.npmjs.com/package/log4js), adibidez, erroreak lehenago antzeman eta ulertuko dituzu. Beraz, utzi alde batera console.log
@ -238,7 +238,7 @@ Irakurri beste hizkuntza batzuetan: [![CN](/assets/flags/CN.png)**CN**](/README.
<p align="right"><a href="#edukien-aurkibidea">⬆ Itzuli hasierara</a></p>
# `3. Kodearen estiloa`
# `3. Kode estiloa`
## ![✔] 3.1 Erabili ESLint

View File

@ -2,7 +2,8 @@
### ESLint eta Prettier alderatzen
Kode hau formateatzen baduzu ESLint erabiliz, abisu bat besterik ez dizu emango luzeegia dela esanez (zure `max-len` ezarpenaren arabera). Prettierrek zure order automatikoki formateatuko du.
Kode hau formateatzen baduzu ESLint erabiliz, abisu bat besterik ez dizu emango luzeegia dela esanez (zure `max-len` ezarpenaren arabera). Prettierrek zure order automatikoki formateatuko du.
```javascript
foo(
@ -28,4 +29,4 @@ Iturria: [https://github.com/prettier/prettier-eslint/issues/101](https://github
### ESLint eta Prettier integratzen
ESLint eta Prettier kodearen formateatze funtzionalitateetan gainezarri daitezke, baina [prettier-eslint](https://github.com/prettier/prettier-eslint), [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier), eta [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) bezalako liburutegiekin errez konbinatu daitezke. Beren arteko ezberdintasunei buruzko informazio gehiago nahi izanez gero, [hemen](https://stackoverflow.com/questions/44690308/whats-the-difference-between-prettier-eslint-eslint-plugin-prettier-and-eslint) begira dezakezu esteka
ESLint eta Prettier kodearen formateatze funtzionalitateetan gainjar daitezke, baina erraz konbina daitezke [prettier-eslint](https://github.com/prettier/prettier-eslint), [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier), eta [eslint-config-prettier](https://github.com/prettier/eslint-config-prettier) bezalako liburutegiekin. Haien arteko ezberdintasunei buruzko informazio gehiago nahi izanez gero, [hemen](https://stackoverflow.com/questions/44690308/whats-the-difference-between-prettier-eslint-eslint-plugin-prettier-and-eslint) begira dezakezu esteka

View File

@ -2,26 +2,26 @@
### Azalpen paragrafoa
Exzepzioa != Errorea. Errore kudeaketa tradizionalak kodearekin erlazionatutako arazotzat hartzen ditu exzepzioak, baina aplikazioaren erroreak, formularioko kode bide motelek, APIen jardunik gabeko uneek, konputazio baliabide faltak... ekar litzazke. Hementxe dira APM produktuak praktiko, askotariko 'ezkutatutako' arazoak instalazio minimo batekin proaktiboki antzematen laguntzen dute eta. APM produktuen ohizko funtzionalitateen artean, HTTP APIak erroreak bidaltzen dituenean alerta jotzea, API erantzunaren denbora aurretik zehaztutako denbora muga baino luzeagoa denean, kode usainak atzeman, monitorizazio zerbitzariaren baliabideetzat funtzionalitateak, operazio inteligentziadun aurreko panelak (dashboard) IT metrikekin eta beste funtzionalitate erabilgarri ugari. Hornitzaile gehienek dohaineko plana eskeintzen dute
Salbuespena != Errorea. Erroreen kudeaketa tradizionalak kodearekin erlazionatutako arazotzat hartzen ditu salbuespenak, baina aplikazioen erroreak formularioko kode bide motelen, APIen jardunik gabeko uneen eta baliabide konputazionalen gabezien ondorio izan daitezke. Horra non APM produktuak oso erabilgarriak diren, 'lurperatutako' askotariko gaiak modu proaktiboan detektatzeko aukera ematen baitute gutxieneko konfigurazioarekin. APM produktuen ohiko funtzionalitateen artean daude, adibidez, HTTP APIak erroreak bidaltzen dituenean alerta jotzea, APIaren erantzunaren denbora aurretik zehaztutako denbora muga baino luzeagoa denean antzematea, kode usainak hautematea, monitorizazio zerbitzariaren baliabideentzako funtzionalitateak, operazio inteligentziadun panelak (dashboard) IT metrikekin eta beste funtzionalitate batzuk oso erabilgarriak direnak. Hornitzaile gehienek dohaineko plana eskaintzen dute.
### Wikipedia APMri buruz
Informazioaren teknologien eta sistemen kudeaketaren alorretan, Application Performance Management (APM) software aplikazioen errendimendu eta erabilgarritasunaren monitorizazio eta kudeaketa da. APM, aplikazioen errendimendu arazo konplexuak antzeman eta diagnostikatzen saiatzen da, esperotako zerbitzu maila mantentzeko. APM IT metriken itzulpena da negozio esanahi balioa duen zerbaitera“. Produktu nagusiak eta segmentuak.
Informazioaren teknologien eta sistemen kudeaketaren alorretan, Application Performance Management (APM) software aplikazioen errendimendu eta erabilgarritasunaren monitorizazio eta kudeaketa da. APM aplikazioen errendimendu arazo konplexuak atzeman eta diagnostikatzen saiatzen da, esperotako zerbitzu maila mantentzeko. APM "IT metrikak negozioaren esanahira ([hau da,] balioa)" itzultzea da. Produktu eta segmentu nagusiak. APM "IT metrikak negozioaren esanahira ([hau da,] balioa)" itzultzea da. Produktu eta segmentu nagusiak.
### APM merkatua ulertzen
APM produktuek 3 segmentu nagusi dituzte:
1. Webgune edo API monitorizazioa, martxan egondako denbora eta errendimuendua HTTP eskaeren bidez etengabe monitorizatzen dituzten kanpo zerbitzuak. Minutu gutxi batzuetan ezarri daiteke. Hurrengo hauek dira aukeratutako lehiakide batzuk: [Pingdom](https://www.pingdom.com/), [Uptime Robot](https://uptimerobot.com/), eta [New Relic](https://newrelic.com/application-monitoring)
1. Webgune edo APIen monitorizazioa, martxan egondako denbora eta errendimuendua HTTP eskaeren bidez etengabe monitorizatzen dituzten kanpo zerbitzuak. Minutu gutxi batzuetan ezar daiteke. Hurrengo hauek dira aukeratutako lehiakide batzuk: [Pingdom](https://www.pingdom.com/), [Uptime Robot](https://uptimerobot.com/), eta [New Relic](https://newrelic.com/application-monitoring)
2. Kodearen instrumentazioa, kode motelaren antzematea, exzepzioen estadistikak, errendimenduaren monitorizazioa eta holako beste funtzionalitateak erabiltzeko agente bat aplikazioan txertatzea eskatzen duen produktu familia da. Hurrengo hauek dira aukeratutako lehiakide batzuk: New Relic, App Dynamics
2. Kodearen instrumentazioa, kode motelaren atzematea, salbuespenen estadistikak, errendimenduaren monitorizazioa eta holako beste funtzionalitate batzuk erabiltzeko agente bat aplikazioan txertatzea eskatzen duen produktu familia da. Hurrengo hauek dira aukeratutako lehiakide batzuk: New Relic, App Dynamics
3. Operazio inteligentziadun aurreko panelak (dashboard), Ops taldea metrikekin eta landutako edukiarekin laguntzean oinarritutako produktu familia da, aplikazioa errendimendu hoberenean modu errezean egon dadin. Honek sarri informazio iturri ezberdinak (aplikazioaren erregistroak, Datu-Basearen erregistroak, zerbitzarien erregistroak, etab.) gehitzea ekartzen du eta aurreko panelen diseinu lana aurreikusi. Hurrengo hauek dira aukeratutako lehiakide batzuk: [Datadog](https://www.datadoghq.com/), [Splunk](https://www.splunk.com/), [Zabbix](https://www.zabbix.com/)
3. Adimen operatiboaren panela produktuen linea bat da, operazio taldeari metrika eta eduki aukeratuak eskaintzen dizkiona eta aplikazioaren errendimendua zein den jakitera behartzen duena. Horrek informazio iturri anitz (aplikazioen erregistroak, DB erregistroak, zerbitzarien erregistroa, etab.) eta aurrez aurreko arbelaren diseinua batzea eskatzen du. Hurrengo hauek dira aukeratutako lehiakide batzuk: [Datadog](https://www.datadoghq.com/), [Splunk](https://www.splunk.com/), [Zabbix](https://www.zabbix.com/)
### Adibidea: UpTimeRobot.Com: Webgune monitorizazio aurreko panela
### Adibidea: UpTimeRobot.Com: webguneak monitorizatzeko panela
![alt text](https://github.com/goldbergyoni/nodebestpractices/blob/master/assets/images/uptimerobot.jpg "Webgune monitorizazio aurreko panela")
### Adibidea: AppDynamics.Com: kode instrumentazioarekin konbinatutako hasieratik amaierarainoko monitorizazioa
### Adibidea: AppDynamics.Com: hasieratik amaierarainoko monitorizazioa kode instrumentazioarekin konbinatutakoa
![alt text](https://github.com/goldbergyoni/nodebestpractices/blob/master/assets/images/app-dynamics-dashboard.png "kode instrumentazioarekin konbinatutako hasieratik amaierarainoko monitorizazioa")

View File

@ -2,9 +2,9 @@
### Azalpen paragrafoa
Callbackak ez dira kudeaerrezak programatzaile gehienek ondo ezagutzen ez dituzte eta. Callbackek etengabeko errore egiaztatzea eskatzen dute, kode korapilotsua jasanaraziz eta kodigoaren fluxuaren ulergarritasuna zailduz. BlueBird, async, eta Q bezalako promesa liburutegiek kodigo estilo estandarra RETURN eta THROW erabiliaz paketatzen dute, programaren fluxua kontrolatzeko. Zehazki, kodigo nagusia funtzio bakoitzean erroreak kuadeatzetik askatzea ahalbidetzen duen try-catch errore kudeaketa estilo gogokoena onartzen dute
Callbackak ez dira kudea errazak programatzaile gehienek ez dituzte ondo ezagutzen eta. Callbackek etengabeko errore egiaztatzea eskatzen dute, kode korapilotsua jasanaraziz eta kodigoaren fluxuaren ulergarritasuna zailduz. BlueBird, async, eta Q bezalako promesa liburutegiek kodigo estilo estandarra RETURN eta THROW erabiliz paketatzen dute, programaren fluxua kontrolatzeko. Zehazki, kodigo nagusia funtzio bakoitzean erroreak kuadeatzetik askatzea ahalbidetzen duen try-catch errore kudeaketa estilo gogokoena onartzen dute
### Kodearen adibidea: promesen erabilera erroreak harrapatzeko
### Kode adibidea: promesen erabilera erroreak antzemateko
```javascript
return aFuntzioa()
@ -15,7 +15,7 @@ return aFuntzioa()
.then(betiExekutatuFuntzioHau);
```
### Kodearen adibidea: async/awaiten erabilera erroreak harrapatzeko
### Kode adibidea: async/awaiten erabilera erroreak antzemateko
```javascript
async function exekutatuAtazaAsinkronoBat() {
@ -32,7 +32,7 @@ async function exekutatuAtazaAsinkronoBat() {
}
```
### Anti ereduaren kodearen adibidea: callbackaren estiloko errore kudeaketa
### Anti ereduaren kode adibidea: callbackaren estiloko errore kudeaketa
<details>
<summary><strong>Javascript</strong></summary>
@ -95,24 +95,25 @@ datuakEskuratu(
### Blogeko aipua: "Promesekin arazo bat dugu"
pouchdb.com blogetik
pouchdb.com blogetik hartua
> ……Izatez, callbackek zerbait oraindik maltzurragoa egiten dute: pilaz gabetzen gaituzte, programazio lengoaietan sarri egintzat jotzen duguna. Kodea pila gabe idaztea kotxe bat freno pedalik gabe gidatzea bezala da: ez zara konturatzen zein punturarte behar duzun erabiltzen saiatu eta ez dagoela konturatzen zaren momenturarte. Promesen interes guztia asinkronoa (async) erabiltzean galdutako lengoaien oinarri guztiak berreskuratzea da: return, throw eta pila. Baina promesak modu egokian erabiltzen jakin beharra dago beraien probetxua ateratzeko.
> ……Izatez, callbackek zerbait oraindik maltzurragoa egiten dute: pilaz gabetzen gaituzte, programazio lengoaietan sarri egintzat jotzen duguna. Kodea pila gabe idaztea kotxe bat freno pedalik gabe gidatzea bezala da: ez zara konturatzen zein puntura arte
behar duzun erabiltzen saiatu eta ez dagoela konturatzen zaren momentura arte. Promesen helburu nagusia da asinkronoa (async) erabiltzean galdutako lengoaien oinarri guztiak berreskuratzea: return, throw eta pila. Baina promesak modu egokian erabiltzen jakin beharra dago beraiei probetxua ateratzeko.
### Blogeko aipua: "Promesen metodoa askoz ere konpaktuagoa da"
### Blogeko aipua: "Promesen metodoa askoz ere trinkoagoa da"
gosquared.com blogetik
gosquared.com blogetik hartua
> ………Promesen metodoa askoz ere konpaktuagoa, argiagoa eta idatzeko azkarragoa da. Errore edo exzepzio bat gertatzen bada .catch() kudeatzaile bakar batek maneiatzen du. Errore guztiak kuadeatzeko leku bakar hau edukitzeak erroreen egiaztatzea lanaren fase bakoitzean idatzi beharrik ez dagoela adierazten du.
> ………Promesen metodoa askoz ere trinkoagoa, argiagoa eta idatzeko azkarragoa da. Errore edo salbuespen bat gertatzen bada, .catch() kudeatzaile bakar batek maneiatzen du.Errore guztiak kudeatzeko leku bakarra edukitzeak erroreen egiaztatzea lanaren fase bakoitzean idatzi beharrik ez dagoela adierazten du.
### Blogeko aipua: "Promises are native ES6, can be used with generators"
### Blogeko aipua: "Promisak jatorrizko ES6 dira, eta sorgailuekin erabil daitezke"
StrongLoop blogetik
StrongLoop blogetik hartua
> ….Callbackek errore kudeaketa istorio kaskarra dute. Promesak hobeak dira. Promesekin, erabili Expressen errore kudeaketa kapsulatua eta horrela exzepzioren bat ez harrapatzeko aukerak murriztu. Promesak ES6ren berezkoak dira, generatzaileekin eta ES7ren async/await bezalako proposamenekin, Babel bezalako konpilatzaileetan, erabil daitezke.
> ….Callbackek erroreen kudeaketa istorio kaskarra dute. Promesak hobeak dira. Promesekin, erabili Expressen errore kudeaketa kapsulatua eta horrela salbuespenen bat ez antzemateko aukerak murriztuko dituzu. Promesak jatorriz ES6ak dira, eta generatzaileekin eta ES7ren async/await bezalako proposamenekin erabil daitezke Babel bezalako konpilatzaileetan.
### Blogeko aipua: "Ohiko fluxu kontrol erregular egitura guzti horiek guztiz apurtuta daude"
### Blogeko aipua: "Ohiko fluxu kontrol erregularren egitura guzti horiek guztiz apurtuta daude"
Bennos blogetik
Bennos blogetik hartua
> ……Asinkronoaren, callbacketan oinarritutako programazioaren, gauza hoberenetako bat, ohituta zauden fluxu kontrol erregular egitura guzti horiek guztiz apurtuta daudela da. Hala ere, exzepzioen kudeaketa da niretzat apurtuen dagoena. Javascriptek nahiko try…catch egitura ezaguna hornitzen du. Exzepzioen arazoa, erroreak pila batean ekiditeko aukera ona eman arren, errorea beste pila batean gertatzen bada guztiz alferrikakoak izaten bukatzen dutela da
> ……Asinkronoaren, hau da, callbacketan oinarritutako programazioaren gauza hoberenetako bat da ohituta zauden fluxu kontrol erregularren egitura guzti horiek guztiz apurtuta daudela. Hala ere, salbuespenen kudeaketa da niretzat apurtuen dagoena. Javascriptek nahiko try…catch egitura ezaguna hornitzen du. Salbuespenen arazoa da, erroreak pila batean ekiditeko aukera ona eman arren, errorea beste pila batean gertatzen bada guztiz alferrikakoak izaten bukatzen dutela…

View File

@ -4,11 +4,11 @@
### Azalpen paragrafoa
Normalean, Node.js/Express aplikazio kode moderno gehienen promesen barruan funtzionatzen dute, .then kudeatzailearen, callback funtzio baten edota catch bloke baten barruan. Modu harrigarrian, garatzaileak .catch klausula gogoratu ezean, leku hauetan jaurtitako erroreak ez dira uncaughtException ebentu-kudeatzaileaz kudeatuak izaten eta desagertu egiten dira. Noderen bertsio berrienek ohartarazpen mezu bat gehitu dute kudeatu gabeko errefus bat agertzean, egia da honek gauzak ondo ez doazenean jakinarazten lagundu dezakela, baina argi dago ez dela erroreak kudeatzeko modu zuzena. Konponbide samurrena, promesa dei kate bakoitzaren barruan .catch klausula erabiltzen ez ahaztea eta errore kudeatzaile zentralizatu batera desbideratzea da. Hala ere, zure errore kudeaketa estrategia soilik garatzaile diziplinan oinarritua apurkorra da. Ondorioz, atzera-egite dotorea erabiltzea eta `process.on('unhandledRejection', callback)`ra harpidetzea oso gomendatua dago, honek, promesa errore bakoitzak, lokalki kudeatuta egon ezean, bere tratamendua izango duela ziurtatuko du.
Normalean, Node.js/Express aplikazio kode moderno gehienek promesen barruan funtzionatzen dute, .then kudeatzailearen, callback funtzio baten edota catch bloke baten barruan. Harrigarria bada ere, garatzaile batek .catch klausula bat gehitu zuela gogoratu ezean, leku hauetan jaurtitako erroreak ez dira uncaughtException ebentu kudeatzaileaz kudeatuak izaten, eta desagertu egiten dira. Noderen bertsio berrienek ohartarazpen mezu bat gehitu dute tratatu gabeko errefusa agertzen denean; egia da horrek, gauzak ondo ez doazenean, ohartzen lagun dezakeela, baina argi dago ez dela erroreak kudeatzeko modu egokia. Konponbide samurrena da ez ahaztea promesa kateko dei bakoitzaren barruan .catch klausula erabiltzen eta errore kudeatzaile zentralizatu batera desbideratzea. Hala ere, hauskorra da erroreak kudeatzeko estrategia garatzailearen diziplinan soilik oinarritzea. Ondorioz, oso gomendagarria da atzera egite dotorea erabiltzea eta `process.on('unhandledRejection', callback)`ra harpidetzea, horrek ziurtatuko baitu promesa erroreek, bere tratamendua izango dutela, lokalki kudeatzen ez badira.
<br/><br/>
### Kodearen adibidea: errore hauek ez ditu inolako errore kudeatzailek harrapatuko (unhandledRejection-ek izan ezik)
### Kode adibidea: errore hauek ez ditu inolako errore kudeatzailek atzemango (unhandledRejection-ek izan ezik)
```javascript
DAL.berreskuratuErabiltzaileaIdBidez(1).then((johnSnow) => {
@ -19,7 +19,7 @@ DAL.berreskuratuErabiltzaileaIdBidez(1).then((johnSnow) => {
<br/><br/>
### Kodearen adibidea: kudeatu gabeko eta baztertutako promesak harrapatzen
### Kode adibidea: kudeatu gabeko eta baztertutako promesak atzematen
<details>
<summary><strong>Javascript</strong></summary>
@ -65,11 +65,11 @@ process.on("uncaughtException", (errorea: Error) => {
<br/><br/>
### Blogeko aipua: "Akatsen bat egiteko gai bazara, momenturen batean egingo duzu"
### Blogeko aipua: "&quot;Erroreren bat egiteko gai bazara, momenturen batean egin egingo duzu"
James Nelson blogetik
James Nelson blogetik hartua
> Froga dezagun zure ulermena. Hauetako zeinek uste duzu erakutsiko duela errore bat konsolan?
> Proba dezagun zure ulermena. Hauetako zeinek uste duzu erakutsiko duela errore bat kontsolan?
```javascript
Promise.resolve("agindutako balioa").then(() => {
@ -85,4 +85,4 @@ new Promise((resolve, reject) => {
});
```
> Ez dakit zer pentsatzen duzun, baina nire erantzuna guztietan errore bat bistaratuko dela da, eta errealitatea, JavaScript ingurune moderno gehienek kasu hauetako batentzat ere ez dituztela erroreak bistaratuko da. Gizakien arazoa, akatsen bat egiteko gai bazara, momenturen batean egingo duzula da. Hau argi edukita, begibistakoa dirudi gauzak akatsen erruz ahalik eta gutxien hondatzeko diseinatu behar direla da, eta honek erroreak beti kudeatzea esan nahi du, alde batera utzi beharrean.
> Ez dakit zer pentsatzen duzun, baina nire erantzuna da guztietan bistaratuko dela erroreren bat, eta errealitatea da JavaScript ingurune moderno gehienek kasu hauetako batentzat ere ez dituztela erroreak bistaratuko. Gizakien arazoa da, erroreen bat egiteko gai bazara, momenturen batean egingo duzula. Hori argi edukita, begibistakoa dirudi gauzak diseinatu behar direla erroreen erruz ahalik eta gutxien hondatzeko, eta horrek erroreak beti kudeatu beharra dagoela esan nahi du, alde batera utzi beharrean.

View File

@ -4,7 +4,7 @@
Errore kudeaketarako ardura bakarreko objektu bat ez izateak, errore garrantzitsuak ezkutatzeko aukerak ugaritzen ditu kudeaketa ezegoki baten eraginpean. Errore kudeaketarako objektua, errorea begibistako bihurtzearen arduradun da, adibidez, egoki formateatutako erregistro batean idatziz, ebentuak [Sentry](https://sentry.io/), [Rollbar](https://rollbar.com/), edota [Raygun](https://raygun.com/) bezalako monitorizazio sistemaren batera bidaliz. [Express](http://expressjs.com/en/guide/error-handling.html#writing-error-handlers) bezalako web framework gehienak, errore kudeaketa middleware mekanismo bat proposatzen dute. Errore kudeaketa fluxu tipiko bat hau izan daiteke: moduluren batek errore bat jaurtitzen du -> API routerrak errorea harrapatzen du -> errorea middlewarera hedatzen du, (adibidez Express edo KOA), zeinek erroreak harrapatzeko ardura duen -> errore kudeatzaile zentralizatu bati deitzen zaio -> middlewareari esaten zaio ia errore hau konfiantzazkoa den (ez operazio errorea) aplikazioa dotoreki berrekiteko. Kontutan izan Express midelwarean erroreak kudeatzea praktika arrunta dela, okerra izan arren. Hau egiteak ez ditu kontutan hartzen weba ez diren bestelako interfazeetako erroreak.
### Kodearen adibidea: ohizko errore fluxu bat
### Kode adibidea: ohiko errore fluxua
<details>
<summary><strong>Javascript</strong></summary>
@ -72,7 +72,7 @@ app.use(async (errorea: Error, req: Request, res: Response, next: NextFunction)
</details>
### Kodearen adibidea: erroreen kudeaketa ardura bakarreko objektu batekin
### Kode adibidea: erroreen kudeaketa ardura bakarreko objektuekin
<details>
<summary><strong>Javascript</strong></summary>
@ -110,7 +110,7 @@ export const kudeatzailea = new ErroreKudeatzailea();
</details>
### Kodearen adibidea: anti Eredua: erroreak middleware barruan kudeatu
### Anti ereduaren kode adibidea: kudeatu erroreak middleware barruan
<details>
<summary><strong>Javascript</strong></summary>
@ -156,20 +156,20 @@ app.use((errorea: Error, req: Request, res: Response, next: NextFunction) => {
</details>
### Blogeko aipua: "Batzuetan maila baxuagoek beren deilariari errorea hedatzea baino ezer erabilgarriagorik ezin dute egin"
### Blogeko aipua: "Batzuetan maila baxuagoek beren deitzaileari errorea bidaltzea baino ezer praktikoagorik ezin dute egin"
Joyent blogetik, “Node.js errore kudeaketa" hitz gako bati esker sailkatua
Joyent blogeko “Node.js errore kudeaketa" hitz gako bati esker sailkatua
> …Errore bera pilaren maila askotan kudeatzen bukatuko duzu. Hau, maila baxuenek beren deilariei (eta beste hauek beren deilariei, etab.) errorea hedatzea baino hoberik ez dutenean gertatzen da. Askotan, soilik goi mailako deilariak daki zein den erantzun zuzena, ia ahalegin operazio berria den, erabiltzaileari erroreari buruz eman, edo beste edozer. Baina honek ez du esan nahi errore guztiak goi mailako callback bakar bati jakinarazi behar dizkiozunik, callback honek ere errorea zein kontextutan gertatu den ez daki eta…
> …Errore bera pilaren maila askotan kudeatzen bukatuko duzu. Hau gertatzen da maila baxuenek beren deitzaileei (eta beste haiek beren deitzaileei, etab.) errorea bidaltzea baino beste ezer egokiagorik ezin dutenean egin. Askotan, soilik goi mailako deitzaileak daki zein den erantzun zuzena, ia ahalegin operazio berria den, erabiltzaileari errorearen berri eman behar dion, edo beste edozer. Baina horrek ez du esan nahi errore guztiak goi mailako callback bakar bati jakinarazi behar dizkiozunik, callback horrek ere errorea zein testuingurutan gertatu den ez daki eta…
### Blogeko aipua: "Errore bakoitza bakarka kudeatzea bikoizte galanta izan daiteke"
JS Recipes blogetik, “Node.js errore kudeaketa" 17 hitz gakori esker sailkatua
JS Recipes blogeko “Node.js errore kudeaketa" 17 hitz gakori esker sailkatua
> ……Hackathoneko Starter api.js kontrolatzaile bakarrean, 79 errore objektu inguru daude. Errore bakoitza bakarka kudeatzeak kodea ikaragarri bikoiztea eragin dezake. Hurrengo egin dezakezun gauza hoberena errore kudeaketa logika Express middleware bati uztea da
> ……Hackathoneko Starter api.js kontrolatzaile bakarrean, 79 errore objektu inguru daude. Errore bakoitza bakarka kudeatzeak kodea ikaragarri bikoiztea eragin dezake. Hurrengo egin dezakezun gauza hoberena da errore kudeaketa logika Express middleware bati uztea…
### Blogeko aipua: "HTTP erroreak ezin dira zure datu-basearen kodean egon"
### Blogeko aipua: "HTTP erroreak ezin dira zure datu basearen kodean egon"
Daily JS blogetik, “Node.js errore kudeaketa" 14 hitz gakori esker sailkatua
Daily JS blogeko “Node.js errore kudeaketa" 14 hitz gakori esker sailkatua
> ……Errore objektuetan ezaugarri erabilgarriak zehaztu beharko zenituzke, baina ezaugarri hauek tinkoki erabili. Eta, ez gurutzatu korronteak: HTTP erroreak ezin dira zure datu-basearen kodean egon. Edota, nabigatzaile garatzaileentzat, Ajax erroreak zerbitzariarekin hitz egiten duen kodean daitezke, baina Mustache txantiloiak prozesatzen dituen koderik ez…
> ……Errore objektuetan ezaugarri erabilgarriak zehaztu beharko zenituzke, baina ezaugarri horiek tinko erabiliz. Eta, ez gurutzatu korronteak: HTTP erroreak ezin dira zure datu basearen kodean egon. Edota, nabigatzaile garatzaileentzat, Ajax erroreak zerbitzariarekin hitz egiten duten kodean egon daitezke, baina Mustache txantiloiak prozesatzen dituen koderik ez…

View File

@ -2,9 +2,10 @@
### Azalpen paragrafoa
REST APIek HTTP estatus kodigoak erabiliz bueltatzen dituzte emaitzak, APIaren erabiltzailearentzat guztiz beharrezkoa da APIaren egituraren eta baita errore posibleen berri izatea, erabiltzaileak errorea harrapatu eta kontu handiz kudea dezake. Adibidez, zure APIaren dokumentazioak aurrez azaldu behar du 409 HTTP estatus kodea bueltatzen dela bezeroaren izena iada existitzen denean (APIak bezero berriak gordetzen dituela ziurtzat joz), APIaren erabiltzaileak egoera bakoitzerako bistaratze egokiena proposa dezan. OpenAPI (aintzina Swagger) APIaren dokumentaziorako eskema bat zehazten duen estandar bat da, dokumentazioa online modu errezean sortzea ahalbidetzen duten tresna ekosistema bat proposatuz, begiratu hurrengo pantaila argazkiak beherago
REST APIek HTTP estatus kodigoak erabiliz bueltatzen dituzte emaitzak. APIaren erabiltzailearentzat guztiz beharrezkoa da APIaren egituraren eta baita ere errore posibleen berri izatea, erabiltzaileak errorea atzeman eta kontu handiz kudea dezake eta. Adibidez, zure APIaren dokumentazioak aurrez azaldu behar du 409 HTTP estatus kodea bueltatzen dela bezeroaren izena iada existitzen denean (APIak bezero berriak gordetzen dituela ziurtzat joz), APIaren erabiltzaileak egoera bakoitzerako bistaratze egokiena proposa dezan. OpenAPI (aintzina Swagger) APIaren dokumentaziorako eskema bat zehazten duen estandar bat da, dokumentazioa online modu errazean sortzea ahalbidetzen duten tresna ekosistema bat proposatuz. Begiratu hurrengo pantailako argazkiak beherago
Dagoeneko GraphQL erabiltzen baduzu zure APIaren helburuetarako, zure eskemak iada zorrozki bermatzen du zein errorek zein itxura eduki beharko luketen ([dokumentuan laburbilduta](https://facebook.github.io/graphql/June2018/#sec-Errors)) eta nola kudeatu beharko liratekeen zure bezero tresnekin Gainera, komentarioz osatutako dokumentazioa ere gehi zenezake.
Iada GraphQL erabiltzen baduzu zure APIaren helmugetarako, zure eskemak iada zorrozki bermatzen du zein errorek zein itxura eduki beharko luketeen ([dokumentuan laburbilduta](https://facebook.github.io/graphql/June2018/#sec-Errors)) eta nola kudeatu beharko liratekeen zure bezero zatiko tresnekin. Gainera, komentarioz osatutako dokumentazioa ere gehi zenezake.
### GraphQL errore baten adibidea
@ -41,11 +42,11 @@ Iada GraphQL erabiltzen baduzu zure APIaren helmugetarako, zure eskemak iada zor
}
```
### Blogeko aipua: "Zure deilariei zein errore gertatu diren esan behar diezu"
### Blogeko aipua: "Zure deitzaileei zein errore gertatu diren esan behar diezu"
Joyent blogetik, “Node.js erregistratzea“ hitz gako bati esker sailkatua
Joyent blogeko “Node.js erregistratzea“ hitz gako bati esker sailkatua
> Erroreak nola kudeatzeari buruz hitz egin dugu, baina funtzio berri bat idazten ari zarenean, nola bidaltzen dizkiozu erroreak zure funtzioa deitu duen kodeari? …Zein errore gerta litezkeen edo hauek zer esan nahi duten ez badakizu, zure programa ezin litekeela zuzela izan esan nahi du, txiripaz izan ezean. Beraz, funtzio berri bat idazten ari bazara, zure deilariei zein errore gerta litezkeen eta hauek zer esan nahi duten esan behar diezu…
> Erroreak nola kudeatu behar diren aztertu dugu, baina funtzio berri bat idazten ari zarenean, nola bidaltzen dizkiozu erroreak zure funtzioa deitu duen kodeari? …Zein errore gerta litezkeen edo haiekk zer esan nahi duten ez badakizu, esan nahi du zure programa ezin litekeela zuzena izan, txiripaz izan ezean. Beraz, funtzio berri bat idazten ari bazara, zure deitzailei zein errore gerta litezkeen eta haiek zer esan nahi duten esan behar diezu…
### Tresna erabilgarria: Swagger Online Dokumentazio Sortzailea

View File

@ -2,13 +2,13 @@
### Azalpen paragrafoa
Denok dakigu argudioak egiaztatzea eta azkar huts egitea garrantzitsua dela ezkutuko arazoak ekiditeko (ikusi anti-eredu kodearen adibidea behean). Horrela izan ezean, irakurri programazio explizituaren eta babes programazioaren inguruan. Errealitatean, hau ekiditeko ohitura daukagu, kode hau idazteak suposatzen duen gogaikarritasuna dela eta (adibidez pentsatu posta elektronikoa eta datak bezalako alorrak dituen JSON objektu hierarkiko bat balioztatzen), Joi eta Validator bezalako liburutegiek hau asko leuntzen dute.
Denok dakigu argudioak egiaztatzea eta azkar huts egitea garrantzitsua dela ezkutuko erroreak ekiditeko (ikusi ereduaren aurkako kodearen adibidea behean). Bestela, irakurri zerbait programazio esplizituaren eta babes programazioaren gainean. Errealitatean, hori ekiditeko ohitura daukagu, kodea idazteak suposatzen duen gogaikarritasuna dela eta (adibidez pentsatu posta elektronikoa eta datak bezalako alorrak dituen JSON objektu hierarkiko bat balioztatzea). Joi eta Validator bezalako liburutegiek asko leuntzen dute lan hori.
### Wikipedia: babes programazioa
### Wikipedia: programazio defentsiboa
Babes programazioa software eta jatorri kodea hobetzeko ikuspuntua da, kalitate orokorraren terminoetan, software akats eta arazo kantitatea murriztuz. Jatorri kodea ulergarria eginez, jatorri kodea irakurgarria eta ulergarria izan behar da kode auditoria batean onartua izan dadin. Softwarea aurreikusteko moduko eran jokatzeko egin, ustekabeko sarrerak edo erabiltzaile ekintzak gertatu arren.
Programazio defentsiboa softwarea eta iturburu kodea hobetzeko ikuspuntua da, kalitate orokorrari dagokionez, software errore eta arazo kopurua murriztuz. Iturburu kodea ulergarria izango bada, irakurgarria eta ulergarria izan behar da kode auditoria batean onartua izan dadin. Softwarea aurreikusteko moduko eran jokatzeko egin behar da, ustekabeko sarrerak edo erabiltzaile ekintzak gertatu arren.
### Kodearen adibidea: JSON sarrera koplexua balioztatu Joi erabiliaz
### Kode adibidea: balioztatu JSON sarrera koplexua Joi erabiliz
```javascript
var kideEskema = Joi.object().keys({
@ -24,7 +24,7 @@ function kideBerriaGehitu(kideBerria) {
}
```
### Anti eredua: balioztatze ezak akats kaskarrak dakartza
### Anti eredua: balioztatze ezak errore kaskarrak dakartza
<details>
<summary><strong>Javascript</strong></summary>
@ -66,6 +66,6 @@ bidaliDeskontuTiketakInprimatzera(httpResponse, kiderenBat, -12);
### Blogeko aipua: "Errore hauek zuzenean jaurti beharko zenituzke"
Joyent blogetik
Joyent blogetik hartua
> Kasu degeneratu bat norbaitek funtzio asinkrono bat callback gabe deitzen duenean da. Errore hauek zuzenean jaurti beharko zenituzke programa apurtuta baitago eta hau arazteak gutxienez pila arrastoa eta errorearen lekuko fitxategia berreskuratzea eskatzen ditu. Hau egiteko, funtzioaren hasieran argudio guztien motak balioztatzea gomendatzen dugu.
> Kasu degeneratu bat da norbaitek funtzio asinkrono bat callback gabe deitzea atzera deirik egin gabe. Errore horiek berehala jaurti beharko zenituzke programa apurtuta baitago eta hori arazteak gutxienez pila arrastoa eta errorearen lekuko fitxategia berreskuratzea eskatzen du. Hori egiteko, funtzioaren hasieran argudio guztien motak balioztatzea gomendatzen dugu.

View File

@ -1,10 +1,10 @@
# Bereizi eragiketa erroreak eta programatze erroreak
# Bereizi eragiketa erroreak eta programazio erroreak
### Azalpen paragrafoa
Ondorengo bi errore mota hauek bereizteak zure aplikazioaren matxura-denbora gutxitu eta programazio-errore eroak ekiditen lagunduko du: eragiketa erroreek, gertatu dena eta honen ondorioak (adibidez, HTTP zerbitzu bati egindako deiak huts egitea konekxio arazo bat dela eta) ulertzen dituzun egoerei deritze. Aldiz, programazio erroreek, errorea zergatik eta nonkik etorri den (balio zehaztugabe bat irakurtzen saiatzen den kodea edo memoria ihes egiten dion datu-basea izan daitezke) ez dakizun egoerei deritze. Eragiketa erroreak erlatiboki kudeaerrezak dira, normalean errorea erregistratzea nahikoa da. Gauzak konplikatuagoak izan daitezke garatzaile errore bat tupustean agertzen denean, aplikazioa egoera inkontsekuente batean aurki daiteke eta dotoreki aplikazioa berrekitea baino hoberik ez duzu
Ondorengo bi errore mota hauek bereizteak zure aplikazioaren matxura denbora gutxitu eta programazio errore eroak ekiditen lagunduko dizu. Batetik, eragiketa erroreak daude, gertatutako arazoa eta haren ondorioak ulertzen dituzunean (adibidez, HTTP zerbitzu bati egindako deiak huts egitea, konexio arazoak direla eta. Bestetik, errorea zergatik eta nondik etorri den ez dakizun egoerei programatze errore deritze (balio zehaztugabe bat irakurtzen saiatzen den kodea edo memoria ihes egiten dion datu basea izan daitezke). Eragiketa erroreak besteen aldean kudea errazak dira, eta normalean nahikoa izaten da errorea erregistratzea. Gauzak konplikatuagoak izan daitezke garatzaile errore bat tupustean agertzen denean, aplikazioa egoera aldakorrean aurki baitaiteke. Horrelakoetan, aplikazioa berrabiarazi baino irtenbide hoberik ez duzu
### Kodearen adibidea: errore bat eragiketa errore (konfiantzazko) bihurtu
### Kode adibidea: erroreak eragiketa errore (konfiantzazko) bihurtu
<details>
<summary><strong>Javascript</strong></summary>
@ -71,30 +71,30 @@ throw new AppErrorea(
</details>
### Blogeko aipua: "Programatzaileen erroreak programan programazio-erroreak dira"
### Blogeko aipua: "Programatzaileen erroreak programazio erroreak dira programan"
Joyent blogetik, “Node.js errore kudeaketa" hitz gako bati esker sailkatua
Joyent blogeko “Node.js errore kudeaketa" hitz gako bati esker sailkatua
> …Programatzaile erroreetatik suspertzeko modurik hoberena berehala kraskadura eragitea da. Kraskadura baten aurrean automatikoki berrekingo dituen berrekite sistema bat erabiliaz exekutatu beharko zenituzte zure programak. Berrekite sistema bati esker, kraskadura da programatzaile errore pasakor baten aurrean zerbitzu fidagarri bat berreskuratzeko modurik azkarrena
> …Programatzaile erroreak gainditzeko modurik hoberena berehala huts eragitea da. Huts egiteren bat gertatzean automatikoki berrekingo dituen berrekite sistemaren bat erabiliz exekutatu beharko zenituzte zure programak. Berrekite sistemei esker, huts egitea da modurik azkarrena programatzaile errore iragankorrak gertatzean zerbitzua berreskuratzeko modu fidagarrian
### Blogeko aipua: "Alde egiteko modu segururik ez zehaztugabeko egoera hauskor bat sortu gabe"
### Blogeko aipua: "Alde egiteko modu segururik ez dago zehaztugabeko egoera hauskorrik sortu gabe"
Node.js dokumentazio ofizialetik
Node.js dokumentazio ofizialetik hartua
> …JavaScripten throwen funtsezko funtzionamenduan, ez dago ia inoiz "alde batera utzitakoa jasotzeko" modu seguruan egiteko biderik, erreferentziak galdu gabe edota bestelako zehaztugabeko egoera hauskorrak sortu gabe. Jaurtitako errore bati erantzuteko modurik seguruena prozesua itzaltzea da. Jakina, web zerbitzari arrunt batean, konekxio ugari eduki ahal ditzakezu irekita, eta ez da zentzuzkoa tupustean hauek ixtea beste batek eragindako errore batengatik. Planteamendu hoeberena, errorea bidali duen eskariari errore erantzun bat bidaltzea da, besteei beren atazak bukatzeko denbora utziz, eta eskari berriei kasu egiteari utzi prozesu horretan.
> Throw-ek JavaScripten nola funtzionatzen duen kontuan izanda, ez dago ia inoiz ataza bati modu seguruan “bertan behera utzitako puntuan segida ematerik erreferentziak galdu gabe edota bestelako egoera hauskor zehaztugaberik sortu gabe. Jaurtitako erroreei erantzuteko modurik seguruena prozesua gelditzea da. Jakina, web zerbitzari arruntetan, konexio ugari eduki ahal ditzakezu irekita, eta ez da zentzuzkoa tupustean haiek ixtea beste batek eragindako errore batengatik. Planteamendu hoberena da errorea bidali duen eskariari errore erantzun bat bidaltzea, besteei beren atazak bukatzeko denbora emanez, eta eskari berriei kasu egiteari utzi prozesu horretan.
### Blogeko aipua: "Bestela zure aplikazioaren egoera arriskatu dezakezu"
### Blogeko aipua: "Bestela zure aplikazioaren egoera arriskuan jar dezakezu"
debugable.com blogetik, “Node.js harrapatu gabeko exzepzioa" 3 hitz gakori esker sailkatua
> …Beraz, baldin eta benetan egiten ari zarena jakiten baduzu, “uncaughtException” exzepzio ebentua jaso ostean zure zerbitzuaren berrekite dotorea egin beharko zenuke. Bestela, zure aplikazioaren egoera arriskuan jar dezakezu, edota bere liburutegiak inkontsekuenteak bihurtuarazi, mota guztietako errore zoroak eraginez…
> …Beraz, baldin eta benetan egiten ari zarena jakiten baduzu, “uncaughtException” exzepzio ebentua jaso ostean zure zerbitzuaren berrekite dotorea egin beharko zenuke. Bestela, zure aplikazioaren egoera arriskuan jar dezakezu, edota haren liburutegiak aldakor bihurtuarazi, mota guztietako errore zoroak eraginez…
### Blogeko aipua: "Errore kudeaketaren inguruko hiru ideia-eskola daude"
### Blogeko aipua: "Errore kudeaketaren inguruko hiru ideia eskola daude"
JS Recipes blogetik
JS Recipes blogetik hartua
> …Errore kudeaketaren inguruko hiru ideia-eskola daude:
> …Errore kudeaketaren inguruko hiru ideia eskola daude:
1. Utzi aplikazioak kraskadura izan dezan eta ondoren berrekin ezazu.
2. Errore posible guztiak kudeatu eta inoiz ez eduki kraskadurarik.
3. Bien arteko planteamendu bat
1. Utzi aplikazioak huts egin dezan eta ondoren berrekin.
2. Kudeatu errore posible guztiak kudeatu eta inoiz ez huts egin.
3. Bien arteko planteamendu bat.

View File

@ -4,11 +4,11 @@
### Azalpen paragrafoa
Errore bat gertatzen denean, fluxu sinkrono edo asinkrono bat dela, errore fluxuaren pila aztarna guztia edukitzea derrigorrezkoa da. Funtzio asinkrono batek (adibidez beste funtzio asinkrono bat deitzen duena) itxaron gabe (await) promesak itzultzen dituenean, errore bat gertatuko litzateke eta jatorrizko funtzio honen izena ez litzateke pilaren aztarnan agertu beharko. Honek, errorea diagnostikatzen duen pertsona informazio partzialarekin utziko luke, are gehiago errorearen zergatiak jatorrizko funtzioan badu oinarria. Badago "zero-kostuko pila aztarna asinkronoak" deitzen den v8 funtzionalitate bat, pila aztarnak azken gertatu berri den `await`ean moztuak ez izatea ahalbidetzen duena. Garrantzirik gabeko inplementazio xehetasunak direla eta, honek ez du funtzionatuko funtzioak bueltatzen duen balioa (sinkronoa edo asinkronoa), promesa bat baldin bada. Promesak deuseztuak izango direnean pilaren aztarnan zuloak egotea ekiditeoko, promesak beti explizituki ebatzi behar ditugu `await` erabiliaz berauek funtzioetatik bueltatu baino lehen
Errore bat gertatzen denean fluxu sinkrono edo asinkrono batetik abiatuta, derrigorrezkoa da errore fluxuaren pila aztarna osoa edukitzea. Harrigarria bada ere, funtzio asinkrono batek (adibidez beste funtzio asinkrono bat deitzen duena) itxaron gabe (await) promesak itzultzen dituenean, errore bat gertatuko litzateke eta jatorrizko funtzio horren izena ez litzateke pilaren aztarnan agertu beharko. Horrek informazio partziala emango dio errorea diagnostikatzen duenari, are gehiago errorearen zergatiak jatorrizko funtzioan badu oinarria. Badago "zero-kostuko pila aztarna asinkronoak" deitzen den v8 funtzionalitate bat, pila aztarnak azken gertatu berri den `await`ean moztuak ez izatea ahalbidetzen duena. Garrantzirik gabeko inplementazio xehetasunak direla eta, horrek ez du funtzionatuko funtzioak bueltatzen duen balioa (sinkronoa edo asinkronoa), promesa bat baldin bada. Promesak deusezten direnean pilaren aztarnan zuloak egotea ekiditeoko, promesak beti esplizituki ebatzi behar ditugu `await` erabiliz beraiek funtzioetatik bueltatu baino lehen
<br/>
### Kodearen adibidea Anti-Eredua: funtzio asinkrono bat deitu itxaron gabe
### Anti ereduaren kode adibidea: funtzio asinkronoak deitu itxaron gabe
<details><summary>Javascript</summary>
<p>
@ -36,7 +36,7 @@ Errorea: bueltatuItxaronGabe falta da pilaren aztarnan
</p>
</details>
### Kodearen adibidea: zZuzenki deitu eta itxaron
### Kode adibidea: zuzenean deitu eta itxaron
<details><summary>Javascript</summary>
<p>
@ -68,7 +68,7 @@ Error: zati guztiak edukiz
<br/>
### Kodearen adibidea Anti-Eredua: promesa bat bueltatu funtzio bat asinkronotzat etiketatu gabe
### Anti ereduaren kode adibidea: itzuli promesak funtzioak asinkronotzat etiketatu gabe
<details><summary>Javascript</summary>
<p>
@ -102,7 +102,7 @@ Error: syncFn falta da pilaren aztarnan
</p>
</details>
### Kodearen adibidea: etiketatu promesak asinkrono gista bueltatzen dituen funtzioa
### Kode adibidea: etiketatu promesak asinkrono gisa itzultzen dituen funtzioa
<details><summary>Javascript</summary>
<p>
@ -139,7 +139,7 @@ Error: zati guztiak edukiz
</br>
### Kodearen adibidea Anti-eredua #3: callback asinkrono baten erabilera zuzena callback sinkrono bat espero zen lekuan
### Kode adibidea, anti eredua #3: callback asinkronoen erabilera zuzena callback sinkronoa espero zen lekuan
<details><summary>Javascript</summary>
<p>
@ -170,7 +170,7 @@ Error: pilaren aztarna falta da berreskuratuErabiltzailea deitu den lekuan
</p>
</details>
### Kodearen adibidea: callback asinkronoa funtzio asinkrono babo batekin bildu callback asinkrono gisa pasa aurretik
### Kode adibidea: bildu callback asinkronoa funtzio asinkrono faltsu batean callback sinkrono gisa bidali aurretik
<details><summary>Javascript</summary>
<p>
@ -225,33 +225,35 @@ Error: [...]
<br/>
zero-kostuko pila aztarna asinkronoak" deitzen den v8 funtzionalitate bat
Zero kostuko pila aztarna asinkronoak" deitzen den v8 funtzionalitate bat
## Azalpen aurreratua
Funtzio sinkronoen pila aztarnen eta funtzio asinkronoen pila aztarnen meknismoak v8ren ezarpenetan oso ezberdinak dira:
pila aztarna asinkronoa Node.js martxan dagoen sistema eragileak emandako **pila**n oinarritua dago (programazio lengoaia gehienetan bezala). Funtzio asinkrono bat exekutatzen ari denean, sistema eragileko **pila** agerian jartzen da funtzioa bere lehen `await`era iristen den momentuan. Beraz, pilaren aztarna, sistema eragilearen **pila**ren eta baztertutako **promesa ebazpen katea**ren nahasketa bat da. Zero-kostuko pila aztarna asinkronoen ezarpenak **promesa ebazpen katea**ren du jatorria soilik promesa `itxaroten` <span>[¹](#1)</span> ari den bitartean. Nola bakarrik funtzio `asinkrono`ek (`async`) `itxaron`go (`await`) duten, beti galduko da funtzio asinkronoa pilaren aztarna asinkrono batean, operazio asinkronoren bat egina izan bada funtzioa deitu eta gero <span>[²](#2)</span>
Oso ezberdinak dira funtzio sinkronoen pila aztarnen eta funtzio asinkronoen pila aztarnen mekanismoak v8ren ezarpenetan: pila aztarna asinkronoa oinarritua dago Node.js martxan dagoen sistema eragileak emandako **pila**n (programazio lengoaia gehienak bezala). Funtzio asinkrono bat exekutatzen ari denean, sistema eragileko **pila** agerian jartzen da funtzioa bere lehen `await`era iristen den momentuan. Beraz, pilaren aztarna nahasketa bat da, hain zuzen, sistema eragilearen pilaren eta baztertutako **promesa ebazpen katea**rena. Zero kostuko pila aztarna asinkronoen ezarpenak **promesa ebazpen katea** luzatzen du bakarrik promesa `itxaroten` <span>[¹](#1)</span> ari den bitartean. Funtzio asinkronoek bakarrik (`async`) itxaron (`await`) ahal dutenez, beti galduko da funtzio asinkronoa pilaren aztarna asinkrono batean, operazio asinkronoren bat izan bada funtzioa deitu eta gero <span>[²](#2)</span>
### The tradeoff (sektorea)
`await` bakoitzak mikro ataza berri bat sortzen du ebentuen begiztan, beraz `await` gehiago gehitzeak errendimendu isunak sortu ditzake. Hala ere, sareak edota datu baseak sortutako errendimendu isuna [ikaragarri handiagoa](https://colin-scott.github.io/personal_website/research/interactive_latency.html) da, beraz gehitutako `await`aren isuna ez da zerbitzariak edo CLIak garatzeko orduan kontutan hartu beharreko zerbait, eskaera edo komando zailen kodearentzat ez bada behintzat. Orduan, `await` ezabatzea `return await`etan errendimendu bultzada nabarmenak bilatzeko azken lekua izan beharko lukete eta, zalantzarik gabe, inoiz ez lirateke aldez aurretik eginak izan beharko
`await` bakoitzak mikro ataza berri bat sortzen du gertaeraren begiztan. Beraz `await` gehiago gehitzeak errendimendu zigorra ekarriko luke. Hala ere, sareak edota datu baseak sortutako errendimendu isuna [ikaragarri handiagoa](https://colin-scott.github.io/personal_website/research/interactive_latency.html) da, eta, beraz gehitutako `await`aren zigorra ez da zerbitzariak edo CLIak garatzeko orduan kontutan hartu beharreko zerbait, eskaera edo komando bakoitzeko oso kode beroa izan ezean behintzat. Orduan, `await` ezabatzeak `return await`etan errendimendu bultzada nabarmena bilatzeko azken lekua izan beharko luke eta, zalantzarik gabe, inoiz ez litzateke aldez aurretik egin beharko
### Zergatik await bueltatazea anti eredutzat jotzen zen iraganean
[Artikulu bikain](https://jakearchibald.com/2017/await-vs-return-vs-return-await/) ugari daude zergatik `return await`ak inoiz `try` bloke baten kanpoan erabili behar diren azaltzen dutenak, eta [ESLint arau](https://eslint.org/docs/rules/no-return-await) bat ere hau ezesten duena. Honen arrazoia async/await Node.js 0.10ko transpilatzaileekin (eta berezko sostengua lortu du Node.js 7.6n) erabilgarri bihurtu izana eta "zero kostuko pila aztarna asinkronoak" Node.js 10en gehitua izana eta ondoren Node.js 12n kenua, `return await` eta `return` guztiz parekoak ziren, edozein `try` kode bloketik kanpo. Oraindik ere berdina izaten jarraituko du seguraski ES motoreentzat. Honegatik, promesak kalkulatzea berauek bueltatu aurretik Node.jsentzat jarraibide egokiena da eta ez orokorrean EcmaScriptentzat
### Zergatik jotzen zen await bueltatzea anti eredutzat iraganean
[Artikulu bikain](https://jakearchibald.com/2017/await-vs-return-vs-return-await/) ugari daude azaltzen dutenak zergatik `return await`ak ez diren inoiz `try` bloketik kanpo erabili behar, bai eta [ESLint arau](https://eslint.org/docs/rules/no-return-await) arau bat ere hori debekatzen duena. Horren arrazoia da async/await Node.js 0.10ko transpilagailuekin erabilgarri bihurtu izana (eta jatorrizko laguntza lortu dutela Node.js 7.6 bertsioan) eta "zero kostuko pila aztarna asinkronoak" Node.js 10en gehitua izana eta ondoren Node.js 12tik kendua, `return await` eta `return` guztiz parekoak ziren, edozein `try` kode bloketik kanpo. Oraindik ere berdina izaten jarraituko du seguraski ES motoreentzat. Horregatik, Node.jsentzat jardunbide egokiena da promesak kalkulatzea beraiek bueltatu aurretik. EcmaScriptentzat, ordea, hori ez jardunbide egokiena.
### Oharrak:
1. Pila aztarna asinkronoak halako ezarpen korapilatsua izatearen beste arrazoietako bat pila aztarna beti modu sinkronoan eraiki behar izanaren muga da, ebentuaren begiztaren <span id="a1">[¹](#1)</span> momentu berean
2. `throwAsync` barruan `await` gabe, kodea ebentu begiztaren fase berean exekutatuko litzateke. Hau, sistema eragilearen **pila** hustutzen ez deneko eta pila aztarna esplizituki funtzioaren emaitza itxaron gabe ere betetzen deneko kasu degeneratua da. Normalean, promesen erabilerak operazio asinkrono batzuk edukitzen ditu, non pilaren aztarnaren zati batzuk galduak izango diren
3. Zero-kostuko pila aztarna asinkronoek promesa erabilera kasu konplikatuentzat ez dute funtzionatuko, adibidez askotan eta leku ezberdinetan itxarondako promesa bakarra
1. Pila aztarna asinkronoak halako ezarpen korapilatsua izatearen beste arrazoi bat da pila aztarna beti modu sinkronoan eraiki behar dela, gertaeraren begiztaren <span id="a1">[¹](#1)</span> momentu berean
2. `throwAsync` barruan `await` gabe, gertaera begiztaren fase berean exekutatuko litzateke kodea. Hori, degeneratutako kasua da: sistema eragilearen **pila** ez litzateke hustuko, eta pila aztarna beteko litzateke funtzioaren emaitzari berariaz itxaron gabe ere. Normalean, promesen erabilerak operazio asinkrono batzuk edukitzen dituenez, pilaren aztarnaren zati batzuk galdu egingo lirateke
3. Zero kostuko pila aztarna asinkronoek ez lukete funtzionatuko promesa erabileren kasu korapilatsuetan: promesa bakar bati hainbat aldiz eta leku ezberdinetan itxaron beharra dagoenean, adibidez.
### Erreferentziak:
<span id="1">1. </span>[v8ko zero-kostuko pila aztarna asinkronoak blog argitarapena](https://v8.dev/blog/fast-async)
<span id="1">1. </span>[v8ko zero kostuko pila aztarna asinkronoak blog argitarapena](https://v8.dev/blog/fast-async)
<br>
<span id="2">2. </span>[zero-kostuko pila aztarna asinkronoei inguruko dokumentazioa ezarpen xehetasunekin hemen](
<span id="2">2. </span>[zero kostuko pila aztarna asinkronoei inguruko dokumentazioa ezarpen xehetasunekin hemen](
https://docs.google.com/document/d/13Sy_kBIJGP0XT34V1CV3nkWya4TwYx9L3Yv45LdGB6Q/edit
)
<br>

View File

@ -2,9 +2,9 @@
### Azalpen paragrafoa
Zure kodearen lekuren batean, errore kudeaketa objektua errore bat gertatzen denean nola jokatu erabakitzearen arduradun da, errorea konfiantzazkoa bada (adibidez operazio errorea, irakurri azalpen osatuagoa #3 jarraibide egokian) erregistro fitxategian idaztea nahikoa izango da. Gauzak okertzen dira errorea ezezaguna denean, honek osagairen bat egoera txarrean dagoela eta hurrengo eskaera guztiek huts egiteko aukera handia dutela esan nahi du eta. Adibidez, singleton bat edukiaz, token batek exzepzio bat jaurti eta ondoren bere egoera galdu duen zerbitzu batekin arazoa du, hemendik aurrera ustekabean joka dezake eta eskaera guztiek huts egitea eragin. Egoera honen aurrean, prozesua gelditu eta 'Berrekite tresna' erabili (Forever, PM2, etab. bezalakoak) egoera garbi batekin berriz hasteko.
Zure kodearen lekuren batean, erroreren bat gertatzen denean erroreen kudeaketa objektuaren ardura da erabakitzea nola jokatu, eta, errorea konfiantzazkoa bada, nahikoa izango da erregistro fitxategian idaztea; errorea operazionala bada, berriz, irakurri azalpen osatuagoa #3 jarraibide egokian). Gauzak okertzen dira errorea ezezaguna denean, horrek osagairen bat egoera txarrean dagoela eta hurrengo eskaera guztiek huts egiteko aukera handia dutela esan nahi du eta. Adibidez, eman dezagun, singleton bat edukita, token batek salbuespen bat igorri duela eta ondoren bere egoera galdu duen zerbitzu batekin arazoa duela; hortik aurrera ustekabean joka dezake eta eskaera guztiek huts egitea eragin. Egoera horren aurrean, prozesua gelditu eta 'Berrekite tresna' erabili (Forever, PM2, etab. bezalakoak) egoera garbi batekin berriz hasteko.
### Kodearen adibidea: krak egin ala ez erabakitzen
### Kode adibidea: huts eragin ala ez erabakitzen
<details>
<summary><strong>Javascript</strong></summary>
@ -77,23 +77,23 @@ export const kudeatzailea = new ErroreKudeatzailea();
```
</details>
### Blogeko aipua: "Irtenbiderik hoberena krak egitea da"
### Blogeko aipua: "Irtenbiderik hoberena huts egitea da"
Joyent blogetik
Joyent blogetik hartua
> …Programatzaile erroreetatik suspertzeko modurik hoberena berehala krak egitea da. Hutsegite gertaraki baten aurrean programa automatikoki berrekingo duen berrekite sistema bat erabili beharko zenuke zure programetan. Berrekite sistema baten erabileraz, programatzaile errore pasakor baten aurrean krak egitea zerbitzu fidagarri bat suspertzeko modurik azkarrena da…
> …Programatzaileen erroreak konpontzeko modurik hoberena berehala krak egitea da. Programaren batek huts eginez gero, berrabiarazle bat erabiliz exekutatu beharko zenuke, automatikoki berrabiaraziko baitu. Berrabiarazlea dagoenean, huts egitea da programa fidagarria berreskuratzeko biderik azkarrena programatzailearen errore iragankor baten aurrean ...
### Blogeko aipua: "Errore kudeaketaren inguruko hiru ideia-eskola daude"
### Blogeko aipua: "Errore kudeaketaren inguruko hiru ideia eskola daude"
JS Recipes blogetik
JS Recipes blogetik hartua
> …Errore kudeaketaren inguruko hiru ideia-eskola nagusi daude:
1. Utzi aplikazioak kraskadura izan dezan eta ondoren berrekin ezazu
2. Errore posible guztiak kudeatu eta inoiz ez eduki kraskadurarik
> …Errore kudeaketaren inguruko hiru ideia eskola nagusi daude:
1. Utzi aplikazioari huts egiten eta ondoren berrabiarazi
2. Errore posible guztiak kudeatu eta inoiz ez huts egin
3. Bien arteko planteamendu bat
### Blogeko aipua: "Alde egiteko modu segururik ez zehaztugabeko egoera hauskor bat sortu gabe"
### Blogeko aipua: "Ez dago modu segururik irteteko zehaztugabeko egoera hauskorrik sortu gabe"
Node.js dokumentazio ofizialetik
Node.js dokumentazio ofizialetik hartua
> …JavaScripten throwen funtsezko funtzionamenduan, ez dago ia inoiz "alde batera utzitakoa jasotzeko" modu seguruan egiteko biderik, erreferentziak galdu gabe edota bestelako zehaztugabeko egoera hauskorrak sortu gabe. Jaurtitako errore bati erantzuteko modurik seguruena prozesua itzaltzea da. Jakina, web zerbitzari arrunt batean, konekxio ugari eduki ahal ditzakezu irekita, eta ez da zentzuzkoa tupustean hauek ixtea beste batek eragindako errore batengatik. Planteamendu hoeberena, errorea bidali duen eskariari errore erantzun bat bidaltzea da, besteei beren atazak bukatzeko denbora utziz, eta eskari berriei kasu egiteari utzi prozesu horretan.
> …JavaScripten lanak nola exekutatzen diren kontuan izanda, ez dago ia inoiz lan bati ziurtasunez jarraipena emateko biderik utzitako puntuan hasita, erreferentziak galdu gabe edota bestelako zehaztugabeko egoera hauskorrik sortu gabe. Jaurtitako errore bati erantzuteko modurik seguruena prozesua itzaltzea da. Jakina, web zerbitzari arruntetan, konekxio ugari eduki ahal dituzu irekita, eta ez da zentzuzkoa tupustean haiek ixtea beste batek eragindako errore batengatik. Planteamendu hoberena da bidaltzea errore erantzun bat errorea bidali duen eskariari, besteei beren atazak bukatzeko denbora utziz, eta eskari berriei kasu egiteari uztea prozesu horretan.

View File

@ -2,9 +2,10 @@
### Azalpen paragrafoa
Bide alaiak frogatzea ez da huts egiteak frogatzea baino hobea. Kode frogatze estaldura onak ezohiko bideak frogatzea eskatzen du. Bestela, ez dago exzepzioak modu zuzenean kudeatuta daudenaren inolako konfidantzarik. Unitate test framework guztiek, adibidez [Mocha](https://mochajs.org/) edo [Chai](http://chaijs.com/), exzepzio frogaketa sostengatzen dute (kode adibideak beherago). Gogaikarria iruditzen bazaizu funtzio eta exzepzio bakoitza frogatzea, soilik REST APIen HTTP erroreak frogatzea erabaki zenezake.
Bide alaiak probatzea ez da hutsegiteak probatzea baino hobea. Probako kodeen estaldura ona da salbuespenezko bideak probatzeko. Bestela, ez dago inolako konfidantzarik salbuespenak zuzen kudeatuta dauden. Unitateen azterketa esparru guztiek, [Mocha](https://mochajs.org/) edo [Chai](http://chaijs.com/) bezala, onartzen dituzte salbuespen probak (kode adibideak beherago). Gogaikarria iruditzen bazaizu funtzio eta salbuespen bakoitza probatzea, REST APIen HTTP erroreak bakarrik probatzea erabaki zenezake.
### Kodearen adibidea: Mocha eta Chai erabiliz ziurtatu exzepzio egokia jaurtitzen dela
### Kode adibidea: ziurtatu salbuespen egokia jaurtitzen dela Mocha eta Chai erabiliz
<details>
<summary><strong>Javascript</strong></summary>

View File

@ -2,18 +2,18 @@
### Azalpen paragrafoa
Gustuko dugu console.log, baina [Pino][pino] (errendimenduan zentratutako aukera berriago bat)a newer option focused on performance) bezalako erregistratzaile tresna ospetsu eta iraunkor bat ezinbestekoa da proiektu serioetarako.
Errendimendu handiko erregistratze tresnek erroreak eta arazoa posibleak identifikatzen laguntzen dute. Erregistratze aholkuen artean:
1. Maila ezberdinak (debug, info, error) erabiliz erregistratze maistasuna
2. Erregistratzerako orduan, kontextuaren informazioa eman JSON objektu eran
3. Erregistro kontsulta API batekin (erregistro sistema ezberdinetarako erabilgarria) edota erregistro bistaratze software batekin monitorizatu eta filtratu erregistroak
4. Erregistroen informazioa [Splunk][splunk] bezalako operazio inteligentzia tresnekin erakutsi eta landu
Gustuko dugu console.log, baina [Pino][pino] bezalako erregistratzaile tresna ospetsu eta iraunkorra (errendimenduan zentratutako aukera berriagoa) ezinbestekoa da proiektu serioetarako. Errendimendu handiko erregistratze tresnek erroreak eta arazo posibleak identifikatzen laguntzen dute. Erregistratze aholkuen artean:
1. Maiz erregistratu maila ezberdinak erabiliz (debug, info, error)
2. Erregistratzerako orduan, eman testuinguruaren informazioa JSON objektu eran
3. Monitorizatu erregistro kontsultak API batekin (erregistro sistema ezberdinetarako erabilgarria) edota erregistro ikustailearen software batekin
4. Erakutsi erregistroen informazioa [Splunk][splunk] bezalako operazio inteligentzia tresnekin
[pino]: https://www.npmjs.com/package/pino
[splunk]: https://www.splunk.com/
### Kodearen adibidea
### Kode adibidea
```JavaScript
const pino = require('pino');
@ -25,18 +25,19 @@ const erregistratzailea = pino();
erregistratzailea.info({ anything: 'Hau metadatua da' }, 'Frogatu Erregistro Mezua %s parametroren batekin', 'parametroren bat');
```
### Blogeko aipua: "Erregistratzailearen Betebeharrak"
### Blogeko aipua: "Erregistratzailearen betebeharrak"
StrongLoop blogetik ("Winston eta Bunyanen Node.js Erregistratzaile sistemak konparatzen" Alex Corbatcheven eskutik, 2014ko ekainaren 24a):
StrongLoop blogetik hartua ("Winston eta Bunyanen Node.js Erregistratzaile sistemak konparatzen" Alex Corbatcheven eskutik, 2014ko ekainaren 24a):
> Identifika ditzagun betebehar gutxi batzuk (erregistratzaile batentzat):
>
> 1. Denboran seilatu erregistro ilara bakoitza. Nahiko argi dago, erregistroko sarrera bakoitza noiz gertatu den esateko gai izan behar duzu
> 2. Erregistro formatua ulergarria izan behar da bai gizakientzat eta baita makinentzat ere
> 3. Korronte ezberdin ugari onartu behar ditu. Adibidez, errore erregistroak fitxategi batean idazten egon zintezke eta momentu horretan errore bat antzematen bada, fitxategi beraren barruan idatzi, errorearen fitxategian ere idatzi, eta posta elektroniko bat bidali, dena aldi berean, egiteko aukera eman behar du
> 3. Korronte ezberdin ugari onartu behar ditu. Adibidez, errore erregistroak fitxategi batean idazten ari den unean errorereb bat atzemanez gero, fitxategi beraren barruan idatzi, errorearen fitxategian ere idatzi, eta posta elektronikoa bidali, dena aldi berean, egiteko aukera eman behar du
### Non dago Winston?
Zergatik ohizko gustukoak hemengo aholkatutako jarraibide hoberenen zerrendan agertu beharko ez liratekeela jakiteko, begiratu [#684][#684].
Zergatik ohiko faboritoak (adibidez, Winston) ez dauden aholkatutako jardunbide
onenen egungo zerrendan jakiteko, begiratu [#684][#684]an
[#684]: https://github.com/goldbergyoni/nodebestpractices/issues/684

View File

@ -2,9 +2,9 @@
### Azalpen paragrafoa
JavaScripten permisibitate naturalak, bere kode fluxuaren aukera guztiekin (adibidez EventEmitter, Callbackak, Promesak ...) garatzaileek erroreak kudeatzeko modu anitzak edukitzea eragiten du: batzuek stringak erabiltzen dituzte, besteek beren mota pertsonalizatuak zehazten dituzte. Node.jsen "Errorea" objektu kapsulatua erabiltzeak zure kodearen eta bestelako liburutegien arteko uniformetasuna gordetzen laguntzen du, eta gainera StracTracea bezalako informazio esanguratsua gordetzen du. Exzepzio bat jaurtitzean, errorearen izena edo erlazionatutako HTTP errore kodea bezalako kontextu ezaugarriekin osatzeza jarraibide egokia da. Uniformetasun eta praktika hau lortzeko, saiatu "Errorea" objektua beharrezko ezaugarriekin osatzen, baina kontu izan gehiegitan ez egitearekin. Orokorrean ideia ona da "Errorea" objektu kapsulatua behin bakarrik osatzea AppErrore batekin aplikazioaren maila guztietako erroreentzat, eta beharrezko duzun informazioa argumentu gisa pasatuz errore mota ezberdinak ezberdintzeko. Ez da beharrezkoa "Errorea" objektua askotan osatzea (errore kasu bakoitzerako behin, adibidez DbError, HttpError...). Begiratu ondorengo kode adibideak
JavaScriptek berezko permisibitatea du, eta, bere kode fluxuaren aukera ugariarekin (adibidez EventEmitter, Callbackak, Promesak ...), garatzaileek erroreak kudeatzeko modu anitzak edukitzea eragiten du: batzuek stringak erabiltzen dituzte, besteek beren mota pertsonalizatuak zehazten dituzte. Node.jsen "Errorea" objektu kapsulatua erabiltzeak zure kodearen eta bestelako liburutegien arteko uniformetasuna gordetzen laguntzen du, eta gainera StracTracea bezalako informazio esanguratsua gordetzen du. Salbuespen bat jaurtitzean, jarraibide egokia da errorearen izena edo erlazionatutako HTTP errore kodea bezalako testuinguru ezaugarriekin osatzea. Uniformetasun eta praktika hau lortzeko, saiatu "Errorea" objektua beharrezko ezaugarriekin osatzen, baina kontu izan gehiegitan ez egiten. Orokorrean ideia ona da "Errorea" objektu kapsulatua behin bakarrik osatzea AppErrore batekin aplikazioaren maila guztietako erroreentzat, eta beharrezko duzun informazioa argumentu gisa pasatuz errore klase ezberdinak ezberdintzeko. Ez da beharrezkoa "Errorea" objektua askotan osatzea (errore kasu bakoitzerako behin, adibidez DbError, HttpError...). Begiratu ondorengo kode adibideak
### Kodearen adibidea: era zuzenean egin
### Kode adibidea: era zuzenean egin
```javascript
// ohizko funtzio batean Error objektua jaurti, sinkronoa dela edo asinkronoa dela (sync async)
@ -30,7 +30,7 @@ const gehituProduktua = async (gehitzekoProduktua) => {
};
```
### Kodearen adibidea: anti Jarraibidea
### Anti jarraibidearen kode adibidea
```javascript
// string baten jaurtiketak edozein pila informazio eta datu ezaugarri garrantzitsu falta ditu
@ -38,7 +38,7 @@ if (!gehitzekoProduktua)
throw "Nola gehi dezaket produktu bat baliorik ez duenean?";
```
### Kodearen adibidea: oraindik ere era zuzenagoan egin
### Kode adibidea: oraindik ere era zuzenagoan egin
<details>
<summary><strong>Javascript</strong></summary>
@ -111,26 +111,26 @@ if (erabiltzailea == null)
_`Object.setPrototypeOf`ri buruzko azalpena Typescripten: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-2.html#support-for-newtarget_
### Blogeko aipua: "Ez dut mota ezberdin ugari edukitzean interesik ikusten"
### Blogeko aipua: "Ez diot interesik ikusten mota ezberdin ugari edukitzeari"
Ben Nadel blogetik, “Node.js errore objektua” 5 hitz gakori esker sailkatua
Ben Nadel blogeko “Node.js errore objektua” 5 hitz gakori esker sailkatua
> …”Modu pertsonalean, ez dut mota ezberdin ugari edukitzean interesik ikusten [bakarra edukitzearekin alderatuz] - Ez dirudi JavaScriptek, lengoaia gisa, eraikitzailez-oinarritutako errore-harrapaketa hornitzerik. Horrela, objektu baten ezaugarriak bereizteak Eraikitzaile motak bereiztea baino errazagoa dirudi…
> …”Nik neuk, ez diot interesik ikusten errore objektu klase ezberdin ugari edukitzeari [bakarra edukitzearekin alderatuz]. Ez dirudi JavaScriptek, lengoaia gisa, eraikitzailez oinarritutako errore harrapaketa hornitzen duenik. Horrela, objektu baten ezaugarriak bereizteak Eraikitzaile klaseak bereiztea baino errazagoa dirudi…
### Blogeko aipua: "String bat ez da errore bat"
devthought.com blogetik, “Node.js errore objektua” 6 hitz gakori esker sailkatua
devthought.com blogeko “Node.js errore objektua” 6 hitz gakori esker sailkatua
> …String baten ordez errore bat pasatzeak moduluen arteko elkarreragintasuna murrizten du. `instanceof` errore egiaztapen arrakastatsuak izan litezken kontratuak apurtzen ditu APIekin. Errore objektuek, ikusiko dugun bezala, Javascript motore modernoetan ezaugarri interesgarriak dituzte eraikitzaileari pasatutako mezua kontserbatzeaz gain
> …String baten ordez errore bat pasatzeak moduluen arteko elkarreragintasuna murrizten du. instanceof errore egiaztapen arrakastatsuak izan litezken kontratuak apurtzen ditu APIekin. Ikusiko dugun bezala, errore objektuek, eraikitzaileari pasatutako mezua kontserbatzeaz gain, Javascript motore modernoetan ezaugarri interesgarriak dituzte…
### Blogeko aipua: "Erroretik jaraunsteak ez du balio askorik gehitzen"
machadogj blogetik
machadogj blogetik hartua
> …Error klasearekin daukadan arazo bat jaraunsteko erraza ez izatea da. Noski, klasea jarauntsi dezakezu eta zure HttpError, DbError, etab. bezalako Error klase propioak sortu. Hala ere, horrek denbora eskatzen du eta ez du balio askorik gehitzen[AppError batentzat behin bakarrik jaraunsteaz alderatuz] baldin eta motekin zerbait egiten ez bazabiltza. Batzuetan, soilik mezu bat gehitu nahi duzu eta barruko errorea mantendu, beste batzuetan ordea, errorea parametro edo bestelako informazioekin osatu nahi zenezake…
> …Errore klasea jaraunsteko erraza ez izatea arazo bat da. Noski, klasea jaraunts dezakezu eta zure HttpError, DbError, etab. bezalako Error klase propioak sortu. Hala ere, horrek denbora eskatzen du, eta ez du balio askorik gehitzen [AppError batentzat behin bakarrik jaraunsteaz alderatuz], baldin eta klaseekin zerbait egiten ez bazabiltza. Batzuetan, soilik mezu bat gehitu nahi duzu eta barruko errorea mantendu; beste batzuetan, ordea, errorea parametroekin edo bestelako informazioekin osatu nahi zenezake…
### Blogeko aipua: "Node.jsek jaurtitako JavaScript eta System errore guztiak "Error" objektutik datoz"
Node.js dokumentazio ofizialetik
Node.js dokumentazio ofizialetik hartua
> …Node.jsek jaurtitako JavaScript eta System errore guztiak JavaScripten "Error" klase estandarretik datoz edo "Error" objektuaren instantziak dira eta gutxienez klase horretako ezaugarri erabilgarriak hornitzea bermatzen dute. Errorea zergatik gertatu den inolako berariazko baldintzarik adierazten ez duen JavaScript Error objektu generikoa. Error objektuek "pila aztarna" bat atzematen dute, Error instantziatua izan den kodearen lekua zehaztuz, eta errorearen testu deskribapena eduki dezakete. Node.jsek sortutako errore guztiak, System eta JavaScript erroreak barne, Error klasetik eratorritakoak edo Error klasearen instantziak izango dira…
> …Node.jsek jaurtitako JavaScript eta System errore guztiak JavaScripten "Error" klase estandarretik datoz edo "Error" objektuaren instantziak dira, eta gutxienez horrelako ezaugarri erabilgarriak hornitzea bermatzen dute. JavaScript Error objektu generiko bat da, errorea zergatik gertatu den inolako berariazko baldintzarik adierazten ez duena. Error objektuek "pila aztarna" bat atzematen dute, Error instantziatua izan den kodearen lekua zehaztuz, eta errorearen testu deskribapena eduki dezakete. Node.jsek sortutako errore guztiak, System eta JavaScript erroreak barne, Error klasetik eratorritakoak edo Error motaren instantziak izango dira…

View File

@ -4,8 +4,7 @@
### Azalpen paragrafoa
Tamaina ertaineko nahiz handiko aplikazioetarako, monolitoak benetan kaltegarriak dira. Menpekotasun asko dituen software handi bat edukitzea zaila da hausnartzeko eta maiz espageti kodea eragiten du. Arkitektu azkarrek ere, piztia mantsotzeko eta zatikatzeko haina gaitasun dituztenek, diseinuan esfortzu mental handiak egiten dituzte, eta aldaketa bakoitzak menpeko beste objektuekiko eragina arretaz aztertzea eskatzen du. Azken irtebidea software txikia garatzean datza: banandu kode pila osoa fitxategiak beste inorekin partekatzen ez dituzten aparteko osagaietan, bakoitza fitxategi gutxi batzuekin osatua egonik (APIa, zerbitzuak, datuen sarbidea, egiaztatzeak, etab.) oso erraza da hausnartzeko. Askok mikrozerbitzu' egitura deitzen diote horri, garrantzitsua da ulertzea mikrozerbitzuak oinarri sorta bat direla eta ez derrigorrez jarraitu beharreko zehaztapenak. Printzipio ugari erabil ditzakezu mikrozerbitzudun egitura handi batean edota gutxi batzuk soilik. Biak dira zuzenak zure softwarearen konplexutasuna baxua den bitartean. Gutxienez, egin zenezakeen beste zerbait da osagaien artean oinarrizko mugak sortzea, zure proiektuaren erroan karpeta bat egokitzea osagai logiko bakoitzarentzat eta autonono bihurtzea: beste osagaiek haren funtzionalitatea erabili ahal izango dute soilik bere interfaze publikotik edo APItik pasatuz. Hau oinarrizkoa da zure osagaiak sinpleak izateko, menpekotasunen korapiloa ekiditeko eta zure aplikazioa mikrozerbitzu egitura handietarako prestatzeko.
Tamaina ertaineko nahiz handiko aplikazioetarako, monolitoak benetan kaltegarriak dira. Menpekotasun asko dituen software handi bat edukitzea zaila da hausnartzeko eta maiz espageti kodea eragiten du. Arkitektu azkarrek ere, piztia mantsotzeko eta zatikatzeko haina gaitasun dituztenek, diseinuan esfortzu mental handiak egiten dituzte, eta aldaketa bakoitzak menpeko beste objektuekiko eragina arretaz aztertzea eskatzen du. Azken irtebidea software txikia garatzean datza: banandu kode pila osoa fitxategiak beste inorekin partekatzen ez dituzten aparteko osagaietan, bakoitza fitxategi gutxi batzuekin osatua egonik (APIa, zerbitzuak, datuen sarbidea, egiaztatzeak, etab.) oso erraza da hausnartzeko. Askok 'mikrozerbitzu' egitura deitzen diote horri, garrantzitsua da ulertzea mikrozerbitzuak oinarri sorta bat direla eta ez derrigorrez jarraitu beharreko zehaztapenak. Printzipio ugari erabil ditzakezu mikrozerbitzudun egitura handi batean edota gutxi batzuk soilik. Biak dira zuzenak zure softwarearen konplexutasuna baxua den bitartean. Gutxienez, egin zenezakeen beste zerbait da osagaien artean oinarrizko mugak sortzea, zure proiektuaren erroan karpeta bat egokitzea osagai logiko bakoitzarentzat eta autonono bihurtzea: beste osagaiek haren funtzionalitatea erabili ahal izango dute soilik bere interfaze publikotik edo APItik pasatuz. Hau oinarrizkoa da zure osagaiak sinpleak izateko, menpekotasunen korapiloa ekiditeko eta zure aplikazioa mikrozerbitzu egitura handietarako prestatzeko.
<br/><br/>
### Blogeko aipua: "Eskalatzeak aplikazio osoaren eskalatzea eskatzen du"
@ -13,7 +12,6 @@ Tamaina ertaineko nahiz handiko aplikazioetarako, monolitoak benetan kaltegarria
MartinFowler.com blogetik hartua
> Aplikazio monolitikoak arrakastatsuak izan daitezke, baina jendeak gero eta frustrazio gehiago ditu beraiekin, batez ere gero eta aplikazio gehiago inplementatzen direlako lainoan. Aldaketa zikloak elkarrekin lotuta daude: aplikazioaren zati txiki batean egindako aldaketak monolito osoa bersortzea eta inplementatzea eskatzen du. Askotan zaila da denbora aurrera joan ahala moduluzko egitura egokia mantentzea, modulu batean bakarrik eragina izango dituzten aldaketak mantentzea. Eskalatzeak aplikazio osoaren eskalatzea eskatzen du
<br/><br/>
### Blogeko aipua: "Zergatik egiten du garrasi zure aplikazioaren egiturak?"

View File

@ -20,7 +20,7 @@ Konfigurazio liburutegi batzuek aipatutako funtzionalitate gehienak dohainik esk
<br/><br/>
### Kodearen adibidea: konfigurazio hierarkikoak balioak aurkitzen eta konfigurazio fitxategi handiak mantentzen laguntzen du
### Kode adibidea: konfigurazio hierarkikoak balioak aurkitzen eta konfigurazio fitxategi handiak mantentzen laguntzen du
```json5
{

View File

@ -8,7 +8,7 @@ Azken Express sorgailuak mantentzea merezi duen sekulako jardunbide bikain bat d
<br/><br/>
### Kodearen adibidea: APIaren deklarazioak app.js/app.ts-en barruan egon beharko luke
### Kode adibidea: APIaren deklarazioak app.js/app.ts-en barruan egon beharko luke
```javascript
const app = express();
@ -17,7 +17,7 @@ app.use("/api/events", events.API);
app.use("/api/forms", forms);
```
### Kodearen adibidea: zerbitzari sarearen deklarazioak /bin/www-en barruan egon beharko luke
### Kode adibidea: zerbitzari sarearen deklarazioak /bin/www-en barruan egon beharko luke
<details>
<summary><strong>Javascript</strong></summary>
@ -53,7 +53,7 @@ const server = http.createServer(app);
</details>
### Kodearen adibidea: zure APIa prozesua martxan den bitartean probatu supertest (frogentzako pakete ospetsua) erabiliz
### Kode adibidea: zure APIa prozesua martxan den bitartean probatu supertest (frogentzako pakete ospetsua) erabiliz
<details>
<summary><strong>Javascript</strong></summary>

View File

@ -4,7 +4,8 @@
### Azalpen paragrafoa
Hazten hasi eta zerbitzari ezberdinetan antzeko baliabideak erabiltzen dituzten gero eta osagai ezberdin gehiago dituzun heinean, menpekotasunak kudeatzen hasi beharko zenuke. Nola gorde zenezake zure baliabidearen iturburu kodearen kopia bat eta beste osagaiei hura erabiltzen eta inplementatzen utzi? Bada, npm izeneko tresna bat badago horretarako... Hasi baliabide paketeetan zure kodea jartzen, etorkizunean kodearen ordezkapena errazteko eta argitaratu zure kode propioa npm pakete pribatu gisa. Horrela, zure kodeak beste kode hori inportatu ahal izango du, debaldeko menpekotasun kudeaketa tresnari esker. Posible da zure erabilera pribaturako npm paketeak argitaratzea, haiek publikoki partekatu gabe, [modulu pribatuak](https://docs.npmjs.com/private-modules/intro), [erregistro pribatua](https://npme.npmjs.com/docs/tutorials/npm-enterprise-with-nexus.html) edo [npm pakete lokalak](https://medium.com/@arnaudrinquin/build-modular-application-with-npm-local-modules-dfc5ff047bcc) erabili
Hazten hasi eta zerbitzari ezberdinetan antzeko baliabideak erabiltzen dituzten gero eta osagai ezberdin gehiago dituzun heinean, menpekotasunak kudeatzen hasi beharko zenuke. Nola gorde zenezake zure baliabidearen iturburu kodearen kopia bat eta beste osagaiei hura erabiltzen eta inplementatzen utzi? Bada, npm izeneko tresna bat badago horretarako... Hasi baliabide paketeetan zure kodea jartzen, etorkizunean kodearen ordezkapena errazteko eta argitaratu zure kode propioa npm pakete pribatu gisa. Horrela, zure kodeak beste kode hori inportatu ahal izango du, debaldeko menpekotasun kudeaketa tresnari esker. Posible da zure erabilera pribaturako npm paketeak argitaratzea,haiek publikoki partekatu gabe, [modulu pribatuak](https://docs.npmjs.com/private-modules/intro), [erregistro pribatua](https://npme.npmjs.com/docs/tutorials/npm-enterprise-with-nexus.html) edo [npm pakete lokalak](https://medium.com/@arnaudrinquin/build-modular-application-with-npm-local-modules-dfc5ff047bcc) erabiliz
<br/><br/>

View File

@ -4,17 +4,17 @@
### Azalpen Paragrafoa
Proben txostenak, aplikazioaren berrikuspenak kodea ezagun ez dutenentzako baldintzak betetzen dituen aipatu behar du: saiatzailea, inplementazioa egiten ari den DevOpsa eta hemendik bi urterako etorkizuneko zu. Hau hoberen lor daiteke probak eskatutako baldintzak kontuan hartzen baditu eta hiru zatiz osatua badago:
Proben txostenak esan behar du aplikazioaren berrikuspenak erantzuten dien kodea nahitaez ezagutzen ez duten pertsonen beharrei: probatzailea, inplementazioa egiten ari den DevOps injinaria eta zu zeu hemendik bi urtera. Hori errazago lortuko duzu probak eskatutako baldintzak kontuan hartzen baditu eta hiru zatiz osatua badago:
(1) Zer ari gara frogatzen? Adibidez, ProduktuZerbitzua.gehituProduktuBerria funtzioa
(1) Zer ari gara probatzen? Adibidez, ProduktuZerbitzua.gehituProduktuBerria funtzioa
(2) Zein egoera eta kasutan? Adibidez, ez zaio preziorik pasatu funtzioari
(2) Zein egoera eta agertokitan? Adibidez, ez zaio preziorik pasatzen funtzioari
(3) Zein da esperotako emaitza? Adibidez, produktu berria ez da onartua
(3) Zein da espero den emaitza? Adibidez, produktu berria ez dago onartua
<br/><br/>
### Kodearen adibidea: 3 zati dituen proba izena
### Kode adibidea: 3 zati dituen proba izena
```javascript
//1. unitatea frogapean
@ -31,8 +31,7 @@ describe('Produktu Zerbitzua', () => {
<br/><br/>
### Kodearen adibidea, Anti Eredua: norberak proba osoaren kodea irakurri behar du eta asmoa ulertu
### Kode adibidea, anti eredua: norberak proba osoaren kodea irakurri behar du eta asmoa ulertu
```javascript
describe('Produktu Zerbitzua', () => {
describe('Produktu berria gehitu', () => {
@ -47,9 +46,9 @@ describe('Produktu Zerbitzua', () => {
<br/><br/>
### "Zuzen Egitearen Adibidea: Proben txostenak dokumentuaren baldintzak biltzen ditu"
### "Zuzen egiteko adibidea: proben txostenak dokumentuaren baldintzak biltzen ditu"
["30 Node.jsen proba jarraibide egokiak" blogetik, Yoni Goldbergen eskutik](https://medium.com/@me_37286/yoni-goldberg-javascript-nodejs-testing-best-practices-2b98924c9347)
["30 Node.jsen proba jardunbide egokiak" blogetik hartua, Yoni Goldbergen eskutik](https://medium.com/@me_37286/yoni-goldberg-javascript-nodejs-testing-best-practices-2b98924c9347)
![Proba txostenaren adibidea](https://github.com/goldbergyoni/nodebestpractices/blob/master/assets/images/test-report-like-requirements.jpeg "Proba txostenaren adibidea")

View File

@ -4,14 +4,13 @@
### Azalpen Paragrafoa
Probak egiterakoan daukagun erronka handiena memoria espazio falta da, iada badugu asko lanpentzen gaituen ekoizpen kodea. Honegatik, proba kodea sinplea eta ulergarria izan behar da. Proba kasu bat irakurtzean, ez du kode inperatiboa (begiztak, ondoretasun) irakurtzearen irudia eman behar, HTML moduan, esperientzia deklaratibo bat baizik. Hau lortzeko, erabili AAA eredua irakurtzaileek probaren asmoa esfortzu gabe uler dezaten. Eredu hau bezalako beste batzuk ere badaude, XUnit 'Prestatu, Aritu, Egiaztatu, Eraitsi' ('Setup, Excercise, Verify, Teardown') bezalakoak. Hauek dira hiru Ak:
Probak egiterakoan daukagun erronka handiena memoriako espazio falta da, dagoeneko ekoizpen kodeak oso lanpetuta gauzka. Horregatik, proben kodeak sinplea eta ulergarria izan behar du. Probak irakurtzean, ez luke eman beharko kode inperatiboa irakurtzen ari zarela (begiztak, oinordetza), HTML moduan, esperientzia deklaratibo bat baizik. Hori lortzeko, erabili AAA eredua, irakurtzaileek probaren asmoa esfortzu gabe uler dezaten. Badaude hori bezalako beste eredu batzuk ere, adibidez: XUnit 'Prestatu, Aritu, Egiaztatu eta Eraitsi' ('Setup, Excercise, Verify, Teardown'). Hauek dira hiru Ak:
Lehenengo A, Prestatu (Arrange): Sistema, proba kasuak simulatu nahi duen egoeran jartzeko, egin beharreko kodearen prestakuntza. Honek, eraikitzailearen unitate proba egitea eska lezake, datu-basean datuak gehitzea, objektuak antzeratuz (mock) eta beste edozein prestakuntza kode
Lehenengo A, prestatu (Arrange): hau da, prestatu kodea lortzeko sistema jartzea probak simulatu nahi duen egoeran. Horrek, besteak beste, eraikitzailearen unitate proba egitea eska lezake, datu basean erregistroak gehitzea, objektuak mock/stub eta beste edozein prestakuntza kode eranstea
Bigarren A, Jokatu: zure unitate proba exekutatko. Normalean kode ilara bat
Hirugarren A, Baieztatu: Jasotako balioak esperotakoa errespetatzen duela ziurtatu. Normalean kode ilara bat
Bigarren A, jokatu: exekutatu zure unitate proba. Normalean kode ilara bat izaten da
Hirugarren A, baieztatu: ziurtatu jasotako balioak espero ziren modukoak direla. Normalean kode ilara bat izaten da
<br/><br/>
### Kode adibidea: AAA ereduaz egituratutako proba bat
@ -38,7 +37,7 @@ describe.skip("Bezero klasifikatzailea", () => {
<br/><br/>
### Kodearen adibidea, Anti Eredua: bereizketarik ez, bloke bakarra, ulertzeko zailagoa
### Kode adibidea, anti eredua: bereizketarik ez, bloke bakarra, ulertzeko zailagoa
```javascript
test("Premium gisa klasifikatua izan beharko litzateke", () => {
@ -57,7 +56,7 @@ test("Premium gisa klasifikatua izan beharko litzateke", () => {
### "Erabili 6 zati proba bakoitzean"
["30 Node.jsen proba jarraibide egokiak" blogetik, Yoni Goldbergen eskutik](https://medium.com/@me_37286/yoni-goldberg-javascript-nodejs-testing-best-practices-2b98924c9347)
["30 Node.jsen proba jarraibide egokiak" blogetik hartua, Yoni Goldbergen eskutik](https://medium.com/@me_37286/yoni-goldberg-javascript-nodejs-testing-best-practices-2b98924c9347)
![Proba txostenaren adibidea](/assets/images/6-parts-in-test.jpg "Proba txostenaren adibidea")

View File

@ -4,11 +4,11 @@
### Azalpen paragrafoa
Hau da urrezko proba araua: egin proba kasuak sinpleak, proba bakoitzak bere datu-baseko ilarak sortu eta erabili behar ditu menpekotasunak ekiditeko eta probaren fluxua ondo ulertzeko. Egia esan, garatzaileek hau askotan urratzen dute, datu-baseak beteaz probak exekutatu aurretik (test instalazioa bezala ere ezagutuak), errendimendua hobetzeko xedearekin. Errendimendua gai garrantzitsua izan arren arindua izan daiteke (adibidez Memoria Datu-Baseak, begiratu "Osagarrien probrak" atala), baina proben konplexutasuna da kontutan hartu beharreko gai mingarriena. Praktikan, sortu proba kasu bakoitza explizituki datu-basean beharrezko informazioa gehitzeko eta jokatu bakarrik datu horiekin. Errendimendua arazo larria bihurtzen bada, oreka akordio bat aurki daiteke soilik datuak gehituko dituen proba bat idazten eta ondoren hau bikoizten beste probentzat (adibidez queries)
Urrezko proba arauari jarraituz egin proba kasu/eredu sinpleak: proba bakoitzak bere datu baseko ilarak sortu eta erabili behar ditu menpekotasunak ekiditeko eta probaren fluxua ondo ulertzeko. Egia esan, garatzaileek askotan urratzen dute hori, datu baseak betez probak exekutatu aurretik (test instalazioa bezala ere ezagutuak), errendimendua hobetzeko xedearekin. Errendimendua gai garrantzitsua izan arren, arindua izan daiteke (adibidez, begiratu Memoria Datu Baseak "Osagarrien probak" atalean), baina proben konplexutasuna da buruko min asko ematen dituen gai, kontutan hartu beharrekoa. Praktikan, sortu proba kasu bakoitza berariaz datu basean beharrezko informazioa gehitzeko eta jokatu bakarrik datu horiekin. Errendimendua arazo larria bihurtzen bada, adostasun orekatua aurki daiteke soilik datuak gehituko dituen proba bat idatziz eta ondoren hori bikoiztuz beste probentzat (adibidez queries)
<br/><br/>
### Kodearen adibidea: proba bakoitzat bere datu multzoa bakarrik ikutzen du
### Kode adibidea: proba bakoitzak bere datu multzoarekin bakarrik egiten du lan
```javascript
it("Webgune baten izena eguneratzerakoan, baieztapen arrakastatsua izan", async () => {
@ -26,7 +26,7 @@ it("Webgune baten izena eguneratzerakoan, baieztapen arrakastatsua izan", async
<br/><br/>
### Kodearen adibidea, Anti Erdua: probak ez dira independenteak eta aurrez konfiguratutako datuak egotea aintzat hartzen dute
### Kode adibidea, anti eredua: probak ez dira independenteak eta aurrez konfiguratutako datuak daudela supotzen dute
```javascript
before(() => {

View File

@ -1,14 +1,15 @@
# Zure CI plataforma arretaz aukeratu
# Aukeratu arretaz zure IE plataforma
<br/><br/>
### Azalpen paragrafoa
CIaren munduak [Jenkins](https://jenkins.io/)en malgutasuna versus SaaS honitzaileen sinpletasunaren arteko lehia ohi izan zen. Egoera aldatzen ari da [CircleCI](https://circleci.com/) eta [Travis](https://travis-ci.org/) bezalako hornitzaileek prestatze-denbora minimodun Docker kontainerrak bezalako soluzio irmoak proposatzen dituztenetik, Jenkins 'sinpletasunean' ere lehiatzen den bitartean. Edozeinek hodeiean CI soluzio aberats bat prestatu ahal dezan arren, oraindik ere plataformaren erabakia da Jenkinsen xehetasun finenak kontrolatu behar izatea ala ez. Erabakia askotan CI prozesua pertsonalizatua izan beharrak zehazten du: hodeieko dohaineko hornitzaileek shell komando pertsonalizatuak exekutatzea ahalbidetzen dute, docker irudi pertsonalizatuak, lan fluxuaren doitzea, matrize eraikitzeak exekutatzea eta bestelako funtzionalitate aberatsak dituzte . Hala ere, infraestruktura edo Java bezalako programazio lengoaia formal bat erabiliaz CIaren logika programatzea nahi bada, Jenkins izan daiteke oraindik aukera hoberena. Bestela, aukeratu dohainekoa eta sinplea den hodeirako soluzio bat
IEaren mundua [Jenkins](https://jenkins.io/)en malgutasuna versus SaaS hornitzaileen sinpletasunaren arteko lehia izan ohi zen. Jokoa aldatzen ari da, [CircleCI](https://circleci.com/) eta [Travis](https://travis-ci.org/) bezalako SaaS hornitzaileek irtenbide sendoak eskaintzen baitituzte Docker edukiontziak barne, gutxieneko konfigurazio denborarekin Jenkins-ek "soiltasun" segmentuan ere lehiatzen saiatzen den bitartean. Hodeian edozeinek IE irtenbide aberatsa presta dezakeen arren, prozesua xehetasun handiz kontrolatu beharra izanez gero, Jenkins da oraindik ere aukeratutako plataforma. Erabakia askotan IE prozesua zenbateraino pertsonalizatu behar den zehazten du: hodeiko dohaineko hornitzaileek/ doako eta konfiguratutako doako hodei saltzaileek ahalbidetzen dute shell komando pertsonalizatuak, docker irudi pertsonalizatuak, lan fluxu doitua, matrizearen eraikuntzak exekutatzea, eta bestelako funtzionalitate aberats batzuk dituzte. Hala ere, Java bezalako programazio lengoaia formal bat erabiliz azpiegitura kontrolatu edo IE logika programatu nahi izanez gero, Jenkins izan daiteke oraindik aukera. Bestela, aukeratu dohainekoa eta sinplea den hodeko soluzioren bat.
<br/><br/>
### Kodearen adibidea: hodeieko CI ezarpen arrunta. .yml fitxategi bakar bat besterik ez
### Kode adibidea: hodeiko IE ezarpen arrunta. .yml fitxategi bakarra besterik ez
```yaml
version: 2
@ -40,11 +41,11 @@ jobs:
```
### Circle CI - ia zero prestakuntzadun hodeieko CIa
### Circle CI: ia zero prestakuntzadun hodeieko IEa
![alt text](https://github.com/goldbergyoni/nodebestpractices/blob/master/assets/images/circleci.png "API erroreen kudeaketa")
### Jenkins - CI sofistikatu eta sendoa
### Jenkins - IE sofistikatu eta sendoa
![alt text](https://github.com/goldbergyoni/nodebestpractices/blob/master/assets/images/jenkins_dashboard.png "API erroreen kudeaketa")

View File

@ -4,24 +4,26 @@
### Azalpen paragrafoa
Garapen iteratiboaren fluxuan, berregituratzea prozesu garrantzitsua da. "Kodearen usainak" (kode-garatze praktika okerrak) ezabatzen, Bikoiztutako Kodea, Funtzio Luzeak, Parametro Zerrenda Luzeak bezalakoak, zure kodea hobetuko dute, mantentzea erreztuz. Analisi estatikoko tresnak erabiltzeak kode usain hauek aurkitzen eta berregiturazio prozesu bat eraikitzen lagunduko dizu. Tresna hauek zure CI eraikitzean gehitzeak kalitate egiaztapenaren prozesua automatizatzen lagunduko du. Zure CIak Sonar edo Code Climate bezalako tresnak integratzen baditu, eraikitzeak huts egingo du kode usainen bat aurkitzen badu, eta egilea arazoaren konponbideaz jakinaraziko du. Analisi estatikoko tresna hauek ESLint bezalako tresnen osagarri izango dira. Linting tresna gehienak fitxategi bakoitzeko indentazioa eta ahaztutako azpituzabeak (hala ere, batzuek funtzio luzeak bezalako kode usainak aurkituko dituzte) bezalako kode estiloetan zentratuko dira, analisi estatikoko tresnak berriz, fitxategi bakarreko edo anitzetako kode usainak (bikoiztutako kodea, analisi konplexitatea, etab.) aurkitzen saiatuko dira
Garapen iteratiboaren fluxuan, berregituratzea prozesu garrantzitsua da. "Kodearen usainak" (kodetze jardunbide okerrak) ezabatzen badituzu hala nola, Bikoiztutako Kodea, Funtzio Luzeak, Parametro Zerrenda Luzeak-, zure kodea hobetuko duzu, eta mantentzea erreztuko. Analisi estatikoko tresnak erabiltzeak kode usain horiek aurkitzen eta berregiturazio prozesu bat eraikitzen lagunduko dizu.
Tresna horiek zure IE eraikuntzari gehitzeak kalitatea egiaztatzeko prozesua automatizatzen lagunduko dizu. Zure IEak Sonar edo Code Climate bezalako tresnak integratzen baditu, eraikuntzak huts egingo du kode usainak antzematen baditu, eta egileari arazoa nola konpondu jakinaraziko dio. Analisi estatikoko tresna hauek ESLint bezalako tresnen osagarri izango dira. Linting tresna gehienak fitxategi bakoitzeko indentazioa eta ahaztutako puntu eta komak bezalako kode estiloetan zentratuko dira (hala ere, batzuek funtzio luzeen moduko kode usainak aurkituko dituzte); analisi estatikoko tresnak, berriz, fitxategi bakarreko edo anitzetako kode usainak aurkitzen saiatuko dira (bikoiztutako kodea, analisi konplexitatea, etab.)
<br/><br/>
### Martin Fowler - ThoughtWorkseko Zientzilari Burua
### Martin Fowler, ThoughtWorkseko zientzilari burua
"Berregituratzen - Bizi Den Kodearen Diseinua Hobetzen" liburutik
"Berregituratzen - Bizi Den Kodearen Diseinua Hobetzen" liburutik hartuta
> Berregituratzea, bizi den kodearen diseinua hobetzeko teknika kontrolatua da
<br/><br/>
### Evan Burchard - Web Garapen Aholkulari eta Autorea
### Evan Burchard, web garapeneko aholkulari eta idazlea
"JavaScript Berregituratzen: Kode Okerra Kode Ona Bilakazen" liburutik
"JavaScript Berregituratzen: Kode Okerra Kode Ona Bilakazen" liburutik hartuta
> Berdin dio zein framework edo "JSen-konpilatzen-du" lengoaia edo liburutegi erabiltzen duzun, akatsen eta errendimendua beti izango dira arazo bat zure JavaScripta pobrea bada
> Berdin dio zein framework edo "JSen-konpilatzen-du" lengoaia edo liburutegi erabiltzen duzun, erroreak eta errendimendua beti izango dira arazo bat zure JavaScripta pobrea bada
<br/><br/>

View File

@ -4,7 +4,8 @@
### Azalpen paragrafoa
Askok Middlewarearen probak alde batera uzten dituzte sistemaren zati txiki bat adierazten dute eta zuzeneko Express zerbitzari bat edukitzea eskatzen dute. Bi arrazoi hauek okerrak dira, Middlewareak txikiak dira baina eskaera guztietan edo gehienetan eragina dute eta `{req,res}` JS objektuak berreskuratzen dituzten funtzio puru gisa errez probatu ahal dira. Middlewareko funtzio bat probatzeko, norberak funtzioa bera deitu behar du eta {req,res} objektuekin dagoen elkarrekintza espiatu (spy) ([erabili Sinon adibide gisa](https://www.npmjs.com/package/sinon)), funtzioak ekintza zuzena egin duela ziurtatzeko. [node-mock-http](https://www.npmjs.com/package/node-mocks-http) liburutegia oraindik ere urrutiago doa eta {req,res} objektuak faktorizatzen ditu beraien jokaera espiatuz. Adibidez, res objektuan zehaztutako http estatus bat esperotako balioarekin bat datorren baieztatu dezake (Ikusi beheko adibidea)
Askok middlewarearen probak alde batera uzten dituzte sistemaren zati txiki bat adierazten dutelako eta zuzeneko Express zerbitzaria edukitzea behar dutelako. Bi arrazoi horiek okerrak dira: middlewareak txikiak dira, baina eskaera guztiei edo gehienei eragiten diete, eta erraz probatu daitezke {req,res} JS objektuak berreskuratzen dituzten funtzio huts gisa. Middleware funtzioak probatzeko, norberak funtzioa deitu behar du eta {req,res} objektuekin dagoen elkarrekintza espiatu (spy) ([erabili Sinon adibide gisa](https://www.npmjs.com/package/sinon)), funtzioak ekintza zuzena egin duela ziurtatzeko. [node-mock-http](https://www.npmjs.com/package/node-mocks-http) liburutegia oraindik ere urrutiago doa eta {req,res} objektuak faktorizatzen ditu beraien jokaera espiatuz. Adibidez, res objektuan zehaztutako http estatus bat espero den balioarekin bat datorren baiezta dezake (ikusi beheko adibidea)
<br/><br/>