Usa esta tecnología, pero… por qué?

Hoy mientras conversaba con unos amigos me quedo la duda y a la vez molestia ante un sustento presentado.

”Es que es drag and drop, eso haría mas productivo el trabajo…”

Cuando pregunté si es que se habia hecho alguna comparativa, benchmarking, estudio o “algo” al respecto, para verificar tal productividad, me repetian una y otra vez eso del drag and drop.

Yo la verdad, no se que decir al respecto, pienso que es de muy poca seriedad alegar características que, es cierto, son muy bonitas e interesantes en primera instancia, pero a la larga lo facil, como que… sale caro, no?

En resumen, qué deberia tomarse como característica clave para estas alternativas?
Considero inicialmente:
- Facilidad de uso: es decir, una curva de aprendizaje apropiada
- Complejidad de posibles mantenimientos: que las modificaciones sean de bajo costo y no se necesite un gurú para resolver el problema.
- Estabilidad del producto: cuidado con aquellos en beta, alpha o la primera version “estable”
- Soporte de comunidades de desarrollo o proveedor: una comunidad activa implica que el producto va por buen camino.
- Papers desarrollados por otras entidades: si otros hablan, es por algo, no? (aun recuerdo cuando Oracle no tenia una seccion .net)
- Documentación OnLine/OffLine variada: Si hay libros y no son del tipo “for dummies”  o “… en 24 minutos”, pues es un indicador a considerar. 
- (Muy importante) Frameworks asociados?: es decir, si hay plataformas o mas de un framework que lo usa de manera “seria”, pues deberia considerarse.


Bueno, pero, deberia tomarse otro punto a considerar?

El código que si debería preocuparte

Basándome en la premisa de "pensar que cosas hacer en vez de como hacerlas", es que debemos tener cuidado al momento de diseñar o presentar ciertas recomendaciones.

Dado que, de acuerdo a lo que debe hacerse, se plantea un esquema de construcción, y luego de priorizar dichas actividades uno debería tener ya en cuenta que las funcionalidades van por delante del código/librerías a construir/implementar. Y que, dicho sea de paso, las funcionalidades determinan los contratos "mínimo/suficientes" que deben considerarse para determinar el cumplimiento de los requerimientos.

Con estas funcionalidades transformadas en contratos es que se tienen que trabajar los conocidos casos de prueba (me parece es que David estaba hablando de pruebas en su ultimo post?) desde el inicio del proyecto, ya que a mi parecer, estos casos se van enriqueciendo con el pasar de los días. De ser asi, por que esperar hasta terminar el desarrollo para tener listo todo el set de pruebas?
Que si es posible lo contrario? creanme que he experimentado situaciones en las que no consideraban la construcción de casos de pruebas desde el inicio.

En si, las pruebas, independientemente de la manera en que sean ejecutadas (el cual es un tema largo de conversación) deben en primer lugar, enfocarse en los resultados y cumplimiento de estos contratos "mínimo/suficientes". Dado a que, en resumidas cuentas, nuestro trabajo es reconocido por si el producto funciona. Si no es asi, favor corrijanme si es que al usuario no todo le parece transparente.

He notado que en la mayoría de situaciones es menos probable encontrar la explotación y seguimiento de resultados de casos de prueba, puesto que, principalmente es el código que le preocupa a cada desarrollador.
Pero que sucede con el caso del resto de componentes? es decir:
- Librerías de la compañía (Librerias de uso comun, como acceso a datos o correo)
- Librerías especializadas-externas (Proveedoras de controles/componentes/etc.)
- Librerias Open Source

Lo que debe tomarse ya como cierto es que no tenemos que caer en el juego de "lo necesito, lo construyo". Dado a que, tiempo es dinero y ese dinero es el que estamos ahorrando para disminuir costos, a corto o largo plazo.

Considero que a pesar de ello debe tenerse bastante cuidado con las librerias con las que se decida trabajar. La importancia con la que se maneje tal situación determinará el cumplimiento del objetivo de "no reinventar la rueda"
Y porque digo esto?

***Caso: Librerias de la compañía
Creo que en cierto punto, casi todos hemos pasado por la situación de haber construido un componente que "a nuestro entender" puede convertirse en algo de uso común.
El problema viene cuando dicho componente/librería/control/piece of code, no está del todo documentado o peor aun, luego de algunas pruebas llegamos al punto de "ese caso no nos ha pasado, pero no debería caerse".
Esto en vez de aportar al proyecto puede convertirse en un cuello de botella.

Pues que solución? Entre tantas, creo con un poco de Gestión de la Configuración y algo de compromiso de parte del Gestor o responsable para que al liberar versiones de componentes de construcción, estos se mantengan estables, documentados o en todo caso, autosostenibles que permitan el correcto uso de las funcionalidades que brindan.
Creo que tambien ayuda un poco menos de ego, no les parece?

***Caso: Librerías especializadas-externas
Este tema es mas que conversable, pues estamos hablando de pagar por librerías de uso comprobado.
El problema está en que muchas veces nos dejamos llevar por las propagandas o animaciones que podemos encontrar en la red. Creanme, que a veces es asi.
El caso es similar si es que hablamos de complejidad de uso, documentación, ejemplos y lo mas importante, costos de soporte. En algunas situaciones, este deja de ser gratuito (muchos de mis amigos me dicen que alli radica el negocio, o no?)

Pues que solución? Evaluacion directa de las alternativas de compra, asi como tambien la revisión de la actividad pública de los foros de usos de la librería y de la rapidez de respuesta y aportes brindados por el soporte de la empresa.
Como punto adicional, algo que debe considerarse en la evaluación, es la periodicidad de fixes/patchs liberados, la compatibilidad hacia atras, y ademas claro, de la caducidad del contrato.
En mi caso he pasado por estos procesos de evaluación. Sinceramente es algo tedioso, ya que no estamos hablando de un juguete para navidad, esto es algo serio!

***Caso: Librerías Open Source
Este aspecto es de por si delicado, ya que ademas de la estabilidad, documentación o ejemplos de uso, debemos considerar aspectos como el nivel de aporte brindado por la comunidad (se de un caso en que el proyecto fue cerrado porque el unico que desarrollaba era el dueño de la idea, asi que un día se cansó y dejó de hacerlo).
En si, los riesgos o problemas identificables en este aspecto son similares a los encontrados en el caso de las librerías especializadas, pero bajo la premisa que la empresa de terceros es ahora una comunidad abierta y algunas veces, volatil.

Pues que solución? En las evaluaciones debe considerarse el aporte de la comunidad en lo que desarrollos se trata, ademas de la periodicidad de releases y compatibilidad con nuestras plataformas de trabajo. 
Si hemos llegado aqui, debemos coincidir en un punto medio, ya que tampoco conviene estar actualizando constantemente las librerias.
Lo que no debe olvidarse de que las ideas Open Source no dejarán de ser buenas ideas, pero que muchas veces caemos en trabajos de entusiastas (esto claro, sin animo de ofender a nadie) que -muchas veces- cubren el trabajo bajo la idea de "primero que funcione luego ya veo".
Asi que, debemos atenernos al riesgo de encontrar disparidad de estándares, manejo de memoria, falta de ejemplos, etc.



En resumen.
De por si son demasiados los aspectos que debemos considerar en nuestras preocupaciones sobre que parte de código probar o no, pero muchas veces olvidamos darle cierta importancia a algunos empaquetados que "se supone" deberían funcionar correctamente.
Creanme, somos humanos, existe aún código por probar.

Nota: Les recomiendo el libro "Code Leader", al escribir este post recordé claramente algunas recomendaciones que pude resumir brevemente, creo que el capítulo se llamaba "Buy or not buy code".

Saludos[at]Cama

Elementos que no dejo de usar en la red.

No acostumbro tener demasiadas ventanas abiertas, pero gracias al Chrome y conversando con David, les comparto algunas herramientas web que uso ultimamente...
Esto claro, sin orden en particular.

- Google Reader: De todas formas, imprescindible... requiero leer entre lo básico del día, miscelánea, gurúes y demas temas que muchos dirían "y que significa esto?"

- Web de Noticias: BBC de Londres - El Comercio Perú, pues bien, trato de leer cosas variadas, intento si, seriamente no ubicarme en temas dolorosos (No a la Violencia)

- GMail: Correo que sin darme cuenta se volvió en mi cuenta personal!

- Google Analytics: No diariamente, pero si cada cierto tiempo.

- Google Alerts: La verdad es que, me entero de muy buenas cosas, y todo esto... sin esfuerzo alguno!

- Twitter: Bueno, este es un vicio que vale la pena tener en cuenta!


Como pueden notar, no son muchas las cosas que considero imprescindibles, pero entre los feeds y alerts que reviso, tengo muchísimo por revisar.

Lo preocupante es ver como cada día soy uno mas, un Google Fan Boy que sigue usando "productos beta", pero bueno, mientras no compren TwT seguiré tranquilo (asi que FaceBook, apurate con la compra)

Sin mas me despido, y ya saben... Jersson tambien tiene twitter.


Saludos[at]Cama

Jersson tambien tiene twitter

hace un par de dias, ya que es mas rápido escribir una linea que tooodo un post (los que me conocen saben que demoro en demasía).
Aqui mi dirección,
http://twitter.com/Jersson
a ver que pasa

Saludos[at]Cama Prestada

Algo Rapido sobre SQL2008

Debo confesar que estaba algo cerrado en ese aspecto, luego de revisar los features me quedé pensando un poco en si debía o no instalarlo.

Asi pasaron los dias, y dias, y nada.

Pues bien, luego de tanta molestias de algunos amigos, lo instalé, confirmé algunos features,

Y solo puedo decir.
Qué esperan?

Si eres un developer y odiabas una depuración no deseada, pues, date un momento y haz unas pruebas.

Reporting Services? Report Builder? debo decir algo mas que.
Qué esperan?

Monitoreo de información (que se elmina, actualiza o inserta?)
Qué esperan?

Y si no les alcanza para la versión oficial, pues, la express, no? hasta viene con libro de regalo. (UPDATE: Segun veo, el libro es del SQL2005, estaba demasiado contento, de verdad)

Bueno, nada mas. Creo que fue demasiada propaganda por hoy :D

Saludos[at]SQL Server 2008

3 Comentarios

Hoy tuve una reunión relampago, la cual ademas de una propuesta de implementar SCRUM en un proyecto que ya ejecutándose, me trajo las siguientes dudas:
- "Debería grabar y publicar este tipo de reuniones en las que listamos problemas y luego de un brainstorming, dibujos y demas, salen propuestas realmente interesantes?"
- "Debería encotrar la manera de hacer que estos chicos escriban las experiencias que compartimos de manera offline"
- "Deberia escribir sobre lo que converso de manera offline"

Ante esto, me respondo:

"Debería grabar y publicar este tipo de reuniones en las que listamos problemas y luego de un brainstorming, dibujos y demas, salen propuestas realmente interesantes?"
- De grabar las conversaciones que tenemos (aunque algunas si fueron grabadas), sería gracioso escuchar hasta las anecdotas que salen en el momento. Pues, hemos demostrado que una anecdota vale mas que cien ejemplos o tecnicas de desarrollo.
Lamentablemente, algunas historias son demasiado personales o intelegibles.

Debido a que algunas veces caemos en la informalidad o el desenfoque, las grabaciones contendrían chistes, risas, información de la bolsa de Londres o incluso comentarios referentes a técnicas de como puedes hacerte famoso sin necesidad de escribir un libro, ganar un grammy o chocar el carro de tu jefe.

Aqui me detengo un momento, solo para agregar que hasta cierto punto y estando fuera de la reunión uno puede notar ciertos elementos de falta de productividad/eficiencia. Pero he demostrado que luego de cada desenfoque en las conversaciones, al retomar el tema principal las respuestas se vuelven cada vez mas claras.
Recuerdo cuando mas de una vez un problema no me salía y decidía dejarlo unos minutos (en ese instante decidia salir a comprar un helado o simplemente jugar cualquier cosa), para luego de volver, encontrar una luz, una salida ante tal elemento bloqueante.

Volviendo a la primera interrogante, considero complicado publicar una de estas grabaciones, sería si, gratificante, transcribir un poco de todo lo conversando en las sesiones de trabajo. Creo sinceramente que serían posts espectaculares.
Pero, ya lo dije hace una lineas, algunas partes se vuelven intelegibles, y la verdad es que, algunas conversaciones se vuelven largas y la unica manera de explotar la información es  escuchando todas las horas de la reunión (si, horas)

"Debería encotrar la manera de hacer que estos chicos escriban las experiencias que compartimos de manera offline"
- Hoy una vez mas me di cuenta que existe mucho potencial entre las personas que he podido conocer hasta el momento -y estoy seguro- afuera debo encontrar muchos mas.
El problema es que, de toda esta gente no muchos escriben acerca de todo eso que saben.

La verdad es que no comprendo como es que decimos que no hay información en nuestro idioma, cuando muchos fuentes estan entre nosotros pero quizá el tiempo, las ganas o desconocimiento de lo que es tener un blog, no permiten que existan puntos de vista disponibles para cualquier habitante de la red.
El problema es que a veces uno pierde el concepto de lo que es compartir, o simplemente no tiene tiempo, o no sabe como hacerlo (sea escribir, o compartir)

Es gracioso, pero a veces sucede que hablamos de un tema, o se reenvia cierta información que luego de unos días (o peor aun horas) se convierte en tema recurrente de blogs, noticas técnicas o uno que otro etc.
Eso si me causa gracia, sinceramente.

Pero, les dire algo, aun no me rindo en este punto. Es cuestion de cambiar lo offline por online y listo.

"Deberia escribir sobre lo que converso de manera offline"
- La verdad es que me siento, digamos que con algo de suerte cuando de alguna u otra forma, sale un tema de conversación interesante y estoy presente para poder dar mi apreciación personal.
Técnicamente hablando, recuerdo por ejemplo, haber conversado con chicos del mundo java acerca de persistencia de datos, cadena de responsabilidades, metamodelos, maquina virtual y mucho mas de la recurrencia del término Separation of Concerns.
Pero de todos estos temas, siempre queda claro que la solución nunca será un término cerrado.
Pero, creo que alli mas que nunca es que recuerdo cuanto blog, artículo, libro o capítulo de libro he podido ojear mas de una vez, pues, a veces recuerdo términos o conceptos interesantes, que la verdad, valdría la pena planificar bien una que otra grabación/transcripción.

El problema es que este asuntillo del internet hace tiempo que se volvió propagandezco, y la verdad es que no me motiva mucho poner mis apreciaciones personales a pesar claro que no me importa eso del "que diran".
Pero claro, que periódicamente considero conveniente escribir de ciertas cosas, pero a veces uno por dar sus puntos de vista cae en lucha de puristas o inclusive, cerca de los límites del fanatismo absoluto.

A veces es gracioso, incluso mientras uno conversa que haya gente que replique con frases del tipo "pero la otra vez dijiste lo contrario" o "pero en este modelo que comentaste, no se cumple".
Aqui digo "gracioso" pues existen lo que muchos llaman, contextos (es decir, realidades) que determinan la validez de ciertas reglas, modelos, formas de trabajo. Y el punto de la risa, es que a veces uno se amarra a un solo paradigma olvidando que existen otras soluciones que no se resuelven solo con un "depende", "mi cuaderno de universidad dice..." o "la experiencia determina..." sino con un mix de todo esto.

Del poco tiempo que llevo trabajando, he descubierto que lograr que un grupo comprenda una linea de trabajo denota tiempo. Ergo, escribir "algo" (por decirlo asi) de esa naturaleza, y mas aun, que sea abierto al público, denota mas tiempo de lo esperado.



---
De todo esto, puedo decir que me he quedado corto, tengo demasiadas ideas en mi cabeza, y -sinceramente- mas ganas de escribirlo (como por ejemplo, saben que es DDD? realmente saben de que se trata? de verdad, saben de que se trata? ahora la pregunta mas importante... como lo han usado?), pero debo dormir (aunque muchas veces creo que es opcional)

Saludos[at]Cama

Regla Básica: Pensar en el QUE HACER y no en COMO HACERLO

Este es un tema de conversación que he tenido muchas veces, claro, on algunos miembros de diferentes equipos.
Pues es alli, cuando conversamos, sobre la importacia de tomar requerimientos o de como tomarlos.

Pensar en ciertos aspectos de diseño que muchas veces nos quitan demasiado tiempo por entrar en detalle cuando todavia no es necesario hacerlo (pues nunca deja de ser necesario, solo que hay momentos para hacerlo a a detalle)

A veces, cuando converso con algunos chicos, sale el comentario que notan algo aburrido al usuario al que estan entrevistando.
El silencio llega si es que les pregunto "Qué tal la primera vez que se reunieron, de qué tipo eran tus preguntas, qué tanto ahondaste?"

Quizá demasiado, no?

Lo que sucede es que muchas veces pecamos de entusiastas, y de esa forma es que a pesar que caemos en el hecho de que no cubriremos toda la información necesaria en una sola entrevista, queremos seguir preguntando y preguntando al usuario detalles que de primera mano no vienen al asunto.

Es mas importante para el usuario, entrar a comprender las necesidades básicas que desea satisfacer.
Cierto, los requerimientos principales, funcionales del sistema.

Aunque, algunos recomiendan tener todavia, menos detalle, llamándoles "Requerimientos Macro" o simplemente "Características" (algo asi como matricular, vender, comprar, grabar).
Lamentablemente esto a veces logra confundir, asi que lo recomendable es comenzar a comprender, o al menos tomar en cuenta aquello QUE debe cumplir el proyecto, es decir el QUE del proyecto.

El problema es que, mientras vamos comprendiendo aquellas cosas QUE deben hacerse en nuestro proyecto (en este caso, nuestro sistema), vienen interrogantes que hacen nos desviemos del objetivo.
Asi es, nos preguntamos como es que vamos hacer esas cosas de las cuales, seguimos tomando nota.

Error! eso nos desenfoca demasiado del problema a resolver, en estos casos, el COMO nos cambia la dirección del problema, y mientras mas vamos ahondado en como cubrir esas duda, vamos perdiendo la hilación y el objetivo de las primeras reuniones.

Lo mismo sucede en la fase de diseño, he notado el problema en la preocupacion sobre el nombre de un método (lo cual, tambien a veces me concierne, pues sigo creyendo que el nombre de las cosas es muy importante para un correcto desenvolvimiento), que ademas de pensar en los parámetros a recibirse, hay integrantes del equipo que comienzan a hurgar en COMO hacer el método, cuando el objetivo de algunas tareas que son solo, la definición del objeto, el QUE del objeto, no el COMO cumplir con ciertas actividades.

Es gracioso, pero, la palabra clave siempre termina siendo "No Desenfoques, estamos averiguando el QUE, luego veremos el COMO", o simplemente "NO Desenfoques!!!"

Ahora, como es que vamos convirtiendo el QUE en muchos COMOs? pues iterando. o no?

Saludos[at]Cama

Windows Live Messenger 9 Beta 2 = WPF?

Acabo de enterarme via esta noticia, que, entre las nuevas características del WLM una dice que está basado en Windows Presentation Foundation.

En si, no me sorprende la idea, creo haberla leido o escuchado hace ya un tiempo.

De por si, el hecho que escribo este pequeño post es para mencionar la estrategia usada por MS para que tengamos instalado en nuestra PC el core de WPF.

La verdad es que de por si, la estrategía no deja de ser buena, ya que, usuarios del servicio de mensajería, son miles de miles. Pero, qué pasa si no quiero instalar el core debido a malas experiencias?

Actualmente uso Firefox y muy pocas veces he tenido buenas opiniones del control de SilverLight en el navegador, no han sido pocas las veces en las que me ha pedido reinstalar el producto.

De verdad, espero que con el tiempo llegue a lo que hasta el momento ha logrado Flash.
Pero bueno, el tiempo lo dirá, no?

Un saludo[at]Gesfor-Lima
PD: Gracias por todos los comentarios al último post en Geeks.ms. aun sigo sorprendido.

LINQ - Cuestiones de performance - II

Bien, para terminar con esta serie de posts (2/2), partiremos de algo mencionado en la sección consideraciones del post anterior.
No es recomendable el uso de datasets. Entonces, continuemos con el trabajo!

La prueba -digamos, más- real es cuando se trabaje bajo un modelo con la siguiente combinación:

- Uso de Entidades (Clases mapeadas a las tablas de la base datos)
- Procedimientos Almacenados
- DataReaders
- Carga en Listas Genéricas de entidades

Luego de esto se revisarán los siguientes casos:
- Linq en C# - Procedure/DataReader/Lista Genérica en C#
- Linq usando Stored Procedure en C# - Procedure/DataReader/Lista Genérica en C#

Los ejemplos serán una continuación de los usados el post anterior.
Comencemos pues.

Tiempos de Respuesta:  Linq en C# - Procedure/DataReader/Lista Genérica en C# - Linq usando Stored Procedure en C#
Para continuar debemos considerar que se necesita construir un stored procedure, una clase y cargar una lista genérica por medio de un DataReader.
Parte del código utilizado es el siguiente:



 

Para el caso de Linq usando Procedures el código es el siguiente:

En este caso, se utiliza el método ListarClientes, que es un reflejo del procedimiento usado líneas arriba, si requieren información sobre como realizar este mapeo, les recomiendo este post de ScottGu.

Con esto y verificando los tiempos de respuesta, se obtiene lo siguiente:

Usando Jet Brains para el Ejemplo Linq en C# (Del post anterior)


Usando Jet Brains para el Ejemplo Stored Procedure/DataReader/Lista Genérica en C#


Usando Jet Brains para el Ejemplo Linq usando Stored Procedures en C#


Como puede observarse, el caso propuesto obtiene 1,853 ms contra los 2,521 ms entregados por el modelo Linq usando C#.
Si, es cierto, utilizar Stored Procedures desde Linq toma 4,911 ms. Es incomparable, no?
Pasemos entonces a la revisión del uso de memoria.

Hablemos de memoria:  Linq en C# - Procedure/DataReader/Lista Genérica en C# - Linq usando Stored Procedure en C#
Pasemos a los resultados del CLR Profiler.

Usando CLR para ejemplo Linq (Del post anterior)


Usando CLR para ejemplo Stored Procedure/DataReader/Lista Genérica en C#


Usando CLR para ejemplo Stored Procedure en Linq


Luego de la respectiva inspección, puede observarse que el consumo de recursos con Linq es considerable con respecto al modelo Procedures/Reader/Listas.
Si hablamos del modelo Linq2Sql "tradicional" (usando expresiones de consulta), el uso de recursos es casi el doble.
Pero si cambiamos a la alternativa de aprovechar los Stored Procedures, el consumo se incrementa hasta casi el triple.
Esto ultimo si que es preocupante.

Comentarios y Consideraciones
- El caso propuesto fue usando Northwind,
- Debemos recordar que hay un grupo en codeplex que está buscando algo mas acorde a la realidad, indicando que no se ajusta a las necesidades de Linq (y adicionales).
- A pesar de ello, el modelo no tiene mucha ciencia en lo que respecta a lógica de negocio requerida.
- En resumen es un stored procedure que ejecuta un filtro sobre dos campos (seleccionados al azar por el desarrollador, es decir, yo).
- Sinceramente creía que el modelo que combina Linq y Stored Procedures tendría mejor performance.
- El código usado para la ejecución del procedure desde Linq puede optimizarse (noten que uso una variable tipo "var" cuando defino la variable datacontext)
- A pesar de ello, los tiempos de respuesta, no cambian mucho (dejo a su elección la verificación de este caso)
- El consumo de recursos me parece preocupante, pero lamenteblemente he notado que muchas veces esto pasa a segundo plano.
- Un ejemplo claro para mi, es el Windows Vista.
- A mi me gusta, pero cuando lo usaba desde mi PC de 1GB me sentía como en los viejos tiempos, pero no tenia intención de desinstalar el SO, menos regresar a Windows XP.
- Ahora tengo 3GB, sigo feliz con el Vista.
- Creo haberlo comentado al menos una vez, Linq me gusta mas como herramienta de consultas contra otros objetos, no como alternativa al SQL.
- A menos claro que se cambie el modelo de SQLServer (SQL 2012? como diría David)
- Alguna explicación a los tiempos de respuesta y consumo de memoria?
- Yo creo que los mapeos que utiliza Linq para realizar las ejecuciones contra la Base de Datos son de alguna manera, una evolución a lo que se tenia con el uso de los Typed DataSets, los recuerdan?
- Recuerdan entonces que habian "Duelos" (por decirlo asi), entre usarlos o no usarlos?
- Volviendo al ejemplo propuesto, la consulta usada retorna 3 registros.
- Es un ejemplo simple, lo sé.
- Pero eso no deja de hacerlo usar tantos recursos.
- Consideran que si usara mas de 100 registros, las respuestas cambiarán considerablemente?
- Lo dejo a su elección.

Antes de despedirme, solo me queda agradecer a David por la presión a escribir estos posts, sino fuera asi, todo esto hubiera quedado en las conversaciones del msn.
Pues claro, a Carlos Walzer, por sus posts reveladores (e inspiradores, claro está).

Saludos[at]Cama

LINQ - Cuestiones de performance

Bien, sinceramente quisiera comentarles todo lo que he podido averiguar, investigar, estudiar y conversar al respecto.
La verdad es que el post sería interminable y como le decia a David, pues, no tendría mucho sentido (explicaciones sobran)

De LINQ puedo decirles que hace tiempo que nos enteramos de su advenimiento, yo por mi parte, estaba emocionado, recuerdo que alguna vez dije frameworks sobre frameworks, y lo mejor, frameworks y mas frameworks!

Es que, al fin y al cabo, todo lo que competa a Framework 3.0 / 3.5 y relacionados, significa para mi frameworks sobre frameworks.
Siendo la base, pues nuestro querido .net framework (2.0, por supuesto).

Es cierto, Linq2Sql es muy interesante, que uno no necesite conocer T-SQL para trabajar y realizar ejecuciones contra la base de datos, puede ser para muchos, un gran alivio.

No para mi.

Considero que si somos algo puristas al respecto, uno debe realizar una tarea con la mejor herramienta disponible, a su vez, debe contarse con el experto en el ambito.
No recuerdo cuando fue la ultima vez que estuve en un proyecto en el que no habia DBA, la verdad no recuerdo, quizá fue en la universidad, pero hace mucho tiempo que ademas de un DBA, el personal de desarrollo tiene la capacidad necesaría para construir un stored procedure con menor probabilidad de ajuste en lo que respecta a lógica y performance.

Por ese aspecto no me preocuparía mucho tener como alternativa, el uso de Linq2Sql.

Pero dejemos mi punto de vista de lado, comencemos con una de mis preocupaciones.
Creo yo, con el tiempo he mencionado algunas de ellas, pero una vez no está de mas.

Estaba algo interesado en la forma de trabajo de LINQ, pues es interesante todo esto de los datacontext y expresiones de consulta dentro del código .net, pero queria ver exactamente como hacía para obtener la información de la base de datos.

Encontré la respuesta con un poco de código a la mano y una que otra depuración cuando llegaba a la expresion de consulta.
Ahora es menos complicado encontrarnos con imagenes como la siguiente (via lancefisher.net):


Como puede notarse, la expresión se transformará en T-SQL.

Todos felices, no? el CLR se encarga de interpretar parte de lo que escribimos, transformándolo en una consulta SQL que será enviada a ejecutarse contra la base de datos.

Dije, interpretar. Es decir, estariamos regresando, en parte al código interpretado.

Por otro lado, el T-SQL generado será enviado desde nuestra aplicación hacia la base de datos, cierto?
Si lo tomamos desde otro punto de vista, estamos regresando al concepto de escribir las sentencias SQL dentro de la aplicación.
Estariamos obviando entonces el uso de stored procedures?
Claro, este es un tema controversial, como puede notarse aquí, aquí, aquí o aquí.
Por mi parte soy partidario del uso de stored procedures.

Cuando hablamos de performance uno recuerda al instante "tiempo de respuesta al cliente", lo cual es cierto, pero que pasa si hablamos de espacios de memoria? y qué hacemos con la memoria disponible?
Claro, a estas alturas uno puede olvidar esos "aspectos mínimos", aqui me estoy refiriendo al hardware.
Lamentablemente ya se han obviado las epocas en las que se luchaba por cada bit a usarse, quizá ese sea el problema.

Pero si, "esas cosas" influyen y bastante, solo para darnos una idea, veremos algunos escenarios. Para esto usaremos Northwind.

Tiempos de respuesta: Linq en C# - Linq en VB
Lo que se hizo fue construir una expresion que contiene un filtro simple, no mostraré la imagen depurando la aplicación. Pero puedo adelantarles que la expresión SQL de la imagen anterior solo puede reproducirse cuando se trabaja en una aplicación basada en C#.

Aquí la consulta construida.



Para seguir con el ejemplo usaremos las herramientas recomendadas por Carlos Walzer (esto en su sección Anti Prácticas.NET, la cual es una lectura que no deben dejar pasar), en este caso usaremos Jet Brains luego el CLR Profiler.

Usando JetBrains para el Ejemplo en VB

Usando JetBrains para el Ejemplo en CS


La linea resaltada indica el tiempo de respuesta para la ejecucion del ejemplo mostrado.
La diferencia es notoria, no? bueno, algo tendrán que ver los chicos de C# no? (es que, Linq fue creado sobre C#)

Para el siguiente caso se trabajará sobre el ejemplo en C#.


Tiempos de respuesta: Linq en C# - Ejecución de T-SQL desde código C#
Se agregó el siguiente código de prueba.



En este caso no se está usando una librería en particular, bueno, continuemos con las pruebas de tiempos de respuesta.


Como puede observarse, ejecutar el código mostrado, demora 2688 ms, el cual, comparado con los 2521 ms del caso Linq en C#, nos indica que usar Linq en C# es mas rápido.

Debemos confiar en este resultado?
Estamos hablando de poco mas de 100 milisegundos.
Por esta diferencia debemos cambiar de forma de trabajo?
Pues bien, que ganamos? Un modelo completamente tipado (recordemos que las primeras propuestas venian de la mano con los datasets tipados).
Esa es una buena respuesta, pero aun no me siento convencido.


Hablemos de memoria: Linq en C# - Ejecución de T-SQL desde código C#
Aquí usaremos el CLR Profiler, la verdad es que me gusta bastante esta herramienta, sirve para darnos una vista diferente cuando hablamos de performance.

Usando CLR para ejemplo Linq


Usando CLR para ejemplo C#


Aqui el asunto es algo preocupante.
Como puede observarse, el uso de memoria nos muestra un 607kB de Linq contra 187kB de C# tradicional, es decir estamos hablando de mas de 100% de diferencia en lo que respecta a consumo de recursos.
Qué deberiamos hacer al respecto? Qué modelo deberiamos seguir?
Yo aun no me siento convencido.

Consideraciones
- En primer lugar, el ejemplo usando DataSet es algo que no debería ocurrir en el mundo real, a pesar de que he visto lugares en los que se han construido asi, y que, funcionan!, asi que, por qué cambiarlo? Es lo que dirian, estoy seguro que si. Recuerdan el post del paradigma?
- Como les iba diciendo, el ejemplo fue con un DataSet, y hablando seriamente, la diferencia se volvería abismal si es que realizamos el ciclo completo usando un DataReader. Aqui aplicaremos la lógica y los mitos cazados por Carlos Walzer en su seccion Antiprácticas .Net. (Oye Carlos, no me conoces, pero ya te estoy haciendo bastante propaganda!!!!, es broma, es broma)
- Debemos tomar en cuenta que dejé el ejemplo con la sentencia SQL incrustada en el código C#, la respuesta mejorará si es que hablamos de una llamada a un stored procedure.
- Aplicando lo aprendido por los posts de Carlos, comprenderemos a detalle que el DataReader combinado con modelos de entidades y listas genéricas, es de momento, la mejor alternativa en lo que respecta al trabajo y desarrollo orientados al modelo de base de datos.
- El modelo tipado ofrecido por Linq (Aqui me refiero a los datacontext y entidades análogas a las tablas de la BD) puede ser reemplazado por herramientas que generan entidadas mapeadas a las tablas (Aqui me estoy refiriendo a generadores de código, en el mercado hay cientos, y que no decir en cada empresa de desarrollo)
- Este post no busca controversia alguna, hace mucho que conocí una frase que nos saca de algunas situaciones y esta es "eso depende" (y esto a veces genera desorden)
- Personalmente hablando, considero Linq como un lenguaje interesante, pero que debe afinarse en muchas cosas.
- Lo bueno de todo esto es que uno puede seguir construyendo sus procedimientos SQL y enlazarlos a las clases Linq2Sql, pero eso es mas trabajo, no? (Qué creian que el designer nos iba a ayudar toda la vida?)
- Me despido

Saludos[at]Cama

Para qué debe usarse la depuración? (y cuándo?)

Depurar el código tal vez no sea la respuesta indicada si es que se necesita entender el proceso de un negocio en particular.

Menos aun si es que si quiere identificar de buenas a primeras un problema.

Menos aun si es que estamos hablando de la depuración línea por línea.

No estoy en contra de la depuración, no he dicho eso.
Con lo que no estoy de acuerdo es con el uso incorrecto que se le dá, a veces pienso que el termino apropiado es "abusar" de tal funcionalidad.

Considero que si tenemos que depurar una aplicación es debido a un funcionamiento no esperado de la misma, algo que el código no tenia contemplado, si... una excepción a la regla.

Correcto, una parte de la depuración debe ser cubierta por el manejador de excepciones,
Pues claro, dado a que, si sucede un problema en el código, uno no debería preguntarse dónde comenzar, menos aun basarse en corazonadas del tipo "a ver, en que ventana se cae?". (A menos claro, que uno termina cayendo por las corazonadas, observaciones y/o experiencias)

Si es que estamos en una construcción debemos tener en cuenta que el mensaje de error nos tiene que entregar información suficiente que sirva como base para identificar el problema.

En este caso la corazonada se convierte en pregunta del tipo "veamos el mensaje de error" 
Es muy cierto que con el tiempo una persona termina preguntando "qué dice el mensaje de error?" (incluso por teléfono), pero la idea es que la descripción entregada por la misma sea comprensible por personas de menor experiencia.

Cómo se logra esto? si estamos en etapa de construcción, el detalle debe ser explícito, incluyendo información del stack (okey, creo que fui demasiado técnico), es decir hay maneras de obtener incluso la línea de código que presenta el problema.

Con esto ya sabriamos donde comenzar y el espectro de revisión será cada vez menor.
Y eso que no estamos mencionando aspectos muy importantes como lo son, las pruebas unitarias.

Cuando el rango de revisión es cada vez mas pequeño, estamos obligados de manera inconsciente, a reemplazar la depuracion línea por línea por una revisión del código manteniento un correcto uso de los puntos de interrupción (es decir, por ejemplo, antes y despues de la llamada a una función).

Claro, que esto puede lograrse mientras mas información del error se tenga. Y si estamos hablando de construcciones propias, pues podemos controlarlo, o no?

Ahora, si estamos hablando de algun legado que tenemos que terminar de construir o agregar funcionalidad y este sistema no cuenta con un manejador de excepciones o tiene mensajes no apropiados al ojo humano (es decir, error general, por favor, arreglame), pues preparense, que necesitan paciencia.

Saludos[at]Trabajo