Agregar widgets en un Fragmento de Página en Liferay 7. 1

Hace pocos meses que la nueva versión de Liferay ya está disponible para todos nosotros, ésta es la versión Liferay 7.1 la cual trae consigo características nuevas é interesantes.

Una de éstas características nuevas son los Fragmentos de Página (Page Fragments), los cuales son pequeños modulos de HTML, CSS y JS los cuales puedes añadir a Páginas de Contenido para dar forma a una página con contenido relativamente estático. (Las Páginas de Contenido son también algo nuevo en ésta versión de 7.1).

Pensemos en una página que no requiere de mostrar contenido dinámico, en la cual quieres presentar un banner en la parte superior compuesto por una imágen y un encabezado después, un componente con 3 cards que presentan distinta información y finalmente quieres mostrar un formulario de registro.

Bien, vamos concentrarnos en el último componente, en éste caso el formulario. Para lograrlo, tenemos que seguir los sigueintes pasos:

1.- Ve a la sección de Content -> Forms desde el menu de administración del sitio en tu instancia de Liferay previamente ya levantada.

2.- Ya en la sección de Formularios, crea una forma de manera tradicional y publícalo.

1.- Creando Formulario de registro

3.- Ahora, nuevamente desde el menu de administración, dirigete a Build -> Page Fragments.

4.- Para poder crear un fragmento nuevo, necesitas crear una colección, ésto para tener una organización de tus fragmentos. En nuestro caso, creamos una colección llamda Fragmentos – Registro.

5.- Ahora que ya tenemos esa colección lista, seleccionala y crea una Página de Fragmento, que como ya te has dado cuenta, en Liferay 7.1 el botón para crear/agregar un nuevo elemento está en la parte superior derecha, a diferencia de la versión 7.0 que lo tiene en la esquinar inferior derecha.

6.- Dale un nombre a tu Fragmento de Página y guardala, depués de eso notarás que tienes disponible en tu pantalla una página con 4 divisiones.

* La primera es para añadir HTML, verás que ya tienes un div con una clase generada dinamiamente, la sugerencia es que no lo cambies y dentro de ése div agregues el HTML que necesitas.

 * La segunda es para que puedas añadir CSS, donde verás la misma clase de la sección de HTML, donde podrás agregar reglas para estilizar tu HTML.

 * La tercera división es donde podrás añadir Javascript en caso de ser necesario.

 * Y finalmente, la cuarta división es donde podrás previsualizar el HTML, estilos y funcionalidad javascript que añadiste previamente.

2.- Cómo crear un Fragmento de Página

7.- Bien, ahora que ya conocemos nuestra área de trabajo para crear un Fragmento de Página, te preguntarás como puedo agregar un Widget/Aplicación/Portlet a un Fragmento de Página, bueno para eso Liferay nos proporciona un par de tags que podemos utilizar en nuestro HTML cuando estamos haciendo un Fragmento de Página.

  • <ltr-editable></ltr-editable>
  • <ltr-widget-[portlet-alias]></ltr-widget-[portlet-alias]>

Donde <ltr-editable> nos va a ser útil para hacer posible la edición de texto ó imágenes, por ejemplo:

<p><ltr-editable id="miParrafo" type="text">Aquí va mi párrafo</ltr-editable></p>

Donde una vez añadido nuestro Fragmento de Página a una Página de Contenido, podremos editar el texto de nuestro párrafo dandole doble click sobre el texto.

Ahora si, después de la espera, te platico que el tag para añadir Widgets/Aplicaciones/Portles a un Fragmento de Página es <ltr-widget-[portlet-alias]> donde el portlet alias es una propiedad nueva en los Portlets de Liferay 7.1, la cual se agrega se agrega de la siguiente manera:

@Component(
	immediate = true,
	property = {
		"com.liferay.fragment.entry.processor.portlet.alias=form",
        .
        .
        .
        }
);

Entonces, para poder injectar nuestro Widget de Formulario, necesitamos conocer el portlet alias, para eso, visitamos el repositorio de Liferay Portal, donde hicimos una busqueda de la propiedad portlet alias.

Ya con nuestro portlet alias en mano, procedemos a añadir nuestro tag dentro de nuestro Fragmento de Página en el espacio designado para el HTML.

<div class="fragment_36091">
  <lfr-widget-form></lfr-widget-form>
</div>

 

Una vez insertado nuestro tag, podrás ver en el spacio de previualización que tienes ya la opción para seleccionar el formulario previamente creado.

Puedes seleccionarlo desde el Fragmento de Página, pero no prodrás visualizar la formar hasta que éste sea añadido a una Página de Contenido.

Bueno, ahora ya sabes que es un Fragmento de Página, como crear uno y sobre todo, como añadir Widget dentro de ellos.

Si quieres saber un poco más sobre los Fragmentos de Página da click aquí.

Si tienes comentarios o dudas, escribelo en el apartado de comentarios al final de éste post, saludos.

Diferencia entre parámetros y argumentos en JavaScript

Hoy en nuestro Curso Profesional de JavaScript Avanzado uno de nuestros amigos nos preguntó sobre la diferencia entre “parámetros” y “argumentos” así que decidí dejar aquí la explicación para futura referencia.

 

Pregunta

Hola Alex! Tengo una preguntita que me da un poco de vergüenza preguntar porque es como muy básica y ya debería saber la respuesta.

Pero desafortunadamente no la sé, y siempre es fuente de confusión para mí. Tiene que ver con los métodos en JS.

Cuando creo un método que toma dos argumentos, cada vez que llamo a ese método tengo necesariamente que meterle esos dos argumentos, ¿verdad?

Luego quería preguntarte también, ¿cuál es la diferencia entre “parámetro” y “argumento”?

Respuesta

Que tal esta es una excelente pregunta; y no te preocupes para nada debe darte vergüenza ya que es algo importantísimo de comprender. Aquí te dejo varios puntos referentes a “parámetros” y “argumentos” en JavaScript.

Los parámetros son la lista de variables que ponemos cuando se define una función, por ejemplo, en la siguiente función tenemos dos parámetros “a” y “b”:

function sum(a, b) {
	return a + b;
}

Los argumentos son los valores que se pasan a la función cuando ésta es invocada, de esta manera, en el siguiente ejemplo tendríamos que “7”, “4” son los argumentos de nuestra invocación a la función:

const result = sum(7, 4);

Aclarado lo anterior, en las definiciones de funciones suelen haber parámetros que son opcionales, como en este caso en la documentación de la Mozilla Developer Network (MDN) sobre el método filter tenemos: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter

var newArray = arr.filter(callback(element[, index[, array]])[, thisArg]);

Lo que quiere decir que el único parámetro requerido por “filter” es un “callback” y a su vez este “callback” tiene como único parámetro requerido al “element” que es precisamente cada uno de los elementos disponibles durante el ciclo (loop). Los parámetros opcionales son los que están entre corchetes”[ ]”

var filtrarNumerosPares = function(numero) {
	return numero % 2 === 0;
};

var numerosPares = [3,4, 7, -1].filter(filtrarNumerosPares);

console.log(numerosPares); // 4 es el único número par

De hecho de manera equivalente podríamos escribir nuestro “filter” así:

var filtered = [3,4, 7, -1].filter(function(numero) {
	return numero % 2 === 0;
});

Y más aún, en ES2015 podríamos reducir nuestra instrucción a una sola línea, usando un “return” implícito:

var filtered = [12, 5, 8, 130, 44].filter(numero => numero % 2 === 0);

Y el objeto “arguments” ¿para qué sirve?

Otra cosa interesante es que JavaScript tiene una variable local implícita llamada  arguments, la cual te da la posibilidad de acceder a los argumentos del llamado a tu función.

Imagina que quieres validar que SIEMPRE te manden un cierto número de argumentos para que tu función se ejecute correctamente, eso lo podrías lograr con algo como esto:

function sum(a, b) {
	if(arguments.length !== 2) {
		throw new Error("Unable to run, the sum() function needs TWO arguments...");
	}
	return a + b;
}

/* Mandará un error porque sólo hemos pasado "un solo argumento" */
const result = sum(7);

¿Te gustaría aprender más sobre JavaScript?

Adquiere nuestro Curso Profesional de JavaScript Avanzado y aprende entre otras cosas: patrones de diseño, promesas, ES2015+,  y mucho más.

 

Saludos.

¿Dónde descargar imágenes gratis para tus proyectos?

Dicen que “una imagen vale más que mil palabras” y en la mayoría de las circunstancias es cierto, cuando hablamos de la internet las imágenes juegan un papel muy importante desde el punto de vista de marketing digital.

Ahora bien, todo recurso multimedia (audio, imágenes, video) que encuentres en internet tiene un dueño o un autor, y aunque no necesariamente esté formalmente dicho en algún documento legal, de ser necesario estos autores de recursos multimedia pueden reclamar la propiedad en cualquier momento.

¿Por qué esto es importante si eres un negocio o empresa?

Simple:

Cumplir legalmente todos los términos de lo que usas y así evitar complicaciones legales en el futuro.

¿Dónde puedes descargar imágenes que puedas usar libremente?

Aquí te doy algunos sitios donde puedes descargar imágenes de muy alta calidad y que podrás usarlas sin complicaciones legales.

  1. Unsplash: https://unsplash.com/
  2. Pixabay: https://pixabay.com/en/
  3. Pexels: https://www.pexels.com/

Ahora bien estas imágenes no significa que sean “libres” en el sentido de que alguien más quiera atribuirse la propiedad o quiera re-venderlas en algún sitio comercial.

Estas imágenes proveen algo que se llama “royalty-free license” lo que significa que tú como persona o empresa tienes el derecho de utilizar las imágenes sin pagar regalías o una cuota por una licencia de uso a sus autores o dueños.

En sitios como Unsplash se sugiere que des crédito al autor de la imagen pero no es requerido, ni estás obligado a hacerlo (aunque se agradece que lo hagas).

¿Dónde puedes leer más sobre las licencias de imágenes?

Cada sitio de descarga de recursos multimedia SIEMPRE tendrá un enlace a sus términos de uso y licenciamiento.

Si quieres profundizar más en el tema de licenciamiento de estos sitios aquí te dejamos un extracto de la licencia original de varios de ellos:

Unsplash https://unsplash.com/license

All photos published on Unsplash can be used for free. You can use them for commercial and noncommercial purposes. You do not need to ask permission from or provide credit to the photographer or Unsplash, although it is appreciated when possible.

Es decir, en este caso la licencia es muy clara: podemos usar las imágenes incluso comercialmente (por ejemplo para ponerlas en tu sitio web o para armar campañas de publicidad).

Pexels: https://www.pexels.com/photo-license/

 All photos on Pexels can be used for free for commercial and noncommercial use.

Genial, entonces podemos usar comercialmente estas imágenes.

 Attribution is not required. Giving credit to the photographer or Pexels is not necessary but always appreciated.

Siempre es bueno agradecer y reconocer el trabajo de otros artistas.

 You can modify the photos. Be creative and edit the photos as you like.

Como ves, incluso puedes modificar las imágenes para que sean usadas a como las necesites en tu proyecto o empresa.

Es todo por hoy, espero que estos sitios de internet te provean lo que estás buscando en términos de imágenes.

Cuéntame ¿qué otros sitios conoces que permitan descargar recursos gráficos de manera gratuita?

Regresa en el tiempo con Git

¿Te encuentras ya en desarrollo de código? ¿Eres ingeniero de software?

Imagínate que por alguna razón alguien entra a tu servidor y se infectan tus archivos y no tienes forma de comparar un histórico, de cuál fue la versión anterior que tenias, con respecto a la que está ya modificada, no te será tan fácil recuperar todo lo que ya tenías.

Una de las grandes ventajas de Git es que te va a permitir  “Regresar en el tiempo”

Continúa leyendo Regresa en el tiempo con Git

Corregir error “413 Request Entity Too Large” cuando se suben temas de WordPress a tu servidor

Problema

Cuando trato de subir un archivo un poco “pesado” a mi servidor (por ejemplo un tema de WordPress) estoy recibiendo el error 413 Request Entity Too Large

Explicación del error

Este error sucede porque en la configuración de tu servidor web nginx hay una limitante en cuanto al tamaño del archivo que se puede subir; este tamaño usualmente se especifica en megabytes y normalmente está acotado a sólo 2 MB, lo cual es muy poco para un tema de WordPress por ejemplo.

Solución

Lo que debemos hacer son dos cosas:

Paso 1. Modifica la configuración de nginx

Modificar nuestra configuración de nginx para que tenga un parámetro con  menos limitante en cuanto al tamaño en megabytes que podemos subir a nuestro servidor usando un navegador web.

Para ello, procedamos con lo siguiente:

Ingresa en modo terminal en tu servidor y abre el siguiente archivo (previo respaldo del mismo):

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup
sudo nano /etc/nginx/nginx.conf

Localiza el bloque referente a la configuración http y agrega la siguientes líneas:

# To avoid error when uploading files added Alex Arriaga
client_max_body_size 32M;

Como notarás ahora estamos indicando un tamaño de cuerpo de las peticiones de 32 MB (es decir, podrías subir por ejemplo un archivo ZIP de aproximadamente ese tamaño).

Después de la modificación de tu archivo más o menos se contendrá algo como esto:

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        # To avoid error when uploading files added Alex Arriaga
        client_max_body_size 32M;

        # Aquí habrá más líneas de configuración...
        # ...


}

Paso 2. Verifica sintaxis y recarga la configuración

Primero verifiquemos que NO tenemos errores de sintaxis en nuestro archivo de configuración. Eso se hace fácilmente con el siguiente comando.

sudo service nginx configtest

En caso de tener algún error, puedes ver qué pasa usando este comando:

sudo nginx -t

Si no ves algún error, entonces es momento de recargar la configuración de nginx usando:

sudo service nginx reload

Paso 3. Modifiquemos nuestro archivo php.ini para que coincida con el parámetro de nginx

El archivo php.ini es un archivo de configuración de PHP (el lenguaje de servidor con el que están hechos muchos CMS -como WordPress y Drupal- y frameworks -como Laravel y CakePHP-.

La localización de este archivo puede variar, la forma más fácil de saber dónde está este archivo, es creando un archivo info.php en tu servidor y accederlo desde tu portal de internet (ya sea en local o en un dominio real).

Veamos cómo hacer esto:

# Esta sería la ruta donde está tu proyecto
cd /path/to/your/project/or/app
sudo nano info.php

Coloca en este archivo la siguiente línea de código PHP:

<?php phpinfo(); ?>

Ahora si tu sitio de internet o aplicación está en http://example.com, entonces podríamos visitar http://example.com/info.php y veríamos una tabla de color morado con datos como estos:

Busca ahí la parte donde diga “Configuration File (php.ini) Path” y con eso sabrás dónde está tu archivo php.ini. En nuestro caso está en la ruta:

nano /etc/php/7.0/fpm/php.ini
Al terminar estas configuraciones recuerda eliminar el archivo info.php ya que expone DEMASIADA información que un atacante pudiera usar para hacer cosas malas en tu sitio.

Perfecto, ahora abramos este archivo y modifiquemos esta línea:

upload_max_filesize = 2M

Para abrir tu archivo simplemente usa algún editor como nano:

sudo nano /etc/php/7.0/fpm/php.ini

Después de modificar tu archivo, éste se vería con algunas líneas como estas:

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
; upload_max_filesize = 2M

; Esta es nuestra configuración cambiada a 32M
upload_max_filesize = 32M

Guarda tu archivo y continuemos.

Paso 4. Reiniciemos PHP-FPM

Este paso podría NO aplicar a tu servidor, ya que depende si uses PHP-FPM en caso de que no, con el simple reinicio de Nginx debería ser suficiente.

# Restart Nginx
sudo service nginx restart

# Restart PHP-PFM
sudo /etc/init.d/php7.0-fpm restart

Y listo, ahora si intentas subir tu archivo, ya deberías tener permitidos archivos con un tamaño mayor (32 M).

Saludos cordiales y nos vemos en otro momento.

Por cierto ¿ya viste todos los cursos que tenemos en Webtraining.Zone? Si no, aquí puedes ver TODO el catálogo de cursos premium con los cuales podrás dar el siguiente paso en tu carrera como Desarrollador, Ingeniero o Arquitecto de la Web.

¿Qué es JSON-LD?

JSON-LD, ¿así que encontraste este nuevo término y no te quedó claro si es una nueva forma de describir objetos en JavaScript? ¿o si se trata de un nuevo framework para crear aplicaciones? ¿o si es parte de la especificación ES8?

La respuesta a todas las preguntas anteriores es: NO.

JSON-LD = JavaScript Object Notation for Linked Data

JSON-LD es una forma de codificar o representar Datos Enlazados (Linked Data) utilizando el famoso formato JSON.

¿Qué significa en palabras más simples?

Muy bien, demos una definición algo más digerible que los tecnicismos; imagina que tienes varias aplicaciones, cada una de estas aplicaciones o sistemas utiliza su propia forma de guardar información (bases de datos relacionales, bases de datos NoSQL, archivos, etc.).

Y ahora imagina que tienes la responsabilidad de obtener información de una aplicación para presentarla en la otra, pero no sólo eso, te interesa que los datos de una aplicación tengan una forma de relacionarse contra los datos de otro sistema.

Normalmente este tipo de problemas de integración y relación los resolvemos generando otro sistema que mantenga esto…

Lo cual evidentemente a largo plazo genera muchos retos para mantener índices, tablas, o cualquier cosa que guarde las relaciones entre tus datos.

¿Que tal si hubiera una forma de relacionar toda la complejidad de tus datos en alguna manera que OTROS sistemas (incluso aún no creados) pudieran “comprender” inmediatamente?

La respuesta a esta necesidad se llama: Linked Data o la iniciativa de Datos Enlazados que tiene el W3C. Es una propuesta fue hecha por Tim Berners Lee por allá de 2009 en esta conferencia de TED.

¿Y qué tiene que ver esto de Linked Data con JSON-LD?

Bueno, pues precisamente JSON-LD permite describir o codificar datos que siguen esta recomendación del W3C.
¿Te gustaría ver un ejemplo de un objeto escrito en JSON-LD? Aquí tienes un objeto que describe a John Lenon:
{
  "@context": "https://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}

Como verás es JSON con algunas particularidades como la existencia de algo llamado “@context” que pareciera ser una URL a “algo”.

Si abres esa URL encontrarás algo como esto, que es llamado un “Schema” o en otras palabras es el conjunto de propiedades que describen a una persona (Person).
{
   "@context":
   {
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "name": "http://xmlns.com/foaf/0.1/name",
      "nickname": "http://xmlns.com/foaf/0.1/nick",
      "affiliation": "http://schema.org/affiliation",
      "depiction":
      {
         "@id": "http://xmlns.com/foaf/0.1/depiction",
         "@type": "@id"
      },
      "image":
      {
         "@id": "http://xmlns.com/foaf/0.1/img",
         "@type": "@id"
      },
      "born":
      {
         "@id": "http://schema.org/birthDate",
         "@type": "xsd:dateTime"
      },
      "child":
      {
         "@id": "http://schema.org/children",
         "@type": "@id"
      },
      "colleague":
      {
         "@id": "http://schema.org/colleagues",
         "@type": "@id"
      },
      "knows":
      {
         "@id": "http://xmlns.com/foaf/0.1/knows",
         "@type": "@id"
      },
      "died":
      {
         "@id": "http://schema.org/deathDate",
         "@type": "xsd:dateTime"
      },
      "email":
      {
         "@id": "http://xmlns.com/foaf/0.1/mbox",
         "@type": "@id"
      },
      "familyName": "http://xmlns.com/foaf/0.1/familyName",
      "givenName": "http://xmlns.com/foaf/0.1/givenName",
      "gender": "http://schema.org/gender",
      "homepage":
      {
         "@id": "http://xmlns.com/foaf/0.1/homepage",
         "@type": "@id"
      },
      "honorificPrefix": "http://schema.org/honorificPrefix",
      "honorificSuffix": "http://schema.org/honorificSuffix",
      "jobTitle": "http://xmlns.com/foaf/0.1/title",
      "nationality": "http://schema.org/nationality",
      "parent":
      {
         "@id": "http://schema.org/parent",
         "@type": "@id"
      },
      "sibling":
      {
         "@id": "http://schema.org/sibling",
         "@type": "@id"
      },
      "spouse":
      {
         "@id": "http://schema.org/spouse",
         "@type": "@id"
      },
      "telephone": "http://schema.org/telephone",
      "Address": "http://www.w3.org/2006/vcard/ns#Address",
      "address": "http://www.w3.org/2006/vcard/ns#address",
      "street": "http://www.w3.org/2006/vcard/ns#street-address",
      "locality": "http://www.w3.org/2006/vcard/ns#locality",
      "region": "http://www.w3.org/2006/vcard/ns#region",
      "country": "http://www.w3.org/2006/vcard/ns#country",
      "postalCode": "http://www.w3.org/2006/vcard/ns#postal-code"
   }
}

¿Genial no crees? Significa que ahora puedes describir tus modelos de datos (entidades de información) usando un formato muy conocido en el mundo de la web, es decir, en JSON.

Y no sólo eso, sino que JSON-LD es el formato recomendado por buscadores web como Google para proveer datos enriquecidos que ellos puedan utilizar para mejorar el mostrado de resultados, como lo indican en las “Structured Data General Guidelines”

¿Dónde puedes aprender más sobre este tipo de datos estructurados en JSON-LD?

Por supuesto aquí en Webtraining.Zone en nuestro taller de Datos Estructurados para SEO.

Todo esto de los datos enlazados es un campo emergente y su potencial es muy grande, hoy por hoy ya empiezan a nacer productos que hacen más fácil la creación de datos siguiendo esta recomendación del W3C.

Un ejemplo de una herramienta muy poderosa para crear aplicaciones que usen Linked Data es Carbon LDP.

¿Te gustaría seguir aprendiendo sobre Linked Data, JSON-LD y cosas relacionadas a la Web Semántica?

Déjanos un comentario y con gusto veremos cómo mostrarte una área emergente que cambiará la forma en cómo hacemos aplicaciones y sistemas.

Saludos.

Tu Servidor,

Alex Arriaga

Testing REST API con HTTPie

En días pasados tuvimos un taller práctico sobre cómo hacer testing de REST APIs usando una herramienta muy poderosa que definitivamente deberías agregar a tu set de tools: HTTPie.

Definido por sus creadores como:

A single http command designed for painless debugging and interaction with HTTP servers, RESTful APIs, and web services

Instalación

HTTPie te ayudará a probar que tus REST APIs estén funcionando como se espera, la instalación varia un poco de acuerdo al sistema operativo que tengas; aquí te dejamos las instrucciones oficiales para proceder con la instalación.

Ejemplos

En la siguiente lista tenemos algunos ejemplos de ejecución para los casos de uso más comunes, por ejemplo obtener (GET), agregar (POST) o actualizar información (PUT).

Estos ejemplos pertenecen al REST API creado en Laravel Lumen para el Curso Profesional de Angular para Aplicaciones Enterprise disponible en video.

El código que crea este REST API está público en: http://projects-api.webtraining.zone/ para tu consulta y aprendizaje.

Empecemos, pues con los ejemplos:

GET users

Imaginemos que queremos obtener la lista de usuarios registrados en nuestro sistema, entonces podríamos hacer una petición GET hacia nuestro API con la siguiente instrucción:
http GET http://projects-api.webtraining.zone/users
La respuesta del llamado anterior, será como sigue:
Si notamos, este REST API tiene los recursos (users) protegidos, por lo que es necesario primero “iniciar sesión” para poder leer los datos, entonces hagamos eso en el siguiente ejemplo:

Login

Para poder efectuar la operación de login a nuestro API es necesario ejecutar una petición de tipo POST. Esta petición necesita el username y password.
En HTTPie la forma de mandar estos parámetros es el formato <nombre-del-parámetro>=<valor-del-parámetro> por ejemplo: username=esmeralda-rodriguez
http POST http://projects-api.webtraining.zone/users/login username=esmeralda-rodriguez password=esmeralda
Lo importante en la respuesta que obtenemos es el api_token que más adelante enviaremos como un header de la petición para poder solicitar datos.

GET con token

Una vez hecho el login que nos devuelve nuestro token, ahora procedamos a “inyectarlo” en los headers de la petición:
http GET http://projects-api.webtraining.zone/users Content-Type:application/json Api-Token:jJHGtk3IoZ84CmKlDz5N206w46yaj6v4mk0vXdTDl5w80iqnk0skp9Jp6NQ3
Como vemos, ahora sí, ya tenemos nuestros datos de forma correcta ya que el token es válido y por tanto tenemos “permiso” para leer datos.

PUT con JSON body

Ahora que pasa si deseo hacer una actualización de datos, reemplazando una instancia completa de un usuario; normalmente estos “reemplazos” de entidades de datos se realizan mediante el método PUT (PATCH usualmente se usa para hacer modificaciones de elementos de una entidad, por ejemplo en nuestro caso el nombre de usuario o sólo la contraseña).

echo '{ "username" : "esmeralda-rodriguez", "email" : "esmeralda@webtraining.mx", "password" : "esmeralda", "name" : "Esmeralda Rodríguez B."}' | http PUT http://projects-api.webtraining.zone/users/2 Content-Type:application/json Api-Token:jJHGtk3IoZ84CmKlDz5N206w46yaj6v4mk0vXdTDl5w80iqnk0skp9Jp6NQ3

Evidentemente aquí tenemos una desventaja, ya que si nuestro objeto JSON fuera muy grande, resulta muy incómodo escribir eso a nivel de línea de comandos.

Sería mejor tener una forma de tener este JSON en un archivo y luego usar ese archivo como entrada, eso lo veremos en el siguiente ejemplo.

PUT con JSON body desde un archivo

Para poder realizar este ejercicio vamos a crear un archivo llamado “esmeralda.json”, con el siguiente contenido:

{
    "username": "esmeralda-rodriguez",
    "email": "esmeralda@webtraining.mx",
    "password": "esmeralda",
    "name": "Esmeralda Rodríguez B."
}

Ahora procederemos a ejecutar nuestra petición PUT usando este archivo como entrada, nota el símbolo “@” antes del nombre del archivo:

http PUT http://projects-api.webtraining.zone/users/2 Content-Type:application/json Api-Token:jJHGtk3IoZ84CmKlDz5N206w46yaj6v4mk0vXdTDl5w80iqnk0skp9Jp6NQ3 @esmeralda.json

El resultado será exactamente el mismo que el ejercicio anterior, sólo que esta opción es mucho más mantenible y cómoda de trabajar.

¿Te gustaría escuchar una explicación en video?

Visita nuestro taller en Webtraining.ZoneREST APIs con Postman y HTTPie

Nos vemos en el siguiente post. Saludos.

Tu servidor,

Alex Arriaga.

¿Por qué me llegan por correo tantas actualizaciones en Políticas de Privacidad?

¿Has notado que todos los servicios, apps o suscripciones a las que te has registrado alguna, vez te están enviando correos referentes a actualizaciones de Políticas de Privacidad? Esto se debe al Reglamento General de Protección de Datos (o GDPR por sus siglas en inglés), un nuevo y amplio reglamento europeo que entra en vigor el día viernes 25 de mayo del 2018, es decir, ¡mañana mismo!

En Webtraining nos preocupamos por mantenerte actualizado, así que aquí te dejo 12 cosas que debes saber acerca del GDPR.

1. La Unión Europea (UE) tiene el poder de castigar.

El GDPR le brinda a la UE la facultad de responsabilizar a las empresas y organizaciones por la manera en que obtienen y tratan los datos personales de sus usuarios, entre ellos tú. Todas las empresas y organizaciones han tenido dos años para prepararse. La promulgación del GDPR no fue un movimiento espontáneo por parte de las instituciones europeas. El GDPR se hizo oficial en mayo del 2016, otorgando suficiente tiempo para prepararse a todos los que recolectan información de sus clientes.

2. Aunque todo esto fue orquestrado por en Europa, el GDPR impacta a todo el mundo.

Si vives fuera de Europa, probablemente te estarás preguntando qué tiene que ver una nueva ley europea contigo. Gracias a algo llamado Alcance Territorial (tercer artículo del GDPR), cualquier organización que trate con datos de residentes europeos deben acatar el GDPR para dichos individuos, lo cual impacta a organizaciones globales como Apple y Facebook (¡Ha!). A pesar de no ser estrictamente requerido, algunas organizaciones están brindando el mismo control y protección a los que viven fuera de Europa.

3. Está saturando tu buzón de entrada

Todos hemos sido bombardeados con emails sobre políticas de privacidad actualizados y con términos y condiciones de uso del servicio. Esto NO es (mayormente) una repercusión del escándalo “Cambridge Analytica-Facebook”,  sino porque las organizaciones están ajustando sus prácticas y políticas para acatar el GDRP. Considera que todos estos emails son un recordatorio para que te desconectes de servicios que ya no usas y hasta olvidaste. No tiene caso que sigan teniendo datos tuyos, ¿o sí?

4. La privacidad de información es por diseño y por defecto.

Aclaro, “por defecto” me refiero no a errónea sino a “dado por hecho”.

Las organizaciones que recolecten o usen datos personales deberán considerar la privacidad a lo largo de todo el ciclo de vida de sus productos y servicios.

Esto significa que desde el día en que los equipos inician a diseñar un producto, servicio o funcionalidad, la privacidad debe permanecer en sus mentes en todo momento.

Esto también significa que los ajustes iniciales de una app o servicio estarán configurados por defecto para beneficiar la privacidad, y será elección del usuario ajustar o remover dicha privacidad.

5. Las políticas y los términos y condiciones deben ser fáciles de entender.

El GDPR exige que las políticas sean escritas en lenguaje simple para que el usuario pueda entender claramente a qué está dando su consentimiento. Ahora es un buen momento para revisar las políticas de privacidad y términos y condiciones de los servicios que usas y actualizar tus ajustes.

Puedes comenzar con estas (algunos enlaces son a las políticas en inglés, pero puedes navegar un poco y buscar la versión en español):

6. Tienes el derecho de llevarte tus información hacia otro servicio.

Este principio se llama “Portabilidad de datos” y significa que tú:

  1. Tienes visibilidad sobre la información que una organización tiene recolectada sobre tí.
  2. Puedes mover esa información a un proveedor de servicios diferente (como un competidor) sin perder el historial de datos que has producido.
  3. Estás más cerca de ser el guardián y beneficiario de tu propia información.

¿Cómo sucederá todo esto? Aún no hay certeza, pero ya lo veremos.

7. Tienes el derecho de ser olvidado.

Adicionalmente al derecho de poseer tu información, también tienes el derecho de solicitar su eliminación.

8. Las violaciones de datos serán reportadas a los reguladores mucho más rápido.

El GDPR tiene una “Regla de las 72 horas” que significa que los manejadores de tu información deben reportar una violación de datos a su autoridad supervisora en un lapso menor a tres días después de haberse percatado de ella.

9. Violaciones serán caras.

Realmente caras. En el pasado, las multas por un manejo y recolección irresponsable de datos eran tan bajas que, quizás, era más rentable para las grandes organizaciones pagarlas y seguir con lo suyo.

Sin embargo, ahora las organizaciones que violen el GDPR pueden ser multados por hasta el 4% de su facturación global anual o 20 millones de euros (lo que resulte mayor).

Aún no está claro cuál sería una violación significante, pero podemos tomar a Alphabet (la compañía que posee a Google) para un ejemplo hipotético de una violación al GDPR. Alphabet se hizo de 110 billones de dólares en 2017, así que una multa a una organización así vendría siendo de 4.4 billones de dólares.

10. Lo que es bueno para el usuario también es bueno para los negocios.

Almacenar información personal siempre tendrá riesgos. Mejores prácticas de seguridad disminuye los riesgos asociados con la recolección y procesamiento de datos personales para ambos, usuarios y organizaciones.

Esto no es algo insignificante: en 2015 las violaciones de datos costaron en promedio 3.79 millones de dólares por compañía afectada, sin mencionar la confianza de los clientes perdida y repercusiones en relaciones públicas.

11. Menos información, más confianza.

Es triste pero cierto que algunas organizaciones ni siquiera saben qué información tienen o dónde está almacenada, y el GDPR exhorta a las organizaciones a pensar dos veces sobre la cantidad de información que recolectan.Además, estas necesitan justificar el propósito de dicha recolección.

El GDPR representa una oportunidad para más negocios de ser líderes en términos de recolección de datos al inclinarse por recolectar sólo lo que es necesario para proveer su producto o servicio, en lugar de acaparar datos de todo tipo.

12. El GDPR es un piso, no un techo.

El GDPR provee un conjunto inicial de reglas, las cuales sirven de base para fomentar enfoques más éticos en la recolección y procesamiento de datos. Esto es un paso en la dirección correcta, pero el lado oscuro aparecerá en los detalles para la mayoría de las organizaciones.

Nuevos controles de privacidad, incluso si llegan a cumplir técnicamente con el GDPR, no ayudarán si resultan difíciles de usar y si las organizaciones no están comprometidas con los principios de los cuales nació este reglamento. Aún así, nos gusta que esto fomente una cultura de privacidad responsable, empoderando al usuario con control y elección sobre su experiencia online.

Así que ya sabes, a revisar en dónde estamos metidos y qué andan haciendo con nuestra información.

Espero que este post sea de utilidad, incluso si no eres del mundo de la computación. Déjame un comentario o un saludo. Nos leemos en la próxima.

¿Y en Webtraining dónde puedo ver las políticas de privacidad?

Puedes darle un vistazo a nuestra política actualizada en el siguiente enlace: Políticas de Privacidad de Webtraining.

– Enrique D.

El origen de Bootstrap, el framework CSS líder

Hace unos días me daba vueltas en la cabeza quiénes eran las personas que desarrollaron Bootstrap, este framework tan amigable (que a muchos nos ha aliviado en más de un par de ocasiones), me hacía preguntas como ¿son personas normales? ¿dónde viven? y ¿qué otras cosas hacen? por este y otros cuestionamientos más, hoy me dí a la tarea de investigar y este fue el resultado de mi investigación.

Bootstrap fue desarrollado por Mark Otto (@mdo) y Jacob Thornton (@fat) desarrolladores del famosísimo Twitter, proveedor de servicios de microblogueo.

¿Pero quiénes son Mark Otto y Jacob Thornton?

Mark Otto es un diseñador viviendo y trabajando en San Francisco, trabajó como freelance durante la secundaria y la universidad, antes de mudarse a California para trabajar en la empresa de diseño ZURB, en 2007.

Durante su estancia en ZURB diseñó y desarrolló docenas de proyectos con grandes y pequeños clientes, incluido un sitio web para Britney Spears -¡Cool! – .

Después de un periodo de dos años y medio en ZURB, renunció para comenzar a trabajar en Twitter como diseñador de productos.

En Twitter trabajó en numerosos proyectos y varias herramientas internas, ahí fue donde creó el popular kit de herramientas para front-end de código abierto Bootstrap con ayuda del buen Jacob Thornton.

Bootstrap nació en Twitter como un medio para crear mejores herramientas internas, comenzó como algo simple de HTML/CSS, luego Jacob construyó complementos encima y así es como comenzó “Bootstrap de Twitter” llamado así originalmente.

Bootstrap es un framework de código abierto para diseño de sitios y aplicaciones web. Entre sus herramientas contiene una gran variedad de plantillas de diseño con tipografía, botones, menús de navegación, tarjetas y otros elementos de diseño basado en HTML y CSS, así como también extensiones de JavaScript.

Hasta la fecha Otto y Jacob han puesto más de 1000 horas en Bootstrap, sino es que más. Semanalmente trabajan de tiempo completo en sus respectivos empleos, pero suelen realizar esfuerzos durante algunas horas por la noche y más los fines de semana, esto quiere decir que ellos no trabajan de tiempo completo en Bootstrap.

Actualmente Otto se desempeña como Director Principal de Diseño en GitHub, administra un equipo de aproximadamente 25 diseñadores web, ingenieros y artistas.

Por su parte Jacob Thornton es cofundador de Bumpers (aplicación de podcasting). Trabajó en Medium y Twitter, dondé junto a Otto creó Bootstrap.

Jacob hace un tiempo solía mantener un blog, donde escribía una serie de artículos de filosofía, sociología, teoría crítica y tecnología, donde abordó diferentes temas “con los que estaba luchando en ese momento”.

Jacob en particular tiene ideas que dan vueltas en su cabeza como ¿los robots o la inteligencia artificial se volverán demasiado inteligentes y tomarán el control? ¿ya vivimos en una realidad virtual? y cuestiones como “necesitamos colonizar Marte, o de lo contrario nos vamos a extinguir” y temas por las que la gente como él está obsesionada.

Jacob dice que no se deprime demasiado por este tipo de aspectos humanistas, pero sí es juicioso al respecto y tiene la tendencia a enloquecer al respecto.

Él es una persona muy filosófica y de ideas futuristas, sufre de alergias y le encantaría tener un ‘gato robótico’, y que no estaría nada preocupado si su gato intentara atacarlo.

Soy alguien que realmente quiere que haya destinos y experiencias radicales, únicas y diferentes, especialmente en Internet.

Bootstrap 4

Finalmente, Bootstrap es un proyecto que recientemente se ha actualizado a su versión 4, añadiendo diversas funcionalidades y mejoras, las cuales les invito a conocer en un muy entretenido y amigable curso impartido por nuestro amigo Alex Arriaga donde serás testigo de la genialidad de estos dos personajes.

https://webtraining.zone/cursos/curso-profesional-de-bootstrap-4

Conclusión general

Creo que Otto y Jacob son personas como tu y como yo, que con el esfuerzo y dedicación de su día a día han logrado proyectos muy interesantes e innovadores.

Así que sigamos trabajando todos los días “pasito a pasito” y así poco a poquito alcanzaremos y construiremos cosas más grandes y mejores para bien de todos.

Corre tras tus sueños…

Truco de Vue.js #2: Quiero usar Vue.js en un proyecto grande y viejo.

Tenemos el siguiente escenario: Eres el nuevo miembro de un equipo de desarrollo que lleva unos años perfeccionando una aplicación Web. Dicha app está hecha con tecnologías como .NET y usa jQuery a todo lo que da. Tu primera tarea es “arreglar” el sistema de comentarios pero al analizarlo por un rato descubres cosas como esta:

$('#comment-' + commentId2)
  .toggleClass('comment-state-02')
  .css('display', displayFlag);

Intentas sacarle explicación a cada variable, clase y ID para medio comprender qué están tratando de lograr. Te ves en 2 meses arreglando el parche que arregló el parche que arregló el parche, te deprimes y luego te armas de valor y propones rehacer el módulo.

Y para tu sorpresa… ¡TE LO ACEPTAN! Es tu momento de meterle tecnología de punta que no solo sea novedosa sino eficiente. ¿Pero qué puedo usar que sea eficiente y al mismo tiempo fácil de integrar? OJO: Fácil de integrar es que al meterlo al proyecto no te rompa todo y tome días ajustarlo. Mi sugerencia es obviamente Vue.js.

¿No te convence? Considera que añadir solamente 32kb al proyecto acelerará tu productividad y mantendrá un buen nivel de escalabilidad si creas una abstracción de componentes decente. ¿Qué piensas ahora?

¡Acepto! ¿Cómo empiezo?

Importar el script de Vue.js, sea por CDN o guardando el archivo en el proyecto, es sumamente fácil. Considero que es algo que podemos saltarnos en este post, pero te dejo el link de la documentación oficial aquí.

Ahora, siendo un curioso de la web que conoce Vue.js, sabrás que trabajar con componentes es lo ideal. Y dividir la lógica de cada uno en un archivo con extensión .vue es la cereza del pastel. Sin embargo, el proyecto al que te enfrentas no usa Webpack y, honestamente, integrar Webpack en un proyecto que no se pensó desde un principio con él es una lata. Y tú, siendo el nuevo que ya convenció al Project Manager de usar Vue.js, debes entregar resultados ASAP.

Dale, no pasa nada. Afortunadamente Vue.js tiene más de una manera para declarar un entorno de componentes. En un escenario como este yo te sugiero estas dos formas:

  1. Declaración con strings inline.
  2. Declaración con X-Templates.

Preparación

Checa el repositorio que preparé para ti: https://github.com/enriqued93/truco-vue-2. La rama master contiene el ejemplo para la declaración con strings inline, y la rama x-templates para el segundo ejemplo.

En este repositorio están los pasos necesarios para integrar Vue.js en cualquier proyecto de manera segura. Hay comentarios suficientes dentro del código para comprender qué está sucediendo, así que te recomiendo fuertemente que le des un vistazo.

En el archivo comments.module.js está la definición e inicialización del widget de comentarios y sus componentes. Mi enfoque se basa en definir funciones descriptoras cuyo único fin es devolver objetos con la estructura especificada para un componente de Vue.js.

¿Por qué usar este tipo de funciones y no escribir el objeto inline? En mi humilde opinión, englobar dichos objetos de esta manera ayuda a tener un código más limpio y estructurado. Si estamos trabajando con una herramienta que promueve el uso de componentes, debemos estar consientes de que tener una estructura mantenible y reusable es primordial. Otra ventaja es que si tienes la necesidad de utilizar un componente en otro lado, puedes copiar y llevarte la función completa y no se romperá absolutamente nada ya que la función descriptora debe ser ajena al contexto donde se define.

Declaración con strings inline

Quizá sea la manera más simple de definir un componente en Vue.js. Primero te dejo algunas ventajas y desventajas de este método.

Ventajas

  • Como desarrollador, es imposible perder referencia visual entre lógica y template del componente, pues se encuentran en el mismo sitio.
  • Al mover la declaración de lugar (posiblemente a otro archivo) el componente no se romperá ya que está todo en el mismo objeto.
  • Los problemas que surgen por ejecutar JavaScript antes de tener listo el DOM no te afectarán por declarar este componente porque el template que necesita viene integrado.

Desventajas

  • Como el template se está definiendo como un string, te será muy dificil escribir un componente muy grande.
  • La mayoría de los IDEs (o tal vez todos) tratarán el template como un vil y plano string, omitiendo cualquier tipo de Syntax Highlighting.
  • Para escribir un string multilinea puedes usar las Templates Literals de EcmaScript2015, pero dado que existen navegadores que no implementan esta especificación es un poco arriesgado usarla (a menos que tus requerimientos no incluyan este tipo de navegadores).

Enfoque

Si has usado el framework sabrás que debemos crear un objeto que funja como “descriptor” de nuestro componente y que tiene una estructura como te muestro acontinuación:

{
  template: ...,
  data: ...,
  methods: ...,
  computed: ...
}

Existen ciertas consideraciones que debemos tener en cuenta respecto a este objeto, pero por ahora solo me estoy enfocando en la propiedad template por el alcance de este post.

En el repositorio que te compartí encontrarás que defino el template de los componentes de manera inline, es decir, el HTML con directivas de Vue.js es un string asignado a la propiedad template del objeto descriptor. Este string lo defino usando sintásis diferentes para que de acuerdo a tus gustos o requerimientos uses la que más te acomode. Recuerda que las Template Literals no son soportadas por todos los navegadores (checa la compatibilidad actualizada aquí).

function getCommentListDescriptor() {
    return {
        data: function () {
            return {}
        },
        props: ['comments'],
        components: {
            'comment': getCommentDescriptor()
        },
        template: `
            <div class="wt-comment-list">
                <comment v-for="c of comments" :key="c.id" :model="c"></comment>
            </div>
        `
    }
}

function getCommentEditorDescriptor() {
    return {
        data: function () {
            return {}
        },
        template: '<div class="wt-comment-editor"><textarea class="wt-comment-editor__input" placeholder="Escribe algo..."></textarea><button class="wt-comment-editor__button" type="button">Enviar</button></div>'
    }
}

Declaración con X-Templates

Bueno, pero entonces ¿debo tener forzosamente mis archivos JavaScript con todos esos strings que tienen una sintáxis más parecida a HTML? La respuesta es NO.

Ventajas

  • Ciertos IDEs pueden ayudarte con Syntax Highlighting ya que el template se encuentra en un archivo HTML.
  • Resuelve el impedimento de los templates multilinea.
  • Si creamos un componente con un template muy extenso, el código se aligera visualmente al quitarlo del descriptor.

Desventajas

  • Si no tenemos cuidado y olvidamos incluir los X-Templates en el contexto, el componente no encontrará su respectivo template y explotará.
  • Si el componente se inicializa antes de tener listo su respectivo X-Template dentro del DOM, también explotará.

Enfoque

Hagámosle unos cambios al ejemplo anterior. En lugar de tener los templates en nuestro JavaScript, lo moveremos al HTML de la siguiente manera.

<script type="text/x-template" id="vue-comment-template">
    <div class="wt-comment">
        <p class="wt-comment__subject">{{model.subject}}</p>
        <p class="wt-comment__body">{{model.body}}</p>
    </div>
</script>

El punto clave es englobar el template en un <script> con la propiedad type=”text/x-template”. El ID del script reemplazará al template inline del ejercicio pasado.

function getCommentDescriptor() {
    return {
        data: function () {
            return {}
        },
        props: ['model'],
        template: '#vue-comment-template'
    }
}

No olvides que para que la inicialización de un componente se lleve a cabo adecuadamente, es necesario que el X-Template en cuestión exista en el DOM en dicho momento. Puedes usar $(document).ready() o la estrategia que prefieras para asegurar que el JavaScript se corra cuando el DOM se haya cargado (en el repositorio encontrarás una estrategia usando solamente JavaScript por si has superado jQuery).

Conclusión

En mi humilde opinión, establecer una buena abstracción y arquitectura de componentes en tu aplicación es primordial. Si lo haces no importará si tu app debe seguir creciendo pues soportará nuevas funcionalidades (escalabilidad); arreglar bugs dejará de ser tarea de andar descifrando código ajeno (mantenibilidad).

Si usas Vue.js o estás considerando en usarlo, aprovecha todas las bondades que ofrece y sácale todo el jugo. Recuerda que puedes tener el mejor framework del mundo pero si no lo usas como se debe no hará ninguna diferencia.

Ojalá esto te sea útil y no olvides dejarme tus comentarios diciendo qué cosas te interesarían aprender, cómo te pareció este post o qué opinas de mi escritura. Te mando un saludo, nos leemos en el próximo post.

– Enrique D.