Aldán Creo - Búsqueda de texto completo (FTS) en tu sitio web – mi proyecto de Google Summer of Code

Hola, hoy vengo a hablar sobre cómo podemos realizar búsquedas de texto completo, también conocidas en inglés como Full Text Search, en nuestra base de datos. Este es mi proyecto del Google Summer of Code, así que en la presentación lo que voy a hacer va a ser hablar sobre la búsqueda de texto completo. Por un lado, un apartado más técnico y después voy a hablar sobre el Google Summer of Code. Voy a dedicar otra parte a hablar sobre el programa en sí. Entonces, antes de empezar, me gustaría destacar que esta presentación tiene un nivel técnico básico, es decir. No voy a tratar conceptos avanzados y los pocos fragmentos de código que voy a incluir los voy a explicar para que nadie se pierda.

Por tanto, cualquier persona que más o menos sepa un poco de Python va a poder seguir sin problema la presentación. Ahora, vamos a empezar ya con una introducción breve sobre mí. Yo soy Aldán Creo Mariño , estoy estudiando ingeniería informática en la Universidad de Santiago de Compostela. Y ahora mismo, donde estoy estudiando, es en la Universidad Sorbona. Estoy haciendo Erasmus allí. España aparece en ese mapa en rojo porque es mi país de origen. Siempre he sido un apasionado de los lenguajes de programación y llevo programando ya bastantes años, desde que era pequeño, de hecho. Empecé con Lab View, que es un lenguaje

con bloques visual. And then continue with Visual Basic, which is the first language that I wanted. And I investigated after my applications of Android con Java. Ya a los 14 años. Luego, con 16 años, empecé a experimentar con Python, con C y con muchos otros lenguajes que no salen en la lista, pero lo cierto es que sí que me apasiona aprender nuevos lenguajes. Me encantan los ordenadores y precisamente por eso siempre he querido realizar un programa como el Google Summer of Code. Entonces, Esto precisamente se relaciona con uno de mis intereses principales, que es el Big Data.

La búsqueda de texto completo tiene muchísimo que ver con esto, con el tema sobre todo de la escalabilidad. Entonces, mis intereses principales son el Big Data y la inteligencia artificial, y mi proyecto tiene muchísimo que ver con este campo. Ahora me gustaría detallar brevemente cuál es la estructura que voy a seguir en esta presentación. Hemos empezado haciendo una introducción breve sobre mí. Y ahora de lo que vamos a hablar es acerca de qué es Wactil, ya que esta es una presentación orientada a un público de nivel básico. Después de lo que hablaremos es sobre el programa del Google Summer of Code en sí y más adelante hablaremos sobre un tema más técnico que es la búsqueda de texto completo en Wagtail, cómo se instala y cómo se usa.

Después hablaré sobre mi experiencia en el Google Summer of Code, daré también consejos para el mismo y finalmente acabaré con dos partes más breves que serán lo que nos ofrece el Google Summer of Code. Code y cómo podemos apuntarnos al Google Summer of Code. Entonces, ¿qué es Wagtail? Bueno, dicho en tres palabras sencillas, Wacteal es un CMS sobre Django. Es decir, es un sistema gestor de contenidos que funciona sobre Django. ¿Qué es un sistema gestor de contenidos? Bueno, un sistema gestor de contenidos lo que nos permite es desvincular lo que es la creación de las páginas web en código. De su

gestión por parte de los usuarios. Es decir, por ejemplo, en una agencia de noticias, los periodistas quieren poder publicar noticias en la página web Sin necesidad de tener que escribir el código HTML ellos mismos. Entonces, aquí es donde entra un CMS. Un CMS lo que nos permite es que los periodistas vayan a un panel de administración online. Y escriban ahí sus noticias, el texto de la noticia, le den a publicar y entonces en ese momento se muestra en directo la noticia en el sitio web. Esto, como decía, lo que hace es desvincular el código de lo que es la gestión del contenido en sí. Y por eso estos sistemas se utilizan ampliamente en todo tipo de sitios web. WagTil, concretamente, es uno de los sistemas gestores de contenidos que existen para Django

y. Una de las ventajas más relevantes que nos ofrece es, en primer lugar, que es open source, es decir, de código abierto. Además, está actualizado regularmente, cada dos meses sale una nueva versión, con lo cual tenemos nuevas funcionalidades y el código se refresca constantemente. Es fácil y rápido desarrollar en Wagtail. Esto es de cara a las personas que estén encargadas de desarrollar el código en sí, utilizando Wagtail. Después, de cara a los usuarios finales, es fácil de usar. Los periodistas que están en la agencia de noticias. No van a tener ningún problema a la hora de redactar sus propias noticias porque Wactile es muy intuitivo.

Y aparte, está usado por miles de organizaciones, entre ellas, por ejemplo, Google, la NASA o el Sistema Nacional de Salud del Reino Unido. Todas estas organizaciones saben lo confiable que es Wagtail y por eso mismo hoy en día lo están usando. En wactil. io tenemos más información sobre lo que es este sistema gestor de contenidos. Y no le voy a dedicar más tiempo a esta parte, pero sí que es verdad que quiero incitar a todo el mundo a que lo pruebe y a que descubra todas sus bondades, porque son muchas y realmente Yo me he enamorado de este sistema. Precisamente por ello, es en parte por lo que he decidido hacer mi proyecto del Google Summer of Code en Wagtail.

Y entonces, ¿qué es el Google Summer of Code? Bueno, aquí tenemos una imagen donde vemos a un montón de personas reunidas presencialmente, pero realmente no es un programa presencial. Tal como dice su propia página web, el Google Summer of Code es un programa global que busca atraer a los estudiantes. Universitarios al mundo del open source. Es un programa online, es decir, nosotros trabajamos de forma telemática. Y es un programa realmente importante, es un programa que tiene un alcance grandísimo y para ello me gustaría dar algunas cifras sobre este programa para que nos hagamos a la idea de lo importante que es. Concretamente, los estudiantes que hacemos este programa le dedicamos unas 10 semanas de trabajo

Durante junio y agosto, aunque esto queda un poco a nuestro criterio, es decir, nosotros lo manejamos según nuestra propia disponibilidad, pero más o menos hay que dedicarle 10 semanas a este programa. Y cada semana trabajar en torno a 18 horas, aunque de nuevo esto depende mucho de las circunstancias individuales de cada persona. En el Google Summer of Code participan o han participado más de 715 organizaciones open source. Es un número tremendo. Pero más tremendo aún es el número de estudiantes que han participado, que son más de 16. 000. Son muchísimos estudiantes a lo largo de muchos años, porque este programa lleva existiendo desde el año 2005. Como decía, alcanza a todo el mundo

y además ofrece una cantidad de dinero bastante considerable como incentivo económico para que se apunten estudiantes a este programa. Son unos 2. 000 euros o dólares en general, pero lo cierto es que esta cantidad se ajusta. Con respecto a lo que es el nivel de vida de cada país. En países con mucho poder adquisitivo se da más dinero y en países con menor poder adquisitivo la cantidad baja. Voy a comentar ahora dos cosas rápidas. En primer lugar, quién es el público objetivo del Google Summer of Code. Por supuesto, están los estudiantes universitarios, pero después también hay un público del que muchas veces nos olvidamos. Que son los programadores veteranos. ¿En qué entran aquí los programadores veteranos?

Los programadores de este estilo son mentores en el Google Summer of Code y precisamente a este colectivo le voy a dedicar una parte de la presentación después. Y finalmente ya, simplemente un detalle concreto es que me gustaría destacar cómo participa Wagtail en el Google Summer of Code. Wagtail no participa como una organización per se. En este programa, sino que lo que hace es aliarse con Django para que a través de la Django Software Foundation se envíen a los estudiantes a este programa. Por tanto, Django aquí lo que hace es actuar como una especie de intermediario. Ahora, pasamos a una parte más técnica, que es la búsqueda de texto completo en Wagtail.

No voy a explicar concretamente qué es la búsqueda de texto completo de forma muy profunda, porque todo esto ya está explicado en otra charla de hace dos años. Search from the Ground Up que es súper extensa, súper detallada y es buenísima. Y os recomiendo muchísimo que si os quedáis interesados por esta charla, vayáis a ver esa otra charla porque es muy muy formativa y de verdad que es tremendamente ilustrativa. Se centra en el caso de Postgres, pero sí que nos permite tener una idea en general sobre cómo funciona la búsqueda de texto completo. Entonces yo lo que voy a dar es una idea básica sobre qué es y cómo funciona.

Y para explicar la búsqueda de texto completo normalmente se pone un ejemplo típico. Aquí lo que vemos es una página de una panadería sencilla donde tenemos arriba, y esta es la parte importante, una caja de búsqueda que pone pan. Es decir, estamos buscando por pan, no bread. Vale, pues nosotros escribimos ahí Bread y le damos a buscar. Y lo que esperamos es que un backend de búsqueda haga magia por detrás. para conseguir encontrar las páginas que nos hablan sobre pan. Entonces así es como llegamos a una página de resultados de búsqueda donde nos aparecen las entradas que nos hablan sobre pan en algún momento. Vale, el backend de búsqueda es lo que yo he estado desarrollando.

Antes de que yo llegase a Wagtail, había un backend de búsqueda. Es decir, vamos a hablar ahora sobre la situación previa. ¿Qué había antes de mi proyecto? Lo que había eran dos posibles situaciones dependiendo de si usábamos Postgres o si usábamos SQLite o MySQL. Concretamente, si usábamos Postgres teníamos tres posibilidades. Ahí solo pongo dos en la lista porque una de ellas es un backend genérico que sale en la derecha. Y no es muy relevante, pero realmente en Postgres tenemos tres posibilidades. Tenemos la posibilidad de usar un backend genérico que explicaré ahora. Teníamos la posibilidad de usar Postgres Search, que es una especialización del backend. Para Postgres, y después teníamos la posibilidad de usar Elasticsearch, que también voy a explicar ahora en un momento.

Después, si usábamos otro tipo de sistemas de bases de datos, entonces lo único que teníamos eran dos posibilidades: un backend genérico. Y Elasticsearch. El backend genérico lo que hacía era utilizar iContains, que básicamente es un operador SQL que busca por un término de búsqueda sin tener en cuenta si están mayúsculas o minúsculas, por ejemplo, si buscamos por PAN. Va a buscar todas las entradas que incluyan la palabra pan, independientemente de que estén en mayúsculas o en minúsculas, y después teníamos Elasticsearch. Que esto sigue existiendo hoy en día y es un sistema muy complejo, muy avanzado, muy bueno también, pero que tiene la gran desventaja de que es complejo de configurar. Es bastante difícil porque implica. configurar un nuevo servidor

que trabaje de forma independiente y no está digamos diseñado para todos los públicos en el sentido de que sitios web Pequeños no van a utilizar Elasticsearch porque al final es demasiado trabajo configurarlo para las necesidades que tienen. Entonces, como vemos en la columna de la izquierda, para el caso de utilizar bases de datos Postgres, lo que teníamos era un backend concreto, un backend que utilizaba instrucciones SQL disponibles solo en Postgres. Para realizar búsquedas de texto completo. Esto era muy positivo y precisamente lo que permitía era tener buenos resultados de búsqueda en los sitios web que usaban esta aplicación.

Y que estaban utilizando bases de datos Postgres. Lo que pasa es que en el caso de sitios web que utilizaban bases de datos SQLite o MySQL, entonces lo que teníamos simplemente era este backend genérico. Que es súper ineficiente porque no utilizaba ningún tipo de índices ni ningún tipo de optimización para realizar las búsquedas. Y entonces, por ejemplo, cada vez que buscábamos una página que incluyera la palabra pan , Tendría que realizar la búsqueda a través de todas las entradas de la base de datos para encontrar la palabra pan. Y esto, cuando va creciendo, por ejemplo, si tenemos una agencia de noticias que cada vez tiene más noticias, cuando va creciendo,. Se vuelve cada vez más complejo y más costoso. Por lo tanto, la búsqueda era cada vez más ineficiente.

Es decir, en Postgres teníamos una buena situación, pero en el resto de sistemas de bases de datos, no. Y aquí es donde se centró mi proyecto, en conseguir crear nuevos backends de búsqueda para los sistemas de bases de datos que no tenían un backend propio, que no tenían un backend que. Utilizaba las propias instrucciones SQL disponibles en esos sistemas de bases de datos, porque cambian según cada sistema , para mejorar los resultados de búsqueda. Entonces, ahora mismo, después de mi proyecto del Google Summer of Code, lo que tenemos es que en cualquier tipo de base de datos vamos a tener un backend específico, por ejemplo, en Postgres. Un backend como el que comentaba antes, o después en MySQL, un backend

que utilice los índices específicos que se utilizan en MySQL, o después en SQLite, pues un backend que se encargue de crear tablas virtuales. En las que almacenar las propias entradas para poder realizar búsquedas de texto completo Y en definitiva, backends que se adapten a cada base de datos. Este ha sido mi proyecto del Google Summer of Code, conseguir crear. Un backend específico para cada base de datos y esto integrarlo en un backend conjunto. Es decir, un backend que yo utilizo de forma Conjunta independientemente de la base de datos que yo utilice, y después, en el momento en el que se ejecutan las búsquedas de texto completo, se utilice

un método u otro dependiendo de qué base de datos estoy utilizando. Por supuesto, Elasticsearch siempre queda ahí, pero no voy a entrar en ese tema porque no afectaba a mi proyecto. Con lo cual, lo que comentaba de la selección automática del backend es precisamente la cuestión de que nosotros tenemos ahora un único backend. Para realizar búsquedas de texto completo en nuestra base de datos, utilizando las propias funciones de la base de datos. Y en tiempo de ejecución se va a seleccionar el backend específico que queremos utilizar dependiendo de nuestro sistema de bases de datos. Por ejemplo, si estoy utilizando Postgres se va a utilizar el backend de Postgres o si estoy utilizando SQLite, pues se va a utilizar el de SQLite. Se selecciona automáticamente el mejor backend

para nuestro caso. Entonces ahora voy a hablar sobre cómo podemos instalar el backend de búsqueda y cómo podemos utilizarlo. Para configurar el backend de búsqueda, lo primero que tenemos que ver es cómo indicarle a Wagtail que queremos utilizar este nuevo backend. Es muy sencillo, no es necesario especificar el backend como estaba indicando porque se selecciona automáticamente y lo único que tenemos que hacer es crear una variable que es WagDivSearch Backends, donde especificamos que el backend por defecto es. wactil. search. backends. database. Y ya está, es así de sencillo. Después, bueno, ahora lo que vamos a definir es un modelo de prueba para usarlo simplemente para nuestros ejemplos. Entonces

aquí definimos simplemente un modelo en el que tenemos un campo de texto y abajo lo que definimos es una serie de. De campos de búsqueda, en este caso solo un campo de búsqueda, que es el que se va a indexar, es decir, cuando realicemos búsquedas, lo que se va a buscar es en este campo. Podríamos poner varios campos, pero en este caso simplemente vamos a buscar en el campo Que se llama Body. Entonces, ahora que tenemos definido un modelo con un campo que es buscable, Simplemente tenemos que ejecutar los dos comandos típicos, MakeMigrations y Migrate, y bueno, ahora vamos a suponer que los objetos ya están creados, es decir, que hemos creado instancias de foo. Y antes de buscar los objetos es importante que nos acordemos de actualizar el índice de búsqueda.

Esto lo hacemos con el comando updateIndex, que nos devolverá una salida de este estilo. Y ahora sí que sí vamos a ver cómo se hacen las búsquedas. Por ejemplo, podemos hacerlo con un formulario en el que El usuario escribe su consulta y entonces nos lleva a una ruta que está ahí indicada, barra search. Y vamos a realizar una búsqueda en nuestra página web. Cuando realicemos una petición a esta dirección Es decir, a barra search lo que se nos hace es dirigirnos a la función que se encarga de procesar nuestra solicitud de búsqueda que tenemos justo aquí.

Es decir, esta función, la función search, de lo que se encarga es de coger todas las instancias de foo. Bueno, le ha llegado por supuesto la solicitud, se la pasamos como parámetro. Coge todas las instancias de foo y lo que hace es buscar en base a nuestra solicitud. Por ejemplo, bread. Pues busca todos los objetos foo por la palabra bread. Y después lo que hace es devolvernos una página renderizada donde nos aparecen los resultados de búsqueda Por supuesto, tenemos que ejecutar el servidor para que funcione y si lo hacemos, entonces en este caso lo que tendríamos es una página, como digo, de resultados de búsqueda. En la que vemos todas las instancias de páginas que nos hablan sobre pan.

Entonces, ¿cuáles son las ventajas del nuevo backend? Bueno, en primer lugar, que tiene más eficiencia porque utiliza Las funciones propias de los sistemas de bases de datos y además, como utiliza índices, no tenemos que recorrer todas las entradas de cada vez. Además, nos ofrece mejores resultados Precisamente por esto que comentaba, de que estamos utilizando las funciones propias de cada sistema de bases de datos, mayor escalabilidad por esta misma razón. Como decía, estamos usando las herramientas nativas y además lo que comentaba de que tenemos una selección automática del back-end a utilizar. Ahora, sobre lo que voy a hablar es sobre mi experiencia en el Google Summer of Code y voy a hablar sobre cuáles son las etapas que vive un estudiante.

en este programa. Entonces, la primera parte es lo que se llama la búsqueda de proyectos. Básicamente llega un punto del año en el que se anuncian cuáles son las organizaciones Que ofrecen proyectos y son muchísimas. Aquí he hecho una captura de pantalla donde se ven solo algunas, y yo, concretamente, empecé a mirar las organizaciones que había y de repente vi que estaba la Django Software Foundation. Entonces dije, esta organización me interesa, voy a ver qué proyectos me ofrece. Entonces llega con entrar en la propia página de la organización en sí. Ver las ideas que nos ofrece, y justo aquí, en este caso, yo me encontré con la posibilidad de trabajar en el CMS de Wagtail, donde había un proyecto que era el proyecto que he desarrollado yo.

Entonces, una vez que decidimos nuestro proyecto, es momento de tener un primer contacto con la comunidad. Realmente sobre esto daré consejos ya después, pero bueno, la idea que nos tenemos que quedar aquí es que simplemente se trata de empezar a conocer a la comunidad y al mismo tiempo de hacer que nos conozcan. Después lo que tenemos que empezar a hacer es redactar una propuesta, una propuesta que debe tener una serie de contenidos detallados. Que son la información personal típica que podremos encontrar en cualquier tipo de propuesta. Luego, los beneficios que aporta la comunidad, por ejemplo, lo que he comentado yo sobre el backend de búsqueda, los entregables, lo que nosotros vamos a. Conseguimos

presentar al final de nuestro proyecto, después un plan de trabajo donde detallemos según el momento qué es lo que vamos a realizar y después otros trabajos relevantes que nosotros hayamos hecho. Nuestra propuesta primero la realizaremos en Google Drive y le presentaremos un borrador a la organización de software que esté llevando nuestro proyecto. para que nos dé su opinión y después, finalmente, después de que nos la revisen, presentaremos un PDF con una propuesta final que la organización en sí decidirá si acepta o no. Suponiendo que nuestro proyecto se acepta, entonces pasamos a la fase de integración en la comunidad que se le llama Community Bonding. Y básicamente aquí lo que hacemos es

pues. ultimar detalles , planearlo todo, planear cuándo va a haber reuniones, a qué horas, con qué frecuencia , Detallar el calendario de trabajo , configurar todo el entorno de desarrollo del estudiante para que esté listo para empezar en el momento en el que comiencen las semanas de. De trabajo, conocer al resto de miembros de la organización. En definitiva , ultimar todos los factores que influyen en nuestro proyecto. Entonces, una vez que sabemos todo esto, llega el momento de desarrollar el proyecto y hay un momento concreto

en el año en el que Google nos indicará que podemos empezar a trabajar Como dije antes, son 10 semanas de trabajo y aquí es realmente importante tener lo que se llaman milestones, es decir, Puntos clave en los que conseguimos grandes avances cada dos, tres semanas, y además es muy importante que realicemos entregas de código funcional de forma más o menos regular. Además, entre los maestros milestones también es bastante recomendable que entreguemos código. Cuanto más nos comuniquemos con nuestro mentor, es mucho mejor. Pero bueno, sobre todo esto ya detallaré después en la parte de consejos sobre el Google Summer of Code. Es importante destacar que tenemos evaluaciones a la mitad del proyecto y a la final

del proyecto. Y una vez que hayan pasado las 10 semanas, llegamos al fin del proyecto. Donde tendremos una fase final de evaluación y donde entregaremos nuestro código para que sea revisado y que nuestro mentor nos ponga una calificación de aprobado o no. Redactaremos una memoria del proyecto, por supuesto, donde detallaremos lo que hemos hecho y es importante normalmente continuar en la comunidad open source, que es un poco el objetivo del Google Summer of Code, que nos integremos en la comunidad. Entonces, ahora que ya sabemos cómo funciona el programa, me gustaría dar algunos consejos concretos sobre el Google Summer of Code. En primer lugar, ¿cómo conectar con la comunidad?

Bueno, es muy importante unirnos a todos los medios de difusión que existan. Las listas de correo, por ejemplo, son muy importantes. Además, tienen un archivo normalmente que podemos leer para ponernos en contexto. También, claro, los foros, los chats. Son realmente lugares donde nos podemos formar. Después , leer otros proyectos que se hayan realizado en la organización previamente También familiarizarnos con la con la documentación de nuestro proyecto y en general Entrar en contacto con todos los miembros de algún modo.

¿Cómo conectamos? Bueno, más consejos. Podemos empezar con un mensaje de introducción nuestro, es decir, en el foro. Podemos realizar una breve introducción en inglés, por supuesto. Podemos hacer y responder preguntas que se hagan en los foros. Y sobre todo es muy importante que estemos abiertos a aprender, que siempre seamos humildes, que siempre seamos educados con el resto de comunidad, para que tengamos la mejor integración posible. Entonces, ahora me gustaría dedicar un breve momento a hablar sobre qué es lo mejor y lo peor del Google Summer of Code, más allá de lo que ya he comentado.

Lo mejor, por supuesto, es que desarrollamos contactos y conexiones, y esto lo digo en el sentido de que nos integramos en el mundo del open source, así que después del Google Summer of Code podremos seguir metidos en Este mundo. También nos sentiremos más cómodos para realizar nuevas contribuciones en otros proyectos. Por supuesto, aprenderemos nuevos conocimientos, nos volveremos expertos en nuestro tema y además tendremos un importante Satisfacción personal. La peor parte del Google Summer of Code, por supuesto, es la inversión de tiempo que nos implica, es decir, tenemos que dedicar nuestro verano, pero tampoco es tan malo teniendo en cuenta que al fin y al cabo lo hacemos porque queremos. Es decir, no es un sufrimiento, sino que realmente es un proyecto apasionante que estamos realizando como si fuera nuestro propio bebé.

Entonces Es malo en el sentido de que a veces puede quitarnos parte de las vacaciones, pero realmente es muy positivo porque estamos haciendo Un proyecto que nos aporta muchísimo. Sí que es cierto que a veces puede tener momentos de estrés, especialmente hacia las partes del medio y del final, cuando se acercan las evaluaciones, y podemos estar perdidos, es normal estar perdidos, de hecho, en el Google Summer of Code al principio, sobre todo, porque todo este mundo es nuevo. Llegamos aquí para formarnos al fin y al cabo. Como digo, hay que sobre todo llevar una actitud proactiva y estar dispuestos a aprender. Entonces, hay una serie de errores típicos que me gustaría destacar aquí

y lo hago un poco en forma de consejos. Por ejemplo, ¿cuántas propuestas deberíamos enviar? Podemos enviar hasta tres propuestas, pero es importante que tengamos en cuenta que la calidad es más importante que la cantidad. Solo vamos a hacer una propuesta al final. Entonces. Es mucho mejor que enviemos una que es de muy buena calidad que que enviemos tres mediocres. Además, también es recomendable informar a las organizaciones. Si entregamos varias propuestas de que estamos entregando propuestas en otras organizaciones, simplemente por un tema de transparencia. Después, también tenemos que ser transparentes en cuanto a que, por ejemplo, si tenemos unas vacaciones en mitad del verano, deberíamos avisarlo para poder planear nuestro horario en base a eso.

Tampoco debemos coger un trabajo de verano, porque como indicaba antes, ya sabemos que vamos a tener que trabajar bastante en el Google Summer of Code. Y nos implica un compromiso bastante fuerte, esta inversión de tiempo de la que hablaba antes. Entonces, tenemos que tener en cuenta que el Google Summer Code va a ser nuestra prioridad número uno en el verano. Otro error común es intentar abarcar demasiado, porque es tentador hacer una propuesta de proyecto ambiciosa, porque realmente parece que es más probable que vaya a ser aceptada, pero en realidad lo que ven las organizaciones es que precisamente. Es más probable que no cumplamos nuestros objetivos si intentamos abarcar demasiado. Así que realmente es mejor ser humildes en lo que podemos cumplir para que parezca una propuesta más realista.

Luego, es muy recomendable estar al día en las fechas y para esto recomiendo muchísimo marcarse mini objetivos cada semana una serie de objetivos con el objetivo final en mente, por supuesto. Luego, esto de ser precavidos con el plan, a lo que se refiere es a que pueden surgir contratiempos. Por ejemplo, en mi proyecto, cuando estaba desarrollando el backend de SQLite, me encontré de repente con que no existía soporte para el operador NOT. Y claro, yo siempre había supuesto que ese operador existiría porque es un operador estándar y es un operador básico. Entonces, por un motivo concreto no existía en SQLite. Y tuve que dedicar más tiempo a intentar encontrar una forma alternativa de implementar este operador.

La idea es que siempre surgen contratiempos y si desarrollamos un plan. . En el que no dejamos margen de reacción, podemos acabar teniendo problemas al final en cuanto a nuestro proyecto Entonces, siempre es mejor dejarnos un cierto margen de seguridad. Luego, es recomendable empezar a programar en el momento adecuado, es decir, ni demasiado pronto ni demasiado tarde. Deberíamos desarrollar un plan mental de lo que queremos hacer, no empezar a escribir código a lo loco, pero tampoco deberíamos retrasar demasiado el momento de escribir código. A veces nos puede ayudar mucho empezar a escribir código e ir mejorándolo. Iterativamente, en vez de simplemente intentar

conseguir algo perfecto desde el primer momento. Por eso, ni demasiado pronto, ni demasiado tarde. Después, pedir ayuda a tiempo. Tenemos una comunidad, tenemos a nuestros mentores, podemos preguntar en internet. Todos estos recursos están para nosotros. Y es muy recomendable que los utilicemos. En primer lugar, porque son 10 semanas y no tenemos mucho tiempo para perder. Y en segundo lugar, porque nos ayuda precisamente a ganar familiaridad con lo que es el mundo de lo open source, con lo cual es muchísimo mejor. Que recurramos a otras figuras para pedirles ayuda en vez de tratar de sacarlo todo por nuestra cuenta. Luego, escribir tests y cumplir con los estándares de la comunidad es muy importante. Debemos revisar cuáles son porque varían según cada organización.

Y, en definitiva, lo que destacaría como ideas generales es que debemos ir al Google Summer of Code con una actitud honesta, debemos ser realistas también. Debemos ser humildes, amables, estar dispuestos a aprender todo el tiempo y también, muy importante, ser responsables y ser constantes. Todo esto, además, se complementa bastante bien con la guía del Google Summer of Code, donde incluye algunos consejos adicionales a los que he comentado. Y desarrolla un poco más algunos de los aspectos por los que he pasado, así que recomiendo bastante consultarla y es el enlace que vemos en pantalla. ¿Qué te ofrece el Google Summer of Code? Bueno, tenemos dos públicos principales. En primer lugar, los estudiantes universitarios.

Los estudiantes universitari disfrutar de una experiencia increíble durante sus vacaciones. Al mismo tiempo que obtienen una formación real que pueden aplicar después en sus estudios. Tendrán una gran satisfacción por desarrollar un proyecto que afecta a las vidas de personas reales y además ganarán una familiaridad tremenda con el mundo open source, lo cual les ayudará muchísimo en su carrera. Aparte, conseguirán mejorar su currículum tremendamente y todo esto son ventajas que solo les ofrece el Google Summer of Code. En segundo lugar, ¿qué ofrece el Google Summer of Code a los veteranos? Bueno, en primer lugar, una ventaja clave es que Les permite tener la posibilidad de traer a nuevas personas al mundo open source, es decir, ayudar a estudiantes a descubrir este mundillo.

Pero aparte también tiene una ventaja importante que es que, en muchos casos, los estudiantes que vienen desarrollan proyectos que estaban dejados de lado porque no había suficiente gente para desarrollarlos. Precisamente así conseguimos Reavivar muchos proyectos que estaban dejados de lado. Luego mejorar las relaciones en la comunidad en el sentido de que Aporta un nuevo soplo de aire fresco en muchos casos que revitaliza muchísimo la comunidad. Y después también conseguimos a nuevos contribuyentes a futuro para la organización en muchísimos casos, con lo cual es un soplo de aire fresco, como digo, para todas las organizaciones de software libre. Y finalmente, simplemente me gustaría brevemente destacar cómo podemos apuntarnos al Google Summer of

Code. Por supuesto, toda esta información la tenemos en la propia página web del proyecto, pero Sí que es verdad que tenemos unas fechas claves que es muy importante que tengamos en mente para que no se nos pasen, porque sí que es cierto que el Google Summer of Code es muy estricto con respecto a las fechas. Entonces, Para empezar a pensar las propuestas este año, la fecha de inicio ha sido el 9 de marzo y en ese momento es cuando debemos empezar a buscar, como comenté antes, organizaciones donde realizar proyectos. Y la fecha en la que empieza la fase de redacción de propuestas es el día 29. En este momento podemos empezar ya a mandar nuestros borradores para que las organizaciones. Los revisen, con lo cual tenemos hasta el 13 de abril para presentar nuestro PDF

final, y como digo, los plazos son bastante estrictos, con lo cual es muy importante que mantengamos Nuestro esfuerzo de forma constante también a la hora de aplicar para el programa. Así que finalmente ya llegamos a la conclusión de la presentación y simplemente quería recapitular un poco de qué hemos hablado en esta presentación. Bueno, hemos descubierto lo que es Wactale, hemos dado un breve repaso a qué es el Google Summer of Code. Luego hemos profundizado un poco más en lo que es el tema de la búsqueda de texto completo y cómo funciona en WhiteTale y cómo lo podemos instalar. And desarroll the Google Summer of Code,

and podemos apuntarnos. Así que ahora que ya sabemos todo lo que hemos hablado, me gustaría simplemente aprovechar para dar unos pequeños agradecimientos, en primer lugar a mis mentores, Carl y Cintia. Y después también al equipo de Wagtail entero porque han sido tremendamente útiles de cara a mi proyecto y siempre han estado ahí. Y después también a la Django Software Foundation, que me han echado un cable siempre que ha hecho falta. También a Google por poner este programa a la disposición de estudiantes como yo. A DjangoCon por darme La oportunidad de participar en esta conferencia, y por supuesto a vosotros por haber venido aquí. Así que de esta forma llegamos a la parte final de la presentación. Y simplemente a modo de despedida me gustaría dejaros con

el mensaje, la idea y espero que también la motivación de Incitar a todas las personas que conozcáis a presentarse al Google Summer of Code porque es una experiencia inolvidable, es una experiencia tremendamente enriquecedora y también me gustaría Que difundiesis la palabra acerca de Wagtail, porque es un CMS fantástico en el que ya confían muchísimas personas Y me gustaría que vosotros también pudierais hacerlo en un futuro. Con lo cual, muchísimas gracias por vuestra atención y seguimos en contacto para todo lo que necesitéis. Gracias.