diff --git a/cursos/dagger/00_actividades/01_modulo_1.md b/cursos/dagger/00_actividades/01_modulo_1.md
new file mode 100644
index 00000000..3bd47935
--- /dev/null
+++ b/cursos/dagger/00_actividades/01_modulo_1.md
@@ -0,0 +1,3 @@
+# Módulo 1: Primeros Pasos con Dagger
+
+##
diff --git a/cursos/dagger/01_dagger_101/01_que_es_dagger.md b/cursos/dagger/01_dagger_101/01_que_es_dagger.md
new file mode 100644
index 00000000..fc4f6029
--- /dev/null
+++ b/cursos/dagger/01_dagger_101/01_que_es_dagger.md
@@ -0,0 +1,62 @@
+# ¿Qué es dagger?
+
+
+
+Dagger es un herramienta que permite crear y correr funciones dentro de containers con el propósito principal de integrar y desplegar código.
+
+Gracias a su particular diseño y al empleo de buildkit permite el empleo de contenedores por cada función de nuestro workflow.
+
+En palabras de su creador: ```Dagger es el primer motor de containerización de funciones```.
+
+## ¿Por qué usar dagger?
+
+### La filosofía
+
+Dagger parte de una filosofía clara:
+
+1. La construcción y testeo de software es un proceso "íntimo" al propio desarrollo y debe acompañarlo en todas sus fases.
+2. El proceso debe poder expresarse en lenguajes conocidos (Go, NodeJS, Python...) y ser ejecutable en **cualquier** entorno (incluido el local).
+3. La ejecución de nuestro proceso de dagger, por su naturaleza repetitiva, debe ser rápida, evitando realizar pasos innecesarios y solo revisitando aquellos que sean necesarios.
+4. La construcción de nuestro proceso debería poderse beneficiar de piezas o módulos públicas o privadas puestas a nuestra disposición por la comunidad y/o terceros.
+
+Partiendo de esta filosofía, dagger ha sido construido de manera que:
+
+- Puede correr en todos los sitios (1) (2) exactamente igual que los contenedores de software.
+- La ejecución crea un (DAG)[https://en.wikipedia.org/wiki/Directed_acyclic_graph] (grafo acíclico directo) para poder cachear todos y cada uno de los pasos y evitar volverlos a realizar en sucesivas iteraciones (salvo que sea necesario).
+- Puede expresarse en los principales lenguajes de programación y beneficiarse de cualquier librería o módulo que tengamos a nuestra disposición en el stack elegido.
+- Permite el empleo de módulos y funciones de terceros (daggerverse) de manera eficiente y sin preocuparnos del lenguaje en que estén expresados.
+
+Estos principios de construcción se destilan en una herramienta con la que implimentar una clara *estrategia de plataforma*.
+
+### La estrategia
+
+Cuando el equipo de plataforma se enfrenta a gestionar los ciclos de construcción y despliegue del software de una organización se encuentra con el siguiente **dilema**:
+
+
+1. **Ansia de control**: la tentación de controlar de manera férrea los ciclos de integración y despliegue está justificada: a mayor control, mayor facilidad y seguridad en el trabajo de plataforma.
+2. **Necesidad de flexibilidad**: no obstante, los equipos de desarrollo lidian con problemas específicos y propios de cada micro-servicio que motivan su necesidad de dar soluciones **ad hoc**.
+
+Si el control es excesivo:
+
+1. Se forman "cuellos de botella" donde varios equipos de desarrollo están esperando a que el equipo de plataforma ofrezca una solución a su problema específico.
+2. El equipo de plataforma pierde eficacia al tener que adaptar su ciclo de trabajo a las necesidades propias de cada desarrollo pudiendo llegar a colapsar por inoperancia.
+
+Por otra parte, si la flexibilidad es total:
+
+1. Se crea una "jungla de tecnologías y soluciones" al permitir que cada equipo de desarrollo llegue a una solución específica para su problema lo cual hace inmantenible e ingestionable la plataforma a largo plazo.
+
+¿Cuál es, entonces, el equilibrio óptimo de control y flexibilidad? ¿Qué conjunto de herramientas pueden satisfacer ambas necesidades?
+
+Dagger aporta, aquí, su estrategia:
+
+* a) El equipo de plataforma emplea las características modulares y de neutralidad de lenguaje de dagger para ofrecer un conjunto de librerías y rutinas de trabajo en plataforma.
+Estos elementos constituyen el marco de trabajo que permite que el control resida en el equipo de plataforma.
+
+* b) Por otra parte, los equipos de desarrollo emplean los módulos y funciones ofrecidas por plataforma en sus propios workflows utilizando el lenguaje de su preferencia y adaptándolo a sus necesidades específicas, obteniendo así la flexibilidad que reclaman y, manteniéndose al mismo tiempo dentro del marco ofrecido por plataforma.
+
+
+
+
+
+
+
diff --git a/cursos/dagger/01_dagger_101/01_que_es_helm.md b/cursos/dagger/01_dagger_101/01_que_es_helm.md
new file mode 100755
index 00000000..dae8ca72
--- /dev/null
+++ b/cursos/dagger/01_dagger_101/01_que_es_helm.md
@@ -0,0 +1,81 @@
+# ¿Qué es HELM?
+
+
+
+Helm es una herramienta de gestión de artefactos de Kubernetes que permite instalar y gestionar conjuntos de recursos (services, deployments, jobs, configmaps...) como si de una sola aplicación se tratase.
+
+A veces llamado el apt/yum de Kubernetes, su empleo permite una mayor eficiencia y mejor gestión de las operaciones en k8s.
+
+## ¿Cuáles son los problemas que pretende resolver Helm?
+
+Todo lo que existe en kubernetes se expresa en forma de artefactos (objetos). Para que una aplicación funcione correctamente en Kubernetes, se pueden llegar a necesitar decenas e incluso centenas de estos objetos que además son dependientes entre sí.
+
+
+
+*Fig 1. Conjunto de artefactos para una posible instalación de wordpress*
+
+Tal y como se puede apreciar en la figura 1, una aplicación en kubernetes puede emplear una cantidad importante de artefactos que:
+
+1. Necesitan desplegarse conjuntamente para que la aplicación funcione.
+1. Es necesario borrar para "desinstalar" una aplicación.
+1. Pueden tener que modificarse (actualizarse) por grupo en determinados momentos.
+
+Una de las soluciones a las que se suele recurrir para poder realizar estas tareas es la de la expresión de todos los artefactos en un único fichero de yaml (separados entre sí por ---) y recurrir al kubectl para poder lanzarlos y borrarlos.
+
+```shell
+kubectl {create|apply|delete}
+```
+
+Esto, evidentemente, trae problemas a la hora de realizar modificaciones a ese bloque de código, así, se "inventan" soluciones como ficheros en bash que formateen cada artefacto y lo envíen al bloque final que se pasa al kubectl...
+
+Helm da respuesta a este problema mediante el concepto de release.
+
+Una release de Helm es una instalación de un grupo de artefactos de kubernetes que tratamos como si fuese una unidad:
+
+
+
+*Fig 2. Casos de uso de una release desde Helm*
+
+Al existir la release, nos podemos despreocupar del conjunto, grande o pequeño, de artefactos que la integran, y tratarlo todo como una unidad.
+
+> Helm abstrae la complejidad de las aplicaciones residentes en kubernetes y las presenta como **releases** sobre las que podemos operar sin preocuparnos de su estructura interna ni del número de artefactos que la componen.
+
+Un segundo problema que presentan las aplicaciones en K8s es su configuración. Los artefactos que componen una aplicación en kubernetes tienen una configuración que expresa su funcionamiento y su forma de interactuar con los demás. Normalmente, estos objetos suelen tener dos partes bien diferenciadas:
+- **Estructura**: elementos más o menos inmutables del objeto (Kind, Name, apiVersion, annotations, volumes...)
+
+- **Datos**: elementos más volátiles: valores de variables de entorno, puertos, límites de ejecución...
+
+Al administrar una aplicación en k8s, las operaciones suelen comportar la edición de los ficheros de artefactos (expresados en yaml) para modificar los valores (la parte de datos) generalmente sin tocar la estructura de los mismos. Al poco tiempo, se hace evidente la necesidad de usar algún tipo de sistema de [plantillas](https://es.wikipedia.org/wiki/Plantilla) que permita diferenciar la estructura (inmutable) de los artefactos de k8s de los datos (configuración volátil). Helm da una respuesta a este problema mediante un potente lenguaje de plantillas: el [go templates](https://pkg.go.dev/text/template?tab=doc).
+
+Mediante Helm, las aplicaciones (el grupo de artefactos que las conforman) se describen en un conjunto de plantillas, que conforman su estructura, que se pueden rellenar con la configuración que deseemos.
+
+Al conjunto de plantillas de artefactos que definen una aplicación concreta, en Helm se le da el nombre de **Chart**.
+
+
+
+*Fig 3. Chart de helm*
+
+> Helm expresa la estructura de una aplicación mediante un conjunto de pantillas al que denomina **Chart**
+
+Una chart de Helm, por tanto, no es un conjunto de artefactos de Kubernetes: es un conjunto de plantillas de artefactos al que, aplicando la configuración que deseemos, produce lo que realmente se desplegará en nuestro clúster; esto es, la **release**.
+
+
+
+*Fig 4. Esquema de conceptos en Helm*
+
+> Al aplicar nuestra configuración deseada a una chart obtenemos una release que es lo que realmente se desplegará en nuestro clúster de k8s.
+
+## ¿Por qué se le llama a Helm el apt/yum de Kubernetes?
+
+Como vimos en la sección anterior, Helm emplea charts que son conjuntos de plantillas para expresar la estructura de una aplicación para Kubernetes. Existe un [repositorio de charts](https://hub.helm.sh/) (al igual que existe para apt o yum) donde podemos encontrar plantillas para muchas aplicaciones y servicios (MariaDB, Wordpress, RabbitMQ, Elastic Search...)
+
+Podemos, por tanto, escoger la chart de cualquier aplicación del repositorio y, con un simple comando, instalarla en nuestro clúster. (Al igual que ocurre con apt o yum). Además, podremos establecer muchos de sus parámetros de configuración para definir el comportamiento que deseemos e instalarla.
+
+En un ejemplo, la chart de [MariaDB](https://hub.helm.sh/charts/bitnami/mariadb)
+
+## Tarea
+**Echa un vistazo a la sección de "parameters" de la chart de MariaDB. Identifica algunos de los valores configurables.**
+
+
+
+
diff --git a/cursos/dagger/01_dagger_101/02_empleo_basico_helm.md b/cursos/dagger/01_dagger_101/02_empleo_basico_helm.md
new file mode 100755
index 00000000..51e38460
--- /dev/null
+++ b/cursos/dagger/01_dagger_101/02_empleo_basico_helm.md
@@ -0,0 +1,88 @@
+# Empleo básico de Helm
+
+## De la instalación de Helm
+
+Helm funciona como un cli que podemos instalar en nuestro PC local (al igual que [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/)). De hecho, vamos a necesitar que kubectl esté instalado en el sistema donde queramos correr Helm.
+
+Para instalar Helm basta con seguir alguno de los métodos que se describen en esta [guía](https://helm.sh/docs/intro/install/).
+
+Una vez que lo tengamos instalado podremos ver su versión:
+```shell
+~ helm version --short
+v3.0.0-rc.3+g2ed2067
+```
+## De la interacción con las releases
+
+Como sabemos, mediante Helm vemos las entidades residentes en nuestro clúster en forma de releases.
+
+En esta sección veremos las formas básicas de controlarlas.
+
+### a) Listado de releases
+Parar obtener un listado de las releases de nuestro clúster, podemos recurrir a [helm list](https://helm.sh/docs/helm/helm_list/).
+
+Helm aisla las releases mediante [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) de kubernetes, así que, normalmente listamos las releases de un namespace concreto:
+
+```shell
+~ helm ls -n curso-helm
+
+NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
+mi-bbdd curso-helm 1 2020-07-19 17:45:19.944032634 +0000 UTC deployed mariadb-7.6.1 10.3.23
+```
+
+Como podemos ver, el listado de releases del namespace "curso-helm" nos da los siguientes resultados:
+- Una release llamada mi-bbdd.
+- El namespace al que pertenece.
+- El número de revisión (sobre esto hablaremos más adelante).
+- La fecha del último cambio.
+- Su estado (en este caso, desplegada).
+- El nombre y versión de la chart.
+- La versión de la aplicación (sobre las diferencias entre versión de chart y aplicación hablaremos en otra sección).
+
+Si queremos ver todas las releases de todos los namespaces de un clúster, podemos recurrir al flag `--all-namespaces`:
+
+```shell
+~ helm list --all-namespaces
+NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
+mi-bbdd curso-helm 1 2020-07-19 17:45:19.944032634 +0000 UTC deployed mariadb-7.6.1 10.3.23
+```
+
+> Helm distingue entre namespaces a la hora de interactuar con las **releases**. Por lo tanto, pueden existir dos releases con el mismo nombre en distintos namespaces.
+
+### b) Obtención de información de una release
+Además de su listado, Helm nos ofrece otros métodos para obtener información de las releases existentes en un clúster.
+
+Mediante el comando [helm get](https://helm.sh/docs/helm/helm_get/) se pueden obtener distintas facetas relativas a una release:
+
+```shell
+# obtener toda la información disponible relativa a una release
+~ helm get all mi-bbdd -n curso-helm
+
+# obtener el manifiesto de una release
+~ helm get manifest mi-bbdd -n curso-helm
+
+# obtener los valores de una release
+~ helm get values mi-bbdd -n curso-helm
+```
+
+Existen varias facetas recuperables de la información relativa a una release, por ahora nos basta con conocer:
+- **all**: toda la información disponible.
+- **manifest**: el renderizado completo en yaml de la release (un fichero único con todos los artefactos y sus valores tal y como está instalado en el clúster)
+- **values**: la configuración (la parte de datos) de la release, tanto la que aportamos nosotros a la hora de crearla como la que está establecida por defecto por parte de los desarrolladores de la chart.
+
+> Mediante el comando helm get se pueden obtener distintas facetas de la información existente sobre una release determinada.
+
+### c) Borrado de releases
+Para eliminar una release de nuestro clúster, basta con emplear [helm uninstall](https://helm.sh/docs/helm/helm_uninstall/).
+
+```shell
+~ helm uninstall mi-bbdd -n curso-helm
+release "mi-bbdd" uninstalled
+```
+
+Como se puede apreciar en el ejemplo, es necesario enviar como parámetros el nombre de la release y el namespace en el que está instalada.
+
+El comando elimina completamente la presencia de la release (borra todos los artefactos y su configuración del clúster) aunque esto se puede parametrizar como veremos más adelante.
+
+### d) Instalación de releases
+A esta parte dedicaremos la sección siguiente de la presente lección.
+
diff --git a/cursos/dagger/01_dagger_101/03_de_la_instalacion_de_releases.md b/cursos/dagger/01_dagger_101/03_de_la_instalacion_de_releases.md
new file mode 100755
index 00000000..620af166
--- /dev/null
+++ b/cursos/dagger/01_dagger_101/03_de_la_instalacion_de_releases.md
@@ -0,0 +1,23 @@
+# De la instalación de releases
+
+Como sabemos, Helm crea instalaciones (releases) de aplicaciones mediante la interpolación de la configuración que deseemos en un conjunto de plantillas que reciben el nombre de charts.
+
+Esta sección está dedicada al estudio de los pormenores del empleo de charts predefinidas para su instalación en un clúster de k8s.
+
+## Búsqueda de charts
+
+Como ya vimos en secciones anteriores, existe un repositorio oficial de charts de Helm en: [helm hub](https://hub.helm.sh/).
+
+El código de estas charts se puede encontrar normalmente en un repositorio público alojado en esta [dirección](https://github.com/helm/charts).
+
+### Tarea
+Prueba a entrar en helm hub y busca las siguientes charts:
+- MariaDB de bitnami.
+- Wordpress de bitnami.
+- La versión 7.7.1 del elastic stack.
+
+## Empleo de charts: los repos
+Existen, como hemos visto, repositorios públicos de charts de Helm que podemos usar.
+
+No obstante, y al igual que ocurre con las imágenes de docker, Helm necesita descargar la chart al sistema para poder emplearla.
+
diff --git a/cursos/dagger/README.md b/cursos/dagger/README.md
new file mode 100755
index 00000000..f0f4c10f
--- /dev/null
+++ b/cursos/dagger/README.md
@@ -0,0 +1,2 @@
+# Introducción
+
diff --git a/cursos/dagger/_cdn/copy-code.js b/cursos/dagger/_cdn/copy-code.js
new file mode 100755
index 00000000..86698602
--- /dev/null
+++ b/cursos/dagger/_cdn/copy-code.js
@@ -0,0 +1 @@
+!function () { "use strict"; function r(o) { return (r = "function" == typeof Symbol && "symbol" == typeof Symbol.iterator ? function (o) { return typeof o } : function (o) { return o && "function" == typeof Symbol && o.constructor === Symbol && o !== Symbol.prototype ? "symbol" : typeof o })(o) } !function (o, e) { void 0 === e && (e = {}); var t = e.insertAt; if (o && "undefined" != typeof document) { var n = document.head || document.getElementsByTagName("head")[0], c = document.createElement("style"); c.type = "text/css", "top" === t && n.firstChild ? n.insertBefore(c, n.firstChild) : n.appendChild(c), c.styleSheet ? c.styleSheet.cssText = o : c.appendChild(document.createTextNode(o)) } }(".docsify-copy-code-button,.docsify-copy-code-button span{cursor:pointer;transition:all .25s ease}.docsify-copy-code-button{position:absolute;z-index:1;top:0;right:0;overflow:visible;padding:.65em .8em;border:0;border-radius:0;outline:0;font-size:1em;background:grey;background:var(--theme-color,grey);color:#fff;opacity:0}.docsify-copy-code-button span{border-radius:3px;background:inherit;pointer-events:none}.docsify-copy-code-button .error,.docsify-copy-code-button .success{position:absolute;z-index:-100;top:50%;left:0;padding:.5em .65em;font-size:.825em;opacity:0;-webkit-transform:translateY(-50%);transform:translateY(-50%)}.docsify-copy-code-button.error .error,.docsify-copy-code-button.success .success{opacity:1;-webkit-transform:translate(-115%,-50%);transform:translate(-115%,-50%)}.docsify-copy-code-button:focus,pre:hover .docsify-copy-code-button{opacity:1}"), document.querySelector('link[href*="docsify-copy-code"]') && console.warn("[Deprecation] Link to external docsify-copy-code stylesheet is no longer necessary."), window.DocsifyCopyCodePlugin = { init: function () { return function (o, e) { o.ready(function () { console.warn("[Deprecation] Manually initializing docsify-copy-code using window.DocsifyCopyCodePlugin.init() is no longer necessary.") }) } } }, window.$docsify = window.$docsify || {}, window.$docsify.plugins = [function (o, s) { o.doneEach(function () { var o = Array.apply(null, document.querySelectorAll("pre[data-lang]")), c = { buttonText: "Copiar", errorText: "Error", successText: "Copiado" }; s.config.copyCode && Object.keys(c).forEach(function (t) { var n = s.config.copyCode[t]; "string" == typeof n ? c[t] = n : "object" === r(n) && Object.keys(n).some(function (o) { var e = -1 < location.href.indexOf(o); return c[t] = e ? n[o] : c[t], e }) }); var e = ['"].join(""); o.forEach(function (o) { o.insertAdjacentHTML("beforeend", e) }) }), o.mounted(function () { document.querySelector(".content").addEventListener("click", function (o) { if (o.target.classList.contains("docsify-copy-code-button")) { var e = "BUTTON" === o.target.tagName ? o.target : o.target.parentNode, t = document.createRange(), n = e.parentNode.querySelector("code"), c = window.getSelection(); t.selectNode(n), c.removeAllRanges(), c.addRange(t); try { document.execCommand("copy") && (e.classList.add("success"), setTimeout(function () { e.classList.remove("success") }, 1e3)) } catch (o) { console.error("docsify-copy-code: ".concat(o)), e.classList.add("error"), setTimeout(function () { e.classList.remove("error") }, 1e3) } "function" == typeof (c = window.getSelection()).removeRange ? c.removeRange(t) : "function" == typeof c.removeAllRanges && c.removeAllRanges() } }) }) }].concat(window.$docsify.plugins || []) }();
diff --git a/cursos/dagger/_cdn/motor.js b/cursos/dagger/_cdn/motor.js
new file mode 100755
index 00000000..4153578a
--- /dev/null
+++ b/cursos/dagger/_cdn/motor.js
@@ -0,0 +1 @@
+!function(){function s(n){var r=Object.create(null);return function(e){var t=c(e)?e:JSON.stringify(e);return r[t]||(r[t]=n(e))}}var a=s(function(e){return e.replace(/([A-Z])/g,function(e){return"-"+e.toLowerCase()})}),l=Object.prototype.hasOwnProperty,h=Object.assign||function(e){for(var t=arguments,n=1;n/gm),Ve=F(/^data-[\-\w.\u00B7-\uFFFF]/),Xe=F(/^aria-[\-\w]+$/),Ke=F(/^(?:(?:(?:f|ht)tps?|mailto|tel|callto|cid|xmpp):|[^a-z]|[a-z+.\-]+(?:[^a-z+.\-:]|$))/i),Qe=F(/^(?:\w+script|data):/i),Je=F(/[\u0000-\u0020\u00A0\u1680\u180E\u2000-\u2029\u205f\u3000]/g),et="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(e){return typeof e}:function(e){return e&&"function"==typeof Symbol&&e.constructor===Symbol&&e!==Symbol.prototype?"symbol":typeof e};function tt(e){if(Array.isArray(e)){for(var t=0,n=Array(e.length);t"+e;else{var r=Ce(e,/^[\s]+/);n=r&&r[0]}var i=b?b.createHTML(e):e;if(o)try{t=(new m).parseFromString(i,"text/html")}catch(e){}if(s&&ze(U,["title"]),!t||!t.documentElement){var a=(t=w.createHTMLDocument("")).body;a.parentNode.removeChild(a.parentNode.firstElementChild),a.outerHTML=i}return e&&n&&t.body.insertBefore(l.createTextNode(n),t.body.childNodes[0]||null),A.call(t,X?"html":"body")[0]}var O=Ge,$=Ye,M=Ve,N=Xe,z=Qe,P=Je,j=Ke,D=null,H=ze({},[].concat(tt(je),tt(De),tt(He),tt(qe),tt(Ie))),q=null,I=ze({},[].concat(tt(Ue),tt(Be),tt(Ze),tt(We))),U=null,B=null,Z=!0,W=!0,G=!1,Y=!1,V=!1,X=!1,K=!1,Q=!1,J=!1,ee=!1,te=!1,ne=!1,re=!0,ie=!0,ae=!1,oe={},se=ze({},["annotation-xml","audio","colgroup","desc","foreignobject","head","iframe","math","mi","mn","mo","ms","mtext","noembed","noframes","plaintext","script","style","svg","template","thead","title","video","xmp"]),le=ze({},["audio","video","img","source","image"]),ce=null,ue=ze({},["alt","class","for","id","label","name","pattern","placeholder","summary","title","value","style","xmlns"]),pe=null,de=l.createElement("form");d.isSupported&&(function(){try{F('
$');if(i){if("color"===i[2])n.style.background=i[1]+(i[3]||"");else{var a=i[1];_(n,"add","has-mask"),Q(i[1])||(a=re(this.router.getBasePath(),i[1])),n.style.backgroundImage="url("+a+")",n.style.backgroundSize="cover",n.style.backgroundPosition="center center"}r=r.replace(i[0],"")}this._renderTo(".cover-main",r),W()}else _(n,"remove","show")},Ht._updateRender=function(){!function(e){var t=m(".app-name-link"),n=e.config.nameLink,r=e.route.path;if(t)if(c(e.config.nameLink))t.setAttribute("href",n);else if("object"==typeof n){var i=Object.keys(n).filter(function(e){return-1": ">", '"': """, "'": "'" }; return String(e).replace(/[&<>"']/g, function (e) { return n[e] }) } function h(e) { return e.text || "table" !== e.type || (e.text = e.cells.map(function (e) { return e.join(" | ") }).join(" |\n ")), e.text } function u(i, e, o, a) { void 0 === e && (e = ""); var s, n = window.marked.lexer(e), c = window.Docsify.slugify, d = {}; return n.forEach(function (e) { if ("heading" === e.type && e.depth <= a) { var n = function (e) { void 0 === e && (e = ""); var r = {}; return { str: e = e && e.replace(/^'/, "").replace(/'$/, "").replace(/(?:^|\s):([\w-]+:?)=?([\w-%]+)?/g, function (e, n, t) { return -1 === n.indexOf(":") ? (r[n] = t && t.replace(/"/g, "") || !0, "") : e }).trim(), config: r } }(e.text), t = n.str, r = n.config; s = r.id ? o.toURL(i, { id: c(r.id) }) : o.toURL(i, { id: c(p(e.text)) }), d[s] = { slug: s, title: t, body: "" } } else { if (!s) return; d[s] ? d[s].body ? (e.text = h(e), d[s].body += "\n" + (e.text || "")) : (e.text = h(e), d[s].body = d[s].body ? d[s].body + e.text : e.text) : d[s] = { slug: s, title: "", body: "" } } }), c.clear(), d } function c(e) { var i = [], o = []; Object.keys(d).forEach(function (n) { o = o.concat(Object.keys(d[n]).map(function (e) { return d[n][e] })) }); var a = (e = e.trim()).split(/[\s\-,\\/]+/); 1 !== a.length && (a = [].concat(e, a)); function n(e) { var n = o[e], s = 0, c = "", d = n.title && n.title.trim(), l = n.body && n.body.trim(), t = n.slug || ""; if (d && (a.forEach(function (e) { var n, t = new RegExp(e.replace(/[|\\{}()[\]^$+*?.]/g, "\\$&"), "gi"), r = -1; if (n = d ? d.search(t) : -1, r = l ? l.search(t) : -1, 0 <= n || 0 <= r) { s += 0 <= n ? 3 : 0 <= r ? 2 : 0, r < 0 && (r = 0); var i, o = 0; o = 0 == (i = r < 11 ? 0 : r - 10) ? 70 : r + e.length + 60, l && o > l.length && (o = l.length); var a = "..." + p(l).substring(i, o).replace(t, '' + e + "") + "..."; c += a } }), 0 < s)) { var r = { title: p(d), content: l ? c : "", url: t, score: s }; i.push(r) } } for (var t = 0; t < o.length; t++)n(t); return i.sort(function (e, n) { return n.score - e.score }) } function o(t, r) { var e = "auto" === t.paths, i = function (e) { return e ? l.EXPIRE_KEY + "/" + e : l.EXPIRE_KEY }(t.namespace), o = function (e) { return e ? l.INDEX_KEY + "/" + e : l.INDEX_KEY }(t.namespace), n = localStorage.getItem(i) < Date.now(); if (d = JSON.parse(localStorage.getItem(o)), n) d = {}; else if (!e) return; var a = e ? function (i) { var o = []; return Docsify.dom.findAll(".sidebar-nav a:not(.section-link):not([data-nosearch])").forEach(function (e) { var n = e.href, t = e.getAttribute("href"), r = i.parse(n).path; r && -1 === o.indexOf(r) && !Docsify.util.isAbsolutePath(t) && o.push(r) }), o }(r.router) : t.paths, s = a.length, c = 0; a.forEach(function (n) { if (d[n]) return c++; Docsify.get(r.router.getFile(n), !1, r.config.requestHeaders).then(function (e) { d[n] = u(n, e, r.router, t.depth), s === ++c && function (e, n, t) { localStorage.setItem(n, Date.now() + e), localStorage.setItem(t, JSON.stringify(d)) }(t.maxAge, i, o) }) }) } var f, m = ""; function i(e) { var n = Docsify.dom.find("div.search"), t = Docsify.dom.find(n, ".results-panel"), r = Docsify.dom.find(n, ".clear-button"), i = Docsify.dom.find(".sidebar-nav"), o = Docsify.dom.find(".app-name"); if (!e) return t.classList.remove("show"), r.classList.remove("show"), t.innerHTML = "", void (f.hideOtherSidebarContent && (i.classList.remove("hide"), o.classList.remove("hide"))); var a = c(e), s = ""; a.forEach(function (e) { s += '