Ya está lista la nueva versión de SimpleGDC

viernes, 22 de agosto de 2008

Seguramente no conocen SimpleGDC, por supuesto. Es una nueva aplicación para generar documentos contables, tales como la Hoja de rayado diario, Esquemas de mayor, Balanza de comprobación y el Balance general. Actualmente en la versión 2.0.0.1 con muchas mejoras respecto a la primera versión.
La generación de estos documentos los realiza SimpleGDC después de haber creado una hoja de asientos de diario, y los exporta a Excel para su mejor uso. Screenshot

Pueden encontrar la descarga y el tutorial de uso en http://simplegdc.wikispaces.com y apoyar con sugerencias, ideas e informe de errores en el grupo de discusión de Google.

Muchas gracias a la profra. Araceli Susunaga por la idea de la realización de esta aplicación.

Cómo catalogar a un desarrollador de software

lunes, 11 de agosto de 2008



15 consejos para obtener el ascenso que quieres, e incrementar el salario que te mereces

¿Cómo catalogas a un desarrollador de software? Es una pregunta fantástica. Hay muchas teorías por allí, y hay muchas formas en las que los equipos de Recursos Humanos lo hacen y te ayudarán a dirigir el estudio de rendimiento. Sin embargo, ¿qué hace realmente a un gran desarrollador? Y si eres un Desarrollador de Software, ¡cómo puedes mejorar hoy tu carrera! Abajo les presento mi biblia para catalogar a los desarrolladores en mi equipo. Siguiendo estos consejos e ideas, podrás mejorar tu estado de "buen desarrollador", a "gran desarrollador".

1. Tiempo que invierte escribiendo código grandioso.
¡No me refiero a la cantidad, sino a la calidad! Sin embargo un giro a esto es: Me refiero a la cantidad, y la calidad. Muchísimas veces encontrarás uno de estos dos escenarios.

En el escenario A, tienes a un desarrollador que escribe código como loco, y las cosas parecen funcionar... entonces comienzan a suceder errores, y tú no sabes porqué, parece que llevará toda la vida arreglarlos. ¡O ellos arreglan 10 y causan 5 más! Pero obtuviste bastante código...

En el escenario B, tienes a un desarrollador que parece inteligente. Lo entrevistas y él lo sabe todo de todo, puede hablar teóricamente de arriba a abajo. Pero por alguna razón, tú le has asignado tres tareas, y tres semanas después, ¡él aun está trabajando en algo que debió haber terminado en 3 días! Y estás confundido. ¡Él es tan inteligente! Conoce todo acerca de generics, multi/threading, ¡y puede explicarle de punteros a tu abuela y hacer que ella se emocione y quiera codificar! ¿Por qué no esté terminado nada?

¡En el escenario de tus sueños, obtienes código grandioso! El código grandioso está hecho por un gran desarrollador que es súper inteligente, conoce lo que es código de calidad, y escribe código como Tony Hanks maneja su patineta. ¡Se ve tan natural! Es muy entretenido verlo/a. Además, lo consiguen a una velocidad cegadora. Saben cuánto tomará cada problema, y no se detendrán por buscar cuál es la mejor solución del mundo con múltiples threads y capas para escribir un juego de pong. Lo errores no existen porque ellos escriben pruebas unitarias para ellos mismos, y solo codifican en sus sueños. Estos chicos valen lo que pesan en ORO.

2. Interpretación del problema.
Hay un problema con millones de formas de resolverlo. Algunas personas son solamente pensadores rápidos y pueden salir con múltiples soluciones instantáneamente. Sin embargo, lo que un gran desarrollador haría es definir totalmente el problema antes de hacer cualquier cosa. Un gran desarrollador escribirá un documento o pizarra con el problema. Ellos enviarían un correo electrónico a su gerente y dirían cosas como "¿Podemos tener una junta para que le pueda explicar cómo entiendo yo el problema?" Luego ellos comienzan dando varias soluciones, etc.

Vea, un gran desarrollador conoce que la forma en la que ellos ven e interpretan el problema, probablemente no es la forma en la que el creador del problema quiso que fuese entendido. Este es un punto importante, ten eso en mente. Un gran desarrollador buscará entender completamente el problema antes de intentar proponer una solución. ¿Entiendes el problema al 100%? ¿no? ¿99%? ¡Ve, haz más preguntas y asegúrate que está 100% claro!

3. Cómo se aborda el problema
¿Una vez que tengas claramente definido el problema, solo comienzas a codificar? ¡Error! Un gran desarrollador mirará la disposición, y comenzará a pensar en varias opciones, y basado en el problema, pensará en el mejor enfoque para resolver el problema. Yo veo esto como un juego de ajedrez; puedes saber cómo se mueven todas las piezas, conocer todas las reglas del juego, ¿pero sólo comenzarás a mover las piezas? ¡Claro que no! Debes analizar el tablero, crear tu plan de juego, mirar a tu oponente, y ver qué es lo que él o ella hace usualmente. Es el mismo caso cuando abordas un problema.

Observa el problema, imagínate cómo necesita ser el resultado, el tiempo del que dispones, la calidad que se espera, las herramientas de las que dispones para trabajar, etc. Entonces, comienzas a resolver el problema.

4. La confianza en el código
Como gerente, cuán confiado puede estar en sus códigos. Puede decirle a algunos desarrolladores "Necesito esto completamente para el Viernes" y llega el viernes, recibe un email diciendo "He revisado el código en el branch y está listo para las pruebas" y tú sabes que el equipo de aseguramiento de la calidad encontrará muy pocos errores, o ninguno. Por otra parte, hay algunos desarrolladores que en lugar de eso le enviarán un email diciendo "Aún no he terminado, estará listo para el Lunes a primera hora en la mañana." Y estás 95% seguro que estará plagado de errores, y que no será utilizable durante días, sino es que semanas, hasta que los errores sean eliminados completamente del código.

Resumiendo: ¡La más alta fiabilidad que puedes tener de los desarrolladores, es que están muy cerca de ser grandes desarrolladores! Imagínate siendo tu manager, y el peso que quitas de su hombro si no tiene porqué preocuparse por tu código.
5. Confianza en la solución
Una cosa es sentirte confiado en el código. Si tienes a un gran desarrollador en tus manos, estás confiado en la solución. Los grandes desarrolladores serán grandes arquitectos. Ellos son capaces de analizar el problema entero, e imaginarse cómo necesita ser solucionado el problema. Ten en cuenta que no es solo codificar con código grandioso, !se trata también y principalmente de la arquitectura que le das a la solución! Este es un punto importante, y que realmente separa a los buenos desarrolladores de los grandes en el mundo del software.

6. Satisfacer los requerimientos del usuario
Al final del día, puedes tener el mejor código, y la mejor solución posible, con toda la mejor arquitectura, ¿pero logra satisfacer los requerimientos del usuario? ¡Posiblemente no! Y has fallado completamente. Ahora, hay varios grados de falla, pero un gran desarrollador dará en el blanco consistentemente. Ellos encuentran lo que el usuario necesita exactamente, crean una propuesta, le muestran al usuario lo que obtendrán paso a paso durante la marcha con ediciones semanales sin errores, y seguirán la construcción desde la última versión. ¡Los requerimientos están justo como deben estar y el usuario baila de contento!

7. Mantenerse actualizado
Los grandes desarrolladores están actualizando constantemente sus habilidades independiente y proactivamente! Tienen sed de nuevos conocimientos y perfección como un gato con la leche. No esperan a que su director venga a darles tareas, les ofrezcan tomar cursos, o les den libros para ser más eficientes. ¡Ellos van y consiguen esas cosas por sí mismos!

Encuentran las conferencias a los que quieren asistir, y envían correos electrónicos como "Estaría encantado de ir al Tech-Ed este año. Aprenderé [insertar razones aquí], y estaré capacitado para contribuir a [insertar proyectos aquí]. He hecho provisión para ahorrarles [dinero/razones métricas aquí]. ¿Si fuera posible, la empresa me ayudaría a pagar el viaje?" Si alguien me enviara esto, no solo le podría ayudar a pagar, ¡sino que le pagaría el viaje entero!

Los grandes desarrolladores acuden siempre a los grupos de usuarios, como un grupo de usuarios .net por ejemplo, o un grupo de usuarios Java. Asisten a los encuentros locales, y hacen lo que sea para alimentar su cerebro. ¿Has leído todos los últimos blogs y revistas? Haz una lista con tus 5 blogs de desarrollo favoritos. ¿Puedes hacerlo? ¡Deberías poder hacerlo como si fueran actividades de un club de boy scouts! Actualízate, esto abrirá tu mente, tendrás la siguiente gran idea y serás recompensado.

8. Contribuye al equipo
Puedes ser uno de los mejores, o aún el mejor programador, arquitecto y más brillante chico en el equipo, pero en lo que a mí respecta, sino estás dispuesto a compartir y contribuir con tu equipo, estás perdiendo la mitad de tu valor, sino es que más. Un gran desarrollador hace grandes a los otros alrededor de él. fíjate, un buen desarrollador consigue ser cada vez mejor, pero no comparte el conocimiento que obtiene, o cómo lo obtiene.

Aprende nuevas cosas, aprende acerca de las nuevas tecnologías, pero no deja que otros sepan de ellas. Un buen desarrollador termina sus proyectos a tiempo, pero cuando la presión es mucha, no está allí para su equipo. Un gran desarrollador está en contacto con todos los proyectos que tiene el equipo y está listo para ayudar cuando se necesite. Ellos dirán cosas como "Me enteré que el equipo A está trabajando en [proyecto], y creo que puedo ayudar, ¿no crees?"

9. Haz grandiosas actas de juntas
Esto es increíblemente importante! No hay peor cosa que llamar a una reunión, tomar tiempo para explicar nuevos conceptos, nuevas ideas, lluvia de ideas, venir con grandes diseños, y no tener nadie que tome notas de las reuniones. Incluso si tienes a alguien designado para esto, quisiera ver a todos con pluma y papel (de preferencia la notebook del desarrollador). Un gran desarrollador hace grandiosas actas en las reuniones; escribe todos los acuerdos de la reunión, y al final de los encuentros puedes escucharlo decir "Entonces solo para confirmar, mis tareas son: . ¿Me falta algo?"

Luego, un gran desarrollador enviará el acta a su manager, listando la fecha de la reunión, el tema, y quién lo atendió. Siguiendo esto, tendrás las tareas en la parte superior, con el abanderado de la tarea. Bajo eso, encontrarás las notas detalladas de la reunión. Un buen desarrollador no toma notas de las reuniones, dice 'Si' cada vez que agregas una tarea a su lista... y espera que su memoria le funcione bien. Luego te envía un email para revisar sus cambios, y te molestas cuando ves que se le olvidaron algunas cosas, pero obtuvo el 90% si está bien. ¡Este es un enorme desperdicio de tiempo! Y sin ninguna razón. Toma grandiosas actas de reuniones.

10. Esté dispuesto a aprender y aceptar críticas constructivas
Si has leído esto, entonces estarás tomándolo todo e intentarás implementar alguna de mis sugerencias en tus labores de desarrollo diarias. Mira, otra área importante es la habilidad del desarrollador para aprender de otros, y aceptar críticas. Sé una persona dispuesta a aprender, debes ser como una esponja, y absorber enormes cantidades de conocimiento rápidamente! Tu jefe está allí por alguna razón. Seguro, ellos pueden ser unos programadores a la antigua, pero también estuvieron en las trincheras, y han estado en cientos de batallas, y tienen heridas y miedos. Ellos tienen el instinto para hacer grandes decisiones, y hacerte grande. Están en la posición en la que están porque quieren verte tener éxito, y desean hacerte crecer.

Por supuesto, este es el entorno de trabajo ideal, pero eso puede pasar donde tú quieras si eres un gran desarrollador. Te garantizo absolutamente, y te prometo, que lo mejor es cultivar esta habilidad, hacerte extremadamente enseñable, tomar notas de las sugerencias y críticas, y ponerte el objetivo de mejorar, y es la mejor oportunidad para convertirte en más de lo que te hayas imaginado posible. Si por otra parte, escoges pensar de tí mismo como "la élite", y que no tienes más que aprender, siempre estarás estancado en donde estás. Si no estás creciendo, ni siquiera estás en el status quo, estás muriendo! Crece!

11. Siempre disponible cuando se necesite.
Esto es dar y recibir. Si trabajas para una gran empresa, ellos serán flexibles contigo. Nunca deberían preguntarte acerca de las horas de cita con el doctor que no pudiste programar después de las horas de trabajo, por la hora de entrada o de salida, o tu hora de comida. Ellos deberían animarte a ir al gimnasio a la hora del almuerzo, pagar por las comidas cuando sales con el equipo, etc. Deberían darte algunos días libres después de algún día o proyecto pesado. Y la lista sigue y sigue.

Sin embargo, con todas esas ventajas, vienen responsabilidades, inexcusablemente! En momentos difíciles, un gran desarrollador te sugerirá que el vendrá el fin de semana si se necesita. Se queda hasta muy tarde como sea posible y tan tarde como se necesite para asegurar que el trabajo se termine. Escucha, los grandes desarrolladores toman responsabilidad de sus creaciones. Ahora, claro que esto no es necesario, pero esta es la marca de un gran desarrollador. Algunas personas solo quieren trabajar sus 8 horas diarias, y ser buenos desarrolladores, pero ellos nunca serán grandes. Los grandes desarrolladores están con los jugadores del equipo hasta el final, y ven su trabajo como un arte, y a su equipo como una familia.

12. Vestir profesionalmente a diario
Nunca sabes cuándo puede venir un cliente a una visita. Nunca sabes cuándo serás llamado a una junta, ya que no todo es planeado. Y cuando ese momento llegue, debes estar listo para el baile! Un buen desarrollador viste ropa normal de lunes a viernes, incluso con jeans negros, y tenis que parecen zapatos de vestir. Un viernes casual lleva shorts, tenis, y una playera. Cuando la visita llega el viernes con una nueva cuenta enorme, no puedes llamarlo para ir a una comida porque él no está vestido apropiadamente.

Un gran desarrollador viste ropa de negocios de lunes a viernes. Ellos visten para tener éxito. Claro, si no tienes habilidades, no serás ascendido a manager o líder de equipo solo porque vistas muy bien. Pero si tienes grandes habilidades, y vistes de traje y corbata, entonces te has catapultado de rango, no se puede negar. Los 400 dólares que gastaste en un conjunto decente y corbata te será devuelto con los años. ¡Te lo prometo!

13. Habilidad de comunicación
Esta es otra categoría crítica! Hay muchos buenos desarrolladores allí afuera, pero no hay muchos grandes desarrolladores, ¿Por qué? Porque todos los buenos desarrolladores son terribles comunicadores. Hay varios niveles de comunicación, desde un correo electrónico hasta encuentros SCRUM, todas las formas de reuniones ejecutivas y tu habilidad para contribuir en un nivel ejecutivo. Tú llegas a ser "El show" cuando te presentas a cientos de personas para mostrarles el nuevo software. Si bien no es necesario llegar a las etapas finales, debes al menos estar dispuesto a comunicar tus ideas clara y efectivamente en las reuniones. Mientras mejor sea tu comunicación, más lejos llegarás.

Resumiendo: Si quieres ser un ejecutivo, debes tener un 9 o 10 en comunicación. Aun cuando tomes notas de las reuniones, o envíes reportes de estado, necesitas comunicarte extremadamente bien. No digas solo "Arreglé el error 1371" en tu reporte diario. Expláyate; explica cuán complicado fue resolver el problema, cuánto tiempo te tomó, o cómo lo resolviste rápidamente. Explica la tecnología que usaste, y porqué estás seguro que el problema no volverá a suceder. Tus reportes de estado no deberían ser algo malo que no te guste hacer. Los reportes deben ser una parte emocionante de la semana donde consigues mostrarle todo a tu manager.

14. Objetivos en cuanto a habilidades
Los buenos desarrolladores pueden hacer las cosas e ir haciendo diariamente lo que les digas que hagan. Realmente no ven a futuro y tampoco saben lo que quieren estar haciendo dentro de uno, cinco o 10 años. Algunos buenos desarrolladores saben lo que quieren... pero no tienen un plan real para conseguirlo. Un gran desarrollador tiene sus metas fijadas para un año, los siguientes cinco años, y sabe también dónde estará en 10 años.

Los grandes desarrolladores además lo llevan a otros nivel, no solo piensan en sus objetivos, sino que también los visualiza. Pueden ver exactamente lo que estarán haciendo dentro de cinco años, y el nivel en el que lo estará haciendo. Y todavía más, un gran desarrollador crea un plan detallado para su siguiente año, lo completa con cursos que tomará, proyectos que completará, y relaciones que construirá.

15. Habilidades organizacionales
El componente final que realmente conjunta todo es la organización. Puedes ser el mejor desarrollador en el mundo, pero si no eres organizado, caerás y te hundirás. Eventualmente te abrumarás y finalmente te hastiarás. Los grandes desarrolladores mantienen un escritorio extremádamente limpio, cuidan sus laptops y escriben claramente. Anotan constantemente en su calendario de Outlook sus tareas y reuniones. Tiene un apartado en la bandeja de entrada para acordar con mensajes de correo a reuniones y nuevas asignaciones. Mantienen carpetas de archivos y pueden sacar instantáneamente proyectos, notas de reuniones y otros detalles cuando se les pida que lo saque.

Bonus Tip: Pasión!
Uno de los miembros de mi equipo leyó la entrada y me recordó algunas cosas que todas las personas simples en mi equipo tienen. Pasión! Sin pasión en los que haces a diario, no serás un gran desarrollador, o grande en niguna cosa. Esto es también la principal razón por la que las personas no tienen éxito. Un desarrollador apasionado superará al mejor desarrollador técnico si éste no se apasiona por su trabajo, su rol, y su proyecto. Piensa en esto, si has leido hasta aquí, ¿estarás haciendo un esfuerzo para hacer los cambios que he listado? Parece simple, pero sin la pasión para hacer esas cosas, realmente te comprometerás hoy y tendrás éxito?

¡Entonces ahí lo tienes! Esos son los punos principales con los cuales evalúo a mi equipo de desarrollo durante las revisiones de los procesos. Pon atención, proveo a los miembros de mi equipo del mejor entorno como me es posible, y por lo tanto espero que sean grandes desarrolladores, o si tú mismo eres un desarrollador, por favor usa esta lista para hacer los cambios que sean necesarios, y catapulta tu carrera y la de tus compañeros.
Sigue estos consejos, y obtendrás el escenso que buscas, el aumento de salario que estabas esperando, y sobre todo estarás feliz con tus logros. Inténtalo y cuéntanos de tus resultados en los comentarios de abajo. Me agradará escuchar de tí. ¡También si tienes otros puntos que creas que deberían ser agregados, hazmelo saber!



Traducido del original en Real World Software Development

Después de haber leído esto, me puse a reflexionar seriamente sobre mi estado actual como desarrollador de software. Soy fuerte en algunos puntos, pero muy débil en otros.
En cualquier área de desarrollo de software en la que te encuentres, ¿cómo te catalogas? ¿Te has propuesto mejorar?

Devolver el orgullo al nombre de "programador" para solucionar el déficit de programadores

miércoles, 30 de julio de 2008

Hace unas semanas atrás discutíamos en el foro de mi facultad acerca de las diferencias entre los títulos de "programador" y "desarrollador". En este foro comentaban maestros y alumnos acerca de esta distinción, entre los comentarios más frecuentes se encontraban que el programador simplemente codifica y el 'desarrollador' analiza, planifica, codifica y muchas otras cosas más. Esto me hace recordar la etapa del desarrollo de software de manera artesanal que tomó fuerza a finales de los 60's. Sin embargo, desde ese entonces, el desarrollo de software ha avanzado, aunque a pasos lentos que actualmente aun se sigue produciendo software a manos de técnicos y programadores artesanos.

Enrique Dans menciona el problema de la desvalorización de los programadores en su primer artículo referente al tema en Libertad Digital:

...el programador es considerado una especie de "obrero especializado", y sometido a una economía de salarios bajos, inestabilidad laboral, elevada rotación y fuerte incidencia de estrés.
Esta es la consideración que se tiene, cuando debería ser otra muy distinta.
Ser programador es un trabajo creativo, un papel indispensable en la economía de hoy que merece muchísimo respeto y que genera un elevado valor. Sin embargo, ¿dónde están los programadores? ¿Por qué no salen de las universidades, dispuestos a convertir esa hiperabundancia actual de ideas en código y a participar en esa revolución consistente en crear tantas actividades en el seno de la red? ¿Qué profesionales están generando las carreras de Informática o algunas Ingenierías, y por qué tienden a rechazar la idea de programar como si fuera un estigma o algo típico de obreros especializados?

En España, a este lado del túnel, se necesitan programadores. Y los programadores necesitan una reivindicación urgente de su profesión, que recupere el legítimo orgullo de quien crea, de quien desarrolla, de quien se responsabiliza de un todo, de quien se enamora de un proyecto y no se limita a ser un obrero en el mismo, sino un verdadero arquitecto. Se buscan programadores con orgullo y capacidad para serlo. Pero por lo que se ve, habrá que mirar debajo de las piedras.


Y México no escapa de este problema. Sumado a esto está la deserción de los estudiantes en las carreras de informática y sistemas computacionales, y las matrículas se reducen cada vez más. Como señala Emilio Osorio en la revista Software Gurú:
El desarrollo de software atrae cada vez a menos jóvenes, y muchos de estos cambian de carrera antes de graduarse... Mucho se ha hablado de las causas de esta crisis, algunos culpan a la falta de profesionalismo y experiencia real de los maestros, otros, al mal ejemplo que damos los que somos parte de esta industria: nuestras jornadas de trabajo, niveles de estrés y costumbres geeks no son muy atractivas para jóvenes de 18 años que sólo se quieren divertir.
Leyendo más acerca de porqué se ha infravalorado el título de programador he encontrado varias perspectivas. Una de estas alude a la poca importancia que le dan las empresas y casas de software a los programadores, viendo en ellos a simples máquinas mecánicas a los cuales se les dan unos planos de la construcción de un determinado software y produce código que hace lo que el analista le ha planteado. Tal como lo menciona Enrique Dans hablando acerca de la concepción común de un programador en la publicación de altianews de septiembre de 2007:
...mientras en nuestro entorno, la palabra “programador” define un trabajo de baja cualificación, casi mecánico, asociado al traslado de las especificaciones de un analista en líneas de código ejecutables por un ordenador, lo que las empresas necesitan no es eso, sino una noción más moderna del término: la de un profesional mucho más autosuficiente, con conocimientos de ingeniería del software, teoría de la computación, matemática, algorítmica e incluso nociones de estrategia de negocio, que desempeña una actividad de elevada cualificación y responsabilidad. Enrique Dans: “Programadores: cuando falla la base”
Otra de las rezones se da en el artículo mencionado son las instituciones académicas, ya que los profesores influyen en gran manera en los alumnos a despreciar el puesto de programador.
...mientras los profesores en las Escuelas Técnicas, insistiendo en el error y manifestando una clara incapacidad para formar a ese tipo de profesionales, se afanan en convencer a sus alumnos para que huyan de la programación como de la peste.
Ricardo Galli, creador de Menéame, también menciona este problema en su antiguo blog:

...más del 70% de los alumnos de las ingenierías informáticas están completamente desmotivados y/o desinteresados por su carrera, especialmente la programación.

Quizás se debe a que durante muchos años de habló que era la “carrera del futuro”. Quizás también se deba a que ser un buen programador es cada vez más difícil y que obliga a un esfuerzo intelectual muy importante. Quizás también se deba a la “falta de perspectiva” de cómo es la profesión en los centros importantes: mucho esfuerzo pero a la vez mucha autoconfianza y coraje.

Seguramente los profesores tenemos parte de esas culpas. Conozco a muchos que piensan que un “ingeniero no necesita programar”, conozco también a muchos que ya no se acuerdan de cómo se programa. Pero también conozco a muchos profesores que son unos monstruos programando y dando clases, pero esos justamente son los más “odiados” o ignorados por esa gran mayoría de alumnos que sólo desean aprobar las asignaturas de la forma más sencilla, segura y sin liarse demasiado el coco. Así muchas veces terminan festejando al profesor que les cuenta batallitas por que así sí que aprenden “cosas prácticas” y útiles.

Pero sí, los profesores –incluido yo–, somos parte importante del problema

Aunque los artículos hablan acerca del problema en España, en México he visto el mismo problema en mi propia universidad, tal vez no de forma tan extrema, pero si intentando convencer a los estudiantes de buscar un "nivel más alto" como lo es el Ingeniero de Software o "Desarrollador", los cuales según la concepción generalizada, programan menos y están más arriba en la escala jerárquica empresarial.

Otro problema son los sueldos de los programadores, que como ya he mencionado antes, las empresas desvalorizan la labor del programador, así que pagan bajos sueldos. Sin embargo, a estos mismos les urgen programadores.
...la empresa cree que necesita programadores a la vieja usanza, y pretende pagar dos duros a quienes son, en realidad, profesionales capaces de destilar ideas en código y convertir el proyecto en realidad. Y ante semejante estímulo, los profesionales simplemente rehuyen la confrontación y buscan otras metas. Y es que pasar de obrero a arquitecto no sólo requiere un nivel superior de cualificación. Supone, además, que existan incentivos para ello.
A diferencia, otros se arriesgan a opinar que no es que falten programadores, los hay, lo que hace falta es motivación. Se refieren a la motivación del programador, pero esto no es sino un reflejo de lo que tales programadores han aprendido durante su carrera y de la manera en la que ven el puesto de programador. Aunque lo que menciona Jordi Abad en su blog es muy cierto:
...el trabajo de programador está asociado a la base de la estructura jerárquica de una empresa. Esto implica: bajos salarios, mala reputación y comerse muchos marrones de las capas superiores de la pirámide. Es un trabajo muy poco agradecido. A pesar de ello se trata de un trabajo necesario e imprescindible por parte de una empresa que se dedica a programar software.
Ricardo Galli propone además sus propios puntos de vista referentes a las causas que generan estos problemas:
  1. Las empresas grandes que pueden pagar bien a los buenos programadores tienen obsoletas estructuras piramidales que lo único que logran es quemar a los buenos programadores en menos de un año.

  2. Las puntas de esas pirámides suelen ser aquellos que no quieren saber nada de programación y se dedican a ascender, delegando toda responsabilidad a los “analistas senior”, que a su vez delegan y culpan a los “analistas junior” y así abajo en la cadena hasta llegar al buen programador que está a punto de dejar porque ya está quemado.

  3. Empresas grandes que venden carne de ingenieros al kilogramo pagando salarios de becarios y haciendo verdaderas chapuzas porque al final nadie es el responsable. ¿Alguien recuerda al web del Congreso y tantas otras administraciones por ejemplo?.

  4. Las administraciones y grandes empresas, como tienen problemas en mantener a sus buenos programadores (por 1 y 2), contratan ingenieros al kilogramo a las que se dedican a venderlos.

  5. Las empresas pequeñas buscan programadores “básicos”, que sepan un poco de Visual Basic, con suerte Java, y montón de otras cosas como instalar MS Office o “un servidor Linux”.

  6. Muy pocas empresas tienen asumido que sus programadores requieren un entrenamiento inicial especializado en lo que va a hacer –que no puede brindarle ninguna universidad o ciclo formativo– y que esos programadores también necesitan una formación continua –vía cursos específicos o tiempo y tranquilidad necesario para trabajar en proyectos con técnicas y métodos más modernos y diferentes–.

  7. El problema de la disfunción metacognitiva, muy generalizada entre los informáticos.

  8. Existe una especie de presión a las universidades para que “formen profesionales adecuados al mercado del trabajo”. Ese mensaje ha calado profundo en muchos profesores, pero aún más entre los alumnos que exigen que se les enseñe Java desde primero –y nada más que Java– porque es lo que demanda el “mercado laboral” y que hace que pasen olímpicamente de otras asignaturas que marcan diferencias, por ejemplo álgebras o conceptos complejos de la “ciencia de la computación”.

  9. Quizás por #6, muy pocos programadores dedican tiempo a leer, aprender y navegar mucho por Internet, que se ha convertido en la fuente principal y fundamental para aprender las nuevas técnicas, tendencias y formas de llevar adelante proyectos. Existe una especie de sentimiento generalizado –que todavía no puedo comprender, con lo guapa y divertida que es la informática y programación– de “en mi poco tiempo libre me olvido del ordenador”…

Como bien lo ha dicho, he visto mucho de esto con mis compañeros de clases y colegas de trabajo. A muy pocos de ellos les llama verdaderamente la programación y muy pocos leen y se mantienen actualizados. En la región sur de México existen muy pocas empresas especializadas en desarrollo de software, y los que están, ofrecen bajos salarios y no tienen mejores prácticas de desarrollo. A esto también me quiero referir, a la centralización de las empresas en el Edo. de México, Monterrey y Guadalajara. Esto provoca que muchos jóvenes con deseos de superación y con grandes capacidades pierdan de la oportunidad de poder desarrollarse profesionalmente ya que vivien en otros estados.

También quiero citar a una publicación de
BusinessWeek en donde señala una importante consultora acerca del déficit de talentos en la India para el 2010.
Building showpiece campuses the size of many U.S. colleges is just one way big Indian employers are battling to hold on to budding engineers, designers, and finance specialists... Today, companies face high turnover, escalating salaries, and shortages of qualified workers and managers. Less than a quarter of companies surveyed in 2006 in India by McKinsey & Co. said they were meeting recruiting needs. By 2010, McKinsey predicts, India will face a shortfall of 500,000 staff capable of doing work for multinationals.
Con este problema en puertas, las empresas Indias están necesitando trabajadores para las multinacionales y atrayendo mano de obra de los países vecinos y de América Latina, con lo que deberemos afrontar más rápidamente este problema. Menciono esto porque, debido a los sueldos de un programador en México en comparativa con otros países, parece ser que hace falta concientizar de la importancia del programador, el cuál es la parte más activa e importante de una empresa. Como bien dos programadores crearon Google, Microsoft y Apple. En salarios, los programadores mexicanos se encuentran en el lugar 20 de los países con mejores sueldos (tablas de salarios en México), justo debajo de España y Corea, ocupando Hong Kong y Suiza los pirmeros puestos.

Parte de la solución reside en el cambio de mentalidad del profesorado y del gobierno. Por ejemplo, en Argentina, según el periódico La Gaceta, se está diseñando un programa de becas para las carreras de TI y así poder incrementar el número de matrículas y reducir las bajas para lograr afrontar los nuevos programas económicos del país.
El flamante programa contempla la entrega de 6700 becas, con una inversión total de 52 millones de pesos para el período 2009-2013 que serán destinadas a jóvenes de todo el país que estudien en universidades nacionales.
Las becas serán destinadas a quienes estudien las carreras de Ingeniería Electrónica, Ingeniería en Telecomunicaciones, Ingeniería en Computación, Ingeniería Informática, Ingeniería en Sistemas de Información, Licenciatura en Informática, Licenciatura en Análisis de Sistemas, en Sistemas y en Ciencias de la Computación.
Cambiando la mentalidad de los empresarios (los de más alto nivel jerárquico) , la academia, y estrechando la brecha academia-sector productivo es como se logrará incrementar nuevamente las matrículas en las carreras de TI y mejorar la economía nacional con base en el conocimiento.

Para finalizar quiero recomendar y citar una
entrevista al Dr. Carlos Montes de Oca en Software Gurú:
...el dueño de una fábrica de coches sale a las 6 de la tarde, y ahí tiene su fábrica, con su valor intacto; puede venderla y recuperar su inversión. En cambio, el dueño de una fábrica de software, a las 8 de la noche que sus empleados ya se fueron a su casa, está descapitalizado. Lo único que tiene son escritorios y unas máquinas depreciadas.
No perdamos el orgullo de ser programadores, las empresas están cambiando a darnos mayor importancia porque nos necesitan. Y no pretendamos llamarnos Desarrolladores (Developers) solo porque la gente que no programa crea que es un nivel más alto.

Creando un User Control con VB.NET 2005

domingo, 6 de julio de 2008

Actualmente estoy mejorando una aplicación de escritorio que hice para los chicos de las materias de Contabilidad I y II de las carreras de Contaduaría y Administración. Esta aplicación usa una ventana para crear asientos de diario, creando y quitando registros, cuentas y asientos. Al final, con un solo clic generan los esquemas de mayor, balanza de comprobación, balance general y rayado diario y se exportan a Excel. Pues durante el upgrade me encontré nuevamente con la dificultad de dar al usuario la facilidad de agregar y quitar registros visualmente, porque en la primera versión estuve modificando manualmente todos los tamaños y posiciones de decenas de controles que tenía en la ventana de trabajo. Lo que hice en esta segunda versión fue diseñar un control personalizado (User Control) llamado ControlAsiento.vb que contiene a otro User Control llamado ControlRegistro.vb, los cuales me facilitaron la vida.
Para este pequeño tutorial estaremos consider
ando Visual Studio 2005, usando VB.

¿Qué es un UserContr
ol y para qué sirve?
Un User Control no es más que una clase común .vb que también provee las referencias para poder trabajar con las clases dentro del espacio de nombres System.Windows.Forms, a diferencia de los Class Library, que es buen tema para otro post. Con los User Control podemos crear controles más complejos o avanzados derivados de los controles que ya nos proporciona el IDE, tal como veremos más adelante con un ejemplo. Aquí les muestro paso a paso cómo crearlos y usarlos. En el siguiente ejemplo haremos una pequeñísima parte de lo que tuve que hacer para la aplicación que estaba desarrollando, esto es poder generar en tiempo de ejecución nuevas instanacias de los controles que vamos a diseñar y programar.



¿Cómo se hace?

1. Después de abrir el IDE de Microsoft Visual Studio 2005 y empleando el lenguaje Visual Basic, creamos una nueva Aplicación de Windows como comunmente. Yo he llamado "Ejemplo1" a mi proyecto.




2. Cuando se crea nuestro proyecto nos presenta un nuevo formulario vació para comenzar a trabajar. Pues bien, lo que haremos será agregar un
User Control a nuestra aplicación. En el explorador de soluciones (Solution Explorer) desplegaremos con un clic derecho sobre el nombre de nuestra aplicación una ventana emergente donde seleccionaremos la opción Add > User Control.


3. Nota que al abrir la ventana de diálogo está seleccionado el tipo de control User Control. Le daremos un nombre a nuestro nuevo control, en nuestro caso será ControlRegistro.vb. Este será el control de más bajo nivel, es decir, el último que solo contendrá a controles predefinidos por Visual Studio.





4. Podremos ver un nuevo lienzo que no contiene barras de título ni bordes, en el cual comenzaremos a diseñar nuestro control.





5. Para el ejemplo solo programaremos un botón en cada
User Control, aunque esto vendrá después de haber diseñado todo lo demás.






6. Habiendo temrinado con el diseño de ControlRegistro, crearemos
entonces ControlAsiento, que contendrá una cantidad indeterminada de registros. Para esto procederemos de la misma forma en la que creamos ControlRegistro. En el explorador de la solución (Solution Explorer) desplegaremos con un clic derecho sobre el nombre de nuestra aplicación una ventana emergente en la que seleccionaremos la opción Add > User Control y lo nombramos ControlAsiento.vb, y procederemos a hacer el diseño de la interfaz. Para esta interfaz necesitaremos agregar al menos un control del tipo ControlRegistro que hemos creado, sin embargo no podremos acceder a este control en la Caja de herramientas mientras no hayamos reconstruido la aplicación para que las modificaciones en ControlRegistro tomen efecto en los lugares en los cuales se haya usado. Hasta ahora no lo hemos usado y para esto también necesitaremos reconstruir. Seleccionamos en el menú principal Build > Rebuild Ejemplo1.





7. ControlAsiento tendrá el siguiente aspecto.








8. Al temrinar el diseño debemos reconstruir nuevamente la aplicación de la forma que ya hemos mencionado, entonces podremos ver nuestro control en la caja de herramientas.




9. Finalmente tendremos el siguiente aspecto en nuestro formulario principal Form1.












Pues bien, ya hemos diseñado nuestros controles, solo falta darles vida, para esto pondremos fragmentos de código en ControlRegistro, ControlAsiento y Form1.

*** Form1 ***

Public Class Form1
Dim asiento As ControlAsiento

Sub crearAsiento(ByVal asientoAnterior As ControlAsiento)
' Calculamos la posición del nuevo asiento a partir del asiento anterior, el cual hizo la llamada
' y agregamos el nuevo ControlAsiento al formulario
asiento = New ControlAsiento
asiento.Location = New Point(asientoAnterior.Location.X, asientoAnterior.Location.X + asientoAnterior.Height + 5)
asiento.Label1.Text = asientoAnterior.Label1.Text + 1
With GroupBox1
.Size = New Size(.Width, .Height + asientoAnterior.Height + 5)
.Controls.Add(asiento)
End With
End Sub
End Class

*** ControlAsiento ***
Public Class ControlAsiento
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
' Llamamos al método crearAsiento() del formulario que contiene a este asiento.
CType(Me.FindForm, Form1).crearAsiento(Me)
End Sub

Private Sub ControlAsiento_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
' Es solo un ejemplo de cómo se puede agregar un manejador de eventos a un control,
' ya que en micaso he usado mucho este tipo de manejadores al momento de crear controles dinámicamente
' y tener varias formas de acceder a un mismo evento
AddHandler Button1.Click, AddressOf Button1_Click
End Sub

Sub crearRegistro(ByVal sender As ControlRegistro)
Dim reg As New ControlRegistro
' La separación que agregaremos a la posición del registro y demás controles, y la cantidad que agregaremos al tamaño del GroupBox1
Dim y = sender.Height + 3
reg.Location = New Point(sender.Location.X, sender.Location.Y + y)
' Bajamos también la caja de texto multilinea y los botones del ControlAsiento
redaccion.Location = New Point(redaccion.Location.X, redaccion.Location.Y + y)
Button1.Location = New Point(Button1.Location.X, Button1.Location.Y + y)
Button2.Location = New Point(Button2.Location.X, Button2.Location.Y + y)
' Con Me.ParentForm obtenemos el formuylario que contiene a este control y lo convertimos al tipo Form1, que es la clase que tenemos
With CType(Me.ParentForm, Form1).GroupBox1
.Size = New Size(.Width, .Height + y)
End With
' Agregamos el nuevo control al contenedor correspondiente, en este caso ControlAsiento que contiene al botón que hemos presionado
Me.Controls.Add(reg)
End Sub
End Class

*** ControlRegistro ***
Public Class ControlRegistro
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
' Obtenemos el ControlAsiento que contiene a este ControlRegistro
Dim asiento As ControlAsiento = Me.Parent
' Llamamos a la subrutina que hicimos en ControlAsiento para generar nuevos registros
asiento.crearRegistro(Me)
End Sub
End Class
He resaltado en negritas algunas funciones que son de mucha utilidad para poder acceder a los controles que contienen a nuestros
User Control, y así poder usar propiedades y métodos de estos.
Lo que el código anterior hará será generar un nuevo asiento debajo del asiento que contiene al botón '+' en donde se hizo clic. Y generará un nuevo registro debajo del registro en el que se encuentra el botón '+' en el que se hizo clic.


Como hemos visto, podemos usar
User Control no solo para aquellos casos en los que tendremos que usar un control complejo en varias partes de nuestra aplicación, sino también en casos en los que sea necesario crear dinámicamente algunos controles complejos sin necesidad de rompernos tanto la cabeza, como a mí me pasó.
Espero que les sirva de algo este breve tutorial.

Super Clásico Chihuahua 2008

jueves, 12 de junio de 2008

El 7 de junio pasado fue de grandes bendiciones para mi novia y para mí; estuvimos en el primer Super Clásico en México realizado en el Estadio Olímpico Universitario de la UACH. Con la participación de Indira Lazo, Veronica Leal con música norteña, Pedro Ochoa con música country, Santo Remedio con un poco de rock pop, y coronando con Tercer Cielo y María del Sol, antes de comenzar con Dante Gebel. Al finalizar se presentó John Schlitt vocalista de la legendaria banda de rock cristiano Petra. Fue maravilloso, estuvo extraarchirrequetecontrabendecido. Alrededor de 28 mil jovenes abarrotaron el estadio, aproximadamente 18mil en las gradas y 10 mil saltando, cantando y gritando frente al escenario.

Al llegar a Chihuahua no sabíamos si buscar primero dónde instalarnos o ir por nuestros boletos al estadio, acepté la sugerencia de Jazmin de ir primero al estadio para hacer tiempo antes de buscar un hotel. Fuimos los primeros en llegar esa mañana al estadio, y ahí nos encontramos a la hermana Licha, que nos ofreció su casa, bueno la de su hija, pero terminamos en su casa, jeje. El cuarto tenía dos camas, televisión, cable, comida con los hermanos, puras bendiciones. Los hermanos nos transportaron durante nuestra estancia en Chihuahua.


El día anterior al evento, el viernes 6, no hubo ni una sola nube en el cielo, y el Sábado por la tarde antes del evento el cielo se comenzó a nublar impidiendo el temible calor de Chihuahua, especialmente una gran nube se posó sobre el estadio; y después de finalizar el evento comenzó a lloviznar. La gente estaba haciendo fila desde las 8 de la mañana solo para obtener los mejores lugares, nosotros teníamos lugares VIP que nos regalaron, jejeje, más bendiciones, aunque preferimos irnos hasta abajo en la cancha, al frente del escenario.

Muchas gracias a los organizadores de este gran evento, y a los hermanos Licha y Chuy de la iglesia Amistad Cristiana por darnos hospedaje, tmbn a Miguel por apoyarnos. Aquí algunas fotos del evento...

Jazmín atendiendo la taquilla del estadio
La gente animándose iniciándose el evento
Verónica Leal
Los chicos de Tercer Cielo cantando EnamoradosJohn Schlitt a los 56? años cantando y saltandoDante en el tema de Linaje sanguineo