He querido compartir en este video de 7 minutos mis experiencias con la implementación de test unitarios cuando la inversión en capacitación es escaza. Que peligros encierra una pobre capacitación y ante que escenario nos podemos encontrar es de los objetivos de este video.
Lucas Ontivero
Por muchos años programé en lenguajes que contaban con un preprocesador, recuerdo especialmente a tres: clipper, C y C++. Pero cuando me inicié con java dos cosas me llamaron poderosamente la atención, la primera fue la ausencia del declarados de tipos (typedef) y la segunda, y más dolorosa, fue la ausencia de un preprocesador. La explicación de esto era que estas dos características hacían al código propenso errores ya que lo volvían sumamente ilegible y muchos desarrolladores hacían un pésimo uso ellas. Y es cierto, aunque en ese momento no le entendí puesto que por aquel entonces yo las utilizaba correctamente gracias a haber aprendido estudiando excelentes piezas de código, como el del sistema operativo Minix.
Cuando me introduje en .Net, y conocí CSharp, lo primero que observé fueron los signos #, era evidente que estaba frente a directivas de preprocesador al mejor estilo C, y aunque me dejó con ganas entendí que en el contexto de .Net no tenían sentido más directivas como así también que las nuevas directivas #region eran una verdadera estupidez. Tenía sentido ya que uno de los usos más importante del preprocesador era el de hacer el código portable pero ahora ya no era necesario preocuparse de estas cosas.
Creo que hemos perdido un gran amigo dado que hoy en muchos casos debemos recurrir a técnicas algo avanzadas para lograr lo que antes se podía hacer con una pequeña ayuda del preprocesador. Por ejemplo, vemos el caso de los DSLs. El más grande dsl que conocí fue clipper y si no me crees observa cómo quedaba el código clipper luego ser preprocesado:
En realidad no encontré un ejemplo más significativo pero recuerdo casos en los que una palabra se convertía en un importante bloque de código luego su preprocesado. Entonces, ¿podría el preprocesador ayudarnos en la creación de un dsl sencillo?. Mi respuesta: por supuesto que sí.
No hace falta ir tan lejos, con sólo observar LINQ y las expresiones lambda podemos darnos cuenta que no era necesario modificar el lenguaje para introducir estas características sino que bien podrían haberse resuelto con simple macros de sustitución.
Ahora bien, que se trata de un arma de doble filo no hay dudas pero también debemos reconocer que la posibilidad de modificar el código fuente instantes antes de compilarlo es una poderosísima posibilidad. Pero claro, hasta ahora hemos hablado de preprocesadores clásicos como los de C y C++ pero imaginemos algo más potente, imaginemos un preprocesador capaz de modificar el código de una manera más versátil, quizás con directivas ocultas en comentarios o alguna otra manera sencilla. Tal vez no con simples directivas sino con un lenguaje que sea interpretado y que ejecute acciones sobre código fuente.
Algunas cosa que se me vienen en este momento a la mente son la programación orientada aspecto, la inyección de dependencias, la generación de código basado en el código, etc. Por ejemplo, en C es muy común ver cosas como estas:
También podríamos hacer que, embebiendo un simple comentario en un método privado, el preprocesador se encargará de la creación de un método público para accederlo con el fin de poderlo testear.
Ya sé que hoy tenemos solucionadas todas estas cosas y que parezco un tanto nostálgico pero la verdad muchas veces terminamos recurriendo a reflexión y a la carga dinámica de assemblies para resolver problemas muy sencillos que bien podrían solucionarse a la antigua y no por ello ser un antiguo. Déjeme que les cuente una experiencia de cuando programaba video juegos para celulares utilizando java ME. En Gameloft a partir de un mismo código fuente deben poderse crear binarios del juego para una enorme variedad de dispositivos. El building system (como lo llaman) debe poderse configurar para construir el juego dependiendo del carrier, manufacturer, modelo (de los cuales dependen las apis, el ancho, el alto, las teclas, si vibra o no, las luces laterales), idioma, cantidad de niveles, publicidad activada o desactivada y muchísimas cosas más que en este momento no recuerdo. El tema es que la máquina virtual java no asegura la portabilidad ni mucho menos por lo que el uso del preprocesador en estas aplicaciones era sumamente extensivo y aún lo es.
Lucas Ontivero
Desde hace 2 días que el canal 13 de Argentina está siendo interrumpido por una señal, en la misma frecuencia, de origen desconocido hasta el momento. Ayer, el diario La Nación denunció que una de sus notas, en la que se citaban declaraciones de una jueza de la nación, había sido hackada y alterada. Esto son solo dos hechos, de gran impacto, que demuestran a las claras que si uno se va a la cama dejando la puerta abierta puede encontrarse con algunas sorpresas a la mañana siguiente.
Más allá de que estos episodios tienen el característico olor a podrido propio de los manejos políticos, estas cosas no deberían suceder. Pero me dan el impulso que necesito para escribir una entrada sobre seguridad.
Actualmente estoy coordinando una iniciativa sobre Secure Development en la empresa en la que trabajo, el objetivo es reducir la cantidad y severidad de los defectos de seguridad en el software que se desarrolla. Esta tarea es verdaderamente difícil y por eso hemos perdido muchas horas debatiendo sobre cómo se debe encarar, que capacitaciones son necesarias, que herramientas, que tareas realizar en cuales etapas del ciclo de vida, como se siguen esos defectos, como se miden, como se institucionalizan la conciencia, etc. En fin. El problema es que como siempre, hay gente que conoce muchos sobre seguridad o desarrollo en general mientras que otros solo conocen los ‘if’ y el F5. ¿Cómo se hace software con cierto nivel de confianza con gente que no sabe que es un SQL Injection?. La respuesta es muy sencilla verdad? Claramente, es imposible.
La ignorancia en cuanto a cuestiones elementales del desarrollo de software por parte de gran parte de los ingenieros de software es un tema altamente preocupante y voy a ejemplificarlo con un anécdota reciente: con el objeto de lograr que se tome conciencia sobre la importancia de mejorar la seguridad de las aplicaciones desarrolladas, me puse a probar tres cosas muy sencillas en algunas de las aplicaciones de la empresa a las que tengo acceso, estas fueron: XSS, SQLI y modificación de parámetros pasados por querystring. El resultado fue el muy desalentador. Casi todas las aplicaciones web reventaban a los pocos intentos (y ojo que lo hice a pulmón! sin herramientas). Obviamente, lo siguiente que hice fue reportar los errores cargando los tickets con la descripción de los problemas. El primero decía algo así:
“He detectado que en la pagina [URL] de la aplicación [APP], el campo ‘Search’, es posible inyectar html. Puede comprobarse con esta cadena sin comillas “<h1>hola</h1>”.”
Para mi sorpresa, el mail que envía el sistema automáticamente al usuario que cargó el tickets, decía algo así:
“Su tickets no.[NRO] ha sido asignado al [ALGUIEN] con la siguiente descripción del problema:
He detectado que en la pagina [URL] de la aplicación [APP], el campo [CAMPO], es posible inyectar html. Puede comprobarse con esta cadena sin comillas “
hola
”.
Bueno, al menos es coherente! dije. Pero el tema es cuando me llega el mail de respuesta:
“Sr. Ontivero,
¿Podría aclarar un poco más la descripción de este ticket? ¿Que está Ud. buscando exactamente? ¿Para qué quiere buscar html?…..”
A esto me refiero. ¿¡Cómo puede ser que ni siquiera se haya preguntado cómo llegó ese enorme HOLA en ese mail!?. Solo le faltó decirme “probá sin los <h1> y avisame”.
¿Cómo se llega a esta situación?. Creo que si tus productos se venden de a miles seguramente la reputación de tu software será bien conocida, y la de la seguridad de tus aplicaciones será todavía más comentada, ahora, si haces sistemas a medida el nivel de seguridad de ese software será desconocida para el cliente y en el peor de los casos, será desconocido para ti también. Todos felices.
El software seguro y el inseguro se venden por igual solo que el software más seguro lleva un mayor esfuerzo de desarrollo. Porque es un aspecto invisible para el cliente, y gracias a la ignorancia reinante en el medio, para alguno de nosotros también. Ya sé, ya sé, vos no sos ignorante en este tema y existen miles más como vos, pero eso lo sé porque estás leyendo blogs de desarrollo, este y probablemente otros más de geeks.ms; me alegro por vos pero ¿qué porcentaje de desarrolladores leen blogs o mantienen uno?, ¿cuantos testers solo hacen tests funcionales y nada más que eso?, ¿cuántos managers saben algo de seguridad?, ¿cuánto cuestan los defectos de seguridad?, ¿lo sabemos?, ¿nos importa?, ¿y qué hay del ROI, nos conviene o no?
Creo que estamos mal pero por otro lado creo también que es muy difícil que esto empeore. Ahora, en el futuro inmediato esto debería cambiar a medida que la gente lo demande. Para ello deben ser defraudados y hasta tomar conciencia. Las empresas solo demandarán aplicaciones seguras (y estarán dispuestas a pagar el precio) una vez que vean los números.
Lucas Ontivero
Este videito de solo 1 minuto y 37 segundos muestra lo que se puede lograr con XNA, recursos de terceros como XNA Quake 3 Lib y un poco de matemática básica para implementar algo de física.
Este trabajo se basa en el tutorial de XNA Quake 3 Lib y que reutiliza su código, y otros recursos de terceras personas.
El código del proyecto, el video en 800x600 y una pequeñísima explicación de cómo implementar la gravedad, los saltos y las colisiones en este tipo de juegos lo publiqué en:
http://www.preguntaalexperto.net/articles/lontivero-XNA-Quake-3-Lib-Carga-de-niveles-BSP-Colisiones-Gravedad-Saltos.aspx
Este es mi primera experiencia con XNA y son mis primeras líneas pero no es mi primer contacto con juegos :)
Espero que a algún hobbista le agrade y quien sabe? quizás le agregue algunos enemigos y armas para hacerse algunos tiritos!
Saludos.
Lucas Ontivero
Si hay una aplicación sin la cual no puedo vivir esa es VIM. Vim es un editor de texto sumamente configurable que está pensado para trabajar con texto de la manera más eficientemente posible e imaginable. Puesto que es una evolución de Vi, Vim tiene más de 32 años de evolución.
Vim realmente incrementa la velocidad de desarrollo de una manera fantástica, por ese motivo y dado que vale la pena el esfuerzo, he realizado una serie de 5 vídeos tutoriales sobre los aspectos más elementales de Vim.
Si bien faltan aspectos mucho más básicos como son "cómo abrir un archivo" y "como guardarlo", eso lo veremos más adelante ya que estos videos solo muestran los aspectos más elementales del editor.
Para descargar los videos:
Para verlos por streaming pueden ir a:
http://www.preguntaalexperto.net/articles/lontivero-Tutorial-Baacutesico-de-VIM.aspx
Lucas Ontivero
El correo electrónico es una de las herramientas más importantes de trabajo, todos tenemos un cliente de correo que chequeamos varias veces al día ya sea en nuestro trabajo o en nuestros hogares. Es tanto un medio de comunicación como un sistema para recibir alertas y recordatorios, todos los sistemas se comunican con nosotros mediante correo electrónico, "se te ha asignado un nuevo ticket", "quedan 3 días para renovar las licencias", "inscríbete para el curso de seguridad", "tienen una reunión en media hora", y otros muchos mensajes nos ordenan y recuerdan las tareas que debemos realizar.
Esto crea tal dependencia que en mi primer empleo, en que desarrollaba un CRM, verifiqué una hipótesis muy lógica: cuando no hay correo electrónico el trabajo simplemente no se realiza.
Es claro, el costo de recorrer todos los sistemas con el fin de verificar si tengo algo que hacer con ellos es enorme, las reuniones simplemente desaparecen, la comunicación con los equipos de otros países vuelve a ser como a principios de siglo. Que el servicio de correo no esté disponible hace que la gente se comporte como si le hubiesen cortado la electricidad, no trabajan y no porque no tengan voluntad sino porque el sistema motor se ha apagado.
Por lo tanto, uno puede hacer el siguiente razonamiento: email=bueno => (no email)=(no bueno). La verdad es algo distinta, existe otro tipo de parálisis que se presenta por exceso de email y eso me sucede todos los días. Lo explico.
En mi trabajo recibo entre 20 y 30 email diarios (algo menos los sábados y los domingos), cuando no estoy vinculado a ningún proyecto, número que ha llegado a ascender hasta los 60 emails en mi ante último proyecto. Esto representa algo así como un mail cada 8 minutos.
Pero de donde salen tantos emails!? Son emails institucionales del estilo:
-
no hay aire acondicionado en el 7mo piso.
-
el server unixXXXX será retirado.
-
conflictos políticos en Bolivia, estén alerta si necesitan viajar
-
nuevos productos
-
nuevas políticas
-
nuevos managers o cambios de posiciones
-
posiciones abiertas
-
cumpleaños
-
millones de marketing
-
opciones de compra de acciones
-
ventanas de mantenimientos
-
reuniones
-
trainings
-
que cargues las horas
-
que el equipo de ayuda a la comunidad no sé que cosa quiere
-
las invitaciones a las revisiones de proyectos
-
los blogs de los managers a los que uno está forzado a sindicarse
-
miles de recursos humanos
-
las subastas internas
-
cambios en la obra social
-
y millones de etcéteras que asombrarían hasta a los xmen.
Ahora, cuando estoy en un proyecto, a estos se le suman varios tipos de emails más por lo que la interrupción es constante y la única manera de poder trabajar es no abriendo el outlook. Esto, que a priori resulta una solución, se convierte en una pesadilla al día siguiente en donde uno puede encontrarse con una cantidad de correo verdaderamente apabullante. Por lo que muchos optan por perder algunas horas creando toda clase de filtros, digo algunas horas porque la variedad de fuentes es enorme. Otra cosa espantosa es que a medida que transcurre uno por distintos proyectos, va haciéndose merecedor de nuevos emails que no dejan de llegar una vez que se abandona ese proyecto, por esta razón la creación de filtros no se hace solo una vez.
Pero esta tampoco es una solución muy feliz, es demasiado común reunirse a conversar y que la mitad de los participantes no tengan ni la menor idea de lo que se está hablando simplemente porque "todos esos mail van directo a la papelera". Otro efecto interesante es el de "sí, lo vi pero no lo leí bien", esto no es de gente floja sino que se produce un hábito de leerlos a medias o entre lineas.
Si bien los generadores de mail son en su inmensa mayoría las herramientas de desarrollo, recursos humanos, marketing, los managers de todos los niveles y las áreas de soporte, algunos lideres de proyectos también tienen su lugarcito en esta locura, claro que estos emails suelen estar mucho más relacionados al proyecto que el resto, pero aún así son email que no siempre se leen como debieran, cosa que produce el enojo de muchos productores.
El tema es que muchas personas parecen llevarse bastante bien con esta situación mientras que otras realmente lo sufren. Por lo general uno puede distinguir entre los productores de este spam y los receptores, los productores ya los mencioné pero de entre los receptores, que en principio somos todos, quiero resaltar a los desarrolladores. El problema es que si bien los desarrolladores solemos ser quejumbrosos por naturaleza, esta vez tenemos una justa razón para hacerlos: necesitamos concentrarnos! Es como tratar de resolver una ecuación diferencial en una habitación plagada de mosquitos hambrientos.
Hay una frasecita que escucho casi a diario cuando se aborda este tema: "es que, en algún momento tenemos que trabajar". Comparto. Esto es confesión de improductividad por emails.
Lucas Ontivero.
Esta es la segunda entrega de Key Padawan. Próximamente escribiré sobre los detalles de esta herramienta ya que tiene algunas cosas interesantes pero todavía no es el momento porque todavía es una gran BETA.
El cambio de la versión anterior se debe a que mientras lo usaba me estorbaba mucho. Otra cosa es que no funcionaba bien en teclados en ingles (Esta versión funciona mejor aunque no maneja bien el layout del teclado de mi notebook).
Como lo muestra el GIF animado, esta versión tiene una pequeña área de visualización que es transparente, se oculta automáticamente, se puede mover, se puede redimensionar, puede estar siempre visible y posee un trayicon y un menú con opciones básicas.
Bueno, espero que sea de utilidad.
Saludos.
Lucas Ontivero
He terminado de leer este libro de Terence Parr, The Definitive ANTLR Reference - Building Domain Specific Languages, y es realmente excelente si estas interesado en compiladores,
interpretes, analizadores de código, generadores de código y otras cosillas.
El libro trata sobre la versión 3.0 de Antlr y tiene toda la forma de un manual de referencia en el cual van presentandose temas y ejemplos de implementaciones de lenguajes. Por último desarrolla todo un compilador para un lenguaje de ejemplo.
En breve volveré sobre este tema que me encanta.
Saludos.
Lucas Ontivero
Pregunta al experto y la UTN-FRC te invitan al Primer Fish Bowl en Córdoba
Cuando y donde: UTN Regional Córdoba, Salón de Actos, Miércoles 12 de Noviembre a partir de las 18:30hs.
Trasfondo
En mi ciudad, Córdoba-Argentina, se viene observando cada vez más que en las charlas conferencias sobre tecnología la cantidad de asistentes disminuye progresivamente. En mi opinión, la cual comparto con algunos amigos, esto se debe a que mucha gente, por diversos motivos, va perdiendo o ha perdido el tren de la tecnología o al menos este los va superando y apabullando en su vorágine. Otra causa posible es que la diversidad y puntualidad de los temas que se presentan hace que el público objetivo sea naturalmente pequeño, aún más si se trata de presentaciones de productos y más todavía si esos productos están en beta o por salir al mercado y no presentan una solución real al momento ni tiene aplicación inmediata.
Pero hay más, las presentaciones son justamente eso, comunicación unidireccional, una persona que habla y otros muchos que son meros receptores que no eligieron la temática sobre la que quieren escuchar sino que asisten a presenciar "lo que hay".
Por este motivo, este Miércoles 12 de Noviembre a las 18:30 hs se realizará en la UTN-FRC el primer FishBowl.
Para quienes no conozcan esta modalidad les comento un poco de qué se trata:
El inicio
En el inicio del evento se plantean las bases del mismo. Esto para que las personas que no conocen o no saben de la modalidad puedan ponerse al tanto. Después de esos 15 minutos introductorios, los asistentes deben dirigirse a un pizarrón, o tablón, que contiene una grilla de vacantes y horarios. O sea, algo similar a esto:
| Evento 1 | Evento 2 | Evento 3 |
| Hora 1 |
|
|
|
| Hora 2 |
|
|
|
En esa grilla, cada persona asistente puede proponer un tema. Cada tema propuesto compite con otros en el caso de que existan más temas que los horarios y vacantes posibles. Los demás asistentes votan, si así lo desean, por alguno de los temas ya propuestos o simplemente proponen aquellos temas que les interesan.
Al finalizar esa etapa las charlas con mayores votaciones son las que se llevan a cabo.
La interacción
La idea general es que, en cada charla se colocan 4 sillas. Cada persona que quiere opinar sobre el tema en cuestión debe sentarse en una de las sillas y solo recién emitir su opinión. Siempre debe quedar una silla disponible (para que se siente quien quiere opinar). Si las 4 estuvieran ocupadas, la persona que ya no tiene más que decir, o que ha estado más tiempo, o aquella que simplemente tiene la voluntad de pararse y volver a la "zona" de escuchas lo hace.
Los asistentes pueden ir pasando por diferentes grupos, y no necesariamente deben quedarse en una charla, o en la charla inicialmente elegida. La persona que propuso el tema de la charla es la que inicia la misma, y al mismo tiempo puede o debería, preferentemente, actuar como moderador.
Hay que destacar que no es necesario conocer un tema para proponerlo. Puede, por ejemplo, proponerse un tema del cual una persona quisiera obtener conocimientos ya que es posible que dentro de los asistentes se encuentren personas que sepan del mismo.
En esta oportunidad, cada charla debería tomar alrededor de 45 minutos. Si el mismo se agota antes de tiempo, este se disuelve y las personas pueden ir a observar o participar de otras charlas. Es posible llevar computadoras, y mostrar código y/o presentaciones, bajo la idea de que los asistentes deberán asomarse a la pantalla y tratar de ver algo.
Si se cuenta con algún medio de proyección, también es posible usarlo, aunque esto dependerá directamente de las instalaciones. Que temas tratar: Los temas son de informática, y no necesariamente de código. Tampoco están relacionados a una empresa, industria, propietario o modalidades de distribución. Simplemente es informática. Se podría hablar de generación automática de código, software factories, test unitarios, análisis estático de código, cloud computing, pair programming vs. revision de código, test automation, herramientas de productividad, estimaciones, secure programming, XSS y SQL injection, domain specific languages, CMMi vs Agile, store procedures vs SQL inline, web client vs smart clients, lenguajes funcionales, hasta XNA o el mercado del desarrollo de juegos, o lo que sea.
Lucas Ontivero
Nota: Exite una nueva versión de Key Padawan publicada aquí.
enHace algún tiempo leí en el blog de Roy Osherove's Blog sobre su ShortWatcher, ahora rebautizado "Key Jedi" y me gustó mucho, lo vi especialmente util para mostrar al público de una presentación los atajos que uno iba presioanado.
Hace un par de dias pensé en crear unos videos tutoriales sobre como incrementar la productividad utilizando un mix de VS y Vim así que se hizo evidente que necesitaría una especie de keylogger visual en donde se fuesen mostrando las teclas que presionaba cuando hacia tareas complejas com Vim. Por eso, y siguiendo con la tradición nerd de nombrar cosas con palabras propias de la guerra de las galaxias, y otra tradicción de todo hispano parlante de tirarse un poco a menos que los de habla inglesa, he llamado "Key Padawan" a mi keylogger visual :) (si no sos nerd y no entendes nada, estas en el sitio equivocado).
Las features son estas:
- Siempre está visible,
- Se transparenta para no estorbar (tanto),
- Todas las teclas son visualizadas, hasta los espacios, tabs, escape, en fin, todas
- Tiene un menú contextual para borrar el area de visualizado,
- Presenta el logo de preguntaalexperto.net que hace las veces de link al sitio a la vez que sirve de excusa para pasar el chivo,
Cosas a mejorar:
- Funciona en mi teclado solamente (si alguien lo quiere me lo pide o se compra uno igual).
- El último punto es una broma con algo de cierto: funciona en teclados en español porque el mapeo entre las virtual keys y los caracteres impresos lo hice a pata. (o a mano para aquellos que no esntiendan)
Falta:
- En el menú debería haber una opción copiar al portapapeles y otra para switchear cuando queremos que loguee y cunado no.
- Tengo que hacerlo más configurable.
- Falta un abaut...
Lucas Ontivero
Subtítulo: Como implementar MetaweblogApi en tu sitio web.
Introducción
En mi sitio www.preguntaalexperto.net quisimos brindar a todos los integrantes de la comunidad la posibilidad escribir artículos y publicarlos allí. Por esto, comenzamos tomando como referencia el modelo de CodeProject: subir un html y sus adjuntos. Pero resultaba incómodo hasta para nosotros mismos publicar algo, por eso, y acostumbrados a bloguear usando Windows Live Writer, nos propusimos habilitar las publicaciones mediante esta herramienta.
Como se hace esto de manera sencilla: http://www.preguntaalexperto.net/articles/lontivero-Windows-Live-Writer-y-Tu-sitio-de-contenidos.aspx
Lucas Ontivero
Voy a explicar aquí como hice el generador de RSS para el sitio www.preguntaalexperto.net.
El requerimiento era simple: permitir que lectores se subscribieran mediante RSS para conocer acerca de los nuevos artículos disponibles en el sitio. Es decir, queriamos lograr subscribirnos mediante un cliente como RssBandit.
Así que lo primero fue buscar es schema del xml que genera para a partir de allí generar las clases pero increiblemente o lo encontré por ninguna parte. A decir verdad sí lo encontré pero no era lo que esperaba ya que eran o demasiado complejos o demasiado simples así que:
Busqué algo parecido a lo que necesitabamos y lo encontré en el rss de CodeProject. (http://www.codeproject.com/webservices/articlerss.aspx?cat=1).
La estructura es muy simple:
<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="2.0">
<channel>
<title>The Code Project Latest Articles</title>
<link>http://www.codeproject.com</link>
<description>Latest Articles from The Code Project</description>
<language>en-us</language>
<image>
<title>The Code Project</title>
<url>http://www.codeproject.com/images/codeproject100x30.gif</url>
<link>http://www.codeproject.com</link>
<width>100</width>
<height>30</height>
<description>The Code Project</description>
</image>
<copyright>Copyright © CodeProject, 1999-2008</copyright>
<webMaster>webmaster@codeproject.com</webMaster>
<lastBuildDate>Wed, 15 Oct 2008 15:10:00 GMT</lastBuildDate>
<ttl>1</ttl>
<generator>C# Hand-coded goodness</generator>
<item>
<title>Excel export from DatagridView</title>
<description>A way to export data to native excel (xls) from a Datagridview with any data source</description>
<link>http://www.codeproject.com/KB/grid/exceldatagridview.aspx</link>
<author>kevinuni</author>
<category>C#</category>
<category>.NET</category>
<category>Win32</category>
<category>Intermediate</category>
<pubDate>Wed, 15 Oct 2008 17:03:00 GMT</pubDate>
<subject>Grid & Data Controls</subject>
</item>
</channel>
</rss>Esta es exactamente la información que yo quiero proveer!!
Ahora existen muchas posibilidades para crear este xml:
- Concatenando strings. La más sencilla, rápida y económica de todas. Hasta un mono puede mantener el código hecho de esta manera. Realmente, no sé por qué no lo hice así :) El tema es que es tan poco elegante que pocos que...
- Usando un XmlTextWriter: Más elegante e igualmente efectiva.
- XDocument y XElement: También es muy buena.
- Serializando objetos: La más costosa y rígida alternativa. Esta es la que escogí :(
Luego de tener el xml es necesario validarlo con http://feedvalidator.org/ el cual examina un rss y arroja todos los problemas que tiene según el estandar. Desde el tamaño de la imagen (el logotipo), el formato de las fechas, los textos y muchas cosas más.
En cuanto a las fechas es bueno saber que deben formatearse según lo indica la RFC822. Les dejo un método extensor por si les llega a hacer falta para algo. Tampoco es muy elegante pero funciona a la perfección.
public static class DateExtensions
{
public static string ToRfc822(this DateTime dt)
{
string rfc822dt = dt.ToString(@"ddd, dd MMM yyyy HH:mm:ss zzzz (\U\T\C)",
System.Globalization.DateTimeFormatInfo.InvariantInfo);
rfc822dt = rfc822dt.Remove(rfc822dt.LastIndexOf(':'), 1);
return rfc822dt;
}
}Luego de esto, hay que indicarle al browser que tenemos un rss para que muestre el iconito de modo que el usuario lo sepa. Esto se hace simplemente poniendo:
<link href="http://www.preguntaalexperto.net/rss.aspx" title="Ultimos artículos"
type="application/rss+xml" rel="alternate">
<link href="http://www.preguntaalexperto.net/rss.aspx?q=10masvistos" title="Los 10 artículos más vistos"
type="application/rss+xml" rel="alternate">
<link href="http://www.preguntaalexperto.net/rss.aspx?q=10masvotados" title="Los 10 artículos mejor votados"
type="application/rss+xml" rel="alternate">
Por último, solo me resta decir que como cada cliente RSS interpreta este xml como se le dá la gana, es bueno cumplir con todo lo que nos señala feedvalidator. Es to vale tanto si uno quiere que otros puedan usar su cliente favorito, suscribirse mediante feedburner, o lo que sea. Algo que feedvalidator no nos dice es que en el elemente <guid> (que lo exige) debe agregarsele un atributo isPemaLink="false". En síntesis, debe quedar así:
<guid isPermaLink="false">acá un guid</guid>
El guid no titne que necesariamente tener un G U I D sino que debe tener un identificador único como la url a ese post.
Lucas Ontivero
That's all friends!!! Bueno, es solo para contarles que con un amigo hemos largado con algo que queriamos hacer desde hace tiempo: un sitio de contenidos técnicos en castellano.
La idea es brindar un medio para que quienes comparten nuestra pasión por la tecnología y el desarrollo de software puedan publicar sus articulos, tutoriales, videos o lo que quieran siempre y cuando sea en castellano.
Tengo que aclarar que hemos sido aún más audaces que google ya que lo lanzamos casi en alpha, pero esperamos ir pulindo los detallen en breve.
Aunque no todas son buenas noticias, también las hay malas. Tengo que comunicarles que no me voy de aquí. Sigo siendo un Geek :)
Bueno, para ir cerrando, los invito a que se peguen una vuelta por www.preguntaalexperto.net, se registren y que publiquen algo cuando les de las ganas (para eso está).
Saludos Geeks!!!
Aquí les dejo la segunda parte de la explicación de este patrón. La primera parte pueden verla en [Patterns] Patrón Visitor Explicado. Les dejo también un attachment con los archivos del proyecto por si quieren ver el código más detenidamente (es sumamente sencillo).
Una buena para recursos humanos!
Esta entrada es para compartir una experiencia muy buena. Es que en la empresa ahora... en realidad hace ya un par de meses, tenemos el servivio de chair massage disponible para todos los empleado. La cosa es que estaba bastante tensionado y estresado por temas relacionados a lo proyectos, los deadlines, los clientes y las bolsas de bugs de los productos que mantenemos que me decidí a sacar un turno para unos masajitos, cosa que hice con bastante temor a la burla de algún que otro compañero caza metrosexuales. (Nota: es un chiste)
Esta es la segunda vez que me siento en la silla y la verdad es que considero la experiencia como sumamente positiva. Sí, lo recomiendo firmemente. ¿Se descarga tensiones?. Sí.
En mi vida dentro de las empresas he visto muchos espejitos de colores, promos, beneficios que no cuestan dinero, y otros beneficios "extraños" (una vez me dijeron "en esta empresa trabajamos con mouse OPTICOS" - un beneficio sin duda impresionante) "pensados" por las chicas de RRHH pero, esta vez le pegaron! un urra por ellas sea como sea que se escriba urra (es la primera vez en 30 años que escribo esa palabra).
Bueno, en fin, si estas mucho tiempo sentado, si estas estresado y pensas patear el monitor, o bien ya le empezaste a hablar.... este es un buen punto para empezar.
Sí sí, son en horario laboral.
Esta es la primera parte de la explicación de este patrón. Uno de los patrones más lúcidos.Este es el último que grabo en sesiones nocturnas así que ya no me van aoir susurrando :)
Lucas Ontivero
Aprender a desarrollar y a diseñar software es una tarea en la que hay que invertir muchos años. Hay que ser obsesivo, fanático, hay que equivocarse miles de veces y aprender de esos errores. No contentarse con los aparentes aciertos porque al poco de andar se descubre que no se hizo lo mejor sino que alguien más en un blogs perdido en la web lo resolvió mucho mejor que nosotros y ese alguien también encontrará mejores maneras 10 minutos después de su posteo. Pero sobre todo, hay que leer muchísimo.
En las empresas de desarrollo como mucho existe un 10%-20% de gente con este perfil (atención que hablo de perfil y no de skills) por lo que el restante 90%-80% hará código (y Dios no lo permita, diseños) que van desde extremadamente malo a bastante bueno, mientras que los más experimientados, haran código que va desde lo aceptable a muy bueno con algunos chispazos de excelencia.
El análisis estático de código intenta achicar "un poco" esa brecha haciendo posible la implementacion de estándares y mejores prácticas en la codificación. La idea es extraer conocimiento de los profesionales más experimentados y plasmarlo en un conjunto de reglas que luego guien a la tropa de desarrolladores. En cierto modo esto se logra, porque a cualquiera por más experimentado que sea, una herramienta de análisis estático de código le dirá que su código tiene aspectos a observa, esto es lo mismo que ocurre cuando escribimos 500 u 800 lineas y presionamos F5, el compilador casi siempre nos dice "Eyy! y el punto y coma?" o "Y esta variable no la pensas declarar?" y cosas por el estilo. Sí, el primer análisis estático es el que hace el compilador sobre el arbol de sintaxis. Pero al igual que en el caso del compilador, el nivel análisis que se pueden plasmar en estas herramientas, al menos por ahora, es muy reducido y voy a explicar por qué.
Hace un par de dias, un compañero me preguntó como podia resolver un problema que el "sentía" que no lo estaba resolviendo bien. En una aplicación ASP.NET, tenia un formulario y un conjunto de botones que disparaban distintas acciones sobre los controles del formulario, ejemplo: Clear (limpiaba el formulario), Validate (validaba las entradas), Submit (posteaba el formulario previo tratamiento). El código del método Clear() era similar a este:
1: private void Clear()
2: { 3: foreach (WebControl wctrl in this.Controls)
4: { 5: switch (wctrl.GetType().FullName)
6: { 7: case "System.Web.UI.WebControls.TextBox":
8: ((TextBox)wctrl).Text = String.Empty;
9: break;
10: case "System.Web.UI.WebControls.CheckBox":
11: ((CheckBox)wctrl).Checked = false;
12: break;
13: case "System.Web.UI.WebControls.DropDownList":
14: ((DropDownList)wctrl).SelectedIndex = 0;
15: break;
16: }
17: }
18: }
El problema salta a la vista muy rapidamente, una instrucción switch en cuya expresión interviene una instancia de Type! Esta no es una solución orientada a objetos!. Aquí debe utilizarse un Adapter dije, pero el FxCop no advertía sobre esto. La opción es homogeneizar las operaciones mediante adaptadores:
1: namespace Patterns.Test
2: { 3: public partial class _Default : System.Web.UI.Page
4: { 5: private void Clear()
6: { 7: foreach (WebControl wctrl in this.Controls)
8: { 9: ControlAdapterFactory.Instance.GetAdapter(wctrl).Clear();
10: }
11: }
12: }
13:
14:
15: interface IControlAdapter
16: { 17: void Clear();
18: void Submit();
19: void Validate();
20: }
21:
22: internal class TextBoxAdapter : IControlAdapter
23: { 24: private TextBox textbox;
25:
26: public TextBoxAdapter(TextBox t)
27: { 28: this.textbox = t;
29: }
30:
31: void Clear()
32: { 33: textbox.Text = String.Empty;
34: }
35:
36: void Submit() { } 37: void Validate() { } 38: }
39:
40: internal class ControlAdapterFactory
41: { 42: public static readonly ControlAdapterFactory Instance;
43:
44: private ControlAdapterFactory() { } 45: static ControlAdapterFactory()
46: { 47: Instance = new ControlAdapterFactory();
48: }
49:
50: public IControlAdapter GetAdapter(WebControl wctrl)
51: { 52: IControlAdapter adapter = null;
53: switch (wctrl.GetType().FullName)
54: { 55: case "System.Web.UI.WebControls.TextBox":
56: adapter = new TextBoxAdapter(wctrl);
57: break;
58: case "System.Web.UI.WebControls.CheckBox":
59: adapter = new CheckBoxAdapter(wctrl);
60: break;
61: case "System.Web.UI.WebControls.DropDownList":
62: adapter = new DropDownListAdapter(wctrl);
63: break;
64: default:
65: throw new ArgumentException(
66: String.Format("The control {0} has not an Adapter implemented", wctrl.Name)); 67: break;
68: }
69: }
70: }
71: }
Así que pensé: esta regla es muy sencilla de implementar (en este caso no lo fué porque en el switch, cuando intervienen cadenas, no se utiliza el SwitchInstruction sino un infierno de IFs anidados) y me puse a escribir la regla.
Luego se me ocurrió que sería posible identificar patrones de mal diseño (antipatrones de diseño) que pudiesen mapearse con soluciones orientadas o objetos pero pronto llegué a la conclusión de que esto no es posible debido a que el analizador, en este caso una regla de FxCop, debía "entender" primero lo que el código debia hacer para luego sugerir la solución.
Por otro lado, detectar un mal diseño puede ser factible mediante la detección de patrones de mal diseño o bien mediante algunos otros intentos como el de la "complejidad ciclomática" del código la que, amén de los falsos positivos, permite identificar puntos de mejora pero no puede recomendar nada concreto, más allá de un "divida este método en algunos otros". Sin duda este último análisis puede dar una pista que el desarrollador más experimentado puede "considerar" para un análisis pero que pone al desarrollador junior ante un callejón sin salida: "esto está mal". Pero más allá de esto, el problema mayor es que todas estas alternativas llegan tarde, cuando el esfuerzo para el desarrollo de esas piezas de software ya fueron consumidas. Esto puede verse en herramientas que hacen análisis de algunos aspectos de la arquitectura como Klocwork.
Por esto, aún cuando una herramienta pudiese identificar malos mini-diseños y proponer soluciones, no basta con solo una descripción de la solución al estilo "Reemplace este switch con un Adapter y una Factoría" sino que debería tener capacidades de refactorig que asistiese en la tarea.
Ni el análisis estático de código, ni el análisis dinámico de código nos salvan del mal código. ¿Será la programación con pares o las revisiones de código la solución?
Lucas Ontivero
Resulta que estaba averiguando para hacer una certificación de C++ y entre el material del curso se recomendaba un compiladore de C++ online. Como era la primera vez que veia esto lo busqué para C# y lo encontré!
Se trata de un IDE online (ver la foto de abajo) para proyectos en C# y VB.Net (por ahora) y solo permite usar el framework 2.0 (según dice también es "por ahora" al igual que los betas de Google :)
Este es el sitio: http://compilr.com/ para no tener que loguearse ni nada pueden entrar por acá: http://www.compilr.com/IDE/13/
Nota: hago este post solo porque me parece una curiosidad destacable pero no es una recomendación en ningún sentido.
Lucas Ontivero
Hace una año comencé la serie Introducción a los Software Factory con 4 entradas: [Software Factories] Introducción (Parte 1), [Software Factories] Introducción (Parte 2), [Software Factories] Introducción (Parte 3) y [Software Factories] Introducción (Parte 4).
Hoy quiero exponer los desafios que plantea la implantación de una software factory en el mundo real.
Veamos....
- Al hablar hoy de software factories uno puede revivir el sentimiento de frustración que sentia 15 años atras cuando hablaba de programación orientada a objetos. Nadie sabe muy bien de que se trata pero en lugar de interiorizarse y comprarse un buen libro, prefieren dejar volar su imaginación y crear sus propias definiciones. Recuerdo a una profesora de la universidad inventando toda una teoría paralela mientras que alumnos atormentados se preguntaban si un caso de herencia múltiple entre una clase Hombre y otra Lobo daba por resultado un Hombre-Lobo o algún otro ser mitológico. Con los conceptos de SF hoy sucede exactamente lo mismo.
Otros confunden las clases con los objetos en el sentido de que piensan que los software factories son SCSF, WSSF, WCSF o simplemente "cosas que se hacen con VS". Es decir, no diferencian entre un conjunto particular de instancias de SFs horizontales, en este caso hechas por MS como son SCSF y WCSF, y los conceptos en los que se sustentan.
Esto trae aparejado el siguiente pensamiento: - ¡Nooo, pero para eso falta muchísimo!. (visión developer) Esta es con total seguridad la más común y se compone de dos facciones, los que están en lo cierto (hay avances pero estamos en veremos) y los que piensan que desarrollar software con una SF es algo parecido a "tomo un módulo de ventas, se lo incrusto a este otro de stock... lo pego con dos piecitas de biztalk, lo envuelvo en este estandard y listo!!", esto es producto de las desafortunadas analogías con industrias como la automotríz o la aeronáutica las cuales son de producción y no de desarrollo.
- ¡Es muy riesgozo y nosotros ya tenemos un proceso de producción de software!. (visión PL/PM) Esta es la misma pero con una diferencia importante: aquí es posible hablar de reducción de costos, tailorización de procesos, beneficios en el time-to-market, es decir, es mucho más sencillo traducir los conceptos al idioma de un PL que habla en $$$ al de los desarrolladores que hablan en C++. También es posible interesarlos con los casos de éxito de HP, IBM, Nokia y otros, o alinearlo con objetivos de negocios o con las iniciativas de mejora de la calidad y de reuso de software o alguna otra.
- Si los manager entienden del tema todavia es muy dificil por cuanto se trata de una "inversión" que posiblemente no se alcance a recuperar por lo que querran estudiar el tema (lógico!). Si después de que los números los convenzan, si logran ignorar a los miedosos, deben esponsorear el proyecto de cambio que, piloto de por medio, movilizará a referentes de todas partes a tomar acciones como:
- Tailorizar el o los procesos para adecuarlos a la manera de trabajar que se lleva en los proyectos de esa familia de productos.
- Gestionar la comunicación interna para informar a todos los involucrados sobre la nueva manera de pensar y hacer software. Estos cambios siempre despiertan curiosidad y motivación en la gente por lo que abre las puestas para que se los involucre en las nuevas tareas. Además todo el mundo tendrá preguntas y sugerencias. Si esto no se hace lo que se generará será alguna variante del temor.
- Seleccionar al equipo de desarrolladores que construirá el SF. Aquí el arquitecto es pieza clave y debe tener ante todo un conocimiento muy profundo sobre el dominio.
- etc. Digo etc. porque estos puntos y otros ya los traté en las introducción (parte 2)
En una lista de consideraciones tan escueta podemos ver que existen varias condiciones que probablemente al principio no se tenian en cuenta como que llevan tiempo y dinero y que la fase de codificación es solo una pequeña parte de la cuestión, que involucran a roles de administración de proyectos, gestión de la configuración, especialistas de testing, ingenieros de campo, desarrolladores obviamente y otros, que habrá que mantener la SF, que tendrá que capacitarse a la gente que la utilizará, que debe verse como una inversión a recuperar y que esto sucederá a medida que se vayan entregando proyectos en los cuales se hayan reducido los costos gracias a la utilización del SF, que es una apuesta a largo plazo, y otras cuantas más, pero la síntesis seria algo así como: "Creiste que era más facil ¿no?"
Existen pruebas de que esto no es facil, solo hay que ver como los distintos elementos que conforman el sistema de una SF se han ido utilizando como quick fixs que de a uno logran verdaderamente muy poco. Hay quienes todo lo pretenden resolver con un framework, otros intentan sin exito entender para qué sirven los DSLs y cual es la diferencia con los frameworks, otros utilizan VS (GAT/GAX) para verdaderas nimiedades, los procesos apenas si se alteran en algo.Pero ayer me he dado con una prueba curiosa pero contundente de que esto no es facil, al toparme con este paper de M. L. Griss del año 1993 en el que se plantea la necesidad de crear SFs, y los llama así: Software Factories. Griss comenta los casos de éxito en las iniciativas de SF de distintos monstruos de la economia. Hoy seguimos hablando de los mismos temas.
Lucas Ontivero
El XML es un gran invento pero sinceramente prefiero rodearme de monos con navajas que de desarrolladores con xml. Desde la primera vez que tuve contacto con el Extensible Markup Language hasta el dia de hoy he visto una cantidad de estupideces sorprendentes gracias al mal uso, y al sobre uso de este lenguaje. Voy a ir comentando de a uno los casos reales en que pude comprobar como la fórmula (XML*Inconciencia) da por resultado un verdadero desastre económico.
1.- XMLs a la Dase de datos. Un grupo que desarrollaba un producto de Record Management System para una verdadera multinacional de tecnología concluyó que el modelo relacional, con varios años de existencia y desarrollo, no era lo suficientemente bueno para ellos porque no les daba la suficiente "flexibilidad" que su capilla sixtina necesitaba por lo que decidieron... atención a esta!... crear una tabla con solo dos campos a saber: entityID int not null y, data text. Obviamente en el campo data, del tipo "text", va un enorme y amorfo xml que contendrá los datos que ahora, gracias a esta genialidad, serán libres de toma la forma que quieran.
Como las consultas sobre estos datos se complicaron un poquito se desarrolló toda una libreria para facilitar las busquedas pero funcionaba de la siguiente manera: por cada registro levanto el xml en memoria con DOM y mediante xpath compruebo si es lo que busco o no. Todavia no he visto como resolvieron los outer left joins y las agrupaciones pero sospecho que ya lo tienen en la bolsa.
Esto mismo lo vi muchas veces en muchos lugares así que no es una excepción.
2.- Una alternativa al paso de parámetros. En una migración de un producto grandioso desde Visual Basic 6 a VB.Net, el nuevo equipo decidió que el paso de parámetros entre métodos podía hacerse mucho mejor si todos los datos necesarios se fueran compartiendo en un xml de modo que cada método guardase o añadiese información de contexto (una especie de patrón Context pero "más flexible") a este xml. Así que todos los métodos recibian un solo parámetro del tipo XmlDocument y extraian aquello que les así falta, agregaban más datos y modificaban otros. Una especie de todos los antipatrones juntos: que encapsulamiento ni que ocho cuartos!
Bueno, más allá de que cada desarrollador le agregaba sus datos (y banderas también!) al xml y que modificaba los que habian puesto los otros desarrolladores, el problema fue la performance. Procesador al 100% el 100% del tiempo. Otro problemita se daba cuando un desarrollador nuevo invocaba un método... ya sabia que parametro recibia pero ¿que deia contener el xml? a mirar el código señores.
Pero ueno, de acá a 7 u 8 años, con los nuevos equipos, este producto tendrá un desempeño aceptable.
3.- La doble transformación. Un producto de eLearning se construyó con lo que en esa empresa alguien llamó "la arquitectura de doble transformación", y funcionaba así: ante una petición del usuario se invocaba a un componente que gracias a un XML determinaba que consultas debia tirarle a la base de datos y luego convertia todos esos resultados en un gran XML el cual pasaba por dos "transformaciones", dos XSLTs, el primero hacia operaciones sobre los datos y luego el segundo transformaba (creaba) la UI o lo que obtenia el usuario. De esta manera si mañana salia un nuevo requerimiento para exportar esos datos a .pdf, excel o a cualquier cosa solo se debia tocar el XSLT de la segunda transformación, mientras que lo demas permanecia igual.
¿Alguien puede imaginar lo que habia que hacer para depurar el código JavaScript que se habia generado con un XSLT?
De locos!
4.- El super app.config. Es tan fácil leer desde el app.config, o web.config, que todo lo que alguien no quiere hardcodear lo pone en el app.config. Incluso hasta recursos como los strngs en lugar de ponerlos en archivos de recursos van a parar a los archivos de configuración. Parece que me estoy equivocando, después de todo, no hay motivo por el que no se puedas poner string en estos archivos pero un equipo de trabajo del box de al dado tiene un web.config de casi 3 MB que me resulta sospechoso.
5.- (N)Ant. Escribir scripts con xml como Ant es una burrada. No tiene sentido implementar un leguaje script con XML y solo se justifica por el echo de que es fácil leerlo y nos evitamos la tarea de crear los analizadores léxico y sintáctico sino que solo tenemos que levantarlo con DOM.
Lucas Ontivero
Más artículos
Página siguiente >