Una wiki de Plex oficial

Desde hace ya ocho años aproximadamente, la comunidad de usuarios de Plex sostiene y ha hecho crecer una wiki que se proponía difundir el producto, y reforzarlo con artículos enfocados en aspectos difíciles de entender, o la descripción de variantes novedosas de uso del producto. Un gran esfuerzo sostenido especialmente por la gente de Desynit, pero acompañado por muchos otros, que dejaron un producto robusto, aunque difícil de navegar. No es la única que existe (también puede mencionarse más enfocada a la que AllAbout sostiene), pero es la más completa y profunda en sus contenidos.
Ahora, hace un par de días, CA, aparentemente en el marco de una política de "wikificar" todos sus productos, acaba de lanzar su versión oficial de una wiki para Plex. Contrariamente a la primera existente, esta no parece ser modificable por la comunidad de usuarios, sino sólo por la propia empresa. Por ahora, la invitación es a leerla y sugerir correcciones o ideas. Valga, no sería el único caso y tiene sentido defender la integridad de su contenido. La "antigua" wiki ha tenido que ir cerrando la participación de colaboradores externos después de ser blanco de centenares o miles de ataques de spammers, hasta el punto en que la participación es por referencias y conocimiento seguro de los participantes interesados.
Su contenido apunta bien, y digamos que CA tiene lo necesario para que esta wiki se convierta en una referencia primaria de Plex, especialmente considerando su carácter abierto, es decir, consultable por cualquiera que la acceda. Algo que no es tan simple si alguien desea abordar su documentación (bookshelves) conservada en el área de Producto de la web de CA. Un aspecto importante es que la wiki completa es descargable como pdf o epub (como pdf deja un documento de más de trescientas páginas).
Esta wiki está en sus comienzos, enfocada en la versión 7.1. No dudo que a través de sugerencias y críticas se irá puliendo y enriqueciendo, hasta convertirse en una referencia primaria para quienes quieran conocer el modelador y generador, y para nuevos desarrolladores que quieran entender cómo usarlo.
Por ahora, todavía un poco parco, y con algunas inperfecciones, como considerar la explicación del uso del diagrama de acción y el manejo de entidades relacionales como parte de los componentes de System i. De todas formas, muy recomendable, especialmente esperando su enriquecimiento futuro, que eso es lo que está en la esencia de cualquier wiki.

¿Yahoo en caída libre?

Al último recorte de personal conocido de Yahoo, acaba de agregarse la posibilidad de una reducción drástica de los productos que la empresa sostiene, particularmente Delicious. Casi dieciocho mil enlaces guardados que deberé exportar. Quizá no haya sido igual para todos, pero en mi caso, Delicious me permitió ordenar, relacionar, recuperar, una inmensa cantidad de información de todo tipo. Ahora, lo mejor que puedo hacer, es descargar todos los enlaces, y estudiar la posibilidad de mantenerlos en algún otro software. ¿En la nube? veremos...como este caso lo demuestra una vez más, Internet es frágil y volátil, y se mueve al compás de los negocios (volúmen de mercado mediante). Y la nube no necesariamente ofrecería una perspectiva de riesgos distinta.

Iniciativa académica de IBM

Recordada en estos días por IBM Developers Network, la Iniciativa Académica de IBM merece ser agendada por quienes estén en el alcance de sus servicios: estudiantes, investigadores, miembros de organizaciones de estándares. No sólo papeles, manuales, guías de trabajo sobre las áreas de trabajo de IBM, sino también acceso a servidores (disponibilidad de hardware):

Become a member of the IBM Academic Initiative to get no-charge access to hardware, full-version software, professionally developed courseware, tools, training, books, and discounts. Let us help you keep up with the latest technologies and reap the benefits of open source.

Quienes pueden participar.
Qué está disponible.
Diez razones para ser miembro.

Johan den Haan acerca de las virtudes de desarrollo basado en modelos (MDD)

Quisiera destacar algo que ya otros hicieron antes, pero no en castellano: las quince razones que Johan den Haan destaca en defensa del desarrollo basado en modelos. Lo haré muy brevemente, remitiendo a su artículo en inglés, pero en pocos días hablaremos un poco más de la crítica a MDD que se desarrolló en LinkedIn, que es su visión inversa. Tan pronto haya tiempo...
Las quince razones de Johan, simplemente enumeradas:
1. MDD es más rápido
2. MDD ofrece un mejor costo (cost-effectiveness)
3. MDD conduce a una mayor calidad
4. MDD es menos propenso a errores
5. MDD conduce a validaciones más claras
6. MDD produce softwaqre menos afectado por cambios de personal
7. MDD potencia los expertos de un dominio
8. MDD permite a los programadores avanzados a enfocarse en los problemas más árduos
9. MDD tiende un puente entre el enfoque de negocios y el tecnológico
10. MDD permite que el software sea menos sensible a los cambios de requerimientos
11. MDD permite que el software sea menos sensible a los cambios de tecnología
12. MDD realmente fuerza el cumplimento de una arquitectura
13. MDD captura conocimiento del dominio
14. MDD produce documentación actualizada del modelo
15. MDD permite enfocarse en problemas de negocios en lugar de hacerlo en la tecnología

Adhiero cien por cien a ellas. Remito a su artículo para su explicación ampliada; y en unos días, volveremos y daremos una vuelta de tuerca a partir de las críticas comentadas.

Bye, Bye COM: Estándares y Empresa

...otro Requiem, por COM (escrito por Ángel López). Un buen resúmen de la transición de COM a .NET, que da una idea de cómo mapear las relaciones entre las dos tecnologías. Sin embargo, quisiera agregar dos palabras al tema, que hacen a un asunto más general: el soporte de las tecnologías que son reemplazadas por nuevas versiones.
En distintas ocasiones, muchas más de las que se pudiera suponer, me he visto obligado a mantener código o arquitecturas que fueron quedando si no obsoletas, al menos demoradas; es decir, desarrollos con los que su propietario se siente conforme y no ve la necesidad de evolucionarlo radicalmente, adoptando un nuevo paradigma que le obligue a reescribir o reestructurar código por la simple razón de que la "nueva novedad" lo representa de otra manera. Éste es un fenómeno que en algunas plataformas puede degenerar en real atraso (1), pero que es absolutamente legítimo: una inversión satisfactoria no debería quedar descartada simplemente porque no encaja ya con la evolución de su propia plataforma nativa.
En el caso de la evolución de COM a .NET, así como en el paso de Visual Studio 6.0 a 2005 0 2008, el problema se plantea en el campo del soporte de documentación; quizá en cuanto a compatibilidad del código el problema no sea muy grande, pero es complicado si se requiere mantener una aplicación de VS 6 consultando MSDN; lo más que frecuente es que se hayan perdido las referencias de detalle, y que no se encuentren sino con grandes dificultades las descripciones de las versiones "antiguas" que se desea mantener. La única garantía es conservar bajo llave una copia de la documentación original, mas la historia de modificaciones, porque obtenerlo en la guía en línea puede ser casi imposible.
Este patrón se extiende al seguimiento de problemas, que una y otra vez conduce a callejones sin salida: páginas que ya no existen, aún para temas que debieran estar cercanos, pero que quizá hayan sido enviados a vía muerta en el curso del desarrollo del nuevo producto.
En más de una ocasión algún colega me explicó esto como una política disuasiva de Microsoft, para inducir a la masa de desarrolladores a adoptar las nuevas versiones de sus productos. Sin embargo, tengo la impresión de que, a nivel decisorio, esto produce otro efecto: la observación de una política de soporte del usuario descuidada y tiránica. Bastante alejada de la que he observado por muchos años sobre el AS400 y otros ambientes de IBM, y también, aunque no lo he requerido probar muy a fondo, con el caso del soporte de Sun sobre la plataforma Java.

Justamente, la conveniencia de no estar sujeto a las políticas de un proveedor, es lo que da al diseño guiado por modelos (MDA/MDD) un atractivo especial: la posibilidad de mantener el patrimonio de diseño a un mayor nivel de abstracción, nos otorga libertad de movimientos frente a proveedores y plataformas.

(1) Las facilidades de mantenimiento de código obsoleto -legacy- sobre el AS400 ;-) han llevado a muchas empresas a no innovar por años, dado que el código de su plataforma antigua sigue ejecutando sobre las nuevas versiones). Recuerdo algún caso de una distancia entre código ejecutado y sistema operativo de más de diez años.

Código autodocumentado

Una wiki dedicada a las reglas de escritura de código: La mejor forma de escribir comentarios es que el código sea el comentario...