#44 Ya te vale amigo... para asesinos, esos títeres que colocaba la CIA, por doquier, en el Cono sur.
Documéntate un poco, anda...vaya niñatos despistados que pululan últimamente por Menéame...
Evidentemente puede ser muy bonito por dentro pero dentro de diez años estar hecho mierda. Sin embargo recordar que estructuras como la Torre Eiffell llevan más de cien años en pie y son también montadas por piezas.
#67 Un bosque nuevo en un sitio donde no había captura CO2 mientras el bosque crece. Pero llega un momento en el que se estabiliza y ya no captura, se vuelve neutro.
Así que para compensar el petróleo que quemamos habría que estar construyendo continuamente nuevos bosques, hasta que no haya más sitio. La única solución posible (iba a poner viable, pero no creo que lo sea) es la de #55, enterrar tantas toneladas como las que extraemos.
#55 si pero un árbol nace y muere, pero tiene hijos, genera frutos para que crezcan mas árboles... el asunto es que los árboles son acumuladores de C02, por eso cuando hay un incendio lo liberan, por eso hay que intentar que no haya quema de árboles porque si. Otra ventaja absorbe y expulsa oxígeno.
Ahora bien, hay muchas formas, evitar propagar mas emisiones (evitar desplazamientos, trabajos remotos, deslocalización de grandes urbes (justo propagas la emisión para que los árboles puedan absorber mejor), reducirlas y que sean capaces de absorber... pero has indicado una cosa, economicamente viable y hay esta el problema, no es viable fin, pero son inversiones con otro fin mayor pero como siempre la economía debe mandar sobre la salud y ese es nuestro problema, si ponemos la economía por delante ya estamos condenamos.
#267 Que no han subido lo suficiente? Pero si en algunos sectores, hasta han bajado
La mediana de los sueldos espannoles está igual que hace más de 20 años. En fin, un despropósito.
#264 Para mi comunión me regalaron un Amstrad CPC 6128, creo que eran unas 70-80 mil pesetas, unos 500€, supongo que ajustado a inflación hoy en día unos 1300€.
Así, que sí los PC eran caros, pero los ordenadores domésticos, no lo eran tanto. Tampoco sé cuanto podía costar una video consola, pero creo que la Nintendo rondaba las 30.000 pesetas, o algo así, ¿no?
UML no se usa, salvo en situaciones muy puntuales donde la forma más clara de explicar un flujo de datos o el la colaboración entre diversos sistemas requiera un gráfico de calles de piscina, de colaboración, o de secuencia.
- Para hacer ingeniería inversa
- Para modelar use cases scenarios
- Para modelar máquinas de estado
- Para expresar el comportemiento de una historia de usuario en el tiempo
Hay muchos ejemplos donde debes usar UML porque el texto siempre va a ser más ambiguo que los diagramas UML hechos para los distintos stakeholders.
Y no se usa por una razón muy concreta: no es mantenible.
No es mantenible porque la gente usa herramientas de diseño en lugar de herramientas case para UML por ejemplo StarUML e una herramienta case donde tu diagramas y luego conviertes a código java, c#, javascript, sql, etc lo que has diseñado. Claro si usas drawio es una locura pero con una herramienta case te paras encima del caso de uso y ves todos los artefactos enlazados a ese caso de uso. Por lo tanto, si creo que es mantenible
Un modelado UML es como los planos de un edificio: muy bonito, y exhaustivo, pero si tienes que tirar abajo varias paredes, abrir un suelo para añadir un garaje, y adjuntar pozos de ascensor externos, los planos se quedan anticuados y, o alguien tiene que actualizarlos, o se tornan obsoletos.
Con la herramienta case lo resuelves porque usa trazas. Recuerdas las trazas de UML? Donde desde una colaboración de caso de uso puedes poner traza hasta los clasificadores de análisis (boundary, control and entity class). Y de ahí a los clasificadores en la fase de Diseño y así por todas las fases siempre poniendo trazas entre los artefactos. StarUML permite hacer eso muy simple porque es para ello.
Muchas vacas sagradas que nos enseñaron cosas en los 90s y 2000s (como UML, OOP, y más) se han visto superados en el tiempo no por "la última moda", sino porque tras 20-30 años de experiencia, se ha demostrado que son lastre.
Soy un fan de esta parte de la ingeniería y de Rumbaugh, Jacobson, Booch, Liskov, etc.
Por cierto. Sobre la recopilación de requisitos, te recomiendo que te actualices, porque los casos de uso no se usan desde hace más de una década. Hay una docena de técnicas diferentes que se deben usar en paralelo, cada cual más apropiada a la naturaleza concreta del sistema o del requisito.
No se ha encontrado forma más eficiente de tomar requisitos. Me lo dices por las famosas "historias de usuario" que cuando las anlizas es lo mismo que un caso de uso porque ya las han agrandado que es una locura. Los casos de uso se siguen usando para realizar ingeniería inversa, incluso en el mundo ágil proque al igual que las historias de usuario modernas están compuestos por escenarios. Todavía no se ha inventado una forma mejor de obtener requisitos de software de una manera no ambigua.
#257 por las respuestas recibidas veo que he pinchado donde duele....centrarse en el tema del número de lineas no es lo importante,es solo un ejemplo en un caso particular que me ocurrió una vez.Como dice #149 se trata más bien de no intentar reinventar la rueda y emplear aquello que ya se ha pensado para resolver un problema. Un ejemplo lo encontré en dispositivos en los que había que gestionar acceso a recursos compartidos con procesos simultáneos que en ocasiones ha Ia que sincronizar. Las mates nos enseñan que la estructura básica adecuada son las redes de petri, no hay mucho que discutir sobre esto. No he conocido un informático que supiera de su existencia, aunque supongo que los habrá.
#265 los compiladores y los lenguajes existen precisamente para abstraer al programador de la inmensa complejidad de cualquier maquina de estados no trivial.
#158 Yo todavía utilizo diagramas de clases para pasarle la tarea a los programadores, con un simple diagrama de clases tienes la mayoría del problema resuelto, al menos de modelo datos. Hay plataformas que te implementan el código, a partir del diagrama te hacen la estructura básica y sólo queda hacer las extensiones, la que yo uso te implementa hasta la interfaz completa (framework muy concreto)
Un diagramita de casos de uso y de secuencia viene mu bien para explicarle al cliente que es lo que quiere.
#149 Yo siempre he dicho que saber programar es como saber pintar un cuadro. Hay que valer para coger un lienzo en blanco, visualizar lo que quieres y ser capaz de crearlo.
Luego ya los lenguajes son las diferentes técnicas que puedes emplear.
#158 Como anécdota personal con el UML que ilustra lo que dices, yo estuve en una empresa donde usabamos sparx Enteprise Architect para modelar con OMG UML el par de cientos de sistemas que usaba la empresa. Despúes de menos de un par de años de uso, se dejó de mantener dicha herramienta y modelado, por que los architectos de soluciones eran incapaces de mantener el mounstruo en el que se convirtio el EA.
#149 "The Art of Computer Programming" debería ser la biblia de cualquier ingeniero en informática. Quién domine todos los algoritmos que hay ahí (aunque no se los sepa de memoria), sabe programar a un nivel del top 1% de los programadores. Por desgracia, en 4 años no da tiempo a meter este contenido junto con todo el resto de contenidos que se deben enseñar. La carrera de II debería durar 6 años.
#129 no es un mal libro.
Lo malo es el integrismo.
Es muy importante en una empresa establecer unas convenciones de código, pq nadie puede ser imprescindible.
El código mantenible e independiente de librerías externas es vital en un producto a largo plazo. Y ha de estar abstraído totalmente del entorno en el que se ejecuta.
De lo contrario tus costes de mantenimiento irán creciendo más que tus mejoras en producto.
Y el uso de ddd es vital para trabajo en equipos desde mi punto de vista.
Documéntate un poco, anda...vaya niñatos despistados que pululan últimamente por Menéame...