Planet

Symfony provee de un ingenioso sistema para enrutar todos nuestros enlaces. Es un simil (vagamente parecido) con el sistema de eventos.
En un fichero routing.yml se asigna a una dirección que que es un parámetro en el método link_to(@direccion, “Texto”) a una dirección que aparecerá al renderizar la página así como los parámetros que recibe y las acciones a realizar:
athletes:
url:   /:sf_culture/athlets/
param: { module: user, action: myUsers }
Para enlazar con un listado de atletas a los que tiene acceso el entrenador pondríamos link_to(@athletes, “Mis Atletas”) y esto lo haría sería poner en la barra de direcciones http://gesport/es/athlets y mostraría lo que se definiera en el método executeMyUsers de la clase user. En este caso lo que hace executeMyUser es una consulta a la base de datos preguntando quienes de los atletas tienen al usuario de la sesión como entrenador y los lista. En esta lista se muestran además de datos, enlaces a otros formularios donde se podrán introducr entrenamientos, datos médicos o consultar los anteriores.
Y bien, ¿Cual es el problema con el routing?. Pues por defecto Symfony toda cosa que llega estará definida por @default. Luego hay que definir el resto de rutas. Pero lo que no sabía yo era que : “EL ORDEN IMPORTA”. Así que ya sabéis dejad default al final del todo e intentar que no se solapen nombres de rutas.

Buenas. Tras mucho pensar como montar el sistema gráfico (sobre todo la gestión de las imagenes y de las escenas) ya lo tengo decidido. Lo montaré de la siguiente forma:
Para cada escena diferente que haya en la aplicación crearé un fichero xml en el cual pondré la ruta de la imagen a utilizar y la posición. Esto me será de gran utilidad por varios factores:leer más

Esta entrada es para agradecer a Jose Luis Ramos Muñoz los diseños de los sprites para mi proyecto y de paso dar a conocer a un gran artista que actualmente expone en el café Tierra, cerca de la facultad de informática y telecomunicación, bellas artes y del parque Almunia.
Os dejo un link a su espacio: http://jlmessiah.spaces.live.com/default.aspx?wa=wsignin1.0&sa=270142421
      

Después de usar durante cierto tiempo scp para enviar mi pagina web a la forja de RedIris, me encontré con el problema de no poder borrar los ficheros que ya había subido. Supuse que esto se debía a una limitación propia del comando scp y no del protocolo que usa. Por ello decidí probar la aplicación winSCP que nombran en la página de la forja (a veces para vencer al enemigo hay que estudiar las tácticas que este usa). Cual fue mi sorpresa cuando vi que desde dicha aplicación podía borrar, copiar, …
El siguiente paso fue indagar en la página de winSCP (http://winscp.net/eng/docs/requirements), en ella descubrí que para que el programa pudiera realizar todas estas operaciones, era necesario que el usuario tuviera una cuenta ssh en el sistema remoto y que además éste pudiera ejecutar los comandos: cd, chgrp, chmod, chown, echo, groups, ls, mkdir, mv, pwd, scp, rm y ln.
Dado que el protocolo scp (no el programa (el nombre de los dos coincide) ) funciona sobre ssh, pensé que quizás pudiera ejecutar los comandos anteriormente mencionados a través de ssh. Para probar esto ejecuté el siguiente comando:
$> ssh cusl3-libgann@forja.rediris.es "ls"
Después de introducir la clave, el programa devolvió:
bin
dev
etc
home
htdocs
lib
lib64
root
tmp
usr
var
Os invito a ejecutar el siguiente comando:
$> ssh cusl3-libgann@forja.rediris.es "ls bin"
¿Qué significa el resultado devuelto?
Pues bien si queremos borrar un fichero de nuestra carpeta web, bastaría usar el comando:
$> ssh cusl3-libgann@forja.rediris.es "rm htdocs/"
Si quisiéramos mover un fichero:
$> ssh cusl3-libgann@forja.rediris.es "mv "
Recomendaría solo modificar en contenido de la carpeta htdocs, ya que si eliminamos o modificamos algún otro fichero, quizás tengamos que ponernos en contacto con el administrador de la forja.
Un saludo y espero que os haya ayudado en algo. Por cierto, cundo tenga tiempo quiero hacer un script que facilite esta tarea.
      

Aqui os dejo el diseño.
Ahora estos dias tendré más tiempo e iré actualizando el blog con el trabajo que llevo hecho de dias hacia atrás.
Adrián
      

Echando un vistazo a la web Talking Android, he visto un vídeo en el que se muestra como se pueden  tratar varios touch events en el móvil G1. Tenía entendido que actualmente el único dispositivo que realmente conseguía tratar varias pulsaciones en una pantalla táctil era la pantalla del Iphone/Iphone Touch desarrollada por Apple, y [...]

pues eso mismo….

Ya estamos de vuelta de las estupendas pero cortas vacaciones de Navidad. Desearos a todos un Feliz año y espero que los Reyes Magos os trajeran muchas cosas.
He empezado la búsqueda del controlador CAN y aunque he visto algunas alternativas, os puedo adelantar que mi elección de momento es Microchip, concretamente el MCP2515 para controlador y el MCP2551 como transceiver. Estos dispositivos son bastante fáciles de conseguir, y el propio fabricante suministra “samples”, que por cierto ya los tengo de camino a casa. La información está bastante clara en el Datasheet, se controla usado SPI, mediante comandos relativamente sencillos. También existen algunas notas de aplicación y he encontrado algunos proyectos que los usan. Su precio ronda los 3€.
Como alternativa factible solo he encontrado el SJA1000 de NXP. Tiene un precio más elevado que el MCP2515 rondando los 6€. Su interfaz de comunicaciones (INTERFACE MANAGEMENT LOGIC) es un poco extraña, y el Datasheet lo veo escueto. Al menos de entrada no parece tan fácil de usar como su rival de Microchip.
Estoy un poco sorprendido, ya que no he encontrado de forma fácil ningún otro CAN-Controller. Esperaba una oferta mucho mayor y me atrevería a decir que en la mayoría de los casos, se integran en las gamas altas de los microcontroladores de cada fabricante. Esta última opción evidentemente es mucho más cara que la elegida, y más engorroso porque se tendrían que programar aparte.
Transceiver existen algunos más, pero eligiendo el MCP2515 que es de microchip, veo mucho más cómodo, y creo que evitaría muchos problemas si elijo el transceiver que Microchip recomienda y fabrica para este controlador, el MCP2551.
Usaré solo encapsulados PDIP, para que a todo el mundo le sea fácil la construcción de la PCB.
Podéis descargaros los Datasheet pinchando en los siguientes enlaces:

• MCP2515
• MCP2551

Por último me gustaría comentar que desde Diciembre estoy trabajando en Ingelabs, una empresa dedicada al Sector I+D. Esto ha reducido bastante mi tiempo, y con los exámenes de Febrero tan cerca, me estoy viendo un poco desbordado. El proyecto por supuesto continúa y de momento voy cumpliendo bastante bien la fechas, pero pido disculpas de antemano si no puedo hacer una entrada semanalmente como me había propuesto.
En la proxima entrada públicaré la primera versión del esquemático que colgaré en PDF

He detectado un fallo en la última versión, la 0.5. El fallo ocurre al descargar archivos. Voy a intentar arreglarlo y en cuanto lo haga saco una nueva versión.
      

Desde hoy está disponible una nueva versión de Unimail, la 0.5.
El único, pero muy importante, cambio, es la sustitución del uso del protocolo POP por el uso del protocolo IMAP. Esto hace que ahora las búsquedas sean muchísimo más rápidas. Por poner un ejemplo, con la cuenta de e-mail de uno de mis colaboradores, la cual tenía más de 3000 mensajes en su bandeja de entrada, la búsqueda tardaba unos 8 minutos, y ahora tarda unos 4 segundos. La mejora es evidente.