Líder TI Caso 04. Consideraciones para mover una BD de un server a otro

Escribo esto porque acabo de llegar a mi cueva después de un ajetreado día de trabajo, mejor dicho, una ajetreada que me despegó del mundo unas 5 horas consecutivas. Inicié a las 05:00 PM a 10:00 PM aproximadamente. Me refiero a una migración de bases de datos de un servidor a otro, los servidores son IAAS en Azure con Windows Server 2012 R2, eran 14 bases de datos de SQL SERVER 2014, algunas BDs con 4GB otros con 35 MB, En total era migrar unos 15GB, además de migrar los web services WCF y REST relacionados. ¿Por qué la migración? Porque en el servidor origen (llamémosle servidor A) se presentó una anomalía para acceder al escritorio remoto del mismo, creemos que un ataque de consumo o alguna falla por parte de alguien que tiene acceso oficial al servidor, que en este caso somos 3, malogró alguna configuración. Dicha anomalía sucedió el domingo en la tarde noche, cuando nadie trabaja, por lo tanto todo el lunes nos dimos cuenta y no se podía ingresar al server para revisar los backups generados ni cualquier otro archivo de revisión de rutina, por suerte esta anomalía no afecto el funcionamiento del motor de base de datos, tampoco a los servicios web. El día había iniciado, los clientes del servidor A iniciaron operaciones de lo más normal así que un reinicio para verificar si esa era la solución, podría ser fatal, así que en la noche esperé que todos los clientes salgan para el reinicio. Lamentablemente persistía el problema.

Decisión. Como jefe de producción y encargado de la continuidad de negocio de nuestros clientes, tenía dos caminos, o mecharme con los de Microsoft Perú, o migrar a otro servidor IAAS, bueno, creo que el título del post lo dice todo, porque no podía esperar más en obtener los backups del sábado, domingo, lunes y martes estancados en un servidor inaccesibles. Ahora, iniciar un trámite de acuerdo con Microsoft nos quita un recurso importante: tiempo, ya que anteriormente sucedió algo similar que hizo que el negocio de nuestros clientes se detuvieran por cerca de cuatro horas. Inaceptable. Menos mal entendieron que dependía de responsabilidad de nuestro proveedor MS, pero no cualquier cliente puede entender eso, pero menos mal que nuestro cliente tenía planes de contingencia en caso fallara el sistema. Obviamente llegamos a un acuerdo para que este perjuicio sea un descuento en su mensualidad por el servicio. Bueno, saquen Uds. sus conclusiones respecto a Azure, si bien es cierto no es seguido (el primer inconveniente sucedió hace un año) pero deja que desear, en fin. La decisión ya está tomada, a ejecutarla.

A las 05:00 PM arrancó todo, tenía que esperar hasta las 08:00 PM para que salgan todos de los servicios, eso quiere decir que: Primero debe coordinarse el corte de servicio con el cliente, esto es vital, hasta los bancos lo notifican, claro ellos hacen mantenimiento por las madrugadas. En fin, hasta las 08:00 PM tenía tiempo para preparar la automatización de la migración, esto es obvio, si no queremos tener fallas, dejemos que el SO lo haga por nosotros. Primero comencé con asegurarme que el servidor destino (llamémosle servidor B) esté operativo a la perfección, para ello le instalé los web services de A a B, esto se logra fácilmente a través de una carpeta compartida entre servidores Azure conectados a una VPN que permitan copiar los contenidos de los web services de IIS. Segundo, configurar la seguridad del BD destino, usuarios, roles, permisos, accesos, denegaciones y configuraciones extra, para ello ya tenía preparado el script sql necesario. Tercero, hacer una prueba de acceso con una BD de prueba cambiando las configuraciones del lado del cliente a una aplicación aislada, y asegurarte que todo lo anterior esté configurado correctamente. Cuarto, antes que llegue la hora tope creé el script que saque los backups completos hacia una carpeta del servidor A que sea de escritura y sea leída desde otro servidor (para mi fortuna todo servidor de nuestro negocio tiene una carpeta FTP, lamentablemente la carpeta compartida entre servidores por la VPN no tenía permisos de escritura). Como me alcanzaba el tiempo, también alisté el script que restaure esas backups en el servidor B. Entonces, para nuestros 60 o 70 clientes con el ejecutable que apuntaba al servidor A ¿Cómo podríamos cambiarlos para que lean al servidor B?, pues tendríamos que cambiar la parte del servidor de su actualizador automático para que descarguen la misma versión del ejecutable de presentación pero con los archivos configs que apunten al servidor B (Sí, eso olvidé mencionar, la arquitectura es cliente/servidor de escritorio conectado a servicios WCF y REST) además cambiar paralizar el server A para que nadie se comunique con él. ¿Cómo podría detener los servicios de A si no hay acceso a su escritorio remoto?, fácil hay solución, si tuvieras respuesta favor de comentármelo, pero para este apaga fuego sólo decidimos a cambiar las contraseñas a todos los login de la BD a las 08:00 PM. Ejecuté el script de backups a la carpeta FTP y con FileZilla descargué directamente los BAK a una carpeta del server B, realmente lo hizo en media hora esos 15GB aprox. asumo que por lo que están en VPN (velocidad de 32MB/s aprox), ejecuté el script de restauración en el server B, además de otro script que le asigne los usuarios, permisos, roles, etc a las BDs restauradas (claro, porque hasta ese momento tenías las ids de los usuarios incluidos en la migración aún son del server A), con eso ya era suficiente para que la presentación pudiera acceder al nuevo server. Luego, configuré el Firewall para que todas las IPs que accedían al puerto SQL de A sean idénticas en B. Finalmente, se cambió el DNS para que el IP pública fija que apuntaba al servidor A apunte ahora al B. Después de tanto trajín y pruebas, todo estuvo correcto a las 9:47 PM y para el usuario mañana todo será trasparente.

Obvio que cada ambiente de sistema es un mundo, pero no escapa de cosas que son estándares, como por ejemplo hacer este trabajo fuera de horario de oficina del usuario, pruebas de continuidad, notificaciones previas al usuario, etc. Si tuvieras recomendaciones favor de enviarme a mi correo o comentario. Bueno, en honor a la verdad este post pudo ser más extenso, pero tengo controlar mi tiempo que le dedico a los post, pero si tuvieran la necesidad de que comparta algún detalle de esta travesía no dudes en escribirme, tal vez quieres que te pase algún bat, script powershell, o T-SQL, en fin, estamos para compartir. Ahora sí a dormir.

Tesis de Maestría, Matrimonio, Certificaciones y más

En todos estos meses ha estado rondando sobre mi cabeza la clásica frase de Terminator "I'll be back". Y aquí estoy, a ponerme al día. Hasta esta fecha estoy debiendo 60 post, y es un reto ponerme al día, pero no imposible. El motivo del cese fue en primer lugar, mi Tesis de maestría, el cual acabo de culminar e inicio la gestión de mi trámite, esta tesis me ha consumido miles de horas de lecturas en inglés de la prestigiosa ISACA, pues en estos meses logré obtener un certificado de miembro de ISACA y así acceder a todo el material rico en proteínas de conocimiento y así generar un mejor bolo alimenticio de investigación. Pues me sirvió mucho, me sirve mucho, he contactado con profesionales de alta calidad en auditoria de TI, entre ellos los más destacados de Perú. En fin mi tesis de 220 páginas lo vale, me ha costado sudor, y como dice mi asesor, la cereza en el pastel es la participación de estos validadores internacionales dentro de mi tesis.

Referencia a la película TESIS

Otro gran evento que ha consumido parte importante de mi tiempo, es mi próximo matrimonio con la persona responsable de mi segundo post en mi blog. Lili. Decidimos comprometernos y casarnos civil-religioso en el día de la primavera. Este trámite también es un exacerbante pensamiento de ver cómo tu dinero se desvanecerá para unas horas de celebración, mi novia y yo, sólo esperamos que valga la pena en el futuro, pues no somos mucho de gastar en eventos. Pero, sin duda no es cualquier evento y queremos hacer algo de acorde a nuestros gustos. Así es que si deseas casarte, verifica tus posibilidades económicas o ajústate a la realidad si luego no quieren tener trifulcas por temas económicos con la pareja, esto es muy a parte de los sentimientos y puede llegar a matarlos si no saben entenderse. Menos mal nosotros tenemos pensamientos económicos similares así que todo va bien. Mientras, hasta llegar el día, estamos full con los detalles y toda la parafernalia que involucra. Para felicidad nuestra, nuestros padres, hermanos, familiares nos están brindando todo su apoyo incondicional. :)

Help! se acaba la soltería

Bueno, para terminar, se vienen varios trámites y gestiones que me mantendrán ocupado pero no tanto como la tesis, así que me pondré al día brindando todo el conocimiento obtenido en esta ausencia, y espero sepan apreciarlo (Libros nuevos, discos nuevos, conciertos, sorpresas, regalos, #eseconch..). No hago nada de publicidad a mi blog, sólo espero que poco a poco solo se vaya haciendo conocido. Si estás leyendo esto, gracias. Estoy preparando mucho armamento para descargar..

El regreso se manifestó como un ensamble de fuerzas acumuladas

Lider TI Caso 03. Test Development Driven. Mi implementación es un bebé en pañales

Es todo un mundo nuevo si tu forma de programación es clásica, es decir, recibir las necesidades de tu cliente o usuario final y pasarlo a código durante horas y horas, el TDD, te resetea el chip, ¿Cómo?, de la siguiente manera: Primero creas el código que verificará si los resultados son los correctos de acuerdo a las pruebas que el usuario realizará o al menos tiene la noción de realizarlas para su respectiva aprobación de funcionamiento, y luego, te pones a programar el código fuente principal del software a entregar, si existirá bugs, se asume la refactorización, pero de manera ágil. Te la pintan de manera mágica, es más, para algunos es la salvación, pero hay una gran brecha entre la teoría y la práctica. Así que vamos por partes, y como suelo hacer, vamos por tres partes: Teoría, Planificar y Disfrutar.

Teoría

No quiero expandirme en teoría que encontrarás en cualquier libro de TDD, en tal caso te doy mi opinión para que nutras tus conceptos desde varias perspectivas. Bueno, hay varias buenas universidades en el mundo que presentan en su gama de carreras a Ciencias de la Computación, y en sus cursos de Ingeniería de Software, consideran las pruebas unitarias, tal es el caso del curso 164 de Ciencias de la computación de Harvard (http://www.registrar.fas.harvard.edu/courses-exams/courses-instruction/computer-science). Esto lo obtuve buceando en la página de Harvard. Hay más universidades top donde tienen buena escuela sobre Ciencias de la Computación, si deseas saber sobre el enfoque en Ciencias de la Computación a nivel mundial te invito a ver el top de 50 mejores escuelas que dictan esta ciencia. (http://www.businessinsider.com/best-computer-science-engineering-schools-in-america-2015-7).

Bueno, les cuento una experiencia, a mí me ha tocado entrevistar a varios nuevos egresados de escuelas de Sistemas, Computación e Informática de diferentes Universidades del departamento de Lambayeque para que ingresen a la empresa a la que trabajo; y a cada uno les solté la pregunta “¿Cuéntame tu experiencia sobre TDD, Desarrollo orientado por pruebas?”, y ninguno supo responder, y el 90 % no tenía conocimiento de ello (Considerar que pasaron el examen de conocimientos), eso me hizo pensar que hay que reforzar ese tema en nuestras universidades o al menos incentivar a que lean sobre el tema.

Planificar

Si tienes un software ya construido (es decir varios meses o años de escribir códigos), se te hará difícil pero no imposible trasladarte a este paradigma. Pero si vas a empezar un nuevo proyecto o idea estrella a explotar, te recomiendo que no dejes de lado el TDD, porque automatizar las pruebas te agilizan la forma de desarrollar tu software, pero ojo, el TDD puro va mucho más allá, así que necesitarás expertos y bastante inversión de tiempo.

Les cuento mi experiencia personal, actual, sí, ahora, right now, en la empresa donde trabajamos tenemos un ERP de 5 años de mantenimiento, así que cuenta con 10 módulos aprox., y nunca se han automatizado las pruebas, ni un solo Unit Test, así que como Responsable de Investigación y Desarrollo me estoy encargando de la automatización correspondiente, pero, de la manera más ágil posible (porque estamos madurando para aplicar SCRUM), así que estoy planificando lo siguiente: En primer lugar se debe planificar, es decir, estudiar bien el campo para luego ver como lo atacas, en mi caso, estudiar la arquitectura de software seguido, el tipo de BD utilizado, las interfaces y web services implementados, escenarios complicados (esto es muy importante porque las pruebas unitarias consisten en crear pruebas aisladas e independientes por cada escenario planteado, y dejar todo al finalizar como cuando estuvo al iniciar la prueba, o sea un chambón de ingeniería). Entonces conversando con el Jefe de Desarrollo se estableció arrancar de a pocos para no detener la productividad en paralelo, porque de hecho tendrás que meter mano al código que los desarrolladores están trabajando. (Bueno, un poco para aterrizar, en la empresa estamos utilizando TFS, así que si es un equipo de más de 3 metiendo mano al código, les recomiendo utilizar un repositorio central de fuentes), así que se inició con el módulo core de negocio para nuestros clientes, es decir Ventas (nuestro ERP es para fines comerciales de MYPES), y no todas las clases que conforman el módulo de Ventas, solamente la clase principal, que es Comprobante, y para hacer una prueba de automatización, no a todos sus subs o functions, solo el más representativos, en mi caso elegí el más complejo “Adicionar”. Entonces para empezar deduje que se debe arrancar con refactorizar algunas llamadas, en mi caso, el código no seguía un estándar para manejar parámetros, así que para “Adicionar” indiqué que todo debe ser un parámetro de entrada de tipo DataSet (puedes utilizar objetos si deseas, depende de cada uno), eso establecía que dicho dataset pueda pasarlo a XML y guardarlo una BD exclusiva para pruebas, con ello estaría guardando el “Escenario 1” y según vaya creando más escenario estas se guardaban automáticamente si es que tenía alguna bandera activada, todo en formato XML, para ello y automatizar las pruebas desde un proyecto unit test, hago lectura de todos escenarios con un for construyo un DataSet en base al XML y lo envío como parámetro. Pero si estás en un caso como el mío, donde se utilizan web services, entonces inicia pruebas de integración con los web services, porque si inicias con pruebas unitarias, tendrás que necesitar mucho tiempo para cubrir el 80% de cobertura que te exigen las buenas prácticas de pruebas unitarias.

Disfrutar

Bueno, en mi caso, el disfrute lo tendrán los desarrolladores cuando les entregue el resultado de mi investigación teórico práctico, pero hay que recordar algo, ellos tendrán que construir sus propios escenarios cuando programen, eso conlleva a estimar un tiempo para dicha actividad. Pero se beneficia en el sentido de aprovechar el tiempo en pensar más que hacer actividades manuales repetitivas, ese tiempo perdido se plasma ahora en programar los escenarios, así que ahora ese tiempo se utilizará para entrenar tu cerebro. En mi caso me estoy dividiendo entre la implementación y despliegue de ISO 9001 para la empresa donde trabajo e investigar aplicar TDD al 100%, por lo que poco a poco se está avanzando con TDD. De hecho lo ambiciosos es llegar a un DevOps total, incluyendo pruebas del fantasma (pruebas UI), pruebas unitarias al 80%, aplicación de mocks, stubs, etc.

De hecho que hay un montón de cursos, diplomados, certificaciones, etc., pero si no se ponen en práctica es lo mismo que nada. Este post es un bebé en pañales, estoy en casi nada, pero nunca es tarde para iniciar. Estoy seguro que en un futuro estaré posteando como fuimos avanzando y cuanto hemos madurado respecto a este tema. Disfruten de la Ingeniería del Software, programen!.

Biblioteca de la vida. Capítulo 04. "El joven multimillonario Mark Zuckerberg en sus propias palabras" George Beahm

Mi novia que sabe de mis adiciones, me regaló este libro "El joven multimillonario Mark Zuckerberg" de George Beahm, ella me vio que cada vez que entrabamos a Librería Crisol iba donde estaba ese libro y lo veía y veía, hasta que en un mesario me lo regaló. Un lindo detalle para una chica enamorada de un chico como yo. Ambos somos complicados, con mucho amor, y comprensión en gustos. Pero, en realidad, esperaba más de este libro, este libro contiene en palabras del mismo Mark Zuckerberg sus ideas sobre un modelo de empresa de software de este siglo, frases motivadoras, y entrevistas otorgadas, entonces como se habrán dado cuenta, todo lo hablado por Zuckerberg originalmente está en inglés y asumo que con jergas gringas, ya que la traducción es mala, al parecer no hubo control de calidad al editar este libro. Hay sílabas que se repiten como "que que", entre otras cosas que ya no recuerdo, de todo el libro de 141 páginas habrán 3 a 4 cositas por el estilo. Por lo demás está muy bien, pero creo que Zuckerberg tiene un carácter que no lo convierte en un Steve Jobs ni en un Bill Gates, se ha ganado el odio de muchos de sus mismos usuarios por situaciones que para mi no tienen  fundamento, una porque el producto que consumen es gratis y otra porque en situaciones tuvo desatinos en sus respuestas, pero también hay que entender que era un chiquillo entre 22 a 25 cuando vino el boom de facebook. Siempre ha sabido marketearse, o al menos la gente de marketing de facebook ha sabido direccionar la imagen de su creador. Actualmente es una persona felizmente casada con la Dra. Priscilla Chan, novia desde antes que creo facebook. Y pues, es algo que rescatar pues Priscilla lo conoció antes del boom y lo apoyó bastante emocionalmente.

Hay una parte muy importante de este libro que es la carta que manifestó hacia sus inversionistas (e inversionistas potenciales también) explicando claramente la misión social de facebook: "conectar cada vez más al mundo". Además está el decálogo de facebook que utilizan para brindar un buen servicio y sirve para promover la motivación en sus trabajadores, y colaboradores.

Si adquieren este libro, será muy bueno para leer, ya que tiene las palabras distribuidas para una lectura de descanso, cada página no contiene mucho texto, y está en páginas color beige. Hay muchas cosas que coinciden de la película "La red social" pero, dicha película, realizó algunos ajustes ficticios para poder marketear el guión y meterle un poco de drama, cosa que Mark desmintió, y tiene razón porque en la película aparece una novia Erika Albright la cual no tiene nada que ver, ya que fue Priscilla quien estuvo ahí en su creación de facebook. Pero, punto a parte esa película es buena, y el libro también.

"Construir una compañía es una de las formas más eficientes en el mundo de alinear los talentos de mucha gente inteligente para lograr un cambio" Mark Zuckerberg

Biblioteca de la vida. Capítulo 03. "El líder interior" de David Fischman

Corrían los últimos días de mayo del 2014, caminaba por las calles de Chiclayo y me topé con un afiche que pronunciaba la próxima conferencia del Ing. David Fischman en la ciudad de Chiclayo. Para ese entonces había escuchado sobre David Fischman en las redes sociales y en uno que otro mensaje de positivismo a través de imágenes motivadores. Dicha conferencia se realizó el Jueves 05/06/2014 en el "Centro de convenciones Tumbas Reales", y su tema principal fue la Motivación.

David Fischman y yo

Libro autografiado por el Ing. David Fischman

Para mi sorpresa, estaban vendiendo libros del autor y había una zona para tomarse unas fotos con él y para que te autografíe el libro que compres. Como yo no había leído ningún libro de él hasta el momento, y tenía una gama de ellos para elegir y aprovechar que me lo autografíe, revisé los nombres de cada uno, y hubo uno que me llamó la atención, el nombre del libro era "El líder interior", me llamó la atención porque lo vi enfocado más al plano espiritual y entendimiento del ser humano dentro de un todo. Y después de leerlo no me equivoqué. Es más, considero que con este libro uno debe iniciar para aprender liderazgo según Fischman, porque si uno no tiene liderazgo a sí mismo, mucho menos lo tendrá hacia otras personas.

El libro se divide en cuatro puntos bien claros, y el Ing. Fischman, sí sabe expresar lo difícil en términos fáciles. Estos puntos son:

• Autoconocimiento
• Poder de la actitud
• Capacidad de comunicación
• Inteligencia espiritual

Bueno, comentaré a mi opinión lo beneficioso de este libro, y apoyarte en la decisión si deseas adquirirlo.

Autoconocimiento
Evaluarte a ti mismo implica regresar a tu infancia y ser consciente que en tu niñez hubieron escenas que tú nunca deseaste, dichas escenas dejaron huellas profundas en tu carácter y comportamiento en la vida. Estas huellas son un porcentaje alto que suma a tu carácter de nacimiento que es un porcentaje bajo. Dichos malos escenarios (como golpes físicos y psicológicos de tus padres, engreimientos de la madre, abandonos y toda clase de sufrimientos), se reflejarán si o si en tu vida personal y profesional del presente. Además uno debe ser consciente de sus talentos para encontrar un trabajo de acuerdo a ello, sino sufrirá de estrés laboral. otro punto a resaltar es que uno debe diferencia bien el ROL del SER, y no debemos traer lo que somo en la vida real (SER), a nuestras responsabilidades en el ámbito laboral (ROL). Recuerda, un árbol es difícil de enderezar, pero nosotros los humanos no somos árboles y podemos cambiar nuestra forma de ser ante la vida.

Poder de la actitud
Una vez que analizaste tus fallas del presente en base al estudio de tu pasado, debes reforzar tus emociones positivas, y asumir más responsabilidad ante tus asignaciones, esto implica dejar de echarle la culpa a los demás de nuestros errores, ser observador y evaluar los fracasos que aparecen en el día a día en el trabajo. Para todo esto es necesario harta dosis de felicidad, para que sea contagiada al ambiente laboral y contribuir con un buen clima organizacional. Hay muchos tips para automotivarse, es más crearé un post a parte indicando muchos de ellos, por ahora uno de los más fuertes tips es pensar en la muerte, aunque parezca duro, en cualquier momento podemos morir, y no podemos dejar de vivir cada segundo como si fuera el último pero basándote en un objetivo de tu vida, recuerda que estamos por una temporada en este mundo terrenal. Recuerda, la felicidad depende de que tan lejos observas los problemas sin ser ciegos a ellos.

Capacidad de comunicación
Comunicarse actualmente está un poco dañado, existe tanta tecnología mal aprovechada, que nuestra comunicación como humanos está deteriorándose, ¿Por qué?, porque estamos perdiendo el don de escuchar, no simplemente oir, sino escuchar con atención y ponerse en los pies de la otra persona, llegar a tener un alto grado de empatía hacia los demás conlleva  a fortalecer tus silencios cuando debes escuchar y a evitar prejuicios (voces internas) que no te dejan entender la realidad de las cosas. Esto llevándolo al plano laboral evitará muchos teléfonos malogrados y aumentará tu productividad, ya que la comunicación es la base de toda organización, si no hay buena comunicación no habrá buena productividad. Recuerda, cada persona es un mundo y no hay que juzgarlos, pero sí podemos ayudarlos escuchándolos y aconsejándolos.

Inteligencia espiritual
Esta sección es la base del libro. Aquí te explica que tú tienes inteligencia racional e inteligencia emocional, uno para usarlo en el contexto académico, mediante el aprendizaje, raciocinio y lógica; y el otro para controlar tus impulsos sentimentales, de afecto y emoción; respectivamente. Pero, hay una inteligencia mucho más superior, que es inteligencia espiritual, enfocada en la paz interior y felicidad. De manera breve indicaré que uno para llegar a ese estado, deberá evitar el ego, pensar en el mundo como un solo ente donde todos estamos conectados hacia un fin en la vida, sin embargo, no se puede solamente estar hablando de lo que uno realizará o hará como cambio en su vida después de leer el libro, hay algo más para fortalecer el espíritu, y es la meditación, que dependerá mucho de las creencias del lector, puede ser mediante oración para los cristianos, meditación hindú para los Hare Krishna, meditación budista, etc. El objetivo es darle unos minutos al día a tu mente para poder limpiarla y fortalecerla; al igual que el cuerpo, la mente también necesita descanso y limpieza. Recuerda, uno de los caminos más faciles para vivir con paz interior es ayudando o sirviendo a los demás con el corazón.

Este libro es muy recomendado, tiene muchos ejercicios para el autoconocimiento a través de cuestionarios, referencias reales a estudios científicos sobre liderazgo, tips reales con casos del día a día, y de hecho con las metáforas que caracterizan al Ing. David Fischman. para expresar lo difícil en lo fácil. El próximo libro que debo conseguir es "la alta rentabilidad de la felicidad", créanme que estar feliz día a día, ser agradecido y ayudar constantemente a los demás con el corazón es el combustible más poderoso para potenciar el motor motivador de nuestra vida. Por favor, sean felices y disfruten la vida, sin importar la religión o creencias.

Líder TI Caso 02. Analista programador Senior o Jefe de Proyectos Junior

Una de las habilidades de mi carrera que me gusta aprender día a día y explotar, es el liderazgo. El liderazgo no se aprende leyendo libros ni viendo videos, el liderazgo se practica, uno se tiene que envolver mucho con temas de psicología y hasta pueden pasar años para ser un buen líder. ¿Por qué años?, por lo siguiente: Hay muchos que son técnicamente expertos en su especialidad, por ejemplo, un Programador Senior en Visual Studio o Java con 5 años de experiencia, tienes objetivos cumplidos muy altos, prácticamente es el "men!", pero, luego la empresa al evaluar su productividad, lo asciende a Jefe de Proyectos. ¿Cómo lo acepta?, hay dos caminos, uno, acepta su nuevo cargo pero no quiere dejar de ser el "men" se descuida de sus nuevas responsabilidades de Jefe y lo sobrelleva porque le gusta el sueldo, y sabe que si se mantiene como analista programador no tendrá ese sueldo. Esto último es un error, luego lo detallaré. O dos, acepta sus nuevas responsabilidades, acepta su nuevo rol, y se desprende del rol anterior paulatinamente, teniendo en claro sus objetivos y nuevas metas a conseguir.

Según mi experiencia y conocimiento, tengo claro tres roles en este escenario, sin embargo la mayoría ve sólo dos. Para mi son: Analista programador, Jefe de Proyectos y Líder tecnológico. Quién de estos tres gana más en sueldo, el líder tecnológico; quién de estos tres tiene más poder de decisión, el Jefe de Proyectos; quién de estos tres tiene más participación operativa, el Analista Programador. Entonces, vamos por partes y seamos sinceros, si bien es cierto en la universidad nos enseñan a programar y esto parece ser una actividad de ingeniería muy productiva para nuestra profesión, demostrar que somos unos capos escribiendo códigos inteligentes, algoritmos como solución al problema, y nos creemos hackers gringos que pueden acceder a los datos secretos del Área 51, en fin. Pero, en la universidad no nos explican o detallan que esta actividad es muy operativa si no se combinan con habilidades de liderazgo, es muy bonito programar, es un arte, la gente te tiene respeto al descubrir nuevas soluciones ante un crisis en proyecto, pero, ¿Es eso a donde quiere llegar uno en el ámbito profesional de la programación?. Por lo tanto dependerá del enfoque que le das a tu carrera, Enfoque operativo (Analista programador), Enfoque experto (Líder tecnológico) y Enfoque en toma de decisiones (Jefes de proyectos o Gerentes de Sistemas).

Equipo de Macintosh en Apple 1983. Programadores, Jefes de Proyectos, Lideres.

Enfoque operativo
Si nos ponemos a pensar quienes son los programadores más representativos en la historia de la informática, y que han dedicado su vida netamente a la programación sin enfocarse o prestarle atención a los conflictos de tomas de decisiones, negocios, la bolsa de valores, etc. etc., y sobre todo no preocuparse en figurar. Se me viene a la mente: Dennis Ritchie, creador del lenguaje C, fue un científico de la computación y programador, el tipo era el clásico programador barbón encerrado en su habitación para demostrar al mundo su poder a través de los códigos, erudición e imagen ermitaña. También está Rasmus Lerdorf, creador del lenguaje de programación PHP, el cuál fue madurando con ayuda de colaboradores a nivel mundial, llevando el lenguaje a un estado superior estableciéndolo como un referente en desarrollo web. De hecho hay muchos más representantes, los cuales detallaré uno a uno en futuros posts. Otro célebres personajes son Steve Wozniak, cofundador de Apple y Paul Allen cofundador de Mcirosoft.

Dennis Ritchie

Enfoque experto
Aquí se encuentran los influyentes, aquellos que tuvieron una idea en la informática, sobretodo en programación y lo convirtieron en filosofía. ¿A qué se debía?, por su alta experiencia y conocimiento en el tema que defendían a capa y espada. En este enfoque considero a Linus Torvalds, responsable del kernel de Linux, él hasta la fecha ha conseguido varios reconocimientos por sus aportes a la ciencia de la computación, aún sigue vigente con sus aportes de programación (síganlo en su perfil de google plus). Otro programador y activista de Internet, fue Aaron Swartz, él desde niño tuvo alma de programador, su padre consiguió un ordenador para el hogar y desde ahí no dejó de investigar a nivel internacional con otros programadores en los foros; tras esas investigaciones fue cofundador de Reddit. Lamentablemente falleció por temas judiciales con un robo de información hacia el MIT, esto sucedió pocos años después de su activismo en contra de la ley SOPA.

Aaron Swartz

Enfoque en toma de decisiones

Veamos el caso de Mark Zuckerberg, fue programador pero ahora es el CEO e imagen de facebook. O Bill Gates, que fue programador y fue CEO de Microsoft, ahora filántropo que lucha contra la malaria. Ellos, son el claro ejemplo de personas que decidieron dejar sus habilidades de programadores para dedicarse a la Gerencia y Gestión, y enfocarse a que su empresa no se vaya a la quiebra y sea sostenible en el tiempo. Pero que hayan sido programadores les ha permitido una visión demasiado holística de su empresa, pues ellos fueron la parte operativa en su momento y se quebraron con sudor y sangre para obtener un producto sostenible como negocio. A este saco también metería a Larry Page y Sergey Brin, de Google.

Mark Zuckerberg

Bien, cuando mencioné que es un error creer que un Analista Programador no puede ganar más que un Jefe de Proyectos, es cierto. Las responsabilidades netas de un Jefe de Proyectos, son de gestión y control, pero si a este Jefe le agregas responsabilidades de Líder Tecnológico, aumentará su valor, tendrá mayor información y poder de decisión. Sin embargo si al Analista Programador lo fusionamos con las responsabilidades de un Líder Tecnológico, obtendremos a una pieza clave del proyecto, mano derecha del Jefe de Proyectos; y, si la organización tiene el criterio de otorgar sueldos en base a su conocimiento y cumplimiento de responsabilidades, el Líder Tecnológico tendrá más sueldo que el Jefe de Proyectos.

Pero, ¿Qué roles tienen mayor sueldo en la informática?. Están, los Arquitectos de Software, Gerentes de Sistemas, Auditores de Sistemas, CTOs y CEOs. Y, todos ellos manejan muy bien el liderazgo. Así, que para triunfar en cualquier cosa de la vida, se debe tener mucho liderazgo, primero interior y luego exterior. Eso lo detallaré en futuros post, gracias a las lecturas realizadas a las obras de David Fischman, también Ingeniero.

Entonces, no dejen de mejorar sus errores en comportamientos y actitudes, en asumir responsabilidad de errores y triunfos en proyectos de software, y siempre aceptar riesgos para mejorar la actitud positiva y vencer los miedos. Disfruten su trabajo!

Tetris

Era niño, aún lo recuerdo, mi hermanastro llegó algún día de visita a mi casa en Chorrillos (tenía 5 años más que yo y yo bordeaba los 7 años), entonces sacó de su mochila un "Brick Game", y me sorprendió, él parecía un iluminado con este dispositivo que me parecía de la más alta tecnología. Me lo prestó y me enamoré del dispositivo y le pedí a mi mamá que me adquiera uno. Así que lateamos por el centro de Lima y lo conseguimos:

Brick Game

El juego que hasta ahora está presente en mi vida, es Tetris, este venía incluido como juego bandera en estos Brick Game's. El juego creado por Alekséi Pázhitnov, Ingerniero Informático de profesión, consistía en vencer a la velocidad de la gravedad de unas figuras constituidas por cuatro cuadros o cubos, los cuales al formar una línea horizontal completa en el campo de juego, reducía la altura del cúmulo de figuras agrupadas. Conforme ibas progresando en formar líneas horizontales la velocidad de la gravedad aumentaba e ibas consiguiendo frutas (esta forma de logros venían en esta versión de 1995). Las figuras son solamente de cuatro cuadros o cubos. Ellos son las letras: I L J T S Z O

La pantalla era la siguiente:

Esta consola barata y accesible, hizo historia en el mundo. Salieron muchas versiones de juegos "engaña muchachos" (como suelo decir), donde repetían este juego miles de veces y ya tenías 999999 juegos en 1. Recordarlo merece un #ROFL. Poco tiempo después mis padres adquirieron una consola FAMILY COMPUTER, y para alegría mía venía con Tetris incluido. Luego me siguieron comprando otras consolas similares a Brick Game, una de las consolas que recuerdo me compraron mis padres era en color negro y se llamaba APOLO, buenas épocas!

En la actualidad juego en mi celular Android "Clasic Blocks", que es una versión con cuadros o cubos similares a los 90 (ver figura anterior), y en mis tiempos libres juego tetris online en http://www.tetrisfriends.com/,

Disfruten este juego o hagan que sus hijos aprendan a ganar y vencer sus propios records, pues, está comprobado que este juego agiliza las reacciones en toma de decisiones y entrena el cerebro para trabajar con rapidez. Perfecto para un ingeniero en potencia.