 Bueno, paso ahora a presentaros a Carlos Longarela. Carlos es desarrollador backend desde finales de los años 90. Comenzó con ASP, pero pronto le convencieron las bondades de PHP. Reconoce que WordPress es base para la mayoría de sus desarrollos. El título de su charla es Mi Timeline programando desde el Notepad a la Nube. Os dejo con él. Hola, hola a todos, gracias. Como dijo Lua, mi nombre es Carlos Longarela. Y lo que os voy a contar es mi ciclo desde que empecé a desarrollar, a programar, lo que hacía antes, como lo hacía antes, y más o menos como ha ido evolucionando, como lo hago ahora. Como indica el título, empecé a finales de los 90 con el blog de notas, con el Notepad. Literalmente. No es una frase, decir tal, pero grabábamos con este blog de notas que era simplemente el fondo blanco con el texto negro ese que veis. Más de uno aquí quizá lo haya utilizado en aquellos años. Y no teníamos ninguna ayuda, no teníamos nada como natalidad. Entonces vamos a ir viendo estos cambios desde aquella época hasta lo que se hace ahora o como lo hago yo en mi caso. Es decir, cada uno tendrá su propio flujo de trabajo. Ahora la evolución es que tenemos todo esto y muchísimo más que esto. Tenemos diversas librerías, utilizamos PHP, JQuery, HTML, tenemos Ansible Engines, tenemos multitud de herramientas y de tecnologías. Algunos timelines de nuestras líneas de tiempo han cambiado a lo largo de los años, tanto en la programación como personalmente. Tenemos, por ejemplo, este señor que tenéis aquí, que no sé si alguno suena, pero ha estado en la charla anterior, ha cambiado un poco su timeline. Tenemos este otro, por ejemplo, aquí en esta silla tan años 90, que seguro que también lo conocéis de ayuda WordPress. Igual que estos dos, también tenemos este niño de aquí, que bueno, ha cambiado, en este caso ya no sé si ha mejor o ha peor, pero bueno, soy yo. Bien, vamos a ver un poco, intentaré apurar sobre todo, no pararme en las diferentes tecnologías, en las diferentes partes, porque como son bastantes diapositivas, sino al final tendré que apurar muchísimo o quedará la mitad, por decir. Vamos a intentar ver todas estas tecnologías y todas estas partes. Comenzamos con la parte de servidor web. Aquí a la izquierda de todo, veis esta pantalla de Windows. Perdón, tenemos esto para señalar. Esto es el IIS, que es un servidor web en Windows, que es con lo que trabajábamos inicialmente. Después tenemos Apache, Engines y el flujo de trabajo ha sido, a finales de los 90, trabajábamos con IIS. En un servidor interno en red, trabajando sobre un Windows NT4, en aquella época. Después, seguimos trabajando sobre Windows, con la tecnología de Windows en NT y Windows 2000, pero ya trabajábamos sobre un Apache, que quizá os suena un poco más. Evolucionamos ese Apache, en vez de estar en Windows, lo llevamos a su entorno más natural, que era Debian. Después empezamos a trabajar ese Apache sobre FreeBSD y posteriormente ya Engines sobre FreeBSD y actualmente, con lo que suelo trabajar o con los Hostings, o si son servidores dedicados, suele ser combinaciones de Engines y Apache sobre Ubuntu. Que el último se Ubuntu no quiere decir que sea mejor que Debian o mejor que FreeBSD, simplemente ha ido cambiando por diferentes motivos. No es mejor esta tecnología que la otra, o Apache mejor que Engines o viceversa. Son distintas tecnologías. Bien, bases de datos. En cuanto a las bases de datos, aunque os pueda extrañar, inicialmente trabajábamos en la web con una base de datos Access. Trabajamos con unos Access y nos conectábamos mediante ODBC. Después ya hicimos el gran cambio y pasamos a un SQL Server. Ya era una base de datos en condiciones. Ya se podía hacer algo más que con esta base de datos de escritorio. Y la evolución siguiente fue pasar a MySQL y variantes ahora mismo como MariaDB, Percona, etc. Las bases de datos, bueno, aquí se han movido un poquito las flechas, pero bueno, os las imagináis un poquito más abajo y ya está. Empezamos lo que os había contado. Access nos conectábamos con ODBC, SQL Server, MySQL y variantes de MySQL Server. Para administrar las bases de datos. Claro, desde WordPress, haced a la base de datos y nos olvidamos del resto. Si queremos nosotros hacer cambios a mano, tenemos que administrar cualquier cosa. Seguro que la mayoría os suena PHP MyAdmin. Es una aplicación web que si trabajáis con servidor de hosting, la mayoría o casi diría que casi 100% tiene el PHP MyAdmin. Después tenemos otra que suelo utilizar bastante, que es Adminer, porque la ventaja o la diferencia con el PHP MyAdmin que es un único archivo PHP. Si no tienes acceso a su panel de control, el cliente no te lo da lo que sea, tú subes ese archivo a su WordPress, a su directorio al que queráis, entráis en la dirección que le hayáis puesto a la Adminer y tenéis un gestor de base de datos con un solo archivo. Es rápido, incluso en algunas ocasiones me ha salvado que no funcionaba bien el PHP MyAdmin, daba algunos problemas y la Adminer funcionaba bien. Es otra opción, simplemente. Y aparte, podemos administrar la base de datos sin ser con aplicaciones web, sino con aplicaciones de escritorio. Cuando queremos ya poner un poco más la base de datos, crear determinadas consultas, ver rendimientos, ver más cosas a las que no llega el PHP MyAdmin o la Adminer, pues tenemos diferentes programas de escritorio. En mi caso, utilizo Heide SQL y el MySQL Core Bench, según para cada ocasión. Por cierto, esta presentación después se colgará y hay enlaces al final de todas las cosas con lo cual nos hace falta copiar ahora si os interesa alguno de estas cosas. La mayoría de las veces no tenemos un acceso directo a la base de datos porque el hosting no nos da el acceso directo desde nuestro escritorio a la base de datos, solo se puede desde el servidor web. Bueno, para eso hay algo que se llama SSH Tunel, que lo que hacemos es conectarnos cualquiera de estos dos programas, por ejemplo, lo permiten. Desde el programa de base de datos de escritorio nos conectamos por SSH al escritorio, perdón, al servidor web, y desde el servidor web se conecta la base de datos. Estamos haciendo un tunnel. Nos conectamos a un lado y desde ese lado al otro. Nos estamos saltando, saltando entre comillas esa restricción. Cambios en el HTML, de cuando empezamos ahora, bueno, muchísimos, cambió la especificación HTML igual que en los demás lenguajes, pero en cuanto a la programación tenemos cosas ahora como, por ejemplo, Enmet, no sé si lo conocéis, pero podéis escribir con unas determinadas abreviaturas. En este caso, bueno, aquí no se lee mucho, lo veréis después en la presentación. He puesto deep.clgionworkup y eso me crea un deep con una clase clgworkup. Si después pongo un símbolo mayor que p, pues me crea un p, un asterisco 3 y me queda todo. Es decir, puedo escribir una línea y con esa línea crearme una estructura completa de a lo mejor la página entera. Entonces, nos ha abreviado muchísimo la forma de escribir nuestro HTML, que antes teníamos que picar a mano todo, todo, y ahora tenemos estas abreviaciones. En la parte tenemos servicios web, como en este caso codepen, en el que desde ahí podemos escribir el HTML, el CSS, el JavaScript directamente, o incluso utilizar librerías como jQuery para CSS, les, SAS, y todo eso nos lo va compilando, nos va creando y nos muestra el resultado abajo. Con lo que antes, cuando teníamos que hacer una prueba, nos teníamos que crear un HTML en nuestro escritorio, escribir los cambios y ver cómo quedaba. Ahora lo podemos hacer directamente en vivo indirecto desde una página web. En este caso codepen, hay varias, varias alternativas. Son muy útiles para hacer pruebas. Y aparte de esto que acabamos de ver, también tenemos las pruebas editando directamente el HTML desde el navegador, la consola, la consola en este caso del crón, del Firefox, de ópera, de cualquiera de los navegadores modernos. Aquí estamos viendo la página del país y vemos las noticias sobre esta WorldCamp, que es a nivel mundial, bueno, todo lo que veis aquí, que en realidad es la página web directamente y yo estoy editando la HTML ahí y viendolo en directo sobre la propia página web. No necesitamos como antes guardar el HTML, verlo en local, ver las pruebas. Podemos editar el resultado para ver cómo quedaría. Esto en cuanto al HTML. CSS y JavaScript, bueno, un mundo evolucionado. Podéis ver aquí a la derecha esta página, supongo que suena un poco, hace unos cuantos años y esta otra página de aquí. Ha cambiado totalmente de cómo eran antes, de cómo eran ahora. Antes las páginas eran así, ahora son de otro estilo. ¿Qué hacíamos en los 90? Utilizábamos vanilla JavaScript, no sé si sabéis lo que es. ¿Quién no sabe lo que es vanilla JavaScript? Bien, como volveré a hablar después de vanilla JavaScript, lo cuento un poco más después. CSS, por lo menos en mi caso, seguramente se utilizaría más avanzado, pero en mi caso se limitaba a hacer en los enlaces un hover y entonces te cambiaba el color y era muy bonito, pasabas por encima de un enlace y cambia el color. Utilizar color y fue un family, poco más era el CSS que utilizábamos de aquella era. Un avance increíble. En cuanto a Debug, para JavaScript, por ejemplo, utilizábamos los Alert. Alert aquí, a ver si llega hasta aquí, si está ejecutando. Entonces le dabas a actualizar la página y te saltaba ahí una ventanita alert. Ya sé que esto y seguías probando cosas, hasta ver dónde estaba el fallo. Ese era el Debug que utilizábamos en los 90, principios de los 2000. En cuanto al CSS para Debug, pues esto de aquí abajo. ¿Dónde está esta tabla tal? Pues le poníamos border. Un pisel solid red. Y entonces veíamos dónde estaba eso. Y ahora ponemos otra con un pisel dotted green. Y entonces lo veíamos con puntitos en verde. Y ahora éstos entonces con todo eso y vamos viendo un poco. Esto es lo que hacíamos en cuanto a Debug, de JavaScript y de CSS. ¿Cómo han cambiado las cosas? Ahora tenemos librerías, que supongo que a la mayoría os sonará, por ejemplo, jQuery, Backbone, Thickbox. No sé si os suenan estas librerías, pero por defecto están todas en WordPress. Se pueden utilizar ya directamente. Tenemos otras comocepto, que viene a ser como un jQuery un poco más reducido, más liviano. Y Vanilla JavaScript, que es lo que os hablaba antes. Vanilla JavaScript es la principal. Hay que seguirla utilizando. Al final de todo, tenéis los enlaces y tenéis el enlace a la web de Vanilla JavaScript, que es un poco una web de coña. Vanilla JavaScript es el JavaScript sin nada. De hecho, si le dais a descargaros, os dirá que ocupa cero. Es lo que tienen todos los navegadores. Es decir, es el JavaScript apelo, que rinde muchísimo mejor que el de jQuery que cualquier otra librería. Claro, nos da más trabajo hacerlo, si se puede, debería de utilizarse en lo posible JavaScript sin nada. Tenemos también les, SAS, SCSS, que son precompiladores de CSS, que lo que hacen es que podemos utilizar variables en nuestros CSS, funciones, una serie de cosas de programación que no nos brinda directamente el CSS. Cuando nosotros utilizamos todas esas funciones variables, por ejemplo, definimos color rojo, y le ponemos el estilo RGB de nuestro color, o el RGBA el que queramos. Cuando eso después lo guardamos, si utilizamos esa variable en 50 sitios de nuestras hojas de estilo, nos va a cambiar todo eso por el propio valor. ¿Cómo se pasa estas, estos lenguajes precompilados al propio CSS? Los propios editores nos lo dejan hacer. O tenemos tecnologías como Google, Chrome, Webpack, que sirven para eso y para muchas otras más cosas. Para que, por ejemplo, escribamos una propiedad CSS y que sea algo nuevo y nos haga compatible con todos los navegadores. Nos ponga los prefijos. Que nos comprima ese CSS final, que concatene los JavaScript, que comprima JavaScript, es decir, multitud de cosas los podemos hacer directamente con cualquiera de esos. En cuanto a mejora de tecnologías, lo que hablábamos antes, tenemos la developer tools, que son las herramientas de desarrollo que traen todos los navegadores actualmente. Y en JavaScript, si antes hacíamos alert, ahora tenemos console log. Evidentemente tenemos muchísimas más mejoras y no es lo que utilizamos para debug. Pero una de las mejoras es esto, que nos va mostrando mensajes en la consola de nuestro navegador y no nos salta una ventanita aquí en el medio y parándonos todo. Como hacía antes, el alert. Bueno, lo siga haciendo. Alert, sigue funcionando. Podemos, lo que os contaba antes, podemos comprimir el JavaScript, con pilarsas, etcétera. Y entre todas estas cosas en esta imagen no se ve muy bien, lo podríais ver después, el que le interese la presentación. Aquí tengo mi editor abierto y tengo abierto un archivo JavaScript que en el momento que le doy a guardar, o me muevo para otra ventana, lo guarda solo y está aquí abajo Gulp en este caso, está comprobando que ese archivo cambie, tan pronto lo guardo, crea el archivo minimizado, optimizado, etcétera. ¿Cómo optimizar el JavaScript? Hacer debug, bueno, pues la consola. La consola de JavaScript en este caso, vemos la página web, la estamos viendo en el formato del iPad, estamos viendo las reglas, las estoy mostrando, estamos viendo aquí todos los GameFrames, según se va ejecutando cada una de las cosas, incluso le cambiamos la posición, el geoposicionamiento, le estamos diciendo que la estamos viendo desde Nueva York, por ejemplo, le podemos cambiar lo que queramos, y la posición. En este caso, la página web no hace nada, pero podía ser que, según la movamos, haga diferentes efectos en la página, pues para los dispositivos móviles. Todo eso lo podemos hacer desde la consola, lo podemos mover gráficamente aquí, si abrís la consola, ahí va esta parte, bueno, todas estas maravillas nos las brindan ahora directamente los navegadores. Lenguaje de programación PHP actualmente, es lo que utilizo programación en el servidor únicamente. Cuando en PC ASP, que eran perdón, que se me ha ido la depositiva ASP, que era es una tecnología de Windows, páginas activas de servidor, Active Server Pace también utilizaba Visual Basic y lo compilábamos a una DLL y entonces después llamábamos desde la ASP a Sdll, es decir, para ofuscar el código para que no se viera. Era una época en que la web se veía de una manera totalmente distinta a la actual. Algo dejaba, nos tocó hacer por algún proyecto de donde trabajábamos, y empezábamos con PHP versiones 4.4.0 algo en esa época. El debug, lo que hablábamos antes, es decir, ver lo que está sucediendo en nuestra aplicación, hacíamos un print ¿Dónde estás? Aquí. O si eso se nos pasaba porque se quedé ejecutando diferentes partes, hacíamos un die. Die, paramos. Sé que ha llegado hasta aquí. Algo muy, muy básico. Actualmente trabajamos con PHP 7, ramas 7 algo. 7.2 es la actual, es una de las más rápidas que hay. 7.3 saldrá a finales de este año, sobre diciembre se calcula. Diferentes tecnologías y formas de PHP desde en consola, desde CGI hasta FPM, fast process manager. Tenemos diferentes sabores, podríamos decir de PHP, según si se ejecuta desde Apache, como un proceso aparte en un puerto, etc. Y multitud de herramientas como PHP CS, PHP Codesniffer, que nos permite cosas como integrado directamente en nuestro editor, que nos esté mirando la calidad del código y nos avise de unos determinados estándares si no los cumplimos. En este caso estoy trabajando con PHP CS integrado en el editor y con los estándares de WordPress. Que WordPress tiene unos estándares para PHP para CSS y para JavaScript y para HTML, perdón. Y en este caso me está diciendo, aquí no se ve, pero bueno, aparece subrayado en rojo, porque hay un fallo y me dice que espera un espacio después del paréntesis de apertura y que ha encontrado cero. Me está avisando directamente, voy aquí, le ha añadido un espacio y esto ya cumple los estándares. No va a cambiar nada, pero estoy haciendo un código que cualquier otro desarrollador que cumpla los estándares lo va a ver muy bien a primera vista. Nosotros trabajamos en base a esos estándares y estaremos mejorando muchísimo el código. El Debug del que hablábamos antes, tenemos ahora herramientas como el X Debug que instalamos en el servidor nuestro servidor normalmente de desarrollo que suele ser local y desde ahí vamos ejecutando paso a paso, vamos viendo lo que hace en cada momento nuestro WordPress por donde va pasando y todos los valores que tiene. En este caso aquí tengo un punto de interrupción en la línea 301 y tenemos la variable de query y aquí a la izquierda estoy viendo todos los valores que tiene esta variable que podemos desplegar podemos cambiar los valores, es decir podemos hacer auténticas maravillas cuando antes lo que hacíamos era un print, un echo y poco más. Esto es lo que ha evolucionado nuestra línea de tiempo en cuanto a la programación en lenguaje de servidor. Control de código fuente bien, en aquella época trabajábamos en una carpeta compartida, en el servidor todos teníamos acceso a esa carpeta trabajábamos todos sobre la misma carpeta no sobre copias locales. ¿Qué pasa? Como trabajábamos varios a la vez pues a lo mejor estábamos pisándonos el archivo entonces el primer control de código fuente era grito pelado ¿Quién tiene el archivo? ¿Está abierto? Después decidimos comentar los archivos esto es asp cuando veis estos tags los comentarios es como esta postrofe y decidimos ponerle el nombre y la fecha de la persona que había cambiado el archivo en este caso qué años aquellos ampersante, netil, de punticoma porque tampoco funcionaba muy bien el utf8 en aquella época bien, esto estuvo muy bien como control de código fuente cuando lo implementamos en el trabajo pero sólo había una persona que lo escribía y los programábamos y no hacíamos nada de esto entonces todos los archivos acababan teniendo el mismo nombre de la persona parecía que los modificaba a todos aunque no era así con lo cual esto no funcionó hoy en día tenemos perdón que no volvió a pasar tenemos diferentes programas para control de código fuente yo empecé utilizando mercurial me pasé allí que es lo que se utiliza actualmente la gran mayoría de la gente y tenemos territorios centrales para nuestro código gratuito donde podemos subir todo nuestro código y llevar en control como jit hub bitbucket, git lab son quizá los tres principales os recomiendo el primero si vuestros proyectos open source y los otros dos si tenéis proyectos privados con clientes no tenéis que pagar por ellos podéis tenerlos en cualquiera de los otros esta integración de jit la tenemos en el editor y desde el propio editor vamos viendo todos los cambios lo que se hizo en cada momento se hizo cada persona desde donde yo por ejemplo a lo mejor estoy trabajando yo solo con el archivo pero trabajo en el ordenador fijo en el portátil y entonces también veo en cada posición auténticas maravillas podemos hacer con esto tenemos programas aparte de la línea de consola de la integración con el editor programas gráficos como en este caso software que es de la misma empresa de bitbucket y el desarrollo local cuando desarrollamos para WordPress podemos desarrollar directamente sobre la web un gran error o en local y después irlo pasando para afuera bien empezamos con máquinas bueno con un desarrollo directamente sobre el servidor después sobre aparte, perdón, sobre máquinas en frivsd y montábamos la carpeta en samba entonces trabajamos todos sobre esa misma carpeta después empezamos con las máquinas locales microsoft virtual pc y vmware actualmente para las máquinas locales usamos virtualbox el aprovisionamiento lo hacemos con ansible la gestión de máquinas virtuales con background y los entornos de WordPress con vvv virtual variable grants y paneles de control como tres uves todo esto tenéis después los enlaces al final ahora lo que utilizo es local by flywheel es como la anterior que acabamos de ver de tres uves pero me ha dado una serie de problemas la anterior he visto que bastante gente le da esos mismos problemas y ahora los desarrollos lo suelo hacer con esto en local editor como os decía blog de notas pasamos una época muy muy corta de front page un tremendo desastre y lo dejamos empezamos con el visual studio 97 que aquello ya fue la panacea una auténtica maravilla porque te ponía colores en el código y hacía muchas más cosas después eclipse y en eclipse ya tenía configurado mi entorno de maravilla hacía también de todo pero era muy pesado entonces empecé a probar editores como el sublimetés y atom brackets en brackets me paré bastante tiempo bastante brackets y ahora le volví a dar otra oportunidad a visual studio code que lo proveen sus inicios no me convenció pero ha evolucionado una borrada y ya hace un año que utilizo esto como veis podéis tener bueno nos cuento todo lo que podéis configurar en el visual studio code en la nube cloud 9 podemos editar el código esto es una página web donde tenemos un editor online y podemos editar nuestro código todo nuestro código directamente desde una página web desde cualquier entorno si además todo esto lo vamos juntando con anterior con git y vamos synchronizando todo en la nube podemos estar trabajando todo desde un navegador tenemos otros como codio desde donde podemos lanzar directamente un WordPress editar su código fuente y hacer todo esto como veis en un navegador esto es un navegador web para pasar nuestros desarrollos locales intentaría probar un poco más porque ya estoy casi sin tiempo de desarrollos locales a live, es decir a lo que tiene que ver al final lo que tiene que estar público utilizábamos LFTP, era lo único que había pero bueno nos podían pasar cosas como estas que 39 años decía que le quedaba de su vida al final le quedaba algo menos actualmente utilizábamos LFTP se sigue utilizando pero bueno sería quizá lo más sencillo de todo tenemos git como hablábamos antes nuestro desarrollo local y enviarlo enviarlo directamente al servidor donde también tengamos git entonces ya queda publicado podemos publicarlo con Ansible con directamente una receta como esta donde ejecutamos un código y ya nos lo suba al servidor con herramientas como local to live de manager WP que nos permite subir ese código o bajarlo directamente en una web light o herramientas de este tipo en este caso es buddy que podemos configurarle cosas como esta como en el momento que yo envío un comando git y publico mi versión entonces subenme todo este código al repositorio envíame un mensaje al slack en caso de que falle hacer esto bueno podemos hacer miles de cosas bien tenéis todos los enlaces aquí al final ahora nos queda la parte de mantenimiento pero ya estoy fuera de tiempo entonces vemos que tenemos muchas herramientas para hacer el mantenimiento la que WP remote infinito WP podemos hacerlo con tareas desde nuestro servidor Chrome desde MOS que es una especie de SSH trabaja sobre SSH WP CLEE que ya se habló en alguna charla hoy sobre esto manager WP y herramientas de comunicación nada lo que utilizábamos antes que era el mail, el ICQ no se si alguien le suena, el messenger y el voice of the air es decir agrito pelado el jefe te gritaba desde al lado y te decía esto funcionaba ahora tenemos herramientas más sofisticadas como en este caso el slack aquí tenemos una reunión de algo relativo a WordPress donde veis que están ahí conectadas pues 15 personas las herramientas como veis aquí a la izquierda que podemos integrar todas e interactuar entre ellas que cuando pase esto nos envía un mensaje a nuestro slack de que la web está caída al telegram nos avisa directamente podemos integrar mil cosas y el bonus track lo vamos a dejar porque como es bonus track era simplemente la música yo para todas las herramientas que hago trabajo siempre con música lo que teníamos antes lo que tenemos ahora y aquí vemos cuatro páginas con lo que os contaba antes con todos los enlaces de todo esto que hemos contado eso es todo no se si no se si queda tiempo para preguntas bueno, dicen que hay tiempo para alguna pregunta solo los de la mitad abajo Carlos habéis encontrado alguna solución de otro de versiones para bases de datos si existe algo el no es que no lo conozco no se si existe algo y no he respondido rápido ¿Queréis una pregunta más? qonado bases de datos es un problema común no conoces ninguna pusiste alguna que hay en la nube para poder editar código para poder gestionar el versionado y otras plataformas yo conozco una herramienta que se llama DIBO que está hecha en España DIBO de E es ahora te permite tener tus tres estados de la web en plan producción, desarrollo y demostración en cuanto a eso utilizo para los diferentes estados muchas veces un servicio que es panteón panteón TH que son hosting pero yo no lo utilizo como hosting sino para esos estados es decir, yo normalmente mis desarrollos suelen ser en local trabajo en local, ahora con local by flywheel después en panteón me creo una web desde ahí igual que otros servicios como pylvia y otros series de servicios me creo una web los tres estados que son develop, staging y live entonces yo trabajo con los estados de developing y staging cuando llego al staging, lo paso directamente al live del usuario que en este caso no es del propio panteón y después en cuanto a volver a versiones anteriores utilizo herramientas a la mayoría de los clientes y les llevo un mantenimiento que te hace una serie de copias de seguridad lo normal que suelo tener suelen ser 4 al día cuando actualizo un plug en cualquier cosa si hay algún problema vuelvo al estado anterior es decir, es como volver como si fuera un git pero son copias de seguridad en realidad gracias