Jorge, Gracias por tu comentarios y halagos. :D Es cierto, muchas veces ( la mayoría del tiempo) los developers están atados a calendarios imposibles de cumplir, etc. que haces que no puedan terminar su trabajo en la forma deseada. Dicho esto y pensandolo objetivamente el que escribe el código es el developer. Por ende, es el el responsable de lo que escribe (el y nada mas que el).
Tomemos el ejemplo de escribir en forma correcta y sin errores de ortografía ( YO CLARAMENTE NO LO HAGO ;) ) Cada uno de nosotros es responsable de mantenerse al día y saber las reglas ortográficas, no podes culpar a tu empresa porque te apura a escribir algo, deberías, en teoría, escribir correctamente desde un principio. Eso no implica que tengas errores casuales, pero si implica que tengas que saber las reglas y normas. Ya que sabiendo las reglas y normas en general vas a evitar el 99% de los errores que podes llegar a tener. Lo mismo pasa con la seguridad, como developer de un cierto lenguaje es tu responsabilidad educarte , conocer las reglas del lenguaje y aprender como programar en el mismo. Saber programar también implica programar en forma correcta y programar en forma correcta definitivamente implica programar pensando y teniendo en cuenta la seguridad del sistema. La realidad es que en casi ninguna etapa de nuestra educación sea en la universidad o en forma propia se tienen en cuenta un proceso de seguridad. Bueno, nos estamos yendo de tema. Saludos y mil disculpas por cambiar el topic del thread. 2008/12/3 Jorge Kalmbach <[EMAIL PROTECTED]> > Solo como acotacion al pie, me parece bueno aclarar que no siempre que > encontramos vulnerabilidades en un app le hechemos la culpa a los developers > de una diciendo que estos no tienen ni idea de practicas de seguridad. En la > mayoria de los casos las empresas no invierten en seguridad, crean una > bateria de smoke tests y casos de uso especifico, si eso pasa el release se > aprueba, en todo caso despues cuando la aplicacion es estable y los reditos > fueron buenos la empresa invierte en consultores de seguridad o en el peor > de los casos lo hacen despues de algun incidente. Pocas empresas se rigen > por un riguroso proceso de calidad, y a veces los tiempo sencillamente no > dan, hay que sacar un release porque hay una demo ya programada ante un > grupo de inversores y los developers hacen lo que pueden, y la clasica frase > de los dirigentes es: "despues vemos, ahora hay que terminar esta feature" > :D > > Por otro lado tambien es cierto que los developers no son (somos) expertos > en seguridad, sino los consultores de seguridad no tendrian trabajo ;). > > Aprovecho tambien para responder algo que lei en este mismo thread, donde > hablaban de que mantener los tests puede ser una tarea tediosa frente a los > cambios de codigo. El tema es que unicamente deberias cambiar los tests > cuando renombras classes lo cual es bueno si estas limpiando el codigo pero > no es algo que se hace seguido, si los tests estan bien construidos y el > resultado esperado de los metodos esta bien definido, cuando cambies el > codigo de los metodos esto no deberia afectar en absoluto a los tests, esa > es la maravilla de la ecapsulacion. > > Bueno, lean el paper de Matias que esta muy bueno. > Saludos. > /jk > > 2008/12/3 Matias Pablo Brutti <[EMAIL PROTECTED]> > > Se que es un poco "off Topic" , pero hablando de testing yo ademas de >> pensar los tipos de tests que mencionan como consultor de seguridad se me >> vienen a la marola, los tests que yo tengo que hacer a diario. Y que creo >> que deberian estar haciendolo los developers como parte de "testing" >> Mi recomendación con respecto a tests de seguridad es hacer ambos tipos >> whitebox ( auditoria de codigo) y blackbox en la forma de web application >> Penetration tests. >> >> En la ultima LugparanaConf que se realizo en Paraná, di una charla >> sobre vulnerabilidad en aplicaciones web con una orientación para >> programadores y developers. ya que a diario veo que la gran mayoría de estos >> no tienen ni idea de practicas de seguridad. Talves para >> la próxima reunión que tengamos la pueda orientar exclusivamente a >> ruby/rails/otros frameworks y dar algo. SI alguien tiene ganas hasta podemos >> hacer algo en conjunto. >> >> Slds. >> >> >> >> 2008/12/3 NachoKB <[EMAIL PROTECTED]> >> >>> >>> >>> 2008/12/3 Nicolás Sanguinetti <[EMAIL PROTECTED]> >>> >>>> >>>> Hasta hace un tiempo, era un firme creyente en limitar los tests al >>>> caso mas especifico posible, stubbear todo, y asegurarme de que todos >>>> los tests fuesen unitaros. >>>> >>>> Hoy en dia, hago todo lo contrario. Estoy escribiendo *solo* tests de >>>> aceptación (usando Cucumber), y cuando necesito testear algun edge >>>> case, o tengo que modelar algún api "no convencional", bajo a escribir >>>> units. >>> >>> >>> A mi me pasa justamente que me cuesta muchísimo pensar "de arriba hacia >>> abajo", necesito siempre comenzar por los units (y, digamos, siempre queda >>> poco tiempo para integración y aceptación). >>> >>> Recién cuando voy conociendo la funcionalidad es que "me sale" el diseño >>> de la "interacción"... >>> >>> >>>> >>>> >>>> Ojo, los tests son lentos. Esa es una contra grande a ir contra toda >>>> al aplicación en lugar de testear en aislación una clase dada (además, >>>> ruby es lento! >:-)), pero a) me dicen si anda o no exactamente lo que >>>> el cliente quiere (si los stories de cucumber son buenos) y b) no >>>> pierdo horas manteniendo tests. >>>> >>>> (b) es un problema grande. Mañana refactorizas un método de un modelo >>>> y pasa una de dos cosas: >>>> >>>> 1) Cambiás todos los controller tests que usan dicho modelo >>>> (engorroso, aburrido, perdida de tiempo que le estás cobrando a tus >>>> clientes sin darle ningún beneficio a ellos) >>>> >>>> 2) Te olvidás, y todos los tests siguen pasando, por más que tu >>>> controller se rompe, y el cliente te llama a las 3am para putearte >>>> porque justo hizo una demo a un potencial inversionista =P (no, no me >>>> pasó, pero podría) >>>> >>>> >>>> En definitiva, escribir tests a lo más alto nivel posible, y, a medida >>>> que se hace necesario por edge cases, ir bajando de nivel hasta units. >>> >>> >>> Me encantaría :D >>> >>> >>>> >>>> >>>> Y ta, el tema de la lentitud se puede "arreglar" no corriendo toda la >>>> suite de tests todo el tiempo, sino solo los que te importan a vos >>>> mientras estas trabajando, y dejar que un servidor de integracion >>>> continua como Integrity [1] te avise si se rompio algo ;-) Así >>> >>> trabajan en github, por ejemplo (si, si, usan integrity =P) -- Ojo, >>>> esto solo funciona si pusheas cambios seguido. Si sólo pusheas una vez >>>> al final del dia, suerte en pila =) >>> >>> >>> Chivo!! :D >>> >>> >>>> >>>> >>>> -foca >>> >>> >>> -- nachokb >>> >>> >>>> >>>> >>>> [1] Chivo! http://integrityapp.com >>>> >>>> On Wed, Dec 3, 2008 at 12:38 PM, Pedro Visintin >>>> <[EMAIL PROTECTED]> wrote: >>>> > Hola Gente: >>>> > >>>> > Creo que todos estamos de acuerdo que las metodologías no estan 100% >>>> maduras >>>> > y estan evolucionando continuamente. >>>> > >>>> > A medida que avanzamos nos aparecen nuevas preguntas y >>>> cuestionamientos >>>> > sobre lo que venimos haciendo y si nos sirve para lo nuevo o si hay >>>> forma >>>> > mejor de hacerlo. >>>> > >>>> > Muchas veces caemos en el cliche de tomar lo que dice el libro, pero >>>> siempre >>>> > es lo mejor? >>>> > >>>> > En cuanto a testing hay muchos interrogantes y muchas diferentes >>>> formas de >>>> > encarar las cosas. >>>> > >>>> > Esta charla plantea algunas cosas interesantes para pensar: >>>> > >>>> > http://rubyconf2008.confreaks.com/testing-heresies.html >>>> > >>>> > De ahí sale la pregunta: Con los specs y tests de controllers hago >>>> stubbing? >>>> > >>>> > pros que veo con stubbing: >>>> > el dominio del test lo tengo claro, estoy testeand el controller. >>>> > me fuerza a hacer stubbing de todas los mensaje s que mando a los >>>> objetos lo >>>> > cual queda bien ajustado. >>>> > me delata si tengo acciones mal hechas cuando tengo que hacer mucho >>>> stubbing >>>> > es porque el controller esta haciendo mas de lo que tiene que hacer. >>>> > >>>> > contras que veo con el stubbing: >>>> > si mi diseño del controller no es bueno voy a avanzar muy lento >>>> teniendo que >>>> > hacer miles de stubbings y mocks >>>> > pueden romper el modelo y el spec del controller va a seguir >>>> funcionando. >>>> > (aqui un punto interesante, el spec de controller es de integracion?) >>>> > >>>> > pros que veo sin stubbing: >>>> > estoy testeando el modelo tambien >>>> > puedo ahorrar tiempo en el stubbing >>>> > >>>> > contras que veo sin stubbing: >>>> > no queda claro que estoy probando en los specs se mezcla un poco la >>>> cosa, >>>> > requiere mas atencion al escribirlos >>>> > acciones complejas en el controller pasan desapercibidas >>>> > >>>> > Seguramente sus puntos de vista seran diferentes y me parecio >>>> interesante >>>> > abrir la discusión >>>> > >>>> > Gracias por hacer tan buena esta lista! >>>> > >>>> > Saluti >>>> > >>>> > P >>>> > >>>> > -- >>>> > Pedro Visintin . S o f t w a r e A r c h i t e c t >>>> > http://www.pedrovisintin.com >>>> > >>>> > Ruby On Rails Argentina. http://blogs.onrails.com.ar >>>> > >>>> > Personal page: >>>> > http://www.p-e-t-e-r-p-u-n-k.com.ar >>>> > >>>> > "Todo descontento por aquello que no tenemos parece provenir solamente >>>> de >>>> > nuestra falta de gratitud por aquello que tenemos" >>>> > >>>> > >>>> > > >>>> > >>>> >>>> --~--~---------~--~----~------------~-------~--~----~ >>>> Grupo de Usuarios Ruby del Uruguay - >>>> http://groups.google.com/group/ruguy >>>> Anular suscripción - [EMAIL PROTECTED] >>>> -~----------~----~----~----~------~----~------~--~--- >>>> >>>> >>> >>> _______________________________________________ >>> Ruby mailing list >>> [email protected] >>> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >>> >>> >> >> >> -- >> -- >> --<自由編碼人>-- >> Ing. Matias Pablo Brutti >> Security Consultant >> Email : [EMAIL PROTECTED] >> Site: http://www.freedomcoder.com.ar >> >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > > -- -- --<自由編碼人>-- Ing. Matias Pablo Brutti Security Consultant Email : [EMAIL PROTECTED] Site: http://www.freedomcoder.com.ar
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
