Alguien conoce algún manual decente para empezar con javascript?? Que os parece este: http://www.librosweb.es/javascript/
SharePoint 2010 y C#
Aprovecho para decir que tocais unos lenguajes tan extraños y from the past que tela...
#274 Nop, estoy en una consultoria que solo trabaja con lenguaje microsoft.
#276 Yo también lo odio pero más odio otras cosas asi que mejor malo conocido que bueno por conocer... 
#248 +1 con Rails x'DDDD... web development that doesn't hurts
http://ruby.railstutorial.org/ruby-on-rails-tutorial-book
Ahora mismo acabo de terminar ¡por fin! un programa en C++ que lea desde un puerto serial virtual (COM1 ahora mismo) las temperaturas enviadas por Bluetooth recogidas por un LM35 controlado por Arduino.
Y quiero añadir, que he tirado todo el día enterándome de las putas pilas bluetooth (y acojonándome cada vez que leía por ahí que variaban de un sistema a otro) y liándome con librerías como 32feet para nada, cuando todo era tan fácil como configurar lo del puerto de serie.
#278 Ese manual que acabas de poner era LO ÚLTIMO que necesitaba para ponerme con Ruby después de años oyendo hablar de él. ¡Gracias!
El manual está genial, TDD desde el primer momento y deploys constantes... Rails no es algo fácil de pillar, pero lo tiene todo, está a otro nivel.
#282 Macho pues a mi Rails viniendo de Spring me pareció lo más fácil e intuitivo del mundo xD. Es puro amor.
Y eso hablando exclusivamente de Rails que si nos metemos con ruby y la metaprogramación ya son pajas de sangre.
#282 TDD, mi puta asignatura pendiente.
¿Alguien tiene experiencia REAL con TDD y puede comentar resultados? Es que no acabo de ver claro que ahorre tiempo de verdad.
Vale, hacer tests es positivo, eso lo tenemos claro, pero... ¿Test Driven? Muchas veces el diseño evoluciona con el desarrollo, haciendo un prototipo, haciendo tweaks aquí y allá... el TDD no hará más que perder tiempo en estos casos, ¿no? Y encima usar mocks es un puto coñazo y con TDD no te salvas.
Además me da la impresión de que el TDD hace más difícil la reacción al cambio (imagina cambiar una pequeña cosa y que se te rompan 30 tests...) mientras que cuando testeas lo justo y necesario sólo tienes que cambiar lo justo y necesario.
Por no hablar de tests en UI. ¿Quién coño tiene la UI clara al principio? Rehacer tests para la UI con cada cambio... pfff...
Es que me imagino haciendo TDD, terminar una feature, que el cliente me diga que no es así y querer morir.
#282 No se si me va a costar, programar se, en C, C++, java, Objective-C, SQL... y programacion web he tocado solo Java Servlets. Ayer empezé dandolé a una ojeada rápida e hice lo del try ruby: http://tryruby.org/levels/4/challenges/5 que por cierto está muy bien
Java y SQL .
El año que viene ademas de Java y SQL , tendré que dar javascript , php y la duda sera si seguiré con java o pasare a C ( ya que tengo cambio de profesor y no se que dara).
#284 Precisamente, los test son para ver que partes fallan de tu aplicación al evolucionar xD. Claro si te están cambiando requisitos cada 2 días pues no puedes hacer test pero es que falla el proyecto de base, empezar a hacer algo sin tener ni puñetera idea de qué se quiere (que una cosa es adaptarse a los cambios y otra vivir en el cambio diario). El desarrollo siempre será más lento pero si en mitad de una feature te cambia y tienes que cambiar parte de tu desarrollo, con los test sabes lo que está fallando y por qué. Por no hablar de que te aseguras de que desarrollas lo necesario (lo que está en los test) y no te vas por las ramas.
No se en los proyectos que trabajáis (no lo digo en tono despectivo), pero hacer cambios sobre aplicaciones grandes puede ser que una simple cosa te casque media aplicación y te lleve una semana probando y cambiando cosas, con los test sabes donde está fallando y sobre todo, te aseguras de que tu aplicación cumple esos requisitos (los test).
De todas formas yo no soy muy purista con esto y tener test de una cosa no quiere decir que esa cosa funcione correctamente (el test puede estar mal o simplemente no testear todos los casos posibles) pero nu sep, testear las cosas a mano es el mayor coñazo del mundo y pierdes muchísimo tiempo (mucho más que haciendo los test, te lo garantizo xD), de la otra forma tienes mayor control sobre la aplicación y que hace lo que debe.
Eso sí, de los test de la UI paso directamente, por ahí si que no trago xD
Hay algunos libros gratuitos por la red que hablan de TDD:
http://www.dirigidoportests.com/wp-content/uploads/2009/12/disenoAgilConTDD.pdf
Le echaríaun vistazo aunque el ejemplo del prologo a mi no me gusta la verdad xD
#288 lo que comentas es el beneficio de los tests y no del TDD.
Entiendo perfectamente el beneficio de testear, pero TDD es algo muy diferente. ¿Qué me proporciona hacer los tests ANTES y no después cuando ya está el comportamiento definido? No es lo mismo escribir tests (aunque tengas un 100% de coverage) que hacer TDD. La primera es necesaria, mientras que la segunda es una metodología de desarrollo.
No es una cuestión de requisitos que cambian, es una cuestión de comportamiento interno que evoluciona junto con el prototipo de la implementación (ya sea el prototipo de la aplicación completa o de un módulo en desarrollo), ¿me explico? Si con TDD defino el comportamiento antes siquiera de comenzar a prototipar el módulo tendré doble trabajo: escribir el test inicial y volverlo a escribir cuando no coincida con lo que necesito realmente.
#289 hacer los test de antemano muchas veces te sirve para identificar casos extremos en los que no caes a posteriori, cuando estas "contaminado" por la implementacion del codigo y ves las cosas de otra manera.
#290 y por qué un test y no en papel, que no hay que comerse la cabeza con la implementación del test, mocks, BD de test, inicialización de datos, etc.?
Se llama "diseño" xD El test no aporta valor añadido.
Aprovecho el hilo para preguntar, alguien que haya probado con varias alternativas para desarrollar apps web para móviles, ¿por donde tiraríais? He echado un ojo a AngularJS o incluso Dart + Rikulo pero no me decido... Y si tenéis algun tuto que usaseis en su momento o algo estupendo
PD: ¿Por lo que leo Ruby es puro amor, no? Le tengo ganas xD
#292 no, testear lo hago en un test. Los corner cases es lo que identifico en papel. No hay que confundir TDD con simplemente testear.
De hecho te argumentaría que no tengo ni puta idea de cuáles son algunos corner cases hasta que no estoy implementando y los veo en forma de código. Antes de implementar, para mí D* no es más que "que me de la ruta más corta y se actualice dinámicamente", ni corner cases ni leches.
¿En qué ayuda hacer TDD a identificar nada? El test no aporta valor, lo que hay que hacer es sentarse y pensar "¿cuáles son mis casos extremos? ¿dónde puedo cagarla al implementar?". Esto lo haces igualmente si te sientas delante de un papel o delante de un test.
De hecho, ¿cómo testeas con TDD un D*?
Si testeas la integración es una caja negra, necesitas saber la salida correcta de antemano... así que lo has tenido que hacer en papel o de cualquier otra forma.
Si testeas unitariamente cada función... vuelvo a preguntar, ¿qué beneficio aporta el TDD frente a identificar corner cases, implementar y testear?
#294 tres articulos que reflejan bastante bien la idea de TDD:
http://scrumology.com/the-benefits-of-tdd-are-neither-clear-nor-are-they-immediately-apparent/
http://scrumology.com/the-benefits-of-tdd-part-2/
http://scrumology.com/the-benefits-of-tdd-why-tdd-part-3/
TL;DR: la adopcion de TDD hace que inicialmente tu productividad disminuya (malo) pero cuando lo dominas el codigo generado a partir de tests tiende a ser menos complejo (bueno) y respetar mas el patron SOLID (bueno tambien).
Yo nunca he usado TDD como forma exclusiva de desarrollo pero hay que decir que si tienes que desarrollar cosas completamente deterministas es un comienzo bastante bueno.
#295 gracias, les echaré un vistazo, aunque me interesa más la otra parte (criticas a TDD) porque los beneficios me los sé de memoria de tanto leer evangelizaciones xD Lo que me interesa es experiencia real, no un montón de letras sobre por qué teóricamente es positivo.
El problema es que no tengo suficiente experiencia con TDD ni para apoyar ni para criticar esos artículos, así que me quedo un poco igual, y la mayoría de gente que apoya o critica TDD lo hace desde una perspectiva teórica.
Yo estoy empezando con TDD en algunos proyectos concretos... en algunas ocasiones desarrollo más rápido y en otras no tanto. Cuanto más TDD hago, más rápido noto el workflow en general. Encima sabes exactamente cuándo parar de desarrollar esa función.
Hay una diferencia entre hacer un test antes de picar el código y después de haberte peleado... y, en cualquier caso, tarde o temprano vas a tener que comprobar que tu código funciona, ya sea con un log, un echo, un print o cualquier mierda... ¿por qué no hacerlo bien desde el principio?.
Tampoco se me ha dado el caso todavía de cambiar una especificación y tener que actualizar 300 tests, pero supongo que si te toca actualizar 300 tests es porque algo muy malo ha pasado.
#296 Yo con los únicos problemas que me encuentro son por mi culpa, por no tener experiencia suficiente, de resto es puro amor.
PD: En el libro también te habla acerca de que no todo tiene que pasar por TDD, por ejemplo, aplicándolo al desarrollo web, hay que comprobar en las páginas exista un footer con un copyright, y puede que tengas un Test que lo certifique, pero si le cambias una coma o cambias el teléfono de sitio, no necesitas comprobarlo. Todo depende de lo que estés haciendo.
"Making tests a central part of the process because they’re useful to developers? Awesome. Dictating a workflow to developers that works in some cases as the One True Way: ridiculous."
RPV:
- ¿El problema es carne de TDD?, haz TDD
- Si en casos concretos es mejor hacer el Test después, hazlo después (no la semana que viene, sino una vez que sepas lo que has hecho y lo que tienes que testear)
- En cualquier caso, tienes que escribir los tests
#294 yo no soy un experto, y seguro que estoy haciendo un "dónde vas manzanas traigo", pero los cornercases como los llamas, al menos lo que entiendo yo (casos extremos para los cuales el algoritmo no da la mejor solución o tarda mucho más de lo normal) no son siempre fáciles de ver al menos en un problema de combinatoria (asignación de recursos, etc.). Vaya, a veces sólo el hecho de contar cuántas soluciones puede haber ya es chungo xD.
De todos modos pensaba que ahora se llevaba más el average case analysis, pero ya digo que no tengo ni idea eh xD.
TDD no es un metodo de testeo, sino de dise;o. Eso lo primero xD
Por mi parte ya he tirado demasiadas horas modificando test suites porque me hayan cambiado la spec. Nunca mais. A otro con ese hueso.
El TDD es para holamundos de github. En la practica el tiempo es demasiado valioso como para pasarlo escribiendo tests. Que no digo que los tests sean malos o innecesarios, pero cuando te pasas el 50% del tiempo con ellos algo falla, y es mejor dedicar recursos en cosas mas importantes.
Y es que una puta mierda de software sigue siendo una puta mierda de software, por mucha test suite y lucecita verde que tenga.
