Coding Dojo #2

Se ve que estuvo bueno el ambiente.....
Veo dificil ir pronto, pero.... trataré de escaparme un día de estos jejeje

Saludos!!!

"Como no tuve una participación muy activa en esta edición" Uhh? Por que no??

@Rugi, yo también, yo también yo tambien.

:) :) :) :) : ):: ))):):))):):):))::))

Entiendo que, al igual que yo, Oscar tiene horarios un tanto cuanto demandantes.

Por esa razón su insistencia en los streams o en que se graben los eventos ;)

Yo sí te endiendo !!! jejeje

Saludos!!
---

Jajajaj .. este si lo grabaron, pero estaría chido en streaming para twitter y cerrar el círculo de la comunicación.

Si se puso genial el coding-dojo, y con súper anfitrión; deodeveloper, lo que más me gusto, fue ver las soluciones de los demás, lo que menos el silencio mortal a la hora de iniciar los ejercicios. Necesitamos una “gabacha” :P.

@Orcar ammm porque no me salieron ayer los ejercicios :(, pero ya aprendí y como no podía estar sin haber saboreado ese delicioso sabor que te queda después de haber resuelto un problema, pus que me levanto, me cambio, me subo al metrobus y me pongo a leer sobre números romanos, y voila que lo resuelvo : )

Todo muy divertido.

Ahh vaya... mmhh que mal, eso sucede a veces cuando muuuchas veces. Yo creí que te habían sentado en una esquinita por ahí.

Lo importante es salir del hoyo sr, y veo que no solo salió, sino que terminó llegando a una solución muy elegante... enhorabuena!!

Desde que está metido en lo del proj. euler como que usa más   y   en su código que de costumbre, no? :-P

Una duda: usaste TDD en el ejercicio de números romanos o las pruebas fueron "after the fact"?

Saludos

@Alfred Pues no use TDD pero tampoco hice las pruebas hasta el final. Me ayudo mucho de las pruebas mientras voy desarrollando pero no tengo la disciplina de moverle muy poquito al código, tiendo a saltarme muchos pasos.
Y gracias por los comentarios : )

Tampoco está peleado ( bueno en realidad sí ) sáltate los pasos pero crea el test primero.

Es decir, en vez de que sea TDD, sería Test Supported Development o algo así.

Test Inspired Development

Test Encouraged Development

Cuando hablamos de TDD, siempre escuchamos el término "diciplina" asociado con el mismo. Sin embargo, no debemos olvidar que la última "D" se refiere a "desarrollo", por lo que al igual que este, entre más lo practiquemos, mejor nos volveremos con el mismo.

Sé que especialmente en el trabajo es difícil hacerlo, pero como un reto personal, trata de desarrollar todo el código que escribas (en tus propios proyectos) durante una semana, usando TDD estricto y después decide si vale o no vale la pena desarrollar esa habilidad.

Aquí mis soluciones, no me había dado chance de subirlas:

Tampoco utilicé TDD como tal, la premura y el tiempo limitado fueron factor, para la próxima prometo hacerlo.

Pues Le di un pequeño refactor al de los números romanos como lo mencione el dia del Dojo lo reduje a que la obtencion del numero romano fuera en un solo metodo y no en los 4 que tenia. EL otro es el de los números primos

Vaya que bien te quedo el código. Mire el video podcast de viviecodigo y me encanto.

Muchas gracias por el comentario. Sip estubo genial el Dojo :)

Me hizo un poco de ruido el comentario de que la razón por la cual estaba tan lento era por la conversión que hace Groovy de todos los objetos y aunque es en parte cierta no creí que fuera la razón principal.

Veo entonces que el cambio de la v1 a la v2 es:

Intenté implementar el mismo algoritmo en Java ( en una Dell del 2005 ) y la primera versión se ejecutó en 80 segundos y la segunda en 500 milisegundos!!

Luego entonces, confirmo que no es en realidad el lenguaje sino el algoritmo lo que causo la demora.

Lo más interesante es que hay aún una optimización más a ese algoritmo porque ( a mi entender y puedo estar equivocado ) lo que hace el siguiente código:

Es iterar todo el rango y ejecutar el closure por cada elemento y luego negar el resultado. El problema con esto es que si se encuentra el resultado de inmediato de todas formas se va a iterar todo el rango ( si el son 10k números y el elemento 10 resultó divisible, aún se van a ejecutar los restantes 9,990 )

Se podría cambiar eso por algo como:

y cortar el ciclo tan pronto encontremos que el número no es primo.

Al hacerlo en mi implementación Java, pasé de 80 secs . en la primera versión a 9 secs. y de 500 ms en la segunda versión a 64 ms.!!!

¿Que aprendo con esto?

Entonces no es culpa de los lenguajes de programación solitos... así nomás porque sí ( y me siento un poquito raro defendiendo a Groovy, pero en fin :P ) , tiene mucho que ver ( o siempre tiene que ver ) el algoritmo que se implementa.

También se aprende que aunque es fácil suponer cosas y de hecho es muy necesario para poder atacar el problema, es mucho mejor si se confirma la teoría con un poco de código. Al no hacerlo se queda la idea de: "Groovy es espantosamente lentooo.... , de hacerlo en ____ sería mucho más rápido"

Finalmente que mi propia implementación inicial es ridiculamente mala pues corre en 2 segundos vs. los 64 millisegundos de la segunda versión de Rodrigo.

Y ya.

Ahi les dejo el código por si ocupan.

:D

En Groovy,   recibe un closure que ejecuta con cada elemento de la colección, hasta que devuelva true y en ese momento se detiene. Si con el primer elemento devuelve true, ya nada más se ejecutó una vez. Si ningún elemento devolvió true, find devuelve null. Similar a   en Scala.

  ejecuta el closure con cada elemento de la colección, sin importar lo que pase. No toma en cuenta el resultado del closure, no hace nada con él. Es como   en Scala.

  es como find pero ejecuta el closure con todos los elementos de la colección y devuelve una nueva colección que contiene todos los elementos que hayan dado true (o una colección vacía si ninguno dio true). Es como   en Scala.

  ejecuta un closure con todos los elementos de la colección y devuelve una nueva colección con el resultado de cada ejecución del closure. Es como   en Scala.

No sé cómo están implementados los rangos en Groovy pero parece que son bastante ineficientes, sospecho que internamente generan una colección con los elementos contenidos, o sea si defines 1..1000 el rango internamente tendrá una lista de mil enteros. En Scala y en Ceylon únicamente tienen los límites inferior y superior, y su iterador solamente devuelve el elemento siguiente hasta llegar al límite superior; no se generan listas de elementos de manera innecesaria.