miércoles, 21 de mayo de 2014

Los 6 tipos de Programador



Con 7 años de experiencia, 2 empleos, 5 equipos de trabajo, 
y ya habiendo liderado de 2 de ellos, puedo darme el lujo de "clasificar" a mis compañeros de trabajo en distintos tipos de programadores, según la calidad de su trabajo.



Pero no es sino después de leer un artículo de Steven Benner, en donde describe casi a la perfección a los tipos de programadores con los que uno tiene que lidiar. Si tal vez no son todos, sí que son los más reincidentes:

1. El parchador. (The duct tape programmer)

Puede que el código no sea lindo,
pero maldición, ¡funciona!
Este tipo es la base de tu empresa. Cuando algo vaya mal, él lo reparará ipso facto y dejándolo funcionando correctamente.

Pero -por supuesto- no le interesa nada más:
cómo se vea, la facilidad de uso, el orden del código, técnicas de programación, variables innecesarias, la optimización de algoritmos, el mantenimiento, el uso de estándares, ni otra de esas "trivialidades".

Él sólo "hará que suceda", lo solucionará sin pérdida de tiempo.
La mejor forma de trabajar con él, es enfocarse en un problema y dejarlo trabajar.

domingo, 6 de abril de 2014

Los 9 principios básicos para todo Programador



Hay algunos criterios que un aprendiz de programador no siempre toma en cuenta, por desconocimiento;
o peor aún: que un programador "experimentado" no toma en cuenta por mediocridad negligencia.

Según creo, estos criterios necesitan ser enseñados explícitamente a los newbies y amateurs, aunque también son aprendidos y comprobados durante la práctica; para finalmente, ser aplicados inconscientemente de manera intrínseca por un programador experimentado.

1. Desarrollar código fácil de entender.
Así, se hace código comprensible trascendiendo el tiempo; y no tener que deducir tantas las líneas de código.
Pero eso no es suficiente:
No comentar todo (cada declaración de variables, cada abrir y cerrar de llaves, cada conexión a BD), porque demasiados comentarios irrelevantes quitan atención a los comentarios importantes.
Un buen complemento a los comentarios también es el hacer un código claro y bien definido, no redundante ni aglutinado.
Tal vez cause gracias, pero siendo objetivos: Es egoísta e inmaduro.

2. No complicar el código.
Muchas veces solucionamos algún problema de la forma más enredada por dar una impresión de "soluciones complejas desde una mente compleja". 
O peor aún: porque no queremos dedicarle más tiempo para simplificar la solución.
El arte de la programación está en la abstracción de desarrollar soluciones sencillas para problemas complicados. 
Debemos buscar la forma más simple de resolver las cosas. Esto ayudará a entender el código mejor y a mantenerlo* de una manera más eficiente, haciéndolo menos propenso a errores.

miércoles, 29 de enero de 2014

[Oracle BPM Studio] Error: NoClassDefFoundError en el workspace.log


(*) Este error no aparece en tiempo de compilación -ni de publicación-, sino en tiempo de ejecución:
Empezó con una observación del área de testing (Que luego se tornó más grave porque todos los proyectos recientemente modificados presentaban dicho fallo)
La tarea de la actividad XXXXX no se ha podido ejecutar correctamente.
Y al darle clic a "Detalles >>": 
"Consulte el archivo de registro para obtener más información" y un código de error.

Al consultar dicho archivo (el log de errores, workspace.log), sólo se encontraba una descripción vaga y muy general, y entre un montón de líneas del error no capturado por el WebLogic
Aquí un extracto de dicho log:

jueves, 2 de enero de 2014

Los 10 mandamientos de un programador humilde


Estos mandamientos son un extracto de un libro de Gerald Weinberg, ¡publicado en 1971!:
"The Psychology of Computer Programming".
Y de lo que encontré en mis fuentes, quiero presentar un consolidado de éstas:

martes, 7 de mayo de 2013

[Oracle BPM Studio] 2 minutos para modificar un campo en los Web Presentation


Trabajar con Oracle BPM Studio podría llegar a ser una pesadilla (Al menos, con BPM Studio 10.3).
Y es que frecuentemente aquí publico algunos trucos y soluciones a errores que ocurren en BPM y que no son fáciles de detectar, ni de manejarlos una vez identificados. Y definitivamente uno de sus mayores defectos fue es la pésima asignación/administración de memoria.
Me tomé la molestia de hacerle un vídeo a mi workspace, yo intentando hacer algo tan sencillo como agregar campos mientras edito una pantalla (un web presentation).

Spoiler alert: el Studio se cuelga, no realiza los cambios, si los realiza no los visualiza, o por cada pequeño cambio aparece un mensaje para cancelar ("Stop script") o seguir esperando su ejecución.

viernes, 12 de abril de 2013

[Oracle BPM Studio] Error: La tarea no se ha podido ejecutar correctamente


Para los que todavía desarrollamos en Oracle BPM Studio 10.3, hay mensajes de error que no son nada fáciles de identificar sin la correcta ayuda.
Es un error en tiempo de ejecución a.k.a. "en caliente":
Sea en el workspace local para pruebas -obviamente- locales o en la publicación en los servidores de prueba para testeos oficiales, o ya en producción para el usuario final;
El escenario es el siguiente:
Al aparecer este error, se pierde la actividad y aparece un frame rojo con el mensaje:
"La tarea (nombre de la tarea e id) no se ha podido ejecutar correctamente".
Y al darle clic al botón "Detalles", el mensaje:
"Consulte el archivo de registro para obtener más información [Código de error: workspace-XXXX]" donde XXXX es un valor numérico asignado, y corresponde a una descripción del error que será descrita a continuación...