Compartir:
){kind=small}
Actor de formación con una disertación sobre la comedia, llegué al desarrollo de PHP a través de la escena de las reuniones. Puedes encontrarme hablando y escribiendo sobre tecnología, o tocando/comprando discos raros de mi colección de vinilos.
PHP cumple 31 años y Vonage sigue de cerca el PHPVerse
Tiempo de lectura: 14 minutos
Es increíble pensar que en junio PHP cumplió 31 años. Desde sus orígenes como un lenguaje de scripting básico destinado a ayudar a un único desarrollador hasta convertirse en un gigante del código abierto en la web, ha sido todo un recorrido. Si tienes curiosidad por saber cuál es la situación actual de PHP y hacia dónde se dirige, este resumen te dará una idea bastante clara.
En mi trabajo diario, en el fondo sigo siendo desarrollador de PHP. Todo lo que creo, desde demostraciones hasta contribuciones al software libre, se ha centrado en el SDK de PHP de Vonage. Esto es algo fundamental para lo que hacemos; los lenguajes concretos y sus comunidades son es importante estar conectado a.
Tras mi entrevista con el director ejecutivo de la Fundación PHP, JetBrains anunció una nueva edición anual de PHPVerse, una conferencia de un día, exclusivamente en línea, dirigida a desarrolladores de PHP. Este año, al igual que el año pasado, contó con un cartel estelar de figuras habituales del mundo del código abierto que hablaron sobre diversos temas relacionados con la comunidad. En este artículo, voy a repasar la mitad de las charlas con algunos comentarios para que mantengas al día tus conocimientos de PHP o, si no eres desarrollador de PHP, puedas hacerte una idea de por qué sigue siendo tan popular. Próximamente publicaré la segunda parte.
Empecé mencionando la charla de Vonage con Elizabeth, así que probablemente tenga sentido comenzar con esta charla. Desde su creación, ha sido muy estimulante contar con una infraestructura de gobernanza de código abierto para PHP. La Fundación se ha incorporado a The Linux Foundation, ha recibido una importante inyección de fondos del Gobierno de Alemania y ahora cuenta con un equipo de desarrolladores internos, con salario completo, repartidos por todo el mundo.
Esta charla se centró en la dirección que ella ha dado a la Fundación desde sus inicios, en los planes que se están llevando a cabo y en sus reflexiones sobre el futuro. Por lo tanto, voy a desglosarlos en estas tres áreas.
Al principio, Elizabeth decidió escuchar. Esto supuso realizar muchísimas llamadas (unas 60, siendo el autor de este artículo una de ellas) para recabar las opiniones de los desarrolladores de PHP sobre la situación actual del lenguaje. La conclusión fue que había cuatro áreas diferentes que requerían atención:
· Transparencia
· La percepción de PHP fuera de nuestra comunidad
· La falta de nuevos promotores inmobiliarios para el crecimiento
· Aspectos internos y el proceso de votación
A raíz de estas conclusiones, se han puesto en marcha las siguientes iniciativas bajo el término genérico de «Grupos de Interés Especial» (SIG):
· Grupo de interés especial (SIG) del Equipo de Seguridad del Ecosistema
· Grupo de interés especial (SIG) del Programa de Embajadores de PHP
· Grupo de interés especial sobre la incorporación
· Grupo de interés especial sobre criptografía
· Grupo de interés especial sobre eventos comunitarios
· Grupo de interés especial sobre accesibilidad
Cualquier persona interesada en unirse a estos grupos puede informarse de cómo hacerlo en el blog de la Fundación PHP.
El mayor problema al que se enfrenta PHP es una problema de percepción , no técnico. Llegó a la conclusión de que el lenguaje es estable, la comunidad es numerosa y activa, así que hay motivos para estar optimistas.
Tras el anuncio realizado este año sobre la creación de un equipo de seguridad del ecosistema en la Fundación PHP, parece oportuno que Nils haya venido a hablar sobre la seguridad de la cadena de suministro. En los últimos cinco años hemos sido testigos de varios casos de gran repercusión, como el de XZ Utils, en el que un mantenedor malintencionado logró introducir una puerta trasera en los archivos tar de las versiones de XZ Utils, una herramienta utilizada en muchas de las principales distribuciones de Linux. También se ha producido un aumento de los ataques a máquinas locales, lo cual no es de extrañar, dado que las herramientas de IA y los entornos de desarrollo integrado (IDE) como VSCode y PHPStorm realizan ahora numerosas llamadas externas para escribir código. Estas herramientas también cuentan con mercados de complementos de código abierto, lo que hace que el acceso a los repositorios de GitHub sea uno de los ataques más comunes en la mayoría de los principales gestores de paquetes.
El modelo de publicación de Composer siempre ha tenido una ventaja estructural: cuando se etiqueta una versión en GitHub, Packagist registra una URL que apunta a la API de GitHub, la cual genera dinámicamente un archivo zip directamente a partir del código fuente.
El inconveniente es que estos archivos ZIP generados dinámicamente no son estables. Cambian con el tiempo, lo que significa que no se pueden firmar de forma segura. Aunque el archivo de bloqueo de Composer fija una confirmación para una etiqueta determinada, esto implica que, a efectos de auditoría de seguridad, los desarrolladores tienen que revisar minuciosamente los archivos de bloqueo. No sé si has trabajado en un proyecto grande, pero estos pueden llegar a ser enormes grandes. Sin embargo, Packagist (la empresa responsable de Composer) cuenta con una función de revisión de actualizaciones, por lo que existen herramientas que pueden facilitar un poco esta tarea.
Ya se han puesto en marcha una serie de medidas de seguridad para combatir los ataques a la cadena de suministro.
· Inmutabilidad de la versión estable
· El marco normativo sobre dependencias
· La opción de recurrir al código fuente si falla la descarga del archivo ZIP ahora está desactivada por defecto
· Escaneos automáticos de Aikido Security
· Registro de transparencia pública
· Control centralizado de la seguridad de la cartera de paquetes para proyectos de mayor envergadura, por ejemplo, Symfony
· Tiempo de recarga de la liberación, para permitir el escaneo automático
· Ventanas de preparación para la publicación
· Autenticación multifactorial (MFA) obligatoria
· Alojamiento de artefactos inmutables a cargo de Packagist, para aumentar la confianza en el gestor de paquetes
En primer lugar, hay varias medidas que puedes tomar ahora mismo para mejorar tu seguridad. Entre ellas se incluyen:
· Activación de la autenticación multifactorial (MFA)
· Utiliza herramientas como Zizmor para garantizar la seguridad del proceso de integración continua (CI)
· Asegúrate de que tienes instalado Composer 2.0
· Utiliza el alojamiento de Private Packagist para cumplir con requisitos de seguridad específicos.
Y lo que es más importante, los desarrolladores y las organizaciones pueden olvidarse de las estadísticas que hay detrás de algo que, en esencia, es gratuito. Packagist recibe 4.800 solicitudes por segundo, es el único gestor de paquetes PHP de facto y ofrece 450.000 paquetes que se instalan unas 4.000 millones de veces al mes. Aunque parte de la financiación para las funcionalidades procede de la Fundación PHP, es esencial que Packagist reciba los fondos necesarios para mantener esta infraestructura. Este mes se va a poner en marcha un programa de patrocinio oficial; si tu organización depende de esta infraestructura, es fundamental que reciba la financiación que necesita.
Quienes me conocen seguramente habrán notado que estoy en una especie de cruzada contra una famosa frase que la gente repite sin cesar y que es falsa. Si esto es cierto en el caso de PHP, es justo decir que a WordPress se le atribuyen exactamente las mismas opiniones infundadas. La cuestión es que no se puede seguir gestionando el 40 % de la web si no merece la pena utilizarlo.
Jonathan se centró en una serie de mitos que quería desmentir, así que aquí tienes diez mitos, ordenados de forma práctica, de los que habló.
Me sorprendió bastante descubrir que todas las nuevas instalaciones de WordPress utilizan PHP 8.3 y que ahora incluyen declaraciones de tipos, interfaces y espacios de nombres, tras un esfuerzo de modernización del código iniciado a partir de 2020.
Los temas de bloques ahora utilizan Block Markup, que es un lenguaje de plantillas basado en comentarios HTML. Las etiquetas PHP de antaño (¿alguien echa de menos aquellas páginas HTML repletas de código PHP entremezclado?) han desaparecido, así que sí: ahora sí que funciona.
Otra de las críticas que se han vertido sobre PHP en general en el pasado. WordPress cuenta ahora con el plugin «Performance Lab», que mide el rendimiento y mejora la velocidad. La carga especulativa se incorporó al núcleo de WordPress 6.8, lo que supuso un aumento del rendimiento del 98,2 %.
Ahora los bloques tienen estados independientes, lo que permite separar los ámbitos del front-end y del back-end. Se ha acabado el uso tradicional de the_post() y otros horrores similares que recuerdo de hace muchos, muchos años en WordPress
Con la introducción de la API Block Bindings ya no es necesario que los campos personalizados requieran, casi siempre, una serie de complementos de terceros para que funcionen.
Quizá Matt Mullenweg se marcó un pequeño gol en propia puerta con este comentario cuando el proyecto Gutenberg empezó a ponerse en marcha. Tras señalar que los desarrolladores tendrían que aprender JavaScript como una habilidad esencial, es posible que algunos desarrolladores de PHP se sintieran preocupados. Es decir, a mí me pasaría lo mismo, dado que siento un odio bastante irracional hacia React. Los desarrolladores que no quieran meterse en el frontend pueden utilizar la API de interactividad para lograrlo, de modo que la interacción se realice con bloques dinámicos.
Otro caso habitual: se han tomado muchas medidas para garantizar que los desarrolladores cuenten con las herramientas necesarias para que esto no ocurra. Se han implementado actualizaciones automáticas para plugins y temas, protección contra la reversión de cambios y el hash de contraseñas bcrypt, y el propio WordPress no presenta vulnerabilidades críticas sin parchear.
Aunque es cierto que WordPress no incluye de serie compatibilidad con Composer, el proyecto Roots Bedrock lo hace posible. El mismo equipo ha lanzado recientemente WP Packages, un repositorio de Composer que recoge todos los plugins y temas gratuitos de wordpress.org.
El ha estado muy ocupado, como demuestra el esfuerzo que han dedicado al blog para desarrolladores, con la publicación de tutoriales y la serie de Videos «Learn WordPress». El portal para desarrolladores se ha renovado por completo, por lo que ahora se tratan de forma exhaustiva los temas, los plugins, el editor de bloques y la API REST.
Es cierto que, en el pasado, WordPress contaba con su propio objeto Exception, WP_Error. Esta restricción se ha eliminado, por lo que los desarrolladores tienen libertad para crear su propio manejo de excepciones personalizado. El propio equipo del núcleo está debatiendo actualmente la posibilidad de eliminar WP_Error del código.
Al igual que los desarrolladores que podrían juzgar PHP basándose en la experiencia de hace 20 años, merece la pena plantearse volver a analizarlo. El hecho es que los desarrolladores modernos de WordPress utilizan herramientas como PHPStan, PHPUnit, Composer, etc., pero la comunidad en general simplemente no lo sabe. Desde este punto de vista, Jonathan lanza un reto a los desarrolladores de WordPress para que escriban sobre el desarrollo moderno en la plataforma, y a los que no son desarrolladores de WordPress para que le den otra oportunidad.
Symfony fue el primer framework de PHP que utilicé. De hecho, cuando impartía formación a medida, enseñaba a trabajar con Symfony 2. Desde entonces, el proyecto ha crecido enormemente. Fabien lleva más de 20 años al frente del proyecto.
¿Qué tareas de mantenimiento tiene que realizar Fabien? Pues bien, hay más de trescientos repositorios, con 5.000 versiones etiquetadas al año. El 25 % de todas las descargas de Composer Packagist proceden de Symfony (aunque Fabien se apresura a señalar que las descargas suelen ser una métrica un tanto engañosa debido a las descargas automáticas).
Un aspecto que me parece realmente interesante de Symfony es cómo está estructurado el framework: es, a la vez, un framework completo y una serie de componentes independientes. Gracias a este diseño, se utiliza como motor para otros proyectos de gran envergadura, como Joomla! y Drupal, pero también como componentes que utilizan proyectos como Laravel y Magento, todos ellos mencionados por Fabien.
Durante muchos años, al principio de mi carrera, se libró un acalorado debate entre los «microservicios» y el «monorepo». Curiosamente, Fabien nos cuenta que, justo al inicio de Symfony 2, tomó la decisión consciente de que todo se alojara en el mismo repositorio, bajo symfony/symfony. Una herramienta que él mismo creó, llamada Splitsh, se encarga de la instalación; esta herramienta escucha los webhooks de GitHub que, a continuación, descargan cualquier otro paquete solicitado durante la instalación bajo el espacio de nombres «symfony», incluyendo Symfony AI, Twig, Symfony UX y Symfony Console, por nombrar algunos. A estos se les denomina «sub-splits».
Fabien destaca cuatro áreas fundamentales que han llevado a Symfony a donde se encuentra hoy en día.
En primer lugar, la estabilidad dentro del equipo principal. Fabien al mando, 30 desarrolladores principales, muchos de ellos con una larga trayectoria.
A continuación, una marco de trabajo . Soy un gran, gran admirador de este enfoque, porque cuando tengo que trabajar en el mundo de Node, me siento constantemente abrumado por las muchas, muchas opciones que se pueden elegir a la hora de programar. Existe un estilo de código coherente («A la manera de Symfony ») y estándares abiertos (PSR).
Para tus clientes que dependen del marco, la coherencia es fundamental. Symfony tiene previsto lanzar dos versiones menores al año y una versión LTS cada dos años.
Por último, un tema que me interesa mucho debido al mantenimiento que tenemos que realizar en el SDK de PHP de Vonage: el versionado semántico. No puedo entender cómo lanzábamos software antes sin utilizar el versionado semántico.
Un aspecto complicado del mantenimiento de un proyecto de código abierto de este tamaño es que vas a necesitar los procesos adecuados y, por lo tanto, las herramientas adecuadas que te ayuden a lograrlo. Durante la mayor parte de la vida de Symfony, se han realizado muchos pasos de forma manual. Sin embargo, la IA ha cambiado esto.
Fabien ha creado agentes personalizados para gestionar la mayor parte de las tareas masivas y repetitivas. Entre ellas se incluye la labor de investigación que conllevan los conflictos de fusión complejos, sobre todo teniendo en cuenta que Symfony tiene que mantener actualmente seis ramas etiquetadas.
El proceso de lanzamiento en sí mismo lo gestiona ahora un agente PHP creado por el propio Fabien. Este agente recibe el comando de lanzamiento, pregunta de qué tipo de lanzamiento se trata, responde con un plan de lanzamiento que debe revisarse y, una vez recibida la confirmación, puede ejecutarlo. Incluso cuenta con una función añadida que permite generar borradores de entradas de blog para los lanzamientos.
Quizá sea por la rapidez a la que avanzamos en la era de la IA, pero no siempre se hablan tan abiertamente de los inconvenientes. Fabien nos cuenta que antes se sometían a un Audit de seguridad una vez al mes. Ahora reciben una al día. De hecho, hace poco lanzaron una versión de Symfony que corregía 50 vulnerabilidades comunes (CVE).
Este enorme volumen de actividad a un ritmo tan acelerado se debe a un único factor: los modelos de lenguaje grandes (LLM). La razón por la que afirmo que, en mi opinión, hay aspectos positivos y negativos es que el equipo de Symfony ahora se ve prácticamente obligado utilizar los LLM para corregir esta cantidad de código, ya que, si el equipo de Symfony no lo hace, alguien más encontrará una vulnerabilidad (CVE) mediante un LLM. La otra desventaja es tener que examinar las respuestas en busca de falsos positivos, pero, en general, supone un paso positivo que Fabien pretenda utilizar estas herramientas para lanzar versiones más seguras, en lugar de tener que aplicar parches a posteriori.
En esencia, Symfony no deja de crecer, y Fabien y el equipo principal han estado utilizando todas las herramientas a su alcance para mantenerse a la vanguardia de un framework de PHP que realiza algunas de las tareas más exigentes de todo el sector. Personalmente, he sido testigo de muchísimos cambios (creo que el lanzamiento de Symfony Flex coincidió más o menos con la época en que me pasé a otros frameworks) y he vuelto a encontrarme con una abrumadora variedad de funcionalidades acompañadas de una documentación excelente.
Hubo ocho charlas en total, así que no te pierdas la segunda ronda, en la que hablaré sobre IA con Ashley Hindle y Jeffrey Way, sobre Drupal con Mike Merchel y sobre las propuestas de cambio de especificación (RFC) de PHP con Larry Garfield.
¿Tiene alguna pregunta o quiere compartir lo que está construyendo?
Suscríbase al Boletín para desarrolladores
Síguenos en X (antes Twitter) para estar al día
Ver tutoriales en nuestro canal de YouTube
Conéctese con nosotros en la página Vonage Developer en LinkedIn
Ayúdanos a mejorar nuestra experiencia como desarrolladores rellenando nuestro cuestionario «La voz del desarrollador»
Mantente conectado y entérate de las últimas noticias, consejos y eventos para desarrolladores.
Compartir:
Actor de formación con una disertación sobre la comedia, llegué al desarrollo de PHP a través de la escena de las reuniones. Puedes encontrarme hablando y escribiendo sobre tecnología, o tocando/comprando discos raros de mi colección de vinilos.