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.

¿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é se sigue usando Java?

Hoy recibimos una pregunta muy interesante de uno de nuestros webtrainees desde Youtube, sobre por qué Java aunque es un lenguaje que parece “antiguo”, sigue siendo uno de los que recomendamos aprender en Webtraining.Zone. Aquí está parte de la pregunta:

Necesito ayuda,…, nunca programé en Java, mas bien fui formado en frontend, me incliné fuertemente por la programación funcional: manejo Haskell, Rust, PureScript y Elm. Siempre me gusto la programación, pero…

Java siempre me ha parecido un lenguaje feo y tortuoso, lo siento mi idea no es ofender, el hecho de no tener inferencia de tipos, tener que crear clases para todo e incluso tener que manejar estado dentro de una clase me resulta raro, extraño o no natural.

Quiero saber por qué me parece terrible tener que trabajar con Java, y siempre que empiezo proyectos intento evadirlo, tal que argumento con las estadísticas StackOver Flow para demostrar que esta siendo relegado. Quiero que alguien pro como Alex me de su punto de vista.

Mil gracias.

Primero que nada quisiera comentarte que Java es un lenguaje que al ser un predecesor de todos los lenguajes que mencionas, definitivamente no tiene todas las características “modernas” para hacer desarrollos a los que estás tienes acceso con lenguajes como Rust.

Ahora bien Java no es funcional por lo tanto no podemos hacer cosas usando ese paradigma al estilo de Haskell, en todo caso Scala sería un competidor para éste (entonces ahí la comparativa tomaría otra vertiente).

Java no es sólo un lenguage

Cuando hablamos de Java, no sólo se toma en cuenta el lenguaje en sí, sino todo el ecosistema que tiene a su alrededor, sólo por darte un ejemplo: en el mundo empresarial (aplicaciones de alta demanda y muy distribuidas como las que usan los bancos, los grandes corporativos y los gobiernos) el lenguaje predominante es Java, y eso es gracias que muchos de los frameworks y productos más poderosos están creados con Java.

Tal es el caso por ejemplo de los servidores de aplicaciones como IBM WebSphere, JBoss (RedHat), Weblogic (Oracle). Plataformas de creación de contenido como IBM Web Content Manager, Liferay DXP también están construidas sobre Java.

Mientras empresas como IBM, Oracle, Amazon y Google, sigan creando productos empresariales en Java, es muy difícil que otra plataforma se posicione a su nivel.

Ingeniero de Software vs Arquitecto

Es cierto, como Ingenieros de Software nos gustan los lenguajes nuevos y brillantes, pero… como Arquitectos de Soluciones vemos más allá del lenguaje:

  • Vemos quién da mejor soporte,
  • Quién tiene más madurez en herramientas,
  • Qué tan complejo es encontrar profesionales con conocimientos avanzados,
  • Qué tantas empresas pueden implementar sistemas en tal o cual lenguaje,
  • Cuánto nos costaría mantener nuestras aplicaciones,
  • Qué tan riesgoso es elegir tal o cual tecnología,
  • Quién va a pagar el costo de los errores de producción cuando se presenten.

Haciendo la suma de todos los puntos anteriores, la verdad es que la lista de dónde podemos elegir se limita a dos plataformas: .NET de Microsoft o Java de Oracle, no hay más.

Los otros lenguajes se pueden usar para proyectos de otra naturaleza, pero no para el mundo de aplicaciones empresariales, donde una mala decisión puede costar millones de dólares o una buena decisión puede ahorrarlos.

Una decisión de millones

Ahora mismo, estoy involucrado en un proyecto de un gobierno de uno de los países más poderosos del mundo, y ahí por ejemplo este tipo de decisiones de arquitectura son decisiones que repercutirán por al menos 5 años.

Imagínate… 5 años es un tiempo muy largo en software, que cuando se tiene una buena base esos 5 años pueden ser muy productivos. O bien estos cinco años pueden ser de muchas pérdidas.

¿Y tu qué piensas sobre Java?

Te gustaría aprender otras cosas interesantes, qué tal sobre Los 10 mandamientos de un buen Ingeniero de Software.

Saludos cordiales.

¿Cuándo se creó Node.js?

Hoy una de nuestras webtrainees: Alejandra, nos comentaba que en su país había visto vacantes que pedían alrededor de 3 años de experiencia en Node.js. Entonces varias preguntas vinieron a su mente:

¿Es posible que alguien tenga experiencia de 3 años con Node.js?

Sí, si es posible; eso significaría que fue una de las primeras personas que comenzaron a utilizar Node.js en el ámbito enterprise. Node.js históricamente fue presentado por su creador Ryan Dahl por primera vez en la JSConf 2009 el 08 de noviembre de ese año, estas son las diapositivas originales usadas durante esa conferencia .

Ahora bien, si encuentras a una persona con tres años de experiencia en Node.js, eso significa que realmente es alguien con bastante experiencia en él ¡no lo dejes ir!

¿Te gustaría ver la conferencia original? Aquí la tienes.

¿En qué año se empezó a implementar Node.js?

Podríamos decir que Node.js despegó formalmente en 2013 que es cuando sale version 0.10.x, aquí te dejamos la tabla oficial tomada de nuestra querida Wikipedia.

Release Code name Release date LTS status Active LTS start Maintenance start Maintenance end
v0.10.x 2013-03-11 Old version, no longer supported: End-of-life 2015-10-01 2016-10-31
v0.12.x 2015-02-06 Old version, no longer supported: End-of-life 2016-04-01 2016-12-31
4.x Argon 2015-09-08 Older version, yet still supported: Maintenance 2015-10-01 2017-04-01 April 2018
5.x 2015-10-29 No LTS N/A
6.x Boron 2016-04-26 Current stable version: Active 2016-10-18 April 2018 April 2019
7.x 2016-10-25 No LTS N/A
8.x Carbon[65] 2017-05-30 Current stable version: Active 2017-10-31 April 2019 December 2019
9.x 2017-10-31 No LTS N/A
10.x Future release: Pending October 2018 April 2020 April 2021

Cuéntame ¿has usado Node.js para hacer cosas geniales?

Saludos.

Los 10 mandamientos de un buen Ingeniero de Software

Disclaimer: Este post no tiene nada que ver con religión. Respetamos todas las creencias y la fé que tienen nuestros amables lectores.

Leerás los requerimientos antes de empezar a codificar

Sabemos que nos encanta el código pero… trata de resistir la tentación de iniciar a codificar si antes haber leído tu lista de requerimientos, que esperemos que tu compañero Business Analyst haya preparado para ti. Si no hay una lista de requerimientos, créala, te aseguro que tu alter ego frustrado del futuro te lo agradecerá.

Diseñarás la arquitectura de tu aplicación antes de iniciar con el código

El mes pasado estuve leyendo el libro más reciente del Uncle Bob (a. k. a. Robert C. Martin): Clean Architecture: A Craftsman’s Guide to Software Structure and Design y en particular encontré muy buenas opiniones acerca de qué tan importante es sentarnos y pensar cómo vamos a construir nuestro sistema, no sólo se trata de la cuestión técnica de cuál framework usar, o si usaremos REST o GraphQL sino ir más allá, diseñar interacciones (inputs/outputs), prever casos dónde nuestro sistema pueda fallar, etc.

Una de las cosas que normalmente no hacemos es priorizar nuestras tareas. Y me gustó mucho esta frase:

I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.

– Dwight D. Eisenhower

Imagen de SafariBooksOnline.

Those things that are urgent are rarely of great importance, and those things that are important are seldom of great urgency.

Es decir, si algo es urgente casi nunca es importante y viceversa las cosas importantes rara vez son urgentes. La arquitectura de un sistema es algo IMPORTANTE.

No desearás el framework de tu prójimo

A todos nos encanta probar nuevos frameworks, la más reciente biblioteca para hacer tal cosa, lo más moderno, sin embargo, otra vez, trata de no desear lo que otros están usando y en su lugar pregúntate ¿realmente necesito migrar esta funcionalidad? ¿qué beneficios le traerá a mi cliente este cambio? ¿cuánto va a costar implementar tal o cual cosa? ¿qué tan importante es probar la nueva tecnología? ¿puedo re-usar partes de lo que tengo? ¿qué valor agregado me dará cambiarme ahora mismo? ¿estoy listo para dar el salto?

Te aseguro que después de responder las preguntas anteriores estarás más en paz con tu implementación y sabrás qué camino tomar.

Usarás un controlador de versiones

¿Verdad que no hay nada más triste que llegar a un proyecto y darte cuenta que nunca se guardó en un Version Control System (VCS)? Si puedes usar Git mejor; si no puedes por políticas internas no importa, pero por favor usa un controlador de versiones, te quitará muchos dolores de cabeza y reducirá drásticamente los errores en tu ciclo de desarrollo de software.

Crearás un conjunto de pruebas (si son automatizadas mejor)

Sí, estoy de acuerdo; crear pruebas para un sistema es una de las tareas más cansadas, largas y hasta tediosas, sin embargo son un excelente punto para asegurar la calidad de tu software y más aún, estarás creando un mecanismo para ayudarte a reducir la cantidad de errores cuando se agreguen nuevas características o se cambien las ya existentes.

Escucharás atentamente a tu equipo, ellos tienen mucho que aportar

Que no te gane el ego, todos tienen una opinión y una forma de ver las cosas. Nadie tiene la verdad absoluta; recuerda existen tres verdades:

  • Tu verdad: lo que tu crees que es lo mejor y lo más correcto
  • La verdad de tu prójimo: lo qué él cree que debería hacerse
  • Y la verdad: lo que realmente es correcto (ésta suele ser una combinación de las dos anteriores).

Pensarás antes de criticar el código de tu prójimo

Antes de decir ¡que $#$%@ es esto! Investiga, lee, documéntate, quizá quien creó el sistema o aplicación, lo tuvo que hacer en un tiempo muy corto y por ello no tuvo los recursos para crear algo mejor.

Quizá el ingeniero anterior tenía muchas dudas pero no fueron resueltas en el tiempo apropiado y tuvo que salir a producción con lo que tenía.

Quizá el cliente cambió los requerimientos a última hora. Esto casi no pasa ¿verdad?

Estarás en comunicación con tu Project Manager

Los Project Managers no son dioses, no son intocables, diles cuando no te sientas cómodo con los tiempos que te dieron para hacer tus tareas, que sepan que te están causando conflicto en tu vida porque ahora tendrás que desvelarte durante 4 meses para poder salir en el tiempo previsto.

Ellos son tus compañeros, son tus aliados y colegas, hazlos partícipes de tus preocupaciones. Qué sepan que vas a tener que hacer mucho más de lo que en su sistema de tracking de tareas dice.

Pedirás ayuda cuando lo necesites

Aceptémoslo, siempre hay alguien mejor que nosotros, y tu siempre sabrás algo más que otra persona. No cierres tus pensamientos a sólo lo que tu crees que es mejor, pregunta, lee y busca la opinión de quienes ya han recorrido por más tiempo este apasionante pero complicado mundo de la creación de software.

Encuentra a quien admirar, síguelo, busca su código, lee sus ideas, escríbele. Te aseguro que hay mucha sabiduría en esas personas que llevan muchos más años en estos caminos.

Buscarás en Google o Stack Overflow antes de preguntar

Tu tiempo es valioso, así como el de tu prójimo también lo es. Busca por tu cuenta primero, lee, estudia y analiza; tenemos mucha información en internet y claro en nuestro amado Stack Overflow, trata de solucionar tus tareas, primero por ti mismo.

Sin embargo, tampoco dejes que pase mucho tiempo, si ya pasaste más de tres horas con un problema y no encuentras la solución, entonces pregunta a tu prójimo, tal vez pueda ayudarte.

Tu servidor,

Alex Arriaga

Vue, el framework progresivo que llegó para quedarse

Estamos a mitad de 2018 y como siempre es un placer poder seguir en contacto y continuar aprendiendo cosas interesantes que nos ayuden a crear mejores proyectos de software.

Hoy te voy a platicar sobre Vue.js el llamado “Framework Progresivo” para creación de aplicaciones.  Vue.js fue creado con la simplicidad en mente, su aceptación se ha debido en gran medida a que incrementa mucho la productividad mediante el uso de un API muy bien documentado y fácil de comprender, incluso si no se tiene tanta experiencia en web.

¿Por qué aprender Vue?

A mi gusto, Vue provee un API mucho más sencillo de utilizar y manejar cuando se compara contra frameworks más robustos como Angular 2+; Vue fue de hecho inspirado en la primera versión de Angular conocida como AngularJS; de las propias palabras de su creador Evan You:

I started Vue as a personal project when I was working at Google Creative Labs in 2013. My job there involved building a lot of UI prototypes. After hand-rolling many of them with vanilla JavaScript and using Angular 1 for a few, I wanted something that captured the declarative nature of Angular’s data binding, but with a simpler, more approachable API. That’s how Vue started.
Fuente: Github Open Stories

Ventajas de usar Vue

  • No necesitas aprender un nuevo lenguaje como TypeScript para poder usarlo, aunque si te gusta TypeScript Vue es compatible con este lenguaje
  • Puedes usarlo como un reemplazo de jQuery para manipulación del DOM
  • Para casos más complejos puedes usar todo el poder del front-end moderno: ES2015+, Webpack, pre-procesadores, etc.
  • Curva de aprendiza muy corta
  • No requieres que tu aplicación sea de tipo SPA, ya que Vue puede irse adaptando a como lo necesites: por ejemplo lo puedes integrar con una vista de Laravel Blade, en tu app de Spring MVC, o en un módulo de tu CMS favorito (Drupal, Joomla, Liferay, IBM WCM, Umbraco, etc.)
  • Puedes usarlo en combinación con Node.js para hacer server-side rendering
  • Y más…

¿Cuándo usar Vue y no Angular?

Angular es un framework mucho más robusto que Vue.js eso quiere decir, que tiene muchos módulos y componentes avanzados que quizá no necesites en tu aplicación. Aquí hay algunos casos de uso donde NO se recomendaría Angular.

  • La aplicación NO es una Single Page Application. Angular fue pensando 100% para SPAs, si tu no estás desarrollando una Angular no es buena opción.
  • Tu aplicación sólo se comunica con muy pocos servicios REST externos (menos de diez end-points). Angular es muy bueno para aplicaciones empresariales complejas, pero para algo más sencillo es muy pesado cuando se compara con Vue.js.
  • Necesitas crear componentes sencillos integrados en la capa de vista de algún framework como Laravel o Spring MVC. Hay ocasiones que tenemos un framework de backend que hace casi todo, excepto que necesitamos interacción del usuario mediante JavaScript, Angular no sería natural en este caso de uso. Recuerda Angular funciona genial con SPAs.

Entonces ¿ya estás listo para continuar con Vue.js?

¿Dónde puedo aprender Vue?

En Webtraining.Zone tenemos un curso de Vue.js el cual fue impartido en vivo el martes 23 de enero de 2018. Este curso está disponible en: https://webtraining.zone/cursos/curso-profesional-vue-js

¿Cómo obtengo acceso al curso de Vue?

Si tienes una membresía en Webtraining.Zone ¡ya tienes incluido este curso!

Spoiler alert!
React is coming…

Tu servidor:
Alex Arriaga

Angular 5, la evolución sigue

Si bien la nueva versión de Angular había sido planeada para ser liberada el pasado 23 de octubre de 2017; eso no sucedió, pero no te preocupes hoy se acaba de liberar el Release Candidate #7 por lo que es muy probable que en muy próximos días Angular 5 ya esté con nosotros. Finalmente tenemos versión 5.0 estable y lista para ser usada.

En este último release se han corregido algunos issues menores, es decir, ya nada crítico está siendo arreglado en estos momentos.

¿Qué esperar en la versión 5?

Optimización en los bundles

Al parecer se acabaron los tiempos donde teníamos bundles de más de 500 Kb para aplicaciones sencillas; eso nos llena de alegría, ya que una de las mayores limitantes (hasta la versión 4) era que nuestros archivos generados eran aún pesados, incluso para aplicaciones con muy pocos componentes.

Ahead Of Time Compilation por defecto para la Angular CLI

Oh sí, mi buen amigo, finalmente ya tendremos AoT desde el inicio cuando se crean proyectos que usen la CLI de Angular. Esto es definitivamente algo excelente, ya que nos olvidaremos de estar pasando flags extraños al estar creando nuestra aplicación para producción.

Mejor Desempeño para Event Listeners

Se han aplicado algunas mejoras en la forma en cómo se registran eventos, como el documentado en este pull request.

¿Progressive Web Apps con Angular? Por supuesto que sí

En la versión 2 y 4, no existían mecanismos completos y bien documentados sobre la creación de Aplicaciones Web Progresivas, ¿y qué crees? en la versión 5, el equipo detrás de este genial framework ha puesto especial énfasis en este tema que cada vez toma más relevancia en todos los frameworks modernos. Angular no se quedará atrás y por supuesto que ya se está trabajando en hacer este tipo de aplicaciones mucho más robustas usando mecanismos de caché en el browser y otras mejorar que ya platicaremos más adelante.

Componentes de Material Design Listos para Server-side Rendering

Esto quizá es de las cosas que personalmente más espero, ya que actualmente Angular está muy “joven” en cuanto server-side rendering, incluso con la adopción de Angular Universal por parte de Google, la verdad es que nos nos han brindado una forma estable y potente para este tema, que es el motivo por el que muchos desarrolladores e ingenieros de software han descartado Angular para aplicaciones donde el SEO sea vital.

Tengo mis reservas en este tema, quisiera probar si realmente estos componentes funcionarán como es debido. Esperemos que sí.

¿Qué sigue?

  • Evidentemente, ya estamos ansiosos por probar la versión estable de Angular 5, así que tan pronto como se libere, estaremos probando todo lo nuevo en el día cero.
  • Angular 6 se empezará a cocinar tan pronto como la 5 sea estable ¿qué? sí recuerda que Angular adoptó el sistema SEMVER con lo cual se ha prometido tener nuevas versiones de Angular cada 6 meses; eso quiere decir que más o menos entre marzo y abril del próximo año tendremos Angular 6…

¿Tendremos un Curso Profesional de Angular 5 en Webtraining.Zone?

Por supuesto que sí, tan pronto como tengamos versión estable, estaremos creando un proyecto completamente desde cero para que puedas aprender todo lo nuevo.

Ya tenemos fecha y hora: 18 de Noviembre 2017 en punto de las 10 AM (Hora México Centro).

Inscríbete ahora al Curso Profesional de Angular 5 con Material Design: https://webtraining.zone/cursos/curso-profesional-de-angular-5-con-material-design
Nos vemos en ese curso, mientras tanto coméntame ¿qué opinas de Angular? ¿has tenido oportunidad de explorarlo?

Tu amigo Alex Arriaga

Angular vs Vue.js ¿qué framework me conviene aprender?

Hoy por hoy la cantidad de opciones entre las que podemos elegir para crear aplicaciones de front-end ha crecido exponencialmente; todos los días hay nuevas ideas, nuevas herramientas y metodologías y con ello llega el gran reto de poder distinguir bajo que circunstancias o casos de uso una es mejor que la otra.

En este artículo te platicaré un poco de mi experiencia personal con dos de los mejores frameworks (en mi opinión) que tenemos a la mano; asimismo te dejo un video de un curso rápido que tuvimos donde comparamos ambos frameworks.

Aclaro que este artículo NO se enfoca en cuestiones de performance, sino que trata de ser un punto de vista más general.

¿Por qué no incluí a React?

Porque hasta ahora no he tenido la oportunidad de trabajar con él a nivel profesional.

Angular

Creado por Google, como evolución de AngularJS. Es un framework muy robusto para creación de Single Page Applications, provee todo lo necesario para crear aplicaciones de cualquier tamaño. La comunidad alrededor de Angular es muy dinámica por lo que todos los días se generan nuevos módulos para las versiones más recientes.

Sitio oficial: https://angular.io/

¿Te gustaría aprender Angular desde cero?

Checa este Curso Profesional de Angular que tenemos en Webtraining.Zone

Ventajas

  • Preparado para cualquier tipo de aplicaciones
  • Excelente documentación técnica
  • Un buen número de módulos creados por la comunidad
  • Sugiere muy buenas convenciones para nombrar tus archivos, componentes, módulos y servicios
  • Hace uso extensivo de un stack moderno que incluye: TypeScript y Webpack.
  • Posee una Command Line Interface: Angular CLI que permite generar código boilerplate muy rápidamente
  • Preparado para lazy loading
  • Provee un modo producción y un modo desarrollo
  • Listo para Ahead of Time Compilation
  • Angular es MUY bien pagado en el mundo front-end empresarial

Desventajas

  • Angular es un framework complejo, por lo que la curva de aprendizaje puede ser alta dependiendo de tu experiencia previa
  • Es necesario aprender TypeScript, que aunque es un super set de JavaScript, agrega nuevas cosas como por ejemplo los tipos, las interfaces, los modificadores de acceso, etc. que pueden parecerte no naturales al principio (sobretodo si vienes del mundo de JavaScript 100%)
  • Es forzoso utilizar un proceso que incluya un bundler y module loader (como Webpack o Rollup.js)

Vue.js

Creado Evan You, es considerado un framework progresivo, es decir, es un framework que puede irse haciendo tan robusto como se necesite; ya que puede ir desde la simple inclusión de éste como una biblioteca JavaScript regular que sólo crea pequeños widgets, hasta un framework muy potente para crear aplicaciones completas.

Sitio oficial: https://vuejs.org/

Ventajas

  • No necesitas aprender algo nuevo, ya que se puede usar con ES5 o incluso con ES2015 si así lo deseas.
  • Puedes usarlo directamente en tu sitio web sin necesidad de tener un complejo sistema de empaquetado (es decir, no necesita Webpack para trabajar en su formato más simple).
  • Es un framework muy ligero
  • La curva de aprendizaje es muy amigable
  • Tiene una documentación muy “digerible” (se lee y comprende muy bien)

Desventajas

  • Mantenido por un pequeño grupo de personas, lo cual podría suponer un riesgo menor ya que la comunidad alrededor de Vue.js es muy grande (no te preocupes, puedes usarlo)
  • Vue.js te da mucha libertad, lo que para un desarrollador poco experimentado puede resultar peligroso cuando se trate de aplicaciones muy grandes
  • En general he visto que el salario ofrecido para un desarrollador de Vue.js es menor al de un desarrollador de Angular

¿Qué opinas? ¿cómo te ha ido con alguno de estos frameworks? ¿qué tipo de aplicaciones has hecho? ¿crees que sea bueno tener tantas opciones para elegir?

 

Como cambiar el editor de textos WYSIWYG de un campo text-html en Liferay 7

Por defecto Liferay tiene un editor de textos muy particular llamado AlloyEditor. Este editor es muy práctico pero a la vez poco intuitivo, ya que si estás muy acostumbrado a un editor como Microsoft Word -por poner un ejemplo-, el primero puede causarte conflictos a la hora de querer usarlo.

Como podrás ver en la imagen anterior, AlloyEditor no tiene una barra de herramientas fija en la parte superior como la mayoría de los editores. Para poder hacer uso de las herramientas que provee AlloyEditor debemos seleccionar el texto a editar y automáticamente nos mostrará un pequeña barra de herramientas para editar nuestro contenido; por ejemplo, poner el texto en negritas, hacer una lista, insertar un link entre otras opciones.

Si aún no estás convencido de quedarte con este editor, Liferay nos da la oportunidad de cambiarlo por algún otro de los que ya trae pre-cargados como (alloyeditor_creole, ckeditor, ckeditor_bbcode, ckeditor_creole, simple, tinymce and tinymce_simple).

Antes de pasar a cambiar el editor, debemos mencionar que cuando instalamos ó configuramos Liferay la primera vez, se van a generar varios archivos .properties dentro de los cuales se definen propiedades y características de inicio para Liferay.

Uno de estos archivos es portal.properties el cual se encuentra bajo /tomcat/webapps/ROOT/WEB-INF/lib/portal-impl.jar. Si tienes curiosidad, te recomiendo sólo hecharle un vistazo procurando no modificar ninguna de las propiedades presentes en ese archivo. Para poder modificar o agregar propiedades de nuestro archivo portal.properties debemos crear un archivo llamado portal-ext.properties (en caso de que no exista) bajo el directorio /tomcat/webapps/ROOT/WEB-INF/classes.

Bien, ahora que sabemos eso y explorando un poco dentro del archivo portal.properties nos podremos dar cuenta de que hay una sección con propiedades relacionadas con el editor de textos.

En la imagen anterior se ve claramente que tenemos comentarios (todo lo que inicia con el caracter #) con el nombre de la sección “Editors” además de tener también una  descripción de sobre los editores disponibles.

Como pudimos verlo en el título de este artículo, el acrónimo WYSIWYG es parte de la descripción y parte de los nombres de las propiedades, esto se debe a que es un término muy común cuando hablamos de editores de texto. El significado de este acrónimo por sus siglas en inglés es What You See Is What You Get que en español se traduce como “Lo que ves es lo que obtienes”.

Después de ese pequeño dato de cultura general, te platico que la propiedad que debemos modificar para poder cambiar el editor de textos que viene por defecto es editor.wysiwyg.impl.portlet.ddm.text_html.ftl la cual tiene asignado por defecto el valor de AlloyEditor.

Como mencionamos hace unos instantes, la manera correcta de modificar el archivo portal.properties es a través del archivo portal-ext.properties el cual va a sobreescribir los valores de las propiedades que anexemos a éste.

Tomando como base lo anterior, debemos copiar de portal.properties la propiedad a modificar a nuestro archivo portal-ext.properties. Ya que hemos copiado dicha propiedad, podemos asignarle cualquiera de los valores mencionados en la descripción de estas propiedades, en nuestro caso decidimos usar el editor ckeditor.

Ya con los cambios hechos podemos guardar el archivo portal-ext.properties y cerrarlo.

Algo muy importante y que no debemos dejar pasar es reiniciar el portal, para que de esta manera surtan efecto los cambios realizados.

Finalmente, después de haber reiniciado el portal, podrás ir al contenido y editar cualquiera de los assets/artículos que cuenten con un campo text-html y verás establecido ckeditor como editor por defecto.

Esperamos que este post te sea de mucha ayuda, nos vemos en el siguiente post y no olvides dejarnos tus comentarios.