97 Things es un proyecto colaborativo que pretende recopilar 97 axiomas que todo arquitecto de software debe conocer.
La idea de esta lista es que es creada por la comunidad. Puedes registrarte en el sitio y valorar los axiomas enviados. Además, si alguno de los axiomas enviados por ti es aceptado, te conviertes en un autor del sitio, con la posibilidad de crear una página con tu “biografía” y participar de modo más activo en la página.
Todos este trabajo queda disponible bajo una licencia creative commons pero además estos axiomas serán luego recopilados en un libro que O’Reilly Media publicará próximamente.
Por ahora tienen ya seleccionados 49 axiomas y contando.
A través del artículo Dip into concept programming de Phil Manchester en Reg Developer he estado leyendo unas Diapositivas sobre Concept Programming de Christophe de Dinechin y el lenguaje de programación extensible XLR
La idea, hasta donde yo la entiendo, es un lenguaje que te permita definir tu propia sintaxis para expresar conceptos.
En principio, la idea está muy bien, todos sabemos que en ocasiones es preciso escribir un código muy retorcido para expresar algo muy simple.
Por ejemplo: “Devolver true si el elemento x está en la lista {a, b, c, d}” En los lenguajes imperativos esto requiere escribir un bucle o usar un iterador, en los funcionales ese tipo de funciones se expresan de forma más natural, aunque la notación todavía puede quedar bastante inintelegible.
Lo que propone Dinechin es un lenguaje donde esté permitido escribir cosas como:
function Add (A, B : array) return array written A+B
dando así la notación del lenguaje para expresar el concepto de sumar dos matrices.
El problema es que esto ya se ha intentado, y no ha salido bien. El lenguaje conceptual por excelencia son las matemáticas clásicas. Cuya notación es tan críptica que resulta imposible de leer sin años de formación previa. Los matemáticos te calzan una hache mayúscula negrita para expresar Dios sabe qué espacio vectorial H y si te encuentras una â con acento circunflejo ya agárrate los nachos a saber lo que significa. Para colmo de males, fuera del cálculo y el álgebra básicos, ni siquiera hay una notación totalmente estándar o un manual de referencia general sobre notación matemática que puedas consultar.
Es decir, que yo creo que la idea está bien, pero no estoy seguro de que sea una buena cosa abrir la veda y que cada cual se invente su propio idioma de programación según le venga en gana.
Interesante el artículo de Variable not found donde nos da 13 consejos para comentar nuestro código.
Son todos consejos muy bien traídos y me gusta sobre todo que van más allá de la implementación concreta en un lenguaje concreto y en lugar de eso se centra en cual debe ser el espíritu de los comentarios: No comentar lo evidente, escribir código que esté autocomentado, comentar como parte del proceso de programación, no después, etc.
Igual que los patrones de diseño en programación nos permiten estudiar diferentes técnicas de programación y diseño, estructurarlas, ponerles un nombre para que los programadores nos entendamos, etc, lo mismo puede hacerse para casi cualquier disciplina (de hecho, el origen de los patrones de diseño está en la arquitectura).
En este caso concreto, una buena aplicación del concepto son los patrones de interface de usuario o de interacción. ¿Cuando es mejor utilizar tags? ¿Cual es la forma más amigable de presentar una paginación? ¿En qué casos puede ser interesante proporcionar un Wizard?
En Welie.com catalogan soluciones de diseño de interacción, proporcionando ejemplos, detalles, soluciones alternativas, etc.
UI-Patterns es otro sitio del mismo tipo, este con menos patrones, pero que incluye una sección donde se presentan detalles de implementación de los diferentes patrones (si bien todavía dispone de pocos items).
En Coding Horror han creado una tabla comparativa de licencias libres
No es una compilación exhaustiva, ni entra en los detalles de cada licencia (para eso podemos acudir a la OSI) pero nos permite hacernos una idea en 5 minutos de qué licencia escoger cuando liberemos código. El mensaje principal es: Elige alguna licencia. Si no eliges ninguna licencia y simplemente liberas el código realmente le estás imponiendo un copyright.
A continuación una traducción libre de la tabla:
| Licencia | Fuente | Tipo | Clausulas | Comentarios |
|---|---|---|---|---|
| Sin licencia | Abierto | Ninguno | 0 | Sin una licencia, el código tendrá copyright por defecto. La gente puede leer el código, pero no tienen ningún derecho legal para usarlo. Para usarlo, deben contactar con el autor directamente para pedirle permiso. |
| Dominio público | Abierto | Permisivo | 0 | Si tu código está en el dominio público, cualquiera puede usarlo para cualquier propósito. Nada está en el dominio público por defecto, tienes que ponerlo específicamente. |
| Licencia GPL | Abierto | Copyleft | 12 | La licencia abierta pata negra. Tu código no puede ser usado en un programa propietario, ¡jamás! |
| Licencia LGPL | Abierto | Básicamente Copyleft | 16 | GPL con una válvula de escape. Los programas propietarios pueden ser linkados binariamente con software LGPL bajo ciertas circunstancias. |
| MIT/X11 | Abierto | Permisiva | 2 | Cortita. Incluye descargo de responsabilidad genérico |
| BSD | Abierto | Permisiva | 2 | Cortita. Incluye descargo de responsabilidad donde se nombra expresamente a una organización. |
| Licencia Apache | Abierto | Permisiva | 9 | Requiere que los trabajos derivados incluyan avisos de cualquier código licenciado o propietario en un lugar común. |
| Licencia Eclipse Plugin | Abierto | Permisiva | 7 | Adecuada para negocios. Permite a los trabajos derivado elegir su propia licencia para sus contribuciones. |
| Licencia pública Mozilla | Abierto | Permisiva | 13 | Permite la mezcla liberal con software propietario. |
| MS Permissive License | Abierto | Permisiva | 3 | Se parece a la MIT y BSD. No está formalmente aceptada por OSI y se ofrece también en una variante tipo LGPL. |
| MS Community License | Abierto | Copyleft | 3 | Se parece a la licencia GPL. Requiere que todas las contribuciones se pongan a disposición de la comunidad. No está formalmente aceptada por y se ofrece también en una variante tipo LGPL. |
| MS Reference License | Propietario | Solo lectura | 3 | Puedes revisar el código y hacer copias del mismo, pero no lo puedes modificar. |
Muy buena la entrevista a Bjarne Stroustrup (creador de C++) The Problem with Programming publicada en MIT Technology Review.
En teoría, la respuesta [a los problemas de la programación] es simple: educar mejor a nuestros desarrolladores de software, usar métodos de diseño más apropiados, y diseñar para la flexibilidad y para el largo plazo. Recompensar correctamente los sistemas sólidos y seguros.
En realidad eso es imposible. La gente recompensa a los desarrolaldores que entregan software barato, defectuoso y rápido. Eso es porque la gente quiere gadgets chulos ya. Eso es porque no quieren ninguna inconveniencia, ni aprender nuevas formas de interactuar con los ordenadores. No quieren retrasos en las fechas de entrega, y no quieren pagar más por la calidad. Y sin cambio reales en el comportamiento de los usuarios es poco probable que los suministradores de software cambien.
Y, por cierto, el libro The Design and Evolution of C++ de Stroustrup no debería dejar de leerlo nadie que realmente quiera saber sobre lenguajes de programación.
De la mano de nuestro colaborador, Juan Palacio, se presenta Qualitatis.
Qualitatis es un nuevo sitio web para intercambio de conocimiento y experiencia sobre desarrollo de sistemas TIC. Cuenta con una sección de artículos, un blog y un foro.
La empresa 37signals, reconocida como una de las mayores innovadoras en el mundo del desarrollo web, creadora de Basecamp, Ta-da List y otros, ha condensado su filosofía de desarrollo en el lema Getting Real.
Ahora publica un libro en el que desarrolla dicha filosofía, basada en la simplificación del ciclo de desarrollo y en la orientación al usuario final. El libro, también llamado Getting Real está disponible en formato pdf y además se puede leer online de modo completamente gratuíto: Getting Real.
En Navegapolis han comenzado la publicación de unos útiles ficheros de apuntes que condensan en pocas páginas la información relacionada con distintos temas de la Ingeniería del Sofware. Se presentan en formato PDF y resultan una lectura muy interesante.
Por ahora han publicado dos:
Actualización: Y hoy mismo publican el tercer fichero: Gestión de Proyectos ?gil
