NHibernate esta muerto?

[Elio R. Batista Gonzalez]

 Hola gente, en mi oficina estamos a punto de comenzar un nuevo proyecto, uno grande, y tenemos que elegir entre NHibernate y EF. Por supuesto que al ser yo fan de Nhibernate mi inclinacion es por este. No obstante he notado que su desarrollo NHibernate se ha desacelerado a un punto que me preocupa su futuro y el impacto del desarrollo en este y futuros proyectos.

Que opinan ustedes?

Gracias

Elio

[José F. Romaniello]

En mi humilde opinión el desarrollo en .net se viene desacelerando desde cerca de 2009. Sin embargo no debería preocupar ya que ambos proyectos EF y NH son de código abierto

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/FB874IdA1asJ.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

[Erick Orlando]

De donde sacan que .net ya está desacelerando desde el 2009?

Seguro todavia usas XP jeje.

[Elio R. Batista Gonzalez]

Hola Jose que tal? Te refieres a los proyectos en .NET de código
abierto tales como NHibernate? He notado el mismo comportamiento en
otros como Castle. O te refieres a la plataforma .NET como
herramienta de desarrollo?

Eirc sin duda Jose sabe lo que esta hablando,el hombre ha sido unos de
los buenos contribuyentes a varios de estos proyectos que yo
personalmente he usado con éxito hasta ahora.]\

slds


El día 23 de diciembre de 2012 15:41, Erick Orlando
<orland...@gmail.com> escribió:

> De donde sacan que .net ya está desacelerando desde el 2009?
>
> Seguro todavia usas XP jeje.
>

> --
> Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

> Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/_MkJHg0DhXYJ.

[Fabio Maulo]

Viste cuando dicen "es un proyecto maduro" ?
Bueno... es como cuando un hombre llega a los 60-70, no es que va tan acelerado a los boliches cazando chicas.

NH se sigue desarrollando en cuanto a mejoría de alguna funcionalidades aprovechando .NET4.5 pero mas que eso que queres que haga? al fin y al cabo es un ORM... tampoco le pida que cabecee

[Elio R. Batista Gonzalez]

cabecear!! jejeje seria muy bueno eso Fabio.
Broma aparte, copiado alto y claro, si lo dices tu me basta con eso.
slds

El día 23 de diciembre de 2012 17:25, Fabio Maulo
<fabio...@gmail.com> escribió:

> Viste cuando dicen "es un proyecto maduro" ?
> Bueno... es como cuando un hombre llega a los 60-70, no es que va tan acelerado a los boliches cazando chicas.
>
> NH se sigue desarrollando en cuanto a mejoría de alguna funcionalidades aprovechando .NET4.5 pero mas que eso que queres que haga? al fin y al cabo es un ORM... tampoco le pida que cabecee
>

> --
> Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

> Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/mSeWRHzfNaMJ.

[Daniel Cazzulino]

Si quieren revitalizar .NET, tienen q comprar Xamarin y dejarse de boludear con Windows only. Casualmente, creo q tb es la única chance de q tengan más apps para win8 y q no sea un fracaso por 1+ años como hasta ahora... 

El domingo, 23 de diciembre de 2012, Elio R. Batista Gonzalez escribió:

--
/from mobile



--
/from mobile

[Angel Java Lopez]

Agrego algo, hay bastante actividad en

https://github.com/nhibernate/nhibernate-core/commits/master

no digamos, "uy, que bruto... que actividad" ;-)

Pero vean la cantidad de commits, y hay varios forks, no se cuanto contribuyeron con pull request, hay varios pull

https://github.com/nhibernate/nhibernate-core/pulls

Angel "Java" Lopez

@ajlopez

gh:ajlopez

[Mauricio Scheffer]

Posteé mi respuesta en https://groups.google.com/d/topic/nhusers/k9i15VRrKUs/discussion

Saludos

[Elio R. Batista Gonzalez]

Mi preocupación inicial vino precisamente de los análisis de Ohloh y no solo por NHibernate sino por otros proyectos que he estado usando com Castle o LinkFu , pero estoy de acuerdo con el punto que expones en nhusers. 

slds

[Miguel Madero]

>el desarrollo en .net se viene desacelerando desde cerca de 2009.

En general concuerdo con esto, aunqe justamente EF (entre otros pocos) han tenido un aceleramiento interesante en los ultimos meses. Esto gracias a una nueva actitud de parte de MS y por otro lado porque al proyecto le faltaba mucho. 

Miguel

2012/12/23 Elio R. Batista Gonzalez <elio...@gmail.com>

[José F. Romaniello]

hola Elio, me refiero al uso de .net en general. Aclare que era una apreciación persona, aunque creo que no soy el único que ha notado una especie de éxodo hacia otras tecnologías. De todas formas .net sigue siendo fuerte en varias areas muy importantes (enterprise, aplicaciones de escritorio windows, aplicaciones para telefonos ms).

[Elio R. Batista Gonzalez]

Jose interesante ese dato que ofreces. Yo personalmente no he notado este fenómeno, quizás debe ser que trabajo exclusivamente sobre .net desde hace ya varios años y a penas he dispuesto de tiempo suficiente para evaluar otras herramientas.
De todas formas como la curiosidad me come en estos momentos, si no te estoy pidiendo mucho podrías mencionar algunas de estas tecnologías alternativas? 

[Angel Java Lopez]

node.js

2012/12/23 Elio R. Batista Gonzalez <elio...@gmail.com>

[Matias Molinas]

Creo que Daniel Cazzulino tiene razon, que Microsoft deberia comprar Xamarin y dejar de ser Windows Only para permitir programar para Android y iOS en  .net

Por el momento los lideres en las plataformas moviles son Android y iOS y entonces cuando hay que desarrollar una aplicacion para moviles, cada ves mas hoy en dia.., la unica opcion para programar en .net es Xamarin. Al no tener el respaldo de un grande como Microsoft muchas veces se termina optando por programar en los lenguajes que soportan oficialmente cada una de estas plataformas, y se termina abandonando en estos casos .net como plataforma de desarrollo.

Otro motivo es el que bien sugiere el maestro Angel Java Lopez,  la aparición de nuevas alternativas muy potentes, como node.js, que para determinadas aplicaciones son mejores que la plataforma .net

Respondiendo a la pregunta inicial, yo optaria por EF, por que entiendo que como es un producto/proyecto de Microsoft, este deberia darle soporte y asegurarse que todos aquellos que confiamos en la plataforma .net en distintos desarrollos vamos a tener respaldo de su parte. Creo que ademas las herramientas de VS para EF mejoran la productividad respecto a NHibernate.

Saludos

2012/12/23 Angel Java Lopez <ajlop...@gmail.com>

[Oscar Zárate]

Muy interesante la opinion de Matias. Creo que comparto 100% en los 3 puntos.

2012/12/24 Matias Molinas <matias....@gmail.com>

[Elio R. Batista Gonzalez]

Angel Java Lopez, gracias por el dato

Pues si, seria bueno que se pudiera programar para plataformas Android y iOS usando .net, para mi personalmente seria ideal.

Con respecto a usar EF sobre NHibernate, ahi no estoy 100% de acuerdo, mi experiencia es que la facilidad inicial que da de crear el modelo de forma rapida a partir de la base de datos se ve eclipsada posteriormente. Cierto que ahora con EF ya se puede diseñar primero el modelo pero aun no he tenido la oportunidad de evaluarlo.

slds

[José F. Romaniello]

na jajaj, fijate el nombre de la lista a la que estas posteando :)

El 23 de diciembre de 2012 15:41, Erick Orlando <orland...@gmail.com> escribió:

De donde sacan que .net ya está desacelerando desde el 2009?

Seguro todavia usas XP jeje.

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/_MkJHg0DhXYJ.

[Elio R. Batista Gonzalez]

je ok ok, no hay problemas

El día 23 de diciembre de 2012 20:19, José F. Romaniello
<jfroma...@gmail.com> escribió:

[Angel Java Lopez]

Hola gente!

Elio, voy a escribir lo que cada dia escribo, es mas fuerte que yo (a pesar que se aleja de todo este thread):

Sea lo que sea en lo que programen, si es codigo de produccion, usen TDD ;-)

Siguiendo ese camino, yo por lo menos no plantearia el tema base de datos, hasta avanzado el desarrollo y desplegado y entendido algun caso de uso.

Yo diria mas: la base de datos es el boson de Higgs en el desarrollo agil, iterativo. Ni bien aparece, le da masa inercial y friccion a cualquier cosa que hagamos... ;-)

El bueno de Uncle Bob tiene un post, citado con mas contexto en

http://msmvps.com/blogs/lopez/archive/2012/07/04/tdd-y-casos-de-uso.aspx

Angel "TddRocks" Lopez

2012/12/23 Elio R. Batista Gonzalez <elio...@gmail.com>

Angel Java Lopez, gracias por el dato

[José F. Romaniello]

Elio, estaba contestandole a Erik Orlando :)

[Elio R. Batista Gonzalez]

Hola Mauricio, bueno para esclarecer las cosas tendría que explicar el origen de todo y el porqué de mi pregunta. Me encetaría haber podido participar más en muchos de estos proyectos de código  abiertos y contribuir con ellos, pero lamentablemente el país donde vivía hasta hace 4 meses internet no era algo que estuviera muy fácil de tener, a penas con fuertes restricciones y conexiones muy limitadas y un poco de susto también  por tanto nos es imposible a los de allá poder aportar mucho por más que queramos, apneas podemos estar siempre actualizados, este país es Cuba. Hace 4 meses pude salir hacia Paraguay donde estoy viviendo actualmente. Entonces ahora me estoy poniendo los guantes y quiero actualizarme con todo para empezar a hacer trabajos, lo primero que hice fue revisar las estadísticas de estos proyectos en Ohloh , principalmente en el de NHibernate.  Actualmente si estoy en condiciones y disposición de colaborar con el proyecto que se necesite.

Un saludo

El domingo, 23 de diciembre de 2012 19:07:51 UTC-3, Mauricio Scheffer escribió:

[Elio R. Batista Gonzalez]

ahh ya, ok

slds

[Oscar Zárate]

Elio,

 

Siguiendo lo que decis, antes de poner tu voto para uno u otro (y sin olvidar lo que dice el maestro Lopez) deberias actualizar tus conocimientos de ambas herramientas. Ha pasado mucha agua bajo el puente de EF (no solo Code First, al fin y al cabo ya hay una version 6 por algunos lados).

 

Aprovechando que esta lista hay gente que conoce tanto de EF y NHibernate, podriamos hacer una buena explicacion de lo bueno y lo malo de cada una? (yo tengo mucho para aprender de NHibernet).

 

SaludOZ,

 

2012/12/24 Elio R. Batista Gonzalez <elio...@gmail.com>

Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/c4F5kX92SgQJ.

[Mauricio Scheffer]

En ese caso bienvenido al mundo del desarrollo open source! Nunca dudes en preguntar o meter mano cuando haya que meter mano :-)

Saludos,

Mauricio

[Miguel Madero]

Angel, 

Comparto el sentimiento de usar TDD. Sin embargo, creo que lo que sugieres podria confundir a algunos. Si entendí bien, estas sugiriendo que de usar TDD significa postponer el uso de una base de datos? Y sugieres hacer esto hasta avanzado el proyecto?

Aunque entiendo que esto sería tecnicamente posible, yo consideraría:

• Que mi definición de DONE cubra esto
• Trabajar en slices verticales y no horizontales (capa de negocios o front end)
• Poner algo en producción tan pronto como sea posible (una o dos semanas idealmente)
• En los sprint reviews mostrar algo funcionando end to end. 

Debería tener un muy buen motivo para postponer esta decisión. Sin miedo a equivocarme, y vaya que lo he hecho, podría cambiar de DB o DAL de ser necesario, pero empezaría con algo. 

Miguel

2012/12/23 Angel Java Lopez <ajlop...@gmail.com>

Hola gente!

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

[Angel Java Lopez]

Aca, en mi disco, tengo un repo de un sistema que tienen 20 semanas de vida, con demostraciones a distancia y en vivo, en tres continentes. Y tengo otro, con cinco meses sin bases de datos.

Insisto, les remito al post de Uncle Bob citado en el enlace que envie.

Como dices, depende del DONE. Pero muchas veces, el DONE no implica base de datos, sino cumplir con uno o varios caso de usos.

Eso es lo importante: el caso de uso. Veo muchas veces ir definiendo la base de datos desde el principio. IMNSHO, es una violacion de YAGNI.

Insisto de nuevo, leer el post de Uncle Bob ya citado.

Tengo otro caso por aca cerca: un caso donde se puso base de datos relacional desde el principio. Eso "infecto" el sistema. Hoy se puede ver que bien podria ser satisfecho todo caso de uso con NoSQL en memoria, o algo similar (un key-value store en memoria distribuida, por ejemplo). Pero como se inyecto base de datos desde el principio, ya comenzo "torcido". Y ahora es dificil refactorizar para lo que seria una solucion mas flexible.

Eso es lo que nos da "agile", en contraste con "waterfall". El poder diferir la decision, sin incurrir en costos crecientes o exponenciales.

Sugiero lo de "avanzado el proyecto" porque tengo proyectos asi, no es algo dicho en el aire ;-)

Angel "Java" Lopez

@ajlopez

gh:ajlopez

2012/12/23 Miguel Madero <m...@miguelmadero.com>

[Oscar Zárate]

Que interesante se puso esta charla, será por que estamos cerca de fin de año? :-)

 

Comparto 100% con ambos (Angel y Miguel, loco, pero es cierto) y el secreto está en la definición de "HECHO" (done).

Creo que Angel (sobre todo citando a Uncle Bob y me animo a agregar a Evans) está pensando en el dominio primero (o me equivoco Angel?).

 

El tema es, hacé andar el sistema y mostralo andando a como de lugar, incluso guardando los datos en un archivo XML o TXT. Cuando sea el momento adecuado lo persistís donde haga falta pero eso va del repositorio para abajo y no para arriba.

 

SaludOZ,

 

PS: Maestro, algo que difiero (no se si es un problema de traducción) es que yo incluyo varios "historías de usuarios" y no "casos de usos" (User Stories not User Cases).

2012/12/24 Angel Java Lopez <ajlop...@gmail.com>

[Miguel Madero]

Angel, 

Como te decía se que tecnicamente es posible. Yo tambien lo he hecho en prototipos, MVPs o en algunos casos cuando usamos lo que llamo DemoDrivenDevelopment (otro DDD). Entiendo que el introducir la base de datos agrega fricciones, pero este es un precio que eventualmente tendremos que pagar. Creo yo que hay un punto en el que confiadamente podemos tomar una decisión y el no tomarla incrementara el riesgo a futuro. 

El enfoque también depende de que estas desarrollando. Si estás pensando en que tienen que presentar una demo el siguiente viernes, no, no necesitas persistir nada. Si estás pensando en que tienes que poner un SW en producción el siguiente viernes, entonces el enfoque cambia. Yo trato de evitar caer en el patrón de DemoDrivenDevelopment. Si es un prototipo, va, aunque espero no dure 20 semanas. Inclusive para un MVP (Minimum Viable Product), es tan sencillo tirar los datos en MongoDB, SQL Server o archivos XML o una cookie que porque no hacerlo y cambiarlo despues de ser necesario? A fin de cuentas todos estos son metodos de persistencia. 

Cheque el artículo. Hay algunas cosas interesantes y otras con las que no concuerdo al 100%

You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.

All es una palabra muy fuerte. Yo la cambiaría por ENOUGH. 

A good architecture allows you to defer framework decisions. 

Tambien una buena arquitectura te permite tomar decisiones y cambiarlas mas adelante si no eran las correctas. No te digo que tomes las decisiones el primer día, pero cuando tengas ENOUGH use cases, es más probable que tomes las decisiones correcta disminuyendo los riesgos de postponerlas.

Tambien mencionas en el artículo el porque no entregar un DER. Esto es diferente a usar una BD. Yo no estoy sugiriendo el tener un ER completo, mucho menos en la primer iteración. Actualmente es fácil  evolucionar y refactorizar bases de datos, SQL o NoSQL. 

Concuerdo contigo que una base de datos relacional no siempre es la mejor opción. Un amigo, Paul Stovell, desarrollo Octopus, una herrmienta que ayuda con el deployment. El empezo con SQL Server, libero un beta, obtuvo valioso feedback que lo llevo a cambiar a RavenDB antes de su RC. Como el dice, quería que jalara lo suficientemente bien para obtener feedback

When I started building Octopus Deploy, I wanted to build something that worked well enough to release a beta and start getting feedback

De acuerdo a lo que dices el podría haber hecho todo con TDD, diferir la decisión y darse cuenta de que RavenDB era mejor opción. Bueno, no en este caso. Fue del feedback del primer beta de donde sugieron ideas nuevas que requerían del uso de NoSQL. Sin SQL Server, no hubiera habido primer beta. TDD te da cierto feedback, tener algo jalando end to end, te da el feedback real.

I was getting great feedback and suggestions, and had a lot of feature ideas. But I noticed myself making feature trade-offs based on how complicated they'd make the database

Es posible que si el hubiera tenido más experiencia con NoSQL el hubiera escogido RavanDB desde un principio, pero de cualquier forma dudo que el hubiera tratado de desarrollar ALL the use cases sin solucionar la persistencia. 

>Eso es lo que nos da "agile", en contraste con "waterfall". El poder diferir la decision, sin incurrir en costos crecientes o exponenciales.

Alguien dijo la palabra con W? 

Que pasara cuando eventualmente, despues de 20+ semanas el sistema este en producción o que pasaría si no se trata de un proyecto greenfield. Ese no sea el fin del desarrollo agile e iterativo. Como mencionaba antes las bases de datos pueden y deben tener un desarrollo evolutivo a la par con el codigo. Aunque la mayoría de las veces será lo último que hagamos de un caso de uso o historia de usuario, sin duda es algo necesario antes de presionar el botón de deployment al final de la iteración. 

Uno de los principios de Lean es mantener el Batch Size tan pequeño como sea posible. Si esperamos a tener muchas User Stories antes de poder hacer una actualización a producción, tendremos un batch size enorme. 

Interesante discusión :) 

Saludos,

Miguel

2012/12/23 Angel Java Lopez <ajlop...@gmail.com>

Aca, en mi disco, tengo un repo de un sistema que tienen 20 semanas de vida, con demostraciones a distancia y en vivo, en tres continentes. Y tengo otro, con cinco meses sin bases de datos.

[Elio R. Batista Gonzalez]

Excelente post este que referencias Angel, lo he leído de punta a cabo, yo soy un gran fan a TDD y todos los proyectos que he empezado desde cero lo he hecho usando TDD con NUnit y Rhino Mocks,no se si este ultimo se mantiene aun activo tengo que actualizarme con este también, el caso es q yo he podido comprobar que es muy saludable diferir el uso de base de datos hasta tanto no sea necesario y mi experiencia es que durante el proceso de desarrollo casi nunca lo es, es mas útil en todo caso enriquecer las clases del dominio con comportamientos y reglas de negocios que sean independientes de la base de datos y de frameworks, de esta forma evitamos arrinconarnos en una esquina con nuestro propio código.

slds

[Elio R. Batista Gonzalez]

Hola  Oscar, de acuerdo estoy recopilando informacion y preparabndo algunos test para hacerme de mi propio criterio, noobstante seria util si alguin expone su experiencia personal

slds

[Elio R. Batista Gonzalez]

Empezar con algo la mayoría de las veces equivale a amarrarnos a ese algo, dedicarle tiempo a implementar la DB desde le mismo comienzo es tiempo que le dejamos de dedicar a nuestro modelo. Claro esta, esto depende de la intención q tengamos y el alcance y complejidad  de nuestro proyecto,  si es que se quiere implementar DDD yo opto pro retrazar tanto como sea posible la implementacion de la base de datos

slds

[Miguel Madero]

Yo no hablo de empezar con la base de datos, mi preferncia sería diferir cualquier metodo de persistencia lo mas posible. Por otro lado tambien es mi preferencia liberar software lo ante posible. Liberar SW generalmente implica tener un mercanismo de persistencia. Si tengo que escoger, prefiero liberar SW en lugar de seguir postponiendo el uso de algun mecanismo de persistencia. 

Vamos a obtener feedback mucho más valioso de usuarios usando nuestro SW que de un modelo muy completo que nadie pueda usar. 

Por cierto, cuando dices 'implementar' una base de datos suena como algo complejo. Serializar objetos en XML, guardar un documento en Mongo o usar NH con Fluent y persistirlos en SQL Server es, creo yo, algo tan sencillo que no considero que no hacerlo valga la pena. 

Miguel

2012/12/24 Elio R. Batista Gonzalez <elio...@gmail.com>

Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/Jbw4_vKf0-cJ.

[Angel Java Lopez]

Bueno, en los proyectos que expuse, se entrego sin persistencia, Y se consiguio feedback de los usuarios. El modelo se mantiene en memoria, con un set inicial, y todos los interesados estan avisados.

Aclaro esto, porque justamente, el tema de entregar sin persistencia fue lo que posibilito tener feedback mas rapido, y cambios agiles. Luego, pueden o no adoptar ese "approach". Pero desde aca senialo: ha sido perfectamente posible ese camino.

Creo que la diferencia, es que implica en cada proyecto "liberar". En los casos que expuse, fue exponer a los usuarios para conseguir feedback (y ahi no se necesito persistencia). El servidor pueden estar prendido por dias, y si hay algun recicle, el dominio inicial se recarga, y es lo suficientemente rico para esa iteracion. Si alguna vez se necesitara persistencia, podemos pasar a base de datos, pero seguro que yo intentaria primero algo mas liviano, como simplemente serializar el dominio.

Si alguna vez/iteracion se necesita SI o SI base de datos (con justificacion), hasta se puede hacer de a partes. Al final, termina habiendo un sistema con DOS implementaciones internas (elegibles, por ejemplo, por configuracion), de persistencia, a una base de datos y "en memoria". Eventualmente, podria tener una intermedia, "en memoria" compartida entre varias maquinas, usando un key-value store por ejemplo.

Jejeje.... yo llego al extremo de:

http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx

pero lo hago para llamar la atencion sobre un punto que se nos pasa, para pensar "out of the box". Hoy, estamos tan ligados a bases de datos (y aun relacionales) que hay que llamar la atencion sobre para que sirven, y que es persistencia y por que se necesita. Vean, por ejemplo, como lo ha resuelto la gente de Smalltalk, y luego, la gente de GemStone.

Todo lo que describi mas arriba va surgiendo por "baby steps", haciendo TDD. Sino, se complica. El tener TDD y "baby steps" va haciendo que todo vaya creciendo organicamente, que no se le agregue "de golpe" demasiado, y que todo este listo para un refactor sin dolor, y luchar para no agregar algo ahora "porque lo vamos a necesitar despues", no abandonar YAGNI. Por eso me referia a el costo de la decision. Debe ser Kent Beck el que lo describe en uno de sus libros. Agile nos da eso: decidir X hoy o dentro de cuatro semanas, es casi lo mismo. Nombre a "waterfall" porque se basaba en algo distinto, tenia su rationale, pero era este: decidir X hoy es MUCHO menos costoso que dentro de cuatro semanas o meses. Ese "rationale" nace en el medio de la guerra fria, inspirado por manejo de proyectos como la construccion del Polaris. 

Justamente Agile, soportado con disciplinas como XP y TDD, permite socavar ese supuesto. Y adoptar el cambio, sin que duela.

Jeje... como ven, el tema me interesa, espero que no se esten aburriendo ;-)

Vuelvo ahora, a programar con TDD, JavaScript y Node.js, y a luchar por mi desayuno....

Ah! Me olvidaba, para aportar algo a Elio, sobre otras tecnologias, fijate que el bueno de @jfroma (con @woloski y @retrofox) publico sobre Node.js:

http://es.joseoncode.com/post/35272597285/un-tutorial-de-node-js-en-castellano-y-en-github

Nos leemos!

Angel "LookMaNoDatabase" Lopez ;-)

@ajlopez

github:ajlopez

2012/12/24 Miguel Madero <m...@miguelmadero.com>

[Cristian Prieto]

Quizas me estoy alejando del punto principal, pero he leido muchos comentarios como: .NET no es lo "inn" en estos dias... 

No tengo mucho tiempo en esta profesion, son nuevo debo admitirlo (solo un poco mas de 13 anios, quizas 14 en esto) y BASTANTE nuevo en .NET (solo desde .NET 2.0, asi que no soy alguien que pueda hablar con tanta propiedad)... Pero luego de muchos lenguajes, frameworks, plataformas, sistemas operativos puedo decir algo...

Todo es moda, Ruby desplazo .NET?... no se, quizas en ciertas esferas... Python desplazo .NET? me hubiera gustado en serio... Haskell y lenguajes funcionales lo hicieron? no :( 

Bueno, el nuevo kid on the block es JS y Node.JS...

Con esto no digo que .NET va a morir o que Node.JS sea moda (no soy disenador ni hipster ni conocedor de arte para saber de modas), todo lo contrario, creo que lo que esta sucediendo es que como carrera estamos "madurando" y hemos aprendido (o esperaria que asi fuera) que cada cosa tiene su lugar.

Bases de datos SQL? NoSQL? bueno, revisen la historia y veran que NoSQL existio antes de lo relacional y solo esta regresando... La razon por la que _personalmente_ me gusta NHibernate es simple, la persistencia es solo una desicion del proceso, el que lo hagas en un disco o en un motor de base de datos DEBE ser algo que no afecte inmediatamente el proceso. Claro, hay casos en que esto es inevitable (por ejemplo, tu cliente quiere de huevo a pelotas que sea SQL Server, que puedes hacer? eres consultor, hazle huevos, recuerda, puedes sugerir como consultor, no exigir).

No se si en su pais tienen el mismo dicho pero yo lo aprendi en Guatemala: "El perico es verde donde sea"... Si eres buen dev, TODO lo demas es una tool... Y acerca de NHibernate y que no es mantenido, bueno, lo mismo digo con Java y aun veo TANTOS programadores de Java y tantas cosas hechas en JAVA que me asusta... (Y si, ese tambien es un buen ejemplo, aunque Scala es popular pasara mucho tiempo, si es que pasa, que Scala o Clojure sean un lenguaje de preferencia para la JVM).

Mi grano de arena.

Cristian Prieto

2012/12/24 Miguel Madero <m...@miguelmadero.com>

[Vicenç Garcia]

En esta charla de la NDC tío bob habla de algo parecido al amigo Angel http://vimeo.com/43612849

Salut!

2012/12/24 Angel Java Lopez <ajlop...@gmail.com>

Bueno, en los proyectos que expuse, se entrego sin persistencia, Y se consiguio feedback de los usuarios. El modelo se mantiene en memoria, con un set inicial, y todos los interesados estan avisados.

--
Vicenç García
http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

[Angel Java Lopez]

Jaja! Vieja, pone los fideos, que estamos todos, @cprieto is in! ;-)

Muy bueno lo del perico, yo tengo:

"La mejor arma es una mente despierta" Rambo II

"La mejor herramienta es una mente despierta" ajlopez I ;-)

Algun comentario para volver a algo del tema inicial. Donde brilla NHibernate y similares? en el manejo de las relaciones, y lo lazy.

@cprieto menciona la sencillez. Justamente, surgieron los micro ORM, en .NET tenemos drapper. Ahi, el mapeo simple de relacional y objetos esta bien resuelto. En el proyecto al que me sume hace dos semanas, lo usan, y parece bastante simple, sin fricciones, pero hablo solamente con esa experiencia. Hasta donde vi, no maneja lo lazy.

Con respecto a Node.js, tiene pilares:

- El excelente engine V8 de Google

- Un muy bien resuelto tema de paquetes de NPM (con versionado, download, y manejo de dependencias, y hasta manejo de dependencias y carga por modulo, es decir, si dentro de una aplicacion, modulo X necesita Z.1, y modulo X necesita Z.2 (dos versiones distintas de Z), no hay problema, cada uno tiene en sus dependencias lo que necesita; algo que no he visto ni en Python, ni en Ruby Gems, ni en NuGet, ni en los .war/.jar de Java).

- Lo que ha llevado ha conseguido lograr un ecosistema notable de paquetes, muchos livianos

- JavaScript, que es una "manteca" de tan flexible... Me recuerda a la cancion "You are beatiful, you are sixteen, and you are mine... " ;-)... Ya cada vez necesito menos AjBasic y AjSharp (pero bueno, son mis hijitos... que no se enteren... ;-)

Angel "RambitoYRambon" Lopez ;-)

2012/12/24 Cristian Prieto <keme...@gmail.com>

[Miguel Madero]

Cuando me refiero a liberar me refiero a poner en producción, llamenle beta o pruebas piloto o producción. Mostrar a algunos usuarios para conseguir feedback me suena más como un demo que como liberar el sistema. Si liberara un sistema sin ningún mecanismo de persistencia me imagino que el feedback que recibire de los usuarios será "hagan algo para no perder mis datos". 

Miguel

2012/12/24 Angel Java Lopez <ajlop...@gmail.com>

Bueno, en los proyectos que expuse, se entrego sin persistencia, Y se consiguio feedback de los usuarios. El modelo se mantiene en memoria, con un set inicial, y todos los interesados estan avisados.

[Carlos Peix]

Hola,

No estoy en condiciones de hacer un paralelo como el que hizo Jose hace un tiempo, pero en mi trabajo de consultor (que es menos comprometido que el de miembro de equipo), aun encuentro que EF (5.x) no tiene algunas cosas que NH tiene desde años. Seguramente va a alcanzar esas caracteristicas en algun punto del proximo año o dos. Por ejemplo en queries o esto, que es algo que a estas alturas daba por sentado (EF aun no tiene el "all-delete-orphan" de NH).

Por otro lado, aun no he visto uso de las herramientas visuales de EF dentro de Visual Studio que mejore la productividad a largo plazo. *Siempre* que he logrado que el equipo se mueva a Codo First, logran mas productividad (mayormente debido a la mayor flexibilidad). Es posible que esto se deba a entornos particulares en los que he estado y que no sea una norma, pero es mi experiencia.

Un saludo

----------------------------------
Carlos Peix

2012/12/23 Oscar Zárate <oscar....@gmail.com>

[Cristian Prieto]

Puff, mejor no enumeremos lo que no tiene EF que acostumbraba a usar en NH, me da caries...

+1 con que en quizas uno o dos anios (quizas la EF7) ofrezca muchas cosas, en mi trabajo diario con la EF me costo adaptarme, y aun me cuesta, pero para proyectos 'sencillos' el code first me ha servido... Claro, al final siempre termino haciendo un monton de malabares para emular muchas cosas (como los eventos de NH) en la EF... Pero son gajes del oficio...

Cristian Prieto

2012/12/24 Carlos Peix <carlo...@gmail.com>

[cibrax]

Creo que Microsoft tiene una politica de soportar cada cosa que hacen al menos unos 5 anios o mas, con lo cual, mucha gente utiliza los frameworks de MS vs Open Source por eso respaldo implicito que existe. El que metio la pata fue Sinofsky cuando dijo que .NET estaba muerto cuando presento Win8, y luego tuvo que salir a desmentir sus dichos. Lo de comprar Xamarin en mi humilde opinion, no tiene mucho sentido, y es lo que vengo escuchando desde que esta Mono, a Microsoft no le interesa nada mas que vender licencias de sus productos, y .NET es solo una herramienta hacia ese objetivo, que la gente desarrolle en productos para la adopcion de Windows. No creo que le interese Android o iOS en absoluto salvo para vender sus cosas ahi tambien.Por ahi me equivoco con esto, pero es lo que vengo viendo desde siempre.

Saludos

Pablo.    

[Carlos Peix]

Soporte durante 5 años: ese es el problema y no la ventaja, en mi opinion (aunque a veces ni siquiera eso se cumple, por ejemplo Linq2sql)

Por eso es una buena noticia que se haya liberado el codigo fuente.

----------------------------------
Carlos Peix

2012/12/24 cibrax <cib...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/Pz0axkETGW0J.

[Esteban Grinberg]

Si, pero quien elige comprar un Windows solo porque es la única plataforma en la que se puede desarrollar en .net o correr un SQL Server?

Generalmente las herramientas de desarrollo son secundarias a la hora de elegir la infraestructura de un proyecto. 

2012/12/24 cibrax <cib...@gmail.com>

--

[Daniel Cazzulino]

Y como van a vender licencias de Windows 8 para tablets cuando la disponibilidad de aplicaciones es inexistente comparativamente? Llevar .NET a otras plataformas significa traer apps al Windows store, así de simple...

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/Pz0axkETGW0J.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

--
/from mobile

[Elio R. Batista Gonzalez]

Bueno esta discusion ha resultado ser muy interesante y productiva,
mas que aclarar la pregunta inicial tiene el bonus de haber convocado
a varios expertos con sus puntos de vistas y conceptos. Ha sido muy
util todo.
Gracias
Elio

El día 24 de diciembre de 2012 15:28, Daniel Cazzulino
<dan...@cazzulino.com> escribió:

[Fabio Maulo]

El mismo respaldo que se le dió a Linq2SQL, por ejemplo, sin ir muy atrás en el tiempo... el Maestro AjL nos podría deleitar un rato largo con tecnología perdidas en el tiempo.

2012/12/23 Matias Molinas <matias....@gmail.com>

Creo que Daniel Cazzulino tiene razon, que Microsoft deberia comprar Xamarin y dejar de ser Windows Only para permitir programar para Android y iOS en  .net

Por el momento los lideres en las plataformas moviles son Android y iOS y entonces cuando hay que desarrollar una aplicacion para moviles, cada ves mas hoy en dia.., la unica opcion para programar en .net es Xamarin. Al no tener el respaldo de un grande como Microsoft muchas veces se termina optando por programar en los lenguajes que soportan oficialmente cada una de estas plataformas, y se termina abandonando en estos casos .net como plataforma de desarrollo.

Otro motivo es el que bien sugiere el maestro Angel Java Lopez,  la aparición de nuevas alternativas muy potentes, como node.js, que para determinadas aplicaciones son mejores que la plataforma .net

Respondiendo a la pregunta inicial, yo optaria por EF, por que entiendo que como es un producto/proyecto de Microsoft, este deberia darle soporte y asegurarse que todos aquellos que confiamos en la plataforma .net en distintos desarrollos vamos a tener respaldo de su parte. Creo que ademas las herramientas de VS para EF mejoran la productividad respecto a NHibernate.

Saludos

2012/12/23 Angel Java Lopez <ajlop...@gmail.com>

node.js

2012/12/23 Elio R. Batista Gonzalez <elio...@gmail.com>

Jose interesante ese dato que ofreces. Yo personalmente no he notado este fenómeno, quizás debe ser que trabajo exclusivamente sobre .net desde hace ya varios años y a penas he dispuesto de tiempo suficiente para evaluar otras herramientas.
De todas formas como la curiosidad me come en estos momentos, si no te estoy pidiendo mucho podrías mencionar algunas de estas tecnologías alternativas? 

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

--
Fabio Maulo

[Angel Java Lopez]

Jajaja! Si, ya comence una serie de posts "Computacion en el Recuerdo" ;-)

2012/12/27 Fabio Maulo <fabio...@gmail.com>

[José F. Romaniello]

también WPF y Silverlight

[Angel Java Lopez]

Yo hace rato que en la suscripcion de MSDN no encuentro Multiplan ni Xenix ;-)

2012/12/27 José F. Romaniello <jfroma...@gmail.com>

también WPF y Silverlight

[Elio R. Batista Gonzalez]

WPF y Silverlight tambien?? mmm bombillo rojo? actualmente estoy
apostando por estas 2 precisamente

El día 27 de diciembre de 2012 18:47, José F. Romaniello
<jfroma...@gmail.com> escribió:

[Eugenio Pace]

Xenix y Multiplan no los encontre, pero si encontre todos los discos del 2001 :-)

y tambien Project 95! 

En serio ahora, la policy de soporte oficial esta aca:

http://support.microsoft.com/lifecycle/ 

Silverlight 5 en particular esta oficialmente soportado (Mainstream) hasta el 2021:

Aca pueden buscar un producto en particular:

http://support.microsoft.com/lifecycle/search 

Saludos

Eugenio

2012/12/27 Elio R. Batista Gonzalez <elio...@gmail.com>

[Oscar Zárate]

José,

Eso es relativo.

Si bien puede ser cierto que en un futuro Silverlight (SL) y Windows Presentation Foundation (WPF) no tengan nuevas versiones no significa que estén muertas. 

Cualquiera que aprendió WPF o SL puede hacer aplicaciones para Windows 8 (Store Applications) y Window Phone 8 (WP8) usando C# ( o incluso Visual Basic y hasta C++, hablando de C++ era otro que estaba muerto según algunos).

Elio, creo que todo esto vuelve a la sentencia del Maestro Lopez, hacé TDD, crea tu sistema desde el modelo y la infraestructura de persistencia o la presentación (User Interface) puede cambiar tantas veces como haga falta.

Ahí está la papa y si logras meter todo eso en una portable class tenes las hilo para rato.

SaludOZ,

PS: Windows Forms está muertisimo sin embargo sigue siendo parte de todas las versiones de Visual Studio ;-)

2012/12/28 José F. Romaniello <jfroma...@gmail.com>

[Esteban Grinberg]

Silverlight en realidad creo que nunca tuvo vida, mas allá de algún desarrollo particular.

De todos modos hay que tener cuidado con "matar" tecnologías, como así también adoptar otras nuevas porque todo el mundo habla de ellas. Hay demasiadas modas en el mundo tecnológico.

Para el caso, todavía se sigue desarrollando bastante en Visual Basic 6, que tiene 15 años (dicho sea de paso, usar la IDE de VB6 en una computadora moderna es una delicia. Es casi tan rápido como el notepad).

Las buenas tecnologías, no mueren. Se extinguen lentamente, que distinto.

2012/12/27 Oscar Zárate <oscar....@gmail.com>

[Angel Java Lopez]

Aguante JavaScript+Node.js+TDD! ;-)

Si hasta sirve para resucitar COBOL ;-)

https://github.com/ajlopez/CobolScript

"Es una manteca, neeeneeee... " (solo entendible por argentinos, creo ;-)

No habra Sidekick para Windows 8?

Recuerdo ahora que habia MS COBOL, y hasta tenian un Lisp, que compraron a un hawaiano, en los ochenta... Si haste el primer MS C compiler era el de Lattice, revamped. Si no fuera por Borland, el Visual Studio seria de comando de linea ;-)

Y yo booteaba Xenix con una docena de diskettes, por lo menos.

"Eramos tan pobres... " (disculpen, de nuevo, algo solo para argentinos ;-)

2012/12/27 Esteban Grinberg <esteban....@gmail.com>

[Oscar Zárate]

Y te acordas de COBOL.Net? Si hasta había MVPs!!! 

2012/12/28 Angel Java Lopez <ajlop...@gmail.com>

[José F. Romaniello]

in-line

El 27 de diciembre de 2012 20:58, Oscar Zárate <oscar....@gmail.com> escribió:

Eso es relativo.

Si bien puede ser cierto que en un futuro Silverlight (SL) y Windows Presentation Foundation (WPF) no tengan nuevas versiones no significa que estén muertas. 

Creo que yo no dije que estuvieran muertas, pero si pienso que estan menos vivas.

 

Cualquiera que aprendió WPF o SL puede hacer aplicaciones para Windows 8 (Store Applications) y Window Phone 8 (WP8) usando C# ( o incluso Visual Basic y hasta C++, hablando de C++ era otro que estaba muerto según algunos).

Cualquiera que aprendió WINFORMS puede hacer Windows Metro, Windows Phone 8 e incluso aplicaciones web. De que me estas hablando? Somos programadores.. si alguien quería aprender una cosa y ganarse la vida con eso se equivoco de profesión, tendría que haber sido cura (cito a Fabio Maulo).

 

Elio, creo que todo esto vuelve a la sentencia del Maestro Lopez, hacé TDD, crea tu sistema desde el modelo y la infraestructura de persistencia o la presentación (User Interface) puede cambiar tantas veces como haga falta.

TDD no te va a salvar si le apuntas a las tecnologías incorrectas. Hay que dedicarle un rato a pensar en eso, la gente trabaja en macs, ipads, tabletas androids, telefonos celulares y también en PCs.. incluso esta esto de BYOD, apuntarle con todo a WPF puede ser peligroso. 

> PS: Windows Forms está muertisimo sin embargo sigue siendo parte de todas las versiones de Visual Studio ;-)

En serio pensas que esta muerto Winforms? Me voy a explayar.. en mi opinión WPF es algo que quedo a mitad de camino y xaml para UIs también, los ejemplos se ven muy bien pero cuando vos queres hacer algo que se vea bien necesitas aprender muchas cosas, no-standard, de las que no mucha gente escribe y a pocos les interesa o contratar un diseñador de XAML que al menos aca escasean y así y todo fabricar componentes basicos que ya existían en winforms. Los componentes de UIs son en su mayoría pagos pero quedaron a mitad de camino y no son tan buenos (en mi expieriencia) como los componentes que hay de winforms. Con DevExpress puede hacer en winforms interfaces metro http://www.devexpress.com/Support/Demos/win-crm-build-it.xml y el databinding que tiene es muy bueno.

[José F. Romaniello]

si, también hay soporte oficial de cobol85 y si no fuera por CobolScript para mi esta medio muerto :P

[Martín Salías]

¿Qué tomaste, OZ? ¿Quién puede haber dicho que C++ estaba muerto?

El mundo corre en C++. Detrás de la chica del vestido rojo, son todos punteros...  8-)

Abrazo,

---
Martín Salías

2012/12/27 Oscar Zárate <oscar....@gmail.com>

[Oscar Zárate]

Me gusta lo de "tendría que haber sido cura" ... aunque ultimamente están cambiando un poco (esto es joda pesada y por ahí no se entiende por email y la verdad que prefiero no aclarar porque oscurece :-) ... como no se entendió que decía que WinForms NO está muerto aunque si menos vivo como decis vos).

Creo que compartimos varios puntos (o casi todos), así que expreso lo que creo que es diferente (y tal vez nuevamente sea problema de semantica o falta de ella en mi escritura).

Aplicaciones Windows Store con XAML es más fácil si sabes WPF/SL, dado que es MUY PARECIDO.

"Apuntale a TDD y hacé bien el modelo (y el diseño)" me refiero a que si lo haces bien, tenes el problema "grabe" resuelto (no hace falta que expliquemos porque TDD te va ayudar). Después podes ponerle la UI o Persistencia que quieras (al fin y al cabo esta charla empieza por saber si usar NH o no).

Insisto, creo que estamos diciendo lo mismo en varios puntos.

SaludOZ,

2012/12/28 José F. Romaniello <jfroma...@gmail.com>

in-line

[Oscar Zárate]

Salías, no me lees y eso no te lo perdono ... jajajaja.

Yo dije: "hablando de C++ era otro que estaba muerto según algunos"

Se lee SEGUN ALGUNOS???? si incluso le puse el tilde para vos :-) (eso es mucho laburo para mi).

SaludOZ,

PS: Me voy a almorzar que tengo dentista en un rato ... ahí si que me va a doler ... la boca y el bolsillo (que caros que son los dentistas acá).

2012/12/28 Martín Salías <mar...@salias.com.ar>

[Juan Nallar]

Permitanme mis 2 cents:

- La web está de moda, aunque no es lo ideal, por los siguientes motivos:

   . Se baja el la vista y los datos todas las veces por el cable, cuando sólo cambiaron los datos.

   . Para resolver lo anterior, se puso de moda AJAX, que tiene el problema de que se escribe en javascript :( (gustos aparte)

   . Para resolver lo anterior, se crearon fwks de javascript, miles de ellos... pero sigue siendo js.

   . El protocolo HTTP es bastante limitado, desde su concepción (Modo Request - Response... y las notificaciones del server, bien gracias)

 

Por qué se usa? Por 3 motivos:

  1 - No hay que instalar en cada cliente (Y es el argumento principal de todo arquitecto de software en mi compañía usa para migrar apps a web)

  2 - Gracias a internet, se popularizó, y ahora es el martillo para todos los clavos, tornillos, y todo lo que se quiera clavar.

  3 - Es "open". (cualquiera puede leer HTML) 

 

En definitiva, creo que es un precio demasiado alto a pagar sólo por éstas dos características.

 

Winforms no está muerto. Se usa en los lugares donde se requiere performance (hagan la prueba de mostrar los mismos -muchos- datos en una app web y en una winform), y en los lugares donde se requiere que el modelo comunique algo a la vista.

 

Silverlight fue un buen intento de resolver las falencias del modelo web, pero, como lo hizo MS, no contó con la aceptación generalizada (dejó de cumplir con el "requisito" 3, o sea, es propietario, y es el mismo motivo por el cual HTML5 tiene tanta expectativa, es abierto)

 

Hoy WPF es la herramienta mas productiva para desarrollar aplicaciones de escritorio, aunque, vino con una avalancha de cosas nuevas y poco tiempo para adoptarlas completamente (EF, MVVM, Commanding, ADO Data Services,  RIA Services, etc)

 

 

Yo sinceramente espero que algún día, todas las plataformas compartan el mismo bitcode (quizás incrustado en el hardware), de esa manera, no haría falta librerías externas y todo lo que programemos se pueda ejecutar ahí (mas o menos como programar en C, pero con lenguajes de  mayores generaciones).

 

Feliz año a todos, y sigamos aprendiendo !

 

2012/12/27 Oscar Zárate <oscar....@gmail.com>

[Alberto Arroyo Raygada]

Juan:

Interesante  observaciones, en mi caso yo prefiero la web por un tema de estándar (W3C), la idea de poder tener un producto evolutivo en el tiempo y no depender de modelos propietarios me parece clave. Pasen o no a la historia Winforms, WPF, Silverlight, etc, etc, etc... la libertad no tiene precio.

Saludos.

Alberto Arroyo Raygada

Desarrollador de Software

Sitio Web: http://www.cslanet.org

Celular: (511) 99752-5257

[Walter Poch]

Juan,

Yo personalmente SIEMPRE prefiero web, y solicito que me den fundamentos porque no se podría hacer WEB y debe hacerse desktop (WPF, WinForms, Metro, etc).

El deployment y securitización que te dá una app web, para mi gusto es mejor a un desktop. Ni hablar del resto, compatibilidad de clientes (Ubuntu + Chrome, $0 licencias), etc.

Respecto a HTTP como protocolo no lo veo limitado, sino maravilloso ;). Anda en la nube derecho, firewalls, cache. Y notificaciones desde el server, desde hace años existe Comet (http://en.wikipedia.org/wiki/Comet_(programming)) pero no logró mucha adopción, ahora si está SignalR (https://github.com/SignalR/SignalR) que si no lo conoces miralo porque es excelente.

Saludos,

El 28 de diciembre de 2012 10:45, Alberto Arroyo Raygada <beyondn...@gmail.com> escribió:

observaciones

--
Saludos,

Walter G. Poch
Sr. .Net Developer
--------------------------------------------
Cell: +54 (9 341) 3353273
walte...@gmail.com

[Angel Java Lopez]

Agregaria Socket.IO cliente, Socket.IO servidor (solo lo vi en Node.js) y WebSocket (clientes y servidores en varias tecnologias).

Igualmente, un cliente desktop, tranquilamente puede consumir HTTP+JSON. Lo bueno que da HTTP+JSON es la gran cantidad de clientes y tecnologias que pueden montarse sobre esa combinacion. Permite cambiar la implementacion servidora por otroa (o tener alternativas) y permite tener mas de un cliente, o cambiar uno por otro si se necesita.

2012/12/28 Walter Poch <walte...@gmail.com>

--

[Juan Nallar]

Walter,

La característica de deployment es lo que le dá ventajas a la web.

La de securitización no. Un app desktop tiene la seguridad que le dá el sistema operativo en donde corre.

La discusión de precios es otra tema.

 

Lo que me decis del protocolo HTTP, que anda en la nube, en firewalls, cache, etc, etc, no tiene sentido, Te explico por qué:

La nube: Fue creada para el protocolo, y no a la inversa.

Firewalls, no tienen nada que ver con el protocolo. Está estandarizado que el puerto 80 quede abierto, solamente por una convención: Los ervidores webs sirven por ahí.

Cache: Es una técnica no relacionada con HTTP.

 

Ahora te propongo un ejercicio mental: Imaginemos que el http no existe. Cómo te comunicarías con un server?

Yo te digo: TCP/IP. es un protocolo que sí fue pensado con un amplio propósito.

 

Y Te contesta la pregunta de por qué programarías winform y no webforms:

- Simplicidad: Drag&Drop de controles, binding, commanding, statefull.

- Usabilidad: Thick client vs Thin client (programá una grilla editable en uno y en otro, y vemos el código).

- Performance: Código compilado, corriendo en la máquina del usuario, y no solo texto enviado por el cable interpretado y dibujado.

 

Son las que se me ocurren ahora, pero hay un argumento irrefutable: Las aplicaciones web, desde hace tiempo,  quieren parecerse mas y mas a las aplicaciones de escritorio. Por algo será, no?

 

Unos ejemplos gruesos: Las utilidades de los paquetes ofimáticos web está muy por debajo de los pares de escritorios. Un IDE cualquiera de escritorio tiene mil veces mas funcionalidad que el mas poderoso editor de texto web. Lo mismo pasa con los clientes de correo, gestores de bases de datos, y en general con cualquier programa que quieras comparar.

 

 

Angel,

Socket.IO es una implementación de WebSockets, el cual es un "parche" para permitir lo que HTTP no permite, que es la comunicación full duplex. De hecho, se realiza usando el viejo conocido TCP. Websockets está pensado para ser usado en navegadores y en servidores web, pero que puede ser usado en cualquier cliente (ovbiamente quién querría, cuando uno en una app desktop puede usaer los sockets directamente).

Además, según http://en.wikipedia.org/wiki/WebSocket todavía no hay una API estandarizada, y sólo las versiones mas recientes de navegadores implementan una versión segura, lo que indica que son cosas recientes.

 

No me malentiendad. Ya enumeré las ventajas de la web, sólo quería resaltar las desventajas (que todos parecen ignorar), y la cantidad de cosas que se hacen para solventar esas ventajas, que los desarrolladores recibimos como buenas nuevas, cuando en el mundo desktop nunca fueron un problema.

 

Me gustaría que gente que desarrolló -seriamente- en ambas, diera su opinión también. Yo particularmente, empecé con winforms, y cuando pasé a la web me resultó tremendamente complicado: Y es lógico, entre mi vista y mis datos, hay un intermediario que también tiene que ser programado, que es el servidor web. La web es stateless. El navegador no es mi aplicación (una ventana modal es un dolor de cabeza... ni hablar de hacer una applicación MDI). Los datos vienen como texto, cuando binario es mas rápido. Ya tengo la página en mi navegador, quiero mas datos, ah, hay que bajar la página entera de nuevo. Ahora puedo pedir los datos solos, pero si la vista se modifica con esos datos, tengo que usar javascript de manera intensiva... y no es tipado, ni compilado, o sea que tengo que ejecutar para ver si tengo algún error. Y así sucesivamente.

 

No es mi intención polemizar. Simplemente quería instalar la idea de que si el .Net framework (o la virtual machine de java, o cualquier otro "intérprete") se instalara como bitcode de todos los sistemas operativos (o mejor, fueran superinstrucciones de micros) la web no tendría sentido.

 

Mas claro: Si una app desktop pudiera ser instalada y actualizada con la facilidad de una app web, seguirían usando la web?

 

 

En fin, soñar no cuesta nada.

 

Saludos!

 

 

 

 

 

2012/12/28 Angel Java Lopez <ajlop...@gmail.com>

Agregaria Socket.IO cliente, Socket.IO servidor (solo lo vi en Node.js) y WebSocket (clientes y servidores en varias tecnologias).

[Angel Java Lopez]

Con respecto a:

Si una app desktop pudiera ser instalada y actualizada con la facilidad de una app web, seguirían usando la web?

Yo por lo menos si, seguiria usando la web, es decir, un cliente web como primera cosa a desarrollar de interfaz de usuario, a menos que haya un super requerimiento concreto de parte del usurio final. Lo que tendria que evaluar son las aplicaciones nativas de los nuevos dispositivos, que veo que van a ser las nuevas aplicaciones "desktops". Ahi es donde entra HTTP+JSON: para cambiar la tecnologia cliente cuando quiera. Si alguna vez necesito una aplicacion desktop, smartphone o tablet nativa, probablemente la seguiria usando sobre HTTP+JSON o variante sencilla que aparezca en el futuro para comunicarme con un servidor, porque es lo mas ubicuo.

Realmente, no veo problema en usar JavaScript en el cliente browser. Solo como todo: hay que estudiarlo. Pero lo veo como una inversion mas que interesante, mas que como algo en contra. Ya esta bastante maduro, es flexible. Solo recomendaria TDD, como siempre ;-)

Aca ahora tengo aca, en nuevo equipo agil, una excelente aplicacion, con una muy buena interfaz web con javascript, que se comunica con y API servidora, expuesta para otros tipos clientes, si alguien quiere desarrollarlos. Y me parece mas sencillo, flexible, mantenible que una aplicacion desktop. Lo que se invirtio en el desarrollo, se levanta en varios paises, sin mayor problema, y si alguien inventa un nuevo cliente, incluso uno desktop, lo puede tranquilamente usar. El unico tema es que se requeria soporte de IE8 para el cliente web. Sino, tendria menos friccion de desarrollo todavia.

Un contra ejemplo: Dropbox, que desarrolla su propio cliente "desktop", en Python que recuerde.

2012/12/28 Juan Nallar <nalla...@gmail.com>

[Walter Poch]

Como siempre Angel 100% de acuerdo.

La ubicuidad de la web es fundamental, a eso me refería con firewalls, nube, etc...

Desktop es algo cada vez más chico y creo que sólo tiene sentido en muy pocas circunstancias. Ahora tenes tablets, smartphones, smart tvs, All-in-One. con Web llegas a todos.

Yo siento una resistencia al cambio Juan, Win8 se puede programar con HTML+CSS+JS. También mirá este proyecto: http://www.meteor.com/ quizás vayas viendo lo que hemos visto nosotros en la web.

Un abrazo,

El 28 de diciembre de 2012 16:05, Angel Java Lopez <ajlop...@gmail.com> escribió:

para

[Ernesto Cárdenas]

Ojala que no pase lo que paso con Power Builder
www.displacedguy.com/tech/the-powerbuilder-phenomenon/ pues la idea de
que .Net se vuelva algo para proyectos legacy... asusta de veras.

[Juan Nallar]

Angel, seguis pensando en que tu app se va a user en otros lados, y por eso usarías web.

 

Imaginate que tu codigo binario se debería ejecutar en cualquier lado. Windows, Linux, Unix, Phone, Tablet, Licuadora, TV, Microondas, etc, etc.

 

No quitarías de en medio el servidor web? Para qué lo querrías? No te gustaría que los datos sean binarios y no texto, con la rapidez que eso conlleva? No te interesaría que fuera statefull?

 

Yo creo que usar un navegador + servidor web es un desperdicio de recursos, cuando podrías usar el cliente directamente accediendo a los datos. (Y no, no estoy hablando de la vista accediendo a la base). 

Personalmente creo que estamos tan "webizados", que creemos que todo lo que podemos hacer es Request/Response, y que es lo mejor :)

 

Pero pensemos un poco mas, podrías tener un cliente desktop (con todo el poder de la PC del usuario) y seguir consumiendo datos JSON (Es, a grandes razgos, lo que trató de ser Silverlight, y fue desplazado por la costumbre del HTML)

 

Mas todavía, imaginemos que hay una manera que, por ejemplo, SQL server me devuelva los datos en JSON. Para qué querrías HTTP y su web server? 

 

Programaste en WPF con MVVM? no lo consideras mucho mas sencillo, para cualquier contraparte en web?

 

 

No conozco el cliente desktop de Dropbox, pero tiene alguna des/ventaja con su interfaz web?

 

Saludos ! 

[Walter Poch]

Yo hoy "trato" de hacer aplicaciones como http://www.meteor.com/.

Tengo REST endpoints que devuelven JSON sobre HTTP. Statefull lo tengo en mi modelo en JS. Mi código se ejecuta en cualquier Licuadora que tenga un intérprete de JS. Mi servidor web, en realidad no es web, sino más un servidor de servicios.

SQL Server que devuleva JSON => MongoDB, RavenDB... etc...

Nuevamente, creo que es resistencia al cambio, algo que a menos que seamos curas vamos a tener que seguir enfrentando.

Abrazo,

El 28 de diciembre de 2012 16:37, Juan Nallar <nalla...@gmail.com> escribió:

mas

[Juan Nallar]

Walter, estoy de acuerdo con que desktop es cada vez mas chico, y es por el fanatismo del HTTP.

 

Sólo me planteaba si pudieramos mejorar el modelo, tanto en facilidad de desarrollo, ubiquidad, y "llegada a todos", cómo sería. Y me parece que si se pareciera mas al modelo desktop que al web, sería mejor.

 

He hablado con gente que programó toda su vida en apps web, y por un tema de proyectos están programando en desktop. Les resulta mucho mas fácil e intuitivo. El camino inverso es mas duro (lo he recorrido yo).

Debería ser un llamado de atención. Si desktop es mas facil, por qué seguimos con web? Sólo por la alta disponibilidad? Y si agregamos esa disponibildad al desktop, que pasaría?

 

En fin, sólo ideas. Estoy mirando la web, y mucha gente que opina, pero pocos han probado las dos plataformas.

 

Saludos

2012/12/28 Walter Poch <walte...@gmail.com>

--

[Angel Java Lopez]

Jajaja! Yo he probado desde tarjetas perforadas ;-)  y vi tantas aplicaciones desktop que no quiero ni recordarlas ya ;-)... y te cuento que el tema de tener cliente browser, capa de servicios, mandar un string (que puede ser comprimido automaticamente), y el cliente separado de lo demas, es realmente es muy flexible.

2012/12/28 Juan Nallar <nalla...@gmail.com>

[Juan Nallar]

La flexibilidad depende de la arquitectura, no de la tecnología.

 

Que quede claro, creo que la web, hoy por hoy, es lo mejor que tenemos, pero me gusta pensar que todo se puede mejorar, solo creo que parchando lo que HTTP no puede hacer no es la mejor manera.

 

Saludos y buen año !

2012/12/28 Angel Java Lopez <ajlop...@gmail.com>

Jajaja! Yo he probado desde tarjetas perforadas ;-)  y vi tantas aplicaciones desktop que no quiero ni recordarlas ya ;-)... y te cuento que el tema de tener cliente browser, capa de servicios, mandar un string (que puede ser comprimido automaticamente), y el cliente separado de lo demas, es realmente es muy flexible.

[Miguel Madero]

Creo que ambos tienen ventajas y desventajas y hay que conocer bien las opciones que tenemos para tomar una decisión informada en beneficio de nuestros usuarios. Creo que web vs nativo es un tema que se ha tratado mucho. Un problema que veo en estas discusiones es que la mayoría de la gente parece tener una opinión muy polarizada dependiendo de su experiencia y el contexto en el que ellos tomaron sus decisiones, cuando en diferentes contextos terminaremos con diferentes justificaciones y muy posiblemente una conclusión diferente. 

Creo que en general, web es la opción principal en la mayoría de los casos. Es la plataforma que más innovación tiene y en cualquier caso, minímo la parte de servidor utilizara muy seguramente tecnologías web por más que tenga un frontend en WPF o escrito en Java para Android o ObjectiveC para iPhone. Para aplicaciones grandes, en muchos casos terminaremos con sistemas hibridos. 

Por cierto, lo de JavaScript, para muchos es una ventaja el no tener que escribir C#. Las desventajas que mencionas son ventajas para otros y muchos otros lenguajes (e.g. Pyton, Ruby) tienen caracteristicas similares y pocos de los que escriben en estos los cambiaría por C#. 

Miguel

2012/12/28 Juan Nallar <nalla...@gmail.com>

[Miguel Madero]

La diferencia en performance y ancho de banda entre gzipped text o binario es grande, pero no significativa en la mayoría de las aplicaciones. 

Miguel

2012/12/28 Angel Java Lopez <ajlop...@gmail.com>

Jajaja! Yo he probado desde tarjetas perforadas ;-)  y vi tantas aplicaciones desktop que no quiero ni recordarlas ya ;-)... y te cuento que el tema de tener cliente browser, capa de servicios, mandar un string (que puede ser comprimido automaticamente), y el cliente separado de lo demas, es realmente es muy flexible.

[Daniel Cazzulino]

Solo voy a decir: imaginate Google Earth, o Google Maps (Navigation especialmente), hecho como pagina web. O Flipboard, o Audible, o....

Hay MILES de escenarios donde una aplicacion nativa (especialmente mobile) tiene MUCHISIMO sentido. 

/kzu

--
Daniel Cazzulino

2012/12/28 Juan Nallar <nalla...@gmail.com>

[Miguel Madero]

NOTA: Respondiendo a mensajes viejos de este thread.

Creo que todas las tecnologías tienen un ciclo de vida cada vez más corto y creo que la tendencia va a continuar así. Tenemos que estar al tanto de esto y considerarlo cuando alguien diga que va a apostar a una tecnología como su plataforma para los siguientes diez años (he trabajado en empresas grandes que aún piensan así).

Lo que dicen de TDD y centrarse en el modelo va ayudar a hacer más 'deshechables' ciertas partes, como data access layer o UI. Creo que el hecho de que algo sea deshechable es bueno por si solo. Mientras menos apegados estemos a nuestros sistemas o partes de este, más fácil será mantenerlo y tomar ventaja de nuevas tecnologías para ofrecer mejores soluciones a nuestros usuarios. Sin embargo, no creo que esto sea suficiente. Hemos visto bases de datos y mainframes sobrevivir por decadas como el centro de la aplicación, con todas las reglas de negocio, mientras tratamos de poner algo de ajax encima de estos. Sin duda los portales bancarios, por poner un ejemplo, se ven mejor que hace 10 años, pero la tecnología de bajo de bajo de muchos de estos sigue siendo el mismo COBOL en un mainframe con el que todos bromeamos. Será nuestro modelo bien testeado y diseñado con TDD el nuevo mainframe? 

Creo yo que un mejor enfoque es el tener silos verticales y autonomos. Pensemos en servicios (ala SOA (by Udi Dahan's definition)) o simplemente (mini) aplicaicones las cuales todas tienen un tiempo de vida mucho más corto y que pudieran colaborar entre ellas. Claro habrá algunas que sean más duraderas, pero otras que vivirán algunos meses o algunos años. Creo que en lugar de pensar en "EL MODELO" de la empresa, como lo he escuchado mucho, debemos pensar reducir el alcance de "EL SISTEMA" y pensar en áreas de negocio, departamentos o hasta funciones y, las interacciones entre estas. 

Para pensar en apps deshechables (o con corta vida), pensemos en ROI's express. Muchos piensan en el ROI "EL SISTEMA" a 3-5 años (para un desarrollo de 2 años que terminan siendo 3 o 5, yeah right!). Porque no pensar en un ROI de 3 meses para un sistema de un mes. Quien se va a quejar cuando les digas que vas a desarrollar desde zero (incluyendo el modelo) cuando tres años después, con un retorno de inversión de 16 veces (si fuese lineal) presiones Shift+Delete, seguido de File>New Project y escojas todas las nuevas tecnologías.

Pare hacer esta idea más intersante (IMHO) hay que tomar en cuenta que no solo las tecnologías cambian, sino la forma en la que la gente las usan y la forma en la que los negocios operan (e.g. reglas de negocio y todo lo que era valido 3 años atras en el "modelo"). Así que en lugar de pensar en que simplemente actualizaremos la capa de persistencia o la Interfaz de Usuario y dejaremos nuestro modelo, con tecnología obsoleta y muy posiblemente, lógica obsoleta, pensemos en diseñar SW más deshechable. Más fácil de reemplazar que de mantener. Rewriteability over Reusability.  

Miguel

2012/12/27 José F. Romaniello <jfroma...@gmail.com>

[Oscar Zárate]

Miguel, muy interesante lo que decis. Lo que si, lo de seguir usando Mainframes no es una elección, es lo que hay y no se puede cambiar sin grandes inversiones (en mi laburo se está pasando por eso, cambio de sistemas de Mainframe a otra cosa). Ojala alguno de mis sistemas pueda tener una vida útil de 20 años (muchos de ellos ya no cumplieron esa expectativa :-S)

Con respecto a lo de los cilentes, me imagino que cuando hablan de cliente de escritorio (fat client o thick client) no están pensando en un cliente desconectado, no?

En el caso de clientes conectados (la licuadora tiene que estar conectada a algo para recibir la información a ser mostrada en la aplicación nativa de Google Map), no estarían usando un servidor (como muy bien dijo alguien en este thread) de servicios respondiendo a los mensajes solicitados desde la licuadora? Y ese servidor (seguramente) va a responder en HTTP/JSON (o XML o SOAP o lo que sea).

Mi punto, El servidor (o la colección de servidores o la nube o lo que sea) es algo con la lógica de negocio que responde de una forma universalmente entendida y los clientes son lo que mejor se adapte a la necesidad en particular.

Por ejemplo, si alguien quiere una aplicación para iPad, le vas a ofrecer un cliente web? El tipo quiere una app en el Apple Store, pero la info está provista por el mismo servidor que provee los clientes fat en las oficinas y la aplicación web para las sucursales en grandes ciudades y la aplicación para el Windows Store que YO le quiero vender :-)

2012/12/29 Miguel Madero <m...@miguelmadero.com>

[Ale Miralles]

Juan, desktop no es ni más fácil ni mas intuitivo que web. Son dos cosas distintas, nada más.

Yo hice el mismo camino que vos, primero desktop después a  la web, en mi caso con asp.net 1.x. Todavía me acuerdo del designer pedorro que tenia VS2003 para hacerle creer al programador que seguía haciendo drag and drop WinForms cuando estaba programando en web…, bueno, eso para mí, es aprender mal como programar en web. En su momento lo que hice fue aprender php y ahí entendí como funciona http y los dos working horses de la web POST y GET, después hice cosas en Ruby y actualmente algunas cosas en ASP.NET MVC/WebAPI.

Hace 10 años que trabajo en .NET (WinForms y ASP.NET) y los dos tienen sus pros y sus contras, no hay uno más fácil que el otro.

 

Aclaro que creo que desktop no está muerto y menos en ambientes corporativos, yo trabajo haciendo sistemas para banca mayorista y el 80% del trabajo sigue siendo desktop.

Pero me parece que el argumento del drag and drop de desktop y de “no entender” el request/response de http, sean suficientes para decir que los desktops deberían dominar al resto.

 

Saludos, Ale Miralles

http://amiralles.com.ar

http://blog.amiralles.com.ar

[Juan Nallar]

Gracias Ale, por compartir.
Sigo creyendo que hacer una misma aplicación (con exactamente la misma funcionalidad, usabilidad, mantenibilidad, etc) toma menos tiempo y requiere menos conicimiento de infraestructura en desktop que en web, con lo cual es mas fácil.

Pero bueno, respeto tu punto de vista.

A propósito, ¿no estaría buena una competencia de éste tipo? Hay muchos "peros", pero sería interesante, no?

Saludos

[Ale Miralles]

Totalmente!