Siguiendo con las herramientas de medición de la calidad del código fuente del post anterior, encontramos que tenemos disponible una alternativa a PHP Depend, que tiene funciones parecidas. Se trata de PHPLOC de Sebastian Bergmann, que te puede sacar unas métricas muy descriptivas en modo texto de todo un programa.
Es bien sencillo de usar y los resultados son bien descriptivos por si mismos. Vamos al grano..
Continuar leyendo..
Hay muchas herramientas para medir la calidad del código fuente. Una de estas es PHP Depend, que del mismo modo que JDepend para Java, analiza los códigos fuentes, y nos da una visión del estado del código sin entrar al detalle.
Este es un pequeño HOWTO para instalarlo en un proyecto y empezar a usar esta herramienta.
Continuar leyendo..
Aquí puedes encontrar un howto o codekata en PHP, en el que se comparan algunos algoritmos de recorridos de grafos. Este post es continuación del post anterior sobre el algoritmo general de recorrido en grafos.
A partir del algoritmo general, tenemos derivados cuatro algoritmos más. Dos de estos algoritmos son de los básicos, y dos aplican técnicas heurísticas. Los heurísticos tratan de predecir qué camino usar primero para alcanzar antes el nodo meta.
Continuar leyendo..
Ando poniéndome al día de nuevo, con este howto o codekata, mientras que les comparto en este post sobre estas joyas de la informática. Se trata de Browser-sync y de Gulp, herramientas para desarrollar localmente más rápido páginas web.
Con Browser-sync nos evitamos el continuo F5 para refrescar los navegadores con cada cambio mientras que trabajamos, además de que podemos probar en múltiples dispositivos las páginas web mientras que vamos construyendo. Y además con Gulp, podemos tener programadas una serie de rutinas de trabajo, como combinar hojas de estilo, ficheros JavaScript, minificarlos, etc.. para así poder trabajar también más rápido y mejor.
No he encontrado por Internet un howto para Gulp 4, así que aquí estoy compartiéndolo mientras que he conseguido hacerlo funcionar. Con este howto, queda programado en Gulp el lanzamiento de Browser-sync, junto con unas rutinas básicas de JavaScript y CSS, para un entorno básico de página web.
Continuar leyendo..
¡Hola de nuevo! Dejo aquí un Shell Script de ayuda para preparar los ficheros de publicación para cada nueva versión de un plugin para WordPress. La idea es que estamos trabajando en un plugin en una instalación de WordPress. Por defecto en WordPress los plugins estarán en el directorio /wp-content/plugins/slug-de-tu-plugin/ y tendremos que preparar los ficheros antes de subirlos al repositorio de Subversion y publicarlos así en la comunidad de plugins para WordPress.
Este preparar los ficheros se puede hacer manualmente. Pero con cada nueva versión se puede volver tedioso, aburrido, el volver a generar la estructura. Así que si ya tenemos revisado y aceptado el publicar un plugin, podemos usar este Shell Script para ir publicando nuevas versiones.
Continuar leyendo..
Dejo aquí un howto sobre este sistema de control de versiones. Un sistema de control de versiones es una herramienta de trabajo para gestionar las modificaciones que se hacen en el software a lo largo del tiempo. Apache Subversion, cuya abreviatura es SVN, se lanzó en el año 2000 y desde entonces ha habido muchas aplicaciones en las que se ha utilizado.
En este post puedes encontrar un resumen de los principales comandos que hace falta usar para empezar a trabajar con subversion.
Continuar leyendo..
Hoy traigo esta herramienta de AWS que me ha impresionado después de un tiempo probándola. Cloud9 es un entorno de desarrollo integrado, un IDE, que funciona sobre la web en un navegador. No necesitas instalarte nada en tu ordenador. Cloud9 usa el editor de código fuente Ace adquirido por Amazon Web Services en 2016, que está escrito en JavaScript, y sólo necesita acceso SSH al servidor donde quieras trabajar.
Es decir, con este entorno de desarrollo podemos programar directamente en un navegador. No tenemos que instalarnos localmente ningún IDE, ni bajar los códigos fuentes de la nube, base de datos, etc.. Todo, absolutamente todo el entorno de desarrollo puede correr sobre servidores en una nube, con lo que esto conlleva.
Continuar leyendo..
JavaScript es uno de los lenguajes de programación más populares. Se pueden hacer aplicaciones para webs, de escritorio, para móviles, aplicaciones de servidor como microservicios o también aplicaciones de consola. Es un lenguaje de programación interpretado, no compilado, te permite OOP, y aunque sea imperativo, también permite la programación funcional.
Con todas estas cosas, a fecha de hoy, podemos programar en JavaScript fuera de los navegadores gracias al entorno de ejecución de Node.js. Viene a ser lo mismo que el JRE para Java, el runtime de PHP, o el CLR del .NET framework.. pero en este caso es para JavaScript. Este post es un sencillo howto o codekata para comenzar a usarlo.
Continuar leyendo..
Dejo aquí un pequeño howto o codekata para configurar un despliegue manual de una aplicación mediante Git. Con este codekata se instala el repositorio en un directorio, mientras que los ficheros de trabajo que finalmente corren la aplicación estarán en otro directorio diferente. Internamente los sistemas de despliegue automatizado usan configuraciones de este estilo para hacer lo que se llama Continuous Deployment (CD).
Para este post sólo se trabaja la forma manual de hacer el despliegue. Que si quisieras, podrás automatizarlo añadiendo luego webhooks a tu repositorio, y recibir estos webhooks para lanzar este despliegue.
Suponiendo que queremos poner la aplicación y repositorio en el mismo directorio, vamos al directorio y podemos ejecutar lo siguiente:
git --work-tree=./la_app/ clone git@servidor-de-repos.com:ruta/al/repo.git el_repoSi estamos en el directorio /ruta/al/directorio/ entonces se crearán los siguientes directorio:
No tienen que existir los directorios para que Git pueda crearlos.
cd /ruta/al/directorio/el_repo/
git checkout master
git fetch --all
git reset --hard origin/master
# aquí otros comandos especiales de tu app como borrar cachés, archivos temporales, etc..
Hoy les traigo otro tutorial sobre Symfony. Siguiendo con la serie de tutoriales de iniciación a Symfony, hoy llegamos a cómo hacer un programa que navegue por las páginas web en Symfony. Es decir, los fundamentos de cómo utilizar el DomCrawler, el BrowserKit y el CssSelector de Symfony.
Esto puede servir para dos cosas. La primera utilidad es para comprobar que el proyecto en el que estamos trabajando funciona como debe ser. Podemos automatizar pruebas funcionales navegando por el proyecto, comprobando que los resultados son los esperados, mientras que desarrollamos y antes de que llegue a producción ningún fallo. La segunda utilidad es para navegar por páginas web remotas que estén en servidores remotos, no en local. Quizá necesitamos hacer comprobaciones en producción, o puede que necesitemos obtener contenidos, información relevante, o ficheros remotos alojados en páginas web mediante el protocolo HTTP que necesitemos recoger por alguna razón. Es decir, la segunda utilidad es para conectar tu proyecto con sistemas informaticos remotos mediante el protocolo HTTP.
Continuar leyendo..
Siguiendo con la puesta al día que llevo con Symfony y Flex, llegamos a los eventos. Engancharnos a los eventos es una forma de editar el comportamiento natural de los proyectos Symfony. En el proceso de una petición HTTP al servidor, en Symfony ocurren muchas cosas. Durante ese proceso, se van ejecutando una serie de tareas en orden. A la vez que se procesan esas tareas, se van disparando una serie de señales. Estan señales definen los eventos. Y a su vez podemos engancharnos a estas señales para personalizar el funcionamiento de la aplicación web.
Es decir, cuando un navegador hace una petición a un proyecto web Symfony, éste la recibe con el fichero public/index.php y comienza la ejecución de todo el framework junto con todo lo que hayamos construido, además de todos los componentes extra que le hayamos instalado. Ésta ejecución se hace en perfecta armonía, es una buena forma de comunicar componentes de Symfony entre sí, con los nuevos componentes que hayamos instalado, o para personalizar el comportamiento de nuestra aplicación.
Continuar leyendo..
Hoy traigo un pequeño CODEKATA sobre una consulta que me ha hecho un lector. Se trata de unos códigos fuentes en Symfony 4 para subir ficheros al servidor, pero sin usar ningún componente extra en el proyecto.
Se trata de unas pocas modificaciones que le he hecho al código fuente de ejemplo de la documentación oficial. Así el código dejará de chequear la extensión, el mime type del fichero, y además de que no renombra los ficheros con un identificador único. Esto puede tener doble filo porque puedes acabar machacando los ficheros en nuevas subidas, pero siempre se le puede añadir después la lógica necesaria para comprobar si el fichero ya existía.. 😉
Continuar leyendo..
