Perestroika
El funcionario de la calva brillante con la mancha como un mapamundi se levantó y se dirigió hacia los micrófonos. Carraspeó y comenzó a hablar cansinamente, como hablaban los funcionarios de la extinta Unión Soviética:- Daraguíe tavarischi - es decir, "hola, troncos" - El Soviet Supremo me ha encargado la honrosa tarea de comunicaros dos noticias. Una buena y una mala. La buena es que hoy ya es viernes.
Un murmullo de satisfacción teñida de falsa sorpresa recorrió la sala.
- La mala - titubeó, aunque sólo un momento - la mala es que lo nuestro no funciona.
Los ecos del murmullo cesaron abruptamente.
- ... y no me refiero a lo de enfriar en una nevera las semillas de patata antes de sembrarlas, para aclimatarlas al frío - el anciano hijo de Trofim Lysenko se levantó airado y abandonó la asamblea - sino a este invento del comunismo.
Una mosca atravesó la enorme sala zumbando. Nadie la detuvo.
- Sí, coño, hemos estado haciendo el panoli durante setenta años. Y para nada. Hemos matado de hambre a media Ucrania. Hemos jodido a conciencia a polacos, húngaros y checos, y a buena parte de Alemania. ¿Y todo para qué? Para que nuestros obreros pasen hambre y frío, para fabricar estos horribles coches y esos espantosos sintetizadores alemanes democráticos que se funden antes de terminar la primera estrofa de la Kalinka. Esto, maí vesyolye rebyata, no firula...
Los murmullos se reanudaron. El delegado de Dirkadirkastán alzó tímidamente la mano y preguntó:
- Y ahora, ¿qué?
- Ahora - el calvo hizo una pausa teatral - ahora... ¡perestroika!
- Ahora - el calvo hizo una pausa teatral - ahora... ¡perestroika!
En Redmond parecen estar también algo revueltos y perestroikos:
Y ya era hora, coño. Ya era hora de que alguien se diese cuenta de que todo este invento del POJO, del POCO y del MOJO POCO no funciona cuando se trata de escribir aplicaciones multicapas. La vanguardia del proletariado, por supuesto, pondrá el grito en el cielo, pero de momento andan callados. Puede que no hayan comprendido lo que hay en juego. En realidad, los fundamentalistas javalinos suelen comprender muy pocas cosas.
Es verdad que los de Microsoft se asemejan más a los chinos que a los rusos: cada cierto tiempo se inventan una Revolución Cultural y no son muy ortodoxos en lo tocante al martinismo-fowlerismo. Además, acaban de perder al Gran Timonel. Y tienen una misma palabra para crisis y oportunidad: suena parecido a crisistunidad.
Etiquetas: .NET, ADO.NET, LINQ, metodología
Ian Marteens, 3:39 p. m.
84 Comments:
No creo que esto se pueda comparar con que los rusos se diesen cuenta de que el comunismo no funciona.
Esto se podría decir si se diesen cuenta de que la OO no funciona con sistemas de bases de datos, pero cuanto más tiempo cometes un gran error más difícil es reconocerlo, sobre todo cuando vives en un mundo endogámico donde todos cometen ese error y nadie lee otra cosa que no sea prensa de mercado.
Con lo fácil que sería asociar controles visuales a variables de la base de datos y olvidarse de todo lo demás.
Con Delphi te haces un formulario de clientes en dos patadas sin apenas escribir código.
En lugar de mejorar eso y hacer que funcione bien independientemente del número de capas, se dedican a reinventar el modelo de red y la gestión de datos procedimental en las aplicaciones.
Hola Alfredo, siempre leo tus comentarios en este blog ,me gustaria hacerte una pregunta , yo programe mucho tiempo en delphi , ahorita necesito empezar un proyecto en multicapas, ya probe de todo , Entity Framework con Ado.net DataServices me resulto complicado lleno de problemas y ademas lentisimo, intente con datasetTipados , me parece muy trabajoso y lento tambien, en resumen mi delphi con ClientDataSet y DataSnap resulta ser mas rapido, que me podrias recomendar que continue explorando la plataforma .net o que continue usando mi tradicional delphi
con que los rusos se diesen cuenta
:) Bueno, pues los cubanos o los coreanos entonces.
No, no creo que haya sido un brusco despertar. Estarán empezando a ver las orejas al lobo, y estarán todavía en la fase de "creo que podemos arreglarlo".
De todos modos, la impresión general es que esta gente pondrá toda la carne en el asador del Entity Framework. La verdad es que algunas cosas son más sencillas, y el problema principal que hay ahora mismo es que más de tres cuartas partes de las cosas hay que resolverlas en XML.
Hice muchas puebas con el entity framework , mi conclusion es que es lento, y todo lo demas de tus comentarios , maestro detalle , relaciones cada cosa , cada relacion agregada lo deja mas lento, y programar del lado cliente es un desastre, eso si usas ado.net dataservices, si quieres ejecutar un prodecimiento almacenado por ejemplo , lo tienes que hacer por uri,el procedimiento no puedes devolver ningun dato que no este definido como entidad, el linq sobre los EF es muy pobre , y si vas a usar con WCF por supngamos TCP/IP bueno es peor , tienes que estar acoplando las entidades del lado servidor constantemente , y escribes mucho codigo, en este punto si algo me gusto de XPO de devexpress que define un IDataStore para las actualizaciones , basicamente evita de escribir mucho codigo, mi frustracion Ian es la sgte , tengo que escribir mucho mas codigo para tener lo que tenia antes con mucho menos trabajo con delphi(y ya tengo claro el futuro de delphi), en resumen donde esta la productividad en todo este conjunto de cosas que funciona a medias
Todo lo que dices es cierto... y peor aún: ahora mismo tienes que programar mucho más código que con los datasets de la 1.1. Con ADO.NET "tradicional", pillar el evento RowUpdating para colar valores en la instrucción (estoy programando ahora mismo para Oracle, y me exigen que lo haga con una mano atada a la espalda y un parche en un ojo), es una odisea.
¿La productividad? En ninguna parte. Yo saqué un libro para la 1.1 con entusiasmo, pero desde entonces me estoy aguantando para sacar el siguiente. Ahora mismo, no puedo escribir para el EF de la 3.0, porque casi todo va a tener que cambiar en la 4.
La esperanza mía es que las aguas regresen a su cauce con EF y la 4: cuando las "entidades" ofrezcan al menos la misma funcionalidad que los viejos datasets. Por eso creo que es importante que se esfuercen con lo de las self-tracking entities. Hay algunas cosas que serán más sencillas. Por ejemplo, la resolución de conflictos de concurrencia (a costa quizás de perder algunas opciones que tienen los datasets, pero que nadie implementa).
Y el otro problemón son los sistemas de remoting. Está claro que los tiros tienen que ver con WCF... pero hay patrones que venían de serie con el antiguo COM+ que ahora tienes que implementar bajándote un ejemplo de una página oculta y esotérica de Microsoft (el object pooling, nada menos).
Creo que en Microsoft, quitando a la gente de los compiladores y el CLR, han perdido tres años a lo tonto. Y lo peor es que no ha aparecido un tercero que resuelva los problemas, como hacía Borland en los "gloriosos" tiempos del WinAPI.
Cristian, sin duda entre esas dos opciones te recomiendo que sigas con Delphi. DataSnap está lejos de ser perfecto, pero lo de Microsoft es un desastre. Respecto a lo de las capas hay que distinguir entre "layers" y "tiers". Como regla práctica, todo lo que habla sobre applicaciones "multilayer" puede ignorarse por que no son más que tonterías. Y los sistemas "multitier" solo deben de crearse cuando realmente sean necesarios, por que sino son ganas de buscarte un montón de problemas para nada por que la tecnología sigue siendo muy inmadura.
Y en el caso de que necesites crear un sistema "multitier", para mí la regla de oro es que las aplicaciones deben de crearse de la misma forma sea cual sea el número de "tiers". Es decir que si la forma de crear una aplicación es muy distinta dependiendo de si van a usarse más o menos capas es señal de que algo no está bien pensado.
Bueno, pues los cubanos o los coreanos entonces.
Quería decir que como mucho los de M$ se han dado cuenta de que los koljost no funcionan, pero siguen aferrados al comunismo.
No, no creo que haya sido un brusco despertar. Estarán empezando a ver las orejas al lobo, y estarán todavía en la fase de "creo que podemos arreglarlo".
Sí, algo como esto, pero ya llevan un montón de tiempo dando palos de ciego intentando arreglarlo.
Algunos palos caen más cerca que otros, como por ejemplo LINQ to SQL, pero parece que es por pura casualidad, por que enseguida vuelven a alejarse con cosas como Entity Framework.
como por ejemplo LINQ to SQL
Seguro que ya lo sabes: se lo cargan. Más penita que me da con el niño Vijay: mira que dedicarle medio libro a LINQ to SQL para nada.
las aplicaciones deben de crearse de la misma forma
Completamente de acuerdo. Y el principal obstáculo para ello, que no es grande, está en diseñar un sistema de metadatos que funcione con independencia del origen de datos. IMHO...
El problema es que hay "orígenes de datos" (que poco me gusta ese término) que no tienen nada que ver con otros, y si queremos algo que funcione con todo, nos tenemos que restringir al máximo común divisor. Y el MCD de dos números coprimos es un palote :-)
En el lado de las aplicaciones yo veo una solución sencilla: olvidarse de los "orígenes de datos" XML y DBase y similares excepto para importar datos, y usar "entry level" ANSI SQL (el MCD) como lenguaje de comunicación entre applicaciones y servidor.
Para estandarizar el sistema de metadatos simplemente tendríamos que crear un juego de vistas estandar (un catálogo) y adaptarlo para cada SGBD que queramos usar.
Todo esto como solución cutre para ir tirando si no necesitas tipos de datos complejos. Arreglarlo bien es mucho más complicado por que habría que sustituir SQL por algo bien hecho.
El problema es que ni Microsoft ni Embarcadero ofrecen herramientas con las que se pueda desarrollar sin tener problemas, todos tienen errores, cosas sin resolver, y siguen inventando en cada versión, yo como programador estoy hasta los mismisimos de romperme la cabeza cuando algo no funciona y resulta que despues de mucho investigar... pues resulta que es un agujero tan negro que no se ve nada, a ver cuando alguien hace algo y por lo menos lo termina hasta el punto de que funcione, y que decida mejorarlo pero no inventar nada hasta que lo que tiene entre manos lo tenga 100 % funcionando, y si decide inventar que lo haga a la vez. Alguien puede decir cual es el futuro de Delphi o de Visual Studio, yo estoy cansado de estar entre Pinto y Valdemoro, estoy pensando en probar suerto con WinDev, o Velneo jaja.
Y lo peor es que no ha aparecido un tercero que resuelva los problemas, como hacía Borland en los "gloriosos" tiempos del WinAPI.
¡Hola Ian! Mira que sentí una especie de llamado subliminal al leer esta frase, pero temo que mi precaria economía (por cierto, en un país no comunista) carece del poder suficiente para hacer que el primitivo y casi experimental Morelia Framework venga a rescatar el ánimo de las víctimas de EF.
Algunas personas me ha preguntado por qué nombré “Rescatando a Delphi” a mi bitácora; son quienes conciben dicho título como una exageración, incluso como una ofensa. Afortunadamente son pocos (o al menos son pocos los que me han reclamado). Pero lo que expongo ahí es casi siempre con miras a mejorar no sólo el mundo alrededor de Delphi, sino del desarrollo de software en general y, aún más allá, el estadio humano en sí. Ojo, no me considero con el conocimiento o poder suficientes para causar grandes cambios, pero cuando tengo algo que ofrecer, siento un irremediable impulso por colocarlo sobre la mesa. Vaya, es como mi “inútil” intento de proteger al planeta separando la basura. No sé si logre rescatarlo, mas intentarlo es vigoroso. En este sentido, la palabra Delphi simboliza todo lo que hay, y lo que trato de hacer es rescatar las cosas buenas que parecen estarse perdiendo.
Cristian: Encuentro empatía en tus comentarios. Me gustaría invitarte a conocer de cerca las ideas que he venido plasmando en mi “EF casero” a fin de mejorarlo. Está basado en la clase TClientDataSet de Delphi, pero te advierto que es aún tan rudimentario que su código fuente tiene efectos somníferos.
Ian: En cuanto sienta que esta cosa que inventé se encuentre a la altura adecuada, estaré encantado de enviarte una copia para que la “despedaces” con tu ojo crítico, y con ello perfeccionarla aún más. Desde luego, si tú quisieras. Perdón si esto es demasiado atrevimiento.
Respecto a los sistemas económicos, recuerden que son como el software (es extraño, acabo de tener un déjà vu): su buen desempeño depende en gran medida de los usuarios. Stalin y Bush no eran precisamente grandes gestores de riquezas. ;)
Estupendo artículo Ian, uno de los que más gusto ha causado en la Avenida Olivares.
Un abrazo.
Al González. :)
Hola Al Gonzales , vaya coincidencia el dia de ayer estube leyendo tu blog, para ver si alguien me daba una luz de como andaba mi querido delphi, lo que yo reclamo y creo qe tengo razon es que Navision2009 ,Solomon2009 , GP2009 y todo el soft de ERP de micrososft digo ERP pq ese es mi segmento de desarrollo , nada usa ni EF , ni ado.net ni nada de .net abolutamente nada ni de winforms ni nada , no entiendo pq microsoft no usa su propia plataforma .net, y se me complica la vida pq antes con delphi ClientDataSet, DataSnap , y el FW de Remote Objects todo me resultaba productivo ,entre al .net sinceramente por capricho me entusiasme con el libro de Ian , bueno siempre ando entusiasmado con los cursos de Ian pero ahora ando medio que pensando de esta menera , donde esta la productividad?, pq me veo obligado a escribir mas y programar cosas como concurrencia o otras cosas que antes con delphi era facil?, pq en .net (EF) todo es mas lento?pq ahora para ejcutar un procedimiento almacenado tengo que escribir un mas codigo , y luego publicarlo con mas codigo en el servicio y luego mas codigo para la Business y mas codigo para el cliente, escribo 3 veces la misma o casi la misma cosa? estou en .net por dos motivos y son los unicos ,1.-La calidad de los componentes es muy buena(Me refiero a Developer Express)creo que son mejores que la VCL, 2.- Me gusta el lenguaje C#, otros motivos no los tengo pq no encuentro nada en .net que no pueda hacer con delphi uno de mis miedos era que el mercado de componentes pra delphi(developer express) y otros desapareciera por eso estou intentando las cosas en C# , actualmente uso XPO de devexpress y me parece lo mas acertado en acceso a datos que he usado hasta el momento.AL si tienes MSN y quires compartir conmigo experiencias en delphi el mio es cledesma99@hotmail.com
Yo veo este movimiento como el ofrecer una opción para aquellos que no le gustan el modelo POCO, pero en este universo de la informatica hay varios gustos.
La críticas fuertes a Entity Framework en la primera versión eran respecto a lo invasivo que es en la entidad, y si que lo era, lo que se pedía era un modelo no invasivo POCO que sirviera para el mismo propósito, pero ¿porque POCO? ahh, el modelo POCO permite la reutilización de las entidades en cualquier capa y en cualquier tipo de aplicación debido a su bajo acoplamiento, igual se utiliza en la capa de datos que en la lógica o en el cliente, o en WinForms , ASP.net o una aplicación movil hecha con CF. Vaya, en otras palabras la entidad se convierte en otro tipo de dato más.
La otra opción opuesta es cargar cierta lógica a la entidad para que se defienda sola, unos lo llevan al extremo como CSLA, otros son más moderados, esta tiene la ventaja de que en cualquier tipo de programa que lo invoque las validaciones serán siempre las mismas y recicladas, la desventaja es que teniendo lógica se tendría tal vez a veces que crear otro objeto puente más ligero operaciones que no demandan tanta carga.
Las dos opciones son buenas y solo hay que saber cuando aplicarlas y para que tipo de aplicaciones se les puede sacar el máximo provecho.
En lo personal actualmente uso el modelo POCO en los proyectos pero el otro no es para desconsiderarlo.
Sobre el otro punto de escribir menos código y volver al viejo modelo RAD yo en la verdad no lo haría. No niego la cruz de mi parroquia que en mis inicios en Delphi cometía los mismos pecados, arrastrar y pegar componentes de datos y tener un ABC en cinco minutos, Esto es genial!!! esclamabamos mis colaboradores y yo, ahora lo veo diferente, esas mismas aplicaciones que en su momento desarrolle con esas técnica ahora se han vuelo un gran problema en su escalabilidad, y se han quedado obsoletas.
Yo en lo personal no tengo problemas en escribir más código siempre y cuando sea garantía de flexibilidad, escalabilidad y desempeño.
Comparando un simple ABC que me tardaba 30 mins. máximo en Delphi, ahora tardo 3 veces más en C# en .NET, pero el tiempo invertido se recupera después, al menos yo si lo he comprobado.
Si bien aún uso Delphi para aplicaciones que no demandan mayor atensión que unas 15 a 20 formas, me dedico a .NET para proyectos escalables grandes que son de 100 a 150 formas y son para mucho más usuarios, ¿Se tarda más tiempo en terminarla?, si, pero yo no engaño al cliente, le digo cuanto va a tardar el proyecto y negociamos entregas paulatinas, pero tengo la ventaja que un cambio inesperado por X circunstancia no me hara perder el sueño, porque desde el principio diseñe el proyecto a prueba de esos cambios.
Al finalizar el proyecto me queda la satisfacción de que el 80% es reutilizable para cualquier otro proyecto y ahí recupero mi inversión.
Este proceso es muy dificil asimilarlo al principio, en mi experiencia yo le preguntaba de forma desafiante al consultor de arquitectura "¿Para que tanto brinco estando el suelo tan parejo? esto ya lo habría termindado so lo hubiese hecho a mi manera", pero despúes lo comprendí por mi cuenta en un proyecto que de no haber tenido esas bases lo hubiese perdido o retrabajado casi al 70%. Además permite que otros miembros del proyecto reutizen lo que yo hice en sus propios proyectos y yo puedo usar lo de ellos también.
Desventajas, el tiempo de entrega, y en este negocio entre más rápido termines un proyecto más luego te pagan y más luego empiezas otro. Por eso no para todos los proyectos usamos este metodo, solo para el cliente que puede pagarlo y demanda un grado de confiabilidad muy grande. Para los otros tipos más ligeros seguimos usando Delphi, pero no de la manera RAD, sino orientado a objetos, para eso Delphi se pinta solo.
¿Se utilizan las mismas herramientas para pintar una silla que un rascacielos? Por la misma razón no creo que NECESARIAMENTE una aplicación de 3 capas haya que programarla igual que si fuera de 1.
Por otro lado enlazar controles visuales a campos es igual que obviar que existe una lógica de negocio detrás de cada dato y por eso ha fracasado el modelo DELPHI y TODOS LO MODELOS que realizan BINDINGS (y lo que le queda).
En cuanto al MCD estoy de acuerdo que el sistema ANSI SQL es lo más parecido que hay, y lo que hay que hacer es avanzarlo en vez de reinventar continuamente la rueda.
(Esto me recuerda al plan Bolonia)
Finalmente creo que el camino correcto es el de los webservices , las aplicaciones deben comunicarse entre SI intercambiandose paquetes de información que bien pueden ser XML, pero el XML siempre debe ser transparente al usuario.
y por eso ha fracasado el modelo DELPHI
¿¿¿¡¡¡!!!???
Borland se hundió por sus tonterías (entre ellas, tirarse tres años creando una herramienta de programación para los majaderos de Linux que luego ninguno de ellos quería pagar).
Delphi tuvo sus problemas, efectivamente, pero el databinding no fue ni remotamente uno de ellos.
pero el XML siempre debe ser transparente al usuario.
Entonces, ¿para qué quieres XML? Es un lenguaje horriblemente costoso.
De todos modos, para atemperar la nostalgia por Delphi, recordad que DataSnap se tiró no se cuántas versiones con un problema grave en las relaciones maestro/detalles, cuando ocurría un error al grabar detalles teniendo ambas tablas claves automáticas. Incluso ahora no tengo claro que lo hayan arreglado... o siquiera comprendido.
¿Y recordáis aquel problemón de eficiencia con las relaciones maestro/detalles? La consulta de detalles se tenía que evaluar una vez por cada fila de la tabla maestra. Ah, y si querías traerte las dos consultas por separado y enlazarlas en el lado cliente, al estilo ADO.NET, tenías que tirar de trucos, porque directamente daba un palo de película.
Y lo peor de todo: la imposibilidad de modificar el comportamiento de providers y client datasets por un diseño miope de las clases, sin métodos virtuales apropiados, y con toda la lógica "hard-wired", a lo bestia.
Al leer este parrafo en las contestaciones del artículo se me dibujo una sonrisa en el rostro:
"I will follow-up with a post on what we can expect the entities to look like, but for now the important point is that we will not require an interface or base class that is part of the Entity Framework to use self-tracking entities."
...... yo estoy cansado de estar entre Pinto y Valdemoro, estoy pensando en probar suerto con WinDev, o Velneo jaja.
Te oigo decir windev y Velneo y aun en bromas me pongo malo como un perro.
Si quieres saber lo que es sufrimiento, vete a una demo de windev y disfruta al verlo reventar.
Y si quieres ver un interface antidiluviano vete a velneo (es menos malo que el otro).
we will not require an interface
Bueno, si Microsoft logra la cuadratura del círculo, no seré yo quien me queje. De todos modos, creo que alguna versión futura de EF puede funcionar. Siempre, claro, que recuperen toda la funcionalidad que se han dejado por el camino durante todos estos años.
Estoy de acuerdo con avmm2004 en que eso del Velneo no se debe decir ni en broma. Eso es peor que volver a DBase. Lo más antediluviano de Velneo son las bases de datos, y si lees la documentación dan ganas de llorar.
Respecto a lo que dice Ramses, el RAD no está reñido para nada con la escalabilidad. Las aplicaciones DBase-Delphi no eran escalables, pero el RAD no tenía ninguna culpa. Yo hago RAD con C# todo lo que puedo.
Con respecto a EF, CSLA, ORM y demás, no son más que tonterías producto del analfabetismo en bases de datos.
Redman, SQL tiene errores fatales y no tiene remedio. Además los SGBD SQL dan muy pocas opciones a la hora de diseñar el modelo físico y son leentos.
Si tenemos una rueda cuadrada tiene sentido hacer una redonda, pero sabiendo hacerla, claro.
Con respecto a los databindings, fueron una de las razones del triunfo de Delphi. Lo malo es que los componentes eran muy rígidos, mal documentados y difíciles de modificar.
Los databindings de .NET son muy básicos, pero por lo menos son muy sencillos de entender y de hacer con ellos lo que quieras. Yo no tengo ningún problema para imitar las cosas buenas de los TQuery de Delphi en C#
Una de las primeras cosas que hago cuando comienzo un proyecto en C# es eliminar las referencias a ADO.NET y XML.
Respecto a las relaciones maestro detalle para mí la solución es hacer algo que para el programador sea como lo de Delphi pero que internamente haga paginación tanto con maestros como con detalles.
Por cierto, yo estoy pensando seriamente en pasarme a Silverlight para casi todo.
Lo de WinDev y Velneo es broma son sistemas de juguete a los que no se le puede pedir casi nada, lo decía un poco por tirar de las lenguas y por ver opiniones. Lo que sí que es verdad es que cualquier empresa que se dedica a desarrollar herramientas de desarrollo nos maltrata durante años para que al final todo quede en las páginas de Historia. Empiezan a desarrollar un caramelo lo dan a probar y no está dulce hasta que pasan años mientras tanto los catadores esperamos y esperamos con la esperanza de que algún día sepa bien o muy bien, y entonces dejan de fabricarlo, pero no hay problema porque otra gominola esta en desarrollo y nos dicen esto va a saber a ... mejor me callo, creo que Ian ya comentaba algo de los caramelos en otra entrada y nosotros que somos muy curiosos vamos corriendo a probar. Bueno, ¿es normal que desde la versión 1.1 hasta la 4 por decir algo la EF haya estado esperando su turno para ponerse al día? Esto es vergonzoso, sobre todo tratándose de Microsoft, el grande, a ver si contratan a gente para solucionar los problemas que están presentes, visibles, y con un montón de gente esperando a que se solucionen... De Borland, CodeGear, Embarcadero para que hablar, tienen deberes pendientes desde ni recuerdo, estaré empezando a tener alzeimer por culpa de estos maltratadores... ¿Cuando los programadores tendremos herramientas de desarrollo de 7ª generación?
Manuel, lo que pasa es que los fabricantes no saben lo que hacen. La industria está cada vez más alejada de la ciencia y de la razón.
El EF es una tontería sin piés ni cabeza y lo único que se puede hacer para arreglarlo es tirarlo a la basura, y es lo que van a hacer dentro de no mucho tiempo.
Es un ciclo que se repite y se repite: gente que no tiene ni idea desarrolla una tontería que por supuesto resulta que no funciona. Durante un tiempo más o menos largo intentan arreglarlo hasta que acaban dandose cuenta de que los problemas son demasiado profundos y entonces otros desarrollan otra tontería sin piés ni cabeza que tampoco funciona, pero como todavía no han tenido tiempo para experimentar sus problemas se lanzan todos como locos a por ella y el ciclo continúa.
Y todo por que la gente no quiere saber nada de las matemáticas.
Es como si a los ingenieros se les cayesen los puentes una y otra vez y se empeñasen en no querer saber nada de la física.
Me he expresado mal:
Cuando hablo de binding realmente me refiero a BINDING directo a las bases de datos!!
No tengo nada en contra de hacer un binging contra memoria (un DataSet de .net)
Cuando hablo de XML me refiero a como se comunican las distintas aplicaciones (o mejor dicho sus servicios) entre si , podría ser cualquier otra cosa pero el XML es un estandar y no me parece malo, es la manera que dos empresas que no se conocen de nada se puedan entender, ejemplos:
Un CONTROL GRID de una compañia! Toma distintos XML, para representar su interfaz, o tomar datos. (si es un grid en entorno .net puede ser un DATASET)
Un interfaz hecho en LINUX ataca a un SERVICIO programado en un programa WINDOWS (q ataca sql server).
Una programa de tres capas comunica la interfaz con los servicios que ofrece la capa de negocio.
Todo esto no implica que haya que saber mucho XML yo trabajo con DataSets mientras que no me salga del entorno .NET
Alfredo:
Y todo por que la gente no quiere saber nada de las matemáticas.
Cargocultismo.
El EF es una tontería sin pies ni cabeza
Yo nunca hubiese tirado por ahí. El modelo ER me parece estupendo, pero si quieres darme algo así, no me obligues a hacerlo en el lado cliente. Disfrázame tu servidor de datos, que para eso tienes uno (le estoy hablando a Microsoft). Si quieres que funcione también con Oracle, pon un adaptador en el lado del servidor. Esa es la ventaja de tener el CLR funcionando dentro de SQL Server o la JVM con Oracle: aprovechadla, coño.
Y dame un API decente para construir el lado cliente. O si no quieres alejarte demasiado de SQL, por la inversión ya existente, haz algo parecido al ESQL... pero que al cliente le parezca "nativo" del servidor.
Mi principal pega a un EF hipotético que ya funcionase es toda la parafernalia de SSDL, CSDL que hay que montarse para este apaño.
No obstante, tal como están las cosas, y poniéndome en las botas de Microsoft, no creo que tengan muchas más opciones que hacer que el EF funcione. Con el self-tracking, pueden hacer que las colecciones de entidades tengan, finalmente, la misma funcionalidad que los datasets. Hablando con objetividad, algo se ha ganado con el LINQ en el lado cliente: ya no tienes limitaciones para filtrar un resultado en memoria, como tenían los datasets (incluidos los délficos).
Hay otro "progreso" respecto a la 1.1: la posibilidad de crear controles mediante drag and drop. Es todavía mucho más pedestre que lo que ofrecía Delphi, pero al menos ya existe.
Problema: seguimos igual en lo que respecta al desarrollo multicapas. No hay nada parecido al IDataBroker. Pero no estaríamos peor que en la 1.1.
Sí, efectivamente, es triste decir: "me conformo con lo que ya tenía". Pero hay que ser realistas.
No tengo nada en contra de hacer un binging contra memoria
:) ¿Y qué cosa era un TClientDataSet?
Hola amigos:
veo que en general todos los que somos desarrolladores independientes, o casi, lidiamos basicamente con los mismos problemas y compartimos el mismo desencanto con las herramientas que utilizamos en nuestros desarrollos. Al margen de sentir como imposible poder alcanzar a dominar todas las tecnologias necesarias que requieren los sistemas actuales.
Por tal motivo me permito recomendarles que echen un vistazo a GENEXUS (www.genexus.com). Reconozco que no he usado el producto (la licencia es bastante onerosa como para decidirse de una), pero los comentarios que tengo de quienes lo utilizan no pueden ser mejores. Seguramente la gran mayoria nunca lo habra sentido nombrar, ya que el marketing no es su fuerte parece, pero he pasado horas viendo los videos de las conferencias de su ultimo encuentro internacional y viendo su curso no presencial en videos y realmente me parece muy interesante. Sobre todo por la concepcion del producto, ya que parece que hasta el propio amigo Gates anuncio que ya no se puede seguir programando de la forma que lo venimos haciendo. No me quiero extender en tratar de explicarles sobre el producto y su filosofia, me parece que en la pagina encontraran informacion mejor que la que yo pueda darles x aca. Simplemente que para despejar algunas de sus logicas dudas les puedo comentar que varios sistemas, sobre todo en administracion publica de argentina estan desarrollados con dicha herramienta, como para que vean que en sistemas grandes funciona sin problemas.
Por ultimo, n otengo acciones en la compañia (ojala las tuviera :)), simplemente me permito compartir algo que descubri y que me parece puede ser muy util para todos los que venimos lidiando con la tecnologia. Yo la conocia desde hace tiempo y no me parecia muy buena, pero viendo la ultima version he cambiado radicalmente de idea. Si alguien la conoce, trabaja con ella o simplemente llevado por la curiosidad de mi comentario la explora, agradeceré sus opiniones al respecto.
Un saludo desde el fin del mundo.
Cuando hablo de binding realmente me refiero a BINDING directo a las bases de datos!!
Pues es justo lo que hay que hacer. Pero con bases de datos de verdad y no porquerías como XML y DBase.
Otra cosa es el número de "tiers" que tiene que tener el SGBD.
Un diseño de base de datos relacional es la mejor forma de abstraer una base de datos que se conoce, y la gente iletrada se empeña en abstraer la abstracción con inventos caseros que por supuesto nunca funcionan.
No tengo nada en contra de hacer un binging contra memoria (un DataSet de .net)
Pues esta es la raiz de todo el mal. Tener una base de datos en memoria sin casi ninguna de las ventajas que da un SGBD. Y en el caso de los objetos de negocio todavía peor por que además de esto tenemos una base de datos de red.
Los que se van de modernos usan sin saberlo técnicas de los 50 que se quedaron obsoletas hace décadas.
Y lo demás que dices de XML también lo puedo hacer mucho mejor con ODBC u OLE DB.
Alfredo seguro que eres un gran programador, pero no sales de esa piel y por eso te ofuscas en que todo el mundo es muy malo y lo hace mal, yo lo que digo es que hay que hacer herramientas que se abstrigan de los campos y tablas y consultas y todo lo que tenga q ver con programación un usuario lo que quiere es que le de un servicio y se le demanden parámetros SIN TENER NI IDEA DE TECNOLOGÍA más allá de la propia herramienta que utilice.
Yo nunca hubiese tirado por ahí. El modelo ER me parece estupendo,
A mi me parece prácticamente inútil, pero si quieres ofrecer el Modelo ER tiene que ser como una fina capa por encima del Modelo Relacional, que eso es lo que es, y no interpretar el Modelo ER como te de la gana y destrozar el Modelo Relacional, que es lo que han hecho.
EF no es una implementación del Modelo ER, sino que es una aberración que se inspira en lo que los cargocultistas de M$ creen haber entendido sobre el Modelo ER escuchando radio macuto.
Pero de todas formas el Modelo ER le aporta tan poco al Modelo Relacional que nadie se había planteado usarlo para algo más que para hacer dibujitos para las presentaciones.
No obstante, tal como están las cosas, y poniéndome en las botas de Microsoft, no creo que tengan muchas más opciones que hacer que el EF funcione.
Pero es imposible que llegue a funcionar bien, igual que es imposible que Velneo o Deklarit lleguen a funcionar bien.
Al final le echarán la culpa a las manchas solares y sacarán cualquier otra tontería y vuelta a empezar. Ya lo hemos visto muchas veces.
SIN TENER NI IDEA DE TECNOLOGÍA más allá de la propia herramienta que utilice
Uno se abstrae de algo concreto cuando existen alternativas reales a ese algo concreto. ¿Cuáles son las alternativas tecnológicas a las bases de datos relacionales?
Y conste que no creo/descreo en todo lo que Alfredo cree/descree.
Ahora mismo estoy programando un proyecto que es una pesadilla: me obligan a trabajar contra Oracle con una mano atada a la espalda... con el noble propósito de la "portabilidad".
Claro, que a renglón seguido, cuando me cago en el hideputa de Oracle que inventó determinada característica que funciona de pena, siempre hay un vigilante de la empresa que me reprocha mi pobre adaptación a la realidad (estoy clasificado localmente como "genio chiflado", y como se sabe, estos suelen ser gente poco realistas) porque "nuestro cliente tiene y tendrá Oracle, y hay que adaptarse a esa realidad".
Pero volviendo al caso: las alternativas reales a las bases de datos relacionales son, hoy por hoy, inexistentes. Y esto no lo dice el autor de un par de libros de programación que podían haber sido escritos por cualquiera, sino alguien que ha estado investigando seriamente, en su momento, sobre teoría y práctica de las bases de datos orientadas a objetos.
Esos servicios tienen una entrada y una salida, que pueden ser xml , txt o lo que quieras , pero tiene que ser un estandar global, para que se puede facilitar la gestión por parte de las herramientas.
Ese era el espiritu de los WebServices que se vendió en su día y que me parece genial.
Lo que fracasó ya y no digo que no vuelva como todo es el ENTORNO CONECTADO, A VER SI ME EXPLICO YA !!
yo lo que digo es que hay que hacer herramientas que se abstrigan de los campos y tablas y consultas y todo lo que tenga q ver con programación
¡Pero eso son las aplicaciones!
Y para desarrollar aplicaciones necesitamos herramientas que nos abstraigan de las bases de datos, y esas herramientas son: Oracle, SQL Server y compañía. Esto es lo que mucha gente no entiende.
NOOOO también pueden ser los servicios!!!
¿Cuáles son las alternativas tecnológicas a las bases de datos relacionales?
Bueno, lo que yo "creo" es que las bases de datos relacionales son la alternativa tecnológica a las bases de datos SQL :-)
Respecto a lo de Oracle, pues menuda contradicción que por un lado pidan portabilidad y por otro digan que el cliente usa y va a usar Oracle.
Si el cliente usa y va a usar siempre Oracle pues a la porra con la portabilidad.
NOOOO también pueden ser los servicios!!!
¿Servicios telepáticos?
Los gurus que te vigilan para que no te salgas del carril no son nada comparados con aquellos que te vigilan que no te salgas del proceso, en mi caso CMMI.
CMMI
¡Dios! Tiene pinta de ser doloroso. Acabas de lograr que me sienta afortunado...
Alfredo (off topic): el día que me apunte a AdSense o algo parecido para sacarle dinero al blog, voy a tener la obligación moral de compartir los beneficios contigo :)
el día que me apunte a AdSense o algo parecido para sacarle dinero al blog, voy a tener la obligación moral de compartir los beneficios contigo :)
¡Que va! :-)
Lo que pasa es que este es casi el único blog de programación que conozco que vale la pena seguir y que se actualiza regularmente.
Por eso doy tanto la lata :-)
Y para responder a Daniel, ya hemos hablado aquí de Genexus y a mi me parece que es un juguete del estilo del Velneo o del gsBase. Es decir, algo con lo que no perder ni un minuto.
y será que vale la pena perder mas de um minuto perfeccionandose em Delphi?
Lo digo porque ya tengo ciertos conocimientos de Delphi, pero me gustaria perfeccionarme mas em alguna herramienta.
Lo digo porque ya tengo ciertos conocimientos de Delphi, pero me gustaria perfeccionarme mas em alguna herramienta.
Lee mucho, es todo lo que puedo recomendarte, Yo estoy lyendo un libro de WPF, de ahì me voy a leer uno de ASP.Net y de uno de linq.
Y ademas ya me leí un libro de WCF dos libros de smartclient y te recomiendo uno que se llama "Code Clean", de Delphi me leí casi todos los de Marco Cantú y hasta la Cara Oculta de Delphi 6 que mando pedír un compañero desde España.
Si te sobra al menos media hora de tu tiempo al día, la mejor inversión es leer.
Si te sobra al menos media hora de tu tiempo al día, la mejor inversión es leer.
Pero también hay que leer cosas más serias.
Es más, yo creo que a la prensa de mercado hay que dedicarle el mínimo tiempo posible, y solo sirve para conocer detalles técnicos.
El origen de muchos problemas de la informática es que mucha gente pretende formarse leyendo exclusivamente ese tipo de libros que están plagados de errores.
Y a su vez los que escriben esos libros normalmente solo leen libros parecidos, con lo que se crean círculos viciosos porque apenas existen controles de calidad en lo que se publica.
Alfredo será que puedes recomendarnos algunos libros?
Actualmente estoy leyendo uno de banco de datos de C.J. Date.
La lectura es medio pesada, pero da una excelente vision del asunto.
Ramsees: si hubieses pedido La Cara Oculta de primero, te habrías ahorrado una pasta.
Yo en lo particular aprendí Delphi gracias a los libros de Ian, primero leí la Cara Oculta de Delphi 4 luego La Cara Oculta de Delphi 6, también compre el Curso de Delphi 6 ahora estoy con el curso de C#. Con la literatura ofrecida por Ian he tenido más que suficiente para aprender.
Ahora que si Alfredo puede recomendarme algunos libros se lo agradecería.
Yo tambien me lei la cara oculta de delphi 4 y aprendi muchas cosas, que las aplico todos los dias em mi trabajo.
Tambien me compre el curso de C# de Ian. Solo falta que me llegue el libro por correo.
Queria comprarme la cara oculta de delphi 6, porque me gusta mucho el deplhi, pero como van las cosas con la herramienta, no sé si vale la pena...
Si en el mercado de los libros existiera un estandar de publicación para que sus autores escriban cosas bien argumentadas y que realmente resuelvan los problemas que se nos presentan a los que decidimos ganarnos el pan con la programación existieran en el mercado muy pocos libros y entre esos pocos estarian los de Ian (Claro si los que hacen el estandar no son los mismos que hacen los libros desechables).
Sabiendo que contamos con herramientas con muchos problemas y nadie se decide a hacer las herramientas perfectas o mejor dicho no hay tantas mentes prodigias para hacerlas, lo que tenemos que hacer es tratar de utilizar lo que sirve de ellas y dejar lo que no. y seguir insistiendo para que los que hacen las herramientas entiendan las necesidades que tenemos, tal vez asi algun dia le llegará un rayo de luz que los ayude a perfeccionar lo que hacen. Si hubieran más autores que entendieran esta parte como la entiende IAN avanzariamos mucho más.
Tambien hay muchas diferencias entre lo ideal que plantean los libros teoricos como ejemplo los de BD y las herramientas que existen en el mercado para plasmarlas correctamente esas reglas. Al parecer es más facil escribir las reglas a las que deben apegarse los SGBD, pero ya que escribieron las reglas por que no hacen ellos mismos un SGBD que las cumpla y además si la hacen por que no crean las herrientas para trabajar en las aplicaciones cliente sin la llamada impedance mismatch.
pero como van las cosas con la herramienta, no sé si vale la pena
No, no creo que te merezca la pena... :) sobre todo porque en el pack te he puesto el CD con los cursos de Delphi. No tiene la misma organización que un libro, pero la información es mucho más exhaustiva: en un curso puedes poner detalles que no caben en un libro. Por ejemplo, la solución a un bug que esperas que desaparezca en la siguiente versión.
Más te va a servir el libro de Marco Antonio Santín, que se ocupa precisamente del lenguaje (Delphi Prism).
Nota: perdonad que vaya contestando a ráfagas (Al: no te he pasado por alto). Es que estoy a tiempo completo con un maldito proyecto con el maldito Oracle y voy justísimo de tiempo.
Estimado Sr. Alfredo Novoa, la verdad que tildar de "juguete" a Genexus, le quita credibilidad a sus otros comentarios. Por lo que lo leo en este foro, parece una persona que sabe mucho de los temas que aca se tocan. Sin embargo en lo que solo toca de oido, ya que ni conoce la ultima version del producto, no se le mueve un pelo en calificarlo despectivamente o compararlo con otros productos que estan a años luz.
Ahora se me planteo la duda, de todo lo otro que expresa con tanto convencimiento.
No lo tome como un ataque a este comentario, solo un aporte.
Daniel, he mirado lo de Genexus hace un mes más o menos por que alguien tambíen lo recomendó aquí sin haberlo utilizado, y después de tener que mirar un montón de palabrería muy poco técnica me quedó claro que es un sistema muy primitivo tipo PICK. No creo que compararlo con gsBase y Velneo sea muy desacertado.
"Sobre todo porque en el pack te he puesto el CD con los cursos de Delphi. No tiene la misma organización que un libro, pero la información es mucho más exhaustiva"
Pero si comparas muchos libros que se refieren a los mismos temas comparados con los de la cara oculta ves que existe un toque más acabado y realmente aplicable.
Aunque no estoy estoy tirando por el suelo esos libros reconozco que tienen mucha información pero en muchos de ellos la información importante es como buscar en el MSDN version reducida.
Libros buenos hay muchos, depende de lo que te interese, pero está claro que hay que conocer a los clásicos como: Dijkstra, Knuth, Tanenbaum, Norvig, Aho, Ullman, Date, etc.
Por ejemplo el libro que usan en el MIT como introducción a la ciencia informática es este:
http://mitpress.mit.edu/sicp/
Y está muy bien para introducirse en la programación funcional.
En Amazon hay listas de libros recomendados para cualquier tema como Inteligencia Artificial, videojuegos, Sistemas Operativos, etc.
Ya que estamos hablando de bases de datos, para comprender bien el modelo relacional es prácticamente imprescindible leer a Date o a los de su banda como está haciendo Eduardo. "Databases Types and the Relational Model The Third Manifesto" es un libro duro de leer pero es el que mejor trata la integración de la OO con el Modelo Relacional.
Además de esto viene bien leer libros sobre teoría de los lenguajes de programación y teoría de tipos como por ejemplo "Concepts of Programming Languages" de Sebesta o "Essentials of Programming Languages".
Lo que quería decir es que no se llega muy lejos leyendo solamente libros escritos por los fabricantes o personas afines. Así solo llegas a donde el fabricante quiere que llegues.
pero ya que escribieron las reglas por que no hacen ellos mismos un SGBD que las cumpla
Porque lo que les gusta y lo que saben hacer es escribir las reglas y no los SGBD :-)
Y tienen pasta suficiente para hacer solo lo que les gusta.
Los que les gusta escribir SGBD pero no saben tanto de las reglas les deberían de hacer más caso.
Esos libros que mencionas son excelentes se refieren más a como deberian ser las herramientas y eso es bueno. Pero tambien debemos diferenciar entre programadores de sistema y de aplicación. Me gustaría ser programador de sistema pero las condiciones de mi país no me lo permiten.
bueno de todas formas el saber no pesa es bueno estudiarlas.
Junior, es necesario saber lo que deben de hacer las herramientas para poder hacerlo nosotros cuando las herramientas no lo facilitan.
Los programadores de gestión deben de saber de sistemas y los de sistemas de gestión. Una de las razones por la que las herramientas son tan malas es por que los programadores de sistemas raramente han visto un sistema de gestión real en su vida.
Y por supuesto tampoco digo que los libros de los fabricantes no tengan su utilidad, pero hay que desconfiar mucho de todo lo que digan que no sean especificaciones de los productos. Por ejemplo las guías de buenas prácticas de M$ son de llorar.
Estoy de acuerdo contigo, pero los que desarrollan las herramientas que usamos no realizan una documentación muy profunda que describa a fondo lo que hacen, para asi poderlas extender su funcionabilidad.
Siempre tenemos que recurrir a realizar prueba y error o a otros que ya han pasado por la experiencia.
Aunque dominemos de fondo las reglas creadas y claro que nos facilitará mucho en las mejoras que podamos hacer a estas herramientas tendriamos el problema que no estan documentadas las cosas realmente importantes para mejorarlas. y solo ellos saben las chapuzas que hay que no se apegan a esas reglas.
Coincido con la con la opinión de que debemos crear nosotros las herramientas para poder poner en practica esos libros.
Alfredo Novoa dijo...
"Por cierto, yo estoy pensando seriamente en pasarme a Silverlight para casi todo."
Vaya Alfredo te gusta sufrir, igual eso va en contra de todo lo que te leo.
Buena suerte con Silverlight.
El tema de documentación eso hay de todo:
1. MSDN de cada 100 tips/tricks solo unas pocas funcionan realmente, hay gente que publicó ahi pura basura. Igual hay otras cosas que si van a lo que es. Por ejemplo me pasó queriendo generar ItemTemplates programaticamente, funcionó como Dios manda: http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.templatefield.templatefield.aspx
2. Hay lecturas Microsoft muy buenas: http://msdn.microsoft.com/en-us/architecture/dd393308.aspx
Hay llamada a artículos, por qué no demuestran todo su conocimiento ahi a ver cómo les va?
3. En general hay algunas guías de P&P (patterns & practices) que vale la pena revisar, al menos dan una aproximación a muchas cosas. En mí caso me pasa con Sharepoint, plataforma compleja de Microsoft, pero esa guía sirve de algo:
http://msdn.microsoft.com/en-us/library/dd203468.aspx
Por qué no se sientan a documentar algo así a ver cómo les va?
En fin toca adaptarse a las tecnologías y claro tener buena documentación, y además de las joyas de libros de IAN no esta demás:
- Dino Esposito
- Andrew Whitechapel
- Jeff Prosise
- Blog de Scott Guthrie
Entre otros
No recomiendo los libros de examenes de certificación de la Press, esos libros si son un desperdicio de dinero. Aunque hasta la versión 1.1 del Framework realmente me sirvieron para completar el % del examén en la parte teórica, los de la versión 2.0 si fueron decepcionante.
Un abrazo
Junior, lo que quería decir es que los que desarrollan herramientas no saben lo que necesitamos los que desarrollamos aplicaciones y cuando te sales de los ejemplos de los manuales ves que las cosas no van nada bien.
Andrés, no me gusta nada sufrir y Silverlight me quita bastante peso de encima por que así no tengo que tocar los ordenadores de los clientes para nada y ya no me preocupo de que me pirateen los programas ni de que me echen la culpa de los virus que pillan mirando vete a saber que páginas (casos reales).
A veces tengo problemas para vender software por que el cliente no tiene un servidor en condiciones y entonces hay que comprarlo y comprar el Windows 2003 y montarlo y administrarlo y acaban pagándole a los HP y M$ mucho más que a mí, si es que no se echan atrás.
Windows Forms tiene muy poco futuro y con Silverlight 3.0 me apaño y no necesito todo el WPF y me ahorro los problemas de la gente que no tiene el .Net actualizado.
Yo creo que las RIA tienen mucho potencial y cuanto antes me ponga con ellas mejor.
Yo no uso ADO.NET para nada en los clientes, así que cambiar desde WinForms a Silverlight es bastante sencillo para mí.
De seguro en españa la conexion de internet es muy estable, pero en paises sub-desarrollados las aplicaciones RIA aunque existen no son tantas y tenemos windows Form por algun tiempo. Claro que se puede instalar un servidor web para utilizarlas pero seguimos teniendo el mismo problema de instalar el servidor.
las alternativas reales a las bases de datos relacionales son, hoy por hoy, inexistentes
Retomando esas palabras, preguntales a los Maqueros(Mac)por que su SGBD (FileMaker Pro)supero ya hace mucho tiempo eso de los sistemas relacionales.
en la siguiente pagina asi lo expresan
http://www.elprofesionaldelainformacion.com/contenidos/1998/junio/filemaker_sistema_hibrido_de_gestion_de_bases_de_datos_con_integracion_de_tecnologia_web.html
Relacional
Cabe señalar que FileMaker no es un sistema relacional. Por lo menos no lo es en el sentido matemático del término -sentido que es el generalmente aceptado, tanto en la bibliografía técnica sobre el tema, como el que adoptan mayoritariamente los grandes fabricantes de bases de datos del mercado (Macleod, 1991; Gardarin, 1994; Codina, 1994)-.
Pero filemaker a mi me parece algo como fox versión apple, parece de jugete tambien. segun los de mac lo mejor que existe.
Junior, por lo que parece FileMaker no es más que un sistema relacional capado como DBase y Access. Si un maquero dice que eso es lo mejor que hay simplemente es que no tiene ni idea.
Lo que pasa es que este es casi el único blog de programación que conozco que vale la pena seguir y que se actualiza regularmente.
De verdad que he aprendindo muchas cosas leyendo este blog y los comentarios.
Creo que todos los días paso por aqui.
Hay mucha desinformación por todas partes y es difícil orientarse.
Em la empresa donde trabajo utilizamos Delphi e Sql Server, pero el paraíso de todos mis companeros seria trabajar com Java e Hibernate.
Por lo que tengo entendido estas herramientas no son las óptimas para desarrollar sistemas como ERP, sistemas de contabilidad, etc.
Estoy correcto o equivocado???
Creo que todos los días paso por aqui.
Es más cómodo usar un agregador de noticias :-)
Por lo que tengo entendido estas herramientas no son las óptimas para desarrollar sistemas como ERP, sistemas de contabilidad, etc.
Java con JDBC o algo parecido tampoco tiene mucho problema si dispones de buenos controles visuales.
Pero Hibernate está específicamente "diseñado" para hacer el mal :-)
Yo no creo que el .net sea malo, el C# es bueno , es un lenguaje limpio entendible elegante,facil de aprender, creo que el problema del .net esta en el acceso a datos,en mi caso los problemas son de velocidad , y el soporte a procedimientos almacenados del EF, 90% de mis reportes son construidos por PA en la base de datos,aqi en mi Pais el FoxPro era el lenguaje mas usado , todos los programadores de FoxPro se pasan a Delphi en este momento y los de Delphi al C#, en mi caso en mi empresa me toca mantener todavia el ERP en delphi, me cuesta conseguir programadores en C#, como pregunte varias veces inclusive en los foros de Microsoft y nadie me sabe responder, Navision2009, Solomon2009, GP2009 todo es win32, nada .net por que esto ,microsoft deberia promocionar el uso de su propia plataforma en sus productos,no me gusta la programacion usando objetos de negocios , pero lamentablemente lo mas practico , rapido y facil que e encontrado es XPO de Devexpress,en cuanto a lo N-tier lo que necesito es un sistema que se puede conectar desde otra ciudad usando VPN pues el tipo de cliente mio necesita facturacion OnLine no puede ser replicada,entonces me obliga a desarrollar un sistema distribuido, igual problema tengo que el de Ian , tengo que trabajar con sqlserver y oracle, he usado firebird por un tiempo me parece bueno pero el tipode cliente mio no quiere nada open tienen miedo a esa tecnologia a pesar de ser muy usada, Delphi + Oracle es lo mejor que he visto hasta ahora, con Componentes Nativos para Oracle y remoteObj en ves del DataSnap, el principal tema con microsoft es que lanza tecnologia nueva muy rapido y todo lo que lanza es de experimento , el ejemplo vivo es el Vista ni bien salio ya le menten Windows 7, es preocupante pq no nos deja actualizarnos en una tecnologia la cambian por una mejor y todo lo que gastaste(USS + tiempo) practicamente no te sirve, ya con delphi , puedes usar 4,5,6,7, hasta 2009 sim problemas de compatibilidad, lamentablemente el futuro indiscutible sera el .net ho hoy , pero dentro de 3 años mas no nos quedara otra, son tiempos dificiles para nosotros , tenemos que tomar decisiones dificiles, con herramientas dificiles y un soporte y ayuda dificil, por eso es que siempre estoy pendiente de las palabras de Ian por que siempre ha sido mi punto de referencia en el desarrollo de software, si microsoft tubiera alguien como el trabajando en el acceso a datos seria la solucion definitiva a nuestras dudas
Buenos días amigos, se me presentó una duda en estos días acerca del buen uso de las trigger.
No sé si este es el lugar adecuado para exponer mi duda. Si no lo es me disculpen y me indiquen el lugar cierto por favor.
Es lo siguiente, en la empresa donde trabajo tenemos varios sistemas de logística, donde la entrada de datos se hace de forma manual(por ejemplo, cuando um camion esta cargando, se especifica el lugar de carga, el tiempo que demoró, etc).
Ahora comenzamos a trabajar con rastreadores, entonces consumimos un webservice que nos indica las posiciones de los camiones, etc y colocamos esos datos en unas tablas genéricas donde cae la información de qualquier vehiculo, independiente de cual sistema logistico vaya a utilizar.
Ahora viene mi duda, estan utilizando triggers en esas tablas genericas para alimentar las tablas de nuestros sistemas especificos (Simular entrada de datos automática).
Eso esta correcto ??. Las trigger tienen esa finalidad??
O es mejor hacer programas que se ejecutem em threads, y lean los datos de las tablas genericas y simulen la entrada de datos automatica en los sistemas logísticos ?
Gracias por su ayuda...
¿Porque Microsoft todavía no ha contratado a Ian...? Supongo que Ian no le ha mandado el curriculum a Bill, a mi ese tal Anders Hejlsberg no me crea confianza, y encima no escribe ni cursos ni libros en español. Ian anímate y sustituye ya a ese tío que no nos aporta nada, jaja.
¿Porque Microsoft todavía no ha contratado a Ian...?
...por lo que veo también Alfredo debería estar contratado.
Esto ya lo hemos comentado más veces. Las empresas como M$ no son buenas contratando gente y la poca gente que tienen que sabe algo de bases de datos normalmente tiene muy poco poder para cambiar las cosas. Yo conozco a gente que trabajó en Redmond y que se sabe muy bien estas cosas pero que no pudo hacer nada para hacer entrar en razón a la mayoría.
Además Redmond me queda bastante a desmano :-)
A mi me parece que no solo es por que se encuentren personas capaces de hacer el cambio, de seguro que en microsoft las hay, pero al no ser muchas no se ve el efecto al estar siempre en contradicion con los tantos que no comprenden como deberian ser las cosas. En un mundo perfecto solo estarían ahi personas capaces o en su mayoria.
Ese fenomeno es como un patron en las empresas grandes siempre hay personas que se identifican mas con los proyectos que otras y siempre hay contradiciones más en nuestro ambiente informatico. Por lo menos en microsoft todos estan de acuerdo en usar el mismo sistema operativo. En otras empresas donde ahí fanaticos de MacOS, Linux, Windows y otros puede ser peor.
Si M$ hiciera cosas que funcionaran siempre bien, se acabaría el chollo de la informática.
En Mayo de 2008 estuve en una ponencia de D. Mario Piattini Velthuis que decía que la diferencia de productividad de un desarrollador a otro puede ser hasta 100 a 1(aunque nadie le pagaba a un programador 100 veces más que a otro).
Esta es la parte positiva, el buen programador se puede DESTACAR!!
"Si la industria automovilística fuera como la informática, harían coches que correrían 1.000 por hora y costarían 500 euros, aunque explotarían una vez al año destruyendo a todo aquel que estuviera dentro"
Redman, depende de en donde caigas. En muchas empresas se intenta estandarizar, y eso siempre es hacia abajo. Se organiza el trabajo de tal forma que hasta un simio pueda hacerlo, y por muy bueno que seas no vas a destacar mucho, y si aun así destacas mucho te pueden pedir que dejes de hacerlo por que dejas en mal lugar a los demás.
Y cuanto más atrasado está el país más pasa esto.
En Estados Unidos hay muchos programadores senior de elite, y "arquitectos" que también dedican una buena parte de sus horas a escribir código, pero en España si "todavía" escribes código a los 35, te ven como un fracasado.
Supongo que Ian no le ha mandado el curriculum a BillEfectivamente. Hace poco se abrió una convocatoria para plazas en el equipo del compilador de C# y ni me molesté. Pero no por las razones insinuadas: soy asmático, y Redmond tiene un clima puñetero. Es la misma razón por la que no me he ido a la Gran Bretaña y sigo sufriendo por aquí.
Respecto a Microsoft Ibérica, creo que no necesito explicarme...
pero en España si "todavía" escribes código a los 35Exacto. A mí me están pagando ahora mismo por hacer de "power programmer". Es decir, me pagan una pasta para hacer lo que no logran conseguir de sus programadores. Pero me obligan a permanecer apartado del diseño de las aplicaciones. De hecho, ¡consideran que mis "diseños" son malos! Las razones para esto último son de risa: un peculiar gusto estético, una filosofía de aplicaciones tipo "blackboard" (todo vale, pero las operaciones cotidianas deben realizarse casi manualmente, no hay automatización del flujo de trabajo... es decir, el típico diseño de aplicaciones de gente que no tiene ni puñetera idea de Informática), un absoluto desconocimiento de los pros y contras de las interfaces gráficas en Windows (no se aclaran con las aplicaciones MDI, por ejemplo).
Por cosas como estas es que somos un país tan "avanzado" en Informática, y por eso los programadores españoles triunfan... cuando se van a trabajar a empresas extranjeras o logran independizarse de la panda de palurdos e ineptos que mueven la pasta en estos sitios.
Al parecer es como proyectos que he visto que abusan de las ventanas modales y todo lo hacen asi.
Lo más incomodo es tener una aplicación que solo se puede tener una ventana abierta, aunque hay ocaciones que es obligatorio pero es bueno saber cuando se puede y cuando no.
(todo vale, pero las operaciones cotidianas deben realizarse casi manualmente, no hay automatización del flujo de trabajo... A esto me refería con lo de organizar el trabajo para que puedan hacerlo simios.
Se hace todo a pedal a base de utilizar mucha mano de obra. Así creen que pueden contratar a cualquiera por 1000€ para que haga el trabajo y reemplazarlo fácilmente cuando se harte.
Hola Alfredo,
¿Por qué dices que:
Pero Hibernate está específicamente "diseñado" para hacer el mal :-)
????
Nosotros en nuestra empresa la gran mayoría de las aplicaciones las desarrollamos utilizando Eclipse con Java, Spring, Hibernate y ExtJS. Con una herramienta casera interna, generamos con unos cuantos clicks la mayoría los objetos de dominio, los objetos de transferencia de datos y los archivos de definición de los grids y formas de ExtJS. De ahi, ya agregamos de manera manual las reglas de negocio y el resto de las formas de procesos.
Para la base de datos, no nos interesa que le estén pagando a Microsoft, Oracle o el que sea, por eso básicamente le proponemos al cliente PostgreSQL ó MySQL.
Para el servidor, Linux ó FreeBSD de 64 bits, Java de 64 bits y ya quisieran la gente de Microsoft alcanzar esos rendimientos.
Sobre la eficiencia, con las herramientas internas que nos hemos hecho es bastante alta.
Con una herramienta casera interna, generamos con unos cuantos clicks la mayoría los objetos de dominio, ... De ahi, ya agregamos de manera manual las reglas de negocio
Pues a esto me refiero con lo de hacer el mal.
Hibernate sirve para ayudar a gestionar los datos en las aplicaciones usando redes de objetos en memoria usando el SGBD como un simple sistema de almacenamiento.
Si haces las cosas bien entonces Hibernate no te sirve para nada y Spring tampoco para mucho.
Y MySQL es muy flojo (no soporta ni CTEs, corregidme si me equivoco), pero claro si solo lo vas a usar para almacenar registros entonces no te enteras.
Hola Alfredo,
Definitivamente el mundo está muy lejos de ser perfecto. Y además la relatividad está presente en todo y para todos. Lo que para un problema pudiera ser una solución perfecto, para otro problema pudiera no ser lo mejor.
A nosotros Spring si nos sirve mucho. A lo mejor hay personas que no utilizan MVC, pero nosotros si lo utilizamos y con buenos resultados.
Tampoco nos gusta meter lógica en la base de datos porque nos volvemos dependientes de esa base de datos y tenemos que estar reescribiendo o buscando otra forma de hacer las cosas porque la base de datos A soporta ciertas caracteristicas que la B no lo soporta. Por eso preferimos meter la lógica en el servidor de aplicaciones. Que no aprovechamos la potencia del manejador de base de datos y utilizamos solo la capacidad de almacenar registros, eso es cierto, pero el sacrificio lo hacemos para lograr portabilidad e independencia. Como dije en el post anterior a nosotros no nos interesa que el usuario esté gastando dinero pagando por Oracle o SQL Server y que el costo del licenciamiento haga que no se pueda desarrollar el proyecto o que lo que tengamos hecho para una base de datos no nos sirva porque el cliente quiere utilizar la base de datos que ya tiene.
Como tu crees que pudieramos evaluar por ejemplo a la gente de Google que en su implementación utilizan un concepto de BigTable que no tiene nada que ver con el modelo E/R, no soporta joins, no soporta querys y logra unos niveles de escalabilidad que deja atrás a las bases de datos comerciales.
Estará bién la solución de Google? Para lo que hacen ellos, probablemente no haya muchas soluciones mejores, pero para una aplicación de una Pyme donde se conectan 10 usuarios probablemente no sea lo adecuado.
Y además la relatividad está presente en todo y para todos.
Esto es una falacia que normalmente se usa para intentar hacer creer que todo vale por muy mal que esté.
Tampoco nos gusta meter lógica en la base de datos
Seguramente esta es una de las principales razones por las que os gusta Spring.
porque nos volvemos dependientes de esa base de datos
Querrás decir que os volveis dependientes de ese SGBD.
Es una excusa muy pobre para volver a la prehistoria y tener que trabajar muchísimo más y muy probablemente obtener resultados mucho peores.
Además si no metes toda la lógica de negocio en la base de datos entonces te haces más dependiente del lenguaje de programación de aplicaciones y multiplicas la cantidad de código.
a base de datos A soporta ciertas caracteristicas que la B no lo soporta.
Dime alguna que no soporte PostgreSQL. MySQL simplemente no sirve para aplicaciones de gestión.
Que no aprovechamos la potencia del manejador de base de datos y utilizamos solo la capacidad de almacenar registros, eso es cierto, pero el sacrificio lo hacemos para lograr portabilidad e independencia.
Pues o vuestras reglas de negocio son muy muy sencillas o estais sacrificando meses para ganar días.
Prácticamente siempre compensa adaptar el código SQL a otro dialecto en el caso de tener que cambiar de SGBD, en lugar de la monstruosidad de implementar las reglas de negocio en Java y similares.
Además yo también logro más independencia de C# cuando implemento toda la lógica de negocio en la base de datos.
Y mucha gente pone la excusa esa de la independencia del SGBD en proyectos en los que no hay ninguna probabilidad de cambiar de SGBD y muchas probabilidades de cambiar de lenguaje de programación. Yo conozco proyectos que pasaron de Visual Basic a Delphi y de Delphi a Java y que nunca dejaron de usar Oracle.
Como dije en el post anterior a nosotros no nos interesa que el usuario esté gastando dinero pagando por Oracle o SQL Server y que el costo del licenciamiento haga que no se pueda desarrollar el proyecto o que lo que tengamos hecho para una base de datos no nos sirva porque el cliente quiere utilizar la base de datos que ya tiene.
Pero seguramente si interese tardar el triple por no hacer las cosas bien y que el cliente al final acabe pagando muchos miles de euros más que si se hubiese comprado SQL Server y se hubiesen hecho las cosas bien.
Además con PostgreSQL se pueden implementar las reglas de negocio perfectamente.
Estará bién la solución de Google?
Es una solución muy primitiva, pero no les servía ningún producto del mercado, y desde luego sería muchísimo mejor y podrían hacer muchas más cosas si tuviesen un SGBD relacional igual de escalable como dice estar haciendo M$.
Las bases de datos que usa Google son muy sencillas, y aun así les tiene que costar un montón gestionarlas con esa cosa.
No me extrañaría que en Google existiesen 500 programadores por tabla, cuando en mi empresa la relación es más o menos al revés.
El Google App Engine no sirve para aplicaciones empresariales. Será muy escalable pero está terriblemente limitado.
Desde luego no tiene nada que hacer contra SQL Server Data Services cuando lo hagan por lo menos un poco relacional.
Publicar un comentario
<< Home