Durante el pasado de mes de Julio, tuve la gran oportunidad de pasar una semana trabajando con los increíbles chicos de BeBanjo. En cuanto me enteré de que están buscando gente para ampliar su equipo, decidí escribir a Luismi Cavallé para obtener más información al respecto. Y cual fue mi sorpresa cuando me propusieron trabajar una semana con ellos. Claro: ¿qué mejor forma de conocer a tus candidatos que trabajar una semana con ellos?. Mucha gente no entendía que fuese a una empresa a trabajar sin cobrar un duro, pero ¡yo no lo dudé ni un minuto!

La experiencia fue genial para mí. Fueron sólo 5 días pero personalmente me aportó mucho. Por eso, y en primer lugar, quiero dar las gracias a Jorge Gomez Sancha y Bastian Manintveld por la invitación. Thanks!.

Paso a resumir algunas de las buenas prácticas y aspectos que más me llamaron la atención y por las que opino que realmente merece mucho la pena trabajar en BeBanjo:

A nivel técnico

Llevaba mucho tiempo deseando trabajar en algún proyecto Rails “de la vida real” y con un equipo maduro que realmente llevara mucho tiempo trabajando con el framework. Ya había asistido a una sesión sobre Testing de aceptación en Ruby impartida por Luismi y Sergio Gil y eso me motivó mucho a escribirles. A nivel técnico, me llamó la atención:

La programación por parejas: un ordenador, dos pantallas, dos teclados, y dos ratones

Reconozco que nunca había programado en pareja de una forma tan intensiva. Sí lo había hecho para resolver algún problema complejo concreto, pero no durante jornadas completas. La experiencia fue muy positiva. En BeBanjo tuve la oportunidad de comprobar la productividad y calidad que se consigue cuando dos cabezas están resolviendo un mismo problema.

El hecho de tener una persona al lado, con quien poder discutir una determinada solución, no sólo ayuda a obtener un mejor código, sino que también consigue que ambas partes estén completamente concentradas en su trabajo. Trabajando con Luismi comprendí que el hecho de exponer el problema a otra persona de una forma oral, ayuda a darse cuenta de muchas cosas que de forma introspectiva sería difícil descubrir.

Y si a eso le sumas la técnica del Pomodoro sincronizada entre todos los miembros del equipo con tomatoi.st, un sencillo tablero kanban y una planificación al comienzo de cada día: ¡la productivad es brutal!

El ciclo BDD/TDD: ¡las pruebas primero!

¡En BeBanjo siempre escriben los tests primero!. Y gracias a esta experiencia puede ver a un equipo real con su propia forma de hacer BDD/TDD, es decir, programando primero cuál es el comportamiento esperado desde el punto de vista del usuario en forma de test para después codificar una solución lo más elegante posible. Esto hace posible desarrollar nuevas funcionalidades sin apenas abrir el navegador.

En el caso de Ruby On Rails, tuve la oportunidad de trabajar con el famoso Steak, y también pude ver a Jasmine en acción

Lo mejor que he aprendido referente a este tema es, a parte del enfoque BDD, que no existe una forma definitiva de probar tu código sino que cada equipo/persona debe elegir qué aproach le aporta más valor y seguridad… Por otro lado, he aprendido que hay cosas bastante triviales que no merece la pena probar.

El workflow con git: varias ramas y un buen entorno

He de reconocer que a nivel profesional sólo he trabajado con Subversion. Conozco GIT gracias a GitHub y algún proyecto que he desplegado en Heroku.

En BeBanjo tienen muy bien planteando su flujo de trabajo con git. Descubrí bastante comandos de git y los problemas que puede ocasionar el trabajar con una única rama master.

Ni que decir tiene, que los despliegues en producción son bastante frecuentes y que cualquier miembro del equipo puede desplegar nuevas funcionalidades sin miedo a romper algún código anterior.

Excelencia técnica y happy programmers

Poco puedo contar de Luismi, Sergio Gil (Porras) y Christos Zisopoulos que no se sepa ya. A nivel técnico cuentan con una gran experiencia y son desarrolladores muy “visibles” y activos en el panorama Ruby nacional e internacional, lo cual dice mucho sobre sus perfiles y los convierte en grandes compañeros de trabajo. Pero lo más importante de todo es que disfrutan con su trabajo.

En este punto he de agradecerles a los tres su gran paciencia a la hora de responder mis infinitas preguntas, y en especial a Luismi que fue con quién más trabajé y de quién más pude aprender . Thanks!

A nivel de empresa

Al mismo tiempo, tenía muchas ganas de vivir el ambiente de una empresa de producto tipo startup. El hecho de que mi estancia coincidiera con un cambio de oficina me hizo estar implicado en situaciones bastante divertidas y a su vez curiosas por las que supongo toda startup debe pasar algún día. BeBanjo me parece una buena empresa por los siguientes aspectos:

El buen ambiente de trabajo: felt like home!

Los miembros de BeBanjo me hicieron sentir como en casa desde el minuto nº1. Pocas veces me he sentido tan cómodo en un ambiente de trabajo en tan sólo una semana. He de reconocer que durante esa semana no tuve la sensación de ir a “trabajar”. Horarios flexibles, mucha comunicación entre el equipo, reuniones informales, comidas muy distendidas, y mi gran inquietud por aprender con ellos lograron que el día a día fuese super ameno.

Productos nicho que resuelven necesidades reales

El éxito de BeBanjo radica en que sus productos están enfocados a un nicho de mercado muy específico. Los fundadores detectaron que las empresas que ofrecen contenidos de video bajo demanda tienen determinados problemas a la hora de gestionar la información sobre sus referencias (series, películas, etc) y la publicación en diversas plataforma. Entonces diseñaron y desarrollaron varias aplicaciones (Sequence, Movida y Metadata) enfocadas a ayudar a estas empresas. Un punto clave en este aspecto es la gran colaboración de los clientes en todo este proceso.

Concienciación de la importancia del diseño

Sin duda, en BeBanjo saben lo importante que es el buen diseño de producto y por eso trabajan con los mejores. No pude conocer personalmente a Ale Muñoz pero sin duda ha hecho un gran trabajo en el diseño de los actuales productos de BeBanjo. Actualmente están buscando diseñadores todo-terreno y estoy convencido que no tardarán en encontrar a algún crack en este campo.

La importancia de un buen equipo comercial y una clara orientación a cliente

Hace tiempo que soy consciente de la importancia de un buen equipo comercial a la hora de desarrollar productos tecnológicos de éxito. De poco o nada sirve tener un producto excelente a nivel técnico si los posibles compradores no conocen acerca de su existencia… En este sentido creo que ambos socios realizan una gran labor a la hora de establecer nuevos contactos comerciales y en el trato diario con el cliente.

Su enfoque internacional: pensando en grande

Me llamó mucho la atención el enfoque claramente internacional de esta pequeña gran empresa… No era raro escuchar a lo largo del día muchas conversaciones de fondo en inglés o francés. Parece de perogrullo pero… ¿por qué limitarse al mercado nacional? Y este enfoque no se limita a la parte de captar clientes, sino también a la hora de contratar nuevos empleados… ¿por qué no contratar a gente con talento de otros países?.

Podría seguir escribiendo… pero no me quiero extender mucho más. Aprovecho para agradecer de nuevo a todos los miembros de BeBanjo y me despido recomendado a todo el mundo vivir una experiencia de este tipo. Merece la pena.

¡Gracias BeBanjo!

Las empresas acostumbran a destinar uno o varios servidores para albergar en ellos los repositorios de cada uno de sus proyectos. Otras recurren a servicios como los que incluyo a continuación.

A nivel personal, es muy probable que no contemos con esa infraestructura y nos interese contratar un servicio bueno, bonito y barato, que nos permita alojar nuestros proyectos privados (y otros públicos). Si bien es cierto que GitHub es uno de los sitios más populares y alberga el código fuente de muchas aplicaciones conocidas, existen otras alternativas.

Bitbucket

Visitar ell sitio web de BitBucket

Codebase

Visitar el sitio web de Codebase

Codeplane

Visitar el sitio web de Codeplane

GitHub

Visitar el sitio web de GitHub

Projectlocker

Visitar el sitio web de Projectlocker

Repositoryhosting

Visitar el sitio web de RepositoryHosting

unfuddle

Visitar el sitio web de unfuddle

XP-Dev

Visitar el sitio web de XP-Dev

Si conoces alguna alternativa más estaré encantado de incluirla en este listado. Gracias!
]]> http://alonsogarciapablo.com/blog/sitios-web-alojar-el-codigo-fuente-privado/feed/ 6 http://alonsogarciapablo.com/blog/modulos-en-ruby/ http://alonsogarciapablo.com/blog/modulos-en-ruby/#comments Thu, 12 May 2011 07:54:17 +0000 Pablo http://alonsogarciapablo.com/blog/?p=603 Llega un momento en la vida del programador Ruby en que, de forma natural, empieza a indagar en el código escrito por otras personas, por ejemplo en proyectos alojados en GitHub. En estos proyectos se empieza a ver cómo se hace uso de los módulos, mixins, etc. Pero no siempre es fácil de entender todos estos conceptos.

Con este post pretendo ayudarte a entender bien los módulos de ruby para, por ejemplo, aprender cómo dividir bien el código en módulos, entender el código de las gemas, extender el comportamiento de Rails, etc…

¿Qué es un módulo?

Un módulo es una agrupación de métodos, clases y constantes. Mediante el uso de módulos, podemos dividir un programa o sistema en varias partes independientes y reutilizables que interactúen entre sí. Si estás familiarizado con Java, el concepto de módulo podría asimilarse al concepto de paquetes.

Uno podría pensar que esta definición es similar a la de una Clase, que también tiene métodos, clases y constantes… Sin embargo, la diferencia fundamental respecto a las clases, es que no se pueden crear instancias de un módulos.

Como ejemplo de módulo tenemos el módulo Math, que recopila mayormente funciones para operaciones trigonométricas. Y que

¿Cómo se define un módulo?

module MyModule
 
  MY_CONSTANT = '...'
 
  def MyModule.my_method_1
    ...
  end
 
  def my_method_2
     ...
  end
 
  ...
 
end
 
puts MyModule::MY_CONSTANT
...
MyModule.my_method_1

El ejemplo define un módulo de nombre ‘MyModule’ con una constante MY_CONSTANT. Vemos que el módulo tienes 2 métodos: un primer método de módulo, llamado “my_method_1″, que sería equivalente a un método estático de una clase; y un segundo método, “my_method_2″, que sería un método de instancia. ¿Método de instancia? ¿No me acabas de decir que los módulos no tienen instancias? Lo veremos un poco más abajo

Como hemos visto, podemos acceder al valor de una constante a través de “::” y el nombre de la constante. La invocación de los métodos de módulo sería similar a la invocación de un método estático.

Principales usos de los módulos

Definición de espacios de nombres

Cuando los programas crecen, surge la necesidad de organizar de alguna forma todas las partes de la aplicación que están de alguna forma relacionadas entre sí. En el caso del módulo Math, queda claro que todas esas funciones están tan relacionadas que deben habitar en un mismo espacio de nombres. Los espacios de nombres también evitan el problema de que surja una ambiegüedad en el caso de que haya dos componentes con un mismo nombre. Por ejemplo, podemos tener dentro de un programa varias clases con el nombre “Settings”, pero cada una estará referida a algo concreto. Incluyendo esas clases en distintos módulos, conseguimos que puedan ser identificadas de forma unívoca.

Para cargar y utilizar un módulo desde otras partes de la aplicación, podemos usar principalmente 3 métodos:

• require, que carga un fichero de código sólo una vez. En este caso el método recibe una cadena con el nombre del fichero.
• load, que carga un fichero de código aunque ya ha sido ejecutado previamente.
• autoload, que recibe el nombre de un fichero y de un módulo, y carga el fichero la primera vez que se accede al módulo indicado.

Todos estos métodos aceptan rutas absolutas y relativas.

Mixins

Los mixins permiten añadir funcionalidad a una clase mediante el comando include.

Vamos a ver un ejemplo en el que añadimos un método de instancia a la clase String que elimina los espacios en blanco de principio y fin de una cadena y los sustituye por guiones.

module StringUtils
  def hyphenize
    self.to_s.strip.gsub(' ', '-')
  end
end
 
class String
  include StringUtils
end
 
puts " en un lugar de la mancha... ".hyphenize

Con este mecanismo, podemos reutilizar el módulo en varias clases. Es posible incluir varios módulos en una misma clase o módulo, con lo que conseguiríamos un efecto similar al de la herencia múltiple disponible en otros lenguajes como C++.

Además de añadir métodos de instancia, es posible extender una clase con métodos de clase, haciendo uso de extend. Lo vamos a ver con un último ejemplo, que extiende una clase con métodos de instancia y de clase.

module MiModulo
 
  def self.included(base)
    base.send :include, InstanceMethods
    base.send :extend, ClassMethods
  end
 
  module InstanceMethods
    def mi_metodo_de_instancia
      "mi método de instancia"
    end
  end
 
  module ClassMethods</p>
    def mi_metodo_de_clase
      "mi método de clase"
    end
  end
end
 
class MiClase
  include MiModulo
end
 
puts MiClase.mi_metodo_de_clase
puts MiClase.new.mi_metodo_de_instancia

Como vemos, definiendo el método included dentro de un módulo, podemos especificar un comportamiento que se ejecutará cuando ese módulo sea incluido en otro módulo o clase. En este caso, cuando se incluye el módulo en tiempo de ejecución, en envían dos mensaje con send a MiClase para añadir los métodos de instancia(include) y de clase(extend).

Y con esta introducción y los ejemplillos, espero que entiendas un poco mejor cómo funcionan los módulos en Ruby .

Referencias

Lógicamente, esto no lo he inventado yo, sino que he consultado estos enlaces:

• Documentación de la clase Module de Ruby.
• Capítulo sobre módulos en Programming Ruby, The Pragmatic Programmer’s Guide.
• Sección sobre módulos, Ruby User’s Guide.
• Definición de programación modular, Wikipedia.

westartup es un evento que une a desempleados y emprendedores para impulsar ideas de negocio. El próximo evento se va a celebrar en Gijón, del 6 al 8 de mayo 2011.

¿En qué consiste el evento?

El evento consiste en desarrollar dos ideas de negocio, ver su viabilidad y hasta desarrollar prototipos del producto / servicio de la idea. Tanto si tu idea sale seleccionado como si no trabajarás en un equipo multidisciplinar, de forma ágil y aprendiendo constantemente. Apúntate, es una experiencia única.

¿Cuanto dura el evento?

El evento comienza el viernes 6 de mayo a las 16 horas y finaliza el domingo 8 de mayo con la cena de fin de westartup, dos días y medio intensos y llenos de experiencias que no te puedes perder.

¿Cómo es el proceso de Inscripción?

Se ha de mandar un correo electrónico a la dirección tuoportunidad@westartup.org para recibir las instrucciones para formalizar la inscripción

¿Es necesario presentar una idea de negocio para participar?

No, no hace falta. Los asistentes que no quieran presentar una propuesta son bienvenidos igualmente. Podrán participar en las votaciones de selección de ideas y luego trabajar en la idea que prefieran de las dos ganadoras.

¿Qué tiene además de novedoso este evento?

En este evento se va a aplicar Scrum (metodología ágil) para el desarrollo de las dos ideas de negocio, esto permite disponer ya de una primera beta del plan de empresa el sábado para posteriormente redefinirlo el domingo. Por tanto los asistentes se benefician además de la experiencia de trabajar en un entorno ágil con una metodología ágil.

El evento está organizado por la asociación ImpulsaTIC (formada por: Inxeniu Internet Media, Domótica Davinci, Gedpro, Iniciamedia y Cowork Asturias).

Tenéis más información en la página oficial westartup: http://www.westartup.org/

En esta entrada explico mis primeros pasos con Ruby Version Manager (RVM), una aplicación que nos permite gestionar fácilmente varias versiones de Ruby y agrupaciones de gemas. Mi intención es ir “migrando” poco a poco a la versión 1.9.2 de Ruby y a la versión 3 de Ruby On Rails y durante un tiempo voy a tener que convivir con ambos entornos… De momento todo esto me ha funcionado bajo Mac OS X.

Instalación

Ejecutamos el siguiente comando:

bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

Añadimos la siguiente línea al fichero de configuración ~/.bashrc, teniendo en cuenta que no haya ningún “return” antes:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"  # This loads RVM into a shell session.

Si abrimos un nuevo shell y ejecutamos el comando rvm, deberíamos ver la descripción del comando y modo de uso. Ahora deberíamos instalar una versión de Ruby, por ejemplo la versión 1.9.2:

Instalación de Ruby

rvm install 1.9.2

Ahora ya podemos indicarle al sistema que use la versión de ruby de RVM:

rvm use 1.9.2

Si ejecutamos la orden:

which ruby

Veremos que ya no apunta a /usr/bin/ruby, y si listamos las gemas instaladas veremos que ¡no hay ninguna!. Podríamos volver a la versión del sistema fácilmente, con:

rvm system

Si queremos seleccionar una versión por defecto para nuestro shell, podemos hacerlo con el flag –default:

rvm --default use 1.9.2

Gemsets

Ahora llega la parte interesante, la opción de crear gemsets, que son agrupaciones de gemas. Por ejemplo, podríamos tener en un mismo sistema 2 gemsets, uno con las gemas de rails 2.3.8, y otro con las gemas que tienen que ver con la versión 3 de Rails. Al instalar una versión de Ruby, RVM crea por defecto el gemset de nombre ‘Global’ y es el que se usa por defecto si no se lo indicamos explícitamente otro (como en el siguiente ejemplo). Para crear un gemset y empezar a usarlo:

rvm gemset create rails3
rvm use 1.9.2@rails3

Podemos ver los gemsets que hemos creados con:

rvm gemset list

Ahora ya podemos instalar la gema de Rails3 y todas las gemas que nos hagan falta. ¡Anímate a probarlo! Es my sencillito. Y ahora… ¡a enredar un poco con Rails 3!

Por fín he terminado de leer Clean Code, el famoso libro de Robert C.Martin a.k.a. Uncle Bob, que algunos conoceréis por ser uno de los autores del manifiesto ágil. Después de haberme encontrado con innumerables referencias al libro – tanto en twitter, como en algunos blogs que sigo habitualmente (que ahora recuerde este de @kinisoftware y este de @jacegu) – me propuse leerlo como uno de los objetivos para este año.

Escribir código que funciona es una tarea relativamente sencilla. Lo difícil es escribir código que, con el tiempo, no se convierta en un “chorizo” imposible de ampliar y/o mantener, y que sea entendible por otros programadores. En Clean Code, Uncle Bob nos explica su visión del buen código: el código limpio.

Resumiendo mucho, un código limpio (y bueno según el autor):

• Incluye nombres significativos en variables, funciones, clases, etc.
• Incluye funciones con responsabilidades bien diferenciadas, los parámetros justos, un nivel de abstracción uniforme.
• No repite código.
• Está autodocumentado, por lo que no es necesario usar comentarios.
• Está bien diseñado. Por ejemplo, hace uso de interfaces en vez de implementaciones concretas.
• Tiene bien separado el manejo de errores para que esto no interfiera en la comprensión del código.
• Se integra bien con otras aplicaciones, manteniendo limpias las fronteras y transformando la información externa en objetos de nuestra aplicación.
• Está cubierto al 100% por una batería de tests que comprueban todos los posibles caminos de ejecución.
• Está dividido y organizado en clases de un tamaño justo con responsabilidades bien definidas.
• Separa claramente la construcción e inicialización del sistema de lo que es la ejecución en sí.
• Crece de una forma sostenible, es decir que la arquitectura evoluciona incrementalmente y el código no va degenerando sino todo lo contrario, con cada cambio es más “fino” y siempre cumple las 4 reglas de Kent Beck para escribir código limpio.

El libro está repleto de código escrito en Java. Hay 2 capítulos donde Uncle Bob explica las refactorizaciones de una clase de JUnit y la clase org.free.date.SerialDate. Estos ejemplos son muy educativos, aunque exigen bastante atención.

En general no es un libro “de piscina” ni “de váter”, sino que requiere bastante esfuerzo: reeler los ejemplos para entenderlos, subrayar y tomar notas, consultar referencias, etc.

Me ha gustado por que no sólo te explica cómo escribir si no que tiene bastantes referencias y conceptos como la Ley de Demetrio, Desarrollo guiado por pruebas (TDD) y las reglas F.I.R.S.T., Separation of Concerns, Single Responsability Principle (Principio de Responsabilidad Única), Open-Closed Principle, Inversion of Control y el patrón Depency Injection, Domain Specific Languajes, etc.

También ayuda a ver y compreder algunos patrones de diseño como Abstract Factory y Adapter (Wrapper).

El último capítulo incluye una referencia de “Smells and heuristics”, que son una ampliación de los Code Smells del libro de Refactoring de Martin Fowler y que sirve como muy buen resumen del resto del libro.

Sin duda, Clean Code puede marcar un antes y un después en tus capacidades de programación si lo estudias con dedicación.

Y cómo la práctica hace al maestro, ¡ahora toca practicar!

Últimamente, están proliferando aplicaciones web que te permiten aglutinar fácilmente tu biografía y tu presencia online (cuenta de twitter, facebook, linkedin, etc) en una página personal. Algunas de ellas te permiten incluso configurar un dominio personal. Gracias a las posibilidades de personalización del aspecto final de la página, y usando un poco nuestra imaginación, el resultado puede ser muy bonito.

Estas son las 3 aplicaciones que conozco a día de hoy, ordenadas según mis preferencias:

About.me

Flavors.me

Myegoo.com

Y a tí, ¿cual te gusta más? ¿conoces alguna más? Te invito a comentar esta entrada y prometo ir ampliando la lista. ¡Gracias!

Resumiendo, las 12 tendencias que proponen son:

1. “Barcos salvavidas” para la inundación de aplicaciones. La red está inundada de aplicaciones y será necesario desarrollar mecanismos que permitan a los usuarios buscar y encontrar las aplicaciones que mejor se adapten a sus necesidades. Una consecuencia de la sobrecarga de información.
2. “Experiencias líquidas”. Experiencias que pueden ser experimentadas desde cualquier pantalla. Por ejemplo, el mecanismo de Amazon para que, independientemente de la pantalla que uses para leer los libros de Kindle, sigas leyendo en el punto en que lo dejaste. O el botón “Me gusta” de Facebook, que aparece ya en millones de contenidos y aplicaciones.
3. Reinvención de las revistas digitales, para que se adapten a los nuevos dispositivos (tipo tablets) tanto en lo referente a modelos de negocio, como en sus formas, diseño, vocabulario, etc.
4. Uso de juegos para las tareas cotidianas. En este sentido recomiendan estar atento a los próximos movimientos de Foursquare. Esto me recuerda a los vídeos y experimentos de The Fun Theory.
5. Proliferación de los objetos inteligentes, también conocido como El internet de las cosas.
6. Desarrollo de super-teléfonos. Cada vez más, los teléfonos serán capaces de renderizar gráficos en 3D e incluso imágenes proyectadas por el propio teléfono.
7. Nuevas necesidades para la gestión de información sobre la vida de las personas en la red. Estos últimos años mucha gente ha compartido información sobre su vida personal en la nube y en Fjord creen que será necesario que haya agentes que se dediquen a aglutinar toda esa información de cada persona.
8. Uso de teléfonos móviles como tarjetas de crédito.
9. Cambios en nuestra forma de trabajar debido a la proliferación de los Tablets, que tenderán a convertirse en herramientas de trabajo de uso cotidiano.
10. Aparición de nuevos formas de pago a través del móvil: subscripciones, micropagos, cupones, etc. En definitiva, uso del móvil como monedero para pequeños pagos.
11. “La nube se transforma en una cometa”. Hay mucha información ya en “la nube”. Aparecerán nuevos servicios y mashups que introduzcan nuevas formas de relacionar y visualizar toda esa información.
12. Batalla de los fabricantes para entrar en nuestros salones. Nuestros salones tienden a acumular cada día más dispositivos y entretenimientos: televisores en 3D, Tablets, Internet en la televisión, etc. Seguirán surgiendo nuevas formas de interacción y control remoto de todos estos aparatos.

Algunas de sus propuestas son ya parte del presente. En cualquier caso, todos estos campos tienen muchas posibilidades de desarrollo y mucho potencial. Si quieres ser innovador, ya sabes: ¡a darle al coco y a currar!

• Pass all tests.
• Clear, expressive & consistent.
• Duplicates no behavior or configuration.
• Minimal methods, classes, & modules

Cuya traducción al castellano vendría a ser:

• Estar bien cubierto y satisfacer las aserciones de una buena batería de tests unitarios.
• Expresar las ideas que nosotros como programadores queremos expresar (código auto-documentado).
• Decir cada cosa una única vez (DRY -> Don’t Repeat Yourself).
• Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro (You ain’t gonna Need it -> YagNi); y tener el mínimo número de clases y métodos (teniendo en cuenta el Principio de Responsabilidad Única).

Me he enterado de la existencia de estas reglas gracias al libro Clean Code, que llevo tiempo leyendo y que mucha gente considera de obligada lectura para cualquier desarrollador de software.

Ya he terminado de leer Ha llegado la hora de montar tu empresa, el nuevo libro de Alejándro Suárez, donde hace un repaso general de todos los pasos que hay que seguir para emprender un negocio. Esta es mi ficha del libro.

¿Por qué lo leí?

Hace tiempo que barajo la posibilidad y siento muchas inquietudes por montármelo por mi cuenta. Desde entonces, vengo formándome en estos temas, leyendo otros libros como El libro negro del emprendedor y acudiendo a eventos como Iniciador (ahora en Asturias). La recomendación, por parte de Javier Martín (Loogic) me impulsó a comprar el libro y tengo que reconocer que me lo merendé en un viaje de ida y vuelta en tren Gijón-Madrid

¿A quién se lo recomendaría?

Se lo recomendaría a cualquier persona que tenga en mente montar su propio negocio y tenga dudas sobre el proceso: ¿cómo buscar financiación? ¿qué tipo de sociedad constituir?, ¿con qué ayudas podemos contar?, ¿qué errores son los más comunes?, etc.

Resúmen

El libro divide el proceso para convertir una idea en emprendimiento de la siguiente forma:

1. Evaluación de tus capacidades como emprendedor.
2. Búsqueda y análisis de la idea de negocio.
3. Toma de la decisión de lanzarse a emprender.
4. Elaboración del plan de empresa.
5. Emprendimiento en sí.

En cada uno de los pasos, Alejandro aporta ejemplos y casos concretos: algunos extraídos de su propia experiencia como emprendedor e inversor; y otros extraídos principalmente del negocio anglosajón (Amazon, Apple, etc). Y no duda en hablar también de sus fracasos.

A lo largo de todo el libro, y más a fondo en el último capítulo, Alejandro hace una evaluación de la situación de la cultura empredora en España. Concretamente nos expone los errores más comunes de los emprendedores españoles y analiza porqué en este país no hay más personas que, en vez de aspirar a convertirse en funcionarios, optan por el camino de convertirse en “hombres echos a sí mismos” (self-made men). La conclusión es que tenemos que dejar de ver al empresario como un explotador y empezar a verlo como alguien que ha asumido unos riesgos, ha pensado en grande y ha conseguido generar empleo.

Me ha gustado el tono con el que Alejandro se dirige al lector (de tú a tú). Desde mi punto de vista se trata de un libro aséptico en el sentido de que no te va a animar a dar el paso, pero sí que te puede aclarar muchas dudas para que te animes a hacerlo.

En la página del libro, se ofrecen una serie de descargas complementarias. Es interesante la plantilla para elaborar el Plan de Empresa, cuyos distintos apartados se explican a lo largo del libro.

Para cerrar este post, incluyo un vídeo (3:22 min) con uno de los ejemplos de motivación de los que habla Alejandro en el libro: la historia de la última carrera del atleta olímpico Derek Redmond en las olimpiadas de Barcelona 92: