http://porras.lacoctelera.net 2009-11-02T18:03:50Z Sergio Gil http://porras.lacoctelera.net/post/2009/11/02/git-bisect#c4619250 2009-11-02T18:03:50Z cientifico

Mola. Siempre se me olvida la sintaxis y/o la forma de uso.

<p> Mola. Siempre se me olvida la sintaxis y/o la forma de uso. </p> http://porras.lacoctelera.net/post/2009/08/14/they-don-t-understand#c4394829 2009-08-14T21:39:53Z Xavi Noria

Una vara del calibre IE6 le hace falta al listo este.

<p>Una vara del calibre IE6 le hace falta al listo este. </p> http://porras.lacoctelera.net/post/2009/08/14/they-don-t-understand#c4394619 2009-08-14T20:03:01Z loki

Yo hago desarrollo web por las mujeres y porque me lo dijo Dios. "De listos está lleno el infierno", me dijo. Luego bailamos.

<p> Yo hago desarrollo web por las mujeres y porque me lo dijo Dios. "De listos está lleno el infierno", me dijo. Luego bailamos. </p> http://porras.lacoctelera.net/post/2009/08/14/they-don-t-understand#c4394349 2009-08-14T18:11:21Z mort

Si sirve de algo, por lo que he entendido su rant se dirige exclusivamente contra Javascript. Cuando le mencionan Ruby o Java...

<p>Si sirve de algo, por lo que he entendido su rant se dirige exclusivamente contra Javascript. Cuando le mencionan Ruby o Java, dice en los comentarios que para él eso no es "web programming", que eso es "server side programming" y que es otra cosa (?)</p> <p>Es un tipo confundido, en general.</p> http://porras.lacoctelera.net/post/2009/08/14/they-don-t-understand#c4394339 2009-08-14T18:05:42Z porras

Sí sí, si a mí me ha encantado el rant, por eso lo que copiado. Lo que pasa es que me ha gustado de patético y mal argum...

<p> Sí sí, si a mí me ha encantado el rant, por eso lo que copiado. Lo que pasa es que me ha gustado de patético y mal argumentado que está pero eso es harina de otro costal :D</p> <p>Lo que más me ha gustado es que un tipo que por su manera de escribir parece un poco corto me diga que no soy muy listo porque no conozco el lenguaje Wadus ni la metodología Wadus Wadus.</p> <p>Para otro día puede explicar cómo es que creamos aplicaciones que aportan igual valor que las suyas (no pondré más valor que estaría feo) siendo tontos y con herramientas deficientes. </p> http://porras.lacoctelera.net/post/2009/08/14/they-don-t-understand#c4394320 2009-08-14T17:55:30Z therobot

El jueves conocí a un chaval que era programador. Su trabajo consistía en optimizar algoritmos en java para dispositivos mÃ...

<p>El jueves conocí a un chaval que era programador. Su trabajo consistía en optimizar algoritmos en java para dispositivos móviles, y me decía que le encantaba, el chaval tenía pinta de ser muy listo, y seguramente un trabajo que para muchos nos puede parecer dificil, oscuro y no demasiado divertido para el suponía un reto cada día, así me lo describió.</p> <p>Puedo entender que para algunas personas hacer desarollos en un lenguaje de muy alto nivel con facilidades, mas orientado a tareas o servicios que a cosas mas abstractas y complejas pueda resultarle sencillo y aburrido. Otra cosa es el rant, pero a quien no le gustan los rants?</p> http://porras.lacoctelera.net/post/2007/10/12/plugin-livevalidation-rails#c4356133 2009-07-24T21:58:36Z Rafael

Parece un plugin muy interesante, solamente que no tuve la oportunidad de probarlo ya que yo uso jQuery y no Prototype. Baj...

<p> Parece un plugin muy interesante, solamente que no tuve la oportunidad de probarlo ya que yo uso jQuery y no Prototype.<br /> Bajé la versión standalone de livevalidation y reemplazé el que crea el rake install y no funciona, no pasa absolutamente nada, tan diferente es la versión Prototype de la version standalone (me refiero a livevalidation)</p> <p>Me hubiese sido muy útil </p> http://porras.lacoctelera.net/post/2007/10/08/enviando-formularios-con-parametros-compuestos-con-ruby-y-net#c4300080 2009-06-29T23:05:49Z Franco

Gracias por el post, me has ahorrado una laptop porque te juro que la estaba por tirar contra la pared jeje. te dejo aqu...

<p> Gracias por el post, me has ahorrado una laptop porque te juro que la estaba por tirar contra la pared jeje. </p> <p>te dejo aquí mi solución final con autenticación</p> <p> parameters = { :page => {"page_text"=>"test", "page_title"=>"test", "browser_title"=>"test"} }</p> <p> url = URI.parse('<A HREF="http://localhost:3000/admin/pages/create" REL="nofollow">http://localhost:3000/admin/pages/create</A>')</p> <p> req = Net::<A HREF="HTTP::Post.new" REL="nofollow">HTTP::Post.new</A>(url.path)<br /> req.basic_auth @username, @password</p> <p> res = Net::HTTP.new(url.host, url.port).start {|http| http.request(req, parameters.to_http_params) }</p> <p>Saludos.</p> http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas#c4134390 2009-05-11T15:17:29Z Raimond Garcia

Muy interesantes porras siento que fuera un pequeño infierno usar cucumber en el MOR2 :( Como sabes cada día estoy mas m...

<p>Muy interesantes porras siento que fuera un pequeño infierno usar cucumber en el MOR2 :(</p> <p>Como sabes cada día estoy mas metido en el tema de cucumber/tests y lo voy a intentar seguir defendiendo...</p> <p>Las ventajas a medio y largo plazo creo que están bastante aceptadas entre todos, la discusión es a corto plazo.</p> <p>En mi opinión, aunque sea un proyecto pequeño y sin estar bien definido, excepto en casos como un programa por puro disfrute, por jugar con una herramienta nuevo u otros casos excepcionales, hacer tests es esencial, si son antes de la implementación mejor, si son después pues muy bien también, pero como recalca Lusimi, lo importante es *como* hacemos esos tests. Si la implementación va a estar cambiando cada día, no conviene usar muchos mocks, si son los requerimientos que van cambiando cada día<br /> pues inevitablemente aunque se hayan hechos los tests desde un enfoque clasicista habrá que cambiarlos.</p> <p>Esto es un drawback porque tienes que cambiar los tests, pero creo que compensa no tener que probar la funcionalidad manualmente de todo lo demás que has desarrollado en el proyecto. Creo que aquí viene la definición de un proyecto no solo productivo sino de calidad.</p> <p>Si definimos la calidad como la visión que tiene nuestro cliente de nosotros y la calidad de nuestra vida como desarrolladores, el hecho de no tener que manualmente confirmar que nuestra aplicación sigue funcionando al introducir un cambio, ni que el cliente nos mande un email diciendo que ha dejado de funcionar una parte de la aplicación, incrementa la calidad percibida por el cliente y la que nosotros entendemos de nuestro propio trabajo.</p> <p>También, me doy cuenta, de que una simple conversación con el cliente deja muchos cosas sin definir, ahora bien, cuando empiezas a escribir los tests es cuando te das cuenta de todas esta preguntas que tendrías que haber hecho o que el cliente te *tendría* que haber comentado, pero ni uno ni otro pensamos en ello o bien porque asumimos que entendíamos los requerimientos o bien porque el cliente asumía que entendíamos el modelo de negocio con la misma profundidad que el.</p> <p>Dicho esto, también es cierto que en un proyecto de un día o dos en un proyecto personal, no comercial y por puro disfrute de programar, no compensa pasarse la mitad del tiempo escribiendo tests. Pero este problema en vez de achacarlo a escribir tests o no, creo que lo que hace es abrir la puerta y la imaginación, a como escribimos los tests y las herramientas que utilizamos para escribirlos.</p> <p>En el caso hipotético (espero real dentro de poco) de que los tests estén ya escritos y definidos en el lenguaje de programación escogido, ruby, java, php, .NET, y que lo único que haya que hacer sea escribir la implementación que los hagan pasar, no hay razón para no utilizar tests, ya que es igual de rápido usarlos que no usarlos. </p> <p>Un ejemplo son los tests relacionados con los emails. Si ya tienes todos los steps definidos de como testear las funcionalidad de emails, es tan fácil como escribir en texto plano usando un autocomplete de steps, las 20-30 lineas que lo testen. </p> <p>Si el desarrollo en estas colecciones de steps no están bien definidas en casos como selenium, es un problema de todos, es necesario crear las gemas, plugins o simples repositorios donde estarían estos steps definidos para su uso de inmediato por cualquier desarrollador (póngase el ejemplo, muy dicil de testear hoy, como es el autocomplete en un formulario de una manera exhaustiva). Siempre habrán tests que no se puedan reusar pero también habrá mucho sitio para tests que si se puedan reusar en múltiples aplicaciones.</p> <p>Ahora bien, siempre hay que pensar en el aspecto pragmático, y en un proyecto muy corto y no comercial igual no compensa pasarse 8 horas escribiendo una seria de steps reusables en cualquier otro proyecto. Si después lo va a usar la gente, pues apreciarían un test suite para extenderlo con tranquilidad, si no lo va a usar nadie, ni el propio creador, pues mira me parece bien no escribir ni un solo test y dedicarme a otras cosas.</p> <p>Todo depende del contexto, por supuesto, pero el uso de tests hoy en la mayoría de proyectos tiene ventajas imposibles de cuantificar en tiempo pero sin duda muy grandes para el mañana.</p> <p>Viva Cucumber y Vivan los TESTS. </p> http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas#c4108961 2009-04-30T10:30:23Z cientifico

Si MOR2 te ha hecho llegar a estas conclusiones... MOR2 se puede tachar de éxito rotundo.

<p> Si MOR2 te ha hecho llegar a estas conclusiones... MOR2 se puede tachar de éxito rotundo. </p> http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas#c4108915 2009-04-30T09:52:44Z Francisco Javier Guzmán Rivas

Muy buen post!! Seguro que podemos mostrar a ciertos "managerianos" las indudables ventajas del buen testing.

<p> Muy buen post!! Seguro que podemos mostrar a ciertos "managerianos" las indudables ventajas del buen testing. </p> http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas#c4108898 2009-04-30T09:40:34Z Luismi Cavallé

Excelente post, sí señor. Me gustaría comentar acerca del corto plazo. A menudo hablamos acerca del testing y de los benef...

<p>Excelente post, sí señor. Me gustaría comentar acerca del corto plazo. A menudo hablamos acerca del testing y de los beneficios que aporta en el medio y largo plazo a costa del corto plazo. No estoy completamente de acuerdo con que inevitablemente solo haya un perjuicio en el corto plazo.</p> <p>Corey Haines, uno de los tipos detrás del movimiento del Software Craftmanship, mantiene que el conjunto de prácticas y técnicas de uno es aquel que emplea cuando el tiempo aprieta y el proyecto necesita resultados rápidos. En este situación a menudo renunciamos a determinados "lujos" como el testing o el refactoring. Según Corey si esto es así, entonces es que el testing no es una de tus prácticas, pues no te sirve cuando más falta te hace.</p> <p>Testear es solo una herramienta. También lo es emacs y quien realmente ha invertido tiempo y esfuerzo en aprender a usarlo eficientemente, no renunciará a emacs en favor del bloc de notas de windows cuando tenga prisa. Al contrario.</p> <p>Entre los beneficios en cuanto a productividad que puede aportar el testing a corto plazo se me ocurren varios: proporcionan un criterio del "hecho" (saber cuando has acabado), tienden a evitar la sobreingeniería y perder tiempo resolviendo problemas que no tienes hoy, minimizan el tiempo antes de ponerte a escribir código al sustituir a la fase de diseño, etc. Todo ello, desde luego, utilizando las técnicas de testing adecuadas al tipo de proyecto y haciéndolo de manera efectiva. Uno no es eficiente con emacs el primer día que lo utiliza. Al contrario, es menos eficiente que con cualquier otra cosa.</p> <p>En definitiva, pienso que la discusión correcta no es la de cuánto testing necesito (o si testeo o no) en determinado proyecto, sino la de **cómo** testeo, teniendo en cuenta tanto las características del proyecto y como las habilidades del equipo, para maximizar la productividad a medio, largo, pero también, a corto plazo. </p> http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas#c4108850 2009-04-30T08:58:44Z Raúl Murciano

Cuanto más conozco de la comunidad Perl más me arrepiento de haberla ignorado durante todo este tiempo :P Coincido tambi...

<p>Cuanto más conozco de la comunidad Perl más me arrepiento de haberla ignorado durante todo este tiempo :P</p> <p>Coincido también con la segunda parte del comentario de Xavi: muchas veces el cliente prefiere empezar el desarrollo sin tener claras las funcionalidades y en ese caso realmente estás prototipando y testear en esa fase me parece tiempo perdido (en la confe rails comenté que con domestika.org llegué justo a esta misma conclusión). </p> <p>Sobre el TDD: lo aplico cuando tengo clara una funcionalidad y como herramienta de diseño, cuando no tengo claro cómo definir algo en mi código. Cuando no es así suelo aplicar tests a posteriori para confirmar que el código trabaja bien en casos límite o para detectar que un bug no se vuelve a producir.</p> <p>En el BDD no me meto: aún no le he hincado el diente porque no consigo integrarlo en mi forma de trabajar. Supongo que será fácil de aplicar en proyectos propios porque tú tienes la libertad de modificar el comportamiento mientras estás escribiendo los tests, pero cuando el comportamiento lo define el cliente no le termino de ver las ventajas sobre el testeo tradicional.</p> http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas#c4108817 2009-04-30T07:57:25Z estrelase

Cada día estás peor.

<p> Cada día estás peor. </p> http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas#c4108744 2009-04-30T06:01:16Z Mari Carmen Gutierrez de la Ossa

Siempre aprendo cuando leo tu blog, no sólo por tus posts sino por el feedback que despiertas :-). Celebro que hayas vuelto...

<p> Siempre aprendo cuando leo tu blog, no sólo por tus posts sino por el feedback que despiertas :-). Celebro que hayas vuelto a derramar tus conclusiones por aquí, hasta tal punto que a estas horas de la mañana me haya leído de cabo a rabo y atentamente toda tu exposición te debería dar qué pensar. Eres grande Porras!! :-D </p>