Laboratorio de Inversión y Especulación 6 - Colaborar Programadores
La gente con mas conocimientos de programación, puede colaborar en todo tipo de tareas, proponer ideas para la arquitectura etc...
Unos comentarios de Juanmi que ya ha estado colaborando activamente en el proyecto:
Me gustaría fijar el camino a donde vamos para que tengamos que hacer la mínima rearquitectura al cambiar las dimensiones del problema y poder ir paralelizando el desarrollo. Por supuesto no vamos a hacer esto de golpe, sino que iremos aproximándonos pero sin cerrarnos puertas.
Creo que deberíamos hacer dos sistemas:
El primero no visual interno:
1º Sistema de cubo de información
a- El cubo se va rellenando con quotes
b- El Sistema actualiza las quotes automáticamente
c- Otros Cálculos derivados de las quotes
d- Se guardan en el cubo tb estos cálculos
e- Se automatizan tb estos cálculos
2º Dimensionamiento:
a- Clusterizamos el cubo de información
b- Paralelizamos para reparto en hilos y máquinas la actualización y el calculo
3º Optimización:
Creación de cubos diarios. Basicamente entorno de persistencia y ejecución distribuido (que solo necesitemos poner mas nodos para ampliarlo).
Arquitectura+servicio global de persistencia
Gestor de tareas y distribución de carga.
En resumen: un poco de arquitectura, un par de gestores.
Lo demás es crear los feeders de screenscraping, algoritmos de calculo y sistemas para importar y exportar datos.
Parte visual:
Entorno independiente de gestión que administre y use la información.
a- Ver datos, sacar gráficos con los datos.
b- Crear, eliminar y gestionar tareas automatizadas del sistema.(pudiendo configurar elementos de calculo, crear líneas de comando o crear cálculos con scripting).
c- Poder pintar directamente en los gráficos, poder aplicar cálculos directos locales sobre los datos en pantalla o aplicar los resultados de cálculos automatizados. Poder guardar vistas del gráfico con sus cálculos asociados.
Deberíamos tb crear un sitio donde estén los datos descargados para todo el mundo y que sea el prioritario de descarga, así se bombardea lo menos posible a las webs de datos. Si empiezan a tener demasiada carga automatizada de peticiones van a cambiar las cosas para cortar de raíz (ya he estado en casos similares en el otro bando).
Digase, colgar los históricos y las actualizaciones diarias (por ejemplo últimos 30 días y el resto a históricos).
La gente sincroniza contra ahí y luego si quiere algo mas se lo baja.
Poco a poco iremos haciendo el sistema maestro lo mas rico posible, lo normal seria que todo el mundo terminase sincronizando contra este principal y no fuese a buscar datos a ningún otro sitio. Siempre que sea posible deberíamos indicar en la aplicación la fuente de los datos, ya que en realidad son datos que hacen públicos y nos los prestan. A la hora de implementar algoritmos hay que identificar al autor y asegurarse que el algoritmo es libre.
Muy importante se necesitan ficheros de configuración en plan, para hacer el sistema mas fácil de usar, mas inteligente y para ir haciendo la copia de datos
principal:ticker-value-proveedor de datos
Creo que habría que crear un modelo de información para acciones, otro para futuros, otro para opciones y si acaso otro para bonos. Con todos los campos posibles, de tal manera que si están los datos se meten y sino pues nada...Normalmente es mejor que sobren campos a que falten. Los campos que no se llenen ahora quizás en un futuro cuando se encuentre la información si se llenen (Por ejemplo el de acciones prestadas). Los campos que sea información que se pueda sacar a través de un calculo de otros datos que tengamos no los metería (por lo menos por ahora).
Creo que Llinares nos podría dar esa información, a nosotros seguro que se nos pasarían campos.
Los temas de cluster y paralelizacion no son tan complicados. Metemos Sequoia para clusterizar y JPPF para GRID (si conocéis implementaciones que os parezcan mejores decírmelo). El tema es pensar que lo vamos a meter.
Para la persistencia usamos un motor de JDO (hibernate u otro) donde guardemos datos+metadada+nombre de forma independiente. Uno que automatice lo mas posible. A la hora de hacer persistencia simplemente tenemos que evitar al máximo la interdependencia de tablas (aquí hay que jugar un poco porque no es como le gusta a JDO).
En el tema de la bolsa y en sistemas grandes es mejor bajar la dependencia de datos. Por un lado tendremos los datos y por otro lado los cálculos basados en esos datos.
Cada uno guarda sus soluciones de forma independiente y solo hay que guardar la metadata de interdependencia.
Por ejemplo:
Se bajan las quotes de ibex y vía jdo se crea una tabla llamada ibex donde se guardan las quotes.
Se automatiza el calculo de media móvil para ibex a 30 días:
El algoritmo recupera su info anterior si quiere o tiene (datos de medias a 30 días de ibex realizados), recupera las quotes de ibex que le interesan, calcula el nuevo punto para el día y se guarda en jdo el nuevo valor. Por debajo lo que ocurriría es que se crease o reusase una "tabla" para ese estudio, algo así como MOV30_IBEX y los resultados de la media para ese día se guardarían en esa "tabla" (junto a los demás históricos).
Aparte cuando se crea esta tabla se añade la meta información de dependencia: que MOV30_IBEX tenia relación con ibex (La meta-info nos sirve para que los humanos asociemos la información).
De esta forma desde el entorno gráfico, si estamos en ibex podemos listar los estudios que se basan en el (Gracias a su meta-información) y decir que se pinten si queremos.
TB seria fácil hacer un motor de lo mismo hacia fichero. Pero finalmente creo que detrás habrá una base de datos y encima tendremos importadores y exportadores de info a formatos que nos interesen.
Es simplemente aprovechar un entorno de mucha lectura y calculo pero pocos cambio (casi todo inserciones), con casi nulas transacciones.
Mas adelante podemos meter sistemas de eventos para avisos o cálculos en cascada (por ejemplo que estén atentos a que 2 medias móviles se crucen o cosas así para que nos avisen).
Resumiendo:
1- Modelo de información abierto, dinámico pero independiente. Meta-Información para asociación humana.
2- Entorno de calculo y automatización por "tareas" escalable
3- Tareas de importación y exportación de datos (los feeders actuales y sus persistores).
4- Entorno visual que gestione y visualice esta información. Que permita crear nuevos cálculos, automatizarlos, graficarlos etc...
Si pasásemos de datos diarios a mensuales, minuto, ticker ...etc. Podríamos reutilizar todo esto, simplemente añadiríamos nuevas vistas al cubo, con info de quotes timeframe de minutos podríamos crear las vistas de timeframe de horas...etc.
En realidad lo que mas tiempo lleva es crear todos los feeders (importadores sobre todo), algoritmos de calculo y un entorno visual cómodo. Lo demás es un tema mas técnico que de muchas líneas de datos. Esto cumpliría con todo lo comentado en el mail anterior.
Además muchos usuarios podrían estar usando el grid en paralelo de forma bastante óptima (para esto ya abría que empezar a meter algo mas de arquitectura de gestión de usuarios).
Creo que si a esto luego le sumamos scripting y motor de reglas vamos muy bien.
NOTA: A partir de ahora este tipo de comentarios de tipo técnico irán en el foro de Sourceforge, en el próximo post explicare con detalle como puede colaborar la gente que no sabe programar.
Unos comentarios de Juanmi que ya ha estado colaborando activamente en el proyecto:
Me gustaría fijar el camino a donde vamos para que tengamos que hacer la mínima rearquitectura al cambiar las dimensiones del problema y poder ir paralelizando el desarrollo. Por supuesto no vamos a hacer esto de golpe, sino que iremos aproximándonos pero sin cerrarnos puertas.
Creo que deberíamos hacer dos sistemas:
El primero no visual interno:
1º Sistema de cubo de información
a- El cubo se va rellenando con quotes
b- El Sistema actualiza las quotes automáticamente
c- Otros Cálculos derivados de las quotes
d- Se guardan en el cubo tb estos cálculos
e- Se automatizan tb estos cálculos
2º Dimensionamiento:
a- Clusterizamos el cubo de información
b- Paralelizamos para reparto en hilos y máquinas la actualización y el calculo
3º Optimización:
Creación de cubos diarios. Basicamente entorno de persistencia y ejecución distribuido (que solo necesitemos poner mas nodos para ampliarlo).
Arquitectura+servicio global de persistencia
Gestor de tareas y distribución de carga.
En resumen: un poco de arquitectura, un par de gestores.
Lo demás es crear los feeders de screenscraping, algoritmos de calculo y sistemas para importar y exportar datos.
Parte visual:
Entorno independiente de gestión que administre y use la información.
a- Ver datos, sacar gráficos con los datos.
b- Crear, eliminar y gestionar tareas automatizadas del sistema.(pudiendo configurar elementos de calculo, crear líneas de comando o crear cálculos con scripting).
c- Poder pintar directamente en los gráficos, poder aplicar cálculos directos locales sobre los datos en pantalla o aplicar los resultados de cálculos automatizados. Poder guardar vistas del gráfico con sus cálculos asociados.
Deberíamos tb crear un sitio donde estén los datos descargados para todo el mundo y que sea el prioritario de descarga, así se bombardea lo menos posible a las webs de datos. Si empiezan a tener demasiada carga automatizada de peticiones van a cambiar las cosas para cortar de raíz (ya he estado en casos similares en el otro bando).
Digase, colgar los históricos y las actualizaciones diarias (por ejemplo últimos 30 días y el resto a históricos).
La gente sincroniza contra ahí y luego si quiere algo mas se lo baja.
Poco a poco iremos haciendo el sistema maestro lo mas rico posible, lo normal seria que todo el mundo terminase sincronizando contra este principal y no fuese a buscar datos a ningún otro sitio. Siempre que sea posible deberíamos indicar en la aplicación la fuente de los datos, ya que en realidad son datos que hacen públicos y nos los prestan. A la hora de implementar algoritmos hay que identificar al autor y asegurarse que el algoritmo es libre.
Muy importante se necesitan ficheros de configuración en plan, para hacer el sistema mas fácil de usar, mas inteligente y para ir haciendo la copia de datos
principal:ticker-value-proveedor de datos
Creo que habría que crear un modelo de información para acciones, otro para futuros, otro para opciones y si acaso otro para bonos. Con todos los campos posibles, de tal manera que si están los datos se meten y sino pues nada...Normalmente es mejor que sobren campos a que falten. Los campos que no se llenen ahora quizás en un futuro cuando se encuentre la información si se llenen (Por ejemplo el de acciones prestadas). Los campos que sea información que se pueda sacar a través de un calculo de otros datos que tengamos no los metería (por lo menos por ahora).
Creo que Llinares nos podría dar esa información, a nosotros seguro que se nos pasarían campos.
Los temas de cluster y paralelizacion no son tan complicados. Metemos Sequoia para clusterizar y JPPF para GRID (si conocéis implementaciones que os parezcan mejores decírmelo). El tema es pensar que lo vamos a meter.
Para la persistencia usamos un motor de JDO (hibernate u otro) donde guardemos datos+metadada+nombre de forma independiente. Uno que automatice lo mas posible. A la hora de hacer persistencia simplemente tenemos que evitar al máximo la interdependencia de tablas (aquí hay que jugar un poco porque no es como le gusta a JDO).
En el tema de la bolsa y en sistemas grandes es mejor bajar la dependencia de datos. Por un lado tendremos los datos y por otro lado los cálculos basados en esos datos.
Cada uno guarda sus soluciones de forma independiente y solo hay que guardar la metadata de interdependencia.
Por ejemplo:
Se bajan las quotes de ibex y vía jdo se crea una tabla llamada ibex donde se guardan las quotes.
Se automatiza el calculo de media móvil para ibex a 30 días:
El algoritmo recupera su info anterior si quiere o tiene (datos de medias a 30 días de ibex realizados), recupera las quotes de ibex que le interesan, calcula el nuevo punto para el día y se guarda en jdo el nuevo valor. Por debajo lo que ocurriría es que se crease o reusase una "tabla" para ese estudio, algo así como MOV30_IBEX y los resultados de la media para ese día se guardarían en esa "tabla" (junto a los demás históricos).
Aparte cuando se crea esta tabla se añade la meta información de dependencia: que MOV30_IBEX tenia relación con ibex (La meta-info nos sirve para que los humanos asociemos la información).
De esta forma desde el entorno gráfico, si estamos en ibex podemos listar los estudios que se basan en el (Gracias a su meta-información) y decir que se pinten si queremos.
TB seria fácil hacer un motor de lo mismo hacia fichero. Pero finalmente creo que detrás habrá una base de datos y encima tendremos importadores y exportadores de info a formatos que nos interesen.
Es simplemente aprovechar un entorno de mucha lectura y calculo pero pocos cambio (casi todo inserciones), con casi nulas transacciones.
Mas adelante podemos meter sistemas de eventos para avisos o cálculos en cascada (por ejemplo que estén atentos a que 2 medias móviles se crucen o cosas así para que nos avisen).
Resumiendo:
1- Modelo de información abierto, dinámico pero independiente. Meta-Información para asociación humana.
2- Entorno de calculo y automatización por "tareas" escalable
3- Tareas de importación y exportación de datos (los feeders actuales y sus persistores).
4- Entorno visual que gestione y visualice esta información. Que permita crear nuevos cálculos, automatizarlos, graficarlos etc...
Si pasásemos de datos diarios a mensuales, minuto, ticker ...etc. Podríamos reutilizar todo esto, simplemente añadiríamos nuevas vistas al cubo, con info de quotes timeframe de minutos podríamos crear las vistas de timeframe de horas...etc.
En realidad lo que mas tiempo lleva es crear todos los feeders (importadores sobre todo), algoritmos de calculo y un entorno visual cómodo. Lo demás es un tema mas técnico que de muchas líneas de datos. Esto cumpliría con todo lo comentado en el mail anterior.
Además muchos usuarios podrían estar usando el grid en paralelo de forma bastante óptima (para esto ya abría que empezar a meter algo mas de arquitectura de gestión de usuarios).
Creo que si a esto luego le sumamos scripting y motor de reglas vamos muy bien.
NOTA: A partir de ahora este tipo de comentarios de tipo técnico irán en el foro de Sourceforge, en el próximo post explicare con detalle como puede colaborar la gente que no sabe programar.
Etiquetas: colaborar programadores, laboratorio
Publicado por Dalamar a las 13:15
Enlace Permanente
Dani... te estás sobrando.
Quizá antes que hacer cosas tan grandes, primero esperaría que el modelo de datos y la arquitectura esté hecha. Solamente eso.
Nos vemos en el sourceforge.
El autor ha eliminado esta entrada.
Mister, son las ideas de Juanmi, me ha parecido bien ponerlas porque se lo esta currando mucho y son muy buenas ideas, pero si que es verdad que son demasiado avanzadas.
Es mejor tener algo funcionando y despues planificar el resto, pero Juanmi ha escrito y mudificado mucho codigo tambien.
Yo de momento me estoy centrando en el interfaz grafico que es algo que la gente va a querer para usarlo, sino la mayoria de la gente no lo va a mirar, despues ya me enfocare en lo siguiente.
Tambien es importante tener los feeders, para poder dar el siguiente paso, que seria algo mas practico, como calcular pautas.
El curro es hacer los importadores de datos (screen scrapping) y los calculos que tengamos que meter al sistema o la capa visual. Para el cubo simplemente voy a montar un pequeño gestor de espacios independientes encima de jdo(jpox, ya he ehcho los test para tener solucionados los detalles) e ir metiendo un control de metainformacion de los mismos para ayudar luego a la capa visual (no es tanto curro, es un pequeño entorno de informacion y un par de trucos). Para que sea distribuido el espacio de informacion es cuestion de poner sequoia por detras. Y para automatizar el calculo (grid), simplemente en el gestor de tareas embebemos las tareas para JPPF (sio acaso tb podemos hacer que se marquen como locales o en el caso de necesitar datos de disco locales hacer un proxy a disco para el grid). Digase, con simplemente meter en la arquitectura una dependencia a estos frameworks solucionado. La arquitectura, salvo la parte de metainformacion, es independiente del modelo de datos, incluso independiente de lo que vaya a hacer (en vez de bolsa se podria montar otra cosa encima). El tema es tan sencillo como meter encima de esta base nuestros calculos y nuestro modelo de datos. Simplemente es una buena base para crecer el sistema encima.
alguna duda???
Esto puedes ser interesante para el tema de las URLs:
Antlr - this parser generator can look daunting, but it's pretty easy once you get your head around it. Can be used to parse things like complex URLs where regexps are not up to the job.
Este podria ser util:
Janino - someone took the time to write an embeddable Java compiler! It lets you use Java like a scripting language, eg. allow your users to type Java expressions directly into your GUIs.
Sin duda para lestadisticas:
Commons Math - everything from linear algebra to statistics
Por cierto ya estamos 7 apuntados en Sourceforge! alguien mas?
Hay un wiki, un foro y falta la lista de distribucion!
Igual ya los conoceis, pero por si acaso os pueden servir de referencia y ayuda:
http://code.google.com/p/truetrade/
http://code.google.com/p/jsystemtrader/
http://ta-lib.org/
Saludos y ánimo.