tag:blogger.com,1999:blog-234707062024-03-18T02:48:26.865-07:00DevelopeandoBlog de Mario CornejoMario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.comBlogger167125tag:blogger.com,1999:blog-23470706.post-26987589585068168172021-02-19T20:53:00.000-08:002021-02-19T20:53:06.093-08:00Tú, no eres tu código<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-iv56Ficub2s/YDCSvZMyzYI/AAAAAAAABz4/OYOSgjVSL54QfhPQCDAt23x3Vvq7SsxRACNcBGAsYHQ/s2048/thisisengineering-raeng-8hgmG03spF4-unsplash.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1366" data-original-width="2048" height="426" src="https://1.bp.blogspot.com/-iv56Ficub2s/YDCSvZMyzYI/AAAAAAAABz4/OYOSgjVSL54QfhPQCDAt23x3Vvq7SsxRACNcBGAsYHQ/w640-h426/thisisengineering-raeng-8hgmG03spF4-unsplash.jpg" width="640" /></a></div><p style="text-align: justify;">Escribir código puede sentirse muy personal, sobre todo si pasas mucho tiempo pensando en él, diseñando, escribiendo, editando y quizás reconstruyendo módulos para lograr que se vea mejor. Puedes sentir orgullo por el código que escribes y por lo tanto, llegar a pensar que es parte de ti; pero la verdad es que: el código, no es parte de ti, es solamente algo más que hiciste.</p><p style="text-align: justify;">Tú, no eres tu código. El código representa el nivel que tenías cuando lo escribiste; pero no te representa a ti como persona. Eso significa que está bien hablar de tu código con confianza, ver las fallas y oportunidades de mejora sin sentir que estamos hablando de las fallas de la persona que lo escribió. Una cosa es hablar de las fallas del código y una muy distinta hablar de las fallas de la persona.</p><p style="text-align: justify;">Lo mismo aplica a las ideas acerca de la arquitectura y los procesos que debemos seguir para crear un producto de software. Alguien puede sugerir que se use algo diferente o usar algo de manera distinta. Esa persona puede sugerir cosas que quizás ya son obsoletas para ti. El sentir que sus ideas son viejas u obsoletas no significa que pienses que esa persona es vieja u obsoleta. Puede pasar que seas tú esa persona que sugiere cosas que para alguien más ya no se usan. Debes de no tomarlo personal para que así puedas evaluar las alternativas que te están sugiriendo. Si lo tomas como un ataque a tu persona será difícil poner atención a las ideas que proponen, se complicará ver las fallas de tu idea y poder aprender de eso.</p><p style="text-align: justify;">Cada que veas código viejo escrito por ti, puedes sentir orgullo, eso está bien; pero también deberías de sentir un poco de "vergüenza", porque ahora puedes ver muchas mejoras que le puedes hacer, esos detalles que no viste porque fue ya hace tiempo y no tenías la experiencia que ahora tienes. Si ves tu código viejo y no sientes algo de pena, entonces quizás no estás mejorando tus habilidades para programar. Para ayudar con eso, debes dejar que otros comenten lo que opinan de tu código, sin tomarlo personal e incluso si no estás de acuerdo. También intenta leer cómo otras personas resuelven esos mismos problemas con nuevos estilos, busca cómo innovar.</p>Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com1tag:blogger.com,1999:blog-23470706.post-30321264597361663692020-08-22T13:45:00.002-07:002020-08-22T13:45:28.256-07:00Primero la pregunta y después el contexto<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-CIHc7jhJWWw/X0GB4-VOy-I/AAAAAAAABvI/UGUtFxk0zXYTse006HSBcRPja-4eIRWSwCNcBGAsYHQ/s1280/0.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="704" data-original-width="1280" src="https://1.bp.blogspot.com/-CIHc7jhJWWw/X0GB4-VOy-I/AAAAAAAABvI/UGUtFxk0zXYTse006HSBcRPja-4eIRWSwCNcBGAsYHQ/s640/0.jpeg" width="640" /></a></div><p>A veces cuando alguien quiere hacerme una pregunta, empieza por darme contexto sobre el tema del que va a preguntar. Me empiezan a explicar cómo fue que llegaron a la pregunta que tienen en mente. Algunos comienzan por explicarme lo que han intentado para resolver el problema que enfrentan, me explican el porqué de esos intentos. Ha habido, incluso, ocaciones en que me explican las respuestas que han encontrado en internet; pero todo esto sin haberme hecho la pregunta todavía.</p><p>Comprendo que me dan el contexto para ayudarme a encontrar la mejor respuesta, también lo hacen para que no crea que no han intentado encontrar la respuesta por su cuenta; o quizás para que no piense que me consultan sin tener una buena razón. Entonces empiezan por justificar el porqué de la pregunta sin siquiera haberme hecho la pregunta todavía. </p><p>El contexto de la pregunta es importante, sirve para saber de qué estamos hablando en realidad, lo cual es bueno para dar una respuesta correcta. Entender el porqué sin saber el qué es más complicado. El contexto o el saber qué se intentó, sí me ayuda; pero una vez que conozco la pregunta, cuando sé que problema es el que se necesita resolver. A veces ni siquiera necesito saber porqué se necesita resolver el problema, con la sola pregunta puedo dar una respuesta rápida o puedo darme cuenta que no voy a poder contestarla sin importar el contexto, en esas ocaciones iniciar con la pregunta nos ahorra a todos algo de tiempo.</p><p>Yo también hago esto, empiezo por explicar la razón de alguna pregunta en lugar de solo iniciar con la pregunta y partir de ahí. Si se necesita contexto, es bueno darlo; pero no antes de la pregunta. Intentemos iniciar con la duda y después podemos explicar lo que hemos intentado para resolverlo, lo que queremos lograr con esa respuesta o el porqué de la pregunta; pero solo después de haber hecho la pregunta. No iniciemos por el contexto, primero hagamos la pregunta.</p>Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com1tag:blogger.com,1999:blog-23470706.post-90449532417719390802020-07-11T20:15:00.001-07:002020-07-11T20:16:51.133-07:00Fighting Frustration<div class="reader-article-content" dir="ltr"><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-otPisbtmX-Y/XwqAjLZiAeI/AAAAAAAABuM/TMcxfIpG1LcafbxUSnahPNypJ_TLhfeyQCNcBGAsYHQ/s1079/0.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="720" data-original-width="1079" height="419" src="https://1.bp.blogspot.com/-otPisbtmX-Y/XwqAjLZiAeI/AAAAAAAABuM/TMcxfIpG1LcafbxUSnahPNypJ_TLhfeyQCNcBGAsYHQ/w625-h419/0.jpg" width="625" /></a></div><p>Some days things don't
go the way I expected, sometimes people don't agree with my opinion or
with what I feel is "obviously" more important to do. It's easy to start
thinking that some people just don't care, if only they leave me alone
and allow me to do my work, I can change the company. I can blame others
when things go bad and start thinking that is their fault because they
have a different opinion than mine.</p><p>But the true is that if
something goes wrong, with the project I'm working, it's my fault. I
should be responsible to finish the project, in time and budget, and
because of that, I have to deal with all the bureaucracy that needs to
be dealt with. I have to realize that I need to do that as part of my
job. Besides, is not that people don't care is just that they have a
different (and valid) approach than mine.</p><p>How do I deal with the
frustration? Well... first I need to stop complaining, because if I
start to focus in the bad and let the negativity enter my mind, all the
required work will be harder. I need to stop focusing in the bad and see
the challenges as an opportunity to grow my skills. If I want others to
follow my lead or my ideas what I need is to show them how I can get
results and being known by my results instead of being known as a
complainer.</p><p>Frustration is a feeling that I need to choose not to
feel, if things don't go the way I expected then I take a step back, see
what it didn't worked, what alternatives do I have and then try again
using another approach, all this without complains. The solution is not
that others change their opinions, the goal should be for me, to
understand their reasons and give them a solution that address their
concerns and allow me to complete the project on time.</p><p>So... to fight frustration I will <b>stop complaining and start doing</b>.</p></div>Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-24876877796213964472019-10-05T13:09:00.003-07:002019-10-05T13:09:57.310-07:00Bloqueos<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-cX0aQ7I0FtQ/XZj4VMBf1NI/AAAAAAAABq0/bc7NPgK5Flc90icrKqa61bfzuO7_ZG4NgCNcBGAsYHQ/s1600/bloqueo.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="446" data-original-width="487" height="585" src="https://1.bp.blogspot.com/-cX0aQ7I0FtQ/XZj4VMBf1NI/AAAAAAAABq0/bc7NPgK5Flc90icrKqa61bfzuO7_ZG4NgCNcBGAsYHQ/s640/bloqueo.jpg" width="640" /></a></div>
<br />
Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.<br />
<br />
He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea. <br />
<br />
En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto problemas similares y conoce los problemas comunes con cada posible solución. Si no ha resulto algo similar entonces es capaz de investigar, realizando búsquedas más concretas que le dan una mejor respuesta para el problema en particular que se quiere resolver. Para una persona con más experiencia los bloqueos son cuando está esperando información de alguien más. Puede ser alguna respuesta del cliente, la definición por parte de otro equipo sobre que herramienta en particular se va a usar.<br />
<br />
La principal diferencia es que la persona sin experiencia puede sentir que está bloqueada aunque el problema no involucre a otras personas. La persona sin experiencia acepta la idea de que está bloqueada porque no tiene idea de como resolverlo. Por otro lado, una persona con experiencia sabe que si no ha resuelto el problema por si misma aun, entonces no hay un bloqueo solo hay un retraso, debe de intentar otras formas, debe de investigar, debe de preguntar a otros miembros del equipo o personas externas incluso. Es decir tiene cosas que hacer para resolver el problema, no está bloqueada a que alguien más venga a resolverle el problema. La persona con experiencia no acepta la idea de tener un bloqueo si el resolverlo depende de sí misma.<br />
<br />
¿Qué pasa con los bloqueos que tiene la persona con experiencia, esos bloqueos que son porque está esperando que el cliente le conteste o que alguien más termine otra parte del sistema? En esos bloqueos la persona encargada del sistema puede buscar en qué otra cosa se puede trabajar mientras se da algo de tiempo a quien debe de dar la información. Se agrega como tarea dar seguimiento a las respuestas que se están esperando. Se busca la forma de obtener esa información lo antes posible o de trabajar alrededor de eso para que en cuanto llegue la información se pueda incluir de manera rápida.<br />
<br />
El patrón que se observa en estos ejemplos es que lo que para unos es un bloqueo para otros son tareas a realizar para poder avanzar en el proyecto. Eso significa que un bloqueo que puedes usar como excusa para no trabajar puede convertirse en una tarea, en trabajo que puedes realizar para poder progresar en el proyecto. El llamarlo bloqueo depende de lo que aceptes que puede ser un bloqueo para ti. Puede variar según tu nivel de experiencia; pero debes de tender a tener cada vez menos bloqueos hasta que puedas trabajar sin bloqueos. Debemos aspirar a ser profesionales que encuentran una solución a todos los problemas a los que nos enfrentamos para completar los proyectos.<br />
<br />
<a href="https://es.wikipedia.org/wiki/Robert_C._Martin" target="_blank">Robert C. Martin</a> comentó en una de sus presentaciones que: "...lo peor que podemos hacer como profesionales es nada", cuando <a href="https://youtu.be/zwtg7lIMUaQ?t=1113" target="_blank">hablaba del tema de no estar bloqueado</a>. Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-50535754907103484542019-09-30T08:21:00.000-07:002019-09-30T20:22:51.203-07:00Comentar lo buenoLa intensión de que alguien más revise mi trabajo es poder encontrar posibles errores o revisar que haya tomado en cuenta detalles importantes. Se puede aprender cuando alguien más revisa lo que haces. <br />
<br />
Los <i>code reviews</i> es un ejemplo de eso, se revisa el código y se ve qué es lo que se puede mejorar, se critica el estilo y la manera en la que se implementó la solución en el código. Los comentarios en la revisión del código ayudan a darme cuenta de lo que hice mal o de lo que pude haber hecho mejor y me hace crecer porque la siguiente vez que implemente algo similar sabré a que (otras) cosas debo poner atención, en base a esos comentarios.<br />
<br />
También revisar el código de alguien más, con la intención de encontrar oportunidades de mejora, me ayuda a mí. No solamente le ayuda a quien escribió el código, también me ayuda a mí porque soy consciente de esos detalles que quizás no los hubiera visto si no hubiera revisado el código con la única intención de buscar mejoras. Después, cuando programe algo similar, puedo recordar esos comentarios que hice al código de alguien más y mejorar el código que yo mismo escribo, tomando en cuenta eso que comenté en la revisión.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-4WvV72d-3Sc/XY7OK0CgPJI/AAAAAAAABqQ/pdt8uql21OkDTo3t269N8tjBk6u3XCsgwCNcBGAsYHQ/s1600/good-job-not-done-anything-stupid-in-five-minutes-funny-retro-poster.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="488" data-original-width="335" height="640" src="https://1.bp.blogspot.com/-4WvV72d-3Sc/XY7OK0CgPJI/AAAAAAAABqQ/pdt8uql21OkDTo3t269N8tjBk6u3XCsgwCNcBGAsYHQ/s640/good-job-not-done-anything-stupid-in-five-minutes-funny-retro-poster.jpg" width="438" /></a></div>
<br />
Pero no solo es importante comentar las oportunidades de mejora, también es bueno comentar lo bueno de lo que se está revisando. Los comentarios buenos, que no recomiendan una mejora, sino que simplemente resaltan lo se hizo bien, ayudan a motivarme para hacer un buen trabajo. No solo busco que mi código se vea bien para que no me comenten como mejorarlo, ahora también me motivo a dar un extra porque sé que el equipo lo va a apreciar. Van a notar esos detalles extras, ese plus.<br />
<br />
A veces puedo enfocarme en revisar que todo esté bien, comentar esas posibles mejoras y sentir que ya terminé la revisión; pero me doy cuenta que así como busco lo que se puede mejorar debo también buscar lo que quedó bien y también comentarlo. Cuando encuentre lo bueno y lo malo entonces ya puedo decir que terminé mi revisión. Claro que no se trata de siempre comentar, solo cuando se amerite. Si todos los comentarios son buenos, se pueden volver irrelevantes. La idea aquí es que, al revisar, debo poner atención a lo bueno también, así como lo hago con los posibles errores u oportunidades de mejora.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com2tag:blogger.com,1999:blog-23470706.post-70074322132031249832019-09-22T18:35:00.001-07:002019-09-22T18:35:45.228-07:00Trabajando remoto. ¿Desde casa u oficina?Casi toda mi carrera de programador o ingeniero de software la he realizado de manera remota, aunque ha habido temporadas en las que sí estuve trabajando desde una oficina como parte de un equipo; pero la mayoría del tiempo lo he trabajado desde casa.<br />
<br />
Actualmente a veces voy a la oficina y trabajo un turno completo desde allí, otras veces lo hago desde casa; pero siempre de manera remota, el resto de las personas trabajando en los proyectos están en otra parte. No es lo mismo trabajar de manera remota o a distancia que trabajar desde casa.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-CBdJmTMauoQ/XYWcVJeNmrI/AAAAAAAABp4/DQkZlzjbRGcgpIBoguWvU2UVTxgNrOYGwCNcBGAsYHQ/s1600/oficina.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1200" data-original-width="1600" height="480" src="https://1.bp.blogspot.com/-CBdJmTMauoQ/XYWcVJeNmrI/AAAAAAAABp4/DQkZlzjbRGcgpIBoguWvU2UVTxgNrOYGwCNcBGAsYHQ/s640/oficina.jpg" width="640" /></a></div>
<br />
<br />
Una diferencia es el tiempo que estás disponible para trabajar, cuando voy a la oficina y allá dejo el equipo (la laptop y cuaderno con notas) no puedo seguir trabajando cuando ya llegué a la casa, lo mismo pasa a la mañana siguiente. Ha pasado que me piden algunos cambios rápidos y debo esperar a llegar a la oficina para atenderlos. Esta es la principal diferencia, cuando estoy desde casa siento que tengo todo el día para terminar mis tareas y me la llevo tranquilo haciendo que pase más tiempo en el trabajo. Cuando estoy en la oficina trato de trabajar más rápido, casi sin darme cuenta lo hago. Me imagino que es porque sé que no tengo todo el día y que en unas horas debo irme a casa. <br />
<br />
Otra diferencia son las interrupciones, aunque en la oficina también pasan, son distintas; como el resto de las personas en la oficina conmigo no están trabajando en el mismo proyecto, se puede llegar a sentir un poco como distracciones, más que las que ocurren en casa. Puede ser por lo mismo de que en la oficina siento el tiempo más limitado.<br />
<br />
El traslado es otra característica, aun estando remoto hay traslado si voy a una oficina a "<i>remotear"</i>. Como que aquí no tiene mucho sentido ser remoto si de todos modos me estoy trasladando a una oficina. Algunas veces me gusta porque aprovecho para escuchar música o algún <i>podcast</i>, disfruto manejar (si trabajo muchos días desde casa, casi no manejo). Por otro lado es agradable la semana que me quedo en casa y veo que no gasté en gasolina esa semana.<br />
<br />
Me gusta la sensación de ir a la oficina y terminar todo a tiempo para poder irme a casa y ya no pensar en el trabajo; pero también extraño estar en casa todo el día, estar con la familia desde temprano aunque esté trabajando incluso hasta un poco más tarde.<br />
<br />
La idea de la oficina fue tener un equipo y trabajar juntos; pero al equipo también le gusta trabajar remoto y a veces es más fácil revisar código viendo la pantalla de la otra persona compartiéndola y hablando con un <i>headset </i>usando herrarmientas como Slack, Zoom, Skype, etc. la otra persona y yo estamos viendo la pantalla de frente, cuando estamos en persona hay más distracciones y alguien ve la pantalla de lado.<br />
<br />
Empiezo a dudar si es buena idea tener una oficina para equipos de desarrollo de software.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com2tag:blogger.com,1999:blog-23470706.post-70328252743059085372019-07-20T21:27:00.002-07:002019-07-23T17:13:50.594-07:00Editor de texto obscuro y editor de texto claro <div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-D2YXSgNkTr4/XTPmM3yFGFI/AAAAAAAABoc/fyyfkvwfCpssnaWY78bF07I3AqiK_CsJACLcBGAs/s1600/dark-light.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="377" data-original-width="623" height="386" src="https://1.bp.blogspot.com/-D2YXSgNkTr4/XTPmM3yFGFI/AAAAAAAABoc/fyyfkvwfCpssnaWY78bF07I3AqiK_CsJACLcBGAs/s640/dark-light.png" width="640" /></a></div>
<br />
Estos últimos meses he regresado a programar tiempo completo, además de realizar tareas administrativas y administración de proyectos. Esto ha hecho que tenga que programar un rato en la mañana, luego atender unas juntas, después programar otro rato por la tarde y en las noches. No siempre estoy en el mismo lugar, por lo general durante el día voy a una oficina donde trabajo en un monitor externo y en la noches trabajo desde la laptop en mi casa.<br />
<br />
He notado que cuando estoy en el monitor externo y la luz de la oficina está detrás de mi, no es tan intensa en la pantalla, usar el fondo de pantalla obscuro ayuda a sentir la vista cómoda mientras programo. Uso macOS y Windows, afortunadamente ambos sistemas operativos tienen un <i>Dark Mode</i> para esas ocasiones que prefiero usar el editor de texto con un tema obscuro.<br />
<br />
Cuando estoy en la casa desde la laptop, ya sea una PC o la Macbook Pro, tiendo a usar el fondo claro. También ha pasado si estoy con un monitor externo que está justo debajo de un foco, el fondo obscuro en estas ocasiones no se siente cómodo. Esto es, en parte, porque me reflejo en la pantalla y siento que leo mejor si tengo el fondo claro y es más fácil navegar entre aplicaciones que tienen el fondo claro siempre, ya que hay algunas que no soportan el fondo obscuro, como Slack (también hay las que no soportan un tema claro, como Spotify).<br />
<br />
A veces siento que debo elegir un tema, usar ese y acostumbrarme; pero no logro decidirme si solamente usar fondo claro u obscuro y en cierto modo me gusta usar los dos, de ese modo el fondo del editor no es excusa para no ponerme a programar. Algo similar <a href="http://www.developeando.com/2011/12/teclado-en-espanol-latinoamerica.html" target="_blank">me pasa con los teclados</a>, me gusta poder usar cualquier layout sin estar quejándome como he visto a otros o como lo llegué a hacer yo mismo. Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-12733139683153342062019-05-11T14:52:00.000-07:002019-05-13T11:00:17.402-07:00Trabajando bajo presiónNo es raro encontrar ofertas de empleo donde como parte de las habilidades requeridas se pide trabajar bajo presión. Esto generalmente es una <a href="http://www.developeando.com/2015/06/banderas-rojas-en-las-ofertas-de-empleo.html" target="_blank">bandera roja</a>. Puede ser un lugar en el que no hay un proceso definido para realizar las cosas o que los tiempos estimados son muy optimistas y por lo tanto se necesita sacar el trabajo para "ayer".<br />
<br />
En las empresas chicas es común que haya presión por sacar el trabajo rápido. En una empresa grande es fácil pasar semanas sin trabajar y que apenas se note; pero en empresas chicas, donde el dinero y el personal es menor, es más notorio cuando el trabajo no se termina a tiempo.<br />
<br />
Aún cuando se haya planeado todo a detalle siempre hay cosas que se salen del plan, por ejemplo: puede ser que un cliente no entrego la información a tiempo, que el trabajo era más complicado de lo esperado, el resultado que el cliente esperaba era otro y ahora necesita que se haga de otra manera lo antes posible y esto nos va afectar la fecha de entrega final, etcétera. No se puede asegurar que las cosas van a salir bien siempre y eso es parte del trabajo, no te enojes, míralo como parte del proceso. Puede ser fácil apuntar a la persona culpable de que las cosas no hayan salido bien y concentrarse en eso; pero si te concentras en eso puedes sentir frustración por pensar que tienes que pagar (con tu trabajo y tiempo) los errores de alguien más. Piensa que es un trabajo en equipo, si algo salió mal es parte del trabajo, no es algo personal.<br />
<br />
Puedes llegar a sentir que todo urge; sentir una presión por terminar todo a la carrera, que debes apurarte para entregar. Ante estos escenarios es necesario que haya tranquilidad con la presión. Con esto no me refiero a tener un actitud desdeñosa; sino a tener una actitud calmada.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-zJ_EIU_PYnw/XNcnKnrtoSI/AAAAAAAABmA/kvwzQFP-50on7U3_kySUv7mZ4cb2OIDbwCLcBGAs/s1600/Calm%2Bunder%2Bpressure%2Bistock.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="580" data-original-width="870" height="426" src="https://4.bp.blogspot.com/-zJ_EIU_PYnw/XNcnKnrtoSI/AAAAAAAABmA/kvwzQFP-50on7U3_kySUv7mZ4cb2OIDbwCLcBGAs/s640/Calm%2Bunder%2Bpressure%2Bistock.jpg" width="640" /></a></div>
<br />
Para sentirte cómodamente con la presión debes despegarte del problema. Ve la situación como si fuera un problema que le pasa a alguien más. En ocaciones es más fácil ver la solución de los problemas de los demás. A veces es obvio como resolver el problema; pero estamos tan metidos en el problema y presionados por resolverlo que puede ser que no vemos las soluciones que están frente a nosotros. Si ves el problema desde una perspectiva despegada entonces puedes ver el problema con una actitud tranquila (como si no fuera tu problema). No siempre es fácil despegarse del problema, es cuestión de seguir practicando.<br />
<br />
Es importante conocer las causas del problema para poder encontrar una solución. Es necesario, al buscar estas causas no concentrarnos en culpables. No se trata de ver qué persona tuvo la culpa del problema donde nos encontramos. La idea de buscar causas es entender el problema, la idea no es apuntar dedos ni estarse quejando, las quejas no ayudan, solo harán que te sientas peor. Una vez que entiendes el problema, con una buena actitud, puedes concentrate en la solución.<br />
<br />
Debes verte como la solución al problema y hacer el trabajo necesario para arreglarlo, un paso a la vez porque no siempre se puede arreglar todo al mismo tiempo, procura que tu solución no sea trabajar toda la noche. Atendiendo el problema con calma; pero progresando en la solución es lo que puedes hacer. Siempre manteniendo la calma.<br />
<br />
Sentirse a gusto con la presión es una habilidad de valor, si tomas esto en cuenta, esa oferta de empleo que pide que sepas trabajar bajo presión puede no ser tan mala, siempre y cuando la remuneración sea la adecuada. Trabajar bajo presión no tiene que ser estresante para ti. Si los clientes o jefes están presionados es problema de ellos. No se trata de que no te importe o que seas indiferente a sus necesidades, se trata de que mantengas la calma para pensar claro y dar soluciones. Y que logres disfrutar tu trabajo porque estás haciendo tu mejor esfuerzo por solucionar problemas. Solucionar problemas puede ser divertido.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com1tag:blogger.com,1999:blog-23470706.post-39038515428306227222019-01-13T20:23:00.000-08:002019-01-15T09:28:57.536-08:00¿Cuándo lo tengo que terminar?<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-tEz3uAtCRJg/XDwI-Vmew3I/AAAAAAAABic/8P73JS1Mk50jdnIeo33aWC87FpvWUoCkgCEwYBhgL/s1600/no-lo-se-tu-dime3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="600" data-original-width="1225" height="312" src="https://1.bp.blogspot.com/-tEz3uAtCRJg/XDwI-Vmew3I/AAAAAAAABic/8P73JS1Mk50jdnIeo33aWC87FpvWUoCkgCEwYBhgL/s640/no-lo-se-tu-dime3.jpg" width="640" /></a></div>
<br />
Me ha pasado que le pido a alguien que me ayude con cierta tarea de desarrollo de software y me pregunta que cuándo lo tiene que terminar<span style="background-color: white;"><span style="color: black; display: inline; float: none; font-family: "times new roman"; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">. </span></span>Mi respuesta generalmente es: "lo antes posible"; pero la persona que va a hacer el trabajo es quien debería de decirme cuándo considera que va a estar listo, claro que su respuesta debe estar justificada. Tampoco se trata de que invente un número.<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Parece que estamos acostumbrados a que alguien más nos diga para cuándo ocupa lo que nos pide y nosotros ya veremos como le hacemos para cumplir con esa fecha. Quizás sea que esta costumbre la tenemos porque así se nos enseña en la escuela. Se nos pide un proyecto de tarea y se nos da una fecha de entrega. Es curioso; pero generalmente desarrollar el proyecto se toma todo el tiempo que tenemos... ni más, ni menos.<br />
<br />
Se nos enseña que la persona que pide el trabajo nos dirá para cuándo lo quiere listo. No nos enseñan que como profesionales, somos nostros, los que <a href="http://www.developeando.com/2015/09/debemos-dar-estimados.html" target="_blank">debemos dar estimados</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
Lo hacemos, también, porque al preguntar en cierta forma estamos evadiendo la responsabilidad de entregar algo completo en la fecha dada. Porque podemos alegar después que no quedó completo por falta de tiempo y sentir que no fue nuestra culpa. Podríamos decir que nos da miedo equivocarnos.</div>
<br />
Si hacemos seguido eso que nos da miedo, después ya no nos dará miedo. Podemos intentar hacer estimados seguido. Al principio es normal equivocarse, puede que seamos muy optimistas y después darnos cuenta que es más trabajo del previsto. Aun así debemos seguir practicado estimar el trabajo que nos piden. Incluso cuando no hay fecha límite, pensemos en: <i>"¿Qué tengo que hacer y cuánto tiempo me tomará cada tarea?".</i> De ese modo vamos practicando y podemos revisar al final del proyecto si tomamos en cuenta (en la estimación original) todo el trabajo que en realidad tuvimos que realizar.<br />
<br />
La próxima vez que nos pidan un proyecto, recordaremos esos detalles que se nos pasaron en el proyecto anterior y los tomaremos en cuenta. Así cada vez, la estimación será más apegada a la realidad y en lugar de preguntar para cuándo, ahora nosotros daremos la fecha aproximada en que puede estar listo eso que nos piden, claro que siempre agregando algo de margen para los imprevistos. <br />
<br />Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com2tag:blogger.com,1999:blog-23470706.post-62274161709320219862018-11-15T22:01:00.000-08:002018-11-16T10:49:11.913-08:00Email para el SeguimientoEn varios equipos de desarrollo con los que trabajo se ha dejado de usar el correo electrónico como principal forma de comunicación, para ahora usar herramientas de mensajería instantánea. Herramientas como: Skype, Slack o similares son comunes. Todo esto está bien porque permite una mayor interacción entre el equipo de desarrollo. Hay una retroalimentación rápida sobre el trabajo a realizar.<br />
<br />
Esta mayor interacción también provoca que haya muchos mensajes que leer, de ahí surge la necesidad de tener canales o "conversaciones" específicas para cada proyecto. Sirve tener canales específicos porque así podemos ver toda la información relacionada a cierto proyecto en un solo lugar. Esto ha influido para que cada vez se use menos el correo electrónico entre los equipos de desarrollo con los que trabajo.<br />
<br />
El problema de los mensajes instantáneos surge cuando se necesita ver el panorama general del proyecto. Es difícil dar seguimiento a grandes bloques o módulos al leer los detalles de la conversación. Herramientas de administración de proyecto ayudan a tener toda la conversación agrupada a una tarea; pero a veces hay muchos lugares dónde buscar el estatus de las tareas. A veces no queda otra que leer los mensajes del chat del día para saber cómo vamos.<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-eo7r8DoK4Wk/W-5U-a0fp8I/AAAAAAAABfs/DbqMS0VMedgI8_Ntlw33rLXyqPj9r5sEQCLcBGAs/s1600/email.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="520" data-original-width="780" height="424" src="https://1.bp.blogspot.com/-eo7r8DoK4Wk/W-5U-a0fp8I/AAAAAAAABfs/DbqMS0VMedgI8_Ntlw33rLXyqPj9r5sEQCLcBGAs/s640/email.jpg" width="640" /></a></div>
<br />
El correo electrónico me sirve en esos casos porque no es tan instantáneo. Se puede incluir a varias personas en la conversación y no se necesita una respuesta de cada uno al momento. Solo con que respondan cuando tengan algo que decir y en un solo mensaje te den todas las respuestas que necesitas. A veces en los mensajes se pierde la secuencia porque contestan varios al mismo tiempo y dan una respuesta por mensaje y mandan dos o más mensajes para una sola respuesta, mientras otros hacen los mismo y ya se revolvió todo. Por correo recibes una respuesta por cada miembro del equipo e idealmente viene toda la opinión o informe que requieres de esa persona en un párrafo explicado. A veces por la flojera de pensar y dar un reporte se prefiere escribir varios mensajes de una línea y puede ser más complicado darle sentido a la idea del mensaje completo.<br />
<br />
He notado que cada vez es más común que no revisen el correo electrónico, no es raro que tenga que avisar por mensaje que les he enviado un correo electrónico que requiere respuesta. A veces van y lo leen y me contestan por mensaje. Para mi es difícil darle seguimiento a las cosas de ese modo. Porque eso me exige, en cierta manera, estar atento a los mensajes, que pueden ser muchos.<br />
<br />
Usando el correo electrónico puedo programar un tiempo para hacer las preguntas que necesito enviar o escribir los reportes que necesito enviar y si la respuesta es por correo entonces puedo dejar que se acumulen en mi buzón mientras sigo trabajando en otras tareas. Una vez que tenga tiempo puedo ir y procesar mi bandeja de entrada. No puedo hacer lo mismo con los mensajes. Los mensajes distraen más y puede que si me dan los datos que necesito por mensaje, al momento que tengo tiempo de revisarlo ya han enviado muchos mensajes más y es difícil encontrarlo. Por eso prefiero las respuestas a mis correos por correo electrónico, el seguimiento es más fácil.<br />
<br />
¿No les pasa lo mismo?<br />
<br />Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com2tag:blogger.com,1999:blog-23470706.post-59996271534955164922018-10-22T18:25:00.003-07:002018-10-22T18:25:55.849-07:00Micromanagement al RescateHace ya un buen tiempo me tocó trabajar con un equipo de desarrollo que tenía problemas a la hora de dar resultados. Siempre había un pretexto o detalle que se les iba y por alguna u otra cosa no se entregaban las características requeridas en el programa. Este era un equipo que lo administraba el cliente directamente. Nuestra empresa solo "rentaba" a los programadores.<br />
<br />
Algo que intentó el administrador de proyectos para "rescatar" al equipo, fue realizar lo que se conoce como <i>micromanagement</i>. El <i>micromanagement</i> (o microgestión en español) es cuando la persona encargada de administrar, o dirigir a otra, le da instrucciones al detalle de lo que hay que hacer. Esto es algo que por lo general se busca evitar ya qué es cansado para ambas partes.<br />
<br />
Cuando supe que se intentaría "rescatar" al equipo usando <i>micromanagement</i> no me pareció una buena idea. Supuse que eso traería más problemas. Me comentaron que sería una medida temporal en lo que "salíamos del hoyo". Contra mis pronósticos parece que la medida dio algo de resultados. El equipo empezó a entregar tareas y quedaron expuestas las causas de los problemas del equipo, haciendo posible realizar correcciones. Algunas de. estás correcciones no tan agradables; pero fueron necesarias para bien del proyecto.<br />
<br />
Una vez realizadas las correcciones necesarias para que el equipo funcionara mejor, se pudo regresar a un ambiente menos controlado y se pudo seguir avanzando en el proyecto.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-WJiR5ZwlJkw/W8pBsRc58QI/AAAAAAAABfU/vaYSUiTou4Mtgr4EE9S6OfLTaJQx5R9igCLcBGAs/s1600/micromanagement-570x177.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="177" data-original-width="570" src="https://1.bp.blogspot.com/-WJiR5ZwlJkw/W8pBsRc58QI/AAAAAAAABfU/vaYSUiTou4Mtgr4EE9S6OfLTaJQx5R9igCLcBGAs/s1600/micromanagement-570x177.gif" /></a></div>
<br />
Esa no ha sido la única vez que la microgestión nos ha ayudado a sacar adelante un proyecto. En otra ocasión me tocó a mi detener un proyecto y volverlo a empezar desde cero. Lo que hicimos para que el proyecto no se saliera nuevamente de control fue que lo iniciamos programando todos juntos en la misma maquina. Éramos un equipo distribuido por lo que todos nos conchabamos a una junta por GoToMeeting y el "chofer" compartía pantalla y empezaba a programar mientras los demás íbamos viendo. Eramos 4 personas en la llamada. Al principio me parecía un desperdicio de recursos estar los cuatro viendo como definir algunas clases; pero ahora que veo hacia atrás, creo que fue una buena decisión porque eso logro sacar al proyecto adelante.<br />
<br />
Después de un tiempo dejamos de conectarnos para programar y cada quien trabajaba en cierto módulo; pero no permitía que subieran código fuente al repositorio hasta que lo revisara yo mismo. Al principio había varias observaciones en los <i>commits</i> que me solicitaban; poco a poco fueron disminuyendo. Pasado algún tiempo dejé de revisar todo el código fuente y ahora solo nos preocupábamos porque la funcionalidad estuviera ahí y pudimos trabajar sin <i>micromanagement</i>. Se tenía una junta en las mañanas para tener el plan del día y con eso era suficiente.<br />
<br />
El <i>micromanagement</i> es algo que por lo general se ve como malo, yo mismo <a href="http://www.developeando.com/2013/01/como-vas.html" target="_blank">me he quejado de eso en este blog</a>; pero también puede ser una práctica que puede ayudar al equipo a salir adelante en ciertas ocaciones.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com2tag:blogger.com,1999:blog-23470706.post-11961790318759270192018-07-19T17:19:00.000-07:002018-07-19T22:03:06.202-07:00Atención al DetalleHay varias cosas que distinguen a los profesionales de los aficionados, una de esas es la atención al detalle. Cuando estás empezando a programar lo que te puede interesar es crear algo, que funcione y quizás eso evite que te fijes en los detalles que le harán la vida fácil a tus usuarios.<br />
<br />
Un caso común que he visto que se omite es el de permitir al usuario usar solo el teclado para navegar en tu aplicación. Es algo que me pasó en los primeros programas en los que trabajé, sobre todo cuando el proyecto no era web, cuando era un ejecutable y en esos se debe especificar el "<i>tab order</i>" explícitamente. Y a veces por hacer que el programa funcionara y poder decir que ya estaba listo olvidaba verificar el orden de todos los <i>tabs</i> y definir <i>labels</i> que permitieran navegar fácilmente sin necesidad del ratón.<br />
<br />
La atención no es solo al momento de programar, también es importante al realizar todas las actividades de tu trabajo. La comunicación es una parte importante para el éxito de un equipo de programación. Debes poner atención al detalle de como te expresas, debes ser capaz de dar una explicación tanto técnica, en caso de ser necesaria, como una explicación que personas no técnicas puedan entender el problema y la solución que se está planteando. Debes evitar que los clientes o jefes se sientan ignorados. Contestar rápidamente a peticiones, no necesariamente con la solución, quizás solo informando que vas a investigar, es una atención a la otra persona y ayuda a la comunicación. Nadie está tan ocupado como para no poder contestar que vas a revisar lo que te piden. Y ya que lo revises, avisa. Evita que te tengan que preguntar nuevamente por cosas que ya te pidieron.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/--xhVbVCnqrI/W0_Yj3BuFWI/AAAAAAAABc8/Yw9ay9sPh2U-TVmwg4pFul6tL1AG0dbewCLcBGAs/s1600/Captura%2Bde%2Bpantalla%2B2018-07-18%2Ba%2Bla%2528s%2529%2B17.15.20.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1282" data-original-width="826" height="640" src="https://3.bp.blogspot.com/--xhVbVCnqrI/W0_Yj3BuFWI/AAAAAAAABc8/Yw9ay9sPh2U-TVmwg4pFul6tL1AG0dbewCLcBGAs/s640/Captura%2Bde%2Bpantalla%2B2018-07-18%2Ba%2Bla%2528s%2529%2B17.15.20.png" width="412" /></a></div>
De la misma forma cuando se te pide que realices ciertas actividades como documentar es importante que pienses en la persona que va a consumir esos documentos. Dar toda la información posible para que sea de utilidad lo que escribes y que la otra persona no tenga que buscarte para pedir que aclares qué quisiste decir. A veces no te salvas de eso por más explicado que esté; pero por lo menos ya lo aclaraste para ti cuando lo escribiste.<br />
<br />
Básicamente estoy hablando de entregar las cosas completas y bien hechas, sin detalles pendientes. Esa es la diferencia entre una persona profesional en la que se puede confiar y una persona aficionada a la que hay que revisarle todo lo que hace porque no tienes la garantía de que: lo que hizo, lo hizo bien.<br />
<br />
La experiencia ayuda a poner más atención, cuando eres principiante es fácil pasar por alto los detalles; pero además de la experiencia, la mentalidad para hacer las cosas bien es muy importante. Ten la intensión de hacer las cosas bien terminadas, sin detalles pendientes y así lograras ser una persona profesional y confiable.<br />
<br />Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com2tag:blogger.com,1999:blog-23470706.post-52762993328290293792018-07-12T15:50:00.000-07:002018-07-12T17:41:38.142-07:00Programando cerca de los cuarentaDespués de los 35 casi no se ven programadores...<br />
<br />
He trabajando muchos años para una empresa de desarrollo en Tijuana, cuando entré era el más joven. Al pasar los años han llegado nuevos, se han ido otros y ahora soy de los mayores. Cuando hay una reunión la mayoría son más jóvenes que yo. Lo noto también en los grupos de usuarios o comunidades de programadores.<br />
<br />
He notado que varias ofertas de empleo <a href="http://www.developeando.com/2017/10/limite-de-edad-al-busar-programadora.html" target="_blank">solicitan programadores jóvenes</a>. No todas tienen limite de edad; pero si vemos a los aspirantes al puesto o incluso si nos damos una vuelta a la empresa es fácil encontrar que la mayoría de los programadores son veinteañeros.<br />
<br />
A veces bromeo, cuando veo las ofertas de empleo que tienen un limite de edad, diciendo que después de cierta edad se nos olvida programar y por eso ya no se ven programadores mayores. Sé que no es que se nos olvide; pero entonces... ¿Por qué a cierta edad ya no se ven tantos programadores?<br />
<br />
Creo que tiene que ver con hecho de que cualquier empleado ha sido contratado para aportar a la empresa. Aunque no estés en una posición donde te toque vender directamente un producto, la empresa te contrata para que aportes y ayudes hacer crecer la empresa. De lo que se trata es de dar algo de valor al negocio.<br />
<br />
Al principio le puedes aportar valor a la empresa programado. Después, cuando tienes experiencia programando, quizás le aportas más valor a la empresa si le ayudas a coordinar y dirigir a los programadores más jóvenes. O quizás sea importante que ayudes a la empresa a hablar con los clientes y "traducir" lo que el equipo de desarrollo quiere comentarles. Al tener una mayor madurez es más fácil entender ciertas cuestiones del negocio y puedes ayudar a interpretar los requerimientos del cliente y convertirlos en acciones concretas que el programador joven pueda realizar.<br />
<br />
Leo seguido en blogs que: no nos contratan para escribir código, que nos contratan para dar soluciones. Es cierto, <a href="http://www.developeando.com/2016/06/el-codigo-no-es-lo-mas-importante.html" target="_blank">no es el código que escribes lo que quiere tu empleador o cliente</a>, es lo que se puede hacer con el código lo que interesa. De igual forma, al tener cierta experiencia esa experiencia puede aprovecharse para ayudar a dar mejores soluciones a la empresa, aunque eso implique que no te quede mucho tiempo para programar a ti.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-oiyOfe3oGfw/W0fT_kML9HI/AAAAAAAABbc/s49jZPUPDDksWwjjEkF5xq0YZsNFnn7SgCLcBGAs/s1600/managers.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="480" data-original-width="381" src="https://2.bp.blogspot.com/-oiyOfe3oGfw/W0fT_kML9HI/AAAAAAAABbc/s49jZPUPDDksWwjjEkF5xq0YZsNFnn7SgCLcBGAs/s1600/managers.png" /></a></div>
<br />
<br />
Es importante estar de cerca al código, para no ser irrelevantes en los aspectos técnicos; pero como programadores llegando a los cuarenta no debemos tener miedo de dejar de programar para aportar a la empresa de otra manera. Quizás ahora en lugar de programar código nos toque programar reuniones...Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com1tag:blogger.com,1999:blog-23470706.post-12087577610524633742018-06-06T18:03:00.000-07:002018-06-08T08:28:49.058-07:00El Efecto Cafetería Cuando recién llego a una nueva oficina o uso un nuevo escritorio, me siento motivado para terminar todo el trabajo que tengo pendiente. El cambio me ayuda a quitarme el tedio de estar siempre en el mismo lugar, frente a la computadora. Es algo que había notado cuando trabajaba en casa, trataba de mover el escritorio de vez en cuando. Es una de las razones por las que me gusta la idea de <a href="http://www.developeando.com/2012/01/programando-en-laptop.html" target="_blank">trabajar en laptop</a>, porque es más fácil moverte.<br />
<br />
Ahora que t<a href="http://www.developeando.com/2018/01/emprendiendo.html" target="_blank">rabajo en una oficina</a>, lo que hemos estado haciendo es mover los escritorios cada cierto tiempo. No hay una fecha, simplemente sentimos que ya es tiempo de un cambio. Eso me ayuda a sentir renovado el lugar de trabajo, aunque seguimos dentro del mismo local.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-xg5A9Miq58M/WxhBkVsWRHI/AAAAAAAABaQ/iUNisqg7gcw4ezfUc5UIhbOhkbULi1FAACLcBGAs/s1600/java-cafe.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="500" data-original-width="500" src="https://1.bp.blogspot.com/-xg5A9Miq58M/WxhBkVsWRHI/AAAAAAAABaQ/iUNisqg7gcw4ezfUc5UIhbOhkbULi1FAACLcBGAs/s1600/java-cafe.png" /></a></div>
Como ya no trabajo en casa, no tengo un escritorio designado para trabajar cuando no voy a la oficina. He notado que en esas ocasiones me gusta ir a una cafetería y trabajar desde ahí. Eso me ayuda a concentrarme, si me quedo en la casa tiendo a distraerme. Esto me sorprende porque pasé muchos años <a href="http://www.developeando.com/2013/08/trabajar-desde-casa-interrupciones.html" target="_blank">trabajando desde mi casa</a> casi sin <a href="http://www.developeando.com/2015/08/desventajas-de-trabajar-desde-casa.html" target="_blank">problemas</a>, ahora que estoy en una oficina no logro concentrarme para trabajar desde casa como antes. Parece que mi cerebro ya se acostumbró a que la casa no es un lugar de trabajo.<br />
<br />
Hace poco leí un artículo en el <a href="https://blog.trello.com/" target="_blank">blog de Trello</a> donde escribían sobre el <a href="https://blog.trello.com/coffee-shop-effect-boosts-productivity" target="_blank">"Efecto Cafetería"</a>. Me hizo darme cuenta que esas son las razones por las que estamos cambiando constantemente como se ve nuestra oficina y la razón por la que siento que soy más productivo cuando salgo de casa a trabajar en una cafetería los fines de semana.<br />
<br />
En el artículo de Trello se mencionan razones por las que al moverte a trabajar a una cafetería de vez en cuando te ayuda a ser productivo:<br />
<ol>
<li>Café</li>
<li>A nuestro cerebro le gusta la novedad</li>
<li>Si estamos siempre donde mismo, podemos caer en hábitos no productivos </li>
<li>La intención de trabajar</li>
</ol>
<div>
Con el cuarto punto "La intención de trabajar" me identifico cuando en un fin de semana salgo a Starbucks a trabajar. Porque siento que sí ya dejé la comodidad de la casa y gasté en moverme y comprar un café entonces debo hacer que ese gasto valga la pena produciendo resultados. Si me quedo en la casa, aunque tengo la intención de trabajar, es fácil encontrar pretextos para postergar los pendientes. El ir físicamente a otro lugar con la intención de trabajar siento que me hace productivo.<br />
<br /></div>
Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-14622747385837702542018-05-23T21:16:00.000-07:002018-05-24T09:53:42.295-07:00Abstracciones prematurasCuando empecé a programar, cuando aprendía un nuevo patrón de diseño no tardaba mucho en encontrar en donde aplicarlo. Mis proyectos rápidamente tenían varias clases que representaban cada abstracción del patrón que quería aplicar. Lo mismo pasaba con arquitecturas y formas de organizar mis proyectos. Hubo un tiempo donde creaba tres capas al iniciar mi proyecto (presentación, reglas de negocio y acceso a datos), hubo otra época en que creaba una capa de servicios al iniciar el proyecto y otra de repositorios; en otro tiempo creaba interfaces para casi todas las clases con la idea de poder cambiar las implementaciones sin afectar el resto del proyecto.<br />
<br />
Con el tiempo fui descubriendo que el tener muchas abstracciones tiene un precio. Aunque siempre digo que las clases son gratis y no debes tener miedo de crear una más. No pienso lo mismo cuando se trata de agregar una nueva capa de abstracción. Esas sí me van a costar si me lleno de clases o interfaces que no hacen otra cosa más que abstraer la implementación de algo que puede ser simplemente una clase concreta.<br />
<br />
Ahora mi regla es: <b>si solo hay una implementación entonces no se necesita una interfaz</b>. Las implementaciones que solo se usan para los tests no cuentan, me refiero a implementaciones de código real. Si después descubrimos que habrá otra implementación, es entonces cuando se hace un <i>refactoring</i> del código para introducir la interfaz; pero no antes. Debemos resistir <a href="http://www.developeando.com/2017/06/la-tentacion-de-la-capitis.html" target="_blank">la tentación de la capitis</a> y solo agregar abstracciones cuando sea necesario. Si encontramos una abstracción con una sola implementación concreta entonces se trata de una abstracción prematura.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://imgs.xkcd.com/comics/the_general_problem.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="230" data-original-width="550" src="https://imgs.xkcd.com/comics/the_general_problem.png" /></a></div>
<br />
<br />
Por ejemplo:<br />
<br />
Supongamos que tenemos una lista de clientes y nos piden que la exportemos a un archivo CSV. Es posible que hagamos una clase <i>CustomerExporter</i> con el método <i>Export;</i> de momento con eso es suficiente.<br />
<br />
Sabemos que quizás en un futuro nos pidan que también se pueda exportar a otro formato; pero de momento no es parte del alcance del proyecto y quizás nunca sea necesario otro formato. Si introducimos una interfaz ICustomerExporter y la única implementación CustomerCsvExporter tendremos complejidad innecesaria y una abstracción prematura.<br />
<br />
Es hasta que tengamos el requerimiento o necesidad de poder exportar clientes en otro formato que debemos realizar el <i>refactoring</i> e introducir la abstracción para las <b>dos o más implementaciones.</b><br />
<br />
<br />Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-67939815474392955232018-01-05T17:34:00.000-08:002018-01-05T17:34:32.102-08:00EmprendiendoEn julio 2017 dejé de trabajar desde casa y empecé a ir a mi oficina. Antes de ese mes había estado trabajando desde casa por más de diez años y era algo que me gustaba, hasta presumía el no tener que salir de mi casa todos los días. Tomar la decisión de empezar a ir a una oficina (sin que nadie me lo estuviera pidiendo) no fue tan fácil.<br />
<br />
Tenía tiempo que, además de mi trabajo de tiempo completo, tomaba proyectos de desarrollo por mi cuenta, como freelance. Fue en febrero que tuve un "<i>padawan</i>" y entre los dos trabajamos en los proyectos para los que me iban contratando. Cada uno de nosotros, trabajaba desde su casa, usábamos herramientas como Skype y GoToMeeting para estar en constante comunicación y nos reuníamos cada semana en un café a platicar del estatus de los proyectos. Hacíamos una pequeña retrospectiva de la semana.<br />
<br />
Después de meses trabajando así decidí empezar a tomar más proyectos por mi cuenta e iniciar mi propia empresa. Ya no como freelancer sino como una empresa de desarrollo. No íbamos a poder dos personas terminar todos los proyectos, por lo que sería necesario que el equipo creciera. Teníamos en mente a unos muchachos que estaban por egresar de la universidad. Los cuales necesitarían apoyo para iniciar su camino como profesionales. Esta fue una de las razones que nos convencimos de que era necesaria tener nuestra propia oficina.<br />
<br />
Para mi, la decisión se miraba venir desde que quise tomar más trabajo por mi cuenta, sabía que eso implicaba salir de mi zona de confort literalmente, tendría que salir de mi casa, donde estaba a gusto todo el día, a tener que salir a trabajar a una oficina todos los días, por más horas de las de un turno.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-BS_YOV3exbA/Wkl-Vnp9KPI/AAAAAAAABVw/yCzhsl5Sv7AqDRZNk_BIwXx4CvRgewwRgCLcBGAs/s1600/la-cara-quepones-cuando-ves-que-todos-reciben-aguinaldo-menos-tu-porjugarle-al-emprendedor-s1aGa.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="857" data-original-width="640" height="640" src="https://3.bp.blogspot.com/-BS_YOV3exbA/Wkl-Vnp9KPI/AAAAAAAABVw/yCzhsl5Sv7AqDRZNk_BIwXx4CvRgewwRgCLcBGAs/s640/la-cara-quepones-cuando-ves-que-todos-reciben-aguinaldo-menos-tu-porjugarle-al-emprendedor-s1aGa.jpg" width="475" /></a></div>
<br />
<br />
Han sido meses de mucho aprendizaje. Hemos tenido varios cambios en la empresa: pasé de ser una persona física a ser una persona moral, ahora tenemos una nómina que pagar, empleados que llegan y otros que se van. He aprendido que el negocio del software no es lo mismo que el desarrollo de software y que si quieres vivir programando todo el día entonces no pongas una empresa por tu cuenta. La mayoría del tiempo se va en cosas del negocio y no necesariamente en lo que te gusta hacer, es por eso se necesita tener a un equipo.<br />
<br />
Veo con optimismo el siguiente año de <a href="https://evolucionapps.com/" target="_blank">Evolución Apps</a>.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com12tag:blogger.com,1999:blog-23470706.post-72314826825104813222017-12-26T15:29:00.002-08:002017-12-26T15:29:11.529-08:00Esa es una buena pregunta..."Esa es una buena pregunta...". Esa frase la he escuchado varias veces, sobre todo en presentaciones cuando alguien de los asistentes pegunta y el presentador no sabe la respuesta. ¿Es eso lo que la hace una buena pregunta, que el presentador no conozca la respuesta? No creo, quizás si fuera importante la pregunta entonces la persona que presenta ya conociera la respuesta.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-4pgfI4LqcRw/Wj6rgqc7npI/AAAAAAAABTk/VWv0CA4QARkqxGQbzpBHlOmU0R9wjJuewCLcBGAs/s1600/question.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="377" data-original-width="498" height="302" src="https://1.bp.blogspot.com/-4pgfI4LqcRw/Wj6rgqc7npI/AAAAAAAABTk/VWv0CA4QARkqxGQbzpBHlOmU0R9wjJuewCLcBGAs/s400/question.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Las buenas preguntas nos ayudan a comprender</td></tr>
</tbody></table>
El desconocer la respuesta no hace, necesariamente, a una pregunta buena. Para mi una buena pregunta es la que ayuda a entender o explicar mejor algún tema. Si la pregunta no aporta información relevante al tema entonces no es buena, independientemente de que se conozca su respuesta.<br />
<br />
A veces no tenemos respuesta para las buenas preguntas y nos hacen darnos cuenta de lo que no sabemos del tema. Saber lo que no sabemos es importante y por eso muchas de las preguntas para las que no tenemos una respuesta son buenas; pero no son buenas porque no tengamos la respuesta. Sino porque nos hace conocer más del tema, que hay otras cosas por descubrir.<br />
<br />
Dejemos de usar la frase: "Esa es una buena pregunta..." si es solo porque no conocemos la respuesta porque eso promueve preguntas para escenarios muy específicos que no aportan mucho al tema en general. Puede haber una pregunta donde la respuesta parece obvia y aclara algo que quizás puede ser ambiguo, esa puede ser una buena pregunta; pero si andamos buscando preguntas que nadie sabría la respuesta, solo porque esas son las "buenas" podemos perdernos de comprender mejor el tema.<br />
<br />
Las buenas preguntas son las que nos ayudan a comprender.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-34289184860659866902017-12-19T15:22:00.000-08:002017-12-21T11:53:20.272-08:00Actitud en Proyectos LegacyLos proyectos legacy... esos proyectos que por lo general fueron iniciados por alguien más. Aunque a veces fueron iniciados por nosotros mismos. Por lo general son viejos y ya no programamos así o en ese lenguaje. Alguien tiene que darles mantenimiento, corregirlos...<br />
<br />
Cuando nos toca empezar a trabajar en un proyecto de esos a veces puede ser frustrante el tratar de moverle, agregarle funcionalidad usando herramientas "anticuadas" o usando convenciones de nombrado diferentes a lo que quisiéramos. Siempre está ese pensamiento, indecisión de: "<a href="http://www.developeando.com/2015/08/y-si-lo-reescribimos.html" target="_blank">Y si lo reescribimos</a>" o "<a href="http://www.developeando.com/2012/01/seguir-usando-delphi.html" target="_blank">seguiremos usando lo mismo</a>". Es pesado trabajar en proyectos así, sobre todo si fue hecho de una manera poco organizada o si cuenta con mucha deuda técnica. Es fácil caer en quejas y empezar a verlo todo mal.<br />
<br />
La experiencia de haber visto otros proyectos similares, de conocer diferentes arquitecturas, haber leído artículos sobre cosas que la gente intenta te ayuda a darte una idea de que estaban pensando los programadores anteriores y conocer <a href="http://www.developeando.com/2017/06/la-tentacion-de-la-capitis.html" target="_blank">por qué agregaron esa interfaz que a lo mejor no tiene sentido si solo tiene una implementación</a>. La experiencia también puede hacernos arrogantes y ver con mayor desprecio ese proyecto que usa otras practicas a las que recomendarías o ya usamos y aprendimos que no son lo mejor para ese tipo de proyecto.<br />
<br />
Si no tienes experiencias puede ser también frustrante porque no es algo que tú conoces y por lo tanto no es algo que recomendarías. A veces cuando uno empieza quiere usar lo que conoce, la tecnología con la que jugó en proyectos de prueba, que generalmente es algo nuevo. El querer usar lo último y que nos toque trabajar en un proyecto con tecnología vieja puede frustrarnos y sentir que estamos estancados. Sin aprender cosas que nos van a ayudar en el futuro.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-bfVJA3yrLsw/WjmcwteCYOI/AAAAAAAABTI/-EhWFL90Hvwr622oK0JYKfZ5LchpFD8zQCEwYBhgL/s1600/legacy.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="674" data-original-width="1017" height="424" src="https://4.bp.blogspot.com/-bfVJA3yrLsw/WjmcwteCYOI/AAAAAAAABTI/-EhWFL90Hvwr622oK0JYKfZ5LchpFD8zQCEwYBhgL/s640/legacy.png" width="640" /></a></div>
<br />
<br />
Cuando tienes que trabajar en proyectos <i>legacy</i> que inició alguien más, la buena actitud con la que revisas el problema es parte de las habilidades necesarias para mejorarlo. Debemos pensar que el equipo anterior tomó decisiones con la mejor intención, con la información que tenían en ese momento.<br />
<b><br /></b>
Es fácil juzgar una vez que ves que el resultado no fue el esperado y tienes que corregirlo. Pero entrar al problema con quejas en lugar de entender el porqué de la situación, es más desgastante y puede ser más costoso porque puede haber cosas rescatables en el proyecto que no veras, además corres el riesgo de cometer los mismos errores por no entenderlos. <b></b><br />
<b></b><br />
Evita esa frustración, piensa que se hizo lo que se creyó mejor y éntrale al proyecto con una buena actitud, buscando dar soluciones en lugar de quejas. El primer paso es darte cuenta que está en ti cambiar las cosas.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-74198613131970526382017-10-23T12:26:00.002-07:002017-10-23T12:59:06.619-07:00Limite de edad al buscar programador(a)He notado que varias <a href="http://www.developeando.com/2015/06/banderas-rojas-en-las-ofertas-de-empleo.html" target="_blank">ofertas de empleo para programadores</a> tienen un limite de edad, dicen algo como: <i>"se solicita programador (o programadora) de 20 a 34 años"</i> como si después de cierta edad se nos empezara a olvidar como programar. Por lo que he visto, entre más mayor sea el programador más experiencia de vida tiene y hay que explicarle menos el porqué de las cosas. Programar no es una actividad física que requiera de juventud.<br />
<br />
La edad no define las ganas de trabajar. He conocido tanto a personas que siempre quieren echarle ganas al trabajo, como personas que siempre tienen flojera y nomas quieren estar jugando, de todas las edades. Si esto es cierto entonces ¿Por qué habrá esta restricción de edad en las ofertas de empleo?<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-S1AtF7GLqMk/We47aFZnkXI/AAAAAAAABQQ/ZgGBtLEaXiMUGAjhykTJEPdLMuv2gYeWQCLcBGAs/s1600/Gandalf-used-Macbook.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="677" data-original-width="680" height="398" src="https://3.bp.blogspot.com/-S1AtF7GLqMk/We47aFZnkXI/AAAAAAAABQQ/ZgGBtLEaXiMUGAjhykTJEPdLMuv2gYeWQCLcBGAs/s400/Gandalf-used-Macbook.jpg" width="400" /></a></div>
<br />
He pensando que lo hacen para pagar menos, entre mayor es la persona generalmente tiene más compromisos y por lo tanto más gastos. Necesita más dinero y tiempo para sus compromisos fuera del trabajo. Un joven quizás no necesite tanto dinero y pueda quedarse hasta tarde porque le gusta lo que hace.<br />
<br />
Hace tiempo en <a href="http://www.dev3cast.com/2015/06/11/esas-banderas-rojas-en-ofertas-de-trabajo/" target="_blank">un episodio del dev3cast</a>, <a href="https://gabo.wordpress.com/" target="_blank">Gabriel</a> me preguntó que si yo contrataría a alguien mayor. Me tomó de sorpresa la pregunta y titubeé al contestar. Me sentí mal por eso; pero así de pronto pensé que prefería contratar a alguien más joven que yo. La razón por la que no pensaba en contratar a alguien mayor es porque en ese tiempo hablamos de contratarlo no como empleado de la empresa donde trabajo, sino como ayudante para proyectos que hago por mi cuenta. Esos proyectos generalmente los hacia para clientes que me conocen y les "gusta" la forma en que trabajo. Pensaba que con un joven sería más fácil que hiciera las cosas a mi modo, sin tener que darle explicaciones del porqué.<br />
<br />
Ahora que he iniciado una <a href="https://www.evolucionapps.com/" target="_blank">empresa de desarrollo de software</a> por mi cuenta, me doy cuenta que esto no es necesariamente buena idea... porque aunque mis clientes lleguen a mí debido a que me conocen como programador y piense (yo) que quieren el código como si fuera hecho por mi mismo (en realidad no, lo que quieren es una solución, <a href="http://www.developeando.com/2016/06/el-codigo-no-es-lo-mas-importante.html" target="_blank">el código no importa</a>), el trabajo lo puede hacer cualquier persona sin importar la edad que tenga. Incluso, ahora que he tratado con varios jóvenes, el tener cierta edad puede ser una ventaja que no tienen los jóvenes, por la simple experiencia que te da la vida. Explicar los requerimientos y entender las prioridades para una persona mayor puede ser más fácil.<br />
<br />
Al final lo importante es la actitud y la responsabilidad de cada persona, como empresa buscamos gente <a href="http://www.developeando.com/2017/01/si-no-sabes-no-mientas.html" target="_blank">que saque el trabajo sin excusas</a>, <a href="http://www.developeando.com/2017/01/aprender-o-morir.html" target="_blank">sin tener miedo a aprender,</a> <b>la edad no importa</b>.Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-32709639005760738402017-06-28T11:52:00.000-07:002017-06-28T11:52:32.054-07:00La tentación de la capitisCada que inicio un nuevo proyecto lo veo como una oportunidad para organizar diferente la estructura, la arquitectura, a fin de mejorar la forma en que se desarrolla el proyecto.<br />
<br />
En esta etapa es fácil caer en la tentación de crear varias capas (capitis), con esto me refiero a la intención de separar toda la lógica o "responsabilidades" en proyectos separados. Intentar que el modelo del dominio del problema quede "puro", es decir, limpio de dependencias externas. Sin "manchas" con detalles de frameworks. Que alguien al abrir el proyecto vea nombres de carpetas que tengan que ver con el negocio, y no con detalles "sucios" como controllers, views, etc.<br />
<br />
Es divertido definir la capa de negocio (o dominio) y estar programando abstracción, tras abstracción. Para después crear proyectos de implementaciones concretas usando cierta tecnología, librería o framework. Como no queremos tener implementaciones concretas, entonces definimos interfaces. Las cuales serán consumidas por la capa de presentación, claro que sin conocer las implementaciones concretas. Así será "fácil" cambiar (pensamos) de implementación sin afectar la aplicación en un futuro.<br />
<br />
Por poner un ejemplo (cuando se trabaja con .NET) se puede llegar a tener un proyecto "Negocio" que solo tiene clases que contienen el "core" del problema e interfaces para todo lo demás que necesita contener dependencias de terceros. Después se agrega un proyecto para cada tecnología que necesitas para realmente hacer las cosas, como "Negocio.EntityFramework" que es una implementación de nuestro proyecto usando EntityFramework para guardar los datos. Y nos sentimos bien porque en un futuro "podríamos" tener un proyecto "Negocio.FileSystem" que guarda los datos en disco directamente o una implementación que los guarde en MongoDB "Negocio.MongoDb". Esto por poner ejemplos. También podemos abstraer el Web como una presentación más y llegar a tener más interfaces e implementaciones concretas que podemos cambiar. Hay veces que se agrega una capa de "servicios" que lo único que haces es llamar a la capa de acceso a datos, incluso a veces es peor y llama a una capa de repositorios que entonces esa sí llama a la base da datos.<br />
<br />
Lo que termina pasando, la mayoría de las veces que he visto esa arquitectura, es que solo se tiene una implementación para cada Interfaz. Es decir tantas abstracciones para nada. Solo es más código para ocultar la implementación concreta, al final esa abstracción <a href="https://en.wikipedia.org/wiki/Leaky_abstraction" target="_blank">contendrá fugas</a> para así poder acceder a la funcionalidad que tiene la implementación concreta. A veces se usa el pretexto de que las pruebas serán más fáciles; pero la verdad es que en muchos de esos proyectos ni si quiera hay pruebas unitarias. <br />
<br />
Darle mantenimiento a un proyecto así es más complejo de lo necesario, por varias razones:<br />
<ol>
<li>Es más difícil encontrar la implementación concreta de un método porque la mayoría del código tiene llamadas a interfaces, debes buscar en otro proyecto la implementación.</li>
<li>La configuración necesaria es mayor, se necesita configurar todos los tipos en un contenedor de dependencias o usar el patrón de service locator (que tiene sus propias desventajas) para instanciar las clases concretas que implementan las interfaces del core.</li>
<li>La cantidad de código escrito es mayor (sin ningún beneficio, si solo tienes una implementación), por lo tanto entenderlo es más complicado.</li>
<li>Como la cantidad de código es mayor, hay mayor posibilidad de bugs. </li>
<li>Un cambio trivial puede significar realizar cambios a todas las capas, debido a las abstracciones con fugas.</li>
</ol>
<div>
Aún conociendo esas desventajas y haber tenido que mantener proyectos de este tipo, donde incluso he visto que se agregaran abstracciones para obtener la fecha y hora del sistema. Aun así cuándo estoy por iniciar un proyecto nuevo, tengo esa sensación de dejar "puro" el dominio y las implementaciones concretas declararlas en otro proyecto. Aún sabiendo que no vale la pena, como que se antoja dejarme llevar en ese viaje creando abstracción sobre abstracción.</div>
<div>
<br /></div>
<div>
A veces siento que he logrado separarlo en capas, con moderación, limitando mis abstracciones. Es decir sin llegar al extremo de tener puras interfaces en el dominio. Pero casi siempre tengo que recordar que "No voy a necesitar otra implementación", pensar en <a href="https://es.wikipedia.org/wiki/YAGNI" target="_blank">YAGNI</a> y el <a href="https://es.wikipedia.org/wiki/Principio_KISS" target="_blank">principio KISS</a>. Recordar que <a href="http://www.developeando.com/2011/06/adiccion-la-refactorizacion.html" target="_blank">siempre puedo refactorizar</a> si se llega a ocupar. el refactoring es fácil porque el código es poco. </div>
<div>
<br /></div>
<div>
Siempre es más fácil agregar una capa después, que darte cuenta que no la ocupabas y tratar de quitarla. <a href="https://ayende.com/blog/posts/series/153889/limit-your-abstractions" target="_blank">Limitemos nuestras abstracciones</a>.</div>
Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-80562116141777692872017-06-02T18:59:00.004-07:002017-06-05T13:30:16.916-07:00QA no debe encontrar errores.<div class="separator" style="clear: both; text-align: center;">
<img border="0" data-original-height="306" data-original-width="460" src="https://3.bp.blogspot.com/-gPaco4M3KSM/WTITgETRYQI/AAAAAAAABLE/Zid8gGeYWCYG6wnKpCsyGFzaeeuwDDg7gCLcB/s1600/b872a15215a69ffc3757286f0bccbcca_software-testing-probs-qa-testing-meme_460-306.jpg" /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
En equipos de desarrollo, además de las personas que programan, también hay personas que realizan las pruebas a los <i>releases</i> o entregas que realizan los programadores. Es el equipo de QA. Este equipo (como su nombre lo dice <i>"Quality Assurance") </i>se asegura de que el producto entregado por el equipo de desarrollo esté libre de errores o <i>bugs</i>.<br />
<br />
Un "malentendido" que a veces veo en algunos equipos es: que creemos que las personas de QA están para probar nuestro código por nosotros. Que están ahí para revisar si el cambio que hicimos, lo hicimos bien. A veces nos da flojera y sentimos que no ocupamos correr el programa y revisar si lo que hicimos está bien. Solo cambiamos el código y lo enviamos a QA para que lo prueben ellos.<br />
<br />
Es un "malentendido" porque QA no está para eso, QA no está para que nosotros los programadores hagamos cosas bien. Eso lo tenemos que hacer habiendo equipo de QA o no. Es responsabilidad de cada persona revisar que el trabajo que hizo se haya hecho bien, de manera profesional. Sin embargo, me ha tocado ver que llegan a ser ridículos algunos de los bugs que encuentra el equipo de QA. Cosas que si nosotros como programadores le hubiera dado una revisada lo hubiéramos visto. Nos debería de dar vergüenza que QA encuentre errores, no debería ser común. Evitemos esa actitud de que no nos importa cuantos bugs se encuentren.<br />
<br />
Como <b>programadores</b>, debemos tener claro que la <b>responsabilidad</b> de que nuestro<b> trabajo esté bien hecho</b> no es responsabilidad del equipo de QA, es nuestra. El equipo de QA está ahí solo como una <i><a href="https://en.wikipedia.org/wiki/Safety_net" target="_blank">Safety-Net</a></i>, una red de protección por si acaso fallamos, no es para que seamos flojos y entreguemos trabajo mediocre.<br />
<br />
Robert C. Martin (aka Uncle Bob) habla un poco de eso en su <a href="https://www.youtube.com/watch?v=zwtg7lIMUaQ" target="_blank">presentación sobre profesionalismo</a>. Les recomiendo que (si no la han visto) la miren.<br />
<b><br /></b>
Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com1tag:blogger.com,1999:blog-23470706.post-590094714847362462017-04-05T15:22:00.000-07:002018-04-06T12:23:59.811-07:00Consultas y comandosLa mayoría de las aplicaciones en las que trabajo siguen un patrón. Son aplicaciones web que tienen consultas y comandos, ya sea acciones con los métodos HTTP GET o POST. Viene siendo el viejo y conocido patrón CQRS. No inicio directamente con el patrón en mente; pero cuando el controlador empieza a tener mucho código en una acción, ahí es donde suena como buena idea introducir un comando o un consulta.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-rYhqB4Vh39c/WNlzrW2rfUI/AAAAAAAABJA/LwmHBpsd89UqMnjs1fbFmX38W1I_1zUDACLcB/s1600/cqrs.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://4.bp.blogspot.com/-rYhqB4Vh39c/WNlzrW2rfUI/AAAAAAAABJA/LwmHBpsd89UqMnjs1fbFmX38W1I_1zUDACLcB/s1600/cqrs.png" /></a></div>
<br />
<br />
Imagina que estás desarrollando una aplicación para capturar ordenes de trabajo, la aplicación es solo un ejemplo por lo que las reglas serán básicas. Los requerimientos pueden ser los siguientes:<br />
<ol>
<li>Capturar orden de trabajo</li>
<li>Consultar orden de trabajo</li>
<li>Cambiar el estatus de la orden</li>
<li>Marcar como pagada la orden</li>
<li>Consultar ordenes de trabajo pendientes</li>
</ol>
<div>
Puedes ver que la mayoría son consultas o comandos; pero no inicies el desarrollo de la aplicación usando el patron por todos lados, deja que sea el código el que te diga cuando se necesita introducir una nueva abstracción. Al principio agregarías un OrdersController que use algo como EntityFramework con acciones para cada uno de los requerimientos. Y veras si el código se ve fácil de seguir. </div>
<div>
<br /></div>
<div>
Probablemente te pedirán que al momento de capturar una orden no solo se guarde en la db, sino que también hay que enviar correos, agregar un registro en algún log, realizar ciertas validaciones, etcetera. Si metes todo ese código en el action del controller será difícil seguir el código. Ahí es donde abstraer la creación de la orden en un comando tiene sentido. Lo que puedes hacer es agregar una clase "<i>CreateOrderCommand</i>" que seguramente tendría un método <i>Execute</i> que recibe como parámetro un objeto del tipo <i>CreateOrderModel</i> con toda la información necesaria para crear una orden. Este método puede regresar un objeto del tipo <i>CommandResult</i> que es un objeto con una lista de errores y un objeto con el resultado del comando (en este caso, puede ser una nueva orden). De este modo es fácil ver y modificar todo lo que se necesita para crear una orden en un solo lugar, sin tener que ver detalles de HTTP o del framework MVC. Es sencillo ver qué es lo que necesita el comando para funcionar correctamente.</div>
<div>
<br /></div>
<div>
Lo mismo puede pasar para las consultas, si la consulta es compleja será buena idea encapsularla dentro de un objeto Query que tenga propiedades con los posibles parámetros para la consulta y un método <i>Execute o Find</i> que regrese el resultado de la consulta.</div>
<div>
<br /></div>
<div>
Seguir este patrón también me ha servido cuando no conozco o no tengo control sobre la base de datos del sistema. Puedo ir armando los comandos y consultas que regresan valores fijos de prueba y construir la aplicación aunque aún no tenga acceso a la DB o aun no sepa de donde obtener los datos. Una vez que sé de donde consultar o qué actualizar puedo simplemente cambiar la clase consulta y comando indicado.</div>
<div>
<br /></div>
<div>
Seguir este patron cumple mejor con el principio de responsabilidad única, en lugar de tener una clase gigante "Repository" que hace todas la consultas y todos los comandos, tengo una clase comando o consulta para cada característica de la aplicación.</div>
<div>
<br /></div>
Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com2tag:blogger.com,1999:blog-23470706.post-71033245811493281542017-03-03T18:52:00.003-08:002017-03-06T15:49:15.089-08:00Código hediondo<div style="text-align: left;">
Hay ocasiones en que el código huele mal, es a lo que se le llama <i><a href="https://www.martinfowler.com/bliki/CodeSmell.html" target="_blank">code smell</a></i>. El termino que encontré en español es <a href="https://es.wikipedia.org/wiki/Hediondez_del_c%C3%B3digo" target="_blank">"código hediondo"</a>. No es código que tenga un error obvio, el código que huele mal no necesariamente está mal; pero debes darle una revisada y quizás reescribirlo porque generalmente cuando hay mal olor significa que algo se está "echando a perder".</div>
<br />
<div style="text-align: left;">
Cuando veas código que huele mal... sí, el olor del código se ve, incluso se puede detectar mientras se <a href="http://wiki.c2.com/?ListenToTheCode" target="_blank">escucha al código</a>... bueno, decía que sí ves código que huele mal, cámbialo en el momento, no lo dejes para después porque si trabajas mucho tiempo con código que huele mal, puedes acostumbrarte al olor y después no darte cuenta de que tu código apesta.</div>
<br />
<a href="https://1.bp.blogspot.com/-qyNseA8OFCc/WLoawomGsEI/AAAAAAAABH4/JLDJkm8mFIgEyJsR-OFgSQ4EafZKGQ3HACLcB/s1600/refactor.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://1.bp.blogspot.com/-qyNseA8OFCc/WLoawomGsEI/AAAAAAAABH4/JLDJkm8mFIgEyJsR-OFgSQ4EafZKGQ3HACLcB/s1600/refactor.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-qyNseA8OFCc/WLoawomGsEI/AAAAAAAABH4/JLDJkm8mFIgEyJsR-OFgSQ4EafZKGQ3HACLcB/s1600/refactor.jpg" /></a><br />
<br />
Algunos de los malos olores en el código son:<br />
<br />
<b>Código Duplicado</b><br />
<div style="text-align: left;">
El código duplicado no es en sí un error. El problema es que no ayuda al mantenimiento del código. Hace que sea fácil cometer errores en el futuro, además de que te llevará más tiempo modificarlo. ¿Te ha tocado hacer un cambio en un programa y tener que ir a muchos partes del código a hacer el mismo cambio? No solo te tardaste más, también existe la posibilidad de que hayas olvidado cambiarlo en algún otro lugar y por lo tanto has introducido un error. </div>
<br />
<div style="text-align: left;">
Para prevenir el código duplicado, lo que puedes hacer es que cuando necesites que se ejecuten instrucciones en varios lugares, en lugar de copiar y pegar, mejor corta y pega. Corta la parte que se repite, pégala en un nuevo método, lo que cambia lo defines como parámetros y mandas llamar (o ejecutas) ese método donde lo necesites.</div>
<br />
<b>Método muy largo</b><br />
<div style="text-align: left;">
El problema con los métodos largos es que es difícil leer que es todo lo que hace. Se complica poder entenderlo y por lo tanto lograr notar a simple vista como puedes afectar la funcionalidad del método al introducir un cambio. </div>
<br />
<div style="text-align: left;">
Si el método hace muchas cosas es mejor llamar a otros métodos que hagan una parte chica cada uno. Por ejemplo: si tienes un método que genera un archivo con mucha información (como la factura electrónica). En lugar de tener todo el código en el mismo método, puedes dividirlo en métodos que escriben cada parte del objeto al archivo (un método para escribir los datos del emisor, receptor, otro para productos, etc.).</div>
<br />
<b>Función con muchos parámetros</b><br />
<div style="text-align: left;">
Este es un mal olor que se va dando con el tiempo, empiezas con uno o dos parámetros y todo se ve bien, luego agregas funcionalidad, necesitas más información y le vas agregando más y más parámetros y a veces algunos de esos son opcionales. Al final puedes terminar con un método (o función dependiendo como le llame el lenguaje) que recibe muchos parámetros. No es un error; pero puede hacer más difícil entender el código.</div>
<br />
<div style="text-align: left;">
Lo que puedes hacer es que cuando empieza a crecer el número de parámetros, en lugar de recibir muchos parámetros, recibir uno solo, un objeto o estructura con atributos (o propiedades) para cada posible valor. Algo como lo que hace jQuery (por ejemplo) con la función <i>ajax</i>, en lugar de recibir muchos parámetros, recibe un solo objeto con atributos para cada opción esperada.</div>
<br />
<b>Magic Strings</b><br />
<div style="text-align: left;">
No solo aplica para las strings, también para los números. Las magic strings son <b>valores literales</b> que aparecen en el código. Por ejemplo cuando en ASP.NET tienes algo como <i>[Authorize(Role = "Administartor")] </i>si te fijas escribí mal el nombre del rol <i>Administrator</i> y no me voy a dar cuenta hasta que vea que todos los usuarios pueden acceder a ese recurso (no solo los que tengan el rol administrador). Con los números el problema no es que lo escribamos mal, sino que no sabemos qué es, si tenemos algo como <i>if order.status = 2 then</i> es difícil saber qué significa ese 2 por lo tanto si quiero modificar el código debo tener cuidado.</div>
<br />
<div style="text-align: left;">
El uso de constantes para los strings y el de enums en los enteros ayuda a prevenir este feo olor. Usa cosas como <i>[Authorize(Role = Role.Administrator)] </i>porque así si lo escribes mal puedes darte cuenta en tiempo de compilación. Tener cosas como <i>if order.status = OrderStatus.InProgress then</i> hace que sea fácil de saber que está pasando en el código.</div>
<br />
<b>Complejidad innecesaria </b><br />
<div style="text-align: left;">
Es como cuando usas una bazuca para matar una mosca. La complejidad innecesaria hace que el código sea más difícil de seguir, de entender y de modificar. El desarrollo se vuelve más lento y sin ningún beneficio. Este olor puede ser difícil de detectar, más por uno mismo. Es como la persona que se pone mucho perfume pero no se da cuenta porque siempre se pone y ya se acostumbro. No es que huela feo; pero no es agradable el perfume en exceso.</div>
<br />
<div style="text-align: left;">
Algunos proyectos son más complejos que otros; pero no debes empezar de lo complejo a lo simple, sino al revés (para seguir con la metáfora, no te puedes ir quitando perfume). A veces sí ocupas dividir tu proyecto en varias capas; pero ve agregándolas cuando sientas que lo necesitas. No empieces agregando capas solo porque sí, después es más difícil quitarlas. </div>
<br />
Estos son algunos de los olores que identifico, <a href="https://blog.codinghorror.com/code-smells/" target="_blank">hay más</a>; pero hasta aquí la dejamos por hoy. Mantén tú código oliendo bien, <b>evita el código hediondo</b>.<br />
<br />
<br />
<br />Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0tag:blogger.com,1999:blog-23470706.post-67474547376950294372017-02-13T13:05:00.000-08:002017-02-13T16:19:20.478-08:00Cohesión <div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-eQGPQpG5IbI/WKIdzLtPDgI/AAAAAAAABGo/ZsEekQwWm7Ih5eAap4hXuJwZBT5UXy-EgCLcB/s1600/cohesion.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://4.bp.blogspot.com/-eQGPQpG5IbI/WKIdzLtPDgI/AAAAAAAABGo/ZsEekQwWm7Ih5eAap4hXuJwZBT5UXy-EgCLcB/s1600/cohesion.jpg" /></a></div>
<br />
<br />
La cohesión (en programación) se refiere a que tan bien están relacionados entre sí los elementos de un módulo. En el desarrollo orientado a objetos podría decirse que es el grado de relación que existe entre los métodos y variables de una clase. </div>
<div>
<br /></div>
<div>
</div>
<div>
Conocer la cohesión te puede ayudar a saber si la clase cumple o no con el principio de responsabilidad única, el cual dice que una clase solo debe tener una razón para cambiar. A veces no se ve a simple vista si el diseño cumple con este principio. Midiendo la cohesion podría ayudarte a distinguir si realmente los métodos hacen cosas relacionadas entre sí. </div>
<div>
<br /></div>
<div>
</div>
<div>
He visto que hay más de una forma de medir la cohesión de una clase, hay herramientas que pueden auditar el código y decirte como está la cohesión en el proyecto. No he tenido oportunidad de jugar con esas herramientas, la verdad es que esta métrica no la aplico seguido; pero una forma sencilla de medirla es creando un diagrama donde a cada operación de la clase la representas con un rectángulo y cada variable como un circulo (o rectángulo con bordes redondeados). Después conectas los elementos relacionados con una línea. Una vez que se hacen todas la conexiones agrupas los elementos que tienen relación entre sí. <br />
<br />
Si solo te sale un grupo entonces hay una alta cohesión y la clase tiene una sola responsabilidad. Si salen varios grupos entonces tiene una baja cohesión, significa que la clase tiene más de una responsabilidad y quizás sea buena idea dividirla en otras clases, según los grupos resultantes en el diagrama. </div>
<div>
<br /></div>
<div>
Esto va a depender de lo que buscas con la clase, hay ocasiones en que la clase solo la quieres para tener datos relacionados entre sí, como una clase de tipo <i>dirección</i> sin operaciones, solo propiedades para cada parte del dato. Ahí tienes una baja cohesión; pero quizás quieras dejarlo todo en una sola clase. Esto dependerá de tu diseño, la métrica solo te da información, a ti te toca decidir que hacer con ella.</div>
<div>
<br /></div>
<div>
Haz un ejemplo, supón que estás trabajando en una aplicación que generará una factura electrónica, entonces creas una clase <i>Factura</i> con las siguientes operaciones y variables (omitiendo cosas porque esto es solo un ejemplo):<br />
<br />
<div class="separator" style="clear: both; text-align: left;">
<a href="https://4.bp.blogspot.com/-gJSKQVwrmZo/WKIQ5KcCDEI/AAAAAAAABF0/BaMCnJyu9wISTfxcmEbfXFODYZ2riDMsQCLcB/s1600/factura-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="251" src="https://4.bp.blogspot.com/-gJSKQVwrmZo/WKIQ5KcCDEI/AAAAAAAABF0/BaMCnJyu9wISTfxcmEbfXFODYZ2riDMsQCLcB/s640/factura-1.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Ya que tienes las operaciones y variables dibuja unas flechas con las relaciones y reacomodas los elementos para que se vean mejor las relaciones:</div>
<div class="separator" style="clear: both; text-align: center;">
<img border="0" height="334" src="https://2.bp.blogspot.com/-xs0cKKf2n60/WKIRz359SdI/AAAAAAAABF8/YOb5073K5B42UxG1oxsggzWVUoQuTMGkgCLcB/s640/factura.png" width="640" /></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="color: black;">Viendo las relaciones puedes identificar 4 grupos, eso te dice que la clase <i>Factura</i> tiene baja cohesión y que puede dividirse en varias clases. Puedes ver, también, que la clase tiene varias responsabilidades.</span></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Separando las responsabilidades de la clase factura y buscando una alta cohesión puedes quedar con un diseño de 4 clases donde antes tenias solo una. Cada una con una única responsabilidad y "una sola razón para cambiar". </div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-aSTHZnf1moc/WKIT2F9YF3I/AAAAAAAABGI/SE8MGGNl2GYrjMT4-NjrUoQfpYMMtSDwQCLcB/s1600/factura-2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-aSTHZnf1moc/WKIT2F9YF3I/AAAAAAAABGI/SE8MGGNl2GYrjMT4-NjrUoQfpYMMtSDwQCLcB/s1600/factura-2.png" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Al final el objetivo es que el código sea fácil de entender y de mantener por ti o por alguien más. La meta no es lograr una alta cohesión, la meta es lograr un mejor diseño. Si después de separar en muchas clases, algo te dice que hubiera sido mejor dejar todo en una sola, no dudes mucho en hacer el cambio. </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br /></div>
Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com3tag:blogger.com,1999:blog-23470706.post-40918629303797685252017-02-02T13:17:00.000-08:002017-02-02T13:20:55.606-08:00Todo comienza con la escritura<div style="text-align: justify;">
Estaba escuchando el <a href="http://seanwes.com/podcast/" target="_blank">podcast de seanwes</a>, un <a href="http://seanwes.com/podcast/303-no-really-it-all-starts-with-writing/" target="_blank">episodio</a> donde comentaba (como muchas otras veces) que todo comienza con la escritura. Ya había escuchado esa opinión de Sean, de hecho él tiene un <a href="http://seanwes.com/supercharge-your-writing/" target="_blank">curso</a> y toda la cosa sobre el tema. Cuando escuchaba esa frase, pensaba que eso aplicaba solamente para el content marketing; pero pensando un poco más me di cuenta que también puede aplicarse al desarrollo de software.</div>
<br />
<div style="text-align: justify;">
"Todo comienza con la escritura". Al pensar como aplica esa frase al desarrollo de software, recordé que como programador lo que me gusta es escribir código. No me gusta escribir palabras sobre lo que va a hacer mi programa, no me gusta realmente escribir documentación; pero... </div>
<br />
<div style="text-align: justify;">
También recuerdo que en los proyectos donde he podido avanzar más rápido y sin estrés es cuando me entregan los requerimientos por escrito y bien explicados. Cuando la persona que describe el problema se tomó la molestia de escribir claramente el objetivo del proyecto. Me ha tocado estar en proyectos donde no hablo directamente con el cliente, donde mi trabajo es solo implementar una solución propuesta por el arquitecto, en esas ocasiones ha sido fácil llegar al resultado cuando el diseño está bien documentado. Cuando no tengo que estar en las juntas donde <a href="http://www.developeando.com/2014/12/no-hablemos-solamente-por-pereza.html" target="_blank">se habla de como sería bueno que funcionaran las cosas en lugar de definirlas por escrito</a>. </div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-ZDQOEFvqOxc/WIvcw0MNuvI/AAAAAAAABFM/U0WWvmeNPBgq_Bd3y4eRRANxEnhohuCdwCLcB/s1600/writer.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://4.bp.blogspot.com/-ZDQOEFvqOxc/WIvcw0MNuvI/AAAAAAAABFM/U0WWvmeNPBgq_Bd3y4eRRANxEnhohuCdwCLcB/s1600/writer.gif" /></a></div>
<br />
<br />
<div style="text-align: justify;">
Parte de la<a href="http://www.developeando.com/2011/06/motivacion-diaria.html" target="_blank"> motivación diaria</a> que me ayuda para no distraerme es tener tareas bien definidas, por eso creo que es bueno <a href="http://www.developeando.com/2017/01/define-las-tareas-antes-de-empezar.html" target="_blank">definir tareas antes de ponerse a programar</a>... con esto me doy cuenta que realmente todo empieza con la escritura, también en el desarrollo de software. Se inicia con la definición de la idea, del objetivo y con la definición de tareas. Si tenemos el habito de escribir nuestras ideas, no nos dará flojera definir por escrito lo que vamos a realizar. De ese modo cuando tengamos definido lo que haremos podemos abrir el editor y solo preocuparnos por el código, seguir el flujo sin detenernos por falta de información. </div>
<br />
<div style="text-align: justify;">
Es claro que el escenario ideal no es muy común, por lo general no hay tiempo para definir todo a detalle e incluso cuando lo hay no tiene mucho sentido ya que seguramente los detalles de requerimientos cambiarán. Pero no por eso debemos dejar de definir el proyecto con escritura antes de iniciar, las especificaciones pueden cambiar y el habito de escribir nos va a ayudar a no postergar la actualización de la definición. Como todo, entre más practiquemos definir los proyectos con palabras más sencillo se nos hará. Será fácil que llegue una persona nueva al equipo y se ponga al corriente con lo que es el proyecto. </div>
Mario H. Cornejohttp://www.blogger.com/profile/01576953695407749789noreply@blogger.com0