Archivo | internet RSS for this section

Enlaces de los martes (06-11-2012)

Hace muchos martes que no publicaba una serie de enlaces, así que creo que esta vez la lista ha quedado un poco larga, pero espero que encontréis los enlaces muy interesantes:

  • Branching and merging with git and github, encontrado en Learn Github: Buscando alguna manera de trabajar con ramas en git y github, he encontrado este enlace. Creo que explica de forma muy clara y concisa una forma básica de crear ramas, trabajar en ellas, y pasar los cambios de una rama a otra. Ahora por lo menos, lo tengo mucho más claro.
  • The App Developers Alliance, de Joel Spolsky: Este post me ha gustado especialmente, no por el título, si no por las perlas que Joel dice en el artículo:

Cuando un programador escribe software, escribe un guión para el futuro.

El software es omnipresente.

El software se está comiendo el mundo, así que los programadores son los diseñadores del futuro

Enlaces de los martes (02 oct 2012)

Seguimos, un martes más, con una recopilación de los enlaces que me han parecido más interesantes, espero que a vosotros también os gusten:

  • Los desarrolladores odian las tareas sin valor (inglés), de Java Code Geeks: artículo donde el autor explora las razones de por qué los programadores odiamos las tareas sin valor (o que percibimos que no aportan valor) por ejemplo: una tarea repetitiva, una tarea que debemos hacer cada cierto tiempo, trabajo que antes de estar terminado alguien decide que ya no es necesario.
  • Comunicación productiva en equipo, de Think Wasabi, vía El Canasto: qué importante es una buena comunicación en un equipo. Descubre unos consejos para comunicarte mejor con tus contactos, ya sean del trabajo o no.
  • 6 ventajas de FDD frente a Scrum, de Javier Garzás: en el post anterior acerca de enlaces interesantes, dejé 2 de Javier acerca de la metodología FDD (Feature Driven Development), así que no podía dejar pasar este otro post acerca de esa metodología. Esta vez la compara con Scrum, una metodología ágil mucho más conocida y extendida, pero no por ello tiene que servir para todo tipo de proyectos. FDD se enfoca hacia un público muy distinto al de Scrum.
  • Cursos gratuitos de las universidades de Berkeley, Massachusetts y Harvard: no son simples cursos, creo recordar que son cursos académicos completos, es decir, un año de carrera en cualquiera de estas universidades. Los hay desde Introducción a Ciencia de Computadores (Computer Science) hasta temas tan punteros como Software as a Service (SaaS). Lo único no positivo que les veo es que son en inglés.
  • Groovy: The road map for the popular JVM language (inglés), de InfoWorld: Entrevista a los líderes de los proyectos Groovy y Graisç, Guillaume Laforge y Graeme Rocher respectivamente, donde comentan las futuras funcionalidades del lenguaje groovy y el framework web grails.
  • Prefiero github:pages a wordpress.com, de Roberto Vázquez: He descubierto el blog de Roberto a través de su post sobre la barcampes, y en particular, este post me ha gustado mucho. Me lo apunto como tarea, haré lo posible por tener tiempo para migrar mi blog de wordpress a github:pages, ¿por qué no?
  • Learnable programming (inglés), de Bret Victor, via Linking paths: según la fuente donde encontré el enlace, este es probablemente el ensayo técnico más importante del año, y la verdad es que promete. Fascinante lectura, en serio!

Enlaces de los martes (18 sept 2012)

Vaya! Se acabó el verano, y parece ser que el mundo vuelve a coger velocidad, y qué velocidad. Espero que estéis preparados para una nueva entrega de enlaces muy interesantes, vamos allá:

  • Code School, vía un tweet de Israel Alcázar: Una magnífica web de cursos de programación online. Muchos de ellos son de pago y todos tienen pinta de tener una altísima calidad en sus contenidos.
  • Tweet de ryah con el que estoy completamente de acuerdo, traduzco libremente:

Si quieres sentirte bien programando, debes aceptar aprender algo nuevo cada día durante el resto de tu vida

  • Cómo expresar tu pasion en tu currículum y en las entrevistas (inglés), de Jobs tips for geeks: Un artículo relacionado más con la vida como desarrollador que un artículo técnico, pero hay que tener conocimiento en varios campos. En resumen, qué demuestra tu pasión como desarrollador (de más a menos): participación en proyectos open source, colaboración en grupos locales de tu tecnología favorita, etc …
  • Continuous Integration for Javascript, de eriwen: ¿Usas Javascript en tus desarrollos? ¿Conoces alguna herramienta de integración contínua? Aquí, Eric te explica cómo montar un entorno de integración contínua para proyectos Javascript. Lectura muy recomendable, muy instructiva y también muy técnica :D.
  • The 4 pillars of a good software developer, de Contended Coder: artículo donde el autor cuenta su visión de los que cree son los cuatro pilares en los que se basa un buen desarrollador software: calidad, corrección, rapidez de ejecución y productividad; cómo mejorarlos y cómo llegar a un equilibrio en ellos.
  • Metodología ágil FDD, de Javier Garzás: consta de dos artículos (I y II) donde Javier nos describe esta metodología, FDD (Feature Driven Development, desarrollo dirigido por funcionalidades). Me llamó la atención por ser una metodología orientada a grandes empresas y grandes proyectos y grandes equipos, en contraposición de metodologías ágiles como Scrum, XP y Kanban que suelen proponerse para equipos pequeños.
  • What have you tried? (inglés), de Matt Gemmell: un artículo donde Matt expone una problemática con la que todos nos hemos tropezado: pedir ayuda en internet. La opinión de Matt al respecto es que antes de pedir ayuda, deberías currartelo un poco, e intentar solucionar el problema por tu cuenta: conociendo más el entorno que te está causando el problema, buscando información, leyendo manuales, FAQs, etc. En definitiva, que cuando te pregunten “¿Qué has intentado?”, tengas algo real que responder para no obtener una respuesta del tipo “Si no has intentado nada, ¿por qué esperas que te vaya a ayudar?”.

Referencias:

Enlaces de los martes

En los enlaces de hoy he incluido un poco de autopromoción. No me gusta hacerlo, pero por otro lado creo que es muy bueno hacer públicos los pequeños logros que uno va consiguiendo, más que nada para recibir el máximo feedback posible y poder crecer en el ámbito personal.

Además, se nota que estamos en verano, y el ritmo de enlaces interesantes ha bajado bastante. O me estoy volviendo demasiado exigente, quien sabe.

Sin más, ahí van los enlaces:

Enlaces de los martes

Y este martes tenemos otra nueva entrega de enlaces. Espero que os guste, cualquier feedback es bienvenido.

 

Enlaces de los martes

Como el título indica, espero que esto se convierta en una costumbre (sana) para mí.

En mi día a día, leo muchos artículos o gracias a la gente que sigo (blogs, twitter, …) llego a páginas realmente interesantes. Y simplemente no quiero que esos enlaces se queden por ahí perdidos, y además, me gustaría compartirlos.

Así que ahí van mis primeros enlaces de los martes:

  1. De qué hablo cuando hablo de excelencia, de Javier Lafuente Garcia (@jlafuenteg): Un genial artículo sobre la definición de excelencia en el mundo del software.
  2. 25 Best Free Maven Plug-ins to Make Java Developer More Productive, visto en fromdev: Donde se listan plugins esenciales para el trabajo del día a día con maven.
  3. Code School – Try git, visto en github: Una estupenda herramienta para aprender a usar git.
  4. Clientes con los que yo no trabajo, de Asier Marqués: Espero acordarme de este artículo si algún día decido dedicarme a tener mi propio negocio.
  5. El mítico restaurante italiano, visto en Frogtek: Una inestimable alegoría para comprender mejor las metodologías ágiles. No puedes quedarte sin leerlo.

Espero que estos enlaces os sirvan para descubrir recursos muy interesantes y valiosos.

Refactoring: improving the design of existing code

Refactoring: improving the design of existing code

Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

Por qué lo he leído

El título me pareció sugerente. Me gusta que el código que utilizo, el código que escribo o el código que leo, tenga muy buena apariencia, sea legible, sencillo y, por qué no, sea bonito.

No soporto ver clases mal identadas, o con nombres que no significan nada. Lo odio. Y siempre he pensado que refactorizar el código ayuda a conseguir todo esto.

Qué esperaba

Evidentemente, según el título, esperaba un manual, una guía, sobre cómo refactorizar. Esperaba que el libro me enseñara a refactorizar, a mejorar las refactorizaciones que hago en mi día a día.

Teniendo a Martin Fowler como autor principal, esperaba una descripción de experiencias, una demostración de veteranía, de la que poder beneficiarme y aprovechar esa sabiduría para mejorar en mi trabajo.

Qué encontré

Encontré un catálogo de acciones de refactorización. Muchas de las refactorizaciones descritas en el libro son sencillas, otras ya las practicaba sin conocerlas formalmente y otras estoy seguro de que me resultarán muy útiles de aquí en adelante.

Conclusiones

El libro me ha resultado un poco denso, y a veces muy lento, incluso llegó un momento en el que estuve a punto de dejar de leer.

Cada acción de refactorizar está muy detallada. Esto hace que leerlo sea un poco aburrido, pero como referencia no tiene precio.

Como ya he dicho antes, muchas refactorizaciones ya las estaba realizando personalmente, pero ni las había categorizado, ni les había puesto nombre. Por esto mismo, no he encontrado muchas refactorizaciones desconocidas para mí, pero al mismo tiempo me ha permitido categorizar, catalogar, varias refactorizaciones que estaba realizando. De las refactorizaciones nuevas, tengo pensado escribir sobre alguna de ellas.

Sin duda, es un libro a tener en cuenta para cualquier desarrollador software, tanto como para su lectura como para tenerlo de referencia. Totalmente recomendado.

Pasajes que quiero recordar de este libro

El primer paso, es construir un conjunto sólido de tests para el código que se va a refactorizar.

En la mayoría de los casos, un método debería residir donde los datos que el método usa.

Para refactorizar, lo mejor es pasito a pasito, lo que lleva a cometer menos errores.

La lección más importante del ejemplo es el ritmo del refactor: test, cambio pequeño, test, cambio pequeño, test, …

¿Por qué refactorizar? Mejora el diseño del software, hace el software más fácil de mantener, ayuda a encontrar errores, ayuda a programar más rápido.

¿Cuándo no refactorizar? Cuando es necesario empezar desde cero, o cuando estás cerca de una entrega.

Cuando los testers encuentran un bug, hay que hacer dos cosas: arreglarlo y crear un test que te asegure de que el bug no volverá a aparecer.

El estilo que yo sigo es el de fijarme en todas las cosas que la clase puede hacer y pruebo cada una de ellas para todas las condiciones que pueden hacer que la clase falle. No es lo mismo que testear cada uno de los métodos públicos. Los tests deben de exponer cierto riesgo.

La repetición es la raiz de todos los males del software.

(Las sentencias de protección indican: esto es raro, haz algo y sal de aquí) La sentencia de protección o retorna de la función o lanza una excepción, nunca debería dejar seguir ejecutando el método.

A veces, se da por supuesto algo y se escribe un comentario. Es mejor hacer explícita lo asumido creando una sencia assert.

Mi experiencia me dice que conforme refactorizar se va convirtiendo en una rutina, deja de ser una sobrecarga y comienza a ser algo esencial