TDD – ¿De adentro hacia afuera o de fuera hacia adentro?

Hace unas semanas estuve en un Merendojo de Madrid Software Craftmanship (desde aquí gracias a los organizadores Luís, Pablo y el resto de personas) y después de la kata estuvimos discutiendo distintos enfoques sobre como afrontar el problema. En un momento de la conversación surgió el tema de como afrontar los test, por donde empezar, desde dentro hacia afuera, haciendo test desde la parte más externa posible,… la verdad es que la charla fue bastante interesante y me picó la curiosidad sobre como afrontar los test y como hacer TDD cuando tienes un problema grande. Así que buscando en Internet encontré este interesante post TDD – From the Inside Out or the Outside In? de Georgina Mcfadyen y me he animado a hacer una traducción libre.

A menudo la parte más difícil de programar es saber por donde empezar. Haciendo TDD (Test Driven Development) la mejor lugar de empezar es con un test, pero estar delante de una página en blanco puede ser desalentador.

¿La mejor manera de empezar es por los detalles de lo que está construyendo, y dejar que la arquitectura vaya emergiendo con un enfoque de adentro hacia afuera (Inside Out)? O bien, empezar por algo grande y dejar que los detalles vayan revelando a medida que se van usando desde afuera hacia adentro (Outside In)

Sigue leyendo

Don’t be STUPID: SOLID and GRASP

Has oído hablar de SOLID? Seguramente: Es un término que describe una colección de principios para “buen código” que fué acuñado por Robert C. Martin (aka “uncle bob“) nuestro gran evangelista del “clean code”.

La programación está llena de acrónimos como este. Otros ejemplos son DRY(Don’t Repeat Yourself!) y KISS(Keep It Simple, Stupid!). Aunque obviamente hay muchos, muchísimos más.

Sigue leyendo

Cómo escribir un README que mole

A los desarrolladores les encanta compartir código en forma de paquetes, apps, o pequeños módulos. Compartir mola, pero una de las características que muchos desarrolladores olvidan son los archivos README. Este archivo es una de las piezas más importantes de los proyectos y muchos desarrolladores no invierten el tiempo suficiente.

Un README empezó como una guía para desarrolladores. Se podía acceder después de descargar el código y mostraba instrucciones relacionadas con la configuración, instalación, derechos de autor, solución a problemas conocidos y mucho más. Los repositorios de código populares empezaron a poner los readme como página principal del proyecto y se convirtieron de ser información técnica a ser directamente la presentación del proyecto. Este cambio significa pasar de ser documentos para desarrolladores a convertirse en herramientas de marketing con la información básica del proyecto.

Sigue leyendo

El cumpleaños del blog

El día 08/06/2011 publiqué mi primer post en este blog, un tímido y típico Hola Mundo que nada hacía presagiar que invertiría en este blog tanto tiempo y esfuerzo para llegar a más de 140 posts. En este post voy a contar un poco del camino recorrido para llegar hasta aquí.

¿Como empezó todo?

Tenía la carrera de ingeniería informática casi a terminar, con muchas ganas de hacer cosas pero con el objetivo puesto en sacar tiempo para el proyecto de fin de carrera. El blog empezó siendo un lugar donde anotar trucos, hacks, conocimiento que estaba desperdigado por la red y que escribía como pequeños apuntes para mi yo del futuro😉. En un principio eran solo hojas de ruta como cómo resetar un password de mysql, cómo desarrollar con Liferay en Eclipse, cómo dar más memoria a Eclipse así intentaba ahorrarme tiempo buscando en internet soluciones para poder centrarme en lo importarte realizar un proyecto fin de carrera.

14363173403_0bcff9b696_z

Sigue leyendo

equipos

Trabajar con un buen equipo es una de las mejores cosas que puede pasarnos, tener a nuestro lado a gente que sabe más que nosotros, que nos ayuda, nos guía, nos reta hace que cada día saquemos lo mejor de nosotros e intentemos superarnos. Todo lo que vamos a leer en este post son experiencias personales, sobre las características que creo debemos fomentar en los equipos de desarrollo software para que sean efectivos, abierto y por tanto mejores.

Formar un equipo no es algo que podamos hacer de la noche a la mañana fichando buenos profesionales, creo que crear un gran equipo de desarrollo es un camino que hacemos paso a paso, equivocándonos, fallando aprendiendo y mejorando. Ninguno de los siguiente puntos funcionan de la noche a la mañana y creo que funcionarán aun peor si son impuestos. Solo existe una cosa que podemos hacer y es trabajar, trabajar y trabajar para conseguir resultados, y no me refiero solo a entregas, proyectos, funcionalidades, sino a trabajar para mejorar el entorno de trabajo, las relaciones con los compañeros y en definitiva crear un clima de con de confianza en el que se mantenga la motivación con proyectos, planes e incentivos que nos hagan estar feliz en nuestro día a día.

Sigue leyendo

Preguntas sobre… en una entrevista a un “desarrollador”

Normalmente cuando te encuentras ante un proceso de selección para un puesto técnico, tanto siendo la persona que realiza el proceso como el que se presenta tienes que enfrentarte a una batería de preguntas durante la/s entrevistas.

En este post vas a ver una recopilación de preguntas que podrían hacerte en una pruebas de selección relacionadas con desarrollo software o programación en PHP. No tienes qué conocer todas las respuestas a estas preguntas, es más la honestidad en la respuesta diciendo “no lo sé” es algo (bajo mi punto de vista) muy a valorar en un proceso de selección. Son solo una batería de preguntas que puedes repasar si vas a enfrentarte a un proceso de selección.

Aunque antes de seguir debes tener en cuenta una serie de consideraciones: estas preguntas están sacadas de vivencias personales, comentarios con compañeros o compañías que tienen públicos sus procesos de selección. No soy un experto en recruiting ni pretendo serlo (seguro que cometeré algún que otro gazapo, te ruego que comentes en el post y lo corregiré encantado) solo quiero aportar mi opinión acerca de qué pueden preguntar en las entrevistas y lo más importante IMHO el porqué de estas preguntas.

Depende del perfil que estén buscando o al puesto que hayas aplicado creo las preguntas serán más técnicas, creo que a un perfil Junior puede que te realicen preguntas más técnicas solo por saber cuanta “hambre por aprender” demuestras. En cambio si estan en busca de un perfil más senior tendrás preguntas más sobre arquitectura, diseño, patrones o management.

Preguntas sobre “el puesto”

  • ¿Conocías la compañía? ¿Has podido ver que hacemos?
  • ¿Qué te interesa de esta posición?
  • ¿Qué puedes aportar a esta posición?

A nadie le gusta que le hagan perder el tiempo, si una entrevista no te interesa comentalo y si te decides ha hacerla aprende y busca más acerca de la empresa y del puesto. Es cierto que muchas veces las ofertas dejan bastante que desear pero somos libres de no aplicar si no nos sentimos atraídos por la oferta.

Preguntas sobre “conceptos software”

  • ¿Qué diferencia hay entre una cola(queue) y una pila(stack)?
  • ¿Que significa la expresión “pasar por referencia”?
  • Clases abstractas e interfaces ¿que diferencia hay?
  • ¿Qué es un ORM? ¿Qué es MVC? ¿Qué alternativas hay al patrón MVC?
  • ¿Te suena el concepto de dependencia de inyección? ¿inversión de dependencias?
  • ¿Qué patrones conoces aparte de Factory Pattern?
  • ¿Que diferencia hay entre un Mock y un Stub?

Habitualmente no es normal que conozcas al dedillo un lenguaje, que sepas todas las triquiñuelas que tiene, sobre todo si se trata de Javascript o PHP😉 por lo que tener preguntas sobre conceptos generales son muy normales a la hora de afrontar un proceso de selección.

Como hemos comentado antes, no es necesario que conozcas todas las respuestas, ya que son conceptos que pueden que no te suenen o que los hayas oído pero no tengas claro lo que son. Sé franco y responde con sinceridad.

Preguntas sobre “Agile”

  • ¿Conoces Scrum? ¿Kanban?¿eXtreme Programing?
  • ¿Conoces los roles y artefactos de Scrum?¿reunión diaria? ¿retrospectiva?
  • ¿Conoces conceptos Test Driven Development (TDD),Behaviour Driven Development (BDD) o similares?
  • ¿Estas familiarizado con el concepto de Pair Programming? ¿Y con Code Review?
  • Sabes algunas técnicas de refactoring ¿cómo lo afrontas?

Este tipo de preguntas son para ver si conoces estos conceptos o si anteriormente has trabajado bajo un “marco de trabajo” agile. No pasa nada si no has estado en una compañía que practique agile o algo que se le parezca siempre pueden explicartelo como hacen los chicos de Tecnilógica. Creo que estas preguntas solo advierten sobre cómo has trabajado antes y puede que sirvan al entrevistador cual ha sido tu bagaje anterior en cuanto al mundo agile.

Preguntas sobre “Ecosistema Desarrollo de Software”

  • ¿Que herramientas de automatización has usado? ¿Jenkins? ¿Phing? ¿Travis?
  • ¿Cómo despliegas en producción? ¿MagePHP? ¿Capistrano? ¿Ansistrano? ¿script personalizados? ¿Por FTP?
  • ¿Has oído hablar de Vagrant? ¿Docker? ¿Los has utilizado?
  • Estas familiarizado con los estándares de código PSR-2, Zend Standard
  • Autoload, ¿require o include? PSR-4
  • ¿Conoces Composer?
  • ¿Te suena PHPUnit? ¿Behat?

Aquí conocerán cómo o cuánto automatizas los despliegues a producción o si estas familiarizado con estándares de código (algo IMHO indispensable cuando se trabaja en equipo). Son características de tu manera de programar que quizás con una prueba de código no pueden verse al 100%.

Como indentas el código, si los nombres de variables son los aceptablemente buenos, si has utilizado tests, si sabes de que va eso de PSR4 y los namespaces, como resuelves un problema, como nos expresamos,… caracteristicas como esta son las que podrían verse en una prueba de código. Pero resolver por n-ésima vez Fibonacci o la kata FizzBuzz no creo que demuestren que seas un ninja de la programación.

Preguntas sobre “SQL y Bases de Datos”

  • ¿Qué diferencia hay entre una vista(View) y una tabla(Table)?
  • ¿Qué hace la cláusula HAVING?
  • Estas familiarizado con las bases de datos NoSQL

Depende del perfil que estén buscando estas preguntas serán más “rebuscadas” o irán a conceptos más básicos. SQL es muy amplio y pueden preguntarte relaciones con JOIN’s, MongoDB o incluso quizás con ejemplos.

Preguntas sobre tu día a día programando

  • ¿Linux, Mac, Windows?
  • ¿Cuál es tu framework favorito? ¿y el menos?
  • ¿Qué IDE usas?
  • ¿Control de código fuente? ¿Git? ¿Cónoces estrategia de branching como Git flow?
  • ¿Has utilizado algún bug tracker como Jira, Trello o similar?
  • ¿Cómo debugueas?
  • ¿Prácticas TDD, BDD o similar?¿PHPUnit?
  • ¿Estás habituado a tratar con código legado?
  • ¿Has trabajado en remoto?

Estas preguntas no son decisivas ni mucho menos, en mi opinión solo sirven para romper el hielo y/o relajar la tensión. Al final quien nos está entrevistando también programa o programaba y por ello conoce IDEs, herramientas y a partir de hay es fácil empezar a charlas de puntos afines o de discordia Linux vs Mac, PHPStorm vs Eclipse, Vi o Emacs,…😉;)

Preguntas “motivacionales”

  • ¿De tus trabajos previos qué te ha gustado más/menos?
  • Si tiene trabajo, ¿por qué quieres cambiar de trabajo? ¿Qué es lo que más valoras de un trabajo?
  • ¿Qué estás orgulloso de haber hecho en el trabajo? ¿A qué problemas de te has enfrentado?
  • Si tú fueras el entrevistador ¿qué cualidades valorarías más? ¿Qué es lo que más valoran de ti tus compañeros?

Estas preguntas son para determinar si la empresa y tu encajáis, si estáis buscando lo mismo ya que ahí estas contando lo que valoras en una compañía, lo que le pides a una compañía, si serías capaz de enfrentarte a los retos que la compañía tiene y cuanto puedes aportar a la compañía como profesional y como persona.

Consideraciones finales

Como he dicho al principio este post solo recopila una serie de preguntas que podrían hacerte durante un proceso de selección, no soy un experto en recruiting así que esto es solo mi visión personal desde un lado de la mesa. El hecho de que no sepas responder a una pregunta no va a excluirte del puesto automáticamente la idea detrás de estas preguntas es bajo mi punto de vista aprender a construir un discurso coherente con el puesto al que has aplicado basándote en tus experiencias profesionales. Es decir, avalado por tu curriculum y tus experiencias ser capaz de responder a estas preguntas de una manera honesta y sincera de tal modo que puedas 4

Sacando partido a Docker

Estoy cansado de instalar dependencias, que si npm, ruby, php56, php7,… y lo peor cuando cambio de ordenador y no tengo nada instalado y otra vez volver a instalar npm, ruby, php56, php7,… pero esto se acabó o al menos voy a intentar aliviar mi dolor sacándole más partido a Docker. Hace tiempo ya hablamos de Docker y empezamos con Docker tratando el vocabulario básico y poco después vimos como instalar Docker en Mac. Hoy vamos a montar nuestro propio container con las dependencias que necesitamos para un pequeño proyecto.

bpcnlo

 

El proyecto

Hace bastante que tengo ganas de probar angular y hacer algo pequeñito y por casualidad me encontré con este proyecto para tener un CV bonito así que me pensé que actualizar mi CV era una buena manera de probar Angular, utilizar bootstrap y gulp. Pero cuando me puse manos a la obra npm me dio pereza intalar node, npm,… en el Mac así que ¿por qué no crear un container con todo lo necesario?

Sigue leyendo