Por último, pero DEFINITIVAMENTE no menos importante, para redondear nuestros 10 elementos principales para incluir en tu próximo proyecto de Oracle APEX es una auditoría de seguridad. Hay una serie de amenazas comunes para cualquier aplicación web moderna que puede poner en grave riesgo tus datos y los datos y privacidad de tus usuarios. Es posible que te interese obtener más información sobre el documento de los 10 OWASP ( https://owasp.org/www-project-top-ten/ ) principales que representa un amplio consenso sobre los riesgos de seguridad actuales más críticos para las aplicaciones web. Los desarrolladores deben comprender los conceptos básicos sobre cómo proteger sus aplicaciones Oracle APEX, pero también hay una serie de herramientas disponibles que resaltarán las fallas y los riesgos potenciales. Los desarrolladores siempre deben ejecutar el APEX Advisor en sus aplicaciones y, aún mejor, aprovechar herramientas como APEX Sert ( https://github.com/OraOpenSource/apex-sert ) o APEX

Muchas veces, las columnas de auditoría de las tablas serán suficientes. ¿Cuándo se creó el registro y por quién? ¿Quién lo actualizó por última vez y cuándo? Pero cuando las columnas de auditoría no son suficientes y se necesita un seguimiento detallado de los cambios, incluidos los valores antiguos y nuevos para todos los cambios, se deberá decidir una estrategia de auditoría. Lo bueno es que hay muchas opciones excelentes disponibles que probablemente brinden las capacidades de auditoría que se necesiten.  Puedes utilizar Flashback Data Archive ( https://oracle-base.com/articles/12c/flashback-data-archive-fda-enhancements-12cr1 ) que es compatible con Oracle y se ajusta automáticamente a los cambios en las tablas.  Cuando no puedas utilizar FDA, Connor McDonal tiene un activador de auditoría / generador de paquetes para tablas de Oracle ( https://github.com/connormcd/audit_utility ) que es muy interesante. El SQL Developer Data Modeler también ofrece funcionalidad de registro en d

Decide con anticipación como manejarás los errores en tu aplicación y como instrumentarás su código.  No existe una sola forma correcta de hacer esto, pero debes asegurarte de decidir cómo manejarás los diferentes tipos de errores que pueden suceder ( y sucederán ) en tus aplicaciones de producción. Junto a varios equipos APEX he incorporado una metodología para la creación de métodos y gestión de errores mediante validación junto  con asistencia  d el paquete APEX_DEBUG. Esta metodología se basa en una adaptación del patron MVC (Model - View - Controller), donde el controlador forma una parte fundamental para la validación y el mantenimiento de la consistencia. Una vez más, al igual que con muchos puntos enumerados anteriormente, es importante tomar una decisión para tu proyecto y manejar los errores con elegancia de tal manera a que los usuarios no se rasquen la cabeza para poder identificar claramente lo que salió mal y porqué. Esto es muy importante. Creditos: Esta serie se ha basa

Tener un conjunto de estándares de desarrollo de Oracle APEX y mejores prácticas a las que adherirse garantizará que se creen aplicaciones escalables, seguras y visualmente atractivas. En tal sentido, durante los años he definido un conjunto de estándares de codificación en Oracle APEX que me aseguro de que todos los desarrolladores sigan tanto como sea posible.  Por supuesto, cada proyecto es diferente, y si un cliente tiene estándares diferentes, trabajo con sus estándares, p ero, nuevamente, los estándares aseguran la consistencia en todo el equipo y entre varias aplicaciones, y te preparan para el éxito en los años venideros. Entre algunos ejemplos de estándares de desarrollo que en APEX pueden incluir se encuentran: • Incorporar a todas las páginas esquemas de autorización • Agregar texto de ayuda a todos los elementos • Asegurarse de que siempre se escapen los caracteres especiales ¿Quieres un buen comienzo para tus propios estándares? Pues echa un vistazo a la publicación

Al planificar tu proyecto, asegúrate de incluir pruebas unitarias y de regresión de tu código SQL y PL/SQL. Incorpora esto en la línea de tiempo de tu proyecto y establece las expectativas del cliente en torno a él. Aquí hay algunas opciones a considerar para las pruebas de SQL y PL/SQL. 1. UtPLSQL ( http://utplsql.org/ ) es el mejor y más popular marco de trabajo de código abierto para probar el código de la base de datos Oracle 2. Pruebas unitarias de SQL Developer ( https://docs.oracle.com/cd/E15846_01/doc.21/e15222/unit_testing.htm#RPTUG45000 ). No es tan potente como utPLSQL, pero está integrado en la IDE 3. Pruebas ad-hoc, lo que significa que no tienes ningún script de prueba que puedas ejecutar según sea necesario. En su lugar, ejecutas scripts y consultas para verificar que los casos de uso esperados se realicen correctamente. 4. Puedes usar un arnés de prueba hecho a medida, esto es un marco que contenga scripts para ejecutar pruebas, recopilar resultados, compararlos

Aunque APEX es una plataforma de desarrollo de bajo código, rara vez nos salimos con la nuestra con proyectos que no involucren al menos algo de código. Muchos, de hecho, involucran MUCHO código y lo más probable es que el tuyo también lo haga. El código SQL y PL/SQL es fundamentalmente uno de los códigos más importantes que escribo para mis clientes y socios. La diferencia entre un SQL y PL/SQL que funciona bien y otro que no funciona puede ser la diferencia entre un sistema exitoso y una gran decepción. Ya sea que te guste tu código en minúsculas o mayúsculas o prefieras los nombres de tus tablas en singular o plural, o tengas preferencias particulares sobre el formato del código, es importante tener estándares que estén documentados e implementados en tu base de código. Mis estándares de codificación SQL y PL/SQL están adaptados de trivadis ( https://trivadis.github.io/plsql-and-sql-coding-guidelines/v4.3/ ) y, sean cuales sean tus estándares, asegúrate de comunicarlos bien a todo t

DevOps es un conjunto de prácticas para compilar, probar y publicar su código en pasos pequeños y frecuencias. Una de las prácticas principales de DevOps es una integración continua, que hace que los desarrolladores se comprometan con un repositorio compartido con frecuencia, a menudo a diario, una de esas herramientas en el repositorio de control de código fuente que hemos visto anteriormente. Los chicos de Insum han creado una metodología para implementaciones de Oracle APEX utilizando un proyecto en GitHub el cual recomiendo ampliamente y que puedes ver en el enlace que aparece a continuación https://github.com/insum-labs/starter-project-template Muchos pasos de las implementaciones que he realizado en Oracle APEX están automatizadas, esto permite aumentar la eficiencia del equipo y como resultado, mejora la velocidad y la estabilidad de las implementaciones. Creditos: Esta serie se ha basada en la publicación de INSUM, adaptada del ingles y con mis contribuciones adicionales. Pue

Recuerdo un evento en una época pasada en el cual uno de los presentadores preguntó a la audiencia cuántos de nosotros utilizábamos la base de datos como nuestro repositorio de código.  No me atreví a levantar la mano y mirando alrededor, vi que nadie lo hizo. El orador nos llamó mentirosos y al menos por mí, algo de razón tenía. Con el paso del tiempo he aprendido de este error. El control de código fuente es un sistema que te permite realizar un seguimiento de los cambios en tu código a lo largo del tiempo. Esto es importante por varias razones:  Permite retroceder en el tiempo y ver cómo ha cambiado su código.  Podemos realizar un seguimiento de quién realizó qué cambios y cuando.  Es posible fusionar el trabajo de varios desarrolladores Si estás utilizando una base de datos como control de fuente, definitivamente lo estás haciendo mal. Pero no te preocupes, no es necesario que levantes la mano. Algunas herramientas de control de fuente que puedes considera (y no es una lista exhaus

  “Nunca olvidaré porqué estoy escribiendo este fragmento de código”, estos son dichos que decimos como desarrolladores a lo largo de la historia para justificarnos y después de tratar de resolver el problema durante horas. Y es posible que realmente creas que estás diciendo la verdad, pero, hazme caso.. LO VAS A OLVIDAR Incluso, podrías encontrarte años después mirando ese código y preguntándote qué tonto podría haber escrito algo tan intrincado, antes de darte cuenta que oppps. ese fui yo…😬 La documentación técnica es fundamental en cualquier proyecto de desarrollo de software. La documentación proporciona una hoja de ruta para los desarrolladores que describe cómo debería funcionar el sistema y qué hace cada componente. Además, puede ser utilizado como referencia por los usuarios que necesitan comprender cómo funciona el sistema o solucionar problemas.  La documentación ayuda a garantizar que todas las partes interesadas tengan una comprensión común del sistema, lo que evita malos