Tag Archives: programaciĆ³n

Comentarios

ĀæCuĆ”l es la segunda regla del Club de la ProgramaciĆ³n?

Leave a comment

Si existiera un Club de la ProgramaciĆ³n (al mismo estilo del Club de la Pelea), creo que la primera regla deberĆ­a ser:

ā€“ Ā”Versiona tu cĆ³digo!

Pero ĀæcuĆ”l serĆ­a la segunda regla?, estaba pensando en eso y creo que podrĆ­a ser:

ā€“ Ā”Escribe pruebas unitarias!

Aunque para este punto encuentro muchas confusiones (como cuando se confunde unit testing con TDD), y tambiƩn cierto desconocimiento para reforzar nuestras pruebas.

Es aquĆ­ donde entran a tallar los fakes, stubs y mocks. O tambiĆ©n llamados Test Doubles y que en resumen permiten que nuestras automatizaciones no dependan de otras implementaciones (ocurre regularmente cuando se tiene mucho trabajo en paralelo) o que incluso no se comprometa el uso de componentes que bajo diseƱos ya existentes, solo tienen versiĆ³n productiva (por ejemplo, componentes de core empresarial que no tienen reflejo en ambientes de desarrollo)

Les comparto un post que me pareciĆ³ muy interesante, espero les sea de mucha utilidad

Yo por mi lado, seguirĆ© pensando en el Club de la ProgramaciĆ³n.

Comentarios

ĀæCĆ³mo construir un microservicio?

Leave a comment

Para escribir esta publicaciĆ³n decidĆ­ revisar mis anotaciones, experiencias, leer algunas referencias e incluso volver a leer algĆŗn libro que me permitiera confirmar ā€“o reforzarā€“ mis puntos de vista al respecto. La finalidad es compartir algo distinto y que ademĆ”s sea fĆ”cil de entender. Espero cumplir con ese objetivo šŸ™‚

ĀæQuĆ© no es un microservicio?

  1. Un servicio pequeƱo: Esta confusiĆ³n se genera al creer que el tamaƱo tiene que ver con el nĆŗmero de lĆ­neas de cĆ³digo del programa a exponer como microservicio. No hay que confundir tamaƱo con nivel de [granularidad]
  1. Un API: Las [Application Program Interfaces] son una puerta para consumir o comunicarnos con un microservicio expuesto. Existe una dependencia muy marcada entre ambos elementos, pero un [API] no necesariamente involucrarĆ” el uso de microservicios.
  1. La evoluciĆ³n de SOA: A veces se habla de migrar arquitecturas a “algo nuevo”, cuando en realidad lo que se debe buscar es la convivencia de las mismas. Si no les ha ocurrido, encontrarĆ”n situaciones en las que serĆ” mĆ”s barato (y efectivo) implementar un servicio en vez de un microservicio.

ĀæCĆ³mo describirĆ­a un microservicio?

  1. Una necesidad especĆ­fica de negocio: Una componentizaciĆ³n adecuada sugiere que las funcionalidades se agrupen por [afinidad de objetivos en el negocio]. Posterior a esto, debemos dar un paso adicional y subdividir dicho componente en funcionalidades particulares que podrĆ­an generar valor al negocio. Un ejemplo aquĆ­ serĆ­a, aislar la funcionalidad de obtenciĆ³n de ranking financiero de un usuario, del resto de funcionalidades ā€“o cĆ”lculos o serviciosā€“ financieros.
  1. Independiente: No se deberĆ­a involucrar a otro microservicio para cumplir el objetivo del microservicio diseƱado inicialmente. De acuerdo al ejemplo anterior, la obtenciĆ³n del ranking financiero tendrĆ­a que ser resuelta de manera efectiva sin apoyo de otros elementos.
  1. AutĆ³nomo: Un microservicio debe utilizar sus propios recursos, esto implica fuentes de informaciĆ³n e incluso el espacio donde serĆ” instalado fisicamente. Esto algunas veces no se cumple a nivel de datos y ya hace un tiempo se habla de [servicios stateless]

En tƩrminos sencillos, un microservicio es un programa que responde a una sola necesidad de negocio y que ademƔs puede instalarse y ejecutarse sin depender de la existencia de otros microservicios.

ĀæQuĆ© tengo que hacer si quiero construir un microservicio?

Lo que normalmente hacemos es [buscar en la web]. Allƭ encontraremos muchas plantillas que, en algunos casos, brindan erroneamente el concepto de microservicio. Esto principalmente porque reflejan servicios que exponen (y soportan) mƔs de una funcionalidad.

Creo que un diseƱo adecuado se puede conseguir si respetamos los principios propuestos por [Sam Newman], autor de [Building Microservices], el cual por cierto es un excelente libro. Aquƭ un grƔfico que la propuesta y claro, un enlace a [un video] donde se explican cada uno de los principios.

ĀæCĆ³mo construyo un microservicio?

Hay que tener en cuenta que lo ideal es respetar principios de diseƱo (en mi caso me pareciĆ³ que Sam Newman lo explicaba de manera mĆ”s sencilla). Ahora, si estan aprendiendo o experimentando, podrĆ­an seguir las consideraciones que definĆ­ mientras iba aprendiendo (las cuales respetan de alguna forma la propuesta del buen Sam)

  1. Requisitos de negocio: Creo que independiente a la estrategia de arquitectura, lo primero que debemos respetar es la funcionalidad a cubrir. Si esta no estƔ cubriendo las expectativas del negocio (lo cual en algunas situaciones se relaciona con el core del negocio), no tiene sentido continuar con el diseƱo.
  1. ExposiciĆ³n: Otro elemento importante es responder ĀæcĆ³mo vamos a exponer el microservicio? AquĆ­ entrarĆ” a tallar la API que complementarĆ” el diseƱo que estamos realizando.
  1. Requisitos tĆ©cnicos: Si se tienen cubiertos las dos primeros consideraciones, se puede continuar con el diseƱo de otras necesidades, como por ejemplo ĀæcĆ³mo vamos a probar el microservicio? ĀæcĆ³mo vamos a desplegarlo? ĀæcĆ³mo vamos a manejar los errores? AquĆ­ es donde entra la secciĆ³n de herramientas complementarias.

Un diseƱo que estoy construyendo es el siguiente:

Como mencionĆ© en una [publicaciĆ³n anterior], hace poco empecĆ© un proyecto open source en el cual comparto plantillas y ejemplos de microservicios. Todo el [cĆ³digo fuente] que verĆ”n en dicho repositorio responde a las consideraciones de diseƱo que comento en esta publicaciĆ³n.

Hay que recordar que este diseƱo responde a un microservicio como unidad de trabajo. Esta acotaciĆ³n es importante pues queda pendiente conversar sobre la interacciĆ³n con otros elementos del ecosistema. AquĆ­ es donde se entiende que se necesitarĆ” estudiar conceptos de [orquestaciĆ³n y coreografĆ­a]

ĀæCuĆ”les son los prĆ³ximos pasos?

No debemos olvidar que los microservicios son una tĆ©cnica mĆ”s dentro de las posibilidades para atender las necesidades del negocio. Esto significa de que no necesariamente serĆ”n la primera ā€“ni la Ćŗnicaā€“ respuesta a los problemas a cubrir.

Habiendo dicho esto, sugiero que descarguen el [cĆ³digo de ejemplo] (en este momento estĆ” disponible en JavaScript, TypeScript y c#), revisar el contenido, contribuir en GitHub o bueno, darme feedback al respecto.

Quedo atento, un abrazo.

Fuente cabecera: [what are microservices?]

Comentarios

CĆ³digo Muerto šŸ’€

2 Comments

Una de las anĆ©cdotas mĆ”s comunes de un proyecto de software es que siempre hay una clase o una funciĆ³n que serĆ” recordada por el nĆŗmero de lĆ­neas que esta tuvo. Estoy seguro de que al menos una vez hemos escuchado:

“No toques esa clase, tiene como 1000 lĆ­neas de cĆ³digo”

Developer anĆ³nimo

Este es un dato particular de acuerdo a los proyectos en los que estuve y conversaciones entre amigos. Lo que es menos comĆŗn, es saber cuĆ”ntas lĆ­neas de cĆ³digo tiene el proyecto en el que estamos trabajando.

Si en este momento nos hacemos esa pregunta o se la hacemos a otro miembro del equipo, es posible de que no consigan una respuesta concreta. Si bien es cierto no considero necesario ser 100% precisos, he notado que pocas personas se preocupan de esa mĆ©trica, a menos claro, de que haya algĆŗn costo asociado.

Si no les ha pasado, les comento que casos como este se dan desde hace mucho en proyectos donde se audita cĆ³digo. Sin ir muy lejos, Amazon liberĆ³ [CodeGuru], un servicio (aĆŗn en preview) que analiza el cĆ³digo fuente. Como es de esperar, el costo estĆ” asociado al nĆŗmero de lĆ­neas y no es el Ćŗnico producto o servicio que hace este [tipo de trabajos]

Fuente: [Amazon CodeGuru]

ĀæQuĆ© es lo que regularmente encontraremos?

He participado en proyectos donde el anĆ”lisis o auditorĆ­a de calidad de software era uno de los objetivos mĆ”s importantes. Muchas veces el costo de servicios adquiridos ā€“u ofrecidosā€“ estaba relacionado al nĆŗmero de lĆ­neas de cĆ³digo (o LoC por [Lines of Code]).

En cada trabajo era comĆŗn confirmar lo encontrado en proyectos anteriores:

  1. Pocas personas conocĆ­an el nĆŗmero de LoC o la importancia de este indicador
  1. Una prĆ”ctica conocida ā€“y en algunos casos, aceptadaā€“ era “agregar cĆ³digo de ejemplo, ir cambiando y probando pero guardar la versiĆ³n original por si algo se malograba”
  1. Muchas veces se mantenĆ­an las carpetas de plantillas y ejemplos de las librerĆ­as y componentes de terceros que en algunos casos ya no se utilizaban

Ya en un caso concreto, estuve en un proyecto donde el desarrollo tenĆ­a mĆ”s de un millĆ³n de LoC y estaba seguro de que eso no podĆ­a ser posible pues las funcionalidades del sistema no reflejaban dicha realidad.

SabĆ­a que estaba frente a un caso de CĆ³digo Muerto, pero tenĆ­a que demostrarlo.

ĀæQuĆ© es CĆ³digo Muerto?

Sin entrar en detalles (pues es posible que encuentren discrepancias y hasta [una canciĆ³n]), el cĆ³digo muerto o “Dead Code” es aquel que no aporta valor al negocio.

El cĆ³digo muerto se puede clasificar de la siguiente manera:

  • CĆ³digo que no se usa: Muy usual en los proyectos de software, algunas veces no se recuerda su objetivo inicial y por lo general ocurre pues las necesidades van cambiando y el cĆ³digo no se depura adecuadamente luego de cada cambio (mucho cuidado con las frases “es que no hay tiempo” o “lo vemos despuĆ©s”)
  • CĆ³digo que se ejecuta pero que no se usa: AquĆ­ entran los casos como los de variables asignadas o llamadas a funciones cuyo resultado no es utilizado. Esto es nocivo pues ademĆ”s ser cĆ³digo inĆŗtil, consume recursos del sistema.
Fuente: [Refactoring Guru]

ĀæCĆ³mo identificar CĆ³digo Muerto?

Con el paso del tiempo preparĆ© una secuencia de anĆ”lisis que me sirviĆ³ para encontrar casos de cĆ³digo muerto bajo la premisa de que si algo se define en el programa, este debe ser utilizado de manera efectiva. La lista puede parecer obvia, pero ya estĆ” demostrado que en tecnologĆ­a no debemos confiar en las obviedades šŸ™‚

  • Variables
  • Funciones
  • Clases
  • Comentarios (sean redundantes o cĆ³digo que fue comentado para ser utilizado “mĆ”s adelante”)
  • Elementos de archivos de configuraciĆ³n (por ejemplo, secciones comentads o que ya no se utilizan)
  • Archivos de configuraciĆ³n
  • LibrerĆ­as (componentes de terceros)
  • Elementos idĆ©nticos (funciones, clases archivos, librerĆ­as o carpetas distribuidos en ubicaciones distintas)
  • Elementos parecidos (librerĆ­as con versiones diferentes, funciones o clases que inicialmente eran una copia de la otra)
  • Carpetas y archivos varios que poco a poco quedan relegados hasta el olvido

Un hecho comĆŗn en todos los casos, es que el cĆ³digo muerto existe debido al temor a perder cĆ³digo o a malograr el sistema construido. Esto tiene relaciĆ³n directa con el desconocimiento de que los gestores de versiones permiten volver al pasado si es que se necesita ver algo que ha sido borrado.

Otra consecuencia es que a mĆ”s cĆ³digo muerto, mĆ”s complejo serĆ” el entendimiento de nuestro sistema, la mantenibilidad serĆ” afectada y a su vez generarĆ” dependencias con un programador en particular (a veces pueden ser mĆ”s personas). Recuerden, el cĆ³digo es de todos los miembros del equipo y mientras menos dependencias, mejor.

ĀæQuĆ© herramientas debemos usar?

Puede que parezca una broma, pero un elemento muy importante es la inspecciĆ³n visual. A pesar de ello, esta debe pasar a segundo plano pues debemos evitar confiar totalmente de los presentimientos o “literalmente” de puntos de vista.

De acuerdo a esta premisa, lo primero que debemos hacer es trabajar con [herramientas de anƔlisis estƔtico] que nos brinden un enfoque acertado de lo que estƔ ocurriendo.

A pesar de ello, hasta el momento no he encontrado una herramienta que brinde un indicador de cĆ³digo muerto bajo un enfoque holĆ­stico. Es asĆ­ que utilizo principalmente [SonarQube] como base del trabajo a realizar.

Regresando al caso del millĆ³n de LoC, encontrĆ© pistas que me ayudaron a confirmar la existencia del temible cĆ³digo muerto.

Si queremos empezar con estas prĆ”cticas, algo que nos podrĆ­a ayudar estĆ” incluido en las herramientas del navegador web. Una de las que ha llamado mi atenciĆ³n es la utilizada para analizar la cobertura de los archivos JavaScript y CSS. Esta viene en [Chrome] y no es complicado de usar/entender.

ĀæQuĆ© conseguĆ­ luego de presentar lo encontrado?

El objetivo de mi trabajo en dicho proyecto, fue preparar un informe sobre lo que se estaba construyendo y sobre eso un plan de trabajo para implementar una nueva arquitectura. No me parecĆ­a adecuado llegar con una presentaciĆ³n llena de indicadores ni menos seƱalar responsables (aunque en algunos casos ese ha sido mi trabajo), asĆ­ que gracias al apoyo y explicaciones que el equipo dio cuando estaba analizando el cĆ³digo, tenĆ­a el conocimiento necesario para “limpiarlo”, al menos en casos que parecĆ­an obvios o donde veĆ­a que complejidad baja o media.

Como este tipo de trabajos me gustan, no parĆ© hasta eliminar 95% del cĆ³digo del sistema. No esperaba llegar a ese nĆŗmero pero mĆ”s de un millĆ³n lĆ­neas era cĆ³digo muerto que se podĆ­a limpiar fĆ”cilmente.

Nada mejor que llegar con un informe que tenga un entregable como ese šŸ™‚

La buena noticias es que el equipo quedĆ³ sorprendido. CuĆ”ndo me preguntaron cĆ³mo lo hice, les comentĆ© que empecĆ© por las obviedades (y ya saben lo que pienso de ellas :)) creo que eso los animĆ³ a seguir limpiando (luego de una segunda limpieza el cĆ³digo no superaba las 30 mil LoC)

ĀæQuĆ© es lo que aprendĆ­?

  • Es posible que este tipo de trabajos sea incomprendido al principio, pero se consigue mucho enseƱando con el ejemplo. En dicho proyecto tenĆ­a que preparar una arquitectura que aproveche lo que ya estaba construido, pero ante las sospechas de cĆ³digo muerto, decidĆ­ detenerme un momento y evaluar cĆ³mo eliminarlo, primero por mi cuenta y luego con el equipo.
  • Lo que he encontrado en muchos casos, es que hay pocas intenciones de refactorizaciĆ³n que a veces no se dan por el uso desmedido de frameworks y herramientas. Lo que creo que se debe hacer es sentar una base medible de lo que estĆ” sucediendo sin olvidar que lo mĆ”s se hace en un proyecto de software es la construcciĆ³n del mismo. Si es asĆ­ Āæpor quĆ© no saber cĆ³mo va creciendo nuestro cĆ³digo?
  • La automatizaciĆ³n de pruebas es muy importante pero esta se debe postergar si hay casos obvios de cĆ³digo muerto, he comprobado que a veces resulta mĆ”s rĆ”pido borrar (sin miedo) que ponermos a programar un caso de prueba.
  • Siempre debemos utilizar un gestor de versiones (personalmente prefiero Git sobre GitHub) y tenerlo enlazado a un motor de automatizaciĆ³n (como [Jenkins] o [Azure DevOps], ambos me parecen buenos y Azure DevOps es mĆ”s sencillo de configurar) que ayude a tener visibilidad de la integraciĆ³n continua.
  • El equipo de desarrollo pasa a otro nivel de conocimiento, pues ademĆ”s de entender la importancia de prĆ”cticas de limpieza de cĆ³digo muerto se abre una nueva puerta hacia la calidad del producto.
  • Si la confianza y comunicaciĆ³n son las adecuadas, este tipo de situaciones se convierten en anĆ©cdotas del equipo.

ĀæCuĆ”l fue mi reflexiĆ³n final?

Antes de refactorizar o hacer lo que sea en el sistema, eliminen el CĆ³digo Muerto, no teman.

Un abrazo,

Fuente imagen cabecera: [Finding Dead Code]

Comentarios

Mi aventura en 42 Silicon Valley

Leave a comment

Hace unos meses me animĆ© a postular a [42 Silicon Valley] y creo que tuve suerte para ser aceptado (pues no tuve que dar examen de ingreso) o para conseguir un dormitorio gratis (aquĆ­ si tuve que esperar confirmaciĆ³n luego de casi dos meses)

El punto de inicio era participar en [The Piscine], el bootcamp para demostrar luego de un mes que tienes las habilidades necesarias para ingresar [al programa] que ademĆ”s de ser gratuito, tiene una duraciĆ³n de cinco aƱos.

ĀæEn quĆ© consistiĆ³ el bootcamp?

  • Estudiar todos los dĆ­as de la semana, la mayor cantidad de horas posibles. PodĆ­as usar el material disponible o buscar en internet el material de estudio requerido para cada dĆ­a.
  • Resolver las asignaciones diarias respetando el orden de cada pregunta (es decir, no puedes continuar si no terminas con una pregunta)
  • Respetar reglas de programaciĆ³n sobre el uso de librerĆ­as (muchas no se podĆ­an usar, te pedĆ­an construir tus propias librerĆ­as), nĆŗmero de lĆ­neas (25 lĆ­neas por programa), nĆŗmero de variables (4 por programa), sentencias (el “for” estaba prohibido) y asĆ­…
  • Terminar de programar antes de la hora lĆ­mite (11.42 de la noche)
  • Tener en cuenta que cada lĆ­nea de cĆ³digo escrita deberĆ­a ser fĆ”cil de entender
  • Recibir diariamente 2 evaluaciones aleatorias que se hacĆ­an de manera presencial, lo cual te obligaba entre otras cosas a defender tu cĆ³digo en inglĆ©s (sĆ­ o sĆ­ tenĆ­as que hablar)
  • Realizar diariamente 2 evaluaciones (como dije, sĆ­ o sĆ­ tenĆ­as que hablar)
  • Participar en los trabajos grupales, que si bien es cierto no eran aleatorios, requerĆ­an mucha coordinaciĆ³n.
  • Participar en los exĆ”menes semanales, en los que cada viernes te asignaban una computadora que no tenĆ­a acceso a internet ni a herramientas como Visual Studio Code, asĆ­ que si no sabĆ­as como usar vim o comandos en Linux, estabas muerto šŸ™‚
  • Tener en cuenta que los tres primeros exĆ”menes durarĆ­an 4 horas y el Ćŗltimo serĆ­a de 8 horas
  • Programar en C
  • No hacer trampa, pues si bien es cierto los problemas se pueden conseguir fĆ”cilmente, si no puedes explicarlos o se descubre que ese no es tu cĆ³digo, cosas malas pueden ocurrir (ademĆ”s de que queda en tu registro y te podrĆ­an invitarte a salir del programa)

Pues bien, fueron cuatro semanas en las que ademƔs de compartir dormitorio con dos amigos de China y uno de KazajistƔn, conocƭ amigos de Rusia, Francia, Argentina, Brasil, China, Korea y USA. AdemƔs, en todo ese tiempo aprendƭ de todo un poco, inclusive como ahorrar tiempo y dinero pues a pesar de vivir gratis en el campus, necesitabas dinero para comer y allƔ todo era caro :O

SĆ­, hay una bandera de PerĆŗ šŸ˜€ y como datos anecdĆ³ticos, era el Ćŗnico peruano y la foto muestra a los que quedamos hasta el final pues mĆ”s del 50% se retirĆ³

ĀæQuĆ© aprendĆ­?

AdemĆ”s de respirar programaciĆ³n, encontrĆ© cosas muy interesantes:

  1. Resiliencia: Si hay una palabra para definir a las personas que conocĆ­ en el bootcamp, esa es la primera que podrĆ­a decir. Muchos amigos tenĆ­an unas ganas de superaciĆ³n increibles, algunos trabajaban por las tardes o noches. Otros no lograron conseguir dormitorio, asĆ­ que viajaban una o dos horas (algunos manejando) para llegar diariamente al campus. Todo por estudiar.
  1. ColaboraciĆ³n: Si bien es cierto encontrĆ© casos de segregaciĆ³n de acuerdo al paĆ­s de origen o similitud de conocimientos, cuando habĆ­a problemas nadie dudaba en ayudar si te acercabas a preguntar. Algunos lo hacĆ­an con muchas mĆ”s ganas que otros, pero todos terminaban respondiendo al pedido de ayuda.
  1. Empatƭa: Algunas veces mi evaluador no sabƭa como decirme que me habƭa equivocado pues le daba pena que eso afectara a mi promedio. Esto lo supe pues me puse a conversar con ellos pidiendo mƔs detalle ya que al igual que todos, querƭa aprender.
  1. Humildad: Algunas personas sabĆ­an lo suficiente como para terminar el trabajo en la mitad del tiempo o menos, pero a pesar de ello ni alardeaban, ni lo demostraban cuando te tocaba evaluar su cĆ³digo o cuando ellos evaluaban el tuyo. Me pasĆ³ mĆ”s de una vez que hubo personas que me para preguntaban como habĆ­a resuelto un problema y a veces descubrĆ­an un error en su lĆ³gica o algo por mejorar en ella. Nunca se molestaban, siempre agradecĆ­an.
  1. Optimismo: Una frase con la que siempre me encontraba cuando cometĆ­a un error era “no te preocupes, es solo un test, maƱana lo haremos mejor” Lo genial es que a veces ocurrĆ­a con personas que acababa de conocer.
  1. Competencia sana: Si bien es cierto todos sabĆ­amos que cada examen semanal era determinante para ser aceptado en el programa oficial y que no todos serĆ­amos aceptados, todos nos animĆ”bamos antes de empezar cada evaluaciĆ³n. Al finalizar nos preguntĆ”bamos comos fue y hubo casos en los que comparĆ”bamos soluciones. En mi caso preferĆ­a ir a dormir ā€“pues terminaba muy cansadoā€“ pero al dĆ­a siguiente la conversaciĆ³n seguĆ­a šŸ™‚
  1. ComunicaciĆ³n: Si me preguntan cuĆ”l es diferenciador con respecto a lo que he visto en el medio local (es decir, PerĆŗ), este es un elemento muy importante. Teniendo en cuenta de que los programadores no hablamos mucho, eso tambiĆ©n ocurre fuera del paĆ­s, pero la diferencia es que estando allĆ”, me encontrĆ© con personas que ademĆ”s de escribir buen cĆ³digo, explicaban muy bien lo que hacĆ­an o en todo caso, sabĆ­an vender muy bien sus ideas. Cosa que humildemente tenemos que seguir mejorando.

ĀæQuĆ© pasĆ³ despuĆ©s?

Como mencionĆ© anteriormente, el examen final fue un viernes y tenĆ­a una duraciĆ³n de 8 horas, en mi caso terminĆ© de programar en la sĆ©ptima hora. No recuerdo el nĆŗmero de problemas que resolvĆ­ pero sĆ­ que habĆ­a programado sin descanso alguno, asĆ­ que cuando sentĆ­ que necesitaba salir de ahĆ­, fue lo que hice. La verdad es que, cuando tu cabeza no da para mĆ”s, lo mejor es dejar de programar.

A las dos semanas de dar el examen estaba de viaje y con poco acceso a internet, recuerdo que cuando pude conectarme, recibĆ­ con mucha sorpresa el correo de aceptaciĆ³n al programa, podĆ­a irme a estudiar por tres aƱos y si no tenĆ­a donde vivir, podĆ­a postular nuevamente para conseguir un dormitorio.

ĀæQuĆ© es lo que harĆ©?

En esta Ć©poca de mi vida me gustarĆ­a volver a enseƱar, mientras tanto estoy retomando mi prĆ”ctica de escribir y reforzar mis conocimientos en [arquitectura] (es por eso que mi blog ha renacido), ademĆ”s estoy presentando una tesis para conseguir mi maestrĆ­a en administraciĆ³n y en paralelo a esto, me puse a estudiar mi segunda maestrĆ­a mientras busco un nuevo empleo.

Creo que estoy algo ocupado por el momento (o quizĆ” algo loco), pero bueno, nunca se sabe šŸ™‚

Un abrazo,

Comentarios

Microservicios y cĆ³digo de ejemplo

1 Comment

Estaba preparando una propuesta de charla de [microservicios] y mientras buscaba informaciĆ³n para el cĆ³digo de ejemplo, me di con la sorpresa de que lo que encontraba en la web era de complejidad media/alta (o no se entendĆ­a) o peor aĆŗn, a pesar de que muchos (podrĆ­a afirmar que mĆ”s del 50%) indicaban que se trataban de microservicios, pues no lo eran.

Fuente: [microservices]

ĀæCĆ³mo confirmas si estĆ”s viendo un microservicio?

Siendo concretos, un microservicio debe:

  1. Responder a un solo trabajo, es decir, una sola funcionalidad
  2. Ser autĆ³nomo incluso en su instalaciĆ³n

Okey, hay [otras consideraciones] a tomar en cuenta, pero a mi entender si no pasamos los dos primeros filtros, no tiene sentido seguir avanzando.

ĀæQuĆ© hice al respecto?

Sin ir en muchos detalles, se me ocurriĆ³ detener lo que estaba haciendo para ponerme a escribir cĆ³digos de ejemplo de microservicios.

Ojo, no me considero un experto pero creo que mi idea es sencilla, crear un proyecto para compartir lo que voy aprendiendo.

ĀæEn quĆ© consiste el proyecto?

El requitisto principal es que el cĆ³digo sea fĆ”cil de entender y que ademĆ”s permita aprender a construir microservicios. Es asĆ­ que lo que tengo en mente hasta ahora es:

  • Una plantilla de cĆ³digo (incluye soporte de HTTP GET)
  • CĆ³digo de ejemplos para:
    1. Soporte de HTTP GET
    2. Soporte de HTTP GET y parƔmetros
    3. Soporte de HTTP POST y parƔmetros
    4. Soporte de HTTP GET y Docker para desplegar el microservicio

Inicialmente pensĆ© en escribir todo en NodeJS pero luego dije ĀæPor quĆ© no mĆ”s lenguajes?

ĀæQuĆ© he avanzado hasta ahora?

Pues como dije lĆ­neas arriba, me animĆ© a escribir algo de cĆ³digo šŸ™‚ El proyecto se llama microservices-templates y ya estĆ” en GitHub, aquĆ­ la url: https://github.com/jersson/microservices-templates

Si bien es cierto tengo en mente programar en al menos cinco lenguajes, decidĆ­ que no podĆ­a esperar tanto para liberar algo, asĆ­ que aquĆ­ va la versiĆ³n en NodeJS: https://github.com/jersson/microservices-templates/tree/master/00-node

Como podrĆ”n notar en el cĆ³digo, este incluye descripciones sobre como probar cada microservicio. AdemĆ”s, cada archivo tiene pocas lĆ­neas de cĆ³digo y cada una de ellas la he escrito de manera que busquĆ© facilitar su lectura.

Este proyecto me gusta bastante y estoy seguro de que si consigo ayuda podrĆ© avanzar mĆ”s rĆ”pido, asĆ­ que si les interesa aprender o ya saben como escribir o mejorar lo que estoy construyendo, anĆ­mense, estarĆ© aquĆ­ o en GitHub šŸ™‚

Sin mƔs que decirles me despido esperando que tengan un excelente nuevo aƱo.

Un abrazo.

Fuente imagen cabecera:[what are microservices?]