miércoles, abril 15, 2009

Una decepción y un rayo de esperanza

La decepción

Apartaos de este libro cuanto podáis: Essential LINQ (Microsoft .NET Development Series). Ni se me ocurriría comprar un libro de Calvert (ya he tenido la mala experiencia), pero pensé que al estar Dinesh Kulkarni en el potaje, la cosa cambiaría. ¡Qué error!:
  • Las dos terceras partes del libro son las típicas obviedades sobre LINQ for Objects que puede encontrar en Intuitive C# gratuitamente, o en el libro de Octavio sobre LINQ por una fracción del precio. Es el tipo de énfasis que hace un autor que odia las bases de datos y sólo le interesa hacer trinos y gorgoritos con el lenguaje.
  • El contenido sobre LINQ to SQL (un sistema ya condenado) es el doble o el triple (me niego a contar páginas) que el contenido sobre el Entity Framework.
  • ... pero ni siquiera el contenido sobre LINQ to SQL es medianamente funcional, así que ya puede imaginar lo que hay sobre el EF.
  • Charlie Calvert nos obsequia con sus mañas características de escritor: apéndices sobre todo lo humano y divino (para engordar el libro y encarecerlo), incluyendo una tabla de seis páginas sobre los atajos de teclados en Visual Studio 2008 (que usted puede encontrar perfectamente en la ayuda de VS).

El rayo de esperanza

Este otro libro, Programming Entity Framework, de Julia Lerman, es harina de otro costal. Para empezar, tiene 792 páginas con un tipo de letra legible, pero compacto. Nada de trucos sucios para engordar artificialmente el contenido.
En segundo lugar, se tratan todos los temas necesarios: ESQL, los puñeteros formatos de bajo nivel para crear un esquema conceptual y mapearlo a una base de datos, el uso avanzado de procedimientos almacenados, los problemas actuales al intentar trabajar en múltiples capas (¡sinceridad, por una vez en la vida!), cómo usar EF desde ASP.NET y Windows Forms, y los problemas y soluciones en cada plataforma...
Además, y esto es muy importante, la autora escribe bien. No he terminado el libro, y me va a llevar un par de semanas, pero hasta donde he llegado, me siento satisfecho.

Etiquetas: , , ,

210 Comments:

Blogger Unknown said...

Hola Ian, una pregunta...has leido el libro de Unai,Octavio y Eduardo sobre entity framework. Lo recomiendas?..

Gracias

miércoles, abril 15, 2009 10:59:00 p. m.  
Blogger Ian Marteens said...

No, no lo he leído. Tratándose de esa gente, de todos modos, es imposible que saquen un libro "deshonesto": puede ser mejor o peor, en dependencia de la información de la que dispongan en ese momento y del estado de la herramienta, pero seguro que es el mejor libro que se pueda escribir en esas condiciones.

jueves, abril 16, 2009 1:11:00 a. m.  
Blogger Andrés Ortíz said...

Ian que esperas de Charlie Calvert, si es el mismo que estas mencionando, ¿acaso no sabes su papel en Microsoft?, es de esos de pura diversión y claro escribir un libro para él es simplemente una de sus tareas más. Solo miren el blog, él se la pasa es jugando con pequeñas tonterias de cada cosa que saca Microsoft:

http://blogs.msdn.com/charlie/

Debería darle verguenza ante las entradas del señor Scott Guthrie, además de liderar los grupos más importantes dentro de MS tiene tiempo para escribir sendos ejemplos, demasiado buenos para el que quiere arrancar desde cero con las cosas nuevas de MS.

Un abrazo
http://dotnetsofi.blogspot.com

jueves, abril 16, 2009 5:13:00 a. m.  
Blogger Manuel said...

Mi autor favorito es Ian Marteens, alguien sabe si esta escribiendo "La nueva cara de C#", "La cara oculta de ASP.net", me parece raro, hace mucho tiempo desde La cara oculta de C#,... Por cierto esto de Linq + EF tiene futuro, o va a pasar como con ECO en Delphi?

jueves, abril 16, 2009 9:13:00 a. m.  
Blogger Daniel said...

Alguien ha leido el libro "Programacion Microsoft ASP.NET 3.5" de Dino esposito? Que les parece?
Ante la falta de nuevos libros de Ian y por una recomendacion suya del libro anterior de ete autor, me veo tentado a comprarlo, pero es bastante oneroso para las economias de Argentina, algo asi como 100 euros, que para nosotros es una pequeña fortuna :)
Una saludo desde el fin del mundo.

jueves, abril 16, 2009 1:51:00 p. m.  
Blogger Alfredo Novoa said...

Para empezar, tiene 792 páginas con un tipo de letra legible, pero compacto.Supongo que será restándole las páginas en blanco por que me acabo de bajar la "versión de evaluación" ahora mismo y tiene 832.

crear un esquema conceptual y mapearlo a una base de datosSupongo que con lo de "mapearlo" te refieres a asociarlo.

Lo he mirado casi entero en unos minutos, y olvidando todas las tonterías que dice en la introducción, el libro cumple su propósito de describir el disparatado EF.

Lo que más me ha llamado la atención es el capítulo de "Using your own custom classes".

Sospecho que la mayoría de la gente va a tirar por ahí y se va a añadir una nueva capa superflua a las aplicaciones.

Al final del libro también menciona a Oslo, que es uno de los últimos desvaríos de M$.

Yo creo que hay que buscar soluciones sencillas y huir de quienes necesitan 800 páginas para enseñarte como asociar un par de grids a un par de tablas y aun encima reconociendo un montón de limitaciones. No creo que sea muy buena idea seguir a M$ en la espiral de locura en la que se ha metido en los últimos años.

jueves, abril 16, 2009 2:04:00 p. m.  
Blogger Andrés Ortíz said...

"Alguien ha leido el libro "Programacion Microsoft ASP.NET 3.5" de Dino esposito? Que les parece?"

Amigo pues el señor Dino es muy buen escritor y se mantiene muy actualizado y habla de cosas sobre cada tecnología que muy pocos tocan, por ejemplo sus entradas en MSDN sobre arquitectura en Silverlight va muy bien. Me encantaba leerlo en DotnetManía, ahi da unos consejos muy desde la realidad.

Pero mi punto de vista con respecto a libros de ASP.NET es que mejor no gastes tú dinero. No porque unos sean malos u otros excelentes, el punto es que es practicamente una perdida de 100euros que podrías invertir en algo que te permita crecer más en aspectos conceptuales en lugar de algo tan técnico que finalmente terminas es remitiendote a los N-mil Blogs que encuentras en internet sobre ASP.NET. Si tú quieres estar actualizado sobre ASP.NET 3.5 pues leete la ayuda de MSDN, creo que es muy completa y al final te guia a artículos y entradas de gente muy experta.

Es mi humilde opinión, lo mismo me pasa con libros de Silverlight, aunque ese engendro si que peor, ya que aun eso no es estable.

Lo que siempre me llamó la atención de IAN en la Cara oculta de CPPB 4 era que además del aspecto técnico comentaba sobre la tecnología y las buenas desiciones de una manera amena, así que al final eso es lo que más me llama la atención y se t queda grabado, los aspectos técnicos de cada libro al final están ahi afuera toca es irlos encontrando a medida que te vas enfrentando a problemas reales.

Un consejo compra libros de temas como Framework, Arquitectura (de esto Dino tiene uno del 2008 que se ve bien), SOA, si sabes de eso las cosas técnicas ASP.NET, WPF, Silverlight...están ahi afuera...

Un abrazo
http://dotnetsofi.blogspot.com

jueves, abril 16, 2009 3:41:00 p. m.  
Blogger Andrés Ortíz said...

Más de libros recomendados, y esto si es usar la tecnología:

http://blogs.msdn.com/brada/archive/2005/02/21/377628.aspx

jueves, abril 16, 2009 3:45:00 p. m.  
Blogger Alfredo Novoa said...

mejor no gastes tú dinero. No porque unos sean malos u otros excelentes, el punto es que es practicamente una perdida de 100euros que podrías invertir en algo que te permita crecer más en aspectos conceptuales en lugar de algo tan técnico que finalmente terminas es remitiendote a los N-mil Blogs que encuentras en internetBueno, si te lo puedes permitir tampoco están mal para introducirte rápidamente en un tema. Lo malo es que los llenan de paja y para una cosa que se puede contar en 200 páginas usan 800 y se hacen muy pesados.

Pero está claro que es prensa de usar y tirar como los periódicos.

Yo estoy deseando que saquen esto y productos similares:

http://www.plasticlogic.com/product.html

En cambio los libros de Knuth y los artículos de Dijkstra son casi inmunes al tiempo.

Arquitectura (de esto Dino tiene uno del 2008 que se ve bien)¿Te sabes el título?

jueves, abril 16, 2009 4:07:00 p. m.  
Blogger Alfredo Novoa said...

No se que han cambiado los ñapas de Google que se juntan los párrafos cuando citas algo.

jueves, abril 16, 2009 4:08:00 p. m.  
Blogger Andrés Ortíz said...

Exacto de 800 solo 200, pero vale la pena gastar 100 euros por conseguir de todo eso solo el 30 o 40 %? y eso si las mismas introducciones trilladas de todos los autores sobre .NET.

Claro Alfredo este es el book:
http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-PRO-Developer/dp/073562609X

Qué significa ÑAPAS?

Un abrazo
http://dotnetsofi.blogspot.com

jueves, abril 16, 2009 5:21:00 p. m.  
Blogger REDMAN- said...

Bonito el plastic logic este, pero ahora q se alude al hardware PIENSO que hay una locura absurda con las chorradas portatiles. La clave del futuro no está en los móviles ni en las pda's AL MENOS COMO DISPOSITIVOS DE VISUALIZACIÓN sino en la INTEGRACIÓN ENTRE DISPOSITIVOS, lo bonito sería llevar una pda y al pasar por delante de una pantalla OLED de 52"(esto si es el futuro) este pase a ser mi dispositivo de visualización e interactue con esta, y ya se encargará el tiempo de llenarlo todo de PANTALLAS OLED o similares con BLOTOOTH 8.0. Además esta tecnológicamente hecho , (es el mismo problema q en el software) PONERSE DE ACUERDO como cuando nació el PC COMPATIBLE.

Es absurdo el tiempo que se gasta en desarrollar interfaces de 2"

Por otro lado lo que si debe hacerse pequeño es el PC ESTANDAR (de escritorio) y aunque se ha avanzado últimamente con los barebones y similar, ¿a que esparn a HACER EL ESTANDAR de unidad óptica de 3,5"? un BLUE RAY DE 12cm si que hubiera sido una innovación (SUPONGO Q EXISTE COMO LOS DVD DE 12CM) PERO NO ES LO ESTANDAR!

En definitiva, nuestra vista no necesita q le hagan las cosas cada vez más pequeñas, pero nuestra vivienda SI!

jueves, abril 16, 2009 5:21:00 p. m.  
Blogger Ian Marteens said...

Supongo que con lo de "mapearlo" te refieres a asociarlo.-

Err... sí. Lo utilicé a propósito, pero ya sé que suena horrible. No lo usaría ni en un libro ni en un curso.

el libro cumple su propósito de describir el disparatado EF-

Por eso titulé la revisión en Amazon "How to write a superb book on a problematic topic".

jueves, abril 16, 2009 5:34:00 p. m.  
Blogger Alfredo Novoa said...

pero vale la pena gastar 100 euros por conseguir de todo eso solo el 30 o 40 %? y eso si las mismas introducciones trilladas de todos los autores sobre .NET.Si que es un fastidio que muchos te metan en cada libro una introducción trillada de .NET.

Claro Alfredo este es el book:Muchas gracias.

Qué significa ÑAPAS?Chapuzas o chapuceros.

jueves, abril 16, 2009 5:34:00 p. m.  
Blogger Ian Marteens said...

alguien sabe si esta escribiendo "La nueva cara de C#".

Sí. Tamaño enciclopedia. Utilizable también como arma gravitatoria (si te cae encima, te mata). Pero voy a intentar subirme a la beta de VS2010, porque tal y como está la tecnología ahora, un libro que incluyese EF quedaría incompleto. No merece la pena adelantarse tres o cuatro meses a estas alturas.

jueves, abril 16, 2009 5:39:00 p. m.  
Blogger Alfredo Novoa said...

Redman, el Plastic Logic es papel electrónico de 8,5x11 pulgadas que es un tamaño muy bueno para los libros de los que estamos hablando.

Yo no me imagino tumbado en la cama leyendo de un OLED de 52 pulgadas.

Ahora tengo un libro de papel electrónico de 6 pulgadas de diagonal y es una maravilla para leer novelas y ensayos. Nada que ver con leer de la pantalla, y la carga de la batería te dura más de un mes leyendo un par de horas al día.

jueves, abril 16, 2009 5:43:00 p. m.  
Blogger Alfredo Novoa said...

Pero voy a intentar subirme a la beta de VS2010
Haces bien, por que ahora mismo hay demasiadas cosas en el aire como el EF y Silverlight.

El VS2008 es una versión muy de transición con muchas cosas a medio hacer como los diseñadores visuales del WPF.

¿Vas a tratar WPF y Silverlight?

Para mí Silverlight es algo mucho más importante que el EF. Yo ya no quiero saber nada de ASP.NET y similares.

jueves, abril 16, 2009 6:04:00 p. m.  
Blogger REDMAN- said...

Vs2008 lleva el C# 3.0 con cosas como los EXTENSIONS METHODS que están muy bien y lo importante es que sigue soportando WINFORMS que es la es única realidad DENTRO DE .net
las aplicaciones de gestión de empresas no necesitan para nada silverlight ni wpf !!!

jueves, abril 16, 2009 6:49:00 p. m.  
Blogger REDMAN- said...

Necesitamos herramientas de cliente potentes no que microsoft se invente cosas y diga que son estandar!

jueves, abril 16, 2009 6:52:00 p. m.  
Blogger REDMAN- said...

Alfredo no lo decía por el papel ese, me parece genial

jueves, abril 16, 2009 6:59:00 p. m.  
Blogger REDMAN- said...

Aun asi la pantalla de 52 es tu techo, cuando estás en la cama

jueves, abril 16, 2009 6:59:00 p. m.  
Blogger REDMAN- said...

y las paredes ...

jueves, abril 16, 2009 7:00:00 p. m.  
Blogger Ian Marteens said...

Redman, ¿qué has tomado? ¿Has dejado para los demás?

jueves, abril 16, 2009 9:28:00 p. m.  
Blogger Ian Marteens said...

¡Ah, ya he logrado recomponer las preguntas correspondientes a las respuestas! Nada, nada, estabas sobrio, lo siento...

Silverlight-

Mais oui!

jueves, abril 16, 2009 9:30:00 p. m.  
Blogger REDMAN- said...

¿Alguien sabe si hay algún erp importante hecho en .net?

viernes, abril 17, 2009 12:09:00 p. m.  
Blogger Alfredo Novoa said...

He estado leyendo el libro ese de arquitectura del tal Esposito y es un desastre. No tienen ni idea de lo que es una base de datos.

Esos tíos saben de arquitectura de sistemas de información empresarial lo mismo que yo de literatura húngara.

Lo único que dicen en todo el libro de los SGBD es que son un medio para hacer persistentes sus redes de objetos en memoria.

Es decir, te cuentan el mismo rollo que cualquier javalí.

viernes, abril 17, 2009 1:44:00 p. m.  
Blogger Manuel said...

Hay fecha aproximada para esa arma / enciclopedia? es que planteandolo desde ese punto de vista, no esta mal la idea, es comprar un dos por 1, siempre esta bien tener un arma a mano sobre todo para matar a los Srs. Butters, cuando tengas el primer ejemplar puedes probar con el tuyo, espero que no pase mucho por el blog porque sino te hara la vida imposible, jaja,... bueno Ian, no es por presionar pero a ver si confirmas la fecha, es por no gastarme el dinero en cazar conejos playeros, que yo estoy muy cerca de la playa y el buen tiempo no creo que tarde mucho en llegar.

viernes, abril 17, 2009 1:55:00 p. m.  
Blogger Freman said...

Hay fecha aproximada para esa arma / enciclopedia?Va a tardar. Para el otoño, como mínimo.

espero que no pase mucho por el blog:) A veces la ironía logra resultados que no consigues de otro modo.

A veces es bueno que ciertas personas comprendan de verdad cuando uno no tiene mucho que perder. Precisamente, no porque uno vaya a perder mucho, sino para ahorrar molestias a ambas partes... y para ganar lo poco o mucho que haya que ganar.

Pero mejor me callo, que me estoy poniendo budista...

viernes, abril 17, 2009 5:58:00 p. m.  
Blogger Andrés Ortíz said...

Ian apresuraos con ese libro, yo estoy muy alejado de los gastos bibliograficos por motivos de aburrimiento y en búsca de otros temas, pero sinceramente un libro tuyo en la Biblioteca siempre ha sido un buen deseo, y viendote tú punto crítico y habiendo leido la cara oculta de CPPB por allá en mis mejores epocas, creo que un libro tuyo a aestas alturas será mejor que bueno!!

Recomendaciones:

1. NO a la trillada Introducción de la Plataforma .NET ... bla bla bla

2. Fuerte en cosas de utilidad: Eventos, Delegados, Generics, Best Practices, y esas cosas nuevas de C# 4 ...

3. Cero ejemplos obvios.. Habran visto los libros de ASP.NET, todos hacen el Bind de un GridView y ya, con eso creen que conquistaron el mundo, cuando detras de ese único control hay una gran potencia que nunca muestran... sencillamente nunca han hecho proyectos de verdad por eso no tienen nada de que hablar en el libro...

4. Ian parale bolas a Silverlight, estoy de acuerdo con Alfredo que WPF es carreta ...

5. Todavía recuerdo como mostrabas cosas internas de C++ Builder, has lo mismo con el Framework, algo así como FRamework Internals...

6. Un buen ejemplo de principio que guie todos los conceptos, eso sería un Hit...al estilo de los geniales ejemplos que Microsoft tiene por ahi que realmente valen la pena.. y como lo hacias en aquellos grandes libros de CPPB

7. Hombre WCF vale la pena escucharlo desde tú perspectiva, todo el tema de servicios, cloud computing eso vale mucho la pena comenzar a pensar así...

8. LINQ pues allá tú..

9. Tuning, Deployment, cosas reales que realmente sirven en los proyectos...

10. IAN de tí aprendi el concepto de OLE, automatización de word... etc etc, por qué abandonaste eso, si VSTO hoy en día es de las cosas lindas de .NET

11. Un buen apartado de sacarle partido al IDE eso es otro HIT, eso si realmente que ahorra tiempo

Un abrazo

sábado, abril 18, 2009 4:06:00 a. m.  
Blogger Junior said...

En mi opinión estoy de acuerdo con Ian en el sentido que es mejor darle un poco de tiempo a ver como se van a definir las cosas en Redmond, asi el material ofrecido no se quedará atras en corto tiempo y podremos sacarle mayor provecho.

Quiza en microsoft no monten un nuevo disfras a las chapuzas que han hecho y se pongan serios a hacer su trabajo.

sábado, abril 18, 2009 1:29:00 p. m.  
Blogger Ian Marteens said...

NO a la trillada Introducción de la Plataforma .NET.

No, efectivamente. Me costaría dinero a mí y al lector. Del libro de Delphi 4 al de Delphi 6 desaparecieron muchos capítulos: las plataformas maduran y los lectores también.

Eventos, Delegados, Generics.

¿Es una contradicción con lo anterior? Buena parte de esto ya está en Intuitive C#. Es verdad que lo gratuito no se aprecia tanto... :)

Un buen ejemplo de principio que guie todos los conceptos.

Eso, sin embargo, es mortal para un libro. Obliga a leer de arriba a abajo. Lo contrario, por supuesto, es el "ejemplo obvio" (que puede partir de cero). La clave está en buscar ejemplos alejados de ambos extremos. Que se puedan desarrollar rápido y que no sean los obvios. Ahí es donde está el arte.

FRamework InternalsEso se me daría bien. Trabajar con Freya me ha enseñado muchas cosas.

Por cierto, quiero convertir Freya/Lyra en open source. Lo que no tengo claro es cómo organizarlo. ¿Se os ocurren ideas?

domingo, abril 19, 2009 4:28:00 p. m.  
Blogger Alfredo Novoa said...

Lo que no tengo claro es cómo organizarlo.

¿Puedes explicarte un poco más?

Lo obvio es meterlo en Codeplex que tiene soporte para Subversion y Team System y foros.

Y luego le vas dando permisos de escritura a quien te de la gana.

Y además podemos usar los foros para desbarrar en vez de hacerlo aquí en los comentarios :-)

domingo, abril 19, 2009 5:10:00 p. m.  
Blogger Salvador said...

>Por cierto, quiero convertir Freya/Lyra en open source. Lo que no tengo claro es cómo organizarlo. ¿Se os ocurren ideas?

Hola Ian:

No se si es una pregunta tonta, pero el pasar el proyecto a opensource es por algun motivo en especial?? Me alegra que sea así, pero desde la primera vez que empece a saber de la existencia de Freya a través de estas entradas, tenía el convencimiento de que acabaría siendo un proyecto comercial, lo cual me parecía lógico dadas las horas que creo has invertido en el.

Espero, a igual que el resto de compañeros que se han pronunciado ,que pronto podamos leer un nuevo libro tuyo.

Y respecto a Velneo, que comentabais en una entrada anterior, yo que he podido ver las betas y las he probado y puedo decir que me parece que están haciendo un trabajo muy serio, con independencia de que estén fuera de la onda de la moda. La V7 tiene un interfaz actual, que era una de las quejas de los programadores que se acercaron a la V6. Hay muchos otros aspectos que han sido contemplados que no existian en la V6 como el tratamiento de eventos, el drag and drop, el control de versiones y trabajo en equipo, etc...

Y para acabar solo queria preguntarte si estas organizando algun curso en Madrid en estos meses. ¿Tienes alguno a la vista?


Gracias.
Salvador Jover

domingo, abril 19, 2009 6:42:00 p. m.  
Blogger Alfredo Novoa said...

tenía el convencimiento de que acabaría siendo un proyecto comercial

Que sea open source no tiene nada que ver con que sea comercial o no.

domingo, abril 19, 2009 11:06:00 p. m.  
Blogger Salvador said...

>Que sea open source no tiene nada que ver con que sea comercial o no.

Hola Alfredo:

Ok. No me he explicado bien. No queria decirlo en ese sentido porque yo también estoy de acuerdo contigo en ese punto, pero mi comentario iba en cuanto a que pensaba que ese proyecto iba a formar parte de algun servicio o catalogo de las empresas que pueda participar Marteens. Y por eso mi extrañeza de que acabará siendo Opensource.

Un saludo,

Salvador Jover

domingo, abril 19, 2009 11:53:00 p. m.  
Blogger Andrés Ortíz said...

Ian no le des vueltas

http://www.codeplex.com/

Pero si lo extraño es que lo quieras volver OS

No le has tocado a la puerta MS? depronto les guste tú proyecto.

Saludos

lunes, abril 20, 2009 7:54:00 p. m.  
Blogger Ian Marteens said...

La trampa en lo de Freya es que quiero soltarlo. Me es imposible llevarlo sólo: para que sea medianamente utilizable necesita mucho trabajo en Intellisense, el diseñador visual, y esas cosas... aparte de llevar el propio compilador al paso del compilador de C#.

Por otra parte, sí que he tocado a Microsoft (Ibérica) y la gata de mis padres suele hacerme más caso cuando le pido que haga el pino. En general, el interés de quienes han visto el proyecto y tienen pasta y posibilidades, ha sido nulo.

Una posible reacción mía sería chapar el asunto en plan "no se lo merecen". Sería una tontería, claro. Pero no puedo dedicarle más tiempo al asunto. Si alguien quiere relevarme, bienvenido.

lunes, abril 20, 2009 9:14:00 p. m.  
Blogger Alfredo Novoa said...

para que sea medianamente utilizable necesita mucho trabajo en Intellisense, el diseñador visual, y esas cosas...

Es mucho trabajo y ya está hecho. No me parece muy buena idea competir en eso con Visual Studio y SharpDevelop. Además Windows Forms está ya medio muerto.

A lo mejor se podía integrar con SharpDevelop como el lenguaje Boo, o incluso con Visual Studio.

En general, el interés de quienes han visto el proyecto y tienen pasta y posibilidades, ha sido nulo.

Hombre, como experimento está muy bien, pero el problema más grande que yo le veo es que se parece demasiado a C# y Visual Studio, y por ahí nunca vas a poder competir con M$. Habría que diferenciarse más y tirar por donde M$ flojee. Pero como punto de partida lo que tienes está muy bien.

Lo he estado mirando un rato con el Reflector y tiene buena pinta. Yo intentaría hacerlo lo más modular posible por ejemplo haciendo independientes los AST de la generación de código. Y en el tema de la optimización siempre hay cosas para entretenerse :)

lunes, abril 20, 2009 10:38:00 p. m.  
Blogger Marco Antonio Santin Torres said...

Además Windows Forms está ya medio muerto.Como Junior comento ya en un post pasado, por desgracia en países de tercer mundo como en el que yo vivo, Windows Forms es una alternativa a las lentas e inestables conexiones a Internet. Así que al menos en América Latina Windows Forms todavía no está ni medio muerto.

martes, abril 21, 2009 1:02:00 a. m.  
Blogger Alfredo Novoa said...

Windows Forms es una alternativa a las lentas e inestables conexiones a Internet

También lo es WPF e incluso Silverlight en Intranet o en modo escritorio.

Me refería a que M$ ya tiene a Windows Forms medio abandonado y ahora casi todo el esfuerzo está centrado en WPF y Silverlight.

martes, abril 21, 2009 1:07:00 a. m.  
Blogger REDMAN- said...

La diferencia es que Windows Forms "ES" y WPF y Silverlight "NUNCA SERÁN"

martes, abril 21, 2009 9:36:00 a. m.  
Blogger REDMAN- said...

Win32 es lo mejor que ha habido. Punto Net es una chorrada pues no es real que pueda funcionar en LINUX, o sea no deja de ser una capa absurda (salvo por que soluciona el DLL HELL que no es poco), pero es que WPF es un paso atrás que no tiene absolutamente ninguna ventaja, aunque entiendo que Silverlight puede tener alguna.

martes, abril 21, 2009 9:42:00 a. m.  
Blogger Alfredo Novoa said...

Redman, andas un poco despistado. WPF y Silverlight son una realidad y hay muchísima gente trabajando con ellos, y .NET no es una chorrada por que no pueda funcionar con Linux, porque entre otras cosas funciona estupendamente con Linux.

Es más .NET viene muy bien para poder librarnos de los Windows Server. El único problema es que no hay SQL Server para Linux.

martes, abril 21, 2009 12:42:00 p. m.  
Blogger REDMAN- said...

¿que controles .net hay q sirvan para linux?

martes, abril 21, 2009 1:45:00 p. m.  
Blogger REDMAN- said...

¿cual es la ventaja de WPF contra WINDOWS FORMS?

martes, abril 21, 2009 1:46:00 p. m.  
Blogger REDMAN- said...

Alfredo por favor, lo criticas todo y luego estás a la última chorrada que salga!

martes, abril 21, 2009 1:47:00 p. m.  
Blogger Alfredo Novoa said...

Controles .Net que sirvan para Linux los hay a montones y habrá más. Y no todas las aplicaciones necesitan controles.

Ventajas de WPF. Pues bastantes:
Separa bien el diseño gráfico de la lógica de la aplicación. Tiene mejor "databinding". Permite migrar fácilmente las aplicaciones al navegador. Tiene mejor soporte para mostrar documentos. No usa la mierda del GDI+ y tiene muchas más posibilidades gráficas.

La desventaja más grande es que los textos se ven borrosos :(

martes, abril 21, 2009 2:02:00 p. m.  
Anonymous Anónimo said...

Pues le doy la razon en todo esto al Sr. Alfredo Novoa, una des la ventajas del .net es justamente esa un proyecto bien separado en capas, es relativamente facil de migrar de winforms por ejemplo a WPF, o al Web, sin duda WPF y Silverlight son el futuro , pero igualmente creo que todavia no estan como para ser usados en produccion hoy en dia , ya los winforms creo que no van a morir pronto el mercado de componentes es muy grande, pero eso no es problema pq net permite usar tanto winforms como host en WPF y vice-versa , esto si es una ventaja del .net y cualquier control o componente (winforms) del .net puede correr en linux con mono, una cosa que tenemos que reconocer es que hoy dia nada es tan sencillo antes teniamos Clipper y DBF's y eso era lo qe habia o Cobol u AS400, todo era relativamente facil pero teniamos muchas limitaciones , en cuanto a tamano de la aplicacion , base de datos entre otras , hoy dia necesitamos saber de todo un poco, Windows, Mobile y Web no nos queda otra y ahora con la compra de Oracle a sun , bueno el futuro o sera Java o .net, otra cosa creo que sera perdida de tiempo aprender.

martes, abril 21, 2009 3:53:00 p. m.  
Blogger REDMAN- said...

Las ventajas que implica WPF no son ni por asomo suficientes para hacer una inversión en otro cambio de mentalidad para empezar a desarrollar con dicha plataforma, por no hablar de la falta de documentación con la que se encontrará alguien que intente hacer algo serio.

Las aplicaciones que no utilizan controles se puede programar con casi cualquier cosa .

Tienen mejor databinding -> me da igual nunca lo he usado impide aplicar reglas de negocio parejas a todo el sistema.

Permite migrar fácilmente las aplicaciones de navegador -> claro
si es que es una mierda como las aplicaciones del navegador.

Linux siempre será el futuro, yo llevo 15 años ya oyéndolo y me retiraré sin verlo.

martes, abril 21, 2009 4:28:00 p. m.  
Blogger Junior said...

Y cual es el temor de microsoft de llevar a Sql server a linux. Quizas ellos pienzan que la comunidad de codigo libre lo burlara o algo por el estilo, yo pienzo que si ellos a travez del framework lo hacen multiplataforma quedarian mal parados muchos de esos SGBD multiplataforma. Novell de seguro que si Microsoft le otorga los permisos y le da un poco de financiamiento lo haría bastante rápido.

Otra probabilidad es que la pasta fuerte esta en los servidores y microsoft quiere que las empresas usen windows, pero a final de cuenta la que elige es la empresa
cual plataforma quiere usar.

Pero ¿Donde pueden ellos ganar más con el sistema operativo, o con el SGBD?.

martes, abril 21, 2009 4:37:00 p. m.  
Blogger Alfredo Novoa said...

Las ventajas que implica WPF no son ni por asomo suficientes para hacer una inversión en otro cambio de mentalidad para empezar a desarrollar con dicha plataforma,

Depende de lo duro de mollera que seas. Para otros será un cambio trivial.

De documentación está igual que todo lo demás.

Los databindings permiten ahorrar mucho código y no tienen nada que ver con las reglas de negocio.

Y Linux no es el futuro, es una realidad en el mundo de los servidores. ¿Que crees que usan Google, Amazon, IBM y la mayoría de los super ordenadores?

martes, abril 21, 2009 4:37:00 p. m.  
Blogger Alfredo Novoa said...

Y cual es el temor de microsoft de llevar a Sql server a linux.

Pues supongo que Linux le gane más cuota a los servidores Windows.

Además de que la gente de Linux está acostumbrada a no pagar por el software.

martes, abril 21, 2009 4:41:00 p. m.  
Blogger REDMAN- said...

"Y Linux no es el futuro, es una realidad en el mundo de los servidores. ¿Que crees que usan Google, Amazon, IBM y la mayoría de los super ordenadores?"

Si y seguro q usan WPF no me seas chorra que no hablamos de MACRO SISTEMAS.
Entonces como la CAM (que no es perico de los palotes) usa servidores BULL pues eso es el futuro!!!

martes, abril 21, 2009 4:45:00 p. m.  
Blogger Junior said...

"Pues supongo que Linux le gane más cuota a los servidores Windows"Yo lo digo en el sentido que lo hagan como Sun, por que Oracle aunque sea para linux no es nada barato

martes, abril 21, 2009 4:52:00 p. m.  
Blogger Junior said...

"Pues supongo que Linux le gane más cuota a los servidores Windows"Yo lo digo en el sentido que lo hagan como Sun, por que Oracle aunque sea para linux no es nada barato

martes, abril 21, 2009 4:52:00 p. m.  
Blogger Junior said...

"Pues supongo que Linux le gane más cuota a los servidores Windows"Yo lo digo en el sentido que lo hagan como Sun, por que Oracle aunque sea para linux no es nada barato

martes, abril 21, 2009 4:52:00 p. m.  
Blogger Junior said...

"Pues supongo que Linux le gane más cuota a los servidores Windows"Yo lo digo en el sentido que lo hagan como Sun, por que Oracle aunque sea para linux no es nada barato

martes, abril 21, 2009 4:52:00 p. m.  
Blogger Junior said...

Este editor tiene problemas...

martes, abril 21, 2009 4:53:00 p. m.  
Blogger Junior said...

Los de Google al parecer no usan mucho este editor para enviar mensajes.

martes, abril 21, 2009 4:54:00 p. m.  
Blogger Alfredo Novoa said...

Si y seguro q usan WPF no me seas chorra que no hablamos de MACRO SISTEMAS.

No hablarás tú. No todo el mundo hace programas de facturación para 5 usuarios.

Y no solo se usa en grandes sistemas. Por cada 3 o 4 Windows Server debe de haber un servidor Linux en el mundo, y hay más servidores Web con Linux que con Windows. El 95% de los ordenadores de los estudios de animación y efectos especiales usan Linux, los servidores de Second Life usan Mono, etc, etc.

martes, abril 21, 2009 5:14:00 p. m.  
Blogger REDMAN- said...

Si alguien trabaja en Google que siga los consejos de Alvaro.

martes, abril 21, 2009 5:19:00 p. m.  
Blogger raultr said...

Alfredo, desde tu punto de vista que le hace falta a postgresql para poder ser tomada como una alternativa seria a oracle o sql server.

martes, abril 21, 2009 5:38:00 p. m.  
Blogger Alfredo Novoa said...

Hola raultr, pues no lo conozco muy bien, pero por lo que he visto en principio no le falta nada. De los SGBD abiertos creo que es el más completo.

martes, abril 21, 2009 5:52:00 p. m.  
Blogger Marco Antonio Santin Torres said...

Por otra parte, sí que he tocado a Microsoft (Ibérica)Oye Ian y ¿nunca tocaste las puertas de CodeGear? a lo mejor hubieran elegido a Freya en lugar de Oxygene para que fuera lo que ahora es Delphi Prism.

martes, abril 21, 2009 6:22:00 p. m.  
Blogger Manuel said...

Marco Antonio, yo he pensado la mismo que tu muchas veces, Freya tendría que ocupar el sitio de Delphi Prism. Por cierto y tu libro? Tampoco tienes fecha de lanzamiento? Yo lo del Delphi Prism tampoco lo veo claro porque estos de Embarcadero igual que se han cargado Delphi para .NET, no se yo hasta donde van a llega con esto del PRISM, la idea es buena, pero tener que metersela a M$ para poder trabajar... no se yo, y si un dia cierra las piernas y no se deja, jaja.

miércoles, abril 22, 2009 8:31:00 a. m.  
Blogger Marco Antonio Santin Torres said...

Manuel:

Con respecto a lo de mi libro, la fecha exacta no la sé, estoy con los últimos capítulos pero espero que este a la venta en a finales de mayo. Como dijo Ian en un post pasado Delphi.NET muy a mi pesar nunca funciono, los de Embarcadero se dieron cuenta de que no tenia arreglo y pues como dijo Ian optaron por adoptar al hijo del vecino para convertirlo en lo que ahora es Prism (Me hubiera gustado mucho que el hijo del vecino hubiese sido Freya). Yo he estado en contacto con la gente de CodeGear/Embarcadero en especial con Andreano Lanusse y pues hasta donde yo sé le están echando todas las ganas para que el proyecto funcione, además de que RemObjects es el responsable directo del compilador y ya lleva mucho tiempo invertido en este lenguaje. RemObjects está detrás de ellos y no creo que dejen caer el proyecto. El lenguaje pinta bien y hasta donde yo le he probado no he tenido problemas graves, de hecho ya he completado la gran mayoría del curso de C# de Ian en Prism y no he tenido problemas. Como dijo Ian es una buena alternativa para la gente que no nos gustan mucho las llaves jejeje.

miércoles, abril 22, 2009 4:39:00 p. m.  
Blogger vicente said...

Con respecto a lo que dijo Marco Antonio.... espero que delphi prism no se quede en solo una alternativa sino que vaya mas lejos. A mi tampoco me gustan las llaves aunque pienso que la dificultad no viene por las llaves sino por el .net.Yo ahora estoy esperando una por el libro de Marco para empezar una serie de trabajos y espero que todo funcione tan bien como en delphi o mejor. A mi lo que realmente me da miedo es que microsoft le vuelva a dar la vuelta a la tortilla antes de que la pueda morder y tirarme un montón de años estudiando y mirando temas que no duran nada. Pienso que los programadores no estamos para testear ideas locas de cuatro genios con ideas alocadas sino para desarrollar programas estables con cierto grado de innovación cada x años. Ese es el principal problema de microsoft : innovaciones que no van a ninguna parte (en muchos casos) y que no duran ni un año para ser sustituidas por otras antes de implantarse las actuales.

miércoles, abril 22, 2009 11:10:00 p. m.  
Anonymous Anónimo said...

No creo que prisma vaye lejos ojala si me gustaria mucho pq me gusta el pascal pero hay q tener en cuenta que no tiene soporte a mobile y otra muy importante no existe un mercado de componentes de terceros que lo apoye sin eso hoy dia es imposible un desarrollo decente , ojala este yo equivocado, envie email's a DevExpress y sus componentes no son 100 x100 compatibles con prisma, creo y estoy convencido de que C# sera el lenguaje de vanguardia en los proximos tiempos de la programacion, microsoft siempre estara al frente en su propio terreno por lo menos lo que a .net refiere.

miércoles, abril 22, 2009 11:40:00 p. m.  
Blogger Marco Antonio Santin Torres said...

Con respecto a que los componentes DevExpress no son 100% compatibles con Prism es cierto, pero también es cierto que ya están trabajando en ello y en poco tiempo estarán trabajando al 100%,(eso lo sé porque me lo han dicho la propia gente de CodeGear, inclusive en el Media Kit Original de Delphi Prism viene la versión de evaluación) yo ya he hecho pruebas de estos componentes con Prism y no he tenido problemas.

Lo del soporte para Mobile si lo tienen pero no desde el IDE de Visual Studio. Puedes ver un ejemplo bajándote este video:

http://cc.embarcadero.com/item/26379

C# siempre ira a la delantera por obvias razones, pero la gente de Embarcadero/RemObjects está trabajando muy rápido y muy duro para que la brecha no sea muy larga (esto me consta). Por lo pronto Prism soporta bien la última versión de Microsoft .NET 3.5, Windows Forms, WPF, Silverligth, ASP.NET LINQ y la programación orientada a aspectos (AOP) entre otras cosas.

Creo que van por buen camino y espero que sigan así.

jueves, abril 23, 2009 12:12:00 a. m.  
Blogger Junior said...

Si yo fuese Director del proyecto delphi en embarcadero le hubiera puesto Delphi 2007.00001 al delphi 2009 para win32 por que !como que no se ven muchas mejoras! que lo hagan una opción para cambiar.

Por que ellos no se dirigen a un solo frente y dejan de lado eso de delphi para php y optan por seguir con win32 o .net asi de seguro que la estarian mejor posicionados.

jueves, abril 23, 2009 4:10:00 a. m.  
Blogger Junior said...

Si yo fuese Director del proyecto delphi en embarcadero le hubiera puesto Delphi 2007.00001 al delphi 2009 para win32 por que !como que no se ven muchas mejoras! que lo hagan una opción para cambiar.

Por que ellos no se dirigen a un solo frente y dejan de lado eso de delphi para php y optan por seguir con win32 o .net asi de seguro que la estarian mejor posicionados.

jueves, abril 23, 2009 4:10:00 a. m.  
Blogger Junior said...

Si yo fuese Director del proyecto delphi en embarcadero le hubiera puesto Delphi 2007.00001 al delphi 2009 para win32 por que !como que no se ven muchas mejoras! que lo hagan una opción para cambiar.

Por que ellos no se dirigen a un solo frente y dejan de lado eso de delphi para php y optan por seguir con win32 o .net asi de seguro que la estarian mejor posicionados.

jueves, abril 23, 2009 4:10:00 a. m.  
Blogger Junior said...

sera mi conexion lenta la que esta causando el problema que se repite el mismo mensaje.

jueves, abril 23, 2009 4:12:00 a. m.  
Blogger Andres Ortiz said...

Miren señores Linux, Windows, MAC etc, he odio a un chico de mi empresa que utilizó ultimamente la cosa de MONO y le ha ido muy bien. No he leido todos los post así que escribo esto por si no han tocado el tema, pero viendo algunos posts creo que el comentario vale la pena. Ese Mexicano sabe e hizo algo bueno con ese invento de MONO. Por ejemplo IAN según Alfredo ese es el diferenciador. .NET funciona bien en su Windows, pero y...?? tocaba también tenerlo en otros sistemas y ahi si que se logró un gran diferenciador.

WPF a veces me parece un juguete no le veo futuro, al igual que las cosas Desktop, el futuro es la NUBE, pasarle la pelota a los Data Centers de los grandes y que las empresas se quiten ese peso.

Silverlight, eso si tiene futuro, ahi está Flash, ahi está el de los Javalies, etc etc, la cosa RIA tiene mucho sentido. Lo malo es que los ejemplos empresariales de Silverlight son pocos, así que revisen los artículos de Dino y otros por ahi de los últimos números de MSDN.

Un abrazo

jueves, abril 23, 2009 5:15:00 a. m.  
Blogger Marco Antonio Santin Torres said...

Si yo fuese Director del proyecto delphi en embarcadero le hubiera puesto Delphi 2007.00001 al delphi 2009Junnior, creo que si estuvieses en el puesto de Nick Hodges (Product Manager de Delphi) y le hubieras puesto 2007.00001 a Delphi 2009 ya te hubieran corrido. Porque no fueron pocas las mejoras hechas entre ellas:

- Bastantes mejoras a DataSnap la más importante la independencia de COM.
- Soporte a genéricos y métodos anónimos.
- Completo soporte a Unicode.
- Numerosos cambios al lenguaje y al RTL.
- Nuevos componentes VCL

Cambio bastante con respecto a Delphi 2007, si quieres saber más al respecto te recomiendo el libro Delphi 2009 HandBook de Marco Cantú. Ahí vienen muy bien explicadas las muchas mejoras hechas al lenguaje.

Por que ellos no se dirigen a un solo frenteCon respecto a lo de un solo frente, creo que la mejor estrategia que hizo Embarcadero fue el haberse asociado con RemObjects, RemObjects se encarga únicamente de Delphi Prism para .NET y CodeGear solo de Delphi 2009 win32 así ambos frentes están cubiertos ampliamente y así como dices tú están mejor posicionados.

jueves, abril 23, 2009 6:41:00 a. m.  
Blogger Alfredo Novoa said...

.NET funciona bien en su Windows, pero y...?? tocaba también tenerlo en otros sistemas y ahi si que se logró un gran diferenciador.

Completamente de acuerdo. El ser realmente multiplataforma es la razón de ser de MONO. Eso y ser abierto. Sin estas dos cosas MONO no le hubiese interesado a casi nadie.

Yo también pienso que la "Nube" tiene mucho futuro, aunque tardará en llegar. Y ahí Linux tiene un papel que jugar por que los servidores Linux son más baratos y dan el mismo servicio. El cliente final ni sabe ni le importa que sistema operativo usa el centro de datos.

Por cierto, si quereis que las citas se vean bien es mejor poner dos "br" después de cerrar las cursivas.

jueves, abril 23, 2009 9:55:00 a. m.  
Blogger REDMAN- said...

Pero lo de menos son los servidores si son WIN o LINUX lo importante son los clientes (que tb da igual q sean WIN/LINUX porque esa batalla la va a resolver el usuario final) la inversión económica importante esta en la programación por culpa de estándares de comunicación. En el caso de las interfaces lo que no puede ser es estandarizar por abajo (navegadores) porque eso son horas de programación y aplicaciones absurdas.Pero el verdaro problema es como se comunican las aplicaciones entre si (ya sean una interfaz con su servidor o aplicaciones distintas ), pues cada uno lo hace a su forma y las aplicaciones son incompatibles entre si.

jueves, abril 23, 2009 11:54:00 a. m.  
Blogger Alfredo Novoa said...

Pero lo de menos son los servidores si son WIN o LINUX lo importante son los clientes (que tb da igual q sean WIN/LINUX

Pues eso, si son lo de menos es mejor poder escoger lo más barato.

la inversión económica importante esta en la programación por culpa de estándares de comunicación.

Pues a mi ese problema me preocupa muy poco.

Yo creo que la programación es cara porque es complicada de por sí, y además las herramientas son muy malas y los lenguajes son poco apropiados para programar sistemas de gestión, o son directamente malos.

jueves, abril 23, 2009 12:44:00 p. m.  
Blogger REDMAN- said...

"Pues a mi ese problema me preocupa muy poco."

Ese es el problema Alfredo que a todos nos importa poco por eso lo que tu haces solo vale para ti y lo que hace Embarcadero solo vale para ellos.

jueves, abril 23, 2009 12:45:00 p. m.  
Blogger Junior said...

Marco Antonio claro tienen que mejoras, pero lo que critico es que esas mejoras no son tan significativas como la que esperamos los desarrolladores de delphi. Estoy por empezar un nuevo proyecto en delphi y estube viendo dicha versión.

Nuevos componentes: si lo dices por los Ribbons control no es la gran cosa por que normalmente siempre tenemos que recurrir a terceros para poder hacer aplicaciones un poco decentes y los Ribbons de devexpress son más completos.

Sobre DataSnap ya hace tiempo ellos debieron haberlo hecho, si ya COM es algo que va en decadencia desde hace mucho tiempo y ya no criticando a Embarcadero fueron sus anteriores directores que cuando introdujeron CLX debieron haber echo mejoras a DataSnap, lo que queremos es independencia del SO.

Los cambios al lenguaje no podria hablar de ellos por que solo le he dado un vistazo a lo mas básico para desarrollar mi aplicación.

Seguimos con los mismos problemas de que las tablas de detalles deben hacer una lectura por cada registro y el provider sigue con sus limitaciones y sus faltas ortograficas.

Ahora es peor por que en delphi 7 yo podia acceder al código fuente de muchos de esos componentes ahora como esta el código fuente esta cerrado estoy limitado a la pobre documentación que ellos ofrecen para hacer cualquier cambio y si no han mucho las cambiado las cosas utilizando delphi 7 para ir viendo esas clases.

Mejoras significativas que necesitanos no es introducir nuevos componentes sino mejorar los que ya hay.

y por otro lado cuantos programadores crees que tiene microsoft solo para darle soporte a visual studio y su C#, quizas puedan haber muchas cabezas calientes en Embarcadero pero por muchas que sean en microsoft tienen que haber muchas más y siempre irá muy por delante.

Aunque en los equipos para cada plataforma sean muchos no son lo suficiente como para hacerle el frente necesario.

jueves, abril 23, 2009 3:03:00 p. m.  
Anonymous Anónimo said...

No tengo nada en contra de linux trabaje en un proyecto grande para 930 terminales conectadas para una empresa debia ser todo linux + Oracle + java , la sorpresa fueron los costos aunque es dificil creer eso , y sistemas distribuidos en linux es algo muy complicado y tiene un costo superior a una implementacion windows , linux es bueno para servidores web para otra cosa le falta mucho, o sea de haber soluciones las hay pero tienen costos muy elevados

jueves, abril 23, 2009 3:46:00 p. m.  
Blogger Alfredo Novoa said...

la sorpresa fueron los costos aunque es dificil creer eso

No es nada difícil de creer, sobre todo habiendo javalíes de por medio.

Las herramientas que tienen suelen ser mucho menos productivas y se pierde más tiempo con tonterías.

Aunque piense usar servidores Linux (por ejemplo contratando servidores Linux en un centro de datos), el desarrollo desde luego lo seguiré haciendo todo en Windows y ni me planteo crear aplicaciones de escritorio para Linux. Si MoonLight funciona sin tocar nada pues estupendo y si no pues mala suerte.

jueves, abril 23, 2009 3:58:00 p. m.  
Anonymous Anónimo said...

El problemita que se presenta es que pensamos que todo lo OPEN es FREE y que tiene que ser asi , pero , que tal si a todos nosotros nos tocara trabajar GRATIS y OPEN?, otra cosa el que usa software libre necesariamente tiene que distribuir su software con los fuentes , ejemplo la licencia de Mysql lo usas , bueno tienes que distribuir los fuentes a tu cliente, o entiendo pq los programadores algunos creen que todo lo que es Open es gratis y bueno, en mi pais por ejemplo no conozco ningun abogado que trabaje OPEN , o gratis pq nosotros tenesmo que hacerlo?, como tu dices Alfredo las herramientas son menos productivas y logicamente linux tambien tiene sus problemas antes habia Mandrake y otros que van desapareciendo, es muy complicado mantener algo open , a no ser que pagues el soporte como RedHat y Ubuntu o Suse.

jueves, abril 23, 2009 5:11:00 p. m.  
Blogger Alfredo Novoa said...

por ejemplo la licencia de Mysql lo usas , bueno tienes que distribuir los fuentes a tu cliente

Eso si no quieres pagar. Si no quieres distribuir las fuentes pues pagas y listo.

Pero el software para la "nube" es lo más cerrado que hay por que al cliente no le das ni los ejecutables, y es una de las cosas por las que es interesante.

jueves, abril 23, 2009 5:21:00 p. m.  
Anonymous Anónimo said...

si , tienes razon pero como le voy a convencer hoy dia con tanta inseguridad informatica a mi cliente que sus datos estaran en un server fuera de la empresa, las empresas medianas/grandes , tiene todo dentro , servidor de dominio, emails todo , es buena la idea ahora la confianza todavia tengo mis dudas, en mi caso tengo clientes que son competencia entre si y sus costos son sagrados , asi como saldos de cuentas , proveedores , contactos si todo eso lo tengo fuera de la empresa de ellos para mi sera un problema

jueves, abril 23, 2009 5:38:00 p. m.  
Blogger Alfredo Novoa said...

Ya, está claro que eso no convence a todo el mundo. También hay que dar garantías de seguridad y confidencialidad.

Y también existen los clientes que están encantados de tener los servidores fuera de la empresa donde no puedan ser robados fácilmente y que otros se encarguen del mantenimiento, las copias de seguridad y todo eso.

jueves, abril 23, 2009 5:44:00 p. m.  
Blogger Junior said...

"Y también existen los clientes que están encantados de tener los servidores fuera de la empresa"

Quizas fuera pero no muy lejos, te pongo por ejemplo una empresa que que tiene sus datos en españa y su cede esta en mi país. ¿Cuantos puntos tiene que recorrer esa información para llegar aquí? Se pueden dar averias de conexión desde allá hasta llegar a su destino, y mientras tanto como pueden atender los usuarios con una fila de clientes en espera.

Por ejemplo en mi país conviene más que esos datos se encuentren dentro de la empresa y brindar el servicio de adentro hacia afuera.

jueves, abril 23, 2009 6:43:00 p. m.  
Blogger Unknown said...

Hola Marco Antonio,

Tienes noticias de cuando Embarcadero tiene planeado liberar el compilador que genere código de 64 bits?

miércoles, abril 29, 2009 7:48:00 a. m.  
Blogger Unknown said...

Ya alguien ha probado la nueva versión de Ubuntu para escritorio?

Me llama mucho la atención que casi todo el mundo sigue hablando como en el pasado, que Linux es solo para servidores, pero los adelantos de Linux en las distribuciones para escritorio escritorio son impresionantes.

Nosotros hicimos la prueba con la última distribución de Ubuntu en una portátil Acer con un procesador AMD Turion64 X2 y sin duda alguna en el rendimiento gráfico Windows XP y Vista sin dudas se queda mordiendo el polvo.

Otra muy agradable sorpresa fue la detección automática de nuestras impresoras de red (HP y Brother) y la impresión sin ningún problema.

Además ya Ubuntu tiene también su distribución para Netbooks la cuál no hemos probado mucho pero se ve por demás atractiva.

miércoles, abril 29, 2009 8:04:00 a. m.  
Blogger Unknown said...

Hola Alfredo,

Tu que eres un anti-javalí, o mejor dicho que no concuerdas con las filosofías javalianas esperas algún cambio importante con la adquisición de Sun por parte de Oracle?

Nosotros en la empresa somos lo que ustedes llaman "javalies". Utilizamos Eclipse, Spring, Hibernate y ExtJS.

miércoles, abril 29, 2009 8:11:00 a. m.  
Blogger Alfredo Novoa said...

Hola Miguel Angel,

Tu que eres un anti-javalí, o mejor dicho que no concuerdas con las filosofías javalianas esperas algún cambio importante con la adquisición de Sun por parte de Oracle?

Bueno, yo tampoco tengo mucho en contra de Java, aunque creo que .NET es mejor para lo que yo hago.

Y por desgracia las filosofías javalíes están cada vez más extendidas en entre los microchoferos (muchos quieren usar LINQ como si fuese Hibernate). Vamos, que no son filosofías exclusivamente javalíes, que gente que no usa bien un SGBD siempre ha habido.

No espero cambios importantes de momento, pero espero que a Sun se le pegue algo de la cultura sobre bases de datos que hay en Oracle y no que Sun contagie a Oracle con su analfabetismo en bases de datos.

Espero que mejore la integración entre Java y Oracle, y tienen muy fácil hacerlo mejor que M$ si el diseño se hace desde Oracle.

No se que va a pasar con MySQL. Supongo que se potenciará la versión comercial. Pero a mi MySQL nunca me ha interesado.

miércoles, abril 29, 2009 11:28:00 a. m.  
Blogger Junior said...

Si realmente quieren que MYSQL sea una buena opción a seguir tienen que cambiar muchas cosas, algunos dicen que MySql es mejor que SQLSERVER entre otras cosas y ellos atribuyen esto por la gran cantidad de aplicaciones que existen con este gestor vs SQLServer. Lo que ellos no analizan es que MySql es mas usado por que es gratis y que mejor si me dan gratis o a un costo mucho menor las herramientas que yo uso.

Pero yo prefiero pagar algo mas y ahorrarme muchos dolores de cabeza.

La verdad es que MYSQL le falta mucho para ser un SGBD Respetable para empresas que tengan que procesar grandes volumenes de información, y no es que no se haga la aplicación pero con mucho mas trabajo por parte de los desarrolladores. Y no es que SQLSERVER sea la planacea pero facilitan más lo que hago.

Veremos que tan barato quedará ahora que ya Mysql pertenece a Sun y Sun a Oracle y que van a hacer al respecto para poder decir como los que lo defienden a voca llena que es mejor..

miércoles, abril 29, 2009 5:34:00 p. m.  
Blogger Alfredo Novoa said...

Lo que ellos no analizan es que MySql es mas usado por que es gratis

Ni tampoco analizan lo que es más importante: que es lo que hacen esos sistemas.

Para muchas webs que hay por ahí MySQL es suficiente y es gratis y rápido haciendo cosas simples. Y tampoco me parece mal que lo usen.

La verdad es que MYSQL le falta mucho para ser un SGBD Respetable para empresas que tengan que procesar grandes volumenes de información, y no es que no se haga la aplicación pero con mucho mas trabajo por parte de los desarrolladores. Y no es que SQLSERVER sea la planacea pero facilitan más lo que hago.

En lo único que no estoy de acuerdo es en lo del volumen de datos.

Yo tengo muchos clientes que manejan pocos datos, pero MySQL sigue sin servirme porque aunque los datos sean pocos la complejidad de la programación muchas veces es la misma que cuando hay muchos datos.

Es más, cuando tienes muchos clientes pequeños cada uno pidiendo cosas distintas es cuando más necesitas tener herramientas productivas. Si usase Hibernate me iría directo a la quiebra.

miércoles, abril 29, 2009 5:50:00 p. m.  
Blogger Junior said...

y eso del gran volumen de información lo dije para que no me digan que estoy parcializado en absoluto pero como ya lo dijiste te sigo la corriente ni para aplicaciones pequeñas me ayuda.

miércoles, abril 29, 2009 11:32:00 p. m.  
Blogger Marco Antonio Santin Torres said...

Miguel Ángel lo único que sé es que liberaran el compilador de 64 bits a principios o mediados del próximo año, no se la fecha exacta.

Alfredo ¿Por qué dices que si usas Hibernate te vas a la quiebra? ¿Has probado NHibernate? He escuchado mucho de este último y me gustaría saber tú opinión.

jueves, abril 30, 2009 1:11:00 a. m.  
Blogger Andrés Ortíz said...

Hace unos posts atras alguien preguntaba por libros, Ian escribió criticando los malos libros que hay por ahi, pero yo si quiero recomendar y aconsejar algo que me llega y es MSDN Magazine.

No se compara aunque la publiquen en línea poderla tener entre las manos.

Amigo que quiere comprar libros, no gaste su plata y suscribase a esta revista, porque definitivamente escriben con pasíón estos amigos.

El mes de MArzo está muy bueno, JQuery, Silverligth Virtual Storage, Labguages Mix, etc etc

Saludos

jueves, abril 30, 2009 3:59:00 a. m.  
Blogger Alfredo Novoa said...

¿Por qué dices que si usas Hibernate te vas a la quiebra?

Creo que ya lo he explicado muchas veces. Porque la productividad se hundiría. Sería mucho peor que implementar la interfaz en ensamblador.

En cambio si vendiese horas de programación me vendría genial por que podría facturar montones de horas incluso para implementar las reglas de negocio más sencillas.

NHibernate es simplemente Hibernate portado a .Net. Es igual de maléfico.

jueves, abril 30, 2009 4:31:00 a. m.  
Blogger Eduardo Carvallo said...

Hola Alfredo, conococes algum blog o foro de bases de datos com buen nivel?

Nos aconsejas alguno?

viernes, mayo 01, 2009 9:08:00 p. m.  
Blogger Eduardo Carvallo said...

Es que se me ha presentado una duda
a la hora de implementar una regla de negocio en el banco que es relativamente simple. Es mejor definirla com check + function o con trigger? qual es la mejor forma?

lunes, mayo 04, 2009 7:07:00 p. m.  
Blogger Alfredo Novoa said...

Hola Eduardo, he puesto algunos enlaces en mi blog.

Hace años comp.databases.theory estaba bastante bien, pero ahora está casi muerto.

La lista de correo del Tercer Manifiesto tiene mucho nivel pero no trata sobre diseño de bases de datos sino de diseño de SGBD.

Respecto a lo de la regla de negocio casi siempre es mejor definirla con un check.

lunes, mayo 04, 2009 11:50:00 p. m.  
Blogger Eduardo Carvallo said...

pero si defino la regla com um check + function no estaria pecando de trabajar orientado a registro e no a conjunto?

Porque la regla se validara un registro por vez.

Lo digo porque podria hacer varias inserciones de una vez en una tabla.

Disculpen si estoy hablando tonterias.

lunes, mayo 18, 2009 4:12:00 a. m.  
Blogger Manuel said...

Mr. Marteeeeeeeens!!! Estas bien? Ha mucho que se sabe nada...

lunes, mayo 18, 2009 11:52:00 a. m.  
Blogger Alfredo Novoa said...

pero si defino la regla com um check + function no estaria pecando de trabajar orientado a registro e no a conjunto?

Tú no, pero el SGBD seguramente lo va a hacer.

Pero con la mayoría de los SGBD SQL también hay que trabajar registro a registro en los triggers.

Con SQL Server sí que puedes trabajar con conjuntos en los triggers.

Si usas SQL Server y te preocupa la velocidad y vas a hacer muchas inserciones del tipo:

insert into X select ...

Entonces sí que te puede compensar comprobar la restricción en el trigger aunque sea más trabajoso.

lunes, mayo 18, 2009 1:21:00 p. m.  
Blogger Eduardo Carvallo said...

Alfredo, es exactamente eso a lo que me referia, porque yo utilizo sql server 2005.

Asi quando hago un monton de inserciones en una tabla, puedo verificar las reglas de integridad con triggers utilizando la tabla inserted junto con los operadores de conjuntos (joins, etc).

Por ejemplo en una tabla de ventas voy a inserir y validar registro por registro. Pero en la tabla de venta_itens puedo validar por conjunto(en caso que insira varios itens para una venta).

Aunque las trigger sean mas trabajosas, me parecen muchiiiisimo mas facil que controlar essa integridad en la aplicacion con codigo em Delphi, por ejemplo.

Lo unico que me estan reclamando aqui en la empresa es que es dificil darle mantenimiento al codigo SQL.

lunes, mayo 18, 2009 4:44:00 p. m.  
Blogger Alfredo Novoa said...

Aunque las trigger sean mas trabajosas, me parecen muchiiiisimo mas facil que controlar essa integridad en la aplicacion con codigo em Delphi, por ejemplo.

Eso por supuesto, y además es mucho más seguro.

Lo unico que me estan reclamando aqui en la empresa es que es dificil darle mantenimiento al codigo SQL.

Pues que aprendan SQL. Y también hay que documentarlo bien. El código SQL al hacer muchísimas más cosas por línea que el código Delphi también necesita más documentación por línea de código.

El código SQL es mucho más fácil de mantener, siempre que sepas SQL, claro.

lunes, mayo 18, 2009 4:55:00 p. m.  
Blogger Alfredo Novoa said...

Pero en la tabla de venta_itens puedo validar por conjunto(en caso que insira varios itens para una venta).

¿Y como haces esto?

¿Tienes una tabla temporal y cuando acabas la venta haces un insert con un select?

Yo no lo hago así. Cuando un usuario graba una línea queda grabada en la tabla definitiva al momento. Esto me simplifica mucho las cosas.

miércoles, mayo 20, 2009 1:48:00 a. m.  
Blogger Eduardo Carvallo said...

La verdad es que es un ejemplo que imagine, pensando en un clientdataset
en el cual hago varios append e post e por fin um applyupdates para enviar los datos al banco.

miércoles, mayo 20, 2009 2:06:00 a. m.  
Blogger Alfredo Novoa said...

¿Y el DataSnap es capaz de insertar varias lineas con un solo INSERT?

Se puede hacer, pero me sorprendería bastante.

Por ejemplo:

INSERT INTO X
SELECT 'A'
UNION ALL
SELECT 'B'
UNION ALL
SELECT 'C'

Si las líneas se insertan de una en una con el ApplyUpdates entonces no ganas nada con el trigger.

miércoles, mayo 20, 2009 2:17:00 a. m.  
Blogger Junior said...

Ya que se esta hablando de este tema de trigger y herramientas que facilitan la abstración y hacen más facil el trabajo; quisiera saber si existe algo que mejore el funcionamiento de las CTE (Comun Table Expression)en Sql Server. Tengo una tabla recursiva la cual debe sumar valores de otra tabla relacionada y los registros maestros de la tabla recursiva deben sumar los resultados de los registros hijos hasta llegar al nivel N, disculpen por hacer la pregunta aquí, es que los ejemplos que he visto sobre CTE no llegan hasta donde quiero y no encuentro un foro que este al nivel de este para contestar esta pregunta.

miércoles, mayo 20, 2009 3:17:00 a. m.  
Blogger Junior said...

Actualmente logro el resultado pero utilizando una tabla temporal

miércoles, mayo 20, 2009 3:19:00 a. m.  
Blogger Eduardo Carvallo said...

Alfredo lo de DataSnap no lo he investigado.

Me sorprendio esa forma de trabajar que mencionaste, al inserir los itens de las ventas.

Pensaba que lo natural seria rellenar todos los datos de la venta junto con sus itens en la aplicacion, y cuando la persona confirma la venta entonces se manda a salvar todo en el banco, obteniendo el identity del maestro, y colocandolo en los detalles.

Em que momento tu obtienes el identity del maestro?

miércoles, mayo 20, 2009 1:20:00 p. m.  
Blogger Alfredo Novoa said...

Junior, en el foro de SQL Server de M$ seguro que te responden a eso sin problema.

Pensaba que lo natural seria rellenar todos los datos de la venta junto con sus itens en la aplicacion, y cuando la persona confirma la venta entonces se manda a salvar todo en el banco

Eso puede servir para una venta muy sencilla, pero para una complicada con control de stocks, lotes, números de serie, etc complica mucho las cosas. Supongo que por eso la mayoría de las tiendas de Internet no controlan los stocks en tiempo real.

Si grabas cada línea inmediatamente en la base de datos entonces todas las reglas de negocio te las valida el SGBD. Para confirmar la venta solo necesitas activar algún "flag" y además puedes continuar una venta que has dejado por la mitad aunque hayas apagado el ordenador. Si tienes pedidos de más de 300 artículos como alguno de nuestros clientes es de agradecer.

Em que momento tu obtienes el identity del maestro?

Casi nunca uso identities, solo cuando me obligan los triggers de SQL Server. Celko dice que los identities son para id-iotas :-)

El número y la serie del documento los grabo al darle al botón de nuevo documento, junto con el resto de los datos por defecto. Y además se pueden cambiar a mano.

miércoles, mayo 20, 2009 1:45:00 p. m.  
Blogger Eduardo Carvallo said...

A ver si entiendo.

Cuando le das al boton de nuevo documento ya grabas el registro maestro, con el numero de la venta y fecha, etc?

El nombre del cliente por ejemplo como como queda?

Lo grabas como string vacia y despues lo actualizas?

miércoles, mayo 20, 2009 5:01:00 p. m.  
Blogger Alfredo Novoa said...

Cuando le das al boton de nuevo documento ya grabas el registro maestro, con el numero de la venta y fecha, etc?

Bueno, en realidad lo grabo cuando están rellenos todos los campos obligatorios de la cabecera, pero sin tener que darle a ningún botón de grabar.

En el caso de una venta es cierto que se graba después de introducir el cliente porque es el único campo obligatorio que no tiene un valor por defecto.

miércoles, mayo 20, 2009 5:07:00 p. m.  
Anonymous Anónimo said...

Solo como comentario si les sirve, en una Venta Maestro detalle, tambien guardo item x item en la base de datos, lo que hago basicamente es colocar el codigo del cliente el cual estara asociado a todos los campos por default , Lista de precios , vendedores, Plazos y todo el resto ya esta asociado al codigo del cliente luego al introducir el primer item de la venta es alli donde guardo el master , ahora lo importante es que siempre uso un numero de registro interno y un numero de factura , la relacion Maestro detalle se basa en el numero de registro interno, una ves que la venta tenga un Item ya no se puede eliminar solo anular para no perder la secuencia de la numeracion interna

miércoles, mayo 20, 2009 6:33:00 p. m.  
Blogger PabloNetrix said...

Un inciso en la tertulia:

"Se acabó".
http://www.internetnews.com/bus-news/article.php/3819126/Micro+Focus+Snaps+Up+Borland+Compuware+Unit.htm

o también "Crónica de una muerte anunciada" (sólo que, por esta frase igual viene la SGAE a buscarme las cosquillas).

jueves, mayo 28, 2009 12:40:00 p. m.  
Blogger Alfredo Novoa said...

Un poco vieja la noticia, aunque todavía mantienen su web.

Los han comprado pagando menos de 50 millones de €

Es sorprendente lo rápido que puede desmoronarse una gran empresa de software.

jueves, mayo 28, 2009 1:56:00 p. m.  
Blogger Junior said...

Si en Redmond no logran curar con sus nuevos SO el fracaso de Vista y otros antepasados, y como esta la economia mundial, la caida de Boland le va a quedar pequeña.

jueves, mayo 28, 2009 3:20:00 p. m.  
Blogger Alfredo Novoa said...

Pues por lo pronto nos van a llenar los colegios de Windows.

jueves, mayo 28, 2009 4:29:00 p. m.  
Blogger Junior said...

Es una buena estrategia para mantenerse, y mas si las alternativas que existen o son de juguete y muy caras o gratis y con más problemas que soluciones.

jueves, mayo 28, 2009 4:54:00 p. m.  
Blogger PabloNetrix said...

Con todos mis respetos Junior (y Alfredo)... no creo que a MS le venga de "unos cuantos" cientos de miles de licencias de Windows, aunque yo doy por sentado que, por mucho que el gobierno diga que se van a potenciar las "soluciones libres" en esos portátiles (que ardo en deseos de ver cómo se las van a ingeniar para cumplir esta promesa sacada de la chistera, de los portátiles)... al final harán como han hecho con las eléctricas, en cuanto éstas han medio-alzado la voz para decir que, de devolver lo cobrado de más, nanai de la china:

Bajada de pantalones,hasta los tobillos.

Y puede que 7 sea el último SO (de MS) que conozcamos como tal (yo no lo sé, pero hay rumores). Lo digo por Azure, por ejemplo.

jueves, mayo 28, 2009 5:50:00 p. m.  
Blogger Alfredo Novoa said...

Yo creo que a M$ le queda cuerda para rato.

Lo de los portátiles no se como acabará porque todo es un despropósito. Supongo que se pelearán con las comunidades autónomas y se quedará en nada.

De donde saldrían los portátiles está claro: de los bolsillos de los padres. La idea consiste en obligar a los padres a comprar portátiles a El Corte Inglés, el software a M$ y los libros de texto con DRM a PRISA, y todo sin ningún plan de para que se van a usar esos ordenadores.

El Windows 8 puede que sea el Midori. Si les sale bien van a dejar al Linux a la altura del betún.

Lo del Azure es una chorrada, no tiene casi nada nuevo.

jueves, mayo 28, 2009 6:08:00 p. m.  
Blogger Junior said...

"Y puede que 7 sea el último SO (de MS) que conozcamos como tal".

Pienzo que todavia faltan condiciones para dejar atrás esta arquitectura y seguir con el modelo para la nube; las desiciones que toma MS son las que hacen que se sigan usando la versión anterior del SO.

jueves, mayo 28, 2009 7:07:00 p. m.  
Blogger Marco Antonio Santin Torres said...

Bueno y a todo esto, ¿en donde está Ian?

¿Alguien sabe de él? Ya se desaparecio.

viernes, mayo 29, 2009 4:26:00 p. m.  
Blogger Ramon Garcia Perez said...

Posiblemente ha de andar por ahi peleandose con el BETA de VS10 a ver como le va en la contienda!

viernes, mayo 29, 2009 9:21:00 p. m.  
Blogger Ian Marteens said...

:) Exacto. Y escribiendo...

lunes, junio 01, 2009 11:49:00 a. m.  
Blogger Ian Marteens said...

Por cierto, pensé que el entorno en WPF iba a ser más lento, pero va bastante bien en mi Windows Vista. Sólo me fastidia la diferencia del tipo de letra en el editor de código, pero es porque uno se acostumbra hasta a la Courier New.

No están todos los cambios anunciados para el EF. Hay una generación personalizada de código a golpe de plantillas... pero de momento es un coñazo. Está el puñetero POCO/MOJO/LOCO. Hay una opción StoreUpdateKind (más o menos) en las propiedades (vulgo campos) de las entidades (vulgo filas). Hay borrados en cascadas para las asociaciones (vulgo relaciones). Pero no hay todavía self-tracking entities.

Interesante: parece que el .NET 4 viene con "code contracts". Precondiciones, postcondiciones e invariantes expresadas al estilo AOP mediante atributos.

lunes, junio 01, 2009 11:55:00 a. m.  
Blogger Ian Marteens said...

o también "Crónica de una muerte anunciada".

But I won't cry for yesterday
there's an ordinary world
Somehow I have to find
and as I try to make my way
to the ordinary world
I will learn to survive

El Windows 8 puede que sea el Midori.

"Midori" es "verde" en japonés. ¿Tendrá algo que ver con los "brotes verdes" de la vicepresidenta?

lunes, junio 01, 2009 12:01:00 p. m.  
Blogger Alfredo Novoa said...

Yo creo que lo de los "code contracts" es con mucho lo más interesante. Te genera pruebas unitarias bastante buenas sin ningún esfuerzo.

Yo aun no he probado la beta esa. Me preocupa que el editor de código no se vea nítido sobre todo con fuentes pequeñas. Yo uso las proggy tiny.

lunes, junio 01, 2009 12:08:00 p. m.  
Blogger Ian Marteens said...

que el editor de código no se vea nítido sobre todo con fuentes pequeñas-

Ese es justo el problema.

lunes, junio 01, 2009 12:41:00 p. m.  
Blogger Ian Marteens said...

¡Ah, para que os riáis (o lloréis)! La semana pasada le pedí a dos "arquitectos de sistemas" que dividiesen una tabla en dos, y me dijeron que para qué, que era tradición de la empresa hacerlo con una tabla, y que habían tenido mucho éxito hasta el momento. Les respondí que la tabla violaba de forma estúpida las correspondientes formas normales. ¡Y me miraron como si estuviese hablando en chino! Luego comprobé que, efectivamente, no tenían ni zorra idea de lo que estaba hablando.

¿A que es divertido?

lunes, junio 01, 2009 12:47:00 p. m.  
Blogger Ian Marteens said...

... ah, perdón, he dicho un disparate: los contratos no se expresan mediante atributos, sino mediante llamadas. Más sencillo de implementar, menos interesante para el programador.

lunes, junio 01, 2009 1:06:00 p. m.  
Blogger Alfredo Novoa said...

¿A que es divertido?Hombre, es mejor tomárselo con humor.

¿Son de la generación de la LOGSE?

lunes, junio 01, 2009 1:34:00 p. m.  
Blogger Junior said...

"¡Ah, para que os riáis (o lloréis)! La semana pasada le pedí a dos "arquitectos de sistemas" que dividiesen una tabla en dos, y me dijeron que para qué,"jeje, yo recintemente he encontrado colegas pensantes de esos arquitectos. Resulta que estoy desarrollando una aplicación la cual debe obtener información que proviene de otro sistema. ellos solo me pueden ofrecer vistas y no acceso a manipular directamente las tablas. Bueno entoces pense que lo mejor para ellos y para mi es que ellos hagan vistas simples de las tablas y les pase entonces los requerimientos con vistas de cada una de las tablas que necesito, cuando ellos vieron todas esas vistas pusieron una cara de asombro que me hubiese gustado tirarle una foto. Ellos dijeron que eso se debe hacer como mucho en dos vistas y eran más o menos 20 que le estaba pidiendo. Entoces eso quiere decir que ellos tendran que ingeniarsela con esas tablas para darme la información aglomerada que después yo tendre que descomponer para que sea de utilidad al sistema que estoy desarrollando.

lunes, junio 01, 2009 3:33:00 p. m.  
Blogger Alfredo Novoa said...

Yo no paro de escuchar a la gente quejarse que los conocimientos de bases de datos de los desarrolladores no paran de caer día tras día.

Yo estoy pensando en contratar a algún chaval de 17 o 18 años para enseñarle yo.

Los recién titulados quieren empezar de "arquitectos" cobrando un pastón y no saben hacer una O con un canuto.

lunes, junio 01, 2009 3:52:00 p. m.  
Blogger Ian Marteens said...

Yo estoy pensando en contratar a algún chaval de 17 o 18 años para enseñarle yo.

Más fácil (y te lo digo en serio): escribe un libro. En este momento, ¿qué hay en el mercado hispano que merezca la pena, aparte de las posibles traducciones de libros escritos hace 30 años?

lunes, junio 01, 2009 4:05:00 p. m.  
Blogger Alfredo Novoa said...

Ya, pero yo lo que tengo es exceso de trabajo. Hacer eso me retrasaría aun más.

Esas traducciones de libros escritos hace 30 años sirven perfectamente, nada fundamental ha cambiado desde entonces, y los detalles se han ido actualizando en las sucesivas ediciones. El problema es que nadie los lee.

Hay libros nuevos estupendos en inglés como este que estoy leyendo:

Applied Mathematics for Database ProfessionalsEl problema es que pasan completamente desapercibidos entre la gran marea de publicaciones de baja calidad que nos inunda.

Además, de escribir algo tengo claro que primero lo escribiría en inglés.

Pero yo creo que primero hay que escribir las herramientas y después los libros.

Por muy bueno que sea un libro sobre bases de datos si luego resulta que no existe ningún SGBD decente pues tampoco ayuda mucho.

lunes, junio 01, 2009 4:37:00 p. m.  
Blogger Junior said...

"Pero yo creo que primero hay que escribir las herramientas y después los libros"

A eso es que me referia en post anteriores; por que a lo mejor si quieres escribir un libro que valga la pena sobre las herramientas de trabajo seria bueno también describir como darle solución a las chapuzas que se encuentran en ellas para poder hacer aplicaciones que funcionen decentes.

La mayoria de autores solo describen las bondades de las herramientas y lo que ellas superan pero nunca se refieren a los baches que se nos presentan, por lo mismo que comentabas, ellos son solo escritores de libros y no también de aplicaciones.

Y la mayoria de los que saben como se debe crear una herramienta de programacion y/o Base de Datos, solo les interesa escribir las reglas por que ellos tienen mucha pasta y no les gusta ensuciarce las manos con cosas de mortales.

Mientras tanto los mortales siguen cometiendo muchos pecados y condenando las herramientas que ellos crearon al eterno descanso por no decir al inf... y nacen otras con nuevos pecados que le siguen los pasos a las anteriores prontamente; pero esos son los mortales que crearon las herramientas, aqui llamese reyes y que le dejan a los Súbditos que somos los que las usamos y los que pagamos las concecuencias de los reyes.

lunes, junio 01, 2009 5:23:00 p. m.  
Blogger Junior said...

"Pero yo creo que primero hay que escribir las herramientas y después los libros"

A eso es que me referia en post anteriores; por que a lo mejor si quieres escribir un libro que valga la pena sobre las herramientas de trabajo seria bueno también describir como darle solución a las chapuzas que se encuentran en ellas para poder hacer aplicaciones que funcionen decentes.

La mayoria de autores solo describen las bondades de las herramientas y lo que ellas superan pero nunca se refieren a los baches que se nos presentan, por lo mismo que comentabas, ellos son solo escritores de libros y no también de aplicaciones.

Y la mayoria de los que saben como se debe crear una herramienta de programacion y/o Base de Datos, solo les interesa escribir las reglas por que ellos tienen mucha pasta y no les gusta ensuciarce las manos con cosas de mortales.

Mientras tanto los mortales siguen cometiendo muchos pecados y condenando las herramientas que ellos crearon al eterno descanso por no decir al inf... y nacen otras con nuevos pecados que le siguen los pasos a las anteriores prontamente; pero esos son los mortales que crearon las herramientas, aqui llamese reyes y que le dejan a los Súbditos que somos los que las usamos y los que pagamos las concecuencias de los reyes.

lunes, junio 01, 2009 5:24:00 p. m.  
Blogger Junior said...

Las conexiones lentas hacen que se repitan los comentarios. Cuando mejoraran los de google esto.

lunes, junio 01, 2009 5:27:00 p. m.  
Blogger Alfredo Novoa said...

si quieres escribir un libro que valga la pena sobre las herramientas de trabajo seria bueno también describir como darle solución a las chapuzas que se encuentran en ellas para poder hacer aplicaciones que funcionen decentesEso ya se ha hecho y además muy bien como por ejemplo en el libro que acabo de citar. Pero está sirviendo de poco. La gente quiere dedicarse a la informática sin aprender informática.

La inmensa mayoría de los blogs de desarrollo de software que veo o se dedican a copiar de la MSDN y similares o a hablar de la psicología de los equipos de trabajo. La técnica no le interesa a nadie.

La mayoria de autores solo describen las bondades de las herramientas y lo que ellas superan pero nunca se refieren a los baches que se nos presentan,Yo creo que es peor aun. La única fuente de información que usa la mayoría son las notas de prensa de los fabricantes.

Y la mayoria de los que saben como se debe crear una herramienta de programacion y/o Base de Datos, solo les interesa escribir las reglas por que ellos tienen mucha pasta y no les gusta ensuciarce las manos con cosas de mortales.O porque no se atreven a dejar su trabajo e invertir todos sus ahorros en algo que probablemente poca gente va a valorar.

No es tan fácil. Cuando eres joven tienes bastante tiempo pero no tienes conocimientos ni dinero ni experiencia. Cuando eres menos joven ya tienes conocimientos, experiencia y algo de dinero pero entonces tienes gastos y responsabilidades. Y cuando eres viejo ya tienes tiempo, dinero, experiencia y menos responsabilidades pero ya no tienes ganas ni energías.

lunes, junio 01, 2009 5:41:00 p. m.  
Blogger Junior said...

En un mundo perfecto si hubieran herramientas bien diseñadas los libros malos serian mejores por que se referirian a bondades y no existirian malos diseños y bugs y los buenos serian super excelentes.

"O porque no se atreven a dejar su trabajo e invertir todos sus ahorros en algo que probablemente poca gente va a valorar"y lo dificil es que hasta que ellos
no lo hagan se seguira el circulo que describi más arriba sobre las herramientas que duran poco.

No se valorarian si no hicieran su cometido; y claro un poco de mercadeo, por que si no das a conocer algo muy pocos lo sabran.

y para ser más perfecto tendrian que apartarse esas empresas que cuando no pueden darle una solución acabada a esas herramientas lo completan con mucho mercadeo y ya esta.

Pero es la descripción de un mundo perfecto, no lleno de intereses.

lunes, junio 01, 2009 6:14:00 p. m.  
Blogger Alfredo Novoa said...

y lo dificil es que hasta que ellos
no lo hagan se seguira el circulo que describi más arriba


Pues sí. Hay muchos círculos viciosos en la informática.

Como el de los autores que aprenden leyendo tonterías y sirven de fuente para nuevos autores de tonterías.

lunes, junio 01, 2009 6:17:00 p. m.  
Blogger Junior said...

Es que ellos lo ven con el sendido de cuanto dinero van a hacer con esos libros, no que esos libros van a ser una solución a los problemas de sus lectores y mientras menos lucha cojan haciendolo mejor para ellos. Es lo que se puede ver en este post "Una decepción y un rayo de esperanza".

lunes, junio 01, 2009 6:35:00 p. m.  
Blogger Ramon Garcia Perez said...

Donde encuentro un diccionario de los terminos y regionalismos (Pasta, Chapuzas...etc) usados por ustedes en España me pierdo algunas cosas cuando leo los comentarios del blog, si es que existe.

PD: Soy de República Dominicana

lunes, junio 01, 2009 8:32:00 p. m.  
Blogger Alfredo Novoa said...

Tito, casi todos los encuentras en el diccionario de la RAE.

http://buscon.rae.es

Chapuza no creo que sea un regionalismo.

lunes, junio 01, 2009 9:05:00 p. m.  
Blogger Junior said...

Es cierto, chapuza se usa en todos los paises de habla hispana, sinonimo de cosas mal creadas en Rep. Dom. Cuando le dicen chapuzero o eso esta hecho a la brigandina o eso es una porqueria es lo mismo.

lunes, junio 01, 2009 9:24:00 p. m.  
Blogger Ramon Garcia Perez said...

Hola amigos concurse para una beca en www.rit.edu para una maestría en ingeniería de software mediante un organismo local falle por insuficiente puntuación en el TOEFL quisiera saber si vale o valía la pena ya que pienso prepararme y concursar para el próximo año. Tengo mucho tiempo ya programando en Delphi, desde hace un tiempo 2001 hacia acá leyendo y jugando por llamarlo de cierta forma con .Net y C# he conseguido algunas estrellas en www.dce2005.com 3 en total en el viejo y el nuevo programa, pertenezco a una pequeñísima empresa de software en una localidad con poco desarrollo del país en realidad necesito orientación de parte de los que considero expertos y mI blog favorito el único que leo de hecho.
A ver que me dicen actualmente estoy estudiando el curso de Intsight (Programación con ADO.NET en C#)

martes, junio 02, 2009 9:16:00 p. m.  
Blogger Ramon Garcia Perez said...

Dos dias y nadie se anima a darme un rayo de esperanza sobre mi anterior comentario.

jueves, junio 04, 2009 10:13:00 p. m.  
Blogger Alfredo Novoa said...

Tito, no creo que nadie de aquí pueda contestar a esa pregunta. Tendrás que decidir tú si vale la pena o no.

viernes, junio 05, 2009 1:43:00 p. m.  
Blogger Junior said...

Ian espero verte pronto posteando sobre la continuación de Mr. Butters para seguir comparando lo que es imaginario con lo que se ve en muchos lugares de este mundo cruel.

viernes, junio 05, 2009 6:55:00 p. m.  
Blogger PabloNetrix said...

Uy si que ha crecido esto en pocos dias... xD

La semana pasada le pedí a dos "arquitectos de sistemas" que dividiesen una tabla en dos, y me dijeron que para qué, (...) Luego comprobé que, efectivamente, no tenían ni zorra idea de lo que estaba hablando.

Estooo... ¿Nombre de la empresa?

Es para enviar algun curriculum y tal... :-)

lunes, junio 08, 2009 12:25:00 p. m.  
Blogger Alfredo Novoa said...

Se dice el pecado, pero no el pecador ;-)

lunes, junio 08, 2009 12:26:00 p. m.  
Blogger PabloNetrix said...

Jejejeje muy buena esa Alfredo ;-)

Pero vamos, no me diras que no es sangrante (e indignante) el tema. Yo ya te digo que no cumplo el perfil de un Arquitecto (nótese la mayúscula, indicativa de que se refiere a alguien que sabe "de lo suyo") de sistemas, pero vamos que para que un mindundi esté cobrando el pastizal que se le supone a un puesto con un nombre de esa rimbombancia... joer pa eso ya voy yo que seré casi igual de mindundi pero al menos "me suena" lo de las formas normales (y si no te cebas mucho con los requisitos te puedo diseñar una BDD que cumpla hasta con la tercera incluso...)

lunes, junio 08, 2009 4:37:00 p. m.  
Blogger Alfredo Novoa said...

El problema es que el perfil de "arquitecto" tiene poco que ver con los conocimientos.

Yo una vez me encontré con un ingeniero en una empresa cliente que decía que DBase tenía todo lo que podía ser deseable para un servidor de comunicaciones con 15.000 clientes, y que eso de los SGBD era una chorrada. Y estoy hablando en serio.

lunes, junio 08, 2009 4:47:00 p. m.  
Blogger Eduardo Carvallo said...

Alfredo e leido varios post tuyos donde dices que es muy practico trabajar siempre conectado con el sgbd. Tengo una duda.

Eso se aplica tambien a sistemas en tres camadas?

No se supone que la ventaja de las tres camadas es reaprovechar las conexiones?

Eso de las camadas me tiene medio confundido.

lunes, junio 08, 2009 4:58:00 p. m.  
Blogger Alfredo Novoa said...

Eduardo, en español se dice tres capas, lo de tres camadas suena bastante raro.

¿A que tipo de capas te refieres? ¿Layers o tiers?

Hay un montón de confusión en estos temas.

Cuando hablo de SGBD normalmente no me refiero a un producto en concreto sino a quien ejerce esa función.

Por ejemplo si utilizas un servidor intermedio que utiliza por detrás un SQL Server entonces la suma del servidor intermedio y SQL Server forma tu SGBD.

lunes, junio 08, 2009 5:06:00 p. m.  
Blogger Eduardo Carvallo said...

rsrsrs. Lo de camadas es porque actualmente estoy en Brasil, asi a veces se me sale un poco el Portugues.

Cuando hablo de capas me refiero, a por ejemplo: Aplicacion en delphi + servidor de aplicacion (una dll en el IIS) + sql server.

Conectado la aplicacion con el servirdor de aplicacion a traves del protocolo SOAP.

lunes, junio 08, 2009 5:15:00 p. m.  
Blogger Alfredo Novoa said...

Ah, pensaba que eras brasileño. No te preocupes por esas cosas, lo decía para aclarar.

Un SGBD no es más que un caso especial de servidor de aplicaciones.

En ese caso la suma de IIS más SQL Server son tu SGBD.

Entonces si la aplicación Delphi trabaja conectada al servidor de aplicaciones entonces trabaja conectada al SGBD.

Lo importante es no intentar hacer en la aplicación Delphi las cosas que son mucho más fáciles y más seguras de hacer en el SGBD, tenga este la forma que tenga.

Por ejemplo estoy harto de ver como para borrar una tabla de miles de registros la gente se trae todos los registros al cliente y los va devolviendo uno por uno al servidor para ir borrándolos uno a uno en lugar de enviar símplemente un: delete tabla.

Y después aun me llaman retrógrado :-)

lunes, junio 08, 2009 5:29:00 p. m.  
Blogger PabloNetrix said...

Alfredo, ¿pero era realmente ingeniero (uséase, titulado) el individuo en cuestión? ¿Ingeniero en Informática o, al menos, en algo que mínimamente tenga que ver?

Y con respecto al "título" de arquitecto, ¿no será en parte culpa de los criterios que han imperado a la hora de "inventarse" estas jerarquías (por llamarlo de alguna manera) clasificatorias de puestos de trabajo en TI? Es decir: ¿Qué o quién normaliza lo que es un ARQUITECTO DE SISTEMAS? ¿Qué o quién ha especificado qué es un DBA? etc etc.

Ahora mismo estoy recordando una frase tuya que venia a decir algo así como que la informática dejó de ser "informática" en cuanto se ocuparon de ella "informáticos", y no físicos o matemáticos.

En fin.

lunes, junio 08, 2009 5:35:00 p. m.  
Blogger PabloNetrix said...

Perdón por el doble post:

estoy harto de ver como para borrar una tabla de miles de registros la gente se trae todos los registros al cliente y los va devolviendo uno por uno al servidor para ir borrándolos uno a uno

No puede ser. No, ahora no cuela Alfredo, tienes que estar de cachondeo macho... que no hombre que no :-P

lunes, junio 08, 2009 5:37:00 p. m.  
Blogger Alfredo Novoa said...

Alfredo, ¿pero era realmente ingeniero (uséase, titulado) el individuo en cuestión? ¿Ingeniero en Informática o, al menos, en algo que mínimamente tenga que ver?


En telecomunicaciones, creo. Y el proyecto movía muchos millones de las antiguas pesetas.

El lío que había montado ya te lo puedes imaginar: velocidad penosa, pérdida de datos, cliente final que no paga y amenaza con demandar, etc, etc.

Al final se rehizo todo con Interbase y de maravilla.

Y con respecto al "título" de arquitecto, ¿no será en parte culpa de los criterios que han imperado a la hora de "inventarse" estas jerarquías (por llamarlo de alguna manera) clasificatorias de puestos de trabajo en TI? Es decir: ¿Qué o quién normaliza lo que es un ARQUITECTO DE SISTEMAS?


Cada uno puede autoproclamarse o nombrar a sus empleados lo que le de la gana. También es normal que una misma persona sea un supermegaconsultor hacia el exterior y un "piernas" hacia el interior.

Normalizarlo sería aun peor por que los cargos serían otorgados por la "burrocracia" en lugar de por los méritos como cuando ocurre ahora cuando hay mucha suerte.

lunes, junio 08, 2009 5:48:00 p. m.  
Blogger Alfredo Novoa said...

No puede ser. No, ahora no cuela Alfredo, tienes que estar de cachondeo macho... que no hombre que no :-P



¿No has oido hablar del famoso mapeado objeto/relacional?

lunes, junio 08, 2009 5:49:00 p. m.  
Blogger Eduardo Carvallo said...

Pues si yo tengo todas mis reglas de negocio en el banco sql server, entonces cada aplicacion tendra que mantener una conexion abierta con el servidor de aplicaciones, que a su vez tendra una conexion con el sql server, para poder validar cada registro que voy mandando a inserir.

Eso es exactamente lo que no recomiendan. Lo que yo he leido dice que conectar y desconectar lo mas rapido posible es lo recomendable y no mantener abierto.
Para reutilizar las conexiones.

Claro que se complican algunas cosas como por ejemplo el login de usuario.

lunes, junio 08, 2009 5:53:00 p. m.  
Blogger Alfredo Novoa said...

Pues si yo tengo todas mis reglas de negocio en el banco sql server, entonces cada aplicacion tendra que mantener una conexion abierta con el servidor de aplicaciones, que a su vez tendra una conexion con el sql server, para poder validar cada registro que voy mandando a inserir.



No, no es cierto. El servidor de aplicaciones puede tener una piscina de conexiones a SQL Server y reutilizarlas. Esto es típico de las aplicaciones Web.

Eso es exactamente lo que no recomiendan. Lo que yo he leido dice que conectar y desconectar lo mas rapido posible es lo recomendable y no mantener abierto.
Para reutilizar las conexiones.




Esta recomendación viene de la época en la que un servidor de bases de datos tenía 32 megas de RAM y se ha mantenido por que la gente sigue recetas sin pensar en lo que hace.

Una conexión entre el servidor de aplicaciones y SQL Server ocupa muy poca memoria para los servidores modernos. Si tienes menos de 100 conexiones puedes tenerlas abiertas todo el rato que el consumo de memoria es ridículo.

lunes, junio 08, 2009 6:00:00 p. m.  
Blogger Junior said...

y eso de los arquitectos e ingenieros que opinan de lo que no conocen bien, es proporcional al desarrollo del país.

lunes, junio 08, 2009 9:14:00 p. m.  
Blogger Alfredo Novoa said...

Inversamente proporcional

lunes, junio 08, 2009 9:18:00 p. m.  
Blogger Junior said...

Lo digo en el sentido de que mientras menos desarrollado es el país se encuentran más arquitectos e ingenieros con los mismos pensamientos citados

lunes, junio 08, 2009 9:28:00 p. m.  
Blogger Junior said...

Al decirlo asi se ve que es inversamente proporcional. Pero si lo digo mientras más atrasado es el país más se encuentran (profesionales) con esos pensamientos.

lunes, junio 08, 2009 9:43:00 p. m.  
Blogger PabloNetrix said...

Buff... Qué chirriante me suena eso de "piscina" de conexiones. :P

martes, junio 09, 2009 11:36:00 a. m.  
Blogger Alfredo Novoa said...

¿Y como la llamas entonces?

¿Charca?

Cuando hacía programas para centrales nucleares allí la piscina de elementos combustibles era una piscina de verdad :-)

martes, junio 09, 2009 12:10:00 p. m.  
Blogger Eduardo Carvallo said...

Alfredo, solo que de esa forma com la piscina de conexiones, no puedo utilizar la seguridad de la base de datos.

Me refiero a los permisos de usuario, etc.

martes, junio 09, 2009 1:18:00 p. m.  
Blogger Alfredo Novoa said...

Alfredo, solo que de esa forma com la piscina de conexiones, no puedo utilizar la seguridad de la base de datos.



Exacto. Por eso yo tengo una conexión a la base de datos por cada cliente. Con el giga de RAM a menos de 10€ me preocupa bastante poco gastar unos pocos megas más.

En los casos en los que todo el mundo se conecte usando el mismo usuario como en muchas aplicaciones Web, sí puedes usar una piscina de conexiones. Pero no deja de ser otra chapuza para rodear las limitaciones de SQL Server.

martes, junio 09, 2009 1:27:00 p. m.  
Blogger Junior said...

Entoces si las conecciones son tuberias conectadas a un SGBD decente la piscina será una fuente de datos cristalina que solo se contaminará si entran esos tipos de arquitectos. Si es DBase, FoxPro y los otros tantos que andan por ahí el liquido ya de por si ha sido contaminado antes de ponerle la mano cualquiera que pretenda usarla. A veces también puede contaminarse por la inflexibilidad que ofrecen las herramientas y los casos complejos que esta tiene que resolver si no se tiene mucho cuidado ej: Los Provider de delphi se puede trabajar de risa mientras se hace lo que ellos permiten, pero si se quiere algo más de funcionabilidad se le presentan migrañas para solucionar el problema.

martes, junio 09, 2009 1:40:00 p. m.  
Blogger PabloNetrix said...

¿Y como la llamas entonces?
¿Charca?


Jacuzzi. ;-)

No, en serio, hay términos que no deben traducirse, principalmente porque somos propensos a coger el primer significado literal de la palabra que nos devuelve Google (o leemos en el Collins Pocket) y... a lo mejor el ámbito de la expresión original no es "ese" exactamente.

Es como lo de "Gran Hermano". Coge el subnormal del becario de turno y hace una traducción literal de "Big Brother". Ahí, con un par.

Pues el término "Pool" entra, en mi opinión, en ese grupo de términos, como "Release", que es mejor dejar "como está".

miércoles, junio 10, 2009 5:22:00 p. m.  
Blogger PabloNetrix said...

De nuevo perdón por el doble post.

Uno de los significados (sinónimos más bien) de Pool es stockpile, cuya definición me cuadra bastante más que lo de "piscina":

"A supply stored for future use, usually carefully accrued and maintained".

Y una traducción correcta para stockpile (correcta para utilizar en este supuesto, me refiero) sería "Reserva".

Una Reserva de conexiones.

miércoles, junio 10, 2009 5:34:00 p. m.  
Blogger Alfredo Novoa said...

Pues yo creo que los únicos términos que no deben de traducirse son los que son imposibles de traducir. Si no para eso ya hablamos directamente todo en inglés. Para mí pool y release forman parte de las palabras que hay que traducir.

Además el término piscina se usa para eso mismo desde hace mucho tiempo. Ya te digo que en Iberdrola no escuché nunca decir "la pool de elementos combustibles" ni "la pool de combustible elements".

Y la cagada de lo de Gran Hermano parece que es de un "ilustre escritor" que lo tradujo así de mal en 1952.

miércoles, junio 10, 2009 5:40:00 p. m.  
Blogger Alfredo Novoa said...

Pues sí, reserva seguramente sea una mejor traducción.

miércoles, junio 10, 2009 5:48:00 p. m.  
Blogger PabloNetrix said...

Sí, yo lo de la piscina tambien lo vengo oyendo desde hace bastante, pero seguramente sea un ejemplo más de lo que decías del "ilustre escritor" encargado de traducir el libro de Orwell.

Que era para haberle dado "a good pair of wafers" ;-)

Ojo que yo soy partidario de traducir todo lo que se pueda porque el exceso de anglicismos técnicos es sangrante y quieras que no, eso debilita el idioma (me refiero a que no puedes utilizarlo como idioma de conversaciones técnicas sino que al no renovarse, va quedando como un "idioma para paletos"). Pero, cuando digo que souy partidario de traducir, es eso: Traducir, no "castellanizar" sin ton ni son, sobretodo los infinitivos (linkar, googlear, bloguear, dropar, updatear...)

miércoles, junio 10, 2009 5:59:00 p. m.  
Blogger Alfredo Novoa said...

Yo es que veía mucho Mazinger Z de niño y entonces me parece normal guardar cosas en una piscina O:-)

Respecto a lo de traducir estamos de acuerdo.

miércoles, junio 10, 2009 6:01:00 p. m.  
Blogger PabloNetrix said...

Yo es que veía mucho Mazinger Z de niño y entonces me parece normal guardar cosas en una piscina O:-)

Jajajaja xDDDDDDDD Buenisimo

miércoles, junio 10, 2009 6:06:00 p. m.  
Blogger Junior said...

Me gustar ver que este foro se mantenga siempre vivo y se mantengan posteando cosas que nos nutran de conocimientos. Aunque hay muchas paginas interesantes esta es mi faborita.

miércoles, junio 10, 2009 6:26:00 p. m.  
Blogger Junior said...

Y una pregunta ¿Si les toca crear una base de datos para un servidor con plataforma UNIX o LINUX, Cuál SGBD Recomendaran a sus clientes, si es una empresa mediana que no puede pagar por ORACLE(ELCARO)?

Bueno ya son dos

¿Habría que cojer la lucha con MySQL o Postgrees?

domingo, junio 14, 2009 2:43:00 p. m.  
Blogger Eduardo Carvallo said...

Hola amigos, termine un curso de Oracle este fin de semana.

El profesor nos dio un ejemplo de una empresa donde se cambiaron de delphi para Java e no fue mucho lo que tuvieron que programar, porque casi todas las funcionalidades del sistema estaban escritas como procedimientos almacenados.

Que les parece esa forma de hacer las cosas?

Esta claro que si hubieran tenido que cambiar de banco, si que tendrian que programar mucho.

domingo, junio 14, 2009 9:33:00 p. m.  
Blogger Alfredo Novoa said...

Que les parece esa forma de hacer las cosas?

Pues no muy bien porque hay más formas de implementar la funcionalidad con un SGBD que los procedimientos almacenados.

Cuando algo se puede implementar con consultas, vistas y restricciones es mejor que hacerlo con procedimientos almacenados.

Esta claro que si hubieran tenido que cambiar de banco, si que tendrian que programar mucho.

Pero eso casi nunca pasa y tampoco hubiesen tenido que programar mucho porque los dialectos de SQL se parecen mucho.

En cambio así han ahorrado mucha programación en Java.

Cambiar de lenguaje de programación es muchísimo más habitual que cambiar de SGBD.

Ahora es bastante habitual portar aplicaciones de Delphi a Java y C#.

domingo, junio 14, 2009 9:50:00 p. m.  
Blogger Junior said...

Coincidiendo con Alfredo y post anteriores de Ian, Yo pienzo que lo importante es conocer todos o en su mayoria los recursos que nos ofrece el SGBD para así darnos cuenta de que nos puede funcionar mejor en cada escenario, si puedo aplicar restricciones con un Check para que complicarme la vida programando código que no va a ser más óptimo que lo que hace la restricción. Y como se dice por ahí, si fuera un Javalí estubiera buscando la forma de hacerlo todo a código por que la ficción de "si no es a código no es seguro" esta tatuado en su frente.

domingo, junio 14, 2009 11:21:00 p. m.  
Blogger Alfredo Novoa said...

Yo creo que es porque la inmensa mayoría de los programadores no tienen nada claro lo que es un SGBD.

Ahora la mayoría los microsiervos ya han descendido al nivel de los javalíes y ya casi no hay diferencia entre lo mal que trabajan unos y otros. M$ ayuda a esto todo lo que puede.

Yo creo que en la mayoría de los proyectos faltan DBAs y jefes de proyecto competentes que sepan poner orden y prohiban esas malas prácticas.

Lo más grave es que vamos a peor. Algunos programadores viejos sabemos para que sirve un SGBD, pero los jóvenes cada vez menos, y cada vez hay más proyectos dirigidos por gente que no tiene ni la más remota idea de como hay que trabajar con datos.

El lado bueno es que los que sabemos un poco somos cada vez más competitivos.

lunes, junio 15, 2009 2:21:00 p. m.  
Blogger Junior said...

"Yo creo que en la mayoría de los proyectos faltan DBAs y jefes de proyecto competentes que sepan poner orden y prohiban esas malas prácticas"

Pienzo el problema se da porque muchos de esos DBAs se han quedado también en la era Medieval y tampoco conocen cuales son las capacidades de los SGBD.

Por otro lado están los egresados de las universidades que salen crudos y no encuentran personas que los guíen por el camino correcto, y peor áun, muchos de ellos salen sin lógica de programación. Se da mucho en donde se piensa que la Ing. en sistemas es algo más que programar, pero un Ing. en Sistemas que no sepa programar ¿Que es entonces?.

Se sabe que la Ing. En sistemas es Algo más que programar pero es requisito No. 1 Saber hacerlo si se quiere llamar Ing. en Sistemas.

¿Como puede guíar bien un Director de Programación que no sabe lo que sus programadores estan haciendo por dentro, si solo sabe lo que se debe obtener?.

Y como dice Alfredo, Microsoft que ayuda a despistar a los que aprender como se hacen las cosas bien.

¿Será cierto que UML con esos patrones y todas esas figuras que se han inventado ayuden realmente ha hacer software de calidad, cuando los que están diseñandolos en su mayoria NO son los que cojeran el teclado para digitar el código necesario para que el programa funcione?

Y creo que el parecido entre el microsiervo y el javalí parte de esos patrones que se han inventando, aunque los de m$ los hacen con otra mentalidad a los de java, por que la diferencia entre los de java es que les gusta hacer todo a codigo y los de microsoft creen que se pueden generar un monton de código haciendo diagramas.

lunes, junio 15, 2009 4:22:00 p. m.  
Blogger Marco Antonio Santin Torres said...

Ya deberiamos formar un foro llamado "Los seguidores de Ian" y que el moderador sea Alfredo.

martes, junio 16, 2009 7:59:00 p. m.  
Blogger Alfredo Novoa said...

No, yo de moderador nada :-)

martes, junio 16, 2009 8:08:00 p. m.  
Blogger Ramon Garcia Perez said...

No, yo de moderador nada :-)

JEJEJE

Que tiene de malo lo de ser moderador, supongo y espero que asi sea, problema de tiempo o algo por el estilo, ya que, perteneciendo y de la manera que lo haces en este blog ...una almita sensible no eres

Capacidad y condiciones te sobran.

martes, junio 16, 2009 8:52:00 p. m.  
Blogger Eduardo Carvallo said...

Sin duda que el sgbd es parte vital de un sistema de información.

El conocerlo bien nos ayuda a no ponernos a reinventar ruedas.

Em mi poquisima experiencia con los sgbd, ya puedo darme cuenta como utilizandolo bien agilizan el desarrollo de las aplicaciones.

Ahora tengo una gran duda.

Como hago para aprovechar todo lo que un sgbd me ofrece, si tengo que hacer un producto multibanco?

Lo de reescribir, por ejemplo, todas mis vistas, mis restricciones, para varios bancos me parece mucho trabajo.

Y solo en pensar en mantener eso, ya me cansa.

Sera que en un caso asi esta justificado utilizar hibernate por ejemplo??

domingo, junio 21, 2009 12:25:00 a. m.  
Blogger Alfredo Novoa said...

Lo de reescribir, por ejemplo, todas mis vistas, mis restricciones, para varios bancos me parece mucho trabajo.

Lo único que tendrías que reescribir de las vistas son los triggers. Y de con las restricciónes parecido.

Sera que en un caso asi esta justificado utilizar hibernate por ejemplo??

No, por que para eso usas solo Entry Level ANSI SQL y ya tienes algo mejor que Hibernate.

domingo, junio 21, 2009 4:00:00 a. m.  
Blogger Ramon Garcia Perez said...

HOLA TODOS!

No sabia donde poner esta pregunta asi que lo puse aqui. Espero que no sea algo tonto o "imposible de lograr"

Es posible en Intebase determinar si un FOREING KEY esta en uso, la idea es si una referencia esta activa cuando en una tabla que tiene una referencia a otra ya hay registros.

Ej.
Una tabla de productos o articulos donde tengo referencias desde las lineas de la facturas, en entradas y salidas de inventario ...etc.

Una solucion podria ser:
create procedure FK_EN_USO
(
COD varchar(30)
)
returns
(
FK_ACTIVA char(1)
)
as
begin
SELECT 'S' FROM RDB$DATABASE
WHERE
EXISTS (SELECT * FROM TABLA_CON_FK WHERE TABLA_CON_FK.CODIGO = :COD)

UNION
SELECT 'N' FROM RDB$DATABASE
WHERE
NOT EXISTS (SELECT * FROM TABLA_CON_FK WHERE TABLA_CON_FK.CODIGO = :COD)
INTO
:FK_ACTIVA;

SUSPEND;
end

Pero y si tengo mas tablas referenciando entonces que hago agregar mas UNION no funciona creo.

lunes, junio 29, 2009 11:07:00 p. m.  
Blogger Alfredo Novoa said...

Puedes probar a borrar la tabla, y si no te deja es que hay una FK activa :-)

Si la borra entonces haces un rollback.

lunes, junio 29, 2009 11:22:00 p. m.  
Blogger Eduardo Carvallo said...

Hola a todos. Me toco hacer una vista que se puede actualizar (insert, update, delet).

Implemente las actualizaciones con triggers instead of que graban en tres tablas.

Estoy con un problema. Necesito el identity de la primera tabla.

El @@identity me trae el identity de la ultima tabla donde la trigger dio insert.

Alguien ya paso por eso??

Estoy utilizando la vista desde un clientdataset. Necesito ese identity porque es el campo clave y debo mostrarlo al usuario.

Agradezco qualquier ayuda.

viernes, julio 03, 2009 2:45:00 a. m.  
Blogger Junior said...

Saludos Eduardo..

De seguro que si ya has estudiado los cursos a distancia de Ian, te habras dado cuenta que este campo que se tiene como clave primaria con el atributo identity no es necesario mostrarlo, ya Ian se ha referido claramente sobre los códigos y como se deben utilizar en los cursos y se lo agradezco mucho por que antes estaba muy confundido sobre esto.

Aunque si necesitas eso, una idea que me llega a la mente sería crear una tabla que almacenara el @@identity generado por la primera tabla pero este se insertaría después de haber insertado todos los datos de las tablas siguientes utilizando una variable local que almacenara el identy mientras se insertan datos en las otras
entoces seria necesario crear un store procedure que consulte el @@identity que será el generado por la tabla que se creo para almacenar el identity de la primera tabla y luego con el mismo consultar el identity de la primera tabla que estara almacenado podria devolverlo en el result del Sp. Este SP seria llamado desde el modulo de datos donde necesitas el valor.

viernes, julio 03, 2009 8:19:00 p. m.  
Blogger Alfredo Novoa said...

este campo que se tiene como clave primaria con el atributo identity no es necesario mostrarlo

Yo diría más bien que es necesario no mostrarlo.

Mira a ver si te sirve esto:

http://msjawahar.wordpress.com/2008/01/25/how-to-find-the-last-identity-value-inserted-in-the-sql-server/

viernes, julio 03, 2009 8:48:00 p. m.  
Blogger Junior said...

Ok, reinvente un poco la rueda con la idea que se me llego a la mente, con el SCOPE_IDENTITY() se resuelve, esa función y la IDENT_CURRENT(‘tablename’)
las agregaron a partir de SqlServer 2005.

viernes, julio 03, 2009 9:10:00 p. m.  
Blogger Junior said...

"Yo diría más bien que es necesario no mostrarlo."

Es así, lo que pasa es que muchos programadores se confunden por que sus clientes quieren que todo lo que ellos registran tenga un código para supuestamente identificarlo más facil "la tradición". y como se dice ya es difícil saber cuando se necesita o no un código. Pero tomar la clave primaria para mostrarla como un código que vea el usuario no es una buena practica.

viernes, julio 03, 2009 9:46:00 p. m.  

Publicar un comentario

<< Home