31 ejemplos de arquitectura para DevOps y entrega continua.

En el blog de Sonatype, Derek Weeks ha anunciado esta estupenda presentación en la que se hace referencia a 31 arquitecturas de entrega continua (Continuous Delivery)

Cada ejemplo de arquitectura va acompañado de un enlace a la presentación original o blog en la que se presenta y explica.

Por hacer un poco de patria, indicaros que en esta recopilación se nombran dos empresas o productos nacionales.

• En la diapositiva 19, hace referencia a una presentación de la empresa española atSistemas.
• Y en la diapositiva 24, hace referencia a Clinker un Ecosistema de desarrollo de software desarrollado por la empresa sevillana klicap.

Aquí os dejo la presentación.

Integración continua en la nube.

Uno sale a dar una vuelta por la nube, a buscar un servicio de integración continua o entrega continua. Busca algo con Jenkins. Le suenan sobre todo 2 sitios.

• Clinker, http://clinkerhq.com/, porque es español y desarrollado por la empresa sevillana Klicap (@recena y compañia.)
• Cloudbee, http://www.cloudbees.com/, la superconocida cloudbee….

Y se encuentra con todo esto.

Clinker Cloud	http://clinkerhq.com/
CloudBees	http://www.cloudbees.com/dev
Cloud Foundry	http://www.cloudfoundry.com/
CircleCi	https://circleci.com/
Semaphore	https://semaphoreapp.com/
Travis	https://travis-ci.com/
Codeship	https://www.codeship.io/
Ship.io	https://ship.io/
Drone.io	https://drone.io/
tddium	https://www.solanolabs.com/
Wercker	http://wercker.com/
Shippable	http://www.shippable.com/
hostedci	https://hosted-ci.com/
Go-Ci	http://www.thoughtworks.com/products/go-continuous-delivery
snap-ci	http://snap-ci.com
appveyor	http://www.appveyor.com/
Magnum CI	magnum-ci.com

Aquí lo dejo por el momento y ya lo iré mirando con más tranquilidad.

Las fuentes principales para obtener estos datos han sido:

• 10 Hosted Continuous Integration Services for a Private Repository, recopilación realizada por Yegor Bugayenko, que por cierto tiene un estupendo blog, yegor256.com,  sobre entre otras cosas integración continua.
• What is the difference between Jenkins CI, CircleCI, Codeship, Travis CI, Shippable, Cisimple, Hosted CI, Semaphoreapp, Bamboo and Wercker?, en la página de Quora, donde los responsables de estos proyectos hacen una «encomiable y licita» defensa de sus proyectos.

 

 

MarkDown, Pandoc y generación de libros y artículos en múltiples formatos de forma sencilla

Cuando tengo que escribir me gusta utilizar herramientas en las que la escritura y la presentación  no deban gestionarse al mismo tiempo. Prefiero un entorno ligero, un editor de texto, que me permita escribir sin más distracciones. Y cuando posteriormente deba darle formato, sin tengo la opción, prefiero utilizar un lenguaje de marcado ligero.

Gracias a la plataforma LeanPub que nos permite ir publicando y compartiendo de forma progresiva nuestros libros, he conocido el lenguaje de marcado ligero MarkDown y las herramientas e implementaciones que existen a su alrededor. Y la verdad es que quedado gratamente sorprendido y sobre todo por una de ellas: la aplicación Pandoc.

Markdown es un lenguaje de marcado ligero creado originalmente por John Gruber  y Aaron Swartz  que trata de conseguir la máxima legibilidad y «publicabilidad» tanto en sus forma de entrada como de salida.

• Se puede utilizar y esta implementado en múltiples lenguajes.
• Existen múltiples conversores tanto de entrada como de salida.
• Y su uso esta bastante extendido como lenguaje de edición en algunos gestores de contenidos (CMS).

La guía oficial de la sintaxis MarkDown

Para profundizar en su sintaxis os recomiendo:

• La guía oficial de la sintaxis MarkDown por John Gruber.
• Guía Rápida de Sintaxis de Markdown.
• O esta estupenda guía de Joe Di Castro en castellano.

Estos son algunos ejemplos de su sintaxis, que supongo os sera muy familiar si en alguna ocasión habéis utilizado un Wiki.

# Esto es un H1
## Esto es un H2
### Esto es un H3

[Esto es un enlace](https://jbravomontero.wordpress.com)

**Esto es negrita**

_Esto también es cursiva_

Lista numerada (ordenada)

1. Este es el primer elemento
2. Este es el segundo elemento
3. Este es el tercer elemento

Lista de puntos (desordenada)

* Un elemento de la lista
* Otro elemento de la lista
* El tercer elemento de la lista

Imagenes

![Con titulo](pictures/avatar.png)

Tablas

| Elemento | Cantidad | Precio |
| :------- | :------: | -----: |
| Item 1   | 15       | 150    |
| Item 2   | 3250     | 23,65  |

Para Windows hay varios editores pero yo he encontrado uno que funciona estupendamente, es el MarkdownPad.

Editor Markdown para Windows.

No es necesario, pero si queréis os permite ir escribiendo y de forma simultanea ir viendo en la derecha el resultado en formato HTML. Aunque evidentemente cuenta con la opción de no mostrar el visualizador HTML para evitar las distracciones durante el duro proceso de escribir un artículo, un libro, etc.

Pero yo buscaba algo que me permitiese:

• Escribir con comodidad y una sintaxis ligera. Tengo mucha experiencia en XML y editores de XML pero no deja de ser farragoso.
• Y en diferentes ficheros para luego permitir:
  • Combinar de forma fácil el resultado en un único documento de presentación.
  • La documentación colaborativa.
  • Obtener varios formatos de salida.

Y he encontrado todo esto y mucho más en esa maravilla de herramienta que se llama Pandoc que ha sido desarrollada por un filósofo de la Universidad de Berkeley llamado John MacFarlane. Y que es lo que hace Pandoc para ser tan estupendo.

• Pues lo primero que funciona. Me ha funcionado todo a la primera.
• Y lo segundo, pues que le pasas a Pandoc un archivo fuente cualquiera de los que soporta Markdown, reStructuredText, etc y lo puedes convertir a LaTex, HTML simple, PDF, DocBook, OpenDocument, docx, rtf, man, texto plano y hasta tres tipos diferentes de presentaciones en HTML; y mi lista se queda corta, cortísima. Aquí hay un diagrama ilustrando su poder:

Pandoc input output

Su instalación en Windows ha sido muy sencilla. Como me interesaba sobre todo el tema del PDF, mi instalación a consistido en 2 aplicacioens:

• El instalable de Pandoc para Windows.
• Y un procesador de LaTeX que nos permita la conversión a PDF. Yo he instalado basic-Miktex. Aunque la generación del PDF es totalmente transparente desde el Pandoc.
  

Para probarlo os he subido un zip que os podéis bajar con:

• Mi artículo: Reduciendo el tamaño del código de un proyecto Java en formato MarkDown, codigo_duplicado_muerto_java.md, para que podáis realizar pruebas de conversión.
• Un fichero generar.bat:

pandoc codigo_duplicado_muerto_java.md -o codigo_duplicado_muerto_java.pdf
pandoc codigo_duplicado_muerto_java.md -o codigo_duplicado_muerto_java.docx
pandoc codigo_duplicado_muerto_java.md -o codigo_duplicado_muerto_java.html
pandoc -s codigo_duplicado_muerto_java.md -o codigo_duplicado_muerto_java.tex
pandoc -s -S -w docbook codigo_duplicado_muerto_java.md -o codigo_duplicado_muerto_java.db

• que permite de un sola vez varias realizar todas las transformaciones:
  • A PDF.
  • A Word.
  • A HTML
  • A Tex.
  • A Docbook.
  • etc.

NOTA: Tener cuidado de que las imágenes estén en la ruta adecuada.

Ejemplo de la transformación en formato Word.

El fichero, codigo_duplicado_muerto_java.md no lo he escrito directamente en este lenguaje, sino que lo he obtenido a partir del html original también utilizando Pandoc (aunque luego lo he tenido que modificar por las rutas de las imágenes):

pandoc -s -r html https://jbravomontero.wordpress.com/2012/12/28/reduciendo-el-tamano-del-codigo-de-un-proyecto-java/ -o codigo_duplicado_muerto_java.md

En resumen, dos herramientas estupendas y que funcionan a la perfección para escribir y transformar nuestros documentos.

Y también y ya termino me encanta porque se puede utilizar para la escritura colaborativa utilizando por ejemplo un control de versiones. Por ejemplo,  el famoso libro Pro Git

Esta escrito utilizando markdown, estando todo sus capítulos y traducciones organizados en Gitub, permitiendo por tanto escribirlo, mantenerlo y traducirlo de forma colaborativa. Eso si, desconozco el mecanismo por el cual terminan convirtiéndolo a los diferentes formatos de salida, aunque me parece que todos ellos serían posibles con Pandoc.

Un saludo.

Tips Sonar: Cálculo manual del porcentaje de las violaciones.

Si nos fijamos en el panel de control del Sonar podemos observar como uno de los widgets que nos muestra es el número de violaciones que incumplimos.

Sonar Apache Lucene. Widget violaciones.

NOTA:  Imagen del proyecto: http://nemo.sonarsource.org y como ejemplo el tablero de la aplicación Apache Lucene.

Estas violaciones son el resultado de incumplir algunas de las reglas que tenemos definidas en nuestro perfil de calidad. Son las reglas que normalmente tenemos definidas para las tres herramientas de análisis de código estático que utiliza el Sonar:

• PMD.
• Finbugs.
• Checkstyle.

Bueno, si volvemos al widget de violaciones, podemos observar como:

Violaciones Sonar

• Nos indica el número total de violaciones.
• El tanto por ciento de reglas que cumplimos.
• Y luego organizadas por categorías: blocker, crítical, major, minor, info el número de violaciones que tenemos de cada tipo.

Lo que voy a explicar a continuación, es como se calcula el porcentaje de cumplimientos de reglas.

Hay que partir de cada categoría de violaciones tiene asignada un peso. Esto se puede ver en la configuración del Sonar: System | General Settings  | General.

Como podemos ver:

INOF=0;MINOR=1;MAJOR3;CRITICAL=5;BLOCKER=10

Y el tanto % se calcula en función de la siguiente formula:

Porcentaje_violaciones_tipo_xxxx = nº_violaciones_tipo_xxxx * peso_violaciones_tipo_xxxx / nº líneas total

Por tanto, vamos a ver como en nuestro ejemplo como se obtiene el 75,8% que muestra la figura .

En primer lugar multiplicamos el número de violaciones por el peso correspondiente en cada categoría:

0 * 10 +
6 * 5 +
6.208 * 3 +
0 * 1 +
816 * 0
= 0 + 30 + 18624 + 0 + 0 = 18654

Y este valor lo dividimos para el número de lineas: 77.087

18.654/77.087=24,1986% aproximadamente 24,20%.

Es decir, incumplimos un 24,20% de reglas lo que supone que tenemos un 75,8% de reglas correctas. Esto nos permite también calcular el porcentaje por categoría, etc.

¿Y todo esto para que nos sirve? Nos permite conocer el peso de las violaciones por categorías en el computo global. Normalmente cuando se establece una perfil de calidad, se establece unos valores mínimos que se deben cumplir. 

• Puede ser que nos pidan que las blocker y crítical deban ser 0 y que el porcentaje global debe ser del 85%. ¿cuantas bloqueantes podríamos tener como máximo para llegar al 85%?
• Puede que nos pidan que las bloqueantes no pasen del 0,2% del total.
• Y nos puede servir para establecer estrategias optimas de limpieza de código de manera que con menos esfuerzo cumplamos un mayor número de reglas.

En cualquier caso, lo mejor es  no generar violaciones y gestionar el tema desde el inicio. Cuando se dejan estas cosas para el final en un proyecto muy grande el proceso es laborioso. Ademas parece muy poco profesional:  ¿que pasa? ¿solo sabemos programar bien al final?.

Si fuese el cliente y gestionase el cumplimiento de las reglas, más que la situación actual miraría la evolución de dichas reglas y exigiría que desde un principio se mantuviese a un nivel aceptable.  Poca confianza me produciría un código que se siempre esta alrededor del 75% y que de repente en pocos días pasa al 85%/90% ¿que o parece?.

NOTA: Gracias a Guillerme Iglesias que me explico el otro día estos cálculos, precisamente para saber si cumplíamos con los requisitos del cliente.

Hoy es el primer día para cambiar tu sector

Es divertido leer. Me encanta leer porque siempre termino encontrando gente que es capaz de expresar y sintetizar mejor que yo muchas de las cosas que pienso.

Me gusta el trabajo que hago: tengo la suerte de que me encanta. Pero no me gustan algunas cosas del sector en el que trabajo.  Pero no me voy a extender más en este post.  Roberto Canales lo explica mucho mejor que yo. No es cuestión de quejarse, es cuestión de ponerse las pilas e intentar entre todos cambiar el sector y hoy es un buen día para empezar.

Os recomiendo su artículo «Hoy es el primer día para cambiar tu sector» en el que explica como entre todos podemos hacerlo.

Reduciendo el tamaño del código de un proyecto Java.

En la siguiente gráfica podemos observar la evolución del número de clases, métodos y lineas de código en el proyecto en el que me encuentro actualmente.

Donde:

• La linea azul indica el número de clases.
• La linea naranja indica el número de métodos.
• Y la linea verde indica el número de lineas.

Como podemos observar no han hecho más que reducirse desde el mes de Junio. Es decir, con menos lineas de código, menos clases y menos métodos estamos en estos momentos implementando más funcionalidad que hace 6 meses (la implementación de nuevas funcionalidades ha continuado durante estos meses). Es sin duda, uno de los logros de los que más contento estoy en este proyecto.

Y me gusta, porque que más se puede pedir: que hacer más y mejor con menos lineas de códigos. Si recordamos el principio KISS ( siglas de Keep It Simple, Stupid):

«La perfección se alcanza, no cuando no hay nada más que añadir, sino cuando ya no queda nada más que quitar.»

El trabajo no ha sido fácil. El principal problema es cambiar la inercia en un proyecto y los programadores. Es muy dificíl en proyectos en los que:

• Lo importante es desarrollar, desarrollar, desarrollar y sacar nuevas funcionalidades al precio que sea.
• Y sobre todo, donde la filosofía que se impone es: «para que voy a cambiar algo que ya funciona«.

En este punto hay que tener claro un par de cosas:

• El concepto de «funciona». Por ejemplo ¿consideráis que funciona una funcionalidad que esta repetida n veces a lo largo del código? Yo estoy convencido de que terminara generando alguna incidencia. ¿Funciona? si, ¿pero durante cuanto tiempo?. ¿En que momento dejaremos de actualizar esa funcionalidad en algunos de los sitios que se repite?.
• No estamos haciendo calidad. Maldigo el significado que se le suele dar a esta palabra, y es que en muchos casos se suele entender por calidad una tarea adicional y por tanto como excusa para evitar los cambios. Estamos hablando de corregir nuestros errores, nuestras limitaciones no de mejorar el código. Calidad es lo que haremos después de esto.

Por eso hay que hay y darse cuenta de que el tamaño si importa y comprender como repercute en nuestro desarrollo:

• Cuando más código, más grande es lo que estamos construyendo y por tanto más difícil de manejar por las herramientas que lo gestionan: el servidor de aplicaciones, el entorno de desarrollo, el entorno de integración continua, etc. Todo va cada vez más lento y es más pesado. Por ejemplo,  si utilizas Spring cuantas más clases más tardara en cargarse el contexto.
• Tener nuestro código «bueno» entre miles de lineas de código duplicado o que no se utiliza es una locura para el mantenimiento.
• Y que pasa cuando tenemos que refactorizar. Cambias cosas en sitios en los que no hace falta porque no se esta utilizando (código que no se utiliza). Cambias la misma cosa en varios sitios (código duplicado).

Por tanto, el principal problema para abordar este problema es el cambio de mentalidad. Es lo que más vamos a tener que trabajar. Hay que tener en cuenta este aspecto desde el principio del proyecto y gestionarlo más durante todo el proceso de desarrollo.

A continuación paso a explicar las herramientas que hemos utilizado y me permito ofrecer algunos consejos que nos han resultado útiles.

Para controlar el tamaño de nuestro código hemos trabajado los siguientes puntos:

• Reducir el código que no se utiliza.
• Reducir el código duplicado.
• Y sobre todo, reducir las funcionalidades duplicadas, tanto a nivel de negocio como elementos de la arquitectura.

Para ello nos hemos basado en las siguientes herramientas:

El Sonar.

http://www.sonarsource.org/

Desde el panel de control nos permite:

• Tener identificadas las partes del código donde se producen las malas prácticas que anteriormente hemos mencionado.
• Y nos permite ver la evolución de estas métricas a lo largo de la vida del proyecto.

Esto lo podemos hacer mediante los siguiente widgets:

• Size metrics, nos proporciona información sobre el tamaño del proyecto.
• Timeline, información sobre la evolución de estas métricas.
• Comments & Duplications, código duplicado.
• Useless Code Traker, código que no se utiliza.

Mediante el Size Metrics y el Timeline podemos estar al día de las cifras y de su evolución a lo largo del tiempo.

Bueno, el Timeline es un widget más genérico que se puede configurar para ver la evolución de las tres métricas que nosotros deseamos. En nuestro ejemplo esta configurado para mostrar el número de clases, métodos y lineas.

Mediante Comments & Duplications (¿porque irán juntos comentarios y duplicaciones?) podemos encontrar donde se encuentran los duplicados. En la siguiente imagen se puede observar como nos ofrece la información:

Por defecto, siempre he utilizado la configuración por defecto, aunque parece que se configurar. Para más información sobre el tema: Manage Duplicated Code with Sonar.

Y mediante plugin Useles Code Tracker el código que no se utiliza.

Que si no me equivoco es una mezcla de información que ya tenemos: ofrece la información del código duplicado que se podría eliminar y algunas reglas que vienen con el PMD y  SQUID: PMD:UnusedPrivateMethod, SQUID:UnusedPrivateMethod, SQUID:UnusedProtectedMethod.

Para más información os remito a la documentación Useless Code Tracker Plugin.

Plugin PMD/CPD para eclipse.

http://pmd.sourceforge.net/eclipse/

El  PMD  nos proporciona otra herramienta: CPD que busca código duplicado. Para poder utilizarlo podemos utilizar el PMD  como plugin de eclipse y seguir los pasos que indicamos a continuación.

Para ejecutarlo, pulsamos botón derecho sobre un proyecto y seleccionamos la opción PMD | Find Suspect Cut and Paste tal y como podemos ver en la siguiente imagen.

el cual nos crea en un directorio «report» de nuestro proyecto un informe con el nombre de cpd.txt.

Recomiendo ir por partes y dividir el trabajo de eliminar código duplicado en fases. El código duplicado puede estar:

• En la misma clase.
• En clases del mismo paquete o entidades de negocio.
• En paquetes que no tienen nada que ver unos con otros.

Recomiendo empezar por las dos primeras que son relativamente fáciles y que normalmente se resuelve con un refactor que permite extraer el código a un nuevo método o clase.

En cambio el código duplicado entre diferentes paquetes puede implicar cambios más importantes:

• La creación de nuevos paquetes a un nivel alto.
• O delegar parte de la lógica a otros servicios que ya están funcionando y que son los que realmente tienen esa responsabilidad.

Aunque sin duda la mejor técnica para evitar el código duplicado es evitar o tener mucho cuidado con el Copiar y Pegar.

Plugin UCDetector para eclipse.

http://www.ucdetector.org/

Es un plugin para eclipse que nos permite encontrar código muerto. Es decir, clases, métodos y propiedades que no se utilizan.

Se instala como cualquier otro plugin desde la dirección http://ucdetector.sourceforge.net/update.

Y para utilizarlo, botón derecho sobre un proyecto y seleccionar las opción UCDetector | Detect Unnecesarie Code.

Mostrándonos los resultados en las clases afectadas y la vista de problemas de eclipse.

Aunque ojo, porque cuando intentamos detectar código que no se utiliza hay que tener en cuenta que en algunas circunstancias ya que si que se puede estar utilizando:

• Si utilizas Spring recuerda que las implementaciones no se llaman desde el código: son las interfaces.
• Si utilizas reflection evidentemente habrá parte del código que no se referencie.
• Ten cuidado con las clases que ofreces como APIs a terceros. Estas clases como puntos de entrada no tendrán ninguna referencia dentro de nuestro código.
• Etc.

En eclipse la combinación de teclas CONTROL + SIFTH + G.

La cual dada una clase, método o propiedad te indica si esta siendo referenciado o no desde el espacio de trabajo.

Configurar el formateador de código de eclipse para que la guardar elimine código que no se utiliza.

Es sin duda la opción que menos esfuerzo nos requiere. Configuramos el eclipse para que cada vez que guarde el código fuente de una clase elimine los elementos que no se utilicen en dicha clase.

Buscamos en el Eclipse en Preferencias | Java | Editor |Save Actions:

Y configuramos la pestaña de Unnecesary Code:

Ojo con esta configuración, porque puede causar problemillas ya que cada vez que guardas te elimina lo que no estés utilizando en ese momento, aunque lo vayas a utilizar a continuación. Por eso, normalmente los métodos privados no solemos marcarlos.

Otras herramientas que pueden ayudarnos

Antes os he indicado 3 herramientas que nos pueden servir en esta labor y yo creo que son más que suficientes. En cualquier caso aquí os dejo otras que también he probado:

• CheckStyle, al igual que PMD viene con su herramienta para la detección de duplicados.
• Atomiq, que me encanta. Me gusta mucho la representación gráfica en la que muestra el código duplicado. La cuestión es que es de pago pero tiene una versión de evaluación de unos días.

• CodePro AnalytiX, plugin Eclipse de Goolge para analizar código Java que entre otras virtudes tiene la de detectar código duplicado o similar.
• Proguard, es una herramienta para optimizar y ofuscar código java. Entre sus tareas esta la de eliminar clases, métodos, etc, que no se utilicen. Yo no lo he probado y la verdad es que no se como funciona, ya que entiendo que la acción de eliminar código que no se utiliza, forma parte del proceso completo. Pero lo pongo en la lista porque ya he visto a varios autores que lo recomiendan.
• Structure101, es una aplicación de pago que también nos permiten detectar lo que ellos llaman clases huerfanas («Orphans»).

Bueno, ya esta, supongo que aquí faltaría ahora hablar de técnicas de programación o de algunos patrones que nos ayudan a no repetir código. Bueno, para otro artículo!!! en cualquier caso la mejor técnica es la de no copiar y pegar. Y sobre el código que no se utiliza pues no tengamos miedo a eliminarlo lo tenemos en el control de versiones. Ya nos resulta complicado manejar un código relativamente limpio como para que debamos manejarlo acompañado de código que no se utiliza y código duplicado.

SOLID y GRASP – Buenas practicas hacia el exito en el desarrollo de software

Estupendo documento de Juan García Carmona sobre los principios SOLID y GRASP.

En esta dirección SOLID Y GRASP. Buenas prácticas hacia el éxito en el desarrollo de software. explica en su blog el origen de este documento al cual tenéis acceso desde esta dirección de Google Docs.

Disfrutarlo.

 

¿Que dos cosas le pediría a un programador?

Bueno dos cosas, entre otras muchas cosas. Pero sin duda les pediría y preguntaría:

1. ¿Si en su carrera profesional han llegado a implantar un proyecto?. Es decir, han llegado a ponerlo en producción y liberarlo con éxito para que los usuarios los utilicen en su vida diaria.
2. ¿Si han desarrollado algún proyecto para usuarios que lo van a utilizar porque les gusta o interesa y no por obligación?. Es decir, no un proyecto para un usuario de intranet de empresa que tienen la obligación de utilizarla si o si.

Y en ambos casos: ¿cual ha sido el resultado?. Aunque este es un aspecto un poco menos importante.

Si una persona en su vida profesional me responde afirmativamente a las dos preguntas anteriores me generara mucha más confianza como profesional que otros.

Liberar un proyecto no es una tarea fácil. El que crea que ya ha terminado un proyecto cuando los usuarios todavía no lo están utilizando de forma habitual se equivoca. El objetivo del proyecto es precisamente ponerlo en producción y que el usuario lo utilice.

Que las personas que trabajan en el proyecto sean capaces de tener esto claro no es una tarea sencilla. Y no lo digo por decir, estoy actualmente en un proyecto en el que prácticamente nadie a puesto un proyecto en producción. Y algunos de ellos son gente que ya llevan 6 años o más trabajando. Pero son personas que en sus 6 o más años de vida laboral no han hecho más que saltar de proyecto en proyecto y de empresa en empresa y nunca han terminado nada. Les falta por tanto ese «toque», esa «mentalidad» que te permite «terminar» el proyecto. Son personas para las cuales termina el proyecto cuando se van o los cambian, no cuando lo entregan. Y esto termina suponiendo un montón de problemas.

La respuesta afirmativa a la segunda pregunta me garantiza calidad y preocupación por lo que estas haciendo. Me garantiza que has tenido que pensar en el usuario y que te lo estas intentando ganar con la aplicación: porque es usable, porque va rápida, porque esta llena de funcionalidades que te agradan, etc.

!! Que diferentes serían muchos proyectos en los que he trabajado!! para intranets de algunas empresas, si no viésemos al usuario de la aplicación como un empleado que tiene que usarla si o si. Que parece que le puedes colocar cualquier cosa. Los usuarios de aplicaciones de Internet no se andan con tonterías: si no funciona no la utilizan y ya esta. Te dejan ahí con dos palmos de narices. Los tienes que cuidar y ofrecer lo mejor de lo mejor.

En resumen, me gustaría trabajar con gente:

• Que sepa que el objetivo del proyecto es un «producto» puesto en producción y funcionando.
• Que debemos hacer la aplicación como si fuésemos a cobrar por ella y por tanto, cuidando y mimando al usuario.

Siempre nos estamos quejando (con razón en muchos casos) de otros elementos que interfieren en el proyecto, cuando todavía queda mucho por mejorar en nosotros mismos.

El otro día leía en twitter «Con la tecnología actual se pueden hacer las cosas mejor y mucho más rápido » y estoy seguro y convencido de que es así.

Effective Java por Leo Antoli

Clase magistral de Java por Leo Antoli.

La presentación esta en: kcy.me/apz6 

Algunos consejos para ser un buen programador.

Hoy solo os dejo 2 enlaces. Dos enlaces que me han encantado y que están relacionados con las aptitudes de un buen programador y con lo que debería hacer a lo largo de su vida profesional para conseguirlo.

Los 4 pilares del buen programador

http://www.contentedcoder.com/2012/08/the-four-pillars-of-good-software.html

En el primer artículo, nos explica que para ser un buen programador no podemos conformarnos simplemente con escribir código, que debemos preocuparnos por:

• La calidad.
• La corrección.
• La productividad.
• La performance.

El conjunto de estas 4 pilares determinará si se es o no un buen programador y lo más recomendable es estar en la intersección de esos 4 puntos.

Aprende a programar en 10 años

http://loro.sourceforge.net/notes/21-dias.html

En el segundo artículos, el autor Peter Norvig, se mofa un poco de los libros que dicen enseñar un lenguaje de programación en 7 o 21 días.

Según el autor, algunos investigadores (Hayes , Bloom) han mostrado que toma aproximadamente diez años desarrollar habilidades en cualquiera de una amplia variedad de áreas y por tanto en la programación.

Nos recomienda que debemos hacer durante estos diez años:

• Interésate en la programación.
• Habla con otros programadores.
• Programa.
• Si quieres, dedica cuatro o cinco años en una universidad (o más en una escuela de graduados).
• Trabaja en proyectos con otros programadores.
• Trabaja en proyectos después que otros programadores. Proponte entender un programa escrito por otra persona.
• Aprende por lo menos una media docena de lenguajes de programación.
• Involúcrate en un plan de estandarización de algún lenguaje.
• etc.

Me parece muy acertada la parte en la que dice:  «Sé el mejor programador en algunos proyectos; sé el peor en otros. Cuando eres el mejor, tienes que poner a prueba tus habilidades para liderar un proyecto y para inspirar a otros con tu visión. Cuando eres el peor, aprendes lo que los maestros hacen, y aprendes lo que a ellos no les gusta hacer (pues te ponen a hacerlo por ellos)».

En definitiva 2 grandes artículos que nos pueden ayudar a ser mejores programadores.

Adiós.