Burdjia

Etiqueta PHP, 11 entrada(s)

Feed Rss, Atom

Ágora 2.0

El pasado viernes subí (por fin) la versión 2.0 de Ágora, algo que debería haber hecho hace tiempo pero que, entre procrastinación y medios-trabajos, no terminé la documentación hasta entonces.  Para descargar, basta con ir a la página del proyecto.

Para quien no sepa de qué va, Ágora nació hace tiempo como alternativa a Code Igniter, un marco de desarrollo (framework) para PHP.  La idea era hacer lo mismo pero más sencillo, más dirigido a pequeños proyectos o páginas que no necesitaran demasiado trajín, nunca al desarrollo de aplicaciones.  Sin embargo, seguía siendo mucho más complejo de lo que pretendía.

Con esta versión 2.0 sí he conseguido la simplicidad que buscaba.  De hecho se ha eliminado el patrón Modelo Vista Controlador con el que partía, y lo he reducido todo a un único archivo, el cual define unas pocas constantes de configuración y una clase estática llamada AGORA que contiene todo el sistema.  También creo que he conseguido escapar de la trampa de los porsiacas en la que caí en la versión anterior, y de la que no conseguí zafarme en las tres versiones posteriores.

Espero que la documentación y los dos ejemplos, uno de los cuales es una plantilla para páginas web hospedadas en SourceForge que ya estoy utilizando en un par de proyectos, sean suficientes.  Aun así, como sé que hay cosas que pueden no comprenderse a la primera, no dudéis en preguntar en los comentarios o en este hilo del Club Delphi.


Y una vez más, aprovecho para decir que PHP no es un buen lenguaje para desarrollar aplicaciones de ningún tipo.

Etiquetas: PHP

Categorías: Ágora, Programación, Proyectos, Web

Rescatando Gesbit

Hace algunos años, David Esperalta creó Gesbit, el "motor para bitácoras" que, precisamente, uso aquí, para aprender y mejorar sus conocimientos sobre programación.  Cuando llegó a la versión 2.0 decidió abandonar su desarrollo.  El problema es que también eliminó toda la información del proyecto de Internet.

Trabajando, como estoy, en la mejora de Burdjia.com me encontré con la disyuntiva de continuar o no utilizando Gesbit.  Podría pasarme a otro sistema, o podría crear el mío propio, pero decidí contactar con David y pedirle el rescate del proyecto.  Y accedió, me envió todo lo que tenía (la versión 2.0 al completo, junto con muchas extensiones) y yo acabo de subirlo, de nuevo, a la web del proyecto, desde la que puede descargarse de nuevo.

No hay nada concreto planeado para el proyecto, ya que tengo que determinar si lo que necesito de él es mejor obtenerlo mediante extensiones o modificando el propio motor.  De hecho todavía no sé si ya es capaz o no de hacer lo que planeo.  Algunas cosas son comunicación con las redes sociales, soporte de múltiples idiomas (es decir, poder tener varias versiones del mismo artículo/entrada), enlaces diversos, integración ...  También hay alguna cosa que no funciona, o al menos no lo hace como creo que debería, y tengo que revisarlo antes de decidir nada.

De momento, la buena noticia es que de nuevo está disponible.  Dentro de poco abriré los servicios de soporte de SourceForge para que puedan hacerse sugerencias, enviar notificacions de error, resolver dudas y hacer un seguimiento del proyecto.

Etiquetas: PHP

Categorías: Gesbit, Proyectos, Web

Nuevo sitio Allegro.pas

Con un mes de retraso, informo que publiqué una nueva versión de Allegro.pas, la 4.4.4.

Y hoy mismo he terminado y subido la nueva web del proyecto.  Esta está adaptada mejor a las mejoras realizadas por SourceForge en sus servicios, por lo que ya no usará GesBit.

La nueva web está realizada, en parte, con Ágora, pero con una nueva versión reescrita desde cero.  Esta nueva versión sí es realmente simple (admito que hasta ahora no era tan simple como pretendía, sino todo lo contrario); de hecho ocupa únicamente un archivo de apenas 12KiB.  Todavía no la he hecho pública porque he querido ponerla a prueba.  En cuanto tenga unos pocos ejemplos para documentar su uso, la publicaré y comenzaré la necesaria reforma de Burdjia.com.

Etiquetas: Pascal, PHP

Categorías: Ágora, Allegro.pas, Proyectos, Videojuegos, Web

El valor de medio céntimo

Hoy voy a contar un nuevo episodio en mi vida como desarrollador contra-corriente.  Como ya conté en mi artículo sobre los colectores de basuras, llevo tiempo trabajando en un megaprograma de gestión de clientes, pedidos, facturas, análisis, seguimiento y más cosas. También dije que hay varias cosas de este proyecto con las que no estoy de acuerdo y de las que me he quejado en repetidas ocasiones, empezando por que la planificación no fue suficiente en su momento.  Precisamente esta falta de planificación ha sido la causante de un problema que reventó hace pocos días.

Hace tiempo, al principio, sugerí que íbamos a tener problemas con el redondeo. Este no es un problema trivial, porque si no se hace bien aparecerán discrepancias y luego no hay forma de cuadrar las cuentas.  Ya entonces propuse una forma de evitarlo que usé con éxito hace años en un Terminal Punto de Venta que desarrollé cuando trabajaba en la empresa Asintec Gestión.  En aquel programa, en lugar de almacenar el valor real de los productos guardábamos un valor ficticio y lo guardábamos como un número entero.  Para obtener el valor real se dividía este número ficticio por un factor que dependía de la divisa;  así para los euros dividíamos por 100.000, mientras que para obtenerlo en pesetas dividíamos por 601.  Con este método nos quitamos dos problemas:  la conversión entre divisas (importante, porque se hizo para un hotel, y además coincidió con el paso de la peseta al euro) y teníamos una precisión de hasta la milésima de céntimo de euro, más de lo necesario.  Además, los ordenadores son pésimos con el cálculo fraccionario, siendo mucho más precisos si calcula con números enteros.

Con la aplicación que estoy desarrollando ahora, sin embargo, tampoco en esto se me hizo caso y se me obligó a almacenar y realizar todos los cálculos con euros “reales”.  Y no sólo eso, sino que la precisión se limitó a dos decimales, esto es, a un céntimo:  ni siquiera una fracción de céntimos, sino a céntimos enteros.  Esto ya es un problema con el cálculo de impuestos.  La cosa empeoró cuando en Julio entró en vigor el nuevo IVA1.  El cliente quiso que los precios finales se mantuvieran invariables aun con el cambio de IVA, sin embargo al hacer el cálculo siempre faltaban o sobraban uno o dos céntimos en cada producto.  Canté aquello de “os lo dije” con toda la sutileza de la que fui capaz y volví a sugerir la solución que he explicado antes, pero de nuevo no me hicieron caso y la solución impuesta fue aumentar en un decimal la precisión (es decir, hasta la décima de céntimo) porque así ya no faltaban ni sobraban céntimos al sumar el nuevo impuesto y se solucionaba el problema.

Hasta que se demostró que no era así.  Hace unos días, un cliente se quejó porque hizo un pedido por un importe aproximado de 1.500€, pero la factura que le enviaron había una diferencia de 21 céntimos a favor de la empresa.  Por más que revisé los cálculos, todos eran correctos, tanto en el albarán de pedido como en la factura, sin embargo la discrepancia permanecía.  Yo sabía que era un problema de redondeo, pero no lograba descubrir dónde se producía la diferencia.  Al final lo descubrí por casualidad.

Resulta que del cambio en la base de datos se encargó mi jefe, y lo realizó sólo en la tabla que almacena la información de los productos en venta.  Sin embargo, en nuestro programa el precio de los productos se almacena también en cada factura, de forma que aunque cambie el precio de los productos este no varía también en las facturas, y en la tabla donde se almacena el precio en factura no se hizo el cambio.  Es decir, que el precio del producto se guarda con tres decimales, mientras que el precio en factura se guarda con dos.  ¿Y dónde está el problema?  Pues sencillo:  en unos productos el precio es de tantos euros, tantos céntimos y menos de medio céntimo, lo que al redondear a dos decimales no afecta al precio salvo si son muchas unidades (por ejemplo, si el precio es de 10'652 al redondear queda 10'65), pero en otros es de tantos euros, tantos céntimos y más de medio céntimo, por lo que al redondear a dos decimales ese “más de medio céntimo” hace que el precio suba al céntimo siguiente (por ejemplo, de 10'656 queda 10'66).  Es decir, el mismo problema que existía al calcular el nuevo valor neto para ajustarlo a los nuevos IVA y Recargo de Equivalencia; era una bomba de relojería.

Todavía no sé si está arreglado, ya que conseguí cargarle el mochuelo a quien realmente tuvo la culpa.  Me gustaría pensar que en el próximo proyecto me harán más caso pero, visto lo visto, me temo que voy a tener que sufrir estas cosas durante mucho tiempo, todavía.


1 Lo del IVA fue otra buena, porque se puso "en duro", es decir, que para añadir los nuevos IVAs tuve que cambiar varias fórmulas matemáticas y comprobaciones en un buen número de archivos.  Evidentemente también rechazaron mi propuesta de guardar los impuestos en la base de datos para poder añadirlos y eliminarlos a gusto sin tener que cambiar ninguna fórmula;  recuerdo perfectamente que me dijo que no porque, total, era muy poco probable que cambiaran los impuestos.

Etiquetas: PHP

Categorías: Artículos, Programación

Ágora 1.2

Y aquí llega otra preocupación que quitarme de encima.

Como ya dije, al desarrollar el gestor de descargas hice algunas mejoras a Ágora, y hoy he terminado con la documentación y el empaquetado.

Los cambios son pocos: alguna mejora en el módulo de bases de datos y un módulo para gestionar en un único punto los parámetros GET y POST y las huellas o cookies. También he releído toda la documentación y he ampliado algunas partes.

Los interesados, ya saben, pueden obtener la nueva versión la página del proyecto.

Etiquetas: PHP

Categorías: Ágora, Programación, Proyectos, Web