Esta semana vuelve la BetaBeers, cómo cada mes. Y en esta sesión volvemos a estar al pie del cañón para presentaros qué hacemos y cómo lo hacemos. En esta ocasión será el riguroso Lluís Barceló (@ebotey) quién entrará en escena para hacer el croquis de Emagister y de @EmagisterTech.

Para la ocasión vamos a asistir unos cuantos miembros del equipo y nos hemos hecho unas camisetas, las camisetas del #rigor, para dar apoyo a Lluís. Así que si veis a alguien con una camiseta oscura, por delante el hashtag #rigor y por detrás @EmagisterTech, no tengáis dudas. Somos nosotros.

Sin duda el evento promete, tanto por la charla inicial cómo por la presentación del resto de proyectos, además del nuestro. Así que, desde aquí, os animamos a asistir!

Estoy ejecutando una migración de svn a git (git svn clone…) en el que va a ser nuestro nuevo servidor de desarrollo, son las 20:44, me quiero ir a casa, el proceso va por la revisión 15146 y hay un total de 26000, lo que significa que todavía le falta un rato. Como soy un poco agonías, he ejecutado el proceso sin nohup, así que si cierro el terminal, la líamos parda…

Solución

job running...
[ctrl]+z
>$ bg
>$ disown -h


Ale, pa casa!

Referencias

http://web.mit.edu/gnu/doc/html/features_5.html

http://www.quantprinciple.com/invest/index.php/docs/tipsandtricks/unix/jobcontrol/

La idea es que podéis hacernos alguna oferta sobre cualquiera de las máquinas (depende del componente entre 50€ y 150€). Podemos quedar y bajároslo a Barcelona. Si necesitáseis factura, os podríamos hacer una, aunque habría que sumarle el IVA.

Lo más divertido es que podéis explicarnos vuestro proyecto y prometer añadir unos agradecimientos en vuestra página con un link a nuestro blog. Si lo hacéis, evaluaremos las propuestas más divertidas y os regalarémos el hierro en el que estéis interesado.

Como compréndereis, el hierro no tiene garantía pero funcionan y funcionan bien. Cualquier duda, nos podéis enviar un mail a php@emagister.com.

Os paso el listado de hierro:

Rendimiento

El equipo de sistemas ha estado haciendo pruebas con Apache 64bits viendo mejoras entre el 15% y 30%, hemos implementado la gestión de Etags (304), hemos cambiado los banners de SmartServer en Argentina por los de Google con DFP Small Business (unas mejoras de UX muy notables en términos de deferring y bloqueo), así que en breve subirán al resto de los países, hemos migrado 100% a Libmemcached (binary protocol + igbinary + no blocking + no compression) y el sprint que viene los deamons correrán en modo binario (para evitar la negociación de protocolo) y hemos experimentado con phps como modo de respuesta del Solr.

Curiosidades

Debido a un error, una de las máquinas de Italia, tenía 40 megas de memory limit en la configuración de PHP. Lo bueno es que no generaba ningún problema, ¡lo que nos llamó la atención! así que queríamos dedicar unas palabras a todos aquellos que dicen que los framework como Symfony o Zend consumen mucha memoria.

Charlas

Ricard, Christian, Lluís y yo estuvimos en la Symfony Barcelona de este mes. Marcos Quesada hablaba sobre Caching en Symfony 2, tocando muchos temas como Varnish con ESI, APC, Memcached, CDN, etc. Os recomiendo que miréis la presentación y lástima que no se grabaron los debates posteriores que fueron muy animados (http://www.symfony-barcelona.es/eventos/show/6).

Formaciones

Ya sabéis que los viernes hacemos formación, pues durante este sprint hemos conocido Pimple (el contenedor de injección de dependencia de Symfony), Silex (el microframework de Symfony) y cómo debugar peticiones contra Solr. Necesito que me ayudéis a convencer a Oriol para que pueda impartir su formación de Pimple y Silex en alguna Symfony Barcelona, es un poco tímido, así que comentar en este post, para que se anime a presentar. Sobre el debugging de peticiones a Solr, Iker está a vuestra disposición si necesitáis alguna cosa, simplemente brillante, super práctico y muy útil.

En resumen, un buen sprint. Muy satisfechos y expectantes de ver quién gana la porra del Barça vs. Madrid. Buen fin de semana a todos!

Introduction

The Developer Dice is thought for throwing it each time any developer in your team get stuck with a problem. It will show you the path.

Building it

1. Get a medium size box
2. Write on each side the sentences you want

Suggested sentences

Feel free to use your own sentences based on what your team needs.

1. Review the specification
When developers don’t have proper specifications, we complain, when we have them, we don’t read them. This is the same as reading user manuals, if you have to, you are not a real man. But from time to time, it’s nice to review the spec, use cases, etc. in order to guarantee that you are not missing anything. One step backwards to see the forest, not the tree.

2. Check with the stakeholder
Maybe you are doing it right and there is something wrong with the user story, product definition, etc. so stand up and visit the stakeholder, phone him, etc. share what it’s not gearing with him and together you’ll see the light.

3. Write a UnitTest
If you are developing, you should be writing unit tests. Because TDD forces you to play with coupling/decoupling and SOLID concepts, you can jump to a and come back.

4. Ask for a code review
4 eyes can see more than 2! Invite a mate to check your code and listen his opinion. Open your mind and your ears, any comment is welcome.

5. Document in the Wiki
Saying that a User Story is done, means coded, unit tested and documented. So, if you get stuck, create that wiki page to explain the technical approach to your mates or what configurations your feature has and how to use them to have a mental break.

6. Take a break
Of course! From time to time, you need to rest. If you don’t see the solution, just stand up, walk around, make a cup coffee and then come back. You will see how evertyhing is clearer. But, don’t roll the dice n times so you get this side, don’t trick!

If you build your own Developer dice, please send us a picture to php@emagister.com or comment with a link to your picture!

Load average

El load average tiene mucha afectación. ¿Notáis algo a partir del 28 de Febrero? Se puede apreciar mejoras entre el 20% y el 50%.

Consumo de memoria

Máximo aplauso para el amigo Derick, no se aprecia nada, no hace falta ni que ponga el gráfico.

Conclusión

1. Revisar vuestra configuración, por si se os ha escapado Xdebug en Producción.

2. Si sólo utilizáis xdebug para pintar de manera bonita los var_dumps, los E_*, etc. revisadlo, vuestra máquina de desarrollo o servidores de integración, staging, etc. podrían estar consumiendo CPU para hacer otras cosas más interesantes.

Recursos Extras

http://web.performancerasta.com/php%E2%80%99s-xdebug-tracing-overhead-in-production/

Algunas start-ups muy interesantes compartieron sus modelos de negocio y sus arquitecturas técnicas. A destacar, personalmente, changeyourflight.com.

Pues bien, tuve el placer de que me invitaran a chalar durante 1 hora sobre Agile y Scrum y el resultado lo tenéis en youtube:

Empecemos por la inicialización:

$ php -a

Interactive shell

php >

¿Fácil, no?. Y nada más, ahora toca empezar a escribir algo de código . Recuerda usar el caracter “;” para terminar una instrucción. Para seguir escribiendo dentro de funciones, bucles, etc, puedes usar el salto de línea.

php > echo 'hola emagisteers!';

hola emagisteers!

php > if (true) {

php { echo 'Ejemplo de condición';

php { }

Ejemplo de condición

php >

Una ventaja del Interactive Shell es que tiene la función de autocompletar mediante tabulación, y funciona tanto para variables como funciones, clases o constantes.

Mediante las teclas arriba/abajo te puedes mover por el historial de instrucciones ejecutadas.

Las funciones creadas por el usuario no se mantienen entre sesiones, y del mismo modo, si estás haciendo diversas pruebas sobre la misma sesión, puede haber código ejecutado anteriormente que afecte al flujo actual de ejecución (alguna variable o constante inicializada anteriormente que pueda alterar tu valor esperado), así que hay que tenerlo en cuenta para evitar posibles resultados imprevistos.

Para salir de la interfaz, tan sólo hay que ejecutar exit; o bien usar la combinación Ctrl + C.

También puedes usar php -r para lanzar una simple línea de php:

$ php -r 'echo "Hola emagisteers\n";'

Hola emagisteers

Usos del Interactive Shell

Aunque a partir de la versión 5.4 se incluya un pequeño Servidor Web, vale la pena seguir usando el Interactive Shell en muchos casos.

• Probar código: Verificar resultados de funciones, operaciones, precedencias de operadores, etc. se hace muy sencillo y rápido. Puedes copiar directamente código del manual de PHP y pegarlo en la consola, ejecutándose sin problema.
• Enseñar, aprender: Tanto si estás aprendiendo PHP, como si quieres enseñar su funcionamiento a alguien, el Interactive Shell es muy útil para mostrar ejemplos rápidamente, sin tener que montar un entorno de pruebas. En nuestro equipo fue especialmente útil cuando preparamos la certificación de Zend PHP.
• Soporte al desarrollo: Dispones de tu entorno de desarrollo local, pero tener una consola con la interfaz abierta hace que pruebes mucho más rápido aquellos casos en los que te queda una pequeña duda, sin tener que recargar la página ni introducir pruebas en tu código fuente.
• Autocompletar: La mayoría de IDEs actuales disponen de soporte para la nomenclatura de funciones, pero en ocasiones estos utilizan muchísima memoria y se hacen lentos incluso para operaciones sencillas. En alguna ocasión, cuando más o menos recordáis el nombre pero no con total exactitud os puede ahorrar tiempo.

PHP como Shell Script

Desde CLI puedes ejecutar scripts escritos en PHP mediante:

$ php my_script.php

De todos modos, podría ser útil en alguna ocasión que el fichero se pudiera interpretar del mismo modo que un Shell Script. Pues bien, esto es posible definiendo en la primera línea de código el interprete de comandos que se va a utilizar:

#!/usr/bin/php

<?php echo "Hola de nuevo!\n"; ?>

Así, podremos lanzar el script (recuerda que debes tener permisos de ejecución) de esta forma:

$ ./my_script.php

Hola de nuevo!

Referencias

PHP Manual

http://php.net/manual/en/features.commandline.interactive.php

10 Examples To Inspire You To Use PHP Interactive Shell

http://www.techchorus.net/10-examples-inspire-you-use-php-interactive-shell

phpsh, una alternativa por facebook con acceso a la documentación:

http://www.phpsh.org/

Executing PHP files

http://php.net/manual/en/features.commandline.usage.php

En algunas de mis presentaciones en las que hablo sobre la Certificación Zend PHP, siempre existe alguien del público que hace la misma pregunta, “¿vale la pena?”, pero no sólo en presentaciones, también en grupos de LinkedIn o foros, así que imagino que tanto si soys desarrolladores como tech leads puede que os estéis haciendo la misma pregunta… pues ahí van algunas respuestas.

Q. ¿Compensa?

A. Sí, compensa, pero hay que tener en cuenta algunos matices que explico con las siguientes respuestas.

Q. ¿Me va a ayudar a encontrar trabajo?

A. Para encontrar trabajo no os va a ayudar, ya os lo digo ahora. Tal y como están las cosas (mucha demanda), podréis acceder a cualquier puesto sin necesidad de tener la certificación aunque nunca se sabe si la cosa se pondrá un poco más complicada. Mi sugerencia es que si PHP forma parte de tu cinturón de herramientas y no te va de 195€, no lo dudes! La percepción desde un punto de vista de entrevistador es que estás preocupado por tu desarrollo profesional y ser más competitivo, en mi opinión, muy buenos inputs.

Q. ¿Va a ayudarme a mejorar mis conocimientos?

Sí, definitivamente, incluso el desarrollador más profesional siempre encontrará algo interesante que aprender, os lo garantizo. Pero no sólo aprenderéis más, sino que consolidaréis lo aprendido y profundizaréis más en lo que ya conocéis. Es evidente! si inviertes unas cuantas semanas de tu tiempo a estudiar, repasar y profundizar sobre un tema serás más competitivo, tendrás más visión y serás capaz de aportar más a tu trabajo y tu equipo. En resumen, todos aquellos que todavía no os habéis puesto con los namespaces u otras curiosidades, ya va tocando y es una muy buena excusa.

Q. ¿Qué beneficios extras tengo?

Creo que el más interesante es una licencia de por vida al Zend Studio 9, que en mi opinión, funciona bastante bien. Me parece un argumento de peso.

Q. ¿Vale la pena que pague la certificación a mi equipo?

Totalmente! Hablando con mi equipo después de certificarse la frase más común era “noto que ahora sé más, conozco PHP mucho mejor”. Me resulta difícil dar un número, pero estoy seguro que tiene impacto en la generación de bugs, el rendimiento, la arquitectura, etc.

La respuesta final la tenéis vosotros.

Presentaciones sobre certificación Zend PHP:

- http://www.slideshare.net/carlosbuenosvinos/certificacion-zend-en-vivo-php-barcelona-2008

- http://www.slideshare.net/carlosbuenosvinos/zend-php-53-demo-certification-test

En los entornos actuales de desarrollo Web, donde el tiempo es un factor clave para no perder la oportunidad de negocio, y el volumen de trabajo es increíblemente grande, muchos equipos que implementan SCRUM suelen adaptarlo en base a sus necesidades, y la reunión de retrospectiva suele caer en el olvido fácilmente. Se recomienda encarecidamente seguir todas y cada una de las reglas de SCRUM para que éste pueda funcionar fluidamente. En este caso, me gustaría remarcar porqué esta reunión debería ser imprescindible en cualquier equipo de trabajo.

¿Cómo funciona?

Es común que la reunión de retrospectiva sea la segunda parte de la Sprint Review Meeting, y suele durar un par de horas. En nuestro equipo técnico acostumbramos a reducirla a 1h o 1’30h en función de la cantidad de puntos tratados.

Se elige una miembro al azar que ejerza el rol de moderador o facilitador de la reunión. El equipo completo se reúne en una sala y cada uno de ellos expone 3 puntos con los que está contento o crea que hayan avanzado durante el Sprint y 3 puntos en los que crea que se deba mejorar. El facilitador se ayuda de una pizarra y separa en dos columnas (Good / Bad ) los puntos mencionados, incrementando mediante votos si más de una persona está de acuerdo con un punto. Al finalizar la ronda, tendremos una lista de puntos positivos y negativos ordenada en función de la importancia de cada uno (más votos, más importante).

Esta primera parte suele ir rápido, y es increíblemente enriquecedor ver cómo cada vez más el equipo se va alineando con los problemas que han surgido y el pensamiento de equipo prevalece sobre el pensamiento individual.

El resto de tiempo de la reunión suele ser variable, pero acostumbramos a recoger los puntos a mejorar, discutirlos brevemente e intentar aportar acciones y personas para mitigar dicho punto. Hay que remarcar que es clave que todos los puntos acaben en acciones y con un responsable, siendo revisadas en el siguiente Sprint, para que ésta pueda desarrollarse en el Product Backlog y no caiga en el cementerio de “los problemas que siempre han ido así y no va a cambiar”.

¿Cuando realizarla?

La reunión se realiza en la parte final del Sprint, cuando las tareas han sido entregadas y se ha realizado la demostración de éstas. Es preferible hacerlas a última hora de la tarde, siempre que todo el equipo esté de acuerdo, para que interrumpa lo mínimo la producción y la segunda parte de discusión pueda alargarse tanto como los asistentes prefieran.

En ocasiones, es útil crear retrospectivas para proyectos grandes que no tienen cabida en un sólo Sprint, e invitar a miembros de otros equipos que hayan participado, con el fin de mejorar el flujo de comunicación entre departamentos y entender lo que necesita cada uno de nosotros.

¿Cómo prepararla como miembro del equipo?

Es importante que nos anotemos en nuestra agenda todo aquello que nos ha afectado negativamente o en positivo nuestro desempeño. ¿El entorno de desarrollo va muy lento?. ¿Algunos miembros del equipo han hecho un sobreesfuerzo excepcional y quieres hacerlo ver? ¿Nos ha fallado la comunicación con otro departamento? Anótalo en el mismo momento, y antes de la reunión revisa que tus puntos son interesantes para la mejora del equipo.

Y no sólo va de exponer tus puntos, sino también de aportar posibles soluciones. Piensa en cual es la mejor solución y aporta con tus propuestas.

¿Qué nos aporta la retrospectiva?

Realizar reuniones de retrospectiva de forma frecuente tiene muchos beneficios que aporta tanto a la compañía como a las personas:

• Mejora la confianza: El equipo conoce sus puntos fuertes y debilidades, y los miembros comienzan a reconocer sus inquietudes. Empieza a fluir la sensación de que las propuestas son escuchadas.
• Mayor implicación: Los problemas se abordan de forma directa, y todos son responsables. La compañía ahora conoce las posibles amenazas del equipo y tiene propuestas para mejorar la productividad.
• “Pulveriza rocas“: Hay problemas que se arrastran de forma permanente como si de una roca se tratara. Tratándolo en una retrospectiva con una parte de los votos del equipo hará notar de la importancia de la solución de dicho problema.
• Valorar personas: En ocasiones, se puede aprovechar para valorar el esfuerzo de algunos miembros o equipos y hacerlo notar al resto del equipo. Las posibles tensiones o problemas personales es mejor tratarlos de forma individual.
• Visibilidad global: Enviad la tabla de Good/Bad/Actions al resto de la compañía o dirección y dad una visibilidad a todos de cómo afrontáis cada tipo de situación.
• Objetivo de mejora de ejecución: Cabe recordar que el primer objetivo de la reunion es el de mejorar la ejecución de vuestro equipo. Producir más en menor tiempo, ya sea cambiando prioridades, solucionando distintos problemas, motivando al equipo o simplemente asignando responsables.

Éstos son algunos puntos en que se muestran resultados beneficiosos de la retrospectiva. Es muy importante recordar la importancia de las acciones y sus responsables, realizar un seguimiento y dar un margen de tiempo adecuado para su realización. Si dichas tareas caen en el olvido, parte del equipo perderá la confianza en la metodología y caerá en la tentación de no hacerla más.

De todos modos, viendo la gran cantidad de mejoras que puede llegar a aportar a tu compañia, ¿no merece la pena darle un voto de confianza?

Photo source: Natural-Heart http://flic.kr/p/anv1y3 (cc)