Desde hace un par de años, se libera una versión de PHP cada año y por lo tengo para estar al día, es recomendable estar actualizando el código para que sea compatible con futuras versiones. Si utilizas alguna herramienta de contenedores como Docker y tienes tu stack armado allí tarde o temprano tienes que cambiar de versión. Pero si usas PHP en laradock, el proceso es muy fácil como puedes ver.

Cambio de versión de PHP en laradock

El primer paso es ir a la carpeta raíz de Laradock y buscar el archivo de variables de entorno llamado .env. Ábrelo con tu editor de textos favorito y buscar la variable de entorno denominada PHP_VERSION y escribir la versión deseada, por ejemplo:

PHP_VERSION=8.2

Reconstruir imágenes

Luego debes volver a construir los contenedores de php-fpm que es el que procesa el código PHP en laradock y el de workspace para poder ejecutar scripts de PHP como composer, phpcs, entre otros.

docker-compose build php-fpm
docker-compose build workspace

Luego para que los cambios tomen efecto, debes reiniciar los contenedores. En mi caso como uso un stack LAMP sería:

docker-compose down
docker-compose up -d nginx mariadb phpmyadmin workspace

Comprobar que la versión de PHP en laradock es correcta

Y finalmente ya todo debería estar en la versión definida. Para comprobar, puedes crear un archivo .php con la función php_info() por dentro para imprimir todos los datos de la versión. Para el caso del workspace puedes ejecutar: php –version y ver la versión instalada.

Finalmente, espero que te sirva y puedas usar PHP en laradock con la versión que desees. Si necesitas volver a la versión anterior, simplemente edita de nuevo el archivo .env y comienza de nuevo.

La entrada Cambiar la versión de PHP en Laradock se publicó primero en El blog de Skatox.

Hace unas semanas empecé usar JAMStack para rehacer mi sitio profesional usando tecnologías mas nuevas (el stack original tenía 11 años pero es tema de otro artículo). Al investigar decidí usar Hugo y me enteré de la HugoConf. Por lo que envié una propuesta de mi experiencia y fui aceptado a participar en ella.

Afiche de la HugoConf 2022 de la charla de la experiencia de usar JAMStack con Hugo viniendo de un entorno LAM
Mi charla del HugoConf 2022

Mi camino desde el stack LAMP hasta JAMStack con Hugo

Esta presentación es un tema totalmente nuevo. Decidí enfocar mi experiencia de hacer mi primer sitio web con Hugo viniendo de muchos años de hacer sitios con PHP/MySQL y con WordPress (es decir, con o sin CMS). En ella les comento como es el proceso para elegir un generador de contenidos, porqué usé Hugo, las características y herramientas que provee Hugo, como empezar a hacer sitios, ventajas y como hacer optimizaciones del sitio para que cargue muy rápido.

Te recomiendo verla a continuación si deseas conocer como es eso de crear sitios web estáticos y deseas conocer como comenzar:

YouTube Video

Mi charla en el HugoConf 2022

Mi experiencia en la HugoConf 2002

Fue excelente evento totalmente virtual. Como estaba empezando a usar Hugo fue interesante ver todo lo que puedes hacer con este generador de contenido estático. Y por la misma razón me sentía un poco intimidado por mi charla porque pensé que era la de menos nivel. Pero la receptividad fue muy buena, se generaron varias preguntas y tuve comentarios muy positivos de esa experiencia. Me motivó a seguirla dictando o crear nuevo contenido similar.

Palabras finales

Espero que te haya gustado la presentación. Si vienes un entorno LAMP (Linux Apache MySQL y PHP) estos consejos te ayudarán a iniciarte en el mundo de JAMStack. Pronto haré un artículo con mas detalles sobre la experiencia de usar Hugo para rehacer mi sitio profesional y obteniendo mejores resultados.

La entrada Mi charla de la HugoConf 2022: migrar a JAMStack viniendo de un entorno LAMP se publicó primero en El blog de Skatox.

Hace unas semanas tuve la oportunidad de participar en una edición de FullStapps. Una comunidad para hacer crecer a desarrolladores brindando contenido de alta calidad. En ese episodio fui entrevistado por el Ing. Henry Bravo para hablar principalmente de 3 temas:

  • WebAssembly: breve introducción sobre esta gran tecnología que nos permite ejecutar aplicaciones de alto rendimiento en la web; qué es eso y para que sirve en tus aplicaciones.
  • ¿PHP ha muerto? Comento sobre cómo el lenguaje esta muy vivo, es usado ampliamente y tiene gran oferta laboral. Desmiento algunos mitos y por qué puedes aprender este lenguaje en el 2001.
  • ¿Universidad? Mi opinión sobre si debes estudiar una carrera de Ingeniería de la computación, informática o sistemas.

También comento de otros temas y un poco de mí. Por lo que te invito a escuchar o ver el episodio.

Episodio de Fullstapps

Así que si la quieres ver, a continuación puedes ver el episodio de Fullstapps donde tuve la oportunidad de participar y compartir conocimientos. Fue una excelente experiencia y la entrevista la sentí diferente a las démas. El hecho de hablar sobre varios temas me gustó.

Si les gustó no duden en compartirlo en redes sociales y suscribirse a FullStapps para que crezcan como desarrolladores. Si tienes algún comentario que añadir, expresar un desacuerdo o solicitar mas información, no dejes de comentar al final de la entrada.

La entrada Mi participación en Fullstapps se publicó primero en El blog de Skatox.

Desde que trabajo de manera independiente he tenido que ser más paciente e incisivo sobre las preferencias de los clientes, sobre todo cuando hay diseño gráfico involucrado, la mayoría de las veces no saben por cual muestra decidirse o escogen la que menos me gusta, irónico pero cierto. Aveces llega lo que defino como “clientes celestiales” estos ya saben lo que quieren, tienen bastante tiempo con el concepto en su cabeza y son muy decididos, la mayoría del tiempo ya poseen algunas muestras de lo que quieren o intentos hechos por otros freelancers que han fallado en completar el proyecto.

Hace semanas me contactaron para diseñar/desarrollar un sitio web completo, lastimosamente no puedo divulgar mucho sobre la finalidad del mismo, solo puedo decir que si todo va bien podría ser Trend Topic en twitter muy pronto, lo curioso es que fue uno de esos “clientes celestiales”, decidido y bien centrado en lo que quiere, tan atento que me proporciono algunas plantillas a modo de inspiración, estas plantillas para WordPress las había descargado de un sitio famoso, lo mejor de todo es que como el refirió, la plantilla “es gratis”.

Luego de examinar la plantilla en cuestión, me encontré con una linea bastante “diferente”, check this out:

La linea que me llamo la atención
Linea malvada!


WTF!, eso no parece un código común de una plantilla de WordPress, luego de decodificar varias veces esa linea me encuentro con esto:

Código Verdadero
Lo que escondia la linea en base64


Examinando el código observamos que no es tan grave, no están tratando de explotar una vulnerabilidad o algo parecido, solo están colocando publicidad, pero creo que a mi cliente no le hubiese gustado tener esa publicidad en su sitio. Moraleja… no todo lo gratis es bueno, siempre debemos al menos pasarle un antivirus al contenido que descargamos por la web, saludos.

La manera más facil y efectiva de manejar las fechas cuando estas desarrollando una aplicación (en este caso usando PHP) es usar fechas en formato “UNIX timestamp“. Podemos definir a las fechas en formato UNIX timestamp como la cantidad de segundos que han pasado desde 1 Enero, 1970 a las 00:00:00 GMT, lo que nos permite facilmente ejecutar calculos para transformar valores de fecha y tiempo.

Pero este formato no es perfecto, tiene características que pueden afectar tanto su uso como el funcionamiento, una de ellas es que no es leible por humanos normales (a menos de que seas Sheldon Cooper), por ejemplo si me preguntaras ¿Qué día es hoy? y te respondo 1309666385 ¿Estarías en capacidad de interpretar el numero y obtener la fecha en que necesitas?, seriamente lo dudo.

El otro inconveniente es que este formato solo puede usarse en un rango limitado dependiendo del Sistema Operativo. En sistemas basados en GNU/Linux puedes retroceder hasta el año 1902 y avanzar hasta el año 2037. En Windows el limite menor es “Enero 1, 1970” debido al tamaño del numero en UNIX timestamp. Cualquier Sistema Operativo puede manejar enteros hasta un tamaño especifico (2 levado a la 32, o 4.249.967.296 para 32 bits) despues de esta cifra se necesita más trabajo para manejar numeros grandes. Por materia de eficiencia este “maximo” es impuesto para valores importantes como horas y fechas. Linux permite tener valores negativos para ambos y por ende puedes obtener fechas anteriores al limite menor. Algunos se preocupan por estos limites, inclusive acuñan al problema como un segundo Y2K, yo tengo la confianza de que para el 2038 ya todos los Sistemas Operativos de 32 bits habran sido reemplazados y no esto no será un problema.

Lo anterior deberia preocuparte si estas pensando desarrollar una aplicación que necesite planificar tanto para el futuro como para el pasado o que simplemente permita el registro de personas donde uno de sus campos sea la fecha de nacimiento, pero para todo existe una solución. Existe otra razón para estar pendientes y es debido a la presentación de las fechas en numeros enteros, por ejemplo si tenemos la fecha Enero 2, 1970 en formato UNIX sera mucho mas corta en digitos que Mayo 13, 2009. Si vas a almacenar fechas o horas en formato UNIX timestamp en una base de datos asegúrate de que el campo tenga una longitud de 10 digitos y eso bastara para almacenar fechas lo suficientemente largas para mantener tu sistema ejecutandose unos cuantos años.

MySQL tiene su propio formato de timestamps y es mas sencillo de usar, su formato es “YYYY-MM-DD HH:MM:SS” y normalmente es almacenado en su propio tipo de columna llamado “datetime”. Si necesitamos usar comparaciones y ordenamiento simple este formato funciona muy bien usando las funciones internas del RDBMS; adicionalmente tienen la ventaja de ser legible por humanos y su longitud es predecible lo que lo hace más fácil para validar, pero si necesitamos que nuestra aplicación sea flexible a la hora de cambiar de manejador de base de datos y no dependa tanto de funciones internas de MySQL es preferible usar UNIX timestamps.

A la hora de hacer operaciones complicadas relacionadas con fechas u horas terminaras convirtiendo todo a UNIX timestamps, haciendo tantas conversiones manejando grandes porciones de datos probablemente caigas en el uso excesivo de recursos de Hardware altamente valiosos que pueden aminorar la velocidad de tu aplicación. Yo era estricto al usar MySQL timestamps y casi todas mis aplicaciones “viejas” las usan pero luego de estudiar más el tema comprendí la ventaja de usar UNIX timestamps.

La epifania llega al momento de hacer operaciones con intervalos de tiempo, es mucho mas facil usar UNIX timestamps a la hora de hacer ordenamiento, adiciones, substraciones y comparaciones entre dos fechas, ayuda a mantener consultas mas simples y a no comprometer la compatibilidad de tu aplicación si Oracle decide cambiar alguna funcionalidad de MySQL. En PHP tal facilidad viene de mano de la función “mktime()” que nos permite construir Unix timestamps usando segundos, minutos, horas, meses, dias y años de la fecha/hora necesaria. Imaginandonos que tenemos un sistema con millones de usuarios (Facebook, twitter, etc.) y donde cada bit de información es importante yo seguiria usando UNIX timestamps dado a que los campos “date” y “datetime” ocupan más espacio que uno “INT(10)”, quizas les paresca descabellado pero cuando tenemos 500 millones de usuarios cada bit (termina acumulandose y formando petabytes) de información que se almacena o se transmite a traves de DataCenters localizados en distintas partes del mundo es muy importante que esa data sea la más depurada y liviana posible, tal principio parece innecesario para una pequeña aplicación, pero su uso ahora puede ser un salvavidas mañana.

Finalmente es tema de opinion, MySQL también ha incluido funciones internas que hacen el manejo de UNIX timestamps más sencillo y flexible, eres libre de estudiar el tema y opinar al respecto en la sección de comentarios. Saludos.

Como siempre hay amigos, familia, amigos de la familia, entusiastas del SL y de la Programación que encuentran mi correo por internet o me conocen por referencia y aprovechan la oportunidad para hacerme preguntas sobre temas diversos, en esta oportunidad 3 personas diferentes que estan comenzando a programar en PHP y estan estudiando el paradigma de la Programación Orientada a Objetos se han estado confundiendo mucho con las definiciones de Clases Abastractas e Interfaces proporcionadas en la documentación oficial de php.net y esta publicación es un intento para diluir esas dudas adicionalmente aprovecho esta oportunidad para disculparme con ellos pues prometí escalercer las dudas antes, pero esta semana los problemas terrenales me alcanzaron y tuve que lidiar con las diligencias/molestias/atenciones que conlleva una operación de emergencia, dando gracias porque todo salio bien y no hubo inconvenientes mayores.

¿Qué son las Clases Abstractas?

Las clases abstractas son clases normales con super poderes capacidades especiales, dado a que sus propiedades y metodos que pueden ser implementados o no dependiendo a las reglas del juego, pero, como sucede esto?, no hay mejor manera de explicarlo que con un ejemplo extraido de la documentación de php.net


class Fruta {
private $color;

public function comer() {
//Masticar
}

public function setColor($c) {
$this->color = $c;
}
}

class Manzana extends Fruta {
public function comer() {
//Masticar hasta llegar al Centro
}
}

class Naranja extends Fruta {
public function comer() {
//Pelar la Naranja
//Masticar
}
}

Instanciamos la clase, es decir, te doy una manzana y tu te la comes.


$manzana = new Manzana();
$manzana->comer();

Al finalizar el metodo “comer()”, podrías decir a que te supo la fruta, la respuesta sería a Manzana pues fue lo que te di y si te diera una fruta de manera generica…


$fruta = new Fruta();
$fruta->comer();

A que te supo la fruta?, no tiene mucho sentido ya que no deberias haber podido comerte la fruta pues no deberia funcionar de esa manera, en algun punto deberia de existir una restricción en la implementación de metodos y propiedades, por eso es que deberia declarar la Clase Fruta como abstracta y a su vez el metodo “comer()” que esta contiene.

Ejemplo:


abstract class Fruta {
private $color;

abstract public function comer()

public function setColor($c) {
$this->color = $c;
}
}

¿Que son las Interfaces?

Pensemos en las interfaces como declaraciones de metodos que objetos en comun pueden compartir, inclusive si esos objetos no guardan relación ninguna. Digamos que tenemos una serie de objetos que mediante la herencia no pueden conectarse o no pueden heredar metodos de un objeto padre ya que no tendria sentido, aqui es donde la interfaz juega un papel muy importante, por supuesto no hay mejor manera de explicar esto que con un ejemplo:


interface interaccion {
public function encender() {
//Procedimiento para encender
}

public function apagar() {
//Procedimiento para apagar
}
}

class lampara implements interaccion {
//Heredada de la Interfaz
public function encender() {
}
//Heredada de la Interfaz
public function apagar() {
}
}

class automobil implements interaccion {
//Heredada de la Interfaz
public function encender() {
}
//Heredada de la Interfaz
public function apagar() {
}
}

Espero que los ejemplos hallan sido suficientes para lograr su comprensión sobre el tema y en palabras finales podemos resumir que la diferencia entre las clases abstractas y las interfaces es que cada una se utiliza para disgregar y discernir limites en la estructura de la aplicacion que se quiere construir usando el paradigma de “Programación Orientada a Objeos”. Las interfaces nos permiten compartir comportamientos entre objetos no relacionados mientras que las clases abstractas nos permiten limitar y/o definir con precisión las capacidades de cada objeto.