.Net | Tecnología, Emprendimientos y Experiencias de Vida

F# – Programación Funcional en Visual Studio 2008

(¡Se el primero en puntuarlo!)

Loading ...

septiembre 06, 2008 Fede 3 comentarios

Hace un tiempo comentaba que ya iba a escribir algo sobre F#, un nuevo lenguaje resultado del trabajo de Microsoft Research que se enfoca a utilizar la programación funcional.

La programación funcional es un paradigma de programación donde las situaciones se resuelven como si se aplicaran funciones matemáticas. En la historia de la informática se han presentado varios casos de lenguajes funcionales, siendo los más conocidos Haskell y Miranda.

Pero en el mercado, los lenguajes funcionales no han tenido mucho éxito. La Programación Orientada a Objetos es el paradigma más utilizado por los lenguajes más comunes como Java, C#, Visual Basic, Delphi, entre otros.

De forma que hoy contamos con el el primer Comunity Preview de F#, un lenguaje que conjuga la programación funcional junto a la orientación a objetos y toda la potencia del Framework .Net.

Entonces, bajamos el CTP September 2008 de F#. Si tenemos Visual Studio 2008, lo instalamos. Luego aprendemos algo de F# en el sitio de MSDN al respecto. Y para finalizar, escribimos un Hello World.

¿Pero para que nos sirve F#? Sin duda podremos escribir cualquier tipo de programa, incluso hasta juegos de Xbox usando XNA. Pero F# está especialmente diseñado para escribir programación paralela y programación orientada a lenguajes. ¡Voy a poder escribir mi propia versión de Logo! (Nota: Logo también tiene características funcionales porque está basado en Lisp, otro lenguaje funcional bastante famoso).

Mi Hello World se ve así en el código:

y de esta forma en su ejecución.

Habrán notado que en el código que se definen varias funciones y que se programa muy diferente a cualquier otro lenguaje que puedan mencionar en menos de 10 segundos. Así que dejemos que los expertos nos ayuden a programar en F# con esta introducción de 20 minutos al lenguaje.

Aplicaciones ASP.NET con debug=true

(¡Se el primero en puntuarlo!)

Loading ...

agosto 10, 2008 Fede Se el primero en decir algo!

Hoy Mauricio compartía un post interesante donde alertaba de que no se deben correr aplicaciones ASP.NET con la configuración debug=true en Producción.

http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

Es realmente muy interesante lo que dice y creo que no le prestamos mucha atención a eso cuando ponemos en producción. En especial rescato los siguientes puntos:

1) La compilación de páginas ASP.NET lleva más tiempo (ya que algunas optimizaciones están deshabilitadas).
2) El código puede ejecutarse más lento (ya que están habilitadas algunas rutas adicionales de depuración).
3) Se utiliza mucha más memoria en tiempo de ejecución.
4) Scripts e imágenes descargadas desde el WebResources.axd no son cacheadas.

Lean el artículo mencionado (en inglés) si quieren más datos de cada uno.

Sockets en Visual Basic .Net

(¡Se el primero en puntuarlo!)

Loading ...

agosto 07, 2008 Fede Se el primero en decir algo!

De las cosas más interesantes para programar, son las aplicaciones distribuidas. Éstas, requieren que un programa cliente se pueda comunicar con un programa servidor, lo cual puede ser logrado de varias formas. La forma más moderna, es utilizando WebService, tanto asíncronos como sincronizados. Otra forma, utilizando colas de mensajes lo cual es un método bien asícrono. Pero si queremos un sicronía completa y además, velocidad, debemos utilizar Windows Sockets.

Un socket es una dirección de comunicación que utiliza una aplicación y que tiene asociado una dirección IP y un número de puerto.

Mi primer intento con Windows Sockets murió con Visual Basic 6. Con .Net, la cosa es bastante más sencilla, en especial porque existe más información que antes. Y sobre todo, en Visual Basic. Así que navegué un rato por Internet buscando algo sencillo y rápido, y encontré un resultado muy bueno en http://www.elguille.info/colabora/puntoNET/PabloTilli_SocketsVBNET.htm, una página de el amigo Guille, uno de los Gurú de Visual Basic en español.

Mi único problema al respecto, es que ese artículo está escrito utilizando aplicaciones Windows Form. Yo lo necesitaba con Servicios de Windows. Pero eso es otro artículo.

Para entender lo que hace el ejemplo mencionado, basta mencionar que utiliza algo de multitarea y algunas cosas del System.Net. En principio se separa el código en 4 partes.

1) Código de la aplicación servidor
2) Clase conteniendo el código de comunicaciones del servidor
3) Código de la aplicación cliente
4) Clase conteniendo el código de comunicaciones del cliente

Realmente esta separación está muy buena, porque nos permitiría construir nuestro propio ensamblado de comunicaciones por sockets y referenciarlo en varias aplicaciones. Incluso, hasta podríamos construir clases que permitiera untilizar diferentes métodos de comunicación en una misma aplicación. Así, dejaríamos la aplicación cliente con toda la lógica que le es importante e independizándola de las comunicaciones que utilicemos.

Actualizar automaticamente una aplicacion .Net (2)

(1 votos, promedio: 2,00 sobre 5)

Loading ...

mayo 19, 2008 Fede

Seguí con el tema del post anterior. Pero esta vez estudié el tema de ClickOnce.

Ya había visto ClickOnce cuando apareción con la salida de Visual Studio 2005, sin embargo, aunque básicamente lo hice funcionar aquella vez y también ahora, aún hay cosas que no me convencen del todo.

¿Será porque parece demasiado sencillo?

Comencé por abrir Visual Studio 2005 y crear una aplicación. Luego elegir la opción de Publicar.

Me llevó aun asistente al que le respondí todo que sí y la aplicación quedó publicada en el Information Server de mi PC. Allí me mostró una página web con un botón de Instalar. Hice click, se instaló y se abrió la aplicación.

Ahora la aplicación me quedó en el menú de programas y cada vez que la inicio se contacta con el sitio web desde donde se descargó. Checkea si hay una versión nueva, y si es así, la descarga y ejecuta.

¿Demasiado sencillo, verdad? Creo que está bueno para aplicaciones provistas por el departamento de IT de una compañía, pero no tanto para distribución de aplicaciones que están disponibles a través de internet para cualquier usuario de hogar u oficina.

Sin embargo, cada realidad es diferente y debemos analizar cada una de las opciones con los datos y aplicaciones de verdad. Al respecto, es bueno tener en cuenta algunas notas que encontré en la información que MSDN tiene sobre ClickOnce. En especial, se compara ClickOnce con Windows Installer (quería pegar la tabla acá, pero el **** Blogger… no soporta tablas).

Nótese que en Visual Studio 2008 con Framework 3.5, ClickOnce sigue funcionando igual. No esperaba demasiados cambios, pero las páginas de información de MSDN al respecto, dicen básicamente lo mismo que las de Framewor 2.0.

Actualizar automáticamente una aplicación .Net

(2 votos, promedio: 4,00 sobre 5)

Loading ...

mayo 17, 2008 Fede 5 comentarios

Hace unos días un amigo me comentaba que quería hacer una aplicación .Net que se actualizara automáticamente. Googleando, encontré varios recursos.

Primero me topé con algo que parece que está archivado, pero aun disponible. Es el Updater Application Block 2.0. Como es parte de los Pattern & Practices de MS, fui por allí y descubrí que lo que necesitaba era leer la guía de Implantación de aplicaciones basadas en el Framework 2.0. Leyendo la guía, que es un PDF muy interesante (cero línea de código, muchos conceptos), encontré que referenciaba al sitio oficial de Windows Forms y Windows Presentation Fundation: WindowsClient.NET. Uno de los artículos de dicho sitio, me llevaba directo a la implementación de una aplicación auto actualizable.

Un pequeño problema que encontré, es que las aplicaciones de ejemplo estaban hechas en C#, mientras que a mi C# me paspa un poco (no por el lenguaje, sino porque en Visual Basic, Visual Studio tiene más ayudas) y mi amigo solo programa en Visual Basic.

Resolviendo el problema

La solución que elegí, es utilizar una aplicación de fachada que chequea por actualizaciones e inicia la aplicación de verdad. El chequeo se hace contra un WebService. Dicho WebService compara la versión de la aplicación que lo llama, contra la versión de la aplicación que tiene guardada.

El WebService devuelve la ruta de desacarga y la aplicación de fachada descarga el nuevo ejecutable. Tanto lo descargue, como no lo haga por ya tener la versión actual, dicha aplicación de fachada inicia a la aplicación real, y se cierra.

El código del WebService es demasiado tonto como para ponerlo, sin embargo, puede ser interesante mostrar parte del código de la aplicación de fachada. Tengan en cuenta que es un código para demostrar como se haría. Compila y hace la descarga. Cualquier purista vería que no es un código para copiar y pegar en una aplicación de verdad.

Quienes deseen implmentar algo así, pero de verdad, lean el PDF que mencionaba para tener los conceptos y luego vayan al articulo de WindowsClient.Net. Con un poco de trabajo podrán hacer andar los ejemplos en C#, y ya que están, escriben todo en C# y van a sentirse más machos.