Grimpi IT Blog

junio 11, 2011

La subjetividad en el desarrollo del software

Filed under: Arquitectura, Opinion — grimpi @ 11:08 pm

Muchas veces tenemos que decidir a la hora de desarrollar la arquitectura de una aplicación, que tecnología, que frameworks, que patrones vamos a utilizar. Muchas veces se generan discusiones en el grupo, porque uno quiere usar algún ORM y otro prefiere ADO.NET directo, o se generan peleas por si usar mocking o no, por alguna metodología sobre otra metodología, etc.
Todas estas discusiones se argumentan del lado técnico y racional. Uno intenta demostrar que el uso de un ORM es mejor por tal y tal motivo. Que este framework es más productivo que tal otro. Que este patrón es más prolijo o no y un largo etcétera.
Y es verdad que muchas veces, no cabe dudas, para escenarios específicos, una tecnología es mejor que la otra. Sin embargo, hay muchas situaciones, donde la elección de una determina forma de hacer software no se debe a un análisis racional de las opciones existentes, sino simplemente a un gusto. Gusto que se debe porque uno tiene más experiencia en esa tecnología, o todo lo contrario, porque no la conoce y le gusta jugar con cosas nuevas, o simplemente gusto porque sí.
Y ahí es donde voy. El elegir una arquitectura de desarrollo porque sí. Jamás, never de los never, un arquitecto, un programador, un líder técnico puede argumentar que es preferible usar una tecnología sobre porque simplemente le gusta más. La subjetividad en el mundo de desarrollo está terminantemente prohibida. Se supone que es una ciencia exacta y que por tal motivo, no podemos dar lugar a la irracionalidad. El sentido común epistemológico de un programador en general es bastante ingenuo en ese aspecto. Sin embargo, la subjetividad está presente en las ciencias exactas. Fue Thomas Kuhn en su tesis sobre los paradigmas y las revoluciones científicas, el primero en sostener que los elementos subjetivos tienen un papel fundamental en la elección entre teorías científicas rivales.
Muchas teorías científicas se imponen simplemente por consenso entre un panel de científicos influenciado por el contexto político e ideológico del momento.
Ejemplo: El feto es un ser humano? Y la realidad es que un científico ateo va a dar una respuesta y un científico católico, va a dar otra respuesta completamente distinta. Ambos argumentaran desde lo racional y técnico. Pero en el fondo, esto no es más que una manera de “racionalizar” una posición política.
Un intento de objetivar la subjetividad.

Y en el mundo de software pasa lo mismo. Acaso un “militante” del software libre diría que tecnológicamente, .NET es superior a Java? Muy difícil.
Muchos podrán sincerar su pensamiento político y decir que prefieren Java porque es open source y punto. Pero otros se enroscaran en una larga
“flame war” para demostrar que tienen razón.
Ahora que pasa cuando la elección de una tecnología ni siquiera obedece a una posición política visible? A nadie se le ocurriría decir que el uso store procedures sobre queries representa una postura ideológica… Y la realidad es que así como muchos prefieren a las rubias sobre las morochas o viceversa, muchos prefieren store procedures sobre querys.
Por supuesto como dije antes, para una determinada especificación funcional o restricción tecnológica, puede haber una clara y objetiva racionalidad en elegir un producto sobre el otro. Sin embargo, hay un universo de situaciones, donde la ventaja de la elección de una tecnología sobre otra es más difusa y ahí entra el conflicto. Ahí es donde se abre una ventana para la del tabú del programador inteligente, para lo que dificilmente pueda reconocer, para la subjetividad mas irracional posible: “el porque si”.

Y como se soluciona esto?
Mal que le pese a un peronista, la mejor opción para estos casos es el diálogo y consenso.

Anuncios

abril 5, 2011

¿El desarrollo de software hoy en día es más productivo que hace 10 años atrás?

Filed under: Opinion — grimpi @ 3:20 pm

La primera aplicación que hice en mi vida profesional, fue una típica intranet para una empresa. Todo el código y acceso a la base de datos, se ejecutaba en archivos ASP.
Luego me dijeron que está mal acceder directamente a las tablas de la base de datos desde el código, por lo tanto implemente store procedures para cada uno de los accesos a la base.
Luego me dijeron que está mal mezclar lógica de negocio y de presentación en el mismo archivo, por lo que implemente la lógica de la aplicación en un componente que era llamado por el ASP.
Luego me dijeron que con eso no alcanza, que hay que dividir la lógica de la aplicación en acceso a los datos y en reglas de negocio, por lo que tuve que crear 2 clases para trabajar con una entidad. Una que acceda a los datos y otra que tenga las reglas de negocio.
Luego me dijeron que había que implementar mecanismos de logueo de excepciones, por si ocurre algún error inesperado. Por lo tanto debíamos utilizar algún framework de logging (porque grabar texto en un archivo x DIA, es algo que requiere un framework).
Luego me dijeron que está mal instanciar directamente el framework de logging desde los componentes, que debíamos abstraerlo a una interfaz, por si el DIA de mañana cambiamos de framework.
Luego me dijeron que está mal tener toda la capa de presentación en solo archivo. Hay que usar el patrón MVC y tener un archivo de vista con el código HTML, una clase controller que maneje el flujo y comportamiento y otra clase modelo. Para eso, debería usar algún framework MVC.
Luego me dijeron que los store procedure son obsoletos, que esta mal poner lógica de negocio en la base de datos y que si el DIA de mañana migramos de base de datos vamos a tener problemas, por lo tanto, debería usar algún framework ORM y crear un archivo XML por entidad que mapee las clases con los datos.
Luego me dijeron que está mal subir todo esto directo manualmente a producción, por lo tanto, deberíamos configurar algún mecanismo de integración continua que baje los archivos del repositorio de fuentes, los compile, ejecute los test de integración y los suba a un FTP o los copie a un directorio. Para esto debíamos crear un archivo de compilando en NANT o MSBUILD o similar.
Luego me dijeron que por cada método que tenemos, hay que hacer test unitarios para verificar que algún nuevo cambio, no rompa el código, por lo tanto, hay que crear una nueva clase de testing por cada clase de negocio, usando algún framework de test unitario.
Luego me dijeron que ejecutar pruebas unitarias que accedan a la base de datos esta mal y es muy lento, por lo cual deberíamos utilizar algún framework de mocking que “simule” este comportamiento, por lo tanto, debíamos modificar los constructores de nuestras clases para que acepten inyección de dependencias y debíamos crear una interfaz por cada clase “mockeable”. Sin embargo, debíamos mantener nuestros antiguos test unitarios que accedían a la base que ahora pasan a llamar test de integración, porque necesitamos una prueba integrada con el resto de los componentes del sistema. Entonces por cada método, ahora debemos crear 2 tipos de test, el unitario y el de integración.
Luego me dijeron que no había razón alguna para utilizar “manualmente” inyección de dependencias existiendo frameworks que hagan esta tarea tan difícil y complicada (sic).
Luego me dijeron que autenticar nuestro usuario directamente contra la base de datos o un servidor Active Directory/LDAP es antiguo e inseguro. Ahora hay que utilizar algún mecanismo de autenticación por claims moderno, seguro y ágil. Por lo tanto, debíamos utilizar algún framework de autenticación como WIF.

Para crear un ABM de clientes, pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación. También debemos crear varios archivos XML de configuración para los distintos frameworks. Por supuesto no hay que olvidarse que debemos también crear clases e interfaces adicionales para los distintos patrones de diseño existentes que hacen nuestro código más elegante, óptimo, lindo, portable, legible, etc. O sea, más PRO.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.

No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.



marzo 11, 2011

Cosas piolas que debería traer la nueva versión de SQL Server:

Filed under: Opinion, SQL Server, T-SQL — grimpi @ 2:13 pm

1) Encriptación irreversible por columna (similar al COLUMN ENCRYPT de Oracle). Ideal para almacenar passwords.

2) Agregar la sentencia CREATE OR REPLACE PROCEDURE/VIEW/FUNCTION como ya tienen Oracle o PostgreSQL. De esta manera, con una sola sentencia, nos evitamos verificar si existe o no una vista, store procedure o una función cuando deployamos.

3) CREATE TABLE NuevaTablaCliente AS TableClienteExistente. La posibilidad de crear una nueva tabla copiando la estructura de otra tabla ya existente es una feature muy piola de PostgreSQL.

4) ALTER COLUMN NombreColumn SET IDENTITY ON/OFF. Habilitar/deshabilitar un campo identity sin necesidad de reconstruir toda la tabla.

5) @NuevoParametro TablaCliente.ClienteId%TYPE. Poder declarar un parametro o variable como tipo de dato de una columna, en vez de declarar explicitamente el tipo de dato como hacemos actualmente.

6) Indíces Bitmap como los de Oracle.

7) Una funcion DECODE similar a la de Oracle (para el que no la conoce, es una especie de CASE…WHEN en una funcion).

8) Que no haya que configurar 50 parametros de Windows y DTC para poder correr una transacción distribuida correctamente.

9) Tener una función de conversión y formateo de datos potente, amigable y facil de usar, y no ese engendro de CONVERT.

10) Una función de SPLIT de string nativa para T-SQL que devuelva una variable de tabla.

11) ALTER TABLE para cambiar el orden de una columna en una tabla. Si bien es un poco “polémica” esta feature (se supone que el orden de las columnas no debería importarnos), la realidad es que a veces termina siendo útil. MySql tiene esta posibilidad.

12) Mejorar el error “String or binary data would be truncated.” cuando insertamos o modificamos datos. En que columna? Que valor fue el que tiro error? Si lo sabes, porque SQL Server no me lo queres decir?

13) Que soporte este tipo de sentencias: SELECT * FROM Clientes WHERE (col1, col2) NOT IN (SELECT col1, col2 FROM OtrosClientes). Actualmente el IN o NOT IN solo lo podemos hacer con una sola columna.

Alguna otra sugerencia?

diciembre 20, 2010

Programando bajo Assumptions Driven Development (ADD)

Filed under: Arquitectura, Opinion — grimpi @ 4:24 pm

Antes de empezar este post, quiero advertir al lector, que el dueño de este blog no está muy de acuerdo con el modo en que se está desarrollando software actualmente. La mayoría de las posturas del autor, son contrarias a las del “mainstream” informático.

Una de las cosas que actualmente se utiliza mucho en el desarrollo de software, son los supuestos. Qué pasa si el día de mañana cambiamos de base de datos? Qué pasa si el día de mañana en vez de escribir en una base de datos, escribimos en un xml? Qué pasa si el día de mañana cambiamos de framework de logging? Qué pasa si el día de mañana nuestro sistema desarrollado para correr en un servidor Windows 2008 debe correr en un celular Android?
En definitiva, planteamos una serie de supuestos posibles cambios tecnológicos o de infraestructura que podría sufrir nuestra aplicación, pero nunca evaluamos la posibilidad de que tal cosa efectivamente suceda. Y estos supuestos no son gratis, porque requieren de capas de abstracciones que agregan más código, necesidad de uso de frameworks y nos limitan nuestras posibilidades.
Es lo que yo llamo Assumptions Driven Development (ADD). Desarrollo a base de supuestos.
Lamentablemente hoy en día, es casi la regla trabajar bajo esa “metodología”, pero cuya importancia esta terriblemente sobrevalorada. El gran mito de la portabilidad.

Si una empresa trabaja hace 10 años con un motor de base de datos especifico, por ejemplo, SQL Server y no hay ningún proyecto a corto y mediano plazo de migrar a Oracle, cual es el sentido de hacer una aplicación especifica para esa empresa que sea portable por si el día de mañana se cambia de motor, sabiendo que es muy poco probable que tal cosa suceda? Y como dije antes, los supuestos no son gratis. Nos limitan tanto en productividad como en performance. Si yo quiero hacer que mi sistema sea portable, entonces estoy desaprovechando muchas características que son propias de una determinada tecnología. Puedo usar store procedures en vez de tener un ORM que me autogenere consultas SQL genéricas, puedo usar características avanzadas de SQL Server incorporadas en SQL 2005 y 2008 que nhibernate o cualquier ORM no soportan. Lo mismo aplica a otros motores. PostgreSQL tiene algo fantástico que son los campos vectores. Es algo muy específico de PostgreSQL y lamentablemente si quiero portabilidad, difícilmente pueda usarlos.
Y no solamente con las bases de datos. La metodología ADD se usa en casi todas partes y junto con la utilización de mocking, es responsable del gran auge que está teniendo los frameworks IoC y la inyección de dependencias. Realmente necesito inyección de dependencias en mis clases para otra cosa que no sea mocking? Realmente necesito crear tantas interfaces para mis clases puedan ser reemplazadas por otras? Puede que sí, depende de las características del negocio y la aplicación, pero si vamos a usar DI solamente para un eventual cambio de librería de logging o de acceso a base de datos, me parece que hay que hacer un stop y pensar nuevamente si realmente vale la pena ensuciar el código con esto.
Porque ese es uno de los costos que pago para ser en muchos casos, innecesariamente flexible. Y la realidad que el uso de tantos frameworks a veces a uno le hace perder un poco el control de la aplicación.
Otro supuesto también muy común, es la escabilidad. Nuestro sistema “debe ser” escalable de antemano, aun si estamos desarrollando un software especifico para una pyme que van a usar 20 empleados. Esto significa hacer uso de estrategias de caching (con su respectivo framework) muchas veces innecesariamente.
La pregunta que hay que hacer es: tiene sentido pensar en portabilidad si la vida util del sistema es de 3 o 4 años maximo? Tiene sentido tanta flexibilidad y portabilidad? Estos supuestos, es común que ocurran? Y la verdad que no siempre sucede.
Y me atrevería a decir, que son minoría.

Por supuesto que si yo estoy desarrollando un software ERP genérico que quiero venderlo al mercado, la portabilidad es una gran ventaja, porque me permite venderlo a clientes que utilicen distintas plataformas. En ese caso, cuando se inicia el desarrollo del proyecto, no queda otra que pensar en portabilidad. Pero la mayoría del software que hacemos en general, no es genérico. Es específico para una empresa particular cuya infraestructura no suele ser migrada radicalmente o es una página web en donde los cambios de arquitectura e infraestructura tienen otra dinámica totalmente distinta y generalmente, cuando se produce un cambio de este estilo, es necesario reescribirla gran parte y no por una cuestión de no haber pensado en estos supuestos cambios, sino porque los casos de uso de nuestra aplicación cambiaron mucho. La vida util de un sistema web suele ser por otra parte mucho mas corta.

Ojo, yo no planteo tirar por la borda todo y no pensar en posibles cambios tecnológicos que puedan existir en la aplicación, pero si tener un poco más de cuidado, evaluar los costos que significan estos supuestos y ver si realmente existe la posibilidad de que tal cosa exista. Dejar de tener miedo en “casarse” con una tecnología y aprovechar al máximo, todas las bondades que ofrece.

diciembre 13, 2008

Un ejemplo de inseguridad…

Filed under: Opinion, Seguridad — Etiquetas: — grimpi @ 1:09 pm

La semana pasada tuve que ir a instalar un sistema en una planta de una empresa de bebidas muy pero muy conocida.
Me sorprendió de sobremanera, la increíble inseguridad a nivel accesos a datos que existe en dicha planta.
Paso a enumerar los horrores bizarros que encontré:
1) El password sa del servidor SQL Server de PRODUCCION era vacio.
2) El password de administrador de todas las PC era el mismo, incluyendo el del Servidor SQL y estaba anotado en marcador rojo indeleble en unos de los monitores!!!.
3) Estaba habilitado el acceso por Terminal Server al servidor de producción (cuya password recordemos estaba anotada en el monitor). No vaya ser que un potencial hacker tenga que tomarse la molestia de tener que ir físicamente al rack de servidores…
4) El usuario administrador del repositorio de reportes (Crystal Reports Server) también era vacio.

Es realmente difícil encontrar un cuadro más patético e inseguro que este. El que instaló todo esto, debía ser un junior y muy vago, porque de otra manera no se explica como un profesional de sistemas sea tan pero tan irresponsable. Como también es terrible que no exista una auditoria, control interno o normas de seguridad mínimas que detecten este tipo de situaciones.
Un dato importante a tener en cuenta que el sistema que instalamos monitorea en tiempo real determinados aparatos de la fábrica, que luego son volcados a una base de datos y visto por distintos reportes. Tal vez no sean datos estratégicos para la empresa que requieran un nivel de acceso excesivamente restrictivos, pero definitivamente semejante nivel de inseguridad no es aceptable en NINGUN sistema. Creo que no tengo que aclarar los desastres que una persona con suficientes conocimientos puede hacer con un acceso tan amplio y fácil a los servidores.

Y no estamos hablando de una pyme familiar de 50 empleados, sino de una empresa multinacional que en la Argentina solamente su facturación debe ser de cientos de millones de dólares y seguramente más.
No es la primera vez que veo este tipo de situaciones, especialmente en las plantas de las empresas. Recuerdo que una vez también en una importante farmacéutica, descubrimos que el password administrador del dominio era de toda la red era “administrador”. En muchas plantas industriales, independientemente del rubro, el sector informático está totalmente ausente.
Porque estoy seguro que en su sector administrativo y contable, este tipo de situaciones no ocurren. Pero como en las plantas, no suele existir ningún tipo de empleado en sistemas, sino mas bien consultores que instalan sistemas y tratan de hacer las cosas lo mas fácil y rápido posible, nadie controla el aspecto de la seguridad.
Me pregunto en cuantos lugares sucederán este tipo de cosas y en cuantas situaciones hay riesgo de desastre absoluto porque el que instalo el servidor de base de datos, no puso un password.

Blog de WordPress.com.