From 163980f57c7ae155877e7c4e9efac9c7108c5842 Mon Sep 17 00:00:00 2001 From: Sergio Rafael Gianazza Date: Mon, 9 Apr 2018 22:58:44 +0200 Subject: [PATCH 1/7] Use correct property name --- es/02.4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/02.4.md b/es/02.4.md index 1274079e..82f0a8a6 100644 --- a/es/02.4.md +++ b/es/02.4.md @@ -27,7 +27,7 @@ Vamos a ver como usarlo. P.nombre = "Astaxie" // asigna "Astaxie" al campo 'nombre' de p P.edad = 25 // asigna 25 al campo 'edad' de p - fmt.Printf("El nombre de la persona es %s\n", P.name) // accedemos al campo 'nombre' de p + fmt.Printf("El nombre de la persona es %s\n", P.nombre) // accedemos al campo 'nombre' de p Tenemos tres formas mas de definir un struct. From 78ab007e671a7e576cb5e02617ba53bad78a273c Mon Sep 17 00:00:00 2001 From: Sergio Rafael Gianazza Date: Thu, 12 Apr 2018 21:01:09 +0200 Subject: [PATCH 2/7] remove duplicated word --- es/02.7.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es/02.7.md b/es/02.7.md index e6d0d053..311d43c6 100644 --- a/es/02.7.md +++ b/es/02.7.md @@ -114,7 +114,7 @@ Puedes probar con este código en tu computadora y cambiar algunos valores. ``` ## Range y Close -Podemos usar range para para hacer funcionar los 'buffer channels' como una lista y un map. +Podemos usar range para hacer funcionar los 'buffer channels' como una lista y un map. ``` package main From ffe6d4119bd74c2ca12fcc16a3f9288aef7c37df Mon Sep 17 00:00:00 2001 From: Sergio Rafael Gianazza Date: Fri, 13 Apr 2018 19:00:30 +0200 Subject: [PATCH 3/7] Fix typo --- es/03.1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/es/03.1.md b/es/03.1.md index 98a304be..cd7c2641 100644 --- a/es/03.1.md +++ b/es/03.1.md @@ -2,7 +2,7 @@  Cada vez que abres tu navegador, escribes alguna direccion URL y pulsas ENTER, verás hermosas páginas web que aparecen en pantalla. Pero, ¿sabes lo que está sucediendo detrás de esta simple acción? -Normalmente, el navegador es un cliente, después de teclear la URL, envía peticiones a un servidor DNS, para obtener la dirección IP de la URL. Luego de encontrar el servidor en esta dirección IP, configura una conexión TCP. El navegador envía las peticiones HTTP a través de la conexión. El servidor las maneja y responde con respuestas HTTP que conteienne el contenido que puedes ver en tu página web. Finalmente, el navegador renderiza el cuerpo de la página web y se desconecta del servidor. +Normalmente, el navegador es un cliente, después de teclear la URL, envía peticiones a un servidor DNS, para obtener la dirección IP de la URL. Luego de encontrar el servidor en esta dirección IP, configura una conexión TCP. El navegador envía las peticiones HTTP a través de la conexión. El servidor las maneja y responde con respuestas HTTP que contiene el contenido que puedes ver en tu página web. Finalmente, el navegador renderiza el cuerpo de la página web y se desconecta del servidor. ![](images/3.1.web2.png?raw=true) @@ -48,7 +48,7 @@ Para entender más acerca de su principio de funcionamiento, veamos en detalle 2. Si no hay relación de proyección en el archivo hosts, el sistema operativo comprueba si hay alguna caché en el DNS, si es así, termina la resolución de nombres de dominio. 3. Si no hay relación entre el computador y el servirdor de caché DNS, el sistema operativo busca el primer servidor de resolución de DNS en la configuración de TCP / IP, que es el servidor DNS local en este momento. Cuando el servidor DNS local recibió consulta, si el nombre de dominio que desea consultar está contenida en la configuración local de los recursos regionales, a continuación, devuelve los resultados al cliente. Esta resolución DNS es autoritaria. 4. Si el servidor DNS local no contiene el nombre de dominio, y hay una relación de correspondencia en con el servidor caché DNS, el servidor DNS local devuelve este resultado a cliente. Esta resolución DNS no es autoritaria. -5. Si el servidor DNS local no puede resolver el nombre de dominio, ya sea por la configuración de los recursos regionales o caché, se procede al próximo paso, que depende de la configuración del servidor DNS local. Si el servidor local de DNS no permite seguir avanzando, el enruta la petición a la raiz del servidor DNS, entonces returna la dirección IP de un servidor DNS de alto nivel, que debería conocer el nombre de dominio, `.com` en este caso. Si el primer servidor de mas alto nivel no reconoce el nombre de dominio, de nuevo re enruta la petición al siguiente servidor DNS de mayor nivel, así sucesivamente hasta que encuentre un servidor DNS que pueda reconocer el nombre de dominio. Entonces, se le solicita al servidor DNS la IP correspondiente al dominio, en este caso `www.qq.com` +5. Si el servidor DNS local no puede resolver el nombre de dominio, ya sea por la configuración de los recursos regionales o caché, se procede al próximo paso, que depende de la configuración del servidor DNS local. Si el servidor local de DNS no permite seguir avanzando, el enruta la petición a la raiz del servidor DNS, entonces retorna la dirección IP de un servidor DNS de alto nivel, que debería conocer el nombre de dominio, `.com` en este caso. Si el primer servidor de mas alto nivel no reconoce el nombre de dominio, de nuevo re enruta la petición al siguiente servidor DNS de mayor nivel, así sucesivamente hasta que encuentre un servidor DNS que pueda reconocer el nombre de dominio. Entonces, se le solicita al servidor DNS la IP correspondiente al dominio, en este caso `www.qq.com` - Si el servidor DNS local habilita seguir adelante, envía la solicitud al servidor DNS de nivel superior, si el servidor DNS de nivel superior también no sabe el nombre de dominio , a continuación, seguira enviando solicitudes a nivel superior. - Si el servidor DNS local permite a modo de avance , la dirección IP del servidor de nombre de dominio devuelve al servidor DNS local, y el servidor local envía a los clientes. From 15a78086552087dd96c490fea07be16588ced525 Mon Sep 17 00:00:00 2001 From: Sergio Rafael Gianazza Date: Sat, 14 Apr 2018 22:32:48 +0200 Subject: [PATCH 4/7] Fix case and typos, also remove some english text. --- es/04.0.md | 4 ++-- es/04.1.md | 6 +++--- es/04.2.md | 2 +- es/04.4.md | 2 +- es/04.5.md | 3 +-- 5 files changed, 8 insertions(+), 9 deletions(-) diff --git a/es/04.0.md b/es/04.0.md index 0fae2308..79e26d1d 100644 --- a/es/04.0.md +++ b/es/04.0.md @@ -2,7 +2,7 @@ Un formulario de usuario es algo que es usado comunmente cuando desarrollamos aplicaciones web. El provee la habilidad de comunicarse entre clientes y servidores. Debes estar familiarizado con los formularios si eres un desarrollador web; si eres un programador C/C++ te puedes estar preguntando, ¿qué es un formulario de usuario? -Un formulario es un área que contiene elementos de de formulario. Los usuarios pueden ingresar información en los elementos como en campos de texto, listas desplegables, botones circulares, cajas de chequeo, etc. nOsotros utilizamos la etiqueta `
` para definir formularios. +Un formulario es un área que contiene elementos de de formulario. Los usuarios pueden ingresar información en los elementos como en campos de texto, listas desplegables, botones circulares, cajas de chequeo, etc. nosotros utilizamos la etiqueta `` para definir formularios. ``` ... @@ -10,7 +10,7 @@ Un formulario es un área que contiene elementos de de formulario. Los usuarios ...
``` -Go tiene muchas funciones muy convenientes para lidiar con formularios de usuario. Facilmente puedes obtener la información de un formulario en una petición HTTP, y se pueden integrar fácilmente en tus aplicaciones propias. En la sección 4.1, vamos a hablar de como manejar la información de los formularios en Go. También que no puedes confiar en cualquier datao que viene del lado del cliente, primero debes validar los datos antes de usarlos. Vamos a ir a través de algunos ejemplos de como podemos validar la información de los formularios en la sección 4.2. +Go tiene muchas funciones muy convenientes para lidiar con formularios de usuario. Facilmente puedes obtener la información de un formulario en una petición HTTP, y se pueden integrar fácilmente en tus aplicaciones propias. En la sección 4.1, vamos a hablar de como manejar la información de los formularios en Go. También que no puedes confiar en cualquier dato que viene del lado del cliente, primero debes validar los datos antes de usarlos. Vamos a ir a través de algunos ejemplos de como podemos validar la información de los formularios en la sección 4.2. Decimos que HTTP es un procolo sin estado. ¿Cómo podemos identificar que varios formularios vienen del mismo usuario? y ¿cómo nos damos cuenta que un formulario solo puede ser enviado una vez? Miraremos algunos detalles concernientes a las cookies (una cookie es un segmento de información que puede ser guardado en el lado del cluente y agregado al encabezado de la petición cuando la petición es enviada al servidor) en los capítulos 4.3 y 4.4. diff --git a/es/04.1.md b/es/04.1.md index 3ec9a73f..1b3b8553 100644 --- a/es/04.1.md +++ b/es/04.1.md @@ -66,9 +66,9 @@ Es fácil darnos cuenta usando el paquete `http`. Veamos como manejar los formul } ``` -Aquí usamos el método `r.Methoc` para obtener el tipo de petición, el cual retornará uno de los siguientes verbos: "GET", "POST", "PUT", etc. +Aquí usamos el método `r.Method` para obtener el tipo de petición, el cual retornará uno de los siguientes verbos: "GET", "POST", "PUT", etc. -En la función `login`, usamos `r.Method` para verificar si es una petición a la página o una petición para procesar los datos. En otras palabras, verificamos si el usuario solo abró la página o está intentando ingresar. Únicamente mostramos la página cuando viene desde un método GET, y ejecuta la lógica cuando viene un método POST. +En la función `login`, usamos `r.Method` para verificar si es una petición a la página o una petición para procesar los datos. En otras palabras, verificamos si el usuario solo abrió la página o está intentando ingresar. Únicamente mostramos la página cuando viene desde un método GET, y ejecuta la lógica cuando viene un método POST. Podrás ver la interfaz cuando visitas `http://127.0.0.1:9090/login` en tu navegador. @@ -76,7 +76,7 @@ Podrás ver la interfaz cuando visitas `http://127.0.0.1:9090/login` en tu naveg Figure 4.1 Interfaz de ingreso de usuario -El servidor no va a imprimir nada hasta que nosotros escribamos un usuario y contraseña, porque el manejador no analizará los datos hasta que llamemos `r.ParseForm()`. Agreguemos `r.ParseForm()` antes de `fmt.Println("username:", r.Form["username"])`, compilemos el programa e intentémolo de nuevo. Ahora puedes ve la información en la consola del servidor. +El servidor no va a imprimir nada hasta que nosotros escribamos un usuario y contraseña, porque el manejador no analizará los datos hasta que llamemos `r.ParseForm()`. Agreguemos `r.ParseForm()` antes de `fmt.Println("username:", r.Form["username"])`, compilemos el programa e intentémoslo de nuevo. Ahora puedes ver la información en la consola del servidor. `r.Form` contiene todos los argumentos de la petición, por ejemplo la cadena de consulta en la URL y la información en el POST y PUT. Si la información tiene conflictos, como parámetros que tienen el mismo nombre, el servidor almacenará la información en un segmento con múltiples valores. La documentación de Go dice que Go guardará la información de las peticiones GET y el POST en diferentes lugares. diff --git a/es/04.2.md b/es/04.2.md index 2a6734a6..2d4b3aff 100644 --- a/es/04.2.md +++ b/es/04.2.md @@ -2,7 +2,7 @@ Uno de los principios mas importantes en el desarrollo web es que no puedes confiar en nada de lo que viene en los formularios de usuario. Necesitas validar todos los datos de entrada antes de usarlos. Muchos sitios web son afectados por este problema, lo que es simplemente crucial. -Existen dos maneras de verificar datos de formularios, que son usadas comunmente. La primera es la validación del lado del cliente en. el front end, y la segunda es la validación del lado del servidor, en el back end. En esta sección vamos a hablar sobre la validación del lado del servidor. +Existen dos maneras de verificar datos de formularios, que son usadas comunmente. La primera es la validación del lado del cliente en el front end, y la segunda es la validación del lado del servidor, en el back end. En esta sección vamos a hablar sobre la validación del lado del servidor. ## Campos requeridos diff --git a/es/04.4.md b/es/04.4.md index 37cf5a4a..b0d39308 100644 --- a/es/04.4.md +++ b/es/04.4.md @@ -1,6 +1,6 @@ # 4.4 Envíos duplicados -No se si alguna vez has visto blogs que tienen uno o mas de un post que son exactamente iguales, pero puedo decirte que es porque un usuario envió dos veces el mismo formulario. Existen muchas cosas que pueden cambiar envíos duplicados; algunas veces los usuarios hacen doble click en el botón de enviar, o quieren modificar el contenido después de postear y usan el botón de atrás. En algunos casos es por una acción intencioanl de usuarios malicioso. Es facil ver como los envíos duplicados pueden generar muchos problemas. Afortunadamente tenemos herramientas para prevenirlos. +No se si alguna vez has visto blogs que tienen uno o mas de un post que son exactamente iguales, pero puedo decirte que es porque un usuario envió dos veces el mismo formulario. Existen muchas cosas que pueden cambiar envíos duplicados; algunas veces los usuarios hacen doble click en el botón de enviar, o quieren modificar el contenido después de postear y usan el botón de atrás. En algunos casos es por una acción intencional de usuarios malicioso. Es facil ver como los envíos duplicados pueden generar muchos problemas. Afortunadamente tenemos herramientas para prevenirlos. La solución es añadir un campo oculto con un único token al formulario, y siempre verificar si el token ha sido procesado con anterioridad. También si quieres usar ajax para enviar un formulario, puedes usar javascript para deshabilitar el botón una vez se ha presionado. diff --git a/es/04.5.md b/es/04.5.md index 9ccbe28e..de1d3bd0 100644 --- a/es/04.5.md +++ b/es/04.5.md @@ -2,8 +2,7 @@ Supón que tienes un sitio web como Instagram y quieres que tus usuarios suban sus fotos. ¿Cómo implementarías esa funcionalidad? -Tienes que agregar la propuedad `enctype` al formulario que vas a usar para subir fotos. Aquí están los tres posibles valores para esta propiedad -You have to add property `enctype` to the form that you want to use for uploading photos. There are three possible values for this property: +Tienes que agregar la propiedad `enctype` al formulario que vas a usar para subir fotos. Aquí están los tres posibles valores para esta propiedad: ``` application/x-www-form-urlencoded. Transforma todos los caracteres antes de subirlos (Por defecto). From e9b5060921fa75db9fc62896ef7fa13300168577 Mon Sep 17 00:00:00 2001 From: Sergio Rafael Gianazza Date: Sun, 15 Apr 2018 20:50:48 +0200 Subject: [PATCH 5/7] Fix typos --- es/05.1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/es/05.1.md b/es/05.1.md index 37c5fd0a..81caa10f 100644 --- a/es/05.1.md +++ b/es/05.1.md @@ -59,7 +59,7 @@ Todos los manejadores de terceros debería tener esta función para analizar el ## driver.Conn -Esta es la interfaz de conexión con algunos métodos, como dije aarriba, la misma conexión solo puede usarse una vez por rutina. +Esta es la interfaz de conexión con algunos métodos, como dije arriba, la misma conexión solo puede usarse una vez por rutina. ``` type Conn interface { Prepare(query string) (Stmt, error) @@ -103,7 +103,7 @@ Esta es una interfaz opcional. Exec(query string, args []Value) (Result, error) } ``` -El el manejador no implementa esta interfaz, cuando llame `DB.Exec`, automáticamente llamará `Prepare`, retornará un `Stmt`. Después ejecutará el método `Exec` de `Smtt`, y cerrará el `Smtm`. +El manejador no implementa esta interfaz, cuando llame `DB.Exec`, automáticamente llamará `Prepare`, retornará un `Stmt`. Después ejecutará el método `Exec` de `Smtt`, y cerrará el `Smtm`. ## driver.Result From d54d56d37fb1d7bfb793ebda1b7dc9dbc527c584 Mon Sep 17 00:00:00 2001 From: Sergio Rafael Gianazza Date: Mon, 16 Apr 2018 12:23:55 +0200 Subject: [PATCH 6/7] Fix typos --- es/06.1.md | 10 +++++----- es/06.2.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/es/06.1.md b/es/06.1.md index 52811f09..d4999f69 100644 --- a/es/06.1.md +++ b/es/06.1.md @@ -2,9 +2,9 @@ Las sesiones y cookies son dos conceptos muy comunes en la web, y también son muy malentendidos. Sin embargo, son extremadamente importantes para la autorización de páginas, así como para tener información para estadísticas de las páginas. Echémos un vistazo a los dos siguientes casos de uso. -Supón que quieres acceder a una página que tiene acceso restringido al público, como el perfil de twitter de un usuario. Por supuesto que puedes abrir tu navegador y escribir tu usuario y contraseña para acceder a esa información, pero el concepto de "exploración web" significa usar un programa para automatizzar este proceso sin intervención humana. Por consiguiente, tenemos que encontrar que está ocurriendo realmente detrás de bambailnas cuando vamos a usar un navegador para acceder. +Supón que quieres acceder a una página que tiene acceso restringido al público, como el perfil de twitter de un usuario. Por supuesto que puedes abrir tu navegador y escribir tu usuario y contraseña para acceder a esa información, pero el concepto de "exploración web" significa usar un programa para automatizar este proceso sin intervención humana. Por consiguiente, tenemos que encontrar que está ocurriendo realmente detrás de bambalinas cuando vamos a usar un navegador para acceder. -Cuando por primera vez recibimos una página de acceso y escribimos un usuario y contraseña, después de presionar el botor de "entrar", el navegador envía una petición POST a un servidor remoto. El servidor redirecciona al usuario a su página de inicio después de verificar la información de acceso y retorna una respuesta HTTP. La pregunta aquí es ¿cómo el servidor sabe quien tiene privilegios de acceso a cierta página? Como HTTP es sin estado el servidor no tiene cómo saber si se ha pasado la verificación en el paso anterior. La solución mas fácil en ingenua es pegar el nombre de usuario y la contraseña en la URL. esto funciona, pero coloca mucha presión en el servidor, porque siempre se debe validar un usuario y una contraseña en la base de datos, y puede hacer que la experiencia de usuario se deteriore. Una alternativa para lograr esta meta es guardar la identidad del usuario en el cliente y el servidor usando cookies y sesiones. +Cuando por primera vez recibimos una página de acceso y escribimos un usuario y contraseña, después de presionar el botor de "entrar", el navegador envía una petición POST a un servidor remoto. El servidor redirecciona al usuario a su página de inicio después de verificar la información de acceso y retorna una respuesta HTTP. La pregunta aquí es ¿cómo el servidor sabe quien tiene privilegios de acceso a cierta página? Como HTTP es sin estado, el servidor no tiene cómo saber si se ha pasado la verificación en el paso anterior. La solución mas fácil e ingenua es pegar el nombre de usuario y la contraseña en la URL. esto funciona, pero coloca mucha presión en el servidor, porque siempre se debe validar un usuario y una contraseña en la base de datos, y puede hacer que la experiencia de usuario se deteriore. Una alternativa para lograr esta meta es guardar la identidad del usuario en el cliente y el servidor usando cookies y sesiones. Las cookies, de una manera corta, almacenan información (incluyendo la información de acceso) en el computador del cliente. El navegador envía estas cookies cada vez que el usuario visita el mismo sitio, automáticamente completando el paso de acceso para el usuario. @@ -12,7 +12,7 @@ Las cookies, de una manera corta, almacenan información (incluyendo la informac Figure 6.1 principio de las cookies. -Las sesiones, por otro lado, guardan información histórica en el lado del servidor. El servidor utiliza un identificador de sesión para diferenciar las esiones, y también este identificador es generado por el servidor y debería ser aleatorio y único. Puedes utilizar cookies o argumentos en la URL para obtener la identidad del cliente. +Las sesiones, por otro lado, guardan información histórica en el lado del servidor. El servidor utiliza un identificador de sesión para diferenciar las sesiones, y también este identificador es generado por el servidor y debería ser aleatorio y único. Puedes utilizar cookies o argumentos en la URL para obtener la identidad del cliente. ![](images/6.1.session.png?raw=true) @@ -30,7 +30,7 @@ Las cookies tiene un tiempo de expiración, y se dividen en dos tipos por su cic Si tu aplicación no le da a una cookie un tiempo de expiración, el navegador no la guardará en el sistema de almacenamiento después de que el navegador sea cerrado. Estas cookies son llamadas cookies de sesión y son guardadas usualmente en memoria en vez del sistema de almacenamiento permanente. -Si tu aplicación define un tiempo de expiración (por ejemplo, setMaxAge(60*60*24)), el navegador *guardará* esta cookie en el sistema de ficheros, y no la elimninará hasta que se alcance el tiempo de expiración. Las cookies guardadas en el sistema de ficheros pueden ser accedidas por diferentes instancias del navegador, por ejemplo, por dos ventanas de Internet Explorer; diferentes navegadores usan diferentes procesos para manejar las cookies que son guardadas en memoria. +Si tu aplicación define un tiempo de expiración (por ejemplo, setMaxAge(60 * 60 * 24)), el navegador *guardará* esta cookie en el sistema de ficheros, y no la elimninará hasta que se alcance el tiempo de expiración. Las cookies guardadas en el sistema de ficheros pueden ser accedidas por diferentes instancias del navegador, por ejemplo, por dos ventanas de Internet Explorer; diferentes navegadores usan diferentes procesos para manejar las cookies que son guardadas en memoria. ## Definir cookies en Go @@ -86,7 +86,7 @@ Una sesión es una serie de acciones o mensajes. Por ejemplo, piensa en las acci Las sesiones ayudan a almacenar el estado de la conexión entre servidor y cliente, y esto puede ser en forma de estructuras de datos. -Las sesiones son mecanismos del lado del servidor y usualmente empleaan tablas has (o algo similar) para guardar la información que llega. +Las sesiones son mecanismos del lado del servidor y usualmente emplean tablas hash (o algo similar) para guardar la información que llega. Cuando una aplicación necesita asignar una nueva sesión a un cliente, el servidor debe verificar si existen sesiones anteriores del actual cliente con un único identificador de sesión. Si la sesión ya existe, el servidor continúa con la misma sesión al cliente. Por otro lado, si una sesión no existe para el cliente, el servidor crea una nueva sesión (estu usualmente ocurre cuando el servidor ha eliminado el identificador de sesión correspondiente, pero el usuario ha usado la sesión anterior manualmente). diff --git a/es/06.2.md b/es/06.2.md index 9e203911..f92335b1 100644 --- a/es/06.2.md +++ b/es/06.2.md @@ -7,7 +7,7 @@ En la sección 6.1, aprendimos que las sesiones son soluciones para la verificac El principio básico detrás de las sesiones es que el servidor mantiene la información de cada cliente , y los clientes tienen una única sesión para acceder a su información. Cuando los usuarios visitan la aplicación web, el servidor crea una sesión siguiendo los siguientes pasos en tanto sean necesarios: - Crear un identificador de sesión único. -- Abrir un espacio de almacenamiento: normalmente tenemos las sesiones en memoria, pero las perderás si el sistema accidentalmente se interrumpe. Esto puede ser un serio problema si la aplicación web maneja datos sensibles, como de comercio electrónico por ejemplo. Para solucionar este problema, puedes guardar los datos de sesión en la base de datos o en el sistema de ficheros. Eso hace que los datos sean mas fiables y fácil de compartir con otras aplicaciones, sin embargo la negociaciónde información es mas del lado del servidor para leer y escribir sesiones. +- Abrir un espacio de almacenamiento: normalmente tenemos las sesiones en memoria, pero las perderás si el sistema accidentalmente se interrumpe. Esto puede ser un serio problema si la aplicación web maneja datos sensibles, como de comercio electrónico por ejemplo. Para solucionar este problema, puedes guardar los datos de sesión en la base de datos o en el sistema de ficheros. Eso hace que los datos sean mas fiables y fácil de compartir con otras aplicaciones, sin embargo la negociación de información es mas del lado del servidor para leer y escribir sesiones. - Enviar el identificador de sesión único al cliente. El paso clave aquí es enviar un identificador único de sesión al cliente. En el contexto de una respuesta HTTP estándar, puedes usar el encabezado o el cuerpo que lo acompaña, por consiguiente, tenemos dos maneras de enviar identificadores de sesión a los clientes: por cookies o por URLs. From 956139ee1ed22c7b57bb0cf2f1c614d434cf2218 Mon Sep 17 00:00:00 2001 From: Sergio Rafael Gianazza Date: Mon, 16 Apr 2018 14:34:09 +0200 Subject: [PATCH 7/7] Fix typos --- es/07.0.md | 2 +- es/07.1.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/es/07.0.md b/es/07.0.md index 06c09b09..bc6904fe 100644 --- a/es/07.0.md +++ b/es/07.0.md @@ -1,6 +1,6 @@ # 7 Archivos de texto -Manejar archivos de texto es una gran parte del desarrollo web. A menudo para producir o manejar contenido el contenido de texto recibido, incluyendo cadenas, números, JSON, XML, etc. Como un lenguaje de alto rendimiento, Go tiene gran soporte para esto en su librería estándar. Encontrarás que las librerías de soporte son mamravillosas, y te permitirán fácilmente lidiar con cuanlquier contenido de texto que puedas encontrar. Este capítulo contiene 4 secciones y te dará una intruducción al procesamiento de texto en Go. +Manejar archivos de texto es una gran parte del desarrollo web. A menudo necesitamos producir o manejar contenido recibido en formato texto, incluyendo cadenas, números, JSON, XML, etc. Como un lenguaje de alto rendimiento, Go tiene gran soporte para esto en su librería estándar. Encontrarás que las librerías de soporte son maravillosas, y te permitirán fácilmente lidiar con cualquier contenido de texto que puedas encontrar. Este capítulo contiene 4 secciones y te dará una introducción al procesamiento de texto en Go. XML es un lenguaje interactivo comúnmente usado en muchas APIs, muchos servidores web que están escritos en Java, usan XML como su lenguaje de interacción estándar. Hablaremos mas de esto en la sección 7.1. En la sección 7.2, miraremos JSON, que se ha vuelto muy popular en los años recientes y es mucho mas conveniente que XML. En la sección 7.3, vamos a hablar sobre expresiones regulares que (para la mayoría de gente) parecen un lenguaje usado por aliens. En la sección 7.4, verás como el patrón MVS es usado para desarrollar aplicaciones en Go y también como usar el paquete `template` de Go para usar plantillas en tus vistas. En la sección 7.5, vamos a introducir las operaciones de archivos y carpetas. Finalmente explicaremos las operaciones de cadenas en la sección 7.6. diff --git a/es/07.1.md b/es/07.1.md index 879bd1c8..98ccf055 100644 --- a/es/07.1.md +++ b/es/07.1.md @@ -2,9 +2,9 @@ XML es usado comúnmente como formato de comunicación de datos en servicios web. Hoy, está asumiento un rol mas y mas importante en el desarrollo web. En esta sección, vamos a introducir el cómo trabajar con XML a través de la librería estándar de Go. -No voy a hacer ningún intento de enseñar la sintaxis o convenciones. Por esto, por favor lea la documentación sobre XML. Nosotros nos enfocaremos en como codificar y decodificar archivos XML en Go. +No voy a hacer ningún intento de enseñar la sintaxis o convenciones. Para esto, por favor lea la documentación sobre XML. Nosotros nos enfocaremos en como codificar y decodificar archivos XML en Go. -Sopón que trabajas con información y tecnología y tienes que lidiar con el siguiente archivo de configuración en XML: +Supón que trabajas con información y tecnología y tienes que lidiar con el siguiente archivo de configuración en XML: ```