Todos los programadores se quejan de que no les dejan hacer un trabajo decente y de calidad ¿Qué razón de mercado existe para esto?

Leer completo...

Ángel Medinilla de Proyectalis imparte los días 11 y 12 de mayo en Madrid y el 29 y 30 de junio en Barcelona un curso propio sobre Scrum y Metodologías Ágiles. Personalmente he tenido el placer de asistir a ediciones anteriores y doy fé de que son dos días tras los cuales la inmensa mayoría de los asistentes salen muy contentos de la inversión. Coste: 400€

Hoy estuve en el chat con un amigo a quien llamaré el Capitán del Proyecto para preservar su anonimato. El Capitán me contaba lo que estaba pasando en su proyecto, que no es nada nuevo, ni nada sorprendente. Pero no por ello menos impactante.

Leer completo...

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.

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

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

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

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.