#20 ya ves, los pliegos para una aplicación están hechos como si se fuera a pintar una fachada cuando la realidad es que el software es más parecido a un mural.
#69 Y tuvieron la suerte de estar en el momento adecuado en el lugar preciso. Clientes que acaban de llegar, proyectos de reciente creacion, etc. o sea lo que comunmente se conoce como suerte.
Como contrapunto yo conozco a gente que se parte el lomo por la empresa, obtiene certificaciones, etc y no recibe ni una misera palmadita en la espalda. Y tu podrias decir: "si es bueno pues que se busque la vida" y yo te diria "si, en Madrid o Barna, pero... ¿y si no quieres vivir en esas mierdas de ciudades?"
#69#52#61 No es 100% suerte pero tampoco es 0%. Yo caí relativamente pronto en mi carrera laboral en un área que ha tenido tirón, eso fue suerte porque con 1 año y poco de experiencia laboral yo no tenia ni idea de que tipo de tecnologías tenían futuro y cuales no. Aparte de eso, supe aprovechar la oportunidad de manera digamos medio decente, cambiando de curro un par de veces y aprendiendo mas y mas de mi área. Eso no fue suerte. Pero las cosas no son blancas o negras.
Por ejemplo, quien nada mas licenciarse empieza de junior en SAP tiene una suerte que te cagas. Es un área de nicho bien pagada y que se usa en todas las empresas gordas, y con una barrera de entrada bastante gorda porque formarte por tu cuenta es muy difícil. La oportunidad muchas veces SI es suerte, saber aprovecharla (o saber huir a tiempo de otros curros donde no aprendes nada) no lo es.
#101 Se perfectamente quien es Kent Beck, de hecho me gusta su libro 'TDD by Example'.
Dicho esto, yo opino que el agilismo si es una metodologia. Es especificamente una metodología de resolución de problemas de alta incertidumbre. Basicamente el concepto principal del agilismo es que cuando tus problemas tienen mucha incertidumbre, es muy probable que te equivoques. El problema de equivocarse no es el coste del error en si, sino cuanto tardas entender que te equivocaste.
Si estas creando un software y entendiste mal algo, cuanto mas continúes en tu error, mas caro será. Por lo que cuanto antes te des cuenta de si vas por el buen camino o no, mejor.
Para poder crear este marco de trabajo de iteraciones cortas, se han de dar una serie cirscumstancias especificas que permitan hacer el setup de la iteracion, ejecutarla y comprobar resultado, obteniendo feedback. Entonces, es en esta parte donde puede ser útil esta parte filosófica de la que se habla (demasiado creo yo). Por ejemplo, es imposible montar un ciclo de iteraciones con feedback para resolver un problema si no tenemos claro donde empieza y acabar la iteración. Ni tampoco tenemos claro como validar la iteración ni nada.
Si no me crees que el agilismo es unica y exclusivamente esto, podemos escoger cualquier metodología especifica que resuelve un problema especifico usando agilismo y ver si esto que estoy diciendo es cierto. En todas vamos a encontrar el mismo patrón: una estructura y prácticas pensadas para favorecer el setup de un ciclo de feedback.
De hecho, otro gran error que cometes es pensar que agilismo lo ha inventado Kent Beck y los demás. En realidad el agilismo (metodologías iterativas) es mucho mas antiguo que Kent Beck y que Xtreme programming etc. De hecho, tienes ejemplos en Toyota desde al menos 1940.
Podrías argumentar que fueron Kent Beck y los demás quien lo llamaron agilismo. Y estoy de acuerdo y es un nombre bueno, pero el concepto es mucho… » ver todo el comentario
#92 el agilismo es una metodología de resolución de problemas de alta incertidumbre. Es una metodología iterativa con ciclos cortos que a través del feedback reduce el coste provocado por la incertidumbre.
no existe tal cosa como valores ágiles, ya que insisto en que el agilismo no es una filosofía, sino un tipo especifico de proceso.
#101 Quizás de forma más general, y no solo aplicado a UML, a veces se olvida que un buen profesional sabe la diferencia entre cuando debe saltarse las "normas" y cuando debe aprovecharlas. Al final todo es un compromiso entre lo que ganas y lo que pierdes, un diagrama muy general puede ayudar a entender fácilmente cuál es la idea detrás de un módulo.
Una de las primeras cosas contra las que te advierten al estudiar programación son las variables globales y los goto. Es una regla del pulgar válida, pero que cuando seas profesional tendrás que valorar donde te conviene saltártela.
#101 Si, porque listos los de UML, cuando lo diseñaron, dijeron "coño, vamos a llamar todo lo que esta dibujado con diagramas y bolitas "UML as Sketch", y nos quedamos tan anchos".
Es una forma de decir mira, mi forma de programacion es Patatin, todo lo que no sea mi forma de programacion es "Patatin as Sketch".
#41 gran argumentación #47#28 siempre con lo mismo de "eso es que no se aplican bien los principios ágiles".
Nos ha jodido, es que si se aplicara bien la metodología tradicional, tampoco haría falta correr a última hora.
Yo os hablo de la práctica del día a día, y vosotros de la teoría. Al final es un problema de cultura del trabajo general, que no se arregla con metodologías concretas.
#41 Vamos, que aquellos trabajos en los que no sale a cuenta reducir la jornada son aquellos que tienen más probabilidades de ser sustituidos por robots. Blanco y en botella...
Es un proyecto Spring, JPA, etc... Los jsp se comunican con los controller (hay uno específico para las peticiones ajax por cada jsp que lo precisa) estos con los SpringServices y estos con los dao ambos con sus correspondientes interfaces e implementaciones separados.
Además están los command que suelen ser los bean de formulario y diversos validators.
En teoría los controller solo mapean y traducen como bien dices aunque alguna ñiapa que otra contienen
Lo que si que es cierto es que haciendo debug a veces puedes perder el hilo por la de saltos que hay entre métodos públicos y privados. Mi impresión es que la complejidad es notable pero bueno en eclipse inspeccionando los valores de los objetos y con el outline para no perder la referencia te apañas.
#44#48#51 Una clase una sola responsabilidad? No será un método de clase una sola responsabilidad?
Según eso, para una página que tiene varias funcionalidades en vez de tener un controller con varios métodos que mapeen cada funcionalidad debería tener uno por cada una?
En el proyecto en el que yo estoy eso sería como ver un unicornio
#152 Tu caso Alfredo es un poco especial. Tu tienes un nivel muy alto (recuerdo bastantes podcasts de javahispano donde salias) donde digamos que están el 5% de profesionales tic. luego hay un 20-30% que son buenos luego ..etc
Dentro de la profesión hay niveles, no es lo mismo crear una arquitectura para una aplicación con cierta complejidad, que hacer pantallas copy-pasteando las que están creadas.
La mayoría de gente por muchos motivos no puede negociar con su talento, y todo y ser buenos profesionales, necesitan un soporte vía convenio o vía lo que sea para que el trabajo le ofrezca estabilidad, buen sueldo..etc. Si no se ponen límites esto es una jungla en que el único perjudicado es el trabajador.
También es cierto que p.ej en la provincia de Tarragona es prácticamente imposible que un alguien programando tenga un sueldo ni que se acerque siquiera al de un operador de planta químico (con un buen convenio..). Si a mi hijo le gustase programar y también le gustase trabajar con un torno haciendo piezas.. le recomendaría que hiciese un módulo de metal y no se complicará la vida..Para lo complicado que es realmente programar esta mal pagado.
Yo recomendaría sin duda estudiar programación si realmente te gusta (como es mi caso), efectivamente se puede llegar a trabajar desde casa como freelance, hay poco paro..etc. Aunque he reconocer que muchos ex compañeros de trabajo salieron por patas de España y es una pena que no se haga nada para remediarlo..
#33 RoyBatty66 
