El ElePHPante se muda

26 noviembre, 2010 Deja un comentario

Pues eso amigos, que nos movemos de dominio! jeje, he montado en mi dominio personal un WordPress y, aunque aun estoy limando cosillas, quería compartir con todos vosotros, mis lectores, esta para mi gran noticia🙂 No sois muchos, pero bueno, jeje, lo importante es la calidad y no la cantidad😉

Os paso a dejar aquí los nuevos enlaces:

http://www.fperezp.com/blog

http://cronicas-de-un-elephpante.fperezp.com

No mireis la página que la tengo montada en plan guarro jeje. En los próximos días, semanas, quiero montar algo más apañado, así como generarme un CSS para el blog propio, a ver qué diseño se me ocurre😛

Pues lo dicho amigos, espero que sigamos viéndonos en este nuevo domicilio.

Un saludo a todos y gracias por vuestra atención ;)

Categorías:Varios

Scrum: cómo organizar tu primer Sprint

23 noviembre, 2010 Deja un comentario

Este blog se ha trasladado a http://www.fperezp.com/blog/. Puedes leer acerca de Cómo organizar tu primer Sprint Scrum aquí.

Hola de nuevo amigos! Bien, tras un fin de semana algo ajetreado y nuestro último post sobre frameworks php, volvemos a este mundo bloguero donde compartir mis experiencias frikiprofesionales🙂 En esta ocasión vengo por estos lugares perdidos de la mano de dios para compartir con vosotros cómo fue nuestra primera reunión Scrum de planificación de sprint. Sí, la primera. El pasado viernes comenzamos una nueva forma de gestión del trabajo en la empresa donde trabajo. Scrum nos llama mucho la atención, y creemos que puede ayudarnos mucho, muchísimo, a mejorar nuestra productividad, tanto individual, como colectivamente.

En este post no voy a tratar de daros la brasa con la teoría, algo que podeis incontrar en la propia wikipedia de una manera muy bien explicada. Aquí simplemente trataré de seguir el ejemplo de Henrik Kniberg (cuyo libro Scrum y XP desde las trincheras os recomiendo encarecidamente) dando una visión completamente subjetiva de mi experiencia a la hora de aplicar Scrum a un equipo de desarrollo software.

Bien, comencemos. En primero lugar dividiremos la preparación de esta nuestra primera reunión Scrum en dos partes: Infraestructuras y Definición de la Pila de producto.

  1. Infraestructura física: Vamos a necesitar varios elementos, sencillos, pero necesarios. Aunque parezcan triviales o poco importantes, hacen que nos centremos y tengamos mejor asimilado qué, cómo y cuándo debemos tener listos nuestros objetivos del Sprint. Esta estructura consta de:
    • Tablón de estado del Sprint. En este tablón vamos a definir diferentes áreas y veremos como avanza nuestro Sprint. Tendremos nuestras tareas organizadas en no comenzadas, en proceso, pendientes de chequeo, terminadas, etc. Nosotros hemos creido importante tener un apartado dedicado a chequeo para darle importancia a la correción tanto del back-end como del front-end del software implementado.

      Tablon Scrum Inicial

      Tablon Scrum Inicial

    • Tarjetas de historia. Son simples hojas de papel divisiones donde podamos poner las diferentes propiedades que van a definir cada una de nuestras historias. Estas tarjetas nos servirán luego para colocarlas en nuestro tablón y organizar nuestro sprint de una manera más visual y eficaz.

      Tarjeta de Historia Scrum

      Tarjeta de Historia Scrum

  2. Pasemos ahora a la definición de la Pila de producto. Antes de iniciar la reunión Scrum de planificación de Sprint, debe haber habido una reunión previa del Scrum Master con el Dueño de producto, en la cual se hayan designado las prioridades, que a su vez nos indicará el orden de las historias dentro de la pila de producto. Una vez las historias han sido ordenadas, es muy recomendable organizarlas físicamente, bien en un tablón, bien en una mesa. En nuestro caso las organizamos en una mesa.

    Pila de producto

    Pila de producto

Cuando ya tenemos organizadas la pila de producto, podemos comenzar con la reunión Scrum de planificación del Sprint. En nuestro caso hemos optado por un sprint de duración media-corta de 3 semanas. Creemos que nos da la suficiente libertad para poder desarrollar sin demasiadas reuniones que entorpecen el trabajo, pero que a la vez permite que la empresa tenga agilidad a la hora de sacar nuevos productos.

Pues bien, teniendo todo esto, es hora de que el equipo Scrum se ponga las pilas. Toca entender, analizar y definir qué podemos incluir en el sprint. Es muy recomendable, y diría que necesario, que el dueño de producto se encuentre presente en esta reunión, ya que es posible que la estimación que el equipo Scrum haga sobre el tiempo de desarrollo haga cambiar las prioridades dentro de la pila de producto, o que se decida dividir una historia en varias partes para incluir una parte en el sprint actual y el resto dejarlo para próximos sprints.

Aclaremos algunos aspectos antes de continuar. En la reunión de planificación vamos a repartir una serie de historias entre los diferentes componentes del equipo. Para ello debemos calcular la dedicación que tendrá el equipo y la duración en puntos de cada historia. Para el cálculo de la dedicación del equipo procederemos de la siguiente manera:

Días de dedicación de cada miembro * % de dedicación.

Por ejemplo, tenemos que en este Sprint el equipo Scrum estará compuesto por 4 personas:

Persona 1: 12 días hábiles

Persona 2: 11 días hábiles

Persona 3: 12 días hábiles

Persona 4: 10 días hábiles

Debemos tener en cuenta que existen días de vacaciones, días festivos, etc. Bien, a estos días hábiles debemos aplicarle el factor de dedicación. Por ejemplo, imaginaos que la persona 1 debe dedicarse también al mantenimiento de equipos informáticos. A esta persona, por ejemplo, le daremos una dedicación del 50%. Ahora imaginaos que la persona 4 debe dedicarse también a dar soporte telefónico a software. Le daremos una dedicación, por ejemplo, del 70%. De esta forma tenemos que la dedicación en término de puntos ideales del equipo Scrum será de:

12*0.50 + 11 + 12 + 10*0.70 = 36

Esto serían puntos ideales, pero debemos tener en cuenta que las personas no somos máquinas, y que el mayor valor que tiene Scrum es la de poder estimar una velocidad real de trabajo. Por ello debemos indicar qué porcentaje real vamos a ser productivos. En un principio, y dado que no tenemos con qué comparar, fijaremos el factor de conversión en 0.5. Lo ideal es alcanzar el 1 de factor de conversión, pero sabemos que esto no es posible. Por ello debemos marcarnos objetivos coherentes y reales. Nuestro objetivo en 2-3 Sprints será alcanzar un factor de conversión de 0.7. Bien, como hemos dicho, el factor de conversión de este primer Sprint será de 0.5, de modo que los puntos ideales se transoforman en

36*0.5 =  18 puntos de equipo

Estos 18 puntos son los que al finalizar la reunión de planificación de Sprint deben haber sido repartidos entre las diferentes historias de la pila de Producto, conformando de esta forma la Pila de Sprint.

Para la estimación de tiempo de desarrollo de cada historia, hemos optado por el poker de Scrum points. Es decir, cada miembro del equipo Scrum posee una serie de cartas con puntos escritos. Estos puntos son puntos ideales. Esto quiere decir que cada punto representa a un programador-dia ideal. Si, por ejemplo, creemos que cierta historia necesitará de 2 programadores trabajando a plena dedicación 3 días, para nosotros esa historia tendrá una estimación de 6 puntos ideales (2 programadores * 3 días ideales). Para cada historia, cada miembro del equipo elegirá una carta de su mazo con la puntuación que cree que tardará la historia y la pondrá boca abajo en la mesa. Una vez que todos los miembros del equipo Scrum hayan votado, el Scrum Master barajará las cartas y les dará la vuelta. De esta forma la estimación de tiempo de cada miembro no se verá condicionada a la estimación de los demás miembros Scrum, y a su vez podremos ver si alguien no ha comprendido el propósito de la historia. Si tenemos 4 miembros, y 3 votan, por ejemplo, 12, y uno vota 50, claramente el que  ha votado 50 no ha entendido algo ya que está pensando en hacer algo bastante más complicado que el resto. O es posible que el que ha votado 50 haya tenido en cuenta algo que a los otros 3 se les haya pasado por alto (bastante poco probable, pero posible a fin de cuentas). Hemos de dejar claro que la estimación de tiempo debe ser consensuada y aceptada por todos y cada uno de los miembros del equipo Scrum.

 

Distribución de historias

Distribución de historias

Continuemos. Ya tenemos la valoracion de tiempo de cada historia, su importancia, su alcance y los puntos del equipo Scrum. Ahora toca repartir las historias. Es importante que tengamos en cuenta el tiempo que cada miembro del equipo va a tener disponible, ya que no es coherente que si una historia tiene, por ejemplo 5puntos, se le asigne a la persona 5, que sólo tiene 3.5 puntos reales disponible durante todo el Sprint.

Pues bien, ya tenemos organizado nuestro primer Sprint. Ahora solo falta rellenar el tablón para poder llevar una organización más limpia y clara de las tareas e historias que se van completando. Aquí os dejo una imagen de nuestro tablón de Sprint relleno.

 

Tablon de Sprint Scrum relleno

Tablon de Sprint Scrum relleno

Ya os iré contando qué tal nos va, si planteamos alguna modificación al sistema inicial y si finalmente obtenemos los resultados esperados, que no son más que el incremento de la productividad.

Y listo, me despido por ahora. Espero que pronto volvais a tener noticias mías🙂

Un saludo a todos y gracias por vuestra atención😉

Frameworks PHP: ¿Propio o estándar?

17 noviembre, 2010 4 comentarios

Este blog se ha trasladado a http://www.fperezp.com/blog/. Puedes leer acerca de Frameworks PHP : Propios o estándar aquí.

Hola amigos lectores. Hoy quiero hablar sobre los frameworks en PHP, pero la verdad es que ya estoy un poco harto de leer posts sobre la conveniencia o no de usar frameworks, sus ventajas e inconvenientes, cual es mejor o peor… Creo que el enfoque es un poco equivocado. No se trata de si se debe o no usar un entorno de desarrollo, sino de si usamos un propio o uno ya prefabricado.

Aliñando PHP

Desde que comencé a escribir Crónicas de un Elephpante llevo dándole vueltas al tema de los frameworks, sobre todo tras mi fugaz viaje de 3 días a Barcelona para asistir a la phpConference. Allí conocí a mucha y buena gente de este mundo del desarrollo de aplicaciones web con los que estuve debatiendo sobre este asunto. En mi opinión ésta que hago es la pregunta clave, ya que a fin de cuentas, todos trabajamos con un framework; sólo nos diferenciamos en si el que usamos es uno que ha creado otra persona y es comercial, o por el contrario trabajamos con uno que nos hemos ido fabricando nosotros mismos.

Todos los que nos dedicamos al desarrollo sobre PHP acabamos teniendo un conjunto de funciones que nos generan el código de ciertos componentes que solemos usar con asiduidad. Este conjunto de funciones son las que conforman nuestro entorno de trabajo particular.

Yo personalmente considero que usar un framework prefabricado te ofrece muchas más ventajas que fabricarte tú uno propio. Cierto es que sobre lo que picas tú tienes total control, pero… ¿cuánto tiempo tardas en depurar y perfeccionar un código que puedes encontrar ya hecho, bien hecho, depurado y perfeccionado? ¿y customizable? Sirva de muestra un botón: ¿cuánto tiempo tardarías en generar un sistema de control de tiempo de ejecución de ciertas partes de tu código? Bien, es algo sencillo, que puedes tener listo, bien presentado y demás, en cuanto… ¿2 horas? ¿3? más o menos tadarás eso… y es cierto que es poco tiempo, pero es tiempo que podías haber invertido en otras tareas y no haciendo un código, que por poner un ejemplo, ya trae implementado symfony.

Algunos me diréis… ¿y qué pasa con la seguridad? Si tenemos un código base estándar, corremos el riesgo que sea roto y por lo tanto nuestro sitio web sea vulnerable. Sí, es cierto, corremos ese riesgo, pero no es menor que el que corremos con nuestro propio código. Sin embargo tendremos la ventaja que los frameworks generalistas tienen detrás una comunidad de usuarios que testean, depuran y sacan parches para ese tipo de errores mucho más rápido incluso que nosotros para nuestro framework particular. En general, considero que estamos mucho más protegidos usando este tipo de software que el propio.

Otra ventaja es la estandarización del entorno de desarrollo, lo que facilitará la incorporación de nuevos programadores al equipo de trabajo. Esta ventaja es más desde el punto de vista empresarial, ya que cuando contratamos a alguien deseamos que sea productivo lo antes posible. Si tenemos un framework propio, además del tiempo que debemos emplear en se empape del sistema, debemos perder una cantidad X de tiempo, y nada despreciable, en que el nuevo desarrollador se adapte y aprenda nuestro software.

Todo esto me lleva a pensar que el uso y adaptación a un framework comercial hace que aumentemos nuestra productividad general. Perdemos control sobre el código, pero ganamos tiempo que puede ser invertido en otros factores más importantes que hacer un código que nos genere formularios rápida y fácilmente. Esto ya está hecho, no pierdas el tiempo en ello, just do it.

Y esto es todo. Espero vuestras opiniones y me digais qué pensais vosotros, qué creeis que es mejor en terminos generales.

Un saludo a todos y gracias por vuestra atención😉

xClip: Copiar y pegar en el Terminal [Ubuntu]

16 noviembre, 2010 1 comentario

Este blog se ha trasladado a http://www.fperezp.com/blog/. Puedes leer acerca de xClip: Copiar y pegar en el Terminal [Ubuntu] aquí

Hola de nuevo! qué poco tiempo desde la última vez, no? Jeje, bien, todo a surgido porque @drwaky me ha preguntado en la última entrada sobre GitHub qué era xClip. Pues bien, esa herramienta no demasiado conocida es de mucha utilidad cuando estamos trabajando con el Terminal, ya que nos permite copiar al portapapeles cualquier salida que produzcamos.

En el ejemplo de GitHub, lo usábamos para meter en el portapapeles la clave RSA sin necesidad de estar ajustando con el ratón (sí amigos, es fácil, pero a veces parece que nos ha poseído alguien y no somos capaces de seleccionar justo lo que queremos) sin que se nos meta o escape algún carácter no deseado.

Veamos un ejemplo


ls -a | xclip

Bien, con esto hemos conseguido meter la salida del ls en el buffer del portapapeles, ahora para poder soltarlo, haremos lo siguiente


xclip -o

Os recuerdo que una manera rápida de pegar en la consola es pulsar la combinación de teclas Ctrl+Shift+v. Pero aun podemos mejorarlo… ¿cómo? Muy fácil, con esto no podemos llevar el texto a xWindows, es decir, no podemos pegarlo en un lugar del entorno gráfico y no de línea de comandos. Para solucionarlo realizaremos la siguiente modificación en la instrucción


ls -a | xclip -sel clip

De esta forma ya tenemos operativo el contenido del portapapeles en cualquier lugar de nuestro sistema. Podéis hacer la prueba y decidme qué tal, pero os aseguro que es una de los tips que más me han facilitado la vida cuando trabajas mucho con el Terminal.

Espero que os haya gustado y podáis sacarle el mismo rendimiento a este “truquillo” como lo hago yo🙂 Me hace la vida mucho más sencilla.

Un saludo a todos y gracias por vuestra atención😉

Categorías:Tips, Ubuntu Etiquetas: , , , , , ,

Cómo comenzar con GITHub [Ubuntu]

15 noviembre, 2010 4 comentarios

Este blog se ha trasladado a http://www.fperezp.com/blog/. Puedes leer acerca de Cómo comenzar con GitHub [Ubuntu] aquí.

GitHubHola de nuevo. Tras unos días sin comentaros nada interesante, me dispongo a resumir en estas líneas como comenzar a usar GitHub. Quiero aprovechar este espacio para dedicarle este post a los fundadores de Cadiz Developers: @oldlastma y @drwaky, así como a Loba Sofware por cedernos amablemente sus instalaciones.

Este manual está pensado para usuarios de Linux, en concreto Ubuntu. De todas formas aunque los comandos no sean los mismos, puede dar una idea de cómo debemos proceder en cualquier otro sistema operativo. Para ello, configuraremos nuestro usuario, generaremos nuestra clave SSH, generaremos un repositorio nuevo, y por último lo sincronizaremos en local y lo actualizaremos.

Si quereis simplemente usar un repositorio que ya existe, podeis avanzar aquí directamente.

 

Registrandose en GitHub

  • En primero lugar, y aunque parezca obvio, nos debemos registrar en GitHub.
  • Una vez registrados, procederemos a obtener nuestro certificado RSA. Este proceso variará según el sistema operativo que estés utilizando. La propia página de GitHub te proporciona la guía de cómo hacerlo, nosotros os explicamos aquí como hacerlo en Ubuntu.

Instalación de GIT en Ubuntu

Instalamos GIT y GITK, un gestor gráfico para ver las ramas y actualizaciones de los colaboradores.

sudo apt-get install git
sudo apt-get install gitk

Obtención de una clave SSH

ssh-keygen -t rsa -C "youremail@youremail.com"
sudo apt-get install xclip
cat ~/.ssh/id_rsa.pub | xclip -sel clip

Una vez tenemos nuestra clave SSH, la agregamos a nuestra cuenta de GitHub. Para ello nos vamos a configuración y en el apartado “Llaves públicas SSH” agregamos la que acabamos de obtener. Ahora ya podemos interactuar entre el repositorio remoto y el local. Comencemos entonces con la generación de un repositorio.

Generación de un repositorio en GitHub

Debes irte a la propia web de GitHub, y en tu Escritorio, verás la opción “Añadir nuevo repositorio”. Allí tienes las instrucciones, pero por si acaso, te las repetimos aquí.

Configuramos nuestros datos.

git config --global user.name "Your Name"
git config --global user.email youremail@youremail.com

Creamos el directorio en local y generamos un fichero README, subimos el fichero al repositorio remoto y ya lo tenemos listo😉

mkdir [NombreRepositorio]
cd [NombreRepositorio]
git init
touch README
git add README
git commit -m '[Comentario]'
git remote add origin git@github.com:[NombreUsuarioGitHub]/[NombreRepositorio].git
git push origin master

¡Ya tenemos nuestro repo subido a GitHub y un archivo en él!

Veamos ahora qué debemos hacer si queremos usar un repositorio que ya existe en GitHub.
Clonación de un Repositorio de GitHub

Trabajar con un repositorio existente

git clone git@github.com/[NombreUsuario]/NombreRepositorio.git

Ya tenemos descargado el código de nuestro repositorio remoto. Una vez hayamos modificado el código y queramos subir nuestros cambios, procederemos de la siguiente manera:

git add [nombre_del_fichero_modificado]
git commit -m "Comentario sobre los cambios"
git push

Por ahora esto es todo, dejaré para otra entrega cómo crear ramas, y el trabajo con ellas. Espero que les sea de utilidad.

Un saludo a todos y gracias por vuestra atención😉

phpConference: Desarrollo de aplicaciones para Facebook en PHP

8 noviembre, 2010 3 comentarios

Después de la charla-publipropaganda del señor Kuassi Mensah, de Oracle, de la cual ni siquiera voy a escribir entrada, a pesar de estar agradecido por la simpatía con la que intentó llevar su disertación adelante; es que no había por donde cogerlo, pero bueno, es lo que toca cuando se trata de una charla del principal patrocinador, nos encaminamos hacia una presentación que se las prometía felices, pero que finalmente acabó decepcionando a muchos, entre ellos a mi.

Para empezar, quiero felicitar a Victor Castell y Xavi, los ponentes, por el esfuerzo en hacer de su ponencia algo dinámico, intuitivo y participativo. Una pena que finalmente no se cumplieran sus objetivos. En primer lugar por la ubicación, la organización no esperaba una afluencia de gente tan masiva, por lo que muchos tuvimos que permanecer de pie o sentados en el suelo para poder asistir.

Por otra parte, los problemas de audio se dejaron notar haciendo en ocasiones casi ininteligible a los bien dispuestos Victor y Xavi. Añadimos a estos problemas de infraestructuras, que la ponencia estaba pensada más como taller que como discurso, siendo bastante dificil de seguir para aquella mayoría que asistió sin portatil.

Bien, pasemos ya a sintentizar los dos puntos más relevantes, a mi entender, de lo comentado aquí:

En primer lugar, una aplicación para Facebook no es más que una aplicación web cualquiera, que no está siquiera alojada en Facebook, sino simplemente es una aplicación que podemos acceder a través de esta red social. Esta independencia implica que debemos tener un hosting donde alojarla que es completamente independiente de Facebook, por lo que deberemos tener especial cuidado con las caidas del sistema y demás problemas derivado.

En segundo lugar, debemos leer atentamente las condiciones que, casi siempre, por no decir siempre, aceptamos sin siquiera echar un vistazo. En muchas ocasiones podemos encontrarnos con alguna sopresita en plan nos han cerrado la aplicación, por no haber tenido en cuenta estas condiciones bastante restrictivas. Por ejemplo, una de las cosas que más me llamó la atención, es que si organizamos algún tipo de concurso con nuestra aplicación, el ganador de éste no puede definirse por el número de “me gusta” que pueda obtener en ella, debiendo diseñaro otro tipo de baremo para decidir quien gana.

Además, estuvimos viendo de forma práctica como configurar una aplicación, como desarrollarla y como ponerla en marcha. Aquí os dejo el enlace al código fuente sobre el cual estuvimos trabajando.

Poco más podemos decir de esta charla, en principio de lo más interesante, pero que debido a diversos motivos nos dejó con un sabor agridulce. Aun así, mi mas sincera enhorabuena a Victor y su compañero Xavi por el gran esfuerzo realizado🙂

Un saludo a todos y gracias por vuestra atención😉

Categorías:phpConference Etiquetas: , ,

Activar htaccess en Apache [Ubuntu]

6 noviembre, 2010 Deja un comentario

Hola a todos, aquí estamos una vez más. En esta ocasión para comentar un problema que acabo de solucionar y que me he dado cabezazos contra las paredes, y mira que es una tontería soberana.

Acabo de instalarme, después de unos cuantos años sin tener que hacerlo, un servidor Apache con PHP en Ubuntu. Por diversos motivos, necesitaba hacer uso de un .htaccess, pero el uso de estos no viene habilitado en la instalación por defecto del servidor. Para poder activar el uso de estos útiles ficheros, debemos proceder de la siguiente manera.

Ejecutamos la siguiente sentencia en consola:

sudo nano /etc/apache2/sites-available/default

Una vez lo tenemos abierto, buscamos el siguiente fragmento de código:


NameVirtualHost *
<VirtualHost *>
 

ServerAdmin admin@site.com

DocumentRoot /var/www/

<Directory />

Options FollowSymLinks
AllowOverride None

</Directory>
<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
# Commented out for Ubuntu
#RedirectMatch ^/$ /apache2-default/

</Directory>

Debemos modificarlo y dejarlo como sigue. Es solo una pequeña modificación, debemos activar el AllowOverride all


NameVirtualHost *
<VirtualHost *>
 

ServerAdmin admin@site.com

DocumentRoot /var/www/
<Directory />

Options FollowSymLinks
AllowOverride None

</Directory>
<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
# Commented out for Ubuntu
#RedirectMatch ^/$ /apache2-default/

</Directory>

Una vez guardado el archivo, reniciamos el servicio Apache ejecutando lo siguiente:

sudo /etc/init.d/apache2 restart

Y listo, ya solo tenemos que añadir las directivas que queramos al fichero .htaccess

Un saludo a todos y gracias por vuestra atención😉

Categorías:Tips Etiquetas: , , , , ,
A %d blogueros les gusta esto: