Yo estoy cursando diseño con Passerini y esta semana tuvimos la primer entrega de TP...
Te cuento que a nosotros nos preguntó por qué hicimos una cosa de determinada manera y, cuando le respondimos, nos dijo más o menos esto: "Yo lo hubiese hecho de esta otra manera, porque te beneficia en 'X' cosa. Pero de la manera que lo hicieron ustedes, tienen la ventaja de 'Y'. Es una cuestión de diseño, ustedes decidieron priorizar Y sobre X y me fundamentaron por qué; así que está bien"
Y nos terminó calificando la entrega como "Muy buena".
Espero haber podido contestar tu pregunta después de
2 3 páginas de espera
(18-05-2012 15:43)el pibe escribió: [ -> ]A mi lo que me sucedio, es que ni siquiera hubo un "mal" justificativo, me dijeron textualmente "No nos gusta que lo hagas asi".
Claro, a mí me pasó algo parecido =P
Después me di cuenta que en realidad lo que yo había hecho estaba mal, pero no porque "a ellos no les gustaba" sino porque realmente estaba mal xD
Solo que faltaba una explicación a eso =P
Por ahí es lo mismo que te pasó a vos xD
(18-05-2012 16:03)lifestyles27 escribió: [ -> ] (18-05-2012 15:43)el pibe escribió: [ -> ]A mi lo que me sucedio, es que ni siquiera hubo un "mal" justificativo, me dijeron textualmente "No nos gusta que lo hagas asi".
Claro, a mí me pasó algo parecido =P
Después me di cuenta que en realidad lo que yo había hecho estaba mal, pero no porque "a ellos no les gustaba" sino porque realmente estaba mal xD
Solo que faltaba una explicación a eso =P
Por ahí es lo mismo que te pasó a vos xD
Bajon
A mi me compilaba, andaba, y cumplia la funcionalidad.
Pero me lo hicieron con los 3 paradigmas, asi que estoy de malas con pdp.
Tambien cosas como "No esta bueno que lo hagas asi".
Pero a ver, mas alla de eso, me reprobaban ! Onda... si no te gusta, alla vos, pero si cumple las consignas me tenes que aprobar !
(18-05-2012 15:54)tenchology escribió: [ -> ]Yo estoy cursando diseño con Passerini y esta semana tuvimos la primer entrega de TP...
Te cuento que a nosotros nos preguntó por qué hicimos una cosa de determinada manera y, cuando le respondimos, nos dijo más o menos esto: "Yo lo hubiese hecho de esta otra manera, porque te beneficia en 'X' cosa. Pero de la manera que lo hicieron ustedes, tienen la ventaja de 'Y'. Es una cuestión de diseño, ustedes decidieron priorizar Y sobre X y me fundamentaron por qué; así que está bien"
Y nos terminó calificando la entrega como "Muy buena".
Espero haber podido contestar tu pregunta después de 2 3 páginas de espera
Si, gracias
De paso, Passerini es profesor o ayudante ?
Habria que hacer un estudio, mi problema lo tuve con un ayudante; Aplicar transitividad a los profesores tal vez no se cumple (?)
Para los que cursaron las 2, ¿la materia es, básicamente, TADP (OOP)?
para los que se preguntan sobre la nueva cátedra de diseño acá pueden ver de qué se trata...
yo estoy muy contento de haberme cambiado
http://www.ddsutn.com.ar/
PD: hoy nos entregaron el parcial y no fué tan difícil. pensé que era un 3 y fue un 6 en mi caso.
Saludos.
Ah, ok. Es una materia de ingeniería de software.
dejo esto por acá...
http://www.aosabook.org/en/index.html
Cita:Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's successes.
Our goal is to change that. In these two books, the authors of four dozen open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to these books provide unique insights into how they think.
If you are a junior developer, and want to learn how your more experienced colleagues think, these books are the place to start. If you are an intermediate or senior developer, and want to see how your peers have solved hard design problems, these books can help you too.
De lo mejor que leí en lo que respecta a diseño de software.
los problemas son los mismos de siempre. las soluciones tambien, solo cambia el lenguaje de programacion
siempre la programacion molestando
(30-08-2012 11:45)el pibe escribió: [ -> ]los problemas son los mismos de siempre. las soluciones tambien, solo cambia el lenguaje de programacion
siempre la programacion molestando
No entiendo ni a qué te referís, ni el por qué lo decís.
Así que voy a suponer.
1) El swebok como libro para aprender diseño, me parce horrible. El diseño es un proceso de síntesis, tenes que "equilibrar" diferentes características de lo que diseñas con un objetivo. El swebok, como mucho, te lista algunas.
2) Los "lenguajes de programación" nunca te van a resolver "el problema". Te van a presentar un modelo computacional/ de programación, de forma que puedas expresar las operaciones necesarias que querés que haga la computadora para resolver el problema. Entre mejor se ajuste el modelo que te presentan al problema, podes tener menos tiempo de desarrollo, menos errores, menos complejidad técnica, etc, etc, etc.
Así que no, decir "siempre la programación molestando" es medio una boludes.
(30-08-2012 17:44)Dem0 escribió: [ -> ] (30-08-2012 11:45)el pibe escribió: [ -> ]los problemas son los mismos de siempre. las soluciones tambien, solo cambia el lenguaje de programacion
siempre la programacion molestando
No entiendo ni a qué te referís, ni el por qué lo decís.
Así que voy a suponer.
1) El swebok como libro para aprender diseño, me parce horrible. El diseño es un proceso de síntesis, tenes que "equilibrar" diferentes características de lo que diseñas con un objetivo. El swebok, como mucho, te lista algunas.
2) Los "lenguajes de programación" nunca te van a resolver "el problema". Te van a presentar un modelo computacional/ de programación, de forma que puedas expresar las operaciones necesarias que querés que haga la computadora para resolver el problema. Entre mejor se ajuste el modelo que te presentan al problema, podes tener menos tiempo de desarrollo, menos errores, menos complejidad técnica, etc, etc, etc.
Así que no, decir "siempre la programación molestando" es medio una boludes.
yo tampoco entendí. por qué no nos explicás mejor qué quisiste decir?
saludos.