DEV Community: Jorge Cano

10 años participando en DevFest!

Jorge Cano — Sun, 17 Nov 2024 22:54:50 +0000

8 años como Google Developer Expert, y más de 10 participando en Devfest y meetups mensuales. A pesar de todo, recuerdo mi primer Devfest, e imagino mi cara en ese momento como la de un niño entrando a Disney por primera vez...

Tantas personas que hacen lo mismo que vos, tantas personas con ganas de escuchar y participar en un evento "nerd" donde lo que reina es la buena onda, el compartir y aprender.

Recuerdo disfrutar las charlas como si fuera un recital de música, cada momento, el contenido, las risas, hasta las preguntas... Ahí entendí que era algo que quería en mi vida, no sabía qué ni cómo se tenía que hacer, pero sabía que yo quería eso...

Claro que hoy te puede parecer algo raro, arrancaste tu carrera como Dev viendo videos en youtube, meetups, streamings, o algo así, pero no siempre fue el prime time de las comunidades de desarrollo, y yo había descubierto algo que cambió mi carrera profesional y mi vida.

Hoy escribo desde el aeropuerto de Montevideo, Uruguay

Ayer se realizó el DevFest Montevideo 2024, y fue algo que disfruté demasiado. No voy a mentirles, dormí 4 horas el día anterior, estuvimos con el pana (@villanuevand) preparando una charla MUY PERO MUY detallista, que tal vez deje el video de intro que hicimos por mis redes... Pero a pesar del cansancio y todo, al llegar al evento, vuelve esa sensación de sentirse en casa, a pesar de conocer poca gente, o casi nadie en porcentual... Sentirte parte de algo tan bonito es un boost de energía tan fuerte que se te va el sueño, absolutamente todo.

Y esto me puso a reflexionar un poco, cuánto tiempo ya, cuántos eventos, cuántas charlas, risas, abrazos, reencuentros y tantas sensaciones en algo tan importante...

A veces, tantos años haciendo algo a uno lo cansa, lo desmotiva, lo hasta pone nervioso que todo salga bien. Al final, te paras en un escenario frente a un público, y en mi mente por lo menos, ellos tienen esa ilusión que tengo yo cada vez que voy a ver una charla que me gusta... Esa ilusión de reírme, de aprender algo nuevo, de que me hagan sentir parte de esto.

Tal vez otros lo sienten con un club de fútbol/béisbol/básquet/lo que sea, yo lo siento con las comunidades de desarrollo.

A pesar de que tengo muchas cosas trackeadas sobre mis charlas/videos/eventos, ya que hay programas que me lo piden... Perdí la cuenta de las veces que me reí, aprendí e hice cosas por la comunidad, como tan solo ir a ver una charla, correr hacia un avión porque no llego gracias a la conexión, o esas personas que te agradecen por algún motivo X.

Sería deshonesto decirte que nunca pensé en dejar todo esto, en simplemente no hacerlo más, pero la realidad es que cada vez que lo hago, me da la suficiente energía para volver a pasar todo lo que no se ve de los eventos/charlas... Toda esa preparación previa, coordinaciones, gastos (se gasta mucho dinero aunque no lo crean) y por sobre todo el tiempo invertido, realmente vale cada segundo, centavo, nervio y por eso siempre vuelvo a hacerlo.

Si llegaste hasta acá, es porque hay algo de todo esto que te llama la atención, y te voy a decir algo, son más de 10 años en esto, y 8 como GDE (que me dio un boost de invitaciones y viajes importantes, aunque antes ya lo hacía), y si a vos te gustaría compartir, ir a conocer gente que hace lo mismo que vos... Ser parte de la comunidad, ¡no lo esperes más!
En esta web vas a encontrar todos los GDG del mundo, por lo tanto, hay demasiadas posibilidades de que alguno te quede "cerca" y, en el caso de que no, muchas veces hay eventos online a los cuales te podés conectar, por ejemplo, en unos días (depende cuándo leas esto) vamos a hacer muchos un watch party del evento de Angular v19 y lo que hacemos es comunidad, charlar, ser parte de algo, aunque estemos en nuestras casas, vamos a verlo "juntos".

Hay otros eventos y comunidades por fuera de los GDGs que también son lo mismo, cambian los nombres o tipos de tecnologías (tal vez no)...

Dale, animate a ir a uno, hablá con alguien que no conocés, animate a divertirte, aprender, conocer nueva gente que hace y le encanta lo mismo que vos... Sé parte de una comunidad, ¡te va a cambiar la vida profesional como mínimo! Quién te dice que le decís "Hola soy X" a la persona que va a ser tu próximo compañero de trabajo y no lo sabías en ese momento.

Sin más, sé que no es un blogpost técnico, pero hace rato que no escribía, tengo tiempo y quería aprovechar para revivir un poco esto y agradecer un poco a todos los que hacen comunidades, ya sea organizando, dando charlas, talleres/workshops o simplemente sentando y escuchando...

Seguramente existan mil fotos mejores que estas dos que voy a poner del evento de ayer, pero así se ven dos personas que se conocieron hace muchos años en un evento y se hicieron grandes amigos ¡y hasta ayer no habían dado una charla juntos!

Gracias por leerme, y nos vemos por las redes!

Angular signals, que son y como funcionan? - parte 1

Jorge Cano — Mon, 11 Dec 2023 10:32:38 +0000

No hay nada nuevo que decir que son un gran fan de RxJS… que desde que lo descubri con angular para mi se volvio una de mis herramientas favoritas

al punto que 2 veces cree cursos gratuitos en youtube sobre esta tecnologia, aprovechando sus actualizaciones y novedades…

Pero angular, tomo un camino de decidir que tenia que cambiar algunas cosas en el framework, es un camino que viene de varias versiones para atras, y esto esta armando un poco de GRANDES cambios en el framework en si…

Por lo tanto, integraron Signals, con su reactividad primitiva, para utilizar en angular… esto hace que muchas cosas que soliamos hacer con rxjs u otros metodos, paso a utilizar signals, lo cual hace que mejore la performance debido a que el framework tiene que realizar menos chequeos y re-draws de algunas cosas en nuestros templates…

Por eso decidi hacer algunos videos y posts, los cuales van a ayudarte a entender esto, pero bien desde dentro… no solo a utilizarlos si no, a entender como funciona, porque deberiamos utilizarlos y cuando deberiamos utilizarlos.

Con esta intro, vamos a escribir un poco de codigo, en este post vamos a ver los principios de Signals, como funcionan que es un compute y los effects…

Podriamos ver los signals como un objeto que tiene las siguientes funciones:

creacion con seteo de valor inicial
getter
setter
update

estas cuatro funciones hacen de nuestro manejo de datos algo mas facil, y me preguntas porque…

Bueno, vamos a verlo en el codigo directamente y pasando a explicar cada uno de ellos.

El Signal se crea con un valor inicial SIEMPRE, depende de nosotros darle un type inicial o no, pero en el caso de que no lo hagamos el runtime lo va a hacer por nosotros y le va a setear el type del valor que le damos.

entonces, primero vamos a importarlo de @angular/core, una vez que lo tenemos ya podemos usarlo

Como lo vamos a crear, bueno de una forma bastante simple,



version = signal(17);

en esta variable version, vamos a decirle que es del tipo signals y su generico va a pasar a ser un number.

QUE? COMO?

bueno, vamos a ver la firma del mismo



/**
 * A `Signal` with a value that can be mutated via a setter interface.
 */
export declare interface WritableSignal<T> extends Signal<T> {
    /**
     * Directly set the signal to a new value, and notify any dependents.
     */
    set(value: T): void;
    /**
     * Update the value of the signal based on its current value, and
     * notify any dependents.
     */
    update(updateFn: (value: T) => T): void;
    /**
     * Returns a readonly version of this signal. Readonly signals can be accessed to read their value
     * but can't be changed using set, update or mutate methods. The readonly signals do _not_ have
     * any built-in mechanism that would prevent deep-mutation of their value.
     */
    asReadonly(): Signal<T>;
}

Aca esta la firma de los signals, usan generics, que es una de las grandes genialidades de typescript a la hora de crear cosas de este estilo.

Lo que vamos a indicarle es que ese generico (que dejara de serlo, va a ser el mismo type de esta instancia de signal), por lo tanto, siempre que lo utilicemos, ya sea para obtener el valor o modificarlo vamos a tener un number.

Sigamos, entonces, ahora tenemos la segunda función, el getter, que es basicamente obtener el valor un get.

Esto se hace con los parentesis directamente, sin la necesidad de escribir nada mas



version() en el template
o this.version() en el componente

ahora que pasa si nos olvidamos de esto y ponemos simplemente version bueno…

nos vamos a encontrar la firma de la funcion, que es el getter() y su nombre en el prototipo.

Asi que si encuentran algo asi, ya sabes que se olvidaron los () parentesis.

Pero bueno sigamos con lo importante, obtener el dato, es facil, ahora que pasa si queremos actualizar el valor del mismo, bueno tal y como comente antes vamos a tener 2 opciones para hacerlo:



this.version.set(18);

el set es la primera forma, que lo que va a hacer directamente es sobre-escribir el valor actual por el nuevo.

Ahora, muchas veces queremos actualizar el valor, pero utilizando el valor actual, por ejemplo en una cuenta (sumandole 1 por ejemplo).

Para eso tenemos update, que a diferencia de set, que sobre-escribe el valor, lo que hace es darnos el valor, para que podamos ejecutarlo en una funcion anonima la cual su retorno return es el valor que va a “setear” en el signal.



this.version.update((valorActual) => valorActual + 1);

como asi podemos hacer algunas cosas un poco mas “complejas” que esta, por ejemplo



this.version.update( (valorActual) => {
    if (valorActual === 10 && flag) {
        return 11;
    } 
    return valorActual + 1;
});

De esta forma, tenemos las actualizaciones y todas las funciones que podes obtener de los signals, pero hay una cosa que no te comente hasta ahora…

Hay 2 tipos de signals, los que acabamos de ver que son los WritableSignals y luego tenemos los Signals que a diferencia de los anteriores, no se pueden escribir/setear a “mano” por asi decirlos y van a necesitar de uno o mas signals para poder obtener valores y ejecutarse.

Estos son los computed estos signals a diferencias de los anteriores, son funciones anonimas que son lazy y memorized, que quiere decir, que derivan del valor de otro signal, y dependen de su cambio de valor para actulizarse y ejecutarse



// writableSignal
version: WritableSignal<number> = signal(17); // return 17

// signal
versionComputed: Signal<number> = computed(() => {
    return this.version() + 1;
}); // return 18

Aca esta las pequeñas diferencias, los computed, solo ejecutan una funcion anonima que va a ejecutarse cada vez que el/los signal/s que tiene dentro cambien de valor (que se les haga un set o update)… y entrega un nuevo valor.

Esta forma, los computed basicamente “reaccionan” a los cambios de otros signals, algo que estamos acotumbrados en cosas como el combineLatests de rxjs por ejemplo… que si alguno de los valores cambia se ejecuta de nuevo. Por esto mismo, se dice que sus dependencias son dinamicas, ya que depende 100% del cambio de valor de 1 o mas signals.

Y por ultimo tenemos, los effects, que es una funcion que se ejecuta siempre que un signal que este dentro de esta funcion, cambie de valor.

Los effects tienen bastantes complejidades si queremos verlos en profundidad, pero por ahroa lo vamos a ver bien por arriba, osea las funciones mas basicas que tiene:



effect(() => {
    console.log('se modifico el valor de version: ', this.version());
});

Y asi se ven los effects, y esta funcion anonima que lleva dentro, solo se va a ejecutar cuando version cambie de valor, en el caso de que nunca cambie, este effect nunca se ejecutara ya que es un efecto del cambio del signal.

El equipo de Angular, en su documentacion, habla de que los effects los deberiamos usar en por ejemplo:

loggear datos cuando cambia para analitics o debbugear
mantener los datos del localstorage en sync
agregar custom data al DOM, que no se pueda hacer en el template directo
para el elemento canvas para mejorar la performance del mismo.

Con esto, ya tenemos el primer vistaso de que son los signals, cuales son las funcionalidades que tienen y que podemos empezar a hacer con ellos, creo que tal vez lo mas importante que podemos ver es la diferencia entre un writableSignal y un signal comun, osea entre el signal que vamos a setear nosotros y el computed que es el que depende de otros.

En proximos capitulos, vamos a ver como funciona mas adentro los effects, como asi hacer una comparativa de funcionalidades y velocidad entre codigo con signals y codigo con rxjs.

Si quieren ver el codigo completo que utilice en el video lo tienen aqui: https://stackblitz.com/edit/stackblitz-starters-dcqlbf?file=src%2Fmain.ts

Se vienen cosas muy interesantes, asi que espero que esto te sirva mucho y estes muy atento a las novedades que voy a ir trayendo!

Gracias por llegar hasta aqui, nos vemos en la proxima!

—

El detrás de escena de las charlas

Jorge Cano — Tue, 03 Sep 2019 11:04:57 +0000

Alguna vez pensaste cuanto tiempo gasta un speaker para armar una charla?
No tan solo en el dinero, si no en el tiempo y todo lo demás.

Hace un tiempo que no escribo... Y creo que es hora de escribir un poco de todo esto!

Me gustaría aclarar que escribo esto con la idea de todo el trabajo que hacemos para cada charla, cada uno de los que dan una charla o un workshop.

Para empezar, me gustaría contarles que a pesar de que tengas mucha experiencia o no, vas a tener que invertirle un tiempo a la charla/workshop que tengas que dar...
Son horas y horas entre tener la idea, conocer del tema, estudiar un poco mas para simplemente crear un titulo y una breve descripción.

Si queres tener una idea de como hago para crear una idea, escribí hace algún tiempo sobre esto (en ingles, si a veces toca) https://medium.com/@jorgeucano/some-tips-to-create-a-wonderful-cfp-43b1058392ee

Por lo tanto, hablemos de esta primera faceta, vos creas todo con mucha fuerza y ganas pensando en que estas casi seguro que te va a llegar esa confirmación de que vas a poder dar la charla. Pero bueno tenes que entender que no siempre pasa.

Creo que en la mayoría de las veces que aplique me dijeron que NO!.

Pero bueno, eso seria la primera etapa.

Por lo tanto, la etapa uno, seria poner algunas horas entre estudio y creación de todo para poder crear el titulo y descripción.

Ahora que pasa cuando te aceptan la charla.

Una vez que te aprueba la charla viene la corrida, que quiero decir con esto, muchas conferencias/meetups tienen sus tiempos y no todas tienen el tiempo necesario para avisarte con tiempo para que puedas preparar todo como corresponde. Sin olvidar y contar que algunas te piden las slide's unos 30 días antes (vuelvo a repetir) no todas pero algunas conferencias lo hacen. Lo cual me parece perfecto, ya que esta bueno que vean que no tengas nada que pueda llegar a incomodar a nadie y que tus diapositivas concuerdan con lo que vos vas a presentar...

quiero aclarar que esos 20 minutos a 4/8 horas dependiendo si das una charla o un workshop, no hay con que pagarlo, por lo menos para mi, yo disfruto mucho compartiendo desde mi punto de vista lo que aprendo y trato de compartir de una forma mas "divertida", esto no quiere decir que todas las charlas deberían ser así, cada uno tiene su estilo y forma donde se siente cómodo... A mi en lo personal a veces me gusta estar en temas complejos de formas divertidas.

Pero bueno, es hora de empezar la charla, como ya hiciste un titulo y un abstract, seguramente tengas una idea del "theme" que va a tener tus diapositivas... Pero bueno, no siempre pasa, o a veces uno varia un poco, CLARO QUE ES NORMAL pivotar un poco en la charla, no drasticamente, si no a veces un enfoque un poquito mas de costado.

Entonces, ahora arrancamos con todo esto, crear la charla, esto casi nunca es cuestión de salir de una. Nos damos cuenta que tenemos que aprender algo, leer mas sobre otra cosa, ver si llegamos con el tiempo, agregar unos memes del momento, y como siempre si elegís demo, esa sensación de no saber si llegas a hacerla, si funciona, si no cambia nada antes.

Por lo tanto ya estamos hablando de algunas noches sin dormir, muchas horas invertidas y eso se refleja en varias cosas, que voy a mencionar mas adelante.

Llega el momento y luego de un promocionar el evento al que vamos, tal vez hacer un vídeo o una serie de tweets(o red social que usen) sea la hora de empezar el viaje.

No siempre, o casi nunca, la conferencia se hace en tu ciudad/provincia/estado/país/continente... Parece medio drástico lo que digo, pero es la verdad, a veces es simplemente tomarse un medio de trasporte publico, pero otra veces uno tiene que viajar muchas horas (hasta 1 o 2 dias) para poder llegar al lugar de la conferencia.

Claro que en el avión/(medio de transporte) no podes descansar mucho, pensando en no olvidarte nada para la conferencia, llegas cansado, muchas veces cambios de horarios, de altura o lo que sea.

Pero a llegar a este momento, uno esta feliz y cansado, claro todavía no diste la charla pero te juntas con los speakers organizadores o algún amigo y estas con tu mente dividida en: no estoy al 100% seguro de que la charla este terminada, el ejemplo del workshop no funciona, me cambiaron una librería de versión o alguna cosa por el estilo que podría romper todo... LO DIGO PORQUE ME PASO y siempre terminas hablando de eso con los demás speakers...

Por lo tanto las noches anterior/es que estas ahí, vas a estar cansado/nervioso y corriendo a contra reloj para poder llegar al momento mágico como se debe.

Este apartado lo voy a usar para los workshops y voy a hablar de MI caso en particular.

A mi me gusta que cuando doy un workshop este todo en perfección para que cada una de las personas que van, puedan aprovechar el máximo tiempo en el que yo estoy dictando el workshop.

Yo siento personalmente que cada una de las personas que pagan y van a mis workshops lo hacen esperando que de lo mejor de mi, aprovechar algún momento extra para colar alguna pregunta extra del tema en el cual estamos o algo que no estemos cubriendo.
Y en lo personal trato de dar lo mejor de mi en cada workshop.
Y me veo obligado a contarles también, que NUNCA cobre por ningún workshop en latinoamerica... Si fuiste a algún workshop mio, en algún evento de LATAM, seguramente pagaste (no en todos) ese dinero yo no lo toque, ni tampoco lo vi, ni nunca me lo ofrecieron.
Y si te preguntas, pero porque nunca lo pediste? o porque no preguntaste?
Porque me gusta pensar que ese dinero se usa para que la gente pueda estar o llevarse algo mas en el workshop.

Como cuando regalo algo, lo saco de mi bolsillo, si gasto dinero para que la gente que paga por algo que no cobro se lleven mas cosas... Pero lo mas importante es que brindo mi conocimiento y todo lo que me hubiese gustado ver a mi cuando estaba aprendiendo lo que yo estoy ensenando.

Ahora el apartado charla, llegan esos 20 a 45 minutos (dependiendo el evento) y uno juega a todo o nada... es en ese momento donde se ve si todo sale bien o mal... como no estar nervioso no? cuantas noches sin dormir, cuanto tiempo invertido viajando... cuando y cuanto...

Claro que el placer que me da a mi personalmente, poder dar una charla y compartir con la comunidad vale muchísimo, pero algún vez pensaron en mas allá de esto.
Alguna vez pensaron cuanto dinero, tiempo, historia gasto en todo esto?

Vamos a hacer un repaso a todo esto...

Para una charla en un evento, utilizo:

Alrededor de 10 horas en el titulo y abstract.
alrededor de 30 a 60 horas en la creación del contenido, slides, ejemplos y demás.
Unos 50 dolares (para el ida y vuelta al aeropuerto)
Otros 50 a 150 dolares entre taxis y comidas/cafés en los lugares que voy (sin quedarme días extra... simplemente viajando para la conferencia.
Noches sin dormir, y tiempo que dejo de estar con mi novia, familia, amigos o trabajando simplemente.
Al no trabajar todos esos días, obviamente, no cobro dinero... así que mínimo son 2 días menos que facturo por esa semana.

Si, si hacemos una cuenta, yo por lo menos, termino pagando mucho dinero para cada una de las charlas que voy a dar... pero lo hago con mucho amor, porque me encanta hacer todo esto para la comunidad.

PERO me duele mucho, cuando hay gente desagradecida, que o porque no hablaste de lo que ellos querían o por X motivo, se llenan la boca hablando mal de una charla (sea la mía o la de cualquier otro).

Es hora de hacer los números para los workshops.
Hablemos de otras 10 horas entre pensar el titulo y el temario
Y luego de unas 50 a 150 horas entre terminar el temario aprender lo que falta y empezar a generar el contenido.
Claro que si llega a cambiar algo en el transcurso de que vos creaste todo y el día/hora del workshop, tenes que salir a modificar todo y cambiar y cambiar hasta que quede todo finalizado.
Y acá volvemos a repetir
Unos 50 dolares (para el ida y vuelta al aeropuerto) Otros 50 a 150 dolares entre taxis y comidas/cafés en los lugares que voy (sin quedarme días extra... simplemente viajando para la conferencia. Noches sin dormir, y tiempo que dejo de estar con mi novia, familia, amigos o trabajando simplemente. Al no trabajar todos esos días, obviamente, no cobro dinero... así que mínimo son 2 días menos que facturo por esa semana.

Claro que es un montón de dinero y tiempo que invierte uno, que lo podría gastar en otras cosas... Por lo tanto, como siempre dije, sean agradecidos con los que hacen una conferencia o evento, recuerden que esa gente usa tiempo suyo para poder crear todo... Pero también, entiendan y sean agradecidos con los speakers y quienes dan los workshops, porque ellos también pusieron de su tiempo y dinero.

Debo admitir que hace tiempo tenia ganas de escribir esto, que todos entiendan que no es como dirían en Argentina "soplar y hacer botella", si no que conlleva un montón de tiempo hacer todo esto.

Y si vos organizas un evento/meetup, también deberías entender que quienes dictan el workshop o dan una charla, son personas que se pueden enfermar, tienen familia y también tienen que pagar las cuentas...

Creo que es hora que seamos todos mas agradecidos y sigamos haciendo crecer las comunidades en las somos partes... y lo siento como un descargo mas que nada, ya que a veces siento que porque sos speaker tenes la obligación de X o Y, y la gente (ya sea organizadores o asistentes) no se da cuenta que también sos una persona, que puede estar pasando porque cualquier situación, ya sea cansancio o cualquier otra.

La verdad que yo estoy super feliz de ir a cada uno de los eventos que voy, y me pone triste a veces tener que decir que "no". Pero a veces no queda otra, hay cosas que resolver antes de ir a cada evento y también ver la agenda, no tan solo de eventos, si no la agenda personal.

Así que simplemente, este es otro de estos post de concientización que me gusta hacer cada tanto!

El próximo, seguramente sea sobre algo mas técnico!

Si me queres ver y hacer preguntas en vivo, me encontraras los lunes a las 7pm (hora argentina) en twitch https://www.twitch.tv/jorgeucano .

Si queres ver mis videos sobre los lives y otras cosas lo podes hacer en youtube https://www.youtube.com/channel/UCdp9sM22GW5uIOaU9eZ7n6w

Si queres ver mis articulos anteriores a dev.to, podes ir a verlos a mi medium en https://medium.com/@jorgeucano

Si queres contactarme por cualquier motivo, o simplemente ver de que hablo, podes darme follow en twitter https://twitter.com/jorgeucano

Gracias por llegar y leer todo! nos estamos leyendo/viendo en la próxima!!!

Deberías colaborar en proyectos open source

Jorge Cano — Thu, 06 Dec 2018 12:28:35 +0000

Hace algunas semanas en las oficinas de google de sunnyvale se hosteo el “Google Developer Expert Summit” y tuve la “gran idea” de hablar sobre porque deberíamos trabajar en proyectos open source en nuestro tiempo libre.

Y toque varios puntos que me gustaría compartir con ustedes:

- Yo haciendo OSS?

Claro, basicamente si sabes programar podes colaborar en OSS

¿Qué te diferencia de la gente que lo hace? Que ellos simplemente lo hacen!

Seguramente una persona que esta haciendo hace tiempo OSS sabra algunos trucos mas que vos a la hora de crear un PR o de entender y dialogar en los tickets abiertos… Pero no se nace sabiendo, se va aprendiendo todo…

Así que a la primera pregunta es un SI, tu código en proyectos open source es posible, solo tenés que tener ganas, tiempo y hacerlo.

No es tan fácil!

Bueno, claro que no, pero nunca te topaste con uno de esos issues bien difíciles hasta que lo sacaste?

Bueno, es lo mismo, la diferencia es que posiblemente tenga el “síndrome del impostor”

Claro que existe, lo dice wikipedia.

La verdad que a veces uno piensa que no esta “al nivel” de los que hacen “open source” pero la verdad es que si no empezás a hacer aunque sea cambios SUPER chiquitos, no vas a empezar nunca.

¿Por qué necesito contribuir en open source?

Esta es una de las preguntas que me hicieron varias veces… Y creo que es la más fácil de responder de todas.

Vas a entender mejor la libreria/framework
Vas a ayudar a otros desarrolladores
Vas a tener una mejor vision del potencial de utilizar ese proyecto
Vas a ayudar a las personas que te ayudan a vos (los mantainers)

¡Aprendes una nueva forma de ayudar y mejorar tus habilidades!

¿Cómo empiezo a colaborar?

Esta es una pregunta tal vez un poco mas trabajosa (?) , bueno en realidad no, una vez que arrancas te vas a dar cuenta que es más fácil de lo que parece… pero para mí, las mejores formas de arrancar son:

Buscando en el proyecto los issues con label “good for first PR” / “community help”
Busca algún mentor que haga OSS
Busca la forma de comunicarte con el team que mantiene el proyecto
No te avergüences por preguntar o por lo que estas haciendo

Agradecer, no cuesta nada y alegra a muchos

Cuando alguien te ayude o te de una mano, siempre tenes que ser agradecido, no te cuesta realmente nada… Y eso va a hablar bien de vos!

Espero que estos pequeños tips te sirvan para arrancar a colaborar con proyecto open source y lleves tus skills a otro nivel !!

Como siempre, espero que les guste lo compartido y cualquier duda dejo mis canales:

Saludos

Atrévete, vos podes!

Jorge Cano — Wed, 05 Dec 2018 12:46:19 +0000

Muchas veces leo cosas de como la gente se “atreve” a hacer algo y me pone muy contento y ayer lei de dos personas de la comunidad de Buenos Aires que contaron sus perspectivas, de animarse a mas

Y justo ayer charlando con otras personas de la comunidad me puse a pensar todo lo que me dio a mí la comunidad y no hablo solo de Buenos Aires o Argentina… hablo de la comunidad de todo el mundo.

Esto no es “auto-bombo” no estoy “vendiendo” nada escondido, simplemente es una especie de descargo que hace tiempo tengo ganas de hacer

Tengo varios puntos de “quiebre” en situaciones específicas… pero me encantaría que cuando termines de leer esto, te pongas a pensar en que hizo la comunidad de vos y porque estas agradecido, y si te animas a escribirlo me encantaría leerlo..

Voy a arrancar por el gran impulso de Google en todo esto, desde los GDG’s hasta los Experts…

Los GDG son Google Developers Group (pero sin google) jejeje, que quiere decir esto, quiere decir que Google ayuda a un grupo de personas a tratar de “evangelizar” la tecnología con el espíritu de compartir… Seria como una meetup pero mas balanceada al mundo de la gran G.

Y porque lo pongo primero, porque gracias a un GDG arranque con mi misión de compartir mas mis conocimientos (por muchos o pocos que sean) entendi que uno tiene que compartir lo que sabe, y ayudar a los demas, porque SIEMPRE PERO SIEMPRE todo vuelve.

Pero no es tan solo compartir lo que aprendiste, si no que es conocer un monton de gente a tal punto de llamar amigos a mucho (esto es mas genial que aprender lo que sea)

Por otro lado esta el programa de Experts, GDE o Google Developer Expert, es un programa para NO EMPLEADOS de Google, lo que quiere decir es que es solo para personas que NO TRABAJAN directa o indirectamente con Google, si no entendiste la indirecta hasta ahora “NO COBRAMOS UN CENTAVO”… Exacto, lo hacemos por amor a la comunidad :) … Ser GDE no te hace mejor que otro (somos todos iguales) lo que hace es que puedas tener mas visibilidad y eso conlleva la responsabilidad de AYUDAR MAS… Lo bueno de esto como mencione antes es que me hizo ponerme mas la camiseta de la comunidad (como se dice en Argentina, me puse la 10) y le dedique MAS tiempo todavía a la comunidad… Como les dije ser mas “visible” hizo que de cursos en las plataformas mas importantes de habla Hispana de “la internet” y que cada vez que escribo o hago un video tenga un impacto interesante… Pero como les dije no todo son números, pero si lo mas importante para mi son los Amigos alrededor del mundo, tengo muchos amigos que cada vez que veo (a veces solo 1 vez por año) hacen que esos momentos sean geniales, que no dormir, o tomarte 3 aviones, estar 1 hora esperando migración y trabajar a deshoras hagan que valga de verdad.

Las meetups me dieron muchísimos amigos y momentos invaluables, cree NG-BAIRES con la idea de compartir mas de Angular, hoy en día, somos un grupo de amigos que llevan NG-BAIRES que van haciéndose tiempo para poder dar una charla o organizar la meetup para que siga viviendo mes a mes…

Por otro lado esta MEETUPJS que es la meetup de Javascript de Buenos Aires, que ya tiene mas de 1900 personas en slack y tengo la suerte de llamar amigos a varios, pero lo importante es que se dedica a ser inclusiva y ayudar, sin importar sobre que preguntes…

Y creo que por ultimo quiero hablar de la ng-conf, la conferencia mas grande de Angular en el mundo, que la hace la comunidad… esto me parece increíble y como esta formado todo me parece MAS GENIAL aun… entender que cada paso que dan esta totalmente revisado y se preocupan porque absolutamente todos puedan estar cómodos es muy difícil, a veces es difícil manejar a 5 personas, 1500 son muchas mas xD… Pero ahi entendí que hasta esta mal tener un lugar “separado” para los speakers, las personas que van a los eventos mejor dicho a TODOS nos gusta hablar con los speakers, organizadores, con todos… Hoy después de mucho ayudar, me dieron la oportunidad de ser uno de los nuevos organizadores y eso me puso realmente muy contento, estar tras escenario desde 6 meses antes, preparando todo para que las personas que vayan sientan que estuvo mejor que el año anterior, es algo que me esta motivando mucho…

Escribo esto para que cuando estes leyendo esto, tengas ganas de compartir algo, animarte a mas…

Criticas vas a tener siempre, cuesta mucho, pero uno tiene que entender cuales son constructivas y cuales no… Entonces las que no, aunque duelan a veces, hay que dejarlas pasar de largo. Ahora las criticas constructivas hay que tomarlas con mucho amor y entender que siempre se puede mejorar.

Tenes ganas de preparar una charla te dejo un video que tal vez te ayude =>

Tambien escribí algunos tips para preparar un CFP => https://medium.com/@jorgeucano/some-tips-to-create-a-wonderful-cfp-43b1058392ee

Tenés ganas de escribir, hazlo, crear un perfil en medium es cuestión de un clic, no necesitas una mega web hecha por vos para eso, “just do it”.

Tenés ganas de hacer un curso, graba tu pantalla, hacelo, iteralo, compartilo a amigos/colegas.

Simplemente hazlo, te vas a sentir genial y la gente te lo va a agradecer!

Creo que todo lo bueno y lo agradecido que estoy, es porque alguien me dio el espacio y me anime a un poquito mas… así que quiero que te animes a mas… y si me compartís en que te animaste voy a estar mas contento de ver que pudiste y saber que esto sirvió 😃

Como siempre, espero que les guste lo compartido y cualquier duda dejo mis canales:

Saludos

Some tips to create a Wonderful CFP

Jorge Cano — Thu, 22 Nov 2018 11:42:10 +0000

Each year, ng-conf receives hundreds of proposals, and there is not enough space for all … That’s why having a good CFP is very important when submitting a proposal to speak at #ngconf2019 .

The first thing I have to tell you is that there is not magic potion …

But, there are a few good tips for making your CFP more striking and impressive. Here are just a few:

It is very important that you understand what your “purpose” is for the talk, let’s see some examples:

Explain specific functionality
Show the library you were creating
Talk about performance on X performance

Now, if you want to tell how cool your company is and what they do, it would be better to have your company sponsor, because the talks about “how cool is my company” are usually not selected.

Now that you know what you want to talk about, you’re going to have to think about a title and a description for the talk … but we’re going in parts…

Every year, ng-conf chooses a theme … if you have not seen it yet, for the #ngconf2019 the theme is going to be “space” … so if you are creative, hook your CFP with something of the theme. This could make it more attractive…

Returning to the proposal, we should think about our description (Yes, the title is left for later)…

Imagine that we want to talk about the “remoteness of a star” … Then we have the idea of the talk … now we should focus on “selling” it so that they choose it …

There are many methods of “selling” our talk, but let’s see some interesting ones:

“When you look at a star, have you ever thought about how far away it is?, Did you take into account the distance or the equipment that we would need to reach it? “

Ask “interesting” questions that you will then answer in the talk. It is a good option to give an overview of what you want to cover in your talk …

“SUPERREMOTESTAR is a mega-framework for research the best options for navigating to your favorite start, are you ready for arrive?”

Another option is to say what you are going to do in a few words, so that reading it generates intrigue.

There are many methods to write a CFP (it could be a university course), but the important thing is that it has a meaning. You are selling your talk for others to “buy” and be chosen among the few that can enter every year.

You have the “idea”, the “Abstract”, and now it’s time to create your title…

The first thing that catches the attention of a talk is the title, if the title is attractive, people will take the time necessary to read the abstract of the talk…

This year, I gave a talk about “Angular Bazel and closure compiler”, of course, if I put this on my own and the organizer’s don’t know what Bazel is, it would not be attractive to them, so I called her “ABC: it is not the beginning of the alphabet “. After several iterations I end up calling my talk ABC: the new Alphabet for Angular “, and it was striking enough for the selectors of 4 different conferences to read the abstract and accept the talk …

The point is, the title and the abstract must have absolute meaning between them both. An individually striking title and striking abstract do do not necessarily make them attractive together … this is important, to pivot between the title and the abstract so that they are a unique piece of art.

ABC, The new Alphabet for Angular

Monorepos, Blazingly-fast localized builds, and highly optimized output bundles are no longer a dream reserved just for the dream teams — they are now a big-time reality in Angular.

You are prepared for what is coming: Angular Bazel & Closure!

This is an example of a CFP, which worked for me (not in all proposal), this does not mean that it is perfect or that yours should be like this, it is just an example … as mentioned at the beginning, there are no magic potions for this …

Many CFP forms, allow us to write something “extra” outside of what is going to show to the public, this place is VERY IMPORTANT, here is where you can write a little more about your talk and also clear some doubts that may Get to bring your Title or abstract…

So it is very important to do a little more in this section, remember to add everything you have in mind, if you have an example to show in the chat, add it there, for example => “I’m going to show you how to make a migration to bazel in 5 minutes and every time I make a compilation takes 10x less than with the common method “, “create a karaoke machine and I want to make someone sing “… this will be known by you and the organizers ( who should know to help you in the preparation), BUT it will be a big surprise for those who see your talk, for example.

It’s All About The Angular Baby — ng-rap — LIVE — Shai Reznik

Do you already have everything?

Okay, so it’s time to push the button and send your proposal!!

Good Luck and Enjoy creating your CFP

Before leaving, I leave all the places for which it is possible to see what I’m doing, or just to be greeted =).

Thanks for read 👌

Entendiendo Bazel

Jorge Cano — Mon, 24 Sep 2018 11:52:01 +0000

Para arrancar bazel es una herramienta que utiliza google para compilar TODOS sus códigos fuentes, basado en un mono-repo (lo que quiere decir es que todo el código de google se encuentra en un solo repositorio) Podes imaginarte cuanta cantidad de lineas de código, lenguajes y configuraciones distintas en un mismo repositorio.

Que locura no? Y nosotros a veces nos quejamos de tener alguna diferencia entre dev y producción xD …

—

vamos a hacer un pequeño parentesis en todo esto, imagino que se estaran preguntando porque en todo esto tenemos que entender:

porque y para que sirve bazel

La realidad es que angular esta migrando sus funcionalidades hacia bazel, para que podamos mejorar en nuestros tiempos de desarrollo, transpilación y compilación. Tambien es importante entender que los equipos de google (que tienen alrededor de 600 apps realizadas con angular), no pueden usar el CLI porque usan bazel… pero hace poquitos días ya se pudo ver los primeros avances interesantes en este merge entre bazel y webpack… entonces para poder explicar como funciona lo demas, tienen que entender como funciona bazel.

—

El primer punto que tenemos que entender es que bazel se basa en una serie de conceptos y terminología que tenemos que ir aprendiendo.

Bazel crea software a partir del código fuente organizado en un directorio llamado WORKSPACE. Los archivos de origen en el workspace están organizados en una jerarquía anidada de paquetes, donde cada paquete es un directorio que contiene un conjunto de archivos fuente relacionados y un archivo BUILD. El archivo BUILD especifica qué salidas de software se pueden generar a partir de la fuente.

Workspace

Un Workspace es un directorio en su sistema de archivos que contiene los archivos de origen para el software que vamos a programar, así como enlaces simbólicos a directorios que contienen los resultados de compilación. Cada directorio del espacio de trabajo tiene un archivo de texto llamado WORKSPACE que puede estar vacío, o puede contener referencias a dependencias externas necesarias para construir los resultados.

Packages

La unidad primaria de organización del código en un workspace es el paquete. Un paquete es una colección de archivos relacionados y una especificación de las dependencias entre ellos.

Un paquete se define como un directorio que contiene un archivo llamado BUILD, que reside debajo del directorio de nivel superior en el espacio de trabajo. Un paquete incluye todos los archivos en su directorio, más todos los subdirectorios debajo de él, excepto aquellos que contienen un archivo BUILD.

Por ejemplo, en el siguiente árbol de directorios hay dos paquetes, my/app y el sub-paquete my/app/tests. Tenga en cuenta que my/app/data no es un paquete, sino un directorio que pertenece al paquete my/app.

src/my/app/BUILD  
src/my/app/app.ts  
src/my/app/data/input.txt  
src/my/app/tests/BUILD  
src/my/app/tests/test.ts

targets

Un package es un contenedor. Los elementos de un package se llaman targets. La mayoría de los targets son uno de los dos principales tipos, archivos y reglas. Además, hay otro tipo de targets, grupos de package, pero son mucho menos numerosos.

Los archivos se dividen en dos tipos. Los archivos de origen generalmente se escriben por el esfuerzo de las personas y se registran en el repositorio. Los archivos generados, a veces llamados archivos derivados, no se incorporan, pero la herramienta de compilación los genera a partir de los archivos fuente de acuerdo con reglas específicas.

El segundo tipo de target es la regla(rule). Una regla especifica la relación entre un conjunto de entrada y un conjunto de archivos de salida, incluidos los pasos necesarios para derivar los resultados de las entradas. Los resultados de una regla son siempre archivos generados. Las entradas a una regla pueden ser archivos fuente, pero también pueden ser archivos generados; en consecuencia, los resultados de una regla pueden ser las entradas a otra, lo que permite construir largas cadenas de reglas.

Si la entrada a una regla es un archivo fuente o un archivo generado es en la mayoría de los casos no es importante; lo que importa es solo el contenido de ese archivo. Este hecho hace que sea fácil reemplazar un archivo fuente complejo con un archivo generado por una regla, como ocurre cuando la carga de mantener manualmente un archivo altamente estructurado se vuelve demasiado molesto, y alguien escribe un programa para derivarlo. No se requiere ningún cambio para los consumidores de ese archivo. Por el contrario, un archivo generado puede ser reemplazado fácilmente por un archivo fuente con solo cambios locales.

Las entradas a una regla también pueden incluir otras reglas. El significado preciso de tales relaciones suele ser bastante complejo y dependiente del lenguaje o de la regla, pero intuitivamente es simple: una regla A de la biblioteca C ++ podría tener otra regla B de la biblioteca C ++ para una entrada. El efecto de esta dependencia es que los archivos de encabezado B están disponibles para A durante la compilación, los símbolos B están disponibles para A durante el enlace, y los datos de tiempo de ejecución de B están disponibles para A durante la ejecución.

Una variante de todas las reglas es que los archivos generados por una regla siempre pertenecen al mismo paquete que la regla en sí; no es posible generar archivos en otro paquete. Sin embargo, no es raro que las entradas de una regla provengan de otro paquete.

Los grupos de paquetes son conjuntos de paquetes cuyo propósito es limitar el acceso a ciertas reglas. Los grupos de paquetes se definen mediante la función package_group. Tienen dos propiedades: la lista de paquetes que contienen y su nombre. Las únicas formas permitidas de referirse a ellas son desde el atributo de visibilidad de las reglas o desde el atributo default_visibility de la función de paquete; no generan ni consumen archivos

Labels

Todos los targets pertenecen exactamente a un package. El nombre de un target se llama su label, y una label típica en forma canónica se ve así:

//my/app/main:app_binary

Cada label tiene dos partes, un *nombre de paquete* (*my/app/main*) y un nombre de destino (*app_binary*). Cada label identifica de manera única un objetivo. Las etiquetas a veces aparecen en otras formas; cuando se omiten los dos puntos, se supone que el nombre del objetivo es el mismo que el último componente del nombre del paquete, por lo que estas dos etiquetas son equivalentes:

//my/app  
//my/app:app

Los labels de formato corto como /my/app no deben confundirse con los nombres de los packages. Los labels comienzan con //, pero los nombres de los packages nunca lo hacen, por lo tanto my/app es el package que contiene //my/app. (Una idea errónea común es que //my/app se refiere a un package, o a todos los objetivos en un paquete; ninguno es verdadero).

Dentro de un archivo BUILD, la parte del nombre del package del label puede omitirse y, opcionalmente, también los dos puntos. Entonces, dentro del archivo BUILD para el package my/app (es decir, //my/app:BUILD), los siguientes labels “relativos” son todos equivalentes:

//my/app:app  
//my/app  
:app  
app

(Es una cuestión de convención que los dos puntos se omiten para los archivos, pero se retienen para las reglas, pero no es significativo).

Del mismo modo, dentro de un archivo BUILD, los archivos que pertenecen al package pueden ser referenciados por su nombre sin adornos relativo al directorio del paquete:

generate.cc  
testdata/input.txt

Rules

Una regla especifica la relación entre las entradas y las salidas, y los pasos para construir las salidas. Las reglas pueden ser de uno de muchos tipos o clases diferentes, que producen ejecutables compilados y bibliotecas, ejecutables de prueba y otros resultados compatibles, tal como se describe en Build Encyclopedia.

Cada regla tiene un nombre, especificado por el atributo de nombre, de tipo cadena. El nombre debe ser un nombre de objetivo sintácticamente válido, como se especifica arriba. En algunos casos, el nombre es algo arbitrario, y más interesantes son los nombres de los archivos generados por la regla; esto es cierto de genrules. En otros casos, el nombre es significativo: para las reglas * _binary y * _test, por ejemplo, el nombre de la regla determina el nombre del ejecutable producido por la compilación.

Cada regla tiene un conjunto de atributos; los atributos aplicables para una regla dada, y el significado y la semántica de cada atributo son una función de la clase de la regla; consulte Build Encyclopedia para obtener la lista completa de las reglas admitidas y sus atributos correspondientes. Cada atributo tiene un nombre y un tipo. Algunos de los tipos comunes que un atributo puede tener sone integer, label, list of labels, string, list of strings, output label, list of output labels.. No todos los atributos deben especificarse en cada regla. Los atributos forman así un diccionario de claves (nombres) a valores tipados opcionales.

El atributo *srcs* presente en muchas reglas tiene el tipo “list of label”; su valor, si está presente, es una lista de etiquetas, cada una es el nombre de un objetivo que es una entrada a esta regla.

El atributo de salida presente en muchas reglas tiene el tipo “list of outputs labels“; esto es similar al tipo del atributo srcs, pero difiere de dos maneras significativas. En primer lugar, debido a la invariabilidad de que los resultados de una regla pertenecen al mismo paquete que la regla en sí, las etiquetas de salida no pueden incluir un componente de paquete; deben estar en una de las formas “relativas” que se muestran arriba. En segundo lugar, la relación implicada por un atributo de etiqueta (ordinario) es inversa a la implícita en una etiqueta de salida: una regla depende de sus srcs, mientras que una regla depende de sus salidas. Los dos tipos de atributos de etiqueta asignan dirección a los bordes entre los objetivos, dando lugar a un gráfico de dependencia.

Este gráfico acíclico dirigido sobre los objetivos se denomina “gráfico objetivo” o “gráfico de dependencia de compilación”, y es el dominio sobre el que opera la herramienta Bazel Query.

Build file

La sección anterior describía los packages, los targets y las labels, y el gráfico de dependencia de compilación en forma abstracta. En esta sección, veremos la sintaxis concreta utilizada para definir un package.

Por definición, cada paquete contiene un archivo BUILD, que es un programa corto. La mayoría de los archivos BUILD parecen ser poco más que una serie de declaraciones de reglas de compilación; de hecho, el estilo declarativo se recomienda encarecidamente al escribir archivos BUILD.

Sin embargo, los archivos BUILD se evalúan usando un lenguaje imperativo, Skylark.

Declaring build rules

Los archivos BUILD utilizan un lenguaje imperativo, por lo que, en general, el orden sí importa: las variables se deben definir antes de usarlas, por ejemplo. Sin embargo, la mayoría de los archivos BUILD constan solo de declaraciones de reglas de compilación, y el orden relativo de estas afirmaciones es irrelevante; lo único que importa es qué reglas se declararon, y con qué valores, cuando la evaluación del paquete finaliza. Por lo tanto, en los archivos BUILD simples, las declaraciones de reglas se pueden reordenar libremente sin cambiar el comportamiento.

Se alienta a los autores de archivos BUILD a usar los comentarios generosamente para documentar el rol de cada objetivo de compilación, ya sea para uso público y cualquier otra cosa que ayude a los usuarios y a los futuros mantenedores, incluyendo un comentario en la parte superior, explicando el papel del paquete .

La sintaxis de comentario de Python de # … es compatible. Los literales de cadena de comillas triples pueden abarcar varias líneas y se pueden usar para comentarios de varias líneas.

Types of build rule

La mayoría de las reglas de compilación vienen en familias, agrupadas por idioma. Por ejemplo, cc_binary, cc_library y cc_test son las reglas de compilación para los binarios, las bibliotecas y las pruebas de C ++, respectivamente. Otros idiomas usan el mismo esquema de nombres, con un prefijo diferente, p. java_ * para Java. Estas funciones están documentadas en Build Encyclopedia.

* *_binary Las reglas de binary crean programas ejecutables en un idioma determinado. Después de una compilación, el ejecutable residirá en el árbol de salida binaria de la herramienta de compilación con el nombre correspondiente para la etiqueta de la regla, por lo que //my:program aparecerá en (por ejemplo) $(BINDIR)/my/program.

Dichas reglas también crean un directorio de archivos de ejecución que contiene todos los archivos mencionados en un atributo de datos que pertenece a la regla, o cualquier regla en su cierre transitivo de dependencias; este conjunto de archivos se reúne en un solo lugar para facilitar el despliegue a la producción.

* *_test Las reglas de prueba son una especialización de una regla * _binary, usada para pruebas automatizadas. Las pruebas son simplemente programas que devuelven cero en el éxito.

Al igual que los archivos binarios, las pruebas también tienen árboles de ejecución y los archivos que se encuentran debajo son los únicos archivos que una prueba puede abrir legítimamente en el tiempo de ejecución. Por ejemplo, un programa cc_test (name = ‘x’, data = [‘// foo: bar’]) puede abrir y leer $TEST_SRCDIR/workspace/foo/bar durante la ejecución. (Cada lenguaje de programación tiene su propia función de utilidad para acceder al valor de $ TEST_SRCDIR, pero todos son equivalentes al uso directo de la variable de entorno.) Si no se observa la regla, la prueba fallará cuando se ejecute en un host de prueba remoto .

* *_library rules especifica los módulos compilados por separado en el lenguaje de programación proporcionado. Las bibliotecas pueden depender de otras bibliotecas, y los binarios y las pruebas pueden depender de las bibliotecas, con el comportamiento esperado de compilación independiente.

Dependencies

Un target A depende de un target B si B es necesario por A en el tiempo de construcción o ejecución. El depende de la relación induce un gráfico acíclico dirigido (DAG) sobre los objetivos, y lo llamamos un gráfico de dependencia. Las dependencias directas de un objetivo son aquellos otros objetivos alcanzables por una ruta de longitud 1 en el gráfico de dependencia. Las dependencias transitivas de un objetivo son aquellos objetivos de los que depende a través de una ruta de cualquier longitud a través del gráfico.

De hecho, en el contexto de construcciones, hay dos gráficos de dependencia, el gráfico de dependencias reales y el gráfico de dependencias declaradas. La mayoría de las veces, los dos gráficos son tan similares que no es necesario hacer esta distinción, pero es útil para la discusión a continuación.

Types of dependencies

La mayoría de las reglas de compilación tienen tres atributos para especificar diferentes tipos de dependencias genéricas: srcs, deps y data. Estos se explican a continuación.

Muchas reglas también tienen atributos adicionales para clases de dependencia específicas de reglas compiler, resources, etc. E

srcs

Archivos consumidos directamente por la regla o reglas que generan archivos fuente.

deps

Regla que apunta a módulos compilados por separado que proporcionan archivos de encabezado, símbolos, bibliotecas, datos, etc.

data

Un target de compilación puede necesitar algunos archivos de datos para ejecutarse correctamente. Estos archivos de datos no son código fuente: no afectan cómo se construye el target. Por ejemplo, una prueba unitaria puede comparar la salida de una función con el contenido de un archivo. Cuando construimos la prueba unitaria, no necesitamos el archivo; pero lo necesitamos cuando hacemos la prueba. Lo mismo se aplica a las herramientas que se lanzan durante la ejecución.

El sistema de compilación ejecuta pruebas en un directorio aislado donde solo están disponibles los archivos que figuran como “datos”. Por lo tanto, si un archivo binario / biblioteca / prueba necesita algunos archivos para ejecutarse, especifíquelos (o una regla de compilación que los contenga) en los datos.

Aca dejo un ejemplo de como funciona en angular sin ningun tipo de “bridge” entre el CLI y Bazel….

jorgeucano/ngx-bazel-ngrx-template

En el proximo post, voy a estar explicando como funciona Bazel con Angular y el angular CLI , así podemos empezar a sacarle provecho a esta magnifica combinación.

Como siempre, espero que les guste lo compartido y cualquier duda dejo mis canales:

Saludos

From no-sql database to Firestore & AngularFire

Jorge Cano — Fri, 13 Jul 2018 13:20:04 +0000

From no-sql database to Firestore & AngularFire

Have you ever thought that the unique querys format of firestore is unlike any other nosql …

Firestore is this super powerful database created by the Firebase team in google, but what happens when we want to migrate what we had in another database and we find that we handle state data, and these are not handled equally in query’s from firestore…

Suppose we want to migrate from mongodb to firestore…

And suppose that what we are migrating is a chat … a chat normally has data like who sends it, who receives it, and above all it has an important data, the famous double blue check, or rather the follow-up of read.

Then we would have a structure similar to this one:

With this format, we would have no problem in making an easy query to identify if it is true or false, reading them, because there are simply two states, if we want to see “the readings” we go to the ones that are true and the opposite for the “unread”…

Let’s think about how to do the query:

But there are more “states” that actually read or not read … We have to identify “by sending”, “sent”, “received / not-read”, “received / read”

But, what would be the problem? It’s easy, I can add more “where” and filter by 2 or 3 diferentes “allRead”, yes in MongoDB, but in firestore NO

In firestore we would have to generate a structure of this type:

So, are you telling me that I can not do the migration?

Well actually if we want to keep the format of the data we will have to make some changes in our code…

The first thing we could think about is to call the different functions and push in a general array:

But, is this fine?

Is it the best way to do it?

does not exist something to not have to do so much code?

I’m repeating a lot the same …

Thanks to RXJS and some small tricks, we will be able to improve our experience with AngularFire and Firestore

RxJS my precious

In this way, thanks to the data and data that comes from firestore, we will be able to make a fusion of data, and be able to show them completely, without thinking about how many things we have to do.

But how does it work?

What we do is iterate the arrays and thus be able to work with the different returns, but what firestore actually delivers is an “observable” by which we send the data we requested in the query.

In this way with the switchMap we will be able to bring all the data of all the observables and in this way concatenate them.

Once all the data have been established in the same array, we will make the map to obtain the data of the collection plus the unique ID of each one and thus deliver it in our list, in order to work with the data correctly.

Remember that the collection surely does not include all the real data that exists in a database of a real chat, but it is a way to explain how the differences in how we use a non-sql and Firestore.

The function can be in:

Right now, you can migrate to firestore :) … enjoy it

After more than 9 years working in the tech industry, Jorge is a full stack developer with focus on JavaScript technologies. Today, Jorge is working at ByteDefault using Angular / RxJS / Firebase / Nativescript as well as other technologies. He delivered several courses and talks as well as write some tech articles on these subjects. Because of that, he was recognised as a Google Developer Expert in Angular & web technologies and Nativescript Developer Expert.

Before leaving, I leave all the places for which it is possible to see what I’m doing, or just to be greeted =).

Thanks for read 👌