OT: Sexo, drogas y biología

Hoy me veo obligado a salirme de la temática propia de este blog, debido a que ayer terminé de leer el libro Sexo, drogas y biología, de Diego Golombek. En los últimos años he leído varios libros de divulgación científica (principalmente de las colecciones Ciencia que ladra y Ciencia Joven) pero con este libro en particular además entender mejor algunas cosas y aprender otras, me maté de risa, la forma de escribir de Golombek es muy divertida y por momentos hace que uno no pueda dejar de leer. Simplemente ¡excelente!

Ping Pattern for Services

En los últimos meses he estado trabajando mucho con servicios WCF. Si bien en el ambiente de desarrollo no he encontrado mayores inconvenientes, si he encontrado algunos a la hora de desplegar los servicios en un ambiente de test/producción (win2003). Dichos inconvenientes se han debido principalmente a las diferencias existentes entre web server de Visual Studio y el IIS 6, existente en Windows 2003.

En más de una ocasión me encontré con servicios que en el ambiente de desarrollo se ejecutaban perfectamente y al desplegarlos en un ambiente de test no. En algunas ocasiones la diferencia estaba en cuestiones de configuración de WCF, mientras que en otras ocasiones en cuestiones relacionadas a la funcionalidad del servicio en sí.

Para poder distinguir rápidamente la causal del error, decidí agregar a cada servicio una operación "Ping" que simplemente, sin recibir parámetro alguno, devuelva la hora actual. De esta forma una vez desplegado el servicio, invocando a la operación Ping yo podía descartar cualquier problema relacionado a la configuración de WCF.

[OperationContract]
public string Ping()
{
    return DateTime.Now.ToString();
}

Después de haber aplicado esta receta en reiteradas ocasiones ya la he agregado a mi librito de prácticas útiles para el desarrollo de servicios.

 

Enjoy it!

Sobre la evolución de herramientas

Este es un post que tengo pendiente desde hace rato largo y está motivado por este link que me envió Nicolás Avellaneda http://codebetter.com/blogs/patricksmacchia/archive/2008/03/18/number-of-types-in-the-net-framework.aspx

Junto con el link, Nicolás preguntaba: "Mas tipos, métodos, interfaces, etc. ¿Nos brindan herramientas más simples?"

Esta pregunta me recuerda inevitablemente el excelente artículo de Fred Brooks, "No silver bullet", a la luz del cual podemos reformular la pregunta de Nicolás como: "¿ha logrado la plataforma .NET introducir un cambio en el orden de magnitud de la complejidad de la construcción del software?"

Definitivamente la respuesta a esto depende de contra que comparemos. Personalmente creo que si comparamos contra otras tecnologías actuales como Java, Ruby, Phyton y otras no tan recientes como VB6, Delphi, Smalltalk, no creo que que ni por asomo las cosas hayan cambiado en orden de magnitud, aunque sin duda muchas cosas se han simplificado.

Distinta puede que sea la cuestión si comparamos contra tecnologías más antiguas como COBOL y Pascal. De todas formas es preciso aclarar que mis opiniones están teñidas por el contexto en el cual trabajo: desarrollo de software de gestión.

Volviendo a la pregunta original ¿tenemos herramientas más simples? Creo que definitivamente si. Y en este sentido resulta interesante la estrategia planteada por Microsoft de querer unificar los distintos modelo de programación. Inicialmente con la aparición de la plataforma .NET y particularmente con ASP.NET Microsoft intentó unificar el modelo de programación Web y Windows, y podríamos decir que hasta cierto punto lo logró.
La reciente aparición de Silverligth también es un esfuerzo en ese sentido. No importa donde ni como vaya a correr la aplicación, no importa si es una interface web, smart cliente o RIA, no importa si es un web service o un componente remoto, no importa de si es lógica de negocio o de acceso a datos, la plataforma de desarrollo es siempre la misma: lenguaje C# e IDE Visual Studio. De esta forma se busca que un programador pueda hacer "todo" tipo de programación conociendo simplemente las herramientas mencionas C# y Visual Studio (al menos esta es la intención de Microsoft).

My 2 cent.

Nicoláz

Oferta de carreras de informática (parte 1)

Este post está motivado por varias consultas que me han llegado en los últimos años.

Si bien soy consciente que es un tema sobre el cual puede hablarse mucho, voy a intentar exponer en unas pocas líneas una visión lo más objetiva posible al respecto.

Si miramos la oferta de carreras universitarias de informática (y afines) existente en la actualidad en Argentina, en forma muy general nos encontraremos con 3 tipos de carreras:

1- Licenciaturas en computación

2- Licenciaturas en sistemas

3- Ingeniería en sistemas

Dentro (1) están aquellas carreras enfocadas en la investigación científica, con una fuerte base matemática y algorítmica. Posiblemente el exponente más claro de este grupo sea la licenciatura en computación de la Facultad de Ciencias Exactas y Naturales de la UBA. Carreras de este mismo tipo se dictan en las universidad de nacionales de Rosario, La Plata y del Sur.

Las carreras del grupo (2) suelen estar más enfocadas en los sistemas de información y si bien como parte del plan de estudio hay algunas materias de matemática, no son muchas, en comparación con las carreras del grupo (1). Al mismo tiempo estas carreras suelen tener materias como estructura e información de las organizaciones. Claramente el foco de la carrera es la implementación de sistemas de información. Un claro exponente de este grupo es la Licenciatura en Sistemas de la Facultad de Ingeniería de la UBA. Algunas otras universidades que dictan carreras de este tipo son la Universidad Nacional de Luján, la USAL y la UADE.

Finalmente las carreras del grupo 3 tienen una base matemática importante y también materias de información de las organizaciones. Pero adicionalmente tienen una base "científica" más amplia dada por las materias de física, química y electrónica. En la mayoría de los casos (o sea, en la mayoría de las casas de estudio) el foco de esta carrera es el mismo que el de la licenciatura en sistemas y la diferencia principal radica en que la ingeniería tiene unas 10 materias adicionales entre las que se encuentran las de física, química y electrónica. Claros exponentes de este grupo son la Ingeniería en informática de la UBA y la Ingeniería en sistemas de la UTN.

 

Es importante destacar que si bien la programación es una de las áreas comunes en las tres carreras, en ninguno de los tres casos es el foco de la carrera. O sea, si alguien quiere ser programador, bien puede seguir alguna de estas carreras, pero  debe ser consciente que  sería como usar un cañón para matar un mosquito, pues las tres carreras lo preparan a uno para cosas mucho más allá de la programación (ojo, con esto no quiero restar importancia a la programación).

 

Si miramos un poco más en detalle, nos encontraremos con carreras un poco más particulares como ser la Licenciatura en sistemas de información de la Facultad de Ciencias Económicas de la UBA, la cual está tiene un tinte mucho más contable-administrativo que informático.

También es común encontrarse con carreras de Analista de sistemas, que muchas veces suelen ser títulos intermedios de las 3 carreras analizadas.

Y si hablamos de carreras afines a la informática no podemos dejar de mencionar la ingeniería en electrónica, que si bien tiene un foco más cercano al hardware, en ciertas universidad tiene una carga de programación interesante.

 

Continuará…

Clase de AOP

El jueves pasado, el profesor Pablo Cosso me invitó a dar una clase sobre AOP en el contexto de su materia (Seminario 1, FIUBA). Durante la clase surgieron algunas preguntas interesantes por parte de los alumnos. El material utilizado en la clase está disponible aquí.

 

Espero les resulte útil.

Clase de Smalltalk

Como viene sucediendo desde hace un par de cuatrimestres en Algoritmos y programación 3 (fiuba), ayer di una clase introductoria de Smalltalk, creo que la gente entendió bastante, hubo algunas preguntas interesantes que me hicieron pensar esto. Todos los ejemplos fueron mostrados en Squeak.

El material utilizado está disponible aquí.

RAF 08

Durante los días 27 y 28 de este mes de mayo se llevó a cabo la cuarta edición del Foro Regional de Arquitectos, organizado por Microsoft Cono Sur. En en contexto de dicho me tocó ser orador de una se las sesiones junto a Fernando Das Naves.El slide deck utilizado en dicha sesión está disponible aquí. En breve también pondremos disponible los ejemplos de código mostrados.

Adicionalmente todos las sesiones fue grabadas y estarán disponibles en arquitectum.org.

No puedo dejar de agradecer al grupo de arquitectura de Microsoft Cono Sur por la invitación y felicitarlos por excelencia del evento.

Enjoy it!

Complementos Firefox

Estos son algunos complementos que me han resultado utiles.

  • PDF Download: PDF Download relieves the pain experienced when encountering PDF files
    on the Web. Whenever you click on a PDF file, PDF Download lets you
    know before trying to open it, and then offers you choices such as
    downloading, opening, or converting it straight to HTML
  • Video download helper: ayuda a bajar archivos de YouTube
  • DownThemAll: adminstrador de descargas
  • FireFTP: cliente de FTP

Enjoy it!

Regla ágil: La iteraciones terminan los viernes

Este post surge a partir de un hecho que me ocurrió en un proyecto que estoy participando en estos días. Resulta que al comienzo del proyecto en una reunión de coordinación con todos los involucrados (en el proyecto participan varias empresas de desarrollo), el gerente de proyecto propone cerrar las iteraciones los días lunes, para que en caso de haber un retraso, el equipo pueda recurperarlo trabajando el fin de semana, y llegar así a cumplir con la entrega el día lunes.

CHAN!CHAN!CHAN!

Desde el punto de vista de alguien esto puede sonar razonable, pero para un equipo ágil esto es inaceptable, pues se estaría violando la práctica «40 hour work week». Esta situación me ha hecho reflexionar y he concluido que para evitar que algún gerente de proyecto se tiente de hacer trabajar al equipo los fines de semana, es conveniente que las iteraciones terminen los viernes, de esa forma los viernes por la mañana se hace la reunión de revisión/demo con todos los involucrados. Por la tarde el team hace la reunión de retrospectiva y luego cada cual a su casa a disfrutar del fin de semana.