Una cosa que se suele hacer bastante en javascript es resetear un formulario, es decir, devolver el formulario a su valor inicial.
Con jquery esto es bastante fácil:
$(
Una cosa que se suele hacer bastante en javascript es resetear un formulario, es decir, devolver el formulario a su valor inicial.
Con jquery esto es bastante fácil:
$(
English
06/05/2009 at 12:37 am Permalink
Criticas y comentarios? Bueno, me parece interesante el tema este, pero no se.. me gustaria «ver resultados». Cuando lo implementes, podrias comentar los resultados, a favor o en contra de este tipo de tecnicas tan agresivas.
Yo soy mas tradicional en ese sentido. Me parece guay tener un buen sistema de build y que todo sea automatico, pero hijo, a la hora de llevar cualquier cosa a produccion o sacar un release de algo ¡¡piensatelo 2 veces!! De echo, mejor que se lo piense otro: el departamento de QA (si existe).
Obviamente si no tienes QA (ni prevision de tenerlo) y tu mismo tampoco vas a hacer aunque sea un minimo QA, lo mejor es tener mogollon de tests (mejor unit tests que nada) y ahi ya hacer el deployment continuo o no da igual.
06/05/2009 at 8:11 am Permalink
Por eso al final concluia diciendo algo como que lo que realmente tiene sentido y valor, es poder saber para un determinado build se sepa si puede ser instalado en producción sin problemas o no, así como disponer de un botón que te haga deployments automáticos.
En cualquier caso, yo pienso igual que tú, en el sentido de que antes de que saques un build tienes que estar seguro de que tiene el mínimo numero de bugs posibles, porque lo último que uno quiere es molestar a los usuarios.
La pregunta que yo te hago es: Si dispusieras de un sistema automático de test equivalente a los tests que te pueda realizar una persona…. y tu programa/web/whatever pasara esos tests ¿harias deployment continuos, digamos, 1 por dia?
Comento esto, porque indica donde está el cuello de botella en el proceso de release (al menos desde mi punto de vista).
12/05/2009 at 12:17 am Permalink
Contestando a tu pregunta: si puedo permitirme un departamento de QA dejaria que se mojaran ellos, sino podria llegar a probar este tipo de deployment y obrar segun los resultados. Es decir, prefiero confiar en una mezcla de «humanos» y tests automaticos, pero en caso de no disponer de «humanos» puede ser interesante del deployment continuos…
13/05/2009 at 11:42 pm Permalink
Yo creo que el punto clave del deployment continuo, es que también tienes que cambiar el chip con respecto a tus ciclos de desarrollo.
Es decir, partiendo de una base en la que tienes la aplicación X subida, te hace preguntarte:
– ¿cual es el siguiente bug a solucionar?
– ¿cual es el siguiente feature a implementar?
Con este sistema las prioridades se plasman al instante en el servidor. Como se suben pocos cambios a la vez, es menos probable hacer una pifiada del copón por estar 1 mes implementando cosas nuevas y luego subirlas. Y si haces algo mal, seguro que al dia siguiente ya te has enterado y puedes solucionarlo rápidamente (porque el desarrollador también lo tiene fresco). Hay que asegurarse de testear bien los cambios del copón 😉
Bien es cierto, que si la pifias muy a menudo subiendo cosas al servidor, la gente va a pensar que tu web es un asco, porque siempre está fallando.
PD: asumir que tus usuarios son testers no es muy buena idea, lo se, no pretendo que lo sean. Como ya dije, al final yo al menos, lo que pretendo sacar de estas ideas es saber para cualquier build, si sería deployeable, y tener un botoncito que lo deployee automáticamente. Qué builds deployeo o dejo de deployear de momento quiero seguir haciéndolo de forma manual.