Noticias Weblogs Foros Wiki Código

Versión Cero

"Nosotros hacemos Scrum"

En esto de Scrum y las metodologías de gestión de proyectos en general existen dos corrientes de pensamiento principales. Una es la encabezada por Jeff Sutherland, co-creador de Scrum y gurú de las metodologías Ágiles: según él, para que Scrum funcione hay que ceñirse estrictamente a las reglas, y todo lo que no pase el checklist completo no puede llamarse Scrum (y de hecho debería estar perseguido por la iglesia y garantizarte una buena temporada en los fuegos del infierno).

Otra la forman los que piensan que no hay una policía del Scrum que vaya a venir a detenerte si decides formar equipos de 14 personas cuando la norma es de entre cuatro y diez personas por equipo, o que rodeen el edificio con sirenas y megáfonos si llegáis a la conclusión de que los Sprints de duración fija no son para vosotros.

Leer completo...

Concept Programming

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.

Consejos para comentar tu código

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.

Patrones de Interface de Usuario

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).

10 problemas abiertos en informática práctica

Sergio Montoro

A los que trabajamos en informática aplicada nunca nos darán el Premio Alan Turing por resolver algún enigma conceptual muy complicado. No obstante, nos enfrentamos a diario a problemas prácticos que nos hacen la vida muy incómoda.
Este artículo es una reflexión sobre algunos de mis problemas cotidianos, y una invitación a comentar posibles tácticas para solucionarlos.

Leer completo...

Licencias libres: Una guía rapida

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.

El problema con la programación

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.

Qualitatis

Qualitatis

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.

Getting Real: Libro gratuíto

37signals

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.

Apuntes en Navegapolis

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