Resumiendo los principios de diseño de la construcción de software

Hoy he tenido que hacer el ejercicio de resumir los principios de diseño que yo creo que deben dirigir un proceso de construcción de software. Después de bastante reflexión me he quedado sólo con cuatro. Los siguientes:

  1. KISS (Keep it simple, stupid). Creo que nunca valoraremos lo suficiente el valor de simplificar todo lo posible los sistemas que construimos. ???? ????? ??? ????
  2. No construyas si puedes usar algo que ya existe.
  3. Entrega (parte de) el producto cuanto antes a sus usuarios, sigue construyéndolo apoyándote en los comentarios de los usuarios. ??????? ??? ?????
  4. La interfase del usuario debe ser web, siempre.
  5. La interfase del usuario es un animal totalmente distinto. 1xbet ???? Debe diseñarla y construirla un equipo de especialistas en interfases de usuario y debe estar totalmente desacoplada de la lógica de la aplicación.

¿Qué opináis?.

Descubierto un fallo de seguridad crítico en Ruby on Rails

Untitled document

[lang_es]El equipo de desarrollo de Ruby on Rails ha anunciado que ha descubierto y corregido un fallo crítico de seguridad y recomienda que todas las sedes web basadas en RoR sean actualizadas inmediatamente.

No se ha publicado todavía la naturaleza y características del fallo, según el equipo de desarrollo para permitir a los usuarios actualizarse antes y evitar posibles ataques.

La actualización es muy sencilla ya que RoR incluye un gestor de actualizaciones automático que permite actualizar el software con una única orden.

Actualización. Segú he leido en Kriptopolis al equipo de desarrollo de Ruby on Rails le ha costado dos intentos solucionar el problema de seguridad detectado.

Todos los detalles y los enlaces a los parches para las distintas versiones de Rails aquí[/lang_es]

Interesantes reflexiones alrededor de J2EE

Untitled document

 Estoy leyendo una entrevista realizada por TheServerSide a Rod Jhonson el creador del framework Spring. La entrevista es vieja, de Febrero de 2003, pero en mi opinión muchas de las cosas que dice siguen siendo totalmente ciertas. Os traduzco (libremente) algunas de las que me han parecido más interesantes.

Hablando sobre los mayores "pecados" del desarrollo J2EE dice: 

– Los desarrolladores tienden a pensar que el simple hecho de que existan tecnologías complejas, como los EJB's, implica la necesidad de utilizarlas. –
 
– Las soluciones más complejas necesitan más tiempo para su desarrollo, implican un mayor esfuerzo de mantenimiento y, con frecuencia, proporcionan peor rendimiento. –

 

– Es necesario que abordemos los problemas con la mente abierta y deberíamos estar preparados para utilizar la solución más simple y efectiva. –

Cuando le preguntan por la importancia de los patrones dice lo siguiente:

– He visto desarrolladores enloquecidos con los patrones. Centrados en encontrar oportunidades para aplicar patrones en vez de en dar respuesta a los requerimientos reales. –
 
– Los patrones deben ser utilizados como herramientas para construir una buena solución, sin pensar que el hecho en si mismo de utilizarlos convierte una solución en buena. – 
 
– Mi consejo a los desarrolladores es: leer el libro de patrones de la banda de los cuatro de cabo a rabo al menos una vez al año. Contiene el 90% de lo que necesitáis saber de patrones y os hará mejores programadores cada vez que lo leáis. –

Hay que decir que Rod recomienda a continuación leer también el libro Core J2EE Patterns y su propio libro, Expert One-on-One J2EE Design and Development, que nos ayudará a poner los pies en el suelo y a aprender como usar los patrones de la banda de los cuatro en un entorno J2EE.

Cuando contesta a la pregunta acerca de su opinión acerca de la gestión que Sun está haciendo de Java suelta algunas perlas y una de las que más me ha llamado la atención es la siguiente:

– Quizás lo peor que ha hecho Sun en la historia de J2EE ha sido desarrollar la Pet Store y presentarla como un ejemplo a seguir para el desarrollo de aplicaciones J2EE. La Pet Store está inflada y es ineficiente y ha dado a Microsoft un objetivo perfecto para atacar a J2EE. –

Más sobre los EJB's, pero en este caso para ponerlos en su sitio sin demonizarlos.

– Creo que los EJB's son la herramienta idónea para algunas tareas, pero están sobreutilizados. No veo a los EJB's como el núcleo de J2EE. Son solo una más de las tecnologías que incluye J2EE y sirven para resolver un tipo de problemas muy concreto. –

Aunque a continuación dice:

– No me gustan demasiado los Entity EJB's. Hay muy pocas situaciones en las que los he usado. –

Como véis, creo que lo que dice está totalmente vigente todavía. 

 
 

Evolución cinematográfica de un programador

Untitled document

[lang_es]En el diario web de übercansino: wip he encontrado una artículo en el que ArchEnemy compara la evolución de un programador con distintos actores cinematográficos. El artículo en cuestión es el siguiente: Evolución cinematográfica de un programador.

Está divertido, aunque creo que el tema daría para mucho más.[/lang_es] 

StarUML – The Open Source UML/MDA Platform

Untitled document [lang_es]StarUML es un proyecto de código abierto que tiene como objetivo desarrollar una herramienta de modelado de software del estilo de RationalRose o Together. Alguna de sus principales características son:

  • UML 2.0
  • MDA (Model Driven Architecture)
  • Plug-in architecture
  • Usabilidad

Todavía no lo he probado, el modelado de software no está en las primeras posiciones de mi lista de prioridades, pero lo haré. Una cosa que no me gusta es que solo funciona en plataformas Win32, esto es una limitación que, en mi opinión, hoy por hoy es poco justificable. Una cosa que me gusta y mucho, es que es un proyecto nacido en 1996, ¡hace 10 años!, y que va ya por su quinta versión. Anteriormente se llamó Plastic o Agora Plastic. [/lang_es]

[lang_en]StarUML is an open source project which aim is to develop a UML/MDA platform running on Win32 platform. StartUML has the goal of build a software modeling tool and also platform that is a compelling replacement of commercial modeling tools such as Rational Rose, Together and so on. Some of its main characteristics are:

  • UML 2.0
  • MDA (Model Driver Architecture)
  • Plug-in architecture
  • Usability

I have not tried it yet, software modelling is not in the first places of my ToDo list, but i will do it. One thing that i don't like is that StartUML only runs on Win32 platforms. I think that nowadays this is a unacceptable limitation. And one thing i like a lot is that this project is live since 1996, ten years ago!. StarUML is formerly known as "Plastic" or "Agora Plastic" [/lang_es]