HAL 9K

Pululan en el mercado diversas soluciones de Business Process Managment ( BPM ) , con distinto grado de prestaciones y mecanismos de licenciamiento, con las cuales se pueden construir proyectos de automatización de procesos, según las preferencias y posibilidades de cada organización. No obstante esa diversidad, es posible, de acuerdo a mi experiencia en el área, extrapolar una serie de principios, normas y prácticas que ayudan a conseguir una implementación menos traumática. Primero empecemos por definir que es BPM y que es solución de BPM ( BPMS ). SegúnWikipedia “ El BPM es el entendimiento, visibilidad, modelado y control de los procesos de negocio de una organización. Un proceso de negocio representa una serie discreta de actividades o pasos de tareas que pueden incluir personas, aplicativos, eventos de negocio, tareas y organizaciones ”. Como vemos, no necesariamente  tiene  que ver con la automatización, sino más bien con una estrategia de visión ...

Hace un buen rato, en la época que el Lotus 123 dominaba en las hojas de cálculo, que leí un excelente artículo que se denominaba: Programación Orientada a Objetos con Lenguaje C. Si, no hay error. No falta un ++ allí. Es POO con el maravilloso lenguaje C. El artículo en cuestión, proponía como utilizar las estructuras de datos y punteros de C para emular el comportamiento de Clases y Objetos. Hacía énfasis en diversas técnicas para aprovechar el encapsulamiento, la herencia y otros principios y conceptos de la POO con el C. Acá un enlace a una publicación que menciona algunas de estas técnicas.

Hace un rato que no echamos algo de código, así que hoy vamos a ver como construir un cliente SOAP sin usar las populares librerías externas de AXIS , CXF o Metro , entre otras que se podrían usar. Esto no es sólo académico. En ocasiones queremos proveer comportamientos específicos, o “tunear” la conexión de modo particular, ganar en flexibilidad y control o buscar mejoras en el rendimiento, y por esta razón nos vemos en la necesidad de efectuar la conexión “a mano” de un cliente SOAP . Asumimos en este artículo que se tienen conocimientos básicos de Java, SOAP , XML , Xpath , Maven , SoapUI y la librería Freemarker . Pare este ejemplo vamos a usar el webservice para CloblaWeater que se ubica en la siguiente url “ http://www.webservicex.net/globalweather.asmx?WSDL ” . Así que manos a las sobras… digo, a las obras jajajaja

Cuando la programación estructurada era la que mandaba en el mundo, y submundos, del desarrollo de software, muchos fuimos los evangelizadores, cuando no creyentes, que proponíamos esta forma de programación y, aún más relevante, sus metodologías asociadas RUP, Waterfall, Etc., como la panacea, la crema y nata, de la construcción de soluciones de software. Pasamos lustros, décadas, en esas lides. Y nos fue bastante bien. Luego vino la programación orientada a objeto (OOP), con sus alternativas metodológicas asociadas, y lo cambió todo nuevamente. Y, como era de esperarse, no faltábamos los nuevos conversos, los profetas de la OOP y de sus métodos, filosofías y procesos. No a pocos, lo que no sonara a OOP les hacía fruncir el ceño, casi les producía arcadas pues!! Vale decir que con la OOP también nos ha ido bastante bien como vendedores de “vaporware” (luego explico el término) que somos jajajajaja…. Y así por el estilo. Programación funcional, Cloud, Quantum… es l...

SOLID es un acrónimo para una serie de principios básicos, 5 en total,  de la programación orientada a objetos ( POO ) y el diseño orientado a objetos ( OOD ) inventado por Robert C. Martin. Estos principios tienen relación con algunos patrones de diseño. Muchos creen que el objetivo de la arquitectura de software, los patrones de diseño y los principios SOLID es programar más rápido. Pero no. La verdad es que el objetivo real es facilitar el mantenimiento de los grandes proyectos de software. Como norma el mantenimiento consume muchos recursos de los destinados a los proyectos de software, hasta un promedio de 77%, por lo que los ahorros en esfuerzos en esta área son cruciales para facilitar el sostenimiento de una plataforma de software o de soluciones de software cualquiera. En forma general estos principios son los que a continuación se detallan…

Era popular entre mis amigos de carrera la expresión “Para qué lo vamos a hacer fácil si lo podemos hacer difícil”, y es esta expresión la que resume el primero de los extremos de los que hablaré en esta publicación. Me refiero al Sobre diseño. Entendiendo como tal la consideración e implementación de estructuras de software con características de funcionalidad, configuración, mantenimiento y usabilidad innecesarias, o totalmente prescindibles, para alcanzar un objetivo o resolver un problema. Imagine que Ud. se encuentra almorzando plácidamente, cuando de pronto es importunado por el zumbido y presencia de una asquerosa mosca volando cerca de su plato de comida. Visiblemente molesto, se dispone a resolver el problema y dar cacería al desagradable intruso. Para ello contrata a tres consultores, con miras a que le propongan la mejor alternativa para resolver su problemática con la plaga voladora. El primer consultor le recomienda usar simplemente sus manos y perseguir y ap...

Recientemente me encontraba trabajando con uno de estos programadores que creen que programar es “echar” líneas de código, y que piensan que conocer un lenguaje de programación los hace programadores como tal. Este individuo en cuestión, incluso parloteaba sobre Patrones de Diseño, más específicamente sobre el patrón de diseño Factory . Cuestionaba este sujeto el uso del patrón Factory a lo largo de un  código. Él no estaba de acuerdo, y decía que uno usa el Factory es “cuando no sabe que clase va a instanciar”, que si sabemos cuál es la clase no debemos usar Factory porque es más lento que la instanciación directa del objeto y además introducimos mucha “indirección”, esa es la palabra que usó,  en el código. Esto sólo demuestra un par de cosas. La primera es que tenemos a alguien que cree que conoce algo. La segunda es que lo conoce MAL. En primer lugar el patrón Factory no se usa porque sepamos o no que clase debemos instanciar. Se usa porque garantiza q...

Corrían los años 80, 1982 para ser exactos, y estaba por estrenarse el que fuera un éxito de taquilla “ET el extraterrestre” de Spielberg. Para ese entonces, la firma Atari quería patear el mercado y recuperar su posición de líder sacando una edición autorizada de un juego para el Atari 2600 basado en la popular película. La tarea le fue encomendada a Howard Scott Warshaw, un experto programador de 24 años de edad muy respetado en Atari para esa época. Atari venía perdiendo su cuota de mercado, por lo que necesitaba que este juego fuese un éxito, razón por la cual no escatimaron en gastos para el lanzamiento y promoción de ese producto. Era por lo tanto un juego estratégico para la empresa. El problema era que debían producirlo con rapidez para aprovechar el lanzamiento de la película, por lo que el tiempo de construcción del juego fue de tan sólo 5 semanas, cuando un juego en esa época requería al menos unos 5 meses. Llego el día del estreno de la película, del respectivo ...