Bienvenidos a la charla de "Ilusionismo con GitHub Pages".
Antes de empezar me gustaría contar un poco el por qué de usar este cartel.
Para esta charla voy a basarme en la historia de Georges Méliès, uno de los pioneros del cine. En sus películas participaba en todo, era director, guionista, actor, decorador, operador, montador... Él sí que era un verdadero full-stack (en su caso artista full-stack).
Y después de esta pequeña introducción, me presento.
Soy Cristina Fernández, trabajo como desarrolladora Front-end, es decir, hago aplicaciones del lado cliente con html, CSS y JavaScript.
Trabajo actualmente en Kairós Digital Solutions aunque la charla de hoy la he creado a partir de un proyecto personal.
Y me podéis seguir en las redes como @cristinafsanz, tanto en twitter como en GitHub.
En la charla voy a hablar de:
-
¿Por qué surgió esta charla?
-
¿Qué es GitHub Pages y qué necesitáis saber para empezar?
-
Casos de casos que me han parecido interesantes
-
Alternativas y por qué elijo GitHub Pages?
Además, para amenizar la charla voy a incluir algunos trucos de magia que creó Georges Méliès. Porque antes de cineasta fue ilusionista.
Cuando empecé como desarrolladora front-end me propuse crear un portfolio para mostrar los proyectos que fuera realizando a nivel personal.
Por cierto, en la presentación no aparece mi portfolio sino el de Méliès, si hubieran existido los portfolios hace 100 años...
Un tiempo después de tener la idea del portfolio me di cuenta que sería también my útil poder acceder al código de esos proyectos web desde cualquier sitio, para poder consultarlo y reutilizarlo en otros proyectos.
Para alojar el código una alternativa bastante popular es GitHub, una plataforma que te permite tener repositorios de código en remoto. Además usa el sistema de control de versiones Git, que te permite volver a anteriores versiones de tus proyectos.
Sin embargo no veía conexión entre la publicación de la página web y el alojamiento del código con GitHub. Fue entonces cuando escuché hablar de GitHub Pages y tuve mi momento eureka.
Para que véais cómo me sentí, vamos a retroceder hasta finales del siglo XIX.
Georges Méliès era un ilusionista que asistió, invitado por los hermanos Lumière, a la primera representación del Cinematógrafo. Méliès quedó impresionado (como yo con GitHub Pages) y se decidió a incluirlo en su función. Como los hermanos Lumière no se lo quisieron vender, se compró un artilugio de la competencia y lo transformó para que sirviera como cámara y proyector para hacer sus experimentos. Y aquí es cuando me di cuenta de que Georges Méliès y yo tenemos vidas paralelas. Él llegó a crear 500 películas y yo he actualmente tengo 30 repositorios, que a lo mejor os parecen pocos, pero dadme tiempo...
GitHub Pages es una funcionalidad de GitHub que te permite publicar sitios web estáticos a partir del código que subes en un repositorio.
El código que publicas tiene que ser código del lado del cliente, es decir, html, css y JavaScript, pero como los proyectos que hago son front-end, a mí me sirve.
Cuando habilitas esta funcionalidad te proporciona un subdominio de github.io con tu nombre de usuario en GitHub:
-
Para un repositorio con nombre "username.github.io" tendrás la url https://username.github.io.
-
Para cualquier otro nombre de repositorio tendrás una url https://username.github.io/repo.
Puedes tener un único User Site y múltiples Project Sites. En la presentación pongo el ejemplo de mi User Site, donde pongo los enlaces a las redes sociales y al blog que tengo.
Ejemplo User Site: https://cristinafsanz.github.io/.
Ejemplo Project Site: https://cristinafsanz.github.io/projects/.
Nivel básico de Git y del terminal para ejecutar los comandos. Y nivel básico de cómo trabajar con la interfaz gráfica de GitHub.
Para que veáis que es sencillo trabajar, os pongo la lista de pasos que suelo hacer:
- La primera vez crear cuenta en la aplicación web de GitHub e instalar git en local.
Hay que crearse un repositorio en GitHub para almacenar allí tu código.
Clonamos el repo en local para incluir todos los ficheros en nuestro local.
En la presentación añado un gif de Méliès donde se clona a sí mismo y me pareció muy apropiado para esta slide.
Añadimos al código dentro el proyecto clonado.
Subes el código a GitHub primero añadiendo el código en local con git add y git commit y luego haciendo push al repositorio remoto.
Los gifs de esta parte son de la película viaje a la luna (de 1902) y el gif actual es como me imagino que llega el código a remoto.
Una vez subido el código vas a la pestaña Settings a la sección de GitHub Pages y habilitas GitHub Pages. Lo más común sería elegir la opción de publicar desde master, aunque os explicaré a continuación un caso donde podría resultar mejor subir desde otro origen.
Una vez habilitado GitHub Pages tenemos la página web publicada en la url de User Site o Project Site, dependiendo de qué repositorio hayamos utilizado.
Para explicar las distintas formas de publicar con GitHub Pages voy a utilizar la extensión de Chrome Octotree, que añade un panel a la izquierda en la página web de GitHub y que muestra el proyecto en forma de árbol, siempre que el proyecto sea público. También lo usaré al mostrar otros repositorios de ejemplo.
A mí me resulta muy útil para ver toda la estructura del proyecto.
Para explicar las formas en las que podemos publicar voy a basarme en el truco de sobreimpresión, donde Méliès rebobinaba la cinta para grabar su cabeza en partes distintas de ella.
En la presentación apreciamos que a Méliès también le gustaba clonar su cabeza.
Basándome en ese truco voy a usar el mismo proyecto y lo voy a publicar de 4 formas distintas, utilizando un repositorio para cada una.
https://github.com/cristinafsanz/vue-master
https://github.com/cristinafsanz/vue-master-docs
https://github.com/cristinafsanz/vue-gh-pages
https://github.com/cristinafsanz/vue-gh-pages-travis
He cogido al azar el proyecto que usó Jose Dongil en su charla de Vue. Hay gente en el público que pueden corroborar que se trata del mismo proyecto de Codenares. Y ahora que está demostrado que no hay ninguna trampa en el truco voy a comenzar.
Para el primer repositorio voy a utilizar el origen más común, master. El código que subes en master es el que se publica.
Se trata de un proyecto vue que utiliza webpack para preparar la aplicación para producción. El código que quiero publicar lo tenemos en el directorio dist, por lo que si habilitamos GitHub Pages desde master, tendremos la aplicación en https://username.github.io/repo/dist.
GitHub Pages nos permite publicar lo que se sube a la carpeta /docs de master, así que vamos a usar esta opción para el segundo repositorio.
Como sólo queremos publicar lo que hay en una carpeta /dist, podemos renombrar esta carpeta destino para que se llame /docs. Así tendremos la aplicación directamente en https://username.github.io/repo.
Sé que puede quedar un poco raro que tengas en una carpeta docs cosas que no son documentación, lo que pasa es que GitHub Pages sólo admite este nombre de carpeta por ahora, así que más no podemos hacer.
Además hay mucha gente que no quiere subir a GitHub el código generado para producción, no quiere subir esa carpeta de distribución.
Por ello hay una tercera posibilidad, que es subir el código que queremos publicar en otra rama, que tiene que llamarse gh-pages por convención.
Este proceso es un poco más enfarragoso porque hay que hacer push a 2 ramas con contenidos distintos, en una el proyecto y en otra el código para publicar (el que estaría en /dist o en /docs en los repositorios anteriores).
Por ello normalmente se utiliza un servicio de integración continua como Travis para que cuando hagas push a master, se genere el código de producción y se haga push a gh-pages automáticamente.
Además ahora Travis integra con GitHub Pages de forma más sencilla y sólo necesitas añadir un fichero travis.yml. En él indicas el script para generar los ficheros de producción, dónde se generan y la rama origen.
Os voy a contar algunos casos de uso que considero interesantes.
Voy a usar el truco de parar para explicar este caso de uso. Se grababa una escena, se paraba la cámara, se añadían o quitaban elementos y se volvía a grabar.
Yo basándome en este truco os voy a enseñar el mismo proyecto de dos formas distintas. En el segundo repositorio voy a añadir una librería que nos puede venir bien al subir nuestros cursos (o tutoriales, manuales, ...).
https://github.com/cristinafsanz/flexbox-master
https://github.com/cristinafsanz/flexbox-jotted
Voy a partir de 2 ejemplos del curso de Flexbox de Diana Aceves.
Antes de subir nada, hay que saber si tenemos permiso para alojar los cursos de una determinada escuela. En el caso de EscuelaIT les pregunté a ellos y a Diana y me dijeron que no había problema.
Vamos a subir estos ejemplos a la rama master y habilitamos master para GitHub Pages. Con esto tenemos los ejemplos en:
https://username.github.io/repo/example1/
https://username.github.io/repo/example2/
Ahora añado una librería que se llama Jotted, que es similar a un emulador como JSFiddle pero para demos que queremos tener en un entorno propio:
Tenemos los mismos ejemplos que antes en:
https://username.github.io/repo/example1/
https://username.github.io/repo/example2/
Con esto en la misma página tenemos el código html, css y js en distintas pestañas y en otra el resultado de cómo se ve en un navegador.
Tanto en el caso de subir el curso sin esta librería como con ella tenemos la ventaja de que podemos ver la demo sin tener que bajarnos el código de GitHub a local para ver el resultado, lo que agiliza mucho las cosas. Esta aplicación de GitHub Pages es la que me parece más interesante y que quiero seguir probando en el futuro.
Para hacer esta presentación he utilizado el proyecto WebSlides y el resultado está publicado en GitHub Pages.
Estáis viendo un caso de uso en esta misma presentación, ese es el truco.
https://cristinafsanz.github.io/slides/codemotion2017/#slide=1
https://github.com/cristinafsanz/melies-origen
Me creé un blog para hablar del proceso de esta charla, pero también para probar un generador estático distinto al de por defecto (Jekyll).
https://github.com/cristinafsanz/melies-hugo
El truco es que he usado un generador estático en concreto, no por la velocidad o la tecnologías, sino por el nombre que tiene. Se llama igual que una película que homenajea a Georges Méliès. Éste es el truco.
Puedes documentar un proyecto para explicar de qué va usando el fichero README o la wiki disponible en GitHub.
Un truco que he visto si no quieres complicarte añadiendo un estilo inicial es usar GitHub theme en la pestaña de Settings, que activa un diseño entre unos cuantos posibles usando el generador estático por defecto de GitHub, Jekyll.
https://github.com/cristinafsanz/github-page-theme
Además de GitHub Pages podemos utilizar otras plataformas para publicar nuestros experimentos.
Como primera alternativa podemos contratar un hosting y enlazar con el repositorio de GitHub donde tengamos el código.
Un ejemplo de esto lo podemos encontrar en el blog de Jorge Aznar en el que explica Grid Layout.
http://jorgeatgu.com/ejemplos/css-grid/
https://github.com/jorgeatgu/ejemplos-blog/tree/master/css-grid
También podemos usar Codepen u otro emulador como JSFiddle para publicar la demo de un código que tenemos en GitHub, como hace Sarah Drasner.
https://codepen.io/sdras/pen/d953d844fb3bed2c053fb83874844f64?editors=0110
Y como última alternativa que os propongo podemos tener el código en GitHub y publicarlo en otras plataformas como Surge o Netlify, como hace Angel de Miguel en un proyecto de Open Source.
https://github.com/Angelmmiguel/rock-the-open-source
https://angelmmiguel.github.io/rock-the-open-source/
https://rock-the-open-source.surge.sh/
https://rock-the-open-source.netlify.com/
https://www.youtube.com/watch?v=-MXVtFwS6Gw
También podemos probar GitLab en vez de GitHub. A muchos desarrolladores les gusta más porque la plataforma en sí es open source.
GitLab también tiene un servicio GitLab Pages.
Porque me ha sido más sencillo de utilizar al conocer GitHub.
Porque es bastante usado en la comunidad y puedes tener ayuda de mucha gente que lo utiliza.
Y sobre todo porque puedo tener código, demostraciones y notas en el mismo sitio. No hace falta bajarte el código del repo a local para ver el resultado, sólo acceder a la url de la demo.
De hecho GitHub se puede utilizar para casi todo: para escribir novelas (como JJ Merelo), organizar una charla, mostrar tus herramientas de trabajo y mucho más. Sólo faltaría poder grabar y proyectar películas para que fuese perfecto.
Como dije al principio, cuando empecé como desarrolladora front-end quería crear un portfolio que mostrara los proyectos que fuera realizando, lo que no me esperaba es que el medio para exponerlo fuera GitHub.
Con cada repositorio explico lo que hecho y cómo lo he hecho. Me sirve tanto para alojar proyectos web como para organizarme y centralizar lo que aprendo. Y puedo compartirlo con otros a los que les pueda servir. Me sirve para mostrar parte de mi trabajo.
Creo que mi objetivo ha sido cumplido.
Espero que esta historia os haya inspirado para buscar vuestra manera de experimentar y exponer vuestros trabajos. Puede ser GitHub Pages o cualquier otro medio que encontréis.
Los hermanos Lumiere inventaron el cine pero Méliès lo convirtió en arte. Yo encontré GitHub y lo he convertido en charla.
¡Muchas gracias!
Os comparto el repo donde tengo todos los casos de uso, las slides con el guión y el blog sobre el proyecto.
-
Giphy
-
Youtube to gif: https://github.com/F1LT3R/youtube-to-gif
Ejemplo:
youtube-to-gif -u https://www.youtube.com/watch\?v\=uvfwgA6mBu0 -b 40 -d 14 -s 500x375
Versión inicial: Todas las imágenes de la carpeta imagenes-guion pasarlas de png a archivo pdf con https://pdfcandy.com/png-to-pdf.html.
Después usar la funcionalidad de recortar pdf para adaptarlo al tamaño de la imagen.
Si quieres tener un dominio propio tienes que añadir un fichero CNAME con el dominio contratado.
La desventaja es que pierdes el https y si quieres mantenerlo como en el caso de username.github.io tienes que utilizar CloudFlare u otra alternativa, aunque yo no lo he probado por ahora, para los experimentos que hago suelo dejar el dominio por defecto.