Tendencias en Desarrollo de Software en 2007

A continuación algunos extractos completos del Blog de Carlos Perez traducidos al español para compartir su visiones en nuestra lengua. Mis aportes personales están en cursiva.

Lenguajes de Programación Dinámica (scripting)

Ruby (y Groovy) continuaran ganando convertidores, sin embargo este será confinado a la minoría de organizaciones de desarrollo altamente capaces. La facilidad de crear Lenguajes de Dominio Specifico (DSLs) en Ruby/Groovy llevara a crecer la promoción de la idea en la literatura. Las herramientas de desarrollo continuaran evolucionando. Al final Ruby y Groovy se convertirán en herramientas para los desarrolladores de Java como ocurre con el Ant.
Esto es discutible, los lenguajes de programación alternos a Java también tienen un gran rango de usos y con unas ventajas considerables, no solo para ser opciones scripting sobre la maquina virtual de Java (ver escalabilidad de PHP).

Repositorio de Contenido en Java

Las organizaciones comenzaran a preocuparse acerca de su Administrador de Contenido (CMS) pobremente soportado y empezara a salvaguardar sus activos de contenido migrando a implementaciones JCR estándar.
El estándar para JCR (Java Content Repository) es una gran solución para el acceso al Repositorio de Contenido flexibilizando el uso del CMSs (ver JSR-170). Existen una gran diversidad de administradores de Contenido o CMS funcionando en las empresas con problemas de portabilidad, escalabilidad y estandarizacion ademas que no son facilmente integrables a otras aplicaciones empresariales.

Plataforma Integración en el Navegador con Javascript

La gente se paralizara por completo por las utilidades basadas en extensiones como una expresión de la integración. Los desarrollos tales como Operador de Mozila, librerías de AJAX robustas como Tibio GI y aplicaciones Web Sociales como PiggyBank llevaran a una explosión de desarrollo de aplicaciones de escritorio que estarán solamente basadas en el navegador. Los mashups serán llevados al próximo nivel en donde se ejecutara en el navegador la integración en flujos de trabajo. El rendimiento de Javascript será mejorado con la compilación JIT.
Ahora que mozila Firefox se ha convertido en un verdadero contendiente de explorer, sus ambiciones van mas alla de ser un simple navegador hasta convertirse en una plataforma o en sistema operativo de web (ver entrevista con creador de Firefox).

Ubicuidad Eclipse

Las herramientas de desarrollo de Eclipse serán frecuentes en las organizaciones de desarrollo a pesar de los lenguajes de programación seleccionados (C++, Flash, Javascript, Ruby, Pitón, etc), sin embargo el crecimiento de las aplicaciones basadas en RCP serán retadas por técnicas de integración basadas en el navegador. Lo que es más probable es que los plugins de Eclipse soporten la competencia de tecnologías basadas en el navegador.

Framework AJAX Multimodales

El interés en el toolkit GWT de Google continuara creciendo, particularmente en las organizaciones tradicionales basadas en Java. El GWT sera usado no solo para desarrollar aplicaciones AJAX, también aplicaciones móviles basadas en J2ME. Esto será a expensas de Laszlo que hará un esfuerzo por terminar su módulo de AJAX y J2ME.

Vida después de EJB

La pesadilla de EJB finalmente ha muerto. Desafortunadamente, el mundo al que estamos transicionando esta extremadamente fragmentado. Despues de la carnicería, han emergido Spring y JBoss (osea Hibernate, jBPM y Rules) como los dos principales competidores en el espacio de la empresa. Spring y JBoss son actualmente meta-frameworks, Spring estructura la participación usando código, JBoss lo hace a través de empleo. Sin embargo es seguro decir que cualquier empresa respetable que se gane la vida con java debería basarse en cualquiera de estos dos frameworks. JSF será el nuevo Struts.
Spring es una excelente opción como framework para realizar aplicaciones de clase empresarial debido a su modularidad, integración, flexibilidad, rapidez y configuración simple comparado a EJB.

Administración de la Identidad Descentralizada

Cada grupo de Arquitectura en grandes organizaciones de IT se ha encontrado con el problema de la administración unificada de la identidad a lo largo de la empresa. Desafortunadamente, ha sido un problema desde el punto de vista técnico y social. Afortunadamente ha sido desarrollada una solución viable y liviana (osea OpenID).

Mueren los Webservices

WS y sus correspondientes especificaciones como SOAP y WSDL serán declarados muertos al final del año. Usted encontrará la declaración primero por los vendedores de herramientas y proyectos open source que rechazaran dedicar más esfuerzo en el camino equivocado. El vacío generado forzara a desplazarse a SOA (ver mas en SOA 2.0)

Hay probablemente más tendencias que he olvidado, así que puede hacérmelas saber.

Clasificación de la Ignorancia o los cinco niveles (ordenes) de Ignorancia

El software no es un producto es un medio para almacenar conocimiento. Por lo tanto el desarrollo de software no es una actividad produciendo un producto, es una actividad de adquisición de conocimiento. El conocimiento es solo la otra cara de la moneda de la ignorancia, por lo tanto el desarrollo de software es una actividad de reducción de la ignorancia.
Entonces que tipos de ignorancia tenemos? Hay 5 niveles o “Ordenes de ignorancia”. Ellos son (comenzando desde cero, ya que somos tipos de la computación y siempre contamos desde cero):

Ignorancia de Orden 0 (I₀) – Falta de Ignorancia
Tengo I₀ cuando se algo…
…y puedo demostrar mi falta de ignorancia de alguna forma tangible, tal como construyendo un sistema que ayude al usuario.

Ignorancia de Orden 1 (I₁) – Falta de Conocimiento
Tengo I₁ cuando no se algo…
…y puedo con agrado identificar ese hecho.

Ignorancia de Orden 2 (I₂) – Falta de Conciencia
Tengo I₂ cuando no se que no se algo…
…Digo, que no solo ignoro algo (I₁), sino que tampoco soy conciente de eso.

Ignorancia de Orden 3 (I₃) – Falta de Proceso
Tengo I₃ cuando no se la forma apropiada y efectiva para hallar que no se que no se algo…
...así que soy incapaz de resolver mi I₂

Ignorancia de Orden 4 (I₄) – Meta Ignorancia
Tengo I₄ cuando no se acerca de los 5 niveles de ignorancia…
…lo cual es algo que usted ya no va ser, estimado lector.

Tomado de CACM Oct 2000

Programando Cerca del Dominio

El siguiente texto es un resumen completo de la entrevista que llevo Bill Venners de artima a los SrS. Andy Hunt y Dave Thomas

Andy Hunt y Dave Thomas son los Programadores Pragmáticos, reconocidos internacionalmente como expertos en el desarrollo de software de alta calidad. Su libro mas vendido “The Pragmatic Programmer: From Journeyman to Master” está lleno con consejos prácticos en un rango amplio del desarrollo de software. También son autores de “Programming Ruby: A Pragmatic Programmer's Guide”, además han ayudado a escribir el Manifiesto Ágil del desarrollo de Software.

¿Cuando vale la pena construir una herramienta?

Muchas personas han malinterpretado el termino “Lenguaje de dominio” como si se tratara de rescribir java de la nada. Un lenguaje de dominio puede ser tan simple como una docena de macros en lenguaje C que dejaran crear valores iniciales y estructuras de datos. Si se estuviera usando un lenguaje que soporte reflexión, un Lenguaje de Dominio puede ser algo que permita configurar el sistema mediante la construcción de clases al vuelo, en tiempo de ejecución.

Una razón de por que la programación es difícil en general es que usted tiene que acercarse y alejarse a través de los diferentes niveles de detalle. Usted puede bajarse hasta los bits en bajo nivel y aritmética de punteros y entonces hacer un alejamiento hacia una abstracción que esta cerca del Dominio del Negocio. Usted estará de aquí para allá y de allá para acá, lo que resulta muy difícil. Es mucho más fácil si el usuario le da las Reglas del Negocio en su propio Lenguaje de Dominio. Es mucho más fácil si usted no tiene que mapear las Reglas de Negocio hacia el nivel mas bajo como un compilador lo haría. Para eso se usa la automatización, para eso están los computadores mismos, dejándolo quedar en el alto nivel de abstracción es la gran ventaja de los Lenguajes de Dominio.

Hablando del Lenguaje de Dominio

Un ejemplo real que refleja la aplicación de este concepto es una compañía que hace un software para probar lo interruptores de la línea telefónica. El software es cientos de miles de líneas de C++. Usted configura el software para el interruptor a ser probado. Se entran las señales y se chequea la salida correcta. Anteriormente cada ves que un nuevo interruptor entraba, ellos tenían que alterar el programa principal y recompilar 800.000 líneas de C++ para soportar un nuevo interruptor. Ahora ellos usan el lenguaje Ruby el cual tiene una interfaz muy simple a C++ que hace que los objetos de C++ parezcan como los del mismo de Ruby. Ellos envolvieron la plataforma de pruebas completa en Ruby, de esta forman pueden accederla por medio de programas en Ruby. Ahora para soportar un nuevo interruptor solo tienen que escribir un programa en Ruby de 50 líneas para manejarlo. Ellos ahora escriben código al nivel de Dominio de la aplicación. Y son infinitamente más productivos.

Un lenguaje de dominio es solo otro nivel de influencia. Así como C es otra capa de influencia encima del lenguaje ensamblador, Java es otra encima de C++, un Lenguaje de Dominio es por encima de Java. Un lenguaje de dominio es solo una capa más en una pila que abstrae más y más desde el nivel de ensamblador hasta el nivel de dominio.

¿Como se hizo Ruby su lenguaje de dominio?

Debido a que en Ruby, se puede escribir código de la forma, “para cada línea en el conjunto de entradas, ponga la línea de estado en Alto”. Esto hace que el código en Ruby sea muy específico al dominio.

Usted desearía codificar de tal forma que le puede mostrar a una persona del negocio y es mas posible que le entienda. Usted debe hablar en su lenguaje, no en el lenguaje del computador

¿Pueden diferenciar entre lenguajes declarativos e imperativos. Cuales son las ventajas y desventajas de ambos?

Es preferible codificar en forma declarativa, debido a que al nivel del negocio no se están ejecutando una serie de instrucciones. Se esta tratando con datos. Entre mas se pueda mantener el código a nivel de los datos, mas cercano se esta codificando en el dominio de la aplicación. Si usted puede expresar el programa en términos de los datos y de las relaciones entre los datos, se mantendrá en un nivel más alto siendo declarativo. Alternativamente si necesita controlar, o si necesita ser muy específico acerca del orden en el cual hacer las cosas, entonces necesita bajar al nivel imperativo. Lo que no debe hacer es ir y venir entre los dos modelos en la misma porción de código. Debido a que obtendrá un efecto traumático. Debe mantener las cosas separadas enfocándose en cada modelo según sea necesario.

La programación declarativa es otro ejemplo de programación cercana al dominio del usuario. Tal como el lenguaje SQL. SQL es principalmente declarativo con una instrucción SELECT usted dice “tráigame estos campos de esta tabla” usted no dice el como. En SQL no dice “Siga el puntero, traiga este archivo del disco. Recórralo con este índice BTREE. Optimícelo.” Usted no dice nada de eso. Eso es lo que necesita, eso es lo que se busca.

Referencias

Andy Hunt y Dave Thomas son los autores de El Programador Pragmático, http://www.pragmaticprogrammer.com/

El Manifiesto Ágil: http://agilemanifesto.org/

XProgramming.com: Recursos de Programación Extrema: http://www.xprogramming.com/

Como usar de un modo práctico estas técnicas para el desarrollo Agil de aplicaciones ver mas en: Open Systems Development (OSD) - http://www.osdglobal.com

Aplicaciones Web vs. Escritorio (Desktop) vs. legacy o consola

1. Concepto

Las aplicaciones Web utilizan lo que se conoce como clientes livianos (light clients) los cuales no ejecutan demasiadas labores de procesamiento para la ejecución de la aplicación misma. Desde el punto de vista de la arquitectura se distinguen dos lados el uno es el cliente en donde se encuentra el usuario final utilizando la aplicación por intermedio de una navegador (explorer o firefox), es aquí donde el usuario interactúa con la aplicación localizada al otro lado o servidor en donde residen realmente los datos, reglas y lógica de la aplicación.

2. ¿Por que este concepto ha tomado tanta relevancia?

La esencia del concepto es: no dejar que el cliente realice demasiadas tareas, solo lo necesario para que lleve a cabo su trabajo y dejar que en el lado del servidor se realicen las operación importantes: almacenamiento de datos, transacciones, reglas del negocio y la lógica del programa.

Con el auge de las rede locales (empresariales, institucionales o caseras) y la popularidad de la Internet ofreciendo la oportunidad de acceso a través de computadores y otros dispositivos móviles, lo que era algo de uso privilegiado hace algunos años, ahora es común. La Internet ha elevado y extendido aun más el concepto de aplicación Web para servir no sólo a usuarios de una pequeña red sino ubicados en cualquier sitio donde tenga acceso a la Internet.

3. Problemas con las aplicaciones de escritorio.

Con la división del problema en dos partes, se logra centralizar la administración en general a un solo lado: el servidor, resolviendo una gran cantidad de problemas anteriormente encontrados en las aplicaciones de escritorio mono usuario, como son:

• Duplicidad de datos por la falta de unificación de los mismos.
• Diseminación de la información y lógica en muchas partes (cada computador que la use).
• Falta de portabilidad de la aplicación a diferentes sistemas operativos
• Traumas a la hora de realizar actualizaciones o correcciones al programa ya que las instalaciones están diseminadas
• La administración de la seguridad, controlando el acceso a los usuarios a información no relevante o privada es un caos.
• Dificultad para configurar cada una de las instalaciones.(deployments) dependiendo de las necesidades de cada usuario

4. Que pasa con las aplicaciones de consola o modo texto?

Con aplicaciones tipo consola nos referimos a las aplicaciones construidas en plataformas del tipo Cobol, AS400 y RPG, FoxPro entre otras.

El concepto de las aplicaciones de consola es un poco similar al de una aplicación Web con una arquitectura del tipo cliente-servidor en el cual el cliente también se puede considerar liviano. Aunque existen algunas diferencias como son:

• Protocolos de comunicación propio y no estándar como si ocurre en Web con el protocolo HTTP y el concepto de URL.
• Formatos de intercambio propio y no estándar como si ocurre en Web con el formato HTML o XML.
• En el lado del cliente hay restricciones con las vistas ya que es necesario instalar APIs específicas que no son estándar, portables, o extensibles. En la Web sólo se debe instalar un navegador para acceder a la aplicación.y demas.
• La dependencia con el proveedor del software con respecto a la plataforma, arquitectura, hardware, sistema operativo y demás aditamentos que lleva consigo el “paquete” de la “solución” es inmensa en las aplicaciones de consola. En la Web la división por capas de las soluciones hace posible una independía en todo sentido mucho mayor.

5. La Web

La Web se puede considerar como una plataforma o “sistema operativo” en el cual los recursos están distribuidos en la red y están siendo extendidos en todo momento con posibilidades ilimitadas.

La Web se ha hecho popular con aplicaciones tales como clientes de correo, buscadores, portales, foros, chats, IRCs, RSSs, blogs y demás. Además de estas aplicaciones de propósito general existe adicionalmente una gran diversidad de soluciones que se acomodan al ambiente Web como son: Administradores de contenido (CMS), Administrador de proyectos, Suites para trabajo colaborativo, Administración de relaciones con el cliente (CRM), ERP y demás

La Web se reinventa día a día, lo que ayer parecía imposible hoy es una realidad, hace uno año o quizás meses no me cabía en la cabeza que hubiera muchas opción para realizar una hoja de calculo (Excel) en plataforma Web docs.google.com o que tal un juego animado de construcción de mundos (Age of empires) www.travian.net, un sistema de búsqueda mapas y direcciones (Google maps) maps.google.com. Google es uno de tantos que ha ayudado y sirve de infraestructura para llevar a cabo tales ideas a la realidad.

Si bien es cierto que la arquitectura cliente servidor de la web ha ofrecido muchas ventajas también es cierto que carece de la riqueza gráfica de las aplicaciones de escritorio que cuentan con controles inteligentes que dan mayor fluidez al trabajo del usuario, esto ha sido resuelto con varias estrategias o tecnologías tales como AJAX, flash y Web 2 entre otras. Asi que en vez de ir perdiendo fuerza debido a la pobreza en sus interfaces gráficas, la web busca alternativas que le permitan ofrecer todas sus ventajas pero con la posibilidad de ofrecer controles visuales más amigables al trabajo del usuario.

6 Integración

No se puede despreciar el enorme impacto que ha tenido el computador personal o PC en la actualidad, el haber puesto al servicio de un usuario normal el poder de una computadora en vez de una terminal simple ha potenciado una gran diversidad de usos.

Las aplicaciones de escritorio se han usado y se seguirán usando y tienen un campo enorme (sistemas CAD, CAM, suite de oficina, aplicaciones graficas, juegos, utilidades o el mismo sistema operativo), no todo esta en Web, hay cosas que se necesita que se ejecuten estrictamente en su máquina para aprovechar el poder que tiene al alcance. Pero la fusión e integración de servicios de los computadores, las aplicaciones de escritorio y la extensión de las facultades de comunicación con las aplicaciones Web que hace posible la Internet es la plataforma óptima que sirve de infraestructura para todos los usuarios desde el tipo empresarial, institucional o personal.

Referencias

Como usar de un modo práctico estas técnicas para el desarrollo Agil de aplicaciones, ver mas en: Open Systems Development (OSD) - http://www.osdglobal.com

Software abierto (libre) vs. Software propietario (comercial)

Vamos a llamar el Software abierto o Software libre por su acrónimo en ingles "OSS".
Existen varias ideas que van por ahí rodando que no hacen sino confundir aun mas a los usuarios del software.

1. Quien me puede dar soporte por el OSS

Muchas aplicaciones OSS son lo suficientemente estables y bien desarrolladas como para no necesitar mucho esfuerzo para ser implementadas sin problemas. Además existe una gran diversidad de comunidades, sitios, foros medios para comunicarse con personas dedicadas y dispuestas a ayudarle en su problema, recuerde que antes de requerir ayuda directamente es muy probable que ya haya sido resulto su problema antes, solo debe usar efectivamente su buscador favorito.

2. El OSS no vale la pena

Si usted es de los que piensa que las aplicaciones OSS no valen nada puede ver en este sitio www.koders.com el verdadero valor del software que se ha realizado bajo este modelo de desarrollo. Aqui se puede estimar el valor real de todos estos proyectos de acuerdo a su complejidad y trabajo, mejor aun están ahí para su servicio a un costo nulo.

3. El OSS es de baja calidad

La mayoría de aplicaciones OSS es realizada por expertos en el tema, universidades, empresas de todo tipo, personas que han trabajado en el sector por muchos años y han resuelto compartir su experiencia y dedicación con toda la comunidad; con esto se deduce el profesionalismo y la seriedad con la que se contruyen tales aplicaciones.
Para citar un caso Mysql tiene una tasa defectos muy por debajo de las soluciones comerciales alternas, puede ver mas en http://www.reasoning.com/downloads.html
Tambien puede ver algunas estadísticas de defectos en proyectos OSS en http://scan.coverity.com/

4. El OSS es abierto hasta que llegue una gran compañía y los compre a todos

El modelo Open source no nació ayer, lleva décadas con un éxito indiscutible, antes de pensar que las aplicaciónes OSS se puedan privatizar, lo que esta ocurriendo es exactamente lo contrario, muchas empresas comerciales están poniendo a disposición del publico su código confirmando aun mas que el modelo es valido y esta para quedarse.


1. El OSS es complejo

Aproveche la oportunidad de aprender; al usted analizar, entender y expandir una aplicación OSS esta ocurriendo una transferencia de conocimiento sin ningún costo por parte del creador. Para múltiples sectores en la industria y diferentes regiones geográficas esta es una gran oportunidad para ponerse al día en esta rama del conocimiento. Tal es el caso de OSD, empresa dedicada a la construcción de soluciones de software basadas en OSS.


4. Tendré que dar el código que haga en base al OSS

Existe una gran diversidad de licencias todas bajo el tipo de OSS, una de las mas populares es la GPL, en resumen el código que realice con software de este tipo debe ser proveído con el mismo tipo de licencia. Mírelo bien pero esto parece ser muy justo, y el objetivo no es más que hacer que el mismo software crezca aun más, que no se cierre o privatice de alguna forma haciendo que los aportes adicionales no sigan siendo compartidos para todos. Hay que madurar un poco para no ver este tipo de licencia como algo perjudicial para los desarrolladores de software.
Hay otros tipos de licencias mucho mas permisivas como es la licencia tipo Apache que da libertad en el software derivativo haciendo que usted pueda aun hasta cambiarle de nombre, el logo, el estilo, lo venda y no tenga ningún problema. Aunque este no es el caso el verdadero fin es quitar los mitos que existe con las licencias OSS. Lo que si debe quedar claro es que se es totalmente libre (no hay ningún tipo de compromiso u obligación) al solo usar aplicaciones OSS.

Referencias

puede ver mas información de los mitos acerca del OSS en
http://www.cio.com/archive/030104/open.html
http://www.oreillynet.com/pub/a/oreilly/opensource/news/myths_1199.html

Como usar de un modo práctico estas técnicas para el desarrollo Agil de aplicaciones, ver mas en: Open Systems Development (OSD) - http://www.osdglobal.com