Diario de un Dotnetero

En la entrevista que le hicieron al Rocky en DotNetRocks, hizo algunos argumentos breves en contra del Test-Driven Development (TDD)--lo cual me pareció bastante chistoso, dado que en el episodio anterior acababan de entrevistar a Jean Paul Boodhoo, uno de los que anda muy metido con CruiseControl.NET y TDD. En fin, me llamó bastante la atención. Y hoy el Rocky publicó algunos comentarios adicionales. No estoy de acuerdo con algunos de ellos, pero léanlos para que vean por qué:

"As a testing methodology TDD (as I understand it) is totally inadequate. I was unable to express this point in the interview due to the format, but the idea that you’d have developers write your QA unit tests is unrealistic. And it was pointed out on Palermo ’s blog that TDD isn’t about writing comprehensive tests anyway, but rather is about writing a single test for the method – which is exceedingly limited from a testing perspective. [...] But the real key is that developers are terrible testers (with perhaps a few exceptions). This is because developers test to make sure something works. Actual testers, on the other hand, test to find ways something doesn't work. Testers focus on the edge cases, the exceptional cases, the scenarios that a developer (typically?) ignores. [...] I don't buy into TDD as a "design methodology" either. You can't "design" a system when you are focused at the method level. There’s that whole forest-and-trees thing... Of course I am not a TDD expert – by a long shot – so for all I know there’s some complimentary part of TDD that looks at the forest level."

Aunque comprendo sus puntos de vista--sobretodo respecto a que TDD no es una "metodología de diseño", sino una "filosofía de construcción" (¿?)--sigo creyendo que los beneficios de TFD y TDD son mayores a los "perjuicios". Si el argumento principal es que los desarrolladores no son buenos testers, pues propondría la perspectiva de que el desarrollar las habilidades de un tester en verdad te hace un mejor desarrollador. Mi argumento es el mismo que hice cuando hice la analogía entre un escritor y un programador, es decir, un buen escritor/programador opera en 2 modos de pensamiento: el creativo y el censor. Seguro, que un escritor cuenta con un editor (que revisa a otro nivel lo que haces) pero ni modo que pongas al editor a revisar cada construcción gramatical de cada oración de tu libro. Además, no todos los proyectos--me atrevería a decir que la mayoría--van a contar con un equipo dedicado de testers veteranos, así que TFD o TDD garantizaría un mínimo de testing a nivel unitario. Y sí, TDD está limitado. Faltarían más pruebas--no solo hay pruebas unitarias y de regresión, faltaría integración y contra-tontos. Pero esa no es razón para no usarlo--aunque tampoco hay que caer en la creencia de que es una bala de plata.

<acronymHell> CSLA = Component-Scalable Logical Architecture (o algo así, no recuerdo muy bien) </acronymHell>

Hace una semana o dos, Rockford Lhotka finalmente liberó la versión 2.0 del CSLA, que es un framework para objetos de negocios.

Pero con lo perezos... ejem... pragmático que pretendo ser, y con eso de que los libros apenas van a salir en las próximas semanas, pues la entrevista que le hicieron en el podcast de DotNetRocks me cayó como anillo al dedo. Y lo mejor de todo es que no solo lo entrevistaron en audio, sino que hasta sacaron la primera parte de una serie de videos para demostrar cómo usar CSLA, para aquellos que nunca lo han visto o no saben cómo se usa.

Aparte de los cambios que trae el CSLA, en la entrevista se avientan un par de puntadas bastante curas también, entre ellas: lo feo que está el sitio de Rocky--y sí está bien pinche feo para qué negarlo--y las cosas que no son tan buenas de las herramientas ORM (Object-Relational Mapper). Yo estoy del lado de Rocky con lo de ORM, la verdad no me gustan las herramientas (NHibernate, et.al.) con la gran excepción de una: IdeaBlade (luego les platico de ella).

En fin, entre los cambios más relevantes que al parecer hubo entre la versión 1.x y la 2.0 del framework (CSLA) están: Mejoras a la validación de las reglas de negocios

Si usaron la versión 1.0 del CSLA que venía con los libros originales, recordarán que tenían que usar un de BrokenRules.Assert para cada regla de negocios que querían validar. En el libro, Rocky las ponía en los set y get de las propiedades, pero rápidamente uno descubría que esos Assert's se necesitaban en otros lados. Nosotros tuvimos que adaptar el framework y mover todos ellos a un solo método (IsValid) que se mandaba llamar siempre al intenter guardar un cambio al objeto. Sin embargo los resultados fueron menos que elegantes y el código de ese método se complicaba rápidamente porque tenías que determinar si el objeto era nuevo o existente, si lo estabas borrando o no, etc.

Al parecer todo eso ya quedó de lado desde la v1.3 del CSLA. Por lo que entendí, declaró un delegado el cual sirve como base para las reglas de negocio (que ahora son métodos) en tu objeto de negocios en donde le pasas la instancia y la propiedad que quieres validar y éste método te regresa si es válida o no, así como la descripción del error en el RuleArgs.

Soporte para autorización a nivel campo de una clase

Esto es algo con lo que me tocó pelearme personalmente. A menudo el cliente te dice que quiere controlar por seguridades lo que un usuario ve en la pantalla/página a nivel campo. Es decir que quieren que todo mundo vea la misma página pero que nomás fulanito que es supervisor/deidad-menor/etc. pueda ver y/o editar un campo especial.

Cuando me enfrenté a este problema me aventé una esquema semi-sofisticado de roles y permisos, con unos métodos en las clases base de nuestras páginas para que todas pudieran determinar qué pintar en la página en base a los permisos del usuario.

Al parecer no fuimos los únicos en andar haciendo esos jales chicanos y el Rocky agregó funcionalidad en el framework para poner esto en la capa de negocios--donde en realidad corresponde. Dos palabras: ¡Woo-Hoo!

Cambios al DataPortal

El famoso DataPortal--el mecanismo que permitía tener objetos móviles--también ha sido rediseñado para desligarlo de la tecnología que empleaba para la comunicación: Remoting.

A mi Remoting aún no me acaba de convencer. Y cuando aprendí que tanto Remoting como Web Services era más lentos que DCOM--aunque menos latosos para implementar y configurar--pues menos me agradó la fregadera. Lean la segunda parte del libro Expert ASP.NET 2.0 Advanced Application Design y sabrán por qué.

Bueno, pues el buen Rocky parece haber abstraído esa parte y ahora podremos usar, a parte de Remoting, Enterprise Services (COM+/DCOM o como le quieran llamar), Web Services o cualquier otro canal que a ustedes les plazca, incluso Windows Communication Foundation. Tener opciones me agrada.

Mucho se le ha criticado a Microsoft por la nueva interfaz de usuario que trae Office 2007 (Office 12, pues): Que si le da en la torre a los últimos 10 años de convenciones en el diseño de GUIs al deshacerse de los menúes y las barras de herramientas... que si van a provocarle un colapso nervioso a los usuarios, quienes tendrán que re-aprender la manera en que hacen sus cosas... que si lo hicieron porque ahora ya sintieron competencia de OpenOffice.org y necesitan diferenciarse... en fin.

Por ahora, pueden ver el producto en acción mediante este video y decidir por ustedes mismos si vale la pena el alboroto o la lana que tendrían que gastar para actualizarse a la última versión.

(Hmmm, me pregunto en dónde he visto una interfaz similar...)

Parece que estará aún más enfocado a que las personas usen su mouse (ratón, pues). Solo espero que no cambien los atajos que se usan con el teclado, porque eso sí sería impedimento serio para mi: re-mapear todo lo que la memoria muscular de mis manos ha aprendido--¿alguna vez han intentado usar Office o Windows en español? ¿Quién jodidos asocia Ctrl+E con Select All (seleccionar todo), por el amor de Dios? ¡Ctrl+A! ¡Ctrl+A!

Me gusta leer otros blogs, y poner enlaces a ellos. Quizá esto lo vean como que me dio demasiada flojera tirar rollo sobre algo, pero en realidad hay veces que me topo con otras personas que dicen las cosas de una forma mucho más concisa y elocuente que yo. Últimamente me he hecho fanático de Christopher Hawkins, quien con su blog, Effective Software Development, habla sobre temas del proceso de desarrollo de software desde el punto de vista de un Project Manager. Comparto muchos de sus puntos de vista, así que les doy una probadita (sin albur) del rollo que él tira con los siguientes 4 artículos de él que me parecen esenciales:

• 11 Clients You Need To Fire Right Now. Habla sobre 11 tipos de clientes latosos con los cuales te conviene mejor no hacer negocios--o de plano cortar los que ya tienes. En resumen: clientes con los cuales te sale más caro el caldo que las albóndigas. Entre ellos están "el todo-por-nada", "el desilusionado", "el sospechoso", "el flake" (intraducible esa jerga, creo yo), "el hoyo de dinero" etcétera. Léanlo, y si se topan con alguno con el que hacen negocio ahorita no creo que sea coincidencia.
• En I Am Not In The Software Business, Christopher dice algo que he dicho por mucho tiempo: no estamos en el negocio de hacer software, estamos en el negocio de dar soluciones.
• The 5 Pitfalls Of Estimating A Software Project debería ser lectura requerida para cualquier PM que traiga proyectos de software. Entre las 5 cosas que hay que evitar: que estimen personas no-técnicas que no estarán involucradas en satisfacer los requerimientos, el no realizar revisiones post-mortem de los estimados, tratar de estimar sin tener requerimientos claros.
• Y finalmente, Why Your Schedule Is No Good - And How to Fix It, probablemente sea una respuesta al manejo de proyectos a la mexicana, que mencionó el Tocayo hace poco. "¿Saben por qué nadie en la compañía se toma sus días de vacaciones? Porque nadie programa los proyectos adecuadamente. [...] ¿Saben por qué nadie se toma sus días de enfermedad y trabajan enfermos? Porque nadie programa los proyectos adecuadamente. [...] ¿Saben por qué las personas no se toman sus días festivos de ley? ¿Por qué se tienen que quedar tarde? Porque nadie... " bueno, ya tienen la idea, ¿no?

Enjoy.

Con todo el ruido que le andan haciendo al AJAX--y no me refiero al bi-cloro--no es sorpresa que Microsoft sacara sus propias herramientas. Lo que sí me sorprendió es que estén saliendo tan rápido y que sean tan fáciles de usar. Y de pilón, parece que el último CTP (Community Tech Preview) ya hasta trae licencia Go-Live, así que pueden ponerlo en producción (bajo su propio riesgo). Así que si les interesa, aquí hay algunas cosas que pueden hacer para comenzar:

• Vayan a atlas.asp.net, y échenle un vistazo al sitio. Ahi pueden bajar el instalador y la documentación.
• El sitio tiene varios videos, pero al menos vean este, que fue el que me impresionó--en 15 minutos ya tienes una aplicación AJAX-esca.
• Chequen los QuickStart Tutorials, que contienen un montón de ejemplos con código.

Y si quieren ver un sitio interesante que utiliza este tipo de tecnologías, vean PageFlakes, un desktop para el Web que puede consolidar información de GMail, del.icio.us, Flickr, suscripciones RSS, y más. Enjoy

Creo que sé más de física cuántica teórica que de PHP. Bueno, sé que se usa para programar cosas Web, no como otras personas.

Lo cura es que tengo compas, que parecen ser ultra-fans del la cosa esa. La verdad es que tengo ya casi 10 años desarrollando cosas Web (CGIs con Perl, ASP, ASP.NET) pero en todo ese tiempo nunca me había tomado el tiempo para ver de qué se trataba el alboroto con PHP. Así que cuando leí hoy en Slashdot que IBM sacó una lista de lecturas recomendadas, decidí echarle un vistazo.

La lista trae enlaces a todo tipo de recursos, desde cómo adiminstrar hasta como desarrollar con PHP--lenguaje y herramientas de desarrollo. Me fui directamente a la sección de Absolute Beginners, que me llevó a unos tutoriales en el sitio de Zend.

En 3 patadas le pude agarrar la idea del lenguaje--de hecho me supo a scripting de UNIX para el Web. Ya tengo mucho que estudiar.

Así que si están como yo, quizá les sea útil.

Enjoy.

P.D. No se pierdan esta definición de PHP.

Me topé con este artículo que menciona un editor para poder crear tus propios code snippets para Visual Studio 2005, al menos en VB. Hmmm. Me pregunto si funcionará también para C# o si tienes que seguir haciéndolo a pata.

OK, quizá escribir software no sea como escribir ficción. Quizá es más parecido a escribir un ensayo o un editorial, en donde quieres lograr algo específico y concreto, en lugar de postear sin sentido en tu blog como un lunático. Pero los principios son los mismos:

1. Al inicio solo tienes una idea abstracta o peor aún, solo un feeling de lo que quieres decir y/o cómo lograrlo.
2. Hasta que no te sientas a escribirlo, no desarrollas en realidad la idea de lo que quieres decir.
3. Deberías emplear 2 modos mentales: el creativo y el censor. A veces se nos olvida el segundo y algunos programillas no son mas que “primeros borradores” de lo que pudieron ser.
4. Alguien siempre debería revisar las idioteces que se te ocurren antes de publicarlas. Luego escribes 2 páginas de cosas en tu blog cuando las pudiste decir en media. Lo mismo pasa con el código.

Siguiendo con la idea del desarrollador como artista, creo que la bronca es porque es demasiado común que caigamos en consultingware cuando quizá nos convendría más enfocarnos a desarrollar algo pre-empaquetado. Imaginen que Miguel Ángel hubiera tenido al Papa ahí enseguida diciéndole cómo quería que se viera la Capilla Sixtina. Claro que para eso Miguel Ángel seguramente era una chucha cuerera que conocía perfectamente el negocio de su cliente, y por eso lo dejaron hacerlo a su antojo. De cualquier forma, es un camino escabroso, porque, como dijo ayer Gabriel Bravo: “lo difícil es hacerle entender a tu cliente que estás ahí para satisfacer sus necesidades, no para satisfacer sus necedades”. Recuerden: entre necesidad y necedad sólo hay un “si” de diferencia. Así que cuando les pidan sus clientes algo, tengan cuidado de decir “sí” a las cosas correctas.

Desde hace rato noté una analogía en el proceso mental que se sigue para escribir ficción—cuentos cortos o novelas—y el proceso que se sigue para escribir software.

Creo fervientemente que el crear software es mitad arte y mitad ciencia, favoreciendo fuertemente al arte.

Algunos de los mejores codificadores que conozco tienen bastante de bohemio. Les piden un sistema o un requerimiento, y pasa una semana… dos semanas quizá y los ves sin hacer nada, tranquilos como si ponderaran la cantidad de hojuelas que trae la caja de Corn Flakes que se comieron en la mañana… Se echan un café o una chela—dependiendo de la hora del día—y ponderan otro rato más. De pronto, en una sentada de 1 o 2 horas se sueltan vomitando código que a un mortal le parecería inicialmente indescifrable, pero al inspeccionarlo de cerca resulta ser compacto, eficiente y genial.

Sin embargo, la mayoría de nosotros—creo—no somos así, más bien somos como los escritores normales, que tienen que aprender semi-sistemáticamente a evolucionar sus ideas.

Así que ahí les va un cuento y les dejo a ustedes sacar las similitudes. Cualquier coincidencia con cómo se desarrolla—o debería desarrollarse—el software no es mera coincidencia.

Las aventuras de Pito Pérez

Pito Pérez es un joven—ni tan joven—de treinta y tres, chaparro, medio regordete, prieto pa’ acabarla, ah pero eso sí, muy hábil con las viejas. Tiene aspiraciones de escritor, pero en realidad trabaja para el Municipio en el departamento de tránsito entregando placas, porque es el único lugar donde le sirve su título de Licenciado en Filosofía y Letras de la Universidad Técnica Regional del Norte del Tercer Mundo.

Un día se le ocurre la genial idea de convertir sus aventuras teiboleras en un cuento corto. En uno de los alucines que tuvo se imaginó que las señoritas que bailaban en esos establecimientos eran literalmente de otro planeta: con solo una sonrisa y una enseñadita de nalgas, convertían a los hombres débiles (osea el 99% de ellos) en zombies descerebrados de quijada abierta que obedecían ciegamente a sus comandos, les daban todo su dinero y hacían únicamente lo que ellas querían.

Claro que también habría en la historia un héroe—basado en él por supuesto—que era inmune a las emanaciones feromónicas de la raza de viejas extra-pechugonas extra-terrestres que amenazaban con dominar el mundo.

“Esa es la trama, a grandes rasgos”, pensó él, aunque en realidad no tenía ni puta idea de exactamente qué quería ni a dónde iría con la historia.

Con voz de anunciador de la serie viejita de Batman en su cabeza se escucha:

“¿Serán suficientes para nuestro héroe las katas mágicas que le aprendió al David DeAngelo en persona? ¿Logrará nuestro héroe dominar esta amenaza a la civilización, salvar al planeta y hacerse de un súper-harem? No se pierdan el próximo capítulo de Las Aventuras del Gran Pit…, ¡ah caray! Como que no es bueno ese título, ¿verdad?”.

En fin, ya en pleno trance creativo se sienta a escribir la historia. “Lo más importante para escribir una historia es sentarse a escribirla”, le enseñó su profesor de la facultad de artes y ciencias políticas.

Y después de 10 páginas de prosa sin censura, sin siquiera revisar la ortografía, saca un primer borrador. Como le enseñaron en la Uni, cambia su “cachucha de escritor” por la “cachucha de revisor” y comienza a disectar la historia, con la agudeza de un cirujano plástico. Se da cuenta que el primer borrador apesta, gacho. Pero está bien, porque como le dijo su profe de ficción, “un primer borrador debe ser malo”.

Dos días después, acaba de cortar la mitad de la paja a la historia, de re-escribir párrafos enteros y de reacomodar la trama y el cierre para dar un efecto más dramático, aunque se parezca a la película del Sexto Sentido. Y contento y feliz con su gran obra maestra la manda a la revista TVyNovelas para ver si la publican. “Digo si publican las hazañas de la Gloria Trevi, seguramente les interesará mi historia, y si no, se las mando a los de Reader’s Digest ¿no?”.

Unas 2 semanas después recibe una carta del editor de TVyNovelas diciéndole que le encantaría publicar su cuento, pero que ve “áreas de oportunidad”:javascript:void(0) Publish Post

“Estimado Sr. Pérez: bla blah bla, bla blah… nos interesó su historia… bla blah blah … Si logra bajarle otras 2 páginas y se deshace del personaje mamilas del DJ chilango que se la pasa haciendo ridiculeces, entonces tendrá una historia que estaríamos orgullosos de publicar.”

“¿Deshacerme del Frank? ¿Qué están locos? ¡Piden a un artista cambiar su arte, jamás!”

Pero después de humear 3 días sintiéndose el regalo de Dios a la literatura castellana—después de Octavio Paz, claro—le gana la ambición del reconocimiento y el deseo de que su cuento sea publicado. Hace las modificaciones solicitadas por el editor y se da cuenta que en realidad sí quedó una mejor historia.

Me siento un poco ruco. Hace uno o dos fines de semana me topé a mi primo en una reunión familiar y me contó, bastante emocionado que aún le llegan mensajes de felicitaciones y agradecimientos por un sitio de Web que hicimos juntos cuando él era profesor del Tec y yo aún comenzaba con las cosas Web. El sitio fue Matemáticas en Movimiento. Ha cambiado de dirección un par de veces, pero aún anda flotando por ahí en el ciberespacio. Sniff, aún aparezco en los créditos. Mi “padrino”, Erick Lerma fue el buen tercio en el equipo. Comenzamos en junio de 1996, si no recuerdo mal, y publicamos el sitio en la primer mitad de 1997. Casi 10 años hace de eso. Sniff. Pa’ que vean cómo hice mis primeros pininos… antes del ASP clásico… antes del .NET, MathML (XML) y todas esas cosas. Puro HTML, GIFs y JavaScript--aunque al inspeccionar el código se ve que le metieron mano con alguna tarugada como FrontPage o MS Word. Oh, cómo han cambiado los tiempos. (¿Escuchan ustedes un violín melancólico en el fondo? jejeje) Así que si son medio burrones para lo que es cálculo y esas cosas definitivamente échenle un ojo. Aprenderán cosas que son mucho más difíciles de comprender utilizando solo un libro, y eso es decir mucho. Y no porque sea mi primo, pero la verdad es que Sergio se dejó caer la greña con el contenido y las animaciones.

Ayer vi este post de Grady Booch en su blog y me pareció chistosísimo (y cierto).

"My take on the whole SOA scene is a bit edgier than most that I've seen. Too much of the press about SOA makes it look like it's the best thing since punched cards. SOA will apparently not only transform your organization and make you more agile and innovative, but your teenagers will start talking to you and you'll become a better lover. Or a better shot if your name happens to be Dick [Cheney]. Furthermore, if you follow many of these pitches, it appears that you can do so with hardly any pain: just scrape your existing assets, plant services here, there, and younder, wire them together and suddenly you'll be virtualized, automatized, and servicized. What rubbish. SOA is, first and foremost, about the A part of the acronym (architecture). Organizations who already have a solid approach to architecture will likely do reasonably well with SOA; organizations who already have a broken architecture and/or a broken architectural governance practice will likely fail with SOA and then blame SOA on all their problems."

Échenle un ojo al post completo aquí.

Estaba ya apunto de comenzar a echarme un rollo sobre el curso para "principiantes" que estoy dando, cuando me dí cuenta que Alex Briseño (aka Pelos) anda haciendo algo similar en su blog. Así que mejor me espero y veo si puedo platicar con él este martes en la reunión de la Comunidad .NET de Juárez. A ver qué sale. Ahorita ando investigando si con algo como Google Pages podría hostear los archivos zip o ppt con las presentaciones, pero por ahora estoy en la lista de espera. Por lo pronto les comento que los chavos que están llevando el curso van bastante bien, aunque no logramos cubrir todo lo que les tenía yo programado para esta semana, me comentan que han aprendido mucho, y en verdad los resultados de las prácticas que les he dejado lo reflejan. Ahorita me estoy aventando la presentación de mañana donde trataremos puro XML con .NET. Para algunos de los siguientes temas, los pondré a hacer unos CBT's (computer-based trainigs) a los cuales tenemos acceso en nuestra empresa, porque eso de dar clases es bien cansado--por cada hora de clase tengo que pasar al menos media de planeación/preparación--y hay cosas que las explican mejor los CBTs o los libros.

No he podido postear esta semana porque resulta que me cambiaron de un proyecto a otro, y hace como una semana me dijeron de pronto que tenía que dar un entrenamiento. Resulta que contrataron otros cuatro compañeros, que no están recién salidos de la carrera, pero nunca han manejado cosas dotneteras ni de Web... han manejado y programado en varias plataformas y en otros lenguajes, pero nada que ver con C#... ni siquiera VB. Estas son personas que traen conceptos básicos de orientación a objetos pero no conocen las herramientas específicas. Así que tengo 3 semanas (8 horas diarias) para enseñarles lo más que pueda. Mi objetivo es que queden a un nivel como para presentar el examen de certificación de Microsoft. Y siendo que soy medio fresa y ex-profesorcillo de la Prepa del Tec, decidí diseñar el curso en modalidad "rediseñada"... lo cual significa que es un curso casi auto-dirigido, y yo estoy más bien como facilitador/mentor que como "maestro". En otras palabras, echo muy poco rollo--solo en las cosas más abstractas y difíciles de entender--y el resto son actividades: lecturas específicas en libros con su chorro de preguntas para revisar y discutir, videos, tutoriales en línea, y bastantes practiquillas. Apenas llevamos 3 de las 15 sesiones, pero hasta ahorita la retroalimentación que me han dado y los resultados que he visto con los chavos--ejeeem, casi todos están más jóvenes que yo--han sido muy buenos. Voy a ver si no hay problema con mi empresa y les puedo poner las presentaciones, o de perdida la lista de actividades que estoy abarcando en el curso, a manera de "guía de estudio para principiantes". Luego les digo.

Comparado con estos weyes, no merezco el título de geek. Por favor, mátenme si algún dia llego a algo remotamente parecido.

Después de mucho buscar y esperar, finalmente encontré los Code Snippets para Visual C# 2005. Les recomiendo mejor bajarlos todos de un guamazo, en lugar de uno por uno, y luego hagan lo que dice en esta página. Para los que no saben de code snippets, este es un feature de Visual Studio 2005 que te permite insertar un machote (sin albur) de código pre-definido para tareas sencillas y comúnes. Esto facilita enormemente las cosas para la raza que apenas comienza a aprender, ya que con la enorme librería de clases del .NET Framework a veces parece difícil hacer cosas sencillas, como cómo leer un archivo o registrar un evento en el EventLog de la máquina. Los proyectos de VB 2005 ya traen de cajón un montón de snippets, pero si querías hacer lo mismo con C#, te tenías que conformar con unos patéticos para cosasa como for's o if's. Supongo que asumieron que si sabías C# deberías saber lo que estabas haciendo... En fin, lo único que tienes que hacer para usarlos es dar clic derecho en el editor de código... Insert Snippet... y te da un menú para que escojas una tarea de diferentes categorías, como el siguiente ejemplo (dale clic a la imágen para verla bien): Otra alternativa es utilizar el shortcut (atajo pues) del snippet--en el ejemplo de arriba sería appEvent. Del editor de código, comienzas a teclear el shortcut del snippet... el IntelliSense lo reconoce, TAB + TAB--mi nueva combinación favorita--y listo, en menos de 2 segundos tienes tu código. De ahí solo tienes que llenar las cajas resaltadas, y estás listo pa'l baile.