| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

2011-07-buenos-aires-temas

Page history last edited by Martin Rabaglia (R/GA) 9 years, 2 months ago Saved with comment

Para proponer un tema para la reunión escriba un título y su nombre, y una descripción entre 5 y 10 líneas.

 

Recuerde que puede proponer temas:

 

  • en los que se considera muy calificado o experto, para presentar
  • en los que tiene algo de experiencia, para discutir con colegas
  • en los que tiene interés pero poco conocimiento o muchas dudas, para pedir orientación de otros con más experiencia

 


¿titulo aqui? (Carlos Peix, autor aquí)

[breve descripcion aqui] Ultimamente surgio un hilo en la lista de discusion de Arquitectura del MUG de Argentina sobre opciones para la generacion mas o menos automatizada de interfaz a usuario. Las opciones discutidas son Generacion de código y su compilacion, generacion de la UI en runtime, etc. 


Leguajes estáticos vs lenguajes dinámicos. (Alejandro Miralles)

Los lenguajes dinámicos, son realmente más productivos que los lenguajes estáticos?

Sacando la etapa de codificación inicial (donde los lenguajes como Python o Ruby suelen ofrecer ventajas sobre C#), es conveniente utilizar este tipo de lenguajes, en que proyectos aplican, cuando no deberíamos utilizarlos (si la decisión es nuestra).

En algún momento los lenguajes dinámicos dejan de ser “cool” y comienzan a tener un efecto negativo en el ciclo de desarrollo? (Por ejemplo: equipos muy grandes, poco soporte para tooling, refactoring, etc).

Es posible combinar lo mejor de los dos mundos en ambientes productivos, utilizando por ejemplo IronPython? ó es un lenguaje que solo aplica para escenarios de demo y presentaciones.


CQRS: eventos y comandos de dominio, y tiro mi ORM y API RESTful a la basura? (Daniel Cazzulino)

Eventos y comandos de dominio son los pilares de CQRS (Command Query Responsibility Segregation), pero parecen ser totalmente incompatibles con la metodologia arraigada de disenio tradicional de objetos de dominio con estado (persistido tipicamente con un ORM) y comportamiento. Parece ser un todo o nada, un cambio radical de paradigma para los que estamos acostumbrados a lo "clasico". Las ventajas de CQRS en cuando a un log de eventos significativo y semantico del dominio ("ClienteCreado", "ProductoComprado", "EmailCambiado", "ProductoCalificado", etc.) sumado a la posibilidad de reproducir el estado completo del sistema a un momento del tiempo (por ej. llevar al sistema completo al estado en q estaba al momento de evidenciarse un bug) son demasiado tentadoras, pero su propuesta radical con relacion a la (no) persistencia de estado de entidades parece en principio escalofriante.

 

Hay alguna forma de armonizarlos? Existe una progresion donde pueda ir de a poco "comprando" los beneficios de CQRS sin tirar mi ORM? Como compatibilizo mis APIs RESTful que son orientadas a ABM con la propuesta orientada a comandos de CQRS?

Sin respuesta certera a ninguna de estas preguntas, estaria bueno discutir los pro/cons aparentes/reales de cada una...


Continuando con un tema que planteó Martín Salías en el último Alt.NET (Que estamos aprendiendo de Ruby?) (Alejandro Miralles)

Se me ocurre que estaría bueno evaluar la siguiente expresión:

ASP.MVC + NuGet + NHibernate (o EF) + NMigrations + Log4Net == Ruby on Rails;

No conozco demasiado RoR, pero se probablemente muchos de los asistentes sí y se puede llegar a armar algún debate sobre este tema y probablemente contestar la pregunta que planteaba Martín “Es importante o no aprender Ruby para la gente de .NET?


 

NoSQL (José F. Romaniello)

Espacio para compartir experiencias (malas o buenas) que han tenido utilizando bases de datos nosql, (mongodb, ravendb, redis, couchdb..etc). Me interesa puntualmente los desafíos que hayan aparecido tanto técnicos y no técnicos. También su opinión acerca del estado actual de las librerías clientes en .Net, tooling y demás.


UnitTesting (José F. Romaniello)

Todavía es un desafío? o cambio algo en este último tiempo?... Buenas o malas experiencias, dificultades y desafíos técnicos y no técnicos. Qué podemos mejorar en nuestras organizaciones?


¿Qué estamos aprendiendo de los lenguajes funcionales? (Mauricio Scheffer)

El paradigma funcional está cada vez más presente en la programación .NET de todos los días. Cómo se relacionan cosas como LINQ y Rx con el paradigma funcional? Qué son las mónadas? Cómo se pueden usar en .NET? Qué ventajas o diferencias tiene F# sobre C#/VB.NET? Cómo se programa en un mundo inmutable, qué ventajas tiene? Cómo se combinan OOP y FP? Qué dificultades presenta esto?

 


.NET en el desarrollo de App para Smatphones (Carlos Rodrigo)

La idea es básicamente compartir experiencias sobre el desarrollo de aplicaciones para Smartphones utilizando la plataforma .NET, ya sean dispositivos con Windows Phone 7, Android, o iOS. Para los últimos dos utilizando MonoTouch y MonoAndroid. Debatir sobre el futuro de este tipo de desarrollo en el mercado actual, las oportunidades, y como se complementa con Azure. Tengo poca/nula experiencia, pero es un tema que me parece interesante y que se puede explotar con mas profundidad. 

 


Azure Oriented Architectures (Martin N. Rabaglia)

Le objetivo del espacio es compartir experiencia sobre arquitecturas orientadas a Azure. Por que se han decidido a utilizar cloud?

Que dificultades les trajo implementar Azure en proyectos?  Cual es la curva de aprendizaje para los desarrolladores? En que cambia el enfoque clasico de persistencia? Que herramientas existen para monitoreo y parametrizacion? Que se tiene que tener en cuenta al diseñar infrestructuras orientadas a Azure? Ejemplos de proyectos exitosos y proyectos sobrestimados.

 

 

 

 

 

 

 

Comments (0)

You don't have permission to comment on this page.