Skip to content

Commit c07ae5c

Browse files
committed
Useing ice and fire api
1 parent fe90e97 commit c07ae5c

File tree

11 files changed

+3484
-0
lines changed

11 files changed

+3484
-0
lines changed

01 Non blocking/README.md

+25
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
### To get the demo working:
2+
3+
name: Jaime Lannister
4+
house: House Lannister of Casterly Rock
5+
6+
## En esta demo vamos a observar la naturaleza no bloqueante de JS.
7+
8+
* Hemos dicho, que sólo una cosa puede pasar por vez, pero el tiempo parece que se está cargando bastante rápido. Y no es sólo porque nuestro BW sea realmente bueno, si no que además existe otra razón.
9+
10+
* Si miramos el código, esta razón no parece tan obvia. Después de lo que hemos dicho de JavaScript, podríamos pensar, que este trozo de JavaScript, que tenemos aquí en main.js, donde hacemos las peticiones:
11+
* Que hasta, que no termine esta: `service.getCurrentWeather(handlerError, handlerCurrentWeatherSuccess);`
12+
* No va a comenzar la siguiente: `service.getForecastWeather(handlerError, handlerForecastWeatherSuccess);`
13+
14+
* Pero si hemos trabajado con callbacks, estaremos familirizados con el hecho de que los callbacks nos permiten, iniciar una petición y después seguir con el resto de la ejecución del programa.
15+
16+
* Por ejemplo, haciendo otra petición. Cuando las peticiones estan completadas sus respectivos callbacks serán llamados. Pero cómo es esto posible, si sólo una cosa se puede ejecutar por vez, ¿cómo podemos hacer dos peticiones web de manera concurrente?
17+
18+
* Abrimos debugger (F12). Abrimos network, NOTA: `XHR Breakpoints desactivado así como Async checkbox.`
19+
20+
* Aquí podemos ver como las dos peticiones son arrancadas en paralelo por parte del browser.
21+
* NOTA: Utilizar el zoom de Chrome, para que se vea mejor.
22+
23+
* Volvemos a repetir, ¿cómo es esto posible? Si sólo podemos hacer una cosa por vez, ¿no deberíamos de obtener una petición antes que la otra? Mientras que el motor de JavaScript sólo ejecutará una pieza de código cada vez, detrás de bambalinas, existe un pool the threads que son usados para cosas como hacer web requests. Y éste pool de threads pueden tener múltiples hebras abiertas contra múltiples servidores para solicitar el data para múltiples peticiones diferentes al mismo tiempo. Todo esto se desarrolla detrás de bambalinas, pero esta es la manera que tenemos para conseguir parelalismo (concurrencia) dentro de una aplicación JavaScript. Seguimos teniendo detrás de bambalinas, la habilidad para multithreading.
24+
25+
* Lo que tenemos que apuntar fuera aquí, es la naturaleza no bloqueante de JavaScript. Hacemos una petición pero no esperamos, la respuesta y ya hacemos la siguiente, y tampoco esperamos la respuesta de esta. No estamos bloqueando para coger los resultados. Si bloquearemos, eso sería bastante malo ya que sólo podríamos ejecutar una cosa por vez.

01 Non blocking/gulpfile.js

+24
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
'use strict';
2+
3+
const gulp = require('gulp'),
4+
connect = require('gulp-connect'),
5+
open = require('gulp-open'),
6+
options = {
7+
port: 9005,
8+
root: ['src'],
9+
devBase: 'http://localhost:',
10+
browsers: ['safari', 'chrome']
11+
},
12+
openOptions = {
13+
uri: options.devBase + options.port,
14+
app: options.browser
15+
};
16+
17+
gulp.task('connect', () => connect.server({
18+
root: options.root,
19+
port: options.port
20+
}));
21+
// https://github.com/stevelacy/gulp-open/issues/15
22+
gulp.task('open', () => gulp.src(__filename).pipe(open(openOptions)));
23+
24+
gulp.task('default', ['connect', 'open']);

0 commit comments

Comments
 (0)