En este video explico el por qué un ejemplo tomado del MSDN está mal y cómo debería de escribirse en cuanto a la manera en que trata las excepciones.

Soy un convencido de que muchos de los malentendidos que existen en cuanto al manejo de excepciones en VB.Net y C# es por culpa de los malos ejemplos que siempre ha tenido el MSDN. Con solo invertir un par de segundos en google uno puede encontrar verdaderas aberraciones.. A modo de ejemplo solo pondré dos links y las capturas:

http://msdn.microsoft.com/en-us/library/system.net.dns.resolve(v=vs.110).aspx 
Si Bien es cierto que los ejemplos han mejorado muchísimo, porque años antes eran un desastre, todavía siguen existiendo demasiados de estos ejemplos, ejemplos que son tomados por muchos desarrolladores como “bunas prácticas” ya que provienen de un sitio de la más alta confianza.

Otro ejemplo: http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient(v=vs.110).aspx. Hay tantas cosas mal en este que da para pensar si estos ejemplos ayudan a los programadores o si por el contrario, los perjudica.

Termino de leer el artículo de Martin Fowler: DiversityImbalance y la verdad es que no estoy de acuerdo con lo que sugiere ese post. Al parecer Fowler piensa que la razón de la bajísima proporción de mujeres programadoras se debe a que estas son excluidas por un sistema algo prejuicioso sobre las capacidades o inclinaciones de las mujeres.

Que la falta de mujeres programadoras es un problema grave, es algo evidente, al igual que lo es el hecho de que en una industria, en la que la necesidad de encontrar nuevos talentos se acrecienta día a día, solo se cuente con la mitad de la población (la masculina). También estoy de acuerdo en que este desbalance daña nuestra profesión, y en cierto punto nuestra reputación.

Ahora bien, lo que realmente me sorprende es que el desbalance se produce principalmente en el rubro programación y no tanto así en otros muy próximos como Testing, Business Analysis, UI Design o Project Management. Es decir, estamos rodeados de mujeres pero difícilmente nos sentamos al lado de una. Por esta razón, y siguiendo el pensamiento de Fowler, me pregunto ¿será que la gente de Testing, los analistas funcionales, los diseñadores de interfaces de usuario y los gerentes de proyecto son menos prejuiciosos que los programadores? ¡Por supuesto que no!

Yo estudié en la Universidad Tecnológica Nacional (Argentina) en donde todas las carreras son técnicas y entre ellas, las carreras con mayor número de mujeres eran ingeniería de sistemas e ingeniería química pero en otras carreras como mecánica, electromecánica, industrial, metalúrgica, civil y otras que no recuerdo, los muchachos se sentían afortunados si en alguna de las materias encontraban una chica. ¿Estoy siendo lo suficientemente claro?

Una situación similar, aunque a la inversa, se puede observar (al menos en mi provincia) en las carreras en las que predominan las mujeres como son los casos de las carreras de lenguas, odontología, psicología, recursos humanos entre otras. ¿Pero por qué sucede esto? ¿Será que existen prejuicios sobre las capacidades de los varones en esas carreras? ¿O quizás no tengan las aptitudes necesarias?.

Este desbalance ocurre no solo en lo que a programación se refiere sino que es común a muchas profesiones o actividades, no obstante es curioso que del número total de mujeres en las empresas de desarrollo de software muy pocas se dediquen a programar. Entonces es aquí en donde el terreno se puede volver algo escabroso. Entiendo que independientemente de la cultura, existe cierta presión social tanto sobre hombres como sobre mujeres que condicionan de cierto modo sutil, aunque poderoso, la elección de las profesiones y/o actividades que cada cual puede desempeñar y es quizás por eso que parezca natural observar grandes desbalances en carreras fuertemente técnica y tradicionalmente reservada a los hombres (como por ejemplo: ingeniería metalúrgica) y lo mismo sucede con aquellas en las que históricamente han sido reservadas para las mujeres (ejemplo: enfermería).

Mi hipótesis es que socialmente la programación es vista como un trabajo reservado para los hombres y esa visión es fuerza suficiente para producir el obvio desbalance que vivimos diariamente en nuestras empresas. Por esa razón es que entiendo que la manera más eficaz para reducir este desbalance es trabajar para cambiar esa percepción social y de ese modo lograr que más y más mujeres se interesen por esta pasión que es programar. Entonces, manos a la obra!

Introducción

Existen ocasiones en las que almacenar y organizar nuestros datos en una estructura tabular puede no ser lo ideal, en las que por conveniencia queramos guardar un conjunto de datos fuertemente relacionados en un sencillo xml pero a la vez necesitemos muchas de las características propias de SQL.

Si bien SQL Server nos permite guardar XML (con o sin esquema asociado) e indexarlo, estos índices son muchas veces demasiado grandes y algo lentos y, aunque funcionan obviamente muy bien, podríamos crear nuestro propio sistema de índices más livianos (y también indexar los xml no en tiempo real).

La idea

La idea es crear una delgadísima capa de acceso a datos que nos permita guardar documentos XMLs en la bases de datos utilizando procedimientos almacenados. Estos son básicamente 2: InsertDocument y UpdateDocumet. El objetivo es no solo insertar y actualizar los documentos sino también insertar y actualizar los índices que se hayan creado para los mismo.

Ejemplo

Imaginemos que deseamos guardar datos personales de personas, sus nombres, apellidos, datos de contacto, familiares y otros datos. Para ello usamos documentos XMLs como el que sigue:

Lo primero es crear y registrar la tabla en donde se guardarán los documentos XMLs, para esto utilizamos un procedimiento almacenado: CreateForm y que recibe el nombre de la tabla a crear:

Esto último crea una tabla y la registra dentro de la tabla Forms.

 

También queremos poder buscar dentro de estos documentos por Nombre, Edad y por el nombre del padre de las personas y por ello crearemos 3 indices mediante el procedimiento almacenado CreateIndex.

Esto último crea 3 tablas, una por cada índice y las registra en la tabla de índices (Indexes). Para la creación del nombre de estas tablas se una como convención NombreTabla_XpathNodo_Idx.

Y ahora si, una vez creados y registrados tanto la tabla como los índices, podemos comenzar a insertar y actualizar documentos. Por ejemplo, para insertar el documento que veíamos al inicio solo debemos invocar al procedimiento

Insertemos otro más:

Veamos cómo quedan los índices luego de insertado este registro:

Ahora podemos buscar los en las tablas de índices y obtener el/los id del/de los documento/s que contiene/n el valor buscado. ¿Pero que sucede si quisiera buscar por más de un valor/columna? Bueno, con estas tablas podemos crear una vista que las uniera mediante un join por DocumentId. Para eso utilizamos el procedimiento almacenado CreateSearchView como sigue:

Lo que crea la vista Personas_SearchView la cual puede utilizarse para búsquedas.

Ahora bien, puesto que el indexado es algo caro, podríamos configurar un Job para que indexe los registros por las noches o lo haga por lotes pequeños de registros o de alguna otra forma que nos permita mover el costo de procesamiento a otro lado o a otro momento. Para ello existe el procedimiento almacenado UpdateIndex el cual recibe como parámetro el nombre del indice a actualizar.

Conclusión

Bien, esta es solo una idea que puede utilizarse en algunos escenarios en los que debamos (o queramos) utilizar SQL mientras que a la vez almacenamos nuestros datos como XMLs sin esquemas las cual puede brindarnos algunas de las características propias de las bases de datos NoSql.

El código está acá.

Los Supertesters son a los testers lo que Superman es a un hombre común y corriente. Básicamente la diferencia es que estos son “Super” mientras que el resto no lo son y, al igual que Superman,  los Supertesters parecen venir de otro planeta y tenerlos entre nosotros es un gran privilegio.

Veamos que es lo que hace a un tester ser “Super”:

Poderes

A diferencia del resto de los testers, un Supertester tiene poderes especiales que lo hacen distinguirse. Estos poderes los constituyen un gran conocimiento técnico que los demás no poseen. Esto le permite entender mejor qué debe probar, cómo debe probarlo y saber por qué puede fallar algo. Uno de esos poderes que yo admiro de Supertester es que puede leer y escribir código lo que le permite automatizar sus pruebas, probar servicios, desempeño, stress y básicamente puede, gracias a su vista de rayos X, hacer pruebas de caja blanca mientras que los testers menos super, que no poseen ese tipo de vista, solo pueden hacer pruebas de caja negra.

Supertester conoce de bases de datos, de servicios stateful y stateless, de ciclos de vida de los distintos tipos de aplicaciones, etc. Supertester no necesita que un desarrollador se le siente al lado y mediante una parabola le intente explicar qué son la cookies, él sabe de cookies.

Baticinturón

La comparación con Superman la he escogido adrede porque si bien Supertester tiene mucho de Batman, quedaba mejor decir Superterster que Batitester. No obstante, supertester tiene además su cinturón con sus herramientas especiales que el resto de los testers ven como de ultra alta tecnología. Solo para mencionar algunas diremos que Supertester usa fiddler2, WatiN o similar, TestApi y Profilers entre otras muchas cosas.

Recuerdo que tuve el placer de trabajar con Supertester y entre los bugs que me reportó había uno que decía más o menos así: “Se está realizando un select N+1 en el componente de autorización. Adjunto trace log”. Esto fue para mi un baldazo de agua fría, ¿¡Quien era ese tester!? No hace falta decir que de inmediato se ganó mi respeto.

Actitud

Lex Luhtor siempre opera desde la clandestinidad buscando dar el golpe que lo reivindique como el villano más genial del mundo y por eso, salvo aquella que mantiene con sus secuaces temporarios, su interacción con la sociedad es muy limitada. Al igual que Lex, muchos de los testers no tan super se aislan del equipo, participan poco y se concentran en “dar el golpe” que les otorgue el premio nada deseable de ser quienes impiden el release y con esto tomar cierta relevancia. Lex se sabe un enemigo del mundo, muchos testers creen que deben ser los enemigos de “el equipo de desarrollo”.

Supertester, por el contrario, sabe que su responsabilidad es hacer del equipo un equipo mejor, él sabe que es un miembro importante de “el equipo de desarrollo” y que su objetivo es que este sea tan exitoso como sea posible. Supertester no necesita cobrar relevancia con una mala noticia, las malas noticias son su responsabilidad y trabaja para que estas no deban darse en la medida de lo posible. Todo el mundo acepta las malas noticias cuando quien las comunica es Supertester.

Respeto

Nadie le falta el respeto a Superman no por su superfuerza (o super trompada) sino porque es un ser admirable, lo mismo sucede con Supertester, el respeto que lo sigue se basa en la reputación que le otorgan sus conocimientos, su trabajo diario, su gentileza y su lucha por el bien del proyecto y del equipo. Al igual que Superman, Supertester es el amigo de todos.

Trabajar con Supertester es un placer y un privilegio del que se disfruta muy pocas veces, o al menos yo he disfrutado muy pocas veces pero lo bueno de todo esto es que podemos estar seguros de que si bien ni Superman, ni Batman, ni Papá Noel existen; sí existen los Supertesters.

Es fácil entender por qué los hombres de negocio prefieren cantidad de desarrolladores sobre calidad de desarrolladores, es por lo que yo llamo el pensamiento lineal en la administración y que no voy a discutir nuevamente aquí pero solo diré que esa tendencia lleva implícita la idea de que programar no es tan complicado y por lo tanto cualquier programador podrá hacerlo bien.

Lo que cuesta entender es el por qué Ivar Jacobson dice que el 80% del trabajo de programación es algo mecánico (“it is not brain work” – según él). Ivar Jacobson es uno de esos personajes que todo el mundo debe conocer y cuyos aportes han sido grandiosos (salvo este) y por lo tanto se merece el mayor de nuestro respeto aunque sinceramente lo primero que pensé cuando lo escuché por primera vez fue: “ojalá hubiese estado presente un programador iraquí para que le tirara un zapatazo”

Si a la tendencia de “los hombres de negocio” de preferir cantidad sobre calidad se le suman las opiniones de verdaderos gigantes de nuestro medio como Ivar Jacobson, la idea de que programar es relativamente sencillo toma todavía mucha más fuerza y nos hace un flaco favor. Sumado a esto tenemos una realidad difícil de falta de talentos debido a la gran demanda de desarrolladores en la industria que lleva a que conseguir buenos desarrolladores sea una tarea complicada.

Por estos motivos es que muchas empresas completan sus puestos con lo que muchas veces llaman “programadores promedio” que hace referencia a aquellos programadores cuya principal destreza es la fuerza bruta. (Si como dijo Lampson: todo problema en computación puede ser resuelto añadiendo un nivel de indirección; según el “programador promedio”: todo problema en computación puede ser resuelto añadiendo un IF)

Lo interesante del caso es que las expectativas que se tienen sobre el desempeño de estos programadores son muchas veces demasiado altas y así se pretende lograr software de calidad superior con desarrolladores de calidad promedio desviando el foco hacia las metodologías, QA, auditorías y herramientas entre otras cosas.

Está claro que para muchas tareas de desarrollo no se necesitan genios, también es cierto que las tareas que requieren mayores destrezas las deben realizar aquellos con mayor experiencia y conocimientos, es claro además que todo el mundo es distinto y que no se pueden contratar todos rock stars pero una cosa es decir esto y otra mucho más delicada es decir que programar no es tan complicado.