Profesor, estoy desarrollando aplicaciones usando PostgreSQL, PGSQL, PostgREST para el API y PG Websockets. Sin embargo, no logro definir una estructura de archivos y directorios óptima para administrar mi código. ¿Qué herramientas o frameworks me recomienda para desarrollar con estás tecnologías?
Edito con `vim` en un terminal. Rara vez con `gvim`.
Usamos `git` para el control de versiones. Prefiero usarlo desde la línea de comandos, o desde `vim` usando el plugin `fugitive`. Tengo instalado `giggle` para cuando el análisis no cabe en un terminal, cosa infrecuente.
Todos los elementos de base de datos están en un directorio `db`. Allí están scripts SQL separados para extensiones, tipos, tablas, funciones, triggers, vistas, índices y constraints. Para PostgREST conviene tener esquemas, así que tenemos subdirectorios bajo `db` con la misma estructura.
Las pruebas de los componentes de base de datos están escritas usando PG TAP. Eso implica que las pruebas están en scripts SQL separados bajo un directorio `t/` de modo que pueda usar `prove` (provisto por Perl) para ejecutarlas individualmente o en masa.
Un `Makefile` para crear la base de datos en blanco, llenarla con los datos iniciales, llenarla con datos de prueba, y correr las pruebas. Cada uno como un objetivo diferente, con un objetivo principal que lo hace todo.
No tengo nada con PG Websockets, pero probablemente lo atendería como una combinación de pruebas de PG TAP y el infatigable Test::WWW::Mechanize de Perl, para engancharlo con `prove`.
Eso es lo que uso y no hay ninguna colección de botones y menúes que me resulten más interesantes. Tampoco se si es óptima, pero es lo que mejores resultados nos ha redituado.
Herramientas sencillas conectadas de manera clara. Políticas separadas de mecanismos. Interfaces separadas de implantaciones. Esa transparencia y simplicidad, conduce a su robustez. Y cuando hace falta, es mejor escribir un programa que genere los programas, que escribir cada programa a mano.
For that is the Unix way.
Usamos `git` para el control de versiones. Prefiero usarlo desde la línea de comandos, o desde `vim` usando el plugin `fugitive`. Tengo instalado `giggle` para cuando el análisis no cabe en un terminal, cosa infrecuente.
Todos los elementos de base de datos están en un directorio `db`. Allí están scripts SQL separados para extensiones, tipos, tablas, funciones, triggers, vistas, índices y constraints. Para PostgREST conviene tener esquemas, así que tenemos subdirectorios bajo `db` con la misma estructura.
Las pruebas de los componentes de base de datos están escritas usando PG TAP. Eso implica que las pruebas están en scripts SQL separados bajo un directorio `t/` de modo que pueda usar `prove` (provisto por Perl) para ejecutarlas individualmente o en masa.
Un `Makefile` para crear la base de datos en blanco, llenarla con los datos iniciales, llenarla con datos de prueba, y correr las pruebas. Cada uno como un objetivo diferente, con un objetivo principal que lo hace todo.
No tengo nada con PG Websockets, pero probablemente lo atendería como una combinación de pruebas de PG TAP y el infatigable Test::WWW::Mechanize de Perl, para engancharlo con `prove`.
Eso es lo que uso y no hay ninguna colección de botones y menúes que me resulten más interesantes. Tampoco se si es óptima, pero es lo que mejores resultados nos ha redituado.
Herramientas sencillas conectadas de manera clara. Políticas separadas de mecanismos. Interfaces separadas de implantaciones. Esa transparencia y simplicidad, conduce a su robustez. Y cuando hace falta, es mejor escribir un programa que genere los programas, que escribir cada programa a mano.
For that is the Unix way.
Liked by:
Carlos Torres
