viernes, noviembre 23, 2007

Fotos soho

Pues por ahí vi un código en Java para bajar las fotos de Soho en 550 lineas de código. Si alguien lo quiere ver, está aquí. El código está horrendo (éste horrendo es una opinión personal)

Un amigo lo hizo en 54 usando Bash. Está aquí
Lo cual me hizo dar ganas de aprender sed.

Yo no me podía quedar atrás, entonces hice uno muy sencillo en Ruby.

El Link al código bonito en HTML usando el modulo de Steve Yegge.

Y el script está aquí

Voy a ver si en otro desparche lo hago en Haskell.
Lo mas charro de todo es que ni he visto las Fotos.

miércoles, noviembre 21, 2007

Algo mejor que Ruby

Por fin me encontré con algo mejor que Ruby para desarrollo Web!

Creo que ésto superará con creces la agilidad de esas herramientas nuevas :P

jueves, noviembre 15, 2007

Problema de Definiciones

Últimamente he tenido un par de problemitas con definiciones de Ingeniería de Software.

El primer problema surgió cuando estaba discutiendo sobre si Linux era o no usable. Yo sostenía que Linux era bastante usable, era claro de entender, simple y demás. "Fácil de usar" era mi definición pero luego la persona con la que estaba hablando empezó a asociar a usabilidad cosas como "intuitivo " y "fácil de aprender a usar".

Yo todavía me quedo con mi definición.

La otra y más traumática fue con la definición de Transparencia. Para mi transparencia tenía mucho que ver con lo que mencioné en otra entrada.

Para mi básicamente era simplicidad y ocultación. Mi definición incluía muchas cosas... para hacerme entender esta digamos RMI, RMI es un mecanismo de invocacion remota de objetos en Java. Esto permite que si ud tiene un objeto en una máquina pueda llamar métodos de este desde otra de manera Simple y Ocultando toda la complejidad de abajo (Sockets, Marshaling y otras cosas). Es decir RMI era para mi un método transparente de invocación remota de objetos.

Ahora bien, Leyendo "The Art of Unix Programming" Me di cuenta que existe una definición totalmente diferente. Para Eric Raymond Transparencia tiene que ver con la facilidad de entrar en el código, de ver su funcionamiento. El habla de "discoverability" algo así como "la habilidad de descubrir".

Eric Raymond menciona por ejemplo, como una opción --verbose que diga todo lo que hace un programa, hace de éste mas transparente.

Pensemos por ejemplo en un reloj... imaginémoslo ahora transparente. Todos los engranajes se ven y el funcionamiento es fácil de descubrir.

La pregunta que me surge es... ¿De donde salió la definición que tenía inicialmente?

jueves, noviembre 08, 2007

The Art of Unix Programming

Últimamente he estado leyendo "The Art of Unix Programming" de Eric Raymond y con ésto me he dado cuenta que soy muy cerebrilavable.

En éste libro uno no se encontrará con cantidades de código shell o C, sino mas bien con una buena explicación de la filosofía Unix; la historia de Unix; las lecciones aprendidas a través de la historia, remontándose a la PDP-7; EL lenguaje predecesor de C y otro montón de cosas.

El librito es bastante ameno de leer y creo que le vendría bien incluso a las personas que no son amantes de Unix. Por ejemplo, se pasa por propiedades deseables del software, con ejemplos claros desde el punto de vista de un programador. Es decir, estoy acostumbrado a escuchar imbéciles que no han echado una sola línea de programación hablando de Modularidad. Gente que solo es capaz de asociarla al paradigma OO y se enredan ellos solos con sus Patrones, Factorys, Mixins y demás pendejadas. Mientras este libro recorre las mismas temáticas de un curso de Ingeniería de Software solo que con un acercamiento que yo lamaría De Verdad.

Como por ejemplo: como se usa C como capa delgada de pega, como se aplica la modularidad a nivel de shared libraries en Linux o con casos de estúdio como el diseño el sistema de Plugins en Gimp.

Sería tan bacano una clase de Ingeniería de software así!


Mas que repetir lo que dice el libro (eso sería muy daña libros de mi parte). Dejaré éste link a la versión online.