Federico de los Santos

Hoy me preguntaron mi opinión sobre si debería dejar de escribir código Visual Basic y pasarse a C#.

Mi respuesta: es totalmente una decisión personal.

Los dos lenguajes, son totalmente equivalentes. Todo lo que puedes hacer en uno, lo puedes hacer en el otro. Yo sigo programando en Visual Basic y no me he encontrado con ninguna limitante del lenguaje. No pienso cambiar, al menos que en algún proyecto se me solicite de forma explícita por capricho del que lo dirija.

Sin embargo, identifico las siguientes ventajas en cada uno:

Ejemplos de código de cosas complicadas: están principalmente en C#.
Facilidades de Visual Studio para programar como Intellisense y otras tecnologías: están o son más completos principalmente en Visual Basic.

Particularmente, Visual Basic tiene algo imbatible. El objeto My. Con él, en Visual Basic se hace un ping con una línea de código, mientras que en C#, se necesitan cerca de 10. Adicionalmente, Visual Basic tiene heredado desde las versiones que no eran OOP, el concepto de los módulos. Si necesitas hacer una funciona que le pases un parámetro y te lo devuelva transformado, ¿qué necesidad de estar declarando un clase y un método estático, etc, etc? Creas un módulo y lo usas.

C# requiere mayor cuidado a la hora de escribir código, porque diferencia entre mayúsculas y minúsculas. A causa de eso, no autocorrige el código. También requiere el uso explicito de llaves { } que se usan para armar las estructuras de control. Todas las sentencias deben terminarse con punto y coma (;), lo cual genera muchos errores por olvidarse de ellos.

Si se quiere migrar a C#, puede plantearse a partir de los nuevos proyectos que se tengan, pero no tiene sentido reescribir el código que ya se ha hecho en Visual Basic. También, una solución puede tener proyectos en diferentes lenguajes. Todos los lenguajes .Net generan el mismo código intermedio (MSIL), por lo cual son equivalentes a la hora de ejecutarse en el procesador.

Espero que esto les aclare un poco el panorama.

También puedes ampliar algo más en este otro post que encontré por ahí.

Etiquetas: Informatica, Programacion, Software

Mi peor experiencia en FING fue conocer el lenguaje Modula-2. Y no puede haber peor noticia para mi y muchas otras personas que no gustamos de dicho lenguaje, que recordarnos la existencia de un Modula-3.

Modula-3 existe hace años y alguna vez leí de su existencia. Pero así como entré, salí. Hoy, una entrevista de Computer World a Luca Cardelli, uno de los diseñadores de tal engendro que actualmente trabaja en Microsoft Research, me retrotrae a tales sinsabores. Pero como ahora soy un adulto (ya no me aceptan la Tarjeta Joven cuando me piden la cédula) he decidido leer el artículo completo.

Algunos extractos graciosos traducidos libremente y a veces comentados:

¿Por qué sintió la necesidad de desarrollar Modula-3?
El "problema" era tener entornos de programación que tuvieran lenguajes type-safe. Significa [...] que si mi cliente encuentra un error, puedo decir: "no es mi problema, alguien debe estar haciendo chanchadas en algún lado" porque el chequeo de tipos me garantiza que no es mi problema. No podrías decir eso con C++.

¿Cómo influenció Modula-2+ el diseño de Modula-3?
Básicamente es el mismo lenguaje, pero sin las puntas oscuras. (FD: entonces lo hicieron de cero, no?)
Modula-2+ [...] necesitaba limpieza y estandarización. (FD: yo ya lo sabía!)

¿Había una necesidad real para un lenguaje así en los 80s?
Si, estaba en plena moda [...] y aunque se continúa con Microsoft's .NET, aun no estamos ni cerca. (FD: Es una utopia de facto. Necesitamos vender licencias y rehacer las aplicaciones cada 2 años para no quedarnos sin trabajo en el futuro)

¿Qué piensa acerca de que el lenguaje no haya sido adoptado por la industria, pero aun es influyente en circulos de investigación?
Básicamente por la competencia con Java [que soporta casi todo...]. Creo que ellos leen nuestros reportes técnicos. [...] Sin embargo creo que el sistema modular de Modula-3 es por lejos superior al de Java [...].

¿Aún usa Modula-3 hoy en día?
[...] Dejé de usarlo cuando me fui de DEC (FD: DEC se fundió y la compró Compaq, que se fundió y la compró HP). Usé Java por un tiempo, pero ahora uso C# y F#.

¿Cómo se siente acerca de afirmaciones como la siguiente en Wikipedia: "Modula-3 se enseña únicamente en universidades, en cursos de comparativas de lenguajes de progrmación, y sus libros ya no se imprimen"?
¡Lo cual probablemente es muy cierto!

¿En su opinión, cual ha sido el legado de Modula-3 al desarrollo para computadoras?
Creo que Modula-3 jugó un rol importante en la programación type-safe. Cedar/Mesa fue muy innovador, pero siempre lo mantuvieron en "secreto" dentro de Xerox. (FD: Xerox es una máquina de perder oportunidades de negocio. Inventaron las interfaces gráficas, el mouse y no sé cuanta cosa más que no convirtieron en productos)

¿Hacia donde ve que van los lenguajes de programación, en especial en los próximos 5 a 20 años?
La programación Funcional está volviendo. [...] F# y Haskell se vuelven cada vez más populares. (FD: se viene post de F# dentro de poco)

¿Algo más de interés que desee agregar?
Solo que la más excitante reunión de diseño de Modula-3, fue abruptamente interrumpida por el terremoto de 7.1 grados en San Francisco. (FD: ¡Fue una señal del Señor! ¿Entendieron que no tiene que haber ningún Modula-X más?)

Nota: no encontré como traducir "type-safe".

Etiquetas: Nuevas tecnologías, Programacion

La gente que usa Linux se vanagloria de todas las bondades y cosas en las que Linux es superior a Windows. La verdad, no sé si es mejor o no. Los considero equivalente y uso el que me sirva según la ocasión.

Una de esas "maravillas" que tiene Linux, son los múltiples escritorios. Windows también los tiene, pero deben instalarse aparte y Microsoft no los provee. La primera vez que usé multiples escritorios fue con Windows NT 4.0. Pero hasta el día de hoy no tuve la necesidad de usarlos.

Una rápida búsqueda en Google me llevó a conocer Vista/XP Virtual Desktop Manager. No solo es gratuito sino que también es de código abierto.

Vista/XP VDM funciona tanto en Vista como en XP. Pero se obtiene un mejor resultado en Vista gracias a las nuevas APIs de vista previa que incluye.

Lo estoy usando desde hace varias semanas para correr una aplicación de edición de video, ya que me encuentro con la necesidad de procesar videos. La aplicación utiliza una ventana modal, por lo cual, me dificulta utilizarla por varias horas. En especial, me hace dificil la tarea de ver y trabajar con los archivos del escritorio.

Así que ahora corro esa aplicación (el querido Windows Movie Maker) en un segundo escritorio y me quedo en el primero para hacer el trabajo habitual.

Para otra cosa que es util, es para esconder ventanas de descargas. ¿Cuántas veces te pasó que cuando la descarga finaliza viene a primer plano justo cuando estabas escribiendo y ocasionas la cancelación de la descarga cuando estaba a punto de terminar?

Espero que si alguien anda con un problema similar el mio, o simplemente es curioso, ¡lo aproveche!

Etiquetas: Nuevas tecnologías, Programacion, Software, Windows Vista

El tipo de control más divertido que hay en una aplicación Windows (WinForm), son las barras de progreso. Además, son muy fáciles de usar. Máximo, mínimo, valor actual y se terminó la historia.

Sin embargo, cuando creamos una aplicación de console (Console Application) también conocida como de línea de comandos, hacer un indicador de progreso no es tán fácil como arrastrar un control y establecer 3 propiedades.

Hoy me encontré con ese problema y llegué a desarrollar la siguiente solución de prueba:

Luego, lo integré a mi aplicación agregándole el siguiente procedimiento:
Para usarlo, únicamente llamar al procedimiento con esta línea:

EscribirProgreso(Valor)

donde Valor es una variable que contiene el contador de avance que utilizaríamos si fuera una barra de progreso. Lo mejor de todo, es que no hay que establecer valores máximos y mínimos, ya que lo que se muestra, es una simple animación.

Etiquetas: Programacion

A veces se descubre én Internet una serie de archivos que sería interesante descargarlos todos. Por ejemplo, hoy encontré en una Wiki de Stargate, que podía descargar los Screenplays de los 214 capítulos de Stargate SG-1.



Aquí el código para copiar y pegar.

Module Module1
Sub Main()
  'http://media.dave.tv/sites/stargatesg1/screenplays/s06e06.PDF
  'V lido del s01e01 al e10s09. Los dem s hay que bajarlos a mano.  
Dim Intentos As Integer = 0
  Dim Descargas As Integer = 0
  For Temporada As Integer = 1 To 10
    For Capitulo As Integer = 1 To 22
      Dim URL As String = _
"http://media.dave.tv/sites/stargatesg1/screenplays/"
      Dim Archivo As String = "s" & Right("0" & Temporada.ToString, 2) & "e"
      Archivo &= Right("0" & Capitulo.ToString, 2) & ".PDF"
      Dim Destino As String = My.Application.Info.DirectoryPath
      URL &= Archivo
      Destino &= "\" & Archivo
      Console.WriteLine("Descargando de: " & URL & ".")
      Intentos += 1
      Try
        My.Computer.Network.DownloadFile(URL, Destino)
        Console.WriteLine("Archivo " & Archivo & " descargado.")
        Descargas += 1
      Catch ex As Exception
        Console.WriteLine("No se pudo descargar " & Archivo & ".")
      End Try
    Next
  Next
  Console.WriteLine("Tarea finalizada.")
  Console.WriteLine("Se descargaron " & Descargas.ToString & " de " & _
  Intentos.ToString & " intentos.")End Sub
End Module

Siempre que enuentres una serie de archivos a descargar, hacer algo como esto es básico para tener más tiempo libre para mirar capítulos de tu serie favorita!

Etiquetas: Programacion

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.

Etiquetas: .Net, Microsoft, Programacion, Software

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.

Etiquetas: .Net, Microsoft, Programacion, Software

Acabo de leer en el Blog de Brenner y Fogel, un artículo donde Brenner plantea su preocupación frente a la despreocupación con que últimamente se está considerando a los bugs en el software.

Creo que los 8 comentarios hasta el momento han sido muy interesantes y me han dejado pensando.


Trabajar en una fábrica de software da una visión muy diferente a la del consumidor del software. También ayuda a entender las variadas posiciones que diferentes personas toman frente a esta problemática.

Pero,


Leer el post de Brenner me ha dejado en realidad más dudas que respuestas. Pero sin duda que una cosa queda muy clara: se debe establecer una política de tolerancia mínima que tienda a cero.

Como se rescata de los comentarios, no podemos dejar cosas libradas a la eficacia del departamento de SQA, sino que, como digo siempre: hacer las cosas bien la primera vez, es mucho más barato.

Etiquetas: Problemas de Software, Programacion, Software