Valkertown Blog

RANT: Si MATLAB es supuestamente la mejor herramienta para analizar datos en ingenieria por que ese programa tiene tantos problemas para trabajar con archivos mixtos? Quizá fue un problema por parte del programador, pero este tiene suficiente experiencia con este programa como para decir que esta tarea es especialmente obscura. Definitivamente la capacidad de integración de MATLAB en un ambiente de producción/análisis conjunto es pobre y deja mucho que desear.

Para quienes quieran entender la idea del proyecto, es muy sencilla:

Toma de datos -> Almacenamiento y Categorización de datos -> Preprocesamiento -> Procesamiento y Análisis -> Almacenamiento y generación de reportes.

Esto resume un sistema general de trabajo, pero realmente matlab se ha quedado por fuera ya que se nego a participar rapidamente en el ciclo de forma que todo el proceso quedará completamente automatizado para poder generar reportes con muchos diferentes análisis.

Realmente me he convencido que Matlab podrá estar muy bien para estudiantes, pero cuando se trata de trabajo serio pongo en duda su útilidad, por lo que realmente pienso que nisiquiera los estudiantes deberian perder el tiempo con él.

Al final python no brillo por su velocidad en el análisis ni por su excelente uso de la memoria, pues con las cantidades de datos que se le alimentaron hicieron que varias fallas aparecieran. Sin embargo brillo por la facilidad con la que resumi casi tres meses de trabajo en matlab en 24 Horas de programación en Numeric de Python más todo el trabajo de automatización y trabajo con bases de datos. Por favor, una vez más escuchenme Open Source es simplemente mejor, no se dejen engañar por los botoncitos y los colorcitos!!!

EOR
EOT

Notas preliminares

WTFPL: Licencia divertida

Para apoyar mi Rant: I love CLI aquí esta la prueba:
Microsoft para su nuevo windows decidio añadir un shell que tiene un aspecto muy sofisticado y realmente me gusta la idea de poder contar con un shell en un futuro Windows, según lo que lei en el articulo parece ser un shell muy competente a ver si por fin Windows se vuelve un SO decente.

Otro apoyo más para el presente articulo queda este:
Barrapunto: Un paso más en el libre acceso a la información, esta clase de esfuerzos son los que deberian ser apoyados por todos.

Más links:
Kiko Calendario AJAX, es muy bonito y ayuda a organizar y tener la información en todo lado.

Artístico

Bueno siguiendo la tradición de publicar algunos de los trabajos de Sabbath, esta
esta pequeña animación de flash elaborada por 3ID3R y Sabbath:
NinaGotas

Continuación:Sobre GNU/Linux/BSD y Open Source

¿Por qué GNU/Linux/BSD?

Esta respuesta debe tener en cuenta la naturaleza de las personas, pues estos entornos son mucho más aptos para quienes desean conocer y aprovechar sus herramientas más allá del simple uso, es por esto que el valor de estos entornos va más allá que simples herramientas gratuitas.

El motivo por el cual en GNU/Linux/BSD he aprendido mucho más de lo que hubiese aprendido si siguiera usando Windows es el simple hecho de la disposición de la información; algunas veces esto mismo causa problemas a quienes recién llegan a estas plataformas desde Windows u otro SO y en general de un ambiente Cerrado.

A pesar de que Windows, como principal ejemplo, es muchas veces más conocido que GNU/Linux/BSD la información disponible y las herramientas para realizar actividades verdaderamente productivas son excluyentes entre sí.

Si es cierto que existen muchos IDEs(Integrated Design Enviroment) para cada propósito, estas son en sí excluyentes poco colaboradoras y quieren que sus usuarios se encierren en las funcionalidades que estas ofrecen, en sí la mayoría de los entornos cerrados pretenden eso, es su naturaleza.

Cada vez que me encuentro con un sistema de estos, soportando desarrollos complejos, veo un gran rompecabezas a medio armar con fichas que no encajan por que no pertenecen al gran propósito de la implementación. He de anotar que yo soy Ing. Electrónico y los sistemas que se desarrollan como tal no solo se tratan solo de firmware/software, el hardware, su diseño e interacción con firmware/software hacen parte del problema.
A diferencia del software el diseño de hardware no es posible realizarlo bajo el esquema de ensayo y error, los costos son muy altos para desperdiciar recursos de esa forma, es por esto que me interesa tanto un entorno de desarrollo globalmente integrado.

Modelo *nix

¿Cómo obtener un ambiente realmente integrado?. La respuesta viene desde el modelo *nix para hacer funcionar la herramienta que es el computador.
Este modelo se basa en la idea fundamental, Divide y vencerás, pues todos los *nix son una gran comunidad de pequeños programas, pequeñas herramientas que su único propósito de existencia es cumplir una única tarea de la forma más eficiente posible, y *nix se encarga de proveer los mecanismos para que estas pequeñas herramientas se comuniquen entre ellas.

Es así como se trabaja bajo *nix, se buscan, escogen y reunen todas las herramientas necesarias para realizar una tarea, al final igualmente se arma un rompecabezas, sin embargo el rompecabezas encaja, por que esta diseñado para hacerlo y existen los mecanismos para hacerlo.

Es por esto que es posible incluir e integrar todas las etapas de un diseño, p.e top-down, coherentemente y de forma que todas las herramientas que componen las etapas compartan información entre ellas y se generen mecanismos de verificación eficientes.

¿Por qué no?

Está bien, existen muchas razones por las cuales usted no deba usar estas plataformas y las que se me ocurren las voy a enumerar

1. Realiza labores artísticas Hay que admitirlo somos pobres en esta area
2. La pereza es su mayor motivación y perder el tiempo no le importa
3. Su trabajo no es importante así que, ¿Qué importa? , si lo pierde ante un virus/falla del sistema
4. Entiende computador por consola de vídeo-juegos

Si esperaban alguna motivación técnica, me alegro al informarles que aún no encuentro la primera.

Algunos aspectos más técnicos

Ya fuera del aspecto “filosófico” del asunto, existen unas ventajas técnicas algo particulares que he decidido tratar por separado.

En mi caso particular como Ing Electrónico y desarrollador de hardware/firmare principalmente las herramientas de naturaleza abierta presentan esta característica muy favorable para desempeñar esta labor. Esto dada la cantidad de tiempo que se ahorra en la producción y entrenamiento en N compiladores diferentes para cada procesador sobre el que se quiere trabajar, lidiando con nuevos bugs, metodologías e IDES diferentes.
Adicionalmente en esta clase de desarrollo es raro encontrar una plataforma de firmware o diseño de hardware que cumpla con todas las exigencias de un proyecto de mediana complejidad y ni hablar de uno de gran complejidad, esto y que no cueste cantidades prohibitivas de dinero.
Así esta alternativa siempre será la mejor por la capacidad de entrar en las entrañas del sistema para modificarlo y adaptarlo al proyecto en especifico.
Es así como en mi grupo de trabajo e investigación no solo hemos modificado el SO sobre el cual corren muchos de nuestros desarrollos, adicionalmente hemos modificado compiladores y programas de EDA(Electronic Design Automation) para acomodarlos a las necesidades de los proyectos y gustos particulares.

Al final todo esto se traduce en un equipo de desarrollo eficiente, capaz de producir prototipos en algunos días y proyectos terminados de gran calidad en algunos meses.

Debo aclarar que esto no es solo resultado de las herramientas, es resultado de un largo proceso de estudio y selección y lo que presento aquí son las conclusiones a las que hemos llegado después de dicho trabajo.

Eso es… por ahora, ¿Preguntas? ¿Comentarios?

Algunos temas que quisiera discutir luego:

• OpenDesktop, DBUS: Me gusta su filosofía y DBUS tiene capacidades excelente para la integración.
• Jabber: Quiero mostrar con código por qué Jabber es mucho más atractivo que cualquier otro IMS.
• Python/Perl/Lisp: De alguna forma estos lenguajes me impresionan más allá de lo que pueden hacer, la experiencia que se obtiene al aprender a realizar un par de códigos con ellos.
• Cli Magic: Sobre este tema, me gustaría mostrar un poco más algunas idea sobre como extender las capacidades de la Linea de Comando usual y acomodarla para un uso sofisticado y eficiente de ella, esto incluiría algunas ideas sobre key-bindings en algunos manejadores de ventanas y programas habituales.

EOT

herulor:Bien… ya que fui invitado a incluir ‘personal comments’… hate hate hate hate hate hate hate cada una de las cosas en la lista anterior. . Long live to talk

Más del rant. Odio mi ISP porque no me deja usar ni PINE ni MUTT para mi correo, así que tengo que usar Thunderbird y ya se quedó enano, el maldito se ha vuelto demasiado lento con la cantidad de RSSs y Listas de correos a las que estoy inscrito. Además, no hace nada que ya no supiera hacer en PINE o MUTT y en comparación con mail a la hora de escribir correos es tan lento…
La causa: Me bloquea el puerto 25 saliente y si quiero hacer relay en el server de ellos POP-before IMAP; sin embargo, hasta ahora todos los intentos de hacer esto con PINE o MUTT han sido una desgracia…
Me gusta thunderbird, me gusta la interfaz, pero me gustaba más cuando no tenía menos de 300MB de información en correos, ahora ya no :S. Lo que más odio es tener que esperar a que termine de arrancar para escribir un correo.

No hay nada como:

NOT-RANT:

Me gusta la idea del Avatar en los IM.

Me gusta el 1337 no porque sea (001, simplemente las letras y los símbolos son bonitos.

Un llamado a la conveniencia, no importa si usa Windows o lo que sea, siempre existirá un cliente para Jabber. Algunos clientes de jabber en win son bastante bonitos. Pandion y Gush los recuerdo, pero existen muchos más.

Me gusta usar más de un programa para todo, por ejemplo:
navegadores: firefox, opera, links, links -g, lynx, dillo, elinks.
editores: emacs, vim, ed, jed, pico, gedit…

BACK-TO-RANT:

Al final después de escribir esto, me doy cuenta del verdadero motivo del rant:

Conclusión:

Un llamado a la conveniencia, para muchos he tratado de mostrarles que existe un mundo verdaderamente más sencillo que el point and click y que se relaciona con la línea de comandos aka CLI, se llama: teclado

El teclado es el dispositivo de entrada más sofisticado que conozco, sólo hay que pensarlo un momento para darse cuenta, pero hay que pensarlo:

¿Cuántos clicks por minuto se pueden dar? ¿Qué tan complejas son las tareas que se realizan con un puntero?
Si bien es una buena herramienta para quienes realizan trabajos artísticos, no es un “mouse” la mejor opción elegida por ellos pues resulta demasiado inconveniente, para eso existen los apuntadores tipo lápiz.
Es mas, los ilustradores y diseñadores más hábiles que conozco no sólo utilizan el apuntador.

Ahora hay que preguntarse, ¿cuánto tiempo pierdo mientras suelto el teclado y agarro el apuntador? ¿Cuánto tiempo me demoro “navegando” por menús interminables que me hacen buscar la misma opción una y otra vez porque es terriblemente difícil recordar no sólo el nombre de lo que quiero encontrar, sino también su ubicación espacial?.

Luego viene otro de los problemas que he podido encontrar en las “dichosas” GUI que dicen simplificar las “tediosas” tareas de teclear comandos: resulta que estas [dichosas] GUI son excesivamente complicadas para una persona que no está acostumbrada a ellas; para la muestra un botón, sólo hay que ponerme a mí o a Herulor frente a una de estas GUIs para probar cuán ineptos somos al hacer uso de ellas. La información llega en paralelo, pero para m’i y creo que para la mayoría de personas -en esto me apoya Herulor- es imposible o sumamente improductivo distribuir la atención, y cuando se hace disminuye el rendimiento y aparecen los errores.

Al final, las GUIs y las imágenes no facilitan el trabajo, ese no es su propósito; lo que se logra con ellas es eliminar el aprendizaje permanente, lo que hacen es crear un sistema ineficiente de continuo re-aprendizaje de la misma tarea una y otra vez, así que lo que queda es “Que no se pierde tiempo memorizando una cantidad de comandos y combinaciones de teclas, sino que se puede perder tiempo una y otra vez”, da una falsa sensación de facilidad a cambio de la productividad, a cambio del tiempo.

Ahora algo sobre la CLI. Siempre se dice que resulta excesivamente complicado el uso de una línea de comandos, que gran mentira!!!, no existe una forma más simple de interactuar con un computador, ¿por qué? Porque es lenta, es lineal, ante cada comando existe una sola respuesta en múltiples lineas, pero sólo es una respuesta congelada en el tiempo, se puede retroceder a leerla con calma, la línea de comandos espera que se haya procesado la información antes de continuar, o en cualquier caso se puede obligar o hacer un log al respecto. El uso de la línea de comandos es una conversación con el computador.

Otro mito de la línea de comandos es que se tiene que memorizar cada uno de los comandos, que gran mentira!!!, cualquier usuario medio avanzado de CLI puede corroborarlo.
¿De dónde nace este mito? De Windows, de DOS, nunca ha tenido una línea de comandos decente ni sofisticada, es primitiva y gracias a esto da la impresión de que todas son así.
Un usuario avanzado de línea de comandos no recuerda, busca, pero no busca él personalmente para eso existen herramientas y mecanismos. Se trata del dispositivo de entrada y como éste se relaciona directamente con la línea de comandos, es cierto que las secuencias de teclas pueden llegara ser tan complejas como los menús (a la emacs, por eso la interfaz de VI y ED es superior); sin embargo, generalmente el número de teclas disponibles es suficiente para que la mayoría de los bindings queden como máximo en una secuencia o combinación de dos teclas.
Se llama complejidad 1, acceso directo a la función que se quiere. Cuando se mecaniza ni siquiera se piensa en lo que se hace; no se trata de interrumpir el flujo de ideas como sucede con un apuntador y un GUI. A pesar de ser más simple y que el flujo de información sea mucho menor que en imágenes, el teclado->CLI->texto se presenta de una forma mucho más continua y “natural”.

Los modos gráficos no son inútiles, pero para mí está sobrevalorado el aspecto gráfico sobre la funcionalidad.

EOT