Off-topic:

pasar de una arquitectura monolitica a una dividida en varias capas implica tener mas partes moviles. lo que hace que haya mas puntos posibles de falla, y que sea mas dificil encontrar que es exactamente lo que esta fallando. lo cual en mi opinion no es una contra suficiente para dejar de lado la idea de modularizar.

pero no habla de pasar una aplicación existente a una dividida en capas. Si tenés 3 capas, cada capa está correctamente mockeada y testeada, sabés exactamente dónde falla algo cuando hay un bug.


sabés qué petición le tiene que llegar al webservice y qué tiene que devolver, eso se testea de forma unitaria y aislada. Lo mismo el cliente, sabes qué tiene que enviarle al webservice y qué tiene que esperar como respuesta, eso se mockea. Y con la base de datos exáctamente lo mismo.


menos mal que falté a esa clase, me hubiera peleado con el profesor.

---

"Actualmente la performance de ejecución de código JavaScript en los Browser es inferior a la de otros lenguajes existentes: Java, .NET, PHP. "

con el motor V8 de chrome esto sigue ocurriendo o es otro delirio que encontré en las ppt?

"Actualmente" es un smoke alert siempre. Aún así, todas las técnicas que usan en V8 seguramente existan en Java. Por los otros dos no podría hablar.


Decir que separar en tres capas "complica la detección y arreglo de fallas" es una frase... osada.

Lo realmente es peligroso que lo den como un mantra.


Separar la aplicación en tres capas incrementa la complejidad del sistema. Eso es factual.

Ahora, complicar la detección y arreglo, no me queda tan tan claro que sea siempre válido. Me parece que no son comparables.

Encontrar errores en un programa perfectamente bien diseñado y modularizado y blah, pero que es standalone, puede ser más complicado de encontrar que un error en tu servidor, porque al servidor tenés acceso y quizás puedas reproducir el problema y parchear el software más rápido. Encontrar errores en Office es facilísimo porque tiene un montón, pero habrá muchos que son dificiles de encontrar porque tenés millones y millones de instalaciones hechas, y upgradearlas cuando tenés el fix es un bardo. En cambio, en Google Docs _lo tienen ahí_.

Pero también es cierto que en GDocs tampoco es trivial encontrar los problemas. Hay mil configuraciones de browsers, entran en juego latencias de red, la puta versión del soft que estabas usando en ese momento, etc. No es trivial, tampoco, reproducir los errores, qué se yo. Quizás algunas aplicaciones standalone bien enlatadas, por el hecho de tener menos componentes, tienen menos puntos de falla.



Pero, insisto: me parece una afirmación peligrosa para hacer tan "firmemente".

Y eso es algo muy poronga de ADR. Tienen en mente UN caso que a uno se le ocurrió una vez, pero como decir "una vez me pasé una semana y media debuggeando un error en el JS de mi página" es poco académico, tratan de generalizarlo (o, quizás, convertirlo en chisme enigmático) y terminan jurando por Ala que es más dificil, y, bueh.

en el apunte que yo recuerdo iba pasando de una arquitectura a la siguiente, y comparando unas con otras, en fin, es anecdotico. lean lo que puso desert.

la respuesta a lo de la velocidad: Depende que hagas
creo que el principal problema es querer resumir todo en 4 o 5 frases cortas. qeu supuestamente te tiren "la posta" para evaluar tecnologias

Es lo que pasa cuando el único material que se ofrece son ppts.

Cada vez que pienso que tengo que dar este final me quiero matar un poco más.

no hay nada que se pueda hacer al respecto? es peor que la cátedra vieja de diseño. Bue quizás estoy exagerando, porque no fui a casi ninguna clase, pero el parcial que tomaron fue un asco (y encima desaprobé por gil)

Adhiero, humo total toda la materia. Y sualdea tampoco le pone demasiada onda, pasa los ppts y chau

(16-06-2014 23:16)Vallo escribió:  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."

Que necesidad de meter esos temas.

Lo que intentan "explicar" es un mal copy-paste de artículos como este:

http://es.wikipedia.org/wiki/Cliente-ser...ulti-capas

Quoteando un poco:
" Ventajas de las arquitecturas n-capas:
- La ventaja fundamental de una arquitectura n-capas comparado con una arquitectura de dos niveles (o una tres-capas con una de dos niveles) es que separa hacia fuera el proceso, eso ocurre para mejorar el balance la carga en los diversos servidores; es más escalable.

Desventajas de las arquitecturas de la n-capas:
-Pone más carga en la red, debido a una mayor cantidad de tráfico de la red.
- Es mucho más difícil programar y probar el software que en arquitectura de dos niveles porque tienen que comunicarse más dispositivos para terminar la transacción de un usuario."

En definitiva, me da la sensación que no pensaron el apunte en base al desarrollo del software per sé, sino en el desempeño del software dentro de una red y su diseño.
Lo de los errores está muy mal encarado... Si tengo una "arquitectura monolítica" donde no habría una red, obvio me ahorro analizar cualquier problema referido a comunicaciones. Da la sensación que se refieren a eso, pero igual es cualquiera. De mi parte ni lo mencioné en el parcial.

"Un threads es como un proceso pero más liviano"


http://www.campusvirtual.frba.utn.edu.ar...se%202.pdf página 16


no puedo creer que esté estudiando esto, parece una clase de un secundario

Ah, la frase del threads me hizo levantarme e irme. Extrañamente siempre hay una frase así en cada clase.

y yo quiero dar el final la semana que viene hue hue

la ppt de redes es digna de una clase de secundario dictada por los alumnos


http://www.campusvirtual.frba.utn.edu.ar...eA2est.pdf

En esta materia, las frases clave son "no esta en el alcance de la materia, no vamos a entrar en detalle" y "lo van a ver (o ya lo vieron) en otra materia".
Con esas 2 frases como bandera, no te enseñan un carajo.

En qué quedó todo esto? Algunos usuarios iban a convalidar su experiencia con la materia a fin de año pasado