wearearima / blog Goto Github PK
View Code? Open in Web Editor NEWArima's public blog
Arima's public blog
He encontrado la solución a los tiempos de arranque (6m+) que sufríamos cada vez que parábamos el contenedor.
Básicamente se reduce a montar un volumen que almacena los gem
s de Jekyll, para que no tenga que descargarlos/instalarlos cada vez.
Creo un pull request con los cambios en el README.
Ejecuto el siguiente comando dentro del repositorio:
$ docker run -p 4000:4000 --rm --volume="$PWD:/srv/jekyll" -it jekyll/jekyll jekyll server
Y me da el siguiente error:
jekyll" -it jekyll/jekyll jekyll server
Fetching gem metadata from https://rubygems.org/...........
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Bundler::PermissionError: There was an error while trying to write to
`/usr/gem/cache`. It is likely that you need to grant write permissions for that
path.
An error occurred while installing public_suffix (4.0.1), and
Bundler cannot continue.
Make sure that `gem install public_suffix -v '4.0.1' --source
'https://rubygems.org/'` succeeds before bundling.
In Gemfile:
minima was resolved to 2.5.1, which depends on
jekyll-feed was resolved to 0.12.1, which depends on
jekyll was resolved to 4.0.0, which depends on
addressable was resolved to 2.7.0, which depends on
public_suffix
Docker version 19.03.8, build afacb8b
macOs High Sierra 10.13.6
Antes de que cerréis la issue: algunos párrafos no se ven bien en móviles porque tienen código
inline
muy largo y no cabe en una sola línea. Podéis verlo en el punto 5.
Igual lo suyo es utilizar bloques de código que tienen scroll.
Aquí: https://github.com/wearearima/wearearima.github.io/blame/master/_posts/2020-04-21-buenas-practicas-para-escribir-un-dockerfile.markdown#L85
Originally posted by @jagobagascon in #14 (comment)
Me he fijado que esto ocurre en más posts. En concreto:
kubectl explain pod.spec.containers.livenessProbe
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
@UrkoLekuona @itelleria @aberasarte
Al introducir el euskera y poner en cada "index" sólo los posts de ese idioma ha quedado al descubierto un problemilla: y es que no se ven todos los posts de cada idioma, sólo aquellos que NO están traducidos al euskera.
Hemos encontrado cuál es el problema: para cargar la variable site.posts se hace recorriendo todas las carpetas en orden alfabético. El orden de las carpetas es: en, es, eus. Qué sucede? Que por cada post se está quedando el último que encuentra. Así en el caso de los que están en euskera siempre se queda con la versión en euskera. Eso sólo sucede para el caso de la raiz, ya que tenemos puesto el idioma por defecto "_".
Si cambiamos el idioma por defecto a "es" funciona, PERO nos quedamos sin la ruta /es/.
Hemos valorado la opción de prescindir de esta ruta PERO hay tuits que hacen referencia a ella, así que la hemos descartado.
Después de mucho mirar, probar, hacer cambios etc. sólo se nos ocurren 2 workarounds, que son un poco meg.
1.- Poner el idioma por defecto a "es" y en el github actions añadir un paso que sea, crear una carpeta "es" y copiar todo lo que hay en la raiz en esa carpeta.
2.- Renombrar las carpetas dentro de _posts para que el último idioma por el que pase sea el de defecto.
Hemos optado por esta última. De tal forma que poniendo lang_def_es conseguimos que todo funcione ok. Como digo, tenemos claro que es una trampa, pero nos parece la trampa menos "cochina", ya que si en algún momento queremos cambiar el idioma por defecto, únicamente tendríamos que renombrar esta carpeta a "es" y poner a la que queramos que sea la de defecto lang_def_xx
Remove keywords. It's ignored by search engines.
Search engines' index is based on:
Si acabamos utilizando Jekyll Polyglot para dar soporte multilenguaje a nuestro blog (ver issue de Gitlab(privada)), habrá que tomar ciertas decisiones tanto para la apariencia del blog como para la estructura interna:
Aquí veo dos problemas a decidir:
Para que Polyglot asocie las diferentes versiones del mismo post, utiliza los permalinks de cada post.
Polyglot works by associating documents with similar permalinks to the lang specified in their frontmatter. Files that correspond to similar routes should have identical permalinks. - Extraído del repositorio de Polyglot
Como nuestro permalink es permalink: /:year/:month/:day/:title:output_ext
, esto implica que los nombres de archivos para ambas versiones deben de ser iguales (:title
corresponde al nombre del archivo, no al título del frontmatter). El resultado es que las URLs de las versiones están en el mismo idioma. Ejemplo:
http://localhost:4000/2020/04/21/buenas-practicas-para-escribir-un-dockerfile.html
http://localhost:4000/en/2020/04/21/buenas-practicas-para-escribir-un-dockerfile.html
¿Es esto un problema? Si cambio el nombre del archivo en inglés a "2020-04-21-dockerfile-best-practices.markdown", la URL en inglés cambia a http://localhost:4000/en/2020/04/21/dockerfile-best-practices.html
, pero ya no lo asocia con su versión en castellano, así que no sirve.
¿Cómo queremos que sea la URL de la versión en castellano? Actualmente, la versión en ingles es http://localhost:4000/en
, y hay que decidir si queremos que en castellano sea:
http://localhost:4000
http://localhost:4000/es
Si hacemos un blog multilenguaje, habrá que añadir un selector del idioma actual en algún sitio (cambiarlo por URL no es lo ideal). Se me ocurre que podemos añadir uno en el header/footer del blog y en cada post un enlace a la versión alternativa. ¿Qué opináis?
Esto esta relacionado con el problema de la URL. Utilizando el permalink actual, la manera en la que habría que organizar los posts para que el plugin funcione correctamente es crear un directorio dentro de _posts
llamado en
que contendrá todos los posts en inglés. ¿Qué vamos a hacer con la versión en castellano? ¿Los dejamos en _posts
o movemos a _posts/es
? Es decir:
Esto:
_posts
|
|- en
| |
| |- postIngles.md
|
|- postCastellano.md
o esto:
_posts
|
|- en
| |
| |- postIngles.md
|
|- es
|
|- postCastellano.md
No lo he probado aún, pero entiendo que los posts que contengan recursos con contenido en castellano, también necesitarán que esos recursos sean traducido. ¿Vamos a estructurar la carpeta assets
de alguna manera?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.