Recomendaciones de trabajo en local

 Bienvenido o bienvenida aquí otra semana más a Drupalizate, te cuento temas de Drupal. Primero de todo, mil disculpas porque la semana pasada me olvidé completamente de hacer el episodio y publicarlo. O sea, me acordé el lunes siguiente cuando estaba escribiendo la newsletter, porque yo cada semana tengo el viernes publico episodio y el lunes publico la newsletter. Recuerda que tienes el episodio antiguo y del viernes pasado y pongo unos enlaces de noticias relevantes que encuentro yo de esta semana de temas de Drupal. Que si no estás apuntado a la newsletter, pues te vas al LinkedIn, me buscas a mí o buscas Drupalizate y te saldrá la newsletter por ahí. Es una newsletter que en verdad no es una newsletter como tal, es una newsletter de LinkedIn. Dicho todo esto, ¿qué se me pasó? Y en episodios anteriores pregunté qué cosas queréis que cuente en este podcast, porque al final el podcast BD como proyecto lo dejo, digamos, terminado. Tengo que arreglar algunas cosillas, pero no es una cosa que tenga que contar en este podcast. Y pregunté por ideas de, bueno, vosotros como audiencia, pues, ¿qué queréis escuchar? Y hubo una persona, Salvador, que me dio unas cuantas ideas y la que quiero comentar hoy es una de las que me dio él, que es entornos de desarrollo, recomendaciones de cómo montártelo y de qué usas herramientas, dockerizarlo o no, o sea, qué es mejor si usas Docker en local o no. Así que me voy a enfocar en esta temática hoy, espero que sea un episodio cortito. Intentaré que sea cortito, así que vamos a ello. Lo primero de todo, yo hace muchos años que ya trabajo con Docker en local. Recomiendo mucho aprender el conocimiento mínimo para trabajar en Docker y en local. O sea, yo empecé muchos años atrás con temas de champ y Wamp, depende si trabajas con Windows o con otros sistemas operativos, que básicamente te instalan pues PHP, Apache y MySQL. Y con eso, para un Drupal normalito o un WordPress o cualquier cosa que vaya con PHP, pues te sirve perfectamente. El problema que tienes es que cuando tienes varios proyectos y cada proyecto tiene una versión de PHP distinta, por ejemplo, digamos que son problemas. En cambio, si está todo dockerizado, pues es mucho más fácil que cada proyecto tenga sus contenedores Docker con sus versiones correspondientes y aparte lo puedes personalizar. Pues si tienes un proyecto que usa, digamos, cosas más extrañas como Redis, Memcache, o Elasticsearch o Solar, te permite tener dockers específicos y cada proyecto que tenga los suyos. Y al final, puedes apagar los contenedores de Docker y encenderlos para determinados proyectos. Y es muy cómodo, la verdad. Cambias de directorio de un proyecto a otro, en el directorio viejo, apagas, o sea, haces un stop de los contenedores y cambias al directorio nuevo del nuevo proyecto y haces una app para levantar contenedores. Y en un comando, básicamente, tienes toda la web ya levantada. Es muy cómodo, es muy configurable y yo, sinceramente, recomiendo muchísimo aprender al menos lo mínimo en Docker. Yo actualmente estoy usando lo que son dockers de Goodby, que es una empresa. Esta gente ha hecho, como digamos, un conjunto de dockers que, si lo buscas en Google, es docker for Drupal con un 4. El 4 es el número 4. Y si buscas por Goodby, también te van a salir. Lo tienen en un GitHub, es libre y lo puedes descargar y usar como tú quieras. Y es muy configurable y fácil de usar. Y por eso lo uso. O sea, me va perfecto, no he tenido ningún problema con ellos. Sí que es verdad que he probado otras cosas en docker también. Una de ellas es el Lando. La probé hace mucho tiempo en sus inicios y a mí, en sus inicios, no me ha convencido. Lo encuentré muy complejo para lo que era, pero sí que es verdad que he visto que hay agencias que lo siguen usando, supongo que es porque ha madurado y va mejor que como iba antes. A todo esto, que yo no lo he mencionado, yo trabajo con Linux en mi local. Mi portátil es con Linux, no es con Windows ni con Mac. Hay otras agencias con las que he trabajado que con docker for Drupal tenían problemas de rendimiento por tema de escritura en disco, porque usaban Windows únicamente en la agencia. En ese caso en concreto les funciona muy bien pasarse a DDEV. Es otro, digamos, otro conjunto de herramientas para trabajar con docker, que también te monta un Drupal, un entorno en Drupal en local, es con dos D's, DDEV. Dejaré los links de todo en las notas del programa, porque sepáis que, a menos por mi experiencia trabajando con otra gente que trabaja con Windows, docker for Drupal en Windows iba muy lento, porque al final los dockers comparten el kernel con Linux y al final tienen cosillas de rendimiento. Y con DDEV la gente que trabaja con Windows le iba igual de rápido que a mí en Linux y con docker for Drupal. Así que esto, mi recomendación sería si usas Windows quizás es mejor DDEV antes que docker for Drupal. Si usas Mac te recomendaría docker for Drupal, que tampoco debéis tener problema. Y si no quieres saber nada de temas docker, bueno, pues al final un champ o un Wamp, que son cosas digamos ya viejas porque se pueden seguir usando, sobre todo si sólo tienes un proyecto que es el tuyo y no tienes más. Y son proyectos, como digo, simples, que no hay esto ni solas, ni elastics, ni redis, ni mcaches, ni cosas así más complejas. Cuando son proyectos pequeños o medianos es factible. Así que digamos esto es mi forma de trabajar en local. ¿Qué más tengo para trabajar yo en local? Mi IDE de desarrollo, o sea mi software con el que toco código, ahora mismo desde hace unos años es PHPStorm. Me pago la licencia yo, ¿vale? Porque PHPStorm es de pago, aunque si es estudiante me es una que en su día tenían ofertas de estudiantes y lo puedes usar de forma gratuita. No sé cómo está a día de hoy. Yo recomiendo mucho, me gusta mucho cómo funciona y por eso sigo pagándolo y lo sigo usando. Justamente lo he tenido que renovar ahora en agosto, la licencia. Ventajas versus Otros IDE que te hace recomendaciones, detecta si estás en un Drupal y si es un Drupal 7 u 8 y te hace recomendaciones de código y también la navegación entre funciones dentro del mismo Drupal pues es lo mejor que he probado básicamente. Tiene muchísimas integraciones con muchas otras tecnologías así que también cuando haces cosas de Frontend y bueno al final a mí me da perfecto PHPStorm. Pero aún así cuando empecé yo hace la tira de años empecé con Sublime Text que también se puede usar perfectamente. El problema de Sublime Text es que digamos es más simple, lo puedes extender con muchas extensiones pero bueno lo hace configurar muchísimo más. PHPStorm lo instalas y sin que hagas falta tocar mucho ya puedes empezar a trabajar. Así que es verdad que hay cosas que las puedes configurar pero digamos que hagan de rasgos como viene por defecto ya se serviría para la mayoría de la gente. Así que yo recomendaría PHPStorm. Después a mucha gente seguramente usará Visual Code. Es otra opción, o sea al final digamos que es un punto medio entre Sublime Text y PHPStorm está Visual Code y seguramente se aparece más a lo que es PHPStorm. Visual Code digamos que es gratuito y por eso lo usa mucha más gente y ya está. Yo no me acabo de adaptar a él, lo intenté probar y fue bueno. Encuentro faltar cosas que en PHPStorm son mucho más fáciles de hacer. Sobre todo creo que la integración con Git para navegar por las ramas y ver temas de cambios en las ramas. Encuentro mucho más usable PHPStorm o estoy mucho más acostumbrado así que yo sigo usando PHPStorm. Después qué más... Otras herramientas que puedo usar. La verdad como PHPStorm en mi caso tiene incluido el tema de Git y ver las ramas y poder navegar por dentro sin línea de comandos, me es muy cómodo. En su día cuando usaba Sublime Text usaba otras herramientas que no me acuerdo el nombre pero que básicamente me servían para hacer los commits y hacer los merge y que visualmente fuera todo más fácil. Aparte de esto, poca, es que realmente no hace falta mucho más. Es algo para editar el código y ya está y después para subir código es por SSH, que es línea de comandos en mi caso. Años atrás, bueno y en verdad últimamente hay un cliente que también no tiene SSH y se siguen trabajando con files por FTP. Yo no lo recomendaría. Recomendaría que todo se suba por SSH y por Git, no por FTP. Pero bueno aún hay gente que trabaja así. Y creo que poca cosa más la verdad. No es tan complicado, igual que la gente trabaja con webpages, con un editor de textos normal que no es ni un IDE de programación, en Drupal si quisieras, podrías. Lo único que digamos que por facilidades de trabajo y para trabajar más rápido pues tener un IDE y en este caso en mi caso PHPStorm, yo lo hiper recomiendo. Se trabaja mucho más rápido y si al final digamos que estás en varios proyectos al mismo tiempo, la forma de poder cambiar de proyecto y que te guarde todo el entorno y cosas que por ejemplo en Sublime en su día no las tenía como tal. Y nada más que esto. Que recomiendo PHPStorm, recomiendo Docker y recomendaría Linux la verdad. Pero sé que mucha gente, algunos me mían como loco, sobre todo porque hay agencias que no tienen Linux y usan o Windows o Mac. Y sobre todo me extraña las que usan Windows a día de hoy aún para temas de programación. La única excusa viable es el tema de los diseños. El que te pasen los diseños y otros pasan en formato PSD, o sea en formato Photoshop. Claro, en Linux yo no tengo Photoshop porque Photoshop no está disponible para Linux. Así que tienes que usar otros softwares que pueden abrir ficheros de Photoshop. Pero realmente después hay fallos. O sea, cuando se ve un fichero de estos es como cuando abres un Word. Cuando en Linux no hay Word pues la compatibilidad no es 100% exacta y pueden haber cosas que se mueven de sitio. Esto en un Word realmente te importa poco, pero cuando estamos hablando de un diseño que tú tienes que fiarte del diseño para aplicarlo a la web pues que hayan cosas que se vean distintas al diseño original que estaba en Photoshop pues puede ser un marrón. Así que en mi caso últimamente ya no trabajo tanto el tema de Frontend, por suerte o por desgracia. A mí no me gusta más lo que es Frontend. Pero en su día, al final de la edad, o me lo pasáis en un formato que no sea Photoshop, que sea más estático y que yo en Linux lo pueda abrir, o se trabajaba en softwares que básicamente se subía a un servidor y yo tenía acceso directamente a la URL y veía cómo tenía que quedar la web ya en tipo SaaS de que subían el diseño directamente en web. También iba bien porque lo compartían con clientes y vaya gente al mismo tiempo podía comentar, sobre todo con temas de videoconferencia. Pero esto depende mucho de la agencia y en mi caso es que apenas lo uso. O sea, yo uso lo que me pasa la agencia porque yo no hago los diseños. A mí me pasa el diseño y yo lo tengo que aplicar a Frontend. Y como digo, desde hace unos meses apenas hago nada de Frontend. O sea, no hago una web de Frontend entera sino que me dicen de hacer arreglos. Cosas que se ven un poquito mal, pues toqueteas. Lo que me estoy ocupando últimamente es más de temas de backend, que se acostuma a pagar mejor y también me gusta más a mí. Bueno, pues nada, que no me quiero alargar mucho más. Es así mi resumen de cómo trabajo yo en mi local y qué cosas recomiendo que tengas en tu local. Así que nada más, atento a la siguiente semana que seguir con esas preguntas que me han hecho la gente y ir respondiendo estas cosas. Así que muchas gracias por vuestro tiempo y nos escuchamos. Chao.