Una araña en la web (Parte 1) – Diferencia entre Web Crawling y Web Scraping

El año pasado participé del taller DESENVOLVENDO WEB CRAWLERS COM SCRAPY realizado durante la Semana de Computación 2018 (SECOMP 2018) de la UNICAMP. ¿Web Crawler? ¿Scrapy? ¿te animas a saber qué son?

Web crawler (Rastreador web): Es un programa que recoge contenido de la web de forma sistematizada a través del protocolo web estándar (http/https)[1]. Además, en [1] nos dice que hay 3 tareas donde las técnicas de web crawlers son muy utilizadas:

  • Motores de búsqueda
  • Monitoreo de marcas, noticias, etc.
  • Creación de banco de datos para procesamiento de contenido

En [2] nos dicen que cualquier página disponible en internet puede ser visitada e inspeccionada (es decir crawled) y cualquier cosa visible en dicha página puede ser extraída (scraped)

Como cada página posee su propia estructura (Ver figura 1), se tiene que desarrollar un programa específico para extraer la información de dicha estructura.

Figura 2: Ejemplo de estructura de una página web (secciones de Header, Nava, Section, Sidebar, Footer entre otros)

Cuando empecé a estudiar este tema de web crawler, me surgió una duda (quizás tú también la tengas en estos momentos):

He escuchado “scrapear” y “crawlear”, pero ¿son procesos iguales? ¿O cuál es la diferencia?.

En [3][4], encontramos lo siguiente:

Web crawling: Es una técnica para visitar todas las páginas de un sitio web o todos los sitios web de un determinado contexto y a medida que va visitando los links de dichas páginas va encontrando más y más links hasta encontrar la información requerida. Es útil para inspeccionar a profundidad un conjunto grande de páginas web, ¿cómo? desarrollando un web crawler (mencionado líneas arriba)

(Web) Scraping: En [4] nos hace hincapié en que el término “scraping” significa en la extracción de información de cualquier fuente (base de datos, archivos csv, etc) y no necesariamente páginas web. Para usar esta técnica es necesario conocer la estructura de la página web de la cual queremos extraer información, es decir deberíamos conocer la estructura HTML de dicha página así como las clases CSS de sus elementos.

Veamos un ejemplo usando la Figura 2 para que quede claro esa diferencia :

Quiero obtener los nombres de los productos que pertenecen a la categoría “laptops” ofrecidos por Amazon.com.

Como 1er paso (Web Crawling), inspeccionaremos/visitaremos todos links del tipo “https://www.amazon.com/s?k=laptop&page=<número de página>
Como 2do paso (Web Scraping), aplicamos la siguiente “regla” para cada página hallada en el paso anterior: Los nombres de los productos se encuentran en el tag html <span> con clase CSS “product-name” (Ver figura 3). Ejecutamos la regla y comienza la ¡Extracción!, todos los elementos que cumplan dicha regla serán extraídos. Durante este proceso podemos tratar esa información, por ejemplo: convertir todos los nombres a “mayúsculas”.
Ojo: El inspector del navegador web será nuestra herramienta más util para conocer los elementos HTML y el CSS que usa la página de la que queremos extraer información.
Como 3er paso: La información extraída y/o tratada en el paso anterior, debe ser almacenada para posterior análisis (o para lo que deseemos hacer con esa información) en una base de datos, en un archivo csv, excel, json, etc.

 

Figura 2: Web Crawling y Web Scraping como proceso de tratamiento de información [Creación propia]

Figura 3 – Ejemplo de elemento html que posee el nombre de un producto (información que queremos extraer)

Según [3], para poder “scrapear” algunos sitios web, se necesita de ambos procesos: web crawling y web scraping.

¡Listo!

Todo ese proceso explicado líneas arriba, lo podemos realizar con S-C-R-A-P-Y

ScrapyEs un framework open source para la extracción de información de páginas web. Algunas de las funcionalidades disponibles de Scrapy son controlar la navegación en la web, bibliotecas para analizar HTML, representación de datos y pipelines para filtrar y tratar datos [1]

 

Figura 3: Arquitectura de Scrapy según [2]

 

En la siguiente parte veremos cómo crear nuestro 1er spider con Scrapy!. Por mientras les recomiendo este tutorial [5]

Cualquier comentario/duda/corrección, déjame un mensaje en el artículo!

 

Referencias

[1] Utilizando o Scrapy do Python para monitoramento em sites de notícias (Web Crawler)

[2] Making Web Crawlers Using Scrapy for Python

[3] Web Crawling: Data Scraping vs. Data Crawling

[4] Quora – What are the biggest differences between web crawling and web scraping?

[5] How To Crawl A Web Page with Scrapy and Python 3

 

[SCRUM] Mi experiencia con el Planning Poker®

En este post me gustaría contarles mi experiencia con la técnica de Planning Poker® usada durante la reunión “Sprint Planning” en el proyecto actual que formo parte.

Antes de comenzar, expliquemos de qué trata el Planning Poker®.

Planning Poker® es una técnica de estimación basada en consenso. Équipos ágiles alrededor del mundo usan esta técnica para estimar las historias de sus Product Backlog.  La unidad de estimación puede ser con puntos de historia (story points) siendo el ideal “días” [1]

 

Pasos del “juego” de Planning Poker® . ¡Let’s play! 

Requisitos a la mano:

  • Lista de funcionalidades a ser estimadas Product Backlog
  • Baraja de cartas para cada miembro del equipo. Los valores de cartas representan el número de puntos de historia de usuarios (cuya unidad de medida puede ser “días“), estos valores podría ser los números de la secuencia de Fibonacci (recomendada por [1]) o cualquier otra medida que el equipo considere más eficiente. En [5] adicionan los valores “?” (difícil de estimar), “taza de café” (muy fácil), entre otros a la secuencia de Fibonacci. Sin embargo . . .

¡Ojo! Sea cual fuere la unidad seleccionada lo más importante es que todo el equipo esté al tanto de ello

Figura 1: Ejemplo de valores de las cartas de Planning Poker® [1]

Basándonos en [1][4], tenemos los siguientes 7 pasos:

  1. El Product Owner del equipo lee y explica las historias de usuarios/ funcionalidades candidatas a ser implementadas durante el Sprint al resto del equipo que se encargará de estimarlas.
  2. Cada miembro tendrá una baraja de cartas
  3. Los miembros discuten y/o solicitan aclaraciones al Product Owner para así poder tener un entendimiento correcto de lo que será estimado.
  4. Cuando la historia de usuario ha sido totalmente aclarada para todos los miembros, cada uno de ellos selecciona una carta que representa su estimación. La carta de cada uno es revelada al mismo tiempo.
  5. Si todos los miembros eligieron el mismo valor, ese será el valor de estimación de la historia de usuario/funcionalidad. Si los valores son diferentes: Los miembros con los valores más altos y más bajos deben explicar la razón de sus estimaciones. Luego de ello, nuevamente los miembros eligen y muestran su carta.
  6. Si existe un consenso, se empieza el juego para estimar la siguiente historia.
  7. El juego finaliza cuando todas las historias han sido estimadas.

Figura 2: Planning Poker® [1]

Mi experiencia con el Planning Poker® . ¡Ahora sí! 

¿Es necesario tener una baraja de cartas físicas? La respuesta es No. En el mercado existen algunas online como ScrumPoker-online o el app Scrum Poker Cards (Agile)

Pero … ¿Será que hay algo más simple?

Nuevamente, la respuesta es Sí. En [2] nos presentan una variación del clásico Planning Poker® llamado The Power of Two la cual nos permite realizar el Planning Poker sin necesidad de cartas físicas u online, en lugar de eso usa “una mano”

Siendo así, nuestro equipo realiza el Planning Poker® – The Power of Two con las siguientes reglas personalizadas

  • Dedo meñique representa: 0.5 punto
  • Dedo índice, pulgar, anular, medio: 1 punto
  • Ningún dedo: 0 puntos (significado: Tarefa muy fácil)
  • Es posible decir combinar el dedo meñique con algún otro dedo para dar el valor, por ejemplo, de “1.5 puntos”
  • Nosotros seguimos la secuencia de valores primos: 0, 0.5, 1, 2, 3, 5. Por tanto, el valor “4” no es posible.

Escala entre puntos y días: 0.5 representa medio día de trabajo(4h) y 1 punto un día de trabajo (8h). Definimos de esta manera pues en nuestro equipo algunos miembros trabajan solo medio día algunos días de la semana.

Hemos realizado varios Sprints de esa manera y nos ha ido bien, cumpliendo a tiempo la implementación de las funcionalidades.

¿Ya usas el Planning Poker®? ¿Sí? ¿No?. Te invitamos a que nos cuentes cómo sus equipos estiman sus tareas 🙂

Referencias

[1] Planning Poker

[2] Planning Poker – The Power of Two

[3] Scrum Effort Estimations – Planning Poker®

[4] SCRUM EFFORT ESTIMATIONS – PLANNING POKER®

[5] Planning poker: A técnica baseada no consenso

 

[User Experience] Un poco de User Experience Design (Parte 3)

En este 3ero y último artículo de “Un poco de User Experience Design” veremos el último paso del ciclo “4 step Design Process” (Figura 1): “Evaluation”. Recordemos que un buen UX es el resultado de horas de esfuerzo gastados en el proceso del desarrollo del producto, desde la creación del concepto hasta la entrega final.

En la parte 1 y 2 de esta serie de artículos vimos los pasos de “Levantamiento de requisitos”, “Diseño de Alternativas”y “Desarrollo de prototipo”

Figura 1 –4 step design process (imagen basada en [1])

Paso 4: Evaluation ( “Evaluación” )

Consiste en un conjunto de técnicas para confirmar/verficar que nuestro diseño satisface y está alineado a las necesidades del usuario. Este paso envuelve diseño y rediseño de nuestro producto basado en las sesiones de testing con los usuarios.

Debemos recordar que este paso no puede ser realizado con wireframes o mockups visuales. Se necesita de algún tipo de interactividad sino los usuarios no entenderán cómo es que realmente funciona el producto. ¿Cómo entonces hacemos el test?

La respuesta es a través de una simulación de nuestro producto final. Podría ser un mockup interactivo que debe tener un cierto grado de fidelidad o propiamente un prototipo que nos muestra el comportamiento del producto [2] y así testar si los flujos de los procesos son consistentes y entendibles además de cumplir con los requisitos del usuario.

Recuerda: El prototipo no es el producto final

Si tu producto es un sitio/sistema web, en [3] nos dicen que la clave para desarrollar este tipo de productos de forma que sean altamente usables es a través del diseño centrado en el usuario (user-centered design). Además, nos deja esta excelente y apropiada frase:

“Testar temprana y frecuentemente”.

¿Como evaluamos si el diseño es usable y útil?

En [1][4] nos mencionan 2 técnicas:

  • Cuantitativo: A través de cuestionarios en busca de feedback o log de datos (registro de datos generados por los sistemas informáticos por ejemplo para ver qué opciones fueron seleccionadas y qué eventos ocurrieron). Aquí se podrían aplicar las herramientas: Google Analytics y Hotjar
  • Cualitativo: Entrevistas con el usuario.

En [4] nos aconsejan que demos importancia de 50/50 a ambas técnicas. Ignorar el feedback de los usuarios (sugerencias/comentarios) e implementar el producto en base a nuestra “intuición” o “corazonadas” es un error.

Podemos definir unas medidas para decir si es un diseño eficiente o no, tales como:

  • Cantidad de tiempo gastado en el proceso “X”, “Y” o “Z”. Nos permite saber “que tan fácil de recordar es realizar una tarea después de varias ejecuciones repetidas”
  • Cantidad de clicks usados para completar la tarea “X”, “Y” o “Z”. Esto nos permite saber “que tan fácil es completar una tarea con éxito”

¿Como evaluamos la experiencia de usuario (UX)?

Aquí, el feedback sobre el UX (cualitativo) de los usuarios deberíamos “cuantificarlo” de alguna forma según [4] y nos muestra 3 formas de hacerlo

 

Cuantificación del feedback de los usuarios de testing

Quantifying user testing feedback 

Haré un resumen de esta forma pues es la que estoy usando en uno de los proyectos que participo.

Útil para:  la evaluación completa de las experiencias de los usuarios e identificar aquellos puntos que causan problemas de usabilidad

Métricas: Percepción del nivel de dificultad, tiempo requerido para completar una tarea, tasa de éxito y error al realizar una tarea.

Según este enfoque, podremos responder a las siguientes preguntas:

  • ¿El flujo de acciones requeridas para realizar una tarea tiene sentido para el usuario?
  • ¿Los usuarios se bloquean en algunos puntos de los flujos desarrollados
  • ¿Los usuarios se distraen facilmente de la tarea que están realizando?
  • ¿Algún punto no está claro sobre qué debe hacer el usuario?

Resumen de los pasos para cuantificar el feedback:

  • Decidir qué tareas deberá realizar el usuario y la Cantidad de tareas (pueden ser 15 tareas simples o 5 tareas complejas)
  • Definir las métricas (métrica de dificultad podría ser a tarvés de tasa de error y suceso)
  • Definir la forma en la que se analizarán los datos
  • Ejecutar los tests
  • Analizar resultados
  • Presentar los resultados y ¡actuar!

Más información en [4]

Quantifying feedback for quick UX/UI design decisions Más información en [4]
Run the “experience rating” poll with a quantitative test Aquí es necesario una herramienta tipo Hotjar. Más información en [4]

Cuando digo “actuar” es ejecutar nuevamente el ciclo “4 step design process” 

Cada iteración debe generar valor para los usuarios tomando siempre en cuenta la experiencia de uso.

Observaciones personales

  • El año pasado (2018) comencé a formar parte de un equipo de trabajo para el desarrollo de un sistema web desde CERO. Cuando tuvimos una primera versión de los flujos principales, se dio inicio a los test de usuarios.
  • ¡Gran sorpresa! Tuvimos feedbacks valiosos y nos enseñó a dejar de lado “las corazonadas”: hubo un flujo “z” que nuestro equipo lo consideró eficiente y una mejora frente a los sistemas de la competencia, se implementó y al testearlo ninguno de los usuarios lo entendió o si lo entendieron nos dieron esta respuesta (literal): “está interesante, pero no lo usuaría porque no lo necesito”. Hasta el día de hoy tomamos al flujo “z” como “ejemplo” de lo que no debemos hacer.
  • Aprendimos a enfocarnos en lo que es realmente útil para nuestro público usuario.
  • Analizamos los comentarios/sugerencias/correcciones y dimos inicio al nuevo ciclo de implementación.
  • ¿Cuándo acabaremos? Pues, la mejora siempre es continua ¿cierto? 🙂

Con esto ponemos fin a este artículo de 3 partes. Comparte con nosotros tu experiencia durante el diseño de productos, apps, etc 🙂

Referencias

[1] Introduction to User Experience Design 

[2] Wireframe, Mockup y Prototipos: en busca de sus diferencias

[3] Usability Evaluation Basic 

[4] Measuring and Quantifying User Experience

 

Recursos útiles

Nielsen Norman Group – World Leaders in Research-Based User Experience

Qué es el Test A/B

[User Experience] Un poco de User Experience Design (Parte 2)

En la parte 1 de este artículo presenté la diferencia entre UX y UI, qué es UX Design y mostré el 1ero de 4 pasos del proceso para el diseño de interfaces propuesto en [1] (Figura 1). En este nuevo post continuaremos explicando los demás pasos.

Figura 1 –4 step design process (imagen basada en [1])

En el curso de [1] en cada momento nos dice que debemos tener en mente el concepto principal de User Experience Design:

¡Los usuarios utilizan interfaces para cumplir una tarea!

Dicho esto, seguimos  …

Paso 2: Design Alternatives ( “Diseño de alternativas” )

Para dar inicio a este paso, debemos ya tener claro cuál es el espacio del problema (problem space): es decir ya sabemos quiénes son nuestros usuarios, cuáles son sus objetivos/metas y la forma actual en la que desarrollan sus actividades. De esta forma, estaremos listos para utilizar esta valiosa información y desarrollar varias opciones de diseño que mejorarán la experiencia de nuestros usuarios (UX). Es el momento de “Pensar más alla” o … Thinking outside the box; y aquí haremos un breve paréntesis de este paso 2, porque considero que es importante entender este concepto de “ir más alla”

Significa poder responder: ¿Cómo unes los 9 puntos de la Figura 2 con máximo 4 líneas sin levantar el lápiz del papel y sin pasar dos veces por el mismo punto?:

Figura 2 – Reto de los 9 puntos

  • ¿¡Qué!? No, no se puede Pamela
  • ¡Claro que sí! Intenta hasta la solución que parezca más descabellada. ¿Ves?

Leer más

[User Experience] Un poco de User Experience Design (Parte 1)

En nuestra empresa LiOnline tratamos a nuestros clientes de forma personalizada y entendemos que sus clientes son lo más valioso que tienen y por tanto los productos y/o servicios que les entregan deben satisfacer sus necesidades a través de la mejor experiencia de uso (Experiencia de usuario – UX).

¿UX? (El famoso ‘iuex‘) ¿Qué es? Particularmente, empecé a escucharlo muchísimo estos 3 últimos años y una definición sencilla es: Cómo el usuario se “siente” o qué “impresión/percepción” recibe cuando usa un producto y/o servicio. Este término fue acuñado por Don Norman [11].

y UI (User Interface o Interfaz de Usuario) es cómo nuestro producto se ve, es decir la apariencia física o diseño visual (look & feel) con la que el usuario interactua.

Antes de entrar al objetivo del post el cual es explicar un poco sobre el “Diseño de Experiencia de Usuario (User Experience Design), me gustaría dejar en claro la diferencia entre UX y UI por medio de un ejemplo:

La evolución de la botella de Ketchup de Heinz
Henry J. Heinz diseñó la botella con un objetivo claro “la pureza mediante la transparencia”, así los compradores podían ver el estado de la famosa salsa de tomate [7].

Yo era niña cuando vi por primera vez dicha botella y recuerdo que me pareció muy elegante y fina. Lamentablemente pasé de la admiración a la frustración en segundos: ¡Cómo saco ketchup! ¡Papá, ayúdame, no sale nada!. Y para él también no era una tarea fácil y así para muchas personas más en el mundo. ¿Qué estamos haciendo mal?, según Heinz existe una forma correcta para hacerlo [5][6].

Es decir a pesar de tener un envase de ketchup con buena apariencia (UI), la experiencia de echar ketchup a las comidas para la mayoría de consumidores era muchas veces frustrante (UX) y no conseguir realizar dicha tarea de forma intuitiva es una señal de que “se debe mejorar” el diseño. Y así fue, surgió la versión de plástico con un diseño diferente que facilitó la vida para muchos y me incluyo. (Ver figura 1)

¡Ojo! Es cierto que al día de hoy aún existen consumidores que prefieren usar la clásica botella con el método de Heinz. Además, hay un factor que actualmente las empresas deben considerar en sus productos: “La preservación del ambiente” y definitivamente un envase de plástico va en contra de ello.¡He ahí un reto más para las empresas! [8]

Figura 1 – Definición de UI/UX (imagen de [2])

Sabiendo ya la diferencia, surge la pregunta: ¿Cómo logramos crear una buena experiencia de usuario?

Empecemos …

Resultado de imagen para KEEP CALM AND UX

Leer más

[Tip] ¿Cómo hago para elegir un software adecuado?

Creo que en algún momento, todos hemos pasado por la difícil decisión de elegir un software para resolver una determinada tarea (desde un básico calendario hasta un complejo software de desarrollo de aplicaciones web). Hoy en día, tenemos muchas opciones disponibles en el mercado para cualquier tarea y entre tantas ¿cuál debería seleccionar?

Resultado de imagen para pensando gif

Me gustaría comentarles cómo suelo buscar y decidir la mejor opción

Leer más

[SCRUM] Daily Meeting y demás comunicaciones con Slack

En artículos anteriores he hablado sobre qué es Scrum, cuáles son sus principios, aspectos y procesos, cómo certificarnos como Scrum Master y más.

De qué trata una Daily Standup Meeting?

Hoy me gustaría comentarles sobre Daily Scrum o Daily standup meeting que como recordarán forma parte del principio “Timeboxing” o “Bloque de tiempo asignado“. La productividad de un equipo ágil se logra usando el tiempo de forma eficiente, es por ello que el principo deTimeboxing es uno de los más críticos pues permite que el equipo se mantenga enfocado en el cumplimiento de sus tareas en el tiempo asignado.

Figura 1 – Timeboxing [3]

Específicamente para la Daily Scrum el tiempo asignado es de 15 minutos por cada 24 horas. En esta reunión cada miembro del equipo, uno por vez, debe responder las siguientes 3 preguntas:

  • Qué hiciste ayer?
  • Qué harás hoy?
  • Cuando crees que terminarás esa tarea? (opcional)
  • Existe algún impedimento/obstáculo para la realización de tus tareas?

Haciendo esto promovemos la transparencia: Todos sabemos en qué andamos y si tenemos o no algún problema (que no es solo del tipo “tengo X bugs en mi código”. En [1] encontramos ejemplos de impedimentos:

  • Mi computadora tuvo un problema y necesito un día más
  • Aún no llego el software/hardware/programa que pedí hace un mes
  • Me gustaría aprender ___________ y para ello me gustaría trabajar en par con fulanito (el famoso programming pair
  • El jefe del área X me ha pedido apoyarlo “por uno o 2 días”

El Scrum Master es el responsable de resolver dichos impedimentos. En aquellos de tipo técnico en donde el Scrum Master no puede resolverlos directamente, él deberá asegurarse de encontrar alguna persona (ya sea del equipo o externa) que pueda ayudar a resolver ese problema rápidamente.

Recomiendo la lectura de [4][5] para conocer qué es lo que NO debemos hacer en la ‘daily‘ y más tips.

 

Leí que la daily tiene que ser presencial, el primer evento del día de trabajo, todos de pie y sin discusión. ¿No es un mundo ideal?

Déjame decirte que sí y pues somos humanos y vivimos en un mundo real. El artículo [6] empieza diciendo “Vamos a ahorrar tiempo, evitemos esta ‘ceremonia’ [daily], es demasiado antiguo!” y cuando empecé a leerlo me sentí identificada con los problemas que surgen de la forma tradicional de conducir una daily.

Y no es que la daily tradicional exija que sea presencial, puede ser hasta por videocámara pero algunas veces sucede que aún asi no se da de la forma que esperamos y podría hasta ser contraproducente. Les contaré algunos de los problemas que percibí cuando empecé a participar de dailies:

  • Las dailies eran programadas a las 9am y hay que decirlo el tráfico de Lima (y la ‘hora peruana’) no permitía que empezáramos a esa hora o si empezaba no estábamos todos al inicio ¿que ocurría entonces?: Algunos miembros perdíamos lo que se había dicho pues no había un registro (y pues tener una persona para redactar una acta de reunión diaria es con certeza improductivo)
  • Otro problema era que la reunión podía durar más de 15 minutos. Porque sin querer o queriéndolo empezábamos a discutir y analizar las respuestas en ese momento y la daily no es para eso.
  • Algunos miembros podíamos no estar interesados en escuchar en ese momento a los demás: ¿imagina que eres el último en responder las preguntas?. ¿no te sentirías aburrido?. No voy a mentir, sí a veces.

¿A que hora empezábamos el trabajo real?: 9:30 o 9:40. ¿Cómo podría hacer más eficiente una daily?. Porque ¡ojo! doy fe de los beneficios de una reunión diaria.

Actualmente estoy utilizando Slack como medio de comunicación y colaboración con mi equipo de trabajo. Al inicio me parecio que era whatsap para empresa. Luego de casi 1 año de usarlo, lo ¡recomiendo fuertemente!. Inclusive realizamos nuestras dailies en Slack gracias a un bot llamado Limitbot.io

Cómo funciona Limitbot como daily? (sin detalles técnicos)

  • Configura las 3 preguntas indicadas líneas arriba
  • Configura el horario en que avisará a cada miembro del equipo para responder las preguntas del paso anterior
  • En el horario indicado, Limitbot enviará una notificación como por ejemplo “Hello Pamela! It’s time for our standup meeting *Standup*. When you are ready please answer the following question:”
  • Es hora de responder una a una las preguntas. Al finalizar el pequeño cuestionario, las respuestas son almacenadas en un “channel” (equivalente a un grupo) que podríamos llamar #dailies.
  • Ese channel estará disponible para todos en cualquier momento: ¡cumplimos con la transparencia!. El Scrum Master podrá revisar las respuestas y buscar soluciones a los impedimentos registrados.

Figura 2 – Preguntas configuradas usando Limitbot  [3]

Probablemente te preguntarás ¿no va en contra de lo que dice Scrum?. No me condenen por favor, yo concuerdo con [7][8]: me libré de una reunión jeje.

Resultado de imagen para happy inside out gif

Tú que opinas? estás a favor de las dailies tradicionales o te animarías por alguna herramienta como um bot de Slack? 🙂

Referencias

[1] Daily Scrum Meeting – Mountain Goat

[2] 21 Ways to Use Slack Bots to Simplify Everyday Tasks

[3] What is timeboxing?

[4] Daily Scrum meeting: tips

[5] Scrum Daily Meeting 

[6] What if we do daily scrum stand-up over slack?

[7] Limitbot.io

[8] Stop the meeting madness

Imagen principal del post tomada de [5]

[Front y Back End] Node.js y NPM

El desarrollo web ha evolucionado a pasos agigantados. Me gustaría empezar con una anécdota sobre ello: A inicios del año pasado, 2017, me reuní con 2 grandes amigos de la universidad y me comentaban sobre tecnologías como Node.js, Angular, React y hablar sobre la tendencia de ejecutar “Javascript en el lado del servidor”. 

Pensé, bueno es hora de …

Así que empecemos … ¿qué es Node.js?

Node.js fue creado en el año 2009 y con ello cambia el concepto de JavaScript pues éste pasa de ser un lenguaje para desarrollo web exclusivo del lado del Front-End (lado del cliente) para ser utilizado también en el Back-End (lado del servidor) [5]

Node.js es un entorno de ejecución en el cual los programas escritos en JavaScript son compilados, optimizados y finalmente interpretados por la máquina virtual V8 de Chrome, la cual es la misma que usa Google para ejecutar JavaScript en su navegador Chrome [1] [2]. Su modelo de operaciones E/S (entradas y salidas) sin bloqueo y orientado a eventos lo hace liviano y eficiente [7].

En [1] nos dice que el uso principal de Node.js está en la construcción de APIs pues su modelo asíncrono, que trabaja con un único hilo (thread) consume pocos recursos del hardware.

¿Modelo de operaciones sin bloqueo, asíncrono? ¿Qué es eso? continuemos 🙂

Leer más

[Front End] Mundo JavaScript en 2018

En enero 2018, estuve comparando 2 tecnologías para desarrollo web del lado Front-End: la librería JavaScript “React” y el lenguaje de programación “ELM” que genera código JavaScript. Para dicha comparación revise diversos artículos y cada uno de ellos me dejaba más preguntas (existían conceptos que no conocía o había olvidado) que respuestas.

¡¿Cuánto ha evolucionado JavaScript?! ¡Dios!¿Cuántas herramientas? No voy a tener tiempo para aprender todo!  – pensé 

… JavaScript posee un gran ecosistema de librerías, frameworks y herramientas que cambian rápidamente y es casi imposible mantenernos siempre actualizados. Es por ello que durante la elección de tecnologías JavaScript para nuestros proyectos webs podríamos sufrir de:

 “JavaScript Fatigue”

Sofocación/Ahogamiento por conocer varias tecnologías y no saber por cual empezar

Tengo algunas preguntas para empezar este post: ¿Qué nos está trayendo JavaScript 2018? ¿Aún debería utilizarlo? ¿Si hay tantas opciones, cómo voy a elegir la mejor?. En el video de [1] y el artículo [6] pude encontrar algunas respuestas.

Leer más

[SCRUM] Ser Scrum Master Certified y ¡no morir en el intento! (Parte 2)

En la parte 1 de este artículo, mencioné donde encontrar los recursos/material de preparación para los exámenes Scrum Fundamentals Certified (SFC)  y Scrum Master Certified (SMC) disponibles por la empresa SCRUMstudy, bajo la cual yo me certifiqué. Durante mi revisión de artículos para la elaboración del presente, me encontré con algunas preguntas para certificación como Scrum Master que me parecieron “extrañas” pues utilizaban algunos términos diferentes a los que había aprendido con el SBOK, fue ahí que recordé que existen 3 grandes empresas certificadoras de Scrum:

  • SCRUMstudy
  • Scrum.org
  • Scrum Alliance

En el artículo de Scrum Alliance vs SCRUMstudy se muestra un cuadro comparativo de ambas empresas. Uno de los puntos que concuerdo con dicho artículo totalmente es que un verdadero Scrum Master (sin importar por cuál empresa obtuvo su certificación) podrá responder a qué se refiere el Manifiesto Ágil: “Hemos llegado a valorar …:

  • A los individuos y su interacción, por encima de los procesos y las herramientas.
  • El software que funciona, por encima de la documentación exhaustiva.
  • La colaboración con el cliente, por encima de la negociación contractual.
  • La respuesta al cambio, por encima del seguimiento de un plan.”

Dejando ese punto en claro, seguiré enfocada en el Scrum Master Certified (SMC) de SCRUMstudy.

Leer más

1 2 3 5