UTNianos

Para mí está perfecto que sea una materia de programación. Hacía falta una materia de ingeniería de software que no fuera solamente la administración del proyecto. Yo no la cursé, pero si hice tadp, y, por lo que leí, estoy 100% con la cátedra nueva.

Ahora, como opinar en el foro es gratis, para mí también falta una materia proyectual de diseño donde te digan "resolve un problema del mundo real usando lo que aprendiste hasta ahora". O que te den un problema del mundo real a resolver. Y una materia teórica donde se vea la historia y tendencias en human-computer interaction, diseño de producto, diseño de sistemas de información, diseño de ui, etc.

Ambas materias me parecen difíciles de implementar por diferentes motivos. La primera es un bardo de controlar y de calificar, y la segunda necesita docentes que sepan y apliquen lo que saben de esas áreas en el dia a día.

Con esto no quiero sugerir que es responsabilidad de la gente de diseño incluir esto en la materia, ya vienen haciendo bastante, solamente aclarar por qué me da cosa que se refieran a la implementación(programación) como "EL diseño" y el único aspecto que vale la pena (aunque antes de dar cualquier cosa, quizás si es preferible dedicarse solamente a las materias técnicas y exactas)

[attachment=8346]

Yo que antes me quejaba del tema auditoría porque me parecía una bosta, y ahora que me bajo "la nueva ppt" encuentro ésta porquería...NO FUERON CAPACES NI DE HACER EL CUADRO ELLOS MISMOS!

De terror muchachos, dejémonos de joder, tendrían que ponernos un MB10 carita feliz sellito de estrella por su falta de vergüenza.

Dejo para el lector el ejercicio de imaginar mi cara de "No podés ser tan caradura" mientras Sualdea nos daba aconsejaba cómo preparar buenas presentaciones en la época de presentar los proyectos a fin de año...

(23-02-2014 20:06)Dem0 escribió: [ -> ]Entonces no, una cosa no implica a la otra. Que una implique a la otra quiere decir que la relación es de "sí solo sí", bidireccional, no de "entonces".

Una cosa es conocer la mejor forma de llevar una implementación y otra muy diferente es determinar que forma del producto/sistema/servicio/proceso/etc. es la mejor solución a un problema. Fallar en lo primero es construir algo que se rompe o no es eficiente, y fallar en lo segundo es construir la cosa equivocada. En diseño de sistemas se estúdia lo primero, que en software se llama "programación".

Una cosa implica la otra: para poder programar BIEN hay que saber diseñar bien. A eso iba.



Por otro lado. Me anoté a ADR los miércoles a la noche. ¿Hice cagada? ¿Con quién me va a tocar?

Ya que estamos... ¿saben quién suele dar clases los viernes a la noche?

Yo el año pasado estuve viernes a la noche con el ladri de Sualdea. PERO también estaba Fabricio Restagno (el de Gestión de Datos) en otro curso.

Cita:Una cosa implica la otra: para poder programar BIEN hay que saber diseñar bien. A eso iba.

Si diseñar es definir como organizar el programa, por ejemplo siguiendo MVC, entonces tenes razón. Pero en ese caso, "diseñar" es "diseñar programar", que es programar.

Si diseñar es, por ejemplo, diseñar el producto, entonces no, programar bien no implica saber diseñar bien. El contrajeemplo de tu argumento es cualquier materia de programación, TADP y hasta Diseño de Sistemas. Ahí te pasan "requerimientos" de productos o servicios, vos no diseñas un producto sino que encaras la mejor forma de implementarlo/programarlo.

Creo que el concepto de diseñar se refiere en realidad al diseño a alto nivel de la aplicación, mas que nada un diseño de arquitectura en UML, esquematización y diagramas de clases y componentes, un mockup de las interfases, establecer los patrones a utilizar, etc. Al menos yo lo veo bastante separado del software eso, si bien la idea termina siempre siendo llevar el diseño a código (por lo que está bueno que el que diseña sepa programar).

Che la discusión sobre Diseño me parece re interesante (posta), pero me creo que tiene mucho más sentido moverla al famoso thread de Diseño, por varias razones:

- es coherente con el título del thread
- hay mucha más gente que puede opinar y enriquecer la discusión
- tanto docentes como consejeros miran de vez en cuando el thread

Sin ánimos de ofender a nadie, estaría bueno discutir acá cosas relacionadas a la bendita ADR. Y quién sabe, quizás en un par de años podamos discutir acá mismo sobre el enfoque de la "nueva ADR"

(25-02-2014 14:58)Nimix escribió: [ -> ]Creo que el concepto de diseñar se refiere en realidad al diseño a alto nivel de la aplicación, mas que nada un diseño de arquitectura en UML, esquematización y diagramas de clases y componentes, un mockup de las interfases, establecer los patrones a utilizar, etc. Al menos yo lo veo bastante separado del software eso, si bien la idea termina siempre siendo llevar el diseño a código (por lo que está bueno que el que diseña sepa programar).

Exacto.

En las primeras clases que tuve con Dodino se ve lo imposible que resulta separar del todo el diseño de la programación. Están un poco relacionadas, y no es simple decir "acá terminé de diseñar" y "ahora empiezo a codear". Si bien primero se establecen las ideas principales, las decisiones a tomar, cuando programás también surgen problemas que requieren conocimiento de diseño para solucionarlo.

Dodino también dijo una vez que lo importante es saber qué preguntas/problemas tenés que resolver ahora y cuáles tenés que resolver después. Hay patrones de gran rasgo que definís al principio (si usar base SQL o no-SQL, si usar MVC o MVVM, si usar un lenguaje tipado o no tipado, etc etc) y otros problemas que cuesta definir si son de programación o de diseño (si resolver X problema con un strategy o con un state, o usar un composite o un decorator para abstraer un concepto).

(25-02-2014 15:08)faloi escribió: [ -> ]Che la discusión sobre Diseño me parece re interesante (posta), pero me creo que tiene mucho más sentido moverla al famoso thread de Diseño, por varias razones:

- es coherente con el título del thread
- hay mucha más gente que puede opinar y enriquecer la discusión
- tanto docentes como consejeros miran de vez en cuando el thread

Sin ánimos de ofender a nadie, estaría bueno discutir acá cosas relacionadas a la bendita ADR. Y quién sabe, quizás en un par de años podamos discutir acá mismo sobre el enfoque de la "nueva ADR"

Adhiero con Fede

Y hablando del tema, mañana rindo el final. Alguno tiene un resumen o algunos tips para no fumarme las ppts?

(25-02-2014 15:08)faloi escribió: [ -> ]Sin ánimos de ofender a nadie, estaría bueno discutir acá cosas relacionadas a la bendita ADR. Y quién sabe, quizás en un par de años podamos discutir acá mismo sobre el enfoque de la "nueva ADR"

Será "la nueva NUEVA ADR", fede

y acá estoy preparando el parcial que rindo el miércoles y encuentro este concepto (en arquitectura multicapa con cliente desktop)

"La lógica de la aplicación ahora se encuentra dividida en tres partes. Esto complica la detección y arreglo de fallas."


cuando yo creo que dividir una aplicación en tres partes te ayuda a detectar y arreglar fallas.


siento que voy a desaprobar por no poner los conceptos actuales de 1987

Uff, yo tmb estoy cursándola y fue bastante debatido este tema en clase con el profesor, el cual no esta muy de acuerdo pero lo justifico diciendo que supuestamente es mas dificil encontrar errores porque la logica ahora esta dividida en varios lugares y eso hace mas complejo seguir el hilo de ejecucion.

Yo estoy bastante en desacuerdo con este tema, más sabiendo que desde que uno empieza a estudiar sistemas el primer concepto importante que aprende es el de "divide y venceras", y luego el tema de la modularidad, etc., entonces me resulta muy contradictorio que a esta altura me vengan con este cuentito.

una cosa es modularizar una aplicacion. Separarlas en distintos niveles para organizar el codigo, reutilizar, etc.
A eso se refiere como generalmente modularizar, lo que se ve usualmente en las materias

cuando se refiere ahi a que separa un sistema en multicapa, se refiere a que se separa en capas que pueden estar hosteadas (o no) en distintos lugares (lo cual no seria lo mismo a pispear el codigo en una unica solucion), y además, puede estar en distintos lenguajes

ej una web app en js, un backend en C#, con sql en una base de datos remota, y ademas consumir algun web service que está por ahi en PHP dando vuelta. No se, lo que se me ocurrió


la diferencia está en eso, pasa que no debe estar bien explicado. O asi lo entendi yo en su momento