Desarrollo Colaborativo de Proyectos de Aprendizaje y Enseñanza de Tecnologías en la Nube
Partiendo del repl.it que creó en la práctica anterior, vamos a profundizar en el generador de web sites y blogs estáticos (Jekyll).
Siga estos pasos:
p03-t0-aprender-ide
Haga un fork de su repl.it en que trabajó en la práctica anterior p03-t0-aprender-ide
p04-t0-aprender-jekyll
Modifique el projecto para que sea un web site para la asignatura que piensa desarrollar en su TFM y en sus Prácticas en Centros. En el directorio _posts
escriba varias lecciones de prueba. Algo así:
~/.../aet2021/apuntes(master)]$ tree _posts
_posts
├── 2020-11-03-leccion.md
├── 2020-11-05-leccion.md
├── 2020-11-10-leccion.md
├── 2020-11-12-leccion.md
└── 2020-11-17-leccion.md
Recuerde poner el front-matter en sus posts. Especifique al menos el layout
y el title
.
---
layout: post
title: "Clase del Jueves 12/11/2020"
---
temas
para los temas que va a impartir y ponga algún contenidotareas
para las tareas que va a asignarles a sus alumnos y añádales algún contenido_data
en un fichero JSON o yml de manera que el web site sea fácilmente modificable para adaptarlo a otra asignaturaJekyll Collections is the way Jekyll extends the functionality Jekyll provides for Posts to other user defined collections of documents (like lessons or task assignments in a web site course or departments or people in a school web site).
In addition to any collections you create yourself, the posts
collection is hard-coded into Jekyll. It exists whether you have a _posts
directory or not.
This is something to note when iterating through site.collections
as you may need to filter it out.
You can see your collections with a code like this one:
<div style="border-style: solid; border-radius: 25px;">
<ol>
{%- for col in site.collections %}
<li> Colección: {{ col.label }} </li>
<ol>
{%- assign firstdocs = col.docs | slice: 0,3 %}
{%- for elem in firstdocs %}
<li> <b>path:</b> {{ elem.path }} <b>url:</b> {{ elem.url }} </li>
{%- endfor %}
</ol>
{%- endfor %}
</ol>
</div>
when runned in this site produces:
_config.yml
. For example here’s a collection called tareas
: collections:
- tareas
Create a corresponding folder (e.g. <source>/_tareas
) and add there the collection documents. Something like this:
[~/.../sytws2021/apuntes(curso2021)]$ tree _tareas
_tareas
├── 01p01-t0-pb-gh-campus-expert.md
├── 01p01-t1-iaas.md
├── ...
└── 12p12-tfa-user-experience.md
0 directories, 17 files
Here is an example of how you would add a new tarea to the collection tareas
set above. You add a file to the _tareas
folder. Something like ./_tareas/10p10-t3-jekyll-search.md
. Follows an example of content:
---
name: p10-t3-jekyll-search
visible: true
date: 2020-11-30
my_order: 4
---
# Task to Add Search to Your Jekyll Web Site
Blah, blah, blah ... description of the task the student must do
Regardless of whether front matter exists or not, Jekyll will write to the destination directory (e.g. _site
) only if output: true
has been set in the collection’s metadata
collections:
tareas:
output: true
temas:
output: true
content
attributetareas
and temas
Except for documents in hard-coded default collection posts
, all documents in collections you create, are accessible via Liquid irrespective of their assigned date, if any, and therefore renderable.
Documents are attempted to be written to disk only if the concerned collection metadata has output: true
. Additionally, future-dated documents are only written if site.future
is also true. Therefore, you can hide a document by setting the date to a future date.
More fine-grained control over documents being written to disk can be exercised by setting published: false
(true
by default) in the document’s front matter.
Now you can iterate over site.tareas
on another page, let’s say file tareas.md
and output a link to each tarea
.
{%- for practica in site.tareas %}
{%- if practica.visible %}
{{ practica.name | slice: 0, 2 }}. <a href="{{ practica.url }}">Práctica {{ practica.name }}</a>
{%- endif %}
{%- endfor %}
We can link to the generated page using the practica.url
attribute
Similar to posts, the body of the document can be accessed using the content
variable. Here is another example:
{% for task in site.tareas %}
<h2>{{ task.name }} - {{ task.date }}</h2>
<p>{{ task.content | markdownify }}</p>
{% endfor %}
markdownify
filter converts a Markdown-formatted string into HTML. The name sounds wrong to me: It will be better to call it htmlifydate
attribute when both of them have the date
key in their front matter.YYYY-MM-DD HH:MM:SS +/-TTTT
; hours, minutes, seconds, and timezone offset are optional.sort_by
metadata to the front matter key string.
For example, to sort the collection tareas
based on key my_order
, the configuration would be:
collections:
tareas:
sort_by: my_order
See Liquid Attributes section in the Jekyll tutorial about Collections
Collections are also available under site.collections
, with the metadata
you specified in your _config.yml
(if present) and the following information:
Variable | Description |
---|---|
|
The name of your collection, e.g. |
|
An array of documents. |
|
An array of static files in the collection. |
|
The path to the collection's source directory, relative to the site source. |
|
The full path to the collections's source directory. |
|
Whether the collection's documents will be output as individual files. |
In addition to any front matter provided in the document’s corresponding file, each document has the following attributes:
Variable | Description |
---|---|
|
The (unrendered) content of the document. If no front matter is provided, Jekyll will not generate the file in your collection. If front matter is used, then this is all the contents of the file after the terminating `---` of the front matter. |
|
The rendered output of the document, based on the
|
|
The full path to the document's source file. |
|
The path to the document's source file relative to the site source. |
|
The URL of the rendered collection. The file is only written to the destination when the collection to which it belongs has |
|
The name of the document's collection. |
|
The date of the document's collection. |
\(\LaTeX\) is a free professional typesetting, that it is the standard for scientific documents.
To use the \(\LaTeX\) language in your posts
, temas
or tareas
collections or in any document, you can make use
of MathJax and insert in your layout file _layouts/default.yml
a line like this one:
<!-- Mathjax Support -->
<!-- MathJax version 3 -->
<script type="text/javascript">
window.MathJax = {
tex: {
packages: ['base', 'ams']
},
loader: {
load: ['ui/menu', '[tex]/ams']
}
};
</script>
<script type="text/javascript" id="MathJax-script" async
src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-chtml.js">
</script>
Now you can use LaTex formulas everywhere in your website:
You can insert some formula $$f(x) = \int_{-\infty}^\infty \hat f(\xi)\,e^{2 \pi i \xi x} \,d\xi$$ in the middle of a sentence.
You can also put large formulas in their own paragraph.
$$f(x) = \int_{-\infty}^\infty \hat f(\xi)\,e^{2 \pi i \xi x} \,d\xi$$
$$mean = \frac{\displaystyle\sum_{i=1}^{n} x_{i}}{n}$$
You can insert some formula \(f(x) = \int_{-\infty}^\infty \hat f(\xi)\,e^{2 \pi i \xi x} \,d\xi\) in the middle of a sentence.
You can also put large formulas in their own paragraph.
\[f(x) = \int_{-\infty}^\infty \hat f(\xi)\,e^{2 \pi i \xi x} \,d\xi\] \[mean = \frac{\displaystyle\sum_{i=1}^{n} x_{i}}{n}\]See the References section in this notes about \LaTeX
npx js-yaml data.yml > data.json
converts from .yml to .jsonEn tu repl.it, el remoto git sigue apuntando al repo que creaste en su momento:
GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
$ git remote -v
origin https://github.com/ULL-MFP-AET-2021/JekyllBlog-mrguezl (fetch)
origin https://github.com/ULL-MFP-AET-2021/JekyllBlog-mrguezl (push)
Configuramos nuestra identidad git
en la máquina virtual de repl.it con estos comandos:
git config user.email mariarguezleon@gmail.com
git config user.name mrguezl
Nos situamos en el directorio site
:
$ cd site
Y creamos un nuevo repo local con el comando git init
:
$ git init .
Initialized empty Git repository in /home/runner/p04-t0-aprender-jekyll-no-aceptado/site/.git/
En el directorio site
editamos un fichero con nombre .gitignore. En este fichero listamos aquellos ficheros y directorios que queremos que no estén bajo el control de versiones. Algo similar a esto:
$ cat .gitignore
_site
.DS_Store
.jekyll
.jekyll-metadata
.bundle
.sass-cache
.jekyll-cache*
Le indicamos a git que ponga todos los ficheros bajo el control de versiones del nuevo repo con git add .
:
$ git add .
El punto .
es un sinónimo de directorio actual.
Esto añadirá todos los cambios ocurridos en todos los ficheros en el directorio actual salvo los que fueron especificados en el .gitignore
.
A continuación confirmamos los cambios en el repo con un git commit
$ git commit -am 'creating a repo inside site and linking it with the remote assignment repo'
...
create mode 100644 style.scss
Ahora hacemos que este repo local tenga como remoto el repo GitHub de entrega de la tarea p4-t0-aprender-jekyll
$ git remote add origin https://github.com/ULL-MFP-AET-2021/p04-t0-aprender-jekyll-mrguezl.git
Cuando hagamos el push
git preguntará por el usuario y la clave en el remoto.
Para evitar que este preguntando a menudo por el usuario y la password
de GitHub podemos decirle que los almacene con este comando:
git config credential.helper store
Empujamos los contenidos del directorio site
en el repo de entrega de la práctica con git push -u --force origin master:main
$ git push -u --force origin master:main
Username for 'https://github.com': mrguezl
Password for 'https://mrguezl@github.com':
Counting objects: 54, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (50/50), done.
Writing objects: 100% (54/54), 1.17 MiB | 2.05 MiB/s, done.
Total 54 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), done.
To https://github.com/ULL-MFP-AET-2021/p04-t0-aprender-jekyll-mrguezl.git
+ c948d4f...c1fe9a0 master -> main (forced update)
Branch 'master' set up to track remote branch 'main' from 'origin'.
$
--force
en git push
es un poco peligrosa. Fuerza a que, cualquiera que fuera la historia previa del repo remoto nuestros cambios se impongan y sean llevados al mismo.master:main
de esta forma le indicamos que nuestra rama local master
debe ser copiada en la rama del epo remoto con nombre main
-u
o --set-upstream
hace en este caso que se vincule la rama empujada master
del repo local con la rama main
remoto origin
. Los subsiguientes git push
no tendrán que especificar las ramas implicadasSi nos vamos al repo de la entrega en github deberíamos ver algo como esto:
A continuación activamos GitHub Pages del Repo (elegimos la rama main
y la raíz del proyecto)
Compruebe el buen funcionamiento. ¿Se ve mal? ¿funcionan bien los enlaces? Si algo va mal en este punto, recuerde abrir la cóonsola en las herramientas del desarrollador para ver los mensajes de error (En la página de despliegue, botón derecho -> inspect).
Recordemos poner el enlace al despliegue en la sección de descripción del repo
En el README.md
:
Añadimos un enlace al replit
Recuerde compartir el replit con el profesor (crguezl) y poner un enlace al mismo en el README.md
See the section References in this notebook
Having Different types of posts: Jekyll multiple post types
- work
-- _posts
--- portfolio01.md # The portfolio01.md belongs to the work category.
--- portfolio02.md # /work/portfolio02
- blog
-- _posts
--- blogitem01.md # The blogitem01.md belongs to the blog category.
--- blogitem02.md # /blog/blogitem02