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?

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é 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.

Bootstrap 4 ya está listo

Si eres un seguidor de este genial framework esta es una excelente noticia para ti. ¡Ya fue liberada la versión 4.0.0 de Bootstrap! ¡La última versión Beta de este framework fue anunciada el pasado 28 de diciembre de 2017!

Los creadores de Bootstrap nos han prometido que no habrá más breaking changes, lo cual es una excelente noticia, porque ahora sí ya puedes utilizar esta Beta final sin temor a que tu código deje de funcionar cuando se libere la versión estable 4.0.0.

There will be no breaking changes from Beta 3 to stable, so our changelog should be short and sweet.

Fuente: http://blog.getbootstrap.com/2017/12/28/bootstrap-4-beta-3/

¿Por que Bootstrap y no otro framework?

  • Documentación muy completa
  • Una comunidad de usuarios muy grande
  • Muchos ejemplos en los cuales basarte
  • Simple de aprender y usar
  • Muy personalizable, con unas cuantas líneas de SASS/SCSS tendrás un Bootstrap totalmente nuevo

Bootstrap ya está listo

La nueva y flamante versión de Bootstrap ya fue liberada, así que ahora sí tenemos versión estable 4.0.0.

¿Cuándo se liberará Bootstrap 4?

No hay fecha confirmada, sin embargo si revisamos la lista de issues abiertos en Github ya son menos de 15 al momento de escribir este artículo. Te invito a que lo veas por ti mismo en: https://github.com/twbs/bootstrap/projects/12

¿Dónde puedes aprender Bootstrap 4?

Por supuesto, aquí en Webtraining.Zone tendremos un Curso Profesional de Bootstrap 4, así que inscríbete ahora y reserva tu lugar.

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