La segunda dificultad es Java. Matlab7 enlaza con Java 1.4 y lo trae dentro de su directorio. Primero instalamos java desde java.com y después vamos a c:\program files\java y copiamos el directorio jre que haya ahi dentro (por ejemplo: jre6) al directorio de java dentro de matlab, usualmente c:\MATLAB7\sys\java\jre\win32 (debe quedar junto a otro jre1.4.2). Luego abrimos el archivo jre.cfg que sólo contiene 1.4.2, lo reemplazamos por el número de versión de la jre que estamos instalando (por ejemplo: 6) y guardamos.

Ahora debe ser posible ejecutar Matlab7 sin mayores problemas. ¡Suerte!

English details after the jump, at the bottom (link below), comment if you want the full translated article.

Resulta que MetaPost es un lenguaje bastante útil para hacer figuras, pero debe compilarse por separado y enlazar el archivo resultante en el archivo Latex, lo que puede llevar a errores en la sincronización. Aquí incluyo un método CON EJEMPLO FUNCIONANDO para escribir MetaPost embebido en Latex y compilarlo en un solo paso con TexnicCenter.

Usaremos un paquete llamado EMP (Encapsulated MetaPost) para generar y compilar automáticamente el código MetaPost. Esto significa que también podemos tener los diagramas en archivos MetaPost separados que podremos incluir desde Latex con \input{archivo} y se compilarán de forma automática, si cumplimos con lo que se detalla a continuación.

Recomiendo leer las instrucciones mirando el archivo de ejemplo de mi autoría :). Primero incluiremos el paquete EMP, luego abrimos un bloque empfile donde irá cualquier cosa que hagamos con EMP.

Dentro de este bloque abrimos un bloque emp, el que creará una figura en la posición actual del documento. En el bloque emp podemos poner el programa MetaPost sin modificar.

Existen más formas de usar EMP, las que están MUY BREVEMENTE detalladas en su manual. Pero claro, el manual existente en CTAN que es el apuntado por la mayoría de las páginas que lo mencionan está.. ¡¡CORTADO A LA MITAD DEL PRIMER CODIGO EJEMPLO!! lo que no es de mucha utilidad.

Un manual completo puede encontrarse en CiteseerX (download es gratis, está a la derecha) o directamente en el mirror de la UTFSM (que también aloja la otra versión cortada como empman.pdf).

Adicionalmente hay una forma de configurar TexnicCenter para que haga todos los pasos necesarios para compilar y obtener un PDF a partir de estas fuentes. Esto está detallado en un mensaje a lista de correo "por ahí", con solo una respuesta indicando cómo respetar las reglas de formato para la lista de correo. Uf.

Moraleja: cuando alguien pregunta algo en un foro/lista de correo ud o responde o da un link. NO ENVIE A GOOGLE, QUE DE AHI VENDRA MUCHA GENTE.

Entonces, para configurar TexnicCenter:

1. En el menú Build escoger Define Output Profiles. Agregar (botón Add, abajo) un nuevo perfil llamado LaTeX => MP => DVI => PDF
2. Seleccionar este nuevo perfil y rellenar los datos siguientes en el tab Latex
1. Marcar la casilla Run Latex in this profile
2. En Path to Latex indicar la ubicación de latex.exe, en mi caso C:\Program Files (x86)\MiKTeX 2.7\miktex\bin\latex.exe
3. En Command line arguments poner --src -interaction=nonstopmode "%Wm"
3. En el tab Postprocessor crearemos 3 postprocesadores (con el botón ubicado sobre el listado vacío)
1. MetaPost
1. Executable mp.exe, en mi caso C:\Program Files (x86)\MiKTeX 2.7\miktex\bin\mp.exe
2. Arguments %Bm.mp
2. LaTeX to DVI
1. Executable latex.exe, en mi caso C:\Program Files (x86)\MiKTeX 2.7\miktex\bin\latex.exe
2. Arguments --src -interaction=nonstopmode "%Wm"
3. DVI to PDF (opcional, convierte el DVI a PDF, también intercambiable por DVI to PS)
1. Executable dvitopdfm.exe, en mi caso C:\Program Files (x86)\MiKTeX 2.7\miktex\bin\dvipdfm.exe
2. Arguments %Bm.dvi

Hecho esto dar a OK y escoger el nuevo perfil en el listado arriba de la interfase del editor. Puede probarse con el archivo de ejemplo . Podremos compilar como siempre.

También puede agregarse en el diálogo el visor para este perfil, para asi poder apretar el botón de view output y ver el documento. En el perfil creado sólo basta con copiar en el tab Viewer lo mismo que haya en otro perfil que termine en PDF.

ENGLISH

Here you can find the full Encapsulated MetaPost (EMP) manual, here is the mailing list archive post detailing how to get TexnicCenter to compile in one step. I only had to add a PDF postprocessor (look at the steps above, you should be able to figure it out) and a PDF viewer (which I copied from another PDF profile). Here is a small example file using Encapsulated MetaPost which actually works right out of the box.

If this helped you or you need more, please let me know either way by commenting. Current antispam answer is santiago, which you would have figured out if you could read spanish :P

UPDATE

Eliminate postprocessor 3 and in postprocessor 2 put pdflatex.exe instead of latex.exe. Now follow instructions from Guy Wiener: How to embed UML in Latex and you've got MetaUML working embedded in Latex, which is what I was after from the start. Yay!

Como todo buen programador tengo mis reservas al respecto, pero puedo hablar con algo de autoridad al haber utilizado durante un tiempo algunos sistemillas gráficos para creación de videojuegos y al compararlo con mi experiencia con UML, ER y otros diagramas.

De forma breve y concisa algunos puntos que se plantearon y luego mi pensamiento al respecto:

• El lenguaje de modelado nunca cubrirá todas las posibilidades, por lo que siempre se contará con una herramienta útil para obtener programas que ya no necesitamos.
• Nuestros queridos C y C++ también son lenguajes de modelado. Sólo el ensamblador le habla directamente a la máquina. Ya tenemos lenguajes de modelado, sólo son basados en texto. Un lenguaje gráfico no es menos lenguaje por ser gráfico. Por otro lado si el diseño del lenguaje fuera obviamente limitado (no turing completo) siempre puede tomarse el camino de la extensibilidad. De todas formas el software tiende a ser muy similar.
• Es gráfico asi que no es un lenguaje de verdad
• Al aprender a programar lo hacemos con diagramas de flujo. Estos diagramas son capaces de representar cualquier algoritmo. Siempre existe alguna forma gráfica de representar las mismas ideas. Esto asumiendo que quisiéramos representar las mismas ideas, ya que no me cabe duda de que se han introducido construcciones en los lenguajes específicamente dirigidas a paliar problemas producidos por la naturaleza textual de los lenguajes actuales (namespaces, por ejemplo).
• El modelo gráfico de un sistema real sería gigante y tan complejo que complicaría mas de lo que aportaría (cubriría todas las paredes de la sala, dijo un profesor).
• El código completo de un sistema real abarcaría varias cuadras si lo imprimimos en papel. Pero no lo hacemos por que el código nunca se mira como una sola pieza. ¿Por qué habría de ser distinto en un diagrama? Un buen lenguaje permitirá separar el modelo en secciones y una buena herramienta permitirá tener las referencias a mano, de la misma forma en que los entornos modernos de desarrollo tienen completación de código y buscadores de objetos y funciones que abren el archivo adecuado dentro de todos los que conforman el sistema.
• Visualizar cambios entre versiones sería complejo.
• El versionado se hace con herramientas que procesan texto. Se necesitará una herramienta que procese el diagrama y lo pueda mostrar de forma adecuada, pero los conceptos básicos del control de versiones no cambian. Si el versionado se realizara sobre el código generado, claro, sería muy difícil entender.
• El producto resultante sería lento.
• Los primeros compiladores de C generaban ensamblador, el que a su vez era transformado a código ejecutable por otro compilador. No hay ninguna diferencia aquí, el compilador de modelos genera código intermediato que debe compilarse. En mi opinión esto debería evolucionar para eliminar la necesidad de un lenguaje intermediato, claro, de forma que el modelo sea realmente el software y no una abstracción del lenguaje intermediato.
• No hay herramientas y ya ha pasado bastante tiempo planteándose esta idea, ¿será que no se puede?
• Los compiladores de C++ tardaron largos años antes de poder compilar templates de la forma en que el standard especificaba. El lenguaje C tardó años antes de ser aceptado como un standard internacional. Estas cosas toman tiempo, mas aún cuando no hay concenso sobre cómo debe enfrentarse un problema (para un ejemplo ver SQL).

A fin de cuentas la impresión que me llevo es que parece una buena idea pero SOLO si se elimina el lenguaje intermediato de forma que el modelo siempre sea consistente con el resultado y no se esté persiguiendo representar otro lenguaje de forma gráfica (lo que haría el lenguaje gráfico superfluo). Un set reducido pero turing-completo de primitivas gráficas podría perfectamente convertirse en el lenguaje de preferencia.

El programador no desaparece, sólo deja de preocuparse de menudencias. En su tiempo todo programador debía manejar los registros de la CPU, hoy sólo quienes programan Kernels, drivers o plataformas embebidas lo hacen. En el futuro quizás recordemos con orgullo que debíamos administrar memoria manualmente (o tal vez no, hasta hoy la teoría y práctica de recolección de basura no ha dado los resultados prometidos).

Como puede verse mi postura no es 100% a favor pero no me parece algo utópico sino un posible camino de evolución. Ya veremos que dice el tiempo y el mercado.

Durante la investigación me he encontrado con muchas quejas de seguridad sobre bibliotecas populares que realmente no son problemas de seguridad.

Aquí veremos algunos de estos conceptos de lo que implica la seguridad de una aplicación web que (en mi opinión) están equivocados.

1. Passwords o datos sensibles en plaintext en la sesión: Las variables de sesión (PHP) se guardan en el servidor, no en el cliente. Por lo tanto no hay forma de que el cliente obtenga estos sensibles datos A MENOS que el mismo desarrollador obtenga estos datos del servidor y se los entregue al cliente. El problema de seguridad no está en la existencia de las variables, sino en la acción del desarrollador que usa un print_r o var_dump en una variable sensible.
   

2. Conexión global a la base de datos: Las abstracciones de bases de datos no existen para aislar el servidor, sirven para FACILITAR el acceso. Cualquier código que conecte a una base de datos tendrá en su código o en memoria los datos requeridos para la conexión. Si realmente un atacante buscara obtener estos datos y ya tuviera código ejecutando dentro del sistema, obtenerlos es trivial. En el peor caso podría monitorear el intercambio de información entre aplicación y base de datos o podría crear un dump de la memoria. En un lenguaje de scripting basta con imprimir el código fuente de los archivos. El problema real es EL CODIGO ARBITRARIO EN EL SISTEMA.
3. Otorgar acceso a todo el código fuente dentro de un grupo de desarrolladores: Una vez que un desarrollador puede escribir código arbitrario en cualquier módulo la seguridad ya está comprometida. Más útil es escoger con cuidado a los desarrolladores, establecer reglas de uso y aplicarlas mediante control de versiones, a menos que el código "prohibido" esté prohibido para evitar el robo de el mismo.

Son punto por punto iguales. La balanza se estaba inclinando por Zend sólo por su simple instalación (descomprimir e incluir, a diferencia de los impredecibles y crípticos scripts instaladores de PEAR. ¿Por qué no distribuyen un zip?) pero hice un descubrimiento. Existe una fundamental diferencia de filosofías entre Zend Db y PEAR::MDB2 que tiene una repercusión muy concreta en la API.

Usaré PEAR. La razón después del salto.

Zend pareciera apuntar a hacer consultas fáciles y seguras sin problemas de sintaxis. MDB2 intenta normalizar el uso de bases de datos.

Esta diferencia repercute en las características no implementadas en todos los RDBMS.

Por ejemplo: MySQL no implementa secuencias (...yep). Si uno está obligado a usar MySQL (y será el caso en la mayoría de los hosting baratos o gratis) en Zend no puedes usar secuencias pero si autoincremento.

Claro que no todas las bases de datos implementan autoincremento. Luego,tenemos que programar soporte para ambas si lo que necesitamos es controlar la secuencia de inserción. Un cacho.

MDB2 en cambio provee una capa de emulación de ambos secuencias y autoincremento (algo que Zend en su bug tracker proclama IMPOSIBLE) de forma que uno no deba preocuparse de si lo implementa o no, sino simplemente si la API de MDB2 lo ofrece. Se programa una vez, funciona siempre.

En la práctica la secuencia en MySQL consiste de una simple tabla y una consulta creadas de forma que los IDs obtenidos sean siempre únicos por consulta. Esto es literalmente una secuencia.

Supongo que tendré que encontrar formas cómodas de instalar PEAR, a ver si hay alguna.

Podemos esperar esta joyita para mitad del presente año, junto con quizás opciones de otros fabricantes.

Consultas e información en:

Facebook

Página del taller en CAINF

Aquí mismo en los comentarios :P

Wiimotion+ es un agregado que inicialmente se venderá con Wii Sports Resort (un juego comparable a Wii Sports o Wii Fit en simplicidad) que se enchufa al Wiimote como tantos otros.

¿Que contiene? es la gran pregunta. La respuesta después del salto.

Un osciloscopio.

Así, sin anestesia.

Anteriormente la función de osciloscopio se obtenía mediante el uso de los acelerómetros (en 3 ejes) y asumiendo una aceleración de gravedad standard (9.8 m/s^2), pero esto interfiere con la medición de aceleraciones por parte del usuario. Ahora con un osciloscopio dedicado la aceleración de gravedad puede restarse de la medición, obteniendo así una medida muy precisa de la aceleración y permitiendo la integración para calcular posición.

El juego incluido demuestra esto con el juego del frisbee, el que refleja la posición de nuestra mano y no oscila locamente como en el juego de golf de Wii Sports. También es notable un duelo de espadas incluido, que tiene a todos soñando con Star Wars (Lucasarts: ¡aún es tiempo de usar este aditamento en Force Unleashed!)

¿Por qué menciono este aditamento aquí con tanto detalle?

Pues porque el osciloscopio no se incluyó en el diseño original por su tamaño. El incluido en este aditamento está fabricado con una tecnología que no estaba disponible (al menos no para un giroscopio, al parecer) en el periodo de diseño de la consola: fabricación MEMS.

MEMS (Micro-Electro-Mechanical Systems) permite fabricar dispositivos mecánicos a una escala antes sólo permitida para componentes eléctricos que se fabricaban por deposición de silicio.

¿Qué tan chicos? Wikipedia dice: así de chicos. Ojo, el bicho de la foto es un ácaro (si, los invisibles) y la foto es tomada por microscopio electrónico, ya que uno óptico no es suficiente. Los componentes pueden medir desde 1 micrómetro hasta 100.

Nanotecnología (ok, Microtecnología), pronto en grandes tiendas y a bajo precio.