Facturlinex busca colaboradores

[xaime]

Buenos días.

Antes de pasar a materia pediros de nuevo disculpas si con los comentarios ofendía a alguien.

Nuestros deseos son el conseguir una aplicación operativa y funcional, y para eso ( sobre todo por la falta de tiempo para el desarrollo ) le tenemos que dedicar todo nuestro tiempo al avance y no a la optimización del proyecto.

Desde aquí lanzamos un llamamiento a quien quiera y pueda a que nos ayude en la optimizacion de facturlinex : renombrado de campos, reutilización de código, ... .

Si os fijais en el svn, tenemos una parte trunk donde estamos con el desarrollo y otra para la estable ( branches ). Podríamos abrir una tercera opcion donde fuésemos optimizando. La verdad es que sin ayuda no creo que podamos asumir esa tarea de momento. Queremos estabilizar lo que tenmos ahora para subir un nuevo deb a los repositorios de debian.

Así que queda echado el guante por si alguien se anima.

Reconocemos ( y hablo en nombre de todo el equipo ) que el código hay que mejorarlo, pero repito que lo que hicimos fue partir de las fuentes de la versión anterior, y aunque ya existen tablas con la nomenglatura de los campos más humana y código reutilizado le falta muuuucho por hacer.

Nos juntamos 5 amigos, cada uno de su familia y con sus métodos de programación; nos adaptamos a lo que había y nos parece que estamos haciendo un buen trabajo.

Gracias por las críticas y por aquí nos tendreis para lo que podamos ayudar.

Un saludo.

[mamcx]

Una buena manera de arrancar seria tener un diccionario de datos.

O algo mas simple: Una lista de llave=valor para automatizar el renombrado.

Mirando el codigo, veo que se puede hacer algo con expresiones regulares. Una vez que hice algo similar utilice http://www.regular-expressions.info/powergrep.html.

La idea es tener una lista como

CO1 = ???
C02 = ???

Y hacer con eso un reemplazo masivo... Si cada C01 es unico entre los demas campos de tablas el trabajo es ligeramente facil de hacer. Sino, hay si toca hacerlo a la antigua...

[f-javier]

Hola,

Jaime anda hoy algo liado, por eso voy a responder yo en este hilo.

Si dijera que tenemos mentes privilegiadas y que nos acordamos del contenido de los campos, mentiría como un bellaco, jejeje. Sin embargo, tenemos un documento donde mantenemos las equivalencias de los campos con su contenido. El que quiera echarle un vistazo lo puede encontrar en http://facturlinex.svn.sourceforge.n...acturLinex.odt.

Imagino que ahora mismo lo que más nos puede interesar es la realización de un TO-DO, una hoja de ruta, para ir planificando el trabajo, pero nos falta experiencia en esos temas.

Ahora que se han aclarado los malentendidos iniciales, creo que lo mejor es dejar pasar todo este asunto y planear estrategias para el futuro. Si alguien de vosotros se anima y nos echa una mano en la realización del TODO creo que mejoraremos en lo que llevamos años trabajando.

Quizá el hecho de estar enfrascado en una tarea específica, en nuestro caso el desarrollo de FacturLinEx, haga que no nos demos cuenta del global y sigamos en el trabajo diario.

Creo que ahora mismo el planteamiento es ver de planificar tareas, quizás un brainstorming, pero en mi caso los que hice eran presenciales, por lo que sí era factible. Como recién llegado al mundo del software libre, no tengo demasiada idea de cómo se plantean estas cosas en la distancia, por lo que sí podemos aprender de vosotros. Algunos consejos serán bien recibidos, seguro.

Bueno, lo dicho, trabajo hay para el que quiera, jejeje.

Hablo por mi, pero supongo que el resto de compañeros pensarán igual.

Un saludo,
f-javier

[mamcx]

Les recomiendo usar para ello https://www.pivotaltracker.com/, es el mejor administrador de tareas de desarrollo que hay (es gratis para proyectos open source).

Tambien deberian tener algo como lo que hicieron los de firebird, osea, para que version planean la conversion. Hacerlo en medio de algo importante que estan haciendo es mala idea... es mejor cerrar lo mas crucial ahora, abrir una linea de codigo pa lo nuevo e ir solo metiendo fixes a lo viejo.

Un primer paso seria solo el de cambiar los nombres de los campos. Refactorizar y lo demas es mas complejo y al menos con nombres mas humanos la cosa mejoraria mucho.

En el proyecto de https://www.djangoproject.com/ tienen una idea buena que cada tanto tiempo hacen un sprint (carrera) de arreglar cosas con mucha gente enfocada x dias solo a eso.

El proyecto es muy grande asi que la tienen mas facil, pero la idea es:

1- Tener la lista concreta de que hay que hacer (la parte mas importante) en una herramienta de manejo de bugs (como pivotal), con lista de tareas reducida a lo mínimo del objetivo buscado
2- Solicitar ayuda de tanta gente como se pueda para que dedique un numero fijo y claro de tiempo, en un momento bien definido (ej: Lunes - Miercoles entre tales y tales horas)
3- Dar algo a cambio por el esfuerzo extra: Un badge, una camisa, reconocimiento, lo que sea (quizas con el apoyo de algun cliente de la app) a los que mas hayan colaborado.

Es mas facil hacer algo asi si se define un tiempo, un objetivo y un lugar claro. Quizas de esa manera, es mas simple lograr que quienes no estan interesados en hacer parte full-time del proyecto pero les suena la idea aporten en algo.

[[mightydragonlor]]

Empezado por xaime

Buenos días.

Desde aquí lanzamos un llamamiento a quien quiera y pueda a que nos ayude en la optimizacion de facturlinex : renombrado de campos, reutilización de código, ... .

Un saludo.

Bueno la verdad es que quiero hacer parte de esta optimizacion, ahora, tengo varias ideas sobre sobre como hacerlo, me gustaría discutir una ruta de trabajo demás, como lo hago?, básicamente quiero hacerlo bien pronto para ayudarlos en este grandioso proyecto, que la verdad desde hace rato que me atrae y como todos sabemos que el código no es el mejor del mundo, casi que me gustaría arrancarlo como proyecto nuevo y siguiendo desde el inicio una buenas prácticas de programación, bueno me cuentan que opinan de esto y estoy pendiente de una respuesta, gracias.

[f-javier]

Hola mightydragonlor,

Primero explicar cómo andamos actualmente.

Siempre hemos trabajado en la rama trunk en nuestro servidor de svn (alojado en sourceforge). Llegó un momento en el que pensamos que la versión 2 ya estaba bastante madura y sin fallos, pues llevaba algún tiempo en producción en el negocio de uno de los desarrolladores y decidimos cerrar una versión estable.

En ese momento creamos una rama estable (v.2.0) y el desarrollo continuó en trunk (v.2.1). En esa rama ya no se añadía nada nuevo, sólo se solucionaban errores, de la cual salió la versión 2.0 (estable), previo paso por una RC1.

Ahora lo que podríamos plantear.

La idea ahora sería abandonar la versión 2.0, pasar a estabilizar la actual 2.1 (pasándola a denominar 2.2) y seguir en trunk con la 2.5, donde se tomaría todo el cambio del código que se precise hasta su correcta funcionalidad que podríamos liberar como versión 3.0.

Supongo que la única "condición" para empezar con este asunto sería seguir trabajando con sourceforge, estoy seguro de que habrán muchas herramientas más completas, pero siempre hemos trabajado allí y creo que la gente querrá mantener el proyecto donde está. Yo por mi parte, no cierro las puertas a usar otras herramientas si se mejora la productividad y creo que los compañeros tampoco, sólo digo que si seguimos mas o menos como estamos, mejor. Pero vamos, que todo es cuestión de plantearlo entre todos.

Seguimos en contacto.

Un saludo,
f-javier

[mamcx]

El uso de pivotal no implica abandonar sourceforge. De todas maneras, dale una mirada a ver que les parece...