Una idea que estoy rondando

Bueno pues eso, hace tiempo que estoy rondando la idea de hacer un programa que nos permita el tener almacenada toda la información de nuestras motos, cosas como cuando se hanhecho los cambios de aceite, lugar , coste, cambios de ruedas, averias, ...

No se os parece y que cosas pensais que tendriamos que tener en cuenta.

Espero vuestros comentarios para ver si merece la pena que le dedique tiempo o no.

(como soy informático, es la única forma que veo de poder aportar yo un granito de arena a este gran foro que tenemos)

Hola Asoblech!!!

de aprendiz de informático a informático: una base de datos de access sería lo más rápido. Pero si quieres se podría llegar a plantar hacerse sobre Oracle, pero eso son palabras mayores para mí.

¿Cómo lo ves tú?

Un saludo

Dejaros de mariconadas y empezad a hacer un programa como dios manda para poder cambiar el mapeado de nuestras centralitas leches!

jajajajajajajaja
Es broma, me parece perfecta la idea, ya que yo por ejemplo tengo muy mala memoria para estas cosas hehehe.
Saludos!

Lo de Oracle, me parece que no es muy correcto ya que son necesarias licencias, servidores, ... Lo que tenia pensado era una BD en Access controlada con un programa en PowerBuilder que es el lenguaje de programación que más controlo.

Con respecto a lo de la centralita, he estado investigando por internet y no he encontrado nada, ni como conectarla a un ordenador, pero no lo descarto, supongo que con el tiempo y alguna filtración encontraremos algo

Jajajajaja
Joder que recuerdos con el powerbuilder Que gozada era parametrizar las datawindows....
Hice con eso mi proyecto de carrera. Al año estuve haciendo la aplicación de gestión de Socios del Club megatrix de Antena 3.
Entre medias una aplicación pirata.....digamos para sacarme unos duros extra, que cuando empiezas cobaras muy poco.
El tema del oracle...es una chulada, hay instaladores para bases de datos no clusterizadas, o el Oracle Express, pero no es lo mejor para gente que no sabe de trastear.
Lo mas sencillo.... un SQL lite, no ocupa ni nada, pues para la volumetria que se usaría es lo recomendable.
La otra opción es Access mas generico y visual para alguien que no sabe y tiene que toquetear la base de datos.
Yo ahroa estoy fuera de la parte de programación, pues me dedico al analisis y esas cosas......
Per si necesitais ideas.... aqui estoy.

Este tipo de aplicaciones para que funcione de lujo, requiere que el usuario sea muy constante en la introducción de datos, como por ejemplo cada repostaje, dado que de esta manera te avisaría (bajo alarmas parametrizadas como cambio de aceite, ruedas, pastillas, liquido anticongelante, cadena, kit de distribución) que tienes que hacerle a la moto.
He de deciros que la manera de llevar a cabo el desarrollo correctamente, lo mejor es ver hasta donde se quiere alcanzar, e ir atacando por partes, pues de lo contrario acabaríaís locos.
Es mi consejo.

Tiralo para alante, todo lo que sea apotaciones para el cuidado de nuestra territa resulta interesantisimo.

Hola a todos!!!

En mi caso particular de análisis no tengo ni idea. De lo poco que toco son las BBDD en Access y Oracle. En Oracle me he limitado a hacer tan sólo inserts, deletes y/o updates. En Access me he atrevido con algo de Visual Basic.

Lo primero que deberíamos hacer, desde mi punto de vista, es indicar qué conceptos consideramos relevantes, para ponerlos como campos, como por ejemplo fecha de lo que sea, como fecha de repostaje, fecha de cambio de aceite, etc., y también pues para esa fecha qué kilómetros tiene la moto... Esto es tan sólo una idea.

Un saludo

Joer que me ha jodido todo el rollo que os tenia preparado

Bueno bueno.
Me he puesto a hacerlo en Woed primero para que no se joda lo que iba a escribir.
En principio lo que se me ocurre es que la aplicación puede tener las siguientes partes:

Combustible
Esta es la parte más básica de la aplicación y la más usada. Se almacenará la fecha, los km del cuenta km (no el parcial si no los totales) cantidad echada y coste de lo echado (el precio litro lo podemos sacar por la división) y pongamos que el tipo de combustible. A la hora de guardar el registro, sacará la cantidad de KM recorridos desde el ultimo repostaje.
En este aspecto es importante poder editar los repostajes.
A la hora de guardar un repostaje, se revisarán la alarmas-avisos referentes a KM.
Como dato interesante, es importante saber si el repostaje va a asociado a algún evento. Por ejemplo Pingüinos. De esta manera podremos controlar el coste asociados a eventos.

En definitiva para cada registro de Mantenimiento-Compras deberemos guardar:
*Fecha del Respostaje
*Km de la moto
*Km desde el último repostaje (automático)
*Descripción Corta
*Descripción Larga
*Cantidad
*Descripción de la misma. (Por si queremos guardar mas información del repostaje)
*Evento (por defecto es General a no ser que se introduzca un evento asociado)


Alarmas-Avisos
A la hora cuidar la moto… no está de más que algo nos diga que se acerca el momento de meter mano a la moto.
En este caso se definirían dos tipos de alarmas.
Distancia
Se definirán avisos en función de la distancia pendiente. En este caso se almacenaría a que km deberá saltar la alarma, un texto para poder indicar qué es la alarma, y si queremos que nos preavise, por ejemplo 500 km antes. Estas alarmas se revisarán cada vez que se produzca un repostaje
Fecha
Se definirán avisos en función de la Fecha. En este caso se almacenaría cuando deberá saltar la alarma, un texto para poder indicar qué es la alarma, y si queremos que nos preavise, por ejemplo 500 km antes. Estas alarmas aparecerán cuando se inicie el aplicativo.
Evento:
Esto no está asociado al mantenimiento, y sí digamos como una agenda de eventos (ya puestos el cambio es bajo) en el que el usuario podrá de alta eventos como concentraciones, quedadas, compras conjuntas…

Por supuesto, se debe poder editar las alarmas, Teniendo disponible un campo de que indique, activa, inactiva o caducada.

En definitiva para cada registro de Mantenimiento-Compras deberemos guardar:
*Fecha de alta de la alarma
*Fecha de activación de alarma(si es una alarma de Fecha)
*Días en que se debe preavisar la alarma
*KM de activación de alarma (si es una alarma de KM)
*Km en los que se debe preavisar de la alarma
*Descripción de la misma. (Por si queremos guardar mas información del repostaje)
*Evento (por defecto es General a no ser que se introduzca un evento asociado)


Mantenimientos – Compras
Esta parte es la más compleja. Es donde nos gastamos la pasta o vemos mantenimientos a la moto.
Para esta parte, el usuario, según el detalle que quiera mantener en al información, debe poder mantener dos categorías (grupo y subgrupo) . Ahora lo entenderéis mejor.
Cada tarea va asociada a una categoría, subcategoria, tiene una fecha, un coste, y unas unidades consumidas-Compradas, y un c ampo de información .
Tenemos varias categorías.

Mantenimiento
En esta categoría introduciremos las tareas individuales que iremos realizando en la moto.
En este caso la categoría sería Matenimiento y las subcategorías serían(por ejemplo) Aceite Motor, Ruedas, Anticongelante, Filtro de aire, Filtro de Aceite, etc… O sea, en este caso al ser temas constantes, el usuario puede definir el detalle de la Subcategoría.
Un ejemplo.
Yo compro 5 litros de Bardhal. Esto supone una entrada en la que se indica que ha habido un gasto en Mantenimiento-Aceite, pero no unidades de consumo.
Ahora le cambio el aceite a la moto o le tengo que echar algo porque me consume. Esto implica una entrada en Mantenimiento-Aceite sin coste, pero con un consumo de 300cc.
Con esto conseguimos tener control del coste y de los consumos de aditivos, o lo que necesitemos.
En cambio. Que me cambian la rueda trasera. Pues eso es una entrada en Matenimiento, Ruedas, una ruda trasera por 60€(ejemplo) en una fecha con unos km de la moto.

Accesorios de la moto.
En esta parte tomaremos todo lo que es accesorio en la moto. Estos complementos tienen que tener un tratamiento parcialmente distinto.
No es un coste atribuible al mantenimiento, si no que ya son cosas que le ponemos de extra.
Estaríamos hablando de la categoría Accesorios y con subcategorías….. Equipaje, Luces, Escapes.
Aquí también pondríamos cosas como el pico de pato en la adventure, repintado o cambio de color….
De esta manera tienes localizados lo que digamos que es un poco superfluo a la moto.

Piloto:
No solo la moto Gasta.
Nosotros también tenemos lo nuestro. En este caso tendríamos subcategorías como , vestimenta, cascos, guantes, electrónica (gps, comunicadores), calzado etc.

Otro gastos:
Dentro de esta categoría serían gastos asociados a la moto pero no de aplicación directa como Seguros, Impuestos, si nos ponemos chulos ---- parkings y peajes…..

En definitiva para cada registro de Mantenimiento-Compras deberemos guardar:
*Fecha del Gasto-Mantenimiento
*Km de la moto
*Categoría (Mantenimiento, accesorios, Piloto, Otros Gastos)
*Coste
*Cantidad (Consumida- o comprada)
*Descripción de la misma.
*Evento (por defecto es General a no ser que se introduzca un evento asociado)

REPORTES-INFORMES
Esta parte es, dada la información anterior, presentar informes asociados a esta información.
Costes, Consumos, km, ventos, próximas alarmas, históricos etc….

-------------------------------------------------------
Yo creo que para empezar me he pasado de la raya, pero…. Todavía me quedan cosas en el tintero:
*Alarma de Consumo excesivo.
*Alarma de consumo de aceite.
*Creación de alertas autmáticas.
*Almacenamiento de información de la moto.
*Sistema Multimoto.


Saludos......

Por cierto, tengo que poner una pega a este tipo de aplicaciones.
En el caso de que se siga al 100%...os podeis asustar que lo que os gastais en Moto....
jajajajaja

PD: Tener la aplicación escondida (por eso el pen drive) de esposas ignorantes de lo que te puedes gastar.

Saludos

Cascade, creo que tenemos una misma idea de lo que queremos para la aplicación.

Y por otra parte, lo que has puesto de que hiciste el proyecto de fin de carrera en PB y el que seas de Segovia, me hace pensar que has estudiado en el Domingo de Soto, que es donde yo estudié, por lo que es muy probable que nos conozcamos.

En mi caso soy de la segunda promoción.

Hola Cascade!!!

muy completo el análisis!!! Parece un enunciado de práctica de mi universidad, jejeje...

Pues la verdad es que sería un punto de partida perfecto, si bien algunas cosas aún no las veo claras de todo (llevo ocho horas encerrado en mi garito ) u otros tal vez los complementaría. Pero no le falta de nada. Los reportes o informes estos tienen más juego en el sentido que a un usuario le pueden interesar algunas cosas, y a otro otras cosas distintas.

Esta tarde miro de ver si se me ocurre algo. Y ya os digo, que si queréis mi colaboración contad con ella, pero por desgracia se limita a lo que he comentado antes... Aún soy aprendiz...

Un saludo

asoblech escribió:Cascade, creo que tenemos una misma idea de lo que queremos para la aplicación.

Y por otra parte, lo que has puesto de que hiciste el proyecto de fin de carrera en PB y el que seas de Segovia, me hace pensar que has estudiado en el Domingo de Soto, que es donde yo estudié, por lo que es muy probable que nos conozcamos.

En mi caso soy de la segunda promoción.

Jajaja te iba a decir lo mismo... y a Felix de Profesor de la asigntura de proyecto.
Empecé en el 1995 y acabé en el 1999, en septiembre....Que hayamos coincidido es posible... Yo ando en Segovia Ahora por si necesitas algo... pero ya te digo que ando muy pero que muy perdido en programación...
Algún viernes por la tarde me puedo escapar para vernos y tomarnos una birrita.

Bueno... cuando tenga un rato hago un análisis del modelo de Base de datos.... (o directamente lo hago en Access que es muy rápido)
Un tema...
¿Versión de Powerbuider?
Yo ahora no tengo nada, y hecho una búsqueda en fuentes alternativas....y no he encontrado nada.....que me guste..

Pues creo que si que coincidemos ya que yo comencé en el curso 94/95 y terminé en el 96/97, quizas te acuerdes de un chico que tenía un R19 verde oscuro (ya que tenia 42km desde el pueblo), rubio, con gafas que ganó el premio de escolaridad de los cursos 95/96 y 96/97. Pues ese era yo en mis buenos tiempos. (que buena epoca la de la universidad).

Por otra parte por ahora yo estoy en Madrid, pero suelo bajar un fin de semana cada mes o mes y medio al pueblo (con eso me escapo un rato con la moto), pero hace dos años que nacio mi enano y nos tiene practicamente copado todo el tiempo. De hecho el tema de hacer el programa sería despues de acostarlo, pero de todas formas si un finde tengo algo de tiempo, ya te pongo un mensaje y si podemos nos tomamos unas cañas.

Por lo de la versión de PB, en el curro tenemos la 11 y en casa tengo la 9 que va muy bien, por lo que no es problema. Y en cuanto a BD, yo creo que con Access es más que suficiente.

Saludos

JOer.... hace ya 11 años que salí y la memoria no me da mucho.
Yo iba con Michel que era de Coca, hijo de un encargado de la escuela de Capacitación Forestal de Coca, y tocaba en la banda de Coca.

Creo que los pasos a tomar serían los siguientes:
1º- Definición de la Base de datos.(¿Interesa definir integridad referencial o se controla por aplicación?)
2º- Definición del Menú base.
3º- Definición de Datawindows.
4º- Definición de Ventanas.
5º- Definición de Informes (esto seguramente sea incremental)

Realmente.
Yo puedo dejar preparada una BD de datos access pero....ya me pondría y tomaríamos información de qué moto lleva el gasto etc... Digamos que ya se puede hacer multimoto, pues para la entrada de datos afecta poco y para los informes... siempre prefiltrado. (moto1, moto2, o gasto generico)

LA idea es dejar ahora la base de datos lo más completita posible, para que a futuro las versiones solo sean versiones del Programa, y la gente no pierda la información.

Para todo el mundo.... El tema de las categorías y subcategorías.... definid vuestras ideas..... que esto es para todos...

Siempre he sido del pensamiento que la integridad referencial la realice la BD que para eso está.

Por otro lado, lo podemos hacer pensando en vehículos de forma generica, de esta forma nos puede valer también para nuestros coches, ... con practicamente definir el numero de ruedas que tiene el vehículo.

Para el tema de las alarmas, lo que tenia pensado es hacerlas dobles, es decir siempre se dice que el cambio de aceite se tiene que hacer a los x KM o al x tiempo, por lo que la alarma comprobará de forma automática las dos condiciones, y tenia pensado que en cada vehículo cada usuario se pudiera configurar sus propias alarmas ya que de esta forma se puede poner la de la ITV, la de cualquier mantenimiento como recordatorios de engrasado de cadena, cambios de aceite, etc

Por otra parte, creo que todo lo que son acciones se pueden guardar en una única tabla a modo de seguimiento del vehiculo, perfectamente identificados con su fecha, categoria, subcategoria, ... de tal forma que si haces un informe de los datos de un vehiculo ordenados cronologicamente, tendrias toda la vida de la moto, incluso comentarios varios que el usuario quiera hacer tales como que tal día salió a dar una vuelta y le comenzó a sonar tal cosa, o lo que sea.

Por otra parte, quizas tendriamos que comenzar a definir las entidades de la aplicación tales como vehículos, categorias, subcategorias, ... de esta manera todo el mundo comenzará a entender un poco como se estructuran los datos y nos pueden ir ayudando con las multiples ideas que puedan tener que seguro que son muy buenas y ya se sabe ven mas cuatro ojos que dos.

Creo que es mas fácil empezar a definir la base de datos... nos la vamos pasando con los comentarios de cada uno pues si la definimos con nombres claros... solo con verla ya sabemos lo que tenemos y sus posibilidades.

Yo creo que teniendo la base, por tu parte si puedes dejar arrancada la parte inicial (ventana principal, tipos de ventana a usar, y el menú, yo me puedo animar, al menos con eltema de informes y definición de datawindows (si no recuerdo mal podían ser llamados por parámetros y al ser llamados en la llamda se incluian los mismos, sin hacer referencia a los objetos...

cascade escribió:Bueno bueno.
Me he puesto a hacerlo en Woed primero para que no se joda lo que iba a escribir.
En principio lo que se me ocurre es que la aplicación puede tener las siguientes partes:

Combustible
Esta es la parte más básica de la aplicación y la más usada. Se almacenará la fecha, los km del cuenta km (no el parcial si no los totales) cantidad echada y coste de lo echado (el precio litro lo podemos sacar por la división) y pongamos que el tipo de combustible. A la hora de guardar el registro, sacará la cantidad de KM recorridos desde el ultimo repostaje.
En este aspecto es importante poder editar los repostajes.
A la hora de guardar un repostaje, se revisarán la alarmas-avisos referentes a KM.
Como dato interesante, es importante saber si el repostaje va a asociado a algún evento. Por ejemplo Pingüinos. De esta manera podremos controlar el coste asociados a eventos.

En definitiva para cada registro de Mantenimiento-Compras deberemos guardar:
*Fecha del Respostaje
*Km de la moto
*Km desde el último repostaje (automático)
*Descripción Corta
*Descripción Larga
*Cantidad
*Descripción de la misma. (Por si queremos guardar mas información del repostaje)
*Evento (por defecto es General a no ser que se introduzca un evento asociado)


Alarmas-Avisos
A la hora cuidar la moto… no está de más que algo nos diga que se acerca el momento de meter mano a la moto.
En este caso se definirían dos tipos de alarmas.
Distancia
Se definirán avisos en función de la distancia pendiente. En este caso se almacenaría a que km deberá saltar la alarma, un texto para poder indicar qué es la alarma, y si queremos que nos preavise, por ejemplo 500 km antes. Estas alarmas se revisarán cada vez que se produzca un repostaje
Fecha
Se definirán avisos en función de la Fecha. En este caso se almacenaría cuando deberá saltar la alarma, un texto para poder indicar qué es la alarma, y si queremos que nos preavise, por ejemplo 500 km antes. Estas alarmas aparecerán cuando se inicie el aplicativo.
Evento:
Esto no está asociado al mantenimiento, y sí digamos como una agenda de eventos (ya puestos el cambio es bajo) en el que el usuario podrá de alta eventos como concentraciones, quedadas, compras conjuntas…

Por supuesto, se debe poder editar las alarmas, Teniendo disponible un campo de que indique, activa, inactiva o caducada.

En definitiva para cada registro de Mantenimiento-Compras deberemos guardar:
*Fecha de alta de la alarma
*Fecha de activación de alarma(si es una alarma de Fecha)
*Días en que se debe preavisar la alarma
*KM de activación de alarma (si es una alarma de KM)
*Km en los que se debe preavisar de la alarma
*Descripción de la misma. (Por si queremos guardar mas información del repostaje)
*Evento (por defecto es General a no ser que se introduzca un evento asociado)


Mantenimientos – Compras
Esta parte es la más compleja. Es donde nos gastamos la pasta o vemos mantenimientos a la moto.
Para esta parte, el usuario, según el detalle que quiera mantener en al información, debe poder mantener dos categorías (grupo y subgrupo) . Ahora lo entenderéis mejor.
Cada tarea va asociada a una categoría, subcategoria, tiene una fecha, un coste, y unas unidades consumidas-Compradas, y un c ampo de información .
Tenemos varias categorías.

Mantenimiento
En esta categoría introduciremos las tareas individuales que iremos realizando en la moto.
En este caso la categoría sería Matenimiento y las subcategorías serían(por ejemplo) Aceite Motor, Ruedas, Anticongelante, Filtro de aire, Filtro de Aceite, etc… O sea, en este caso al ser temas constantes, el usuario puede definir el detalle de la Subcategoría.
Un ejemplo.
Yo compro 5 litros de Bardhal. Esto supone una entrada en la que se indica que ha habido un gasto en Mantenimiento-Aceite, pero no unidades de consumo.
Ahora le cambio el aceite a la moto o le tengo que echar algo porque me consume. Esto implica una entrada en Mantenimiento-Aceite sin coste, pero con un consumo de 300cc.
Con esto conseguimos tener control del coste y de los consumos de aditivos, o lo que necesitemos.
En cambio. Que me cambian la rueda trasera. Pues eso es una entrada en Matenimiento, Ruedas, una ruda trasera por 60€(ejemplo) en una fecha con unos km de la moto.

Accesorios de la moto.
En esta parte tomaremos todo lo que es accesorio en la moto. Estos complementos tienen que tener un tratamiento parcialmente distinto.
No es un coste atribuible al mantenimiento, si no que ya son cosas que le ponemos de extra.
Estaríamos hablando de la categoría Accesorios y con subcategorías….. Equipaje, Luces, Escapes.
Aquí también pondríamos cosas como el pico de pato en la adventure, repintado o cambio de color….
De esta manera tienes localizados lo que digamos que es un poco superfluo a la moto.

Piloto:
No solo la moto Gasta.
Nosotros también tenemos lo nuestro. En este caso tendríamos subcategorías como , vestimenta, cascos, guantes, electrónica (gps, comunicadores), calzado etc.

Otro gastos:
Dentro de esta categoría serían gastos asociados a la moto pero no de aplicación directa como Seguros, Impuestos, si nos ponemos chulos ---- parkings y peajes…..

En definitiva para cada registro de Mantenimiento-Compras deberemos guardar:
*Fecha del Gasto-Mantenimiento
*Km de la moto
*Categoría (Mantenimiento, accesorios, Piloto, Otros Gastos)
*Coste
*Cantidad (Consumida- o comprada)
*Descripción de la misma.
*Evento (por defecto es General a no ser que se introduzca un evento asociado)

REPORTES-INFORMES
Esta parte es, dada la información anterior, presentar informes asociados a esta información.
Costes, Consumos, km, ventos, próximas alarmas, históricos etc….

-------------------------------------------------------
Yo creo que para empezar me he pasado de la raya, pero…. Todavía me quedan cosas en el tintero:
*Alarma de Consumo excesivo.
*Alarma de consumo de aceite.
*Creación de alertas autmáticas.
*Almacenamiento de información de la moto.
*Sistema Multimoto.


Saludos......

Yo creo que con esto sería perfecto y valido para cualquier moto.
A partir de los siguientes mensajes no entiendo ni papa, digamos que mi punto álgido en programación fue hacer un programita que te calculase cuanto te cuesta la compra con visual basic xD.

V'sss

Hola a todos!!!

Esta tarde al final no he podido revisarme nada, pero veo que la cosa va viento en popa.

De todos modos se me ha ocurrido una idea, pero que no tengo ni papa de cómo se podría llevar a cabo: que el programa sea un pequeño aplicativo web accesible para todo el mundo con usuario y contraseña.

Mi jefe me comentó en su momento que con Access se pueden hacer que los formularios sean como páginas web, por eso lo comento. Como siempre, ante la falta de tiempo para desarrollar nada pues no seguimos con la idea.

¿Es una locura lo que he dicho?¿O es mejor un programa tipo llave en mano?

Un saludo

la ventaja del sistema de desarrollo con Powerbuilder es que para cosas básicas, funciona mejor el access, pero para tratamiento complejo de información, es mucho más rápido que incluso el .Net.

El tema de hacerlo WEB, no tiene mucho dentido, a nivel de que es mas lento, y es una aplicación usario, no distribuido, y totalmente local.

Lo hacemos como querais, pero creo que lo mejor seria una aplicación para local que como no va aser muy grade, luego podriamos compilarla como ocx web y con algunas modificaciones si la cosa va bien ya veriamos si es aconsejable.

Por lo de el desarrollo, lo hacemos como quieras, yo suelo plantear un funcional despues de la base de datos y lo suelo afrontar por ventanas completas.

cascade escribió:Jajajajaja
Joder que recuerdos con el powerbuilder Que gozada era parametrizar las datawindows....
Hice con eso mi proyecto de carrera. Al año estuve haciendo la aplicación de gestión de Socios del Club megatrix de Antena 3.
Entre medias una aplicación pirata.....digamos para sacarme unos duros extra, que cuando empiezas cobaras muy poco.
El tema del oracle...es una chulada, hay instaladores para bases de datos no clusterizadas, o el Oracle Express, pero no es lo mejor para gente que no sabe de trastear.
Lo mas sencillo.... un SQL lite, no ocupa ni nada, pues para la volumetria que se usaría es lo recomendable.
La otra opción es Access mas generico y visual para alguien que no sabe y tiene que toquetear la base de datos.
Yo ahroa estoy fuera de la parte de programación, pues me dedico al analisis y esas cosas......
Per si necesitais ideas.... aqui estoy.

Este tipo de aplicaciones para que funcione de lujo, requiere que el usuario sea muy constante en la introducción de datos, como por ejemplo cada repostaje, dado que de esta manera te avisaría (bajo alarmas parametrizadas como cambio de aceite, ruedas, pastillas, liquido anticongelante, cadena, kit de distribución) que tienes que hacerle a la moto.
He de deciros que la manera de llevar a cabo el desarrollo correctamente, lo mejor es ver hasta donde se quiere alcanzar, e ir atacando por partes, pues de lo contrario acabaríaís locos.
Es mi consejo.

"ir atacando por partes" = "divide y venceras" sabio consejo, es lo primero que te enseñan (o enseñaban, mi primer programa vendio, o mejor dicho cobrado lo hice en cobol. Ya ha llovido) en programación,


¿De verdad os queréis meter en ese follón?, yo las anotaciones las hago en excel apuntando acción, fecha, km etc con lo que en cualquier momento calculo lo que necesito. También existen con licencia gratuitas programas para estas cosas.

Si de verdad queréis meteros al tema pues adelante, os hecho una mano si queréis. Hace mucho que no programo pero eso nunca se olvida, en una semana se pone un las pilas.

No habéis considerado java y creo que es un buen candidato porque facilitaría que se pudiera hacer una versión para el móvil o pda.

cascade escribió:Por cierto, tengo que poner una pega a este tipo de aplicaciones.
En el caso de que se siga al 100%...os podeis asustar que lo que os gastais en Moto....
jajajajaja

PD: Tener la aplicación escondida (por eso el pen drive) de esposas ignorantes de lo que te puedes gastar.

Saludos

Yo veo una pega mayor, hay que mantenerlo, yo es que soy mu flojo para meter después todos los datos

Yo tengo dos motos y las hago yo el mantenimiento, y lo llevo de cabeza, de momento mi programa no ha fallado,incluso a veces se adelanta y cambio el aceite antes de tiempo.

JAJAJAJA!!!!!!

Ahora en serio, para el que es meticuloso y le gusta llevar un control exhaustivo de su moto ,está muy bien lo que estais pensando.

Yo introduciría también en los repostajes la estacion de servicio, no todas las gasolinas son iguales y seguro que unas rinden más que otras, por lo que se podrían sacar informes muy interesantes del rendimiento de la chofa.

No veas que caña de ideas que teneis, yo lo de la chofa lo solía calcular con el excel, aunqué solo ponia km totales y Litros de combustible hechados...
Así descubrí que la Lobito consumia 5 Litros jajaj

Buena idea lo del programilla, seguid con ello y con suerte saldrá algo bueno!!!

Hola a todos!!!

evidentemente la idea de hacerlo en en web es que sea como un portal simplemente. No haría tan sólo falta grabar nada en local, o al menos esa era mi idea. De hecho en mi empresa ya tenemos dos portales hechos así, uno con VB y el otro con .net.

La parte mala es que para eso hacen falta pagar el dominio, el alojamiento en un host, etc.

Tal vez tan sólo por eso sea mejor la idea de una aplicativo local. Aunque si fuéramos del todo estricto, también deberíamos de pagar la licencia de Access que tenemos en nuestro portátil o torre de casa... Pero, ¿quién lo hace? jejeje

Un saludo

Una pregunta....
¿Realmente quereis que la información de vuestra moto, donde repostais, que lelvais en la moto.... este publicado en internet?

Lo siento...jejejeje... pero sigo sin verlo... yo lo prefiero en mi equipo controlado por mi.

En lo referente a la idea de poner la gasolinera.... digmos que es una análisis diferente..
Me explico.
Con la idea inicial, es para el control de litros y km recorridos, algo sencillo.
Lo que tu comentas mas complejo, pues digamos que echas 98 en una Cepsa pero solo haces 50 km y al pasar por Carrefour decides llenar el depósito, es mas barato. Le has echado 2 litros....
Y has hecho con ese depíto lleno 300 y con uno de Cepsa haces 310.... realmente tu depósito llevaba una mayoría grande de 98 de cepsa....

Digamos que el primer método es un sistema simple de compra y repostaje....
Lo segundo es un sistema complejo de Consumos, y si metemos por medio el coste... mas complejo...
La idea cojonuda.... complejo... un rato....Vamos pasoa a paso

Hola a todos!!!

Entiendo perfectamente la posible desconfianza que pudiera darte el tener tus datos publicados en un servidor, pero para eso está el tema de la LOPD para cualquier base de datos que exista. Respecto a la visibilidad de los datos eso es un tema de permisos y ya está.

Pero vamos, sí que es cierto que un programa de llave en mano o alojado en local es mucho más sencillo de implementar y asegura lo que dices de que sólo lo vas a ver tú (a no ser que te entre nadie por el cable de cobre conectado a la roseta sin que te enteres, claro).

Como dije antes, la propuesta inicial era y sigue siendo perfecta. Tan sólo he propuesto una idea de interfaz con el usuario en entorno web, pero aplicado sobre esa primera idea, como un paso más.

Poco más puedo aportar de ideas y tan sólo ofreceros mi ayuda si hay que hacer cualquier tipo de desarrollo en alguno de los lenguajes que conozco.

Un saludo