| 🕗 | ||||
| 10:30 | Bienvenida | |||
| 11:15 | Side Projects | Acuarela | ||
| 12:00 | Etherum | Optimización Web | ||
| 13:00 | VR | SVG | ||
| 16:30 | Autogestión de equipos | |||
| 17:30 | Podcasting | |||
| 18:30 | Kata de Refactoring |
@KikoBeats cuenta cómo empezó haciendo paquetes NPM un poco chorra, como una librería de emojis con millones de descargas. Pero, se preguntó... ¿por qué "lo más humillante que tengo es lo que más ha triunfado"?
No se puede poner en LinkedIn. "Quiero hacer un side project, pero no a cualquier precio."
Muchas veces hay muchas ideas y no sabes por dónde empezar. ¿Cuánto tiempo voy a tardar? ¿Cómo de grande es la idea? Así empezó haciendo una aplicación enfocada al negocio del Windsurf.
Windtoday es un buscador de anuncios de segunda mano de artículos de Windsurf. Al final, es algo que él quería aprender sobre algo que le gustaba.
Para guardar toda la información de los artículos, que "escrapeaba" de otras webs, utilizó Algolia.
¿Y el código? ¿Qué framework utilizar? Da igual, no es el objetivo, no hay que construir un castillo súper grande, porque se hace bola. Hay gente que hace proyectos geniales con JQuery
Además, como en el caso de Windtoday, Kiko tuvo la oportunidad de crear un escenario par aprobar Algolia, con los que ha ido contactando y con los que ha colaborado.
Todo esto, además, está en GitHub, y se puede ver el curso del proyecto, desde que era un prototipo rápido con JQuery hasta la estructura actual hecha con React.
Cuando haces un proyecto, y más si es open source, existen un montón de herramientas que puedes utilizar GRATIS. Entre ellas, está Algolia, que ya hemos mencionado, pero también Travis, Trello, GitHub...
El código es importante, pero no lo más importante. Un side project te permite aprender sobre producto, sobre cómo hablar con posibles futuros clientes, escribir correos, marketing online... "La clave es priorizar".
Lo que mola es pensar un producto y desarrollarlo
¿Y las ideas? Lo mejor es compartir las ideas. Porque, ¿y si alguien te resuelve un problema? ¿Y si te dan feedback?
¿Sabéis quién es Pieter Levels? Empezó haciendo 12 startups en 12 meses y ahora tiene un montón de side projects por los que la gente paga y que además, son increíbles. Y el código no es brillante, pero como hemos dicho antes, eso no es lo más importante. Además, comparte cómo hace los proyectos.
Un ejemplo de producto que hizo Pieter Levels: Pagar si no cumples retos. Por ejemplo: "Voy a leer el Seños de los Anillos en dos meses. Si no, te pago 100 euros". Con que uno te pague, no está mal, ¿no?
Se ha hablado de algún proyecto que aquí no se puede contar #hype #misterio
Blockchain es una base de datos distribuida, segura, y que no necesita veracidad de las acciones que se guardan: no hace falta un banco central ni ningún tipo de intermediario que verifique que lo que contiene es verdadero. Todos los nodos son los que certifican, mediante un protocolo, estos valores. Es una "red de confianza".
Pero también es una burbuja de especulación.
A día de hoy la volatilidad de las criptomonedas es espectacular. Si vemos el gráfico de Bitcoin, es una montaña rusa. El mercado puede bajar el 50% de un día a otro. Esto ocurrió, por ejemplo, cuando iba a haber un fork de Bitcoin, o cuando hubo una amenaza de hackear Etherum.
Ethereum es una máquina virtual de criptomoneda. La diferencia entre un Ether y un Bitcoin es que el primero es un sistema virtual distribuida, mientras que Bitcoin es una moneda virtual. Ether te da la posibilidad de hacer contratos distribuidos, porque tienen estado, no como Bitcoin que es un sistema transaccional. Cada operación en un nodo de Ether tiene un "gas" concreto que se cuantifica en tanto "Ether". El propio creador de Ether (Vitalik) ha dicho que los movimientos especulativos sobre Ether son una amenaza para el sistema. Al final, yo como especulador, compro unos Ether, los cambio por Bitcoins, espero que suban o bajen...
Hoy en día, los ICOs consiste en comprar una cantidad de moneda valorada en una cantidad de Ether concreto. Por ejemplo, para conseguir financiación, puedo valorar inicialmente mi empresa en cien millones de monedas "Aragon", y luego las puedo vender por ejemplo, por tres mil Ethers. La gente quiere comprar entonces diez monedas de Aragon, de manera que se genera un contrato inteligente y en el blockchain se va anotando a quién van perteneciendo estas monedas.
Los Ether cada día valen más porque cada vez hay más demanda, ya que es muy fácil para mí como empresa hacer un contrato y generar transaccionalidad. Así, en esta burbuja la gente está metiendo su dinero.
¿Y no hay normas? Todavía no, porque, realmente, no es dinero.
¿Y cuando la burbuja explote? Entonces el Ether podría empezar a tener el valor que realmente debe de tener. Un ejemplo de su uso: no necesito un registrador de la propiedad. La pregunta es, ¿nos conviene esto como sociedad? :)
Un blockchain es inviolable. Nadie puede añadir un "cero" a una cifra porque sí, ya que cada bloque se basa en el bloque anterior.
¿Qué ocurre cuando hay una compra-venta de Etherum? Suceden varias cosas: las transacciones se almacenan en un bloque, y cada bloque hay que minarlo. Para que yo pueda meter algo en la base de datos distribuida, necesito resolver un problema criptográfico muy importante. Tengo una serie de datos (como wallet de origen, wallet de destino, o cualquier tipo de datos, puede ser una imagen o un poema) y consiste en buscar un hash aleatorio. El poder para minar esto es muy importante. Al resolver este hash, que hace que esta ecuación esté resuelta, se mina un bloque entero y lo envía al blockchain (donde puede haber varias transacciones.) Se puede dar el caso de que varios nodos hayan resuelto este hash. Entonces, se establece un consenso (regla del 51%). Cuando encuentras el hash no quiere decir que lo tengas, ya que las transacción se tiene que confirmar.
En Ether, se tienen que ejecutar ahora mismo unas 2^69 operaciones para conseguir encontrar un hash. Para minar un bloque de Etherum se pueden necesitar un millón de dólares al día. El blockchain no escala indefinidamente.
La única manera de generar Bitcoins, por ejemplo, es minando bloques. Es un premio por resolver este problema criptográfico. Para minar un bloque nuevo, necesitas un minero, que esté generando hashes constantemente hasta que encuentra el que necesitas. Ahora, yo no puedo meter una transacción al blockchain, sino que la publico a la red de Bitcoin y digo: quiero que esta transacción forme parte del blockchain. Para eso, tengo que ofrecer una recompensa (que puede ser lo que tú quieras, como un porcentaje de Bitcoin). Los mineros deciden si lo aceptan o no.
Jorge nos habla de SVG!
Es una etiqueta de la especificación de HTML. Estás pintando codigo.
Dependiendo de la imagen, nos puede interesar tenerla en SVG o no.
Escribir en línea el SVG nos permite ahorrarnos espacio y animarlo con CSS y JS. Sara Soueidan dice de incluirlo siempre con SVG. El tema es que si lo incluyes como imagen, se cachea y se carga más rápido, ya depende de lo que quieras hacer. Si lo incluyes a través de CSS tampoco se puede animar. También se puede utilizar la etiqueta object, pero de nuevo, no podemos animar.
Se pueden utilizar herramientas como Illustrator para optimizar SVG (archivo > exportar > exportar como). Eso se debe a que al crear un SVG hay muchos datos que no son necesarios a la hora de utilizarlos en la web.
Otro optomizador es SVGO (SVG Optimizer)
Otra manera es utilizando sprites, pero no tiene soporte en IE (aunque hay una librería que se puede utilizar)
Xavi nos cuenta cómo están organizados los equipos de Kaleidos.
Existe el siguiente problema habitual: cómo conseguir que una persona sea independiente y su trabajo no dependa tanto de, por ejemplo, un jefe o de otro equipo. Es decir: equipos autogestionados.
Una de las cosas que hacen es establecer unos acuerdos de equipos, desde cómo gestionar problemas hasta cómo organizar el código, por ejemplo. Son unas técnicas que se van mejorando con el tiempo, pero se ha comprobado que algo que suele pasar es que con el tiempo gente que asume más responsabilidades que otras.
Es muy fácil escudarse en que "otra persona es responsable", y es normal que los que tienen más responsabilidad sean cargos más "altos", por lo que los cargos más "bajos" tienden asumir menos responsabilidades.
Al final, cada miembro del equipo asume unas tareas. El problema es cuando, una tarea del equipo que suele hacer una persona, tiene que ser realizada por otra, ya sea porque dicha persona tiene más trabajo o esté de vacaciones, En ese caso, a los demás les cuesta más asumir esa "responsabilidad", ya que prefieren seguir haciendo las tareas que más le gustan o a las que están más acostumbrados.
¿Por qué puede pasar esto? Discutimos si esto pasa porque la gente no se siente preparada para asumir una tarea con la que no se siente cómodo, no sólo porque no te guste.
Un ejemplo de esto es: imagínate que todos acordamos después de comer, limpiar. Pero algún día, alguien deja de hacerlo, por prisa o por cualquier razón. ¿Cómo se gestiona este problema? ¿Cuál es la solución? ¿Se vuelve a hablar?
Hablamos de que muchas veces nos excusamos en el "no tenemos tiempo", ya que consideramos que unas tareas dan más valor que otras (ya sea esto dinero, producto...) ¿Sería una solución, para eso, utilizar gamificación?
Es importante establecer lo que es un "Definition Of Done" (DoD), es decir: cuándo consideramos que una tarea está finalizada. Esto puede ser, que los tests salgan en verde, pero en definitiva es un consenso que asegura que una tarea ha sido terminada con calidad y todos están de acuerdo con eso.
Una forma muy efectiva de currar es el pair programming, tanto con gente que lleva mucho en el equipo como con gente que acaba de entrar.
Hablamos sobre cómo gestionar las tareas, en concreto de Pull Requests. Si una tarea es tan grande que "no hay tiempo" para hacer una PR, o que la PR es gigantesca, es una señal de que la tarea es demasiado grande y que habría que dividirla en tareas más pequeñas. Otra regla de la que hablan para evitar tareas largas es que una nueva rama no pueda tener más de dos días de vida.
Al hilo de cómo repartir la responsabilidad, hablamos de equipos en los que "todos hacen de todo", aunque en el equipo haya distintos niveles entre junior y senior. Se debate que, partiendo de eso, hay equipos en los que si alguien encuentra un bug, automáticamente tiene que arreglarlo, sea cual sea su nivel. Un bug "inmediato" es algo que NO puede llegar a producción.
Xavi nos pregunta cómo acordamos con el equipo "qué es" un bug: ¿cómo se llega a ese acuerdo?
Se habla también de cómo gestionar los problemas visuales, de accesibilidad, usabilidad, maquetación, diseño... y cómo es la comunicación entre perfiles de diseño y desarrollo. Es conocido que hay muchos problemas de integración entre estos perfiles. Un PR puede incluir también al encargado del diseño, que tenga que aprobar lo que se ha hecho y pueda dar feedback.
El problema no está en cuando algo es blanco o negro, sino los "grises". Es decir, cuando hay que decidir porque no está claro. Cómo decidir quién "tiene razón", porque al no haber una contradicción en el que está claro la posición de cada uno, nadie lo tiene claro del todo. Esto se puede ver haciendo lo que es un "voto romano", donde 👍 quiere decir de acuerdo, 👎 en desacuerdo, y 👊 ni sí ni no. Si hay mucho 👊, quiere decir que hay un problema, porque no has logrado convencer a nadie. Previene además de "falsos consensos".
Se recomienda el libro: "The Senior Software Engineer", que habla de qué hacer cuando hay una discusión, cómo abordar una PR, que pueden venir muy bien para el trabajo diario en equipo.
Ignacio comienza contando el podcast Wecodesign, que lleva junto a Carmen. Lo comenzó como herramienta para estar al día en el ámbito del diseño y desarrollo web, y así además tener un proyecto personal. Ellos viven en ciudades diferentes (Madrid y Barcelona respectivamente), por lo que graban los podcasts en remoto.
Ignacio comenta que su equipo de grabación ronda los 250 euros. Además, ahora el podcast lo editan profesionales, por lo que les cuesta un dinero extra. Hay muchos problemas ya que los entrevistados también son a distancia. Ha habido muchos problemas, desde gatos jugando con un cuenco de metal, un compañero que se está duchando en el baño de al lado... Para solucionar esto, suelen hacer alguna llamda anterior con el entrevistado para hacer pruebas de sonido y ver si hay algún problema.
Hay cosas que vas aprendiendo con la práctica. Un ejemplo es tener cuidado con la pronunciación de las eses, evitar los "eeeeeh" antes de hablar, respirar apartado del micro, no mover la silla, cuidado con los movimientos. Hay que tener cuidado si quieres buscar alguna referencia en Internet, puede haber ruido al teclear.
Lo más importante son los micrófonos. Hay dos tipos de micrófonos: de condensador (con mucha sensibilidad). Muy importante también los "anti-pop", y son muy baratos. Un dato interesante: los micrófonos que vienen en los auriculares de iPhone graban muy bien. Hay muchos tipos de micrófonos: unos que tienen varias posiciones (por ejemplo, grabar a dos personas, situadas una enfrente de la otra).
Para grabar los podcasts eligen Skype a la hora de las entrevistas, ya que la calidad es bastante mejor que otras herramientas, como por ejemplo, Hangouts.
Tienen una lista de temas y ponentes en GitHub
(Nota: hemos hablado de muchas cosas muy diversas difíciles de apuntar aquí. Si alguien más se anima, adelante). Besis.
Vamos a hacer una kata de refactoring entre todos. Se puede encontrar más detallada aquí y el código en GitHub (Está en un montón de lenguajes).
Se trata de una kata muy divertida, y la van guiando Sergio Revilla y Dani Latorre
"Welcome to Gilded Rose Inn Hi and welcome to team Gilded Rose. As you know, we are a small inn with a prime location in a prominent city ran by a friendly innkeeper named Allison. We also buy and sell only the finest goods. Unfortunately, our goods are constantly degrading in quality as they approach their sell by date. We have a system in place that updates our inventory for us. It was developed by a no-nonsense type named Leeroy, who has moved on to new adventures. Your task is to add the new feature to our system so that we can begin selling a new category of items"
Hablamos de que esta kata está muy ligada al concepto Domain Driven Design (DDD)
function Item(name, sell_in, quality) {
this.name = name;
this.sell_in = sell_in;
this.quality = quality;
}
var items = []
items.push(new Item('+5 Dexterity Vest', 10, 20));
items.push(new Item('Aged Brie', 2, 0));
items.push(new Item('Elixir of the Mongoose', 5, 7));
items.push(new Item('Sulfuras, Hand of Ragnaros', 0, 80));
items.push(new Item('Backstage passes to a TAFKAL80ETC concert', 15, 20));
items.push(new Item('Conjured Mana Cake', 3, 6));
function update_quality() {
for (var i = 0; i < items.length; i++) {
if (items[i].name != 'Aged Brie' && items[i].name != 'Backstage passes to a TAFKAL80ETC concert') {
if (items[i].quality > 0) {
if (items[i].name != 'Sulfuras, Hand of Ragnaros') {
items[i].quality = items[i].quality - 1
}
}
} else {
if (items[i].quality < 50) {
items[i].quality = items[i].quality + 1
if (items[i].name == 'Backstage passes to a TAFKAL80ETC concert') {
if (items[i].sell_in < 11) {
if (items[i].quality < 50) {
items[i].quality = items[i].quality + 1
}
}
if (items[i].sell_in < 6) {
if (items[i].quality < 50) {
items[i].quality = items[i].quality + 1
}
}
}
}
}
if (items[i].name != 'Sulfuras, Hand of Ragnaros') {
items[i].sell_in = items[i].sell_in - 1;
}
if (items[i].sell_in < 0) {
if (items[i].name != 'Aged Brie') {
if (items[i].name != 'Backstage passes to a TAFKAL80ETC concert') {
if (items[i].quality > 0) {
if (items[i].name != 'Sulfuras, Hand of Ragnaros') {
items[i].quality = items[i].quality - 1
}
}
} else {
items[i].quality = items[i].quality - items[i].quality
}
} else {
if (items[i].quality < 50) {
items[i].quality = items[i].quality + 1
}
}
}
}
}
Smells a simple vista:
this.items[i]". ¿Cómo llamamos a la variable para guardar este valor en el iterable? Hablamos de consistencia de los nombres.increaseQuality y decreaseQuality o changeQuality?items[i].quality = items[i].quality - items[i].quality (en nuestro caso, la versión refactorizada)try - catch, mientras que en C# es convención.