jueves, 13 de julio de 2017

Codewars: jugar, practicar, codear

codewarsHace unos días recordé este sitio que conocí hace unos años, al verlo mencionado en un tweet de mi amigo el Maestro.

A raíz de esa mención volví a visitarlo y me alegró ver cuánto progreso mientras yo no estaba mirando.

Codewars es básicamente un sitio de práctica. Está basado en la idea de Code Katas, pero extendido a formas adicionales como el Kumite (una especie de competencia entre desarrolladores), y todo en un entorno colaborativo donde los participantes mismos son quienes agregan y refinan los ejercicios, también votando y comentando tanto los planteos como las distintas soluciones.

Entre las características que más me gustaron es que hay:

  • Diferentes niveles de dificultad
  • Tags que agrupan los ejercicios por temas, niveles, foco
  • Alto nivel de gamification: los participantes tenemos Kyu (niveles), Honor (puntos acumulados), seguidores, clanes y medallas entre muchas otras característica que generan una comunidad vibrante
  • Foros y comentarios bien integrados
  • Un gran contenido gratuito soportado por publicidad, pero que está bien integrada y es relevante (son siempre productos o servicios de desarrollo y los avisos no son molestos), más una oferta paga económica y que más allá de ofrecer unas pocas características avanzadas para quienes realmente le dedican mucho tiempo, es casi una membresía a un club de amigos.
  • Y sobre todo, la chance de aprender y/o practicar en una variedad enorme de lenguajes:
    (en este momento) C, Clojure, CoffeeScript, C++, Crystal, C#, Dart, Elixir, F#, Go, Haskell, Java, JavaScript, Lua, Objective-C, OCaml, PHP, Python, Ruby, Rust, Shell, SQL, Swift, Typescript, y otros que todavía no tienen Katas, pero están en proceso, como: CSS3, D, Erlang, Groovy, Julia, Kotlin, Liso, Perl, R, Racket, Sass y Scala.

Para los que ya saben que soy un enfermo de los lenguajes de programación, se dan cuenta que esto es un picnic para mi.

Recién retomé, y usualmente esto es para mi un equivalente a mirar series o jugar videojuegos: un pasatiempo estimulante. Los que quieran pueden encontrarme en Codewars y eventualmente podemos hacer un Kumite.

jueves, 29 de junio de 2017

Katas de Arquitectura

Un año atrás mi amiga Rox (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.

Primero copio su consulta:

Mañana tengo una sesión de kata de arquitectura con un equipo.  El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.

Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.

Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.

¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?

Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):


¡Hola, Rox! 

Tarot de Arquitectura

Te paso el material:

 

Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).

Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional. 

Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:

Contexto

¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.

Métrica 

¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.

Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno. 

Decisión 

¿Cómo hacemos para lograr esa métrica?

Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.