Arte generativo

He de reconocer que hasta hace muy poco lo único que tenía en la cabeza era montar proyectos, posibles startupso apps que podrían revolucionar la vida de millones de ciudanos. La verdad que al final he terminado pocos de estos proyectos de fin de semana, el día a día en mi trabajo ya me permite trabajar en este tipo de ideas y hacer lo mismo en mi tiempo libre tampoco me aportaba mucho.

De un tiempo a esta parte cuando tengo un rato libre me dedico a jugetear con el lenguaje Processing, tanto en tu versión normal como en su versión en JavaScript. Processing es un lenguaje muy utilizado para la creación de proyectos multimedia o de diseño digital. De momento estoy conociendo su potencia y adminrando alguno de los proyectos tan interensantes que se pueden realizar con él.

Moda: el último gran negocio del mundo editorial

Tras el parón por la huelga, volvemos el próximo 26 de abril al centro de innovación BBVA con una nueva edición de Hacks Hackers Madrid. En esta ocasión el título que hemos puesto es “Moda: el último gran negocio del mundo editorial”. Como invitados tendremos a dos startups: ModaEs y Chicisimo, y la bloggera/presentadora Laura Hayden.

Si quieres tener información más detallada visita la página de MeetUp de Hacks Hackers Madrid. Recuerda que para acceder a la charla es necesario que nos envies tu DNI.

Tagged , ,

Hacks & Hackers IV: Fórmulas para monetizar nuevos proyectos periodísticos

Ya hay cartel para la proxima edición de hacks & hackers Madrid. Será el día 30 y los invitados serán: Yorokobu, Smark Magazine y Vis-á-Vis. Si quieres entrar en más detalle puedes ver la info de hacks & hackers IV en nuestro weblog.

Tagged , , , ,

Hacks & Hackers Madrid

Todavía no he tenido tiempo de contarlo, pero me he metido a ayudar en la organización de hacks & hackers en Madrid. Este próximo miércoles celebramos la III edición, os animo a que vayais! En cuanto saque algo de tiempo os cuento en detalle.

Tagged , , ,

Aprendiendo Ruby 3: Contenedores, Bloques e Iteradores

Los arrays son un tipo de datos conocido en todos los lenguajes, en Ruby sobre todo me ha interesado como se puede acceder a los elementos de un array mediante rangos o indices negativos.

a = [1,3,5,7,9,11]
a[-2] = 'paco'
p a        # [1, 3, 5, 7, "paco", 11]
p a[1..4]  # [3, 5, 7, "paco"]
p a[1...4] # [3, 5, 7]

Los code blocks y los iterators son sin duda una de las partes más potentes que estoy descubriendo por parte de Ruby. Resumiendo bastante un code block es un método sin nombre. Al igual que los métodos normales puede recibir parámetros, van entre || al principio del code block. A continuación se muestra un trozo de código que se realizaría sin tener conocimiento de esta funcionalidad por parte de Ruby. Como se puede ver es un simple for que permite acceder hash donde se guarda una palabra y el número de veces que aparecen en un texto.

for i in 0...5
  word = top_five[i][0]
  count = top_five[i][1]
  puts "#{word}:
end

Gracias a los code blocks y los iterators es posible aumentar su legibilidad de la siguiente manera.

# forma 1
top_five.each do |word, count|
  puts "#{word}: #{count}"
end

# forma 2
puts top_five.map { |word, count| "#{word}: #{count}" }

Si se desea se pueden pasar/recibir parámetros al code block gracias a la palabra reservada yield.

def fibbonaci_hasta(max)
  i1, i2 = 1, 1
  while i1 <= max
    yield i1
    i1, i2 = i2, i1+i2
  end
end
fibbonaci_hasta(1000) {|f| print f, " " }

# 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987

En Ruby hay muchísimos iteradores: each, inject, collect, each_with_index, etc. Más adelante podré entrar en detalle con cada uno de ellos.

Otra de las características que incluye Ruby son los enumerators. Gracias a ellos es posible tratar el iterator como su fuera un objeto al 100%, pudiéndose pasar como parámetro dentro de una función. Además, gracias al método loop y los enumerators es posible recorrer a la vez varios objetos y terminar su ejecución cuando alguna de las condiciones llega a su fin.

short_enum = [1, 2, 3].to_enum
long_enum = ('a'..'z').to_enum
loop do
  put "#{short_enum.next} (#{long_enum.next})"
end
# 1 (a) 2 (b) 3 (c)

Tagged , , , ,

Aprendiendo Ruby 2: Clases, objetos y variables

Ruby es un lenguaje totalmente orientado a objetos. Una de las diferencias que tienen con otros lenguajes de programación es los tipos de acceso que presentan los métodos y atributos de una clase. Los tres tipos de accesos son:

- Métodos públicos, pueden ser invocados por cualquiera. Es el modo por defecto.
- Métodos private, pueden ser invocados solo por la misma instancia del objeto.
- Métodos protected, solo pueden ser invocados por objetos de la misma clase y por objetos que hereden de la clase.

class MiClass
 def initialize (number)
  @number = number
 end
 def todas
  mi_publica
  mi_protegida
  mi_privada
 end
 def mi_publica
  puts 'publica'
 end
 protected
 def mi_protegida
  puts 'protegida'
 end
 private
 def mi_privada
  puts 'privada'
 end
end

class MiClassHija < MiClass
  def a_mi_padre
    self.mi_publica
    self.mi_protegida
    self.mi_privada
  end
end

m = MiClass.new(1)
m.mi_publica #OK
m.mi_privada #Da error
m.mi_protegida #Da error
m.todas #OK

m_hija = MiClassHija.new(2)
m_hija.a_mi_padre #Da error con self.mi_privada.

Otro punto que me ha llamado la atención es el acceso a variables. En las variables lo que se guarda siempre la dirección de acceso al objeto. Esto produce cosas como esta:

nombre1 = "Cama"
nombre2 = nombre1
nombre1[0] = 'L'
puts "nombre1 is #{nombre1}" # Esto imprime 'nombre1 es Lama'
puts "nombre2 is #{nombre2}" # Esto imprime 'nombre2 es Lama'

Es posible evitar este comportamiento, congelando los objetos mediante el método freeze.

nombre1 = "Cama"
nombre2 = nombre1
nombre1.freeze
nombre2[0] = 'L' # Genera una excepcion

Tagged , ,

Aprendiendo Ruby 1: Introducción

Ayer de nuevo volvió a aparecer la convesación de si no sabes Ruby no estás en la pomada. Cansado que estoy de escuchar siempre la misma historia voy a intentar aprender Ruby y posteriormente Ruby on Rails en el menor tiempo posible. Me estoy empollando Programming Ruby de The Pragmatic Bookshelf. Para que me sirva un poco de recordatorio intentaré apuntar por aquí lo que más me llame la atención.

Como siempre los primeros pasos en cualquier lenguaje pasan por conocer algunos tipos primitivos y las estructuras de control, nada nuevo. Lo que si que me ha llamado la atención han sido dos conceptos el de los symbols y el de los code blocks.

En PHP y en otros lenguajes de programación, si queremos que una variable tenga siempre el mismo valor a lo largo de nuestra aplicación la definimos como una constante. Posteriormente la podemos utilizar en cualquier parte de nuestro código

ADMIN = 0;
MANAGER = 1;
WORKER = 2; 

if (rol == ADMIN) echo "Soy el admin!";

Con los symbols no es necesario inicializar nada, Ruby se encarga de mantener constante el valor por nosotros, haciendo que todo sea más legible.

def permisos(rol)
  if rol == :admin
    # ...
  end
end

Por otro lado un code block es un trozo de código que se puede asociar con métodos como si fueran parámetros.

def que_dice_quien
  yield("Ruben", "hola")
  yield("Romina", "adios")
end
que_dice_quien {|quien, que| puts "#{quien} dice #{que}"}

...Salida...
Ruben dice hola
Romina dice adios

Los code blocks son muy útiles también cuando se hace uso de iterators o utilizándolos en cualquiera de las estructuras de loop.

nombres = %w( ruben romina jose luis )
nombres.each {|nombre| puts nombre }

...Salida...
ruben
romina
jose
luis

Tagged ,

Coding Dojo @ Decide

Coding Dojo

Durante toda esta semana @carlosble va a estar en @antevenio dandonos un curso de introducción a TDD y a prácticas XP. Aprovechando que estaba por Madrid y en colaboración con la gente de Decide ha montado un coding dojo denominado el reto XP. La misión principal del dojo era comprobar si realmente teníamos interiorizado algunas de las  buenas prácticas de XP (Simplicidad, Entregas Continuas, etc…). Para ponernos ha prueba nos han divido en grupos de dos personas y nos han proporcionado un problema de combinatoria que debíamos resolver haciendo uso de TDD durante un periodo de tiempo reducido.

Cuando mi pareja y yo nos hemos puesto a programar todo iba como la seda. Hemos hecho TDD como unos auténticos campeones, primero el rojo del test erroneo, luego el verde del test correcto, adelante con la refactorización, pasos pequeños para ir poco a poco cubriendo toda la aceptación del problema. Desgraciadamente cuando el tiempo establecido ha llegado a su fin la realidad nos ha golpeado de manera contundente ¿Que hemos hecho mal?

Uno de los requisitos fundamentales era entregar un producto que funcionara. ¿A que nos hemos dedicado nosotros? A hacer nuestros test y dejarlo todo en verde. Pero la realidad es que solo hemos llegado a tener una clase, ni más ni menos. No había nada que pudieramos enseñar que realmente funcionara.

Para colmo nos han pedido que borraramos todo nuestro código de producción y otra pareja han tenido que analizar a partir de nuestros test cual era la responsabilidad de nuestra clases y ejem, mejor no cuento que es lo que han dicho porque era cualquier cosa menos la definición de nuestro algoritmo.

Tras el primer jarro de agua fría nos hemos puesto las pilas y  hemos conseguido teminar el segundo reto (en parte gracias a las funciones de PHP shuffle y slice) con tiempo de sobra, el producto entregrado y con bastantes test funcionando. Eso sí, sin ninguno de los errores que habíamos cometido en la primera parte del reto.

Como cierre al  Dojo hemos tenido una retrospectiva que ha servido para discutir que nos ha parecido todo. Gracias a eso me llevo la recomendación de la lectura del libro Agile Retrospectives: Making Good Teams Great, que ya está en mi kindle esperandome para que lo lea.

Para finalizar nos hemos ido a tomar unas cañas (como dice un buen amigo si no hay cañas después no es deporte) y hemos hablado de lo divino y lo humano, ¿es PHP un lenguaje de programación? ¿Quien conoce más framework de pruebas para JS? ¿Como puedo currarme un exploit de un buffer overflow? Vamos lo típico en estos eventos.

Espero tener ocasión de volver a disfrutar de una tarde tan entretenida como esta y no se me puede olvidar dar gracias a Decide y @rliana, por dejarnos pasar la tarde en su oficina frikeando y a @eamodeorubio y @carlosble por facilitar este Dojo.

Tagged , , ,

Consejos para Ninja Coders: No toques ahí!

No hay ni un solo programador que no se haya visto en una situación como esta. Se acaba de realizar un despliegue a producción y aparece un error que hasta ese momento no había sido detectado. Rapidamente pides acceso a producción porque sabes perfectamente cual es el problema y quieres solucionarlo.

Esta claro que hay un problema, pero no es otro que un programador que piensa que debe tener acceso a los servidores de producción para poder solucionar un problema online.

Para un buen proyecto como mínimo debe haber cuatro entornos.

  • El entorno de desarrollo y pruebas local de cada programador.
  • Un entorno donde se realizan pruebas de integracion tanto manuales como integradas.
  • Un entorno de preproducción donde el equipo de QA y los usuarios realizan las pruebas de aceptación
  • Un entorno de producción.

Aunque sea el crack más grande del planeta un programador jamas debe tener acceso más alla de su entorno de desarrollo. Cuando el código es subido al sistema de control de versiones y desplegado, el programador debe ser un mero espectador. Lo mismo sucede con el equipo QA o los usuarios. El entorno en el cual deben trabajar es el de preproducción y no tienen porque tener ni porque “mirar” en el entorno de pruebas o de desarrollo. Si hay una versión nueva disponible, el responsable de versiones deberá moverlas al siguiente entorno para que el ciclo de vida del proyecto siga avanzando.

Si hay un error en producción, debe ser solucionado por el equipo de operaciones. Si no pueden arreglarlo, el desarrollador deberá correguir el bug en su entorno, subirlo a gestor de versiones y desde alli esperar la validación del equipo de QA. Cuando este todo correcto se podrá realizará un parche que se subirá a producción.

No seas responsable de una catastrofe en tus servicios por tocar en producción directamente.

Adaptado de un consejo de Cal Evans.

Tagged , , , , ,

12meses12katas: StringCalculator

Una kata (型) es una palabra de origen japones que se traduce como forma. El concepto es utilizado en todo tipo de artes tradicionales incluyendo el teatro kabuki, la ceremonia del té (chadó) y por supuesto las artes marciales.

Dentro del mundo de la programación también se utiliza el concepto de Code Kata. Con el se hace referencia a un ejercicio de programación en el cual se resuelve un problema mas o menos complejo donde el único objetivo es mejorar la técnica mediante el ejercicio y la repetición.

Dentro de la comunidad ágil, ha aparecido la iniciativa 12meses12katas, donde cada mes se propone una nueva kata. Abierta a todo el mundo y a todos los lenguajes, parece una plataforma excelente para poder practicar y aprender. Sin duda alguna mi “kung fu” no está para tirar cohetes, pero voy a intentar sacar tiempo para poder realizar lo ejercicios y poder comentar lo que he aprendido.

Para Enero el ejercicio era el String Calculator, si queréis ver el código de todo el mundo podéis visitar el github del proyecto. Mi código está almacenado dentro de la carpeta agileando.

Alguna de las cosas que he aprendido, sobre todo viendo el código del resto de la gente, han tenido que ver en como definir las pruebas unitarias. En mi primera versión del código cada una de las pruebas las tenias definidas en una función independiente.


   public function testSumaUnSoloNumero() {

        $this->assertEquals($this->sc->add('1'), 1);
        $this->assertEquals($this->sc->add('332'), 332);
    }

Conocía la posibilidad de utilizar la anotación @dataProvider, pero la forma en la cual se proporciona añadiendo una etiqueta a los datos, hace que mejore mucho la legibilidad y limpieza de la clase de test.


    public function dataProvider() {
        return array(
            "sumaVaciaDevuelveCero" => array(0, ""),
            "sumaUnSoloNumero1" => array(1, "1"),
            "sumaUnSoloNumero2" => array(332, "332"),
            "sumaDosNumeros1" => array(2, "1,1"),
            "sumaDosNumeros2" => array(22, "10,12"),
            "sumaVariosNumeros1" => array(6, "1,2,3"),
            "sumaVariosNumeros2" => array(60, "10,20,30"),
            "sumaVariosNumerosMasDeMil" => array(460, "10,20,30,400,1000"),
            "sumaConRetornosYComas1" => array(6, "1\n2,3"),
            "sumaConRetornosYComas2" => array(3, "1\n2"),
            "sumaConfigurandoDelimitador1" => array(3, "//;\n1;2"),
            "sumaConfigurandoDelimitador2" => array(7, "//;\n1;2;3\n1"),
            "sumaConfigurandoDelimitadoLargo1" => array(6, "//[***]\n1***2***3"),
            "sumaConfigurandoDelimitadoLargo2" => array(6, "//[+*+]\n1+*+2+*+3"),
            "sumaConfigurandoDelimitadorMultiple" => array(3, "//;\n1;2"),
        );
    }

Además con el tema de la prueba unitaria de excepciones siempre me pasaba igual. Siempre me complicaba muchísimo con estas pruebas, metiendo try y catch para validar que el resultado era correcto.


    public function testExpcepcionNegativa()
        try {
            $this->sc->add('1,-2,3');
        } catch (Exception $exception) {
           $this->assertTrue(true);
       }
    }
}

De nuevo haciendo uso de una anotación @expectedException se mejora muchísimo la legibilidad de las pruebas.


    /**
     *  @expectedException InvalidArgumentException
     */
    public function testExpcepcionNegativa() {
        $this->sc->add('1,-2,3');
    }

De momento me doy por satisfecho con la solución que he propuesto, he aprendido bastante de otros desarrolladores. Sobre todo me gusta la solución que hay en PHP usando inyección de dependencia y que incluso lleva un autoloader (MarioTux). En cuanto pasen unos días voy a intentar realizar la kata de nuevo a ver si la hago en menos tiempo y mejor.

Tagged , , , , , ,