Mi Viaje de Configuración: Manteniéndolo Sencillo

xcode-select --install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew install --cask iterm2

ZHS y Oh My ZSH

brew install zsh

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" 

¡Felicidades por llegar a la fase de tuneo de tu terminal!

brew tap homebrew/cask-fonts

brew install font-{nombre-de-la-fuente}

bash -c  "$(curl -sLo- https://git.io/vQgMr)" 

Plugins y Configuraciones Adicionales

Bueno vamos a los pasos que he seguido para poder ejecutar el Hola Mundo con un emulador de Android en mi Mac M1.

#Paso I 

Pues descargar el android studio, en un curso de kotlin básico que ando tomando me han recomendado bajar el IntelliJ IDEA community, pero la verdad para poder ejecutar el emulador lo hice con android studio y pss básicamente es lo mismo. Puedes descargar aquí.

#Paso II

La típica apple installation, y luego el next, next finish, deberán ver una pantalla como esta. 

#Paso III

Ahora para probar y hacer jalar lo del emulador, le damos en >New Project, y yo elegí el ejemplo de Bottom Navigation Activity, le damos al Next. 
Y en la siguiente pantalla verificamos que el Language sea Kotlin y en el Minium SDK : API 30 Android 11, en caso que no tuvieran un sdk instalado les mostrará un pop-up para que instalen. Y le damos al finish.

Deberían ver algo similar a esto. 

Ahora en la esquina superior izquierdo centro, hay una pequeña como martillo, que es para compilar, le picamos, puede que les marque error como a mí, algo así. 

So, habrá que ir al menú Tools > SDK Manager. 
Ahí elegir el correspondiente (aka lo importante por que me paso es que yo puse primero el x86, y deben elegir el de arquitectura arm64)

Y con esto básicamente estamos ready, vuelven a darle al botón de compilar y todo debería ir viento en popa, y por ultimo le pican al triangulito verde, que es como de play, y voila.

Errors
Links
Included

#Errors

Posiblemente el segundo miembro más importante después de data, es errors. Ya que contiene como su nombre lo indica, todos los objetos de error y debe ser un array.

Como observamos en la imagen la estructura, seré breve explicado cada uno de los key's, empezando por: 

status se recomienda usar un status http que haga referencia a el title del error, si no saben todos los estatus http, denle click a.k.a. 

El detail puede ser una breve descripción de qué causa el error y el source que es un objeto que apunta al lugar dentro del documento que contiene dicho error. 

De igual manera se puede utilizar otros miembros como links, meta, pero nunca data cuando se devuelve errors.

#Links

Por lo general este contiene los enlaces de una paginación, y es común complementar con el objeto meta para enviar más info relevante.

#Includes

Como recordaran dentro del Resources Object, en relationships si mostramos el miembro links sería para conocer los url para manipular la relación y acceder a los datos de la misma, si quisiéramos incluir los datos y/o atributos de la relación es dónde usamos included, el cual contiene todos los Resources Object, que están relacionados con los datos primarios, y se le conoce como Compound Document.

Esto es una breve explicación de los elementos que forman parte de una respuesta con la especificación JSON:API, si tienen dudas comentarios, dejen sus comentarios, igual siempre es bueno consultar la documentación oficial. 

~Happy Coding

Para leer este post el único requisito es que lean mi post anterior, ya que esto es la continuación de. Les dejo aquí el link.

Bien, pues sin más rodeo continuemos, el elemento por el que empezaremos en Data, ya que es el más importante pues contiene la información principal del documento.

En caso de tener 1 solo registro puede ser un objeto o un array de objetos si se obtienen varios registros. O bien según sea el caso puede ser null o un array vacío.

A cada uno de estos objetos se le conoce como Resource Object, y lo que debe contener cómo se aprecia en la imagen es un tipo y un identificador por mínimo y ambos valores deben ser strings. Si solo contiene lo mínimo requerido, se le conoce como un Resource Identifier Object, ya que solo sabemos que es el customer con id 1. Adicionalmente puede contener: 

attributes
relationships
links
meta

Veamos cómo se forma cada uno.

#Attributes

#Relationships

El campo relationships que contiene las relaciones, y cómo podemos ver cada elemento es el tipo de recurso y dentro debe existir al menos uno de los 3 elementos.

En data tenemos los objetos identificadores de recurso, pero no tenemos los atributos, esto con el fin de mantener el peso de las respuesta y si el cliente necesita esos recursos, ya sabrá cual es el id.
Links es un objeto que contiene al menos uno de estos elementos, self / related. Self es un enlace para la relación en si, este permite manipular directamente la relación. Related es el enlace al recurso relacionado, nos devolverá dentro del elemento data el resource object de Address, en este caso.
Por último Meta es cualquier información adicional que se quiera dar.

Recapitulando, este es el resource object y los elementos que puede contener, recordemos que obligatorios solo son el type y el id y el resto son opcionales.

Listo, hemos visto la estructura de Data, en el post pasada les hable de meta y jsonapi que son bastante sencillos. Así que veamos links.  En el siguiente post por que esto ya se extendió.

~Happy Coding

¿Qué es JSON:API Spec?

Es una especificación de cómo un cliente debe solicitar que se busquen o modifiquen recursos, y cómo un servidor debe responder a estas peticiones. Esto con el fin de mantener un estándar. 

Pero, ¿Por qué utilizarlo?

Empecemos por un caso que estoy viviendo en mi trabajo actual, es un caos, como hay servicios que aún se están desarrollando, la respuesta no mantiene la estructura, no hay un estándar, el front no sabe que esperar, todo lo malo es un 400 y todo lo bueno es un 200.

Aquí van algunos puntos de por qué la vida sería más fácil al usar esta especificación.

• Convención
  • Al tener reglas preestablecidas, tanto front como back se pueden desarrollar en paralelo. Ya que estamos seguros de que formato tendrán las peticiones y las respuestas.
• Eficacia en el desarrollo
  • Al no tener que crear tu propia convención, solo queda enfocarse en la lógica de negocio.
• Herramientas
  • Existen muchas que nos facilitan el adherirnos a la especificación tanto para consumir como para crear. Aquí  puedes checar las implementaciones en diferentes lenguajes y frameworks.

Todo esto ayuda a tener buenas prácticas y claro un software de mejor calidad.

Pero bueno, dejemos de tanto dato duro, y veamos la estructura de un documento. Como documento sabe' que me refiero al cuerpo de una petición o respuesta no? 😜

Tanto el API con el cliente debe ignorar cualquier otro miembro que no se contemplen aquí. Sin embargo esto no quiere decir que siempre deban existir todas estas llaves en el documento.

Esto es bastante claro, si la respuesta es correcta se devuelve 'data', si por el contrario contienen errores entonces traerá 'errors', pero nunca ambas al mismo tiempo. 

El miembro 'meta', básicamente es para cualquier información adicional que deseemos incluir.
'jsonapi' es un objeto que contiene la versión del API, si no se envía se asume que es la versión es la 1.0

Aún queda explicar el resto de llaves, y profundizar en data, ya que este es el miembro más importante por que contiene la información principal del documento. Y otros detalles, pero para no extenderme más lo escribiré en un segundo y posible tercer post. 

Si ustedes son impacientes lean la especificación JSON:API y comenten sus experiencias si ya han usado esta o las complicaciones que han vivido al no usar algún estándar.

~Happy Coding

Blueprint es una herramienta que nos ayudará a generar múltiples componentes de Laravel a partir de un archivo legible por cualquier hobbit de nuestra comarca.

Instalar este paquete es muy sencillo, una vez en nuestro proyecto de laravel, en terminal ejecutamos: 

$ composer require laravel-shift/blueprint --dev
$ php artisan vendor:publish 

Explico brevemente, el primero es para agregar el paquete a nuestro proyecto solo cuando estamos en desarrollo, el segundo es para publicar la configuración de paquetes, (nos agregar un archivo dentro de la carpeta config); en este paso hay que elegir el paquete del que queremos la configuración vean mi captura de pantalla.

Cómo pueden observar al ejecutar el vendor:publish podremos elegir en este caso la 10 es la de blueprint.

Ahora editamos el archivo que nos creo en config, blueprint.php con los siguientes valores.

'models_namespaces' => 'Models'
'use_constraints' => true
'use_guarded' => true

Ahora explico rápido, el models_namespaces es opcional, para este caso en mi proyecto si quiero tener los modelos dentro de un folder. 

El constraints es creo lógico sirve para que si nos agregue los constraints de las llaves foraneas. Y el guarded para que al crear los modelos la propiedad sea un array vacío.

Ahora sí viene lo chedo! Blueprint es tan sencillo de usar como crear un archivo en la raíz de nuestro proyecto llamado draft.yaml.

Les dejo un ejemplo en este link para que se lo puedan bajar, revisar. Creo que será muy fácil de entender. Una vez que lo tengan listo pueden ejecutar el siguiente comando 

$ php artisan blueprint:build

Y como por arte de magia,

se genera todo, como podrán observar en el yaml que les deje, en los id no es necesario especificar que son llave  foranea por que cambiamos el constraint a true en el config.

Pro tip usen phpstorm vayan al modelo User, click derecho > Refactor > move class y listo elegimos la carpeta models, checamos que esten marcados los checkboxes y le damos a <do refactor >

~Happy coding

Pero a veces recordar muchos comandos con sus parámetros puede ser tedioso, entonces para agilizar la ejecución de algunos comandos recurrentes hice lo siguiente.

Recuerden que para esta receta, necesitan una terminal y que su OS este basado en unix. 

Primer paso abrimos la terminal y vamos a nuestra carpeta raíz [cd  ~/], ahora creamos un archivo llamado .bash_profile (este muy seguramente no existe).  Dentro de este creamos con la siguiente estructura tantos alias como queramos.

alias [alias_del_comando]='[comando]'

alias es la palabra reservada, y lo que viene en corchetes es lo que remplazaremos. 

Ya que terminamos de agregar nuestros alias, guardamos y ejecutamos

$ source .bash_profile

Para poder ver los efectos de nuestros alias, o cierren y abran la terminal 😝. 

Bueno hoy si usan MacOs les mostraré el cómo cambiar el nombre por defecto las capturas de pantalla y elegir otra destino que no sea el escritorio, obvio de una manera pro, utilizando nuestra terminal. 

$ defaults write com.apple.screencapture name "capture"

El primer comando lo que hará es cambiar el nombre a capture, en versión actuales de MacOS el sufijo de fecha se quedará. 

Ahora para mover a otra carpeta hice el siguiente movimiento.

$ mkdir ~/Pictures/screens 
$ defaults write com.apple.screencapture location ~/Pictures/screens 

No olvides reiniciar el UI, para que todo lo anterior tenga efecto

$ killall SystemUIServer

Y listo con eso ahora mi escritorio luce más limpio. 

La pandemia ha traído muchos cambios a nuestra forma de vivir e interactuar, uno de ellos es el trabajo remoto.

Si bien, trabajar de manera remota no representa una novedad, el confinamiento ha presentado una oportunidad única para probar su validez en ciertas áreas donde es viable y no se requiere de presencia física.

Hoy tras dos meses de trabajo remoto el CEO de twitter Jack Dorsey, anunció que sus trabajadores podrán seguir trabajando desde casa si así lo desean, incluso después de que finalice el confinamiento y se pueda volver a las oficinas. [Ver original]

No es la primera vez que Jack Dorsey deja ver algo por el estilo. En febrero de este año precisamente comentó que concentrar a sus trabajadores en las oficinas de San Francisco ya no les era útil. 

¡Otras empresas que ya habían dado el paso!

Si bien este movimiento de Twitter es un gran paso para el home office, no es empresa pionera en ello.

Empresas como WordPress, los cuales cerraron sus oficinas en 2017 para trabajar completamente en remoto. Otras empresas como Gitlab y Basecamp, además de que todo el mundo trabaja remotamente, promueven encarecidamente este método de trabajo. 

Si no me creen, chequen este libro de Basecamp REMOTE: Office Not Required. 

Ustedes que opinan, creen que cada vez esto sea más común?

Ahora tenemos más detalles, junto a un hermoso y actualizado sitio web.

Taylor anunció en el blog de laravel, 

Por lo general, hago los principales anuncios del año en vivo en el escenario en Laracon US. Este es un momento increíblemente emocionante, pero me molesta que muchas personas en todo el mundo nunca tengan la oportunidad de experimentar esos anuncios en vivo.

La misma línea de oradores planeada para Laracon 2020 US permanece en su lugar, con más anuncios de oradores por venir.

¿Qué significa esto para el evento actual de Laracon Online?

El evento en línea de Laracon que ocurre cada año alrededor de febrero contará con un nuevo formato para diferenciarlo del evento de verano, pero los detalles exactos aún están por llegar.

¿Qué significa esto para futuros eventos de Laracon en Estados Unidos?

Taylor mencionó en su anuncio que un evento en vivo y en persona es posible en 2021 y que "... el evento probablemente tendrá un énfasis en profundizar en los detalles esenciales de los anuncios de características realizados durante nuestro evento en línea".

¡Sin más recuerden que pueden comprar boletos ahora en el sitio web de Laracon por $29 usd !