Friday, October 10, 2008

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

Thursday, October 09, 2008

Windows Strata? (Vamonos a la nube!)

Si de novedades se trata, hace mucho que la gente del entorno menciona aspectos como cloud services, S+S, SaaS y relacionados.

Sin ir muy lejos, el ultimo post de Jorge Serrano menciona un curso de S+S, de que primera mano puedo decir, que me parece muy bueno (a pesar de haber tenido ciertos problemillas con mi navegador y el plugin que de momento no quiero mencionar)

A lo que venía con este post, es que está mas que confirmado que en el PDC 2008 los amigos de MS mostrarán su Sistema Operativo basado en Cloud services, es decir...

nada!, no podemos decir mucho al respecto, puesto que antes se hablaba de un codename Red Dog, y de acuerdo a Mary Jo Foley (de all about Microsoft), no se tiene claro si se trata de lo mismo.

Se entiende? la verdad es que es un misterio.

Ahora, todo esto de Strata salió pues en la página de sesiones del PDC apareció un nuevo bloque llamado "Windows Strata", y revisando las imágenes contiene sesiones relacionadas a Cloud Services.

Dije "revisando las imagenes", pues entré a la página del PDC y no encontré tal información, incluso inicié sesión vía passport, pero nada!

Aquí uno y otro de los post que comenzó todo este por decirlo de alguna manera "marketing viral"

Aquí la imagen que no pude replicar (vía iStartedSomething)

Ahora si, supongo que, a dormir.

Saludos[at]cama temporal 

Monday, October 06, 2008

Mono 2.0 & Interactive C# Shell


La siguiente es para comentarles que de acuerdo a la siguiente nota del site oficial, mono 2.0 ha sido liberado.
La verdad es que ya habia olvidado la promesa de mono 2.0, un mono que esté a la par del nuevo framework.

Un momento, no es que ya estamos cerca del Framework 4.0? Bueno, ya estamos en 3.5 (por mas comercial que sea el nombre, y no lo pienso solo yo, sino el mismo ScottHa)

Pues si, incluso en la nota que mencioné líneas arriba, indica que cubre soporte a funcionalidades .net 2.0 pero de momento nada de Workflow, Comunication o Presentation.
Aunque, de acuerdo a una entrevista concedida por Miguel de Icaza, esto se verá en mono 3.0 (es decir...)

Y bueno, revisando el blog de Miguel, acabo de encontrarme con el post que menciona la liberación de mono 2.0 (osea, Miguel, casi te gano en publicarlo? es broma)
Lo que si, me sorprende (y bastante) en primera instancia es la inclusión de Linq (bacán, no?)

Por otro lado, hace mucho que no leia las publicaciones de Miguel, y es que, viendo algunos posts es que sigo con mis sorpresas, como por ejemplo:
- Cambiar el tipo de licenciamiento MS de algunas distribuciones/proyectos publicados en CodePlex. Como por ejemplo lo referente a MEF.
- Interactive C# Shell, esta funcionalidad si que me sacó de la silla del trabajo, salté hasta el techo viendo esta herramienta, pues, una cosa es escribir tu código y luego de compilarlo verlo en ejecución. Pero otra cosa es ver tu codigo funcionando "al vuelo" mientras vas escribiendolo.
Algunos me dirán "oye eso de alguna manera ya se podia", pero, a ver, veamos una ventanita como esta:
 

Como que dan ganas de entrar a la página del proyecto, descargar las fuentes y hacer una pequeña implementación completamente basada en .net, no?

Bueno, ya me despido, tengo que bajarme las fuentes del mono (digo, seguir trabajando)

Saludos[at]Silla defectuosa
PD: Sabian que Miguel estará en el PDC? Claro... el PDC!

Friday, October 03, 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

Thursday, September 04, 2008

La Caja - Artículos Recomendados - ANTS Profiler - Brad's Sure Guide to SQL Server 2008 (Free)

Holas, volvemos con La Caja (ya era hora)

Artículos Recomendados
Mas que un articulo, me gustaría comentarles que hace un tiempo descubrí una página llamada LittleTutotials, la cual de por si me dejó pensando, mas aun, luego de haber leido "36 steps to success as technical lead", en la cual se resumen de manera muy interesante y a la vez detallada lo minimo que deberia tenerse en cuenta si es que se busca ser un buen lider técnico.
Tambien pueden encontrar algunos puntos de vista referentes al uso de UML en "13 reasons for UML’s descent into darkness", artículo que de verdad, te hace confirmar la frase que sueltan algunos "bueno, veamos que tanto tenemos que usarlo"

ANTS Profiler
Ya debo estar cansándolos con tanta herramienta de profiling que debo haber mencionado en este medio (no creo que hayan sido muchas, je). Pero la verdad es que ANTS Profiler es la que mas recuerdo cuando se habla de este rubro. Lo gracioso es que siempre recordaba el símbolo, pero no el nombre ni el proveedor.
Lo bueno, es que pude averiguar como se llamaba (por fin) y hasta hace poco la version 4.0 estaba en Beta.
Pues bien, a mi siempre me llamó la atención esta herramienta, sobre todo por hacer mas visible el profiling, es decir, en cada línea de código puedes tener un detalle del profiler! Esto pueden observarlo en la imagen sacada del sitio de ANTS, es decir Red Gate.

 

Les recomiendo la herramienta, si han usado CLR Profiler o dotTrace JetBrains (los cuales he mencionado en posts como este y este), van a sentirse mas que comodos. Claro, que el problema es el precio =D

Brad's Sure Guide to SQL Server 2008 (Free!)
Vía el newsletter de Red Gate me entero de la disponibilidad de este libro, acabo de bajarmelo y está muy interesante pues ha listado rápidamente los diversos features de esta nueva versión del SQL Server.
Lo bueno de los chicos de redgate te dan un enlace directo a la descarga del libro, aduciendo, claro, que ya tenemos sus productos al menos en modo trial.
Como les decía el libro esta interesante, y mas aun si es que luego de bajar el archivo te das con la sorpresa que vienen ademas, otros dos libros, uno de buenas prácticas en SQL y otro que, segun entiendo luego de una rapida revisada tendria que ser un must read de los DBAs.
Olvide decirles, una vez mas, que es Gratis!

Comentarios.
Bueno, creo que de momento eso es todo por hoy en La Caja, lo que si no podía dejar comentar es que, la ultima vez que escribí para La Caja mencioné al YSlow, y bueno, al mes siguiente, The ToolBox tambien la mencionó. Te gané por un mes, ScottMi!

Saludos[at]Trabajo/Trabajo/Trabajo

Tuesday, August 26, 2008

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

Thursday, August 14, 2008

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.

Saturday, August 02, 2008

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:

up_ListarClientes

SpListaCs 

Para el caso de Linq usando Procedures el código es el siguiente:
SpLinq
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)
TiemposCS

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

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

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)
MemoriaLinq

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

Usando CLR para ejemplo Stored Procedure en Linq
MemoriaLinqSp

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

Tuesday, July 29, 2008

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.

Expresiones

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
TiemposVB

Usando JetBrains para el Ejemplo en CS
TiemposCS

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.

SqlEnCodigo

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

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
MemoriaLinq

Usando CLR para ejemplo C#
MemoriaCs

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

Monday, July 21, 2008

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